Apollo相對地圖在自動駕駛中的使用及實際應(yīng)用

上周，來自百度資深軟件工程師—Yifei Jiang，在Apollo開發(fā)者社群內(nèi)分享了有關(guān)Apollo相對地圖的內(nèi)容，通過基于人工駕駛路徑的實時地圖生成方案，和相對地圖模塊特點及應(yīng)用等技術(shù)內(nèi)容，進一步剖析了Apollo相對地圖，讓開發(fā)者了解相對地圖在自動駕駛中的使用及實際應(yīng)用。

錯過社群直播的開發(fā)者可以從以下資料回顧干貨內(nèi)容：

Apollo相對地圖

基于人工駕駛路徑的實時地圖生成

百度資深軟件工程師Yifei Jiang

相對地圖是在Apollo 2.5的時候第一次對外開放。在3.0的時候我們和長沙智能駕駛研究院一起合作研發(fā)，對相對地圖進行了功能和架構(gòu)上的升級。今天我會給大家介紹什么是相對地圖，為什么我們要做相對地圖，以及相對地圖是如何設(shè)計和實現(xiàn)的。

本次分享將會從以下四個方面展開：

一、相對地圖的功能及特點

二、指引者的設(shè)計思想及在相對地圖中的作用

三、相對地圖在自動駕駛中的使用

四、相對地圖和指引者的設(shè)計細節(jié)及特點總結(jié)

在公眾號內(nèi)回復(fù)“ PPT0731 ”獲取完整PPT

1相對地圖的功能及特點

這是Apollo一個簡單框架圖，在這張圖的底部是規(guī)劃和控制模塊，負責車輛行駛軌跡的規(guī)劃和執(zhí)行。這個模塊依賴兩個重要的上游模塊高清地圖和感知。

感知模塊主要提供了動態(tài)障礙物的信息，比如車輛，行人及其他障礙物。由于感知模塊加入了視覺感知的能力，該模塊也能夠提供部分實時地圖信息，比如車輛的當前車道線，斑馬線，和紅綠燈停止線。這類信息通過實時計算得到，成本低，但是依賴于路面狀況及標識清晰度。

和實時地圖相對應(yīng)的是高清地圖模塊提供的靜態(tài)地圖信息。相比實時地圖信息，靜態(tài)地圖信息是在線下提前收集和處理，這個信息由于是在線下制作，準確度高，信息種類更加豐富細致，而且不依賴于路面狀況，但是制作周期長，成本高。

為了將有不同特點和格式的實時地圖信息和靜態(tài)地圖信息更好的結(jié)合在一起，同時也為了給規(guī)劃和控制模塊提供統(tǒng)一的接口。我們設(shè)計和開發(fā)了相對地圖模塊。

相對地圖有如下兩個特點：

首先，產(chǎn)生的地圖數(shù)據(jù)是相對于車的車身坐標系，這也是為什么該模塊被命名為相對地圖；在車身坐標系下，車輛坐標永遠在原點，車頭方向永遠為0。

其次，地圖數(shù)據(jù)會根據(jù)車的位置和朝向的變化實時更新，更新頻率是10Hz。

相對地圖采用車身坐標系，而不是全局坐標系，有兩個原因：

第一，感知模塊的原始數(shù)據(jù)輸出是基于車身坐標系。采用車身坐標系，我們就不需要把感知的輸出再轉(zhuǎn)化成全局坐標系。這樣減少了轉(zhuǎn)化帶來的誤差，也減少了轉(zhuǎn)化的計算量。

第二，在相對地圖的一些模式下，只能使用車身坐標系，比如在定位不存在或者不準確的時候。為了使相對地圖能夠在所有模式下進行無縫實時切換，我們統(tǒng)一了坐標系到車身坐標系。同時規(guī)劃和控制模塊也能夠無感的處理不同的輸入和場景。

不管是基于實時地圖信息還是靜態(tài)地圖信息，相對地圖對規(guī)劃和控制模塊提供了接口統(tǒng)一的地圖數(shù)據(jù)。這些地圖數(shù)據(jù)約束和限制著規(guī)劃和控制模塊產(chǎn)生的軌跡和速度。比如，數(shù)據(jù)中的車道線限制規(guī)劃路徑要在左右車道線之間。再比如地圖中的紅綠燈停止線限制車輛在紅燈時不能超過停止線。

