Support loading models from SDF (Simulation Description Format)

[traversaro]

For a long time with iCub we used both the URDF format and the SDF format to represent our robots, see for example the models available at icub-models.

We use URDF for our control software, while we use SDF for Gazebo simulation.

The reason for this duality were two:

• URDF is much easier to write/parse/debug, and is supported by far more support w.r.t. to SDF. For this reason, official or semi-official URDF are available for many robots.
• SDF is necessary because not all Gazebo features are accessible in the Gazebo URDF-extensions. However, we could not go SDF-only as it did not support many features that we need to have for our control/planning software:
  • Fixed joints, for representing six axis F/T sensors
  • Purely kinematic frames ( https://discourse.ros.org/t/urdf-ng-link-and-frame-concepts/56 ) that are necessary to specify in the model frames to use for control and planning
  • The official SDFormat library, that is essential to use given the complexity of the specification, was depending on the Boost libraries, that are always a problematic dependency to have on Windows

As the problem with fixed joints was solved years ago ( https://bitbucket.org/osrf/sdformat/pull-requests/194 ), the boost dependency has been finally removed by migrating to C++17 (https://bitbucket.org/osrf/sdformat/pull-requests/438/removal-of-boost/diff), and there is ongoing work to support purely kinematic frames (https://bitbucket.org/osrf/sdformat/issues/200/support-multiple-frames-in-a-single-parent), it may be interesting to also (not replacing URDF) support for import and export of iDynTree::Model to SDF.

The advantages of SDF over URDF are the following:

• Official specification for sensors tags (http://sdformat.org/spec?elem=sensor)
• Support for closed loop kinematic structures (http://gazebosim.org/tutorials?tut=kinematic_loop&cat=)
• Ongoing active development
• No constraint for the location of the frame (in URDF the link origin needs to lay on the axis of the parent joint if the parent joint is not fixed)

[traversaro]

This may be even more attractive with the recent developent of SDFormat 1.7, see the discussion in https://discourse.ros.org/t/sdformat-pose-frame-semantics-proposal/9852 . That adds some additional advantages:

• A clearly specified semantics to distinguish between frame and links
• A clearly specified system to have custom extensions to the format ( https://discourse.ros.org/t/sdformat-pose-frame-semantics-proposal/9852 )

[diegoferigo]

SDF support would be an excellent addition, particularly with the new frame semantics feature.

Beyond the comprehensive list of advantages your listed, I would add that we can directly use sdformat for the deserialization. It will provide an effortless parser for the SDF files.

Moreover, upstream there's a SDF -> URDF converter in WIP that we could make use.

[traversaro]

Also loading meshes from relative paths (see https://bitbucket.org/osrf/sdformat/pull-requests/558) would be a great feature that currently the "official" URDF specs lacks (see https://github.com/robotology/idyntree/issues/291).

[traversaro]

Related but different issue: support the export of SDF files: https://github.com/robotology/idyntree/issues/835 .