ROS+Gazebo实现TurtleBot3扫地机器人仿真：从SLAM建图到弓字清扫

做机器人仿真最怕什么？在我看来不是算法难，而是你花了一个星期把环境搭好、代码跑通，结果发现根本没法在真机上复现，或者调试一次要烧一次硬件，成本和耐心都撑不住。我一开始接触ROS的时候也走过不少弯路，后来用TurtleBot3在Gazebo里把一套完整的“建图、定位、导航、规划清扫路径”跑通之后，突然就明白了：仿真不是玩具，它是你把机器人逻辑想清楚的最好方式。这篇就来完整记录我的实操全流程——怎么用ROS加Gazebo，把TurtleBot3当成一台简易扫地机器人来跑，包含环境搭建、SLAM建图、move_base导航，以及我写的一个“弓字形”清扫脚本。无论你是刚装完Ubuntu的纯新手，还是想在项目里做路径规划验证的开发者，这个过程都值得你亲手走一遍。

选择这套组合，还有一个很现实的原因：TurtleBot3的仿真模型几乎复刻了真实硬件的传感器配置，激光雷达、IMU、轮式里程计都有对应插件，你在仿真里调过的参数，放到实物上有八成以上可以直接用。扫地机器人本质上就是一个装了两个驱动轮、一个万向轮、头顶加了一颗雷达的差速底盘，TurtleBot3 Burger的底盘结构跟它极其相似，拿它模拟扫地机器人，不是硬凑，是真的很对口。

1. 项目整体设计与思路拆解

1.1 为什么是TurtleBot3而不是自己建模

很多人一开始会有个误区，觉得既然是扫地机器人，干脆自己用SolidWorks画一个模型导进Gazebo算了。我不反对，但强烈不建议作为入门第一步。自己建模涉及三件事：模型文件格式转换、物理参数（质量、惯性张量、摩擦系数）标定、传感器插件配置。这三件事每一个都能让你卡上两三天。比如你从Blender导出一个DAE格式的模型，放进Gazebo后机器人往往会像踩在冰面上一样原地打滑，原因就是轮胎的摩擦系数没设，这类问题在入门阶段非常劝退。

TurtleBot3的好处在于，它把底盘、雷达、IMU这样一套标准配置全给你封装好了。Burger型号是两轮差速驱动，带一个360度激光雷达（LDS-01的仿真插件），底座还有一颗IMU。这套硬件组合跟市面上不少家用扫地机器人的传感器配置非常接近：激光雷达负责测距和建图，轮式里程计负责短距离位姿推算，IMU用来修正姿态漂移。所以你练的是通用能力，不是TurtleBot3专用技巧。

1.2 扫地机器人功能模块怎么拆

我在动手之前先把“扫地机器人”这件事拆成了四层，这也是后面所有步骤的主线：

• 感知层：激光雷达扫描周围环境，实时输出距离数据；轮式里程计输出机器人每一帧的相对运动
• 建图与定位层：SLAM算法把雷达数据拼成全局地图，同时估计机器人在地图中的位姿；后续导航时再换成AMCL做蒙特卡洛定位
• 规划层：move_base负责全局路径规划和局部避障，给机器人一条从A到B的路线
• 行为层：这是最像“扫地逻辑”的部分，决定机器人怎么走才能覆盖整个房间——常见的有弓字形往返、沿墙、螺旋覆盖等

TurtleBot3自带的仿真包覆盖了前三层，但行为层需要自己写。这也正是“模拟扫地机器人”最有价值的一环：你不可能只靠手搓遥控器去“扫”完一个地图，必须让机器自己在房间内规划出合理的覆盖路径。

1.3 仿真环境怎么选版本

这个坑我提一下，因为我见过太多人在版本搭配上翻车。ROS本身分ROS 1和ROS 2，两个大版本的启动方式、话题通信、参数系统都不完全一样。当前主流还是：

• ROS 1 Noetic + Gazebo 11，配Ubuntu 20.04，生态成熟，TurtleBot3官方教程最完善
• ROS 2 Humble + Gazebo 11（或Ignition），配Ubuntu 22.04，更接近新项目方向，但教程相对分散

我这次以ROS 1 Noetic为主线来写，因为大部分人第一次跑TurtleBot3仿真，用Noetic是最稳的，全网踩坑记录也最多。你如果已经装了ROS 2 Humble，整体流程的框架是一样的，只是launch命令和包名略有区别，这我在后面也会顺带提。

2. 环境准备：从空白系统到能启动Gazebo

2.1 安装ROS：手动源安装和一键脚本都能用

