Decide how to publish non-trajectory information about universal_robots_ros2_driver HOT 6 CLOSED

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 ..).

from universal_robots_ros2_driver.

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

• ros-controls/roadmap#38
• ros-controls/roadmap#39
• ros-controls/ros2_controllers#150

from universal_robots_ros2_driver.

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.

from universal_robots_ros2_driver.

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

from universal_robots_ros2_driver.

ros-controls/ros2_control#318

from universal_robots_ros2_driver.

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 :)

from universal_robots_ros2_driver.