gazebo中的多机器人仿真指的是在gazebo中加入多个urdf，并控制机器人运动。下面是我总结的一些名称的命名规律

1 joint名称

在spawn_model中，通过-model model_name添加参数，则joint名称为: model_name::joint_name，该名称可以通过gazebo仿真查看，和命名空间无关。

2 topic名称

topic名称的修改是通过在launch file中加入命名空间实现的。值得注意的是：topic名称只需要修改一次，如果在最外层group加入了ns参数，或者通过include标签加入了ns参数，则里面包含的文件和节点都不应该添加命名空间ns参数。

举例:

  <include file="$(find agv_gazebo)/launch/agv_gazebo.launch" ns="agv_car0">
	<arg name="ns" value="agv_car0"/>
  </include>

那么在agv_gazebo.launch中所有的节点包括group就不应该再次添加ns标签。而我传入ns参数的原因是为了修改gazebo包中的一些参考系名称，所以传入了ns.

节点名称也受命名空间影响，因此不同命名空间下的可以有同名的节点，不需要修改节点名称。如果指定节点name属性为node_name，那么实际情况下，节点名称会变为: ns\node_name

如何将参数传入urdf或者xacro文件中：在加载入参数服务器时候添加参数，比如：

<param name="robot_description" 
		command="$(find xacro)/xacro '$(find agv_gazebo)/urdf/agv_car.urdf.xacro' ns:=$(arg ns)" />

然后在xacro文件中通过$(arg xxx)使用该参数，注意xacro中使用变量的方法是${xxx}

可能在配置gazebo包，比如diff_drive中遇到，该值不受命名空间影响，需要自己修改为需要的值。比如说：

<odometryFrame>$(arg ns)/odom</odometryFrame>

受到命名空间影响，不需要自己配置，比如

<odometryTopic>odom</odometryTopic>

实际发布的位置是ns/odom

需要自己配置，不受命名空间影响

<robotNamespace>$(arg ns)</robotNamespace>

都需要自己添加，不受命名空间影响。比如

<param name="odom_frame_id" value="$(arg ns)/odom"/>

以及

<param name="local_costmap/robot_base_frame" value="$(arg ns)/base_footprint"/>

move_base中的scan需要自己添加命名空间：

<param name="scan" value="{sensor_frame: $(arg ns)/laser, data_type: LaserScan, topic: $(arg ns)/scan, marking: true, clearing: true}"/>

值得注意的是，这个laser的坐标系出现的位置是在urdf中指定的：

<plugin name="gazebo_rplidar" filename="libgazebo_ros_laser.so">
  <topicName>scan</topicName>
  <frameName>$(arg ns)/laser</frameName>
</plugin>

这个例子也很好体现了在urdf中，命名空间只影响topic，不影响frame

有两种可行的坐标系，分别是每个机器人有一个独立的odom坐标系，以及共用一个odom坐标系，odom坐标系是里程计坐标系，不知道这两种的区别。我使用的是独立的odom坐标系。

下面看下公用的odom参考系，例子是: https://www.guyuehome.com/4889

这里需要注意了：

我一开始同时参考他们两个例子，结果发现不对。后来发现两个例子的思路是有区别的。