Noise, Bias, and Uncertainty: Turning Raw Readings into Reliable Measurements

A unified view of sensor error

Robotic sensors differ in physics and interfaces, but their errors can be described with a shared vocabulary. This helps you compare modalities, combine measurements, and specify requirements without getting lost in device-specific details.

A convenient starting point is a simple measurement model:

z = h(x) + b + n

where z is the sensor reading, x is the true quantity of interest (possibly a vector), h(·) maps the true quantity into the sensor’s ideal output (often identity), b is bias (systematic offset), and n is noise (random variation). In practice, b may change slowly over time (drift), and n may be non-Gaussian or state-dependent.

Noise vs bias vs drift

• Noise: fast, random fluctuations around the expected value. If you hold the true input constant, noise makes repeated readings differ. Noise is often summarized by variance or standard deviation.
• Bias: a consistent offset (or scale error) that shifts readings away from the truth in a repeatable way. Averaging many samples does not remove bias.
• Drift: bias that changes over time (e.g., due to temperature, aging, warm-up, supply voltage). Drift can be slow and may look like a trend in a time series.

Many real sensors also exhibit scale factor error (multiplicative bias) and nonlinearity (bias depends on the true value). A slightly richer scalar model is:

z = (1 + s) x + b + n

with s a small scale error. This matters when you compute derived quantities (e.g., distance traveled, energy, torque) because multiplicative errors grow with magnitude.

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

Repeatability vs accuracy

• Repeatability (precision): how tightly clustered repeated measurements are under identical conditions. High repeatability implies low noise.
• Accuracy: how close measurements are to the true value. Accuracy depends on both noise and bias (and calibration quality).

Two sensors can have the same repeatability but different accuracy (one is consistently offset). Conversely, a sensor can be unbiased on average but noisy, giving poor repeatability.

Uncertainty as a quantitative language

Uncertainty is a structured way to express how much you trust a measurement. In robotics, uncertainty is often represented as a variance (scalar) or covariance matrix (vector), enabling consistent propagation through computations.

Mean and variance (core tools)

Given samples z1..zN of a reading under (approximately) constant conditions:

• Sample mean: z̄ = (1/N) Σ zi
• Sample variance: s² = (1/(N-1)) Σ (zi - z̄)²

Interpretation: the mean estimates the expected value; the variance estimates noise power. If the sensor is unbiased and conditions are stable, z̄ approaches the true value as N grows. If there is bias, z̄ approaches the biased value.

Confidence intervals (intuition, not ritual)

If noise is roughly Gaussian with standard deviation σ, then about 68% of samples lie within ±1σ of the mean, and about 95% within ±2σ. For the mean of N independent samples, the standard deviation shrinks to σ/√N. This is why averaging can reduce noise but cannot remove bias.

In robotics, use this intuition to answer practical questions: “If I average 20 samples, how much does the jitter reduce?” and “Is the remaining uncertainty small enough for the control or planning decision?”

Outliers and robustness

Real robot data often contains outliers: rare, large deviations caused by interference, reflections, missed detections, packet corruption, or transient mechanical events. Outliers can dominate averages and least-squares fits, so you need detection or robust statistics.

Simple outlier detection methods

• Thresholding by physical plausibility: reject values outside feasible bounds (e.g., negative distance, impossible acceleration, impossible joint angle).
• Z-score gating: compute z̄ and s over a window; flag samples with |zi - z̄| > k s (often k in 3–5). Works best when the baseline distribution is roughly unimodal and stable.
• Median and MAD (median absolute deviation): robust to outliers. Compute median m, then MAD = median(|zi - m|). Flag if |zi - m| is large relative to MAD.
• Temporal consistency checks: compare against a predicted value from a simple motion model; reject if the jump is too large for the robot’s dynamics.

Outlier handling should be paired with logging and counters: frequent outliers are a symptom of a deeper issue (environment, mounting, timing, power, or algorithmic assumptions).

Uncertainty propagation for derived quantities

Robots rarely use raw readings directly; they compute derived quantities such as velocity from position, heading from multiple sensors, or distance-to-goal from pose estimates. Uncertainty must be propagated through these computations to avoid overconfidence.

Rule of thumb: linearize and propagate variance

For a derived scalar quantity y = f(x) where x has variance σx², a first-order approximation gives:

σy² ≈ (df/dx)² σx²

For multiple inputs x (vector) with covariance Σx, and Jacobian J = ∂f/∂x:

Σy ≈ J Σx Jᵀ

This is the backbone of many robotics estimators: you don’t need heavy math to use it; you need to identify the function and compute sensitivities.

Example: velocity from position (finite differences)

Suppose you estimate velocity from two position samples:

v = (p2 - p1) / Δt

If p1 and p2 have independent noise with variance σp², then:

var(p2 - p1) = σp² + σp² = 2σp²

So the velocity variance is approximately:

σv² ≈ (2σp²) / (Δt²)

Key implication: decreasing Δt (higher-rate differentiation) amplifies noise as 1/Δt². This is why raw differentiation often looks “noisy” even when position looks stable. Smoothing position (or using a model-based estimator) trades latency for reduced velocity noise.

Timing uncertainty matters

If Δt itself is uncertain (timestamp jitter), it introduces additional error. A practical approximation for small timing error δt is that velocity error grows with both measurement noise and timing jitter. If you see occasional spikes in derived velocity, suspect timestamp irregularities before blaming the sensor.

Measurement models: from “a number” to “a statement”

