Vc-3 on the top, standard blue loctite on the bottom.
Sorry for taking so long with these, been traveling for work and trying to stay off CD. These screenshots are from Elie, the design lead for the hopper. They did a great job with the assembly and it’s one of my favorite subsystems I’ve seen on an FRC robot. A perfect blend of optimization and simplicity in my mind. If you have any questions for them, please ask!
We’re hoping to share the CAD and a fair amount of other resources from the season sometime in the next couple of weeks. Stay tuned.
How does 1678 prototyping lead into design? For instance, in this pooper example, I see 12" between the entrapption stars…why is it 12" and not 11.5" (or some other number)? How did you come upon the use of the entrapption star instead of a compliant wheel? Were the orange kicker wheels an afterthought?
I see a lot of influence from 2910 in Margie (big fan of both! Can’t wait to see the CAD…a dirty version to see the iterations/evolution would be really neat!): Amazon Photos
Going to try to do a more detailed writeup with the students to answer all these questions and show the process, might take a little but we’ll get it to y’all.
It’s this stuff, we just cut some strips and folded it over and riveted it into the 1x1 to diffuse the light. The light is just a simple addressable LED strip.
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.
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.
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.
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.
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.
You can take Dave out of the open alliance, but you can’t take the open alliance out of Dave.
The rate at which the 1678 kids work is just insane. The offseason bots definitely paid off. Do you have a picture of the Rev 6 prototype with the adjustable holes?
Dave and Elie,
Thanks for taking the time to write up the process on the development of the ball transport system, it’s awesome to see the progression of design and where the inspiration for the “pooper” came from directly. I understand 1678 is normally pretty closed off design sharing while during build season, but I hope you consider releasing more write-ups like this in the future after the season is over.
Could you elaborate in more detail Citrus’ offseason training program that gets your students to the point of prototyping such advanced prototypes so quickly?
Thank you for all your posting answering all the questions! It really helps everyone!
Thanks, Justin! I really enjoy working on these with the students and sharing them with the community. I’ll make sure we continue to do them and expand them a little bit, hoping next year we can do something similar to the old 254 build blogs that will get released at the end of the year if the community is interested in something like that.
There’s a ton of content on this topic and I want to make sure that we cover it really well so I’ll work with the students on developing something that lays out what we do and how we run our trainings and start a new thread with them in the next couple months.
Thanks for all of these great details. We are learning a lot!
Can you provide some details on what you have learned with using a motor and gearbox for actuating your intake? We typically use pneumatics for this type of mechanism but have seen several teams using motors now.
What kind of gearing, controls, limits, etc. do you consider with this type of mechanism? Any tips or tricks available?
Already seen your code release on Github.
frc1678/C2022: Code for FRC Team 1678’s 2022 Rapid React robot (github.com)
Can’t wait to see your cad and scouting white paper released!
JK, very excited to see the CAD!
I’m excited, but I’m also worried
Hope the playoffs won’t be full of 2910 and 1678 machines
Oops! That’s not good.
They may upload it again
I meant may 28th is tomorrow.
The code and CAD release should be later today, thanks for your patience as our students wrap up some of the last details for the release.