1. 为什么要专门做“纯定位”建图模式根本不想让你长期跑1.1 建图模式下定位的隐性问题很多朋友第一次接触 Cartographer 的纯定位模式都是因为同一个困惑明明我在建图模式下也能看到机器人位置在变化雷达点云能对上为什么还要单独搞一个“纯定位”出来这个问题的答案藏在 Cartographer 内部的两条工作线上。建图模式下前端Local SLAM负责把每一帧点云跟当前子图匹配输出高频位姿后端Global SLAM负责在后台做闭环检测和全局优化不断修正子图之间的相对位姿。后端一跑全局优化地图就会跟着动轨迹也会被修正。这是建图模式的正常工作方式但放在“长期部署”场景里问题就来了。首先是地图会持续膨胀。机器人每走一段没去过的地方前端就会创建新子图后端不断积累新的约束。跑一天仓储环境内存占用轻松涨到几个GB。其次是定位结果会被“未来”影响。后端优化是一批约束一起算的上一秒发布的位姿下一秒可能被后端整体调整掉这在导航系统看来就是“定位突然跳了一下”。对导航控制来说位姿抖动比位姿有固定偏差更致命。更麻烦的是建图模式下没有“地图不可变”这个概念。机器人长时间运行雷达对同一个位置反复扫描如果遇到玻璃墙、反光地砖这种退化场景前端匹配可能把新子图钉在错误位置上而后端会把这个错误当成真实约束加入优化图最后把整个地图拉变形。这个过程的可怕之处在于它不是一次性失败而是随着运行时长慢慢腐化等发现时地图已经没法用了。1.2 纯定位模式的本质把“建图”和“定位”拆成两件事Cartographer 的纯定位模式做的事情可以用一句话概括加载一份已经建好的、不再变化的 3D 点云地图pbstream新启动的轨迹只做“匹配定位”不往全局地图里塞新内容。具体到代码层面当你用load_state_filename参数加载 pbstream 时Cartographer 会把文件里的所有轨迹标记为 frozen冻结。冻结轨迹意味着这些轨迹对应的子图是只读的不参与任何地图更新但它们在位姿图优化中仍然扮演锚点角色。新轨迹进入系统后local SLAM 照常做 scan-to-submap 匹配产生高频位姿global SLAM 后台则会把新轨迹的子图和冻结轨迹的子图做闭环匹配用这些约束把新轨迹“钉”在已有地图上。这个过程依然触发了后端优化但优化的核心不是修正地图本身而是修正“新轨迹在旧地图里的相对位姿”。所以地图是死的位姿是活的。这就是纯定位模式和数据回放做定位的本质区别——数据回放只是把保存的轨迹发出来纯定位是实时匹配、实时输出。这也是为什么纯定位模式必须同时准备两样东西一份高质量的 pbstream 地图以及一套跟建图时完全一致至少高度一致的传感器配置和 TF 树。地图质量决定定位精度上限配置一致性决定你能否稳定复现这个精度。1.3 判断你的项目是否真的需要纯定位不是所有场景都需要纯定位。我的判断标准很简单机器人只在已建图区域内运行地图不需要变化就需要纯定位。机器人会长期、反复探索新区域且地图需要持续更新就别用纯定位老老实实做在线建图加定期保存地图。如果只是做技术验证跑一段 bag 看效果也不必大动干戈直接在建图模式下跑关闭地图更新即可。用 3D 雷达机械式多线雷达或固态雷达的场合纯定位模式尤其有价值。因为 3D 点云数据量是 2D 的几十倍后端优化压力非常大在线长期建图对工控机的 CPU 和内存都是折磨。把建图和定位拆开建图阶段可以在高性能机器上离线做定位阶段用一台普通工控机就够了。2. 纯定位模式的软件版本与地图数据基础2.1 版本选择为什么我推荐确认这几个 commitCartographer 的版本演进里纯定位相关的改动比大多数人想象得多。2020 年之前的版本加载 pbstream 后新轨迹的初始位姿经常跳变要手动设置一个比较接近的初始值才能收敛。后来官方做了一次比较大的重构把MapBuilderInterface的轨迹管理逻辑理顺了加载地图后的重定位稳定性明显改善。我的建议是不要直接用最新 master也不必用最早的老版本。选择你 ROS 发行版官方仓库里带的版本比如 ROS Noetic 的 1.0.0或者选择 2021 年之后、commit 相对稳定的某个 release 分支。因为 Cartographer 的代码质量很高但上游更新频率不高社区维护的 patch 往往更贴近实际部署场景。纯定位模式相关的核心接口主要涉及这几块MapBuilder::AddTrajectoryBuilder新建轨迹时根据参数决定是否冻结已有轨迹MapBuilder::LoadState加载 pbstream并设置严格一致性检查TrajectoryBuilderInterfacelocal SLAM 前端的接口定义。如果你要二次开发比如把纯定位模式嵌入自己的调度系统这几个接口是绕不开的。建议在动手前先读一遍map_builder.cc里LoadState的实现理解 frozen 轨迹在 PoseGraph 里是怎么被处理的这对后续排查定位跳变问题非常有帮助。2.2 pbstream 不只是点云地图文件里到底装了什么很多人误以为 pbstream 就是一张点云图其实点云只是它的表象。pbstream 的完整内容可以拆成这样几层数据层内容在纯定位中的作用子图集合每个子图的点云、匹配体素栅格单元提供 local 匹配的基准轨迹数据每条轨迹的节点位姿、子图位姿提供全局坐标基准约束关系子图间、节点与子图间的匹配约束保证地图内部刚性传感器标定信息激光与 IMU 外参、重力方向参考保证新轨迹能对齐这意味着你加载一份 pbstream 时不只是“加载了一张地图”而是加载了一个完整的位姿图状态。新轨迹的每一个节点都要跟这个位姿图里的子图做匹配形成新的约束。这也是纯定位模式比“ICP 配准点云”类方案更稳定的原因它同时利用了局部几何特征和全局拓扑约束而不是单纯做帧到模型的匹配。我在实际项目里有一个体会pbstream 的质量决定纯定位能用多久。一份由长时间建图、包含大量闭环约束的地图即使局部点云稀疏一点定位也能靠约束撑住。反之一份只跑了五分钟、没有闭环的“快餐地图”在定位时稍微走远一点就开始飘。2.3 录制 bag 和建图的预处理建议既然地图质量决定定位上限那建图阶段的预处理就得认真对待。这里分享我的标准操作流程使用 rosbag 录制原始数据不做任何在线滤波。录制内容包括点云话题、IMU 话题、里程计话题如果有。录制时确保雷达转速稳定、IMU 采样率不低于 200Hz典型 3D 雷达搭配的 IMU 都是这个量级。离线建图优先。把 bag 放到性能足够的机器上跑建图开use_online_correlative_scan_matching3D 模式下通常设为 false2D 才常用。建图过程不要急走完所有需要覆盖的区域关键拐角处放慢速度让前端有足够的时间积累视差。检查轨迹和闭环质量。建图完成后在 Rviz 里打开轨迹和子图重点看拐角、走廊尽头这些位置有没有明显错层。如果地图有分层定位大概率会在对应区域跳变。这时回到第 2 步重新建图或者裁剪掉出问题的轨迹段再保存。保存地图# 结束编号为0的轨迹 rosservice call /finish_trajectory 0 # 等待几秒让后端处理完剩余约束 sleep 5 # 保存地图 rosservice call /write_state {filename: /home/user/maps/industrial_3d_map.pbstream, include_unfinished_submaps: false}注意include_unfinished_submaps这个参数。如果设为 true会把还没完成匹配的子图也写进地图地图面积更大但边缘位置约束不完整。定位模式下我不建议这么做设 false 更干净。3. 3D 纯定位的 launch 与 lua 配置逐项拆解3.1 配置主体框架加载 pbstream 和关闭“在线建图”纯定位模式的 launch 文件核心就是一个cartographer_node加上一个cartographer_occupancy_grid_node如果你要在 Rviz 里看 2D 栅格。先看一个典型的 3D 纯定位 launch 骨架launch node namecartographer_node pkgcartographer_ros typecartographer_node outputscreen param nameconfiguration_directory value$(find my_robot_config)/config / param nameconfiguration_basename valuemy_robot_3d_localization.lua / !-- 加载已有地图这是纯定位模式的入口 -- param nameload_state_filename value$(find my_robot_config)/maps/industrial_3d_map.pbstream / !-- 3D雷达点云话题 -- remap frompoints2 to/rslidar_points / remap fromimu to/imu/data / remap fromodom to/odom / /node node namecartographer_occupancy_grid_node pkgcartographer_ros typecartographer_occupancy_grid_node outputscreen remap frommap to/map / /node !-- TF 静态变换如果激光雷达和 base_link 之间有固定外参 -- node pkgtf2_ros typestatic_transform_publisher namebase_to_laser args0 0 0.5 0 0 0 base_link rslidar / /launch这份配置的关键一点都不在 launch 文件本身而在于load_state_filename。只要这个参数被设置了Cartographer 启动时就会先加载 pbstream然后以“已有地图新轨迹”的方式运行——这就是纯定位模式。如果没设置这个参数同样的 lua 配置会跑成一个在线建图节点所以千万别搞混。从 Cartographer 1.0 之后官方并不要求单独设置pure_localization true这样的参数。模式切换完全由“是否加载地图”决定。很多新手在网上看到老教程里写了一个pure_localization参数找了半天找不到其实就是这个原因。3.2 3D 雷达传感器参数点云话题、体素滤波和坐标粘贴3D 纯定位模式下num_point_clouds通常设为 1表示只接收一个点云话题。这里有一个细节Cartographer 的 3D 前端对点云有一个要求——点云必须是“去畸变”的。但 Cartographer 自身不去畸变它依赖雷达驱动去畸变或者依赖你离线把点云处理好。如果你用的是速腾、禾赛这类国产雷达驱动里通常自带运动畸变去除选项。定位模式下建议开启。别小看这个参数畸变未去除的点云在机器人转弯时会明显“拖尾巴”纯定位的 scan-to-submap 匹配会对这种系统性变形非常敏感表现为定位偶尔跳一下又回来。lua 配置里跟点云相关的核心参数options { -- 必须与 launch 里 remap 对应 num_point_clouds 1, -- 雷达坐标系 tracking_frame base_link, -- 发布频率定位模式下可以降低节省CPU pose_publish_period_sec 0.005, trajectory_publish_period_sec 0.03, }tracking_frame这个名字经常让人疑惑它并不是“跟踪坐标系”而是“位姿追踪坐标系”。在 3D 模式下Cartographer 内部做 scan-to-submap 匹配时会自动把点云从雷达坐标系变换到 tracking_frame通常是 base_link。如果你的雷达安装在 base_link 的正上方且不做大角度旋转直接设tracking_frame base_link没问题如果雷达和 base_link 之间有较大外参需要提供静态 TF。3.3 local SLAM 和 global SLAM 在定位模式下的角色差异我见过很多人对纯定位模式的理解是关闭建图只跑匹配。这个理解只说对了一半。实际上 Cartographer 纯定位模式下local SLAM 依然会创建子图——只不过这些新子图不会影响已有地图它们只作为临时局部参考用于生成高频位姿。这么说吧local SLAM 前端依然接收点云构建新的 local submap对当前扫描帧和 local submap 做匹配输出高频帧位姿。global SLAM 后端不用来做“地图大规模优化”而是专门做“新轨迹与冻结轨迹的约束”。当机器人走到已有地图的某个区域时后端会尝试把新轨迹的节点与冻结的子图做匹配scan-to-map形成全局修正。理解这个机制的价值在于当你在 lua 里调global_sampling_ratio这个参数时你调的不是“定位的准确性”而是“新轨迹和旧地图之间做闭环检测的频率”。调高它定位更稳但 CPU 占用量上升调低它CPU 更省但长走廊等区域容易累积漂移。我常用的经验值是3D 纯定位模式下global_sampling_ratio设在 0.03 左右能平衡 CPU 和稳定性。你可以跑一段 bag 试调看 Rviz 里连接新旧轨迹的约束线是否连续。3.4 常用调参清单下面这个表格是 3D 纯定位模式最值得调的参数按优先级排列参数建议值作用use_imutrue3D 定位必须开IMU 提供重力方向use_odometrytrue有轮式/视觉里程计就开能大幅提升抗退化能力global_sampling_ratio0.03控制全局匹配频率pose_publish_period_sec0.005控制位姿发布频率200Hz 对导航足够submap_publish_period_sec0.3只在 Rviz 里看效果时影响不大可适当增大num_subdivisions_per_laser_scan13D 点云一般不需要细分min_range/max_range根据雷达型号过滤过近/过远的点一定要跟建图时一致use_online_correlative_scan_matchingfalse3D 模式下通常关闭省资源关键提醒min_range和max_range在定位模式里必须和建图时完全一致。如果建图时用了 0.5~100m 范围定位时改成 0.2~80m点云的几何分布变了匹配结果会系统性偏移。这个坑我踩过一次查了很久才发现是范围参数不一致导致的定位偏差。4. 从零到定位跑通完整命令行与流程4.1 启动节点加载三维地图假设你已经准备好了industrial_3d_map.pbstream完整的启动流程大概是这样的# 终端1启动雷达驱动 roslaunch rslidar_sdk start.launch # 终端2启动IMU驱动如果需要 roslaunch my_robot imu.launch # 终端3启动cartographer纯定位节点 roslaunch my_robot_config localization_3d.launch # 终端4启动Rviz查看效果 rviz -d $(rospack find cartographer_ros)/configuration_files/demo_3d.rviz启动之后Rviz 里应该能看到三样东西一个 2D 的map话题来自cartographer_occupancy_grid_node、3D 点云子图来自submap_list、以及机器人的 track 轨迹。如果你发现map话题是空的大概率是cartographer_occupancy_grid_node没有正确订阅到子图数据。检查一下它的submap_list话题是否跟cartographer_node的输出了话题名一致。这个问题经常出现在改了 node 命名空间之后。4.2 TF 树的建立map、odom、base_link 和雷达坐标系的关系纯定位模式下 TF 树长这样map - odom - base_link - rslidarmap到odom由 Cartographer 内部维护表示“全局位姿修正的漂移量”。这个变换会在线更新。odom到base_link如果provide_odom_frame true由 Cartographer 发布否则由你的里程计节点发布。base_link到rslidar静态变换由你负责提供通常在 launch 里写死。有一个常见误区很多新手试图自己给map - odom发一个静态变换这会把定位功能完全废掉。map - odom必须由 Cartographer 发布并且是动态的。如果你在 rqt_tf_tree 里看到多个节点都在广播这个变换TF 会频繁切换定位会表现为“机器人模型在 Rviz 里抖动”。纯定位模式对 TF 时间的同步要求也很严。lookup_transform_timeout_sec默认 0.2 秒如果你的 TF 树里某个环节延迟过高比如 IMU 驱动和雷达驱动跑在不同机器上Cartographer 会频繁打印Transform timed out警告点云被丢弃。遇到这种情况优先检查网络延迟而不是盲目调大超时。4.3 初始位姿不发布会怎样怎么发布启动纯定位节点后Cartographer 对新轨迹的初始位姿默认是(0,0,0)。如果你的机器人实际不在这个位置附近local SLAM 的匹配收敛不到正确解上定位会一直“飘着”甚至直接报Unchanged 100 scans这种重复匹配失败的警告。解决方式是通过/initial_pose话题发布一个大概的初始位姿rostopic pub /initial_pose geometry_msgs/PoseWithCovarianceStamped header: frame_id: map pose: pose: position: x: 5.0 y: 3.0 z: 0.0 orientation: w: 1.0 covariance: [0.25, 0, 0, 0, 0, 0, 0, 0.25, 0, 0, 0, 0, 0, 0, 0.25, 0, 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0, 0, 0, 0.01, 0, 0, 0, 0, 0, 0, 0.01] -1这个位姿可以从 Rviz 的2D Pose Estimate工具直接获取跟 AMCL 的初始定位类似。区别在于 Cartographer 的/initial_pose只在新轨迹启动后的窗口期内监听如果你启动节点超过了十几秒才发布可能不会生效。稳妥的做法是在 launch 文件里用roslaunch的arg传入初始坐标让节点启动瞬间就设置好。初始位姿的精度不需要太高纯定位模式通常能在 1~2 秒内通过 scan-to-map 匹配收敛到位姿差半米以内的状态。但如果初始位姿偏离超过 3 米收敛就非常困难建议手动校准后再启动。4.4 验证定位是否正常判断纯定位是否真的“定位上了”不要只看 Rviz 里点云对上没。我推荐按这四步验证看/tracked_pose话题如果位姿以 100Hz 以上稳定发布且没有长时间中断前端匹配是活的。看退化检测Cartographer 输出日志里的Scan match residual这个值突然变大说明当前帧和子图匹配不上可能是走到了地图没覆盖的区域。推一推机器人或用手转一圈雷达看 Rviz 里 base_link 和点云的相对关系是否跟着动。如果机器人动了但地图里的位姿不动说明 TF 树有问题。折返跑让机器人沿原路折返回起点时看位姿偏差。如果偏差超过 10cm说明定位在后端约束上还有问题需要回看全局匹配频率。5. 3D 定位实测中的问题排查链路踩坑实录5.1 点云坐标粘贴导致的重影和“假定位”这是我做第一个 3D 纯定位项目时踩的坑。现象是启动定位节点后Rviz 里点云看起来和地图高度重合但机器人实际前进时位姿更新明显滞后停下来后位姿还会倒退一段。排查链路是这样的先看/tracked_pose时间戳和点云时间戳发现点云时间戳比位姿时间戳旧了大约 0.5 秒疑点落在雷达驱动。再看 TF 树base_link - rslidar的静态变换没问题。最后直接打印点云的received time发现雷达驱动把时间戳打成了“雷达内部时钟”和主机上的 ROS 时钟差了老远。问题根源就是雷达驱动或你的采集脚本给点云打了错误的header.stamp。Cartographer 内部会用位姿时间戳索引点云帧时间戳错位直接导致“地图坐标粘贴在错误的位姿上”表现就是重影和假定位。这个问题的修复方式很简单在雷达驱动里校准时间戳保证点云时间戳是主机时钟。但如果你的系统里有多台机器跨网络运行记得用 PTP 或 NTP 做时钟同步。Cartographer 对时间同步的容忍度极低这是 3D SLAM 系统的通病不是 Cartographer 独有的要求。5.2 运动畸变和去畸变配置差异有过一个项目定位模型在静态环境下精度极高但机器人一跑起来就频繁“找不回去”误差在 20~30 厘米之间来回跳。排查到后面发现建图时用的 bag 是离线录制的离线建图时雷达驱动开了去畸变但定位时是实时跑雷达驱动的去畸变选项被某次参数整理时不小心关掉了。这个问题的本质是Cartographer 的 3D 前端假设点云帧内没有运动畸变或者说畸变已经被驱动去除一旦假设被打破匹配就会产生系统误差。机械式雷达每帧扫描需要 50~100ms这期间机器人运动产生的畸变不可忽略。排查方法很简单把实时定位时收到的点云 dump 下来和建图时同一场景的点云对比看边缘有没有明显的“拖尾”。如果拖尾明显检查雷达驱动的去畸变开关。5.3 回环与退化环境长走廊、玻璃墙、动态遮挡3D 纯定位在开阔环境停车场、厂房、货架区表现很好但在几类退化场景下会出问题长走廊沿走廊方向没有足够几何约束local SLAM 会沿走廊方向漂移但垂直方向约束很强所以定位表现为“方向正确但里程越走越偏”。玻璃墙和镜面雷达点打到玻璃上要么丢失要么产生多径反射地图上会形成一大片“假点”。这些假点不参加匹配还好一旦匹配到了会造成局部错位。动态人车如果你的定位环境里经常有叉车、行人在雷达附近经过它们会把局部点云“污染”。Cartographer 没有内置动态物体滤除完全靠匹配的鲁棒性硬扛。这些退化场景的解法不是一个参数能搞定的我的建议是分层处理硬件层在多线雷达之外加一个短距 2D 雷达辅助定位。Cartographer 支持同时接收 3D 点云和 2D scan两路数据互补。长走廊场景下2D 雷达在底部提供的扫射约束往往比 3D 点云更稳定前提是 2D 雷达的地图是可靠的。配置层max_range不要设太大把玻璃墙外那些远距离噪声点挡在外面。同时适当提高global_sampling_ratio让后端在退化区域更频繁地“拉一把”新轨迹。软件层在纯定位之外跑一个轻量的点云滤波节点如通过半径离群点滤波剔除稀疏噪点输出滤波后的点云给 Cartographer。5.4 定位丢失后的自恢复与重定位触发即使配置再好定位也不是永远不丢。目前 Cartographer 纯定位模式没有内置的“丢失自恢复”机制——它没有一个像 AMCL 那样的主动粒子重定位阶段。定位一旦发散基本只能重启新轨迹。但你可以把“重启新轨迹”做成一个自动化流程。具体做法在系统里监听 Cartographer 的匹配残差和轨迹节点的时间戳新鲜度当连续 N 帧匹配残差超阈值或者轨迹节点的更新时间超过某个阈值就通过 service 调用新建一条轨迹来重新初始化rosservice call /start_trajectory options: ...这里有个经验在调用start_trajectory前先用你上一次有效位姿或导航系统给出的大致位姿做initial_pose成功率会高很多。如果完全盲发新轨迹很可能也匹配不上因为 3D 点云的匹配窗口有限不像 2D 那样容易碰运气。在新轨迹成功匹配并稳定几秒后再调用finish_trajectory结束旧轨迹。实际项目中这个自动恢复逻辑挽救了无数次“深夜机器人卡死”事故。6. 长期运行中的稳定性与性能调优6.1 计算资源预算local SLAM 实时性与多线程消耗3D 纯定位对 CPU 的消耗比很多人想象的高。实测下来一个 32 线机械雷达、10Hz 点云输入、开了 IMU 融合的定位任务Cartographer 在工控机上大约消耗 2~3 个完整核。如果你的系统还要跑导航、感知、调度CPU 预算要提前规划好。Cartographer 的线程模型是map_builder的后端优化跑在一个独立线程里local SLAM 匹配跑在另一个线程数据分发和订阅占用一个线程occupancy_grid_node 还要额外线程。优化的思路是定位模式下降低不必要的发布频率。pose_publish_period_sec从默认 5ms 改到 10ms 对定位几乎没有影响但能减少下游节点的压力。trajectory_publish_period_sec从 30ms 改到 100msRviz 里的轨迹更新频率降低但不影响定位精度。submap_publish_period_sec从 0.3 改到 1.0能省不少可视化带宽。6.2 内存和 pbstream 的裁剪策略长期运行下内存占用主要来自两部分新轨迹的子图数据和位姿图的约束数据。如果你只在固定区域做来回运动这些数据不会无限增长因为新轨迹节点在同一个局部区域内会不断被合并进已有约束不会无限膨胀。但如果机器人会在整个园区不停穿梭新轨迹覆盖的区域越来越大内存会持续上涨。一个可行的策略是定期比如每 2 小时调用finish_trajectory和start_trajectory把当前轨迹截断重新开一条新轨迹。这不会影响定位因为新轨迹会自动跟冻结地图匹配。另外pbstream 文件本身也可以裁剪。如果建图时不小心把路线尽头的一条死路也建进地图那些子图对定位没任何帮助却会让LoadState时间变长。我建议有空的时候用 Cartographer 自带的cartographer_pbstream工具或写个小脚本把 pbstream 里的轨迹按空间范围裁剪掉减少加载时间。6.3 多雷达融合和低退化风险的传感器配置思路如果你的预算允许我非常推荐在 3D 雷达之外加一个 2D 激光。Cartographer 的num_laser_scans和num_point_clouds可以同时大于 0并且 2D 和 3D 的匹配结果会共同约束同一帧位姿。实际做下来2D 3D 的双传感器融合在长走廊场景的定位精度提升非常明显。原因是 2D 雷达在贴近地面、扫描范围较小几何约束更“硬”不容易被走廊方向拉松。当然代价是配置复杂度上升你需要额外维护一套 2D 雷达的外参标定并且建图时也要同时录制 2D 雷达的数据。对于固态雷达这类视场角受限的传感器纯定位模式还有另一个注意点尽量安装时让它朝向定位区域内信息量最丰富的方向。3D 雷达的视场角受限意味着某个方向可能长期没有点云如果那个方向恰好是机器人导航的主要方向定位会在接近前进方向时缺少约束导致“越开越偏”。7. 写在最后的长期运维心得聊了这么多配置和排错最后分享一点我从项目维护角度总结的心得。纯定位模式最容易被忽视的是“地图生命周期管理”。地图不是建一次就永远不变的。厂房改造、货架位置调整、墙面装饰变化都会让旧地图和现实环境逐渐脱节。我见过不少项目在部署初期定位精度很好跑了半年后开始频繁跳变最后排查发现是环境变了地图却没更新。我的做法是在系统里加一个简单的“环境漂移监控”模块。定期统计定位过程中 scan-to-map 匹配的残差分布如果长期运行中残差均值缓慢上升就提醒运维人员重新建图或对局部环境重新扫描更新。这个模块不需要多复杂一个 Python 脚本订阅/tracked_pose和点云话题就能算出来但对长期稳定性非常有用。另外纯定位模式的日志一定要保留。Cartographer 的日志信息量很大很多问题通过日志就能一眼定位——比如Truncated、Unchanged、Transform timed out每个关键词都是一个故障类型的指纹。运维团队拿到日志就能判断是传感器问题、驱动问题还是配置问题不需要每次都远程拉实时数据。希望这篇分享能帮你少走一些弯路。做 3D 纯定位这件事本身不难难的是把每一个细节都做扎实。地图质量、传感器标定、参数一致性、时间同步这四件事做好了定位自然就稳了。