KITTI点云预处理与Complex-YOLO训练数据制作详解-平芜编程栈

1. 项目背景与整体设计思路

做3D点云目标检测，尤其是跑Complex-YOLO这种算得上“老前辈”的方案，第一步往往不是搭网络，而是跟数据死磕到底。这话一点都不夸张，我见过不少新手一上来就急着clone仓库、装依赖，结果模型还没开始训，数据预处理环节就卡了一个星期——要么标定矩阵读错，要么BEV图生成出来全是黑的，要么3D框在图像上飘得不知所踪。这篇博文就是把我在实际训练Complex-YOLO之前做KITTI数据集预处理和标签制作的完整过程记录下来，包含踩过的坑、验证过的代码和可以直接照抄的脚本思路，适合所有想用KITTI数据训练点云检测模型、但又不想在预处理上浪费太多时间的同学。

1.1 Complex-YOLO训练前为什么要做数据预处理

先理清楚一个问题：Complex-YOLO吃进去的输入到底是什么。它不是直接把十几万原始点云丢给神经网络，而是先把三维点云压成鸟瞰图BEV多通道特征图，再把BEV图喂给YOLOv2风格的检测头。网络输出的也不是3D空间里的任意框，而是基于BEV平面的中心坐标、长宽、朝向角和高度信息。

这就引出了预处理的必要性。原始KITTI点云是Velodyne HDL-64E激光雷达采集的，坐标原点在车顶雷达位置，坐标系方向是前x、左y、上z；但KITTI提供的3D标注框坐标却定义在相机坐标系下，x朝右、y朝下、z朝前。两个坐标系如果不对齐，后面所有步骤都会乱套。同时，原始点云是稀疏的、无序的，为了让CNN能稳定处理，必须把点云栅格化到固定分辨率的二维网格上，并在每个网格里编码高度、密度、反射强度等信息。

所以整个预处理的核心目标非常明确：把原始点云和3D框标签，统一变换到一个网路方便学习的BEV表示上，输出一个能直接进训练管线的数据集。这其中牵涉三个关键子问题：

点云怎么读、怎么滤波、怎么变换到BEV平面。
3D标注框怎么解析、怎么投影到BEV平面并生成训练标签。
标定矩阵怎么读、怎么用，保证点云和图像、点云和BEV严格对齐。

链路里的每一步都有对应的验证方法，而不是盲目地走完脚本拉倒。后面我会一一展开。

1.2 KITTI数据集到底长什么样

KITTI数据集的原始文件结构，是每个做自动驾驶感知的人都应该熟悉的。它由几个主要目录组成，我贴一下我实际使用的目录结构：

kitti/ ├── data_object_calib/ │ ├── training/ │ │ ├── 000000.txt │ │ ├── 000001.txt │ │ └── ... │ └── testing/ ├── data_object_image_2/ │ ├── training/ │ │ ├── 000000.png │ │ ├── 000001.png │ │ └── ... │ └── testing/ ├── data_object_label_2/ │ ├── training/ │ │ ├── 000000.txt │ │ ├── 000001.txt │ │ └── ... ├── data_object_velodyne/ │ ├── training/ │ │ ├── 000000.bin │ │ ├── 000001.bin │ │ └── ... │ └── testing/ └── data_object_pose/ └── training/

calib保存的是传感器标定参数，每个序列号对应一个txt文件，文件里包含相机投影矩阵P0-P3、校正旋转矩阵R0_rect、雷达到相机的平移旋转矩阵Tr_velo_to_cam等关键矩阵。image_2是左侧彩色相机拍摄的图像。label_2是3D检测的标注文件，每个txt包含当前帧所有目标的类别、截断、遮挡、2D框、3D尺寸、3D中心位置和朝向角。velodyne是激光雷达原始点云，每帧是一个四维float数组，顺序为x、y、z、reflectance。

训练集一共7481帧，测试集7518帧。在训练阶段一般又把训练集进一步划分，我见过比较常见的做法是分出3712帧作为训练子集，3769帧作为验证子集，也可以直接全部参与训练然后另外划分，看具体仓库怎么设计的。Complex-YOLO作者用的划分脚本是公开的，但自己预处理时完全可以根据任务重新划分，只要保证训练和验证不重叠。

1.3 环境准备与工具选择

预处理阶段的环境比训练阶段轻量得多，不需要CUDA和GPU，纯CPU就能完成。我用的是Python 3.8 + NumPy + OpenCV + Matplotlib，工具方面还额外装了pykitti库用来辅助读取标定矩阵，当然你不用它也行，自己解析txt文件无非是多写几行代码的事。

