ROS 2-nodes, -topics, -services en -actions

Het Robot Operating System 2 (ROS 2) laat onafhankelijk draaiende programma’s getypte gegevens uitwisselen. Een cameradriver, een motorcontroller, een planner en een gebruikersinterface kunnen losse nodes zijn die via de ROS-graaf met elkaar verbonden zijn. De belangrijke ontwerpbeslissing is niet alleen het berichttype, maar of de interactie een stroom, een korte aanvraag of een langlopend doel is.

Deze gids blijft distributie-onafhankelijk. Opdrachten en kernbegrippen zijn stabiel, maar volg voor installatiedetails en pakketversies de documentatie van de ROS 2-distributie die je daadwerkelijk gebruikt.

Modelleer één verantwoordelijkheid per node

Een node is een deelnemer in de ROS-graaf. Goede nodegrenzen volgen verantwoordelijkheden: een lidardriver publiceert scans, een odometrienode schat de beweging, en een navigator accepteert doelen. Maak niet van elke functie een node — de proces- en communicatieoverhead is alleen gerechtvaardigd als de grens hergebruik, isolatie, uitrolbaarheid of eigenaarschap verbetert.

Namen maken de graaf begrijpelijk. Gebruik beschrijvende node- en interfacenamen zoals /front_lidar, /wheel_odometry en /cmd_vel. Namespaces laten twee robots gelijkwaardige grafen zonder botsingen draaien.

Inspecteer een draaiend systeem voordat je het verandert:

ros2 node list
ros2 node info /wheel_odometry
ros2 topic list -t
ros2 service list -t
ros2 action list -t

node info toont publishers, subscribers, serviceservers en -clients en actions van die node. Het is vaak de snelste manier om een ontbrekende of verkeerd benoemde interface te vinden.

Gebruik topics voor continue stromen

Een topic is asynchrone publish/subscribe-communicatie. Publishers sturen getypte berichten zonder op een direct antwoord te wachten, en een willekeurig aantal subscribers kan ze ontvangen. Topics passen bij gegevens die in de tijd veranderen:

• camerabeelden en lidarscans;
• gewrichtstoestanden en wielodometrie;
• batterijstatus;
• opgedragen snelheid;
• diagnostische gebeurtenissen.

Controleer een stroom vanaf de opdrachtregel:

ros2 topic echo /scan --once
ros2 topic hz /scan
ros2 topic info /scan --verbose

Het berichttype is onderdeel van de overeenkomst. Coördinatenframes, eenheden, tijdstempels en covariantie zijn net zo belangrijk als veldnamen. Een subscriber kan een positie niet veilig interpreteren als hij niet weet of de waarde in meters in map is of in millimeters in een cameraframe.

Quality of Service (QoS)-instellingen beïnvloeden de bezorging. Sensorstromen geven vaak de voorkeur aan recente gegevens boven het opnieuw versturen van verouderde monsters, terwijl status die op configuratie lijkt misschien betrouwbaar of transient-local gedrag nodig heeft. Een publisher en een subscriber met onverenigbare QoS-beleidsregels kunnen in de graaf zichtbaar zijn en toch geen gegevens uitwisselen.

Gebruik services voor korte aanvraag en antwoord

Een serviceclient stuurt een verzoek en wacht op een antwoord van de server. Services passen bij snelle bewerkingen met een duidelijk antwoord:

• een configuratie lezen of bijwerken;
• odometrie resetten;
• een kaart wissen;
• vragen of een component gereed is.

Ze passen slecht bij continue sensorgegevens of een manoeuvre dat seconden kan duren. Een synchrone aanroep die op een trage motorbeweging wacht kan de aanroeper blokkeren en geeft geen standaard voortgangsinformatie of annulering.

Inspecteer en roep een service aan met:

ros2 service type /reset_odometry
ros2 interface show example_interfaces/srv/Trigger
ros2 service call /reset_odometry example_interfaces/srv/Trigger "{}"

Het exacte type in de laatste opdracht moet overeenkomen met de server. Ontwerp antwoorden zo dat ze zowel het slagen van het transport als de betekenisvolle status van de bewerking melden; een ontvangen antwoord garandeert niet dat de gevraagde hardwarebewerking mogelijk was.

Gebruik actions voor langdurige doelen

