简介：这是一份面向ROS初学者与进阶者的多机器人仿真项目资料，围绕导航与编队两大功能展开，包含完整的仿真环境与机器人模型，适合作为毕业设计、课程设计或工程实训的参考基础。资源共包含70个文件，压缩包仅1.22MB；其中launch启动文件用于启动仿真，yaml参数配置用于调整导航与编队参数，world文件定义仿真场景，urdf/xacro机器人描述文件负责模型构造，cpp控制源码提供可扩展逻辑，并配有rviz可视化配置与地图文件，便于直接运行和二次修改。已有329人学习或下载，内容组织清晰：多机器人编队包、机器人描述模块、导航模块、Gazebo仿真与遥控脚本等目录一应俱全。借助该资料可快速搭建多机器人协同仿真场景，理解导航与编队控制的基本流程，也能为后续算法改进或项目扩展提供可复用的工程框架。

1. 多机器人仿真为什么难：独立命名空间、TF 树和编队控制

如果你做过单机 ROS 导航，再回头碰多机器人仿真，一定会觉得「这水太深了」——两个机器人放在同一个 Gazebo 世界里，只改一下模型名字远远不够。命名空间隔离、TF 树的 frame 前缀、move_base 的代价地图归属、rviz 里显示哪个机器人，每一层都藏着坑。这个基于 ROS 的多机器人仿真项目（导航 + 编队）正好把这些环节打包成一套可跑的工程：四个功能包分别负责建模、仿真世界、导航与遥控，launch 里一键把两个 ares 机器人放进同一场景，再配合编队控制逻辑做目标点动态计算。对新手来说，它是课程设计、大作业或毕设起步的完整骨架；对做过单机导航的人，它的命名空间拆分方式也值得参考。要复现它，建议先把四个包各自管什么理清楚，再谈参数调优。

2. 拆开 multirobot_formation：四个 ROS 功能包各自管什么

拿到压缩包，先别急着 roslaunch。扫一遍顶层目录，会发现这套工程按「描述 → 仿真世界 → 导航 → 遥控」四个方向拆成了独立功能包，这个拆法本身就是多机器人工程的正确姿势：每个包只干一件事，命名空间互相隔离，后加的机器人只要复制同样的包结构再改前缀。

2.1 ares_description：URDF 模型与坐标系设计

ares_description 中放了urdf、meshes、launch、config四个目录。URDF 文件定义了机器人的连杆、关节、传感器挂载点和坐标系树；meshes 目录里是 STL 或 DAE 网格文件，供可视化与碰撞检测使用；launch 目录里主要是robot_state_publisher相关的启动入口，它会读取 URDF 并发布 TF 变换。

多机器人场景下，URDF 里最需要关注的是坐标系命名。假设每个机器人的 base_link、laser 等 frame 都叫同一个名字，两个机器人一起发布 TF，tf 树必然崩。这个项目的做法是让 launch 传入frame_prefix或 ns 参数，把每个机器人的 TF 树压到不同的命名空间下，例如robot_1/base_link与robot_2/base_link。你在看 URDF 时如果发现 frame 名是硬编码的，记得改造成支持前缀拼接。

2.2 ares_gazebo：仿真世界与机器人注入方式

ares_gazebo 的三块内容非常典型：worlds是 Gazebo 物理场景文件，maps是导航用的 2D 栅格地图（与 gazebo 世界对应），launch负责把模型跑进 Gazebo。值得注意是包里同时给出了sim.world和一张名为cave.png的地图，前者是物理仿真场景，后者是导航 map_server 要加载的图片资源——这意味着物理世界与代价地图之间不是自动对齐的，需要靠 launch 里的坐标转换和映射把两者对上。

从项目结构能看出，这套仿真不是随便拿一张图片当地图，而是先设计物理世界，再用 SLAM 或手工构建出对应的栅格地图。你在改世界时，最常犯的错是只改了 world 而不换 map，结果传感器数据正常，但全局代价地图里的障碍和 Gazebo 里看到的墙壁完全不是一回事。

2.3 ares_navigation：move_base、 map_server 与其他导航组件

ares_navigation 在四个包中配置最密：launch里是导航启动入口，maps是地图数据，config是 move_base、代价地图与局部规划器的参数，rviz是可视化配置，src则是几个 C++ 或 Python 节点，承担主题重映射或导航状态逻辑。

