FRC Team 612 2020 Off-Season Project: StealthBot

We are proud to unveil our 2020 off-season project, StealthBot!

StealthBot is a project from several members on FRC Team 612, including myself, @ablfish612, and @EAGLIN, to design an ‘ideal’ robot to compete in the 2020/2021 game Infinite Recharge. It is designed optimally to fit our team’s desired play style, fabrication limits, and goals.

We designed StealthBot using OnShape, and rendered it using Fusion360 and Blender. Check out the video we made for it below!

We made a technical binder showcasing some of our design decisions and reasoning.

StealthBot Tech Binder V2.pdf (1.7 MB)

This was a very fun project for us to do during quarantine, and it taught us a lot about robot design, collaboration, CAD, rendering, and video editing. Wishing you all a successful 2021 season!


May I ask how the climber works?

Edit: also love how professional and smooth the animation looks


The climber functions using a steel tape-driven system and 3D printed custom tubing. It was designed with inspiration from 118’s 2020 robot, and is capable of climbing with only one arm if necessary, although a climb with both is optimal.


On behalf of the 612 members who participated in Rosie Rewind (the design period we had last summer that led to Eaglin, Alex, and Aidan this beautiful CAD model/rendering masterpiece) I’d like to say that we really enjoyed designing this bot. It allowed us to learn a lot more about different techniques and it allowed everyone, not just veterans, to have a say in the design process and to learn from each other.

I’m so excited to see what 2021 brings! Best of luck y’all!

also i helped out with the climb. gotta claim a tiny bit of credit for that lol


We took almost all our pointers for the climber from @Rob_Stehlik’s thread: Steel Tape Drive (for telescoping arm) - General Forum - Chief Delphi

The climber was the main thing that hung us up in our design. We wanted something that was simple and effective. We choose this design because, even though we have little to no experience in steel tape climbers, we felt like it would be something we can more easily prototype and build at home using 3D printed parts, rather than needing a full shop if we went with the more common elevator-style climber that we were debating using.

Also, it was fun to learn about how these things worked, and the knowledge might be useful in the future!


Can I ask about the drive gearing? Is that 9.5 FPS free or adjusted? Can you talk about the process used to pick that gearing? If your typical cycle path is through the trench I would have expected a higher top speed to decrease cycle times.


We had a lot of discussion when it came to choosing our Drivetrain speed. We first decided which gearbox we wanted to use. We did not have a great time with the VEX 3 CIM Ball Shifters this year, and decided to use the WCP Flipped SS for its openness and small size.

The actual speed is 10.7ft/s, the theoretical free speed is 12.1 ft/s (Using ILITE’s calculator). We went with this after talking to the drivers about how they felt the 2020 robot moved. They liked the maneuverability provided by the slow speed (using video we calculated the 2020 bot ran just under 7ft/s in low gear), but would’ve preferred something slightly faster. The drivers also said that the high gear, which was theoretically at 16ft/s (although we never measured IRL) was too fast for them. After watching other examples of robots we wanted to emulate, and calculating their actual cycle speeds from videos, We pinned ~10ft/s as a good number to aim for, and found a ratio that worked with the WCP Gearbox that got close to that number.

Ill update the Tech Sheet to reflect the actual numbers. I think the 9.5ft/s was an older revision of the sheet that didn’t get updated.


This is a great design and a beautiful animation, well done!
It seems like overall you designed to your resources and your goals pretty well. Good job not doing a spindexer, using COTS gearboxes, doing a cots shooter.
However, it seems like you’re drifiting away from your goal of building a simple robot in a few major ways. The first of these being the steel tape climber, which is not particullary simple or tried and true, especially compared to a standard elevator or telescoping tube climber. There’s a ton of extremly succesful teams out there that used simpler designs to great effect, like 1678, 1114, 111(linkage climb not telescoping tube), 148, 6328 etc etc.
Another example of this is a turret, which is certainly not the simplest way to shoot balls accuretly. A shooter with no turret and no hood has been fieleded to great effect by teams like 973.
Another point, your tall vs short analysis completly ignores any mention of simplicity, only implying that a tall robot might need an additional mechanism. In my experience, and I’m sure many others, a tall robot is far more simple and nearly, if not just as effective as a short robot.
I think using a more conventional design will eliminate a ton of the guess work in trying to reproduce what 118 did on limited information.
Lastly, why are you using carbon fiber? It is much harder to machine and just generally use than aluminum.
This project seems like it was a great learning experience for your team, and I can’t wait to see some updates when this gets built!


