智能车辆窄路协调通行的远端控制技术

滕政哲 林士飏 王界钦 张天淼 穆虎

（山东理工大学，淄博 255022）

1 前言

目前，国内对于车辆远程驾驶技术的研究大多集中在远程获取车辆的信息以及对简单电器设备的控制，包括远程控制车辆起动、打开和关闭车门、车辆定位等[1]。白云伟等人设计和开发出了一款远程控制车辆的APP，采用XMPP通信协议进行手机端和车载系统的通信[2]。曹正策等人提出基于车联网技术的分时租赁系统方案和分时租赁控制系统方案[3]。李治民等人提出了一种基于硬件在环半实物仿真平台的远程控制系统的测试方法[4]。

智能网联汽车研究目前主要集中在车辆的换道、超车、避碰，以及交叉路口附近车辆的协同控制。Nie等人提出了一种分布式自动驾驶车辆换道决策框架[5]。Michael Düring等人提出了自动驾驶汽车协同运动规划的方法[6]。Huang等人提出了一种新型混合控制系统[7]，利用人工势场的方法实现对车辆路径的规划和运动控制。然而，对于窄路场景下车辆的协同运动却鲜有研究，可以预见，若无相应机制，当两对向行驶的无人驾驶车辆进入窄路段，可能会触发前向避碰机制，使车辆停于窄路导致会车死结情况的发生。

为满足窄路场景下车辆协调通行需求，本文提出一种基于Android的车辆远程驾驶系统，通过Socket通信、蓝牙Socket通信、九针串口连接的方式建立从控制端到汽车CAN 网络的连接，使用户通过控制界面实现对车辆的加速、制动、转向的远程控制，使得窄路两侧车辆形成集群，以有效避免会车死结的发生，并对该系统集成于云端对于窄路场景下车辆通行效率的影响进行研究。

2 系统开发环境

电脑端的控制程序以Eclipse 2019 作为开发平台,控制界面（Server）通过Socket通信的方式实现与手机端（Client）之间信息的传递。本文选用JDK11作为编译和执行Java 程序的Java 开发环境，同时引入JavaFX11 作为外部依赖Java集开发控制界面。

手机端的控制程序以Android Studio 作为开发平台，利用蓝牙Socket 的通信方式实现手机与GCAN-203之间通信的连接，手机端的应用程序将从电脑端获得的控制字节流转传给GCAN-203。

3 系统总体设计方案

操作人员通过电脑端的控制界面发送控制车辆运动的指令给手机端APP，指令是由13 个字节组成的数据帧。手机端的APP 获取电脑端控制指令后将其转传给设备GCAN-203，GCAN-203 将该数据帧通过DB9 连接器传送到汽车的CAN 总线，从而实现对车辆运动的控制。系统总体设计方案如图1所示。

图1 远程驾驶系统总体方案

3.1 系统硬件组成

该系统硬件由笔记本电脑、Android 手机、设备GCAN-203、汽车4 个部分组成，其中，笔记本电脑选用惠普星14，搭载Windows 10系统，拥有16 GB运行内存，使用Intel Core i7处理器，满足电脑端Android控制主程序的需求。Android 手机选用华为Mate20x 5G 版手机，其操作系统为基于Android 9的EMUI 9.0，搭载麒麟980处理器，拥有8 GB 运行内存，可以使用5G 网络。GCAN-203 为沈阳广成科技有限公司的蓝牙转CAN 总线设备。汽车选用哈弗H7，该车辆经改造，后备箱内搭载dSPACE 公司的MicroAutoBox，有外接汽车CAN 总线的DB9连接器，以及为后备箱设备供电的超威12 V、60 A·h 的汽车蓄电池，转向盘下加装步进电机用于接收来自CAN总线的报文后进行转向动作。设备GCAN-203 是将电脑端的控制指令发送到汽车CAN 总线上的关键硬件，如图2所示。

图2 GCAN-203设备

目前，GCAN-203 已广泛应用于现场总线实验室、智能小区、工业控制、CAN 总线网络领域中的数据处理、CAN总线网络控制节点的数据采集等方面，该设备具有CAN-Bus通信波特率在5 Kb/s～1 Mb/s间任意可编程、使用9～24 V 直流供电、工作温度范围为-40～85 ℃、最高数据流量为300 帧/s 等性能特点，其6 个引脚的定义如表1所示。

表1 GCAN-203各引脚定义

为了保证设备GCAN-203 与汽车CAN 总线在车辆行驶过程中连接的稳定性，消除物理连接不良导致数据发送失败的可能性，制作九针串口的DB9连接器（公头）与连接汽车CAN 总线的九针串口母头相连。为使设备GCAN-203正常与汽车上的CAN 总线进行控制信息传递，需要将GCAN-203 的4 号引脚（CAN_L）与DB9连接器的2 号引脚（CAN_L）以及GCAN-203 的6 号引脚（CAN_H）与DB9 连接器的7 号引脚（CAN_H）用导线连接。

3.2 系统软件设计

3.2.1 电脑端软件的设计

本文将电脑端作为车辆运动的控制终端，利用Eclipse 开发平台，引入JDK11 以及JavaFX11 作为开发环境，进行程序的开发，该程序主要完成控制界面的设计、Socket 通信架构的搭建（服务端）、按钮点击事件的构建3个部分。

3.2.1.1 控制界面的设计

电脑端控制界面设计了上、下、左、右4 个键位，分别对应车辆的加速、制动、左转和右转控制。此控制界面的开发用到了JavaFX11 中一些jar 包中的方法，所以在Java编程的初始阶段需要导入javafx.*.*包，保证界面设计调用方法能够被正确使用。

3.2.1.2 Socket通信架构搭建

Socket 是一种相对底层的网络编程方式，是支持TCP/IP 协议的网络通信中的基本操作单元。在TCP/IP协议的5层模型中，Socket位于应用层和传输层之间，是抽象层。Socket的通信模型如图3所示。

图3 Socket通信模型

由该通信模型可以明确电脑端（Server）与手机端（Client）建立Socket 通信的编程流程。Server 服务端初始化时设置一个端口，本文选用端口55533，然后建立一个ServerSocket 绑定该端口号并对该端口进行监听，之后调用accept()方法为ServerSocket 接收请求并返回一个Socket对象。客户端初始化时需设置端口和IP，并建立一个Socket 绑定该端口和IP。本文双方建立连接后用getInputStream()和getOutputStream()的方法获得输入字节流和输出字节流，并建立缓冲区对数据进行读取。由于本文使用了Socket通信以及getInputStream()和getOutputStream()等方法，需要在程序编写的初始阶段导 入 java.net.Socket、java.net.ServerSocket、java.io.OutputStream、java.io.InputStream等jar包。

3.2.1.3 按钮点击事件的构建

完成控制界面的构建以及Socket 通信架构搭建后，为了在点击按钮时能够传递相应的控制指令，需要对按钮点击事件进行设计，事件构建流程如图4所示。

图4 点击事件流程

其中，计算机时钟内时间的获取使用Calendar.getInstance() 中 的get(Calendar.MINUTE) 方 法 以 及get(Calendar.SECOND)方法。按键按下与抬起时间的差值作为汽车加速、制动及转向动作幅度的依据，将取得的数值转化为对应的16进制数写入Socket通信模块中服务端的输入字节流，按键抬起时将对应的控制指令从电脑端发送到手机端。

3.2.2 手机端软件的设计

本文将手机作为控制信息从电脑发送到GCAN-203的中间设备，其作为客户端接收来自电脑服务端的字节流，同时将其通过蓝牙Socket 进行转传。手机端Android 主程序以Android Studio 为开发平台，该程序主要完成手机APP 主界面的设计、蓝牙Socket 通信的构建、Socket通信客户端程序的编写3个部分。

3.2.2.1 手机APP主界面设计

手机端主界面运用layout 中的activity_main.xml 文件设计Button 控件和TextView 控件。Button 控件完成对蓝牙的搜索连接任务，向Server服务端发送连接请求任务，TextView控件完成对来自客户端的控制指令的显示。手机端主界面如图5所示。

图5 手机端主界面

3.2.2.2 蓝牙Socket通信的构建

为实现手机APP 与设备GCAN-203 之间的蓝牙Socket 通信，需在配置文件中添加相关权限，包括允许程序连接到已配对的蓝牙设备、允许程序发现和配对蓝牙设备、允许程序打开网络套接字。手机端蓝牙Socket通信的程序设计流程如图6所示。

图6 蓝牙Socket程序设计流程

4 远程驾驶可行性测试

4.1 通信协议

