Med Asbjørn, Christer og Jesper

torsdag den 24. januar 2008

Projekt, closing words...

Vi er nu færdige med projektet og har afleveret robotten og de udleverede kasser med stumper.
Vores sidste youtube-video kan ses nedenfor. Nu er det spændende om den kan tiltrække samme mængde seere som den tidligere (pt 55000+ views).


Til særligt interesserede ligger kildekoden her.

Da vi sendte den nye ColorSensor-klasse til leJOS, blev vi opfordret til at skrive et indlæg i deres forum om projektet. Det ligger her.

Tak for nu.
That is all.
Dismissed!

tirsdag den 15. januar 2008

Projekt, møde 8, 9, 10 og 11

Dette blogindlæg dækker over torsdag og fredag i uge 2 samt mandag og tirsdag i uge 3.
Deltagere: Asbjørn, Christer og Jesper
Tidsforbrug: 4 x 6-7 timer

Et samlet program for disse møder har været
  • Fix af "defekt" farvesensor
  • Optimering af løsningsalgoritmen
  • Samle de forskellige elementer i problemløsningen
  • Finjustering af maskinen
  • Håndtering af mekaniske fejl undervejs
Disse vil vi her gennemgå et for et.

Fix af "defekt" farvesensor
Torsdag havde vi pludselig en fejl på vores ene farvesensor. Vi kunne registrere at den var sat til, men den målte alt som sort. Kabelfejl og fejl i NXT'en blev hurtigt udelukket. Ligeledes opdagede vi at en anden gruppe havde en sensor der ikke kunne måle blå, men rapporterede det som grøn i stedet. Hvis 2 ud af 5 indkøbte sensorer er i stykker, er det en uacceptabel fejlrate. Derfor gik vi igang med at undersøge om det kunne være et konfigurationsproblem. En internetsøgning fortalte os at det skulle være muligt at kalibrere hvid- og sortniveau for hver farvekomponent, men producentens hjemmeside, hitechnic.com, indeholdt ingen information om dette. Den indeholdt til gengæld information om i hvilke registre man kan læse rå 10 bit værdier for de tre farver. Da disse værdier viste sig at være normale i de "defekte" sensorer, lå det klart at problemet lå i sensorens omregning til 8 bit værdier (hvor det er meningen at den skal lave omregningen ud fra hvid- og sortniveau grænser).
Det tætteste vi kom på en løsning i dokumentationen var, at sensoren har et command register på adressen 0x41, men det står kun beskrevet som "reserved for future use". Vejen frem var derfor at prøve sig frem. Register 0x41 er tilsyneladende generelt til styring af tilstand i de forskellige i2c sensorer til NXT'en. På siden om Hitechnics kompas-sensor kunne man læse at den kunne sættes i kalibreringstilstand ved at skrive værdien 0x43 til register 0x41. Dette prøvede vi med farvesensoren og kunne konstatere, at vi nu kunne indstille hvidniveau. Efter at lege lidt med forskellige værdier, kunne vi desuden se at vi ved at skrive værdien 0x42 kunne indstille sortniveau. Disse resultater endte med at vi lavede vores egen farvesensor driver i leJOS, baseret på den (meget skrabede) eksisterende, samt et lille program til at kalibrere med.
Når man indstiller hvidniveau skal sensoren holdes 1.5 cm fra et hvidt stykke papir hvorefter man starter kalibreringen, der er færdig når sensoren blinker. Når man indstiller sortniveau (eller ambient light niveau), skal sensoren holdes så den peger ud i luften. Herefter er fremgangsmåden den samme som for hvidniveau.

Optimering af løsningsalgoritmen
Dette er en fortløbende indsats. Vores algoritme er sådan set funktionel, men selv små ændringer i antallet af træk kan betyde flere minutters forskel i udførselstiden.
[Christer kan evt skrive mere her]

