Teknoblog
Onsdag 2005-03-16 samlet vi oss igjen, først på Kattelabben (som
visstnok er for de tøffe guttene sammenliknet med Fiskelabben). Første
problem var at Dag Håkon hadde glemt strømadapteren til
mikrokontrolleren, så Stian måtte løpe og låne en tilsvarende adapter
ifra IT-seksjonen.
De som arbeidet med kontrolleren denne
dagen var Dag Håkon, Torbjørn og Stian. Hvis jeg husker rett. Egentlig
var vel Erlend og Andreas også involvert når ting begynte å bli
merkeligere.
Igjen kom vi bort i rare serieportproblemer. Vi
prøvde å dumpe dataene ifra kameraet, og på merkelig vis så ble dette
bare 1020 byte istedet for de ca 10.000 vi ventet. Alle iherdige forsøk
på å dekode dette med programmer som Photoshop eller Gimp viste seg
nyttesløse. I de tilfeller hvor man fikk et bilde ut dreide det seg om
enkeltstående linjer som hadde en fin gradering.
Videre
forsøk på å bare skrive ut "xxxxxxxx..." istedet for bildedata gav også
litt rare resultater, her fikk man istedet "abcdefgh..." - litt
merkelig. Mikrokontrolleren kan altså leve sitt eget liv. Det kunne i
det hele tatt virke som om denne såkalte kompilatoren syntes det var
helt OK å plassere flere variabler på samme minneområde, noe som førte
til litt merkelig programflyt og enda rarere resultater.
Utover
dagen satte vi oss på sanntidslabben, som var helt ledig. Her gjorde vi
to oppdagelser. Den ene var at vi målte med oscilloskopet (mest for
gøy) klokken på mikrokontrolleren. Istedet for 8 MHz var denne 3,71
MHz. En kamerat av Stian som var på labben kom bort og kunne bekrefte
at det hele nok kjørte på 3,71 MHz. Vi sjekket også opp databladene på
STK500 og STK501, og joda, ganske riktig. Dette 8 MHz-greiene må vi ha
innbilt oss.
Dette førte til at alle utregninger for
serieporthastighet var helt på syre. Ny kalkulasjoner ble utført, og nå
ble seriekommunikasjonen klokkestabil. Ikke et tegn gikk tapt, og alt
kom riktig frem. "Linjestøyen" var borte med en gang.
Det
andre tipset kom da Stian spurte om disse "High memory
address"-pinnene. Det var riktig at de skulle stå tilsluttet slik de
stod nå, det var nemlig slik at man kunne velge å bruke disse som
dataporter hvis man ikke hadde bruk for mer minne. Men den viktige
detaljen var at man også måtte koble til "SRAM enable"-biten. Den hadde
vi glemt!
Ved å koble til den så det ut til at ting fungerte
en god del bedre. Nå gikk både forsøk på å lagre "xxxx" og "abcdefg"
(denne gang med vilje) i det utvidede minnet kjempefint. Dog må man
selv fortsatt si char *image = 0x1100; - kompilatoren er fortsatt
helt på syre hvis man prøver seg på noe så naivt som char image[10000];.
Det
er fortsatt problemer, dog, denne gangen enda rarere. Når man bruker
read_image() istedet for å bare lagre "x"-er eller alfabetet, så
oppfører programmet seg merkelig. Enten henger det, eller så går det i
evig loop hvor den hopper tilbake til "Initialiserer"-biten. Dette
lukter at stacken er overskrevet eller noe sånt siden programflyten er
helt på syre. Jeg vet ikke om dette er innstillinger i kompilatoren
eller ikke.
Stian prøvde derfor såvidt å prøve å kompilere med avr-gcc istedet, men ble ikke ferdig med dette før dagen var slutt.
Tingenes tilstand
Etter en del arbeid har jeg fått i gang kommunikasjon mellom mikrokontroller og PC. Med 8MHz krystall kan en maks oppnå 500Kbps på UART. Med et annet krystall kan en klare det dobbelte. Jeg har også "oversatt" koden vi fikk fra Even til å kompilere i IAR. Neste trinn blir derfor å klare å koble de 20 speilvendte og motsatte pinnene fra kamera til rett port og pinne på mikrokontrolleren. Det er også naturlig å prøve å sette seg bedre inn i hva koden gjør dvs. hvordan den kommuniserer med kamera. Har en mistanke om at den koden vi fikk ikke er helt identisk med den de brukte til slutt.
Erfaringer
Mye av problemene jeg har hatt skyldes konfigureringsfeil og feil med programmer og komponenter. For eksempel viste det seg at Windows sin "hyperterminal" ikke altid virker som den skal (bombe!) og at jeg i stedet måtte bruke "Brays terminal" som er mer robust og har flere valgmuligheter. Et annet problem var at USB til RS232 omformeren jeg brukte og har betalt dyre penger for ikke klarte å overføre data korrekt. Resultatet ble at terminalen viste greske, latinske, matematiske og muligens kinesiske tegn når alt jeg la ut på UARTen var "hallo!"
Videre fremdrift
Jeg håper at vi i løpet av uken skal få et livstegn fra kamera. Det neste da blir å få denne informasjonen til å bli hentet inn i Matlab slik at vi kan vurdere bildekavilteten. For å bli mer effektive fremover mener jeg at det er like viktig med parallelle arbeidsoppgaver og konkrete mål som en diskusjon om hvem som skal være fast leder. Slik jeg ser det er det 5 arbeidsområder hvorav de tre første er viktigst :
1. Kommunikasjon mellom kamera og mikrokontroller og videre til RS232
2. Kommunikasjon mellom Matlab og mikrokontroller via RS232 og test av bildekvalitet og algoritmer
3. Programmering av Butterfly for menysystem, lagring av målinger og kommunikasjon med mikrokontroller knyttet til kamera
4. Utforming av "produktet" mht. design og praktisk håndtering av kamera og lyskilde.
5. implemetasjon av algorimte på mikrokontroller og kommunikasjon med Butterfly
http://www.ovt.com/pdfs/ds_note.pdf er beskrivelse av OmniVisions "Serial Camera control bus", SSCB.
Stian og Andreas satt og tok bilder med webcam, og så på histogram o.l. Disse avhenger ekstremt mye av lysforholdene, og det er vanskelig å lage noen generell algoritme som tar høyde for alle mulige forhold. Derfor må vi kontrollere lysforholdene på noen måter.
Vi tenkte på å bruke infrarøde leds til belysning, og å sette på et filter for å kun ta inn infrarødt lys på webkameraet, siden dette kan registrere lys like bra i dette spekteret (vi gjorde en test med mobilens infrarøde sender). Etter litt googling fant vi ut at man kunne eksponere en vanlig filmrull i 5 sekunder, og så fungerte den som et infrarødt filter.
Dag-Håkon foreslo også å bruke polariodfilter for å filtrere vekk gjenskinn i pupillen, da dette ødelegger veldig.
Stian og Andreas endte opp på å bruke en algoritme som antar at man befinner seg ett eller annet sted i pupillen i den midterste linjen, og å prøve å basere det på store endringer i naboverdier (type 70 av 255 nivå).
Diskuteres videre på mandag.
Jeg har fått et webcam ifra Arvid Staupe på IDI. Vi kunne bare
demontere det om vi følte for det, sa han. Jeg har ikke testet det noe
særlig, da det er et Creative Webcam NX Ultra, og dette ikke virker så
veldig bra i MacOS. Vi får se hva vi får til på mandag. Det så ikke ut
som om man kom helt nært til, så kanskje man trenger en makrolinse.
Jeg har også tatt et par bilder av meg selv med videokamera, her kom man helt nært. Se hvordan pupillen endrer seg!
Her er spectrum response for et av Microns kameraer, MT9V011:

