我花了两天把FAST-LIO跑通的经历让我决定写这篇东西。这两天里踩的坑比过去写业务代码一年都多不是编译报错就是雷达IP不对好不容易编译过了一启动就段错误崩掉。很多刚入门激光雷达SLAM的朋友其实第一道坎根本不在算法本身而是不知道怎么把FAST-LIO这个激光雷达-惯性里程计框架在ROS环境里稳稳当当地跑起来。这篇博文就是基于我自己在ROS Noetic上部署FAST-LIO的完整过程把环境准备、源码编译、launch文件配置、mid360雷达适配、建图实操到点云地图保存这些关键环节全部拆开讲一遍顺手把我踩过的坑、查过的源码、试过的参数都记录在案给你一条能直接照着走的路。那这个内容适合谁看呢主要是三类人一是刚入手固态激光雷达尤其是livox mid360想做建图的新手二是已经用别的2D雷达跑过cartographer想往3D雷达SLAM进阶的同学三是被网上各种ROS安装教程带偏了、系统环境已经一团乱麻的兄弟。无论你是想验证传感器能不能用还是想快速搭一套激光雷达-惯性里程计的融合建图方案这篇文章都能帮你少走弯路。1. 部署前的环境准备与技术选型1.1 为什么选择FAST-LIO而非传统LOAM系算法先说结论在固态激光雷达IMU融合建图这个场景里FAST-LIO是当前ROS1生态里我用过最省心的紧耦合方案没有之一。LOAM系列包括A-LOAM、LEGO-LOAM当年确实神但它们的架构是基于旋转式机械雷达设计的对点云畸变矫正和特征提取有很强的假设。到了固态雷达时代比如mid360这种非重复扫描的棱镜式雷达点云分布方式完全变了LOAM系的表现会明显下滑。FAST-LIO把雷达点云和IMU数据放进一个迭代误差状态卡尔曼滤波IESKF框架里紧耦合直接在原起点云上做配准不需要像LOAM那样单独提边缘点和平面点这种思路天然适合固态雷达稀疏且分布不均匀的点云。实测下来在同样的走廊场景里A-LOAM跑几步就飘FAST-LIO能稳稳贴住地面。而且FAST-LIO对IMU的依赖不只是当作运动补偿工具它把IMU状态写进了滤波器这意味着在雷达退化场景——比如长直走廊、空旷大厅——惯性信息能兜底这个特性对建图稳定性非常关键。如果你后面要换雷达、换IMUFAST-LIO的launch文件里参数结构也足够清晰改起来不至于满头问号。1.2 Ubuntu与ROS版本怎么匹配最省事这是新手最容易被坑的地方。FAST-LIO官方源码支持的ROS版本很宽但从我实际编译体验来看Ubuntu 20.04 ROS Noetic是舒适度最高的组合没有之一。为什么这么说因为FAST-LIO依赖的livox_ros_driver、livox_ros_driver2这些雷达驱动在Noetic上有成熟的预编译支持网上现成的教程和报错案例也最全。Ubuntu 18.04 Melodic虽然理论上也行但PCL和Eigen版本偏老编译时容易撞上奇怪的模板报错。Ubuntu 22.04 ROS Humble也可以跑但要走livox_ros_driver2的新架构API有变动很多东西得自己适配新人会非常痛苦。如果你是纯新手系统还没装ROS我强烈建议你重装Ubuntu 20.04然后用国内源镜像装Noetic。装ROS那一步网上很多人推“鱼香ROS一键安装”我自己也试过确实快一条命令装完ROS核心省去了一堆源配置的折腾。不过要注意一键脚本只解决ROS本体安装不解决后面雷达驱动和FAST-LIO的依赖冲突所以关键还是把系统版本和ROS版本选对。如果你非要留在Ubuntu 22.04至少做好折腾两三天的心态准备。1.3 依赖库版本与编译顺序的硬性约束FAST-LIO的核心依赖有三个Eigen、PCL、livox_ros_driver。这三个的版本和编译顺序都有讲究乱来大概率会编译报错。EigenFAST-LIO代码里用了大量Eigen的块操作和矩阵运算建议直接装系统源里的libeigen3-dev版本3.3.7以上即可不需要自己源码编译最新版反而容易跟PCL的Eigen版本冲突。PCLNoetic自带的PCL 1.10完全够用不需要额外编译如果你之前为了折腾某个项目手动编译过PCL建议在新环境里装完先查一下pcl_version免得FAST-LIO链接到错误版本。livox_ros_driver这个是重头戏。官方FAST-LIO仓库默认适配的是livox_ros_driver但对于mid360用户更推荐用livox_ros_driver2因为mid360在driver2里支持更完整的点云格式配置。装驱动的时候有个细节driver2编译时会生成livox_ros_driver2这个包名跟老版livox_ros_driver不一样后面launch文件里引用的名字要对应上否则会报找不到package。编译顺序上我建议严格按照下面的顺序来先装Eigen和PCL再编译livox_ros_driver2最后编译FAST-LIO。这个顺序是为了保证FAST-LIO在cmake搜索依赖时能找到正确版本如果先编译FAST-LIO再装驱动那FAST-LIO的CMakeLists里find_package(catkin REQUIRED COMPONENTS livox_ros_driver2)就会失败你只能在中间反复加环境变量碰运气。2. 源码编译与雷达驱动适配详解2.1 FAST-LIO源码拉取与工作空间搭建环境准备好了接下来是拉源码。先创建catkin工作空间注意不要用sudo普通用户权限就够mkdir -p ~/catkin_ws/src cd ~/catkin_ws/src git clone https://github.com/hku-mars/FAST_LIO.git cd ~/catkin_ws catkin_make这里有个坑FAST-LIO默认分支是面向livox_ros_driver的如果你用的是mid360且想走driver2建议直接看FAST-LIO的README里关于livox_ros_driver2的说明里面要求你改CMakeLists.txt里的包名引用并且在launch文件里用driver2的节点名。不夸张地说我见过不少人都卡在这一步编译报错提示找不到livox_ros_driver2包但实际就是没改CMakeLists。还有一个容易忽略的点catkin_make之前确认~/.bashrc里的ROS环境变量已经source了比如source /opt/ros/noetic/setup.bash。如果你用了zsh记得把环境变量也加到~/.zshrc否则编译时rosdep相关的命令会找不到。编译过程中如果报错提示找不到某些头文件别急着瞎改代码先用rospack find确认对应功能包是否存在。比如报eigen3/Eigen/Core: No such file大概率是Eigen没装或者路径没配好。一条sudo apt install libeigen3-dev就能解决的事不需要去翻源码。2.2 mid360专用驱动livox_ros_driver2的配置要点livox_ros_driver2和旧版驱动的最大区别在于它引入了一个config目录里面有各型号雷达的json配置文件。mid360的配置文件里可以直接设置扫描频率、点云密度、坐标系朝向等参数比老驱动用launch参数硬撸清晰得多。在安装driver2之前先看看自己的雷达是网口连接还是USB连接。mid360默认走网口默认IP是192.168.1.1xx具体看雷达标签。这个IP必须和你的电脑网卡IP在同一个网段否则连不上。举个实际例子我手里的mid360默认IP是192.168.1.102那我电脑的网卡IP就得设成192.168.1.100子网掩码255.255.255.0网关不用管。很多新手在这步栽跟头我见过最典型的场景是折腾半天改雷达IP结果发现网线压根没插到笔记本的千兆网口上或者插到了USB转网口的百兆扩展坞里点云数据直接被带宽卡死。驱动编译本身不复杂cd ~/catkin_ws/src git clone https://github.com/Livox-SDK/livox_ros_driver2.git cd ~/catkin_ws catkin_make编译完以后第一次连接雷达时可以用roslaunch livox_ros_driver2 rviz MID360.launch测试如果RViz里能出现点云说明驱动链路通了大半。这个launch文件里面读的配置文件是config/MID360_config.json里面有个host_ip字段要改成你电脑的IP否则雷达会把点云数据发给错误的地址现象就是驱动节点显示已连接但就是没有点云话题输出。这是我第二次踩坑的地方改完IP立刻正常。2.3 点云话题与坐标系的统一问题FAST-LIO订阅的话题名一般是/livox/lidarIMU话题是/livox/imu但这只对mid360的默认配置成立。如果你用的雷达不同或者驱动launch文件里改了话题名那必须在FAST-LIO的launch文件里同步修改。知道为什么容易乱吗因为FAST-LIO官方仓库里的示例launch是给livox_ros_driver准备的话题名是/livox/lidar和/livox/imu但driver2的默认话题名也是这两个。当你把两个包混在一起编译后话题名恰好一致时会正常工作可一旦用了driver2的录像包重放或者改了雷达ID话题名就可能出现/livox/lidar_0这种带后缀的情况FAST-LIO自然就收不到数据了。排查方法很简单驱动节点跑起来以后用rostopic list看一下实际输出的点云和IMU话题名再对照FAST-LIO的launch文件里pointcloud_topic和imu_topic两个参数必须严格一致。这个话题名不一致的问题在fast-lio运行后RVIZ界面黑屏、无点云显示的报错排查中占了一半以上的比例。3. launch文件解析与核心参数调优3.1 FAST-LIO自带的launch参数逐项拆解FAST-LIO的launch文件实际上是整个系统能否稳定运行的关键。很多人编译通过、驱动也正常但一跑建图就飘根本原因就是launch参数没调对。这里我把用mid360建图最关心的几个参数拿出来逐项说明都在FAST_LIO/launch/mapping_mid360.launch这个文件里。arg namerviz defaulttrue / arg namepointcloud_topic default/livox/lidar / arg nameimu_topic default/livox/imu / arg nameset_config_file default$(find fast_lio)/config/mid360.yaml /rviz默认是true启动后自动打开RViz可视化。如果你的电脑性能吃紧或者只想跑后台数据可以改成false但调试阶段建议保留观察点云和轨迹最直观。pointcloud_topic和imu_topic上面已经说过必须和实际发布的话题名对应。涉及到雷达驱动和IMU是否能被FAST-LIO感知的问题。set_config_file指向FAST-LIO的yaml配置文件mid360的配置在这里。这个文件是重头戏里面参数很多但真正需要动的不多关键是lidar_type、imu_en、point_filter_num这几个。再看yaml里几个核心参数common: lidar_type: 1 imu_en: true scan_line: 4 point_filter_num: 6lidar_type为1表示livox系列雷达这是FAST-LIO里livox适配的开关。如果你用其他雷达这个值要改成对应的类型。scan_line对mid360来说写4就行因为mid360虽然等效扫描线不多但FAST-LIO并不依赖这个值做特征提取。point_filter_num是点云抽稀参数每N个点取一个数值越大参与计算的原始点越少、CPU负担越小但建图精度也会下降。我用mid360时把它调成2-6之间室内小场景用6基本够室外大场景调到2更稳。IMU参数在preprocess和imu段里preprocess: lidar_type: 1 scan_line: 4 blind: 2.0 imu: imu_en: true imu_rate: 200blind是近距离盲区阈值把雷达近处过于密集且不可靠的点过滤掉mid360设置2.0米比较合适太大会丢掉墙上的特征太小会引入雷达自身的噪声点。imu_rate是IMU频率mid360内置IMU是200Hz这个值务必和实际IMU输出频率一致不一致的表现就是建图轨迹缓慢漂移肉眼看不出来但跑一大圈回到原点时会发现闭合差很大。3.2 坐标系外参标定的实操建议FAST-LIO把激光雷达和IMU的安装外参写死在yaml里初装时可以不那么精确但外参和实际偏差过大会导致地图分层。mid360这种自带IMU的雷达外参基本是单位矩阵也就是雷达坐标系和IMU坐标系重合。自己组装雷达独立IMU的就必须标定外参。简单说下我的做法先把雷达和IMU刚性固定保证二者之间没有相对位移。然后跑一小段有旋转和直线运动的数据录成rosbag再用lidar_align这类外参标定工具离线算。注意标定时要人为制造足够的旋转激励只在原地平移标出来的外参不可信。外参不准的典型症状是静止时点云对齐良好一运动起来地图边缘出现重影或分层。如果你确认雷达和IMU的物理安装没有松动但建图就是飘先怀疑外参。外参的旋转和平移量写在哪在yaml文件里的extrinsic_rotation和extrinsic_translation通常是3x3矩阵和3x1向量从标定工具的结果直接抄进去即可。3.3 点云频率、带宽和CPU负载的平衡mid360在驱动里默认是10Hz扫描点云点数在30万左右每秒。FAST-LIO的实时性取决于CPU算力、点云抽稀比例、配准迭代次数三者之间的平衡。我在一台八代i7笔记本上实测point_filter_num6时CPU占用在60%到80%之间建图帧率能稳定在8到10Hz左右。如果把point_filter_num改大比如12CPU占用降下来了但建图精度肉眼可见下降转角和门框处会有明显拉花。如果你用的是工控机或者老笔记本建议先用4到6之间的值跑一遍小场景观察CPU和内存占用再决定要不要调大抽稀比例。还有一个容易忽略的带宽问题。mid360是网口雷达如果你把点云话题原样发布出去同时又在同一台电脑上跑FAST-LIO千兆网口问题不大。但要是电脑用了无线网络或者网口被其他数据占满雷达点云会出现丢包FAST-LIO的表现是轨迹跳变。这种情况优先检查有线连接和交换机而不是调算法参数。4. 激光雷达-惯性里程计建图实操与地图保存4.1 从驱动到建图的全流程快速验证所有配置就位后先不要急着扛着设备跑大场景我们做一次最小化验证。先启动驱动roslaunch livox_ros_driver2 rviz MID360.launch确认RViz里能看到点云并且rostopic hz /livox/lidar输出频率在10Hz左右rostopic hz /livox/imu输出频率在200Hz左右。这两路数据的频率正常才说明传感器链路可靠。然后启动FAST-LIOroslaunch fast_lio mapping_mid360.launch启动后RViz里会多出FAST-LIO的Map点云和Odometry轨迹。拿雷达对着天花板和墙壁静止晃一晃观察点云是否和驱动RViz里显示的一致再看Odometry的轨迹是否随设备移动而伸缩。如果轨迹和实际运动方向背离基本是外参错误或者IMU方向问题。这一步验证通过后就可以拿设备在房间里慢慢走一圈记录建图效果。FAST-LIO在室内小场景通常不需要额外的回环检测就能保证低漂移但你走得越快、场景特征越少漂移风险越高。我建议第一圈尽量贴墙走让雷达多看到一些墙角和门的特征后面再放开速度。4.2 录制rosbag与离线建图的操作细节在很多实际工程场景里我们不想扛着设备现场调参而是把传感器数据录下来回办公室慢慢处理。这就需要rosbag录制。录制命令很简单rosbag record /livox/lidar /livox/imu -O scene01.bag但有个细节rosbag record默认不记录tf和odom这类高频小消息但对FAST-LIO离线建图来说只需要点云和IMU就够。录的时候注意磁盘空间mid360半小时的数据量轻松超过10GB建议录之前检查一下磁盘剩余。离线重放建图的话先启动FAST-LIO节点再播放bagroslaunch fast_lio mapping_mid360.launch rosbag play scene01.bag播放bag时有个容易踩的坑bag里记录的时间戳是录制时的真实时间而rosbag play默认按原时间轴播放如果你中途暂停过FAST-LIO的IMU预积分会跳变导致建图出现断层。解决办法是用rosbag play --clock并勾选launch文件里的use_sim_time但这个操作复杂且容易引入新问题。我的建议是录制时一气呵成别中途停播放时也别用暂停功能尽量让IMU流是连续的。4.3 点云地图的保存与pcd格式输出FAST-LIO运行过程中RViz里看到的地图只是实时可视化的结果并不会自动保存。想拿到能够用于后续导航或展示的完整点云地图需要订阅FAST-LIO发布的/cloud_registered话题里面是已经配准到世界坐标系下的点云。保存地图最常用的是pcl_ros里的pointcloud_to_pcd工具rosrun pcl_ros pointcloud_to_pcd input:/cloud_registered这个工具会持续把点云写入当前目录下的pcd文件文件名带时间戳。问题在于它会一直写直到节点被CtrlC终止中间会产生大量文件。想保存最终地图有两个办法。办法一等FAST-LIO跑完在RViz里把地图话题取消再勾选一次让Rviz重新订阅一帧完整点云然后用RViz右上角“File→Save as Image”之类的方式保存这只能存图不能存点云。办法二更适合拿到高质量pcd自己写一个ROS节点订阅/cloud_registered按下CtrlC时保存一帧完整点云为pcd文件。如果不想写代码也可以用pcl_ros的另一个工具bag_to_pcd从rosbag里提取点云帧。但不管哪种方式都建议建图结束后保持雷达静置一两秒让滤波器收敛再保存场景地图这样得到的pcd边缘更干净。保存pcd后可以用CloudCompare或者pcl_viewer打开查看pcl_viewer scene.pcd如果发现地图有轻微倾斜或者漂移回查外参和IMU参数如果只是点云密度不均匀那是盲区和抽稀导致的正常现象。5. 高频问题排查与避坑经验总结5.1 雷达连接与IP配置的常见故障这一节是写给用mid360和新手的。雷达连接问题占了FAST-LIO部署故障的一半而且症状千奇百怪驱动启动后报错、点云话题不刷新、RViz黑屏等等最后排查下来十有八九是网络没通。现象1roslaunch livox_ros_driver2后没有报错但rostopic hz /livox/lidar输出为0。先检查网线连接和网卡IP确保与雷达IP同网段。用ping 192.168.1.102测一下如果ping不通大概率是IP配置问题而不是驱动问题。现象2ping通了但点云依然没有。看看是否在驱动的json配置文件里改了雷达IP但电脑IP没同步改或者改了两处的IP不在同一子网。更隐蔽的是mid360默认广播域是192.168.1.x如果你电脑的IP是192.168.2.x即便你设置了路由雷达的UDP广播也过不来。现象3雷达在RViz里显示的点云有断续。如果横向转动雷达时点云连续纵向转动时点云跳跃大概率是雷达和电脑之间网络拥塞。不要用百兆网口或USB转网口直接用主板上的千兆口网线也尽量用短线。很多教程会教你直接改雷达本身IP但是mid360这代雷达支持通过驱动配置软件去改。实际操作中如果电脑端IP能改我更建议先改电脑端IP来匹配雷达默认地址。只有当一台电脑需要接多台雷达时才去改雷达自身IP。5.2 FAST-LIO编译和运行时的经典报错这里挑三个我在部署过程中遇到的高频报错来剖析基本覆盖了绝大多数编译运行问题。报错一fatal error: livox_ros_driver2/LivoxLidarConfig.h: No such file or directory。这个就是没改CMakeLists.txt导致fast_lio编译时找不到driver2的头文件。解决办法是把FAST_LIO/CMakeLists.txt里所有出现livox_ros_driver的地方改成livox_ros_driver2再重新catkin_make。但要注意find_package(catkin REQUIRED COMPONENTS livox_ros_driver2)和add_executable里的链接库名都要同步改别只改一半。报错二Error: Invalid laser type!。这个直接写在FAST-LIO源码里意思是yaml配置里的lidar_type值不对。mid360应填1如果是livox系列填1如果是旋转式雷达填其他对应值。很多人编译没问题但一启动就报这个就是yaml没改对。报错三编译时PCL相关的模板报错比如no matching function for call to ‘pcl::PointCloudpcl::PointXYZINormal::push_back’。这多半是PCL版本混了比如系统自带的PCL和你手动编译的PCL头文件路径冲突。检查一下echo $CMAKE_PREFIX_PATH如果包含了你手动安装的PCL路径把它清理干净用系统源里的PCL就好。5.3 建图漂移问题与IMU标定技巧建图漂移是FAST-LIO最大的痛点但漂移未必是算法问题很多时候是数据质量或传感器标定问题。第一种漂移设备静止时地图点云在雷达坐标系里不动但里程计轨迹在缓慢移动。这种通常是IMU零偏没校准好或者IMU话题频率不对。mid360内置IMU的零偏通常在出厂时标定过如果不是自己拆机过不太容易出问题。更多情况是imu_rate填错了比如实际IMU输出100Hz配置里却写了200Hz滤波器的时间戳对不上轨迹自然会飘。第二种漂移建图过程中地图整体在旋转或者打弯。这种通常外参不正确特别是IMU和雷达之间的旋转外参。解决办法是重新做外参标定标定时的运动要多包含旋转纯平移的数据不适合标定旋转外参。第三种漂移地图在场景环境退化区域发生跳变比如长直走廊。这时候FAST-LIO靠IMU撑着如果IMU也有漂移会出现轨迹慢慢偏到墙上。这属于算法局限可以通过在场景中增加特征点来缓解比如贴一些图案或摆几个箱子和椅子给雷达制造可配准的特征。如果你懒得做完整的外参标定至少可以把mid360的IMU和雷达外参写成单位矩阵然后跑一段数据看看轨迹是否反转。轨迹反转基本是外参的旋转矩阵方向错了把外参矩阵取负或者交换轴序再去试。这个方法粗暴但不失为一种快速验证手段。5.4 数据录制、回放与性能监控的实用技巧最后聊点平时不被人提但很实用的技巧。数据录制建议开一个专门的终端提前写一个别名或者脚本把rosbag record参数固定下来避免每次现敲漏掉话题。我自己的录制脚本一般是rosbag record /livox/lidar /livox/imu -O $(date %Y%m%d_%H%M%S).bag回放时如果出现播放速率跟不上不要加-r 2这种加速参数FAST-LIO对IMU流的时间敏感加速播放会让IMU预积分崩掉。宁可等它慢慢播放也不要为了省时间破坏数据流。性能监控方面用htop看CPU和内存是最直观的。如果CPU长期100%说明抽稀参数太小或点云频率过高。这时候调大point_filter_num不要想着换更强的电脑——在车上和机器人上CPU资源本来就紧调参比换硬件更实际。另外如果你打算把FAST-LIO的输出接入到后续的导航或者路径规划里记得保存好里程计话题/Odometry和点云地图。FAST-LIO本身不输出占据栅格地图你需要自己用octomap或者cartographer的2D投影库把pcd转成栅格地图这一块我也踩过坑但那是另一个话题了。6. 写在最后从能跑到跑好的几个进阶方向FAST-LIO跑通只是第一步真正让它成为可靠工具还需要一些后续工作。我个人建议按这个顺序来完善你的系统第一把雷达驱动、FAST-LIO节点、录制脚本整理成一套可复用的launch文件参数固化下来。别每次都手动启动三四个终端容易漏。第二练好用rosbag离线调参的工作流。现场建图一旦失败重跑一遍数据又快又安全比在现场反复试错高效十倍。第三如果要在实际机器人上长期跑考虑加入回环检测后处理。FAST-LIO本身是里程计大场景长时间运行会有累计漂移配合回环检测或因子图优化精度会更接近工程可用的标准。从更长远看ROS 2生态下的激光雷达SLAM工具链正在成熟FAST-LIO也有相应的ROS 2版本。但我个人的经验是在传感器驱动和算法社区的成熟度上ROS 1的Noetic版本目前依然是最平滑的起点。德尔塔机器人上用mid360跑FAST-LIO和在扫地机器人底盘上跑环境和资源差异很大但核心的部署思路是一样的先把传感器链路打通再做标定最终才轮到调参。如果你跟我一样也是从零开始接触固态激光雷达和惯性里程计希望这篇实战记录能让你少踩几个坑。毕竟我踩过的坑已经够多了你踩新的就好。