正如我们在上一讲中所说，2017a的Matlab带来了一系列“车辆动力学模型”，这直接导致了业界HIL中的“一维纵向动力学模型”从高端产品沦为街头地摊，生意难做。

宇宙中最强大的工程 IDE 并不止于此。 它在2018版本中进一步发布了完全自由的车辆模型，并且还带有自己的场景。

独自挑战“Prescan+Carsim”的黄金组合，今天我们就用它来谈谈几种自动驾驶测试解决方案。

第一步是构建一个简单的游戏机并玩它

MATLAB/Simulink 提供了可用于驱动程序在环的基本演示模型。 网址：

该模型简单明了，如下图：

左上角是驾驶控制控件。 通过操纵这些控件，可以控制转向、油门、刹车等。这些控制模块来自Simulink--->Dashboard工具箱。 如下所示：

您可以将这些控制模块与模型中的参数关联起来，轻松调整参数，然后就可以愉快地玩游戏了。

由于是基础演示，因此车辆模型已被大大简化。

对于3D场景，渲染引擎使用Unreal Engine。 MathWorks 与游戏引擎 Unreal Engine 相结合，构建高保真驾驶场景。

对于传感器模型和车辆模型部分，Matlab的自动驾驶工具箱提供了与Unreal Engine场景交互的摄像头、激光雷达、毫米波雷达等。

在这个demo中，默认的3D场景是密歇根大学的MCity，改为一个大型停车场场景，汽车模型也发生了变化。

另外，车身上放置了一个摄像头（下面视频左下角的图像就是这个摄像头生成的），仅用于显示，不用于处理。

以上是Simulink模型部分。 另外，因为我们需要运行虚幻引擎的3D场景，所以我们要准备一台高性能的PC。 我们这里不需要实时模拟机，个人电脑就可以了。

虚幻引擎的最低计算机性能要求：

经过实际体验，想要获得好的体验，电脑性能必须远高于这个配置，尤其是GPU。

我们使用的电脑是Intel NUC8I7HVK4 Core I7-8809G Pluto Canyon（下图），GPU是AMD RX Vega M GH，性能非常强劲，运行非常流畅。

demo版实用视频如下：

整个系统在Simulink中完成，不需要任何其他软件或硬件。 简单明了，能够清晰地呈现驱动在环系统的架构。

这是游戏机！

第二个位置是在游戏机上安装控制器。

第二个姿势和第一个基本一样，只是多了一个手柄~

第一种姿势有两个肉眼可见的缺陷：

让我们进行升级，添加游戏控制器，并增加车辆的复杂性，以满足各个年龄段的男孩和老人。

游戏手柄

游戏手柄采用HORI FPS PLUS。

手柄接口为USB，可直接插电脑。

手柄上有很多操作按钮，这些按钮信号需要读入Simulink中。

Simulink 提供控制器驱动模块（也适用于 Logitech 控制器）。 驱动程序模块是 Simulink 3D 动画工具箱的操纵杆输入。

Joystick Input 的输出轴和按钮包含很多信号，需要预先校准手柄按钮与这些信号的对应关系。

校准方法非常简单。 将 Joystick 输入拖到 Simulink 模型中，按下手柄上的按钮，然后查看 Joystick 输入的哪个输出信号发生变化。 校准结果如下：

车辆型号如下

需要对这个模型进行一些调整，比如将可变步长改为固定步长、用Joystick Input替换驱动程序模型、替换3D场景等。

整个架构如下图：

一切准备就绪后，就可以开始愉快的玩耍了，这样就多了几分刺激。

第三个位置是分离整个车辆模型。

以上两个版本纯属自娱自乐，只能离线玩（如极品飞车）。

当车辆模型在普通PC上运行时，实时性无法保证。 还是有点软，不够硬，不够凉！

比如我们小时候玩虎克船长这样的游戏，一旦坏人大量出现，游戏机内存耗尽，就会卡住。

因此，我们将进行升级，使测试方案更加先进，让车辆模型在实时仿真硬件中运行。

游戏手柄更换为罗技G29。 罗技 G29 是一款入门级驾驶模拟器。 它有USB接口、方向盘和踏板，方向盘有反馈。 它提供了出色的驾驶体验。 。

同样，G29也需要一个驱动模块来将信号连接到Simulink。 操纵杆输入仍然有效。 此外，Simulink 在 Simulink Real-Time 工具箱中提供了专用的 G29 驱动程序模块 - Steering Wheel Read。

校准 G29 和方向盘读数。

实时模拟器用于运行整个车辆模型。 它可以从任何主流制造商那里找到。 各大厂家都有相关产品。 它可以是 HIL 设备或快速原型。 它们本质上是同一件事。

