THE LOOP
Feedback works because the system reacts to error before the error has changed too much.
A basic feedback controller compares a desired state with a measured state, forms an error, and chooses a command intended to reduce that error. In compact form, the loop looks harmless:
target → compare → controller → actuator → plant → sensor → compare again
The trick is that every arrow takes time. Sensors integrate. Filters buffer. networks queue. software schedules. buses arbitrate. actuators accelerate. structures flex. motors build current. valves move. cameras expose. estimators wait for enough data to update. Even if every component is individually fast, the round-trip loop can be slow enough to change the dynamics.
When the controller acts on a measurement that describes the system a few milliseconds ago, it is not correcting the current state. It is correcting an estimate of the past. If the system changes slowly, that distinction may be irrelevant. If the system is fast, lightly damped, unstable, or commanded aggressively, the distinction can be the whole problem.
PHASE
Delay rotates the relationship between cause and effect.
For a sinusoidal component at angular frequency ω, an ideal pure time delay τ contributes a phase shift of approximately:
phase lag = −ωτ radians
That means the same physical delay becomes more dangerous as frequency rises. At low frequency the system has plenty of time to react. At higher frequency the controller increasingly acts out of phase with the motion it is trying to suppress.
This is why control engineers care about phase margin. The loop can tolerate some additional phase lag before negative feedback effectively reaches the condition where it behaves like positive feedback around a critical frequency. Cross that boundary and a controller designed to damp motion can sustain or amplify oscillation instead.
The practical lesson is not that every delayed loop explodes. It is that delay consumes stability margin. A design with generous margin may shrug off added latency. A design already tuned close to the edge may become unstable after somebody adds a prettier filter, a slower camera, a network hop, or a debug layer that seemed operationally harmless.
LATENCY BUDGET
Measure the whole round trip, not the fastest component.
People routinely quote the sensor frame rate or controller cycle rate as though that number were the loop latency. It is not.
A 1 kHz controller nominally executes every millisecond. That does not guarantee the state estimate it consumes is one millisecond old. The sensor may have exposure or conversion latency. A bus may deliver the sample later. The estimator may wait for synchronization. The operating system may introduce jitter. The command may queue for the next actuator update. The actuator then has its own electromechanical or hydraulic response.
A useful latency budget records each stage:
measurement acquisition → preprocessing → timestamping → transport → synchronization → estimation → control calculation → command transport → actuator electronics → mechanical response.
The correct number is not always the mean. Tail latency and jitter matter. A loop that is normally 4 ms but occasionally 20 ms can behave differently from a truly constant 4 ms loop, especially if those long delays occur under high CPU load, high network load, or emergency states when control authority is already stressed.
SAMPLING
Fast sampling helps, but sampling rate is not magic.
Digital control adds discrete-time behavior. A sensor may sample at one rate, an estimator at another, the controller at another, and the actuator interface at yet another. If those clocks are not synchronized, effective delay can vary from cycle to cycle.
A high sample rate can reduce some forms of delay and improve the ability to observe fast dynamics, but it also increases computational load, bus traffic, and sensitivity to noisy high-frequency measurements. Running everything at the maximum available rate can therefore create the very scheduling jitter and filtering problems that increase effective latency elsewhere.
Sampling should be chosen relative to the dynamics being controlled, the estimator bandwidth, the desired closed-loop bandwidth, and the actual compute/transport budget. The engineering target is not the largest number in the device brochure. It is a loop fast and predictable enough for the plant.
FILTERS
Smoothing noise costs time.
Sensors are noisy, so engineers filter them. Filters are useful. Filters also introduce lag.
A low-pass filter that suppresses high-frequency noise inevitably changes amplitude and phase as frequency rises. An aggressive filter can make the measured signal beautifully smooth while making it too late to stabilize the motion that matters.
This trade is especially visible around derivative action. A derivative term responds strongly to rapid changes and therefore magnifies measurement noise. Engineers often filter the derivative estimate. Good. But the filter changes the phase behavior of the controller. If the filter is chosen only by looking at the time-domain trace until it appears less ugly, the resulting loop can lose margin invisibly.
Filtering therefore belongs in the control design, not in post-processing after the controller has supposedly been finished.
ESTIMATION
A state estimate can be precise and still be late.
Many robots do not control directly from raw measurements. They estimate position, velocity, orientation, load, contact state, or other hidden variables from multiple sensors. Estimation can dramatically improve robustness, but it also creates a temporal contract.
Suppose a vision pipeline produces an excellent pose estimate 80 ms after the photons arrived. For a slow mobile robot that may be fine. For a rapidly rotating aerial vehicle, 80 ms is ancient history. The right response may be prediction, faster sensing, a complementary high-rate inertial path, or a control architecture that uses different sensors at different bandwidths.
State estimators should therefore expose not only a value and covariance or confidence measure, but also the timestamp describing when that state was true. “Current pose” is a dangerous API if the value is actually a delayed reconstruction.
ACTUATORS
The command is not the motion.
Software can update a command immediately. Physical effectors cannot.
Motors have electrical and mechanical time constants. Hydraulic systems have pressure dynamics. pneumatic systems compress. gear trains have backlash and compliance. propellers spool. control surfaces move at finite rates. muscles and prosthetic actuators have delays. structures flex. thermal actuators may be glacial compared with the software telling them what to do.
If a controller assumes the actuator reaches each requested command instantly, then fast commands can accumulate faster than the plant can realize them. The controller observes continuing error, asks for more effort, and may overshoot badly once the actuator catches up.
Actuator dynamics belong in the plant model. When they are omitted, the controller is negotiating with an imaginary machine.
NETWORKED CONTROL
Putting Ethernet, Wi‑Fi, CAN, a hypervisor, or a cloud service inside the loop changes the loop.
Networked robotics can be extremely effective, but transport introduces variable delay, packet loss, retransmission behavior, buffering, clock synchronization problems, and failure modes that do not exist in a direct electrical connection.
Some traffic can tolerate this. Supervisory commands, mission planning, map updates, logs, and slow setpoints often live comfortably on non-deterministic networks. Inner stabilization loops usually deserve a much stricter timing path.
A useful architecture separates control by bandwidth. Fast loops stay close to the hardware. Slower loops can operate at higher levels and tolerate more communication uncertainty. If loss of the network immediately destabilizes the vehicle, the architecture has probably placed a critical loop farther away than necessary.
JITTER
Variable delay is its own problem.
A fixed delay can be modeled. Variable delay is harder because the loop dynamics change over time.
Operating-system scheduling, garbage collection, bus contention, camera buffering, thermal throttling, logging bursts, storage writes, network congestion, and shared accelerators can create latency jitter. The average loop rate may look excellent while the worst-case timing is unacceptable.
This is why real-time systems are obsessed with bounded behavior rather than just speed. A processor that finishes a task in 200 microseconds most of the time and 12 milliseconds occasionally may be less useful for a critical control loop than a slower processor that finishes predictably every time.
SIMULATION
Simulation often lies by being too punctual.
A physics model can be excellent while the simulated implementation path is unrealistically ideal.
If the controller receives a perfect state vector at exactly the requested time, computes instantly, and applies force with no actuator dynamics, the simulation has removed three of the most important real-world sources of phase lag. The resulting controller may be tuned aggressively because the simulated loop has stability margin that the physical system never gets.
Hardware-in-the-loop and timing-aware simulation are useful precisely because they put implementation constraints back into the experiment. Add measured sensor latency. Add command transport. Add actuator models. Add clock jitter. Add dropped frames. Add saturation. Then see whether the controller still deserves its confidence.
FIELD METHOD
How to investigate a suspicious loop.
1. Timestamp every boundary. Record acquisition time, estimator output time, control execution, command send, command receipt, and when actuator feedback confirms motion.
2. Plot age, not just rate. A 100 Hz stream can still contain 50 ms-old samples. Measure how old the information is when consumed.
3. Measure distributions. Median latency is not enough. Inspect high percentiles and worst observed cases under CPU, bus, thermal, and network stress.
4. Compare commanded and actual actuator behavior. The requested torque or position is not evidence that the actuator achieved it.
5. Sweep controller bandwidth conservatively. If oscillation appears as gain or bandwidth rises, inspect phase margin and unmodeled delay before blaming random noise.
6. Disable decorative processing temporarily. Extra smoothing, visualization, logging, and synchronization can be diagnostic suspects if they sit in the critical path.
7. Move fast loops closer to hardware where possible. The cleanest latency optimization is often architectural rather than algorithmic.
BOTTOM LINE
Feedback is a race between correction and change.
Control works when measurements are fresh enough, commands arrive soon enough, and actuators respond predictably enough that corrective action still points in the useful direction.
Delay spends phase margin. Jitter makes the price variable.
When a robot oscillates, overshoots, hunts, or becomes unstable only after the “real” software stack is connected, inspect time before inventing a more exotic explanation.
SOURCE TRAIL
Technical starting points.
MIT OpenCourseWare — Feedback Control Systems
MIT OpenCourseWare — Feedback and Control lecture
MIT OpenCourseWare — Analysis and Design of Feedback Control Systems