日本无码免费高清在线|成人日本在线观看高清|A级片免费视频操逼欧美|全裸美女搞黄色大片网站|免费成人a片视频|久久无码福利成人激情久久|国产视频一二国产在线v|av女主播在线观看|五月激情影音先锋|亚洲一区天堂av

  • 手機站
  • 小程序

    汽車測試網(wǎng)

  • 公眾號

    • 汽車測試網(wǎng)

    • 在線課堂

    • 電車測試

首頁 > 汽車技術 > 正文

百度Apollo7.0 規(guī)劃算法框架解析（干貨）

2022-02-07 15:30:29·  來源：智車科技  作者：Steve  
　
本篇文章想和大家分享一下Apollo7.0最新的規(guī)劃算法。由于Apollo的planning整體代碼都相當龐大，一開始還是理清其框架，再分算法塊逐個擊破這樣效果更好。這篇文
本篇文章想和大家分享一下Apollo7.0最新的規(guī)劃算法。由于Apollo的planning整體代碼都相當龐大，一開始還是理清其框架，再分算法塊逐個擊破這樣效果更好。
這篇文章希望能帶領讀者理清planning的整體框架，梳理數(shù)據(jù)流，以主要場景為例，一直分析到task (apollo planning 的主要算法所在處)邏輯前的準備工作、輸入如何構造的，之后再深入看task內(nèi)部的細節(jié)也更容易理解。
特別注意，本文中的流程圖均為作者花費了大量時間梳理而來，以便讀者能夠更易理解planning的整體框架，抓住重點不被細節(jié)帶跑偏。
planning 的輸入輸出
讀懂一個模塊，首先必然是了解其的上下游，即輸入輸出是什么。熟悉Apollo CyberRT框架的小伙伴都知道在該框架下，輸入輸出由Reader和Writer構成，并定義在每個模塊的component文件中。除此之外，CyberRT框架定義了兩種模式，分別為消息觸發(fā)和時間觸發(fā)，而planning中采用的為消息觸發(fā)，因此必須接到特定的上游消息后，才會進入內(nèi)部主邏輯，而消息觸發(fā)的上游消息，定義為component中Process()函數(shù)的入?yún)ⅰ?

因此總結來看，planning的上下游關系總結為下圖：
這里再重復一下，planning的輸入分為Reader和Process()入?yún)⒌脑蛟谟?，planning依賴于Process()的三個上游輸入，只有同時接到這三個輸入，才會觸發(fā)planning的主邏輯，即是planning正常啟動的必要條件。而Reader則不是，其中部分上游還依賴于配置參數(shù)是否打開，具體可以查看Apollo的源碼。
planning的輸出就比較簡單了，主要是給控制的ADCTrajectory數(shù)據(jù)，包含了一條帶時間、速度的軌跡點集，具體的格式定義可以查看對應的proto文件。
planning 整體框架

上面兩張流程圖是我整理的Apollo規(guī)劃算法的框架，整體框架和之前并無太大變化。主框架分為兩個線程，子線程ReferenceLineProvider以20HZ的頻率運行，用于計算planning中最重要的數(shù)據(jù)結構reference_line；主線程上還是基于場景劃分的思路，多數(shù)場景下還是采用基于ReferenceLine的規(guī)劃算法，對于泊車相關場景，則利用open space算法。目前Apollo的場景劃分為了16種，在proto文件中可以查看到。在Apollo 7.0中，新增了deadend_turnaround場景，用于無人車遇到斷頭路時，采用openspace的方法進行調頭的軌跡規(guī)劃，后續(xù)我會詳細看一下里面的算法實現(xiàn)細節(jié)。

