Opdracht beschrijving

De opdracht was om met behulp van lego een robot te ontwerpen, bouwen en programmeren. De robot moet rondrijden in een vierkante arena, obstakels kunnen verwijderen en frisdrankblikjes kunnen vinden, en naar een bepaalde hoek van de arena brengen. Het doel was om in vijf minuten zoveel mogelijk blikjes te verzamelen. Het materiaal dat we tot onze beschikking hadden bestond uit:

· een Lego MindStorms Robotic Invention Set

· een extra motor

· een extra licht sensor

· twee rotatie sensoren

De programmeertaal die we moesten gebruiken was NQC, een taal ontwikkeld door Dave Baum. Als hulpmiddel hierbij kregen we de RCX Command Center, ontwikkeld door Mark Overmars. De precieze opdracht is te vinden op internet (www.cs.uu.nl/people/markov/lego/index.html).

Aanpak van de robot-bouw

Wat kunnen sensoren

Er is eerst begonnen verschillende sensoren te combineren, omdat een van de belangrijkste beperkingen van de robot is dat er maar 3 sensor-inputs zijn. Tevens staat in de introductie handleiding dat sommige combinaties van sensoren niet (zinvol) kunnen worden gecombineerd.

Wij hebben geprobeerd om rotatie en touch (r&t), licht en touch (l&t), licht en licht (l&l) en licht, touch en touch (l&t&t) te combineren in een sensor-input. Rotatie en licht was bij gesprekken en experimenteel viewen van de sensoren al gebleken dat dit (waarschijnlijk) te lastig zou zijn. Het lastigste bleek bij ons inderdaad te zijn om rotatie en touch (r&t) te combineren. Het idee was dat je in raw-mode kon zien of touch geraakt was (<=100 was de waarde dan) en als dit niet zo was dan de mode te wisselen naar hoeken of rotation en dan te meten de rotatie. Dit bleek niet te werken, omdat het wisselen op de een of andere manier niet werkte, zodat hij in raw-mode bleef meten, waar we niks aan hadden. De andere combinaties waren niet zo erg moeilijk, in raw-mode kon je telkens de aparte sensoren afleiden. L&t&t was te combineren omdat je de richting van bewegen weet en omdat de raw-waarde bij het indrukken van allebei de touch-sensoren de raw-waarde onder 60 kreeg en zodoende verschil zag met een touch-sensor.

Uiteindelijk hebben we besloten om de twee rotaties sensoren apart te zetten en l&t&t als derde sensor te gebruiken. Met deze sensor-opstelling hebben we een groot deel van het gehele project zitten werken, totdat we ontdekten dat heel moeilijk was om de exacte positie in de ruimte nauwkeurig te bepalen en dat uit te programmeren. Mogelijk kregen we de opdracht dan niet af binnen de gestelde tijd en toen de opdracht ook veranderde in geen challenge tussen robots en dus geen tweede “thuis-vak”, had je de rotatie-sensoren niet meer nodig.

De definitieve opstelling is dan ook veranderd in twee licht sensoren apert, en twee touch sensoren gecombineerd (l,l,t&t), zodat we beter de lijnen van het thuis-vak kunnen herkennen (met de tweede licht sensor naar onderen gericht).

Hoofdzaken: aandrijving, oppakken en botsen

Voor de aandrijving kon uit meerdere manieren gekozen worden. Er kon gebruikt gemaakt worden van een rupsband of wielen. Daarbij kon uit verschillende wielen gekozen worden. Omdat de oriëntatie bij wielen beter bijgehouden kon worden is voor wielen gekozen.

Er werd over het oppakken van het blikje nagedacht. Hiervoor waren verschillende manieren te bedenken. Het blikje zou geklemd kunnen worden en dan door de robot meegesleept worden. Of de robot zou het blikje voor zich uit kunnen duwen. Er werd gekozen om het blikje op te pakken. Een manier om dit te doen is het blikje in te klemmen en dan op te tillen.

Om botsingen te detecteren moet er gebruik gemaakt worden van een bumper.

Bouwen van de robot

Het bouwen van de robot is opgedeeld in verschillende delen. Deze delen zijn globaal:

· Bouwen van het onderstel.

· Bouwen van de grijparm.

· Bouwen van de bumper.

· Plaatsen van de sensoren.

Als een onderdeel af was werd dat op de robot gebouwd. Hierdoor werden de verschillende onderdelen geïntegreerd en zijn de afzonderlijke onderdelen niet eenvoudig van de robot af te halen. Dit komt doordat de robot robuust moet zijn. De onderdelen moeten goed op de robot gemonteerd worden omdat het één geheel moet zijn. Is dat niet het geval dan kan de robot niet robuust gebouwd worden.

