What Feedback Control Actually Does

A home thermostat is the most domestic example of one of the most consequential ideas in engineering. You set it to 68 degrees. The furnace runs, the room warms, and at some point the furnace shuts off. A while later it kicks on again. Nothing about this is dramatic, but the structure of what is happening underwrites cruise control, autopilots, insulin pumps, hard drive read heads, and the speed governor on the steam engines that made the industrial revolution legible to its own engineers.

The structure has four pieces. There is a setpoint, which is what you want the system to do. There is a measurement of what the system is actually doing — in the thermostat case, the current room temperature read by a sensor. There is the error, which is simply the difference between the two. And there is an actuator, something that can push the system in a direction that reduces the error. The furnace is the actuator. The loop closes when the measurement is fed back to the controller, which decides what the actuator should do next based on the current error. Hence feedback control, and hence the term closed-loop, in contrast to an open-loop system that acts without checking the result.

What the loop actually does, stated plainly, is convert a goal into a continuous correction. You do not need to know in advance how cold the night will get, how drafty the house is, or whether someone leaves a window open. The controller does not model any of this. It only needs to keep asking: what is the error right now, and which way should I push? This is why feedback is powerful. It substitutes ongoing measurement for advance knowledge. A well-designed loop can hold a system on target despite disturbances the designer never anticipated and despite a plant — the thing being controlled — whose behavior is only approximately understood.

This substitution is not free. A feedback loop can fail in characteristic ways, and learning to see those failure modes is most of what a first course in controls teaches. If the controller pushes too gently, the system drifts and never quite reaches the setpoint; engineers call this steady-state error. If it pushes too hard, the system overshoots, the controller reverses, the system overshoots the other way, and the result is oscillation — sometimes a small ringing that decays, sometimes a growing swing that destroys the equipment. Cruise control that hunts up and down around 65 mph is a benign version. The Tacoma Narrows Bridge, oscillating itself apart in 1940, is what happens when feedback in a physical structure goes unstable. Stability is not automatic; it is something the controller has to be tuned for.

There is a deeper point hiding inside the failure modes. Feedback works by acting on error, which means it can only respond to a problem after the problem has begun. A pure feedback controller is always, in a small way, behind. This is why real systems often combine feedback with feedforward — using a model of expected disturbances to act in advance — and why controllers are sometimes given memory of past error or an estimate of how fast the error is changing. The classical PID controller, ubiquitous in industry, is exactly this: a weighted sum of the present error, the accumulated past error, and the rate of change of error. Each term addresses a specific weakness of the others.

The thermostat hides all of this. It hides it well enough that we forget the loop is there, which is the highest compliment a control system can receive. When you notice a feedback controller, it is usually because it is doing badly — the shower that scalds when someone flushes a toilet, the elevator that bounces before settling, the drone that wobbles in wind. The goal of the discipline is to make the loop disappear into the behavior of the system, so that the room is simply warm and the car simply holds its speed. What looks like the absence of effort is, almost always, a loop quietly closing thousands of times a second.