導(dǎo)讀

4月27日，地平線智能駕駛感知研發(fā)部負(fù)責(zé)人蘇治中就《面向規(guī)?；慨a(chǎn)的自動(dòng)駕駛感知研發(fā)與實(shí)踐》這一主題進(jìn)行了直播講解。

本次課程內(nèi)容分為4個(gè)部分：

1、地平線自動(dòng)駕駛環(huán)境感知量產(chǎn)實(shí)踐2、軟硬協(xié)同的自動(dòng)駕駛感知算法設(shè)計(jì)3、實(shí)現(xiàn)規(guī)?；慨a(chǎn)的“最后一公里”4、感知技術(shù)的發(fā)展趨勢

01 地平線自動(dòng)駕駛環(huán)境感知量產(chǎn)實(shí)踐

圖1 首先，為大家簡單介紹下自動(dòng)駕駛分級，圖1左邊來自于SAE，是大家提到自動(dòng)駕駛分級時(shí)最廣泛看到或最廣泛引用的權(quán)威來源。從定義上來看，L3級以上才算是自動(dòng)駕駛。L3級自動(dòng)駕駛功能里，汽車具備從A點(diǎn)開到B點(diǎn)的能力。L2級的自動(dòng)駕駛汽車僅僅具備縱向或橫向的控制能力，不具備同時(shí)控制的能力，因此無法進(jìn)行變道、超車、上下匝道，所以不能從一個(gè)地點(diǎn)開到另外一個(gè)地點(diǎn)。L4相比于L3，不再需要人去接管。到了L5級，對自動(dòng)駕駛場景的限制就不再有了。
目前，國內(nèi)的量產(chǎn)乘用車還不具備L3級的能力和功能，所以上面剛剛提到研發(fā)的Horizon Matrix Mono和Horizon Matrix Pilot產(chǎn)品，實(shí)際上也是ADAS或輔助駕駛產(chǎn)品。現(xiàn)有的一些車型實(shí)際上已經(jīng)具備了L3能力，稍后講到Pilot時(shí)也會(huì)提到，所謂L3是能夠在限定場景區(qū)域內(nèi)從一個(gè)點(diǎn)開到另外一個(gè)點(diǎn)。

圖2
圖2是地平線Horizon Matrix智能駕駛解決方案的一個(gè)產(chǎn)品矩陣，包括Mono 前視輔助駕駛解決方案、Pilot 領(lǐng)航輔助駕駛解決方案和高級自動(dòng)駕駛解決方案。它們分別是基于征程2，征程3和征程5開發(fā)的。由于今天聚焦于量產(chǎn)實(shí)踐，所以會(huì)講解在征程2和征程3上已經(jīng)量產(chǎn)的Mono 和即將量產(chǎn)的Pilot 。從圖2中可以看到，Mono的研發(fā)時(shí)間是從2018年到2021年，三年磨一劍；Pilot 也是用了近兩年的研發(fā)時(shí)間，而SuperDrive，即更高級別基于征程5的解決方案將會(huì)在明年量產(chǎn)。

圖3
先來看下Mono 的簡介，Mono 是基于征程2或征程3的前視單目ADAS解決方案，征程2有4 TOPS的算力，征程3有5 TOPS的算力，它們分別支持C-NCAP跟E-NCAP的法規(guī)要求。
Mono 產(chǎn)品雖然看似簡單，僅僅是一個(gè)單目前視解決方案，卻是提升用戶駕駛安全性，使得客戶車型能夠滿足NCAP要求的重要產(chǎn)品。NCAP是指New Car Assessment Program，這也是歐洲、日本、北美和中國在法規(guī)層面，汽車進(jìn)入市場之前一個(gè)逐步強(qiáng)制的要求。

圖4

Pilot 是基于3顆征程3，10路攝像頭，支持高速路領(lǐng)航輔助駕駛和停車場記憶泊車的一款L2+產(chǎn)品，也是首個(gè)基于國產(chǎn)AI芯片的行泊一體的平臺。從圖4右下角可以看到Pilot 攝像頭的布局，包括1個(gè)前視的8M相機(jī)，4個(gè)側(cè)視的2M相機(jī)，后視的1顆相機(jī)和4路的環(huán)視魚眼相機(jī)。
一些外部的調(diào)研也發(fā)現(xiàn)，消費(fèi)者認(rèn)為自動(dòng)駕駛目前最需要解決的場景或最有需求的場景，是停車和高速路駕駛，Pilot 3恰好滿足了這個(gè)要求，所以Pilot 3這款產(chǎn)品的功能正在逐步成為智能汽車的一個(gè)標(biāo)配。我們也看到并預(yù)測，未來具備高速路領(lǐng)航輔助駕駛功能車型的量產(chǎn)會(huì)越來越多。
以上是已經(jīng)量產(chǎn)和即將量產(chǎn)的兩款主要產(chǎn)品，接下來會(huì)為大家講解其中的感知算法設(shè)計(jì)，并且是如何結(jié)合征程2和征程3芯片實(shí)現(xiàn)高性能表現(xiàn)。

02 軟硬協(xié)同的自動(dòng)駕駛感知算法設(shè)計(jì)

圖5
最簡單的是一個(gè)固定的融合網(wǎng)絡(luò)，這也是最早期的BEV方案。它的好處是所有的都見過，沒有特別新的架構(gòu)在里面，但是足夠簡單、魯棒、好用，所以作為一個(gè)起點(diǎn)對應(yīng)上面提到的幾個(gè)不同層次內(nèi)容。左邊是上面提到的alignment、temporal fusion、 spatial fusion、最終的Task heads，圖6以攝像頭為例，激光雷達(dá)可能會(huì)有一些不同的變種，但基本的意思是一樣的。首先，在征程2和征程3里，通過采用多任務(wù)模型來同時(shí)獲得更好的感知性能和更低的系統(tǒng)延遲，所以可以認(rèn)為我們的感知系統(tǒng)是由一個(gè)或多個(gè)多任務(wù)模型組成的。圖5有一個(gè)簡單的示例圖，包括以全圖輸入的一些多任務(wù)模型，和若干以ROI作為輸入，或是需要做細(xì)粒度識別的一些多任務(wù)模型。

