torsdag den 1. oktober 2009

Robot Race (TØ 6 + TØ 7)

Program for torsdag 08.10:
I dag fortsætter vi med sidste uges test af ColorSensoren og vil se på andre mulige løsninger, så Alishan banen kan gennemføres hurtigst muligt. Vi har overvejet følgende løsningsmodeller:

Robot med 4 ColorSensors på række:

Idéen bag denne robot var, at de to inderste sensorer skulle kunne følge en sort linie ved at korrigere robotten svagt i den rigtige retning hvis en sort farve registreres af én af sensorerne (dvs føre sensoren væk fra det sorte). I de tilfælde hvor robottens to yderste sensorer registrerer sort (sker i forbindelse med de forskellige plateauer) skal robotten korrigere ved at stoppe den ene motor og give fuld speed på den anden for at dreje kraftigt. Når robotten registrerer en målstreg (alle 4 sensorer måler sort) skal robotten vende 180 grader og så fortsætte ned af bakken.
Vi havde svært ved at løse problemet, når robotten skulle forcere det sidste stykke af en bakke. Sensorerne kom simpelthen for højt op og registrerede derfor alle farven sort eller grøn. Det problem løste vi med en løftearm, så alle sensorer konstant kørte lige over jorden. Vi måtte til sidst sande, at denne løsning ikke var optimal til den givne opgave, da hastigheden hvormed robotten kunne navigere korrekt var for lav. Vi måtte komme frem med en specialiseret robot, som var hurtig på den givne bane og ingen andre steder. Derfor overvejede vi nedenstående robotter.
Update: ved slutningen af denne TØ fandt vi ud af sensorport 4 på vores NXT Brick ikke virkede. Dette kan være skyld i, at robotten ikke reagerede som forventet.


Robot med 1 TrykSensor:
Idé: robotten skal når den kører op af en bakke være trykket i bund. Når den når et plateau og tryksensoren frigives, skal robotten blot følge en forudbestemt kurve indtil sensoren atter er i bund. Vi kom frem til, at denne løsningsmodel ikke var holdbar da sensoren ikke ville kunne fungere på vejen ned af bakken (vil altid være trykket i bund).



Robot med 2 ColorSensors og 1 afstandsmåler som hænger langt fremme på robotten:

Idé: Skab en robot som ved hjælp af ColorSensorer følger den sorte streg på vej op og ned af bakken. Når afstandsmåleren så registrerer et fald eller en stigning, skal robotten dreje i en forudbestemt kurve. Robotten skal programmeres efter de givne omgivelser, så den drejer korrekt, dvs. højre første gang og så venstre etc.
Problem: afstandsmåleren er for følsom overfor bilen bevægelser, hvilket resulterer i svingende værider som er for svære at arbejde med. Efter diverse tests kasserede vi denne model.





Hardcoding/state:

Realiteten er, at denne konkurrence ikke kan vindes med en "tænkende robot" som udelukkende reagerer på det data den samler ind. Man kan hardcode dele af banen ind i robotten, så den følger den sorte linie v.h.a. 2 ColorSensors indtil et plateau nåes og derefter skal robotten dreje efter vores hardcodede anvisninger (dvs. uden at tage højde for sorte streger og andre omgivelser). Denne metode nåede vi ikke at afprøve.

Kode - Control loop for 4 lightsensors:

if (sensorOne.white() && sensorFour.white()) {

if (sensorTwo.white() && sensorThree.white()) {
//Continue ahead
Car.forward(power, power);
} else if (sensorTwo.black() || sensorTwo.color()) {
Car.forward(power, turnPowerMiddle);
//Turn slight right
} else if (sensorThree.black() || sensorThree.color()) {
//Turn slight left
Car.forward(turnPowerMiddle, power);
} else {
Car.stop();
}

//Edge turns
} else if (!sensorOne.white() && sensorFour.white()) {
Car.forward(power, 0);
} else if (sensorFour.white() && !sensorOne.white()) {
Car.forward(0, power);
} else if (sensorOne.black() && sensorFour.black()) {
Car.stop();
}


