IEEE智能车辆汇刊，第4卷，第3期，2019年9月 375

无实时性约束的硬件在环自动驾驶仿真

克雷格·布罗格尔,张超,林凯利,和托马斯·布劳恩尔

摘要

仿真技术是自动驾驶研究的基石，使得测试能够比仅使用硬件平台更快速地进行，并显著降低风险。仿真系统必须能够模拟多种传感器，包括摄像头和激光雷达，以便对图像处理和路径规划等高层软件进行测试。本文提出了一种无实时限制的硬件在环仿真系统。该系统基于CARLA，可访问测试高层软件所需的传感器，同时集成了与自动驾驶车辆平台相同的计算硬件，以提供关于可用处理能力的真实约束。此外，我们探讨了大学生方程式赛车车辆上使用的基于机器人操作系统的软件框架及其与驾驶模拟器的集成。最后，我们通过实际的自动驾驶硬件平台对仿真系统的传感器输出和车辆动力学进行了验证。

索引术语

自动驾驶，软件框架，驾驶仿真。

一、引言

西澳大学（UWA）的可再生能源汽车（REV）项目目前专注于自动驾驶应用的开发。该开发主要在一个硬件平台上进行，该平台由一辆改装为电动驱动的大学生方程式赛车（FSAE）组成，配备IbeoLUX激光雷达、XsensMTi‐G‐710惯性测量单元（IMU）/全球定位系统（GPS）组合以及多个用于感知的摄像头、英伟达JetsonTX1计算平台，以及完整的线控驱动功能。无人驾驶FSAE项目的目的是提升车辆在赛道上行驶时的自主程度，从依赖通过谷歌地图驱动的网页界面手动设置的航路点，逐步过渡到完全依靠车辆上各类传感器的输入。最终目标是使车辆能够在没有任何先验知识的情况下，自主行驶并绘制出半结构化赛道（赛道边缘由锥桶界定，如图1所示，或道路边缘），生成优化路径，并以更高的速度重新完成赛道行驶。

该平台配备了多种硬件安全系统，并具有诸多优势，例如机械结构简单（从而降低了维护需求）并且能够轻松进行修改）以及能够为车载传感器和硬件提供充足的电力。然而，由于它是一辆重达250千克、速度可达80公里/小时的车辆，因此必须满足严格的安全要求。此外，它并非道路许可车辆，无法在公共道路上进行测试。这些问题促使了开发一种无实时限制的硬件在环仿真系统，旨在允许在更广泛的环境中进行更频繁的测试，同时将风险降至最低，但仍保持对可用计算硬件的相同约束。

本文所述硬件在环仿真系统的可行性，尤其是在集成便捷性和可维护性方面，深受FSAE赛车当前所用软件框架的影响。因此，本文也将对该软件框架进行探讨。为了使仿真测试有效，必须在仿真与真实系统之间保持高度相似的车辆动力学和传感器输出。因此，

针对物理自动驾驶平台对HIL仿真系统的这些方面进行了验证。

本文的贡献包括：开发了CARLA与ROS之间的集成；验证了真实传感器测量值与仿真传感器测量值之间的相关性；建立并验证了无论是仿真还是真实车辆运行均无需严格的实时约束；并通过量化在真实车辆实验之前采用仿真实验作为初始步骤所节省的时间。

本文其余部分组织如下。第二节介绍了当前在FSAE赛车上使用的软件框架。第三节介绍了用作驾驶模拟器基础的开源软件，并详细说明了其与FSAE赛车所用软件框架的集成。第四节概述了FSAE赛车上的可用传感器以及仿真软件中对应的传感器，同时介绍了FSAE赛车上现有的锥桶检测和路径规划算法。第五节展示了我们的实验与结果，随后第六节讨论了可能的未来工作。最后，第七节给出了结论。

II. 软件框架

本节介绍当前在大学生方程式赛车上使用的软件框架。鉴于该软件作为自动驾驶车辆的开发平台，必须具备灵活性和可扩展性，以便于轻松集成新组件，并且能够抵御软件故障。这一系列需求促使采用了发布/订阅软件架构，因为它支持开发高度解耦的软件，仅需最少的共享依赖，每个组件（或一系列组件）只需符合预期的输入和输出消息类型即可。此外，这也允许根据组件的重要性和所需性能特性使用不同的编程语言进行开发，从而缩短简单非关键组件的开发时间。采用发布/订阅架构还允许组件的灵活替换，简化了不同解决方案的测试，并提供了简单的日志记录、数据采集和数据回放方法，而无需单独修改每个组件。

