Robotica. Het bouwen van een autonome robot Profielwerkstuk VWO Daniel Boon Stefan Janssen

Transcriptie

1 Robotica Het bouwen van een autonome robot Profielwerkstuk VWO 2004 Daniel Boon Stefan Janssen

2 Robotica 2 Inhoudsopgave Inleiding 3 Doelstellingen 4 Deel I: Het prototype 5 Elektronica 5 Voortbeweging 7 Constructie 9 Tast en zicht 10 Deel II: De de nitieve versie 13 Motivatie 13 De opbouw - fotoverslag 14 Deel III: De software 22 Inleiding 22 Infrastructuur - het besturingssysteem 22 De intelligentie van de robot 24 Evaluatie 29 Hardware 29 Software 30 Suggesties voor verder onderzoek 32 Nawoord 35 Bronvermelding 36 Bijlage 1: Plan van aanpak 37 Bijlage 2: Logboek 38 Bijlage 3: Broncode software 45 Bijlage 4: Schema s, prints en constructietekeningen 51

3 Robotica 3 Inleiding Het idee om iets te bouwen voor ons pro elwerkstuk hadden we al vanaf het begin: een werkstuk maken zoals we al zo vaak hadden gedaan wilden we niet. Alleen maar informatie opzoeken over een bepaald onderwerp of een of ander verschijnsel onderzoeken mondt meestal toch uit in het raadplegen van een eindeloos aantal bronnen en op het eind van de dag heb je dan weer een werkstuk over een onderwerp. Ook valt er dan niet zo veel te presenteren: slechts luisteren naar hoe iets werkt of in elkaar zit is niet echt interessant. De motivatie raakt dan op een gegeven moment op en dat komt het werkstuk ook niet ten goede. We wilden dus iets gaan bouwen. Iets als een hovercraft of een robothand. Het laatste was echter veel te ambitieus. Zelfs professionele onderzoekers doen hier jaren over. De hovercraft viel ook af omdat je dan wel een hovercraft hebt, maar die heeft geen echt doel. Na even verder te hebben gekeken op internet, kwamen we op het idee om een robot te maken die door een doolhof heen kan lopen en ook de uitgang kan vinden. In de praktijk kan dit uitmonden in een volwaardige robot die bijvoorbeeld in de stad op zoek moet naar een bepaalde bestemming om daar een pakketje af te leveren. We zijn beiden geïnteresseerd in robotica en Daniel had al wat ervaring met elektronica en we hadden allebei al eens geprogrammeerd. Dit pro elwerkstuk zien we als een algemene inleiding in de robotica. We wilden thuis raken in de meest belangrijke aspecten, zoals mechanica, elektronica, kunstmatige intelligentie en informatica. De beste manier was wat ons betreft om dit allemaal te combineren door zelf aan de slag te gaan met het ontwerpen van een geheel autonome robot. Hierbij komen al deze aspecten uitgebreid aan de orde en ben je verplicht je erin te verdiepen omdat je alles zelf moet toepassen. Bovendien doen we hier nuttige praktische ervaring op. We hebben zoveel mogelijk geprobeerd onze keuzes te motiveren en door naar bestaande projecten en kennis te kijken niet het wiel opnieuw te hoeven uitvinden. We moeten dit project dus echt zien als een begin; de verschillende onderdelen bieden ieder voldoende uitdaging om verder onderzoek naar te doen en misschien hebben mensen die in robotica zijn geïnteresseerd wat aan dit verslag. De indeling van het verslag is grotendeels chronologisch; we hebben er echter voor gekozen om eerst de elektronica te behandelen en daarna pas de software; dit komt niet overeen met hoe we het onderzoek werkelijk uitgevoerd hebben. Tijdens het ontwikkelen van de hardware waren we al bezig met concrete ideeën voor de software. Ook hadden we al wat uitwerkingen gemaakt om niet voor verrassingen komen te staan. Verder hebben we voor ieder onderdeel van de hardware wanneer deze af was, enkele testprogramma s geschreven om te testen of we het hardwareonderdeel juist konden aanroepen en aansturen. Hierdoor waren we er vrij zeker van dat het ons ging lukken de robot zijn einddoel op een redelijk ef ciënte manier te laten vinden. In dit verslag leggen we vooral uit waarom we voor diverse oplossingen hebben gekozen. Natuurlijk komen we er niet onderuit op diverse technische aspecten in te gaan, maar dit hebben we tot een minimum beperkt om het geheel interessant en leesbaar te houden. We hopen dan ook dat dit verslag veel leesplezier verschaft!

4 Robotica 4 Doelstellingen Goed, het is dus de bedoeling dat er een robot gemaakt gaat worden die door een doolhof heen gaat lopen en de uitgang vindt. Wat moet die robot hier voor kunnen? De robot zal zichzelf moeten kunnen verplaatsen. Voortbeweging werd dus het eerste punt. Maar een blinde robot zal niets doelgericht kunnen uitvoeren. De robot heeft hulpmiddelen nodig om de omgeving te verkennen: zicht. We hadden al voorzien dat zicht op sommige punten kon falen, dus hebben we nog een onderdeel erbij bedacht om dit op te kunnen vangen: tast. Als laatste zal de robot moeten weten wanneer het doel bereikt is. Communicatie met de buitenwereld is dus de laatste eis aan de robot. Vervolgens hebben we deze punten in een schema gezet en zijn we gaan brainstormen over welke oplossing per onderdeel ideaal zou zijn en welke oplossing voor ons model haalbaar en betaalbaar is. Dit heeft geleid tot het volgende schema: Onderdeel Ideale oplossing Model Voortbeweging Motors Stappenmotors Zicht Camera, GPS Sonar, infrarood sensors Communicatie Spraaksynthesizer, spraakherkenning Speaker, eindpunt De oplossingen die we hebben gekozen te gebruiken in ons model, wijken om verschillende redenen af van de ideale oplossingen. De redenen hiervoor zijn dat de ideale oplossingen simpelweg te duur zijn, of te moeilijk toe te passen.

