Rethinking the layout of MoveIt Setup Assistant

[AndyZe]

In ROS1, the process of using MSA went like this:

• Work through the various tabs (collision matrix, planning groups, perception, ...)
• At the end, select which files you want to export. This is a very long list!

The problem here is, most new MoveIt users don't know which launch/yaml/xml files are important, so they get confused at the very end. I still do sometimes.

A better work flow would start by asking what needs to be updated then automatically suggesting what files to export at the end. Example:

• Tab 1: What do you want to do?
  • Generate MoveIt configuration for a brand new robot (if selected, other options are grayed-out since they all need to happen)
  • Update robot geometry and collision matrix
  • Update planning groups
  • Update 3D sensors
  • Change ros_control setup
  • ...
• The next few tabs are auto-selected based on user input from Tab 1
  • Complete each step (e.g. generate the new collision matrix)
  • Export the files at the end of each step.

Exporting files at the end of each step would be a great way to learn which files do what.

Here's a screenshot of the old setup, to jog memory:

[rhaschke]

The root cause of that confusing list is that we don't read back all manual changes performed in those config files. If we would do, we could easily point out (rare) conflicts with new changes in MSA and otherwise just write back the files including all manual changes (instead of overwriting them as we do now).

[tylerjw]

Maybe we should write some sort of basic lint type checker of the configs to check for invalid or conflicting that could then be used by MSA to warn users about issues with their config.

[AndyZe]

It seems like parsing for manual changes vs. overwriting completely is a whole different topic...

[rhaschke]

But, I think it is the proper way of thinking about it. As we only deal with xml and yaml, I don't think it is too much of a problem.

[nbbrooks]

I like this idea. Having some more semantic knowledge of what they want to do will give us a better ability to detect errors in the configuration and merge things. Did they mean to have xyz set up in a abnormal manner? Or did the API to the feature being configured just change/extend? Or did someone just copy paste another arms setup that is not going to work in the new application? Hard to know without semantics.

[DLu]

Worth noting that this is not closed via #1254, but it is much more possible with it.

For example, moveit_setup_controllers/launch/control.launch.py a version of MSA is launched with only the three plugin widgets relevant to ros2_control.