自動駕駛 Apollo 原始碼分析系列，感知篇(一)

我是自動駕駛從業者，百度的 Apollo 是行業優秀的開源框架，近幾年發展的比較快，基於對技術的熱愛，我計劃用 3 個月的樣子來學習 Apollo 的原始碼，以提升自己的自動駕駛認知和技術。

在 Apollo 官網它有顯示自己開放平臺的架構，我關注於演算法及程式碼實現。

自動駕駛公認的分層架構是：

• 感知
• 決策
• 控制
• 執行

所以，系列文章我先從感知模組開始。

當前 Apollo 版本是 6.0，所以這一系列文章都是 Apollo 6.0。

百度 Apollo 是基於 Lidar 的，這個需要明白這一點。

即使在當前，一款機械式的鐳射雷達也要 10 多萬出頭，儀器比車貴，所以我認為 Apollo 的方案大規模和普通使用者見面還需要硬體領域的發展和成本優化，這需要整個行業的努力。

當然，如果 L4 面向政府、大型企業，高昂的感測器成本是可以通過運營持續的收入承接的，用鐳射雷達也沒有什麼問題。

高階車用鐳射雷達也沒有什麼問題。

現實是普通大眾還是很在乎成本的，據我瞭解到 Apollo 也在摸索純視覺的方案，如果真的成熟了成本會急劇下降。

感測器

講感知不能不提到機器視覺，但視覺不僅僅包括攝像頭，還包括其它的感測器。

Apollo 有 360 度感知能力，因為它配備了下面的感測器：

• 前視攝像頭 2 個(6mm 焦距 1 個，12mm 焦距 1 個)
• 毫米波雷達 2 個(前向、後向)
• 鐳射雷達 3個(128 線 1 個，16 線前後向各1個)

感知的目的

我們在學習原始碼的時候，最好的方式就是先了解這個東西是幹嗎用的。

Apollo 的感知目的就是 2 個：

• 障礙物檢測(車、行人或者其它交通要素)
• 紅綠燈檢測

藉助於鐳射雷達和深度學習，Apollo 的感知模組能夠輸出障礙物的 3D 資訊。

感知融合

自動駕駛靠單一的感測器不滿足安全冗餘的要求，所以自動駕駛的解決方案都會進行多感測器的融合。

Apollo 的感知模組需要接收感測器資訊及自車速度資訊，經過內部演算法處理最終輸出障礙物的 3D 軌跡和交通燈探測結果。

其中，3D 障礙物軌跡其實就是融合的體現。

camera

開啟原始碼中 camera 的目錄

從程式碼目錄中可以看到 camera 主要任務有 4 個：

• 障礙物感知
• 車道檢測
• 交通燈檢測
• 障礙物和車道檢測基礎上計算出來的 CIPV(closest in-path vehicle)

Radar

相比於 Camera，Radar 的任務單一，它只處理障礙物的檢測。

Lidar

Lidar 的感知主要是處理點雲資料，Apollo 6.0 會應用 PointPillar 模型得到障礙物的 3D 資訊,也就是能得到障礙物的 3D 尺寸框加上速度和偏航角資訊。

Lidar 輸出的資訊送到 Fusion 元件和 Camera 、Radar 的結果進行融合，形成最終的 3D 障礙物跟蹤軌跡。

Fusion

感知模組的核心應該是融合.

不同的自動駕駛場景要求的感測器不一樣，也許是純視覺方案，也許是鐳射雷達為主，也許是視覺+毫米波雷達，但無論感測器怎麼配置，多感測器的融合也必不可少。

融合的好壞決定了感知的好壞，甚至是一款自動駕駛產品的好壞。

所以，建議每一位關注自動駕駛感知的同學都要建立自己的感測器融合能力。

從程式碼目錄上看，Apollo 要融合的東西大概這 5 樣：

• 目標存在可能性的融合
• 目標運動狀態的融合
• 目標形狀的融合
• 目標軌跡融合
• 目標的類別融合

後續

我在瀏覽 Apollo 的程式碼是，確實感受到了工程的龐大，然後很多程式碼運用了很多設計模式的技巧，物件導向和多型封裝的思想。

程式設計師應該加強程式碼的這種高度抽象和封裝的能力，但同時我還是喜歡簡單的程式碼，因為越簡單越容易理解。

後續的文章，我將從 camera 講起，之後 radar，然後 Lidar，然後 fusion，可能 fusion 我會花的時間更多點，因為我對它更感興趣。