Advanced FTC Robot Programming: Design Patterns, Tooling, and the Complete Code for a Competition Robot (The Qubit Bot)

An advanced guide to programming FIRST Tech Challenge (FTC) robots in Java with the FTC Software Development Kit (SDK). Twelve chapters each dissect one class or cluster: layered composition, zero-overhead logging and performance metrics, background asynchronous processing, custom Limelight pipelines in Python, Pedro Pathing driver assistance in TeleOp, cross-OpMode state handoff, and the calibration and tuning tooling that makes the rest maintainable. Ten appendix sections then carry the complete, unabridged source for a working robot from the 2025-26 DECODE season: roughly 10,000 lines of Java plus 200 lines of Python on a Limelight 3A camera.

Read it not as one team's solution to a particular game, but as a worked example of a robot design that survives multiple seasons. No file is large. The biggest, Lift.java, is 380 lines, and most subsystems fit in 150 to 200. The premise is that the small file size comes from repeated, careful application of a handful of patterns, and that those patterns are the thing worth learning. Every chapter closes with the same two questions: what this class won't save you from, and why the pattern generalizes.

Five themes recur throughout.

Layered composition, not monoliths. No class does more than one thing. Bots are Composite trees of subsystems, a concrete bot is one ~20-line method, and the four autonomous options are 30-line files of poses and flags.

The 100Hz loop is sacred. Every 10ms the robot reads sensors, runs logic, and commands actuators. Motor and servo Decorators cache the last commanded value, cutting a naive 38ms of hardware writes to about 5ms. Logging compiles away to a no-op in competition builds. Expensive work such as AprilTag detection moves to background threads, and OpenCV thresholding runs on the camera instead of the robot.

Tooling beats genius. Calibration OpModes, PID tuning rigs, a CSV recorder, and a pre-match configuration TeleOp add no game-day capability. They collapse the iteration loop, turning flywheel tuning from thirty build-and-deploy cycles into live dashboard edits. A team without tooling spends its tuning budget guessing; a team with it spends that budget measuring.

Degrade gracefully, fail loud. Absent hardware is null and callers null-guard, so one set of consumers works across every robot. Uninitialized state gets a sentinel outside any legal range. Faults a driver should see get warnings that do not abort the OpMode, and silent failures get loud markers.

State survives boundaries. The TeleOp OpMode is a fresh object with no memory of autonomous. Alliance, position, delay, motif, and the end-of-auto pose persist to disk, so TeleOp resumes exactly where autonomous stopped, with no measurement and no driver repositioning.

There is no special technology here. The patterns are thirty years old, the libraries are off the shelf, and the hardware is what every team can buy. What is distinctive is how consistently the patterns are applied: exactly one way to add a subsystem, one to add an autonomous variant, one to add a vision pipeline, one to do background work. A robot design succeeds through architectural restraint, not algorithmic cleverness.

For an FTC team, the lesson is to build the tooling first. It feels like a detour from the real work; it is the real work. For a working or aspiring software engineer, the hard real-time loop, the cross-process state handoff, and offline tooling for online work are problems shared with embedded and distributed systems, and with any production software that has a human operator in the loop. Read it as a dozen worked examples of applying standard patterns in a constrained domain, and the lessons will outlast this season's game.