Noise, Delay, and Safe Stopping

Why can a robot keep moving after danger appears?

A robot does not react at the instant the world changes. A sensor samples, software transports and processes the sample, the controller decides, the actuator responds, and the body decelerates. The total distance before rest is therefore more than braking distance.

Learning objectives

You will be able to:

• distinguish measurement noise from delay;
• build a latency budget from sensing through actuation;
• estimate stopping distance as reaction distance plus braking distance;
• explain why filtering, saturation, watchdogs, and independent stop paths change safety evidence.

Mental model: noisy evidence arrives late

Noise changes the reported value even when the physical state is similar. Delay makes a correct measurement describe an older state. Filtering may quiet jitter, but an overly slow filter can add lag. Saturation means a controller cannot command more than the actuator can deliver.

Use this evidence chain:

sense → timestamp → transport → estimate → decide → command → brake → verify stopped

If any link is stale, missing, or bounded, the robot needs a defined safe response.

Worked example: a delayed stop

A rover travels at v = 1.2 m/s. Its end-to-end reaction delay is t = 0.25 s. Once braking begins, its measured deceleration is a = 2.0 m/s².

Reaction distance:

d_reaction = v × t = 1.2 × 0.25 = 0.30 m

Idealized braking distance under constant deceleration:

d_brake = v² / (2a) = 1.2² / 4.0 = 0.36 m

Nominal stopping distance:

d_stop = d_reaction + d_brake = 0.66 m

That is not yet a safety boundary. Real designs add evidence-based margin for timing variation, surface changes, measurement error, actuator limits, and uncertainty. Test the complete stop path under worst credible conditions.

Noise is not delay

Suppose a range sensor alternates between 0.98 m and 1.02 m around a stationary obstacle. That is noise. Suppose it consistently reports the obstacle position 200 ms late. That is delay. A median or low-pass filter can reject spikes, but filtering old samples more heavily may increase effective delay. Evaluate both jitter and age.

Retrieval pause

A smooth range signal is 400 ms old. Is it trustworthy for a fast stop? Explain using both accuracy and freshness.

Saturation changes the promise

If a controller requests -1.0 braking but the drive can apply only -0.5, the applied command—not the request—sets deceleration. Log both. One successful stop on a high-friction floor does not prove the same stop on dust, carpet, slope, low battery, or payload change.

A layered stop design

1. Normal control: slows or stops from planned behavior.
2. Watchdog: commands a safe state when messages are stale or missing.
3. Independent collision monitor: uses defined zones to slow or stop without waiting for the main planner.
4. Safety-rated hardware: when risk demands it, use rated devices and a qualified safety process. A ROS node alone is not certification.
5. Recovery gate: clear the cause, reset stale goals, verify the scene, then deliberately restart. Do not automatically resume old motion.

Misconception checks

• “A smoother signal is always safer.” No: smoothing can add delay.
• “Commanding zero means stopped.” No: momentum and actuator dynamics remain.
• “An emergency-stop button is just another software message.” No: required safety functions may need independent, safety-rated hardware.
• “After the obstacle leaves, resume immediately.” No: verify state and invalidate stale goals first.

Summary

Stopping evidence is a budget: perception and computation consume time, the robot travels during that time, and braking consumes distance. Treat noise, delay, saturation, watchdog behavior, and recovery as measurable parts of one safety case.

Further learning

• WPILib Filters
• Nav2 Collision Monitor
• Universal Robots robot state helper