TFE4850 Eksperter i Team - Studentsatellitt Infrarødt kamera Prosjektrapport

Transkript

1 TFE4850 Eksperter i Team - Studentsatellitt Infrarødt kamera Prosjektrapport Eirik Marthinsen Geir-Arne Fuglstad Jørn Skogsrud Magnus Botnan Sindre Hansen 5. mai 2010

2 TODO: Bør skrive noe her Sammendrag

3 Innhold 1 Innledning 4 2 IR-kamera IR-kamera Hva er IR? Hvordan fungerer et IR-kamera? Hva kan vi bruke IR til? Hvilken nytte har dette? Brennvidde vs. sensorstørrelse Kritisk feilanalyse Objektiv Termografisk kamera Bruksområder Nær-infrarødt kamera Bruksområder Satellitteori Plassering av bilde Baneteori Solsynkron bane Tidskorreksjon Numerisk beregning Nettløsninger Hjemmeside En praktisk beskrivelse av hjemmesiden Hva er en god hjemmeside? Forsiden: Brukerens første møte med IR-Earth Bildesøk: Nettsidens viktigste del Øvrige deler av siden Den tekniske delen ved utvklingen av hjemmesiden Kravspesifikasjoner Databaser Nettsiden Fra server til applikasjon: Unix-skript D-fremvisning

4 4.4.1 Krav Muligheter Nødvendige Java-biblioteker Java 3D Utplassering av bilder Rotasjon Henting av bilder fra database Resultater Realisering av kameraprototype Mikrokontroller Kode Lysfilter Strømforsyning Objektiv Applet Implementasjon Nærmeste-nabo interpolasjon Overføringshastighet Diskusjon Kameraprototypen Hjemmesiden Applet Konklusjon 37 Bibliography 41 A Datablad for IR-kamera 41 3

5 Kapittel 1 Innledning Faget Eksperter i Team ble opprettet i 2001 som et svar på næringslivets ønsker om studenter med mer erfaring fra tverrfarlig samarbeid. Et stadig økende krav til spesialisert kunnskap og økende kompleksitet i prosjekter har ført til at erfaring, kunnskap om og evne til tverrfaglig samarbeid har blitt et viktig fokuspunkt. EiT ble arrangert for 10. år på rad våren 2010 med 1642(NTNU[19]) studenter fordelt på 61 landsbyer, hver med et eget tema. Vår gruppe(ir-earth) var en del av Studentsatellittlandsbyen og besto av fem medlemmer. Studentsatellitt er et større prosjekt som også har inkludert prosjekt- og masteroppgaver, og bidrag gjennom EiT har vært en relativt viktig del av dette prosjektet, både som problemløsing og introduksjon for studenter som senere velger å fordype seg i studentsatellittprosjektet. Nasjonalt senter for romrelatert opplæring(narom) var ekstern kontakt for vår landsby. Det er tenkt at studentsatellitt skal følge CubeSat-standarden. Denne standarden er utviklet ved California Oplytechnic State University(CubeSat[21]). Den gir en billigere og enklere måte for NTNU å utvikle og få sendt opp en satellitt, enn å måtte designe en slik standard selv. I denne forbindelse så vi på en type nyttelast for en slik type satellitt. Vi valgte å jobbe med et prosjekt om hvordan et IR-kamera kan brukes på en studentsatellitt. Vår problemstilling var Vurdere muligheten for å sende opp et IR-kamera og bruke det til å ta bilder. Videre se på muligheten for å sende disse til bakkestasjon på jorden og vise bildene på en hjemmeside. Med denne problemstillingen ønsket vi å velge en bredere oppgave enn bare å se på den tekniske delen av kameraet. Dette er fordi det i tillegg ga oss muligheten til å se på hvordan slike data kan gjøres tilgjengelig for folk flest, og på den måten skape interesse for dette prosjektet også utenfor studentsatellittmiljøet. Siden Kamera-Gruppen som var på samme landsby som oss, valgte å blant annet å se på overføring av bilder fra satellitt til bakkestasjon, valgte vi å fokusere på selve IR-kameraet og en nettløsning for å vise de. I hovedsak jobbet tre personer med selve kameraet og posisjonering av satellitten, mens to personer hadde hovedansvaret for nettløsning. 4

6 Kapittel 2 IR-kamera 2.1 IR-kamera Hva er IR? Infrarød stråling (IR) er elektromagnetisk stråling med bølgelengde mikrometer. Sensitiviteten til menneskets øye for elektromagnetisk stråling faller raskt når bølgelengden blir over 700nm, så for det blotte øyet er ikke infrarød stråling synlig. Forskjellige elektroniske sensorer kan derimot oppfatte infrarød stråling, noe som gjør at man kan ta bilder med lys fra det infrarøde spekteret mye på samme måte man tar vanlige fotografier. IR kan også brukes når det er lite eller ikke noe synlig lys til stede, noe som blir utnyttet til flere formål, blant annet innen overvåking og militæret. Alle objekter gir fra seg svartkroppstråling i et spekter definert av temperaturen til legemet, noe som gjør at man ved hjelp av et termografisk kamera (et IR kamera som er følsomt for de frekvensene som sendes ut ved svartkroppstråling ved romtemperatur) kan se temperaturen til omgivelsene. Dette er noe av det som danner basisen for at det er interessant å sende opp satelitter utstyrt for å oppfatte infrarød stråling Hvordan fungerer et IR-kamera? IR-kameraer kan hovedsaklig deles inn i to kategorier, kjølte og ukjølte kameraer. Disse opererer på helt forskjellige måter. Et kjølt IR-kamera fungerer stort sett på samme måte som et kamera for synlig lys, bortsett fra at frekvensområdet er i den infrarøde delen av spekteret. Virkemåten her er at fotonene eksiterer elektonene i halvlederen ut av valensbåndet og lager en strøm som kan registreres. Forskjellen ligger i at energien til fotonene i IR-spekteret er så lav at den termiske energien ved romtemperatur vil overdøve signalet. Derfor trengs det aktiv kjøling av sensoren for å få et tilfredsstillende støy/bilde-signal. Et slikt system er relativt plass- og energikrevende, og derfor dårlig egnet til bruk på en cubesat. Halvledere som har lite nok båndgap til at IR-stråling skal klare å eksitere elektronene er også meget dyrt, og masseproduseres ikke på samme skala som silisium. 5

