systems engineering//error budget

An error budget is a table listing every source of error in a system, each carried to the same units at the same point of the loop, together with a rule for combining them; it is used to check whether a design meets its requirement before anything is bought, to decide which subsystem to improve first, and to split a system requirement into derived requirements for each team. A facade-inspection drone flying at 5 m/s with an RTK receiver must keep its along-track position error under 0.5 m 95 % of the time, which for a roughly Gaussian error means a standard deviation of about 0.25 m. The budget asks where the 0.25 m goes.

An error budget is a table listing every source of error in a system, each carried to the same units at the same point of the loop, together with a rule for combining them; it is used to check whether a design meets its requirement before anything is bought, to decide which subsystem to improve first, and to split a system requirement into derived requirements for each team. A facade-inspection drone flying at 5 m/s with an RTK receiver must keep its along-track position error under 0.5 m 95 % of the time, which for a roughly Gaussian error means a standard deviation of about 0.25 m. The budget asks where the 0.25 m goes.

Building one takes two steps. First, each source is translated into metres of position: a source with spread σx\sigma_xσx​ reaching the output through a function fff contributes σy≈∣∂f/∂x∣ σx\sigma_y\approx|\partial f/\partial x|,\sigma_xσy​≈∣∂f/∂x∣σx​, the same linearized propagation an EKF performs (uncertainty propagation). Three cases come out by themselves: a quantization step Δ\DeltaΔ gives Δ/12\Delta/\sqrt{12}Δ/12​; an uncompensated latency τ\tauτ at speed vvv shifts the position by vτv\tauvτ, a bias along the direction of motion; a clock offset δt\delta tδt between sensors gives v δtv,\delta tvδt. Second, the sources are combined, independent random ones by root sum square and biases and correlated ones linearly. For the drone, illustrative values of the right order (RTK 0.02 m, 50 ms latency giving 0.25 m, model 0.10 m, control 0.15 m, sync 0.025 m, estimation 0.05 m, the rest negligible) total 0.31 m by root sum square and 0.60 m in the worst case. The design fails.

Latency × speed25 cmModel error10 cmSensor desynchronization2.5 cmPosition sensor noise2.0 cmDiscretization, step Δt5.0 mmADC quantization0.9 mmTotal, root sum of squares27 cmWorst case, plain sum40 cmtotal, RSS27 cm worst case40 cm dominantlatency, 85 % without the dominant11 cm (−61 %) A drone at 5.0 m/s with six independent error sources. Their root sum of squares is 27 cm against a worst case of 40 cm; the latency carries 85 % of the variance, so removing it leaves 11 cm, while removing the smallest (quantization) leaves 27 cm.

Slide the latency down to 5 ms and watch the dominant source change; then push the speed to 10 m/s and see latency and sync grow with it until they take everything, while halving the sensor noise barely moves the total.

Fix the largest source first. A receiver ten times better moves the drone's total from 0.314 to 0.313 m, because latency carries 63 % of the variance. Timestamping every measurement and predicting it forward to the present costs almost no computation and cuts that term to 0.025 m: the total falls to 0.19 m and the design passes. Control now dominates; halve it and the model takes over. The error moved twice, and each time the budget said where (error relocation).

Do the sums at the worst operating point. At 10 m/s uncompensated latency alone contributes 0.5 m, the whole requirement, so a budget that passes in a hover can fail at cruise speed.

Check that fixing one source does not fatten another. A more aggressive controller follows the reference better and amplifies estimation noise; a heavier filter cuts sensor noise and adds latency.

The same budget, run backwards, is how a requirement becomes derived requirements: allocate the 0.25 m among sensor, latency, estimation and control, and each team designs to its share.

Walking the loop gives the list of sources: noise, bias, drift, aliasing and quantization at the sensor; what the model leaves out; badly chosen QQQ and RRR in the estimator; bias and unrepresentative data in what was learned; bandwidth and saturation in control; latency, jitter, synchronization and discretization on the platform (delay as the enemy, time synchronization). Usually one or two dominate.

A five-row table and a root sum square, done before buying anything, is among the most profitable tools in engineering; a Monte Carlo simulation is worth it only when sources are correlated or the system strongly nonlinear (Monte Carlo method). The budget belongs to systems engineering.