Read and write to hardware over ROS topics

[roni-kreinin]

I have a diff drive robot running Foxy that does not have direct access to the hardware. The motors are controlled by a microcontroller running microROS which communicates with the robots PC. The motors are individually commanded with a ROS topic and the microcontroller publishes a feedback topic with encoder data. I understand that I should not be using ROS pub/sub directly in hardware as mentioned here, but I don't see how I can subscribe to the feedback topic and update the state interfaces of the hardware with a controller when the LoanedStateInterface are read only.

Any help would be appreciated.

[gavanderhoorn]

I understand that I should not be using ROS pub/sub directly in hardware as mentioned here, [..]

as I wrote that answer, I'll add some clarification here.

The ROS Answers Q&A you link asks about whether it'd be a good idea to have 'ROS-facing' pub-sub directly in the hw interface class(es), or whether any interaction with the ROS application should only be located in controllers/broadcasters:

what would be best practice for implementing "actions" like emergency brake or sending sensor information like bumpers state? In case the robot hit something, the read() method will get the information from the board and can have internal state to make the robot stop. Still i want this information available in other nodes as well.

That's different from what you're describing, as you have a 'driver' -- your only interface to your actual hw -- which you can only communicate with using pub-sub. Architecturally, that driver isn't really part of the application. It lives on the edge.

So while I would still maintain that what the OP in the ROS Answers Q&A asks would not be best-practice, and all application-facing interaction with a ros_control stack should be through controllers/broadcasters, in your case using pub-sub to interact with your hw driver would be OK(-ish).

(and I add -ish as it seems to make deterministic interaction impossible, due to the use of the RMW infrastructure, which will be difficult to make predictable)

[destogl]

We had already such questions and discussion. It would make sense to make a generic HardwareInterface for microROS that uses publisher and subscribers, but in a very controlled way toward ros2_control, i.e., RealtimePublishers and callbacks in a separate thread.

@roni-kreinin If you are interested to contribute this, we can support you a bit with some recommendations and issue solving.

[gavanderhoorn]

It would make sense to make a generic HardwareInterface for microROS that uses publisher and subscribers, but in a very controlled way toward ros2_control, i.e., RealtimePublishers and callbacks in a separate thread.

Technically that would be nice, but with the mico-ROS Agent in between the Client and any ros2_control hw interface, I'm wondering whether there's really any benefit.

Determinism is hard enough with regular ROS 2 RMWs in the mix. Let alone with an additional non-determinstic hop.

I wouldn't suggest making it 'target' micro-ROS specifically.

[destogl]

Technically that would be nice, but with the mico-ROS Agent in between the Client and any ros2_control hw interface, I'm wondering whether there's really any benefit.

At least people could use our controllers more easily, and we will see ho this could be optimized in the future. It is far from ideal.

I wouldn't suggest making it 'target' micro-ROS specifically.

You are right. We will probably end up having generic component. microROS is a good development use-case.

Determinism is hard enough with regular ROS 2 RMWs in the mix. Let alone with an additional non-determinstic hop.

This is true, but also interesting to investigate. I think you mentioned that it would be appealing to have communication inside the framework based on topics or something similar. As Acutronics did with MARA robot. This is something I am planning to investigate in the upcoming months with a student from KIT, to see if how distributed control-framework could look like and what are the limits and tweaks needed for it. It is for sure very researchy project with many risks.

[bmagyar]

https://github.com/PickNikRobotics/topic_based_ros2_control