KITTI基准评测：目标检测、深度估计与视觉里程计算法实战对比

最近团队里在争论自动驾驶感知方案选型，检测算法该用YOLO还是Faster R-CNN，深度估计用自监督还是监督式，里程计要不要上VINS……与其靠经验拍板，我直接把KITTI数据集拉出来，搭了一套公平的测试流程，把这三个方向的代表性算法挨个跑了一遍。这篇文章就是这次测试的完整复盘，包括怎么下载数据、怎么统一指标、跑出哪些数据、以及我在实操中踩过的坑。如果你也在做算法选型、写论文需要benchmark，或者刚接触KITTI想找一份完整的上手流程，这篇内容可以直接当参考。

1. 为什么拿KITTI做算法对比

1.1 KITTI能解决什么问题

KITTI是德国卡尔斯鲁厄理工学院和丰田芝加哥研究院联合发布的数据集，采集车装了两台灰度相机、两台彩色相机、一个Velodyne 64线激光雷达和GPS/IMU。它覆盖了市区、乡村、高速公路、多人多车等典型驾驶场景，自带目标检测、目标跟踪、深度估计、光流、视觉里程计等任务的标注。所以我这次把它当“统一考场”。自动驾驶感知里大部分算法都会在KITTI上验证，论文里的指标互相可查，我拿KITTI测试不同算法，本质上是在同一套考题下对比不同学生的水平，比拿私有数据集自说自话可靠得多。

还有一个实际原因：KITTI的数据规模适中，原始数据约180GB，但单任务数据集并不大。比如目标检测训练集仅7481帧，深度估计和里程计所需的raw data按序列下载后也就几十GB，单张消费级显卡就能跑完大部分算法。对个人开发者和中小团队来说，没必要一上来就上nuScenes那种几百GB的“全家桶”，先把KITTI的baseline跑通，后面再迁移到更大规模的数据集，是效率最高的路径。

相比很多合成数据集，KITTI的优势是“真”。激光雷达点云、图像、GPS轨迹都来自真实道路场景，对算法的验证更有说服力。虽然它采集时间比较早，传感器分辨率放在今天不算高，但正因为大家都在用同一批数据，横向对比才变得有意义。

1.2 三组算法的选型思路

这次测试我分成三组：2D目标检测、深度估计、视觉里程计。目标检测选了YOLOv8、Faster R-CNN、CenterNet，对应如今最主流的三种设计思路——单阶段、两阶段、无锚框。深度估计选了Monodepth2和Depth Hints，两个都是自监督深度估计里口碑很好的开源项目，前者是基线，后者在损失函数上做了改进，正好能对比出“改进到底值不值”。视觉里程计选了ORB-SLAM3和VINS-Mono，一个基于特征点，一个基于IMU紧耦合，也是SLAM社区最常见的绕不开的两个系统。

选型的判断标准不是“谁最先进就选谁”，而是要考虑代码成熟度、能否跑通、是否适配KITTI。KITTI本身提供了odometry基准，很多SLAM算法都做过适配，ORB-SLAM3甚至自带KITTI示例配置。如果选一个只有论文没有开源的算法，测试流程根本走不起来。所以“工作量大不大”也是算法对比里必须提前评估的隐形指标。

我一开始也想过把车道线检测、多目标跟踪、光流估计全加进来，后来放弃了。测试范围铺得太开，数据准备和评测脚本会膨胀到难以维护。先把三条主线跑清楚，后续要扩展再单独开新模块，这样实验记录也更干净。

2. 数据准备与环境搭建

2.1 下载KITTI的正确姿势

KITTI官网数据下载是网页表单形式，没有一键全量包，网络不稳定时很容易下到一半断掉。我的做法是用wget加断点续传参数，比如：

wget -c https://s3.eu-central-1.amazonaws.com/avg-kitti/raw_data/2011_09_26_drive_0005/2011_09_26_drive_0005_sync.zip

如果只是做目标检测，下载object数据集里的training和testing压缩包就行，不用去碰raw data。raw data体积大，是按日期加drive编号拆分的，如果跑SLAM或深度估计才需要按序列下载。另外，很多教程里会给国内网盘链接，方便是方便，但我不建议直接沿用，一是版本可能过旧，二是链接失效后很难追溯，最好去官网核对一遍文件列表。