为什么选这几个工具，说下我的判断：

NumPy负责点云数组操作，尤其是np.fromfile直接读取bin文件，比Pandas高效太多，点云这种纯数值数据根本不需要DataFrame。
OpenCV用来做图像读写和基本的绘制操作，验证投影效果时非常顺手。
Matplotlib主要用来可视化BEV图和检查标签分布，虽然在检测项目中很多人不用它做最终可视化，但在预处理阶段排查坐标对齐问题，它比OpenCV更灵活。
pykitti包装了KITTI各种数据文件的读取逻辑，省去自己手写矩阵解析的麻烦，但它对新版Python的兼容性一般，如果遇到问题就自己写，别死磕。

我在处理时用的是自己写的解析脚本而非pykitti，原因很简单：自己对矩阵的每一个数字有掌控感，才敢往下做投影验证。工具永远只是辅助，关键是你知道每一步在算什么。

2. 点云预处理与BEV编码实现

2.1 Velodyne点云数据解析与格式理解

先把最基础的读取搞定。Velodyne点云bin文件的结构非常简单，每四个float32组成一个点，分别代表x、y、z三维坐标和反射强度reflectance。每帧大约有12万个点，但不同帧点数会有浮动，因为激光雷达在扫描过程中会有一些点落在无效区域或被过滤掉。

读取代码一行就行：

import numpy as np def load_velodyne_bin(file_path): points = np.fromfile(file_path, dtype=np.float32).reshape(-1, 4) return points

np.fromfile默认按二进制小端序读取，返回的一维数组size一定是4的倍数，直接reshape(-1, 4)即可。

这里有一个容易忽略的点：KITTI点云单位是米，坐标原点在雷达中心，x轴朝前，y轴朝左，z轴朝上。反射强度范围一般是0到1，但实际有少数点会略超，后面生成density或intensity通道时建议做截断归一化。

预处理之前是否需要滤波？我的建议是：保留全部点，只在BEV栅格化时做范围裁剪。原因有两个，一是滤波器会引入额外参数（比如半径、邻居数量），增加调试成本；二是很多目标点本身就很稀疏，过度滤波会把远距离小目标直接滤没了。真正需要处理的是离群点，但这类问题在网络训练时可以通过数据增强和网络本身的鲁棒性消化掉，预处理阶段不必大动干戈。

2.2 点云坐标变换与齐次变换矩阵解析

点云读进来了，接下来就是坐标变换。这一步是整个预处理里最容易出错的环节，我把它单独拿出来讲。

KITTI点云坐标定义与相机坐标定义不同，需要把点云从雷达坐标系变换到相机坐标系。变换需要的矩阵在标定文件的Tr_velo_to_cam字段中，它是一个3x4矩阵：

Tr_velo_to_cam: 9.999239e-01 9.837760e-03 -7.445048e-03 -4.690e-02 -9.869795e-03 9.999421e-01 -1.799163e-04 -3.639e-04 7.451046e-03 8.786338e-04 9.999718e-01 4.689e-03

这是一个从雷达坐标到相机坐标的刚体变换，包含旋转和平移，齐次形式是4x4：

def get_velo_to_cam_matrix(calib_file_path): with open(calib_file_path, 'r') as f: for line in f.readlines(): if 'Tr_velo_to_cam' in line: parts = line.strip().split(' ') # 去掉 'Tr_velo_to_cam:' 这个 token values = [float(x) for x in parts[1:]] mat = np.array(values).reshape(3, 4) # 转成齐次 4x4 矩阵 Tr = np.eye(4) Tr[:3, :] = mat return Tr

为什么需要齐次矩阵？因为多个坐标变换（雷达到相机、相机到图像）串联时，用4x4齐次矩阵可以直接做矩阵乘法，否则你得一次次手动拼旋转和平移，非常容易出错。

变换逻辑：

def transform_points(points, transform_matrix): # points: Nx4 (x,y,z,reflectance) xyz = points[:, :3] # Nx3 ones = np.ones((xyz.shape[0], 1)) xyz_hom = np.hstack([xyz, ones]) # Nx4 transformed = (transform_matrix @ xyz_hom.T).T # Nx3 return transformed

注意点：经过变换后，点云数据的顺序不变，只是坐标数值变了。反射强度那一列保持不变。变换后的点云是在相机坐标系下的三维点，x朝右、y朝下、z朝前。

