ros2_control publish/subscribe topic & action? good or bad?
Situation:
I implemented a ros2_control hardware interface and custom controller for my mecanum wheeled robot. This all works fine for driving the wheeled robot, but 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. Also other nodes might have a reason as well to make sure the robot stops imideatly.
Is it a good or bad idea to publish & subscribe directly inside the hardware interface or should i try to get this information trough joints and handle it in the custom controller?
Kind regards,
Asked by RandyD on 2021-04-02 17:32:28 UTC
Answers
Is it a good or bad idea to publish & subscribe directly inside the hardware interface
A "bad" one, as it violates separation of concerns.
hardware_interface implementations should be responsible for interacting with the hw only, not providing ROS interfaces. hardware_interfaces expose a number of resources, manage data conversion from whatever the hw needs to more generic representations and vice-versa and some related activities. Layering a ROS interface on-top of that is the responsibility of other entities in a ros_control stack.
This was already not really a "good idea" in ros_control (ie: the ROS 1 version), but many hardware_interface implementations did do it (the realtime_tools package made this too easy).
or should i try to get this information trough joints and handle it in the custom controller?
No need to "get this information trough joints": there is work underway to allow for arbitrary resources to be exposed, which could then be claimed by broadcasters (new name for something which does not actually control anything) or controllers. Those two would then expose services and actions and publish to topics.
Asked by gvdhoorn on 2021-04-03 01:49:10 UTC
Comments
hey, I have a similar question and I stumbled upon this ros answer. In my application, the vehicle already has all the mobility controls so the autonomy layer (the computing unit) will communicate and send drive and steering commands to the existing vehicle mobility module via CAN. Initially, I figured I'd have 2 hardware interfaces one for steering and one for wheel speed, BUT both signals are part of the same CAN message. My next thought was to have the hardware interfaces publish this information to a topic and then another node would take both info and send the CAN message. However, this, as you said, breaks the separation of concerns. How should I architect this? Thank you in advance.
Asked by guidout on 2023-05-05 19:13:45 UTC
Comments