Hi everyone, I want to sincerely thank @peci1, @chfritz, and @bmagyar for the deep technical insights here.
@bmagyar - You are completely right that ros2_control already handles command timeouts and speed limiters beautifully, and trying to replicate that at the /cmd_vel layer with hard stops was an architectural mistake on my part.
@chfritz - Your explanation of time-stamped causal links for remote teleop is spot on, and it made me rethink how I handle time windows.
@peci1 - Your opinion that “the active stop command needs to be adapted for different vehicles” is very accurate.
Based on all your feedback, I realized the community doesn’t need another controller overriding /cmd_vel. What is actually missing is visibility into physical execution failures (like wheel slip or localization jumps) when the commands do arrive safely but the robot physically fails to execute them.
I have completely refactored the project from a ‘guard’ into a passive diagnostics observer called runtime_integrity. It introduces zero control friction and simply publishes execution-consistency states to /diagnostics.
I just released v0.3-alpha and opened a new discussion here: https://discourse.openrobotics.org/t/release-runtime-integrity-v0-3-alpha-turning-command-to-physical-execution-consistency-into-standard-ros-diagnostics/55095?u=zc_liu. Thank you again!"