The D term causes most of the trouble

Why the derivative correction amplifies noise.

The derivative term causes most of the trouble in a real PID controller because it works by dividing a small difference between two closely spaced measurements by a very small interval of time, and that particular arithmetic, a small number divided by an even smaller one, has a habit of turning ordinary measurement noise, harmless on its own, into a wildly exaggerated and completely misleading signal the moment it is asked to represent a rate of change.

The short version

The proportional and integral terms both work on the error itself, a value that is naturally smoothed simply by being a single measurement at a single moment, however noisy that measurement might be in absolute terms. The derivative term works on something far more fragile, the difference between one measurement and the very next one, taken only a fraction of a second later, divided by that tiny time gap to estimate how quickly the error is currently changing. When the underlying signal is genuinely smooth, this works exactly as intended, producing a sensible estimate of the true rate of change. When the signal carries even a small amount of random noise, however, that noise gets compared against an equally small time interval, and dividing a small, essentially random fluctuation by an even smaller number of seconds routinely produces a computed rate of change many times larger and far more erratic than anything actually happening in the real system being measured.

The jittery-GPS comparison

A car's satellite-based speed reading is a familiar example of exactly this fragility. Cruising at a rock-steady sixty kilometres an hour on an open motorway, the GPS receiver's own reported speed still flickers by a kilometre or two either way from one reading to the next, an entirely normal artefact of how the underlying signal is calculated rather than any real change in the car's actual speed. Nobody driving the car feels any of that flicker, since the car itself is not accelerating or decelerating at all. But a system trying to compute the car's acceleration by comparing two of these jittery readings taken a fraction of a second apart, and dividing that tiny, essentially random difference by the tiny time between them, would report wild, meaningless surges of acceleration that have nothing to do with anything the car is actually doing, purely because ordinary reading-to-reading noise has been divided by an interval far too small to average any of it away.

Why smoothing the signal is not a complete fix

The obvious response to this fragility is to smooth or filter the measurement before differentiating it, averaging several recent readings together so a single noisy sample cannot dominate the calculation, and this genuinely helps, reducing how wildly the derivative term swings in response to ordinary noise. It is not a complete fix, however, because smoothing a signal also delays it slightly, averaging in older readings alongside the newest one, and a derivative term computed from a delayed signal is, by definition, reacting to slightly stale information, reintroducing a version of the overshoot problem covered earlier in this set that the derivative term was originally supposed to help prevent. Every practical controller using derivative correction is negotiating this same trade-off, filtering enough to tame the noise without filtering so much that the correction starts reacting too late to be useful, a balance found by trial rather than by any formula that settles it cleanly in advance.

One figure worth keeping in mind

A raw sensor signal carrying only a small amount of noise relative to its overall range, perhaps a fraction of a percent, easily overlooked when the signal itself is used directly, can produce a computed derivative many times noisier in relative terms, since the noise survives the division essentially unchanged while the true underlying rate of change, being smooth, often does not grow nearly as large by comparison, a mismatch that is exactly why the derivative term is so often the first thing turned down, or turned off entirely, when a real controller starts behaving erratically.

Where a coarse sensor makes the problem worse

A sensor that reports its measurement in coarse steps rather than a smooth continuous value makes the derivative term's vulnerability noticeably worse, since a value that can only report in whole units, jumping from one reading to the next rather than gliding between them, forces the derivative calculation to treat every one of those jumps as a real, sudden change even when the underlying quantity is moving perfectly smoothly. A finer, more continuous sensor gives the derivative term genuinely smoother material to work with, and upgrading a system's sensor resolution is often a more effective fix for erratic derivative behaviour than any amount of tuning the controller's own filtering, since no amount of smoothing after the fact fully recovers detail a coarse sensor never captured in the first place, having discarded it permanently the moment the measurement was rounded down to its nearest reportable step.

What this changes in practice

Recognising the derivative term's particular vulnerability to noise, rather than treating erratic controller behaviour as an unexplained mystery, changes how a real system actually gets tuned in practice, since a controller that oscillates or jumps unpredictably is often suffering from an overly aggressive or unfiltered derivative correction rather than from a poorly chosen proportional or integral gain. This is also why many practical controllers apply real, deliberate random vibration filtering specifically to the signal feeding the derivative term, accepting a small delay in exchange for a correction that responds to genuine trends in the system rather than to the ordinary statistical jitter every real sensor carries along with the measurement it was actually built to provide, and it is a large part of why some controllers, on systems where noise is severe and speed matters less, are tuned with no derivative correction at all rather than fighting this trade-off continuously.