How do I set up a fail-safe controller for emergency stop logic on a safety-critical mobile robot?

Designing emergency-stop (E-stop) logic for a safety-critical mobile robot is a functional safety problem, not just a software feature. The safe pattern is to make the stop behavior fail-safe by default, use hardware-backed safety, and ensure a single fault does not prevent stopping.

Here’s a practical architecture.

1) Start with the safety goal

Define exactly what “safe stop” means for your robot:

• What hazards are possible?
  • collision with people
  • runaway motion
  • arm/crusher pinch points
  • dropped load
• What stop response is required?
  • Stop Category 0: immediate removal of power to motion
  • Stop Category 1: controlled stop, then power removal
• What conditions require E-stop?
  • physical E-stop button
  • safety sensor trip
  • watchdog timeout
  • drive fault
  • loss of comms to main controller
  • overcurrent / overspeed / encoder fault
  • localization failure, if relevant to hazard

For mobile robots, the typical safe response is:
disable propulsion, apply brake if available, and remove torque command within a bounded time.

2) Use a safety controller, not the main robot CPU

Do not implement E-stop only in the application computer or ROS node.

Use a dedicated safety-rated controller or safety PLC / safety MCU architecture that:

• has independent power and reset behavior
• monitors E-stop inputs directly
• can cut motion enable signals and/or contactors
• does not depend on the main autonomy stack to function

Common pattern:

• Main controller: navigation, planning, teleop, perception
• Safety controller: E-stop inputs, safety sensors, watchdog, safe outputs
• Motor drives: accept torque/enable only through safety chain

3) Prefer hardwired, de-energize-to-trip inputs

Your E-stop circuit should be designed so that a broken wire, unplugged connector, or loss of power causes a stop.

Typical principles:

• Use normally closed (NC) E-stop contacts
• Wire them in a series safety chain
• Any open circuit = stop condition
• Use dual-channel if you need higher integrity
• Monitor for shorts across channels and welded contacts if using safety-rated inputs

This is a classic fail-safe approach:

• power lost → outputs de-energize → robot stops
• wire broken → circuit opens → robot stops
• controller fault → safety outputs drop → robot stops

4) Use redundant stop mechanisms

A safe mobile robot usually has multiple independent ways to stop:

Primary stop

• Safety controller deasserts motor enable / STO

Secondary stop

• Hardware power contactor opens battery/motor power
• Brake engages if applicable

Tertiary stop

• Software command to drives to zero velocity
• Useful, but not the safety mechanism

For motor drives, the best option is usually:

• STO (Safe Torque Off) if supported
• or a safety-rated enable line
• plus power removal contactor for higher-risk systems

If your drive supports STO, use it. It is designed for this purpose.

5) Design the E-stop chain as a safety loop

A typical loop:

E-stop buttons / safety sensors / bumper switches / watchdog relay / overtravel / drive faults
→ safety input module / safety MCU
→ safety outputs
→ STO and/or contactor coil
→ motor power disabled

Important properties:

• No single software task should be able to bypass it
• No single sensor failure should permit motion when stop is required
• The default state after power-up should be not allowed to move until safety checks pass

6) Add a watchdog from main controller to safety controller

The autonomy computer should send a periodic heartbeat to the safety controller.

If heartbeat is missing for too long:

• safety controller assumes fault
• robot enters safe stop

Implement it so that:

• heartbeat must be refreshed continuously
• a frozen process does not count as healthy
• the watchdog timing is independent of the main CPU load

This catches:

• application crashes
• OS hangs
• network loss
• power brownouts on the main computer

7) Separate “stop request” from “resume”

A common mistake is making E-stop just a bit in software that clears automatically.

Use a latching stop:

• once E-stop is triggered, the system stays in safe state
• human intervention is required to clear
• restart requires explicit reset sequence
• reset should only be possible if the hazard is gone and inputs are healthy

For example:

1. E-stop pressed
2. motor power removed
3. fault latched
4. operator inspects
5. reset button pressed
6. safety controller performs self-check
7. motion is re-enabled

Do not auto-restart when an input recovers.

8) Monitor the stop path itself

It is not enough to command stop; you should verify it actually happened.

Useful feedback signals:

• drive “enabled” status
• contactor auxiliary contacts
• motor current near zero
• wheel speed zero
• brake engaged feedback
• STO channel status
• safety relay feedback loop

If stop is commanded but the system still reports torque, flag a fault and keep it latched.

9) Handle battery and power architecture carefully

For mobile robots, the battery system can be a hazard.

Questions to answer:

• Does the safety controller stay powered when propulsion power is cut?
• Is there a separate low-voltage safety supply?
• Can the robot still brake if the main traction power is removed?
• What happens during brownout?

Best practice:

• keep safety logic on an independent, protected supply
• use energy storage or braking path if needed for controlled stop
• design so loss of power does not create uncontrolled motion

10) Use safety-rated standards and components

Depending on your application and jurisdiction, reference relevant standards such as:

• ISO 3691-4 for driverless industrial trucks / mobile robots
• ISO 13849-1/-2 for safety-related control systems
• IEC 61508 for functional safety concepts
• possibly IEC 60204-1 for machinery electrical equipment

Choose components with appropriate safety ratings:

• E-stop buttons
• safety relays / PLC
• contactors
• STO-capable drives
• safety sensors

The required performance level depends on your hazard analysis.

11) Practical fail-safe implementation pattern

A robust architecture looks like this:

Inputs to safety controller

• E-stop mushroom switch channels A/B
• bumper strip
• safety lidar zone
• deadman switch, if teleop
• drive fault lines
• watchdog heartbeat from main computer
• battery undervoltage / overtemp / BMS fault
• contactor feedback

Safety controller logic

• continuously evaluate all safety inputs
• if any fault or stop condition:
  • drop STO
  • open main contactor
  • assert brake
  • latch fault
• only allow motion when:
  • all inputs healthy
  • reset performed
  • watchdog valid
  • outputs verified off/on as expected

Outputs

• motor enable / STO
• contactor coil
• brake release
• warning beacon / buzzer
• fault indicator to operator UI

12) Test for single faults and abuse cases

A fail-safe controller is only as good as its validation.

Test:

• unplug E-stop wire
• short one channel to 24V or GND
• freeze the main CPU
• kill network link
• brown out the main controller
• weld a contactor simulation if possible
• trigger reset during motion
• power-cycle at random states
• sensor stuck-on / stuck-off faults

Verify the robot always transitions to a safe state.

13) Common mistakes to avoid

• relying on software-only E-stop
• using normally open E-stop contacts
• auto-clearing stop conditions
• sharing one MCU for both autonomy and safety
• not checking contactor feedback
• using a contactor without suitable ratings for DC motor loads
• forgetting that “stop command” is not the same as “energy removed”
• letting reboot restore motion without explicit reset

14) A good minimal architecture

If you want a simple but strong baseline:

• dual-channel NC E-stop mushroom
• safety relay or safety PLC
• STO-capable motor drivers
• main contactor in the motor power path
• heartbeat watchdog from main CPU to safety relay/PLC
• latching fault state
• manual reset button
• feedback monitoring of contactor and drive enable

15) Final design principle

The key idea is:

If anything important fails, the robot must become less capable of motion, not more.

That means:

• open circuit → stop
• lost power → stop
• controller fault → stop
• uncertain state → stop
• only explicit, verified reset allows motion again

If you want, I can also give you:

1. a reference block diagram for the safety chain,
2. a sample state machine for E-stop logic, or
3. a parts-level implementation using a safety relay, safety PLC, or safety MCU.