NXT Programming, lesson 15

Dato: 15/16-12-2010
Varighed: 10 timer
Deltagere: Nick, JC, Allan


Formål:

Vi skal lave koden til mobiltelefonen, så vi kan teste billederne den tager, når robotten bevæger sig. Vi skal arbejde videre med banen, for at sikre at den virker sammen med klodserne og vi skal begynde på koden til den endelig robot, så robotten kan finde vej vha. lyssensorerne. 
Derudover skal ultrasonicsensoren flyttes, da mobiltelefonen er i vejen, når afstanden måles.


Plan:

-Lave et program til mobiltelefonen, der tager billeder
-Teste robotten på banen med en klods
-Arbejde på koden til lyssensorene
-Ultrasonicsensor flyttet og testet


Test af robot med klods


Vi testede vores robot med en klods i kloen på banen.

Som det kan ses på videoen, så kan kloen ikke holde godt nok fast i klodsen på vores bane. Vi har tapet kanterne mellem papirene, men klodsen vælter stadig. Vi besluttede os derfor for at ændre på kloen frem for at ændre på banen. Dette blev gjort ved at tilføje en ekstra klo på hver siden, så den samlede klo nu har et ordenligt greb om klodsen. Videoen kan ses her:

Test af billeder taget fra mobil i bevægelse

Vi lavede et simpelt program til mobiltelefonen, der tog et billede hvert sekund og lavede et program til robotten, der fik den til at snurre om sig selv, hurtigere og hurtigere.

Denne test skulle gerne give os en ide om hvor skarpe billederne er fra robotten i bevægelse og hvilke dele af billedet vi har brug for.

Her under er et par af billederne taget fra mobilen:

 

Som det kan ses er de meget utydelige og vi kom også frem til at kameraet ikke kunne tage billeder hurtigt nok. Vi skal derfor lave en videostream fremfor enkelte billeder.
Videostream

Video streamen kommer som nævnt fra en Google Nexus One telefon. Det har taget en del timer at få lavet kode til telefonen der kan analysere en livestream hurtigt nok. Planen er at telefonen skal dele billedet ind i en mængde områder og derefter at sende dette til NXT'en. Muligvis vil det kun være nødvendigt at sende en bestemt linje på en pixels brede, som altid vil indeholde klodserne, da kameraet altid er i samme højde. Koden ser ud som følger:

Thread t = new Thread() {

            public void run() {

                while(running) {                

                 if(previewBuffer!=null) { 

                 int[] res = new int[previewBuffer.length];

                 decodeYUV(res, previewBuffer, w, h);

                 Bitmap.createBitmap(w,h,Bitmap.Config.ARGB_8888);

                

                 Bitmap bMap = Bitmap.createBitmap(res, w, h, Config.ARGB_8888);

                 int segments = 12;

                 int width = bMap.getWidth();

             int height = bMap.getHeight();

             for(int i=0; i<width; i++) { //width

             for(int j=0; j<height; j++) { //height

             int color = bMap.getPixel(i, j);

             }

             }

                 }

                }

            }

        };

        t.start();

Den gennemløber indtil videre blot livestreamen og kigger på hver pixels farve.

Næste gang skal vi arbejde videre med dette . 

Ultrasonicsensor:


Vi har flyttet den ultrasoniske sensor fremad på robotten, så den nu kan se henover mobilen. Vi har lavet en simpel adfærd til robotten, når den er ved at støde ind i noget. Koden kan ses her:

package BrickSorter;
import Robot.DistanceSensor;
import Robot.LightSensorNavigator;
import Robot.Movement;
import lejos.nxt.LCD;
import lejos.nxt.Sound;
import lejos.robotics.subsumption.Behavior;
public class DetectWall implements Behavior {
private DistanceSensor ds;
private LightSensorNavigator lsn;
public DetectWall(DistanceSensor distanceSensor, LightSensorNavigator lightSensor)
{
ds = distanceSensor;
lsn = lightSensor;
}
public boolean takeControl()
{
int distance = ds.getDistance();
String sd = "" + distance;
if(distance < 100) sd = "0" + sd;
LCD.drawString("Distance: " + sd, 0, 1);
return distance < 15;
}
public void suppress()
{
//Since  this is highest priority behavior, suppress will never be called.
}
public void action()
{
int left = lsn.getLeft();
int right = lsn.getRight();
if(left > right){
Movement.drive(-40, -40);
Sound.pause(500);
Movement.drive(40, -40);
Sound.pause(500);
}
if(left < right){
Movement.drive(-40, -40);
Sound.pause(500);
Movement.drive(-40, 40);
Sound.pause(500);
}
}
}


