美團無人車引擎在仿真中的實踐

1. 引言

過去幾年，自動駕駛技術有了飛速發展。國內也出現了許多自動駕駛創業企業，這些公司以百度開源項目Apollo爲起點，大均可以直接進行公開道路測試，公開道路測試也成爲促進技術進步的主要方法。基礎問題得以解決以後，行業面臨的更可能是長尾問題，依靠路測驅動自動駕駛能力建設的方式變得再也不高效，離線仿真的地位日益凸顯。行業頭部企業在仿真的投入十分巨大，Waymo公司2019年公佈的仿真里程是100億英里，是路測里程的1000倍。

相應地，美團無人車團隊在仿真上的投入也在逐漸增大。在仿真平臺的建設中，團隊發現公開道路測試和仿真測試看似類似，實際上差別巨大：在車載環境下，爲了確保系統的穩定運行，一般要保證必定資源處於空閒狀態；仿真環境則不一樣，如何高效利用資源，如何實現壓榨資源的同時確保仿真結果與路測結果一致成爲了關鍵目標。在應對這些挑戰的過程當中，美團提出了無人車引擎的概念，將車載與離線環境的差別隔離起來：功能模塊無需任何更改即可以知足兩種場景的須要。

本文首先會介紹無人車引擎的概念，並以仿真環境面臨的挑戰爲線索介紹美團無人車引擎的核心設計。

02 無人車引擎

概念

無人車引擎是自動駕駛的基礎設施，在機制、工具和計算模型上對功能模塊提供支持，隔離自動駕駛所處環境，使各功能模塊專一於自身功能。

在機制層，他爲各功能模塊提供通訊、調度、數據、配置、異常監控等支持。

在應用層，引擎爲各功能模塊提供調試、可視化、性能調優、效果評估等工具支持。

在模塊層，引擎爲各功能模塊提供統一的計算模型和運行環境，確保他們在車上環境、分佈式環境、調試環境下的行爲一致。

美團無人車引擎的架構圖以下：

如圖1所示，做爲引擎支撐的主要部分，Perception、Localization、Planning等是自動駕駛系統中重要的功能模塊，它們實現了無人車系統的核心功能。引擎則在機制和工具，上下兩個方向上支撐他們：各功能模塊按照引擎的規範開發，直接或者間接地使用引擎機制層提供的功能並天然而然地得到工具的支持。好比，功能模塊只要使用引擎的通訊工具，就能直接得到數據落盤、性能報表調試信息可視化的支持，同時基於這些路測數據，在仿真環境下，功能模塊會自動得到單步調試、效果評估等功能支持。

自動駕駛引擎面臨的挑戰

圖1中所列舉的功能是引擎的基礎組成部分，引擎所提供的遠不止於此，對於多種環境的支持纔是美團無人車團隊引入引擎概念的真正緣由。前面提到，無人車首先運行在車載系統中，隨着技術和環境的變化，更多地運行於仿真環境下，兩者大相徑庭。車載環境下，無人車系統的運行環境較好，爲了保障各功能模塊可以正常運行，CPU、GPU、內存等資源要提供必定程度的冗餘。而仿真環境的要求徹底不一樣：從用戶的角度看，仿真的用戶是工程師，他們指望仿真任務可以在肯定時間內完成儘可能多的任務；從集羣的角度看，他們但願仿真可以儘可能提高資源利用率。接下來的部分將介紹無人車系統在這兩類環境下會面臨哪些挑戰，以及美團無人車團隊如何經過引擎應對這些挑戰。

行爲一致性的挑戰

早期，美團無人車團隊依賴於ROS搭建無人車系統，在車載環境下，ROS的表現合格。然而在開始仿真建設後，團隊遇到不少問題，其中最突出的是「行爲一致性問題」，這個問題具體是指：無人車系統在運行過程當中，當出現系統資源的變化，行爲也隨之發生變化。好比，當仿真任務在一臺機器上運行時，系統產生的結果和這臺機器的狀態有關，這臺機器被獨佔地使用或是和其它任務同時運行，結果會有差別。並且，即便不考慮資源利用率，讓仿真任務獨佔機器資源，同一個任務運行兩次，結果也會有微弱的擾動。

更嚴重狀況發生在離線環境，此情境追求資源利用率的最大化，意味着計算資源的十分緊張，擾動將變得再也不輕微，結果將變得更不可靠，仿真的結果也就失去了價值。

所以，如何在車上和離線兩套大相徑庭的環境下確保結果的一致性，是仿真引擎必須解決的問題。此問題由如下兩個緣由形成：一是功能模塊時序的不一致；二是功能模塊內部執行的不一致。

時序一致性

爲了介紹什麼是時序一致性，首先要介紹一下無人車系統中時序的概念。

無人車系統由多個功能模塊組成，功能模塊之間有數據依賴關係，好比Perception依賴於 Lidar、Camera的數據，Prediction依賴於Prediction的輸出。不一樣模塊的觸發條件不一樣，好比 Planning是依據時鐘觸發的而Prediction是依賴於Perception的數據觸發的。由數據關係和觸發條件造成的功能模塊的執行順序就是自動駕駛系統的時序。在理想狀況下，每一個模塊都能在知足觸發條件時馬上執行並在預期的時間內完成任務，也就是說，只要保留各模塊的輸出就能夠徹底復現線上的問題，離線仿真出現的問題在路測時也必然出現。

然而現實狀況遠比這複雜，舉例來講，當無人車通過擁堵路段時，Perception須要處理的數據會顯著增多，Planning也可能由於交通參與者過多致使耗時增加，時序必然與理想狀況不符合。以下圖3所示，在車載環境下這種行爲方式是沒問題的，然而在仿真環境時卻會致使嚴重後果：每一次計算環境的些許變化都有可能致使時序的變化，進而致使系統行爲的差別。

這就是時序一致性問題。爲了解決這種問題，美團無人車引入了調度器，時序的一致性由調度器保證。此外，引擎按照不一樣的應用場景，進一步細化了調度器的種類。其中最簡單的調度器是「在線調度器」，它的目標只有一個：在功能模塊處於Ready狀態時執行它，車載系統中就是使用的這種調度器，它的行爲方式也與ROS相似，不過他會記錄下調度時序以備使用。除此以外，引擎還提供一組離線調度器，以應對不一樣的使用場景。這裏在線和離線的差別根據數據來源判斷，若是數據來自傳感器那麼就是在線調度器；若是數據來自路測記錄那就是離線調度器，具體分類以下圖4所示：

如下是美團無人車引擎提供的調度器種類及他們的使用場景：

• 在線調度器：在知足觸發條件時當即觸發功能模塊，一般在車載環境下會使用；
• 復現調度器：按照調度器保存的調度信息復現調度時序，在調試時或復現路測場景時使用；
• 理想調度器：按照理想時序調度資源，一般在仿真時使用；
• 條件驅動調度器：在條件知足時調度功能模塊運行。在這種調度方式下，功能模塊的調度密度介於理想調度器和復現調度器之間，他的實現也相對簡單，是應用最普遍的調度器。

在他們的幫助下，功能模塊執行的時序就能獲得保障：只要調度器和輸入數據不變，那麼不管計算環境如何變化，各功能模塊的執行時序總能保持一致。

功能模塊的計算模型

時序一致性除了須要調度保證以外，功能模塊的內部計算必須是受到調度器調度的。功能模塊必須在調度器容許時才能開始執行，在結束時調度器能獲得通知。若是存在脫離調度器以外的計算線程，那麼系統的一致性必然沒法保證。爲此，引擎引入了標準計算模型，任何一個功能模塊都有應該遵照這個計算模型，從而得到引擎包括一致性保障、單步調試支持、信息可視化等功能的支持。

標準計算模型以下：每個功能模塊都有且僅有一個計算過程並以迭代爲單位，每一次調度完成一幀的計算。固然引擎並不控制幀計算內部的細節，幀計算內部的優化由功能模塊負責。

標準模型的定義並不必定符合每個功能模塊的實際狀況：好比Localization，它訂閱多類頻率不一樣的傳感器數據並以不一樣的頻率輸出。在實踐中，引擎經過對Localization功能的從新拆分實現了標準化。此外，對於像Perception這類計算量很大、同時兼具異構計算的功能模塊來講，多線程，異步I/O的機制必須引入，引擎同時提供了相應的支持確保符合標準模型。

在實踐過程當中，美團無人車團隊花費了至關時間來完成這些改造。改造完成後仿真結果的權威性獲得了增強，更重要的是：系統的行爲再也不受外部資源（GPU、CPU、內存等）的影響，這也爲離線環境提高資源利用率掃清了障礙。接下來介紹無人車引擎如何在功能模塊徹底無感的狀況下提高資源利用率。

04 資源利用率問題

前面提到過，車載系統和仿真系統環境差別很大：車載系統爲了追求系統的平穩運行會保證關鍵資源有必定程度的富裕；對於仿真系統，保留idle就是對資源的浪費。在系統的一致性獲得保障以後，資源利用率才能成爲引擎的優化目標。優化資源利用率包含了不少方面，好比數據調度等，因爲篇幅所限，這裏只介紹與引擎相關的優化工做。接下來的部分，將根據無人車系統在仿真環境運行時的特色進行優化，他們分別是資源需求不均、功能模塊的重複計算、GPU/CPU計算不平衡。

