Team 6672: Fusion Corps 2023 CAD and Code Release

Team 6672 is proud to present our CAD and code for our 2023 robot TARS.


The CAD is slightly messy (as usual) so this is how we try to organize the document. As each subsystem goes through its design process, new versions are made and named using titles like Arm 1.0. Versions with a .5 are designs that never hit production. Along the same lines, versions with a .0 did hit production. Some of these CAD models are not exactly what we have in real life however the main assembly “TARS” is the closest thing to real life. You will also find old versions of TARS called “Robor” which is not a typo… well it was at one point but we have embraced it now.

Our intake took inspiration from 3847’s and 8177’s Chief Delphi threads. Thank you for providing awesome resources to the FIRST community!

In the next two weeks we hope to release a whitepaper going into more detail on things we found while designing and building this robot.

Here is a list of materials used to make the robot and where we got them: TARS BOM. I left out things like Motors, wires and raw materials like sheets of steel or poly since those are hard to source and people have preferences on suppliers. We did have a limelight on TARS but it was never used so I didn’t add it to the list. I hope I got everything, but I may have missed a couple of items.

Since we do not have much documentation on our robot to share with you right now, if you have any questions feel free to email us at [email protected]

We are also releasing our code: GitHub - FusionCorps/2023-Ignition
Here are some bullet points about the code from our lead programmer Andrew Oliver (@CrazyMetic):
• Custom swerve code built-on from 2022, with features such as wheel optimization and a closed loop ramp limit to prevent wheel slip during driving. Also comes with a custom odometry class, though we ended up using the WPILib one instead.
• Arm control via setpoint that uses an algorithm to move through the robot safely without needing to implement inverse kinematics and path generation. Motion magic control on the pivot motors prevents excess lash.
• Autonomous driven by PathPlanner (Thanks 3015!), with steps allowing us to modify paths separately on each side of the field.
• Single driver setup keeps control focused and simple.


We’re glad our thread could help! :orange_heart:

1 Like

This is one of my favorite robots this year by a landslide. Impeccably simple (I’m still reeling over the fact that your entire BOM is <60 items!?!?) and beautifully elegant, hats off to ya’ll.

I’m curious what kind of camera you guys use opposite the limelight at the top of the superstructure? Is it just for drivers or more to it?

1 Like

Its a logitech webcam (I think its this one on amazon). Our driver never used it but it was meant for him to see whatever he was trying to intake. No special game piece detection or anything though.

Is TARS a Interstellar reference?

Yes, In the early stages of CAD we noticed that it looked very similar to TARS in Interstellar so we decided to name it that.

1 Like

Are the gear ratios in the max gearboxes accurate in cad to what they are in real life?

No. The exact gear ratios can be found in the Constants file in our code.

If I recall correctly, we switched out the wrist gearboxes from 2 5:1 stages and 1 4:1 stage for a total of 100:1 to 3 3:1 stages in addition to an additional 2:1 reduction via sprocket for a total of 54:1 to increase the speed of the wrist while also reducing lash introduced via the MAXPlanetaries.

I’m not as sure for the arm base, but I do know we definitely decreased the gearing at some point in order to speed the arm up.

If you want to confirm any of the ratios, I would just cross reference the CAD with the code’s constants, since I know those are up to date.


Wow very compact design but

I saw some transparent parts (for example this swerve guard) that are somehow bended. Are these parts made out of polycarbonate or PLA/ABS etc.

bending polycarb isn’t difficult, all it takes is a heatgun and some patience

1 Like

Just cold bend :sunglasses:


yes it is not difficult to bend polycarb but it becomes more fragile. Isnt that something we want to avoid?

1 Like

Poly is pretty resilient even if it has been bent. These parts are meant to absorb collisions from the arm going astray (due to getting hit or a malfunction) so even if they broke they would have done their job to an extent. We had many hits to them from external robots and they never broke.

How have you guys seen that intake work out for you with cubes? Have you seen any problems with dropping pieces? I see most teams have a wide part and a skinny part like the everybot intake but you have just the skinny on the end. You also have one of the rollers with a tube and the other with the Churro shaft. How do you choose this design vs other designs?

Overall, we were very pleased with the performance of our intake. The one-slot design started by us trying to experiment with a 3847-style intake that pulls the cubes through the two rollers but we made the compression too high and the cube wouldn’t go through.

Since this was actually holding the cube in place very well, we decided to stick with it for the rest of the season, and the rest is history. We run the intake motor at low current while holding a cube, so it gets compressed slightly and generates more friction in order to not fall from our intake.

For the most part, we don’t have any issues intaking cubes, though this design makes it imperative for us to keep the rollers clean. We wipe them down with Simple Green cleaning solution before every match. In addition, over-inflated cubes are harder to intake than less inflated ones, but we didn’t see this pose issues for us that much this season.

The Churro shaft roller is needed for us to be able to pick up cones from the ground, as a larger roller would not be able to get underneath the tip of the cones.

For more info on how our intake works, check out our Behind the Bumpers. Our intake geometry hasn’t changed since week one, so all the info should still be accurate.


Did you ever try making the small shaft a dead shaft(only the bigger roller moves). If so what results did you see?

No, we only did live rollers for both. Since the Cone and the tubing on the rollers have a large amount of friction you probably wouldn’t be able to intake a cone with a stationary bottom roller (a cube would probably be just fine with that type of intake though). Also the floor pickup geometry only works out where the bottom roller makes contact with cones before the top roller and therefore needs to be live.

The only gearbox that was incorrect was the one at the top of the robot (Forearm Gearbox). I have changed it. All gearboxes in the CAD are now the same as they are in real life. Thanks for reminding me to check that!

Loved your guys robot this year! Was wondering a couple of things about your robot. Did you use MAXtube for you drivetrain and if so what was your experience with it was? For your bicep joint did you run a hex shaft through the whole MAXspline? Did you only use the MAXspline endcaps to connect the shaft to the MAXspline? Did you only use the falcon encoders for arm postion and if so how did you home the arm? Thanks so much!

We did use MAXTube for our drivetrain. We did suffer one severe impact that caused the tube to begin to “unzip” during DCMP (Q50 impact with 7540, their corner bumper hit the exposed metal) but we were able to repair it with the ten-match turnaround. @rjack probably could tell you more about both our drivetrain and how we rigged our bicep joint.

For the arm position, we only used the Falcon encoders and reset them at the start of every match. We wanted to add some REV Through-Bore Encoders in order to get absolute position readings, but the wiring was too complex for little added benefit. Our amazing drive team did a great job of making sure the arm started the match in the same position every time, although we did see some minor issues with that at Waco. Once we figured out a system for setting up the robot before each match, homing the arm ceased to be an issue for us. We tried to make sure that the RIO never completed its boot cycle while the robot was in transit so that it didn’t register an arm position that was slightly off.

1 Like