ROS2 3D LiDAR 导航实战：如何根据需求选择 FAST-LIO、LIO-SAM、Point-LIO、KISS-ICP

很多人刚开始做 3D 激光雷达导航，第一句话通常是：

"FAST-LIO、LIO-SAM、Point-LIO、LOAM、KISS-ICP，到底哪个最好？"

这个问题就像问：

"螺丝刀、扳手、电钻，哪个最强？"

答案是：

如果你拿电钻拧眼镜螺丝，那不是工具强不强的问题，是你和眼镜可能都需要冷静一下。

3D 激光里程计也是一样。

没有绝对最好的算法，只有最适合当前需求、传感器、算力和系统架构的方案。

本文不打算写成"算法百科全书"，而是从机器人实机部署角度聊一个更实际的问题：

对于 3D 激光雷达，怎么根据需求挑选合适的激光里程计？

---

先说结论

如果你赶时间，可以先看这一段。

需求场景	推荐方向	原因
室内移动机器人，想快速接 Nav2	FAST-LIO / FAST-LIO2	速度快、精度高、工程使用广
Livox 等非重复扫描固态雷达	FAST-LIO / Point-LIO	对固态雷达支持较友好
想要建图、回环、因子图优化	LIO-SAM	系统完整，适合做 SLAM 框架研究
没有 IMU，只想要纯 LiDAR odometry	KISS-ICP / LOAM 系	简洁，不依赖 IMU，但动态和退化场景更吃亏
算力很紧张，上嵌入式平台	FAST-LIO / KISS-ICP	相对轻量，实时性好
室外大场景、车载平台	LIO-SAM / FAST-LIO + 回环模块	需要长期一致性和全局约束
只想让 Nav2 有一个稳定 /odom	不要迷信算法，先把 TF 和 frame 接对	Nav2 不管你论文多强，它只认数据链路

一句话总结：

选激光里程计，不是选"论文名气最大"的，而是选"最能稳定输出你系统需要的 odom"的。

---

1. 激光里程计到底在机器人系统里干什么？

先把概念压实。

3D 激光里程计主要解决的是：

机器人从上一帧到当前帧，移动了多少？

它通常输出：

位姿 Pose
速度 Velocity
轨迹 Odometry
部分情况下还会输出局部地图 / 全局地图

在 ROS2 导航系统里，它更像是一个"定位发动机"。

如果把机器人系统比作一个外卖小哥：

3D LiDAR：眼睛
IMU：前庭系统
激光里程计：我刚才往哪走了多少
地图：城市地图
Nav2：接单以后怎么走
cmd_vel：腿怎么迈

激光里程计不负责点外卖，也不负责吃饭。

它最核心的职责是：

给机器人一个连续、稳定、低延迟的局部位姿估计。

---

2. 别先看算法，先看需求

很多选型失败，不是因为算法垃圾，而是因为需求没想清楚。

选激光里程计前，建议先问自己 8 个问题。

---

问题 1：你的雷达是什么类型？

雷达类型	特点	选型影响
机械旋转式 3D 雷达	扫描规律，点云结构稳定	LOAM、LIO-SAM、FAST-LIO 都常见
Livox / 固态雷达	非重复扫描，视场角和点云分布特殊	更推荐 FAST-LIO、Point-LIO 这类适配较多的方案
低线数雷达	点云稀疏	对算法鲁棒性要求更高
高线数雷达	点云丰富，但计算量大	需要考虑降采样和算力

如果你用的是 Livox 这类固态雷达，还硬套传统机械雷达假设，那就像拿筷子喝汤：不是不能喝，是场面比较辛苦。

---

问题 2：有没有 IMU？

激光里程计大体可以分成两类：

纯 LiDAR Odometry
LiDAR-Inertial Odometry，也就是 LIO

简单区别如下：

类型	是否需要 IMU	优点	缺点
纯 LiDAR 里程计	不需要	系统简单，传感器少	快速运动、退化场景容易不稳
LIO	需要 IMU	运动预测更强，实时性和鲁棒性更好	标定、时间同步、IMU 质量会影响效果

如果机器人运动比较慢，环境特征丰富，纯 LiDAR 方案也能跑。