如果你用的是Ubuntu 20.04，最可靠的方式是官方源安装，这里给出核心命令：

sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list' sudo apt install curl curl -s https://raw.githubusercontent.com/ros/rosdistro/master/ros.asc | sudo apt-key add - sudo apt update sudo apt install ros-noetic-desktop-full

这一步会装完整版ROS，包含Gazebo 11、RViz、move_base等常用仿真和导航工具，总大小约3GB，需要一点耐心。如果网络环境不好，也可以尝试国内镜像源或开源社区维护的一键安装脚本，网上搜“鱼香ROS一键安装”就能找到，脚本本质就是把上面的步骤封装成自动执行，适合不想折腾源配置的初学者。我自己在虚拟机里装的时候也用过这种方式，省事不少。

2.2 安装TurtleBot3功能包和依赖

装完ROS本体以后，还需要安装TurtleBot3的仿真包和导航相关包：

sudo apt install ros-noetic-turtlebot3 ros-noetic-turtlebot3-simulations ros-noetic-turtlebot3-navigation sudo apt install ros-noetic-slam-gmapping ros-noetic-map-server ros-noetic-amcl ros-noetic-move-base

这里解释一下每个包的用途：

• turtlebot3-simulations：Gazebo仿真模型和launch文件
• turtlebot3-navigation：TurtleBot3在真实机器人上用的导航配置，仿真也要用
• slam-gmapping：基于激光雷达的2D SLAM算法，用来建图
• map-server：保存和加载地图
• amcl：蒙特卡洛定位，导航时确定机器人在地图中的位置
• move-base：核心导航框架，负责任务级的路径规划和避障

2.3 设置环境变量：这是最容易漏的一步

TurtleBot3在不同型号之间的模型文件不一样，所以ROS官方要求设置一个环境变量来指定型号。你可以在每个终端里执行：

export TURTLEBOT3_MODEL=burger

但这样做每开一个新终端就得重新设置一次，非常容易忘。我直接把这一行加进了~/.bashrc：

echo "export TURTLEBOT3_MODEL=burger" >> ~/.bashrc source ~/.bashrc

这样所有终端都会自动加载，不然后面启动launch文件时会报“TURTLEBOT3_MODEL is not set”或者一直提示找不到模型。

2.4 提前解决Gazebo模型下载慢的坑

很多人在第一次启动Gazebo时卡了半天，界面里一片灰白什么都没有，其实是Gazebo默认要从国外服务器在线下载模型文件。解决办法有两个：

第一个是检查~/.gazebo/models目录，如果没有就手动创建，然后把常用的模型放进去。第二个更高效的方法是直接用git把模型仓库克隆下来：

git clone https://github.com/osrf/gazebo_models.git ~/.gazebo/models

如果git下载也慢，可以尝试在GitHub页面上下载压缩包再解压。做完这步之后，后续启动仿真就不会再卡在“Downloading model ...”这一步了。

3. 跑通第一段仿真：看到机器人在房间动起来

3.1 启动Gazebo世界

环境准备好以后，第一次真正跑仿真的感觉还是很爽的。打开一个终端，输入：

roslaunch turtlebot3_gazebo turtlebot3_world.launch

这个命令会做三件事：启动Gazebo服务器、启动Gazebo客户端界面、加载TurtleBot3 Burger模型到仿真世界。turtlebot3_world是一个已经布置好的室内环境，里面有墙壁、简单的家具障碍物，非常适合做SLAM和导航测试。

启动过程中如果终端输出里出现很多红色的model下载失败信息，别慌，大概率是模型缺失，回到上面的模型目录检查一下就行。等到Gazebo界面加载完整、中央出现一个带蓝色激光线束的小车，就说明成功了。

3.2 用键盘控制机器人移动

此时机器人还瘫在原地，我们需要让它动起来。新开一个终端，安装并启动键盘遥控节点：

sudo apt install ros-noetic-teleop-twist-keyboard rosrun teleop_twist_keyboard teleop_twist_keyboard.py

这个节点把键盘按键映射成/cmd_vel话题上的速度指令。在终端里按w前进、s后退、a左转、d右转，Gazebo里的小车就会跟着动。Gazebo界面上还能看到激光雷达扫描出的蓝色线条，碰到墙壁时线条就会弯折，这就是雷达数据可视化的效果。

有个细节值得注意：键盘节点默认线速度是0.5米每秒，这个速度在仿真里看起来不算快，但建图时如果一直高速旋转，激光帧之间会出现较大畸变，后面SLAM建出来的图会糊。我建议进入建图环节之前，把速度调低一些，启动键盘节点时加参数：

