客户端
游戏
无障碍

0

评论

收藏

分享

手机看

微信扫一扫,随时随地看

重温Tesla基于Transformer的BEV实现

==卷首语===================
自从去年9月份的Tesla AIDay 2022以来,BEV和基于Transformer的BEV技术一夜走红。不仅仅出现在纯视觉的感知协议堆栈方法中,也出现在Camera +Lidar的混合感知协议堆栈方法中;不仅仅出现在标准的道路行驶自动驾驶视线中,也出现在以Fisheyecamera为基础的AVP代客泊车场景中。业内各种主流实践方法慢慢趋同,小编相信基于Transformer的BEV技术,逐渐将进入比拼数据质量、规模和训练方法的新阶段。
===================车右智能==
写在前面的概念:
投影平面视角:也叫做Perspective view视角和Pixel panelview像平面视角,是指自动驾驶系统中,光学摄像头直接在其自身的CCD感光阵列上所拍摄出的2D平面视角。投影平面视角上基于像素的信息量丰富,但缺乏场景的深度信息;
BEV视角:也被称作俯瞰视角,是一般自动驾驶系统中,规划和控制系统的标准输入。在大多数的规范道路环境下,属于带有深度信息,但不带高度信息的2D平面视角,通常对于规控系统来说够用;
感知矢量场:可以被理解为主车周围带有高度信息的完整道路和道路参与目标的3D完整状态,是一个理想的感知结果,但不包含被遮挡空间的道路和目标状态。
Level-2系统中的视觉感知
在早期的自动驾驶辅助功能/Level-2(含以下级别)集合中,以视觉信息为基础的自动化驾驶应用,有相当一部分就是体现在对于公路表面的各种车道线的检测上,其他类型的车载传感器无法做到对于可视目标物的观测。具体包含:
1 L0中的LDW:Lane Departure Warning,车道偏离预警;
通过摄像头检测前方车道线,计算出车身与车道线之间的距离,判断汽车是否偏离车道;在驾驶员无意识(未打转向灯)偏离原车道时,系统能在偏离车道0.5s之前发出警告或转向盘开始振动,提示驾驶员回到本车道内,减少因汽车偏离车道引发的危险;
2 L1中的LCC:Lane Centering Control,车道居中控制;
采用前向雷达与前向摄像头探测道路环境中的车道线及前车的行驶轨迹线,规划出自车应正确保持的行驶轨迹(路径),通过对转向系统的主动干预控制自车按规划的轨迹(路径)行驶,从而减轻驾驶员对转向控制负担;
3 L1中的LDP:Line Departure Prevention,车道偏离辅助;
利用前向摄像头检测车道线,在未打转向灯的前提下,如车轮即将压线或已经压线,通过施加校正性转向干预并进行提示,辅助驾驶员保持车辆在本车道中央;
4 L1中的LKA:Lane Keep Assist,车道保持辅助;
在驾驶员注意力不集中或疲劳驾驶出现车辆偏转时,系统进行主动修正、转向干预,当检测到驾驶员操作转向信号灯时,系统进入被动模式(关闭模式),LKA实际包含了LDW、LDP和LCC三项功能;
5 L2中的TJA:Traffic Jam Assistance,交通拥堵辅助;
指在车辆在沿车道线行驶时,诊断到车道线发生丢失时。跟随前车的行驶轨迹行驶,直至车道线再次识别,TJA功能将切换回LCC。TJA的工作车速范围为: 0~60km/h;
//以上的ADAS类的功能汇总信息输入来自于公众号“自动驾驶之心”的相关文章,有兴趣的读者可以去关注这个账号。
其实小编还是不太习惯这些对于自动驾驶/辅助驾驶能力,在应用上的细分或者切片。但考虑到车辆传统的电器架构以及历史发展沿革,这样做可能也是传统车辆制造巨头,和其身后庞大产业链合作的唯一选择。毕竟不是谁都可以像Tesla一样具备这种没有历史包袱,从零开始发展的机遇。在这些辅助驾驶的细分功能中,车辆横向控制的子功能大多数都和摄像头及视觉感知能力直接相关,而纵向控制的子功能大多依赖毫米波雷达和新锐的激光雷达技术(视觉也是极其重要的补充)。对于当下这个ADAS辅助驾驶的自动化阶段来说,横向控制——视觉的紧耦合关系,落脚点还是公路表面上广泛存在的车道线和各种标记线。
譬如,在车道保持Lane Keeping Assist的功能基础上,再匹配上以视觉信息和雷达探测信息联合处理结果为基础的车辆自适应巡航Adaptive Cruise Control能力,基本上在固定和规则的场景下,比如高速公路的固定车道上,就可以长时间解放驾驶员双手和右脚了(小编:司机切记,Level-2无法解放驾驶员注意力)。在这个时期,Level-2所定义的车辆自动化驾驶的功能边界和人类司机的注意力边界,之间的切缝还是比较清晰的,什么场合人能放松,怎样程度的放松,什么东西又不能放松,甚至不满足边界条件的前提下Level-2功能也无法激活……这种“保守”和“谨慎”,令迄今为止大范围的Level-2驾驶自动化部署,基本表现出Level-2这个自动化程度对于人类司机的平均驾驶素质来说——总体安全。
当然,我们今天主题的关注点并不在于此。而是在于,为什么自动驾驶系统对于视觉信息的利用在早期的Level-2及以下的应用场景——至少在若干个核心应用LKA、TJA和ACC下,表现出了靠谱的支撑。但当自动化驾驶程度再试图往高阶迈进时,对于视觉信息的利用就显得笨手笨脚、左支右绌,而不得不依赖昂贵复杂的多传感器融合方案呢?
图片
图一【BEV-1.png】来自leju.com报道文章“河源紫金桥正式通车”新闻稿插图,获取URL:https://m.leju.com/news-hb-6749888859540363853.html;
图1所显示的就是在标准的封闭高速道路条件下,Level-2系统的车载前向摄像头对于车道线和路面环境(包括障碍物)的识别场景的一般条件。不论是利用传统的光学处理方法,还是基于深度学习的视觉处理方法,都可以保证目标清晰和识别稳定。被识别出的车道线虽然在摄像头的投影平面上(Perspective view)呈现出倾斜交汇于路面中心无限远的一点,但实际上车辆自动驾驶域控制器(Level-2 Domain Controller)完全可以忽略这种投影规律,而直接将其等同于具备标准车道宽度的平行直线(小编:视角的转换关系直接、明确且简单)。在这种场景下,负责自动驾驶的域控制器并不需要特别复杂的视场转换处理算法来对抗投影平面上的“交叉线”,直接处理成理想状态的直行车道,并配合车载雷达识别的前端目标车辆距离和速度真值,就可以完成接近完美的LKA+ACC=Level 2自动驾驶任务了。
这只是视觉处理车道线的一个范例,但读者也许已经明白了,早期的Level-2级别辅助驾驶系统之所以在商业上成功,最主要的就是广泛部署的车载传感器能力(小编:Camera+mmRadar上车适应性好、稳定且便宜)和车载自动驾驶计算能力(小编:域控制器无需执行需要高算力的视场转换任务),在严格的适用场景限定下(小编:封闭道路、跟车或者自适应自主直道巡航),可以相当好地彼此契合。这其中最核心的部分其实还是“感知”部分——尤其对于车道线的视觉感知任务相当之简单,几乎不需要执行复杂的视场转换计算,在相机投影平面上的识别结果可被快速的、低成本的利用。这就是Level-2系统可以单纯依赖Camera和Radar,且无需高算力的原因。
以上讨论并不能代表当下流行的Level-2+或以上的自动驾驶范畴,实际上小编也不是非常了解现在各种各样的Level-2+技术边界到底在哪里了。总体感觉是,只要有助于车辆销售,增加客户吸引力,什么样的功能都能往Level-2+这个框里塞。一些新造车势力,甚至把明天的功能都拿到今天来卖了:比如在当下出售的车辆上,Lidar传感器位置在车体上已经提前预留,以后软硬件进入成熟期后再免费升级……这种策略下,Level-2+的功能边界变得模糊,消费者对于自动驾驶的理解和把握都出现认知误区,也就不难理解为什么总会出现边开车边放心看手机从而引发恶性事故的案例了。
回到我们今天的话题线索,从Level-2+再往上的高阶自动驾驶,视觉识别子系统,显然就不能满足于简单的车道线识别任务了……
高阶自动驾驶系统中的视觉感知
图片
图二【BEV-2.png】来自sohu.com报道文章“如皋大润发转盘即将大变样”新闻稿插图,获取URL:https://www.sohu.com/a/472962461_693945;
随着自动化驾驶落地应用场景不断延伸,当从高速公路单一场景迈向在城市更为普遍的道路环境时,就会出现各种各样复杂的感知需求。如上图2,城市环岛为例,尤其在国内随处可见的大型环岛。当处于交通流量高峰时期,自动驾驶系统对于道路环境的感知难度会呈几何级数上升。设想身处其中的一辆自动驾驶车辆,它需要感知:
1道路前景和背景的区隔——以道路上街沿为界限;
2道路前景范围内的布局——机动车道(顺向和对向)、非机动车道和行人道;
3顺向道路范围内的车道结构——车道数量、转弯车道、车道线性质;
4道路范围内的信号设施——信号灯、道路标识牌;
5道路范围内的合作使用者——静物、动物;
……注意这其中最大量的感知需求还必须是依赖视觉感知系统。
不具备以上感知能力的Level-2自动驾驶系统,穿越图2这样路况的环岛是不可能的。即便依赖预制的HDmap和车辆自身具备的高精度定位能力可以缓解一部分即时感知任务的压力,也不能从根本上简化City Road的感知难度。
我们依然选择参考重度依赖视觉感知能力的Tesla,其Autopilot系统的技术演进过程很好地解释了什么样的视觉感知能力,才是高阶自动驾驶系统所需要的。(小编:当然,Autopilot系统在历史上同样频繁发生重大的交通事故。一方面证明消费者在Tesla和Elon musk的光环下对于Autopilot期望过高,直接导致不能正确使用;另一方面也说明Autopilot系统虽然在逐步迈向高阶自动驾驶,但过程坎坷,未来能力天花板能否达到Levlel-4,仍存疑。)
Autopilot中的视觉感知系统的进化
Notes:本章节内多数的插图可能读者都看到过,但系统地以时间轴来审视这些系统级别的变化,可能很多读者并未考虑过。
图片
图三【BEV-3.png】来自2019年AndrewKarpathy技术演讲截图,历史图片,获取URL不详;
图3显示了在2019年,Tesla Autopilot第一次公众技术展示时所呈现的视觉深度学习堆栈。图中左侧展示了Tesla全系列车型所标配的视觉传感器命名,Main—主摄像头,Narrow—遥距摄像头,Fisheye—广角摄像头,Repeater—车头侧边回视摄像头,Pillar—车侧摄像头,Back—后视摄像头,共8个。其中一个细节:我们可以肉眼观测到,前向的Fisheye和后向的Back摄像头因追求视角宽广,成像平面上的畸变比较严重,和其他摄像头差异较大。图3中右侧的视觉感知深度学习模型中,从底部往上描述了Autopilot的感知模型。这是业界标准的“主干Backbone+肩部+头Head”模型架构,在Backbone位置提供对所有摄像头输入内容的通用CNN特征处理,然后再根据具体的感知任务的差别,对涉及的摄像头特征数据做具体模型训练和识别。图中顶部的细分业务包含:moving objects动态物体识别、static objects静态物体识别、signs信号标识牌和路面信号涂装识别(包含车道线)、traffic lights信号灯识别。
这就是早期Autopilot的HydraNet,也叫九头蛇网络。它的特点在于,从自动驾驶的感知任务角度看,可以做到在“特征”层面上感知具体任务所涉及的多摄像头的数据。但这种“复用”并非地理层面上的复用,而是通过感知模型的组合(CNN的分层组合网络结构),以具体任务为单位,实现对于各摄像头视觉特征数据的数学复用。以图3举一个例子吧,以对signs——各种道路标识的识别任务来看,这个任务主要用到了Pillar车侧摄像头和Fisheye车前Fisheye广角摄像头数据,在这两个传感器提供的视觉信号中挖掘视觉特征进行训练,从而获取对于各种道路标识,比如在道路路口广泛存在的Stop sign标识牌的识别能力。
但很快,在随后Tesla的新业务演进中,这种方法所提供的识别能力,逐渐不够用了。
比如在Smart Summon智能召唤任务中,车辆需要在没有人类驾驶员的情况下,在封闭停车场内完成低速的自主行驶。这种任务对于道路结构中车道线和道路边界(可行驶区域)的识别需求有了更高的要求。不是所有的停车场都具备清晰和完整的道路线,因此这种对于可行驶区域的识别要求往往体现在语义级别上。例如,停车场地面上并没有车道线,或者大家的车辆没有严格按照车道线和车位停泊,因此车辆本身的排位和所构成的地面通行通道区域,就是可行驶区域。如下图:
图片
图五【BEV-7.png】来自摄图新视界图片,非商业用途,获取URL:https://xsj.699pic.com/tupian/0rnhpk.html;
图5环境中,自动驾驶车辆不能说地面没有车道线就无法实现自主驾驶或者自主泊车业务AVP,可行驶区域在这种条件下,几乎完全是由已经入场的车辆边界所构成的。这就要求主车自动驾驶系统的视觉识别系统必须能够在语义的级别上、类人地去解释为什么可行驶区域存在于车辆之间,哪里可以走?哪里可以停车等等一系列问题。当然,也存在大量道路标识良好的停车场内部道路结构,如下。这两个场景条件对于场内低速自动驾驶能力的需求,显然是不一致的。
图六【BEV-6.png】来自荆楚网www.cnhubei.com网站评论文章《荆州红门路停车场正式开放》,非商业用途,获取URL:http://www.cnhubei.com/content/2022-02/09/content_14483821.html;
不论图5还是图6,车辆在停车场内实现自动驾驶的前提都是,对于停车场内部可行驶区域的感知和认知,应该是全面的、准确的。如果Tesla依然沿用早期基于分层CNN网络的特征融合技术,显然是不够用的。
因此,下图7中所显示的在俯瞰角度下的“地理位置级别的视觉信号复用”技术浮出水面。这里一共涉及了六个摄像头数据的组织和处理(不包含后视backup摄像头数据):经由专门的Fusion Layer将六个摄像头的数据,进行“拼接”处理,再经由Temporal module时序模块处理。获取拼接之后的时序视觉数据后,需要注意的是,此时的拼接后的时序数据依然是在投影平面上的视觉数据格式。动静物体的距离、场景的深度信息在2D的投影平面感知结果上并不能得到有效呈现。因此,需要专用的BEV网络来提供从投影平面到BEV平面的视角转换。
图片
图七【BEV-4.png】来自2020年AndrewKarpathy技术演讲截图,历史图片,获取URL不详;
上图7中的BEV Net的功能和原理细节不清楚,最近两年各种各样实现BEV的深度学习方法也确实比较多了,相关分析文章最近一段时间在互联网上到处都是,我们就不做深究了。但当完成BEV俯瞰网络任务之后,我们就得到了类似上图7右下角的矢量地图。然后在这个基础之上,基于BEV Net的俯瞰视场数据格式,为满足Smart Summon的需求,提供了三个任务:Moving Objects、Road Lines和Road Edges的识别。即,提供在俯瞰角度下的道路边界、道路线和运动物体的识别和显示。这些BEV的感知结果,将直接提供给规控模块,让车辆在低速度条件下完成自我控制。
读者应该理解这两个阶段的差别了,大的识别模块在投影平面内还是俯瞰平面内给出识别多任务输出结果,效果必然迥异。
Transformer网络浮出水面
在2021年之后,基于多视角摄像头的3D目标感知以及在鸟瞰图下的表达(Bird's-eye-view Perception, BEV Perception)吸引了越来越多的注意力。一方面,将不同视角在BEV下统一与表达是很自然的描述,方便后续规划、控制模块任务。而且符合第一性原理,有证据表明人类处理视觉信息,尤其在路径规划时,即是在BEV视角下;另一方面,BEV下的物体表达没有投影平面视角下的距离尺度问题和遮挡问题。因此,如何快速、优雅地得到一组BEV下的道路和目标特征描述,是提高视觉感知性能的关键。在上一节提到的Tesla虽然利用BEV Net涉足俯视图转向领域(参考图7方案),但彼时的技术形式一定不是由代表性的Transformer实现......直到2021年夏天Tesla的AI Day活动上,Karpathy才给出了下面这张大家耳熟能详的识别框架图。
图片
图八【BEV-5.png】来自2021年AndrewKarpathy在AI Day上的技术演讲截图,历史图片,获取URL:https://www.youtube.com/watch?v=j0z4FweCy4M&t=4380s;
图8这张架构图,在很长一段时间以来,在业内是焦点问题,被无数文章分析和讨论。原因之一是因为Transformer作为AI界的当红炸子鸡,被另一个当中炸子鸡企业开创性地规模试用,本身就是一件值得关注的技术实践;原因之二也是因为在2021年Tesla AI Day上,Karpathy欲言又止地谈到Transformer这个新的计算结构给BEV视场构建所带来的突破性进展,确实那个现场也没怎么讲清楚。即便结合当时公布的图8,在技术上也有很多不确定的地方,这就留下了讨论的伏笔。小编记得那次AI Day后不久,在知乎上看到一个业内同样也是从事感知任务的技术人士兴奋地表示:看了Karpathy的演讲,确实很受启发。Transformer用于自动驾驶领域的视觉感知任务,似乎被捅破了最后一层窗户纸。他所服务的公司已经开始重新讨论感知架构,而且他深信国内会有大量的视觉感知架构会向类似结构上迁移……
过去的这大半年,小编觉得,他说对了,看看现在的BEV网络的各种变种,和Transformer普及到什么程度了~~~
以上图8中,先看整个架构的一头一尾两端。顶部的头部Head任务——Vector space Road edge说明这个感知网络的任务是感知矢量空间内的道路边界,即道路边缘也就是我们常说的“可行驶区域”。因为考虑到Tesla在视觉感知任务取得进展之后,在2021年夏天取消了车载毫米波雷达传感器,所以基于视觉的感知架构不可能只有这一个任务Head。而架构的尾端,也就是整个架构的信息输入源是来自于三个摄像机,包括:主摄像Main、Pillar(车侧的摄像机)、和Repeater摄像机(前翼子板),这三个摄像机提供整个网络的视觉输入信号源。下图中黑色线条所勾勒出来的空间,即为这个Road edge任务方案的视觉感知范围,基本上是一个宽度160m,长度150m的范围:
图片
图九【BEV-8.png】来自eetasia.com的文章《Teardown:Tesla’s Hardware Retrofits for Model 3》中的插图,有后期加工,获取URL:https://www.eetasia.com/teslas-hardware-retrofits-for-model-3/;
图9显示的这个空间范围虽然不是360度连续空间,但对于Road Edge这个任务来说足够了。当车辆沿着轴线前进时,道路上的车道线、道路结构等目标信息会逐一落入main视觉范围,再从前到后随着车辆前进而逐步先后落入Pillar和Repeater camera的感知区域内。如果从时间轴和空间轴两个角度说,目标物体在自动驾驶系统的计算资源内,浮现和处理都将是连续的。这种目标物体在Autopilot系统内所具备的时间和空间上的连续属性,将有助于Transformer结构的上层应用,对目标物体的进行跟踪,以进一步提高识别的准确性。
图片
图十【BEV-9.png】来自eetasia.com的文章《Teardown:Tesla’s Hardware Retrofits for Model 3》中的插图,有后期加工,获取URL:https://www.eetasia.com/teslas-hardware-retrofits-for-model-3/;
除此之外,三种摄像头在物理空间上的覆盖重叠区域也很重要。上图10当中读者可以观察到main、pillar和repeater camera之间的重叠区域客观存在。如果自动驾驶系统在相机得到精确校准的前提下,掌握每个地理相邻摄像机在像平面Perspective view上的重叠区域时,相当于自动驾驶系统掌握了部分“先验”信息。即便这种先验随着车辆的使用寿命而逐渐失准(小编:这是个人推测,车辆使用寿命越长,相机校准的精度就越差),但后端算法是可以弥补的,我们在BEVformer的算法上也明确地看到了这一点。这对于BEV网络算法实现从像平面到俯视平面BEV的视场转换以及(特别是)相机之间的信号fusion计算,大有裨益。
让我们回到图8架构中,三种5部摄像机所提供的Raw data经过下半部的CNN Backbone Network后,被处理为Multi-scale features后得到存储,等待后续进入Transformer处理。Transformer网络在这里的任务是明确的,如下:
1融合5部摄像机的feature,输入时是独立的5路视觉信号,输出是1路接近360度的连续feature map;——镜头缝合层
2将5路视觉信号的Perspectiveview投影格式,转换为BEV鸟瞰格式。——视场转换层
以上两个任务实现时没有时序上的先后,都是在Transformer的过程中同步完成的。如同图8中Transformer那一层的标识信息——Image to BEV transform + Multi-camera fusion。
关于Transformer的原理和技术框架,互联网上已经太多相关参考信息了,也不是我们本篇文章的讨论焦点,我们假设读者都已经理解什么是注意力attention机制,这里就不再深入涉及了。但Transformer在整体Tesla视觉感知架构中的作用——对于什么样的输入信息做了何种计算,再产生什么样的输出?这是我们无法回避的问题,也是虽然我们之前已经提供了好几篇关于Transformer的文章,互联网上的各种解读和参考更是一大堆,但始终感觉差点意思,且话没说清楚的原因。
我们先再看整体的感知架构:
图片
图十一【BEV-11.png】来自Karpathy在2021 Tesla AI Day中的演讲插图,获取URL:https://www.youtube.com/watch?v=j0z4FweCy4M&t=4769s;
图11的整体架构中,Transformer层的I/O在公开资料中并没有直接描述,我们需要自行分析。Transformer将投影平面下的初级感知结果——Multi-scale feature(请参见图8,在描述端到端的整体架构中,图11将其作为中间结果而忽略了),送入Transformer执行视角转换操作和多摄像头融合操作,此为Transformer的Input;当其离开Transformer层,进入RNN为基础的feature queue队列处理时,此刻其实存在BEV视角下的特征层,其对应Transformer的输入,只是完成了拼接和视角转换计算,此为Transformer的Output。虽然我们看不到Output的具体形态,但当这些特征数据进一步被Spatial RNN架构处理之后,我们就可以看到可视化的输出了,如下图:
图片
图十二【BEV-10.png】来自Karpathy在2021 Tesla AI Day中的演讲插图,获取URL:https://www.youtube.com/watch?v=j0z4FweCy4M&t=4769s;
上图12的可视化特征图,在图11中即为“BEV视角下具备时间连续、地理连续的特征输出”。这个位置的特征数据呈现其本质和Transformer的output没有太大差别,只是多了时间和空间上的连续尺度的表达方式。Karpathy所介绍的图12中的十五种特征数据,是主车通过一个丁字路口的表现。这其中有围绕“车道中心线”、“地形结构”、“车道绿化带”和“车道线结构”等等的连续特征数据。读者可以自行分辨哪些是我们在本例中最关心的车道线特征。
所以当理解Transformer层的output时,我们可以将图12中的涉及“车道线结构”的特征挑出来,并消除时间和地理的连续性,就可以理解Transformer的产出结果了。很可能的情况是,描述车道线的特征可能不是一种,从底层CNN的卷积核特征开始,到Transformer,都有可能是一组,一起通过大量训练被用于精细刻画并转移这些车道线特征。这是需要Transformer + RegNet(CNN)所协同完成的。
图片
图十三【BEV-12.png】来自Karpathy在2021 Tesla AI Day中的演讲插图,获取URL:https://www.youtube.com/watch?v=j0z4FweCy4M&t=4769s;
上图13中,清晰描述了从CNN特征层输出,到最终感知架构输出之间的对偶关系。为了产生右上角的最终输出,为后续的规控模块提供良好的判断基础,整个感知模块使用了右下角的三种CNN特征识别结果,包含但不限于:深度图、车辆特征识别结果和车道线特征识别结果。尤其需要注意的是,这些特征的处理都是发生在投影平面Perspective view视角下的,而最终输出结果则发生在BEV俯瞰视角下,这就是Transformer对于视觉信号处理的功劳。
以上即是当视觉数据以“特征-Feature”的形态流经整个感知协议堆栈过程的全部。Tesla AI Day过去的接近一年的时间内,诸位读者应该可以看到整个产业界在感知框架内的逐渐趋同,除了部分传感器素质的差异即对Lidar的引入以外。
TeslaTransformer网络的实现
关于Tesla Transformer网络实现的分析,汗牛充栋了。核心要点主要有以下:
1Tesla的Transformer实现重点在于Cross Attention部分,扮演feature encoder角色的Self Attention似乎是由CNN框架送上来的Multi-scalefeatures所替代了,性能会差一些,但效率更高,对于车载硬件平台的友好性更好一些;
2所谓Cross Attention部分,本质上就是实现了从BEV俯瞰角度对于投影角度像素(像素块)的查询,类似不同语种之间的翻译行为;
3从BEV角度发起的Query查询,也是一个MLP过程的结果,MLP本身也需要充分的训练;
4通过BEV角度的Query,查询投影平面中的特征。具体到我们上文所举的例子,就是在Main、Pillar和Repeater camera视觉数据中查询那些最像车道线的像素区域,到底在俯瞰角度中应该位于什么点位。
这就是Transformer的本质。人类为什么可以通过2D图像来判断视野范围内目标物体的前后关系、距离远近,这些信息往往足够我们规划一条穿越其中的路线呢?是因为大量的生活和实践经验告诉我们,物体的大小、阴影的方向、遮挡的前后关系甚至一些生活常识……这些特征,都会协助我们在我们的脑海里建立一个类似“上帝视角”的BEV俯瞰图。
从实现细节上看,小编看到Patrick Liu代表小鹏汽车的一篇在知乎上的回答《自动驾驶BEV感知有哪些让人眼前一亮的新方法》比较有参考价值。作者之前在medium.com(towardsdatascience.com)发表的对于Tesla BEV方法的分析写得也特别好,建议读者可以去搜一下(插图有链接)。
图片
图十四【BEV-13.png】来自Patrick Liu在知乎上的《自动驾驶BEV感知有哪些让人眼前一亮的新方法》答复中的插图,获取URL:https://www.zhihu.com/question/521842610/answer/2431585901;
上图中的上半部分是著名的DETR架构,是典型的利用Cross-Attention decoder的Transformer方法。参照DETR架构,我们会发现Tesla的BEV方式与其非常类似,BEV方向提供Q,投影方向提供K、V,经查询后得到BEV ImageFeatures。注意Encoder部分可以直接采用CNN backbone所提供的features,从而降低系统不得不获取Self-attention的高负荷。
图片
图十五【BEV-15.png】来自Karpathy在2021 Tesla AI Day中的演讲插图,获取URL:https://www.youtube.com/watch?v=j0z4FweCy4M&t=4769s;
图片
图十六【BEV-14.png】来自Patrick Liu在知乎上的《自动驾驶BEV感知有哪些让人眼前一亮的新方法》答复中的插图,URL:https://www.zhihu.com/question/521842610/answer/2431585901;
图15和16可以对照着看,这是Patrick Liu对于Tesla Transformer的具体分析。首先从Backbone获取PerspectiveImage Features,即投影平面上的视觉特征信号。然后通过线性投影方法得到自己的K和V值以备来自BEV方向的Cross Attention查询计算。与此同时,BEV空间中的预定义栅格生成查询Q,并于必不可少的位置编码相互连接。但令人不解的是,Tesla方案中显示了有“Context Summary”上下文摘要的存在,同位置编码同样平铺在预定义的BEV栅格空间内。Patrick Liu认为,“可能存在一个global pooling操作,可折叠投影平面上的所有空间信息,然后按照平铺的操作将这个1*1的张量平铺在BEV的预定义平面上。”根据他的分析,BEV的预定义空间中,同时由预定义的栅格、每个栅格所对应的位置编码,以及这个独特的Global Pooling张量组合而成,从而形成来自BEV空间的Q。
比较晦涩。如果简单理解这个思想,大意应该是,从BEV发起的对于投影平面特征的查询,不应该是一点关联都没有的随机查询计算(本质是注意力交叉计算),在查询之前,BEV的发起方总是应该知道投影平面内的特征到底是如何分布的,会更加有利于查询的准确性和命中率,这是对于投影平面的特征图引入global pooling操作的原因(如果PatrickLiu的分析是正确的话)。
举例说明,如果Transformer在具体应用中要解决对于车道线的视角转换操作,那么这个Global pooling的等效意义在于让拟人化的Transformer在经历对于大量车道线的训练后,变得特别理解车道线的具体特征,变为“车道线专家”,并在一个张量中体现这种能力,从而在BEV的查询中,将这个张量复用于每个BEV的位置,从而利用交叉注意力值的高低,知道当车道线的任意一点出现在投影平面中的某个位置时,它应该对应地最有可能地出现在BEV中的哪个具体位置。
读者可以将以上二图对照着看,相信会对Tesla的整体方案有一个更好的理解。
回到文章开头我们给出的三个基本概念,其中“3D感知矢量场”尚未涉及,主要是依据最近Tesla Ashok的一次技术演讲的内容所准备的,本质和之前我们曾经介绍过的Occupancy Network性质差不多。考虑到本片篇幅相对较大了已经,所以放到下期再讲。我们希望在月底Tesla AI Day 2022之前,能带着读者重温一遍去年滚烫的感知技术框架。
==卷尾语===================
本文不带有任何立场和倾向,只是作者从公开资料着手,试图分析行业主流技术的原理和表现,让读者可以在多种自动驾驶系统实现中做横向对比和思考。码字不易,读者如果看着有收获,欢迎转发,请注明来自微信公众号—车右智能。
=========================
备注:
1封面底图来自互联网插图,URL资源: https://www.malls-77.ml/products.aspx?cname=tesla+model+s+top&cid=4
写在最后
“知识积累”类稿件质量要求:
A:信息密度高于绝大多数券商的绝大多数报告,不低于《九章智驾》的平均水平;
B:信息要高度稀缺,需要80%以上的信息是在其他媒体上看不到的,如果基于公开信息,需要有特别牛逼的独家观点才行。多谢理解与支持。
免责声明:本内容来自腾讯平台创作者,不代表腾讯新闻或腾讯网的观点和立场。
举报
评论 0文明上网理性发言,请遵守《新闻评论服务协议》
请先登录后发表评论~
查看全部0条评论
首页
刷新
反馈
顶部