So many great points all around and thank you for the compliments! I’ll try and answer as many questions as I can, the short VS talk also came down to how much we can push the robot, having such a fast robot it would be a shame to see it tip or waste time balancing the robot during acceleration and deceleration. Especially considering the imbalance occurring when hitting the steel bars on the field, and running under the control panel. As for the carbon fiber that would be my fault for during the render process that was completely an aesthetic choice, I just thought it looked cool for the render and in reality would not hesitate to swap it out for aluminum, polycarbonate, lexan, or wood! I loved the contrast between the black, carbon, orange and wood so those were the color schemes chosen for the bot. For the turret we went back and forth between how much we could push the horizon of the robot and settled that with a turret the list of capabilities of the bot are expanded so far, from previous years running tank and a fixed shooter it was just too time costly to line up in a hurry or to try and shoot while being defended against, on top of that the areas from which we could accurately shoot were reduced. We do agree that it may not be the simplest but again it comes down to a cost benefit analysis. We aren’t trying to make an everybot style robot where it’s the simplest most effective way to run the game rather a realistic edition of a robot that is feasible for most teams. There is still a lot of changes to come on the design and I appreciate the feedback so very much!


Thanks for your thoughts!

One of the hardest parts of this project was trying to draw the line between “Designing for the Field” and “Design for the Team”. While I 100% agree with you that this Robot isn’t perfect for the competition field (for a team of our capability), it is designed for what we wanted to get out of it.

This robot served several purposes:

  1. Be effective on the field,
  2. Teach us a lot if we build it,
  3. Teach us a lot, even if we don’t build it.

I talked about this a bit in our Design Philosophy section. Note that #2 and #3 can (and do) conflict at times, and we had to draw the line between them.

One of the things we realized early on is that designing a dead-simple robot, like an Everybot, WOULD be the best option for us in a competitive sense. But while an Everybot would give us an effective on-field robot, it wouldn’t teach us in the areas of weakness we noticed in our 2020 robot (and team).

That’s why we made some of the decisions we did. We spent several hours arguing whether we needed a turret. I personally didn’t think we should have one, but we decided to add a COTS one because we knew we could buy it and get it working in the (probably non-existent) 2021 season and learn a lot from it. We knew we did not have the knowledge to really design our own turret from scratch, but we felt that buying a COTS turret (+ limelight) would teach us a lot that we could use in 2022 and beyond.

Another thing was the steel tape climber. We actually originally went with a elevator-style climber, but scrapped it after realizing we knew less about the Steel Tape climber, and we also believed a Steel Tape climber could be more realistically made at home using 3D printers and other tools, if we didn’t have access to a shop.

Every mechanism was a trade-off between effective design, a useful learning experiment to design, and ability to realistically build it in 2021. Never could we do all three.

As for the CF and colors, those are just aesthetics. We wanted to expand our rendering and video abilities using Fusion360 and Blender, a niche we hope our team can become known for.

So in the end, if we wanted to design the “Perfect” robot, we could’ve just done a CAD remodel of 2056 or something. But we wanted to be realistic, look at what we could possibly build in 2021, and if nothing else, learn a lot during the design process (which we certainly did).

Here’s to hoping that we can build some of this robot this season!


This bot is breathtaking!

For the renders, how did you guys port fusion 360 to blender? I have a bot design in fusion, and I’m struggling to find a file format that I can use to import into blender.

1 Like

Hey dude! first of all welcome to Chief Delphi, I’m super happy you’re here! so as for the porting from fusion to blender this took me about 1 month of tweaking to perfect to get the maximum quality transition and linked parts to move over in their respective folders but the simplest easiest way to do this would be to export from fusion as a.FBX file which will carry over a lot of the geometry and allow you to do a direct import without any Rhino converters online. so remember to export from fusion as a .FBX and import to Blender as a .FBX. on top of that, there are a lot of modifiers and stuff you need to apply to get “perfect” geometry transition between programs but a .FBX transition should be more than enough for anyone starting out.

1 Like