Enhance processing and URDF export of //frame elements

[diegoferigo]

This PR:

• Fixes the computation of the //frame/pose element when not explicitly defined in the model description following the documented semantics (pay attention how the pose is defined when there is no explicit //frame/pose, and what's the default when also //frame/attached_to is not defined).
• Enhances the process of converting //frame elements to compatible chains in URDF.

---

In the last two year, sdformat received different updates on how URDF models are converted to SDF. In particular, few of them altered how kinematic chains involving massless links (or with tiny masses) are processed. Here below some references for those that want to dig deeper:

• URDF->SDF handle links with no inertia or small mass gazebosim/sdformat#1238
• parser_urdf: add //frame for reduced links/joints gazebosim/sdformat#1148
• URDF to SDF conversion ignores links without inertia gazebosim/sdformat#199 (comment)

TL;DR

• Before, links with mass smaller than 1e-6 were completely ignored, now instead they become frames.
• Before, child link of fixed joints (without additional tags for keeping such joints) were lumped into the parent link of the joint, therefore disappearing in the output model. Now, when a link is lumped, instead of disappear, becomes a SDF frame.

This PR bumps the minimum version of sdformat to 12.x such that the processing of such cases is handled in a unique way. Then, in order to prevent the need to install a full Gazebo suite, the minimum sdformat version is raised to 13.x. This version allows to have the gz sdf command line just by installing a small subset of the Gazebo libraries.

---

Some further details on the logic introduced by this PR:

• Switching frame convention has now an additional attach_frames_to_links option to update the //frame/attached_to element to be a link, following recursively the hierarchy. In this way, downstream projects can post-process easily frames attached to other frames knowing their real parent link.
• The inverse of a transform is now computed without inverting the original transform.

[diegoferigo]

Ok I guess it's now time to remove support for the sdformat version included in Ubuntu 22.04. cc @traversaro

[traversaro]

Ok I guess it's now time to remove support for the sdformat version included in Ubuntu 22.04. cc @traversaro

That kinds of mean enforcing the installation of gz sim via openrobotics's apt repo in apt and gz-sim with conda-forge on conda-forge, right? Fortunatly both at the moment are side-by-side installable with gazebo classic thanks to:

• Add variants to permit clean co-installation with libgz-tools2  conda-forge/gazebo-feedstock#208
• Installing Gazebo11 side by side with new Gazebo Tutorial gazebosim/docs#438

[diegoferigo]

That kinds of mean enforcing the installation of gz sim via openrobotics's apt repo in apt and gz-sim with conda-forge on conda-forge, right?

Yep!

I don't want to install the whole Gazebo Sim suite just for having the /usr/bin/gz sdf command. I tried to get it using Fortress (sdformat 12.x and gz-tools 1.x), but I couldn't find a way to install only a subset of the libraries. Instead, things work fine with sdformat 13.x and gz-tools 2.x. I propose to support them as minimum versions.

Btw, the working versions are the first ones after the transition from Ignition Gazebo to Gazebo Sim.

---

Edit: on Fortress it's actually possible to have a minimum installation with only libsdformat12 gz-tools, but the right command line is ign sdf. However, as discussed below, this sdformat supports only the 1.9 SDF specification that at the time of writing does not have all the necessary features to support what ROD require.

[traversaro]

Can you add a few lines on this runtime dependency on sdformat + gz-tools ? As long as the dependency was just any gz command (either gz-tools+sdformat or gazebo classic) I guess it was quite common for users to just have in the system and/or environemnt, while now the the requirement is more specific, it is quite probably that users will get it wrong. By the way, what is the error in case gz from gazebo classic is installed?

[diegoferigo]

Can you add a few lines on this runtime dependency on sdformat + gz-tools?

I plan to update the main README with the new dependencies in another PR. I will also bump Python to 3.10. Furthermore, I'd also like to add these dependencies to the conda-forge recipe of rod so that they get automatically installed.

By the way, what is the error in case gz from gazebo classic is installed?

You can see the test failing here. The sdformat of Gazebo Classic 1) does not convert chains of dummy links to frames and 2) links with zero mass are silently removed.

[traversaro]

I plan to update the main README with the new dependencies in another PR.

Ok.

[traversaro]

You can see the test failing here. The sdformat of Gazebo Classic 1) does not convert chains of dummy links to frames and 2) links with zero mass are silently removed.

So it does not fail on gz invocation, but silently produce the wrong result? Do you think we can make that an hard failure?

[flferretti]

LGTM, thank you Diego! I just left a comment on a minor thing

[diegoferigo]

So it does not fail on gz invocation, but silently produce the wrong result? Do you think we can make that an hard failure?

I gave it a thought. Initially I was thinking how to check the installed sdformat version either by checking the output of gz sdf --versions or by inspecting the OS. I didn't like both solutions as they are quite fragile.

Then, I realized that the sdformat version is not really relevant. What really matters is the SDF specification. This can be checked more easily by processing a SDF string <sdf version='1.4'> and checking the version of the output (I used 1.4 as the minimum specification listed in the sdformat website).

---

• On my setup based on conda-forge with libsdformat14 and libgz-tools2, the check does not raise any exception.
• On a clean Ubuntu 22.04 docker image with a Gazebo classic installation (and libsdformat9-9), I get the following exception:

  RuntimeError: The found sdformat installation only supports the '1.7' specification, while ROD requires at least the '1.10' specification.
  

• On a clean Ubuntu 22.04 docker image with libsdformat13 gz-tools2 installed from the OSRF repo, the check does not raise any exception.
• On a clean Ubuntu 22.04 docker image with libsdformat12 gz-tools installed from the OSRF repo (on this setting, the command line is the old ign sdf instead of gz sdf), the check raises the following exception:

  RuntimeError: The found sdformat installation only supports the '1.9' specification, while ROD requires at least the '1.10' specification.
  

  On this setup, I also verified that the rod tests fail since I was not sure that this specific sdformat version got the necessary features required by the new //frame handling.

[diegoferigo]

@traversaro last check? Apparently on Windows files need to properly closed before being opened by another process, therefore I had to pass through a temporary directory when a model description string has to be processed by sdformat.

[traversaro]

Great!