通过Socket 通信及蓝牙Socket 的方式传送的控制信息（报文），需遵循车辆的控制接口协议以及GCAN-203使用的CAN2.0B协议帧格式，才能保证传输的报文被各节点正确接收。CAN2.0B 协议帧格式决定了一条CAN 帧包含13 个字节，其中包括1 个字节的帧信息，4个字节的帧ID以及8个字节的帧数据，帧信息指明了该帧的帧类型和数据长度。所使用的车辆的控制接口协议决定了本文中帧信息设为0X08，表示该帧为数据帧和标准帧，数据长度为8个字节；帧ID为0X238表明该帧用于主动加速、减速以及转向请求；波特率为500 Kb/s，同时使用Motorola 的编码格式。车辆的控制接口协议如表2所示。

表2 车辆控制接口协议

4.2 通信测试

为了保证传输到汽车CAN 总线上数据的准确性，排除因数据帧错误导致相应节点无法接收而造成的车辆远程控制失败，需要在实车测试前进行通信测试。具体方法是通过12 V 的蓄电池为设备G-CAN203 供电，使其与USB-CAN 适配器通过DB9 连接器相连，USBCAN适配器再通过USB接口与电脑连接。

USB-CAN 适配器可以作为一个标准的CAN 节点，带有USB2.0 接口和2 路CAN 接口，其与电脑连接后可通过USB-CAN Tool 对接收到的数据进行解析，判断从电脑端发送的数据是否正确，测试软件如图7所示。

图7 通信测试软件

由图7所示软件，可获取从电脑端控制界面发送的数据，包括ID 号、帧类型、帧格式、长度，由此判断通信链路可行性。

4.3 实车测试

理论上，当设备GCAN-203 与汽车的CAN 总线连接后，电脑端的控制界面就可以向汽车发送控制信息，本文将设备GCAN-203置于汽车后备箱，使用DB9连接器将其与汽车CAN总线的外接DB9连接器CAN1相连，从电脑端发送控制信息进行验证，如图8所示。

图8 车辆设备

电脑端控制界面点击“上”键后，电脑端通过通信链路向汽车发送0x080000023844000000**000000 数据帧，其中**代表1 个字节的目标驱动加速度；点击“下”按键后，向汽车发送数据帧0x08000002384800000000##0000，其中##代表1 个字节的目标制动减速度；点击“左”“右”按键后，向汽车发送数据帧0x0800000238420000000000XXXX，其中XXXX代表2个字节的目标转向盘转角，向左转向数值范围为0～32 767，向右转向数值范围为32 768～65 535。通过电脑端控制车辆的加速、制动、转向动作，可实现对车辆的远程控制。

5 窄路仿真验证

5.1 理论方法

文献[8]提出了合作速度协调（Cooperative Speed Harmonization，CSH）的方法，证明了2 条不同道路的车辆交替通过交叉口的可行性。为了做到这一点，CSH将同一道路车辆分组，使其像波浪一样向交叉口移动，对于2 条交汇的道路，CSH 分别运用不同的波长，以集中控制的方法使车辆接近最近的虚拟波，不同道路上的波浪会在不同的时间轮流到达交叉口。但是这种方法只适用于到达交叉口后车辆同向行驶的情况，对于窄路对向行驶的车辆不完全适用。因此，本文只借鉴其方法，使车辆到达到窄路段前形成集群，车辆集群过程如图9所示。

图9 车辆集群过程示意

由图9 可以看出，道路左侧的车辆由虚线波引导，道路右侧的车辆由实线波引导，车辆会通过对自身速度的调整使其向最接近的虚拟波靠拢，同一运行方向的车辆在道路上形成分组集群。如图10 所示，以道路右侧被实线波引导的车辆B为例，车辆运行速度由以下过程获得：

图10 车速取得过程示意

首先取得窄路段中心位置与车辆前波间的距离dw：

式中，lw为波长；dt为目前车辆与窄路中心的距离；vw为虚拟波向窄路端行进的速度；t为系统时间。

为了使窄路两侧的车辆到达窄路的时间不同，窄路左侧的车辆增加1/2波长。然后计算车辆与其前波的距离et：

最后，车辆的速度可以估算为：

式中，P、I、D、T为控制器参数；vmin为车辆运行的最小速度；Δet为et的差值；最大运算符可使差值et过低时有合适的控制器输出速度。

进入窄路段前，车辆会根据上述速度控制方式形成集群，当车辆将要进入窄路段，中止该速度控制方式，改由以下方式对车辆进行速度的控制：

车辆进入窄路段时会提前得到对向集群的信息以及道路信息，如集群内车辆运行速度、集群的规模、集群内车辆的间隙、窄路段的长度。车辆依据当前获取的信息，合理规划进入窄路的行车速度，其过程见图10。

图11所示为窄路通行过程。窄路左侧集群中的主车为V1，长度为LV1，其后的跟随车辆为V2，V1 与V2 的距离为Lg1，窄路端的长度为LW，目标车辆与窄路段的距离为Lr。由此可以得出：

图11 窄路通行过程示意

式中，LC为集群的长度；n为窄路一侧车辆的数量。

由此可得：

式中，v为集群运行的速度；LC+LW为集群通过窄路行驶的总长度。

进而得到目标车辆的建议速度vs：

窄路右侧的目标车以建议速度vs运行时，理论上可以在主车通过窄路后，不停车通过窄路段。

5.2 仿真场景建置

本文打通了车辆远程控制的通信链路，在可期的未来将系统完善后置于云端，可以远程控制区域内车辆的联合运动。本文针对窄路场景，云端收集该区域内的道路环境信息后对车辆远程控制，理论上可以使行车更加高效。窄路场景如图12所示。

图12 窄路场景

为了验证车辆在窄路处的通行效率，使用SUMO搭建窄路场景进行仿真。利用NETEDIT对仿真所需路网文件（net.xml）、车流文件（rou.xml）以及附加文件进行设计。其中路网文件中构筑长度为60 m 的狭窄路段，车流文件设计车辆的数量、行驶路径以及车辆本身的属性，附加文件中设置瞬时感应线圈以记录车辆进入和离开窄路的时间。本文共设计了3组对照仿真工况，分别使50辆、75辆、100辆汽车从窄路段通过，每组进行2次仿真，其中一次使车辆在远程驾驶下通过窄路，另一次使车辆依据自身的驾驶模型自由通过窄路段用来模拟人工驾驶。

6 结果与分析

通过SUMO-GUI 运行搭建的仿真场景获得车辆运行整体情况以及各探测器的取得的结果，对取得的数据进行处理，得到了3组通过窄路段汽车的数量与时间的关系以及车辆整个运行过程的平均速度与时间的关系，分别如图13和图14所示。

图13 汽车通过窄路段数量与时间的关系

图14 汽车平均行驶速度与时间的关系

由图13 可知，在人工驾驶的方式下，3 种不同数量的汽车全部通过窄路段所需时间均大于远程控制方式所需时间，同时可以看出，远程控制的方式汽车通行过程较为规律，因此在远程控制下汽车的通行效率更高。在远程控制下，出现75 辆汽车通过窄路所需时间大于100 辆汽车通过窄路所需时间的情况。这与仿真软件SUMO中车辆出现的时间点相关，由于车辆出现的时间点随机，若某一时段内车辆出现较少，按照该机制对车辆速度进行控制，形成的集群内车辆的数量将相对较少，因此车辆全部出现时将形成更多的集群，使得交替通过窄路的次数增多，通过窄路所需的时间增加，这与现实中路口处车流密度实时变化情况相符。

由图14可知，在人工驾驶的方式下，汽车在整个运行过程中速度的波动较大，出现过停车的状况，其运行过程大致分为3 个阶段，以图14c 为例：在第0～210 s 时由于没有集群同行的机制，存在一侧车辆在窄路前等待的状况；第210～302 s 时等待一侧的车辆找准时间间隙开始通过窄路；第302～373 s窄路处车辆开始通行顺畅，车辆整体平均速度提升。而在远程控制下，车辆运行速度平稳，速度维持在约20 m/s。由于每次经过窄路段的车辆数量随机，75 辆汽车一组在远程控制下由于通过窄路次数较多，导致其时间略长于100辆汽车在远程控制下通过窄路段所需时间。

综合图13 和图14 可以得出，在远程控制的方式下车辆通过窄路段效率更高，因为所有车辆被集中控制，这允许车辆间有更小的距离，同时收集到的窄路范围内的道路环境信息使得车辆能够以合适的速度通过路口而无需停车，避免了车辆在路口起停的时间损耗。

7 结束语

本文设计了一种基于Android 的车辆远程控制系统，使用支持TCP协议的Socket 以及支持OBEX 协议的蓝牙Socket 的通信方式实现了字节流的传输，利用GCAN-203将字节流信息传输到汽车CAN总线，实现了对车辆的远程操纵，通过SUMO 构筑窄路场景，验证了远程驾驶系统集成在云端可以大幅提高车辆通行效率。本文未完成云端系统的构建，未来将通过路侧设备、车载传感以及通讯设备完成对道路环境信息的获取，在云端进行信息处理后，通过本文设计的车辆远程控制系统完成决策的执行，实现从云端整体控制窄路处车辆的通行。