7 Et ukjølt IR-kamera fungerer ved at varmeenergien fra IR-strålingen treffer et pyroelektrisk eller ferroelektrisk materiale, eller et mikrobolometer, som igjen gir en forandring i motstand, spenning eller strøm som kan detekteres. Det er forskjellig prinsipp fra de kjølte IR-sensorene ved at fotonene ikke slår løs elektronene direkte. Ukjølte sensorer har ikke samme krav til temperaturregulering som de kjølte sensorene, og trenger heller ikke lages av like eksotiske materialer. Til gjengjeld har ukjølte sensorer mye lavere nøyaktighet og følsomhet, men i en cubesat vil ikke dette være et stort ulempe da mengden data som kan overføres er meget begrenset Hva kan vi bruke IR til? IR-bilder og -video er relativt utbredt innen overvåkning og innbruddsalarmer. Mindre IRkameraer har også utbredelse innen brannvesen hvor det brukes for å få oversikt over branner, innen bygningsbransjen hvor det kan brukes for å kontrollere isolering og finne hot spots og flere andre bruksområder. Mer avanserte og høyoppløste IR-kameraer, samt kameraer som kan oppfatte både deler av det synlige og infrarøde spekteret brukes i det militære for overvåkning og samling av informasjon, og er ofte eksportbegrenset. IR-bilder brukes også innen meterologi og klimaforskning for å overvåke blant annet skyer og havstrømmer, og det er dette som er det mest interessante bruksområdet for thermografiske kameraer i satellitt Hvilken nytte har dette? Ved å kunne skyte opp flere og billigere satellitter utstyr med IR-følsomme kameraer kan man få oftere oppdatert og mer detaljert meteorologisk data. Ved å finne billigere metoder for å samle data kan man samle inn større mengder data og bruke dette til å lage mer pålitelige værmeldinger, samt gi større muligheter til overvåkning av blant annet værfenomener som orkaner. Mer data om havstrømmer og skyformasjon/bevegelse kan også være med å på lage bedre modeller for klimaet/global oppvarming Brennvidde vs. sensorstørrelse De fleste som har drevet med fotografi er vant til at fokallengden til objektivet tilsvarer en bestemt field of view. Dette er sant når man snakker om et system med fast størrelse på bildebrikken/filmen, men et IR-kamera i en satelitt vil gjerne bruke sensorer som har betydelig mindre fysisk størrelse enn 35mm-formatet som har vært standard på filmkameraer. Fordelen med å bruke mindre sensorer er at man kan få et mindre field of view ved samme fokallengde, samt at objektivene ikke trenger å projisere bildet over et like stort område. Forholdet mellom Angle of view og brennvidden kan beskrives vha ligningen α = 2 arctan d hvor α er vinkelen 2f på synsfeltet, d d er diameteren på sensoren og f er fokallengden. Ut fra denne ligningen ser vi at hvis vi har små sensorer med liten d kan vi bruke mye kortere fokallengde og allikevel få like stor eller like liten synsvinkel som hvis vi skulle brukt en større sensor og lenger fokallengde. 6

8 Kategori Følger Tabell 2.1: lol1 1 Katastrofiske feil, eller tap av redundans eller evne til å oppdate feil som kan føre til katastrofiske feil 2 Tap av evne til å gjennomføre oppdrag, eller tap av redundans som skal forhindre tap av evne til å gjennomføre oppdrag 3 Senket evne til å gjennomføre oppdrag 4 Mindre feil, ikke relevant for gjennomføringen av oppdrag Kritisk feilanalyse Når man designer instrumenter som skal være del av en satelitt er det viktig å kartlegge hvilke komponenter som kan feile, hvordan de kan feile, og hva som eventuelt blir konsekvensen av dette. Etter at en satellitt først har blitt skutt opp i rommet er det ingen mulighet for reparasjoner eller vedlikehold, så alt må virke som det skal fra begynnelsen. For å gjøre dette vanskelig er oppskytningen en relativt stor fysisk påkjenning, og i rommet blir elektronikken utsatt for store mengder stråling. Dette gjør at komponenter kommer til å slutte å virke før eller senere, og det er viktig å tenke på dette i designet av både hardware og software i satellitten. Failure Modes, Effects, Criticality Analysis er betegnelsen på et bottom-up, induktivt system for å skaffe en oversikt over potensielle problemer, sannsynligheten for at de inntreffer, og konsekvensene dersom de gjør det. Feilene rangeres så etter hvilke konsekvenser de vil ha dersom de inntreffer, slik at man kan dirigere ressurser og prioriteringer der de vil ha mest nytte. Kritisk feilanalyse kunne blitt viet mye større oppmerksomhet, og ført til relativt lange teoretiske utredninger, men denne rapporten vil kun inneholde en relativt kort oppsummering da det finnes flere forskjellige standarder på området. Alvorlighetsgraden av feil på komponenter kan deles inn etter flere forskjellige systemer, men en grov inndeling etter en amerikansk standard (MIL-STD-882) kan en se på figur 2.1. Feil som kan påvirke et eventuelt kamera i satellitten kan f.eks være som i figur 2.2 Ved konstruksjon av en potensiell satellitt bør kritisk feilanalyse utføres for alle delene av satellitten. Ulempen med et slikt system er imidlertid at det er meget arbeidskrevende, og må utføres for et stort antall trivielle situasjoner. På en annen side er kostnadene for arbeid på satellitten før den sendes opp relativt liten i forhold til kostnaden ved funksjonsfeil etter at satellitten har blitt skutt opp. 2.2 Objektiv En optisk linse brukes for å bryte innkommende lys slik at det vises på bildesensorbrikken til kameraet. For å få et godt bilde må bildebrikken være i riktig avstand fra linsen slik at alle stråler fra et spesifikt punkt på objektet det taes bilde av brytes til samme punkt på bildebrikken (se figur 2.1). 7