但如果是移动机器人、无人车、机器狗、无人机这种会加速、转弯、颠簸的平台，IMU 基本不是锦上添花，而是防止系统"原地去世"的安全带。

---

问题 3：你是为了建图，还是为了导航？

这点很关键。

很多人说"我要 SLAM"，但实际需求可能只是：

我需要一个稳定的 odom 给 Nav2 用

这两件事不是一回事。

目标	重点	推荐关注
实时导航	低延迟、连续、稳定	FAST-LIO、Point-LIO、KISS-ICP
构建全局地图	地图质量、回环、一致性	LIO-SAM、FAST-LIO + 回环模块
重定位	全局匹配能力	ICP、small_gicp、KISS-Matcher 等
学术研究	可扩展性、理论完整性	LIO-SAM、因子图类方案
工程部署	稳定、易调、能复现	FAST-LIO 类方案更常见

对于 Nav2 来说，它并不关心你背后是不是用了某篇顶会论文。

它更关心：

map -> odom -> base_footprint

这条 TF 链是不是通的。

Nav2 的态度很朴素：

"你论文再强，TF 断了我也不走。"

---

3. 一个实机导航系统里，激光里程计应该放在哪？

在 ROS2 + 3D LiDAR + Nav2 系统里，常见链路大概是这样：

3D LiDAR + IMU
      ↓
激光里程计 / LIO
      ↓
输出 Odometry / TF
      ↓
odom -> base_footprint
      ↓
点云裁剪 / pointcloud_to_laserscan
      ↓
Nav2 costmap
      ↓
Planner / Controller
      ↓
cmd_vel
      ↓
底盘运动

也可以画成这样：

┌──────────────┐
│  3D LiDAR     │
└──────┬───────┘
       │ PointCloud2
       ▼
┌──────────────┐       ┌──────────────┐
│  IMU          │──────▶│  LIO / LO     │
└──────────────┘       └──────┬───────┘
                               │ odom / tf
                               ▼
                        ┌──────────────┐
                        │ TF Tree       │
                        │ map-odom-base │
                        └──────┬───────┘
                               │
                               ▼
┌──────────────┐       ┌──────────────┐
│ PointCloud2   │──────▶│ LaserScan     │
└──────────────┘       └──────┬───────┘
                               │
                               ▼
                        ┌──────────────┐
                        │ Nav2 Costmap  │
                        └──────┬───────┘
                               │
                               ▼
                        ┌──────────────┐
                        │ cmd_vel       │
                        └──────────────┘

这里最容易犯的错误是：

以为激光里程计算出来了，Nav2 就一定能用。

不一定。

激光里程计输出的可能是：

lidar_frame 在 odom 下的位姿
imu_link 在 map 下的位姿
body 在 world 下的位姿

而 Nav2 通常希望看到的是：

odom -> base_footprint

所以中间经常需要一个 bridge，把 LIO 的输出转换成 Nav2 真正能吃的数据。

---

4. 主流方案怎么选？

下面不做论文级推导，只从工程视角讲。

---

4.1 LOAM / A-LOAM：经典老兵，能打，但别让它背锅太多

LOAM 系列是很多 3D 激光 SLAM 的祖师爷级方案。

它的核心思想大概是：

提取边缘点和平面点
        ↓
帧间匹配
        ↓
局部地图优化
        ↓
估计位姿

适合：

• 学习 3D LiDAR SLAM 基本思想；

• 机械旋转雷达；

• 环境结构比较清晰；

• 对系统实时性要求不是极端苛刻的场景。

不太适合：

• 想快速工程部署；

• 固态雷达；

• 剧烈运动；

• 高动态环境；

• 希望直接丝滑接入 ROS2/Nav2 的场景。

它像一位经验丰富的老师傅，技术底子很强。

但如果你让它今天写 ROS2 launch、明天适配 Livox、后天接 Nav2，它可能会沉默，然后抽出一本 C++ 模板元编程。

---

4.2 LeGO-LOAM：地面机器人友好，但前提是你确实在地上跑

LeGO-LOAM 对地面移动机器人比较友好，利用了地面分割等假设。

