Uge 4; Balancing killer

Deltagere: Thomas, Lars og Morten.

Goal:
Målet med dagens aktivitet er, at bygge og programmere en virkende segway-lignende robot. Gennem denne aktivitet ønsker vi at opnå større erfaring med PID-controllers.

Plan:
Indledningsvis konstruerer vi robotten og uploader eksempelprogrammet sejway, herefter tester vi robotten i dens standardkonfiguration. Andel del af dagens program består af eksperimenter med de forskellige parametre i programmet, samt med en eventuel auto-kalibrering af robotten. Ekeperimenterne benytter dataloggeren til dataindsamling.

Activities:
Eksperiment 1.
Med dette eksperiment ønsker vi at undersøge, hvilken betydning den initielle kalibrering af robotten har for dennes evne til at balancere og evt. finde den optimale værdi. Eksperimentet udføres ved, at starte robotten med forskellige kalibreringer og så bringe den i en nogenlunde balancerende position, hvorefter der observeres hvorvidt robotten falder frem- eller bagover og hvor kraftig denne tendens er.

Resultater:
587 - fremover, hurtigt
527 - fremover, langsom
512 - fremover, meget langsom, mange standsninger
509 - skiftende tendens, mange standsninger
506 - bagover, langsomt
504 - bagover, langsomt
487 - bagover, hurtigt

På trods af de meget grove målinger, mener vi dog at kunne konkludere, at vores optimale kalibrering, på det anvendte underlag, ligger mellem 506 og 512. Udover det fundne resultat, giver eksperimentet anledning til at undersøge hvorfor robotten pludseligt standser og hvorvidt dette sker sker mere eller mindre hyppigt under forskellige forhold.

Eksperiment 2.
For at undersøge hvorfor robotten pludseligt standser, tilføjede vi loggerkoden til programmet og starter robotten med en kalibrering på 512. Herefter tolkes dataen for at identificere eventuelle mønstre der standser robotten.

Eksperiment 3.
For at finde en kombination af parametrene KP, KI og KD der giver den optimale balanceevne, gennemførte vi eksperimenter der testede indstillinger af de tre parametre, det skete ved at lade en parameter være variabel og de to andre faste. Til formålet tilføjede vi kode til programmet, således vi kan aflæse et tal(F)der er proportional til antal svingninger frem og tilbage pr. millisekund. Testresultaterne ses nedenunder.

KP	28	28	28	28	28	28	28	28	28	28
KI	1	1	2	3	4	5	6	7	8	9
KD	1	1	1	1	1	1	1	1	1	1
F()	53		56	48	44	50	52	56	57	52

Generelt virkede robotten meget ustabil med ovenstående settings, dog muligvis lidt mere stabil jo højere værdien var. Vi mener derudover ikke at kunne bruge svingningsmålingen til noget, idet vi er nødt støtte robotten under udførslen, hvilket givetvis har indflydelse på denne måling. Med endnu større værdier af KI(20 og 40) kunne vi dog konstatere, at tendensen til at robotten stopper bliver meget mere udpræget.

KP	28	28	28	28	28	28	28	28	28	28
KI	1	1	1	1	1	1	1	1	1	1
KD	0	5	10	15	20	25	30	35	40	45
F()	45	51	56	104	156	187	226	319	119	327

Med denne række målinger, mener vi at kunne se en tydelig forøgelse af svingningstallet. Dette giver udslag i meget mindre svingninger og hvis robotten anbringes i en fornuftig startstilling, kan den næsten balancere selv fra værdier omkring 25 og op, den bliver dog også mere og mere følsom overfor store udslag i målingerne.

KP	0	5	10	15	20	25	30	35	40	45
KI	0	1	1	1	1	1	1	1	1	1
KD	1	1	1	1	1	1	1	1	1	1
F()	310	49	41	49	51	55	56	53	56	56

Bortset fra den første måling, hvor KP er 0, giver de øgede værdier for KP anledning stil større svingninger, men til gengæld bliver den bedre til at modstå store udsving, ved f.eks. lettere skub, som med KD målingerne er robotten ved de høje værdier næsten i stand til at balancere selv.

Som forventet skal den optimale løsning findes som en kombination af de tre værdier.

Eksperiment 4.
Efter at have fået en ide om hvordan robotten opfører sig ved ændringer i parametrene, eksperimenterede vi her med at få tunet løsningen, så robotten selv kan balancere.

<-- Ved øvelsernes afslutning havde vi endnu ikke fundet en virkende løsning -->