9 Tabell 2.2: lol2 Komponent Årsak Alvorlighetsgrad Sensor Gradvis degradering over tid 3 eller 4, avhengig av levetiden på sensor og satellitt Sensor Manglende output, fysisk skade eller tap 2 av strømtilførsel Kameramodul Kortslutning eller åpen krets 1 eller 2 avhengig av hvor robust resten av systemet er. Dersom satellitten har flere oppdrag, bør denne ikke være høyere enn 3 Kameramodul Null output 2 Kameramodul Lyslekkasje 3 Kameramodul Tap av struktural integritet 2 eller 3, avhengig av konstruksjonen Figur 2.1: Brytning av lysstråler fra samme punkt på objektet Noen viktige begrep: Fokalpunktet: Midtpunktet i bildesensorbrikken. Brennvidde (også kalt fokallengde): Avstanden mellom det optiske senteret i objektivet og fokalpunktet. Dette bestemmer bildevinkelen. Kortere brennvidde gir videre bildevinkel. Blendeverdi (F/#): Skrives som en brøk der telleren angir objektivets brennvidde (F) og nevneren er tallet som fremkommer ved å dividere objektivets brennvidde med diameteren på den største optiske blenderåpningen. Jo lavere tallet i nevneren er, jo mer lys kan objektivet slippe i gjennom på fokalplanet. 8

10 2.3 Termografisk kamera Infrarøde kameraer brukes ofte i industrien til termografi, det vil si avlesning av temperatur på en overflate. Dette kan være nyttig for å avdekke varmetap i bygninger, varmgang i elektriske anlegg eller andre formål der temperatur har en vesentlig innvirkning. Disse kameraene oppfatter IR-stråler med bølgelengder på typisk mikrometer. Termografiske kameraer kan deles opp i to hovedtyper [9]: Termografisk kamera med avkjølt bildesensor. Termografisk kamera uten avkjølt bildesensor. Avkjøling av bildesensorene brukes for at bildene ikke skal påvirkes av sensorens egne varmeutvikling. De bruker typisk mer plass, strøm og tid for å ta bilder sammenlignet med kameraer uten avkjøling. Til gjengjeld gir de bedre bilder og gir mulighet for å bruke linser med større blendeverdi (se kapittel??). Dette gjør det mulig å lage mindre og billigere høykvalitetslinser med lengre fokallengde. Et av kameraene vi fant på markedet var Miricle Microcam fra Thermoteknix Systems Ltd. A. Dette hadde følgende spesifikasjoner. Har ikke avkjølt bildesensor. Videokamera. Gir videodata i formatet Composite PAL/NTSC med frame rate 60 fps. Matrisestørrelse på 384x288 piksler. Antall piksler: Oppfatter IR-stråler med bølgelengder fra 8 til 12 mikrometer. Effektforbruk på 0.6 Watt ved 5V spenningspådrag. Typisk vekt med optikk: 74 gram. Størrelse på 42.5x50 mm. Fungerer i temperaturer fra -20 til 60 grader celcius. Pris på rundt NOK. Dette kameraet vil antakelig være akseptabelt med hensyn på plass- og strømforbruk [2]. Kameraet har heller ingen bevegelige deler, og vi slipper dermed å tenke på problemer dette kunne medført i rommet. Kameraet gir også ut videosignal, noe som kan være problematisk mhp. minneforbruk. Mulighetene for å bruke kameraet til å ta stillbilder med akseptabelt minneforbruk bør derfor undersøkes videre Bruksområder Dette kameraet oppfatter infrarødt lys med bølgelengder fra 8 til 12 mikrometer. Dette området passer spesielt godt når man tar bilder av meterologiske fenomen [?]. F.eks. vil man kunne skille ulike typer skyer fra hverandre og vil kunne detektere temperaturen på landområder eller i havet. Dette er verdifullt for f.eks. fiskere eller shippingindustrien som ønsker informasjon om 9

11 de beste fiskestedene eller hvordan havstrømmer oppfører seg. 2.4 Nær-infrarødt kamera Kameraet vi bruker kalles C328V-6016BW [11] og tar stillbilder. Det har følgende spesifikasjoner. 8-bit, 256-nivås svart-hvit bildesensor. Fysisk størrelse på 20x28 mm. Oppløsning: 640x480 piksler (VGA). Også mulig å nedsample til 320x240 (QVGA). Bruker spenningen 3.3 Volt og et gjennomsnittlig strømforbruk på 105 ma. UART-grensesnitt. Overføringsraten detekteres automatisk og kan være fra 7200 bps til bps. Kameraet har fire pinner som beskrevet i tabellen nedenfor. Pinne VCC TxD RxD GND Tabell 2.3: Beskrivelse av kamerapinner Beskrivelse Strømforsyning (3.3V DC) Data transmit (3.3V DC) Data recieve (3.3V DC) Jord VCC kobles til strømforsyningskretsen vår og resten av pinnene kobles til mikrokontrolleren. Merk at TxD må strømdeles for å få omtrent 3.3V ettersom mikrokontrolleren sender ut 5V på hver pinne og vi bruker en software-implementasjon av UART-grensesnittet for å kommunisere med kameraet Bruksområder Kameraet reklameres som spesielt sensitivt for infrarødt lys. Ettersom det har en CMOSbildesensor må dette i såfall bety at det kan oppfatte infrarødt lys med bølgelengder fra rundt 0.75 til 1 mikrometer. Dette betyr at kameraet i hovedsak oppfatter infrarødt som opprinnelig kommer fra solen og som reflekteres fra f.eks. blader og annen vegetasjon. Dette betyr at et kamera som oppfatter nær-infrarødt lys kan være spesielt egnet til å kartlegge vegetasjon og forskjellige egenskaper ved denne [12]. Bølgelengder fra 0.4 til 2.7 mikrometer har vist seg å være spesielt egnet for refleksjon fra blader. I tillegg til å kartlegge hvor mye vegetasjon det finnes, kan dette være nyttig for å kartlegge stress, aldring og sykdom i vegetasjonen på jorda. 10

12 Kapittel 3 Satellitteori 3.1 Plassering av bilde Systemet er avhengig av å vite posisjon og orientering av satelitten i det øyeblikket bildet taes for å kunne vite hvor og hvordan bildet endelig skal plasseres på modellen av jorden. Dette kan bestemmes enten ved, gitt noen initialbetingelser, beregninger eller ved direkte målinger på det aktuelle tidspunktet. Satellitten beveger seg med en fart på i overkant av 7 km/s så en viss presisjon er helt nødvendig for at bildene ikke skal bli feilplassert. Måling av posisjonen kan bestemmes ved for eksempel bruk av GPS eller andre former for triangulering, men ulempen med dette er at man utstyrer satellitten med flere komponenter og øker dermed kompleksiteten og sårbarheten til systemet. Alternativet er å beregne banen til satellitten. I det følgende vil vi se på beregning av posisjonen. Orientering av satellitten er verre å prediktere. Satellitten vil i utgangspunktet ikke være orientert med kameraet rettet loddrett ned som hadde vært det enkleste. Den vil i teorien kunne ha en vilkårlig orientering, samt rotere rundt en eller annen akse. Eventuell rotasjon vil holde seg stabil så om man har tilstrekkelig med initialbetingelser ksn dette også beregnes, men det er ikke gjort. 3.2 Baneteori Å beregne baneformen kan være både veldig enkelt og veldig komplisert avhengig av hvor høy presisjon man har behov for. Det enkleste er et tolegemesystemet med kun satellitten og en sfærisk jordklode. For korte tider er dette en fin modell. Gravitasjonskraften fra jorda er i størrelsesorden 10 5 ganger sterkere i forhold til månen og 10 3 ganger sterkere i forhold til sola, om man tar utgangspunkt i en banehøyde på 800 km. 11

13 3.2.1 Solsynkron bane Satellitten er tenkt å følge en solsynkron bane. Det vil si at orienteringen til banen i forhold til sola til en hver tid er den samme. Det er det samme som å si at soltiden er konstant i en gitt posisjon langs banen. Dette kan være en gunstig da bildene vil bli tatt på samme tid av døgnet ved samme breddegrad og er ideelt for sammenligning av bilder tatt på samme breddegrad ulike steder rundt jorden. En solsynkron bane oppnås ved å kombinere banehellning og banehøyde på en slik måte at orbitalplanet presiserer rundt jorden med en hastighet på en runde i året. α α α Figur 3.1: Figuren viser orbitalplanet til banen i forhold til sola for en solsynkron satellittbane. Årsaken til at banen vil presisere slik er på grunn av jordas ikke-sfæriske form. Jorda er litt flattrykt og tykkere rundt ekvateor på grunn av jordas rotasjon. Bortsett fra når satellitten er akkurat over ekvator vil gravitasjonskrafta virke virke en anelse unna jordas sentrum. Dette vil skape et dreiemoment som fører til denne presisjonen. En god approksimasjon av presisjonsraten vil være [23] ω p = 3a2 2r 2 J 2ω cos i (3.1) hvor a er jordas ekvatorradius, r er satellittens baneradius, ω er satellittens rotasjonshastighet, i er banens inklinasjon i forholt til ekvatorplanet og J 2 er jordas andre formfaktor. J 2 er relatert til jordas ikke-sfæriske form og kan beskrives som følger J 2 = 2ɛ E 3 a3 ω 2 E 3GM E (3.2) hvor ɛ E er et mål på jordas flattrykking, ω er jordas rotasjonshastighet, G er gravitasjonskonstanten og M e er jordas masse. Flattrykktheten ɛ E er definert som forholdet mellom differansen av korte og lange halvakse og lange halvakse ɛ E = (a b)/a. For jorda er denne størrelsen J 2 = Ved å velge banehøyde og inklanasjonsvinkel på en god måte kan man dermed sørge for at presisjonsraten er en runde per år. Om presisjonen er i riktig retning så vil man dermed ha en solsynkron bane. Et eksempel på en bane kan da være en med periode på 100 minutter, og dermed en banehøyde på omtrent 763 km og dermed en inklanasjon på

14 3.3 Tidskorreksjon Om man skal registrere tiden et bilde er tatt, er det en forutsetning at denne tiden er korrekt. Tiden blir her målt i satellitten som beveger seg med høy hastighet og i et annet sted i gravitasjonsfeltet. Korreksjon i tiden på grunn av tidsdilatasjon er [22] til første orden i 1/c ( ) korreksjon for 1 ( ) v (3.3) tidsdilatasjon 2 c 2 hvor v er banefarten til satellitten. Korreksjon på grunn av gravitasjonsfeltet er ( ) korreksjon for GM ( 1 gravitasjonsfeltet c 2 r 1 ) (3.4) R hvor r og R er henholdsvis satellittradien og jordradien, M er jordmassen og G er gravitsjonskonstenten. Dette gir et avvik på 8ms per døgn, og 3.1 s i året. Innenfor noen få dager kan det være neglisjerbart men over lengre tidsrom vil det være avgjørende å ta hensyn til dette avviket. 3.4 Numerisk beregning Det vanligste måten å bestemme posisjonen på er å benytte seg av numeriske beregninger. Da kan man om ønskelig putte mange forskjellige patrametere inn i modellen for å fø ønsket nøyaktighet i beregningene. Med de beste modellene og nøyaktige initialbetingelser kan man beregne satellittbaner med en presisjon i størrelsesorden meter. Det finnes mange dataprogrammer på markedet for slike numersike beregninger on NAROM benytter seg for eksempel av programmet Satellite Tool Kit. Det samme programmet blir blandt annet benyttet av både NASA, ESA og Boeing. Det er nok på denne måten vi bør finne posisjonen til banen. Det vil gi veldig høy nøyaktighet. Om man samtidig oppdaterer posisjonen med observasjoner fra bekken vil man kunne kunnne korrigere for eventuell drift. 13

15 Kapittel 4 Nettløsninger 4.1 Hjemmeside Når en ønsker å formidle informasjon i dagens samfunn er ikke Internett til å komme utenom. For å distribuere våre IR-bilder og programmet IR-Earth utvklet vi en hjemmeside med tilhørende teknologi. Beskrivelsen av hjemmesiden er bygget opp av to deler, den første delen er om det praktiske på hjemmesiden, som hva den inneholder og hvordan dette er en god måte å dele IR-bilder på. Den andre delen er teoretisk og tar for seg den tekniske delen ved utvkling av hjemmesiden, databaser og UNIX-skripting. Nettsiden kan besøkes på og alle filer er lagt i vedlegget på denne rapporten. 14

16 Figur 4.1: Forsiden av hjemmesiden 15

17 4.2 En praktisk beskrivelse av hjemmesiden Hva er en god hjemmeside? Mulighetene ved en hjemmeside endrer seg over tid og hjemmesider som før var moderne er i dag fryktelig utdaterte. Et eksempel på dette kan en se ved NTNU sin utredning fra 1996[13] om hvordan NTNUs nye hjemmeside burde utformes. Med dagens teknologi er mulighetene større og hjemmesider inkluderer nå grafikk som ville vært altfor tung å laste i Selv om teknologien utvikles er det fortsatt noen grunnprinsipper som ligger til grunn for hva som er en god hjemmeside. Nettstedet smashingmagazine.com (SM) utarbidet i principles of effective web design[18], 1. Don t make users think 2. Don t squander users patience 3. Manage to focus users attention 4. Strive for feature exposure 5. Make use of effective writing 6. Strive for simplicity 7. Don t be afraid of the white space 8. Communicate effectively with a visible language ( visible language er det brukeren ser) 9. Conventions are our friends 10. Test early, test often Ved utformingen av hjemmesiden har disse punktene på ingen måte blitt fulgt slavisk, men det er greit å ha dem i bakhodet Forsiden: Brukerens første møte med IR-Earth En forside må både være informativ og enkel slik at brukeren fort forstår om dette er noen som er interessant. Vi har valgt en forside som inneholder et enkelt sammendrag av hva prosjektet vårt går ut på sammen med vår introduksjonsfilm. Filmen er satt inn for å gjøre innholdet mer levende og fange brukerens interesse. I margen til venstre er det plassert to godt synlige referanser til NTNU og NAROM. Prosjektet er støttet av disse to aktørene og for en bruker vil det være ønskelig å se hvem om står bak. Dessuten har både NTNU og NAROM et anerkjent rykte så dette vil uten tvil være med å øke seriøsiteten ved siden umiddelbart. Av navigasjon har vi valgt å plassere lenkene mellom bildene og hovedfeltet på siden. Vi har valgt følgende lenker på navigasjonsmenyen, 16

18 Figur 4.2: Brukeren kan velge å søke på både koordinater og stedsnavn. Navn Bildesøk IR-Earth Medlemmer Tekniske data Hensikt Mulighet for å søke opp bilder i databasen, både på posisjon og stedsnavn IR-Earth lenker til appleten, og med dette valgnavnet ønsker vi at hvis brukeren skal trykke på en link, skal det være denne. Informasjon om de ulike medlemmene Teknisk data om IR-kamera Siden er på ingen måte nyvinnende når det kommer til design og kan ikke sammenlikne seg med sidene til for eksempel ESA, men på et så lite prosjekt har vi rett og slett ikke nok data til å lage noe så omfattende Bildesøk: Nettsidens viktigste del I denne siden skal brukerne ha muligheten til å søke på områder i verden i et gitt tidsrom og så skal de få opp de bildene som inneholder området i det oppgitte tidsintervallet. Her er det viktig at en ikke ber om får mye av brukeren. Vi har derfor lagt til rette for at brukeren kan søke på både koordinater og stedsnavn. Hvis en skulle kreve at brukeren selv fant koordinater til stedsnavn ville det blitt for tungvindt, samtidig bør det være støtte for de som har noen spesifikke koordinater de ønsker å se. Det kan for eksempel være områder i havet hvor det ikke er noen stedsnavn i nærheten. 17

19 Figur 4.3: Brukeren får opp en liste med bilder som tilfredstiller kravene brukeren har satt Øvrige deler av siden IR-Earth Da vi satt oss ned for å skrive en prosjektdefinisjon var IR-Earth på mange måter vårt endelige produkt og appleten må ha en naturlig inkludering på hjemmesiden. Appleten forutsetter java installert og åpner i hovedmenyen som vist på figur 4.4. Medlemmer og Tekniske data Siden med tekniske data er lagt med for at de spesielt interesserte skal kunne lære mer om kamera. Dette er selvsagt kun vårt prototypekamera, da et fjern ir-kamera koster langt over budsjettet. Vi følte også det kunne være interessant for utenomstående å lære om medlemmene bak prosjektet. 18

20 Figur 4.4: Inkludering av appleten på hjemmesiden. 4.3 Den tekniske delen ved utvklingen av hjemmesiden Kravspesifikasjoner Før utvklingen av nettsider og databaser kan starte er en nødt til å sette seg ned for å finne ut hvilke tjenester nettsiden skal levere. En annen gruppe arbeidet med datakommunikasjon med satelitten og dermed kunne vi anta at hvis bildene ble tatt med IR-kameraet vil de kunne bli transportert ned til jorden. Vårt spørsmål ble da hva vi skulle gjøre når bildene ligger på en server på jorda. Vi kom fram til at bildene automatisk skal gå fra server og inn på nettsiden og IR-Earth, og at en på nettsiden skal kunne søke i bildene. Utover dette skal nettsiden ha en del annen informasjon, men det er mer et innholds- og designmessig problem enn programmering Databaser Som databasesystem ble MySQL valgt. MySQL er en av de mest brukte databasene når det kommer til web-applikasjoner og støtter mange plattformer, noe som er gunstig når databasen ikke bare skal kommunisere med nettsidene, men også java-appleten IR-Earth. Med MySQL som valg for database var bruk av PHP på nettsiden det kanoniske valget. Det kan nevnes at store sider som Flickr, Facebook og Wikipedia bruker MySQL til lagring av data[14]. På nettsiden skal det være mulig å søke på et koordinat og få opp alle bilder der det koordinatet dekkes. For at dette skal være mulig må hvert bilde lagres med informasjon om hvor sentrum av bildet ligger slik at vi kan finne alle punkter som ligger innenfor en viss radius. Vi har valgt å søke etter punkter innenfor en sirkel siden bildet ikke er kvadratisk og vi ikke kjenner 19

21 rotasjonen til satellitten i det bildet blir tatt. Radiusen til sirkelen regnet vi ut ved å kjenne høyden til satellitten, bildets brennvidde og sentrum. Det er også nødvendig å legge med timestamp på bildene slik at en kan søke på tidsintervall. Med disse spesifikasjonene i bakhodet ble databasen opprettet med følgende felt: (id, dato, longitude, latitude) som vist på figur Nettsiden Av funksjonalitet på nettsiden krever vi ikke så mye utover at den skal kunne kommunisere med databasen. Nettsiden er forutenom HTML og CSS utviklet i PHP da dette er et ypperlig skriptspråk for å kommunisere med MySQL. Siden er programmert i tre lag, et øvre lag som inneholder logo, logoer og meny, en hoveddel hvor inneholdet for hver side står, og en underdel. Førstnevnte og sistnevnte er skrevet i henholdsvis over.php og bottom.php og inkludert på alle sidene. Dette, sammen med CSS, gjør det veldig enkelt å foretå endringer i oppbyggingen av sidene Fra server til applikasjon: Unix-skript En av de viktigste delene ved prosjektet er automatikken i å få bilder fra server og tilgjengelig for brukermassen. For at dette skal være gjennomførbart antar vi at det til hvert bilde lagres informasjon på formen (bildenavn, dato - tid, lengdegrad, breddegrad) der lengdegrad og breddegrad er koordinatene til sentrum av bildet. I figur 4.6 ser en eksempel på datafilen som kommer inn sammen med bildefilene. I tillegg setter man på en cron-jobb som gjør at scriptet kjøres hvert Nte minutt, der N er en parameter som velges etter hvor ofte vi kan forvente å få inn bilder på server. Etter at scriptet er kjørt vil bildene som havnet på server havne i passende mapper på serveren, for eksempel vil et bilde tatt 22/10/2010 havne i mappen bilder/2010/22/10 og bildenavnet være time minutt sekund lengdegrad breddegrad.jpg. Figur 4.5: Skjermdump som viser hvordan bilder legges inn i databasen 20

22 Figur 4.6: Denne informasjonsfilen legges på serveren sammen med bildefilene. Første feltet er navnet på bildet nå deretter følger dato med tid, lengdegrad og breddegrad D-fremvisning Krav Til å begynne med hadde vi noen enkle krav til hva vi ønsket Mulighet for å vise bilder på en tredimensjonal jordklode. Mulighet for å plassere bilder i vilkårlige posisjoner. Mulighet for å hente ut bilder fra en database. Bakgrunnen for kravene var et ønske om at dette systemet skulle inngå i et større automatisert system, der bilder mottas fra satellitten og legges i en database automatisk. Denne delen skulle inngå som en alternativ og mer spennende måte å vise bildene på Muligheter Basert på kravene var det ingen nødvendighet å skrive applikasjonen i Java. Andre utbredte muligheter som Flash ville også ha fungere. Grunnen til at valget tidlig falt på Java, var at vi hadde tidligere erfaring med Java. Vi var derfor sikre på at vi skulle rekke å bli ferdige hvis vi valgte denne løsningen. I tillegg var det et krav at løsningen enkelt skulle kunne brukes på forskjellige operativsystemer. Java oppfyller kravene til kompabilitet, ettersom det er utviklet programvare for å kjøre Java til de fleste operativsystemer. Alle de vanligste operativsystemene som Windows, Mac og de vanligste linux distribusjonen har mulighet for å kjøre Java og Java-appleter. Et annet positivt punkt med Java er at den samme kompilerte koden kan kjøre på alle plattformene, slik at det ikke trengs noen plattformspesifike forandringer i koden. Dette er fordi den kompilerte koden kjøres på en virituell maskin på brukerens datamaskin. Dette betyr at 21

23 programmet ikke kjøres direkte på maskinen, men på en emulert maskin som startes på den brukerens datamaskin Nødvendige Java-biblioteker Vårt ønske om å vise bilder på en jordklode medførte at vi trengte en måte å implementere en tredimensjonal jordklode som kunne roteres og zoomes. I tillegg til muligheter for å vise bildene i riktig størrelse og proposjoner på selve jordkloden. Dette lar seg gjøre med 2D-grafikk biblioteker, men er en mye lettere jobb med 3D-biblioteker som automatisk rendrer en scene basert på avstandene objektene har fra et virtuelt kamera og deres rotasjoner. For Java finnes et slik type bibliotek kalt Java 3D, men dette er ikke med i en standard Java-installasjon. Dette løste vi ved å la Java automatisk laste ned Java 3D bibliotekene på klientmaskinen og la disse være tilgjengelig mens Appleten kjøres. Dette kan gjøres ved å spesifisere en JNLP-fil der Java 3D bibiotekene angis som eksterne biblioteker. Hvis denne da startes med Java Web Start rammeverket vil disse filene automatisk lastes ned og være tilgjengelige til applikasjonen avsluttes. Fra og med Java SE 6 Update 10 er det støtte for at Appleter som er spesifisert i en slik fil kan startes i nettleseren. En JNLP-fil er en tekstfil som inneholder forskjellige tags som angir diverse informasjon om Appleten Java 3D Java 3D er et bibliotek til Java som gir et programmeringsgrensesnitt for tredimensjonal grafikk. Dette grensesnittet er objektorientert og baserer seg på scener som konstrueres fra en scene-graf. Det vil si en graf som gir en representasjon av objektene som skal tegnes på skjermen. Dette kan være faktiske geometriske objekter eller objekter som utfører rotasjoner eller translasjoner av geometriske objekter og så videre. Når biblioteket brukes er det ikke nødvendig å tenke på hvordan lavnivå renderingen foregår, med OpenGL og Direct3D for eksempel. Selve bibliotekene og mer informasjon kan finnes på Sun sine hjemmesider[15] Utplassering av bilder Utplassering av bilder på jordkloden utgjør en teoretisk utfordring. Før vi går videre med dette problemet la oss se på en enklere oppgave. Anta vi har to bilder, herfra kalt bilde A og bilde B, som har forskjellige oppløsning. Det vil si et forskjellig antall pixler i høyde og/eller bredde. Vi har her antatt at bildene er lagret som bitmaps, det vil si at bildet er delt inn i pixler som har verdier som angir farge. La oss videre anta at vi ønsker å plassere bilde B innenfor et gitt rektangulært område på bilde A. For å gjøre dette må vi på en eller annen måte oppskalere eller nedskalere bilde B, slik at antall pixler i bredde og høyde stemmer med det antall pixler innenfor det avgrensede rektangulære område i bilde A. Det finnes ulike algoritmer for å oppnå dette, men de har til felles at de angir en eller annen interpolasjon av pixlene i bilde B. Det vil si at de angir en sammenheng som skal brukes på pixlene i bilde B for å finne verdiene på pixlene i det avgrensede området i bilde A. 22

24 Figur 4.7: En enkel illustrasjon av hvilke verdier som brukes ved bilineær interpolasjon. Verdien i pikselen markert i blått estimeres med et vektet gjennomsnitt av de to pikslene merket i grønt som igjen er et vektet gjennomsnitt av de to nærmeste pikslene horisontalt for hver av de to. En av de enkleste algortimene for å gjøre dette kalles nærmeste-nabo interpolasjon. Denne foregår ved at man først tenker seg at et bilde består av et regulært gitter av punkter. Det vil si at avstanden mellom nærmeste gitterpunkter horisontalt er den samme overalt, og at det samme er tilfellet for vertikale avstander. Punktene i gitteret er de ulike pixlene. For å gjøre interpolasjonen legges det det nye og det gamle gitteret over hverandre og skaleres slik at de er like brede og høye. Etter dette er gjort gir man hver piksel i det nye gitteret den samme verdien som den pikselen i det gamle gitteret som er nærmest den nye pikselen. Mer avanserte algoritmer framkommer på samme måte ved å legge det nye gitteret over det gamle, men i steden se på flere punkter i det gamle bildet for hvert punkt i det nye bildet. Et eksempel er bilineær interpolasjon der man brukes pikslene i den nærmeste 2 2 ruten. Man gjør et vektet gjennomsnitt horisontalt og så et vektet gjennomsnitt vertikalt av disse verdiene igjen. Se figur 4.7 for en visualisering av dette. Dette vektede gjennomsnittet kan typisk være en lineær interpolasjon mellom verdiene. I prinsippet trenger man å gjøre noe lignende når et bilde skal settes inn på teksturen som brukes på jordkloden. Problemet er at det brukes en rektangulær tekstur for jordkloden. Denne teksturen brukes ved at det lages tekstur-koordinater på jordkloden som gis en verdi basert på interpolasjon mellom verdier i teksturen. Denne transformasjonen fra et rektangulært område til en sfære, betyr at det helt klart vil gi feil resultat å plassere bildet direkte som et rektangulært område på teksturen. Ettersom bildet da vil bli deformert når teksturen blir plassert ut på jordkloden. For å løse dette problemet må vi ta hensyn til denne deformasjonen når bildet plasseres ut, slik at det etter deformasjonen vil se riktig ut. Vi må i prinsippet gjøre den omvendte opperasjonen av deformasjonen. I tillegg er vi nødt til å ta hensyn til at høyre og venstre ende av texturen vil være ved siden av hverandre på overfalten av jordkloden. Dette fordi teksturen brettes rundt jordkloden. Løsningen vi valgte var å bruke en tilnærmet nærmeste-nabo interpolasjon, der nærmeste nabo vil bli i den vanlige Euklidske forstand i rommet. Algoritmen foregår som følger. Vi starter med 23

25 (a) Bildet vist på jordkloden i forhold til (b) Bildet vist på jordkloden etter nevnte startposisjon av jordkloden. rotasjoner. Figur 4.8: Jordkloden før rotasjon i a) og etter rotasjon i b). å gjøre en tenkt rotasjon av jordkloden slik at senteret av området bildet skal settes inn på er rett foran oss på jordkloden. I tillegg tenker vi oss at vi gjør en rotasjon om aksen gjennom sentrum av jordkloden og det punktet på jordkloden senteret av bildet skal settes inn på, slik at topp og bunn av bildet blir parallelle med en tenkt ekvator. Se figur 4.8 for et nærmere eksempel av hva som menes. Etter disse tenkte rotasjonene projiserer vi hele den halvkulen som er synlig ned på et plan gjennom sentrum av jordkloden som står vinkelrett på aksen gjennom sentrum av jordkloden og senteret av bildet. Denne operasjonen gjør at vi mister den delen informasjon som ligger i avstanden fra dette planet. Dette betyr at avstandene mellom punkter som projiseres vil forandre seg. Men nært sentret av bildet vil denne tilnærmingen være god ettersom punkter der ligger omtrent like langt fra planet. Etter projeksjonen finner vi posisjonene i planet til hver av teksturkordinatene og posisjonene i planet til pikslene i bildet. Dette gjøres ved å sette radiusen til sfæren lik jordens radius og sette en virkelig bredde og høyde på bildet. Når vi har disse romlige posisjonene kan vi gå igjennom alle pikslene på teksturen og bestemme om de er på riktig halvkule og om de projiseres til et punkt som er innenfor bildet som skal settes inn. Hvis det projiseres til et punkt innenfor bildet bruker vi den nærmeste pikselen på bildet. Der nærmest betyr minst Euklidsk avstand i planet. Det er verdt å merke seg at antall piksler som må skiftes på teksturen vil variere veldig avhengig av hvor bildet skal plasseres på jordkloden. Ved nordpolen har teksturen mange flere piksler enn ved for eksempel breddegrad 0. Dette trenger vi ikke å tenke på med denne metoden. Det er derimot mulig å gjøre store kutt i antall piksler som vi trenger å vurdere, spesielt hvis bildet har liten romlig størrelse. Men vi anser foreløpig ikke kjøretid som et problem. 24