move_base 是整套导航的核心调度器。它接收goal消息，调用全局规划器在代价地图上规划路径，再交给局部规划器跟踪。在多机器人场景下，非常重要的点是：每个机器人必须有独立的 move_base 实例，并且各自的 costmap 要严格限定在独立命名空间内。否则你会发现 robot_1 的全局规划器会把 robot_2 看成障碍物，两个机器人互相堵路。

你可以打开config下的代价地图参数文件确认这几个参数：robot_radius是否调到了与实际模型相符，inflation_radius是否合理，obstacle_range有没有设得像雷达一样长。后面第四章会写具体调参思路。

2.4 ares_teleop：键盘遥控与前期调试

ares_teleop 是调试阶段的好帮手。多机器人导航调试时，经常需要手动把其中一个机器人挪到某个位置，或者验证编队算法时让领航机器人动起来——直接开一个键盘遥控节点，通过cmd_vel话题发送线速度与角速度，比改代码重跑快得多。

这个包里一个简单 Python 脚本就能监听键盘按键，把对应的速度值发布到指定命名空间的cmd_vel。分布式遥控的关键是 topic 重映射：robot_1/cmd_vel和robot_2/cmd_vel必须指向各自的控制器，不能默认全部发到/cmd_vel。如果发现遥控没反应，第一件事查 topic 名是否对应正确，第二件事查cmd_vel是否被 move_base 的局部规划器占用。

提示：遥控是验证机器人正向/反向运动学是否正常的最高效途径。所有导航调试之前，先用 teleop 手动开一圈，确认左右转、前进后退方向都符合直觉。

3. 单机多机器人启动：从 Gazebo 到 rviz 的完整链路

多机器人仿真比单机多出来的，就是「把两份模型塞进同一个 launch 文件，各自带一套命名空间」。启动顺序一般分成三步：先起 Gazebo 世界，再注入两个机器人模型，最后拉起导航与 rviz。如果你用项目里的OnYourMarkGetSetGo.launch这样的综合入口，它会一次完成上述动作。

3.1 综合 launch 的结构：怎么同时拉起两个机器人

一个合理的多机器人 launch 文件，通常是「一个总的入口 + 多个 group」的结构。外层启动 Gazebo 与 map_server，内层通过<group ns="robot_1">和<group ns="robot_2">分别加载机器人描述、spawn 模型、启动导航节点。下面是这类 launch 的骨架，你在.launch里会看到类似写法：

<launch> <!-- 启动 Gazebo 世界 --> <include file="$(find ares_gazebo)/launch/empty_world.launch"> <arg name="world_name" value="$(find ares_gazebo)/worlds/sim.world"/> </include> <!-- 机器人 1：整个组独立命名空间 --> <group ns="robot_1"> <param name="robot_description" command="$(find xacro)/xacro $(find ares_description)/urdf/ares.xacro prefix:=robot_1"/> <node name="spawn_model" pkg="gazebo_ros" type="spawn_model" args="-urdf -model robot_1 -param robot_description -x 0.0 -y 0.0 -z 0.1"/> </group> <!-- 机器人 2：与机器人 1 并排 --> <group ns="robot_2"> <param name="robot_description" command="$(find xacro)/xacro $(find ares_description)/urdf/ares.xacro prefix:=robot_2"/> <node name="spawn_model" pkg="gazebo_ros" type="spawn_model" args="-urdf -model robot_2 -param robot_description -x 2.0 -y 0.0 -z 0.1"/> </group> </launch>

我拆这类 launch 时，一般会先查两个地方：一是xacro的prefix参数有没有真正传入 URDF；二是spawn_model的-model参数是否唯一。上面这段代码中机器人初始位置用-x、-y、-z硬编码，这是最省事的做法，但如果你要做编队实验，建议把初始位姿参数提升为 launch 的 arg，方便在多次实验中调整队形初始间距。

3.2 从 Gazebo 到 rviz：frame_prefix 与 TF 树校验

模型注入成功后，下一步就是把两个机器人的 TF 和传感器数据接到 rviz。常见的错误是在 rviz 里 Fixed Frame 只填map，然后发现只有一台机器人的 TF 树。正确做法通常是让 rviz 以map为全局参考，同时给每个机器人设置 TF 前缀，这样robot_1与robot_2的树互不干扰。

校验命令很简单，先看tf是否正常更新：

rostopic echo -n 1 /robot_1/odom rosrun tf view_frames

view_frames会生成一张 TF 图，检查图中是否出现robot_1/base_link和robot_2/base_link这两棵完整的分支。如果只看到其中一个，说明另一个还没发布 TF，回头看它的robot_state_publisher是否启动。如果两棵树的 frame 名都变成base_link而非robot_1/base_link，那就是前缀设置失效，后期导航与编队一定会出问题。

