A worked example of building your own drive library: the reasoning behind how SpartanDrive hits a precise distance or angle on its own — the closed-loop idea, and the choices we made wrapping it.
This is a companion to our odometry write-up and to Build Your Own Drive Library — the same philosophy applied to the hardest part of an autonomous routine: driving an exact distance, and turning to an exact angle, with no human at the controls. The idea and our choices are here for any team; the code that implements them stays ours to write, and yours.
The closed-loop idea below — and why we made the choices we did — is openly shared. It's universal control theory any team can use. The SpartanDrive source, the tuned constants, and the API that implement it stay with the team, same as everywhere on this site. The idea is the gift; the implementation is the work.
The naive way to drive 24 inches is to turn the motors on for some number of milliseconds and hope. It never holds up: a fresh battery drives farther than a tired one, carpet drags differently than foam, and a heavier robot coasts further. The timer doesn't know any of that — it just counts.
The fix is to stop guessing and start measuring: watch how far the robot still has to go, and adjust the power constantly until that distance is zero. That's a closed loop, and the standard tool for it is PID.
PID reaches a target smoothly by adding up three simple reactions to one number — the error, or how far the robot still is from where it should be. The robot recomputes all three about a hundred times a second.
"How far off am I?" The further from the target, the harder it drives; as it closes in, it eases off. This is the main driving force. P alone, though, tends to overshoot and wobble.
"Am I stuck just short?" If friction holds the robot a hair from the target, this slowly builds a little extra push to finish the job. Used lightly — too much causes overshoot of its own.
"How fast am I closing in?" It gently brakes if the robot is coming in too hot. This is what cancels the overshoot-and-wobble that P alone causes, and smooths the landing.
Add P, I, and D together each moment and you get a motor power that drives hard when far, eases in when close, and settles cleanly on the target — without anyone touching a stick.
PID is the textbook part. The choices around how to wrap it are where building your own earns its keep — and where a judge's questions get interesting.
A straight drive runs a second, gentle loop alongside the distance one: it watches the heading and nudges the two sides to cancel any drift. The robot covers the distance and stays straight, on its own — no separate "drive straight" code to remember.
Turns target an absolute field heading rather than a relative spin, and always take the shorter way around (350° to 10° turns 20°, not 340°). The robot's sense of direction stays consistent no matter what move came before it.
A move isn't finished the instant it first touches the target — it has to stay within a small zone for a brief moment first. Skip that and the robot declares victory while it's still coasting past the point.
Every move carries a give-up timer. If the robot jams against a wall or a defender, the move ends cleanly instead of grinding the motors for the rest of the match. Safety first, every time.
When a judge asks "how does your robot drive an exact distance in autonomous?", a student who wrapped this themselves answers in one breath: we measure how far is left and adjust constantly — push hard when far, ease in when close, brake the overshoot before it happens. That answer isn't something you can borrow from a black box; it comes from having built the loop and chosen how it behaves.
It's the same principle as the rest of our code, the one the design principles describe: build exactly what the robot needs, name it for the people using it, and understand every piece. PID is just where the control theory shows up.
The control theory and the reasoning here are yours to learn from. But if you build PID driving into your own robot, the code — and the tuning — has to be work you did and can explain; that's exactly what the notebook and the judges reward. Take the idea; write the implementation yourself.
Keep going: how we track position, the case for building your own library, or the code organization guide for structuring a project cleanly.