ROS 2 RMW alternateで学んだメモ
海洋ロボコンをやってた人です。
今回はROS Japan UG #53 ROSCon & ROSCon JP ふり返り会にて、ROS 2 Alternative middleware reportを読んでみると良いということだったので、英訳と殴り書きで学んだことをメモしておきます。
※ 通信プロトコルについて詳しくないので、記載に間違いがある可能性もございます。
詳細を知りたい方は、リンク先の文献をご自身で読むことを推奨します。
ROS 2 Alternative middleware report
上記の内容をピックアップして記載していきます。
Abstract
ROS MiddleWare interface (RMW) は、ROS 2ので使用されている通信の抽象化レイヤーです。
RMWはDDS に基づいており、過去8年間の使用を通じユーザーからのフィードバックより次のような問題が上がる。
- RMWのTier 1実装はDDSであるため、DDSの詳細がIFを通じて漏洩する可能性がある
- DDSには参加者の完全に接続されたグラフがあり、システム内のネットワークエンティティの数が制限される (problem 2)
- DDS検出は、デフォルトでマルチキャストUDPに依存。 多くの導入環境では、マルチキャストUDPがサポートされていない/到達できるネットワークの範囲が制限されているため、サイレント検出の失敗が発生する (problem 3)
- DDSは、多くのロボットSWの基礎となる大きなメッセージ (画像、点群など) を扱うのに苦労することがある (problem 4)
- DDSは、UDPマルチキャストが無効になっている場合/ネットワーク接続が不安定な場合、WiFi ネットワーク上で問題が発生する可能性がある。
- DDS は、理想的ではないネットワークの構成が複雑になる場合がある。
User Challenges with DDS
2015年頃にROS 2 開発が開始されて以来、ミドルウェアとして DDS を使用。
DDS が選択されたのは、ROS と同じ目標の多くに取り組んでおり、さまざまな分野にわたる大規模でミッションクリティカルな展開の長い歴史があり、DDS を使用した8年の経験がある。
その間、一貫して困難の原因として上記の6つの問題が浮上。
以下、6つの問題の一部を説明している。
- DDS has a fully-connected graph of participants (problem 2)
設計により、DDS は完全に接続されたグラフを作成および維持。
ネットワーク内のすべての参加者、トピック、およびサービスは、他のすべての参加者によって検出される必要があるため、検出のための
ROS 1 とは対照的に、ネットワーク内での新しいトピックの作成には比較的コストがかかるため、ネットワーク内のノードとトピックの数が制限される。
- DDS uses UDP multicast for discovery (problem 3)
大規模な WiFi ネットワークでは、パフォーマンス上の理由からデフォルトでマルチキャストが無効になっていることがよくある。
また、UDP マルチキャストが有効になっているネットワークであっても、UDP マルチキャストが通過できるネットワークセグメントは制限されていることがよくある。
これは、複雑なネットワーク設定全体で機能するように DDS 検出を構成することが難しい可能性があることを意味する。
- DDS can have difficulty transferring large data (problem 4)
標準に従って、DDS はパケット配信のデフォルトの基礎となるネットワーク プロトコルとして UDP を使用しており、DDS で大きな画像や点群を転送しようとすると、カーネルとユーザーランドのUDPバッファがいっぱいになる可能性がある。
これは、接続が信頼できない可能性がある WiFi ネットワークで特に問題なる。
この問題は、より大きなバッファサイズを要求するようにDDS層を構成し、カーネルのUDPバッファサイズを調整することで回避できるが、ユーザーが要求の厳しい UDP アプリケーション向けにシステムを構成する微妙なニュアンスを学習する必要があり、場合によっては Wireshark などの低レベルのネットワーク診断ツールを使用する必要がある。
- DDS can struggle on some WiFi networks (problem 5)
一般に、DDS を WiFi 上で動作させるのは困難な場合がある。
WiFi ネットワークが UDP マルチキャストを許可しており、接続が良好な傾向にある場合、DDS はかなり良好に動作するが、これらの条件のいずれかが当てはまらない場合、DDS はデータを配信するのに苦労する可能性がある。
Requirements gathering
コアチームは、ROS 2 トランスポート/ミドルウェアの要件のリストを収集。
User Survey
ユーザー調査 2023/7/31、ROS 2 コアチームは、RMW 実装の代替案を作成する意図を述べて、コミュニティにアンケート形式でフィードバックを送信。
調査内容の詳細は文献参照を推奨しますが、要約としては以下です。
which best describes your organization?
→ 回答者の54.8%はSmall Business/Startup、残りはLarge Business、Academia、Research Organization、Hobbyistが数10%ずつ占める。
Technical Data
→ 43.5%が 10 台未満の小規模なロボット群を所有、33.3%が 10 ～ 100 台のロボットを所有17.2％が100〜1000台のロボットを所有、さらに大規模なロボット群を所有している回答者も少数人いる。
Which container technologies do you use?
→ 回答者の93.6％はコンテナに Docker または Podman を使用。Virtual machine with NATsは13.5%
Alternative middleware option
→ Zenoh はユーザーから最も多く提案された代替案だが、TCPROS、MQTT、および ZeroMQ の実質的なサポートがあった。
Performance
いくつかのミドルウェアの詳細なパフォーマンス分析が以下によって行われた。
- Zenoh vs MQTT vs Kafka vs DDS
- Fast-DDS vs CycloneDDS
- Fast-DDS vs ZeroMQ
- Kafka vs ActiveMQ vs RabbitMQ
上記の内、Zenoh, MQTT, Kafka, DDSパフォーマンス比較は以降にメモをまとめています。
Conclusion
ROS 2 ユーザーからの要件が収集され、現在利用可能なミドルウェア オプションが調査された。
調査の結果より、Zenoh が要件を最もよく満たしていると結論づけられ、代替ミドルウェアとして選択されることになる。
この実装に関しては、設計上の決定がまだ多く残っており、詳細について開発が開始される際に https://discourse.ros.org で説明される。
Zenoh, MQTT, Kafka, DDSパフォーマンス比較
上記をサッと目を通して、Zenohが代替案として良いことがわかるのだが、パフォーマンスの観点から見ないとよく分からなかったり、そもそもMQTT / DDSなどに詳しくないと理解しにくいので、こちらもメモ書き程度に記載します。
Zenoh vs MQTT vs Kafka vs DDSのパフォーマンス比較A Performance Study on the Throughput and Latency of Zenoh, MQTT, Kafka, and DDSは以下を参照してください。
予備知識
パフォーマンス比較を理解するための予備知識を以下で復習。
ご存知の方はスルーしてください。
TCP/UDP
- TCP(Transmission COntrol Protocol)
3ウェイハンドシェイクという手順で通信相手とコネクションを確立し、データを送受信するコネクション型の通信プロトコル。
信頼性のあるプロトコルであり、データの到達と順序が確実である。
また、再送処理や順序付けが行われ、データの正確性が保たれ、データが送信中に損失や変更があった場合、それを検知して修復する。
- UDP(User Datagram Protocol)
パケットの再送制御などを一切行わないコネクションレス型の通信プロトコル。
信頼性よりもシンプルで軽量な低遅延なプロトコルとなっており接続確立などの手続きが不要で、リアルタイム性が重要なアプリケーションに適している。
DDS（Data Distribution Service）
- 特徴
高性能、信頼性の高い、分散型リアルタイム接続のための OMG (Object Management Group) 標準であり、UDPマルチキャスト機能を利用して、トランスポート層でメッセージをブロードキャストする。
-
利点
ローカルネットワーク内での高速ピア検出(高リアルタイム性)とQoSベースの低遅延データ送信が可能。 -
欠点
オープン環境やワイヤレス環境において通信制約やフラッディングの影響や、柔軟性や機能の多様性によりオーバーヘッドが発生する可能性がある。
- 利用例
ROS 2の認定された Tier-1 RMW (ROS ミドルウェア) 実装の 1 つであり、現在は ROS 2 パッケージに同梱。Cyclone DDS は、TTTech Auto、Autoware、Apex.AI、AutoCore、その他の採用企業など、ロボット工学および自動運転車の業界およびプロジェクトですでに広く採用されている。
Zenoh
- 特徴
クラウドからエッジおよびモノの連続体をサポートする新たに開発されたパブ/サブベースのデータ中心通信プロトコルであり、高性能および高スケーラビリティの特徴を持ち、信頼性が高い。
TCP、UDP、TLS/mTLS、QUIC、Websocket、UNIX ドメイン ソケット、さらには Bluetooth やシリアル データ リンクなどの非IPプロトコルなど、ピア間でさまざまなトランスポートプロトコルを使用することもできる。
- 利点
Zenoh は完全分散システムとして、P2P通信(peer-to-peer communication)をサポート。 Zenoh ピアは、ピア同士が直接通信できるため集中ブローカーによる制約を回避できる可能性がある。
Zenohの詳細は以下のPub/Sub通信ライブラリZenohのススメが非常に分かりやすく勉強になります。
MQTT
- 特徴
IoT 分野で使用される最も一般的な通信プロトコルの 1 つ。
非常に軽量なパブリッシュ/サブスクライブ メッセージングトランスポートとして設計されており、設置面積が小さくネットワーク帯域幅が限られているリモート デバイスを接続するのに最適。
プロトコルは、通信に3つの異なる QoS レベルを提供する。
QoS0：最高1回配信 / ベストエフォート (Best Effort) レベルの品質
QoS1：最低1回配信されることを保証
QoS2：正確に1 回だけ配信されることを証
- 利点
軽量かつシンプル: シンプルで軽量なプロトコルで、ネットワークリソースを効率的に使用。
広範なサポート: IoTデバイスやクラウドなど、さまざまな環境で使用可能。
- 欠点
リアルタイム性の制約: DDSほど高いリアルタイム性は提供されない。
MQTTの詳細は以下が勉強になります。
Apache Kafka
- 特徴
高スループットで低遅延のデータ フィードを提供することを目的としたストリーム処理プラットフォーム。
データには、Zenoh、MQTT、DDS と同様のトピックによって名前がつけられ、プロデューサはトピックの異なるパーティションにメッセージをパブリッシュすることができ、メッセージは各パーティション内のオフセットによって順序付けされる。
パーティション内のメッセージは FIFO 順にで、1 つのプロデューサーがメッセージをさまざまなパーティションに分散し、スループットをスケールアップできる。
- 利点
レプリケーション(複製品:レプリカを作っておくこと)をサポートしているため、大規模なデータストリーミングアプリケーションの構築が可能。
Apache Kafkaの詳細は以下が勉強になります。
Evaluation Results
以下、評価結果より気になる項目を抜粋。
Latency Results(Single-machine Scenario)
レイテンシ テストでは、「ping」プログラムが ping メッセージを発行し、「pong」プログラムが ping を受信すると同じメッセージで応答し、 各ping/pongペアの往復時間 (RTT：round-trip time) が測定され、遅延値が RTT/2 として計算。
結果は、「Zenoh-pico」で示されているように 5 usが最小値で、Cyclone DDS のレイテンシーよりも低くなった。これはZenoh プロトコルとその実装が軽量で、デフォルトのP2Pモードの Zenoh は、MQTT や Kafka と比較してレイテンシーが最も短くなるため。
Tab. 2 Latency data in microseconds for the single-machine scenarioより引用
| Target | Latency(us) |
|---|---|
| Kafka | 73 |
| MQTT | 27 |
| Cyclone DDS | 8 |
| Zenoh-brokered | 21 |
| Zenoh-p2p | 10 |
| Zenoh-pico | 5 |
| ping | 1 |
Conclusion
パフォーマンス比較の結果から、基本的なスループットとレイテンシーのベンチマークでは、Zenoh が MQTT、Kafka、および DDS よりも全体的に優れたパフォーマンスを示していることがわかる。
Zenoh は、クラウドからエッジ、そしてモノへの連続性をシームレスにサポートできる産業および IoT アプリケーションにとって最良の選択肢の 1 つになると信じられている。
以上、「2023-09 ROS 2 RMW alternate」と「A Performance Study on the Throughput and Latency of Zenoh, MQTT, Kafka, and DDS」で学んだことのメモでした。
何か、訂正内容などあればご指摘ください。
ここまでご覧いただきありがとうございました。
Discussion