Concurrent Subsystem Control

The Problem

Thirty seconds is not much time. A robot that drives, stops, runs its intake, stops, and then scores spends most of autonomous waiting on itself. The team had a small command library from earlier seasons that could run a task in the background on its own thread, but almost no robot code was built on it, and there was no clear place for a new teammate to add a feature.

What I Built

In 2023–24 I rebuilt the robot code around four kinds of modules. Subsystems own the hardware and expose simple methods. Commands drive subsystems and know when they are done. OpModes, the programs a driver picks on the phone, choose which commands to run based on Utilities like odometry and vision. Commands can run one after another or side by side, so the robot can drive to a spot while the intake gets ready.

Scaling to Four Threads

By 2025–26, the robot had to aim a turret, hold a flywheel at speed, sort balls, and run its intake, all while driving. With that many commands on their own threads, they were all reading and writing the same motors and sensors, and every extra hardware call slowed down every loop.

So I separated deciding from doing. Commands on background threads only set targets in shared variables. A single I/O loop does all the talking to hardware: one bulk read from the control hub per cycle, then motor outputs written once. The autonomous path talks to the background aiming, launching, and intake commands through a few shared flags. It sets “start launching,” then waits for the launch command to clear it.