自動駕駛仿真大觀！一起聊聊自動駕駛仿真這個行當！

各位聽眾朋友大家好！又到了模擬大觀園節目時間了！今天將由我來為大家浮光掠影地介紹一下自動駕駛模擬這個行當。

首先說為什麼自動駕駛需要模擬。幾年前看非誠勿擾，嘉賓黃瀾表示要有2/3的人接受自動駕駛她才會接受，體現了普通群眾對於自動駕駛安全性的關注。而為了要確保安全性，自動駕駛演算法在真正大規模應用之前，就需要經歷大量的道路測試。但自動駕駛系統的測試非常「貴」：時間和資金成本龐大，所以人們就希望將盡量多的測試搬到電腦系統中去做，用模擬暴露自動駕駛系統中的大部分問題，減少實地路測的需求，因此，我們的飯碗就出現了。

一、模擬場景

模擬場景即自動駕駛系統的test case。根據中國汽車技術研究中心的分類，自動駕駛測試場景可分為【自然駕駛場景】【危險工況場景】【標準法規場景】【參數重組場景】等四大類：自然駕駛場景來自汽車真實的自然駕駛狀態，是建構自動駕駛測試場景中最基礎的資料來源；危險工況場景主要包含大量惡劣天氣環境、複雜道路交通以及典型交通事故等場景，如CIDAS資料庫；標準法規場景是驗證自動駕駛有效性的一種基礎測試場景，是透過現有的標準、評估規程建構測試場景，目的是對自動駕駛汽車應該具備的基本能力進行測試；參數重組場景是將已有模擬場景進行參數化設定並完成模擬場景的隨機產生或自動重組，具有無限性、擴展性、 批量化、自動化等特性。

場景庫搭建流程大致可分為【收集資料】：即實際道路資料和法規資料等、【處理資料】：即從資料中擷取特徵並組合形成場景和【應用資料】：場景庫測試並反饋。

目前，自然駕駛場景的生成基本上已經自動化：採集車按照一定的格式收集數據，演算法篩選可能會有用的關鍵片段的數據，演算法計算片段數據中本車和周圍其他車輛的軌跡，再把軌跡寫入場景描述文件，例如OpenScenario格式的場景文件，現有的許多模擬軟體都可以直接利用這樣獲得的場景文件進行模擬。需要注意的是，在這種情況下，仿真軟體中還原出來的只是實採場景的“邏輯”，場景中的參與者披著仿真軟體三維模型庫中的車輛模型“馬甲”上演著一幕幕真實行為片段。換句話說，這樣還原出來的場景當然可以滿足規控演算法的測試，但這樣無法還原當時的感測器感知訊息，因為畢竟還是由模擬軟體的三維模型來扮演的前景車輛和背景。現在如果想要還原感測器感知訊息，可以應用NERF。

那麼，究竟什麼樣的模擬場景才是有價值的呢？路測車輛收集的自然駕駛資料還原場景被認為是最能接近真實路況且隨機性強的，但我們不是說目前路測花費的時間長趕不上趟兒嗎？這就需要我們對路測資料進行處理，將交通參與者辨識提取出來後再重新排列組合，形成基於真實資料的隨機場景。

例如百度19年大火的論文介紹了他們的AADS模擬系統：在該系統中，使用一台安裝了雷射雷達和雙目相機的汽車掃描街道，便可獲得自動駕駛模擬的全部素材，然後自動將輸入素材分解為背景、場景照明和前景物件。透過視圖合成技術，可以在靜態背景上改變視點，產生任意視角的真實影像，進而模仿車子在不同環境中行走的動作。那麼如何證明這些重組場景的有效性呢？論文中提到了一種透過比較虛擬場景和實際場景中感知演算法的辨識效果來評估的方法，用被測對象的表現來評估測量工具，也很有趣。後來的一些應用於自動駕駛的NERF研究中，也使用的是這樣的一套思路，例如UniSim。

我個人認為，再有效的自然駕駛資料模擬場景也只適合部分演算法的測試：這種方法不管怎樣，周圍物體的軌跡都是錄製好的，是沒辦法根據本車行為改變的。這就像是電影和遊戲的區別，電影中的場景只能播放，而遊戲是可以根據互動改變場景的。

也許在不久的將來，結合交通流模擬和真實數據，隨機場景產生可以批量建立既符合真實交通狀況，也能夠隨本車行為變化的模擬場景。

二、模擬開發

我們之前談到的場景庫，可以說是在為自動駕駛模擬測試準備數據，那麼模擬開發工作就是在創建或完善工具了。

模擬開發大概包含以下幾個面向：

1. 【場景庫】：我之前說過很多了，會包含資料處理、深度學習、資料庫等技術內容
2. # 【感知】：有了模擬環境，需要將環境資訊傳遞給演算法，因此需要建立各種感測器模型，如相機、光達、毫米波雷達、超音波雷達等，根據需要建立物理原理級模型和理想模型。感測器建模想要做得好，需要感測器工作原理的理論研究、物理過程的電腦建模和工程落地能力，以及大量實驗數據支撐。
3. 【車輛動力學】：演算法輸出的控制指令需要有控制對象，因此需要車輛動力學模型，這幾乎是另一個學科，會有專門的工程師研究動力學模型，在自動駕駛仿真中需要能夠接上專業動力學模型或簡化。
4. 【中間件】：演算法與模擬平台間，不同功能的模擬平台間都需要資訊交流，因此需要大量介面開發。自動駕駛研究階段較常用的中間件如ROS，在應用階段常用的如基於AUTOSAR的中間件。
5. 【模擬引擎】：有企業喜歡自研模擬平台，那麼管運動、碰撞的是物理引擎，常用開源的如ODE、Bullet、DART等，管三維顯示的是渲染引擎，開源的如OGRE、OpenGL。 Unreal和Unity是常用來製作遊戲的既有物理也有渲染的兩套引擎。
6. 【模擬加速】：會牽涉到平行運算雲端運算等，自動化測試也可以算在這裡吧。
7. 【前端】：我看有很多模擬開發的職位其實都是在招募前端，因為模擬的動態可能需要顯示互動等。

最後我覺得可能還有更高進階要求的第8點：「哪裡不會點哪裡」的能力，例如如果你的被測對像只是自動駕駛功能框架的一部分呢？你能不能透過開源演算法把剩下的補齊，讓「閉環」跑起來？

三、模擬測試

有了自動駕駛模擬測試所需的資料和工具，接下來就是模擬測試了。今天主要介紹幾個常見模擬測試鏈路。

1. 【MIL模型在環】：說實話我不是很知道模型在環和軟體在環的差異（也許和MBSE方法論興起有關）。狹義上來講，模型在環是在編寫編譯實際程式碼之前使用例如MATLAB等工具驗證演算法邏輯功能的測試。說穿了就是用simulink模型實作演算法，進行模擬。
2. 【SIL軟體在環】：使用實際編譯後的程式碼軟體進行測試，按理說模型在環測試通過了，SIL只是檢測程式碼生產上是否有問題。和HIL一樣，SIL需要為被測對象提供一系列的運作環境、其他與待測功能無關的前置虛擬訊號等。
3. 【HIL硬體在環】：廣義地講，只要是一個硬體在迴路中受到測試的方法都可以叫做HIL，所以針對某個感測器所做的測試也可以叫HIL測試。狹義地講，我們一般指控制器硬體在環，是以實時計算機運行仿真模型來模擬受控對象的運行狀態，透過I/O接口與被測的ECU連接，對被測ECU進行全方面的、系統的測試。從HIL開始，要求模擬測試具有強大實時性。
4. 【VIL車輛在環】：我了解一般有兩種車輛在環的方式：一種是搭載自動駕駛系統的車輛安裝在試驗台上，車輪卸掉替換為模擬負載的拖曳電機，地形路面給車輛的激勵都透過試驗台來模擬，在這種方式中如果加上了很好的顯示系統，也能夠作為駕駛員在環仿真係統使用；另一種是車輛可以在一個空曠場內行駛，由模擬系統提供感測器輸入，讓車輛雖在空場地中，但演算法也會認為周圍有各種不同的場景，一般可用車載GPS提供位姿回饋給模擬系統。

四、日常工作

前面幾節說了那麼多，都是在總體介紹我們這個行當，都是我這個盲人摸出來的大象，本節就來談談大體上我們每天都在幹嘛。這些日常工作當然是包含在第二、三節的內容當中的：

1. 【感知】：搭建感測器模型必不可少，需要注意到每種感測器的一系列參數，如探測距離、探測角度範圍、解析度、畸變參數、雜訊參數、安裝位置等，還有硬體的通訊協定等。接下來視所用的模擬軟體工具不同，看看是「配置」已有類型的感測器，還是要自己基於模擬軟體開發新類型的感測器。為了演算法模型的訓練或評價，模擬往往還需要提供真值，如2D/3D包圍框、車道線等地圖資訊、2D/3D佔用柵格等等，如果模擬軟體既有功能不能滿足，就也需要工程師做二次開發。
2. 【車輛動力學】：需要根據車輛參數在專業的動力學模擬軟體中配置車輛模型，也需要能夠根據簡化公式直接編寫簡化的運動學、動力學模型。
3. 【中間件】：介面的開發是重要的工作內容，要負責當好被測對象與模擬軟體間的「翻譯」；另外就是使用軟體的api介面實現不同層級模擬平台間的聯合仿真，例如場景仿真聯合車輛動力學仿真，再加上交通流仿真，再統一放進自動化測試管理軟體的調度中去。
4. 【模擬加速】：我把自動化測試也放到了模擬加速裡，因為要是能夠實現7x24小時不間斷測試也是一種提高效率的途徑吧！這就涉及了自動化呼叫模擬平台、自動化腳本編寫、錄製資料、根據用例要求評估資料等內容。
5. 【軟體開發】：有自研模擬軟體需求的企業主要就是這方面業務。

另外還有一點6.【需求分析】：身為模擬開發工程師，你理應是最了解你所用工具的那個人，所以一旦客戶（內部外部都算）有了新需求，模擬開發工程師應該能夠根據需求和被測對象的具體情況設計技術方案、提出軟硬體需求和專案計劃。所以有的時候，產品和專案管理的活都要幹。

五、技術堆疊

「技術堆疊」這句話聽著挺洋氣，但其實就是這個崗位應該都會點啥。很久以前我看過一個電視劇，裡邊一個急診的大夫自嘲：我們是萬金油，人家外科大夫才是金不換。我一直認為模擬工程師就像醫院裡的急診科大夫，什麼都得知道點：測試什麼演算法，那麼除了這個演算法之外的所有東西都要準備好，導航定位、控制規劃、資料處理、參數標定、天文地理、醫卜星象、金批彩掛、評團調柳……可以不求甚解，快速滿足演算法測試需求是最重要的。

這種所謂的「全局觀」是模擬工程師的優勢，但只有對演算法有真正的了解，才能做出能真正幫助演算法改進的模擬工作，也才能走得更遠。扯遠了，拉回來：

1. 【程式碼】：主要是C /Python，但如果涉及到前端顯示的部分我就不了解了。一般來講要求肯定沒有演算法開發那麼高，不過如果是專屬模擬軟體開發的另當別論。
2. 【ROS】：單拎出來是因為目前ROS仍是自動駕駛和機器人演算法研究領域繞不開的一部分，且ROS社群中提供了許多現成的許多可用工具。
3. 【車輛動力學】：可能不需要像真正的車輛工程師了解得那麼多，但基本原理是要知道的。另外就是各種座標轉換需要熟練（這條可能不算車輛的，算數學）。
4. 【感測器原理】：自動駕駛車輛上的相機、光達、毫米波雷達等各種感測器是如何運作的，輸出的訊號長什麼樣子，有哪些關鍵的參數。
5. 【地圖】：模擬測試場景使用的檔案格式如opendrive、openscenario需要了解，因為有時候需要從其中提取資訊作為感測器模擬的輸入。

以上只是我個人的一點總結，歡迎廣大同行在此補充！

為了文章的完整性，我也會在這一節簡單介紹下市面上常用的一些模擬軟體（真的不是廣告！沒上榜的也不要氣餒）。

1. CarSim/CarMaker：這兩款軟體都是強大的動力學模擬軟體，被世界各國的主機廠和供應商所廣泛使用，也可以做一部分道路場景的模擬。
2. Vissim/SUMO：Vissim是德國PTV公司提供的一款世界領先的微觀交通流模擬軟體。 Vissim 可以方便的建造各種複雜的交通環境，也可以在一個模擬場景中模擬包括機動車，卡車，有軌交通和行人的交互行為。 SUMO是開源軟體，可以透過互動式編輯的方式添加道路，編輯車道的 連接關係，處理路口區域，編輯信號燈時序等。
3. PreScan：已被西門子收購，用於建立和測試演算法的主要介麵包括MATLAB和Simulink，可用於MIL、SIL和HIL。
4. VTD：作為商業軟體，VTD可靠性強，功能全面，涵蓋了道路環境建模、交通場景建模、天氣和環境模擬、簡單和物理真實的感測器模擬、場景模擬管理以及高精準度的即時畫面渲染等，說一句VTD是國內主機廠使用率最高的模擬軟體應該不為過。可以支援從 SIL 到 HIL 和 VIL 的全週期開發流程，開放式的模組式框架可以方便的與第三方的工具和插件聯合模擬。
5. CARLA/AirSim：兩款開源模擬平台，都依托UE開發，也推出了Unity版本。 CARLA可以製作場景和配套的高精地圖，支援感測器和環境的靈活配置，它支援多攝影機，雷射雷達，GPS 等感測器，也可以調節環境的光照和天氣。微軟的AirSim有無人機和車輛兩種模式，車輛模式下的功能實在乏善可陳，沒法很方便地建立環境和車輛模型，社區也沒有CARLA活躍，建議以後招人寫JD別把AirSim算進去了，沒多大用。另外，國內的深信科創最近推出了基於CARLA開發的OASIS，目前可視為開源CARLA的加強版。
6. 51SimOne/PanoSim：這兩個都是國產的模擬軟體，場景模擬軟體該有的主要功能他們都能滿足。

最後再補充一個lgsvl：本來lgsvl的優勢是和Apollo結合得較好，但是我聽說lgsvl的官方已經放棄了這個項目，所以我勸你棄掉這個洞。

六、學習路徑

相信透過我前五節的介紹，聰明的在校同學已經可以從中體會出成為一名自動駕駛模擬工程師的學習路徑，而透過批判我前五節的內容，年輕的同行也已可以從中得出進階之道。但本節我還是寫一些在這方面的粗淺理解。

我前邊說了那麼多，想必大家也能看出來，自動駕駛的模擬是一個多學科交叉的領域，能夠接受來自很多專業的同學，包括但不限於：電腦/控制/機器人/機械/車輛/電力電子等等。

經歷與技術上，我嘗試列舉一些任職要求：

1. 程式碼能力：做模擬的雲端運算、雲端伺服器等相關開發的同學可能需要熟練使用C /Go/Java任何語言的開發，有良好的程式設計習慣，掌握常見的設計模式、資料結構與演算法，熟悉Linux系統、Docker技術及Kubernetes的相關知識，有雲端服務開發經驗，這些是奔著高並行高復用高自動化的自研模擬測試平台去的。另外，自研模擬軟體的職位除紮實的電腦基礎外，可能需要遊戲引擎的開發經驗，所以做遊戲開發的同學也可以轉行到自動駕駛模擬上（包括技術美術）。目標是應用已有的模擬軟體進行二次開發和整合的同學可能需要熟練使用C/C 和Python，熟悉Linux/ROS的開發，如果能夠有AUTOSAR等車規級中間件的開發經驗更好。
2. 軟體經驗：任何的自動駕駛模擬軟體的實際使用經驗當然都是加分項，但是由於商業軟體大多非常貴，因此在這點上很依賴學校實驗室或公司的實力。在沒有商業軟體支援的情況下，我認為現在CARLA是開源軟體的最適解。
3. 領域知識：我個人認為，身為自動駕駛模擬工程師，對於自動駕駛演算法怎麼深入了解都不為過，包括演算法的原理實現的方方面面，只有更好地了解演算法，才能更好地做好仿真。另外，如果是非電腦專業出身的同學，學好本門兒的專業課也十分重要，例如機械、車輛、力學、電子等等等等，守正才能出奇，總會用到。

目前自動駕駛產業正經歷很大波動，但總結起來能用到模擬工程師的主要有以下幾類企業：主機廠，以整合應用成型模擬軟體為主，但新勢力基本上都要做自研；自動駕駛解決方案供應商，也就是演算法的Tier1，可能也是自研模擬的居多；模擬軟體企業，這方面國內才剛起步，基本上都是新創企業。

在本節的最後我再談一點從傳統機械「轉行」來的體會。我碩士畢業的一個學校具有濃厚的轉碼風氣，我那屆入學機械研究生院的中國學生裡，大概有十之七八畢業後都從事了電腦行業。有賴於相對寬鬆的選課制度，同學的操作是盡量多修電腦學院的課程。於是在那兩年，焚膏油以繼晷，恆兀兀以窮年是常態。但我不記得當年找工作需不需要刷題了。總之一句話，機械如何轉型計算機：去讀半個電腦學位。其實當時也不單機械，各個專業都在轉，也不單是中國學生，全世界人民都這樣。

不過後知後覺的我並不在當年的這十之七八里邊，所以我錯失了轉型最好的機會。等到靠自學的時候，就難多了：最主要沒有時間，這就更要求學習資料和方法要有效率。因此相對來講，還是上網課效率較高，畢竟有老師指導。 Coursera的課不錯，好像比較貴。近幾年開源的網路資源越來越多了，不過上的課在精不在多，畢竟電腦最注重實作也最容易實作。電腦經典的著作也很多，像是資料結構與演算法、c primer……我是一本沒看過，有些事真的一旦錯過就不再。

其實我覺得，一個最容易的轉型方式就是，直接從事電腦相關的工作，有了需求提高是最快的，解決了我上面說的學習方向問題和時間問題。不過要是因此產生了績效不達標的問題，您當我沒說。

七、關於NERF

NERF正伴隨著“資料閉環”、“大模型”、“端到端”這些新興熱門詞彙一起在自動駕駛領域「興風作浪」。短短幾年的時間，NERF再也不是出道時單純的MLP 體渲染，儲存空間資訊的載體五花八門：哈希表、體素網格、多維高斯函數…新的成像方式也層出不窮：U-net 、CNN、光柵化…自動駕駛方向只是NERF一個很小的應用分支。

NERF應用到自動駕駛模擬方向，主要會面臨以下這些問題：

自動駕駛資料收集的方式導致場景的範圍「不閉合」：室外的場景會包含大量遠景，這對NERF的空間資訊儲存是很大挑戰；自動駕駛場景包含大量的動態物體，NERF需要能夠處理動靜態物體（或曰前景背景）的分離；NERF模型普遍不具有遷移能力，可能每個場景都需要訓練單獨的NERF模型，而NERF的訓練仍然比較慢，所以NERF在自動駕駛資料上的大規模應用仍然會有問題。

不過我仍然期待著，同時也相信，NERF會為自動駕駛模擬帶來顛覆性的發展，最終消除仿真在感知演算法上的domain gap，甚至做的更多。從我所了解的資訊來看，NERF至少會帶來以下這些突破：

