Additional levels in DiagnosticStatus

[nnarain]

I'd like to propose adding additional levels in the diagnostic_msgs/DiagnosticStatus message type.

I work on systems with large amounts of ROS diagnostics and it can often be hard to convey to end users what to focus on when issues occur. Now in ROS diagnostics world you can create custom analyzer plugins (and that's something I'm working on) but I still fine the OK, WARN and ERROR levels to be a bit limiting.

Taking some inspiration from OpenCyphal's Severity level message I'd propose the following for ROS

byte INFO=0       # Purely informational
byte OK=1         # Component's diagnostic is in an OK state
byte NOTICE=2     # Level at which user awareness might be recommended but action is not necessarily required
byte WARN=3       # Begin to bring awareness to users, as there might be an issue
byte ERROR=4      # An error condition has been detected
byte CRITICAL=5   # Failure is imminent 
byte ALERT=6      # User attention is required
byte STALE=7      # Reserved for use by the aggregator 

The distinction between INFO and OK would be in some cases we have a diagnostics that just report some values because it's convenient but the level is not expected to change, as opposed to a diagnostic reporting OK which might not always be OK.

The distinction between ERROR and CRITICAL would be the operational context. For example we do a lot of configuration checksum validation at startup. If there's a mismatch in what we expect that would be an ERROR. An example of a CRITICAL level might be critically low battery levels. This is not necessarily an error, it is a state of the battery (a BMS on the other hand could report errors and that could be an ERROR level diagnostic).

An example of ALERT might be usage of an emergency stop button. It's usage is not necessarily an error, but as it is related to safety we need to report it at the highest level possible.

The current OK, WARN and ERROR states remain the same. If nothing else I think NOTICE and ALERT would be valuable additions.

In terms of impact to existing functionality I imagine there would be implications on UI components like in RVIZ (text and colors used for each level).

Looping in @ct2034. Wasn't sure if I should have made this issue in this repo or in ros/diagnostics

[ct2034]

Hey @nnarain. I am generally open for a discussion about more states. But I would be really interested in more opinions. Do you maybe want to share this on discourse to ask people for their take? Hopefully more people take part in the discussion there. My opinion would be:

• Yes, more granularity would be helpful for some use cases.
• The simplicity of the current states also has its merits. Especially considering that one always has to communicate the meaning of all states across a team, less is more. Also, warn and error and their meaning are fairly well understood.
• I would be open for a proposal that allows users to create custom states and logic between them in ros/diagnostics. Because agreeing to them on a common_interfaces-level seems like a hard thing to get a consensus on. And it gets harder the more states you add.

[nnarain]

Thanks @ct2034. Yes I can do that.

Point 3 is interesting I'll have to consider that.

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/additional-levels-in-diagnosticstatus/41967/4

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/additional-levels-in-diagnosticstatus/41967/11