FRC125 - The NUTRONs, 2024 Code and CAD Release

Hey Everyone!

We’re happy to finally release our code and CAD databases for the 2024 season for our robot, MOMENTUM.

Here are some of the relevant links:

We wanted to highlight a few areas we felt we provided some unique solutions to Crescendo below:

1.* One button shooting:

  • Revs shooter to RPM using an interpolating tree map which shoots at a slower speed up close and at max speed after 10 ft
  • Interpolating tree map of distance to hood angles found through testing
  • Fuses odometry from LL MegaTag2 with PhotonVision. Incorporate heading from PhotonVision only
  • Aims drivetrain angle and waits until robot odom is stationary and then shoots
  • Effectively allowing driver to hold down shoot while driving and robot shoots when joystick is released
    • Pass Shot: changes rpm depending on distance allowing for the note to consistently land in the same spot from anywhere on the field
    • Note detection: Robot automatically aligns robot-relative side to side while keeping control over forward and back
    • New for the offseason - Demo Mode: Kids can hold the stick with an april tag and the note lands on top
    • LEDStrip class: Has lights depending on note location but also shows blue light in the middle when Limelight sees an april tag, allowing for faster debugging. Rainbow animation after trapping for funsies

Robot Design & Integration

  1. Intake/Note Path - MOMENTUM featured a dual ground intake on the front/back of our robot. The magic of this system was that the Note always ended up in the same position in the robot after being acquired which meant the Drivers did not need to think beyond pressing the intake button and driving into a Note with either side.

The Intake also allowed us to pass the Note to our Amp and Trap scoring mechanism. This was done via a series of rollers, and a specific set dubbed the “Triforce”. The Triforce allowed us to dynamically switch the Note destination based on high level Driver inputs, such as “Amp Score”.

Note tracking in the Intake/Note Path was accomplished via 3 IR proximity sensors. Two of these were featured in the Shooter and required both of them to be TRUE to be “In Shooter”. This allowed us to use the Shooter as part of the Intake/Note Path.

The dynamics and mechanics of this path allowed for many possibilities. As part of the HW/SW integration, a state table was developed for the SW team to appropriately set roller directions based on desired Note destination.

  1. Tramper - We landed early in the season on our general concept which got us to a place where a Note could be handed to a secondary mechanism to score in the Amp and Trap. This mechanism was dubbed “The Tramper”.

The Tramper required far more iteration than we ever could have imagined when first conceived. At it’s core, its a very simple mechanism - fixed rollers on a single extending stage with a single proximity sensor. However, as we progressed we found that getting the Note to reliably pass up to these extending Rollers was a big challenge.

Additionally, we (among many many other teams) discovered how challenging it was to get a Note to fall into the Trap. The linear extension was accomplished via a printed rack/pinion setup with telescoping aluminum box tubing. This was a similar setup to our Ground Intake from 2023. We are very happy with this type of mechanism, and it is likely apart of our core design DNA moving forward. The issue of course was not getting the Note to the Trap, but getting the Note INTO the Trap.

Our original mechanism was similar to others, with a curved hood guiding the Note “up and over” and into the Amp/Trap. You can see an image of an earlier version below. Ultimately this was too slow and finnicky for our liking, so we redesign the Tramp to flip the Note up and then back down. The logic for this was basically “why bend the Note 300 degrees when we could simply bring it up straight, flip its direction and only need to bend it 30”. Ultimately this was a great choice for us and we encountered no issues at events with Notes not dropping into the Trap (assuming we were up and scoring).

  1. Shooter - The Shooter for our 2024 Robot came to being after extensive prototyping. It was a highly integrated mechanism that did triple duty as the Launching mechanism, the Shoulder/Articulation for aiming and as the Feeding mechanism for Notes into the Launcher.

Early in our architecture phase, we hypothesized about a blackbox mechanism dubbed “The Briefcase”. The fundamental functions of this briefcase were all as defined above. It was a pretty big bet that we could pack these functions into a small mechanism - however if we could accomplish this, we had an overall robot architecture that we really liked.

