Apollo如何規劃模塊

本篇內容介紹了“Apollo如何規劃模塊”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

簡介

在包括Apollo 3.0在內的前序版本中，都使用相同的配置和參數對不同的駕駛場景進行規劃。這種方法雖然是線性的且易于實現, 但并不靈活或者沒有面向特定的場景優化。隨著Apollo系統的成熟，在不同的路況和駕駛用例中使用，開發更加模塊化、場景指定和全局的方法更有必要。在該方法中，每個駕駛用例都被視為不同駕駛場景。這種設計方法是很有用的，因為在當前這種方式下，修復一個特定場景下的問題不會像以前版本中出現的影響那樣，來影響其他場景的情況。在以前版本中，所有的駕駛用例都被認為是一個駕駛場景，導致一個問題的修復會影響其他的駕駛用例。

駕駛場景

在Apollo 3.5中，我們將聚焦以下三種主要駕駛場景：

如下圖所示，車道跟隨場景是默認駕駛場景，包括但不限于在單一車道駕駛（例如巡航）或者變道，遵循基本的交通規則或簡單的轉彎。

▲車道跟隨場景—默認駕駛場景

在這種場景中，如果在當前車輛行駛車道上有靜止車輛或者障礙物，而且在不發生碰撞的情況下，車輛無法安全地通過當前車道，規劃模塊將執行以下步驟：

•  檢查鄰近車道是否有靠近的車輛。

•  如果安全，做一個側轉動作，從當前車道轉到旁邊車道。

• 一旦安全通過障礙物，迅速回到原來車道。

▲側方行駛

停車標志

對于停車標志，有兩種不同的駕駛場景：

不受保護的：在這種情況下， 汽車希望通過一個具有兩路停車標志的十字路口，如下圖所示。因此，自動駕駛系統必須駕駛車輛緩慢地通過十字路口，并且在繼續行駛之前測量十字路口的車流量。

▲無保護駕駛場景

受保護的：在這種情況下，汽車希望通過一個具有四路停車標志的十字路口，如下所示。因此， 在繼續行駛之前，我們的自動駕駛系統必須衡量本車到停車標志之間的車流量，并且理解車輛在隊列中的位置。

▲受保護駕駛場景

為了安全通過停車標志區域，受保護和無保護兩種場景都將執行以下步驟：

• 即將到達停車標志點：感知當前正在等待其他停車標志的所有車輛或者障礙物。

• 完全停車：監測并查看先前停留在其他停車標志車道的車輛是否已經開始移動。保證之前到達的車輛都已經離開是十分重要的。

• 緩慢向前移動（爬行）：檢查看是否有其他車輛正在移動或者處于非保護場景下的停車狀態，檢查當前車道的旁邊車道是否有迎面駛來的車輛。

• 安全通過十字路口。

注意：研發團隊正努力工作，以在規劃模塊中增加其他駕駛場景的規劃方案，其中一個案例就是處理交通燈。

Apollo 3.5中規劃模塊的體系結構已經有所改變，該架構能夠反映針對不同駕駛場景的模塊化設計方法。如下圖所示， 在規劃器中, 每一個獨立的駕駛場景都和對應的場景處理器一一對應。每個駕駛場景都有其一組特定于該場景的駕駛參數，使其更安全、高效、更易于自定義和調試以及更靈活。因為每個階段都被劃分為多個任務，使得每個階段也是可配置的，并且可以通過編輯該場景的配置文件config來刪除或創建每個任務。

▲ Apollo 3.5 中規劃模塊的體系結構圖

一些關鍵特性：

• Apollo FSM（Apollo有限狀態機）：它是一個根據車輛的當前位置、路由方案和高精地圖，來決定車輛狀態的有限狀態機。

• 規劃分發器：根據車輛的當前狀態和一些其他相關信息調用合適的規劃器 。

• 規劃器： 獲取所需的上下文數據和其他信息， 確定車輛的意圖，執行該意圖所需的規劃任務，并生成規劃軌跡。它還將更新上下文以服務于未來的任務。

• 決策者和優化器：一組實現決策任務和各種優化的無狀態庫。優化器專門優化車輛的軌跡和速度。決策者是基于規則的決定制造者， 給出何時更換車道、何時停止、緩慢行駛或蠕變何時完成的建議。

• 黃色框：這些框主要是為未來的駕駛場景和開發者基于現實世界的駕駛用例貢獻自己的駕駛場景預留的。

“Apollo如何規劃模塊”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！