torsdag den 23. februar 2012

Lego LAB uge 4

Tilstede:
Mikkel Nielsen
Søren Bramer Schmidt
Peter Jessen

Mål

Målet med dagens øvelse er at lave en robotbil, som kan følge en linje og stoppe på en blå farve. Vi vil forsøge dette med både 2 og 1 lys-sensorer.


Plan
Planen er skrevet således, at vi følger opgaveformuleringen for uge 4 [1]
1.  Vi vil undersøge lys-sensorernes værdier over forskellige farver, og sammenligne disse resultater med hinanden..
2. Installere og køre test-programmet LineFollowerCal.
3. Skrive et program, der via lyssensoren kan kende forskel på sort, hvid og en målfarve.
4. Programmere og teste et program, der kan følge en linje og stoppe på et farvet målområde vha. 2 lyssensorer.
5. Gentage punkt 4 med kun 1 lys-sensor, ved at bruge en PID-regulator.


Resultater

1. Sort-hvid måling

Eksperimentet med at teste værdien på forskellige farver, er nøjagtig det samme vi gjorde i uge 1. Vi holdt skiftevis den ene og den anden lyssensor over forskellige farver. Af dette lærte vi, at der kan være forskel på lyssensorer, og at det derfor giver mening at kalibrere hver enkelte lyssensor inden brug. De to sensorer vi testede i dag havde en forskel imellem forskellige farver på mellem 1 og 5 procent-point.  


2. Line Follower med kalibrering

Vi kørte LineFollowerCal som givet fra [1].

Programmet har et problem med at nå at rette op, hvis svinget er for skarpt. Sensoren kommer ud over den forkerte side af linjen inden den når at rette op. Det betyder, at den kan tage sving i den ene retning uden problemer, men misser sving i den anden retning. Hvis linjen var meget bredere ville dette ikke være et problem. Problemet er illustreret på videoen her:



3. Farve-genkending med kalibrering

Vi har skrevet colorsensor programmet således, at hvid og sort er værdier,  der er henholdsvis over og under et threshold. Målfarven er en zone på +/- 2 procentpoint omkring en bestemt procent værdi for målfarven, som vi kalibrerer før robotbilen bliver sat til at køre.

Da værdien for blå er i området mellem hvid og sort vil lyssensoren ofte registrere “blå” i overgangen mellem linje og ikke-linje. Derfor har vi monteret en ekstra lyssensor, der sidder så langt ude til siden, at den aldrig kommer ind over linjen som robotten følger.


4. Line Follower som stopper over blå

Med den ekstra sensor har vi kombineret vores colorsensor med linefollower koden. Robotten følger linjen med oscillerende adfærde som i linefolloweren fra uge 1. Den anden sensor måler alene efter den målfarve som indikerer at vi har nået målet.


Video: 



Kode for FollowStopSensor [2]:
while (true) {
    if (sort) {
        Drej til venstre!
    }

    else {
        Drej til højre!   
     }

    if (mål) {
        Stop!
    }
}


5. PID Linefollower


Vi startede med at implementere P-controlleren som beskrevet i pseudo-koden i [3]. Her bliver der målt en error og kraften til de to motorer bliver sat herefter. Vi lavede et forsøg på en bane med denne kode alene. 
Herefter tilførte vi ‘I’ delen således, at vi fik en PI-controller.  
Vi prøvede at bruge programmet direkte, men det gav nogle problemer. Integral variablen steg for hurtigt, så vi måtte tilføje nogle check. Vi rettede det ved at dele error med 1000 inden vi lagde den til integral. Desuden indførte vi et treshold på +/- 50 for integral, og nulstillede integral variablen hver gang error blev 0. Dette fik robotten til at følge en linje nogenlunde.

Disse ændringer kan ses i pseudo-kode her:

if (error skifter fortegn) {
    integral = 0;
}


integral = integral + error/1000;
           
if (integral > 50) {
    integral = 50;
}
           
if (integral < -50) {
    integral = -50;
}

Tilsidst programmerede vi ‘D’ delen ind, så vi havde en PID controller. D delen sørger for at forskellen mellem error værdien og foregående error værdi bliver lagt til hastigheden. Dette sørger for at mindske oscilleringerne.
Vi sammenlignede P, PI, og PID delen med tidsmålinger på en bane med en lige sort streg, som vist på billedet her:


Tidsmålingerne er vist her:

målingerne er vist i sekunder
          50    100 basis hastighed
PID    16,4    6
PI       9,4    3,9
P        9,2    n/a

P kunne ikke gennemføre banen med en basis hastighed på 100.
PID var meget langsom på 50, dette skyldes formentlig, at error fik sænket hastigheden på begge motorer. PI fik de bedste tider, men dette skyldes at banen var helt lige. PI reagerede for langsomt, så på banen med mange sving, kørte den let af banen. PID var den eneste version, som kunne klare banen med sving, med en basis hastighed på 100. Banen er vist her:


Videoen her er af PID med basis hastighed 100 på bane med sving
Video af PID på 100



Status
Ialt har vi brugt 6 timer på denne øvelsesgang. Vi nåede alt hvad vi havde planlagt. Vi brugte det meste af tiden på at programmere og teste PID-controlleren. Vi havde især problemer med PI delen, da vi måtte lave flere ændringer fra designet givet i [3]. Vi blev positivt overrasket over hvor godt PID virkede, efter vi havde haft problemer med PI. 

Referencer

torsdag den 16. februar 2012

Lego LAB Uge 3

Tilstede:

Mikkel Nielsen
Søren Bramer Schmidt
Peter Jessen

Mål

Målet med dagens øvelse er at undersøge hvorledes lydsensoren på NXT'en virker, og herefter bruge den i diverse programmer som bruger lyd.


Plan
1. Installere Lejos og bluetooth funktionalitet på flere computere, for ikke at være afhængig af en enkelt computer.
2. Afprøve de forskellige medfølgende .bat filer til at overføre filer og monitor NXT'ens status, så vi ikke hele tiden skal kigge på displayet.
3. Tilføje lydsensoren til robotten og teste lydmålinger fra forskellige lyde ved forskellige afstande som beskrevet i øvelsesbeskrivelsen [1].
4. Optage en lydsekvens af forskellige lyde med datalogger.java og lave en graf over lyden.
5. Afprøve SoundCtrCar.java og tilføre en escape-mekanisme.
6. programmere en klappe styret bil som reagere alene på klap og ikke andre lyde.

Resultater

1. og 2.  Installation af bluetooth
Installation og afprøvning af bluetooth funktionaliteten fungerede fint. Vi kunne bruge nxtbrowse til se filerne på NXT'en.
Vi fik dog ikke monitoren til at vise sensor data, som vi havde forventet at den ville.
Den viste dog tacho tal fra motoren. Vi kunne hente og overføre filer, hvilket var det vi skulle bruge nu og her.

3. Test af lyde

Vi testede forskellige lyde fra forskellige afstande. Herefter kunne vi aflæse lyden på displayet af NXT'en.
Lyden blev vist i en procent-sats mellem den menneskelige hørlige del af decibel-skalaen.

Målte værdier:

Klap

afstand            lyd-niveau
50 cm              93
100 cm            48
200 cm            26


Høj stemme

afstand            lyd-niveau
50 cm              63
100 cm            52
200 cm            43

Vi kan konkludere at lyden bliver mindre når afstanden bliver større. Herudover ser klappet ud til at falde hurtigere med afstanden end stemmen.
Testen blev udført i et mindre lokale, og der kan derfor have forekommet noget ekko der har spillet ind på resultatværdierne, men konklusionen er den samme.

4. Optaget lyd
Vi brugte dataloggeren til at optage en lyd hvor vi først var stille, så klappede vi af robotten og tilsidst råbte af den. Denne lydfil downloadede vi fra
NXT'en, og processerede dataene via MATLAB. Resultatet ses i billedet her:


Ved ca. den 800 måling kommer der et klap som ses ved den hurtige stigning til over 90.
De senere lyde er stemmer som ikke stiger lige så brat, og ikke kommer lige så højt op.


5. Lyd styret bil
Vi hentede og kørte Soundctrcar.java. Programmet kørte fint, og vi testede som vist her i videoen:

Programmet kunne ikke stoppes, så vi tilføjede en buttomlistener på escape knappen. Hvis knappen trykkes ned afslutter vi programmet med system.exit(), som vist her:

Button.ESCAPE.addButtonListener(new ButtonListener() {

   @Override
   public void buttonReleased(Button arg0) {
   }

   @Override
   public void buttonPressed(Button arg0) {
    System.exit(0);
   }
  });




6. Klappe styret bil
Vi programmerede den klappestyrede bil med noget besvær. Vi ville gerne have robotten ti kun at reagere på klap og ikke på stemmer.
Vi fulgte så vidt mulig beskrivelsen for et klap, som beskrevet af Sivan Toledo.
Der var mange aspekter i denne algoritme for et klap, og vi måtte derfor debugge en hel del, før vi fik det til at virke.
Vi fik den tilsidst til at virke, nogenlunde. Den reagerede dog stadig på høje pludselige stemmer.
Vi er dog stadig noget skeptiske over for det klappestyrede system. Det er sjældet at stemmer på over 90 ikke er pludselige lyde.
Det som den klappestyrede ikke reagere på er langsomt stigende lyde som den lyd kontrollerede bil ikke reagere på.  

Den vigtigste del af algoritmen fra vores ClapCar.java kode [2], kan ses her:

if(soundLevel < 50)
{
 trin 1
}
   
if (step1 && soundLevel > 85)
{
 trin 2
}
   
if (step2 && soundLevel < 50 && ms <= 275)
{  
 trin 3
}

Status
Vi fik vi lavet alt det vi havde planlagt. Det tog længere tid end vi havde først regnet med. Vi brugte ialt godt 5 timer,
hvor det meste a tiden gik med at forsøge at optimere den klappestyrede bil.
V ville gerne have haft monitor af NXT'ens display til at virke over bluetooth, således at vi ikke hele tiden måtte kigge på displayet.
Dette vil vi kigge videre på næste gang.

Referencer
[1] Uge 3 opgaver
[2] Kode fra uge 3

torsdag den 9. februar 2012

Lego LAB Uge 2

Tilstede:

Mikkel Nielsen (20082285)
Peter Jessen (20082519)
Søren Bramer Schmidt (20082602)

Mål
Målet med dagens øvelse er at lege med en ultrasonic sensor.


Plan
  • Tilføje en ultrasonic sensor til NXT robotten
  • Compile, uploade og teste SonicSensorTest.java klassen.
  • Compile, uploade og kører Tracker.java og Car.java klasserne.
  • Ændre variablerne i de ovenstående programmer, for at teste deres effekt.
  • Afprøve Wallfollower (eventuelt omskrive til Java kode)
  • Installere Lejos og drivere på 2 computere mere.
  • Afprøve installation via Bluetooth.



Resultater 
Test af ultrasonic sensor


Robotten blev tilført en ultrasonic sensor som beskrevet på side 28-29 af den medfølgende 9797 bygningsmanual. Vi overførte herefter SonicSensorTest programmet og kunne konstatere at det målte afstanden fra sensoren som forventet. Vi udførte herefter en test af dens præcision ved forskellige afstande til forskellige materialer. Testen blev udført ved, at vi placerede robotten, med sensoren installeret, med forskellige afstande til diverse objekter. Afstanden blev så fysisk målt med en linial, og sammenlignet med sensorens måling.
Testen viste os, at det ikke var ligegyldigt hvilket materiale som sensoren måler afstanden til.
Som man kan se herunder, er den faktiske afstand sammenlignet med den målte fra sensoren.

Afstand til hvid tapet's væg
Reel afstand (cm)                   Målt afstand (cm)
67                                                    71
40                                                    45
24                                                    24
148                                                 151
200                                                 203
225                                                 227-228

Der syntes at være en lille forskel i reel og målt afstand, hvilket kan forklares med at den ikke er præcist kalibreret.



Vi testede også den maksimale afstand som sensoren kan måle til forskellige materialer. Da de høj-frekvente impulser ikke bliver reflekteret lige godt af alt materiale har dette en effekt.

Objekt                                 Maksimal afstand
Radiator(metal)                               180 cm
Pude(stof)                                        100 cm
Billede(glas)                                    253 cm

Den glatte overflade reflekterer bedre end den ru overflade fra stoffet. Testen her viste os også, at vinklen på objektet har en betydning. Hvis ikke det målte objekt er tilpas lodret, så tror sensoren at det er en del af gulvet.






Vi fjernede delayet på 300 ms, som fandtes i den ældre version af NXT'en. Dette viste sig ikke længere at være nødvendigt.

Da lydenshastighed er 340,29 m/s og afstanden fra sensoren til den maksimalt målte afstand er 253 cm * 2 = 506 cm, får vi et delay af information på:

5,06 m / 0,34029 m/ms = 14,87 ms

Dette har teoretisk set en effekt, men i vores tilfælde kører robotten ikke hurtigt nok til at det har en reel effekt.

Test af tracker klassen
Vi fik installeret tracker klassen og kunne konstatere, at det virkede ved at robotten kunne køre frem mod en mur og stod herefter og oscillerede frem og tilbage, omkring threshold'et på 35 cm. Ved at øge delayet imellem målingerne kunne vi øge robottens oscillering.
Vi indførte herefter et ekstra tjek i koden, som ser om fejlmarginen til muren er mindre end 2 cm, og i så fald skal robotten stoppe helt. Dette fjernede oscilleringen.