圖6
下面將從Backbone、Task設(shè)計(jì)以及Multi-task model三個(gè)方面為大家講解算法的設(shè)計(jì)。首先是Backbone的設(shè)計(jì)，在Google提出MobileNet之后，MobileNet在對低延遲有非常高要求的場景中獲得了巨大成功，并且它僅需要更小的算力。但MobileNet也有一定的缺陷，因?yàn)樗膁epthwise convolution與pointwise convolution的計(jì)算量分配不均，使得在硬件上會(huì)增加計(jì)算和訪存讀取的切換時(shí)間。

為了解決上面的問題，我們提出了VarGNet。它是指可變組的卷積，即variable group的CNN，通過可變組卷積升維，再通過pointwise convolution降維。MobileNet則是通過depthwise convolution升維。相比普通的 group convolution，我們的網(wǎng)絡(luò)group數(shù)可變，但每個(gè)卷積里分組channel數(shù)是一致的，而一般的group convolution是channel數(shù)不一致，但group數(shù)保持一致。之所以要做到channel數(shù)一致，是因?yàn)榭梢越M合跨層之間的部分 channel卷積，減少在SRAM與DDR之間的讀取。
VarGNet有兩個(gè)特性，一個(gè)是Block內(nèi)計(jì)算更均衡，像剛剛提到的升維和降維分別使用variable group跟pointwise convolution計(jì)算，減少了內(nèi)存切換和計(jì)算之間的平衡；另外一方面在block之間采用了一個(gè)更小的 channel或更小的feature map，通過這種方式達(dá)到更好的訪存和計(jì)算平衡。
關(guān)于特征和參數(shù)的組合，以及硬件在計(jì)算過程中的流水線，大家可以參考凌坤在2月23日講解的《好的自動(dòng)駕駛AI芯片更是“好用”的芯片》，里面有更詳細(xì)的介紹。這篇VarGNet的論文，也可以在arXiv上找到。

圖7

之后是感知任務(wù)設(shè)計(jì)，大家最熟悉可能是2D感知。計(jì)算機(jī)視覺里一些經(jīng)典的任務(wù)，比如檢測、分割、分類和關(guān)鍵點(diǎn)檢測，組成了自動(dòng)駕駛里最基礎(chǔ)的2D感知。圖7有一些示例，像車輛檢測、車型分類、針對一個(gè)行車場景和停車場景的分割，以及通過車輪接力點(diǎn)的關(guān)鍵點(diǎn)檢測，在2D任務(wù)里判斷車輛的朝向，和在停車場景中停車位的檢測。但是2D感知都是在圖像域的，所以要變?yōu)榭梢员宦窂揭?guī)劃和控制所使用的車輛坐標(biāo)系或世界坐標(biāo)系下的感知結(jié)果，因此需要結(jié)合一系列的先驗(yàn)才能得到所需要的信息。

圖8
綜上可知，2D感知實(shí)際上具有很大的局限性。它依賴人工邏輯設(shè)計(jì)，難以規(guī)?；臄U(kuò)展，比如圖8左邊的例子，上面是一個(gè)車道線的分割，它能夠幫我們擬合出來在圖像坐標(biāo)系下的二維車道線，然后再通過一系列外參的映射，把它反推到車輛坐標(biāo)系下的車道線。圖8右邊的兩張照片是2D檢測不能很好應(yīng)對的場景，右側(cè)上圖是一個(gè)橫穿的車輛，可以看到車輛的檢測效果并不好，這是因?yàn)樽詣?dòng)駕駛汽車可能在大部分行駛過程中，都會(huì)看到車尾或者對向來車，這種橫穿車輛相對來說是較少出現(xiàn)。
右側(cè)下圖是復(fù)雜遮擋的例子，車尾與全車檢測都還有一個(gè)不錯(cuò)的效果，但在這樣很多遮擋情況下，很難估計(jì)車輛的pose。如果沒有辦法估計(jì)車輛pose，也沒有辦法知道它行進(jìn)的方向，以及對自動(dòng)行駛的影響。因此為了使用深度學(xué)習(xí)，即通過數(shù)據(jù)和計(jì)算進(jìn)行端到端的優(yōu)化，是需要進(jìn)行原生的3D環(huán)境感知。

圖9
講到3D環(huán)境感知，首先會(huì)想到單目深度估計(jì)。當(dāng)然，單目深度估計(jì)實(shí)際上是一個(gè)2.5D的任務(wù)，并不是一個(gè)嚴(yán)格的3D任務(wù)。現(xiàn)在最常見的單目深度估計(jì)的算法是通過激光雷達(dá)點(diǎn)云的監(jiān)督，可以看到圖9左下角是激光雷達(dá)提供的稀疏真值，圖9左上角是原始輸入的 RGB圖像，然后通過激光雷達(dá)提供的稀疏監(jiān)督，能夠預(yù)測出稠密的深度值。通過深度值可以解決非常多的問題，比如圖9右上角，如果使用車尾和全車檢測，很難應(yīng)對一輛拉了樹木的大車，甚至車尾會(huì)發(fā)生漏檢，但depth可以很好的應(yīng)對，防止出現(xiàn)一些交通事故。

此外depth還可以改進(jìn) Freespace的效果，尤其是外參測距的情況。圖9右邊中間部分是單純的外參測距產(chǎn)生的Freespace，而下面的是外參+depth產(chǎn)生的Freespace，可以看到在一個(gè)高速收費(fèi)口有三個(gè)水馬，實(shí)際上感知是找到了水馬，但Freespace投影出來這幾個(gè)水馬的位置卻比較靠后。而通過引入depth，可以更好的得到一個(gè)準(zhǔn)更準(zhǔn)確的Freespace，結(jié)果顯示這三個(gè)點(diǎn)的位置跟水馬檢測到的位置是很接近的。
很多同學(xué)也會(huì)問到，基于激光雷達(dá)的任務(wù)，怎樣更好的優(yōu)化，因?yàn)榱慨a(chǎn)車上是沒有激光雷達(dá)的，所以現(xiàn)在也在嘗試基于多攝像頭和多幀的光度一致性，對深度預(yù)測模型做無監(jiān)督或自監(jiān)督的優(yōu)化，這也是目前學(xué)術(shù)界廣泛嘗試的方案。

