599 The Robodox | 2023 Build Thread

the The Robodox 599 kickoff featuring :: underestimating the game challenge :: bad designs :: passable designs :: not enough prototyping :: and some ctrl-c


In which we read the game manual, did strategy, and read the game manual more. And then took the rules test.

Our game analysis document:

We began to discuss what mechanisms we would use on our robot. We settled on a swerve drivetrain (with L2 mk4is).

A few designs for a manipulator and intake:

And a few very terrible drawings made when I explained them during our recap meeting:

2019 pivot extension:

Four-bar (double compounding optional):

Double elevator (in name only, the second ‘elevator’ is a slider):

Wristed intake:

“Noah’s roller thing”:

Eventually during the yknow midnight discord convos we decided that a pink arm system (eg. 294 in 2018) was worth looking into.

in other news our omio power supply got fried (fun) and we’re waiting on school admin to be able to get a new one

Our team completed some worksheets prepared by our strategy team.


We began to prototype today, among other developments. Mostly we prototyped noah’s roller thing, as the rest of our design team was still discussing options for scoring and an arm structure. After running geometry, we decided that a pink arm system didn’t leave enough space for the intake structure. We eventually settled on something like 971’s 2018 system, with two independent arms.

We started machining drive rails for our chassis. (150 holes go brrr)

Programming updated laptops

e&p started prepping batteries

We cleaned 60 years of rust off our bridgeport mill. apparently it was supposed to be silver

We also began to fabricate game elements. We are focusing on charging station first but we’re missing some materials, including the hinges


week 1 recap (if you squint) featuring :: cad :: misguided prototyping :: actual prototyping :: field building :: “cad release” :: a goat named rianne :: the cad lead, suffering :: or well just plain suffering

should i have gotten this done earlier? i should have done this earlier

“CAD release”

…is it still a cad release if there isnt a neutral file format

there isnt a step because there isnt a main assembly. this is fine.

would you believe me if i said cad is only a day or two behind

GrabCAD public drive:


Cad’s been. Going. Has it been going well? …good question how about maybe

We settled on an intake design similar to most 2018 intakes, with horizontal rollers. We plan to build in some compliance by using both compliant wheels and some small gas springs.

We had a discussion on our prototyping, and decided that our way of prototyping was ineffective. We temporarily paused prototyping in order to work on CAD and create layout sketches. After finishing them, we continued to prototype and should be done next week.

CAD screenshots:

FEA of the arm with a 500 N force at the intake attachment point:

Arm assembly as it is right now:

dont look at the bottom i want to cry

does it work? good question


Mechanical have been working hard on our parts. After finalizing the drivetrain CAD, we sent the drivetrain rails out to be fabricated.


We replaced the power supply on our omio CNC router, and it works again. Here we’re cutting a belly pan segment:

Our (newly silver!!) bridgeport mill:

Official goat Rianne machining drive rails:

More drive rails:

Electrical and Pneumatics

We got six new MK batteries and two new chargers to support them. We are transitioning to 4 gauge wire this year, so we’ve been changing out our battery leads to 4 gauge.

Electrical have also begun to plan out the electrical layout on the belly pan.


Programming has been working on apriltag detection with photonvision. We are setting up photonvision on a beelink minipc that we got recently.


flashing lights warning - 599 Week 1 Recap Video


I only forgot about this for like four days and it’s still technically on time so everything is fine i swear


We were supposed to be done this week. We, uh, aren’t, but we’re “done enough” that mechanical can have our parts. By “done enough” I mean “we have a cad release with a .step and main assembly” and “if it were made now i can pretend it works”.

GrabCAD workbench link (should be the same, should also include a .step file):

Some CAD images

Intake iteration 0 (Sushi style intake in order to have one by CAD’s deadline)

Intake iteration 1 (A native claw-style intake with pneumatic actuation in order to intake both game pieces)

Final (we hope) arm

Arm gearbox (missing: brakes)


We began assembly of the chassis, and fabrication of sponsor panels.

Electrical & Pneumatics

In E&P, we were able to figure out a general layout of the belly pan that is able to contain both pneumatics and electronics. Many of the challenges we faced in planning the board came from the large number of components we needed to be on there like the Beelink or the CANdle, in which we were also able to figure out how to have cool LEDs working. In addition, we continue to work with our batteries to ensure that they are ready for competitions and analyze them through the use of Andymark’s Computerized Battery Analyzer.