下载后不要急着解压，先记下压缩包大小，逐个用unzip -t校验完整性。KITTI文件经常出现解压后内部文件缺失但zip不报错的情况，实际读取时才发现掉了几帧，很麻烦。我现在会写一个校验脚本，把压缩包大小、解压后的文件数量和预期值比对，全部通过后再删压缩包，避免二次下载。

深度估计和视觉里程计会用到raw data，下载前最好先规划需要哪些序列。Eigen split用到的序列主要集中在2011_09_26、2011_09_28、2011_09_29、2011_09_30等日期下，不需要把全部raw data都下下来。odometry benchmarks则单独下载sequences和poses，目录结构更紧凑。

2.2 目录结构与预处理要点

先看目标检测对象数据集的结构：

KITTI/training/ ├── calib/ ├── image_2/ ├── label_2/ ├── velodyne/ └── plane/

calib里存放相机内参、外参和激光雷达到相机的变换矩阵。image_2是左彩色图，label_2是2D/3D检测标签，velodyne是激光雷达点云，plane是地面平面信息。需要特别注意：KITTI的标签中“物体位置location”是相机坐标系下的三维坐标，单位是米，而点云在velodyne坐标系，如果你要训练3D检测模型，必须先根据calib里的R0_rect和Tr_velo_to_cam把点云投影到相机坐标系，否则标签和点云对不上。

raw data的结构稍有不同，每个序列包含image_00到image_03四路图像（灰度双目+彩色双目）、velodyne_points和oxts（GPS/IMU）。做视觉里程计时用image_00/01作为双目输入，用oxts里的轨迹生成真值。预处理时我通常做几件事：把同一序列的图像时间戳提取出来，生成一个frame列表；检查相机和激光雷达时间戳是否对齐；如果需要跑自监督深度估计，再按Eigen split划分训练验证序列，Eigen split是社区通用的划分方式，不用自己随机分，否则和论文结果不可比。

做目标检测时，还需要把KITTI的标签转换成算法需要的格式。YOLOv8需要txt格式的归一化边框，而mmdetection需要json格式的COCO标注。转换的核心是看懂KITTI标签的15个字段：第一个是类别名，后面依次是截断度、遮挡、观察角、bbox坐标、三维尺寸、三维位置和旋转角。很多脚本会把这些顺序搞错，导致训练时检测框飞到奇怪的位置。我的建议是转换完随机抽几帧可视化，确定框和物体对得上再开始训练。

2.3 环境依赖和硬件配置

我的测试机是i9-12900K加RTX 3090，Ubuntu 20.04，PyTorch 1.13，CUDA 11.7。这配置放在2024年不算顶级，但跑KITTI足够了，检测训练一轮大概几小时，深度估计稍慢但在可接受范围。动手之前我用conda建了独立环境，把torch、torchvision、mmcv、opencv-python这些关键依赖固定在某个版本，避免实验到一半因为环境变动导致复现不了。

另外一个值得注意的点是评测期间的GPU确定性。PyTorch很多算子默认不保证完全确定性，如果不设置随机种子，同一份代码跑两次mAP可能差0.2个点。我在每个实验前设置了torch.manual_seed、cudnn.deterministic等参数，虽然没有完全消除随机性，但至少能让结果在合理范围内波动。SLAM实验受CPU调度影响更大，我通过taskset把进程绑定到固定CPU核心，这样帧率统计会比较稳定。

除了主测试机，我还留了一台不带GPU的备用机器专门跑ORB-SLAM3，目的是避免GPU训练任务抢占CPU资源导致里程计帧率抖动。很多时候性能对比结论不稳定，不是算法不行，而是机器上同时开了太多任务。跑benchmark前最好用nvidia-smi检查一下还有没有其他进程占着显卡。

3. 评价指标与统一测试口径

3.1 目标检测怎么打分

KITTI目标检测的官方指标是AP（Average Precision），分easy、moderate、hard三个难度。easy要求目标边界框高度大于40像素、遮挡水平为完全可见，moderate是高度大于25像素、部分遮挡，hard是高度大于25像素、很难辨认。评测时默认用moderate作为汽车类别的结果，这个细节经常被忽略，很多人直接拿COCO的mAP来对比，但KITTI的AP计算方式其实基于40个recall点插值，和COCO的101点插值不一样，出来的数值没有直接可比性。

