ROS Topic when the controller is starting - on_init or on_activate

[brennand]

System: ROS 2 Jazzy

Hi,
I'm writing a custom hardware interface for an EtherCAT system. It works well, but it takes around 30–60 seconds for the system to fully initialize.

I'm wondering — is there a way to use /dynamic_joint_states (or another topic) to publish status updates during on_init() or on_activate()?

It would be really helpful if /dynamic_joint_states could start publishing at that stage.

Reason:
When I launch the system from the command line, I can see what's happening through the console output. But when running on the real robot, I use a GUI that monitors the internal system state using custom /dynamic_joint_states messages — and during startup, it’s silent.

I’m wondering if there’s a better or more standard way to expose what’s happening during initialization?

Bren

[christophfroehlich]

During on_init() this is not possible. But in inactive state all the exported state and command interfaces are available, we recently updated the docs to make that clearer.
This means that any ros2_controllers can publish the information even if the hardware component is not in active state.

[bmagyar]

dynamic_joint_states are published by the broadcaster, not the hardware component.

Just to clarify: your goal is to monitor what's happening during startup, not to use that information elsewhere, right? To that end we've recently added some new support to pal_statistics and also scoped up a GSoC project to generally improve logging and introspection there: https://github.com/osrf/osrf_wiki/wiki/GSoC25#hardware-diagnostics-support-for-ros2_control

[brennand]

Thank you for your fast feedback. I will have a look today.

[brennand]

@bmagyar looking at: https://github.com/osrf/osrf_wiki/wiki/GSoC25#hardware-diagnostics-support-for-ros2_control I had a thought:

You could implement a publisher for each hardware interface—similar to how dynamic_joint_states works—where each interface defines its own diagnostics or internal state values, much like how we currently define state_interfaces.

Here’s an example from my URDF where I expose internal states:

<!-- Motor internal state -->
<state_interface name="motor_error_code"/>
<state_interface name="motor_status_word"/>

<!-- ROS 2 Control internal state -->
<state_interface name="controller_initialized"/>
<state_interface name="controller_enabled"/>
<state_interface name="controller_override"/>
<state_interface name="controller_operational"/>

<!-- The state of the EtherCAT slave -->
<state_interface name="ethercat_state"/>

So maybe something like this could be added for hardware_diagnostics:

<!-- The state of the EtherCAT slave -->
<hardware_interface name="ethercat_state"/>

Which could then automatically publish to a topic like: /EthercatHardwareInterface_0

And then have a function for example publish_diagnostics() that you can call from anywhere in the interface code.

Just a thought on a lightweight way to integrate diagnostics directly into the hardware interface layer. As I did think about doing this in my custom hardware interface.

[github-actions]

This issue is being labeled as stale because it has been open 45 days with no activity. It will be automatically closed after another 45 days without follow-ups.

[github-actions]

This issue was closed because it has been stalled for 45 days with no activity.