在上期文章中，我們從Autopilot的感知堆棧的backbone網絡開始分析，從raw data到RegNet，再到BiFPN，最后來到多頭的Head結構，這就基本上給HydraNets的框架結構定了性。在Tesla AI Day結束之后，很多關心自動駕駛產業發展的人，觀后感普遍是智商不夠，看不懂。而實際上，如果讀者不進入實際的研發領域，要理解Autopilot的工作機制、框架和基本脈絡，實際上并沒有那么困難。而對于Autopilot整體框架的理解，一旦有心得，對于自動駕駛行業的從業者、愛好者和政策關注者，其實都是大有裨益的。

而作為一個典型的跨學科產業，傳統封閉知識結構的限制讓很多初次涉足自動駕駛行業的新手來說，都會感到明顯困難。一個突出的問題就是交叉學科概念實在太多太新了，往往名詞都看不懂，就不要說深究了。所以，小編寫這個系列文章的初衷就是盡可能拉低閱讀門檻，讓每個感興趣的讀者開卷有益。畢竟，Tesla這種具備開放心態的先鋒企業，不是總能遇得到的。

所以關注這個系列的讀者，在看系列中任何一篇文章的時候，都可以聯系系列中的其它文章串起來看，各種新鮮的名詞解釋和上下文串講會協助諸位和小編一起跑完這個理解的過程的。

圖一【Tesla transformer-33.png】來自論文《EfficientDet: Scalable and Efficient ObjectDetection》中的插圖，獲取URLhttps://arxiv.org/pdf/1911.09070.pdf；

這是上一篇文章中我們所講的關鍵點BiFPN網絡結構，其中BiFPN和其他上下游的網絡結構交代得比較清楚，所以小編在這里再強調一次。上圖左半部分為Google的EfficientNet，是一種典型的層次化的CNN Backbone結構，上圖中顯示為7層，每一層的分辨率逐漸降低，但是特征Feature map也是在這個過程中通過卷積計算來實現搜集的。重要的是，我們可以清晰地觀察到，從第3層到第7層的Feature map數據被依次輸入到BiFPN網絡內，從而可以利用BiFPN的融合結構設計，將不同層次的feature按照預定義的規則融合到一起，制造更準確的識別結果。

上圖（圖一）的最右側顯示了這個整體模型中的Task Head，顯示了優化后的backbone所提供的feature map最終被用于何種任務的實現。其中一個是分類任務Class，另一個是定位任務Box共兩個任務。它們兩個共享了EfficentNet backbone+BiFPN的特征識別結果，實現了算力的共享和高效利用。

在一個典型的CNN網絡中（以下圖為例是VGG16）另一個直觀的案例，原始的Input image在后續的一些列卷積處理之后，最終按照任務的要求實現Output輸出。通常講，CNN被用于網絡內容的識別，并在識別后按照識別結果的類別來報告輸出。下圖模型就是干這個的。

圖二【Tesla transformer-34.png】來自youtube.com中賬號@denisdmitriev的VGG16 Neural Networkvisualization視頻的插圖，獲取URLhttps://www.youtube.com/watch?v=RNnKtNrsrmg；

如果將這個VGG16的卷積模型拉伸開來，就可以清晰地展示出每一個卷積層、池化層的輸出直觀計算（or感知）結果，如下：

圖三【Tesla transformer-35、36.png】來自youtube.com中賬號@denis dmitriev的VGG16 Neural Network visualization視頻的插圖，獲取URLhttps://www.youtube.com/watch?v=RNnKtNrsrmg；

由于不同卷積算子的卷積計算，原始圖像中的蘋果（或者洋蔥），其不同的特征被捕捉出來，比如顏色、形狀、表皮類型、根莖形狀，甚至不同物種常常呈現的不同的凹凸不平的特點，都被CNN抓出來，并通過BiFPN類似的特征融合機制形成最終的認知，或者提供給后端Task Head有效的、良好的認知素材。從這個流程上看，CNN對于圖像信息特征的捕捉方式，幾乎和人類對于圖像的感知方式一致了。當然，人類的感知能力除了視覺信息分析，我們還具備觸覺、味覺和更一般的“世界知識體系”……這是AI暫時所做不到的。比如，兩個在外觀上完全一致的蘋果和洋蔥，人類視覺無法判斷分類結果，自然會拿在手上掂量一下，甚至聞一下、嘗一口，最終總是可以找到正確答案的。

