torsdag den 16. december 2010

Afsluttende projekt, 3. dag

Date: 16. December 2010
Duration of activity: 4 hours
Group members participating: Heine Stokholm og Mads Møller Jensen


Dagens mål:

  • Færdiggøre PID-systemet
  • Finde ud af robottens endelige navigation i banen
  • Kigge på Bluetooth kommunikation
Plan:
  • Arbejde videre med gårsdagens PID-system
  • Undersøge muligheder for at navigere i banen
  • Få robotten til at sende de læste kompasværdier til computeren vha. Bluetooth, og eventuelt fortæller detaljer om hvordan den har kørt
PID-systemet
I dag har vi arbejdet videre med PID-systemet og fået et rigtig fornuftigt resultat. Robotten overstyrer stadig, når den skal dreje til en bestemt kompasværdi, men nu har vi fået den til at oscillere tilbage mod målet, så vi ender med en errorværdi på 0, og robotten altså peger præcis den vej, som kompasset fortæller den, den skal. Desværre har vi stadig lidt problemer med kalibreringen af kompasset, så robotten ikke drejer 90 grader, selvom den tror, den gør. Alligevel drejer den "omkring" 90 grader, og vi kan godt bruge dette resultat, selvom det ikke er perfekt.
Planen er, at robotten skal køre til midten af et banemodul, dreje 90 grader og læse om der er en sort streg, og gentage dette fire gange, og på den måde genkende banemodulet. Her er det ikke så vigtig om robotten drejer 90 eller 95 grader, da vi i begge tilfælde vil være muligt at se om der er en sort streg.
Koden for at dreje 90 grader med PID-systemet kan ses her


De største forskelle på PID-systemet til at følge en linie  og det til at følge kompasset er måden vi finder vores offset i starten og måden vi beregner error værdien løbende. Vores metode til at dreje med PID-systemet tager to værdier, start og t, som er i hvilken retning peger og hvor meget vi gerne vil dreje den. Ud fra det beregner vi så offsettet. Error værdien bliver beregnet ud fra offsettet minus den retning vi peger, men med nogle yderligere tjek da vi skal sikre os at vi altid drejer kortest vej. Derfor har vi sagt at hvis vi skal dreje over 180 grader skal vi istedet dreje error - 360 grader. 
Udover det har vi lavet en variabel der meget passende er døbt awesome som bliver talt op hver gang vores error er lig nul, og nulstillet hvis error er forskellige fra nul. Med den kan vi registrere om robotten har fundet hvile i den rigtige retning, eller om den bare står og oscillerer over offsettet. Hvis de sidste 100 errors har været 0 går vi ud af løkken og går ud fra at robotten peger i den rigtige retning. 

De relevante steder i koden står med fed i kodestykket nedenfor.


public static void pidTurn(int start, int t){
 long kp = 300;
 long ki = 10;
 long kd = 500;
 long offset = (start + t)%360;
 long tp = 10;
 long integral = 0;
 long lastError = 0;
 long error = 0, derivative, turn, power;
 int awesome = 0;
 while(awesome < 100){
     LCD.drawInt((int)us.getDegrees(),3,13,0);
     LCD.drawString("offset", 0, 1);
     LCD.drawInt((int)offset,3,13,1);
     LCD.drawString("error", 0, 2);
     LCD.drawInt((int)error,3,13,2);
     error = (start + t)%360 - (int)us.getDegrees();
     if(error > 180) error = error - 360;
     integral = integral + error;
     derivative = error - lastError;
     turn = kp * error + ki * integral + kd * derivative;
     turn = turn / 100;
     power = tp + turn;
     leftMotor.controlMotor((int)power,1);
     rightMotor.controlMotor((int)power,2);
     
     lastError = error;
     if(lastError == 0){
  awesome++;
     }else{
  awesome = 0;
     }
 }
    }
    
Navigation på banen
Problemet i at vores robot ikke drejer præcist er, at vi så har svært ved at få det til at køre "rigtigt" rundt på banen. Vi har derfor valgt at bruge en sekventiel strategi. Først og fremmest vil vi modificere banen, så vi får en midterlinje på hele banen. Derved kunne vi bruge en LineFollower til at køre imellem de forskellige moduler og skifte til kompasfunktionen, når vi skal genkende de forskellige moduler. Et problem, vi dog stadig slås lidt med, er, at vi mangler en god idé, så robotten kan se når den er på midten af et modul, og altså kan bruge genkendelsesprocessen. Indtil videre har vi to forslag:
  • Bruge en tacocounter for at måle, hvor langt vi er kørt. Da vi ved hvor store de forskellige moduler er burde dette være en mulig løsning, og også den vi ville have brugt, hvis kompasset fungerede optimalt. Men da vi nok bliver nødt til at bruge en LineFollower, bliver det svære at bedømme afstanden, da robotten skal navigere efter stregen, samtidig med at den skal køre en bestemt længde frem.
  • En anden løsning kunne være at lave en markering på midten af hvert modul. På den måde ville robotten kunne genkende midten, når den vha. LineFolloweren nåede derhen. Problemet er her, at vores lyssensor er placeret et stykke foran robotten, så vi alligevel er tvunget til at bruge tacocounteren til at køre det sidste stykke frem, og derved igen er i fare for at miste præcision. En løsning her er dog at bruge en ekstra lyssensor, som vi placerer ud for hjulene. På den måde ved vi, at vi skal stoppe, når denne lyssensor læser markeringen midt på modulet. 
