一、前言
2022年结束了，这一年，自动驾驶行业的关键词是“落地”，在疫情、国际封锁、战争的大背景下，资本对自驾研发周期的耐心越发稀薄了。我们看到无数曾经的明星企业轰然倒塌，我们看到无数的L4研发团队，转头去研发L2。大家心里只有一个想法：落地，活下去。
但同时，我们也看到，技术的进步并未停滞，transformer、bev，一项又一项的新技术不断涌现，不断打破过往的架构和认知，并且以极快的速度变得越来越快，越来越好，自动驾驶迈向成功的脚步从未停止。
作为自驾行业的一名从业者，谨以此文记录一下近期的工作和思考。
二、2d 车道线检测
车道线检测是我的老本行了，从最初的传统视觉方法做起，到后来深度学习的方法，不知不觉已经做了六年了，期间发布了约有四个大版本了。
现在2d车道线检测算法已经很成熟了，随便一个开源项目，就可以在各种开源数据集上以极快的速度跑出很好的效果了。
但是聚焦于“落地”，现有的2d车道线算法还有两大难题：
- 车载运算芯片对算子的限制
- 真实车道线的复杂场景
对于第一点，目前除了英伟达系列的芯片，其他的如德州仪器、地平线等厂家的NPU，支持的算子大多还停留在两年前，比如笔者部署的德州仪器TDA4，只支持最普通的卷积、池化等操作，最新的一些算法基本上就不能部署了。当然如果有高端最新的芯片，那自然不是问题了。
对于第二点，才是车道线识别的瓶颈，目前的车道线检测算法，虽然在开源数据集上能跑出很好的效果，但往往因为算法本身对车道线的先验假设，在现实的复杂场景基本就嗝屁了。退一步讲，就算算法对于各种场景都支持，车道线难例的长尾分布太大了，有各种乱七八糟的颜色、线型。而收集、标注大部分的难例，也几乎不可能。所以对于尝试检测所有场景下的车道线，我持悲观态度，目前最优解还是限定使用场景，在此基础上设计网络，让神经网络尽可能多的支持各种场景下的车道线。
笔者参考了RCLane、PINet、CondLaneNet的思想，结合这些年的一些经验，设计了一种车道线检测网络，能够支持各种线型、各种朝向的车道线的识别，并且仅仅使用卷积、池化等最普通算子，在TDA4上以30fps以上的速率运行，支持后端的规控控车。
目前已经申请专利了，后续有机会和大家分享。
三、车位检测
车位检测是临时接到的任务，做了一下调研，读了一些paper，发现也是一个很成熟的领域。
车位检测主要应用于自动泊车功能。相比于自动驾驶，自动泊车要更容易落地得多。自动泊车也有相当多的厂家在做，而且早就有很多落地的产品了。
自动泊车主要的难点还是在停车位的感知上，后续的规控相对很成熟了。早在深度学习问世之前，就有不少高端车型搭载了自动泊车功能，当时主要是利用超声波雷达来感知停车位，要求停车位前后都有障碍物，才能探知停车位位置以执行自动泊车。现在各家基本上都使用相机来检测停车位，做出的效果也良莠不齐。
笔者结合硬件特性，参考现有的算法搭建了一个模型，仅用卷积、池化等最普通的算子，能在地平线J3上以15fps运行，当然目前还未进行运算速度优化，预计提升到30fps不成问题。
拿小批量数据训练了一个模型，效果如下：
图像识别部分本身并没有什么难度，在测试集上很容易做到90%以上的指标，但是要落地还是有不少难度的，主要体现在一下两点：
- 测距重建模块
- 复杂的场景
对于第一点，目前大多数方案是先把各个环视相机图像通过IPM转换再拼接，转换成完整的俯视图再进行识别并测距的，本身这套转换测距精度就不高，距离相机越远，误差越大，再者这套转换是强依赖相机标定的准确度的，如果标定不准，或者车身颠簸，俯视图就会强烈变形。
如果说因为泊车场景是低速、平地场景，所以测距精度低、颠簸变形问题可以接受的话，那么IPM本身导致的俯视图畸变问题，则会对车位检测的图像识别模块带来致命的干扰。
图像识别模块输入是通过IPM以及拼接转换后的俯视图，但是因为IPM先验条件是平面到平面的转换，而前视图中往往有大面积的不在地平面上的车辆、柱子、墙壁等物体，所以就导致转换后的俯视图受干扰严重，可能俯视图中50%以上的面积都是变形的车辆、柱子等像素，这样的俯视图中的停车位，往往人类都无法辨认。让图像识别模块来检测，也很困难。
当然现在也有很多其他架构的车位检测算法，比如下面要介绍的BEV感知架构，就直接从各相机图片中读取要素信息并融合，端到端生成车身坐标系下的检测结果，避免了这些问题。
第二点，能否适配各种复杂的场景，则是自动泊车效果好坏的关键了，或者可以说是所有数据驱动的神经网络算法好坏的关键，停车位也同样有各种千奇百怪的样式，目前现有的自动泊车产品在标准清晰的停车位表现的都还不错了，但是遇到比如地砖颜色不同做车位线、甚至无车位线的场景，基本都要嗝屁了，我的态度还是和车道线检测一样，在通用人工智能时代到来之前，务实的做法还是限定场景，把80%常见的场景做好，不要好高骛远，一上来产品规划定义的时候，就要一口吃个胖子，那样会白白浪费很多资源和时间。
更新：
笔者修改了一下模型，新添了一些数据，目前在常见的停车场场景，模型的鲁棒性还不错了，开放测试效果如下：
四、BEV感知
BEV架构在近几年是百家争鸣，对于BEV在项目上的优缺点，这里引用一下带我入门的师傅 @Captain Jack 的文章：
BEV感知架构和传统的融合方案相比，结构简洁优雅，稳定和效果都有很大提升，主要问题在于：
- 硬件支持
- 数据需求
对于第一点，目前大部分NPU都不支持现有的BEV算法使用的算子，正如前文所言，现在很多加速器甚至仅能支持最最基础的卷积池化等操作。但是基于目前BEV的热度，我相信用不了多久，就有更多的加速器支持这些算子了。就算预算有限，需要现在就在这些加速器上部署，最近也涌现了越来越多的纯CNN的部署友好的BEV方案，效果也不错了。
对于第二点数据问题，我认为是最难的问题，这个难有两点：
其一是标注难，相比于2d图像标注，所见即所得，BEV的数据要在空间上标注，标注的成本是成指数级增加的，目前大多数公司使用激光点云辅助标注，这又另外增加了数据采集的成本和难度。
其二是数据需求量大，现在的方案不管是transformer还是MLP，都对数据量有非常大的要求，同时因为绑定硬件标定参数，augmentation很受限，就导致模型非常容易过拟合，我自己的实验是，数据集已经一万多了，模型仍然过拟合，而2d车道线检测模型，在一万多数据集时已经有非常好的鲁棒性了。
对于数据需求的两个难点，我们需要一个低成本、高精度地能生成大量数据的方法。
我在下半年开始着手，利用项目间隙和下班休息时间，用高精地图生成BEV车道线数据集，并参考了BEVFormer、DETR、MapTR等，搭建了一个简单的BEV车道线感知模型，训练出来效果还不错，以下是模型在市区、高速场景下的验证集上的效果（目前数据集场景还比较单一，验证集由总数据集采样得出，算是封闭测试的效果）：
注意：
测试条件为：总数据集抽帧80%作为训练集训练模型，其余20%作为验证集验证模型。以下视频是模型在该验证集上前向得到的结果，也就是封闭测试。
模型是明显过拟合的，做过深度学习的同学都知道过拟合以及封闭测试的含义，笔者做这个实验仅仅为了验证利用高精地图制作数据集的可行性，以及测试模型的能力，不代表模型在其他场景也能达到这样的效果。
后续有机会的话，在公司允许的前提下，笔者会放出模型给大家实验。
市区测试效果：
高速测试效果：
真值是利用高精地图、高精定位数据自动脚本生成的，环视图像是很久以前的历史数据，并没有为BEV数据单独适配。因为不需要人工标注，理论上只要有图像和定位信息，就可以快速生成无限的数据集。
同时模型纯视觉作为输入，可以端到端输出矢量化的车道线，无需复杂的后处理。
模型使用了transformer，在车载低性能设备上部署还有难度，但是在服务器上能跑到18fps（3090GPU）可以用来自动成图，自动成图效果如下：
至此，这条路算是走通了，后续还有很多的工作要做：
- 提速并把模型部署到Xavier、Orin等算子支持比较全的板子上
- 尝试替换transformer BEV模块，使其可以部署到普通的低端板子上
- 生成更多的数据集，训练模型（进行中）
- 加入停止线、斑马线、箭头等要素，增加模型检测的能力
我坚定地认为，前融合架构是未来的趋势，正如深度学习淘汰了人工写特征提取的传统方法那样，以BEV架构及其变种为代表的前融合架构，早晚要淘汰人工写策略逻辑的后融合，只是现在时机未到。
五、尾声
作为从业者，我们见证了曾经行业繁荣时的蒸蒸日上，也见证了如今行业寒潮下的荆棘丛生，我们只是一粒沙，往往被资本的洪流裹挟而身不由己，无论是研究着最前沿的算法，还是写着枯燥的 if-else，这些都是成长，都是重要的经验。
重要的是，作为技术人，那些浮躁的大话不应出自我们之口，要以求真务实地态度，踏实地完成眼前的工作，同时也别忘了空闲时间看看前沿的技术，一步一步地实现曾经的理想。
共勉！