Here’s an overview and case study of how 1678 prototyping can lead to our final design. I worked on this with Elie, the lead designer for the hopper subteam. It’s a little long, but tells the story of the hopper design iterations and talks about the process a bit. As always, feel free to ask any questions.
Alpha
When starting our looking at concepts for game piece manipulation, we know the easiest way to brainstorm ideas is to look at robots from the past. This past year was no exception. A shooting game, with a similar game piece, led us to look a lot at robots from 2020. When starting out, we always push for simplicity in design, and after getting smoked at a few offseason events by 973, their robot was an obvious choice to study to see how they did different elements of the game. Their hopper and indexing system in 2020 was simple, elegant, and easy enough for us to replicate for our alpha robot.
The Alpha robot was born out of a desire to be able to quickly combine different prototypes to better understand how the game will be played. We know the sooner we can start practicing, the sooner we’ll learn about how the game is played, and we’ll know exactly what we need to focus on and optimize, and what we can get away with keeping very simple and won’t really matter in gameplay. After seeing how good the 973 hopper was, we jumped very quickly over to designing our own version using wood and stuff we had to lay around the shop, here are a few videos of some of the early prototypes.
Rev 1
Rev 2
It’s easy to see over the course of the 2 videos we slowly kept making small improvements and adjusting dimensions and trying different belts to get a better understanding of what would work and what wouldn’t. Once we had a good idea of major dimensions, we quicked hopped back into CAD and started working on a higher fidelity prototype. This all happened pretty quickly so I don’t have a picture of it being built, but here’s a picture of the Alpha hopper that has been completed, and the first iteration of the shooter prototype is mounted on the top of it.
And here’s it bolted on the robot about day 7 or 8 of build season.
I think at this point it’s important for me to emphasize that a ton of training goes into being able to turn something over this quickly. For me, I think offseason training is one of the pillars of Citrus’ ability to get the students to the point of having a good enough knowledge base that they can develop a prototype like this mostly on their own. The build season is for executing the plan, not developing it.
Back to the question at hand, from here we have a prototype robot that is working well enough utilizing decently little hard testing of ideas. Just going off of designs from the past, the team quickly built something that could play the game. From this point on we’re basically running driver practice and software development for the rest of the season. Using all the stuff we learn from both driver practice and running autos, we were able to come up with a better understanding of what we did and didn’t need to focus on.
Beta
After finishing up Alpha, we pretty much immediately knew we were going to need to pull more performance out of the machine. Specifically, with the hopper, we realized how much of a time suck it was for us to filter out the wrong color balls, and how big of an issue it would be in the long run. We also knew that being able to continually throw the opponent’s cargo around the field would be very frustrating for them. We didn’t have a solution yet, but the understanding that this could be a piece of the game we could optimize was there.
A couple of days later, while sitting at work one day, one of the engineers (@aphimm) that works with Matt, Mike, and I (who is a Citrus alum 
) mentioned a robot from the VEX game Change-Up, the robot had a pooper!! Here’s the video he showed us, we brought the idea up to the students, and we all knew it was something we needed to implement into the robot.
Going off all the lessons learned from Alpha, we started working on the Beta robot, the original intent of this robot was to be able to fit the new climber concept (shout out 125) which drove the need to change the architecture of the robot a fair bit. Here are a couple of photos of the Beta robot prototype, with the first swing at a pooper, and a pneumatically powered flap that would swing up to let the balls pass out of the back of the robot.
After a couple of iterations of this prototype, we quickly moved to designing and building the one for Beta, this took about a week of CAD design work, which I don’t have many progress photos of, but here are some pictures of the subassembly actually getting built.
Here’s a quick video of us just running balls through the robot.
And here’s where we started to see the issues with our design. So thankfully, with this high fidelity prototype, we were able to add in some sensors and software to start simulating and testing more accurately. Once we got the software loaded on and tuned, it became very apparent that the flap would not be able to actuate quickly enough. Here’s a video where you can clearly see the ball moving past the flap, then it actuating. We tried relocating the sensor and a few software tweaks, but in the end, it was very apparent it was not quick enough. Into the trash, it goes!
From this point, we started discussing different ideas to obtain the same results without needing to utilize something that was pneumatically actuated. During one of the brainstorming talks, the idea of just trying to find a way to simulate a gate utilizing a wheel spinning in opposite directions depending on what path you wanted to go in got floated around. Going off this idea, we quickly built this prototype concept to see if you could divert the ball using just some wheels. I’m not entirely sure where the star wheels came from, but I assume it made sense given the wheel’s ability to comply and keep in contact with the balls for longer than if it was just a single roller. Here’s the prototype, a simple concept, that proved the point.
As you can probably guess at this point, we jumped back into CAD and started working on designing a high-fidelity version of this prototype. Here’s a quick video of that in action. The prototype was just two pieces of sheet metal, which some standoffs, and is being driven by drills. We actually built in some adjustments into where the main driveshafts were mounted, so we could adjust them in different directions to see what worked best.
Once we were happy with the spacing, we jumped back to CAD and started working on developing the final design.
Epsilon
With the Beta robot getting scrapped due to us ditching the climb, we had the ability to really optimize a few small things that helped us increase the performance of the robot. We took advantage of the full rebuild to lower all of the motors into the belly pan to lower the center of gravity and optimize the geometry going into the shooter. With that, we ended at our final design, which you’ve all seen but here are some assembly and testing pictures and videos to wrap up the post!
I hope this shows a little bit about the process 1678 and the students go through to develop a subsystem, not every subsystem will get this many revisions, but some might get more. I can’t express enough how great the Citrus students are in understanding that this is an iterative process and you need to fail as fast as you can to learn what you need to do to make it work.