其他
大牛讲堂 | 苏治中：面向规模化量产的自动驾驶感知研发与实践
导读
4月27日，地平线智能驾驶感知研发部负责人苏治中就《面向规模化量产的自动驾驶感知研发与实践》这一主题进行了直播讲解。
本次课程内容分为4个部分：
1、地平线自动驾驶环境感知量产实践2、软硬协同的自动驾驶感知算法设计3、实现规模化量产的“最后一公里”4、感知技术的发展趋势
01 地平线自动驾驶环境感知量产实践
02 软硬协同的自动驾驶感知算法设计
下面将从Backbone、Task设计以及Multi-task model三个方面为大家讲解算法的设计。首先是Backbone的设计，在Google提出MobileNet之后，MobileNet在对低延迟有非常高要求的场景中获得了巨大成功，并且它仅需要更小的算力。但MobileNet也有一定的缺陷，因为它的depthwise convolution与pointwise convolution的计算量分配不均，使得在硬件上会增加计算和访存读取的切换时间。
为了解决上面的问题，我们提出了VarGNet。它是指可变组的卷积，即variable group的CNN，通过可变组卷积升维，再通过pointwise convolution降维。MobileNet则是通过depthwise convolution升维。相比普通的 group convolution，我们的网络group数可变，但每个卷积里分组channel数是一致的，而一般的group convolution是channel数不一致，但group数保持一致。之所以要做到channel数一致，是因为可以组合跨层之间的部分 channel卷积，减少在SRAM与DDR之间的读取。
VarGNet有两个特性，一个是Block内计算更均衡，像刚刚提到的升维和降维分别使用variable group跟pointwise convolution计算，减少了内存切换和计算之间的平衡；另外一方面在block之间采用了一个更小的 channel或更小的feature map，通过这种方式达到更好的访存和计算平衡。
关于特征和参数的组合，以及硬件在计算过程中的流水线，大家可以参考凌坤在2月23日讲解的《好的自动驾驶AI芯片更是“好用”的芯片》，里面有更详细的介绍。这篇VarGNet的论文，也可以在arXiv上找到。
之后是感知任务设计，大家最熟悉可能是2D感知。计算机视觉里一些经典的任务，比如检测、分割、分类和关键点检测，组成了自动驾驶里最基础的2D感知。图7有一些示例，像车辆检测、车型分类、针对一个行车场景和停车场景的分割，以及通过车轮接力点的关键点检测，在2D任务里判断车辆的朝向，和在停车场景中停车位的检测。但是2D感知都是在图像域的，所以要变为可以被路径规划和控制所使用的车辆坐标系或世界坐标系下的感知结果，因此需要结合一系列的先验才能得到所需要的信息。
右侧下图是复杂遮挡的例子，车尾与全车检测都还有一个不错的效果，但在这样很多遮挡情况下，很难估计车辆的pose。如果没有办法估计车辆pose，也没有办法知道它行进的方向，以及对自动行驶的影响。因此为了使用深度学习，即通过数据和计算进行端到端的优化，是需要进行原生的3D环境感知。
此外depth还可以改进 Freespace的效果，尤其是外参测距的情况。图9右边中间部分是单纯的外参测距产生的Freespace，而下面的是外参+depth产生的Freespace，可以看到在一个高速收费口有三个水马，实际上感知是找到了水马，但Freespace投影出来这几个水马的位置却比较靠后。而通过引入depth，可以更好的得到一个准更准确的Freespace，结果显示这三个点的位置跟水马检测到的位置是很接近的。
很多同学也会问到，基于激光雷达的任务，怎样更好的优化，因为量产车上是没有激光雷达的，所以现在也在尝试基于多摄像头和多帧的光度一致性，对深度预测模型做无监督或自监督的优化，这也是目前学术界广泛尝试的方案。
接下来针对动态目标的3D检测，与depth任务类似，同样要用激光雷达得到场景中所有3D的动态目标，比如车辆、骑车人，然后再以图像为输入进行学习，并直接输出3D的bounding box offset，还有长、宽、高等。图10可以看到一些3D检测的示例图，包括一个多类目标的感知车辆，还有骑车人以及针对横穿马路场景的处理。刚刚前面也讲到，目前2D感知很难应对横穿车辆的场景。
再接下来是3D车道线，上面讲到2D感知局限性时，实际上也提到了2D车道线，如果先做分割，再做投影会很复杂。其次分割还需要一个相对复杂的连通域提取过程。车道线是环境里面最重要的一个静态目标，因为我们在大多数的城市道路和高速路上，车辆主要是沿着车道线行驶，因此研发原生的3D车道线感知很关键。上面右半部分的图片是对图11中的左半部分图片进行了IPM投影，然后将竖直的列作为anchor进行anchor-based detection，之后再在 instance基础上提取关键点。3D车道线的输入可以是单摄，也可以是跨摄感知融合的特征，跨摄感知融合的特征会在后面讲到。
接下来是多任务模型的设计和改进。图12是第一版多任务模型组成的视觉感知系统，是一个全图输入且相对比较大的多任务模型，采用了UNet结构，做所有关键目标的检测。之后会对这个图片感兴趣区域做截取，比如找到了行人、交通灯和车辆。因为基于行人或车辆的输入，还要做很多其他的任务，像朝向的判断、关键点检测以及分类等，所以还会针对不同的目标，再去使用一系列、更小的、以ROI作为输入的模型，做更细粒度的任务。
在这个系统中，实际上是有多个大小不一的多任务模型，最终至少产生了40多个task outputs。这个task output并不是tensor，因为每一个task可能会有非常多的tensor输出，比如3D车辆检测就有非常多的tensor输出，包括pose、长宽高以及中心点位置等。但是这个系统也存在一些问题，比如在系统中需要去截取这些图片，再去独立的过模型，可能没有办法复用或者共享之前大模型提取的一些特征，这实际上有一定的浪费，因此也希望采用特征ROI输入的多任务模型来改进系统。
针对基于特征ROI的多任务模型还有很多优化方法，下面为大家罗列了三种方法。首先将RPN替换成一个更好的 proposal generator，而征程3也支持一个更复杂的检测器，得到了ROI，然后再用ROI返回Backbone上取特征的方式，并且这个过程非常高效，它完全是在BPU里进行；其次是把一些没有必要的Dense prediction变成Sparse prediction，以及在Task head之间有一些share feature，进一步降低模型的延迟。
下面详细介绍下这三种方法，首先是Better proposal generator，比如把RPN替换成FCOS，这也是现在相对比较新或者检测性能相对比较好的模型。上面有提到征程3是支持通过更复杂的检测器获取ROI，反过来再通过ROI来获取feature，然后进行下游任务。但是更复杂的 proposal generator有利也有弊，利在于首先是特征表达相对可能更浅层一些，所以通过引入浅层的特征，检测框可能是一个更精确的框；其次因为FCOS本身有很好的性能，所以它对 proposal 的提取会更精确，像可以更减少一些false positive proposal。但是它也有代价，因为FCOS会比RPN更复杂，所以计算量更高，可能会给模型带来一些延迟的增加，所以这里需要去做一些trade off。
接下来是dense prediction变成sparse prediction，和一个典型的例子：Vehicle 3D det变成Sparse vehicle 3D det。因为常见的基于 CenterNet的检测器，比如FCOS 3D是一个稠密的3D检测器，只需要把它连接在backbone上，就能够完成多任务模型，但是这个过程实际上是有一定浪费的，既然 region proposal已经给出了车辆的区域，那完全可以在proposal上预测3D bounding box。
图15可以看到Sparse 3D与Dense 3D的对比，在一些远距离的车辆上面， Sparse 3D获得更好的召回，同时还降低了计算量。这也是因为RPN会提取更多、更丰富的proposal，使得能够在第一个阶段保留更多的候选区域。
最后一个是Task head combination，比如针对vehicle task123可能是检测、关键点或者分类等其他任务，这三个head实际上是比较类似的，或者说是相关的任务，如果把这三个head再共享一部分特征，能够使得整个模型的计算量有一定下降，从而获得更低的模型延迟。
以上是针对多任务模型进化做过的一些尝试或一部分工作，前面讲到了基于图片ROI跟特征ROI两种多任务模型的选择，但是基于特征ROI和图片ROI的模型并不简单是一个替代关系，即特征ROI模型做出来之后，它不可能完全替代图片ROI。
它们相互会有一些优势和缺点。比如基于图片ROI的多任务模型，它的研发工作是相对解耦的，像我在做车辆，我的伙伴在做行人，我们俩可以迭代两个模型，而不需要在同一个很大的模型里开展工作，这样研发的节奏或分工会更清晰简单些；其次，它可以针对单一任务快速、低成本迭代，比如我的版本发出去后，发现车辆的效果不太好，但是其他的都很好，实际上可以只迭代车辆的多任务模型，而不用迭代其他的，但是基于特征ROI模型也可以只迭代这个head，但是基于特征ROI总是要提取 Backbone的特征，所以会让过程变得稍微复杂；最后图片ROI可以调度skip非关键目标的计算，比如一些远距离车辆，可能现在不是特别关注，软件就不会调度图片ROI的车辆多任务模型。
针对特征ROI，因为在常规的一个两阶段检测器里，通常只能设置置信度和proposal的上限，很难做更复杂的策略来选择这个特征的ROI。虽然在软件层面上可以实现，但是会更复杂一些。
图片ROI的缺点刚刚也讲到，之所以要做特征共享就是为了节约计算量，所以它必然有更大的一个计算量；其次它的发版会更复杂，也更繁琐，维护也会更麻烦，因为一个版本里面可能要带很多个模型，而它们要被整理成一个相同的版本号。
特征ROI，首先它能完成特征共享，节约算力降低延迟；其次能够做端到端的联合优化，即proposal的提取与stream下游的一些任务能够做端到端的联合优化，做过深度学习的同学，应该都会非常期望我们的任务是可以被端到端联合优化的，有梯度回传一般来说总能带来更好的效果；最后特征ROI能够给下游任务提供更大的感受野，因为每个特征的像素对应到原图上一个很大的区域。但是特征ROI也不是完全完美，它会有一些训练难度大、耗时长的问题，以及Train from scratch代价高，所以在实际工作中这两种也会针对产品与任务，以及不同的项目做灵活选择。
多任务模型的最后一部分是多任务模型的训练。多数模型如果没有一个很好的训练机制，需要把每张图片上所有的task都进行一个标注，并且有时很难控制不同task之间的数据量、更新频率以及迭代权重，所以也设计开发了一种每个task独立forward 和backward的训练模式，它可以每个任务单独构建计算图，使用独立的 batch size，比如task1是针对vehicle的某一个任务，而task2是针对pedestrian的某一个任务，它们俩可以有不同的batch size，这样独立的方式也可以比较容易的控制task1跟task2的迭代次数。像刚刚提到，如果车辆任务已经做得特别好，但行人任务不是特别好，只想迭代行人的task2。再次，它可以很方便去做任务采样训练。最后，它支持图片仅做一部分任务的标注，比如有一些图，过去可能只标注了pedestrian跟vehicle，但现在新增了一个task，是交通灯，通过这种方式就能够很好的把仅有部分标注的 data也可以做很好的应用。
图17的PPT动画也展示了这个过程，可以看到是在不同task之间，我们去simple一些data，然后forward 、backward结束之后，再进行到下一个task。
03 实现规模化量产的“最后一公里”
那什么是一个好的工作流或我们的工作流是什么呢？首先收到长尾的问题或corner case，这些case可能来自于自己的测试，也可能来自于客户的测试。这些case会积攒得非常快，我们也会对它进行分类。当某一类型的case积攒得比较多时，会对它们进行 root cause分析，将大量的root cause扔进一个相对比较标准的优化流程里，我们有若干很标准的优化流程。尽管大部分优化流程都是很收敛的，但难免还是会发现新的根因，新的根因也会为它设计新的优化流程。
图20右侧是一个root cause分析的一个triage tree，但这只是部分，可以看到把这个根因分得非常细，这也是在三年量产过程中，针对场景或特定情况的一些分类的积累。root cause分析的过程一部分是自动的，也有一部分是手动的。如果是自动，它也会依赖云端更大的计算量，或者依赖后验分析，因为一般在得到这个case或问题触发之后，还有很长的一段时间。当你离线去处理它时，你可以用事后诸葛亮的方式来反推是否有问题，或者是有什么样的问题。也有一部分会依赖算法工程师或者标注人员进行手动的root cause分析。
有两个主要的分支，第一个分支是用很多这样的长尾问题去产生一个回归用的集合 regression dataset。首先会选取一个片段，我们称之为pack或clip的视频片段，然后在这里面选取关键的目标和时刻，关键目标是右上角图片里左边的车，因为它是我们的CIPV，即是本车道离自车最近的一辆车；关键时刻就是错误帧框跳出来，造成车辆产生点刹前后的一些时刻，然后会确定关键指标。针对这样的检测问题，关键指标实际上是AP或者 IoU error，因为IoU决定了框的检测是否足够贴合，之后会进行真值的标注或者自动生成，自动生成可能是一个预标注的过程，也可能是其他更复杂的4D标注生成的过程。针对2D更快或更常见的做法还是标注，之后把选好的corner case加入到框分裂case的回归集合里，这是回归case集合建立的链路。
另外一条链路是我们如何去解决它。首先会统计近处的大车是不是真的不充分，即是训练集合的一个统计，并分析训练集里打的一些tag，比如大车、离自车的距离、CIPV等看有多少这样的情况在训练集里是存在的。如果它非常丰富，但是还是出现了问题，会对它做算法调整，比如引入框的置信度，针对框边界的置信度，而不是针对框本身的置信度，因为现在的很多基于关键点的检测技术，实际上能够给我们带来框边界的置信度。但这种情况并不是特别多，大部分情况下会发现这种类型的数据并不充分，因此会做一些数据挖掘，然后将挖掘到的数据放到模型里做训练，然后评测，跟 case集合做回归，之后再做模型的发布。
以上是以近处大车造成的ACC点刹为例，实际上很多与某一个目标相关的，并且需要通过数据挖掘解决的标准工作流的方法都非常类似，这也就使得我们的工作能够相对比较收敛，以一种较少的工作流程来解决大部分在量产之前会遇到的问题。
第二个是用Scene tagging，通过这种感知结构化信息，因为在测试过程中都是一边测试一边在跑功能，所以会保留很多已有的感知结果，比如车道线的感知结果以及场景分类得到的天气、时间段的结果，这些感知结果会被结构化成一些场景的标签，比如夜晚高速路导流线的场景标签，这样可以在大的、全量的datasets里寻找相关的数据，并且将它们引入到训练当中。
第三个会用到的方法是similarity search。similarity search会对图片提取一个特征，提取特征的模型是什么，可以自行选择或自行去训练，现在有非常多性能非常好的、通过自监督学习得到的各类大模型，当提取出来这些特征之后，我们可以用希望得到的场景图片，比如一个隧道口，去底库里所有图片做特征的相似搜索，然后得到一系列高速路隧道口的图片，引入到训练里。
这只是一部分会用到的数据挖掘方法，因为数据挖掘在工作中非常重要，所以也会有一些其他更丰富的手段。
接下来讲下工具部分，前面提到了一个高效的工作流是被很好用的工具和基础设施所支撑的。而地平线艾迪（Horizon AIDI）AI开发平台，就是我们所依赖的一个算法研发的平台和基础设施，它由AIDI-Issue，AIDI-Eval、AIDI-Model、AIDI-Label等多个平台支撑算法研发服务。目前关于地平线AIDI的材料非常多，我的同事凌坤2月23日公开课课程《好的自动驾驶AI芯片更是“好用”的芯片》中，对这部分内容有更细致的介绍，大家如果感兴趣可以看下回放。
算法工程师开发更多的是Horizon Data Flow(HDFlow)。它是依托于AIDI构建、基于DAG的算法自动化开发全链路闭环工具。DAG是指有向无环图，如图24左边的示例，把一些节点或者OP通过一些边连接在一起，让OP能够流转。现在业界有非常多不同的DAG引擎，我们也是通过对DAG引擎的封装来构建HDFlow，然后完成自动化的工作流。
HDFlow对业界一些比较普遍主流的一些DAG引擎都做了一个抽象跟封装，并且简化了OP操作的接口，同时它也是支持本地，即在自己的开发机上或者在集群上的分布式执行，灵活度高，也方便算法工程师调试。右边是一个DAG任务的可视化，每个小圈表示一个OP，之所以画了绿色的对号，是因为DAG已经顺利的完成了一个执行，这里面可能包含了一些数据挖掘和模型训练等等，都会作为HDFlow中的一些节点。
图25展示了一些可以由HDFlow搭建的任务，包括训练前闭环：数据挖掘、标注质量检查、评测集构建、场景与Corner case数据集构建、数据分布统计，以及训练闭环：训练数据打包、模型训练、模型发版、模型评测和回归等等，这些都是通过HDFlow可以自动化构建的一些task。所有的小DAG可以被更大的DAG包含，所以这些任务之间也是可以被HDFlow自动化的串联在一起，通过这个工具，大幅的提升了在标准化工作流中做数据流转或算法开发任务。
目前，Horizon Matrix Mono前视单目解决方案，是国内唯一具有纯视觉AEB感知能力的方案，能够同时达到两项非常厉害的指标：C-NCAP 五星+和AEB误报数小于1次/20万公里。C-NCAP是中国的New Car Assessment Program，五星+是最高级别得分， C-NCAP要求车型需通过乘员保护、行人保护和主动安全三大项严苛评测，综合得分率≥90%才能获得5星+。与此同时，Matrix Mono也控制了AEB的误报数在非常低的水平——远小于20万公里一次，即大部分用户在开这个车的生命周期里面，像10万公里、 15万公里，很大概率都碰不到AEB误触发的情况，而且指标还在不断被优化。
AEB误触会带来很不安全的问题和很差的用户体验。大家过去可能听过一些车，由于AEB误触造成所谓幽灵刹车的情况，像正在路上开车，然后什么东西都没有，车突然自动刹车，然后把乘客吓了一跳，所以它也是一个很关键的指标。
我们之所以能够达到这样的指标，与前面讲到的算法方案、工具、标准化的工作流相关，也和测试能力有关。目前我们的产品是经过了超千万公里、超过60万小时的实车测试，并且具备百万公里每天的回灌测试能力，即如果有一个版本做了一定的改进，可以在一天之内完成100万公里的回灌测试。在前不久的中国电动汽车百人会的论坛上，苗圩主任也提出需要将AEB作为车辆标配的建议，这也说明了AEB作为主动安全重要的功能，被看重的程度或重要性。
接下来展示两个NOA领航辅助驾驶的 Demo视频。展示的是夜间车辆进入匝道的过程，可以看到整个驾驶过程非常平顺。在高速路行驶的期间，进入匝道的过程中，是完全没有驾驶员接管的。第二个视频同样是基于夜间领航辅助驾驶。这里是在跟着一辆车，车上载有货物，且货物跟车辆的车尾高度不相匹配的情况。可以看到，还是能够做到平稳跟车。
图27展示地平线的一些量产成果，已经有超过20个车企的定点合作，50多个车型的定点，以及超过百万的智能芯片出货和超过100家的生态合作伙伴。这张图中是已量产的部分车型示例，黄圈是我个人参与过的一些ADAS量产项目。
04 感知技术的发展趋势
最后给大家介绍我个人对感知技术发展趋势的一些看法，我认为图28的这些技术会成为达成自动驾驶的重要途径。
首先是 Transformer。它有多种不同的应用，首先可以作为Backbone，比如 SwinTransformer，在相当长一段时间内是SOTA，但现在有一些新的模型产出；其次Transformer还是空间和时间特征融合很重要的组件，现在不管是做一些Tracking或BEV感知，很多时候都用到Transformer结构，才能够达到很好的效果，所以Transformer很重要。
其次是 BEV感知。关于BEV感知，刘景初博士在地平线自动驾驶技术专场第1讲上有一个课程叫《上帝视角与想象力--自动驾驶感知的新范式》，深入讲解了地平线针对BEV感知的一些实践。而BEV感知同时端到端地提供了特征融合和视角转换，所以是一个很好的新范式，目前很多人都在做，但是特征融合的方式有很多，不仅仅是BEV感知。然而视角转换也能够给下游的一些任务预测和planning提供一个更好的输入，这也是当前会比较倾向于使用BEV感知的一个原因。
之后是时序的端到端感知。这种结合时序特征的，比如通过Transformer做时序特征融合的一些端到端检测到跟踪再到预测，能够进一步降低系统不喜欢的人工逻辑参与。因为人工逻辑会使得我们总是需要很优秀的工程师不断优化系统，使得系统很难 scale up。
接下来是多传感器前（中）融合。现在有很多量产的车规级固态激光雷达，已经在很多车型上应用，像蔚来的ET7，理想的L9上都已经有一些装配。先不去论Lidar跟视觉之争，如果仅仅是有这些传感器，相比依赖人工逻辑的后融合，Lidar、Camera特征级的前融合，它能够通过数据和计算的驱动替代人工逻辑，带来更简单，或者更容易迭代的系统，同时算法也能够降低对传感器同步的要求。
下一个是（大模型的）自监督学习。目前业界有非常多大模型的自监督学习的工作，这些模型也显示出了一定的智能。比如最近特别火的DALL-E2，可以输入一段话来创作图片，创作的这些图片很难辨别是被机器或模型所创建的。我认为自监督学习的发展还是很好的，但自监督预训练在下游任务的表现还有待提高。我们会对这个领域保持关注。
最后一个是 Low Level Vision的应用。纯视觉的自动驾驶系统如果还是仅仅是依赖语义级的感知，比如detection、parsing会非常有局限性，因为这些语义级的感知往往是针对闭集，即一些定义好的类别，比如说车辆等。但是，它很难应对一些极端复杂的场景，或者一些没有定义过的障碍物类型。我个人认为纯视觉自动驾驶系统的发展，会依赖 Low Level Vision的成熟和大规模应用。
地平线已经发布并即将量产的征程5正使得这些技术的量产落地成为可能。征程5有更大的算力，单颗芯片达到了128TOPS算力，也使得做一些更大的模型成为可能；其次它对Transformer有比较好的支持。在征程5上 SwinT可以跑到140FPS，同时征程5的功耗只有30瓦，而PC端常用的NV 3090，是在上百瓦功耗下达到230FPS，所以可以看到征程5有一个非常好的能效比，并且作为车规级的芯片，确实达到了很高的FPS，使得 SwinT系列在这个产品中使用成为可能。不过需要说明一下就是SwinT这里是一个batch size为1的情况，随着batch size增大，3090也会明显提升它的帧率。
其次，征程5支持图片和特征的remap变换，因为现在不少BEV或者其他技术会依赖高效的图片或特征的remap，包括要做虚拟相机之类的技术也是需要一些remap。
最后，征程5也硬核支持部分Low Level Vision feature的提取。
图29左下角是一个以EfficientNet作为Backbone的FCOS模型，在征程5上与Xavier和Orin-X的对比，蓝色的线是征程5，黄色的线是Orin-X，橙色的线是 Xavier，纵轴是mAP，横轴是FPS，可以看到征程5是有显著的优势。1283 FPS是在保持MS CoCo数据集上的精度 mAP=34.6%，输入分辨率为512*512的情况下，征程5所达到的计算性能。
最后，给大家展示下基于征程5的Matrix SuperDrive产品片段做个预热，后面还会有详细的课程做讲解。它是基于两个征程 5，256 TOPS算力支持下的一款自动驾驶产品。片段展示了一些BEV感知的结果和一个左转的过程，可以看到整个过程是没有接管并且非常平顺的。这也是通过纯视觉完成的。
以上是我今天跟大家分享的内容，谢谢大家。