ROS2 Diagnostics
ROS2 Diagnostics and Health Monitoring with Clean Architecture (Python & C++)
git clone --depth 1 https://github.com/harunkurtdev/ros2-claude-code-template /tmp/ros2-diagnostics && cp -r /tmp/ros2-diagnostics/.claude/skills/ros2_diagnostics ~/.claude/skills/ros2-diagnosticsSKILL.md
# ROS2 Diagnostics Skill
This skill demonstrates how to integrate standard ROS2 diagnostics tools for health monitoring within a Clean Architecture.
## Domain Layer
```python
# domain/entities/health.py
class HealthLevel(Enum):
OK = 0
WARN = 1
ERROR = 2
STALE = 3
@dataclass
class ComponentHealth:
name: str
level: HealthLevel
message: str
values: dict
```
## Infrastructure Layer (Python)
See previous Python example using `diagnostic_updater`.
## Infrastructure Layer (C++)
Using `diagnostic_updater` package in C++.
```cpp
// infrastructure/ros2/diagnostics/diagnostics_manager.hpp
#pragma once
#include <rclcpp/rclcpp.hpp>
#include <diagnostic_updater/diagnostic_updater.hpp>
#include "domain/interfaces/diagnostics_port.hpp"
namespace infrastructure::ros2::diagnostics {
class DiagnosticsManager {
public:
explicit DiagnosticsManager(rclcpp::Node::SharedPtr node)
: node_(node), updater_(node) {
updater_.setHardwareID(node->get_name());
}
void register_monitor(const std::string& name,
std::function<void(diagnostic_updater::DiagnosticStatusWrapper&)> callback) {
updater_.add(name, callback);
}
// Example callback wrapper for domain entities
void check_component(diagnostic_updater::DiagnosticStatusWrapper& stat) {
// Retrieve health from domain service
// auto health = domain_service_->get_health();
// stat.summary(health.level, health.message);
// stat.add("temp", health.value);
}
private:
rclcpp::Node::SharedPtr node_;
diagnostic_updater::Updater updater_;
};
} // namespace
```
### Frequency Status Example (C++)
```cpp
// infrastructure/ros2/diagnostics/frequency_monitor.hpp
#include <diagnostic_updater/publisher.hpp> // For TopicDiagnostic
class FrequencyMonitor {
public:
FrequencyMonitor(diagnostic_updater::Updater& updater,
const std::string& topic_name,
double min_freq, double max_freq) {
diagnostic_updater::FrequencyStatusParam freq_param(&min_freq, &max_freq, 0.1, 10);
monitor_ = std::make_unique<diagnostic_updater::HeaderlessTopicDiagnostic>(
topic_name, updater, freq_param);
}
void tick() {
monitor_->tick();
}
private:
std::unique_ptr<diagnostic_updater::HeaderlessTopicDiagnostic> monitor_;
};
```
## Use Case Integration
```cpp
// application/services/motor_controller.cpp
void MotorController::check_temp(diagnostic_updater::DiagnosticStatusWrapper& stat) {
double temp = read_temp();
if (temp > 80.0) {
stat.summary(diagnostic_msgs::msg::DiagnosticStatus::ERROR, "Overheating");
} else {
stat.summary(diagnostic_msgs::msg::DiagnosticStatus::OK, "Normal");
}
stat.add("temp", temp);
}
```
## Best Practices
1. **Hardware ID**: Always set a unique Hardware ID in the updater.
2. **Frequency Monitoring**: Use `TopicDiagnostic` to monitor publication rates.
3. **Meaningful Messages**: Provide descriptive error messages.
4. **Standard Levels**: Stick to OK, WARN, ERROR, STALE semantics.Use proactively before opening a PR that adds or changes BehaviorTree.CPP nodes or BehaviorTree.ROS2 wrappers (RosActionNode/RosServiceNode/RosTopicPub/SubNode, TreeExecutionServer). Reviews a diff against BT.CPP v4 conventions — node base-class choice, non-blocking ticks, ports/blackboard typing, factory/plugin registration, XML v4, and the ROS 2 wrapper contract. Returns a punch list with file:line anchors, not a rewrite.
Use when a design decision touches Clean Architecture boundaries in a ROS 2 project — which layer a new behaviour belongs to, whether a port belongs in domain or application, whether a new node should be lifecycle-managed, whether to compose nodes or split packages. Returns an architectural recommendation with trade-offs, not implementation.
Use when a design decision touches the gz-sim ECS — where new state should live, which system phase should write it, how to avoid coupling, whether to add a component vs. a member variable, whether a new system should be split or merged with an existing one. Returns an architectural recommendation with trade-offs, not implementation.
Use proactively before opening any gz-sim PR. Reviews a diff against the project's C++17 style, ECS conventions, plugin registration patterns, CMake structure, test placement, Migration.md / Changelog.md expectations, and pre-commit configuration. Returns a punch list, not a rewrite.
Use proactively before opening a PR that adds or changes a ros2_control controller, broadcaster, or hardware component (incl. URDF <ros2_control> bringup). Reviews a diff against ros2_controllers / ros2_control_demos conventions — controller & hardware lifecycle, command/state interface configuration, real-time safety of update()/read()/write(), generate_parameter_library usage, pluginlib registration, chainable-controller correctness, URDF wiring, and tests. Returns a punch list with file:line anchors, not a rewrite.
Use proactively before opening any ROS 2 / Nav 2 PR. Reviews a diff against this template's Clean Architecture, ROS 2 communication, lifecycle, testing, and Nav 2 plugin conventions. Returns a punch list with file:line anchors, not a rewrite.
Use proactively before opening a PR that touches a VDA 5050 connector / fleet bridge. Reviews a diff against VDA 5050 v3.0.0 protocol compliance (topics, QoS, header rules, base/horizon, action state machine, schema validation) and the template's Clean Architecture for the MQTT↔Nav 2 bridge. Returns a punch list with file:line anchors, not a rewrite.
Build the colcon workspace (optionally a single package) and report the outcome.