自动驾驶BEV火了,再给它加点脑洞会靠谱吗?

作者|洪泽鑫
编辑|Bruce
百度今年Create大会上辅助驾驶板块的内容挺硬核的 , 不在这个行业内基本听不懂 。
正好是研究兴趣所在 , 结合百度给的资料 , 试着来中译中一下 。
总的来说 , 百度是弄了一个车路一体的BEV感知方案——叫UniBEV 。
做什么用?
简单理解 , 就是马路上现在都装了摄像头等传感器 , 百度借这个方案 , 想把这些设备都用上 , 让乘用车的辅助驾驶系统达到更好的感知结果 。
即便某辆车上装了有31个感知传感器 , 但也会有感知不到的物体 , 这时就可以把路边的传感器也都用上 , 让车拥有“千里眼” 。
先回到什么是BEV感知?
BEV是近几年车企和自动驾驶公司经常提到的词 , 全称是Bird'sEyeView , 可翻译为鸟瞰图 , 也被称为上帝视角 。
自动驾驶BEV火了,再给它加点脑洞会靠谱吗?
文章图片
用上图来理解 , BEV感知就是把多个视角的摄像头图像 , 统一通过公共的特征提取器 , 投影到同一个BEV空间里面 , 主要是两步:摄像头接收到影像 , 通过一个视觉神经网络的主干网络(Backbone)提取影像中的特征值(Feature);借助Transformer算法 , 把上一步得到的多个摄像头影像的特征值 , 放进一个3D空间里 。
这里又涉及到Transformer算法 , 这是一种传统用于自然语言处理——也就是机器翻译的算法 。
自动驾驶BEV火了,再给它加点脑洞会靠谱吗?】要想详细了解 , 可以看大神的这篇文章:https://zhuanlan.zhihu.com/p/552543893
文章里有个例子 , 当机器想把“一套自动驾驶解决方案”翻译成英文“anautonomousdrivingsolution”时 , 为什么算法会知道“一套”应该翻译成“an”而非“a”?“解决方案”应该翻译成“solution”而非“settlement”?
靠的就是Transformer算法 , 通俗点说 , 它能让句子中的每个元素都能“联系上下文” , 知道自己应该被翻译成什么 。
2021年之后 , BEV感知、Transformer都爆火了一把 。
自动驾驶BEV火了,再给它加点脑洞会靠谱吗?
文章图片
在BEV感知之前 , 传统的做法是分别算出每个摄像头图像的感知结果 , 然后再把这些感知结果拼在一起 。
假如有一辆小电动 , 但形状比较怪异 , 导致两个摄像头的感知结果不一样——一个觉得是只狗 , 一个觉得是台电动车 , 就得靠人类程序员制定规则 , 来下个定论——比如程序员觉得XXX情况下这肯定是只狗 。
BEV不需要上述这个人类插手的过程——也是容易犯错的过程 , 所以可以真正做到“数据驱动” , 理论上收集的数据越多 , 感知越精准 。
自动驾驶BEV火了,再给它加点脑洞会靠谱吗?
文章图片
百度之前就是用的传统的方式 , 上面这张图表示的是一个单目摄像头 , 再加上多个环视摄像头的后融合技术 。
每一个不同朝向的相机 , 会各自先经过一个神经网络去推理出周围的障碍物位置、大小、朝向等信息 , 然后再把他们拼在一个3D空间里 。
2019年 , 百度对标特斯拉做的纯视觉智能驾驶方案ApolloLite用的就是这个技术 。
虽然百度当时单个相机的深度学习感知已经做得很牛——单相机的3D感知信息都可以通过模型来输出 , 但有些被截断的物体也是识别不出来的 , 而且没有其他相机的数据作为“上下文” , 也不好猜 。
百度想把BEV玩出花儿来
过去的一年 , 百度首先也把视觉感知升级成BEV感知了 。
可以检测到障碍物 , 预测障碍物的轨迹 , 以及感知道路结构(车道线、马路边缘等) 。