rosrun teleop_twist_keyboard teleop_twist_keyboard.py _speed:=0.2 _turn_speed:=0.5

3.3 检查话题、TF和里程计

看得到机器人能动只是第一步，仿真作为开发环境的价值在于你可以随时“透视”机器人的内部状态。新开一个终端，用以下几个命令验证最基本的数据流：

rostopic list

这个命令会列出所有正在通信的话题。你需要重点关注的是/scan（激光雷达数据）、/odom（里程计数据）、/cmd_vel（速度指令）、/imu（惯性测量单元数据）。只要这四个话题都在，说明传感器插件正常。

再看机器人各部件之间的坐标变换：

rosrun rqt_tf_tree rqt_tf_tree

或者更简单的方式是：

rosrun tf view_frames

这会在当前目录生成一个frames.pdf，打开后能看到base_link到laser、odom等各个坐标系之间的关系。如果TF树断裂，后面AMCL或move_base一定会报错，所以这一步不要跳过。

4. 让机器人拥有“房间地图”：SLAM建图实操

4.1 SLAM选型：先用gmapping打底

扫地机器人要清扫的前提是知道房间轮廓。SLAM的方法有很多，Gmapping基于粒子滤波，对小场景和单层雷达效果不错，算力要求也不高；Cartographer是Google开源的那套，加入了子图匹配，回环修正能力强，但配置复杂很多。TurtleBot3仿真里默认推荐gmapping，我用下来感觉对于这个场景足够，启动也极简。

启动SLAM：

roslaunch turtlebot3_slam turtlebot3_slam.launch slam_methods:=gmapping

这个launch会启动slam_gmapping节点，并打开RViz可视化界面。RViz里会显示机器人模型、激光雷达点云，以及正在逐步构建的地图。刚开始地图是空的，随着机器人走动，地图会像拼图一样慢慢展开。

4.2 建图操作：速度要慢，转向要稳

启动SLAM之后，接下来就是手动控制机器人在环境里“逛一圈”。我实际操作有个心得：建图质量跟操作手法的关系非常大，不是任何速度都能建出好图。

首先是速度，前面提过，遥控节点默认的线速度太快，建议降到0.15到0.2m/s，转向速度控制在0.5rad/s以内。其次是路线规划，尽量从房间一端开始，沿着墙走“回”字形，一圈一圈往里缩，这样雷达能同时看到内外两侧的墙壁，特征点丰富，粒子滤波不容易发散。最后是尽量避免原地多次小角度转向，转向时激光数据容易产生错位，如果发现某段地图歪了，可以慢慢倒回去重新扫一遍。

大概花五分钟把整个地图扫完，RViz里应该能看到一个清晰闭合的室内轮廓。如果扫的过程中机器人撞到障碍物，在纯仿真里不会真的损坏，但你会发现地图上障碍物边缘会出现奇怪的缺口，这是碰撞后机器人位姿被弹开导致的，属于仿真中的正常现象，别当成SLAM算法有问题。

4.3 保存地图：一条命令的事

建完图先别关终端，把地图保存下来：

rosrun map_server map_saver -f ~/map

这会在家目录生成map.pgm和map.yaml两个文件。PGM是地图图片，YAML是地图的元信息，包括分辨率、原点坐标、占用阈值等。保存成功后打开PGM看一下，黑色是障碍物，白色是空地，灰色是未知区域。如果灰色占了一大片，说明没有扫全，得回到Gazebo里继续补扫。

到这里，“地图”这个扫地机器人最重要的先验知识就已经拿到手了。后面导航和规划路径全都要靠这张图。

5. 给机器人装上“大脑”：导航与清扫路径实现

5.1 启动导航栈：定位加路径规划

清扫和建图的区别在于，清扫时机器人已经知道自己在哪里，并且知道整个房间的地图，它要做的是在地图上规划路线，而不是边扫边探索。这个阶段用的是导航栈。

roslaunch turtlebot3_navigation turtlebot3_navigation.launch map_file:=$HOME/map.yaml

这行命令会启动三个核心节点：AMCL负责定位，move_base负责全局和局部路径规划，加上RViz可视化界面。启动后RViz里会看到机器人模型，但它还不确定自己在哪里。

有一个手法我很常用：在RViz顶部工具栏点击“2D Pose Estimate”，然后在地图上机器人对应的位置拉一个箭头，先给它一个初始位姿。这个操作等价于告诉它“你大概在这个位置、朝向这个方向”。AMCL定位收敛后，机器人周围的粒子会逐渐聚集到真实位姿附近。如果粒子到处散开，说明初始位姿给得偏差太大，重新拉一次即可。

