Lego labøvelse 4

Balancerende robot

Denne uge står laboratorie-udfordringen på en selv-balancerende robot. Ved brug af en lyssensor skal vi bedømme om vores robot står oprejst eller er ved at falde til en side - og derpå ved hjælp af motorerne hjælpe robotten tilbage i balance.

Idag er Toke, Phillip og Esben tilstede, Lasse er syg.

Forsøg 1:

Bygge-fasen var simpel og kort, det tog omkring 2 min at samle den nye robot.

I mellemtiden var balance programmet blevet downloadet og gjort klar til overførsel. Den første kørsel fejlede øjeblikkeligt; Robotten startede og væltede inden for 1 sekund.

Forsøg 2:

Vi forsøgte at finde den value der passede med ligevægt, og forsøgte at hard-code denne ind i programmet. Dette gav umiddelbart en fordel; Det var muligt for os at finpudse denne værdi og dermed ikke være afhængig af at hole robotten helt ens under start længere.

Forsøg 3:

Efter noget finpudsning af lys-sensor threshold. begyndte vi at rode med de forskellige gains. Det var dog stadig ikke muligt for os at finde en indstilling som kunne få robotten til at balancere mere end 1-3 sekunder.

På dette tidspunkt er den første time gået.

Datalog:

Da vi ikke helt var klar over hvorfor vores program fejlede, besluttede vi at indføre en datalogger, så vi kunne få en graf over udviklingen; Og måske klarlægge årsagen til vores fejlende program.

Fra den graf vi fik ud, kunne vi konkludere at vores robot overskød mere og mere og derfor uundgåeligt væltede.

data eksempel

Forsøg 4:

Efter tilføjelse af datalogger kørte vi flere forsøg hvor vi igen prøvede forskellige gain-indstillinger. Da vi havde behov for at skifte omåde og underlag måtte vi sætte initial indstilling af threshold tilbage i robottens program.

video 1

Sidste udkald:

Efter nogle timers frustrationer over vores robot og da tiden var ved at være udløbet, gik det op for os at vi havde arbejdet på et dårligt underlag. underlaget havde været et bord som havde en skinnene overflade. Da vi skiftede til at køre på et stykke farvet papir gik det bedre - men robotten ville stadig ikke balancere helt.

video 2

Vores sidste udkast til programmet (som stadig ikke virker):

Lego labøvelse 3

SoundSensorTest
I starten af øvelsen monterede vi lydsensoren på fronten af vores robot så vi kunne teste vores første testprogram SoundSensorTest.java. Dette program er meget lige UltraSonicTest.java hvor vi ændrede Sensor porten til SoundSensor og læste dB i stedet for distance.

Ved at stille robotten på et punkt hvorfra vi ændrede vores afstand til robotten kunne vi aflæse at dB værdien ændrede sig alt efter hvor langt eller tæt på vi var fra robotten.

SoundSensorTest.java

Datalogger
Tilføjelsen af dataloggeren til vores robot gik smertefrit. Det samme kan også siges om testen af selve loggeren. Til selve graf repræsentationen af vores indsamlede data krævede det dog at vi ændrede en smule i datalogger klassen så den skrev ud i et format vi kunne bruge sammen med GnuPlot.

DataLogger.java

Vi har lavet et plot hvor vi laver lidt forskellige lyde:

Sound controlled car
Ved testen af SoundCtrCar.java fandt vi ud af at robotten står og venter på at registrere en høj lyd, i koden er det speciferet til at være 90 dB (LeJOS defination af dB). Efter at have registreret en høj lyd cykler robotten igennem en prædefineret sekvens af bevægelser: frem, højre, venstre, stop.

For at løse problemet med at escape er i det yderste loop laver vi en button listener hvis funktion er at lytte efter tryk på bestemte knapper og på den måde bryde vores loop.

SoundCtrCar.java

Clap controlled car
Ved implementationen af vores klap kontrollerede bil fandt vi ud af at det er noget vanskeligere at definere et klap i forhold til bare at registrere en høj lyd. Nogen af de problemer vi løb ind i var at timingen skulle være rigtig for at definationen var korrekt. Desuden så var der også den faktor at vi sad i et stort lokale med masser af andre grupper der larmede, hvilket vores robot selvfølgelig også registrede.

