ESEA Gruppe X's hjemmeside i ESEA

Kodeudvikling.

De mest betydningsfulde ændringer fra gammel til ny kode beskrives i det følgende ganske kort.

• Opdeling i flere filer
• Den oprindelige kode bestod af én stor uoverskuelig fil med alle mulige deklarationer og definitioner i et stort virvar.
  I den reviderede version er der lavet en logisk opdeling af koden i flere forskellige filer. I alt er der fem C-filer med tilhørende deklarationsfiler (header filer). Dette har givet en langt mere overskuelig kode, men har først og fremmest gjort koden langt lettere at vedligeholde og udvide.
• Opdeling af strukturer (structs)
• Den originale kode indeholdte en forholdsvis stor struktur (Sample), der indeholdte information der dækkede to begreber (Sample og Pattern) og kunne helt naturligt opdeles i hver deres struktur. Det gamle begreb (Sample) dækkede således både sensorer og motorernes tilstand samt måden, der skulle reageres i tilfælde af ”sample clicking”.
• I den nye kode er en ”Sample” blot et stillbillede af tilstanden af input og output på RCX’en (output fortolket til tilstand på motor). Et ”Pattern” er et nyt begreb i den reviderede version der så kombinerer en Sample og en reaktion (Behaviour) på en naturlig måde.
• Generelle forbedringer og større grad af konsistens
• I den nye kode er der, for at opnå bedre konsistens i koden, lavet op til flere ændringer af variabel- og funktionsnavne samt deres typer. Enkelte variabler og funktioner er blevet overflødige og findes således ikke længere.
• Der er desuden lavet mindre forbedringer af koden, både udseendemæssigt og enkelte steder i minimal grad størrelses- og ydelsesmæssigt.

Beskrivelse af koden.

Koden er delt op i fem forskellige C-filer med tilhørende header-filer.

LearningLegoCar er den vigtigste og indeholder hele fundamentet for hele styringsalgoritmen.

De øvrige filer er en slags hjælpefiler hvori der er uddelegeret funktionalitet der logisk set adskiller sig fra det øvrige program.

Sample- og pattern-filerne består af definitionen af henholdsvis sample- og pattern-datatyperne og funktioner til oprettelse og kopiering.

SampleStack indeholder funktioner til at holde styr på og håndtere de samples der løbende indsamles af robotten.

Sidst og mindst er der en tool-fil, der indeholder alt det der passer ind over det hele uden rigtigt at høre til noget specielt sted. I skrivende stund indeholder filen blot en enkelt funktion, Abs, der udregner den absolutte værdi af et heltal.

Project Log Entry 1

• Et "sample" er en liste af sensor-værdier, både input og output værdier. De repræsenterer robottens omgivelser og tilstand i et givet øjeblik.
• "Kritiske sensorer" er de sensorer der trigger/udløser en refleks, dvs. "smerte"-sensorerne.
• En "criticalEvent" er når robotten er i en kollision eller udenfor en linie mm. Det er også situationer, som robotten har den ikke har mulighed for at komme ud af, med dens udvalg af reaktioner.
• Et "Warning-sample" er et sample der kommer lige før vi har oplevet en critical-event. Det beskriver altså at vi er tæt på at opleve en situation, som vi ikke ønsker at opleve.
• Et "pattern" er en sample som bruges til at prøve at undgå en kritisk situation, dvs. en succes indtil andet er bevist. Hvis det ikke er muligt at undgå en kritisk sensor, bliver et pattern "udnævnt" til at være kritisk. Værdierne i dette sample er tæt på et sæt værdier, registreret ved en critical-event. Alle warning-samples bliver til patterns og patterns bliver så, afhængigt af om de er i stand til at undgå den kritiske situation, markeret som værende kritiske patterns (og dermed en criticalEvent) eller patterns der reagerer. Et pattern bruges til at identificere situationer som leder til kritiske tilstande. Til et pattern er tilknyttet et reaktionsmønster eller opførsel (behaviour), der skal udføres for at undgå at havne i den kritiske situation. I tilfælde af at den kritiske tilstand ikke kan undgås, noteres det pågældende pattern til at være en kritisk situation i sig selv.
• At et pattern "klikker" vil sige at 2 sæt sample-værdier, er sammenlignet og fundet matchende ud fra nogle opstillede kriterier. Disse kriterier er et af de komplekse problemer vi står overfor når vi skal lære robotten op.

Fig. 1: Sample-historik. En liste af tilstands-snapshots der går tilbage i tid.

Der oprettes et sample i hver iteration af loop'et, og der gemmes hele tiden en historik over de x foregående samples. Se Fig. 1
Når robotten får trykket sine kritiske sensorer ind, rejses en criticalEvent. Når der sker en criticalEvent, så registreres det sample i nuværende itteration – 1. Dvs. vi registrerer det sample til den tid der kom lige før den kritiske oplevelse i den holdte historik. Dette er et warning-sample. Næste gang der vi oplever et sample der matcher en warning-sample, forsøges der med en reaktion for at undgå at komme i en criticalEvent. Den pågældende warning-sample indeholder information om hvilke reaktioner der er forsøgt til at undgå at komme i en kritisk tilstand. Hvis ingen reaktioner på et warning-sample undgår critical event, så markeres dette warning-sample som critical og denne værdi vil efterfølgende betragtes som en critical-event, da den i praksis svarer til en kollision, da den ikke kan undgås vha. de indbyggede reaktioner. Næste gang robotten så kommer i denne tilstand, gemmes et nyt warning-sample til tiden lige før dette, altså igen den forrige entry i historikken. På denne måde skulle robotten gerne ende med at lære at undgå critical-events i tide. Hvis vi efter at have mødt et warning-sample forsøger os med en reaktion, og vi ud fra et endnu ikke præcist defineret succes-kriterium, ikke ender i en critical-event, gemmes dette warning-sample som et pattern dvs. en situation som robotten nu har lært at genkende, og har knyttet en succesfuld undgåelsesadfærd til. Når et pattern efterfølgende klikker, vil den tilknyttede reaktion/adfærd blive udført.

Teori:
Vores løsning er i første omgang baseret på egne idéer mht.
læringsmekanismen, som er det centrale i projektet. Prioriteringsmekanismer, adfærdsstyring og kontrol-strategier er inspireret af stoffet fra kurset mht. disse
ting. Dette vil blive uddybet i næste labsession, hvor vi forventer at have arkitekturen på plads.

Figur 2

Figur2 beskriver vores indlæringsmekanisme meget abstrakt. Princippet er baseret på at genkende. Enten er en genkendelse, en genkendelse af en kritisk situation/hændelse eller også er det en genkendelse der medfører en handling. Afhængigt af hvad der bliver genkendt uddrages forskellig læring/erfaring. Denne nye læring/erfaring indgår nu i det genkendelige. Figuren er bevidst lavet meget abstrakt, så den giver mulighed for at tænke over andre måder at opnå indlæring på, end den implementation vi har valgt at realisere og derudover ikke begrænser tankegangen. Fx hvordan lærer man af en handling? Lærer man positivt, negativt eller en blanding? Dvs. vurderer man sine handlinger som værende en succes, ved at der kommer noget godt ud af dem, at der ikke kommer dårligt ud af dem eller en blanding.

Mål med projektet:
Projektet forventes at have en høj usikkerhed mht. de resultater vi gerne vil opnå. Ingen af os har erfaring med lærings-teorier, neurale netværk mm.
Vi håber på at kunne lære robotten forskellige opgaver, såsom follow-wall, obstacle avoidance og follow-line, udelukkende ved at andre på dens grund-reaktioner, og dens smerte-tilstand. Mht. obstacle avoidance skulle den gerne kunne lære dette unsupervised, og mht. follow-line forestiller vi os at vi kan lære den det supervised, altså ved at vi hver gang den kommer udenfor linien, kan sige "fy" ved at give den et tryk på dens smerte-sensorer. Målet for projektet bliver dermed at give robotten følgende egenskaber:

