自動駕駛場景的描述方法

駕駛場景爲自動駕駛系統的測試和驗證提供了一個強大的框架。本文介紹了表徵場景的基本元素和時空關係,並逐步構建了一種表示它們的表現力語言。

駕駛通常被描述爲機動車輛的受控操作,通常用於人員或貨物的運輸,但也會作爲一種活動來享受。駕駛需要掌握一些技能,例如車道保持、交通合流、紅燈停車、避讓行人等。這些技能中的每一種都與我們在路上發現自己所處的某些情況或"場景"有關,需要我們以適當的方式做出反應。識別和表徵這些駕駛場景對於實現自動駕駛汽車開發和安全操作的幾個過程非常重要。

當面臨艱鉅的技術挑戰時,我們經常在沒有充分考慮問題空間的情況下潛入尋找解決方案。乍一看,自動駕駛似乎是一個典型的機器人問題,感知、規劃和控制是關鍵因素。雖然這些功能確實構成了此問題的任何解決方案的基礎,但你很快就會意識到問題的複雜性源於系統必須運行的條件的可變性。如果不花時間規劃出在路上可能遇到的不同情況,並特意針對這些情況測試系統,那麼你就有可能開發一個僅適用於少數情況的解決方案。

在這裏插入圖片描述

弄清楚更廣闊的可能場景有助於我們採取更全面的方法——瞭解問題有多大以及其多樣化,劃分出我們準備解決的問題的有意義的子集,然後設計一個滿足需求的適當解決方案。這也有助於我們弄清楚在所需系統中需要開發哪些功能並進行相應的計劃。

確定適用於所選域的方案是此過程的第一步。例如,如果你正在建造一輛自動穿梭巴士,以便在封閉的校園內運行,則相關場景集將與你在公共道路上可能期望的場景不同。然後,可以根據對你重要的因素來組織場景,例如車道駕駛與交叉路口、讓行與停車標誌、領先/跟隨與切入等。這種對方案進行編目的方式可能足以滿足某些用例的需求,例如根據驗證計劃測試和驗證系統。但是,通過將每個方案分解爲其構成元素,可以執行更多操作。

1、表示場景元素

先前的工作建議將場景的元素組織成不同的"層",例如道路或地圖信息,場景中的參與者,天氣和其他環境條件。通常還區分一般描述或"邏輯"場景,以及表示特定實例的更"具體"變體。這些也是我們在場景建模方法中採用的一些指導原則。但我們的重點是另一個方面——我們如何最好地表現不同元素之間的關係?

答案可能取決於你的最終目標是什麼,例如,你可能希望完全按照其播放方式重現一個場景(通常稱爲"重新模擬"),或者你可能希望獲得場景的不同潛在變體(有些人稱之爲"場景模糊化")。或者,也許你只想將相關方案聚集在一起,以瞭解問題空間。無論目前的用例是什麼,我們都會假設,能夠滿足所有這些需求的場景表示可能會更具表現力,並且對未來的使用也很健壯。

解決不同用例(包括提取,重新模擬和模糊測試)的常見場景表示將更具表現力和健壯性。

這種思路將我們引向了一種公理化的場景建模方法,我們試圖根據其突出特徵來表徵每個場景,而不會過度擬合特定的最終應用。讓我們從一個簡單的例子開始 - 一輛車在陽光明媚的日子裏在一段路上行駛。 在這裏插入圖片描述

請考慮以下事項:

  • 此方案中涉及哪些不同的元素?好吧,有車輛(例如V1),還有一條路(R1)。
  • 這些元素有何關聯?顯然,車輛V1位於公路R1上。
  • 在這種情況下發生了什麼?V1 正在以某種速度(例如,20 m/s)行駛(在 R1 上)。

如果我們要對這種情況進行最小描述,則對以下信息進行編碼可能就足夠了。

- weather: sunny
- road: R1
- vehicle: V1
    position: R1
    actions:
    - drive:
        road: R1
        speed: 20

2、空間和拓撲關係

如果我們有兩輛車在一條路上行駛,一輛跟着另一輛呢?

在這裏插入圖片描述

這一次,讓我們稍微迭代一下格式,併爲全球/環境因素(例如天氣)、地圖元素(例如道路、車道)和參與者(例如車輛、行人)以及其初始位置和操作創建不同的部分。此外,現在我們有兩輛車在同一條道路上,因此需要額外的措施來區分它們沿着道路的位置。這通常被稱爲縱向位置或"station"(s座標)。

environment:
- weather: sunny
map:
- road: R1
actors:
- vehicle: V1
    position:
      reference: R1
      station: S1
    actions:
    - drive:
        road: R1
        speed: 20
