在自動駕駛技術中，軟體系統是最具有技術壁壘的領域之一。近年來，國内外成立了不少自動駕駛創業公司，花費了大量人力物力投入到自動駕駛軟體系統的開發中，每一行代碼、每一個專利，都是它們未來競争的底氣和資本。可以說，自動駕駛軟體系統是上述公司最核心的資産之一。
百度是國内最早投入自動駕駛技術研發的公司之一。Apollo是百度釋出的向汽車行業及自動駕駛領域合作夥伴提供的軟體平台，不僅在全球各種權威自動駕駛榜單中成績斐然，也在商業化推進上有着驚人的速度。下圖是Apollo開源項目的系統架構。
圖1. Apollo 6.0 Architecture
圖檔來源：Apollo項目GitHub位址https://github.com/ApolloAuto/apollo
簡單解析一下Apollo架構。
其中，Open Software Platform指的是Apollo開源軟體平台，它是圖中位于右側的各個子子產品的總稱。RTOS（real-time operating system）是實時作業系統，實時性是它的最大特征，它為上層功能子產品的高效執行提供底層環境。
Map Engine是地圖引擎，在軟體中負責擷取各類地圖資料，并提供相應的地圖資料功能接口。Localization和Perception分别是定位和感覺子產品，是處理汽車周圍環境資訊的功能子產品，負責将各類傳感器收集到的資料進行加工和處理，用結構化的結果來描述汽車周圍的場景。Planning是規劃子產品，負責對結構化的場景資訊進行下一步的處理，通過計算得到一條安全可通行的路徑。Control是控制子產品，負責把規劃的結果轉換成對電子油門、電子刹車和電子轉向的控制信号，最終實作對車輛運動的控制。
這其中，感覺子產品需要對大量的傳感器資料進行實時處理，需要準确且高效地識别場景資訊，是以是最有工程挑戰的子子產品之一。
下圖是Apollo開源項目的感覺架構圖，可以看到整個感覺部分的結構是比較複雜的，多條資料處理路線并行展開，每一個節點子子產品都會涉及到很多算法處理，同時，這些路線之間還會有互相的資料交換，最後，綜合處理多條路線的結果得到感覺子產品的輸出。
圖2. Apollo 6.0版本感覺架構圖
下文将簡單地剖析一下感覺子產品的架構，從資料流動的次元講述感覺子產品是如何運作的。
我們先從簡單的模型入手，把感覺子產品拆分成資料輸入、資料處理、資料輸出三個部分，再分别對每個部分進行深入探讨。
圖3. 感覺子產品資料流動簡圖
資料輸入過程
首先是資料輸入端。資料輸入主要包括雷射雷達、車載相機、毫米波雷達（以下分别簡稱Lidar、Camera、Radar）等傳感器的場景資料采集，以及從車輛底盤擷取自車信号（速度、加速度、轉向等）。此外，感覺還會依賴到高精地圖等資訊。
下面主要探讨Lidar和Camera的資料輸入過程。
Lidar資料輸入
Lidar的工作原理，是通過雷射照射到物體表面接收到反射光，進而計算反射點相對發射器的空間坐标。不論是哪種類型、哪個廠家的Lidar，最終輸出的資料本質上都是大量反射點的資訊集合。這些空間中大量的反射點集合在一起就是我們經常稱呼的點雲（point cloud）。
圖4. 點雲可視化圖像
圖檔來源：Velodyne官網 https://velodynelidar.com/
上圖是将Lidar點雲可視化以後的結果，為了直覺，圖中用了顔色梯度來表示點的距離。Lidar裝置端口發出來的原始資料并不是我們在圖中看到的這樣，感覺子產品需要對原始資料進行處理才能得到合适的資料形式。
這裡先介紹一下點的描述參數。如下圖所示，單個反射點的資訊主要包括空間資訊、時間戳和反射強度。其中，由于Lidar的工作原理不同，機械旋轉式Lidar通常會使用徑向距離（radius）、俯仰角（elevation）、方位角（azimuth）來表示點的空間位置，而半固态/固态Lidar，通常使用笛卡爾坐标系下xyz來表示點的空間位置。
圖5. Lidar反射點的資訊
雖然不同的Lidar裝置廠家描述點雲的資料形式不同，發送出來的格式不同，但究其本質都是對點雲的資料描述。是以，各大廠商的Lidar發送出來的資料結構都是類似的。在此，我們以Velodyne 16線Lidar為例講述。
下圖所示是Velodyne 16線Lidar在單回波模式下發送的資料結構。每一個區域裡都存放着固定位元組大小的資料，整個區域組成了資料包（Data Block）。每個Data Block裡面包括了Head（資料頭部區域），Data（點雲資料存放區）和Tail（資料尾部區域，有些Lidar硬體不發送尾部資料域）。Head和Tail裡面通常存儲一些用來通信校驗的資料以及Lidar的自身工作狀态參數等，Data域裡包含很多Channel域，每一個Channel裡存放着一個點的資訊。固定數量的點雲資料整齊而緊密地排列在一起，組成了中間的Data域。最後打包成的Data Block是一塊Bytes大小固定的資料區。
圖6. Velodyne 16線Lidar發送的資料包結構示意圖
圖檔來源：Velodyne官網
Lidar的工作模式有單回波和雙回波之分。簡單來講，Lidar發射出來的雷射束是有面積的，打在物體表面的是一小片區域，如果雷射束剛好打在了物體邊界，那麼就會有一部分留在近處的物體上，另一部分觸碰到更遠的物體，這時一個發射信号就會有兩個回波信号，這就是雙回波原理。在單回波模式下，可以選擇光強高或低，距離近或遠的回波。而通常情況下，雙回波模式的資料大多都是重複的，是以，一般都會選擇讓Lidar在單回波模式下工作，并選擇光強高&距離近的回波作為原資料。
在資料發送方式上，有些Lidar廠商選用網線連接配接工控機，基于UDP傳輸協定（User Datagram Protocol）發送Lidar硬體打包好的Data Block。
圖7. Lidar資料發送機制
UDP是一個無連接配接協定，傳輸資料之前的源端和終端不建立連接配接，不維護連接配接狀态以及收發狀态，也就是說，在UDP方式下Lidar裝置隻需要單方面發送資料，并不需要考慮通信是否成功。選擇這樣的發送方式可以保證Lidar向下遊的發送不間斷、無延遲，在提高發送效率的同時，也保證了Lidar硬體和下遊系統的獨立性。
通過這種方式，Lidar裝置将打包好的點雲資料發送出去，下遊系統通過預先設定好的通信協定接收資料并進入點雲資料的處理流程。
Camera資料輸入
首先介紹一下圖像資料。
以RGB圖像為例，一張圖像是由紅綠藍三種顔色通道疊加而成的（見下圖）。在一個通道内使用數字來表示顔色，比如在紅通道中用8位bit來表示紅色，也就是用十進制下的0～255（28=256）來表示紅色。如果一張照片的像素是1280*960，那麼這張照片的紅色通道（R通道）就是1280*960大小的數字矩陣，矩陣中每個位置上都填寫着0～255的數字。再結合綠色和藍色通道，這張RGB圖像就可以用1280*960*3大小的數字矩陣來表示。
圖8. RGB圖像結構
圖檔來源：https://www.geeksforgeeks.org/matlab-rgb-image-representation/
接來下，講述一下Camera資料的輸入過程。
車載相機主要由鏡頭、感光傳感器和圖像信号處理器（ISP）組成。其中感光傳感器主要是用CMOS，它的作用是将場景的光信号（模拟信号）轉換成對應的電信号。接下來，電信号再通過ADC（模數轉換器）轉化成數字信号輸送給ISP，在ISP上進行圖像處理（自動曝光、自動白平衡、自動對焦、暗角修複等），處理完成後通過标準的SCCB總線（I2C總線）接口和外部進行通信，輸出RGB格式（或YUV格式）的圖像。
一般情況下，需要驅動（driver）來控制CMOS模組工作，相機廠商一般會把開發好的驅動提供給使用者。将driver部署在自動駕駛平台的軟體端，就可以控制外接CMOS模組的工作狀态了。通過調用相機廠商提供的API（application programming interface，應用程式接口），感覺子產品可以通路這些原始圖像資料，這樣，Camera資料就傳入了感覺子產品中。整個過程可以用下圖簡單表示。
圖9. Camera輸出圖像的流程
Lidar資料擁有豐富的空間資訊，而圖像資料擁有着物體幾何、色彩紋理的特征。
下圖十厘清楚地展示了三類傳感器之間的優劣勢。Camera在物體分類和車道線檢測中表現較好，但是在惡劣天氣、弱光條件下表現不佳；Lidar在物體檢測和弱光條件下的性能較好，但是在車道檢測上表現較差；Radar在惡劣天氣和弱光條件下表現較好，但是在物體分類和車道線檢測上表現不行。使用多種傳感器資料，根據它們各自的工作特點，優勢互補，可以使整體資料在多個衡量緯度上表現優異，提高對場景的資料表示性和資料魯棒性。
圖10 .各類傳感器資料對比
圖檔來源：Apollo開發者中心
接下來，傳感器将大量的原始資料傳輸給下遊，由感覺子產品依靠豐富的算法手段進行進一步處理。
資料處理過程
從上遊擷取到感覺子產品需要的資料以後，感覺子產品就需要對這些資料進行處理。參考Apollo開源項目的感覺架構圖，我們可以看到Lidar、Camera、Radar的資料是先分成三條線路處理的，然後再把各條路線的資料進行融合，得到最終的輸出。
簡單來講，可以分為傳感器資料預處理、檢測、跟蹤和融合。
預處理子產品
預處理子產品主要是将從上遊接收到點雲和圖像資料進一步轉化成算法需要的形式。
首先是點雲的預先處理。把上遊發送來的Data Block去除Head和Tail以後，按照定長位元組讀取，就可以獲得每一個點的中繼資料，通過空間變換可以計算出點相對Lidar裝置的空間坐标xyz，之後再把坐标、時間戳、強度等資訊存儲在特定的資料域或結構體中。最後，把Lidar完整走完一周的資料放入集合中作為一幀點雲資料。使用可視化工具或開源庫（例如PCL，https://pointclouds.org）就會呈現出類似圖3的點雲圖。
對圖像的預處理主要包括對圖像的剪裁、圖檔灰階處理、縮放、資料增強等操作，這一步的目的是适配神經網絡輸入資料的尺寸和形式，同時也減少了輸入神經網絡的資料量，進而減少計算資源占用。
預處理子產品都是對于各類傳感器資料的簡單處理，占用計算資源較少，實作過程也比較容易。
物體檢測子產品
點雲資料帶有明确的空間位置資訊，工程師們通常使用它來檢測車輛、行人、路側欄杆等物體。點雲資料的檢測可以依賴傳統算法和深度學習網絡。傳統的障礙物點雲檢測算法，依靠點雲的幾何特征，通過分割聚類等方法輸出障礙物；深度學習算法則是通過對标注的障礙物點雲進行模型訓練，再使用模型檢測實際場景點雲資料。實際工程中可以僅使用深度學習算法，也可以将傳統算法和深度學習算法結合運用。
圖11. 點雲檢測
圖檔來源：waymo在CVPR 2020的報告
對于圖像資料，工程師們主要依靠深度學習的方法來處理。自動駕駛公司大都會選擇自主開發檢測模型，通過訓練标注好資料的真值圖像，調整神經網絡的結構和參數，以達到最優的檢測結果。
圖12. 圖像檢測
圖檔來源：Tesla AI Day 2021
物體檢測是最具工程挑戰的部分之一。在車輛高速行駛的過程中，如果錯誤地檢測了某個障礙物體，會導緻錯誤的車輛控制，最終可能帶來非常嚴重的後果。如何快速且準确地識别障礙物是一項極具挑戰的任務。
傳統的計算機視覺算法（Harris角點檢測、SIFT算法、SURF算法、ORB算法等）相比于深度學習算法，檢測速度慢、準确率低，很難滿足大多數場景下自動駕駛的需求。此外，這些傳統的視覺算法都需要對圖像提取特征，換句話說就是，對資料在更高、更多的次元上尋找特點，提取特征的過程通常比較複雜。相比于深度學習這種從端到端的算法，傳統的視覺算法難以開發，不具優勢。深度學習算法的應用，極大地加速了物體檢測領域的發展，同時，這也對深度學習算法廣泛應用于自動駕駛技術，起到了至關重要的作用。
深度學習算法确實有很多優點，但同時其輸出結果是機率分布式的，不能保證檢測的完全準确性。在今天，這種端到端算法的中間過程仍然是不可解釋的，大家無法解釋為什麼輸入一張照片，就會在它的某個區域内檢測到某個物體。而傳統的視覺算法卻具有成熟的理論支撐、透明的中間過程和穩定的性能。
筆者比較看好傳統計算機視覺算法和深度學習算法兩者結合，可以充分利用兩種方法的優勢。
圖13. Tesla檢測模型架構
自動駕駛公司一般都會花費大量力氣投入到檢測模型的開發中。同樣，網上也有很多開源的圖像檢測模型和點雲檢測模型，為學者、工程師們提供一些開發支援。
Lidar和Camera的物體檢測，雖然資料輸入端不同，但是通過神經網絡後，輸出的檢測物體都具有同樣的資料結構。其中主要包括被檢測物體的類型、ID、包圍框（bounding box，框頂點集合，2D或3D形式）、橫縱向距離、速度、加速度、置信度等等。當然，不同類型的被檢測物體也會存在不一樣的描述特征，比如紅綠燈類型的障礙物就需要顔色資訊，車道線類型的物體不是輸出包圍框，而是輸出若幹個車道線上的關鍵點（通過連接配接這些點構成完整的車道線）。
圖14. 檢測子產品輸出資料結構示例
跟蹤子產品
在單幀資料中檢測到我們關注的物體後，我們仍然需要知道障礙物（車輛、行人）是如何運動的，場景中障礙物的運動資訊（軌迹、速度變化等）對于後面預測這些障礙物運動軌迹和控制自車運動至關重要。想要得到障礙物的曆史運動狀态，就需要一些曆史幀資訊，從連貫的曆史幀資訊（例如，研究從曆史第10幀到目前幀這一段連續時序過程）中挖掘出物體的運動狀态。
通常使用的方法是，分析前後幀内檢測到的同一障礙物。如果上一幀出現的物體在下一幀也出現了，那麼前後幀内出現的同一個物體可以用相同的ID來表示，并把檢測結果按照時間序列存儲，這樣就得到了某物體在兩幀時間内的運動狀态，包括速度變化、位置變化、方向變化等等。在連續幀内不斷使用上述過程，就能得到物體的曆史運動狀态。以上就是一個跟蹤過程。
那麼工程師們是如何确認前後幀中的同一個物體呢？通常情況下，是使用ROI（前後幀内物體包圍框的交并比）這一名額來比對。以圖14為例，在T時刻檢測到了A和B兩個障礙物，在T+1時刻檢測到了C、D和E三個障礙物。其中包圍框（bounding box）可以表示被檢測物體在圖中的位置。根據bounding box的位置，很容易發現A與C的重疊度很大，B與E的重疊度也很大，那麼就有理由相信，在這連續的兩個時刻内，A與C，B與E都分别代表了同一個物體。
當然，這種方法成立有一個前提，一般在10幀率的檢測過程中，也就是0.1s内，被檢測物體的運動位置變化不是足夠大，這樣才能有前後幀bounding box的重疊度，才能用來衡量比對過程。
圖15. 基于IOU的比對過程
在跟蹤子產品，通常使用的方法有卡爾曼濾波和匈牙利比對算法。第一步，使用卡爾曼濾波階段一對上一幀物體進行運動估計，估計出其目前時刻的位置和速度。接下來，使用匈牙利算法對上一步中運動估計出的物體和目前幀檢測到的物體進行比對，匈牙利算法中使用的比對權重就可以結合上面所講的IOU方法來設計，成功比對代表跟蹤成功。第三步，通過卡爾曼濾波階段二更新被跟蹤物體目前的最優位置和最優速度。
圖16. 典型的跟蹤疊代過程
此外，還有使用神經網絡直接檢測障礙物并輸出跟蹤結果的方法，也就是說，跟蹤過程也是在神經網絡中完成的。這種方法需要使用連續幀資料訓練網絡，在使用該類神經網絡時，輸入端就是連續幀的圖像或點雲，輸出端仍然是一系列被檢測到的物體，額外的資訊是這些物體已經具有了被跟蹤的屬性，在時間序列上，同一個物體具有同一個跟蹤識别ID。在網上，很容易能找到一些開源的跟蹤網絡模型。
融合子產品
目前，自動駕駛技術需要使用多種傳感器，并對這些不同傳感器資料進行處理，最終輸出單一結果，這就涉及到資料融合。融合又可以分為前融合和後融合，它們的差別在于，融合過程是在檢測和跟蹤過程之前還是之後。在Apollo感覺軟體架構中，融合過程位于不同傳感器資料跟蹤處理之後，是一個典型的後融合過程。整個過程就是将Lidar、Camera、Radar三條處理路線輸出的追蹤結果進行融合，修正被追蹤物體的各項參數資料。
舉個簡單的例子，假設Lidar、Camera、Radar三種傳感器的時間已經同步，對于同一幀内的被檢測物體A來說，使用Lidar資料檢測出了結果a1，使用Camera資料檢測出了結果a2，使用Radar資料檢測出了結果a3，融合過程就是在這三個結果中，通過一定的政策得到最優的檢測結果。
這裡的融合政策會綜合考慮各類傳感器的優劣勢，比如Lidar在測距方面的表現性能更好，那麼對于距離或者空間位置的參數，就會更傾向于選擇通過Lidar資料得到的結果。對于交通标志、紅綠燈、車道線這類物體，後融合的過程會更傾向于選擇通過Camera資料得到的結果。基于這樣的考量，就可以将多類傳感器資料的感覺結果進行融合，進而得到最優解。
另一種前融合的方式是，在資料輸入端就将Lidar、Camera等資料組合起來，形成一種新的資料體，這個資料裡既有圖像紋理、顔色這樣的資訊，同時也包含了3D空間中的距離資訊，這種資料結構加強了不同傳感器資料之間的資料關聯性。
圖17. Lidar和Radar資料的前融合邏輯
圖檔來源：優達學城無人駕駛工程師學位
上圖簡單介紹了Lidar和Radar資料融合的邏輯。在首次擷取資料時，先初始化Kalman濾波器的各個矩陣參數，接下來對兩類資料進行預測和更新，最後輸出融合後障礙物的位置、速度。[1][2]
圖18. 資料前融合的步驟
圖檔來源：智行者科技
上圖簡單介紹了智行者科技在傳感器資料前融合過程中的步驟，包括了采集及預處理、坐标轉換和資訊融合。其中最有難度的部分就是資訊融合，它包括了資料關聯、時間同步、資料融合、目标生命周期管理四個步驟。首先是在資料關聯階段，建立評價名額并選擇全局最近鄰比對方法；第二步對多傳感器進行時間同步，選用了固定時漂和随機時漂的方法； 第三步，使用粒子濾波算法融合資料;最後，對目标進行生命周期管理，提高融合後資料的魯棒性。
同樣地，通過标注前融合資料并訓練模型，可以得到适用于前融合資料的神經網絡，這種模型的輸出結果也是對同一物體的檢測結果，然後再進行物體跟蹤，不同的是，檢測跟蹤之後，不需要再次融合。
目前，很多主流公司都在朝着前融合的方式研究，這樣做的好處之一就是提前耦合了多種傳感器的資料，是以資料次元更加豐富，更能真實地反映場景。
資料輸出
在Apollo的感覺架構中，最終輸出到下遊的結果可以分為兩部分，一部分是車輛、行人等障礙物的資料，另一部分是交通信号燈的結果。場景中障礙物的資料可以通過上述的資料處理過程得到，而交通信号燈的結果則是通過一種多燈投票機制來得到的。簡單來講，就是在一個路口處，一般會有多個紅綠燈被檢測到，這其中既有紅燈又有綠燈，也有其他不同類型的燈（直行、左轉、掉頭等等），需要設計一種投票機制來決策目前直行、左轉或右轉的單一燈狀态。
圖19. 感覺輸出資料結構示例
原始的傳感器資料經過感覺子產品的處理，輸出的結果會傳遞到下遊預測子產品。預測子產品主要是針對車輛、行人這類障礙物，預測障礙物在未來一段時間内的運動軌迹。然後便進入了規劃子產品，結合場景資訊和障礙物預測軌迹，進行自車的路線規劃。
小結
從各類傳感器資料采集開始，到輸入到感覺子產品，再經過檢測、跟蹤、融合這些過程，最終向下遊輸出場景内的必要資訊。本文簡要地介紹了一下感覺子產品的資料流動。
當然，感覺子產品還會涉及很多其他功能，比如利用地圖資料增強感覺結果、自動錄入采集資料、功能監控和失效診斷等等。這些功能之間也存在着複雜的資料交換，在感覺子產品運作的過程中共同作用。
參考文章：
[1] 《開發者說丨手把手教你實作多傳感器融合技術》
[2] 《開發者說｜Apollo 6.0 Perception 子產品 Fusion 元件（二）：主體算法流程分析》
寫在最後
行業轉型交流群
交流轉型遇到的困難、分享轉型過程中的心得，可掃描右方二維碼添加從業人員微信，并提供一下名片和個人履歷，然後拉您入群。
注：加微信時務必備注您的真實姓名、公司、現崗位
以及意向崗位等資訊，謝謝！
關于投稿
如果您有興趣給《九章智駕》投稿（“知識積累整理”類型文章），請掃描右方二維碼，添加從業人員微信。
“知識積累”類稿件品質要求：
A：資訊密度高于絕大多數券商的絕大多數報告，不低于《九章智駕》的平均水準；
B：資訊要高度稀缺，需要80%以上的資訊是在其他媒體上看不到的，如果基于公開資訊，需要有特别牛逼的獨家觀點才行。多謝了解與支援。