Pegasus Project（3）：智能駕駛實車數據處理系統

轉載自作者：我是路頭

連結：Pegasus Project（3）：智能駕駛實車數據處理系統-知乎 (zhihu.com)

來源：知乎

著作權歸作者所有。商業轉載請聯系作者進行授權，非商業轉載請註明出處。

Pegasus專案整體材料可以分成10個課題（按照自己的理解進行分割的）左右和大家分享，由於計劃中的前兩個課題已經和夥伴們分享過，今天開始從第3個課題：實車數據相關內容和大家一起分享。

一. Pegasus 體系

Pegasus專案是基於場景實作智能駕駛的典範。

其主要解決的核心問題為： 1. 智能駕駛的功能如何設計？ 2. 智能駕駛的功能如何驗證？

為解決以上兩個問題，Pegasus從產品設計到工具鏈，生成了完整的Demo。整個專案可以被分成四個部份（此處沒有參照原圖，詳見 ^[1] )：

結合以上Pegasus的整個實作鏈路中的四部份，在本文中將其總結為如 圖1.Pegasus架構圖 。

本文中 圖1. 中模型的下半部份主要回答第一個問題——智能駕駛如何設計。模型最上部份解決第二個問題——智能駕駛如何驗證。

二. Pegasus 中數據系統（不包含知識系統）

圖2.Pegasus的數據系統 展示了Pegasus四個階段中的數據流程。整體數據系統建立的主要目的是：

1. 標準化采集和訊號定義
2. 標準化不同資料來源資訊的數據分析流程
3. 標準化儲存
4. 參數化場景的泛化，系統數據模型
5. 標準化場景泛化產生的場景格式

數據種類主要被分為 ^[3] ：

1. Derived Vehicle Data： CAN，GPS，PIs，video and Annotations，PointCloud and Annotations
2. Subjective Data： questionaires，simulator studies，interviewers
3. External Data： weather，map，infrastructure，other traffic participant...
4. Open Data: Aggregated Data

本文今天主要圍繞紅線框中內容講解，即主要回答智能駕駛如何設計來進行討論。從原始數據到 邏輯場景和參數空間 （即L1-L4ODD J3016 2021版）可以大致的分成三個階段：

1. 數據采集 ： 主要由仿真測試，場地測試和道路測試作為數據主要來源；
2. 數據處理 ：數據預處理，場景提取，場景聚類，參數提取等主要過程；
3. 數據儲存 ：數據模型和儲存共享方案；

三. 數據采集

數據來源主要有場地測試，道路測試和仿真測試三種（ 圖3. 原始數據來源 ）。在智能駕駛設計中，不同的測試也提供了不同場景描述側重點，見 表1. Pegasus中的數據來源及說明 。值得一提的是，Pegasus的采集設計中同樣使用了無人機的使用。並且在實車測試（FOT 見 ^[4] ）中考量了不同傳感器配置以及智能駕駛功能是否裝配。而交通事故的采集則是為了尋找到智能駕駛的參數設計邊界。

實車數據采集是透過安裝一套專業的硬件采集器材，將車輛總線以及搭載的傳感器和後裝器材中的數據流儲存的過程。這個數據采集過程通常是連續的，但由於車載器材的儲存限制，也可以透過車端搭載的演算法將重要的場景數據進行保存或者透過通訊器材上傳至「雲」中以便後續繼續分析。這種車端的儲存和上傳由於安全性和儲存壓縮問題，是需要以特定的協定進行儲存的，例如：車載總線的CAN協定，Some/IP等。但為了在整條工具鏈上的靈活性，這些密文必須是可解析的。

四. 數據分析

本文主要集中在實車采集（包含道路及場地）的數據進行分析，如 圖4. 數據分析過程 所示。途中步驟不固定，按照不同廠商以及場景略有區別。本章節將分成兩小節進行講解。數據預處理和數據後處理。

1. 數據預處理

