ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

[ROS2] Best Practices: /rosout versus /diagnostics

asked 2021-11-29 05:20:32 -0600

bvaningen gravatar image

updated 2021-11-29 05:23:36 -0600

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 .

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2023-05-16 12:57:18 -0600

ChuiV gravatar image

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).
edit flag offensive delete link more


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 ?

bvaningen gravatar image bvaningen  ( 2023-07-24 03:02:13 -0600 )edit

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.

ChuiV gravatar image ChuiV  ( 2023-07-25 08:18:20 -0600 )edit

Question Tools

1 follower


Asked: 2021-11-29 05:20:32 -0600

Seen: 310 times

Last updated: May 16 '23