Citrus Circuits 2020 and 2021 Code and CAD Release

Besides , can you introduce your auto? How do you accomplish such an amazing autonomous project? And how do you draw your trajectory?
Thanks for replying!



Slid out the back, CAD is missing the cutout in the bumpers.

Thanks for all the questions y’all, keep them coming! The students will be getting to y’all shortly


Thank you for releasing this information. I learned a lot, and had a lot of fun, looking through all of the CAD. I really appreciate your willingness to share your designs. After looking through the CAD for the 2020 and 2021 robots I had some questions:

  1. Why did you switch to polycord for intake power transfer on the 2021 robot? Did you do anything special to prevent slipping?
  2. How does the 2020 climber rotate upwards? I assume those 1x1 bars that pivot from the telescoping tube play some role, but cannot figure out what/how
  3. How, and out of what material did you manufacture the wheel guards on the 2021 robot? Did they break during competition?
  4. Were there issues caused by relying on the flanges of the bearings to resist side loads on the 2020 climber? if there were, did they cause the switch to bearings on all faces in 2021?
  5. In 2020 you used a standard bellypan/electronics setup, but in 2021 the bellypan is on top of the frame and the electronics are mounted upside down. Do you have a preference for one setup, or is it decided based on the specific robot’s packaging?

We purchased the rough top tiny tank treads from FN Sheppard:

The belt P/N is: TUS375H200VAC
Description: US 375H200-V Self Tracking w/ Blue Nitrile Ruff-Top Cover

Lead time was 4 weeks. FN Sheppard is great! We also use them for the belts on our cleaning robots at my old work.




Just curious, is there a way to see the part studios/sketches? Was looking forward to looking at the master sketches/design process.

Thanks for the release!

The intake actuation is really interesting to me. It looks like you’re only powering the intake deployment, but there’s nothing constraining the rotation of the roller plates (?). This seems like it would help if you drive into a wall or something, but how do you keep the rollers in a position where you can intake balls? Does it just tend towards the extended position by gravity or angular momentum of the rollers?

l see that you use feedforward in your swerve. How do you use the characterization tool to calculate the ks , kv , ka with a swerve drive. Can you explain the main steps ?

Iirc in real life there were some cords between the top of the intake arms and the superstructure. Similar to 973’s cords, I think?


Great question, here is an answer from our 10th grade design student Brendan, who designed the turret, but doesn’t have a CD account :slight_smile:

The range of motion on the turret is ~235 degrees, and the ma3 encoder tracks for the entire travel. We have the encoder set up to a 28.4:1 ratio relative to the motor, whereas the turret rotates on a 27.8:1 relative ratio to the motor, so for the full movement of the turret, the encoder shaft only rotates ~230 degrees.


Surgical tubing, ziptied through the two holes below the top roller.


Really like your bash guards on your swerves wheels. How did you like them and how did you make them?


Great question! Design and software tasks for each of the robots are all delegated to groups per each robot, with some intermediate guidance from more experienced subteam members who are involved with the development process for multiple robots.

From a software perspective, separate groups are defined for subsystem code writing and bring-up, whereas the writing process for areas like vision tracking and superstructure for interdependent subsystems are guided by more experienced members. Usually, a veteran member leads the writing / bring-up process to properly delegate remaining tasks by skill level and priority.

On the design end, the process varied slightly for each of these robots, depending on how many were being put together simultaneously. Both our 2020 competition robot and our mk2 robot were created by splitting up veteran members to each lead the design of a single mechanism, meanwhile, new members were given the opportunity to work on smaller complex parts and systems such as 3D-printed electronics mounts, large pieces of bent sheet metal/polycarb, or even a system such as the control panel mechanism in 2020. The essence of this process has remained fairly consistent through our following projects, though we did split up our subteam into two groups for both the 2021 build season and offseason robots we made, which each underwent a similar process as described above to divide up work among group members.
As for the process of designing the 2910 and 4414 clones in the 2021 offseason, we took direct inspiration from 2910’s CAD release when redesigning many aspects of their robot, while the 4414 clone design team worked primarily off of videos and images of their robot for the redesign, since 4414’s CAD had not been made publicly available. Nonetheless, both robots still underwent a complete redesign.

