MotionPlanning Rviz Plugin Issues when Move Group is Launched in Namespace

[swiz23]

@JafarAbdi and @nbbrooks

Description

For my project, I'm launching move_group in a robot specific namespace (let's call this 'arm1'). I then launch Rviz in the root namespace, and configure the MotionPlanning display's 'Move Group Namespace' to 'arm1'. Additionally, I changed the 'Planning Scene Topic' name from /monitored_planning_scene to arm1/monitored_planning_scene and the 'Planned Path -> Trajectory Topic' name from /display_planned_path to arm1/display_planned_path. These two topic name changes in the MotionPlanning display were necessary in order to properly connect them to the topics advertised by the move_group node in the 'arm1' namespace. Not sure why that should be necessary tho - shouldn't the Move Group Namespace field automatically do that for me?

At this point, I'm able to plan/execute motion using the interactive marker in Rviz without any issue. Next, I checked the 'Use Cartesian Path' checkbox in the MotionPlanning plugin, and tried to plan a path by clicking the 'Plan' button. After a second or two, Rviz crashes with this message.

[move_group-1] [INFO] [1671826605.272934063] [moveit_move_group_default_capabilities.cartersian_path_service_capability]: Computed Cartesian path with 16 points (followed 100.000000% of requested trajectory)
[rviz2-3] [INFO] [1671826605.273259230] [moveit_ros_visualization.motion_planning_frame_planning]: Achieved 100.000000 % of Cartesian path
[rviz2-3] [INFO] [1671826605.274086331] [moveit_ros.current_state_monitor]: Listening to joint states on topic 'joint_states'
[rviz2-3] [INFO] [1671826606.274177370] [moveit_ros.current_state_monitor]: Didn't received robot state (joint angles) with recent timestamp within 1.000000 seconds.
[rviz2-3] Check clock synchronization if your are running ROS across multiple machines!
[rviz2-3] [ERROR] [1671826606.274200770] [move_group_interface]: Failed to fetch current robot state

Notice that it says that the current_state_monitor says that it's listening to the 'joint_states' topic. This was strange to me, since I expected it to be subscribing to the 'arm1/joint_states' topic (do you know why it's not?). I wasn't sure how to fix that so I explicitly remapped /joint_states to arm1/joint_states within the rviz2 node in my launch file. At this point, I relaunched, rechecked the 'Use Cartesian Path' checkbox, and was able to successfully plan and execute cartesian motion multiple times using the MotionPlanning display in rviz. However, the first time I plan a cartesian motion after checking the 'Use Cartesian Path' checkbox, I get the following message in the terminal.

[rviz2-3] [INFO] [1671826935.739807331] [moveit_ros_visualization.motion_planning_frame_planning]: Achieved 100.000000 % of Cartesian path
[rviz2-3] [INFO] [1671826935.740744804] [moveit_ros.current_state_monitor]: Listening to joint states on topic 'joint_states'
[rviz2-3] [WARN] [1671826935.770153606] [moveit_ros.current_state_monitor]: Unable to update multi-DOF joint 'access_panels_base_joint':Failure to lookup transform between 'platform_base_link'and 'access_panels_base_link' with TF exception: "platform_base_link" passed to lookupTransform argument target_frame does not exist. 
[rviz2-3] [WARN] [1671826935.770425618] [moveit_trajectory_processing.time_optimal_trajectory_generation]: Joint acceleration limits are not defined. Using the default 1 rad/s^2. You can define acceleration limits in the URDF or joint_limits.yaml.
[rviz2-3] [INFO] [1671826935.776913758] [moveit_ros_visualization.motion_planning_frame_planning]: Computing time stamps SUCCEEDED

The first thing that confuses me is the failure to lookup this transform. While access_panels_base_joint is modeled as a floating joint in my urdf (note that this joint is not part of my robot, but rather is a joint to define where an object is located w.r.t. the robot), I explicitly publish a static transform describing the relationship between platform_base_link and access_panels_base_link way before I tried to plan the cartesian motion. That said, at the end of the day, the cartesian motion still plans and executes fine, so maybe this is just a tf buffer issue?

Moving on, I'm also confused about the warning that my joint acceleration limits are not defined. They are in fact defined in my joint_limits.yaml so I'm not sure why the warning is saying they are not defined... Additionally, I haven't found any tutorial that says you can define acceleration limits in the URDF, but if that's really the case, I'd be interested if you could point me to a tutorial that shows me how to do it!

Your environment

• ROS Distro: Humble
• OS Version: e.g. Ubuntu 22.04 in Docker
• Source or Binary build? Source
• If source, which branch? Main

Steps to reproduce

N/A

Expected behaviour

1. I should not have to explicitly prefix the display_planned_path and monitored_planning_scene topics in the MotionPlanning plugin display with the Move Group Namespace. Rather, the Move Group Namespace field within the display should automatically be applied to those fields.
2. Rviz should not crash when I try to plan with the 'Use Cartesian Path' checkbox checked. Additionally, the current_state_monitor should be listening to 'arm1/joint_states' and not 'joint_states'.
3. I should not be seeing a TF Exception warning about the multi-DOF (a.k.a floating) joint from the current_state_monitor since I am publishing a static transform to define the relationship before I try planning.
4. I should not be seeing a warning that my acceleration limits are not defined when they are.

Actual behaviour

Already specified within the Expected behavior section.

[swiz23]

By launching rviz2 in the 'arm1' namespace, and then configuring the Move Group Namespace to be '/arm1' instead of 'arm1', the following issues (as defined in the 'Expected behavior' section above) were fixed:

1. I no longer have to explicitly prefix the two specified topics (display_planned_path and monitored_planning_scene). Though I think this is because these topics are now remapped due to launching the node in the 'arm1' namespace, and not due to the 'Move Group Namespace' field in the MotionPlanning Rviz plugin.
2. Rviz no longer crashes when planning with the 'Use Cartesian Path' checkbox checked. That said, the current_state_monitor still says it's listening to 'joint_states'.... maybe it's only printing the relative topic name?
3. I am still seeing this TF Exception issue only the first time I plan with the 'Use Cartesian Path' checkbox checked (though this was the case even beforehand).
4. I am still seeing this acceleration limit warning only the first time I plan with the 'Use Cartesian Path' checkbox checked (though this was the case even beforehand).

[swiz23]

I figured out the issue to #4 (the acceleration limit warning). I was not including the joint limits as a parameter in the Rviz node (i.e. under the robot_description_planning param). I thought that these were only necessary in the move_group node.

[nbbrooks]

Good to hear. @Abishalini is working on a class by class migration of all of the MoveIt params to use generate_params_library which will make knowing the possible and required params more knowable and enforceable. If you want to learn more about that, I would check out the following resources

• generate_parameter_library documentation
• Tyler's discussion on MoveIt's full list of parameters
• Abi's work thus far migrating params - note we haven't made it to robot model loader yet

Despite having pasted 3 links, the process of helping with this migration is pretty accessible (check out some of the PR diffs) so I would encourage to you get involved!

[swiz23]

Thanks @nbbrooks.

Since I was able to address all the pressing issues here (except for the 3rd one - which really isn't such a big deal), I am closing this.