如果只看2D检测，IoU阈值取0.5还是0.7，结果差距很大。KITTI早期评测对汽车使用0.7的IoU阈值，行人和骑行者使用0.5，我在测试时把三个类别的阈值分开设置，而不是一刀切。3D检测还要额外评估鸟瞰图和3D框的IoU。为了公平，所有检测算法我都使用相同的置信度阈值和后处理NMS参数，这部分必须在实验记录里写清楚，不然复现时对不上。

我自己的习惯是先跑一遍官方devkit，再把官方输出和算法自带的评测结果对比。如果两者差异很大，大概率是后处理参数不一致，而不是算法本身变了。KITTI devkit可以在官网下载，里面有matlab、cpp和python三种版本，我用的是python改写版，方便集成到训练脚本里。

3.2 深度估计指标解析

深度估计的常用指标有RMSE、RMSE log、MAE和delta_k。delta_k表示预测深度与真值深度之比落在一定阈值内的像素比例，比如delta1是max(pred/gt, gt/pred)小于1.25的像素占比，越高越好。真值来自激光雷达点云投影，通常只保留80米以内的点，并且要去掉投影后落在图像边界外的点。KITTI原始点云比较稀疏，所以评测时只在这些有真值的像素位置计算误差，而不是整张深度图。

我用Monodepth2和Depth Hints时，虽然两者都声称是“自监督深度估计”，但评测脚本里的深度裁剪范围不同会导致结果浮动。Monodepth2的官方评估默认将深度限制在0.1到80米，其他模型可能用不同的范围。这次测试我统一使用80米作为最大深度，并且统一使用Eigen split的验证序列，这样不同算法之间的数字才具备可比性。另外一个容易踩的坑是深度图后处理：有的方法用了双边滤波，有的没有，必须把这类后处理也写进实验记录。

还有稀疏真值的问题。KITTI的Velodyne点云投影到图像上后，很多像素位置没有深度，需要做插值或者只取有效像素。不同论文对“有效像素”的定义略有差别，有的要求深度大于0，有的要求大于1米，这些细节都会影响最终指标。为了减少歧义，我在测试脚本里固定了一套有效像素mask，所有算法共用同一个判断逻辑。

3.3 视觉里程计轨迹误差

视觉里程计常用绝对轨迹误差（ATE）和相对位姿误差（RPE）两个指标。ATE衡量整条估计轨迹与真值轨迹的整体偏差，单位是米；RPE衡量固定时间间隔内的相对位姿误差，可以细分为平移误差和旋转误差。对单目视觉里程计来说，还存在尺度不确定性，计算ATE前通常要用Sim(3)变换对齐估计轨迹和真值轨迹，这一步可以由evo工具完成，命令我后面会写。

KITTI odometry基准提供了00到10共11个训练序列，测试时一般取其中几个代表性序列。ORB-SLAM3自带了KITTI双目配置，直接运行即可输出KeyFrameTrajectory.txt和CameraTrajectory.txt。但我发现默认输出的是世界坐标系下的位姿，而KITTI真值轨迹是相对第一帧的，需要先做一次对齐再计算误差。VINS-Mono则没有现成的KITTI配置，需要自己把图像、IMU数据转成ROS bag，这个步骤稍不留神就会让IMU初始化失败。

评估SLAM轨迹我有两个小工具推荐：evo和kitti_odometry_evaluation。evo适合做轨迹对齐和绘图，kitti_odometry_evaluation是官方devkit的重写版，能直接输出KITTI格式的数值。对不同序列按长度归一化后取平均，才是更稳的对比方式。单个序列的数字偶然性很大，特别是ORB-SLAM3这类依赖特征提取的系统，遇到低纹理路段可能突然丢帧。

3.4 容易被忽略的公平性细节

统一测试口径比跑算法本身更花精力。我的经验是先把每个算法官方给出的KITTI结果记录下来，再用同样的输入数据复现，如果官方指标和复现指标差距在允许范围内，说明环境和代码没有问题。然后再去改自己的输入尺寸、训练轮数等变量。否则算法本身没问题，只是你的评测脚本口径变了，排名很容易被扭曲。

