2357 System Meltdown - 2023 Open Alliance Build Thread

“Backboard” Intake Testing

We cut out new pieces for our “Backboard” intake design. This will be our 3rd iteration. This version adds a “funnel” to the two sets of 4" compliant wheels we had before.

The good :smile:

The first try worked well! The funnel brought the base to the center and locked it in place.

The bad :frowning_face:

In this second instance, the third roller is working against us, by grabbing the tip of the cone and shoving it in the wrong way.

The ugly :open_mouth:

So, we have an obvious weak spot in our 1/4" masonite cutouts. But we all had a good laugh and the slow-mo is pretty enlightening. Once again, the third rollers are grabbing the tip of the cone and shoving it the wrong way, which wedged the cone in sideways instead of the direction we wanted.

What did we learn?

Further out in the funnel, we don’t want wheels down low where they’ll make contact with the tip of the cone. We will either move these wheels up, or omit them entirely and just use a static shape of some kind (a rod, or hdpe skid, etc.) in order to push the tip of the cone away so the base gets pulled in.

I would like to say no intakes were harmed in the making of these videos, but the evidence speaks for itself! Don’t worry though, we’ll shore it up with some aluminum strap on Saturday, adjust the outer axles, and run it some more times before we iterate again.

Thanks for following along!


How are you planning on scoring with this design?

Our plan is to capture the cone, rotate it up with the intake, and then hand it off to a separate lightweight claw mechanism for scoring. I’ll post some CAD with the week 3 recap in a few moments.


Week 3 Recap

Thanks for bearing with us on the late recap for last week! Lots going on in the schedule right now.

CAD Updates

The robot is taking shape in CAD at this point, but we’re pushing hard to get to 100% complete. Still a ways to go.

To recap the overall design:

  • Separate intake on single pivot
  • Static slanted uprights
  • Rotating arm at top
  • Single extension on the arm
  • Wrist rotation
  • Latching claw

The intake rotation, wrist rotation, and claw latch will all be pneumatic cylinders, so we’re going to watch our air usage (the ones on the wrist/claw will be small though)
The motors and gearboxes for the arm rotation and arm extension will be placed down at the bottom of the uprights, for CoG purposes.

Intake Refinement

