search

moveit / moveit2

:robot: MoveIt for ROS 2
https://moveit.ai/
BSD 3-Clause "New" or "Revised" License
1.03k stars 508 forks source link

global dynamic robot_description #615

Open tylerjw opened 3 years ago

tylerjw commented 3 years ago

In ROS 1 we used the global parameter server for one view of the robot_description parameter. One downside to this is it was immutable and never changed. In ROS 1 dynamic parameters were per-node, similar to ROS 2 but this was never used for robot_description.

For MoveIt2 we are currently loading that parameter into each node (via python launch files) that needs it to use a similar parameter interface for reading the robot_description in each node. This exposed an issue where the rviz plugins were each declaring the parameter before they would get it and it is an error to declare a parameter twice. This race condition prompted this workaround by @JafarAbdi: https://github.com/ros-planning/moveit2/pull/525

Some proposed solutions to this:

  1. (me) instead of declaring the parameter in each node it should be declared for just the node with the PlanningSceneMonitor. Then other nodes should use the get_parameter service that is started by every ros2 node to read that parameter from the node with the PlanningSceneMonitor. This would more closely resemble the behavior is ROS 1 by treating whatever node is running the PSM as a global parameter server. This would require a new drop-down in rviz plugins to specify the node running the PSM that it could get the robot_description from.

  2. (@henningkayser) Create an action server in the PSM for the robot_description that other nodes could connect to. Then the feedback messages could update that node of changes in the robot_description and a result would signify that the PSM is shutting down.

  3. (@JafarAbdi ) expanding on my suggestion use the AsyncParameterClient to subscribe to updates to the robot_description parameter from the PSM node.

DLu commented 2 years ago

What is the advantage to using parameters, as opposed to using the existing infrastructure of published topics?

v4hn commented 2 years ago

What is the advantage to using parameters, as opposed to using the existing infrastructure of published topics?

At the least, you would need guaranteed processing order between the description topic and your published joint states. Otherwise you receive values for joints you don't know about. It's probably possible in DDS, but I don't think this is the default in ROS2, is it? With the service calls you can at least in theory ensure that no modified joint state message is published before the receiver updated its description.

It's far from trivial either way to set this up though.

v4hn commented 2 years ago

Oh, one more upside of using a topic is that it can be easily logged to rosbags! I don't know whether this is already supported in rosbag2 in some other way though.