• At være uafhængig af sensorers placering.
• At være uafhængig af antal sensorer.
• At være uafhængig af sensor-typer.
• At være uafhængig af hvilke porte forskellige sensorer er tilknyttet.
• At kunne lære at genkende ugunstige situationer vha. smerte-princippet.
• At kunne lære at benytte prædefinerede reaktioner og kombinationer at disse til at undgå ugunstige situationer.
• Vha. ovenstående egenskaber at blive i stand til at lære at løse forskellige opgaver, udelukkende ved at ændre robottens grundreaktioner, og smerte-definition.

Project Log Entry 2

Mål: Der var flere formål med dagens møde. For det første skulle en kodestruktur (beskrevet i pseudokode) skitseres, så der blev skabt et fælles overblik over hvordan læringsprocessen for vores Lego-bil, skal implementeres. For det andet skulle en løs milestone-plan vedtages. Efter disse første to ting kom på plads, påbegyndtes kodning.

1. Hvor tit skal vi oprette samples?
2. Hvor mange patterns har den mon brug for at lære, og har vi overhovedet plads til det i RCX'en?
3. Hvordan sammenligner man et sample med et pattern? Hvad er kriterierne for et klik?
4. Hvilke reaktioner skal den udstyres med, og hvordan skal den udvælge disse?
5. Hvordan skal robotten konkludere om en reaktion er en succes?
6. Virker ideen mon overhovedet?

Simple Pattern Matching (pkt. 3)
Dette en central del af systemet. Vi har besluttet os for at starte med en simpel model, og lave en sammenligning kun på lyssensor-værdier, og bruge et offset a la +-10, og dermed sige klik, hvis værdierne ligger indenfor intervallerne defineret via dette offset. Alle tidligere patterns bliver løbet igennem under hvert gennemløb. Hvis der er et klik på et tidlige pattern skal der så laves en reaktion på det. Det næste der så skal kigges på er om vi nåede at klikke tidligt nok på det genkendte pattern. Dette gøres ved at undersøge om de kritiske sensorer er blevet aktiveret. Hvis det er tilfældet skal der oprettes et nyt pattern fra samplingen før og tilføjer den til listen.

React mekanisme (pkt. 4)
Vi vil ud over at afstemme hvornår der skal reageres på input værdier fra lys sensorer også lave en mekanisme der skal udvælge det mest succesfulde reaktionsmønster, når en forhindring skal undgås. Denne react mekanisme skal gå ind og afprøve forskellige handlinger når et pattern udløser at den skal reagere. Vi har tænkt os at definere en liste med reaktioner, som robotten prøver igennem. Dvs. at den første gang den klikker på et warning-sample, prøver første reaktion i listen, og hvis dette ikke medfører succes, vil den hvis den en anden gang klikker på dette warning-sample prøve den næste reaktion i listen. Vi tænker på at lave listen, på en sådan måde at den kan løbes igennem flere gange, men hver gang med f.eks. et drej i en retning i lidt længere tid end forrige gang. På denne måde skulle den gerne lære kun at dreje det der er nødvendigt, og ikke bare ende med at vende 180 grader hver gang den møder en forhindring. Hvis man forestiller sig at robotten udstyres med et mål, det kunne være at køre efter en lyskilde, vil denne fremgangsmåde forhåbentligt sikre at robotten tager den korteste vej mod lyset. Så kan man sige at listen med reaktioner skal løbes igennem 4 gange med forskellige tider på drejet, før man konkluderer at der ikke var nogen reaktioner der gav et gunstigt resultat.

React success (pkt. 5)
For at en givet reaktion kan klassificeres som en success, har vi besluttet at der skal gå et stykke tid efter reaktionen er udført, hvor robotten kører ligeud, uden at støde ind i noget, så hvis den i de efterfølgende x millisekunder rammer en critical-event, vil reaktionen bliver klassificeret som ugunstig, og ellers som gunstig.


Pga. usikkerheden mht. hele ideen, var vi enige om at vi skulle hurtigt i gang med at lave en grund-implementation, så vi kunne afprøve konceptet. Det virker umiddelbart ret enkelt, at lave en grundstruktur, der let kan udvides med mere avancerede overbygninger.

Pseudo kode
I den første omgang pseudokode, forsøgtes kontrolstrukturen/arkitekturen at blive lagt fast.


Der er mange ting der mangler I ovenstående pseudokode. Koden skal kun læses som en meget forenklet udgave af learningalgoritmen, der (forhåbentligt) giver et overblik over princippet. Herunder følger en lidt mere opdateret udgave af learning algoritmen, hvor de forskellige samples’ reaktioner bliver testet, for at afgøre om en sample er kritisk eller ej.
Main er stadig den samme.



Der er brugt flere metoder i ovenstående kode, de vil blive beskrevet herunder. Dog er det kun formålet med metoderne og en meget enkel implementation af dem der vil blive beskrevet. Dette skyldes at der indenfor rammerne af ovenstående struktur, gennem metoderne, er forskellige måder at udvikle learning-elementerne på.

1. GetCurrentSample()
   Opdaterer den sample som bruges til sammenligninger. Dvs. metoden opdaterer øjebliksbilledet.
   
2. React(Sample pSample)
   pSample ”afprøver” en reaktion, i den nuværende implementation skifter React bare retning. (Frem og tilbage)
   
3. ReactOnCriticalEvent()
   I den nuværende implementation skifter ReactOnCriticalEvent() bare retning.(Frem og tilbage)
   
4. 4. FindTheBestFittingSample()
   Sammenligner alle lærte samples med currentSample og returnerer den der ”ligner mest”.
   
5. ReactionUpdate()
   Opdaterer en reaktion hvis en sådan er i gang.
   

Tidsplan.
For at vi ikke mister overblikket over hvad vi vil nå at lave på projektet har vi opstillet en simpel tidsplan. Det første vi vil ha på plads er en overordnet struktur af designet. Efterfølgende vil vi så udvikle på matching(klik)-mekanismer og react-mekanismer, hvor vi så endeligt kan afprøve vores løsningsmodel.

Arkitektur
Vi har i vores design af programmet, ikke brugt tråde. Det kunne være relevant at have dele af koden, såsom CriticalSensorTriggered, og sample-matching mekanismen i tråde for sig, da de kan ses som selvstændige processer, der kan informere andre dele af systemet, om deres resultater. Det ville til reducere kompleksiteten i den konceptuelle logik, og give en sund adskillelse af disse funktionaliteter i koden. Vi mener dog ikke at det skulle være noget problem at konstruere systemet uden tråde, og da der ofte kan følge bøvl med tråde i form at synkroniseringsproblemer, race-conditions mm., har vi derfor valgt ikke at bruge tråde i håbet om at spare tid. Dette forenkler projektet, der i forvejen har en stor usikkerhed.

Vores projekt bygger på at knytte situations-betingelser til reaktioner. Vores overordnede tilgang kan derfor ses som en "purely reactive" kontrol-strategi, som beskrevet i [1,3], men med dynamiske definitioner af condition-action pairs, defineret gennem vore lærings-algoritme. Maja karakteriserer i [1] den rent reaktive kontrol-strategi således: "Purely reactive strategies have proven effective for a variety of problems that can be completely specified at designtime. However, such strategies are inflexible at runtime, due to their inability to store information dynamically."
Vores erfaring med en ren reaktiv strategi står i modsætning til [1], i det vi netop mener at kunne lave en fornuftig kombination af den rene reaktive strategi med dynamisk opbygning af condition-action pairs. Vi definerer ikke på design-time en fast binding mellem conditions og actions, og vi opnår en dynamisk udvikling af disse bindinger på run-time. Ingen af de nævnte begrænsninger er dermed noget vi oplever i vores strategi, der eller må betegnes som en ren reaktiv strategi - en erfaring der ligeledes er gjort af [2].

Herudover bygger princippet i vores arkitektur på traditionel Sense-Plan-Act, hvor Plan måske burde hedde Learn, da der netop ikke er implementeret en planlægningsstrategi, men kun et udgangspunkt for selv-udvikling.
Proportional control er når kontrol-algoritmen reagerer proportionalt med en fejl-værdi, det kunne være en afstand til en væg for eksempel. Vi har forsøgt at modellere proportional control, som beskrevet i Martin [3], ved i vores læringsalgoritme at lade robotten afprøve reaktioner inkrementelt, hvor reaktionerne hver gang bliver lidt længere. På den måde håber vi på at opnå at det robotten lærer, er at knytte proportionale reaktioner til de situationer hvor det er passende, dvs. at den eksempelvis kun laver små drej, hvor dette er nok, og store drej, hvor små drej ikke er nok.

