Team 3467 2023 Build Blog


We decided to use to the REV ION hardware this year because we saw the benefit of using the MAXSpline shaft over a normal piece of hex at the rotation points. A 100: 1 or 125:1, still have to decide, MAXPlanetary drives a 24t sprocket on hex which drives a 48t MAXSpline sprocket fixed to each joint. We repeat this step for the upper joint making it use the same exact hardware. One of the main reasons we decided to use MAXSpline is because of how easily their system was able to be mounted on a ¾” deadaxle tube with a tube nut on each end and be able to easily come on and off the robot as shown here.

Also, when drilling a 1.375” hole into the box tube, the MAXSpline sprocket, plate, and shaft collar can all be clamped together using 6 bolts on the top and bottom section of the pattern when correctly lined up.


As mentioned before We decided to make a prototype of this arm with materials we have in our shop, which were mostly composed of VEX parts. In order to convert this from REV to VEX, we changed the MAXTube to just standard VersaTube. This will incorporate a VersaPlanetary with a similar 100:1 gear reduction. We continued to use a 48t sprocket but unfortunately, we had to a 22t sprocket instead a 24t so our ratio won’t be 100% symmetrical, but to attach them onto the tubing we used VersaBlocks because of the convenient hole patterns they had.

Earlier this week we started manufacturing parts for this proto arm and just today we concluded our assembly of it. In the next coming meetings, we plan to assemble a drivebase along with a prototype claw and make it into our practice robot for programming to use or drive practice for later on when programming has the actual robot.

Fully Assembled Arm Video

Actual Drivebase Update

We also assembled all our swerve modules we will be using this season



Not a full post, but thought I’d share that DoubleJointedArmSim now supports a motorized wrist, with prototype code for all 6 setpoints we plan to use on the arm initially.

This is available on GitHub on the double-with-wrist branch.


Wonderful work Windham Windup!


Thanks James! 95’s thread has been quoted many times as inspiration in our slack. We’re super excited to see your machine at Granite State.

1 Like

I worked a bit more on my simulation yesterday. I decided to extend the SingleJointedArmSim to slightly modify it to work better with the wrist.

  1. Instead of having a boolean for simulating gravity, I changed it to a BooleanSupplier. This is because we plan on having a brake on the arm itself to hold it at its goals.
  2. I added an additional DoubleSupplier for the gravity vector offset (in radians). This allows you to simulate gravity in the wrist simulation and have the gravity vector in the correct direction.

This of course still doesn’t simulate the effects of the wrist position on the forces acting on the arm, but it aligns better with the real world.

Code: SimulatedDoubleJointedArm/ at master · BraedenHunt/SimulatedDoubleJointedArm · GitHub


Week 1 Recap


This week we have almost finished the design of the entire robot excluding some small tweaks and optional modifications. We spent a lot of time over the past week prototyping and Saturday we completed the prototype arm.

The Arm

The Claw

For our claw, we have 2 sets of 4in 30A durometer rollers spaced for optimal compression of the cube and the cone. We are running it using a bag motor going into an UltraPlanetary Gearbox. We will be 3D printing some herringbone gears made of PLA to reverse the direction for the opposite side of the claw. The exact gearing of the UltraPlanetary is TBD.

We’ve decided to incorporate a wrist to the claw to enable primitive ground pickup and extra maneuverability while scoring game elements. We had 2 general designs for a wrist, one using pneumatics and the other using gearing inspired by 7407’s wrist design found in their Open Alliance CAD.

We’ve decided to prioritize building the pneumatic wrist due to its simplicity in the programming. After Week 1, depending on how beneficial we see it to be, we may switch out for a geared wrist to enable some more freedom for the angle of the claw.

The ground pickup functionality from the arm is not ideal but we are hoping to be able to use it in Auto or scoring in the Low Row for week 1.

The Belly Pan

The belly pan this year is your typical belly pan. We considered making a brain pan like last year, but with worries of falling off the charging station, and thus touching the underside of our robot, we didn’t want to damage any electronics. The PDH is centered in the robot (of course) and with the Pigeon and Carnivore right above it. The Carnivore makes CAN much easier considering we would need a lot of CAN wire otherwise. The right side of our robot features the compressor, Talons, and PH, while the left features the RIO and Mini Power Module. We also decided on a horizontal battery as it would make the wiring to the breaker a lot easier. Some electronics not seen are our radio, radio power module and solenoids would all be on the arm and arm mount. A solenoid would be on the arm because it reduces the amount of tubing needed from a normal manifold-solenoid assembly on the belly pan.



do you have any videos of the intake in use?

Just wanted to give a quick update-- 997 has aligned (probably) on a double-jointed arm as well. To be honest, I haven’t done as much work on the software side of things as I would have liked to. However, 3467’s sim, and 449’s feedforward dynamics model, will both be very useful to us.

However, I have had the time to work on one of the pieces needed for our configuration space navigation-- the generation of configuration space plots so we know where we can put Dijkstra nodes.


A figure generated with MatPlotLib and a point-cloud method. Areas we want to avoid are defined and split up into hundreds of points. They are then translated into sets of joint angles with inverse kinematics and plotted here on a graph from -pi to pi. The white areas are valid states for the arm to occupy.

