企业官网建设流程全解析

做机器人这么久，我始终觉得“建图”是一项特别有成就感的入门技能。你把自己攒的底盘、雷达、上位机组装到一起，在终端敲下几行命令，几秒钟之后，一张由激光点云实时拼出来的房间轮廓图出现在 RViz 里，那一刻你会觉得之前踩过的所有坑都值了。

这篇文章写给正准备入坑 SLAM 的朋友，核心方案就是思岚 A 系列单线激光雷达配合 Google 开源的 Cartographer 做 2D 栅格地图构建。它解决的典型问题是：我只想用最低的成本、最短的路径，在一台 Ubuntu 笔记本或工控机上，把一个带轮子的机器人变成能画出房间地图的移动测量平台。整个过程不涉及复杂的理论推导，但该懂的原理我会用大白话讲清楚，该避开的坑我也会老老实实列出来。适合刚接触 ROS、第一次用雷达、或者已经试过 gmapping 但觉得地图质量不够好的开发者参考。

先说清楚这套组合为什么值得折腾：思岚的 RPLIDAR 系列在国内创客圈和高校实验室几乎快成标配了，接口简单、驱动成熟、价格友好，而且 ROS 社区资源非常丰富；Cartographer 是 Google 出的开源 SLAM 框架，和经典的 gmapping 相比，它引入了回环检测和子图（submap）机制，建图累积误差明显更小，尤其对于走廊、回字形这类几何特征明显的场景，效果几乎可以用“惊喜”来形容。两个东西凑一起，你就拥有了一个不依赖 GPS、不依赖昂贵惯导、纯靠激光雷达也能稳定跑起来的 2D 建图系统。

1. 内容整体设计与思路拆解

1.1 为什么是思岚雷达 + Cartographer，而不是其他组合

先聊聊选型这事儿。很多新手一上来就在纠结：用 gmapping 还是 Cartographer？用思岚还是国产其他牌子？我的建议是别纠结，先把这套组合跑通，再谈其他的。

思岚 A 系列（A1、A2、A3）用的是三角测距原理，不是工业级的 ToF 方案，所以成本才能压到几百到两千块这个区间。它发出的红外激光打到障碍物上，反射回来经过透镜成像在感光芯片上，通过光斑在芯片上的位置偏移来算距离。这个原理决定了它在室外强光下容易受影响，但在室内 2D 建图这个场景下，精度和稳定性完全够用。而 Cartographer 最让我满意的地方在于：它不是一个“盲人摸象”式纯递推算法。它的内部维护了一个由多个子图组成的位姿图，每当新的激光帧到来，它会先在当前子图里做 scan-to-submap 匹配，再把匹配结果提交到后端的位姿图优化器里，一旦机器人回到曾经走过的区域，回环检测（loop closure）就会启动，把整个轨迹拽回正确的位置。这个机制对你手里那把几百块钱的雷达特别友好，因为即使雷达数据有轻微噪声，后端优化也能把地图拉回正轨。

相比之下，gmapping 是早期的粒子滤波方案，实现简单、计算开销小，但它的缺陷在于只能靠当前的粒子权重去纠正位姿，没有显式的回环检测环节，跑大场景时误差容易越积越大。我之前在宿舍楼走廊用 gmapping 测过，两百米下来地图已经“漂”得没法看了。换到 Cartographer 之后，同样一把雷达，同样的底盘，效果直接上了一个档次。

1.2 硬件选型与部署形态分析

这套方案的核心硬件一共三样：激光雷达、计算平台、移动底盘。如果你只是验证算法，甚至可以不接底盘，拿着雷达和电脑在屋子里走一圈，也能出一张像模像样的地图，但效果不如装在底盘上稳定。

先看雷达。思岚官方型号里，A1M8 是入门款，测距半径 12 米，采样频率 5.5kHz（实测一般在 4kHz 出头），价格最低，缺点是电机寿命短一些、角分辨率在高速下会变粗。A2M8 是进阶款，测距 16 米，采样频率和精度都更好，最关键的是它把电机的磨损问题做了优化，更适合长时间跑。A3M8 性能最强，测距 25 米，但在 2D 建图这个任务里，A2M8 的性价比已经足够碾压了。我的建议是预算允许直接上 A2M8，没必要在 A1 上省那三五百块。下表是我实测过的一些关键参数对比：

计算平台的选择也比较随意：Ubuntu 系统能跑起来就行，1818 的树莓派 4B 也能跑，但建图时 CPU 占用率会飙到 80% 以上；建议一台 x86 架构的笔记本或迷你主机，最好是 i3 及以上加 4GB 内存，跑起来会比较从容。我之前在一台 NUC 上跑，Cartographer 前端 scan matching 的实时性非常好，没有掉帧的情况。

移动底盘这块，如果你没有现成的，最简单的办法是用带编码器的差速底盘，让 MCU 把轮式里程计通过串口发给上位机。为什么强调“带编码器”？因为 Cartographer 虽然是纯激光也能跑，但加上里程计约束以后，机器人快速旋转或者经过长走廊时，前端匹配不容易跟丢。这个后面具体讲配置时会重新提到。

1.3 为什么单线激光雷达适合室内 2D 建图

很多人第一次接触思岚雷达时会好奇：它就一个平面里转圈扫描，怎么能画出整个房间的轮廓？其实 2D 建图的核心假设是：机器人在同一个平面上运动，房间里的墙、家具在某个水平高度上都是“一条线”。雷达安装在一个固定高度（比如离地 10-20 厘米或 30-40 厘米，别对着桌子腿或椅背顶部），旋转一周就能得到这个水平切面上的轮廓点云。Cartographer 从这些点云里不断匹配位姿，叠加出完整的栅格地图。

这个原理也解释了一个实战经验：雷达的安装角度必须尽量水平。我见过有人把雷达随便粘在底盘上，结果扫描平面歪了，点云打到地面或天花板上，建出来的地图全是毛刺。另外，雷达高度要避开重灾区——如果你装得太低，满地乱跑的宠物、拖鞋、电线都会变成地图上的“墙”；装得太高，又可能扫不到家具中段。我习惯装在离地 15-30 厘米的位置，既能覆盖大部分家居轮廓，又不会扫到太多地面杂物。

2. 核心细节解析与实操要点

2.1 从雷达硬件到 ROS 话题：串口、权限与数据流

雷达上电后，数据通过 USB 转串口芯片（CP2102 或 CH340）进入系统。你要做的第一件事不是启动建图，而是确认系统认识这个串口设备。插上 USB 后，执行lsusb应该能看到对应的厂商 ID，比如10c4:ea60（CP2102）。接着查看设备节点：

ls /dev/ttyUSB*

正常情况下会出现/dev/ttyUSB0。如果没有，多半是驱动没装上（CH340 需要额外装驱动，Ubuntu 内核不一定自带）。

串口权限是新人最容易栽的坑。默认情况下，普通用户没有读写/dev/ttyUSB0的权限，你得先sudo chmod 777 /dev/ttyUSB0或者把自己加进dialout用户组：

sudo usermod -aG dialout $USER

加完组后一定要注销重新登录，否则权限不会生效。要是嫌麻烦，写一条 udev 规则，让系统启动时自动给这个串口赋予权限。在/etc/udev/rules.d/下新建一个文件，内容就两行，KERNEL匹配设备名，MODE给权限，这样以后插上雷达就能直接用。

雷达驱动在 ROS 里是一个节点，负责读取串口数据并发布成标准的sensor_msgs/LaserScan消息。消息里每一条数据都有 angle（角度）、range（距离）、intensity（强度）等信息，但 ROS 把它们封装成了一个数组。你不需要关心协议细节，只要知道驱动节点输出的scan话题就是 Cartographer 的“眼睛”就可以了。启动雷达后，用rostopic echo /scan | head能看到实时数据，用rostopic hz /scan能看到频率。正常情况下 A1 在 5-10Hz，A2 能达到 10Hz 左右。

这里多提醒一句：雷达供电很重要。思岚雷达虽然标称 5V 供电，但 USB 口的 5V 不一定干净，笔记本 USB 口供电不足时雷达会出现转速不稳、数据丢帧的现象。我实测过，A1 插在台式机前面板 USB 口，数据明显比后面板接口乱。如果你的雷达频繁掉线，优先怀疑供电，插个带屏蔽的 USB HUB 或者外接 5V 电源会好很多。

2.2 Cartographer 核心概念与配置文件详解

Cartographer 的配置不是 YAML，而是一段 Lua 脚本。很多新手第一次打开配置文件会被密密麻麻的参数吓到，但其实你只需关注三大块：地图构建参数、位姿图优化参数、轨迹构建参数。

先看构建参数，里面最常调的是map_frame、tracking_frame、published_frame、odom_frame这四个坐标系名字，它们决定了 TF 树里各个 frame 的命名。比如雷达的 TF 名通常是laser，底盘是base_link，里程计是odom，你必须保证这些名字和你的机器人描述文件（URDF）、雷达驱动里发布的一致，否则 Cartographer 启都启不动。

再看轨迹构建参数，里面有几个直接影响建图质量的：

• min_range和max_range：雷达的有效测距范围。思岚 A2 的测距是 0.15-16 米，你可以把min_range设为 0.2，max_range设为 15，小于或大于这个范围的数据都会被丢弃。为什么要刻意截掉最边缘的数据？因为三角测距在近处和远处误差都偏大，把这些坏点排除掉，让前端匹配更干净。
• num_accumulated_range_data：累积多少帧激光数据做一次匹配。默认值是 1，表示每帧都参与匹配；你可以调到 2-3，相当于把多帧点云叠加后再匹配，抗噪能力更强，但代价是建图延迟变大。如果你发现地图毛刺多，可以先把这个参数调到 2 试试。
• voxel_filter_size：体素滤波的尺寸，用来给点云降采样。默认 0.05 米意味着把空间分成 5 厘米的格子，每个格子只保留一个点。这个值越大，计算越快，但精度越低；越小，细节越丰富，但 CPU 压力大。

位姿图优化参数里必须认识loop_closure_adaptive相关的几个，回环检测的频率和窗口大小可以调。新手阶段不要乱动这些，保持默认就行。Cartographer 的默认参数针对一般的室内环境已经调得比较均衡，乱改反而容易把地图搞坏。

2.3 底盘里程计：让 Cartographer 稳定跑的隐藏条件

纯激光也能跑 Cartographer，但如果你把雷达拿在手里走一圈，建出来的地图往往歪得离谱，原因在于算法没法区分“雷达在平移”和“雷达在旋转”。Cartographer 的前端 scan matching 本质上是在不断地寻找一个刚体变换（平移加旋转），让当前帧激光点和已有的子图最吻合。这个优化问题的初始值越接近真实位姿，匹配越不容易陷入局部最优。

轮式里程计的作用就是提供一个可靠的预测值。底盘控制器根据电机编码器算出左右轮的转速，然后通过航迹推算（Dead Reckoning）估计机器人的位姿增量，再以odom -> base_link的 TF 关系发布出来。Cartographer 拿到这个预测值之后，scan matching 只需要在这个预测值附近做小范围搜索就行了，又快又稳。

如果你压根没有底盘，可以用纸箱推着雷达走，但一定要保持移动均匀，不要急转弯。我在实验室做过一个极简方案：把 A2 雷达用热熔胶固定在快递箱上，箱子底部装了四个万向轮，人推着箱子在办公室走了一圈，最后地图虽有点小歪，但整体轮廓可用。这证明 Cartographer 的容错空间确实大，同时也说明里程计对这个系统有多重要。

3. 实操过程与核心环节实现

3.1 环境准备：Ubuntu 与 ROS 版本选择

这套方案我建议你使用 Ubuntu 18.04 + ROS Melodic，或者 Ubuntu 20.04 + ROS Noetic。Melodic 是老牌组合，教程多、坑少；Noetic 是 20.04 上的版本，用 Python3，更新一些。如果你完全没装过 ROS，建议直接搜对应版本的官方安装教程，跟着一步步来就行。装完确认一下环境变量：

source /opt/ros/melodic/setup.bash echo $ROS_DISTRO

然后创建工作空间：

mkdir -p ~/catkin_ws/src cd ~/catkin_ws catkin_make source devel/setup.bash

这一步主要是验证你的 catkin 编译环境没问题。后面雷达驱动和 Cartographer 都会以源码方式放进这个工作空间里编译。

3.2 编译思岚雷达驱动并验证话题输出

思岚官方维护了 ROS 驱动，仓库名是rplidar_ros。直接在src目录下克隆：

cd ~/catkin_ws/src git clone https://github.com/Slamtec/rplidar_ros.git cd ~/catkin_ws catkin_make source devel/setup.bash

编译完先别急着启动，检查一下雷达串口的权限，然后运行：

roslaunch rplidar_ros rplidar_a2.launch

如果你用的是 A1，把 launch 文件换成rplidar_a1.launch。启动后打开另一个终端：

rosrun rviz rviz

在 RViz 里添加一个 LaserScan 显示项，话题选/scan，坐标系选laser。如果你看到一圈清晰的红点，说明雷达数据已经进入 ROS 了。要是屏幕上啥也没有，先用rostopic list看看有没有/scan话题，再用rostopic hz /scan看有没有数据发布。如果话题都没有，多半是串口设备名不对，或者权限不够。打开 launch 文件，里面有个串口参数，默认为/dev/ttyUSB0，如果你的设备是/dev/ttyUSB1，改掉重启即可。

有一个细节必须注意：实际的雷达 TF 名字要跟你在 Cartographer 里的配置一致。思岚官方 launch 文件里给的 frame 名是laser，一般不用改。但如果你有自己的 URDF，laser可能已经占用了，那就需要统一命名。

3.3 Cartographer 编译安装与网络加速

Cartographer 的官方安装方式有两种：二进制安装和源码编译。对新手来说，二进制安装最快——一条apt install命令就能装好运行库。但如果你需要修改源码或者定制功能，就得走源码编译。

源码编译的最大痛点是依赖太多，包括 abseil、ceres-solver、protobuf 等一大堆库。官方提供了一键脚本cartographer_ros/scripts/install_ceres.sh和install_proto3.sh，但脚本里用的是 Google 官方的下载地址，网络不好的时候经常卡住。我的做法是：先手动下载好这些依赖的源码包，放到脚本里指定的下载目录，然后再执行安装脚本，这样能避开大部分网络问题。

如果你实在不想折腾依赖，也可以用rosdep来安装系统依赖，再手动编译。无论如何，编译时间估计在十几分钟到半小时，建议编译过程中不要同时开一堆任务，给 CPU 留点余量：

cd ~/catkin_ws/src git clone https://github.com/cartographer-project/cartographer.git git clone https://github.com/cartographer-project/cartographer_ros.git cd ~/catkin_ws rosdep install --from-paths src --ignore-src --rosdistro=melodic -y catkin_make source devel/setup.bash

编译结束后，先跑一下官方自带的 demo 数据，验证安装是否成功：

roslaunch cartographer_ros demo_backpack_2d.launch

如果 RViz 里出现一个缓慢旋转的扫描场景，说明 Cartographer 安装成功。这一步很多人跳过了，结果后面一跑自己的数据就出各种问题，最后发现是安装有问题。所以这个 demo 一定要跑。

3.4 编写激光雷达与 Cartographer 的 Launch 文件

这是整个实战里最关键的一步。Cartographer 需要两个文件：一个是 Lua 配置文件，定义算法参数；一个是 launch 文件，负责把它跟雷达驱动串起来。

先看 Lua 配置。基于上面分析的参数，我提供一个适合思岚 A2 的配置。这个配置不是照搬官方默认，而是把几个关键参数按室内房间场景调过，建图效果稳定：

include "map_builder.lua" include "trajectory_builder.lua" options = { map_builder = MAP_BUILDER, trajectory_builder = TRAJECTORY_BUILDER, map_frame = "map", tracking_frame = "laser", published_frame = "laser", odom_frame = "odom", provide_odom_frame = false, publish_frame_projected_to_2d = true, use_odometry = true, num_laser_scans = 1, num_multi_echo_laser_scans = 0, num_subdivisions_per_laser_scan = 1, num_point_clouds = 0, lookup_transform_timeout_sec = 0.2, submap_publish_period_sec = 0.3, pose_publish_period_sec = 5e-3, trajectory_publish_period_sec = 30e-3, } TRAJECTORY_BUILDER_2D.use_online_correlative_scan_matching = true TRAJECTORY_BUILDER_2D.min_range = 0.2 TRAJECTORY_BUILDER_2D.max_range = 15.0 TRAJECTORY_BUILDER_2D.num_accumulated_range_data = 2 TRAJECTORY_BUILDER_2D.voxel_filter_size = 0.05 return options

注意这里面几个关键的逻辑。use_odometry = true表示要使用轮式里程计话题/odom；如果你没有底盘里程计，把它改成false，同时provide_odom_frame设成true，Cartographer 会用激光匹配结果直接输出 odom。tracking_frame和published_frame我都设成了laser，因为我们的雷达就是机器人的“眼睛”，在此方案里没有额外的 IMU 坐标系。如果你的机器人还接了 IMU，需要再加一个tracking_frame = "imu_link"之类的配置。

然后写 launch 文件：

<launch> <node name="rplidar_node" pkg="rplidar_ros" type="rplidarNode" output="screen"> <param name="serial_port" value="/dev/ttyUSB0"/> <param name="frame_id" value="laser"/> </node> <node name="cartographer_node" pkg="cartographer_ros" type="cartographer_node" args="-configuration_directory $(find cartographer_ros)/configuration_files -configuration_basename my_robot.lua" output="screen"/> <node name="rviz" pkg="rviz" type="rviz" required="true" args="-d $(find cartographer_ros)/configuration_files/demo_2d.rviz"/> </launch>

这个文件把雷达驱动节点、Cartographer 节点、RViz 一起启动了。-configuration_basename参数指向上一步写的 Lua 文件名。RViz 直接用 Cartographer 官方提供的 demo 配置，里面已经开好了 Map、LaserScan、Pose 等显示项，不用自己从头配。

如果你的底盘有里程计话题/odom，需要在 launch 文件里再启动一个串口桥接节点，把底盘的串口数据转换成nav_msgs/Odometry并发布/odom话题，同时发布odom -> base_link的 TF。这部分的实现取决于你的底盘协议，我不展开写，但你可以参考你底盘的 ROS 驱动。

3.5 启动建图：从手动推到自动跑

确认所有配置完成后，启动 launch 文件：

roslaunch cartographer_ros my_robot.launch

正常情况下你会看到 RViz 里逐渐出现点云和子图。此时机器人静止，点云应该是稳定的一条条线。接下来慢慢地推动机器人或用手柄遥控底盘，让它沿着房间墙壁走一圈，重点覆盖墙角、门洞、家具边缘这些特征明显的位置。过程中要控制速度，直线 0.2-0.5 m/s、转弯角速度不超过 0.5 rad/s 比较合适。跑太快了，雷达帧与帧之间的重叠太少，前端匹配容易失配。

需要注意，Cartographer 的地图是边建边发布的，并不是扫描完了才出图。刚开始只有雷达当前位置附近出现了点云，随着机器人移动，周围的栅格才渐渐清晰。一个重要的观察点是：当你走完一圈回到起点附近时，RViz 里的地图应该能自动“闭合”——也就是起点和终点附近的墙能对齐，不出现明显的错位。这个现象叫做回环闭合，是 Cartographer 最擅长的事。

3.6 保存地图与后续使用

建图完成后，先别着急关机。Cartographer 默认输出的地图话题不是静态的nav_msgs/OccupancyGrid，而是内部的子图列表。要保存静态地图，需要用map_server包提供的地图保存工具：

rosrun map_server map_saver -f ~/my_map

这条命令会订阅当前的栅格地图话题，生成my_map.pgm（灰度图，黑色为障碍物、白色为空闲、灰色为未知）和my_map.yaml（地图元数据文件，包含分辨率、原点、占据阈值）两个文件。保存时要注意：map_saver 保存的只是当前 RViz 里显示的那张子图，如果机器人还在移动，地图可能不完整。建议停止机器人运动后等几秒，让地图稳定下来再执行保存命令。

之后要把这张地图用于导航，只需要在 launch 文件里启动 map_server：

<node name="map_server" pkg="map_server" type="map_server" args="$(find your_pkg)/maps/my_map.yaml"/>

再配合 AMCL（自适应蒙特卡洛定位）就能做实时定位了。这一步属于导航范畴，这里先不展开，但你可以把建好的地图存好，它们就是后续所有地图应用的“地基”。

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

4.1 高频报错与解决办法速查表

我整理了一下这套部署流程里最常见的几类问题，基本是新手必踩的雷，按优先级排列：

这里面最值得展开说的是 TF 树问题。很多人的雷达数据明明很正常，但 Cartographer 就是报 TF 错误，根本原因是 Cartographer 对坐标系完整性要求很高。你在启动 launch 文件前，可以先单独跑雷达驱动，然后用rosrun tf tf_echo map laser看看能不能查到位姿变换。在没有 Cartographer 时它当然查不到，因为map这个 frame 还没创建。但如果你跑着底盘驱动，odom -> base_link就应该存在。我习惯把底盘驱动先启动，确认rosrun tf view_frames能生成完整的 TF 树图，再启动 Cartographer，这样至少能排除一半的问题。

4.2 数据质量控制：怎么判断雷达是不是在“好好干活”

雷达看起来在转、话题数值也在变，但建图效果依然很差，这种情况多半是雷达数据本身有毛病。我有个简单粗暴的自检方法：让机器人静止不动，然后rostopic echo /scan，看连续几帧数据里固定方向的距离值是否稳定。如果同一个方向上距离值上下跳动超过 3 厘米，说明雷达稳定性不好或供电有问题；如果出现大段 0 值或 inf，说明雷达在这个方向上被遮挡或者超出了量程。

另一个需要留意的是雷达的零度角（即扫描起始方向）。思岚雷达的扫描起始角度默认是电机的机械零位，一般会指向雷达外壳的某条标记线。如果你把雷达装偏了 90 度，点云在 RViz 里的方向就是歪的，建出来的图和实际房间朝向对不上。解决方法是做一次坐标变换补偿：一种是在 URDF 里给雷达加一个旋转关节，另一种是直接用 launch 文件里的angle_compensate参数。不过这个参数在新版驱动里不一定保留，我更推荐在 URDF 里处理。

4.3 建图策略：为什么你“走”地图的方式比参数更重要

参数调得再好，如果机器人移动路径不合理，地图照样建不好。Cartographer 的回环检测依赖机器人“故地重游”，所以最忌讳一口气从 A 点走到 Z 点浪费很远的距离。最合理的建图路线是“回字形推进”：从房间中心出发，先贴着墙走一圈，回到起点附近，再螺旋式向中心靠拢或向另一个区域推进，确保已经扫描过的区域多次出现在视野里。这样做既能触发闭环，还能让地图边缘闭合时更平滑。

实际操作中，我习惯在机器人上贴一张纸，标记雷达的零度方向，这样遥控时心里有底。建图过程中频繁回头看 RViz 里的地图，如果发现某块区域点云断层，就控制机器人退回去重新扫描，而不是硬着头皮往前冲。建图不是一个“一次性扫描到底”的过程，允许你反复走、反复补扫，这是 Cartographer 的优势——它只往地图里叠加信息，不轻易删除已有信息。

5. 建图质量提升与后续扩展建议

5.1 从建图到定位：地图保存之后还能做什么

建图只是第一步，之后最常见的需求就是让机器人在那张地图里面自主导航。流程是：启动定位功能包（AMCL），加载你保存的 map_server 地图，再启动 move_base 做路径规划。AMCL 会通过粒子滤波估计机器人在已知地图中的位姿，然后用激光雷达实时数据与地图匹配，实现实时定位。这几步只要地图质量不过分糟糕，基本都能跑通。更妙的是，如果定位后发现地图某处不对劲，AMCL 的修复过程中也能不断积累新的地图数据，你可以用 lifecycle 工具让地图在线更新。

导航这一块要注意，AMCL 和 Cartographer 不能同时运行，因为它们都会发布map -> odom的 TF，冲突会导致坐标混乱。我的建议是，建图完成后关闭 Cartographer，再启动 AMCL。很多新手在这里踩坑，建完图直接开导航，各种 TF 报错，折腾半天发现是两个定位节点打架。

5.2 升级雷达方案：A3、IMU 与轮式里程计的组合

如果你不满足于 A2 的效果，想挑战更大场景或者更粗糙的地形，可以考虑升级硬件。RPLIDAR A3M8 的测距范围到了 25 米，采样率提到 16kHz，在长走廊、大车间里能明显减少前端匹配的次数；再加一块 MPU6050 级别的 IMU，Cartographer 就能做三维旋转补偿，即使机器人上下坡、俯仰颠簸，激光点云也能被“摆正”之后再匹配。代价是配置文件复杂度上升：你要新增imu_link坐标系，把 IMU 数据通过sensor_msgs/Imu话题发布，并在 Lua 里把num_imu_data设为 1。此外，轮式里程计也需要做标定——用已知长度跑一段直线，测出实际轮径和理论轮径的偏差，然后修正底盘控制器参数。这些升级之间是互惠的，A3 的大视角让回环更容易检测到，IMU 的角速度数据让旋转时前端的初始猜测更准，里程计则保证直线段的位移估计不发散。

5.3 Cartographer 参数调优的个人经验

最后分享几个我在项目里调过的参数，你可以作为起点来“抄作业”，但不要盲目照搬。首先，min_range和max_range的设定要贴合雷达型号：A1 的远端数据噪声大，max_range我一般设 12；A2 可以到 15；A3 可以到 20。不要试图让算法处理雷达规格之外的数据，那只是给优化器添乱。

其次，num_accumulated_range_data这个参数很微妙。调成 2 能抗噪，但代价是地图实时性差一些，如果你在建图时有移动的障碍物（比如有人走过），反而会因为累积过多帧而把动态物体“拖影”进地图。我通常在纯静态环境调 2，在有人的环境调回 1。

还有TRAJECTORY_BUILDER_2D.use_online_correlative_scan_matching，这个参数控制是否启用实时相关扫描匹配，它在匹配失败时能帮上大忙，相当于一个“二次搜索”的保险。室内小场景建议设true，室外大场景如果 CPU 撑不住再设false。

最后是pose_publish_period_sec和submap_publish_period_sec，它们只影响 RViz 显示的刷新频率，不影响建图精度。如果你发现 RViz 卡顿，可以提高这两个数值（比如从小数改成 0.1），地图显示会变慢但 CPU 占用会下降。很多人以为地图生成慢是建图算法出了问题，实际上只是显示刷新频率太低而已。

我个人在实际操作中的最大体会是：这套组合的“下限”很低——哪怕你完全不懂 SLAM，照着流程跑也能出一张图；但它的“上限”也很高，参数、传感器、路径规划每一个环节都能显著影响最终质量。所以我的建议是：第一次跑通就用默认参数，先别急着调。等你看清了默认效果，知道哪里丑、哪里歪了，再去动对应的参数，你才能真正理解每个参数背后的意义。雷达不是越贵越好，关键是让你的环境、底盘和算法三者匹配起来。建图这件事没有“一键完美”，但一旦你把每个环节摸透了，每次建图都是一种可控的、令人满足的体验。