Environment
- OS Version: Ubuntu 20.04
- Source or binary build?
Binary: 9.6.1
Description
- Expected behavior: Have multiple child elements with the same name should not produce an error if the element type is "plugin"
- Actual behavior:
If an element in the SDF contains multiple child plugin elements with the same name:
- The
recursiveSameTypeUniqueNames function and the recursiveSiblingUniqueNames function in parser.cc (called by Gazebo) output an error message containing the entire element followed by the message
[Err] [Server.cc:98] SDF is not valid, see errors above. This can lead to an unexpected behaviour.
Model.cc also produces a warning:
Warning [Model.cc:212] Non-unique names detected in XML children of model with name[element_name]
Steps to reproduce
- Define a model with a plugin in the definition. For example we have a buoy model (https://github.com/osrf/vrx/blob/master/vrx_gazebo/models/mb_marker_buoy_red/model.sdf) that uses an attached bouyancy plugin.
- Define a nested model that uses several instances of the model you defined the previous step. For example, we have a nested model that arranges several of these buoys into a navigation course.
- Launch Gazebo using a world that has the nested model in it.
Output
Using a version of the example above with only two buoys, we see:
Error: Non-unique names detected in type plugin in
<model name='short_navigation_course_0'>
<frame name='red_bound_0::__model__' attached_to='red_bound_0::link'>
<pose relative_to='__model__'>0 0 0 0 -0 0</pose>
</frame>
<link name='red_bound_0::link'>
<inertial>
<pose>0 0 -2 0 -0 0</pose>
<mass>20</mass>
<inertia>
<ixx>1</ixx>
<ixy>0</ixy>
<ixz>0</ixz>
<iyy>1</iyy>
<iyz>0</iyz>
<izz>0.1</izz>
</inertia>
</inertial>
<collision name='collision_inner'>
<pose>0 -0.02 0.02 0 -0 0</pose>
<geometry>
<cylinder>
<radius>0.15</radius>
<length>1.15</length>
</cylinder>
</geometry>
</collision>
<collision name='collision_outer'>
<pose>0 0 -0.3 0 -0 0</pose>
<geometry>
<cylinder>
<radius>0.325</radius>
<length>0.1</length>
</cylinder>
</geometry>
</collision>
<visual name='visual'>
<pose>0 0 0 1.57079 -0 0</pose>
<geometry>
<mesh>
<uri>model://mb_marker_buoy_red/meshes/mb_marker_buoy.dae</uri>
</mesh>
</geometry>
<material>
<script>
<uri>model://mb_marker_buoy_red/materials/scripts/mb_marker_buoy.material</uri>
<name>mb_marker_buoy/Red</name>
</script>
</material>
</visual>
<pose relative_to='red_bound_0::__model__'>0 0 0 0 -0 0</pose>
</link>
<plugin name='BuoyancyPlugin' filename='libbuoyancy_gazebo_plugin.so'>
<wave_model>ocean_waves</wave_model>
<fluid_density>1000</fluid_density>
<fluid_level>0.0</fluid_level>
<linear_drag>25.0</linear_drag>
<angular_drag>2.0</angular_drag>
<buoyancy name='buoyancy_sphere'>
<link_name>red_bound_0::link</link_name>
<pose>0 0 -0.12 0 0 0</pose>
<geometry>
<sphere>
<radius>0.325</radius>
</sphere>
</geometry>
</buoyancy>
</plugin>
<frame name='green_bound_0::__model__' attached_to='green_bound_0::link'>
<pose relative_to='__model__'>0 -20 0.2 0 -0 0</pose>
</frame>
<link name='green_bound_0::link'>
<inertial>
<pose>0 0 -2 0 -0 0</pose>
<mass>20</mass>
<inertia>
<ixx>1</ixx>
<ixy>0</ixy>
<ixz>0</ixz>
<iyy>1</iyy>
<iyz>0</iyz>
<izz>0.1</izz>
</inertia>
</inertial>
<collision name='collision_inner'>
<pose>0 -0.02 0.02 0 -0 0</pose>
<geometry>
<cylinder>
<radius>0.15</radius>
<length>1.15</length>
</cylinder>
</geometry>
</collision>
<collision name='collision_outer'>
<pose>0 0 -0.3 0 -0 0</pose>
<geometry>
<cylinder>
<radius>0.325</radius>
<length>0.1</length>
</cylinder>
</geometry>
</collision>
<visual name='visual'>
<pose>0 0 0 1.57079 -0 0</pose>
<geometry>
<mesh>
<uri>model://mb_marker_buoy_red/meshes/mb_marker_buoy.dae</uri>
</mesh>
</geometry>
<material>
<script>
<uri>file://media/materials/scripts/gazebo.material</uri>
<name>Gazebo/White</name>
</script>
</material>
</visual>
<pose relative_to='green_bound_0::__model__'>0 0 0 0 -0 0</pose>
</link>
<plugin name='BuoyancyPlugin' filename='libbuoyancy_gazebo_plugin.so'>
<wave_model>ocean_waves</wave_model>
<fluid_density>1000</fluid_density>
<fluid_level>0.0</fluid_level>
<linear_drag>25.0</linear_drag>
<angular_drag>2.0</angular_drag>
<buoyancy name='buoyancy_sphere'>
<link_name>green_bound_0::link</link_name>
<pose>0 0 -0.12 0 0 0</pose>
<geometry>
<sphere>
<radius>0.325</radius>
</sphere>
</geometry>
</buoyancy>
</plugin>
<pose>-475 185 0 0 0 -2.14</pose>
</model>
[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].
Additional Notes
I haven't yet found documentation confirming that duplicate plugin names are allowed, but the comment on line 1476 of parser.cc in sdformat suggests this is the case.
Additionally, the sdformat implementation of the <include> tag does not rename plugins to avoid name conflicts, as it does with other elements, and plugin names also can't be overridden when a model is invoked. As illustrated in the above example, this means that whenever a model definition includes a plugin and that model is used more than once in a nested model, Gazebo will report that the SDF is invalid.
Environment
Binary: 9.6.1
Description
If an element in the SDF contains multiple child plugin elements with the same name:
recursiveSameTypeUniqueNamesfunction and therecursiveSiblingUniqueNamesfunction inparser.cc(called by Gazebo) output an error message containing the entire element followed by the messageModel.cc also produces a warning:
Steps to reproduce
Output
Using a version of the example above with only two buoys, we see:
Additional Notes
I haven't yet found documentation confirming that duplicate plugin names are allowed, but the comment on line 1476 of
parser.ccinsdformatsuggests this is the case.Additionally, the sdformat implementation of the
<include>tag does not rename plugins to avoid name conflicts, as it does with other elements, and plugin names also can't be overridden when a model is invoked. As illustrated in the above example, this means that whenever a model definition includes a plugin and that model is used more than once in a nested model, Gazebo will report that the SDF is invalid.