The first national robotics competition made the gap visible. We arrived with a robot that worked in our classroom and discovered how many assumptions that room had been hiding.
The problem
In 2011, I joined the Wenzelbots for my first national robotics competition. We had to build and program a LEGO Mindstorms NXT robot in LabVIEW, then make it complete several tasks in one run. The competition also scored the research and design work behind the robot, which meant the team had to explain its decisions to judges.
We were younger and less experienced than many of the teams around us. The scores made that obvious. Our robot needed repeated adjustments, and every change in design or program meant another full test. The task went beyond writing a better program: the machine had to behave consistently under competition conditions.
The build
We divided the work into the robot, the program, testing, and the research presentation. That division helped, but it also exposed how often the pieces depended on each other. A change to the robot's centre of gravity changed how the program had to approach a line. A new sensor position changed the value the program could trust.
We ran the full sequence repeatedly, not just individual mechanisms. We compared failed runs, adjusted the robot, and tried again. The presentation forced a different kind of discipline: we had to explain why we had made each choice, not just show that the robot moved. Answering a judge's question about a design decision was often harder than fixing the decision itself.
That was more useful than demonstrating the robot. It showed me that a design decision is not fully understood until you can explain what you gave up. Those questions made the design explicit; they were part of the work, not a formality. That is where the next season's process started.
The result
We did not leave with a top placement. We did leave with a working robot, a clearer understanding of how the scoring worked, and a list of things to change before the next season. The competition showed me that preparation, organisation, and communication are part of the engineering work, not extras that happen after it. The debrief gave us a concrete list: a more repeatable setup, a clearer test plan, and a presentation that explained tradeoffs rather than only features.
What I took from it
That year made robotics feel bigger than a school club. It was the first time I saw programming, hardware, presentation, and teamwork collide under a deadline. The result was the realisation that a technical idea only counts when a team can execute it and explain it. The number on the leaderboard was secondary.