26 4.4.6 Rotasjon For å bevege oss mellom to mulige posisjoner av jordkloden trenger vi en måte å rotere jordkloden på som oppfattes som naturlig for brukeren. I tillegg til en natrulig måte å forandre avstanden fra jordkloden på. Når det gjelder forandring av avstand til jordkloden kommer alle avstander til å være på den samme skalaen, det vil si ikke langt ifra eller veldig nærme, slik at vi kan bruke en lineær interpolasjon i tid mellom start- og sluttavstand. For selve rotasjonen er det flere aktuelle metoder. Hva som oppfattes som en naturlig måte å rotere en jordklode på kan diskuteres. Men vi bestemte oss for to kriterier som vi fokuserte på. For det første bør rotasjonen ha en jevn fart, uten store forandringer i vinkelhastighet. For det andre bør rotasjonen gå så direkte som mulig mellom de to orienteringene av jordkloden, det vil si ikke rotere først i lengdegrad og så i breddegrad og så videre. En mulighetet er å representere en orientering av jordkloden med Euler-vinkeler som angir en rotasjon fra en referanseposisjon. Denne referanseposisjonen vil typisk være ingen rotasjon av jordkloden i forhold til hvordan den er når Appleten startes. Det er flere mulige spesifikasjoner av Euler-vinklene, men for dette tilfellet vil en naturlig spesifikasjon være å la lengdegrad og breddegrad være to av vinklene og til slutt la den siste vinkelen være rotasjonen om aksen gjennom sentrum av jordkloden og punktet på den angitte lengdegraden og breddegraden. Disse Euler-vinklene kan representere enhver mulig orientering av jordkloden, men er ikke problemfrie. Det største problemet er at det ikke er noen enkel måte å rotere mellom to forskjellige orienteringer angitt ved sine respektive Euler-vinkler med jevn fart. Se for eksempel på tilfellet med en breddegrad som er nær nordpolen, her vil en forandring av lengdegrad ha mye større effekt enn ved en breddegrad nær ekvator. I tillegg må også den siste Eulervinkelen forandres. Vi valgte derfor å forkaste denne representasjonen selv om den kanskje er den letteste og mest intuitive. Vi ser at det er nødvendig med en annen representasjon av en orientering av jordkloden. Det bør være en representasjon der det er enkelt å gjøre en interpolasjon i tid som gir en jevn rotasjonfart. Det finnes en annen representasjon som oppfyller nettopp dette. Idéen bak denne representasjonen er at man representerer en orientering av jordkloden med en rotasjon av jordkloden i forhold til en referanseposisjon, ved å angi en rotasjonsakse og hvor mange grader jorden er rotert om denne aksen. Dette gjøres vanligvis ved bruk av et kvaternion. Et kvaternion er en samling av fire tall som har visse regler for hvordan de skal adderes og multipliseres. Vi skal ikke gå dypt inn på egenskapene til kvaternionene i denne rapporten, men nærmere informasjon kan finnes på Mathworld sine nettsider[16]. Fordelen med kvaternioner er at det finnes noe som kalles sfærisk lineær interpolasjon, som kan brukes til å gi en rotasjon med konstant vinkelhastighet mellom to orienteringer gitt ved kvaternioner[17]. Slik at denne typen rotasjoner oppfyller det første av våre kriterier. Videre svarer rotasjonen gitt ved denne typen interpolasjon til rt rotasjonen mellom to orienteringer gjøres om bare en akse. Det vil si at det velges én akse slik at jevn rotasjon om denne gir en jevn rotasjon fra start- til sluttorientering. Det finnes bare én slik akse untatt i det degenererte tilfellet at start- og sluttorientering er de samme. Slik at denne rotasjonen fungerer også bra i forhold til vårt andre kriterium, ettersom det bare skjer rotasjon om én akse ved hver rotasjon. 25

27 4.4.7 Henting av bilder fra database Appleten skal finne bilder basert på start- og sluttdato og posisjon. Informasjon om disse bildene skal lagres i en MySQL-database. Denne informasjonen skal være tilstrekkelig til å finne bildet på serveren og til å plassere bildet på jordkloden. Det er ikke ønskelig at Appleten gjør direkte oppslag i MySQL-databasen. Både fordi det kan utgjøre en sikkerhetsrisiko ettersom Appleten kjøres på brukerenes datamaskin og av praktiske hensyn. Vi ikke at kildekoden skal spesifisere en spesifik MySQL-database, brukernavn og passord. Ettersom vi ønsker at Appleten ikke skal være bundet opp mot en database som muligens skal forandres, både med tanke på at det i fremtiden kan bli aktuelt med andre databasetyper enn MySQL og at det i fremtiden kan tenkes at adressen til serveren forandres. I tillegg til at det blir umulig å skifte brukernavn og passord som brukes av appleten uten å kompilere kildekoden på nytt. Vår løsning var å gjøre spørringen i databasen på serveren, ved at Appleten kontakter en side skrevet i et skripting-språk som JSP eller PHP og så retureneres resultatene i ren tekst. På denne måten blir Appleten uavhengig av databasen som ligger i bakgrunnen 26

