自动驾驶的多传感器数据融合要点和基本方法

自动驾驶的多传感器数据融合要点和基本方法

本文整理了多传感器数据融合（Multi－Sensor Data Fusion，MSDF）的要点和基本方法。介绍了Harmonize、Reconcile、Integrate、Synthesize之间的区别和对应的解决方案。文章主要围绕什么是MSDF；为什么要MSDF和如何进行MSDF展开，希望给对自动驾驶感兴趣的小伙伴，提供一些参考。

许多人工智能系统的一个关键要素是具有多传感器数据融合（MulTI－Sensor Data Fusion，MSDF）的能力。在人工智能系统处于一个特定的环境时，MSDF需要对周围环境数据进行Harmonize；Reconcile；Integrate；Synthesize。简单来说，传感器相当于眼睛耳朵等输入感官，而人工智能系统需要以某种方式解释这些输入感官收集回来的信息，使其成为在现实世界可以被解释且有价值的信息。在驾驶汽车时，多目标跟踪（MulTI－Target Tracking，MTT）也是非常重要的课题——设想在市中心开车，周围都是行人和车辆，人类驾驶员要准确的识别并躲避他们，自动驾驶汽车也是。所以，这要求传感器融合具备一个必须的性质——实时性，就像人类每时每刻都在大脑中进行传感器融合一样。尽管人类不会公开地明确地将想法付诸于行动，但是这些"传感器融合"过程都是自然发生的。

自动驾驶的MSDF

首先，需要明确一个老生常谈的概念——SAE对于自动驾驶等级的划分。SAE给自动驾驶汽车划分为5个等级，对于L5以下的自动驾驶汽车，要求必须有一个人类驾驶员（安全员）在场。目前，人工智能和人类驾驶员共同承担驾驶任务，而人类驾驶员被认定为汽车行为的责任人。

回到MSDF的话题，下图展示了人工智能自动驾驶汽车如何进行MSDF的一些关键要素。

上图指出了MSDF面临的主要挑战是如何将收集来的大量数据集中在一起，并做出正确决策。因为如果MSDF出错，意味着下游阶段要么没有必要的信息，要是使用了错误的信息做出了错误的决策。可以看到，一般来说，自动驾驶汽车会通过安装在车身周围的摄像头收集视觉数据，也会通过雷达（激光雷达、毫米波雷达等）来收集诸如周围物体运动速度的数据，但是这些数据是从不同角度来描述现实世界的同一样或不同样的物体。所以，使用什么类型的传感器，怎么融合传感器收集回来的数据，使用多少传感器才能实现基于数据的对客观世界的描述呢？通常来说，使用越多的传感器，对计算能力的要求就越高，这意味着自动驾驶汽车必须搭载更多的计算机处理器和内存，这也会增加汽车的重量，需要更多的功率，还会产生更多的热量。诸如此类的缺点还有很多。

多传感器融合（MSDF）的四个关键方法

假设有两种不同的传感器，称它们为传感器X和传感器Z。它们都能够感知自动驾驶汽车的外部世界。在现实世界中存在一个物体，这个物体可能是人，也可能是车，甚至是一条狗，传感器X和传感器Z都能够检测到这个物体。这就意味着传感器对这个物体进行了双重检测，这种双重检测意味着两种不同类型的传感器都有关于该物体的数据报告，对于该物体有两个维度不同地认知。假设，传感器X表示该物体高6英尺，宽2英尺；传感器Z表示该物体以每秒3英尺的速度正朝着自动驾驶车辆方向移动。结合两个传感器采集到的数据，就可以得出一条相对准确的信息：有一个高约6英尺，宽2英尺的物体正在以每秒钟3英尺的速度移动。假设这两自动驾驶汽车上只安装了X传感器，那么就无法得知该物体的大小；若Z传感器坏了，那么就只有物体的大小信息，无法检测该物体的运动状态。这也就是最近业内广泛讨论的"在自动驾驶汽车上应该安装哪些传感器"的问题。

此前，特斯拉埃隆·马斯克（Elon Musk）旗帜鲜明地声称，特斯拉不会安装激光雷达。尽管马斯克自己也认为，L5自动驾驶不会通过激光雷达来实现这个想法最终可能被验证为错误的，这依旧没有改变马斯克的决定。一些反对的声音称，不配备激光雷达的特斯拉，无法通过其他的传感器获取如同激光雷达效果相同的感官输入，也无法提供补偿和三角测量。但是另一些支持者认为，激光雷达不值得话费如此高昂的费用成本，不值得为其增大计算能力，也不值得为其增加认知时间。

在同一个视场（Field of View，FOV）内，假设传感器X探测到一个物体，而传感器Z没有探测到。注意，这与物体完全在传感器Z的FOV之外的情况有很大的不。一方面，系统会认为传感器X是正确的，Z是错误的，可能是因为Z有故障，或者有模糊探测，或者是其他的一些什么原因。另一个方面，也许传感器X是错误的，X可能是报告了一个"幽灵"（实际上并不存在的东西），而传感器Z报告那里没有东西是正确的。

假设我们有两个物体a和b，分别在传感器X和传感器Z的视场FOV内（a在X视场内，b在Z视场内）。也就是说，Z无法直接检测到a，X也无法直接检测到b。目前，想要实现的效果是，能否将X和Z的报告整合在一起，让它们在各自的视场内探测物体同时，判断是否为X视场中的物体正在向Z视场移动，预先提醒Z将有物体进入探测区域。

