Apollo3.0 PnC更新以及車輛開放平台介紹
在本次技術沙龍中，來自Apollo團隊計算平台的資深研發工程師-羅琦老師帶了關於Apollo3.0 PnC更新以及車輛開放平台的講解。
這裡，我們將整理後的視頻資料及內容分享給大家，沒能到達現場的開發者可以通過視頻和PPT資料來詳細了解課程內容。
演講概要：
安全是自動駕駛前行的保障，尤其是對於 L4 級別的自動駕駛系統，功能安全更是一個全新的領域與挑戰。本演講將分享 Apollo 在功能安全方面的探索。
Apollo3.0 PnC更新以及車輛開放平台介紹
百度自動駕駛計算平台資深研發工程師 羅琦
（建議在Wi-Fi環境下觀看）
1
Apollo Roadmap
這裡分享一下Apollo在3.0裡面的相關更新，以及車輛開放平台的一些介紹。
首先為大家介紹下Apollo的Roadmap。今年7月份，Apollo發布了3.0版本，並升級發布了ASU、Hardware Flexibility、Labelled Obstacles。其中在感知模塊我們也部署了新的檢測方案；而新增加的Guardian-Safety Module是Apollo平台關於功能安全新的嘗試；在Monitor也更新了對硬體的檢測、軟體的功能檢測，為了和Guardian系統一起形成一個完整的Functional Safety的嘗試；在3.0版本中，我們又接入了新的Sensors——毫米波雷達，以及升級版的Hardware Development Platform。
2
Apollo Open Software Platform 更新
Guardian & Monitor
首先是 Guardian和Monitor模塊。Monitor是狀態監控模塊，Guardian是在3.0版本中新加入的一個功能模塊。這兩個模塊是開放平台對於Functional Safety和Fault Handling的嘗試。
Monitor主要實時監控硬體和軟體各個模塊的健康狀態，比如功能模塊——Perception、Prediction、Planning、Control、Roadmap、Localization，同時監測一些信號是否延時，以及是否有收到一些重要的信號。基於此，如果發現一些非正常行為、系統模塊報錯，就會通知Guardian模塊進入安全模式，同時會在Dreamview上通過不同的聲音和畫面方式提醒駕駛員在10秒鐘內需要接管。
之前的Control直接跟CAN Bus模塊進行通訊。現在由於接入了 Guardian，在 Guardian下存在兩個工作模式。在正常的模式下，Guardian會直接轉發Control的Signal到CAN Bus，如果當超聲波感測器正常工作並且前方沒有檢測到障礙物的前提下，嘗試在10s內緩緩停車。如果超聲波感測器在監測的整個過程中信號沒有輸出、輸出不符合預期或者是Ultrasonic Sensors檢測到障礙物，我們會採取緊急措施來防止碰撞。
Relative Map
Relative Map最初是在 Apollo2.5 中發布的，其目的是在一些相對簡單的路況上，降低對於高精地圖的依賴。在 Apollo 2.0 以及之前的開放版本中，高精地圖主要用於3D雷達的監測、2D相機紅綠燈監測以及定位模塊的多感測器融合和DreamView的顯示。這些功能都對高精地圖有很強的依賴。在Apollo 2.5中，我們主要依賴攝像頭來作為進行障礙物和車道線的監測，同時定位模塊主要依賴相對車道線或者GPS定位， 使得我們有機會嘗試解耦對於高精地圖的高度依賴。
Relative Map是根據周圍的環境實時建立的，同時以10hz的頻率向外發布，以供預測、規劃以及Dreamview使用。有三個不同的工作方式。
一是直接由實時的感知模塊監測到的道路邊界，以10hz的頻率生成。好處是完全脫離對高精地圖和高精定位的依賴，部署成本較低，壞處是這種工況對於車道線本身的Lane Marker標註是否清晰依賴度較高，同時在這種工況下只能進行簡單的ACC和Lane keeping。
第二種是指引線加上相對地圖，這樣的方式對於定位有較強依賴，而對車道線本身標註的清晰程度依賴較低，同時，不基於高清地圖，仍然保持較為靈活的部署方式。
最後一種方案是基於指引線+高精地圖模式，這是最精確的解決方案，這樣的優點是可以得到最全面和精確的地圖定位信息，缺點是部署成本較高。
上面是歸納高精地圖在三種模式下的車道應用說明。
Lattice Planner
Lattice Planner一開始在Apollo 2.5時入庫，但那時候並沒有完全Functional ready，簡單來說，Lattice Planner是一種Sample Based Planning的演算法，具體的演算法為：
1. 橫向和縱向分別撒點， 根據實時的決策目標，比如跟車或者停止，在車輛的狀態空間內取不同的終點。用高階曲線鏈接起點和不同狀態的終點。
2. 同時根據體感，是否達到終點狀態等，對於橫向和縱向的曲線Assign不同的Cost。
3. 之後，將橫縱向的曲線bundle起來形成最終的曲線，根據曲線Bundle後的Cost，從小到大排序，再檢查Bundle後的曲線是否符合Gometry Constraint，Comfort Constraint和通過Collision Check。
4. 最終輸出滿足條件的最優的解。
這種方法對比現在的EM Planner來說，優點是在調試性和可理解性上都要容易很多。缺點的話，是跟現有的EM Planner相比，因為軌跡之間是用高階曲線進行連接，Lattice Planner在特別複雜的條件下表達能力有所欠缺。因此Lattice Planner適合相對比較容易的高速場景以及末端物流場景和園區場景中運行。
這是兩種不同的Applications，一種是Relative Map + Lattice Planner在高速場景中的應用，另外一種主要解決方案是HD Map+Lattice Planner在低速物流場景的應用。在Apollo 2.5中Relative Map剛開始發布時主要支持單車道的簡單ACC與Lane Keeping，在隨後的Apollo 3.0以及以後再次升級了相對地圖，以及在此基礎上的決策規劃與控制的能力，同時提供在Relative Map下的多車道的複雜動作，比如超車與換道。
Fleet Mangement
Fleet Management在第三方平台和雲服務平台的之間定義了車輛介面、合作方介面、園區介面、以及起始終點介面。同時，在百度雲端服務和車端自動駕駛系統之間，定義了起始點，以及車輛調度指令下發介面和狀態收集介面，與量產介面一致，保證了和partner是一套調度介面，方便開發者在此基礎上進行開發。
3
Open Vehicle Certificate Platform
Open Vehicle Certificate Platform在1.0版本的時候只有一種車型，對於開發者來說選擇相對較少。因此在Apollo 3.0當中開放了Open Vehicle Certificate Platform，同時發布了Open Vehicle Certificate Standard，比如把整個的標準跟流程進行發布，更方便不同的開發者快速的把他們相關的能力加入我們的平台中。
Apollo開放認證平台，對於自動駕駛開發者來說更方便、更安全以及更低成本，只需要一套代碼就可以支持多種車型，直接進行切換。對於車企和車營商來說，好處在於車輛可以和Apollo平台無縫對接，同時可以接入自動駕駛的開發者，這裡我們也希望能夠和更多車型、車輛的供應商一起攜手建立一套行業標準。
Apollo開放車輛的介面標準主要分為兩大部分。首先對於線控系統來說，線控系統會對於功能指標、性能指標、安全指標進行一系列的約定與標準的提出。其次是對於車輛本身的車輛系統，為了支持自動駕駛，我們也對它的功能、性能、安全以及能耗指標制定了一系列約定。
具體來說最常見的剎車和油門，對於它們來說，控制精度、控制力度及這些系統的周期時間、響應時間都有著嚴格的規定。對於線控系統的安全指標來講，其中包括指令越界保護和控制的處理，都有著明確約定以及標準化的要求。
對於車輛系統本身，首先希望有相對穩定的CAN通信介面，同時對於這輛車的電源，具體包括電壓、功率、最大波動、輸出誤差都有一系列的規定，能夠保證在整個自動駕駛過程中電源輸出穩定。
在車輛系統中，我們希望partners能夠給我們一些動力學模型，具體來說包括加速動力曲線、剎車動力曲線、以及轉向動力曲線。同時，接入的車輛要滿足一系列的安全指標，比如車輛碰撞及一些推薦能耗指標，比如車輛排放標準、油耗標準和續航里程標準。
在Apollo 3.0中，我們開放了相關開放車輛的一些工具和文檔，這些工具文檔包括但並不限於我們的DBC file轉化工具，校驗工具，以及車輛安全測試工具。同時我們也開放了相關的文檔，比如介面需求文檔、操作文檔，及認證車輛類表。接下來介紹一下整個的車輛操作指南，同時在這個過程中帶領大家熟悉一下在Apollo的代碼中，我們的介面需求、文檔以及各個工具具體的位置以及使用方式。
在一個完整的Open Vehicle Certificate Program的流程里，第一步是Apollo Publish Interface and requirements，這裡面包括Interface Documents，也包括我們的Compatible Vehicles，Certification Services以及Apollo Open Source Code，這些都是開始之前預先要做的準備。
第二步是Partners Initiate Process，能夠根據介面要求進行自檢，並進行一系列的測試，同時我們會相應的提供一些文檔和工具的支持。
第三步是一些Process Requirements，以及更多的Tehnical Check和Business Development Process。
第四步是Apollo and Partner Real Vehicle Test。Apollo平台也儘可能提供不同的介面幫助大家完成開發以及對接。首先對於一輛新的vehicle，希望大家在Apollo Github上找到documents，根據流程和文檔，和我們開源的demo code和標準，開發者們可以從一個新的車廠DBC file，生成一整系列的code，通過改變很小的一部分code就可以無縫接入我們的Open Vehicle Certificate Program的流程。
期待我們的partner在Open Loop的時候使用一些Verification工具，保證向下的命令可以符合預期。最後開發者應該可以以Apollo 1.0循跡的方式，用新加入的車輛進行Waypoint Following的測試，通過我們在Apollo平台上提供的相關測試標準。
接下來是最後的步驟，首先是Legal Check，將車輛通信協議代碼添加到Github上，同時將車輛添加到Apollo車輛平台兼容列表裡，就可以完成整個認證流程。
▼
往期線下沙龍
▼
Apollo
TAG:Apollo開發者社區 |