1. 數據脫敏 ： 車主資訊脫敏，交通參與者脫敏等，在必要時需要對傳感器級數據進行脫敏。數據脫敏和上傳的步驟安排根據不同的套用場景， 圖4. 中的順序並不固定。
2. 數據上傳 ：5G上傳或者硬碟上傳，參考數據量。
3. 數據解析 ：主要根據數據采集協定以及字典進行解析，比如L3Pilot 定義的CDF（Common Data Format）中對本車，定位，感知障礙物，感知車道線，外部資訊（天氣等）以及後設資料（駕駛員類別，車輛外形）進行了定義。
4. 數據模型轉換 ：對解析後的數據進行建模，以便儲存至數據庫中。
5. 數據質檢 ：此步既需在車端采集時做，也需要上傳後在數據預處理部份做。因為數據的錯誤或者不完整會在後續數據套用階段造成重大的不便。比如，傳感器標定數據誤差，數據同步誤差，傳感器/通訊故障等。在完整的智能駕駛數據處理工具鏈中，此步可以建立數據質檢規則引擎，透過對故障數據的理解，析出模型，對數據進行自動化處理。

2. 數據後處理

第二個主要的步驟是數據後處理和豐富過程，此階段的主要目的是用於析出邏輯場景以及其參數空間。這個階段的主要步驟如 圖5. 數據後處理步驟 。

1. 高階參數生成（Derived Measures） ：這個步驟主要完成對一些采集可直接獲取的訊號進行推導，生成新的高階訊號的過程。比如TTC，Time Headway，traffic density等。
2. 場景提取（Scenario Detection and Annotation） ： 此步驟主要包含場景提取和標註兩個主要的方法。場景提取表示透過分析智能駕駛采集數據中的訊號來辨識駕駛過程中的一些「連續動作」。例如一個車輛切入場景（ 圖6. 切入場景 ）可以用 公式1 對訊號進行分析從而提取場景。 對於傳感器原始數據如影片，點雲的標註也是數據後處理中的一個非常重要的步驟，透過視覺化分析工具，對於一些場景，比如駕駛員行為，互動，面部表情進行標註從而進行場景提取。 當然，目前關於場景提取部份也不止以上兩種方法。

d/dt(LeadVehicleID) ~= 0 & NewLeadVehicleDistance < ExclusionDistance & NewLeadVehicleVelocity < SpeedThreshold & NewLeadVehicleOrigin == {LeftLane, RightLane} 公式 1

3. 參數指標生成（Perfomance Indicator）： PI描述相關訊號，場景，事件的統計值。此時不在針對一個場景，而是某一類場景的一個參數空間邊界。PI包括：行程中切入場景的頻率，平均車頭時距，最大TTC等。PI也可以從知識中或者Accident數據中獲得，從而用於邊界確定。

此處隱含了一個步驟為場景聚類。DM 和PI共同組成了聚類後的場景參數空間，這些具有一定相似性（此處描述不嚴謹，後續會再跟新一些內容）的聚類的場景即邏輯場景，Logical Scenarios。

五.數據儲存

基於現在的雲原生技術，生成的邏輯場景和參數空間以一定的規範和模型被保存在「雲端」，透過數據共享Frame，OEM、供應商、試驗場、驗證單位可以對集合後的數據有統一的認識和管理。 結構化的場景可以按照檔模型以OpenDRIVE，OpenSCENARIO 或者UML模型 ASAM OSI 等各類規範的數據模型進行儲存。 圖7.6層場景模型 在Pegasus中用於對場景的結構化，作為數據模型的一種。

六.總結

在Pegasus長達3年半的研究中，整車廠、測試驗證中心、供應商們共同實作了L3等級的智能駕駛功能，同樣驗證了方法論，實作了以場景和數據為基礎的上雲工具鏈。本文重在普及，細節描述的很不到位。 有些部份為個人理解。多數參考了Pegasus中的一些文件。

本人在後續會在工作中繼續實踐此專案中的理論。歡迎大家共同討論。 如本文有問題，請各位提點。謝謝！

參考

1. ^ Daniel Lipinski,(2019), Introduction and Overview of 3.5 Years of PEGASUS
2. ^ Shalev-Shwartz, S., Shammah, S., & Shashua, A. (2017). On a formal model of safe and scalable self-driving cars.arXiv preprint arXiv:1708.06374.
3. ^ Hiller, J., Koskinen, S., Berta, R., Osman, N., Nagy, B., Bellotti, F., ... & De Gloria, A. (2020). The L3Pilot data management toolchain for a level 3 vehicle automation pilot.Electronics,9(5), 809.
4. ^ Burzio, G.; Mussino, G.; Tadei, R.; Perboli, G.; Dell’Amico, M.; Guidotti, L. A subjective field test on lane departure warning function in the framework of the euro FOT project. In Proceedings of the 2009 2nd Conference on Human System Interactions, Catania, Italy, 21–23 May 2009; pp. 608–610.