Een action modelleert een doel dat tijd kost. Het ondersteunt doelacceptatie, periodieke feedback, een eindresultaat en annulering of preëmptie. Navigeren naar een pose en een arm langs een traject bewegen zijn natuurlijke actions.

De interactie heeft drie semantische delen:

• Doel: wat de client wil, bijvoorbeeld een doelpose.
• Feedback: voortgang tijdens de uitvoering, bijvoorbeeld de resterende afstand.
• Resultaat: de einduitkomst en eventuele teruggegeven gegevens.

Actionservers moeten snel op annulering reageren en de hardware in een gedocumenteerde toestand achterlaten. Een client moet afwijzing, annulering, afbreking en succes afhandelen in plaats van elk eindresultaat als voltooiing te behandelen.

Vanaf de opdrachtregel:

ros2 action info /navigate_to_pose
ros2 action send_goal /navigate_to_pose <action_type> '<goal_yaml>' --feedback

Vervang de plaatshouders door het type en de velden die de draaiende graaf meldt. Gebruik de opdracht om gedrag te inspecteren, niet als hardgecodeerde productie-interface.

Kies met één beslistabel

Een topic is niet automatisch “snel”, en een service is niet automatisch “betrouwbaar”. Timing en bezorging hangen af van QoS, middleware, executors, belasting en netwerk. Kies eerst op basis van de semantiek van de interactie.

Eén gedrag kan alle drie gebruiken. Een navigatienode abonneert op scan- en odometrietopics, accepteert een navigatie-action en stelt een korte service beschikbaar om een costmap te wissen. De grenzen blijven duidelijk omdat elke interface een ander soort vraag beantwoordt.

Ontwerp een kleine graaf voor een mobiele robot

Neem een robot met differentiële aandrijving:

1. /encoder_driver publiceert wieltellers.
2. /odometry abonneert op de tellingen, publiceert /odom en zendt odom → base_link uit.
3. /range_driver publiceert afstandsmetingen.
4. /safety_controller abonneert op de afstanden en beperkt /cmd_vel.
5. /navigator accepteert een bewegingsaction en publiceert de gewenste snelheid.

Laat niet twee losstaande nodes de motoren aansturen zonder arbitrage. Geef één component het eigendom van het uiteindelijke actuatorcommando of maak de prioriteitsregel expliciet.

Gebruik standaard ROS-berichttypen als hun semantiek past. Eigen interfaces zijn passend wanneer de gegevensovereenkomst werkelijk projectspecifiek is, en niet alleen om bestaande velden te hernoemen.

Debug de graaf laag voor laag

Als er gegevens ontbreken:

1. Bevestig dat beide nodes in ros2 node list staan.
2. Bevestig de interfacenamen en -typen.
3. Bekijk het aantal publishers en subscribers.
4. Vergelijk de QoS-beleidsregels.
5. Echo één bericht en controleer tijdstempels en frame-ID’s.
6. Controleer logs en executorbelasting.

Als een action nooit eindigt, onderscheid dan “doel niet geaccepteerd”, “server produceert geen feedback meer” en “client heeft het resultaat genegeerd”. Als een service blijft hangen, controleer dan of de callback van de server geblokkeerd is terwijl hij wacht op werk dat eigenlijk een action had moeten zijn.

Vermijd de gebruikelijke architectuurfouten

• Alles gebruikt een topic: aanroepers kunnen niet weten of een eenmalig verzoek is geslaagd.
• Beweging gebruikt een service: lang werk mist voortgangs- en annuleersemantiek.
• Sensorgegevens gebruiken standaard een betrouwbare diepe wachtrij: verouderde monsters hopen zich op wanneer de verwerking niet bijhoudt.
• Frame- en eenheidsconventies zijn ongedocumenteerd: getypte berichten zijn semantisch nog steeds dubbelzinnig.
• Eén reusachtige node bezit elk subsysteem: testbaarheid en foutisolatie verdwijnen.
• Tientallen kleine nodes wikkelen gewone functies in: de graaf wordt lastiger zonder een bruikbare grens toe te voegen.

De Robot Arm Simulator biedt een concrete taak die op een action lijkt: vraag een doel aan, volg de beweging en meld onbereikbare of beperkte uitkomsten. Ga verder met ROS 2 TF2-coördinatenframes om de geometrie van elke node consistent te houden.