5 Robotica 5 1. Het prototype 1.1 De elektronica Een van de meest voor de hand liggende manieren om een robot (een vorm van) intelligentie mee te geven is door deze te voorzien van een computer. Een computer kan veel verschillende taken snel uitvoeren en is exibel omdat de software steeds kan worden aangepast. Door de robot te voorzien van een computer leg je alleen zijn fysieke eigenschappen vast. Het zenuwstelsel van de robot wordt dan gevormd door de software, die later veranderd en ontwikkeld kan worden, zonder dat er steeds aanpassingen moeten worden gedaan aan de hardware. De microcontroller Een gewone computer is voor ons doel echter veel te log. De basis van ons project vormt dan ook de microcontroller. Een microcontroller is een soort minicomputer die in één chip is ondergebracht. Zo bevat de microcontroller een processor om taken uit te voeren, een vast programmageheugen (het ashgeheugen) waarin de software wordt ingeladen (vergelijkbaar met de harde schijf van een gewone computer), een werkgeheugen waarin berekeningen worden uitgevoerd en poorten om met de buitenwereld te kunnen communiceren. Microcontrollers worden tegenwoordig in allerlei elektronische apparaten toegepast, denk bijvoorbeeld aan mobiele telefoons, tv s en DVD-spelers. Het grote voordeel van een microcontroller is dat deze erg klein is, weinig vermogen verbruikt en in alle soorten en maten te verkrijgen is. De microcontroller die wij voor onze robot gebruikt hebben, de Atmega161, heeft ongeveer de rekenkracht van een gra sche rekenmachine en een programmageheugen van 16 kilobyte. Enig vooronderzoek wees uit dat het betrekkelijk eenvoudig was om met deze controller tot een werkend resultaat te komen, vooral omdat het mogelijk was om de programma s hiervoor in BASIC te schrijven. BASIC is een van de eenvoudigste programmeertalen en is snel te leren; hierdoor konden wij ons concentreren op de software zonder eerst veel ervaring op te moeten doen met een taal. Om ook echt iets te kunnen doen beschikt een microcontroller over een groot aantal poorten. De microcontroller kan zelf bepaalde poorten activeren, en andere poorten uitlezen. Zo is het mogelijk om op een bepaalde poort bijvoorbeeld de stand van een schakelaar uit te lezen, terwijl op een andere poort een lamp wordt aan- of uitgezet. Ook kunnen poorten worden gebruikt voor (digitale) communicatie; bijvoorbeeld met een PC. Hierdoor is het mogelijk om zelf de software op een computer te schrijven en deze via zo n verbinding in de microcontroller te programmeren. De testopstelling Om een microcontroller daadwerkelijk aan de gang te krijgen en er ook nog iets zinvols mee te doen moeten er een aantal elektrische verbindingen worden gelegd. Normaal gesproken worden dit soort verbindingen gesoldeerd, maar omdat ons prototype nog aan verandering onderhevig is, is dit niet erg praktisch. We hebben er daarom voor gekozen om het elektronische gedeelte op te bouwen op een zogenaamd breadboard. Dit is een bordje waar je verschillende elektronische onderdelen in kunt prikken die je vervolgens met draadbruggen kunt verbinden. Op afbeelding 1 is zo n breadboard te zien; De grote zwarte chip in het midden is de microcontroller. Door een externe voeding wordt het breadboard voorzien van de juiste spanningen. Later zal deze voeding

6 Robotica 6 vervangen worden door batterijen. Een microcontroller heeft weinig onderdelen nodig om te functioneren. Naast de benodigde spanning van 5V hoeft er alleen nog een kristal of resonator te worden aangesloten. Dit onderdeel produceert wanneer het van spanning wordt voorzien een blokgolf van een bepaalde frequentie, bijvoorbeeld 8 Mhz. Aan de hand van dit onderdeel bepaalt de processor in de microcontroller zijn klokfrequentie; bij elke puls wordt een volgende stap in het programma uitgevoerd. Afbeelding 1. De microcontroller op het breadboard In theorie werkt de microcontroller nu. In de praktijk moeten er nog wat extra verbindingen worden gelegd. Zo moet er een resetschakelaar worden aangesloten en moet er een condensator worden aangesloten om stroompieken op te vangen. Omdat een microcontroller snel schakelende onderdelen bevat, is de stroomafname niet gelijkmatig en ontstaat er een rimpel op de voedingsspanning. Het toevoegen van een kleine condensator compenseert dit probleem en zorgt ervoor dat de microcontroller stabieler zal functioneren. Interactie Zoals gezegd vinden alle acties van een microcontroller plaats via poorten. We zullen hier twee voorbeelden van toelichten. Allereerst noemen we de werking van een gewone schakelaar. Afbeelding 2a laat hiervan een schematisch overzicht zien. Omdat de microcontroller altijd een spanning van 0 of 5V op een poort verwacht, mogen we een poort niet zomaar los laten hangen. Daarom wordt de poort in eerste instantie met 5V verbonden: de microcontroller leest nu een 1. De weerstand van 10 k Ohm zorgt ervoor dat de stroom beperkt blijft, in dit geval 0,5mA. Als de schakelaar nu wordt ingedrukt, wordt de poort rechtstreeks met de massa (0V) verbonden. De microcontroller leest een 0. Een andere toepassing is het aansluiten van een lampje, in dit geval een signaal-led. Door de poort vanuit de software te activeren zal er een spanning van 5V op de poort komen te staan. Hierdoor gaat er een stroom via de poort door de LED lopen en deze licht op, zoals te zien is in afbeelding 2b. De weerstand dient wederom om de stroom te beperken, in dit geval bedraagt deze ongeveer 20mA. Dit is tevens ongeveer de maximale stroomsterkte die de microcontroller per poort kan leveren. Wanneer er meer stroom nodig is, zal deze stroom versterkt moeten worden. We komen hier later op terug. Daarnaast zijn er voor de ontwikkeling van ons prototype nog twee belangrijke verbindingen nodig: de programmer en de debugger. De programmer heeft als functie de software die wij geschreven hebben, in te laden in de microcontroller. De debugger zorgt voor communicatie met de PC tijdens de uitvoering van ons programma: zo is het mogelijk Afbeelding 2a Afbeelding 2b

7 Robotica 7 om met bepaalde commando s informatie naar de computer terug te sturen. Zo kan de loop van het programma worden gevolgd en kunnen fouten makkelijk worden opgespoord. De microcontroller kan echter niet rechtstreeks op de computer worden aangesloten, onder andere omdat de voltages van de signalen niet overeenkomen. Daarom moeten tussen deze verbindingen nog enkele onderdelen worden geplaatst die de signalen geschikt maken voor communicatie met de PC. Op de werking van deze onderdelen zullen we verder niet ingaan, hiervoor verwijzen we naar de datasheets die te vinden zijn in de bronvermelding. 1.2 Voortbeweging De eerste eis aan de robot was dat hij zich moest kunnen verplaatsen. We wilden dit op de meest simpele manier doen, omdat de voortbeweging slechts een middel is om het uiteindelijke doel te bereiken. Om deze reden viel het laten lopen van de robot door middel van poten meteen af: dit is erg ingewikkeld om te bouwen en te programmeren. Een gemakkelijkere manier is het gebruik van wielen, maar met wielen zijn er nogal wat variaties mogelijk. Het gebruik van vier wielen, zoals bij een auto, brengt het probleem met zich mee dat de wielen zelf moeten kunnen bewegen. Meer dan vier wielen was in ieder geval geen optie: de robot wordt dan erg lang en zal moeilijk scherpe bochten kunnen nemen. Met twee wielen gaat dat makkelijker; als bijvoorbeeld het linker wiel draait en het rechter staat stil, zal de robot naar rechts draaien. De ruimte die nodig is om te draaien kan dan eventueel nog verkleind worden door in deze situatie het rechter wiel achteruit te laten draaien. Een probleem dat zich hier wel voordoet is de balans: een auto met vier wielen zal nooit omvallen, een motor met twee wielen heeft een hulpmiddel nodig, de stelt. We hebben een soort gelijk hulpmiddel op de robot gemonteerd tussen de wielen. De stelt sleept over de grond waardoor de robot niet omvalt. Op staat een robot die op dezelfde manier zich voortbeweegt. Hier bleek dat dit systeem werkt, de vraag was nu nog alleen: hoe zorgen we dat de wielen gaan draaien? Hier zijn twee manieren voor: met stappenmotors en servo s. We hebben gekozen voor stappenmotors omdat exact bepaald kan worden hoe lang, dus hoeveel stappen achter elkaar, het wiel moet draaien. Dit gaat als volgt: in de motor zit een magneetje met eromheen vier groepen spoelen. Bij ieder commando dat er een stap gezet moet worden, wordt er op de volgende spoel 12V gezet, en draait de magneet dus een stapje verder. De magneet is verbonden met de as van de motor, waar het wiel weer rechtstreeks op vastgeklemd zit. Elke stap zorgt ervoor dat het wiel precies 1,8 graden veder draait. De stappenmotors hebben meer nodig dan de 20 ma die de microcontroller maximaal kan leveren per poort. De stroom moet dus versterkt worden. Dit gebeurt met behulp van een Driver-IC. Dit IC kan de stroom versterken van een aantal verschillende signalen. We hebben gekozen voor een IC met acht in- en uitgangen. Dit maakt het mogelijk de vier spoelen van beide stappenmotors aan te sturen. Afbeelding 4 laat zien hoe de Driver-IC de stappenmotors met de microcontroller verbindt: op het moment dat een ingang wordt aangestuurd, verbindt het IC de uitgang met massa. Op dit moment kan er een stroom lopen: vanaf de 12V-aansluiting naar de spoel van de stappenmotor en het Driver-IC naar massa. Afbeelding 3

