gz-sim icon indicating copy to clipboard operation
gz-sim copied to clipboard

gz-sim should not print an error if a model contains a gazebo-classic plugin

Open traversaro opened this issue 3 months ago • 0 comments

Desired behavior

As part of the migration to gz-sim, we are migrating some URDF models that contains SDF plugin tags embedded via the <gazebo> URDF extension from Gazebo Classic to gz-sim .

During the transition, our plan is for the URDF model to contain both gz-sim and gazebo classic plugins, so that the users can use the model with both simulators, depending on the one they want to use.

At the moment, this currently works, but whenever gz-sim finds a gazebo classic plugins, it prints an error.

To make a simple self-contained example, see the world available at https://gist.github.com/traversaro/0cd565e3bbd716a85f04d6b9abcc4ee7 . If I try to run it in gz-sim 8, everything works fine, but an error is printed:

git clone https://gist.github.com/traversaro/0cd565e3bbd716a85f04d6b9abcc4ee7 test_world
cd test_world
gz sim ./test_model.world
[Err] [SystemLoader.cc:92] Failed to load system plugin [libCameraPlugin.so] : Could not find shared library.

While this is not something extremely problematic, it is confusing for a user that are not experts in Gazebo to see an error when they load a model that should work fine. For the sake of ensuring a fast and smooth transition to gz-sim, it would be great to have some way to clearly mark plugins that belong to gazebo_classic (or any other simulator that is not gz-sim, see https://github.com/gazebosim/sdformat/issues/93) so that gz-sim can simply ignore it.

Alternatives considered

A possible alternative is to have separate models for gazebo classic and gz-sim . Unfortunately, this would be complex to handle both at the user side consuming the model and for the maintenance of the model itself, so we actually prefer the errors to have multiple models. Furthermore, that would break the idea of a having a single source of truth for the model information.

A possible alternative is to have a single plugin-less model, that then is included via SDF's include facilities in two different models, one for gazebo classic and another for gz-sim, but also that would be cumbersome to deal with.

Implementation suggestion

At the moment gz-sim has no way to distinguish between gazebo classic and gz-sim plugins. We would need for sure to provide some way to distinguish between the two. In https://github.com/gazebosim/sdformat/issues/93 there was the suggestion to add the type attribute to the plugin tag of sdf. However, this would require adding the attribute tag to all sdf version down to 1.7, and the downside of creating a warning in all older gazebo classic and gz-sim that do not support it. A possible alternative is to add a plugin_type child element to the plugin element, as the content of plugin element is not covered by the sdf spec. In that way, we could add an element to distinguish between different plugins, without adding warnings for older sdf parsers.

Additional context

See https://github.com/icub-tech-iit/ergocub-software/pull/230 .

fyi @xela-95

traversaro avatar Mar 25 '24 16:03 traversaro