Our most obvious concern was that we could not score consistently from distance (our requirement was 95+% from the Wing line). We needed to answer the question of “do we have an architecture” by proving we could score consistently with a Box that was 16" wide by 16" long :slight_smile: . This required 3 full iterations of prototypes over the course of the first week of the season. We landed on a prototype that showed a lot of promise (video below).

The Shooter used similar fundamentals to a lot of other really good robots. Stealth wheels, separate left/right drives to add spin (we found a 35% delta to be the sweet spot for us), mechanically linked Top/Bottom wheels, UHMW tape EVERYWHERE. Our mechanism also then incorporated the motor + drive system for the shoulder joint to aim, and the motor + drive system to operate 2 opposingly driven Feeding rollers.

The Shooter underwent 2.5 “Final” iterations. Rev 2.5 was a further weight reduction of printed parts and plates.

Final Shooter Rev 1:

Final Shooter Rev 2:

  1. Climber - The last piece of our architecture to click into place was the Climbing mechanism. We had figured out how to score in the Trap, and left ourselves a lot of space, but we still needed to integrate the mechanism that would pull us up to the appropriate height.

The climbing mechanisms for Trapping this year were sneaky hard. You more or less had to get the climbing chain down to the top of your bumpers. We considered articulating arms similar to 254/1323. We considered a linear slide mechanism similar to Spectrum. Ultimately we landed on a fairly unique solution of using a hook on a chain.

The benefits to this were pretty obvious, no telescoping mechanisms, no linear bearings, very few moving parts. The challenges were to try and eliminate the sideloading that could easily snap the chain. I highlighted this part of the challenge in this post in our Reveal thread.

We were happy with the performance in our shop and practice field. Our Drivers had mastered the ability to start next to the Stage, go retrieve a Note from the Source and get back to the Stage and Trapped in 15 seconds. However, as the season progressed we dropped a couple of RP due to chain failures. The combination of the way the hooks were mounted and the 25 chain would produce fairly sporadic failures that were easily fixed, but ultimately too costly.

Pre DCMP implementation

DCMP/CMP Implementation

For DCMP and CMP we switched to #35 chain, and changed the Hook attachment method to one that was in line with the chain link axis. This was bulletproof and we rode our Trap reliability to the #1 seed in Ganson at NE DCMP.

MOMENTUM was one of the most technically challenging, well designed and best integrated Robots I have been apart of in my time in FRC. The NUTRONs student Design team went to another level in 2024 and we’re really looking forward to carrying that momentum forward into 2025.

Feel free to fire any questions at us here in this thread and we’ll be happy to discuss!!



I’m looking through the Gitlab and I can’t seem to find any documentation relating to this. My team has always wanted to make LEDs work but we never knew actually how to code them. Do you have the repository for them somewhere and the actual light strip you used?

Also, what program do you use to design your pit banners and where do you order them from?

(P.S. I wear the hat you gave me at DCMP like every day so thanks for that lol)

WPILib will ship with an LED animation API for next season. It’s intended to be used with WS2812B LEDs, but a CANDdle should be compatible if it supports addressable LED outputs (however, you may need to create your own buffer to support readback for combined patterns like masks and blends)

Here’s the PR that adds it, there are a few code samples and gifs in the description. I’d link the docs but I haven’t finished writing them yet :slight_smile:


How did you do this?

How did you do this? Did you have a fixed shooter angle and vary the speed or vary both? For either of these options, how did you computer the angle/speed? Did you use linear interpolation or some more complicated method?


Better question is why


Because it looks cool


It’s a lot simpler actually.
It shoots at a fixed RPM
Shooter angle directly correlates to the limelight April tag ty plus an angle offset.


The Nutrons always have some stellar 3D printed parts on your robots. Can you talk about your printing setup / workflow for these as well as anything that may not be obvious from the CAD model? (materials, print settings, iterations)

And possibly this chain tensioning assembly?


Amazing robot as always!

Is this part 3d printed? What is the purpose of the extra holes in the back?

Can you describe these bumper mounts, what components are in this “head”?