ClapCar.java

Lego Lab 2

Vi fik bygget vores robot om så den nu også inkluderer en sonar sensor. Vi installerede test programmet og begyndte at teste vores sonar. Ud fra en plan væg hvor sensoren står vinkelret ind på, kan vi måle op til ca. 230 cm fra væggen, herefter vises "no object". Hvis overfladen er skrå (en kasse lænet op ad en væg for eksempel) eller hvis sensoren måler lidt skråt ind på overfladen, reduceres den maksimale afstand vi kunne måle en del. Materialet af overfladen betyder også noget, og ved "støjabsorberende" materiale alla en trøje, har den svært ved at måle korrekt.

I programmet er måleintervallet 300 ms, hvilket vi prøvede at ændre. Vi har sat den til 20 ms uden problemer, da vi beregnede at ved den maksimale afstand (255 cm) vil lyden være ca 14 ms om at nå ud til overfladen og reflektere tilbage. Ved at sætte måleintervallet til 5 ms måler den nogle lidt sære afstande længere ude.

Tracker programmet vi fik udleveret benytter en P-D controller, med et gain på 0.5. Dens standard instillinger får den til at opnå en tilstand hvor den oscillerer frem og tilbage omkring 35 cm. Vi prøvede ikke at tweake på de forskellige parametre men et lavere gain burde få den til at stoppe med at oscillere (men kan risikere at stoppe uden at ramme dens desired state, hvilket kunne fikses med et integral led).

I sidste del af opgaven implementerede vi en wallfollower baseret på vores tidligere linefollower. Den benytter en P-D controller. Efter vi fik tilpasset gainet korrekt, kører den næsten ude oscilationer hen langs en væg. Kommer der en forhindring kører vores robot rundt om, dog med en begrænsning. Da sonar sensoren er monteret i en 45* vinkel betyder dette at hvis vi kommer ind i et hjørne hvor væggene har en vinkel mindre end dette, vil vi ikke kunne se den indkommende væg og robotten kører ind i hjørnet.

Sammenlignet med three_state algoritmen opnår robotten aldrig en tilstand hvor den skal korrigere voldsomt for at komme tilbage imod vores desired state da vi altid laver små korrigeringer når vi er tæt på vores desired state. Sammenlignet med gentle turn og hard turn algoritmerne, fandt vi at vores P-D controller baserede robot oscilerede væsenligt mindre, hvilket skyldes at vi benytter en gain funktion.

Lab øvelser 1

Vi startede med at få bygget standart robotten, mens vi lagde drivere ind på computeren.
Vi havde ingen problemer med at få lagt lejos ind, og robotten kørte fint efter den sorte streg.
Der var nogle problemer med vores ene motoer men vi fik bare en ny.
Ved at sætte sample tiden op oplevede vi at robotten havde svært ved at følge efter stregen da den tit nåede at dreje for langt til den ene siden inden den opdagede stregen, og kørte derfor i ring.
Ved 500ms kunne den følge stregen nogenlunde. Men ved 1000ms kørte den bare "tilfældigt" rundt.

Vi målte lys censorens værdier for forskellige matrialer, med og uden flodlight tændt.


Målinger - Med lys
Ahorn 52
Gråtbord 50
Blåt gulv 35
Whiteboard 54
Sort streg 33
Grå væg 47
Rød Stol 41
Blankt Metal 43

Målinger - Uden lys
Ahorn 43
Gråtbord 35
Blåt gulv 27
Whiteboard 43
Sort streg 27
Grå væg 35
Rød stol 37
Blankt metal 27

Generelt er værdierne væsentligt lavere uden lyset.

Ved at indtaste strenge direkte i metoderne, benyttede vi hurtigt al heapspacen og der måtte ofte køres garbage collection. Derfra kan vi aflede at generelt skal strenge gemmes i variable så de ikke fylder for meget.