2、数据表示与坐标系：体素(Voxel)表示法、世界坐标系与自车坐标系、时间戳对齐

好，咱们进入第二个核心话题。说实话，搞Occupancy网络这么久，我觉得最绕不开的就是数据表示和坐标系。你算法再牛，如果数据表示没搞对，坐标系乱成一锅粥，那模型训练出来也是个“路痴”。今天我就把这块掰开了揉碎了讲清楚。

2.1 体素(Voxel)表示法：从连续到离散

先聊聊体素。说白了，就是把我们感知到的三维空间，切成一个个小立方体。就像乐高积木一样，每个小方块代表空间中的一个点。

为什么非要用体素？ 你想想看，现实世界是连续的，但计算机只能处理离散数据。体素化就是把连续空间离散化，让模型能“看懂”三维结构。我最早做激光雷达感知时，直接处理点云，那叫一个头疼——点云稀疏、无序，模型很难学到稳定的几何特征。后来换成体素表示，问题一下子简化了。

我在项目中遇到过一个问题：体素分辨率设得太高，模型直接OOM（显存溢出）。后来我学乖了，一般先用0.2m分辨率做粗感知，再在感兴趣区域用0.1m做精细重建。这叫“由粗到细”，效果不错。

2.2 世界坐标系与自车坐标系：谁是谁的“锚”

坐标系这块，我见过太多人栽跟头了。说白了，就是搞清楚“我在哪”和“东西在哪”的关系。

自车坐标系：以车辆自身为原点。通常X轴朝前，Y轴朝左，Z轴朝上。这个坐标系是“动态”的——车一动，坐标系就跟着动。好处是直观，传感器数据（比如激光雷达、相机）直接就是自车坐标系下的。

世界坐标系：固定在地球上的某个点。比如以路口中心为原点，X轴朝东，Y轴朝北，Z轴朝天。这个坐标系是“静态”的，不随车辆移动而改变。

你可能会问：“为什么要搞两个坐标系？” 原因很简单——时序融合需要世界坐标系，实时感知需要自车坐标系。举个例子，你要做多帧融合，把t-1时刻和t时刻的障碍物位置对应起来，就必须统一到世界坐标系下。否则，车一转弯，前后两帧的数据就对不上了。

具体转换公式其实不复杂：

// 自车坐标系 -> 世界坐标系
P_world = R * P_ego + T

// 世界坐标系 -> 自车坐标系
P_ego = R^(-1) * (P_world - T)

其中：
R: 旋转矩阵（3x3）
T: 平移向量（3x1）
P_ego: 自车坐标系下的点
P_world: 世界坐标系下的点

嗯，这里要注意：R矩阵不是随便写的，它由车辆的横摆角、俯仰角、侧倾角决定。我一般用欧拉角转旋转矩阵，但小心万向锁问题。实际工程中，我更推荐用四元数，稳定可靠。

2.3 时间戳对齐：别让“时间差”毁了你的模型

时间戳对齐，说白了就是让不同传感器、不同时刻的数据“对上号”。这个问题在Occupancy网络中尤其重要，因为我们要融合多帧信息。

为什么需要对齐？ 你想想看，激光雷达每秒扫描10次，相机每秒30帧，IMU每秒100次。这些数据到达的时间点都不一样。如果不做对齐，你拿到的“同一时刻”的数据，可能实际差了50毫秒。对于高速行驶的车辆，50毫秒能跑出去1米多——这误差就大了去了。

我常用的对齐策略有三种：

策略	原理	适用场景	我踩过的坑
硬同步	硬件触发，所有传感器在同一时刻采集	实验室环境、高精度需求	硬件成本高，调试复杂
软同步	软件插值，把不同时刻的数据对齐到同一时间戳	大多数实际场景	插值方法选不好，精度会下降
时间戳近似	找最近的时间戳，直接拿来用	低精度需求、快速原型	误差大，不推荐用于Occupancy网络

我个人习惯用软同步。具体做法是：以激光雷达的时间戳为基准，把其他传感器的数据通过线性插值或样条插值，对齐到激光雷达的时间点上。为什么选激光雷达做基准？因为它的时间戳最稳定，而且Occupancy网络主要依赖激光雷达数据。

还有一个细节：时间戳的精度。我见过有些数据集的时间戳只精确到毫秒，但实际需要微秒级精度。怎么办？我一般会用IMU的时间戳做“高精度参考”，因为IMU的采样频率高，时间戳更精确。然后把激光雷达和相机的时间戳，通过IMU时间戳做二次校准。

嗯，这块内容确实有点绕。但说白了，数据表示和坐标系就是Occupancy网络的“地基”。地基没打好，上面盖的房子再漂亮也白搭。我当年第一次做多传感器融合时，就是吃了时间戳没对齐的亏——模型训练出来，在高速场景下性能直接崩了。后来花了整整一周排查，才发现是时间戳差了20毫秒。

所以，我建议你在开始写代码之前，先把这三个问题想清楚：

• 体素分辨率设多少？感知范围多大？
• 坐标系转换矩阵写对了吗？
• 时间戳对齐方案选好了吗？

这些问题想清楚了，后面的工作就是水到渠成的事。