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

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

無人駕駛：多種技術的集成

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

圖1 無人駕駛系統范例

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

圖2 無人駕駛軟硬件整合

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

機器人操作系統（ROS）簡介

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

圖3 ROS系統

ROS 1.0

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

圖4 ROS Master Node通信

ROS 2.0

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

圖5 ROS 2.0 DDS

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

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

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

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

系統可靠性

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

去中心化

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

圖6 基于ZooKeeper的監控和報警

實時監控和報警

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

圖7 基于ZooKeeper的監控和報警

節點宕機狀態恢復

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

系統通信性能提升

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

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

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

圖8 Multicast性能提升

第三，對ROS的通信棧研究，我們發現通信延時很大的損耗是在數據的序列化與反序列化的過程。序列化將內存里對象的狀態信息轉換為可以存儲或傳輸的形式。在序列化期間，對象將其當前狀態寫入到臨時或持久性存儲區。之后，可以通過從存儲區中讀取或反序列化對象的狀態，重新創建該對象。為了解決這個問題，我們使用了輕量級的序列化程序，將序列化的延時降低了50%。

系統資源管理與安全性

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

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

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

結論

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

作者簡介：

劉少山，PerceptIn聯合創始人，主要專注于增強現實、虛擬現實、機器人的核心SLAM技術及其在智能硬件上的實現與優化。創立PerceptIn之前在百度美國研發中心工作，負責無人車系統架構及產品化。

張偉德，百度美國研發中心高級架構師。曾在弗吉尼亞大學網格計算小組擔任研究員，在Yahoo!、微軟等公司負責大型分布式搜索構架設計。目前在百度從事大數據、深度學習架構和開發。

James Peng，百度首席架構師。斯坦福大學博士，研究方向包括云計算平臺、深度學習、數據建模、大規模數據庫等。曾在Google工作多年，加入百度后領導多個創新項目，并于2013年獲得百度最高獎。*

編輯：hfy