Opførelsen tjekker om sensoren giver en værdi under 15. Hvis dette sker, overtager DetectWall og sørger for at robotten bakker væk fra væggen. Robotten tjekker hvilken lyssensor, der har den højeste værdi, så den kan bakke i den rigtige retning og vende sig ned mod afleveringszonerne.
Alt koden kan findes her http://daimi.au.dk/~u052912/Lego/end_course_uge50/


Navigering med lyssensore:

package BrickSorter;

import Robot.Claw;
import Robot.LightSensorNavigator;
import lejos.robotics.subsumption.Behavior;

public class NavigateBack implements Behavior{
 
 private LightSensorNavigator lsn;
 private boolean _suppressed = false;

 public NavigateBack(LightSensorNavigator lsn) {
  this.lsn = lsn;
 }

 @Override
 public void action() {
  int right = lsn.getRight();
  int left = lsn.getLeft();
  
  
 }

 @Override
 public void suppress() {
  _suppressed = true;// standard practice for suppress methods
  
 }

 @Override
 public boolean takeControl() {
  return true;
 }

}

Vi er langsomt begyndt på denne opførelse, men som det kan ses i koden, så er det ikke færdigt. Det vil vi se på næste gang.

Adfærdshierarki: 


Vi har nu to adfærd, DetectWall og NavigateBack, som skal sættes ind i et adfærdshierarki (subsumption achitecture [Dean3]).

Vores nederste adfærd i hierarkiet er NavigateBack som skal søge mod målzonerne, og skal altid tage kontrollen hvis den ikke bliver undertrykt af et af niveauerne over den. I dette tilfælde er det DetectWall, der tjekker om afstandsmåleren giver en værdi under 15, og tager kontrollen hvis dette er tilfældet.

Dette hierarki skal udbygges med flere adfærdsmønstre for at fuldende robotten.

Resultat for denne uge

Vi fik ombygget kloen til at bedre kunne holde på klodsen, så den ikke vælter når den bliver ført rundt på banen.
Vi fik taget billeder med mobiltelefonen fra robotten. Vi skal arbejde videre med androidkoden, da vi skal kunne tage billeder med ca. 100 ms mellemrum.
Vi fik i ultrasonicsensoren til at virke med en opførelse, så robotten nu bakker væk fra vægge, og vender sig mod målzonerne.
Afslutnngsvis begyndte vi på koden til navigering vha. lyssensorene og farverne på banen, men denne del skal vi arbejde mere med.

NXT Programming, lesson 14

Dato: 09-12-2010
Varighed: 5
Deltagere: Nick, JC


Formål:
Vi skal bygge både robotten og banen færdig. Vi skal derefter teste om robotten opfylder vores fysiske krav og om robotten kan bruge farverne på banen til at orienterer sig. Vi skal yderligere teste om mobiltelefonens billeder er skarpe selv når robotten bevæger sig.


Plan:
-Ombygning af robotten.
-Lime den udprintet bane på en solid plade.
-Teste om mobiltelefonen sidder fast.
-Tjekke skarphed af billeder.
-Teste robottens evne til at finde rundt kun via farverne på banen.


Forventet resultat:
Robotten skal bygges helt færdig, banen limes og er klar til test, teste skarpheden af billederne taget fra robotten og teste lyssensorenes evne til at navigere på banen.


Montering af mobiltelefonen:
Vi byggede en meget simpel struktur til at holde mobiltelefonen. Billederne kan ses her under:

På billeder nr. 3 kan det ses at kameraet sidder i bunden og derved tættest på kløerne. Vi skal nu teste hvad kameraet kan se når kløerne er åbnede og lukkede og om skarpheden af billedet er tilstrækkeligt til vores formål. Vi skal også teste om kameraet sidder ordenligt fast, når robotten bevæger sig hurtigt.



Banen


Vi skar kanterne af de udprintede dele af banen, og limede dem fast på en spånplade. Her er det færdige resultat. 

Vi skal teste om klodsen vælter, når den bliver flyttet hen over limningerne mellem papirene. Hvis dette er tilfældet så vil vi prøve at bruge tape på samlingerne og derved gøre dem mere glatte.

Navigering via lyssensorerne

Vi har lavet et meget simpelt testprogram, som beskrevet sidst, prøver at udligne værdierne mellem de to sensorer. Herunder er resultatet af dette program på den nuværende bane:

 

Med dette simple program er det mulig for robotten at finde vej fra den ene ende af banen. Vi skal nu lave flere opførelser der kan tage over når robotten kommer til farvecirklerne og målzonerne.


Kamerastabilitet


Vi testede om robotten stadig er stabil efter kameraet er blevet monteret og om kameraet sidder ordentligt fast. Dette blev gjort ved at robotten drejede om sig selv, først den ene vej og så den anden, og derefter kørte frem og tilbage hurtigere og hurtigere for at se om den tiltede. Mobilen blev ustabil ved omkring 80% af motorernes ydeevne. Vi skal derfor ikke køre for hurtigt og bremse for hårdt i det endelige projekt.
Video af testen kan ses her:

