MoveIt Config Redesign - Migrate MSA to ROS 2

[henningkayser]

Porting the MSA requires more effort than simply applying the migration steps. With the switch to Python launch files, the new rclcpp::Parameter interface and related config changes (dropped XmlRpc support) require non-trivial re-implementation of some parts, including:

1. Initial Migration (Initial port of MSA gui #740)
2. Standardized yaml configs and parameter parsing (Standardize parameter parsing #431)
3. New generic launch scripts, available as templates (Standardize usage of ROS Parameters #335)
4. Adaption of changed config/launch setups to MSA layout and implementation (Rethinking the layout of MoveIt Setup Assistant #449)

Design Ideas

Config files
All nodes/classes declare parameters in a standardized way so that it's possible to generate valid config (yaml) files automatically (e.g. ros2 param dump), ideally including descriptions and comments. This would allow MSA to generate config files from the actual node implementation. All exceptions should be caught and handled accordingly, parsing and conversion of abstract data types should be handled with proper parameter documentation and runtime messages/warnings. Optionally, node configs include version tags, loading of outdated configs would then result in a deprecation warning.

Launch files
MoveIt configs should be static by default and only contain the config (yaml,srdf) files needed to describe the setup configuration. The default launch scripts are not copied into each MoveIt config package, they are only used to initialize a MoveIt setup instance (MoveGroup, MoveItCpp) by reading the config files from a config package. Customization of launch descriptions can be enabled by supporting launch file overrides or exporting/importing of factory functions from the launch scripts. This would allow to keep a standard and reduce redundancy (and maintenance overhead) in launch files. Of course it's up to the devs to copy the whole launch architecture and modify it as needed.

[DLu]

MoveIt Setup Assistant Refactor Proposal

I propose that MSA be reimplemented using pluginlib. Most of the "widgets" would be moved to separate packages and implemented as plugins. The core moveit_setup_assistant package would only contain a few key elements.

• List of available plugins
• Set of shared data files
• Functionality for loading some subset of the plugins
• Framework to populate the GUI (including RViz display)
• Intro and Outro widgets

The data files need to be shared at the high level because there are multiple configuration steps that operate on the same data file (i.e. the SRDF) and some configuration steps will need to load data from other configuration steps.

The overall control flow might be something like:

• Show the Initial SetupScreenWidget to select the URDF to operate on OR load an existing moveit_config package (same as before)
• With an eye toward Rethinking the layout of MoveIt Setup Assistant #449, ask the user what they want to do.
  • Each of the available plugins could report a hierarchical string describing what that configuration step does. For example, the VirtualJointsWidget could report something like ["Configure the SRDF", "Update the Virtual Joints"] and multiple operations would be grouped under the section "Configure the SRDF"
  • User would then select a subset of the options which would dictate which plugins get loaded.
• The user would then walk through each of the chosen configuration steps.
  • There needs to be a mechanism for specifying dependencies, so that, for example, you can't specify robot poses until you configure the planning groups.
• At the end, you are presented with the ConfigurationFilesWidget which presents the different shared files that need to be written to.

As much as possible, the GUI logic should be kept separately from the core data-management.

[v4hn]

I propose that MSA be reimplemented using pluginlib.

Reading this from you reminded me of slide 30 from your 2017 ROSCon talk. 😂

I would love plugin support for MSA for users to add their own configuration options.
I don't see the merit in "outsourcing" all standard tabs though and would keep them local classes. But, granted, the difference between local class and plugin in the local package is minor.

As you said the defining data structures need to be defined outside the plugins anyway.

Asking what steps to perform later on would be just another technical hurdle for the user.
It's equally possible to always add all plugins/widgets to the list. Maybe invoke them lazily if the user clicks on them.

As much as possible, the GUI logic should be kept separately from the core data-management.

👍 It would be great to have cli programs for all functionality, if just to finally write reasonable CI tests for MSA!

[gavanderhoorn]

As I don't see it mentioned yet: moveit/moveit#1375.