Samle de forskellige elementer i problemløsningen
Vi har indtil nu udviklet og testet de forskellige komponenter hver for sig. Nu er det på tide at samle dem og teste en kubeløsning fra ende til anden. Indledende forsøg har været lovende. Med ganske lidt hjælp undervejs lykkedes det maskinen at scanne og løse en kube. Det tager godt nok 15-20 minutter, men det virker.
Det er planen at en videooptagelse af hele processen skal lægges online. Vores seneste video har efter en uge på youtube.com genereret over 8700 views! Næste alle disse kom i løbet af søndag og mandag. Tilsammen har vores 3 LEGO-videoer i skrivende stund været set lidt over 10000 gange.

Finjustering af maskinen
Vi har stadig problemer med mekanisk slør i maskinen. Enkelte gange twister den ikke helt korrekt, hvorefter kuben låser i det følgende twist og blokerer maskinen.
[Jesper kan evt skrive mere her]

Håndtering af mekaniske fejl undervejs
Som beskrevet i ovenstående afsnit har vi lidt problemer nu og da. Vi har lavet en todelt fejlhåndtering. For det første har vi ændret motorstyringen, så den stopper og kører lidt tilbage hvis den "mærker" at den sidder fast, f.eks. når den twister. Dette kan den observere ved at holde øje med tachocounteren i motoren mens den kører. Hvis en motor pludselig kører meget langsommere end den skal, er det et tegn på at den sidder fast. Så pauser maskinen indtil situationen er udbedret og den sættes igang igen. For det andet har vi benyttet vores sidste sensorindgang til at tilkoble en touch-sensor, som vi har lavet til en stor rød "panik-knap". Når man trykker på denne, stopper maskinen på samme måde som hvis den selv opdager et problem.
I løbet af tirsdag fik vi desuden tilføjet aktiv fejlkorrigering. Hvis den under et twist sidder fast, vender den kuben og forsøger at "tumle" med kuben der hvor den låser, hvorefter den forsøger at twiste igen.

tirsdag den 8. januar 2008

Projekt, møde 7

Deltagere: Asbjørn, Christer og Jesper
Tidsforbrug: 7 timer (9-16)

Målet med dagens session er, at:
  • Fortsætte arbejdet på en løsningsalgoritme
  • Kunne scanne kuben til vores datastruktur
  • Diverse hardwareforbedringer
  • Aftale næste mødetidspunkt
Fortsætte arbejdet på en løsningsalgoritme.
Dette er vores vigtigste punkt på dagsordnen. Det har vist sig vanskeligere end ventet at konstruere en sådan algoritme. Derfor er to af os sat på denne opgave. Vi nærmer os efterhånden en løsningsmetode, men som det ser ud nu, bruger den alt for mange træk. Det har været en god ide at adskille løsningsalgoritmen fra NXT hardwaren. Debugging på en pc med en grafisk repræsentation af kuben (og ikke mindst flere clockcykler og mere ram at tage af) har lettet arbejdet.

[En eller anden: Indsæt screenshot af vores tool]