28 Kapittel 5 Resultater 5.1 Realisering av kameraprototype Vår prototype av kamerasystemet består av en ferdigkjøpt kameramodul, et lysfilter, en linse, et Arduino-testbrett med tilhørende mikrokontroller og strømforsyning. Den ferdigkjøpte kameramodulen består av bildesensoren, linsen og den har også egen lagringsplass for bildet Mikrokontroller Mikrokontrolleren er av typen ATMega328p. Den har følgende spesifikasjoner. Klokkehastighet: Opp til 20 MHz mulig. Vi kjører den på 16 MHz. Intern EEPROM (ikke-volatilt minne): 1 Kb. Brukes ikke. Intern SRAM (volatilt minne): 2 Kb. Brukes som buffer av programmet vårt. Mikrokontrolleren sitter på et Arduino-testbrett [3] og mikrokontrolleren programmeres ved hjelp av deres bibliotek, IDE og programmeringsspråk (C/C++). Disse bibliotekene gjør det raskt og enkelt å sette opp en fungerende prototype på kort tid. Arduinos løsninger er opensource både når det gjelder hardware og software og de har etterhvert fått et rimelig stort brukermiljø av hobbyentusiaster. Kretsskjema for hele systemet i ett er vist i figur

29 Figur 5.1: Skjema for hele kretsen På kretsskjemaet ser vi et Arduino-testbrett koblet til en strømforsyning og kameraprototypen vår. Lysdiodene brukes for å signalisere overføring av data (Arduino pin 13) og eventuelle feil (Arduino pin 7). RxD og TxD er henholdsvis mottaker- og sendeporten (UART-grensesnitt) til kameraet og opererer i likhet med VCC på 3.3V. Resistansene som er koblet RxD er for å dele opp utgangsspenningen fra Arduino-pin 3, som er på 5V, slik at denne blir nedskalert til 3.3V (se ligning 5.1). Grunnen til at dette må gjøres er at det brukes et UART-grensesnitt implementert i software for å kommunisere med kameraet. V OUT = 5.0V/(100K + 200K) 200K = 3.33V (5.1) Merk at det antas at strømtrekket til kameraets port RxD er neglisjerbart Kode Koden på mikrokontrolleren vår er basert på kode funnet på en japansk blogg [4], der forfatteren tar bilde ved hjelp av Arduino-hardwaren og et lignende kamera. Vi har gjort noen 28