Uge 3; Sound-Sensor-Clapping-Test-Stuff-Ting

goal:
At eksperimentere med SoundSensoren og derved få erfaring med mikrofonens muligheder og begrænsninger.

plan:
Planen er at vi skal ende op med at lave en form for lydgenkendelse, idet vi først analyserer på lydmønstret af forkellige typer af høje klap. Udfra denne dataopsamling skaber vi et billede af et gennemsnitlig klap. Mønstergenkendelsen af klappet skal så forsøges implementeres i en algoritme.

activities:

experiment 1:
Datalogning af forskellige høje lyde.

experiment 2:
I de første eksperimenter, brugte vi dataloggeren for at opsamle data og få skabt nogle lydbilleder af de forskellige typer klap. Herunder ses sammenligningen af 5 forskellige klap.
Med 'KillBot's mikrofon så et gennemsnitlig klap ud som følger: Startende med svag lydniveau på under 15. Herefter følger et skarpt peek på op til et lydniveau på over 80 varende mellem ca. 20 - 50 msek., hvorefter lydniveauet igen stille falder til et lydniveau på under ca. 60 efter en periode på 180 msek. efter peek'en.

EscapeHandling:
Istedet for hele tiden at poll for Escape pressed, har vi lavet en anonym ButtoListener. Koden kan ses herunder. Vi er lidt i tvivl om det er den kønneste løsning, men det er måske bare et spørgsmål om at fravende sig Java's kønne verden og tilvende sig en verden i embedded systemer:

    Button.ESCAPE.addButtonListener(new ButtonListener(){
            public void buttonPressed(Button b) {
                Car.stop();
                LCD.clear();
                LCD.drawString("Program stopped", 0, 0);
                LCD.refresh();
                try{
                    Thread.sleep(1000);
                } catch (Exception e){}
           
                System.exit(0);
            }
       
            public void buttonReleased(Button b) {}

        });

Test-for-clap-algoritme:
Vi skiftede metoden 'waitForLoudSound()' ud med nedenstående. Til at teste og måle tiden imellem samplingerne brugte vi 'System.currentTimeMillis()'. Først venter vi på et lydniveau på over 50, vi sampler i 25 mSek., og tester om niveauet, i en af samplingerne var over 80 (peek), sampler så igen i yderligere 250 mSek og tester om lydniveaut har været tilpas lavt. 'Lavt' er i dette tilfælde sat til at være under 50. Hvis ikke det er tilfældet starter vi forfra.:

    private static  void waitForClap() throws Exception
    {
        int soundLevel;
        boolean clap = false;
        while(!clap){
            LCD.clear();
            LCD.drawString("Step 1",0,0);
            LCD.refresh();

            do {
                soundLevel = sound.readValue();
            } while ( soundLevel < 50 );
           
            LCD.clear();
           LCD.drawString("Step 2",0,0);
           LCD.refresh();
          
           int now = (int)System.currentTimeMillis();
           int maks = 0;
           while ((int)System.currentTimeMillis() <= now+25){
               soundLevel = sound.readValue();
               maks = Math.max(maks, soundLevel);
           }
          
           if (maks > 80){
              
               LCD.clear();
               LCD.drawString("Step 3",0,0);
               LCD.refresh();
              
               now = (int)System.currentTimeMillis();
               while ((int)System.currentTimeMillis() <= now+250){
                   soundLevel = sound.readValue();
                   if (soundLevel < 50){
                       clap = true;
                       break;
                   }
               }
           }
          
        }
    }

Uge 2; Ultrasonisk sensorsjov

Goal:
Målet med dagen var at eksperimentere med den ultrasoniske sensor og derved opbygge noget erfaring og forståelse for sensorens virkemåde, muligheder og begrænsninger.

Plan:
I de første eksperimenter brugte vi programmet SonisSensorTest, som bare tager målinger fra sensoren og udprinter dem på LCD'et. - Meget lig de første eksperimenter fra lyssensoren.

De næste eksperimenter går ud på at lege med værdierne i programmet Tracker, programmet søger at flytte sensoren hen i en afstand af f.eks. 35 cm. Med den nuværende opsætning virker det som om at den bare oscilere bl.a. pga. response-tid mellem processor, sensor og motor. Her gælder det om at finde en gylden middelvej i opsætningen af variablerne i programmet.

Sidste opgave går på at lave en wallfollower udfra Philippe Hurbains fremgangsmåde og eksperimentere med forskellige kontrol-algoritmer fra forrige uges forelæsning.

