Welcome back to the blog! It's been a while since our last post, so we're going to start with a series of posts getting up to speed with our last few robots. Starting off with our 2024 robot, Toucan. Toucan played there 2024 FRC game Crescendo (Game Animation), with a focus on scoring notes into the speaker and amp.
Sunday, June 21, 2026
Open Alliance: A Working Robot
Originally posted on ChiefDelphi on Feb 27, 2024: https://www.chiefdelphi.com/t/frc-2412-robototes-2024-season-build-thread/448663/14
Open Alliance: A Working Robot
Over mid-winter break we were finally able to catch up a bit and assemble the full robot. We were also able to test it out with our programming!
Mechanical delivers
We thoroughly used mid-winter break, meeting every day of it for nearly the entire day each time (with mech meeting mornings and programming evenings). In exchange for our time, mech was able to deliver a fully-assembled robot.
As foreshadowed in my last post, we did end up increasing the size of our wheels. Our intake was just a bit too low to the ground to effectively intake notes. To do this, we ended up just printing larger TPU tires to fit around our billet wheels.
Low infill percentages make the tires a little squishy in a manner similar to Michelin’s Tweels
We started off mid-winter break away from the shop. With our school closed due to President’s Day, we met at the newly christened Steamnasium, which is an old school district building our district turned into a robotics hub (after advocacy from district teams). Go Bellevue Alliance!!
The Steamnasium a few weeks ago. The field elements are all mostly in place now.
Since we were away from the shop, we weren’t able to make massive progress with the bot mechanically. However, we were able to attach the intake rollers and test them out… at which point we discovered that we had made them too high off the ground for the notes to be affected by them. However, this was a pretty simple fix of just adding spacers to the mounting hardware for intake. Later, for a more permanent fix we simply decreased the diameter of our wheels slightly.
In general, we were able to fully manufacture each part of the robot either before or during the beginning of mid-winter break. However, assembly ended up taking a sizeable chunk of time.
Fixing the launcher to the pivot assembly.
However, by Friday night mech finally had a workable robot to hand over to Programming.
Programming gets the robot
Programming ended up with Friday night and most of Saturday to work with the robot. Wasting no time, they got right to work testing the core features of the robot.
Working from bottom to top, Programming started with intake. With the new wheels and spacers, intake worked quite well. Although worn down notes don’t slide as well on the carpet into the ingestion system, the robot doesn’t need to give much more assistance moving on top of the note for it to reach the index. Unfortunately, we didn’t capture any video of this in action.
Index and feeder systems also worked alright, but we did identify one case where notes can get stuck in the belly pan. This happens when we intake when the launcher is vertical, which is when we have the largest gaps in our rollers.
Before we added an extra bar, this pivot angle would sometimes cause notes to get stuck in the bellypan.
Finally, we tested out the launcher and pivot. These also worked quite well. We were able to make several shots from a few tested distances. For control, for now at least we’re using a combination of manual control using controller joysticks and presets for common positions such as at the subwoofer.
https://www.youtube.com/watch?v=L4fpbbUsiAY
Video of the launcher making a shot into the speaker
For fun, we decided to launch a note straight up into the air. For reference, we estimate the room of the atrium (where the note is launched in this video), to be about 60 feet high.
Open Alliance: Manufacturing and Assembly
Originally posted on ChiefDelphi on Feb 20, 2024: https://www.chiefdelphi.com/t/frc-2412-robototes-2024-season-build-thread/448663/13
This post was written on Friday the 16th
This past week has been hyper-focused on manufacturing, assembly, and general preparation for robot testing.
Mechanical Work
Mech has been working to catch up to meet the robot deadline but has been set back by assembly errors and some issues regarding organization. Nevertheless, Mech has been making some serious progress.
It drives!
Index and Intake Assembly
Pivot Plates
Our Omio CNC has been super busy this past week cutting both aluminum and polycarb plates. Here’s a nice photo of some cut aluminum plates we’re using for our pivot this year.
Programming Prepping
Programming has spent the week finalizing robot code and adding additional functionality anticipating issues during robot testing. For one, we’re adding diagnostic commands to each of our subsystems. Running these commands tests all functions of the subsystem. Once Mech hands over the robot, we should be able to power through each these diagnostic commands and figure out quickly what needs to be fixed.
As mentioned in my last post, we’ve also been focused on adding logging and we hope this will also speed up our testing of the robot. Generally, with mechanical delays adding up, programming is expecting to have its timeline shortened, so we’re trying to prepare for that possibility.
Finally, our fully integrated launching command has also been implemented. We use a vision-enhanced robot pose to calculate the robot’s yaw angle to to the speaker, then use PID control to rotate the robot to that angle. For launcher angle and RPM, we use an interpolating tree map with data interpreted from a CSV file. Once the robot is aligned to the speaker and the launcher is up to its target RPM, the drive controller vibrates to signal to the driver that the robot is ready to launch. We used a very similar setup two years ago for Rapid React and it worked well, so we’re hoping for good results this year as well.
As for the general mood on programming this past week… well, there’s been a lot of references to one of our Instagram reels we posted a few weeks back.
That’s about all for now! I’ll have more updates soon as next week is Midwinter break for us (aka next week is all robotics).
Thursday, February 8, 2024
Open Alliance: Coming Along
Hi all! This past week we have been focused on refining our CAD,
ordering parts, and generally preparing to move forward towards more
hands-on manufacturing and assembly.
CAD Polishing and Design Review
Our team’s CAD experts have been hard at work polishing up our robot CAD and finalizing the last elements of our design. On Tuesday we held a design review with both the programming and mechanical teams to review the CAD and ensure everyone is on the same page. This consisted of the Solidworks CAD being presented with a few mech members going through the design choices of each subsystem. Speaking of design choices, let’s highlight a few interesting ones.
Flywheel motors
We’re using Vortexes for our flywheels, and, to keep everything within the launcher frame, we decided to put the motor itself inside a few of the wheels. We’ll see how well the Vortexes handles the temperature dissipation constraint of being wrapped in a rubber wheel once our robot is up and working.
Tensioned Rollerbar Belts
We’re using RoboBitz’ RoboRollerz for our indexing up until the launcher flywheels. All the rollers are driven together via belts and gears. The belt path is shown by the thin gray lines along the rollers in this CAD screenshot. The two wheels next to the middle roller aren’t completely fixed along the vertical axis. If you look closely, the slots they move along are visible. All this should help keep our belts tensioned.
Pivot
Our pivot geometry ended up a pretty interesting this year due to space constraints caused by the location of our swerve modules. We also employ a tensioner here for the chain. This pivot design is pretty similar to the one used in the arm of our 2023 robot, Crane.
Programming Updates
We’ve also been progressing along on the programming team.
LEDS
We’re now looking to add an LED strip to the robot. We’ve realized that with our under-the-bumper intake and with field elements heavily restricting driver vision, we need some way to signal to drivers that the robot has successfully picked up a game piece. We’d also like to be able to signal to human players which amp buttons we’d like them to press.
Logging
We’ve also been focused on adding additional logging and configuration to all our subsystems. We’re trying to reduce the time we spend tweaking values during tuning. The last few years, we’ve had to redeploy code over and over to adjust things like PIDF values. This year, we should be able to do all that tuning through Shuffleboard. To help with this goal, I wrote a sendable wrapper class for the Spark Max PID controller.
That’s about all the updates I have for now. See you in the next post!
Open Alliance: More Robot Updates
We’ve dived deep into the development process. We’ve made good progress with our CAD, our code, and our physical prototypes.
More prototype progress
For quite a while, we were stuck with our launcher prototype. It wasn’t shooting consistently, with the notes occasionally flipping in the air and with irregular trajectories. Eventually, however, we did discover a few issues. First, we added another set of rollers before the flywheel. These additional rollers improved the consistency of the note’s angle as it entered the flywheel. They ensure the note is level relative to the flywheel. Next, we actually tuned PID for the flywheel. This helped us ensure consistent testing as the flywheel’s speed was more predictable. Finally, we reduced the horizontal compression of the note. It’s now only compresses the note 1/16th of an inch on either side of the launcher. With less compression, the note maintains a more circular shape as it proceeds through the launcher.
Our launcher is now much more consistent
We also tested out our launcher’s amp scoring capabilities. Inspired by Team 4481 Team Rembrandts, we decided to try out scoring into the amp by reversing some rollers. This method worked pretty well with our design.
With these tests, we found our flywheels would push the note up towards the top of the amp and keep it from scoring down. However, once we moved away, the note did fall right in.
CAD Progress
After inspecting a bit more climb geometry, we realized that our selected climb design would have difficulties lifting our robot high enough to allow our launcher to score into the trap. We’ve also been paying close attention to threads here on Chief Delphi discussing shooting into the trap from the ground. With these developments, we decided to pivot on our climb decision. Rather than employ a separate climb subsystem, we’re attaching two hook systems to our launcher. We’ll use two pivots off our launcher with hooks attached at a distance.
We expect to be able to reach at least 3 feet from the ground with this design, allowing us to climb along most of the chain. We also expect this design to allow at least one other robot to climb along with us on the same chain, although having all three robots on the same chain seems unlikely. We plan to shoot into the trap throughout the duration of the match. Once we have our stage built, we’ll do some more launcher testing with it, and we hope to achieve decent accuracy.
Code Progress
Our programming team is progressing along well. Our programmers are split between subsystems right now. I’ll include details on some of the interesting developments
Drivebase
We’ve continued our experiments with Choreo and PathPlanner for autonomous. We created a few diagnostic paths for us to tune our odometry and PID on. These paths consist of a marked starting location (we use a tape square on our field), a difficult trajectory (mostly spinning or capricious translation), and then a return to the start location. Using these paths, we can identify what kinds of movements mess up our odometry the most. Then, we plan to identify methods to reduce odometry error.
This path featured lots of rotating which messed up our odometry a lot.
Vision
This year we’re not only continuing our AprilTag vision exploration, we’re also branching into object detection with Limelight’s neural network interface. We plan to include AprilTag cameras on the front of the robot (the same side as where the notes are launched from) and our Limelight for object detection on the back of the robot.
Since we’ll generally be facing our targets when lining up to launch, we decided on only placing AprilTag cameras on the front of the robot. This might come back to bite us if this isn’t enough data for accurate odometry correction, but we’ll see.
We also decided on really only using object detection for our autonomous pathing. We plan on using object detection to both improve our pathing toward game objects, and to see if game objects are really there before we path towards them. Since this game has a set of game pieces that are accessible by either alliance, we want to make sure the game pieces are really still there before we spend time moving towards them. If game pieces have already been taken, we’ll instead switch to a different autonomous trajectory. Since we expect to always be facing towards the speaker during auto and therefore the center line game pieces will always be facing the back of our bot, we decided to only put game object detection cameras on the back of the robot.
Climb
Previously to our decision to nix the separated climb subsystem, we had a climb programming group. Now that climb is integrated with the launcher, we’ve moved those programmers into our intake group. They’re helping integrate sensors into the design.
Okay, that’s about all the updates I have to share. More to come soon!
Open Alliance: More prototyping and our selected robot design
Our second week into the season saw lots of discussion from our robot
design team in selecting our robot design as well as the completion of a
new launcher prototype.
New Launcher Prototype
After our first robot design team meeting, it became apparent we were really leaning towards selecting a horizontal roller launcher design. However, we realized that we hadn’t quite prototyped that kind of design yet. So, before we locked in on it, we decided to create another prototype to confirm the idea.
This prototype features another set of wheels before the flywheels to stabilize the note as it is launched. We also played around with using uneven wheel sizes to add some spin to the note, although this prototype does not implement that idea.
Altogether, this prototype worked quite well with it being able to shoot consistently at a good distance.
Our robot design
Our robot design team met several times this week and spent a lot of time discussing our robot’s design. Due to illness and our uncertainties regarding a climb design, we were slightly delayed, with the final robot design only having been decided this past Saturday.
Let’s start with the intake.
We decided to go with an under-the-bumper design based on one of our
earlier prototypes. Our swerve modules are lifted, allowing notes to
pass under our bumpers and be picked up from our rollers. We use four
driving rollers on each side of the robot, allowing our robot to pick up
notes from all sides. We also plan on using these driving rollers to
reject notes once we have one stowed.
Next, our launcher.
Our launcher design is very similar to the prototype we created earlier in the week. We’re going to attach our launcher to a pivot so that we can both aim our speaker shots and make our amp shot. To make the amp shot, we’re planning on using a hood or some other retractable system to redirect the note into the amp.
Finally, our climb
Our climb design is inspired by FRC 95’s 2022 climber.
Although not pictured in this mockup, the climb will use torsion sprung arms regularly held down by a string attaching the hook of the arms to the drivebase. When we want to climb, we will extend the string, allowing the arms to extend up towards the chain. Pulling the arm back down with the string will complete our climb.
We’re hoping to ensure that our climb will bring the chain at the same level as our launcher pivot. Doing so should allow us to launch a note into the trap by first opening the trapdoor using our hood and then using the same hood to redirect the note similar to how we expect to score in the amp.
There’s our robot design! We’ve started CAD and programming work for each of the subsystems. One of our goals this year is try and reduce the time between concept and physical, working subsystem, so hopefully in future OA updates you’ll see these subsystems come to life soon! See you then!
Open Alliance: Prototyping Week
We just finished our prototyping over here at the Robototes. This
post will cover all our insights, troubles, tribulations, and more that
came with prototyping! Hopefully teams that have not yet decided their
final designs can learn a thing or two from us.
Prototyping Philosophy
We try to prototype only for problems that we haven’t dealt with before - like how to interface with a game piece or element. We don’t prototype things like a telescoping arm or other systems that we already have experience developing.
At the start of the week, we split into 5 mechanical prototyping groups plus one programming prototyping group. I’m going to go over each group one by one.
Shooter
This prototyping group focused on creating a feasible shooter design for our robot. After some discussion, they settled on starting with a design similar to the shooter featured on the kitbot.
The shooter group’s first prototype
After this initial prototype, they iterated by replacing the wall with more wheels. Then, they drove each side with NEO Vortexes. They experimented with using solid rubber wheels, but accidentally found that the wheels simply couldn’t handle the RPM.
Ultimately, using compliant wheels with 5 inches of compression proved very effective with this prototype. One side was driven at a slightly lower RPM so that the note would have some spin as it exited the shooter. According to their testing, roughly 5-10% difference in power between each side was ideal for stability. The distance traveled by the note was consistent although sometimes the note would drift sideways in the air.
Shooter + Amp
The next prototyping group was directed to create a design that could score in both the speaker and amp. However, pretty soon the group found that its concepts could also be applied to work as an intake as well as a shooter. Their first concept involved an under-the-bumper intake-shooter combo attached to an arm that could raise to score in the amp.
One of this group’s initial prototypes, with a reminder to always wear safety glasses. This video was posted as one of our Instagram reels and as of now has 12.4 million views!
However, the group found that the rollers would accelerate too slowly when the note was loaded to function as a shooter. Their next designs continued their concepts of an intake-shooter combo, but these designs allowed for a note to be held away from the wheels to allow them to spin up before the note is sent through. These designs also did away with the arm.
This design intakes from all sides of the robot. Before the notes are shot, they are held against the ground in the center of the robot. Lift kits are used on the swerve modules to gain a few extra inches of clearance. While the group did test scoring in the speaker with a similar design, scoring in the amp was never tested.
This prototype is similar to the final CAD model’s shooter and worked well
Intake + Amp
This group’s assignment was to prototype a design that could function both as an intake and as an amp scorer. Their first idea was to use two sets of rollers with tread between them to intake and hold the notes until they could be scored in the amp. This design would be attached to a pivoting arm to allow the height required.
The design intaking
The design scoring in the amp
This concept proved to be simple and effective. A little while into prototyping, this concept was actually applied on the Unqualified Quokka’s Ri3D team 2, proving the design could work.
Ground Intake
This group was tasked with coming up with an optimal intake design. They choose to go the under-the-bumper router, using rollers and compression to lift the note off the ground.
In testing, their design proved effective in picking up notes
This group also experimented with how their intake design could integrate into a larger robot.
Climb + Trap
Since we didn’t have a chain to reference yet, this group had trouble actually coming up with things to prototype. In the end, most of this group was dissolved into other groups with few members sticking behind to come up with insights and concepts that could later be applied to the real robot. In the end, they recommended using two climb-in-a-box kits with high-grip hooks to lift the robot up on the chain. For trap scoring, they recommended the arms be off-center, so the robot leans into the core of the stage. To open the trap, they suggested some kind of linear actuator that interfaces with whatever scoring system is chosen. They also found a Ri3D team that had a similar climb design as they had brainstormed. 2
Programming Prototyping
While most of our programmers join mechanical prototyping groups to advise their work, a few programmers stayed behind to research new programming concepts.
This year, our programming prototype group focused on researching Yet Another Generic Swerve Library (YAGSL) 1, pose adjustment with AprilTags, and game piece detection using Limelight’s new neural network features.
Since coming across YAGSL, our programming group has wanted to try it out. The first year we used swerve, we used Swerve Drive Specialties’ swervelib to drive our modules. Last year, we switched to WPILib’s swerve implementation. In both those cases, our drivebase code ended up moderately messy. We were really hoping that by switching to YAGSL we could cleanup our side of drivebase code and leave the nitty-gritty details to YAGSL.
Unfortunately, as CTRE just released Phoenix 6 API to all, we found the 2024 version of YAGSL to be pretty buggy with this big switch-up. We ended up spending nearly the whole week debugging. However, by the end of the week, we did have a working robot. For those also trying to get YAGSL working on their robot, check out our repository for an example of a working implementation. 5 I’ve also submitted a few PRs to YAGSL’s repository to help clean up some of their bugs.
Game piece detection was quite quick to setup. We used our v1 limelight with Coral’s AI accelerator 3 to speed up the game piece detection. At the end of the week, we were working on generating paths to drive the robot directly to the game pieces, but we weren’t quite able to finish in time. We’ll continue exploring this further into the season.
That just about wraps up this massive update! See you soon as we continue into build season!
Open Alliance: Kickoff
We started our kickoff bright and early Saturday morning, tuning in to the game reveal livestream. After the livestream, we split into groups to analyze the game manual. There were five groups; Two groups for game rules and a group each for robot rules, scoring, and endgame. Each group read through and discussed the game manual, then created a PowerPoint presentation on it. Once all the groups were done, we presented our presentations to each other.
Reading through the game manual
After our presentations, we took a break for lunch. Of course, the game analysis doesn’t stop during a break. Most of our conversations as we ate were still focused on the game.
After lunch, we moved on to an activity that’s become somewhat of a kickoff tradition on the team. In order to better understand the game, we play a match of that year’s game using our bodies as robots. We get 6 team members to volunteer and act as robots while the rest of the team makes observations on their dynamics. This year, since we held the activity after lunch, our “robots” had a lot of energy and maybe got a bit too into the competitive side of the activity, so, while lots of fun, we didn’t glean a ton of useful observations.
Next up, we separated into new strategy brainstorming groups. Similar to our game analysis groups, these groups discussed potential game strategies, then created a PowerPoint presentation on their findings.
Another group’s thoughts on the game
For most our team members, after we finished up our strategy presentations, the day was over. However, for those on this year’s Robot Design Team, there was still plenty of work to do. The 2024 Robot Design Team is comprised of 6 veteran technical students and 6 mentors and is tasked with choosing the final robot design. As soon as strategy presentations had concluded, the design team started discussing our plans for the coming week. We first determined our robot priorities. We identified a floor, touch-it-own-it intake as a high priority alongside reliable speaker scoring. Next, we decided what we planned on prototyping in the coming week. We decided on five prototyping groups, consisting mainly of intake and shooter variations alongside one group prototyping solutions for the stage and trap. Finally, we ended the meeting making some decisions on what needed to be purchased immediately.
Overall, Saturday’s kickoff was a great start to the season and we here at the Robototes can’t wait for the meetings to come!
Wednesday, October 25, 2023
Open Alliance: Weeks of the 9th and 16th
Weeks of the 9th and 16th
We’ve been super busy these past few weeks. So busy in fact that I wasn’t able to post last week! Therefore, this post will contain two weeks in one.
Bordie Charged
The weekend of the 14th we had an absolute blast hosting our 3rd annual Bordie Blast offseason event! We were ecstatic to host 27 FRC teams with 32 robots in all. We hope all FRC teams who participated in the event had a great time, and we’re looking forward to hosting our 4th Bordie Blast in 2024!
We were so proud of our media team which managed to produce the event’s recap video in less than 48 hours. Check it out here if you haven’t already seen it!
Bordie Charged was the first offseason event we have participated in this year. We were super happy with both the performance of our competition robot Crane (Captain of the Finalist Alliance) and our practice robot Hummingbonk. We’re also planning to attend Girls Gen hosted by Team 2046 Bear Metal this weekend 10/21-10/22 and Block Party 10/28-10/29 hosted by Team 2910 Jack in the Bot.
If you attended or watched Bordie Charged this year, we would really appreciate if you would take the time to complete this survey! All the questions are optional. The feedback will help us plan an excellent Boride Blast 2024!
Wrist Woes
Unfortunately, our wrist was damaged during Bordie Charged. Several of the polycarbonate plates connecting the wrist to the arm were cracked and had to be replaced. We used our OMIO CNC machine to cut the replacement plates.
Fortunately, this meant we had the pleasure of experiencing that sweet sweet sound of peeling polycarbonate protective plastic. We even recorded the sound for this OA post.
New Motor Purchasing
The Kraken X60 and Neo Vortex drops spurred our team to excitement
the last two weeks. We’ve spent a long time discussing new motor
purchases and have just come to a decision recently. We ended up
deciding to purchase only 10 Kraken X60 motors. We poured over the motor
data for the Kraken, Vortex, Falcon 500, and original Neo brushless
motors, and found that the Kraken’s performance was pretty much
unmatched.
While our interest has been piqued by the Vortex’s interchangeable shaft
system, we believe it’s best to wait a year to see how this feature is
really used in competition and how useful it ends up being. As such,
we’re only purchasing the Kraken motors at this point. Our plan is to
use the Kraken motors as propulsion motors for our swerve drive, and use
Neo motors as the steering motors. We purchased 10 Neo motors prior to
the new motor releases, so we believe it’s a good idea to use those
rather than purchase additional motors.
The final analysis slide of a FRC motor comparison PowerPoint presented to our leadership team
That’s all the highlights from the past two weeks! See you next week for another OA post!