介绍自动驾驶感知任务中的--3D Occupancy Semantic Prediction

什么是Occupancy

自动驾驶领域，按照传统会分为perception, prediction, planning和control四大部分，有时会加上map。

其中最为重要的就是perception，也是目前自动驾驶的瓶颈所在，如果感知算法给了下游任务错误的视觉信息，那么整个自动驾驶技术也无从保证了。

感知任务的输入格式主要有三种：相机，激光LiDAR，声波Radar。近几年纯视觉(只有相机输入)的感知算法异军突起，如何从相机的输入中获得准确的深度信息，一直是一个难题。

而Occupancy是自动驾驶感知任务一种近几年非常热门的输出格式。

Occupancy将这个场景划分成正方体网格，每个网格被赋予语义标签，即，标注这个网格内的物体属于哪个类别，或标注为没有被占用。

为什么需要Occupancy

在很长一段时间里，bounding box(简称为bbox)都是非常主流的输出格式。就是给目标物体打上一个3D立方体的标注框。我们一般称这种任务为Object Detection。

但是，这种输出格式也有一些问题：

(1)3D标注框的这种表示消除了物体的几何细节，如挖掘机具有从主体突出的机械臂，bounding box在标注这类物体时就没有办法有很准确的表示；

(2)不常见的类别，如街道上的垃圾桶，往往被忽略，在nuScenes和Waymo数据集中都没有标记，因为开放世界中的对象类别不能被广泛枚举。这些在Occupancy任务中会被归结为General Object(GO)类。

于是就有了Occupancy的提出，他是最近一种非常火热的输出格式，相当于是把颗粒度从object-level给精细化到了voxel-level。

但是Occupancy在这些有点上，也有一些局限性：

(1)相比于Object Detection这个任务，丢失了object或者说instance的概念，没有办法做运动追踪和动态物体的运动补偿；

(2)整个场景很大，但是被占据的位置非常少，监督很稀疏，加大了训练难度；

(3)想要更小的分辨率，就会有巨大的计算量；

(4)还是没有open vocabulary，没有办法穷举所有的uncommon categories。

区分和BEV的概念

BEV是Bied's Eye View的缩写，意为鸟瞰图。并不作为一种感知任务的输出格式，更多的是作为一个特征空间。但是这个特征空间是2D的，每个位置在z轴方向上的信息被隐式地蕴含在了channel这个维度里面。

RGB的相片和点云都可以通过经典的backbone得到BEV这个特征空间上的特征变量，然后用上不同的decoder也可以得到不同的输出，比如map, bounding box, 3D Occupancy.

主流的混合传感器，或者多下游任务同时训练，都会使用BEV作为统一地特征空间，因为这种特征非常灵活。

Occupancy Dataset

Occupancy的真值(ground truth，简称gt)生成，一般是选定一个有相机和雷达数据的自动驾驶数据集，然后有一套复杂的pipeline能够完成这件事情，具体可以参考Occ3D的pipeline。

以下是目前主流的Occupancy数据集，分别来自以下几篇论文，括号内部写的是基础数据集和发表的会议：

主流的Occupancy方法

一些Object Detection上的主流方法可以在更换一个decoder后用来做Occupancy这个任务上使用，比如BEVDet, BEVFormer, TPVFormer, SOLOFusion, FB-BEV等等。

一些我认为Occupancy中重要的方法论文，括号内部是发表的会议：

还可以参考这两篇survey，括号内是挂在arxiv上的日期：