本文著重介紹基于機器人操作系統(tǒng)ROS的無人駕駛系統(tǒng)。文中將介紹ROS以及它在無人駕駛場景中的優(yōu)缺點，并討論如何在ROS的基礎(chǔ)上提升無人駕駛系統(tǒng)的可靠性、通信性能和安全性。

在上篇解析光學(xué)雷達（LiDAR）技術(shù)（《》）之后，本文著重介紹基于機器人操作系統(tǒng)ROS的無人駕駛系統(tǒng)。文中將介紹ROS以及它在無人駕駛場景中的優(yōu)缺點，并討論如何在ROS的基礎(chǔ)上提升無人駕駛系統(tǒng)的可靠性、通信性能和安全性。

無人駕駛：多種技術(shù)的集成

無人駕駛技術(shù)是多個技術(shù)的集成，如圖1所示，一個無人駕駛系統(tǒng)包含了多個傳感器，包括長距雷達、激光雷達、短距雷達、攝像頭、超聲波、GPS、陀螺儀等。每個傳感器在運行時都不斷產(chǎn)生數(shù)據(jù)，而且系統(tǒng)對每個傳感器產(chǎn)生的數(shù)據(jù)都有很強的實時處理要求。比如攝像頭需要達到60FPS的幀率，意味著留給每幀的處理時間只有16毫秒。但當(dāng)數(shù)據(jù)量增大之后，分配系統(tǒng)資源便成了一個難題。例如，當(dāng)大量的激光雷達點云數(shù)據(jù)進入系統(tǒng)，占滿CPU資源，就很可能使得攝像頭的數(shù)據(jù)無法及時處理，導(dǎo)致無人駕駛系統(tǒng)錯過交通燈的識別，造成嚴重后果。

圖1 無人駕駛系統(tǒng)范例

如圖2所示，無人駕駛系統(tǒng)整合了多個軟件模塊（包括路徑規(guī)劃、避障、導(dǎo)航、交通信號監(jiān)測等）和多個硬件模塊（包括計算、控制、傳感器模塊等），如何有效調(diào)配軟硬件資源也是一個挑戰(zhàn)。具體包括三個問題：第一，當(dāng)軟硬件模塊數(shù)據(jù)增加，運行期間難免有些模塊會出現(xiàn)異常退出的問題，甚至導(dǎo)致系統(tǒng)崩潰，此時如何為提供系統(tǒng)自修復(fù)能力？第二，由于模塊之間有很強的聯(lián)系，如何管理模塊間的有效通信（關(guān)鍵模塊間的通信，信息不可丟失，不可有過大的延時）？第三，每個功能模塊間如何進行資源隔離？如何分配計算與內(nèi)存資源？當(dāng)資源不足時如何確認更高的優(yōu)先級執(zhí)行？

圖2 無人駕駛軟硬件整合

簡單的嵌入式系統(tǒng)并不能滿足無人駕駛系統(tǒng)的上述需求，我們需要一個成熟、穩(wěn)定、高性能的操作系統(tǒng)去管理各個模塊。在詳細調(diào)研后，我們覺得機器人操作系統(tǒng)ROS比較適合無人駕駛場景。下文將介紹ROS的優(yōu)缺點，以及如何改進ROS使之更適用于無人駕駛系統(tǒng)。

機器人操作系統(tǒng)（ROS）簡介

ROS是一個強大而靈活的機器人編程框架，從軟件構(gòu)架的角度說，它是一種基于消息傳遞通信的分布式多進程框架。ROS很早就被機器人行業(yè)使用，很多知名的機器人開源庫，比如基于quaternion的坐標(biāo)轉(zhuǎn)換、3D點云處理驅(qū)動、定位算法SLAM等都是開源貢獻者基于ROS開發(fā)的。因為ROS本身是基于消息機制的，開發(fā)者可以根據(jù)功能把軟件拆分成為各個模塊，每個模塊只是負責(zé)讀取和分發(fā)消息，模塊間通過消息關(guān)聯(lián)。如圖3所示，最左邊的節(jié)點可能會負責(zé)從硬件驅(qū)動讀取數(shù)據(jù)（比如Kinect），讀出的數(shù)據(jù)會以消息的方式打包，ROS底層會識別這個消息的使用者，然后把消息數(shù)據(jù)分發(fā)給他們。

圖3 ROS系統(tǒng)

ROS 1.0

