ROS 2-basis: nodes, frames en robotvision
Je kunt een robot opbouwen uit ROS 2-nodes, goed kiezen tussen topics, services en actions, en de waarnemingen van een camera in de framestructuur van de robot plaatsen.
Alles elders op deze site draait op een microcontroller: één programma, één lus, totale controle. ROS 2 is waarheen je verhuist wanneer een robot daar te groot voor wordt — wanneer hij een camera, een planner en een driverstack heeft die allemaal tegelijk moeten draaien, geschreven door verschillende mensen en onafhankelijk herstartbaar.
De prijs is een reeks nieuwe ideeën, en het eerste is dat een ROS 2-robot geen programma is maar een graaf van nodes die met elkaar praten. Het meeste van de vroege verwarring komt door de verkeerde keuze tussen de vier manieren waarop ze kunnen praten, en daarom begint dit leertraject daar: topics voor datastromen, services voor snelle aanvragen, actions voor lange taken die je misschien moet annuleren.
Dan TF2, en dat is het onderdeel dat stilletjes mensen laat falen. Een robot is een boom van coördinaatframes — de basis, de wielen, elke sensor — en vrijwel elke echte bug is een transformatie die ontbreekt, verouderd is, of aan de verkeerde ouder hangt. Zodra frames kloppen, wordt een gekalibreerde camera gewoon nog een node die een pose in die boom publiceert, en zo sluit vision aan op de rest van de robot.
Voordat je begint
Je moet je thuis voelen op een Linux-commandoregel en Python of C++ kunnen lezen. Een Raspberry Pi is het gebruikelijke doel, maar alles tot aan de hardwarenodes draait op een laptop. Reken op een avond voor de installatie zelf — ROS 2 is een gedistribueerd systeem, en het gedraagt zich vanaf het eerste commando ook als zodanig.
Wat je aan het eind kunt
- Juist kiezen tussen een topic, een service en een action, in plaats van van alles een topic te maken en de grenzen later te ontdekken.
- Een TF2-frameboom bouwen die een punt uit een sensorframe naar dat van de robot transformeert, en die debuggen wanneer een transformatie ontbreekt.
- Een camera kalibreren, de pose van een marker verkrijgen en begrijpen waar de getallen ten opzichte van staan.
- Een
cmd_vel-twist omzetten in linker- en rechterwielsnelheden, met verzadiging die de opgedragen boog behoudt.
Waar mensen vastlopen
Nodes vinden elkaar niet. ROS 2-discovery is automatisch totdat het dat niet meer is. Twee machines
met verschillende ROS_DOMAIN_ID-waarden zijn onzichtbaar voor elkaar, en wifi die multicast blokkeert
breekt discovery volledig terwijl elke node zich volkomen gezond meldt.
Niet-overeenkomende QoS. Een publisher die best-effort aanbiedt en een subscriber die reliable eist verbinden nooit, en — onhelpzaam — geen van beide logt een fout. De topic vervoert simpelweg niets. Sensordata is de gebruikelijke boosdoener, want sensordrivers kiezen vaak standaard voor best-effort.
Vergeten de workspace te sourcen. Een nieuwe terminal weet niets over je packages tot die
gesourced is, dus ros2 run meldt een package die duidelijk bestaat als ontbrekend.
Een frame met twee ouders. TF2 is een boom. Hetzelfde childframe publiceren uit twee bronnen geeft het twee ouders, en zoekacties beginnen intermitterend te falen afhankelijk van de timing — een van de lastigere ROS-bugs om te zien, omdat hij meestal wel werkt.
Lege tijdstempels en frame-ID’s. Een bericht waarvan de header geen frame_id heeft kan niet
worden getransformeerd, en een bericht waarvan de stamp nul is komt nergens mee overeen. Allebei
passeren ze het typesysteem zonder morren en falen pas wanneer er iets ze samen gebruikt.
Wat je nodig hebt
| Wat | Waarom dit leertraject het nodig heeft | Opmerkingen |
|---|---|---|
| Een Linux-commandoregel waarin je je thuis voelt | ROS 2 is een systeem dat primair op Linux gericht is, en de tooling gaat daar van uit | Ubuntu komt overeen met de officiële binaries; alles betekent zelf bouwen |
| Python of C++ | Nodecode wordt in een van de twee geschreven | Python leer je sneller; C++ is wat de prestatiekritische nodes gebruiken |
| Een machine met een echt scherm | Een gedistribueerd systeem via SSH debuggen is nodeloos pijnlijk | Een laptop is een betere plek om te leren dan een headless Pi |
| Een Raspberry Pi (alleen voor de hardwarenodes) | Pas nodig zodra de robot zijn eigen computer meedraagt | Een Pi 4 of beter; een Pi Zero stelt teleur |
| Een camera (alleen voor de vision-node) | De laatste node van het leertraject | Een Pi Camera-module of een willekeurige UVC-webcam |
| Een avond voor de installatie | Geen grapje — dit is onderdeel van het leertraject | De installatie is werkelijk de eerste lastige stap |
Waarom dit leertraject in deze volgorde loopt
Communicatiepatronen komen eerst omdat de verkeerde keuze later duur is. De vier manieren waarop ROS 2-nodes praten zijn niet uitwisselbaar, en de klassieke beginnersfout is van alles een topic maken — en dan driehonderd regels verder ontdekken dat je annulering en voortgangsfeedback nodig had en actions met de hand aan het herbouwen bent. Tien minuten nadenken tussen topic, service en action bespaart een herschrijving.
TF2 komt als tweede omdat het het onderdeel is dat stilletjes mensen laat falen. Zodra meerdere nodes gegevens over de fysieke wereld publiceren, betekent elk daarvan “3 meter” ten opzichte van iets anders — de camera, de basis, de kaart. TF2 is hoe die dingen samenhangen, en de meeste echte ROS-bugs zijn een transformatie die ontbreekt, verouderd is of aan de verkeerde ouder hangt. Het als apart onderwerp leren, voordat je het nodig hebt, is veel goedkoper dan het tegenkomen als een raadselachtige zoekactie die mislukt.
Camerakalibratie komt als derde omdat die volledig van de tweede afhangt. De pose van een marker betekent niets zolang je niet weet waar hij ten opzichte van staat. Zodra frames kloppen, is een gekalibreerde camera gewoon nog een node die een pose in de boom publiceert, en is vision geen bijzonder geval meer.
De aandrijvingsnode sluit het leertraject af omdat daar ROS de hardware ontmoet waar alles andere op
deze site over gaat. Een cmd_vel-twist is de standaardinterface die elk ROS-navigatiecomponent
spreekt, en die omzetten in linker- en rechterwielsnelheden — met verzadiging die de opgedragen boog
behoudt in plaats van haar te vervormen — is de brug tussen de ROS-wereld en de motorwereld.
Controlepunten: hoe je weet dat een etappe is geland
| Etappe | De controle | Hoe een succes eruitziet |
|---|---|---|
| Installatie | ros2 topic list in een frisse terminal |
Het werkt na het sourcen, en je weet van tevoren waarom het misgaat |
| Twee nodes | Draai talker en listener op twee machines | Berichten komen aan — en je kunt de domain-ID noemen die ze delen |
| Topic versus service | Schrijf er één van elk voor dezelfde gegevens | Je kunt in één zin zeggen waarom elk patroon bij zijn taak past |
| Actions | Start een lange action en annuleer die halverwege | Hij stopt netjes, en je kreeg feedback terwijl hij draaide |
| QoS | Zet de betrouwbaarheid op een topic bewust verschillend | Hij vervoert stilletjes niets — nu herken je het symptoom |
| TF2-boom | Draai ros2 run tf2_tools view_frames |
Eén boom, één wortel, geen frame met twee ouders |
| Transformatie opzoeken | Transformeer een punt uit een sensorframe naar het basisframe | Het getal klopt, en je kunt het controleren met een rolmaat |
| Verouderde transformaties | Stop een transformatiepublisher terwijl er een zoekactie loopt | Je krijgt een extrapolatiefout — de storing heeft nu een naam |
| Camerakalibratie | Kalibreer en controleer de reprojectiefout | Ruim onder één pixel; een grote waarde betekent dat de opnameset slecht was |
| Pose van een marker | Zet een marker op een gemeten afstand en lees de pose | Komt overeen met de rolmaat, en je kunt zeggen in welk frame hij staat |
cmd_vel |
Publiceer een twist met zowel lineaire als hoektermen | Beide wielen draaien correct, en het verzadigen van het ene schaalt het andere mee om de boog te behouden |
Waar dit leertraject ophoudt
Dit leertraject bouwt de fundamenten onder een ROS 2-robot — hoe nodes praten, hoe frames samenhangen en hoe een sensor en een aandrijving in de graaf komen. Het stopt bewust voor de grote subsysteemen die allemaal al veronderstellen.
Het behandelt niet de Nav2-stack, het standaardantwoord op autonome navigatie in ROS 2 en op zichzelf
een behoorlijk systeem — costmaps, behaviour trees, planners en regelaars, allemaal geconfigureerd in
plaats van geschreven. Nav2 gaat uit van een werkende TF-boom en een cmd_vel-interface, en dat is
precies wat dit leertraject je geeft.
Het behandelt niet URDF en robotbeschrijving, het XML-formaat dat de rest van ROS vertelt van welke vorm je robot is. Alles hier publiceert transformaties met de hand; URDF is hoe je daarmee ophoudt.
Het behandelt niet simulatie in Gazebo, waarmee de meeste serieuze ROS-ontwikkeling zich feitelijk afspeelt, en ook niet ros2_control, de standaard hardware-abstractielaag voor echte aandrijvingen.
En het behandelt niet real-timegedrag. ROS 2 is gebouwd op DDS en is hier veel krachtiger dan ROS 1 ooit was, maar een Linux-machine die een Pythonnode draait is geen real-timeregelsysteem. De strakke lussen — balanceren, stroomregeling, alles op kilohertzniveau — horen nog steeds op een microcontroller, met ROS 2 erbovenop. Die verdeling is de normale architectuur van een serieuze robot, geen compromis.
Leerroute
De route
Volg de knooppunten op volgorde – elk ontgrendelt het volgende zodra je het hebt afgerond. Je voortgang wordt op dit apparaat opgeslagen.
0 / 5 klaar
Veelgestelde vragen
Veelgestelde vragen
Wanneer moet een robot overstappen van Arduino naar ROS 2?
Wanneer één lus niet meer genoeg is. Een microcontroller met één enkel programma is de juiste architectuur voor een lijnvolger, een doolhofoplosser of iets waarvan het hele gedrag in één regellus past — en het is werkelijk beter dan ROS 2 voor die dingen, omdat het deterministisch is en je het allemaal in je hoofd kunt houden. ROS 2 verdient zijn complexiteit wanneer een robot meerdere dingen heeft die tegelijk op verschillende snelheden moeten draaien — een camerapipeline, een planner, een driverstack — die op verschillende momenten geschreven zijn en onafhankelijk herstartbaar zijn. De prijs is een gedistribueerd systeem, en het gedraagt zich vanaf het allereerste commando ook als zodanig.
Topic, service of action — hoe kies ik in ROS 2?
Koppel het communicatiepatroon aan de taak. Een topic is een datastroom zonder antwoord: sensordata, odometrie, snelheidsopdrachten — alles wat continu wordt gepubliceerd waarvoor de laatste waarde telt. Een service is een snelle aanvraag met een antwoord, voor dingen die binnen milliseconden klaar zijn, zoals een parameter opvragen of een modus omschakelen. Een action is voor lange taken waar je voortgang van wilt of die je moet kunnen annuleren — naar een doel navigeren, of een grijper rond een object sluiten. De meest voorkomende vroege fout is van alles een topic maken en er daarna met de hand aanvraag-antwoordsemantiek bovenop bouwen.
Waarom vinden mijn ROS 2-nodes elkaar niet?
Drie oorzaken dekken vrijwel alles af. Verschillende ROS_DOMAIN_ID-waarden maken twee machines volledig onzichtbaar voor elkaar terwijl beide zich volkomen gezond melden. Wifi-netwerken die multicast blokkeren breken het discovery-protocol volledig, en daarom vinden nodes elkaar vaak wel over ethernet en niet via het kantoor-accesspoint. En niet-overeenkomende QoS — een publisher die best-effort aanbiedt terwijl een subscriber reliable eist — betekent dat de twee nooit verbinden, en geen van beide logt een fout. Controleer als eerste de domain-ID; dat kost niets en is meestal het antwoord.
Wat is TF2 en waarom blijven transformaties falen?
TF2 beheert de boom van coördinaatframes op een robot — basis, wielen en elke sensor — zodat je kunt vragen waar een punt in het frame van de camera ligt ten opzichte van het frame van de robot. Zoekacties falen om drie terugkerende redenen. Een frame met twee ouders breekt de boom, en omdat het alleen faalt afhankelijk van welke publisher de race won, werkt het meestal wel. Een lege frame_id in een berichtheader betekent dat het bericht helemaal niet getransformeerd kan worden. En een nul- of verouderde tijdstempel betekent dat de transformatie bestaat, maar niet op het moment dat je vroeg. Alle drie passeren het typesysteem zonder morren.
Heb ik een Raspberry Pi nodig om ROS 2 te leren?
Nee. Alles behalve de hardwaredrivernodes draait prima op een laptop, en dat is een betere plek om te leren — snellere builds, een echt scherm, en geen risico dat een kapotte SD-kaart je een avond kost. Een Pi wordt pas nodig wanneer je wilt dat de robot zijn eigen computer meedraagt. Gebruik je er toch een, verwacht dan dat de Pi de beperkende factor is: een camerapipeline en een planner samen vinden snel de grenzen van een Pi 4.
Waarom zegt ros2 run dat mijn package niet bestaat, terwijl dat duidelijk wel zo is?
Je hebt de workspace in die terminal niet gesourced. Elke nieuwe terminal weet niets over je gebouwde packages tot je het install-setupscript sourced, en ROS rapporteert het resultaat als een ontbrekende package in plaats van als een niet-gesourcede omgeving. Het is de meest voorkomende ergernis in ROS 2, hij overkomt iedereen steeds opnieuw, en de standaardmitigatie is hem vanuit je shellprofiel te sourcen — met de kanttekening dat je het probleem dan juist verbergt als je echt twee workspaces hebt.