之前在這個系列的第一篇文章里，我們談到過AI技術演進的下一個方向，也有對于多模態信息的綜合感知，那是因為Transformer體現出了一定的多模態數據處理能力。其實CNN技術本身也有同時被應用于圖形和語言的信息處理領域，但顯然自動駕駛領域內的感知問題，在當前階段還是應該關注圖形數據（視覺傳感器）為核心，解決了視覺問題，大概99%的問題都被解決了。在此基礎之上的更進一步感知多模態信息，才扎實。

圖四【Tesla transformer-37.png】來自Tesla AI day主題演講視頻截圖，URLhttps://www.youtube.com/watch?v=j0z4FweCy4M&t=4115s；

Backbone+Task heads的整體架構如上圖，這就是標準的多任務系統HydraNets。在這個多任務Heads框架中從左到右分別是Object Detection Task（應該包含靜態和動態所有道路目標的識別）、Traffic Lights Task（交通燈和其它交通標識的識別）和Lane Prediction Task（車道線及可行駛區域識別）。實際上FSD beta現在這個階段，使用到CNN backbone的任務一定不止以上三個。細分任務的原則是一個Head task無法處理和涵蓋一個類別的任務，就需要擁有獨立的Head Task。比如小編推測在Lan Prediction Task中，可能不僅僅是各種車道線的識別和預測，還有可能包含同樣關鍵的馬路邊緣路緣石邊界的識別。在這個具象的Task中，系統框圖只給出了regression方法（reg），在對于車道線的識別這是一個普遍的方法，因為車道線基本上可以用一個固定的二次函數、三次函數既可以描述出車道線走勢，所以機器學習里涉及的車道線識別方法，使用regression回歸方法來預測車道線的多項式系數即可，這是個慣用的標準做法。但對于馬路邊緣路緣石構成的可行駛區域邊界的識別，因為路緣石邊界的不規則屬性，可能無法服用regression方法。感興趣的讀者可以參考PolyLaneNet車道線識別的方法，互聯網可查。

圖五【Tesla transformer-38.png】來自Youtube站點博主@Frenchie的測試視頻截圖，URLhttps://www.youtube.com/watch?v=rfTpt8phxL4；

上圖可以觀察到FSD beta的中控屏幕顯示的紅色曲線為路緣石線條，由于基建處理路緣石的考量不僅僅是勾畫車輛可行駛區域，相對地也要考慮行人道上的各種設備需求，因此它并不是一直和車道線保持并行，會有非規則曲線的場景出現。上圖中這個場景下，顯示的識別結果出現錯誤，且這個非規則的路緣石不可能用低次曲線擬合出來。

對于object和traffic light的預測分類（屬性）和位置，則使用了classification、regression和attribution方法。類似的可以借鑒和查詢的論文就更多了，YOLO系列就是一個完美的參考，互聯網可查。

除了多頭的任務本身，圖四所顯示的多任務架構還需要注意的是Tesla在Backbone和Head之間插入了一個叫做multi-scale features的cache環節。這個環節在模型的測試過程中扮演了關鍵角色。按照Karpathy的解釋，訓練過程如下：

1 首先進行的是end to end的聯合訓練，輸入是視覺raw data，輸出是所有任務的輸出。監督所有子任務的準確度，并根據準確度進行干預（系統自動執行誤差的反向傳播）。這樣的訓練結果將會導致所有子任務的“集體最優結果”；

2 end to end的聯合訓練會導致子任務集體最優，但因為子任務之間不可能做到邏輯上的完全隔離，因此集體最優一定不是單個子任務的“個體最優結果”，因此需要以單個任務為核心進行調優fine tunning；

