osrf / vrx

Virtual RobotX (VRX) resources.
Apache License 2.0
427 stars 193 forks source link

Invalid sdf error for gymkhana task #349

Open M1chaelM opened 3 years ago

M1chaelM commented 3 years ago

Running the task 5 example with

roslaunch vrx_gazebo gymkhana.launch extra_gazebo_args:=--verbose

Produces the following errors:

Error: Non-unique names detected in type plugin in
<model name='short_navigation_course_0'>
...
[Err] [Server.cc:98] SDF is not valid, see errors above. This can lead to an unexpected behaviour.
Warning [Model.cc:212] Non-unique names detected in XML children of model with name[short_navigation_course_0].
Warning [Model.cc:212] Non-unique names detected in XML children of model with name[buoys].
M1chaelM commented 3 years ago

The cause of this error is using the same name for the buoyancy plugin while attaching it to multiple models that are themselves part of the same model. For example, the short_navigation_course_0 model is comprised of 6 mb_marker_buoy models of various colors. Each of these attaches the buoyancy plugin with:

<plugin name="BuoyancyPlugin" filename="libbuoyancy_gazebo_plugin.so">

The robotx_light_beacon model also uses the same buoyancy plugin name, but this doesn't seem to matter unless it is placed in a single sdf with another model that has the same plugin name. I'm not sure whether it's possible to override the default name of the plugin using the include tag. If not, this warning may not be worth fixing right now.

M1chaelM commented 3 years ago

Looking a little further, I'm confused why the include tag does not rename the plugin the way it renames the links and joints (see the description here: http://sdformat.org/tutorials?tut=composition). It seems like it should automatically change the name to something like red_bound_1::BuoyancyPlugin since the non-unique names error we're getting is what this renaming is supposed to prevent.

@caguero What do you think? Is this a bug in libsdfformat? Or is there a reason to treat the plugin name differently from link and joint names?

M1chaelM commented 3 years ago

On further investigation, I'm leaning toward the conclusion that these error messages themselves are the bug.

M1chaelM commented 3 years ago

I've reported this as a bug in sdformat, here: https://github.com/ignitionrobotics/sdformat/issues/712 I'll update further when there is a response.

caguero commented 3 years ago

This pull request should fix our issue.

https://github.com/ignitionrobotics/sdformat/pull/733

M1chaelM commented 2 years ago

This appears to still be a problem. Need to investigate why.

M1chaelM commented 2 years ago

Looks like this was fixed in libsdformat11 and backported to libsdformat9. According to the roadmap, this corresponds to <sdf version="1.7" and <sdf version="1.8". We are currently at "1.6". Incrementing to "1.7" resolves the issue.

M1chaelM commented 2 years ago

To fix this error in particular, we need to increment to version="1.7" for all sdfs that use the short_navigation_course0 or the obstacle_course models. These are:

M1chaelM commented 2 years ago

Generally, we may want to migrate everything to sdf9 as part of release 2.0.