圖10

接下來針對動(dòng)態(tài)目標(biāo)的3D檢測，與depth任務(wù)類似，同樣要用激光雷達(dá)得到場景中所有3D的動(dòng)態(tài)目標(biāo)，比如車輛、騎車人，然后再以圖像為輸入進(jìn)行學(xué)習(xí)，并直接輸出3D的bounding box offset，還有長、寬、高等。圖10可以看到一些3D檢測的示例圖，包括一個(gè)多類目標(biāo)的感知車輛，還有騎車人以及針對橫穿馬路場景的處理。剛剛前面也講到，目前2D感知很難應(yīng)對橫穿車輛的場景。

其次，當(dāng)沒有辦法準(zhǔn)確估計(jì)pose時(shí)，實(shí)際上很難判斷周圍車輛是否會(huì)在近距離對本車安全產(chǎn)生影響，而3D感知可以對遮擋車輛有很好的 pose估計(jì)，因?yàn)?bounding box本身是帶有pose的，這樣可以產(chǎn)生更穩(wěn)定的下游預(yù)測值，自車行駛也會(huì)更加平順。

圖11

再接下來是3D車道線，上面講到2D感知局限性時(shí)，實(shí)際上也提到了2D車道線，如果先做分割，再做投影會(huì)很復(fù)雜。其次分割還需要一個(gè)相對復(fù)雜的連通域提取過程。車道線是環(huán)境里面最重要的一個(gè)靜態(tài)目標(biāo)，因?yàn)槲覀冊诖蠖鄶?shù)的城市道路和高速路上，車輛主要是沿著車道線行駛，因此研發(fā)原生的3D車道線感知很關(guān)鍵。上面右半部分的圖片是對圖11中的左半部分圖片進(jìn)行了IPM投影，然后將豎直的列作為anchor進(jìn)行anchor-based detection，之后再在 instance基礎(chǔ)上提取關(guān)鍵點(diǎn)。3D車道線的輸入可以是單攝，也可以是跨攝感知融合的特征，跨攝感知融合的特征會(huì)在后面講到。

圖12

接下來是多任務(wù)模型的設(shè)計(jì)和改進(jìn)。圖12是第一版多任務(wù)模型組成的視覺感知系統(tǒng)，是一個(gè)全圖輸入且相對比較大的多任務(wù)模型，采用了UNet結(jié)構(gòu)，做所有關(guān)鍵目標(biāo)的檢測。之后會(huì)對這個(gè)圖片感興趣區(qū)域做截取，比如找到了行人、交通燈和車輛。因?yàn)榛谛腥嘶蜍囕v的輸入，還要做很多其他的任務(wù)，像朝向的判斷、關(guān)鍵點(diǎn)檢測以及分類等，所以還會(huì)針對不同的目標(biāo)，再去使用一系列、更小的、以ROI作為輸入的模型，做更細(xì)粒度的任務(wù)。

在這個(gè)系統(tǒng)中，實(shí)際上是有多個(gè)大小不一的多任務(wù)模型，最終至少產(chǎn)生了40多個(gè)task outputs。這個(gè)task output并不是tensor，因?yàn)槊恳粋€(gè)task可能會(huì)有非常多的tensor輸出，比如3D車輛檢測就有非常多的tensor輸出，包括pose、長寬高以及中心點(diǎn)位置等。但是這個(gè)系統(tǒng)也存在一些問題，比如在系統(tǒng)中需要去截取這些圖片，再去獨(dú)立的過模型，可能沒有辦法復(fù)用或者共享之前大模型提取的一些特征，這實(shí)際上有一定的浪費(fèi)，因此也希望采用特征ROI輸入的多任務(wù)模型來改進(jìn)系統(tǒng)。

圖13

征程3芯片支持非常高效的ROI-align算子，這也使得基于特征區(qū)域做多任務(wù)的方案成為了可能，與兩階段檢測器很類似，基于特征ROI的多任務(wù)模型，通過ROI算子選取特征來進(jìn)行下游任務(wù)。一個(gè)檢測器的下游任務(wù)只有RCNN，但我們的多任務(wù)模型下游任務(wù)會(huì)復(fù)雜很多。圖13右側(cè)是基于特征ROI的多任務(wù)模型示例，它由 Backbone與若干個(gè)RPN，以及一系列Task head組成。因?yàn)槟Ｐ蜁?huì)有一些 Dense prediction，比如前面講到的depth，即每個(gè)像素都有輸出的任務(wù)，所以會(huì)有一些不涉及這個(gè)RPN或Region proposal提取部分的任務(wù)。這里舉了兩個(gè)例子是車輛跟行人的RPN，實(shí)際上還會(huì)有更多其他的任務(wù)，包括騎車人、標(biāo)志牌、交通燈等其他的關(guān)鍵任務(wù)。

針對基于特征ROI的多任務(wù)模型還有很多優(yōu)化方法，下面為大家羅列了三種方法。首先將RPN替換成一個(gè)更好的 proposal generator，而征程3也支持一個(gè)更復(fù)雜的檢測器，得到了ROI，然后再用ROI返回Backbone上取特征的方式，并且這個(gè)過程非常高效，它完全是在BPU里進(jìn)行；其次是把一些沒有必要的Dense prediction變成Sparse prediction，以及在Task head之間有一些share feature，進(jìn)一步降低模型的延遲。

