BEV 感知模型实用的一些经验

目前实用 BEV 的技术方案已经有大概半年时间了，多个 BEV 模型都在不同项目做了实际部署，可以在这些工作的基础上做一些经验总结了。

内容其实是断断续续写的，因为新冠的脑雾在我身上可感知的大概持续了半个月。

BEV 带来的优势：

虽然这个看起来比较反直觉。但是实际上性能反而比 2D 任务更好，而且还能保持基本对标甚至更好的指标。同样的两个任务，我们使用更少的算力（1/3 不到），由单相机扩展到 6相机，依然保持了实时运行。在测试指标上，基本保持了一致。当然，我们的 BEV 感知范围减少了侧向和后向的范围。

相比传统的方案，主要的提升来源：

整个 Pipeline 处理更加简单和一致，相比一些传统的方案，代码量降低了很多，在工程方向上，这个极大的一个优点。越少的代码，代表越少的bug，越低的维护成本。
由于没有了 infer 后的一些额外后处理工作带来的指标降低，模型结构可以进一步简化，不用在模型这里去补偿。
Multi-scale 的融合集中在模型内部。
在 BEV 的统一框架下，我们可以将多个任务融合在一个模型中统一处理。

这个无需怀疑，我们的经验和之前 Tesla AI day 上的一些宣传是一致的：

在使用多目的 BEV 模型后，车身周边的障碍物感知是提升显著的。由于多个原因，评测集合中的车身侧后的 GT 是有盲区的，模型都可以正常检测。目标在切换不同相机感知范围时，在我们自己的测试集上看，很少有跳变。

由于这一框架更加稳定，通用，功能扩展基本都可以在 head 上简单增加内容。比如 Tracking Embedding 的功能，代码 + 验证训练，仅仅需要 3 天，实际上绝大部分时间都在训练上。

主要的来源是算子限制。最近一年中，BEV 的论文，百家齐放。但是落实到我们使用的 AI 加速器上，大部分都不支持。即使勉强支持，性能也不行。我们最终还是切换到 MLP 的方案上实现上车运行。

2D -> 3D 的转换模块带来的信息损失，带来的直接问题就是远距离、小目标的检测不理想。不过由于目前阶段的感知范围相对比较小，还没有要求到100m开外，所以整体上表现还不明显。但是这个问题可能依然是未来必须要面对的问题，我这里有一部分的工作也在尝试缓解这个问题。

数据量需求较大：
由于2D -> 3D 的部分我们使用的是 MLP，非常容易过拟合。
视觉上 3D 本身的 augmentation 很难做，而且对于硬件标定有依赖。
生成难度也较大：目前阶段还大量使用激光来辅助数据生成，但是这样的方案由于传感器的原因，在未来是没法扩展的。这也是目前阶段我们在尝试考虑的一个问题。
随着多目任务的引入，带来了一个很难避免的问题：模型和相机的布置基本处于一个硬绑定的状态。对于普通的公司，必须面对这个问题：怎么样可以用尽量少的数据、更快的适配新的车型。在我看来这是一个体系化的解决方案，数据、硬件、算法、工程，都需要针对这一问题作出适应。
目前来看，特斯拉的 4D 标注在静态元素上确实是一个比较符合逻辑的方案，成本和效率都比较高（当然也会有一些问题）。但是动态元素上的工作，我们还在考虑。

当然这个和 BEV 本身并没有直接关系。但是感知模块即使做到完美也存在盲区、遮挡、极限范围外的问题。所以，如何更好的处理不确定性，增加容错度是依然需要面对的问题。

我自己爱说的一句：感知做到最后都是预测。一旦涉及到预测，就引入了不确定性和概率。如何利用模型来应对这个问题，应该是未来工作内容的一个重点。

在学界，已经有很多方案。主要方向：利用投影、Transformer 及其变体、直接的MLP。

目前从应用角度来看，都还有或多或少的缺陷。怎样实用化一个新的转换模块，也是需要考虑的。公司内部也有其他的 team 做了一些探索性的工作，提供了一些情报支持，我们自己也在开展下一代转换模块的选型和试验。

从我个人的角度来看，逐渐的减少先验限制才可能会有更好的结果。当然，从工业界研发来看，要把握好时机和程度，做好平衡。

BEV 方案相对来说是比较吃数据的。当然，也没有夸张到是数据怪兽，非特斯拉的数据量不行，正常的公司慢慢迭代稳定后，是可以达到一个基准线的。

本身引入 3D 空间后，augmentation 变得很难，尤其是多相机相互之间的关系让这个问题更加复杂。最可靠的方法反而是：堆更多的数据。