Add namespace support to SDF elements for easier multi-robot simulation

[C88-YQ]

Desired behavior

It would be useful if SDFormat could provide native support for a namespace field, so that tools and simulators using SDFormat can better support multi-robot simulations.

In multi-robot simulations, users often want to spawn or include multiple instances of the same robot description file (.sdf/.urdf). However, to avoid topic collisions, users usually need to manually modify or template description file (.sdf/.urdf), for example by adding prefixes to topic names, sensor plugin parameters, plugin parameters.

The desired behavior is to allow users to reuse the same robot description file more easily, while still keeping the communication interfaces of each robot isolated.For example, users should be able to include or spawn the same SDF / URDF description file multiple times and assign a different namespace to each instance, without duplicating or heavily modifying the original robot description file.

Alternatives considered

One possible alternative is to reuse the existing name field as the namespace. However, I think name and namespace have different meanings:

• name: mainly describes the identity of an entity or system in the simulation.
• namespace: describes the communication scope used by topics and related interfaces.

Following is an example showing the difference:

<model name="robot1">
  ...
  <plugin
    filename="gz-sim-diff-drive-system"
    name="gz::sim::systems::DiffDrive"
    namespace="controller">
    ...
  </plugin>
</model>

Another reason is flexibility. The name field is usually required, while namespace can be optional. Users may not always want every element name to become part of the topic namespace. For example:

<model name="robot1">
  ...
  <model name="body">
    ...
  </model>

  <model name="sensor">
    <link name="camera_link">
      ...
      <sensor name="camera" type="camera">
        <topic>/data</topic>
        ...
      </sensor>
    </link>
  </model>
</model>

In this case, the user may want the final camera topic to be /robot1/camera/data, instead of /robot1/sensor/camera/data

Implementation suggestion

1. Add an optional namespace attribute to world, model, sensor, and plugin

   Since namespace is similar to name in that it describes metadata of the element itself, I think it may be reasonable to define it as an attribute. For example:

   <attribute name="namespace" type="string" default="" required="0">
     <description>
       Namespace used for communication interfaces related to this element.
     </description>
   </attribute>

   To avoid making this a breaking change, we could make namespace an optional attribute with an empty default value.

2. Add an optional namespace element to include

   For include, the design may need to be different from world, model, sensor, and plugin. I think it may be better to follow the current name override style in include, and add namespace as an element inside include. For example:

   <include>
     <uri>model://my_robot</uri>
     <name>robot1</name>
     <namespace>robot1</namespace>
   </include>

   The namespace value in include could override the namespace of the top-level included element.

3. Support a placeholder such as __name__

   In many cases, the desired namespace is the same as the name. For this common case, it may be useful to support a placeholder such as __name__, which means “use the final resolved name of this element as the namespace”. For example:

   <model name="robot" namepace="__name__">
     ...
   </model>

   For ros_gz users, they could specify only the entity name when spawning the robot, and the namespace could automatically follow that name.

   ros2 run gazebo_ros spawn_entity.py \
     -entity robot1 \
     -topic robot_description \

Additional context

This idea mainly comes from the Gazebo multi-robot simulation use case. The goal is to provide a standard way for SDFormat users and downstream tools to describe communication namespaces, so that multiple robot instances can be used with less manual SDF / URDF templating.

I am not fully sure whether this design fits all SDFormat use cases, or whether this should be handled at the SDFormat level.

I would appreciate feedback and advice from maintainers and the community.