Kode - Test kode for Ultra sonic sensor:

final int upSlopeDistance = 23;
final int downSlopeDistance = 8;
final int upPlatformDistance = 26;
final int downPlatforDistance = 6;
UltrasonicSensor sensorDistance = new UltrasonicSensor(SensorPort.S3);

if (sensorDistance.getDistance() == upPlatformDistance) {
Car.stop();
}


Tid brugt på TØ 7: 7 timer

Program for torsdag 01.10:

I dag skal vi eksperimentere med Lightsensoren og Linefollower programmet[1] for at blive klar til at bygge vores robot til Robot Racet. Den bane vi skal køre på i racet ser sådan ud:
Målfeltet (ved gulvet) er markeret med grøn tape. Derfor får vi brug for at kunne skelne imellem 3 farver; hvid, sort og grøn. Dagens program ser derfor sådan ud:
  1. Test den udleverede BlackWhiteSensor.java[2] og LineFollowerCal.java[1]
  2. Udvid BlackWhiteSensor.java til også at kunne læse grøn
  3. Udvid koden så robotten stopper når den kommer ind i det grønne målfelt
  4. Forbedre vores kode så vi får en hurtigste tid

1 - Test af udleveret kode
Vi testede BlackWhiteSensor.java og LineFollowerCal.java (uden modifikationer)Som forventet virkede denne linefollower som den skulle. Vi bemærkede dog at denne version ocillerede mindre end den første linefollower vi testede, for et par uger siden. Vi valgte ikke at gøre mere ud af dette, så vi kunne komme igang med det interessante.

2 - Fra BlackWhiteSensor til ColorSensor
Vi forsøgte først men en hurtig implementation der samplede den grønne farve og ud fra en konstant margin, kunne udregne hvid og sort. Dette virkede dog ikke. Vi besluttede os for at ved starten af programmet skal alle 3 farver samples. [beskrivelse af upper og lower bounds]. Derudover er sersor klassen lavet så den virker med alle farver (i teorien) og ikke kun hvid, sort og grøn.


import lejos.nxt.*;

