Reduce the number of URDF/SDF variants

[SeanCurtis-TRI]

Description

We have a number of files that specify the same robot, but they vary in how the robot's collision geometry is configured. (e.g., iiwa14_no_collision.urdf, iiwa_polytope_collision.urdf, iiwa_primitive_collision.urdf). Creating these variants increases synchronization challenges; they share the same dynamics properties but differ in collision representation. If dynamics need to be tweaked, they must be tweaked in all files.

We want a mechanism that will eliminate the copypasta but still allow runtime selection of an appropriate collision representation on a task-by-task basis.

See proposals in the discussion below.

[SeanCurtis-TRI]

@jwnimmer-tri @sammy-tri @mposa

Please feel free to comment or edit the description to make sure I have properly characterized the problem and the flavor of an acceptable solution. We can discuss designs that achieve it below.

[jwnimmer-tri]

The easy problem is reducing the copypasta of the dynamics (links, inertias, etc) in source control -- for that, we can have one main file, and then through some document or template processing tool (xacro, embedded ruby, python, etc.) we can the amend different copies to have different collision geometries. We can automate this in the build system, so they are all in bazel runfiles, and we can install them in binary Drake so that users have the full cornucopia of SDF options.

The hard part, and the part I care about, is separating the software for world building (aka workspace building / scenario building) from the code that choose the contact or collision models to be used by a simulator. I want to be able to generate different scenario configurations (how many mugs are on the table, and what are their initial poses) and then later decide which collision models I need to use for them, depending on which plant I've chosen, which integrator, which gripper fingers, sim fidelity, etc. I do not want to have to bleed the "mug_with_10_adjacent_spheres_on_its_base.sdf" details into the scenario-creating logic.

To me, I think that means that either
(1) each SDF model has a single default collision model, and then after the world is built I can swap another one in;
(2) each SDF model has a no collision model, and then after the world is built I can set one;
(3) each SDF model has every possible collision model, and then after the world is build I can turn off most (or all) of them.

[dmsj]

@jwnimmer-tri - being able to set different collision geometries "on the fly" would be very helpful. For our workflow, we create a suite of different urdf configurations at runtime using some python scripts and then load a different rigid_body_tree depending on the specific task. This does not feel like a good solution and it gives us lots of version control headaches.

On a related note, there is some progress on porting xacro out of ROS - but have you built anything resembling the template processing tool you mentioned above for sdf? OSRF has mentioned a few things like this before.

[jwnimmer-tri]

See also RobotLocomotion/drake#4326 where I plan to make xacro available within Drake at build-time (and thus would also be available to any downstream developers of Drake that are using Bazel).

See also RobotLocomotion/drake#4074 where embedded ruby is also mentioned (on the advice of OSRF), and probably will be supported soon within Drake at build-time. (As of RobotLocomotion/drake#8976 Drake already has a build-time dependency on Ruby.)

Beyond that, I don't have much progress here. Internally we have a few places already using xacro to emit a family of related SDFs, and then we choose one to load when starting a simulation or control application. We will probably coast on that idiom for a while (generating variants at build-time, using some mix of xacro, ruby, and python) but hopefully sooner rather than later the MultibodyPlant and GeometrySystem will offer collision model selection as a first-class feature, instead of a build-time band-aid.

[SeanCurtis-TRI]

Worth noting that RobotLocomotion/drake#13022 and RobotLocomotion/drake#13304 have merged (almost merged), respectively. Probably about time to create some sort of plan to update the redundant URDFs.

[jwnimmer-tri]

One small correction to the above ...

See also RobotLocomotion/drake#4074 where embedded ruby is also mentioned (on the advice of OSRF), and probably will be supported soon within Drake at build-time.

We decided not to have Drake build-depend on Ruby. We use Python for our scripting tools inside Drake.

[jwnimmer-tri]

\CC @rpoyner-tri FYI This is somewhat related to our upcoming focus on collision groups.