这里特别提醒，KITTI的相机坐标系是y朝下的，这个跟一般视觉里y轴朝上的习惯完全相反，很多刚接触的人第一步就栽在这。做BEV图的时候通常还需要一个左乘旋转矩阵，把z轴转到朝上，或者直接在取BEV坐标时注意到维度的对应关系，千万不要想当然。

2.3 点云范围裁剪与栅格化：生成高度、强度、密度通道

坐标变换完成后，接下来生成BEV多通道图。Complex-YOLO使用的是类似MV3D和AVOD中的编码方式，常用输入尺寸是BEV图高400像素、宽704像素，对应实际空间范围为x方向0到70.4米（前方），y方向-40米到40米（左右）。每个像素代表0.1米x0.1米的网格。

这是一个非常典型的BEV地图规格，选择逻辑是：车辆前方70米范围基本覆盖了城市道路场景里绝大多数动态目标，横向40米能涵盖双向多车道，0.1米分辨率能在计算量和检测精度之间达到一个平衡。如果你把分辨率提高到0.05米，BEV图尺寸直接翻倍，网络计算量暴增，但精度未必有显著提升；如果降低到0.2米，远处目标在BEV图上只占三四个像素，小目标更容易漏检。

网格范围定义：

BEV_X_MIN = 0.0 BEV_X_MAX = 70.4 BEV_Y_MIN = -40.0 BEV_Y_MAX = 40.0 BEV_RESOLUTION = 0.1 GRID_WIDTH = int((BEV_X_MAX - BEV_X_MIN) / BEV_RESOLUTION) # 704 GRID_HEIGHT = int((BEV_Y_MAX - BEV_Y_MIN) / BEV_RESOLUTION) # 800

注意，这里我用的BEV图高800、宽704，但实际喂给Complex-YOLO的输入可能是704x400，取决于是否对y方向进行裁剪或者下采样。不同实现细节不一样，训练前一定要确认网络输入尺寸和预处理输出尺寸一致。

栅格化的核心逻辑是：把每个三维点映射到二维网格。映射公式很简单：

def point_to_grid(x, y): grid_x = int((x - BEV_X_MIN) / BEV_RESOLUTION) grid_y = int((y - BEV_Y_MIN) / BEV_RESOLUTION) return grid_x, grid_y

这里要注意：KITTI的x轴朝前，对应BEV图的列方向；y轴朝左，对应BEV图的行方向。但图像坐标系一般行是y、列是x，所以我们保存BEV图时通常用bev[grid_y, grid_x]的方式索引，也就是第一维是y方向，第二维是x方向。

接下来生成三个通道：

高度通道：每个网格里所有点的高度z的最大值。为什么取最大值而不是平均值？因为点云扫描到的物体表面更接近目标轮廓的上表面，取最大值能更好保留物体轮廓，比如车辆顶部、行人头顶，这些轮廓信息对检测很关键。

强度通道：每个网格里所有点的反射强度的最大值或均值。我这里用均值，但对一些反射较强的物体表面，最大值会丢失很多细节，均值更稳定。可以两个都跑一下对比效果再定。

密度通道：每个网格里点的个数，归一化到0-1。KITTI原始点云在不同距离上密度差异巨大，近处每平方米有几十个点，远处可能一个网格只有一两个点。直接使用原始点数会让网络过度关注近处目标，所以用log变换或者min-max归一化压缩一下动态范围。

常用的归一化公式：

def compute_density(points_per_grid): density = np.log(points_per_grid + 1) / np.log(64.0) return np.clip(density, 0.0, 1.0)

取log是压缩离散数值的自然选择，分母log(64)表示把64个点视作饱和阈值。这个参数是经验值，实际效果可以在可视化时观察。

拼合并保存：

