网络多车辆实时仿真的同步算法

张 骋，陆 涛

(1. 浙江吉利汽车研究院，浙江 宁波 315336； 2. 福州大学物理与信息工程学院，福建 福州 350108)

0 引言

车辆智能行为验证与评估平台旨在对无人驾驶车辆的智能行为进行验证与评估，具有经济、 安全、 不受时间和空间条件约束等优点[1]. 国内最新研究成果是吉林大学开发的新一代先进智能驾驶模拟仿真系统panosim，为汽车电控与智能化技术与产品的研发提供高效和高精度的测试与验证[2]. 此外，享有很高声誉的汽车系统仿真软件CarSim，被广泛地应用于现代汽车控制系统的开发.

在2007年DARPA城市挑战赛上，11辆全尺寸的无人驾驶汽车首次在封闭的赛道上自由行驶. 期间，麻省理工学院的“塔洛斯”和康奈尔大学的“天网”在一场低速事故中相撞. 分析原因有： ① 传感器数据关联困难，导致难以察觉缓慢移动的车辆； ② 未能预测车辆意图； ③ 在运动规划中过分强调车道约束与车辆接近性. 人类道路使用者之间的眼神交流是车辆之间缓慢移动的近距离接触的重要沟通渠道. 车辆间通信对无人驾驶车辆也可能起到类似的作用，但还存在可用和拒绝服务的问题需要解决[3].

另外，在车水马龙的现实世界中行驶，周围往往是不遵守交通规定的人和车，这是非常棘手的问题.

真实世界的不同状况，如白天与夜晚、 变化的天气、 不同的道路情况和路面材料都会使问题变得更加复杂. 动态的环境增加了许多不确定性和变量，使机器人系统工程师们很难如以往一样将问题简化为一系列基本的假设[4]. 2018年3月18日，Uber自动驾驶试验车撞上横穿马路的行人事件再一次对无人车的实验方法提出了新的挑战.

无论是老牌的CarSim，还是新一代的panosim，都是针对单一无人驾驶车辆在规则场景的仿真，而对于多车辆协同和复杂环境实时交互的功能开发支持不足，在未来的无人驾驶功能开发上存在提升空间. 本项目针对这一空间进行扩展，模拟了以往较难实现的无人驾驶多车辆实时同步交互场景，以减少场地和道路试验的次数和风险. 该系统不仅支持单一设备上的多车辆仿真，同时还支持基于网络多设备的同一场景实时仿真.

本研究主要是针对这一实时系统中的关键技术——场景中多车辆之间的运动状态同步问题.

1 车辆模拟系统架构

图1 车辆仿真系统构架Fig.1 Vehicle simulation system architecture

车辆同步的系统架构如图1所示，表示分布在各终端的车辆之间以及终端内部车辆的同步关系.

服务器维护着所有车辆和交通参与者的状态数据，含有时间点、 速度和位置等信息，以及记录当前的状态参数，负责协调所有车辆的同步； 同一场景里，各终端通过网络连接至服务器，记录所有车辆的最新状态参数，公用物理引擎维护车辆和交通参与者在场景里的当前运动状态； 终端内的两种物理引擎，私有引擎承担车辆仿真功能的计算，与公用引擎同步，共同计算终端自己控制的车辆的运动状态.

仿真系统具有如下功能：

1) 模拟车辆行驶的外部环境的静态内容(如道路，交通信号灯，绿化，建筑等)；

2) 模拟动态内容(如行人，交通流量等)；

3) 接受驾驶行为输入，模拟被控制车辆运动行为、 车辆行驶反馈；

4) 支持多台智能驾驶模拟器互联，支持多台设备连入同一仿真测试环境；

5) 记录仿真测试环境中的数据(包括环境数据与车辆动态数据)，支持通过数据实现实验回放；

6) 记录数据能够实时备份，支持远程备份；

7) 支持升级，更新，自定义模拟环境中的各类视觉外观资源(如车辆，场景，静态动态内容等)；

8) 使用开放数据格式，提供第三方程序数据接口(ROS、 UDP等).

2 多车辆模拟系统的实现策略

有一种写实风格的竞速类网络游戏是以赛车为角色进行驾驶比赛的. 这种由完全仿真的车辆在逼近真实的环境中行驶，车辆之间、 车辆与环境的交互作用，得到运动学意义上的结果，正符合无人驾驶功能开发验证平台的期望. 以赛车类网络游戏技术作为基础，研制一种超越游戏用途，可以高速高效地仿真车辆间的实时交互，满足无人驾驶功能研发需要的开发验证平台，这就是本项目的设计思路.

游戏技术中的物理引擎由运动学计算和碰撞检测组成. 物理引擎能遵循科学的规律自行推演刚体运动，而不必依靠编写脚本，比如描述车辆的颠簸、 所到达的位置等. 碰撞检测可以探测各物体的物理边缘，当两个3D物体撞在一起的时候，防止它们相互穿过，碰撞探测会根据物体和墙之间的特性确定两者的位置和相互的作用关系.

将游戏技术中的物理引擎作为本系统的公用物理引擎，构造车辆的运动学模型，描述车辆之间、 车辆与环境之间的交互关系.

科学仿真中的要求是能够集成车辆的所有动力部件和辅助系统，提供所需要的数据结果. 然而，游戏技术中的物理引擎侧重于实时近似[5]，无法提供建立车辆仿真数学模型的计算精度. 为兼得仿真精度和实时速度，本项目优化设计了一套只针对车辆的科学仿真物理引擎，私用于每辆车的内部系统，构造车辆的动力学模型[6]. 私用物理引擎与公用物理引擎并行计算，大大简化了系统计算复杂度. 在保留实时性的同时又有科学仿真的真实性，还能运行在通用的计算设备上，甚至可运行于更为资源受限的平台(比如手持型游戏设备和移动手机)，而不需要配置昂贵的专用设备.

单一软件平台两种物理引擎，其关键是动力学模型与运动学模型的同步. 单终端上可以有多辆车在同一场景中，多车辆关键是各辆车运动状态的同步. 当扩展至网络分布式系统，关键就是各终端所控制的车辆与其他终端的车辆的运动状态的同步，由网络服务器协调. 这就是本系统的同步策略.

3 多车辆模拟系统的同步算法

3.1 统一基准时钟

多车辆实时仿真时，有单终端或多终端并行两种工况. 单终端是以终端本身的时钟为标准. 多终端由于运行在开放的网络环境中，存在时钟的不确定性，因此需要引入统一的时间基准. 本方案使用服务器设定时钟为统一时钟. 终端的时间校准方式是，终端发起请求服务器时间，服务器收到请求向终端发送基准时间，终端使用收到的服务器返回的时刻减去发起请求的时刻得到往返延迟，用服务器发送的基准时间加上1/2往返延迟估算出基准时间和传输时间. 误差一般在毫秒以下.

3.2 基于运动学的预测

由于系统要求极高的实时性，必须有预测机制. 对于终端自控的车辆，私有引擎进行驱动力预测，把每帧结束时刻的状态作为当前状态. 对于场景中其他终端的车辆，公有引擎进行运动状态预测，以收到的数据包中最新时间戳的相关数据为当前数据. 这里使用的转移矩阵，根据车辆动力学模型，以车辆技术的经验数据为依据[6]，预测与实际车辆运动状态有很高的吻合度. 系统的运行过程就是一个预测执行—同步制约的过程.

3.3 单终端车辆的同步

系统采用分层的状态同步方式： 在终端内部，车辆仿真与场景仿真通过交换位置数据和速度数据的方式实现同步. 算法流程示意图如图2所示，表示在客户端内部，每台车辆通过与场景交换数据来取得车辆间的同步.

图2 终端内部流程示意图Fig.2 Terminal internal synchronizatiion diagram

图3 终端内部同步时序示意图Fig.3 Terminal internal synchronization sequence diagram

在终端内部，公用引擎计算出当前时刻各台车的位置相关的数据，私用引擎读取后更新各车辆的位置管理器参数，并分析与预测值的误差因素，如是否有碰撞等被动力的作用. 接着依据动力系统(这里包括被测控制器的因素： 人在环的操控，软硬件在环的测试)的驱动力，预测出下一时段的速度相关数据，公用引擎读取并更新速度管理器参数，运行到下一时刻检测碰撞并计算出与位置相关的数据，完成一个帧循环，既实现了车辆的驱动力与车辆行为的同步，也实现了各车辆之间的同步. 时序如图3所示.

周期中，Tn—t1读数据，t1—t2计算，t2—t3写数据，t3—Tn+1空闲. 红色虚线表示状态数据，蓝色虚线表示速度数据. 公用引擎的周期通常选择10 ms，可以达到运动学仿真需求，而私用引擎以5～10倍于公用引擎的频率进行计算，使车辆动力学模型的仿真更为精确.

3.4 多终端车辆的同步

在网络上，各终端都通过与服务器交换数据同步到场景中，以实现跨终端同步仿真，并可弹性扩展至大规模车辆仿真，可模拟车流量聚集的堵车场景. 算法流程示意图如图4所示，表示由服务器来执行在不同的客户端上数据的同步.

图4 多终端同步示意图Fig.4 Multi-terminal synchronization diagram

在以服务器为核心的分布式网络上，各终端在每个帧循环结束时刻把本地所维护对象的当前状态数据(时间戳，位置坐标，方向速度，等)报告给服务端. 服务端接收到数据包后向同一场景中的关联终端广

图5 多终端同步时序示意图Fig.5 Multi-terminal synchronization sequence diagram

播. 各终端依据服务端的推送，对公用引擎中的由网络中其他终端所管理的车辆和交通参与者进行处理： 以最新的时间戳的数据更新对象状态，然后预测并执行车辆的运动估计. 完成以上流程后，终端回到等待接收到服务器的推送阶段，直到实时仿真结束. 以系统的同步间隔在100 ms为基准，同步环境下各终端间的车辆位置误差在最高时速(120 km·h-1)过程中不超过0.5 m，速度越低误差越小. 时序如图5所示.

服务器发送同步信号的频率低于本地公用引擎，延时几个周期.m1、m4为有效同步信号，m2信号丢失，由于m3延时落后于m4到达，失去同步作用，m5信号未画出.

3.5 视景同步

由于仿真过程中同时希望屏幕上要有一致的视觉效果[7]，渲染引擎的数据与场景计算结果的同步如图6所示. 有效的同步算法协调运行中的各线程平滑衔接，让系统整体稳定有序地运行.

图6 车辆仿真时示意图Fig.6 Vehicle simulation time diagram

仿真运行时，渲染引擎读取公用物理引擎每个循环计算的运动状态数据，更新自己的数据，在屏幕上显示，完成画面的一帧. 得到的就是数据和画面完全一致的，仿真度达到需求的，非常接近真实的评估和验证结果.

4 运行测试

图4的服务端启动，从数据库读取服务器配置，等待登录车辆. 当第一个终端启动场景仿真运行时，服务端的同步被激活，直到收到最后一个连接的结束通知. 停止同步，清理场景数据，进入休眠，等待下一次场景的启动.

图2的客户端启动，车辆登录服务器，根据设定从数据库读取车辆的配置. 选择场景，开启车辆仿真功能，激活服务端的同步. 双物理引擎根据外部控制器的输入，同步计算出车辆的位置、 速度、 姿态等状态参数的改变，反馈给控制器. 外部控制器包括人在环的驾驶模拟器、 在环测试的智能驾驶的软硬件产品. 记录并输出仿真数据，运行结束后关闭场景，通知服务端.

图6渲染引擎和物理引擎初始化后，车辆模型启动，然后三个模块并行执行. 根据车辆模型的状态参数的改变、 公用物理引擎的场景更新，渲染引擎不断更新画面数据，以不低于60 Hz的频率刷新屏幕. 可以得到与科学仿真同步的，与实际场景吻合度非常高的视景画面.

本系统曾经的用户有： 有大众尚酷、 福田 MPX、 福田 Ollin、 凯迪拉克 CTS-V、 吉利 EC8、 GC9 等.

模拟驾驶仿真视频的回放截图如图7所示，这是一场跟车制动的在环测试，两个版本的AEB-P主动安全系统分别接入仿真系统，测试工况为： 城市高架路，40 km·h-1，30次.

图7中，前车是人工驾驶，后车是无人驾驶. 前车随机刹车，后车自动制动，记录两车间距. 两台车辆均执行高精度动力学仿真. 测试结果数据如图8所示.

图8中的x轴为测试次数，y轴为车距，蓝色曲线图是优化前的版本的数据，橙色曲线表示优化后的版本数据，两次的测试结果，反映了车辆中的AEB-P功能，在优化后跟车制动的间距波动范围变小，稳定度提高. 这个仿真结果与实车测试结果吻合度非常高. 仿真平台发挥了预期的作用.

图7 双车跟车测试视频截图Fig.7 Screenshot of the two-cars follow test video

图8 双车跟车测试结果数据Fig.8 Datas of the test results of both vehicles and vehicles

图9 多车仿真视频截图Fig.9 Screenshot of multi-vehicle simulation video

仿真实景视频截图如图9所示，模拟了复杂环境中的跟车制动场景. 共3台车参与测试，前车是人工驾驶，后两跟车是自动驾驶，黄色主视角车为中间车，除了测试本车的跟车制动，还测试被后车追尾的可能性. 这样的复杂环境工况，真实环境实车测试很不现实，做重复试验几乎完全不可能. 本仿真系统为复杂工况的功能测试提供了可能.

画面中的环境是地图商提供的卫星实景[8]，25 km虚拟现实场景，场景中有大量的运动物体，包括参与交通的其他仿真车辆，也有单纯作为干扰障碍的车辆模型.

5 结语

传统的车辆仿真系统，多车辆仿真难以在统一环境下实现，需要多个软硬件联合仿真，本方案使用公用物理引擎模拟所有交通环境场景和车辆本身的运动，仿真系统得以优化. 针对仿真车辆额外附加的私有物理模型，使综合平台仍然保持了车辆独立仿真时才拥有的高拟真度. 本算法实现了多客户端，多车辆联合仿真的状态同步系统. 通过同步多个仿真环境中的交通参与者行为、 车辆运动学观测以及时钟信号，使需要多车配合才能实现的场景成为可能.