FixTheRobot Explore Robotics / Systems Engineering / Engineering Guides / Module 18

Engineering Guides · Module 18

Safe states, e-stops and communication loss

Define what “safe” means for each failure, make the robot reach it by itself, and compute how far it travels getting there.

  • Intermediate
  • Module 18: Robotics Safety, Reliability & Failure Handling
  • Written for ROS 2 Jazzy where ROS 2 is used
  • Sources checked 2026-11-06

Assumptions: Numbers in the examples are illustrative and the code is executed by the site’s tests. Facts taken from a cited source are marked; other statements are general engineering knowledge and must be confirmed on the datasheet of the part you use.

1. Engineering problem

When the link to the operator or the planner drops, the robot should not keep driving on the last command. When something goes wrong the emergency stop should work without software. Both need a defined safe state and a computed stopping distance.

2. When is this needed?

  • Designing teleoperation or remote supervision.
  • Defining behaviour on Wi-Fi loss.
  • Specifying the emergency-stop chain.

3. Selection and design decisions

The diff_drive_controller of ros2_control offers a cmd_vel_timeout (default 0.5 s): a command older than the timeout is considered stale (parameter file read 2026-11-06), and the Nav2 velocity smoother can send a zero velocity after a timeout of no new commands (README read 2026-11-06). These are operational measures. An emergency stop that must protect people is a hardware function: it removes drive power or commands a safe torque-off through a circuit that does not depend on the main computer; designing and validating it is a safety-engineering task (standards not read here).

FailureSafe stateMechanism
Command link lostDecelerate to stopCommand timeout in the controller and the smoother
Planner or localisation lostSlow or stopWatchdog and health monitor
Emergency stop pressedDrive power removed or safe stopHardware circuit
Computer crashStopHardware watchdog in the drive controller
Battery or power faultControlled stop where possiblePower monitoring

4. Advantages and disadvantages

  • Short timeouts stop quickly and can cause stop-and-go on a poor link.
  • Controlled deceleration is gentle and takes distance; immediate torque removal stops fast and may skid or drop loads.
  • Brakes that hold at power loss are a safe default for some robots and a hazard for others.

5. Requirements and constraints

  • Worst-case distance after loss of the link fits the protective zone.
  • The emergency stop chain works with the computer off.
  • The safe state is reached by the robot, with no operator action.

6. Architecture

command source ─▶ timeout ─▶ decelerate ─▶ stop (software layer)
E-stop button ─▶ safety circuit ─▶ drive power off / safe torque off (hardware layer)

7. Implementation

  1. List failures and define the safe state for each.
  2. Set command timeouts and deceleration (below).
  3. Compute the worst-case distance for each.
  4. Build and test the hardware emergency-stop path.
  5. Test each failure on the robot.
def command_timeout_behaviour(last_cmd_age, v_now, decel, timeout=0.5, ramp=1.0):
    if last_cmd_age <= timeout:
        return v_now, "following commands"
    t = last_cmd_age - timeout
    v = max(0.0, v_now - decel * t)
    return v, "commands stale: decelerating" if v > 0 else "commands stale: stopped"
for age in (0.2, 0.6, 1.0, 1.6):
    v, why = command_timeout_behaviour(age, 1.0, 1.0)
    print(f"no command for {age:.1f} s: speed {v:.2f} m/s ({why})")
v0, a, to = 1.0, 1.0, 0.5
dist = v0 * to + v0 ** 2 / (2 * a)
print(f"worst case distance after losing the link at 1.0 m/s with a 0.5 s timeout and 1.0 m/s^2 braking: {dist:.2f} m")

Printed (checked by the site’s tests):

no command for 0.2 s: speed 1.00 m/s (following commands)
no command for 0.6 s: speed 0.90 m/s (commands stale: decelerating)
no command for 1.0 s: speed 0.50 m/s (commands stale: decelerating)
no command for 1.6 s: speed 0.00 m/s (commands stale: stopped)
worst case distance after losing the link at 1.0 m/s with a 0.5 s timeout and 1.0 m/s^2 braking: 1.00 m

Reading it: with a 0.5 s command timeout and 1.0 m/s² braking, a robot at 1.0 m/s that loses commands holds 1.00 m/s until 0.5 s, then slows to 0.90 m/s at 0.6 s, 0.50 m/s at 1.0 s and stops by 1.5 s; the worst-case distance is 1.00 m (0.5 m during the timeout plus 0.5 m braking). Values are illustrative.

8. Real examples

  • Teleoperated robot: link loss triggers a controlled stop within 1.5 s; the e-stop button cuts motor power directly.

9. Failure scenarios

  • Driving on indefinitely after the planner crashed.
  • An emergency stop routed through the application computer.
  • A timeout of several seconds at high speed.

10. Troubleshooting

  1. Test by unplugging the link while moving at each speed.
  2. Measure the real stopping distance.
  3. Check that nothing restarts motion automatically after a stop.

11. Validation

  • The behaviour example prints the lines shown (executed by the site tests).
  • Link-loss tests stop the robot within the computed distance at maximum speed.

12. Engineering checklist

13. Further references

Related on FixTheRobot