這種約束性的地圖信息，使得規(guī)劃和控制模塊能夠進行嚴謹而且精確的數(shù)學建型，然后進行數(shù)學優(yōu)化，得到最優(yōu)的規(guī)劃結(jié)果。但同時也帶來了一系列的問題。

第一，約束信息必須準確而且完整。因為缺失任何一個約束條件都會導致錯誤的規(guī)劃。這樣的要求會增加地圖的成本。

第二，每一個約束條件需要標注各種交規(guī)相關(guān)的屬性，比如，一個車道線，可能是白虛線，也可能是黃實線。不同的交規(guī)屬性會影響規(guī)劃和控制的輸出。另外每一種約束也可能會有它的物理屬性，比如一個路的邊界可能是一個馬路牙子，也可能是一道鐵柵欄，甚至是一個懸崖。這種物理屬性，也會影響規(guī)劃和控制的輸出。這些標注會增加地圖制作標注的復(fù)雜性。

第三，現(xiàn)實世界中，不是每一個約束都明顯的存在。比如在路口里面或者老舊的路面，車道線并沒有標示出來。因為約束的完整性要求，我們必須要填補這些缺失，而且在填補時，需要考慮規(guī)劃和控制的特性。這樣就增加了地圖制作的難度，也不能和規(guī)劃控制進行很好的解偶。

2指引者的設(shè)計思想及在相對地圖中的作用

因為約束性地圖信息帶來的上述問題，我們在設(shè)計相對地圖的時候一直在考慮，除了對規(guī)劃控制提供限制和約束，告訴規(guī)劃控制不可以做什么，我們能不能告訴規(guī)劃和控制模塊可以做什么，對規(guī)劃和控制模塊提出引導——這就是我們提出的引導性的地圖信息。

如上圖所示的一個形象的比喻，約束性地圖信息是就像在地面上擺交通錐，引導性的地圖信息就像為規(guī)劃和控制模塊建一個虛擬的鐵軌。

引導性信息有如下優(yōu)點：

第一，簡化信息量，降低信息成本。因為能做的什么可能性就只有一個或者幾個，遠遠小于不能做什么的信息量。

第二，對約束的依賴很低，不需要收集和標注約束信息。因為引導的信息，已經(jīng)考慮到了各種限制的影響。

第三，限制性的地圖信息，只對安全進行了限制，舒適性是由規(guī)劃和控制在安全的基礎(chǔ)上進行優(yōu)化。但是引導信息不僅有安全性上的引導，而且有舒適性的引導。

具體到Apollo，引導性地圖信息就是我們引入了的指引線概念。指引線是基于線下收集的人工駕駛路徑生成的虛擬“軌道”， 如上圖的綠色線段所示。

指引線有如下優(yōu)點：

首先，因為路徑是由人工駕駛產(chǎn)生的，兼顧了安全和舒適性。

其次，指引線的成本低。從人工駕駛路徑到指引線的生成，是一個全自動的過程，不需要任何的人工標注。

另外，整個指引線生成過程，是線下完成的。我們在同一路段，可以結(jié)合不同的人，不同場景下收集多段路徑，使得最終的指引線更加優(yōu)化，減少偏差。

最后，我們可以為不同的車型，產(chǎn)生不同的指引線。比如說，大卡車和小轎車，尤其在拐彎的時候，路徑有很大的區(qū)別。這種區(qū)別就可以體現(xiàn)在不同的指引線上，同時降低我們對車輛模型的依賴。

為了在Apollo系統(tǒng)中引入指引線，我們加入了一個新的模塊，叫指引者。指引者連接者高清地圖和相對地圖，為相對地圖提供引導信息。 它即可以單獨使用也可以和高清地圖配合使用。這樣相對地圖為規(guī)劃和控制不僅可以提供約束，也提供了引導。

根據(jù)約束和引導的重要性的不同，相對地圖提供了兩大模式：模式1和模式2。

模式1是以約束為主：在這種模式下，相對地圖接入了指引線和高清地圖數(shù)據(jù)，為規(guī)劃和控制提供了引導和完整的約束。 這樣的模式適用于復(fù)雜駕駛場景，比如城市道路。

