1. 程式人生 > >乾貨曝光(三)| 資深架構師深度剖析:基於深度學習的End-to-End

乾貨曝光(三)| 資深架構師深度剖析:基於深度學習的End-to-End

origin: http://www.sohu.com/a/162012646_795622
2017-08-03 16:58 作業系統 /百度

7月22日,百度自動駕駛事業部資深架構師、資料平臺專家楊凡,百度自動駕駛資深架構師何瑋,百度智慧駕駛事業部資深架構師鬱浩三名講師在中關村創業大街車庫咖啡,向參加沙龍的三百多名開發者們深度解析了Apollo平臺與智慧駕駛方案。

前兩期,百度資深架構師楊凡為我們詳細講解了Apollo1.0開放內容及Apollo2.0展望,

回顧

資深架構師何瑋為我們重點講解了Apollo ROS的改進,

回顧

本期我們繼續曝光乾貨,由百度自動駕駛資深架構師鬱浩跟我們分享:

鬱浩講師:《基於深度學習的End-to-End自動駕駛方案》

鬱浩,百度智慧駕駛事業部資深架構師,無人駕駛演算法方向,重點關注基於深度學習的無人駕駛系統,從演算法到工程再到專案落地,擁有豐富的經驗。

基於深度學習(以 End-to-End 為主)的自動駕駛方興未艾。百度擁有超大規模的訓練資料,同時也在 CES Asia 上首次實車展示了這種自動駕駛。那麼它與傳統的規則式自動駕駛相比,有哪些區別和優劣勢?未來的發展將會如何?百度在這個方向都有哪些實踐?

一、Rule based系統

與End-to-End相對應的是傳統規則式的無人駕駛系統,它經歷了二三十年的研究和試跑過程,運用業界和學術界主流的Rule based系統,從車輛到控制形成閉環。

圍繞這個閉環,除Apollo1.0以外,還有很多人提出了相關的或類似的架構。如:美國的SAE部門,他們在上面閉環基礎上,細化出實時的、大環、小環和各個模組之間的關係。

並以此繼續細化,便得到更復雜的功能模組圖,但實際操作中會形成上千個模組。

|Rule base的特點:

1.系統複雜性,需要人工設計上千個模組。

2.高精地圖的成本,更新必須及時。

3.車載硬體計算能力,每個模組都要深度學習,車輛最多可能需要執行十幾個深度學習網路,對計算能力和消耗需求很大。

以上難度之大,已遠超一家公司的能力範圍,需要一個協作的生態(聯盟)共同完成。比如去年百度和MAP合作框架,到今年百度已經和整個生態的合作。

二、End-to-End

|人,如何駕駛?

人類駕駛不需要知道路面的每一個特點,不需要精確的位置,不需要精確知道車距,多數時間是靠下意識完成。人們在很多自然的行駛過程中可以邊打電話邊開車,但需要集中注意力和實時判斷,比如變道時要考慮前後車輛的情況、盲區等,依靠充分的深入判斷做出決策,這需要很高等的行為思考能力。End-to-End

系統更細化的是輸入原始的感測器資料。

|End-to-End歷史及現狀

1988年,已經有人開始嘗試使用End-to-End。但侷限於30×32畫素,還沒有CNN,這樣也能在簡單道路上實現自動駕駛。

2005年,LeCUN也做了無人駕駛探索。2015年,提出了中間狀態自動駕駛,無需生成各種複雜過程,只需要找出關鍵點生成決策控制。

2016年,在DAVE2基礎之上,提供相機、卷積網路,更關鍵的是實車上路——在美國的很多路上進行測試。並做比較突出共享、評估體系和三目相機採集End-to-End資料。

2016年至今,Comma.ai,Drive.ai,Auto X等都相機進行了探索。

自動駕駛領域出現的End-to-End風潮,在整個機器人領域同樣面臨著變化。如很多人都暢想過家庭機器人,但為何在推廣的時候有一個很大障礙?因為傳統規則式機器人需要地圖,我們不可能知道千千萬萬戶的使用地圖。但如果有End-to-End,先識別出一個家庭的情況,如何自己生成路線並執行End-to-End系統,這樣就大大降低機器人進入千家萬戶的成本。

|End-to-End現狀進行了總結

|功能、系統工程複雜度、演算法要求

人們開車的時候有兩類行為:一類可以邊打電話邊開車,我們稱之為Reactive control(無腦操作)。需要集中注意力做出判斷的,是Proactive planning。End-to-End系統到目前為止,主要實現了Reactive control,Proactive planning尚處於探索階段。每一個message背後其實都是一個複雜的系統,End-to-End大部分系統自己完成,演算法要求都很高。

|可解釋性

自動駕駛對安全性要求極高,必須做可解釋性的東西。很多公司不做End-to-End系統,主要原因是其不可解釋,而Rule based是可解釋的。但限制Rule based往前發展的恰恰就是面臨的不確定性因素,尤其是複雜環境。可解釋性不應該成為這兩個系統選擇或者是評比優劣的點,最終的評比應該是客觀的指標性的東西,比如能安全執行多少公里。