Endnu et PID-system
Vi begyndte at lave et PID-system, så robotten kunne følge en linje, så vi kan være sikre på, at robotten kører "rigtigt" på banen. Igen fulgte vi metoden fra PID_Controller_For_Lego_Mindstorms, da vi føler, at denne metode har en stor succesrate. Dette var overstået rimelig hurtigt og robotten kunne følge en linje uden at oscillere. Eftersom robotten ikke skal følge en linje gennem et sving, gjorde det opgave rimelig overskuelig, og vi fik hurtigt rigtig gode resultater med meget få justeringer. 

Status
De nye tiltag, vi har lavet i dag, har betydet, at vi har lavet to modifikationer i forhold til tidligere.
For det første har vi ombygget robotten:
Dvs. vi nu har en robot med tre sensorer: Et kompas (som er placeret ca. 20 cm væk fra selve NXT'en), en lyssensor (som er placeret foran robotten) og en ekstra lyssensor(som er placeret bag hjulene). Det er nu meningen at robotten skal mappe, som følger:
Følge en streg vha lyssensor1 indtil lyssensor2 ser en markering. Herefter drejer robotten 4x90 grader, og for hver 90 grader scanner den med lyssensor1 efter sort eller hvid. Næste skridt vælger robotten en af de mulige veje, som (den lige har opdaget), eksisterer og følger så vha. lyssensor1 en streg videre til næste gang lyssensor2 ser en markering, osv.


Dette har betydet, at vi også har ændret vores bane:
Selve banen er i for sig den samme, men nu har vi tilføjet alle de markeringer lyssensor2 skal aflæse (de mange små sorte prikker).  Vi mangler dog stadig at lave en streg som robotten skal følge, men dette gemmer vi til næste gang.


Til gengæld har vi nu en klar idé om, hvordan vi skal få robotten til at mappe banen. Vi har et godt PID-system til kompasset og et godt PID-system til at følge linjen med. Det sidste skal muligvis revideres, når vi får testet det på vores endelige bane, altså på den streg vi mangler at tegne op.


Næste gang
Næste gang vil vi:

  • Lave stregen på banen, som robotten skal følge
  • Få robottens sekvensstrategi til at fungere (altså få sat de forskellige dele sammen til et helt program)
  • Kigge på Bluetooth-kommunikation (som vi ikke nåede i dag)
  • Kigge på repræsentationen af robottens input på computeren  

onsdag den 15. december 2010

Afsluttende projekt, 2. dag

Date: 15. December 2010
Duration of activity: 3 hours
Group members participating: Heine Stokholm, Michael Vilhelmsen og Mads Møller Jensen

Dagens mål:
  • Konstruere en bane, der senere skal mappes af robotten
  • Lave et PID-system så robotten kan dreje præcist.
  • Afgøre næste mål
Plan
Banen
Vi har besluttet at konstruere vores egne bane moduler. Vi har valgt at beholde de fire forskellige slags moduler, som findes i LEGO. Dvs. En lige vej, et sving, et t-kryds og et kryds. Vi gik væk fra LEGO-elementerne, da disse både var for små og i grøn og grå som lyssensoren læser næsten ens. Vi har i stedet valgt at lave modulerne i 30x30 cm format, og bruge gaffatape til at markere vejene med.
Måden vi har lavet banen på er ved først at tegne banen på et stykke papir i et mindre format. Derefter tegnede vi samme bane op i rigtig størrelse på vores plade, og til sidst markerede vi de tegnede streger op med gaffatape. På den måde har vi fået en god størrelse bane, som passer til vores robot, hvor vi samtidig kan skelne stregerne, da disse er sorte på hvidt underlag.
Den første bane vi har lavet har vi holdt helt simpel, men vi overvejer at udvide den, når vi kommer længere frem i projektet. F.eks. har vores nuværende bane intet kryds. 



PID-systemet
Vi har forsøgt at lave et PID-system, jvf. det vi lavede til en LineFollower-opgave. Vi havde nogle problemer med at få det til at virke, generelt fordi det var svært at omskrive et program som følger en linje til at finde en kompasværdi. Grunden, til at vi lavede PID-systemet i første omgang, var at robotten overstyrede hen til den kompasværdi, vi ønskede, den skulle stå på. Den fik for meget motorkraft og nåede ikke at stoppe før vi var forbi den værdi vi ønskede. Med PID-systemet havde vi på et tidspunkt også det problem, motorene fik for lidt kraft til at kunne dreje robotten det sidste stykke hen til værdien. Samtidig havde vi igen lidt problemer med magnetisk interferens fra computere i lokalet.
PID-systemet virker stadig ikke helt optimalt, og vi er nødt til at bruge noget mere tid på at forbedre det yderligere, da hele projektet afhænger meget af, at robotten kan dreje meget præcist. Vi har allerede brugt meget tid på systemet, men vi er nødt at investere mere i det, da det er så vigtigt. 
Vi har overvejet to alternativer, hvis ikke vi får PID-systemet til at virke:
  1. At dreje uden PID-system ved at sætte farten helt ned. Dette vil kunne forhåbentlig gøre at robotten ikke overstyrer, men samtidig vil det gøre den meget ineffektiv
  2. At bruge tacocounteren til at tælle omdrejninger på hjulet i stedet for at bruge kompasset. Dette er dog ikke så præcist, som at benytte kompasset, så det er kun som sidste udvej, at vi overvejer dette. 
Næste gang:
Næste gang vil vi:
  • Arbejde videre med PID-systemet
  • Kigge mere på Bluetooth kommunikationen 
  • Begynde at kigge på repræsentationen af det som robotten mapper
Det er opgaver, som minder meget om dem vi har kigget på i dag, men vi arbejder allerede videre i morgen, så vi forhåbentlig snart kan få robotten til at køre på banen.


torsdag den 2. december 2010

Afsluttende projekt, 1. dag

Date: 2. December 2010
Duration of activity: 7 hours
Group members participating: Heine Stokholm, Michael Vilhelmsen og Mads Møller Jensen



Dagens mål:

  • Få hul igennem mellem robot og computer via Bluetooth
  • Få en idé om hvordan vi skal lave en bane, som vi kan arbejde med.
  • Overveje robottens konstruktion: Hvordan skal den se ud? Hvor mange sensorer skal den have?
  • Prøve at præcisere de forskellige delmål, vi gerne vil nå i løbet af projektet.
Plan:
  • For at få hul igennem mellem robot og computer, vil vi forsøge at køre nogle af de eksempler, der følger med leJos-pakken. På den måde håber vi hurtigt at få en form for kommunikation
  • Til banen vil vi prøve forskellige alternativer, og teste dem lyssensoren. På den måde kan vi lave en bane/brikker, som forhåbentlig er optimal(e) til projektet.
  • Til robottens konstruktion vil vi diskutere forskellige varianter, der kunne være mulige. Dette punkt bliver meget afhængigt af banens konstruktion, og vi laver formentlig de to punkter i sammenspil.
  • Til sidst vil vi forsøge at beskrive de tanker, vi har med projektet, bl.a. gennem eksempler.
Bluetooth og andre tests
I starten havde vi lidt problemer med at få computeren og robotten til at "tale" sammen over Bluetooth, fordi vi troede, at vi skulle oprette en forbindelse på samme måde, som man gør med andre Bluetooth-enheder. Vi kunne godt få kontakt fra computer til robot, men den anden vej skrev robotten, at "Connection was unsuccessful". Vi fortsatte alligevel, og uploaded en klasse fra leJos sample-mappen til robotten, og en til computeren. Så kørte vi programmerne og fik hul igennem. Programmet var meget simpelt og gik ud på at computeren sendte nogle talværdier til robotten, som skrev disse på LCD-displayet, og returnerede det negerede tal tilbage til computeren. Dette virkede uden problemer og uden yderligere modifikation. 

Programmet vi brugte på PC'en kan ses her
Programmet vi brugte på robotten kan ses her

Ydermere testede vi kompasset, som vi havde fået som ekstra sensor. Kompasset vil hjælpe os meget i forbindelse med mapping, men mere om det senere.

Programmet vi brugte til at teste kompasset kan ses her   

Vi lavede flere forskellige forsøg med kompasset, da vi opdagede, at det var en smule ustabilt. Vi lavede et program, hvor robotten skulle dreje 90 grader og så stoppe, og gennem denne proces kunne vi se, at det, robotten gennem kompasset troede var 90 grader, ikke var det hver gang. Vi kiggede efter råd i leJos API'en, og fandt en kalibreringsfunktion. Vi forsøgte at køre kalibreringen, men vi havde stadig præcisionsproblemer. Vores teori var, at kompasset blev forstyret af computernes magnetfelter. Når nu kompasset skulle placeres 20 cm væk fra motor og NXT, ville det også give mening at den kunne blive forstyret af computerne.

Vi testede herefter kompasset væk fra alle forstyrrende elementer og kalibrerede den igen. Herefter virkede kompasset perfekt! Vi havde dog stadig lidt problemer med at få robotten til at dreje de 90 grader, men vi ved allerede nu, at vi med et PID-system kan klare det problem. Problemet er at robotten drejer lidt for kraftigt, men med et PID-system vil den dreje mindre og mindre skarpt efterhånden som den nærmer sig den ønskede kompasværdi. 

Banen
Vi har snakket meget frem og tilbage om hvordan vi skal konstruere en bane. Opgaveforslaget lægger op til at banen konstrueres med LEGO's egne bane moduler. Disse har imidlertid flere ulemper. For det første sagde Ole, at vi kunne prøve dem indtil vi gav op. Problemet er at LEGO modulerne er grønne og grå i farverne, og disse farver er meget svære for lyssensoren at skelne i mellem. Derudover synes vi, at bane modulerne er en anelse for små. Selv med en "lille" robot ville det være svært at dreje 360 grader uden at noget af robotten kørte ud af banen. 
Derfor valgte vi at konstruere vores egne banemoduler ud fra LEGOs idé. Vi vil altså beholde de fire forskellige slags moduler, men forstørre dem (til 30x30 cm) og så lave dem i sort/hvid. Ved at beholde modulidéen håber vi, at vores mapping bliver nemmere og mere overskuelig, da robotten kun skal kende de fire forskellige moduler, og så være i stand til at sætte dem sammen til et fuldendt kort.

Vi har denne plade at gå ud fra:
Tanken er, at vi med Gaffatape konstruerer modulerne på den hvide plade. Vi har overvejet at lave to baner, så vi kan vise at vores robot kan genkende forskellige baner, men det er kun på idé-stadiet. Forhåbentlig kan vores program mappe så overbevisende, at det ikke er nødvendigt at vise det to gange. 

Robotten
Vi tog udgangspunkt i vores almindelige LineFollower robot
På denne tilføjede vi et kompas, som vi monterede ca. 20 cm. fra motorerne og NXT'en.
Robotten er ca. 20 cm. bred, og vores "vej-moduler" er 30x30cm. Derfor var vi nødt til at forlænge lyssensoren, så denne kan opfange de mørke områder på vores moduler, når hjulene står midt på modulet. Lyssensoren er herved blevet hævet lidt mere, da stangen vi forlængede var vinklet lidt opad. Heldigvis har det ikke forstyrret vores læsninger betydeligt (endnu).
Vi har (midst) 2 måder at konstruere vores robot på - enten lader vi den være som den er nu, og drejer 360 grader når den står midt på et modul. Under denne rotation skal robotten så notere sig hvor på modulet den kan køre ud og hvor den ikke kan.
Den anden måde er at montere yderligere 2 lyssensorer, så den kan måle alle 3 potentielle veje på én gang. Herved ville vi slippe for det tab af præcission vi har når vi drejer 360 grader.
Vi arbejder videre med robotten med én lyssensor - sammen med kompasset er det håbet at vi kan få foretaget præcise 90 graders drejninger uden at komme ud af kurs.

Plan fremover
I dag har været rigtig god, og vi har nået mange ting. Vi har et kompas, der virker, og en robotkonstruktion der burde kunne klare at mappe en bane. Derudover har vi en idé til hvordan banen skal konstrueres. 
Næste gang gang vil vi:
  • Lave banen
  • Lave et PID-system, så vi får fuld kontrol over robotten. 
  • Arbejde videre med Bluetooth kommunikationen. Vi vil få robotten til at sende nogle af de værdier, den læser gennem kompasset videre til computeren, og se om vi muligvis kan arbejde med robotten, mens den er i gang.
Så håber vi at være på vej mod at få robotten til at mappe en bane, hvilket er vores første store delmål. Herefter er planen, at vi tilføjer nogle ekstra egenskaber, som vi vil præcisere nærmere, når første delmål er nået.

Week 11 in LEGOlab

Date: 25. November

Duration of activity: 3 hours
Groups members participating: Heine Stokholm, Michael Vilhelmsen and Mads Møller Jensen

Dagens opgaver:
  • Finde 3 ideer til endcourse project og vælge hvilken vi har lyst til at arbejde med.


Robot pong

hardware:

3 nxt
4 tryksensorer
computer / mobil til styring af paddles

tanker om projektet:

lave et pong spil hvor bolden og de to paddles er robotter. Bolden skal køre automatisk og selv beregne sin rotation når den rammer en væg.
Paddles skal være styret af brugeren.
En af de store problemer ville være noget mapping til bolden så man kunne regne ud hvor meget bolden skulle dreje ved at ramme væggen.
Samtidig skulle vi også finde en måde at styre paddles.
Derudover vil der være visse mekaniske problemer, i forbindelse med at konstruere en bold der altid har de fire trykflader til at vende den rigtige vej.
Det sværeste vil altså være i bolden. De 2 paddles kan laves relativt nemt. Men bolden vil indeholde al "hjernen".
Og der vil som sagt være visse mekaniske udfordringer ved at lave bolden såvel.

Vi ville forvente at kunne præsentere et (vel)fungerende setup, hvor man kan spille pong vha. robotterne.

road mapping

hardware:
1 (2) nxt
lego veje
computer til grafen
kompas sensor

tanker om projektet:

Der skal laves noget præcist mapping så robotten kan navigere rundt på banen.
Der skal laves kommunikation til computeren så den kan fremvise grafen.
Når grafen er lavet skal vi kunne sige på computeren hvor robotten skal køre hen,
og så skal den kunne køre den korteste rute derhen.
Evt. få 2 nxt'er til at samarbejde om at kortlægge banen, og samtidig undgå at køre ind i hinanden.
Herved vil der sandsynligvis også indgå et element af behaviour based systems.
Det sværeste i dette projekt forventer vi vil være 2 dele:
1) At få lavet et ordentligt map
2) At få konstrueret mappet internt i robotten på en måde som giver mening, rent visuelt, når det overføres til en PC.