8 Robotica 8 Afbeelding 4. De stappenmotors aangesloten. Bij een servo werkt het anders. Deze kan alleen aan of uit worden gezet in een bepaalde richting. Er kan dan wel bepaald worden hoeveel graden het wiel heeft gedraaid, maar dan op een wat omslachtiger manier. Alleen een extra extern mechanisme kan dit bepalen, bijvoorbeeld door het aantal omwentelingen te tellen. Bij een stappenmotor is het veel simpeler. Op de stappenmotor staat namelijk vermeld hoeveel graden de as draait per stap, 1,8 graden in ons geval. Toch bleken de stappenmotoren niet ideaal te functioneren: er was te weinig kracht om over het kleinste obstakel heen te rijden. Daarom sturen we twee spoelen tegelijk aan, wat voor een groter magnetisch veld zorgt. Dit versterkt de kracht van de motor. Afbeelding 3 laat dit principe globaal zien; in dit voorbeeld draait de motor bij elke stap 90 graden.

9 Robotica Constructie Bij de constructie lag er veel vast: de twee motoren en het breadboard moesten een geheel worden, op zo n manier dat er nog van alles aan veranderd kon worden. Ook hadden we verbindingen nodig met de pc voor het programmeren/debuggen en met de voeding. We wilden het breadboard bovenop, zodat we makkelijk chips en draden konden toevoegen. De makkelijkste manier om hier voor te zorgen, is gebruik maken van meccano: de motors konden aan de meccano worden vastgeschroefd en het bordje hebben we aan de bovenkant vastgemaakt met metaaldraad. De kabels leiden we naar de achterkant zodat de robot hier een zo klein mogelijke hinder van ondervindt. De bundel kabels bevat de aansluitingen voor de programmer, de debugger, een spanningsbron van 12V en een van 5V. Als voeding hebben we een oude computervoeding gebruikt die deze spanningen standaard uitstuurt. Een dikke, stevige koperdraad fungeert in de constructie als stelt. Afbeelding 5. Het opgebouwde prototype

10 Robotica Tast en zicht Er zijn diverse mogelijkheden om een robot de omgeving te laten verkennen: camera s, gps, sonar en infrarood. Ook verkenning op de tast is mogelijk, met bijvoorbeeld voelsprieten. De camera en het gps-systeem vielen meteen af. Deze methodes zijn erg duur en niet heel makkelijk te gebruiken voor ons doel. Nu moesten we nog kiezen tussen sonar en IR. We kwamen hier zelf niet goed uit. Daarom hebben we een gestuurd naar een bedrijf dat beide sensoren verkoopt. We kregen als antwoord dat voor ons doel infrarood het beste zou werken, omdat deze sensor een smalle kijkhoek heeft. De sonar meet Afbeelding 6. De Sharp GPD120 afstandsensor in een hoek van bijna 90 graden, dus de kans was groot dat er een zijmuur gedetecteerd werd in plaats van een muur aan het eind van de gang. Daarom hebben we drie infrarood sensors gebruikt: een op de voorkant van de robot en twee op de zijkanten. Dit maakt het mogelijk dat de robot alle noodzakelijke kanten op kijkt. De sensors werden tijdelijk met een paar druppels lijm op het prototype vastgezet. De infrarood sensor De werking van de sensor berust op re ectie van infrarood licht. Hoe dit precies in elkaar zit, is niet belangrijk voor ons onderzoek. Wat wel belangrijk is, is dat de sensor een spanning uitstuurt die correspondeert met een bepaalde afstand. Dit is een analoog signaal. Het bereik is echter niet lineair, zoals afbeelding 7 te zien is. Deze gra ek is afkomstig uit de datasheet van onze sensor. Om de sensor te kunnen gebruiken, moeten we deze op de juiste manier aansluiten. Hier hebben we een AD-converter voor nodig, omdat de microcontroller zelf geen analoge ingangen heeft. We verbinden de IR-sensor dus met een Afbeelding 7 van de ingangen van een AD-converter en met 5V en massa. Deze chip is ook verbonden met 0V en 5V en via twee draden met de microcontroller: een data- en een clocklijn. Het gebruik van deze twee lijnen vindt plaats via een protocol dat veel gebruikt wordt om tussen verschillende chips gegevens uit te wisselen. De AD-converter stuurt een getal tussen 0 en 255 door, een byte. Die correspondeert met een spanning van 0V tot een referentiespanning. Wij hebben de referentiespanning ingesteld op 3,1V, omdat de maximale spanning die de sensor uit kan sturen 3,1V is. Om deze byte om te rekenen naar een afstand rekenen we eerst de byte terug naar de corresponderende spanning: Vervolgens hebben we de voltage - afstand gra ek gebruikt die bij de sensor hoort. Deze gra ek heeft de vorm van een 1/x diagram, met enkele verschuivingen. Na een beetje gepuzzel zijn we uitgekomen op de volgende formule:

11 Robotica 11 Afbeelding 8. De AD-converter Hierbij is U de gemeten spanning en s de afstand tot het gedetecteerde object. Deze formule kwam goed genoeg overeen met de waarden uit de gra ek. Voelsprieten Een infrarood sensor heeft echter een nadeel: hij kijkt alleen maar recht vooruit. Wanneer er een obstakel net buiten het blikveld van de robot staat, wordt dit obstakel niet opgemerkt en rijdt de robot er tegenaan, zonder dat er gereageerd kan worden. Het gebruik van voelsprieten levert een soortgelijk probleem op: niet de hele voorkant wordt bedekt. Daarom hebben we een soort bumper op de voorkant gemaakt van staaldraad (afkomstig van een gitaarsnaar). Deze bedekt wel de gehele voorkant. Wanneer de bumper wordt ingedrukt, maakt hij contact en merkt de robot dus dat hij ergens tegenaan is gelopen. Nu kan daar wel op gereageerd worden. Er kan nu zelfs bepaald worden of het obstakel zich links of rechts van het midden bevindt, omdat de bumper over twee contactpunten beschikt. Beide contactpunten zijn verbonden met een poort van de microcontroller. Het obstakel bevindt zich het meest aan de kant waarvan het contactpunt het eerst werd ingedrukt. Dit is nuttige informatie om te bepalen hoe dit obstakel het best gepasseerd kan worden. We komen hier nog op terug bij het behandelen van de software. Staaldraad Naar microprocessor Naar microprocessor Afbeelding 9. De bumper van de robot Naar massa De grondsensor Een handige sensor is de grondsensor: de robot kan zo bepalen of hij wel op de grond staat. Als dit niet het geval is, hoeft de robot niet te proberen acties uit te voeren. Ook als de robot tijdens het doorkruisen van het doolhof opgetild wordt, kan hij dit registreren. De robot weet dat, als hij weer op de grond staat, zich opnieuw moet oriënteren.

12 Robotica 12 Maar wanneer weet de robot nu of hij de uitgang, of een bepaalde plek heeft bereikt? Dit was lange tijd een probleem. We hebben nagedacht over een speciale infraroodbron, maar dit is niet echt een makkelijke oplossing. Ook een lichtbron is niet ideaal: er moet dan weer een aparte lichtsensor geïnstalleerd worden, en als de robot in een goed verlichte ruimte rijdt, zou hij een andere plek aan kunnen zien voor het eindpunt. Uiteindelijk kwamen we op een simpele oplossing in de vorm van een ijzeren / aluminium plaat met een draadje koper erop. De beugel, die met massa verbonden is, maakt contact met het metalen lipje op de grondsensor door middel van deze plaat. Het lipje is met een draad verbonden met een poort van de microprocessor. Op het moment dat de robot zich op de plaat bevindt, wordt er een 0 doorgestuurd naar de processor en weet de robot dat het eindpunt bereikt is. Naar massa Naar microcontroller Naar microcontroller Afbeelding 10. De grond- en eindpuntsensor De spanningsensor De laatste sensor op de robot meet de spanning die de batterijen leveren. We hadden nog een analoge poort over op de AD-converter en het is wel handig om de batterijspanning te kunnen zien. Mocht de robot het niet goed doen, dan kan meteen de batterijspanning uitgesloten worden als oorzaak van het niet goed functioneren. Het meten van deze spanning gebeurt met behulp van een spanningsdeler. Deze bestaat uit een instelbare weerstand die ervoor zorgt dat de spanning van 0 tot 12V wordt teruggebracht naar een bereik van 0 tot 3,1V. Wanneer de spanningsdeler bijvoorbeeld 6V binnenkrijgt, stuurt hij 1,55V naar de AD-converter en deze waarde is weer om te rekenen naar de spanning die de batterijen nog leveren. Bij de de nitieve versie zal een lampje oplichten zolang de spanning boven 7,2V blijft. Wanneer de spanning onder deze 7,2V zakt, is gebleken dat de robot zijn taak niet meer goed kan uitvoeren omdat de stappenmotors bij deze spanning niet meer voldoende kracht leveren.

13 Robotica De de nitieve versie 2.1 Motivatie In principe zouden we wanneer het prototype op het hardwarematige vlak af was, ons volledig op de software kunnen richten. Echter tijdens het testen van de verschillende hardwareonderdelen, liepen we tegen enkele problemen aan die met het prototype zelf niet op te lossen waren. De manier waarop het breadboard op de constructie was bevestigd, was niet ideaal: het zat niet echt stevig op het meccanoframe. Op het breadboard zelf waren alleen maar koperdraden te bevestigen. Deze draden gingen erg snel en regelmatig los, met als gevolg dat het programmeren en testen kleine vertragingen opliep. Wanneer in plaats van een breadboard een printplaat wordt gebruikt, zijn de verbindingen veel robuuster. Een andere reden om een de nitieve versie te bouwen was dat het prototype erg groot was voor het aantal chips dat erop zat. Ook het doolhof waarin de robot uiteindelijk zijn taak moet uitvoeren wordt dan groter dan nodig. Het navigeren met een kleine draaicirkel en omvang is tevens gemakkelijker met een klein model. De stroomtoevoer bij het prototype was ook niet ideaal. De kabels leidden weer naar een aparte externe voeding en de kabels zorgden er voor dat de robot zich niet helemaal vrij kon bewegen. De robot ondervond niet alleen veel weerstand doordat hij de kabels achter zich aan moest slepen, maar de lengte van de kabels beperkt ook de actieradius van de robot. Wanneer de robot vaak draaide, draaiden de kabels mee en dit zorgde voor nog meer weerstand. Buiten dit was het vanaf het begin al de bedoeling een autonome robot te bouwen: een robot die kon functioneren onafhankelijk van zijn buitenwereld. Maar niet alleen om praktische redenen wilden we een de nitieve versie maken: persoonlijk vonden we een compacte goed vormgegeven robot ook belangrijk. De robot die we in ons hoofd hadden en schetsten, zag er ook mooier uit dan het prototype dat er erg fragiel uitzag. Om deze redenen wilden we iets tastbaars en blijvends bouwen. Deze beslissing bracht een heel nieuw onderzoeksgebied met zich mee: hoe kunnen we deze zogenoemde de nitieve versie eigenlijk bouwen? Niet alleen het ontwerpen en vervaardigen van een zo simpel mogelijk metalen frame maar ook het ontwikkelen van de printplaten, wat zeer nauwkeurig uitgevoerd moet worden om het te laten werken, breidt het onderzoeksgebied uit. Het zijn allemaal belangrijke onderdelen in de robotica en daarom vonden we dat dit ook terug moest komen in ons onderzoek

14 Robotica De opbouw Het bouwen van dit project begon met het maken schetsen. We hebben nagedacht over de grootte, de vorm van een mogelijk metalen frame, de grootte van de printplaten en indeling van de verschillende onderdelen. Tevens moesten er een aantal toevoegingen aan het prototype worden gedaan. De robot kon bijvoorbeeld niet langer worden voorzien van een externe voeding. Door de robot te voorzien van 8 penlite batterijen kregen we een spanning van 12V tot onze beschikking, die nodig was voor het aansturen van de stappenmotoren. De voor de elektronica benodigde 5V werd hieruit gemaakt met behulp van een spanningsregelaar. Deze bestaat uit een kleine chip, een paar condensators een spoel om inductiepieken van de stappenmotoren tegen te houden. De exacte werking van deze spanningsregelaar is niet van belang voor ons verslag. Een andere toevoeging is een klein piezo-luidsprekertje dat we op een vrije poort van de microcontroller hebben aangesloten. Door deze poort in een bepaalde frequentie aan en uit te schakelen, krijgt de luidspreker een blokgolf aangeboden die een bepaalde toon als gevolg heeft. Hierdoor konden we de robot signalen laten afgeven die ons konden helpen bij het uitwerken van zijn intelligentie. Tot slot hebben we de de nitieve versie voorzien van een aan/uitschakelaar en drie indicatieledjes: voor de aan/uit stand, het niveau van de batterijspanning en het correct werken van de processor. Afbeelding 11. Schetsen voor de de nitieve versie