- vehicle: V2
    position:
      reference: R1
      station: S2
    actions:
    - drive:
        road: R1
        speed: 20

在這裏沒有捕捉到的是兩輛車的位置之間的空間關係,即V2(S2)領先於V1(S1)的事實。我們可以在單獨的一節中表達如下:

...
relationships:
- S2 > S1

或者,我們可以根據S1重寫V2的位置(例如S2 = S1 + 10)。一個更簡潔的方法可能是直接表達一個Actor相對於另一個Actor的位置。

...
- vehicle: V2
    position:
      reference: V1
      station: +10
    actions:
    - drive:
        road: R1
        speed: 20

這基本上表明,無論V1的位置如何,V2都應該位於V1前方10個單位(米)處,沿着相同的道路元素。

現在,讓我們考慮一個常見的"切入"場景,其中一輛車在另一輛車前面改變車道。 在這裏插入圖片描述

我們需要捕獲的兩輛車之間存在明顯的空間關係,例如,我們可以引入橫向偏移(l座標)來測量一輛車與另一輛車的距離。但在這種情況下,對車輛最初行駛的兩條車道之間的拓撲關係進行編碼可能更有意義。假設我們將這些車道稱爲R1_1和R1_2。這將使場景更容易推廣到不同的情況,例如,彎曲的道路或更寬/更窄的車道。

拓撲關係允許我們利用道路結構,並推廣到具有不同空間幾何形狀的不同情況。

使用圖表來指定此道路結構似乎是一個自然的選擇。 在這裏插入圖片描述

我們可以將此圖表示爲地圖部分中節點和邊的集合。符號"X =type=> Y"只是語法糖,用於表示具有特定類型標籤的邊。此時,我們還應該從更通用的"drive"操作到"lane_follow"進行細微更改(然後是V2的"lane_change")。

environment:
- weather: sunny
map:
- nodes:
  - road: R1
  - lane: R1_1
  - lane: R1_2
- edges:
  - R1 =contains=> R1_1
  - R1 =contains=> R1_2
  - R1_1 =left=> R1_2
  - R1_2 =right=> R1_1
actors:
- vehicle: V1
    position:
      reference: R1_2
      station: S1
    actions:
    - lane_follow:
        reference: R1_2
        speed: 20
- vehicle: V2
    position:
      reference: R1_1
      station: S2
    actions:
    - lane_follow:
        reference: R1_1
        speed: 25
    - lane_change:
        target: R1_2
        station: S3

和以前一樣,S3可以重寫爲"S1 +一些常量",或者可以相對於V1創建lane_change的目標(這將確保V2嘗試在V1之前切入)。請注意,在這種情況下,V2 的初始車道跟隨速度故意保持在略高於 V1 (20) 的 (25)。我們也可以把它變成一個相對數量。

最後,讓我們考慮一個更復雜的場景,其中兩輛車正在接近由停車標誌控制的十字路口,並且需要相互協商才能安全通過。車輛V1試圖左轉,而V2則沿着直行。哦,現在天氣開始轉多雲了!

在這裏插入圖片描述

在這種情況下,相關的地圖元素包括交匯點 (J1) 和停車標誌 (SS1、SS2)。我們還引入了一個道路"路段"作爲車道元素的中間容器,例如,道路R1由3個路段(R1_1,R1_2和R1_3)組成,每個路段包含一個車道元素或"lanelet"(R1_1_1,R1_2_1,R1_3_1)。這些元素之間的聯繫可能很多,在手工構建這樣的網絡時很容易出錯(部分在下面指定)。幸運的是,這種分層結構是從已建立的路線圖表示格式(如OpenDRIVE和Lanelet2)改編而來的,可以從更簡單的表示中推斷出來,也可以直接從現有映射中提取。

environment:
- weather: cloudy
actors:
- vehicle: V1
    position:
      reference: R1_1_1
      station: S1
    actions:
    - lane_follow:
        reference: R1_1_1
        speed: 15
    - turn_left:
        junction: J1
        exit: R2_3_1
- vehicle: V2
    position:
      reference: R2_1_1
      station: S2
    actions:
    - lane_follow:
        reference: R2_1_1
        speed: 15
    - go_straight:
        junction: J1
        exit: R2_3_1
map:
- nodes:
  - road: R1
  - section: R1_1
  - ...
  - lanelet: R1_1_1
  - ...
  - road: R2
  - section: R2_1
  - ...
  - lanelet: R2_1_1
  - ...
  - junction: J1
  - stop_sign: SS1
  - stop_sign: SS2
- edges:
  - R1 =contains=> R1_1
  - ...
  - R2 =contains=> R2_1
  - ...
  - R1 =crosses=> R2
  - R1_1 =enters=> J1
  - ...
  - R1_3 =exits=> J1
  - ...
  - SS1 =controls=> R1_1_1
  - SS2 =controls=> R2_1_1

