4. 数据表示与预处理

Occupancy Flow 预测的质量，在很大程度上并不取决于网络结构有多深，而取决于输入数据是否被组织成“时空一致、坐标一致、语义一致”的统一表示。本章围绕数据表示与预处理展开，重点解决五个工程问题：多模态如何融合、连续空间如何体素化、多帧如何对齐、多传感器如何统一坐标、标注如何解析与增强。

一、核心原理：从异构传感器到统一占用张量

激光雷达提供精确的三维几何，相机提供丰富的纹理与语义，但两者采样方式完全不同：点云是稀疏、无序、连续坐标的集合，图像是稠密、规则、离散像素的网格。融合的本质，是把它们映射到同一个可学习的表示空间中。工程上通常采用“体素作为公共容器”的策略：将三维空间划分为规则体素网格，每个体素聚合来自点云的几何特征与来自图像的语义特征，最终形成形状为 [T, X, Y, Z, C] 的时序占用张量。

二、方法流程：体素化、特征编码与时序对齐

体素化不是简单地把点塞进格子。常用做法是先设定体素尺寸（如 0.2m×0.2m×0.2m），再对每个体素内的点做特征聚合。常见编码方式包括：

• PointPillars 式柱体编码：在 Z 方向不划分，用柱体代替体素，速度快，适合实时感知。
• VoxelNet 式体素特征编码（VFE）：对体素内点做逐点线性变换、最大池化，保留局部几何。
• 稀疏卷积：只对非空体素计算，显著降低显存与算力开销。
• 图像特征投影：通过相机内外参将图像特征反投影到体素，实现点云—图像融合。

时序帧对齐的关键是“运动补偿”。若直接把 t-1 帧的占用栅格叠加到 t 帧，自车运动与物体运动都会造成错位。工程上通常先做自车运动补偿（ego-motion compensation），再对动态物体做光流或场景流对齐。坐标系统一则需要明确四个坐标系：激光雷达系、相机系、自车系、世界系，并用标定外参和自车里程计完成链式变换。

# 典型预处理流水线（伪代码）
for frame in sequence:
    points = load_lidar(frame)              # 雷达系
    points_ego = T_ego_lidar @ points       # 转到自车系
    points_world = T_world_ego(t) @ points_ego  # 转到世界系
    voxels = voxelize(points_world, size=0.2)
    img_feat = backbone(image[frame])       # 图像特征
    voxel_feat = fuse(voxels, img_feat, calib)  # 点云-图像融合
    aligned = align_to_current(voxel_feat, ego_motion)
    occupancy[t] = encode(aligned)          # 时序占用张量

三、数据增强与标注格式解析

数据增强必须保持“几何—语义—时序”三者一致。对点云做全局旋转、缩放、翻转是安全的；但对图像做随机裁剪时，必须同步修改相机内参，否则投影关系被破坏。时序增强中，随机丢帧、时间抖动可以提升鲁棒性，但会破坏速度估计，需谨慎使用。

标注格式方面，Occupancy Flow 常用两类：一类是稠密占用栅格标签，形状为 [T, X, Y, Z]，每个体素标记为空、占用或未知；另一类是实例级流标签，记录每个体素在相邻帧间的位移向量。解析时要特别注意：未知区域（unknown）不能简单当作空（free），否则会引入错误监督。

四、案例与复盘：一个典型的对齐失败

某项目在城市场景中出现“静止车辆在占用预测中缓慢漂移”的现象。排查发现：体素化与融合均正常，问题出在时序对齐环节——自车运动补偿使用了错误的坐标系顺序，把世界系到自车系的变换当成了自车系到世界系。修正后漂移消失。这个案例说明，坐标系统一不是“配好外参就完事”，而是要在每一帧、每一个模块中反复验证变换方向。

综上，数据表示与预处理是 Occupancy Flow 工程的地基。体素化决定了几何分辨率，融合决定了语义丰富度，时序对齐决定了运动一致性，坐标系统一决定了空间正确性，而标注解析与增强策略决定了监督信号是否可靠。把这五件事做扎实，后续的预测网络才有发挥空间。