所在位置:首頁 -- 數據庫 -- 正文

基于Spark與ROS分布式無人駕駛模擬平臺


發布時間:2017-4-1  來源:admin

 本文是無人駕駛技術系列的第四篇,著重介紹基于Spark與ROS的分布式無人駕駛模擬平臺。無人駕駛的安全性和可靠性是通過海量的功能和性能測試來保證的。無人駕駛系統是一個復雜的系統工程,在它的整個研發流程中,測試工作至關重要同時也繁重復雜。顯然將全部測試工作都集中在真車上進行是一種成本異常高昂且安全系數非常低的方案。通過綜合考慮測試中各種可能發生的正常或異常狀況,軟件模擬成為了面向無人駕駛系統的更安全且更經濟有效的替代測試手段。

無人駕駛模擬技術

無人車駕駛系統由感知、預測、決策、控制等眾多功能模塊組成,每個模塊都各自擁有復雜的結構和算法。絕大部分情況下,系統開發人員在測試過程中很難對海量的輸出參數作評價。同時,開發人員不僅需要單獨測試一個功能模塊,也需要集合聯調多個模塊。因此,系統開發人員所需要的模擬器必須能夠直觀正確地反映出輸出參數的意義,同時還要既能對各個模塊進行單一的測試,又能將各個模塊按照不同需求組合后進行集成測試。

模擬器技術主要有兩種:第一種是基于合成數據對環境、感知以及車輛進行模擬,這種模擬器主要用于控制與規劃算法的初步開發上;第二種是基于真實數據的回放以測試無人駕駛不同部件的功能及性能。在本文中,我們主要討論基于數據回放的模擬器。

出于需盡量真實地模擬真車環境的需求,我們的模擬器采用了和真車相同的機器人操作系統ROS。ROS是一種基于消息傳遞通信的分布式計算框架。這種框架方便開發人員進行模塊化編程,這一特性對于模擬器來說至關重要。在無人駕駛系統中,每一個功能模塊在ROS中都部署在一個節點上,節點間的通信依靠事先定義好格式的message完成。在模擬器中開發人員只需要使用相同的通信格式,針對每個功能模塊制作模擬模塊,然后根據測試需求搭配真實功能模塊和模擬模塊。例如,如果想進行決策模塊和控制模塊的功能聯調,我們需要將決策模塊、控制模塊搭配其他的模擬模塊,安裝到模擬器中進行測試。如果決策模塊需要單獨測試新的決策算法,我們可以只將新的決策模塊搭配其他的模擬模塊安裝到模擬器上,這樣的測試結果就是只針對決策模塊的。

模擬器的組成元素

首先,無人駕駛汽車模擬器中包含了車的動態模型,用來加載測試無人車駕駛系統,并模擬無人駕駛汽車自身的行為。其次,需要模擬的是外部環境,包括靜態和動態的場景。靜態場景中包括各種靜態的交通標志,例如停止線、交通指示牌等;動態場景主要指車周圍的動態交通流模型,例如車輛、行人、交通燈等。所有這些元素構建了與現實環境相對應的模擬世界。

模擬器的應用

無人駕駛汽車真實上路后所要面臨的外部環境是復雜多變的。模擬器在模擬測試中需要做的就是將復雜的外部環境拆解成最簡單的元素,然后重新排列組合,生成各種測試用例。

圖1 模擬器應用

拿一組簡單的測試用例舉例。圖1是一個簡單的直線行駛的車道,需要測試的是無人駕駛汽車對于一輛障礙車的反應。按照障礙車可能出現的起始位置劃分,它可能出現于無人駕駛汽車的左前、左中、左后、前、后、右前、右中、右后總計八個位置。按照障礙車和無人駕駛汽車的相對速度,可分為比無人駕駛汽車快、和無人駕駛汽車速度相等以及比無人駕駛汽車慢三類。按照障礙車的行為劃分則分為直行、向左變道和向右變道三種。將這些變量相乘,再去掉其中不需要的個例,就得到了一組我們需要的測試用例。

模擬器面臨的問題

模擬器的核心問題在于“真”上,人工模擬的場景和真實場景多少會有差異,真實場景中仍然會存在許多令人想象不到的突發事件。因此,如果能采用真實的行車數據復現真實場景,就會得到比人工模擬的場景更好的測試效果。但采用真實數據復現的方案帶來的問題就是海量數據的處理。如果我們想在模擬器上復現真實世界中每一段道路的場景,就需要讓無人駕駛汽車去采集每一段道路的信息,這些海量的信息是單機無法處理的,而且在每個場景下拆解元素重新排列組合生成測試用例的做法會使計算量翻倍。因此,將模擬器搭載到分布式系統上就成為了無人駕駛模擬測試的最佳選擇。