ROS 1.0起源于Willow Garage的PR2項目，主要組件包括ROS Master、ROS Node和ROS Service三種。ROS Master的主要功能是命名服務(wù)，它存儲了啟動時需要的運行時參數(shù)，消息發(fā)布上游節(jié)點和接收下游節(jié)點的連接名和連接方式，和已有ROS服務(wù)的連接名。ROS Node節(jié)點是真正的執(zhí)行模塊，對收到的消息進行處理，并且發(fā)布新的消息給下游節(jié)點。ROS Service是一種特殊的ROS節(jié)點，它相當(dāng)于一個服務(wù)節(jié)點，接受請求并返回請求的結(jié)果。圖4展示了ROS通信的流程順序，首先節(jié)點會向master advertise或者subscribe感興趣的topic。當(dāng)創(chuàng)建連接時，下游節(jié)點會向上游節(jié)點TCP Server發(fā)布連接請求，等連接創(chuàng)建后，上游節(jié)點的消息就會通過連接送至下游節(jié)點。

圖4 ROS Master Node通信

ROS 2.0

ROS 2.0的改進主要是為了讓ROS能夠符合工業(yè)級的運行標(biāo)準(zhǔn)，采用了DDS（數(shù)據(jù)分發(fā)服務(wù)）這個工業(yè)級別的中間件來負責(zé)可靠通信，通信節(jié)點動態(tài)發(fā)現(xiàn)，并用shared memory方式使得通信效率更高。通過使用DDS，所有節(jié)點的通信拓撲結(jié)構(gòu)都依賴于動態(tài)P2P的自發(fā)現(xiàn)模式，所以也就去掉ROS Master這個中心節(jié)點。如圖5所示，RTI Context、PrismTech OpenSplice和Twin Oaks都是DDS的中間件提供商，上層通過DDS API封裝，這樣DDS的實現(xiàn)對于ROS Client透明。

圖5 ROS 2.0 DDS

在無人車駕駛系統(tǒng)中, 我們選擇依舊基于ROS 1.0 開發(fā)，而不是ROS 2.0，主要有以下幾點考慮:

ROS 2.0是一個開發(fā)中的框架，很多功能還不是很完整，有待更多的測試與驗證。而在無人駕駛環(huán)境中，穩(wěn)定性與安全性是至關(guān)重要的，我們需要基于一個經(jīng)過驗證的穩(wěn)定系統(tǒng)來保證系統(tǒng)的穩(wěn)定性、安全性和性能，以達到無人車的要求。

DDS本身的耗費。我們測試了直接在ROS 1.0上使用DDS中間件，其中國防科技大學(xué)有一個開源項目MicROS已經(jīng)做了相關(guān)的嘗試，但是實驗發(fā)現(xiàn)在一般的ROS通信場景中（100K發(fā)送者接收者通信），ROS on DDS的吞吐率并不及ROS 1.0，主要原因是DDS框架本身的耗費要比ROS多一些，同時用了DDS以后CPU占用率有明顯提高。但是我們也確認了使用DDS之后，ROS的QoS高優(yōu)先級的吞吐率和組播能力有了大幅提升。我們的測試基于PrismTech OpenSplice的社區(qū)版，在它的企業(yè)版中有針對單機的優(yōu)化，比如使用了共享內(nèi)存的優(yōu)化，我們暫未測試。

DDS接口的復(fù)雜性。DDS本身就是一套龐大的系統(tǒng)，其接口的定義極其復(fù)雜，同時文檔支持較薄弱。

系統(tǒng)可靠性

如上文所述，系統(tǒng)可靠性是無人駕駛系統(tǒng)最重要的特性。試想幾個場景：第一，系統(tǒng)運行時ROSMaster出錯退出，導(dǎo)致系統(tǒng)崩潰；第二，其中一個ROS節(jié)點出錯，導(dǎo)致系統(tǒng)部分功能缺失。以上任何一個場景在無人駕駛環(huán)境中都可能造成嚴重的后果。對于ROS而言，其在工業(yè)領(lǐng)域的應(yīng)用可靠性是非常重要的設(shè)計考量，但是目前的ROS設(shè)計對這方面考慮得比較少。下面就討論實時系統(tǒng)的可靠性涉及的一些要素。

去中心化

ROS重要節(jié)點需要熱備份，以便宕機時可以隨時切換。在ROS 1.0的設(shè)計中，主節(jié)點維護了系統(tǒng)運行所需的連接、參數(shù)和主題信息，如果ROS Master宕機了，整個系統(tǒng)就有可能無法正常運行。去中心化的解決方案有很多，如圖6所示，我們可以采用主從節(jié)點的方式（類似ZooKeeper），同時主節(jié)點的寫入信息隨時備份，主節(jié)點宕機后，備份節(jié)點被切換為主節(jié)點，并且用備份的主節(jié)點完成信息初始化。

