Decide how to publish non-trajectory information

[nbbrooks]

Decide how to publish additional info to ROS side, tool state, digital I/O, robot mode, safety mode, and tcp pose. Do we create controllers or to spin another thread to publish this stuff

[livanov93]

Here I am more fan of multiple controller creation which would be based on controller_interface.
This approach only tends to make a huge list of state and command controllers like:

• TcpPoseStateController
• IOStateController
• IOController
• RobotModeStateController
• SafetyModeStateController
• SpeedSliderController
• ToolStateController
• ExternalUrScriptController
• ResetMotionController
  ...
  These controllers would interface with driver via one of these state, command or sensor interfaces.

Other option is to hold onto ROS1 approach and spin multiple threads and callbacks within hardware interface to register topics.

[AndyZe]

^that's my understanding from ros2_control meetings, as well

[gavanderhoorn]

I would say "officially", drivers should always have used the *Controller approach to publish additional information. Even in ros_control (ie: the ROS 1 version).

It's just that it was so easy to do it with realtime publishers from the hardware_interface itself, no one really bothered.

ps: I really don't like to use the Controller suffix for something which doesn't actually control anything. I believe we don't have to any more in ros2_control, so it would be great if we could avoid it. It leads to many questions ("ah, so the joint_state_controller let's me execute motions?", well, no ..).

[livanov93]

ros-controls/ros2_control#318

[destogl]

ps: I really don't like to use the Controller suffix for something which doesn't actually control anything. I believe we don't have to any more in ros2_control, so it would be great if we could avoid it. It leads to many questions ("ah, so the joint_state_controller let's me execute motions?", well, no ..).

Unfortunately, we still have it... I agree fully with you....

@livanov93

This approach only tends to make a huge list of state and command controllers like:

I think we can solve this issue by creating a few general controllers/publishers. Basically, we need only GPIOController and an extension of the joint_state_controller which enables the definition of states one wants to have published.

I think this is the most general approach and could make many people happy :)

[destogl]

Mid-term improvements on the ros2_control side as discussed in today's meeting:

• Add description of "gpio"-tag ros-controls/roadmap#38
• Propose additional primitive types for interface-handles. ros-controls/roadmap#39
• Enable synchronized execution of trajector, gripper movements, and GPIOs activation ros-controls/ros2_controllers#150