基于阿波罗自动驾驶项目[2], 的成功，决定采用机器人操作系统[3] 作为基础系统，以提供所需的发布/订阅功能，因其展现出的鲁棒性和性能。此外，这还提供了一系列潜在的未来升级路径，包括过渡到阿波罗平台[4]，以通过共享内存传输实现消息传递、Protobuf消息支持以及去中心化来提升性能，减少单点故障；或在获得支持的硬件平台时，采用完整的阿波罗自动驾驶平台。当前使用机器人操作系统可确保所开发的任何组件在此升级路径的各个阶段均保持兼容，同时还能访问大量现有组件和库，最大限度地减少团队为支持常规操作所需开发的支撑代码和工具数量。

为实现REV项目当前目标所需的设计节点和消息传递，深受两个开源自动驾驶平台阿波罗自动驾驶软件架构中定义的软件模块及其交互方式的影响。

[2]和Autoware[5]。阿波罗自动驾驶是由百度主导的项目，合作伙伴包括福特等主要汽车制造商以及英伟达和速腾聚创等自动驾驶硬件供应商。该项目旨在到2021年底实现高速公路和城市道路的完全自动驾驶，并已应用于在封闭场所运营的100多辆自动驾驶接驳车上[6]。Autoware是一个类似的项目，已被超过100家公司采用，并且有资格在日本的公共道路上运营无人驾驶车辆。

这些项目的高层架构（其中之一如图2所示）在各系统的数据和控制流方面表现出显著的相似性。这始于传感器套件的环境数据，随后是定位和感知模块，处理后的数据再由规划和控制模块使用。为FSAE赛车开发的软件框架正是基于这些架构的共性设计而成，并进行了适当的调整，以确保与FSAE赛车上的可用硬件兼容。例如，由于缺乏足够高分辨率的激光雷达，已进行相应调整以消除对高精度地图的需求。

由于基于发布/订阅框架的灵活性，这仅是所需功能的概要，且显示的部分节点有可能被分解为一系列更小的组件。例如，如图3所示，通过将“目标过滤器”节点拆分为两个节点，可以加快多种“目标过滤器”节点的开发：一个用于简单地将传入的对象数组合并为单个数组（“对象数组拼接”），另一个用于执行过滤操作（“目标过滤器”）。以这种方式开发节点还提供了额外的好处，例如仅需一个组件

第三节 驾驶模拟器

驾驶仿真系统长期以来一直是降低高级驾驶辅助系统开发成本的核心手段，并被主要汽车制造商广泛使用。鉴于监管环境的不确定性可能阻碍自动驾驶汽车的发展，Waymo、Cognata、rFpro和英伟达等公司，以及英特尔、丰田和计算机视觉中心之间的开源合作，正在通过开发自动驾驶仿真器来推进这些理念，以便在没有监管障碍的情况下对自动驾驶汽车进行训练和测试。此外，驾驶模拟器能够快速执行一系列预定义场景的测试，同时也可用于模拟驾驶过程中不常遇到的场景。这些系统已成为自动驾驶汽车测试的基石，例如Waymo仅在2017年就完成了相当于43亿公里的模拟驾驶测试。

尽管REV项目过去曾使用过自动驾驶模拟器[21],，但考虑到其不支持激光雷达作为传感器、图形过时，以及与外部系统集成开发的复杂性，有足够的理由转向更现代的仿真平台。因此，所开发的驾驶模拟器以CARLA开源驾驶模拟器为核心[19],，因为它提供了所需的传感器和可定制场景，且无需昂贵的许可或硬件成本。默认情况下，CARLA通过PythonAPI提供对一组可配置传感器数据的访问，包括摄像头和激光雷达，同时还提供仿真自动驾驶汽车当前位姿、速度和加速的信息。此外，CARLA还提供了有关其他仿真智能体的信息，从而实现结果的自动验证，并且它基于流行的gaming和仿真引擎虚幻引擎[22],开发，确保了未来对系统进行修改时有充足的工具和资源可用。