Kunne scanne kuben til vores datastruktur
Som beskrevet i vores sidste indlæg, virker farveindlæsningen rimelig pålidelig. Derfor har en del af dagens opgave været det videre arbejde med denne indscanning. Problemet er todelt. For det første skal vi have en automatisering indscanning, der hurtigst og/eller enklest muligt fører farvesensorerne forbi samtlige felter på kuben mindst én gang. For det andet skal vi kunne skelne mellem de forskellige RGB-indlæsninger og putte dem i 6 "kasser" der hver svarer til en side på kuben.
Det første delproblem er forholdsvis enkelt. I vores datastruktur CubeRepresentation kan man indsætte felterne enkeltvis. Koordinater i datastrukturen beregnes ud fra hvilken farve det midterste felt på siden der scannes har, samt farven på det midterste felt i siden der ligger opad. Ud fra disse to og et sæt xy-koordinater, indsættes 6 farver pr scanne-pass.
Aller først scanner maskinen det midterste felt på siden. Kuben bliver da roteret 90 grader mod uret og tiltet, hvilket betyder at vi nu kender farven på midterfeltet der peger opad. Herefter scanner vi 4 sider og drejer kuben 90 grader hver gang. Når vi er nået hele vejen rundt, tiltes kuben. Da vi lige har scannet de fire sider, kender vi igen midterfarven opad. Efter at have scannet 4 runder med tilt imellem hver har vi et komplet (og nogle steder ret redundant) billede af kuben indlæst. Vores eksperimenter viser os, at indscanne-fasen af løsningsprocessen tager under 2 minutter, hvilket er meget rimeligt.
Det andet delproblem er konceptuelt enkelt, men der skal flere eksperimenter til før vi kan stole på den aktuelle løsning. I løbet af en indscanning kommer vi i besiddelse af 6 * 9 = 54 RGB-værdier, men algoritmen skal bruge index-værdier fra 0 til 5. Altså skal vi bestemme hvilken farve en RGB-måling passer med. Første version af løsningen benytter en liste af reference-RGB-værdier, der er målt i maskinen. For hver ny måling beregnes afstanden mellem den og hver af reference-værdierne i et 3-dimensionelt RGB rum. Herefter vælges den reference-farve, der er kortest afstand til. Denne metode virker det meste af tiden, men der har vist sig små fejl hist og pist. F.eks. er metoden afhængig af, at lyset ikke ændrer sig for meget mellem måling af referencepunkter og de rigtige målinger. Derfor vil vi ved næste møde afprøve en form for clustering af målepunkterne. Desuden vil vi også indføre et mindre sanity check af målingerne. På den måde kan NXT'en med det samme afgøre om de registrerede farver repræsenterer en lovlig/mulig tilstand af kuben. Hvis det ikke er en sådan tilstand, er der nok fejl i indscanningen og NXT'en kan da forsøge at scanne kuben en gang mere. Mere om det i næste blogindlæg.

Diverse hardwareforbedringer
Griberen har fået en mindre overhaling, da den var for spinkel. Under kørsel (herunder farvemåling) stod den og vippede. Ustabilitet kan have negativ indflydelse på pålidelige farvemålinger. Løsningen har været at spænde motoren bedre fast, samt at stabilisere konstruktionen af armen i enden modsat griberen.

Næste møde
Torsdag

mandag den 7. januar 2008

Projekt, møde 6

Deltagere: Asbjørn, Christer og Jesper
Tidsforbrug: 7½ timer (10-17:30)

Målet for dagens session er at:
  • Opbygge et abstraktionslag mellem algoritmen og motorstyringen.
  • Arbejde med farvesensoren.
  • Påbegynde arbejde på løsningsalgoritmen
  • Påbegynde arbejde på scanner
  • Aftale næste møde
Abstraktionslag mellem algoritme og motorstyringen.
Vi er interesserede i at kunne oversætte et træk fra algoritmen til en sekvens af træk med motorerne. Algoritmen skal i forvejen holde styr på kubens tilstand, men den har ingen ide om hvordan kuben ligger i hardwaren og hvordan den manipulerer med hardwaren. Det er op til abstraktionslaget at varetage disse to opgaver.
Som test af vores abstraktionslag satte vi kuben i en kendt tilstand og lod programmet oversætte løsningen til motor-træk. Resultatet ses i følgende video:


Arbejde med farvesensoren.

Som tidligere beskrevet er farvesensoren rimelig god, men der er undtagelser. Et par ret bemærkelsesværdige af disse er:
  • Den har meget vanskeligt ved at se de blå og de grønne felter på kuben.
  • Den kan overhovedet ikke se en almindelig grøn LEGO klods.
Dog har den ingen problemer med et stykke grønt papir. Vi mistænker det flourescerende lys i Zuse, da det virker bedre ved vinduerne, hvor der er dagslys.

Great success! Nu virker det. Det viser sig at farvesensorerne virker meget bedre hvis der er en lille glødepære der belyser området som sensorerne måler på. Derfor har vi monteret en RCX pære mellem vores sensorer. Vi har desværre ikke nogen ledige motor-udgange til at trække strøm fra, men hvis vi aktiverer en af vores ubrugte sensor-indgange, er strømmen i den lige akkurat stærk nok til at drive en pære. Den lyser svagt, men det er tilstrækkeligt. Nu får vi ganske pålidelige målinger uanset belysning og kubens placering i slæden.