There’s still a flaw where an arm segment can occupy an invalid space if the end effector is okay, but that’ll be fixed soon.

You can find the source here:

I’ve intentionally made the restrictions/even the inverse kinematics very configurable, so this probably is easily adaptable to other 2-dof arm layouts.


We’ve done some small tests, but admittedly didn’t document them as well as we’d like. Today we will grab some photos, videos and share some key dimensions that we find are working.

We are not the strongest team for prototyping and have been learning a lot from other teams on here. :slightly_smiling_face:


A Placeholder

This week is midterms for the team. We met this afternoon for one last “big” push before taking tonight off and entering a stretch of lighter meetings so students can focus on those. I’m putting up a placeholder and our students will follow up with more detailed responses when their schedules allow.

VEX Arm Prototype - “Alpha” Robot

CAD Status - Possible Upgrades??

Software - Planning the First Moves

No GIF tonight - this more accurately describes how the team is feeling with getting so much accomplished this week!

IMG_3667 (1)


EDIT: Forgot to credit 7407, whom our student took heavy inspiration from!


One of our students slapped this bad boy in the design:

The basic concept is simple - stick these forks under a partner who is already on the Charging Station, then use their mass to lift ourselves up. We are planning to be light, so if we have a max weight partner with enough clearance we can get our forks in there, we should be able to lift ourselves up. If we don’t have a max weight partner - well we did build 24”x24”, so hopefully we can all fit on the station together.

A Little Bit of Math

This made me nervous, so I tried to do a little bit of math from my Strength of Materials classes. There’s a decent chance I messed something up, so if my math is wrong or I’m using the wrong equation, please let me know!

The sum of the moments about the pivot point should be the maximum moment we’d see, and I estimated 16” away from the pivot being where our partner’s center of mass is located.

The maximum normal stress through the tube is the Maximum Moment*the diameter of the tube divided by the Moment of Inertia of the tube.

I then compared this to the Flexural Strength of a piece of 0.875” OD CF tube from McMaster and then let out a sigh of relief:

Does this mean the design will work? Absolutely not. But the CF tube shouldn’t fail via normal stress given the assumptions made, and we should have plenty of safety factor in case the assumptions are wrong. It may fail in 15 other places due to stress concentrators or poor mounting or bending causing us to touch the ground or us pushing our partner off the station with the forks or…

kermit worry GIF


You’re 1 DOF away from greatness. Excited to see how this works out for you.

Assisted climb is cute!


Due to Monday being Martin Luther King Jr day and the team not having school, we decided to have a longer work day to help make progress toward our Alpha robot. We started the morning but splitting the students into groups, one group of students making the driverails, another group of students making the bellypan, and another group of students preparing the electronics to go onto the bellyplan. Once the bellypan and driverails were made, we assembled our very first chassis of 2023.


After we mounted all of those together, we then added the arm to this assembly. It did require some disassembly and reassembly due to having to drill all the bolt holes by hand but we did this not because we wanted to finish the job but because we wanted to finish it correctly.

Then after all these were put together, we printed some 1:1 drawings of sections of the electronic mounting which helped ensure all of the holes on the electronic lined up so it can be clamped down securely. The image below shows all of this put together and as seen next to the cone, this robot is very small. (The battery isn’t in the correct state right now because the crossbar was mounted incorrectly but essentially the battery would lay horizontally flat against the bellypan in that position)

Here is a video of one of our beloved mentors showing the tipping point of the bot in its current state. Currently, it is missing a battery and a claw and our bellypan would be made out of aluminum so our actual tipping point won’t match 100%.

Having our tipping point at such a steep angle and not falling over is very helpful because when the bot is on the field we know that tipping won’t be as much of a problem for us. We aren’t saying it won’t be a problem, it will just be less of a problem than previous years.



Sorry for the late response, but as Brendan mentioned the documentation of this wasn’t the best initially when prototyping but we ended up finally getting a video today to help show the intake grabbing both game pieces.


So out of curiosity what kind of ratios are you running on that first joint on the arm and the second? Our JVN calculator is showing about 250-1 to keep the amp load under 30 amps with two falcons. Are you guys seeing the same thing? Thanks!!!


On the current configuration of our VEX arm, we are using a 200:1 ratio on both of the joints. For the second version of the arm, we plan to run either a 200 or 250:1 depending on what we see as more beneficial. The JVN calculator parameters we used are shown here to help compare with what yours,



How heavy is that claw prototype?

When you extend to reach the top row nodes, wouldn’t the arm length for the lower joint be much longer than 30 inches? A single Falcon at 200:1 will very likely move the lower joint when making that max reach, but seems unlikely to do it at 15A.


You may wind up with a serious contact stress where the round tube contacts the angled charger plate. The line-to-circle contact isn’t super bad, but it’s not ideal. A square tube or a flat striker feature (like a 3D printed doober) will relieve that extra stress.

Check out:

And/or amazon for less-expensive CF tubes.

How does the combined CG of the two robots affect the charger’s ability to be balanced?


I tend to be very very conservative on the JVN calc. I don’t want to be under powered on our PID. Plus I’m bouncing in my head without knowing for sure, should I be putting in the distance of the arm CG or the end of the arm? (This is end of the arm to be conservative)