Som dere ser går den også over 740 nm - på alle farvesensorene. Så
hvis man har et farvefilter som bare slipper igjennom infrarødt.. får
vi da det vi vil ha? Hvaslags bølgelengder har vi på infrarøde
LED-er og sånt? Og hvor høyt opp tar øyet imot lys? Se også wikipediaartikkel om det elektromagnetisk spekter.
Se også Microns dataark.
Jeg fant menneskeøyets spekter ifra Wikipedia-artikkel om farger:
Jeg har sett en del på nettet og funnet ferdige kit som bruker mikorkontrollere til å behandle bilder. Flere steder blir det hevdet at CMos er bedre å bruke enn CCD da en kan velge vilgen linje en vil lese av gjennom å skrive verdier til kontrollregister. Har også sett flere komplette kretskjema med camera og mikrokontroller som det ikke så for vanskelig å lage på et protoboard el. Det jeg ikke har funnet er Kamera med ir følsomhet, Kan jo være at de jeg har sett har noe følsomhet i IR området, men vi er avhengige av gode målinger før lys settes på øyet. Det kan også tenkes at aktiv IR belysning kan gjøre at en kan vurdere pupillestørrelse med øynene lukket..hadde i såfall vært noe helt nytt og øket anvendelsesområdet for produktet betraktelig.
-------------------
Andreas Nilsen wrote: Hei Vi lurte på om vi kunne få litt info om hvordan vi går frem hvis vi vil ha støtte til å kjøpe inn komponenter for å realisere oppgaven vår, samt litt mer om adgang til evt. lab'er/verksted. I følge planen tenkte vi å gå til innkjøp for ca. en høvding om et par uker. Er det noen mulighet for å koble oss mot komponentverkstedet på noen måte, kanskje ?
Med vennlig hilsen
Andreas Nilsen
Gruppe 4
-------------------
Spennende...
Gå frem: Det blir vel å snakke med meg, det
Jeg ville tro at et budskjett på 1000 skal ordne seg, men la meg få et totalbudskjett før vi tar avgjørelser.
Komponentlab'en. Ja, vi kan gjøre en slik kobling, men vi må avtale budskjettrammer med Per Inge Løvold før dere tar ut noe (dere må ha "kontonummer"). Småting ordner seg vel på verkstedet uten vidre, men det er høflig å spørre pent, og gå til meg om de er tilbakeholdne (Hvilket av verkstedene er dette ?)
La oss snakke om slike ting etter presentasjonen på onsdag ? Evt. vær konkret på hva dere trenger i neste mail ?
Sverre
På http://homepage.ntlworld.com/geoff.johnson2/IR/ kan man se hvordan man kan demontere et vanlig webkamera og gjøre det om til et IR-kamera ved å ta ut IR-blokk-filteret og sette inn IR-passthru-filteret (fremkalt film).
Vi kan prøve det samme på det webcamet som vi har fått, det fikk vi jo lov å demontere. Da har vi noe å skru på neste gang også! =)
Onsdag 2005-03-03, etter en sørgelig sesjon med "kreativitet", besluttet gruppen seg (hvor er den sterke lederen?) for å splitte opp. Stian og Dag Håkon gikk for å arbeide med mikrokontrolleren og prøve å få opp koden vi hadde fått.
Det som var hovedproblemet var at serieportkommunikasjon så ut til å svikte. Vi lastet opp ulike "Hello world"-aktige programmer og testet med ulike bitrater, men i alle tilfeller endte vi opp med ingen eller lite output i Windows' HyperTerminal, og i dette andre terminalprogrammet til Dag Håkon kom det mye interessant, men det så ut som om bitene kom i litt rar rekkefølge.
Vi brukte litt vel mye tid på å debugge dette uten å komme til noen løsning. Vi prøvde med ulike bitrater, paritetsinnstillinger, klokkefrekvenser, osv. Senere fant Dag Håkon ut at det måtte være den ene maskinen hans som var litt på syre, for på den andre maskinen funket det helt fint.
Vi brukte multimeter for å finne og merke kablingen ifra kamerachipen til inngangene på mikrokontrolleren. Vi fant ut at siden vi også vil ha SPI-kommunikasjon mot LCD må vi frigjøre de fleste pinnene på port B i forhold til slik fjorårets EiT hadde koblet kameraet til mikrokontrolleren. Dette ser ikke ut til å bli noe problem.
Vi la inn programmet for å hente ut bilder fra kameraet og sende dem over serieport. Det var ganske tydelig at det kom bildedata ut på serieporten, men iogmed at dataene ifra "Hello world" var bitforskyvd eller noe slikt ville det være litt håpløst å bruke bildedataene til noe.
From: aolsen@micron.com
Subject: RE: Infrarød bildesensor, utviklersett
Date: Wed, 2 Feb 2005 17:08:24 +0100
To: <stian@soiland.no>
Thread-Topic: Infrarød bildesensor
Hei,
Beklager sen response, men jeg har vært svært opptatt siste tiden.
Jeg er temmelig sikker på at standardutgavene er uten IR-filter. Disse vil være følsomme for "nær IR", særlig de uten fagrefilter. Jeg foreslår at du går inn på www.micron.com/products/imaging/ og finner en passende monochrome sensor.
Det er lettere å svare på tekniske spørmål og pris når du har funnet en sensor, men grensesnittet er vanligvis parallell RGB og LVDS.
For demosystemet er det flere muligheter f.eks. USB. Lukkertider og mange andre parametre for sensorene kan kontrolleres.
Hvor lenge trenger dere demosystemet? Vanligvis er 2 uker greit. Ellers kan det kjøpes ( ~900$).
I tilfelle lån til universiteter som ikke resulterer i salg, pleier man å sette krav om at Micron nevnes i publikasjoner og at noen fra Micron leser gjennom før publikasjon. Dette for å forhindre negativ reklame.
Mvh
Alf
-----Original Message-----
From: Stian Soiland [mailto:stian@soiland.no]
Sent: Monday, January 24, 2005 5:58 PM
To: aolsen
Cc: teit@org.ntnu.no
Subject: Infrarød bildesensor, utviklersett
Hei!
Jeg fikk navnet ditt av Magnus Nordseth, som tipset om at dere kunne ha
noen bildesensorer som er følsomme i IR-området.
Vi er 5 studenter på NTNU innen ulike teknologiske retninger. I år er
vi med på et såkalt tverrfaglig prosjekt som heter Eksperter i Team [1]
(EiT). Et av målene med samarbeidet i EiT er å sammen komme frem til en
løsning for et definert problem.
Vår gruppe [2] har valgt å utvikle en prototype for en enhet som kan
brukes i medisinsk sammenheng for å måle størrelsen på pasientens
pupiller, reaksjonstid og forandring i størrelse når øyet utsettes for
lys.
Vi har kommet frem til at en teknisk mulighet for å gjøre dette er å
bruke en infrarød bildesensor, ta flere bilder av øyet, og deretter
bruke bildebehandling til å analysere pupillens størrelse og endring.
Årsaken til at vi ønsker å bruke en infrarød sensor er at vi da kan
belyse øyet infrarødt uten å påvirket pupillens størrelse. Til vår
prototype vil vi gjøre bildebehandlingen på en PC, men for det
foreslåtte endelige produktet vil vi sannsynligvis spesifisere en
mikrokontroller- eller ARM-basert løsning.
Vi trenger ikke særlig høy oppløsning på bildesensoren, en oppløsning
på 640x480 vil f.eks. være mer enn godt nok. Det som dog vil være
interessant er hvor ofte man kan ta bilder, iogmed at vi vil måle
pupillens responstid.
Vi lurer derfor på om Micron har infrarøde bildesensorer, og om det
isåfall er mulig for oss å få låne et utviklersett?
Vi lurer også på et par detaljer om Microns bildesensorer:
* Hvaslags tilkobling? Er det USB? Hvilke andre muligheter har man for
å koble mot mikrokontrollere?
* Hvaslags programmeringsmuligheter har man? Finnes det et API i C?
Finnes det bindinger mot Matlab? Hvilke muligheter har man her for å
stille f.eks. "lukkertid"?
* Hvor meget vil en slik infrarød bildesensor sånn ca. koste for et
tenkt produsert volum på 100.000 enheter?
[1] http://www.eit.ntnu.no/
[2] http://org.ntnu.no/teit/
--
Stian Søiland You can't say civilization don't
Trondheim, Norway advance, however, for in every war
http://www.soiland.no/ they kill you in a new way. [Rogers]
=/\=
Fikk på torsdag endelig huket tak i en professor innen optikk/fotonikk, Dag Roar Hjelme, og spurt litt om det vi lurer på. Han mente at det skulle la seg gjøre å måle diameteren på pupillen ved hjelp av lys, og foreslo også en metode.
En lar to infrarøde kilder (lys-dioder) projisere to lysstriper på pupillen og plukke opp det reflekterte signalet vha detektorer. Da en vet avstanden mellom disse stripene vil det la seg gjøre å regne ut hva diameteren på pupillen er på det bredeste, gitt at en treffer pupillen med begge stripene, noe som skulle være særlig vanskelig.
Metoden skulle være forholdsvis enkel, og komponentene er ikke særlig dyre. Det var vel snakk om toppen et par hundre ifølge Hjelme. Det vanskelige er å kunne plukke ut og bestemme hva som er hva av signaler fra detektorene. Dette er noe jeg ikke har vært borti før, men det skulle la seg gjøre. Det er jo bare to analoge siganl en kan kjøre inn på en A/D-omformer.
Tror likevel at et kamera er veien å gå for oss, men vi kan jo ha med en liten utredning av muligheten for bruk av lys-metoden. Kamera-metoden, og kameraets samhandling med datamaskin/mikrokontroller er jo noe flere på gruppa har peiling på, så det blir jo greiere sånn sett. Men lys-metoden ville kanskje gitt en litt mer praktisk utfordring, og ikke bare databehandling. Vi får se..., men tror likevel vi velger kamera.
Det er vel slik at med 6milliarder mennekser på kloden så har mange tenkt samme tanker som oss tidliger. En kar jeg snakket med hadde planer om å ta patent på en dings som gjorde at dolokket spratt opp igjen etter bruk. Etter et raskt søk i patentdatabasen fant han flere hundre registrerte patenter som skulle løse det samme livsviktige problemet med dolokket.
Her er noen lenker:
http://www.tidsskriftet.no/pls/lts/pa_lt.visSeksjon?vp_SEKS_ID=1126183
http://murray.newcastle.edu.au/users/students/2000/c9700402/AlanWeb/PupillometerDesign.htm
http://ieeexplore.ieee.org/search/wrapper.jsp?arnumber=73509
http://www.spie.org/scripts/toc.pl?ab=&journal=SPIE.&volume=3908
Dag-Håkon