ros_control interface vs Node that publishes topics (ROS2)

asked 2022-02-02 02:36:49 -0500

Pepe
21 ●1 ●2 ●3

Hello,

I don’t know if this is the right place to talk about this but I have some design questions. I have a sensor board with:

IMU (to be used for robot localisation and also terrain feedback)
temperature
pressure
humidity
addressable RGB LED strip
Two LED headlights (controlled independently)
8 Time of Flight sensors

The board is interfaced via CAN into a Raspberry Pi Compute Module 4. Currently I am writing the driver to get it into the ROS2 network. Two of this boards will be interfaces into the system.

The dilemma that I have is if I should integrate it via a ros_control Interface and then a controller/broadcaster to expose it to the other components in the robot, or if I should make just a Node that reads the data and publishes it into topics and exposes some of the services.

From the development perspective I feel that making the Node directly is very straight forward. While making the ros_control interface (albeit I am a noob at it and might be doing things wrong) is very complex due to all the things that it needs to interface and expose (turning LEDs on/off, sending RGB strip modes, among others).

We made a ros_control interface for the the drive system (via CAN) and it turned out really good and robust. But it feels that for a system as the sensor board, it will be unnecessary complex. 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. Instead I could just read the CAN messages and publish them in my custom message.

What do you guys think? Is the trouble of making the ros_control interface and a broadcaster is worth it? Or should I just make a node?

edit retag flag offensive close merge delete

Comments

(Opinion) From what I understand about ros_control, it's intended to be used to control something in a feed back loop, (ie PID controllers, MPC, etc) Drive systems are great to use ros_control with because you want a low-level feedback system to adjust motor setpoints in order to ensure that the robot is moving at the right velocity or moving to the right position.

Things like lights, don't need feedback loops to ensure that the light is on. (okay, I guess there could be situations were that'd be needed, but from what you've described, not for your application.) If I were in your position, I'd write a node that exposes those sensors as ros2 topics and services. Then other nodes can just subscribe to the data they need or call the services to set the lights. But that's just me.

ChuiV ( 2022-02-04 15:16:03 -0500 )edit

add a comment

answered 2022-03-02 07:40:59 -0500

destogl

877 ●4 ●31 ●26 https://www.stoglrobotics.de

updated 2022-03-03 03:17:03 -0500

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

EDIT: ros2_control is useful in the following cases:

to achieve hardware and controller abstraction, so they are reusable and exchangeable;
to realize access management to hardware;
to deterministically synchronize reading and writing from/to (multiple) hardware.

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.

edit flag offensive delete link

Comments

While I fully understand why you recommend using ros2_control here, I feel this question shows the strange solution it is, and the way it starts to re-implement things like node-to-node communication and messaging interfaces as part of its class structure and design.

The discussion around "supporting complex types" basically revolves around how much of node-to-node messaging to duplicate in ros2_control. A message passing system like ROS 2 already supports all of that. Messages can be as complex as needed.

In ROS 1, the plugin architecture made sense, as it was/is inherently unsuitable for distributed, deterministic control.

Now with ROS 2, not working on facilitating distributed, deterministic control, but instead still trying to work-around it by using plugins which host classes (as nodes) and function/method calls to exchange data (as messaging) seems like we're going in the wrong direction.

gvdhoorn ( 2022-03-02 08:20:56 -0500 )edit

I realise this sounds overly negative btw.

It was certainly not meant to be directed at you -- or to anyone in particular really.

This question just seemed to embody the duality almost of ros2_control and the solution it brings to a problem for which in ROS 1 we could not really implement the proper approach.

gvdhoorn ( 2022-03-02 09:02:41 -0500 )edit

@gvdhoorn I agree with you on all points. And I fully understand your comments. Let me clarify some things I think are misunderstood.

I feel this question shows the strange solution it is, and the way it starts to re-implement things like node-to-node communication and messaging interfaces as part of its class structure and design.

This should definitely not be a point there. This I the reason I am very much against wildcard data-type inside ros2_control. Besides that, I didn't see any purpose of them because I didn't meet any use-case until now where they would really be needed.

destogl ( 2022-03-03 03:07:01 -0500 )edit

Now with ROS 2, not working on facilitating distributed, deterministic control, but instead still trying to work-around it by using plugins which host classes (as nodes)

The main purpose of the plugin is to enable flexible “stacking” of hardware interfaces without any code changes when another endeffector is connected to a robot (if hardware interfaces already exist). In ros2_control hardware interfaces are not nodes, and they will probably never be. The idea is to have only deterministic communication path to hardware interfaces.

Controller are nodes, but they have to be nodes to provide ROS interfaces for external components. Also, using LIfecycleNodeInterface there is very useful and synchronized with the rest of the ROS2 framework.

destogl ( 2022-03-03 03:08:17 -0500 )edit

Check my edit about too

destogl ( 2022-03-03 03:10:58 -0500 )edit

My point was (and is), that with a proper middleware and transport, distributed, deterministic control architectures are possible.

"changing an end effector" should only require starting (a) different node(s), not using plugins. Chaining of controllers -> configuration of pub-sub connections. Etc.

The idea is to have only deterministic communication path to hardware interfaces.

and this would be possible with technologies like DDS-TSN. Accutronic robotics already showed that with their MARA: distributed, deterministic, time-synced control with ROS interfaces.

Node hops (ie: message exchange) does introduce latency of course. That would be something to address, but intra-process messaging can mitigate that. It would still be using actual message passing though, with all the flexibility that offers.

There is certainly value in standardising things like hw access, but that's only part of what ros2_control offers right now. And it would be internal to a node.

gvdhoorn ( 2022-03-03 03:32:17 -0500 )edit

I see now. I am open to reconsider everything we do in ros2_control, but for now, DDS shown itself rather as a bottleneck in the whole story. Maybe we some DDS expert onboard that could help us reorganize everything. It shouldn't be too complex.

Although, simply using the nodes would not solve all the problems, we need anyway management components and standardization of interfaces, what is mostly we are doing right now. As I said, I am open to switch the “transport” layer if we have a working DDS solution for it, hopefully without a need to recompile the entire ROS2 to get this working.

destogl ( 2022-03-03 08:08:11 -0500 )edit

add a comment

ros_control interface vs Node that publishes topics (ROS2)

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

ros_control interface vs Node that publishes topics (ROS2) edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

ros_control interface vs Node that publishes topics (ROS2)