Summary
In the systems I work on, we are still primarily on ROS 1 (I know, I know).
This means most of our nodes are in ROS 1. We bridge various topics to the ROS 2 system and as mentioned in #527 we have an effectively equivalent method of reporting fault codes through ros diagnostics. So I'm primarily relying on the diagnostic stream for the initial stages of integrating medkit into our robots.
When setting up the diagnostic bridge on our systems, I found that everything is reported under the /diagnostic_bridge application. Which makes sense in the current implementation. However if I'm defining components/apps for the hardware on our robots such as lidars, cameras, etc, then I'd expect to see the fault codes we have defined appear under "Faults" tab in the web ui for those specific devices.
Proposed solution (optional)
Pass the hardware_id of the diagnostic message through as the source id in the diagnostic bridge.
Now it's not necessarily the case that the hardware_id will match the node name but this feels like a reasonable incremental step (and I have thoughts on additions to this). And it's pretty easy to make the hardware ID node name.
Additional context (optional)
I'll have a PR up momentarily :)
Summary
In the systems I work on, we are still primarily on ROS 1 (I know, I know).
This means most of our nodes are in ROS 1. We bridge various topics to the ROS 2 system and as mentioned in #527 we have an effectively equivalent method of reporting fault codes through ros diagnostics. So I'm primarily relying on the diagnostic stream for the initial stages of integrating medkit into our robots.
When setting up the diagnostic bridge on our systems, I found that everything is reported under the
/diagnostic_bridgeapplication. Which makes sense in the current implementation. However if I'm defining components/apps for the hardware on our robots such as lidars, cameras, etc, then I'd expect to see the fault codes we have defined appear under "Faults" tab in the web ui for those specific devices.Proposed solution (optional)
Pass the
hardware_idof the diagnostic message through as the source id in the diagnostic bridge.Now it's not necessarily the case that the
hardware_idwill match the node name but this feels like a reasonable incremental step (and I have thoughts on additions to this). And it's pretty easy to make the hardware ID node name.Additional context (optional)
I'll have a PR up momentarily :)