圖14
下面詳細(xì)介紹下這三種方法，首先是Better proposal generator，比如把RPN替換成FCOS，這也是現(xiàn)在相對比較新或者檢測性能相對比較好的模型。上面有提到征程3是支持通過更復(fù)雜的檢測器獲取ROI，反過來再通過ROI來獲取feature，然后進(jìn)行下游任務(wù)。但是更復(fù)雜的 proposal generator有利也有弊，利在于首先是特征表達(dá)相對可能更淺層一些，所以通過引入淺層的特征，檢測框可能是一個(gè)更精確的框；其次因?yàn)镕COS本身有很好的性能，所以它對 proposal 的提取會(huì)更精確，像可以更減少一些false positive proposal。但是它也有代價(jià)，因?yàn)镕COS會(huì)比RPN更復(fù)雜，所以計(jì)算量更高，可能會(huì)給模型帶來一些延遲的增加，所以這里需要去做一些trade off。

接下來是dense prediction變成sparse prediction，和一個(gè)典型的例子：Vehicle 3D det變成Sparse vehicle 3D det。因?yàn)槌Ｒ姷幕?CenterNet的檢測器，比如FCOS 3D是一個(gè)稠密的3D檢測器，只需要把它連接在backbone上，就能夠完成多任務(wù)模型，但是這個(gè)過程實(shí)際上是有一定浪費(fèi)的，既然 region proposal已經(jīng)給出了車輛的區(qū)域，那完全可以在proposal上預(yù)測3D bounding box。

圖15
圖15可以看到Sparse 3D與Dense 3D的對比，在一些遠(yuǎn)距離的車輛上面， Sparse 3D獲得更好的召回，同時(shí)還降低了計(jì)算量。這也是因?yàn)镽PN會(huì)提取更多、更豐富的proposal，使得能夠在第一個(gè)階段保留更多的候選區(qū)域。
最后一個(gè)是Task head combination，比如針對vehicle task123可能是檢測、關(guān)鍵點(diǎn)或者分類等其他任務(wù)，這三個(gè)head實(shí)際上是比較類似的，或者說是相關(guān)的任務(wù)，如果把這三個(gè)head再共享一部分特征，能夠使得整個(gè)模型的計(jì)算量有一定下降，從而獲得更低的模型延遲。

圖16

以上是針對多任務(wù)模型進(jìn)化做過的一些嘗試或一部分工作，前面講到了基于圖片ROI跟特征ROI兩種多任務(wù)模型的選擇，但是基于特征ROI和圖片ROI的模型并不簡單是一個(gè)替代關(guān)系，即特征ROI模型做出來之后，它不可能完全替代圖片ROI。

它們相互會(huì)有一些優(yōu)勢和缺點(diǎn)。比如基于圖片ROI的多任務(wù)模型，它的研發(fā)工作是相對解耦的，像我在做車輛，我的伙伴在做行人，我們倆可以迭代兩個(gè)模型，而不需要在同一個(gè)很大的模型里開展工作，這樣研發(fā)的節(jié)奏或分工會(huì)更清晰簡單些；其次，它可以針對單一任務(wù)快速、低成本迭代，比如我的版本發(fā)出去后，發(fā)現(xiàn)車輛的效果不太好，但是其他的都很好，實(shí)際上可以只迭代車輛的多任務(wù)模型，而不用迭代其他的，但是基于特征ROI模型也可以只迭代這個(gè)head，但是基于特征ROI總是要提取 Backbone的特征，所以會(huì)讓過程變得稍微復(fù)雜；最后圖片ROI可以調(diào)度skip非關(guān)鍵目標(biāo)的計(jì)算，比如一些遠(yuǎn)距離車輛，可能現(xiàn)在不是特別關(guān)注，軟件就不會(huì)調(diào)度圖片ROI的車輛多任務(wù)模型。
針對特征ROI，因?yàn)樵诔Ｒ?guī)的一個(gè)兩階段檢測器里，通常只能設(shè)置置信度和proposal的上限，很難做更復(fù)雜的策略來選擇這個(gè)特征的ROI。雖然在軟件層面上可以實(shí)現(xiàn)，但是會(huì)更復(fù)雜一些。
圖片ROI的缺點(diǎn)剛剛也講到，之所以要做特征共享就是為了節(jié)約計(jì)算量，所以它必然有更大的一個(gè)計(jì)算量；其次它的發(fā)版會(huì)更復(fù)雜，也更繁瑣，維護(hù)也會(huì)更麻煩，因?yàn)橐粋€(gè)版本里面可能要帶很多個(gè)模型，而它們要被整理成一個(gè)相同的版本號。
特征ROI，首先它能完成特征共享，節(jié)約算力降低延遲；其次能夠做端到端的聯(lián)合優(yōu)化，即proposal的提取與stream下游的一些任務(wù)能夠做端到端的聯(lián)合優(yōu)化，做過深度學(xué)習(xí)的同學(xué)，應(yīng)該都會(huì)非常期望我們的任務(wù)是可以被端到端聯(lián)合優(yōu)化的，有梯度回傳一般來說總能帶來更好的效果；最后特征ROI能夠給下游任務(wù)提供更大的感受野，因?yàn)槊總€(gè)特征的像素對應(yīng)到原圖上一個(gè)很大的區(qū)域。但是特征ROI也不是完全完美，它會(huì)有一些訓(xùn)練難度大、耗時(shí)長的問題，以及Train from scratch代價(jià)高，所以在實(shí)際工作中這兩種也會(huì)針對產(chǎn)品與任務(wù)，以及不同的項(xiàng)目做靈活選擇。

圖17

