Apollo集中運行感知、決策、控制模塊，對資源、實時性、可靠性需求是不同的，對計算平臺、操作系統、運行環境的要求也各不相同。黃英君將這些模塊進行解耦，分布式集成運行在不同的計算平臺和操作系統上，即在一個高可靠的雙機備份低成本平臺上運行決策與控制模塊，在多個低成本高性能技術平臺上運行感知模塊，實現一個分布式可擴展的解決方案。

以前要搭建Apollo開發平臺的初期投入不菲，至少需要幾萬元。根據他提供的低成本方案，只需5000元左右（最新的價格是教育機構299美元），就能搭建起Apollo的開發平臺，大大降低了自動駕駛開發的門檻。（提示：目前還只是能夠部署，讓Apollo的所有模塊跑起來，還無法做到很流暢的實時的跑，這里有待大家一起去努力完善）。

以下是分享的全部內容。

作為一名普通的開發者，我在接觸Apollo幾個月的時間里，一直把Apollo作為學習的平臺和工具。

首先Apollo代碼更新很快，但是最近一次大規模的更新是在3月25日左右，后面幾天發現有十幾個到二十幾個文件在更新---建議大家每天早上上班之后先查看GitHub一下。

第一個值得關注的文件是perception_lowcost.sh，這個名字非常有意思，腳本內容如下：

1

run perception "$@"--flagfile=modules/perception/conf/perception_lowcost.conf

這個加載了一個配置文件，打開后發現：

1234567

#Camera node subnodes {   id: 3   name: "CameraProcessSubnode"   reserve: "device_id:camera;"   type: SUBNODE_IN }

上面這個subnode是新增加的攝像機節點；原來的配置文件中的兩個信號燈攝像機節點、激光雷達節點都沒有出現：

12345678910111213141516171819

 #TrafficLight Preprocess node.subnodes {  id: 41  name: "TLPreprocessorSubnode"  type: SUBNODE_IN } #TrafficLight process node.subnodes {  id: 42  name: "TLProcSubnode"  type: SUBNODE_OUT } #64-Lidar Input nodes.subnodes {  id: 1  name: "LidarProcessSubnode"  reserve: "device_id:velodyne64;"  type: SUBNODE_IN }

關于這幾個攝像機，我們可以在驅動目錄里面查看更詳細的信息：

2.0版本有兩個攝像機。打開目錄：pollomodulesdriversusb_camlaunch的start_leopard.launch文件，定義了三個攝像機。

123

"traffic_short_topic_name"fault="/apollo/sensor/camera/traffic/image_short" />"traffic_long_topic_name" default="/apollo/sensor/camera/traffic/image_long"/>"perception_obstacle"default="/apollo/perception/obstacle/camera" />

前兩個是用來針對交通信號燈的，第三個針對障礙物，推測這個攝像機就是用來檢測障礙物的。

打開源碼perception目錄，有一個camera目錄，這個目錄變化最大，也是開放代碼量最多的一個目錄，增加了車道線功能。我們是不是就可以得出結論，第三個攝像機將是執行障礙物檢測和車道線檢測。

綜上所述，最新版本的Apollo，特別強調低成本，具體的方式是在高速場景下弱化了弱化了激光雷達和兩個信號燈檢測攝像機，增加了一個攝像機，專門執行障礙物檢測和車道線檢測。這個變化跨度非常大，一個激光雷達的價格就是70多萬（64線），可以說是非常大的一個跨越。

另外說一句題外話，Apollo這個代碼寫的特別好，寫代碼的是很資深的架構師，所以Apollo這套代碼有非常濃重的谷歌風格，并使用了大量的谷歌系工具，看它的架構非常舒服的，可以作為一個經典的大型c++工程demo，來學習他的c++編程和大型項目的構建。為什么考慮對Apollo進行分布式擴展？

為什么考慮對Apollo進行分布式擴展？因為去年9月份我安排一個實習生，他開始做了幾天，就說目錄挺多，但是總裝不上。后來我發現坑越來越多，問題越來越多。

去年9月份我們訂購了PX2，但卻缺貨。后來代理商把他們自己的一塊給我們用了，左邊是Apollo推薦的計算平臺，是***一家公司的，這個工控機非常小巧和緊湊，它的散熱做得非常好，但是價格還是有點貴，而且訂貨周期比較長，還有就是PX2價格是十萬。

上圖是TX2，256個GPU核，一般性能好的計算機的開發環境對程序員非常友好，東西全，資料非常多，很快上手。最重要的是TX2非常便宜，教育用戶版不到三百美元，可以用它做臺式機做不了的事情，供應充足，我們公司用TX2做了非常漂亮緊湊的車載盒子。

其他還有一些性能、定位差不多的芯片，比如NXP，它在車企用的非常多，可靠性、安全性都很好。現在新推出的i.MX8性能穩定，是六核的架構，帶GPU，但也有供貨問題。它在車載和智能儀表領域的占有率非常高。

另一個是Renesas，一家汽車電子老牌廠家，在自動駕駛計算平臺占有一席之地。