适合：

• 地面机器人；

• 室外相对结构化场景；

• 雷达安装姿态稳定；

• 地面特征明显。

注意：

• 如果机器人不是地面平台，地面假设可能不成立；

• 如果环境地面复杂、坡道多、台阶多，也要谨慎；

• 工程上仍然需要考虑 ROS2 适配和维护成本。

它的特点是：

如果你的机器人老老实实在地上走，它会觉得你是个正常甲方。

如果你的机器人飞起来、跳起来、倒着跑，它会觉得你在为难算法。

---

4.3 LIO-SAM：系统完整，适合研究和大场景，但工程接入别太天真

LIO-SAM 的优势是系统比较完整，融合了 LiDAR、IMU，并且使用因子图优化，可以扩展 GPS、回环等模块。

适合：

• 室外大场景建图；

• 需要回环优化；

• 需要全局一致性；

• 想研究 SLAM 系统架构；

• 车载平台、较大范围地图构建。

优点：

LiDAR + IMU + 因子图
可以做回环
系统框架完整
适合扩展 GPS 等传感器

缺点：

配置复杂
对 IMU、时间同步、雷达格式要求较高
ROS2 部署可能需要额外适配
实时导航接 Nav2 仍然要处理 TF 和 odom 问题

LIO-SAM 更像一辆功能很多的越野车。

能翻山越岭，但你不能指望它像共享单车一样扫一下就走。

---

4.4 FAST-LIO / FAST-LIO2：工程部署热门选手，快、准、适合 LIO 导航

FAST-LIO 类方案在工程里很常见。

它的优势主要是：

实时性好
精度高
对 IMU 融合较强
适配 Livox 等雷达较多
工程资料相对丰富

适合：

• ROS2 机器人导航；

• 室内外移动机器人；

• Livox / 固态雷达；

• 需要实时 odom；

• 想快速跑通 3D LiDAR + Nav2 系统。

但要注意：

FAST-LIO 输出准，不代表 Nav2 能直接用。

你仍然需要关心：

frame_id
child_frame_id
odom -> base_footprint
base_link / base_footprint 区分
雷达外参
IMU 外参
时间戳同步
TF 是否重复发布

常见工程链路是：

FAST-LIO
   ↓
输出 LIO odom
   ↓
odometry bridge
   ↓
发布 odom -> base_footprint
   ↓
Nav2 使用 odom

如果你的目标是"真车跑起来"，FAST-LIO 往往是一个比较务实的选择。

它的风格很像工程队里的老师傅：

"别废话，传感器给我，IMU 对齐，时间戳别乱，我给你 odom。"

---

4.5 Point-LIO：适合高速运动和点级更新，但复杂度也上来了

Point-LIO 和 FAST-LIO 类似，也属于 LIO 方向，但它更强调点级更新和高速运动场景下的表现。

适合：

• 高动态平台；

• 运动速度较快；

• 雷达扫描畸变明显；

• 对实时性和运动补偿要求高；

• IMU 数据质量较好的系统。

注意：

• 系统理解成本更高；

• 参数和传感器配置仍然重要；

• 不建议一上来就用它救所有问题。

Point-LIO 像运动员。

跑得快，但你得给它合适的鞋、跑道和热身，不然它也会拉伤。

---

4.6 KISS-ICP：简单、优雅、纯 LiDAR，但别让它干 IMU 的活

KISS-ICP 是比较简洁的纯 LiDAR odometry 方案。

特点：

不依赖 IMU
结构相对简单
工程上比较轻量
适合快速验证

适合：

• 没有 IMU；

• 机器人运动较平稳；

• 环境几何结构丰富；

• 想快速获得一个 LiDAR odom；

• 算力有限但需要实时运行。

不适合：

• 快速旋转；

• 剧烈运动；

• 长走廊、空旷区域等退化场景；

• 动态物体特别多的环境；

• 希望长期高精度全局一致的场景。

纯 LiDAR 方案就像一个只靠眼睛走路的人。

白天、路清楚、墙够多，问题不大。

一旦环境空旷、转弯太猛、旁边还有人群乱窜，它也会想申请一个 IMU。

