Sensor Noise, Bias, and Filtering in Robotics

Every robot acts on measurements that are noisy, delayed, biased, and sometimes missing. Treating a raw reading as truth is the fastest way to build a robot that behaves unpredictably. This guide covers the vocabulary and the trade-offs you need before trusting a sensor. Experiment with each effect in the Robot Sensor Simulator.

Noise, bias, and drift are different problems

• Noise varies randomly from sample to sample. Averaging or filtering reduces it.
• Bias is a fixed offset from the true value. Filtering will not remove it; you have to measure it during calibration and subtract it.
• Drift is a bias that changes slowly over time, usually with temperature. A calibration taken at startup gradually stops matching reality, which is why long runs need periodic recalibration or a reference to correct against.

Confusing these leads to the wrong fix—more filtering will never cure a bias.

Choosing a filter

Three common filters cover most cases:

• A moving average and an exponential low-pass both smooth random noise, trading responsiveness for smoothness through their window or time constant.
• A median filter is better at removing occasional spikes and dropouts, because a few bad samples do not move the middle value.

Pick the lightest filter that meets the requirement of whatever consumes the measurement—not the one that produces the smoothest-looking plot.

Filtering always adds lag

Every smoothing filter lags the true signal, and more smoothing means more lag. A low-pass filter with a long time constant rejects more noise but falls further behind fast changes. Always plot the filtered estimate against both the raw samples and the truth so the delay is visible before you put the filter inside a control loop, where lag can cause instability.

class LowPass:
    def __init__(self, alpha):
        self.alpha = alpha      # smaller alpha = smoother but more lag
        self.value = None
    def update(self, sample):
        if self.value is None:
            self.value = sample
        else:
            self.value += self.alpha * (sample - self.value)
        return self.value

What sensor fusion can and cannot do

Fusion combines several sensors into one estimate, and it helps only when the sensors contribute complementary information and their uncertainty is represented honestly. Combining two biased measurements does not create truth. A complementary filter, for example, trusts one sensor at high frequencies and another at low frequencies; a Kalman filter weights each source by its uncertainty. Either way, start with calibration, timestamps, and shared coordinate frames before fusing anything.

Timestamp everything

Samples rarely arrive at a perfectly fixed interval, and both filtering and fusion assume you know when each value was measured. Timestamps let you detect jitter, align data from different sensors, and reject stale readings. Log raw values beside processed ones so failures like clipping and dropouts stay reproducible.

Try it yourself

In the Robot Sensor Simulator you can dial in noise, bias, drift, and dropouts, then compare raw data against low-pass, moving-average, and median estimates. It is the quickest way to feel the noise-versus-lag trade-off—the same trade-off that decides how a robot reacts in the Obstacle Avoidance Simulator.