You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 gazebosim/sdformat#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 gazebosim/sdformat#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.
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:
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 gazebosim/sdformat#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 gazebosim/sdformat#93 there was the suggestion to add the
type
attribute to theplugin
tag of sdf. However, this would require adding theattribute
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 aplugin_type
child element to theplugin
element, as the content ofplugin
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 icub-tech-iit/ergocub-software#230 .
fyi @xela-95
The text was updated successfully, but these errors were encountered: