企业官网建设流程全解析

点云、SLAM、Nav2，这三个词拆开看，分别属于感知、建图与导航三个方向，可实际上在扫地机器人这类室内轮式机器人上，它们是一条完整数据流的不同阶段：传感器先吐出一堆点云，SLAM榨干这些点云建出地图并实时定位，Nav2再拿这张图去做代价地图、路径规划和避障。最近给一台扫地机器人做了完整的SLAM与Nav2导航方案，从RealSense D435的点云获取、SLAM Toolbox调参，到Nav2行为树和3D雷达接入，整个链路走了一遍，踩了不少坑，今天把过程整理出来。

这篇内容适合正在做ROS2扫地机、服务机器人、AGV的开发者，也适合刚把《视觉SLAM十四讲》啃完、想从理论知识落到实际整机的人。我会尽量把从点云到地图的转换逻辑、SLAM调参背后的判断依据、Nav2行为树的组织方式，以及常见的故障排查方法讲清楚。全程不会绕弯子，基本都是实测下来的结论。

1. 全链路拆解：一台扫地机器的数据流长什么样

1.1 为什么是“点云→地图→导航”这条链路

很多人把点云、SLAM、Nav2当成三个独立的方向去搜资料，其实它们就是同一串数据流的不同阶段。扫地机器人的核心任务只有两个：知道自己在哪，知道怎么走。前者靠SLAM完成，后者靠Nav2完成，而点云是所有空间信息的源头。

一台典型的扫地机器人，传感器可能是一个2D激光雷达，也可能是一颗RealSense D435这样的结构光相机，或者是一颗3D激光雷达。无论哪种，原始输出本质上都是一堆带坐标的三维点，这就是点云。SLAM负责把这些点按照时间顺序拼接起来，同时估计机器人自身的位姿，最终输出一张可供导航用的2D栅格地图或者3D地图。Nav2拿到这张地图之后，在它上面叠加实时传感器的障碍物信息，生成代价地图，再用规划算法算出一条从当前位置到目标点的安全路径。

这里有个容易被忽略的点：SLAM输出的地图是静态的。地图建完之后，房间里如果多了个快递盒，地图上是没有的。Nav2的价值就在于用实时点云或雷达数据去更新代价地图，让机器人在动态环境中也能躲开障碍物。所以整个链路不是单向的，地图是SLAM给Nav2的“底图”，实时点云是Nav2给路径规划的“增量更新”。

1.2 硬件信息流与坐标系

从硬件到软件的信息流，我习惯画成这样一条链：传感器原始数据 → 点云/激光扫描 → 里程计与IMU → SLAM节点 → 地图与位姿 → Nav2代价地图 → 规划器 → 速度指令。

这里面最核心的是坐标系变换。扫地机器人身上有base_link（机器人本体坐标系）、laser_link（雷达坐标系）、odom（里程计坐标系）、map（地图坐标系）这几套坐标系。SLAM在建图过程中实时维护map到odom、odom到base_link的变换，Nav2的每个模块都要依赖这些TF变换才能工作。我实测下来，90%的导航异常，最后查出来都是TF发布频率不稳定或者坐标系写错导致的。

还有一个实操经验：扫地机器人底盘比较矮，传感器安装高度对后面点云处理影响很大。如果雷达或者相机装得太低，地面点会大量混入，导致SLAM扫描匹配出错；装得太高，又可能看不到桌腿这类低矮障碍。我在某台机器上把D435装到离地约30厘米的位置，配合高度切片过滤，地板和低矮障碍物都能干净分离，这个高度区间在扫地机上算是比较稳妥的。

1.3 硬件选型：2D雷达、3D雷达、结构光相机怎么搭配

硬件选型决定了后面所有代码怎么写，这块值得单独说。2D激光雷达（比如RPLIDAR A1/A2）是扫地机器人的传统方案，成本低、算法成熟，SLAM Toolbox和Gmapping都能直接吃scan数据。它的缺点是只能看到激光平面上的障碍物，桌面上悬空的物体完全感知不到，但扫地机器人本身就是要贴地工作，所以这个缺点在扫地场景下问题不大。

3D雷达（比如Livox MID-360）的优势是视野广、点云密度高，但不直接输出2D scan，要么先转成2D扫描喂给传统SLAM，要么干脆走3D SLAM。RealSense D435这类结构光相机则完全是另一条路线，输出的是深度点云，能感知立体障碍物，也能输出彩色图像，方便做视觉辅助。

在实际项目里，我见过几种搭配：激光雷达+IMU、D435单目深度相机、D435+2D雷达融合。对于纯扫地场景，我个人的排序是：2D雷达最省心，D435可玩性最高但要处理深度噪声，3D雷达适合房间较大的场景。如果你预算有限，先用2D雷达把SLAM和Nav2整条链路跑通，再考虑加D435补充障碍物感知，这样调试成本最低。

2. 点云获取与处理：从RealSense D435到可用障碍物信息

2.1 D435点云获取与ROS2驱动

RealSense D435是英特尔的结构光+双目深度相机，它用红外投影仪投射不可见的结构光纹理，配合双红外相机做立体匹配，所以室内白墙这种没什么特征的环境也能出深度。在ROS2里驱动它非常简单，装好realsense2_camera包后，一条命令就能起来：

ros2 launch realsense2_camera rs_launch.py \ depth_module.depth_profile:=640x480x30 \ pointcloud.enable:=true

这里的关键参数是depth_profile，我实测640x480@30fps是性价比最高的配置。分辨率再高，点云稠密到几百万点，SLAM和Nav2根本用不上，反而让CPU直接拉满。分辨率再低，深度空洞会明显增多，近距离桌腿都可能缺一块。

点云话题会发布在/camera/depth/color/points，坐标系是camera_link。这里要注意一点：D435的深度有效范围是0.3米到3米左右，离得太近反而会丢深度。扫地机器人底盘低，相机如果朝向正前方，近距离地面的盲区是客观存在的，只能通过角度调整去缓解。

我调试时遇到一个典型问题：客厅窗户阳光很强的时候，D435的深度图上会出现大块黑色空洞。原因是阳光里的红外成分干扰了结构光投影，把双目相机的红外图像直接打穿了。这个问题的缓解办法有几个：一是把相机曝光时间调低，二是加遮光板，三是在算法层面对深度空洞做插值。最省事的其实是调整安装角度，避免正对窗户。

2.2 点云滤波与体素降采样

D435每帧会产出一批点云，但这里面混着大量噪声和地面点。直接把原始点云丢给SLAM或者成本地图，轻则地图模糊，重则导航乱转。我的处理链路固定是三步：体素降采样、直通滤波、高度切片。

体素降采样用的是PCL的VoxelGrid滤波器，原理是把空间划分成一个个小立方体，每个立方体里只保留一个中心点。对于D435的点云，我习惯把leaf_size（体素边长）设成0.02到0.03米。太大会把细桌腿也磨没了，太小则没有降采样效果，CPU白烧。

<!-- pointcloud_to_laserscan 的典型配置片段 --> <node pkg="pointcloud_to_laserscan" exec="pointcloud_to_laserscan_node"> <param name="target_frame" value="base_link"/> <param name="transform_tolerance" value="0.1"/> <param name="min_height" value="0.05"/> <param name="max_height" value="0.25"/> <remap from="cloud_in" to="/camera/depth/color/points"/> <remap from="scan" to="/scan"/> </node>

重点说高度切片。扫地机器人的任务是贴地移动，真正需要避障的是从地面到机身高度的障碍物。把min_height设成0.05米，max_height设成0.25米，就能把桌腿、椅子腿这些“必须躲开的东西”保留下来，把地板反射、低矮地毯、还有天花板这些无关点全部过滤掉。这个思路适用于任何把3D点云转2D激光的场景，不只是D435。

2.3 3D点云怎么变成2D栅格地图

扫地机器人整套框架里，SLAM和Nav2绝大多数情况下都工作在2D平面上。这就引出一个核心操作：如何把3D点云转成2D栅格地图。

目前主流做法有两种。第一种是投影法，把点云按高度切片后，直接向XY平面投影，投影密度高的格子标记为占用。第二种是2D扫描模拟法，用ray casting的方式模拟一个2D激光雷达，把切片内的点云转成距离值。ROS社区常用的pointcloud_to_laserscan就是典型的转换工具，它内部做的事情本质上就是“在指定高度范围内做射线模拟”。

我自己的经验是，转换时不要只看高度，还要看点云的密度。D435在3米外深度噪声明显增大，转出来的scan会有一圈“毛刺”，这些毛刺在SLAM里容易被当成边缘特征，导致建图精度下降。所以在转换之前，一定要先做体素降采样，把体素leaf_size调到0.02米以上再转，效果会干净很多。

2.4 结构光相机点云融合的补充经验

结构光相机不只D435一种，还有Orbbec的Astra系列等等。所谓“点云融合”，通常是指把深度相机和彩色相机数据融合，生成带RGB颜色的点云，或者把多个视角的点云配准融合成更完整的三维模型。

在扫地机上做RGB-D融合的实际意义，更多是给重定位和回环检测提供颜色辅助。比如在一个全是白色墙壁的客厅里，激光SLAM的分辨率不够，容易发生“走廊尽头认不出来”的问题，但如果有彩色图像，视觉特征能帮助区分不同位置的相似结构。我曾经在两条外观几乎一样的走廊里做重定位，纯激光只能靠里程计推，融合D435的图像特征之后，能明显降低定位漂移。

不过要提醒的是，结构光相机在阳光直射下深度质量会严重下降，所以融合算法里一定要加置信度判断：深度值低于某个阈值就丢弃该点，不要强行融合。

3. SLAM方案选型与参数调优

3.1 SLAM Toolbox、Cartographer、Gmapping怎么选

在建图方案上，扫地机器人圈子里最常见的三个选择是SLAM Toolbox、Cartographer和Gmapping。我分别跑过一轮对比，直接说结论。

Gmapping是老爷辈的粒子滤波SLAM，依赖里程计质量，适合小房间和低算力平台，但几乎没有回环检测，长时间建大图会飘。Cartographer是Google出的图优化SLAM，把激光扫描匹配和子图优化结合起来，回环检测强，写进论文里的那种强。它能做2D也能做3D，代价是配置复杂，调参是个技术活。SLAM Toolbox是ROS2官方推荐的方案，基于Karto算法，在回环检测和地图质量上平衡得很好，关键是配置非常简单，对新手友好得多。

我的选择很直接：扫地机器人这种室内结构化环境，用SLAM Toolbox最省心。原因有三点：一是ROS2原生支持，launch文件配起来没那么多幺蛾子；二是它的2D建图精度在客厅、卧室这种场景足够用；三是有自带的定位图功能，能和Nav2无缝衔接。Cartographer更适合大面积厂房、走廊这种环境，或者你需要3D地图的场合。

3.2 SLAM Toolbox关键参数与调参逻辑

SLAM Toolbox的配置文件本质是一堆参数，很多人一上来就抄别人的YAML，结果跑出来的地图稀烂。这里必须理解每个参数是干什么的。

slam_toolbox: ros__parameters: max_laser_range: 12.0 minimum_score: 0.2 laser_frame: "laser_link" odom_frame: "odom" map_frame: "map" scan_match: 1 loop_closure: 1 map_update_interval: 0.5

先说max_laser_range。这个值要和你的传感器实际量程匹配。D435转出来的scan有效距离大概3米，你如果写成12米，SLAM会认为远处也有可靠特征，结果把噪声当障碍物。我建议max_laser_range设置为传感器可靠量程的80%左右，宁可少看远一点，也别吃过多的噪声。

minimum_score是扫描匹配的最低得分。建图时如果环境特征太弱（比如空旷走廊），得分会普遍偏低。设置太严，比如0.4以上，SLAM会频繁判定匹配失败，地图建一半就罢工；设置太松，比如0.1，它会把明显错误的匹配也接受下来，地图直接扭曲。我一般从0.2起调，如果建图过程经常报告Scan Matching失败，就往下降；如果地图出现重影错位，就往上升。

map_update_interval控制地图刷新频率。扫地机器人在建图时如果旋转速度较快，建议设0.5秒刷新一次，不然规划时看到的地图明显滞后。但也不能太低，否则CPU占用飙升。这个值本质上是给地图光滑性和CPU负载之间做权衡。

还有一个经常被忽视的选项：scan_match设置在MODE_2D还是MODE_3D。D435转成2D scan之后，MODE_2D完全够用。但如果你直接喂3D点云给SLAM Toolbox，就必须考虑3D模式，那个牵扯到更多传感器位姿估计，一般扫地场景用不到。

3.3 点云配准在SLAM里的实际角色

聊到SLAM，很多人会看到“点云配准”这个词，觉得是个独立知识体系。其实SLAM每时每刻都在做点云配准，只不过在SlAM工具箱里它叫scan matching（扫描匹配）。

所谓扫描匹配，就是把当前时刻的激光帧和上一帧或者已有地图对齐，算出机器人相对上一个位姿的增量。经典做法是ICP（迭代最近点）和NDT（正态分布变换），Cartographer用的是Ceres Solver去做非线性优化求解。ICP的思路是找两组点云里距离最近的点对，计算旋转和平移让它们尽可能重合。扫地机每走一步，雷达看到的墙线就是一组点云，SLAM通过配准把连续帧拼成完整地图。

我调过最深的一个坑，是建图时机器人转得太快导致扫描匹配失败。原因是激光帧率一般10Hz，如果角速度太快，两帧激光之间的视角变化过大，ICP迭代会陷入局部最优。解决办法很简单：建图时控制线速度和角速度的上限，比如线速度不超过0.3m/s，角速度不超过0.5rad/s。这个限制在slam_toolbox的配置里不一定直接体现，但可以通过遥控端去控制。

3.4 视觉SLAM在扫地机上的坎

热词里出现了视觉SLAM、Visual SLAM、图像引导点云，这些在扫地机上不是不行，但确实不容易。视觉SLAM的核心是用相机图像提取特征点，通过特征点三角化得到点云，再优化位姿。以ORB-SLAM3、VINS为代表的一类算法，在室内环境表现尚可，但扫地机这个场景有几个天然的坎。

第一，扫地机视角太低。相机贴地20-30厘米，看到的全是地面纹理和各种腿，特征点分布极其不均匀。第二，室内白墙和光滑地板缺乏纹理，特征提取数量不足，视觉里程计很容易跟丢。第三，结构光相机在阳光直射下深度失效，视觉SLAM跟着完蛋。

所以在实际扫地机项目里，视觉SLAM更多是充当激光SLAM的补充，而不是替代品。我见过一个比较靠谱的融合方案：激光SLAM做主定位，视觉SLAM做回环检测的图像验证。两者融合之后，在长走廊里能有效减少重复场景的误匹配。这个方案对算力要求不低，但效果确实比纯激光好。

4. Nav2导航：代价地图、行为树和路径规划

4.1 代价地图的三层结构与配置

地图建好之后，Nav2要做的事不是直接在上面跑A*，而是先构建一张代价地图（costmap）。代价地图分三层：静态层、障碍物层、膨胀层。静态层加载SLAM输出的栅格地图，障碍物层实时接收雷达或点云数据，膨胀层负责把障碍物“画胖一圈”，给机器人留出安全距离。

local_costmap: local_costmap: ros__parameters: robot_radius: 0.18 inflation_radius: 0.30 obstacle_layer: observation_sources: scan scan: topic: /scan max_obstacle_height: 0.20 min_obstacle_height: 0.05

有几个参数我必须强调。robot_radius是机器人底盘的等效半径，扫地机的半宽可能只有0.15米，但为了不刮到家具，我习惯加上一点余量。inflation_radius决定障碍物的膨胀距离，设大了路径会绕远路，设小了可能贴着墙角走。0.3米对于半径0.18米的扫地机是个比较平衡的值。

障碍物层的min_obstacle_height和max_obstacle_height，很多人直接抄默认，结果很多时候机器人在桌子底下转圈，因为桌面被当成障碍物了。扫地机要考虑的是到底哪些高度有碰撞风险。如果机器人高0.15米，障碍物高度切片设成0.05到0.25米就刚好，桌面高度0.7米以上的物体，在2D代价地图里根本不需要出现的。

4.2 Nav2行为树：把导航逻辑组织起来

Nav2的行为树（Behavior Tree）是它跟传统导航架构最大的不同。你可以把行为树想象成一个可编程的导航决策流程图，每个节点是一个动作或条件，节点之间用序列或回退连接。

默认的NavigateToPose行为树，核心结构是这样一段逻辑：先检查目标是否已经到达，没有的话就执行“计算路径→跟随路径→如果失败则恢复”的循环。恢复节点（RecoveryNode）可以说是扫地机导航的保险丝，路径规划失败或者跟随路径卡住的时候会自动触发清理代价地图、原地旋转、后退这一系列动作。

这里我要特别说说默认行为树的局限。默认恢复动作是ClearEntireCostmap、Spin和BackUp，它们解决“代价地图脏了”的问题，但解决不了“机器人根本不知道自己在哪”的问题。在扫地机这种经常被搬来搬去的小车上，我强烈建议在行为树里加一个重定位分支：当路径规划连续失败超过一定次数，就触发主动重定位，用amcl重新计算位姿，而不是傻乎乎地在错误的位置上反复后退。

自定义行为树的方式是改BT的XML文件。Nav2的bt_navigator允许你指定自己的XML，我可以直接提供一种简化结构：主线是计算路径和跟随路径，失败时先清理地图，再原地旋转，若还是失败，就触发全局重定位。这样做的好处很实际：扫地机被用户拎到另一个房间之后，不会再卡在“旧地图找不到路”的状态里。

4.3 规划器与控制器：Dijkstra还是DWA

Nav2的规划分两层：全局规划器负责在地图上算出一条从起点到目标的无碰撞路径，局部规划器负责实时避障并生成速度指令。

全局规划器我用的是NavFn，它支持Dijkstra和A两种算法。扫地机场景建议用Dijkstra，因为代价地图里的代价不是二值的，A在复杂代价场下可能找到的不是最优解。Dijkstra的计算开销稍大，但室内地图规模不大，CPU完全扛得住。关键参数tolerance设置成0.3米表示“目标点附近的这段距离内能找到路径就算成功”，防止因为目标点被膨胀层覆盖导致路径规划失败。

局部控制器我用DWA（Dynamic Window Approach），它会在每个控制周期枚举一组线速度和角速度候选，预测未来一小段时间的运动轨迹，挑一条既避障又接近全局路径的轨迹输出。扫地机这种差速底盘，DWA是最稳妥的选择之一。关键参数是max_vel_x和acc_lim_x，室内环境下线速度上限0.4m/s，加速度上限1.0m/s²就够了。过快会加剧惯性，导致转弯时碰撞墙角。

controller_plugins: ["FollowPath"] controller_frequency: 10.0 FollowPath: plugin: "nav2_dwb_controller::DWBLocalPlanner" max_vel_x: 0.4 min_vel_x: -0.15 acc_lim_x: 1.0 acc_lim_theta: 1.5

DWA调参有一个很反直觉的地方：max_vel_x设得太大反而会让机器人卡住。扫地机在狭窄过道里，速度越快，DWA的可行轨迹越少，最后规划出来的往往是急刹车。我把限速从0.6降到0.4之后，过门和转弯的流畅度明显提升。

4.4 3D雷达怎么接入Nav2

热词里有一条是“Nav2导航使用3D雷达”，这确实是一个高频需求。3D雷达接入Nav2有两条路：一条是把3D点云话题直接给障碍物层，另一条是转成2D scan再喂进来。

直接给点云的方式，配置上很简单，把障碍物层的observation_sources指向点云topic就行。但实测下来有个大坑：3D雷达点云量太大，没做体素滤波的话，costmap更新频率会掉到几赫兹，导航直接变卡顿。所以如果要用点云直通行，务必在雷达驱动里先做降采样。

另一种更成熟的方式，是先把3D雷达点云转成2D scan，再接Nav2。这个方式的好处是Nav2的2D代价地图算法稳定，调参经验和2D雷达完全通用。转换工具还是pointcloud_to_laserscan，重点是高度切片要和雷达安装高度匹配。我用Livox MID-360的时候，扫到地面点比较多，所以把min_height调得比雷达安装高度略高一点，把地面点尽量过滤干净。这样转出来的2D scan质量接近传统2D激光，后续SLAM和Nav2都不用改套路。

5. 全链路联调与问题排查实录

5.1 高频故障速查表

走完整条链路，我把实际遇到的高频问题整理成了下面这个速查表。每一项都是我在调试中验证过的，直接照表排查能省不少时间。

5.2 实测中的避坑心得

第一个心得是：先调坐标系，再调算法。我在联调的第一周，几乎一半时间花在TF上。D435出来的点云在camera_link下，但SLAM期望的scan帧是laser_link，如果这两个坐标系的变换没有正确发布，SLAM建出来的地图就是个旋转过的世界。任何地图问题，先检查TF树，用ros2 run tf2_tools view_frames看一眼坐标系关系，正常后再深入调参。

第二个心得是：建图过程本身就要控制机器人运动。我见过很多人在建图时遥控机器人满屋子乱窜，以为建图越快越好。实际不是这回事。SLAM匹配依赖连续帧之间的重合度，转向太快或直行太猛都会导致匹配失败。我用SLAM Toolbox建图时，习惯用遥控手柄以0.2m/s左右的线速度、缓慢的角度变化走完整个房间，遇到走廊尽头还专门原地旋转几圈，把回环特征采集充分。这样建出来的地图，后期给Nav2用会顺手很多。

第三个心得是：AMCL的初始位姿不要省。很多人在启动导航时不设置initial_pose，结果AMCL粒子发散，机器人以为自己在房间外面，规划器当然算不出路径。这里有个操作习惯：每次启动导航前，在RViz里给AMCL发送一个大概的初始位姿，哪怕精度差一点都没关系，关键是先把粒子撒到正确区域附近。在扫地机上，这个“确定自己大概在哪”的动作比什么都重要。

5.3 一套调试效率提升组合拳

调试全链路时，工具链比想象中重要。我常用的三件套是RViz2、plotjuggler和ros2 topic。

RViz2用于可视化地图、代价地图、路径和粒子，是整个调试的主战场。几乎所有参数调整，我都是看着RViz2里的实时画面来决定方向。plotjuggler则用来查看里程计、IMU、cmd_vel这些数值信号的时序曲线。有一次导航抖动，我就是在plotjuggler里发现里程计的线速度曲线有高频毛刺，才知道是轮子打滑，而不是规划器的问题。ros2 topic主要用于检查话题频率和数据接口，比如用ros2 topic hz /scan去确认雷达话题有没有掉频。

调试顺序上，我的习惯是先验证数据流。依次检查D435点云频率、scan话题频率、TF树是否无缺失、SLAM是否正常建图。链路每一步都有明确的话题和日志输出，哪一步断了看哪一步。等数据流全通了，再开始调Nav2的行为树和规划参数。这样分段排查，能避免把问题混在一起。

5.4 从单机到量产：还有哪些坑在等你

如果只是做一台原型机，上面的内容已经够用。但如果你想把方案往量产方向推，还有几个坑要提前考虑。

第一个是硬件一致性。一个型号的扫地机，不同批次传感器的安装角度、离地高度可能有微小差异，这个差异在建图上会累积成地图旋转误差。量产方案一定要做产线标定，把激光和相机相对机器人本体的外参固化成标定流程。

第二个是异常恢复策略。量产设备不能被用户搬起来之后就一直卡在一个死循环里，需要有一套异常检测逻辑：比如加速度计检测到被抬起来的时间超过一定阈值，就自动触发全局重定位。这个逻辑Nav2默认没有，必须自己在行为树里加。

第三个是算力余量。我在调试时用PC跑的，到了嵌入式板卡上，D435点云加上Nav2全局规划，CPU开销非常可观。嵌入式平台建议把深度相机的分辨率进一步降低，点云降采样leaf_size调到0.05米，Nav2的costmap更新频率从10Hz降到5Hz。整套方案能跑起来的前提是，单核性能足够扛住点云处理，不然你就只能老老实实换更轻量的2D雷达方案。

最后一个我想说的体会是：SLAM和Nav2的链路看起来很长，但真正决定成败的，往往不是算法本身，而是数据的一致性。传感器帧率是否稳定、坐标系是否发布正确、点云滤波参数是否匹配硬件特性，这些“不起眼”的细节才是让整个系统从能跑变成跑得好的关键。如果你在调试中也被某些诡异问题卡了很久，不妨先放下算法参数，回去检查一遍数据链路的质量。