简介面向SLAM、视觉里程计与自动驾驶方向的学习者与研究者这份文档系统梳理了TUM RGB-D、KITTI与EuRoC三大主流数据集的核心信息帮助读者快速建立选型与使用认知。内容涵盖TUM的Kinect采集方式、彩色与深度图存储规格、深度值5000倍缩放约定、groundtruth四元数位姿格式以及ATE与RPE两类评价准则的适用差异和点云生成脚本同时介绍KITTI采集平台的多传感器配置、raw data按场景分类的组织方式与标定文件构成并简述EuRoC微型无人机数据集的多传感器组成。资源包为1个docx文档约1.93MB便于离线查阅与整理笔记。目前已有9633人学习下载适合需要横向对比数据集格式、评估指标与数据组织方式的读者作为参考资料。1. 三个数据集三种“考卷”搞懂 TUM、KITTI、EuRoC 到底在测什么刚接触视觉 SLAM 或自动驾驶感知的人常会撞上一个困惑论文里动不动就写“在 TUM 上跑了一遍”“KITTI 排名第几”“EuRoC 上漂移多少”可自己下载下来一看一个是室内小桌面的彩色加深度图一个是马路上跑车的激光雷达点云还有一个是无人机在厂房里飞出来的双目加 IMU 数据。它们看起来完全不是一回事为什么能放在同一句话里比较通俗地说这三个数据集就是三张不同科目的“考卷”。TUM RGB-D 考的是“室内小场景里你用彩色加深度相机能不能把轨迹估准”KITTI 考的是“马路上开着车你的检测、跟踪、测距算法扛不扛得住真实交通”EuRoC 考的是“无人机快速飞行、相机和 IMU 一起上你的视觉惯性里程计稳不稳”。搞懂它们各自考什么、怎么评分你才能看懂论文里的数字也才知道自己手里的算法该拿哪张卷子去试。这份资料把三套数据集的采集平台、文件格式、真值组织方式和评价脚本都整理在了一起下面就从“是什么”一路讲到“什么时候该用哪张卷”。2. TUM RGB-D室内小场景的“标准答案”是怎么给的2.1 它到底是什么一台 Kinect 加一套动作捕捉TUM RGB-D SLAM Dataset and Benchmark 来自某高校计算机视觉组采集设备是一台 Kinect 相机同时记录彩色图、深度图部分序列还带 IMU 数据。关键在于“真值”从哪来——不是靠算法自己算的而是用高精度运动采集系统一套贴在相机上的反射标志加多台跟踪相机实时测出相机的真实位姿帧率高、精度到毫米级。这就好比考试时老师手里有一份标准答案你交的轨迹和它一比差多少一目了然。数据集按场景分成多个序列比如 freiburg1_xyz 是相机在桌面上沿三个轴缓慢平移freiburg2_desk 是绕着一张办公桌转freiburg3 系列则涉及更长的走廊和更复杂的运动。每个序列都配了对应的真值轨迹文件还提供了 ROS 的 bag 包把彩色图、单色图、深度图、相机内参、点云和世界坐标系变换打包在一个文件里方便直接回放调试。2.2 文件格式里藏着的几个“坑”彩色图是 640×480 的 8 位 RGB PNG深度图是同样尺寸的 16 位单色 PNG。这里有个必须记住的细节深度图按 5000 倍缩放也就是说像素值 5000 对应真实距离 1 米像素值 0 表示这个点没有深度数据比如玻璃、反光面或超出量程。很多新手第一次用直接把像素值当毫米或米来算轨迹尺度立刻翻车这是血泪经验级别的常见错误。真值轨迹用 txt 存每行一个位姿格式是timestamp tx ty tz qx qy qz qw。timestamp 是 Unix 纪元以来的秒数前三个浮点是彩色相机光心相对运动捕捉系统世界原点的位置后四个是单位四元数表示的方向。四元数不是欧拉角顺序也不是常见的 wxyz 而是 xyzw读文件时顺序搞反姿态会整个错乱。# 读取 TUM 真值轨迹的典型写法注意四元数顺序是 qx qy qz qw import numpy as np def load_tum_trajectory(path): data np.loadtxt(path) timestamps data[:, 0] # 秒 positions data[:, 1:4] # tx ty tz单位米 quats data[:, 4:8] # qx qy qz qw注意不是 wxyz return timestamps, positions, quats这段代码只做一件事把每行的七个数字拆成时间、位置、四元数三组。参数含义就是上面说的位置单位是米四元数需要归一化后再转旋转矩阵。深度图转点云时用generate_pointcloud.py这个示例脚本输入彩色图和深度图输出 PLY 格式可以直接拖进 MeshLab 这类三维软件里看。脚本内部做的就是按相机内参把每个像素反投影成三维点再把 RGB 颜色贴上去。2.3 评分规则ATE 和 RPE 各管什么TUM 提供两个评价脚本对应两种误差。绝对轨迹误差 ATE 直接比较真实轨迹和估计轨迹上对应时刻的点之间的距离预处理时先用时间戳把估计位姿和真值关联起来再用奇异值分解做一次整体对齐因为两者世界原点可能不同最后输出均值、中值、标准差还能画成 png 或 pdf。它适合衡量“整个 SLAM 系统整体准不准”。相对位姿误差 RPE 则看的是“相邻一段时间内的相对运动误差”默认计算所有时间戳对之间的误差但时间戳对数量随轨迹长度呈平方增长所以脚本允许用-max_pairs下采样或者用-fixed_delta加-delta_unit固定一个时间窗口。它更适合衡量“视觉里程计的漂移”比如每秒漂多少。打个比方ATE 像看整条路线你走偏了多少RPE 像看每一小段你走的方向偏了多少。3. KITTI马路上的“全能考场”怎么组织数据3.1 采集平台一辆改装车顶着一堆传感器KITTI 由两所高校合作制作采集车是一辆改装过的轿车后备箱里塞了一台 8 核 i7 跑 Ubuntu 录数据。车顶的传感器阵容是重点1 个 GPS/IMU 惯性导航系统、1 个 64 线激光扫描仪、2 个灰度相机、2 个彩色相机外加 4 个变焦镜头。激光雷达 10 帧每秒扫描相机也保持 10Hz并且在激光雷达朝向正前方时释放快门保证多传感器在时间上对得齐。图像原始采集尺寸被裁到 1382×512校正后可能更小。这套配置决定了 KITTI 的“气质”它不是实验室里慢慢挪的相机而是真实道路上高速运动的平台所以它的数据天然适合测自动驾驶相关的感知和定位算法。所有传感器数据以 image_00 作为同步参考系每份数据都带时间戳。3.2 raw data 的组织方式同步校正过的才是常用款raw data 按场景类别分成 Road、City、Residential、Campus、Person 几类。每个序列都提供传感器原始数据、相机视野内目标的 3D 包围盒跟踪标签以及一个标定文件。标定文件用 txt 存描述相机与相机之间、相机与 GPS/IMU 之间、相机与激光雷达之间的变换关系——这是做多传感器融合的前提没有它点云和图像根本对不上。数据分“原始”和“处理过”两套原始的是带畸变、没同步的处理过的是消除畸变、做过双目校正、并且和其他传感器对齐好的一般大家用的就是这套 syncedrectified 数据。双目灰度图和彩色图都是 50 万像素 PNG激光雷达每帧 10 万多个点用 .bin 格式按 float 矩阵存3D 目标跟踪标签是 xml覆盖汽车、卡车、火车、行人、自行车人这几类。3.3 object 和 tracking一个考单帧检测一个考连续跟踪object 数据集专门验证目标检测分“2D 检测框”“3D 检测框”“鸟瞰图检测”三部分分别对应图像上的框、三维空间或激光雷达里的包围盒、以及俯视图上的检测。它每个下载包解压后有 training 和 testing 两个文件夹训练集带标注。要注意的是object 数据并不是连续采集的都是单帧结果只适合检测算法别拿它去训跟踪。tracking 数据集的组织方式和 object 类似最大区别是每个序列是连续帧专门用来验证目标跟踪算法。这个区分很关键拿单帧检测数据去评估跟踪时序信息根本不存在结果没有意义。数据子集主要用途是否连续标注形式raw data通用感知与定位是3D 包围盒跟踪标签、标定文件object目标检测否单帧2D/3D/鸟瞰图检测框tracking目标跟踪是连续帧目标标签4. EuRoC无人机视角下的双目加 IMU 怎么对齐4.1 硬件与真值飞行器上贴标志屋里布跟踪相机EuRoC MAV Dataset 来自某高校用装备了双目相机和 IMU 的四旋翼无人机采集场景包括一个机器厂房和一个室内房间。真值同样来自高精度运动采集系统在无人机上贴一组反射标志多台跟踪相机以 100Hz、毫米级精度测出它在单一坐标系下的 6D 位姿。这就给视觉惯性里程计提供了一个可信的参照。数据集结构里能看到 cam0、cam1、imu0、leica0 四个文件夹分别对应两个相机、一个 IMU 和一个激光跟踪设备。飞行器的 Body Frame 以 IMU 中心为原点每个传感器文件夹里配一个 sensor.yaml写明该传感器相对 Body 坐标系的变换以及自身内参。这个约定非常重要所有传感器数据都是相对各自传感器坐标系的你要做融合第一步就是按 yaml 把它们统一到 Body 坐标系。4.2 坐标系变换TBS 到底在变什么资料里给了一个旋转坐标变换的约定设相机坐标系 pc 下的向量变换到世界坐标系 pw公式里出现的 RWC 意思是“把一个在 C 坐标系下表示的点的坐标变换成以 W 坐标系下表示的坐标”。同理TBS 表示把所有 Sensor 坐标系下的向量变到 Body Frame 下。很多初学者在这里犯迷糊把变换方向搞反结果轨迹镜像或者整体旋转。通俗地说每个传感器都活在自己的小世界里sensor.yaml 就是一张“从我的世界到机身世界”的翻译表。做视觉惯性融合前先把 cam0、cam1、imu0 的数据都翻译到 Body Frame再谈时间对齐和优化。真值输出带 18 位时间戳精度足够做微秒级对齐。4.3 它和 TUM 的相似与不同两者都用运动采集系统给真值都提供量化评估脚本这是相似处。不同在于TUM 是 Kinect 的 RGB-D主打室内小场景的稠密几何EuRoC 是双目加 IMU主打无人机快速运动下的视觉惯性里程计而且双目没有深度图深度得靠视差算。所以拿 EuRoC 去测一个纯 RGB-D 算法并不合适反过来拿 TUM 去测视觉惯性融合也缺 IMU 激励。选数据集前先看传感器配置这一步省不得。5. 常见误区这三个数据集最容易混在哪5.1 误区一以为“有真值”就等于“能直接比”易混点很多人觉得只要数据集带 groundtruth把自己的轨迹丢进去算个误差就行。为什么混三个数据集确实都提供真值但真值的坐标系、时间基准、关联方式完全不同。怎么区分TUM 的真值在运动捕捉系统世界原点下评估脚本会先用时间戳关联再做 SVD 对齐KITTI 的真值跟 GPS/IMU 和激光雷达标定绑在一起EuRoC 的真值在跟踪系统单一坐标系下还要经过 Body Frame 变换。直接跨数据集套脚本数字没有可比性。5.2 误区二把 ATE 和 RPE 当成一回事易混点两个都是误差指标看起来都是“越小越好”。为什么混名字都带“误差”输出也都是统计量。怎么区分ATE 衡量整条轨迹的绝对偏差适合评价完整 SLAM 系统RPE 衡量固定时间窗口内的相对运动偏差适合评价里程计的漂移率。一个算法可能 ATE 很小但 RPE 在某段很大说明它整体对齐后不错、局部却有跳变。看论文时要看清作者报的是哪个。5.3 误区三拿 object 数据去训跟踪或拿 tracking 去测单帧检测易混点KITTI 的 object 和 tracking 都带目标标注看起来能互换。为什么混两者标注内容相似都是车、人、自行车这些类别。怎么区分object 是单帧、不连续只适合检测tracking 是连续序列才有时序关系。用单帧数据训出来的模型去跑跟踪帧间关联根本学不到反过来用连续数据测单帧检测又浪费了时序标注。5.4 误区四忽略深度图的缩放和四元数顺序易混点读 TUM 深度图和真值时直接按“像素值就是距离”或“四元数就是 wxyz”处理。为什么混PNG 存的是整数看起来像原始测量值四元数顺序在不同库里有不同约定。怎么区分记住深度像素值除以 5000 才是米0 是无效值TUM 真值文件是 qx qy qz qw转旋转矩阵前先确认库的四元数约定必要时重排。6. 什么时候用哪张卷选数据集的边界判断选数据集这件事本质是问自己“我要验证的能力和这张卷子考的能力是不是一回事”。如果你做的是室内 RGB-D 的稠密建图或小场景 SLAMTUM 是最直接的起点它的深度图、真值轨迹和 ATE/RPE 脚本形成了一条完整的量化链路跑通一遍就能知道自己算法的整体精度和漂移水平。但要注意TUM 场景小、运动慢别指望它证明你的算法在高速或大尺度下也稳。如果你做的是自动驾驶相关的检测、跟踪、双目测距或激光雷达感知KITTI 是绕不开的。它的传感器配置贴近真实车辆object 和 tracking 分工明确raw data 还带完整标定。但 KITTI 的数据量大、标注类别有限而且它的场景集中在特定城市道路遇到更复杂的天气或非结构化道路结论要谨慎外推。如果你做的是视觉惯性里程计、无人机状态估计EuRoC 才是对口的卷子。双目加 IMU 的配置、100Hz 毫米级真值、明确的 Body Frame 和 sensor.yaml 约定让它成为检验融合算法坐标系处理是否正确的试金石。反过来说如果你的算法根本不用 IMU硬上 EuRoC 只会暴露一堆与算法无关的配置问题。你的任务优先选别选它的理由室内 RGB-D 稠密 SLAMTUM场景小、运动慢不能证明大尺度性能自动驾驶检测与跟踪KITTI场景集中类别有限外推需谨慎视觉惯性里程计EuRoC无 IMU 的算法上去只会卡在配置纯双目测距KITTI 或 EuRoC看你要道路场景还是无人机场景我自己的习惯是每次拿到一个新算法先问它吃哪种传感器、输出什么、在什么运动模式下工作然后只挑一张对口的卷子跑通基线再考虑跨数据集验证。有一次图省事拿一个纯 RGB-D 的流程直接往 EuRoC 上套结果卡在 sensor.yaml 的坐标系变换上折腾了半天最后发现根本不是算法问题是卷子选错了。从那以后我每次开新项目都强制先把传感器配置和真值坐标系对一遍再动手。希望这份整理能帮你在选数据集这件事上少走几步弯路资料里三套数据集的格式、脚本和评价准则都齐了需要的时候直接取用即可。本文还有配套的精品资源点击获取