During the offseason we managed to get working swerve code that can easily be translated to this year’s robot. So going into this season the main priority was figuring out how to optimally utilize swerve during autonomous periods. We began looking into pathplanner as one of our best options as unlike pathweaver, the 3rd party stuff is more suitable for holonomic drive and decoupled headings. By Wednesday we were able to get output from our drive motors that sorta matched what the trajectories we were creating. However, as we moved onto the ground we realized that our current code kept swaying to a side when we imputed a straight line for a path or could not rotate while moving. After a couple days of banging our heads against the computer we created a chief delphi posted to hopefully get some advice on where our code could be going wrong. The creator of pathplanner himself actually replied and provided some extremely helpful advice.

One problem that now seems painfully obvious in retrospect is that we created wpilib’s HolonomicSwerveController in the execute part of the command instead of the initialize. This meant that on every iteration of the command it created a new object instead of reading from the old one. Sorta insane how we missed that. Another piece of advice that we hope to start testing with on Monday is using pathplanner’s own swerve controller. Hopefully this could provide a more accurate translation of the trajectory states that are produced in pathplanner.

The end goal is to use this to reliably run 4-6 key autonomous routines that can make us extremely competitive during matches. Most of them will likely be run through top of the charging station as crossing the wire cables could mess up our odometry, although hopefully our plan to implement apriltag vision into our poseEstimator could help alleviate this potential issue.

We are still early in development for developing the code in our arm subsystem. From the amazing help of our mentors we have been able to learn a solid foundation of inverse kinematics that we hope to apply to the design of our code to make arm movement as seamless as possible. We plan to create a simulation of the arm movements to predict the PID values that are needed for the arm. The idea was explained to us by our amazing mentor Mr.Siegert.

Week 2 Recap Video:


(written by me, Chanon, William, Diego)

happy (belated) (lunar) new year!


…i know, im late again; life is not a merciful captor


cad is done; detailed post coming soonTM, I swear. Some highlights:

low-effort part tracking because ben was lazy

assembly drawings. are. very hard


We’ve been working hard to fabricate the parts that CAD has given us, which besides being the normal amount (a lot) of spacers, shafts, and L brackets, has been a fun challenge with their more challenging and detailed designs. (CAD note - they’re …having fun with 42” long rails that are too long for the DRO, elaborate lathework, you know, the usual)

We’ve been staying on top of the drawing being pushed out and are expected to hit our deadline without an issue, if no machines break or something majorly bad happens.

Electronics & Pneumatics

We’ve been continuing to analyze our batteries with the use of the Andymark CBA and determine which ones are suitable for competitions and for practice. In addition, we are finalizing our belly pan design and are going to start the integration of components onto subplates to be mounted on the bottom of the belly pan. This would also allow for the robot to be more easily maintainable at competitions because of the ability to easily see the components and wires and the ability to remove and replace components faster.


Fixes have been made to the configuration of the SwerveDriveKinematics in order to correctly align us with the actual coordinate system of the field. This has fixed issues regarding our path planning trajectories, of which, we can now produce generally accurate paths to run during the autonomous period.

Vision through the beelink has been set up on our offseason bot in order to test apriltag integration to the pose estimation of our bot. The end goal is to be able to run accurate autonomous paths on the lower side of the charging station over the power cord. This would make our autonomous periods more competitive over teams who must go through the top of the charging station in order to keep an accurate odometry reading.

Motion-profiling of the arm subsystem has been tested on our dummy board and is confirmed to work. We now wait for the mechanism to be built and electronics assembled to do final tuning.

I mean, we’re on schedule? So.

Post written by Ben, Ian, William, and Diego


the promised cad post

you see, this was supposed to be finished later but we were being not lazy and i went “why not”



or, Project Speedrun CAD

We’re using MK4i L2 falcon swerve, in the normal configuration. You know, pretty basic stuff. The more interesting part (not by much) is our bellypan - inverted electronics with a polycarb shield on the bottom. We might add some silicone to aid with grip if we drive off the end of the charge station.

For supporting the arm and gearbox we decided to make a simple superstructure consisting of a 2x1 supported by triangle 1/4th inch gussets on both sides attached to the dead axle.


or, Project Give Ben Trauma

Our arm is a 2dof arm - basically 971’s 2018 arm - designed to be somewhat easy to manufacture compared to carbon fiber round tube, at the expense of weight and a small amount of stiffness. There’s a wrist on the end, so in total there’s three degrees of freedom on the arm.

Both dof’s on the arm are driven by the central gearbox with power transmission via steel wire rope. An interesting byproduct of this implementation is that without motor input, both joints act as a virtual four bar.

The near (proximal, first, lower) arm consists of 2 ~42” long sticks of 1/8” wall 2x1. We considered using 1/16” wall and ran fea for this as well, however we decided to stick with 1/8" for peace of mind.

