ROS

Wij schrijven voorjaar 2018. De ontwikkeling van ROS, het Robot Operating System, is ruim 10 jaar geleden gestart (november 2007). In de academische wereld is het inmiddels de standaard en blijkt het van grote toegevoegde waarde. In de hobby gemeenschap zie je ROS veel minder. Waarom is dat? En is dat erg? En wat heeft ROS te bieden aan de hobby gemeenschap? Zomaar een paar vragen die mij bezighouden en aanleiding waren met ROS aan de slag te gaan.

Wat is ROS

Op deze vraag zijn online veel antwoorden te vinden, bijvoorbeeld hier. Daarbij wordt al snel duidelijk dat ROS geen klassiek operating systeem is, maar een framework dat draait op Linux. De meest gebruikte talen met ROS zijn C++ en Python.

De vraag die veel robot-hobbyisten vervolgens hebben is: hoe is ROS anders dan de robot met een microcontroller en wat voegt ROS toe aan een uitgebreide robot library? Om hierop een antwoord te vinden, wil ik beginnen om te beschrijven wat ROS in essentie is: een verzameling tools om modulair robot software te ontwikkelen. Een aantal belangrijke hiervan zijn:

Een systeem om berichten uit te wisselen tussen 'nodes' en tools om die berichtenstromen te controleren.
Een set van berichten om informatie uit te wisselen, zie zorgvuldig zijn gedefinieerd om onafhankelijk te zijn van de bron of gebruiker.
Een set tools om packages (sets van software) te ontwikkelen en te gebruiken.

Uiteraard is dit maar een topje van de ijsberg, maar het geeft aan hoe ROS anders is dan een robot met een microcontroller. ROS geeft de tools om kleine stukjes software (nodes) te maken die een specifieke taak hebben. En die focus op een enkele taak maakt dat ze die taak heel goed uitvoeren.

De robot software bouw je - als Lego - op met de nodes. De nodes communiceren met elkaar via berichten. Hierdoor maakt het niet uit of de nodes op dezelfde machine draaien, of elders in het netwerk. Zo kun je bijvoorbeeld de essentiële nodes op de Raspberry pi van je robot draaien. En via het netwerk kun je met je laptop meekijken wat de verschillende processen doen en bijvoorbeeld de kaarten (maps) bekijken die worden opgebouwd.

Op dit punt denk je vast aan je arduino robot en vraag je je af wat het voordeel is van je software opdelen in kleine stukjes en die via berichtjes laten communiceren.