Vi ville forvente at kunne præsentere en robot der er i stand til at mappe en given bane, og danne et billede af banen
på en PC. Sandsynligvis ville vi også kunne gøre robotten i stand til at navigere hurtigst muligt mellem 2 punkter på banen.

sex bots

hardware:

5+ NXT
2x5+ motorer
Ikke nødvendigvis nogen sensorer, afhængig af hvordan robotterne skal køre rundt

Tanker om projektet:

I dette projekt vil vi kunne anvende behaviour based systemer.
Robotterne skal have flere forskellige lag af opførsler og disse skal kunne udvekles med andre robotter.
Der skal også indgå en måde at kommunikere på mellem robotterne, eks. enten via IR eller Bluetooth.
Det sværeste i dette projekt forventer vi er at få robotterne til at kommunikere.
Selve deres adfærd burde ikke volde de store problemer.

Vi ville forvente at kunne præsentere et setup hvor 5+ robotter kører rundt og udveksler adfærd.
Eksempelvis kunne 1 af robotterne starte med en adfærd der var at sige en lyd hvert 5. sekund.
Når alle 5+ robotter siger en lyd hvert 5. sekund vil vi betragte projektet som en succes.

Konklussion

Vi har valgt projektet "Road Mapping".
Grunden til dette er at vi synes det er meget interessant at arbejde med autonome robotter, der er i stand til at udføre tasks af sig selv.
Mapping er også et interessant emne, da det ikke er trivielt. Desuden synes vi det er rart at have noget visuelt at arbejde med/udfra,
og hertil virker det meget fornuftigt, at lave et billede af banen på PC'en vha. robotten.