def generate_bev_map(points_camera_coord): # points_camera_coord: Nx4, 相机坐标系下 grid = np.zeros((GRID_HEIGHT, GRID_WIDTH, 3), dtype=np.float32) # 首先把点云裁剪到BEV范围内 mask = (points_camera_coord[:, 0] >= BEV_X_MIN) & (points_camera_coord[:, 0] < BEV_X_MAX) mask &= (points_camera_coord[:, 1] >= BEV_Y_MIN) & (points_camera_coord[:, 1] < BEV_Y_MAX) filtered = points_camera_coord[mask] # 计算网格坐标 grid_x = ((filtered[:, 0] - BEV_X_MIN) / BEV_RESOLUTION).astype(np.int32) grid_y = ((filtered[:, 1] - BEV_Y_MIN) / BEV_RESOLUTION).astype(np.int32) # 高度通道 # 注意：BEV图的第一维是y，第二维是x，坐标取反 for i in range(len(filtered)): gx, gy = grid_x[i], grid_y[i] z_val = filtered[i, 2] if z_val > grid[gy, gx, 0]: grid[gy, gx, 0] = z_val grid[gy, gx, 1] += filtered[i, 3] # 强度累加，之后求均值 grid[gy, gx, 2] += 1.0 # 点数累加 # 强度均值 mask_density = grid[:, :, 2] > 0 grid[mask_density, 1] /= grid[mask_density, 2] # 密度归一化 grid[:, :, 2] = np.log(grid[:, :, 2] + 1) / np.log(64.0) grid[:, :, 2] = np.clip(grid[:, :, 2], 0.0, 1.0) return grid

上面这个循环在点数量特别大时效率不高（每帧十几万点，循环耗时约零点几秒），但预处理只需要跑一遍，完全可以接受。如果你想更快，可以用np.add.at这类向量化方法替代循环，我不在这里展开。

2.4 标签数据解析与3D框到BEV投影

点云转换完毕，标签也要处理。KITTI标签文件中每一行代表一个目标，格式如下：

Car 0.00 0 -1.57 599.41 156.40 629.75 190.50 1.53 1.63 4.07 2.73 1.72 11.90 -1.55

字段顺序依次是：类别（type）、截断率truncated（0-1）、遮挡程度occluded（0、1、2、3）、观测角度alpha（弧度）、2D框左上角和右下角坐标（x1 y1 x2 y2）、3D尺寸（height、width、length，单位米）、3D中心位置（x、y、z，相机坐标系下）、朝向角rotation_y（弧度）。

对训练Complex-YOLO来说，标签最核心的信息是类别、3D中心位置在BEV平面上的投影坐标（x和y）、朝向角、长度和宽度。其中rotation_y定义在相机坐标系中，z轴朝前，逆时针方向为正，它不等于BEV坐标中的朝向角。

将3D中心投影到BEV平面时，需要用到相机坐标到bev坐标的映射。由于相机坐标系中z是前向、x是朝右，BEV图以x为前向、y为横向，所以映射时要把点云坐标的第0维作为x方向，第1维作为y方向，但要注意正负号对应关系。标定文件中Tr_velo_to_cam已经把雷达坐标转到了相机坐标系，而我们在生成BEV图时用的是相机坐标系的点，标签中的位置也是相机坐标系下的，所以可以直接用同样的网格映射逻辑：

def label_to_bev_box(label): # 只提取 类别, height, width, length, x, y, z, rotation_y cat = label[0] h, w, l = float(label[8]), float(label[9]), float(label[10]) x, y, z = float(label[11]), float(label[12]), float(label[13]) ry = float(label[14]) # BEV 中心坐标（像素坐标） bev_x = int((x - BEV_X_MIN) / BEV_RESOLUTION) bev_y = int((y - BEV_Y_MIN) / BEV_RESOLUTION) # BEV 朝向角，KITTI的rotation_y在相机坐标系下，与BEV角度的对应关系需要推导 # 在相机坐标系下，z向前，x向右。BEV视角下，x向右为前向，y向下为左 # 所以 BEV 角度 θ = -ry theta_bev = -ry return {'category': cat, 'h': h, 'w': w, 'l': l, 'bev_x': bev_x, 'bev_y': bev_y, 'theta': theta_bev}

这里关于角度的符号问题我多写几句。KITTI中rotation_y是相机坐标系下目标朝向与z轴的夹角，绕y轴旋转。当我们俯视BEV平面，把x方向（原相机z）定为前向，y方向（原相机x）定为右向时，角度的方向会反转。网路训练时如果角度符号搞反了，会造成loss振荡甚至不收敛。所以强烈建议保存标签后做一次可视化验证，下面第三节我会具体讲怎么验证。

3. 训练数据制作流程与脚本实现

3.1 标定文件读取与矩阵串联

标定文件是所有坐标系变换的地基。不同仓库对矩阵的处理方式不一样，我见过有人直接把Tr_velo_to_cam乘到点云上，也有人先做相机校正R0_rect再投影到图像。如果你只看BEV，不做图像投影验证，只用到Tr_velo_to_cam就够；但如果要让点云和图像对齐，就需要完整的链路：