模式2是以引導為主：這種模式下，相對地圖不依賴高清地圖，只接入實時地圖信息和指引線，為規(guī)劃和控制提供了引導和基本約束。這種模式適用簡單駕駛場景。比如高速或者鄉(xiāng)村道路。由于不依賴高清地圖，這種模式下，開發(fā)者可以快速和低成本的部署Apollo進行真實道路測試和運營。

3相對地圖在自動駕駛中的使用

下面，我們用一個例子來說明相對地圖是如何應(yīng)用到實際的路測中。在這個例子中我們將聚焦在模式2，即以引導為主，約束信息是來自感知的實時地圖信息。

上圖是我們在地圖上截取的一個路段。我們假設(shè)要在該路段部署自動駕駛。

在部署之前，我們首先要做的是收集人工駕駛軌跡。如上圖所示，紅色的軌跡是我們收集的軌跡數(shù)據(jù)，這個數(shù)據(jù)覆蓋了幾乎所有的車道及行車可能。

在實際操作中，可只收集用于無人駕駛的車道。這個收集過程可以由專業(yè)的司機專門來收集，駕駛過程中盡量避免換道，一個車道行駛一遍即可。

此外，這個過程也可以由普通用戶眾包完成，這種情況下，由于數(shù)據(jù)收集中可能存在噪音以及不可控的換道，每個車道需要收集多次行駛路徑。另外眾包的車型也要保證相似。

人工駕駛軌跡收集完成后會被自動轉(zhuǎn)化成指引線。這個過程是一個全自動的過程，無需任何人工標注。有噪音的數(shù)據(jù)，以及過于頻繁換道的數(shù)據(jù)在這個過程中也會被濾掉。

如上圖所示，最終生成的指引線（綠色）以車道為單位，也包含了車道之間的連接，比如掉頭和左右拐彎。以上就是我們部署自動駕駛前的準備工作。

有了指引線之后，我們就可以在該區(qū)域開始自動駕駛了。我們假設(shè)，車在A點，想要自動駕駛到B點。我們首先向普通導航地圖，比如百度地圖，請求道路級別的routing。

如上圖所示，道路中間的藍色線段，就是我們得到的從A點到B點的道路級別routing。

然后我們拿道路級別的routing去和之前生成的指引線進行匹配，得到A點到B點之間的指引線。

如上圖所示，我們拿到了三條橘黃色的指引線。給出三條指引線是為了給下游的規(guī)劃和控制模塊更多的靈活性。

比如，當A點和B點之間有障礙物時，無人車可以切換到相鄰車道繞過障礙物，再切換到和B點相連的車道。為了使規(guī)劃和控制模塊更好的執(zhí)行換道的策略，我們?yōu)槊恳粭l指引線設(shè)置了不同的優(yōu)先級，橫向越接近終點的指引線優(yōu)先級越高。

無人車在進行無人駕駛的時候，相對地圖模塊根據(jù)指引線和實時車道線實時生成地圖，并以10Hz的頻率進行更新。

在這個過程中，指引線被轉(zhuǎn)化為車身坐標系，并作為車道中心線；從感知模塊的到的車道線作為車道的左右邊界；以上信息被融合在一起產(chǎn)生相對地圖。

在無人駕駛過程中，相對地圖會有兩種特殊情況。

第一種情況是由于定位不準，指引線暫時不可用。在這種情況下，相對地圖只根據(jù)感知的實時車道線來生成地圖信息，無人車可以繼續(xù)進行L3級別的無人駕駛，屬于車道保持或者自適應(yīng)續(xù)航控制狀態(tài)。

這種情況適用于短暫的定位不準確，比如過隧道或者橋洞，一旦定位恢復(fù)，相對地圖會自動切換回正常的指引線+實時車道線模式。

第二種特殊情況是感知無法檢測到車道線，如上圖所示，車輛行駛在路口（或者老舊路面），沒有車道線。這時相對地圖的生成只根據(jù)指引線，車道邊界會根據(jù)歷史數(shù)據(jù)進行預(yù)測，或者根據(jù)左右側(cè)指引線進行估算。

從上面的例子，大家可以看出指引線在自動駕駛中起著多種不同的作用：

