首页/文章/ 详情

从简单到复杂|自动驾驶硬件在环HIL测试的7种玩法

李慢慢

1年前浏览1387

大家好，我是李慢慢。

最近一直在外出差，搭建HIL台架，遇到了挺多困难，不经意中发现网上已经有大佬分享过相关文章（来自公众号-车辆技术），帮了我大忙，相见恨晚，分享给大家。

以下原文（多有改动）：

上一讲我们说了，2017a的Matlab，自带了一系列“车辆动力模型”，直接导致业内HIL中的“一维纵向动力学模型”从高端商品沦为了地摊货，生意不好做了。

作为宇宙最强工程IDE，并没有就此止步，它在2018版中进一步发布了全自由度的车辆模型，并且还自带场景。

真是以一己之力，挑战“Prescan+Carsim”的黄金组合。

我们今天就拿它来讲述一下若干种无人驾驶测试方案。

玩法1-给自己做个简单游戏机玩儿

MATLAB/Simulink提供了一个可用于驾驶员在环的基础demo模型。网址：https://www.mathworks.com/help/vdynblks/ug/scene-interrogation-reference-application.html?s_tid=mwa_osa_a

这个模型简单明了，如下图：

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

可以将这些控件模块与模型中参数关联，方便地调节参数，然后就能愉快地玩游戏了。

因为是基础demo，所以车辆模型做了很大的简化。

3D场景部分，渲染引擎用的是Unreal Engine。

MathWorks结合游戏引擎Unreal Engine构建高保真度的驾驶场景。

传感器模型以及车辆模型部分，Matlab的utomated Driving Toolbox，提供了与Unreal Engine场景交互的摄像头、激光雷达、毫米波雷达等。

该Demo中，默认的3D场景是密歇根大学的MCity，此处改成了大型停车场的场景，同时也把车型换了。

另外，还在车身上放了一个摄像头（下面视频左下角的图像就是该摄像头产生的），仅做显示用，不做处理。

以上是Simulink模型部分。

除此之外，因为需要运行Unreal Engine的3D场景，所以我们得准备一个高性能的PC电脑（此处我们还用不到实时仿真机，个人电脑就行）。

Unreal Engine对电脑性能的最低要求：

Graphics card (GPU) — Virtual reality-ready with 8 GB of on-board RAM
Processor (CPU) — 2.60 GHz
Memory (RAM) — 12 GB

实际体验下来，如果想要获得不错的体验，电脑性能要远高于这个配置，尤其是GPU。

我们用的电脑是英特尔（Intel） NUC8I7HVK4 酷睿I7-8809G冥王峡谷（如下图），GPU是AMD RX Vega M GH，性能挺强的，很流畅。

Demo版实操视频如下：

整个系统全部都在Simulink中完成，不需要任何其他软硬件，简单明了，能清晰地呈现驾驶员在环系统的架构。

这就是一台游戏机！

玩法2-再给游戏机装个手柄吧

玩法2和玩法1本质上是一样的，只是加了个手柄，用来代替鼠标操作~

第一个姿势，有两个肉眼可见的不足：

没有真实的车辆操纵设备，驾驶体验欠缺
车辆模型比较简单，无法较好地呈现车辆的特性，翻车、颠簸的时候，不够逼真

让我们来做个升级，增加游戏手柄，提高车辆复杂度，满足男孩子以及老男人全年龄段的喜爱。这个游戏手柄，我们采用的是HORI FPS PLUS。

手柄接口是USB的，直接插到电脑上即可。

手柄上有很多操作按键，要将这些按键信号读到Simulink中。

Simulink提供了手柄的驱动模块（罗技手柄也适用），驱动模块是Simulink 3D Animation 工具箱的Joystick Input。

Joystick Input的输出Axes和Buttons包含了很多个信号，需要预先标定手柄按键和这些信号的对应关系。

标定方式很简单，把Joystick Input拖到Simulink 模型中，按下手柄的某个按键，看Joystick Input的哪个输出信号有变化。

标定结果如下：

车辆模型如下：

需要对这个模型做些调整，比如将变步长改成定步长、将驾驶员模型替换成Joystick Input、替换3D场景等。

整个架构如下图：

一切ready之后，就可以愉快地玩起来了，更爽了一点点，有没有？

玩法3-把整车模型拆出来

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

车辆模型跑在普通PC电脑中，实时性无法保证，还是有些偏软，不够硬，也不够爽！

就比如我们小时候玩铁钩船长之类的游戏的时候，一旦坏人大量出现，游戏机内存不够了，就会特别卡。

所以，我们再来做个升级，把测试方案搞得更加高大上一些，将车辆模型拆分出来，让车辆模型跑在实时仿真硬件中（以下简称实时仿真机）。

在此之前，我们将游戏手柄用罗技G29代替。

罗技G29是一个入门级的驾驶模拟器，接口是USB的，有方向盘和踏板，方向盘带反馈，驾驶体验杠杠的。。。

同样的，G29驾驶模拟器也需要一个驱动模块将信号接入到Simulink。Joystick Input依然适用。另外，Simulink提供了专门的G29驱动模块-Steering Wheel Read，在Simulink Real-Time工具箱。