Activity:
Vi uploadede programmet 'SonicSensorTest' og forsøgte os at måle afstande til forskellige objekter.

Eksperiment 1:

Vi testede hvorledes ekkoet fra den udsendte lyd fra UltraSonicSensor opførte sig overfor forskellige overflader. Dvs. først på træpladerne på siderne af testbordet i Zuse-bygningen. Et ret forventet resultat, ie. et 'veldefineret ekko'.
Vi prøvede også med en fleecejakke over kanten - for at se hvorledes det påvirkede ekkoet. Det havde faktisk stor indflydelse, idet det absorberede meget af lyden. Vi skulle ind på mellem 89 - 110 cm for at sensoren kunne opfange et ekko.



Eksperiment 2:

Ud fra plottet herunder kan man se resultatet af 2 forskellige tests med Ultrasonicsensorens viste værdier i forhold til reelt målte værdier.


I den første test målte vi ekkoet på en hård overflade, mens vi i anden test målte en overflade hvorpå vi havde lagt en trøje over.
Vi kom frem til at der er god overensstemmelse med de målte værdier i intervallet fra ca. 20 cm og opefter. Hvis vi forsøgte at måle på afstande under 20 cm begyndte der at være fejl. sensoren mente der var længere end der faktisk var.


Eksperiment 3:

Vi forsøgte også at stille objekter ret foran og skråt foran sensoren, for at teste vinklen for de udsendte lydbølger, samt hvor små objekter der kunne opfanges ekko på. F.eks var det svært at opfange en plastikkop, mens den cylinderformede kaffekande og pladen af træ var nemme at se ret foran.
Når måleobjekterne blev stillet ud i en yddervinkel i forhold til sensoren, kunne sensoren ikke længere modtage ekkoet. Eksperimentet viste en overaskende bred vinkel.


Eksperiment 4:
I dette eksperiment anvender vi programmet Tracker.java. Programmet forsøger at flytte robotten til en given afstand af en genstand, ved hjælp af den ultrasoniske sensor. Efter at have kørt det originale program(minpower=60 , gain=0,5 , samplerate=300) ser vi at robotten bevæger sig ind til den korrekte afstand, hvorefter den begynder at oscillere omkring denne afstand. Trackerprogrammet fungerer som en proportionel controller og den oscillerende opførsel er netop et kendetegn ved denne type controllere. Vi vil dog argumentere for, at der er tale om en påtaget oscillering, idet programmet faktisk ikke forsøger at stoppe robotten når den rammer den præcise afstand. Programmet giver anledning til at eksperimentere med følgende variable: minpower, gain og samplerate.

Til forsøgene har vi rettet programmet til således, at robotten skal stoppe hvis den opnår den korrekte afstand, i stedet for at skulle køre enten frem eller tilbage(med standard indstillinger).

1. forsøg (minpower=60 , gain=0,5 , samplerate=300):
Efter ændringerne i koden observerede vi væsentlig færre oscillationer, i flere tilfælde stoppede robotten endda uden synlig oscillation.


5. Eksperiment
Implementering af wallfollower. Med udgangspunkt i en hurtig og forsimplet oversættelse af programmet og kørsel af dette, kan vi konkludere at det fungerer nogenlunde acceptabelt. Standardudgaven fungerer som en bang-bang controller, som dog til forskel fra en typisk implementering kan vælge mellem 6 forskellige muligheder.

Teksten beskriver henholdsvis en "gentle turning" algoritme og en "three state" algoritme. Gentle turning gør generelt at robotten performer bedre, idet begge hjul drejer hele tiden hvilket igen, som navnet antyder, giver en roligere og mere fremadrettet opførsel. Vi implementerede en lignende algoritme for lyssensoren og det gav samme resultat. Vi har ikke store erfaringer med 3-state algoritmen, men i modsætning til de to andre, giver 3-state ikke noget der ligner harmoniske svingninger, men performancemæssigt er den sammenlignelig med den simple wallfollower.

Eksperiment med sampletime

For at undersøge betydningen af sampletime, det vil sige det tidsrum der går mellem lyssensoren måler lysstyrken, har vi ladet vores robot gennemløbe banen med en sampletime på henholdsvis 15, 30, 60, 120, 240. Gennemløbene resulterede i følgende tider:

Sampletime	15	30	60	120	240
Gennemløbstid	1.25	1.29	1.27	1.32	fejler

Vi mener at kunne se en generel forøgelse af gennemførselstiden, når vi sætter sampletime op, dette betyder også at vi er nødt til at se målingen for sampletime = 30 som en tilfældighed, eventuelt på grund af unøjagtighed i tidsmålingen og eventuelle forskelle i startplaceringen.