ROS zorgt er echter voor dat je de meeste software niet hoeft te schrijven: er is een eindeloos aanbod van packages die je zo kunt installeren om werk voor je uit te voeren. Software om zichtbaar te maken wat de status van de robot is (positie, opbouw van maps, beelden op camera's enz). Software om je robot te simuleren zodat je uren kunt testen zonder slijtage, batterijen laden. Zonder dat je beperkt wordt door de ruimte op je zolderkamer. Software om kaarten op te bouwen uit sensor informatie. Software om je positie op te kaart te bepalen en te corrigeren op basis van sensor data. Om een route te plannen. Om routes te rijden, rekening te houden met (onverwachte) obstakels. En zo voort. En zo voort.

Dus overstappen van Arduino naar ROS?

Dat hangt er vanaf. Met Arduino (of andere microcontrollers) kun je prima robots maken. Voor de meeste sensoren zijn libraries en met eenvoudige algoritme kun je mooie dingen doen. Of misschien niet 'eenvoudig' maar algoritmes die relatief weinig rekenkracht en geheugen gebruiken. Vaak gaat dit samen met de sensoren die wij gebruiken: wielencoders, afstandssensoren op basis van licht of geluid. Sensoren die eenvoudige informatie geven (kleine bandbreedte) en samen met onze algoritmes wedstrijden als RoboRama mogelijk maken.

Niet overstappen ?

Iedere roboteer weet echter dat deze prestaties - hoe indrukwekkend ook - niet in de buurt komen van de ontwikkeling op het gebied van - bijvoorbeeld - zelfrijdende auto's. Twee redenen hiervoor zijn:

Voor zelfrijdende auto's is veel sensor-informatie nodig. Laser-scanners en camera's leveren veel meer data dan onze afstandssensoren, misschien wel een factor 1000 meer. Al deze data moet worden uitgelezen en al deze data moet worden verwerkt. En dat vraagt veel rekenkracht, temeer omdat er zware algoritmes nodig zijn om bijvoorbeeld camerabeelden te verwerken tot bruikbare informatie. En om deze informatie - samen met allerlei andere bronnen - te verwerken tot het juiste stuur- of rem-signaal. Rekenkracht en geheugen dat een embedded controller niet heeft.
We hebben allemaal algoritmes ontwikkeld om een robot besturen. En we weten dus allemaal dat het veel denkwerk vraagt. En de nodige tijd om het goed werkend te krijgen. En dat geldt ook voor de knapste koppen: niemand heeft de tijd om alles zelf uit te vinden. Door hergebruik van wat anderen eerder ontwikkeld hebben kun je aan slag. Met je toepassing. Of met de ontwikkeling van een nog slimmer algoritme voor een probleem. Zoals Isaac Newton zei: op de schouders van reuzen.

Dus als je aan de slag wilt met geavanceerde sensoren, complexe algoritmes of geavanceerde toepassingen wilt ontwikkelen en wel houdt van wat puzzelwerk, dan is ROS wat voor jou.

Wil je een lijnvolger, mazesolver of roborama robot maken? Heb je genoeg aan 'eenvoudige' sensoren, zoals afstandsmeter, lijnsensor e.d.? Wil je helemaal begrijpen hoe je robot werkt? Wil je een robot die zelfstandig kan werken, zonder Linux systeem? Gebruik dan een Arduino, STM32 of andere microcontroller.

De eerste stappen

Dit artikel wordt geen handleiding voor ROS, die zijn er al voldoende. Van veelgebruikte packages is goede documentatie en een veelvoud aan tutorials. Via google kom je snel op fora met suggesties bij specifieke problemen en foutmeldingen.

Dit artikel probeert overzicht te geven en je op weg te helpen met je eigen robot. Als alternatief kun je natuurlijk ook een robot kopen. Bijvoorbeeld de Turtlebot 3 Burger of de Husarion RosBot. Het voordeel hiervan is dat je direct een werkend systeem hebt, inclusief de packages (definities, configuraties) om de robot te besturen, te volgen en te simuleren.

Het pad wat ik gekozen heb is om ROS te configureren voor een bestaande robot. Of dit een begaanbaar pad is, moet nog blijken.

Overzicht

Zoals gezegd is er veel te vinden over ROS. Op ROS.org, op verschillende fora en op youtube. Allemaal te vinden als je weet waar je naar moet zoeken, als je vast loopt op een bepaald punt. Ik had behoefte aan een routebeschijving en die heb ik gevonden in dit boek: Programming with ROS

Daarnaast is het boek Robot Operating System for Absolute Beginners een aanrader, vooral als je een Windows gebruiker bent.

ROS distributies

Voordat we beginnen, moeten we een ROS distributie kiezen. Ieder jaar in mei wordt een nieuwe distributie uitgebracht. Een distributie uit een even jaar wordt 5 jaar ondersteund, de andere distributies worden 2 jaar ondersteund.

Aangeraden wordt om de nieuwste distributie met 5 jaar ondersteuning te kiezen. Voor mij was dat 'Kinect'. Bij een een ROS distributie wordt ook een Linux versie geadviseerd en voor Kinetic is dit Ubuntu 16.04 (Xenial). ROS Kinetic in combinatie met Ubuntu 16.04 was op dat moment waarschijnlijk de meest gebruikte combinatie en daardoor de meest stabiele omgeving waarvan de meeste kennis voor handen is.

Meer info.

De robot

Een robot besturen met een Arduino hebben we vaker gedaan, dus dat was het startpunt: een robot met een Arduino Mega, twee encoder motors voor differential drive en twee Sharp afstandsensoren.

De robot controller moet communiceren met de ROS wereld. In dit geval heeft de controller een seriele interface en dan valt direct de package 'RosSerial' op. Hiermee wordt de controller 'opgenomen' in de ROS wereld en kan (binnen de beperking van de bandbreedte) gebruik maken van ROS functionaliteit. Dit is krachtig, maar dat heeft ook een keerzijde: de controller moet omgaan met 'echte' ros messages en dat blijkt soms meer dan in eerste instantie lijkt. Zo heeft bijvoorbeeld de 'Odometry' message 72 variabelen om de positie en beweging van de robot weer te geven.

Mijn (voorlopige) inschatting is dat RosSerial een goede keuze is als je een krachtige embedded controller gebruikt die voorzien is van de nodige libraries, zoals het OpenCR board van Robotis. Met RosSerial is de verbinding universeel en aanpassingen (uitbreidingen) hoeven alleen op het board doorgevoerd te worden.

Een alternatief om (eenvoudige) robotjes met ROS te gebruiken is om een eenvoudig protocol voor de embedded controller te maken, dat de essentiele gegevens levert of kan ontvangen / opvragen. Op een ROS computer wordt een node gestart die (normaal via een serieele verbinding) communiceert met de embedded controller en met de rest van ROS. Deze node vertaalt zo de berichten die heen en weer gaan. Een voorbeeld hiervan is de ros_arduino_bridge.

De arduino-code in ROSArduinoBridge is aangepast zodat deze werkt met mijn robotje en met behulp van Bluetooth een draadloze verbinding gemaakt met de serieele poort van de pc.

Met het command:

roslaunch ros_arduino_python arduino.launch

wordt het ROS node op de pc gestart en is de Arduino robot verbonden met de ROS wereld.

Robot besturen

Uiteindelijk moet de robot autonoom beweging, maar voor het zover is kunnen we de robot handmatig besturen, op afstandsbediening. Hiervoor gebruiken we de package teleop twist keyboard

Deze package stuurt twist messages, met daarin gewenste snelheid (translatie en rotatie). De package ROSArduinoBridge luistert naar deze berichten en beweegt de robot.

Visualisatie - rviz

De volgende stap is om de positie van onze robot te tonen in rviz, de 3d visualisatie tool van ROS.

toon met een bestaand robot model.
maak model van eigen robot (urdf).
voeg sensoren toe.

Tot nu toe draaide ROS soepel in een virtual machine op een kleine laptop. Rviz blijkt een redelijk zwaar programma. Het draait nog wel, maar reageert tamelijk langzaam. Het is onduidelijk of dit komt door de laptop of ook (mede) door de virtuele machine. De schermtoegang van de virtuele machine geeft mogelijk extra overhead bij dit grafische programma.

Ook anderen melden dat de prestaties van een ROS virtual machine op een lichte laptop tegenvallen. Direct installeren van Linux op dezelfde laptop (al dan niet met dual boot) bevalt beter.

Simulatie - Gazebo

Op het eerste gezicht lijkt de simulator op rviz. Beide tonen de robot en haar bewegingen. Maar waar rviz *TOONT* wat de robot doet, *IS* Gazebo de robot. Op basis van het urdf robot model reageert de robot in Gazebo op twist opdrachten van bijvoorbeeld teleop. Voor Gazebo moet het urdf model worden uitgebreid moet fysieke kenmerken, zoals gewicht en inertie.

In Gazebo kan een 'wereld' worden gebouwd. Zo kun je je kantoor nabouwen of de roborama baan met blikken. De gesimuleerde sensoren op de robot detecteren de objecten zodat je uren kunt testen zonder batterijen laden en zonder slijtage en onderhoud van je echte robot.

Net als rviz is een redelijk zwaar programma.

Opmerking: Tot nu toe ging mijn introductie in ROS voorspoedig. Het boek en alle online documentatie gaven voldoende informatie om - met wat zoeken en proberen - zaken werkend te krijgen. Bij het simuleren van de sensoren treedt echter een probleem op wat nog niet is opgelost. De vraag is gepost op answers.ros.org. Zie hier een oplossing voor een ander probleem op basis van mijn vraag ;)

