Rosanswers logo

I want to monitor the status of my different ROS2 nodes and act accordingly if something happens. Some of these nodes are hardware drivers, while others are not, working on things such as image processing, data upload, etc.

One way of monitoring the status is to subscribe to /rosout and filter messages on severity, and filtering further on message string if needed. This filtering then determines how the system responds.

Another approach that i am entertaining is to use the diagnostics system to monitor status.

From the ROS wiki I quote:

The diagnostics system is designed to collect information from hardware drivers and robot hardware to users and operators for analysis, troubleshooting, and logging.

Furthermore when looking at the message definition that both use, DiagnosticStatus and Log, their definitions seem very similar.

Considering the above information, I find it difficult to determine which to use. This has lead to two questions:

  1. Do I use /diagnostics only for hardware drivers as suggested and subscribe to /rosout for the rest?

  2. Is it bad practice to subscribe to /rosout for status monitoring?
    from q33503, it states that subscribing to /rosout

might lead to many socket connections to all the nodes running on your system.

However I wonder if this is still the case with the DDS system that ROS2 uses .

Originally posted by bvaningen on ROS Answers with karma: 167 on 2021-11-29

Post score: 2


1 Answer 1


Rosanswers logo

I can't answer this question generally, but I will talk about what we do, which seems to be working pretty good for us.

  1. We use both diagnostics AND rosout:
    • We use diagnostics to represent the current state of a node. We have other nodes that subscribe to diagnostics, and conditionally react.
    • We use rosout to represent events such as connection time-outs, state transitions, etc. This is mainly used to trace code paths post-execution from bag files.
    • This way anybody can subscribe to diagnostics to view the current state of everything (ie handy to explain why a driver or node isn't working) while still being able to log every event that occurs in a node.
  2. If every node is publishing both rosout and diagnostics, then no matter what you do you'll have a node subscribing to every other node to watch for diagnostics or rosout (or even both). With DDS, that will produce a socket connection to every other node (though just a few sockets per node inter-connection, regardless of number of topics).

Originally posted by ChuiV with karma: 1046 on 2023-05-16

This answer was ACCEPTED on the original site

Post score: 1

Original comments

Comment by bvaningen on 2023-07-24:
on the diagnostics side: are those nodes only hardware nodes as the ROS wiki suggests ?

on the rosout side: we have gone the path of using a FATAL log to start the shutdown procedure of our system. Considering the definition of FATAL this feels like a sane choice ... what do you think ?

Comment by ChuiV on 2023-07-25:
I mean technically the computer you run your nodes on is still hardware. For us, every node publishes it's own diagnostics, including sensor (and other) drivers.

Regarding FATAL, in our applications, we require certain interfaces to always be up in order to keep the rest of our system (VCU, User Command and Control server, etc) informed of our state, so if a node exits or has a FATAL error, we'll restart that node.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.