Engineering & Robotics
The Road to Champs
From a blank page to Australian national champions. Then back to a blank page for the FIRST Championship in Houston.
Overview
One competition season. Two clean-sheet robots. An Australian National Championship. A custom swerve drivetrain, motion-compensated auto-aiming, and a software stack that let us replay the robot in 3D from our Houston hotel room. This is the road from a blank page in Sydney to the FIRST Championship in Houston.
My role
I was the mentor leading Barker’s competitive FTC program, responsible for the engineering effort as a whole. That meant holding the robot architecture, schedule, procurement and software plan in my head at once. When a student was working on one part of the robot, I could connect their decisions to the constraints and dependencies everywhere else. The core engineering team comprised seven students, who were the primary designers and programmers. Day to day, I taught them what good design looked like, reviewed their work, and guided them towards solutions that would perform. This looked like Teams messages like: “Okay, if we want to assemble next Saturday, we need to order the belts tomorrow and the bolts by Wednesday. If you get the assembly to me on Thursday, I’ll machine it while you’re at school on Friday. Oh, and remember we already ordered the 14T and 16T pinions in the last order, so try to use those.” And plenty of Snipping Tool annotations: “This rib looks off. Why don’t you put it here, where the load path actually is?”
What am I even looking at?
TL;DR: the robot needs to shoot more balls in 2 minutes 30 seconds than the other team can. FTC is a student robotics competition where teams design and build a roughly 15 kg robot to play a new game each year. Robots operate both autonomously and under driver control, with teams progressing through regional, national and international competition (if you qualify).
Blank Page
6 September 2025: the game is released. 6–7 December 2025: Australian National Championship. 91 days. So realistically: architecture → prototype → CAD → manufacture/assemble → software/integration → Compete Regional Then, assuming we qualify: refine mechanisms → improve control → driver practice → Compete Nationals Tick tock...
Design Brief
The design requirements we arrived at after analysing the game: Intake balls from the ground Store three balls (max allowed) Sort them into any required shot order (make colour patterns) Shoot into the goal
The Risky Bit
The biggest question mark is, how do we take in 3 balls in any colour order, then rearrange them to be shot in a certain order? We were inclined to a “spindexer”, a design popular in the 2020 FRC game, but we wanted to find out if this was even gonna work, before we bet the house on it.
Detailed Design
This is gonna be too long if we actually cover all of it, so here are a few random CAD screenshots.
Things Don’t Always Go to Plan
The spindexer jammed if a ball was waiting at the intake while an already-filled slot rotated past. The fix was non-trivial, especially once much of the design had been locked in metal, but we won’t get into that here.
Software
The robot used motion-compensated aiming, an interpolated lookup table for aiming data, and camera-based position feedback, amongst other things.
Nationals
Winning the Australian National Championship qualified us for the FIRST Championship in Houston.
Blank Page, Again
Software got complicated. When something went wrong, we struggled to isolate the root cause. Once a match was over, we had no way to rewind it and inspect what the robot thought had happened. Sorting also turned out to be less valuable than we expected. When everyone is scoring fast, making colour patterns becomes difficult enough to be pointless. If we were going to stand a chance in Houston, we needed more balls per second. Faster intake, faster storage, faster shooting, faster everything. 11 January 2026: blank page again. 29 April 2026: FIRST Championship. 108 days.
The Gamble: Swerve
The Nationals robot, like most FTC robots, used mecanum wheels. Omnidirectional travel, mechanically simple. The tradeoff: efficiency and traction. We still wanted omnidirectional travel → swerve. Common in larger-format robotics competitions, but exotic in FTC: harder to package, mechanically much more complex, and more software to solve. We were already dumping our entire architecture mid-season. We knew we were behind. Maybe it was worth just doubling down. So we designed our own swerve to solve these packaging issues.
A Throughput-First Robot
Swerve was only the drivetrain. Everything else was new too, designed around maximum throughput. No more sorting, pure balls/s. Adjustable-angle powered back-roller shooter. Super-fast turret. New transfer.
YouTube The Nationals robot could stream values to a dashboard and graph them live. But once the match ended, the information was gone. For the Championship robot, we had big ambitions. We knew we needed a better way to work. Log everything to disk. Reconstruct any run, at any time.
Robot composition
Driver + autonomous OpModesRobotRobotManager (sensor prefetching + battery monitoring)FusedLocaliser (raw encoder counts + camera → fused position + velocity)Follower (robot path planning)RobotStateMachine (robot intent → Scorer + Transfer target states)Scorer (aiming + mode control + shot readiness)LookupAimer (motion-compensated shot solver)Shooter (PID + feedforward, owns hardware)Turret (PID + feedforward, owns hardware)Transfer (intake + line-break occupancy + clutch controls when balls enter the shooter)SwerveDrivetrainSwerveKinematicsSwerveModule × 4 (steering PID + drive velocity feedforward)FRC already had mature tooling for this. AdvantageScope is an open-source tool widely used to inspect persistent robot logs and reconstruct robot state in 3D. That workflow is far less common in FTC, where debugging generally revolves around live telemetry. We adapted that approach to our FTC software stack. The robot recorded its sensor inputs, estimates, controller targets and subsystem states to disk throughout every run. Afterwards, we could scrub through a run and stop at any moment, with every graph, sensor value and reconstructed mechanism locked to the same timestamp. We could see not only what the robot physically did, but what it believed and commanded at that exact moment.
Aiming, end to end
- The FusedLocaliser subsystem provides robot position + velocity on the field
- Shot distance → interpolated lookup table → time of flight
- Propagate the goal by the robot’s motion during flight, then fixed-point iterate to convergence
- Output shooter RPM + turret angle + shooter exit angle
- Repeat the solve 0.1 s in the future, assuming constant velocity
- Finite difference between the two solves → shooter RPM acceleration + turret angular velocity feedforward
- The Shooter subsystem applies its tuned kS, kV and kA model + velocity PID
- The Turret subsystem applies its tuned kS, kV and kA model + position PID
Feedforward carried the predicted motion. PID corrected what the model missed.
In the final week or so before we left for Houston, I had to take some time away from the team for university exams. The students would occasionally send me a log file and ask for my insight, so I would open it at uni or in a café, wherever I happened to be studying. Most of the time, I could pick out the problem from the replay, then confirm it with one or two yes-or-no questions about what they had physically seen. I was normally right. This really felt like a new way of working.
Time to Ship
24 April 2026. Five days to the FIRST Championship. We left Sydney for Dallas via Melbourne, with the robot packed into a Pelican case and checked in for the journey. Travelling with a competition robot is its own engineering problem. We needed enough tools, fasteners, electronics and spare parts to recover from whatever broke in Houston. No M4 bolts at Home Depot. I drew on my experience competing since 2019, along with what had broken or worn out on this robot over the preceding month, to help the team decide what spares we actually needed to bring. SYD → MEL → DFW. Five days to go.
The Other Side
With a few days still to go before the Championship, we spent our remaining time practising around the clock. Driver practice, autonomous routine tuning, trying to convert what we had into as much performance as possible.
The Championship
Frankly, we bombed. The rushed development schedule had caught up with us. We arrived without enough driver practice or autonomous tuning, and we were plagued by intermittent wiring issues. After days of moving the robot between hotel rooms, vans and the venue, the electrical system seemed to have taken a beating. Except for our final qualification match. For one match, everything came together. It was a glimpse of the robot we thought we had built, and of what the week might have looked like if we’d arrived with another few weeks of development behind us. In a way, this was the risk we had accepted. We knew from the start that we were behind, but chose to swing for the fences anyway. We got close. The robot we made was mechanically more or less what we dreamt of. In software, we had more logging and features than we had expected at the outset, yet it was still just too rushed. The robot was at Championship and we were still running experiments. The biggest takeaway for me was a different way of thinking about robot software: log everything, keep it data-oriented, and make the state replayable. In the weeks before Championship, the students could send me a log file while I was at uni or sitting in a café, and I could usually work out what had gone wrong from the replay and one or two questions about what they had physically seen. That work led to another of my projects, LogVue, built to make the data collation workflow easier. For next season, I’m researching plant/model-based simulation. Maybe next season, we’ll have agents testing the robot inside a simulator at 10× real time.
