What's missing from ROS 2 diagnostics (and what we built)

Projects
, ,
3

You’re right, and I should have been clearer about what I’m comparing to what :sweat_smile:
rqt_robot_monitor and the diagnostic_aggregator are solid tools, I use them myself and I didn’t mean to dismiss that work.

The point I was trying to make isn’t about the visualization layer. rqt_robot_monitor does a good job showing you what’s happening right now. The gap I see is underneath that:

  • Hardware vs software diagnostics - REP 107 and rqt_robot_monitor are built around hardware monitoring: CPU load, sensor status, temperatures. But what about software faults? A navigation algorithm failing, a planning node crashing, a behavior tree entering an unexpected state, there’s no structured way to report and track those in the current diagnostic stack.

  • Fault lifecycle - REP 107 gives you OK/WARN/ERROR/STALE as a current snapshot. There’s no concept of a fault being reported, confirmed after debounce, healed, or cleared. Every status update is independent. If a sensor is flaky and toggles ERROR/OK 50 times in a minute, you get 50 callbacks with no filtering :see_no_evil_monkey:

  • Persistence - when rqt_robot_monitor shows an error and you close the window, it’s gone. There’s no fault history you can query later. “What faults happened last Tuesday between 2 and 3 PM?” - you can’t answer that without external logging.

  • Snapshots - “what was the robot doing when this fault happened?” In automotive, a DTC comes with a freeze frame (engine RPM, coolant temp, speed at the moment of failure). In ROS 2 there’s nothing like that. You’d need someone to have been running rosbag at the right time. We should be able to capture topic data automatically when a fault confirms.

  • Programmatic access - if a fleet management system or a CI pipeline needs to check robot health, it has to subscribe to DDS/ROS topics. There’s no REST endpoint, no way to query from outside the ROS ecosystem.

That’s the layer I’m comparing to automotive (OBD-II/UDS/SOVD) not the GUI (sorry if I was unclear and created confusion :folded_hands:). SOVD isn’t a dashboard, it’s a structured diagnostic data model with HTTP access, fault history, environment snapshots, and lifecycle states.

Thanks for your opinion!

3 Likes