front modifikation

Udbygning af fronten giver større udsving. Påvirkning fra moteren registreres hurtigere, medfølgende sine pros et cons...

Modifikationer

Under gennemførelsen af denne uges eksperimenter, fandt vi det interessant at modificere vores robot. Ændringen består i at vi har sat lyssensoreren længere frem. Dette gør, at vi opdager sving tidligere, så vi kan køre hurtigere igennem dem.

Desuden har vi modificeret programmet således at der ikke kun er et hjul der kører ad gangen. De kører begge hele tiden, det ene bare lidt hurtigere end det andet.

De to ændringer tilsammen gør robotten betydeligt hurtigere.

Det ser faktisk ud som om den vinder...

Eksperiment med og uden lyssensorens diode

Som foreslået i opgave teksten, har vi ved hjælp af lyssensoren målt lysstyrken over materiale med forskellig farve(sort,hvid, brun, lys blå og mørk blå). Vi udførte målingerne både med og uden lyssensorens diode tændt og kom frem til følgende data:

		m/diode i alm. lys	m/diode i skygge	u/diode i alm. lys	u/diode i skygge
Sort		33	31	24	19
Hvid		53	51	42	31
Brun		46	44	33	27
Lys blå		41	n/a	35	n/a
Mørk blå		33	n/a	23	n/a

Udfra de indsamlede data, er det muligt at se visse sammenhænge. Ikke overraskende, er det generelle lys niveau væsentligt lavere når man deaktiverer sensorens diode, mere overraskende er det dog, at udslaget i lysstyrke mellem almindelig belysning og skygge forøges meget, ved denne ændring. Målingen af hvid giver for eksempel et udslag på 11 enheder, når man skifter mellem almindelig belysning og skygge. Målingerne viser os også, at det er muligt at bytte den sorte linie ud med en linie af anden farve, for eksempel ville en mørk blå farve opnå det samme resultat og med en fornuftig threshold-indstilling ville det også at bruge både den lyseblå og brune.
Tilgengæld viser det store udslag på den hvide farve, at vi, udfra disse målinger, ikke vil være i stand til at vælge en thresholdværdi således, at bilen kan følge linien både med og uden dioden aktiveret og både i almindelig belysning og skygge.
Grundet en ombygning af vores køretøj, se billede nedenunder, kom dette i karambolage med den brune tape omkring banen, under vores forsøg med dioden deaktiveret. Dette udslag skyldes en tresholdværdi på 35, som gør at vi er i stand til at se forskel på sort og hvid, men ikke på sort og brun.















(Dette eksperiment kan være påvirket af belysningen i rummet og de forskellige skyggeniveauer.)

Uge 1; Opstart og lyssensor

Goal:
Målet med disse første øvelser er, igennem eksperimenter, at lære nxj-væsenet bedre at kende. At finde ud af hvorledes kommunikationen foregår, både mellem pc og nxj, men også mellem indre og ydre enheder internt på nxj'en.

Plan:
Planen er at vi laver nogle eksperimenter for at teste hvilken indflydelse små ændringer på fx. samplerate, motorhastighed, grænseværdier for lyset m.fl. har på fx oscillation og hastighed for gennemførsel af banen.

Activity:
Der gik en del tid med at få sat nxj-systemet op på computeren.
Efter download af lejos_nxj06 filerne fik vi, efter lidt søgen, også fundet usb- og bluetooth-driver, sat systemvariablen NXJ_HOME og tilføjet lejos_nxj/bin/ til PATH.
Vi fandt ud af, at man skal være root for at bruge nxj_programmerne (kan sikkert sættes bedre op).

NXJ'en er af de forrige 'ejere' blevet navngivet killerrobot. Det er vi fortsat med, men det kan dog godt være, vi alligevel skal have fundet ud af at lave det om. Vi har nemlig endnu ikke opnået bluetooth-kontakt imellem PC og NXJ.

Ved hjælp af USB-ledning fik vi flash'et lejos-firmware på NXJ.
Det første program vi uploadede var SoundSample, men der fik vi kastet en exception efter os - 'oh no, nu har vi fået nxj-klodsen der er defekt' tænkte nogen, men det viste sig at det bare var os der var defekte, fordi vi ikke havde sat sensorer på de porte der var meningen i programmet ;)

Alt imens nogle brugte lidt tid på at få softwaren til at virke, brugte andre tid på at bygge legorobotten.