Hackster Classroom for Teachers and Parents: Getting Started with Robotics 2 – Competition Robotics

There are many different ways to build robots to compete, either with friends or in large competitions that draw people from all over the world. In Part 1 of this article we went from zero to small Arduino-driven level robots with a few sensors. In this piece, we talk about the competition opportunities for middle- and high-school students, and ideas for teaching sophisticated engineering concepts to students out of the normal school sequence.

Going from little Arduino robots to competitive robotics at the high school level or above is a big step. These robots often need to be built by a team, and will interact with a complex game field and one or more other robots. Some of the biggest challenges are learning to plan and build complex systems, to learn math or engineering concepts “just in time," and to put rudimentary configuration control in place to have orderly builds. Some robotics teams are associated with schools, and some are “community teams” that perhaps meet at a sponsor’s facility evenings and weekends. If you are thinking about starting a team or getting involved as a parent or mentor, here are some of the things to know.

Types of student-focused competitions

We mentioned FIRST Robotics (which stands for “For Inspiration and Recognition of Science and Technology”) for its LEGO League beginner competitions in our last article. Here, we will take a look at its FTC (FIRST Tech Challenge) and FRC (FIRST Robotic Competition) programs. Both of these programs have a game that changes from year to year. Games consist of a period where the robot is autonomous, followed by another where the robot is controlled by its student team. Notably, unlike combat robots, the robots are not allowed to damage each other deliberately. Instead, the robots are programmed to achieve a goal and in some cases cooperate with other robots autonomously.

FTC robots play two-against-two games, and FRC has alliances of three-against-three. In both cases, these alliances are randomly assigned at competitions for qualifying matches, and determined with a complicated seed system in final rounds. FTC robots are smaller and have some constraints on the parts that can be used, and are suitable for middle or high school. The 2025 season that just ended had a game that required precise placement of game elements on the field, with bonus points for making the robot lift itself onto robot monkey bars at the end.

FRC is high school focused, and realistically requires access to machine tools and other resources. FRC robots are typically much larger than FTC – around 125 pounds or so – and have standards for the electronics, safety features, dimensions and weight, but otherwise are pretty much open builds. FRC games can be quite complex. In the 2025 season that just ended, robot alliances needed to place pieces of PVC pipe on protruding metal pipes at various angles, manage large rubber balls, and hang from cages at various heights, as described in the kickoff video. Each year, the game is revealed in early January. Competitions start at the beginning of March, allowing only about six weeks of “build season”. There are also subjective awards focusing on both the robot and the team’s interaction with its community.

Another program, VEX, has many different divisions, from younger kids through university levels. Their competitions either have a team of two robots working cooperatively (fourth through eighth grade) or competing in alliances of 2 against 2 (for sixth through twelfth grade). Flexibility on robot build varies by division, but it is in general fairly constrained in what can be used.

All of these options have a mix of autonomous and human-driver play. If you want a robot competition with no real-time human interactions, an option might be Botball. Their competitions require robots to be completely autonomous.

There are also competitions for underwater robotics like MATE ROV which add the complexities of building for underwater play. For more general engineering competition for students, there are competitions to build and race solar-powered cars, such as the American Solar Challenge. And of course, there are other competitions aimed at battling robots, like National Havoc Robot League (NHRL) which are designed more for individuals or ad-hoc teams, rather than being school focused.

Most of our competitive experience is with FRC, so the comments that follow are based on our experience there as mentors and competition judges. We will note that these are our personal opinions, and not reflective of any official policy of a team, school, or robotics program. Other programs may be a little different in the details or difficulty level, but similar challenges will exist.

Learning systems engineering

These competitions dump students headfirst into a realistic embedded-systems engineering environment, layered over with all the drama of who is going to the prom with whom. Many times the teacher assigned to coach has not been in an engineering environment themselves, which adds to the challenges on startup. A basic system engineering process is not all that profound, but there are a few key elements that make things go better.

We have found that a few case studies can be helpful before the robot competition season starts. One warmup exercise can be creating an Arduino-level robot, but the physical integration of one of those is so much simpler that it might not be all that helpful. It is, however, an introduction to building a hardware/software system.

We sometimes describe a “systems mystery”, talking through a real engineering failure that had a surprising cause. Henry Petroski’s books, most notably his classic To Engineer is Human (Vintage: 1992), are a good source of stories. Teaching about infamous failures can help students get past the assumption that if they build something to a specification that it will work. Tolerances, unknown unknowns, and software/hardware interactions can be a shock. Constructing a problem that will cause a surprise failure (unless that happens before you need to stage it!) is a good tactic to make everyone just a little paranoid and willing to have margin on their designs.