点云 → 相机坐标（Tr_velo_to_cam） → 校正相机坐标（R0_rect） → 图像像素（P2）

代码：

def load_calib(calib_path): calib = {} with open(calib_path, 'r') as f: for line in f.readlines(): key, *values = line.strip().split(' ') calib[key[:-1]] = np.array([float(v) for v in values]).reshape(3, 4) return calib def project_velo_to_image(points_xyz, calib): # points 相机坐标 Nx3 Tr = np.eye(4) Tr[:3, :] = calib['Tr_velo_to_cam'] R_rect = np.eye(4) R_rect[:3, :3] = calib['R0_rect'].reshape(3, 3) # 注意 R0_rect 在文件里是 9 个数还是 3x3 P2 = np.eye(4) P2[:3, :] = calib['P2'] xyz_hom = np.hstack([points_xyz, np.ones((points_xyz.shape[0], 1))]).T cam = Tr @ xyz_hom # 相机坐标系 cam_corrected = R_rect @ cam # 校正后的相机坐标 uv = P2 @ cam_corrected # 齐次像素坐标 uv = uv[:2, :] / uv[2, :] # 归一化 return uv.T

关于R0_rect的读取，KITTI标定文件里有时写成R0_rect: 9个float，有时单独一个矩阵，读的时候要注意reshape成3x3。

3.2 批量生成训练样本

核心脚本逻辑梳理清楚后，批量处理就顺理成章了。我的目录规划是：

kitti_prepared/ ├── image_2/ ├── bev_maps/ # 保存 .npy 或者 .png 的 BEV 图 ├── labels/ # 保存转换后的训练标签 ├── train.txt # 训练样本编号列表 └── val.txt # 验证样本编号列表

批量处理脚本框架如下：

import os import numpy as np import cv2 KITTI_ROOT = '/path/to/kitti' OUTPUT_ROOT = '/path/to/kitti_prepared' TRAIN_SPLIT = '/path/to/train.txt' VAL_SPLIT = '/path/to/val.txt' def process_one(idx): velo_file = os.path.join(KITTI_ROOT, 'data_object_velodyne/training', f'{idx:06d}.bin') label_file = os.path.join(KITTI_ROOT, 'data_object_label_2/training', f'{idx:06d}.txt') calib_file = os.path.join(KITTI_ROOT, 'data_object_calib/training', f'{idx:06d}.txt') image_file = os.path.join(KITTI_ROOT, 'data_object_image_2/training', f'{idx:06d}.png') points = load_velodyne_bin(velo_file) calib = load_calib(calib_file) # 点云转到相机坐标系 Tr = np.eye(4) Tr[:3, :] = calib['Tr_velo_to_cam'] points_cam = transform_points(points, Tr) # 生成BEV图 bev = generate_bev_map(points_cam) # 保存BEV图（可以是 .npy，也可以是可视化后的 .png，取决于训练代码怎么读） np.save(os.path.join(OUTPUT_ROOT, 'bev_maps', f'{idx:06d}.npy'), bev) # 解析标签并转换 labels = parse_kitti_label(label_file) with open(os.path.join(OUTPUT_ROOT, 'labels', f'{idx:06d}.txt'), 'w') as f: for lab in labels: f.write(f'{lab["category"]} {lab["h"]:.2f} {lab["w"]:.2f} {lab["l"]:.2f} ' f'{lab["bev_x"]} {lab["bev_y"]} {lab["theta"]:.4f}\n') # 必要时把投影点云画到图像上用于校验 if VERIFY: img = cv2.imread(image_file) uv = project_velo_to_image(points_cam, calib) for u, v in uv: if 0 <= u < img.shape[1] and 0 <= v < img.shape[0]: img[int(v), int(u)] = (0, 255, 0) cv2.imwrite(os.path.join(OUTPUT_ROOT, 'image_2', f'{idx:06d}_proj.jpg'), img)

这里有个建议：BEV图建议保存为.npy格式，保留浮点数精度，不要直接保存成jpg或png。BEV图本来是多通道浮点特征，压缩为8位图像会丢失大量数值信息，尤其是高度通道的精度，会对训练精度产生不可忽略的影响。若训练代码要求输入是图片路径，则要在代码里改成直接读.npy，这通常只需要几十行改动，不要因为偷懒而牺牲精度。

3.3 数据校验与坐标对齐可视化

数据生成完之后，必须做视觉验证，这一步无论如何不能省。一个坐标或角度符号的错误，会在模型训练到一半时才暴露出奇怪的现象，到时候你根本分不清是网络问题还是数据问题。

