導讀

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

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

1、地平線自動駕駛環(huán)境感知量產(chǎn)實踐2、軟硬協(xié)同的自動駕駛感知算法設計3、實現(xiàn)規(guī)模化量產(chǎn)的“最后一公里”4、感知技術的發(fā)展趨勢

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

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

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

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

圖4

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

02 軟硬協(xié)同的自動駕駛感知算法設計

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

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

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

圖7

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

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

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

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

圖10

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

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

圖11

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

圖12

接下來是多任務模型的設計和改進。圖12是第一版多任務模型組成的視覺感知系統(tǒng)，是一個全圖輸入且相對比較大的多任務模型，采用了UNet結構，做所有關鍵目標的檢測。之后會對這個圖片感興趣區(qū)域做截取，比如找到了行人、交通燈和車輛。因為基于行人或車輛的輸入，還要做很多其他的任務，像朝向的判斷、關鍵點檢測以及分類等，所以還會針對不同的目標，再去使用一系列、更小的、以ROI作為輸入的模型，做更細粒度的任務。

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

圖13

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

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

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

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

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

圖16

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

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

圖17

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

03 實現(xiàn)規(guī)模化量產(chǎn)的“最后一公里”

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

圖18

在大部分場景覆蓋和算法方案定型之后，還有大量的細致打磨和解決長尾問題的工作量和時間。圖18是一個長尾分布的圖片，大家可能都非常熟悉，這個圖片中橫軸部分做了一個延長，因為長尾問題是永遠解決不完的。

圖19

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

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

圖20

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

圖21

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

圖22

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

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

圖23

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

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

圖25

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

圖26

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

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

圖27

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

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

圖28

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

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