接下来，对G29和Steering Wheel Read进行标定。

然后是最重要的实时仿真机：

实时仿真机用于跑整车模型，随便找个主流厂商的均可，各大厂商均有相关的产品，HIL设备或者款速原型均可，本质上属于同一个东西。

这个时候已经出现了一个很重要的现象：多机配合。

在经典HIL架构中（比如dSPACE搞的针对发动机控制器的HIL），多机配合指的是编辑测试用例、编译模型的PC，和运行模型的实时仿真机之间的分开运行。而在当前描述的方法中，多机配合指的是，场景运行在普通PC上，整车动力学模型运行在实时仿真机中。

场景相关部分仍然运行在上位机电脑中，原因在于，实时操作系统本质上就是个大号的单片机，缺乏GPU，而且实时操作系统几乎没有能够支持3D场景软件的。

方法3的架构，如下图。

实时仿真机和上位机PC中各跑了一个Simulink模型。前者跑的是车辆模型，后者主要跑的是场景相关模型。

接下来，又可以愉快地玩游戏了。

玩法4-让车辆自动驾驶起来

上面讲的所有方案，都是基于人工驾驶。

从现在开始，我们需要考虑到无人驾驶，这个时候，最终要的变成了算法。

上位机场景软件，是可以输出传感器（摄像头、毫米波、激光雷达等）的检测结果的，我们把这些传感器的检测结果，通过object list（目标列表）发送给实时仿真机，实时仿真机来做融合和决策。

车辆模型、融合决策模型，放一起跑。

架构如下图：

这个时候，实时仿真机不仅运行车辆模型，还运行了传感器融合、决策控制算法。

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

需要说一下，这个检测结果是object list级别的，不是图像、激光雷达点云等，说白了这个方案的传感器识别是通过模型实现的，而不是通过真实测试对象来检测的。

一个最基本的双机无人驾驶演示Demo就实现了。

这个时候，我们的虚拟车辆终于可以脱离鼠标或者游戏手柄或者驾驶模拟器自己驾驶了，不过车辆的驾驶行为完全取决于算法。

玩法5-再加个实时机单独做融合决策

上面所有的例子，都有一个特征：

完全都是自娱自乐，没有 DTU参与，既没有被测件，也没有快速原型。除了1、2、3三个玩法外，外部信号采集属于真实零部件之外，其他的所有工作都是在PC里虚拟完成的。这些个方案，多数还是用于科研汇报演示，对于DTU的实际算法，用处还不是很大，下面我们引入DTU或者RCP。

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

对于识别环节，目前而言，相当一部分传感器供应商已经能够完成了，它的摄像头控制器，能够直接输出object list级别的CAN信号。那么，大多数用户也就只能在融合决策环节比划比划，这一块难度最小，而且试错成本低，可以让用户练练手。

现在我们基于此，增加一个“实时机2”，把“融合、决策控制”的功能模块从实时机1中拿出来，再挪到实时机2上面，随便用户搞，做实验。架构如下图所示。

玩法5和玩法4差别不大，都是自动驾驶，区别仅在于玩法5把融合决策算法拿出来单独运行。

玩法6-也做做识别功能

如果传感器供应商比较弱，做不了识别咋办？

没关系，我们可以选择更强大的ADAS控制器或者快速原型，把识别环节的工作也给包了。于是就诞生了大名鼎鼎的Perception-in-loop的测试验证方法。

我们把玩法5中那个“仿真机2”换掉，用NVIDIA Drive PX2或Xavier代替它，就有了下图所示的Perception-in-loop的测试框架。

这个时候，上图中信号流⑤是上位机PC发送给NVIDIA Drive PX2/Xavier的图像、激光雷达点云等原始数据，而不是object list级别的数据。

NVIDIA表示毫无压力，毕竟世界第一的实力不是吹出来的！

玩法7-自己玩儿传输协议

第5个玩法输出的是识别后的object lists。

第6个玩法输出的是传感器采集的原始数据。

那，还有没有新的玩法呢？

必须有！

没有最牛，只有更牛。

第7个玩法，就是输出图像和object lists之间的私有协议数据。

这个玩意就像是摄像头传感器和摄像头控制器之间的传输协议，业内没有统一标准，需要定制！所以，你在市场上可能还会看到这样的方案：

上面这套方案应该是目前市面上技术难度最大、最高大上、最贵的自动驾驶测试方案了……

看起来只是在上位机和域控制器之间加了一套设备，用来切换下输出数据的格式而已，为啥就贵了许多。

面对市面上N多种上位机模拟传感器输出的N多格式的数据，N多种下位机（域控制器）需要的N多输入格式的数据，能将两者之间搭建起来桥梁，实现上位机和下位机之间N多种数据的无障碍交互通信，谁敢说它不是功德无量！？

唯有一个字，买它，买它。

总结

总之，无人驾驶测试方案的设计，还是比较灵活的。

不同的方案，技术指标不同，侧重点不一样，使用方法也不一样，对后续的使用、公司的体系建设，都有较大影响。

本文完。

来源：车路慢慢

MATLAB 通信 Simulink 自动驾驶游戏控制渲染试验

著作权归作者所有，欢迎分享，未经许可，不得转载

首次发布时间：2023-06-21