3 以單個子任務為核心的fine tunning的輸入為經過聯合調優后確立的backbone所輸出的multi-scale features，從位于中部的那個cache里直接獲?。惠敵鰟t為各自子任務的輸出，還是經過監督學習機制，最后將每個子任務收斂到各自的最優狀態；

4 然后重復1的end to end聯合訓練……

上述這個迭代流程可以確保網絡整體效能最優，且各個子任務的準確度最佳。橫向看，這并非Tesla的專利（小編：盡管Tesla有訓練多任務系統的一些專利，我們之前的文章有涉及過），業內處理自動駕駛系統內的多任務，大抵如此手法。但knowhow在于如何處理車載硬件的CPU算力——訓練方法的有效性——最終模型輸出的準確性，這三者之間的矛盾，達到和諧統一。這個Tesla當然不會細說，就比如這個cache內部的multi-scale feature，到底如何分配給不同的子任務可以協助子任務的預測水平實現最優？這就是Tesla的秘密了。

別的不好說，但是顯然的是，誰的數據（有效數據）最多最豐富最極端corner，誰就最有把握接近最佳模型。Tesla雖然扔掉了所有的毫米波雷達回波數據，也不屑于Lidar的點云數據，但在視覺領域的積累應該還是有底氣的。

截至目前，HydraNets架構已經可以支撐標準的L2自動駕駛業務了。對于Tesla來說，自從和Mobileye分手之后，HydraNets的框架就已經（也必須）開始部署了，無非是在框架內選擇不同的具體技術進行性能更新而已。但實際上如果要往更高層級的自動駕駛自治邁進，對于HydraNets架構的擴展就勢在必行了。

圖六【Tesla transformer-39、40.png】來自Tesla AI day主題演講視頻截圖，URLhttps://www.youtube.com/watch?v=j0z4FweCy4M&t=4115s；

以上兩張圖代表了兩種不同級別的自動駕駛應用，想必各位讀者已經耳熟能詳了。前者是典型的單目攝像頭所獲取的信息，以及背后的多任務HydraNets NN架構的識別結果。從Mobileye開始普及典型的Level-2自動駕駛系統以來，Tesla Autopilot就一直是這個思路。唯一的變化就是2016年脫離和Mobileye的合作之后，Autopilot有一個階段是采用了Camera+mm Radar的傳感器組合，2021年上半年則轉向Full vision。

上圖前者的識別結果確實豐富，我們有過專門的公眾號文章對Autopilot在這個階段對于單目視覺信息的識別做了解讀。但這個識別結果，哪怕融合了毫米波雷達的速度信息，支持更高等級的自動駕駛任務也是不夠用的。所以才有了上圖后者的需求，車輛哪怕是在封閉場地和低速的限制條件下，例如Smart summon（停車場智能召喚功能），也必須要掌握主車四周的全視角道路狀態（可行駛區域），才有可能進行路徑規劃，并發現召喚者。注：上圖中的九個視覺輸出中有兩個黑塊，意味著車身一共8個攝像頭，supper narrow遙距攝像頭并在Smart summon中參與道路3D信息捕獲和可行駛道路區域的識別。

對于Tesla Autopilot系統的識別堆棧談到這里，讀者應當注意這個主題的本質：花多少錢辦多少事兒。迄今為止對于CNN Backbone和純視覺的堅持，可以在大部分的Level-2任務上得到技術落地和回報，并在更大范疇的技術框架上一錘定音、不走回頭路以適應越來越高的NN技術占比對于龐大有效的數據量的需求。只要這一步走對了，小編的角度看，Tesla就算成功了一半。自動駕駛系統在未來能走多遠？走多快？這就不僅僅是一家公司的事情了，很多問題也還是基礎科學、科學技術產業化的問題。舉個非常簡單的例子，純視覺如何克服目標深度信息預測的準確度和時效性問題？神經網絡算子新貴Transformer轉戰視覺信息處理的突破，是如何提供給Tesla一個良好的視覺場轉化工具的？這里面有偶然，但更多是必然，我們相信只要走在正確的路上，困難就總是暫時的。

