ADAS_AD前视感知测评-94汽车网

ADAS_AD前视感知测评

1、前视感知在ADAS/AD中的意义；

2、前视系统的软硬件组成；

3、前视感知算法的测评需求；

4、前视感知算法的测试工具链；

5、测评新技术的展望；

作为普通顾客，如果你花十几万买一款新车，那么它大概率标配了FCW、AEB、ACC等辅助驾驶功能。比如，吉利品牌下面的畅销车型博越(图片|配置|询价)SUV，其就是配置了某家国外供应商的前视感知系统，它输出的检测结果，会和车辆上的雷达探测结果进行融合，共同完成对自车前向的目标物检测。前视感知系统（Front Looking Camera System）简称FLC，它前视感知是感知系统的核心组成，主要原因因为汽车95%以上的行驶工况，都是在往前开的。

前视一般装在后视镜的背面

雷达和视觉融合感知结果用于纵向决策

所以前视感知系统是用来探测自车前向目标，它能够对前向特定目标进行准确的识别、位置估计、3d追踪等功能，其输出的结果，会用于后续的融合、决策等算法模块。那么前视感知系统在一个ADAS/AD系统中占据什么地位呢？简单来说，就是汽车看得远的眼睛。

Tesla Model S（14款，Autopilot 1.0）上只使用一个价格低廉的像素1.2M、HFOV 52°的前向单目感知系统，大约可以检测到150m远的车辆，你可能不觉得这个东西的意义有多大，但是价格要贵几倍的Bosch 4nd Front Radar也仅能够检测到最远160m处的目标。

Tesla Autopilot 1.0–Mobileye EYEQ3

此外，前视感知系统具备丰富的语义信息识别能力，它还能够提供很多前方道路环境信息，我们以Eye Q3的部分感知功能举例：

车道线：可识别道线种类，如虚线、实线、反光点，双线，马路牙等；
车辆：可识别前方车辆、摩托车、自行车等，同时识别出车辆的距离、相对速度、CIPV（前方关键车辆）、TTC等关键参数；
行人：可识别前方多个行人目标，包括迎面、侧面、背面等。并给出行人目标距离以及预计碰撞时间；
会车灯光：可以识别会车前大灯，并给出目标运动参数，以及智能前大灯应避免的晃眼区域；
交通标志：可以识别多种交通标志，包括主标志和主标志下方的辅助标识。可以给出交通标志的位置以及含义信息；
……

可以说前向感知为自车提供了丰富的前方道路环境信息，为ADAS/AD系统重建了世界道路模型，能够让自车理解道路拓扑结构，认识道路上的动静态目标，理解交通信号灯和交通标识的意义。车辆有了这些能力，就具备了类人的视觉感知能力，为进一步实现自主驾驶，提供了基础。

二、前视系统的软硬件组成

ok，前面扯了这么多，那一个前视系统到底是什么样的呢？我们可以先从Tier 1采埃孚（ZF）的前视三目摄像头（S-Cam4）产品聊聊，引出前视系统的软硬件。

ZF的S-Cam4 包括两个版本，一个三目的和一个单目的版本，三目版本包含一个150°的广角摄像头用于监视车辆周围环境，一个52°的中距摄像头和一个28°的远距摄像头。

S-CAM4硬件拆解

3个前视相机通过硬线接口连接在电路板上，通过ISP算法得出人类可感知的图像，再通过MOBILEYE EYE Q4芯片对图像进行处理，得出感知系统的计算结果，输出给下游算法模块。

上面我们从硬件层面初步认识了前视感知系统，下面我们再来聊聊前视感知系统的软件。

现在主流的前视感知都使用单目视觉，比如上面我们提到的S-Cam4也是三个不同检测用于的相机分别运行得出感知结果，只是每个相机承担的功能各有侧重。比如：

HFOV 28°的窄视角相机，能够识别到前方260m的车辆，主要用于Highway场景的远处车辆识别；

HFOV 52°相机一般是主相机，需要感知的前向目标大都需要这个相机来检测；

HFOV 150°相机叫做广角相机，主要用于路口场景横向目标检测；

单目视觉的感知算法，各家算法公司都是采用了深度学习（Deep Learning），因为大家发现rule base 的感知算法检测率远远低于DL的视觉感知。深度学习算法，需要有海量标注数据，用于训练感知算法模型。一个训练出的感知算法模型可以是只检测一种目标的（车辆/行人/自行车）、也可以是检测多种目标（车辆+行人+自行车）。另外，深度学习算法模型可以是只用来做2D识别的，也可以是直接输出目标物类型和3D信息的。（*2D是指目标在二维照片上的检测，3D是指目标在物理空间中目标的三维位姿信息。）

三、前视感知算法的测评需求

那么前视感知算法的测评需求有哪些呢？谈具体的需求，就需用从产品使用的场景出发，依据需要达到的功能性能，反推出具体的模块需求。我们从一个L2+交通拥堵辅助系统TJA（Traffic Jam Assist）为例，来的拆解一下对前向单目感知系统的需求：

TJA主要的功能描述如下：

自车需要在0-60km/h车速范围内，实现在当前车道中央，跟随前方的动静态目标行驶，要对应于交通拥堵的高速公路驾驶场景。

对于前向感知系统的需求，上面主要提到了两点：1、要能够检测到车前向道线，给出当前车道的车道中央引导线；2、能够检测到前向动静态目标，给出目标的3D位姿；

针对于这两条需求，我们把需求细化一下：

能够对前向A(m)的双车道线完成检测，给出车道线相对于自车坐标系的三维空间曲线方程，在前向B（m）范围内车道线的位置检测精度要高于C（cm）；

能够检测到前向D（m）的动静态目标（例如：动态车辆、静态桩桶），给出动态目标相对于自车坐标系的三维位姿信息（Speed、ID、等），在前向E（m）范围内需要满足位置检测精度小于F（%）。

除了以上两条细化需求，还有吗？当然还有，我们细想一下，这个世界有哪些类型的车道线，有哪些类型的动静态目标？

标准车道线

弯道车道线

Y型线

可变车道线

A1-C4标准车辆

复杂的人类

静置的水马、桩桶

以上我们对需要探测的车道线、动静态目标做了些举例，这些都是我们在生活中场景的景象。一个人的阅历是有限的，这个世界上多的是我们没见过的事。其实以上尚没有把前世感知需要达到的感知需求说尽全。还需要考虑的因素有：

天气和光照条件；
道路设施状况；
动静态目标物及其相对自车运动的形式；
……

总结一下，综合以上测评需求，我们对前视感知系统提出了众多的测评指标，简单来说就是在各种环境场景下，前视感知系统对需要探测到的各类目标能否看得到（detection range），看得清（检测分类P/R、追踪tracking），看得准（position、angle、velocity、accelerate、continuity…），看的明白（prediction），当然了目标对自车驾驶行为产生影响越早、越严重，指标要求则越高。

四、前视感知算法的测试工具链

假设我们已经有了一份详尽的前视感知系统需求，并且提出了具体可量化的指标需求，那我们要如何针对指标需求进行测试呢？

通用的前视感知测评工具链有以下几部分组成：

搭载待测前视感知系统的车辆；
感知结果车端可视化界面；
前视感知的真值获取设备；
感知结果指标测评及数据可视化；
原车数据及算法结果的数据采集设备；
车端数据回注的测试台架；

1和2组成了基本的车端感知测试工具，能够满足系统集成商（OEM、Tier1）对前视感知系统的基本测评，能够感性的了解到前视感知的输出结果。

Cruise开源可视化工具

3、4是在解决了感性认知层面后，需要对系统进行指标化测评，实现算法性能迭代用到的工具链，一般只有算法开发公司才会具备这套开发能力。首先通过一个精度满足一定需求的设备，获取一个比待评测目标更精准的结果。这个结果在算法评测上被称真值，简称GT（Ground Truth），而待测的前视感知输出结果则称为检测结果，简称DT（Detection Results）。GT和DT都有了，就可以开发一套评测代码，拿需要评测的DT和GT做比较，从而得到评测指标的结果，最后再开发数据可视化代码，从而更好的展示测评结果。

那么真值怎么搭建呢？可以参考的方法有很多，总的搭建原则是：精度满足、成本低。下面我举一些前视感知真值的事例：

使用自己眼睛识别算法结果的小G实习生，对于算法输出的每一帧结果，他都是一点点检查，标记出感知算法的错检、漏检、检测不准等问题。他很好的完成了算法交付验收工作，实习结束返校时发现自己视力升高了100°；
聪明的小H实习生想到通过人工标记GT的方式，花了几天时间构建了一份GT数据。他将需要检测的目标放置在待测前视感知的检测范围内，通过皮尺量取了每个目标物的相对位置，从而构建了一套几百~上千个静态目标的GT测评集。这份测评集通过人工标注的方式，对待测原始数据进行标注，很好的解决了车端和台架端的交付测评；
有测试经验的老I立马想到可以通过给自车和待测目标都装高精度惯导的方法，获得自车和目标统一坐标系下的精准绝对位置（2cm精度）。通过在试验场一周的测试，获得了一份精准的目标物动静态GT。通过两套成本高昂的高精度惯导，获得的GT，很好的用在了项目交付自动化测评上；
做感知算法融合的资深研发工程师老J，他想到了既然人工可以标注目标的2D感知结果，那是不是可以用测量精度更高的激光雷达点云去标注目标的3D感知结果呢？对，说道做到的他通过在车顶上装了个“大花盆”，在各种场景下做数据采集，获得了帧率10hz的百米范围内的点云结果。通过人工标注点云，老J终于解决了研发评测的难题，拥有了成本不菲的准确GT，用于后续每一版前视感知算法的准出测评；
后来算法公司CEO再提出GT要满足精度足够和成本低两个要求，神秘人K给出了一套低成本获取海量真值数据的方法……

MOMENTA GT采集车

以上真值搭建案例故事纯为虚构。

在1-4的基础上，我们可以做到算法的车端测评，但是我们不可能只在车上做算法测试，一方面是那样的效率太低了，另一方面是待测目标会随着自车运动而运动，很多算法处理不好的corner case都是转瞬即逝的，我们很难对修改后的算法进行问题场景的复测。这就要求我们需要能够将车端测评转到办公室测评，车端发现的问题都能够在办公室复现。

通过开发5、6工具，我们可以很好的解决这两个问题。数据采集设备是一套能够记录车辆原始数据（相机图像数据、CAN数据、GPS等）、算法计算结果（前视感知算法输出结果）的数据采集设备。通过数据设备，我们可以采集到满帧率的车辆运行数据，一般L2+车辆需要采集的数据量在几十MB/s。有了车辆在实际运行过程的原始数据和算法结果，我们就可以拿这份数据回注到嵌入式处理器中，去做算法debug，或者用更新后的算法做回归测试。（*还可以通过对数据时间轴加速/减速，做云端大规模服务器集群的海量数据回放测试。）

这里就给Dspace大哥打个小广告吧。