另外，训练集划分和图像分辨率必须提前固定。检测算法输入分辨率差异很大，YOLOv8默认是640x640，Faster R-CNN常用1333x800，如果各用各的默认分辨率，统计出来的FPS和mAP实际上是在不同输入尺寸下测的，不能放在一张表里。我这次的做法是全部统一缩放到KITTI原始分辨率的等比例尺寸，但不少算法有下采样倍数限制，实际用了各自最接近的分辨率，然后在表格里额外标注输入尺寸，至少让读者知道数字背后的条件。

还有一个容易被忽略的是“训练轮数”。同一个YOLOv8模型，训练50轮和训练100轮结果能差2到3个点。为了公平，我尽量让每个模型都收敛到自己最理想的水平。比如Faster R-CNN从COCO预训练权重开始，微调12个epoch就能收敛；YOLOv8在KITTI小数据集上收敛更快，但我也给它留了更多轮数，避免“没练够”导致对比不公平。

4. 实操过程与结果复盘

4.1 2D目标检测：YOLOv8、Faster R-CNN、CenterNet

先跑的是YOLOv8，因为ultralytics库开箱即用，数据处理文档也全。需要把KITTI标签转成YOLO格式，即归一化的中心点坐标和宽高。转换脚本不难，但要注意类别名称要和yaml文件对应，KITTI汽车、行人、骑自行车的人三类的顺序不要搞错。用COCO预训练权重做初始化，在KITTI训练集上微调50个epoch，输入分辨率设成640x640。训练完成后用val模式输出mAP50和mAP50-95，但我同时用KITTI官方devkit重新算了一版AP，因为官方devkit的难度划分更细致。

YOLOv8训练命令大概是这样：

yolo train data=kitti.yaml model=yolov8s.pt epochs=50 imgsz=640 batch=16 device=0

紧接着我用mmdetection跑Faster R-CNN。backbone选ResNet50加FPN，加载COCO预训练模型后在KITTI上微调12个epoch。这里有个参数要特别注意：KITTI目标很小，训练时anchor的scale要调小，否则容易漏检远处行人。CenterNet我用官方实现，它和Faster R-CNN不一样，输出的是热力图中心点，不需要anchor，但在KITTI这种车辆密集场景下容易出现两个中心点重叠，后处理需要调节max_pool的kernel size。

检测结果我汇总成了一个小表。YOLOv8s在moderate AP上大约84到85，帧率能到110以上；Faster R-CNN moderate AP接近87，帧率只有25左右；CenterNet AP在81附近，帧率70多。这里要强调，mAP数字不是越高说明算法越好，而是要看你的部署目标。如果做实时嵌入式检测，YOLOv8的收益明显；如果离线处理且对精度有极致追求，Faster R-CNN这类两阶段方法还能再压榨一些性能。

4.2 单目/双目深度估计：Monodepth2与Depth Hints

Monodepth2是自监督深度估计的经典baseline，它的做法是用双目图像对的重投影误差来监督深度网络，不需要真值深度。Depth Hints在它基础上引入一个教师模型来生成稠密深度线索，能改善低纹理区域的深度估计质量。两者代码结构很像，测试起来很方便：先下载官方权重，然后对KITTI测试序列逐帧推理，保存深度图，再用官方eval.py计算指标。

运行Monodepth2时有一个选项是--pred_metric_depth，如果开这个，模型会预测真实尺度深度；如果不开，输出的是归一化相对深度，评测前必须做尺度对齐。我用的是双目版本，模型输出的就是metric depth，可以直接和激光雷达真值比较。Depth Hints的体积更大，显存占用高了将近2GB，推理速度也从大约70 FPS降到55 FPS，换来的是delta1提高了2%左右。这类“以算力换精度”的提升，在实际项目里值不值，完全取决于部署平台的上限。

我在KITTI验证集上测到的数字是：Monodepth2的delta1大约0.869，RMSE接近4.67米；Depth Hints的delta1大约0.889，RMSE降到4.40米左右。听起来0.02的delta1提升不算大，但在夜间或反光区域，Depth Hints生成的深度图边界更干净，对后续障碍物检测更有利。不过训练它需要额外的教师模型和前向传播，训练时间是Monodepth2的1.5倍，显存要求也更高。如果你的硬件预算有限，先从Monodepth2起步会更稳妥。