5.2 理解move_base的路径规划逻辑

在清扫脚本写出来之前，先用RViz里的“2D Nav Goal”给机器人打个点，看它能不能自己走过去。点下去之后，绿色线是全局路径，红色线是局部路径，机器人会沿着规划出来的路线绕过障碍物前进。

move_base内部有两层规划器：

• 全局规划器（global_planner）：基于静态地图，算出一条从当前点到目标点的大致路径
• 局部规划器（local_planner）：基于实时激光数据，在小范围内躲避动态障碍物

两层规划器各有一个代价地图，叫costmap。代价地图把障碍物向外膨胀了一圈，膨胀的半径由inflation_radius参数控制。扫地机器人过窄通道时经常卡住，很大概率就是膨胀半径太大，机器人觉得自己过不去。如果你在后面的自主清扫脚本中发现某个狭窄路口机器人一直绕路，优先调小costmap里inflation_radius的值，而不是怀疑算法坏了。

5.3 模拟扫地逻辑：弓字形覆盖脚本

导航栈能做的只是“从A点到B点”，扫地机器人的核心是用一条合理路径覆盖整个房间。最经典的方案就是弓字形路径，沿房间一边走到底，然后平移一个机身宽度，再反向走回来，像农田耕犁一样一行行扫过去。

这一步需要写一个Python节点，利用move_base的action接口连续下发目标点。我写了一个简化版本，下面这段代码可以当成起点来改：

#!/usr/bin/env python3 import rospy import actionlib from move_base_msgs.msg import MoveBaseAction, MoveBaseGoal from geometry_msgs.msg import PoseStamped, Quaternion import math class SweepCleaner: def __init__(self): rospy.init_node('sweep_cleaner') self.client = actionlib.SimpleActionClient('move_base', MoveBaseAction) self.client.wait_for_server() # 清扫区域左下角和右上角（单位：米），按实际地图修改 self.min_x = 0.0 self.max_x = 3.0 self.min_y = 0.0 self.max_y = 3.0 self.robot_width = 0.5 # 每行间距，略小于机器人直径 def make_goal(self, x, y): goal = MoveBaseGoal() goal.target_pose.header.frame_id = "map" goal.target_pose.header.stamp = rospy.Time.now() goal.target_pose.pose.position.x = x goal.target_pose.pose.position.y = y goal.target_pose.pose.orientation.w = 1.0 return goal def run(self): y = self.min_y direction = 1 # 1 向右走，-1 向左走 while y <= self.max_y: if direction == 1: x = self.max_x else: x = self.min_x goal = self.make_goal(x, y) self.client.send_goal(goal) self.client.wait_for_result() y += self.robot_width direction *= -1 if __name__ == '__main__': SweepCleaner().run()

这段代码的逻辑是：从房间左下角开始，先向右走到边界，然后上行一个机身宽度，再向左走到边界。循环往复，形成弓字形覆盖。实际项目中你还需要在拐点时加上旋转动作，以及根据代价地图检测未覆盖区域，但基础骨架就是这个。

运行之前记得给脚本加执行权限：

chmod +x sweep_cleaner.py python3 sweep_cleaner.py

然后就可以在RViz里看到机器人走走停停，按你给的矩形区域做往返运动。这个效果，我可以说已经非常接近一台真正扫地机器人的行为模式了。

5.4 参数微调的几条经验

扫地覆盖跑起来之后，你会发现很多实际问题跟想象中不一样。

第一，行距不能大于机器人直径，否则行与行之间会漏扫。Burger模型直径大概是17厘米，我用0.15米作为行距，覆盖比较密，但就是慢。如果你只是做演示，可以放大到0.2米，视觉上依然能看出清扫效果。

第二，机器人到达每个目标点都会先完全停下来，再转向下一行，这样效率很低。真正的扫地机器人会在行驶过程中直接转弯。解决办法是给每个目标点传入带有朝向的Quaternion，让机器人在到达时提前做姿态调整，而不是停稳再转。

第三，move_base超时问题。如果某个目标点在costmap里被标记成不可达，机器人会一直尝试，然后卡住。我建议在send_goal之后加一个超时判断，超过30秒没到达就放弃当前点，直接去下一个，避免整个清扫流程卡死。

6. 常见问题与排查技巧实录

6.1 Gazebo界面闪烁或者黑屏

这个问题我在热词里看到很多人问。Gazebo的渲染基于OpenGL，如果你的电脑是双显卡或者跑在虚拟机里，经常会出现界面闪烁、黑屏或画面撕裂。最快的验证方法是强制Gazebo用软件渲染：