Mht. hvordan de forskellige behaviors prioriteres har vi valgt følgende enkle fremgangsmåde. For de overordnede adfærdsmoduler, wander og react-to-some-known-situation, har vi fast definerede prioriteter med sidstnævnte som havende højeste prioritet. Sidstnævnte adfærd initieres af robottens selv-lærte evne til at genkende ugunstige situationer. Som vi har implementeret det, vil robotten ikke forsøge at genkende situationer mens den er ved at afprøve en reaktion, men vil dog reagere på at dens kritiske sensorer aktiveres, hvorved den igangværende reaktion termineres, og den nye kritiske situation bliver udgangspunkt for dens videre udvikling. Problemet med at lade robotten genkende ugunstige situationer mens den er ved at afprøve en reaktion, er at det gør det komplekst at definere hvornår en reaktion så er en succes, da reaktionen så får en binding til andre lærte situationer, som kan være sunde, men også kan være usunde, da robotten jo kan lære dårlige vaner.
Flere patterns kan klikke ved et gennemløb, men hvert klik tildeles en match-værdi, hvor vi kun bruger det bedst matchende. Dette definerer en prioriterings-strategi mht. hvilke reaktioner der får lov at blive udført.

Vi har derudover givet mulighed for at lave suppression, som beskrevet i subsumption arkitekturen af Brooks [4]. Dette er gjort på samme måde som vi gjorde i Lab Session 6. Dvs. at man kan smide ordrer ud til motorerne, men de bliver først realiseret når Actuate()-metoden bliver kaldt, og med de først indkomne med lavest prioritet, og de sidste med højeste.

Sample-oprettelse og sample-sammenligning
Når vi sammenligner patterns vil der kunne være flere der klikker, og vi tildeler en match-værdi til de patterns der klikker, og tager kun det bedst matchende. Herved undertrykker vi de andre mulige reaktioner på denne situation. I forbindelse med dette kunne man overveje at bruge en subsumption arkitektur som beskrevet i [4]. Ideen kunne så være at lave hvert adfærdsmodul have specifikke reaktioner, og lade dem hver især have en match-metode, der bygger på den pågældende adfærds karakteristika. En adfærd kunne f.eks. være uinteresseret i motorernes tilstand, og en anden kunne være ligeglad med lyssensor-værdier, men de kunne alle reagere samtidigt, og så lade output være styret af en suppression-mekanisme. Dette var en overvejelse, men i og med at vi blev enige om at afprøvelsen af reaktioner i en ugunstig situation skulle ske sekventielt, var ideen om parallelismen i [4] ikke relevant.

Den specifikke løsning til at tilføje inputsamples udpeger den umiddelbart forrige sample som værende indikator for en begivenhed der kræver en eller anden form for reaktion. Dette medfører en meget lang indlæringstid afhængig af hvor ofte der samples. En mere generel oprettelse af samples tager højde for flere af de tidligere samples end blot den forrige. Dette vil medføre en hurtigere indlæringstid og øget resistens overfor støj på inputsensorerne (fx: Undskyld tjener, der er en flue i min sensor). Man kan ikke sige noget generelt om hvor mange samples man bør overveje da forskellige sensorers optimale samplerate og variation af inputværdier er afhængig af deres natur og beskaffenhed. En generel løsning til udvælgelsen af antallet af samples kunne være at se på samples over tid. F.eks kunne man lade et gennemsnit eller lignende af inputværdierne fra de sidste 2 sekunder udgøre en sample.

Samplesammenligning er nødvendig for at opdage hvornår der er behov for en reaktion. Måden man sammenligner samples på er tæt knyttet til måden samples oprettes på. Igen er der en simpel men specifik måde at sammenligne samples på. Man udvælger én fast værdi, der afgør hvor meget de enkelte værdier i de pågældende samples må afvige for at være ”ens”. Den lidt mere generelle løsning er en værdi for hver eneste inputværdi, ikke bare en enkelt for alle inputværdierne. Dette er en simpel og åbenlys udvidelse da variation af forskellige sensorers værdier som nævnt er afhængig af de enkeltes sensorers natur. Det vil således være nærliggende at udvælge en passende variationsværdi til de enkelte sensorer baseret på måden man opretter samples på.

Videre overvejelser til forbedringer:
En alternativ måde at sammenligne samples på kunne være at tildele enhver sammenligning en værdi mellem 0 og 100. Jo mere to samples ligner hinanden jo tættere kommer en sammenligning på 100. Derudover kunne det tænkes at man kunne tildele de forskellige sensorer forskellig betydning. Dvs en ens variation på forskellige sensorer ikke nødvendigvis har samme udslag i værdien af sammenligningen. Metoden giver en meget fleksibel måde at sammenligne samples på og dermed mulighed for et bedre input til de algoritmer der afgør systemets reaktion.
Fx kunne man forestille sig at en sensor har haft en min værdi på x og en maksværdi på y og at man ønskede sig at dens værdier var delt op i 30 områder. Man ville derved kunne lave en dynamisk relaxation på (y – x) / 30. Udover det ville man kunne teste hvor ofte de forskellige ”relaxationområder” blev brugt og indsnævre deres værdier. Man ville derved opnå en mere præcis CompareTo-funktion. (Da de områder hvor der er mulighed for en lille relaxation, bliver udnyttet/delt op)

Implementation
De centrale elementer vi har valgt at lægge ud med at implementere her ved den første gang er opbygning af patterns. Genkendelsesmekanismen til at behandle de patterns der er gemt i en simpel udgave, hvor opbyggelsen sker i vores update metode. Da det er en del information der skal gemmes anvendes der structs, som så gemmes i et array. De informationer det drejes sig om er inputværdier fra sensorerne, samt information om hvilken retning og fart bilen er kørt er kørt med da den kritiske handling skete. Desuden gemmes der også information om succesraten og hvilken handling der skal foretages bagefter.

Update metoden fungerer på den måde hver gang den kaldes løbes alle de tidligere patterns igennem. Hvis der findes et hit hvor både lys sensor værdier og kørselsretning er ens (eller er ”tæt” på at være ens) kigges der på hvor succesfuldt dette pattern er. Hver gang der er en genkendelse og dens handling forsøges udført holdes der så styr på hvor mange gange det er lykkes at gennemføre handlingen. Hvis der findes et pattern med bedre succesrate vælges dette i stedet for. Nu udføres så handlingen der er gemt for det fundne mønster ved at der laves et kald til react metoden. Hvis det er at der ikke er noget match kigges der på om den kritiske sensor er blevet aktiveret. Hvis det er tilfældet skal der oprettes et nyt mønster og så laves et retningsskift af bilen.

Da vi havde brugt en del tid til at diskutere en pseudoløsning nåede vi ikke at færdiggøre implementeringen af den overordnede kodestruktur ved denne labsession.

Project Log Entry 3

Mål:
At færdiggøre koden til den overordnede struktur.

Implementering:
De sidste ting der skulle til for at lave en simpel kørende løsning er ved denne labsession blevet færdiggjort. Det var små ændringer af koden og opbyggelse af patterns samt genkendelses af patterns. De ting vi bruger til at genkende et pattern er input værdier fra lyssensorerne, og kørselsretningen, samt en relaxations variabel. Det gør at vi ikke skal vide hvor lys sensorerne er placeret på bilen, da vi kigger på hvilken retning bilen kører i. Relaxation variablen bruger vi til at markere et treshold for vores inputværdier. Den er nødvendig at have med da vi ved genkendelse skal have et hit fra begge sensorinput. Ved at vi har kørsels retningen med i sammenligningen gør at vi ikke klikker på vores pattern når vi er i gang med at køre væk fra det kritiske område. Da der til denne udgave ikke skal være nogen reaktionsoptimering lader vi bare bilen køre frem og tilbage. Når bilen så skal reagere vendes kørselsretningen om frem for at finde den optimale kørselsretning.


De centrale elementer fra vores update funktionen.

