ros2 / ros2/common_interfaces

Additional levels in DiagnosticStatus

Open
#268 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

help wanted
Dominant language
C++
Stars
393
Forks
157
PR merge metrics
No merged PRs in 30d

Description

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

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the diagnostic_msgs/DiagnosticStatus message definition and reviewing how its existing OK, WARN, and ERROR values are consumed. Check the implications for UI components such as RViz and coordinate with the ros/diagnostics context; done means an agreed level set and an accepted plan for compatibility and presentation changes.

Written by the indexing model from the issue text.

Assessment

Domain
api
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.