Closed diegoferigo closed 1 month ago
Ok I guess it's now time to remove support for the sdformat
version included in Ubuntu 22.04. cc @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:
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.
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?
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.
I plan to update the main README with the new dependencies in another PR.
Ok.
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?
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).
libsdformat14
and libgz-tools2
, the check does not raise any exception.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.
libsdformat13 gz-tools2
installed from the OSRF repo, the check does not raise any exception.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.
@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.
This PR:
//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).//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:TL;DR
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 minimumsdformat
version is raised to 13.x. This version allows to have thegz sdf
command line just by installing a small subset of the Gazebo libraries.Some further details on the logic introduced by this PR:
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.