Problemer
Mangel på c erfaring gjorde at vi havde lidt svært ved at tyde memory copy fejl vi fik. Efter at vi havde slavet os igennem koden fik vi dog rettet dem alle sammen sådan at koden kunne kompilere korrekt hvilket gjorde at vi kunne teste. Gunden til problemerne var at vi ikke kunne finde ud af at kopiere flere variabler af gangen, f.eks. en struct. Dette kunne kompileres men gav linker fejl. Derfor var det nødvendigt for os at lave forskellige hjælpefunktioner til disse opgaver(copySample).

Test
Til at afprøve vores løsning har vi valgt at teste den i et kontrolleret miljø. Med det menes der hvor bilen til at starte med kun kan køre frem eller tilbage. At lys sensorerne ikke flyttes rundt til andre placeringer under testene. Under den første test med den overordnede model udførte vi testen på denne måde, for at mønstrene kunne genkendes var det dog nødvendigt at sætte treshold op for hvor tæt inputværdierne skulle være inde for et mønster. Med denne test vil vi afprøve om de grundlæggende elementer fungere i vores kode. I første omgang drejer det sig om bare at genkende et tidligere læst pattern. Vi vil også under samme test finde ud af om den måde vi lagre et pattern er brugbar.

Testen medførte at vi efter at vi havde ramt med en kritisk sensor en gang og samplet et pattern kunne genkende det og nå at stoppe tids nok til at kunne reagere på det. Testen var en succes og bilen havde ingen problemer med at reagere. Det betød dog at bilen kom til at reagere et stykke fra muren, da den ikke lavede nogen optimering af reaktionstiden. Vi kunne ved samme test hvor relaxation ikke var høj se at vores lagring af patterns ikke så ud til at skabe problemer. Vi kunne dog se at vi havde fået lavet et godt fundament som fungerede og var godt til at bygge videre på.

Project Log Entry 4

1. Timermekanisme
   
   • Akkumulativ tid. Evaluation Periods længde stiger, i takt med at der er en længere og længere kæde af critical events, der har resulteret i den sample, hvis reaktion der skal testes. (Denne kæde behøver ikke være udspecificeret, derimod kan man lade hver sample indeholde hvilken længde evaluation period, de ikke bestod.)
   • Derudover kunne man evt. sætte mere komplicerede movementPatterns sammen og bruge dette til at generere mere komplicerede reaktioner og opførsel.
   • Random tid eller konstant tid.
2. Reaktioner
• Test af forskellige reaktioner. Det kunne fx være at en Sample bliver testet med fire eller flere reaktioner og kun bliver markeret som critical hvis alle rammer CriticalSensor indenfor ” evaluation period”.

Erfaringer
Vi har via implementeringen i simulatoren fået en god ide til hvordan algoritmen skal opbygges. Hver gang at et pattern klikker bliver der holdt øje med at der ikke er aktivering af en kritisk sensor inde for det tidsrum hvor reaktionen på genkendelsen sker. Hvis kritisk sensor aktiveres indenfor tidsrummet(evaluation period), markeres dette pattern som kritisk og den sampling der var lige inden, der var en genkendelse, bliver gemt som et nyt pattern. Næste gang det så mødes laves den samme undersøgelse igen, er det muligt at reagere så der ikke aktiveres en kritisk sensor.

Test
Vi har i denne test igen valgt at teste i det kontrollerede miljø hvor vi kun kan køre frem eller tilbage. Det skulle nu være muligt for bilen at finde en reaktionstid så den senest muligt reagerer og kører i modsat retning. Relaxation er sat ned til 3, så samples til at finde vægen bliver meget finkornet.. Efter at have kørt frem og tilbage ca. 10 gange skiftede bilen retning, tidsnok til at den ikke kørte ind i muren. Der bliver altså opbygget et reaktionsmønster hvor tidligere patterns er markeret som kritiske, når bilen så har mødt dem igen er der blevet oprettet et pattern ud fra det sample lige inden.

Matchmekanisme
Matchmekanismen (CompareTo, senere CompareToCurrent) er blevet implementeret i en meget primitiv udgave. Hvis de nuværende motortilstandene er de samme som pattern'ets motortilstande, så tilføjes 50 point til et patterns score for hver inputport x (x = 1, 2) hvor:

nuværende inputx - relaxation < pattern.inputX < nuværende inputx + relaxation

Hvis matchværdien er over clickThreshold, som i nuværende kode betyder at ovenstående dobbeltulighed er opfyldt for både x = 1 og x = 2, så sættes pattern til at reagere. I nuværende implementation er det det først klikkende pattern som får lov til at reagere. Dette vil blive udvidet senere hvor det bliver den der er nærmest de nuværende værdier, der bliver sat til at reagere.

Man kan i matchmekanismen lege med mange forskellige ting. Vi har undladt at implementere eller på anden måde at gå i dybden med disse ting, men de idéer der har været oppe er:

• Sandsynligheder ud fra normalfordelinger eller andre fordelinger.
• Brug af statistik over de forskellige input, til at tolke signifikansen af deres variation.
• Sammenholdning af patterns med samme type reaktion/action til at identificere en vægtning af de forskellige input.

Grunden til at vi ikke har forfulgt nogle af disse aspekter er, at vi ville have en funktionel version først som vi kunne bruge til test og til at videreudvikle på. Uddybning følger.

Project Log Entry 5

Grundide til implementation
Ideen til hvordan vores actionselection mekanisme skal fungere er sådan at når et pattern bliver genkendt skal bilen afprøve nogle forskellige handlinger. For at vurdere om en handling er en succes kigges der på om der inden for en tid efter at handlingen er begyndt rammes en kritisk sensor. Hvis det er tilfældet at handlingen fejler skal der angives en ny handling til det tilhørende pattern. Næste gang at dette pattern så klikker skal den nye handling afprøves. De actions som bilen afprøver er sådan at den gradvist prøver at lave et større sving, og skift mellem venstre og højre. På den måde findes der lige præcis den handling der tilstrækkelig til at bilen kan komme ud af den kritiske situation. For at optimere på om handlingen bliver en succes har vi valgt at der skal være en reaktionstid efter at handling er blevet udført hvor bilen kører lige ud, hvis bilen har lavet et lille sving som ikke tog så lang tid skal den altså kører længere tid lige ud efter handlingen. Hvis denne reaktionstid ikke er med kan lille sving bliver klassificeret som en succes, hvor den ikke burde være det da bilen ikke er nået ud af den kritiske region..

ActionSelection. Figur 3. Figuren viser afprøvningsmønsteret for at finde den optimale handling. Alt efter hvor direkte bilen kører ind skal der færrere antal handlinger til at finde ud af hvilken handling, der var den mest optimale.

ReactionTime. Figur 4 For at kunne nå at vurdere om en kort handlinger er en succes vurderes der i en reaktionstid efter at handlingen er blevet udført.

Implementation
For at vi nemt kan lave nye actions til bilen har vi tilføjet dem som structs. Hver action består af to motorstates og to motorpowers, samt en tid for hvor langt handlingen skal foregå.

Den centrale funktion til denne funktionalitet er ReactionUpdate. Her bliver der vurderet om en action er blevet udført med succes, hvis ikke vælges der her en ny action. Under hvert gennemløb af updatefunktionen kaldes ReactionUpdate. Hvis der har været et klik på et pattern er der blevet angivet en handlings tid. Så længe der er tid tilbage fortsættes handlingen. Hvis ikke der er handlingstid tilbage bliver bilen sat til at udføre default action som er at køre fremad. I samme funktion undersøges der om den kritisk sensor er blevet aktiveret. Hvis det er tilfældet er den nuværende handling ikke en succes, og der skal skiftes til en anden handling, som så kan afprøves næste gang at dette pattern klikker.

Kode ind fra reaction Update funktion

Beskrivelse af konstanter:
Da vi under netop disse labsession virkelig fandt ud af hvordan forskellige konstanter havde betydning for hvor godt indlæringen af robotten foregik vil de nu blive forklaret lidt grundigere.

For hver konstant er der forklaret følgende:
- Formål
- Hvor bliver den brugt.
- Hvilken indflydelse har dens værdi på indlæringen.
- Hvilke ting kunne den udvides med, hvis vi havde 3 måneder mere at arbejde på det. Hvilken indflydelse har ændringer af de forskellige konstanter i programmet?