15 Robotica 15 Afbeelding 12. De auteurs aan het werk Printplaten Printplaten hebben in de de nitieve versie gezorgd voor de elektrische verbindingen. Printplaten bevatten aan de onderkant kopersporen die de verschillende onderdelen op de bovenkant met elkaar verbinden. Het maken van printplaten is een behoorlijke (vooral praktische) klus, maar loont de moeite omdat het een stevige en compacte constructie als resultaat geeft. Ook de onderdelen voor de programmer en debugger hebben we op een aparte printplaat gezet. Afbeelding 13. Het moederbord van de robot met processor, A/D-converter, spanningsregelaar en driver-ic. Diverse connectors zorgen voor de aansluiting met overige onderdelen.

16 Robotica 16 Afbeelding 14. De bumperprint, met aansluitingen voor de stappenmotors en onderop de grondsensor. De programmer hebben we zo gemaakt dat deze met behulp van een gewone netwerkkabel aan de robot kan worden geklikt. Het ontwerpen van de printplaten hebben we op de computer gedaan. Eerst werd het elektrische schema uitgetekend en ingevoerd, vervolgens moesten de verschillende elektrische onderdelen handmatig worden gepositioneerd. Tot slot moesten alle kopersporen handmatig worden gelegd tot het resultaat bevredigend was. Door het resultaat af te drukken op transparant plastic, hebben we de printplaat met behulp van een foto-ontwikkelproces ontwikkeld, geëtst en geboord. Uitgebreide informatie over deze stappen is onder andere te vinden in onze bronvermelding. Na de fabricage van de printen was het nog maar weinig werk de onderdelen er op vast te solderen. Afbeelding 15. Het boven- en onderframe

