ros2_medkit_diagnostic_bridge

Bridge node that converts ROS2 /diagnostics messages to FaultManager faults.

Overview

This package provides backwards compatibility with existing ROS2 diagnostic infrastructure. It subscribes to the standard /diagnostics topic and forwards diagnostic status messages to the FaultManager as faults.

Severity Mapping

Quick Start

# Start FaultManager first
ros2 run ros2_medkit_fault_manager fault_manager_node

# Start DiagnosticBridge
ros2 run ros2_medkit_diagnostic_bridge diagnostic_bridge_node

Configuration

Parameters

Example Configuration

diagnostic_bridge:
  ros__parameters:
    diagnostics_topic: "/diagnostics"
    auto_generate_codes: true
    # Opt in to source attribution from diagnostic hardware_id values
    use_hardware_id_as_source_id: false
    max_tracked_sources: 512

    # Custom mappings (optional)
    # Format: "name_to_code.<diagnostic_name>": "<FAULT_CODE>"
    "name_to_code.motor_controller: Temperature": "MOTOR_OVERHEAT"
    "name_to_code.battery_monitor: Voltage": "BATTERY_LOW"

Fault Code Generation

When auto_generate_codes is enabled, diagnostic names are converted to fault codes:

Custom mappings in name_to_code take priority over auto-generation.

Fault Source Attribution

By default, faults reported by this bridge use the bridge node’s fully-qualified name (/diagnostic_bridge) as their source_id. This preserves the behavior of existing deployments because DiagnosticStatus.hardware_id commonly contains a serial number, device path, or no value rather than a ROS node name.

Set use_hardware_id_as_source_id to true to opt in to hardware ID attribution. When enabled, a non-empty hardware_id is used exactly as provided only when it contains /, which is treated as a heuristic for a node/FQN-like identifier. Empty or non-slash hardware IDs fall back to the bridge FQN. This option does not perform manifest lookup or normalize hardware IDs; the accepted value must already match the runtime entity source ID used by the gateway.

The bridge keeps one FaultReporter per active source so local filtering remains isolated by source. max_tracked_sources bounds this cache with least-recently-used eviction; values below 1 are clamped to 1.

Launch

# Using launch file with default config
ros2 launch ros2_medkit_diagnostic_bridge diagnostic_bridge.launch.py

# With custom config
ros2 launch ros2_medkit_diagnostic_bridge diagnostic_bridge.launch.py \
    config_file:=/path/to/custom_config.yaml

File truncated at 100 lines see the full file

Changelog for package ros2_medkit_diagnostic_bridge

0.6.0 (2026-06-22)

• Tests: label test_integration as an integration test so it runs in the integration suite instead of the unit set (#443)
• Contributors: \@bburda

0.5.0 (2026-06-08)

• Build: adopt the centralized ROS2MedkitWarnings and ROS2MedkitSanitizers cmake modules
• Tests: use centralized ROS_DOMAIN_ID allocation for DDS isolation
• Contributors: \@bburda

0.4.0 (2026-03-20)

• Build: use shared cmake modules from ros2_medkit_cmake package
• Build: auto-detect ccache, centralized clang-tidy configuration
• Contributors: \@bburda

0.3.0 (2026-02-27)

• Multi-distro CI support for ROS 2 Humble, Jazzy, and Rolling (#219, #242)
• Contributors: \@bburda

0.2.0 (2026-02-07)

• Initial rosdistro release
• Bridge node converting standard ROS 2 /diagnostics to FaultManager fault reports
• Severity mapping:
  • OK -> PASSED event (fault condition cleared)
  • WARN -> WARN severity FAILED event
  • ERROR -> ERROR severity FAILED event
  • STALE -> CRITICAL severity FAILED event
• Auto-generated fault codes from diagnostic names (UPPER_SNAKE_CASE)
• Custom name_to_code mappings via ROS parameters
• Stateless design: always sends PASSED for OK status (handles restarts)
• Contributors: Michal Faferek