验证分三层：

第一层：点云投影到图像。把变换后的点云按照颜色深度画到相机图像上，如果标定矩阵正确，点云的边缘轮廓应该和图像中的车辆、行人轮廓对齐。特别是地面点应该落在图像的道路区域，车辆点云应该覆盖在车身上。这一层能验证Tr_velo_to_cam和P2是否正确。

第二层：3D框投影到BEV图。把标签里的3D框角点投影到BEV图上，画在BEV图的上面，然后叠加原始点云的BEV可视化。这个能验证BEV栅格化的映射和标签坐标转换是否一致。一个正确生成的BEV图，框中应该能看到对应目标的点云簇，框的朝向应该和点云主体方向基本一致。

第三层：3D框投影到图像。这需要在代码里实现3D框8个角点到图像平面的投影，画出来看是否贴合图像中的目标。KITTI官网提供了show3Dbox项目，直接拿过来用也行。

这些都是为了保证一个事：坐标系链路从始至终是通的，你训练时用的标签描述的目标位置，和你喂给网络的BEV特征里的目标位置，确实是同一个位置。由于Complex-YOLO这类单阶段方法的mAP很大程度依赖预处理的精度，这步多花一小时，能省后面调模型的好几天。

4. 常见问题与避坑指南

4.1 坐标系混乱与角度符号方向

坐标系是预处理里第一大坑。我之前见过一个很典型的问题：点云和图像投影看起来完全正常，3D框投影到图像也很贴合，但训练时loss居高不下，最后发现是标签的的角度和BEV图坐标的符号没对齐——网络要学的是“在这个BEV栅格位置上，以这个角度放置一个框”，你给的角度和位置点云特征没对齐，网络当然学不到。

解决办法是在生成标签的时同步生成一张可视化BEV图，把每个目标的朝向画成箭头，然后和点云的形态对比。如果箭头指向和点云车辆头部方向相差90度，就要检查角度转换逻辑。

另外还有一点，alpha和rotation_y是KITTI里两个不同的角度。alpha是观测角度，取决于目标相对相机的位置；rotation_y才是目标在全局朝向。训练检测网络时一般用rotation_y，别搞混。

4.2 BEV分辨率和范围导致的细节丢失与框偏移

范围越大，分辨率越低，对远处小目标越不友好。KITTI里行人在远处也就几个点，0.1米分辨率下可能只有一个网格，目标基本不可辨。但把分辨率提到0.05米会导致输入尺寸翻倍，检测速度大幅下降。这是一个权衡问题，实际中0.1米是广泛接受的折中。

框偏移问题常见于物体截断场景。KITTI里有些目标在图像边缘被截断，但3D中心坐标仍然完整。预处理时生成标签只保留BEV中心在范围内的目标，这会导致截断目标不可见或框位置偏移。处理方式是：对每个目标的8个角点投影到BEV，判断至少有多少角点落在范围内，做一个阈值过滤，而不是只看中心点，这样能提高标签质量。

4.3 数据不平衡与类别过滤问题

KITTI数据集本身类别极不平衡。Car占了绝大多数，Pedestrian和Cyclist相对少很多，Person_sitting和Van、Truck更少，Tram则更稀少。如果直接把所有类别全部训练，网络大概率会把所有目标都预测成Car。

我的建议是：训练Complex-YOLO这类基础模型时，第一轮先只训Car；等整个pipeline跑通后，再考虑加入Pedestrian和Cyclist。这样既能快速验证模型效果，也能避免一开始就被多类别不均衡干扰。此外，DontCare类别的目标必须显式跳过，不能作为背景，因为它们实际上是目标只是不标注，把它们当背景训练会引入大量false negative干扰，严重影响训练收敛。

4.4 内存、文件读写与随机种子问题

预处理阶段看起来简单，但批量处理7481帧时，内存和IO管理不当也会出问题。BEV图每一帧是800x704x3的float32数组，单帧约6.77MB，7481帧全部加载到内存约50GB，显然不现实。正确方式是逐帧处理、逐帧保存，训练时按需读取。生成train.txt和val.txt时，记录的是索引号而不是预加载数据，这样训练脚本才能做到做了随机shuffle的同时不爆内存。

视角抖动方面，如果你在预处理里使用了随机采样的滤波逻辑（比如随机丢弃部分点），一定要设置固定随机种子，否则每次运行生成的训练集不一样，模型结果无法复现。我一般在脚本开头加：