joint_command_broadcaster?

[tonynajjar]

Is your feature request related to a problem? Please describe. For debugging purposes I often publish or log the commands of my controllers.

Describe the solution you'd like So I was wondering if it would make sense to make this information readily available. One example implementation is to implement a joint_command_broadcaster very similar to the joint_state_broadcaster, with the difference that it populates the JointStates msg with commanded values. We could also think of implementing this from within the joint_state_broadcaster.

[christophfroehlich]

I understand the need for it, we also implemented this with the ~/controller_state message of the joint_trajectory_controller. But I think your proposal would need some changes to the ressource_manager, because it is not possible to claim the command interfaces for reading them if they are claimed already.

[tonynajjar]

But I think your proposal would need some changes to the ressource_manager, because it is not possible to claim the command interfaces for reading them if they are claimed already.

Yep, just discovered this the hard way. I'll leave the solution proposal to the experts, If we can agree on the need for it, I assume designing a solution for it should be straightforward for someone a bit more versed in how access control in ros2_control works

[tonynajjar]

we also implemented this with the ~/controller_state

ahh I see, same is done for steerint_controllers_library. Seems like quite some overhead having to create a State msg for each controller. This could maybe be unified by the ros2_control framework somehow instead of leaving it fully to the controllers to implement it

[christophfroehlich]

Yes it would be an addition for simpler controllers, but no replacement for the JTC's publisher for example: There you have the sampled trajectory, the feedback from sensors, and controller output in one message. The internal states/variables wouldn't be accessible by a joint_command_broadcaster.