3.3 命名空间与话题映射：一次对一对 topic

启动多机器人，本质上是在维护一套「命名空间 → 话题名」的映射表。以 ares 为例：

写成表格之后，编队逻辑就非常直白了：它是一个「读各位位姿、算各目标点、再分发到对应 goal 话题」的节点。你在调试时如果发现 robot_1 的动作影响了 robot_2，大概率是某个节点没加 ns，直接订阅了全局/cmd_vel或/scan。尤其是编队控制器，很多初学者写的节点只订阅一个/odom和发一个/goal，跑起来两台机器人一起乱动——这就是命名空间没清理干净的最典型现象。

4. 导航配置：让两个机器人各自规划路径而不打架

当两台机器人同时出现在一张代价地图上时，导航就从「避障」升级成「避机器人」。如果不做命名空间隔离，robot_1 的全局规划器会把 robot_2 当成障碍物反复重规划；而做隔离之后，还需要处理另一个麻烦：如何让 robot_1 在编队移动时主动避开 robot_2 的行进方向。这一章的落脚点是 move_base 的独立配置。

4.1 move_base 参数与代价地图拆分

打开config下的代价地图参数，核心参数大多长这样：

global_costmap: robot_radius: 0.25 inflation_radius: 0.6 obstacle_range: 3.0 raytrace_range: 4.0 observation_sources: laser laser: topic: /scan data_type: LaserScan marking: true clearing: true local_costmap: robot_radius: 0.25 inflation_radius: 0.4 obstacle_range: 2.0 raytrace_range: 3.0

这段配置要针对多机器人做两个关键修改。第一，observation_sources里laser的 topic 必须写成robot_n/scan，否则它会去订阅全局/scan，而全局/scan大概率什么都不发，代价地图会变成纯膨胀层，墙壁都看不见。第二，robot_radius要按 ares 的实际尺寸改，如果物理模型直径 0.5 m，你填 0.15，那么局部规划器会规划出一条让机器人擦着墙走的路径，最后机器人卡住或撞上去。

inflation_radius是多机仿真中调整最多的参数之一。单机时设 0.5 没问题，两台机器人编队行进时，如果这个值太大，每个机器人的膨胀层会把旁边队友的路也占掉，导致 leader 能走，follower 的全局规划器认为路径被 leader 堵死。编队模式下我一般把全局膨胀半径压到 0.4 以下，同时让 local costmap 只关心附近障碍。

4.2 map_server：从 sim.world 到 2D 占用栅格

项目里地图资源直接放在maps目录下，nav 启动时会通过map_server提供栅格地图。如果你打开maps下的.yaml文件，会看到类似这样的配置：

image: cave.png resolution: 0.05 origin: [-10.0, -10.0, 0.0] occupied_thresh: 0.65 free_thresh: 0.25

resolution表示每个像素对应 0.05 m，这是 ROS 导航中最常见的地图分辨率。地图的原点origin必须与 Gazebo 世界坐标对齐——如果 world 里障碍物的位置在 (1, 1) 附近，而地图 origin 设为 (0, 0)，那么 map 上的墙壁和 Gazebo 里的墙壁就会相差一段距离，导航路径会凭空避开不存在的东西，或直接穿过真实障碍。这个对齐问题非常隐蔽，因为 rviz 里看起来很和谐，但机器人就是绕路。

注意：两个机器人是否共用一张地图？这里建议直接共用。多机编队导航，机器人在同一张全局地图上做路径规划是正常需求。真正要隔离的是 costmap 话题与 TF 树，不是地图本体。

4.3 目标点下发：rviz 与 topic 匿名发布

单机导航时，习惯在 rviz 里直接指定目标点。多机下 rviz 的「2D Nav Goal」按钮默认发到/move_base_simple/goal，你必须在 rviz 面板里把 topic 改成/robot_1/move_base_simple/goal，才能让机器人 1 响应。如果嫌麻烦，直接用命令行验证：

rostopic pub /robot_1/move_base/goal geometry_msgs/PoseStamped "header: {frame_id: 'map'}" "pose: {position: {x: 2.0, y: 1.0, z: 0.0}, orientation: {w: 1.0}}"

