ROS2測評——探索ROS2的性能

Exploring the Performance of ROS2

文章目錄

• Exploring the Performance of ROS2
• • 1. INTRODUCTION
  • • Contribution:
    • Organization:
  • 2. BACKGROUND
  • • 2.1 Robot Operating System (ROS)
    • 2.2 Data Distribution Service (DDS)
  • 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網絡連接配接，無需任何其他網絡。

  ROS1和ROS2節點之間的通信需要一個ros_bridge [33]，這是一個轉換DDS主題的橋接節點。 ros_bridge計劃已由開源機器人基金會（OSRF）釋出[2]。 ros_bridge動态地為ROS2中的節點編組幾個主題。是以，在（3-a）和（3-b）中，啟動ros_bridge，ROS2節點在其上運作。圖6顯示了用于評估從ROS1到ROS2的通信的節點圖。請注意，在使用ros_bridge時，唯一使用的是besteffort政策，因為ros_bridge不支援QoS政策中的RELIABLE政策。

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政策在節點數儲存消息中是不同的。雖然此數字會影響資源，但這不會影響延遲，因為存檔郵件是在每個釋出中進行的。

  最後，通過将片段大小更改為64 KB的最大UDP資料報大小，使用OpenSplice在（2-b）中測量片段開銷。 Connext和OpenSplice的最大有效負載源自此UDP資料報大小，因為将大資料劃分為多個資料報會對QoS政策的許多實作産生重大影響。 如圖16所示，随着片段資料大小的增加，端到端的延遲會降低。 對于大的片段大小，DDS不需要将大資料分成許多資料報，這意味着更少的系統調用和更少的開銷。 就端到端延遲而言，我們應該在使用大資料時将片段大小預設為64 KB。

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

  到目前為止，我們已經從幾個角度闡明了通過ROS2實作DDS的特性：ROS2功能，延遲，吞吐量，線程數和記憶體消耗。我們可以從實驗結果中通過ROS2獲得DDS的見解和指導。它們對DDS和ROS使用者有意義。

  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配置，因為有許多供應商特定的配置選項。