Drake: Need Ability to Export Serialized Version of The World

[liangfok]

Problem Definition

We currently assemble the world by repeatedly adding model instances to a RigidBodyTree (soon to be MultiBodyTree), and instantiating things like sensors and actuators. While this works for simulations and controllers _within_ Drake, it does not bode well with _external_ applications and tools. These include tools in OpenHumanoids and Director.

Proposed Fix

Add the ability to export a fully formed RigidBodyTree into a human-readable serialized format. Since (1) URDF can only support a single model in a file, (2) Drake has its own flavor of URDF, and (3) we cannot express everything in SDF, the exported format will likely need to be a combination of both Drake's flavor of URDF and SDF. Specifically, here is some rough pseudocode of what the exporter could potentially do:

for each model instance in the RigidBodyTree:
  export drake-flavored URDF
end
export SDF that imports all above-generated URDFs and connects them together, and includes actuators and sensors.

[liangfok]

This issue stemmed from a discussion in #5267, which carried over to Slack: https://drakedevelopers.slack.com/archives/drake-kuka-iiwa/p1487958347000651

[patmarion]

I'm not sure I understand the proposed pseudocode. Are you suggesting that kuka_iiwa_wsg.cc writes out urdf files after it constructs the tree in memory?

[liangfok]

Yup! Thoughs?

[patmarion]

would you put those files into version control so that people can use the files without having to run the kuka sim program?

[liangfok]

Per slack discussion, we decided world-serialization should be done pre-RigidBodyTree creation. I shall thus close this issue.

[liangfok]

Would you put those files into version control so that people can use the files without having to run the kuka sim program?

Sure we can do that. Basically, Drake could provide a tool that serializes a programmatically-created RigidBodyTree into one or more files, which could then be used by both Drake and other applications.

[liangfok]

As mentioned above, this issue was originally closed because we decided to do world-serialization pre-RigidBodyTree creation, which I assumed would imply that we would disallow programmatic-creation of a RigidBodyTree. However, in #5317, we decided to continue supporting this capability (see: https://github.com/RobotLocomotion/drake/issues/5317#issuecomment-282455304). Thus, there may still be a need to serialize a RigidBodyTree into one or more files.

[RussTedrake]

@liangfok -- the ability to create trees programmatically is a convenience (for testing, simple apps, etc). That does not imply that we have to serialize them to disk. For the reasons we've already discussed, I don't think that serialization is easy or necessary. I want to close this and take it off the table.

[liangfok]

would you put those files into version control so that people can use the files without having to run the kuka sim program?

BTW, I just read the following description of how auto-generated SDF files should be managed:

Please note that the ruby conversion should be done manually (erb model.sdf.erb > model.sdf) and the final model.sdf file must be uploaded together with the model.sdf.erb (this one only for reference).

http://gazebosim.org/tutorials?tut=model_structure&cat=build_robot.%3C/p%3E#ModelSDF.ERB

This implies to me that SDF officially encourages generated .sdf files to be committed into version control.

[jwnimmer-tri]

That's insane, because it would overwhelm git given the kinds of models and permutations we are talking about. Just have the build system create the generated file, and include the generated file as part of the source & binary releases.

[liangfok]

Good point. We'll try to avoid committing generated files if possible. @patmarion, I assume you'll be OK running xacro or erb to get the generated model files?

[jwnimmer-tri]

What about "have the build system create the generated file" was not a good idea? It minimizes the possibility for user error, and should make it easy for downstream code to use the permutation forest of world files without much effort.

[liangfok]

I assumed @patmarion didn't want to build Drake (I could be wrong), and we don't have any releases yet.

[patmarion]

I'd vote for checking in the generated files where it's reasonable. One reason is to avoid a dependency on xacro (or some other template engine, but xacro is what we've used in the past) in the build system, but I can think of other reasons. We already have generated urdf files in the repo, so there is precedent.

I do build drake, so if the decision is made to do the generation at build time that will work for me.

[jwnimmer-tri]

Files that are generated-but-committed still need to have tool support for regenerating the files, so that any developer can fix a bug and regenerate them. So you can't really escape a dependency on whatever generator tool you choose. Putting it in the build just means that it's guaranteed to work, as opposed to a README with "wget xacro" that will bitrot.