• - LearnedSamples
  • Størrelsen af LearnedSamples afgør hvor mange forskellige situationer der kan læres. Hvis man vil have et lavt antal lærte samples og stadig have at robotten genkender de vigtige situationer, så kan man vælge at sætte relaxationvariablen til en høj værdi.
• - Relaxation
• Relaxationværdien afgør hvor finkornet robotten anskuer samples på. Ved en lav værdi, vil robotten skulle lære mange flere samples, end ved n høj relaxationværdi. Den vil dog skelne bedre mellem forskellige situationer ved en lav værdi og er bedre i stand til at lære præcis opførsel.
• Lav relaxationVærdi vil medføre at robotten får et mindre antal ”false positives”. Ved høj relaxation vil antallet af ”false positives” stige.
• Relaxationværdien har også stor indflydelse på ”oplæringsperioden”, da relaxationværdien der stor indflydelse på hvor hurtigt robotten ”konkluderer” kritiske situationer og reaktioner derpå.
• actionTimeSlice (actionTimer) (En variabel på den enkelte action-struct)
• Hvis den værdi er lav, så medfører det at der skal læres flere situationer for at undgå en kritisk situation, da den kun delvist vil komme ud af den ”tæt-på-kritiske-situation”. Fx kunne man forestille sig at robotten skal dreje til venstre når den er ved at støde ind i en væg. Med en lille actionTimeSlice, så vil den ikke få drejet 90 grader, men måske kun 10 grader. Denne action bliver ikke markeret kritisk, da det først er når der køres fremad igen, at der opnås kritisk tilstand. Den skal derfor lære at dreje til venstre igen, når den står med en 10 graders vinkel foran en væg. Det er nu tydeligt at actionTimeSlice har en stor indflydelse på indlæringstiden og antallet af samples der skal læres. Men ved denne større indlæringstid, får man også en bedre og mere præcis avoidence
• ReactionTimeSlice (ReactionTimer)
• ReactionTimeSlice er længden af Evaluation Period. Ved oplæring af en robot, indlæring hvor man som person skal give CriticalSensorTriggered, kan man sætte ReactionTimeSlice op, så man kan nå at give robotten input til dens actions. Dvs. hvis den drejer til højre ved en sampleclick og man vil have den til at dreje til venstre i stedet, så er skal man nå at trykke på CriticalSensor inden ReactionTimeSlice løber ud.
• PowerConstant
• En variabel der angiver hvor meget power der skal sættes på de forskellige outputporte. At have motorens power som konstant begrænser antal patterns og dermed indlæringstiden for bilen.
• ClickThreshold
• Angiver mindsteværdien for at en sample-sammenligningsscore bliver anset for at være et ”klik”.
• Man kunne overveje at lave denne mere dynamisk, men for at holde programmet simpelt, så er det undladt.
• PossibleActions[possibleActionAmount]
• Dette array indeholder de mulige opførsler en sample skal prøve at bruge. Et stort antal actions ville kunne bruges til at opnå bedre reaktioner, men ville også øge indlæringstiden. En ting man kunne gøre var at lave forskellige opførsler, og for hver opførsel have flere tider de blev prøvet i. Man kunne udvide dette aspekt, ved at have sekvenser af opførsler. Men på den anden side opnås dette allerede med samples. (uddyb evt. her)
  

Tests:

1. Follow-wall
   • ReactionTimeSlice blev sat ned til 1000ms.
   • Og ActionTime blev sat til 100ms.
   • Tog omkring et par minutter og den havde 20 samples, måske lidt mere.
2. Follow-line
   • Relaxation blev sat op til 10.
   • Tog ca. 4 minutter før den fulgte banen i nogenlunde stil, den kørte dog stadig af banen en gang imellem. Den klarede sig med under 10 samples.
3. Follow-road på Lego-roadsystem
   • Delvist success. Det gik galt pga. den drejede i for lang tid. Vi ville have opnået den rigtige opførsel, ved at sænke reactionTimeSlice og actionTimeSlice. Dette blev dog ikke gjort, da der var andre og vigtigere ting at bruge tid på.

Oplæring af Robotten
Oplæringen af Lego-bilen foregår ved hvad man kan kalde kalibrering af dens opførsel. I oplæringssetups er der flere ting som man skal tænke over:

1. Er det muligt for bilen en at konkludere rigtigt, ved hjælp af de sensorer man har stillet til rådighed for den.
2. Hvordan kan placeringen af sensorerne bruges til at give bilen bedst mulig information, så den kan drage de bedste mulige konklusioner.
3. Hvordan laves støttehjulene (dvs. det der sørger for at der kommer criticalSensorTriggered på de rigtige tidspunkter) så det ikke ændrer på bilens ”verden” at de bliver fjernet. Man kan sige at man koder bilens opførsel, ved at give den de forudsætninger og motivationer som resulterer i en bestemt opførsel. (hvis man da har tænkt sig ordentligt om) I løbet af projektet har vi primært testet ved at oplære Lego-bilen til wall-avoidence, men vil nu give eksempler på setups til at oplære en Lego-bil til et par forskellige ting.

Project Log Entry 6

Eksperiment d. 30/5/06.

1. Deleksperiment Ændring af relaxation.

Eksperiment 1.1: (på bane-bordet) I dette eksperiment brugte vi følgende værdier: Lyssensor click-interval: +-4, Det vil sige at et hit på den enkelte sample kan ligge inden for et interval på 4 over og under den gemte værdi i det pågældende pattern. Faste variabler ReactionTImeslice: 1000 ActionTimeslice: 800 Samplelength: 5 ClickThreshold: 80 samplerate: 30ms. Refleks-adfærd: Rot.left, Rot.right, forward(default), collision back up(hvis fremad)   Billede til højre viser de fysiske opsætninger. 2 lyssensorer og en bumbsensor kørende på bane bordet.

Efter 5 minutters kørsel klarede robotten knap 1½ minut uden kollisioner. Den havde på dette tidspunkt lært 152 samples. Herefter ramte den ned i et hjørne, hvor den desværre fik lært en masse dårlige ting. Vi udskriver antal lærte patterns i displayet, og kunne se det vokse hurtigt, og uden fornuft. Det er en kompleks situation at befinde sig i, da den fik placeret sig selv så den havde mur 1 cm foran sig, og 1 cm bag sig.

Eksperiment 1.2:
Ændring af click-interval til +-8
Vi forventer at den vil lære færre samples, men at den vil få en bredere klassificering, altså få en knap så finkornet,

Resultat:
Kørte efter 5 min. Ca. lige så godt som i forrige eksperiment, men med kun 95 samples lært, altså en hel del hurtigere oplæring..

Eksperiment 1.3:
Vi prøver nu med et click-interval på+-20
Herefter håber vi at få et billede af denne værdis betydning for…
Efter ca. 1½-2 minutter kørte den ret godt på banen i forhold til de 2 forrige, og på det tidspunkt havde den lært 15 patterns. Efter yderligere 1 minut kørte den stabilt og godt uden at støde ind i ting, men den valgte pudsigt nok næsten aldrig at dreje til venstre for at undgå at støde ind i ting. Det at den valgte højre, må jo siges at være fint nok, idet denne adfærd faktisk var en succes. Når den kom skråt ind mod en kant på dens venstreside, kunne den nå at dreje så meget til højre at den kørte i den modsatte retning langs med kanten. Den anden vej kunne den følge kanten hele vejen rundt, faktisk ind til vi manuelt ændrede dens retning med vores tykke pølsefingre.

Vi lod den køre yderligere 20 min., til den havde kørt ½ time i alt. På det tidspunkt havde den lært 91 patterns, og var i stand til at køre næsten fejlfrit, dvs. der gik mere end 5 minutter uden kollisioner til sidst, og der kunne formentligt have gået langt længere, hvis det ikke var fordi vi havde flere planer med tiden i dag, og derfor skulle videre. Til gengæld var den blevet lidt mere forsigtig da vi kom tilbage, dvs. den drejede meget tidligt i forhold til hvor tæt den var på kanten. På det tidspunkt var solen gået væk, og det var overskyet, og vi mener at disse ændrede lysfohold fik den til at klikke tidligere på de enkelte patterns, og de ændrede forhold kan derfor have været medvirkende til robottens øgede evne til at undgå kanterne.

2. Deleksperiment ændring af relaxation ved lav action-duration