(applied force of 500N, where the intake is)

The far arm consists of 36.5” of 2” OD 1/16” wall round tube, welded into round tube endcaps. Shoutout to Mr. Paulson for being a goat and helping us with welding.


or, Project What The [Four-Letter Word] is Going On

…yeah, that’s basically it. Both arms are driven by two Neos on a 161.58:1 gear reduction, with a final reduction of #35 chain. A single neo on a 80:1 gear reduction drives the wrist.

There’s also a pneumatically actuated brake for both arm stages. We decided 971’s braking system was the best method to go with, so we decided to use a pancake cylinder to push a rotating brake disc against a stationary brake pad. The rotating brake disc is connected to the gear system, so when stopped it stops the whole stage of the arm.


or, It’s Never Gonna Be Final

We quickly decided to start off with a 2018 style claw to pick and place cubes, but quickly came up with other iterations. Our second idea was to use 3 rolling tubes, almost identical to the intake on the everybot. We eventually settled with making 3 different intakes, a 2018 style claw, an everybot intake, and a 7461 Sushi Squad intake. We decided to use all 3 intakes, rotating each one out.

Our 2018 style intake utilizes two 1/2in pistons to push out the claw, with “open” able to intake cubes and “closed” able to intake cones. This design also allows us to clamp cubes instead of spinning our intake in and out. We are powering our rollers with a single neo 550 on a 5.75:1 gear reduction. In total, our intake weighs 6.1 lbs.

There is a new .step file in our GrabCAD directory, which should be the (mostly) final CAD, before intake iterations.

post written by Ben and Chanon.


taking some inspiration from other teams and threads (who are much better at this thing than I am), is there anything you want to see from us? we’ll see what we can do

599 The Robodox CAD Overview & Intake Demo | The Open Alliance Show | Charged Up 2023 - YouTube 599 The Robodox provides their updates includes a deep dive into their CAD including cool explanation of their breaking system for their arm take inspiration from FRC 971 and also shows off intake prototypes



Why have pneumatic brakes for the arm joints? Are the motors not torquey enough?

We were mostly concerned with keeping the arm inside the frame perimeter before the start of the match. Doing this would also make the arm stiffer while scoring, and potentially lessen the load on the motors when holding position.

Is your brake a COTS or custom?

its a custom inspired from 971’s 2018 robot

1 Like

Would you be willing to provide more detail on why you decided to go with 1/8" 2x1 instead of 1/16? Do you have some kind of team standard for what you want to see or not see in the FEA results for the design/materials? I’m admittedly not very knowledgeable on them.

To be completely honest, it’s our first year doing FEA as well. I’m fairly certain we could have gone with 1/16 wall and have been fine.
On the other hand, experience made me worry that the tube could fail at the bushing holes, and thus we made a decision to use 1/8 instead.

The most immediate impact of using 1/8 instead of 1/16 is increased weight; however this would only increase the weight by 3 lbs, which is negligible compared to the gear ratio and total robot weight.

What led you to choose a wire rope transmission? How are you avoiding slipping on your wires?

We’re avoiding the wire slipping by clamping it down with bolts on the pulleys. This leads to being unable to rotate >180deg but since it’s just arms we decided this was not a problem.
We considered using dyneema (and still might for the arm) but decided not to because we were concerned that it may stretch.
For driving the large arm, we still might use dyneema due to the stiffness of the wire rope not playing well with clamping.

1 Like

under 80% load im pretty sure dyneema is rated to stretch by a factor of 0.46%

1 Like

Week 4 5 i dont even know anymore

It’s been a while, hasn’t it? By necessity, a big update this time around.


As it turns out, mechanical are goats and can somehow handle goofy cadathon parts.

We’ve mostly finished the parts for the robot, and are moving on to some other projects, such as fabricating parts for our new robot cart and battery box.

We’ve been fabricating spare assembly parts for things such as arm and gearbox. CAD designed a lovely frictional brake system (for some reason) and fabrication for it has been rather interesting as they’re decently low tolerance parts. We are also working on making belt tensioners using out cnc and mills. Besides that we are also working on redesigned parts since cad loves to remake things 500 times. We are also doing updates on our machines by fitting a dro on one of our mills. We are also working on fabricating and assembling a proper robot cart instead of using a random cart. That’s mostly done and just needs a few more rails with thousands of holes. Battery box is also on the way and no more floor batteries or traveling with a battery buddy to comp.


We powdercoated our chassis and spray painted some parts. It’s nice, although working around the extra thickness added has proved to be a bit of a pain.