A measurement model specifies what the reading means and how uncertain it is. In robotics, this is often expressed as:

• Observation function z = h(x): how the true state maps to an ideal measurement.
• Noise model: distribution and parameters (often Gaussian with covariance R).
• Validity conditions: when the model applies (range limits, line-of-sight, contact state, lighting, temperature band, etc.).

Even if you do not implement a full probabilistic filter, writing down h(·), a plausible R, and validity conditions forces clarity: it tells you what to log, what to test, and what failure modes to detect.

Bias and drift in measurement models

Bias can be treated as:

• A constant parameter estimated during calibration and then fixed.
• An additional state that evolves slowly (drift), e.g., b(k+1) = b(k) + w where w is small process noise. This captures gradual changes without overreacting to short-term noise.

Choosing between these depends on how stable the bias is in your environment and over your mission duration.

Practical workflow: data logging and sanity checks

Before tuning algorithms, confirm the data is real, correctly scaled, and correctly timed. Many “sensor problems” are actually logging, unit, or synchronization problems.

Step-by-step: set up a logging session

1. Log raw readings (before filtering), plus any driver status flags (valid/invalid, saturation, error codes).
2. Log timestamps from a consistent clock domain. Record both sensor-provided timestamps (if available) and host receipt times.
3. Log configuration: sampling rate, ranges, gains, exposure/integration time, filtering settings, and firmware versions.
4. Log context: robot mode, commanded motion, environment notes (lighting, temperature, surface type), and power state.

Time series plots: what to look for

• Noise level: small rapid fluctuations around a baseline.
• Bias: baseline offset from expected value under a known condition (e.g., “should be zero”).
• Drift: slow trend over minutes (warm-up) or with temperature changes.
• Quantization: stair-step patterns indicating limited resolution.
• Dropouts: missing samples, repeated identical values, or invalid flags.
• Periodic interference: oscillations correlated with motors, PWM, or communication cycles.

Histograms: distribution and outliers

Plot a histogram of readings during a steady condition. Use it to check:

• Center: is the peak where you expect (bias)?
• Spread: does the width match your needed precision?
• Shape: is it roughly bell-shaped, skewed, or multi-modal (suggesting multiple regimes)?
• Outliers: isolated bins far from the main mass.

A multi-modal histogram often indicates the sensor is switching between states (e.g., valid/invalid, different surfaces, intermittent contact), or that your dataset mixes different operating conditions.

Detecting saturation and clipping

Saturation occurs when the true signal exceeds the sensor’s measurable range; clipping is how it appears in data (values stuck at min/max). Detect it by:

• Counting samples at exact limits (e.g., equals max code or min code).
• Flat tops in time series during dynamic motion.
• Asymmetric histograms with a pile-up at an endpoint.

Clipping is dangerous because it can look “stable” (low variance) while being wrong. If you see clipping, adjust range/gain or redesign the operating envelope.

Verifying timing and sample rate

Timing errors can silently break derived quantities and sensor fusion. Perform these checks:

• Inter-sample interval: compute Δt = t(k) - t(k-1) and plot it. Look for jitter, spikes, or long gaps.
• Effective rate: compare mean Δt to the configured sampling period.
• Monotonic timestamps: ensure timestamps never go backward.
• Alignment across streams: if you log multiple sensors, compare event timing (e.g., a commanded step motion should appear consistently delayed, not randomly shifted).

If you must use host receipt times, expect extra jitter; mitigate by buffering, using sensor timestamps when possible, and avoiding differentiation on irregularly sampled data without resampling.

Sanity checks with known conditions

• Zero-input test: measure when the true quantity should be zero (or constant). Estimate bias and noise.
• Two-point check: measure at two known reference points to detect offset and scale issues.
• Repeatability test: repeat the same motion/condition multiple times; compare distributions.
• Environmental sweep: vary temperature, lighting, or load within expected operating bounds; observe drift and failure rates.

Guidelines for specifying sensor requirements

Requirements should be written in terms of what the robot must accomplish, not just sensor marketing numbers. Use the unified error framework to translate task needs into measurable specs.

Define acceptable error bounds (and where they apply)

• Accuracy bound: maximum allowable systematic error after calibration (e.g., offset and scale within limits).
• Noise bound: allowable standard deviation (or variance) under specified conditions and bandwidth.
• Drift bound: maximum change in bias over a mission time or temperature range.
• Operating envelope: ranges of distance/force/illumination/temperature where the bounds must hold.

State bounds with conditions: sampling rate, filtering, mounting, and environment. “±1 unit” without context is rarely testable.

Include failure detection needs

• Detectability: define what failures must be detected (stuck-at, saturation, dropout, implausible jumps, degraded noise).
• Latency: how quickly the system must flag a fault.
• False alarm tolerance: acceptable rate of incorrect fault flags.
• Safe fallback: what the robot should do when the measurement is invalid (hold last value, switch mode, reduce speed, stop).

Let environment and task set tolerances

Tolerances depend on what the robot does and where it operates:

• Control tasks (stabilization, tracking) are sensitive to noise and timing jitter; they often require low-latency, well-characterized variance.
• Mapping and planning are sensitive to bias and drift over long horizons; they require stable calibration and drift management.
• Safety-related interaction requires clear saturation behavior, reliable fault flags, and conservative uncertainty assumptions.

When in doubt, specify uncertainty at the level of the derived quantity you actually use (e.g., velocity uncertainty, not just position noise), including the effects of sampling period and computation.