Crescendo Molto
Build Season Week 1
Intro
Hope you all had a great first week of build season! For our first week, we spent some time planning and prototyping our arm system and intake. We also built a first prototype of our shooter and tackled some other in-game issues such as AprilTag vision.
Vision Programming
This year, we seek to use AprilTags to implement automated speaker scoring from various distances. In the midweek, we looked at using photonvision with orangepi 5s, similar to 6328’s solution last year except without a custom implementation. We used Arducam OV9281 Cameras, began testing without simulation, then in hardware attached simulation, and finally on the robot. Going from a limelight last year that seldom could detect the tags, we found this system to be a massive improvement that we plan to utilize this year.
Video: Apriltags being detected across a room (>25 ft)
Video: Testing how motion-sensitive the 120fps global shutter cameras are
Conclusion: very reliable motion tracking
Not recorded but we also tested multi-target tracking with motion and had consistent results with a live-demo at one of our virtual meetings.
We then added the orangepi and camera onto a jerry-rigged board with a VRM to power it onto the base of our last year robot, Luxo.
(We aren’t getting new swerves, so we have to salvage them from somewhere!)
After attaching some of the corner mounts that 6328 had last year, we then drove the robot around a bit with a fixed apriltag to see its results (no media was recorded)
No concrete conclusions could be made, the tracking software for localization needs to be updated more before it can be fully utilized on a bot.
Archetype Considerations
If we wanted to be self-sufficient in earning ranking points, especially in endgame, earning the TRAP points is a necessity. As such, we realized a one-degree-of-freedom arm would not suffice. We then started to think about a two degree of freedom arm with a pivoting wrist in order to score into the trap, which would mean we would need a higher left in order to score. 
One degree of freedom arm, Quokkas style
Two degree of freedom arm, can score trap as long as it picks itself up a considerable distance
148 2023, Pivot + Elevator + Pivot
Can score trap, needs a secondary lift mechanism, unsure about stability at the end effector to creating repeatable shots
We then considered other archetypes such as the davidbot, or Robot (CAD) in 12 hours
While we liked its simplicity, we were unsure of the rigidity we can achieve with an elevator, the handoff, and adding another motor for indexing for the handoff
We then looked at 342’s 2024 design
It solved a few of our issues, most notably that the shooter was separate, allowing for more rigidity in the shot.
One of the most notable downsides was we would need to figure out how to rotate the arm 180 degrees about the carriage, while still maintaining the required rigidity
We then discussed taking the Quokkas design of a mixed shooter-intake combination, put onto the 342 archetype. While the arm would then not need to rotate a full 180 degrees, only 90 at most, it still has the variability from an elevator’s rigidity, which we have never manufactured properly in the past.
As we were looking at rigid elevator designs, we stumbled upon 3538’s 2018 robot, which had a cantilever intake/shooter from a sideways elevator. This solved the problem of having to maintain a rigid elevator, while being able to rotate 180 degrees.
Our technical captain then stayed up until midnight (by his own choice) to make a master sketch of what this would look like.
It has ground intake, source intake, trap, intake is rotating about on an elevator, which passes off to a fixed position shooter
For amp scoring and for trap scoring it runs the intake in reverse.
There are fixed hardstops which allow for a static position to work well.
We also are looking at adding forks to balance the robot while it climbs.
Currently, we have scrapped the arm as we have that an elevator would be able to reach the trap way easier, not needing a separate mechanism to lift.
Moving into the week we are also looking for rigid elevator designs. We are thinking about using linear slides as opposed to elevator blocks for their simplicity in implementation. The debate about cascade vs continuous is leaning cascade, but we haven’t decided anything finalized.
We HOPE to finally select our final archetype this Tuesday so then programming and design can get started on the rest of their season tasks.
Prototyping
Because of our student limitations, we seek to prototype the bare minimums that we can’t find from researching the open prototypes of other teams. We prioritize a more informed research/prototyping decision as opposed to building a lot, and then using a little, maximizing our leadership, resource, and time constraints.
Intake
For our intake, we originally wanted to do an intake and shooter hybrid, but now we are more in favor of Cranberry Alarm’s Robot in 3 Days intake which uses two rollers driven by belts to pick up notes.
Image is of Cranberry Alarm’s RI3D bot, image was taken from this video
An intake like this is also very easy for us to prototype with as we can use our 2023 robots intake. Here are some videos of that in action:
We decided on this intake because of how easy it is to use and how effective it has been proven to be. This archetype is not final, and we may go back to old ideas.
Shooter prototype
During our weekday Discord meetings, we decided that we wanted to build a shooter loosely based on the Ri3D Unqualified Quokkas shooter as our first prototype. Our main reasoning was to allow ourselves to adjust compression on the note from the flywheels easily.
Intake without the flywheels. Pretend there is a hex shaft with flywheels in each of the bearings’ slots. The shooter was designed for 4in wheels with adjustable compression and 2in feeder wheels
We cut out the prototype polycarb plates using the CNC machines, and we attached another sheet in the cutout slots, although we don’t have a plan on attaching that firmly just yet.
After attaching the motors and some programming, this is the result:
While we achieved the ability to shoot, there is much room for improvement. Variation is obviously the biggest problem right now. One cause of that could just be human feeding error (as we are feeding by hand for now), or the fact that the hex shaft is subtly oscillating up and down during the rotations. We could partially alleviate the problem by placing the initial flywheels slightly higher to reduce drag. Either way, we hope to achieve consistency in the coming weeks.
Human Player Training
Sometimes we have more people than tasks, so in that case we decided to set up a little human player training station for students to see how well they can score in the microphone! (With varying degrees of success… so far, very few members have achieved 10% accuracy)
Check out our raw, unedited human player throwing ideas here!
Conclusion
It has been great initial progress so far! We hope to further refine our shooter and get started on the arm/intake for next week. In the meantime, we will update you on everything that happens, and as always, please reach out to us if you have any questions!
Michelin Man if he was orange (side-by-side for comparison)
Best wishes,
Team 1757
Post written by: Baili, Liam, Luke, and Rachel.
Edited by: Sean and Baili
unfortunately couldn’t find where it originally came from ) and presenting:
. But we’re getting there!!!
