Open M1chaelM opened 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.
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?
On further investigation, I'm leaning toward the conclusion that these error messages themselves are the bug.
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).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
.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.
This pull request should fix our issue.
This appears to still be a problem. Need to investigate why.
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.
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:
Generally, we may want to migrate everything to sdf9
as part of release 2.0.
Running the task 5 example with
Produces the following errors: