智能車輛窄路協調通行的遠端控制技術

滕政哲 林士飏 王界欽 張天淼 穆虎

（山東理工大學，淄博 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 構筑窄路場景，驗證了遠程駕駛系統集成在云端可以大幅提高車輛通行效率。本文未完成云端系統的構建，未來將通過路側設備、車載傳感以及通訊設備完成對道路環境信息的獲取，在云端進行信息處理后，通過本文設計的車輛遠程控制系統完成決策的執行，實現從云端整體控制窄路處車輛的通行。