|廣鋪成本

Rule based廣鋪成本面臨的大問題是高精地圖,End-to-End目前還不需要高精地圖,普通導航系統即可。

|感測器成本

Rule based相對高一些,End-to-End相對低一些。並不是End-to-End系統需要的感測器少,而在於它對感測器的利用率高。以攝像頭為例,寶馬的自動駕駛方案中,前檔有3個攝像頭,周圍一圈又有不少,每個攝像頭都對應了Rule based系統中特定的功能。而End-to-End系統是用神經網路擬合,如不同的攝像頭中所需要的畫素級別的融合,可以自己用機器識別出,或者機器自己判斷和加工中所需要的過程,更高效的利用感測器。

|車載計算資源、核心問題、關係

車載計算資源的實踐差距非常大,Rule based的研發和廣鋪成本極高,而End-to-End系統核心問題主要在於資料,它的所有行為需要資料,而目前開源閉源都很難有優質的資料需要訓練。Rule based和End-to-End更像互補關係。對於普通的,需要在邊打電話邊開車的場合,End-to-End更適合;對於入口和街區,Rule based更靠譜。

三、Apollo實踐

1.資料

百度的地圖採集車每年採集數百萬公里的資料(影象資料及司機行為),通過這些資料訓練出的模型可以在不同駕駛環境下,實現近似駕駛。目前,End-to-End系統沒有明顯的主動路徑規劃,旁邊還是有車道線的總計可循。Apollo和長城汽車合作,用一個攝象頭做自動駕駛系統。場地設計時在兩端專門設計了一個比較急的彎,考驗車能否轉過來。實驗中汽車學會了人的行為,先減速,然後再右靠。這時候工作人員把交通標誌牌放在車道線上,自動駕駛車便識別出左拐標誌,然後做後續的行為。在本期Apollo開放計劃中,已經將實驗中使用的資料開源出來了,這些資料是目前為止百度擁有的非常寶貴的資產。

|當前業界和學界的資料分別是?

這些資料分兩類:真實資料和模擬器資料。

真實的資料,Udacity、Oxford、Comma.ai。主要有兩方面,一方面太少,另一方面是幾乎沒有中國國情資料。

模擬器資料,事實上模擬器資料幾乎不能用到真實的道路上,模擬器資料都是遊戲渲染出來的,其紋理和真實場景的紋理千差萬別。

Apollo的資料是通過地圖採集車得來的,符合中國國情。大家在街上應該經常能看到地圖採集車,上面裝有攝象頭、雷達,車內還有高精度GPS。在這麼多年地圖採集車採集資料中,其實沒有看資料,但之前是高精度的位置資料已經足夠了。

這次開放的資料主要摘取了前向資料,原始資料是比較高清的資料,從中截出正前方一小塊資料,頻率是8赫茲,除了影象資料,還會開源出採集車不是原生的原始座標,根據原始座標繁衍出一些行為出來。

百度地圖通過複雜的地圖工藝處理這些資料,最終會得到非常高精度的軌跡。

通過軌跡處理可以繁衍出橫向和縱向指令,比如知道了汽車拐彎半徑、曲率,進而推算出方向盤轉角等。在低速場景下是典型的Ackermann模型,但在訓練橫向指令時,用的還是曲率。曲率或轉彎半徑二分之一更普世,二分之一方向盤之間的轉化是車廠的業務,幾乎每一家車廠都能支援並執行二分之一指令。

|資料開源

資料的每一個檔案都對應著一次採集任務,一個檔案對應一個採集車影象和姿態。開源沒有開源出精準座標,而是根據座標繁衍出它的二分之一和縱向的指令。這兩個指令可以和車廠合作,從而實現上路。

2.模型

回顧2016年的模型,一個典型的基於CNN的迴歸任務。衡量指標一個是準確度,另一個則是用CNN做系統時,務必注意效能問題,保證計算率快,能夠達到精細的時間控制。根據之前實驗至少達到30赫茲,也就是網路必須在30毫秒以內產出結果發給車。

隨之而來的也需要我們思考兩個問題:一般的CNN只能學習到正常的駕駛行為,如何處理異常行為?不同採集車模型不一樣、其他的引數不一樣,如何將一輛車的經驗遷移到另外一輛車?

縱向模型,這是去年的模型,我們在探索的時間,一段實際的資訊,通過一段視訊對應到加速,但是目前還在研究階段。這個套路變成了視訊領域基本套路的問題,很多都可以拿來用,比如3D卷積,two—sdream等。

目前很多研究者或學者會把大多數精力放在精準預測上,但其實人們開車也不會預測出精準的運動,多數是判斷“有障礙即潛在危險”的因果判斷的關係。另外,還需要關注attention的問題,如何用注意力機制識別出交通標誌或者是紅綠燈等等。