Students also often only design hardware and write code for the expected cases. When inevitably the robot encounters something outside the box, results are... interesting (at best). Even in professional environments, people may bristle when asked how their subsystem might fail. Students, with their limited experience, might not be able to anticipate possible problems and plan for graceful failure.

We like to teach the case of Abraham Wald, a statistician working during World War II. He was asked to assess the best way to protect Allied bombers from fatal damage during flight, and developed the concept of survivorship bias. It’s a complicated story (maybe worth its own column sometime). Check it out at the link if you want to learn a classic failure analysis story about asking the right question to figure out a failure (and prevent future ones).

Finally, the hardware and software for competitive robotics are developed for a very limited specialized market, often by volunteers in whole or in part. As such, documentation and reality may not match, and the systems can be flaky. Students usually click over after a few weeks from never assuming that the hardware and software they have bought can be buggy, to assuming that all problems are arising from the purchased components. The truth, of course, lies somewhere in-between. Coming up with simple, unambiguous unit tests (like having the robot drive a one-meter square clockwise and counterclockwise after every major change) is absolutely key.

Teamwork

Working in a team is also usually new for students on robotics teams, particularly when different team members are responsible for different things. It can be easy to forget that these are still young students with school social dynamics going on outside the robotics lab. As a minimal organizing principle, the people making large and complex metal parts need to work in a space away from the people trying to focus on creating code and game strategy, but not so far away that they become disengaged from changes to robot hardware or capability.

Some sort of age-appropriate process is needed to figure out what the robot is going to do and how it is going to do it. After that, a rough schedule needs to be developed (and monitored), people associated with tasks, and tests defined along the way. Some teams use project management software, but a spreadsheet is probably sufficient for most teams.

Different programs vary on how much adults are allowed to intervene during the build process. Even when adults are allowed to wade in (as is true in FRC robotics) different teams have varying philosophies about how much is too much. Older students will typically mentor younger ones, with high school seniors handing over knowledge to their sophomore and junior replacements. Not all students will be very effective teachers, however, so this poses other challenges.

Mechanics

To this point, we have talked about attitude and organization. But what about learning the technical part of robotics? FRC has a basic “kitbot” with instructions that will guide you through making a decent, but not likely award-winning, robot. It is a part of the Kit of Parts sold by vendor AndyMark that teams have an option to receive at the start of the competitive season. The kitbot documentation talks about what kinds of tools you need (some hand tools, at least a drill, and ideally a drill press; also, the ability to cut metal, at worst a hacksaw). Realistically, you will need either some access to machine tools, or cash to vend out some work to a service provider like SendCutSend.

In a school environment, typically there will not be time or resources to do much stress modeling, but weight limits mean robots can’t be totally overbuilt either. Some rational set of prototypes is needed to figure out how hefty parts need to be.

To vend out parts or use CNC tools, the parts will need to be designed in a CAD program. Teams use various programs depending on school heritage. If you have no constraints, there are prefabbed design libraries for the Onshape CAD program. (Check on educational license discounts before subscribing.) One such package of designs, KrayonCAD, also has tutorials and other resources on its site, and it might be particularly useful for a startup team. That said, if you are a brand new coach starting up a program, the best thing you can do is to find another coach at a nearby school that will let you drop by or ask questions (or even borrow a tool now and again).

Electronics

For compatibility with their playing fields, robot competitions typically specify a standard processor unit and radio, and often other controllers and power distribution hardware as well. At the moment, FRC uses a proprietary processor from National Instruments called the RoboRIO, but will be going to a new processor unit built around a Raspberry Pi Compute Module in the next few years. This new processor will also be phased in for FTC, which will enhance FTC as a training ground for FRC.

Most devices on an FRC robot are controlled over a CAN (Controller Action Network) bus, typically used in automotive applications. The CAN bus interface is of course different from using an Arduino and a few motors, and learning about CAN takes a while for newer recruits. FRC has these resources for learning about wiring up a robot and installing software.

The RoboRIO expects 12 volts (provided by a 12V battery of the type used for electric scooters). This means that 5-volt and 3.3-volt components meant for Arduino-type processors need to have hardware stepping the voltage down.