可以想象,此方案的不同實例化可能會產生完全不同的結果,特別是基於每個參與者的起始位置、其接近速度、主動性等。所有這些都是可以進一步豐富方案描述的參數。

3、事件的時間順序

現在考慮一下 - 如果你想捕捉特定的事件順序,例如,當等待的行人(P1)決定開始行走時,車輛(V1)即將到達人行橫道(CW1), 該怎麼辦?

在這裏插入圖片描述

請注意,這與車輛已經通過人行橫道,然後行人開始行走的情況不同。

在這裏插入圖片描述

有幾種方法可以表達這種時間關係,例如在行人行動之前使用等待條件,或者基於與車輛的距離。這在模擬中執行場景時很有用,但在其他用例中卻沒有實際幫助,例如從真實世界數據中提取場景。因此,我們採用了一種基於艾倫區間代數的更通用的方法,該方法以與我們可能考慮任何一維域的跨度相同的方式表達事件之間的時間關係。

在當前場景中,我們首先將場景中每個可識別的情況標記爲"事件",時間具有定義其間隔的開始和結束時間(假設瞬時事件具有相同的開始和結束時間)。這包括車輛的lane_follow動作,行人的步行動作以及車輛通過人行橫道(這本身不一定是動作,但仍然是可觀察的事件)。

在這裏插入圖片描述

時態關係可以用作查找匹配方案時的約束,也可以在模擬方案時用作執行計劃中的操作。

每個事件也可能具有一些關聯的元數據,例如與事件最相關的地圖元素的標識符(R1、CW1 等)。地圖元素可用於分組兩個事件,例如,在本例中,我們想說車輛中的人行橫道和行人事件是相同的,因此我們使用相同的標識符(CW1)對其進行尋址。

然後,我們可以指定所需的時間關係作爲條件:

...
actors:
- vehicle: V1
    position:
      reference: R1
      station: S1
    actions:
    - lane_follow:
        id: E1
        reference: R1
        speed: 20
- pedestrian: P1
    position:
      reference: CW1
      station: S2
    actions:
    - walk:
        id: E2
        reference: CW1
        speed: 2
events:
- crosswalk:
    id: E3
    actor: V1
    reference: CW1
conditions:
- E2 =before=> E3
- E3 =during=> E1

請注意,在上述條件下,"Y之前的X"被解釋爲X必須在Y開始之前開始;我們故意允許事件之間的一些重疊(例如,車輛可能會在安全的情況下開始過馬路,甚至在行人完全離開人行橫道之前)。

4、Ridecell場景語言 (RSL)

讓我們回顧一下迄今所討論的內容。我們首先確定了駕駛場景的不同組成部分,例如地圖元素、環境因素、參與者及其操作。這些組件可以寫在方案的結構化描述的單獨部分中。然後,我們繼續開發表示形式,以捕獲這些組件之間的不同類型的關係:

  • 空間關係對不同組件彼此之間的位置進行編碼,通常使用數值距離值。
  • 拓撲關係有助於捕獲元素之間的邏輯關係,尤其是地圖元素,例如相鄰車道。
  • 時態關係指定具有方案特徵的事件的順序。

這是我們表達駕駛場景所需的詞彙,也是Ridecell場景語言(RSL)的基礎。我們在團隊中使用RSL進行場景建模,迭代語言規範本身,並圍繞它構建工具和庫,以支持我們已經確定的一些關鍵功能,包括地圖相對座標,參數分佈和actor行爲樹。在即將發表的文章中,我們將分享有關 RSL 格式及其可以啓用的特定用例的更多詳細信息。

RSL使用地圖相對座標、參數分佈和參與者行爲樹爲場景建模提供豐富的詞彙表。

熟悉其他場景描述格式的人可能已經認識到,這在結構上並沒有太大的不同,但包括某些關鍵元素,使其更加靈活和可擴展。這是有意爲之,因爲我們希望保留根據需要輕鬆轉換爲其他格式的能力,以便與具有特定依賴關係的系統進行交互。例如,我們可以將具體的RSL場景導出到OpenSCENARIO v1.0中,許多現有的模擬器都使用該場景。事實上,我們還選擇 YAML 作爲通用文件格式來寫出 RSL 模板,而不是特定於域的語言,這樣就不會有解析或解釋的障礙。

5、場景覆蓋範圍