Bluetooth installation
Da det er besværligt at tilslutte ledningen hele tiden, besluttede vi at få bluetooth til at virke, inden vi gik videre med næste opgave. Dette viste sig at være ganske nemt, da der findes et android program til styring af en NXT robot, som vi kunne bruge til at teste forbindelsen. Da dette virkede fint og vi kunne fjernstyre robotten, fik vi tilsluttet en pc og igennem eclipse virkede dette som plug-'n'-play. 

Wallfollower
Vi startede med at ombygge robotten således at robottens ultrasonic sensor sad med en vinkel på 45 grader til venstre. Denne model tog vi ud fra eksemplet fra http://www.philohome.com/wallfollower/wallfollower.htm. Ved at kigge lidt fremad, istedet for direkte til siden, kan vi hurtigere se om robotten er på vej væk fra en mur eller hen imod den.
Herefter skrev vi koden ud fra Philippe Hurbains eksempel. Dette involverede flere tests langs en mur, for at se om robotten drejede som ventet. De første par forsøg viste at robotten drejede for meget og for tit. Ved at ændre på treshold'et, således at det blev et interval på 5 cm, istedet for en bestemt længde, fik vi robotten til at følge muren mere lige.
 
Kode vi har skrevet til Wallfollower følger denne struktur:

int threshold = 25;
       
         if (distance < threshold - 5)
         { 
            // drej til højre
         }
        
         else if (distance > threshold + 5)
         {
            // drej til venstre
         }
        
         else
         {
             // direkte fremad
         }
 

Den fulde sourcekode kan findes på:
http://users-cs.au.dk/u082285/LegoLAB/uge2/



Status
Vi har i alt brugt 4,5 time på denne øvelsesgang.Vi nåede det meste af planen. Det vi ikke nåede var at få installeret lejos på de andre computere. Vi ville også gerne få bluetooth til at virke således, at vi kunne skrive information fra robotten direkte til computeren. Dette ville kræve, at vi satte os mere ind i koden, og vi valgte derfor at udskyde dette til næste øvelsesgang. Målet med at få leget med ultrasonic sensoren blev i hvert fald opnået, og vi fik en større forståelse for at få kodet robotten.

Referencer
http://www.legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson2.dir/Lesson.html

torsdag den 2. februar 2012

Lego LAB Uge 1

Som det første satte vi os for sideløbende at bygge robotten og få installeret drivere og software til NXT'en. Bygningen af robotten gik efter planen, mens installationen af softwaren var noget mere problematisk. Vi installerede på en Windows 7 64-bit maskine med 32-bit JDK 1.7.0, 32-bit Eclipse og 64-bit USB driver. Under installationen fulgte vi manualen, men det viste sig at være problematisk, da vi havde problemer med "JAVA_HOME" miljøvariablen. Manualen sagde nemlig, at man skulle sætte den, men det virkede faktisk kun, hvis man ikke havde sat den. Det sjove ved dette problem var, at leJOS softwaret faktisk sagde, at vi ikke havde JDK installeret, men det vi ignorerede vi, hvilket endte med at virke alligevel. Efter vi fixede dette problem kunne vi flashe vores NXT med leJOS. Et andet problem var, at vi ikke kunne uploade til NXT'en via de medfølgende .bat filer. Dette fixede vi ved at installere et Eclipse plugin.

Så efter vi brugte en del tid på at få fixet disse problemer, kunne vi begynde at lægge programmer over på robotten. Dette gav os følgende test resultater.

Resultater
Lyssensoren tændt
Grøn: 43
Rød: 57
Lysegrå: 52

Sort: 35
Hvid: 55

Så grunden til at blackWhiteThreshold er sat til 45 er fordi, at det er lige mellem mellem værdierne for sort og hvid.

Lyssensoren slukket
Grøn: 37
Rød: 41
Lysegrå: 34

Sort: 27
Hvid: 42

Så her, er værdierne generelt lavere end før, men til gengæld er de så også tættere på hinanden. Så derfor, ville f.eks. thresholdet fra før ikke virker mere. Denne form for måling kan ikke bruges til farver, men mere til lysstyrke, hvilket resultaterne bekræfter.

Sample interval
I takt med, at vi øger delayed mellem aflæsninger fra lyssensoren, bliver svingene større, og den har sværere ved at holde sig på den sorte linje. Ved 10 ms kørte den perfekt, ved 100 ms var det mere usikkert, mens den ved 500+ ms havde nul chance for at holde sig på den sorte streg.

String-variabler eller ej
Ved begge forsøg svinger den frie memory fra 55.000 til 40.000.

Med variable:
  • 7.6 sekunder inden garbage-collectoren rydder op

Uden variable:
  • 3.0 sekunder

Altså kan vi konkludere, at det at lave nye strenge hele tiden fylder noget mere end at bruge pre-allokeret variabler.