如何在ROS的基礎(chǔ)上提升無(wú)人駕駛系統(tǒng)的可靠性

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

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

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

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

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

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

圖2 無(wú)人駕駛軟硬件整合

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

機(jī)器人操作系統(tǒng)（ROS）簡(jiǎn)介

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

圖3 ROS系統(tǒng)

ROS 1.0

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

圖4 ROS Master Node通信

ROS 2.0

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

圖5 ROS 2.0 DDS

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

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

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

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

系統(tǒng)可靠性

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

去中心化

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

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

實(shí)時(shí)監(jiān)控和報(bào)警

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

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

節(jié)點(diǎn)宕機(jī)狀態(tài)恢復(fù)

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

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

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

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

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

圖8 Multicast性能提升

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

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

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

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

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

結(jié)論

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

作者簡(jiǎn)介：

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

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

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

編輯：hfy