第三姿势出现了一个非常重要的现象：多机协作

在经典的HIL架构中，例如dSPACE开发的发动机控制器HIL，多机协作是指编辑测试用例和编译模型的PC与运行模型的实时仿真机之间的分离。 目前描述的第三种姿势，它的“多机协作”是指场景运行在普通PC上，车辆动力学模型运行在实时仿真机上。

场景相关部分仍然在主机上运行。 原因在于，实时操作系统本质上是一台缺乏GPU的大型单片机，几乎没有实时操作系统能够支持3D场景软件。

。

第三姿势的结构如下图。

实时仿真平台和上位机各运行一个Simulink模型。 前者是运行车辆模型，后者主要是运行场景相关模型。

接下来就可以再次愉快的玩游戏了。

第四个位置是分离整个车辆模型。

上述所有解决方案都是基于手动驾驶。 甚至第三种姿势也没有自动驾驶模块，完全依赖手动操作。

从现在开始，我们需要考虑到自动驾驶。

上位机场景软件可输出传感器（摄像头、超声波、激光雷达）的检测结果。 我们将这些传感器的检测结果通过对象列表级别发送给实时仿真机，由实时仿真机进行融合和决策。

车辆模型，融合决策模型，把它们放在一起

架构如下：

实时仿真平台不仅运行车辆模型，还运行传感器融合和决策控制算法。

上位机PC将传感器模型检测结果发送至实时仿真平台。

需要提到的是，这个检测结果是物体列表级别的，而不是图像、激光雷达点云等。说白了，这个方案的传感器识别是通过模型来实现的，而不是通过真实的测试物体进行检测。

一个最基本的两机无人驾驶演示Demo已经实现了。

第5步：添加实时机器来做出融合决策

上面的例子都有一个特点：

纯属自娱自乐，不涉及DTU，既没有待测设备，也没有快速原型。 除1、2、3三种姿势外部信号采集属于实物外，其他工作均在PC机中虚拟完成。

该解决方案大部分仍用于科研回报演示。 对于DTU的实际算法来说用处不大。 接下来我们介绍一下DTU或者RCP。

通常情况下，无论是车企还是供应商，自动驾驶领域的主要测试工作都是识别和融合决策。

对于识别过程，目前已有不少传感器供应商能够完成。 他们的相机控制器可以直接在对象列表级别输出 CAN 信号。

事实上，大多数用户在集成决策过程中只能做出手势。 这是最不困难的部分，试错成本较低，可以让用户练习技能。

第五种姿势架构如下图。 添加“实时机2”。 将“融合与决策控制”的功能模块从实时机1中取出，移至实时机2中，用户可以随意做，做实验。

姿势六、从霰弹枪切换到大炮，并执行识别功能

如果传感器供应商实力比较弱，无法进行识别怎么办？

没关系罗技摄像头软件，我们可以选择更强大的ADAS控制器或快速原型，并负责识别工作。

于是，著名的感知环测试验证方法就诞生了。

世子一号无情地把Posture 5中的薄型快速原型机换成了NVIDIA Drive PX2或者Xavier，从而打造出了下图所示的Perception-in-loop测试框架。

信号流⑤是主机PC发送到NVIDIA Drive PX2/Xavier的图像和激光雷达点云等原始数据，而不是对象列表级数据。

NVIDIA表示没有压力，毕竟世界第一的实力可不是吹牛的！

姿势7，没有最好，只有更棒

第五个手势输出识别出的对象列表，第六个输出是原始图像。

那么，有什么新的玩法吗？

一定有！

第七个手势是输出图像和对象列表之间的私有协议数据。 这个东西就像是相机传感器和相机控制器之间的传输协议。 行业没有统一标准，需要定制！

因此罗技摄像头软件，您也会在市场上看到这样的解决方案：

这应该是目前市场上技术难度最高、最先进、成本最高的无人驾驶测试方案……你买了，走出大门后气质恐怕会不一样。

总结

无人驾驶测试方案的设计相对灵活。 不同的方案有不同的技术指标、不同的侧重点、不同的使用方法，这都会对后续的使用和公司的系统建设产生影响。

无论HIL解决方案如何千变万化，都逃不开世子一号《HIL27讲座：从根本原理谈HIL切割方法》中提到的“虚实切割”的概念。 有兴趣的朋友可以到《车辆科技》公众号主菜单“原创干货资料”→“原创连载”中找到这篇文章，看一下。

如果“切入点”更靠外，放置在摄像头传感器前面，就会成为“黑匣子”解决方案。 这种方案受环境影响较大，不符合逻辑的特点，所以不再介绍。

车辆技术公众号认为，需要根据自身情况选择最适合的测试技术路线。

【推荐】