Zwei ROS 2-Knoten an gegenüberliegenden Enden eines VPN können die Themen des jeweils anderen auflisten und trotzdem keine einzige Nachricht zustellen. Discovery und Nutzdaten sind getrennte Austauschvorgänge mit getrennten Pfaden, und ein Discovery-Server leitet keine Nutzdaten weiter. Das eine zu prüfen und das andere anzunehmen, führt dazu, dass Teams die Middleware austauschen, obwohl der Tunnel die Daten nie übertragen hat. Der folgende Ablauf trennt die beiden Ergebnisse, bevor etwas ausgetauscht wird.

Was der Discovery-Server tatsächlich trägt

In Fast DDS verteilt ein Discovery Server Informationen über Endpunkte: wer veröffentlicht, wer abonniert und welche QoS jeder erwartet. Sobald Peers voneinander wissen, laufen Nutzdaten direkt zwischen ihnen statt über diesen Server. Den Server zu erreichen beweist, dass der Vermittler der Bekanntmachungen antwortet, mehr nicht. Ein geroutetes VPN braucht weiterhin einen funktionierenden Pfad in beide Richtungen zwischen den Adressen, die die Peers ankündigen.

Diese Unterscheidung erklärt auch Teilausfälle, bei denen bestehende Peers weiter Daten austauschen, während neue Discovery nicht mehr funktioniert. Behandeln Sie beides als zwei Untersuchungen.

Lesen Sie die RMW, die die Knoten wirklich nutzen

ROS 2 kann verschiedene Middleware laden, und eine in Ihrer Shell exportierte Variable erreicht keine Prozesse, die anderswo gestartet wurden. Fragen Sie das laufende System statt Ihre Terminalhistorie.

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

Eine nicht gesetzte Variable bedeutet meist den installierten Standard, der sich zwischen Rechnern im selben Experiment unterscheiden kann. Der Bericht nennt auch die Distribution und die verwendete Middleware, vergleichen Sie beides auf beiden Seiten des Tunnels, bevor Sie annehmen, dass es übereinstimmt. Der ROS-Kommandozeilen-Daemon speichert seinen Zustand zwischen, starten Sie ihn nach einer Umgebungsänderung neu, statt einen veralteten Daemon für die alte Konfiguration antworten zu lassen. Notieren Sie Distribution und RMW beider Hosts in den Testnotizen, solange die Sitzung offen ist.

Testen Sie Discovery und Daten als zwei Ergebnisse

Wählen Sie ein harmloses Thema und messen Sie die Bekanntmachung getrennt von der Zustellung. Der Befehl info listet Endpunkte und QoS auf, während echo beweist, ob eine Nachricht tatsächlich die Verbindung überquert.

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

Dass Endpunkte in der info-Ausgabe erscheinen, ist ein Discovery-Ergebnis. Dass eine Nachricht beim Abonnenten ankommt, ist ein Transportergebnis, und nur das zweite beansprucht den Pfad, den die Anwendung braucht. Wenn Discovery funktioniert und echo in eine Zeitüberschreitung läuft, prüfen Sie die angekündigten Adressen und die Rückroute statt des Discovery-Dienstes. Führen Sie beide Befehle auf jedem Host aus, denn eine asymmetrische VPN-Route zeigt sich oft nur von einer Seite.

Ändern Sie jeweils nur eine Abhängigkeit

Wenn der Datenpfad ausfällt, vermeiden Sie es, Middleware, Discovery-Modus und Nachrichtengröße in derselben Sitzung zu ändern, da sich danach kein Ergebnis mehr zuordnen lässt. Die Zenoh-RMW ist eine legitime Alternative, aber ihr Router wird zu einer weiteren Abhängigkeit, die durch den Tunnel erreichbar sein muss.

export RMW_IMPLEMENTATION=rmw_zenoh_cpp
ros2 run rmw_zenoh_cpp rmw_zenohd

Unter dieser RMW trägt der Router Discovery in der Standardanordnung von Jazzy, und Multicast-Discovery ist dort deaktiviert, daher gehört die Abhängigkeit in Ihre Notizen statt in eine von anderer Middleware entlehnte Annahme. Halten Sie die Arbeitslast fest, während Sie eine Einstellung ändern, wiederholen Sie dann den echo-Test und erfassen Sie Richtung, Nachrichtenrate und Verbindungsbedingungen. Führen Sie den Vergleich zweimal durch, um eine echte Verbesserung von einer glücklichen Wiederverbindung zu trennen. Wenn eine Änderung Discovery verbessert, während die Zustellung gleich bleibt, haben Sie den Bekanntmachungsdienst verschoben, nicht den Datenpfad.

Ähnliche Artikel