Synthesize：

第四种方法Synthesize是将感知数据融合在一起，你可能会遇到这样的情况，传感器X和传感器Z都没有在各自的视场内探测到物体。在这种情况下，没有传感器知道这个物体的存在，但是可以通过一些其他的感观数据，比如声音，间接地弄清楚在视场之外的物体情况。自动驾驶汽车是时刻运动的，所以要求这种预判是瞬间发生的，像上文提到的一样，是实时的。

基于以上四种方法的解释，当各种不同传感器收集回来的数据结合在一起时，使用什么方法来处理这些数据呢？

绝对排序法：在这种方法中，需要事先决定一个传感器的排序。比如，摄像投的级别高于雷达，或者雷达的级别高于摄像头等等。在传感器融合过程中，子系统使用预先确定的排序。比如，在Reconcile情况中，在交叉的视场FOV中，X检测到了物体，但是Z没有检测到，而摄像头传感器X的级别高于雷达传感器Z，那么Z的检测结果不纳入考虑范围内也是允许的。这个方法简单、快速、易实现，但是综合考虑，这种方法并不严谨。

情况排序法：这种方法与绝对排名法相似，但不同之处在于，根据所处的环境，排名是可变的。例如，我们可能已经设置好，如果有下雨的天气，摄像头容易受到雨水干扰，进而摄像头优先级降低，雷达拥有最高优先级。这种方法相对简单、快速、易于实现。然而，从全局角度看，它依然有所不足。

平等投票（协商一致）法：在这种方法中，允许每个传感器进行投票且投票能力都是平等的。然后使用一个计数算法，该算法与投票结果相匹配。如果传感器的某个阈值都同意某个物体，而某些阈值不同意，那么就允许这个阈值决定人工智能系统做出判断。同样，这种方法综合看起来依然有所不足。

加权投票法：有点类似于平等投票的方法，这种方法增加了一个权重，并选择假设一些传感器比另一些传感器更重要。比如，系统可能倾向于认为摄像头比雷达更可靠，所以给摄像头一个更高的加权系数等。

概率投票法：还可以引入概率概念。传感器有自己的控制子系统，可以确定传感器是否得到了真实的数据，然后将概率使用到多个传感器的投票方法中。

争论方法：还有一种新的方法是让每个传感器"辩论"为什么他们的报告是合适的。这是一个比较有趣的概念。相关研究和实验正在进行中。

优先到达法：即优先报告结果的传感器获胜。出于计时的目的，系统不会等待其他传感器报告，从而加快传感器的融合工作。但是从另一个角度讲，无法预测下一秒钟其他传感器是否会报告相反的判断，这存在一定的安全隐患。

最可靠法：在这种方法中，需要跟踪自动驾驶汽车上无数传感器的可靠性。当存在各个传感器之间的数据争议时，最可靠的传感器将"获胜"。

在设计自动驾驶汽车时，可以在传感器融合子系统中使用以上的几种方法。当子系统确定一种方法可能优于另一种方法时，它们就可以各自发挥作用。当然，MSDF也可以通过很多其它的本文未提及的方法进行。

多个传感器之间的差异非常重要

人类的听觉和视觉是不一样的。当人类听到警报声时，使用耳朵这种感官。耳朵不像眼睛，眼睛不能听声音。这个例子可以生动地说明，在自动驾驶领域，一定有许多不同类型的传感器，多传感器融合MSDF的首要任务是，要利用不同种传感器的优势，同时最小化或弱化每种传感器的弱点。

上图中，每一种传感器的一个重要特征都是它能够探测到目标的距离。传感器能够探测到的距离越远，人工智能驾驶任务的提前时间和优势就越大。但是，一些研究结果标明，较远端的数据可能缺乏特征或者缺乏可信度。随着技术的日新月异，需要根据所涉及的距离确定传感器融合的优缺点。以下是一些常用传感器的探测数据（随着技术的进步，以下数据可能随时更新）：

有专家称，在比较各种类型的传感器时，业内有许多图表试图描述这些传感器的优点和缺点。专家建议不要盲目相信的这些对比图表。因为用于比较传感器的标准非常多，但是一些常见图表仅仅提取几个典型特征进行对比，缺乏可信度。如下图（仅供参考）：

笔者观点：在自动驾驶领域，传感器是一个非常博眼球的字眼。但是，一旦涉及具体技术和鲁棒性，目前并没有太多的企业或技术型公司给出一份值得信服的答卷。业内普遍认为，自动驾驶汽车的未来是保障人的安全，而保障人的安全都依赖于多传感器融合MSDF。人类每时每刻都在做着"多传感器融合"的工作，想要将自动驾驶汽车的多传感器融合做到像人类一样尽善尽美，还有很多复杂的工作要做。

声明： 本网站原创内容，如需转载，请注明出处；本网站转载内容（文章、图片、视频等资料）的版权归原网站所有。如我们转载或使用了您的文章或图片等资料的，未能及时和您沟通确认的，请第一时间通知我们，以便我们第一时间采取相应措施，避免给双方造成不必要的经济损失或其他侵权责任。如您未通知我们，我们有权利免于承担任何责任。 我们的联系邮箱：news@cecb2b.com。