How does this part work? I assume it is part of the bumper mount to prevent sliding and rotation.

Do you plan on releasing CAD for years prior to 2023?

Thank you!

1 Like

Yes this part was printed out of Bambu PAHT CF. The extra holes were to potentially accommodate a mount for a powered side roller that we ended up deciding not to pursue.

Those parts are printed out of Onyx and have a 1/4"-20 bolt that goes through into the wood to secure them and give them a good amount of strength.

The bumpers halves latch to each other, and after they are locked they generally are not moving- however that nub guarantees bumper height and prevents any rotation, as you mentioned.


How did the Onyx herringbone pivot and rack and pinion hold up over the course of the season? Did you ever have to replace any of those parts? Also any chance you printed those on a Bambu instead of a Markforge?



We did not have any issues with the pivot rotational gears this season. We did not need to replace either the smaller(driving) gear or the sector gear on either side. It’s worth noting, that the smaller gear utilized WCP 3DP inserts to ensure the hex would not strip out over time.

That is something we have seen over the years, particularly with Onyx parts. You could build a system and have great results for a while, but overtime the softness and relative lack of stiffness of the Onyx material will eventually strip out.

We did not try these particular parts on a Bambu - but I’m very confident these parts as is printed in a PLA+/Pro/etc or PAHT CF would function the same, for the entire season. Our Tramp extension system utilized a rack and pinion setup, and those racks were PLA or Onyx at various points in the season as we made adjustments with no issues on the rack. The pinions in that case would have benefited from a 3DP insert as we did see a couple instances of stripped pinion when the Tramp mech extended into the Stage.

1 Like

Thanks for details. Not very familiar with Onyx, but since it’s nylon it’s likely prone to creep over time which might be part of the issue. I’m very impressed that everything seemed to hold up over your particular competition season, makes me hopeful that we’d find similar success in our efforts to include more sophisticated 3D printed parts.

Yes all plastics will creep to some degree, but in these applications where the directional change is rapid and frequent, I suspect it’s really just straight up material deformation. Onyx itself is really not all that stiff, equivalent PLA parts are much stiffer on their own. However, the Onyx parts are very tough and ultimate yield is notably higher. The beauty of some of the really wild Markforged parts is with the carbon fiber/kevlar inlay where you get those benefits of the Onyx but then are able to greatly stiffen the part with the inlay.

1 Like

small and stupid question, why gitlab?

Because GitHub is a for-profit Microsoft owned company that steals all of your information and code?

1 Like

I love the skillful utilization of 3D printed parts on 125’s robot this year, but I was curious about your sector gear. I’m eager to explore a similar sector gear for an off-season bot, and I was curious about how you generated it and determined the correct angle for it.

The sector gear size, angle, position, etc is all a function of the overall robot architecture. From our experience we knew we wanted that gear to be at least 10DP in size (potentially even larger). The speed/torque calcs to determine its movement led us to a place that we would drive the final stage on the sector gear 10:1, so we used those as inputs to the overall robot design.

As we worked on detailing this Shooter design we were simultaneously working on the overall robot architecture around the Shooter.

This gave us a set of fixed constraints around Shooter + Intake that we then tried to position in the overall robot assembly.

This is where the really marriage of the Shooter and Rotation system for the Shooter meet the actual implementation details for the Frame and rest of robot. This gives us the overall Leader Assembly with key dimensions and axis points locked in. We then take that information and create a separate Leader assembly for the Rotation system.

That now gives us all the large chunks we need on the Robot and Frame side to mount and integrate the Shooter. The last piece was then just detailing out the rest of the Rotation gearbox design as that piece integrated to the rest of the Shooter itself.

Which at this point basically brought us full circle back to the initial sketch around how we could rotate the Shooter to begin with. Once we had all the details hashed out, the very last step was to take the dummy cylinder model (with diameter represented as pitch diameter of the sector gear) and make the actual sector gear.

To do that we use the gear gen solidworks file we built to generate the gear, cut off the sector we need referencing the dummy cylinder, and then go and drop that part into the actual Rotation Assembly in CAD.

Hope that helps explains how we did it!