Fix for issue #169: load xacros in MoveIt cfgs instead of urdfs

[gavanderhoorn]

As per subject.

Makes MoveIt load top-level xacros instead of the urdfs. This should make editing / updating support pkgs a bit more convenient, as the xacro xacro.py .. step is not needed then.

[shaun-edwards]

+1

[gavanderhoorn]

@shaun-edwards: I've changed my approach: instead of including support_pkg/load_M.launch in planning_context.launch (a Moveit Setup Assistant generated file), I've now moved that to the demo.launch and moveit_planning_execution.launch files. I think this has less maintenance overhead, as only demo.launch is an auto-generated file, and the change is minor.

planning_context.launch allows us to prevent it from loading the urdf/xacro, so I'm making use of that.

Similar idea, different implementation.

[gavanderhoorn]

Ping?

[shaun-edwards]

Doesn't moveit allow you to specify a xacro in the setup wizard? And presumably doesn't it auto generate files that use a xacro instead of a urdf?

[gavanderhoorn]

Yes to both questions.

The resulting config pkg then looks exactly like what this PR introduces, minus the inclusion of the load_*.launch files in demo.launch and moveit_planning_execution.launch, and the load_robot_description=false for planning_context.launch.

So first get the pkgs to do what the Setup Assistant would've generated, then suppress loading the xacro directly by having load_*.launch do it instead.

[shaun-edwards]

Why change demo.launch? What is the benefit if using our _load launch file?

[gavanderhoorn]

@shaun-edwards wrote:

Why change demo.launch?

Because it should not let planning_context.launch load the xacro. That should be done by load_X.launch in the support pkg.

What is the benefit if using our _load launch file?

From Working with ROS-Industrial Robot Support Packages - Using the provided launch files (here):

The load_m10ia.launch file simply uploads the urdf of this specific model to the robot_description parameter on the parameter server. It is recommended that users include this launch file in their own launch files, instead of loading the urdf or calling xacro directly. Not all models may have a simple, or single, urdf or xacro to load, and this launch file hides those details behind a simple interface.

This PR tries to implement that suggestion by making use of the abstraction provided by the load_X.launch files. Admittedly, there are currently no support pkgs that have such complicated xacros that would actually need this, but as the Fanuc pkgs are (sometimes) used as examples for others, I thought it would make sense to do this.

The MoveIt Setup Assistant would still directly load the .xacro though, so that would be something to address (perhaps extending it to also support 'loading' a launch file).

[shaun-edwards]

I'd like to limit the number of extra steps required after generating a moveit config. It's bad enough that we have to create a moveit_planning_execution.launch file manually. Editing demo.launch is just one more step. Perhaps we could leave demo.launch alone?

[gavanderhoorn]

I'd like to limit the number of extra steps required after generating a moveit config. It's bad enough that we have to create a moveit_planning_execution.launch file manually. Editing demo.launch is just one more step.

Yes, but unfortunately it cannot be avoided if we want the two to be consistent.

Perhaps we could leave demo.launch alone?

See above: I feel it is important that the two are consistent, so it's either/or for me. demo.launch is essentially moveit_planning_execution.launch, but without the 'active' parts (ie: robot driver / industrial simulator nodes) and configured for the simple controllers of MoveIt.

[shaun-edwards]

+1 to merging this. However, I don't think we can make this a blanket requirement until we have an automatic generation script (either the MoveIt setup assistant or an update to the generation scripts)

[gavanderhoorn]

I'm going to 'mothball' this one for now, at least until I can update the MoveIt setup assistant to also support 'loading' launch files. Otherwise this will still require too much manual editing of files.

[gavanderhoorn]

Closing this one. Replaced by #208, which is somewhat simpler, but doesn't address the duplication.