百度自動駕駛專家從車輛認證平臺、硬件開發平臺、功能安全及量產解決方案四個方面著手，為大家全面解讀 Apollo 3.0 從研發到量產的技術原理。

7 月 4 日，第二屆百度 AI 開發者大會如期而至，在此次發布會中，全球首款 L4 級量產自動駕駛巴士“阿波龍”宣布量產下線。在這突破性的背后，揭示著 Apollo 平臺的快速提升。一年前，百度 Apollo 平臺發布，當時 Apollo1.0 有 35000 行代碼。經過一年的發展，Apollo 3.0 的代碼已經長了 6 倍之多，達到了 220000 多行代碼。

7 月 28 日，由百度開發者中心主辦，極客邦科技承辦的第 80 期百度技術沙龍邀請了來自百度 Apollo 技術布道師胡曠、百度 Apollo 控制／車輛交互技術負責人羅琦、百度自動駕駛技術部高級產品經理王石峰、百度自動駕駛技術部資深研發工程師楊凱、百度自動駕駛事業部資深架構師楊凡五位講師，從車輛認證平臺、硬件開發平臺、功能安全及量產解決方案四個方面著手，為大家全面解讀 Apollo 3.0 從研發到量產的技術原理。

1.Apollo3.0 自動駕駛開放平臺介紹

百度 Apollo 技術布道師胡曠做了開場演講。他首先介紹了百度 Apollo 的發展歷程。在今年 7 月 Apollo3.0 推出前，Apollo 已經在一年里迭代了 4 個版本，最新的版本不僅更新了激光雷達、攝像頭、毫米波雷達、組合導航系統以及超聲波雷達等硬件設施， 還在自動駕駛的感知、定位、規劃、決策以及控制等技術上進行了升級。

隨后，胡曠對百度 Apollo 3.0 的新特性進行了詳細介紹，包括 Apollo 3.0 的架構升級以及新推出的核心能力。如下圖所示，首先在云服務平臺以及軟件平臺方面，Apollo 3.0 針對量產低速園區場景全面升級七大能力：低速園區感知算法、低速園區規劃算法、低速園區控制方案、賦能量產安全監控、賦能量產 HMI 調試工具、賦能量產開發者接口、開發者貢獻相對地圖。在硬件開發方面，Apollo 3.0 從參考硬件升級為硬件開發平臺，新增了 15 種硬件選型，發布了 Apollo 傳感器單元，并添加底層軟件抽象層，旨在為用戶提供更多接口的同時還可以做時間戳同步及空間數據的融合。在車輛方面，Apollo 3.0 從車輛參考平臺升級為車輛認證平臺，鏈接車企與開發者需求，加速無人駕駛的部署和量產。

2.Apollo3.0 PnC 更新以及車輛認證平臺介紹

百度 Apollo 控制、車輛交互技術負責人羅琦在此次分享中介紹了 Apollo3.0 軟件平臺更新以及車輛認證平臺。

Apollo 軟件平臺更新

Monitor/Guardian

在演講中，羅琦首先對 Apollo 3.0 Monitor 狀態監控模塊的升級和 Guardian 新模塊的加入進行了介紹。他表示，Monitor 模塊和 Guardian 模塊是對于 Functional safety 和 Fault handling 的初步嘗試。其主要的工作方式為：Monitor 系統實時監測硬件及軟件各個模塊的健康狀態，以及是否收到一些最重要的信號。一旦發現障礙物，Monitor 就會通知 Guardian 模塊，同時在 Dreamview 上通過聲音和圖像的方式提示接管。緊接著， Guardian 模塊會根據 Monitor 發來的信息，進行一系列的動作。當超聲波傳感器正常工作并且前方沒有檢測到障礙物的前提下，嘗試在 10s 內緩緩停車；當超聲波傳感器不正常工作或者監測到有障礙物，會為了防止碰撞緊急剎車。

相對地圖

相對地圖最初是在 Apollo2.5 中發布。目的是在一些相對簡單的路況上，降低對于高精地圖的依賴。在 Apollo 2.0 以及之前的開放中，高精地圖主要用于 3D 雷達的監測，2D 相機紅綠燈監測， 以及定位模塊的多傳感器融合。 在 Apollo2.5 中，百度主要依賴相機進行障礙物和車道線的監測，同時定位模塊主要依賴相對車道線或者 GPS 定位。

相對地圖總共有三種工作模式：

第一種是直接由實時的感知模塊監測到的道路邊界，以 10hz 的頻率生成。好處是完全脫離對高精地圖和高精定位的依賴，且部署成本較低；壞處是這種工況對于車道線本身的車道線標注是否清晰依賴度較高，同時在這種工況下只能進行簡單的 ACC 和 lane keeping.

第二種是指引線加上相對地圖。這樣的方式對于定位有較強依賴，而對車道線本身標注的清晰程度依賴較低。同時，可以不基于高精地圖，仍然保持較為靈活的部署方式。

第三種是基于指引線 + 高精地圖模式，也就是說和原本 2.0 的方案兼容。這樣的好處就是得到最全面和精確的地圖定位信息，但部署成本較高。

Apollo 2.5 發布的是只支持單車道的方案，在 Apollo 3.0 以及 3.0 以后中，為了支持合作伙伴在這種相對地圖模式下的超車、換道等需求，百度加入了多車道的相對地圖支持。

Lattice planner

Lattice planner 是一種 sample based planning 的算法，具體的算法過程為：

橫向和縱向分別撒點， 根據實時的決策目標，比如跟車或者停止，在車輛的狀態空間內取不同的終點。用高階曲線鏈接起點和不同狀態的終點。

根據體感，是否達到終點狀態等，對于橫向和縱向的曲線 assign 不同的 cost。

將橫縱向的曲線 bundle 起來形成最終的曲線，之后根據曲線 bundle 后的 cost，從小到大排序，再檢查 bundler 后的曲線是否符合各種 gometry constraint 和通過 collision check。

最終輸出滿足條件的最優的解。

同樣， Lattice planner 也有其獨特的優勢及劣勢。與現在的 em planner 對比，Lattice planner 在調試性和可理解性上都要容易很多。但是與現有的 planner 相比，因為軌跡之間是用高階曲線進行連接，所以 Lattice planner 在特別復雜的條件下表達能力有所欠缺。更適合相對比較容易的高速場景以及末端物流場景。

Fleet Management

百度定義了第三方平臺和云服務平臺的車輛接口、合作方接口、園區接口、以及起始終點接口。同時在百度云端服務和車端自動駕駛系統中，定義了起始點、車輛調度整合、聚焦車輛接口以及狀態收集接口，這些接口和量產接口保持一致，保證了和合作方是一套調度接口，可以進行一些功能的實現。

Apollo 開放車輛標準

下圖為 Apollo 開放車輛接口標準，主要分為兩大部分：線控系統和車輛系統。對于線控系統，百度對接入的系統有著功能，性能，安全指標等一系列要求。對于車輛系統本身，百度也對其中的一些功能指標，性能指標，安全指標，能耗指標具有一系列的要求。

3.自動駕駛硬件系統及 Apollo 硬件開發平臺的簡介

第三個主題由百度自動駕駛技術部高級產品經理王石峰講述，王石峰從傳感器的產品定義出發介紹了整體自動駕駛的硬件系統，使開發者能根據自身的自動駕駛 ODD 選擇更加適用的硬件選型和方案。

自動駕駛的硬件系統

從整體看自動駕駛的硬件系統，可粗略分為感知、決策、控制三大模塊。

在車輛感知上，一方面要從車輛運動考慮到車的速度和轉角信息，另一方面還要考慮到環境感知，例如激光雷達、超聲波、攝像頭，毫米波雷達等傳感器的使用。另外，駕駛員監測主要是通過攝像頭和生物電傳感器，生物電傳感器集成在方向盤里面，可判斷駕駛員的手是否脫離方向盤。與此同時，生物電傳感器也可以檢測駕駛員的精神狀態。

在車輛決策上，主要就是計算單元，各類傳感器信息統一到計算單元處理。T-BOX 向上接互聯網，向下接 CAN 總線，可實現遠程對車輛的控制。黑匣子記錄車輛控制和行駛信息，可提供信息對事故進行判定。

在車輛控制上，主要有制動、轉向、發動機、變速箱，以及警告系統，聲音、圖像、振動。

接下來具體到自動駕駛硬件系統中的傳感器、計算單元及車輛線控。

傳感器

自動駕駛使用的感知類的傳感器，主要有激光雷達、毫米波雷達、攝像頭、組合導航。激光雷達安裝在車頂，360 度同軸旋轉，可以提供周圍一圈的點云信息。另外，激光雷達不光用于感知，也可用在定位和高精度地圖的測繪。毫米波雷達安裝在保險杠上，與激光雷達原理類似，通過觀察電磁波回波入射波的差異來計算速度和距離。組合導航分為兩部分，一部分是 GNSS 板卡，另一部分是 INS。當車輛行駛到林蔭路或是建筑物附近，GPS 會產生偏移或是信號屏蔽的情況，這時可通過與 INS 進行組合運算解決問題。

計算單元

說到自動駕駛汽車的計算單元，首先必須考慮到冗余設計。在計算單元中，所有的 CPU、GPU、FPGA 都是雙冗余備份，總線上包括 PCIE 和 Ethernet 也都是雙冗余。當所有系統失效的情況下，還可通過 MCU 發出控制指令到車輛控制單元剎車制動，保證安全性。這種中央集中式的計算有利于算法快速迭代，但也有缺點：整個單元體積比較大，功耗比較高。那有什么辦法可以降低功耗和體積？可以考慮分布式邊緣計算架構。以激光雷達算法的公司 Dibotics 為例，將 SLAM 算法寫到 Renesas 的 R-Car 芯片上，再將芯片植入到傳感器中。另外，自動駕駛的芯片車規是在封裝過程中完成，其主要指標是功耗、算力和面積。目前整個芯片制造正從 16 納米向 7 納米迭代，7 納米對比 16 納米整個運算率會提升 40%，功耗會降低 60%。

線控系統

自動駕駛的線控系統分為減速、轉向和加速三大部分。線控 1.0 版對車輛的踏板以及方向盤進行改裝；線控 2.0 版對車輛的 ADAS 系統進行借用，如 MKZ 的自動泊車以及 ACC；線控 3.0 版對車輛進行定制，所有系統均可線控和手動控制。

4.Apollo 3.0 硬件開發平臺

下圖為 Apollo 3.0 硬件開發平臺結構圖。Apollo3.0 將 Apollo 參考硬件全面升級為 Apollo 硬件開發平臺。成功適配并增加了 15 種以上的設備，添加底層硬件抽象層。可適配多種數據格式，定義通用的 API 接口，無縫銜接 Apollo 上層軟件，使得多種硬件設備在 Apollo 平臺上實現即插即用。極大的方便了開發者，合作伙伴和硬件廠商，節省了大家對 Apollo 平臺的開發適配時間。

5.Apollo 3.0 功能安全探索

安全是自動駕駛前行的保障，尤其是對于 L4 級別的自動駕駛系統，功能安全更是一個全新的領域與挑戰。基于此，百度自動駕駛計算平臺資深研發工程師楊凱現場分享了百度 Apollo 在功能安全方面的探索。

功能安全是什么

無人車主要分為兩大塊，一塊是網絡安全，另一塊就是功能安全。網絡安全主要是指駕駛軟件信息不被黑客竊取。而功能安全是指通過冗余、多樣性手段構建功能安全子系統，極大限度召回軟硬件故障，使得損害風險降低到可接受的水平。

功能安全如何做

在自動駕駛的功能安全上，百度采用了電子電器行業標準 ISO26262。但是目前看，市面上的功能安全還存在很多挑戰：目前業界并無標準可循，不存在為自動駕駛制定的功能安全標準。傳統的汽車電子電氣開發遵守國際標準 ISO 26262。另外，目前大部分研發自動駕駛的廠商還是聚焦在自動駕駛功能本身，只有少數在參考 ISO 26262 的思路，結合自動駕駛系統的特點，探索自動駕駛的功能安全機制。

面對挑戰，百度從兩個方面出發：從全局看，落實 ISO26262，搭建安全流程，系統地分析解決系統風險點；從局部看，建立無人駕駛安全子系統，召回軟硬件故障，建立安全防線。

功能安全子系統

下圖為功能安全的主系統思路。百度把自動駕駛主系統比作成一個人，感知是大腦，控制是手和腳。當駕駛員遇到突發狀況而面臨安全風險時，系統會根據情況做故障檢測和故障處理。故障處理分為 5 個等級：第一個等級警告，不是特別嚴重；第二個等級是減速，當系統延遲比較大的時候，會相應地做降速行使；第三個等級停車，比如傳感器失效，就需要緊急停車；第四個等級是靠邊停車，不過是否能夠靠邊停車是由它發生的故障決定，比如感知系統失效就不能進行靠邊停車；第五個等級就是繼續行駛，無碰撞風險障礙。

熔斷機制 & 碰撞檢測

在楊凱介紹功能安全的熔斷機制時，他說道：“在沒有功能安全這個機制的時候，系統需要把感知發給規劃，規劃再發給行動，進而行動再控制車輛。我們把主系統的控制權拿過來讓安全系統直接進行接管。”如下圖所示，右面是碰撞檢測，綠色區域是規劃距離，也就是正常的車在規劃過程中會與行車保持一個安全距離，而這個安全距離要遠于功能安全的檢測距離。紅色區域是安全檢測的碰撞區域，比如下面的公式，參考 mobilSS。第一部分 VR 是 round。第二部分是當前在 R 的時間內有可能的加速度，也就是你最大可能加速的時候可以行進多少距離。公式第三部分是后車加速到一個速度之后，它用極小的速度減速，往前運行。第四部分是突然減速，后車的距離。這四部分就是我們能夠剎住車的安全距離，在達到安全距離這種情況下我們就需要立即停車，保障避免風險。

另外在碰撞的時候，除了剛才強調的冗余機制、碰撞檢測之外，還有多樣性的感知算法，比如說 CNN 感知算法。

6.Apollo3.0 演進與 Apollo Pilot 量產園區解決方案詳解

從實驗室走向量產需要解決哪些問題？楊凡從安全、智能、量產及經濟四個方面為大家進行了講解，并提出了為量產車輛量身打造的一站式解決方案。

量產園區自動駕駛解決方案

首先，最重要的一點是安全，安全不管是 Apollo 發布還是在日常工作中都是最核心的事情，Apollo 大量的工作或直接或間接都是安全。在這其中，百度最關注的就是從整體設計上的安全。因此，百度作出了一個獨立的物理隔離的安全功能，另外還提供了網絡安全、所有的驗證安全，以及對行使過程中的安全和運營進行多方面的考慮。

接下來是智能，百度完成量產是為了和市場合作，真正把它做成一個產品。所以，它應該是足夠智能的，能夠解決它在路上所有實際應用需求的工況，并要有實際的可應用價值，還需要與人有足夠多的互動。

第三點是量產，我們知道做第一輛車很簡單，因為其具有的獨特性，只要用最好的儀器和設施就可以，如果出現問題，可隨時用更好的工具進行調整。但是如果是量產的東西，就會出現經常說到的召回的概念。但事實上，如果真正有問題了，特別是現在在很多產業通用化的前提下，一個平臺召回可能是幾十萬輛車，這是非常巨大并且不可能承受的成本。所以在量產上，需要防患于未然，在量產設計之前要把翻案和可行性做到切實，并且在生產過程中需要讓每一個工人可以使用有效的方式來簡潔明確的把這個東西生產到位，這就是與實驗室的不同。

最后是經濟，價格必須要降到足夠便宜。關注 Apollo 的朋友應該知道，一開始的價格都是比較高昂，包括 2B 的消費者可能都不見得能承受這樣的產品。而現如今，剛剛推出的 Apollo 兩款產品，一個是阿波龍，一個是 L4 小車，都是可以完成量產，這是一個突破，實現則需要滲透到方方面面。也就是說在設計階段要考慮合理的成本，還要有高能力的配合，然后在具體供貨階段要考慮這些供貨必須是市場上穩定的，才是一個穩定有保障的解決方案。

Apollo Pilot MiniBus 和 MicroCar 方案都包括自動駕駛套件、安全保障體系、人機交互方案、量產工具組件、高效運營方案。

自動駕駛套件包括結合車型的硬件方案和軟件方案。在安全保障體系中，百度對網絡安全、功能安全、驗證與測試及風險應對機制等方面進行了全面升級，為自動駕駛量產打造了全生命周期保護。除此之外，百度還提供了智能人機交互方案，為優質和安全的用戶體驗保駕護航。量產工具組件可以將以往需要工程師實施的高精工作讓產線工人大批量高可靠地完成。

最后，楊凡分享了百度對 Apollo 3.0 高效的運營方案。從 OTA 更新和車隊管理入手，為用戶提供自動駕駛套件及高精地圖，對車輛及模塊狀態進行監控和遠程控制、提供站點播報和多媒體內容管理，并開放 API。在未來，量產解決方案將助力合作伙伴實現更高、更強的自動駕駛能力。