---

5. 按需求选型：别背算法名，背这个表

真正工程选型建议看下面这张表。

你的需求	推荐方案	不建议优先选
我只想快速让机器人在 ROS2 + Nav2 里跑起来	FAST-LIO / FAST-LIO2	一上来改复杂因子图系统
我没有 IMU	KISS-ICP / LOAM 系	强依赖 IMU 的 LIO
我用 Livox 雷达	FAST-LIO / Point-LIO	没适配固态雷达假设的传统方案
我要大场景建图和回环	LIO-SAM / FAST-LIO + 回环	只用局部 odom
我要低算力实时运行	FAST-LIO / KISS-ICP	过重的全局优化系统
我要学术研究和系统扩展	LIO-SAM	只封装好的黑盒工程包
我要接 Nav2	能稳定输出 odom -> base_footprint 的方案	只会输出漂亮轨迹但 TF 不规范的方案
我要任意位置开机重定位	LIO + 全局重定位模块	只靠连续 odom

注意最后一条：

激光里程计解决的是连续运动估计，不等于全局重定位。

机器人开机不知道自己在哪，这不是单纯 LIO 能完美解决的问题。

这时候你需要的是：

已有点云地图
    ↓
当前点云
    ↓
全局粗匹配
    ↓
ICP / GICP 精配准
    ↓
更新 map -> odom

也就是说，LIO 负责"我刚才怎么动了"，重定位负责"我现在到底在哪"。

别让 LIO 一个人干完整个定位系统的活。

算法也有劳动法。

---

6. 最推荐的选型流程

可以按下面这个流程判断。

开始
  ↓
是否有 IMU？
  ├── 没有
  │     ↓
  │   运动是否平稳、环境是否结构丰富？
  │     ├── 是 → KISS-ICP / LOAM 系
  │     └── 否 → 建议加 IMU，否则别怪算法摆烂
  │
  └── 有 IMU
        ↓
      是否使用 Livox / 固态雷达？
        ├── 是 → FAST-LIO / Point-LIO
        └── 否
              ↓
            主要目标是什么？
              ├── 实时导航 → FAST-LIO / FAST-LIO2
              ├── 大场景建图 + 回环 → LIO-SAM / FAST-LIO + 回环
              ├── 高速运动 → Point-LIO / FAST-LIO
              └── 学习研究 → LOAM / LIO-SAM / FAST-LIO 都可以

如果你要接 Nav2，再加一个最终判断：

这个方案能不能稳定提供：
/odom
/tf
odom -> base_footprint
合理的时间戳
正确的 frame_id

如果不能，那它再强也只是 RViz 里的艺术表演。

---

7. Nav2 场景下，选型重点不是"轨迹好看"，而是"链路稳定"

做 ROS2 导航时，很多人会被轨迹图骗。

RViz 里轨迹看起来很顺滑，不代表 Nav2 能跑。

Nav2 还需要：

/map
/odom
/tf
/scan 或点云障碍物数据
costmap
planner_server
controller_server
bt_navigator
/cmd_vel

激光里程计只解决其中一部分。

尤其要注意 TF：

map -> odom -> base_footprint -> base_link -> lidar_frame

常见错误包括：

1. LIO 发布的是 map -> lidar_frame，但 Nav2 需要 odom -> base_footprint
2. base_link 和 base_footprint 混用
3. 雷达 frame 没有接到机器人本体 frame
4. 多个节点同时发布 odom -> base_link
5. map -> odom 被重复发布
6. 时间戳不同步，导致 transform extrapolation

所以，如果你的目标是 3D 雷达接 Nav2，真正应该关心的是：

LIO 输出了什么？
输出的 frame 是谁？
谁发布 odom -> base_footprint？
谁维护 map -> odom？
Nav2 的 global_frame 和 robot_base_frame 配对了吗？
costmap 的 sensor_frame 能查到 TF 吗？

不要一上来就调 controller 参数。

很多时候 controller 是清白的，它只是被一棵断掉的 TF 树绑架了。

---

8. 不同平台怎么选？

---

8.1 室内轮式机器人

典型需求：