圖6 基于ZooKeeper的監(jiān)控和報警

實時監(jiān)控和報警

對于運行的節(jié)點實時監(jiān)控其運行數(shù)據(jù)，并檢測到嚴重的錯誤信息時報警。目前ROS并沒有針對監(jiān)控做太多的構(gòu)架考慮，然而這塊方面恰恰是最重要的。對于運行時的節(jié)點，監(jiān)控其運行數(shù)據(jù)，比如應(yīng)用層統(tǒng)計信息、運行狀態(tài)等，對將來的調(diào)試、錯誤追蹤都有很多好處。如圖7所示，實時監(jiān)控從軟件構(gòu)架來說主要分成3部分：ROS節(jié)點層的監(jiān)控數(shù)據(jù)API，讓開發(fā)者能夠設(shè)置所需的統(tǒng)計信息，通過統(tǒng)一的API進行記錄；監(jiān)控服務(wù)端定期從節(jié)點獲取監(jiān)控數(shù)據(jù)（對于緊急的報警信息，節(jié)點可以把消息推送給監(jiān)控服務(wù)端）；獲取到監(jiān)控數(shù)據(jù)后，監(jiān)控服務(wù)端對數(shù)據(jù)進行整合、分析、記錄，在察覺到異常信息后報警。

圖7 基于ZooKeeper的監(jiān)控和報警

節(jié)點宕機狀態(tài)恢復(fù)

節(jié)點宕機的時候，需要通過重啟的機制恢復(fù)節(jié)點，這個重啟可以是無狀態(tài)的，但有些時候也必須是有狀態(tài)的，因此狀態(tài)的備份格外重要。節(jié)點的宕機檢測也是非常重要的，如果察覺到節(jié)點宕機，必須很快地使用備份的數(shù)據(jù)重啟。這個功能我們也已經(jīng)在ZooKeeper框架下實現(xiàn)了。

系統(tǒng)通信性能提升

由于無人駕駛系統(tǒng)模塊很多，模塊間的信息交互很頻繁，提升系統(tǒng)通信性能會對整個系統(tǒng)性能提升的作用很大。我們主要從以下三個方面來提高性能：

第一，目前同一個機器上的ROS節(jié)點間的通信使用網(wǎng)絡(luò)棧的loop-back機制，也就是說每一個數(shù)據(jù)包都需要經(jīng)過多層軟件棧處理，這將造成不必要的延時（每次20微秒左右）與資源消耗。為了解決這個問題，我們可以使用共享內(nèi)存的方法把數(shù)據(jù)memory-map到內(nèi)存中，然后只傳遞數(shù)據(jù)的地址與大小信息，從而把數(shù)據(jù)傳輸延時控制在20微秒內(nèi)，并且節(jié)省了許多CPU資源。

第二，現(xiàn)在ROS做數(shù)據(jù)broadcast的時候，底層實現(xiàn)其實是使用multiple unicast，也就是多個點對點的發(fā)送。假如要把數(shù)據(jù)傳給5個節(jié)點，那么同樣的數(shù)據(jù)會被拷貝5份。這造成了很大的資源浪費，特別是內(nèi)存資源的浪費。另外，這樣也會對通信系統(tǒng)的吞吐量造成很大壓力。為了解決這個問題，我們使用了組播multicast機制：在發(fā)送節(jié)點和每一接收節(jié)點之間實現(xiàn)點對多點的網(wǎng)絡(luò)連接。如果一個發(fā)送節(jié)點同時給多個接收節(jié)點傳輸相同的數(shù)據(jù)，只需復(fù)制一份相同的數(shù)據(jù)包。組播機制提高了數(shù)據(jù)傳送效率，減少了骨干網(wǎng)絡(luò)出現(xiàn)擁塞的可能性。圖8對比了原有的通信機制（灰線）與組播機制（橙色）的性能，隨著接收節(jié)點數(shù)量增加（X軸），原有的通信機制的數(shù)據(jù)吞吐量急劇下降，而組播機制的數(shù)據(jù)吞吐量則比較平穩(wěn)，沒有受到嚴重影響。

圖8 Multicast性能提升