We also put all our v1 assemblies onto the chassis. It’s finally coming together

After assembling our v1 gearbox, we found a couple problems such as tolerance buildup between the gearbox plates and chassis. Some filing took care of the problem though. When assembling our cable runs to actuate the intake, we realized that we had to loop our metal cable around more than once to have more than 180* of rotation, but we didn’t have enough space to, so we decided to switch to long tensioned 9mm HTD belts since they were easier to assemble and fix.

We also disassembled our swerve modules and found that most of our bearings were starting to go bad, so we would probably have to reassemble the modules after our first competition.

Electronics & Pneumatics

With the chassis powercoated and the swerve modules assembled onto it, we were able to start the integration of electrical components onto the robot underbelly. We were able to assemble our subplates onto the drive train with the components on them already, allowing for the process to be quicker and reduce the amount of time we need to finish everything. We had to do the subplates on the drive train as it would allow for the mounting of the components to be more secured, and our mentor pointed out that it would allow for maintenance to be easier. Hopefully by next week, we are able to finish securing components down and start testing by then.

Recently, our subteam was able to mount all of our plexi plates with the electronics components onto the underbelly of the robot and the pneumatics on the top of the robot. Considering our team’s past with wire management, we wanted to prioritize the ability to maintain and replace components. Therefore, our wiring has changed to allow for the viewer to see all the components, use cable flags so that we know what wire is going to what component, and a ton more zip ties and anchors to ensure no loose wire is present.


As the bot is being assembled we slow down for what we can test on the robot. One thing we have been able to make progress in is in our intake. First, we tested the auto intake and auto outtake commands that use a rev color sensor to determine the series of intake movements to successfully capture a game piece.

Currently in development is tying field orientation to the dpad to ensure faster cycle times. We plan on having the four cardinal directions tied to the dpad that will send the robot to that direction using the shortest path. This will be overridden when moving the right stick so that the driver can quickly switch between automated and manual control of the robot’s rotation.

Another wacky thing that the prog team is working on is to create the ability to switch to arm centric drive, which is where the robot will rotate on the location of the wrist as opposed to the robot’s center. This could help with cycle time and node placement though this is highly experimental and is likely not going to be ready for the first competition .


We’ve been done for a while here and yet i still manage to be very late on oa

Even so, we’re working on some extra things - such as mounting cameras and swerve module covers - and refining our intake. Not much to speak of at the moment.

During assembly of the arm, we found that using steel wire rope to drive our joints raises a host of issues. It’s not really flexible enough, and thus working with it is difficult. Additionally, the wire rope that drives the wrist only has 180deg of motion. Compounding this 180deg of motion over three joints led to the wrist being practically impossible to have any range of motion, thus we transitioned to using 9mm wide HTD belt.

To extend on that, we are transitioning to using dyneema for driving the far arm. Dyneema is similar in strength to wire rope, yet many times more flexible, and thus much easier to work with. It adds some concern with stretching of the rope, but this is mostly mitigated by a custom inline tensioner system.

We’re behind on our personal schedule even though we’re the furthest ahead we’ve ever been. It’s quite a strange irony.

Post written by Chanon, Ian, William, Diego, and Ben.


15 February 2022

…what a way to turn around. two posts in a day? who would have thought


We “finished” the v1 robot today. Meaning we attached all the subsystems, and are ready to hand it over to programming for them to start their initial work.

There’s been a lot of changes since our previous mechanism post. Mostly in the “execution” sense, meaning that the design stays relatively the same yet our method of accomplishing it is different.

Most noticeable: our arm is driven with dyneema rope. It’s posed its own difficulties with its initial stretching under load, however this is a small inconvenience when compared to steel wire rope, which would have forced us to make many concessions and potentially not even have a working arm.

Also worth mentioning: I’m not particularly good at cad; there’s many places where the existence of fasteners were… uhh, not quite taken into account and thus need to be changed in the final robot.

Thing we put the robot on Robot Cart

Featuring: the skeleton of our 2022 offseason robot. RIP Bilbert, we needed your swerve modules and pulleys and belts and motors and stock and

Here’s the cad. (obligatory /s) oh wait wrong link this is the actual cad.


As seen above, we were able to mount everything we needed on the robot for the subsystems. All that is in store for us now is to continue some documentation for the robot (CAN timeline) and prepare our batteries for the upcoming competitions.


https://youtu.be/DY2h7PcXiq8 599 The Robodox shows off their new chassis with an overview and goes into detail on their swerve drive programming process on The Open Alliance Show.