melodic noetic   Show EOL distros: 

Overview

The diagnostic Aggregator is a ROS node that listens to diagnostic_msgs/DiagnosticArray messages on the /diagnostics topic, processes and categorizes the data, and republishes on /diagnostics_agg. The Aggregator loads Analyzer's to perform the diagnostics processing and categorization. The configuration and setup for each analyzer is specific to each robot and can be determined by users or developers.

The two analyzers in this package, GenericAnalyzer and AnalyzerGroup, hold and categorize diagnostic messages. They're useful for categorizing components or systems. They can warn when an item is stale, but do not do additional analysis of the diagnostics. Other analyzers can be loaded as plugins by the aggregator on startup.

The aggregated diagnostic output is displayed in the Robot Monitor. The Robot Monitor can display these messages in a hierarchical format. To determine the hierarchy, the diagnostic aggregator prepends diagnostic status names with a path, joined with "/". For example, "prosilica: Frequency Status" will become "My Robot/Sensors/Prosilica/prosilica: Frequency Status". The analyzers are responsible for correctly setting the names of each item they analyze. The Aggregator does not do any check or enforcement of this convention.

Example

This shows how an Aggregator might categorize and analyze diagnostics data from a simple robot.

If a robot had diagnostics from the motor drivers, SICK laser scanner, Videre camera and a few batteries, the diagnostic input might have status names:

Left Wheel
Right Wheel
SICK Frequency
SICK Temperature
SICK Connection Status
Stereo Left Camera
Stereo Right Camera
Stereo Analysis
Stereo Connection Status
Battery 1 Level
Battery 2 Level
Battery 3 Level
Battery 4 Level
Voltage Status

Using the diagnostic aggregator, we can move these diagnostic messages into easy to understand categories to display in our Robot Monitor. To do this, just prepend the name of the category to the status names, and separate them with "/".

My Robot/Wheels/Left Wheel
My Robot/Wheels/Right Wheel
My Robot/SICK/Frequency
My Robot/SICK/Temperature
My Robot/SICK/Connection Status
My Robot/Stereo/Left Camera
My Robot/Stereo/Right Camera
My Robot/Stereo/Analysis
My Robot/Stereo/Connection Status
My Robot/Power System/Battery 1 Level
My Robot/Power System/Battery 2 Level
My Robot/Power System/Battery 3 Level
My Robot/Power System/Battery 4 Level
My Robot/Power System/Voltage Status

Using the above input, the Robot Monitor will categorize the data as follows:

My Robot
  -- Wheels
  -- SICK
  -- Stereo
  -- Power System

Analyzers

The Aggregator will load analyzers to store and process the diagnostic data. Each analyzer inherits from the base class diagnostic_aggregator/Analyzer. Analyzers must be in packages that depend directly on pluginlib and diagnostic_aggregator.

The base analyzer class is the pure virtual Analyzer class. All derived classes must implement these methods:

• init()

• match()

• analyze()

• report()

• getPath()

• getName()

Analyzers can choose the error state for any diagnostic_msgs/DiagnosticStatus message they analyze. Generally, the "parent" of an analyzer has an error state of the maximum of its children, but some analyzers may have more advanced methods.

Creating an Analyzer

Users can create Analyzers to load as plugins for different robots. See Creating a Diagnostic Analyzer for details.

Configuring an Aggregator

For a full tutorial, see the tutorial Configuring Diagnostic Aggregators

To set up the diagnostic analyzer on a robot, the aggregator is given parameters that will configure the analyzers. These parameters are in the ~analyzers namespace of the aggregator node.

pub_rate: 1.0
base_path: 'PRE'
analyzers:
  motors:
    type: PR2MotorsAnalyzer
  joints:
    type: GenericAnalyzer
    path: 'Joints'
    regex: 'Joint*'

Under each sub namespace under "analyzers", a different analyzer is configured. Analyzers can be robot specific, or they can be general purpose ones like the GenericAnalyzer.

Each analyzer needs a special parameter, type, in the configuration. The type parameter gives the Aggregator the class name of the Analyzer. Each of these classes must be a subclass of diagnostic_aggregator/Analyzer.

Any diagnostic item that isn't analyzed is analyzed by an "Other" analyzer, and will still appear in the Robot Monitor. "Other" items, or remainders, are removed from the diagnostics output after going stale for 5 seconds.

The pub_rate parameter (publish rate of /diagnostics_agg) is optional, and defaults to 1.0. The base_path is prepended to all /diagnostics_agg output, and defaults to "" (empty string).

For more details on writing your own Analyzer, see the tutorial Writing a Diagnostic Analyzer.

Launching a Diagnostic Aggregator

To look for an example of an aggregator in use, look in the demo/ directory in the diagnostic_aggregator package. Users specify each Analyzer in the private parameter space of the aggregator, then start the node.

<node pkg="diagnostic_aggregator" type="aggregator_node"
      name="diag_agg" >
  <rosparam command="load" 
            file="$(find diagnostic_aggregator)/demo/pr2_analyzers.yaml" />
</node>

See Starting the Diagnostic Aggregator for details.

Basic Analyzer Types

In the diagnostic_aggregator package, the two analyzer types provided: GenericAnalyzer and AnalyzerGroup. The GenericAnalyzer can be used to categorize and track stale items. The AnalyzerGroup categorizes analyzers themselves, allowing users to "sub-categorize" analyzers.

GenericAnalyzer

For a full tutorial on the GenericAnalyzer, see Using the GenericAnalyzer

AnalyzerGroup

The AnalyzerGroup can load a group of analyzers as a sub group. This can be useful for analyzing a group of similar items, like 4 different cameras. The AnalyzerGroup can use any type of analyzer as one of the sub-analyzers.

type: AnalyzerGroup
path: Sensors
analyzers:
  base_hk:
    type: GenericAnalyzer
    path: Base Hokuyo
    find_and_remove_prefix: base_hokuyo_node
    num_items: 3
  tilt_hk:
    type: GenericAnalyzer
    path: Tilt Hokuyo
    find_and_remove_prefix: tilt_hokuyo_node
    num_items: 3
  imu:
    type: GenericAnalyzer
    path: IMU
    find_and_remove_prefix: imu_node
    num_items: 3

The above example can analyze all the instruments on a PR2. The AnalyzerGroup uses the parameter "path" to prepend to all output names. In the above example, "tilt_hokuyo_node: Frequency Status" becomes "Sensors/Tilt Hokuyo/Frequency Status".

All sub-analyzers should go under the "analyzers" namespace. They should be specified in the same way that any diagnostic analyzer would be specified

Note: The diagnostic aggregator uses the AnalyzerGroup internally, which is why this is very similar to setting up a diagnostic aggregator.