Why systems overshoot
Momentum and delay, and why correction arrives too late.
Systems overshoot because whatever is being corrected, a temperature, a speed, a position, keeps changing for a while even after the correction meant to stop it has already been applied, so by the time that lingering change finally catches up with the correction, the system has already sailed past the target it was aiming for rather than arriving there and simply stopping.
The physics of overshoot
Overshoot has two closely related causes that often act together in the same system. The first is momentum in the broad sense, the tendency of anything already changing to keep changing briefly even after the force driving that change has been removed, a heated object continuing to warm for a moment after the heat source switches off, a moving mass continuing to travel after the force pushing it stops. The second is delay, the gap between a correction being applied and its full effect actually being felt somewhere the controller can measure, which means a controller reacting only to what it can currently measure is always, in a sense, reacting to slightly stale information, still pushing in a direction that was correct a moment ago but has since become too much. Either cause on its own is enough to produce overshoot, and together they compound, since a system with real momentum and a real delay between cause and effect has already committed to more change than the controller intended before that controller even has the chance to notice and pull back.
The oven-preheating comparison
Setting a kitchen oven to two hundred degrees and watching its internal thermometer climb reveals overshoot happening in real time. The oven's temperature does not rise smoothly up to two hundred and then stop, it typically climbs past that mark first, sometimes by a noticeable margin, before settling back down to the correct setting a few minutes later, a pattern visible on almost any oven fitted with its own internal thermometer rather than trusted purely on the dial. The heating element switches off exactly when the sensor reads the target temperature, doing everything correctly by that measurement, but the element itself and the metal around it are still hot, still radiating heat into the oven cavity for a while after the power has actually been cut, and that lingering heat is what carries the temperature on past the target before the oven finally cools back down to where it was actually meant to settle.
Why reacting only to the present is not enough
A controller that corrects purely based on the current error, with no sense of how quickly that error is closing or how much stored momentum the system is carrying, is structurally prone to this kind of overshoot, because it keeps applying correction right up until the exact instant the target is reached and only then, too late, starts easing off. By the time the correction actually stops, the system's own momentum has already carried it past the mark. This is precisely the gap the derivative term covered earlier in this set is built to close, reacting to how fast the error is shrinking rather than only to how large it currently is, easing the correction off in advance of reaching the target rather than waiting for the target to be reached before doing anything differently, anticipating the momentum rather than only ever discovering it after the fact.
The number that matters here
An underdamped system, one tuned or built with too little resistance to its own momentum, can overshoot its target by a substantial fraction of the original error before finally settling, and can take several full oscillations, swinging past the target and back again with each swing smaller than the last, before the swinging finally dies away completely, a behaviour explored further in the next article in this set. A well-damped system, by contrast, can be tuned to approach the same target with barely any overshoot at all, though usually at the cost of taking slightly longer to get there in the first place, a trade-off between speed and restraint that shows up constantly throughout control engineering and never fully resolves in either direction's favour.
Where overshoot cannot be designed away entirely
It is tempting to treat overshoot purely as an engineering problem waiting for a clever enough fix, but some amount of momentum and some amount of delay are simply physical facts about most real systems rather than flaws that better tuning can remove completely. A heavy mechanism genuinely takes real time and force to slow down once moving, and a sensor genuinely takes real time to register a change once it has happened, and no amount of clever correction erases either fact, it can only shape how the system responds around them rather than removing the underlying cause. This is why control engineers talk about managing overshoot rather than eliminating it, accepting that the honest goal is choosing how much of it a system can tolerate rather than chasing a perfectly flat approach to the target that the system's own physics will not actually allow.
Why this matters in practice
Once overshoot is understood as the predictable result of momentum and delay rather than a simple tuning mistake, it stops being surprising that eliminating it entirely is rarely free, since the very corrections that reduce overshoot, easing off early, adding damping, also tend to slow how quickly a system reaches its target in the first place. Designing around overshoot means deciding, deliberately, how much of that speed a particular application can afford to give up, a heating system tolerating a small swing gladly in exchange for reaching temperature faster, a precision instrument giving up considerable speed in exchange for arriving at its target without ever crossing it at all, and a positioning mechanism somewhere between the two, sacrificing just enough speed to keep any overshoot within whatever margin the rest of the machine can actually absorb safely.