30 justeringer i denne for å tilpasse den vår egen kameramodul. Mikrokontrolleren kommuniserer med kameraet ved hjelp av UART-grensesnittet. Dette grensesnittet består av en inngangsport og en utgangsport, der utgangsporten tar bytes av data og overfører hver bit i serie og inngangsporten tar i mot bits av data og setter dem sammen til bytes [6]. Dette grensesnittet er implementert i mikrokontrollerens hardware, men problemet i vårt tilfelle er at det kun finnes en inngang- og en utgangsport og at vi aller helst vil kommunisere med datamaskinen og kameraet samtidig. For å få til dette benytter koden seg av en software-implementasjon av UART-grensesnittet kalt NewSoftwareSerial [10]. Prosedyren for å ta et bilde er som følgende. Kameraet synkroniseres med mikrokontrolleren. Kameraet initialiseres og ønsket oppløsning (QVGA eller VGA) settes. Setter ønsket pakkestørrelse i bytes. Dette er antall bytes kameraet skal overføre til mikrokontrolleren før mikrokontrolleren sender en bekreftelse (ACK-melding) til kameraet. Venter i 2 sekund for å klargjøre kameraet. Mikrokontrolleren sender beskjed til kameraet om å ta et bilde med JPEG-komprimering eller ingen komprimering. Kameraet tar et bilde og lagrer det på kameramodulens interne EEPROM. Mikrokontrolleren sender beskjed til kameraet om å overføre bildet til mikrokontrolleren. Mikrokontrolleren mottar så en pakke (på et visst antall bytes), som den lagrer/bufrer i egen RAM og deretter sender direkte til datamaskinen. Mikrokontrolleren sender en bekreftelsesmelding til kameraet om at den har mottatt pakken og er klar til å motta en ny Lysfilter I motsetning til et vanlig kamera må vårt kamera ha et lysfilter som filtrerer bort synlig lys og bare slipper i gjennom infrarødt lys. For prototypen har vi benyttet en svart diskettplate for filtrere bort noe av det synlig lyset, etter ide fra diverse sider på internett. Selv om vi fikk tatt et akseptabelt bilde er problemet at vi ikke vet noe om hvorvidt det vi ser på bildet er synlig lys eller infrarødt lys, evt. hvilke av disse to lystypene som dominerer. For å teste om kameraet oppfattet IR-lys i det hele tatt tok vi bilde av IR-dioden til en fjernkontroll. Dette lyset ble oppfattet godt av kameraet. Et bilde tatt av en avslått fjernkontroll er vist i figur 5.2. Samme fjernkontroll i påslått tilstand er vist i figur

