開源機器人作業系統第二代的介紹與未來應用

摘要：ROS 1.0 已經有10多年的發展，早已成為機器人研究領域不可或缺的開發環境。然而其中心化的架構，缺乏QoS的通訊方式以及穩健網路假設等缺點，造成研究開發成果難以直接商品化或導入工業應用。因此，OSRF於2014年起開始投入ROS 2.0的開發，採用已在國防軍工業以及大型工業應用中有諸多實戰經歷的DDS作為ROS 2.0的middleware。本篇文章將大致描述ROS 2.0的源起與設計理念，DDS的發展與相關概念，ROS 2.0與DDS的整合架構到ROS 2.0目前的發展與未來可能的應用。

Abstract：It has been more than ten years since the first version of Robot Operating System (ROS) released in 2007. Currently, ROS has become the de-facto standard in robotic research field. However, its centralized architecture lack  QoS guarantee and assumed  reliable wired based network environment. These drawbacks result in a huge gap between prototyping and building commercial products. Therefore, the Open Source Robotics Foundation (OSRF) has been heavily developing the second generation of ROS, called ROS 2.0, from 2014 to tackle these issues. ROS 2.0 adopted Data Distribution Service (DDS), a defense and military industriy proven distributed service, as its middleware. This article mainly focused on the development procedure, design concept, software architecture, and possible applications in the future regarding  ROS 2.0.

關鍵詞：第二代開源機器人作業系統、數據分發服務、網路通訊服務質量
Keywords：Robot operation system 2.0 (ROS 2.0), Data distribution service (DDS), Quality of service (QoS)

前言
由Stanford 新創的Willow Garage所開發之開源機器人操作系統 (Robot Operating System, ROS) 到今年已經度過10個年頭，早已成為歐美學術界或研究單位等採用的事實標準 (De-Facto Standard)。根據目前負責開發與維護ROS的開源機器人基金會 (Open Source Robotics Foundation, OSRF)的年度報告顯示[1]，2015年由DARPA所舉辦的機器人競賽 (DARPA Robotics Challenge, DRC)，在最終的23組團隊當中，就有超過18組採用ROS環境開發以及14組採用Gazebo作為演算法演示的模擬環境 (Gazebo為OSRF所開發之三維物理模擬軟件，與ROS相容)，或是NASA所開發之Robonaut-2人形機器人亦證明ROS在前瞻性機器人研究領域中的地位[2]。另外，近幾年逐漸熱門的無人車領域，除了BMW[3]或是Bosch 長期使用ROS作為初期系統整合或是演算法驗證之環境，以及近期有名的百度無人車開源架構Apollo[4]，或是由日本多所學校共同開發維護Autoware無人車開發整合平台等[5]，皆透過ROS這個中介層 (Middleware) 作為不同節點 (Node) 之間通訊的架構。然而，擁有多年與學術研究機構相互疊代的ROS，在另一方面也有他的致命傷，因為主要的通訊架構XML-RPC是在10年前依據當時的科技水平所設計，根據當年PR2機器人 (第一台應用ROS的商用級研究機器人) 團隊的目標，ROS主要是用於有線網路 (Ethernet)， 選用TCPIP通訊協定，在單台機器內做資料傳遞，不須考慮通訊安全 (Security) 或是通訊品質 (Quality of Service, QoS) 與優先權 (Priority) 等問題。這些ROS的特性已無法適當地處理當今機器人領域所遇到的各種挑戰，如無線網路通訊不穩，多台機器人協同合作 (Swarm) 需求，或是大量影像數據在不同節點間傳送所造成的頻寬壅塞問題。ROS的開發團隊在近4年前就意識到此類需求，進而對新一代系統的要求、規範以及架構等展開討論與各式概念驗證，於2014 ROSCon (OSRF所舉辦之年度ROS Conference) 正式提出ROS 2.0的稱號以及軟體架構與相關開發的時程規劃[6]。
ROS2.0的前世今生
1.ROS2.0設計理念
以往研究單位或是系統整合開發商在透過ROS快速構建出理想中的機器人平台時，最常遇到的問題是ROS的通訊架構無法符合商用產品的標準，除了前言提到的種種通訊與頻寬上的限制，還有中心化網路的不穩定，缺乏像是android app中對各模組或節點的監控能力 (Node Manager)，以及ROS環境對Ubuntu作業系統的依賴以及架構本身相當肥大等問題，使得系統開發商必須面臨決策，除了冒風險直接將ROS置入商品外，就是投入大量R/D改進或是抽換ROS的中介溝通層，此類最有名的例子就是百度的Apollo無人車系統[4]，一開始是採用原生的ROS，但後來將XML-RPC換成Fast-RTPS (一種輕量化的DDS) 並導入PREEMPT-RT 使Ubuntu Kernel轉成RTOS (Real Time Operating System)，或直接將ROS中所引用的各種演算法軟體庫 (Packages) 自行移植到自家產品的通訊架構中，如BMW無人車開發計畫等。
而ROS2.0的出現，就是為了處理以上種種的問題，根據OSRF CEO-Brian Gerkey以及核心開發人員如William Woodall等在官方維基 (Why ROS2.0) 的撰筆[7]，其設計理念主要著重在中介層的抽換，將原先過時的中心化發布訂閱機構 (Publish Subscribe Middleware) 換成比較新穎的技術如：Zeroconf, Protocol Buffers, ZeroMQ, Redis, WebSockets 以及DDS (Data Distribution Service)。在經過各種內部討論以及初期測試後，決定採用在歐美國防軍工業中已有多年實戰經驗的DDS中介層，主要是因為其分散式、點對點 (Peer-to-Peer) 的拓樸系統、採用UDP但透過嚴格的服務質量(QoS)擔保其通訊品質、並且提供API以及可擴展性等特色，剛好符合ROS 2.0的設計目標。故根據核心開發人員 Dirk Thomas 等在ROSCon 2014的演講中描述[6]，ROS 2.0 主要專注於解決以下幾點ROS 1.0常見的問題：
（1）多台機器人協同合作： 這在ROS 1.0中沒有正統作法，因為其中心節點 (Master) 不支援與其他中心節點溝通，雖然可以透過ROS_MASTER_URI以及ROS_IP等環境變數去將所有機器人平台都依靠在同一個中心節點之下，但會造成系統非常不穩健，中心點一旦失效，就會造成所有機器人失去控制。而DDS是分散式系統，並沒有中心點的存在，比較像是分散式資料庫的概念，故不會有單點失效的風險。
（2）小型嵌入式系統： ROS 1.0官方只支援Ubuntu環境，所以一般的嵌入式開發版如STM32 (如ARM-M4、M7等) 都無法直接與ROS對接，且ROS本身因為引用過多第三方程式庫導致本身環境過於肥大。採用DDS便能支援Windows, MacOS等環境，且根據選用的DDS版本，如Fast-RTPS只保留DDS最底層的DDSI通訊層，是有機會移植到嵌入式開發板上，此類範例可參考DroneCode [8]。