Two ways to give a command
Imagine you want a motor to turn a robot arm to a certain angle. There are two fundamentally different ways to do it. The first is to send a command and trust it: "Run the motor for two seconds at half power." You compute that this should land the arm where you want, you press go, and you walk away. This is open-loop control — the command goes out, and nothing ever comes back to check whether it worked.
A microwave timer is pure open loop. You set it for ninety seconds, it heats for ninety seconds, and it stops. It never measures whether your food is actually hot. If the dish started frozen, it comes out cold in the middle — the microwave has no idea, because it was never watching the result, only the clock.
The second way is to keep checking. A home thermostat does not run the furnace for a fixed time; it reads the room temperature, compares it to the temperature you asked for, and switches the furnace on or off based on the gap. If a window is open and heat keeps leaking out, the thermostat simply keeps the furnace running longer. It corrects for surprises because it watches the result. This is feedback control, also called closed-loop control: the output is measured and fed back to influence the next command.
The set-point and the one number that matters
To close the loop, the controller needs to know what "correct" looks like. That target is the set-point: the value you want the system to reach and hold. On a thermostat it is the temperature you dialed in. For a robot joint it might be "90 degrees"; for a wheeled robot, "1.5 meters per second." The set-point is your wish, expressed as a number.
Then a sensor reports what is actually happening — call it the measurement. Now the controller has two numbers, the wish and the reality, and from them it forms the single most important quantity in all of control: the error signal. The error is simply set-point minus measurement. If you want 90 degrees and the joint is at 75, the error is +15. If the joint overshoots to 95, the error is −5. This one number — how far off you are, and in which direction — is the only input a feedback controller really needs.
error = set_point - measurement set_point = 90 deg (what you want) measurement = 75 deg (what the sensor reads) error = +15 deg (positive: still too low, push up) # after an overshoot measurement = 95 deg error = -5 deg (negative: too high, ease back)
Why boil everything down to one number? Because it makes the controller's job simple and universal. The controller does not need to understand temperature, or angles, or speed — it only needs a rule for turning error into an action: when the error is large, push hard; when the error is small, ease off; when the error is zero, you have arrived. The famous PID controller is exactly such a rule, but even the simplest controller is just a recipe that turns error into a command.
Watching the error fall to zero
Here is the loop in motion. Suppose the joint starts at 75 degrees with a set-point of 90. The error is +15, so the controller drives the motor forward. As the joint swings toward 90, the measurement climbs and the error shrinks: +15, then +9, then +3. A smart controller eases off as the error gets small, like lifting your foot off the gas as you approach a stop sign. The goal is to coast the error all the way down to zero and stay there.
But momentum is real. If the controller pushed too hard, the joint sails past 90 to, say, 95. Now the measurement is above the set-point, so the error flips sign: it was +3, and suddenly it is −5. That sign flip is the controller's cue to reverse — to brake or push back the other way. The system may oscillate above and below the target a few times, each swing smaller than the last, before it settles. How quickly and smoothly it settles is the subject of damping and overshoot; for now, the key idea is that the sign of the error tells the controller which direction to correct, every single cycle.
Notice what every step of this depended on: a sensor. Without a measurement, there is no error, and without an error, there is nothing to feed back. This is why a sensor is mandatory for closing the loop — an encoder on the joint, a thermometer in the room, a speedometer on the wheel. The sensor is the eye that lets the controller see the result of its own actions. Take the eye away and you are back to the microwave, heating blindly for a fixed time.
When open loop is actually good enough
It would be easy to conclude that closed loop is always better, but that is not true. Feedback costs money and complexity: you need a sensor, wiring, and a controller smart enough to read it. Open loop is cheaper, simpler, and faster to build. The honest engineering question is not "which is better?" but "does the result need checking?"
- The task is predictable and disturbances are tiny. A stepper motor advancing a 3D-printer bed moves a fixed amount per pulse; if nothing ever pushes back, counting pulses is enough — no sensor required.
- A mistake is cheap and easy to notice. If your microwave undercooks the food, you just run it another twenty seconds. The human closes the loop, so the machine does not have to.
- You cannot sense the thing you care about, or the sensor is too slow or noisy to trust. Then a carefully calibrated open-loop command may beat a jittery measurement.