This has been our top priority and we’re continuing to iterate on this design. We just tested out the 4th physical iteration on a static mount on our preseason swerve drivebase. This will be the last non-deploying version of the intake. The next one will be on the 2023 drivebase and will pivot, but will still be in wood (we try not to cut 1/4" polycarb until we know the design works, because it’s so spendy!)

Drive Base

We held off a bit on putting our drive base together for a couple reasons, first was that we already had a working preseason one that we were using for mounting prototypes, and second was to get a bit more time to try to shrink our width as much as we felt comfortable. At this point, our parts are cut, the swerve modules are off, cleaned up, re-greased, and we’re wiring it up.

As mentioned before, we’re using SDS Mk4i modules. Our electrical setup is primarily on the bottom. We really liked this setup last year. We use 1/4" HDPE sheet on the top of the drive base, and we use our CNC router to cut it out and center drill the mounting holes for the electronics, then we drill and tap the HDPE for electronics mounting. We’ll finish it off with a thin polycarb cover for the bottom. It may be a bit of a hassle to tip the robot to work on the electronics, but after taking a few screws off, we have full access to almost all of the wiring this way, and the electronics are very well protected from above and below.


The programming team has continued to work on base subsystems of the robot code, targeting and autonomous. Here’s what we have so far:

  • Subsystems set up with stubbed off controllers for motors/pneumatics
  • Limelight targeting of apriltag for centering and advancing in front of cube nodes and cone nodes
  • Initial autonomous routes using PathPlanner
  • Auto-balance using Pigeon 2

Practice Field

We have room for about 1/3 of a field in our practice area, with competition carpet from 2019. We have 1/3 of a grid set up and we also have a functional charge station. We bought some workout weights to bolt to the bottom of the charge station and it seems to be working well. The programming team spent time adding tape to the practice area for both a red-side and blue-side setup. We can just barely fit the area from the grid to the starting game pieces with about 6" to spare!


2-week recap

Hi folks! Apologies for missing a week+ of updates. On a personal note, I’ve been assigned to a new client at work and it’s taking a lot to get ramped up!

Anyway, there’s lots to catch up on, but I’ll try to summarize as much as possible. First off, we’re definitely behind where I’d like to be in our build; however, this is something we planned for because of our team being completely comprised of 1st year and 2nd year students. Additionally, we spent a lot of our first 2 weeks+ working on a floor intake that can pick up tipped cones. No regrets there, we still feel this will pay off at competition. It’s a luxury we can afford to pursue because our first competition isn’t until week 3. On to the updates!


The intake has continued to progress through some iterations. The core functionality is sound, but we knew it would be a fairly heavy extension that would need to rotate on a single pivot in order to present the game piece the way we wanted, where the cone will be standing up vertically while in transit, with no more than 1 inch of deviation in any direction. In order to bring the intake in, we designed a non-parallel four bar linkage to get the 90+ degree motion we needed. Still, we’re adding some passive springs to allow us to use some smaller pneumatic cylinders. (we like using 3/4" bore wherever possible).

One of so many test runs on the intake:

The first pneumatics test (we’ve refined this design a bit since then)
intake pneumatics

Extension Arm

We went down the road of having a slanted elevator carrying an extension arm for quite a while in the design, then had a realization that the slant of the elevator was actually causing a lot of interference issues for our claw mechanism. That coupled with the intake’s surrounding of the game piece from below and the sides made for a very tricky design that ended up stuck in a corner. Unhappy with this, we took a step back. We went back to the original geometry sketches to see if we could simply tilt the elevator back to 90 and make that work. It would necessitate a taller robot, but the tight tolerances were just making us very nervous. To our delight, after doing the sketches, we got the geometry to work and additionally, we were able to remove the dependency on an elevator altogether as well! This greatly simplifies our design and also allows us to put all of our motors down near the base of the robot for a better CoG. It was a big change, but one that greatly reduced our part count and removed a lot of the tight tolerances plaguing our CAD work.

Lesson learned: When the design gets tricky and difficult, take a step back and think about why this is happening and if there’s anything that can be done on a bigger scale to fix it.




The claw has had 4 major revisions in its life, some of them suffered from lack of clamping, some of them suffered from completely external issues (see above about tolerances). The constraints for us using the intake we want means we have to grasp the cone from in front and behind it instead of the sides, but it also has to swing up out of the way for the intake to bring in the game piece. The current (and hopefully final) iteration is a sliding clamp that rotates out of the way at the extent of its rotation:

Clamp in open position, out of the way for the intake to rotate the game piece from below:

Clamp starting contact with a cube (which will be held securely on the sides by the intake):

Clamp starting contact with a cone (the tip of the cone fits between the two sliding tubes):

Clamp in the fully closed position. We expect the cylinders to stop before this point when on a cone or a cube. Both can handle significant clamping forces, so they’ll reach an equilibrium with the cylinders:

Additionally, we’re using pneumatics for the wrist motion of this clamp as well. This will make the claw mechanism as lightweight as possible. In order to get the rotation needed for our wrist, we’re using a “dogbone” joint inspired from an excavator bucket:

The first pneumatics test of the “dogbone” wrist joint with a 2"x3/4" pneumatic cylinder:
pneumatics wrist


While we’ve been taking two steps forward and one step back in our mechanical work, our software team has been dashing forward at full speed! The subsystems are present as much as they can be without mechanisms to test with, we’ve got swerve auto paths running using PathPlanner, although our PIDs will need to be updated after we get the rest of the robot’s weight on board. We’ve also got Limelight PID code running to center the bot on a cube or cone column.

Grid Piece Tracking

In the more experimental department, we’ve had some software folks looking into actually tracking which game pieces are present on the grid. We think it’s going to be fairly difficult to see one’s own grid especially from the 1 & 3 positions, so we’ve actually been experimenting with using the AprilTags on the grid to locate the positions of each of the grid nodes and then check if there’s a game piece there or not. We’re not using any crazy AI or ML techniques to recognize what a game piece looks like, just figuring out where they should be on the picture, and checking for color. We’ve got the first couple of steps working here in WPILib Pi:

Business & Marketing

Our Business team has been busy! After coordinating the Woodie Flowers nomination, their number 1 goal has been to get our Impact award over the line and due to their amazing writing and editing efforts, we submitted it Wednesday this week! In order to involve the whole team, they wrote up questions on sheets of paper and each person on the team took 1-2 to answer with a few questions on activities they participated over the offseason and other aspects of our team. I believe this is the most promising Impact/Chairman’s award submission our team has ever completed. We’re excited to see where it goes!

Additionally, we just received confirmation this week that we received a sponsorship from the Gene Haas Foundation! We’re super excited about this grant and will be using it to further enhance our CNC machining capabilities.


Our strategy/scouting team have been working to refine our processes at competition this year. We’ve finally got a dedicated scout lead, which allows our strategy lead to really focus on getting the best match data possible to our drive team before every match. We’re going to have a printer in our pit this year for them to print out a match sheet for every quals and elim match we’re in with current stats for each team involved and their own suggestions for match strategy. This will be a huge upgrade for us at competition and we’re really excited about heading down this path.


Well that’s about it for us right now. We’re at the point where a lot of our build is coming together now. We’re unfortunately going to miss the Lee’s Summit scrimmage :cry: but we’re still on track to get at least 2 weeks of drive practice and autonomous tweaking before our first competition. We’ll be putting in extra time as needed to ensure we get there.


Sorry in advance for the barrage of questions, I really like this intake for its consistency!

Do you have any video of more runs? Are there any cone orientations that do not work well? Do you find that you have to approach the cone slowly as pictured above or can you go faster as well? Do you have any trouble with cubes?

Thanks! We like it too!

There are a couple more videos I took on that same day. I’ll just link them here:

Cone (miss)

This intake cannot take cones with the tip pointed towards it. We estimate this is around 90 degree or less range centered on the tip. As you can see from the first cone video above, the end of the intake can push the tip of the cone away in most other orientations. The second cone video shows a miss, but it was really misaligned on that one.

We can go pretty much as fast as we want. We’ve been a bit ginger with the early prototypes because the masonite is a bit fragile. We will have the polycarb cut for the intake this week so we’re looking forward to going faster/harder on the intake after that. We’ll take more video for sure.

Cubes work really well, we’ve found cubes extremely easy to work with.

To summarize, we like this design the best of all the ones we’ve tested:

  • It can reorient any cone on it’s side except from a tip-in orientation
  • It presents the game piece to our scoring device in a very repeatable orientation and location
  • It can take in cubes and cones effectively
  • It holds them both extremely tight

Downsides we have observed:

  • The outer tips of the intake are passive, so they can reorient the cone
  • The intake has to be driven forward to reorient a cone, making it just a little less “touch it own it”
  • In order to pick up a game piece in a corner, one would have to use the tips of the intake to slide it away from the corner in order to get to it
  • It’s heavy and a bit hard to pivot back in the robot. We’re still looking at ways to reduce weight

Thank you for the detailed response! To follow up with a few more questions.

  • What wheel RPM do you use for cones vs cubes (or are they the same)?

  • Did y’all find the passive funnel tips to be critical, seeing as they add weight and length? I saw a few videos further back that did not have the tips and wonder what the performance gains are.

I don’t recall the exact RPMs on this, and for the final design, we’ve changed to use a Redline 775 and a single-stage versaplanetary lite. I do also recall that slower speeds work better for cubes and faster speeds work better for cones. I’ll see if I can get actual numbers on this.

The funnel tips further out really help to orient the cone before it hits the inner two sets of wheels. Without it, the cone can get misoriented a lot easier resulting in failed attempts or even sometimes the cone getting stuck in an awkward orientation. Thankfully we’ve always been able to reverse the intake to release the cone when that ever happened.


We dialed in the final geometry of our clamp scoring mechanism last Saturday. These are videos of the last prototype before we started cutting polycarb Sunday.

The design of the clamp uses two 3/4" aluminum tubes to slide on a UHMW pivot (for these tests, the pivot was made out of poplar because 1" UHMW is expensive!)


The clamp is held by two 3/4" bore 2" long cylinders. These tests are at 50 PSI (or less because our air fitting had a leak)


The cube is held extremely securely even with only a little force. Trying to punch the cube out of the clamp doesn’t even budge it. If you’re curious about the clamping surface, we used 2 thicknesses of this natural gum and silicone foam which feels like the bottom of a mouse pad. We glued the two layers together with Barge Infinity cement.

The last video is of the wrist motion. We took this design from the “dogbone” mechanism of an excavator bucket joint. It’s powered by a single 3/4" bore 2" long cylinder (again at 50 PSI with an air leak). We’re very pleased with the results here. The only mounting point for this entire wrist/clamp assembly is a set of 2" long aluminum plates bolted to a 1x1" square tube. Also, we only have to send 4 1/4" pneumatic tubes back through our arm, no wires, gearboxes or motors at all on our end effector.


The total assembly here is just under 5 lbs, and the fasteners here will weigh more than the shafts we’ll be using for the final assembly. I believe we can also lighten the side panels or linkages further, but I was told not to give in to premature optimization :smile:


The OMG only 2 weeks to competition update

Hi folks, it’s been a while! So, the key phrase for our last couple of weeks is “chasing down the gremlins”, which is a part of the design process we all know and love…right? Yeah! Once you get a robot all built, then you get to see all of its major flaws and fix them. Sometimes, it’s a small quick fix, sometimes it’s a larger one, but they all need to be done! * knocking heavily on wood * I’m hopeful we’ve managed all the major gremlins on the robot at this point.

For reference, here’s a picture of our robot as it sits now:

While it is 98% complete, we’re still fixing up some issues here and there while allowing our programmers time to dial in the code and getting some drive practice when we can.

Gremlin 1: Intake actuation (a.k.a. slamming the intake into the floor)

This one showed up quick. While we tried to lighten the intake as much as possible, we really needed it to glide on the carpet, which means placing the intake onto the concrete floor. We learned when you do this quickly with pneumatics, the results can be…unnerving to say the least. I winced each time it hit the floor. After enough times of this, we actually cracked and fractured the 1/4" polycarbonate. It was at that moment we knew we had to make a change. We went from this:

To this:

Instead of using a 4-bar pneumatic linkage, we’re now using a combination between non-pivoting pneumatics and a winch. We reasoned that we can use a trapezoidal motion profile on a winch to ease the intake onto the floor, and the pneumatics are only there to move the intake off of top dead center to deploy it. Both are using nylon straps. The winch uses a 1" nylon strap on a 3" diameter 3D-printed spool, and the pneumatics use a simple 3/4" strap sewn around a 1/4" steel shaft held by the piston clevises. It slides through a UHMW pivot and pulls the intake about 60 degrees, at which point it falls slack.

In all, it took us about 1.5 work sessions to get this in place. Our CNC manufacturing capabilities have been excellent this year! We generally never wait more than 1/2 of a session for new parts!

Gremlin 2: Arm rotation

The first surprise we got when we get the robot all together was our belt system for the arm rotation. We had plenty of torque, but we were still slipping belts right off of the gearbox at the bottom. We added some tensioner posts for the belts, but still had some issues, so we switched out the belt for #25H chain and sprockets and added more UHMW tensioner posts to keep everything snug and happy. We further ran into some more problems with even the chain skipping some teeth, and when we found a high-friction handoff issue (more on that below), we pushed a bit too hard and snapped our chain! Since then, we’ve shored things up a bit more, added an extra bearing for the maxplanetary shaft, and we plan on ordering #35 chain and sprockets to swap out if we need to.

Gremlin 3: Arm Extension

Just like the rotation, the extension was also skipping some HTD5 teeth just because of the longer belt runs and higher torque situation. So we switched these out with chain as well just to be safe. The 15mm HTD5 belt for the actual arm extension remains, however, and we’ve had some issues with skipping teeth in the last 8 inches of travel as the UHMW slides get closer. This especially happens when we have a cone loaded due to the extra weight. We are mitigating this by 3D printing a belt tensioning system where we can use 1/4"-20 screws to tighten the two ends of the open belt together, and also we added a 1/4" shaft with a small UHMW roller on it that goes right up next to the drive pulley for the extension for extra tension and wrap on the drive.

Gremlin 4 The hand-off

We knew this could be a tricky one. Handing off game pieces from the intake to the claw is an operation that requires accuracy and fairly close engineering tolerances.

First issue we found was that top bar of the intake we originally used for pneumatics and then used for our winch pull point? It was too high and interfered with the claw. We could have made it work, but we would have had to rotate our arm out of the robot and synchronize it with the intake coming in when we pick up. Instead, we opted to just chop off the top extension of the intake and mount that pull bar lower. That helped a lot.

Second issue was that the open part of the claw was sagging a bit and the tip of the cone would hit it as it entered. After looking at this and wondering for longer than I should have, I remembered that we had the dogbones in the wrist to change as needed. With extending the dogbone links only 1/4" (really!) the claw pivots up and out of the way, clearing the tip of the cone by at least 2 inches.

Bonus gifts from the intake gremlin!

Fixing our intake pneumatics gremlin and adding a winch instead allowed us a few other benefits:

  1. We can rotate the intake out slightly to ease the exit of the cone base as we lift it out with the claw.

  2. We can score in the hybrid nodes even easier just by rotating out the intake a little and reversing it.

  3. We gain the ability to tilt our intake up and receive a cone or cube from the single substation ramp as a kind of hopper setup. But we will probably still primarily take from the floor as we think it will be faster. We will definitely test both though.

  4. Shooting cubes?? We had to try it out:

cube mid

Success! And for the high?


Not quite as solid, but possible. We think we could ensure our success on this a bit more by switching the 775s to NEO 550s as they have a bit higher stall torque. We may get around to that before our first competition if we have time. We’re not pursuing shooting cubes as a primary method of scoring, but we may incorporate it into auto modes, where we have more control of the inflation level of the cubes we use. We may also set our mid-cube scoring to shooting if we can get that one reliable enough, and just use the arm to place them high.

Control System Updates

Our programmers have finally been getting to run their code on our mechanisms, and it’s actually been going fairly smooth. I don’t know if we’ll have as much time to automate as we want, but we’ll definitely have vision-based scoring commands for all 6 possibilities (mid/high/low and cube/cone). That’s our baseline. From there, we’ll have our most basic auto mode score a cone and then go balance on the charge station. After that, we’ll get into the more interesting stuff:

  1. We’re going to plan on 3 “convergence points” in the community, one in front of each april tag. We’ll be able to run a single command to score on any of the 27 nodes from any of these 3 “convergence points”.

  2. We’re going to map multiple “entry points” on the edges of the community. We’ll use PathPlanner to map a path from each of these “entry points” to one of the 3 “convergence points”

  3. The driver will be able to hold a shoulder button as they enter the community area. When we get close enough to one of the “entry points”, we will have the robot take over and run the path to the “convergence point” and then go score on the selected target node.

How do we determine which node to go to? Let me introduce you to our grid button array:

This uses the Adafruit NeoKey 5x6 array, modified to a 9x3 array, each key is RGB lit and yes, it has the clicky keys. This will be the centerpiece of our new button board this year:

The quick rundown of how this works in software, is it uses our existing Arduino USB JSON code we made for sensors, interfaced with a Java console app running on the Driver Station, which sends data between NetworkTables and the Arduino over USB serial. We send a target row and column to the robot via NetworkTables, and that’s how it knows where to score. Will we complete this all before Heartland in 1.5 weeks from now? Not sure, but I bet we do before Tulsa in 3 weeks after that!

From the department of extra software, we’ve also been working on some grid game piece tracking. It’s a bit tricky because it requires a color global shutter camera, which are hard to come by. But we’ve got some code working where we believe we’ll be able to see which nodes have already been scored and which ones haven’t. We’re just using a Raspberry Pi 4 with WPILibPi and AprilTags library in Python for this. From there, we send a grid over NetworkTables. The robot doesn’t read this, but the driver station sends it over to the button board and the grid buttons light up yellow or purple as is appropriate. We’re mounting two cameras front and back to get the best view of the grid for this, and we’ll also be using this setup for our pose estimation corrections.

Other than that, we’ve been working on our existing drive station case to make sure it’s all ready for the season.

The pit crew are finally turning their attention to setting up the pit for competition, and our fabrication team is churning out spare parts. We started our drive practice last week and our goal is to have drive practice every day from now until competition, even if it’s just an hour.

Oh, one more thing, we sent our scouting and strategy students/mentors up to Team #5013 Trobots’ shop on Saturday to practice scouting on some week one events! One of our mentors has made some new comfy seats for the scouters and our strategy team has finalized the match sheet format. Our drive team is very excited to get detailed intel before each match this year!

Hope you all are having fun in your seasons! I’m tired, but starting to catch up on some sleep, I’ll get there eventually!

1 Like

If you’re not sending any data from the robot to the DS, what’s the advantage of using a custom Java client to read the serial data from the Arduino and send over NT? Why not use an Arduino Leonardo or Micro which can be configured to connect directly to a PC as a joystick, and read the buttons on the robot like any other joystick. That way you’re not reliant on the dashboard working to be able to control the robot (something I personally try to stay away from for reliability’s sake)

1 Like

We enjoyed having you over this weekend! Looking forward to meeting you guys again at Heartland and working together to get the best data possible.

Good question! We are actually sending some data from the robot to the driver station, and if you consider the RPi running WPILibPi as part of the robot sending data, then that’s definitely what we’re doing.

At any rate, we considered using an AVR-based Arduino as a xbox controller. However a lot of the functionality of the button board for us is receiving data, most important is the grid gamepiece info (what pieces have been scored on the grid and where). We were a bit nervous trusting NetworkTables for this, so we tested it out and NT4 is very solid for our purposes. The default update is 100ms, which is fine for our button board because our operator doesn’t have any time-sensitive controls. We put all of those on the driver’s xbox controller. For a while, we considered having two arduinos, one for receiving NT topics and lighting up LEDs, and one for the buttons to show up as an xbox controller. But as we continued, we simplified this to just the NT operation because we found it reliable and fast enough for our needs. If in the future we were to ever have time-sensitive operator controls, we’d definitely use an AVR showing up as a joystick.

1 Like

Intake is :fire:

We’re all really pleased with how our floor pickup is working out. We can pick up from basically any angle except the tip pointed towards the intake. Here are some highlights from drive practice:

batting capture
quick capture facing grid
cube capture
quick capture and turn
fast drive capture

Additionally, we’ve been getting our auto-scoring sequences completed and dialed in. This is one command: