1. 先搞清楚 KITTI 标定文件到底在标什么KITTI 这套数据在自动驾驶圈子里被翻来覆去用了十来年很多人第一次接触它注意力都放在 label_2 里的三维框和 velodyne_points 里的点云上标定文件反而是最后才去翻的。我自己的经历也是这样早期做点云上色的小工具把点云直接往图像上怼结果画面里只孤零零飘着几个点大部分点全跑到画布外面去了折腾了大半天才发现是把坐标系方向搞反了。后来才明白标定文件其实是整个 KITTI 数据集的地基标注、点云、图像之间的所有对应关系都靠它撑着地基没打对上面盖什么都歪。说得直白点KITTI 的标定文件干的事情就一件告诉你相机、激光雷达、惯导这三套设备各自的坐标系是什么朝向以及它们之间怎么互相换算。它不负责告诉你场景里有什么物体也不负责告诉你画面像素对应哪个物理点它只负责提供翻译规则。你拿到一个激光雷达点想知道它投到图像上是哪个像素反过来你看到图像上一个像素想估它离车多远——这些都要靠标定文件里那几十行科学计数法算出来。适合谁来啃这块内容做三维目标检测的、做点云与图像融合的、做深度补全的、做多传感器联合标定的以及想拿自己车上采集的数据复现 KITTI 流程的这些人绕不过去。哪怕你只是想把 KITTI 当作练手数据跑通一个 YOLO 或者 PointPillars标定文件的解析代码也是你数据加载器里最早要写对的那部分。它解决的核心痛点是可复现。同一段数据你算出来的投影结果和别人算出来的必须一致否则所有基于这个数据集的论文结果都没法比较。KITTI 把内参、外参、畸变、校正矩阵全部以纯文本形式随数据一起发布谁都能独立复核这一点比不少自采数据集要省心得多——很多自采数据集标定参数藏在某个二进制文件或者某个内部工具里换个人就复现不出来。下面我按照自己踩坑的顺序从文件组织讲起一路讲到能跑通投影、能验证精度、能挂到下游任务上。1.1 三套坐标系以及它们之间的翻译关系要读懂标定文件先得把 KITTI 用到的三套坐标系刻进脑子里否则后面每一个矩阵你都会看得云里雾里。相机坐标系的约定是x 轴指向图像右侧y 轴指向图像下方z 轴沿着光轴指向画面深处。这是计算机视觉领域最常见的约定你写任何投影代码时的默认假设基本都是它。Velodyne 激光雷达坐标系的约定是x 轴指向车辆前方y 轴指向车辆左侧z 轴垂直于地面向上。注意这里和相机完全不同——相机是右、下、前雷达是前、左、上。IMU/GPS 坐标系和雷达坐标系朝向一致也是前、左、上区别只在原点位置和安装位置不同两者之间靠一个固定的刚体变换联系。把这三套约定摆在一起看你会发现相机和雷达之间至少差了两个轴方向的翻转相机的 x 等于雷达 y 的反方向相机的 y 等于雷达 z 的反方向相机的 z 等于雷达 x 的正方向。这个关系不是猜的你可以直接拿calib_velo_to_cam.txt里的旋转矩阵去验证后面我会演示怎么用这个方法做交叉检查——这是我最常用的一个自查手段比反复读文档可靠得多。生活里可以打个比方三个人分别用东南西北前后左右上下左右来描述同一个房间里的东西标定文件就是那本三方对照词典。词典写错了或者你翻词典的时候看串行了描述就会对不上。KITTI 的标定文件本质就是这么一本词典只不过用矩阵的形式写的。1.2 同一个数据集两套标定文件格式别混用这是很多人第一次上手会困惑的地方KITTI 网站上你下载的数据包里标定参数其实是两套不同的组织形式用途不一样。第一套是原始多文件格式出现在data_object_calib或者 raw data 的日期目录里包含三个独立文件calib_cam_to_cam.txt、calib_velo_to_cam.txt、calib_imu_to_velo.txt。每个文件里字段很多除了外参还有内参、畸变系数、校正矩阵、图像尺寸等等信息最全做标定研究和需要原始参数的场景必须用它。第二套是合并单文件格式出现在目标检测 benchmark 的training/calib/目录下文件名就是帧号比如000000.txt。这个文件被大幅简化了只剩七行P0、P1、P2、P3四个投影矩阵R0_rect校正矩阵Tr_velo_to_cam雷达外参Tr_imu_to_velo惯导外参。内参K、畸变D、原始图像尺寸S全都不在里面了因为它们已经被烘焙进P0到P3里。我把两者的对应关系整理成一张表方便你对照字段原始多文件格式合并单文件格式说明投影矩阵P_rect_00~P_rect_03P0~P3数值完全一致直接搬过来校正旋转R_rect_00R0_rect一致都是 3x3 展平成 9 个数雷达外参calib_velo_to_cam.txt的R、TTr_velo_to_cam合并版把 R 和 T 拼成了一个 3x4惯导外参calib_imu_to_velo.txt的R、TTr_imu_to_velo同理拼成了 3x4内参K_00~K_03无合并版里被吸收掉了畸变D_00~D_03无合并且应用在图像上之后就没必要再存图像尺寸S_00~S_03、S_rect_00无校正后统一为 1242x375基线T_01、T_02、T_03等无做双目深度需要它注意同一个序列里这两套文件的数值是对得上的但字段名和维度不同。如果你写了一个加载器只认P_rect_00这种带下划线的写法换到training/calib上就会直接报 KeyError。我建议解析函数用先按冒号切、再按需取键的通用写法两套格式都能吃。另外还有个小细节值得提一句training/calib/000000.txt这类文件的键名在不同版本的数据包里偶尔有细微差别有的写R0_rect有的写R0_rect后面直接跟 9 个数中间没有多余空格。写解析器时用line.split(:, 1)切一刀最保险别用固定位置切片。2. 逐字段拆解 calib_cam_to_cam.txt这个文件是四个相机0 号左灰度、1 号右灰度、2 号左彩色、3 号右彩色的完整标定集合字段名基本遵循量_相机编号的命名规则。下面挑几个最容易出错的字段逐个说。2.1 P_rect_0x 和 K_0x 的焦距为什么对不上先看一组真实的数值。K_00是 3x3 内参矩阵展平成 9 个数P_rect_00是 3x4 投影矩阵展平成 12 个数。很多人第一反应是这俩里面都装了焦距应该能互相推出来然后就会卡住。以 KITTI 官方给出的calib_cam_to_cam.txt为例K_00里的焦距分量大约是 984.24主点大约在 (690.0, 233.2)而P_rect_00里的焦距分量大约是 721.54主点大约在 (609.6, 172.9)。如果按图像宽度做等比换算原始图像宽 1392、校正后图像宽 1242比例是 0.892984.24 乘上去应该得到 878 左右和 721.54 差了十万八千里。这说明什么说明校正过程不只是把图像裁剪、缩放一下就完事它还包含了去畸变带来的视场重映射两个焦距之间不存在简单的一一对应。所以我的建议很明确不要试图从 K 推导 P_rect也不要拿 K 去替换 P_rect。这两个量服务于不同的图像版本K和D面向的是原始未校正图像P_rect面向的已经是校正后图像。你做点云投影时用的永远是P_rect因为 KITTI 官方发布的image_2就是校正后的图。要是你不小心把K塞进投影公式画出来的点会整体偏移几十个像素而且偏移量还随位置变化非常难查。P_rect的后三列里第四列全是零这也很正常——它描述的是两个校正后共面相机之间的投影关系平移量已经在校正过程中归到无穷远了。真正携带平移信息的是T_01、T_02、T_03这些基线分量。提示如果你只是做单目投影只需要P_rect_02和R_rect_00加上雷达外参四个投影矩阵里的另外三个其实用不到。别被一堆字段吓到先把最常用的那条链跑通再说。2.2 R_rect_00 和 S_rect_00被最多人忽略的校正环节R_rect_00是一个 3x3 的旋转矩阵作用是把 0 号相机也就是整个相机组的参考相机的坐标系旋转到一个共面对齐的姿态上让四个相机的成像平面互相平行。为什么要做这一步因为物理安装时四个相机不可能装得严丝合缝光轴之间总有零点几度到几度的夹角。如果直接拿原始图像做双目匹配或者多目融合极线是斜的搜索起来很麻烦。校正把光轴掰平行之后极线就变成了水平线匹配只需要在同一行里找效率高得多。我实际用的时候习惯把它扩展成 4x4方便和外参矩阵连乘import numpy as np R_rect np.eye(4) R_rect[:3, :3] cam[R_rect_00].reshape(3, 3)S_rect_00则是校正后图像的尺寸格式是宽 高KITTI 上普遍是 1242x375。这个值看着不起眼实际有两个用处一是做投影有效性判断时用来确定边界二是当你想把不同相机的图像拼在一起显示时必须知道各自的分辨率。我见过有人把S_00原始尺寸 1392x512当成校正尺寸来用结果裁剪出来的 ROI 全是错位的非常隐蔽。顺便说一句S_rect_00和S_rect_01、S_rect_02、S_rect_03是同一个值因为它们已经被校正到同一个平面上了。如果你发现它们不相等那大概率是文件被改过或者你读错了字段。2.3 D_0x 畸变参数在投影流程里到底还用不用这是我在技术群里被问得最多的一个问题KITTI 的投影流程里畸变系数D_00到底要不要参与计算答案取决于你的图像版本。KITTI 官方发布的image_0到image_3都是已经去畸变并校正过的图像配套的P_rect_0x也是针对这些校正图像的。所以标准的点云投影流程里D根本不出现——它不是被忽略了而是它的效果已经被预支到图像和P_rect里了。只有在一种情况下你需要D你要从零开始处理原始的、未校正的图像。比如你自己采集的数据想复刻 KITTI 的流程或者你想研究畸变校正本身对精度的影响。这时候流程会变成先用K和D去畸变再用R_rect做共面对齐最后用去畸变后的内参投影步骤比直接用P_rect多不少中间的符号和顺序都很容易搞错。我自己的经验是除非你有明确的理由否则一律走P_rect路线。走得人多了坑都被踩平了开源实现也多遇到问题搜一下基本都有答案。3. 外参链路velo_to_cam 与 imu_to_velo内参解决的是相机内部怎么成像外参解决的是不同传感器之间怎么换算。KITTI 的外参链路是三级串联的IMU - Velodyne - Camera每一级都是一个刚体变换形式都是旋转矩阵 R 加平移向量 T。3.1 R 和 T 的存储形态以及最常见的解析错误calib_velo_to_cam.txt里长这样以官方数据为例calib_time: 15-Mar-2012 11:37:16 R: 7.533745e-03 -9.999714e-01 -6.166020e-04 1.480249e-02 7.280733e-04 -9.998902e-01 9.998621e-01 7.523790e-03 1.480755e-02 T: -4.069766e-03 -7.631618e-02 -2.717806e-01R 有 9 个数T 有 3 个数都是按行优先排成一行。你要把它们分别 reshape 成 3x3 和 3x1而不是 3x1 和 3x1 那种。我见过有人把 R 当成 9 个独立的旋转角去用结果当然是完全跑偏。拼成齐次矩阵的写法def make_transform(R, T): Tr np.eye(4) Tr[:3, :3] R.reshape(3, 3) Tr[:3, 3] T.reshape(3) return Tr Tr_velo_cam make_transform(velo[R], velo[T])这里有个非常实用的自检技巧。前面说过相机的 z 轴前向对应雷达的 x 轴前向那么把 R 按行看第三行应该近似是[1, 0, 0]因为雷达 x 轴几乎原封不动地变成了相机的 z 轴。上面那组数据里第三行是9.998621e-01, 7.523790e-03, 1.480755e-02也就是[0.9999, 0.0075, 0.0148]完全符合预期。同理第一行应该近似[0, -1, 0]相机 x 是雷达 y 的反方向实际是[0.0075, -0.99997, -0.0006]也对得上。第二行应该近似[0, 0, -1]相机 y 是雷达 z 的反方向实际是[0.0148, 0.0007, -0.99989]依然对得上。每次解析完外参我都会先跑一遍这个三行检查。如果三行的符号或者量级不符合预期那基本可以断定是行优先、列优先搞混了或者 reshape 的形状写错了比事后看图找错快得多。3.2 一条完整的点云到图像变换链把内参和外参串起来从雷达点x_v到图像像素(u, v)的完整链路是这样的x_v (4x1, 雷达齐次坐标) - Tr_velo_cam (4x4) 得到相机坐标系下的点 - R0_rect (4x4) 得到校正后的相机坐标系下的点 - P_rect_00 (3x4) 得到图像齐次坐标 - 除以第三维 得到像素坐标 (u, v)写成矩阵形式就是y P_rect_00 R_rect_00 Tr_velo_cam x_v注意顺序不能换。矩阵乘法不满足交换律R_rect_00和Tr_velo_cam换位置得到的是完全不同的物理含义。我习惯在代码里把这个组合矩阵预先算好命名成velo_to_img避免在循环里反复乘。velo_to_img P_rect_00 R_rect_00 Tr_velo_cam这个组合矩阵是 3x4 的可以直接作用在齐次坐标上。一次性算好还有个额外的好处你可以直观看到矩阵里各列的贡献如果某一列明显异常很容易定位是哪一级出了问题。一个具体的数值例子方便你验证假设雷达坐标系下有一个点(10.0, 0.0, 0.5)也就是前方 10 米、正中央、离地 0.5 米雷达大约在车顶高度地面点在雷达坐标系里的 z 是负的所以 0.5 表示略高于雷达的位置这里只是个示意。经过Tr_velo_cam之后这个点在相机坐标系里应该大约落在(0.0, -0.5, 10.0)附近也就是说它在画面正中央偏上一点点距离 10 米。再经过校正和投影应该落在像素接近图像中心的位置。你可以拿这个做单元测试改代码的时候跑一下能立刻发现回归问题。3.3 IMU/GPS 怎么接进来calib_imu_to_velo.txt提供的是 IMU 到雷达的变换格式和雷达外参一样R 加 T。为什么要单独提供这个因为 KITTI 的 GPS/IMU 数据oxts 文件夹里的位姿都是在 IMU 坐标系下给出的而点云在雷达坐标系下两者朝向虽然一致但原点和安装角度有微小差异。做多帧点云拼接、轨迹对齐、里程计评估的时候这个变换是必须的。用的时候就把两级外参串起来Tr_imu_velo make_transform(imu[R], imu[T]) imu_to_cam R_rect_00 Tr_velo_cam Tr_imu_velo这样 IMU 坐标系下的一个点也能投到图像上。不过说实话日常做检测任务Tr_imu_to_velo用得不多它更多出现在需要融合位姿信息的场景比如构建点云地图、做序列级的轨迹评估。如果你只是跑单帧检测忽略它完全没有问题。实操心得KITTI 的 oxts 数据里还包含姿态角、速度、卫星数量等一大堆字段换算成全局位姿需要一套坐标系约定东北天或者类似这部分跟标定文件的关系是间接的。刚上手的时候别陷进去先把 velo 到图像这条链打通其余等需要了再回来啃。4. 手写一套解析与点云投影代码网上的轮子很多但我强烈建议自己写一遍解析和投影。原因很简单这段代码总共不到一百行但它是你后面所有调试工作的显微镜你不把它握在自己手里出了问题就只能靠猜。下面是我自己反复迭代过的一版结构清晰两套文件格式都能吃。4.1 解析函数一个通用的键值读取器KITTI 的标定文件本质就是冒号分隔的键值对值要么是若干浮点数要么是时间戳这类字符串。所以一个通用的解析器就够了import numpy as np def read_calib_file(path): 读取 KITTI 标定文件返回 {键: numpy 数组或字符串} data {} with open(path, r) as f: for line in f: line line.strip() if not line or : not in line: continue key, value line.split(:, 1) key key.strip() value value.strip() if not value: data[key] None continue try: data[key] np.array([float(x) for x in value.split()]) except ValueError: data[key] value return data这段代码有几个设计取舍值得说。第一用split(:, 1)而不是split(:)因为有些字段值里可能包含冒号比如时间戳限制只切一刀最安全。第二先尝试转浮点失败就保留原字符串这样同一个函数既能读数值字段也能读calib_time。第三遇到空行直接跳过KITTI 文件末尾经常多一个空行不处理会让某些严格的解析逻辑报错。这套写法我用了好几年从 KITTI 一直用到后来自己采集的数据只要格式是键: 值都能直接拿来用。4.2 组装变换矩阵与投影计算解析完之后把需要的字段组装成矩阵这里每一步我都加了形状断言宁可启动时报错也不要跑出错误结果def build_velo_to_img(calib_dir): cam read_calib_file(f{calib_dir}/calib_cam_to_cam.txt) velo read_calib_file(f{calib_dir}/calib_velo_to_cam.txt) P_rect_00 cam[P_rect_00].reshape(3, 4) R_rect_00 np.eye(4) R_rect_00[:3, :3] cam[R_rect_00].reshape(3, 3) Tr_velo_cam np.eye(4) Tr_velo_cam[:3, :3] velo[R].reshape(3, 3) Tr_velo_cam[:3, 3] velo[T].reshape(3) # 自检相机 z 轴应对应雷达 x 轴 assert Tr_velo_cam[2, 0] 0.9, 外参解析异常检查行优先顺序 # 自检相机 x 轴应对应雷达 y 轴的反方向 assert Tr_velo_cam[0, 1] -0.9, 外参解析异常检查 reshape 形状 return P_rect_00 R_rect_00 Tr_velo_cam投影函数本身很短但有效率开关和边界判断def project_points(pts_velo, velo_to_img, img_w1242, img_h375): pts_velo: (N, 4) 含强度返回像素坐标、相机系深度、有效掩码 pts np.hstack([pts_velo[:, :3], np.ones((len(pts_velo), 1))]) pts_img (velo_to_img pts.T).T # (N, 3) depth pts_img[:, 2] valid depth 1e-3 # 剔除在相机后方的点 uv np.zeros((len(pts_velo), 2)) uv[valid] pts_img[valid, :2] / depth[valid, None] inside (valid (uv[:, 0] 0) (uv[:, 0] img_w) (uv[:, 1] 0) (uv[:, 1] img_h)) return uv, depth, inside几个参数选择背后的理由值得展开。depth 1e-3这个阈值不能省因为雷达是 360 度扫描的有相当一部分点落在相机后方这些点的z是负的除完之后会得到一个镜像的假像素看起来还挺像那么回事非常容易骗过肉眼检查。边界判断用半开区间[0, W)避免恰好落在W上的点越界访问数组。相机系深度我用的是pts_img[:, 2]也就是相机坐标系下的 z 值物理含义是沿光轴的距离。有人喜欢用雷达坐标系下的距离或者欧氏斜距这两种在深度补全任务里会带来系统性偏差——KITTI 深度补全的 GT 是按相机系 z 给的标准你用了斜距训练出来的网络在图像边缘区域就会偏。这个细节不注意模型精度差个几个百分点你都找不到原因。4.3 可视化验证把点云画到图像上代码写完不验证等于没写。我习惯用点云按深度着色后叠加到图像上一眼就能看出标定对不对import matplotlib.pyplot as plt import matplotlib.cm as cm def visualize(img, uv, depth, inside): order np.argsort(-depth[inside]) # 远的先画近的覆盖远的 u uv[inside][order, 0] v uv[inside][order, 1] d depth[inside][order] norm (d - d.min()) / (d.max() - d.min() 1e-6) colors cm.jet(1.0 - norm) # 近处偏红远处偏蓝 fig, ax plt.subplots(figsize(12, 4)) ax.imshow(img) ax.scatter(u, v, ccolors, s1.2, linewidths0) ax.set_xlim(0, img.shape[1]) ax.set_ylim(img.shape[0], 0) plt.tight_layout() plt.savefig(overlay.png, dpi150)排序那一步不是可有可无的。点云投影到图像上远处的点可能和近处的点落在同一个像素附近如果按原始顺序画远处的点会盖住近处的点视觉上会觉得深度关系反了进而误判标定出错。按深度从远到近画之后近处的物体自然压在前面画面层次就对了。一个判断标定是否正确的经验标准竖直物体电线杆、行人、车辆侧面的轮廓应该保持竖直。如果投影出来的点云在竖直方向上明显倾斜或者随图像横向位置发生系统性偏移那几乎可以肯定是R_rect_00用错了位置或者外参的转置搞反了。另外道路平面上的点在图像里应该呈现一个均匀的水平渐变如果出现明显的分块错位说明某一级矩阵的维度对不上。5. 标定精度验证与常见问题排查标定文件是死的但你的代码是活的。同一份文件不同的加载方式可能得到完全不同的结果。这一节整理我在实际项目里遇到过的典型问题和排查手法。5.1 重投影误差怎么量化别只靠肉眼看图肉眼看叠加图能发现大问题但发现不了小偏差。想量化精度最直接的办法是做重投影自检拿一组已知在图像上有对应关系的点用标定矩阵算一遍投影比较算出来的像素和实际像素的差距。最常用的做法是找图像里的强角点比如棋盘格、建筑物的直角边手动或半自动标出它们在图像上的位置再在点云里找对应的三维点投影之后算像素距离。KITTI 官方标定文件的精度大概在 1 到 2 个像素量级如果你的计算误差普遍超过 5 个像素那基本可以确定是代码问题而不是文件问题。另一个更省事的自检方式是利用立体相机的基线。T_01、T_02、T_03给出了相机之间的平移量你可以用左右相机的图像做一次立体匹配把视差换算成深度再和雷达深度对比。如果两套深度在中距离10 到 30 米上整体一致说明整条链路是通的。这种方法不需要人工标注适合快速回归测试。我一般会把重投影误差做成一个简单的统计报表随机抽 50 帧每帧随机抽 200 个落在图像内的点记录它们的像素残差分布。如果某一天更新了代码之后残差的均值突然涨了一倍那说明改动引入了 bug比逐帧看图高效得多。5.2 常见问题速查表下面这张表是我这些年攒下来的基本覆盖了 90% 的投影不对场景现象大概率原因排查手段点云整体偏移一个固定角度外参 R 转置了检查 R 的三行符号是否符合前/左/上到右/下/前的映射点云在图像里上下颠倒最后一维符号错或图像 y 轴当成向上检查投影后是否u x/z, v y/z别写成-y/z只有一小撮点落在图内用了K而不是P_rect打印矩阵尺寸P是 3x4、K是 3x3点云位置对但深度标尺不对用了斜距而不是相机系 z检查深度取值用的是第三维还是欧氏范数边缘点整体外扩或内缩忘了校正或重复校正确认图像是校正后的版本矩阵链只做一次R_rect换帧号之后结果全变用了同一个标定文件跨日期KITTI 每天一个标定日期目录必须一一对应越靠图像边缘偏差越大残留畸变没处理干净检查是否混用了未校正图像和P_rect解析报 KeyError两套文件格式混用P0和P_rect_00不共存按目录判断格式注意KITTI 的标定文件是按日期分组的2011_09_26、2011_09_28、2011_09_29等等每天的相机安装状态略有差异标定参数完全不同。用错日期的标定文件点云会整体平移几十厘米看起来有点不对但又说不清哪里不对。这是最隐蔽的一类错误我在这个坑里待过整整一个下午。5.3 几个我在实际项目里踩过的坑第一个坑是行优先还是列优先。KITTI 文件里所有矩阵都是按行展平的但如果你用某些 C 库直接memcpy到一个矩阵对象里那就要注意库默认是行主序还是列主序。我遇到过一次Python 侧算得好好的挪到 C 侧之后结果全乱最后发现是 Eigen 默认列主序读进来直接就是转置后的矩阵。解决办法很简单读进来之后立刻打印矩阵和 Python 侧对一下数字一目了然。第二个坑是图像预处理改变了分辨率。很多检测框架在数据加载时会做 resize比如把 1242x375 缩放到 1280x384。这时候你的投影边界判断还是按 1242x375 来的投影出来的点自然对不上。解决办法是把缩放比例一起应用在像素坐标上或者干脆在投影之后再 resize 图像。我建议后者先投影再缩放逻辑最清晰。第三个坑是多相机之间的变换方向。calib_cam_to_cam.txt里给的是各相机相对于 0 号相机的旋转和平移但从谁到谁这个方向很容易搞反。如果你做多相机融合比如把 2 号相机的框投到 0 号相机上中间的变换顺序错一步结果就会偏到画面外面。我的应对方式是用一个明显在 2 号相机画面右前方的点做测试看它投影到 0 号相机之后应该往左移还是往右移用几何直觉验证方向。第四个坑是点云反射强度被当成坐标。KITTI 的 velodyne 点云是四列第四列是强度。如果你直接把整个 (N,4) 矩阵拿去乘 3x4 的投影矩阵要么报错要么静默算错。写投影函数时永远先切[:, :3]这是最基本也最容易忘的一步。6. 标定文件在下游任务里的用法差异标定文件不是拿来欣赏的它最终要嵌到具体任务里。不同任务对它的依赖程度和使用方式差别很大这一节说说我观察到的一些规律。6.1 三维目标检测三维框解算离不开它做三维检测时标定文件主要用在两个地方。第一是数据增强比如全局旋转、全局缩放这些操作必须在统一坐标系下做不能只改点云不改图像。第二是损失函数计算尤其是把三维框投影到图像上算二维一致性损失时。KITTI 的 label_2 里三维框的location是在相机坐标系下给出的底面中心rotation_y是绕相机 y 轴的偏航角。注意这是相机 0 坐标系不是雷达坐标系也不是 2 号彩色相机的坐标系。而image_2是 2 号相机的图像所以你把三维框投到图像上时中间还要经过一次相机之间的变换。这一步在很多开源实现里是被隐式处理掉的如果你自己写不处理就会偏。我一般会在数据加载阶段做一次统一把标注全部转换到雷达坐标系或者相机 0 校正坐标系下之后的增强和损失计算都在这个统一坐标系里完成。这样标定文件只在加载时用一次后面就不用反复查了。这个设计的好处是即使标定文件读错了问题也会在加载阶段立刻暴露而不是训练到一半才发现损失降不下去。6.2 深度补全、多帧拼接与点云分割深度补全任务对标定的依赖最重。它的输入是稀疏的激光点投影到图像后形成的稀疏深度图输出是稠密深度图。整个流程的第一步就是投影标定错了后面全废。而且这个任务对精度非常敏感因为网络学的是从稀疏到稠密的映射关系如果投影本身偏差了几个像素网络就会把这种偏差当作规律学进去在验证集上表现出的误差会一直存在。多帧拼接则是另一个极端它对时间同步和位姿精度的要求超过了对相机标定的要求。这里calib_imu_to_velo.txt就派上用场了因为 oxts 里的位姿是在 IMU 坐标系下的你不动过 IMU 到雷达的变换根本没法和点云对齐。做这类任务的同行常说一句话标定文件在单帧任务里是配角在序列任务里是主角我觉得挺贴切。点云分割相对宽松一些因为分割任务主要靠几何特征对绝对位置的精度要求没那么高。但如果你想做基于图像引导的点云分割用图像特征去增强点的表示那相机和雷达的对齐精度就变得关键了标注一个点的类别时如果错位几个像素取到的图像特征可能来自旁边的物体效果反而变差。6.3 和其他数据集标定格式的横向对照用过几个数据集之后你会发现KITTI 的标定文件格式其实挺老派的纯文本、单文件、字段名用下划线分隔。后来的数据集有的走 JSON有的走 YAML还有的干脆把标定信息塞进数据库或者二进制包里。格式变来变去但内核是一模一样的内参矩阵、外参变换、畸变参数、图像尺寸四样东西跑不出这个范围。如果你打算把自己采集的数据整理成类似 KITTI 的格式我的建议是不要只模仿文件格式更要模仿它的自描述性。每个字段名都要能说清它是什么、维度多少、属于哪个传感器、朝哪个方向。KITTI 那些看起来啰嗦的下划线命名P_rect_02、T_velo_cam其实帮了大忙看一眼就知道含义。我见过自采数据集用matrix1、matrix2命名标定参数的换个人接手就得重新反推一遍这纯粹是给自己挖坑。另外不管你的数据从哪来我建议都写一套统一的投影自检脚本给定标定文件和一组点输出投影结果和叠加图然后固定跑几个典型帧。这套脚本不会提升模型精度但它能在你每次改动数据管线时第一时间告诉你有没有把标定搞坏。我在自己的多个项目里都保留了这么一个小工具改完代码先跑它跑过了再上训练省下来的调试时间远比写它的时间长。最后分享一个小习惯拿到任何一份新数据集的标定文件我都会先做三件事——打印所有矩阵的尺寸和范数、检查旋转矩阵的正交性R R.T应该接近单位矩阵行列式接近 1、画一张点云投影叠加图。这三步走完这份标定文件能不能直接用我心里就有数了。很多看起来很吓人的标定问题其实在这三步里就已经暴露出来了。
KITTI标定文件解析与点云投影实战指南
1. 先搞清楚 KITTI 标定文件到底在标什么KITTI 这套数据在自动驾驶圈子里被翻来覆去用了十来年很多人第一次接触它注意力都放在 label_2 里的三维框和 velodyne_points 里的点云上标定文件反而是最后才去翻的。我自己的经历也是这样早期做点云上色的小工具把点云直接往图像上怼结果画面里只孤零零飘着几个点大部分点全跑到画布外面去了折腾了大半天才发现是把坐标系方向搞反了。后来才明白标定文件其实是整个 KITTI 数据集的地基标注、点云、图像之间的所有对应关系都靠它撑着地基没打对上面盖什么都歪。说得直白点KITTI 的标定文件干的事情就一件告诉你相机、激光雷达、惯导这三套设备各自的坐标系是什么朝向以及它们之间怎么互相换算。它不负责告诉你场景里有什么物体也不负责告诉你画面像素对应哪个物理点它只负责提供翻译规则。你拿到一个激光雷达点想知道它投到图像上是哪个像素反过来你看到图像上一个像素想估它离车多远——这些都要靠标定文件里那几十行科学计数法算出来。适合谁来啃这块内容做三维目标检测的、做点云与图像融合的、做深度补全的、做多传感器联合标定的以及想拿自己车上采集的数据复现 KITTI 流程的这些人绕不过去。哪怕你只是想把 KITTI 当作练手数据跑通一个 YOLO 或者 PointPillars标定文件的解析代码也是你数据加载器里最早要写对的那部分。它解决的核心痛点是可复现。同一段数据你算出来的投影结果和别人算出来的必须一致否则所有基于这个数据集的论文结果都没法比较。KITTI 把内参、外参、畸变、校正矩阵全部以纯文本形式随数据一起发布谁都能独立复核这一点比不少自采数据集要省心得多——很多自采数据集标定参数藏在某个二进制文件或者某个内部工具里换个人就复现不出来。下面我按照自己踩坑的顺序从文件组织讲起一路讲到能跑通投影、能验证精度、能挂到下游任务上。1.1 三套坐标系以及它们之间的翻译关系要读懂标定文件先得把 KITTI 用到的三套坐标系刻进脑子里否则后面每一个矩阵你都会看得云里雾里。相机坐标系的约定是x 轴指向图像右侧y 轴指向图像下方z 轴沿着光轴指向画面深处。这是计算机视觉领域最常见的约定你写任何投影代码时的默认假设基本都是它。Velodyne 激光雷达坐标系的约定是x 轴指向车辆前方y 轴指向车辆左侧z 轴垂直于地面向上。注意这里和相机完全不同——相机是右、下、前雷达是前、左、上。IMU/GPS 坐标系和雷达坐标系朝向一致也是前、左、上区别只在原点位置和安装位置不同两者之间靠一个固定的刚体变换联系。把这三套约定摆在一起看你会发现相机和雷达之间至少差了两个轴方向的翻转相机的 x 等于雷达 y 的反方向相机的 y 等于雷达 z 的反方向相机的 z 等于雷达 x 的正方向。这个关系不是猜的你可以直接拿calib_velo_to_cam.txt里的旋转矩阵去验证后面我会演示怎么用这个方法做交叉检查——这是我最常用的一个自查手段比反复读文档可靠得多。生活里可以打个比方三个人分别用东南西北前后左右上下左右来描述同一个房间里的东西标定文件就是那本三方对照词典。词典写错了或者你翻词典的时候看串行了描述就会对不上。KITTI 的标定文件本质就是这么一本词典只不过用矩阵的形式写的。1.2 同一个数据集两套标定文件格式别混用这是很多人第一次上手会困惑的地方KITTI 网站上你下载的数据包里标定参数其实是两套不同的组织形式用途不一样。第一套是原始多文件格式出现在data_object_calib或者 raw data 的日期目录里包含三个独立文件calib_cam_to_cam.txt、calib_velo_to_cam.txt、calib_imu_to_velo.txt。每个文件里字段很多除了外参还有内参、畸变系数、校正矩阵、图像尺寸等等信息最全做标定研究和需要原始参数的场景必须用它。第二套是合并单文件格式出现在目标检测 benchmark 的training/calib/目录下文件名就是帧号比如000000.txt。这个文件被大幅简化了只剩七行P0、P1、P2、P3四个投影矩阵R0_rect校正矩阵Tr_velo_to_cam雷达外参Tr_imu_to_velo惯导外参。内参K、畸变D、原始图像尺寸S全都不在里面了因为它们已经被烘焙进P0到P3里。我把两者的对应关系整理成一张表方便你对照字段原始多文件格式合并单文件格式说明投影矩阵P_rect_00~P_rect_03P0~P3数值完全一致直接搬过来校正旋转R_rect_00R0_rect一致都是 3x3 展平成 9 个数雷达外参calib_velo_to_cam.txt的R、TTr_velo_to_cam合并版把 R 和 T 拼成了一个 3x4惯导外参calib_imu_to_velo.txt的R、TTr_imu_to_velo同理拼成了 3x4内参K_00~K_03无合并版里被吸收掉了畸变D_00~D_03无合并且应用在图像上之后就没必要再存图像尺寸S_00~S_03、S_rect_00无校正后统一为 1242x375基线T_01、T_02、T_03等无做双目深度需要它注意同一个序列里这两套文件的数值是对得上的但字段名和维度不同。如果你写了一个加载器只认P_rect_00这种带下划线的写法换到training/calib上就会直接报 KeyError。我建议解析函数用先按冒号切、再按需取键的通用写法两套格式都能吃。另外还有个小细节值得提一句training/calib/000000.txt这类文件的键名在不同版本的数据包里偶尔有细微差别有的写R0_rect有的写R0_rect后面直接跟 9 个数中间没有多余空格。写解析器时用line.split(:, 1)切一刀最保险别用固定位置切片。2. 逐字段拆解 calib_cam_to_cam.txt这个文件是四个相机0 号左灰度、1 号右灰度、2 号左彩色、3 号右彩色的完整标定集合字段名基本遵循量_相机编号的命名规则。下面挑几个最容易出错的字段逐个说。2.1 P_rect_0x 和 K_0x 的焦距为什么对不上先看一组真实的数值。K_00是 3x3 内参矩阵展平成 9 个数P_rect_00是 3x4 投影矩阵展平成 12 个数。很多人第一反应是这俩里面都装了焦距应该能互相推出来然后就会卡住。以 KITTI 官方给出的calib_cam_to_cam.txt为例K_00里的焦距分量大约是 984.24主点大约在 (690.0, 233.2)而P_rect_00里的焦距分量大约是 721.54主点大约在 (609.6, 172.9)。如果按图像宽度做等比换算原始图像宽 1392、校正后图像宽 1242比例是 0.892984.24 乘上去应该得到 878 左右和 721.54 差了十万八千里。这说明什么说明校正过程不只是把图像裁剪、缩放一下就完事它还包含了去畸变带来的视场重映射两个焦距之间不存在简单的一一对应。所以我的建议很明确不要试图从 K 推导 P_rect也不要拿 K 去替换 P_rect。这两个量服务于不同的图像版本K和D面向的是原始未校正图像P_rect面向的已经是校正后图像。你做点云投影时用的永远是P_rect因为 KITTI 官方发布的image_2就是校正后的图。要是你不小心把K塞进投影公式画出来的点会整体偏移几十个像素而且偏移量还随位置变化非常难查。P_rect的后三列里第四列全是零这也很正常——它描述的是两个校正后共面相机之间的投影关系平移量已经在校正过程中归到无穷远了。真正携带平移信息的是T_01、T_02、T_03这些基线分量。提示如果你只是做单目投影只需要P_rect_02和R_rect_00加上雷达外参四个投影矩阵里的另外三个其实用不到。别被一堆字段吓到先把最常用的那条链跑通再说。2.2 R_rect_00 和 S_rect_00被最多人忽略的校正环节R_rect_00是一个 3x3 的旋转矩阵作用是把 0 号相机也就是整个相机组的参考相机的坐标系旋转到一个共面对齐的姿态上让四个相机的成像平面互相平行。为什么要做这一步因为物理安装时四个相机不可能装得严丝合缝光轴之间总有零点几度到几度的夹角。如果直接拿原始图像做双目匹配或者多目融合极线是斜的搜索起来很麻烦。校正把光轴掰平行之后极线就变成了水平线匹配只需要在同一行里找效率高得多。我实际用的时候习惯把它扩展成 4x4方便和外参矩阵连乘import numpy as np R_rect np.eye(4) R_rect[:3, :3] cam[R_rect_00].reshape(3, 3)S_rect_00则是校正后图像的尺寸格式是宽 高KITTI 上普遍是 1242x375。这个值看着不起眼实际有两个用处一是做投影有效性判断时用来确定边界二是当你想把不同相机的图像拼在一起显示时必须知道各自的分辨率。我见过有人把S_00原始尺寸 1392x512当成校正尺寸来用结果裁剪出来的 ROI 全是错位的非常隐蔽。顺便说一句S_rect_00和S_rect_01、S_rect_02、S_rect_03是同一个值因为它们已经被校正到同一个平面上了。如果你发现它们不相等那大概率是文件被改过或者你读错了字段。2.3 D_0x 畸变参数在投影流程里到底还用不用这是我在技术群里被问得最多的一个问题KITTI 的投影流程里畸变系数D_00到底要不要参与计算答案取决于你的图像版本。KITTI 官方发布的image_0到image_3都是已经去畸变并校正过的图像配套的P_rect_0x也是针对这些校正图像的。所以标准的点云投影流程里D根本不出现——它不是被忽略了而是它的效果已经被预支到图像和P_rect里了。只有在一种情况下你需要D你要从零开始处理原始的、未校正的图像。比如你自己采集的数据想复刻 KITTI 的流程或者你想研究畸变校正本身对精度的影响。这时候流程会变成先用K和D去畸变再用R_rect做共面对齐最后用去畸变后的内参投影步骤比直接用P_rect多不少中间的符号和顺序都很容易搞错。我自己的经验是除非你有明确的理由否则一律走P_rect路线。走得人多了坑都被踩平了开源实现也多遇到问题搜一下基本都有答案。3. 外参链路velo_to_cam 与 imu_to_velo内参解决的是相机内部怎么成像外参解决的是不同传感器之间怎么换算。KITTI 的外参链路是三级串联的IMU - Velodyne - Camera每一级都是一个刚体变换形式都是旋转矩阵 R 加平移向量 T。3.1 R 和 T 的存储形态以及最常见的解析错误calib_velo_to_cam.txt里长这样以官方数据为例calib_time: 15-Mar-2012 11:37:16 R: 7.533745e-03 -9.999714e-01 -6.166020e-04 1.480249e-02 7.280733e-04 -9.998902e-01 9.998621e-01 7.523790e-03 1.480755e-02 T: -4.069766e-03 -7.631618e-02 -2.717806e-01R 有 9 个数T 有 3 个数都是按行优先排成一行。你要把它们分别 reshape 成 3x3 和 3x1而不是 3x1 和 3x1 那种。我见过有人把 R 当成 9 个独立的旋转角去用结果当然是完全跑偏。拼成齐次矩阵的写法def make_transform(R, T): Tr np.eye(4) Tr[:3, :3] R.reshape(3, 3) Tr[:3, 3] T.reshape(3) return Tr Tr_velo_cam make_transform(velo[R], velo[T])这里有个非常实用的自检技巧。前面说过相机的 z 轴前向对应雷达的 x 轴前向那么把 R 按行看第三行应该近似是[1, 0, 0]因为雷达 x 轴几乎原封不动地变成了相机的 z 轴。上面那组数据里第三行是9.998621e-01, 7.523790e-03, 1.480755e-02也就是[0.9999, 0.0075, 0.0148]完全符合预期。同理第一行应该近似[0, -1, 0]相机 x 是雷达 y 的反方向实际是[0.0075, -0.99997, -0.0006]也对得上。第二行应该近似[0, 0, -1]相机 y 是雷达 z 的反方向实际是[0.0148, 0.0007, -0.99989]依然对得上。每次解析完外参我都会先跑一遍这个三行检查。如果三行的符号或者量级不符合预期那基本可以断定是行优先、列优先搞混了或者 reshape 的形状写错了比事后看图找错快得多。3.2 一条完整的点云到图像变换链把内参和外参串起来从雷达点x_v到图像像素(u, v)的完整链路是这样的x_v (4x1, 雷达齐次坐标) - Tr_velo_cam (4x4) 得到相机坐标系下的点 - R0_rect (4x4) 得到校正后的相机坐标系下的点 - P_rect_00 (3x4) 得到图像齐次坐标 - 除以第三维 得到像素坐标 (u, v)写成矩阵形式就是y P_rect_00 R_rect_00 Tr_velo_cam x_v注意顺序不能换。矩阵乘法不满足交换律R_rect_00和Tr_velo_cam换位置得到的是完全不同的物理含义。我习惯在代码里把这个组合矩阵预先算好命名成velo_to_img避免在循环里反复乘。velo_to_img P_rect_00 R_rect_00 Tr_velo_cam这个组合矩阵是 3x4 的可以直接作用在齐次坐标上。一次性算好还有个额外的好处你可以直观看到矩阵里各列的贡献如果某一列明显异常很容易定位是哪一级出了问题。一个具体的数值例子方便你验证假设雷达坐标系下有一个点(10.0, 0.0, 0.5)也就是前方 10 米、正中央、离地 0.5 米雷达大约在车顶高度地面点在雷达坐标系里的 z 是负的所以 0.5 表示略高于雷达的位置这里只是个示意。经过Tr_velo_cam之后这个点在相机坐标系里应该大约落在(0.0, -0.5, 10.0)附近也就是说它在画面正中央偏上一点点距离 10 米。再经过校正和投影应该落在像素接近图像中心的位置。你可以拿这个做单元测试改代码的时候跑一下能立刻发现回归问题。3.3 IMU/GPS 怎么接进来calib_imu_to_velo.txt提供的是 IMU 到雷达的变换格式和雷达外参一样R 加 T。为什么要单独提供这个因为 KITTI 的 GPS/IMU 数据oxts 文件夹里的位姿都是在 IMU 坐标系下给出的而点云在雷达坐标系下两者朝向虽然一致但原点和安装角度有微小差异。做多帧点云拼接、轨迹对齐、里程计评估的时候这个变换是必须的。用的时候就把两级外参串起来Tr_imu_velo make_transform(imu[R], imu[T]) imu_to_cam R_rect_00 Tr_velo_cam Tr_imu_velo这样 IMU 坐标系下的一个点也能投到图像上。不过说实话日常做检测任务Tr_imu_to_velo用得不多它更多出现在需要融合位姿信息的场景比如构建点云地图、做序列级的轨迹评估。如果你只是跑单帧检测忽略它完全没有问题。实操心得KITTI 的 oxts 数据里还包含姿态角、速度、卫星数量等一大堆字段换算成全局位姿需要一套坐标系约定东北天或者类似这部分跟标定文件的关系是间接的。刚上手的时候别陷进去先把 velo 到图像这条链打通其余等需要了再回来啃。4. 手写一套解析与点云投影代码网上的轮子很多但我强烈建议自己写一遍解析和投影。原因很简单这段代码总共不到一百行但它是你后面所有调试工作的显微镜你不把它握在自己手里出了问题就只能靠猜。下面是我自己反复迭代过的一版结构清晰两套文件格式都能吃。4.1 解析函数一个通用的键值读取器KITTI 的标定文件本质就是冒号分隔的键值对值要么是若干浮点数要么是时间戳这类字符串。所以一个通用的解析器就够了import numpy as np def read_calib_file(path): 读取 KITTI 标定文件返回 {键: numpy 数组或字符串} data {} with open(path, r) as f: for line in f: line line.strip() if not line or : not in line: continue key, value line.split(:, 1) key key.strip() value value.strip() if not value: data[key] None continue try: data[key] np.array([float(x) for x in value.split()]) except ValueError: data[key] value return data这段代码有几个设计取舍值得说。第一用split(:, 1)而不是split(:)因为有些字段值里可能包含冒号比如时间戳限制只切一刀最安全。第二先尝试转浮点失败就保留原字符串这样同一个函数既能读数值字段也能读calib_time。第三遇到空行直接跳过KITTI 文件末尾经常多一个空行不处理会让某些严格的解析逻辑报错。这套写法我用了好几年从 KITTI 一直用到后来自己采集的数据只要格式是键: 值都能直接拿来用。4.2 组装变换矩阵与投影计算解析完之后把需要的字段组装成矩阵这里每一步我都加了形状断言宁可启动时报错也不要跑出错误结果def build_velo_to_img(calib_dir): cam read_calib_file(f{calib_dir}/calib_cam_to_cam.txt) velo read_calib_file(f{calib_dir}/calib_velo_to_cam.txt) P_rect_00 cam[P_rect_00].reshape(3, 4) R_rect_00 np.eye(4) R_rect_00[:3, :3] cam[R_rect_00].reshape(3, 3) Tr_velo_cam np.eye(4) Tr_velo_cam[:3, :3] velo[R].reshape(3, 3) Tr_velo_cam[:3, 3] velo[T].reshape(3) # 自检相机 z 轴应对应雷达 x 轴 assert Tr_velo_cam[2, 0] 0.9, 外参解析异常检查行优先顺序 # 自检相机 x 轴应对应雷达 y 轴的反方向 assert Tr_velo_cam[0, 1] -0.9, 外参解析异常检查 reshape 形状 return P_rect_00 R_rect_00 Tr_velo_cam投影函数本身很短但有效率开关和边界判断def project_points(pts_velo, velo_to_img, img_w1242, img_h375): pts_velo: (N, 4) 含强度返回像素坐标、相机系深度、有效掩码 pts np.hstack([pts_velo[:, :3], np.ones((len(pts_velo), 1))]) pts_img (velo_to_img pts.T).T # (N, 3) depth pts_img[:, 2] valid depth 1e-3 # 剔除在相机后方的点 uv np.zeros((len(pts_velo), 2)) uv[valid] pts_img[valid, :2] / depth[valid, None] inside (valid (uv[:, 0] 0) (uv[:, 0] img_w) (uv[:, 1] 0) (uv[:, 1] img_h)) return uv, depth, inside几个参数选择背后的理由值得展开。depth 1e-3这个阈值不能省因为雷达是 360 度扫描的有相当一部分点落在相机后方这些点的z是负的除完之后会得到一个镜像的假像素看起来还挺像那么回事非常容易骗过肉眼检查。边界判断用半开区间[0, W)避免恰好落在W上的点越界访问数组。相机系深度我用的是pts_img[:, 2]也就是相机坐标系下的 z 值物理含义是沿光轴的距离。有人喜欢用雷达坐标系下的距离或者欧氏斜距这两种在深度补全任务里会带来系统性偏差——KITTI 深度补全的 GT 是按相机系 z 给的标准你用了斜距训练出来的网络在图像边缘区域就会偏。这个细节不注意模型精度差个几个百分点你都找不到原因。4.3 可视化验证把点云画到图像上代码写完不验证等于没写。我习惯用点云按深度着色后叠加到图像上一眼就能看出标定对不对import matplotlib.pyplot as plt import matplotlib.cm as cm def visualize(img, uv, depth, inside): order np.argsort(-depth[inside]) # 远的先画近的覆盖远的 u uv[inside][order, 0] v uv[inside][order, 1] d depth[inside][order] norm (d - d.min()) / (d.max() - d.min() 1e-6) colors cm.jet(1.0 - norm) # 近处偏红远处偏蓝 fig, ax plt.subplots(figsize(12, 4)) ax.imshow(img) ax.scatter(u, v, ccolors, s1.2, linewidths0) ax.set_xlim(0, img.shape[1]) ax.set_ylim(img.shape[0], 0) plt.tight_layout() plt.savefig(overlay.png, dpi150)排序那一步不是可有可无的。点云投影到图像上远处的点可能和近处的点落在同一个像素附近如果按原始顺序画远处的点会盖住近处的点视觉上会觉得深度关系反了进而误判标定出错。按深度从远到近画之后近处的物体自然压在前面画面层次就对了。一个判断标定是否正确的经验标准竖直物体电线杆、行人、车辆侧面的轮廓应该保持竖直。如果投影出来的点云在竖直方向上明显倾斜或者随图像横向位置发生系统性偏移那几乎可以肯定是R_rect_00用错了位置或者外参的转置搞反了。另外道路平面上的点在图像里应该呈现一个均匀的水平渐变如果出现明显的分块错位说明某一级矩阵的维度对不上。5. 标定精度验证与常见问题排查标定文件是死的但你的代码是活的。同一份文件不同的加载方式可能得到完全不同的结果。这一节整理我在实际项目里遇到过的典型问题和排查手法。5.1 重投影误差怎么量化别只靠肉眼看图肉眼看叠加图能发现大问题但发现不了小偏差。想量化精度最直接的办法是做重投影自检拿一组已知在图像上有对应关系的点用标定矩阵算一遍投影比较算出来的像素和实际像素的差距。最常用的做法是找图像里的强角点比如棋盘格、建筑物的直角边手动或半自动标出它们在图像上的位置再在点云里找对应的三维点投影之后算像素距离。KITTI 官方标定文件的精度大概在 1 到 2 个像素量级如果你的计算误差普遍超过 5 个像素那基本可以确定是代码问题而不是文件问题。另一个更省事的自检方式是利用立体相机的基线。T_01、T_02、T_03给出了相机之间的平移量你可以用左右相机的图像做一次立体匹配把视差换算成深度再和雷达深度对比。如果两套深度在中距离10 到 30 米上整体一致说明整条链路是通的。这种方法不需要人工标注适合快速回归测试。我一般会把重投影误差做成一个简单的统计报表随机抽 50 帧每帧随机抽 200 个落在图像内的点记录它们的像素残差分布。如果某一天更新了代码之后残差的均值突然涨了一倍那说明改动引入了 bug比逐帧看图高效得多。5.2 常见问题速查表下面这张表是我这些年攒下来的基本覆盖了 90% 的投影不对场景现象大概率原因排查手段点云整体偏移一个固定角度外参 R 转置了检查 R 的三行符号是否符合前/左/上到右/下/前的映射点云在图像里上下颠倒最后一维符号错或图像 y 轴当成向上检查投影后是否u x/z, v y/z别写成-y/z只有一小撮点落在图内用了K而不是P_rect打印矩阵尺寸P是 3x4、K是 3x3点云位置对但深度标尺不对用了斜距而不是相机系 z检查深度取值用的是第三维还是欧氏范数边缘点整体外扩或内缩忘了校正或重复校正确认图像是校正后的版本矩阵链只做一次R_rect换帧号之后结果全变用了同一个标定文件跨日期KITTI 每天一个标定日期目录必须一一对应越靠图像边缘偏差越大残留畸变没处理干净检查是否混用了未校正图像和P_rect解析报 KeyError两套文件格式混用P0和P_rect_00不共存按目录判断格式注意KITTI 的标定文件是按日期分组的2011_09_26、2011_09_28、2011_09_29等等每天的相机安装状态略有差异标定参数完全不同。用错日期的标定文件点云会整体平移几十厘米看起来有点不对但又说不清哪里不对。这是最隐蔽的一类错误我在这个坑里待过整整一个下午。5.3 几个我在实际项目里踩过的坑第一个坑是行优先还是列优先。KITTI 文件里所有矩阵都是按行展平的但如果你用某些 C 库直接memcpy到一个矩阵对象里那就要注意库默认是行主序还是列主序。我遇到过一次Python 侧算得好好的挪到 C 侧之后结果全乱最后发现是 Eigen 默认列主序读进来直接就是转置后的矩阵。解决办法很简单读进来之后立刻打印矩阵和 Python 侧对一下数字一目了然。第二个坑是图像预处理改变了分辨率。很多检测框架在数据加载时会做 resize比如把 1242x375 缩放到 1280x384。这时候你的投影边界判断还是按 1242x375 来的投影出来的点自然对不上。解决办法是把缩放比例一起应用在像素坐标上或者干脆在投影之后再 resize 图像。我建议后者先投影再缩放逻辑最清晰。第三个坑是多相机之间的变换方向。calib_cam_to_cam.txt里给的是各相机相对于 0 号相机的旋转和平移但从谁到谁这个方向很容易搞反。如果你做多相机融合比如把 2 号相机的框投到 0 号相机上中间的变换顺序错一步结果就会偏到画面外面。我的应对方式是用一个明显在 2 号相机画面右前方的点做测试看它投影到 0 号相机之后应该往左移还是往右移用几何直觉验证方向。第四个坑是点云反射强度被当成坐标。KITTI 的 velodyne 点云是四列第四列是强度。如果你直接把整个 (N,4) 矩阵拿去乘 3x4 的投影矩阵要么报错要么静默算错。写投影函数时永远先切[:, :3]这是最基本也最容易忘的一步。6. 标定文件在下游任务里的用法差异标定文件不是拿来欣赏的它最终要嵌到具体任务里。不同任务对它的依赖程度和使用方式差别很大这一节说说我观察到的一些规律。6.1 三维目标检测三维框解算离不开它做三维检测时标定文件主要用在两个地方。第一是数据增强比如全局旋转、全局缩放这些操作必须在统一坐标系下做不能只改点云不改图像。第二是损失函数计算尤其是把三维框投影到图像上算二维一致性损失时。KITTI 的 label_2 里三维框的location是在相机坐标系下给出的底面中心rotation_y是绕相机 y 轴的偏航角。注意这是相机 0 坐标系不是雷达坐标系也不是 2 号彩色相机的坐标系。而image_2是 2 号相机的图像所以你把三维框投到图像上时中间还要经过一次相机之间的变换。这一步在很多开源实现里是被隐式处理掉的如果你自己写不处理就会偏。我一般会在数据加载阶段做一次统一把标注全部转换到雷达坐标系或者相机 0 校正坐标系下之后的增强和损失计算都在这个统一坐标系里完成。这样标定文件只在加载时用一次后面就不用反复查了。这个设计的好处是即使标定文件读错了问题也会在加载阶段立刻暴露而不是训练到一半才发现损失降不下去。6.2 深度补全、多帧拼接与点云分割深度补全任务对标定的依赖最重。它的输入是稀疏的激光点投影到图像后形成的稀疏深度图输出是稠密深度图。整个流程的第一步就是投影标定错了后面全废。而且这个任务对精度非常敏感因为网络学的是从稀疏到稠密的映射关系如果投影本身偏差了几个像素网络就会把这种偏差当作规律学进去在验证集上表现出的误差会一直存在。多帧拼接则是另一个极端它对时间同步和位姿精度的要求超过了对相机标定的要求。这里calib_imu_to_velo.txt就派上用场了因为 oxts 里的位姿是在 IMU 坐标系下的你不动过 IMU 到雷达的变换根本没法和点云对齐。做这类任务的同行常说一句话标定文件在单帧任务里是配角在序列任务里是主角我觉得挺贴切。点云分割相对宽松一些因为分割任务主要靠几何特征对绝对位置的精度要求没那么高。但如果你想做基于图像引导的点云分割用图像特征去增强点的表示那相机和雷达的对齐精度就变得关键了标注一个点的类别时如果错位几个像素取到的图像特征可能来自旁边的物体效果反而变差。6.3 和其他数据集标定格式的横向对照用过几个数据集之后你会发现KITTI 的标定文件格式其实挺老派的纯文本、单文件、字段名用下划线分隔。后来的数据集有的走 JSON有的走 YAML还有的干脆把标定信息塞进数据库或者二进制包里。格式变来变去但内核是一模一样的内参矩阵、外参变换、畸变参数、图像尺寸四样东西跑不出这个范围。如果你打算把自己采集的数据整理成类似 KITTI 的格式我的建议是不要只模仿文件格式更要模仿它的自描述性。每个字段名都要能说清它是什么、维度多少、属于哪个传感器、朝哪个方向。KITTI 那些看起来啰嗦的下划线命名P_rect_02、T_velo_cam其实帮了大忙看一眼就知道含义。我见过自采数据集用matrix1、matrix2命名标定参数的换个人接手就得重新反推一遍这纯粹是给自己挖坑。另外不管你的数据从哪来我建议都写一套统一的投影自检脚本给定标定文件和一组点输出投影结果和叠加图然后固定跑几个典型帧。这套脚本不会提升模型精度但它能在你每次改动数据管线时第一时间告诉你有没有把标定搞坏。我在自己的多个项目里都保留了这么一个小工具改完代码先跑它跑过了再上训练省下来的调试时间远比写它的时间长。最后分享一个小习惯拿到任何一份新数据集的标定文件我都会先做三件事——打印所有矩阵的尺寸和范数、检查旋转矩阵的正交性R R.T应该接近单位矩阵行列式接近 1、画一张点云投影叠加图。这三步走完这份标定文件能不能直接用我心里就有数了。很多看起来很吓人的标定问题其实在这三步里就已经暴露出来了。