為什么我要把它做成分布式的？分布式部署真正是由功能和性能決定的。我們把自動駕駛模塊劃分一下，有兩種分法。一種是Apollo分法，分成四個模塊：感知、規劃、決策和控制，另一種從性能區分，Sensor、Planning和Action。

現在智能駕駛計算平臺的現狀如何呢？目前沒有一個芯片、計算平臺、操作系統能夠同時滿足上述4個指標。

我們讓控制模塊跑在可靠的、安全的芯片上，但是滿足了安全條件，計算力就跟不上了。感知模塊要求強大的計算力，但是這種情況下再做安全，可能成本無法承受。所以最好的辦法就是讓合適的芯片運行合適的模塊，讓合適的操作系統來承載合適的模塊。

我們把Apollo的四個模塊拆分開，感知模塊可以跑在高性能的感知平臺上，控制模塊可以跑在高可靠性的操作系統上。

我們提出一個構想，把控制模塊跑在高可靠性的芯片上，感知模塊用低成本的處理器。即使一臺車要接十二個攝像機，一塊芯片不能用了，感知部分攝像機宕掉，問題也不大，車還在控制中。但是控制模塊出現問題就不行了。

我們增加了TX2對Docker的支持，使用JetPack3.1刷機。內核缺少containers運行所需的支持，這是我們定制刷新內核的文件，這些都是在網上公開的。編譯之后更新，然后重啟，重啟以后只要帶container就說明這個內核已經可以安裝到Apollo上了。

Docker onTegra本身有下面的問題：

?TX-2 or other Tegra devices 不支持nvidia-docker

? 使用JetPack3.1刷機，內核缺少containers 運行所需的支持

?JetPack3.2解決了這個問題（我還沒驗證）

?nvidia-docker wrapper在TX2上不能正常運行，無法獲取GPU設備

解決方法是：

?定制內核，增加對containers 的支持

?傳遞所需的參數給Docker，使之能夠獲取GPU設備

通過如上面幾幅圖中所述，增加TX2對docker的支持、定制內核配置文件、編譯內核、修改Apollo docker腳本后，Apollo docker中可以運行cuda程序了。

接下來編譯Apollo：

? 構建缺少的依賴庫：caffe(GPU版)，vtk，需要自己寫build文件，修改workspace配置文件；

? 重新編譯arm版本的依賴庫：QPSASES，IPopt，libfastcdr，libfastrtps；

? 重新編譯版本不一致的依賴庫：glog，gflags，protobuf；

? 修改Apollo中某些不兼容的代碼；

感知模塊Trafficlight中，caffe只提供了X86平臺動態庫，X86架構下SSE系列，arm平臺無法使用，要么改寫，要么直接跳過。

在Apollo中構建tensorRT，存在以下問題：

? docker內缺少一系列的庫；

? 缺少tx2相機驅動；

? 需要使用tegra定制的libGL.so；

? libgbm版本不匹配；

? 攝像機守護進程在主機端，docker內無法驅動；

解決辦法如下：

1、用掛載或者copy的形式準備好所需的動態庫，接近100多個；

12345678

cp host /var/nvidia/nvcam/settings -> dockercp host /var/nvidia/nvcam/input -> docker-v/usr/lib/aarch64-linux-gnu:/usr/lib/aarch64-linux-gnu:ro -v/usr/lib/aarch64-linux-gnu/gstreamer-1.0:/usr/lib/aarch64-linux-gnu/gstreamer-1.0:ro -v/usr/lib/aarch64-linux-gnu/tegra-egl:/usr/lib/aarch64-linux-gnu/tegra-egl:ro  -v/usr/lib/aarch64-linux-gnu/mesa-egl:/usr/lib/aarch64-linux-gnu/mesa-egl:ro   -v/run:/run:rw   -v/lib/firmware/tegra18x:/lib/firmware/tegra18x:ro    

2、使用libdrm-2.4.80以上版本重新編譯；

3、為tegra版本libGL.so建立軟連接；

4、修改主機配置，讓攝像機守護進程在docker內啟動；

構建tensorRT完成后，就可以在Apollo Docker中運行tensorRT，實現12-14幀的多目標檢測。

為大家說一下我們的階段性成果，目前已發布部分資源供測試：

?Apollo docker on TX-2的完整鏡像；

?使用不同操作系統重刷Jetpack時會遇到編譯錯，這里提供完整的內核源碼，無需自行下載并執行xconfig；

? 一些需要在arm下單獨編譯的庫；

?修改的Apollo的docker腳本文件；

? 基于Bazel構建的cuda應用程序開發模板

后續我們將做的工作有：

• 解決ROS跨版本通信問題

• 全面使用Nvidia Visionworks對圖像操作進行改寫

• 使用TensorRT對深度學習相關的功能模塊進行inference優化

• 對其他車載計算平臺的測試和驗證

• 針對QNX的移植適配工作

• 車載嵌入式設備的封裝

到2018年5月份，我們會提出專門針對ADAS的QNX開發包。如果說可以解決ROS跨版本通信的問題，那么我們把Apollo往QNX發展是可行的。