Exploring the Performance of ROS2
文章目錄
- Exploring the Performance of ROS2
- 1. INTRODUCTION
- 2. BACKGROUND
- 3. EVALUATIONS
- 3.1 Experimental Situations and Methods
- 3.2 Capabilities of ROS1 and ROS2
- 3.3 Latency Characteristics of ROS1 and ROS2
- 3.3.1 Comparison between remote and local cases
- 3.3.2 Comparison among local, nodelet, and intraprocess cases
- 3.3.3 Comparison within ROS2
- 3.4 Throughput of ROS1 and ROS2
- 3.5 Thread of ROS1 and ROS2
- 3.6 Memory consumption of ROS1 and ROS2
- 3.7 Lessons Learned
1. INTRODUCTION
近年來，諸如自動駕駛車輛的實時分佈式嵌入式系統變得越來越複雜和多樣化。 自2007年11月3日DARPA城市挑戰賽以來，自主駕駛引起了人們的關注[34]。 機器人操作系統（ROS）[28]是開源中間件，經歷了快速發展[11]，並已廣泛用於機器人應用（例如自動駕駛系統）。 ROS幾乎完全是從頭開始構建的，自2007年以來一直由Willow Garage [7]和開源機器人基金會（OSRF）[2]維護.ROS提高了生產力[12]，提供發佈/訂閱傳輸，多個庫（例如 ，OpenCV和Point Cloud Library（PCL）[3]），以及幫助軟件開發人員創建機器人應用程序的工具。
Contribution:
在本文中，我們提供了DDS方法對ROS的概念證明。我們闡明瞭ROS1和ROS2在各種情況下的數據傳輸性能。性能意味着延遲特性，吞吐量和分佈式功能。關注DDS功能，根據DDS供應商和配置，我們從各個方面探索和評估潛在和約束：延遲，吞吐量，線程數和內存消耗。從實驗結果中，我們安排指南以及我們可以採取哪些措施來解決當前的約束問題。據我們所知，這是第一項探索ROS2性能的研究。
但是，ROS不滿足實時運行要求，只能在少數操作系統上運行。此外，ROS無法保證容錯，期限或進程同步。此外，ROS需要大量資源（例如，CPU，內存，網絡帶寬，線程和核心），並且無法管理這些資源以滿足時間限制。因此，ROS不適用於實時嵌入式系統。許多研究團體已經考慮過這個關鍵問題，包括ROS開發人員，並且已經提出並評估了各種解決方案[13]，[19]，[36]。但是，這些解決方案不足以解決ROS對實時嵌入式系統的限制。
爲了滿足現在更廣泛的ROS社區的需求，ROS將對ROS2進行重大升級[23]。 ROS2將考慮以下新用例：實時系統，小型嵌入式平臺（例如傳感器節點），非理想網絡和跨平臺（例如，Linux，Windows，Mac，實時操作系統（RTOS），否則OS）。爲了滿足這些新用例的要求，將重建現有版本的ROS（以下簡稱ROS1）以改進用戶界面API並採用新技術，如數據分發服務（DDS）[24]，[30]，Zeroconf ，協議緩衝器，ZeroMQ，Redis和WebSockets.2 ROS1傳輸系統將被DDS取代，DDS是一種行業標準的實時通信系統和端到端中間件。 DDS可以提供類似於ROS1的可靠發佈/訂閱傳輸。
DDS適用於實時嵌入式系統，因爲它具有各種傳輸配置（例如，期限，可靠性和耐久性）和可擴展性。 DDS滿足分佈式系統的安全性，彈性，可擴展性，容錯性和安全性要求。 DDS可以通過減少庫大小和內存佔用，爲某些實時環境和一些小型/嵌入式系統提供解決方案。由不同的DDS供應商開發，該通信系統的若干實現已經用於任務關鍵環境（例如，火車，飛機，船舶，水壩和金融系統）並且已經由NASA和美國國防部驗證。研究人員[37]，[32]和DDS供應商已對幾種DDS實施進行了評估和驗證。這些評估表明DDS既可靠又靈活。
Organization:
本文的其餘部分安排如下。第2節提供了背景信息，並描述了ROS和DDS系統模型。第3節驗證了實驗情況，並評估了ROS1和ROS2在各種配置下的性能。第4節討論相關工作。最後，第5節總結了論文，併爲未來的工作提出了建議。
2. BACKGROUND
在本節中，我們提供背景知識。 首先，我們描述了與ROS1相比的ROS2系統模型，重點是其通信系統。 然後，我們回顧ROS的各個方面，例如發佈/訂閱模型。 最後，我們描述了DDS，它被用作ROS2中實時系統的通信系統。
2.1 Robot Operating System (ROS)
圖1簡要說明了ROS1和ROS2的系統模型。在圖1的左側，ROS1的實現包括通信系統TCPROS / UDPROS。由於ROS1的實現，此通信需要主進程（在分佈式系統中是唯一的）。相反，如圖1右側所示，ROS2建立在DDS之上幷包含DDS抽象層。由於此抽象層，用戶無需瞭解DDS API。該層允許ROS2具有高級配置並優化DDS的利用率。此外，由於使用DDS，ROS2不需要主過程。這是容錯方面的一個重要點。
ROS應用程序由稱爲節點的獨立計算過程組成，這些過程可促進故障隔離，更快的開發，模塊化和代碼可重用性。節點之間的通信基於發佈/訂閱模型。在此模型中，節點通過主題傳遞消息進行通信。消息具有由.msg文件定義的簡單數據結構（很像C結構）。節點通過主題名稱標識消息的內容。當節點向主題發佈消息時，另一個節點訂閱該主題並利用該消息。例如，如圖2所示，“Camera”節點將消息發送到“Images”主題。主題中的消息由“汽車檢測”節點和“行人檢測”節點接收。發佈/訂閱模型設計爲精細化的模塊化，適用於分佈式系統。
在ROS1中，上述通信系統使用TCP和UDP套接字實現爲基於TCPROS和UDPROS的中間件。當啓動訂閱節點和發佈節點時，它們與主節點交互，主節點收集信息並管理主題，類似於服務器。在與主節點進行XML /遠程過程調用（RPC）事務之後，訂閱節點使用商定的連接協議請求與發佈節點的連接。實際數據（即消息）直接在節點之間傳輸。此數據不通過主數據路由。 ROS1實現節點之間的對等數據傳輸。
可選地，ROS1提供節點，其提供有效的節點組合以用於優化的數據傳輸而無需TCPROS和UDPROS。 nodelet通過傳遞指針實現同一進程中節點之間的非序列化數據傳輸。 ROS2繼承此選項作爲進程內通信，它解決了nodelet的一些基本問題（例如，安全內存訪問）。
ROS2採用DDS作爲其通信系統。但是，作爲例外，在沒有DDS的情況下執行進程內通信。 DDS由許多供應商提供，並具有多種實現類型。開發人員可以從各種DDS供應商中選擇適當的DDS實施。
2.2 Data Distribution Service (DDS)
DDS規範[21]是由對象管理組（OMG）[1]爲發佈/訂閱數據分發系統定義的。 OMG管理定義和標準化API;然而，OMG隱藏了實施的細節。不同供應商已經開發了幾種實現方式（例如，RTI [29]和PRISMTECH [25]）。 DDS支持廣泛的應用，從小型嵌入式系統到大型系統，如基礎設施。請注意，還支持分佈式實時嵌入式系統。
DDS的核心是以數據爲中心的發佈 - 訂閱（DCPS）模型，旨在即使在分佈式異構平臺中也能在進程之間提供高效的數據傳輸。 DCPS模型創建了一個可由任何獨立應用程序訪問的“全局數據空間”。 DCPS有助於高效的數據分發。在DDS中，發佈或訂閱數據的每個進程稱爲參與者，其對應於ROS中的節點。參與者可以使用類型化界面從/向全局數據空間讀取和寫入。
如圖3所示，DCPS模型由DCPS實體構成：DomainParticipant，Publisher，Subscriber，DataWriter，DataReader和Topic。根據服務質量（QoS）策略執行進程之間的每個數據傳輸。
- DomainParticipant: 用於跟蹤其他實體和服務入口點的容器。在DDS中，所有應用程序在域內相互通信，從而促進隔離和通信優化。
- Publisher: 發佈是負責數據發佈的對象。管理一個或多個DataWriters，發佈將數據發送到一個或多個主題。
- Subscriber: 訂閱負責接收已發佈的數據並使數據可用。訂閱代表一個或多個DataReader行事。根據訂閱，DomainParticipant可以接收和發送不同指定類型的數據。
- DataWriter: DataWriter是DomainParticipant必須使用的對象，以通過Publisher發佈數據。 DataWriter發佈給定類型的數據。
- DataReader: DataReader是附加到訂閱服務器的對象。使用DataReader，DomainParticipant可以接收和訪問其類型必須與DataWriter的類型相對應的數據。
- Topic: 主題用於標識DataWriter和DataReader之間的每個數據對象。每個主題由名稱和數據類型定義。
- QoS Policy: 所有DCPS實體都有QoS策略，表示其數據傳輸行爲。每個數據事務都可以通過許多QoS策略選項在不同的粒度級別進行配置。在圖4中，我們顯示了遵循QoS策略的DDS數據傳輸示例。目前爲止，歷史深度和通信可靠性由QoS策略配置。表1顯示了ROS2支持的QoS策略的詳細信息。在DDS中，還有許多其他QoS策略[21]，ROS2應該支持擴展其功能。
![]()
在DCPS模型中，給定類型的數據從一個或多個DataWriters發佈到主題（其名稱在域中是唯一的）。一個或多個DataReader按主題名稱標識數據對象，以便訂閱該主題。在此事務之後，DataWriter使用分佈式系統中的實時發佈/訂閱（RTPS）協議[20]連接到DataReader。 RTPS協議（DDS標準協議）允許來自多個供應商的DDS實現通過抽象和優化傳輸（例如TCP / UDP / IP）來互操作。 RTPS協議是靈活的，並且被定義爲利用QoS策略。一些供應商使用UDP和共享內存傳輸進行通信。但是，在某些情況下，發現和數據交換可能需要TCP協議。
DataWriter和DataReader之間的數據傳輸根據QoS策略在RTPS協議中執行。每個DCPS實體根據唯一的用戶指定的QoS策略管理數據樣本。 DCPS中間件負責基於QoS策略的分佈式系統中的數據傳輸。在不考慮詳細的傳輸實現的情況下，DDS用戶將代碼生成爲DomainParticipant，包括使用DDS API的QoS策略。因此，用戶可以僅關注其目的並確定輕鬆滿足實時約束的方法。
3. EVALUATIONS
本節闡明瞭ROS1和ROS2的功能和潛伏期特徵。 目前，ROS2已作爲alpha版本發佈，其主要功能是C++客戶端庫，構建系統以及來自多個供應商的部分DDS中間件的抽象。 請注意，ROS2是一個非常粗略的草案，目前正在大力發展。 因此，該評估試圖闡明ROS2當前可實現的能力和延遲特性。
進行以下實驗以評估發佈/訂閱消息傳遞的端到端延遲。延遲的測量是從單個節點上的調用發佈函數開始到另一個節點接到數據進入回調函數爲止，使用硬件和軟件環境如表2所示。傳輸數據大小的範圍是256 B到4 MB，因爲大圖像數據（例如， 2 MB）和點雲數據（.pcd）經常用於ROS應用，例如自動駕駛系統[18]。字符串類型消息用於此評估。在下面的實驗中，我們使用兩個QoS設置，即可靠策略(reliable policy)和效果最優策略(best-effort)，如表3所示。在可靠策略中，TRANSIENT_LOCAL允許節點爲延遲加入的訂閱節點保留所有消息，RELIABLE便於可靠通訊。在best-effort策略中，節點不會保留消息並且也不會考慮通信是否可達。雖然每個節點以10 Hz執行，但實驗重複最多4 MB。給出了每個數據大小的100次測量獲得的箱線圖和中位數。對於精確的評估方法，我們在[5]和[6]中開源代碼。我們比較了三種DDS實現，即Connext [29]，OpenSplice [25]和FastRTPS [14]。 Connext和OpenSplice是衆所周知的商業許可證DDS實現。請注意，Connext還擁有研究許可證。已經在LGPL許可下發布了OpenSplice和FastRTPS的幾種實現。默認情況下，Connext使用UDPv4和共享內存來交換數據。請注意，OpenSplice3和FastRTPS不支持共享內存數據傳輸。對於精確的評估和實時要求，節點遵循SCHED FIFO [15]和mlockall系統調用。 SCHED FIFO進程優先於任何非SCHED FIFO進程，即使用默認Linux調度的進程。使用mlockall，進程的虛擬地址空間在物理RAM中得到修復，從而防止將內存分頁到交換區域。
3.1 Experimental Situations and Methods
如圖5所示，在以下實驗中評估ROS1和/或ROS2中的節點之間的各種通信情況。而ROS1用於（1-a）、（1- b）和（1-c）中，ROS2用於（2-a）、（2-b）和（2-c）。在（3-a）和（3-b）中，ROS1和ROS2節點共存。注意，由於進程內通信，即共享存儲器傳輸，（2-c）的情況不需要DDS。共享內存傳輸用於（1-c）nodelet和（2-c）進程內情況。在實驗中，Machine1僅用於（1-b）、（1-c）、（2-b）、（2-c）和（3-b）。通過在節點之間發送消息，在同一臺機器上測量端到端延遲。消息在本地情況下通過本地環回，即（1-b），（2-b）和（3-b）。否則，對於通過網絡的通信，Machine1和Machine2用於遠程情況，即（1-a）、（2-a）和（3-a）。它們通過本地IP網絡連接，無需任何其他網絡。
3.2 Capabilities of ROS1 and ROS2
表4顯示了是否可以測量每個數據大小的端到端延遲，並評論實驗結果的因果因素。表4總結了ROS2的功能，並且可以進行一些有趣的觀察。在“初始丟失”列中，ROS1無法在節點首次發送消息時獲取初始消息，即使ROS1使用具有256 B等小數據的TCPROS並且在發佈節點開始發送之前啓動了訂閱節點消息。雖然TCPROS對於傳遞中間消息是可靠的，但它不支持初始消息的可靠傳輸。當使用ros_bridge時，這會影響ROS2。相比之下，即使使用4 MB等大數據，ROS2也不會丟失初始消息。這證明了DDS的可靠性。在best-effort策略中，必須在發佈節點開始發送沒有“初始丟失”的消息之前啓動訂閱節點。另一方面，使用ROS2可靠策略，在發佈節點開始發送消息之前不必啓動訂閱節點。這歸因於QoS策略的耐久性中的TRANSIENT_LOCAL。可靠的策略被調整爲爲後期加入的訂戶節點提供彈性。在ROS1中，已發佈的消息丟失並且從未恢復。此QoS策略可加速容錯。
表4中另一個有趣的觀察結果是ROS2在傳輸大數據時存在許多問題。在ROS2的各種情況下，許多實驗都失敗了;但是，我們可以觀察到Connext和OpenSplice之間的性能差異。這些對大數據的約束源於Connext和OpenSplice的最大有效載荷爲64 KB。這是IP協議的最大包大小。默認情況下，使用QoS策略維護分段數據包很困難。因此，我們認爲DDS不是爲處理大數據而設計的。這對於分析ROS2性能很重要。例如，FastRTPS不支持大數據，因爲它被設計爲嵌入式系統的輕量級實現。即使是256 B的字符串也超過了FastRTPS中的最大長度。許多DDS供應商不支持使用可靠的連接和通用API發佈大數據。爲了發送和管理分開的數據包，這些DDS供應商提供了一個備用API，例如異步發佈者和流控制器，它們尚未從ROS2中抽象出來。在我們的實驗中，當數據大於64 KB時，具有可靠策略的Connext會產生錯誤。盡力而爲策略的一些失敗是由於不可靠通信導致的頻繁消息丟失。當發佈節點不能將數據傳輸到訂戶節點時，我們無法收集足夠的樣本並進行評估。若干評估在（3-b）和遠程通信中失敗，如表4所示。目前，上述結果表明ROS2不適合處理大型消息。
3.3 Latency Characteristics of ROS1 and ROS2
如圖7，圖8，圖9，圖10所示，在圖5所示的每種情況下，都清楚了端到端延遲特性的趨勢。在（2-a）和（2-b）中，ROS2使用OpenSplice和 可靠的策略，因爲ROS1使用TCPROS，即可靠的通信。 在（3-a）和（3-b）中，爲了評估具有大數據（例如，512KB和1MB）的等待時間，使用具有盡力而爲策略的Connext。 首先，我們分析ROS2與ROS1相比的性能。 然後，我們使用不同的DDS實現和配置（例如QoS策略）來評估ROS2。
3.3.1 Comparison between remote and local cases
ROS1和ROS2遠遠小於遠程和本地通信之間的差異。圖7和圖8顯示了遠程和本地病例的延遲中位數。由於從ROS1到ROS2以及從ROS2到ROS1的轉換影響是相似的，圖7和8包含單向數據。在圖7中，所有延遲的行爲始終爲4 KB。相反，遠程情況下的延遲從16 KB急劇增長，如圖7和圖8所示。這是因爲ROS1和ROS2將消息分成15 KB數據包以通過以太網傳輸數據。遠程和本地情況之間的這種差異對應於Machine1和Machine2之間的數據傳輸時間，這是在初步實驗中測量的。初步實驗使用ftp或http測量每個數據大小的傳輸時間。該對應關係表明RTPS協議和QoS策略數據對網絡中的數據傳輸時間影響很小。此外，通過測量數據傳輸時間可以預測所有延遲。
3.3.2 Comparison among local, nodelet, and intraprocess cases
在小數據和大數據的情況下，延遲特性不同。爲了便於討論，我們將圖分爲圖9和圖10，它們顯示了本地迴環和共享內存傳輸的端到端延遲的中位數。這是因爲消息是否被分成幾個數據包是考慮端到端延遲的導入問題。
對於小於64 KB的數據大小，會觀察到ROS2的持續開銷，如圖9所示，因爲DDS需要對QoS策略進行編組各種配置和決策。無論數據大小如何，我們都會在延遲和QoS策略之間進行權衡。儘管QoS策略產生了不可避免的開銷，但延遲是可預測的並且很小。由於ros_bridge交易，（3-b）有很大的開銷。在（3-b）情況下，ros_bridge導致與ROS1和ROS2通信的開銷更大。
對於大數據，ROS2具有顯着的開銷，具體取決於數據的大小，如圖10所示。（2-b）中ROS2的開銷歸因於兩個因素，即DDS的數據轉換和處理DDS。注意，（2-a）和（2-b）中的ROS2必須兩次轉換ROS2和DDS之間的消息。一次轉換是從ROS2到DDS，另一種轉換是從DDS到ROS2。在這些轉換之間，ROS2調用DDS API並將消息傳遞給DDS。圖11和圖12顯示了（2-b）OpenSplice 在reliable策略和best-effort策略中端到端延遲的細分。我們觀察到ROS2僅需要轉換和處理DDS。如圖11和12所示，“其他”幾乎沒有交易。此外，請注意，數據大小會影響轉換和DDS處理。與ROS1相比，DDS開銷不是恆定的，並且DDS的影響在大數據時是顯着的。因此，ROS2在大數據時具有顯着的開銷，而DDS的影響取決於QoS策略。
此外，在圖10中觀察到共享存儲器與大數據的影響。隨着數據變大，可以觀察到顯着的差異。但是，圖9中的影響似乎很小，因爲小數據隱藏了共享內存的影響。
另一個有趣的觀察是，儘管使用共享內存，但（2-c）進程內的延遲大於（1-b）中的延遲。此結果不是由於DDS的轉換和DDS的處理，因爲進程內通信不通過DDS路由。隨着ROS2的開發，這些差距將被關閉。需要改進進程內通信。
3.3.3 Comparison within ROS2
數據小於16 KB的端到端延遲在（2-b）中表現出類似的性能。我們討論16 KB到4 MB數據的性能。
圖13顯示了（2-b）中不同DDS實現的比較。我們使用besteffort策略評估（2-b）中有和沒有共享內存的OpenSplice和Connext。儘管共享內存，但性能並沒有明顯優於本地環回。這是由各種工具（例如，記錄器和觀察者）的編組引起的，即使在使用共享存儲器傳輸時也是如此。此外，OpenSplice在延遲方面優於Connext，如圖13所示，因爲我們使用的是Connext DDS Professional，它具有比OpenSplice DDS社區版更豐富的功能。我們假設Vortex OpenSplice的性能與OpenSplice DDS社區版的性能類似。但是，Vortex OpenSplice需要商業許可證，ROS2不支持。
此外，QoS策略對端到端延遲的影響在（2-b）OpenSplice中使用可靠的策略，reliable策略和* -depth策略進行評估。 * -depth策略爲此評估做好準備，並按深度配置，如表5所示。圖14顯示了延遲的差異，具體取決於可靠的策略和盡力而爲策略。 QoS策略的影響如圖11和12所示。在該評估中，網絡是理想的，即發佈者節點很少重新發送消息。如果網絡不理想，可靠政策的延遲會增加。 QoS策略中可靠性和耐用性的差異導致開銷，代價是可靠的通信和對後加入訂戶的彈性。圖15顯示了根據* -depth策略的深度沒有差異。這些QoS策略在節點數保存消息中是不同的。雖然此數字會影響資源，但這不會影響延遲，因爲存檔郵件是在每個發佈中進行的。
3.4 Throughput of ROS1 and ROS2
我們還測量了遠程情況下ROS1和ROS2的每個吞吐量。在我們的單向消息傳輸實驗中，網絡的最大帶寬爲12.5 MB /秒，因爲我們使用100 Mbps以太網（100BASE-TX）和全雙工，如表2所示。發佈者節點以10Hz重複傳輸每條消息。
在從256 B到2 KB的小數據中，我們可以觀察到具有OpenSplice的ROS1，ROS2和來自圖20的具有Connext的ROS2之間的恆定間隙。這些附加數據對應於用於QoS策略和心跳的RTPS分組。因此，這些差距不依賴於數據大小。此外，Connext吞吐量低於OpenSplice。當用戶處理具有高Hz和/或網絡帶寬的多種小數據時，這將產生巨大影響。
在2 KB至4 MB的大數據中，圖21的曲線顯示了可持續的理論吞吐量。 ROS1和ROS2能夠利用所有可用帶寬，並且在這種情況下表現相似。吞吐量受網絡限制，而不受DDS限制。
3.5 Thread of ROS1 and ROS2
在本節中，我們測量每個節點上的線程數。 表6顯示了測量結果。 請注意，表6中描述的數字取決於包括QoS策略在內的DDS配置。 供應商不會修復該號碼。
首先，我們可以觀察到Open-Splice的ROS2節點有很多線程。 這可能導致並行處理以及OpenSplice比Connext快得多的事實，如圖13所示。
另一個有趣的點是FastRTPS線程。 具有FastRTPS的ROS2節點實現了發現和序列化，以及具有相同數量的ROS1節點線程的發佈/訂閱數據傳輸。 此結果證明在沒有額外資源的情況下提高了容錯能力，因爲FastRTPS不需要主節點。
3.6 Memory consumption of ROS1 and ROS2
我們還測量ROS1和ROS2中共享庫對象（.so）的內存大小。 共享庫是節點在啓動時動態加載的庫。 它們不與可執行文件鏈接，但它們將是估計內存大小的重要指南。 我們將結果安排在表7中。在此表中，我們將pub / sub傳輸的庫數據大小相加。 在ROS2中，共享庫分爲DDS庫和ROS2抽象庫。 雖然DDS庫由每個供應商提供，但ROS2庫抽象DDS API並轉換DDS的消息。 在表7中，DDS和ROS2庫因供應商而異。 由於其QoS功能和抽象，這些庫數據大小趨於增加。 對於小型嵌入式系統，我們需要一個最小的DDS實現和輕量級抽象層。
3.7 Lessons Learned
DDS支持QoS策略，但在端到端延遲和吞吐量之間存在權衡。在本地案例中，ROS2的開銷延遲並非微不足道。從3.3節開始，延遲是由DDS和DDS事務的兩次數據轉換引起的。 DDS端到端延遲是恆定的，直到消息數據大小低於最大數據包大小（64 KB），如圖9所示。另一方面，當一條大消息被分成幾個數據包時，延遲會急劇增加，因爲顯示在圖10和圖18中，消息數據大小是否超過64 KB是一個重要問題，尤其是在DDS中，因爲管理具有QoS策略的分割數據包需要大量處理時間和某些供應商提供的備用API。我們應該瞭解分組數據包的影響，並在使用DDS時牢記這個問題。雖然DDS和ROS2抽象具有開銷延遲，但OpenSplice比Connext更快地利用了許多線程和進程，如圖13所示。這就是爲什麼我們當前應該在本地情況下在DDS的底層實現中使用OpenSplice的原因。在遠程情況下，雖然開銷延遲是微不足道的，但我們必須考慮帶寬的吞吐量。如圖20所示，就吞吐量而言，Connext優於OpenSplice。無論消息數據量有多小，這種恆定的開銷吞吐量都是可預測的並且存在。特別是當高Hz使用多種主題時。我們建議Connext考慮遠程情況下的最低必要吞吐量。
DDS爲ROS2帶來了實時嵌入式系統的支持。我們認爲ROS2超過了使用DDS的成本。 DDS的容錯性優越，因爲它能夠使用QoS策略保存過去的數據，並且不需要主節點。 DDS保證了公平的延遲，如圖18和19所示。此外，DDS能夠在多個平臺上運行，包括RTOS和交換機DDS實現。在RTPS協議下，任何ROS2節點都相互通信而與其平臺無關。 FastRTPS目前是線程和內存中嵌入式系統的最佳DDS實現，如表6所示，但它不適用於小型嵌入式系統。
由於ROS2正在開發中，我們已經明確了改進ROS2性能的空間，並且DDS的能力爲ROS2帶來了實時嵌入式系統的支持。我們認爲ROS2超過了使用DDS的成本。 DDS的容錯性優越，因爲它能夠使用QoS策略保存過去的數據，並且不需要主節點。 DDS保證了公平的延遲，如圖18和19所示。此外，DDS能夠在多個平臺上運行，包括RTOS和交換機DDS實現。在RTPS協議下，任何ROS2節點都相互通信而與其平臺無關。 FastRTPS目前是線程和內存中嵌入式系統的最佳DDS實現，如表6所示，但它不適用於小型嵌入式系統。由於ROS2正在開發中，我們已經澄清了改善ROS2性能和最大化DDS潛力的能力的空間。首先，ROS2支持的當前QoS策略提供容錯，但它們不足以進行實時處理。 ROS2必須擴展支持的QoS策略的範圍。其次，對於小型嵌入式系統，ROS2需要最小的DDS實現和最小的抽象層。例如，我們需要用於ROS2的C API庫和一個小型DDS實現。由於其抽象層，ROS2很容易支持它們。 FreeRTPS [22] [27]是這個問題的一個很好的候選者，但它正在開發中。第三，我們還闡明瞭對大型消息管理分割數據包的替代API的需求。這對於處理大型消息至關重要。抽象將縮短DDS端到端延遲並實現表4的不足。最後，我們必須調整ROS2的DDS配置，因爲有許多供應商特定的配置選項。