planning中的場景管理
Apollo中的規(guī)劃里的一個重要思想就是基于場景劃分來調用不同的task處理，而其中如何進行場景分配便是實現(xiàn)該思想的核心。從上面的配置參數(shù)可以看到目前Apollo設定了16種場景，而場景下的具體切換邏輯也比較復雜，scenario_manager的具體流程邏輯如下圖所示：
在上圖紅框中的場景判斷中，我只畫了第一步的場景判斷，紅框內(nèi)的5種場景為大類，剩余的場景在這5大類中再細分做出判斷。另外需要注意的是，紅框內(nèi)的5種場景是有優(yōu)先級順序的，即如果判斷為某種場景后，后續(xù)的場景也就不再判斷。下面從這5種場景出發(fā)，介紹一下Apollo中的場景判斷條件，以及每個大類場景下包含哪些細分的場景小類。
1. ParkAndGo
該場景的判斷條件為車輛是否靜止，并且距離終點10m以上，并且當前車輛已經(jīng)off_lane或者不在城市道路上，在該場景下采用的是open_space相關的算法。個人感覺該場景在駛離目標車道并正常規(guī)劃失敗導致的停車時會觸發(fā)，利用open_space方法使其重新回到正常道路上，因此也是場景判斷中首先需要check的。
2. Intersection
在該場景下，又可細分四個場景。首先，根據(jù)先前計算的地圖中第一個遇到的overlap來確定大類型，是包含交通標識的交叉口，還是其他交叉口。其次，若是包含交通標識的交叉口，還細分為stop_sign、traffic_light以及yield_sign，具體結構圖如下所示。
3. PullOver
PullOver場景即靠邊停車，需要滿足以下條件才可切換到該場景：
  • 不在change_line的時候，即reference_line只有一條
  • 當前位置距離終點在一定范圍內(nèi)并且滿足pullover可以執(zhí)行的最短距離
  • 地圖中能夠找到pullover的位置
  • 終點的位置不在交叉路口附近
  • 能查找到最右邊車道的lane_type，并且該車道允許pullover
  • 只有從lane_follow場景下才能切換到pullover
大體邏輯如上述所示，具體的參數(shù)設置可以查看代碼。
4. ValetParking
ValetParking場景即代客泊車，判斷邏輯如下：
  • 從routing中得到target_parking_spot_id
  • 從地圖中搜索是否存在path能夠抵達該parking_spot
  • 查詢當前位置至parking_spot的距離，滿足條件即可切換至該場景
5. DeadEnd
Apollo 7.0中新增的斷頭路場景，增加了"三點掉頭"功能，增加了駛入駛出的能力，擴展了城市路網(wǎng)運營邊界。"三點掉頭"功能基于open space planner框架，包含以下幾個部分：斷頭路場景轉換、開放空間ROI構建、掉頭軌跡規(guī)劃。下列圖片展現(xiàn)了從進入DeadEnd到駛離DeadEnd的整個過程，后續(xù)我也會詳細了解該算法實現(xiàn)邏輯。

上面就是Apollo中的場景切換及管理邏輯。在每個場景scenario下，還分為一個或多個stage，而每個stage下面，又劃分了多個task來完成相應的規(guī)劃任務。以用到最多的lane_follow場景為例，它就包含了一個stage——lane_follow_default_stage，而在這個stage下包含了多個task，如下圖所示：
仔細查看lane_follow場景下的task，我們可以看出Apollo的規(guī)劃思路也是橫縱向解耦，先規(guī)劃path，再規(guī)劃speed。具體的，對于path來說，先做出是否需要lane_change或者lane_borrow的決策，再根據(jù)決策狀態(tài)來生成凸空間，最終基于reference_line及凸空間求解一個二次優(yōu)化問題，從而得到優(yōu)化后的path。對于speed來說，是基于ST圖進行DP+QP的優(yōu)化方法，先利用DP來找到一個cost值最小的可行解，再利用QP對可行解進行平滑，得到最終平滑后的ST圖點集。最終，基于s值對path和speed進行融合，得到一條平滑的軌跡。
總結
至此，Apollo 7.0 planning的核心框架及核心算法的輸入都已經(jīng)解釋清楚了，總體來看Apollo規(guī)劃的整體思路非常清晰，但是細節(jié)部分真的需要花費大量時間來理解，我覺得如果沒能將這套算法部署到實車上跑過的話，很多算法可能真的無法很好地理解。
我個人也陸陸續(xù)續(xù)看這套代碼有兩年多了，始終覺得很多細節(jié)都沒有深入理解透，代碼光看是肯定不行的，如果沒有條件在實車，或者是仿真里實際運行，解決相應場景下遇到的問題的話，是始終不能轉變?yōu)樽约旱闹R的，希望與大家共勉，也歡迎大家有任何疑問在評論區(qū)留言交流。
分享到：
 
反對 0 舉報 0 收藏 0 評論 0
滬ICP備11026917號-25