NERF新視角影像合成的能力可以增強感知演算法訓練資料集：可以產生新感測器內參（相當於改變了感測器配置）、外參（修改了自車軌跡）下的圖片、雷射雷達點雲等數據，給感知演算法更多訓練數據，這方面可以參考StreetSurf、UniSim等研究。在動態物體可編輯的情況下，將來NERF可以產生有針對性的極端情況、隨機情況場景，補充單純路測和WorldSim的不足。如果NERF可以同時很好地解決城市級場景的訓練重建和即時渲染，那麼NERF就完全可以做為一個XIL在環仿真測試的平台，而不會有感知資料domain gap的問題，也會推動端到端算法的發展。另外，NERF的模型甚至也可以作為一個插件放入遊戲引擎（如3d Gaussian Splatting的UE插件已經問世），這樣就可以把NERF的街景重建納入到原有的WorldSim體系中去。如果考慮與AIGC方向的大模型結合，NERF在新場景生成上就會有更多的可能性：將可以任意編輯光線、天氣、物件外觀和行為等等。

所以身為模擬工程師，我強烈建議廣大同行密切關注NERF方向的進展，儘管NERF的各研究項目還都只是初具雛形，但現在深度學習方向在硬體的加速下進展已經越來越快了。

八、寫在最後

雜七雜八寫了這麼多，最後還有一些感想。

模擬開發有什麼坑。技術上的坑不在這裡討論，在這裡只說一點整體上的感想。那就是要警惕你是否在過度陷入到毫無意義的工作中去：給不同人做類似的項目不算，完成好每個項目就是價值；不使用現成工具非要自研長期看也不算，脫離對特定工具的依賴是有價值的；研發上很多事後被證明不通的嘗試也不能算，研發的失敗也有價值的。那麼具體什麼是「毫無意義」的工作呢？這就見仁見智了，我總結不好。

還有從這個職位出發能幹嘛。如果你在工作中對被測對像有了深入的了解，那麼或許可以嘗試轉向某個方向的演算法開發崗位；還有就是機器人、無人機的模擬開發也可以考慮。

移動機器人和自動駕駛的相通性自不必說，這裡提一下無人機。無人機產業的體量肯定沒有汽車這麼大，但也已經有了落地點，像是巡檢、空拍、測繪等。無人機也需要自動操控演算法來進行避障、路徑規劃等，無人機使用的感測器也和無人駕駛車車輛類似，因此可以說模擬測試有相通之處：無人機也需要豐富的視覺影像、雷達點雲等感知輸入，需要更精細的動力學模型等等。

有興趣了解機器人和無人機模擬的同學，可以從開源的模擬平台Gazebo（https://classic.gazebosim.org/）入手，其對運算資源的需求不會像Nvidia的Isaac那麼高。

今年是OSRF從柳樹車庫獨立出來的第十一年，而機器人作業系統ROS和Gazebo至今已經有了二十多年的發展歷史。 Gazebo從最初一個研究生課題組的科研工具，逐步發展成了今天有11個發行版，以及二代ignition 7個發行版的獨立模擬軟體工具。

Gazebo支援ODE、Bullet等實體引擎，使用OGRE作為渲染引擎，可以創建三維環境，模擬相機、雷射雷達等多種感測器的信息，具有豐富的機器人模型：從機械手臂到輪式機器人，再到人形機器人。更重要的是，Gazebo天然地對ROS平台下的演算法提供全面的支援：畢竟如果你下載安裝一個desktop full的ROS版本，Gazebo是自備的。當然了，Gazebo作為一個開源軟體，只提供了一個起點，它的功能均衡，但是各方面都比較粗糙，不夠深入。不過就像太祖長拳，喬峰在聚賢莊使出來還是會不一樣的。

我上學的時候就接觸過Gazebo，後來工作做機器人仿真，一直在用Gazebo，直到改行做自動駕駛。這就好像，我和Gazebo是曾經的同學，那時年輕，大家都不懂事。工作後我和她再次遇見，決定再續前緣，如膠似漆兩年多，人也過了三十歲，我對她留下一句：我想有更好的發展，就離她而去……現在再見只會說一句：好久不見…

#

原文連結：https://mp.weixin.qq.com/s/_bOe_g3mqoobJUbFS3SNWg

以上是自動駕駛仿真大觀！一起聊聊自動駕駛仿真這個行當！的詳細內容。更多資訊請關注PHP中文網其他相關文章！