I knew what a filter was, what resonance does, what feedback loops sound like — but I'd never thought about how physical systems are controlled.
I'm a CS student who builds music tools. I know audio feedback intimately. But PID? Not something I'd encountered.
Then I learned that PID controllers are in literally every robot ever made. Robotic arms, drones, autonomous vehicles, industrial machinery. If something physical is being controlled — if a system is trying to hold a value steady against disturbance — there's almost certainly a PID controller somewhere in the loop.
So I built one from scratch.
What PID is
The problem: a pole is balanced upright on a cart. It's unstable — left alone, it falls. A controller must apply horizontal forces to the cart to keep it upright.
The controller measures one thing: the pole's angle from vertical. That's the error — how far the system is from where it should be. From that single measurement, three terms compute a corrective force:
P — Proportional. Push back in proportion to how far off you are right now. Simple, intuitive, and the one that breaks everything if it's too high. Crank Kp past a certain point and the system doesn't stabilize — it oscillates. The harder you push, the more it overshoots, the harder it has to push back, forever.
I — Integral. Accumulate the error over time. If the pole has been slightly off to one side for a long time, the integral term builds up and applies a corrective force to fix the drift. It has memory. P-only controllers often settle near the target but never exactly at it — I closes that gap.
D — Derivative. Look at the rate of change of the error. If the pole is falling fast, the derivative term pushes back harder than if it's falling slowly — even if the current angle is the same. It's predicting where the system is headed, not just reacting to where it is.
That last one is the one that stuck with me. The D term is anticipatory. It doesn't know the future, but it uses the present rate of change to act as if it does. That felt surprising for something so mechanically simple.
u(t) = Kp·e(t) + Ki·∫e dt + Kd·de/dtThree terms. That's the whole thing. And it's in every robot ever made.
What oscillation looks like
I built an interactive dashboard — Python simulation ported to the browser, with sliders for each gain and presets that demonstrate failure modes.
The most interesting one: high Kp, zero Kd.
The pole starts to fall. P pushes back hard — too hard. It overcorrects, now leaning the other way. P pushes back again. The pole swings back and forth, never settling, oscillating with increasing energy. Without D to dampen it, the proportional response just keeps fighting itself.
It looks exactly like a reverb that builds instead of decays. In audio, when a feedback loop has too much gain — a microphone too close to a speaker, a reverb with too-high feedback — you get the same runaway behavior. Energy re-enters the system faster than it dissipates. PID is the thing that prevents that in physical systems. D is the thing that tells the controller: you're moving too fast, ease off before you overshoot.
Feedback loops everywhere
The more I thought about it, the more PID appeared in things I already know.
Ten years of violin. When you play, you're running a continuous feedback loop: listen to the pitch, measure the error against where it should be, adjust bow pressure and finger position. You don't compute this — it's physical intuition built over years. But the structure is identical. Error measurement, proportional response, derivative dampening (you don't snap to the right pitch, you ease into it).
Live coding at an Algorave. You're writing code that generates music in real time while the audience watches. The loop is: listen to what the system is producing, decide what to change, update the code. You're the controller. The music is the plant. The audience's reaction is the feedback.
Tuning a filter by ear. You sweep the cutoff frequency, listen for the resonance peak, back off when it starts to scream. That's manual gain tuning. That's Kp.
Feedback — measure, compare, correct — shows up everywhere once you're looking for it. PID is the formalization of something that was already familiar.
The pairing
I built this alongside a policy gradient RL project that solves the same physical problem — a pole that needs to stay upright — using a learned neural network policy instead of a hand-coded controller.
PID knows nothing at the start. You give it the math, tune three numbers, and it works. It's interpretable: you can look at the gains and understand exactly what the controller will do in any situation. It converges instantly. An experienced engineer can tune it in minutes.
RL knows nothing at the start either, but it learns through trial and error. 288 episodes of falling poles before it figures out how to balance one. The policy that emerges is a black box — you can't look at the weights and understand why it works. But it generalizes. You could train it on a harder version of the problem and it would adapt.
Neither is better. The thing that makes a robot work isn't one technique. It's knowing which one fits.