这样发消息的好处是能确认从「发送目标 → move_base 响应 → 底盘转动」的完整链路是否通畅。如果消息发出后 robot_1 没动静，再去查/robot_1/move_base/status的状态值；如果是 1（ACTIVE）但底盘不动，优先检查 cmd_vel 话题是否与 Gazebo 插件绑定。

5. 避坑指南：多机器人仿真的四个高频踩坑现场

多机器人仿真的问题往往不是某一个包坏了，而是多个包之间的「隔离」坏了。这一章直接写我在踩过的坑里总结出的现象、原因和解决路径，每一条都对应实操中真实会遇到的卡点。

5.1 卡顿与崩溃：Gazebo 一跑起来 CPU 就顶满

现象：launch 一键启动后，Gazebo 和 rviz 都开了，但画面逐步卡顿，rosout 里没报错，CPU 占用却常年在 90% 以上。跑编队时机器人一顿一顿，像幻灯片。

原因：多机器人场景下，每个机器人如果都挂载了完整激光雷达模型 + 相机模型，并且每个传感器都在实时渲染，仿真计算量翻倍。很多内置 3D 模型的物理仿真，网格碰撞计算量远高于可视化模型。另外 Gazebo 与 rviz 在同一台机器上运行时，GPU 负载会成为瓶颈。

解决：分两层处理。第一层是仿真层，把激光雷达的update_rate从常用的 10 Hz 降到 5 Hz，把相机改成不发图像或降低分辨率；如果室内导航不需要物理碰撞精度，把meshes里的碰撞网格替换成简化圆柱体。第二层是体验层，rviz 里关闭不需要的 Display（比如去掉全局 costmap 的显示），并把仿真速度从「实时」改成times参数控制，能明显改善。

5.2 TF 树串扰：robot_1 的 base_link 变成了 robot_2 的

现象：rviz 中两个机器人像叠罗汉一样全部出现在地图原点。用tf view_frames生成图，发现只有一棵 TF 树，所有 frame 都是base_link，没有robot_1/前缀。

原因：URDF 模型里 frame 名称是硬编码的。launch 里虽然用group ns="robot_1"隔离了话题，但 TF 树里 frame 名的隔离并不由group自动完成，必须让 xacro 显式拼接前缀。

解决：进入 ares_description 的 xacro 文件，确保所有 link 名都通过$(arg prefix)拼接。比如：

<link name="${prefix}base_link"/> <joint name="${prefix}base_joint"/>

然后 launch 中修改robot_description参数生成命令，把prefix传进去。如果你只是想要纯话题隔离、不关心 rviz 里同时显示两台机器人，可以不拼前缀，但后续编队控制读取 TF 时会非常痛苦。我一般建议早改早省事，编队节点读 TF 时直接按${prefix}base_link查，逻辑清晰且不会串。

5.3 机器人转圈打摆：目标点更新过快导致 move_base 反复重规划

现象：编队控制启动后，follower 机器人不沿直线前进，而是原地转圈或左右摆动。rviz 里能看到全局路径不断重画，move_base 状态在 ACTIVE 和 PLANNING 之间高频跳动。

原因：编队控制器以 10 Hz 的频率持续向move_base/goal发送目标点，而 follower 还没走到上一点，新目标就已经覆盖旧目标。对于 move_base 来说，目标点一旦更新，它就会用当前位姿重新规划路径，形成一个高频重规划循环。目标点的小幅抖动，比如定位噪声引起的 5 cm 波动，也会被反馈成规划路径的抖动。

解决：给编队目标加阈值判断和状态机。首先判断当前机器人是否已经在目标点附近（比如欧氏距离 < 0.2 m），如果还没到，就不下发新目标；其次把编队控制频率降到 1～2 Hz，甚至用事件触发而不是定时循环。最省事的做法是把目标点写在某个固定话题上，由 move_base 在一次完整 Reached 后再接收下一个目标。这个改动对编队稳定性的提升立竿见影。

5.4 机器人导航时穿墙而过

现象：机器人走规划路径时，直接从墙中穿过，或者路径明显切割墙角。rviz 中的代价地图看起来一切正常。

原因：最常见原因是map_server地图的origin没与 Gazebo 世界对齐，导致地图上的障碍和真实世界中的墙壁错开一条街。另一种原因是启动 move_base 时，使用的地图话题没正确映射，导致它的障碍数据压根没加载；还有可能是某个 laser topic 配错，观察源一直为空。

