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

本文來源：智車科技

／ 導(dǎo)讀 ／

本篇文章想和大家分享一下Apollo7．0最新的規(guī)劃算法。由于Apollo的planning整體代碼都相當(dāng)龐大，一開始還是理清其框架，再分算法塊逐個(gè)擊破這樣效果更好。

這篇文章希望能帶領(lǐng)讀者理清planning的整體框架，梳理數(shù)據(jù)流，以主要場景為例，一直分析到task （apollo planning 的主要算法所在處）邏輯前的準(zhǔn)備工作、輸入如何構(gòu)造的，之后再深入看task內(nèi)部的細(xì)節(jié)也更容易理解。

特別注意，本文中的流程圖均為作者花費(fèi)了大量時(shí)間梳理而來，以便讀者能夠更易理解planning的整體框架，抓住重點(diǎn)不被細(xì)節(jié)帶跑偏。

1

planning 的輸入輸出

讀懂一個(gè)模塊，首先必然是了解其的上下游，即輸入輸出是什么。熟悉Apollo CyberRT框架的小伙伴都知道在該框架下，輸入輸出由Reader和Writer構(gòu)成，并定義在每個(gè)模塊的component文件中。除此之外，CyberRT框架定義了兩種模式，分別為消息觸發(fā)和時(shí)間觸發(fā)，而planning中采用的為消息觸發(fā)，因此必須接到特定的上游消息后，才會(huì)進(jìn)入內(nèi)部主邏輯，而消息觸發(fā)的上游消息，定義為component中Process（）函數(shù)的入?yún)ⅰ?/p>

因此總結(jié)來看，planning的上下游關(guān)系總結(jié)為下圖：

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

2

planning 整體框架

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