Team 3467 2023 Build Blog

Software Update 3: Saying Goodbye to the Alpha Robot: Hello Yellow :yellow_square:

It’s been quiet here on the blog from the software side for a bit, so we figured it’s time to share some progress!

The above videos show the silver alpha robot in its final form, running with its pneumatic wrist, “beta” version of the arm control software, and “spinny no pinchy” claw (see above).

When we built the alpha bot, its primary goal was to give the software team adequate time to lay a solid foundation for arm control that wasn’t rushed or hacked together, while also providing valuable insights for the design teams working on updates to the arm and intakes. Additionally, we wanted to address even the smallest of control irregularities or odd behaviors from the onset, to leave as little tech debt as possible for us to address later in the season.

In the videos above, the arm moves smoothly between its setpoints and holds position well, so we can say with confidence that the alpha robot has done its job. Let’s dive into the software powering it!

Arm Control Software

Our initial instincts were to use Motion Magic with the CTRE api, but since our REV through bore encoders are wired to the RoboRIO, not to the TalonFXes on each Falcon 500 powering both joints, we didn’t find a good software solution for configuring the sensors to the talon. It was at this point we pivoted to on-RIO control.

We started with two PIDControllers, one for each joint, tuning setpoints and gains for each joint independently. We found this to have precise enough control, but the arm wasn’t moving very smoothly, and so we knew we needed to use trapezoidal motion control. After a few days of struggling through the semantics of the api, we got ProfiledPIDController implemented with each joint of the arm having its own controller. Note that it’s necessary to call reset() on your ProfiledPIDControllers upon enabling the robot or switching back to PID after using an open loop control mode - this had us scratching our heads till we discovered it! After tuning the gains and trapezoidal constants, we landed on a solid implementation but lacked the final piece - feed forwards.

We noticed that as the arm approached horizontal angles, it would struggle to reach the setpoint until the integral term would build up after a few seconds of waiting, and then seem to slowly oscillate. This was suboptimal to us and we knew we needed a feedforward solution. WPILib offers ArmFeedforward which works well for single jointed arms, however we realized that for a double jointed arm, the dynamics are significantly more complex.

We then brought in 6328’s Double Jointed Arm Feedforward class, which is an implementation of the dynamics model published in an excellent paper by @rafi of Team 449. After some tweaking to make sure all of our directions and “zero points” were correct, this ended up being the final piece of the puzzle we needed, stabilizing the arm at steady-state positions and significantly reducing slow oscillations.

Cardinal Direction Drive Control

One thing we realized from the game reveal was the orthogonality of the scoring and pickup locations, that is to say, they all lie at 90 degree angles to one another. This presents a great use case for Cardinal Direction Control - shoutout Teams 111 & 6329 for inspiration - wherein the A B X Y buttons on the driver’s controller correspond to 90 degree angle increments for the drivebase heading. This also still allows translational control as normal, so this can aid in quick alignment to scoring or pickup locations.

Architecturally, this is a simple PIDController closing the loop on the gyro, which takes over control of the swerve drive’s theta value when a button is held. A neat trick is to enableContinuousInput() and use inputModulus() in the WPILib MathUtil library on your gyro value, so that your drivebase never spins the long way around, and always takes the shortest path to a given heading.

Goodbye Alpha!

Starting today, the software team will begin working on porting the code to the Gold robot, which is the first of two competition-spec robots the team will be building this year. The Gold robot is similar, but not identical, to the Alpha robot. The Gold robot for example has a Spinny + Pinchy claw, with a pneumatic release to make dropping cones much more smooth than the Spinny No Pinchy claw.

Once we feel confident with the performance of the Gold robot, we’ll dismantle the Alpha robot’s drivebase so its SDS Mk4i modules can be installed on the Black robot (the second competition robot currently undergoing assembly). The arm will stay together to serve as a pit display and test platform should it be needed. So in a few days we’ll say farewell to the Alpha robot, the one that started it all!



Keep up the great work guys!


Thanks John! Looking forward to seeing the 6329 machine. :slight_smile:

For those new to the thread and who would like a summary of our season posts so far, you can use the Summarize This Topic button at the bottom of the original post.


We and another team we know have both recently experienced failures with the tube nuts in our 3/4" Tube Axle for our arm joints.

Our setup has the tube nuts under considerable loads (cross-section below), so this isn’t a crazy failure - but has anyone experienced failures like this with tube nuts before? This is our first year using them so we’re curious if anyone has any tips and tricks.

Our tube nuts were from McMaster-Carr: McMaster-Carr

For now we’re swapping the tube axles for some solid 3/4" aluminum round stock tapped at each end. It’s about 3x the weight (0.3 lb vs 0.09 lb) but for now it’s not a big difference.


One solution is to cancel out the shear load using plate and only use the tube nuts for tension. That should keep the mass down while still providing rigidity


This is the best option IMO.

Another option we ran in 2019 was push the star-nut in an extra .5-1” and slide a round plug in on the end of the tube that is a tight fit on tube ID and the bolt. The bolt → plug → tube takes most of the shear load.



Echoing this, I forgot to put it in my arm guide, but 7461 usually runs doubler plates on both sides and has the tube resting inside of the superstructure tube, with the tube nut bolted directly to an outside plate. It makes maintenance really easy too as we can just slide out the tube, and I think it’s pretty strong.

Note that the tube isn’t ever actually mounted to the box tube.


Thanks for the suggestions, everyone!

In retrospect it’s obvious that the tube nuts shouldn’t be taking shear loads, and I’m glad we found this failure mode now (rather than during finals, which is where we tended to find failure modes in 2022 :2nd_place_medal:)

