Hi everyone,
Following the recent discussion around /cmd_vel, timeouts, stamped commands, and ros2_control, I realized there is a useful missing layer between vehicle-internal command execution and fleet-level observability.
I’ve updated ros2_kinematic_guard to explore that layer.
The project is no longer only a local /cmd_vel guard. It now also exposes command-execution-integrity telemetry.
The core idea is:
ROS 2 executes robot behavior.
Fleet systems coordinate robot behavior.
But something needs to report whether the recent command window is still trustworthy.
What changed
I added a reporter_node.py that translates the NARH Guard state into:
- ROS-native diagnostics
/diagnostics
diagnostic_msgs/DiagnosticArray
- VDA5050-style fleet telemetry
/command_integrity/vda5050_state
- Compact fleet-readable summary
/command_integrity/summary
Example output during a Wi-Fi collapse stress test
state=RESYNCING latency=CRITICAL R_NAR=5.478 vehicle_response=RESYNC_REQUIRED fleet_action=HOLD_NEW_ORDERS
state=RESYNCING latency=CRITICAL R_NAR=1412.078 vehicle_response=RESYNC_REQUIRED fleet_action=HOLD_NEW_ORDERS
state=RECOVERED latency=NORMAL R_NAR=0.000 vehicle_response=NONE fleet_action=NONE
This means the local command stream is not yet trusted again, and a fleet/orchestration layer could avoid assigning new orders, intersection-heavy tasks, or timing-critical maneuvers until the vehicle recovers.
Why this is different from a timeout
Timeouts answer:
Did a command arrive recently?
The NARH Guard asks:
Is the recent command/feedback window still trustworthy?
This is not meant to replace ros2_control controller-side mechanisms such as stamped references, speed limiting, timeouts, or smooth stop behavior.
Instead, the goal is to expose a higher-level signal that can be consumed by:
- ROS diagnostics
- bag / MCAP post-analysis
- fleet managers
- VDA5050-style orchestration layers
- heterogeneous robots that do not all run the same controller stack
| Failure Mode | Heartbeat / Timeout | NARH Kinematic Guard |
|---|---|---|
| Packet loss | Detects silence only | Detects silence + local predictive braking |
| Stale command | Often ignored | Detected via timing + kinematic drift |
| Burst command | Hidden by buffer | Detected via residual spikes |
| Replay/Out-of-order | Hard to catch | Caught via phase-continuity check |
| Command/Odom Conflict | Blind to physics | Directly measured consistency |
| Recovery Logic | Binary (On/Off) | State-aware resync gate |
| Fleet Visibility | Internal failure only | Structured telemetry (ROS/VDA5050) |
Repository:
I’d be very interested in feedback from anyone working on VDA 5050 bridges, mixed-fleet integration, ROS diagnostics, or fleet-level degraded-mode reporting.
Does a quantitative command-integrity signal like this fit any real orchestration or post-incident analysis needs you have seen?