简介基于机器人操作系统2ROS2与Gazebo仿真器构建的多机器人协同导航与动态编队仿真平台面向机器人系统、多智能体控制方向的研究人员、算法验证工程师及高校师生旨在解决复杂室内外环境下多机自主路径规划、实时避障与队形保持等分布式控制算法验证难题。压缩包共七十个文件大小约一点二兆字节主要包含launch启动配置、URDF/Xacro机器人模型、world仿真场景、yaml参数、C/Python控制源码、rviz可视化配置及说明文档等便于快速搭建和复现仿真工程。资源以multirobot_formation工程组织划分ares_description、ares_navigation、ares_gazebo、ares_teleop等模块分别对应模型描述、导航规划、仿真世界与遥操作控制支持在Gazebo中设置动态障碍物通过ROS2通信机制验证编队与避障策略无需真实硬件即可安全开展实验。目前已有八十五人学习下载适合研究生与工程师作为多机器人协同导航、分布式控制与编队策略研究的基础框架并进行二次开发和扩展。1. 多机器人协同导航仿真真正的坑在坐标系很多人第一次接触多机器人协同导航仿真以为难点在于路径规划算法或编队控制律等真把 ROS2 与 Gazebo 的组合跑起来才发现最难的不是算法本身而是让四个机器人的 tf 树、话题和命名空间在同一个仿真环境里互不打架。这份基于 ROS2 与 Gazebo 的多机器人协同导航与动态编队仿真平台解决的就是这件事。它把多智能体的协同导航、动态避障和队形保持做成了一套完整可跑的仿真项目覆盖室内仓库和室外开放地形支持多台移动机器人在同一 Gazebo 世界同时工作适合做分布式控制算法验证、编队策略对比也适合用实物小车做算法预演前先在仿真里把坑踩完。新人可以从一键拉起的仿真世界里直接开始熟手则可以把它当作一个稳定的实验基准。2. 资源拆解与启动流程文件布局和 launch 一键拉起拿到资源第一件事不是跑而是先看目录。这个平台按常规 ROS2 工程组织核心内容分在几个目录里每个目录承担一个明确的层级职责。我在本地解压后习惯先清理出下面这张表目录/文件角色关键内容worlds/仿真环境层室内仓库世界 SDF、室外开放地形 SDF含光照、地面、障碍物摆放robots/机器人本体层每台机器人的 URDF/XACRO差速驱动插件、激光雷达、IMU 配置config/策略参数层Nav2 参数文件每台机器人独立 costmap 与 planner 参数launch/系统入口层多机器人联合启动 launch 文件负责加载世界与实体behavior/协作逻辑层队形切换与任务调度的状态机脚本这个分层思路不是随便拍的。机器人的“身体”、驾驶策略与协作逻辑分开存放意味着调编队算法时不需要碰 Gazebo 世界换仿真环境时也不需要改机器人模型。实际调试中这种拆分非常省时间尤其当你需要反复对比三角队形和一字队形在同一张地图里的表现时只动 behavior 目录就能完成。2.1 仿真环境依赖与编译准备平台默认建立在 ROS2 humble 之上依赖 navigation2、gazebo_ros_pkgs 和 xacro。如果你从零开始搭环境先装依赖再编译。这里有一个容易踩坑的地方navigation2 和 gazebo_ros_pkgs 的版本必须与当前 ROS2 发行版严格匹配不能直接从源码拉最新版否则编译出来的接口和 launch 文件里的参数名对不上。sudo apt install ros-humble-navigation2 ros-humble-nav2-bringup ros-humble-gazebo-ros-pkgs ros-humble-xacro cd ~/multi_robot_ws colcon build --symlink-install source install/setup.bash这里有个小习惯我一般用--symlink-install而不是默认编译方式。区别在于改 Python 脚本后不需要重新colcon build直接生效。调状态机脚本时你会感谢这个参数的同一个文件一天改几十次很常见。gazebo_ros_pkgs 提供spawn_entity.py等实体生成工具navigation2 提供全局规划与代价地图服务xacro 负责把 URDF 的重复结构展开成实际机器人模型。2.2 多机器人 launch 的设计核心一键启动的主入口在 launch 目录下的multi_robot_launch.py它的任务是把 Gazebo 世界、机器人模型和导航栈一次性拉起来。这个文件表面上看只是循环 spawn 多个实体但真正的关键在两个地方独立的话题命名空间和独立坐标系前缀。# multi_robot_launch.py结构示意 from launch import LaunchDescription from launch_ros.actions import Node ROBOTS [robot_1, robot_2, robot_3, robot_4] def generate_launch_description(): spawn_nodes [] for i, robot in enumerate(ROBOTS): spawn_nodes.append(Node( packagegazebo_ros, executablespawn_entity.py, arguments[ -topic, f/{robot}/robot_description, -entity, robot, -x, str(1.0 i * 0.8), -y, str(0.5), -z, str(0.05) ], outputscreen )) return LaunchDescription(spawn_nodes)注意arguments里的-topic参数每台机器人的 URDF 通过独立的 robot_description 话题加载实体名也不重复。你单独用ros2 topic list看会发现话题数量是单机的好几倍/robot_1/cmd_vel、/robot_2/scan、/robot_3/odom各自独立。如果 launch 里不处理命名空间四个节点拿到的是同一个/cmd_vel你给一台车发指令所有车都动。另一个容易忽略的是 tf 前缀。gazebo 的差速驱动插件默认发布的坐标系不带前缀多机器人必须设置tf_prefix否则 robot_1 的 base_link 会覆盖 robot_2 的 base_link。这两个问题不做干净后续所有算法都白跑。2.3 启动后强制做两件事launch 能拉起来只是第一步验证系统有没有真正隔离好才是关键。我每次跑通后固定做两个检查ros2 run tf2_ros tf2_echo robot_1/map robot_1/base_link ros2 run tf2_tools view_framestf2_echo验证单台机器人坐标变换是否稳定输出view_frames生成一张 tf 树图。正确的情况应该是每个机器人独立拥有map - odom - base_link分支四棵互不交叉。如果看到某些坐标系串到别的机器人下面基本可以断定是 tf_prefix 没设置或者设置了但被后续节点覆盖。这里还有一个实用技巧如果资源里的 launch 文件写死了四个机器人你想加第五台不要直接复制整个节点块。正确做法是抽出循环变量把机器人名列表改成可配置的 YAML 文件方便以后扩展。多机器人项目最终都要走向配置驱动写死在 launch 里只是 demo 阶段的做法。3. 动态编队控制从虚拟台车到 leader-follower编队控制是这个平台的核心价值点。资源里默认的队形保持并不复杂它选的是工程上最稳妥的 leader-follower 方案而不是花哨的图论一致性算法。为什么这么选理由很现实调参路径短物理含义清楚。3.1 两种编队方案的取舍编队控制主流做法分成两类。一类是 leader-follower 领航跟随法一个领航者带路其余跟随者维持相对距离和角度另一类是基于图论的一致性算法靠拉普拉斯矩阵让所有机器人在没有明确领队的情况下收敛到同一速度。这个资源选 leader-follower 的原因从调试角度来看非常合理领航者的行为就是普通单机导航跟随者的控制目标可以在 rviz2 里直观标注出来kp、kd 改了之后影响立刻可见。一致性算法的参数是矩阵系数一个拓扑变化就要重新推导很难在仿真平台里做快速实验。这套仿真平台把编队控制与 Nav2 导航做成了两层配合。巡航模式下领航者执行 Nav2 全局导航跟随者订阅领航者位姿以虚拟目标点方式跟在后面遇到窄通道时切换到单机导航模式通过后再恢复编队。这个机制让避障和编队解耦避免让编队控制器同时承担路径规划和避障两个任务。3.2 编队参数与坐标系约定进入代码之前先明确坐标系约定。领航者位姿取自/robot_1/odom跟随者通过 tf 变换到领航者的 odom 坐标系下计算相对位置。编队参数用(d, phi)描述d 是跟随者与领航者的期望距离phi 是期望相对角度。三角队形的计算方式如下队形robot_1领航者robot_2robot_3robot_4三角自由导航d1.2, phi2π/3d1.2, phi4π/3d1.2, phiπ一字自由导航d1.0, phi0d2.0, phi0d3.0, phi0菱形自由导航d1.0, phiπd1.0, phiπ/2d1.0, phi3π/2施工时有个容易搞反的地方phi 是相对于领航者航向的角度不是相对于地图坐标系的绝对角度。如果直接写死地图角度领航者一转向整个队形会瞬间撕裂。3.3 跟随者控制核心实现以下代码实现跟随者的期望位姿计算和速度输出。它把“跟住领航者”的任务转换成对一个虚拟目标点的跟踪这是工程里最可靠的做法好处是跟随者的行为可以被 rviz2 里的箭头直观验证import math def compute_follower_target(leader_pose, offset): leader_pose: (x, y, theta) 领航者位姿 offset: (d, phi) 编队相对距离和相对角度 返回 follower 的期望位置 (tx, ty) x, y, theta leader_pose d, phi offset tx x - d * math.cos(theta phi) ty y - d * math.sin(theta phi) return tx, ty def follower_control(target, state, kp0.6, kd0.1, v_max0.5): target: (tx, ty) 虚拟目标点坐标 state: (x, y, yaw) 当前位姿 返回 (linear_vel, angular_vel) dx target[0] - state[0] dy target[1] - state[1] dist math.hypot(dx, dy) desired_yaw math.atan2(dy, dx) yaw_err math.atan2(math.sin(desired_yaw - state[2]), math.cos(desired_yaw - state[2])) linear min(kp * dist, v_max) angular kd * yaw_err return linear, angular逻辑说明compute_follower_target根据领航者位姿和编队参数计算出跟随者应该在的位置follower_control用一阶比例控制器把这个位置差变成实际速度指令。角度误差归一化是重点直接用desired_yaw - state[2]在角度从 170 度到 -170 度时会产生 340 度的错误误差用atan2(sin(err), cos(err))保证误差始终落在 -π 到 π 区间。调参的话follower 在目标点附近来回摆动优先减小 kp 而不是加 kd。kp 从 0.4 到 1.0 之间试。加 kd 只能抑制高频抖动如果振荡周期很长多半是 kp 过高或者控制周期与位姿话题频率不匹配。3.4 编队巡航的实际参数范围拿这台仿真平台来说控制周期一般设置在 20~50ms 之间。位姿话题发布频率默认 10~20Hz换算下来每个控制周期能拿到 2~3 个位姿样本够用。如果你把位姿话题频率调到 50Hz必须同步降低 kp否则控制带宽提升后系统会出现奇异振颤表现就是题目里说的“跟在后面像蛇一样走”。速度上限也值得单独说。编队巡航的最高速度通常设定为 0.5m/s 左右低于单机导航的 0.8m/s。原因有两个队形切换时跟随者要在更短距离内修正偏差速度太快必然超调另外 Gazebo 的动态障碍物仿真如果速度高了激光雷达帧率跟不上代价地图会出现断层Nav2 会误判前方障碍物。4. 避障与队形切换Nav2 参数和任务调度的配合动态避障是 Nav2 的主场但多机器人场景里不能直接套单机参数。单机避障只需要对静态地图和传感器障碍物做反应多机器人还要处理队友之间的相互干扰。4.1 Nav2 在编队任务中的角色边界明确的职责划分是Nav2 负责全局路径规划和局部障碍物规避编队控制器负责队形保持。这不是两个模块谁替代谁的问题而是两个阶段的问题。巡航状态下领航者跑 Nav2跟随者不跑全局规划只跟踪虚拟目标点遇到障碍物时领航者触发避障跟随者同步收到队形被打断的信号此时如果跟随者的局部代价地图把领航者当成普通障碍物就会出现“队友把队友挡住”的死锁。所以资源里的 Nav2 参数不是一套而是两套。巡航模式下用宽松的代价地图配置避障模式下用收紧的配置。切换通过动态参数服务实现launch 阶段就加载nav_params.yaml任务调度脚本会在状态切换时调用参数更新。4.2 costmap 参数与动态障碍物感知Nav2 本身不区分动态和静态障碍物它靠代价地图的更新频率来感知变化。local costmap 的update_frequency决定了传感器数据多长时间刷一次。典型参数配置如下local_costmap: local_costmap: ros__parameters: update_frequency: 5.0 publish_frequency: 2.0 obstacle_layer: observation_sources: laser_scan_sensor laser_scan_sensor: topic: /robot_1/scan max_obstacle_height: 0.2 inflation_layer: inflation_radius: 0.4 cost_scaling_factor: 3.0参数里值得留意的其实是inflation_radius和cost_scaling_factor的组合。动态障碍物运动速度快时cost_scaling_factor太大意味着障碍物边缘的代价值迅速衰减机器人可能冲得太近才反应调小到 2.0 会让避障行为更保守但也更容易在窄通道里被自己设置的膨胀层堵住。多机器人场景我的经验是先从 0.4m 膨胀半径开局等队形巡航验证通过再逐步收紧。4.3 局部规划器选型DWB 还是 MPPINav2 的局部规划器在资源和版本里主要有两种选型。DWBDynamic Window Approach是经典方案参数直观对差速底盘适配好四个机器人同时跑时 CPU 开销小MPPI 这两年比较流行它把控制序列采样和代价评估结合起来在密集动态障碍物下表现更平滑但计算量大四台机器人跑 MPPI 时 real time factor 很容易掉。这个平台的仿真场景同时包含室内仓库和室外开放地形如果做四机同时编队我会优先用 DWB。MPPI 更适合单机在拥挤商场环境里的示范不太适合多机编队这种需要频繁切换模式的场景。4.4 队形切换状态机与缓冲策略队形切换不是发一条指令就完事。拿三角队形切一字队形来说后排跟随者的目标点可能会跨越领航者当前位置不加处理必然有一台机器人穿过领航者的路径。资源里的做法是先给目标队形整体放大 1.2 倍所有跟随者先向放大后的虚拟目标点移动等全部进入新队形的邻域后再按步长收敛到精确队形。这个过渡缓冲在代码里对应一个明确的状态class FormationStateMachine: def __init__(self): self.state SINGLE_EXPLORE self.current_formation triangle def update(self, cmd, obstacle_detected, leader_lost): if obstacle_detected and self.state FORMATION_CRUISE: return (EMERGENCY_EVADE, break_formation) if leader_lost: return (EMERGENCY_EVADE, call_replan) if cmd.formation self.current_formation: return (self.state, None) return (FORMATION_SWITCH, cmd.formation)状态机优先级很明确紧急情况 队形切换请求。如果机器人正处在编队巡航而且局部代价地图检测到前方 0.5 米内有障碍物直接进入 EMERGENCY_EVADE这时候所谓的队形必须被打破。等到危险解除再由调度器发送恢复编队指令。不设这个优先级机器人在换队形时遇到障碍物会一边避障一边试图保持队形两头都做不好。4.5 八叉树地图的选配价值如果资源版本里带八叉树地图支持可以把全局代价地图的障碍物来源从二维栅格换成 octomap_server 发布的 occupancy 网格。这样室内有货架、悬空障碍物的场景里全局规划不会生成穿货架底部的路径。缺点是全局地图更新频率低动态障碍物感知还是会依赖 local costmap。我通常只在局部代价地图里维持动态感知全局只做静态 octomap。5. 避坑排查五个翻车现场与解决记录多机器人仿真里那些“玄学问题”九成以上集中在坐标系、物理引擎和通讯三个角落。下面五条是我在这个平台上反复踩过的坑每一条都按现象到原因到解决完整记录一下。5.1 TF 树串线四台机器人在 rviz2 里瞬移现象rviz2 里某台机器人突然瞬移到另一个位置或者 robot_1 的激光扫描点显示在 robot_2 的雷达坐标系下。更玄的是有时候界面一切正常但只要一动地图所有机器人跟着地图一起跳。原因多机器人启动时没有做命名空间隔离所有机器人共用一组map、odom、base_link坐标框架。后加载的节点会把先加载的 tf 发布覆盖掉。Gazebo 场景下特别容易发生因为差速驱动插件发布的坐标系默认不带前缀两个插件发布同名 frame 时后注册的覆盖前面的。解决launch 里给每个机器人设置namespace和tf_prefix让坐标系变成robot_1/map、robot_1/odom、robot_1/base_link四棵独立树。修复后用ros2 run tf2_tools view_frames确认图里是四个分支而不是一团乱麻。这个操作应该是任何多机器人项目的起手式而不是出问题后再补。5.2 Gazebo 性能断崖real time factor 掉到 0.5现象Gazebo 界面左上角显示仿真时间明显慢于真实时间机器人行动像慢动作rviz2 里的路径跟踪曲线有撕裂。原因world 文件里 physics 参数默认real_time_update_rate为 1000Hz四台差速机器人的激光雷达插件叠加后 CPU 计算量爆炸。尤其是激光测距仿真每条射线都要做碰撞检测射线数乘机器人数量几十条上百条射线同时更新再好的 CPU 也扛不住。解决把 world 文件里real_time_update_rate降到 500Hzmax_step_size调到 0.002 秒。无关紧要的传感器噪声全部关闭Gazebo 的接触检测也尽量用简化凸包模型替代复杂网格。如果还卡就在启动时加--headless不渲染 GUI纯跑逻辑计算速度能翻倍。gazebo --verbose --headless worlds/outdoor_grid_map.sdf这条命令在调试导航栈时很有用。画面不重要数据流才是关键headless 模式下 CPU 全部用在物理和传感器上编队实验跑得更快。5.3 编队不收敛follower 走蛇形路线现象跟随者不是平滑逼近目标点而是左右长周期摆动像蛇一样扭着前进。领航者直行时还能勉强跟上一转弯整个队形松散。原因最常见的是控制增益 kp 过高控制周期又和位姿话题发布频率不匹配等效系统阻尼不足。另一个隐蔽原因是角度误差没有归一化或者desired_yaw直接用atan2算出来误差跨越 ±π 边界时控制器输入突变机器人猛打方向。解决先看位姿话题odom的实际发布频率ros2 topic hz /robot_2/odom确认频率。把 kp 降到 0.5 以下角度误差强制归一化加 kd 阻尼抑制高频摆动。如果还有低频摆动给目标点加一个 look-ahead 距离让跟随者朝目标点前方 0.2 米处运动不要精确指向目标点。蛇形路线的锅大部分是增益问题算法本身逻辑没错时不要轻易重写。5.4 DDS 跨机通讯看不到对方话题现象用两台物理机跑同样的程序各自的ros2 topic list正常但看不到对方的话题ros2 node list 里也互不可见。原因ROS2 的通信基于 DDS域 IDROS_DOMAIN_ID不一致、网络接口不在同一网段、或者多播被防火墙屏蔽都会导致节点发现机制失效。Gazebo 仿真里不会暴露这个问题但如果你后面要接实物小车或者分布式部署这是必遇的坎。解决先统一域 ID两台机器执行echo $ROS_DOMAIN_ID对比再固定 RMW 实现两端都设置export RMW_IMPLEMENTATIONrmw_fastrtps_cpp省去不同厂商 DDS 实现之间互通的变量最后用ros2 doctor诊断网络配置。ros2 doctor ros2 daemon stop ros2 daemon start这类问题用ros2 doctor能定位七八成。如果显示 discovery 正常但话题不通再查防火墙。DDS 是黑匣子遇到通信问题要一步一步排查先确认基础设施再怀疑代码。5.5 队形切换时互相顶撞现象三角队形切一字时后排机器人局部代价地图检测到“前方障碍物”绕过目标点绕了一个大圈到头来发现那个障碍物是自己队友。原因Nav2 把队友当成普通障碍物obstacle_layer会把队友的位置标记为致命代价。队友是运动的costmap 刷新频率跟不上就会在队友原位置留下一个短暂的“幽灵障碍物”区域触发不必要的避障。解决给每个机器人单独建一个social_layer专门维护队友位置而不是把队友混进通用obstacle_layer。编队巡航时禁用 obstacle_layer 对队友足迹的惩罚切换回避障模式时恢复。如果不想加 layer退而求其次的做法是降低队形切换速度给 costmap 足够刷新时间但治标不治本。6. 仿真到实物三件验证技巧6.1 先给里程计注入噪声仿真里程计太干净直接用它标定出的控制参数上实物必然翻车。我每次都会在机器人 URDF 的差速驱动插件里加上噪声协方差linear 约 0.05m/stepangular 约 0.01rad/step重新跑一遍编队测试。有噪声能收敛的队形实物上才有概率收敛仿真里噪声一加就散的参数实物基本没戏。6.2 用 ros2 bag 抓出异常现场编队过程中的瞬时穿越、异常抖动靠肉眼在 rviz2 里追很难定位。把话题全部录下来异常发生后回放逐帧分析ros2 bag record -a -o ~/bags/formation_test ros2 bag play ~/bags/formation_test --loop回放时我会在 rviz2 里同时打开 robot_1 到 robot_4 的 tf 和 scan定位是哪一台先偏离了队形然后对比当时的cmd_vel和odom时间戳基本能确认是控制参数问题、通信延迟问题还是 tf 更新问题。这个习惯帮我省了大量重复跑仿真的时间。6.3 参数迁移前先对齐坐标系仿真和实物最大的差异不是算法是坐标系标注。真实小车的base_link原点在底盘中心差速轮距、雷达安装位置都以毫米计仿真资源里直接用尺寸相近的参数差 20cm 很正常。参数迁移到实物前我习惯先量一遍轴距、轮径、雷达离地高度再改 URDF 里的物理属性和inflation_radius。从那以后每次拿到一个新的多机器人仿真资源我都会执行一遍固定流程先view_frames看坐标系隔离再录一段 bag 数据最后加噪声跑一次极限避障。这套流程帮我少翻了很多次车希望帮到你。本文还有配套的精品资源点击获取