Apollo集中運(yùn)行感知、決策、控制模塊，對(duì)資源、實(shí)時(shí)性、可靠性需求是不同的，對(duì)計(jì)算平臺(tái)、操作系統(tǒng)、運(yùn)行環(huán)境的要求也各不相同。黃英君將這些模塊進(jìn)行解耦，分布式集成運(yùn)行在不同的計(jì)算平臺(tái)和操作系統(tǒng)上，即在一個(gè)高可靠的雙機(jī)備份低成本平臺(tái)上運(yùn)行決策與控制模塊，在多個(gè)低成本高性能技術(shù)平臺(tái)上運(yùn)行感知模塊，實(shí)現(xiàn)一個(gè)分布式可擴(kuò)展的解決方案。

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

以下是分享的全部?jī)?nèi)容。

作為一名普通的開發(fā)者，我在接觸Apollo幾個(gè)月的時(shí)間里，一直把Apollo作為學(xué)習(xí)的平臺(tái)和工具。

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

第一個(gè)值得關(guān)注的文件是perception_lowcost.sh，這個(gè)名字非常有意思，腳本內(nèi)容如下：

1

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

這個(gè)加載了一個(gè)配置文件，打開后發(fā)現(xiàn)：

1234567

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

上面這個(gè)subnode是新增加的攝像機(jī)節(jié)點(diǎn)；原來的配置文件中的兩個(gè)信號(hào)燈攝像機(jī)節(jié)點(diǎn)、激光雷達(dá)節(jié)點(diǎn)都沒有出現(xiàn)：

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 }

關(guān)于這幾個(gè)攝像機(jī)，我們可以在驅(qū)動(dòng)目錄里面查看更詳細(xì)的信息：

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

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" />

前兩個(gè)是用來針對(duì)交通信號(hào)燈的，第三個(gè)針對(duì)障礙物，推測(cè)這個(gè)攝像機(jī)就是用來檢測(cè)障礙物的。

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

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

另外說一句題外話，Apollo這個(gè)代碼寫的特別好，寫代碼的是很資深的架構(gòu)師，所以Apollo這套代碼有非常濃重的谷歌風(fēng)格，并使用了大量的谷歌系工具，看它的架構(gòu)非常舒服的，可以作為一個(gè)經(jīng)典的大型c++工程demo，來學(xué)習(xí)他的c++編程和大型項(xiàng)目的構(gòu)建。為什么考慮對(duì)Apollo進(jìn)行分布式擴(kuò)展？

為什么考慮對(duì)Apollo進(jìn)行分布式擴(kuò)展？因?yàn)槿ツ?月份我安排一個(gè)實(shí)習(xí)生，他開始做了幾天，就說目錄挺多，但是總裝不上。后來我發(fā)現(xiàn)坑越來越多，問題越來越多。

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

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

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

另一個(gè)是Renesas，一家汽車電子老牌廠家，在自動(dòng)駕駛計(jì)算平臺(tái)占有一席之地。

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

現(xiàn)在智能駕駛計(jì)算平臺(tái)的現(xiàn)狀如何呢？目前沒有一個(gè)芯片、計(jì)算平臺(tái)、操作系統(tǒng)能夠同時(shí)滿足上述4個(gè)指標(biāo)。

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

我們把Apollo的四個(gè)模塊拆分開，感知模塊可以跑在高性能的感知平臺(tái)上，控制模塊可以跑在高可靠性的操作系統(tǒng)上。

我們提出一個(gè)構(gòu)想，把控制模塊跑在高可靠性的芯片上，感知模塊用低成本的處理器。即使一臺(tái)車要接十二個(gè)攝像機(jī)，一塊芯片不能用了，感知部分?jǐn)z像機(jī)宕掉，問題也不大，車還在控制中。但是控制模塊出現(xiàn)問題就不行了。

我們?cè)黾恿薚X2對(duì)Docker的支持，使用JetPack3.1刷機(jī)。內(nèi)核缺少containers運(yùn)行所需的支持，這是我們定制刷新內(nèi)核的文件，這些都是在網(wǎng)上公開的。編譯之后更新，然后重啟，重啟以后只要帶container就說明這個(gè)內(nèi)核已經(jīng)可以安裝到Apollo上了。

Docker onTegra本身有下面的問題：

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

? 使用JetPack3.1刷機(jī)，內(nèi)核缺少containers 運(yùn)行所需的支持

?JetPack3.2解決了這個(gè)問題（我還沒驗(yàn)證）

?nvidia-docker wrapper在TX2上不能正常運(yùn)行，無法獲取GPU設(shè)備

解決方法是：

?定制內(nèi)核，增加對(duì)containers 的支持

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

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

接下來編譯Apollo：

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

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

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

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

感知模塊Trafficlight中，caffe只提供了X86平臺(tái)動(dòng)態(tài)庫，X86架構(gòu)下SSE系列，arm平臺(tái)無法使用，要么改寫，要么直接跳過。

在Apollo中構(gòu)建tensorRT，存在以下問題：

? docker內(nèi)缺少一系列的庫；

? 缺少tx2相機(jī)驅(qū)動(dòng)；

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

? libgbm版本不匹配；

? 攝像機(jī)守護(hù)進(jìn)程在主機(jī)端，docker內(nèi)無法驅(qū)動(dòng)；

解決辦法如下：

1、用掛載或者copy的形式準(zhǔn)備好所需的動(dòng)態(tài)庫，接近100多個(gè)；

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、修改主機(jī)配置，讓攝像機(jī)守護(hù)進(jìn)程在docker內(nèi)啟動(dòng)；

構(gòu)建tensorRT完成后，就可以在Apollo Docker中運(yùn)行tensorRT，實(shí)現(xiàn)12-14幀的多目標(biāo)檢測(cè)。

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

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

?使用不同操作系統(tǒng)重刷Jetpack時(shí)會(huì)遇到編譯錯(cuò)，這里提供完整的內(nèi)核源碼，無需自行下載并執(zhí)行xconfig；

? 一些需要在arm下單獨(dú)編譯的庫；

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

? 基于Bazel構(gòu)建的cuda應(yīng)用程序開發(fā)模板

后續(xù)我們將做的工作有：

• 解決ROS跨版本通信問題

• 全面使用Nvidia Visionworks對(duì)圖像操作進(jìn)行改寫

• 使用TensorRT對(duì)深度學(xué)習(xí)相關(guān)的功能模塊進(jìn)行inference優(yōu)化

• 對(duì)其他車載計(jì)算平臺(tái)的測(cè)試和驗(yàn)證

• 針對(duì)QNX的移植適配工作

• 車載嵌入式設(shè)備的封裝

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