刚拿到这台雷达的时候我心里想的是“装个驱动、编个包、跑个图半天就能搞定”。真上手之后才发现这一步一步里藏着不少弯。它用的是棱镜扫描结构不是传统机械旋转式驱动协议也不走通用点云那套FAST-LIO这个开源方案虽然跑起来很稳但它在起飞前的准备工作——驱动版本、时间同步、外参配置——哪一环掉链子后面建图都会露馅。这篇文章不绕弯子直接把从零开始装驱动、跑通FAST-LIO复现实测的每一步写清楚。主要适合刚拿到AVIA、想在自己机器上快速复现FAST-LIO做后续开发的读者也适合那些已经被编译报错折磨到想换硬件的人。1. 先理顺AVIA的数据链路为什么装驱动这事没那么简单1.1 AVIA的扫描机制会直接影响驱动和算法的处理方式以前给机械式雷达装驱动的时候思路很直观转一圈、出点云、发标准消息。AVIA不一样它内部用棱镜加振镜做非重复扫描采样轨迹近似李萨如曲线每一帧的采样点位都在变化时间积累越长视场覆盖就越密。这意味着单帧点云不能像机械雷达那样直接套均匀体素策略驱动必须考虑一段扫描周期内的点云积累方式。在驱动里雷达数据默认通过自定义消息发布不再只依赖sensor_msgs/PointCloud2。自定义消息里除了三维坐标还带每个点的相对时间偏移和反射率这是做运动补偿和时间对齐的关键。FAST-LIO当初就是围绕这类雷达设计的雷达惯性融合时直接吃这套时间戳信息。如果图省事把点云转成通用格式再喂给算法时间信息一旦丢紧耦合的优势就全没了所以驱动这条路还是得老老实实走。1.2 驱动和算法之间是“消息契约”关系从工程视角看FAST-LIO和这个ROS驱动的衔接其实就靠几个固定话题。驱动负责把雷达的以太网数据包解析出来发布成点云和IMU数据FAST-LIO的节点订阅这两个话题完成状态估计和建图。听起来简单但实际安装时卡人的点往往在这几处消息类型要匹配、话题名要对上、时间同步要开启。这里有个容易混淆的点驱动支持把点云同时发布为自定义消息和标准点云但FAST-LIO编译时认的是自定义消息头文件。如果你在工作区里少了驱动包FAST-LIO编译会直接报找不到头文件。这不是算法本身的问题而是消息类型没对上。后面第四章我会细说这个报错。1.3 没有理由不选driver2我用的是livox_ros_driver2这个新版驱动没有去折腾老版本。原因很实际新驱动同时支持ROS1和ROS2我当前环境是Ubuntu 20.04加ROS1 Noetic直接用catkin编译就行将来如果要迁到ROS2环境重编一遍即可不用换驱动包。而且新驱动对这款雷达的支持更完整多点云恢复、断线重连这些能力都在维护。对比项老驱动driver2驱动自定义点云消息支持支持ROS2支持不支持支持AVIA产品适配仅部分型号完整支持断线重连与多雷达恢复较弱增强当前维护状态基本冻结持续更新所以如果你的工作环境不是特殊的老ROS版本直接用driver2不要走弯路。2. 环境选型与硬件连接开工前这三十分钟别省2.1 系统版本怎么选我这边选的是Ubuntu 20.04 LTS加ROS Noetic。选它不是因为版本新而是各个依赖链在Noetic上的验证最全。FAST-LIO官方仓库基于Noetic环境的测试案例最多驱动2也对Noetic做了适配。如果手头是Ubuntu 18.04加ROS Melodic大概率也能跑但需要手动处理一些依赖冲突比如部分PCL版本行为不一致。硬件上内存8G以上是底线CPU四核以上编译体验会好很多。磁盘方面留出至少20G空闲空间catkin工作区、依赖库和后续的sdk工具会占不少。另外建议用独立有线网卡来连雷达不要用WiFi点云数据量虽然不算巨大但WiFi的延迟抖动对实时建图不友好。2.2 网口配置和默认IP雷达通过以太网口输出数据默认IP一般是192.168.1.100。你要做的第一件事就是把电脑的网卡配到同一个网段比如192.168.1.50子网掩码255.255.255.0。这一步可以直接用命令搞定也可以走图形界面。sudo ip addr add 192.168.1.50/24 dev eth0偷懒的做法是设成DHCP自动获取但我强烈建议改成手动IP。原因有两个一是避免电脑上其他网卡抢占默认路由造成雷达数据断流二是后续调试驱动时固定IP排查问题方便得多不用每次重新看地址。我最初图省事用DHCP结果雷达一会儿能连一会儿不能连后来才发现是系统里另一个虚拟网卡在抢网段。接线完成后先做最基本的验证给雷达上电看指示灯状态然后ping默认IP。ping 192.168.1.100能ping通说明物理链路没问题。ping不通先查网线、网口、供电不要急着去编译驱动。链路不通后面一切白搭。2.3 把SN号抄下来别等报错再回头找每台雷达的机身上都有一个唯一的SN号这个号在白名单配置里必须用到。建议开工前就把SN号抄到一个文本里比如SNSN12345678901234这样的格式。激光雷达、包装盒、出厂标签上的编号要保持一致如果发现对不上以机身上的为准。另外要顺带确认固件版本。驱动运行起来后可以通过诊断信息看到固件版本号。如果版本过老建议先更新固件再继续否则偶尔会出现点云丢帧、设备掉线的诡异问题。固件更新本身不难但要在Windows环境下处理这个后面根据需要再做不是每次都要更新。3. Livox Driver 2安装全过程从工作区编译到时间同步3.1 创建工作区与编译驱动驱动安装的第一步永远是建立干净的catkin工作区。我之前在别人的环境里直接clone到已有工作区结果各种旧缓存冲突折腾了半天才发现是残留的build目录在作祟。所以这次我从零开始。mkdir -p ~/catkin_ws/src cd ~/catkin_ws catkin_make先把空工作区编译一遍确认基础依赖正常。然后把驱动2源码放到src目录下再执行编译。注意编译前要先加载ROS环境否则找不到catkin命令source /opt/ros/noetic/setup.bash cd ~/catkin_ws catkin_make -j4-j4是让编译并行度控制在4机器性能一般时比默认并行更稳不容易把内存吃满导致编译中断。编译结束后记得source工作区环境source devel/setup.bash这里有个细节以后每次开新终端都需要重新source要不就写进~/.bashrc。我建议写进去省得每次开shell都忘。3.2 白名单配置SN不对驱动不干活驱动编译完只是第一步还差一个关键配置——白名单。打开config目录下的白名单文件把刚才抄下来的SN号填进去一行一个。如果有多台雷达每行写一个。# whitelist.txt 示例注释符号是# SNSN12345678901234为什么不填SN雷达就不输出点云因为驱动默认有一个发现模式如果没有白名单雷达也会被找到但工作状态可能停在“未使能”状态点云不发布或发布频率异常。填上白名单之后驱动才会明确锁定这台设备按正常扫描模式输出。启动雷达节点注意选择对应型号的launch文件不要照抄其他型号的launch。虽然名字不同但对应的可能是选配不同传感器型号的配置roslaunch livox_ros_driver2 msg_AVIA.launch启动后等几秒用rostopic list看一下有没有/livox/lidar这个话题rostopic list | grep livox再到rviz里添加点云显示主题选/livox/lidar。看到点云在屏幕上一片一片地累积说明驱动这一层已经通了。如果rviz里一片空白优先回到白名单和IP配置重新检查不要先怀疑硬件。3.3 时间同步是最容易漏掉的一步FAST-LIO是雷达惯性紧耦合方案时间戳不对齐算法等于拿错误数据做积分。这款雷达支持网络时间同步协议通常有两种做法。方法A配置系统级PTP同步。直接用linuxptp工具把雷达作为主时钟、电脑作为从时钟持续对时。这种方式精度高适合车载或机器人平台的长期建图。但要注意本机网卡需要支持硬件时间戳否则PTP精度会打折扣。方法B不搞复杂PTP只在驱动参数里调整时间戳容差让点云时间采用接收时刻。这种方式适合室内快速验证建图精度在日常场景下够用但车辆高速运动或剧烈抖动时误差会明显变大。我自己的建议是如果只是室内走走、验证功能方法B够了如果后面要上车或者做长时间建图一定要上方法A。时间同步做到什么程度直接决定FAST-LIO会不会跑飞这个坑我后面还会提。4. FAST-LIO编译中三个容易让人劝退的报错与处理4.1 源码与依赖项把FAST-LIO源码clone到同一个工作区的src目录下。因为前面驱动源码已经在src里了所以整个工作区结构看起来像这样~/catkin_ws/src/ ├─ livox_ros_driver2/ └─ fast_lio/依赖方面Ubuntu 20.04默认带的PCL和Eigen一般够用。先用系统包管理器把基础依赖装上sudo apt install libeigen3-dev libpcl-dev然后就可以编译整个工作区了。编译顺序不需要手动指定catkin会自动处理包之间的依赖关系前提是两个包必须在同一个工作区里。4.2 报错一找不到自定义消息的头文件新手最容易遇到的问题就是编译时提示找不到livox_ros_driver2/CustomMsg相关头文件。看到这个报错先别慌原因无非两种一是驱动源码压根没放在同一个工作区导致自定义消息没被编译生成。 二是工作区之前有编译残留环境变量没source干净。处理方式很直接确认驱动在src下然后删除build和devel目录重新编译。rm -rf build devel catkin_make -j4这里要注意一个细节如果build目录存在很久了里面的CMake缓存会记住旧路径导致即使你源码放对了编译时依然找不到新生成的头文件。重置是最省心的方案。4.3 报错二Eigen版本导致的编译失败另一个高频报错和Eigen版本有关具体表现是编译时提示某些宏或函数找不到。不同版本的Eigen在头文件布局上有差异FAST-LIO源码里有些调用是基于某个版本写的遇到不兼容版本就会挂。处理办法不是硬改源码而是显式指定Eigen的路径。在FAST-LIO的CMakeLists里通常已经有Eigen的查找语句确保找到的是系统里真正安装的那份find_package(Eigen3 REQUIRED) include_directories(${EIGEN3_INCLUDE_DIR})如果还是报错检查一下是否装了多个Eigen版本比如系统自带一套、conda环境又带一套。编译时环境变量混乱就会选错。我后来干脆把conda的环境变量从bashrc里临时注释掉才让编译恢复稳定。4.4 报错三编译通过但一启动就崩溃比编译报错更气人的是编译全过启动就段错误或者地图点全飞到天上去。遇到这种情况不要第一时间调FAST-LIO的参数先回到驱动层验证数据。rostopic echo /livox/lidar -n 3 rostopic echo /livox/imu -n 3确认点云话题每帧的坐标是有限数值没有NaN确认IMU话题有数据角速度和加速度量级合理。如果这两路数据本身就空或带NaNFAST-LIO怎么调都白搭。数据没问题的前提下再去看FAST-LIO的launch配置重点检查话题名和外参文件路径。4.5 修改launch文件匹配自己的设备打开FAST-LIO自带的launch文件有几个必改项点云话题改成/livox/lidarIMU话题改成/livox/imu雷达类型标识选到对应型号的枚举值外参矩阵改成当前IMU和雷达的实际安装位置关系外参初值可以先填一个粗略值比如雷达和IMU挨得比较近时平移可以填零旋转按安装朝向大致填。但要注意这只适合初步验证。后面要做正经建图外参必须标定否则雷达和IMU坐标系不一致紧耦合算法很容易发散。5. 实机测试从“能出图”到“跑得稳”还需要做的事5.1 静态测试先看数据是否可信启动驱动节点和FAST-LIO节点后第一件事是让雷达保持静止几秒钟观察rviz里的点云。由于是非重复扫描点云会随着时间累积变得越来越密这是正常现象不要以为点云密起来了就是出问题了。然后拿在手里小范围晃动看里程计轨迹是否平滑点云地图有没有明显的重影。如果发现点云稀得不像话或者地图边缘毛刺很多先回驱动层检查频率和帧率不要急着调FAST-LIO。我在第一次静态测试时就发现点云只铺了半个视场看起来像雷达坏了。后来查驱动参数发现是视场角设置和默认配置不一致。这类问题靠调参就能解决不用动硬件。5.2 动态测试室内纹理场景最能暴露问题静态通过后进入动态测试。室内环境是最好的测试场因为墙壁、门框、转角都有清晰的纹理非常容易看出点云对齐质量。手持雷达慢速走一圈回来时观察门框边缘。好的建图结果门框边缘宽度应该在10厘米以内肉眼看着是“一条线”不是“一条带子”。再做一个快速转动测试。拿着雷达快速左右摇头观察里程计是否瞬间跳变。因为FAST-LIO依赖IMU来补偿剧烈运动如果IMU数据没接入或者时间同步没做好快速转动时轨迹会立刻飞掉。这个测试能帮你快速区分问题在哪个环节单纯地图边缘糊可能是外参不准快速转动后回不到原位大概率是IMU通道或时间同步的问题地图直接散架则要怀疑驱动数据本身。5.3 跑飞了应该从哪个参数开始调跑飞是所有SLAM调试里最让人头疼的事但FAST-LIO的调参顺序相对固定。我会按这个顺序操作第一先检查外参矩阵。很多跑飞案例其实都是外参给得离谱把平移写成米级数值或者旋转方向反了。第二再检查IMU噪声参数。默认参数是针对某款IMU标定的如果你的IMU和那一款性能差异很大噪声协方差要相应调整。大体上噪声设置太小算法过于信任IMU快速运动时会发散设置太大又等于放弃IMU退化成纯雷达里程计。第三查看运动补偿开关配置。有些版本默认开启运动补偿如果你的点云时间戳本身就飘补偿反而引入误差。这三个顺序不要乱一上来就动噪声参数往往调了半天发现是外参写反了。5.4 场景差异室内和室外要分开看室内场景验证的是对齐精度室外场景验证的是抗干扰能力。到室外有植被、树木这类小物体时非重复扫描的优势会体现出来——点云覆盖更密小的树枝和栏杆也能看清。但室外也有个问题开阔环境下雷达有效点云变少如果周围太空旷建图的退化风险会增加。这时候可以适当降低点云配准的距离阈值让算法不要被远处的稀疏点带偏。我的建议是先室内后室外分别记录一段rosbag。这样出问题的时候不用反复扛着设备跑现场直接离线回放bag就能反复调参。6. 复现遇到问题时照着这张表排查6.1 常见故障现象、直接原因和优先处理项我把这几个月看过的、自己踩过的坑汇总成一张表遇到问题先对着表排查比漫无目的改参数有效率得多。现象可能原因优先处理雷达上电后灯亮但ping不通网卡IP不在同一网段、网线松动、供电不足固定电脑IP重新插拔网线检查电源驱动启动后/livox/lidar无数据白名单没填SN、launch文件型号选错检查白名单确认启动的是AVIA对应launch点云断断续续、丢帧DHCP抢地址、网卡降速、USB转网卡不稳定换直连网口手动IP不用USB转接FAST-LIO编译找不到自定义消息头驱动不在同一工作区、build缓存残留重置build目录确认源码路径一启动就段错误点云含NaN、IMU无数据先echo话题验证数据再翻配置快速转动时轨迹飞掉IMU未接入、时间同步没开、外参错误检查IMU话题开启时间同步复查外参地图边缘糊、重影严重外参不准、运动补偿开关异常重新标定外参检查补偿配置6.2 一个问题反复出现时怎么缩小范围如果你遇到的问题不在这张表里教你一个通用的缩小范围方法。先把系统拆成三段硬件链路、驱动发布、算法订阅。硬件链路用ping验证能通就是好的。驱动发布用rostopic hz查看话题频率用rostopic echo查看消息内容频率正常、内容无NaN基本就是好的。算法订阅出了问题就用rosbag录一段正常数据离线播放时逐步改参数对比效果。这个方法几乎能定位90%的复现问题。很多时候你以为是算法参数要调实际上驱动发布频率就不对。先数据后算法排查顺序不要反。6.3 一个不值得被忽略的“玄学”问题最后说一个很多人遇到过但查不到答案的现象雷达运行一段时间后点云数据自己停了驱动进程还在但话题就是没输出。我第一次遇到时怀疑是硬件故障折腾半天最后发现是网口的节能策略把链路休眠了。Linux的网卡默认开启了节能模式长时间没有大流量时会进入省电状态。雷达的点云虽然是持续输出但如果你在一个低动态场景里数据量相对稳定网卡可能就降级甚至休眠。处理方法是把网卡的节能策略关掉常见操作如下sudo ethtool -s eth0 autoneg off speed 1000 duplex full具体网卡命令可能不同但思路一样强制网卡保持全速工作模式。这个问题不属于参数调优属于系统配置范畴却实实在在会让整个复现项目卡住。遇到这种“硬件看起来在工作、数据就是不来”的情况先怀疑网卡节能。跑通之后回头看整套链路其实不复杂但链条上的每一环都有对应的坑。我印象最深的一点是不要总想着“先跑起来再说”花半个小时把环境理顺、把时间同步确认好后面调算法的时间能省一大半。另外一个小技巧是在整个调试阶段养成录bag的习惯出问题时离线回放比在现场干等强太多。