De eerste stap van het bouwen van de robot was het onderstel van de robot. De motoren voor aandrijving van de wielen moesten tussen de draagbalken geplaatst worden zodat de overbrenging naar de wielen toe makkelijk te realiseren was. Hierbij werd ook gekozen voor maar twee wielen die de robot aandrijven. Er werden verder geen wielen voor besturing gebruikt. Hiervoor werd een kleine ronde schijf gebruikt die aan de achterkant van de robot bevestigd was. Dit was gedaan zodat de robot geen last had van onnauwkeurigheden die wel door bijv: zwenkwiel(en) veroorzaakt worden (echter wel meer wrijving, maar dat was geen probleem). Na de testsessie is hier weer vanaf gestapt omdat de opdracht veranderd werd. Er zijn geen twee robots tegelijk meer in de baan zodat oriëntatie niet belangrijk meer was. De robot kan het blikje nu immers niet meer in de basis van de tegenpartij plaatsen want er is geen tegenpartij meer. Er werd dus nu voor een zwenkwiel gekozen omdat het zwenkwiel minder wrijving veroorzaakt. Dit leverde echter een nieuw probleem op. Het bleek noodzakelijk voor het oppakken van een blikje om een klein stukje recht achteruit te kunnen rijden, en dit was met een zwenkwiel niet mogelijk, dus uiteindelijk hebben we toch gebruik gemaakt van een kleine ronde schijf die aan de achterkant van de robot onderaan bevestigd was.

Voor het oppakken van het blikje is een grijparm gebruikt. Deze arm wordt door één motor aangedreven en klemt het blikje en tilt het op. Hiervoor is een hele mooie constructie gemaakt. De grijparm werd op de robot gemaakt. Vervolgens werd een bumper op de robot gemaakt. Voor de bumper was maar één touch-sensor beschikbaar omdat er besloten was dat er ook één voor de arm gebruikt zou worden zodat de arm door verschillen van de motor (vooruit en terug zijn namelijk niet gelijk) elke keer dat de arm omhoog of omlaag gaat geijkt wordt. Er is een bumper gemaakt die van één touch-sensor gebruikt maakt. Zie ook plaatje hieronder.

Het plaatsen van de licht-sensor aan de voorkant zorgde voor kleine problemen omdat de grijparm en de bumper veel ruimte innamen. De grijparm is hoger geplaatst zodat de licht-sensor er tussen gebouwd kon worden.

Het bouwen van de robot zodat deze ook robuust was, was niet echt moeilijk omdat je de robot door kruislinkse constructies erg stevig kunt bouwen. Hier is bij het bouwen van de robot gebruikt van gemaakt. Dit zorgde er wel voor dat het veranderen van de robot meer tijd koste en dat de onderdelen in elkaar geïntegreerd zijn.

Aanpak van de robot-software

Voordat er aan het schrijven van het programma is begonnen, is er op papier een overzicht gemaakt van de taken en functies die nodig zijn om de robot binnen de arena blikjes op te laten pakken en terug naar de basis te brengen. Nadat de taken en functies bepaald waren, zijn deze verder gespecificeerd. Deze bleken nog wel eens te moeten worden her-overwogen, omdat ook de opdracht en de mogelijkheden van de sensoren anders waren dan van te voren was ingeschat.

Vervolgens is het programma geschreven, door telkens afzonderlijke taken te schrijven, dan te testen en daarna de (vervolg) nieuwe taken toe tevoegen en te testen. De datalog mogelijkheid die door de NQC-taal en de robot geboden werd was daarbij soms van groot nut en we kunnen iedereen aanbevelen er van gebruik te maken. Het was dan duidelijker welke taak klaar was en welke taak hij was begonnen of juist niet!

Voor de source-code wordt naar bijlage A verwezen. Het programma hoofdidee is dat er verschillende taken tegelijkertijd lopen, te verdelen in twee hoofdtaak-typen, namelijk beweging- en sensor-taken. Er is een afhankelijkheid tussen de twee type-taken, omdat de beweging moet (kunnen) veranderen, als er iets herkent is door de sensoren. Omgekeerd is er geen afhankelijkheid, want sensoren worden alleen door externe omgeving veranderd (licht inval, aanraking) worden.

Het programma valt in de volgende (hoofd)taken-structuur uiteen:

Figuur 1:

hoofdtakenstructuur

In de initialisatie-fase worden er twee zaken gedaan:

1. In de procedure init worden standaard settings ingevoerd als snelheid motor en sensor-type en modes. Bij de snelheid van de motor – wegens het niet (meer) gebruiken van de rotatie-sensoren – hebben we vaste waarden ingevoerd. Deze lieten de robot zoveel mogelijk recht lopen, door het snelheidsverschil van de motoren te compenseren door de snelste motor langzamer te laten lopen (bijvoorbeeld op 4 i.p.v. op 7, wat het snelst is).

