打造最可靠的自動駕駛基礎架構

文章做者：莫璐怡 Pony.ai

編輯整理：Hoh Xil

內容來源：Pony.ai & DataFun AI Talk

出品社區：DataFun

注：歡迎轉載，轉載請在留言區留言。

導讀：本次分享的主題爲打造最可靠的自動駕駛基礎架構。主要內容包括如何作 Pony.ai 自動駕駛系統的基礎架構，涉及到的技術困難，以及咱們是如何克服的。

首先先了解下傳統互聯網公司的基礎架構：

數據基礎設施，會包括大規模的數據庫、分佈式的文件系統；

計算平臺，可能會須要大量的服務器、大數據平臺、容器的管理機制；

Web 服務管理，同時還會有各類各樣的 Web Service，不停的迭代來知足新的業務發展。

這是傳統互聯網公司要作的事情，可是對於自動駕駛公司和 Pony.ai，在這樣的架構基礎上咱們還會作哪些事情？

這是 Pony.ai 的基礎架構，包含了全部傳統互聯網公司要作的事情，除此以外，還須要作以下事情：

自動駕駛車載系統，如何支持各類各樣的AI技術、算法，如何控制車輛，這都依賴於自動駕駛車載系統來完成。

大規模仿真平臺，Pony.ai 天天至少會跑 30W 千米的仿真測試（不少自動駕駛公司一年跑的里程可能只有百萬級別），這點對於自動駕駛測試來講很是重要。

車隊運營基礎平臺，Pony.ai 要打造本身的移動出行服務，須要基礎平臺來支持 Robotaxi 的運營。

可視化平臺與人機接口，可視化平臺是幫助咱們瞭解系統究竟是如何思考、運做的，或者當測試工程師作各類測試的時候都依賴於可視化平臺；人機接口，自動駕駛車輛最終是要提供出行服務，是有乘客在裏面，這時會有一個可視化的界面，來告訴乘客車所感知的周圍環境，以及接下來的駕駛操做等等信息，同時還會提供人機交互的功能，讓乘客也能控制車輛，好比輸入目的地，或者須要停車等等。

Pony.ai 的目標是打造自動駕駛移動出行平臺，咱們但願能夠在不一樣的城市，能夠提供大規模自動駕駛車輛的運營，那麼咱們的基礎架構會面臨如下挑戰：

車輛數量的增長，目前廣州已經有幾十輛車在進行測試，同時還在不停的增加着；

運營區域的擴大，剛開始只是在很小的區域進行測試，目前已經在幾百平方千米的區域進行測試；

數據量的增加，咱們有不少的傳感器，以及車輛和運營區域的增長，都使得數據量的增加很是很是很是大；

工程師數量的增加，目前 Pony.ai 有廣深、北京、美國四個 office，工程師的數量每週都在增加，因此致使模塊數量和內部代碼的數量也在增加。

全部的這些增加都要求咱們的技術棧是具備可擴展性的，來知足快速增加所帶來的挑戰。

剛剛講了整個基礎架構，其中重要的一點就是車載系統，在講車載系統以前，先簡單介紹下自動駕駛系統：

傳感器及其餘硬件：激光雷達、高分辨率攝像頭、毫米波雷達、GNSS/IMU、運算平臺，咱們可看到圖中標了不一樣的顏色，目前這些傳感器是經過 Supplier Partner 來獲得的，咱們本身不作傳感器，咱們須要去購買他們的產品，可是購買以後須要作數據進一步的分析和整合，而後作後面的處理，而後對於運算平臺除了 supplier 的一些應用外，咱們本身也會作一些優化。傳感器主要要作的事情就是接收真實世界的數據，而後傳遞給 Pony.ai 自動駕駛系統中。

自動駕駛系統：首先，要作傳感器融合，進行時間同步，將多傳感器的數據融合在一塊兒；而後是感知模塊，用來感知周圍的環境有什麼樣的障礙物和物體；接下來會進行行爲預測，預測這樣的障礙物或物體以後的行爲會是什麼樣的；而後纔到咱們的決策規劃模塊，按照以前的預測來決定以後車輛的動做，如急剎車、讓路、超車等動做；最後，就是咱們的控制模塊，他會按照決策規劃模塊，告知咱們的系統要怎麼作，而後決定怎麼踩剎車、油門，怎麼打方向盤。

車輛，咱們自己是不造車的，因此車輛是由 OEM 提供的，可是整個控制的算法，是咱們自研去作的。

除此以外，還有高精地圖與定位模塊，以及數據與系統架構（數據的處理，以及控制數據在不一樣模塊的流動）。

這裏介紹的是各個模塊，但最後把他們串聯起來，靠的是咱們的自動駕駛軟件系統，這就是自動駕駛的車載系統。不少自動駕駛企業使用的是 ROS 的一套工業系統，而 Pony.ai 是從第一行代碼開始，寫了一套 PonyBrain，自研的多層次自動駕駛車載系統，最主要的作的事情有：

多模塊的調度運行，全部模塊的調度運行都是 Pony.ai 本身去作的。

模塊間的消息通訊，如何把數據從激光雷達傳遞到傳感器融合的模塊，再把融合的結果放到感知模塊中，而後感知的數據怎麼告訴行爲預測、決策規劃等等模塊，以及如何拿到高精地圖與定位的信息。

車載計算資源的分配與管理，對於自動駕駛來講反應速度是很是重要的，這就須要咱們對內存、CPU、GPU 等有足夠的優化，作到定製化的車載計算資源分配與管理。

日誌記錄，同時咱們須要完善的日誌記錄，咱們全部的測試數據回來都須要一整套的 Pipeline 去作自動化的分析，而後幫咱們評判出有意義的數據，給到測試工程師或者研發工程師，進行進一步的分析去使用，而後進一步提高咱們的模型。

監控與報警，保證了咱們自動駕駛的安全性。

車載系統的挑戰：

① 可靠性：車載系統必須足夠的可靠，不能有任何的內存泄露、代碼邏輯的錯位，這種都是零容忍的，一旦發生了這樣的事情，對整個自動駕駛系統來講是很是嚴重的事故，是有可能影響到安全性的，對於 Pony.ai 自動駕駛系統技術的發展來講，安全永遠是咱們的第一位，因此全部影響安全性的事情，咱們都是零容忍的，同時他也會影響車隊運營的效率；因此咱們還須要系統監控與異常報警，一旦系統出現任何問題，咱們須要及時提醒安全員，作出車輛接管的操做。

② 高性能：知足模塊間通訊的海量數據壓力，同時實現低延遲。

③ 靈活性：支持多種不一樣類型的計算資源的接入，以及不一樣類型模塊的接入，須要有靈活的系統來支持計算資源的高速迭代。

車載系統的實踐：

可靠性：

① 代碼質量要求高：對於可靠性來講咱們有很是嚴格的 code review 和 unit test，相信這是在國內互聯網公司不太容易見到的一件事情，雖然會很是耗時，可是對可靠性的提高是有很是大的幫助的。

② 合理使用工具幫助發現問題：同時咱們也會使用很是多的工具，如靜態分析、ASAN 等等，來作離線的分析，來保證系統的可靠性。

③ 多重系統可靠性檢查：包括系統啓動前校驗，系統運行時實時監控，系統運行後數據分析等。

④ 這是咱們的持續集成與發佈的平臺：對於每一次代碼的修改，咱們都會進行仿真測試；而後對於研發的迭代，咱們每週會有 Release 版本的更新，保障版本的穩定性，同時，剛剛咱們整個測試包括封閉，半封閉，高峯期的測試，整個測試流程怎麼持續集成與發佈，也是保證系統可靠性的一種方法。

高性能：

① 合理的架構避免大數據拷貝等嚴重影響性能的邏輯。

② 依據模塊邏輯分配合適的計算資源，如內存、CPU、GPU 等。

③ 按期對整個系統 Profile 分析系統的性能瓶頸。

靈活性：

① 定義足夠通用的模塊公共接口。

② 定義足夠通用的消息通訊接口。

爲何須要仿真系統？由於仿真系統可使得咱們車尚未上路的時候，就已經作了大規模的自動駕駛測試，無需路測和人力接入就能夠評價系統的性能變化；因爲沒有進行路測，不會引發路面事故；同時，仿真系統還提供了基於數據驅動快速迭代算法的可行性，新的算法能夠先在仿真平臺上作驗證，一些具體的指標和測試的信息都會在仿真平臺上有所體現。

仿真系統數據的倆個不一樣來源：

① 支持真實路測收集的場景，咱們的路測數據很是的多，數據回來以後，經過 Data Pipeline 自動更新這些有意義和有意思的場景，咱們會根據當時的場景改動相應的模塊，而後會在仿真系統重跑當時的場景，來判斷新的方法是否 work；

② 支持人工和隨機生成的場景，這樣的一些仿真的場景，也是很是的重要的，由於雖然咱們在作大規模的路測，可是不表明能夠遇到全部的場景，不少場景沒法在路測中收集到，這就須要咱們經過人工去創造這樣的場景出來，給咱們的系統一些樣本，來學習如何處理這樣的場景，保證咱們新的 feature 在這樣的場景不會出現問題。

仿真平臺的挑戰與實踐：

① 仿真結果的可靠性：首先仿真的結果必須是可靠的，若是不可靠，用它檢測出來的結果是沒有任何的意義的。整個仿真是在服務端模擬車載環境跑的，同時在服務端構建車輛動力學模型，保證測試的數據足夠可靠。

② 仿真數據的選擇與管理：固然咱們會選擇合適的路測數據來幫助算法的迭代（這裏的選擇不是人工的選擇，是全自動化的選擇，幫咱們在茫茫數據中挑選出有意義的數據）；另外，咱們還會規範的依據類別管理大規模的仿真數據，好比感知模塊的一些改動，到底須要測試哪些數據，纔會更加的體現這個改動帶來多少影響，這裏咱們會有內部的一個分類，咱們不會對全部的數據進行無差異的仿真（這樣作意義不大）。

③ 仿真系統的性能：咱們將整個仿真系統並行部署在分佈式計算平臺中，這纔可能知足咱們單天 30W 千米以上的仿真測試，而且這個數據還在不斷增加。

數據基礎架構：

數據是自動駕駛技術進步的核心驅動力，沒有數據，咱們就看不到如今如此多的測試車輛在進行路測，數據自己有幾個重要的點：

① 如何存儲海量的數據，如何支持快速的訪問。

② 如何進行數據處理。

③ 如何進行數據同步，如何把不一樣區域、路測數據、車載數據同步到數據集中，如何讓不一樣辦公區的工程師均可以使用這些數據，對數據同步來講是一個很大的挑戰。

核心挑戰：

① 數據量大：咱們有 PB 級別的數據，這裏只是以攝像頭爲例，還包括其餘傳感器數據，以及系統運做的中間數據等等。

② 數據屬性不一樣於互聯網數據：咱們的數據由客戶端產生，有大量的傳感器數據、大量的模塊運行日誌，這與互聯網數據有本質的區別，因此對整個數據架構的要求也是不同的。

數據存儲的挑戰：

① 依據特定的使用場景設計合理的存儲格式的設計：以便於車載系統記錄、大規模數據分析（數據回來以後，須要有方法進行分析，找出有意義的數據）、部分數據訪問、文件系統存儲（如何高效的利用文件系統）等。

② 選擇合適的存儲系統：

針對冷/熱數據選擇不一樣方案

選擇高可用的存儲系統

選擇易於水平擴展，由於車輛規模是不停的在變大的，運營時間愈來愈長，數據的增加速度是遠超想象的，因此須要易於水平擴展的存儲系統。

控制成本，不能用過於昂貴的設備。

數據處理能夠幫助收集性能指標，有 MPI（平均每次接管所需里程）、模塊運行效率、乘客溫馨度體驗等，還有就是路測有趣場景的挖掘，如接管、急剎、感知算法識別、不合理的變道策略等用於模型訓練和仿真。

數據處理的挑戰：

① 減少數據採集處處理的全流程時間：如何以最快的速度把數據從車傳到中間處理系統，Data Pipeline 運行完以後，上傳到數據中心，這裏面咱們作了很是多的工做。

② 依據不一樣類型數據處理任務選擇合適的處理系統：計算量要求比較高的咱們選擇 CPU 密集型系統來處理；更多的會是車載的數據，咱們會選擇 IO 密集型系統進行處理。

③ 通用的任務定義以支持靈活的添加新任務：幫咱們檢測出來更多有意義的數據。

車隊運營基礎平臺：

咱們有一個 Pony Pilot 項目，在咱們廣州全部的內部員工均可以使用，同時在北京和美國加州，也有一樣的服務已經上線，那麼支持這樣的服務，咱們須要作哪些事情：

Fleet Control Center，車隊控制中心

Pony Pilot APP

Onboard system

各類各樣的 webapp，幫助咱們觀察整個車隊的運營狀況，幫助管理測試的車輛和人員。

車隊運營基礎平臺的挑戰：

須要支持複雜需求變化的 web 框架，同時咱們有大量的 web service 的部署與管理，這都須要咱們去完善 web 服務通用組件，例如部署工具、日誌記錄平臺隨時排查問題、監控平臺保證全部 service 平臺的高可容性。

容器與服務調度平臺：

經過 Kubernetes 來幫咱們作各類各樣的服務調度和集羣支持。

可視化平臺：

① 目標：方便人類理解無人車系統看到的世界

② 挑戰：首先，須要足夠的靈活，易於適配不一樣需求的工具；其次，須要有高性能的現實，如 3D 實時渲染的高效實現；最後，支持跨平臺的可視化框架，如桌面系統、移動系統、Web 等多平臺。

人機接口：

方便乘客使用的用戶界面，同時能夠看到自動駕駛是如何瞭解世界，如何作決策，如何規劃以後的行爲等等，給乘客更多的信息和信任。

總結：

① Pony.ai 的基礎架構工做包括：

傳統互聯網公司所須要解決的基礎架構挑戰。

自動駕駛技術特定的基礎架構挑戰。

② 在這裏工做你能夠：

接觸自動駕駛系統的各個方面。

設計並實現知足通用需求的單機和分佈式系統。

系統的保障自動駕駛技術的持續進步。

這是一個很是有意思的 team，裏面有不少有意思的工做，很是歡迎你們與咱們一塊兒來工做，推進整個自動駕駛的發展，謝謝你們！

歡迎關注DataFunTalk同名公衆號，收看第一手原創技術文章。