首先，指引線連提供了車道級別的導航，它接著出發(fā)點和目的地，保證無人車能夠達到終點。

第二，指引線會被規(guī)劃模塊用作路徑規(guī)劃的參考線，為路徑規(guī)劃提供安全性和舒適性的引導。

第三，指引線是高清地圖的載體。在進行自動駕駛時，我們無需加載整張高清地圖，而是沿著指引線，加載指引線周邊的高清地圖數(shù)據(jù)。

最后，指引線還是生成相對地圖的重要數(shù)據(jù)之一。

4相對地圖和指引者的設(shè)計細節(jié)及特點總結(jié)

下面，我們來看一下生成指引線的模塊，指引者，是如何設(shè)計和實現(xiàn)的。

指引者是一個云端服務(wù)，如上圖的中間部分所示，指引者有兩個數(shù)據(jù)庫，一個存放指引線數(shù)據(jù)，另外一個存放高清地圖數(shù)據(jù)。除此之外，還有一系列的數(shù)據(jù)處理及算法功能模塊。為了使指引者能夠提供指引線，我們首先要把線下采集的人工駕駛路徑數(shù)據(jù)上傳到云端（如圖中步驟1所示）。

指引者會對數(shù)據(jù)進行一系列的處理，最終生成指引線并存儲在數(shù)據(jù)庫中。之后，用戶會在Dreamview中選擇目的地發(fā)出導航請求（如圖所示步驟2）。

指引者中的導航請求處理器會接受導航請求并轉(zhuǎn)發(fā)給百度地圖API（圖中步驟3），并從百度地圖API得到道路級別的導航（步驟4）。

導航處理器會根據(jù)道路級別的導航進行指引線匹配（步驟5）得到指引線。

如果有相應(yīng)的高清地圖數(shù)據(jù)存在，指引線會和周邊的高清地圖進行關(guān)聯(lián)（步驟6）。

最終，指引線會傳回給Dreamview（步驟7）。

Dreamview得到指引線數(shù)據(jù)后發(fā)送給下游模塊，比如預(yù)測模塊和規(guī)劃模塊。

除了云端服務(wù)，我們也提供了一個離線指引者的工具，供開發(fā)者在沒有網(wǎng)絡(luò)的情況下，或者在私人封閉測試場中使用指引線和相對地圖。這個工具可以把收集到的人工駕駛數(shù)據(jù)進行一系列的處理包括：路徑抽取，路徑平滑，和指引線產(chǎn)生。

最終把生成的指引線數(shù)據(jù)發(fā)送到 ROS topic “/apollo/navigation”。 這樣相對地圖就可以收到指引線，并產(chǎn)生相對地圖。 關(guān)于離線指引者的具體使用發(fā)法，大家可以參照我們Github上的文檔，鏈接列在了上圖中。

這個文檔是我們的外部開發(fā)者根據(jù)他們的實踐經(jīng)驗總結(jié)的，寫的非常詳細。

在上面的使用相對地圖的例子中，我們多次提到百度地圖API。下面為大家總結(jié)一下，相對地圖是如何利用和集成百度地圖API，以及這樣的設(shè)計帶來的好處。

首先，我們利用百度地圖為用戶提供發(fā)送導航請求的界面。如上圖所示，用戶可以在地圖界面中選擇一個目的地，然后點擊左上角的紅色Route按鈕。這樣的一個體驗就像用戶在手機上使用百度地圖導航一樣。

其次，在無人駕駛過程中，我們會把無人車的位置實時顯示在地圖上，為乘客提供當前位置的信息。如上圖所示，百度地圖中間的紅色位置圖標就是無人車的當前位置。

最后，也是最重要的，我們利用百度地圖的導航API為指引者提供了道路級別的導航。這樣的道路級別導航保證了行車線路的準確性，同時也考慮了實時路況，為最終匹配到精確的合理的指引線提供了保障。

上面這張圖總結(jié)相對圖和指引者和Apollo中各個模塊之間的關(guān)系。這張圖的中間是相對地圖模塊，它依賴于感知，定位和指引線。指引線可以由云端指引線產(chǎn)生，也可以由離線的指引者工具產(chǎn)生。相對地圖會融合各種地圖信息，根據(jù)路況條件和輸入數(shù)據(jù)，工作在不同的模式下。生成的相對地圖數(shù)據(jù)，會傳給預(yù)測和規(guī)劃模塊。云端指引線連接著高清地圖和百度地圖API。

