搞了快两周把LVI-SAM在Ubuntu20.04上从源码编译到实机跑通中间还折腾了6轴IMU的适配。这玩意儿网上教程不少但大多只讲到“能跑数据集”就停了真到自己上手接硬件全是坑。这篇文章把我整个复现过程和实机部署流程捋一遍重点说说6轴IMU接入时改了什么、为什么这么改给后面要搞LVI-SAM的人省点时间。LVI-SAM是Tixiao Shan在LIO-SAM基础上扩展出来的紧耦合SLAM方案融合了激光雷达、相机和IMU三类传感器。它解决的问题很明确单靠激光雷达在退化场景长走廊、空旷场地容易飘视觉在光照变化和快速运动时容易丢IMU短时间精度高但长期会漂三者融合正好互补。官方代码基于ROS1Ubuntu20.04对应Noetic版本整个系统拆成视觉里程计、激光惯性里程计、回环检测与地图优化三个模块。对于正在系统学ROS、准备入门激光视觉融合SLAM的人来说LVI-SAM是一个绕不开的经典开源项目。1. 整体方案与核心设计思路1.1 LVI-SAM到底在做什么先理解这系统的整体结构。LVI-SAM本质上是两个紧耦合子系统并行工作一个视觉惯性系统VIS一个激光惯性系统LIS。两个子系统通过因子图共享状态估计激光惯性系统的结果给视觉系统提供初始值和回环候选视觉系统的结果反过来给激光系统提供姿态先验。这种双向耦合比简单的传感器数据叠加要稳得多。代码上对应三个核心节点visualOdometry处理相机图像提取特征点与IMU预积分结果做视觉-惯性里程计输出6自由度位姿。imuPreintegration接收IMU原始数据做预积分维护因子图为其他模块提供高频位姿先验。mapOptimization接收激光雷达点云做特征提取角点、平面点scan-to-map匹配同时处理回环检测和图优化输出最终建图结果。这三个节点之间的关系用一条数据流来描述就是IMU数据进imuPreintegration得到当前位姿估计这个估计同时喂给visualOdometry做视觉匹配初始值、喂给mapOptimization做激光匹配初始值。两个子系统各自产生的结果再回到因子图里做全局优化。1.2 从LIO-SAM到LVI-SAM视觉带来了什么如果你看过LIO-SAM的源码再看LVI-SAM会觉得很亲切因为很多代码结构几乎一样。LVI-SAM最大的改动是在原有的雷达惯性系统上叠加了视觉里程计作为额外的观测来源并在因子图中增加了视觉因子。为什么要引入视觉雷达在结构化环境中表现很好但在长走廊、隧道这类几何特征单一的场景下激光特征退化匹配就容易飘。相机能提供丰富的纹理信息在这些场景下反而能帮上大忙。反过来相机对光照敏感快速运动时图像模糊这时候雷达又比视觉可靠。两个传感器各有短板融合起来才能在不同场景下都有可接受的精度。另一个值得注意的设计是视觉里程计和激光里程计之间采用的是紧耦合而不是简单的松耦合松耦合。LVI-SAM不是先把两个系统的结果拼在一起而是在因子图层面做联合优化这样能更好地处理传感器噪声和相关性问题。对实际部署来说紧耦合的好处在于即使某一个传感器短暂失效整个系统也不会立刻崩掉。1.3 这套方案有什么取舍LVI-SAM的取舍还是挺明显的。它用三传感器融合精度和鲁棒性上来了但系统复杂度和算力要求也上来了。作者的测试环境用的是一台高性能笔记本加独立显卡实机部署在NVIDIA Jetson AGX Xavier这类平台上跑起来还比较流畅但你要是想在树莓派或者低端ARM板上跑帧率会非常难看。另外LVI-SAM对传感器标定和同步的要求比较高。三个传感器之间的外参、时间偏移如果不对整个融合效果会直线下降。这也是为什么很多人在数据集上跑得很好一上实机就开始各种飘的原因。实机部署的难点根本不在算法本身而在工程问题。2. 环境搭建与依赖准备2.1 Ubuntu20.04和ROS Noetic是刚需LVI-SAM官方没有明确说支持哪个ROS版本但代码里大量使用了ROS1的API跑在Noetic上没有任何问题。Ubuntu20.04配ROS Noetic是当前ROS1生态最主流的组合软件包兼容性最好。装系统没啥好说的需要注意的是如果你用双系统建议单独给Ubuntu分一个至少100GB的盘因为光是依赖库、源码编译产物和数据集就能轻松吃掉几十GB。装完系统后先别急着装ROS先把软件源换成国内镜像源这个能省下后续大量下载时间。ROS Noetic的安装推荐直接用鱼香ROS的一键安装脚本。这东西虽然名字听着有点草台班子但实际用过之后会发现确实省心脚本会自动帮你配置软件源、安装ros-noetic-desktop-full、初始化rosdep整个过程基本不用手动干预。命令很简单wget http://fishros.com/install -O fishros . fishros按照提示选择ROS1 Noetic安装项就行。装完之后确认一下环境变量有没有写进~/.bashrcsource /opt/ros/noetic/setup.bash echo source /opt/ros/noetic/setup.bash ~/.bashrc验证一下能否正常使用roscore能启动就说明ROS装好了。2.2 核心依赖逐个装Ceres、GTSAM、OpenCV、PCLLVI-SAM编译之前有几个核心依赖需要提前搞定任何一个出问题都可能导致编译失败。第一个是Ceres Solver版本建议用1.14.0。LVI-SAM在mapOptimization节点中用到了Ceres做scan-to-map匹配的优化求解。这个库直接apt装的话版本会比较老而且经常和后续编译的LVI-SAM出现ABI兼容问题所以推荐源码编译sudo apt-get install -y cmake libgoogle-glog-dev libgflags-dev libatlas-base-dev libeigen3-dev libsuitesparse-dev git clone https://github.com/ceres-solver/ceres-solver.git cd ceres-solver git checkout 1.14.0 mkdir build cd build cmake .. make -j$(nproc) sudo make install第二个是GTSAM这是因子图优化的核心依赖LVI-SAM的imuPreintegration节点全靠它做增量平滑。GTSAM没有对应的Ubuntu apt包需要源码编译。作者推荐使用4.0.2版本实测4.1.1也能编过但建议还是跟着官方文档走4.0.2git clone https://github.com/borglab/gtsam.git cd gtsam git checkout 4.0.2 mkdir build cd build cmake -DGTSAM_BUILD_TESTSOFF -DGTSAM_BUILD_UNSTABLEON .. make -j$(nproc) sudo make install注意CMake参数里这个-DGTSAM_BUILD_UNSTABLEON一定要开否则LVI-SAM里引用的部分头文件会缺失。第三个是OpenCV和PCL。这两个不用特殊处理Ubuntu20.04自带的OpenCV 4.2.0和PCL 1.10就够用不需要额外折腾。LVI-SAM代码本身对OpenCV的调用并不深入主要就是读图像、特征提取、描述子匹配这些基础操作。Eigen也不用单独装编译Ceres和GTSAM的时候会把它带上来。2.3 创建catkin工作空间并编译LVI-SAM依赖装齐了接下来创建catkin工作空间。以我实际使用的目录结构为例mkdir -p ~/lvi_sam_ws/src cd ~/lvi_sam_ws/src git clone https://github.com/TixiaoShan/LVI-SAM.git cd .. catkin_make如果没有意外这个编译过程会跑很久。第一次编译时GTSAM的头文件和库文件可能会找不齐常见报错是找不到gtsam/gtsam.h或者metis.h。这是因为GTSAM安装后头文件路径没有进到系统默认搜索路径。解决办法是修改LVI-SAM的CMakeLists.txt在include_directories里手动加上GTSAM头文件路径include_directories( include /usr/local/include/gtsam /usr/local/include/gtsam/3rdparty/metis )编译完成后如果devel/lib目录下生成了lvi_sam对应的三个可执行文件说明编译通过。3. 数据集复现跑通官方bag验证系统3.1 下载测试数据与启动launch文件源码编译通过只是第一步接下来要在数据集上验证整个系统能正常工作。LVI-SAM作者提供了测试用的rosbag文件里面包含了相机图像、激光点云和IMU数据。我用的是官方推荐的handheld bag传感器数据比较全适合验证系统闭环效果。启动前需要修改LVI-SAM的配置文件路径在LVI-SAM/config/params.yaml。里面几个关键参数需要确认sensor: # 传感器话题名 lidar: /velodyne_points imu: /imu/data camera: /camera/image camera: # 相机内参 fx: 467.6719 fy: 465.5709 cx: 344.7813 cy: 228.5359 distortion: [0.0815, -0.1327, -0.0002, 0.0001, 0.0]不同版本的bag话题名可能不一样先跑rosbag info看一下数据包里面的话题名再对照修改。启动方式source ~/lvi_sam_ws/devel/setup.bash roslaunch lvi_sam run.launch另开一个终端播放bagrosbag play your_bag.bag正常情况下几秒钟之后Rviz里会开始出现点云地图和轨迹线。初始化需要一点时间系统会对IMU做静止初始化。3.2 跑数据集时关注什么数据集跑通了别急着庆祝先观察几个关键点来判断系统状态是否健康看Rviz里的按时间上色的点云地图。地图应该随着传感器移动而不断扩展轮廓清晰没有明显拖影。如果地图出现重影说明点云配准有问题最常见的原因是IMU噪声参数不对或外参标定错误。看轨迹输出。轨迹应平滑连续没有跳变。如果出现跳到远处又跳回来的现象大概率是回环检测误匹配导致图优化把轨迹拉歪了。看CPU占用。在普通笔记本上用CPU跑如果点云帧率不高CPU占用在300%-500%之间是正常的。如果长期800%以上后面实机部署就得考虑降低帧率或者用GPU推理了。官方bag跑完整个系统的基本链路就算验证通过了。从零开始到这一步大概需要一天时间大部分时间都耗在编译和依赖问题上。4. 6轴IMU适配原理与实操细节4.1 为什么6轴IMU要单独适配这是全文最核心的部分。LVI-SAM原始代码默认使用9轴IMU也就是包含加速度计、陀螺仪、磁力计的IMU模组。9轴IMU的磁力计可以提供绝对航向参考帮助系统在初始化阶段把世界坐标系的航向对齐到地磁方向同时也能抑制偏航角随时间漂移。但实际市面上的很多IMU模组尤其是那些体积小、功耗低的模块都是6轴的只有加速度计和陀螺仪没有磁力计。用6轴IMU接入LVI-SAM如果直接照搬默认配置会出现几个典型问题第一初始航向角不可观。六轴IMU静止时加速度计只能感知重力向量告诉你哪个方向是“下”陀螺仪只能感知角速度变化告诉你转了多少但无法告诉你面朝哪个方向。整个系统的初始偏航角就失去了参考基准只能依赖视觉或激光的第一次观测来初始化。第二偏航角累计漂移。没有磁力计校正光靠陀螺仪积分偏航角必然会产生缓慢漂移。短时间运行问题不大但长时间建图会看到轨迹逐渐扭曲。第三代码中有一些隐含假设。LVI-SAM中IMU消息里的orientation字段在部分代码路径下会直接作为先验使用。如果IMU驱动输出的是一个没有绝对航向参考的orientation这些先验就会带偏系统。那怎么解决思路是在驱动层面正确处理6轴IMU的数据发布在算法层面调整LVI-SAM的初始化逻辑让系统不完全依赖磁力计提供航向。4.2 IMU数据发布格式至关重要的sensor_msgs/Imu先说IMU数据怎么发。ROS中IMU数据的标准消息类型是sensor_msgs/Imu核心字段有orientation四元数表示的姿态如果IMU融合算法能给出姿态就用它给不了就填单位四元数并把orientation_covariance[0]设为-1告诉下游“这个字段不可用”。angular_velocity三轴角速度单位rad/s来自陀螺仪。linear_acceleration三轴线性加速度单位m/s2来自加速度计。很多自制IMU驱动的坑就出在orientation字段上。你需要想清楚你的6轴IMU能不能输出可靠的姿态如果你的IMU模块内部有DMP数字运动处理器比如MPU6050的DMP固件它能融合加速度计和陀螺仪数据输出稳定的roll和pitch但yaw是积分出来的没有绝对参考。这种情况下建议把DMP输出的四元数填进orientation字段但要注意这个yaw会随时间漂移算法端不要把yaw当作先验。如果你的IMU模块只是裸的加速度计和陀螺仪没有融合算法那更简单orientation直接填单位四元数把orientation_covariance[0]设为-1让下游自己处理姿态估计。LVI-SAM的预积分模块本来就要自己维护姿态不会依赖这个消息里的orientation。另外两个参数的设置也要注意。linear_acceleration发布时必须除以重力加速度g。ROS的Imu消息规范里linear_acceleration的单位是m/s2但很多IMU驱动会直接输出原始加速度计值单位是g比如静止时输出[0, 0, 1]这个在ROS里其实是错的应该输出[0, 0, 9.80665]。LVI-SAM内部对IMU数据的处理有单位假设搞错了重力方向就完全不对了。angular_velocity的单位是rad/s不是deg/s这个坑也踩到过。4.3 标定IMU内参imu_utils Allan方差6轴IMU要跑出好效果光把数据发对还不够噪声参数必须标定。LVI-SAM的config/params.yaml中关于IMU有这几个参数imu: # IMU噪声参数单位连续时间 noise: [0.005, 0.005, 0.005, 0.05, 0.05, 0.05] bias: [0.001, 0.001, 0.001, 0.01, 0.01, 0.01]前面的noise对应加速度计和陀螺仪的噪声密度noise density后面的bias对应随机游走bias random walk。这两个参数如果不标定直接照搬教程值很多时候也能跑但精度会差一截。尤其是在实机低速运动时IMU噪声参数对系统初始化速度的影响非常明显。IMU内参标定的标准做法是用Allan方差分析工作在ROS环境下的开源工具是imu_utils配合code_utils。标定的大致流程是把IMU固定在一个稳定的平台上静止放置2小时以上录制一段长时间静止数据。用imu_utils对录制的数据做Allan方差分析得到加速度计和陀螺仪各轴的噪声密度和随机游走。把得到的数值填进params.yaml。这套工具编译起来也有点麻烦因为code_utils要先编译然后imu_utils依赖它。建议直接跟着官方仓库的README走。如果不想搞这么麻烦一个应急的替代方案是用9轴IMU模组比如MPU9250的数据手册里的典型值但效果只能算能用不算最优。4.4 外参标定IMU和相机/雷达之间的位姿如果说内参标定决定系统精度上限外参标定就决定系统能不能正常收敛。LVI-SAM的params.yaml里有三个外参矩阵extrinsic_rot: [1, 0, 0, 0, 1, 0, 0, 0, 1] extrinsic_trans: [0.0, 0.0, 0.0]这个外参描述的是IMU坐标系相对于雷达坐标系的变换也就是雷达和IMU的相对位姿。注意这和你日常理解的“相机到雷达外参”不同LVI-SAM用的是IMU作为基准所以外参表达的是雷达在IMU坐标系下的位姿。如果你用官方数据集跑外参不用动。但实机部署时这个外参必须标定。传感器外参标定的工具选择看情况IMU到相机推荐用Kalibr这是苏黎世理工开源的相机IMU标定工具可以同时标定相机内参、相机到IMU外参和时延。虽然Kalibr支持的ROS版本比较老在Noetic上需要打补丁编译但效果确实是目前开源方案里最好的。IMU到雷达方案不统一常见的有lidar_imu_calib、direct_visual_lidar_calibration等。我实测下来效果比较稳定的是lidar_imu_calib输入是静止环境下雷达点云和IMU数据通过对比雷达拟合平面和IMU重力方向来标定外参中的旋转部分。外参标定的一个重要原则是不要用手量尺子去量传感器之间的物理距离。物理测量误差大而且传感器的参考坐标系通常在外壳内部你根本量不到准确值。用标定工具依靠数据自动求解比手工测量靠谱得多。4.5 代码层面针对6轴IMU的改动建议内参、外参、话题格式都处理好了还有最后一个收尾工作检查LVI-SAM代码里有没有对9轴IMU的隐含假设。我编译的源码版本里imuPreintegration.cpp中IMU预积分初始化部分的逻辑是用前几帧的加速度均值来估计重力方向然后用重力方向来对齐世界坐标系。这个逻辑使用6轴IMU时天然可行因为加速度计不需要磁力计就能感知重力。但要留意的是如果系统启动时IMU不是静止的初始化阶段对重力方向的估计就会出错导致后续整个地图都是歪的。这严格来说不是6轴IMU的问题但6轴IMU因为没有绝对航向参考对初始化姿态错误更敏感。另一处值得审查的地方是visualOdometry.cpp中视觉-惯性联合初始化的代码。部分版本的代码在视觉和IMU联合初始化时会假设视觉给出的相对旋转和IMU积分出的相对旋转之间有一个近似恒定的偏置这个偏置在6轴IMU上就是初始yaw不可观带来的。如果视觉和IMU外参标定不够准或者视觉特征跟踪质量不好初始化阶段就可能计算出一组很差的外参初值后面怎么优化都救不回来。我实际采用的最省事方法是在LVI-SAM源码中不要修改核心算法逻辑而是先把IMU驱动做好确保发布的IMU数据干净、坐标系正确、时间戳准确。绝大多数人在实机上的问题根本不是代码需要改而是IMU数据本身就不对。4.6 6轴IMU适配的检查清单把上面说的内容整理成一个自检清单实机部署前逐项过一遍检查项正确状态错误表现linear_acceleration单位m/s2静止时z轴约9.8静止时z轴约1说明发的是g值angular_velocity单位rad/s数值过大说明发的是deg/sorientation字段不可用时covariance[0]-1填了错误姿态导致初始化发散时间戳持续单调递增与雷达/相机在同一时钟域时间戳跳变或为0静止初始化系统启动时IMU保持静止3-5秒启动时晃动导致重力方向估计错误外参标定工具计算非手工测量地图出现系统性倾斜或重影5. 实机部署流程从桌面到小车的最后一公里5.1 实机传感器配置与硬件选型数据集跑通只是热身实机上跑通才是最终目标。以我手头的测试平台为例传感器配置如下激光雷达速腾聚创RS-LiDAR-16线16线机械式雷达10Hz频率点云话题/rslidar_points。相机Intel RealSense D435i虽然D435i自带IMU但我实际用的是外置的独立IMU模组因为RealSense自带的IMU噪声偏大稳定性也一般。IMU6轴的BMI088模组通过串口转USB接入200Hz输出话题/imu/data。计算平台Intel NUC11i7-1165G7 16GB内存跑LVI-SAM勉强够用。这套配置不算高端但能说明的是LVI-SAM对传感器的要求其实是“中规中矩”雷达16线以上、相机30帧以上、IMU 100Hz以上都能跑出不错的效果。传感器固定和安装是实机部署最容易被低估的环节。三个传感器之间的坐标变换关系要尽可能保持刚性固定要足够牢靠任何微小的松动都会导致外参失效。我见过一个案例IMU只是用双面胶粘在支架上结果在振动环境中外参漂移建图精度大幅下降。5.2 雷达到相机、雷达到IMU的时间同步问题实机部署中时间同步比外参标定更容易被忽略但影响却是灾难性的。如果你传感器的驱动各自为政一个用系统时间戳一个用传感器内部时间戳LVI-SAM收到的“同时刻”数据实际上差了100毫秒以上融合效果会非常差。目前比较常用的软件同步方案是在驱动层面让所有传感器的时间戳都使用主机系统时钟。对USB接口的传感器相机、IMU驱动收到数据时打上系统时间戳对网络接口的传感器雷达收到网络包时打上系统时间戳。如果传感器数量更多、精度要求更高可以考虑硬件同步用触发线把相机曝光时刻和雷达扫描时刻对齐。但对绝大多数人来说软件同步已经够了。一个实测经验如果雷达是10Hz、相机是30Hz、IMU是200Hz只要时间戳都是系统时钟LVI-SAM内部会自己处理不同频率之间的对齐和插值不需要你做额外的频率匹配。5.3 修改params.yaml适配实机实机跑之前需要把params.yaml中的话题名改成你自己的话题名sensor: lidar: /rslidar_points # 你雷达驱动发布的话题 imu: /imu/data # 你IMU驱动发布的话题 camera: /camera/color/image_raw # 你相机驱动发布的话题同时把前面标定得到的相机内参、IMU噪声参数、外参矩阵全部填进去。这部分工作没有什么捷径只能一项项改、一项项试。5.4 实机启动与调试流程实机启动建议按以下顺序来第一步启动雷达驱动确认点云话题有数据、时间戳正常。第二步启动相机驱动确认图像话题有数据、画面清晰不模糊。第三步启动IMU驱动用rostopic echo查看IMU消息内容静止时检查加速度计是否约等于重力加速度转动时检查陀螺仪是否有响应。第四步把所有传感器数据录制到rosbag里用rosbag record先录一组数据离线回放调试。这一步非常关键能让你在室内安全地调参不用一遍遍推着车在走廊里跑。第五步离线跑通后再上线实时跑。我实际测试时最常遇到的问题是传感器之间的时间戳存在固定的偏移。表现是离线跑bag效果还行但一上线就跑飞或者地图扭曲。排查方法是用rosbag play --clock回放bag然后查看LVI-SAM的Rviz输出。如果离线效果和在线效果差异很大大概率是时间同步问题。用rostopic hz分别查看三个话题的频率再对比话题的时间戳分布基本能定位问题出在哪个传感器上。5.5 实机调试中的参数调整经验实机跑通后哪些参数值得微调IMU噪声参数标定出来的值先填进去如果初始化慢或者初始化失败可以把噪声密度调大一些让系统更快收敛。回环检测开关params.yaml里的loopClosureEnableFlag默认是true。在小场景实机测试时如果回环检测误匹配导致轨迹跳变可以先关掉回环检测观察前端里程计的原始精度。地图分辨率默认的0.5米对室内建图有点粗糙可以调到0.2-0.3米地图细腻很多但CPU占用会增加。在Jetson这类嵌入式平台上还是保持0.5比较稳妥。6. 常见问题与排查实录LVI-SAM编译和运行过程中的坑很多是共性问题。在这里把我遇到过和朋友们遇到过的问题汇总一下6.1 编译阶段报错找不到gtsam/gtsam.h或metis.h。GTSAM安装路径不在系统默认搜索路径修改CMakeLists.txt手动添加include路径。报错libmetis.so: cannot open shared object file。GTSAM依赖的metis库没有安装到系统库路径。解决办法sudo apt install libmetis-dev sudo ln -s /usr/lib/x86_64-linux-gnu/libmetis.so /usr/local/lib/libmetis.so报错OpenCV的CV_LOAD_IMAGE_GRAYSCALE未定义。OpenCV 4.0之后CV_LOAD_IMAGE_GRAYSCALE改名为cv::IMREAD_GRAYSCALE。LVI-SAM代码中用的旧宏在新版OpenCV下会报错。解决办法是把cv::imread(..., CV_LOAD_IMAGE_GRAYSCALE)改成cv::imread(..., cv::IMREAD_GRAYSCALE)文件里一般只有一两处全局搜索替换即可。6.2 运行阶段现象系统启动后一直卡在初始化Rviz没有点云。大概率是IMU数据有问题。先看rostopic echo /imu/data确认数据有内容、时间戳递增、加速度计数值量级正确。再确认雷达和相机话题也都正常。如果三个话题都正常检查params.yaml中的话题名是否与实测话题名完全一致。现象点云地图严重重影或轨迹跳变。先检查外参标定是否准确尤其是旋转外参。一个快速验证外参的方法让小车低速直线行驶一段距离观察建图结果中墙体是否笔直。如果墙体扭曲说明外参与真实值偏差过大需要重新标定。现象回环检测导致地图突然跳动。场景太小或者特征重复度高回环检测产生误匹配。处理办法是先关闭回环检测看前端里程计本身的漂移幅度。如果前端漂移不大说明回环检测模块的参数需要调整比如提高回环候选的分数阈值。6.3 IMU适配相关的坑踩到的坑IMU驱动里把加速度计数据当作m/s2发布但实际发的是g值。表现是系统初始化正常但建图时地面总是倾斜的。排查方法静止时用rostopic echo看linear_acceleration的z轴如果是1.0左右说明发的是g值应该约为9.8。踩到的坑6轴IMU的yaw漂移导致建图轨迹缓慢旋转。这不是代码bug而是6轴IMU的物理特性。短时间运行可用长时间运行需要考虑引入额外的偏航观测比如用视觉的绝对方向估计来校正IMU偏航。投产之前把IMU固定在平台上静止放几分钟用Rviz观察系统的静止精度。如果静止时轨迹仍然缓慢漂移说明IMU零偏没有完全估计出来可以检查IMU数据是否有异常噪点或者增大IMU噪声参数来让滤波器对IMU信息降权。写在最后的一点个人体会LVI-SAM这套系统真正跑通之后回头看会发现最耗时间的反而不是算法理解而是环境配置、依赖编译、数据格式这些工程问题。装环境装到崩溃时确实会怀疑人生但正是这些折腾让我对ROS的消息机制、坐标系变换、传感器标定有了更系统的认识。6轴IMU适配这件事核心也就一句话把IMU数据发布正确把内外参标定准确系统会自己照顾好剩下的事情。建议后面入坑的朋友们先跑通数据集再上实机实机先录bag离线调参最后再实时跑。这个顺序能省掉至少一半的无效调试时间。 LVI-SAM在Ubuntu20.04上的6轴IMU适配与实机部署教程
搞了快两周把LVI-SAM在Ubuntu20.04上从源码编译到实机跑通中间还折腾了6轴IMU的适配。这玩意儿网上教程不少但大多只讲到“能跑数据集”就停了真到自己上手接硬件全是坑。这篇文章把我整个复现过程和实机部署流程捋一遍重点说说6轴IMU接入时改了什么、为什么这么改给后面要搞LVI-SAM的人省点时间。LVI-SAM是Tixiao Shan在LIO-SAM基础上扩展出来的紧耦合SLAM方案融合了激光雷达、相机和IMU三类传感器。它解决的问题很明确单靠激光雷达在退化场景长走廊、空旷场地容易飘视觉在光照变化和快速运动时容易丢IMU短时间精度高但长期会漂三者融合正好互补。官方代码基于ROS1Ubuntu20.04对应Noetic版本整个系统拆成视觉里程计、激光惯性里程计、回环检测与地图优化三个模块。对于正在系统学ROS、准备入门激光视觉融合SLAM的人来说LVI-SAM是一个绕不开的经典开源项目。1. 整体方案与核心设计思路1.1 LVI-SAM到底在做什么先理解这系统的整体结构。LVI-SAM本质上是两个紧耦合子系统并行工作一个视觉惯性系统VIS一个激光惯性系统LIS。两个子系统通过因子图共享状态估计激光惯性系统的结果给视觉系统提供初始值和回环候选视觉系统的结果反过来给激光系统提供姿态先验。这种双向耦合比简单的传感器数据叠加要稳得多。代码上对应三个核心节点visualOdometry处理相机图像提取特征点与IMU预积分结果做视觉-惯性里程计输出6自由度位姿。imuPreintegration接收IMU原始数据做预积分维护因子图为其他模块提供高频位姿先验。mapOptimization接收激光雷达点云做特征提取角点、平面点scan-to-map匹配同时处理回环检测和图优化输出最终建图结果。这三个节点之间的关系用一条数据流来描述就是IMU数据进imuPreintegration得到当前位姿估计这个估计同时喂给visualOdometry做视觉匹配初始值、喂给mapOptimization做激光匹配初始值。两个子系统各自产生的结果再回到因子图里做全局优化。1.2 从LIO-SAM到LVI-SAM视觉带来了什么如果你看过LIO-SAM的源码再看LVI-SAM会觉得很亲切因为很多代码结构几乎一样。LVI-SAM最大的改动是在原有的雷达惯性系统上叠加了视觉里程计作为额外的观测来源并在因子图中增加了视觉因子。为什么要引入视觉雷达在结构化环境中表现很好但在长走廊、隧道这类几何特征单一的场景下激光特征退化匹配就容易飘。相机能提供丰富的纹理信息在这些场景下反而能帮上大忙。反过来相机对光照敏感快速运动时图像模糊这时候雷达又比视觉可靠。两个传感器各有短板融合起来才能在不同场景下都有可接受的精度。另一个值得注意的设计是视觉里程计和激光里程计之间采用的是紧耦合而不是简单的松耦合松耦合。LVI-SAM不是先把两个系统的结果拼在一起而是在因子图层面做联合优化这样能更好地处理传感器噪声和相关性问题。对实际部署来说紧耦合的好处在于即使某一个传感器短暂失效整个系统也不会立刻崩掉。1.3 这套方案有什么取舍LVI-SAM的取舍还是挺明显的。它用三传感器融合精度和鲁棒性上来了但系统复杂度和算力要求也上来了。作者的测试环境用的是一台高性能笔记本加独立显卡实机部署在NVIDIA Jetson AGX Xavier这类平台上跑起来还比较流畅但你要是想在树莓派或者低端ARM板上跑帧率会非常难看。另外LVI-SAM对传感器标定和同步的要求比较高。三个传感器之间的外参、时间偏移如果不对整个融合效果会直线下降。这也是为什么很多人在数据集上跑得很好一上实机就开始各种飘的原因。实机部署的难点根本不在算法本身而在工程问题。2. 环境搭建与依赖准备2.1 Ubuntu20.04和ROS Noetic是刚需LVI-SAM官方没有明确说支持哪个ROS版本但代码里大量使用了ROS1的API跑在Noetic上没有任何问题。Ubuntu20.04配ROS Noetic是当前ROS1生态最主流的组合软件包兼容性最好。装系统没啥好说的需要注意的是如果你用双系统建议单独给Ubuntu分一个至少100GB的盘因为光是依赖库、源码编译产物和数据集就能轻松吃掉几十GB。装完系统后先别急着装ROS先把软件源换成国内镜像源这个能省下后续大量下载时间。ROS Noetic的安装推荐直接用鱼香ROS的一键安装脚本。这东西虽然名字听着有点草台班子但实际用过之后会发现确实省心脚本会自动帮你配置软件源、安装ros-noetic-desktop-full、初始化rosdep整个过程基本不用手动干预。命令很简单wget http://fishros.com/install -O fishros . fishros按照提示选择ROS1 Noetic安装项就行。装完之后确认一下环境变量有没有写进~/.bashrcsource /opt/ros/noetic/setup.bash echo source /opt/ros/noetic/setup.bash ~/.bashrc验证一下能否正常使用roscore能启动就说明ROS装好了。2.2 核心依赖逐个装Ceres、GTSAM、OpenCV、PCLLVI-SAM编译之前有几个核心依赖需要提前搞定任何一个出问题都可能导致编译失败。第一个是Ceres Solver版本建议用1.14.0。LVI-SAM在mapOptimization节点中用到了Ceres做scan-to-map匹配的优化求解。这个库直接apt装的话版本会比较老而且经常和后续编译的LVI-SAM出现ABI兼容问题所以推荐源码编译sudo apt-get install -y cmake libgoogle-glog-dev libgflags-dev libatlas-base-dev libeigen3-dev libsuitesparse-dev git clone https://github.com/ceres-solver/ceres-solver.git cd ceres-solver git checkout 1.14.0 mkdir build cd build cmake .. make -j$(nproc) sudo make install第二个是GTSAM这是因子图优化的核心依赖LVI-SAM的imuPreintegration节点全靠它做增量平滑。GTSAM没有对应的Ubuntu apt包需要源码编译。作者推荐使用4.0.2版本实测4.1.1也能编过但建议还是跟着官方文档走4.0.2git clone https://github.com/borglab/gtsam.git cd gtsam git checkout 4.0.2 mkdir build cd build cmake -DGTSAM_BUILD_TESTSOFF -DGTSAM_BUILD_UNSTABLEON .. make -j$(nproc) sudo make install注意CMake参数里这个-DGTSAM_BUILD_UNSTABLEON一定要开否则LVI-SAM里引用的部分头文件会缺失。第三个是OpenCV和PCL。这两个不用特殊处理Ubuntu20.04自带的OpenCV 4.2.0和PCL 1.10就够用不需要额外折腾。LVI-SAM代码本身对OpenCV的调用并不深入主要就是读图像、特征提取、描述子匹配这些基础操作。Eigen也不用单独装编译Ceres和GTSAM的时候会把它带上来。2.3 创建catkin工作空间并编译LVI-SAM依赖装齐了接下来创建catkin工作空间。以我实际使用的目录结构为例mkdir -p ~/lvi_sam_ws/src cd ~/lvi_sam_ws/src git clone https://github.com/TixiaoShan/LVI-SAM.git cd .. catkin_make如果没有意外这个编译过程会跑很久。第一次编译时GTSAM的头文件和库文件可能会找不齐常见报错是找不到gtsam/gtsam.h或者metis.h。这是因为GTSAM安装后头文件路径没有进到系统默认搜索路径。解决办法是修改LVI-SAM的CMakeLists.txt在include_directories里手动加上GTSAM头文件路径include_directories( include /usr/local/include/gtsam /usr/local/include/gtsam/3rdparty/metis )编译完成后如果devel/lib目录下生成了lvi_sam对应的三个可执行文件说明编译通过。3. 数据集复现跑通官方bag验证系统3.1 下载测试数据与启动launch文件源码编译通过只是第一步接下来要在数据集上验证整个系统能正常工作。LVI-SAM作者提供了测试用的rosbag文件里面包含了相机图像、激光点云和IMU数据。我用的是官方推荐的handheld bag传感器数据比较全适合验证系统闭环效果。启动前需要修改LVI-SAM的配置文件路径在LVI-SAM/config/params.yaml。里面几个关键参数需要确认sensor: # 传感器话题名 lidar: /velodyne_points imu: /imu/data camera: /camera/image camera: # 相机内参 fx: 467.6719 fy: 465.5709 cx: 344.7813 cy: 228.5359 distortion: [0.0815, -0.1327, -0.0002, 0.0001, 0.0]不同版本的bag话题名可能不一样先跑rosbag info看一下数据包里面的话题名再对照修改。启动方式source ~/lvi_sam_ws/devel/setup.bash roslaunch lvi_sam run.launch另开一个终端播放bagrosbag play your_bag.bag正常情况下几秒钟之后Rviz里会开始出现点云地图和轨迹线。初始化需要一点时间系统会对IMU做静止初始化。3.2 跑数据集时关注什么数据集跑通了别急着庆祝先观察几个关键点来判断系统状态是否健康看Rviz里的按时间上色的点云地图。地图应该随着传感器移动而不断扩展轮廓清晰没有明显拖影。如果地图出现重影说明点云配准有问题最常见的原因是IMU噪声参数不对或外参标定错误。看轨迹输出。轨迹应平滑连续没有跳变。如果出现跳到远处又跳回来的现象大概率是回环检测误匹配导致图优化把轨迹拉歪了。看CPU占用。在普通笔记本上用CPU跑如果点云帧率不高CPU占用在300%-500%之间是正常的。如果长期800%以上后面实机部署就得考虑降低帧率或者用GPU推理了。官方bag跑完整个系统的基本链路就算验证通过了。从零开始到这一步大概需要一天时间大部分时间都耗在编译和依赖问题上。4. 6轴IMU适配原理与实操细节4.1 为什么6轴IMU要单独适配这是全文最核心的部分。LVI-SAM原始代码默认使用9轴IMU也就是包含加速度计、陀螺仪、磁力计的IMU模组。9轴IMU的磁力计可以提供绝对航向参考帮助系统在初始化阶段把世界坐标系的航向对齐到地磁方向同时也能抑制偏航角随时间漂移。但实际市面上的很多IMU模组尤其是那些体积小、功耗低的模块都是6轴的只有加速度计和陀螺仪没有磁力计。用6轴IMU接入LVI-SAM如果直接照搬默认配置会出现几个典型问题第一初始航向角不可观。六轴IMU静止时加速度计只能感知重力向量告诉你哪个方向是“下”陀螺仪只能感知角速度变化告诉你转了多少但无法告诉你面朝哪个方向。整个系统的初始偏航角就失去了参考基准只能依赖视觉或激光的第一次观测来初始化。第二偏航角累计漂移。没有磁力计校正光靠陀螺仪积分偏航角必然会产生缓慢漂移。短时间运行问题不大但长时间建图会看到轨迹逐渐扭曲。第三代码中有一些隐含假设。LVI-SAM中IMU消息里的orientation字段在部分代码路径下会直接作为先验使用。如果IMU驱动输出的是一个没有绝对航向参考的orientation这些先验就会带偏系统。那怎么解决思路是在驱动层面正确处理6轴IMU的数据发布在算法层面调整LVI-SAM的初始化逻辑让系统不完全依赖磁力计提供航向。4.2 IMU数据发布格式至关重要的sensor_msgs/Imu先说IMU数据怎么发。ROS中IMU数据的标准消息类型是sensor_msgs/Imu核心字段有orientation四元数表示的姿态如果IMU融合算法能给出姿态就用它给不了就填单位四元数并把orientation_covariance[0]设为-1告诉下游“这个字段不可用”。angular_velocity三轴角速度单位rad/s来自陀螺仪。linear_acceleration三轴线性加速度单位m/s2来自加速度计。很多自制IMU驱动的坑就出在orientation字段上。你需要想清楚你的6轴IMU能不能输出可靠的姿态如果你的IMU模块内部有DMP数字运动处理器比如MPU6050的DMP固件它能融合加速度计和陀螺仪数据输出稳定的roll和pitch但yaw是积分出来的没有绝对参考。这种情况下建议把DMP输出的四元数填进orientation字段但要注意这个yaw会随时间漂移算法端不要把yaw当作先验。如果你的IMU模块只是裸的加速度计和陀螺仪没有融合算法那更简单orientation直接填单位四元数把orientation_covariance[0]设为-1让下游自己处理姿态估计。LVI-SAM的预积分模块本来就要自己维护姿态不会依赖这个消息里的orientation。另外两个参数的设置也要注意。linear_acceleration发布时必须除以重力加速度g。ROS的Imu消息规范里linear_acceleration的单位是m/s2但很多IMU驱动会直接输出原始加速度计值单位是g比如静止时输出[0, 0, 1]这个在ROS里其实是错的应该输出[0, 0, 9.80665]。LVI-SAM内部对IMU数据的处理有单位假设搞错了重力方向就完全不对了。angular_velocity的单位是rad/s不是deg/s这个坑也踩到过。4.3 标定IMU内参imu_utils Allan方差6轴IMU要跑出好效果光把数据发对还不够噪声参数必须标定。LVI-SAM的config/params.yaml中关于IMU有这几个参数imu: # IMU噪声参数单位连续时间 noise: [0.005, 0.005, 0.005, 0.05, 0.05, 0.05] bias: [0.001, 0.001, 0.001, 0.01, 0.01, 0.01]前面的noise对应加速度计和陀螺仪的噪声密度noise density后面的bias对应随机游走bias random walk。这两个参数如果不标定直接照搬教程值很多时候也能跑但精度会差一截。尤其是在实机低速运动时IMU噪声参数对系统初始化速度的影响非常明显。IMU内参标定的标准做法是用Allan方差分析工作在ROS环境下的开源工具是imu_utils配合code_utils。标定的大致流程是把IMU固定在一个稳定的平台上静止放置2小时以上录制一段长时间静止数据。用imu_utils对录制的数据做Allan方差分析得到加速度计和陀螺仪各轴的噪声密度和随机游走。把得到的数值填进params.yaml。这套工具编译起来也有点麻烦因为code_utils要先编译然后imu_utils依赖它。建议直接跟着官方仓库的README走。如果不想搞这么麻烦一个应急的替代方案是用9轴IMU模组比如MPU9250的数据手册里的典型值但效果只能算能用不算最优。4.4 外参标定IMU和相机/雷达之间的位姿如果说内参标定决定系统精度上限外参标定就决定系统能不能正常收敛。LVI-SAM的params.yaml里有三个外参矩阵extrinsic_rot: [1, 0, 0, 0, 1, 0, 0, 0, 1] extrinsic_trans: [0.0, 0.0, 0.0]这个外参描述的是IMU坐标系相对于雷达坐标系的变换也就是雷达和IMU的相对位姿。注意这和你日常理解的“相机到雷达外参”不同LVI-SAM用的是IMU作为基准所以外参表达的是雷达在IMU坐标系下的位姿。如果你用官方数据集跑外参不用动。但实机部署时这个外参必须标定。传感器外参标定的工具选择看情况IMU到相机推荐用Kalibr这是苏黎世理工开源的相机IMU标定工具可以同时标定相机内参、相机到IMU外参和时延。虽然Kalibr支持的ROS版本比较老在Noetic上需要打补丁编译但效果确实是目前开源方案里最好的。IMU到雷达方案不统一常见的有lidar_imu_calib、direct_visual_lidar_calibration等。我实测下来效果比较稳定的是lidar_imu_calib输入是静止环境下雷达点云和IMU数据通过对比雷达拟合平面和IMU重力方向来标定外参中的旋转部分。外参标定的一个重要原则是不要用手量尺子去量传感器之间的物理距离。物理测量误差大而且传感器的参考坐标系通常在外壳内部你根本量不到准确值。用标定工具依靠数据自动求解比手工测量靠谱得多。4.5 代码层面针对6轴IMU的改动建议内参、外参、话题格式都处理好了还有最后一个收尾工作检查LVI-SAM代码里有没有对9轴IMU的隐含假设。我编译的源码版本里imuPreintegration.cpp中IMU预积分初始化部分的逻辑是用前几帧的加速度均值来估计重力方向然后用重力方向来对齐世界坐标系。这个逻辑使用6轴IMU时天然可行因为加速度计不需要磁力计就能感知重力。但要留意的是如果系统启动时IMU不是静止的初始化阶段对重力方向的估计就会出错导致后续整个地图都是歪的。这严格来说不是6轴IMU的问题但6轴IMU因为没有绝对航向参考对初始化姿态错误更敏感。另一处值得审查的地方是visualOdometry.cpp中视觉-惯性联合初始化的代码。部分版本的代码在视觉和IMU联合初始化时会假设视觉给出的相对旋转和IMU积分出的相对旋转之间有一个近似恒定的偏置这个偏置在6轴IMU上就是初始yaw不可观带来的。如果视觉和IMU外参标定不够准或者视觉特征跟踪质量不好初始化阶段就可能计算出一组很差的外参初值后面怎么优化都救不回来。我实际采用的最省事方法是在LVI-SAM源码中不要修改核心算法逻辑而是先把IMU驱动做好确保发布的IMU数据干净、坐标系正确、时间戳准确。绝大多数人在实机上的问题根本不是代码需要改而是IMU数据本身就不对。4.6 6轴IMU适配的检查清单把上面说的内容整理成一个自检清单实机部署前逐项过一遍检查项正确状态错误表现linear_acceleration单位m/s2静止时z轴约9.8静止时z轴约1说明发的是g值angular_velocity单位rad/s数值过大说明发的是deg/sorientation字段不可用时covariance[0]-1填了错误姿态导致初始化发散时间戳持续单调递增与雷达/相机在同一时钟域时间戳跳变或为0静止初始化系统启动时IMU保持静止3-5秒启动时晃动导致重力方向估计错误外参标定工具计算非手工测量地图出现系统性倾斜或重影5. 实机部署流程从桌面到小车的最后一公里5.1 实机传感器配置与硬件选型数据集跑通只是热身实机上跑通才是最终目标。以我手头的测试平台为例传感器配置如下激光雷达速腾聚创RS-LiDAR-16线16线机械式雷达10Hz频率点云话题/rslidar_points。相机Intel RealSense D435i虽然D435i自带IMU但我实际用的是外置的独立IMU模组因为RealSense自带的IMU噪声偏大稳定性也一般。IMU6轴的BMI088模组通过串口转USB接入200Hz输出话题/imu/data。计算平台Intel NUC11i7-1165G7 16GB内存跑LVI-SAM勉强够用。这套配置不算高端但能说明的是LVI-SAM对传感器的要求其实是“中规中矩”雷达16线以上、相机30帧以上、IMU 100Hz以上都能跑出不错的效果。传感器固定和安装是实机部署最容易被低估的环节。三个传感器之间的坐标变换关系要尽可能保持刚性固定要足够牢靠任何微小的松动都会导致外参失效。我见过一个案例IMU只是用双面胶粘在支架上结果在振动环境中外参漂移建图精度大幅下降。5.2 雷达到相机、雷达到IMU的时间同步问题实机部署中时间同步比外参标定更容易被忽略但影响却是灾难性的。如果你传感器的驱动各自为政一个用系统时间戳一个用传感器内部时间戳LVI-SAM收到的“同时刻”数据实际上差了100毫秒以上融合效果会非常差。目前比较常用的软件同步方案是在驱动层面让所有传感器的时间戳都使用主机系统时钟。对USB接口的传感器相机、IMU驱动收到数据时打上系统时间戳对网络接口的传感器雷达收到网络包时打上系统时间戳。如果传感器数量更多、精度要求更高可以考虑硬件同步用触发线把相机曝光时刻和雷达扫描时刻对齐。但对绝大多数人来说软件同步已经够了。一个实测经验如果雷达是10Hz、相机是30Hz、IMU是200Hz只要时间戳都是系统时钟LVI-SAM内部会自己处理不同频率之间的对齐和插值不需要你做额外的频率匹配。5.3 修改params.yaml适配实机实机跑之前需要把params.yaml中的话题名改成你自己的话题名sensor: lidar: /rslidar_points # 你雷达驱动发布的话题 imu: /imu/data # 你IMU驱动发布的话题 camera: /camera/color/image_raw # 你相机驱动发布的话题同时把前面标定得到的相机内参、IMU噪声参数、外参矩阵全部填进去。这部分工作没有什么捷径只能一项项改、一项项试。5.4 实机启动与调试流程实机启动建议按以下顺序来第一步启动雷达驱动确认点云话题有数据、时间戳正常。第二步启动相机驱动确认图像话题有数据、画面清晰不模糊。第三步启动IMU驱动用rostopic echo查看IMU消息内容静止时检查加速度计是否约等于重力加速度转动时检查陀螺仪是否有响应。第四步把所有传感器数据录制到rosbag里用rosbag record先录一组数据离线回放调试。这一步非常关键能让你在室内安全地调参不用一遍遍推着车在走廊里跑。第五步离线跑通后再上线实时跑。我实际测试时最常遇到的问题是传感器之间的时间戳存在固定的偏移。表现是离线跑bag效果还行但一上线就跑飞或者地图扭曲。排查方法是用rosbag play --clock回放bag然后查看LVI-SAM的Rviz输出。如果离线效果和在线效果差异很大大概率是时间同步问题。用rostopic hz分别查看三个话题的频率再对比话题的时间戳分布基本能定位问题出在哪个传感器上。5.5 实机调试中的参数调整经验实机跑通后哪些参数值得微调IMU噪声参数标定出来的值先填进去如果初始化慢或者初始化失败可以把噪声密度调大一些让系统更快收敛。回环检测开关params.yaml里的loopClosureEnableFlag默认是true。在小场景实机测试时如果回环检测误匹配导致轨迹跳变可以先关掉回环检测观察前端里程计的原始精度。地图分辨率默认的0.5米对室内建图有点粗糙可以调到0.2-0.3米地图细腻很多但CPU占用会增加。在Jetson这类嵌入式平台上还是保持0.5比较稳妥。6. 常见问题与排查实录LVI-SAM编译和运行过程中的坑很多是共性问题。在这里把我遇到过和朋友们遇到过的问题汇总一下6.1 编译阶段报错找不到gtsam/gtsam.h或metis.h。GTSAM安装路径不在系统默认搜索路径修改CMakeLists.txt手动添加include路径。报错libmetis.so: cannot open shared object file。GTSAM依赖的metis库没有安装到系统库路径。解决办法sudo apt install libmetis-dev sudo ln -s /usr/lib/x86_64-linux-gnu/libmetis.so /usr/local/lib/libmetis.so报错OpenCV的CV_LOAD_IMAGE_GRAYSCALE未定义。OpenCV 4.0之后CV_LOAD_IMAGE_GRAYSCALE改名为cv::IMREAD_GRAYSCALE。LVI-SAM代码中用的旧宏在新版OpenCV下会报错。解决办法是把cv::imread(..., CV_LOAD_IMAGE_GRAYSCALE)改成cv::imread(..., cv::IMREAD_GRAYSCALE)文件里一般只有一两处全局搜索替换即可。6.2 运行阶段现象系统启动后一直卡在初始化Rviz没有点云。大概率是IMU数据有问题。先看rostopic echo /imu/data确认数据有内容、时间戳递增、加速度计数值量级正确。再确认雷达和相机话题也都正常。如果三个话题都正常检查params.yaml中的话题名是否与实测话题名完全一致。现象点云地图严重重影或轨迹跳变。先检查外参标定是否准确尤其是旋转外参。一个快速验证外参的方法让小车低速直线行驶一段距离观察建图结果中墙体是否笔直。如果墙体扭曲说明外参与真实值偏差过大需要重新标定。现象回环检测导致地图突然跳动。场景太小或者特征重复度高回环检测产生误匹配。处理办法是先关闭回环检测看前端里程计本身的漂移幅度。如果前端漂移不大说明回环检测模块的参数需要调整比如提高回环候选的分数阈值。6.3 IMU适配相关的坑踩到的坑IMU驱动里把加速度计数据当作m/s2发布但实际发的是g值。表现是系统初始化正常但建图时地面总是倾斜的。排查方法静止时用rostopic echo看linear_acceleration的z轴如果是1.0左右说明发的是g值应该约为9.8。踩到的坑6轴IMU的yaw漂移导致建图轨迹缓慢旋转。这不是代码bug而是6轴IMU的物理特性。短时间运行可用长时间运行需要考虑引入额外的偏航观测比如用视觉的绝对方向估计来校正IMU偏航。投产之前把IMU固定在平台上静止放几分钟用Rviz观察系统的静止精度。如果静止时轨迹仍然缓慢漂移说明IMU零偏没有完全估计出来可以检查IMU数据是否有异常噪点或者增大IMU噪声参数来让滤波器对IMU信息降权。写在最后的一点个人体会LVI-SAM这套系统真正跑通之后回头看会发现最耗时间的反而不是算法理解而是环境配置、依赖编译、数据格式这些工程问题。装环境装到崩溃时确实会怀疑人生但正是这些折腾让我对ROS的消息机制、坐标系变换、传感器标定有了更系统的认识。6轴IMU适配这件事核心也就一句话把IMU数据发布正确把内外参标定准确系统会自己照顾好剩下的事情。建议后面入坑的朋友们先跑通数据集再上实机实机先录bag离线调参最后再实时跑。这个顺序能省掉至少一半的无效调试时间。