export LIBGL_ALWAYS_SOFTWARE=1

但软件渲染性能比较差，大场景里机器人动起来会有点卡。有条件的话可以安装系统的NVIDIA或AMD专用驱动，然后用GPU渲染。另外，有时不是渲染问题，而是Gazebo同时开启了多个客户端实例，多个进程抢同一个渲染窗口，这种关掉多余的gzclient进程就能解决。

6.2 模型加载后机器人乱飞或者掉到地下

如果你在Gazebo里看到机器人外观正常，但一启动就乱飞、下沉或抖动，基本可以确定是模型加载的物理参数出了问题。TurtleBot3官方模型很少出现这种问题，倒是自己导入的外部模型特别容易中招。检查点有两个：模型文件的<mass>和<inertia>是否合理，以及是否设置了合适的<surface>摩擦参数。

如果你用的是TurtleBot3原装模型，还出现乱飞，那大概率是Gazebo版本太旧和ROS Noetic自带的Gazebo 11不兼容，需要升级Gazebo或重新安装完整版的desktop-full包。

6.3 move_base启动后一直报“No transform from odom to map”

这个报错在导航启动时非常常见。本质上是因为没有定位数据，AMCL没有发出从map到odom坐标系的变换。常见原因有三种：

一是初始位姿没设置，回到RViz用“2D Pose Estimate”给一个初始位置；二是map_frame、odom_frame、base_frame这三个坐标系名字不对，打开launch文件确认一下，TurtleBot3默认使用map、odom、base_footprint（或base_link）；三是TF树本身断了，用rosrun rqt_tf_tree rqt_tf_tree检查整棵TF树是否从map一直连到laser。

6.4 导航时机器人在原地打转

机器人到达目标点的过程中如果一直原地旋转，通常是局部规划器的问题。常见原因就是costmap的膨胀半径设得太大，导致机器人认为自己周围全是障碍物，任何速度指令都会被标记为“可能碰撞”。此时适当调小inflation_radius，或者检查雷达话题/scan是否输出正常数据，如果雷达数据是空的，局部规划器等于瞎子，只能在原地转圈。

6.5 仿真速度越来越慢

跑了一段时间后，Gazebo帧率明显下降，这跟模型下载缓存、粒子数量持续增长都有关系。gmapping的粒子数默认是30，如果建图场景很大，可以试着把粒子数调小一些，地图精度会略降但流畅度明显提升。此外，长时间开着多次启动的launch文件会产生大量僵尸进程，用htop查一下，把不再需要的roscore和gzserver进程清掉。

6.6 常见问题速查表

6.7 热词相关心得补充

在海量热词里，“为什么Gazebo界面一直在闪”被提问最多，其次是“Gazebo安装ros环境ubuntu22”这类环境问题。我个人补充两条实用经验：一是使用Ubuntu 22.04配ROS 2 Humble的用户，如果遇到Gazebo启动异常，优先确认是否装了ros-humble-gazebo-ros-pkgs，这个包经常被遗漏；二是“gazebo使用gpu加速”这一点，对室内小场景作用有限，Gazebo的物理引擎计算才是瓶颈，与其纠结渲染，不如把粒子数和地图分辨率调低一点。

清扫路径策略这块，我还有个小建议：不要只盯着move_base默认的规划器，试试把全局规划器切换成NavfnROS，有时候在狭窄通道里的表现反而比默认的GlobalPlanner更稳定。这些都是在反复调参中得到的经验，纯看文档是体会不到的。

7. 写在最后：把仿真成果向真机迈进

TurtleBot3这套仿真流程跑完之后，你手里拿到的不仅是一段能动的Gazebo演示，而是一整套现代机器人开发的基本工作流：仿真建模、传感器数据检查、SLAM建图、定位、导航规划、行为调度。这套工作流稍加变化，就能延伸到其他机器人的研发里。

我个人的建议是，下一步不要急着加复杂的策略，先用日志和数据把仿真的每个环节记录下来：雷达扫描频率是多少、一次完整的弓字形清扫耗时多久、覆盖率能达到多少。这些指标会让你对机器人的性能有更直观的认识，后面换到真机时，你也会养成先量化再优化的习惯。

如果你有动力，可以接着尝试：把TurtleBot3换成Waffle Pi型号，看它对载重能力的变化；或者在Gazebo里加几个动态障碍物，观察局部规划器避障时的真实表现。总之，TurtleBot3是一座桥，跨过它以后，你会发现ROS和Gazebo能做的事情远比你最初想象的多。