前言
今天想來跟大家分享一下自駕車的 software stack 有哪些重要的 module，稍微探討一下各 module 的功能，然後加入一些我自己的想法跟評註。
這篇算是我自己學習過程的一個小記錄，也是未來更深入各 module 的一個定海神針。
最簡單的架構
用最直觀的方式來想像，我們都知道
- 自駕車需要看到周遭的環境，才不會亂開撞到人，所以需要 sensor，來看到外面的環境
- 但只是看到周遭的環境，卻不能理解這個環境，是沒有用的，所以需要 Perception module，辨識 sensor 資訊中的車、行人、和各種物體
- 好了，但自駕車如果不知道自己在什麼地方，又怎麼能規劃出通往目的地的路徑呢？所以我們需要地圖，自駕車就能比對周圍的環境跟地圖，來定位自己在世界中的位置
- 知道自己的位置之後，就能計算要怎麼到達目的地，產生一個從起點抵達目的地的路徑，這部分就由 Motion Planning module 來搞定
- 有了路徑，讚！但下一個問題是，汽車只接受油門、煞車和方向盤的指令，要踩多少油門、煞車跟怎麼轉方向盤，才能符合 motion planning 規劃出的路徑呢？這就是 Controller module 要做的事
- 下達油門、煞車跟方向盤指令後，他會對應到的速度跟角度變化是多少，每一輛車都不盡相同，所以 Actuation module 負責處理這邊的轉換
- 最後，在現實世界中，任何 module 都有可能出錯，我們要怎麼掌握系統的狀態呢？這就需要一個 System Supervisor 來監督
有了上面這一串簡單直觀的理解之後，我們就可以把上面複雜的說明，簡化成下面這張架構圖：
Case Study - 百度 Apollo
上面介紹了基本的重要 module，接下來就讓我們來看看百度 Apollo 的軟體架構，驗證一下有沒有漏掉什麼重要的 module。
他們的架構已經演進了很多代，方便起見，我們直接來看最新的 5.5 代：
因為今天只討論 software，所以我們看 Open Software Platform 那層就好，扣除掉 HMI（Human-Machine Interface），基本上我們只漏掉 Prediction module。
上面之所以會漏掉 Prediction Module，是因為我們沒有考慮環境的動態性，假設今天環境裡面的人、車、各種物體都不會動，那我們確實不需要 prediction，但因為環境是動態的，所以我們需要預測其他人、車、各種物體會怎麼移動，才能在 motion planning 時，規劃出不會撞到這些移動物的路徑。
你可能會想問，難道不能就一直即時地做 perception，然後趕快反應嗎？當然是可以，可是這樣就大幅增加了危險性，畢竟，採取各種 action 都需要時間，不能看到要撞到其他物體了才趕快反應，這麼做的風險太大了，相信你開車也不敢不透過各種方式預判其他人的行為。
實際應用 - Zoox's AV（Autonomous Vehicle） Stack
Zoox 是一間在矽谷的自駕車新創公司，前陣子才剛被 Amazon 收購，相對於其他公司，他們在今年釋出了三支比較完整的道路實測影片，所以我以他們為 case 來討論，三支影片的場景分別是在
擁擠的 San Francisco 市區
道路線道較多、且有更多觀光飯店的 Las Vegas
環境較單純、但車速較快的高速公路（從 Menlo Park 開到 Downtown San Francisco）
其中令我驚艷的地方有幾個：
他們在這幾個場景中使用的是同一個 software stack，並不會因為場景的不同切換成特別不同的模式。有做過產品的人都知道，一個產品根據 scenario 不同，有不同的參數是常有的事，但這種參數間的切換，常常也是引發演算法不連續性的原因，而這種不連續性在自駕車這種有高度安全考量的應用中，就是一種很大的風險。雖然我沒有做過自駕車的產品，不知道只用同一個 software stack 的難度大不大，但我覺得至少他們有這種意識是正確的。
在 San Francisco 市區有很多複雜的情況，例如併排停車、逆向的自行車、非常窄的路等等，這些場景都考驗各 module 夠不夠 robust。
在 Las Vegas 的影片中，他們的自駕車能夠在非常複雜的飯店接送區 navigate，可惜沒有呈現實際接送乘客的場景。
總結
上面我們簡單討論了自駕車的 software stack，這是我自己喜歡的學習方式，先從大綱著手，之後探討細節才容易抓到重點，不會見樹不見林。如果你對自駕車有深入的了解、或有什麼想更了解的東西，都歡迎在下方留言指教！
