ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

SDFormat: Pose Frame Semantics Proposal

Howdy!

I am robotics software developer for Toyota Research Institute, part of the team working towards robust manipulation. For the past few months, I have been working with @scpeters and @azeey at OSRC to start improving the documentation for the full specification for SDFormat, which can be seen here. We are using this as a launching point to extend SDFormat with a proposal for pose frame semantics, which aims to improve expressivity by enabling the definition of arbitrary coordinate frames within a model and choosing the frame relative to which each frame is defined. This is something that I, as part of TRI, would like for Drake, and something that we hope is useful for the ROS and Gazebo communities.

If you have any high level questions about this proposal that don’t necessarily fit in as a SDFormat issue, please feel free to ask here. If you have more specific questions, please consider opening a sdf_tutorials pull request with suggested changes to enable discussion on BitBucket’s review interface.

If you’re curious about other discussions that have not yet been merged into the SDFormat documentation website, you can view existing sdf_tutorials pull requests.

Thanks!

P.S. Not all discussions happen on a publicly visible forum, but we are trying to distill the main points of those discussions in the proposals to make them discoverable / traceable. Additionally, the proposal process for SDFormat is still a bit ad hoc and has not yet been fully formalized (e.g. using REPs).

P.P.S. This has been cross-posted to Gazebo Community.

First of all, thanks a lot @EricCousineau-TRI @scpeters @azeey for working on this. Personally I hoped to use SDF for non-Gazebo use for a long time to avoid several URDF limitations (see https://github.com/robotology/idyntree/issues/481).

I have a few questions related to PR that have been already merged, so as you suggest I will post them here.

  1. Version number

I think this improved features are quite impactful, and in a sense are not “backward compatible”, in the sense that an SDF 1.6 valid model may not be a valid SDF 1.7 . While this is true also for past SDF version, did you think of naming the new format SDF 2.0, to better convey the fact that is quite an improved format?

  1. Removal of //joint/axis/use_parent_model_frame

Removing the //joint/axis/use_parent_model_frame is a great improvement that drastically simplifies the SDF specs, and simplify its use (see for example the discussion in https://github.com/bulletphysics/bullet3/issues/1707). However, the tag is currently still used in the URDF loader in SDFormat (see https://bitbucket.org/osrf/sdformat/src/08ea83caa185e305fcc5d21b80e0b388cf9901b0/src/parser_urdf.cc#lines-3242). The idea is to provide an automatic updater also for the migration from 1.6 to 1.7 ? Ideally the URDF <–> SDF convert should transform URDF “fake” links to proper SDF frames instead of simply removing them (see https://bitbucket.org/osrf/sdformat/issues/199/urdf-to-sdf-conversion-ignores-links and https://github.com/robotology/icub-models/issues/12#issuecomment-422359912), but that would probably mean that we need to modify the URDF <–> SDF converter to target SDF 1.7

Ideally the URDF <–> SDF convert should transform URDF “fake” links to proper SDF frames instead of simply removing them (see https://bitbucket.org/osrf/sdformat/issues/199/urdf-to-sdf-conversion-ignores-links and https://github.com/robotology/icub-models/issues/12#issuecomment-422359912), but that would probably mean that we need to modify the URDF <–> SDF converter to target SDF 1.7

This exact issue started bugging me in some simulations I was trying to do and it converted me into writing the robot description in SDF instead of URDF and converting it to URDF later. But I think the issue with “fake links” is more of an issue of trying to create a link in Gazebo that is not static without any physical properties, maybe that would require some changes in the simulator itself.
I added a sdf2urdf and a urdf2sdf converters in the package I have been working on and it required some computation so the poses would be consistent in both formats.
One of the things that I wish could be done is to express the orientation in the <pose> as a quaternion as well, though.