FRC 95 The Grasshoppers 2023 Build Thread

Hi @joemost,
This year we are using ROS + a Jetson on our robot for a couple things. The primary use is for
LiDAR but we may also plug in other cameras, who knows. But the purpose of the web interface is to display all the data coming from our ROS nodes on a fancy web page instead of having to SSH into the Jetson and view via RVIZ.

The interface itself is just a React app using roslib to connect to web socket setup by rosbridge.
What you see in that picture James sent before was some AprilTag detection running on ROS and then sent via the websocket to the webpage.

The idea was to have a nice interface to see all of the LiDAR data coming through and maybe have a top down view of where the robot is on the field.

You can see all of our ROS stuff here: GitHub - first95/95_ros: ROS Code for team 95.
Not much right now but hopefully there is more to come.


Mk1 production released! By a wide margin this is the earliest we have had a robot design hashed out.

We are going to be using carbon fiber tubes for the first time on a competition robot in our effort to keep CG and arm inertia low.

For now we have chain-drive for the shoulder and virtual 4-bar but may be looking to make those capstan drives in the future for additional weight savings and learning. @JWC_95 will make a post going into some of the shoulder design details once he has a chance to sleep.

A few random updates:
@Justin_Foss the geko-type tape did a few degrees better for the cone (didn’t test cube) than the drawer liner.

Pasta Pincher/Pasta Roller confirmatory prototype looks good. It’s 1:1 on a CIM with 1.5in c2c axle spacing with one roller wrapped in drawer liner. Seems capable of collecting cone flanges at reasonable angles even with just a 1/4-assed effort.

Special shout-out to 9016, Syosset’s rookie FRC team. We had a nice Zoom call with them this evening. They are an ambitious team moving from FTC to FRC and have a running swerve chassis already!


As James mentioned, I did most of the work on the arm assembly in Onshape. Some design requirements that I considered heavily were Lightness, ease of replacement of parts, and rigidity. James and I went through several iterations of the linkage between the moving arm and the support structure. We considered using Max spline as what the arm rotates on but it was heavy, and we were concerned it couldn’t handle the torque forces on the arm (~40 ft-lbs stationary with a very crude calculation). We settled with thunderhex shaft because we have worked a lot with it, and we could use 10-32 bolts to translate the torque directly from the sprocket to the arm(in purple). All of the carbon fiber spars are 1.125*1.125" and use scab plates (green) and nylon spacers to ensure the carbon fiber can be easily replaced and to ensure that the carbon fiber is under uniform stress(more in previous posts). This does add some weight, but the benefits of efficient replacement outweigh the harms of a slightly higher center of gravity. We are using #25 chain to interface with the sprockets, but the chain will be connected to wire rope for most of the long wire runs between the main sprocket(purple) and on the virtual four-bar linkage (VFB RED). I had to revise my support structure carbon fiber (also red) to ensure the VFB chain could clear the carbon fiber tube when the arm is fully retracted. We are mounting two motors as close to the floor as possible to lower CG and to have a redundant mechanism driving both arms (through the thunderhex shaft) if one motor decides not to work. Feel free to ask questions, as I’m sure this post is unclear, and there is plenty more that went into the design. the arm assembly (not including the gripper) is ~12 lbs, which is pretty light if you ask me.


I knew 95 would find a way to make this game look simple! I love the blue bent sheet metal hard stops - creative way to fit those in there.

I’m curious about your dead axle setup on the pivot joint - if the thunderhex isn’t spinning couldn’t it be bolted to the uprights rather than in a bearing hole? Also is there concern about the thunderhex bending on an impact?

MAX Spline setups also have the ability to transfer torque through the bolt pattern in their sprockets or MAXhubs. Tons of info as to how you can transfer torque with them in their build guide: REV ION Build System - ION BUILD SYSTEM


The hex shaft is only carrying the synchronizing torque (e.g. whatever the lag is between the left and right sides) between the two sides of the arm, not the full lifting torque.

We did model out (most of) a MAXSpline shoulder joint. It solved some packaging issues (the wild v4b bracket being a big one) but our hex shaft design wound up lighter overall. Since this shoulder joint is ~4ft in the air it seemed worth shaving a couple pounds off of it.


@Justin_Foss had an excellent request - what are the different mechanism configurations for doing the stuff?

Starting configuration

Tipped cone acquisition (looks like I may need to fuss with roller height a little more), rollers counter-spinning

Cone handoff, run rollers counter-out to spit out cone

Cube scoring

Cube ground intake, both rollers spinning in same direction

Cube handoff ish, both rollers running to scoot squishy cube out (may have some as-yet-not-designed static pincher kind of springs to hold the cube in case the intake roller is over-driven)

Cube scoring

Thanks for coming to my TED talk.



Our primary sheet sponsor is absolutely slammed and likely won’t be able to make sheet parts for us for ~3 weeks. A lifetime in build season. So we are going to rework our existing model to work with flat sheet metal than another sponsor can plasma cut, 3D printed parts, potentially weldments, and other parts we can cut on available cnc routers.

This has me seriously stressed, but I think we can pull it off.


Sending good vibes. Been there.


Currently going through this struggle but with our milling machinist. Keep your head up!


A tip we picked up from 3538 and are still playing with lightly. Robojackets used a vice sheet metal break like this for their entire robot. not sure what thicknesses/length it maxes out at, but we have done 1/8". @Allison_K could tell you more.


Thanks! We have a 4in version of something like that for quick parts in the pit.

Our home school has a variety of sheet forming tools that we will likely be dusting off, including a decent press brake and 4’ pan and box brake (as well as dusting off our bending skills). Sadly, nothing we have can beat the ±.0015in laser and CNC press brake from our sponsor!


@Rufus_t_Doofus, let’s talk about linear mechanism binding!