RSL的一個應用是作爲一個模板,我們可以根據該模板比較現實世界的駕駛路段,並找到匹配的場景。匹配方案實質上爲模板中指定的所有變量提供特定值,同時具有兼容的結構。使用此類模板庫,你可以開始捕獲整個操作域。下一個合乎邏輯的問題是,如何量化場景覆蓋範圍?也就是說,你觀察真實數據中各種場景的頻率。一種顯而易見的方法是計算每個單獨方案模板的出現次數。但這很容易變得無法控制,因爲根據需要考慮的不同因素及其組合,可能的場景總數可能會爆炸式增長。

根據不同的情景因素來表達情景覆蓋率,使我們能夠分析不同的切片和維度,而不會被從測試或生產車輛收集的大量數據所淹沒。

相反,我們建議根據因素本身量化場景覆蓋範圍,以便你可以在有意義的結構中組織它們的組合,並研究與你相關的任何"切片"。例如,要考慮的兩個重要方案因素是地圖元素和對象。地圖元素包括車道、交叉路口、人行橫道、停車標誌等。對象可以根據感知系統的能力進行分類,例如車輛,自行車,行人等。如果我們專注於場景空間的這兩個因素或"維度",我們可以使用二維直方圖或"熱圖"來可視化場景覆蓋範圍。每個單元格的顏色表示該特定組合的計數或出現頻率,邊距爲你提供每個維度的分佈。 在這裏插入圖片描述

能夠隨着時間的推移監控這些分佈可以帶來許多好處。如果你正在從測試隊列中收集數據,它們可以通知你覆蓋範圍中的差距,並幫助指導數據收集工作更有意義。如果要構建碰撞或接近碰撞駕駛事件的模型,則這些分佈可以用作場景發生的先驗概率。這種基於場景的方法還可以幫助決定自動駕駛中的哪些問題應該集中精力,以產生最大的影響。

6、指標和連續分佈

除了場景發生之外,場景的相同結構分解還可以幫助你通過不同的視角查看系統中的指標。與場景中其他參與者的最小距離是需要密切關注的重要指標。在這裏,我們可視化了相對於演員類型的最小距離(以米爲單位)以及自我車輛的動態狀態。任何意外情況,例如在硬加速/減速階段與行人和自行車的最小距離較低,都可以進一步檢查,並改進相應的運動控制算法/參數以避免這種情況。 在這裏插入圖片描述

當我們考慮場景的分佈和可變性時,除了離散分類之外,我們還必須考慮這種連續變量。速度就是這樣一個變量,可以顯著改變場景的性質或結果。讓我們以切入場景爲例,從現實世界的駕駛日誌中找到此模板的所有示例,並在發生切入時測量我們自我車輛的平均速度。

如果從這些場景中收集所有相對速度樣本,那麼我們可以得出一個反映真實世界觀察結果的分佈。例如,從自己的測試車輛中,我們觀察到它具有大致正態或高斯分佈,平均值爲11.2 m / s(大約25 mph),標準偏差爲3.8。這樣的分佈可以很容易地用RSL編碼。

...
actors:
- vehicle: ego
    position:
      reference: R1_2
      station: S1
    actions:
    - lane_follow:
        reference: R1_2
        speed: Gaussian(11.2, 3.8)
...

在這裏插入圖片描述

這在提取場景時沒有太大影響(儘管你可以提出一個似然值來量化觀測值與分佈的匹配程度),但在生成同一場景的不同變體時,它起着重要作用。它構成了推導Actor行爲的真實模型的基礎。例如,下面是從分佈生成的具體方案:

...
actors:
- vehicle: ego
    position:
      reference: R1_2
      station: S1
    actions:
    - lane_follow:
        reference: R1_2
        speed: 8.6
...

從此類分佈中抽樣,並在仿真中播放這些結果場景,使你能夠更可靠地測試系統的性能。同時,它避免了產生不太可能基於觀測數據或完全難以置信的變化。還可以反轉此採樣分佈,以生成更多罕見場景的實例(仍以實際數據爲基礎)。如果你正在訓練使用機器學習的系統,這尤其有用,因爲它們因過度擬合最常見的情況而聲譽不佳。

從真實世界數據計算的連續分佈有助於建立逼真的Actor模型,找到罕見的場景,利用重要性採樣並防止過度擬合。

總之,我們在本文中開發的是用於驅動場景的抽象表示形式,以及一組可用於從中獲取價值的流程。這種基於場景的數據收集、訓練、測試和驗證方法可以幫助組織和分解自動駕駛系統的開發,否則這將是一項艱鉅的任務。目前正在開發的Nemo,將實施這些想法並解決不同的工作流程。

這種方法的應用也擴展到其他領域,例如汽車保險的風險建模,車隊監控和優化,異常事件檢測等。我們期待在即將發表的文章中更詳細地解釋它們,並與我們的行業合作伙伴一起深入研究。


原文鏈接:自動駕駛場景剖析 — BimAnt

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章