Throughout the process of creating these six robots, we’ve found how vital clear and constant communication is, not only within subteams but between them. By keeping all communication transparent in our subteam Slack channels and “robot status” channel, mentors and veteran members can contribute across groups with questions/comments/concerns to provide further guidance along the way, and group leads can check-in with questions for mentors or leads from other subteams working on the same robot.

Please let us know if you have any other questions!


We printed all the wheel guards on our Markforged printers. We went through a couple iterations of the design on these after encountering some issues that we ended up fixing leading up to MTTD. The first image is our previous version (which we took to Chezy), second is the final (which we took to MadTown).

The first issue we found was that the hole clearance on the first iteration was too tight to remove the wheels, which made it tedious to replace tread when it wore out. There were also a few other issues we found when we started driving. The cone-shaped chamfer often broke when driving over the steel bars at the rendezvous point, and the bolts we used to mount these to the drivetrain rails were previously the same bolts that held the modules on, so when the guards would break it meant the modules weren’t strongly constrained to the rails.

For our final version, we increased the diameter of the hole for wheel removal, and we made some of the mounting holes large enough to fully clear a socket-head bolt. This made it so that we could have four bolts mounting the module directly to the frame and another four mounting the guard to the frame, so that if the guard broke it wouldn’t impact the integrity of the module. Finally, we changed the shape of the chamfer from a cone to the pyramid shape (below) so that we could add some 1/4"-20 flat-heads in to hold the layers together. All of these changes helped us get through MadTown with no broken wheel guards.


Thanks for sharing all of this really appreciate it. I really like your idea of putting bolt all the way through. Really makes it a lot stronger. Did you fell like it helped protect the swerve drive. Also where they 100% infill or what settings did you use for the markforge


Having the bolts all the way through definitely helped keep all of the layers together, preventing the modules from getting damaged. The previous versions left the modules more vulnerable since the bottom layers of them tended to rip off when we hit the rendezvous bars. As for what settings we used, we were able to get away with the default 37% infill and didn’t need to use reinforcement material or adjust any other markforged settings. Every guard was printed at either 0.1mm or 0.125mm layer height depending on when we needed them completed.


That is really good to know. We just got a markforge to trying to figure out what settings to use for parts that will see impacts. Thanks for sharing

Thank you for your questions!

  1. We switched to the polycord for the intake after we had issues with 3D printed pulleys getting shredded by the belts we were using, and to prevent slipping we just made sure that the pulleys had really high flanges so they wouldn’t fall out.
  2. The 2020 climber rotates upwards by tightening spectra cable that’s tied to the pulleys on the hex shaft below the arms, which brings the arms in from their resting position, and also releases the arms out of the larger tubes, and that position gets locked with the latches on the side bars. We can then tighten the polycord further pull the arms in and climb.
  3. Our design lead Zach Hoblit, talked a lot about wheel guards in a different response: Citrus Circuits 2020 and 2021 Code and CAD Release - #22 by zhoblit.
  4. Yep, we experienced issues where the flanges of the bearings would actually pop off during matches, and we ending up actually switching to using bushings for the 2020 robot. Those issues were the reasons we switched to having bearings on all sides yep!
  5. For our team, we try to pick which bellypan to use based off of the robots packaging. In 2020 we tried the normal regular bellypan, but it led to major issues for wiring, so for the 2021 bot we reversed the bellypan to make it easier to access electronics. The main added difficulty with the reversed bellypan is making sure that there are cutouts and holes for routing wires, and making sure that the battery is secure.

like replacing a PDP wedged half under the indexer at LAN 2020. Big fun.


I physically winced being reminded of this moment haha. Big (not) fun!


What was the logic behind having an 8 falcon drive on your 2021 bot - is the robot not traction limited already with 2 falcons?

1 Like