本期 AI 前線社群分享我們很高興邀請到了百度自動駕駛事業部的毛繼明，為我們帶來《適用於自動駕駛的分散式模擬平臺》的乾貨分享。
首先給大家介紹下今天的講師：毛繼明，百度自動駕駛事業部資深架構師，自動駕駛事業部模擬團隊技術負責人。 目前重點關注分散式自動駕駛模擬平臺的構建以及百度內無人車模擬技術的研發。在分散式系統架構方面擁有豐富的經驗。
本次分享主要為以下五個方面的內容：
-
一、模擬產品的業務價值
-
二、如何達到真實性
-
三、如何完成更全面異常檢測
-
四、智慧輔助駕駛和全自動無人駕駛的區別
-
五、全面的無人車能力判定
模擬器，顧名思義，用軟體模擬真實。但是在 Apollo 中，對模擬平臺的定位是不僅僅是真實，而是要能夠進一步：能夠發現無人車演算法中的問題。因為在整個演算法迭代閉環中，光有擬真是不夠的，還需要能夠發掘問題，發現了問題後才能去 fix 問題，也就是回到了開發過程。
如此這樣，從開發到模擬再回到開發，模擬平臺跟我們的開發過程串聯成一個閉環。只有閉環的東西才能構成持續迭代和持續優化狀態。所以模擬平臺在整個無人車演算法迭代中的地位非常重要。
如上所述，模擬平臺的功能。
發現問題，進行功能拆解的話，可以拆成有因果關係的兩部分：
先要能夠真實，接下來要能夠進行全面的異常檢測。真實性，就是說要能夠對世界進行數學建模；全面的異常檢測，其中最難的是“全面”二字，這要看我們對“全面的異常”的定義。
客觀世界的真實性表達依賴於三部分：靜態環境的真實性、動態環境的真實性、車輛行為（也就是主車）真實性。
準確來說，對於靜態環境的真實建模本身並不難，比如遊戲畫面中，我們能經常看到“照片畫質”的渲染，看著都很真。最難的是“成本”兩個字，這個成本指的是：單位公里上全部環境建模的時間成本。無人車的場景重建跟遊戲中不一樣。遊戲中是藝術家是造出的場景，它不考慮真實。而真實模擬器中的場景是要跟真實世界做 diff 的，需要做到毫釐不差。
（1）靜態環境的真實性
靜態環境是相對於動態障礙物而言的，比如道路（包括各種地面元素）、柵欄、紅綠燈、路旁的路燈和綠植兩側的高樓。對於自動駕駛來說，它們屬於背景元素。當然大家能夠理解這跟行人、車輛等動態障礙物的不同。
大家都有過這樣的經驗，我們自己得到一個結果，這很簡單，但若要讓你得到一個跟別人一模一樣的結果，這個成本就大太多了。百度內部有成熟的百度高精地圖製作流水線，在釐米級精度的世界刻畫能力的基礎上，成本做到非常低。
那麼大家會問，我講了這麼多地圖生成的事，這跟模擬有什麼關係？其實，Apollo 模擬器的靜態世界的表達，正是直接使用了 Apollo 高精地圖資料。所以它是真實的，且是具有足夠低成本的。
（2）動態環境的真實性
然後是動態環境，也就是各種障礙物的行為真實性了。動態障礙物引入了人的因素，相對靜態場景重建更難，因為人的行為“難以捉摸”。對於 Apollo 而言，最快和直接的做法，不是擬真，而是直接“真”。
用實際路上採集回的海量真實資料，經過 Apollo 感知演算法，做動態場景重建。一方面，我們通過 Apollo 資料生態，會得到更多的資料用來補充場景，另一方面我們利用自身持續迭代的感知演算法可以更精準的還原世界。從量和質上都得到持續的提升。
（3）車輛行為的真實性
主要分感測器模擬和車輛動力學模擬。由於傳統的商業模擬軟體在這兩個領域已經進行了數十年的研發，成果已經被各大車廠所認可。Apollo 倡導開放能力、合作共贏，不應該也不可能重複造輪子，自己新搞一套別人已有的東西。所以這兩塊功能 Apollo 模擬平臺是以直接 involve 商業模擬軟體的方式實現這兩塊 feature。後面在講開放性的時候會提到。
在滿足了真實性後，我們來看看如何完成下一個需求：更全面異常檢測。
其實大家都知道，尤其是搞 IT 的同學可能會更清楚。所謂異常檢測，就是先給一個條件，再給一個預期輸出。就是大家寫的 UnitTest 的常用版型。方法論上都是一樣的。那麼對於無人車的異常檢測，什麼是條件呢？就是車輛執行的場景。什麼是預期輸出？就是要有一整套判定準則或者說判定演算法。
那麼很顯然，要做到全面的異常檢測，這裡重點或者說難點，肯定不在後四個字，而在於前面兩個字“全面”。場景，要是全面的場景；判定，要是全面的判定。
全面的場景。全面這兩個字很虛，而且“100% 全面”在理論上也無法達到。所以很顯然，唯一可行的做法是：在受限場景下逼近 100%。這個“受限場景”，換種說法，就是我們無人車演算法的問題域定義，也就是說這個演算法要解決哪一種受限場景。不同的應用場景，模擬器的設計可能會大有不同。目前以我的理解，能夠對模擬器設計產生革命性變化的，只有一種問題域的劃分方式，就是智慧駕駛 vs 無人駕駛。具體怎麼個革命性變化，後面會講。
全面的判定。這個取決於演算法能力域的設計。什麼叫演算法能力域？就是指演算法能達到的上限，也就是說，是 just work，還是 work well。對於判定演算法而言，如果僅僅是做“just work”級別的判斷其實並不難，難在對“work well”做判斷。所以這裡，也有一個對模擬器演算法產生重大影響的能力域的劃分方式，就是： “機器人型駕駛”（just work）的判定，以及“擬人型駕駛”（work well）的判定。
準確來講，無人駕駛屬於智慧駕駛的一個分支。這麼寫可能不太確切。但是，我想強調的是，無人駕駛和自動駕駛之間的有一個非常大的差異，就是：是否有人。
“是否有人”這個事情，對整個智慧駕駛無論是演算法、還是硬體設計、還是模擬器的設計，都產生了極大的影響。“沒有人來保底”決定了演算法需要應對的佔比從 80% 到 99.9999%。大家都瞭解 28 法則。從 80% 到 99.9999%，無論是演算法、還是硬體、還是模擬，需要解決的問題或者說面臨的困難要提高几個數量級。
99.9999% 是無人駕駛特有的要求。而 99.9999% 需要的是演算法“見多識廣”。要解決長尾問題，也就是要應對全自動無人駕駛的 99.9999% 的場景 handle 能力，必須要累計起【海量場景】。
也許大家對海量場景這個事情並沒有太多感覺。在實際的生產領域，擁有海量場景其實不是難事，難在海量場景的使用效率。我在前面講了，演算法需要高速迭代，我們的使用者需求是：30 分鐘，模擬平臺能告訴我什麼。30 分鐘，大家算算，平均時速 30km/h，只能跑 15 公里，如果是這種能力的話，其實不用談海量場景。
所以從百度內部最開始進行無人車專案時，就在著手考慮模擬平臺的執行效率。Apollo 模擬平臺通過 2 個不同層次的實現方式來進行大幅度優化。從巨集觀角度出發，通過大規模分散式化來進行；所以在 Apollo 模擬從最開始，就是以分散式模擬作為方向的。從微觀角度出發，通過動態變速模擬來進行。
這個是分散式模擬框架的簡圖。瞭解分散式計算框架的同學應該看這個比較眼熟。整體上看，分散式模擬架構按層次和功能，可以按照如下幾部分進行說明：
由於分散式模擬平臺的計算模型很像傳統的 MapReduce。所以整個分散式排程 follow 傳統的 MR 架構。
下層是 Hardware Resource Scheduler。由於模擬節點的執行會用到 GPU+CPU/only CPU/CPU+FPGA 多種硬體組合，又由於模擬的執行是一種彈性的資源使用。所以我們單獨的剝離出來一層 Hardware Resource Scheduler。這層 Scheduler 是支援更換的。比如在百度內部，我們使用了百度內部已有的資源排程器 Matrix，如果是在開源系統裡，我們支援使用 K8S，再比如我們跟 Microsoft azure 合作的 Apollo Simulation Global 中，我們使用了 MS 的 cosmos。未來如果做大客戶定製化，我們也可以支援大客戶內部專門的 Resource Scheduler。
上層是 Batch-job Scheduler。因為分散式模擬執行模式為 Batch-job，所以我們單獨剝離了一層 Batch-job Scheduler。它負責 job 的整個生命週期的執行狀態的推進，比如各種部署、啟動、執行狀態檢查、重試、優先順序、彈性伸縮……等邏輯。這塊同樣的，我們單獨剝離出一層的原因在於，我們解耦了這層標準化的分散式計算模型，也允許根據使用者特別的需要進行替換。在內部我們使用了百度的 Normandy 排程框架，在外部我們支援更換成業界主流的 K8S 等。
中間這層是模擬核心。它執行在 Docker container 中。模擬核心中執行的是客戶的演算法 + 模擬邏輯：包括場景重建 + 動力學模型 + 精細化度量。由於執行模型複雜，所以我們在 Container 內抽象了上下兩層：上層，我們內部叫做 Task Engine，專門負責複雜的模擬執行流程排程。下層是 Sim-Core，用來放置使用者的自己的演算法。
在外層有兩個 Storage Component：Scene Store，Result Store。圍繞著計算，統一管理了資料。Simulation-platform 主要提供了提交介面、資料分析、Dashboard 介面，串通起完整的模擬流程，供使用者使用。
這裡做一下對比，真實道路情況下，車載演算法是在車載電腦上執行，此時實時性要求很高，所以往往需要保留較多的系統資源冗餘（以應對隨時到來的系統處理顛簸的情況），萬一出現顛簸狀態，實時系統會採用丟幀的方式以保證執行時訊息處理的低延遲。
在模擬系統裡，這是在離線執行。如果不做任何處理，我們需要用更強力的伺服器，保留更多的系統資源，或者降低執行速率，以保證不丟幀。很顯然，這種做法一方面帶來大量的執行資源的閒置，另一方面降低了我們的執行速度。所以我們引入了動態變速模擬技術。
動態變速模擬技術，本質上是對無人車複雜資料流進行流控的過程。分解來講：
1）對於處理時間較短的幀，壓縮了資料處理的間隔；
2）對於處理時間較長的幀，等待處理完成再繼續處理後續的幀。而整個排程系統是一種根據當前處理幀的耗時做彈性變化。
通過這兩項改造，可以達到：不等待 & 不丟幀，這樣就可以充分的利用硬體資源，以最快速度執行。據實際測試，採用了動態變速模擬技術，在不影響模擬結果的前提下，單機模擬效率可以提升數倍以上。
從自動駕駛的能力上看，能力分成兩個層面：低端能力（能 work）以及高階能力（像人一樣 work well），所以從能力判定的演算法上，會有較大的不同。後一種（高階能力級別的判定）很顯然是非常有挑戰的。
我們先看一下低端的能力判定方法，它包括了兩層判定：
Level1：模組的執行可靠性判定。類似模組的 coredump、非法 exit、幀率異常等。
Level2：無人車基礎能力的判定。包括：到達目的地、碰撞、違章等。
很顯然，這樣的兩層判定可以通過“通用的規則”來實現。但是此時的通過僅僅代表了無人車能力的下限已經達到。此時無人車僅僅是能夠像是機器人一樣進行駕駛。
既然有低端能力，就對應有高階能力。何為高階能力？——像自然人一樣開車，可以通過圖靈測試。它仍然包括了兩層判定：
Level3：體感判定。體感判定包括了橫擺角，頓挫感等評估體系。
Level4：心理感受。心理感受包括了心理安全感以及遲鈍感等。
高階能力的判定。可以是一種圖靈測試的驗證，是場景特化的。它代表了無人車的能力的上限。
實際上，度量演算法的本質可以認為是：f(場景描述，車輛軌跡)，即某種場景和軌跡的二元函式。當我們擁有大量的正例以及負例，我們通過機器學習方法，基於大量資料，是可以得到一種具有足夠泛化能力的，並且能夠達到圖靈測試判定能力的度量能力。
事實上，百度長期的無人車路測，使模擬擁有了大量的實際的運營 / 路跑資料，我們針對性的大量採集、標註了細粒度的體感異常的 badcase 樣本，進而可以達到相當精準的異常判斷能力。我們會在 Apollo 裡將這樣的能力釋放給大家。
由於時間有限，本次內容分享到這裡就結束了。更多學習資料和自動駕駛相關內容，大家可以關注 Apollo 開發者社群的公眾號來獲取，歡迎大家在這裡溝通交流！
A1：這裡的 general rule 是指“通用規則”。簡單來講，碰撞、到達目的地、交規違規，這些可以認為是“最基礎的無人車能力”的判定。1）他們是通用的，在各個場景都應當存在且適用；2）他們可以用簡單的規則加以描述，來判斷無人車演算法是否異常。所以稱之為 rule-based。
A2: 這個問題非常好。其實百度在做的模擬平臺的目標是能夠提供給，達到商品級別的自動駕駛系統提供更高階的穩定性 / 安全性保證。所以才有了，我們是基於真實路況的真實資料，供給給演算法做測試。
那麼這種回放型，其實是一種靜態的“環境重建”。此時“重構的環境”與“無人車演算法”，是無法實現“與人博弈”的。目前，據我所知，全球只有 waymo 的無人車駕駛演算法裡，才有“與人博弈”的概念。
目前來看，支援“與人博弈”的模擬場景，有一種實現方案，我們在內部稱之為“多主車平臺”，即一個充滿著虛擬障礙物（人、車）的虛擬世界。把我們的演算法放在“虛擬世界”裡，與其他車輛進行博弈執行。
但是這裡有一個最大的前提，是要想達到期望的“博弈效果”，與你博弈的車輛必須是“足夠像人的”。否則你會在與一個“機器人”進行博弈。這種“錯誤博弈”產生的無人車演算法，上路會更加危險。當前“足夠像人”這個前提，還非常難以證明。我們選擇了一個更保守的回放型方案。
所以在百度內部，確實擁有“虛擬世界”這樣的產品，還僅僅正在試用階段。未來我們也會開放這樣的模擬器產品給大家。
A3: 採集回來的資料是“lidar、camera、radar、gps”等全部資料的 fusion 後的資料。
因此包括點雲（流）、圖片（流）等資料部分。
感知演算法的輸入是“原始感測器資料”，輸出就是這個世界的邏輯化表達。因此百度擁有的強大感知演算法使得我們可以對這個世界進行低成本（因為是通過演算法自動進行的），高精度的還原和重建。
A4: 這塊是離線的硬體資源排程方面的方法問題了。事實上在研發階段，無人車演算法往往是重 CPU-usage，輕 FGPA-usage。（當然量產後應該會反過來，大概率會把 fpga 切換到 asic 晶片）。所以如果簡單的將所有演算法構成一個完整包，部署在 cpu+fpga 機器上，會使得 cpu 壓力很大，而 fpga 壓力低，從而浪費 fpga 的算力。
因此我們會將車端“融合在一起的演算法”剝離成 cpu+fpga 部分演算法 以及 only-cpu 部分演算法兩塊。通過模組在不同配置（cpu+fpga, only-cpu）的機器上的排程，更充分的使用 fpga 卡的計算能力，增加整個叢集的吞吐。
更多幹貨內容請關注微信公眾號“AI 前線”，（ID：ai-front），回覆“公開課”可獲得AI前線歷史直播課程。