第三，對ROS的通信棧研究，我們發(fā)現(xiàn)通信延時很大的損耗是在數(shù)據(jù)的序列化與反序列化的過程。序列化將內(nèi)存里對象的狀態(tài)信息轉(zhuǎn)換為可以存儲或傳輸?shù)男问健Ｔ谛蛄谢陂g，對象將其當(dāng)前狀態(tài)寫入到臨時或持久性存儲區(qū)。之后，可以通過從存儲區(qū)中讀取或反序列化對象的狀態(tài)，重新創(chuàng)建該對象。為了解決這個問題，我們使用了輕量級的序列化程序，將序列化的延時降低了50%。

系統(tǒng)資源管理與安全性

如何解決資源分配與安全問題是無人駕駛技術(shù)的一個大課題。想象兩個簡單的攻擊場景：第一，其中一個ROS的節(jié)點被劫持，然后不斷地分配內(nèi)存，導(dǎo)致系統(tǒng)內(nèi)存消耗殆盡，造成系統(tǒng)OOM而開始關(guān)閉不同的ROS節(jié)點進程，從而整個無人駕駛系統(tǒng)崩潰。第二，ROS的topic或者service被劫持, ROS節(jié)點之間傳遞的信息被偽造，導(dǎo)致無人駕駛系統(tǒng)行為異常。

我們選擇的方法是使用Linux Container（LXC）來管理每一個ROS節(jié)點進程。簡單來說，LXC提供輕量級的虛擬化以便隔離進程和資源，而且不需要提供指令解釋機制以及全虛擬化等其他復(fù)雜功能，相當(dāng)于C++中的NameSpace。LXC有效地將單個操作系統(tǒng)管理的資源劃分到孤立的群組中，以更好地在孤立的群組之間平衡有沖突的資源使用需求。對于無人駕駛場景來說，LXC最大的好處是性能損耗小。我們測試發(fā)現(xiàn)，在運行時LXC只造成了5%左右的CPU損耗。

除了資源限制外，LXC也提供了沙盒支持，使得系統(tǒng)可以限制ROS節(jié)點進程的權(quán)限。為了避免有危險性的ROS節(jié)點進程可能破壞其他ROS節(jié)點進程的運行，沙盒技術(shù)可以限制可能有危險性的ROS節(jié)點訪問磁盤、內(nèi)存以及網(wǎng)絡(luò)資源。另外為了防止節(jié)點中的通信被劫持，我們還實現(xiàn)了節(jié)點中通信的輕量級加密解密機制，使黑客不能回放或更改通信內(nèi)容。

結(jié)論

要保證一個復(fù)雜的系統(tǒng)穩(wěn)定、高效地運行，每個模塊都能發(fā)揮出最大的潛能，需要一個成熟有效的管理機制。在無人駕駛場景中，ROS提供了這樣一個管理機制，使得系統(tǒng)中的每個軟硬件模塊都能有效地進行互動。原生的ROS提供了許多必要的功能，但是這些功能并不能滿足無人駕駛的所有需求，因此我們在ROS之上進一步地提高了系統(tǒng)的性能與可靠性，完成了有效的資源管理及隔離。我們相信隨著無人駕駛技術(shù)的發(fā)展，更多的系統(tǒng)需求會被提出，比如車車互聯(lián)、車與城市交通系統(tǒng)互聯(lián)、云車互聯(lián)、異構(gòu)計算硬件加速等，我們也將會持續(xù)優(yōu)化這個系統(tǒng)，力求讓它變成無人駕駛的標(biāo)準(zhǔn)系統(tǒng)。

作者簡介：

劉少山，PerceptIn聯(lián)合創(chuàng)始人，主要專注于增強現(xiàn)實、虛擬現(xiàn)實、機器人的核心SLAM技術(shù)及其在智能硬件上的實現(xiàn)與優(yōu)化。創(chuàng)立PerceptIn之前在百度美國研發(fā)中心工作，負責(zé)無人車系統(tǒng)架構(gòu)及產(chǎn)品化。

張偉德，百度美國研發(fā)中心高級架構(gòu)師。曾在弗吉尼亞大學(xué)網(wǎng)格計算小組擔(dān)任研究員，在Yahoo!、微軟等公司負責(zé)大型分布式搜索構(gòu)架設(shè)計。目前在百度從事大數(shù)據(jù)、深度學(xué)習(xí)架構(gòu)和開發(fā)。

James Peng，百度首席架構(gòu)師。斯坦福大學(xué)博士，研究方向包括云計算平臺、深度學(xué)習(xí)、數(shù)據(jù)建模、大規(guī)模數(shù)據(jù)庫等。曾在Google工作多年，加入百度后領(lǐng)導(dǎo)多個創(chuàng)新項目，并于2013年獲得百度最高獎。*

編輯：hfy