Designing & building a robot

The Task

I founded and camtained my high school robotics team for all 4 years of high school, and took on the role of build lead. As such, much of the design of our FIRST Tech Challenge robot became my undertaking. This is the story of the entire process, from the initial strategy to the final robot.

The Competition

Our team competes in FIRST Tech Challenge, a robotics competition for high school students. The game is played on a 12’ x 12’ field, with two alliances of two teams each. Each alliance has a robot, and the goal is to score as many points as possible by placing wiffle balls in goals. The game is played in two rounds, with the winner of each round being the alliance with the most points. The winner of the match is the alliance with the most points after both rounds.

This post is written about the 2021-2022 season, called Freight Frenzy. This is the official reveal animation, giving a thorough breakdown of the competition at hand.

The basic gist is there are Whiffle Balls and 2” orange cubes that have to be moved (one by one) to an elevated basket. The challenge lies in the fact that there is a barrier between the balls and cubes (“shipping elements”) and the basket (the “goal”). There are narrow gaps on each side, and the barrier is composed of 2 polycarbonate pipes that are just high enough to be a challenge.

From here on, the article assumes you have a functional knowledge of FIRST Tech Challenge and of the season.

Project Management

We followed the standard engineering design process when designing our robot:

Problem Definition

As the entry to our cycle and the most important phase in project management, we had to define our problem, which starts with defining our goals and our constraints. Simply put, the problem definition is our initial understanding of the task we are attempting to solve. On our team, this often comes as watching the game reveal animation and our first look at Game Manual part 2.

Goals

• Score as many points as possible (obviously)
• Be built completely in-house
• Be extremely reliable
• Be a good example for the team moving into the future

Constraints

• Size A maximum drivebase size of 14x14 inches. – the small size allows us to skirt around many of the obstacles around the field, so (even though we are able to handle the obstacles) we do not have to, and it allows us to add small mechanisms that can overflow the edges without violating the maximum size.
• Maneuverability We have used Mecanum wheels in the past and have grown comfortable with the superior maneuverability afforded by the multi-directional driving, so decided to stick with them.
• Access Obviously we have to get into the space behind the obstacles, so we wanted a robot that could both go around the obstacles and go right over them, hence our auxiliary wheel system.
• Speed Each year we have massively increased our speed potential, this year we are using 435 RPM GoBilda YellowJacket motors as our drive motors, connected to our primary wheels with a 1:1 ratio. We have discovered this is the highest speed we can go while staying within the YellowJacket family while still having enough torque to move our robot around easily.

Gathering information

Getting a more in-depth understanding of the challenge through thoroughly reading GM2, and using the one-page game description to plot each task based on point value and perceived difficulty, giving us a roadmap of our priorities. Read more about this process in our game strategy section.

Concept development

Regardless of position on the team, every member is given a stack of note cards and a pen to draw a brief sketch of their ideas for how to solve each task. Once an idea is chosen or developed, the team discusses the mechanism, pros and cons, and assess the build, programming, and driving complexity.

A huge part of concept development is strategizing how we want to break down our problem. The task of building a robot is a monumental one, taking several people multiple months, so it is critical that we know we are working in the right direction.

Our team uses a point value vs. percieved difficulty graph: