简介一套基于ROS2与Gazebo的多机器人协同导航与动态编队仿真平台面向机器人研究人员与工程师用于在室内外复杂环境中验证自主路径规划、避障、队形保持及分布式控制算法。压缩包共70个文件、约1.2MB内含18个launch启动文件、7个world场景文件、5个xacro模型、7个yaml参数、5个cpp源码、3个rviz配置等覆盖从场景构建、模型加载、导航参数设定到算法运行与可视化的完整流程。平台集成ares_description、ares_navigation、ares_gazebo等模块支持自定义控制算法与编队策略可灵活调节动态障碍环境并实时观察队形变化帮助研究者快速迭代验证尤其适合动态障碍物环境下的编队切换与避障协同研究。目前已有85人学习下载既适合开展分布式机器人系统控制算法与编队策略的验证也可作为ROS2与Gazebo联合仿真的进阶学习样例。1. 基于 ROS2 与 Gazebo 的多机器人协同导航与动态编队仿真平台这套项目到底在解决什么问题拿到一个叫“基于ROS2与Gazebo的多机器人协同导航与动态编队仿真平台”的压缩包先别急着解压跑 demo。这类平台本质上是把三件事揉在一起ROS2 做通信和算法组织Gazebo 提供复杂室内外环境和传感器仿真多台机器人则负责演示“自主路径规划 避障 队形保持”这一整条链路。它面向的不是某一个机器人而是一组机器人同时运行时的协同问题——谁规划路径、谁避障、队形怎么不散、动态障碍物来了怎么临时变形。适合的人群也很明确做多机器人或分布式系统方向的学生、研究控制算法需要快速验证的工程师以及想把仿真结果迁移到真实小车上的硬件玩家。搞清楚它的架构和常见坑比跑通 demo 更重要。2. 为什么这套平台锁定 ROS2 和 Gazebo仿真器与通信栈的选型逻辑2.1 ROS2 的 DDS 通信和命名空间多机器人“共用一套代码”的前提多机器人仿真最怕的不是机器人多而是话题和坐标系统一冲突。ROS1 时代靠 master 集中管理一旦一台机器人的节点异常退出整个系统都可能被拖垮。ROS2 改用 DDS 作为底层通信节点之间通过域domain和话题发现机制直连没有单点依赖天然适合分布式机器人系统。对一个仿真平台来说这意味着你可以同时拉起十台机器人每台机器人各自跑导航和编队程序互不干扰。ROS2 的命名空间机制是支撑多机器人的关键。假设你写了一个差速小车的机器人描述和导航配置想让三台车同时跑最省事的做法是给每台车分配一个命名空间/robot1、/robot2、/robot3再通过话题重映射把cmd_vel、odom、scan这些话题变成/robot1/cmd_vel、/robot1/odom。这里有个容易被忽略的细节话题可以重映射tf 树里的坐标系也必须加前缀。常见做法是把 robot_state_publisher 的frame_prefix参数设成robot1/否则三台车会同时往同一个/tf话题上写数据rviz2 里根本分不清谁是谁。实际开发时我还习惯把 ROS2 的 QoS 策略一并纳入设计。实时性高的传感器数据如激光雷达点云用SensorDataQoS控制指令cmd_vel用SystemDefaultQoS或BestEffort而地图这类需要保证完整性的数据则必须用Reliable。多机器人场景里最典型的翻车现场就是某个节点默认是 volatile 的 best-effort而另一个节点用 reliable 订阅两边虽然能发现话题但数据始终不刷新。这些参数在单机仿真里不敏感一旦多机器人同时跑问题会被迅速放大。还需要提一句当前主流的运行环境。Ubuntu 22.04 对应 ROS2 Humble这是目前多机器人仿真项目最常用的组合ROS2 Humble 配 Gazebo Classic 11功能最全。如果你想把仿真环境做成可复用的 Docker 容器我一般会把 ros2 humble 和 gazebo 装在同一镜像里然后用 gzserver 的无界面模式跑这样既方便 CI 自动化跑批也避免桌面渲染占用资源。2.2 Gazebo 与其他机器人仿真平台对比物理、传感器、动态障碍物哪个更顺选择 Gazebo 而不是 Webots、CoppeliaSim不是因为 Gazebo 更“高级”而是因为它和 ROS2 的集成最直接。Gazebo Classic 通过 gazebo_ros_pkgs 提供 ROS2 接口激光雷达、IMU、相机、轮式差速驱动都有现成插件。你在 URDF 里给底盘加上gazebo标签指定插件Gazebo 启动后会自动发布odom、scan等话题nav2 导航栈直接订阅就能用几乎不需要写中间转换层。物理引擎方面Gazebo 默认 ODE支持切换 Bullet 和 DART。做编队控制和多机器人协同ODE 够用但要留意它默认的摩擦力和接触参数在坡道、楼梯场景下的表现。复杂室内外环境里如果机器人频繁打滑或爬坡抖动我会优先检查轮子与地面的摩擦系数而不是改控制器。室内外混合环境的建模也比 Webots 方便房屋墙体直接用 building 模型或静态 SDF 模型室外地形用 heightmap动态障碍物用 actor 走过场或者用脚本控制模型位置。对比之下CoppeliaSim 的脚本和 API 很灵活但免费版在传感器仿真密度上受限Webots 上手快适合单机器人教学但多机器人大规模场景的分布式节点部署不如 Gazebo 自然。做这套多机器人协同导航与动态编队仿真平台核心诉求是“多机同时仿真 障碍物动态变化 与导航算法直接对接”目前 Gazebo 是投入产出比最高的选择。2.3 一套典型平台的目录结构与节点拓扑从 world 到 control 的链路这类压缩包里的项目目录通常有相对固定的套路我自己组织代码时也沿用类似的划分方式。一般会有四个部分worlds存放 Gazebo 世界文件models或urdf存放机器人模型nav存放 navigation2 参数和地图src下是编队控制和节点启动逻辑。压缩包如果打包完整还应该带一个launch目录统一拉起整个仿真。节点拓扑角度一套最小可运行的多机器人协同仿真至少包含这么几层Gazebo 层gzserver 加载世界文件spawn 多个机器人模型发布传感器和里程计数据。机器人模型层每个机器人的 robot_state_publisher 发布 tfjoint_state_publisher 配合控制器插件发布关节状态。导航层每台机器人一套 navigation2 节点完成全局规划、局部规划、costmap 更新。编队层一个或多个编队控制器节点订阅各机器人位姿计算出队形目标点后下发cmd_vel给对应机器人。人机交互层rviz2 做可视化必要时加 rqt_graph 看节点连接状态。这套链路里最容易出问题的连接点是 Gazebo 插件向 nav2 提供的数据格式。比如激光雷达插件默认发布的可能是sensor_msgs/LaserScan而局部 costmap 期望看到的是有frame_id的 scan如果 sensor frame 写错costmap 会把所有障碍物当成在机器人坐标系原点导航直接失效。这类问题不算硬性 bug而是配置一致性多机器人场景下配置翻倍排查成本也跟着翻倍。3. 搭建多机器人仿真环境URDF 实例化、world 动态障碍与 launch 一键启动3.1 用 Xacro 参数化机器人模型避免多台车模型互相覆盖写多机器人仿真时最忌讳的是把一台机器人的 URDF 照着复制三份然后手动改每一处 link 名字。正确做法是用 Xacro 宏定义机器人底盘把prefix作为参数传入之后让 launch 文件循环调用。这样机器人模型定义只有一份却可以生成robot1_base_link、robot2_base_link等带前缀的独立坐标系。一个典型的差速小车 Xacro 宏可以这样写xacro:macro namediff_drive_robot paramsprefix link name${prefix}_base_footprint/ link name${prefix}_base_link/ link name${prefix}_laser_link/ joint name${prefix}_base_footprint_joint typefixed parent link${prefix}_base_footprint/ child link${prefix}_base_link/ origin xyz0 0 0.05/ /joint joint name${prefix}_laser_joint typefixed parent link${prefix}_base_link/ child link${prefix}_laser_link/ origin xyz0.15 0 0.1/ /joint gazebo reference${prefix}_base_link materialGazebo/White/material plugin filenamelibgazebo_ros_diff_drive.so name${prefix}_diff_drive ros namespace/${prefix}/namespace remappingodom:odometry/remapping /ros left_joint${prefix}_left_wheel_joint/left_joint right_joint${prefix}_right_wheel_joint/right_joint wheel_separation0.35/wheel_separation wheel_radius0.10/wheel_radius max_wheel_torque20/max_wheel_torque command_topiccmd_vel/command_topic /plugin /gazebo gazebo reference${prefix}_laser_link sensor name${prefix}_laser typegpu_ray pose0 0 0 0 0 0/pose ray scanhorizontalsamples360/samplesresolution1/resolution/horizontal/scan rangemin0.12/minmax10.0/max/range /ray plugin filenamelibgazebo_ros_ray_sensor.so name${prefix}_laser_scan ros namespace/${prefix}/namespace remappingscan:scan/remapping /ros output_typesensor_msgs/LaserScan/output_type /plugin /sensor /gazebo /xacro:macro这里的逻辑很直接宏定义了底盘、激光雷达和两个固定关节同时在gazebo标签里挂上差速驱动和激光雷达插件。关键参数是namespace它把插件发布的话题限定在各自命名空间下command_topic指定差速插件订阅cmd_vel之后编队控制器通过/robot1/cmd_vel就能控制对应底盘。wheel_separation和wheel_radius必须和实际模型尺寸一致否则 Gazebo 里的 odom 会和真实位移产生偏差导致后续导航和编队误差都被放大。3.2 在 Gazebo 里布置室内外环境和动态障碍物world 文件与 actor 脚本多机器人协同导航要验证“复杂室内外环境”所以 world 文件不能只是一块平地。我会把地图划分成三个区域一个室内房间区墙体用静态模型或 SDF 地标表示一个开阔室外区用 heightmap 做不平整地形中间留一个连接走廊布置动态障碍物。这样每台机器人可以在不同区域测试不同策略。world 文件中动态障碍物常用 Gazebo actor 实现。actor 的典型配置是这样actor namemoving_pedestrian pose5.0 2.0 0 0 0 0/pose skin filenamemodel://pedestrian/mesh.dae/filename /skin animation namewalk filenamemodel://pedestrian/walk.dae/filename /animation script loop_animationtrue/loop_animation trajectory id0 waypoint time0/time pose5.0 2.0 0 0 0 -1.57/pose /waypoint waypoint time5/time pose8.0 2.0 0 0 0 1.57/pose /waypoint waypoint time10/time pose5.0 2.0 0 0 0 -1.57/pose /waypoint /trajectory /script /actoractor 在 Gazebo 里是一条预设轨迹的动画实体会自己往前走也能被激光雷达扫到正好用来模拟动态行人。它的骨架是skin里的网格和animation里的动画文件轨迹点用waypoint定义。仿真平台里如果自带行人模型最好没有的话用简单 mesh 替代也完全可以。值得注意的是actor 不会参与物理碰撞计算如果编队算法需要把它当作真实碰撞体来测试还得额外加一个碰撞模型或在 costmap 中把它标记为静态障碍。3.3 用 Python launch 循环拉起多个机器人命名空间、spawn 与参数传递模型定义好了接下来是把多台机器人送进 Gazebo 并启动各自的话题。我习惯用 Python launch 文件循环生成节点而不是手动重复写几十行。一个能扩展的 launch 骨架如下import os from launch import LaunchDescription from launch.actions import DeclareLaunchArgument from launch.substitutions import LaunchConfiguration from launch_ros.actions import Node def generate_launch_description(): robot_num LaunchConfiguration(robot_num, default3) use_sim_time LaunchConfiguration(use_sim_time, defaulttrue) nodes [] for i in range(1, int(robot_num.perform(None)) 1): ns f/robot{i} robot_xacro os.path.join( get_package_share_directory(multi_robot_sim), urdf, diff_drive_robot.xacro ) robot_state_publisher Node( packagerobot_state_publisher, namespacens, executablerobot_state_publisher, parameters[{ robot_description: Command([ xacro , robot_xacro, prefix:, ns.lstrip(/) ]), frame_prefix: ns /, use_sim_time: use_sim_time, }], remappings[ (/tf, ns /tf), (/tf_static, ns /tf_static) ] ) spawn_entity Node( packagegazebo_ros, executablespawn_entity.py, arguments[ -entity, frobot{i}, -topic, ns /robot_description, -x, str(-1.0 i * 1.5), -y, 0.0, -z, 0.1 ] ) nodes.append(robot_state_publisher) nodes.append(spawn_entity) return LaunchDescription(nodes)这段代码的关键点有三个命名空间、frame_prefix、tf 重映射。namespacens让节点的话题变成/robot1/...frame_prefix给 tf 坐标系加前缀remappings把默认的全局/tf和/tf_static重映射到各自命名空间下避免多台机器人争抢同一个 tf 话题。实际运行时还可以给 robot_state_publisher 加上use_sim_time参数确保它使用 Gazebo 发布的时间避免把系统时间混进来。启动之后用ros2 node list和ros2 topic list检查应该能看到带robot1_前缀的节点和话题。4. 多机器人自主导航的实现ROS2 Navigation2 的多机器人配置与动态避障避坑4.1 Nav2 多机器人迁移要点frame、topic 重映射和 costmap 的命名空间隔离Navigation2以下简称 Nav2是 ROS2 下最常用的导航栈功能覆盖全局规划、局部规划、costmap 和 lifecycle 管理。单机器人跑 Nav2 很容易但多机器人同时跑时前文提过的命名空间问题会再次出现。每一台机器人的 navigation2 节点都必须被限定在各自的命名空间里运行并且它订阅的/scan、发布的/cmd_vel都要是对应机器人自己的版本。一个常见的做法是给每个机器人单独启动一组 nav2 节点而不是共享一份配置。在 launch 文件里需要把 nav2 默认的 remapping 指到对应的 namespace。例如把cmd_vel重映射为robot1/cmd_vel、scan重映射为robot1/scan、odom重映射为robot1/odom。如果一台机器人用了frame_prefixtf 树中的坐标系也带了前缀那么 Nav2 参数里的global_frame和robot_base_frame仍然可以写成map和base_link前提是 tf 查询能够命中带前缀的坐标。这个细节不同项目写法不一样最稳妥的办法是启动后用ros2 run tf2_ros tf2_echo查看坐标帧是否存在。Nav2 的 costmap 是另一个关键隔离点。全局 costmap 和局部 costmap 的 frame 以及传感器 topic 必须指向本机。如果三台机器人共用同一个/scan那么机器人 B 会把机器人 A 的位置当成障碍物规划器会陷入“我方机器人也是障碍”的死循环。常见的配置片段如下global_costmap: global_frame: map robot_base_frame: base_link update_frequency: 2.0 publish_frequency: 1.0 plugins: - {name: static_layer, type: nav2_costmap_2d::StaticLayer} - {name: obstacle_layer, type: nav2_costmap_2d::ObstacleLayer} - {name: inflation_layer, type: nav2_costmap_2d::InflationLayer} obstacle_layer: enabled: true observation_sources: scan scan: topic: /robot1/scan sensor_frame: robot1/laser_link data_type: LaserScan marking: true clearing: true这段配置说明obstacle layer 从/robot1/scan读取数据并把障碍物标到map系中。关键参数是sensor_frame它必须和 Gazebo 里激光雷达的坐标系一致。如果写成laser_link而实际 frame 是robot1/laser_linkcostmap 会在错误位置标记障碍导航轨迹会莫名绕远甚至卡死。4.2 全局路径规划与局部避障的组合怎么选SmacPlanner 与 Regulated Pure PursuitNav2 的规划器组合直接影响避障和队形保持的效果。全局规划器常见的是 NavFn 和 SmacPlanner。NavFn 是经典的 A* 类栅格规划速度快但生成的路径比较“硬”转弯不够平滑SmacPlannerHybrid 则考虑机器人运动学模型输出的轨迹更接近差速或阿克曼底盘的实际可执行路径。在多机器人协同场景里我更推荐 SmacPlannerHybrid 做全局规划。原因很简单编队运动中局部避障会让机器人频繁调整航向如果全局路径本身不平滑局部控制器会持续修正导致车体横向抖振队形误差很难收敛。当然SmacPlanner 依赖正确的 footprint必须在参数里把机器人轮廓描述清楚。局部规划器方面DWA 和 Regulated Pure Pursuit 是比较常用的两种。DWA 通过采样速度空间来评估轨迹在静态障碍较多的室内环境效果好但在动态障碍物较多、速度变化剧烈的场景容易来回搜索导致车速抖动。Regulated Pure Pursuit 则更稳定它让机器人跟踪路径前方的一个点加上曲率约束和障碍抑制适合在开阔环境下保持队形。做动态编队时我会用 Regulated Pure Pursuit把max_angular_accel和max_robot_pose_search_dist调得保守些避免局部控制器把编队指令“纠正”得过猛。4.3 动态障碍物下让规划“活起来”obstacle layer 的 source 与参数调整动态避障依赖 costmap 更新的实时性。Gazebo 中的行人、移动小车等动态障碍物每时每刻都会在激光雷达里产生新的一圈点云。如果 costmap 的更新频率太低动态障碍物会被“画”成假静态区机器人会绕行一个已经不存在的位置。我把obstacle_layer的update_frequency调到 5 Hz 以上局部 costmap 的更新频率可以更高。另一个重要参数是clearing。如果 obstacle layer 只marking不clearing障碍物离开雷达视野后旧障碍痕迹会一直留在 costmap 里时间一长整个地图都被“污染”。动态环境里务必保证clearing: true。同时combination_method决定 obstacle layer 与 static layer 的合并方式默认 0 是覆盖1 是叠加建议设成 0保证动态障碍物不会被静态地图的未知区域覆盖掉。多机器人场景还有一个容易被忽略的问题编队中机器人互相靠近时前车的激光雷达会把后车当作障碍。为了避免队形被破坏可以在 costmap 的 obstacle layer 里把友方机器人发布的可通行区域做过滤或者让编队控制器的目标点尽量避开前车的传感器视野。这个其实已经进入运动规划的研究范畴平台本身提供的是可以反复修改和观测的环境具体策略要各自动手调。5. 避坑 / 常见问题 / 排查多机器人协同仿真跑不起来的几个高频坑5.1 现象tf 树互相覆盖机器人各自看到对方的坐标系多机器人同时启动后rviz2 里出现多个 base_link 和时间戳混乱或者/tf话题里同时夹杂着 robot1 和 robot2 的数据这种情况几乎都出在 robot_state_publisher 的 tf 发布没有隔离。单机仿真的 launch 不会配置 tf 重映射所以多机复用时很容易照搬出问题。原因多个 robot_state_publisher 节点发布到同一个/tf话题tf 树里同名坐标系相互覆盖。解决方法是按前文所示给每个机器人设置namespace并把/tf和/tf_static分别重映射到/机器人名/tf。同时要在 rviz2 的 Fixed Frame 里填写形如robot1/odom的坐标系而不是全局odom。排查时用ros2 topic echo /robot1/tf查看数据帧再用ros2 run tf2_ros tf2_echo robot1/odom robot1/base_link验证坐标变换是否连续。5.2 现象Gazebo 窗口黑屏或闪烁虚拟机里仿真像幻灯片Gazebo 在虚拟机里跑时最容易出现画面闪烁、渲染错乱或黑屏。很多人把问题归咎于电脑不行实际上大多数是 OpenGL 渲染驱动和 Gazebo 的默认渲染引擎不兼容。原因虚拟机的 OpenGL 版本过低或 Gazebo 默认调用了 GPU 渲染但驱动不认。解决办法在启动 Gazebo 前设置环境变量LIBGL_ALWAYS_SOFTWARE1强制走软件渲染黑屏和闪烁通常能缓解。如果只需要跑仿真数据而不需要看画面用 gzserver 无界面模式配合 launch 里的spawn_entity完成机器人加载只在需要可视化时再启动 gzclient。无界面模式还能明显降低 CPU 开销跑多机器人编队时建议默认使用。5.3 现象一开 Nav2 机器人原地转圈报 transform timeout启动导航后机器人原地打转终端反复输出TF_OLD_DATA或 transform timeout。这类问题不是控制算法写错而是时间和坐标系的配置不一致。原因Gazebo 使用仿真时间而 Nav2 或 robot_state_publisher 节点没有开启use_sim_time两边的 tf 时间戳对不上。解决所有参与仿真的节点都要在参数里给use_sim_time: truelaunch 里可以用 group 的方式集中设置而不是每个节点手动加。如果只有部分节点开启也会出现间歇性丢 tf。排查顺序是先看/clock话题是否存在再逐个检查节点的参数是否生效。5.4 现象动态障碍物一进感知范围整个编队急停抖振动态障碍物出现后机器人不是平滑避障而是急停、转向、再急加速整个队形像步进电机一样一顿一顿。这在局部规划参数过于激进时特别明显。原因costmap 更新频率不足局部控制器对突然出现的障碍物反应滞后或者Regulated Pure Pursuit的参数把速度限制得过于严格导致每次检测到障碍就触发大角度修正。解决把局部 costmap 的update_frequency调到 5 Hz 以上同时检查激光雷达扫描频率是否够用降低局部规划器的最大线速度和角速度让机器人对动态障碍的反应更平滑。可以先用rviz2的 costmap 显示功能观察障碍物进入 costmap 的延迟如果延迟超过半秒问题就在传感器或 costmap 更新频率上。5.5 现象多台车跑到同一点互相锁死谁也过不去两个机器人迎面相遇时各自把对面当成障碍同时停下然后互相等待陷入死锁。这在没有集中调度的分布式导航中很常见不是 bug而是策略缺陷。原因每台机器人只考虑自己的 costmap不知道对方的意图。解决思路有两种一是编队策略层面错开轨迹给不同机器人分配不同优先级比如接受侧方避让二是在仿真平台里加一个简单的交通规则节点检测机器人之间的最小距离距离过近时主动让低优先级机器人降速。这个坑也说明多机器人协同导航的真正难点不在单车算法而在多车冲突消解这套仿真平台的价值正是为了暴露和验证这类问题。6. 验证与进阶用 ros2 bag 回放数据把仿真结果量化到能写进论文仿真跑通不是终点能证明“机器人编队在动态障碍物环境中保持了队形、完成了避障”才是终点。我习惯在每个实验场景跑完后立刻用 ros2 bag 把全量数据记录下来ros2 bag record -a -o team_run_001回放时再用 ros2 bag play 把odom、scan、tf、cmd_vel重新打回系统配合 rviz2 慢慢看每一帧的变化。光看 rviz2 还不够为了量化队形保持效果我会订阅各机器人位姿自己写一个小脚本计算相邻机器人的间距误差、航向偏差和目标点跟踪误差。把这些误差输出成曲线就能直观评价编队策略在动态障碍物下的收敛程度。做实验记录时给每一组参数起一个可读的文件名并保存当时的导航参数和编队参数这是少走弯路最重要的习惯。进阶方向是把这套仿真平台迁移到真实硬件。常见做法是把编队控制器从仿真环境里解耦出来它只订阅各机器人位姿并下发速度。通过 ROS2 串口桥接节点把cmd_vel话题接到 ESP32 小车底板上陀螺仪和轮式编码器把真实位姿回报回来仿真里验证过的队形权重和速度限制就能直接复用到实物。我总会提醒自己做一件事仿真环境里的传感器噪声是理想化的迁移到实物后第一件事不是调算法而是先把里程计噪声和通信延迟摸清楚。希望这些经验能帮到你少踩几个坑。本文还有配套的精品资源点击获取