项目已开源到GitHub欢迎Starhttps://github.com/Ikunio/Lidar_nav2_wshttps://github.com/Ikunio/Lidar_nav2_wsNav2 跑不起来真不一定是算法问题我用一棵 TF 树接通了 LIO、重定位和导航很多人第一次调 Nav2 的时候都会经历一个经典阶段机器人不动怀疑 Nav2。机器人乱动怀疑 DWB。地图飞了怀疑 FAST-LIO。RViz 一片红开始怀疑人生。但我后来发现很多时候问题并不在算法本身。不是 FAST-LIO 不行。不是 Point-LIO 不行。也不是 Nav2 看你不顺眼。真正的问题可能只有一个TF 树没接对。在 ROS 2 机器人系统里TF 就像机器人的“族谱”。谁是爸爸谁是儿子谁负责发布谁的变换一旦乱了机器人就会出现各种玄学症状RViz 里机器人原地漂移Nav2 一直等待 transform路径规划正常但机器人就是不走重定位成功了但导航还是像喝多了一样LIO 明明输出了位姿Nav2 却完全不买账。这篇文章就围绕我开源的Lidar_nav2_ws项目讲清楚一个入门阶段非常容易踩坑的问题如何用一棵标准 TF 树把 LIO 里程计、3D 点云重定位和 Nav2 导航真正接起来。一、先说结论Nav2 不是要“一个位姿”而是要“一套关系”很多初学者刚接触 Nav2会有一个误区我已经有 LIO 位姿了为什么 Nav2 还不能跑这句话表面看没问题但实际少了一半。Nav2 不只是要你告诉它机器人现在在哪里它更关心的是机器人在 odom 里怎么动 odom 在 map 里怎么偏 雷达在底盘上的位置是多少 底盘中心到底是谁也就是说Nav2 要的不是一个孤零零的坐标而是一整棵 TF 树。在我的项目中核心 TF 树是map └── odom └── base_footprint └── chassis └── livox_frame这棵树看起来很简单但每一层都有明确分工。如果你把它接反了Nav2 可能不会立刻报错但它会用非常抽象的方式提醒你我不知道我是谁。我不知道我在哪。我不知道我要去哪。我知道你很急但你先别急。二、这几个坐标系到底是谁先把几个核心 frame 讲清楚。1.mapmap是全局地图坐标系。你可以理解成机器人世界里的“地球坐标系”。它通常来自2D 栅格地图3D 先验点云地图SLAM 建图结果重定位系统。map是全局稳定的。机器人从哪里开机不重要只要重定位成功它最终都应该知道自己在map里的位置。2.odomodom是局部里程计坐标系。它的特点是短时间连续、平滑但长期可能会漂。LIO 输出的位姿本质上更接近里程计。它适合描述机器人短时间内怎么运动例如我向前走了 1 米 我左转了 30 度 我又漂了一点但是我不说所以 LIO 更适合维护odom → base_footprint而不是直接硬塞成map → base_footprint因为 LIO 会漂map不应该跟着它一起漂。3.base_footprintbase_footprint是机器人底盘在地面上的投影中心。对 Nav2 来说它通常比base_link更友好。为什么因为导航关心的是机器人在地面上怎么走xyyaw。它通常不关心机器人因为地面不平产生的 roll 和 pitch。所以在移动机器人导航里base_footprint常常作为 Nav2 的核心底盘 frame。你可以把它理解成机器人贴在地面上的影子。Nav2 真正规划的是这个“影子”怎么在地图上移动。4.chassischassis是机器人真实底盘结构坐标系。它可以和base_footprint重合也可以有一个固定变换。比如base_footprint → chassis这个变换通常是静态 TF。它表示底盘结构中心相对于地面投影中心在哪里。5.livox_framelivox_frame是 Livox MID-360 雷达坐标系。它通常挂在底盘上chassis → livox_frame这个变换也是静态 TF。这一步非常关键。因为点云是雷达坐标系下的如果 Nav2 或重定位系统不知道雷达安装在哪里它看到的点云就像一个人戴反了眼镜墙在前面它以为墙在屁股后面。门在左边它觉得门在天上。然后你开始怀疑算法。三、LIO 输出的不是 Nav2 想要的“标准底盘里程计”FAST-LIO / Point-LIO 本身是很强的 LiDAR-Inertial Odometry 算法。但要注意LIO 的输出是为了估计 LiDAR/IMU 的运动不是为了直接伺候 Nav2。很多 LIO 系统内部会有自己的坐标命名例如camera_init body aft_mapped lidar imu这些坐标系在 LIO 算法内部很正常但 Nav2 不认识这些“黑话”。Nav2 更喜欢的是map odom base_footprint base_link laser所以问题来了LIO 输出的camera_init → body不能直接当成 Nav2 的odom → base_footprint用。这就像你拿着一份英文论文去问食堂阿姨今天有什么菜。不是对方能力不行是接口语言不一致。因此我在项目中加了一层桥接逻辑把 FAST-LIO / Point-LIO 输出的内部位姿转换成 Nav2 更能理解的标准里程计关系odom → base_footprint这一步的意义非常大。它让上游 LIO 算法可以自由切换而下游 Nav2 完全不用关心你今天用的是 FAST-LIO 还是 Point-LIO。四、一棵正确的 TF 树应该谁发布谁这部分是重点。一个比较清晰的分工应该是map → odom 由重定位模块发布 odom → base_footprint 由 LIO 桥接模块发布 base_footprint → chassis 由静态 TF 发布 chassis → livox_frame 由静态 TF 发布展开来看就是map └── odom ← 3D 重定位维护 └── base_footprint ← LIO 里程计维护 └── chassis ← 机器人结构静态 TF └── livox_frame ← 雷达安装外参静态 TF为什么要这样拆因为每一段的物理意义不同。odom → base_footprint回答“我短时间怎么动了”这一段由 LIO 负责。LIO 的优势是短时间连续运动估计。它可以高频输出机器人运动状态。例如机器人从 odom 原点出发 向前走了 2 米 左转 45 度 再向前走 1 米这部分运动是连续、平滑的很适合给 Nav2 做局部控制和速度规划。map → odom回答“我的里程计整体偏到哪里去了”这一段由重定位模块负责。为什么不直接让重定位发布map → base_footprint因为这样会把全局校正和局部运动混在一起。比较好的做法是map → odom由重定位不断修正 odom 在 map 中的位置。这样一来LIO 继续负责局部连续运动重定位负责全局纠偏Nav2 看到的是一条完整、连续、可解释的 TF 链。这就是map → odom → base_footprint的核心意义。五、千万别让两个节点同时发布map → odom这是一个非常经典的坑。有些人会同时启动AMCLSLAM Toolboxsmall_gicp 重定位KISS-Matcher 重定位自己写的 map_to_odom 发布器。然后系统里同时出现多个节点发布map → odom这时候 TF 树就开始精神分裂。一个节点说odom 在 map 左边 1 米另一个节点说不对odom 在 map 右边 3 米第三个节点说你们都错了我觉得它在楼上最后 Nav2 看着这群人吵架默默选择罢工。所以原则非常简单同一时间只能有一个模块负责发布map → odom。如果你用 small_gicp 重定位就让 small_gicp 发布。如果你用 KISS-Matcher small_gicp就让它发布。如果你用 AMCL就别再启动另一个 map_to_odom 发布器。map → odom是全局定位权威。权威可以换但不能一群人同时当皇帝。六、为什么我的项目要做 LIO 桥接在Lidar_nav2_ws中我希望实现一个目标上游 LIO 算法可以切换下游 Nav2 接口保持不变。也就是说今天我用 FAST-LIO明天我换 Point-LIONav2 不应该感知到变化。Nav2 不应该关心你上游是 FAST-LIO 你上游是 Point-LIO 你的原始话题叫 /Odometry 还是 /aft_mapped_to_initNav2 只应该看到标准接口/odom odom → base_footprint /registered_scan所以中间必须有一层接口转换。这层桥接模块主要做几件事接收 LIO 原始里程计把 LIO 内部坐标系转换到底盘坐标系发布标准的odom → base_footprint发布标准/odom输出后续重定位和点云切片需要用的/registered_scan。这样做之后系统就变成了FAST-LIO / Point-LIO ↓ LIO Interface ↓ 标准 odom 与 TF ↓ 重定位 Nav2这就是工程系统里非常重要的一件事算法可以换但接口要稳定。否则你每换一个 LIONav2 配置、TF、话题、重定位模块都要跟着改。那不是机器人系统那是大型连连看。七、初学者最容易犯的 5 个 TF 错误下面这些错误我建议直接贴在桌面上。错误 1把 LIO 的原始坐标系直接当成odom很多 LIO 输出的是算法内部坐标关系。比如camera_init → body这类关系。它不一定等价于odom → base_footprint你需要确认原点在哪里旋转方向是否一致body 是 IMULiDAR还是底盘是否已经补偿了雷达到底盘的外参不要看到一个 odometry 就直接喂给 Nav2。这就像看到一个轮子就说自己造了辆车。错误 2base_link、base_footprint、chassis混用这三个 frame 很容易混。一般可以这样理解base_footprint机器人在地面上的投影中心 base_link机器人本体坐标系 chassis具体底盘结构坐标系如果你的系统主要是平面导航Nav2 更常用base_footprint。如果你把 Nav2 参数里写的是base_footprint但 TF 里只有base_link那 Nav2 就会很委屈你说你有底盘但我找不到。错误 3雷达外参写错雷达安装外参一般是chassis → livox_frame如果这个静态 TF 写错点云就会整体错位。典型现象障碍物位置不对地图和现实不重合机器人以为自己旁边有墙实际前方有障碍但 costmap 没反应RViz 里点云像被人拧了一下。这时候不要急着骂点云算法。先检查雷达安装 TF。错误 4重复发布map → odom这个前面已经讲过。一句话map → odom只能有一个权威发布者。不要让 AMCL、SLAM Toolbox、small_gicp、KISS-Matcher 同时抢这个位置。不然 TF 树会变成宫斗剧。错误 5TF 时间不同步有些错误不是坐标错而是时间错。典型报错包括Lookup would require extrapolation into the future Lookup would require extrapolation into the past常见原因仿真时use_sim_time没统一部分节点用系统时间部分节点用仿真时间TF 发布频率太低传感器消息时间戳异常。如果是仿真就统一用仿真时间。如果是实机就不要让某个节点还活在 Gazebo 的梦里。八、如何检查自己的 TF 树调 TF 不要靠感觉。感觉在机器人面前通常不太值钱。建议直接用工具看。1. 查看 TF 树ros2 run tf2_tools view_frames或者项目中封装脚本./show_tf_tree.sh生成之后重点看map 是否连到 odom odom 是否连到 base_footprint base_footprint 是否连到 chassis chassis 是否连到 livox_frame你要看到的是一棵树不是一片森林。如果是这样map → odom base_footprint → chassis → livox_frame中间断了那 Nav2 就找不到机器人。2. 检查map → odomros2 run tf2_ros tf2_echo map odom如果你启动了重定位模块这个变换应该存在。如果不存在说明重定位没有正常发布全局校正。如果疯狂跳变说明重定位不稳定或者有多个节点同时发布。3. 检查odom → base_footprintros2 run tf2_ros tf2_echo odom base_footprint推着机器人动或者在仿真里遥控机器人走一走。正常情况下这个变换应该连续变化。如果完全不变说明 LIO 桥接没有正常工作。如果变化方向很奇怪例如机器人向前走x 没动y 在狂飙那就要检查坐标轴定义。4. 检查雷达外参ros2 run tf2_ros tf2_echo chassis livox_frame这个通常是静态的。你要确认平移是否对应实际安装位置雷达朝向是否正确z 轴高度是否合理没有把角度单位写错。角度单位写错是经典事故。你以为写的是 90 度程序以为是 90 弧度。机器人看完直接开始研究抽象艺术。九、一个比较标准的启动逻辑在我的项目里导航系统大致可以这样理解第一步启动 LIOLIO 负责估计机器人短时间运动。LiDAR IMU → FAST-LIO / Point-LIO这一步得到的是原始里程计。第二步启动 LIO 桥接桥接模块负责把 LIO 内部位姿转成 Nav2 能用的标准关系odom → base_footprint同时输出/odom /registered_scan第三步启动 3D 点云重定位重定位模块根据先验 PCD 地图对机器人进行全局定位。它负责发布map → odom这一步解决的问题是机器人开机以后怎么知道自己在地图中的哪里第四步点云转 LaserScanNav2 成熟的 2D 导航链路通常更习惯使用 LaserScan。所以系统会把 3D 点云切片生成 2D 激光数据PointCloud2 → LaserScan这一步负责让 3D LiDAR 更好地接入 2D Nav2。第五步启动 Nav2Nav2 看到的是map → odom → base_footprint以及障碍物感知数据。这时候它就可以正常进行全局路径规划局部避障速度控制到点导航。至此一套完整链路才真正闭合。十、当 Nav2 不动时先别急着调参数很多人看到 Nav2 不动第一反应是改参数。max_vel_x: 改一下 acc_lim_x: 改一下 inflation_radius: 改一下 xy_goal_tolerance: 改一下改着改着参数文件像腌咸菜一样越来越入味但机器人还是不走。我的建议是Nav2 不动先查 TF再查 topic最后再调参数。优先级应该是1. TF 是否连通 2. frame_id 是否一致 3. 时间戳是否正常 4. /scan 或点云是否正常 5. /odom 是否正常 6. Nav2 参数是否合理不要一上来就调 DWB。DWB 很冤。它只是个局部规划器不是驱魔师。十一、最小排查清单如果你也在调 ROS 2 3D LiDAR Nav2我建议按这个顺序查1. TF 树是否完整ros2 run tf2_tools view_frames必须有map → odom → base_footprint → chassis → livox_frame2. 是否只有一个节点发布map → odom检查是否同时启动了多个定位模块。如果用了 small_gicp就不要再让别的节点抢map → odom。3.odom → base_footprint是否连续变化ros2 run tf2_ros tf2_echo odom base_footprint机器人运动时这个值应该连续变化。4. 雷达 frame 是否接到底盘ros2 run tf2_ros tf2_echo chassis livox_frame雷达必须挂在机器人身上。不要让雷达成为孤儿 frame。5. Nav2 参数里的 base frame 是否和 TF 一致如果参数里写的是robot_base_frame: base_footprint那 TF 里就必须真的有base_footprint。不要参数里写一个TF 里发另一个。Nav2 不擅长猜谜。6. 时间是否统一仿真时确认所有节点use_sim_time: true实机时确认不要误开仿真时间。十二、这个设计的核心价值这套 TF 设计真正解决的是系统解耦问题。简单说LIO 管短期运动重定位管全局纠偏Nav2 管路径规划。每个模块只干自己的活不互相抢饭碗。最终形成FAST-LIO / Point-LIO ↓ odom → base_footprint ↓ small_gicp / KISS-Matcher ↓ map → odom ↓ Nav2这样设计之后系统有几个好处1. LIO 可以切换FAST-LIO 和 Point-LIO 可以根据场景切换。但对 Nav2 来说接口不变。2. 重定位算法可以切换可以用纯 small_gicpKISS-Matcher small_gicpICP 初始化方案。但它们最终都应该服务于同一个目标发布正确的 map → odom3. Nav2 不需要理解上游算法细节Nav2 不需要知道你用了什么 LIO。它只需要看到标准 TF 和传感器数据。这就是一个工程系统应该有的样子上游可以升级下游不用陪葬。十三、总结ROS 2 导航系统里TF 不是配角。它不是“随便发几个静态变换就行”的东西。它是 LIO、重定位、Nav2 之间的骨架。如果 TF 树错了再强的算法也只能在错误的坐标关系里努力表演。对于 3D LiDAR LIO Nav2 这种系统我建议初学者牢牢记住这句话LIO 负责odom → base_footprint重定位负责map → odom静态 TF 负责机器人本体结构。也就是map → odom → base_footprint → chassis → livox_frame当这棵树接通以后Nav2 才真正知道我在哪 我怎么动 我的雷达在哪 我要怎么去目标点所以下次 Nav2 跑不起来不要第一时间怀疑算法。先看看 TF 树。很多时候不是机器人不聪明。是你还没把它的“家庭关系”交代清楚。项目地址如果你也在做 ROS 2、3D LiDAR、FAST-LIO、Point-LIO、点云重定位和 Nav2 导航可以参考我的开源项目GitHub - Ikunio/Lidar_nav2_ws: 基于 Livox MID-360 3D LiDAR 的 ROS 2 自主导航工作空间集成 LIO 里程计、重定位、Nav2 导航支持仿真与实机部署。 · GitHub项目包含FAST-LIO / Point-LIO 接入LIO 到 Nav2 的 TF 桥接3D 点云转 2D LaserScansmall_gicp 重定位KISS-Matcher small_gicp 全局重定位Gazebo 仿真与实机复用Nav2 导航完整流程。如果这个项目对你有帮助也欢迎点一个 Star。毕竟开源项目最怕的不是 bug而是没人看。
Nav2 跑不起来？先查 TF 树
发布时间：2026/6/6 14:35:01
项目已开源到GitHub欢迎Starhttps://github.com/Ikunio/Lidar_nav2_wshttps://github.com/Ikunio/Lidar_nav2_wsNav2 跑不起来真不一定是算法问题我用一棵 TF 树接通了 LIO、重定位和导航很多人第一次调 Nav2 的时候都会经历一个经典阶段机器人不动怀疑 Nav2。机器人乱动怀疑 DWB。地图飞了怀疑 FAST-LIO。RViz 一片红开始怀疑人生。但我后来发现很多时候问题并不在算法本身。不是 FAST-LIO 不行。不是 Point-LIO 不行。也不是 Nav2 看你不顺眼。真正的问题可能只有一个TF 树没接对。在 ROS 2 机器人系统里TF 就像机器人的“族谱”。谁是爸爸谁是儿子谁负责发布谁的变换一旦乱了机器人就会出现各种玄学症状RViz 里机器人原地漂移Nav2 一直等待 transform路径规划正常但机器人就是不走重定位成功了但导航还是像喝多了一样LIO 明明输出了位姿Nav2 却完全不买账。这篇文章就围绕我开源的Lidar_nav2_ws项目讲清楚一个入门阶段非常容易踩坑的问题如何用一棵标准 TF 树把 LIO 里程计、3D 点云重定位和 Nav2 导航真正接起来。一、先说结论Nav2 不是要“一个位姿”而是要“一套关系”很多初学者刚接触 Nav2会有一个误区我已经有 LIO 位姿了为什么 Nav2 还不能跑这句话表面看没问题但实际少了一半。Nav2 不只是要你告诉它机器人现在在哪里它更关心的是机器人在 odom 里怎么动 odom 在 map 里怎么偏 雷达在底盘上的位置是多少 底盘中心到底是谁也就是说Nav2 要的不是一个孤零零的坐标而是一整棵 TF 树。在我的项目中核心 TF 树是map └── odom └── base_footprint └── chassis └── livox_frame这棵树看起来很简单但每一层都有明确分工。如果你把它接反了Nav2 可能不会立刻报错但它会用非常抽象的方式提醒你我不知道我是谁。我不知道我在哪。我不知道我要去哪。我知道你很急但你先别急。二、这几个坐标系到底是谁先把几个核心 frame 讲清楚。1.mapmap是全局地图坐标系。你可以理解成机器人世界里的“地球坐标系”。它通常来自2D 栅格地图3D 先验点云地图SLAM 建图结果重定位系统。map是全局稳定的。机器人从哪里开机不重要只要重定位成功它最终都应该知道自己在map里的位置。2.odomodom是局部里程计坐标系。它的特点是短时间连续、平滑但长期可能会漂。LIO 输出的位姿本质上更接近里程计。它适合描述机器人短时间内怎么运动例如我向前走了 1 米 我左转了 30 度 我又漂了一点但是我不说所以 LIO 更适合维护odom → base_footprint而不是直接硬塞成map → base_footprint因为 LIO 会漂map不应该跟着它一起漂。3.base_footprintbase_footprint是机器人底盘在地面上的投影中心。对 Nav2 来说它通常比base_link更友好。为什么因为导航关心的是机器人在地面上怎么走xyyaw。它通常不关心机器人因为地面不平产生的 roll 和 pitch。所以在移动机器人导航里base_footprint常常作为 Nav2 的核心底盘 frame。你可以把它理解成机器人贴在地面上的影子。Nav2 真正规划的是这个“影子”怎么在地图上移动。4.chassischassis是机器人真实底盘结构坐标系。它可以和base_footprint重合也可以有一个固定变换。比如base_footprint → chassis这个变换通常是静态 TF。它表示底盘结构中心相对于地面投影中心在哪里。5.livox_framelivox_frame是 Livox MID-360 雷达坐标系。它通常挂在底盘上chassis → livox_frame这个变换也是静态 TF。这一步非常关键。因为点云是雷达坐标系下的如果 Nav2 或重定位系统不知道雷达安装在哪里它看到的点云就像一个人戴反了眼镜墙在前面它以为墙在屁股后面。门在左边它觉得门在天上。然后你开始怀疑算法。三、LIO 输出的不是 Nav2 想要的“标准底盘里程计”FAST-LIO / Point-LIO 本身是很强的 LiDAR-Inertial Odometry 算法。但要注意LIO 的输出是为了估计 LiDAR/IMU 的运动不是为了直接伺候 Nav2。很多 LIO 系统内部会有自己的坐标命名例如camera_init body aft_mapped lidar imu这些坐标系在 LIO 算法内部很正常但 Nav2 不认识这些“黑话”。Nav2 更喜欢的是map odom base_footprint base_link laser所以问题来了LIO 输出的camera_init → body不能直接当成 Nav2 的odom → base_footprint用。这就像你拿着一份英文论文去问食堂阿姨今天有什么菜。不是对方能力不行是接口语言不一致。因此我在项目中加了一层桥接逻辑把 FAST-LIO / Point-LIO 输出的内部位姿转换成 Nav2 更能理解的标准里程计关系odom → base_footprint这一步的意义非常大。它让上游 LIO 算法可以自由切换而下游 Nav2 完全不用关心你今天用的是 FAST-LIO 还是 Point-LIO。四、一棵正确的 TF 树应该谁发布谁这部分是重点。一个比较清晰的分工应该是map → odom 由重定位模块发布 odom → base_footprint 由 LIO 桥接模块发布 base_footprint → chassis 由静态 TF 发布 chassis → livox_frame 由静态 TF 发布展开来看就是map └── odom ← 3D 重定位维护 └── base_footprint ← LIO 里程计维护 └── chassis ← 机器人结构静态 TF └── livox_frame ← 雷达安装外参静态 TF为什么要这样拆因为每一段的物理意义不同。odom → base_footprint回答“我短时间怎么动了”这一段由 LIO 负责。LIO 的优势是短时间连续运动估计。它可以高频输出机器人运动状态。例如机器人从 odom 原点出发 向前走了 2 米 左转 45 度 再向前走 1 米这部分运动是连续、平滑的很适合给 Nav2 做局部控制和速度规划。map → odom回答“我的里程计整体偏到哪里去了”这一段由重定位模块负责。为什么不直接让重定位发布map → base_footprint因为这样会把全局校正和局部运动混在一起。比较好的做法是map → odom由重定位不断修正 odom 在 map 中的位置。这样一来LIO 继续负责局部连续运动重定位负责全局纠偏Nav2 看到的是一条完整、连续、可解释的 TF 链。这就是map → odom → base_footprint的核心意义。五、千万别让两个节点同时发布map → odom这是一个非常经典的坑。有些人会同时启动AMCLSLAM Toolboxsmall_gicp 重定位KISS-Matcher 重定位自己写的 map_to_odom 发布器。然后系统里同时出现多个节点发布map → odom这时候 TF 树就开始精神分裂。一个节点说odom 在 map 左边 1 米另一个节点说不对odom 在 map 右边 3 米第三个节点说你们都错了我觉得它在楼上最后 Nav2 看着这群人吵架默默选择罢工。所以原则非常简单同一时间只能有一个模块负责发布map → odom。如果你用 small_gicp 重定位就让 small_gicp 发布。如果你用 KISS-Matcher small_gicp就让它发布。如果你用 AMCL就别再启动另一个 map_to_odom 发布器。map → odom是全局定位权威。权威可以换但不能一群人同时当皇帝。六、为什么我的项目要做 LIO 桥接在Lidar_nav2_ws中我希望实现一个目标上游 LIO 算法可以切换下游 Nav2 接口保持不变。也就是说今天我用 FAST-LIO明天我换 Point-LIONav2 不应该感知到变化。Nav2 不应该关心你上游是 FAST-LIO 你上游是 Point-LIO 你的原始话题叫 /Odometry 还是 /aft_mapped_to_initNav2 只应该看到标准接口/odom odom → base_footprint /registered_scan所以中间必须有一层接口转换。这层桥接模块主要做几件事接收 LIO 原始里程计把 LIO 内部坐标系转换到底盘坐标系发布标准的odom → base_footprint发布标准/odom输出后续重定位和点云切片需要用的/registered_scan。这样做之后系统就变成了FAST-LIO / Point-LIO ↓ LIO Interface ↓ 标准 odom 与 TF ↓ 重定位 Nav2这就是工程系统里非常重要的一件事算法可以换但接口要稳定。否则你每换一个 LIONav2 配置、TF、话题、重定位模块都要跟着改。那不是机器人系统那是大型连连看。七、初学者最容易犯的 5 个 TF 错误下面这些错误我建议直接贴在桌面上。错误 1把 LIO 的原始坐标系直接当成odom很多 LIO 输出的是算法内部坐标关系。比如camera_init → body这类关系。它不一定等价于odom → base_footprint你需要确认原点在哪里旋转方向是否一致body 是 IMULiDAR还是底盘是否已经补偿了雷达到底盘的外参不要看到一个 odometry 就直接喂给 Nav2。这就像看到一个轮子就说自己造了辆车。错误 2base_link、base_footprint、chassis混用这三个 frame 很容易混。一般可以这样理解base_footprint机器人在地面上的投影中心 base_link机器人本体坐标系 chassis具体底盘结构坐标系如果你的系统主要是平面导航Nav2 更常用base_footprint。如果你把 Nav2 参数里写的是base_footprint但 TF 里只有base_link那 Nav2 就会很委屈你说你有底盘但我找不到。错误 3雷达外参写错雷达安装外参一般是chassis → livox_frame如果这个静态 TF 写错点云就会整体错位。典型现象障碍物位置不对地图和现实不重合机器人以为自己旁边有墙实际前方有障碍但 costmap 没反应RViz 里点云像被人拧了一下。这时候不要急着骂点云算法。先检查雷达安装 TF。错误 4重复发布map → odom这个前面已经讲过。一句话map → odom只能有一个权威发布者。不要让 AMCL、SLAM Toolbox、small_gicp、KISS-Matcher 同时抢这个位置。不然 TF 树会变成宫斗剧。错误 5TF 时间不同步有些错误不是坐标错而是时间错。典型报错包括Lookup would require extrapolation into the future Lookup would require extrapolation into the past常见原因仿真时use_sim_time没统一部分节点用系统时间部分节点用仿真时间TF 发布频率太低传感器消息时间戳异常。如果是仿真就统一用仿真时间。如果是实机就不要让某个节点还活在 Gazebo 的梦里。八、如何检查自己的 TF 树调 TF 不要靠感觉。感觉在机器人面前通常不太值钱。建议直接用工具看。1. 查看 TF 树ros2 run tf2_tools view_frames或者项目中封装脚本./show_tf_tree.sh生成之后重点看map 是否连到 odom odom 是否连到 base_footprint base_footprint 是否连到 chassis chassis 是否连到 livox_frame你要看到的是一棵树不是一片森林。如果是这样map → odom base_footprint → chassis → livox_frame中间断了那 Nav2 就找不到机器人。2. 检查map → odomros2 run tf2_ros tf2_echo map odom如果你启动了重定位模块这个变换应该存在。如果不存在说明重定位没有正常发布全局校正。如果疯狂跳变说明重定位不稳定或者有多个节点同时发布。3. 检查odom → base_footprintros2 run tf2_ros tf2_echo odom base_footprint推着机器人动或者在仿真里遥控机器人走一走。正常情况下这个变换应该连续变化。如果完全不变说明 LIO 桥接没有正常工作。如果变化方向很奇怪例如机器人向前走x 没动y 在狂飙那就要检查坐标轴定义。4. 检查雷达外参ros2 run tf2_ros tf2_echo chassis livox_frame这个通常是静态的。你要确认平移是否对应实际安装位置雷达朝向是否正确z 轴高度是否合理没有把角度单位写错。角度单位写错是经典事故。你以为写的是 90 度程序以为是 90 弧度。机器人看完直接开始研究抽象艺术。九、一个比较标准的启动逻辑在我的项目里导航系统大致可以这样理解第一步启动 LIOLIO 负责估计机器人短时间运动。LiDAR IMU → FAST-LIO / Point-LIO这一步得到的是原始里程计。第二步启动 LIO 桥接桥接模块负责把 LIO 内部位姿转成 Nav2 能用的标准关系odom → base_footprint同时输出/odom /registered_scan第三步启动 3D 点云重定位重定位模块根据先验 PCD 地图对机器人进行全局定位。它负责发布map → odom这一步解决的问题是机器人开机以后怎么知道自己在地图中的哪里第四步点云转 LaserScanNav2 成熟的 2D 导航链路通常更习惯使用 LaserScan。所以系统会把 3D 点云切片生成 2D 激光数据PointCloud2 → LaserScan这一步负责让 3D LiDAR 更好地接入 2D Nav2。第五步启动 Nav2Nav2 看到的是map → odom → base_footprint以及障碍物感知数据。这时候它就可以正常进行全局路径规划局部避障速度控制到点导航。至此一套完整链路才真正闭合。十、当 Nav2 不动时先别急着调参数很多人看到 Nav2 不动第一反应是改参数。max_vel_x: 改一下 acc_lim_x: 改一下 inflation_radius: 改一下 xy_goal_tolerance: 改一下改着改着参数文件像腌咸菜一样越来越入味但机器人还是不走。我的建议是Nav2 不动先查 TF再查 topic最后再调参数。优先级应该是1. TF 是否连通 2. frame_id 是否一致 3. 时间戳是否正常 4. /scan 或点云是否正常 5. /odom 是否正常 6. Nav2 参数是否合理不要一上来就调 DWB。DWB 很冤。它只是个局部规划器不是驱魔师。十一、最小排查清单如果你也在调 ROS 2 3D LiDAR Nav2我建议按这个顺序查1. TF 树是否完整ros2 run tf2_tools view_frames必须有map → odom → base_footprint → chassis → livox_frame2. 是否只有一个节点发布map → odom检查是否同时启动了多个定位模块。如果用了 small_gicp就不要再让别的节点抢map → odom。3.odom → base_footprint是否连续变化ros2 run tf2_ros tf2_echo odom base_footprint机器人运动时这个值应该连续变化。4. 雷达 frame 是否接到底盘ros2 run tf2_ros tf2_echo chassis livox_frame雷达必须挂在机器人身上。不要让雷达成为孤儿 frame。5. Nav2 参数里的 base frame 是否和 TF 一致如果参数里写的是robot_base_frame: base_footprint那 TF 里就必须真的有base_footprint。不要参数里写一个TF 里发另一个。Nav2 不擅长猜谜。6. 时间是否统一仿真时确认所有节点use_sim_time: true实机时确认不要误开仿真时间。十二、这个设计的核心价值这套 TF 设计真正解决的是系统解耦问题。简单说LIO 管短期运动重定位管全局纠偏Nav2 管路径规划。每个模块只干自己的活不互相抢饭碗。最终形成FAST-LIO / Point-LIO ↓ odom → base_footprint ↓ small_gicp / KISS-Matcher ↓ map → odom ↓ Nav2这样设计之后系统有几个好处1. LIO 可以切换FAST-LIO 和 Point-LIO 可以根据场景切换。但对 Nav2 来说接口不变。2. 重定位算法可以切换可以用纯 small_gicpKISS-Matcher small_gicpICP 初始化方案。但它们最终都应该服务于同一个目标发布正确的 map → odom3. Nav2 不需要理解上游算法细节Nav2 不需要知道你用了什么 LIO。它只需要看到标准 TF 和传感器数据。这就是一个工程系统应该有的样子上游可以升级下游不用陪葬。十三、总结ROS 2 导航系统里TF 不是配角。它不是“随便发几个静态变换就行”的东西。它是 LIO、重定位、Nav2 之间的骨架。如果 TF 树错了再强的算法也只能在错误的坐标关系里努力表演。对于 3D LiDAR LIO Nav2 这种系统我建议初学者牢牢记住这句话LIO 负责odom → base_footprint重定位负责map → odom静态 TF 负责机器人本体结构。也就是map → odom → base_footprint → chassis → livox_frame当这棵树接通以后Nav2 才真正知道我在哪 我怎么动 我的雷达在哪 我要怎么去目标点所以下次 Nav2 跑不起来不要第一时间怀疑算法。先看看 TF 树。很多时候不是机器人不聪明。是你还没把它的“家庭关系”交代清楚。项目地址如果你也在做 ROS 2、3D LiDAR、FAST-LIO、Point-LIO、点云重定位和 Nav2 导航可以参考我的开源项目GitHub - Ikunio/Lidar_nav2_ws: 基于 Livox MID-360 3D LiDAR 的 ROS 2 自主导航工作空间集成 LIO 里程计、重定位、Nav2 导航支持仿真与实机部署。 · GitHub项目包含FAST-LIO / Point-LIO 接入LIO 到 Nav2 的 TF 桥接3D 点云转 2D LaserScansmall_gicp 重定位KISS-Matcher small_gicp 全局重定位Gazebo 仿真与实机复用Nav2 导航完整流程。如果这个项目对你有帮助也欢迎点一个 Star。毕竟开源项目最怕的不是 bug而是没人看。
