VPN 越しの ROS 2：ディスカバリはデータ経路ではない

VPN の両端にある二つの ROS 2 ノードは、互いのトピックを一覧表示できても、メッセージを一つも配信できないことがあります。ディスカバリとユーザーデータは別々の経路を持つ別々の交換であり、ディスカバリサーバーはペイロードを中継しません。一方を確認して他方を仮定することが、トンネルがデータを運んでいなかったのにミドルウェアを交換してしまう原因です。以下の手順は、何かを交換する前に二つの結果を切り分けます。

ディスカバリサーバーが実際に運ぶもの

Fast DDS では、Discovery Server がエンドポイントに関する情報を配布します：誰がパブリッシュし、誰がサブスクライブし、それぞれがどの QoS を期待するかです。ピア同士が互いを認識すると、ユーザーデータはそのサーバーを経由せず、直接やり取りされます。サーバーに到達できることは、紹介のブローカーが応答していることだけを示します。ルーティングされた VPN では、ピアがアドバタイズするアドレス間の双方向に機能する経路が依然として必要です。

この区別は、既存のピアがデータを交換し続ける一方で新しいディスカバリが機能しなくなる部分的な障害も説明します。これらは二つの調査として扱ってください。

ノードが実際に使っている RMW を読む

ROS 2 はさまざまなミドルウェアを読み込めますが、シェルでエクスポートした変数は、別の場所で起動したプロセスには届きません。ターミナルの履歴ではなく、実行中のシステムに問い合わせてください。

printenv RMW_IMPLEMENTATION
ros2 doctor --report | head -n 20

変数が設定されていない場合は通常、インストール済みのデフォルトを意味し、同じ実験内のマシン間で異なることがあります。レポートには使用中のディストリビューションとミドルウェアも表示されるので、一致すると仮定する前にトンネルの両側で比較してください。ROS のコマンドラインデーモンは状態をキャッシュするため、環境を変更したら再起動し、古いデーモンに古い構成を答えさせないでください。セッションが開いている間に、両方のホストのディストリビューションと RMW をテストメモに記録してください。

ディスカバリとデータを二つの結果として試す

無害なトピックを選び、紹介と配信を別々に測定します。info コマンドはエンドポイントと QoS を一覧表示し、echo はメッセージが実際にリンクを越えるかどうかを証明します。

ros2 topic info /chatter --verbose
ros2 topic echo /chatter --once

info の出力にエンドポイントが現れることはディスカバリの結果です。メッセージがサブスクライバーに届くことはトランスポートの結果であり、アプリケーションが必要とする経路を試すのは後者だけです。ディスカバリが機能し echo がタイムアウトする場合は、ディスカバリサービスではなく、アドバタイズされたアドレスと戻り経路を調べてください。各ホストから両方のコマンドを実行してください、非対称な VPN 経路は片側からしか明らかにならないことがよくあるからです。

一度に一つの依存関係だけを変える

データ経路が失敗した場合、後から結果を帰属できなくなるため、同じセッションでミドルウェア、ディスカバリモード、メッセージサイズを変更するのは避けてください。Zenoh RMW は正当な選択肢ですが、そのルーターはトンネル経由で到達可能でなければならない別の依存関係になります。

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

その RMW では、ルーターが Jazzy のデフォルト構成でディスカバリを運び、そこではマルチキャストディスカバリが無効になっているため、この依存関係は他のミドルウェアから借りた仮定ではなく、メモに記載すべきものです。一つの設定を変える間はワークロードを固定し、その後 echo テストを繰り返して、方向、メッセージレート、リンク条件を記録してください。比較を二回実行し、実際の改善と偶然の再接続を切り分けてください。変更がディスカバリを改善しても配信が同じままなら、移動したのは紹介サービスであり、データ経路ではありません。