Helt konkret vil vi forsøge at lave følgende:

En NXT robot med 2 motorer, der kører rundt på en tilfældig bane konstrueret at LEGO-road moduller (eller tilsvarende sort/hvide papir-udgaver).
Robotten skal holde styr på hvor den har kørt og hvor den ikke har kørt, og den skal stoppe når den har kortlagt hele banen.
Herefter skal banen sendes via Bluetooth til en PC, og ud fra dette input skal vi på PC'en kunne konstruere et kort over banen.
Dernæst vil vi vælge 2 stedet på banen, (evt. givet ved 2 moduler) og vores robot skal så kunne finde den korteste vej mellem disse 2,
og køre denne vej, hvis den startes i et af stederne.

Planen for arbejdet er i første omgang at mødes næste torsdag, og planlægge hvornår vi skal arbejde videre ;)

torsdag den 18. november 2010

Week 9 in LEGO lab

Date: 4. November

Duration of activity: 3 hours
Groups members participating: Heine Stokholm, Michael Vilhelmsen and Mads Møller Jensen

Dagens opgaver:
  • Byg NXT robotten om, så den kan fungere som BumperCar med koden givet fra lejos NXT distributionen i samples/BumperCar
  • Lav eksperimenter med BumperCar
BumperCar
Vi har ombygget vores robot som følger:

