hardware-watchdog

Implement layered MCU, ROS 2, and hardware watchdogs for robot safety stops.

18|2|Updated Apr 20, 2026
One-click install
npx skills add https://github.com/wimblerobotics/ros2-copilot-skills --skill hardware-watchdog
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hardware-watchdog
Source: https://github.com/wimblerobotics/ros2-copilot-skills/tree/main/hardware-watchdog
Command: npx skills add https://github.com/wimblerobotics/ros2-copilot-skills --skill hardware-watchdog

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

If the ROS 2 host or controller firmware dies or communicates fail, the robot can continue driving with stale commands, risking collisions. This Skill defines a multi-layer watchdog strategy to guarantee safe motor states by combining MCU software watchdogs, hardware watchdog timers, ROS 2 watchdog nodes, and a robust safety chain.

Core Features & Use Cases

  • Layer 1: MCU Software Watchdog using IntervalTimer to detect missed host packets and trigger safe motor stops.
  • Layer 2: Hardware Watchdog Timer (WDT) to reset the MCU if the firmware hangs beyond the configured timeout.
  • Layer 3: ROS 2 Watchdog Node to monitor /cmd_vel flow and publish zero velocity on timeout, with status flags.
  • Layer 4: Velocity Multiplexer Priority to ensure safety commands override navigation when a fault is detected.
  • Layer 5: Physical Emergency Stop to cut power to motor drivers, independent of software.
  • Heartbeat Protocol and complete safety chain to coordinate failures across layers.
  • Testing guidelines to verify behavior under node failure, USB unplug, MCU hang, and e-stop.

Quick Start

Enable and validate the multi-layer watchdog system across MCU software watchdog, hardware watchdog, ROS 2 watchdog, and safety stop sequences.

Frequently Asked Questions about hardware-watchdog

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement a safety watchdog for a ROS 2 robot to stop motors on communication failure?

Implement a ROS 2 watchdog by monitoring the /cmd_vel topic flow and automatically publishing zero velocity commands when a timeout occurs, ensuring motors stop safely if the host or controller dies. A multi-layer strategy extends this protection across MCU and hardware systems.

What is a multi-layer watchdog strategy for embedded robotics firmware?

A multi-layer watchdog strategy combines MCU software watchdogs using IntervalTimer, hardware watchdog timers (WDT) for firmware resets, ROS 2 monitoring nodes, and physical e-stops to guarantee safe motor states during serial timeouts or system hangs.

How do I ensure emergency stop commands override navigation in ROS 2?

Use a velocity multiplexer (twist_mux) with safety prioritization to ensure emergency stop and watchdog zero-velocity commands override navigation inputs when a fault is detected across the safety chain.

Can I use a hardware watchdog timer to reset the MCU if firmware hangs?

Yes, a hardware watchdog timer (WDT) resets the MCU if the firmware hangs beyond a configured timeout, providing a critical recovery layer independent of software execution.

How do I test a robot safety chain for node failures and USB disconnects?

Test the safety chain by simulating node failures, unplugging USB connections, triggering MCU hangs, and engaging the physical e-stop to verify that heartbeat protocols and watchdog timers correctly trigger safe motor stops.

Do I need a physical emergency stop if I already have software watchdogs?

Yes, a physical emergency stop is necessary to cut power directly to motor drivers independently of software, providing a final failsafe layer if firmware, host, or MCU watchdogs fail.