多任務(wù)模型的最后一部分是多任務(wù)模型的訓(xùn)練。多數(shù)模型如果沒有一個(gè)很好的訓(xùn)練機(jī)制，需要把每張圖片上所有的task都進(jìn)行一個(gè)標(biāo)注，并且有時(shí)很難控制不同task之間的數(shù)據(jù)量、更新頻率以及迭代權(quán)重，所以也設(shè)計(jì)開發(fā)了一種每個(gè)task獨(dú)立forward 和backward的訓(xùn)練模式，它可以每個(gè)任務(wù)單獨(dú)構(gòu)建計(jì)算圖，使用獨(dú)立的 batch size，比如task1是針對vehicle的某一個(gè)任務(wù)，而task2是針對pedestrian的某一個(gè)任務(wù)，它們倆可以有不同的batch size，這樣獨(dú)立的方式也可以比較容易的控制task1跟task2的迭代次數(shù)。像剛剛提到，如果車輛任務(wù)已經(jīng)做得特別好，但行人任務(wù)不是特別好，只想迭代行人的task2。再次，它可以很方便去做任務(wù)采樣訓(xùn)練。最后，它支持圖片僅做一部分任務(wù)的標(biāo)注，比如有一些圖，過去可能只標(biāo)注了pedestrian跟vehicle，但現(xiàn)在新增了一個(gè)task，是交通燈，通過這種方式就能夠很好的把僅有部分標(biāo)注的 data也可以做很好的應(yīng)用。
圖17的PPT動(dòng)畫也展示了這個(gè)過程，可以看到是在不同task之間，我們?nèi)imple一些data，然后forward 、backward結(jié)束之后，再進(jìn)行到下一個(gè)task。

03 實(shí)現(xiàn)規(guī)?；慨a(chǎn)的“最后一公里”

首先我想說“行百里者半九十”，在這個(gè)方案研發(fā)過程中，從研發(fā)的啟動(dòng)到車型量產(chǎn)會(huì)花掉比較久的時(shí)間。從最開始介紹Mono跟Pilot產(chǎn)品時(shí)，大家可以看到整個(gè)Mono產(chǎn)品是三年磨一劍，Pilot也是達(dá)到了兩年的開發(fā)時(shí)間，所以在這樣長的周期里，實(shí)際上算法方案大部分定型和數(shù)據(jù)覆蓋大部分場景的情況下，距離量產(chǎn)可能僅僅才完成一半的工作。

圖18

在大部分場景覆蓋和算法方案定型之后，還有大量的細(xì)致打磨和解決長尾問題的工作量和時(shí)間。圖18是一個(gè)長尾分布的圖片，大家可能都非常熟悉，這個(gè)圖片中橫軸部分做了一個(gè)延長，因?yàn)殚L尾問題是永遠(yuǎn)解決不完的。

圖19

針對長尾問題的解決方法，是通過標(biāo)準(zhǔn)的工作流和好用的工具，構(gòu)建更有效的datasets，才能夠更好地解決長尾問題。當(dāng)然在這個(gè)階段并不是沒有算法方案改進(jìn)的工作，一定還是有的，但在這部分，datasets的工作會(huì)更加重要。圖19右側(cè)這張圖是Andrej Karpathy 在SPARK+AI SUMMIT 2018 talk里的截圖，他講了非常有意思的一句話：spend most of my time just massaging the datasets。他用了massaging這個(gè)詞，實(shí)際上就是對datasets做一個(gè)非常細(xì)微的調(diào)整。

他還用了一張圖講 lost sleep over，實(shí)際上是講他們在PhD階段和在tesla工作時(shí)的時(shí)間分配。圖中藍(lán)色是指算法的開發(fā)，紅色是指調(diào)整datasets所花的時(shí)間。地平線實(shí)際上也是類似的，在算法方案穩(wěn)定之后會(huì)有大量的調(diào)整datasets的時(shí)間，而剛才也講到一個(gè)好的datasets還需要工具支撐一個(gè)標(biāo)準(zhǔn)的工作流，才能更高效地產(chǎn)出一個(gè)好的datasets。

圖20

那什么是一個(gè)好的工作流或我們的工作流是什么呢？首先收到長尾的問題或corner case，這些case可能來自于自己的測試，也可能來自于客戶的測試。這些case會(huì)積攢得非?？?，我們也會(huì)對它進(jìn)行分類。當(dāng)某一類型的case積攢得比較多時(shí)，會(huì)對它們進(jìn)行 root cause分析，將大量的root cause扔進(jìn)一個(gè)相對比較標(biāo)準(zhǔn)的優(yōu)化流程里，我們有若干很標(biāo)準(zhǔn)的優(yōu)化流程。盡管大部分優(yōu)化流程都是很收斂的，但難免還是會(huì)發(fā)現(xiàn)新的根因，新的根因也會(huì)為它設(shè)計(jì)新的優(yōu)化流程。
圖20右側(cè)是一個(gè)root cause分析的一個(gè)triage tree，但這只是部分，可以看到把這個(gè)根因分得非常細(xì)，這也是在三年量產(chǎn)過程中，針對場景或特定情況的一些分類的積累。root cause分析的過程一部分是自動(dòng)的，也有一部分是手動(dòng)的。如果是自動(dòng)，它也會(huì)依賴云端更大的計(jì)算量，或者依賴后驗(yàn)分析，因?yàn)橐话阍诘玫竭@個(gè)case或問題觸發(fā)之后，還有很長的一段時(shí)間。當(dāng)你離線去處理它時(shí)，你可以用事后諸葛亮的方式來反推是否有問題，或者是有什么樣的問題。也有一部分會(huì)依賴算法工程師或者標(biāo)注人員進(jìn)行手動(dòng)的root cause分析。

圖21

