无雷达调试Nav2：开源仿真到实机复用3D LiDAR导航工作空间

时间：2026-06-05 16:51

基于ROS2开源3DLiDAR自主导航工作空间Lidar_nav2_ws，支持Gazebo仿真与实机部署复用。集成LIO里程计、点云重定位、点云转LaserScan及Nav2导航链路，实现完整自主导航闭环，简化系统搭建，便于学习调试与算法替换，支持多种激光雷达，降低开发门槛。

我们近期整理并开源了一套基于 ROS 2 的 3D LiDAR 自主导航工作空间，命名为 Lidar_na v2_ws。这个项目的目标非常直接：很多开发者想学习 ROS 2 导航、Na v2、Livox MID-360、FAST-LIO、Point-LIO 以及点云重定位，但刚起步就会面临一个非常现实的问题——既没有机器人底盘，也没有激光雷达，该如何进行调试？

购买一套真实的机器人平台成本不低，Livox MID-360 也不是随手就能拿出来的传感器。更棘手的是，即便设备齐全，也不代表系统能立刻稳定运行。话题命名、TF 树、URDF、Na v2 参数、点云转 LaserScan、LIO 里程计、地图保存、实机启动……每一步都可能让人开始怀疑人生。

因此，在开发这个项目时，最想解决的问题并不是“又调通了一个 Na v2 demo”，而是：没有设备，也能先通过仿真环境学习；有了设备，也无需推倒重来。

1. 为什么我想做这个项目？

Na v2 本身已经是 ROS 2 里非常成熟的导航框架，涵盖了全局规划、局部规划、代价地图、行为树、控制器等模块。但很多人在实际中卡住的地方，并不是 Na v2 的某一个参数，而是完整机器人系统的搭建全过程。例如：

雷达数据如何接入系统？
3D 点云如何转换为 Na v2 可用的 2D LaserScan？
LIO 里程计输出的话题应该如何对接？
map -> odom -> base_footprint -> lidar 这条 TF 链如何保证不断？
仿真与实机的话题命名不一致该怎么办？
在 Gazebo 里能正常运行，为什么到了实机就会出问题？
在实机调参之前，能否先在仿真环境中把整体流程验证一遍？

这些问题看起来并不属于“高级算法”，但它们非常真实。因为机器人系统最折磨人的地方，往往不是某个算法公式，而是系统能否完整地转动起来。因此，我希望将这个项目打造成一个可以直接参考、直接运行、并且便于后续改造的 ROS 2 3D LiDAR 导航工作空间。

2. 这个项目主要解决什么痛点？

这个项目主要解决四个关键问题。

第一，不想从零搭建 Na v2 工程

如果只是单独启动 Na v2，其实并不困难。真正麻烦的是把它与机器人模型、传感器、里程计、TF、地图、代价地图全部衔接起来。这个工作空间已经把基础链路整理妥当了：

LiDAR / IMU
↓
LIO 里程计
↓
标准 odom / TF / registered_scan
↓
3D 点云重定位
↓
3D 点云切片成 2D LaserScan
↓
Na v2 导航

也就是说，它不是一个孤立的 Na v2 配置文件，而是一套相对完整的 3D LiDAR 自主导航链路。

第二，没有真实雷达，也能先从仿真开始

许多同学想学习 3D LiDAR 导航，但手头没有 Livox MID-360，也没有真实的机器人底盘。此时直接研究实机部署，门槛很高。因此，这个项目支持 Gazebo 仿真流程。你可以在仿真环境中先验证：

机器人模型是否正常加载；
雷达点云是否正常发布；
LIO 输入输出是否正常；
TF 树是否连通；
3D 点云能否顺利转换成 2D LaserScan；
Na v2 是否可以正常规划与控制；
地图保存和导航启动流程是否顺畅。

这样一来，即使没有真实设备，也可以先把 ROS 2 3D LiDAR 导航的主流程跑通。对于刚开始学习 Na v2、SLAM、LIO、点云重定位的人来说，这比一上来就面对真实硬件要友好得多。

第三，仿真和实机共用一套系统

很多机器人项目会面临一个问题：仿真是一套系统，实机又是另一套系统。仿真里话题叫一个名字，实机里又改成了另一个名字；仿真里 TF 是一棵完整的树，实机上 TF 却断成了几段；仿真里调好的 Na v2 参数，到了实机发现根本不适配；最后项目越改越乱，像一块插满转接头的祖传插线板。

所以这个项目的设计思路是：仿真和实机尽量共用同一套系统。换言之，Gazebo 负责模拟机器人和传感器，真实机器人负责提供实际数据，但进入后续的 LIO、重定位、LaserScan 生成、Na v2 导航流程后，整体结构尽量复用。这样做的好处是：

仿真调通的流程，实机可以继续沿用；
实机出问题时，可以回到仿真环境快速复现；
不需要维护两套完全割裂的工程；
后续替换算法或修改参数更加清晰。

第四，方便后续替换算法

这个项目并不是把所有功能都固化在单一算法上。目前系统设计尽量把几个模块拆分开：

LIO 里程计；
点云重定位；
点云转 LaserScan；
Na v2 导航；
机器人描述；
仿真与实机启动入口。

这样一来，后续想更换算法时，不需要把整个工程推倒重来。例如：想换用 FAST-LIO 或 Point-LIO；想换用 small_gicp 或 KISS-Matcher；想调整 Na v2 参数；想替换机器人模型；想更换仿真环境；想接真实 MID-360。这些都可以基于现有结构继续改进。这也是这个项目最有价值的地方：它不是一个黑盒，而是一个可以持续迭代的起点。

3. 项目适合哪些人？

1. 想学习 ROS 2 Na v2，但不想从零搭工程的人

如果你刚开始学习 Na v2，直接从官方示例跳到真实机器人项目，中间会有不少坑。这个项目可以作为一个相对完整的参考工程，让你看到 Na v2 在 3D LiDAR 机器人系统里是如何衔接起来的。

2. 想学 Livox MID-360 导航，但暂时没有设备的人

没有真实的 MID-360，也可以先用仿真流程理解整体链路。等到后面有了真实设备后，再切换到实机启动流程，继续接入真实雷达数据。

3. 想做 3D LiDAR + Na v2 的机器人开发者

如果你的机器人也是类似的移动底盘，并且希望使用 3D LiDAR、LIO 和 Na v2 做导航，那么这个项目可以作为一个不错的起点。你可以参考它的：工作空间结构、启动脚本、TF 设计、Na v2 参数、点云处理流程、仿真与实机切换方式。

4. 想研究点云重定位的人

除了导航本身，项目里还集成了点云重定位相关流程。这部分可用于研究机器人在已有 PCD 地图中的定位问题，也可以进一步扩展到全局重定位、初始位姿估计、持续 map 到 odom 校正等方向。

4. 这个项目不是万能模板

当然，这个项目并不是下载下来就能适配所有机器人。机器人导航系统与硬件强相关，不同底盘、不同雷达安装位置、不同坐标系、不同控制接口，都会带来差异。所以更希望大家把它理解成：一个经过验证的基础框架。它尽量帮你把最麻烦的基础链路先搭建好，让你不用每次都从零开始处理 Gazebo、URDF、TF、LIO、LaserScan、Na v2 和实机部署这些问题。

如果你只是想学习，可以先从仿真开始。如果你有真实设备，可以在仿真流程调通后，再切换到实机流程。如果你想研究算法，也可以基于这个框架继续替换 LIO 或重定位模块。