具體而言，當Tesla意識到前向單目攝像頭所捕獲的視覺信息，哪怕對其再精耕細作和堆砌大量數據訓練出來的模型，這個能力進展也無法處理更高等級的自動駕駛技術需求的時候，并沒有將現有識別堆棧推倒重來，而是繼續向前選擇了顯性的C++人工代碼試圖提供車身四周完整的3D視角視覺信息……如下圖：

圖七【Tesla transformer-41.png】來自Tesla AI day主題演講視頻截圖，URLhttps://www.youtube.com/watch?v=j0z4FweCy4M&t=4115s；

這個被叫做“Occupancy Tracker”的人工代碼被嵌入到Smart summon這個應用的Task head底部，完成從CNN backbone提取feature map后，需要參照車身攝像頭的幾何尺寸將其轉換到路徑規劃所需要的Birds-view map。

360度的俯視圖Birds-view map在大多數Level-2自動駕駛應用場景中，并非必要。但在更高等級的自動駕駛系統中，多傳感器數據處理結果（小編：同構或者異構傳感器都可以）終結在Birds-view map俯視圖結構上，并提供給后端路徑規劃，還是最合適的。人類構建的公路系統是嚴格符合“連續平面”屬性的，因此忽略高度信息的俯視圖在規劃中，比車載相機獲取的或略深度信息的投影平面，更能表現出道路上各種物體的相對位置關系。但問題在于如果路面拓撲過于復雜，且視覺傳感器會因為各種遮擋場景而只獲取部分信息，在這個基礎上，人工代碼往往力不從心。

對于上圖七的觀察我們就可以看到，在CNN backbone上增加Birds-view map獲取的“Occupancy Tracker”代碼Head之后，可以實現從camera視覺信息到俯視圖的轉換，但問題同樣明顯：

1 Karpathy標識這段代碼功能非常難以落地，具體表現為對于場景適應能力很差，可能在一部分場景下表現尚可，但一旦出現特殊的道路拓撲，就會失效；

2 精度問題。

上圖七左上角是Birds-view map的輸出結果，車輛左轉彎之后，前方兩側都出現大面積的無法識別狀態，右后側出現識別精度大誤差狀態（紅色線條重疊）。讀者可以想象，一旦車速增加、出現大面積的路邊遮擋物和道路拓撲劇烈改變等等，識別效果會進一步惡化。

圖八【Tesla transformer-42.png】來自Tesla AI day主題演講視頻截圖，URLhttps://www.youtube.com/watch?v=j0z4FweCy4M&t=4115s；

如果我們從smart summon應用再往前走一步，在所有道路條件下提供投影成像到Birds-view map的轉換，再從路緣石邊界（上圖紅色線條）擴展到對于車道線（上圖藍色箭頭）的識別和轉換視角，則之前的Occupancy tracker所面臨的問題會被進一步放大。圖八中，我們可以看到在camera投影視圖中的路緣石邊緣識別結果，因為天然在精度上的誤差，經由精確的幾何變換后，在俯視圖上的誤差得到進一步放大，甚至到會引發解讀歧義的問題：認真看投影視圖中的紅色線條，是對路緣石的一種近似的擬合結果。CNN Backbone的各種CNN識別結果，在單目鏡頭的視覺投影信息中，只能依賴CNN的對于人類智能模擬之后的近似。Camera不可能提供和Lidar等同的測量精度，Camera+CNN更多意義上的操作本質是“預測”。因此，建立在預測結果上，對于近似的預測結果進行“硬橋硬馬”的集合轉換，結果就只能是這個水平。

圖中的黃色和綠色箭頭所指位置，投影成像的線條近似，被轉換為以車輛攝像頭為圓心的圓弧段，沒錯，Occupancy Tracker認為線段上的每一個點，到攝像頭的距離都是一樣的…….由此，更新Occupancy Tracker代碼，使用同質的NN網絡來模擬人類的預測行為，來完成這個視場轉換任務，就是Autopilot識別堆棧的下一個核心重點了！

審核編輯 ：李倩