數據需求不均勻

從數據的輸入規模上講，各功能模塊是極不均衡的：Perception和Localization依賴於Lidar和Camera數據，數據使用量佔到系統的 85% 以上（按照數據存儲的規模計算，忽略中間數據，具體比例與開啓的Camera相關，此處給出概數）。從資源消耗上講，Perception和Prediction消耗較多的 GPU 計算資源。爲了提高雲計算資源的效率，無人車引擎必須支持分佈式部署：即一套自動駕駛系統分別部署與多臺機器甚至是跨機房的機器之上的。

爲了實現分佈式部署，引擎參考了計算圖模型的概念，採用了相似於Tensorflow的設計：將功能模塊分紅了Node和Module兩個部分。其中Node負責定義依賴關係，而Module負責完成計算。對於遠程部署的Module來講，引擎提供了ADVContext和Node Stub 的概念用於協助Module完成運算，對於Module而言，它對於自身處於環境（遠程或者本地）一無所知。

基於圖7的設計，自動駕駛系統有了分佈式部署的能力：一套自動駕駛系統能夠運行於一組機器之上。提高離線效率的努力再也不侷限於單臺機器，無人車系統的離線優化得到了更多的手段和更廣的空間。

重複計算

仿真任務分紅多種類型，即有運行單個模塊的任務，也有同時執行 Perception、Prediction、Planning的任務。對於同時運行多個Module的任務，放在集羣的角度看，不少計算都是重複的。試想一個場景：Planning引入新方法，工程師但願可以在最新Perception版本上的得到新方法的效果評估結果。對於仿真而言，這是一個經典場景，經常使用的方法是離線執行 Perception、Prediction和Planning三個模塊並執行Evaluation產生報表、評估結果。

通常而言，Perception的結果受到數據和自己算法迭代的影響，當 Planning的迭代時，Perception的結果不會受到影響，它的輸出徹底能夠複用。得益於Node和Module概念的分離，Perception Node所綁定的Module徹底能夠是一個非計算單元，而是一個數據服務Module。

在美團無人車數據平臺和無人車引擎共同努力下，經過Data Service Module, 這個常見的仿真任務的流程在工程師感知不到的狀況下變成了圖9這樣。不一樣版本的Perception的輸出結果被保存下來，Prediction和Planning只要使用以前的結果，避免了 Perception的反覆計算。

GPU計算分流

無人車系統是一個同時具有重度CPU計算和重度GPU計算系統，兩部分的計算是不平衡的。引擎爲了提高GPU資源的利用效率，在內部集成了模型管理的功能同時提供了本地和遠程兩種Prediction的機制。再結合分佈式部署方式，系統能夠徹底部署於CPU集羣之上，模型相關的計算能夠經過RPC請求在Model Serving上完成。經過GPU和CPU計算的隔離，引擎幫助提高了GPU和CPU計算資源的利用率。

05 結論

在持續的實踐中，美團無人配送團隊抽離出一套自動駕駛引擎，爲功能模塊提供機制和工具的同時，它還提供了對車載（低時延）和仿真（高吞吐）兩套環境的適配。此外，配合美團的大數據基礎設施以及在此基礎之上專爲無人車創建的數據平臺，美團無人車逐步創建了完善的自動駕駛基礎設施。將來，但願在引擎的幫助下可以隔離功能模塊、計算平臺、運行環境，使得自動駕駛能力迭代與自動駕駛落地應用兩個方向上的工做可以獨立開展，齊頭並進，加快美團無人車的落地步伐。

關於美團無人配送

美團無人車配送中心成立於2016年，由美團首席科學家夏華夏博士領導。美團無人車配送圍繞美團外賣、美團跑腿等核心業務，經過與現有複雜配送流程的結合，造成了無人配送總體解決方案，知足在樓宇、園區、公開道路等不一樣場景下最後三千米的外賣即時配送需求，提高配送效率和用戶體驗，最終實現「用無人配送讓服務觸達世界每一個角落」的願景。

招聘信息

美團無人車配送中心大量崗位持續招聘中，誠招算法/系統/硬件開發工程師及專家。歡迎感興趣的同窗發送簡歷至：ai.hr@meituan.com（郵件標題註明：美團無人車團隊）。

想閱讀更多技術文章，請關注美團技術團隊（meituantech）官方微信公衆號。在公衆號菜單欄回覆【2019年貨】、【2018年貨】、【2017年貨】、【算法】等關鍵詞，可查看美團技術團隊歷年技術文章合集。