最后，總結(jié)一下相對地圖的三種工作模式：

圖中的模式1和模式2就是之前提到的指引線+高清地圖方案和指引線+基于感知的實時地圖信息方案。模式0是模式2的一種特例，只依賴于基于感知的實時地圖信息。

首先對于適用場景，模式0由于沒有指引線，適用于短時間的車道保持和巡航。模式1由于有高清地圖信息，適用于復(fù)雜的駕駛場景，比如城市道路。模式2由于只有一些基本的實時地圖信息，適用于簡單駕駛場景，比如高速或者鄉(xiāng)村道路。

對于自動駕駛級別，模式0屬于L3級別，模式1屬于L4級別。模式2由于有限的地圖信息，屬于前兩種模式之間。

關(guān)于部署成本，由于模式0只依賴于感知算法，沒有線下數(shù)據(jù)收集的需求，部署成本幾乎為零。模式1由于依賴高清地圖，部署成本高。模式2雖然依賴指引線，但指引線的制作成本低，總體部署成本也偏低。

關(guān)于對定位的依賴：由于模式0只使用感知數(shù)據(jù)，可以完全不依賴定位。模式1和模式2使用指引線或者高清地圖，所以對定位有強依賴。

最后，關(guān)于對道路標示的要求，即路面交通線的清晰程度：由于模式0是基于視覺對車道線進行識別，對標示清晰度要求高。其他兩種模式由于有了指引線或者高清地圖作為參考，對道路標示要求低。

以上就是對于相對地圖的介紹和分享。非常感謝大家的參加！更多Apollo相關(guān)的技術(shù)干貨也可以繼續(xù)關(guān)注后續(xù)的社群分享。

相關(guān)學習資料和自動駕駛相關(guān)技術(shù)內(nèi)容，大家可以關(guān)注【Apollo開發(fā)者社區(qū)】的微信公眾號來獲取，也可以在Apollo GitHub上提出技術(shù)問題與我們互動，歡迎大家溝通交流！

Q&A

問答

1

Q：相對地圖如何擴展成多車道，目前沒有車道線檢測是否也可以實時生成相對地圖，百度地圖的routing API怎么和相對地圖結(jié)合的？

A：需要采集多條指引線，每一個車道一條。沒有車道線檢測，也可以只依賴指引線生成相對地圖。在模擬器里的百度地圖的界面上選擇終點，點擊route就可以。前提是云端要有相應(yīng)路段的指引線。

2

Q：Apollo有一個分支叫mobileeye_radar，為什么已經(jīng)有十個月沒有更新了？請問是遇到了什么問題呢？

A：這個分支已經(jīng)合入了master，所以沒有更新。這個分支里的主要更新可參照

https://github.com/ApolloAuto/apollo/tree/mobileye_radar/modules/third_party_perception

3

Q：Flocalization模塊中用于lidar定位的地圖需要rtk提供的高精pose 和對應(yīng)的lidar數(shù)據(jù)來生成，鑒于rtk成本較高，請問這里能否用其他方式來提供足夠精度的pose？

A：我們也在探索和開發(fā)基于攝像頭/圖像的定位方法，不依賴RTK。

4

Q：使用相對地圖的規(guī)劃和使用高精度地圖的規(guī)劃有什么區(qū)別？使用相對地圖時如何實現(xiàn)變道行駛？

A：規(guī)劃是通用的，沒有區(qū)別。相對地圖支持多車道，可以在規(guī)劃和控制模塊中實現(xiàn)變道行駛。

5

Q：百度API提供的導航地圖、車道線、實時感知的三維場景，這三者的坐標都是經(jīng)過坐標偏轉(zhuǎn)加密的嗎？

A：百度API的數(shù)據(jù)是經(jīng)過坐標偏轉(zhuǎn)加密的。車道線和實時感知的數(shù)據(jù)是基于車身坐標系的。我們在系統(tǒng)中已經(jīng)做了對齊。對開發(fā)者來說是無感的。