解决：先做「静止实验」——让机器人停在墙前 0.5 m处，查看/move_base/global_costmap/costmap的 cost 值，确认墙是否被标记为 LETHAL。如果没有，就查 observation_sources 里的 topic 是不是robot_n/scan，以及 scan 数据的时间戳是否更新。然后用 rviz 显示 map 与 Gazebo 的叠加图层，看两张图是否坐标重合。如果相差很大，手动微调.yaml里的origin值，直到栅格地图与 Gazebo 模型轮廓对齐。

6. 升级玩法：把静态编队改成动态跟随

项目本身把编队作为多机器人仿真的核心卖点，但初始编队逻辑大多是「让每台机器人移动到固定偏移位置」，这在机器人运动学上是足够的。接下来的升级把编队从「定点占位」变成「跟随移动」，让你能直接观察实时编队保持效果。

6.1 动态目标点计算：让 follower 跟随 leader 的实时位姿

编队控制的核心思路是领航-跟随法里最直接的相对坐标法。假设 leader 是robot_1，follower 是robot_2，设定编队中的期望相对距离 L 与期望相对角度 φ，则 follower 的目标点由 leader 的实时位姿推算：

import rospy import tf import math from geometry_msgs.msg import PoseStamped def compute_follower_goal(leader_pose, offset_x=0.8, offset_y=0.0): goal = PoseStamped() goal.header.frame_id = "map" goal.header.stamp = rospy.Time.now() yaw = tf.transformations.euler_from_quaternion( [leader_pose.orientation.x, leader_pose.orientation.y, leader_pose.orientation.z, leader_pose.orientation.w])[2] goal.pose.position.x = leader_pose.position.x + offset_x * math.cos(yaw) goal.pose.position.y = leader_pose.position.y + offset_x * math.sin(yaw) goal.pose.orientation = leader_pose.orientation return goal

这段代码的距离变量同时传递了 cos 与 sin 两个方向，从而把 leader 的朝向考虑进 follower 的期望位置，保证 leader 转弯时 follower 能跟上转弯，而不是站在原地等待。

两点参数说明：offset_x是期望的纵向编队距离，offset_y是横向偏移，横向偏移为 0 表示串行编队。要让两车变成并排，把offset_y设成 0.8 左右。这段代码里读取 leader 位姿时，TF 监听最好用tf.TransformListener直接监听/robot_1/base_link与/map的变换，比订阅amcl_pose更及时。

6.2 目标点更新策略：阈值与频率

动态跟随最容易翻车的是 leader 在移动时 follower 目标点连续跳变。实际运行时，我建议把 6.1 的compute_follower_goal循环设置在 1 Hz，每次下发前先判断当前 follower 与目标点的距离：

rospy.wait_for_service('/move_base/clear_costmaps') rate = rospy.Rate(1.0) # 1 Hz while not rospy.is_shutdown(): goal = compute_follower_goal(leader_pose, 0.8, 0.0) dx = goal.pose.position.x - follower_pose.position.x dy = goal.pose.position.y - follower_pose.position.y if math.hypot(dx, dy) > 0.25: # 距离阈值，防止重复下发 goal_pub.publish(goal) rate.sleep()

上面这段逻辑解决了两个问题：一是机器人已经到达或接近目标点时不反复重发；二是机器人离目标点距离小于 0.25 m 时，就认为它进入了误差允许范围，不再触发重规划。这样 move_base 的重规划频率自然降下来，编队稳定程度比你高频下发目标点好很多。

6.3 验证编队效果：记录轨迹与误差

仿真最大的好处是可以精确记录位姿，验证「队形保持误差」。具体做法是开启 rosbag 记录两个机器人的 odom 和 move_base 状态，跑一段后回放，用脚本按时间戳对齐两台机器人的路径，再计算期望相对距离与实际相对距离的偏差。

rosbag record -O formation_test \ /robot_1/odom /robot_2/odom \ /robot_1/move_base/status /robot_2/move_base/status

跑完一段轨迹后，回放 bag 并同时播放 tf，然后检查两个机器人的轨迹曲线是否基本平行、间距是否符合设定值。如果领航机器人转弯时 follower 明显内切或外切，说明offset_x设得太长——转弯半径对应跟随半径不够，需要减小编队距离或放慢领航机器人的速度。

从那以后，我每次跑多机器人仿真都会强制走一遍「launch 校验 → TF 树检查 → 手动遥控 → 记录轨迹」的流程，不再跳过任何一个环节。多机器人项目要建立的第一直觉不是「多高贵」，而是「隔离做好没」，这份工程给我最大的启发也在这里。希望帮到你。

本文还有配套的精品资源，点击获取