4.3 视觉里程计：ORB-SLAM3与VINS-Mono

ORB-SLAM3跑KITTI不需要额外写太多代码，官方仓库里Examples_old/Examples/Stereo有KITTI的配置文件。我先跑了sequence 00，命令大概是：

./Examples/Stereo/stereo_kitti \ Vocabulary/ORBvoc.txt \ Examples/Stereo/KITTI00-02.yaml \ /path/to/KITTI_odometry/sequences/00

输出轨迹后，我再用evo对比真值。ORB-SLAM3在KITTI 00上表现很稳定，ATE大约2.1米，跟踪线程全程稳定在90 FPS以上，说明稀疏特征里程计在计算量上很有优势。不过它返回的是稀疏地图，不能直接用于避障或精细三维重建，这是特征点方法的通病。

VINS-Mono跑KITTI相对麻烦，需要把KITTI odometry的image_00/image_01和oxts数据转成ROS bag，并填写相机内参和IMU外参。我转换时踩了坑：KITTI的IMU频率只有10Hz，而VINS-Mono对IMU采样频率有一定要求，频率太低会导致预积分误差偏大，初始化常常失败。后来我把oxts数据插值到100Hz，重新生成bag，才算跑通。在KITTI 00上，VINS-Mono的双目加IMU融合结果和ORB-SLAM3接近，但IMU存在时会明显抑制纯视觉位姿的抖动。

evo评估的命令我放在这里，方便你直接抄：

evo_ape kitti CameraTrajectory.txt poses/00.txt -a -s evo_rpe kitti CameraTrajectory.txt poses/00.txt -a -s --delta 1 --delta_unit m

-a表示自动对齐，-s表示Sim(3)对齐。对单目系统，这两个参数几乎必须加，否则尺度误差会直接淹没位姿误差的真实水平。

4.4 整体性能对比表格

到这里，三个方向的测试数据都有了，我整理成一张汇总表：

从这个表能看出，检测算法里性价比最高的是YOLOv8，深度估计里Monodepth2的实时性更好但精度略低，SLAM场景下ORB-SLAM3的CPU占用更低，VINS-Mono在引入IMU后位姿更平滑但没有拉开明显差距。这个结果不代表算法在所有条件下都是这个排序，比如在低光或高速运动场景下，各方法的鲁棒性排序可能会变，需要再设计专门的压力测试。

我不建议直接把这张表的结论当成“最终答案”。检测任务的mAP受到训练数据分布影响很大，KITTI训练集里市区场景多，高速场景少，换到实际高速公路上的表现可能会重新洗牌。深度估计也是如此，KITTI的LiDAR真值在远距离处非常稀疏，RMSE对近处误差更敏感，这个特性不一定和真实部署需要的误差分布一致。

5. 常见问题与排查技巧

5.1 下载、解压和文件校验

我遇到过好几次KITTI压缩包下到99%卡死，用浏览器重下又非常耗时，所以现在都用支持断点续传的命令行工具。另外zip文件本身不提供md5，官方只有一个总文件列表，我的校验技巧是解压后直接看文件夹里的PNG数量是否符合预期，比如object training的image_2里应该有7481张图，velodyne里对应7481个bin文件。如果对不上，那一帧的传感器数据就是损坏的。这个问题排查起来很隐蔽，算法训练时不一定会报错，但评测某些序列时会突然崩溃。

5.2 点云和图像投影不对齐

激光雷达点云投影到图像后，如果车身周围物体的边缘出现双重影像，多半是标定参数用错了。KITTI的calib文件里Tr_velo_to_cam是激光雷达到参考相机的旋转平移矩阵，但它只是到相机0坐标系的，还要乘上R0_rect校正矩阵才到图像坐标系。很多人把这两个矩阵的顺序搞反，导致投影结果差几像素。我有一次跑了整个3D检测训练流程后才发现标签和点云错位，浪费了三天时间，后来写了个可视化脚本，把点云叠加到图像上人工校验，确认无误再开始训练。

5.3 标签转换和难例过滤

把KITTI标签转YOLO格式时，需要过滤掉类型为DontCare的物体，它们是标注者故意标为“不参与计算”的难例。如果不过滤，模型训练时会被一些无意义的框干扰。另外一个细节是KITTI的遮挡/截断标注，很多转换脚本会忽略难度等级，导致easy和hard样本全部混在一起。我建议在转换时保留原始难度标签，至少把hard样本单独分出去做困难测试集。

