- zenohとは、ZettaScale社が開発しているRustで記述されたPub/Subベースのオープンソース通信ライブラリ。
- zenohプロトコルはOSIのセッション層にあたる。
- zenoh APIを使用したzenoh peer間をP2Pで通信を実現する。
- zenohの実装は、Rustで記述されており、非同期通信を使用して実装されている。
- zenohはROS 2の非DDSのRMW実装(rmw_zenoh)として公式にリリースされる。(humble, jazzy以降)
- zenohには通信仮想レイヤが存在しており、TCP/IP通信以外の通信デバイスをサポート比較的簡単に追加することが可能。
- 標準でzenohのルータ機能を使用したアプリケーションとしてzenohdが提供されている。
- 非multicast環境で接続された通信環境でzenohdを使用することでNAT/マスカレード超え機能を実現することが可能となる。
- zenohdのrouterにはpluginAPIが存在しており、pluginとして新規機能を追加することが可能。
- zenohdのplugin機能も、Rustで記述されており、zenohの管理情報にアクセスする場合に使用する。
参考URL:
Pub/Sub通信ライブラリZenohのススメ
すべてが #Zenoh になる 〜柔軟にして軽量〜
zenohは以下のような派生プロジェクトがeclipseプロジェクトで管理されている。
主な言語/プロトコル：
| プロダクト | 説明 |
|---|---|
| zenoh-c | zenohのC言語のAPI実装 |
| zenoh-cpp | zenoh-cのC++のAPI実装 |
| zenoh-python | zenohのpythonのAPI実装 |
| zenoh-pico | C言語で作成された制限（tiny H/W）の環境（RTOS等）への移植を前提とした実装 シリアル等の非TCP/IP通信の対応 |
主なプラグイン：
| プロダクト | 説明 |
|---|---|
| zenoh-plugin-ros1 | zenohネットワークを使用したROS 1プリッジ |
| zenoh-plugin-ros2dds | zenohネットワークを使用したROS 2 DDS(Cyclone DDS) プリッジ |
全プロダクトの詳細は、zenohのソースサイトを参照の事
zenohを使用した基本的なネットワーク構造は以下のようになる。
-
同一ネットワーク内: (VPN/multicast通信が構築できる環境)
ノード探索 : udp/multicastによる直接探索
データ通信 : tcp/unicastによる直接通信
-
異なるネットワーク間 : (VPN/multicast通信が構築できない環境)
ノード探索 : zenohdによるプロキシ探索
データ通信 : zenohd経由のブリッジ通信
※同一ネットワーク内は直接探索・通信と併用可能
| 凡例 | |
|---|---|
| 四角(□) | Zenohの通信タスク |
| 実線(↔) | 同一ネットワーク上での接続 |
| 破線 | 独立したネットワーク間での接続 |
- スループット性能は、Cyclone DDSと同程度。
- 利用するpayloadのサイズが大きくなっても安定した性能が出る傾向がある。
- レイテンシ性能は、singleマシン環境よりmultiマシン環境の方が良い性能を出す傾向がある。
以下の情報を次のサイトから参照している：Comparing the Performance of Zenoh, MQTT, Kafka, and DDS
-
Throughput data in bit/s for the single-machine scenario
（引用： 上記URL） -
Latency data in µs (microseconds) for the single-machine and multiple-machine
Target Single-machine Multiple-machine Kafka 73 81 MQTT 27 45 Cyclone DDS 8 37 Zenoh brokered 21 41 Zenoh P2P 10 16 Zenoh-pico 5 13 ping 1 7
- 最初から広域ネットワークを前提に設計されている。このためにNATのようなFWを超える通信にも対応可能。
- 複数のzenohdを接続することにより、広域分散されたNamespace空間を構築が安易にできる。
- zetta platform(zetta2c)と呼ばれるコンフィグファイルの設定ツールを使用して動的にネットワーク網の構築が可能。
- 基本は、通信ライブラリのみの実装のために、ROS1/2のような連動したプロダクトがまだ存在しない。
- ローカル環境でのみ使用する場合には、恩恵があまり感じられない。(ROS1/2で作成したほうが効率が良い）
- コミュニティの特徴として、過去の資産への配慮が足りないバージョンアップが行われる傾向がある。
- zenoh 0.x と zenoh 1.x系では通信ができない。同一系でもマイナーバージョンが変わっただけでも動作しない場合がある。
サーバークライアントモデルとは異なり、ピア（ノード）間でデータを直接交換することができる接続方式の総称。
現在、P2Pのグラフ接続の構成は、以下のように分類できる。
- ピア型
- ハイブリッド型
- スーパーノード型
詳細は、総務省のPDFを参照：P2Pネットワーキングの現状と将来 p.11)
zenohは、基本的な通信プロトコルの為にどのような形態のトポロジーも構築することができる。
- Clique
- Mesh
- Brokered
- Routed
zenohは起動時のコンフィグレーションの設定により以下の３つのカテゴリに分類される。
- zenohルータ
- zenohセッション（ピア）
- zenohクライアント
- 自身の所属するセッション内のセッションノードの接続状態の監視や、別ホストの上のセッションとのブリッジの機能を提供する。
- 通常ローカルマシン上のP2P通信には使用されない。
- ホスト間の通信のブリッジ/集中ブローカーとして使用される。
- 別のホスト上のセッションと通信を実施しない環境では起動する必要が無い。
- zenohルータは、マルチキャストの機能を使用し自身のネットワーク内のセッション情報を取得する。
- 他のzenohルータとunicastで通信することで内部情報を交換する。この機能により全体のネットワークを管理することが可能となる。
- zenohの基本通信単位。一般的に、一つのセッションは一つのendpointを構成する。
- 一般的には、zenoh通信とはこの形態を表す。
- zenohセッションは、単体で他のセッションと直接P2P接続が可能となる。
- zenohのネットワークを使用可能な最低機能の実装。
- 自身でP2Pネットワークを構築する機能はなく、他のzenohセッションやzenohルータに自身を登録して通信を行う。
- 最初に接続したzenohセッションがブリッジ機能を実施することによって実現する。このために、接続しているセッションが停止すると通信は停止する。
- zenohの各動作モードは、以下の様な構成となり、使用する拡張機能でモードを変更する。
- 動作モードを変更することで使用できる機能が異なる。
-
以下の方法でzenohの動作設定を修正することが可能
種類 形式 タイミング ファイル json形式のファイルを環境変数により 起動時 プログラム zenoh api zenohのセッション開始時 admin space http （再調査必要） zenoh起動後（再調査必要）
- zenohdは、zenohルータの機能を持つアプリケーション実装の一つ。
- zenohdは、zenohのルータ機能を使用して遠隔地のROS 2の環境をzenohを使用して接続する。
- zenohdは、zenohプロトコルを使用することによって、vpn越しでも通信可能。
- zenohdは、zenohの配布イメージにデフォルトで実装されている。
- zenohdは、zenohプラグインのベースとなる。
- admin space情報へのアクセス機能を持ち、外部の管理ツールから使用される。
- zenohプラグインとは、zenohルータ機能に使用可能な拡張機能の総称。
- ローカルなプロトコルとzenohで通信可能なブリッジとして使用されている。
参考： Integrating ROS 2 with Eclipse zenoh
-
Cyclone DDSとZenohのプロトコルの相互変換するプラグイン。
-
特徴
- ROS 2のトピック/サービス/アクションをブリッジを使用してアクセスできる
- ROS 2の各ツール類を使用することが可能となる
- ROS 2のnodeのコントロールではなくzenoh bridge(plugin)のネームスペースで管理する
- zenohのアプリケーション(ex. zettaplatform,,)と連動できるようになる
- 接続先の発見処理の簡略化
-
現時点でサポートしているROS 2の通信
- Publishers/Subscriptions
- Service/Clients
- Events
- Actions
- Quality of Service
-
制限事項 (2025/01/08)
- 使用できるDDSはCyclone DDSのみ
- ROS 2 DomainIDの機能は正常に動作しない。
- nodeの取り扱いが独自仕様のために、"ros2 node info"等のコマンドは正常に動作しない。(plugin名をnode名として使用)
- export ROS_LOCALHOST_ONLYが使えない。（zettascale側で修正中）
zenoh ライブラリ
- Rust言語で記述されたアプリケーション層で動作するプロトコル実装。
- 受信処理は、非同期処理（tokio）を使用している。
- zenohの各モードは、zenohライブラリの使用方法(接続モード等)で変更可能だが、ソースとしては単一。
zenoh-c ライブラリ
- zenoh-cとは、RustのC言語へのextern機能を利用して、C言語とRustの差を埋めるためのライブラリ。
- zenoh-cは、全てRust言語で記載されている。
zenoh-cpp ライブラリ
- zenohのc++のAPI実装である。
- ヘッダのみで実装されている。
- zenoh-c/zenoh-picoを通信ライブラリとして選択する事ができる。
zenoh-pico ライブラリ
- zenoh-picoは、組み込みシステム等制約のあるデバイスをターゲットとしている。C言語で記述されたzenohライブラリのサブセットである
- コンフィグレーションファイルの機能はオミットされている。パラメータ等はソースに直接記載で指定可能
- マルチthread / シングルthreadでも運用可能であるが、シングルthreadの場合は非同期処理の実装が必要
- zenoh全体も含めて、デバイスのコントロールはzenoh自体では実施しない
このためにOS等の別途デバイスのコントロールの仕組みが必要となる
zenoh-picoの機能
| 種類 | ユニキャスト探索 | マルチキャスト探索 |
|---|---|---|
| ルータ | ✕ | ✕ |
| セッション（ピア) | ✕ | ○ |
| クライアント | ○ | ○ |
※注1) ユニキャストのセッションのフレームワークは存在するがnon-implemetとの事
サポートされているプラットホーム(2024/07/08現在)
Linux
MacOS
BSD
Windows
ESP-IDF
Mbed
Zephyr
Ardunio ESP32
Ardunio OpenCR
Emscripten
Flipper
FreeRTOS-Plus-TCP
Comparison of Middlewares in Edge-to-Edge
参考URL:
ROS 2 RMW alternate
ROS 2 Alternative middleware report
ROS 2 RMW alternateで学んだメモ
現在のDDSを使用したROSノード間通信には、以下の問題が存在する。
- DDS has a fully-connected graph of participants (for multi-cast)
DDSを使用する場合、各ノードの検索はマルチキャストによる完全接続グラフが必要になるために、ノードの更新等の接続情報の同期のために通信量が指数関数的に増大する。 - DDS uses UDP multicast for discovery (for multi-cast)
DDSでノード探索に使用されているmulti-castは、実ネットワーク運用では無効にされている場合が多い。 また、運用されていても動画配信等の特殊な用途や、ルータ等の設定で特別な調整が必要となる。 - DDS can have difficulty transferring large data(for udp)
UDPで大きなデータを転送する場合、一般に使用されているTCP通信にほど最適化されていない。UDPの場合、データの欠損等を検査する場合、全てのデータを取得する必要があるが、最適なUDPのバッファサイス等を事前に想定するのは非常に難しい。 - DDS can struggle on some WiFi networks(for multi-cast / udp)
wifi上でudp multi-castを有効にしてない環境でDDSを使用する場合、非常に困難となる。 - DDS tends to have complex tuning parameters (DDS)
DDSの調整パラメータが多すぎる。 - Vendor specific non-standard DDS extensions (DDS)
各ベンダーのDDS拡張が多く開発されており、オープンソースで使用できないものもある。
実際は、１から４項目の解決案として投票が実施されzenohが選択された。 ※５−６については、zenohでも多くなるかもしれない。しかし、ネットワーク自身の調整をOS側にまかせているので、ある程度は軽減されると考えられる。
- zenoh通信は、完全接続グラフを必須としない。（P2P接続グラフすべてを構築可能）
- zenohdを併用することでマルチキャストの通信環境以外でも運用が可能。
- zenohは、TCPベースの実装のために、大容量のデータ送信時のパケット単位の再送機能実装されている。
- TCPベースのため一般的なwifiの設定との親和性は高い。
上記の内容に以下の利点も追加される。
- zenohはスーパーノード型のP2P構造を持ち、ルータ機能によりNAT（マスカレード）の環境下のマルチキャストを禁止した環境でも運用できる。
また、RMWの開発チームの開発方針として以下の方針が打ち出されている。
- 安定して動くものを出す。（パフォーマンスのチューニングは以降の課題）
- ネイティブのRustでの実装ではなくzenoh-cの実装を使用する。開発リソースの関係
- ネットワークが安定しない環境下での再ルーティング機能等は今後の課題
したがって、rmw_zenohは以下の問題を持つユーザに対して有効と考えられる。
- 使用するノードの生成・削除の回数が多い
- マルチキャストのIGMP設定等の融通が効かない環境（情シス的な全体のネットワーク管理部門との調整が面倒）
- 使用するトピックデータのサイズが大きい（再送の効率化）
- NATの運用、又はマルチキャストが使用できない環境での運用
ベンチマーク等はこのあたりを前提にして性能を測定することが有効と考えられる。
逆にノード内の単純な性能の向上が目的の場合、性能の向上が無い（遅くなる）場合も考えられる。
- DDS以外で初めて採用されるRMW実装の一つ。
- rmw_zenohでは、ROS 2のRMW APIを経由して実行され、zenohネットワークを使用したRMW APIの実装を提供する。
- ROS 2のノードは、zenohのセッションにマップする形で使用される。
| ライブラリ | 言語 |
|---|---|
| ROS 2 RMW API | C++ |
| rmw_zenoh_cpp | C++17以降 |
| zenoh-c | Rust |
| zenoh | Rust |
| ネットワーク形態 | rmw_zenoh |
|---|---|
| ビア型 | △ |
| ハイブリッド型 | - |
| スーパーノード型 | ○ |
- rmw_zenohで通信を実施する場合は、zenohd機能が必須となるためにスーパーノード型になる。
- 検索情報等は各ノードが保持しているため、障害時にはピア型の側面も持つ。zenohdが再起動したときに検索情報が自動的に再構築される。
参考URL:
ROS 2のZenoh対応とZenohのROS 2対応
今後は以下のような調査項目・開発方針が考えられる。
rmw_zenohを使用したmicro-ros/mrosの実装はコミニュティではリリースされていない。
トータルシステム提供の一環としてmicro-rosとの接続は有効と思われる。
本機能のプロトタイプは、rmw_zenoh_picoとしてOSS公開中
Reference implementation of Zenoh-pico to micro-ROS
Cyclone DDSを使用したROS 2環境は、zenoh-plugin-ros2ddsの機能を使用して、zenohプロトコルで利用可能なトピックに変換される。
また、rmw_zenohでは、ROS 2からリクエストを直接zenohプロトコルに変換する。
しかしながら、両者のlivelinessの値が異なっていために直接通信はできない。
DDSとzenohは、お互いを置き換えるのではなく、不得意な分野を補完し共存する環境が望ましいと考えられる。
このために既存のROSの環境と共存できる選択肢を提供するのは有効である。