StreamPETR | 更快更强! 纯视觉感知与激光雷达终有一战之力! - 文章 - 开发者社区

点击下方卡片，关注「集智书童」公众号

作者丨ChrisM@知乎（已授权转载）来源丨https://zhuanlan.zhihu.com/p/645470702 编辑丨小书童

纯视觉BEV感知虽然发展了两年左右的时间，但距离激光雷达算法一直都有较大差距。

BEVDepth首次将纯视觉与激光雷达的差距缩到10%以内，但随后的一系列工作似乎陷入了瓶颈，大都围绕在62%NDS左右（不考虑未来帧的buff）。难道纯视觉感知的性能真的止步于此了吗？

对于这个问题，这里介绍一下我们刚刚收录于ICCV 2023的最新工作“StreamPETR：Exploring Object-Centric Temporal Modeling for Efficient Multi-View 3D Object Detection”。

提出以object query作为时序传递载体，成为在不使用未来帧的情况下首次超越CenterPoint（67.3% NDS, 63.8% AMOTA）的纯视觉BEV感知算法（67.6% NDS, 65.3% AMOTA）。与此同时，由于object query时序传递的高效性，StreamPETR相比单帧的PETR几乎没有引入额外的计算量。这使得StreamPETR同时成为了当下最快的BEV感知算法，比SOLOFusion速度快了2.8倍！

picture.image

文章链接：https://arxiv.org/abs/2303.11926 代码链接：https://github.com/exiawsh/StreamPETR

1、动机

picture.image Fig.1

在BEVFormer之后，大家都将BEV感知的关注点转移到时序建模上，SOLOFusion更是展现了长时序建模无与伦比的性能提升。那么现有的时序建模是否还有提升空间呢，为此我们把现有方法划分为两种分别来看：

「BEV 时序建模（BEVFormer, SOLOFusion）」 ：如图Fig.1（a），该方法显式地将 BEV 特征从历史帧投影到当前帧，将BEV 特征作为中间表示来进行时间建模。在时序匹配上通常使用前一帧的BEV特征与当前帧进行对齐，即

picture.image

无论是简单的concat还是deformable attention都只考虑了静态物体，但由于BEV 特征具有高度的结构化，很难对动态目标针对性处理。

「Perspective 时序建模（PETRv2, Sparse4D）」 ：相比BEV方法，DETR-based方法由于object query的设计机制，并不需要BEV的空间转换，因此更加高效。如图Fig.1（b），Perspective的时序建模主要针对这类方法，通过object query与多帧图像进行时序交互，即 picture.image object query的使用有助于移动对象的建模，但这种时序建模方式效率较低，object query需要和多帧的图像特征共同交互，随着帧数的增加，head的计算成本翻倍增加。

考虑到两种时序建模的优劣性，我们希望以DETR-based方法为baseline，像BEV时序建模那样引入一个高效的中间表征传递时序，避免特征重复计算，保持DETR-based方法的高效性与动态建模特性。

为此，如图Fig.1（c），我们提出了一种基于object query的建模方式：

「Object-centric 时序建模」 ：该方法是通过前后帧object query之间的hybrid attention来进行时序的传播。针对于运动物体的建模，用物体的运动属性M（时间间隔t，速度v，ego姿态矩阵E）对历史帧的object query进行变换

picture.image

来实现与当前帧的进行对齐与融合。随后的时序融合参考了BEVFormer类似的RNN方式

picture.image

基于vanilla attention 的时序融合由于考虑了object之间的特征相似性，对于物体本身的位置先验不会特别敏感，对运动物体更加鲁棒，这也使得基于vanilla attention的时序建模上限更高。

2、方法

picture.image

StreamPETR的模型主要分为三大块：一个image Encoder、一个Queue形式的的内存队列和一个propagation transformer组成。这里主要介绍时序融合相关的Memory Queue与propagation transformer：

「Memory Queue」 ：Queue的大小是 NxK，N是储存的帧数，K是储存的object的数量。采用先入先出（FIFO）的更新机制，一般根据分类得分选取TopK个前景目标的信息进行存储。

具体而言，每一个内存空间包含对应object的时间间隔, 语义embedding,对象中心点,速度 v 和姿态矩阵E。在实验中我们选取K=256，相比BEV方法节省了近百倍的存储空间。

「Propagation Transformer」 ：Propagation Transformer 我们引入了两个概念， Motion-aware Layer Normalization （MLN）和Hybrid attention。

MLN实现了隐式的运动补偿，Hybrid attention则实现RNN式的时序交互。

picture.image

(1) MLN

MLN的设计源于我们此前对于GAN的研究，在生成领域，类似的condition normalization应用非常广泛。因此我们采用了同样的网络结构设计，将normalization 层的仿射变换参数变成dynamic生成的。

(2) Hybrid Attention

Hybrid Attention在这里用于取代原生的self-attention。首先它起到self-attention的作用，对于当前帧的重复框进行抑制。其次，当前帧的object query还需要和历史帧object query做类似cross attention操作，进行时序的交互。

由于hybrid queries远小于cross attention中 image token的数量，因此所带来的额外计算量可以忽略不计。此外历史object query也会传递到当前帧为当前帧提供更好的初始化（propagate query）。

3、实验

「nuScenes 数据集检测和tracking性能」 ：

picture.image

首先是测试集的检测性能，虽然在这里排名第二，但我们是唯一一个没有使用未来帧的方法。

参考VideoBEV未来帧的性能提升（大约4%NDS），其他方法的性能实际上已经被StreamPETR拉开了不小的差距。此外我们注意到我们拥有最强的角度预测能力（mAOE），即便和多模的方法比，我们的角度误差也是最低的。

picture.image

Tracking榜单上由于大家都没有使用未来帧，这种性能优势会更加明显。我们使用和CenterPoint相同的tracking策略，StreamPETR比排名第二的Camera-based方法高8.9%AMOTA，比Lidar-based的CenterPoint高1.5% AMOTA。

3.1 Ablation 实验：

(1) 针对Queue长度的对比试验

picture.image

提高训练帧数主要用来解决训练帧数和测试帧数不一致问题，8帧streaming video测试超过了sliding window方式，12帧性能差不多饱和。

picture.image

对于这个现象，我们在rebuttal中对nuscenes的tracking进行统计。如果说，长时序主要解的是物体的遮挡，那么tracking中物体遮挡的帧数则表明了长时序饱和的帧数。从上图中我们可以看到nuscenes数据集中，绝大部分物体遮挡的帧数都在10帧以内，验证了我们的假设。

(2) 针对MLN的对比试验

picture.image

采用显式运动补偿（MC）时性能并没有提高。这一点有点反直觉，其实很大程度上在于vanilla attention本身就可以解决大部分动态建模的问题，因此运动补偿的作用本身就不会很大。MLN的 ego poses 的隐式编码，其中 mAP 提升了 2.0%，NDS 提升了 1.8%。继续采用MLN的时间偏移量 Δt 和物体速度 v 的编码， mAP 和 NDS 都增加了 0.4%。

(3) memory queue对性能的影响

picture.image

mAP 和 NDS 随着memory queue帧数的增加而提高， 2 帧（将近 1 秒）的时候就开始饱和。这说明这种recurrent的长时序建模并不需要较大的memory queue帧数。之所以1帧没有2帧效果好，是因为每帧只保存了K=256 object query，如果保存512或者900，这种性能gap将会消失。

(4) 不同时序融合方式的对比

我们对比了PETRv2的perspetive时序交互方式，可以看出，StreamPETR 的方式在速度和准确性上都优于perspective交互。且同时使用object query和perspective的交互没有涨点。

picture.image

在我的理解上通过attention机制获得的object query，类似于对于multi view 图像特征进行的low rank分解（参考 Is Attention Better Than Matrix Decomposition），虽然只保存了256 object query，但实际上保存了image features的绝大部分有效信息，因此当两种特征同时使用时不会有继续提升。

(5) 扩展性

我们在 DETR3D 上进行了实验，实现了4.9% mAP和 6.8% NDS的提升，而推理速度几乎没有受到影响。与PETR相比，DETR3D的提升较小，实际上是 DETR3D 采用的局部空间注意力限制了性能。我们私下采用deformable attention将DETR3D的空间采样点增多，可以实现StreamPETR同样或者略高的性能。

4、总结与思考

从PETRv1开始，我们就一直追寻简单高效的工作，方便大家使用。

StreamPETR的速度和精度在3D检测上都相较以前方法有很大优势。不仅如此，在实际开源的过程中我们提供了和SOLOFusion同样的iter-based训练方式，因此实际的训练时间和单帧时间完全一样高效。论文的绝大部分实验都可以在2080ti上训练完成，理论上，我们ViT-L的大模型，不需要修改batchsize也可以在3090级别的显卡上训的下。StreamPETR算是PETR系列的一个结尾，希望大家喜欢我们的工作！

(1) 如何取得比论文更快的速度？

可以把transformer的FFN通道数从2048改为512，此外使用flash attention进行测试。此外，论文的速度包含了后处理。在50米的范围内query数目可以降低到300左右。

(2) 如何提升mAOE？

Transformer本身可以减少角度的误差，此外query denoise本身也有助于mAOE。我们没有针对性调参，ViT+DN起到了比较好的化学反应。

(3) flash attention有哪些注意事项？

flash attention需要开启FP16训练，不支持V100。在PETRv1上，遇到Multi-view 2D PE也会不收敛。flash attention可以大幅降低显存，训练其它基于PETR的框架，例如PFTrack的时候也建议使用flash attention。

(4) Streaming训练有哪些注意事项？

Streaming训练比起sliding window训练没有那么容易收敛，因此Streaming训练最好有辅助监督。例如：2D监督，depth监督，query denoising等。

(5) StreamPETR在实际部署时可能有哪些困难？

一般训练是在关键帧（约2hz）上进行，但是在实际测试时需要引入非关键帧（10-25hz），而StreamPETR采用了时间PE，时间PE的插值和外推性能较差，训测不一致会导致较大的performance下降。

可以考虑将memory queue的大小从NxK改为1xK（比如原论文中我们采用的setting是4x256，可以改为1x900，propagted query的大小保持256不变），对于performance没有较大的影响。或者引入随机时间间隔的时序增广也可以缓解此类问题（参考BEVDET4D或者PETRV2对于sweep的使用方式）。