速度不高
环境结构较多
需要接 Nav2
需要稳定 odom
算力中等

推荐：

FAST-LIO / FAST-LIO2
KISS-ICP

如果有 IMU，优先 FAST-LIO。

如果没有 IMU，可以考虑 KISS-ICP。

系统建议：

3D LiDAR + IMU
    ↓
FAST-LIO
    ↓
odom -> base_footprint
    ↓
PointCloud2 转 LaserScan
    ↓
Nav2

---

8.2 室外无人车 / 园区车

典型需求：

场景大
运行时间长
可能需要 GPS
需要回环或全局一致性

推荐：

LIO-SAM
FAST-LIO + 回环 / 重定位模块

如果只靠局部 odom，长时间运行容易累计漂移。

这时候你需要的不只是 LIO，还需要地图、回环、重定位，甚至 GPS/RTK 融合。

---

8.3 机器狗 / 无人机 / 高动态平台

典型需求：

运动快
姿态变化大
振动明显
扫描畸变明显

推荐：

FAST-LIO
Point-LIO

重点关注：

IMU 质量
外参标定
时间同步
运动补偿
实时性

这种平台上，如果 IMU 时间戳飘了，算法可能不是"误差变大"，而是直接开始写科幻小说。

---

8.4 低算力嵌入式平台

典型需求：

CPU 紧张
功耗受限
实时性要求高

推荐：

FAST-LIO
KISS-ICP

注意：

点云降采样
地图大小控制
发布频率控制
线程占用
是否需要 GPU

不要把桌面端跑得很爽的配置直接搬到嵌入式板子上。

板子不会骂人，但它会用 100% CPU 和 2Hz 里程计表达不满。

---

9. 选型时最容易踩的 7 个坑

---

坑 1：只看精度，不看实时性

有些方案离线跑很准，但实时跑不动。

导航系统里，延迟太高比误差稍大更可怕。

因为机器人不是写论文的，它会真的撞墙。

---

坑 2：只看算法，不看传感器适配

不同雷达点云结构差异很大。

机械雷达、固态雷达、低线数雷达、高线数雷达，不是随便换个 topic 名就完事。

---

坑 3：忽略 IMU 外参和时间同步

LIO 里面 IMU 很重要。

如果 IMU 外参错了，结果可能表现为：

机器人轨迹慢慢歪
原地旋转时位置漂移
建图墙面重影
高速运动直接发散

这时候别急着骂算法。

先看看 IMU 和 LiDAR 是不是在同一个时间宇宙里。

---

坑 4：把 odom 当成 map 用

odom 应该是局部连续坐标系。

它可以漂，但不应该跳。

map 是全局坐标系。

它可以通过重定位或回环发生修正。

常见正确关系：

map -> odom -> base_footprint

如果 LIO 一会儿发 map，一会儿发 odom，一会儿又让重定位模块也发 TF，系统很快就会变成 TF 版三国演义。

---

坑 5：多个节点抢着发同一条 TF

比如：

FAST-LIO 发布 odom -> base_link
robot_localization 也发布 odom -> base_link
你自己写的 bridge 也发布 odom -> base_link

这不是融合，这是抢麦。

正确做法是明确：

谁是主 odom 来源？
谁发布 odom -> base_footprint？
谁发布 map -> odom？
哪些 TF 是 static？

---

坑 6：只做 LIO，不做重定位

LIO 可以让机器人知道"我从刚才到现在怎么动了"。

但如果机器人开机就在地图中某个未知位置，它不知道自己初始在哪。

这时候需要：

全局重定位
ICP / GICP 精配准
map -> odom 更新

否则机器人可能非常自信地在错误位置规划路线。

这就像一个人拿着地图，但坚信自己出生在地图左上角。

---

坑 7：忘了 Nav2 最后吃的是系统链路，不是算法名字

Nav2 不会因为你用了 FAST-LIO 就自动感动。

它只会检查：

TF 能不能查？
costmap 有没有数据？
odom 是否连续？
cmd_vel 是否能发到底盘？
frame_id 是否一致？
时间戳是否合理？

所以选型的最终目标不是：

我用了一个很厉害的 LIO

而是：

