General information about this repository, including legal information and known issues/limitations, are given in README.md in the repository root.

The diagnostic_aggregator package

This package contains the aggregator_node. It listens to the diagnostic_msgs/DiagnosticArray messages on the /diagnostics topic and aggregates and published them on the /diagnostics_agg topic.

One use case for this package is to aggregate the diagnostics of a robot. Aggregation means that the diagnostics of the robot are grouped by various aspects, like their location on the robot, their type, etc. This will allow you to easily see which part of the robot is causing problems.

Example

In our example, we are looking at a robot with arms and legs. The robot has two of each, one on each side. The robot also 4 camera sensors, one left and one right and one in the front and one in the back. These are all the available diagnostic sources:

/arms/left/motor
/arms/right/motor
/legs/left/motor
/legs/right/motor
/sensors/left/cam
/sensors/right/cam
/sensors/front/cam
/sensors/rear/cam

We want to group the diagnostics by

• all sensors
• all motors
• left side of the robot
• right side of the robot

We can achieve that by creating a configuration file that looks like this (see example_analyzers.yaml):

analyzers:
  ros__parameters:
    path: Aggregation
    arms:
      type: diagnostic_aggregator/GenericAnalyzer
      path: Arms
      startswith: [ '/arms' ]
    legs:
      type: diagnostic_aggregator/GenericAnalyzer
      path: Legs
      startswith: [ '/legs' ]
    sensors:
      type: diagnostic_aggregator/GenericAnalyzer
      path: Sensors
      startswith: [ '/sensors' ]
    motors:
      type: diagnostic_aggregator/GenericAnalyzer
      path: Motors
      contains: [ '/motor' ]
    topology:
      type: 'diagnostic_aggregator/AnalyzerGroup'
      path: Topology
      analyzers:
        left:
          type: diagnostic_aggregator/GenericAnalyzer
          path: Left
          contains: [ '/left' ]
        right:
          type: diagnostic_aggregator/GenericAnalyzer
          path: Right
          contains: [ '/right' ]

Based on this configuration, the rqt_robot_monitor will display the diagnostics information in a well-arranged manner as follows:

Note that it will also display the highest state per group to allow you to see at a glance which part of the robot is not working properly. For example in the above image, the left side of the robot is not working properly, because the left camera is in the ERROR state.

Analyzers

The aggregator_node will load analyzers to process the diagnostics data. An analyzer is a plugin that inherits from the diagnostic_aggregator::Analyzer class. Analyzers must be implemented in packages that directly depend on pluginlib and diagnostic_aggregator.

The diagnostic_aggregator::Analyzer class is purely virtual and derived classes must implement the following methods:

• init() - Analyzer is initialized with base path and namespace
• match() - Returns true if the analyzer is interested in the status message
• analyze() - Returns true if the analyzer will analyze the status message
• report() - Returns results of analysis as vector of status messages
• getPath() - Returns the prefix path of the analyzer (e.g., “/robot/motors/”)
• getName() - Returns the name of the analyzer (e.g., “Motors”)

Analyzers can choose the value of the error level of their output. Usually, the error level of the output is the highest error level of the input. The analyzers are responsible for setting the name of each item in the output correctly.

Using the aggregator_node

Configuration

The aggregator_node can be configured at launch time like in this example:

``` yaml pub_rate: 1.0 # Optional, defaults to 1.0 base_path: ‘PRE’ # Optional, defaults to “”

File truncated at 100 lines see the full file

Changelog for package diagnostic_aggregator

4.1.2 (2025-02-10)

• Checking licenses in CI (#431) (#433)
  • Checking licenses in ci
• Add Windows support (#426) (#429) Co-authored-by: Silvio Traversaro <<silvio@traversaro.it>>
• Support custom [rclcpp::NodeOptions]{.title-ref} (#417) (#423) Co-authored-by: Patrick Roncagliolo <<ronca.pat@gmail.com>>
• Skipping flaky tests (#413) (#415)
  • skipping flaky ntp test
• Contributors: Christian Henkel

3.2.0 (2024-03-22)

• Avoid rolling up an ERROR state when empty GenericAnalyzer blocks are marked discard_stale, or when all of their items are STALE. (#315)
• formatting fixes from PR324 (#327)
• Debugging instability introduced by #317 (#323)
• feat: publish top level msg when error is received (#317)
• Empty default aggregator base_path (#305)
• using defined state for stale (#298)
• Contributors: Andrew Symington, Christian Henkel, outrider-jhulas

3.1.2 (2023-03-24)

3.1.1 (2023-03-16)

• exporting dependency on pluginlib fixes #293 (#294)
• Secretly supporting galactic (#295)
• Linting additional package (#268)
• Fix code-analyser bug
• Maintainer update
• Contributors: Austin, Christian Henkel, Ralph Lange, Tim Clephas

3.1.0 (2023-01-26)

• Merge of foxy and humble history into rolling for future maintenance from one branch only.
• Adding READMEs to the repo (#270)
• License fixes (#263)
• Fix/cleanup ros1 (#257)
• Use regex to search AnalyzerGroup
• Contributors: Alberto Soragna, Austin, Christian Henkel, Keisuke Shima, Ralph Lange

3.0.0 (2022-06-10)

• Use node clock for diagnostic_aggregator and diagnostic_updater (#210)
• Contributors: Kenji Miyake

2.1.3 (2021-08-03)

2.1.2 (2021-03-03)

• Adapt new launch file syntax. (#190)
• Introduce history depth parameter for subscription. (#168)
• Contributors: Karsten Knese, Ryohsuke Mitsudome

2.1.1 (2021-01-28)

• Move Aggregator publishing to timer to allow subscription callback more processing time. (#180)
• Contributors: cdbierl

2.1.0 (2021-01-12)

• Update to latest ros2 rolling. (#177)
• Fix installation of diagnostic aggregator example. (#159)
• Restore alphabetical order. (#148)

File truncated at 100 lines see the full file