I derived this equation for estimating the likelihood of binding a linear mechanism.

A way to reconfigure this free body diagram to be more applicable to this year’s likely mechanism is as a laterally-extending telescope mechanism. It may be the case that a and b change as a mechanism is deployed, so you should use the smallest b and largest a values to be conservative.

The conclusions are intuitive:

  • As the eccentricity of the load increases (a) the chance of binding increases
  • As the wheelbase of the linear device increases (b) the chance of binding decreases
  • A the coefficient of friction increases (µf) the chance of binding increases

How does this inform mechanism choices in FRC? In bearing selection of course!

A plain bearing, like Igus Drylin from the KoP makes a great example: best-case we’re looking at a coefficient of friction of 0.05-0.12.

The coefficient of friction iglide®

Ball bearings/roller contact bearings also have an ‘effective coefficient of friction’ that is well understood. There are numerous sources for these numbers, the first one I found through google is here.

While 0.05 is impressive for a plain material contact pair, it is more than an order of magnitude higher than the effective coefficient of a ball bearing. To move the earlier equation around:


As the bearing friction decreases we can support a larger eccentric load and/or reduce the base of support without binding.

If you have a linear mechanism it is worth running your configuration through this quick calculation to see if it is likely to bind. For our intake we have a bearing spacing (center-to-center) of 4.5in=b and a total intake reach past the bearing center of ~16.5in=a. So we get:

4.5/(2*16.5) = 0.13 = µf likely to cause binding

So we would be REALLY close to binding if we used plain bearings with a µf of 0.05-0.12, but super comfortable with a roller contact bearing with an effective µf of 0.002. Looking at the factor of safety:

0.13/0.12 = 1.08
0.13/0.05 = 2.6
0.13/0.002 = 65 for the win


Our minor disaster recovery plan:

  • Route and attempt to bend our own chassis parts immediately
  • @Ty_Tremblay and Red Hawk Robotics 2713 sent our parts to their sheet sponsor, Churchill Corp, and they are making a set as quickly as they can. This set will be backups or immediate replacements if we totally muck up bending. We can’t think you gals/guys enough!

Scatter-brained update time!

We added slot features to our made-at-home sheet parts. This helps the bends to form where we want them and we chose this because we do not have CNC press brakes to work with, just a ratty pan and box brake. But it got the job done.

The intake redesign to avoid sheet parts (oof) relies on the MAXPlanetary gearbox structurally. I think it’ll be fine, they are stout.

I’m printing more parts because, of course, our print farm order is delayed.

Chassis assembly just kinda winked into existence. Packaging looks good, just like CAD said it would. We mounted the compressor a little differently than CAD and it does boop the slide a little, but nothing we can’t fix.

We still have some redesign work to do on the superstructure to build it a little differently, but I think we’re in good shape right now to release those parts for fab on Monday.

Gotta plead mea culpa on one thing though: I futzed one of the fitup sketches and we all missed it at review time. The rails interfered with the swerve modules just a smidge. A few minutes with a bandsaw and jigsaw had us back in operation, luckily.


What kind of metal do you use for your bending?

5052 H32 aluminum. I find it machines pretty well and is highly resistant to cracking during bending. It is a pretty common sheet/bending alloy in industry.


Welp, first day lost to snow this year.

@StephenWitwick and @JWC_95 improved CAD models and we released a bunch of printed parts for manufacture.

I have spent a bunch of time lately getting my router running better and ran some parts from scrap sheet I had kicking around.

Fusion 360’s arrange feature lets me sketch out my random scrap shapes and nest parts into these weird shapes efficiently. I’m a huge fan.

We made a pretty weird looking 3DP insert that gets used in almost every tube junction. We’re going to test hot glue, a technique used by @Cory_Walters on 2767 that aligns with our goals of reparability.


Let’s talk about how to make good OA content.

I have been writing open build threads since 2014 and sharing open content before that. I’ve developed my own style over the years and have opinions about what works and what does not work for OA/build thread content. I think it would be useful to share some of my thoughts as the OA sees explosive growth.

OA posting is technical writing. Sure, the environment is much less formal than academia, but the same basic rules of technical writing apply.

  1. You suck at technical writing. Paraphrased from my Dad and Mom. Technical writing is hard, basically untaught before college, and from evidence available to me it is often poorly taught in college. You will have to work hard to be good at it.

  2. Be concise. Paragraphs should be four sentences or shorter. No run-on sentences. Long blocks of text are rarely engaging, and people will ask for more detail in the areas of their interest.

  3. Don’t waste time writing about what you see. Take pictures and video (or make other visual content) and share those instead. Provide bullet notes on what you see. Your audience can, and will, notice things your whole team missed. Sometimes these insights are critical.

  4. Acknowledge that you have your own biases, even if it’s just to yourself. We are all biased. “I like using virtual 4-bars” or “colson wheels have served us well in the past” are the type of phrases I like to use and see in OA posts to acknowledge these biases.

  5. Share failures, but be positive and not whiny. E.g. a 2018 video where our elevator assembly experienced rapid unplanned disassembly during testing was quite popular. Seeing a team explode things during testing, do a failure analysis, and implement a solution is a REALLY helpful process to share. Some of the best feedback I have received from a build thread has been about sharing our failures.

Now that I’ve made an OA post that breaks many of the rules I suggest…

  1. Understand the rules so you know when to break them. No, not like the game rules, that’s not okay. Breaking the rules such as ‘I try to never have posts that are all text,’ but ‘this post doesn’t really benefit from graphics, so, I’m skipping it’ kind of breaking the rules.

Good luck, and be open!


Huge fan of Fusion’s nesting feature. Enjoy seeing the once odd shaped material can be saved.

Am I crazy…I don’t think I saw this feature before.