Påbegynde arbejde på løsningalgoritmen
Nu hvor hardwaren og hardwareabstraktion er ved at være på plads, kan vi vende fokus mod kernen af problemet. En hurtig Google søgning giver flere forskellige løsningsmetoder. Disse rangerer fra forholdsvis enkle, men tids- eller trækmæssigt uoptimale metoder til højt specialiserede systemer, der involverer store lookuptabeller. Vi har ikke specielt meget ram i NXT'en og vi ønsker generelt at holde kompleksiteten i skak. Mere om dette senere når vi kommer længere...

Påbegynde arbejde på scanner
Dette er en af de sidste dele af projektet. Som beskrevet ovenfor i dette blog-indlæg, er lyssensorerne ved at være på plads. Som noget af det sidste i dagens session lykkedes det at scanne 2x3 felter på en side. Der er stadig småproblemer, men dem regner vi med at udbedre næste gang vi mødes. Det er planen at maskinen selv skal rotere og scanne alle sider før den går igang med løsningsprocessen. Under selve løsningen holder algoritmen styr på kubens tilstand, hvorfor det ikke er nødvendigt at scanne flere gange.

Næste møde
Tirsdag kl 9

fredag den 4. januar 2008

Projekt, møde 5

Deltagere: Asbjørn, Christer og Jesper
Tidsforbrug: 7 timer (9-16)

Hardwaren er nu rimelig komplet. Forhåbentlig drejer det sig kun om småting på den front fra nu af. En enkelt ting vi besluttede os for at rette i hardwaren var drivmekanismen i slæden. Den har en lille smule slør som gør at vi en gang imellem ikke drejer kuben præcis 90 grader. Det er et snegledrev hvor sneglen har mulighed for at forskyde sig en smule langs dens aksel. Vi har adresseret problemet ved at holde sneglen fast ved at indsætte en elastik som afstandsstykke på akslen.

Efter operationen var vi nødt til at kalibrere konstanterne for rotation i softwaren. Det viste sig desværre at denne løsning ikke var tilstrækkelig robust, hvorfor vi ændrede den igen. Det er ikke nemt at finde afstandsstykker med lidt "skæve" længder, men vi fandt heldigvis en type tandhjul vi kunne bruge i stedet.





Hvis vi antager at hardwaren er tilstrækkelig komplet nu, er de resterende opgaver i projektet som følger:
  • Konstruktion af en passende datastruktur for en kube
  • Fastlægge yderligere mødetidspunkter
  • Visualisering af kuben når vi simulerer løsning på pc
  • Løsning af kuben i software
  • Analyse af lyssensoren
  • Mekanisk løsning af kuben
  • Automatisk indscanning af kuben
  • Rapportskrivning
Vi begyndte med det samme med første punkt.

Konstruktion af en passende datastruktur for en kube
Vi havde ingen klar ide om hvordan man bedst repræsenterer overfladerne af kuben i NXT'ens hukommelse. Der er flere udfordringer. Siderne afhænger af hinanden når man roterer dele af kuben. Hvis man f.eks. roterer en ende, følger 1/3 af felterne på de 4 tilstødende sider med rundt. Desuden har har vi en ret begrænset mængde ram til rådighed. Det betyder at vi skal holde kompleksiteten i koden og i datastrukturen på et minimum.
For at brainstorme satte vi os hver for sig og implementerede hver en måde at repræsentere kuben på. To af løsningerne var "side-orienterede" og repræsenterede kuben som 6 sider med 3x3 felter der har nogle bestemte forhold til hinanden ved hjælp af bl.a. lookup tabeller, mens den tredje var "kube-orienteret" og betragtede kuben som en container for 27 små kuber, hver med information om farverne på deres sider. Når man deri vil rotere en ende, roterer man først de 9 involverede små kuber hvorefter man flytter dem. Vinderen blev en af de side-orienterede løsninger.

Fastlægge yderligere mødetidspunkter
Vi aftalte at mødes igen mandag kl 10.

Visualisering af kuben når vil løser den på pc
Vores arkitektur er konstrueret således at repræsentation og løsning af kuben er adskilt fra NXT-specifik kode. Derved kan vi simulere en kubeløsning på en pc og se resultatet på skærmen. Altså kan vi udvikle og teste løsningsalgoritmen uden at være afhængige af robotten.