idyntree
idyntree copied to clipboard
Support loading models from SDF (Simulation Description Format)
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)
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 )
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.
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).
Related but different issue: support the export of SDF files: https://github.com/robotology/idyntree/issues/835 .