我能稳定输出 Nav2 需要的数据链路

---

10. 我的建议：先跑通，再变强

如果你是做 ROS2 3D LiDAR 导航，我建议按这个顺序推进：

第 1 步：先让 LiDAR 和 IMU 驱动稳定
第 2 步：跑通一个 LIO，拿到连续 odom
第 3 步：把 LIO 输出桥接成 odom -> base_footprint
第 4 步：检查完整 TF 树
第 5 步：把 3D 点云裁剪成 LaserScan 或接入 costmap
第 6 步：跑通 Nav2
第 7 步：再考虑回环、重定位、多传感器融合

不要一开始就追求完整大系统。

很多项目不是死在算法不够强，而是死在：

frame 名字不一致
launch 顺序不对
时间戳乱
TF 重复发布
点云 frame 查不到
Nav2 lifecycle 没激活

也就是说，机器人不是被论文打败的，是被工程细节绊倒的。

---

11. 最终选型建议

如果只给一个务实版本，我会这样选：

情况 1：室内移动机器人 + ROS2 + Nav2 + 有 IMU

优先：

FAST-LIO / FAST-LIO2

重点做：

LIO odom bridge
TF 树规范化
PointCloud2 转 LaserScan
Nav2 costmap 配置

---

情况 2：Livox 雷达

优先：

FAST-LIO
Point-LIO

重点做：

雷达外参
IMU 外参
时间同步
点云格式适配

---

情况 3：没有 IMU，只想快速验证

可以考虑：

KISS-ICP
LOAM 系

但要接受：

快速运动不稳
退化环境容易漂
长期运行需要额外约束

---

情况 4：室外大场景建图

可以考虑：

LIO-SAM
FAST-LIO + 回环 / 重定位

重点做：

全局一致性
回环检测
地图管理
GPS/RTK 融合

---

情况 5：机器人要任意位置开机

不要只靠 LIO。

需要额外加入：

点云地图
全局匹配
ICP / GICP 精配准
map -> odom 更新

LIO 负责连续跟踪，重定位负责找回地图位置。

一个负责"走路"，一个负责"认路"。

让走路的负责认祖归宗，确实有点强人所难。

---

12. 排查 checklist

选好算法以后，建议按下面顺序检查。

ros2 topic list
ros2 topic echo /odom
ros2 topic hz /odom
ros2 topic echo /tf
ros2 run tf2_ros tf2_echo odom base_footprint
ros2 run tf2_ros tf2_echo base_footprint lidar_frame
ros2 run tf2_tools view_frames

重点看：

1. /odom 是否稳定发布？
2. odom 的 header.frame_id 是不是 odom？
3. odom 的 child_frame_id 是不是 base_footprint 或 base_link？
4. TF 树是否连通？
5. 是否有重复 TF？
6. 时间戳是否正常？
7. Nav2 参数里的 robot_base_frame 是否和 TF 一致？
8. costmap 的 sensor source 是否能查到 transform？

如果这些都没查，就开始改算法参数，那基本属于"方向盘掉了，但你在调空调温度"。

---

总结

最后总结成几句话：

1. 3D 激光里程计选型不是看哪个算法名气最大，而是看你的机器人需求。

2. 有 IMU、要实时导航，FAST-LIO / FAST-LIO2 通常是务实选择。

3. 要大场景建图和回环，可以考虑 LIO-SAM 或 FAST-LIO 加全局模块。

4. 没有 IMU，可以考虑 KISS-ICP / LOAM 系，但要接受场景限制。

5. 接 Nav2 时，核心不是轨迹多漂亮，而是 map -> odom -> base_footprint 这条链是否稳定。

6. LIO 不是重定位，机器人任意位置开机还需要全局匹配和 map -> odom 维护。

所以，下一次有人问：

"3D 激光里程计哪个最好？"

可以先反问他：

你的雷达是什么？
有没有 IMU？
跑室内还是室外？
要建图还是导航？
算力多少？
要不要接 Nav2？
需不需要重定位？

如果这些问题都没想清楚，直接选算法，就像还没看病人症状就开药。

药可能是好药。

但病人可能只是没吃饭。