Resultat:
Hold da fast! Vi blev meget overraskede over resultatet. Efter ca. 2 minutter kørte robotten næsten fejlfrit, men denne gang med rigtig mange reaktioner meget tæt på kanterne, og stadig uden at støde ind i dem. Reaktionerne virker tillige mere naturlige, idet det nu fremtræder som om at en sekvens at små handlinger udgør en samlet reaktion. Det ser fedt ud.
En anden vigtig ting vi nu kan se er at træningsudgangspunkt meget vigtigt. Vi genstartede nemlig robotten fra et dårligere udgangspunkt, nemlig ned mod et hjørne, og det betød at den hurtigt fik samlet en hel del dårligere patterns op meget tidligt. Dette forstyrrer kvaliteten af det robotten lærer. Den lærte meget hurtigere flere samples, hvilket jo må være en naturlig konsekvens af at den reaktioner nu varer kortere, og den derfor vil have flere kollisioner. Alt i alt et meget spændende eksperiment med overraskende og lærerige resultater.

Robottens valg af reaktioner er pt. Primitivt. Den går en liste af mulige reaktioner igennem sekventielt, og starter eksempelvis altid med at forsøge et højredrej. Det er helt sikkert medvirkende til at robotten igennem flere af eksperimenterne har udviklet en adfærd der bygger på at undgå forhindringer vha. højredrej. Vi overvejer at ændre denne sekventielle gennemgang af adfærd i kollisionssituationer, men den er guld værd her, idet den giver en meget god forståelse af hvordan robotten faktisk lærer. I teorien burde det ikke have indflydelse, da et højredrej i en given situation burde klassificeres ud fra om det var en succesfuld reaktion eller ej, men virkeligheden er mere nuanceret. Det tyder på at evaluationperiod kunne være for lav, hvis et højredrej klassificeres som godt, hvor et venstredrej faktisk ville være bedre, set fra vores ekspert-øjne.

Eksperiment 2.2
Vi forsøgte at skrue click intervallet ned til 8, og bibeholde de andre værdier fra forrige eksperiment. Dette var ikke en succes. Robotten havde en tendens til at stå og oscillere når den kom ned i et hjørne.

Eksperiment 2.3
Vi prøver nu med clickinterval tilbage på de 20, og med actionduration på 200 og evaluationperiod på 500. Efter de første 200 vil bilen kun køre ligeud, men vi forventer at det vil have en effekt på hvor skarpt bilen lærer at dreje, og at det vil få den til at blive bedre til at lære at dreje til venstre.

Resultat:

PROBLEM:
”Hold da fast!” Eksperimentet fungerer ikke længere med tilnærmelsesvis den samme succes. Vi er sikre på at koden er den samme, helt sikre, og at vi kører med de samme parametre. Altså må det være lysforholdende, eller robottens startbetingelser. Selv efter at have prøvet flere forskellige startbetingelser, giver det ikke noget der minder om det tidligere resultat, altså må det være lysforholdende. Kl. er nu 18, og det ER blevet væsentligt mørkere indenfor de sidste timer. Dog utroligt, hvis det skulle være det der er galt.
Vi prøver nu at skrue lyssensor click-intervallet ned fra +-20 til +-8
Resultat: Det blev værre. Vi afsluttede eksperimenterne for denne dag da vi mente at lysforholdende havde for stor påvirkning på eksperimenterne.

NOTER:
Followline experiment(og måske follow wall, da vi jo har prøvet det), og supervised vs. Unsupervised learning.

30/5 duration: fra 1200 til 1930, 7½ time. Primært med eksperimenter med parametrenes betydning for robottens evne til at lære og reagere. Dog også en hel del med rapport-skrivning.

31/5/06

Dagens første eksperiment: kl. 1010
Vi prøvede med HK-eksperimentet fra i går, men med +-40, hvilket var meget højt. Vi håbede på at robotten ville blive bedre til at dreje til venstre, da den i højere grad ville klikke på de samme patterns, og dermed få afprøvet flere forskellige reaktioner.

Resultat: Robotten blev bedre til at dreje til venstre, ikke meget, men dog en hel del. Til gengæld fik den en hel del sværere ved frontale sammenstød med væggen, og i hjørnerne, hvor den havde en kraftig tendens til at blive hængende og prøve alt muligt.

Eksperiment 2: (Kl. 1330)
Implementeret semi-incremental reaktionstid, og random valg af om den vil til venstre eller højre. Ideen skulle være at den forsøger de samme reaktioner igen og igen, men i længere tid hver gang. (0.2, 0.4, 0.8 pt. ) og med +-20
#Reaktioner: 6
Reaktionsvarighed: 800
Evalueringsvarighed: 1000

Resultat:
Udmærket resultat. Robotten lærte både at køre til højre og til venstre, og blev faktisk god til at køre udenom væggene. Vi har stadig et problem med hjørnerne, hvor den ikke kan finde ud af hvad der er bedst for den. Det er sådan set fair nok, idet den ikke med de nuværende sensorer ikke kan sige hvilken væg den kommer ned langs, når den rammer et hjørne.

Eksperiment 3: (Kl. 1340)
Vi kører nu med 8 reaktioner, men ellers samme som før.
Resultat:
Bedre til at komme ud af problemer i hjørnerne.

Eksperiment 4: (kl. 1630)
Vi har nu ændret systemet, så den ikke opretter lærte patterns, mens den er i gang med en undvigelsesreaktion. Vi mener at meget af det den lærer under reaktionerne er ubrugeligt, og forventer at den nu lærer færre patterns, og vil køre mere præcist.
Resultat:
Robotten lærer nu væsentligt færre patterns. Efter 5 min. Har den ikke lært mere end 20, men kører faktisk rimeligt præcist. Det tager altså væsentligt længere at lære tingene nu, men det lader til at kvaliteten af dens lærdom er bedre.

Eksperiment Final
Relax -+20, Reactiontime 1600, Eval Time 1600, 8 Actions

Resultat:
Den kører rigtig godt med disse indstillinger, svingene kan blive store men kun hvis det er den mest optimale handling at foretage i den situation. Små sving sker stadigvæk hvis vinklen ikke er så skarp ind til muren. Efter 5 min. kan den køre rigtig godt rundt på banen med kun 15 samples. For lige at være sikker på resultatet blev eksperimentet gentaget et par gange med det samme resultat til følge.

Eksperiment passive lyssensorer.
Test med passive lyssensorer Lav relaxation på 5.

Resultat: Ok, men ikke så godt som de forrige Den er god til at genkende patterns men det kunne være bedre med et lavere lysinterval. Da vi ikke har mere tid må vi stoppe her.

Konklusion på tests 30/05/06 og 31/05/06
Vi kunne efter at vi havde udført de forskellige tests kunne vi se at bilen på flere punkter opførte sig som forventet. Ved høj relaxation var der få samples, men flere fejl-tolkninger. Hvis der sammetid var mange mulige forskellige actions kunne vi også se at det var nødvendigt med en ikke alt for lav relaxation, da det ellers var for svært at klikke på det samme pattern igen. Desuden fandt vi ud af hvilke minimums grænser for evaluerings tiden for en action, der var nødvendigt for at en action ikke for hurtigt blev vurderet til succes. Med resultaterne af testen fandt vi desuden den opsætning til præsentation til den næste dag. Denne opsætning er hvor relaxation er på 20 og 8 actions hvor tiden til evaluation af action ændres i forhold til hvor stort svinget er.

Eksperiment 05/06/06
Mindre antal Samples
Et problem ved indlæringen i ovenstående forsøg er at der var et højt antal samples. Dette skyldtes at hver gang en behaviour blev testet af og gik galt, så blev der oprettet et nyt pattern. Efter at have ændret dette, så faldt antallet af patterns drastisk og indlæringen blev bedre. Denne bedre indlæring blev vist til fremvisningen og vil blive gået lidt mere i dybden med herunder.
Testen:
Testen i dag, gik ud på at dokumentere indlæringen af Lego-bilen kvantitativt, i stedet for de mere beskrivende forsøg tidligere.
Test-setup:
-

