Proposal: Standardized Hardware Status Reporting in ros2_control

ros-controls ros-controls General
, , , ,
1

Hello ROS Community,

My name is Soham Sanjay Patil (@soham2560), and I am excited to share one of the core parts of my Google Summer of Code 2025 project with Open Robotics. This project, “Hardware Diagnostics Support for ros2_control,” is being mentored by the wonderful Dr. Bence Magyar (@bmagyar) and Sai Kishor Kothakota (@saikishor).

The goal of this project is to create a standardized, flexible, and powerful way for hardware components to report their status within the ros2_control framework.

The Problem

Currently, ros2_control doesn’t have a standard way to report detailed hardware status. Vital information like motor temperatures, bus health, safety circuit states, or vendor-specific error codes is often handled with custom, non-standard messages. This makes it difficult to build generic, reusable tools (dashboards, fault managers, etc.) that can work across different robots.

The Proposal: A Composable, Standards-Based Architecture

To address this, we are proposing a new API centered around a HardwareStatus and a HardwareDiagnostics message. The core idea is to provide a clear separation between high-frequency, machine-readable status and low-frequency, human-readable diagnostics.

The HardwareStatus message acts as a container for smaller, standard-specific state blocks. A hardware driver only needs to populate the blocks that are relevant to it.

For example, a driver for a CANopen-based motor would fill in the generic GenericState and the specific CANopenState blocks, leaving others empty. This makes the system incredibly flexible and extensible.

The HardwareDiagnostics is a slower, richer stream of diagnostic_msgs/KeyValue, strictly for debugging and UI, ideally not parsed by control loops.

We Need Your Feedback!

We would heavily appreciate you submitting PRs on our proposal. We have prepared a design draft detailing the proposed message structures, API design, and example usage. We would be incredibly grateful if you could take the time to review it and share your thoughts.

:memo: Full Proposal Available Here

To help guide the discussion, we are particularly interested in your feedback on these questions:

  1. Included Standards: This is where we really want your feedback. We’ve included rough initial messages for CANopen, EtherCAT, VDA5050. Are there other critical standards we should consider for the initial release?
  2. For Hardware Interface Maintainers: What specific status information from your hardware do you wish you had a standard way to report? Would this proposal meet your needs?

Feel free to crtique in whatever way you feel feel, we hope you drop a PR soon!

Thank you for your time and expertise. We look forward to discussing this with you and building a better ros2_control together!

11 Likes
ROS News for the Week of August 4th, 2025
ROS News for the Week of August 18th, 2025
2

Why not use the standardised HW reporting infrastructure ( GitHub - ros/diagnostics: Packages related to gathering, viewing, and analyzing diagnostics data from robots. ) instead of creating yet another system?

You can then create a customised version of the updater ( diagnostics/diagnostic_updater at ros2 · ros/diagnostics · GitHub ) to create a higher degree of standardisation for the ros2_controls use case, and a listener for extracting that information again when machine reading is required.

While there is the disadvantage that the messages aren’t tailored to your use case, the advantages are:

  • Can reuse existing guis/tools (lower development and maintenance burden)
  • If they dont cover all your needs, improve them for the whole ros2 community (give development effort a broader reach/impact)
  • Simplifies adoption (people are more likely to be familiar with the tools and not have to learn something new)

Being a relatively new/novice user of ros2_control, it has been very noticeable that many concepts are inspired/similar to other aspects of ros2 while being implemented in a different/custom way which leads to a lot friction (and without having gone too deep in the codebase) I imagine a large maintenance burden.