はじめに
背景紹介を交えて
Advent Calendar 2024の企画として、Space ROS (Robot Operating System)について集中的に解説/紹介しています。Space ROSの以下の機能構成のうち、本編前後ではコア（中核）について話しています。
Space ROSは宇宙品質ROS(2)を目指すプロジェクトで、その「宇宙品質」とは、いわゆるNASA規格 NPR7150.2のClass Aを目指す、としています。
Space ROSで採用しようとしているリアルタイムOS（RTOS）であるRTEMSについては一昨日こちらで紹介しています。
また、Space ROSはRTOSでなきゃいけないの？という素朴な疑問について考察した記事を昨日作成しました。結論としては、やりたいこと次第だけどClass AアプリケーションならYesだろうなぁ、だからやっぱりRTEMSなのかなとなります。
本編について
昨年（2023）秋頃のことですが、Space ROS開発に深く関わっている某アメリカ企業の方に、Zenohってどう思う、と聞かれたのですが、その時私はその存在すら知りませんでした。その後調べてみると、確かに現状ROS2でデフォルトで使用されているDDSと、zenohの比較評価の調査結果がズラッと並んでいました。少なくともROS2界隈ではホットな話題なのは間違いないです。
国内でも東大の高瀬英希先生がZENOHについてROSCONJP24で話されていたのをリアルタイムで聴講させて頂いたのと、ROSCON24でも気炎を吐かれておられます。また、Advent Calendarにもzenohとして立っていたので、かなり盛り上がっている模様です。
高瀬先生のROSCON24報告
本編ではSpace ROS中心なので、現状宇宙ロボットとして、また、Space ROSとしてzenohはどうだろう、というコンテキストで議論を進めていきます。
結論から言うと、宇宙ではないロボットでも同じ結論になるのだと思いますが、単体宇宙ロボット、および、地上の操作卓でシステムが閉じる場合にはDDSでも全く差し支えなく、むしろDDSでQoS制御等が効くのは有利に働くかもしれませんが、クラウド等ネットワーキングを広く考える場合にはZenohに軍配が上がると考えています。要するに、Space ROS/宇宙ロボットだからといって直ちにZenohに一気に舵を切ろう、とはならないということで、Space ROSや私としてはROS2での今後の推移を見守ることになると思っていますが、有人拠点や宇宙ステーションなど、Zenoh向けの有望なアプリケーションは存在すると考えられます。
なお、本編では上記結果によって私の時間等不足でZenohをいじれていませんので、調査結果からの考察となります。もしハンズオンの結果等はZenohのAdvent Calendar等をご確認いただくのがよろしいかと思います。
宇宙ロボットとして、また、Space ROSとしてzenohはどうですか？
まずは、Zenohのウェブサイトの構造からZenohの調査を行いました。その後DDSとの比較調査、そして、宇宙ロボティクスアプリケーションにおけるポテンシャルについて議論します。
Zenohとは
Zenohでできることは、分散ストレージ、クエリ、クエリ可能の抽象化により、あらゆる規模の分散アプリケーションの開発が簡素化です。Pub/Sub効率的なpub/subプリミティブを提供。複数レベルの信頼性、動的検出、断片化、およびワイヤ レベルのバッチ処理をサポートをします。Zenohの実装はリソースも小さく住み、最小の実装では、Atmel 8 ビット マイクロコントローラー上でわずか 300 byteのフットプリントしか使用しないとのことです。
Zenohの一番の特徴は柔軟で堅牢なpub/subの動作です。
pub/subの動作はネットワークアプリケーションにとって柔軟に対応が可能です。システムに接続されたサブスクライバーは、Zenohネットワークを介して効率的にルーティングされたパブリッシャーによって送信された値を受信します。また、ネットワークに接続されたスリープ状態のサブスクライバーも許容できて、そのサブスクライバーが起動すると、最も近いZenohノードが保留中のpubを送信します。
要するに、比較的大きなロボットシステムでノードの出入りがあったり、クラウド上につながったりしたときにはその効力を発揮します。
ROS2の現デフォルト通信層「DDS」との比較
ROS2の現デフォルト通信層はDDSです。そんな中DDSをZenohで置き換えるのは意味があるのか？という観点を議論します。
＊QoS ポリシーとデータ タイプの互換性Zenoh ルーターまたは DDS 検出サーバーの可用性が原因とのこと
[3] https://zenoh.io/blog/2023-03-21-zenoh-vs-mqtt-kafka-dds/ Comparing the Performance of Zenoh, MQTT, Kafka, and DDS (2023)
[4] https://zenoh.io/blog/2021-03-23-discovery/ Minimizing Discovery Overhead in ROS2 (2021)
[5] https://arxiv.org/pdf/2309.07496v1.pdf Comparison of DDS, MQTT, and Zenoh in Edge-to-Edge/Cloud Communication with ROS 2 (2023)
高信頼のPeer2Peer通信が特徴のDDSに対し、Zenohは「Zenohとは」で言及したようにwifiや4Gを含む通信ネットワークに強みを持ちます。従来の使用場所限りで閉じるロボット（これがこの先当面も多いと思いますが）に対し、近傍のロボットシステムやIoT、クラウドにあるサーバーなどに積極的にアクセスに行くシステムにはZenohが有効と考えられます。
宇宙ロボティクスアプリケーションにおけるポテンシャル
上記「ROS2の現デフォルト通信層「DDS」との比較」で結論はかなり出ていると思いますが、セキュリティ的にも厳しい人工衛星および宇宙ロボットの通信局はともかく地上局としては単一箇所から運用されるケースがほとんどになると思います。したがって、宇宙機側も閉じたシステムになることも多いと思われますので、一般的には当面DDSでも問題ないと考えられます。
一方で、近傍のロボットシステムやIoT、クラウドにあるサーバーなどに積極的にアクセスに行くシステムはどういうものが考えられるでしょうか？ 地上での用途を考えたときにもそうかもしれませんが、IoTデバイスを入れ替わり立ち変わりで使うような状況というと、例えば有人拠点や宇宙ステーションが考えられると思います。それらは宇宙のスマートホームになっていくと思われます。宇宙機が入れ代わり立ち代わり入ってきては出ていく。ものも同時に入ったり出たりします。宿泊客が来るかもしれませんし、実験も実施するでしょう。インフラとしては、電力、通信のメンテがあるのと、生命維持装置のメンテナンスも必要でしょう。いずれにせよこういう状況になっていけばZenohの出番になっていくのではないでしょうか。そして、以前ここで言及したように、輸送コストは低減してきており、機は熟しつつあるようにも思えます。