Udvikling af software til mobiltelefonen

Udviklingen af et stykke software til Google Nexus One telefonen er ikke gået så hurtigt som planlagt, og derfor har vi ikke nået at teste hvordan robottens bevægelser påvirker billedernes skarphed -- dette vil dog blive testet næste gang.

Planen er at telefonen skal virke som en sensor og blot sende data videre til robotten, hvorefter denne forholder sig til disse data og hvordan der skal reageres på disse. Softwaren på telefonen vil virke ved at den måler mængden af farve i billedet og dermed kan den sende denne værdi til robotten som en indikator på hvor tæt den er på en klods. Yderligere skal mobiltelefonen kunne bruges til at estimere hvilken retning en klods befinder i ved at se hvilken side af billedet der er mest af en given farve i.

Resultat for i dag

Der er foretaget en ombygning af robotten, så den kan holde en mobiltelefon. Det er blevet testet at mobilen sidder tilstrækkeligt godt fast, ved en simpel test. Yderligere er banen limet fast og der er foretaget nogle små tests.

Mobiltelefonapplikationen er endnu ikke færdigudviklet og er dermed ikke blevet testet.

NXT Programming, lesson 13

Dato: 08-12-2010
Varighed: 5
Deltagere: Nick, JC
Formål:
Dagen i dag vil gå med at teste hvorvidt robotten kan benytte banen. Yderligere vil de førnævnte ombygninger af robotten vil blive udført.
Plan:
-Ombygning af robotten.
-Printning af banen.
-Robot test.
Forventet resultat:
Robotten skal bygges færdig, banen printes, robotten testes.
Banen
Den valgte bane er blevet udprintet i A0 format, dvs. 4 gange 4 A4 sider:

Til at sprede billedet ud på flere A4 sider er brugt følgende program: http://www.blockposters.com/. Bemærk banen er ikke limet sammen, dette gøres næste gang.
Robotten:
Som nævnt i tidligere labrapporter, så skulle robottens ændres, da den var bygget efter en model fundet på nettet, der ikke opfyldte vore krav til fulde (se forklaringer af ændringer nedenfor).
Billeder af robotten efter ombygningen:

Trykføleren der var i fronten er fjernet, da vi satser på at kunne bruge mobiltelefonens kamera til at se om der er en brik i kløerne. Holderen til mobilen er ikke bygget endnu, da vi ikke har mobilen. Den bliver hentet senere i dag.

Fangarmene er blevet kortere for at gøre robotten mindre, og derved gøre det muligt at vende på et mindre område.

Lige nu er der fastgjort en lyssensor i den venstre front og en magen til skulle gerne monteres så snart vi får fat  i den ene klods vi mangler. Dette skulle gerne ske i morgen.

Så sammenlagt er robotten blevet kortere, fået to lyssensorer og mangler en mobiltelefon til at kunne "se".

Lyssensor navigation

Lyssensortesten foretages ved hjælp af den ovenfornævnte bane. Først foretages nogle stikprøver for at se om værdierne falder jo tættere robotten er på den grønne eller den røde zone. Det observeres at de to lys sensorer i tilfælde hvor værdierne burde være næsten ens, altid er cirka 5 fra hinanden (normaliseret værdi i procent), hvilket konstateres til at være en sensorunøjagtighed. Denne unøjagtighed løses ved at ligge en konstant på 5 til en af sensorernes værdier, hvilket resulterer i at lyssensorværdierne er ens, eller stort set ens, når robotten er på vej mod den grønne eller røde zone. Det bør bemærkes at værdierne også næsten er ens når man bevæger sig væk fra zonerne, her stiger værdierne dog, men da robotten givere mere kraft til den side der har den højeste målte værdi, vil robotten vende sig mod målzonerne af sig selv.

En endelig test for i dag var hvorvidt det var muligt at lave en simpel algoritme som kan finde frem til zonerne:

if(lightNav.getLeft() < lightNav.getRight()) {

   Car.forward(0, 40);

} else {

   Car.forward(40, 0);

}

Thread.sleep(100);

Denne algoritme kigger blot på hvorvidt venstre lyssensor har en mindre værdi end den højre lys sensor, og giver derefter højre motor 40% kraft mens venstre får 0% kraft, eller omvendt.

Denne simple algoritme løste faktisk opgaven og bevægede sig langsomt mod målzonerne.

Eksperiment med gribeklo:

Vi ville teste om gribekloen kunne gribe fat i de klodser vi forestiller os, der skal bruges i det endelige setup. Vi udvidede klassen Car til at indeholde to nye methoder, openClaw() og closeClaw():

public static void openClaw(){

   if(!clawIsOpen){

      claw.setPower(openingAndClosingPower*c);

      claw.rotate(angle);

      clawIsOpen = true;

   }

}

