上周，我們舉辦了一次課程直播《Apollo「雲+端」研發迭代新模式實戰》，著重為大家介紹了Apollo數據開放平臺與訓練平臺實戰，下面是此次課程的全部內容，錯過直播的開發者可以通過此篇文章了解詳細乾貨！
大家好，我是來自百度自動駕駛事業部的楊凡。這次公開課分享的主要內容包括幾個部分。
首先我會對百度Apollo進行簡要介紹；接著幫助大家了解本機演示方式的實戰以及車輛與循跡自動駕駛能力的實戰；之後是本次公開課的核心部分，障礙物識別和路徑規劃能力的實戰。在此基礎上，我們會介紹雲端訓練平臺訓練紅綠燈感知能力，這是使用雲端算法來加強自動駕駛能力的實戰；最後簡要介紹用雲端仿真能力來完成驗證實戰。
在最開始，先向大家介紹一下百度做自動駕駛的背景：
百度總裁COO陸奇在開發者大會上講的，相信不少朋友已經了解到了——百度已經是一家AI公司。我們可以看到科技大潮的演進，已經從命令行、客戶伺服器、網際網路、移動網際網路一路走來，進入了AI時代。
在百度AI開放生態戰略中，體系分成雲和端，支撐的雲技術是智能雲和百度大腦，而端的輸出就是自動駕駛Apollo生態和喚醒外物的DuerOS生態。
Apollo生態是百度AI重要的、最先落地的生態之一。
Apollo作為百度推出的一個開放、完整、安全的自動駕駛平臺。在Apollo中，首先，我們把多年積累的自動駕駛能力有序地開放出來；在這個基礎上，我們會在生態中，與大家一起共享資源，另一方面開發者們也可以在這個平臺上分享自己的資源，因為分享越多，收穫也就越多。通過開放能力和共享資源的方式，可以有效加速自動駕駛整體性的創新，最後實現共贏。
開放的框架是學術界、科技界、產業界的共同需求，Apollo技術框架由4層構成，分別為：
· Reference Vehicle Platform
· Reference Hardware Platform
· Open Software Platform
· Cloud Service Platform
各層各模塊的基本介紹：
具體來講，首先我們需要一輛能夠接收電子信號控制的車輛——線控車，我們會與很多車廠及Tier1共同推進這一層。
Reference Hardware層，想讓車輛具備自動駕駛能力，我們需要計算單元、GPS/IMU、Camera、雷射雷達、毫米波雷達、人際交互設備、BlackBox等硬體的支持。
開放軟體層，分為三個子層：實時的作業系統、承載所有模塊的框架層、RTOS。高精地圖與定位告訴車輛身在何處，感知模塊告知車輛周圍環境，決策規劃模塊決定全局與細節規劃。控制模塊負責將決策規劃產出的軌跡生成為具體的控制命令。
百度自動駕駛在雲端有非常強的能力。高精地圖在雲端計算集群中生產，模擬駕駛的仿真服務也在雲端，它加速了自動駕駛的研發效率。我們積累了大量的數據和對數據的理解，並且在雲端數據平臺中開放出來，使得數據研發的閉環可以在雲端來完成。同時在雲端還有我們的安全和OTA服務。
百度智能駕駛事業群組總經理李震宇提到，低成本低功耗一定是自動駕駛平臺所追求的目標，但其實在從實驗室走入量產產品這個過程中，安全最重要，百度首要解決的一定是安全問題。
Apollo 2.0新開放的模塊包括了Security、Camera、Radar和Black Box，這意味著Apollo平臺包括雲端服務、服務平臺、參考硬體平臺以及參考車輛平臺在內的四大模塊已全部點亮。Apollo 2.0新開放的安全和OTA升級服務，只允許正確和被保護的數據進入車內，並進一步強化了自定位、感知、規劃決策和雲端方陣等能力。其中Black Box模塊包括了軟體和硬體系統，能夠實現安全存儲和大容量數據集傳輸，可以幫助我們及時發現異常情況，提升整個平臺的安全可靠性。
硬體方面，增加兩個前向攝像頭（長焦+短焦）主要用於識別紅綠燈，正前方保險槓上方新安裝了毫米波雷達。所以很明顯，在Apollo 2.0開放了Camera和Radar的模塊後，整個平臺更強調了傳感器融合的能力，已進一步增加其對晝夜簡單城市道路工況的適應能力。
（百度Apollo無人車在春晚）
就在剛剛過去的春節，熟悉自動駕駛的朋友很有可能已經注意到，春晚上在京港澳大橋上的那幕精彩的表演！實際上大橋有坡度，而且車輛非常密集，行駛方式更是非常特殊，其實這對自動駕駛來說是很高的挑戰。
基於Apollo技術，我們高效地完成了春晚演出任務，給全國人們呈現了一幕科技與技術的設宴。通過完整的框架，開發者很快就可以開發迭代出具有特色的自動駕駛能力。
首先介紹一下Apollo的目錄結構。
通過一目了然的目錄我們可以看到一些功能模塊，如Docs、Modules。這裡挑幾個重點介紹，Modules是整個Apollo所有模塊的位置；Scripts包括一些常用的操作工具腳本；Third-party涉及到一些官方庫，Tools則包含一些工具。
在Modules中，可以看到Apollo的各個主要模塊。
Apollo採用base class和class factory架構，具有新模塊、新功能的拓展能力。
Apollo主要模塊間的關係如圖所示。
首先，由HD-Map支持的Localization模塊產生地圖和定位信息，整個系統都以高精地圖和定位信息為基礎；
接著，感知模塊完成障礙物和紅綠燈的識別；
預測模塊基於感知結果做障礙物的行為預測；
Planning模塊根據障礙物預測的結果和Routing模塊的信息做Trajectory決策規劃；
Control模塊根據Planning的結果通過Canbus模塊控制車輛行駛。
Apollo系統是基於ROS平臺的。ROS是大家在機器人領域非常熟悉的平臺，我們達成了深入合作來降低開發者的門檻。ROS的特點主要包括完整的開發工具包，完整的計算調度模型，還有眾多的調試工具及已有的軟體系統等。為了增強ROS在自動駕駛方面的能力，Apollo做了多項定製優化，如果在真實車輛上測試自動駕駛，建議開發者使用Apollo平臺提供的ROS版本。
ROS的通信是基於ROS Topic的，Apollo主要的ROS Topic如圖所示。開發者可以使用ROS原生工具查看調試Apollo。
我們先演示一下沒有實際的整車，也可以了解驗證Apollo的離線演示方式。
Apollo的作業系統是Ubuntu 14.04.3（實際車輛，推薦更換Apollo內核）；推薦開發者Fork並clone github.com/ApolloAuto/apollo，方便後續修改；並使用Apollo工具安裝並進入Apollo Docker容器。
bash docker/scripts/install_docker.sh
# 退出並重新登錄，這樣可以非sudo運行Docker
docker ps # 確認Docker可以非sudo運行
bash docker/scripts/dev_start.sh –C #啟動並使用中國鏡像加速
bash docker/scripts/dev_into.sh
在Docker容器內編譯並啟動Demo：
bash apollo.sh build
rosbag play docs/demo_guide/demo.bag --loop
打開Chrome瀏覽器，在地址欄輸入 localhost:8888 即可訪問Apollo。至此，就可以在瀏覽器上看到Apollo的DreamView演示。
接下來我們介紹車輛與循跡駕駛能力實戰，這個步驟可以驗證線控車和軟硬體集成的基礎能力，也就是Apollo1.0的能力。如上圖所示，車輛循跡主要依靠的就是定位能力和控制能力。
如我們Apollo架構中介紹的，最底層的是Apollo1.0的車輛平臺，需要由車廠來完成線控改裝。
在車輛平臺上需要完成硬體設備的安裝以及工控機配置，具體的安裝方式可見Apollo的安裝指南。
在車輛和硬體平臺之上，Apollo提供相應的軟體能力支持，比如制動、動力、轉向控制以及一些信息交互。
開發者可以通過Vehicle接口來增加自己的車輛：
· 實現新車控制器
· 實現新消息管理器
· 在工廠類中註冊新車
· 更新配置文件: canbus/conf/canbus_conf.pb.txt
可參考：
【https://github.com/ApolloAuto/apollo/blob/master/docs/howto/how_to_add_a_new_vehicle.md】
隨後通過CAN Card接口增加車輛：
· 實現新CAN卡類CanClient
· 在工廠類CanClientFactory中註冊新CAN卡
· 更新配置文件: canbus/proto/can_card_parameter.proto
然後通過Control Algorithm接口增加車輛：
· 創建一個控制器
· 在control_config文件，為新控制器添加配置
· 註冊新控制器
在車輛的基礎上，Apollo提供高精的定位能力，具體可以參考我們的論文和隨後的課程，在此就不展開介紹了。
之後通過GPS Receiver接口增加車輛：
· 繼承Parse類，實現新GPS接收機的數據解析
· 在Parse類為新GPS接收機增加新接口
· 在配置文件config.proto，增加新GPS接收機的數據格式
· 為data_parser.cpp中方法 create_parser，增加新接收機的實現邏輯
完成上述步驟後，就可以試著啟動循跡自動駕駛了：
· 錄製
在Quick Record下，單擊Setup以啟動所有模塊並執行硬體運行狀況檢查。如果硬體健康檢查通過，單擊 Start 按鈕開始記錄驅動程序軌跡。到達目的地後，點擊Stop 按鈕停止錄製。
· 執行
在Quick Play下，單擊 Setup 啟動所有模塊並執行硬體運行狀況檢查。確保駕駛員準備好了！ 點擊 Start按鈕開始自動駕駛。到達目的地後，點擊 Stop 按鈕停止重放錄製的軌跡。
（Apollo 1.0演示）
在這一系列工作完成後，就完成了Apollo1.0的自動駕駛能力。可以看到，經過高精定位能力的輸出，實際上循跡自動駕駛可以完成非常精準的動作，兩車可以非常精準的交錯行駛。
接下來，我們介紹感知和規劃能力實戰。通過加入Perception、Prediction、Planning模塊的邏輯，Apollo車輛可以實現城市道路的自動駕駛能力。
Apollo支持多種傳感器，Camera、Radar、LiDAR各有所長，分別有各自使用的場景，Apollo通過傳感器融合架構實現較好的感知效果。
首先是關於攝像頭、雷達和雷射雷達的關係。每一種傳感器的特性都既有長處也有短板。例如Camera對於障礙物分類有很好的表現，但如果想對障礙物速度做準確判斷，其實是很困難的。
對於Radar來說，障礙物有很多距離以及速度，特別是在極端分析的情況下，它的穿透力會非常好，但對於障礙物的分類能力，Radar能力相對弱一些。
關於雷射雷達，因為是通過主動發射能量，依靠回波來檢測，所以對於判斷障礙物的遠近，例如暗光條件下障礙物的狀態有非常大的好處。但在一些極遠距離的探測上，可能表現也不是那麼完美。
所以，我們要把所有這些傳感器融合在一起，發揮各自檢測所長。
為了有效使用多個傳感器，我們需要對車輛上的傳感器完成標定。因為我們在車輛安裝時，很難把安裝做到極精密，所以通過標定來了解安裝的具體誤差，然後計算來補償。
對於感知模塊，可以用在Object detection、Object classification、Semantic parsing、Object tracking中，我們在Apollo 1.5中開放了點雲檢測算法，在2.0中我們增加了視覺方案"紅綠燈感知識別"，能在距離路口100多米外識別紅綠燈。
我們以3D障礙物檢測為例，介紹感知的流程。
基於LiDAR的3D障礙物感知，其好處是可以不分晝夜並連續檢測。我們在框架中使用深度學習，這樣就可以很精準地識別一些傳統規則並解決很多疑難問題；我們使用NVIDIA GPU，這樣可以把巨大運算負載放在GPU上完成，從而高效率的進行感知處理。
為了識別一個障礙物，主要步驟是通過高精地圖配置一個ROI過濾器，過濾出我們認為有效的的數據；接著把特徵值計算出來，通過CNN來完成每個區域的Segmentation，這樣就可以有效地識別出物體；再通過MinBox，完成障礙物邊框的構建；最後，通過HM對象跟蹤就可以感知到障礙物的軌跡，計算速度。
多傳感器融合，依賴於Perception fusion DAG框架。如上圖所示，通過構造算法subnode，並且通過DAG描述連接到一起，開發者就可以完成定製的多傳感器感知和融合。
如圖所示，Planning Structure由ReferenceLine、HD-Map 、EM Planner等幾部分構成。其中Em Planner，主要分 Traffic Decider、DP Path、Path Decider、Speed Decider、QP Path和QP Speed 六部分。
通過DP路徑算法，我們將求解過程離散化。
好處是受道路中心線影響低；成本函數形式不單一，適應複雜路況；天然適合併行化。解決了decision 的基於規則優化的痛點。
另一方面，這一步DP算法的結果，並不完美，不是最優解，銜接點處形式固定，雖然平滑但路線較為僵硬，複雜情況處理不夠平滑。
如上圖所示，通過一樣的DP邏輯，我們可以完成s,t，坐標系下的DP規劃。在此基礎上，進一步做QP優化和迭代調整，就可以得到有效的Planning結果。
創建一個新的Planner，然後將新的Planner配置添加到modules/planning/conf/planning_config.pb.txt文件中，最後在Planning.cc中註冊一個新的Planner。
智能自動駕駛汽車需要一顆聰明的車載大腦。我們在自己的研發中一路探索過來，智能汽車的「雲+端」研發迭代新模式是我們對於加速自動駕駛汽車研發效率提出的解決辦法。
我們在車輛上積累了海量的數據，把這些積累的數據用雲端的伺服器集群高效地生成人工智慧的模型，也就是車輛大腦。把汽車大腦更新到車輛上，就為車輛賦予了自動駕駛的能力。
自動駕駛數據可以分為四大類：
自動駕駛車輛產生的數據首先是原始數據，主要是傳感器數據、車輛自身數據和駕駛行為數據等。這些數據的特點是數據量極大、類型多樣、以非結構化和半結構化數據為主，無論對於存儲、傳輸，還是處理都構成了比較大的挑戰。
為了在深度學習中使用數據，我們還需要大量標註數據。主要有紅綠燈數據集、障礙物數據集（2D、3D）、語義分割數據集、自由空間數據集和行為預測數據集等。
為了刻畫自動駕駛行為，我們還需要將數據抽象成邏輯數據。主要是完美感知數據、環境抽象數據、車輛動力學模型等。
最後，我們會用仿真構建仿真數據，主要是參數模糊化數據、三維重建數據、互動行為數據等。
數據平臺是我們支撐智能汽車的「雲+端」研發迭代新模式的核心平臺。由數據採集與傳輸、自動駕駛數據倉庫、自動駕駛計算平臺三個部分構成。
首先是數據採集與傳輸部分。使用Data-Recorder會按Apollo數據規範產生完整的、精確記錄的數據包，可以完成問題復現，同時也可以完成數據積累。通過傳輸接口，可以將數據高效地傳輸到運營點和雲集群中。
接著是自動駕駛數據倉庫部分，會將全部海量數據成體系地組織在一起，快速搜索，靈活使用，為數據流水線和各業務應用提供數據支撐。
最後是自動駕駛計算平臺部分，基於雲資源異構計算硬體提供超強算力，通過細粒度容器調度提供多種計算模型，來支撐起各業務應用，如訓練平臺、仿真平臺、車輛標定平臺等其他平臺。
Apollo開放了6個標註數據集：
· 雷射點雲障礙物檢測分類
提供三維點雲標註數據，標註四類障礙物：行人、機動車、非機動車及其他，可用於障礙物檢測和分類算法的研發和評測。
· 紅綠燈檢測
提供了常見的豎式紅綠燈圖像數據，採集時段為白天，採集天氣覆蓋晴天、陰天和霧天，解析度為1080P。
· Road Hackers
本數據集有兩種主要類型數據，街景圖像和車輛運動狀態。街景圖像提供車前圖像，車輛運動狀態數據則包括車輛的當前速度和軌跡曲率。
· 基於圖像的障礙物檢測分類
數據採集涵蓋城市道路和高速場景，由人工標註出四大類障礙物：機動車、非機動車、行人及靜態障礙物，可用於視覺障礙物檢測識別算法的研發和評測。
· 障礙物軌跡預測
採樣數據來源於多源傳感器的綜合抽象特徵，每組數據提供62維車輛和道路相關信息，可用於障礙物行為預測算法的研發和評測。
· 場景解析
數據包括了上萬幀的高解析度RGB視頻和與其對應的逐像素語義標註，同時，提供了具有語義分割測量級別的稠密點雲、緊急情況的立體視頻以及立體全景圖像。
此外，我們還開放了ApolloScape數據集，目前規劃到20萬幀級別，在3月8日已經開放了第一批，有8萬幀的數據集，是用相機以及掃描的一個場景，而且還是用點集的標記。
ApolloScape對整個學術界都會有比較大的幫助，已經公開的數據中無論是數據本身還是質量都有一些特色。我們還跟會在近期發布一些，希望大家也能參與到整個算法中來。【數據集下載：請訪問http://apolloscape.auto】
我們還通過Apollo訓練平臺為每一個數據集提供配套的計算能力。Apollo訓練平臺的特色是：
· 通過Docker+GPU集群，提供與車端一致的硬體計算能力。
· 集成多種框架，提供完整的深度學習解決方案。
· 通過交互式可視化結果分析，方便算法調試優化。
我們在自動駕駛的算法開發中，最大的痛點之一就是需要對海量數據集，反覆嘗試。我們通過將深度學習算法的研發流程(開發、訓練、驗證、調試)在雲端實現，可以在充分利用雲端大量計算資源的同時，將數據的流動僅在雲端的伺服器內完成，從而大幅提高算法研發效率。
具體來說，首先開發者在本地開發機中基於Docker開發算法，並部署依賴環境。接著將開發好的環境推到雲端的私有Docker Repository中。
接下來在平臺上挑選數據集，發起訓練任務。Apollo訓練平臺的雲計算調度就會將任務調度到計算集群上執行。這個過程中，在雲集群的內部，開發者的程序使用數據獲取接口，從而獲得自動駕駛數據倉庫中的數據集。
最終由業務管理框架將執行過程、評估的結果和Model返回給可視化平臺，完成可視化的調試。
我們的Demo中提供了作者原本的Caffe版，以及Paddle版。
首先，可以看到仿真場景數據集。
仿真場景數據包括人工編輯以及真實採集的場景，覆蓋多種路型、障礙物類型以及道路環境，同時開放雲端仿真平臺，支持算法模塊在多場景中並發在線驗證，加速算法迭代速度。
點擊兩個仿真數據集下的「立即使用」按鈕，可以進入到仿真場景數據集詳情頁。
在打開的仿真平臺中，可以以默認Apollo模塊運行仿真場景，也可以提交自己的模塊運行仿真場景。Apollo仿真的具體使用，會有單獨分享，這裡由於時間關係就不再具體展開了。
歡迎大家進一步關注官網 apollo.auto 和 GitHub 獲取最新信息。也可以關注「Apollo 開發者社區」公眾號，關注最新進展。謝謝大家！
以上就是本次直播課程分享的全內容，點擊【閱讀原文】可觀看課程視頻。此外，我們已將直播中大家的留言提問整理匯總。後續我們會在Apollo開發者社群中分享更多課程內容，如果你還沒有加入Apollo開發者社群，請在公眾號右下角菜單欄-互動交流-交流社群中添加Apollo開發者社區小助手，帶你找到組織！
Q & A
問題1
Q：搭建Apollo環境，帶Docker容器，需要多大的硬碟容量？
A：硬碟容量30G可以滿足安裝需要，但是Apollo鏡像會隨代碼迭代發布，容量更大效果更佳。
問題2
Q：Caffe部分是黑盒？
A：Apollo在感知部分用到了Caffe框架，但是因為對框架有部分改動，目前我們只提供訓練好的模型。
問題3
Q：在車輛實測中如果掉網了，還能繼續開嗎？
A：目前我們更多的處理邏輯均是在本地進行的，對網絡的依賴較少。如果是因為網絡連接的問題，我們會做緊急靠邊停車處理。
問題4
Q：有沒有更簡單的測試方法，一個新算法，是否要跑通所有測試機才能認定可用？
A：為了確保一個新算法的能夠達到適配的效果，最好是在完成仿真測試與實際的路跑測試，才可以說算法可用，但覆蓋的case還需要不斷收集不斷測試。
問題5
Q：自動駕駛和手動駕駛怎麼實現切換的？
A：進入自動駕駛：設置導航信息中，然後點擊「Start Auto」即可進入自動駕駛狀態； 當車輛進入自動駕駛狀態，駕駛員可以通過轉動方向盤、踩下剎車等方式接管，進入人工手動駕駛狀態。
問題6
Q：「雲+端」的自動駕駛研發迭代模式是百度首創嗎？未來還有哪些方面需要改進提升？
A：「雲」在網際網路產品中是非常常見的一種模式，也是百度最擅長的領域；另一方面，百度在國內乃至世界自動駕駛開放平臺一直保持著前沿的探索。基於兩方面深厚的積累「雲+端」對於百度來說是水到渠成的研發迭代模式。我們也注意到許多先進的自動駕駛公司，也不約而同地選擇了這樣的研發迭代模式。我們很高興能把我們高效的研發迭代模式與生態分享，一同推動技術進步。
問題 7
Q：雲端和車體的之間的交互需要實時嗎？
A：這個需要看是什麼模塊的數據，更多的請求是在本地處理的，如果用到與雲端的請求交互，可以考慮異步預加載的方式。