Ros en RobotLib

Geïnspireerd door de koppeling van de ros-arduino bridge is een koppeling gemaakt tussen RobotLib en ROS, gebaseerd op ROSArduinoBridge. Hierdoor kan niet alleen getest worden met het Arduino robotje, maar kunnen ook RobotLib robots worden bestuurd vanuit ROS en kunnen alle sensoren worden uitgelezen die door RobotLib worden ondersteund.

De kern van deze koppeling zijn eenvoudige berichtjes die heen en weer gestuurd worden. Hieronder twee voorbeelden.

ÁRosTwist  317 0.156767À
ÁRosOdom 130 269 -1.766812 999123À

Het eerste wat waarschijnlijk opvalt zijn de A's met diakrieten aan het begin en het einde. Dit zijn de start- en eindvlag voor het frame met respectievelijk de waarde 0xC1 en 0xC0 (193 en 192). Door deze tekens kan de ontvanger de frames herkennen in de stroom van andere (debug) gegevens. Na de start volgt de naam van het bericht en dan de data, gescheiden door spaties.

De namen van het bericht verwijzen naar het ROS bericht waar ze een relatie mee hebben. Maar voor de goede orde: deze berichten zijn veel eenvoudiger en bevatten veel minder informatie. Precies de informatie die we nodig hebben voor de koppeling met ons (eenvoudige) robotje.

Tips en trucs

Het verhaal hiervoor is redelijk 'hoog over' en voor (actuele) details verwijs ik graag naar de rest van het internet. Maar hieronder toch een aantal 'handigheidjes' en 'weetjes' voor mensen die - net als ik - niet dagelijks met Linux en XML te maken hebben.

In Ubuntu kun je een meerdere terminal windows openen. Soms is dat handig omdat je ze tegelijk wilt bekijken. Maar soms worden het wel veel windows. Met ctrl-shift-T kun je een extra terminal openen in het bestaande windows (tabbed window).
De 'comment tags' in XML zijn . Hiermee kun je een deel van de code uitschakelen in bijvoorbeeld een urdf file of een launch file.
Bij het testen moest ik voor iedere poging alle nodes steeds opnieuw starten. Alles draaide wel, maar er was geen communicatie. Achteraf gezien was de oorzaak eenvoudig: ik liet het aan roslaunch over om roscore te starten, maar die stopt roscore ook als de betreffende node stopt. De rest draait door, maar is niet meer bereikbaar van de roscore als deze opnieuw wordt opgestart. Dus: start zelf de roscore in een eigen terminal window.