自动驾驶模拟器由一台计算机（Inteli7‐4770处理器，8GBDDR3‐1066内存，英伟达TitanX（Maxwell）图形处理器（GPU））组成，该计算机运行上述CARLA驾驶模拟器和ROS仿真节点，通过USB连接接收来自罗技G920赛车方向盘的输入，并通过网络连接与英伟达JetsonTX1进行双向通信，如图4所示。引入硬件在环（HIL）使得与纯基于软件的系统相比，能够显著缩小“现实差距”，因为所有车辆

响应是“真实”的，因为它们来自实际的驾驶计算机，并且符合“真实”车辆的时序条件。通过此设置，我们能够在简单环境中使CARLA以超过每秒30帧（FPS）的速度运行，而不影响FSAE软件在英伟达JetsonTX1上运行的性能。需要注意的是，该仿真系统无需实时约束，无论是在仿真端还是实际车辆控制端均无此要求。传感器数据将在计算完成后提供给连接的硬件，但不保证响应时间。该设置如图5所示，同时包括用于提供逼真驾驶环境的显示器和赛车座椅。

由于选择了ROS作为基础，FSAE赛车软件框架与CARLA驾驶模拟器之间的接口得到了极大简化。ROS支持通过网络连接实现设备间通信，而第二节中详述的软件框架则允许组件或组件组轻松地替换。这使得接口仅由一个用Python编写的ROS节点构成，该节点从CARLA应用程序编程接口获取传感器和环境数据（具体包括两个摄像头视频流、一个激光雷达点云以及车辆的姿态和速度信息），并将这些信息发布到视频处理和激光雷达处理节点所期望的主题上。然后，该节点接收来自导航/路径规划节点的控制数据，并利用这些数据生成CARLA驱动仿真车辆所需的控制对象。该节点替代了图6中所示的融合与定位、摄像头、激光雷达以及底层节点，从而形成了图7所示的应用架构。

由ROS实现的设备间通信对于在自动驾驶模拟器中使用真实的计算硬件至关重要。这使得仿真软件和结果验证可以在辅助设备上执行，而FSAE软件则在与FSAE赛车上安装系统相同的英伟达JetsonTX1上运行。这样可以在不影响高层软件性能的前提下进行高质量的仿真，同时仍为高层软件提供类似的性能约束。这确保了在模拟系统上成功测试的软件能够在真实的FSAE赛车上几乎完全相同地运行，这一点已在第五节D部分得到验证。

在替换底层节点时，模拟器接口还承担了模拟底层控制器提供的多种安全系统的功能，例如允许通过手动干预来覆盖自主系统。这是通过处理来自键盘或罗技G920赛车方向盘的手动输入，并在模拟器接口中复现底层系统对这些输入的响应来实现的。此外，还可以将小型触摸屏显示器连接到英伟达JetsonTX1，以提供与FSAE赛车上相同的自主系统接口，从而能够在安全环境中进行用户界面测试。

CARLA模拟器的开源特性带来了额外的优势，例如拥有一个活跃社区，能够提供故障排查支持，并为项目的功能、性能和稳定性改进做出贡献。迄今为止，主要优势体现在能够创建自定义场景以及导入自定义对象网格。然而，如果需要，未来也有空间进行诸如开发新型传感器等操作。

A. 性能及对真实时间操作的适用性

实体FSAE赛车上的控制系统采用ROS，且并非硬实时系统，因为它不保证固定响应时间。这在车辆控制中并非必需，因为所有传感器数据都是异步接收的。

表I 传感器和关键ROS节点的实际与模拟更新频率比较
图8.CARLA实现的帧率（蓝色）与控制节点更新频率（红色）的比较。

以不同的更新速率。因此，只要仿真传感器数据能够以相似且足够高的帧率提供，仿真系统本身也没有实时性要求。值得注意的是，阿波罗自动驾驶和Autoware均基于机器人操作系统，同样也不是实时系统。相反，这里仅需证明仿真系统生成数据的速率超过软件框架消耗数据的速率，从而确保软件框架在每次请求时都能接收到新数据。传感器生成数据以及软件框架中各个关键节点消耗数据的速率如表I所示。

相比之下，仿真系统平均以45FPS的速率生成和发布数据，其中95%的帧生成速率至少为24FPS，如图8所示。尽管IbeoLUX激光雷达以更高的频率生成数据，但这些数据被锥桶检测节点以仅10赫兹的速率消耗，远低于仿真系统提供传感器数据的速率。因此，该仿真系统能够在没有硬实时要求的情况下有效运行。

B. 时间同步

在ROS中，每个发送消息的头部都包含基于源计算机时钟生成的时间戳，将时间同步的责任转移给了操作系统。目前，仿真与自动驾驶软件节点之间的粗略时间同步依赖于一个共享的远程NTP服务器。根据Ubuntu的clockdiff工具测量，这导致仿真与自动驾驶节点之间的时钟误差为35毫秒[24]。

C. 仿真优势

可靠的高精度仿真系统的建立，在高层感知和规划模块的开发过程中大幅节省了时间，显著减少了测试每个软件模块迭代所需的时间。通过大幅缩短测试场景的搭建和拆除时间，实现了这些时间的节约。仿真的可用性所带来的大致时间节约

表二 自动驾驶测试的近似时间
图9.自主FSAE传感器架

系统在表二中进行了展示。从中可以看出，仿真系统每次测试可节省约110分钟，即近两个小时，使得测试能够更频繁地进行。此外，使用仿真系统可由单人完成测试，而实车测试至少需要三人以满足安全要求，从而每次测试节省了约330人分钟，并且不受任何硬件故障（如传感器失效）的影响。本质上，仿真系统发现的每个软件错误至少节省了五个人小时的测试开销，因为它避免了可能导致实车路测无效的问题。

IV. 传感器、导航和路径规划

FSAE赛车使用多种传感器（如图9所示），包括激光雷达、摄像头、轮式里程计和惯性测量单元，这些传感器分为四类：摄像头系统、航位推算、激光雷达系统和里程计。驾驶模拟器为激光雷达和摄像头系统提供了替代方案，并通过在模拟环境中提供精确位置定位，使航位推算和里程计系统变得不再必要，从而可以专注于摄像头和激光雷达系统，同时确保车辆定位数据的准确性。本节将介绍CARLA提供的传感器，并将其与当前安装在FSAE赛车上的传感器进行对比。此外，还将介绍用于测试该模拟器的路径规划算法。

算法1：激光雷达锥桶检测。
1: 过程 激光雷达锥桶检测 (激光扫描)
2: 裁剪 laserscan到[−90, 90]度范围
3: 对于 所有点 在激光扫描 中
4: 如果 点 是第一个点 那么
5: 初始化一个 簇 包含 点
6: else
7: 从 (这个_点,上一个_点)
8: 评估幅度,方向
9: 如果(幅度 或 方向)>阈值 则
10: 用点开始新的 簇
11: else
12: 将 点 添加到当前 簇
13: 结束 如果
14: 结束 如果
15: 结束 循环
16: 对于 所有簇 在激光扫描 中
17: 锥_中心 = 中心_点 的簇
18: 锥_大小 = 最近点 -最远点
19: 结束循环
20: 结束过程

A. 激光雷达系统

FSAE赛车当前使用的锥桶检测算法（详见算法1）依赖于单个前置的二维SICK激光雷达[25],，其水平视场角为270◦，角分辨率为0.25–0.5◦，探测范围可达20米。CARLA提供了一种360◦激光雷达，其探测范围、通道数量、旋转频率以及上下视场角限制[26]均可配置。为了模拟通过SICK的LMS1xxROS驱动程序[28],获取的LaserScan[27]数据，使用了pointcloud_到_laserscanROS软件包[29]，并结合具有窄垂直视场角的CARLA激光雷达配置。该组合可生成具有可配置水平视场角和角分辨率的LaserScan，从而匹配实际激光雷达的输出结果。

B. 摄像头系统

FSAE赛车目前配备了两个FLIRBlackflyGigE[30]摄像头。每个摄像头的最大分辨率为 1288 × 964像素，能够以30帧每秒运行。这些摄像头采用全局快门，因此无需计算硬件对滚动快门效应进行补偿[31],，例如[32]中提到的效应。CARLA提供了名为“scenefinal”的摄像头作为这些摄像头的直接对应模拟[26]。这些也是全局快门摄像头，CARLA提供了配置摄像头视场角、分辨率和位置的功能。利用此功能，仿真被设置为输出两个图像流，每个图像流的分辨率为 1288 × 964像素，并且间距与图9所示的FLIR摄像头布局相同。CARLA提供的摄像头帧率与其模拟器运行的帧率绑定。虽然可以在CARLA中设置固定的FPS目标，但这会阻止模拟器以真实时间运行，而这与我们的FSAE软件框架不兼容。因此，图像以CARLA运行的实际FPS发布到软件框架中，仅保留最新接收到的图像

算法2：视觉锥检测。
1: 过程视觉锥检测 (图像)
2: 将图像裁剪为 64 × 64块，步幅为= 4
3: 对于 所有块 在图像 中执行
4: evaluate特征_向量
5: 传递 特征_向量 到SVM_分类器
6: 如果不 块 包含 箔 则
7: 继续
8: 结束 如果
9: 对 色调_层 进行阈值处理以匹配颜色
10: 在 (x, y) 上对色调_掩膜 应用直方图
11: histo(峰值) = center(锥) in摄像头_frame
12: project center_点 ontoground_plane
13: 投影_点 = 锥_位置 inglobal_坐标系
14: 结束循环
15: 结束过程

算法3：路径规划。
1: 过程 CONEDRIVE (范围内的锥桶)
2: 初始化 转向_范围 至[−25, 25]
3: 对于 所有 范围内的锥桶 执行
4: 评估 与锥桶的碰撞_范围 与cone
5: 从转向_范围中排除碰撞_范围 从steering_范围
6: 结束循环
7: 如果转向_范围 为空 则
8: stop
9: else if all转向_范围 ≤阈值
10: 选择最大的 steering_range
11: else if所有转向_范围 >阈值 then
12: 选择转向_角度 变化最小的 当前方向
13: 结束如果
14: 驶向转向_范围的中心
15: 结束过程

存储后，视觉锥检测节点（详见算法2）随后以15赫兹至 30赫兹的频率按需检索该图像。

C. 路径规划

FSAE控制系统已实现路径规划功能，可支持沿一系列预设航路点行驶，或在车辆两侧布置的一系列交通锥之间行驶。本文将仅聚焦于锥桶驾驶场景，因为该场景具有更高的复杂性，且对处理能力要求更高，能够更全面地测试仿真系统。

当前路径规划过程的迭代版本使用对锥桶的障碍物检测来确定正确路径。当前代码与[33],相同，但进行了简化以允许更快的计算。我们的锥桶驾驶模块从地图、激光雷达或摄像头接收锥桶位置，并将其分类为物体。然后，车辆在由锥桶形成的赛道内安全导航，避免碰撞。通过使用车辆最大转弯圆的范围（包括左转弯和右转弯），系统会检查哪些预测路径将与锥桶相交。因此，在运动规划过程中限制车辆动力学，使转向角不超过

| 表III 不同转向角下的实际与模拟转弯半径 |

25◦。我们的算法将遍历车辆范围内的所有锥桶，并计算出最佳的无碰撞路径，如算法3中所述。

五、实验与结果

我们的仿真系统的验证通过一系列实验完成，这些实验涉及模拟车辆动力学、激光雷达和基于视觉的锥桶检测的精度、处理器负载监控以及系统响应时间，具体细节见第V‐A至V‐E节。

A. 车辆动力学

本实验旨在验证仿真车辆的动力学特性与实体FSAE赛车的相似性。为此，让真实车辆和仿真车辆执行一组预设动作，并记录车辆行驶的路径。实验进行了两个简单场景：以固定时长直线行驶，以及以固定转向角和速度行驶圆形轨迹。在线性行驶场景中，车辆从静止启动，加速至3 m/s的恒定速度，并在第五秒时完全制动，直至车辆再次停止。在此过程中，FSAE赛车平均行驶距离为13.4 m；相比之下，仿真车辆平均行驶距离为13.0 m，误差在FSAE赛车的3%以内。在转向角测试场景中，车辆以3 m/s的速度行驶，并采用多个固定转向角，测量其转弯半径。真实车辆和仿真车辆在这两种场景下的实验结果如表III所示，可以看出，仿真车辆的转弯半径平均误差在实体车辆的5%以内。尽管仿真系统表现出的车辆动力学存在一定误差，但在自动驾驶运行过程中，持续的反馈循环有助于最小化这些差异的影响。