Students will need to learn to select and build wiring assemblies appropriate for various power and signal cables, usually involving crimping connectors and sometimes soldering. They will need to learn what gauge and type of wire to use for which application, and some rudiments of anticipating current to avoid blowing out fuses.

Software

FRC software runs on the robot and on a laptop called the “driver station.” The driver station sends joystick commands and receives telemetry during competition. (In the current system, this computer has to be a Windows laptop, but code can be developed anywhere Microsoft Visual Studio can run.) The RoboRIO can accept C++, Java, and recently Python. There are many other ancillary bits of software running on motor controllers and vision systems that also need management, as well as integrating data from sensors.

Software requirements for FRC have become progressively more sophisticated. In addition, the robot hardware is typically being built in parallel and is ready for software testing sometimes days or less before competition. These days, vision co-processors are common, and take time to develop and tune.

To have any hope at all of having something working, testbeds and simulators are a must. Fortunately, there are many tools (most of them student-developed and released open source) that work with varying degrees of stability. There is really too much material, some of it high quality, some of it not quite ready for prime time, and almost all of it with little or no documentation. An official simulator exists to test some functions.

Many teams use GitHub to manage their software, and we highly recommend that as a baseline. GitHub is widely used to manage open source projects; there are many getting-started tutorials. On some teams, only a software mentor can push changes to the GitHub repository; on others, a student software lead manages it. Have a clear policy about how to handle changes to the main tested branch and get all the software developers comfortable with GitHub’s practices.

Student startup

All this can seem pretty overwhelming. What can you give a new student (or adult mentor) to walk them into this more gently? A new small robot that bridges FRC and Arduino-level robots is the XRP, sold by Sparkfun and Digikey. Software that could be uploaded to an FRC robot can instead be run in a simulated RoboRIO, with the XRP's onboard Raspberry Pi Pico W acting as a wireless I/O bridge. The motor controllers and sensor hardware are different, but with the right translation layer, you can (at least in principle) test your FRC robot code on the XRP. It is more or less a hardware version of the software simulator mentioned earlier. As a bonus, Prusa Research’s Printables site had a contest to develop add-ons for the XRP. These add-ons might be fun things to try out as training exercises before students dive into something the level of a kitbot.

The model comes in two forms: one with all the parts, and a cheaper DIY version that assumes you will 3D print the mechanical parts yourself. We purchased the latter one, and 3D printed the chassis and little robot arm shown in the photos. It was reasonably straightforward for us. As for students making one work, Sparkfun donated a DIY kit for us to pass on to a nearby team impacted by the Altadena fires. We’re looking forward to hearing how they decide to use it!

The intent is that the XRP can support students getting comfortable with the programming environment for the big robot, and gets them used to allowing for mechanical imperfections in programming a robot to move. It also helps them think about how to align movement of an arm on a moving platform. Then, when they are hit with all the complexities of the bigger robot, at least the coding environment and libraries are familiar.

Math

Students on a robotics team may have barely learned basic trigonometry, and yet they will need to understand complicated coordinate transformations. Inverse kinematics defines the movements needed by robot components to get, say, the end of an arm to a particular point in space. It is a trigonometry-heavy exercise, and students need to be walked into it carefully. To make things a bit more scary, different systems (like off-the-shelf vision systems and the main robot control software) may use different coordinate conventions.

Similarly, basic concepts of calculus, like a derivative and integral, are very helpful for understanding algorithms used frequently in robotics. But it can be tricky to avoid getting lost in definitions and algebra when teaching out of the normal sequence.

One way to make this work is to teach these concepts hands-on so that students learn enough to follow code library examples. Our Make: Calculus book teaches the basics of integrals and derivatives using LEGO bricks and goes on from there. Our Make: Trigonometry book creates a simple robot arm and discusses basics of inverse kinematics. All of our math books can be found in the Maker Shed.

The new Make: Robotic Arms (2025) book by high school teacher Matt Eaton teaches inverse kinematics hands-on by building a series of progressively more complex arms. There is also an associated kit in the Maker Shed. These might be good projects for pre-season learning.

And more...

There are many other considerations for an early-stage robotics team, such as safety training, insurance issues, and of course raising money. If you have read this far, let us know what issues you would like us to dive into more going forward. Talk to us on the Hackster Discord channel (use this invite if not in the group already) in the #-educator-parent topic and let us know what you need to learn. Check out our previous Hackster Classroom articles at hackster.io/nonscriptum. And if you would like to be a mentor to an FRC team near you, check out firstinspires.org to get more information on being paired up with a team that needs you.