public class ColorSensor {

private LightSensor ls;
private int colorLightValue;
private int blackLightValue;
private int whiteLightValue;
private int colorLowerBound;
private int colorUpperBound;
private final int MARGIN = 5;

public ColorSensor(SensorPort p)
{
ls = new LightSensor(p, true);
// Use the light sensor as a reflection sensor
// ls.setFloodlight(true);
}

private int read(String color){

int lightValue=0;

while (Button.ENTER.isPressed());

LCD.clear();
LCD.drawString("Press ENTER", 0, 0);
LCD.drawString("to callibrate", 0, 1);
LCD.drawString(color, 0, 2);
while( !Button.ENTER.isPressed() ){
lightValue = ls.readNormalizedValue();
LCD.drawInt(lightValue, 4, 10, 2);
LCD.refresh();
}
return lightValue;
}

public void calibrate(){
blackLightValue = read("Black");
whiteLightValue = read("White");
colorLightValue = read("Color");
colorLowerBound = (blackLightValue + colorLightValue)/2;
colorUpperBound = (whiteLightValue + colorLightValue)/2;
}

public int[] getCalibration() {
int[] tmp = new int[3];
tmp[0] = blackLightValue;
tmp[1] = whiteLightValue;
tmp[2] = colorLightValue;
return tmp;
}

public void setCalibration(int[] cal) {
blackLightValue = cal[0];
whiteLightValue = cal[1];
colorLightValue = cal[2];
colorLowerBound = (blackLightValue + colorLightValue)/2;
colorUpperBound = (whiteLightValue + colorLightValue)/2;
}

public boolean black(){
return (ls.readNormalizedValue() <> colorUpperBound);
}

public boolean color(){
return ((colorLowerBound <>

3 - Make it stop please
Vi har udviddet LineFollowerCal.java så robotten vil stoppe når den ser den samplede målfelts farve.

Ved første forsøg virkede dette efter hensigten, bortset fra at robotten ikke kører helt ind i feltet.

Herfra nåede vi ikke mere i denne TØ.

4 - Optimering af kode
(Nåede vi ikke)

Tid brugt på TØ 6: 3 timer

Referencer

[1]LineFollowerCal.java
[2]BlackWhiteSensor.java

torsdag den 24. september 2009

TØ 4: Sejway - balancerende robot

Tom Ørsnes, Mark Surrow, Harald Andertun - ca 3 timer.

Denne uge har vi arbejdet med en balancerede LEGO robot, lignende Philippe Hurbain's NXTway-robot. Idéen er at den skal fungere ligesom den velkendte selvbalancerende segway.

Målet med denne lab session var først at prøve SejwayBad.java af, hvor vi gerne skulle se robotten kører meget ustabilt og drejer voldsomt frem og tilbage. Herefter skulle vi afprøve Sejwat.java, som er en forbedring af SejwayBad.java. Vi skulle gerne kunne obsevere at Sejway.java virker bedre end SejwayBad.java (bedre balance).


Vi fik downloaded de 2 kode filer, men støte derefter på et problem. Vi kunne ikke forbinde til vores NXJ, da de libraries vi bruder til kommunikere med NXJen i OS X ikke virkede. Det viste sig at en af sidste uges opdateringer til OS X satte Java til at kører 64-bit som standard, hvorfor USB og Bluetooth (hhv. usblib og bluecore) ikke længere virkede. Løsningen var at tvinge Java til at starte NXJ applikationerne (f.eks. nxjbrowse) i 32-bit. Dette tog desværre noget tid at finde ud af.

Det gøres ved at indsætte
-d32 i den sidste linie i det script man ønsker at køre. Her er et eksempel fra nxjbrowse:
java -d32 -Dnxj.home="$NXJ_HOME" -DCOMMAND_NAME="$NXJ_COMMAND" -Djava.library.path="$NXJ_BIN" -classpath "$NXJ_CP_TOOL" lejos.pc.tools.NXJBrowser "$@"

SejwayBad.java forsøg:
Problemet med denne kode er at programmet kører for langt hver vej før den skifter retning. Det 'overreagerer' hver gang, og lærer ikke af sine fejl. Efter at have overreageret burde den korrigere nogle variable så den ikke korrigerer lige så meget næste gang.

SejwayBad.java har en variable int NEUTRAL = 37. Denne variable angiver lysstyrken læst af lyssensoren når robotten står i balance (nautral). I vores tilfælde var det for lavt. Da vi kørte programmet, kunne vi aflæse på displayet en værdi ca 400. Dette resulterede i at robotten straks væltede. Så for at få SejwayBad til at virke var vi nødt til at korrigere denne værdi.

Men pga. de problemer vi havde tidligere med USB-driveren og java, valgte vi at stoppe med SejwayBad og gå videre med den bedre kode (Sejway.java) som vi fået udleveret.

Sejway.java forsøg:
Sejway.java koden er bedre af to grunde. Den første er at programmet starter med at sætte den værdi der læses fra lyssensoren, som balance punkt (i modsætning til SejwayBad.java der havde en pre defineret værdi i koden). Den anden grund er at Sejway.java forsøger at tage højde for overkorrigering ved at huske hvormeget der sidst blev korrigeret med og ændre ud fra dette, hvormeget der korrigeres.

Vi lavede et forsøg med koden uden at have ændret i det, for at se hvor længe robotten kunne holde sig oprejst. Det var muligt for den at holde sig oprejst i et par sekunder, inden den væltede.

Herefter kiggede vi på koden for at se om vi kunne forbedre dette. Vi forsøgte os med at sætte PID variablen KP ned til 10. Det gjorde vi ud fra den obsevation at robotten i første korrigerede sin balance for kraftigt i de første par iterationer og endte med at "stille" sig på lyssensoren. Vi ville derfor nedsætte styrken med hvilken robotten startede med at korrigere, så den kunne nå selv at ændre på sin korrigtions styrke.
// PID constants
final int KP = 17;

Efter nogle forsøg endte vi på 17, hvilket viste sig at være den værdi der fik robotten til at klare sig bedst. Det var det ikke en forbedring på mere end et par sekunder, robotten kunne holde sig oprejst. Herefter nåede vi ikke længere.

Reflektion:
Vi skulle måske have kigget mere på hvordan algoritmen virkede og forsøgt at arbejde med den, såvel som PID værdierne. Vi skulle også have kigget på de andre konstakter, ud over KP.

En anden ting der viste sig vigtig var hvor godt man fik placeret robotten i sit balance punkt. Ulempen her er at der i et givet forsøg ikke er nogen garenti for at vi kan placere robotten på præcis samme måde, som i forgående forsøg og dette kan påvirke vores fortolkning af den effekt, som vores ændringer i koden har givet. F.eks. er det muligt at vores ændringer i KP konstanten ikke var grunden til at vores robot klarede det (en smugle) bedre, men grunden var at vi var bedre til at placere robotten i sit balance punkt ved starten af testen. Vi havde dog ikke tid til at udforske dette, grundte den "spildte" tid på USB/Bluetooth driverne.

torsdag den 17. september 2009

TØ 3: Test af sound sensor

Vi startede med at tilslutte en NXT sound sensor til vores LEGO 9797 bil. Derefter compilede vi SonicSensorTest.java og uploadede den til Killbot. Vi havde først tænkt at lave lidt forskellige tests og udfylde en tabel med de forskellige data, men vores display opdatering virkede til at være for langsom og unøjagtig til denne manuelle aflæsning. Tabellen ses herunder:

LYDFYSISK AFSTAND/CMMÅLT AFSTAND/CMOMGIVELSE
klap1050lidt støj
klap5030lidt støj
klap10040lidt støj
klap500?
lidt støj
Ringetone50?lidt støj
Ringetone50?lidt støj

Denne lyd sensor virker meget følsom. Den registrerer lufttræk og baggrundsstøj meget nemt. Derfor valgte vi at teste den i et lille rum i Zuse, med meget lidt baggrundsstøj, for at kunne aflæse værdierne bedre. For at få et klap med samme styrke hver gang, optog vi klappet på en iPhone. Hør klappet her. Vi ville teste om et klap udført fra samme afstand ville give den forventede måling. Det tilfredsstillende resultat ses i grafen:














Dernæst testede vi Clap Controlled Car. Bilen virkede helt efter hensigten, så længe klappet var højt nok (måling på over 90).

torsdag den 10. september 2009

TØ 2: Test af Ultrasonic Sensor

Under denne uges TØ fik vi endelig Lejos til at samarbejde med vores macs. Vi brugte lidt tid på øvelsen fra sidste uge, LineFollower.java, men fokuserede hovedsageligt på NXT ultrasonic sensoren. Herunder ses en test af vores linefollower :



Med SonicSensorTest.java testede vi sensoren under forskellige forhold (bl.a. trævæg kontra gipsvæg) og opdateringshastigheder. Resultatet ses i tabellen herunder:

Fysisk afstand (cm) Killbots målte afstand (cm) Forhold
30 29-30 svag støj mod hvidt papir
20 22 -"-
10 11-12 -"-
30 30 mod plastic
20 21-22 -"-
11 11-12 -"-
30 30 mod trævæg
11.5 13 mod glas
30 30 glas
120 120 væg
254 243 gips væg
244 243 -"-

Selve brugen af sensoren begrænses naturligvis idet man ikke kan benytte den hvis man har behov for at måle afstande længere end 243-254 cm. Men for os bør det ikke være en begrænsning, da vi arbejder med forholdsvis korte afstande og de målte afstande er ganske præcise.

På korte afstande (op til 30 cm) fik vi nogle flotte og korrekte målinger selvom vi ændrede sensorens reaktionstid til 1 millisekund. Men på længere afstande bliver sensoren begrænset af tiden som lyden er om at echo tilbage og målingerne svinger for meget, hvilket begrænser brugbarheden.

Tracker: Vi arbejdede også med koden Tracker.java og Car.java, der kontrollerede bilen ved brug af Ultrasonic Sensoren. I sin originale opsætning kørte bilen kun fremad og bagud. Når den kom tæt på en forhindring bremsede den og bakkede lidt. Programmet var på dette tidspunkt ikke tilstrækkeligt intelligent til at kunne køre ud af en blind vej.

Vi pillede lidt ved de forskellige variable, og tilføjede også ny funktionalitet til programmet. I Car klassen tilføjede vi følgende metode, eftersom vi ønskede at bilen skulle dreje lidt til venstre når den havde stødt på en forhindring og været nødt til at bakke lidt.

public static void turnleft(int rightPower)
{
rightMotor.controlMotor(rightPower, forward);
}

I Tracker klassen tilføjede vi et kald til turnleft() metoden, lige efter at bilen havde bakket lidt. På denne måde drejer bilen indtil den ser en ny mulighed for at køre lige ud.

Car.backward(power, power);
LCD.drawString("Backward", 0, 6);
Car.turnleft(power);


Problemet med den blinde vej var nu løst - se video :




fredag den 4. september 2009

Vi har nu fået løst problemet og kan uploade filer til robotten (Yay!). Problemet var mangel på dokumentation for 0.85 til OS X. Det er nemlig slet ikke nødvendigt at installere USB Drivere, build lejos_nxj, opdatere .jar filer eller redigere i build scripts (og hvad vi ellers var ude i) i den nye version da USB drivere osv. er inkluderet i lejos_nxj. Det var her problemet opstod - de guides vi har brugt er outdated til 0.85, da man ved at installere Fantom USB driveren selv, tilsydenladende ødelægger lejos_nxj installationen.

Det eneste man skal er at download lejos_nxj, unzippe det og sætte 4 environment variabler:
export NXJ_HOME=din_sti_til_nxj/lejos_nxj
export DYLD_LIBRARY_PATH=${NXJ_HOME}/bin
export PATH=${NXJ_HOME}/bin:${PATH}
export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home (hvis den ikke er sat)

så kan man benytte lejos_nxj/bin/nxjbrowse til at uploade. (NB: nxjconsoleviewer ser ikke ud til at virke, ihvertfald ikke på Os X)

Eclipse Plugin virker stadig ikke (over USB, BT ikke prøvet), men det har ikke top priotet.

torsdag den 3. september 2009

TØ 1: Udlevering af LEGO og installation

Vi fik udleveret vores Lego sets og fik bygget bilen vi skulle lege med. Herefter kastede vi os over at få installeret leJOS værktøjerne. Vi bruge alle Macs og det skulle vise sig ikke at være specielt nemt at få til at kører. Efter at have fulgt guides på leJOS hjemmeside og guiden i README.html uden held, kiggede vi efter andre guides. Vi har fik afprøvet en del guides, men uden held. Her er nogle af dem:
http://tucsontechnics.blogspot.com/2009/05/installing-lejos-on-macbook-pro.html
http://lejos.sourceforge.net/forum/viewtopic.php?t=1186&start=0

Selvom der ikke har været problemer med at gøre som beskrevet i de forskellige guides og vi har fået installeret en USB driver (Fantom USB Driver), er der stadig problemer med at connecte til Brick'en. Vi har brugt en debug version af pccomm.jar (lejos_nxj/lib) og det viser sig at være ham her der giver problemer:
java.lang.NoClassDefFoundError: lejos/pc/comm/NXTConnector

Vi har oprettet et indlæg på leJOS forum og er ved at få hjælp til at løse problemet. En meget mere detaljeret beskrivelse af hvad vi har gjort og problem beskrivelse findes i indlæget her:
http://lejos.sourceforge.net/forum/viewtopic.php?t=1692