2. In de procedure init_default_light wordt de omgeving gemeten bij het rijden van de robot, om zodoende een gemiddelde licht-waarde voor front & bottom allebei te hebben. Front is voor een blikje dat herkent moet worden en bottom is voor de zwarte thuisvak-lijn te herkennen. Dit bleek handiger dan een vaste gemiddelde in te voeren, omdat dit afhankelijk is van de ruimte en het dag-tijdstip. Wel bleek het redelijk donker te moeten zijn om sowieso iets nuttigs te kunnen meten.

Voor de bepaling van de gemiddelde licht-waarde draait de robot ongeveer een rondje (van 360°). Dit is door tijd bepaald en afhankelijk van het type wielen dat onder de robot zit, naast evt. vieze vloeren en andere storende invloeden. Deze kunnen ervoor zorgen dat het niet helemaal een rondje wordt.

Wat nog speciaal maakt is dat de variabelen maar maximaal +/- 32k kunnen bevatten als waarde (15 bit + 1 significante bit). Hierdoor hebben we gekozen om tijdens de bewegen max. 30 waarden te meten (equidistant over de tijd), om zodoende ruim onder de 32k te blijven en het niet nog ingewikkelder te moeten maken.

32-Point Star: 30

Na de initialisatie fase start de main taak de 2 sensortaken lightfront en touchfront tesamen met de bewegingstaak drive.

De bewegingstaak drive voert de beweging wiggel-waggelä (zie figuur 2) uit als zoekmethode om zo een blikje van voren te herkennen (in de sensortaak lightfront). Dit is omdat positie bepaling veel te moeilijk bleek te zijn en dus het idee van scancirkels (zie figuur 2) niet langer nodig en uitvoerbaar was.

Definitie 1: De scancirkel is het maximale (scan)bereik van de licht-sensor zodat hij nog net een blikje herkent van die afstand.

Definitie 2: Een wiggel-waggel beweging is met een soort slingerbeweging naar links gaan, naar rechts gaan en weer terug om een cirkeldeel als (scan)bereik van de licht-sensor te hebben.

Scancirkel Thuis-vak

Figuur 2: scancirkel en wiggel-waggel

De sensortaken checklightfront en checktouchfront testen continu en tegelijkertijd met elkaar en de drive taak of er iets gedetecteerd wordt. checklightfront doet dit door de omgeving te meten en deze te vergelijken met de defaultlight waarde. checktouchbottum doet dan nog niks, deze wordt alleen gebruikt als er een blikje opgepakt is.

Definitie 3: Als de (raw)-waarde lager is dan default_light_front waarde minus recog_f (recognise_front) dan heb je een blikje herkent.

Definitie 4: Als de (raw)-waarde lager is dan default_light_bottum waarde minus recog_b (recognise_bottum) dan heb je de zwarte thuisvak lijn herkent.

De sensortaken starten en stoppen andere bewegingen naar aanleiding van herkende zaken.

Bijvoorbeeld als een blikje herkent is, stopt de huidige beweging en rijd hij tegen het blikje aan om precies op de juiste plekje te kunnen beginnen met de oppak beweging. Hiervoor rijd hij eerst een fixed size naar achteren, om gelegenheid te hebben de grijparm te starten, zodat deze omlaag staat en open [de grijparm staat normaal omhoog, omdat anders de lichtsensor niks kan meten]. Hierna gaat hij weer naar voren en deze maakt de (omgekeerde) beweging om het blikje te pakken en de grijparm omhoog te doen. De stand is te zien in het volgende plaatje:

Dit is gedaan, zodat je niet tegen obstakels botst, omdat deze obstakels niet zo hoog als de grijparm en het blikje zijn.

Voorwaarde 1: De robot werkt alleen als de obstakels lager dan het blikje zijn.

Als het blikje in de grijparm zit, dan zit hij hier ook erg stevig, omdat de kleine rupswielen een soort natuurlijke klemaktie hebben (d.m.v. wrijving?). De stand is dan te zien op het plaatje op de volgende bladzijde van de zijkant en van de bovenkant op het winnersplaatje op de voorkant van dit verslag.

Begin terugrijden na botsen.

Eind terugrijden na botsen, dan nieuwe lijn kiezen met hoek van 25°.

Wiggel-waggel Thuis-vak

Hierna wordt de terugrij procedure gestart, die eerst ongeveer 180° draait en daarna naar voren rijd en bij botsing met een muur een klein stukje naar achter gaat en een kleine hoek maak, telkens naar rechts. De hoek is zo afgesteld dat altijd het thuis-vak wordt gevonden (zie figuur 3).

Als laatste notitie over de software willen we vermelden dat er een safety-timer inzit, die na 5 seconden een draai maakt van ongeveer 90 °, want in dat geval zat de robot mogelijk vast, hetgeen ook bij de wedstrijd gebeurd is en ook het los komen werkte, zodat zo’n feature aan te raden is bij iedere robot om ervoor te zorgen dat hij in ieder geval iets blijft doen!

Het adagium “geluid maken” bleek er handig te zijn, om de verschillende stadia van het programma te onderscheiden, zonder dat je meteen de datalog moest gebruiken.