下面以近處大車造成的ACC點(diǎn)剎為例。首先對 ACC點(diǎn)剎進(jìn)行root cause分析，發(fā)現(xiàn)是因?yàn)榻幋筌嚨臋z測框分裂造成，圖21右側(cè)是一個(gè)真實(shí)的場景，這種場景在測試過程中是非常多的，紅色的框是車尾檢測并不是全車，可以看到這兩個(gè)框本身貼合是很好的，但中間卻出現(xiàn)了一個(gè)很難被去除的框，這就是通過root cause發(fā)現(xiàn)的一類問題，就是近處大車框的分裂，那怎么樣通過一個(gè)標(biāo)準(zhǔn)的工作流去解決這個(gè)問題呢？
有兩個(gè)主要的分支，第一個(gè)分支是用很多這樣的長尾問題去產(chǎn)生一個(gè)回歸用的集合 regression dataset。首先會(huì)選取一個(gè)片段，我們稱之為pack或clip的視頻片段，然后在這里面選取關(guān)鍵的目標(biāo)和時(shí)刻，關(guān)鍵目標(biāo)是右上角圖片里左邊的車，因?yàn)樗俏覀兊腃IPV，即是本車道離自車最近的一輛車；關(guān)鍵時(shí)刻就是錯(cuò)誤幀框跳出來，造成車輛產(chǎn)生點(diǎn)剎前后的一些時(shí)刻，然后會(huì)確定關(guān)鍵指標(biāo)。針對這樣的檢測問題，關(guān)鍵指標(biāo)實(shí)際上是AP或者 IoU error，因?yàn)镮oU決定了框的檢測是否足夠貼合，之后會(huì)進(jìn)行真值的標(biāo)注或者自動(dòng)生成，自動(dòng)生成可能是一個(gè)預(yù)標(biāo)注的過程，也可能是其他更復(fù)雜的4D標(biāo)注生成的過程。針對2D更快或更常見的做法還是標(biāo)注，之后把選好的corner case加入到框分裂case的回歸集合里，這是回歸case集合建立的鏈路。
另外一條鏈路是我們?nèi)绾稳ソ鉀Q它。首先會(huì)統(tǒng)計(jì)近處的大車是不是真的不充分，即是訓(xùn)練集合的一個(gè)統(tǒng)計(jì)，并分析訓(xùn)練集里打的一些tag，比如大車、離自車的距離、CIPV等看有多少這樣的情況在訓(xùn)練集里是存在的。如果它非常豐富，但是還是出現(xiàn)了問題，會(huì)對它做算法調(diào)整，比如引入框的置信度，針對框邊界的置信度，而不是針對框本身的置信度，因?yàn)楝F(xiàn)在的很多基于關(guān)鍵點(diǎn)的檢測技術(shù)，實(shí)際上能夠給我們帶來框邊界的置信度。但這種情況并不是特別多，大部分情況下會(huì)發(fā)現(xiàn)這種類型的數(shù)據(jù)并不充分，因此會(huì)做一些數(shù)據(jù)挖掘，然后將挖掘到的數(shù)據(jù)放到模型里做訓(xùn)練，然后評測，跟 case集合做回歸，之后再做模型的發(fā)布。
以上是以近處大車造成的ACC點(diǎn)剎為例，實(shí)際上很多與某一個(gè)目標(biāo)相關(guān)的，并且需要通過數(shù)據(jù)挖掘解決的標(biāo)準(zhǔn)工作流的方法都非常類似，這也就使得我們的工作能夠相對比較收斂，以一種較少的工作流程來解決大部分在量產(chǎn)之前會(huì)遇到的問題。

圖22

剛剛講到了數(shù)據(jù)挖掘，下面會(huì)給大家展示一些數(shù)據(jù)挖掘的方法示例。首先，最常見到的Model Committee，會(huì)有多個(gè)大小不一的模型檢測上圖。比如圖22中近處大車部分，某一個(gè)模型檢測到了三個(gè)框，某一個(gè)檢測到兩個(gè)，還有檢測到一個(gè)，多個(gè)性能很好的大模型，表現(xiàn)出了不一致的效果。我們認(rèn)為這個(gè)時(shí)刻大概率是有問題的，因此就會(huì)獲取它的標(biāo)注，確認(rèn)它是否有問題，然后加入到訓(xùn)練中。

第二個(gè)是用Scene tagging，通過這種感知結(jié)構(gòu)化信息，因?yàn)樵跍y試過程中都是一邊測試一邊在跑功能，所以會(huì)保留很多已有的感知結(jié)果，比如車道線的感知結(jié)果以及場景分類得到的天氣、時(shí)間段的結(jié)果，這些感知結(jié)果會(huì)被結(jié)構(gòu)化成一些場景的標(biāo)簽，比如夜晚高速路導(dǎo)流線的場景標(biāo)簽，這樣可以在大的、全量的datasets里尋找相關(guān)的數(shù)據(jù)，并且將它們引入到訓(xùn)練當(dāng)中。
第三個(gè)會(huì)用到的方法是similarity search。similarity search會(huì)對圖片提取一個(gè)特征，提取特征的模型是什么，可以自行選擇或自行去訓(xùn)練，現(xiàn)在有非常多性能非常好的、通過自監(jiān)督學(xué)習(xí)得到的各類大模型，當(dāng)提取出來這些特征之后，我們可以用希望得到的場景圖片，比如一個(gè)隧道口，去底庫里所有圖片做特征的相似搜索，然后得到一系列高速路隧道口的圖片，引入到訓(xùn)練里。
這只是一部分會(huì)用到的數(shù)據(jù)挖掘方法，因?yàn)閿?shù)據(jù)挖掘在工作中非常重要，所以也會(huì)有一些其他更豐富的手段。

圖23

接下來講下工具部分，前面提到了一個(gè)高效的工作流是被很好用的工具和基礎(chǔ)設(shè)施所支撐的。而地平線艾迪（Horizon AIDI）AI開發(fā)平臺，就是我們所依賴的一個(gè)算法研發(fā)的平臺和基礎(chǔ)設(shè)施，它由AIDI-Issue，AIDI-eval、AIDI-Model、AIDI-Label等多個(gè)平臺支撐算法研發(fā)服務(wù)。目前關(guān)于地平線AIDI的材料非常多，我的同事凌坤2月23日公開課課程《好的自動(dòng)駕駛AI芯片更是“好用”的芯片》中，對這部分內(nèi)容有更細(xì)致的介紹，大家如果感興趣可以看下回放。

