MapNeXt:Revisiting Training and Scaling Practices for Online Vectorized HD Map Construction

参考代码:None

动机与出发点
MapTR算法在局部在线地图任务中已经表现出了很强的能力,但是在该算法的基础上是否可以进行更近一步探究影响局部地图感知性能的影响因子呢?这篇文章从“training”和“scaling”两个维度对整体算法进行分析和解构。在“training”中,首先探究了MapTR中GT permutation机制带来的额外影响,也就是如何让query更好去学习,并以此基础构建多group的query设置,从而提升局部地图感知的性能。在DETR类算法中query的pos-emb是一个很重要的东西,那么怎么去优化这个(MapTR中采用split操作得到初始pos-emb)才能将pos信息更好融入网络(其实就是让pos-emb的来源更有实际几何先验一些)。在“scaling”中,分析了FFN网络dims、backbone预训练方式、PV到BEV转换方法这些维度上对网络性能带来的影响。文章对MapTR算法的剖析角度和思考值得思考,局部在线建图离真正上车还有很多的路要走。

training维度的思考

1. 参与梯度更新的query绝对数量带来的影响
在DETR类的算法中使用匈牙利匹配 p π ^ ( ⋅ ) p_{\hat{\pi}}(\cdot) pπ^()实现GT(令GT的数量为 N N N)和Pred之间的匹配,再以此来建立回归约束,这个过程描述为:
L = ∑ i = 1 N L H u n g a r i a n ( p π ^ ( i ) , g i ) L=\sum_{i=1}^NL_{Hungarian}(p_{\hat{\pi}}(i),g_i) L=i=1NLHungarian(pπ^(i),gi)
在上述的过程中每个GT只会与一个query去匹配,那么也只有这些匹配上的query会回传梯度和更新网络参数,这样有效query的占比就比较少,导致网络整体不能很快收敛下来。而在MapTR中有permutation的操作,也就是将GT进行变换,原本只有一个的GT会按照某种假定的规则得到数量为 M M M的等效GT。也就是将上述的过程变化为:
L = ∑ i = 1 N ∑ j = 1 M L H u n g a r i a n ( p π ^ ( i , j ) , g i j ) L=\sum_{i=1}^N\sum_{j=1}^ML_{Hungarian}(p_{\hat{\pi}}(i,j),g_i^j) L=i=1Nj=1MLHungarian(pπ^(i,j),gij)
有了上述permutation的过程,实际GT的数量得到增加,那么对应query的数量也会增加,则有效query的占比就增加了,那么参与更新的query变多,梯度下降的方向更加具有方向性,收敛速度更快。那么由此观点出发,要是增加等效GT的数量是否能带来更多的性能提升呢?毕竟MapTR中是设置最大等效GT数量为 M M M,超过的会被舍弃(一些多边形上起点和方向的变化会导致等效GT数量超过设定值)。那么要是把完整等效GT数量称为full-set,在完备集合上的采样称为sub-set,那么比较这两个不同集合带来的性能影响:
在这里插入图片描述
其实,从上表中并没有看到full-set带来太多性能上的提升,那么是否说明到了一定的阈值之后再增加等效GT的数量并不能带来对应幅度的性能提升,也就是接近饱和了。将原本设置的query看作一组的话,那么增加组的数量(设置为 K K K)就不会带来更好的性能提升呢?(每个query组的计算过程相似且独立,infer的时候只保留一组query就行了,这样每次更新的query的绝对数量就提上去了),那么这样的匹配计算过程描述为:
L = ∑ k = 1 K ∑ i = 1 N ∑ j = 1 M L H u n g a r i a n ( p π k ^ k ( i , j ) , g i j ) L=\sum_{k=1}^K\sum_{i=1}^N\sum_{j=1}^ML_{Hungarian}(p_{\hat{\pi_k}}^k(i,j),g_i^j) L=k=1Ki=1Nj=1MLHungarian(pπk^k(i,j),gij)
那么增加组的数量对性能带来的影响见下表:
MapNeXt:Revisiting Training and Scaling Practices for Online Vectorized HD Map Construction_第1张图片
确实如结果所示,增加query的有效数量能带来性能上的提升。

2. qeury-pos的影响
在原本的MapTR中query-pos是通过torch.split()操作得到的,其本身是没有任何位置先验信息的,而query-pos是比较重要的信息,给它以明确的先验信息是能够提升网络的性能的。则比较query-pos的来源对性能的影响,文中使用initial location经过正余弦编码或是FC层得到具有先验信息的query-pos,其得到的性能比较见下表:
MapNeXt:Revisiting Training and Scaling Practices for Online Vectorized HD Map Construction_第2张图片
在query-pos中引入先验信息确实能带来性能上的提升。

scaling维度的思考

1. 增加FFN中dim的维度
往往为了计算开销会将FFN中的dim设置得比较小,但是现在的芯片都是大规模并行计算友好的,那么增加这里的维度是可以带来一些性能提升且FPS不会有太大波动的,见下表:
MapNeXt:Revisiting Training and Scaling Practices for Online Vectorized HD Map Construction_第3张图片

2. 各种backbone和预训练方式带来的影响
不同容量的backbone和预训练的方式会对网络的性能带来影响,其影响见下表:
MapNeXt:Revisiting Training and Scaling Practices for Online Vectorized HD Map Construction_第4张图片

3. PV到BEV的转换方法的影响
在给定的集合上其实是看不出IPM、BEVFormer、GKT这些BEV特征提取算法的优劣的,但是在实际环境中那些方法对环境变化的鲁棒性强弱是有差异的,这个会影响算法的选型的。

实验结果
与其它一些局部地图算法的比较:
MapNeXt:Revisiting Training and Scaling Practices for Online Vectorized HD Map Construction_第5张图片

你可能感兴趣的:(BEV,Perception,#,Lane,Detection,自动驾驶,计算机视觉)