A slow sensor ruins a fast controller
Why measurement rate limits how well a system can be controlled.
A slow sensor ruins a fast controller because no controller, however capable its processor or however cleverly tuned its correction, can react to a change it has not yet been told about, so a control loop able to compute a fresh correction a thousand times a second gains nothing from that speed if the sensor feeding it fresh information only manages to do so ten times a second, leaving the controller confidently recalculating the same stale number over and over between each real update.
A stable mechanism began oscillating after a heavier arm was fitted, and nothing in the software had changed. The instinct was to suspect the tuning, since nothing else on paper had changed, but the real culprit turned out to be a sensor that had always been slightly too slow for the job, a weakness the lighter, slower-moving arm had simply never been quick enough to expose in the first place.
The physics of sensor lag
A control loop's controller can only be as fast as the least frequent piece of information it depends on, and a sensor's own update rate sets a hard ceiling on that, regardless of how quickly the controller itself is theoretically capable of computing a new correction. Between two consecutive sensor readings, the real system may have moved considerably, especially if it is fast-moving or lightly damped, and the controller has no way of knowing that movement happened until the next reading finally arrives, at which point it is reacting to a change that may already be well underway rather than one just beginning. A controller tuned aggressively, expecting to correct promptly on fresh information, instead ends up correcting in occasional large jolts, timed to whenever the slow sensor happens to update, and those jolts, arriving late and sized for an error that has already grown larger than it should have been allowed to, are exactly the kind of behaviour that tips a system past the gain limit covered earlier in this collection and into open oscillation.
The strobe-light comparison
Trying to catch a fast-moving ball lit only by a strobe light flashing once a second is a vivid demonstration of exactly this limitation. Between flashes the ball could easily have travelled a metre or more, and no matter how sharp the reflexes of the person trying to catch it, those reflexes cannot respond to a position they have not yet been shown. The catcher's own reaction speed is not the bottleneck at all, the strobe's flash rate is, and a faster pair of hands attached to the same slow strobe gains nothing, since there is simply no new information for those faster hands to act on between flashes. A fast controller paired with a slow sensor is in exactly the same position, its own quick reactions wasted on a stream of information that only actually updates a fraction as often as the controller is capable of using it.
Why the heavier arm exposed the weakness
A heavier arm moves more slowly for the same applied force and, once disturbed, drifts further between one sensor reading and the next simply because its own momentum carries it further in the same slice of time a lighter, quicker arm would have covered in a smaller distance. The sensor's update rate had not changed at all, since it was still the very same part bolted in the very same place, but the gap between updates, measured in how far the mechanism could travel during that gap, had grown substantially larger, and a controller tuned assuming the arm's old, lighter behaviour found itself reacting to positions that were now noticeably out of date by the time each correction was finally computed and applied.
One figure worth keeping in mind
A sensor updating only a few dozen times a second can look perfectly adequate on a slow-moving mechanism and become a genuine bottleneck on a fast one, since the same fixed gap between readings represents a tiny, irrelevant sliver of travel on the slow mechanism and a large, consequential one on the fast mechanism, even though the sensor itself has not changed in any way at all, and nothing about its specification sheet ever warned that it would.
Where this fits with the delay problem already covered
A slow sensor is a specific, common case of the general delay problem already covered in this collection, but it is worth separating from the broader idea because the fix is different in an important way. Delay caused by a slow actuator or a slow physical process often cannot be shortened much without changing the underlying hardware or the physics involved, but delay caused by a slow sensor is frequently the cheapest kind to fix outright, since faster sensors covering the same physical quantity are very often available off the shelf, at a real but modest cost, in a way that a faster chemical reaction or a lighter physical mass rarely is. Recognising a slow sensor specifically, rather than lumping it in with delay in general, matters because it points toward the single most likely place a real improvement can actually be bought.
What this changes in practice
Diagnosing an oscillating system starts, once this limitation is understood, with checking whether the sensor can actually keep pace with how quickly the real system moves rather than assuming the fault must lie in the tuning, since a controller cannot be tuned around a sensor that simply is not fast enough to support the correction speed the tuning is asking it to deliver. A faster sensor, or a controller deliberately tuned more gently to match the sensor already installed, are the only two honest fixes, and no amount of adjusting gains alone will ever substitute for either one, no matter how many hours are spent chasing the problem in software that was never really where the problem lived.