SDFormat: Pose Frame Semantics Proposal

[EricCousineau-TRI]

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.

[traversaro]

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?

2. 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

[musamarcusso]

Ideally the URDF <–> SDF convert should transform URDF “fake” links to proper SDF frames instead of simply removing them (see Log in with Atlassian account and Add support for using icub-models out of the box with PyBullet · Issue #12 · robotology/icub-models · GitHub), 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.

[traversaro]

@musamarcusso

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.

Probably this is a bit OT, but nevertheless: if a “link” does not have any physical properties, probably it does not make a lot of sense to call it “link”, but “frame” would be a more proper term to refer to it? This is indeed the spirit of the SDF 1.7 proposal, as far as I understand.

@musamarcusso

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.

Those scripts seems to be really great, thanks for sharing! Do you plan to release a ROS-independent version?

[musamarcusso]

@traversaro

Probably this is a bit OT, but nevertheless: if a “link” does not have any physical properties, probably it does not make a lot of sense to call it “link”, but “frame” would be a more proper term to refer to it? This is indeed the spirit of the SDF 1.7 proposal, as far as I understand.

Definitely! Frame is the correct syntax and I am glad it is in the proposal. I can think of numerous cases where frames disassociated from physical links would be handy, but always needed a work around to get done in Gazebo.

Those scripts seems to be really great, thanks for sharing! Do you plan to release a ROS-independent version?

I have been thinking about it, especially because one of the ideas of the package is to make it possible to design and preview the simulation scenario via Python in Jupyter notebooks and setting up the package dependencies via rosdep for Python 3 is currently tricky.

[scpeters]

@traversaro

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?

The proposal initially called for SDF 2.0 as there are some restrictions added to the naming rules for sibling element, but the bigger changes are the semantics for the <frame/> element and the <pose relative_to=''/> attribute. Since the spec is backwards-compatible with respect to these changes (a 1.7 file without frame or relative_to has the same kinematics as if it were a 1.6 file), it seemed more like a minor than a major release. That was are reasoning, and we are open to further feedback on the matter.

[scpeters]

@musamarcusso

One of the things that I wish could be done is to express the orientation in the <pose> as a quaternion as well, though.

There is an open pull request in urdfdom_headers to allow quaternions to be specified in poses ( Add Vector4 and initQuaternions to be able to parse quaternions from URDF files by VictorLamoine · Pull Request #51 · ros/urdfdom_headers · GitHub ), but changes to urdfdom have been slow as the parser doesn’t have a concept of versions in urdf. We could consider adding pose quaternions to SDFormat. Do you have any thoughts about what the syntax should look like?

[scpeters]

@traversaro

2. 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 Bullet SDF parser does not parse correctly SDF files with <use_parent_model_frame>1</use_parent_model_frame> · Issue #1707 · bulletphysics/bullet3 · GitHub). 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).

Independently of this proposal, I think we should update parser_urdf to set sdformat version 1.5, which would avoid the use_parent_model_frame tag. Does it only require changing that one line?

[traversaro]

@scpeters

Independently of this proposal, I think we should update parser_urdf to set sdformat version 1.5, which would avoid the use_parent_model_frame tag. Does it only require changing that one line?

There are a few more lines (related on how the axis is computed at https://bitbucket.org/osrf/sdformat/src/bac3dfb42cc72cb609c0bcdbef2064326f5061dd/src/parser_urdf.cc#lines-2914).
For more details, see the dedicated issue at Log in with Atlassian account, that I totally forgot I opened.

[EricCousineau-TRI]

FYI Related to the removal of use_parent_model_frame, I’m concerned about the complications for migration. I’m trying out the newer stuff in Drake now: https://github.com/RobotLocomotion/drake/pull/12061

Posted a proposal update here:

Update pose frame proposal to support //xyz[@expressed_in]

Please weigh in you feel strongly for / against it. That being said, I agree with Steve’s suggested solution to use a later SDFormat version. (Ideally, once we iron this out, perhaps it could use SDFormat 1.7 once it’s usable in Gazebo?)