Invalid sdf error for gymkhana task

[M1chaelM]

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]

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]

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]

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

• The libsdformat parser code explicitly notes that duplicated plugin names are allowed (see comment on line 1476: https://github.com/ignitionrobotics/sdformat/blob/sdf11/src/parser.cc).
• It does not rename them when processing the include tag, as it does with other elements, and it uses their indices instead of their names to avoid conflicts.
• The code producing the errors and warnings uses the HasUniqueChildNames function to check for duplicate file names. This is called both from Server.cc in Gazebo and Model.cc in libsdformat. In both cases, the calling functions should first check whether the element type is "plugin" and if it is, they should not call HasUniqueChildNames.

[M1chaelM]

I've reported this as a bug in sdformat, here: gazebosim/sdformat#712
I'll update further when there is a response.

[caguero]

This pull request should fix our issue.

gazebosim/sdformat#733

[M1chaelM]

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

[M1chaelM]

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]

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:

• /vrx_gazebo/worlds/xacros/gymkhana.xacro
• /vrx_gazebo/worlds/example_course.world.xacro
• /vrx_gazebo/worlds/gymkhana.world.xacro
• /vrx_gazebo/worlds/2022_phase2/gymkhana0.world
• /vrx_gazebo/worlds/2022_phase2/gymkhana1.world
• /vrx_gazebo/worlds/2022_phase2/gymkhana2.world
• /vrx_gazebo/worlds/2022_phase2/gymkhana3.world
• /vrx_gazebo/worlds/2022_phase2/gymkhana4.world
• /vrx_gazebo/worlds/2022_phase2/gymkhana5.world
• /vrx_gazebo/worlds/2022_practice/gymkhana1.world
• /vrx_gazebo/worlds/2022_practice/gymkhana0.world
• /vrx_gazebo/worlds/2022_practice/gymkhana2.world

[M1chaelM]

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