ROS

De ontwikkeling van ROS, het Robot Operating System, is ruim 10 jaar geleden gestart. 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? 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. Daarbij wordt al snel duidelijk dat ROS geen klassiek operating systeem is, maar 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

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.

In eerste instantie gekeken naar RosSerial om deze robot te verbinden met de 'ROS wereld', maar dit (b)lijkt opgevolgd door 'ros_arduino_bridge'. De versie van HBRC gebruikt, maar achteraf gezien lijkt dit een betere fork: ros_arduino_bridge.

De arduino-code in ROSArduinoBridge 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.

Zoals eerder gemeld: dit is een verhaal op hoofdlijnen, veel details zijn weggelaten. Details over aanpassingen om de Arduino code werkend te maken op de robot en over de configuratie van de ROS node. De github pagina van de ros_arduino_bridge beschrijft grotendeels hoe je dit doet.

Robot besturen

[teleop twist keyboard]

rviz

De volgende stap is om de positie van onze robot te tonen in rviz.

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