我踩过的一个具体坑是训练集里混入了“演出人员”这种KITTI特殊类别，让YOLO的类别数多了一个，训练一直不收敛。后来才发现KITTI标签中有些类别在正式评测里并不参与AP计算，这些类别要么合并成Car或者忽略。代码里加一个类别白名单，能省不少事。

5.4 指标口径不一致导致结论翻车

我最初对比YOLOv8和Faster R-CNN时，直接用了YOLOv8自带的mAP50-95和mmdetection的COCO格式mAP，结果发现YOLOv8的mAP50-95反而更高，但换成KITTI官方devkit的moderate AP后，Faster R-CNN又赢了。这说明评测工具不同，算法排名可能反转。我的建议是，凡是声称“基于KITTI数据集”的结果，一律用官方devkit或者社区公认复现的评估代码再验算一遍，同时把输入分辨率、置信度阈值、NMS阈值这些超参写进最终报告，否则你测出来的性能根本没法定量复现。

如果你要复现论文里的数据，还有个容易被坑的地方是“训练集和验证集不能重叠”。KITTI object检测的训练集和验证集在社区中有多种划分方式，你随机切分的seed不同，最终hard样例分布也会不同。我直接用官方object train做训练，再用留出的验证帧做评测，虽然样本量小，但至少别人也能用同样方式复现。

6. 经验沉淀与后续计划

6.1 这次测试我总结的三条经验

第一条，算法对比最怕“各说各话”，评测口径统一比算法本身更重要。三个算法如果连输入分辨率都不一样，比的就不是算法而是工程调参水平。第二条，数据集不是越大越好，KITTI虽然数据量不算大，但因为它覆盖的任务全、社区工具链成熟，很适合做算法快速筛选。第三条，性能评测要“留痕”，每一组实验对应的代码commit、权重文件、运行参数都要记录，不然半年后回头看，根本不知道当时那张性能表是怎么来的。

我自己的实验管理方式是用一个简单表格记录：算法名、代码仓库commit号、预训练权重来源、训练epoch、输入尺寸、评测脚本版本、最终指标。接下来还会补上GPU功耗和延迟的P99。这样写周报、写论文、给团队做技术方案对比，都能直接拿出依据。

6.2 把评测流程做成自动化基线

测试刚跑完时我也产生过“这就完事了吗”的念头。后来我把shell脚本和Python封装成一键评测流水线，输入KITTI路径，依次跑检测、深度估计、里程计三个模块，最后汇总成一份CSV报告。另一个队友把整个环境打成了Docker镜像，新机器拉下来就能复现。这套东西我现在还在维护，每次候选算法更新，都会先在KITTI上过一遍，确保性能变化可追踪。

Docker镜像的好处是隔离了CUDA和Python依赖的版本冲突。KITTI相关的旧代码很多依赖老版本opencv，新版本一升级API直接报错。容器固化之后，这些问题基本不会再出现。

6.3 还可以往哪些方向扩展

KITTI毕竟只是中等规模的数据集，测试结论在复杂城市道路上不一定完全成立。我的下一步计划是把同样的流程迁移到KITTI-360和nuScenes，重点看算法在新传感器配置、新天气条件、新标注体系下的表现。尤其是3D目标检测，KITTI的车辆类别相对单一，换到nuScenes后类别更多、遮挡更严重，算法排名很可能会重新洗牌。另一个方向是端侧部署性能，把模型转到ONNX/TensorRT再测一轮FPS和显存，团队里已经有小伙伴在做了。

如果只是做算法预研，我建议你把这个流程简化成三个“固定”：固定数据集、固定指标脚本、固定硬件环境。只要这三个固定到位，剩下的变量就是算法本身，测试结论的说服力自然就上来了。

最后多说一句：我习惯用wandb或者一个简单的CSV表格记录每次实验的输入尺寸、随机种子、训练epoch、评测脚本版本，别看这个动作简单，关键时刻能救你。KITTI这个数据集就像一套固定试卷，真正拉开差距的不是谁跑得快，而是谁能把变量控制得死。这一点等你复现别人论文的时候会体会更深。