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 work well with _external_ applications and tools like those in OpenHumanoids and Director.
Drake has a custom URDF parser that is more expressive than SDF in many respects. We don't want to loose this expressiveness by switching entirely to SDF. (This is a temporary situation -- once SDF's expressiveness is a superset of URDF's expresiveness, we should switch entirely to SDF.)
URDF is unable to express floating joints or multiple model instances without modifying the link names to include an "instance identifier". This prevents us from solely relying on URDF. SDF, on the other hand, does support the inclusion of multiple models within a single file.
Let's update Drake's SDF parser to allow the inclusion of URDFs and other SDFs. This will enable us to describe the _entire simulated world_ using SDF and URDF files and thus initialize the RigidBodyTree via a single call to the SDF parser. ~We should thus disable the ability to load~ We could then discourage, but not prevent, users from loading multiple model instances into the RigidBodyTree by calling the parsers multiple times. The motivation is this programmatic method of loading model instances into RigidBodyTree does not facilitate other tools like those in OpenHumanoids and Director to make use of the same model being used by Drake.
I think there are valid use cases for defining multibody geometry on the fly, and just simulating / visualizing it. We should not disallow that.
Would requiring all of those uses cases go through a serialization phase be too arduous? In other words, phase 1 is to generate the SDF + URDF files, then phase 2 is to simulate & visualize them.
Yes, unacceptable.
Alright, I've updated the OP to not prevent users from initializing a RigidBodyTree by repeatedly calling the parsers.
In what ways is URDF more expressive than SDF?
We added some drake-specific tags to urdf that we have not ported to sdf yet. (springs, dampers, airfoils, cable-drives, etc). Many of those are still matlab-parser-only, though.
I updated the OP with a link to Drake's URDF schema: http://drake.mit.edu/urdf/drakeURDF.html, which can be contrasted with ROS's URDF specification: http://wiki.ros.org/urdf/XML.
Step 2 of the following tutorial shows how to attach a gripper to a robot using a SDF file:
http://gazebosim.org/tutorials?tut=attach_gripper&cat=build_robot
I copy/pasted the relevant example below:
<?xml version="1.0" ?>
<sdf version="1.5">
<model name="simple_mobile_manipulator">
<include>
<uri>model://my_gripper</uri>
<pose>1.3 0 0.1 0 0 0</pose>
</include>
<include>
<uri>model://my_robot</uri>
<pose>0 0 0 0 0 0</pose>
</include>
<joint name="arm_gripper_joint" type="fixed">
<parent>mobile_base::chassis</parent>
<child>simple_gripper::riser</child>
</joint>
<!-- attach sensor to the gripper -->
<include>
<uri>model://hokuyo</uri>
<pose>1.3 0 0.3 0 0 0</pose>
</include>
<joint name="hokuyo_joint" type="fixed">
<child>hokuyo::link</child>
<parent>simple_gripper::palm</parent>
</joint>
</model>
</sdf>
Basically, the idea is to include the SDFs of the robot and gripper while specifying their poses, then add joints to connect them. The bodies being connected by the joints are specified using [model instance name]::[body name] syntax.
To include multiple instances of another model within the current model, you can use the <name>...</name> tag: http://sdformat.org/spec?ver=1.6&elem=model#include_name
I was able to use SDF's <include>...</include tags to assemble a model containing two iiwa14s, two extra heavy duty tables, and one desk. The model is loadable in Gazebo, giving me some confidence that my SDF's syntax is correct:

One problem with my current SDF is it lumps all of the models into a single model in the world. I will next try to combine the <world>...</world> tags with the <include>...</include> tags to assemble a world consisting of multiple discrete models.
I figured out a working SDF syntax for including and instantiating separate SDF models. The example is in #5332. Now that I know what the <world><model><include>...</include></model></world> syntax looks like, we can begin modifying the SDF parser to support it.
One major question is whether we should wait for the new libsdformat library to be integrated (#4337) or modify Drake's current custom SDF parser.
Upon further reflection, I think it would be best to prioritize the switch to libsdformat (#4337) prior to adding support for SDF files to include other SDF and URDF files. This will avoid wasted effort updating Drake's current SDF parser. @sherm1 and @clalancette, please let me know if I should think otherwise. Thanks!
Sounds right to me, @liangfok. Any update @clalancette?
Hi @sherm1 ,
Sorry I haven't had any updates for a while on this. I've been stuck in sdformat land, trying to get rid of boost stuff. I've made a lot of progress there, but haven't yet completed it. Once that is done, I can get back to my PR to get sdformat integrated into drake. I'll keep you informed.
Closing this to track progress in this regard in the newer issue #8718 for MBP/sdformat.
Most helpful comment
Hi @sherm1 ,
Sorry I haven't had any updates for a while on this. I've been stuck in sdformat land, trying to get rid of boost stuff. I've made a lot of progress there, but haven't yet completed it. Once that is done, I can get back to my PR to get sdformat integrated into drake. I'll keep you informed.