League Meet 2 Post-Mortem

By Aarav, Krish, Jai, Sol, Tanvi, Alex, Vance, Georgia, and Anuhya

Task: Analyze our performance at our 2nd League Meet

After our performance at Meet 2, Iron Reign sat down as a team and discussed what happened. Here’s an overview of our takeaways and next steps as a team, divided into our strengths, weaknesses, potential threats, and opportunities/next steps.

Strengths:

• Our autonomous scored the purple pixel consistently when set up correctly. This significantly helped us with the tiebreaker and is a significant reason for our high ranking.
• When it worked, the field-oriented drive was quite helpful and simplified things for the drivers.
• When the robot functioned in tele-op, we could consistently and accurately cycle pixels to the backdrop.

Weaknesses:

• The transition to Teleop was unreliable because of a code bug we could not fix during the meet. Late code changes near our queue-up period meant we could not properly test them, and because of this, we sat still in Teleop for the last 3 matches.
• Over the week of the meet, we burned through about 3-4 servos for the intake lift. We kept shattering their gearboxes through hazardous driving and not correctly setting up the robot. This isn’t sustainable, and we currently don’t have the budget to replace servos as they get destroyed.
• Our init cycle at the beginning was too long and held up a couple of our matches, and we needed to remain aware and properly reset our robot each time.
• Sizing remains a problem, mainly because we have little room for error. Even when our lift was slightly out, we failed to size and held up a match because of it. We need to focus more on sizing in the next iteration of the robot instead of being an afterthought until the night before a meet.
• When we traveled under the door, the Scoopagon ran the risk of getting caught under the door if it was not entirely down. A way to combat this would be to create a travel position for the Scoopagon that can be toggled when moving under the stage door.
• Wire management and the packaging of the robot are also issues with the current robot. The Scoopagon will often get stuck on the surgical tubing holding up the intake, the lift will de-spool, or wires will get caught on the chassis and unplug our servos. Issues like these end our matches, but we can fix this with a robot that is designed and visualized first.
• Finally, in general, we have been behind as a team, especially on CAD for the next version of the robot, and that means more people getting involved to support our design efforts so that we can have the next version of the robot by Meet 3.

Threats:

• Our slow progress on V2 of the robot due to a lack of design participation.
• There are fewer connection opportunities than in years before at this time.
• A lack of funding, especially with the need to build an entirely new robot and deal with broken servos.
• Becoming complacent with documentation and completing the portfolio at the very last minute.
• Not expanding our industry connections and using them to get advice on our robot design.

Opportunities and Next Steps:

• We were able to get the hanging mechanism functioning the week before the meet, but we could not get it working at the meet. Specifically, it needs more angled support bars, and the motor placement needs to be redone, as they keep messing up pixel transfer. However, it did serve as a proof-of-concept, and we can adapt the same concept to the lift for the next version of our robot.
• We could also experiment with a kinetic lift that uses the momentum of the robot instead of motors.
• Similarly, we had a drone launcher that could score points the week of the meet, but when we attached it to the lift mechanism, it conflicted with the outtake and was too heavy. However, the concept is a strong starting point for incorporating a drone launcher into the next version of the robot.
• The Scoopagon hinge currently wiggles and is not stable, so we need to replace it with a stronger material, such as carbon fiber.
• A second hinge to allow the outtake to tuck away in a position that doesn’t interfere with as many components.
• A new custom-designed chassis that is not built on rev rails and is lighter/faster will decrease our cycle times. It will also be designed with the complete robot in mind, helping deal with some of the packaging issues we have been facing.
• A swerve drive is an idea that we could implement later in the season for maneuverability.
• Adding the yellow pixel drop-off to our current autonomous routine
• Automating driver paths and the intake/outtake articulations to reduce errors caused by the driver
• Earlier and more consistent driver practice. This is important with a more straightforward game that requires robot performance.

UPDATE: We did find out what the code bug was that messed up a couple of our matches. It was an error in the transition between the autonomous state and the tele-op state.