基于ROS的無人駕駛模擬器

ROS是一種基于消息傳遞通信的分布式計算框架。它的通信模式可以抽象為一種message pool架構,消息發送節點調用advertise方法向指定Topic發送ROS message,消息接收節點調用subscribe方法從指定Topic接收ROS message。

ROSBAG

Rosbag是利用這一架構從Topic中錄制并且向Topic中重新播放ROS message的工具,無人駕駛汽車在數據采集過程中使用的正是Rosbag。它的功能主要分為Record和Play兩類。Record功能是在ROS中建立一個record節點,調用subscribe方法向所有或指定Topic接收ROS message,然后將message寫入Bag文件。Play功能則是在ROS中建立一個play節點,調用advertise方法將bag中message按照時間節點發送至指定Topic。圖2展示了一個LiDAR數據在ROS中回放的實例,在這個場景中,LiDAR數據是以10Hz幀率記錄的。

圖2 ROS BAG LiDAR數據回放

Rosbag生成的數據格式是Bag,這是一個擁有兩層邏輯結構的文件格式。如圖3所示,上層的Bag類對上抽象提供了用戶操作文件的方法,對下封裝了對ChunkedFile的操作方法;ChunkedFile類主要對數據進行了分隔存儲,而存儲的數據為一條條ROS message,不僅包含文字信息,也包含大量的二進制數據,后者主要是無人駕駛汽車傳感器發送的圖片或3D點云文件數據。這就給傳統的主要用來處理文字日志的分布式計算系統應用帶來了新挑戰。

圖3 ROS BAG 結構圖

模擬測試數據集