• Mål:
• At lære Lego-bilen at bruge to aktive lyssensorer til at undgå at støde ind i vægge. Når bilen ikke har andet at lave (avoid) så kører den fremad.
• Hvor
• Testen blev foretaget på banebordet (Det blå bord)
• Kritisk sensor input:
• Kritisk sensorinput er to pressure-sensorer, forbundet til ”kofangere”. (De kan nok kun fange noget lidt mindre end køer, måske hamstre, måske mindre endnu.)
• Data:
• Hvert 30. sekund aflæses antal patterns lært og antal gange den kritiske sensor er blevet udløst.
• Antal tests:
• Der er blevet kørt 2 forskellige tests og hver test er kørt 3 gange.
• I den første testtype startede bilen med at køre vinkelret ind på væggen, i den anden testtype startede bilen med at køre skråt ind mod et hjørne.
• Settings:
• Standard opsætningen som også blev brugt under præsentationen.
• Forventninger:
• Det forventes at Lego-bilen begynder at køre nogenlunde stabilt inden der er gået 5 minutter, dog vil den stadig mangle at lære nogle situationer at kende.

Figur 6: Startsituationer ved oplæring

• Argumentation for test:
• Test af konsekvenserne af hvordan starten af oplæringen påvirker indlæringstiden.
• Testværdier hver 30. sekund giver en tilpas opløsning til at det er muligt at se både situationerne hvor Lego-bilen tester reaktioner og den længerevarende forbedring i mindsket antal kollisioner med væggen.
• Der er lidt forskel på informationerne i testene. De første (1 og 2) blev ikke tjekket for antal lærte patterns. Det gjorde 3 og 4, men de kørte ikke længe nok til at frembringe den tydelige udjævning i antal kollisioner med væggene. De sidste to tests blev kørt i 16½ minut.
• X-aksen er tid, y-aksen er det samlede antal kritiske sensor input og lærte patterns, til tid x.

Herunder ses graferne over Test 5 og 6.

Det ses at der i starten af begge kurver for antal CriticalSensorTriggered stiger ud med at stige hurtigt, men begynder efter nogle minutter at jævne ud. Der ses en tydelig forskel på Test 5 og 6 i hvor hurtigt og pludseligt udjævningen i stigningen i antallet af CriticalSensorTriggered.
Vi mener at denne forskel skyldes at Test 6 fik håndteret hjørnesituationen fra starten og da det er denne der er ”sværest” og som udløser flest CriticalSensorTriggered. Dette medfører, udover at der er et knæk i kurven for CriticalSensorTriggered, at der også kan ses et knæk i antal lærte patterns. Dette knæk skyldes at de patterns der skal læres for at komme ud af et hjørne (Aktive lyssensor har en afstand, hvor de næsten ikke skifter værdi mere) bliver lært fra starten.
Derudover ser det ud til at det tager under 20 minutter at lære Lego-bilen op til at undgå at støde ind i væggene. Men allerede efter 4-5 minutter kørte den forholdsvist pænt i alle testene. Det skal nævnes at vi efter 8 - 10 min begyndte at give bilen udfordringer.

Præsentation af projekt

• Koncept og motivation
• Implementation
• Eksperimenter
• Problemer, ting vi ikke nåede

1 Koncept og motivation
1.1 Abstrakt
Et generelt læringssystem til robotter, der selv skal kunne tilpasse sig forskellige opgaver, udelukkende ved hjælp af reaktioner og de stimulus der trigger reaktionerne. Eksempelvis skal dette system kunne lære både obs. Avoid, follow-line, og follow wall vha træning /oplæring både supervised og unsupervised.

1.2 Indgangsvinkel
Systemet lærer specifikke situationer at kende og forsøger at tilknytte forskellige reaktioner /adfærdsmønstre til disse situationer. Når den forsøger sig med given reaktion til en situation måles succesen i fht. om den efter denne reaktion ikke ender i en av-tilstand i x antal sekunder efter. Hvis den gør det vil den forsøge sig med en anden reaktion næste gang den genkender samme situation. Ellers husker den sin succes.

2 Implementation

• 2.1 Definitioner:
• Kritisk hændelse:
• En tilstand som Legobilen skal lære at undgå. I vores eksempel bruges bumpsensor. (og patterns)
• Sample:
• Et snapshot af Legobilens tilstand.
• Pattern:
• Et billede af Lego-Bilens tilstand før der skete en kritisk hændelse. Pattern bruges til at prøve at undgå den kritiske hændelse. Hvis dette ikke er muligt, så markeres det enkelte pattern, selv som kritisk hændelse. En pattern-kritisk-hændelse er lidt ”mildere” end en sensor-kritisk-hændelse.
• Reaktion (Actions)
• Et grundsæt af simple handlinger som Lego-bilen har til rådighed.
• Klikker
• At et pattern klikker, betyder at den inden for en udregnet sandsynlighed er det pattern som svarer til den tilstand Lego-bilen er i.
• 2.2 Algoritmen
• Mainloop: Sense – Plan – (Learn) - React
• Initialisering
• a. Der køres en kort historik over sensorinput. Når en kritisk hændelse sker, så oprettes et pattern, baseret på historikken og robottens tilstande.
• Kritiske hændelser
• b. Når Legobilen rammer en kritisk hændelse, går den i panik. Fx kan den køre baglæns medmindre den er i gang med at køre baglæns, ellers forlæns.
• Genkendelse
• c. Mens den kører rundt, prøver den hele tiden, at genkende de ting den ser. Hvis den ser noget den kender i forvejen, så reagerer den. Denne reaktion er delt op i to tilfælde. Den ene hvor den prøver at reagere fornuftigt og i det andet tilfælde, den hvor pattern er kritisk hændelse, gås der i panik.
• Reaktion
• d. Når pattern som ikke er kritisk hændelse ”klikker” prøver det de mulige reaktioner af. Den opdager at en reaktion ikke var god, når den går galt.
• 2.3 Vigtige ting i implementationen:
• Hvordan vurderes et pattern til at være en klikker?
• Hvordan vurderes en reaktion?
• 2.4 Referencer
• Klik = Prioritet.
• Reaktioner = Subsumption.

3. Eksperimenter

• 3.1 Variabler og betydning
• Relaxation
• En variabel der bruges i klik-funktionen.
• Reaktions-længder
• Længden af reaktioner definerer hvor finmotorisk eller groft Lego-bilen reagerer.
• Evalueringslængden af reaktioner
• Den tid efter reaktionen der skal kunne køres ligeud uden at opleve kritisk sensor.
• 3.1.1 Wall-avoiding:
• Selflearning, vha. bumpsensor.
• 3.1.2 Line-follow:
• Oplæring (medmindre der blev lavet en cool testbane, dvs. glasvægge.)
• 3.1.3 Wall-follow:
• Oplæring
• 3.1.4 Road-follow/ditch-avoid.
• Oplæring eller smart ditch.
• 3.2 Erfaringer fra eksperimenter:
• Lysforhold betyder meget. Også mere end vi havde forventet, ud fra vores tidligere erfaringer.
  Skiftende lysforhold medførte at Lego-bilen skiftevis var meget modig og meget forsigtig. Og nogen gange en komplet idiot.

• 3.3 Betydning af sensor placeringer
• Betydning af at tænke over hvor man sætter sensorer, både dem der bruges i patterns og de kritiske sensorer.
• 3.4 Vigtige variable
• Relaxation
• Lavt antal patterns vs. højt antal patterns
• Kort oplæring vs. længere oplæring
• Flere false positives ved høj relaxation.
• Reaktionslængder
• Yndefuldt vs. Klodset/stivemandsreaktioner
• Længere oplæring vs. kortere oplæring

4. Problemer og ting vi ikke nåede

• Sample weeding / Merging
• Bedre udvælgelse af reaktioner
• At markere de succesfulde reaktioner og bruge dette til at vurdere patterns.
• Problemer med præference for en retning (højre eller venstre)
• Bedre klikfunktion
• Større antal og/eller bedre sensorer.
• Længere varende vurderingsmekanismer ovenpå det implementerede.
• Patternbillede kunne udvides med ”chain-of-events”-mekanisme eller anden ”over-tid”-vurdering
• Indsamling af information om de enkelte sensorer. Både deres variation (som kan bruges til relaxation) og hvornår de bare er støj. Kort sagt, deres udvikling over tid. Derudover mulighed for at opdage at de generelle lysværdier har ændret sig over tiden.
• Brug af neuralt netværk.
• Man kunne bygge mere komplicerede opførsler op ved at lære robotten op til forskellige ”tilstande”. Disse kan så skifte ved at lave en struktur med:
• Opførsel1 – transition eventX – OpførselX – osv.

