Apollo 低成本方案在TX2 平臺針對相對地圖的優化

張東愛

（北京大學，北京100871）

0 引言

得益于計算機計算性能的大幅提高和人工智能的高速發展，自動駕駛技術在最近的幾年內得到快速的發展[1]。無論是傳統車企或者大型互聯網公司都開始布局自動駕駛的研發。Apollo 是百度公司于2017 年4月推出的開源的自動駕駛軟件平臺，旨在向汽車行業及自動駕駛領域的合作伙伴提供一個開放、完整、安全的軟件平臺，幫助合作伙伴結合車輛和硬件系統，快速搭建一套完整的自動駕駛系統。截止到2019 年1 月已發布5 個版本。其中，2018 年4 月發布的Apollo2.5版本中首次引入了相對地圖的實現方案，因其使用的地圖模式易采集和制作，非常適合于封閉園區和高速場景的低成本自動駕駛方案。相對地圖的路線長度依賴于車輛運行場景的道路長度，道路過長勢必會導致路線數據的加載和刷新的效率低下，進而影響計算平臺的計算效率，可能導致計算平臺無法及時處理傳感器數據，造成延遲增大，進而影響自動駕駛車輛的安全性和乘坐體驗。因此，本文設計了一種Apollo 相對地圖的局部加載方案，該方案不依賴于路線長度，能夠保證計算平臺在任何時間點只計算部分的，等長的路線，從而節省計算資源且保證計算平臺的平穩運行。

1 相對地圖方案分析

1.1 現狀分析

自動駕駛領域遵循的首要目標是安全[2]。為了讓自動駕駛車輛比人類駕駛車輛更加安全，車輛需要能夠精確地定位，實時地刷新地圖數據，快速感知到周圍障礙物和障礙物變化，精確預測障礙物的移動軌跡等。為了達到這個目的，要求車輛的計算平臺能夠低延遲的完成數據輸入、算法運算和數據輸出等工作。

Apollo 低成本的自動駕駛方案的軟件架構可以分為定位、感知、預測、規劃、控制、Canbus、相對地圖、人機交互界面等主要模塊。各模塊間數據通訊流程如圖1 所示。

在相對地圖的加載方案中，將從車輛當前位置到路線終點的數據全部作為前方的路線進行計算，并發布到下游的計算模塊。這導致所有依賴地圖數據的模塊的數據計算量隨著路線長度增加而增加。

另外，低成本的自動駕駛方案的計算平臺通常選用安全、小巧且價格相對低廉的嵌入式計算機。但是計算性能卻遠比不上其他昂貴的工控機[3]。

軟件架構復雜，數據量大，計算資源緊缺是目前低成本自動駕駛方案的現狀。這可能導致計算平臺無法及時處理數據，導致車輛的反應延遲增大，進而增加自動駕駛的危險系數和影響乘坐體驗。

圖1 模塊間數據通訊流程

1.2 相對地圖的制作

在使用Apollo 的相對地圖方案實施自動駕駛的測試前，首先需要確定車輛運行的場景和路線。相對地圖中的地圖數據是車輛在人工駕駛的狀態下錄制的一條數據序列，該數據序列經過平滑處理后作為地圖輸入數據傳輸給規劃模塊，規劃模塊根據地圖數據和當前車輛位置規劃出一條車輛可以運行的路線，進而控制車輛的自動駕駛。

在確定運行路線后，首先開啟Apollo 的定位模塊和Canbus 模塊，其中定位模塊用來收集車輛的位置數據，Canbus 模塊用來收集車輛的底盤狀態數據。然后由人工駕駛車輛在一個車道內從起點行駛至終點，為了減少路線的不可控狀態，行駛過程中應盡量避免換道。每個車道錄制一遍即可。錄制的數據會實時保存到地圖數據包中，該數據包中記錄了車輛行駛過程中定位的位置數據和速度。

地圖數據包錄制完畢后，使用Apollo 提供的工具生成相對地圖的指引線數據。指引線中包含了之前車輛在人工駕駛狀態下的位置數據，以每行作為單位記錄位置數據，并經過了平滑處理，確保點與點之間的平滑過渡。人工駕駛過程中錄入的噪聲數據，例如車輛的抖動和不規則換道等，在平滑處理階段會被剔除掉，以確保自動駕駛階段的平穩性。生成的地圖數據是相對于車的車身坐標系。在車身坐標系下，車輛坐標永遠在原點，車頭方向永遠為0。所以，在地圖上表現出來的指引線和人工駕駛階段的路線是十分吻合的。

1.3 相對地圖的加載和發布

在生成了相對地圖方案的指引線數據后，可以進行車輛的自動駕駛測試。在Apollo 的相對地圖實現方案中，將指引線數據加載進內存，以10Hz 的頻率將車輛當前位置到路線終點的地圖數據發送到規劃模塊，規劃模塊以地圖數據為路線基礎，結合感知模塊感知到的障礙物信息、車道線信息和紅綠燈信息，結合預測模塊對移動的障礙物的移動軌跡預判結果規劃出一條可供車輛運行的路線。規劃出的路線數據將發送給控制模塊，控制模塊根據路線數據和車輛的位置、狀態計算出車輛運行的方向（方向盤轉角）、速度（油門量和剎車量），將控制指令通過Canbus 模塊發送給車輛底盤，進而驅動車輛自動的行駛。

地圖數據的加載，路線的規劃，車輛的控制形成了一個車輛自動駕駛的數據閉環，確保車輛能夠按照相對地圖的既定路線安全平穩的行駛到終點。

2 相對地圖方案運行效率測試

2.1 測試環境

計算平臺采用在人工智能領域應用廣泛，并且在Apollo 的低成本方案中推薦的一款單模塊計算機：NVIDIA Jetson TX2。其主要性能參數如圖2 所示。

圖2 NVIDIA Jetson TX2主要性能參數

測試環境選擇在封閉園區內200 米的路況進行測試。

2.2 主要性能數據表現

以10Hz 的頻率，對200 米的內部道路進行測試后，相對地圖方案的主要性能表現詳見表1。

表1

3 優化方案分析和實施

根據上述的測試數據可以看出，CPU 一直處于高負荷運載的狀態[4-5]，導致無法及時地處理傳感器數據和檢測車輛的異常狀態，存在較大的安全隱患。同時，測試過程中，乘坐體驗較差，明顯感到車輛無法很快地感知到環境變化并快速做出反應。

其中，相對地圖模塊、規劃模塊和刷新模塊占用了較多的計算資源，存在很大的優化空間[5]。通過對相對地圖模塊、規劃模塊和刷新模塊的實現分析得知，這三個模塊都強依賴于相對地圖的地圖數據，地圖數據越大則需要處理的數據越多，需要處理的時間則越長。所以，減少相對地圖的路線長度會減少需要處理的數據量，減輕相對地圖模塊、規劃模塊和刷新模塊的數據計算壓力。

在車輛自動駕駛的數據閉環中，有一個環節是將從車輛當前位置到路線終點的地圖數據發送到規劃模塊。實現方案是讀取指引線數據文件的所有行，相對精確地匹配當前車輛位置和指引線中的某一行，將從這一行開始到文件結尾的所有行作為地圖數據發送到規劃模塊。考慮對此環節進行局部加載的優化。即，將從車輛當前位置到車輛前方一段距離的地圖數據發送到規劃模塊。

實施局部加載的優化方案需要額外解決兩個問題。

首先是確定預加載路線的距離。指引線數據文件中記錄的是車輛在人工駕駛的位置數據，并且已經經過平滑處理，行與行數據之前的方差很小。該位置數據無法準確地量化到距離數據，但是基本上行數越多表示距離越遠。所以，局部加載的數據是從車輛當前位置到前方指引線某些行的地圖數據。

其次是使加載長度的配置更加便捷。考慮到不同測試環境會需要不同的局部加載方案，為了方便用戶的配置和管理，局部加載的行數配置在配置文件中。

將局部加載的方案應用到相對地圖方案中后，以200 米的路況為例，每次刷新前方1500 行的地圖數據，車輛自動駕駛狀態下的主要性能表現詳見表2。

表2

可以看出，實施局部加載方案后，模塊的CPU 占用率顯著的降低，CPU 總體的利用率也顯著降低。測試時乘坐體驗也得到很大的改善，車輛能夠做到對周圍環境的快速感知和反應。

4 結語

本文采用的測試路況環境為封閉的園區環境，是眾多開發者經常采用的測試環境；軟件架構選用了針對低成本園區方案設計的相對地圖方案；計算平臺選用支持Apollo 運行的低成本計算平臺NVIDIA Jetson TX2。在該測試條件下，未實施本文探討的優化方案前，計算平臺的計算資源幾乎被全部占用，無法繼續進行有效的開發和測試。在實施優化方案后，顯著節省了CPU 資源，可以對自動駕駛方案進行更多方面的改進和測試。讀者可以在實施優化方案后對自動駕駛的算法，軟件架構進行進一步的優化。