During my senior year of high school, I led my FRC robotics team in designing and building a complex "Traversal Climb" mechanism for the 2022 competition, one of the most challenging endgames in FRC history. I applied lean startup principles to rapidly prototype and iterate on the design, focusing on creating a mechanism that could consistently climb a series of bars in under 15 seconds. After testing, refining, and adding sensors for semi-autonomous control, we optimized the system to climb in under 7 seconds. Despite initial setbacks, we achieved a 90% success rate by the final competition, outperforming many teams. This project emphasized the importance of quick learning, collaboration, and problem-solving.

During high school, I was deeply involved in my community-based FIRST Robotics team (FRC), eventually becoming team captain in my senior year. That year, the FRC season started in January and ran through mid-April. With a light academic load in my final semester, I dedicated about 30 hours a week to the team—far more than any other student. I was always the first to arrive and the last to leave each meeting, also putting in extra hours outside of the shop to work on CAD and research. My goal was to build the best robot possible for my final season, but I couldn’t do it alone. I focused my efforts on designing the endgame mechanism for that year’s competition, which involved climbing a series of bars resembling monkey bars. This challenge, known as the "Traversal Climb," was one of the most difficult endgames in FRC’s 30-year history.

I applied principles from the Lean Startup methodology, knowing that we had limited knowledge of the challenge and our own capabilities. I defined success as completing the climb in under 15 seconds with a success rate of over 90%. We began by prototyping different geometries and orientations for the mechanism. After consulting with mentors and the team, we decided on a design featuring one active arm in the center of the robot and two passive hooks to latch onto the bars, allowing the active arm to reach for the next bar.

We quickly prototyped the mechanism using 80/20 aluminum extrusion and a wooden sled, which helped us identify potential challenges, such as mass distribution issues and areas where the design might fail. Initially, the design used two motors—one to hoist the robot and the other to rotate the arm—but the motor controlling the arm was slow and would require either hard stops or an encoder to control the movement. To simplify the system, I decided to replace the motor with a pneumatic cylinder, as it only needed to move between two positions.

Once the new arm iteration was complete, we encountered another problem: the passive hooks weren’t resetting quickly enough after each bar. A teammate suggested adding springs to help them snap back into position faster and prevent them from getting stuck on the bars. This solution improved the system, but we still had issues with the bar getting caught on the wrong side of the hooks due to the robot swinging like a double pendulum. To solve this, I extended the hooks' geometry, making it physically impossible for the bar to get stuck.

With the mechanical design mostly complete, we focused on adding sensors to make the system semi-autonomous. The game rules allowed for human control during this phase, but we knew an autonomous system with some human oversight would be more consistent, given the poor visibility during the climb. After consulting with the drivers and programmers, we added limit switches to detect the climber’s state. The programming team then created a system where the driver could simply press one button, and the robot would automatically complete the climb in about 14 seconds.

A week before our first competition, we tested the mechanism about 20-30 times, refining it and creating a pre-match checklist to ensure everything was functioning properly. This checklist included inspecting the rope for fraying, checking the alignment of the slides, and replacing certain components after every three matches. It ensured that any team member could perform the checks, even if others were busy.

At our first competition, we completed 14 matches and successfully climbed in 11 of them—falling short of our goal. During our debrief, we identified two main issues: a limit switch had broken off in two matches, and an electrical issue caused us to miss the climb in another. We quickly learned that hot glue wasn’t strong enough for a 120 lb robot and switched to using epoxy. We also experimented with 3D-printed brackets, but found epoxy to be more reliable. Additionally, we added a manual override button for the climber, allowing the driver to control it manually if the sensors failed. To address the electrical issue, we limited the motor current in firmware to prevent brownouts.

After these reliability fixes, we worked on speeding up the climb. By the time we reached our final competition, we had reduced the climb time from 14 seconds to under 7 seconds. We completed 13 out of 14 climbs, missing one due to a disconnected battery cable caused by an opponent robot, which resulted in their disqualification. At this competition, only 15% of robots attempted the climb, and ours was one of only three to successfully complete it in over 90% of our matches.

This experience taught me the value of quick prototyping and continuous learning. My team and I accomplished something that many other teams couldn’t—not because we had more resources, but because we learned more about our own capabilities and the task at hand.