Keeping localization when a sensor fails

1. Engineering problem

Sensors drop out: GNSS in a tunnel, a camera in the dark, a LiDAR blocked by dust. The filter should keep estimating from what remains, report growing uncertainty honestly, and the robot should respond before the uncertainty becomes unsafe.

2. When is this needed?

• Designing fault handling for localisation.
• Setting speed limits as a function of uncertainty.
• Reviewing a system before field use.

3. Selection and design decisions

The robot_localization documentation (read 2026-11-06) defines sensor_timeout: after that period “we consider any sensor to have timed out. In this event, we carry out a predict cycle on the EKF without correcting it.” It also states that the filter will not begin computation until it receives at least one message from one of the inputs. During prediction-only operation the covariance grows with the process noise, so the reported uncertainty is the signal to monitor.

4. Advantages and disadvantages

• Conservative uncertainty limits stop the robot more often and avoid collisions.
• Redundant sensors cost integration and keep running.
• Fast recovery after the sensor returns needs gating to accept the correction (see the outlier guide).

5. Requirements and constraints

• The uncertainty at which the robot slows or stops is derived from the clearance and the stopping distance.
• Sensor timeouts are set per sensor from its rate.
• Each failure has a tested fallback.

6. Architecture

sensor timeout ─▶ predict only ─▶ covariance grows ─▶ speed limit shrinks ─▶ stop at uncertainty limit ─▶ re-localise on recovery

7. Implementation

1. List the sensors and the failure of each.
2. Set the sensor timeout from the sensor rate.
3. Estimate how fast the covariance grows without that sensor (below).
4. Set a speed limit or a stop that depends on the reported uncertainty.
5. Test by disconnecting each sensor in turn.

import math
def variance_after_outage(p0, q_per_s, outage_s, dt=0.1):
    p, t = p0, 0.0
    while t < outage_s - 1e-9:
        p += q_per_s * dt                          # prediction only: no correction, so uncertainty grows
        t += dt
    return p
p0, q = 0.0004, 0.01                               # 2 cm std at start; 0.01 m^2 per second of drift (illustrative)
for outage in (0, 2, 5, 10):
    p = variance_after_outage(p0, q, outage)
    print(f"outage {outage:2d} s: position std {math.sqrt(p):.2f} m")
limit = 0.5
t = (limit ** 2 - p0) / q
print(f"std exceeds {limit} m after about {t:.1f} s without corrections: slow down or stop before then")

Printed (checked by the site’s tests):

outage  0 s: position std 0.02 m
outage  2 s: position std 0.14 m
outage  5 s: position std 0.22 m
outage 10 s: position std 0.32 m
std exceeds 0.5 m after about 25.0 s without corrections: slow down or stop before then

Reading it: with an assumed process noise of 0.01 m² per second, the position standard deviation grows from 0.02 m to 0.14 m in 2 s, 0.22 m in 5 s and 0.32 m in 10 s, and would pass 0.5 m after about 25 s without any correction (in this simplified model it is a random walk in position; a real filter with velocity states grows faster). The values are illustrative.

8. Real examples

• Outdoor to indoor transition: GNSS drops at the door; LiDAR localisation takes over (see the handover guides).

9. Failure scenarios

• A robot that continues at full speed on a prediction with growing uncertainty.
• A timeout much longer than the sensor period, so stale data is used.
• No test of the fallback.

10. Troubleshooting

1. Record the covariance during a deliberate outage.
2. Check that the speed limit follows the uncertainty.
3. Check recovery: the first measurement after an outage should not be rejected wrongly.

11. Validation

• The example prints the lines shown (executed by the site tests).
• Disconnecting each sensor produces the designed behaviour.

12. Engineering checklist

• Failures listed
• Timeouts set
• Uncertainty growth estimated
• Speed and stop limits tied to uncertainty
• Each fallback tested
• Recovery tested

13. Further references

• robot_localization documentation (ros2 branch): state_estimation_nodes.rst and params/ekf.yaml, read 2026-11-06.

Related on FixTheRobot