Add moveit_configs_utils package to simplify loading paramters

[JafarAbdi]

Description

Second attempt to simplify loading parameters

This's based on JafarAbdi/moveit_resources@44a82c4

Replace: #209

Checklist

• Required by CI: Code is auto formatted using clang-format
• Extend the tutorials / documentation reference
• Document API changes relevant to the user in the MIGRATION.md notes
• Create tests, which fail without this PR reference
• Include a screenshot if changing a GUI
• While waiting for someone to review your request, please help review another open pull request to support the maintainers

[AdamPettinger]

Overall I like this. I think there are pros/cons about this style of implementation but this (as written now) is already better than the current way of doing the same configs setup in every launch file

[tylerjw]

I like the pattern here. I wonder if there is a way to make it more generic so the sytax was more like:

parameters = ParameterBuilder('robot_config_package')
  .yaml('moveit_cpp.yaml')                                        # loads a yaml file into parameters
  .file_parameter('robot_description', 'xacro/panda.urdf.xacro')  # fills out full path based on package
  .parameter('planning_timeout', 0.1)                             # sets a parameter
  .to_dict()

Then it could be used for any sort of parameters, not just a moveit config. Then maybe there could be a moveit config builder that used the ParameterBuilder and was just a function or something like that.

[vatanaksoytezer]

Overall I like it that it is much more smaller, to be used around moveit. What I didn't like was this assumes default locations for some files such as semantic, kinematic, joint_limits, which can be hard to understand if you are looking at this for the first time and not familiar with moveit. I feel making all the parameters yaml is great and at least for example-wise specifying file names here would be more instructive and easier to understand imo.

[AdamPettinger]

I like the pattern here. I wonder if there is a way to make it more generic so the sytax was more like:

parameters = ParameterBuilder('robot_config_package')
  .yaml('moveit_cpp.yaml')                                        # loads a yaml file into parameters
  .file_parameter('robot_description', 'xacro/panda.urdf.xacro')  # fills out full path based on package
  .parameter('planning_timeout', 0.1)                             # sets a parameter
  .to_dict()

Then it could be used for any sort of parameters, not just a moveit config. Then maybe there could be a moveit config builder that used the ParameterBuilder and was just a function or something like that.

I like this a lot. It would let you do multiple inside one launch file (e.g. when getting parameters from multiple packages), and would also let you use it to return a specific set of all parameters for a config package (e.g. moveit_configs, or if some other user wants to have their own bringup/config package they could provide a getPackageConfigs() call)

[henningkayser]

This is awesome, all launch files look so much cleaner! I'm just not sure if we should remove the default values from the builder functions.

Some thought: Let's say all moveit config packages provide python scripts that export their custom moveit configs. Couldn't we then simply build config hierarchies by taking another included moveit config as default and just modifying specific parts, say the kinematics yaml or something else? Given this PR it seems like a really small step to get this done. The only thing we need to watch out for is circular dependencies.

[jrgnicho]

Perhaps these relative path strings should be stored in class variables

[JafarAbdi]

You mean config/kinematics.yaml right .? I'll update the class to have them

[jrgnicho]

I assume rviz needs these parameters for the moveit planning panel correct?

[tylerjw]

Probably out of the scope of this PR but it would be really nice if the rviz plugin had the option of being pointed at the ros node that had the moveit config loaded in it (maybe even as something that could be changed in the gui) and it would use the get_parameters service that ros starts up to read the moveit config from that other node.

[jrgnicho]

I really like what's on here too. Coincidentally I had started working on something similar in order to port the ros-industrial pick and place demo and ended up creating a MoveItConfigHelper python class that looks a lot like what's on here although it isn't as polished. Eventually I was going to pull it out of the launch file and provide it in its own stand-alone package but since that's already being done here then I'll just wait until this PR gets merged. One thing I did that I did not see here is to parse the list of ros controllers from the yaml and provide them as another field in the MoveItConfig. I then use the list to spawn the controllers; I feel this could be done here too.

[tylerjw]

Overall I really like this PR. I just left a couple of comments.

[tylerjw]

Probably out of the scope of this PR but it would be really nice if the rviz plugin had the option of being pointed at the ros node that had the moveit config loaded in it (maybe even as something that could be changed in the gui) and it would use the get_parameters service that ros starts up to read the moveit config from that other node.

[codecov]

Codecov Report

Merging #591 (28b6849) into main (4c75dcf) will increase coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main     #591      +/-   ##
==========================================
+ Coverage   57.96%   57.98%   +0.02%     
==========================================
  Files         309      309              
  Lines       26120    26120              
==========================================
+ Hits        15138    15143       +5     
+ Misses      10982    10977       -5     

Impacted Files	Coverage Δ
...nning_scene_monitor/src/planning_scene_monitor.cpp	53.90% <0.00%> (+0.59%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4c75dcf...28b6849. Read the comment docs.

[mergify]

This pull request is in conflict. Could you fix it @JafarAbdi?

[stephanie-eng]

Small nit - some comments reference robot_name_moveit_configs as the default package name, which caused me a bit of confusion.

[stephanie-eng]

Add move group capabilities loader function

[stephanie-eng]

Support passing LaunchConfiguration as a mapping

[AndyZe]

I just spot-checked this on some of the tutorials. It still works well 👍

We still haven't tested it on a dual-arm system due to some unexpected issues, but I don't want to block a great PR forever. We can always fix up whatever issues emerge.