Emergency stop (E-stop)
Emergency stop (E-stop) – definition
An emergency stop, commonly called an E-stop, is a manually initiated safety function intended to stop a machine or mobile robot when an abnormal situation creates an immediate risk. In an unmanned ground vehicle (UGV), the E-stop function should bring hazardous motion to a safe state through a safety-related control path that overrides normal navigation, teleoperation, autonomy software, and ROS 2 communications.
ISO 13850:2015 defines the emergency stop function as a complementary protective measure. It is not a substitute for risk reduction by inherently safe design, guards, speed limits, obstacle detection, or normal stop controls. The function is intended for emergency situations and should be available to a person who needs to stop the platform quickly.
For a mobile UGV such as Leo Rover or Raph Rover, an E-stop normally initiates stopping and brings the drive system to a defined safe state. Depending on the electrical architecture and risk assessment, this can mean removing motor power, disabling motor-driver enable inputs, opening a safety contactor, or commanding a controlled stop followed by a power-removal state. The exact implementation must be verified against the platform documentation and the integrated payload configuration.
E-stop function versus a software stop
A ROS 2 node that publishes zero velocity is useful for normal operation, but it is not an emergency stop function by itself. A software command depends on the operating system, middleware, network, controller state, and motor-driver firmware. A fault in any of these layers can prevent the command from reaching the actuators.
The following controls have different purposes and should not be treated as equivalent:
| Control | Typical action | Safety relevance |
|---|---|---|
| ROS 2 velocity command | Publishes geometry_msgs/msg/Twist with zero linear and angular velocity |
Operational control only. It is not independent from the robot software stack. |
| Controller timeout | Stops motors when velocity commands are not refreshed within a configured timeout | Fault-mitigation feature. It does not replace a manually actuated E-stop. |
| Emergency stop | Transitions the platform into a safe stopped state through a dedicated safety path | Safety function. Its design follows the risk assessment and applicable machinery standards. |
| Emergency switching off | Disconnects electrical energy where electrical hazards require it | Different function from emergency stopping. It may be required in addition to an E-stop. |
ISO 13850 distinguishes stop category 0 and stop category 1, as defined in IEC 60204-1. Category 0 is stopping by immediate removal of power to machine actuators. Category 1 is a controlled stop with power retained until the stop is achieved, followed by power removal when the stop is achieved. The applicable category depends on the risk assessment, including braking behaviour, slope, payload inertia, wheel traction, and the consequences of uncontrolled coasting.
E-stop architecture for mobile UGV platforms
A practical UGV safety design separates the emergency stop path from the high-level compute path. The Raspberry Pi on Leo Rover can run ROS 2 Humble or a newer distribution, but it should not be the only component responsible for interrupting hazardous drive motion. The same principle applies when Raph Rover is equipped with a higher-payload sensor or compute configuration.
A typical architecture contains the following elements:
- A latching, manually actuated E-stop device with a red actuator and yellow background, as specified by ISO 13850.
- A safety relay, safety controller, or appropriately designed motor-power interruption circuit.
- A defined safe state for motor controllers, such as disabled drive enable, torque-off input, or disconnected traction power.
- A monitored feedback signal indicating that the E-stop circuit is active or that the drive system is inhibited.
- A deliberate reset process. Releasing or mechanically resetting the E-stop actuator must not automatically restart motion.
For field robots, the location of the actuator matters. The E-stop must remain reachable when a UGV carries a LiDAR, depth camera, GNSS/RTK receiver, battery enclosure, research payload, or protective frame. Added equipment must not obstruct access, damage the switch cable, or create a bypass around the safety circuit.
Using E-stop state in ROS 2
ROS 2 can expose E-stop state for diagnostics, user interfaces, logging, and autonomy supervision. It should report the state of an independent safety circuit rather than implement the only stopping mechanism. A hardware interface can publish a Boolean state, a diagnostic status, or a custom message indicating whether traction is inhibited.
The example below checks an E-stop status topic. It is suitable for monitoring during integration and testing, not for replacing a wired emergency-stop circuit. The ros2 topic hz command is useful only if the status is published periodically.
ros2 topic echo /emergency_stop
ros2 topic info /emergency_stop --verbose
ros2 topic hz /emergency_stopA common interface uses std_msgs/msg/Bool, where true means that the emergency stop is active. For more complete diagnostics, a driver can publish diagnostic_msgs/msg/DiagnosticArray with fields for circuit state, controller enable state, communication faults, and reset-required state. Interface names and message definitions should be documented in the robot-specific ROS 2 package.
Autonomy nodes should also react to the reported state. For example, Nav2 can be configured or supervised to prevent new motion commands, and a velocity multiplexer can block teleoperation input. These measures reduce the chance of unexpected software behaviour after a safety event, but the physical E-stop circuit remains authoritative.
Leo Rover and Raph Rover integration context
Leo Rover is a four-wheel differential-drive mobile platform with an IP55 rating and a built-in Raspberry Pi compute unit. It supports ROS 2 natively, but it is not an autonomous vehicle out of the box. A navigation stack, sensor integration, velocity limits, obstacle handling, and safety functions must be selected for the specific deployment.
When integrating LiDAR-based navigation, RGB-D perception, or outdoor GNSS/RTK localisation on Leo Rover, the E-stop should remain independent from sensor availability. Loss of localisation, a blocked camera, a failed ROS 2 node, or an invalid map must not be the only condition that stops the vehicle. These faults can trigger a normal software stop, while the E-stop remains available for immediate human intervention.
Raph Rover is intended for applications requiring a larger payload. Its increased mass, carried equipment, and operating environment can alter stopping distance and residual hazards. An E-stop design for Raph Rover should therefore be validated again after adding batteries, sensor masts, compute enclosures, or custom payloads. A configuration proven on Leo Rover should not be assumed to provide the same risk reduction on a larger platform.
Verification and applicable standards
E-stop verification includes both electrical tests and motion tests. The system should be tested with the robot stationary, during low-speed driving, under representative payload, and in the expected terrain conditions. Tests should confirm that actuation inhibits hazardous motion, that reset does not cause automatic restart, and that ROS 2 correctly reports the safety state.
The following documents are relevant references for an E-stop implementation on a mobile robot:
- ISO 13850:2015, Safety of machinery – Emergency stop function – Principles for design.
- ISO 12100:2010, Safety of machinery – General principles for design – Risk assessment and risk reduction.
- IEC 60204-1:2016+A1:2021, Safety of machinery – Electrical equipment of machines – Part 1: General requirements.
- ROS 2 documentation, for non-safety ROS interfaces, diagnostics, lifecycle nodes, and hardware integration.
- Leo Rover technical documentation, for platform-specific electrical and ROS 2 integration details.