Blog · 2026-07-05 · PID
PID is three ideas a human driver uses without thinking, written as arithmetic a microcontroller can run a thousand times a second. Once you see it that way, the intimidating acronym dissolves.
Every interesting robot behavior — following a line smoothly, holding a heading, balancing on two wheels, keeping a drone level — is the same problem in costume: there is a target, there is a measurement, and something must continuously convert the difference into action. That difference is called the error, and PID is the ninety-year-old, still-dominant recipe for turning error into action. It runs in your drone's flight controller, your 3D printer's hotend, and industrial plants worldwide, and the whole recipe is three terms added together.
You're driving and want to stay centred in your lane. What does your brain actually do? First, the further you've drifted, the harder you steer back — correction proportional to error. That's P. Second, if a crosswind keeps nudging you right, you learn to hold a little constant left pressure — you've accumulated persistent error into a standing correction. That's I. Third, if the car is swinging back toward centre fast, you ease off before you get there, so you don't overshoot into the other lane — you respond to the error's rate of change. That's D. Present, past, future: react to the error you have, remember the error that persists, anticipate the error that's coming.
P_term = Kp × error
Big error, big correction; small error, gentle correction; the gain Kp sets the aggression. P does most of the work in most controllers, and it has two signature failures. Set Kp too high and the system overshoots the target, corrects too hard the other way, and oscillates. Set it low and something subtler appears: steady-state error. Against any constant disturbance — gravity on an arm, friction on a wheel — a P-only controller settles slightly off target, because it needs some error to exist in order to output any correction at all. Zero error would mean zero output, and zero output loses to gravity. You can watch exactly this in our PID Tuning Visualizer: the "P too low" and "P too high" presets show the sag and the ringing side by side.
integral += error × dt
I_term = Ki × integral
The integral term is a running sum of error over time. If error persists — that stubborn P-controller sag — the sum grows, the correction grows with it, and it stops growing only when error is truly zero. I is the term that eliminates steady-state error, and it's why your 3D printer holds 210.0°, not 204. Its dark side is windup: if the system can't respond for a while (actuator maxed out, robot held in hand), the sum balloons, and once free the controller dumps that stored correction into a huge, slow overshoot. Real implementations clamp the integral — a one-line fix you'll see in the pseudocode below, and a failure you can reproduce with the Visualizer's "Windup" preset.
D_term = Kd × (error − previous_error) ÷ dt
The derivative term measures how fast error is changing and pushes against rapid change. When the system is racing toward the target, error is shrinking quickly, so D outputs a braking correction before the overshoot happens — it's damping, the mathematical version of easing off the wheel. D is what turns an aggressive, ringing P response into a crisp one. Its weakness: it amplifies whatever changes fast, and on real hardware the thing that changes fastest is sensor noise. Practical controllers filter the derivative or compute it from the measurement rather than the error; simulated D always looks better-behaved than the real thing.
error = setpoint − measurement
integral = clamp(integral + error × dt, −limit, +limit)
derivative = (error − prev_error) / dt
output = Kp×error + Ki×integral + Kd×derivative
prev_error = error
Run that at a fixed rate — 100 Hz is plenty for hobby robots, and a consistent dt matters more than a fast one — feed the output to your motor driver, and you have the same algorithm flying quadcopters. The three gains Kp, Ki, Kd are the personality knobs, and choosing them is the craft called tuning, covered step-by-step in the companion article.
Line follower. Setpoint: line centred under the sensor array. Measurement: weighted position across the sensors. Error: signed offset from centre. Output: a steering value, added to one motor's speed and subtracted from the other's. With P alone the robot works but weaves, wagging down the track; adding D calms the weave into smooth arcs — the visible difference between a beginner's follower and a winner's. I is often left at zero here: the setpoint changes constantly with the track, and there's rarely a constant disturbance worth remembering.
Wheel speed control. Setpoint: 200 RPM. Measurement: encoder counts per interval. Without control, "equal PWM to both motors" produces a robot that curves, because no two motors are identical. A PI loop per wheel (D usually unnecessary — motors self-damp through friction) makes each wheel independently hit its commanded speed regardless of battery sag or carpet, and suddenly the robot drives straight. This is the most immediately rewarding PID a beginner can build, and pairs naturally with motors chosen via the Motor Sizing Calculator — with encoder versions, for exactly this reason.
| Symptom | Likely cause | First fix |
|---|---|---|
| Constant fast oscillation | Kp too high | Halve Kp, or add Kd |
| Settles below/off target | No or tiny Ki vs a constant disturbance | Add a little Ki |
| Slow, large, wallowing overshoot | Integral windup / Ki too high | Clamp integral, reduce Ki |
| Twitchy, buzzing output | Kd amplifying sensor noise | Filter or reduce D |
| Sluggish, never quite arrives | All gains too low | Raise Kp first |
Every row of this table is reproducible in sixty seconds in the PID Tuning Visualizer — and building that visual vocabulary before touching real hardware is the cheapest control-theory education available.
No — most working controllers are P or PI. Add terms only for the symptom they cure: I for steady offset, D for overshoot. Simplest controller that meets the spec wins.
Yes — it's the classic build. Usually as two loops: a fast inner PID holding tilt angle, a slower outer loop adjusting the tilt setpoint to control position. Cascaded PIDs carry you a long way before "real" control theory is needed.
From tuning — a systematic experimental process, not guesswork. That's the next article: How to Tune a PID Controller.
P reacts, I remembers, D anticipates. Ten lines of arithmetic, three knobs, and most of robot motion control. Go build the intuition where mistakes are free: the PID Tuning Visualizer is waiting.
Three implementation notes separate a textbook PID from one that behaves on hardware. Fixed timestep: compute dt from a hardware timer or run the loop in a timed interrupt; deriving dt from "whenever the loop happens to run" injects noise directly into I and D. Derivative on measurement: when the setpoint jumps (new command), error jumps too, and the derivative term spikes the output — "derivative kick." Computing D from the change in measurement instead of the change in error eliminates the kick with one line, and virtually all serious implementations do it. Clamp everything: the integral (windup), and the final output to the actuator's real range — and when the output is clamped, stop accumulating the integral, since demanding more from a maxed motor is accounting fiction. These three habits cost ten minutes and prevent the majority of "PID is behaving weirdly" sessions.
PID is purely reactive — it corrects error after error exists. When you already know part of the demand, tell the controller in advance: that's feed-forward. A wheel-speed loop knows roughly what PWM produces 200 RPM (from a simple test), so command that baseline directly and let PID trim only the residual error; an arm joint knows gravity's torque at each angle (the exact math from the servo torque article) and can offset it before the integral has to discover it slowly. Feed-forward plus modest PID routinely outperforms heroic PID alone, uses everything you calculated while designing the robot, and is the natural next concept once tuning feels comfortable.
A closing reassurance: nothing in this article required calculus, and nothing in practical hobby PID ever will. The integral is a running sum; the derivative is a subtraction. The mathematics-heavy treatments exist to analyze controllers, not to build them — and the builder's path of intuition first, simulation second, hardware third gets working robots faster than any textbook chapter.