Mapping the sky

Vi skal nå lage et kart av himmelkula i form av bilder som vi kan bruke for å finne ut hvor vi befinner oss. Kartet blir en referanse hvor vi skal kunne finne igjen bilder vi tar med kamera på romskipet og ut i fra det kunne bestemme i hvilken retning romskipet er vendt, eller retter sagt kameraet.

Som utgangspunkt har vi altså RGB data for alle piksler i himmelkula. Med disse dataene kan vi for et hvilken som helst gitt punkt finne en piksel verdi. Hvert punkt på himmelkula kan vi finne ved å bruke to vinkler; en som går rundt ekvator 360 grader, og en som går fra nordpolen til sydpolen og har et område på 180 grader. Dette så vi på i mer detalj i forrige blog post.

Figur 1
[Figur 1] Vinklene for å finne et punkt på himmelkula

Vi gjør et forsøk her og lager et bilde sentrert rundt \(\phi=0\) og \(\theta=90\) grader og FOV (Field of view) er 70 grader. Dvs. at vi ser et område som er 70 grader i bredden og 70 grader i høyden. Vinklene betyr at vi er sentrert rundt ekvator langs det vi kan kalle x aksen i ekvatorplanet. Vi har et referansebilde som er 480 x 640 piksler (høyde x bredde) som vi kan sammenligne med for å teste at implementasjonen vår er riktig. Oppgaven vår er altså å plukke ut punktene på himmelkula i riktig område og plassere dem ned på et flatt bilde. 

[Figur 2] Hvordan vårt Field Of View ser ut på himmelkula, (Ikke helt riktig, men det kommer vi til).

Vi har altså en bildeflate der vi skal finne hvilken verdi pikselen skal ha. Hvordan vi transformerer så vi nærmere på her. Vi må altså transformere pikselen fra en posisjonsvektor på himmelkula til et x,y punkt på bildeflaten.

På første forsøk gikk ikke dette helt etter planen. Vi strevde først med det vi trodde var at bildet ble rotert og/eller speilvendt, men det viste seg etter mye om og men at vi hadde byttet om høyde og bredde. Når vi fikk stokket om høyde og bredde fikk vi til slutt et bildet som ligner veldig på referanse bildet, men hvis du ser nøye, spesielt i øvre venstre og nedre høyre hjørner kan du se at det er en forskyvning som tyder på feil, eller manglende transformasjon. Igjen et eksempel på at man ikke skal stole for mye på øynene.

[Bilde 1] Referansebilde (rotert 90 grader mot klokka)
[Bilde 2] Generert bilde (rotert 90 grader mot klokka)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Spesielt nede til høyre kan man se at den lyse linjen bøyer seg nedover på [Bilde 2]. Det tyder på at vi har stappet inn for mange piksler på denne linja. Den samme effekten kan vi se øverst i bildene. Hmm, så her er det noe vi ikke helt har forstått riktig. Hvis vi går tilbake og ser på Figur 2 så har vi sett på FOV som gradene i ytterkant av bildet, øverst og nederst, mens det dette egentlig betyr er gradene fra senter av bildet.

[Figur 3] Hvordan breddegraden smalner jo lenger "nord" vi kommer.

I høyden (lengdegrad) så blir dette det samme i alle linjene, men ikke i bredden. Ser vi på et utsnitt så ser vi av [Figur 3] at b åpenbart er kortere enn a og at det smalner jo lenger opp vi kommer.

I bildet som vi da skal lage, som har senter ved ekvator, vil jo dette smalne i begge retninger, som er akkurat det vi ser at ikke skjer i det genererte bildet [Bilde 2].

Så vi må altså ha glemt bort transformasjonen. Og ganske riktig så er det det som har skjedd!

 

 

Så da er det bare å prøve igjen, og denne gangen med transformasjonen på plass. Det vi gjør da er at vi finner ytterpunktene (maksimum og minimum som vi fant her med ligning 6 og 8) til x og y aksen, og lager oss en grid med x og y koordinater jevnt fordelt mellom disse ytterpunktene. Der vi har 640 punkter i x retningen og 480 i y retningen: 

X = [-0.630597577757967,0.630597577757967]                                                                       
Y = [-0.630597577757967,0.630597577757967]

