Revision history [back]

(disclosure: biased answer from a ros2_control maintainer)

TL;DR: booth approaches are equally valid, but you probably want to use ros2_control in the long term :)

Hi,

The answer depends on what are expectations and goals of your robot. But let first clarify the main thing about ros2_control:

ros2_control main purpose is to simplify hardware management and its control by providing hardware abstraction and control over resource access.

So if you imagine in the future to exchange your sensor plate or how you are connecting it to PC, but you would like to keep all the controllers and broadcasters the same, then ros2_control is helpful. This is the purpose of hardware_interfaces.

Furthermore, if you imagine that you would need to synchronize robot movements and for example lights, then ros2_control can help you. You could then use those from the same controller, for example you extend DiffDriveController to turn on the lights when robot's velocity is not 0.

I am recommending people in the most cases to take the pain of writing hardware_interfaces for all kind of interfaces they have on their robot. Until now, this was shown as good approach, especially in very complex robots because it enables clarity about availability and access to hardware in any moment.

For example the LED strip mode is an uint8_t but I need to declare it as double so that the hardware_interface::StateInterface is happy with it.

This is a known shortcoming of ros2_contol, and I understand that it is very annoying to do data-type casting. But the good news is: we are working on it and planning to support also other simple types until ROS2 humble. (Here some discussion and information about it; check also our roadmap repository.)

P.S. If you decide to do this with ros2_control, we are happy to support you and get some of new controllers as contributions to our library. Since I was using almost all of those in ROS1 I think the controllers/broadcasters you are proposing are interesting for broader audience.

(disclosure: biased answer from a ros2_control maintainer)

TL;DR: booth approaches are equally valid, but you probably want to use ros2_control in the long term :)

Hi,

The answer depends on what are expectations and goals of your robot. But let first clarify the main thing about ros2_control:

ros2_control main purpose is to simplify hardware management and its control by providing hardware abstraction and control over resource access.

So if you imagine in the future to exchange your sensor plate or how you are connecting it to PC, but you would like to keep all the controllers and broadcasters the same, then ros2_control is helpful. This is the purpose of hardware_interfaces.

Furthermore, if you imagine that you would need to synchronize robot movements and for example lights, then ros2_control can help you. You could then use those from the same controller, for example you extend DiffDriveController to turn on the lights when robot's velocity is not 0.

I am recommending people in the most cases to take the pain of writing hardware_interfaces for all kind of interfaces they have on their robot. Until now, this was shown as good approach, especially in very complex robots because it enables clarity about availability and access to hardware in any moment.

For example the LED strip mode is an uint8_t but I need to declare it as double so that the hardware_interface::StateInterface is happy with it.

This is a known shortcoming of ros2_contol, and I understand that it is very annoying to do data-type casting. But the good news is: we are working on it and planning to support also other simple types until ROS2 humble. (Here some discussion and information about it; check also our roadmap repository.)

P.S. If you decide to do this with ros2_control, we are happy to support you and get some of new controllers as contributions to our library. Since I was using almost all of those in ROS1 I think the controllers/broadcasters you are proposing are interesting for a broader audience.