FTC Robotics

The Story

When I joined my school’s FIRST Tech Challenge team as a sophomore, there was no team. I mean that literally — I helped build it from scratch. We had no robot, no workshop traditions, no veteran members to learn from, and no competition experience. What we had was a group of students who wanted to build something, a faculty advisor willing to support us, and a deadline for our first tournament that felt impossibly close.

I stepped up as team captain not because I had the most experience, but because someone needed to pull everything together. I coordinated our build schedule, organized subteams for mechanical design, programming, and strategy, and made sure we were actually making progress instead of just talking about ideas. Those first months were chaotic, exhausting, and some of the most formative of my life.

The Challenge

Competitive robotics is hard in a way that surprises people who have not done it. You are not just building a robot — you are designing a machine that has to perform specific tasks autonomously and under driver control, building it with limited budget and tools, programming it to be reliable under pressure, and then competing against teams that have been doing this for years.

As a rookie team, we were behind before we started. Experienced teams have institutional knowledge: they know which mechanisms work, which programming approaches are reliable, what goes wrong at competitions, and how to manage a build season. We had none of that. Every lesson we learned was the hard way.

The FTC game changes every year, so you cannot just copy a previous design. But experienced teams understand the design principles that transfer across seasons. We had to develop those principles from zero while simultaneously trying to be competitive.

Our Approach

I structured the team around three pillars: engineering discipline, programming excellence, and relentless iteration.

On the mechanical side, we adopted a prototype-first approach. Instead of trying to design the perfect robot on paper, we built quick prototypes of each mechanism, tested them, measured performance, and iterated. This meant we went through more material and our workshop was messier, but it also meant we found problems early and fixed them before competition day.

For programming, I led the development of our autonomous routines in Java. Autonomous is the portion of the match where the robot operates without any human control — it has to navigate the field, identify targets, and score points entirely on its own. Writing reliable autonomous code requires careful sensor integration, path planning, and extensive testing. I spent countless hours in the workshop running autonomous tests, tweaking parameters, and building a codebase that could handle the variability of real competition conditions.

Strategy was the third pillar. FTC matches are played in alliances, so understanding how to complement your partner and exploit opponents’ weaknesses is just as important as having a good robot. I analyzed match footage, studied scoring breakdowns, and developed match strategies that maximized our alliance’s point potential even when our robot was not the most mechanically advanced on the field.

The Growth Arc

Our rookie season exceeded every expectation. Despite being a brand-new team with no competition history, we earned the number one ranking at our Inter-League Tournament (ILT). That finish was not a fluke — it reflected a team that had worked incredibly hard, iterated constantly, and executed well when it mattered.

But the second season is where things really came together. With a year of experience under our belts, we knew what to focus on. I expanded the team to 15 members, brought in new talent, and established mentorship structures so that experienced members could teach newcomers. The programming team grew from basically just me into a capable subgroup that could develop and test autonomous routines independently.

The results spoke for themselves. In our second season, we achieved ILT and League number one rankings. Our autonomous program was ranked in the top 100 worldwide — out of thousands of FTC teams globally. That ranking was especially meaningful to me because autonomous was the area I had personally invested the most time in. Knowing that our code could compete with the best teams on the planet was an incredible feeling.

Impact

The competitive results were gratifying, but the impact I am most proud of is what happened off the field.

I was nominated as a Dean’s List Semi-finalist in 2025. The Dean’s List award is FTC’s most prestigious individual recognition — it honors students who have demonstrated outstanding leadership, technical skill, and dedication to spreading STEM values. Being nominated meant that people beyond our team recognized what we were building.

Beyond awards, I am proud of the team itself. When I started, there was no FTC team at our school. Now there is a competitive program with 15 members, established practices, and a culture of engineering excellence that will continue after I graduate. Several team members who joined as complete beginners are now capable robot builders and programmers. Watching them grow and take ownership of subsystems was more rewarding than any trophy.

I also gave back to the broader robotics community through FLL mentorship. I coached younger teams in FIRST Lego League, helping them prepare for competitions. Teams I mentored went on to earn a Core Values Award at the world competition and qualify for West Edge International. I served as a translator for international Chinese teams, bridging language barriers so that more students could participate fully. Those mentoring sessions — sometimes five or more per week — reminded me why I got into robotics in the first place: the joy of building something and watching it work.

What I Learned

FTC taught me that leadership is not about being the best at everything. It is about creating an environment where everyone can contribute their best. My job as captain was not to build the whole robot or write all the code. It was to set the vision, allocate resources, remove blockers, and keep morale high when things went wrong — which they always did.

I learned the value of systematic testing. In our rookie season, we showed up to competitions with untested code and got burned by edge cases. By our second season, we had testing protocols that caught problems before they reached the field. That discipline carried over into all my software projects.

The technical skills were substantial. Java programming for real-time robot control taught me about concurrency, sensor fusion, PID controllers, and the gap between code that works in theory and code that works on a moving robot that just got bumped by an opponent. Hardware-software integration forced me to understand mechanical constraints, electrical systems, and communication protocols.

But the deepest lesson was about building teams. Recruiting members, mentoring beginners, managing conflicts, delegating responsibility, celebrating wins, and learning from losses — these are skills that matter far beyond robotics. The team I helped build is my most significant engineering achievement, not because of any single robot, but because it is a system that creates engineers.