【BEV系列（2）】BEV-LaneDet：一个不使用Transformer架构，易于部署的BEV车道线检测算法

论文：https://arxiv.org/abs/2210.06006
GitHub：GitHub-gigo-team/bev_lane_det

1. 概述

介绍：这篇文章是毫末智行在单目场景下在bev视图下实现车道线检测的方法，其车道线检测的基础方法是源自于bev视图下车道线分割，再通过预测几个附加预测头用于辅助后处理。具体来讲创新点主要有三点：
（1）使用MLP进行2D特征到3D BEV特征的空间转换（为了方便部署，没有使用Transformer和Ray的方法）
（2）使用虚拟相机（因为步骤一的缘故）
（3）3D车道线文检测头：车道线语义分割（confidence）+ 预测车道线偏移量（offset）+ 车道线实例辅助信息（embedding）+ 车道线高度信息（height）

2. 方法设计

2.1 整体pipeline

这篇文章的算法整体流程见下图所示：

2.2 2D feature -> 3D BEV feature

为什么选择MLP作为空间转化（VPN，VRM）
这有两点原因，一是部署方便，二是效果比较好。
实际上我么在开始的时候优先选择 基于transformer的方法（BEVFormer，PersFormer等） 和 基于ray的方法（LSS，Fast-BEV等） 等思路，然而发现这两个方法对于车道线检测这种静态的任务效果并没有那么理想。而且更加重要的是，这两个算法相当吃芯片，具体来说有的芯片支持，有的不支持（或者支持的不友好）。此外这两种算法一般转化到BEV后的feature 分辨率一般比较大，通常需要下采样再上采样，计算量也挺大的。

2D特征到BEV实际是坐标的转换，在这篇文章中使用全连接的形式实现坐标转换，同时还使用了多个尺度的特征作为信息来源。其过程见下图所示：

在上图中画了3个VRM（View Relation Module），而实际上使用了两个（分别是stride为32和64的特征），使用这么小的分辨率是因为对网络来讲更好学习。那么通过全连接形式得到的bev特征描述为：

2.3 虚拟相机 virtual camera

为什么使用Virtual Camera 呢？ 和特斯拉在它的AI Day上发布的Virtual Camera 不一样，我们是被逼出来的。正如前面所说的，作者决定用VPN这样的空间转化模块，但是VPN不能够和好的融入相机内外参数，因此作者决定效仿STN在模型的预处理部分进行空间统一化。这样一来模型就不再关心相机内外参数。

2.4 BEV下车道线检测（Key-Points Representation）

在3D车道线预测部分采用的是类似YOLO的检测方案，其包含了预测是否为车道线 （confidence）、距离具体车道线的偏移（offset）、车道线实例信息（embedding）和车道线高度信息（height of lane）。对于其中的前三个其预测流程见下图所示：

confidence

这里使用二值分割描述对应bev grid是否为车道线上的点（bev上的某个grid），使用交叉上损失进行监督

offset

这一项代表的是车道线上的点（bev上的某个grid）中心距离车道线的偏移量，这样可以更加准确预测车道线的未知，避免量化误差。

embedding

在得到车道线基础上还需要得到车道线的实例信息，对此这里参考LaneDet中的方法使用embedding的方式学习线的聚类信息。首先需要拉近同一根车道线的特征表达：

再拉远不同车道线的特征表达：

之后将两者损失组合起来：

车道线的高度（height of lane）

以上过程得到的车道线都是在切平面Proad​ 上的，对此还需要计算其高度偏差

最后总的信息是上述bev下车道线和 2d下车道线检测的组合形式。过这里有一点是没有对车道线的类别进行分类。上述一些变量对性能的影响见下表：

3. 实验结果

OpenLane数据集上的性能表现：

可视化：