Med dette som utgangspunkt kan vi bruke transformasjonsformelen vi så her (ligning 4 og 5) til å finne vinklene vi skal plukke koordinater fra for hver enkelt piksel. Vi tar altså utgangspunkt i det arealet vi skal projisere ned på, og finner så de verdiene som skal settes inn i hver enkelt piksel. Og jammen får vi ikke et bilde som er identisk med referansebildet vårt med denne teknikken.

[Bilde 3] Referanse bilde (Rotert 90 grader mot klokka)
[Bilde 4] Korrekt transformert bilde (Rotert 90 grader mot klokka)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Og selv om vi ikke kan være helt sikre på at bildene er identiske uten å gjøre en piksel for piksel sammenligning så er vi fornøyd med resultatet. (Og vi gjør selvfølgelig denne sammenligningen og de stemmer på en prikk).

 

Målet vårt er altså å lage bilder rundt hele ekvator av himmelkula slik at vi kan sammenligne med bildet fra romskipet vårt og finne ut i hvilken retning vi peker. I vårt univers har vi gjort en forenkling der vi bare beveger oss i 2 dimensjoner i baneplanet til planeten vår. Dette gjør det litt enklere så vi ikke trenger å se oss om i alle retninger, men bare langs ekvator.

Det er flere metoder vi kan bruke for å finne hvilken retning vi peker i. En metode som i dag brukes mye i bildeanalyse, som jo dette er, er en gren innenfor kunstig intelligens som kalles dyp læring. Da kan man veldig forenklet sagt trene opp et system ved å fore det med data, og så fortelle systemet om det gjetter riktig eller feil, på bakgrunn av tilbakemeldingene vil systemet endre sine parametre og lære seg hva som er riktig. Her har man f.eks kommet langt innen bilde diagnostikk av hudkreft, hvor algoritmene nå faktisk er blitt bedre enn hudlegene.

Vi har imidlertid valgt en litt enklere metodikk ved å bruke minste kvadraters metode som vi har laget en egen blogg post om her, men vi skulle gjerne ha gjort et forsøk med dyp læring.

 

Det vi nå skal gjøre er å lage stereografiske bilder for hver grad i 360º rundt himmelkula for å ha et sammenligningsgrunnlag vi kan bruke for å finne retningen romskipet vårt peker i.

Vi bruker stereografisk projeksjon for å lage en serie med flate bilder av himmelkula. Denne serien med flate bilder blir kartet vårt som "the astrogation computer" kan bruke for å finne ut i hvilken retning vi peker kameraet vårt i. Når vi har et bilde fra kameraet vårt forer vi det inn i "the astrogation computer" og ut får vi en vinkel. Vi finner rett og slett det bildet i kartet vårt der forskjellen er minst sammenlignet med input bildet ved hjelp av minste kvadraters metode. Dette betyr at vi må løpe gjennom alle bildene hver gang vi skal sjekke dette.

For vår implementasjon har vi laget et bilde for hver grad fra 0 til 359, der FOV er 70 grader for alle bildene. Vi kunne valgt å ta mindre utsnitt, og så ta et like stort utsnitt fra sentrum av bildet fra romskipet. Da ville vi spart oss en del diskplass og beregningene ville også vært mindre krevende fordi man må regne med færre tall. Dette er relevante problemstillinger i en virkelig romsonde fordi datakraft krever strøm, og jo mer krevende beregningene er jo mer strøm trenger man. Med dagens smarttelefoner og PC'er er det ikke ofte vi trenger å tenke på om vi har nok kraft, og strøm er aldri langt unna, men på en romsonde, eller et romskip, som skal reise over lange avstander, i løpet kanskje flere år, er det å spare på kraft og minne viktig å tenke på. Så kan du jo sjekke ut hva de måtte klare seg med under den første månelandingen da de brukte The Apollo Guidance Computer. En iPhone i 2019 hadde omtrent 100.000 ganger denne prosesseringskraften.

Et problem med å se på et mindre område er at sannsynligheten for å finne et område som ligner på det vi sammenligner med blir større. Så jo mer data vi har jo større vil forskjellene kunne være. Vi kunne også brukt mindre plass ved å sette FOV til 70 x 1 grader for hvert bilde av kartet vårt og så sette sammen disse bildene til 70x70 graders utsnitt for hver posisjon vi ville sammenligne med. Da ville vi ha spart plass, men muligens brukt litt mer kraft til prosessering.

Neste >>

Publisert 14. okt. 2020 21:25 - Sist endret 14. okt. 2020 21:25