Our current plan is to use the solid alum tubing tapped at either end for now, and design one of these solutions in CAD to potentially implement later.


We experienced with tube insert nuts a few years ago, and had similar failures. The little spring steel leaves are not meant to carry much radial load. Hopefully Rev modifies their Ion-system nuts in future to match your suggestion.

Alternatively, if you can spare the weight, you can use solid 3/4" OD aluminum rod, instead of tube, as your dead axle.


Hey friends,

Snipe’d from this photo an expansion board on your roboRIO. What board do you use, and why?


I believe it’s a REV More Board V2. I have no idea what we use it for :wink:

Turns out right now it’s just there to look pretty. The plan is to wire our absolute encoders into the screw terminals at some point for reliability and not using the loose PWM connectors. Not a priority right now, though.


We looked at possibly using JST connectors and these connector boards as a more secure connection than the PWM connectors. But we have never actually done it, so I cannot recommend this based on actual experience. I guess that it would be easier than the screw terminals on the more board and just as secure (and more secure than the PWMs).

1 Like

Today a group of students began making some renders for our technical binder starting with our drivebase. We used Blender as opposed to another CAD rendering engine due to the faster render times and higher quality results. To import CAD files into Blender, the file format .gltf must be used, which is the blender equivalent to a .step file. Due to the larger size of the file, the download takes significantly longer. In Blender, materials need to be updated to be more realistic and a world shader must be added. As more CAD is finalized for the current build of the robot, more renders will be completed and posted.


Tweaking & Testing

It feels like the season just started, but here we are less than a week from our first event of the year. On Saturday 2/18 our team will be one of 30 teams at the official Week Zero Scrimmage hosted by Team 811 The Wild Cards. Good luck to all teams attending or hosting a scrimmage!

To prepare we have been busy working on many small adjustments to the robot, making our first set of practice bumpers, and automating routines on the gold robot. More updates will be in the next software post.

Yesterday we took our gold robot and alpha robot to WPI to test on a full field. WPI has gone above and beyond supporting the New England community by providing a full practice field for teams to use. This included having a real Charging Station made providing some ideal access to tune some auto balancing routines before hitting an official field. As a COTS swerve team using SDS MK4i modules we were very curious how our robot would handle getting the ramps of the Charging Station down during auto consistently and if an active mechanism may have been needed.

We started tuning our Auto Balancing routine we made on our wooden Charing Station at home. It worked pretty well and we did some tests if another robot was stationary while a driver ran the routine.

Since our robot is very light (under 100lbs) the gold robot had a hard time driving onto the station if Alpha was already balanced on it. One time we came at an angle and it did get up but didn’t seem consistent. Once it was on the ramp, auto balancing could do its thing. We didn’t drive Alpha around because we didn’t have bumpers made so we didn’t test two driving on at once.

Next we moved into basic autonomous routines and played around getting a simple L3 Cone + Mobility and L3 Cone + Auto Balancing made. These we feel are satisfactory for next weekend and will let us move to other tasks.

There’s still more work to be done making tweaks to speed things up, work on inverting for Red/Blue, and slowly get the Mobility routine closer to a Staging Mark to plan to set us up for picking up a game piece. You’ll notice the auto balancing sequence stopped working halfway through this video. After we did some teleop practice we started increasing the drivebase speed and the changes started to impact the auto balance routine we had tuned. By the end of the video near the end of the day we got it working.

These auto routines worked with minor tweaks with no adjustments between the wooden and real versions. We were very excited about this since again we were worried if our robot would be consistent on a real charging station. For any teams wondering about our clearance the bumpers we used in the video are 1 ⅝” inches off the floor and using a slicker fabric VX21 X-Pac Fabric.

Next we did some much needed cycling to work through the setpoints we had been tuning in the Grid and Double Substation.

In these videos the drivebase top speed was limited and some other things like the Cardinal Direction Control had not been fully tuned. We also swapped a few different drivers and one of the Cone pegs wasn’t 100% stable causing some misses in auto. The good thing was it proved our robot can do what we intended it to do with scoring and pickup. We have long list of improvements to things like our sequencing, speeds, and handling of game pieces to not lose them so easily. The ground intaking isn’t groundbreaking, but we knew that when we made the decision to use the wrist and basic claw vs. dedicating a whole mechanism which is in the works. More on this later.

Something it did show was the importance of the driver and operating communicating to ensure all arms in the robot are stowed before leaving the Community or Loading Zone. A trick we found was if you hugged the wall in and out of the Loading Zone you can extend your travel time in a safe space if you need to extend out two sides. Traffic patterns will be very interesting in this game coordinating 2-3 robots on each alliance needing to move in and out of these areas and crossing traffic with your opponents.


Can’t wait to see y’all this Saturday!


It was a pleasure to see the Windham robot in person yesterday. Y’all are killing it, can’t wait to get on the field together!


Likewise! Can’t wait to see the 1768 machine again next week. That robot is slick!

Thanks again for the BAG.


Thanks for sharing the charging station videos with another robot on at various locations. We didnt have time to try this extensively.


Love this process, do you think you’d be willing and able to post a “how to” when you guys are wrapped up? I’ve got a couple students who are looking to get started on renders, but I don’t have much experience on how to do it well. Any details you guys would be willing to share would be an awesome resource for them!


We look to release an in-depth tutorial on how to render a CAD model in Blender later on. However, this tutorial by BlenderGuru gives a very good explanation of Blender’s features and how to use them. You can download Blender for free at Download —

For now though, here are 2 more renders of our V1 and V2 claw. More to come soon later