如前所述,我們主要關注基于真實數據回放的模擬器,數據量有多大呢?以來自真實世界的KITTI數據集為例(由KIT和TTIC在2012年啟動的一個合作項目,網站為http://www.cvlibs.net/datasets/kitti/,更詳細的介紹請參見《程序員》2016年7月刊《基于計算機視覺的無人駕駛感知系統》),KITTI的研究人員錄制了6個小時的真實數據,數據量為720GB。但是6小時的數據僅夠完成一些算法的簡單驗證,無人駕駛產品所需求的數據量遠大于此。比如谷歌的無人車在過去幾年中收集了超過40000小時的真實數據,總數據量估計超過了5PB。如此大量的數據,基于單機的模擬遠不能支撐其處理,所以我們必須為基于真實數據回放的模擬器設計一個高效的分布式計算平臺。

計算量的挑戰

巨大的數據處理量對計算平臺造成很大的壓力。例如,KITTI數據整集6小時的原數據包括了超過1000000張140萬像素的彩圖,如果使用單機的基于深度學習的圖像識別平臺,每張彩圖分析時間大概是0.3秒。這樣,僅是分析KITTI數據集的圖片,就需要超過100小時,而如果分析谷歌無人車級別的整體圖片數據,在單機處理上就需要超過60萬個小時。

基于Spark的分布式模擬平臺

Spark是UC Berkeley AMPLab開源的通用并行計算框架。Spark基于內存實現的分布式計算,擁有Hadoop所具有的優點;但不同于Hadoop,Spark Job的中間輸出和結果可以保存在內存中,從而不再需要讀寫HDFS,因此Spark能更好地應用于需要迭代的Map-Reduce算法。

圖4 分布式模擬平臺總體架構

如圖4所示,為了高效地進行無人駕駛回放模擬,我們設計了基于Spark的分布式模擬平臺框架。我們使用Spark進行資源的分配管理、數據的讀寫以及ROS的節點管理。在Spark Driver上,我們可以觸發不同的模擬應用,比如基于LiDAR的定位、基于圖片的物體識別、車輛決策與控制等。Spark Driver會根據數據量與計算量等需求請求Spark worker資源。每個Spark worker首先會把Rosbag數據讀入內存,然后通過pipe啟動ROS Node進程進行計算。我們也可以使用JNI方式連接Spark worker以及ROS Node,但這將涉及對ROS的修改,使得整個系統難以維護與迭代。經過權衡之后,我們最終選擇了pipe的設計方案。

在pipe的設計方案中,有兩個問題需要解決:第一,Spark本身支持讀取文本數據,但并不支持多媒體數據讀取,我們需要設計一個高效的二進制文件讀取方法。第二,Rosbag的play功能如何從內存中讀取緩存的數據,record功能如何將數據緩存至內存中。以下我們將討論這些設計。

二進制文件流式管道處理

Spark操作數據的核心是彈性分布式數據集(RDD),它允許程序員以一種容錯的方式在一個大型集群上執行內存計算。百度美國研發中心之前的一個工作就是在這一數據結構的基礎上引入了新的RDD來實現二進制文件流式管道處理。其結構如圖5所示(關于這個設計的細節請參考《程序員》2016年1月刊《基于Spark的百度圖搜變現系統架構》)。

圖5 BinPiped RDD的總體設計和主要功能

在每一個Spark的worker上,worker根據Binpiped RDD的信息通過標準輸入流在內存中將數據傳送給用戶程序,用戶程序處理完數據后通過標準輸出流在內存中將數據傳回給Spark的worker。worker將數據匯集存儲到HDFS上。

Rosbag緩存數據讀取

在當前使用場景下(如圖6),我們的輸入是一定量的Bag二進制文件,以某種形式存儲在分布式文件系統上面,而用戶想要的輸出是所有這些Bag文件在每一個worker上回放信息進入模擬器后經過處理得到的數據,顯然這一過程通過Rosbag的play和record功能最易實現。

圖6 模擬器在分布式平臺的運作流程

圖7 MemoryChunkedFile設計

不過這一過程中還存在缺失的環節,即Rosbag的play功能如何從內存中讀取緩存的數據,以及record功能如何將數據緩存至內存中。為了實現這一功能,我們為原來的Bag和ChunkedFile的兩層邏輯結構增加了一個分支邏輯層。如圖7所示,MemoryChunkedFile類繼承于ChunkedFile類并且重寫了ChunkedFile所有的方法。MemoryChunkedFile在向下層讀寫文件時是向內存讀寫數據,而不是像ChunkedFile類一樣向硬盤讀寫數據。這樣做的一個好處就是worker通過標準輸入流傳給模擬器的數據不用經過磁盤I/O讀寫就可以被直接讀入,經過模擬器處理的數據也不用經過磁盤I/O讀寫就可以由內存直接傳回worker。這樣的讀寫模式極大地縮短了模擬器處理數據的時間。

通過這一邏輯層的添加,我們可以將模擬器部署到Spark集群內的每一臺worker機器上。通過加載不同的配置文件使每臺機器運行不同的模塊;也可以通過部署相同模塊不同模型的條件下運行相同數據,以比較模型的不同;還可以在相同模塊相同模型的條件下運行不同數據,比對不同數據的差異。由此可見,分布式系統的使用為模擬器添加了無數擴展的可能。

性能評估

在設計實現的同時,我們對系統進行了性能評估。隨著計算資源的增加,計算時間也在線性地降低,系統表現出很強的可擴展性,可以承受很大的數據量與計算量。在一個圖像識別測試集中,使用單機處理圖像數據耗時為3個小時,而使用8個Spark worker后,耗時僅25分鐘。假設我們使用10000個Spark worker對谷歌無人車級別的數據進行大規模的圖像識別模擬測試,整個實驗也可以在100小時內完成。

結論

使用分布式系統能夠極大提升模擬器的工作能力,使無人駕駛系統的測試工作得以大規模有序地擴展開來。這一結果是建立在模擬器架構模塊化,以及測試用例組合模塊化的基礎之上的。采用分布式系統搭建模擬平臺,使得在真車上路之前測試無人駕駛汽車將要行駛的每一條道路成為現實。當然無人駕駛汽車在真實道路上的測試依然必不可少,但是模擬器已經為無人駕駛系統測試了海量的基礎情景,使我們可以以最低的成本最大限度地保障真車測試時的安全。

中国比特币暴涨 三的开奖结果及走势图 南粤36选7走势图 天津时时是官方 曾道免费大全资料 山西快乐10分走势图派彩电子 时时3星缩水软件 平特一肖期期谁 11选五遗漏数据辽宁 极速时时玩法 幸运28走势图pc蛋蛋 江苏东方6十1开奖结果2019044 29333天线宝宝开奖结果 快乐12历史开奖数据 广东时时现场 甘肃快3开奖果 360时时走势图