圖24
算法工程師開發(fā)更多的是Horizon Data Flow(HDFlow)。它是依托于AIDI構(gòu)建、基于DAG的算法自動(dòng)化開發(fā)全鏈路閉環(huán)工具。DAG是指有向無環(huán)圖，如圖24左邊的示例，把一些節(jié)點(diǎn)或者OP通過一些邊連接在一起，讓OP能夠流轉(zhuǎn)。現(xiàn)在業(yè)界有非常多不同的DAG引擎，我們也是通過對DAG引擎的封裝來構(gòu)建HDFlow，然后完成自動(dòng)化的工作流。
HDFlow對業(yè)界一些比較普遍主流的一些DAG引擎都做了一個(gè)抽象跟封裝，并且簡化了OP操作的接口，同時(shí)它也是支持本地，即在自己的開發(fā)機(jī)上或者在集群上的分布式執(zhí)行，靈活度高，也方便算法工程師調(diào)試。右邊是一個(gè)DAG任務(wù)的可視化，每個(gè)小圈表示一個(gè)OP，之所以畫了綠色的對號，是因?yàn)镈AG已經(jīng)順利的完成了一個(gè)執(zhí)行，這里面可能包含了一些數(shù)據(jù)挖掘和模型訓(xùn)練等等，都會(huì)作為HDFlow中的一些節(jié)點(diǎn)。

圖25

圖25展示了一些可以由HDFlow搭建的任務(wù)，包括訓(xùn)練前閉環(huán)：數(shù)據(jù)挖掘、標(biāo)注質(zhì)量檢查、評測集構(gòu)建、場景與Corner case數(shù)據(jù)集構(gòu)建、數(shù)據(jù)分布統(tǒng)計(jì)，以及訓(xùn)練閉環(huán)：訓(xùn)練數(shù)據(jù)打包、模型訓(xùn)練、模型發(fā)版、模型評測和回歸等等，這些都是通過HDFlow可以自動(dòng)化構(gòu)建的一些task。所有的小DAG可以被更大的DAG包含，所以這些任務(wù)之間也是可以被HDFlow自動(dòng)化的串聯(lián)在一起，通過這個(gè)工具，大幅的提升了在標(biāo)準(zhǔn)化工作流中做數(shù)據(jù)流轉(zhuǎn)或算法開發(fā)任務(wù)。

圖26

既然已經(jīng)講了許多量產(chǎn)中的工作，也為大家展示一些成果，首先是純視覺的AEB，如圖26左上角所示。目前大部分汽車上都會(huì)在前保險(xiǎn)杠上裝一個(gè)黑色的毫米波雷達(dá)，而純視覺AEB能夠去掉這個(gè)器件，更節(jié)約成本，特斯拉目前也在Model 3跟Model Y中去掉了毫米波雷達(dá)，因?yàn)樘厮估J(rèn)為會(huì)有一定噪聲，引入毫米波雷達(dá)好壞與否，不是今天要討論的話題。

目前，Horizon Matrix Mono前視單目解決方案，是國內(nèi)唯一具有純視覺AEB感知能力的方案，能夠同時(shí)達(dá)到兩項(xiàng)非常厲害的指標(biāo)：C-NCAP 五星+和AEB誤報(bào)數(shù)小于1次/20萬公里。C-NCAP是中國的New Car Assessment Program，五星+是最高級別得分， C-NCAP要求車型需通過乘員保護(hù)、行人保護(hù)和主動(dòng)安全三大項(xiàng)嚴(yán)苛評測，綜合得分率≥90%才能獲得5星+。與此同時(shí)，Matrix Mono也控制了AEB的誤報(bào)數(shù)在非常低的水平——遠(yuǎn)小于20萬公里一次，即大部分用戶在開這個(gè)車的生命周期里面，像10萬公里、 15萬公里，很大概率都碰不到AEB誤觸發(fā)的情況，而且指標(biāo)還在不斷被優(yōu)化。 
AEB誤觸會(huì)帶來很不安全的問題和很差的用戶體驗(yàn)。大家過去可能聽過一些車，由于AEB誤觸造成所謂幽靈剎車的情況，像正在路上開車，然后什么東西都沒有，車突然自動(dòng)剎車，然后把乘客嚇了一跳，所以它也是一個(gè)很關(guān)鍵的指標(biāo)。
我們之所以能夠達(dá)到這樣的指標(biāo)，與前面講到的算法方案、工具、標(biāo)準(zhǔn)化的工作流相關(guān)，也和測試能力有關(guān)。目前我們的產(chǎn)品是經(jīng)過了超千萬公里、超過60萬小時(shí)的實(shí)車測試，并且具備百萬公里每天的回灌測試能力，即如果有一個(gè)版本做了一定的改進(jìn)，可以在一天之內(nèi)完成100萬公里的回灌測試。在前不久的中國電動(dòng)汽車百人會(huì)的論壇上，苗圩主任也提出需要將AEB作為車輛標(biāo)配的建議，這也說明了AEB作為主動(dòng)安全重要的功能，被看重的程度或重要性。
接下來展示兩個(gè)NOA領(lǐng)航輔助駕駛的 Demo視頻。展示的是夜間車輛進(jìn)入匝道的過程，可以看到整個(gè)駕駛過程非常平順。在高速路行駛的期間，進(jìn)入匝道的過程中，是完全沒有駕駛員接管的。第二個(gè)視頻同樣是基于夜間領(lǐng)航輔助駕駛。這里是在跟著一輛車，車上載有貨物，且貨物跟車輛的車尾高度不相匹配的情況。可以看到，還是能夠做到平穩(wěn)跟車。

圖27

圖27展示地平線的一些量產(chǎn)成果，已經(jīng)有超過20個(gè)車企的定點(diǎn)合作，50多個(gè)車型的定點(diǎn)，以及超過百萬的智能芯片出貨和超過100家的生態(tài)合作伙伴。這張圖中是已量產(chǎn)的部分車型示例，黃圈是我個(gè)人參與過的一些ADAS量產(chǎn)項(xiàng)目。

04 感知技術(shù)的發(fā)展趨勢

圖28