表III 不同转向角下的实际与模拟转弯半径

B. 激光雷达锥检测

本实验旨在验证通过第IV‐A节所述方法在仿真中获得的激光雷达输出与FSAE赛车上所使用的SICK激光雷达生成的输出是否足够相似。这是为了确保锥桶检测算法能够在驾驶模拟器上进行测试，并能高度确信测试结果可适用于SICK激光雷达。为此，我们模拟了一个与之前FSAE赛车测试相似的场景，并验证了在该场景下使用相同的锥体检测算法能否检测到类似的锥桶集合。根据图10中展示的真实与模拟场景，各自场景下进行锥桶检测的结果（如图11中红色圆柱所示）具有足够的相似性。

原始激光雷达数据以绿色显示，检测到的锥体以红色显示。

允许在模拟系统上测试路径规划和避障等高级组件。

此外，通过在已知锥体布局上对真实和模拟激光雷达的激光雷达点云进行直接比较，验证了激光雷达精度，结果如图12所示。除了一些微小的不一致（可归因于物理锥体布局测量误差以及物理锥体与模拟锥体模型之间的细微差异）外，模拟点云与真实点云完全重合。

如算法1所示，基于激光雷达的锥桶检测通过聚类激光雷达点，并根据簇中的点数将它们分类为锥桶，该点数已根据SICK激光雷达的分辨率调整至锥桶能够被可靠检测的最大检测距离。为了确保该算法在模拟激光雷达输出上同样有效，测量并比较了在固定距离处不同尺寸和反射率的物体返回的点数。如图13所示，模拟激光雷达返回的点数与物理激光雷达相差在≈15%以内，并且随着距离增加，物体返回的点数呈现出符合实际的减少趋势。

激光雷达噪声对锥体检测算法的影响通过比较该算法在不同检测率下的表现进行了测试

默认模拟激光雷达输出，其对于构造良好的碰撞框表现出完美的精度，以及向该输出中引入人工噪声后的结果。这是通过将激光雷达数据经过一个滤波器实现的，该滤波器根据激光雷达传感器典型的高斯误差分布来修改每个点的距离。在两种情况下，观测到的平均检测率为≈95%，最低检测率为 ≈92%。这符合预期行为，因为SICK激光雷达的典型误差（±30 mm）明显小于锥体检测算法中使用的截断阈值，因此不会影响点聚类。

C. 视觉锥检测

本实验旨在验证通过CARLA的摄像头传感器（见第四节‐B部分）获取的图像与安装在FSAE赛车上的FLIR Blackfly GigE摄像头生成的图像足够相似，使得视觉锥桶检测算法能够在两组图像上产生类似的结果。图14给出了这些结果的对比。从中可以看出，锥桶在模拟图像上能够被成功识别，但检测范围有所减小。预计在模拟图像上的检测范围可以进一步提升。

表IV 基于计算机视觉的锥桶检测率在真实图像和模拟图像中的比较

表V 模拟图像相对于真实图像的检测指标偏差

通过将一些模拟图像加入训练集，可以提高性能。

该实验还旨在证明计算机视觉代码在真实图像和仿真器生成的图像之间的性能相似，这是通过监控当前在FSAE赛车上使用的锥桶检测算法的逐帧运行时性能实现的。这些时间数据如图15所示，从中可以看出，计算机视觉算法处理仿真图像的平均处理时间比处理真实图像快0.005%，而仿真图像处理时间的中位数比真实图像慢0.003%，证实了计算机视觉代码性能的相似性。

表IV展示了基于计算机视觉的锥检测算法在真实场景和模拟场景中的检测率。其中包括原始的模拟输出，以及经过后处理引入高斯分布加性噪声的图像。这是通过将高斯分布中生成的值（均值为 X ∼N(0, 20²)）添加到图像每个像素的RGB通道来实现的。表V展示了模拟图像与真实图像在检测指标上的偏差。在所有帧的平均值基础上，模拟图像相对于真实图像在三个检测指标上的平均偏差为8.3%，当引入噪声时，该偏差增加至8.7%。

D. 计算硬件负载

本实验旨在验证在仿真循环中使用相同的计算硬件（英伟达Jetson TX1）会产生与FSAE赛车平台相似的性能约束。该验证通过比较真实系统和模拟系统在执行类似任务（在此为基于激光雷达的锥体检测）时所使用的系统资源来实现。实验过程中，在两个系统上运行锥体检测算法的同时，使用Linux系统性能监控工具sysstat [34]收集数据。该工具以1赫兹的频率采集120秒内用户和系统进程所占用的处理器利用率百分比，从而计算出平均值，结果如图16b和图16a所示。从图中可以看出，仿真循环中的硬件在用户空间进程上的处理器利用率持续较高，平均达到 ≈25.2%（图16b），而真实系统上的用户空间进程平均利用率为≈20.6%（图16a）。

和真实(b)输入的基于激光雷达的锥体处理期间的处理器利用率)

鉴于在两种情况下，超过60%的处理器时间都处于空闲状态，因此用户空间进程的处理器利用率差异不太可能对应用性能产生显著影响。

E. 响应时间

鉴于仿真涉及通过网络连接传输图像和其他传感器数据流，因此需要进行验证，以确保这不会对系统的响应时间引入显著延迟。这是通过从仿真计算机发送控制指令，测量系统响应所需的时间，并将该结果与FSAE赛车上的相同测量值进行比较来实现的。实验结果如图17所示，可以看出，仿真系统的平均响应时间明显更低。由于当前测试主要在低速下进行，因此对于当前用例而言，这种差异被视为无关紧要；不过，可以在仿真系统中简单地添加人为延迟，以更好地模拟FSAE赛车。

VI. 未来工作

在当前的实现中，所有车辆动力学均由CARLA通过虚幻引擎的车辆物理模型完全处理。已通过调整现有车辆参数，对FSAE赛车在加速、制动和转弯操作中的稳定性进行了定性努力以实现匹配。通过完成真实车辆和仿真车辆在常见驾驶场景下的位姿定量比较，可进一步加强这一匹配。如果这些结果存在显著差异，则可以实施更精确的车辆物理模型。

我们的仿真系统对控制指令的响应时间明显低于FSAE赛车。为了提高仿真器的精度，建议在控制指令中增加处理延迟。

为了减小同步误差，我们计划采用一个本地网络时间协议（NTP）服务器，其在局域网中的典型精度可达几十微秒。改善时间同步后，当单个计算节点达到性能限制时，软件框架本身便可分布到多个计算节点上，并且整个软件框架可以与可用的GPS接收器提供的参考时钟保持同步。

尽管预计该级别的同步已足够，但通过使用精确时间协议（PTP）可进一步提高时间同步精度，PTP支持亚微秒级的时间同步精度[35]。

所描述的硬件在环仿真系统仅用于模拟接近理想天气条件，以复制西澳大利亚气候，该气候每年平均约有110个晴朗天和130个部分多云天气 [36]。因此，未来系统改进的一个关键重点是开发在较不理想天气条件下的场景，并验证在这些情况下传感器仿真的精度。

第七节. 结论

我们提出了一种硬件在环自动驾驶仿真系统，该系统能够在FSAE赛车上模拟多种传感器，且无需严格的实时约束。我们详细介绍了FSAE赛车所使用的软件框架架构，并说明了该框架因其高度的灵活性和可扩展性，如何简化了硬件在环仿真的开发过程。我们的设计方法是在商用硬件上采用积极维护的开源项目，从而实现了一个相对低成本的仿真解决方案，同时仍能够以高于FSAE赛车软件框架所需帧率的速度生成传感器数据。我们已证明，该系统允许在与FSAE赛车平台具有相似性能约束的环境中对软件进行测试。最重要的是，我们验证了通过该仿真系统生成的结果可应用于FSAE赛车，满足团队当前用例的需求。