Diskussion

Hvor godt er projektet lykkedes?
Vi er meget tilfredse med den endelige løsning der giver gode muligheder for videreudvikling i forskellige retninger. Set i bagklogskabens ulideligt klare lys, var det nok ikke nødvendigt at lave simulatoren. Når det er sagt, så tror vi dog at den ville kunne bruges som et godt testværktøj til at udvikle de forskellige over- og ud-bygninger af vores kode. Vi mener at det er lykkedes os at lave et system der faktisk er i stand til at lære basale ting udfra en primitiv biologisk model, baseret på smerte, fortolkning af stimuli og situationsgenkendelse. Vi har faktisk løst flere af de tidligere lab-opgaver (rent funktionelt) vha. vores system, nemlig folow-wall, follow-line og obstacle avoidance, kun ved træning og ændring af reaktiontider.

Vi har i løbet af vores projekt og også denne labrapport haft mange idéer til mere avancerede løsninger af de enkelte dele af vores algoritme. Derudover har vi overvejet brug af programmet til mere avancerede opførsler og opgaver - desværre ikke nogen vi har haft tid til at lave. Nogle af disse videreudviklinger og vores tanker om deres løsning (som vi desværre ikke har haft tid til at lege med) vil blive beskrevet herunder.

Udvidelse af sample/pattern
Hvis man forestiller sig 2 patterns, med kun 2 lysværdier i hver, og med den samme reaktion tilknyttet begge patterns (disse eksisterer i hobetal i vores tests), kan man definere en ny type pattern. Hvis vi kalder lysværdierne i disse patterns for hhv. L11, L12 og L21,L22 og antager at L12 ligger tæt på L22, og L12 langt fra L21 kunne man prøve at lave et nyt pattern, hvor hver sensor-værdi i pattern'et får tilknyttet en vægt, der kan benyttes til at skabe en match-værdi for den pågældende sensor. I eksemplet ovenfor ville vi så øge vægt-tallet for den sensor der har de tætliggende værdier (L11, L21) og sænke vægten for den anden sensor. I beregningen af match-værdien for hele pattern'et vil vi så få en match-værdi der reflekterer at en sensor har større vægt i sammenligningen end en anden sensor. Dette princip har vi selv fundet på, men efter at have læst lidt om neurale netværk, kan vi se at det faktisk er et af grundprincipperne i disse netværk. Dette ville vi RIGTIG gerne have haft tid til at eksperimentere med, da det ville give vores system muligheden for at klassificere patterns, og "merge" dem.

Avancerede opførsler og reaktioner
Vi ville gerne have udstyret vores robot med en higher-purpose adfærd, altså et "drive" for dens eksistens. Det kunne være at lede efter lyskilder eller noget andet, for det er netop i lyset af en højere mening at adfærd i sig selv giver mening. Det ville ydermere have illustreret pointen med at reaktionerne ikke skal være arbitrære, da reaktionerne skal komplementere meningen med dens eksistens, altså dens højere mål.
Vi ville også gerne have eksperimenteret noget mere med flere, mere advancerede adfærds-mønstre, med et større tidsperspektiv og andre, mere komplekse, succes-kriterier for adfærd/reaktioner, men som sagt har tiden været knap.

Weeding mekanismer
I vores implementation lever et pattern for evigt, uanset dets berettigelse. Det sker jævnligt at robotten lærer noget skidt, false-positives, men denne lærdom forbliver en del af dens lærdom. Hvis man til et pattern associerede en beretigelse-værdi, der hver gang robotten klikkede på dette pattern og udførte den tilhørende reaktion med succes, ville få talt sit beretigelses-værdi op, og talt ned når den tilhørende reaktion ikke virkede, ville man på denne måde få et tal, der altid skulle være større end 0 ved sunde reaktioner, og på et tidspunkt mindre end 0 ved usunde reaktioner. Dette kunne man bruge til at fjerne patterns, med en beretigelse-værdi mindre end 0, og dermed fjerne usunde erfaringer fra dens lærdom.
Yderligere overvejde vi at sikre at robotten ikke kan lære "endegyldige" sandheder. Endegyldige sandheder passer ikke godt til skiftende omgivelser, og derfor overvejde vi følgende: Alle patterns fjernes indenfor et tidsrum, men med en sandsynlighed baseret på deres beretigelses-værdier. På denne måde vil alle patterns med tiden blive dræbt, og nye skulle læres, men de mest brugte, og de mest sunde ville have den længste levetid. Dette ville give robotten bedre muligheder for at klare sig i skiftende omgivelser over tid.

Flere sensorer
Ved at bruge et større antal sensorer, ville man kunne få bedre genkendelser af omgivelserne. Vi har brugt relativt få sensorer i vores projekt, og det har været medvirkende til robotten kun har kunne lære simple situationer at kende, og at den har haft lidt svært ved at finde ud af hvordan den f.eks. kommer ud af hjørner. I takt med at vi ville have øget antallet af sensorere, ville behovet for en mere avanceret klik-mekanisme a la ovenstående med vægte, nok have indfundet sig, idet at antallet af sensorer har en direkte indflydelse hvor mange patterns robottens ville lære indenfor et givet tidsrum, med den nuværende implementation. Der ville dog stadig være mange ting man skulle tage stilling til. Det ville være nødvendigt at tage ind i overvejelserne af sammenlignings/klik-funktionen, hvor mange sensorer der "er hinandens modsætninger" (fx lyssensor frem vs bagud) og deraf hvor mange sensorer der bør være enige, før man mener at det er muligt at konkludere et klik. Ved et større antal sensorer, ville sandsynlighedsregning og statistik helt klart være noget der var meget at vinde ved at tage med. (fx gennem neurale netværk eller lignende) Grunden til at sandsynlighedsregning og statistik sikkert ville blive nødvendigt, er hvis man stadig vil være uafhængig af viden om sensorne, så er det nødvendigt at man prøver at gå ind og identificere hvilke sensorer og hændelser der er uafhængige. Især hvilke sensorer der er afhængige inden for en bestemt reaktion. Dette er ikke noget vi har diskuteret ret meget, men det er helt sikkert noget der ville være godt med gods i at undersøge.

Afsluttende bemærkning
Alt i alt føler vi at det har været et meget spændende projekt vi har været igennem, hvor der stadig er mange gode muligheder for viderudviklling. Det har været svært, sidst i projektet, at lade være med at forfølge nogle af de idéer vi har haft tumlende både i vores hoveder og verbalt til vores møder. Det lykkedes dog at afgrænse os og vi mener vi har fået lavet en implementation, der er tilpas færdig til at den kan bruges som platform for videre udvikling, hvis vi eller andre får lyst til det. I forhold til at udvikle programmer der ikke skal forholde sig til ydre, diffuse inputs, har dette været en anderledes måde at lave programmer på. Hvor man ofte er vant til at man laver logiske fejl, har dette projekt været præget af at programmets ydeevne afhang af indstilling af parametre for at få hold på ustabile, og ofte utilregnelige inputs. Den fysiske verden er ganske rigtigt mere kompleks end dens vituelle pendant - men også på mange måder sjovere i kraft af uforudsigeligeheden og et mere håndgribeligt og ofte underholdende og overraskende resultat.

Anders Jacobsen
Martin Mortensen
Bjørn Petersen
Thomas Østergaard

Referencer

[1] Maja J Mataric, Behavior-Based Control: Examples from Navigation, Learning, and Group Behavior, Journal of Experimental and Theoretical Artificial Intelligence, special issue on Software Architectures for Physical Agents, 9(2-3), H. Hexmoor, I. Horswill, and D. Kortenkamp, eds., 1997, 323-336.

[2] Schopper 87, Chapman 89. See [1] for further reference.

[3]Sequential and reactive control strategies Chapter 5, pp.190-233 of Fred G. Martin, Robotic Explorations: A Hands-on Introduction to Engineering, Prentice Hall,2001.

[4] A Robust layered Control System For A Mobile Robot, Rodney A. Brooks, 1986