最后給大家介紹我個(gè)人對感知技術(shù)發(fā)展趨勢的一些看法，我認(rèn)為圖28的這些技術(shù)會(huì)成為達(dá)成自動(dòng)駕駛的重要途徑。
首先是 Transformer。它有多種不同的應(yīng)用，首先可以作為Backbone，比如 SwinTransformer，在相當(dāng)長一段時(shí)間內(nèi)是SOTA，但現(xiàn)在有一些新的模型產(chǎn)出；其次Transformer還是空間和時(shí)間特征融合很重要的組件，現(xiàn)在不管是做一些Tracking或BEV感知，很多時(shí)候都用到Transformer結(jié)構(gòu)，才能夠達(dá)到很好的效果，所以Transformer很重要。
其次是 BEV感知。關(guān)于BEV感知，劉景初博士在地平線自動(dòng)駕駛技術(shù)專場第1講上有一個(gè)課程叫《上帝視角與想象力--自動(dòng)駕駛感知的新范式》，深入講解了地平線針對BEV感知的一些實(shí)踐。而BEV感知同時(shí)端到端地提供了特征融合和視角轉(zhuǎn)換，所以是一個(gè)很好的新范式，目前很多人都在做，但是特征融合的方式有很多，不僅僅是BEV感知。然而視角轉(zhuǎn)換也能夠給下游的一些任務(wù)預(yù)測和planning提供一個(gè)更好的輸入，這也是當(dāng)前會(huì)比較傾向于使用BEV感知的一個(gè)原因。
之后是時(shí)序的端到端感知。這種結(jié)合時(shí)序特征的，比如通過Transformer做時(shí)序特征融合的一些端到端檢測到跟蹤再到預(yù)測，能夠進(jìn)一步降低系統(tǒng)不喜歡的人工邏輯參與。因?yàn)槿斯み壿嫊?huì)使得我們總是需要很優(yōu)秀的工程師不斷優(yōu)化系統(tǒng)，使得系統(tǒng)很難 scale up。
接下來是多傳感器前（中）融合。現(xiàn)在有很多量產(chǎn)的車規(guī)級固態(tài)激光雷達(dá)，已經(jīng)在很多車型上應(yīng)用，像蔚來的ET7，理想的L9上都已經(jīng)有一些裝配。先不去論Lidar跟視覺之爭，如果僅僅是有這些傳感器，相比依賴人工邏輯的后融合，Lidar、Camera特征級的前融合，它能夠通過數(shù)據(jù)和計(jì)算的驅(qū)動(dòng)替代人工邏輯，帶來更簡單，或者更容易迭代的系統(tǒng)，同時(shí)算法也能夠降低對傳感器同步的要求。
下一個(gè)是（大模型的）自監(jiān)督學(xué)習(xí)。目前業(yè)界有非常多大模型的自監(jiān)督學(xué)習(xí)的工作，這些模型也顯示出了一定的智能。比如最近特別火的DALL-E2，可以輸入一段話來創(chuàng)作圖片，創(chuàng)作的這些圖片很難辨別是被機(jī)器或模型所創(chuàng)建的。我認(rèn)為自監(jiān)督學(xué)習(xí)的發(fā)展還是很好的，但自監(jiān)督預(yù)訓(xùn)練在下游任務(wù)的表現(xiàn)還有待提高。我們會(huì)對這個(gè)領(lǐng)域保持關(guān)注。
最后一個(gè)是 Low Level Vision的應(yīng)用。純視覺的自動(dòng)駕駛系統(tǒng)如果還是僅僅是依賴語義級的感知，比如detection、parsing會(huì)非常有局限性，因?yàn)檫@些語義級的感知往往是針對閉集，即一些定義好的類別，比如說車輛等。但是，它很難應(yīng)對一些極端復(fù)雜的場景，或者一些沒有定義過的障礙物類型。我個(gè)人認(rèn)為純視覺自動(dòng)駕駛系統(tǒng)的發(fā)展，會(huì)依賴 Low Level Vision的成熟和大規(guī)模應(yīng)用。

圖29
地平線已經(jīng)發(fā)布并即將量產(chǎn)的征程5正使得這些技術(shù)的量產(chǎn)落地成為可能。征程5有更大的算力，單顆芯片達(dá)到了128TOPS算力，也使得做一些更大的模型成為可能；其次它對Transformer有比較好的支持。在征程5上 SwinT可以跑到140FPS，同時(shí)征程5的功耗只有30瓦，而PC端常用的NV 3090，是在上百瓦功耗下達(dá)到230FPS，所以可以看到征程5有一個(gè)非常好的能效比，并且作為車規(guī)級的芯片，確實(shí)達(dá)到了很高的FPS，使得 SwinT系列在這個(gè)產(chǎn)品中使用成為可能。不過需要說明一下就是SwinT這里是一個(gè)batch size為1的情況，隨著batch size增大，3090也會(huì)明顯提升它的幀率。
其次，征程5支持圖片和特征的remap變換，因?yàn)楝F(xiàn)在不少BEV或者其他技術(shù)會(huì)依賴高效的圖片或特征的remap，包括要做虛擬相機(jī)之類的技術(shù)也是需要一些remap。
最后，征程5也硬核支持部分Low Level Vision feature的提取。
圖29左下角是一個(gè)以EfficientNet作為Backbone的FCOS模型，在征程5上與Xavier和Orin-X的對比，藍(lán)色的線是征程5，黃色的線是Orin-X，橙色的線是 Xavier，縱軸是mAP，橫軸是FPS，可以看到征程5是有顯著的優(yōu)勢。1283 FPS是在保持MS CoCo數(shù)據(jù)集上的精度 mAP=34.6%，輸入分辨率為512*512的情況下，征程5所達(dá)到的計(jì)算性能。
最后，給大家展示下基于征程5的Matrix SuperDrive產(chǎn)品片段做個(gè)預(yù)熱，后面還會(huì)有詳細(xì)的課程做講解。它是基于兩個(gè)征程 5，256 TOPS算力支持下的一款自動(dòng)駕駛產(chǎn)品。片段展示了一些BEV感知的結(jié)果和一個(gè)左轉(zhuǎn)的過程，可以看到整個(gè)過程是沒有接管并且非常平順的。這也是通過純視覺完成的。
以上是我今天跟大家分享的內(nèi)容，謝謝大家。