在本次技術(shù)沙龍中，來自Apollo團(tuán)隊(duì)計(jì)算平臺(tái)的資深研發(fā)工程師-羅琦老師帶了關(guān)于Apollo3.0 PnC更新以及車輛開放平臺(tái)的講解。

這里，我們將整理后的視頻資料及內(nèi)容分享給大家，沒能到達(dá)現(xiàn)場(chǎng)的開發(fā)者可以通過視頻和PPT資料來詳細(xì)了解課程內(nèi)容。

演講概要：

安全是自動(dòng)駕駛前行的保障，尤其是對(duì)于 L4 級(jí)別的自動(dòng)駕駛系統(tǒng)，功能安全更是一個(gè)全新的領(lǐng)域與挑戰(zhàn)。本演講將分享 Apollo 在功能安全方面的探索。

Apollo3.0 PnC更新以及車輛開放平臺(tái)介紹

1Apollo Roadmap

這里分享一下Apollo在3.0里面的相關(guān)更新，以及車輛開放平臺(tái)的一些介紹。

首先為大家介紹下Apollo的Roadmap。今年7月份，Apollo發(fā)布了3.0版本，并升級(jí)發(fā)布了ASU、Hardware Flexibility、Labelled Obstacles。其中在感知模塊我們也部署了新的檢測(cè)方案；而新增加的Guardian-Safety Module是Apollo平臺(tái)關(guān)于功能安全新的嘗試；在Monitor也更新了對(duì)硬件的檢測(cè)、軟件的功能檢測(cè)，為了和Guardian系統(tǒng)一起形成一個(gè)完整的Functional Safety的嘗試；在3.0版本中，我們又接入了新的Sensors——毫米波雷達(dá)，以及升級(jí)版的Hardware Development Platform。

2Apollo Open Software Platform 更新Guardian &Monitor

首先是 Guardian和Monitor模塊。Monitor是狀態(tài)監(jiān)控模塊，Guardian是在3.0版本中新加入的一個(gè)功能模塊。這兩個(gè)模塊是開放平臺(tái)對(duì)于Functional Safety和Fault Handling的嘗試。

Monitor主要實(shí)時(shí)監(jiān)控硬件和軟件各個(gè)模塊的健康狀態(tài)，比如功能模塊——Perception、Prediction、Planning、Control、Roadmap、Localization，同時(shí)監(jiān)測(cè)一些信號(hào)是否延時(shí)，以及是否有收到一些重要的信號(hào)。基于此，如果發(fā)現(xiàn)一些非正常行為、系統(tǒng)模塊報(bào)錯(cuò)，就會(huì)通知Guardian模塊進(jìn)入安全模式，同時(shí)會(huì)在Dreamview上通過不同的聲音和畫面方式提醒駕駛員在10秒鐘內(nèi)需要接管。

之前的Control直接跟CAN Bus模塊進(jìn)行通訊。現(xiàn)在由于接入了 Guardian，在 Guardian下存在兩個(gè)工作模式。在正常的模式下，Guardian會(huì)直接轉(zhuǎn)發(fā)Control的Signal到CAN Bus，如果當(dāng)超聲波傳感器正常工作并且前方?jīng)]有檢測(cè)到障礙物的前提下，嘗試在10s內(nèi)緩緩?fù)＼嚒Ｈ绻暡▊鞲衅髟诒O(jiān)測(cè)的整個(gè)過程中信號(hào)沒有輸出、輸出不符合預(yù)期或者是Ultrasonic Sensors檢測(cè)到障礙物，我們會(huì)采取緊急措施來防止碰撞。

Relative Map

Relative Map最初是在 Apollo2.5 中發(fā)布的，其目的是在一些相對(duì)簡(jiǎn)單的路況上，降低對(duì)于高精地圖的依賴。在 Apollo 2.0 以及之前的開放版本中，高精地圖主要用于3D雷達(dá)的監(jiān)測(cè)、2D相機(jī)紅綠燈監(jiān)測(cè)以及定位模塊的多傳感器融合和DreamView的顯示。這些功能都對(duì)高精地圖有很強(qiáng)的依賴。在Apollo 2.5中，我們主要依賴攝像頭來作為進(jìn)行障礙物和車道線的監(jiān)測(cè)，同時(shí)定位模塊主要依賴相對(duì)車道線或者GPS定位， 使得我們有機(jī)會(huì)嘗試解耦對(duì)于高精地圖的高度依賴。

Relative Map是根據(jù)周圍的環(huán)境實(shí)時(shí)建立的，同時(shí)以10hz的頻率向外發(fā)布，以供預(yù)測(cè)、規(guī)劃以及Dreamview使用。有三個(gè)不同的工作方式。

一是直接由實(shí)時(shí)的感知模塊監(jiān)測(cè)到的道路邊界，以10hz的頻率生成。好處是完全脫離對(duì)高精地圖和高精定位的依賴，部署成本較低，壞處是這種工況對(duì)于車道線本身的Lane Marker標(biāo)注是否清晰依賴度較高，同時(shí)在這種工況下只能進(jìn)行簡(jiǎn)單的ACC和Lane keeping。

第二種是指引線加上相對(duì)地圖，這樣的方式對(duì)于定位有較強(qiáng)依賴，而對(duì)車道線本身標(biāo)注的清晰程度依賴較低，同時(shí)，不基于高清地圖，仍然保持較為靈活的部署方式。

最后一種方案是基于指引線+高精地圖模式，這是最精確的解決方案，這樣的優(yōu)點(diǎn)是可以得到最全面和精確的地圖定位信息，缺點(diǎn)是部署成本較高。

上面是歸納高精地圖在三種模式下的車道應(yīng)用說明。

Lattice Planner

Lattice Planner一開始在Apollo 2.5時(shí)入庫，但那時(shí)候并沒有完全Functional ready，簡(jiǎn)單來說，Lattice Planner是一種Sample Based Planning的算法，具體的算法為：

1. 橫向和縱向分別撒點(diǎn)， 根據(jù)實(shí)時(shí)的決策目標(biāo)，比如跟車或者停止，在車輛的狀態(tài)空間內(nèi)取不同的終點(diǎn)。用高階曲線鏈接起點(diǎn)和不同狀態(tài)的終點(diǎn)。

2. 同時(shí)根據(jù)體感，是否達(dá)到終點(diǎn)狀態(tài)等，對(duì)于橫向和縱向的曲線Assign不同的Cost。

3. 之后，將橫縱向的曲線bundle起來形成最終的曲線，根據(jù)曲線Bundle后的Cost，從小到大排序，再檢查Bundle后的曲線是否符合Gometry Constraint，Comfort Constraint和通過Collision Check。

4. 最終輸出滿足條件的最優(yōu)的解。

這種方法對(duì)比現(xiàn)在的EM Planner來說，優(yōu)點(diǎn)是在調(diào)試性和可理解性上都要容易很多。缺點(diǎn)的話，是跟現(xiàn)有的EM Planner相比，因?yàn)檐壽E之間是用高階曲線進(jìn)行連接，Lattice Planner在特別復(fù)雜的條件下表達(dá)能力有所欠缺。因此Lattice Planner適合相對(duì)比較容易的高速場(chǎng)景以及末端物流場(chǎng)景和園區(qū)場(chǎng)景中運(yùn)行。

這是兩種不同的Applications，一種是Relative Map + Lattice Planner在高速場(chǎng)景中的應(yīng)用，另外一種主要解決方案是HD Map+Lattice Planner在低速物流場(chǎng)景的應(yīng)用。在Apollo 2.5中Relative Map剛開始發(fā)布時(shí)主要支持單車道的簡(jiǎn)單ACC與Lane Keeping，在隨后的Apollo 3.0以及以后再次升級(jí)了相對(duì)地圖，以及在此基礎(chǔ)上的決策規(guī)劃與控制的能力，同時(shí)提供在Relative Map下的多車道的復(fù)雜動(dòng)作，比如超車與換道。

Fleet Mangement

Fleet Management在第三方平臺(tái)和云服務(wù)平臺(tái)的之間定義了車輛接口、合作方接口、園區(qū)接口、以及起始終點(diǎn)接口。同時(shí)，在百度云端服務(wù)和車端自動(dòng)駕駛系統(tǒng)之間，定義了起始點(diǎn)，以及車輛調(diào)度指令下發(fā)接口和狀態(tài)收集接口，與量產(chǎn)接口一致，保證了和partner是一套調(diào)度接口，方便開發(fā)者在此基礎(chǔ)上進(jìn)行開發(fā)。

3Open Vehicle Certificate Platform

Open Vehicle Certificate Platform在1.0版本的時(shí)候只有一種車型，對(duì)于開發(fā)者來說選擇相對(duì)較少。因此在Apollo 3.0當(dāng)中開放了Open Vehicle Certificate Platform，同時(shí)發(fā)布了Open Vehicle Certificate Standard，比如把整個(gè)的標(biāo)準(zhǔn)跟流程進(jìn)行發(fā)布，更方便不同的開發(fā)者快速的把他們相關(guān)的能力加入我們的平臺(tái)中。

Apollo開放認(rèn)證平臺(tái)，對(duì)于自動(dòng)駕駛開發(fā)者來說更方便、更安全以及更低成本，只需要一套代碼就可以支持多種車型，直接進(jìn)行切換。對(duì)于車企和車營(yíng)商來說，好處在于車輛可以和Apollo平臺(tái)無縫對(duì)接，同時(shí)可以接入自動(dòng)駕駛的開發(fā)者，這里我們也希望能夠和更多車型、車輛的供應(yīng)商一起攜手建立一套行業(yè)標(biāo)準(zhǔn)。

Apollo開放車輛的接口標(biāo)準(zhǔn)主要分為兩大部分。首先對(duì)于線控系統(tǒng)來說，線控系統(tǒng)會(huì)對(duì)于功能指標(biāo)、性能指標(biāo)、安全指標(biāo)進(jìn)行一系列的約定與標(biāo)準(zhǔn)的提出。其次是對(duì)于車輛本身的車輛系統(tǒng)，為了支持自動(dòng)駕駛，我們也對(duì)它的功能、性能、安全以及能耗指標(biāo)制定了一系列約定。

具體來說最常見的剎車和油門，對(duì)于它們來說，控制精度、控制力度及這些系統(tǒng)的周期時(shí)間、響應(yīng)時(shí)間都有著嚴(yán)格的規(guī)定。對(duì)于線控系統(tǒng)的安全指標(biāo)來講，其中包括指令越界保護(hù)和控制的處理，都有著明確約定以及標(biāo)準(zhǔn)化的要求。

對(duì)于車輛系統(tǒng)本身，首先希望有相對(duì)穩(wěn)定的CAN通信接口，同時(shí)對(duì)于這輛車的電源，具體包括電壓、功率、最大波動(dòng)、輸出誤差都有一系列的規(guī)定，能夠保證在整個(gè)自動(dòng)駕駛過程中電源輸出穩(wěn)定。

在車輛系統(tǒng)中，我們希望partners能夠給我們一些動(dòng)力學(xué)模型，具體來說包括加速動(dòng)力曲線、剎車動(dòng)力曲線、以及轉(zhuǎn)向動(dòng)力曲線。同時(shí)，接入的車輛要滿足一系列的安全指標(biāo)，比如車輛碰撞及一些推薦能耗指標(biāo)，比如車輛排放標(biāo)準(zhǔn)、油耗標(biāo)準(zhǔn)和續(xù)航里程標(biāo)準(zhǔn)。

在Apollo 3.0中，我們開放了相關(guān)開放車輛的一些工具和文檔，這些工具文檔包括但并不限于我們的DBC file轉(zhuǎn)化工具，校驗(yàn)工具，以及車輛安全測(cè)試工具。同時(shí)我們也開放了相關(guān)的文檔，比如接口需求文檔、操作文檔，及認(rèn)證車輛類表。接下來介紹一下整個(gè)的車輛操作指南，同時(shí)在這個(gè)過程中帶領(lǐng)大家熟悉一下在Apollo的代碼中，我們的接口需求、文檔以及各個(gè)工具具體的位置以及使用方式。

在一個(gè)完整的Open Vehicle Certificate Program的流程里，第一步是Apollo Publish Interface and requirements，這里面包括Interface Documents，也包括我們的Compatible Vehicles，Certification Services以及Apollo Open Source Code，這些都是開始之前預(yù)先要做的準(zhǔn)備。

第二步是Partners Initiate Process，能夠根據(jù)接口要求進(jìn)行自檢，并進(jìn)行一系列的測(cè)試，同時(shí)我們會(huì)相應(yīng)的提供一些文檔和工具的支持。

第三步是一些Process Requirements，以及更多的Tehnical Check和Business Development Process。

第四步是Apollo and Partner Real Vehicle Test。Apollo平臺(tái)也盡可能提供不同的接口幫助大家完成開發(fā)以及對(duì)接。首先對(duì)于一輛新的vehicle，希望大家在Apollo Github上找到documents，根據(jù)流程和文檔，和我們開源的demo code和標(biāo)準(zhǔn)，開發(fā)者們可以從一個(gè)新的車廠DBC file，生成一整系列的code，通過改變很小的一部分code就可以無縫接入我們的Open Vehicle Certificate Program的流程。

期待我們的partner在Open Loop的時(shí)候使用一些Verification工具，保證向下的命令可以符合預(yù)期。最后開發(fā)者應(yīng)該可以以Apollo 1.0循跡的方式，用新加入的車輛進(jìn)行Waypoint Following的測(cè)試，通過我們?cè)贏pollo平臺(tái)上提供的相關(guān)測(cè)試標(biāo)準(zhǔn)。

接下來是最后的步驟，首先是Legal Check，將車輛通信協(xié)議代碼添加到Github上，同時(shí)將車輛添加到Apollo車輛平臺(tái)兼容列表里，就可以完成整個(gè)認(rèn)證流程。