简介这是一份面向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_descriptionURDF 模型与坐标系设计ares_description 中放了urdf、meshes、launch、config四个目录。URDF 文件定义了机器人的连杆、关节、传感器挂载点和坐标系树meshes 目录里是 STL 或 DAE 网格文件供可视化与碰撞检测使用launch 目录里主要是robot_state_publisher相关的启动入口它会读取 URDF 并发布 TF 变换。目录/文件作用关键点urdf机器人本体、传感器、底盘描述每个 joint 的 origin 直接决定 TF 树是否正确meshes机器人外观网格与碰撞网格碰撞网格通常比可视化网格简化launch状态发布与模型加载入口支持spawn_model参数与 frame 前缀config关节限位、传感器参数与仿真控制器绑定多机器人场景下URDF 里最需要关注的是坐标系命名。假设每个机器人的 base_link、laser 等 frame 都叫同一个名字两个机器人一起发布 TFtf 树必然崩。这个项目的做法是让 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_navigationmove_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 nsrobot_1和group nsrobot_2分别加载机器人描述、spawn 模型、启动导航节点。下面是这类 launch 的骨架你在.launch里会看到类似写法launch !-- 启动 Gazebo 世界 -- include file$(find ares_gazebo)/launch/empty_world.launch arg nameworld_name value$(find ares_gazebo)/worlds/sim.world/ /include !-- 机器人 1整个组独立命名空间 -- group nsrobot_1 param namerobot_description command$(find xacro)/xacro $(find ares_description)/urdf/ares.xacro prefix:robot_1/ node namespawn_model pkggazebo_ros typespawn_model args-urdf -model robot_1 -param robot_description -x 0.0 -y 0.0 -z 0.1/ /group !-- 机器人 2与机器人 1 并排 -- group nsrobot_2 param namerobot_description command$(find xacro)/xacro $(find ares_description)/urdf/ares.xacro prefix:robot_2/ node namespawn_model pkggazebo_ros typespawn_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 到 rvizframe_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_framesview_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 为例数据robot_1robot_2里程计/robot_1/odom/robot_2/odom速度指令/robot_1/cmd_vel/robot_2/cmd_vel激光扫描/robot_1/scan/robot_2/scan定位结果/robot_1/amcl_pose/robot_2/amcl_posemove_base 目标/robot_1/move_base/goal/robot_2/move_base/goal写成表格之后编队逻辑就非常直白了它是一个「读各位位姿、算各目标点、再分发到对应 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.25resolution表示每个像素对应 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的状态值如果是 1ACTIVE但底盘不动优先检查 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 nsrobot_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如果还没到就不下发新目标其次把编队控制频率降到 12 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_1follower 是robot_2设定编队中的期望相对距离 L 与期望相对角度 φ则 follower 的目标点由 leader 的实时位姿推算import rospy import tf import math from geometry_msgs.msg import PoseStamped def compute_follower_goal(leader_pose, offset_x0.8, offset_y0.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 树检查 → 手动遥控 → 记录轨迹」的流程不再跳过任何一个环节。多机器人项目要建立的第一直觉不是「多高贵」而是「隔离做好没」这份工程给我最大的启发也在这里。希望帮到你。本文还有配套的精品资源点击获取
简介这是一份面向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_descriptionURDF 模型与坐标系设计ares_description 中放了urdf、meshes、launch、config四个目录。URDF 文件定义了机器人的连杆、关节、传感器挂载点和坐标系树meshes 目录里是 STL 或 DAE 网格文件供可视化与碰撞检测使用launch 目录里主要是robot_state_publisher相关的启动入口它会读取 URDF 并发布 TF 变换。目录/文件作用关键点urdf机器人本体、传感器、底盘描述每个 joint 的 origin 直接决定 TF 树是否正确meshes机器人外观网格与碰撞网格碰撞网格通常比可视化网格简化launch状态发布与模型加载入口支持spawn_model参数与 frame 前缀config关节限位、传感器参数与仿真控制器绑定多机器人场景下URDF 里最需要关注的是坐标系命名。假设每个机器人的 base_link、laser 等 frame 都叫同一个名字两个机器人一起发布 TFtf 树必然崩。这个项目的做法是让 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_navigationmove_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 nsrobot_1和group nsrobot_2分别加载机器人描述、spawn 模型、启动导航节点。下面是这类 launch 的骨架你在.launch里会看到类似写法launch !-- 启动 Gazebo 世界 -- include file$(find ares_gazebo)/launch/empty_world.launch arg nameworld_name value$(find ares_gazebo)/worlds/sim.world/ /include !-- 机器人 1整个组独立命名空间 -- group nsrobot_1 param namerobot_description command$(find xacro)/xacro $(find ares_description)/urdf/ares.xacro prefix:robot_1/ node namespawn_model pkggazebo_ros typespawn_model args-urdf -model robot_1 -param robot_description -x 0.0 -y 0.0 -z 0.1/ /group !-- 机器人 2与机器人 1 并排 -- group nsrobot_2 param namerobot_description command$(find xacro)/xacro $(find ares_description)/urdf/ares.xacro prefix:robot_2/ node namespawn_model pkggazebo_ros typespawn_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 到 rvizframe_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_framesview_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 为例数据robot_1robot_2里程计/robot_1/odom/robot_2/odom速度指令/robot_1/cmd_vel/robot_2/cmd_vel激光扫描/robot_1/scan/robot_2/scan定位结果/robot_1/amcl_pose/robot_2/amcl_posemove_base 目标/robot_1/move_base/goal/robot_2/move_base/goal写成表格之后编队逻辑就非常直白了它是一个「读各位位姿、算各目标点、再分发到对应 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.25resolution表示每个像素对应 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的状态值如果是 1ACTIVE但底盘不动优先检查 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 nsrobot_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如果还没到就不下发新目标其次把编队控制频率降到 12 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_1follower 是robot_2设定编队中的期望相对距离 L 与期望相对角度 φ则 follower 的目标点由 leader 的实时位姿推算import rospy import tf import math from geometry_msgs.msg import PoseStamped def compute_follower_goal(leader_pose, offset_x0.8, offset_y0.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 树检查 → 手动遥控 → 记录轨迹」的流程不再跳过任何一个环节。多机器人项目要建立的第一直觉不是「多高贵」而是「隔离做好没」这份工程给我最大的启发也在这里。希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