31 Figur 5.2: Bilde av avslått IR-diode til en fjernkontroll Figur 5.3: Bilde av påslått IR-diode til en fjernkontroll 30

32 5.1.4 Strømforsyning Ettersom Arduino-testbrettet har en utgangsstrøm på 50mA ved 3.3V og kameraet vårt har et gjennomsnittlig strømforbruk på 105mA ble det brukt en ekstern strømkilde til kameraet. Strømforsyningen er en egen krets laget ved hjelp av spenningsregulatoren LM317 [5]. Kretsen er den anbefalte standardkretsen vist på informasjonsiden til spenningsregulatoren og består av noen kapasitanser og resistanser som vist i figur stk. AA-batterier på 1.5 V hver brukes for å forsyne denne kretsen med strøm. Ligningen for å regne ut utgangsspenningen til denne kretsen er vist i 5.2. V OUT = 1.25 (1 + R 2 /R 1 ) + I ADJ (R 2 ) (5.2) Her er I ADJ svært liten og kan ignoreres for dette formålet. Om R 1 = 240Ohm som vist i figur 5.4, må R 2 være omtrent lik 400Ohm for at vi skal få V out = 3.33V. Figur 5.4: Krets for spenningsregulatoren LM117/LM Objektiv Objektivet vi bruker fulgte med kameraet og har følgende spesifikasjoner. Brennvidde: 6 mm. Synsvinkel: 39.8 grader. Blendeverdi (F/#): Applet Implementasjon Appleten består av et enkelt grensesnitt med mulighet for å hente ut nye bilder fra databasen og for å gå videre til neste bilde. Utseende rett etter at Appleten startes er vist i figur 5.5. Som figuren viser er grensesnittet delt opp i to deler. Til venstre vises jordkloden og til høyere vises informasjon om bildet og funksjonalitet for å bytte bilde. 31

33 Figur 5.5: Utseende på Applet. Øverst til høyre vises hvor mange bilder som ble funnet ved forrige søk og hvilket av disse bildene som vises nå. Under dette står det informasjon om hvilken lengdegrad og breddegrad senteret av bildet er plassert på. Til slutt vises også tid og dato for når bildet ble tatt. Knappen under denne informasjon brukes for å gå videre til neste bilde. Bildene vises i kronologisk rekkefølge. Nede på høyre side er det mulighet for å søke etter nye bilder i databasen. Det er mulig å avgrense søket basert på starttid, sluttid og posisjon. Det må alltid velges en starttid og sluttid, men posisjonen vil bare benyttes hvis det er krysset av på Position. Hvis søk på posisjon er valgt vil treffene innenfor det valgte tidsrommet filtreres slik at bare bilder som inneholder denne posisjonen returneres. Dette søket gjøres via en nettside som gjør selve spørringen i databasen. Basert på resultatet fra denne nettsiden lagres tiden bildet ble tatt, bildets posisjon på jordkloden og en lenke til bildet. På denne måten er det ikke nødvendig å laste ned bilder før de skal brukes. Neste bilde lastes først ned når Show next image -knappen benyttes. Da lastes bildet ned og jordkloden begynner å rotere mens bildet plasseres ut på jordkloden. Selve jordkloden til venstre kan også roteres og zoomes manuelt ved bruk av musen. Vi bestemte oss for å plassere bildene ut i størrelsen 500km 500km på jordkloden. Dette fordi det er en mellomting mellom faktisk størrelse og noe som har stor nok størrelse til at det er mulig å se noen detaljer i bildet. Det er også mulighet for å styre bildets rotasjon om sitt senter når bildet plasseres ut. Det var tenkt at dette skulle benyttes for å ta høyde for satellittens bevegelsesretning og rotasjon om sin egen akse, men vi fant ut at det var vanskelig å bestemme dette presist, slik at denne funksjonaliteten er ikke i bruk Nærmeste-nabo interpolasjon Teorien bak vår metode for å plassere ut bilder på jordkloden er forklart i teoridelen av denne rapporten. Det er flere grunner til at denne ikke fungerer perfekt i implementasjonen. Blant annet er ikke den geometriske figuren en perfekt sfære, den er bygget opp av polygoner. Videre er det en feil grunnet tilnærmingen gjort på avstandsmålet når nærmeste nabo velges. Ettersom bildene som skal settes inn vil være små sammenlignet med jordas radius er det første av disse problemene som blir mest aktuelt. 32

34 Figur 5.6: Eksempel på å plassere et bilde på et område som ikke er i nærheten av polene. Figur 5.7: Eksempel på å plassere et bilde på et område som er i nærheten av en polene. Denne metoden fungerer ganske bra på områder som ikke er nærme noen av polene som man kan se på figur 5.6. Bildet er noe dratt ut på figuren, men det skyldes at det er satt en bredde og høyde som ikke har riktige proposjoner. Man kan uansett se at venstre og høyre kant forblir rette slik de skal være og at det ikke er noen innsmaling mot topp og bunn av bildet. På figur 5.7 kan man se resultatet når deler av bildet ligger over nordpolen. Det blir en sterk effekt av at jordkloden er bygget opp av polygoner. Det virker som polygonene som møtes i nordpolen ikke bruker alle pikslene i teksturen, men at polygonene bruker forskjellige deler av teksturen. Dette gir klare kanter der to forskjellige polygoner møtes Overføringshastighet Kameraet vårt har en maksimal overføringshastighet på bps. I følge [1] skal satelitten overføre data ned til jorden med en hastighet på 9600bps. Kameraet vårt har med andre ord god nok hastighet for å overføre data. Ligning 5.3 og 5.4 viser henholdsvis total overføringstid fra kameraet til resten av systemet og hvor mye energi kameraet bruker på den tiden (worst 33