Vi har beholdt robotten fra uge 8 og påsat en tryksensor, så robotten kan "føle" at den kører ind i noget.
Herefter har vi uploaded programmet fra tutorialen til robotten med følgende resultat:


Eksperimenter med BumperCar
  • Hvad sker der når tryksensoren holdes i bund?
Når tryksensoren holdes i bund, kræver DetectWall opførslen hele tiden motoradgangen, og robotten forsætter med hele tiden at lave afvigelsesmanøvren.
  •  Både DriveForward og DetectWall har takeControl metoden. Undersøg i Arbitrator koden om Driveforwards takeControl metode, når DetectWall ønkser kontrollen.
I Arbitrator har vi et loop, som kører alle Behaviors igennem. Når loopet finder den Behavior med højest prioritet, som returnerer true ved takeControl, ved den at det er denne Behavior som skal afvikles. Derfor afbrydes loopet, når en sådan Behavior er fundet. Dette betyder at resten af de Behaviors med lavere prioritet ikke bliver kaldt. I BumperCar tilfældet betyder det at DriveForwards takeControl metode IKKE bliver kaldt, når DetectWalls takeControl metode returnerer true. 
  • Implementer end tredje opførsel,  Exit, med højeste prioritet. 
Vi har implementeret en Exit opførsel med højeste prioritet. Dette betyder, at hvis Exit knappen er nede, vil programmet afbrydes, i stedet for at køre fremad, eller afvige. Hvis vi øgede Sound.pause(20) til Sound.pause(2000), ville det ikke være muligt at afbryde robotten i 2 sekunder, hver gang Arbitratoren skal tjekke om DetectWall vil have adgang til motorene. Dvs. vi kan ikke afbryde i bestemte steder i loopet.
  • For at undgå ventetiden i loopet, få den ultrasoniske sensor til at tage prøver hver 20 msek og gemme værdien i en variabel, så takeControl metoden, blot kan tjekke denne værdi.
Vi har valgt at implementere en tråd, som hver 20 msek opdaterer en variable med den senest målte værdi. Fra DetectWall's takeControl metode kigger vi nu bare på den variabel som tråden opdaterer. På den måde undgår vi ventetid i loopet i Arbitration klassen. Vi prøvede at sætte måleintervallet op til 2 sek, og det betød at vi kun kunne afvige hver andet sekund (fordi det kun var der, at vi fik nye målinger). Til gengæld kan vi hele tiden afbryde, modsat før hvor vi var hæmmet af ventetiden i loopet. 
  • Lad DetectWall få robotten til at køre baglæns 1 sekund før den normale afvigelsesmanøvre sker. Implementer at DetectWall kan afbrydes(og køres forfra), hvis den efter det ene sekund stadig kan se forhindringen.
Dette er gjort.Vi har implementeret dette ved hjælp af en ekstra tråd. Tråden indeholder den afvigende opførsel. Hvis tryksensoren så rammes igen, interruptes tråd, og en ny tråd af samme slags kaldes og startes. På den måde kan robotten blive ved med at afvige hvis den bliver ved med at se forhindringer.

Koden for BumperCar efter alle implementationer på nær sidste opgave kan ses her

Koden for BumperCar efter den sidste implementation kan ses her

onsdag den 10. november 2010

Week 8 in LEGO lab

Date: 4. November

Duration of activity: 3 hours
Groups members participating: Heine Stokholm, Michael Vilhelmsen and Mads Møller Jensen

Dagens opgaver:
Thor kørte rundt, og stoppede med jævne mellemrum. Efter ca. 10 sekunder spillede han en lille lyd, og derefter fortsatte han med at køre tilfældigt rundt.
  • Look at the LCD and try to interprete the output
Vi ser 3 linjer:
Drive, Avoid og Play.
Ud for dem alle er et tal der enten er 0 eller 1. Dette tal er 1 når denne behaviour bliver suppresed. Derudover er der et lille bogstav bagved dem alle (enten f, b eller s). Desuden er der et tal fra 0-255 ud for Avoid (afstanden som sensoren måler).
Vi ser at når Avoid suppreser Drive bliver 0'et ud for Drive sat til 1. På samme måde ser vi at når Play suppreser Drive og Avoid bliver begge deres 0'er sat til 1.
  • Look into the three classes and try to identify how the triggering condition is implemented in each of the classes and how the actions for each behavior is implemented
PlaySounds har en while-true løkke. I løkken sleeper den i 10 sek. Når den ikke sleeper, kalder den suppress, og spiller en lille melodi og kalder derefter release. Triggering condition er altså at de 10 sek. er gået - Action er at spille en melodi.

AvoidFront har en while-true løkke. I løkken looper den i en while-løkke så længe den afstand sensoren måler er større end tooCloseThreshold. Så længe afstanden er større måler den en nye afstand og skriver den gamle ud på displayet. Når afstanden pludselig er mindre end threshold suppreser den, og bakker, drejer og til sidst releaser den.
Triggering condition er altså at den målte afstand er mindre end threshold - Action er at bakke og dreje lidt.

Drive har en while-true løkke. I løkken vælges en tilfældig retning og der køres i denne retning, derefter delayes der i et tilfældigt stykke tid. Drive starter med at suppresse og releaser når den er færdig.
Triggering condition er faktisk ingenting; så længe den ikke suppresses kører Thor hele tiden tilfældigt rundt.
Action er at køre i en tilfældig retning
  • Try to watch the car with only the first thread active and then with only the two first threads active to observe the behaviors more clearly.
Vi mente godt at vi kunne forestille os hvordan Thor ville opføre sig hvis vi kun havde en eller to af trådene aktive. I stedet mente vi at det var tydeligere at se hvordan Avoid suppresser Drive og Play suppresser begge dele, hvis Thor hele tiden kører rundt. Derfor fjernede vi det tilfældige delay i Drive, og så opførslen. Videoen her viser resultatet.
  • What is the purpose of making these threads daemon threads as done in the constructor of the Behavior class
Da en daemon-tråd holder op med at eksistere når de tråde den skal servicere terminerer, giver det mening at lade de 3 behaviours være daemon-tråde, da de ikke giver mening at eksistere for sig selv.



Week 7 in LEGO lab

Date: 28. October
Duration of activity: 3 hours
Groups members participating: Heine Stokholm og Mads Møller Jensen




Dagens opgaver:

  • Brug Tom Dean's noter til at implementere Braitenbergs "Vehicle 1", "Vehicle 2a" og "Vehicle 2b
  • Lav en ændring i programmet, så MIN_LIGHT og MAX_LIGHT bestemmes af N samples og altså ikke af alle samples, som robotten har set i sin levetid.
  • Implementer Vehicle 2 (a eller b) med to "threads of control" i stedet for én (Èn for hver forbindelse mellem sensor og motor).
Vehicle 1:
Vi byggede Vehicle 1:


Vehicle 1 er en robot som (i dette tilfælde) har en mikrofon og fremdriften i motorene bestemmes af det lydniveau, som mikrofonen opfanger. Idéen er at robotten skal køre hen i mod en lydkilde, men dette bliver aldrig tilfældet, da robotten ikke har nogen anelse om, hvor lydkilden befinder sig, men kun hvad et givent lydniveau er, der hvor robotten befinder sig.
Først implementerede vi bare, motorene reagerede på lyd, så robotten kørte bare den opfangede en svag lyd.
Det resulterede i at robotten kørte af sig selv p.g.a. den støj som motoren udsender. 




Derfor implementerede vi jvf. Tom Deans note "Braitenberg's Vehicles", en håndtering af baggrundsstøj. Dette gjorde vi vha. et estimat. Vi kunne have valgt at kigge på alle hørte værdier, og beregne gennemsnittet, men over tid er dette en dårlig løsning.
Derfor brugte vi estimatløsningen, hvor det kun er nødvendigt at gemme den sidste estimatværdi, for at beregne den næste.
Som Java kode ser det således ud.


double estimate = 0;
double beta = 0.2
...
estimate = estimate + beta*(volume-estimate);

Dette virkede og robotten stoppede med at reagere på baggrundstøj og dens egen motor.





Hele koden for Vehicle 1 ses her


Vehicle 2:
Vi byggede Vehicle 2:


Vehicle 2 har modsat Vehicle 1 to sensorer (i dette tilfælde lyssensorer). Motorkraften på de to motorer bestemmes så af de lysværdier, sensorerne opfanger. Der findes to forskellige udgaver af Vehicle 2:
a) Her reagerer højre motor på værdierne fra højre lyssensor, og på samme måde i venstre side. Det betyder, at robotten vil køre væk fra en lyskilde.
b) Her reagerer højre motor på værdierne fra venstre lyssensor, og omvendte. Det betyder at robotten vil køre hen imod en lyskilde.


For at få det til at virke med to sensorer ændrede vi en lille smule i koden fra Vehicle 1:


lightL = lightLeft.readNormalizedValue();
lightR = lightRight.readNormalizedValue();
...
estimateR = estimateR + beta*(volume-estimateR);
estimateL = estimateL + beta*(volume-estimateL);
...
Car.forward(normalized(lightR), normalized(lightL));


Det gav følgende resultat:


Herefter implementerede vi MIN_LIGHT og MAX_LIGHT variablene, så den normaliserede værdi (den værdi som motorene skal køre med) passer til det miljø som robotten befinder sig i. Den måler en maksimal lysværdi og en minimal lysværdi, så den reagerer optimalt i de omgivelser den er i. 
Dette gav følgende resultat:
[VIDEO]


Koden kan ses [link]


Miljøændring
I Tom Dean's noter bliver MIN_LIGHT og MAX_LIGHT værdierne kun reguleret, når en henholdsvis mindre og større værdi opfanges. Dette er dog ikke helt hensigtsmæssigt, da lysomgivelserne skifter, eksempelvis når vi går fra dag til nat. Derfor har vi brug for at rekalibrere disse værdier efter N tid eller N indsamlet data. Dette forsøgte vi at implementere med følgende resultat:
[VIDEO]


