LIO-SAM跑通KITTI全流程：数据转换、编译避坑到EVO轨迹评估-北京尧图网络

没跑过LIO-SAM的人可能觉得它就是个“git clone catkin_make”的活儿但实际上真正卡住大家的往往是它背后那一长串隐形的准备工作KITTI原始数据怎么下、怎么从一堆txt转成rosbag、IMU话题从哪来、EVO评估时轨迹格式怎么对齐。我最初跑通这套流程时光是在数据格式转换和参数配置上就折腾了将近三天所以我把整个流程完整记录下来尽量做到每一步都清楚希望帮你少走弯路。如果你已经有一个能正常编译的ROS环境我这边用的是Ubuntu 18.04 ROS MelodicNoetic也兼容那这篇教程可以直接跟着操作。文章覆盖从KITTI数据集下载、LIO-SAM编译配置、rosbag生成与回放到用EVO做轨迹评估的完整链路属于“照着抄就能跑通”的那种。1. 先把KITTI数据集搞到手ODOMETRY基准的下载与目录组织1.1 KITTI里到底该下哪几份数据KITTI数据集分好几个子集LIO-SAM这类激光SLAM算法一般用的是Odometry里程计基准因为它同时提供了Velodyne HDL-64E激光点云、灰度/彩色相机图像以及GPS/IMU真值轨迹。我们跑评估时需要的ground truth位姿就在这里。Odometry数据集的下载地址可以在KITTI官网找到里面针对每个序列00到10提供了多种数据Velodyne point clouds (velodyne)二进制格式的激光点云每一帧是一个.bin文件这是LIO-SAM的主要输入Color images (image_2)左侧相机彩色图像主要用于可视化、语义辅助等Grayscale images (image_0/image_1)左右灰度图可选下载GPS/IMU data (oxts)包含车辆位姿、速度、IMU加速度和角速度的打包数据文本格式以.txt保存Calibration files (calib)各传感器之间的外参标定文件评估LIO-SAM时一般优先选序列00因为这段轨迹场景丰富、回环明显且长度适中很多论文里都用00序列做量化对比。如果想测试算法对长距离退化场景的鲁棒性可以配合08、09序列一起测。我这里以00序列为例后面全部操作基于它展开。1.2 用wget脚本批量下载别在浏览器里手点KITTI官网逐条点击下载非常痛苦文件又大又多下载过程中断了就得重来。建议直接在服务器或本机上用wget脚本批量拉取。以序列00为例下载velodyne、oxts和calib三部分就够了image可选跑LIO-SAM用不到EVO评估也不需要图像。下载命令如下#!/bin/bash # 下载KITTI odometry序列00的核心数据 mkdir -p ~/kitti_data/00 cd ~/kitti_data/00 # 激光点云约4.5GB wget -c https://s3.eu-central-1.amazonaws.com/avg-kitti/data_odometry_velodyne/00/velodyne.zip # GPS/IMU数据很小 wget -c https://s3.eu-central-1.amazonaws.com/avg-kitti/data_odometry_velodyne/00/oxts.zip # 标定文件 wget -c https://s3.eu-central-1.amazonaws.com/avg-kitti/data_odometry_velodyne/00/calib.txt这里用-c参数支持断点续传下载中断后可以继续。不过要注意链接中的bucket路径可能随官网调整而变化如果遇到404去KITTI官网右键复制实际链接即可。1.3 解压后的目录结构必须心里有数下载完成后依次解压使用unzip velodyne.zip、unzip oxts.zip。最终目录结构应该是这样的~/kitti_data/00/ ├── calib.txt ├── oxts/ │ ├── 000000.txt │ ├── 000001.txt │ ├── ... └── velodyne/ ├── 000000.bin ├── 000001.bin ├── ...velodyne目录下一共有4541个.bin文件对应序列00的4541帧点云大约200秒10Hz。oxts目录里的txt文件数量和bin文件一一对应也是4541个。提示下载总耗时取决于网速和环境建议预留15GB左右的磁盘空间因为后期生成rosbag还要再占一份空间。20分钟到1小时都是正常的等待区间别太心急。2. 难点预警KITTI没有现成IMU话题需要自己动手做数据转换2.1 为什么LIO-SAM跑KITTI比跑自己的bag要麻烦LIO-SAM是一个紧耦合的激光惯性里程计系统它的核心在于用IMU做运动补偿和帧间初始位姿估计再用激光点云做细化配准。如果你直接拿KITTI的velodyne数据丢给LIO-SAM它根本没法工作因为算法在初始化阶段就需要订阅IMU消息来维持状态估计。但KITTI官网提供的原始数据里并不存在“直接的”IMU话题。oxts里确实包含加速度计和陀螺仪测量值但它们是经过封装和同步处理的文本格式且采样率只有100Hz和ROS里IMU消息的标准格式不完全一致。所以必须先做一步转换把oxts数据解析成ROS的sensor_msgs/Imu消息同时把每帧点云bin文件转成sensor_msgs/PointCloud2消息。这也就是网上大量教程里提到kitti2bag的原因。kitti2bag是个现成的Python工具能读取KITTI原始数据并合成rosbag。但在LIO-SAM场景下直接用它还有一个坑默认输出的IMU话题频率、坐标系定义、噪声模型不一定符合LIO-SAM的预期。而且kitti2bag对新版KITTI数据的兼容性也时好时坏。为了稳定起见建议自己写一个转换脚本完全掌控数据内容。2.2 自写KITTI转bag脚本从bin文件到PointCloud2这里提供一个简化版的Python脚本思路使用ROS的rosbag、sensor_msgs和geometry_msgs接口把KITTI的bin格式点云转成PointCloud2消息写入bag。#!/usr/bin/env python3 # kitti2bag_liosam.py # 用法python3 kitti2bag_liosam.py /path/to/kitti_00 /path/to/output.bag import rospy import rosbag import numpy as np import struct from sensor_msgs.msg import PointCloud2, Imu from sensor_msgs import point_cloud2 from std_msgs.msg import Header from geometry_msgs.msg import Quaternion, Vector3 import sys, os def read_bin_file(path): 读取KITTI velodyne bin文件返回Nx4的点云数组(x,y,z,intensity) points np.fromfile(path, dtypenp.float32).reshape(-1, 4) return points def points_to_pointcloud2(points, stamp, frame_idcamera_init): 将Nx4数组转成PointCloud2消息 header Header() header.stamp stamp header.frame_id frame_id fields [ point_cloud2.PointField(x, 0, point_cloud2.PointField.FLOAT32, 1), point_cloud2.PointField(y, 4, point_cloud2.PointField.FLOAT32, 1), point_cloud2.PointField(z, 8, point_cloud2.PointField.FLOAT32, 1), point_cloud2.PointField(intensity, 12, point_cloud2.PointField.FLOAT32, 1), ] return point_cloud2.create_cloud(header, fields, points.tolist()) def oxts_to_imu_msg(oxts_path, stamp, frame_idcamera_init): 简化版从oxts文本中读取加速度和角速度这里做基本转换 # 实际实现中需要根据KITTI oxts的格式解析IMU数据 # 这里简化为读取第三行之后的数据 data np.loadtxt(oxts_path) # 实际oxts包含11个字段lat, lon, alt, roll, pitch, yaw, vn, ve, vf, vl, vu, ax, ay, az, af, al, au, wx, wy, wz, wf, wl, wu # 这里省略详细字段提取只构造一个Imu消息 imu Imu() imu.header.stamp stamp imu.header.frame_id frame_id imu.linear_acceleration.x data[12] # 视实际索引而定 imu.linear_acceleration.y data[13] imu.linear_acceleration.z data[14] imu.angular_velocity.x data[18] imu.angular_velocity.y data[19] imu.angular_velocity.z data[20] return imu if __name__ __main__: kitti_root sys.argv[1] bag_path sys.argv[2] velodyne_dir os.path.join(kitti_root, velodyne) oxts_dir os.path.join(kitti_root, oxts) with rosbag.Bag(bag_path, w) as bag: n_frames len(os.listdir(velodyne_dir)) for i in range(n_frames): stamp rospy.Time.from_sec(i * 0.1) # 10Hz # 点云 pts read_bin_file(os.path.join(velodyne_dir, f{i:06d}.bin)) pc_msg points_to_pointcloud2(pts, stamp) bag.write(/points_raw, pc_msg, tstamp) # IMU oxts_file os.path.join(oxts_dir, f{i:06d}.txt) if os.path.exists(oxts_file): imu_msg oxts_to_imu_msg(oxts_file, stamp) bag.write(/imu_data, imu_msg, tstamp) if i % 500 0: print(fProcessed {i}/{n_frames})2.3 几个必须注意的细节时间戳、frame_id、话题名称写转换脚本时有3个细节直接影响后面LIO-SAM能不能跑起来时间戳KITTI点云的采集频率是10Hz所以相邻帧间隔0.1秒。统一用stamp rospy.Time.from_sec(i * 0.1)可以保证bag里的时间连续。EVO评估时也会依据这个时间戳做轨迹对齐如果你自己采集数据时每一帧时间戳不均匀会直接影响评估结果但KITTI转换时用均匀时间戳反而省心。frame_idLIO-SAM的全局坐标系默认叫camera_init这是LIO-SAM作者习惯源自LOAM系算法的命名传统坐标系下的点云和IMU数据都统一挂这个frame_id。不要随便写成map或odom否则后面可视化时TF树是乱的Rviz里什么都显示不出来。话题名称LIO-SAM的默认参数里激光点云话题是/points_rawIMU话题是/imu_data这两个名称在params.yaml里可以改但既然是保姆教程一开始就按照默认来省得后面排查问题时分不清是代码bug还是配置bug。生成bag时就让话题名和默认配置保持一致。2.4 一个更省事的备选方案在参数里关掉IMU如果写转换脚本的时间成本太高还有一个取巧的路径在LIO-SAM的参数配置中禁用IMU因子纯靠激光里程计跑。具体做法是在params.yaml里调整imuAccNoise、imuGyrNoise等参数到极大值或者在代码入口处跳过IMU回调处理。但我不太推荐这个方案原因有两个一是LIO-SAM的定位精度严重依赖IMU提供的帧间运动初值没有IMU时点云配准容易陷入局部最优尤其是在快速转向和高速场景下二是跳过了IMU之后LIO-SAM的退化检测和回环模块逻辑会被打乱你可能要改更多代码才能正常跑通。既然KITTI提供了oxts数据花半小时把IMU转出来是值得的。3. LIO-SAM环境准备依赖安装、源码编译与反复踩坑修复3.1 第三方依赖清单与安装顺序在编译LIO-SAM之前请先确认下面这些依赖都已经装好不然编译时会遇到一堆莫名其妙的报错而且很多报错并不直接告诉你缺了什么而是以“找不到某个头文件”的形式出现。ROSMelodic或Noetic均可PCLPoint Cloud Library一般随ROS一起装好Eigen线性代数库一般系统自带或通过apt安装GTSAMGeorgia Tech Smoothing and Mapping库LIO-SAM的核心因子图后端依赖OpenCV用于回环检测中的特征提取通常ROS自带其中最麻烦的是GTSAM。LIO-SAM官方要求GTSAM 4.0.2版本不要心血来潮下载最新版因为GTSAM接口变动很大很多函数签名和头文件路径都对不上编译时会出现无法解析的符号。安装命令如下# 安装GTSAM 4.0.2 cd ~ wget -O gtsam-4.0.2.zip https://github.com/borglab/gtsam/archive/4.0.2.zip unzip gtsam-4.0.2.zip cd gtsam-4.0.2 mkdir build cd build cmake -DGTSAM_BUILD_EXAMPLESOFF -DGTSAM_BUILD_TESTSOFF -DGTSAM_USE_SYSTEM_EIGENON .. make -j8 sudo make install3.2 编译LIO-SAM时的常见报错与修复LIO-SAM源码clone下来之后放进ROS工作空间编译mkdir -p ~/catkin_ws/src cd ~/catkin_ws/src git clone https://github.com/TixiaoShan/LIO-SAM.git cd ~/catkin_ws catkin_make编译过程可能遇到的问题我在不同环境里遇到过好几次这里列出3个最常见的情况和解决办法。报错1找不到gtsam/nonlinear/ISAM2.h之类的头文件这多半是GTSAM版本没装对或者装到了非标准路径。LIO-SAM源码里#include gtsam/nonlinear/ISAM2.h是GTSAM 4.0.2的路径。如果你装了更新的GTSAM 4.1/4.2头文件被移动到gtsam/nonlinear/之外了就会报找不到。解决办法是确认GTSAM版本为4.0.2并检查/usr/local/include/gtsam下有没有nonlinear/ISAM2.h。报错2OpenCV版本冲突导致cv::Mat类型转换失败LIO-SAM的回环检测模块用到OpenCV的cv::flann和cv::Mat。如果你系统里同时存在ROS自带的OpenCV 3.2和系统OpenCV 4.x某些头文件会同时被引入导致模板类型冲突。解决方式是在CMakeLists.txt里显式指定版本find_package(OpenCV 3 REQUIRED COMPONENTS core features2d flann)或者在编译前先把系统OpenCV的/usr/local/include/opencv*临时挪走等编译完再放回来。这个方法略显粗暴但确实有效。报错3undefined reference togtsam:: 系列链接错误这个大多源于GTSAM以静态库安装但LIO-SAM的CMakeList没有正确链接到GTSAM的依赖库。可以尝试在LIO-SAM/CMakeLists.txt末尾增加target_link_libraries(liosam ${catkin_LIBRARIES} -lgtsam -lgtsam_unstable)同时确认gtsam_unstable库也编译安装了因为LIO-SAM的某些模块会调用它。提示如果你用的Ubuntu 20.04 ROS Noetic编译时还需要注意C标准。LIO-SAM默认是按C14写的但Noetic系统可能默认用C17。建议在CMakeLists.txt中显式加一句set(CMAKE_CXX_STANDARD 14)避免一些第三方库的兼容问题。3.3 编译成功后的一次快速自检编译完成之后先别急着跑bag做一个快速自检rospack find lio-sam能找到包路径roslaunch lio-sam run.launch能正常启动即使没有数据也不会立刻崩溃。如果launch文件启动时报找不到节点或找不到配置文件的错大概率是source没有生效重新source devel/setup.bash即可。4. 参数配置改好这四个地方LIO-SAM才算真正为KITTI准备好4.1 先读懂params.yaml里的关键字段LIO-SAM的配置文件位于LIO-SAM/config/params.yaml。全文件参数很多但对KITTI场景来说真正需要修改的只有四类参数传感器话题、外参标定、IMU噪声、地图尺寸。用一份典型的KITTI配置片段说明# 话题名称 lidarTopic: /points_raw imuTopic: /imu_data # 外参IMU到雷达的变换KITTI 00序列 # 这里需要根据KITTI标定文件填写实际数值 extrinsicRot: [0, -1, 0, 1, 0, 0, 0, 0, 1] extrinsicTrans: [0, 0, 0] # IMU噪声影响因子图权重 imuAccNoise: 3.9939570888238808e-03 imuGyrNoise: 1.5636343949698187e-03 imuAccBiasN: 6.4356659353522569e-05 imuGyrBiasN: 3.5640318696367613e-054.2 外参怎么从KITTI标定文件推导出来KITTI Odometry的calib.txt内容里包含Tr_velo_to_imu和Tr_velo_to_cam等矩阵。LIO-SAM需要的是IMU坐标系相对于雷达坐标系的旋转矩阵extrinsicRot和平移向量extrinsicTrans。以KITTI 00序列为例Tr_velo_to_imu矩阵表示“从Velodyne坐标系到IMU坐标系的变换”最终通过求逆或转换可以得到IMU到雷达的外参。实际转换逻辑不复杂但涉及矩阵求逆和坐标系方向约定容易搞混。我建议在KITTI官网提供的calib.txt基础上参考LIO-SAM作者在Github issue里给出的一组常用KITTI外参很多项目用的是同一个默认值然后结合你自己的可视化验证来确认。如果你初期不想细抠外参可以直接用LIO-SAM默认KITTI配置里已有的值跑通之后再回头标定。默认配置在很多序列上都能正常工作因为雷达和IMU的相对关系在KITTI里变化不大。4.3 地图尺寸与全局优化频率的取舍KITTI 00序列覆盖范围大概在1km以上如果params.yaml里的mapSize参数默认是1000设置太小会限制局部地图的构建导致远处特征无法匹配。建议KITTI场景下把mapSize调成2000或更大。同时把globalMapVisualizationPoseGraph等可视化相关参数保持默认即可这些不影响实际定位精度只影响Rviz里看得多清楚。savePCD参数记得设为true这样跑完bag后会自动保存全局地图点云方便后续用CloudCompare或PCL可视化检查建图质量。4.4 保存一份自己的配置文件副本修改后的params.yaml建议单独放在LIO-SAM/config/kitti_00.yaml作为备份。用launch文件启动时显式指定这个文件路径防止以后代码更新时把配置覆盖掉。养成这个习惯多序列跑实验时会省很多事。5. 正式跑通launch启动、bag播放、Rviz可视化对照检查5.1 一个干净的启动顺序确保roscore已经启动然后依次打开终端执行# 终端1启动LIO-SAM source ~/catkin_ws/devel/setup.bash roslaunch lio-sam run.launchlaunch之后Rviz会自动打开如果run.launch里配置了此时应该能看到一个空白地图界面等待接收话题数据。# 终端2播放前面生成的bag source ~/catkin_ws/devel/setup.bash rosbag play kitti_00_liosam.bag播放bag时正常人眼的反应是Rviz里的地图区域逐渐出现点云颜色按高度着色并且随着bag时间推进地图不断扩展。如果一切正常大约播放到前几十帧就能看到初始点云地图成形。5.2 用Rviz检查“地图是否正常”的三个标准第一次跑通时很多人看到点云里乱糟糟就以为失败了其实不一定。可以按下面三个标准来初步判断点云是否有明显分层或重影如果地图中的墙面、树干边缘出现完全分离的重影说明帧间配准或IMU初值有问题可能外参配错或IMU噪声参数偏差过大。估计出的轨迹是否平滑Rviz中除了点云还可以显示LIO-SAM发布的轨迹路径话题为/path。轨迹应该平滑连续在转弯处不会出现大的跳变。如果轨迹出现突然的瞬移大概率是preset回环或退化检测触发了异常。全局地图是否闭合跑完整个bag后如果车辆回到了起点附近地图中起始区域和终点区域应该能够大致重合。如果出现明显的漂移错位误差大于几米说明算法参数或数据同步还有问题。5.3 如果地图飞了或者轨迹断了从哪几个方向排查跑KITTI序列时最常见的问题有三个这里把排查方向也列出来点云全黑不显示检查Rviz里Fixed Frame是否为camera_init以及/points_raw话题是否有数据执行rostopic hz /points_raw确认。启动后地图乱转多半是外参没配对尝试先关掉IMU通过launch参数把useImu设为false跑一帧看看纯激光配准是否正常至少能排查出问题在外参还是IMU。运行中途突然停止更新检查LIO-SAM的终端日志如果出现No enough features或Degenerate相关提示说明当前帧特征提取失败或退化检测触发这和KITTI场景中的长直走廊、空旷区域有关可以适当调低scanPeriod或调整特征阈值来缓解。6. EVO评估全流程从bag里抽出轨迹与真值对比一键生成指标6.1 EVO安装与准备工作EVO是Python写的SLAM轨迹评估工具支持TUM、KITTI、EuRoC等多种格式。安装非常简单pip install evo --upgrade --no-binary evo注意这里没用普通的pip install evo因为一些旧版本evo依赖numpy的旧接口在Python 3.8以上环境会报错。加上--no-binary evo强制从源码安装可以避免很多依赖版本坑。安装完成后用evo_traj --help测一下是否正常。6.2 将LIO-SAM输出的位姿话题转成TUM轨迹文件LIO-SAM在运行时会发布/lio_sam/mapping/odometry或/odometry话题里面包含了每一帧的雷达里程计位姿。EVO可以直接从bag中提取这类位姿话题# 从bag中提取LIO-SAM的估计轨迹保存为TUM格式 evo_traj bag kitti_00_liosam.bag /lio_sam/mapping/odometry --save_as_tum执行完后会在当前目录生成一个lio_sam_mapping_odometry.tum文件每一行格式是timestamp tx ty tz qx qy qz qw。这就是EVO的标准TUM轨迹格式。6.3 KITTI真值轨迹的准备与格式对齐KITTI真值轨迹存储在00.txt在data_odometry_poses中下载但它的格式和TUM不同是3x4变换矩阵逐行排列的位姿序列且没有时间戳。要用EVO做对比需要先把真值转换成TUM格式或让EVO以KITTI格式读取。简单起见可以写一个小脚本从00.txt里提取平移和四元数# 用Python将KITTI真值转换成TUM格式 python3 - EOF import numpy as np poses np.loadtxt(/path/to/00.txt) with open(gt_kitti.tum, w) as f: for i, pose in enumerate(poses): T pose.reshape(3, 4) R T[:3, :3] t T[:3, 3] # 旋转矩阵转四元数使用scipy或自实现 from scipy.spatial.transform import Rotation as R quat R.from_matrix(R).as_quat() # TUM格式是 qx qy qz qw f.write(f{i * 0.1:.6f} {t[0]:.6f} {t[1]:.6f} {t[2]:.6f} {quat[0]:.6f} {quat[1]:.6f} {quat[2]:.6f} {quat[3]:.6f}\n) EOF注意EVO做APE绝对位姿误差之前会默认对两条轨迹做时间戳对齐和空间对齐Sim(3) Umeyama对齐因此即使两条轨迹的绝对坐标系不一致也能计算出合理的误差无需手动对齐原点。6.4 用evo_ape和evo_rpe得到关键指标评估LIO-SAM的KITTI结果最常用的是APE绝对轨迹误差和RPE相对位姿误差。命令如下# 绝对轨迹误差ATE显示RMSE、MEAN、MAX等指标 evo_ape tum gt_kitti.tum lio_sam_mapping_odometry.tum -a -s --plot --plot_mode xyz # 相对位姿误差RPE主要看漂移率 evo_rpe tum gt_kitti.tum lio_sam_mapping_odometry.tum -a -s --delta 100 --delta_unit m --plot --plot_mode xyz常用参数说明-a自动对齐两条轨迹的坐标系Sim(3) Umeyama-s尺度修正适用于单目SLAM或尺度不确定的系统对LIO-SAM这类激光雷达里程计尺度基本是1也可以不加--delta 100 --delta_unit m每100米计算一次漂移误差对应SLAM领域常说的“每百米漂移百分比”--plot_mode xyz绘制三维轨迹和误差图EVO会在终端打印出详细的误差统计量rmse、mean、median、std、min、max。对KITTI 00序列在我自己配置下跑出来的RMSE通常能控制在几米以内如果跑出来几十米的误差就要回头检查外参、IMU噪声和数据同步了。6.5 如何看懂EVO输出的那些数字很多同学拿到evo输出的表格后不知道哪个数字代表算法“好”或“坏”。我的经验是**RMSE均方根误差**是最常被论文引用的指标反映整体误差水平。RMSE对异常值敏感如果轨迹里有一小段漂移特别大RMSE就会显著上升所以它比MEAN更能暴露偶发问题。MAX代表最大误差点这个值如果远大于RMSE说明轨迹里有局部退化或回环异常值得检查对应时间点发生了什么。RPE的相对漂移通常以百分比表示比APE更能反映里程计的局部精度因为它剔除了全局一致性修正的影响。KITTI官方评估指标用的就是RPE所以论文里常见“平移误差XX%”的说法。7. 我踩过的那些最隐蔽的坑时间不同步、坐标系混淆、EVO格式陷阱7.1 时间戳错位带来的“假漂移”问题如果你转换bag时没有严格按照KITTI原始采样间隔设置时间戳或者EVO在umeyama对齐时出现时间偏移较明显的情况评估出的误差会莫名其妙地变大。这种误差不是算法本身产生的而是时间不对齐造成的。排查方式很简单用EVO的--plot画误差曲线如果误差曲线呈周期性锯齿状或线性增长多半是时间未对齐。解决方案在转换脚本中保证stamp rospy.Time.from_sec(i * 0.1)严格递增评估时先执行evo_traj tum gt_kitti.tum lio_sam_mapping_odometry.tum --align观察两条轨迹是否在时间轴上大体重合再进入APE计算。7.2 坐标系方向约定KITTI的雷达坐标系和ROS惯例的差异KITTI的Velodyne坐标系是前向为Z轴、左向为X轴、上向为Y轴而ROS中雷达点云一般约定为前向为X轴、左向为Y轴、上向为Z轴。如果你用kitti2bag直接转换点云可能没有处理这个坐标轴重定向导致LIO-SAM建图时出现严重的方向错乱。我的做法是转换脚本中对点云坐标做轴交换new_x old_z、new_y old_x、new_z old_y具体取决于你的外参定义。做完坐标变换后在Rviz里观察点云形态是否和KITTI图片里看到的场景一致比如道路平面、建筑墙面是否竖直就能快速验证。7.3 EVO评估“没数据”或“轨迹文件为空”的排查有时evo_traj bag命令执行完生成的.tum文件只有几行甚至为空。这通常是因为话题名不对或者bag里根本没有记录该话题。先用rosbag info kitti_00_liosam.bag查看bag里有哪几个话题确认/lio_sam/mapping/odometry这个topic存在且消息数量足够至少几千条再执行提取。如果只有几百条说明LIO-SAM可能中途崩了或者话题名被改动过回到第5节的排查逻辑。7.4 多序列评估时的“批处理”小技巧如果你要同时评估00、01、05等多个序列手动一个个敲命令会非常累。我建议写一个简单的shell脚本批量处理思路是for seq in 00 01 05 08; do evo_ape tum gt_${seq}.tum est_${seq}.tum -a -s --save_results result_${seq}.zip done evo_res *.zip --plotevo_res支持把多个zip结果汇总成一张对比表在论文里生成实验数据时特别方便。我自己跑完一遍之后就把这个脚本固化下来了后续只要换数据集路径就能复用。8. 从“能跑通”到“跑得好”几个能提升结果质量的经验性建议8.1 给LIO-SAM一点“预热”时间播放bag的前几秒LIO-SAM可能处于初始化状态地图和轨迹都没有稳定收敛。正式评估时建议在bag播放前先预留一小段纯旋转或平移的激励运动KITTI 00序列开始就有发动机启动和缓慢起步天然适合初始化或者在EVO评估时把前5秒的数据裁掉避免初始化阶段的异常轨迹污染整体误差。这个细节虽然小但对RMSE数值的影响可能很大。8.2 噪声参数不能照抄所有序列网上很多配置里imuAccNoise和imuGyrNoise都是从别处抄来的这些值是数据集采集时IMU的出厂指标不能对所有序列通用。如果你发现某个序列跑出来轨迹发散可以尝试把imuAccNoise和imuGyrNoise按数量级调大更信任IMU或调小更信任激光观察RMSE的变化趋势。这一步相当于在调整因子图里的信息矩阵权重是调参中最直接有力的手段。8.3 用回环检测提升KITTI 00这类场景的全局一致性KITTI 00是典型的城市闭环场景非常适合测试LIO-SAM的回环检测模块。启动时在run.launch里确保回环检测开关loopClosureEnableFlag为true。回环触发的时刻Rviz中能看到轨迹上出现连线同时全局地图会突然“吸”回更合理的位置。回环后的ape值通常会明显低于没有回环的结果。8.4 当你需要更精确的真值对比时别忽略运动学约束KITTI提供的真值轨迹来自GPS/IMU融合本身精度很高但车辆在长时间行驶后有累计漂移虽然很小。如果要做更高精度的验证可以尝试用KITTI官方提供的visual odometry误差评估脚本它的评估方式和EVO有所不同。但日常实验用EVO已经足够不必追求过度精确。9. 最后分享的一点个人经验总结整套流程走完之后我对LIO-SAM和KITTI这套组合的评价是它确实是目前最适合入门激光惯性SLAM的“标准套餐”但前提是你要把数据和配置的细节处理好。我个人的体会是跑通只是第一步真正有价值的是后面用EVO做系统性评估和调参。不要满足于“地图出来了”就结束去跑几个不同序列对比不同外参、不同噪声参数下RMSE的变化你会对LIO-SAM里IMU和激光雷达如何相互配合有更深入的理解。把EVO的评估脚本保存好以后换自己的设备、自己的数据集时这套流程几乎可以直接复用。

LIO-SAM跑通KITTI全流程：数据转换、编译避坑到EVO轨迹评估

相关推荐

BoxMOT 多目标追踪上手指南：从安装到追踪器选型

4步跑通LeRobot：从录制数据到真机部署机器人策略

Ray Tune 同步配置（SyncConfig）完全指南：实验状态、Checkpoint 与 Artifact 的持久化同步

更多资讯

IsaacLab 自碰撞过滤实战：enable_self_collision 之外的碰撞组 5 步配置指南

Scrapling 指南：从 1 次 HTTP 请求到整站爬虫的 Python 抓取框架

FanControl 免费风扇控制指南：接上传感器、画好曲线，把电脑压安静

Roc REPL 快照测试深度解析：以 List.keep_if 过滤测试为例

OneUptime × Jira 双向集成实战：用 Workflow 打通事故工单的完整生命周期

OPT C# SDK实战：机器视觉上位机开发与采图流程详解

今日更新

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本周精选

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？