Building an Autonomous Robot for the 2026 Premier Robot League

I participated in the 2026 Premier Robot League, held in Korea. The competition was based on an autonomous-mode version of FTC — FIRST Tech Challenge, using the DECODE game from the 2025–2026 FTC season.

The challenge was simple in concept, but difficult in execution: our robot had to shoot a ball into the goal automatically, without driver control during the match.

Starting with CAD

Before touching any hardware, I started by modeling the robot in Onshape.

Because this was an autonomous-only competition, every mechanism had to work reliably without a driver correcting mistakes in real time. That meant the robot needed to be as simple and predictable as possible from the beginning.

Day 1: Building the Drivetrain

On the first day, I started with the drivetrain. I attached two wheels to the bottom of the robot and built a simple structure that could drive forward and move into position.

I kept the drivetrain minimal on purpose. In autonomous matches, a complicated drivetrain often means more possible failure points — and if something goes wrong mid-match, there is no driver to fix it.

Designing the Body and Ball Path

Later that same day, I moved on to the main body of the robot. This structure needed to support both the ball intake path and the shooting mechanism.

I built a box-shaped frame on top of the drivetrain. The frame had to be tall enough to fit the motor and shooter inside, so I designed it like a vertical chute where the ball could travel from top to bottom.

I chose this chute shape instead of a flat shelf because I wanted the ball to fall into the shooter by gravity. That way, the robot would not need an extra mechanism just to move the ball into position.

Aligning the Entry Hole

I also cut a circular hole in the top panel. This hole is where the ball enters the robot, so it had to be aligned with the shooter underneath.

Getting this alignment right took a few tries. If the hole was even slightly off-center, the ball would hit the wall of the chute instead of dropping straight down into the shooter.

Day 2: Designing the Yaw Mechanism

The next day, I designed the gear system that would control the yaw angle of the shooting mechanism.

The goal position stays fixed, but the robot’s starting position can change slightly between matches. Because of that, the shooter needed to rotate left and right to correct its aim.

Instead of turning the entire robot to aim, I decided to give the shooter its own rotation axis. This made the aiming process faster and reduced the burden on the drivetrain.

A servo sits inside the frame and drives the gear directly. The gear then rotates the shooter to the target angle.

I chose a gear-driven yaw system instead of mounting the servo directly on the shooter axis for two reasons:

• Lower moving mass: keeping the servo off the shooter made the rotating assembly lighter.
• Better protection: if the shooter jammed, the servo would be less likely to take a direct hit.

Assembling the Gear System

I designed two gears because the yaw mechanism needed a pair of meshing gears to transfer rotation from the servo to the shooter.

I also added a small ring of mounting holes near the center of each gear. These holes allowed the gears to be bolted securely onto their shafts, preventing them from slipping under load.

Once the gears were finished, I assembled them on top of the frame, next to the ball entry hole. At this point, the robot had a clear flow:

• The ball drops through the top hole.
• The chute guides it into the shooter.
• The yaw gear adjusts the shooter’s direction.
• The shooter fires toward the goal.

Manufacturing and Assembly

After the CAD design was mostly finished, we started manufacturing the parts using a 3D printer and a laser cutter.

This was the moment when the robot started to move from a digital model into a real physical build. Some parts could be printed directly, while larger flat panels were better suited for laser cutting.

We used Bambu Lab X1C 3D printers for the printed components. The printers helped us iterate quickly, especially for parts that needed small adjustments after testing the fit.

First Physical Assembly

After the parts were printed and cut, my teammate started assembling the first version of the robot.

At this stage, the robot was not fully functional yet, but seeing the parts come together helped us check whether the CAD design actually made sense in real life. It also made it easier to spot small issues that were hard to notice on the screen.

Getting the Control Hub

Next, we assembled the wheels and prepared the electronics, including the REV Control Hub.

Getting the Control Hub was one of the hardest parts of the build. It was too expensive for us to buy at first, and by the time we finally had a chance to get one, it was already quite late in the project.

Get just_grassy’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

So I sent messages to people who were also attending the contest and asked if anyone could lend us one. Fortunately, someone agreed, and we finally managed to borrow a Control Hub.

First Driving Test

With the Control Hub finally ready, we did some simple wiring and connected the drivetrain.

After that, our robot could finally move. It was only a basic driving test, but it was an important milestone because it proved that the drivetrain, electronics, and wiring were working together.

Iterating for the Real Field

After the first driving test, I started changing and upgrading several components so the robot could work reliably in an actual contest environment.

The first major change was the front wheel setup.

Replacing the Ball Caster

In the first version, I used a ball caster at the front of the robot. In theory, this seemed like a simple way to support the front side while allowing the robot to move smoothly.

However, once we tested it on the actual field, the problem became clear. The field floor was softer and more flexible than I expected, so the ball caster sank in too much and created a lot of resistance. Because of that, the robot could not drive smoothly.

To solve this, I replaced the ball caster with omni wheels. The omni wheels gave the front of the robot better support while still allowing sideways slip, which made the drivetrain much more practical for the contest field.

After this change, the robot could drive much better on different types of floors.

Redesigning the Intake Mechanism

Once the drivetrain became more reliable, the next problem was the intake mechanism.

In my original CAD model, I planned to use a rubber wheel underneath the robot to pull the ball in.

However, the rubber-wheel design was too rigid and difficult to integrate with our robot. Instead, we decided to use a rubber-band intake mechanism. I modeled a new component that could hold the rubber bands in the right position.

After finishing the model, I laser-cut the part from MDF and mounted it onto the robot.

With this change, the robot was able to collect the ball much more reliably, as shown in the video below. There was a problem that we did not have any more dc motors, but we fixed it using gears and chains.

Feeding the Ball into the Shooter

After the intake started working, we controlled a servo to move the ball upward into the shooting mechanism. This also worked well during testing, as shown in the video below.

Building Autonomous Mode Overnight

After the hardware tests, I stayed up all night working on the autonomous mode. My goal was to make the robot follow the ball, collect it, drive toward the goal, and shoot.

However, the shooting part was still unreliable. The robot could follow the ball, collect it, and move toward the goal, but it could not shoot the ball consistently in autonomous mode.

In the end, I spent the night at school trying to improve the robot before the contest.

Going to the Contest

After the overnight work session, we headed to the contest venue.

When we arrived, we prepared the robot and started playing matches.

During the contest, we ran into one major problem: the robot was slightly too large. To make it fit within the size limit, I moved the front wheel inward. However, because there was no support across the new wheel gap, that part became structurally weak.

We did not have enough time to redesign it properly, so we continued using the robot as it was. Eventually, during the second match, the front wheel came off the robot.

Even with that failure, we still won the match.

Final Result and Reflection

In the end, we won one out of four matches.

The result was not perfect, but the project taught me a lot. I learned how different a robot can behave between CAD, simple testing, and the real contest field. Small mechanical details — like wheel placement, chassis stiffness, and intake flexibility — ended up making a huge difference.

Most importantly, this project showed me that building a competition robot is not only about designing a mechanism that works once. It is about making every part reliable enough to survive the real field, real time pressure, and unexpected failures.