VPN 経由の ROS 1 トピック: 告知されたエンドポイントをたどる

ワークステーションはトンネル経由で ROS 1 の master に到達しているのに、トピック一覧は空のままです。このパターンがよくあるのは、master への登録とトピックの転送は別々の会話であり、master を通るのは最初の会話だけだからです。以下のチェックリストは二番目の会話、すなわちパブリッシャーが告知するエンドポイント、サブスクライバーが到達できなければならないアドレス、そして両者が会話できるようにする許可をたどります。ここにあるのはすべて旧来の ROS 1 に限定した話で、その Noetic のサポート期間は 2025 年五月に終了しました。

ステップ 1: master への接続がトピックへの接続ではないことを示す

動くものと動かないものを切り分けることから始めます。rostopic list が成功したということは、シェルが master の XMLRPC ポートに到達でき、master がトピックを把握していることを示すだけで、サブスクライバーがパブリッシャーに到達できるかどうかは何も語りません。下の三つのコマンドでその違いが可視化され、いずれも読み取り専用です。

echo "$ROS_MASTER_URI"
rostopic list
rostopic info /chatter

rostopic info の出力にはパブリッシャーのノード URI が示され、それはパブリッシャーのホスト上の XMLRPC アドレスです。そのアドレスこそサブスクライバーが次に呼び出すものなので、サブスクライバーが動くどこからでも到達できなければなりません。それがロボット自身の LAN にしか存在しないインターフェースを指している場合、master の検索は成功してもデータは決して届きません。

ステップ 2: 告知されたエンドポイントをノード自身から読む

ROS 1 は、ROS_IP か ROS_HOSTNAME のどちらかが設定されていればそこから告知するホスト同一性を選び、そうでなければホスト自身の名前解決に戻ります。実際に起動されたプロセスの環境を調べてください、というのも systemd ユニット、コンテナ、あるいは二つ目の端末は、テストが通ったシェルとは異なる値を持っていることがあるからです。

echo "$ROS_IP" "$ROS_HOSTNAME"
rosnode info /talker
getent hosts robot-host

ホスト名の告知は、すべてのピアがその名前を意図した到達可能なアドレスに解決する場合にのみ機能します。その名前がロボット自身のネットワーク内でしか解決されない場合、トンネルの反対側にあるワークステーションには使う手立てがなく、DNS サフィックスを一切配らない VPN はその不一致をさらに悪化させます。トポロジーが経路化されている場合、ROS_IP をトンネルのアドレスに設定するのがより小さな変更です。どちらを選ぶにしても両端のために記録してください、同一性について意見が食い違うパブリッシャーとサブスクライバーは交渉したうえで接続に失敗するからです。

告知された URI がどのピアも経路を持てないアドレスを使っているなら、ここで止めてください。間違ったインターフェースに解決される名前は、どれだけファイアウォールをいじっても直りません。

ステップ 3: 告知されたアドレスを解決可能かつ経路化されたものにする

URI を手にしたら、ロボットからではなくサブスクライバーのホストから到達性を試します。TCPROS ポートは交渉の間に選ばれるので、早い段階で有効なテストは XMLRPC ポートであり、後の段階で有効なテストは確立済みのソケットです。片方向にしか存在しない経路は経路化 VPN でよくある故障であり、戻りの経路は行きの経路と同じだけ重要です。

ip route get 10.70.0.2
nc -vz 10.70.0.2 33911
ss -tnp dst 10.70.0.2

経路化された TUN インターフェースは、ロボットの Ethernet セグメントを広げることなくこれらの IP の会話を運び、これは通常、遠隔の運用者が望むものです。スタックの何かが代わりにブロードキャストや multicast に依存しているなら、その要件は別に評価する必要があります、一つのツールを満たすためにトンネルを TAP に変えると、すべての参加者にとってネットワークが広がるからです。

経路または戻りの経路が欠けているなら、ここで止めてください。自分のホストでは応答するがワークステーションからは到達できないパブリッシャーは、ルーティングの問題を抱えており、ROS の問題ではありません。

ステップ 4: ピア間の会話を許可し、一つのトピックを観察する

交渉された会話に必要なポートだけを開き、各ルールを宣言された参加者に限定します。master のリスナーはトピックのペイロードを中継するものではないので、それだけを許可してもパブリッシャーのエンドポイントは閉じたままです。ROS のリスナーは公開インターネットにさらすのではなく、プライベート VPN の境界に置いてください。

rostopic hz /chatter
rostopic echo -n1 /chatter
rosnode ping /talker

実際のパブリッシャーから実際のサブスクライバーへ無害なトピックを一つ観察し、告知されたエンドポイントと応答経路の両方を確認します。メッセージが一つ届けば経路が機能している証拠であり、安定したレートが続けば開いたままである証拠です。アクチュエータの制御と安全確認は、このネットワークだけのテストの外に置いてください、トピックが動くことはロボットが動くことを保証しないからです。観察した ROS のバージョンとエンドポイントの組を記録し、次の担当者がトポロジーの変更と退行を見分けられるようにします。

告知された URI にサブスクライバーから到達でき、交渉されたポートがそのピアにだけ開いており、宣言されたトピックが一つ流れ、両ホストの環境値が記録されていれば、チェックリストは完了です。旧来の ROS 1 はこの領域で修正を受け取らないので、記録こそが人が入れ替わった後も機能し続ける部分です。