17 Robotica 17 Afbeelding 16. Het sensorframe Het frame Het ontwerpen van een goed frame vormde misschien nog wel de basis voor het uiteindelijke ontwerp. Het bleek dat de stappenmotors zelf uitstekend als frame konden dienen, wanneer deze stevig bij elkaar werden gehouden en voorzien van bevestigingsgaten. Met meccano lukte het niet goed een compact frame te bouwen. Met het uitzagen, boren en buigen van metaal had Afbeelding 17. De stappenmotors gemonteerd met de wielen (afkomstig van een radiogra sch bestuurbare auto

18 Robotica 18 ondergetekende al wat ervaring, dus lag het voor de hand zelf een frame te fabriceren. Twee metalen plaatjes hebben de functie van frame uiteindelijk vervuld. Het onderste frame loopt aan de achterkant nog een stukje door en vervult daarmee de functie van stelt. Ook de sensors aan de voorkant van de robot werden uiteindelijk met een derde, zelfgebogen metalen frame vastgezet. Met wat nauwkeurig meten en uitrekenen van maten, decoupeerzagen, vijlen, buigen en het exact boren van gaten bleek dit een prima oplossing voor ons probleem. Door de stappenmotors als het ware tegen elkaar vast te klemmen ontstond een compacte basis waar de rest van de robot op vast kon worden gezet. Het resultaat Het resultaat was boven verwachting. Langzaam maar zeker begon de robot meer en meer vorm te krijgen en bleek de praktijk perfect met de schetsen overeen te komen. Met M3-boutjes en moeren en een aantal koperen busjes werden de gemonteerde printplaten en batterijhouders bevestigd. Na wat kleine problemen met de voeding en de programmer werkte de elektronica naar behoren en een simpel testprogrammaatje wees uit dat alle andere functies ook werkten; de robot was klaar voor gebruik. Afbeelding 18. Het resultaat (vooraanzicht)

19 Robotica 19 Afbeelding 19. Het resultaat (zijaanzicht) Afbeelding 20, Het resultaat (bovenaanzicht)

20 Robotica 20 Afbeelding 21. De robot in volle glorie

21 Robotica 21 Afbeelding 22 De robot opengewerkt Afbeelding 23. Een overzicht van alle gebruikte onderdelen.

22 Robotica De software 3.1 Inleiding Aangekomen bij de software kunnen we ons weer bezig houden met het belangrijkste aspect van ons project, de intelligentie van de robot. Zoals in hoofdstuk 1 aan de orde kwam zien we de software als het zenuwstelsel van de robot. In de natuur leren dieren doordat er in de hersenen daadwerkelijk nieuwe zenuwen worden gelegd; aan onze robot kan echter fysiek niets veranderd worden dus moet deze taak door de software worden volbracht. De software zal verschillende taken moeten gaan uitvoeren: het uitlezen van de sensors, het aansturen van de stappenmotors en het doorlopen van een strategie. Een computer kan echter maar één instructie tegelijk uitvoeren en we willen juist dat al deze dingen tegelijkertijd worden uitgevoerd. Op het moment dat de robot een draaibeweging maakt, moet deze nog steeds al zijn sensoren blijven controleren en daar ook adequaat op kunnen reageren. Bovendien moet de robot constant de stappenmotors blijven aansturen. Al snel werd het ons duidelijk dat we hier een opzet voor nodig hebben die ervoor zorgt dat de software overzichtelijk blijft, ook naarmate het gedrag van de robot complexer wordt. Simpelweg beginnen met het programmeren van de strategie zal ervoor zorgen dat bepaalde stukken als het uitlezen van de sensors en de aansturing van de stappenmotors steeds herhaald moet worden. Voor zo n opzet is ten eerste de hoeveelheid geheugen te beperkt en bovendien wordt de code door herhalingen dan zo onoverzichtelijk dat we al snel door de bomen het bos niet meer zien en het erg moeilijk wordt de robot een uitgebreide strategie te laten volgen. De oplossing die wij voor ogen hadden is een soort besturingssysteem zoals dat ook op de PC aanwezig is. Dit besturingssysteem zorgt ervoor dat verschillende processen vrijwel tegelijkertijd kunnen verlopen door ze allemaal om de beurt uit te voeren. Als een bepaald proces moet wachten tot er een knop wordt ingedrukt, zal de computer ondertussen doorgaan met de uitvoering van andere processen. Door deze opzet in onze robot toe te passen is het mogelijk om steeds de sensorgegevens te vernieuwen, de stappenmotors constant aan te sturen en daarnaast een strategisch programma af te werken dat de robot tot bepaalde acties aanzet. 3.2 De infrastructuur Het besturingssysteem voor onze robot wordt eigenlijk gevormd door drie stappen: het inlezen van de sensors, het verwerken hiervan en het uitvoeren van de acties. Deze drie stappen worden in een oneindige lus steeds opnieuw uitgevoerd, tientallen keren per seconde. Hierdoor wordt de indruk gewekt alsof de verschillende acties tegelijkertijd door de processor worden uitgevoerd. In de eerste stap, het uitlezen van de sensors (In de code: CheckSensors), worden de waarden van de sensors uit de AD-converter, de batterijspanning en de stand van verschillende schakelaars/voelsprieten opgeslagen in variabelen. In de tweede stap (MainProcess) vind het echte werk plaats; elke keer dat deze routine wordt aangeroepen, wordt er steeds een volgend stapje van de strategie uitgewerkt. De sensorwaarden worden hier geanalyseerd, er worden beslissingen genomen over de acties die de robot gaat uitvoeren en er worden opdrachten gegeven om de stappenmotors een aantal stappen te laten lopen of draaien. De laatste stap

23 Robotica 23 tot slot, brengt deze acties in de praktijk: elke keer dat deze stap (HandleActions) wordt aangeroepen kijkt de robot wat de stappenmotoren moeten doen; een ronde wachten, een stapje vooruit of een stap achteruit. Het aantal keren dat hetzelfde stapje, bijvoorbeeld vooruit, moet worden uitgevoerd, is van tevoren bepaald in MainProcess. Om de robot een bepaalde strategie te laten volgen, moet deze meer kunnen dan alleen reageren op zijn sensors. Het uitvoeren van een draaibeweging vergt bijvoorbeeld al meer dan één stap: eerst moet de robot een aantal stappen vooruit doen en tot stilstand komen, vervolgens moet deze 90 graden draaien, en tot slot nog een aantal stappen vooruit. Pas dan is die beweging voltooid en kan de robot verder gaan met zijn strategie. De robot moet dus langere tijd onthouden waar hij mee bezig is. Een systeem met tellers, statussen en acties maakt dit in ons geval mogelijk. De robot zal een aantal verschillende statussen kennen waarin deze zich kan bevinden: een draaibeweging naar rechts is bijvoorbeeld een status, maar ook bij het rechtdoor lopen of het opgepakt worden bevindt de robot zich in een andere status. De robot onthoudt in welke status deze zich bevindt, en elke keer dat het Mainprocess opnieuw wordt aangeroepen voert deze een nieuw stapje van de status uit. Elke status zelf bestaat ook weer uit een aantal substatussen, die elk voor een aparte beweging kunnen zorgen. Zo zal in de eerste substatus van de status Draai naar rechts de robot 20 keer de actie Vooruit activeren, waardoor de robot 20 stappen vooruit zal doen. De robot belandt nu in de tweede substatus, die de robot 60 stappen laat draaien. De derde substatus laat de robot weer twintig stappen naar voren lopen, en de vierde substatus brengt de robot weer terug in de status Loop vooruit. Met behulp van een aantal tellers die van te voren zijn ingesteld, bepaalt de robot in hoeverre een status is afgewerkt: een eerste teller telt bijvoorbeeld af vanaf 20 en geeft de motor twintig keer het commando om een stapje vooruit te doen. Wanneer deze teller bij nul is, gaat een tweede teller aftellen, bijvoorbeeld vanaf 60 en laat de robot een aantal stappen draaien. Wanneer alle tellers zijn afgewerkt, wordt de robot weer in een andere status teruggezet. Met behulp van het volgende stukje code proberen we dit principe duidelijk te maken. 1 Begin: 2 3 Als Status = LoopVooruit dan: 4 { 5 Actie = Vooruit 6 Als obstakel wordt gedetecteerd dan: 7 { 8 Status = Draaiom 9 Substatus = 1 10 Teller1 = Teller2 = Teller3 = 0 13 } 14 } Als Status = Draaiom dan: 17 { 18 Als Substatus = 1 dan: 19 { 20 Actie = Achteruit 21 StatusCountingFlag = True 22 } 23 Als Substatus = 2 dan: 24 { 25 Actie = Draailinks 26 StatusCountingFlag = True 27 } 28 Als Substatus = 3 dan: 29 { 30 Status = LoopVooruit

24 Robotica } 32 } Ga terug naar Begin Deze code zorgt ervoor dat de robot vooruit blijft lopen. Op het moment dat er voor de robot een obstakel wordt gedetecteerd, zal deze 20 stapjes achteruit doen, 80 stappen links om zijn as draaien en weer vooruit gaan lopen. Van tevoren wordt de status op LoopVooruit gezet. Elke keer dat Mainprocess wordt aangeroepen, ziet de robot dat deze nog steeds de status LoopVooruit heeft (r. 3) en geeft het commando Actie = Vooruit, waarmee de stappenmotors het commando krijgen een stapje vooruit te gaan. Op het moment dat er een obstakel wordt gedetecteerd (r. 6), krijgt de robot de stratus Draaiom, wordt de substatus op 1 gezet en wordt de duur van de verschillende substatussen in een aantal tellers vastgelegd. De robot bevindt zich nu in de substatus 1 van status Draaiom (r. 18), en geeft dus aan de stappenmotor het commando om een stapje achteruit te doen. De uitdrukking StatusCountingFlag = true geeft aan dat de robot de teller van deze substatus moet gaan aftellen, en naar de volgende substatus moet gaan wanneer deze bij nul is aangekomen. Hierdoor zal de robot twintig keer in de eerste substatus van Draaiom blijven, en dus twintig keer de actie Achteruit uitvoeren. De substatus wordt nu 2 (r. 23), en de robot zal 80 keer de actie Draailinks uitvoeren. Tot slot wordt de substatus 3. Er hoeft nu niet meer te worden afgeteld, de enige functie van deze substatus is om de status zelf weer terug te brengen in LoopVooruit ; de status is nu afgewerkt. We hebben er voor gekozen het programma en dus ook de namen van de statussen en acties in het Engels te houden. Dit omdat de programmeertaal zelf in het Engels is en omdat de statussen dan met korte termen aangeduid kunnen worden. 3.3 De intelligentie van de robot Aanvankelijk was het de bedoeling een intelligente robot te maken: een die zelf zijn weg koos, geen vooraf bedachte strategie volgde, de afgelegde weg opsloeg en hieruit de optimale weg terug berekende. Bij het kiezen van die eigen weg, kwamen we nogal wat problemen tegen. Want hoe laten we de robot beslissen of hij dan wel links, dan wel rechts of toch maar rechtdoor gaat? Ook al lukte dit wel, was de kans nog redelijk groot dat de robot de uitgang nooit of na een hele lange tijd pas zou vinden. Want wanneer de robot op een cruciaal moment net de andere kant kiest, begint hij eigenlijk weer opnieuw, om de volgende keer op dit punt misschien een andere, ook verkeerde kant te kiezen, die niet naar het eindpunt leidt. Met een vooraf bedachte strategie wisten we redelijk zeker dat de robot zijn einddoel zou vinden. Of het ons zou gaan lukken met een robot die zelf beslissingen neemt, was een stuk minder zeker. Ook zou dit veel meer tijd vergen om te maken. Het opslaan van de route staat hier los van: we vonden het wel interessant om nadat de robot het doolhof had doorlopen, te bekijken welke route hij had gevolgd. Helemaal mooi zou natuurlijk zijn als hieruit de route berekend kon worden, door de robot zelf of door een externe computer, die de robot zou moeten volgen als hij zo snel mogelijk naar het begin terug wilde. Het berekenen van de optimale route terug leek ons erg lastig: met de gegevens die de robot op had geslagen de route tekenen op een kaart, en dan de optimale route terug tekenen, is voor een mens niet moeilijk. Maar een robot of andere computer kan geen kaart lezen. Dit hebben we dus al snel laten vallen. Zou de robot dan toch alleen de route zelf kunnen opslaan? We hadden niet echt een idee over hoe we dit het beste softwarematig konden doen. Waarschijnlijk zou het erg veel ruimte op de chip kosten, en ook veel tijd. Aangezien we eerst de andere functies van de robot ontwikkeld hadden en toen al ruim over de 200 uur in totaal zaten, hebben we dit niet meer verder bekeken. In dit deel lichten we dus alleen de verschillende

25 Robotica 25 statussen van de robot nader toe: in welke statussen kan de robot zich bevinden en waarom worden juist deze statussen gebruikt? Het detecteren van een muur met een IR-sensor hebben we als volgt gede nieerd in de software: wanneer de gemeten afstand kleiner is dan een bepaalde afstand, staat er een muur. Wanneer de afstand groter is, staat er niets. Het blokschema Voordat we de de nitieve software zijn gaan programmeren, hebben we eerst onderstaand blokschema gemaakt. Dit hebben we gedaan omdat een blokschema erg overzichtelijk is en duidelijk inzicht geeft in de verschillende functies die de robot moet uitvoeren en in welke volgorde dit moet gebeuren. Het schema was ook handig om te bepalen waar we mee moesten beginnen: eerst de basisbeweging, dan sensorverwerking en uiteindelijk alle beschreven situaties programmeren en dit zoveel mogelijk perfectioneren. Het is sowieso makkelijker om een steeds groter en complexer wordend programma eerst uit te werken op papier. Dit voorkomt dat op een gegeven moment de code te onoverzichtelijk wordt en dat er dingen vergeten worden. Het bijsturen hadden we nog niet in het blokschema opgenomen: we waren er nog niet helemaal uit hoe we dit gingen aanpakken. Het bijsturen moest wel plaatsvinden voordat er een andere actie plaatsvond.

26 Robotica 26 Moet de robot wel vertrekken? De robot kan alleen zijn doel volbrengen wanneer deze op de grond staat en als hij zijn doel niet al bereikt heeft. Daarom zijn er twee statussen, genaamd StatusStandBy en StatusFinished. Aan het begin van iedere keer dat MainProcess wordt doorlopen, wordt eerst gekeken of de robot op de grond staat en of het eindpunt al bereikt is. Is dit het geval, dan wordt de status veranderd in de status die bij de gedetecteerde gebeurtenis hoort. In de status Standby wordt alleen gekeken of de grondsensor wordt ingedrukt. Alle acties worden stopgezet: het heeft geen zin de motoren aan te sturen als de robot niet op de grond staat. Wanneer de grondsensor weer wordt ingedrukt, wordt de status veranderd in StatusOrientation, omdat de robot eerst een muur moet vinden om zijn strategie te kunnen vervolgen, terwijl hij bijna tegelijkertijd kijkt of hij wordt opgetild of het eindpunt heeft bereikt. Wanneer het eindpunt is bereikt en de status dus op StatusFinished wordt gezet, maakt de robot een geluid. Verder doet de robot niets meer, behalve als deze wordt opgetild. De robot komt dan in de status StandBy terecht, zodat de robot weer opnieuw kan beginnen als hij weer op de grond staat. Het is niet zinvol om tijdens de status StandBy de beugelsensors af te lezen. De robot staat immers niet op de grond en kan dus niks doen om ervoor te zorgen dat de beugel niet meer ingedrukt wordt. Eerst wilden we een algemene Collision Detection maken: in een routine werd dan bepaald of de robot ergens tegenaan zat, en hier werd dan in deze routine op gereageerd alvorens de robot verder zou gaan met de andere statussen. Het was echter niet praktisch dit centraal te doen: het is niet handig om de robot altijd hetzelfde te laten reageren op sensorafstanden en op de beugel. Als bijvoorbeeld de robot naar rechts aan het draaien is, kan het voorkomen dat de middelste IR-sensor aangeeft dat de robot bijna tegen een muur aan zit, terwijl de robot de bocht toch af kan maken. Dus alleen al tijdens het draaien, iets wat toch veel voorkomt, moet de robot op een andere manier omgaan met de bumper en sensoren. Oriëntatie Om een muur te volgen zal de robot eerst een muur moeten vinden. Het zou natuurlijk heel makkelijk uitkomen als rechts van de robot meteen al een muur stond: de robot kan dan meteen rechtdoor deze muur volgen. Een minder ideale situatie is wanneer de robot tegen een muur aankijkt of wanneer er zich een muur links van de robot bevindt. Er zal dan 90 of 180 graden gedraaid moeten worden. Om er voor te zorgen dat de robot altijd de voordeligste situatie kiest zetten we het commando om de muur te gaan volgen oftewel de status in FollowWall te veranderen als laatste van de drie. Als er dan bijvoorbeeld links en rechts van de robot een muur is, wordt de status eerst op Turnleft gezet om de robot 180 graden te laten draaien. Rechts van de robot staat ook een muur en de status wordt op FollowWall gezet. Het commando om 180 graden te draaien wordt overschreven en dus genegeerd. In het geval dat links van en voor de robot of voor en rechts van de robot een muur staat, is er wat voor te zeggen om wel de eerst gedetecteerde muur (dus de linker en de muur voor de robot) te volgen. Wanneer de robot de muur voor zich gaat volgen, zal hij bijna meteen linksaf moeten gaan om de muur verder te volgen. Hetzelfde geldt wanneer rechts en voor de robot een muur staat. Maar het is niet nodig dit tijdens de oriëntatie te regelen: de robot zal immers ook terwijl de muur wordt gevolgd, voor hem een muur detecteren. Daarom wordt in StatusFollowWall geregeld dat linksaf wordt geslagen als de robot niet rechtuit verder kan. In deze status wordt ook gekeken of de beugel wordt ingedrukt. Als dit het geval is, is het zeer waarschijnlijk dat een muur hiervoor zorgt. In dit geval wordt het nadeel van de IR-sensor dus opgevangen door de beugel. De muur en het bijsturen Zo, de muur is gevonden: rijden maar! En wanneer er rechts geen muur meer is, gewoon 90 graden naar rechts draaien, een stukje rechtuit en daar is de muur weer. Gewoon weer rechtuit rijden dus. Maar dan kan de robot ineens niet meer verder Wat kan er aan de hand zijn?

27 Robotica 27 In het voorbeeld is te veel uitgegaan van een laboratoriumdoolhof : de robot rijdt in deze perfecte situatie perfect parallel met de perfect rechte muur en draait altijd perfect 90 graden naar rechts. In de praktijk komt dit vrijwel niet voor. De muur zal nooit helemaal recht staan en als dit al wel het geval is, staat de robot er naar alle waarschijnlijkheid nooit recht naast. Het draaien van 90 graden is wel redelijk nauwkeurig te voltooien maar ook als hier een kleine afwijking in zit, zal de robot na een paar bochten diagonaal door de gangen heen rijden. De oplossing hiervoor lijkt heel simpel, maar bleek een van de lastigere onderdelen te zijn om tot een acceptabel resultaat te komen: bijsturen. Het bijsturen heeft als doel dat de robot binnen een bepaalde afstand van de muur blijft. Loopt hij er te ver van af of dreigt hij er tegenaan te lopen dan zal hij dit corrigeren. Een aantal simpele hoekberekeningen maken dit mogelijk. Meetwaarde 1 < Meetwaarde 2 Meetwaarde 2 < Meetwaarde 1 Als c < 2 cm: loop door Als 2 < c < 4: draai ß rechts Als c > 4 cm: draai 1,5 ß rechts Als c < 2 cm: draai 1,5 ß links Als 2 < c < 4: draai ß links Als c > 4 cm: loop door a c b Beta 1,5 Beta b a c Beta 1,5 Beta Meetwaarde1 Meetwaarde 2 Meetwaarde1 Meetwaarde 2 De dikke lijn stelt de route voor die de robot langs de muur a egt. a = aantal stappen die de robot gezet heeft * 0,11 b = meetwaarde2 - meetwaarde1 ß = tan^-1 (b/a) c = cosß * meetwaarde2 (omrekenen stappen naar centimeters) (verschil tussen de twee meetwaardes) (de hoek die de robot maakt met de muur) (De afstand die de robot heeft tot de muur) De bovenstaande berekeningen resulteerden in een behoorlijk zenuwachtige robot. Daarom hebben we nog enkele aanpassingen verricht in de software. De robot stuurt minder rigoureus bij en tussen de twee meetpunten zit een grotere afstand waardoor hij minder vaak bijstuurt. Tast Wanneer de beugel wordt ingedrukt, zijn in principe maar twee situaties mogelijk: er staat een obstakel links van het midden van de robot, of rechts van het midden. Als de rechterkant van de beugel wordt ingedrukt, is het meest waarschijnlijk dat het bijsturen niet helemaal heeft gewerkt. De robot moet echter wel deze gang blijven volgen. Dit hebben we opgelost met behulp van een aparte status: StatusTurnLeft. Eerst rijdt de robot 30 stappen achteruit, zodat de beugel niet meer ingedrukt wordt. Vervolgens draait de robot 10 graden naar links, dus van de muur af. Daarna rijdt hij nog 20 stappen vooruit. Als laatste wordt de status weer op FollowWall gezet, zodat de robot weer de muur volgt. Wanneer de linker sensor van de beugel als eerste wordt ingedrukt, is er meer aan de hand: de gang is niet breed genoeg! Om hier uit te komen, zal de robot om moeten draaien. Weer wordt de status veranderd in TurnLeft, maar nu wordt er 90 graden gedraaid. Op zich zou 180 graden draaien logischer zijn, de robot moet immers omdraaien. Maar de robot staat in principe scheef in het doolhof. Wanneer hij dan 180 graden zou draaien, staat weer de linker kant van de beugel recht voor de andere muur. Als de robot nu vooruit gaat rijden, raakt hij de muur en draait weer 180 graden om en is de robot terug bij af. Nadat de robot dus 90 graden is gedraaid, rijdt hij

28 Robotica 28 recht vooruit, maar nu raakt de rechterkant van de beugel de muur. De robot kan echter toch rechtdoor, omdat nu maar 10 graden wordt gedraaid voor dat de robot weer verder rijdt. In de praktijk bleek dit de beste resultaten te geven. Linksaf en rechtsaf De strategie van de robot is om de rechter muur te volgen. De muur maakt echter hoeken. In het geval dat de gang linksaf gaat, is er een simpele oplossing: de robot draait in de status TurnLeft 90 graden naar links en gaat gewoon weer verder. In het geval dat de robot rechtsaf moet gaan om de muur te blijven volgen, wordt het ingewikkelder. In het begin wilden we dat de robot alleen de doorgangen nam wanneer zeker was dat de doorgang breed genoeg was. Daarom maakten we de statussen MeasureGap om de breedte van de doorgang te meten en GoThroughGap om de doorgang daadwerkelijk te nemen wanneer in MeasureGap de doorgang groot genoeg is bevonden. Op het moment dat de rechter sensor een gat in de muur waarnam, werd de status MeasureGap geactiveerd. In deze status meet de robot of er een muur is. Is dit niet het geval, dan wordt er een stap gezet en een stap opgeteld bij de grootte van de doorgang. Is de doorgang na een bepaald aantal stappen breder bevonden dan de robot nodig heeft, dan wordt de status veranderd in GoThroughGap. Als de minimale breedte van de gang nog niet is bereikt, maar de robot meet weer een muur, is de doorgang dus te smal voor de robot. In dit geval gaat de robot deze muur weer volgen in FollowWall. Stel dat de robot een doorgang heeft gemeten die groot genoeg is. Dan moet de robot achteruit rijden tot hij in het midden van de doorgang staat, 90 graden draaien naar rechts en vervolgens vooruit rijden totdat de muur aan de rechterkant weer in zicht is. Op zich werkte deze manier goed, alleen was de tijd tussen het opmerken van de doorgang en het volgen van de muur in de doorgang relatief lang. Ook zag het er erg onnatuurlijk uit. En wat is er mis met een robot die een doorgang probeert te nemen waar hij niet door kan en zich daaruit weer herstelt? Het idee was dus dat de robot iedere doorgang probeerde te nemen en als de doorgang te smal is, raakt de linker kant van de bumper de muur en kan de robot terugdraaien. Het grootste probleem hierbij was dat de robot niet meteen 90 graden naar rechts kan draaien als er een doorgang wordt gemeten omdat het draaipunt van de robot, de wielen, achter de sensors zitten. Zou de robot wel meteen 90 graden draaien, dan loopt hij zich vast tegen de rechter muur. Het draaipunt is dus pas een paar stappen later op het punt waarop de sensor aangaf dat de muur naar rechts afboog. We laten daarom in StatusTurnRight de robot de volgende stappen doen: om zo te kunnen draaien dat de robot zich niet vastloopt tegen de rechtermuur, laten we de robot eerst 70 stappen vooruit lopen. Dit is de afstand die overeenkomt met de afstand tussen de sensor en de wielen, plus nog een extra stuk zodat de robot de bocht ruim genoeg neemt. Vervolgens draait de robot 90 graden en loopt hij een ingesteld stuk van 20 stappen vooruit om de muur rechts van hem weer te kunnen waarnemen. Tenslotte wordt de status weer teruggezet op FollowWall. De robot staat na de bocht meestal niet parallel met de muur, maar dit wordt opgelost door de bijstuurfunctie. Het functioneren van de beugel is bij het draaien cruciaal. Mocht de doorgang niet groot genoeg zijn en raakt de linkerkant van de beugel de muur, dan draait de robot 90 graden naar links (StatusTurnLeft) en vervolgt hij zijn weg met FollowWall. In het geval dat de robot de bocht toch te kort neemt en dus de rechterkant van de beugel wordt ingedrukt, gebeurt hetzelfde als wanneer de robot tijdens FollowWall de rechter muur raakt. Ook nu wordt de status weer teruggezet op FollowWall en detecteert de robot de doorgang opnieuw omdat in FollowWall als eerste wordt gekeken of er een doorgang is. De robot kan nu dus opnieuw proberen de bocht te nemen.