public static void closeClaw(){

   if(clawIsOpen){

      claw.setPower(openingAndClosingPower*c);

      claw.rotate(-angle);

      clawIsOpen = false;

   }

}

Metoderne sætter hastighed på klo-motoren til 50% og henholdsvis åbner eller lukker, ved at rotere 85 grader den ene eller anden vej.

Der bliver tjekket for om kloen er åben eller lukket i forvejen, for ikke at risikere at vi åbner to gange efter hinanden og derved kan ødelægge robotten.

Video af testen:

Kloen får fat i klodsen og åbner fuldt op igen. 

Vi ville også teste at at kloen kan holde godt nok fast til at robotten kan køre med den og dreje med den uden at klodsen vælter.

Videoer af testen:

På forskellige underlag kan vi risikere at klodsen vælter, og vi bliver derfor nødt til at teste med den endelige bane næste gang, for at være sikker på at selve designet af kloen ikke skal laves om. Vi har dog idéer til ændringer, hvor vi har to "fingre" på den ene siden og kloen kan derfor måske holde bedre på klodsen.

Vi har altså en virkende klo, der dog kan have problemer ved visse underlag, så der skal flere eksperimenter til for at være sikre på at klodsen ikke vælter når robotten drejer.

Resultat for i dag:

Vi fik printet banen ud, modificeret robotten til at bedre kunne opfylde vores krav, lavet test med den nye klo og testet lyssensorene på banen. Vi skal i morgen se på at få monteret mobiltelefonen og testet yderligere på banen med lyssensorerne og lave flere tests med kloen.

NXT Programming, lesson 12

Dato: 2-12-2010
Varighed: 6
Deltagere: Nick, JC

Formål:
Vi vil i dag lave et design til banen, med gradierende farver, som kan hjælpe robot 1 med at finde vej til afleveringspunkterne. Vi vil også finde et design til robotten, der kan opfylde vores krav til robot 1.

Plan:
Nick vil prøve at tegne banen i tegneprogrammet Gimp. Grundidé for banen kan ses i lesson 11.
JC vil se om han kan finde et design på nettet til en robot, der kan modificeres til vores formål og krav.

Forventet resultat:
Vi forventer at have en tegning af banen klar der kan printes ud og limes på evt et stort stykke pap, så vi har en permanent bane.

Vi forventer også at have en færdig robot, med alle sensorerne vi skal bruge og en mobil som skal virke som "øjne" for robotten.

Robotten:
Vi søgte efter en robot med gribearme og fandt denne.

Den har både lyssensor til at aflæse underlagets farve, ultralydssensor til at undgå objekter, gribearm der burde kunne gribe fat i de klodser vi har forestillet os og tryksensor.


Dog skal denne robot modificeres en del. Vi skal lave plads til en mobiltelefon, så denne kan bruges til at finde klodserne og hvis muligt, bruges til at indikere at vi har en klods tæt nok på til at vi kan lukke armene og derved gøre tryksensoren overflødig. Vi skal have sat en lyssensor mere på så vi kan se forskelle i farve på de to og bruge det til at navigere på banen med. Til sidst vil vi også prøve at gøre gribearmene kortere, så robotten bliver kortere og derved mere mobil.

Billeder af den umodificeret robot:

Banen:
Banen skal konstrueres på en sådan måde at robotten er i stand til ved hjælp af farve sensoren at bestemme om den kører den korrekte retning, når den har fundet en klods. Første forslag til en bane så ud som følger:

Idéen med denne bane er at robotten hele tiden vil bevæge sig mod en lysere eller mørkere farve alt afhængigt af om robotten vil aflevere en grøn eller en rød klods. Banen blev dog droppet grundet tvivl om hvorvidt lyssensoren er god nok til skelne mellem de mange forskellige nuancer.

Den endelige bane bliver den følgende:

Her er der kun en nuance i baggrunden som bliver mørkere og mørkere jo nærmere man er på målzonerne. Yderligere vil robotten kunne benytte to lyssensorer til at kunne køre mere lige ned mod målzonen, da den cirka skal se samme nuance på hver sensor.

Når robotten nærmer sig målzonen vil den møde nogle røde eller grønne cirkler som betyder den begynder at nærme sig målzonen.

Resultat:


Robotten skal modificeres til vores formål og krav. Den er en god basis at arbejde ud fra, men den mangler en del. Dette vil der blive set på i næste labsession.


Banen skal udprintes i de forskellige versioner, og forsøg skal laves på dem, for at finde den der bedst kan opfylde de krav vi har til banen. Banen skal også udprintes i fulde og sættes på noget pap, så vi kan få en permanent bane. Vægge skal måske også indføres så ultrasonicsensoren kan hjælpe med at holde robotten fra kanten af banen.