Investigate changes to simplify launching MoveIt projects

[tylerjw]

The ROS 2 launch file syntax is obnoxiously verbose, with much of it just noise. There are several reasons for this that we could address with technical changes.

Use wrapper for python launch syntax

Here is a project that offers wrappers for the python launch file syntax. Has anyone tried to use it?

https://github.com/oKermorgant/simple_launch#use_sim_time

Unify configs

Currently, many different config files get built into the moveit config. To make this easier to manage we use MoveItConfigBuilder to load the files. This tool has a bunch of magic to search for various files at various paths and restructure the config dictionary to match what the various components of MoveIt expect. After you launch the demo with rviz2 you can run ros2 param dump /rviz2 to see what it would look like if we used a single file. I have removed the robot_description and robot_description semantic and the repeated joint limits to make it easier to see here.

/rviz2:
  ros__parameters:
    default_planning_pipeline: ompl
    publish_robot_description: null
    publish_robot_description_semantic: null
    qos_overrides:
      /parameter_events:
        publisher:
          depth: 1000
          durability: volatile
          history: keep_last
          reliability: reliable
    robot_description_kinematics:
      hand:
        kinematics_solver: kdl_kinematics_plugin/KDLKinematicsPlugin
        kinematics_solver_search_resolution: 0.1
        kinematics_solver_timeout: 0.05
      panda_arm:
        kinematics_solver: kdl_kinematics_plugin/KDLKinematicsPlugin
        kinematics_solver_search_resolution: 0.005
        kinematics_solver_timeout: 0.05
      panda_arm_hand:
        kinematics_solver: kdl_kinematics_plugin/KDLKinematicsPlugin
        kinematics_solver_search_resolution: 0.1
        kinematics_solver_timeout: 0.05
    robot_description_planning:
      joint_limits:
        panda_finger_joint1:
          has_acceleration_limits: false
          What is this robot configWhat is this robot confighas_jerk_limits: null
          has_velocity_limits: true
          max_position: null
          max_velocity: 0.1
          min_position: null
        ...
    tf_buffer_cache_time_ms: 10000
    use_sim_time: false
    warehouse_host: 127.0.0.1
    warehouse_plugin: warehouse_ros_mongo::MongoDatabaseConnection
    warehouse_port: 33829

As you can see, there isn't much in this config, and it could just be one file. If we made it one file, we could simplify it more and give it a more readable/editable format.

RobotDescription

The URDF and SRDF have a few problems.

Many config files in robot config for single parameters

They have to be parsed from XACRO into URDF/SRDF on launch but rarely change.

• We could greatly simplify the moveit config if we did the xacro expansion as part of the setup assistant workflow.
• Keep the xacro separate file config as an input to the setup assistant because it is more flexible but the output should be a "site config" with two files.

Global but copy-pasted into each node

They have to be passed into each node that uses moveit that is going to use ROS then to communicate with each other. In ROS 1, parameters went into a global parameters server which we were guaranteed would be up before each node started; we do not have this in ROS 2. This is a problem with all the configs used by moveit. Some options I see for making this nicer / easier for users:

• Use a global parameter server; here is a discussion on doing that in ROS 2: https://discourse.ros.org/t/ros2-global-parameter-server-status/10114/9
• Use the latching publisher mechanism currently being used and have one node publish the URDF
• Something else?

URDF / SRDF are not dynamic

This is made more difficult by needing to load them into each different node as parameters. We should discuss designs for how to make it possible to change aspects of the description at runtime.

Support yaml or XML launch file syntax

ROS 2 has a declarative yaml or XML launch file syntax. If we made some of the above simplifications, we could use simpler-to-use declarative launch files.

Support workflows where RViz stays up, and you restart MoveIt nodes

Currently, we have to send all the same parameters to both RViz and move_group (or whatever another node you created with MoveIt in it). This means that when you change those parameters if you want them reflected in RViz, you restart RViz each time. A pull request was submitted here as an attempt to remedy this: #1074

We should consider maybe using the get_parameter interface or synced parameters of some sort from the RViz plugin to get parameters from the other moveit nodes.