Koden kan ses [link]


To tråde
Til sidst prøvede vi at lave to "threads of control" i stedet for en. 
Det gav følgende resultat:
[VIDEO]


Koden kan ses [link]

fredag den 15. oktober 2010

Week 6 in LEGO lab

Date: 7. October
Duration of activity: 8 hours
Groups members participating: Michael Vilhelmsen, Heine Stokholm og Mads Møller Jensen


Robot race


I dag er målet at bygge en robot, der kan konkurrere i LEGOLABs officielle ROBOT RACE.
Robot kapløbet går ud på at bygge en robot, som kan gennemføre "The Alishan Train Track" på hurtigst mulig tid.


Robotten tager udgangspunkt i PID system vi lavede sidste uge. Koden kan ses her.
Svingene i denne bane er ret specielle og meget svære for en robot, der kun kan følge en sort linje.
Derfor har vi modificeret programmet som følger:


Istedet for kun at have vores pid system til at styre robotten har vi nu også nogle forskellige states robotten kan være i repræsenteret ved følgende booleans:



         boolean rightTurn = false;
boolean leftTurn = false;
boolean direction = true;
boolean rightTurnAllowed = true;
boolean leftTurnAllowed = false;
boolean rightFinished = false;
boolean rightFinished2 = false;
boolean leftFinished = false;
boolean up = true;



Når rightTurnAllowed er true tjekker vi hele tiden den venstre sensor for om den ser sort, og hvis den gør laver vi følgende ændring på motorkraften:


         if(rightTurn) powerC = (powerA * 100 ) / 175;


Det vil sige at vi giver mere kraft til den inderste motor i svinget så robotten svingere blødere. Derefter registrerer vi så om den forreste sensor registrer sort så vi har færdiggjort svinget. 



I starten kunne robotten godt køre op ad banen:


 


Men som det ses havde vi allerede her lidt problemer med lys sensoren, som var spændt helt fast. Dette viste sig også at være et problem, når vi skulle ned af banen, fordi sensoren ikke kunne se den sorte streg, når robotten kørte ud over kanten, fordi sensoren blev løftet og fik andre værdier. Derfor valgte vi at modificere lidt i robotdesignet, så sensoren kunne få mulighed for at have en konstant afstand til banen.
Desværre gjorde det, at sensoren kom for langt frem i forhold til hjulene, så robotten blev umulig at styre. Sensoren fik robotten til at køre af sporet fordi den kom til svingene før selve robotten, og sendte den dermed på afveje. 
Vi skiftede derfor tilbage til det tidligere design og arbejdede videre med koden, for at undgå de fejllæsninger som sensoren laver, når vi kører ned af banen. 

Ved første forsøg på at køre ned, prøvede vi til dels at hardcode svingene, så robotten fulgte nogle bestemte instruktioner, når den (ved første sving) venstre lysmåler så en sort streg. Det gav dog nogle problemer, da robotten ikke var konsistent i kørslen, pga. PID systemet, som gjorde at vi ramte plateauet forskelligt hver gang.
Vi brugte mange forsøg og tweakede konstanterne, men udslaget var forskelligt hver gang, så robotten nogle gange kun kunne klare første sving og andre gange kun kunne klare sving nummer 2. 

Pga. de mange komplikationer gik vi tilbage til vores oprindelige PID system, og i vores næste forsøg forsøgte vi at ændre PID systemet, når robotten var i gang med at svinge, i håb om at den så kunne finde tilbage på banen. Dette lykkedes til dels, men robotten var stadig for inkonsistent til at dette virkede hver gang. Ved et perfekt gennemløb kunne robotten godt klare nedturen, men der var for langt mellem disse.


Selvom systemet ikke var perfekt, prøvede vi alligevel at implementere rotationen på toppen og stoppet i bunden. Det gjorde vi ved at hardcode en lille fremdrift efterfulgt af en 180 grader rotation når vi var færdige med venstresvinget og både venstre og højre lyssensor så en sort streg på samme tid. Dette fungerede udemærket efter en del tweaking af de forskellige variable. Stoppet i bunden fungerede ved at hvis begge sensorer målte sort og vores boolean up fortalte vi var på vej ned, så stoppede vi. 


Vi stod altså med en robot, som nogle gange kunne køre op ad banen og nogle gange kunne køre ned. Desværre måtte vi se i øjnene at vores styring var for inkonsistent, så det lykkedes os aldrig at få robotten til at køre både op og ned. Det tætteste vi kom, var at robotten kørte op og vende og kørte igennem første sving på vej ned og derefter kørte den af sporet. 
Koden og robotdesignet var altså desværre ikke tilstrækkeligt til at gennemføre banen!