TIETOTEKNIIKAN OSASTO

Joonas Sarajärvi

Reaaliaikainen kuvaprosessointi robottihelikopterissa

DiplomityöTietotekniikan koulutusohjelma

Toukokuu 2014

Sarajärvi L.J. (2014) Reaaliaikainen kuvaprosessointi robottihelikopterissa. Oulunyliopisto, Tietotekniikan osasto. Diplomityö, 54 s.

TIIVISTELMÄ

Kameran kalibrointi on menettely, jolla selvitetään kameran tuottamien kuvapis-teiden ja kameralla kuvatun näkymän geometrian suhde. Tavallisesti suhde esi-tetään kameramallin avulla. Tyypillisesti kalibrointimenetelmät sovittavat jonkinkameramallin parametrit vastaamaan kameran kuvista tehtyjä havaintoja. Ka-librointi on tarpeellinen, mikäli kameran kuvasta mitataan geometrisia suureita.

Tässä työssä toteutetaan ohjelmisto, joka noudattaa Oulun yliopiston konenäöntutkimuskeskuksessa kehitettyä kameramallia. Ohjelmiston avulla AR.Drone 2.0-robottihelikopterin kameralle suoritettua kalibrointia voi hyödyntää AR.Drone2.0:n omalla suorittimella. Ohjelmisto sopii myös muihin sulautettuihin järjestel-miin ja PC-tietokoneisiin.

Taustatietona tarkastellaan olemassa olevia kameramalleja ja verrataan to-teutuksen noudattamaa kameramallia näihin malleihin. AR.Drone 2.0:n laitteis-toa ja ohjelmistoa tarkastellaan toteutettavan ohjelmiston kohdealustana toimi-misen näkökulmasta. Toteutetuista kuvankäsittelymenetelmistä esitetään perus-toteutus ja sitä nopeuttavia optimointeja. Erityisesti ohjelmiston ja suorittimenvälimuistin vuorovaikutukseen kiinnitetään huomiota. Valittujen menetelmientodetaan soveltuvan myös jaettavaksi usealle suoritinytimelle rinnakkaiseen las-kentaan. Lopuksi toteutetun ohjelmiston suorituskykyä arvioidaan sekä ARM-suoritinarkkitehtuuria edustavissa sulautetuissa järjestelmissä että PC-työase-missa.

Toteutetulla ohjelmistolla voi korjata kalibroidun kameran kuvia perspektii-vimallin mukaiseksi. ARM Cortex-A8 -suorittimella ohjelmisto kykenee korjaa-maan AR.Drone 2.0:n kameran tuottamia kuvia reaaliajassa.

Avainsanat: kameran kalibrointi, sulautettu järjestelmä, välimuistin optimointi

Sarajärvi L.J. (2014) Real time image processing in a robot helicopter. Universityof Oulu, Department of Computer Science and Engineering. Master’s thesis, 54 p.

ABSTRACT

Camera calibration is a means of finding out the relationship between pixels pro-duced by a camera and the geometry of the scene that is imaged. Usually therelationship is expressed as a camera model. Typically, calibration techniques fitthe parameters of a specific camera model to match observations made from im-ages produced by a camera. A calibration should be performed for a camera ifimages produced by it are used for measurement of geometric attributes.

In this work, a camera model developed at the Center for Machine Vision Re-search of Oulu University is implemented in software. The implemented softwarecan be run on the AR.Drone 2.0 robot helicopter, enabling application of calibra-tion to the camera that is used in the device. The software is also suitable for beingrun in other embedded systems and in conventional personal computers.

For background, a number of existing camera models are discussed. The modelused in the software implementation is compared to other models. The computerhardware and software present in the AR.Drone 2.0 is discussed from the point ofview of writing software for them. Of the implemented algorithms, both a basicimplementation and various optimiziation techniques are described. This thesisfocuses on the interaction between software and the CPU caches. A descriptionon how the algorithms are suitable for concurrent processing on multiple CPUcores is given. Finally, the performance of the implemented software is evaluatedon ARM-based systems and personal computers.

The software implemented as part of the work can be used for correcting im-ages produced by a calibrated camera to obey the perspective model. On an ARMCortex-A8 CPU, the images taken by an AR.Drone 2.0 can be corrected in realtime.

Keywords: camera calibration, cache optimization, embedded system

SISÄLLYSLUETTELO

TIIVISTELMÄ

ABSTRACT

SISÄLLYSLUETTELO

ALKULAUSE

LYHENTEIDEN JA MERKKIEN SELITYKSET

1. JOHDANTO 8

2. KAMERAN KALIBROINTI 102.1. Kameramallit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1. Geneeriset kameramallit . . . . . . . . . . . . . . . . . . . . 112.1.2. Aksiaaliset kameramallit . . . . . . . . . . . . . . . . . . . . 112.1.3. Pistemäiset kameramallit . . . . . . . . . . . . . . . . . . . . 12

2.2. Perspektiivikameramalli . . . . . . . . . . . . . . . . . . . . . . . . 132.3. Laajennettu perspektiivimalli . . . . . . . . . . . . . . . . . . . . . . 142.4. Xiong-Turkowski -malli . . . . . . . . . . . . . . . . . . . . . . . . 142.5. Kannala-Brandt -malli . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5.1. Mallin yksityiskohdat . . . . . . . . . . . . . . . . . . . . . . 152.5.2. Käänteinen malli . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6. Mallin valinta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3. KUVAPROSESSOINTI SULAUTETUSSA OHJELMISTOSSA 183.1. Kohdejärjestelmän kuvaus . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.1. OMAP3630 . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.2. ARM Cortex-A8 . . . . . . . . . . . . . . . . . . . . . . . . 183.1.3. Signaalinkäsittelysuoritin . . . . . . . . . . . . . . . . . . . . 183.1.4. AR.Drone 2.0:n vakio-ohjelmistot . . . . . . . . . . . . . . . 19

3.2. Yhteensopivuus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3. Välimuisti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4. Ohjelmointikielet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5. Pohdinta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4. KEHITETTY OHJELMISTO 264.1. Twirl-kirjasto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1.1. Polynomit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1.2. Matriisit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1.3. Kannala-Brandt -mallin toteutus . . . . . . . . . . . . . . . . 314.1.4. Kuvan korjaus perspektiivimallin mukaiseksi . . . . . . . . . 314.1.5. Korjauksen hakutaulukko-optimointi . . . . . . . . . . . . . 33

4.2. Twirr-kirjasto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3. Käyttöliittymät ja testaus . . . . . . . . . . . . . . . . . . . . . . . . 36

5. TULOKSET 395.1. Testiympäristöt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2. Kalibrointi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3. Tarkkuus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4. Laskennalliset resurssit . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.4.1. Ohjelmiston koko . . . . . . . . . . . . . . . . . . . . . . . . 445.4.2. Keskusmuistikapasiteetti . . . . . . . . . . . . . . . . . . . . 455.4.3. Kuvan korjaus perspektiivimallin mukaiseksi . . . . . . . . . 465.4.4. Hakutaulukko-optimoitu kuvan korjaus . . . . . . . . . . . . 465.4.5. Rinnakkainen kuvan korjaus . . . . . . . . . . . . . . . . . . 475.4.6. Rinnakkainen hakutaulukko-optimoitu kuvan korjaus . . . . . 475.4.7. Hakutaulukkohaun PLD-optimointi Cortex-A8:ssa . . . . . . 48

5.5. Pohdinta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6. YHTEENVETO 51

7. LÄHTEET 53

ALKULAUSE

Tämä diplomityö kirjoitettiin keväällä 2014 Oulun yliopiston tietotekniikan osastolle.Haluan kiittää ohjaajiani Jari Hannukselaa ja Jani Boutellieria kannustavasta ja raken-tavasta opastuksesta. Lisäksi kiitän Juho Kannalaa ja Antti Tikanmäkeä asiantuntija-avusta työhön liittyvien teknisten yksityiskohtien selvittämisessä. Työnantajaani Em-belin Oy:ta kiitän mahdollisuudesta järjestää opintojen ohessa työskentelyni niin, ettätyön loppuun saattaminen tänä keväänä tuli mahdolliseksi. Lämpimät kiitokset ansait-see myös vaimoni Kati, jonka piristävä tuki on toistuvasti kannustanut selvittämäänhankalatkin ongelmat.

Oulussa 22. toukokuuta 2014

Joonas Sarajärvi

LYHENTEIDEN JA MERKKIEN SELITYKSET

(a, b)T SarakevektoriARM ARM Holdings:n kehittämä suoritinarkkitehtuuriDRAM Dynamic Random Access MemoryGCC GNU Compiler CollectionGiB Gibitavu, 1073741824 tavuaKiB Kibitavu, 1024 tavuaMiB Mebitavu, 1048576 tavuaOMAP Open Multimedia Applications PlatformPNG Portable network graphics, kuvatiedostoformaattiSoC System-on-ChipSRAM Static Random Access Memory(u, v)T Kuvapisteen sijainti pikseleissäWLAN Wireless Local Area Network, langaton lähiverkkox86 Intel 386-suorittimen kanssa yhteensopivat suoritinarkki-

tehtuuritx86-64 x86-suoritinarkkitehtuurin 64-bittinen laajennosx = (x, y)T Kuvapisteen sijainti kameran sensorissa

8

1. JOHDANTO

Viime vuosina markkinoille on ilmaantunut suuret määrät edullisia, alle tuhannen eu-ron hintaisia pienoisilma-aluksia, joita periaatteessa kuka hyvänsä asiasta kiinnos-tunut pystyy hankkimaan ja käyttämään. Leluluonteisten tuotteiden lisäksi saatavillaon myös vakavammin otettavaksi tarkoitettuja laitteita, joilla esimerkiksi voi edullises-ti ottaa ilmakuvaa lähiympäristöstä.

Yksi suosittu tuote on Parrot:n valmistama AR.Drone 2.0 -lentolaite, joka on allepuolen kilogramman painoinen, neljällä roottorilla lentävä ns. nelikopteri. Laite sisältäätietojärjestelmän, joka WLAN-yhteyttä käyttäen vastaanottaa käyttäjältä ohjausko-mentoja ja lähettää reaaliaikaista videokuvaa kameroistaan. Laite on sellaisenaanpitkälle tuotteistettu, eikä sen ohjaaminen vaadi erityistä harrastuneisuutta pienoisil-mailuun. [1]

AR.Drone 2.0:n ohjaamiseen käytetään normaalisti WLAN-yhteyttä hyödyntävääälypuhelinsovellusta. Laite kykenee ilman ulkoista ohjausta pitämään itsensä vakaanapaikallaan, mutta suuri osa toiminnasta perustuu käyttäjältä, lentolaitteen ulkopuoleltavastaanotettuihin komentoihin. Mielenkiintoiseksi erilaisiin harraste- ja tutkimuspro-jekteihin AR.Drone 2.0:n tekevät laitteen matala noin 300 euron hinta ja se, että oh-jaamiseen käytettävät protokollat ovat julkisesti saatavilla [2]. Protokolladokumen-taatio on parantanut Parrotin ulkopuolisten tahojen mahdollisuuksia kehittää omiatyökaluja laitteen ohjaamiseen.

Viestiliikennettä laitteen kameroiden, sensorien, ohjainpiirien ja WLAN-liitännänvälillä ohjaa AR.Drone 2.0:ssa OMAP3630 -piiri, jossa suoritetaan Linuxiin perustu-vaa käyttöjärjestelmää [3]. Piirin 1 GHz kellotaajuudella toimiva Cortex-A8 -suoritinon laskentakapasiteetiltaan vastaava kuin esimerkiksi monien älypuhelinten suorit-timet. AR.Drone 2.0:n sisäistä ohjelmistoa ei varsinaisesti ole tarkoitettu käyttäjänvaihdettavaksi, mutta niin pystyy tekemään laitteen tarjoamista verkkorajapinnoista.Tämän takia laite on houkutteleva kokeilualusta erilaisiin lentäviä robotteja koskeviinprojekteihin.

Mikäli AR.Drone 2.0:n tai muun vastaavan laitteen haluttaisiin kykenevän suorit-tamaan tehtäviä itsenäisesti ilman jatkuvaa ulkopuolista ohjausta, voitaisiin videoku-vaa lähettävät toiminnot korvata laitteen sisäisessä suorittimessa toimivalla automaat-tiohjauksella. Automaattiohjauksen avulla laite voisi suunnistaa haluttuun kohteeseenja sieltä takaisin itsenäisesti. Maanpinnan lähellä ilma-alusta ei kuitenkaan voi ohja-ta pelkästään esimerkiksi GPS-paikannuksen avulla, vaan laitteen tulee esimerkiksipystyä havaitsemaan ja kiertämään ympärillä olevat esteet.

Usein ympäristön kartoittamiseen kameran kuvan avulla käytetyt menetelmät vaa-tivat tai vähintään hyötyvät siitä, että kuvasta havaittujen piirteiden suunnat suh-teessa kameraan tunnetaan riittävän tarkasti. Perinteistä perspektiivimallia noudat-tavien kameroiden optiikassa esiintyy kuitenkin tyypillisesti vääristymää, joka heiken-tää mittausten tarkkuutta erityisesti kuvien reuna-alueilla. Esimerkiksi AR.Drone 2.0:nkameran kuvissa vääristymä on todettavissa silmämääräiselläkin tarkastelulla. Lisäksiosa laajakulmaisista kameraratkaisuista ei noudata perspektiivimallia lainkaan.

Kuvasta havaittujen piirteiden koordinaatit voidaan määrittää tarkemmin, jos kame-ra kalibroidaan. Kalibroidusta kamerasta tunnetaan tarkasti, missä suunnassa mikäkinhavaittu esine on. Kalibrointi tapahtuu usein soveltamalla mallia, joka huomioi edellämainitut vääristymät. Sopivia malleja on vuosien aikana kehitetty lukuisia [4]. Usein

9

mallin toteutus saattaa olla esimerkiksi Matlab-ohjelma, jonka ajaminen AR.Dronenkaltaisessa sulautetussa järjestelmässä on vaikeaa. Muita kuin Matlabilla toteutettujaratkaisuja vääristymien korjaamiseen on saatavilla esimerkiksi OpenCV -projektista,mutta nekään eivät ole toteutettu erityisesti sulautettuja järjestelmiä silmälläpitäen.

Tässä työssä toteutetaan AR.Drone 2.0-lentolaitteeseen tai muuhun vastaavaan su-lautettuun järjestelmään soveltuva kuvankorjausohjelmisto, joka noudattaa Oulun yli-opiston konenäköryhmässä [5] kehitettyä menetelmää. Ohjelmisto mahdollistaa pers-pektiivimallista poikkeavien kuvien korjaamisen perspektiivimallin mukaisiksi, mikähelpottaa kuvatun esineen tai ympäristön geometrian mittaamista. Lisäksi kuvan kor-jaaminen perspektiivimallin mukaiseksi on usein hyödyllistä esimerkiksi yhdisteltäessäsuurempi panoraamakuva useasta pienestä kuvasta.

AR.Drone 2.0 sisältää kaksi kameraa. Kameroista tarkempi osoittaa eteen päin jatuottaa 30 1280x720 pikselin kuvaa sekunnissa. Alas päin osoittava kamera tuottaakuvia jopa 60 kappaletta sekunnissa, mutta on tarkkuudeltaan vain 320x240 pikseliä.Kuvadataa on siis paljon käsiteltäväksi yhdellä 1 GHz suorittimella. Mikäli AR.Drone2.0:ssa toimiva ohjelmisto tarvitsisi tietoa jokaisesta etukameran kuvasta esimerkiksioman nopeutensa seuraamiseen, sille jäisi noin 33 millisekuntia yhden kuvan käsit-telyyn. Kellosykleinä tämä olisi kymmeniä miljoonia, mutta etukameran kuvassa onpikseleitäkin lähes miljoona.

Käsiteltävän kuvadatan määrää voi tarvittaessa pienentää alinäytteistämällä videoku-vaa paikkatasossa tai jättämällä osan kuvista käsittelemättä. Tämä on tarkkuudenkannalta kompromissi, mutta useimmissa sovelluksissa suoritinaikaa pitää jättää käytet-täväksi myös muille toiminnoille kuin kuvan perspektiivikorjaustoiminnolle. Jotta ta-sapainoilua laskennan nopeuden ja tarkkuuden välillä tarvitsisi tehdä mahdollisimmanvähän, kiinnitetään toteutettavan ohjelmiston suorituskykyyn paljon huomiota.

Työn aluksi kuvataan erilaisia kameran kalibrointiin käytettyjä kameramalleja. Tä-män jälkeen tutustutaan AR.Drone 2.0:n tarjoamaan laitteistoon ja siihen, minkälaisetvalmiudet ohjelmistojen suorittamiseen AR.Drone 2.0 tarjoaa. Kun oleellisimmat työ-hön liittyvät taustatiedot on käsitelty, esitellään työn osana toteutetun ohjelmistonteknisiä ratkaisuja. Lopuksi tarkastellaan toteutetun ohjelmiston suorituskykyä ja sovel-tuvuutta käyttötarkoitukseensa.

13

Mikäli tunnetaan kameran R3-koordinaatistossa oleva piste (x, y, z), voidaan edellämainitun merkintätavan mukainen esitys tulokulmalle laskea sijoittamalla x, y ja zpiste yhtälöön

Φ =

(θφ

)=

(arctan(

√x2 + y2, z)

arctan(y, x)

). (2)

Yhtälössä (2) käytetään kaksiparametrista arctan-funktiota, joka tässä työssä määritel-lään perinteisen yksiparametrisen arctan-funktion kautta yhtälön

arctan(y, x) =

arctan(y/x) : x > 0π/2 : x = 0, y > 0π + arctan(y/x), : x < 0,−π/2 : x = 0, y < 00 : x = 0, y = 0

(3)

mukaisesti. Määritelmän arctan(0, 0) = 0 -haara on mielivaltaisesti valittu. Käytän-nössä tässä työssä ei ole väliä sillä, mikä arvo φ-kulmalle valitaan silloin kun valonsädetulee suoraan kameran edestä.

Kannalan ym. [12] mukaan myös useimmat sellaiset kamerat, jotka eivät ole pis-temäisiä, ovat kuitenkin häviävän pieniä verrattuna kameralla kuvattavaan järjestel-mään. Tällaisessa tilanteessa kameraa voidaan kohdella pistemäisenä ja käyttää pis-temäistä kameramallia.

2.2. Perspektiivikameramalli

Kameramalleista mahdollisesti perinteisin on pistemäisiin kameramalleihin kuuluvaperspektiivikameramalli, joka on tunnettu jo ainakin renessanssista asti [11]. Pers-pektiivimallin mukaista kameraa kutsutaan perspektiivikameraksi. Vaikka perspek-tiivikameramalli muistuttaa suuresti perinteisen neulanreikäkameran geometriaa, onGrossbergin mukaan myös muita kameroita rakennettu siten, että ne noudattavat samaamallia [11]. Myös Kannalan ym. [12] mukaan perspektiivikameramallia voi soveltaauseimpiin tavanomaisiin kameroihin.

Perspektiivikameramalli noudattaa yhtälöä(xy

)=

(f ∗X/Zf ∗ Y/Z

), (4)

missä (x, y)T on kuvapisteen sijainti kameran sensorissa, f on kameran polttoväli ja(X, Y, Z)T on kuvatun pisteen sijainti. [13 s. 154]

Hartleyn ja Zissermanin mukaan perspektiivikameran kuvaamien tasojen kuvautu-minen kuvatasoon voidaan esitttää P2:n projektiivisena muunnoksena. Projektiivinenmuunnos kuvaa suorat suoriksi. [13 s. 25] Tämän lisäksi perspetiivikameran tuot-tamaan kuvaan voidaan soveltaa myös muita projektiiviseen geometriaan nojaaviamenetelmiä.

Kannalan mukaan perspektiivikameraa voi pitää suuntailmaisimena, joka kuvaakunkin kameraan tulevan valonsäteen suunnan joksikin pikseliksi seuraavan yhtälön(

xy

)= tan(θ)

(cos(φ)sin(φ)

)(5)

14

mukaisesti. Kannalan mukaan yhtälön perusteella on selvää, että perspektiivikamerankuvakulman laajuus voi olla puolipalloa suurempi. Jos θ -kulma lähestyisi ääretöntä,kasvaisi (x, y)T -vektorin pituus äärettömän suureksi. [8]

Devernayn ja Faugeras:n [7] mukaan useimmat kolmiulotteisen konenäön algoritmithyödyntävät perspektiivimallia. Grossberg:n ja Nayar:n [9] mukaan sekä optiikkaa ettäkonenäköä kehitettäessä on keskitytty juuri perspektiivimallin ominaisuuksiin. Lisäksiesimerkiksi Fitzgibbon [14] esittää algoritmeja, joiden tarkkuus edellyttää, että kuvienvastinpisteet haetaan perspektiivimallin mukaisista kuvista.

Koska perspektiivimalli on yksinkertainen, yleinen ja hyvin tunnettu, usein kuvakorjataan perspektiivimallin mukaiseksi.

2.3. Laajennettu perspektiivimalli

Koska suuressa osassa perspektiivimallin mukaisiksikin tarkoitettuja kameroita esi-intyy perspektiivimallin vastaisia vääristymiä, on usein päädytty laajentamaan per-spektiivimallia rakenteilla, jotka huomioivat nämä vääristymät. Mikäli malliin lisä-tyt rakenteet saadaan sovitettua vastaamaan jossain tunnetussa kamerassa esiintyviävääristymiä, voidaan mallin avulla korjata vääristymiä pois kuvasta. Vaihtoehtoisestivoidaan korjata vääristyneestä kuvasta havaittuja koordinaatteja vastaamaan paremminkuvattujen esineiden todellisia sijainteja.

Laajennoksia perspektiivimallille on esitetty useita. Esimerkiksi Heikkilä ja Sil-vén [15] ovat käyttäneet mallia, jossa perinteisen perspektiivimallin antamaa kame-ratason sijaintia (x, y) vastaa yhtälön(

uv

)= G(x, y) =

[Dusu(x+ x(k1r

2 + k2r4 + . . .) + 2p1xy + p2(r2 + 2x2))

Dv(y + y(k1r2 + k2r

4 + . . .) + p1(r2 + 2y2) + 2p2xy)

](6)

mukainen kuvapiste. Yhtälössä (6) r saadaan suoraan lausekkeesta√x2 + y2, kun taas

{k1, k2, . . .}, p1 ja p2 ovat mallin vääristymän kuvaavia parametreja, jotka voidaanselvittää Heikkilän ja Silvén:n esittämällä kalibrointimenettelyllä.

2.4. Xiong-Turkowski -malli

Xiong ja Turkowski [16] esittivät vuonna 1997 pistemäisen kameramallin, jokapoikkeaa huomattavasti perspektiivikameramallista ja sen laajennoksista. Perspektii-vimallia ei käytetty mallin perustana varsinkin siksi, että se erittäin laajakulmaistenlinssien koko kuva-alaa ei saada perspektiivimallilla mallinnettua.

Malli esittää yhtälön (1) kaltaisten (θ, φ) -parien kuvautumisen valosensorin pinnalleyhtälön. (

xy

)= r(θ)

(cos(φ)sin(φ)

)(7)

mukaisesti. Yhtälössä (7) funktio r(θ) kuvaa kameran akselin ja valonsäteen välisenkulman etäisyydeksi sensorin keskipisteestä yhtälön

r(θ) = c1θ + c2θ2 + c3θ

3 + . . . (8)

16

missä r(θ) on yhtälön

r(θ) = k1θ + k2θ3 + k3θ

5 + k4θ7 + k5θ

9 + . . . . (11)

mukainen parittomia kertoimia sisältävä polynomifunktio. Yhtälöissä (10) ja (11) θ onkameran symmetria-akselin ja kameraan tulevan valonsäteen välinen kulma ja φ kiertosymmetria-akselin ympäri.

Epäsymmetrinen vääristymä mallinnetaan erikseen radiaaliseen ja tangentiaaliseensuuntaan. Radiaaliseen suuntaan vääristymän suuruus on yhtälön

∆r(θ, φ) = (l1θ + l2θ3 + l3θ

5)(i1 cosφ+ i2 sinφ+ i3 cos 2φ+ i4 sin 2φ) (12)

mukainen. Vääristymän suuruus riippuu siis θ:n ja φ:n avulla ilmaistusta havaitun va-lonsäteen tulokulmasta.

Tangentiaaliseen suuntaan epäsymmetrisen vääristymän suuruus kuvataan yhtälön

∆t(θ, φ) = (m1θ +m2θ3 +m3θ

5)(j1 cosφ+ j2 sinφ+ j3 cos 2φ+ j4 sin 2φ) (13)

mukaisesti funktiolla, joka on hyvin samannäköinen kuin yhtälössä (12) esitetty ∆r-funktio. ∆t-funktion kertoimet ovat kuitenkin täysin erilliset.

Yhtälöistä (12) ja (13) voidaan yhdistellä epäsymmetrisen vääristymän aiheuttamanpoikkeaman kuvatasossa kuvaava funktio S yhtälön

s = S(Φ) = ∆r(θ, φ)ur(φ) + ∆t(θ, φ)ut(φ) (14)

mukaisesti.Mallin epäsymmetrisen osan yhdistäminen symmetriseen osaan on esitetty yhtälössä

xd =

(xdyd

)= x + s = r(θ)ur(φ) + ∆r(θ, φ)ur(φ) + ∆t(θ, φ)ut(φ), (15)

missä xd on symmetrisen mallin antaman tuloksen ja epäsymmetristen vääristymiensummavektori, ur(φ) on yksikkövektori kameran sensorin koordinaatistossa radi-aaliseen suuntaan ja ut(φ) on yksikkövektori tangentiaaliseen suuntaan.

Kuvatason koordinaatit valosensorin pikseleiden koordinaateiksi kuvaa malliin sisäl-tyvä affiiniH -muunnos määritellään kertoimien {mu,mv, u0, v0} kautta yhtälön(

uv

)=

[mu 00 mv

](xdyd

)+

(u0

v0

)(16)

mukaisesti. Yhtälön voi järjestää uudelleen muotoon(uv

)= H(xd, yd) =

(mu ∗ xd + u0

mv ∗ yd + v0

). (17)

2.5.2. Käänteinen malli

Yhtälössä (15) määritelty malli on funktio, joka kuvaa kameran keskipisteen läpikulkevien valonsäteiden kulmat sijainneiksi kameran sensorikennolla. Usein on kui-tenkin myös tarpeen selvittää, mitä valonsädettä jokin pikseli vastaa. Tämän kulman

17

laskemisesta kutsutaan käänteiseksi projisoinniksi (eng. backprojection). Yhtälöä (9)vastaava käänteinen projisointi voidaan kuvata yhtälön(

θφ

)= P−1

c (u, v) = (F−1 ◦ D−1 ◦ H−1)(u, v) (18)

mukaisella P−1c -funktiolla, jonka komponentit ovat suoraan yhtälön (9) käänteisope-

raatioita. Kannalan ja Brandt:n [5] mukaan F−1 ja H−1 ovat suoraviivaiset laskea.Haasteellisempi on D−1, mutta sitä voi approksimoida seuraavasti:

D−1(xd) ' xd−

(I +

(∂S∂Φ◦F−1

)(xd)

((∂F∂Φ◦F−1

)(xd)

)−1)−1

(S ◦F−1)(xd)

(19)Yhtälössä (15) ∂S

∂Φon yhtälön

∂S∂Φ

=

(∂sx∂θ

∂sx∂φ

∂sy∂θ

∂sy∂φ

)(20)

mukainen osittaisderivaattamatriisi ja ∂F∂Φ

on yhtälön

∂F∂Φ

=

(∂x∂θ

∂x∂φ

∂y∂θ

∂y∂φ

)(21)

mukainen osittaisderivaattamatriisi.

2.6. Mallin valinta

AR.Drone 2.0:n etukameralle aksiaaliset ja täysin geneeriset kameramallit ovat tarpeet-toman joustavia, koska käytännössä kameraa voi sen fyysisten mittojen takia pitääpistemäisenä. Puhdas perspektiivimalli sopisi AR.Drone 2.0:n kameralle huonosti.Kameran kuvissa on perspektiivimallista poikkeavaa vääristymää niin paljon, että seon helposti havaittavissa silmämääräisestikin tarkasteltuna. Jokin perspektiivimallinvääristymiä huomioiva laajennus olisi mahdollinen, koska kameran kuva ei yllä π

2

poikkeamiin kameran keskilinjasta.Tässä työssä sovelletaan edellä esiteltyä Kannala-Brandt -kameramallia. Malli sovel-

tuu Kannalan ja Brandt:n [5] mukaan soveltuu tavanomaisille kameroille yhtä hyvinkuin perinteisemmät kameramallit. AR.Drone 2.0:n kamera ei ole niin laajakulmainenettä Kannala-Brandt -mallin sopivuudella kalansilmälinsseille olisi tässä sovelluksessamerkitystä. Mahdollisuus myös kalansilmälinssien käyttämiseen jossain muussa sovel-luksessa tai esimerkiksi optiikaltaan muunnellussa AR.Drone 2.0:ssa on hyödyllinenpiirre. Lisäksi mallin odotetaan olevan yksinkertaisempi, kuin vääristymän huomioivak-si laajennettu perspektiivikameramalli.

18

3. KUVAPROSESSOINTI SULAUTETUSSA OHJELMISTOSSA

Tässä osassa työtä kuvataan seikkoja, jotka huomioidaan kirjoitettaessa ohjelmistoa su-laututettuun järjestelmään tai muuhun ympäristöön, jossa laskennalliset resurssit ovatrajalliset. Muut sulautettujen järjestelmien erityispiirteet jäävätkin toteutettavan ohjel-miston laskentapainotteisuuden takia vähälle huomiolle.

3.1. Kohdejärjestelmän kuvaus

Työssä kehitetyn ohjelmiston halutaan olevan yhteensopiva erilaisten laitealustojenkanssa. Toisaalta sen suorituskykyyn nimenomaan AR.Drone 2.0:n sisältämässä lait-teistossa kiinnitetään erityistä huomiota. Tässä luvussa esitellään AR.Drone 2.0:n omi-naisuuksia ohjelmoijan näkökulmasta.

3.1.1. OMAP3630

AR.Drone 2.0 sisältämä [3], Texas Instrumentsin kehittämä OMAP3630-piiri on integ-roitu kokonainen tietojärjestelmä eli niinsanottu SoC (eng. System-on-Chip). 1 GHzARM Cortex-A8 -suorittimen lisäksi OMAP3630 sisältää useita muita laitteita yh-tenä kokonaisuutena. Integroituna OMAP3630:ssa on muun muassa 64 KiB SRAM-muistia, USB-isäntäohjain (eng. USB host controller), näytönohjain, SD-korttiliitäntäja erilaisia matalan tason sarjaliikenneliitäntöjä. [18]

Sisäisen SRAM-muistin lisäksi OMAP363 voi hyödyntää ulkoisia SDRAM-muiste-ja [18]. AR.Drone 2.0:ssa SDRAM-muistia on 128 MiB [3].

3.1.2. ARM Cortex-A8

Cortex-A8 on ARM Holdings plc:n kehittämä suoritinydin, joka toteuttaa 32-bittisenARMv7-A -käskykannan. ARMv7-A:n pakollisen toiminnallisuuden lisäksi Cortex-A8 tukee sekä VFPv3-D32 -liukulukukäskyjä että NEON -liukulukukäskyjä. Suorit-timen kellotaajuus on tyypillisesti 600 MHz - 1 GHz. L1 -välimuistia suorittimessaon 32 tai 64 kilotavua datalle ja 32 tai 64 kilotavua käskyille. L2-välimuistin koko onlaitevalmistajan mukautettavissa, mutta sitä voi olla korkeintaan 1 MiB. [19]

ARDrone 2.0:n OMAP3630 -SoC sisältämässä Cortex-A8:sa välimuistien kapa-siteetit on valittu siten, että L1-välimuistit ovat 32 KiB kokoisia ja L2-välimuistin kokoon 256 KiB [18].

3.1.3. Signaalinkäsittelysuoritin

OMAP3630-piiriin sisältyy komponenteista on IVA 2.2-signaalinkäsittelylohko, jo-ka perustuu Texas Instruments:n TMS320DMC64X+ -suorittimeen. Suoritin on 32-bittinen kiinteäpisteistä aritmetiikkaa käyttävä signaalinkäsittelysuoritin, joka on op-

19

timoitu erityisesti kuvan- ja videonkäsittelyyn. Suoritin pystyy suorittamaan jopakahdeksan operaatiota kellosyklissä. [18].

Tässä työssä signaalinkäsittelysuoritinta ei juuri huomioida, koska ohjelmistokehi-tys signaalinkäsittelysuorittimille vaatii usein enemmän työtä kuin vastaavan ohjelmis-ton kehittäminen yleiskäyttöiselle suorittimelle. Ohjelmistokehitys signaalinkäsittely-suorittimelle vaatii usein suoritinkohtaisia erikoistyökaluja ja erityisosaamista. Yleis-käyttöiselle suorittimelle ohjelmoitaessa työkalut ovat kehittäjille usein ennalta muistaprojekteista tuttuja. Työssä kehitetyn ohjelmiston osalta työmäärää olisi kasvattanuterityisesti TMS320DMC64X+-suorittimen vaatima kiinteän pisteen aritmetiikan käyt-tö.

Voi olla, että toteutettu ohjelmisto tai osia siitä lopulta on sovitettavissa signaalinkä-sittelysuorittimelle. Alustana TMS320DMC64X+:a yleisemmät tavanomaiset ARM-suorittimet ovat kuitenkin ainakin projektin alkuvaiheessa paljon houkuttelevampikohdealusta.

3.1.4. AR.Drone 2.0:n vakio-ohjelmistot

Parrot:n mukaan [1, 3] AR.Drone 2.0 -laitteeseen sisältyy Linux. Ohjelmistoa ei kui-tenkaan ole dokumentoitu muuten kuin sen käyttämien verkkoprotokollien osalta [2].Jotta toteutetun ohjelmiston soveltuvuutta vakio-ohjelmiston rinnalle voitaisiin arvioi-da, suoritettiin työn osana katsaus erään AR.Drone 2.0-yksilön sisältöön.

AR.Drone 2.0 toimii normaalisti avoimena WLAN-tukiasemana, johon normaalistilaitetta käytettäessä yhdistetäisiin älypuhelimella laitteen ohjaamista varten [3]. Myösmuita WLAN-sovittimella varustettuja laitteita voi kuitenkin käyttää. Tässä kuvattuatarkastelua varten laitteeseen yhdistettiin kannettavalla tietokoneella.

Luomassaan WLAN-verkossa AR.Drone 2.0 tarjoaa muun muassa telnet-palvelun,jonka kautta voi vuorovaikuttaa laitteen kanssa tekstipohjaisen käyttöliittymän kaut-ta. Kun laitteeseen yhdistää telnet-asiakasohjelmalla, päästää AR.Drone 2.0 ilmansalasanakyselyä käyttämään AR.Drone 2.0:ssa suoritettavaa BusyBox -komentoke-hottetta. Kehotteen kautta voi suorittaa muita AR.Drone 2.0-järjestelmään sisältyviäohjelmia. Komentokehote suoritetaan käyttöjärjestelmän pääkäyttäjänä, joten järjes-telmää pystyy tutkimaan hyvin esteettömästi.

Tietoturvan kannalta voi pitää arveluttavana laitetta, joka käynnistyttyään automaat-tisesti luo avoimen WLAN-verkon ja lisäksi antaa ilman salasanakyselyä suorittaakomentokehotteen kautta mitä tahansa laitteen ohjelmistoja pääkäyttäjänä. Ratkaisunsuojaamattomuus kuitenkin luultavasti haittaa laitteen käyttäjiä hyvin vähän, kos-ka normaalissa käytössä AR.Drone 2.0:n tietojärjestelmä on käynnissä vain jotainkymmeniä minuutteja kerrallaan. Tämän työn kannalta ratkaisu on erittäin käytän-nöllinen, koska se mahdollistaa sekä vakio-ohjelmiston tutkimisen että mahdollisenmuokkaamisen ja korvaamisen.

Komentokehotteesta järjestelmää tutkimalla havaitaan, että suuri osa järjestelmänkomentorivityökalusta hakemistoissa /bin, /sbin, /usr/bin ja /usr/sbin ovat symbolisialinkkejä /bin/busybox -työkaluun. Tämä on normaali käytäntö järjestelmässä, jossaBusyBoxia käytetään toteuttamaan suuri osa Linux-ytimen ulkopuolisesta käyttöjär-jestelmästä.

20

Järjestelmästä tarkasteltiin ajossa olevia prosesseja. Havaittiin, että prosessien lu-kumäärä on noin 20. Määrä on Linuxiin perustuvalle järjestelmälle pieni. Suurin osaprosesseista, esimeriksi tutkimisen mahdollistava telnetd -prosessi ja WLAN-verkonosoitteita jakava udhcpd-palvelin, ovat BusyBoxin osia.

Järjestelmän vapaan muistin määrä selvitettiin free-komennolla, jonka tuloste on lis-tauksessa 1. Listauksen perusteella muistista on vakio-ohjelmistolla käytettynä noinkolme neljäsosaa. Käyttämätöntä muistia on 20328 KiB, eli noin kaksikymmentämegatavua. Ohjelmiston lisäämisen kannalta selvästi tarpeellista on, että lisättävätohjelmistot eivät käytä kymmeniä megatavuja muistia. Jonkin verran muistia olisitarpeen jättää myös käyttämättä.

total used free shared buffersMem: 118268 97940 20328 0 0Swap: 0 0 0Total: 118268 97940 20328

Listaus 1. Keskusmuistin käyttö AR.Drone 2.0:n vakio-ohjelmistossa.

Keskusmuistin lisäksi myös tallennustilaa laitteessa on rajallisesti. Listauksessa 2olevan df-komennon tulosteen perusteella käyttämätöntä levytilaa on ohjelmisto-osiollanoin 12 megatavua ja erillisellä dataosiolla noin 50 megatavua. Tilan arvioidaan olevanenemmänkin kuin riittävä pienelle määrälle ylimääräisiä laskentarutiineja.

Filesystem Size Used Available Use% Mounted onubi1:system 26.3M 12.8M 12.2M 51% /tmp 57.7M 632.0K 57.1M 1% /tmpdev 57.7M 0 57.7M 0% /devubi0:factory 4.8M 80.0K 4.5M 2% /factoryubi2:update 13.2M 28.0K 12.5M 0% /updateubi2:data 53.5M 1.0M 49.8M 2% /data

Listaus 2. Tallennustilan käyttö AR.Drone 2.0:n vakio-ohjelmistossa.

Kattava käsitys AR.Drone 2.0:n vakio-ohjelmiston toiminnasta vaatisi huomattavastiperusteellisempaa tutkimista, kuin mitä tässä on tehty. Tässä esitetty katsaus kuitenkinvähäisessä määrin havainnollistaa, minkälaisesta Linuxiin perustuvasta järjestelmästäon kyse. Pääpiirteissään järjestelmä näyttäisi olevan rakennettu lähinnä Linux-käyttö-järjestelmäytimen ja BusyBoxin päälle. Tämäntyyppinen yhdistelmä on melko yleinenja laajasti tunnettu.

3.2. Yhteensopivuus

Kuvankäsittelyalgoritmit itsessään eivät edellytä minkäänlaista vuorovaikuttamista ul-komaailman kanssa. Tämän takia toteutettava ohjelmisto kannattaakin rakentaa siten,että laskentaa tekevät osat eivät suoraan liity käyttöjärjestelmään. Ohjelmisto tarvitseeliitännän laskennan parametrien siirtämiseen ohjelmistoon sisään ja ulos, mutta se onsyytä tehdä mahdollisimman geneerisiksi ja laitteisto- ja käyttöjärjestelmäriippumat-tomaksi. Koska AR.Drone 2.0:n käyttöjärjestelmä perustuu Linux-ytimeen, on syytävarmistaa että toteutettu ohjelmisto soveltuu vähintään Linux-ympäristöön.

21

Vaikka ohjelmiston toisaalta haluttaan toimivan riittävän nopeasti juuri tietyntyyp-pisellä ARM-suorittimella, haluttiin sen olevan helposti hyödynnettävissä myös muun-laisella laitteistolla. Markkinoilla olevien robottihelikoptereiden tarjoamat suorittimetvoivat ajan kuluessa vaihtua, ja kameran kalibrointia voi muutenkin hyödyntää ro-bottihelikopterisovellusten ulkopuolella. helpottavan ohjelman hyödyntämistä muissakuin tämän työn esittämässä Lisäksi mahdollisuus suorittaa ohjelmaa tai sen osia ta-vanomaisella PC-työasemalla helpottaa koko kehitysprosessia.

Osassa suorittimia, erityisesti sulautettuihin järjestelmiin tarkoitetuissa, ei ole liuku-lukulaskentayksikköä. Liukulukujen laskentaoperaatioiden käyttäminen tällaisella suo-rittimella voi olla hidasta. Esimerkiksi Iordachen ja Tang:n [20] mukaan tehokasohjelmistopohjainen liukulukujen toteutus ARMv5 -käskykannan toteuttavalle IntelXScale-suorittimelle käyttää yli 30 kellosykliä liukulukujen yhteenlaskuun.

Työssä kehitettävän ohjelmiston halutaan toimivan, mikäli vähintään normaalintarkkuuden liukulukuoperaatiot ovat kohdealustalla käytettävissä. Vaikka työssä ontarkoitus toteuttaa siirrettävä ohjelmisto, voidaan hyväksyä se että se toimii hitaam-min laitteistolla joka soveltuu huonosti liukulukujen laskemiseen.

3.3. Välimuisti

Nykyaikaisen tietokoneen keskusmuisti on lähes aina hidasta verrattuna suorittimenomaan laskentakapasiteettiin. Tämän takia muistia lukeva tai kirjoittava operaatio voikestää satoja suorittimen kellosyklejä. Käytännön sovellukset vaativat yleensä suhteel-lisen suurikapasiteettista muistia, mutta sekä nopeudeltaan että kapasiteetiltaan suu-ret muistit ovat epäkäytännöllisen kalliita. Tyypillisesti tietokoneet piilottavat suurika-pasiteettisen keskusmuistin pitkän vasteajan käyttämällä pienikapasiteettista, nopeaamuistia välimuistina. Välimuisti on yleensä toteutettu niin, että sen toiminta on ohjel-moijalle läpinäkyvää. Järjestys, jossa ohjelma käsittelee muistissa olevaa tietoa, voikuitenkin vaikuttaa ohjelmiston suorituksen vaatimaan aikaan jopa useita suuruusluok-kia. [21]

Tyypillisesti välimuistin kannalta muisti on jaettu välimuistiriveihin (eng. cacheline), jotka tavallisimmin ovat 64 tavun kokoisia. Osasta keskusmuistin sisällöstä pi-detään kopioituna välimuistiin. Kun suoritin pyytää muistista tietoa josta on kopiovälimuistissa, tilannetta kutsutaan välimuistiosumaksi (eng. cache hit). Välimuistiosu-man tapauksessa tietoa muistista lataava käsky saadaan suoritettua nopeasti, koska hi-dasta keskusmuistia ei jouduta odottamaan. Kun muistista tarvitaan sellaista dataa jokaei satu olemaan välimuistissa, joudutaan välimuistihuti (eng. cache miss) käsittelemäänlataamalla haettu tieto keskumuistista. [21]

DRAM-muistin liitäntä tyypillisesti vaatii useita muistin kellosyklejä, että muis-tiväylää pitkin lähetetty komentosekvenssi tuottaa muistin sisältöä väylälle. Sekvenssiähieman pidentämällä voidaan kuitenkin ladata kerralla useita tavuja. Välimuistihutikäsitelläänkin yleensä siten, että muistista ladataan halutun tavun tai sanan sisältävävälimuistirivi kokonaisuudessaan välimuistiin. [21]

Mikäli ohjelmiston osassa käsiteltävä tietomäärä mahtuu kokonaan L1d-välimuistiin,ei Drepper:n [21] mittauksissa havaita suurta eroa suorituskyvyssä satunnaisten japeräkkäisten muistinkäsittelyoperaatioiden välillä. Suuremmilla tietomäärillä erot ovatkuitenkin hyvin merkittäviä. Drepper:n käyttämässä esimerkkitapauksessa yksinker-

23

käsittelyjärjestyksen voi valita vapaasti, kannattaa se valita siten että kaikki samaanvälimuistiriviin sisältyvät pikselit käsitellään peräkkäin. Tällöin yhteen välimuistiri-viin sisältyvän pikseliryhmän käsittelyssä muut kuin ensimmäinen käsiteltävä pikseliovat todennäköisesti valmiiksi L1d-välimuistissa kun niitä tarvitaan.

Cortex-A8-suorittimessa ohjelmoija voi tehostaa välimuistimekanismin toimintaakäyttämällä ARMv7-käskykannan PLD-käskyä. PLD-käskyllä suorittimelle kerrotaan,että jostain muistiosoitteesta tullaan lataamaan hetken kuluttua. Dokumentaation mu-kaan Cortex-A8 reagoi PLD-käskyyn lataamalla käskyn parametrina annetun muis-tiosoitteen L2-välimuistiin mikäli se ei jo valmiiksi ole L1d-välimuistissa tai L2-väli-muistissa. [22]

PLD-käskyllä voi vähentää L2-hudista aiheutuvaa viivettä, koska välimuistirivienlataaminen välimuistiin saadaan sen avulla aloitettua jonkin verran ennen kuin setehtäisiin ilman PLD-käskyä. PLD-käskystä saatava hyöty on kuitenkin hyvin suori-tinriippuvainen, koska ARMv7-arkkitehtuuridokumentaation mukaan suorittimen to-teuttajalla on hyvin vapaat kädet sen suhteen, miten käskyyn reagoidaan. Eräs sallitturatkaisu on esimerkiksi jättää käsky kokonaan huomiotta. [23]

Drepper [21] varoittaa ennakkolataamisen olevan haasteellista. Eräs mainittu ongel-ma on, että liiallinen ennakkolataaminen voi korvata välimuistista hyödyllisiä väli-muistirivejä vähemmän hyödyllisillä. Kuvankäsittelyrutiineissa esimerkiksi kuvadatanliiallinen ennakkolataaminen voisi huonontaa suorituskykyä, mikäli ennakkolataami-nen todennäköisesti aiheuttaisi kameran kalibrointiparametrit sisältävän välimuisti-rivin ennenaikaisen poistumisen välimuistista. Lisäksi sopivan latausennakon valit-semiseen joutuu kiinnittämään huomiota. Liian myöhään lataaminen auttaa vain vähän,ja liian aikaisin lataamalla ennakkoladattu tieto saattaa poistua välimuistista ennenkuin se hyödynnetään. Mikäli ennakkolataamista hyödynnetään vain huolella valituis-sa osissa ohjelmistoa, voi niiden hyödyllisyyden varmistaa mittaamalla niistä saatavannopeusedun.

3.4. Ohjelmointikielet

Linux-käyttöjärjestelmäytimen päällä on mahdollista suorittaa ohjelmia, jotka voivatolla toteutettu millä tahansa suuresta joukosta ohjelmointikieliä. Esimerkiksi C, C++,Java ja Python olisivat tarvittaessa käytettävissä. Työssä toteutettava ohjelmisto onkuitenkin erityisen mielekäs toteuttaa matalan tason kielillä, koska toteutettaviin algo-ritmeihin ei liity lainkaan esimerkiksi tietoverkkojen käyttöä tai tekstimuotoisen datankäsittelyä. Toisaalta algoritmit toteutetaan juuri numeerisen laskennan kautta, jolloinon edullista suorittaa ohjelmakoodia suoraan prosessorilla eikä esimerkiksi javan vir-tuaalikoneen tulkkaamana. Lisäksi AR.Drone 2.0:n tapauksessa käytettävän laitteis-ton tallennuskapasiteetti kokonaisuudessaan on 128 MiB, joten korkean tason toteu-tusalustan vaatimat ajonaikaiset kirjastot (eng. runtime) voivat kokonsa puolesta ollaongelmallisia.

Yleinen piirre korkean tason kielissä on myös se, että ohjelmoija ei välttämättä voihelposti vaikuttaa siihen, miten käsiteltävä muisti jaetaan eri osiin muistia. Luvussa 3.3mainitut välimuistien erityispiirteet on siksi helpompi huomioida ohjelmoitaessa mata-lan tason kielillä.

24

Sulautetuissa järjestelmissä yleisiä matalan tason ohjelmointikieliä ovat C ja C++ jasuoritinarkkitehtuurikohtaiset assembly-kielet. Näistä jälkimmäisten käyttäminen onristiriidassa sen kanssa, että toteutettava ohjelma on yhteensopiva erilaisten suorit-timien kanssa. C ja C++ kuitenkin ovat molemmat mahdollisia ratkaisuja.

Sekä C:n että C++:n määritelmissä osa kielen semantiikasta on jätetty kieltä toteut-tavan tahon määriteltäväksi. Esimerkiksi int-muuttujatyypin tallentamiseen jokin to-teutus voi käyttää kaksi tavua, jolloin sen arvoalue olisi kokonaisluvut alkaen luvus-ta -32768 ja päättyen lukuun 32767. Jossain toisessa toteutuksessa int-tyypin kokovoi olla neljä tavua, missä tapauksessa int-tyyppisen muuttujan arvo voisi olla vähin-tään -2147483648 ja korkeintaan 2147483647. Muun muassa tästä, mutta myös muistaeroista johtuen sama ohjelma voi käyttäytyä eri kielen toteutuksilla eri tavalla. Esimer-kiksi listauksen 3 funktio parametrilla 200 palauttaa tuloksenaan luvun -25136, mikäliint-tyypin koko on 2 tavua. Jos taas int-tyypin koko on 4 tavua, saadaan tuloksena40400.

intfoo(int a){return a * a + 2 * a;

}

Listaus 3. Esimerkki funktiosta, jonka toimintaa C-standardi ei kokonaan määrittele.

Ohjelmointikielen toteutuksella tässä työssä tarkoitetaan kaikkia niitä asioita, mitkävaikuttavat eroihin joita kielen määritelmän mukaisesti kirjoitetun ohjelman käyttäy-tymisessä voi havaita. Esimerkiksi GNU GCC 4.8.2 -kääntäjän long-tyyppi on 4 tavunkokoinen ARMv7-suoritimelle ohjelmia kääntävässä kokoonpanossa, mutta 8 tavunkokoinen käännettäessä X86-64:lle. Tämän vuoksi listauksen 4 ohjelma tulostaa eritekstin riippuen siitä, mille suorittemelle se on käännetty.

#include <stdio.h>

int main(){int const i = sizeof(long);printf("size of long is %d\n", i);return 0;

}

Listaus 4. C99-standardin mukainen ohjelma, jonka tuloste riippuu käytettävästä C-kielen toteutuksesta.

Työssä kehitetettävän ohjelmiston halutaan toimivan samalla tavalla riippumatta sii-tä, mitä ohjelmointikielen toteutusta käytetään. Yksikään edellä mahdollisiksi ohjel-miston toteutuskieliksi esitetyistä ohjelmointikielistä ei ole määritelty siten, että kaikkimääritelmän mukaiset ohjelmat tuottaisivat kaikissa tapauksissa samat tulokset. Tämänvuoksi ohjelmistoa kehitettäessä kiinnitetään erityistä huomiota siihen, että valitun kie-len toteutusten erot eivät vaikuta ohjelmiston käyttäytymiseen.

25

3.5. Pohdinta

AR.Drone 2.0:n tarjoamat laskennalliset resurssit ovat sulautetuksi järjestelmäksi suh-teellisen suuret. Kokonaisia kuvia käsittelevät toimenpiteet, kuten kuvan korjaus pers-pektiivimallin mukaiseksi, ovat kuitenkin käytettävissä oleviin resursseihin nähdenraskaita. AR.Drone 2.0:n etukameran tuottamat 30 1280x720 -kokoista kuvaa sekun-nissa tarkoittavat, että 1 GHz suorittimella on noin 36 kellosykliä aikaa yhden kuva-pisteen käsittelyyn. Yksittäinen muistia lukeva käsky voi huonossa tapauksessa vaa-tia jopa satoja kellosyklejä suoritinaikaa. Jos muistin lukemisesta aiheutuu näin suuriviive jokaisen korjattavan kuvan kuvapisteen kohdalla, on selvää, että kaikkia 30 ku-vaa sekunnissa ei ehditä korjata. Luvussa 3.3 esitettyihin ilmiöihin huomiota kiinnittä-mällä huolehditaan siitä, että suorittimen välimuistijärjestelmä saa lyhennettyä muistinkäytöstä aiheutuvaa viivettä.

Kohdejärjestelmän tarkastelusta päätellään, että kovin suurta ohjelmistoa AR.Drone2.0:ssa ei voi suorittaa. Levytilan määrä on rajallinen, mutta erityisesti keskusmuistiaei sovi käyttää paljoa. Käsiteltävän muistimäärän minimoimisesta on myös se etu, ettäsuurempi osa käsiteltävästä tiedosta mahtuu välimuistiin. Koska ohjelmiston toteutuk-sessa on tarve voida hallita muistin käyttöä sekä määrällisesti että asettelun ja tietora-kenteiden osalta, matalan tason ohjelmointikielten käyttö toteutukseen on luontevaa.Uudelleenkäytettävyyden maksimoimiseksi kannattaa kuitenkin mahdollisimman suu-ri osa ohjelmistosta toteuttaa alustariippumattomaksi.

26

4. KEHITETTY OHJELMISTO

Opinnäytetyön ohjelmisto-osuus toteuttaa luvussa 2.5 esitellyn Kannala-Brandt -ka-meramallin mukaisia menetelmiä. Toteutetun ohjelmiston avulla voi sulautetussa jär-jestelmässä hyödyntää Kannalan kirjoittaman kalibrointiohjelmiston [17] suorittamaakameran kalibrointia. Ohjelmisto on vapaasti hyödynnettävissä ja ladattavissa osoit-teesta https://bitbucket.org/muep/twirl.

Työssä toteutettu ohjelmisto koostuu noin 8000 rivistä C++-lähdekoodia. Ohjelmis-to on yhteensopiva ainakin GNU GCC 4.8 -kääntäjän ja LLVM Clang 3.3 -kääntäjänkanssa. Ohjelmiston keskeisimmät osat ovat yhteensopivia myös Microsoft Visual Stu-dio Express 2013 for Windows -kääntäjän kanssa. Perinteisemmän C-kielen sijaanC++-kieltä käytetään sen tarjoamien lisäominaisuuksien takia.

Toteutettu ohjelmisto koostuu joukosta moduuleja, joiden piirteitä esitellään jäljem-pänä. Ohjelmiston keskeisin osa on kuvaprosessointirutiinit toteuttavasta lähdekoodis-ta koostuva Twirl-kirjastomoduuli. Kirjasto toteuttaa joukon puhtaita laskentaoperaa-tioita ja tarjoaa helppokäyttöisen ohjelmointirajapinnan niiden käyttöön.

Muita toteutetun ohjelmiston moduuleita ovat uudelleenkäytettäviä apurutiineitasisältävä Twirr-kirjasto, suorituskyvun mittauksessa käytettävä benchmarks-työkalu-kokoelma, kalibrointiobjektin kontrollipisteitä havaitseva ctrlpoint_extractor -työkalu,twirl-cmd -komentorivityökalu, graafinen twirl_viewer -työkalu ja joukko automaat-tisia testejä.

4.1. Twirl-kirjasto

Twirl-projektin twirl -kirjasto sisältää kameraa mallintavia laskurutiineja. Rutiinien to-teutuksessa kiinnitettiin erityistä huomiota ohjelmiston siirrettävyyteen. Niiden hyö-dyntäminen vaatii C++-kääntäjän lisäksi C-standardikirjaston seuraavat asiat:

• stdint.h -otsikkotiedoston kokonaislukutyypit

• memcpy -funktio

• math.h -otsikkotiedoston trigonometriafunktiot

Niiltä osin kuin Twirl-kirjaston toiminnallisuus vaatii muistin varaamista dynaami-sesti ohjelman ajon aikana, on sen varaaminen jätetty täysin kirjastoa käyttävän ohjel-man vastuulle. Kirjasto itse käyttää vain paikallisia muuttujia ja kutsuvasta ohjelmastavälitettyä muistia tietojen tallentamiseen ja käsittelyyn. Dynaamisen muistinvarauk-sen välttämisellä voidaan jonkin verran parantaa ohjelman siirrettävyyttä. EsimerkiksiAVR-mikrokontrollereilla malloc -funktion käyttö on usein vaativaa [24].

Muistin varaamisen lisäksi Twirl-kirjastossa vältetään myös kaikenlaisia muita sivu-vaikutuksia, kuten tiedostojen tai globaalien muuttujien kirjoittamista. Kaikki kirjas-tossa käsiteltävä tieto on siis joko sen paikallisissa muuttujissa tai kirjastoa kutsuvanohjelman varaamassa muistissa. Siten esimerkiksi monisäikeinen ohjelmisto voi kut-sua kirjaston funktiota ongelmitta monesta säikeestä, kunhan se varmistaa että muutsäikeet eivät kirjoita samoihin osoitin- tai viittausparametreina välitettyihin muistinosiin.

27

namespace twirl {

struct polynomy {/* ... */

real_tderivative(const real_t * coeffs,

uint_fast16_t polynomial_order,uint_fast16_t derivative_order,real_t x) const;

/* ... */};}

Listaus 5. twirl::polynomy::derivative -funktion esittely

Kirjaston laskentafunktioiden toteutuksissa C++:n ominaisuuksista pyrittiin käyt-tämään vain sellaisia, joista ei aiheudu merkittävää eroa suorituskyvyssä tai siirret-tävyydessä verrattuna C-kieliseen vastaavaan ohjelmaan. Näiltä osin täysin ongelmat-tomia piirteitä ovat esimerkiksi nimiavaruudet, viittaukset ja muuttujien tyypin au-tomaattinen valinta (ns. auto -tyypiset muuttujat).

Edellä mainittujen funktioiden toteutuksessa C++:n template-toimintoja käytetäänhuolimatta siitä, että niiden varomaton käyttö saattaa paisuttaa käännetyn ohjelmankokoa. Kääntäjän generoiman konekielisen koodin kokoa seuraamalla voi kuitenkinhavaita tilanteet, joissa ohjelman osasta meinaa syntyä liian suuri konekielinen vastine.Tarvittaessa ohjelman osan voi toteuttaa uudelleen ilman template-toimintoja.

Rakenteet, joita erityisesti vältettiin laskentafunktioiden toteutuksissa, olivat muunmuassa poikkeukset, virtuaaliset luokkien jäsenfunktiot ja dynaaminen muistin varaami-nen. Näistä rajoituksista johtuen myöskin C++:n standardikirjaston käyttö rajattiintwirl-kirjaston ulkopuolelle.

Kirjasto toteutettiin siten, että sen käyttämän liukulukutietotyypin voi valita kään-nön asetustentekovaiheessa. Käytännössä tätä mahdollisuutta ei juuri hyödynnetty jakaikissa tämän työn osissa voi olettaa että twirl::real_t on oikeasti float. Ohjelmistossakäytetyn twirl::real_t -tyypin voi kuitenkin tarvittaessa vaihtaa helposti tarkoittamaanC++:n double-tyyppiä.

4.1.1. Polynomit

Kannala-Brandt -kameramallin määritelmässä esiintyy polynomifunktioita ja niidenderivaattoja ja käänteisfunktioita. Niiden laskemiseen toteutettiin polynomy-niminenmoduuli, joka tarjoaa funktiot edellä mainittuihin toimintoihin.

Moduulin toteutuksessa tärkeimpiä osia on twirl::polynomy::derivative -funktio, jo-ka laskeen N:n asteen polynomifunktion M:nnen derivaatan kohdassa x, missä N voiolla mikä tahansa kokonaisluku ja M joko 0, 1 tai 2. Funktion esittely on listauksessa 5.

Huomioitavaa twirl::polynomy::derivative -funktiossa on, että sen rajapinta on tar-peettoman joustava. Joustavuudesta funktion konekieliseen vastineeseen seuraa ehdol-lisia hyppykäskyjä, joissa suoritin voi joutua pysäyttämään laskentalinjaston. Cortex-A8:n tapauksessa hyppykäskystä seuraava viive on 13 kellosykliä, mikäli suoritin eiennakoi ehdollisen hyppykäskyn jälkeistä ohjelmalaskurin arvoa oikein [22].

28

namespace twirl {/* ... */real_tpolynomy::value_135(const real_t * const k,

real_t const x) const{

real_t const poly[] = {0,k[0],0,k[1],0,k[2]

};

return this->derivative(poly,5,0,x

);}/* ... */

} /* namespace twirl */

Listaus 6. twirl::polynomy::value_135 -funktion totetutus.

Toteutettu ohjelmisto tekee suuren määrän polynomilaskuja, joissa polynomin asteja nollasta poikkeavien kertoimien sijannit ovat kiinnitettyjä. Tämän vuoksi usein tois-tuville erikoistapauksille polynomy-moduulissa on omat funktionsa, joissa rajapinta eiole derivative-funktion tavoin joustava. Esimerkiksi listauksen 6 value_135-funktion,laskee arvon polynomille jossa vain ensimmäisen, kolmannen ja viidennen asteen ker-toimet ovat nollasta poikkeavia.

Toteutus value_135 -funktiolle kirjoitettiin siten, että se luo vaaditut ylimääräisetparametrit paikallisiksi muuttujiksi ja kutsuu yleiskäyttöistä derivative-funktiota. Suo-raan käännettynä tällaisen funktion toteutus olisi korkeintaan yhtä nopea kuin sen kut-suma derivative-funktio. Käytännössä kääntäjän on mahdollista tuottaa huomattavastiderivative-funktiota nopeampi konekielinen vastine value_135-funktiolle. Nopeaan to-teutukseen käännetään mukaan inline-kopio sellaisesta derivative-funktiosta, jossa val-ue_135:ssa vakioksi asetetut parametrit ovat vakioita. Esimerkiksi työssä käytetty GCC4.8 -kääntäjä tuottaa value_135:sta listauksen 7 mukaisen konekielisen vastineen. Kos-ka kääntäjä havaitsee, että derivative-funktion silmukan kierrosmäärä on annetuillaparametreilla vakio, voi se poistaa silmukan ja luoda tilalle suoraan kertolaskukäskyt,jotka vastaavat poistetun silmukan suorittamia aritmetiikkakäskyjä.

Listauksen 7 käännöksessä kaikki laskenta mahtuu käytettävissä oleviin rekisterei-hin. Konekielisen ohjelman ei tarvitse esimerkiksi luoda muistiin kuuden alkion real_t-taulukkoa tai silmukkarakenteita, vaikka lähdekoodia seuraamalla sellaiset voi havai-ta. Laskenta pystytään siis määrittelemään yhden kerran joustavarajapintaisella, hitaal-la funktiolla, josta kääntäjä optimoi nopeammin toimivan erikoistapauksen. Testatuistakääntäjistä sekä Clang että GCC tuottivat myös x86-64 -alustalla value_135-funktiostavastaavanrakenteisen konekielisen funktion.

29

0000044c <twirl::polynomy::value_135(float const*, float) const>:44c: ed9f7a1d vldr s14, [pc, #116] ; 4c8450: eef07a47 vmov.f32 s15, s14454: edd06a00 vldr s13, [r0]458: ed913a00 vldr s6, [r1]45c: edd02a01 vldr s5, [r0, #4]460: edd03a02 vldr s7, [r0, #8]464: edd14a01 vldr s9, [r1, #4]468: ed904a03 vldr s8, [r0, #12]46c: ee467a87 vmla.f32 s15, s13, s14470: ed905a04 vldr s10, [r0, #16]474: edd16a02 vldr s13, [r1, #8]478: ed906a05 vldr s12, [r0, #20]47c: e24dd018 sub sp, sp, #24480: ee223a83 vmul.f32 s6, s5, s6484: ee407a03 vmla.f32 s15, s0, s6488: ee633a87 vmul.f32 s7, s7, s1448c: eef05a47 vmov.f32 s11, s14490: ee207a00 vmul.f32 s14, s0, s0494: ee477a23 vmla.f32 s15, s14, s7498: ee644a24 vmul.f32 s9, s8, s949c: ee207a07 vmul.f32 s14, s0, s144a0: ee477a24 vmla.f32 s15, s14, s94a4: ee655a25 vmul.f32 s11, s10, s114a8: ee207a07 vmul.f32 s14, s0, s144ac: ee477a25 vmla.f32 s15, s14, s114b0: ee200a07 vmul.f32 s0, s0, s144b4: ee267a26 vmul.f32 s14, s12, s134b8: ee477a00 vmla.f32 s15, s14, s04bc: eeb00a67 vmov.f32 s0, s154c0: e28dd018 add sp, sp, #244c4: e12fff1e bx lr4c8: 00000000 .word 0x00000000

Listaus 7. twirl::polynomy::value_135 -funktion ARM-käännös

4.1.2. Matriisit

Pienten matriisien perusoperaatioiden laskemiseen kirjoitettiin C++-malli (eng. tem-plate), jonka toteutuksen oleellisimpia piirteitä on poimittu listaukseen 8. Malli ko-konaisuudessaan on saatavilla toteutetun ohjelmiston tiedostosta include/twirl/ma-trix.hpp.

Matriiseja tarvitaan lähinnä Kannala-Brandt -mallin käänteisessä projisoinnissa,joten sen merkitys ohjelmiston suorituskyvylle ei ole erityisen suuri.

C++-malleille perinteinen käyttöesimerkki olisi tyypin suhteen geneeristen tietora-kenteiden kirjoittaminen. Tässä tapauksessa mallissa ei ollut tarvetta hyödyntää usei-ta tietotyyppejä, joten se kirjoitettiin käsittelemään ainoastaan twirl::real_t -tyyppisiälukuja. Tyypin sijaan mallin geneerisyys liittyykin matriisin kokoon. Käytännössäratkaisusta seuraa, että ohjelmointikielen tyyppijärjestelmä kohtelee erikokoisia mat-riiseja eri tyyppeinä. Matriisityypeille tämä sopii erityisen hyvin, koska matriisien ker-tolaskuoperaatiot on perinteisesti määritelty vain yhteensopivan kokoisille matriiseille.

Kuten listauksen 8 viimeisistä riveistä havaitaan, ovat mallin luomat tyypit raken-teeltaan C-tyylisiä 2-ulotteisia taulukoita (eng. array), jotka on pakattu struct:n sisään.Tämä sopii hyvin tavoitteeseen välttää dynaaminen muistin varaaminen. Toisaaltavalittu toteutus voi käyttää suhteellisen paljon muistia paikallisille muuttujille, mikäjoissain järjestelmissä voisi olla ongelma. Esimerkiksi neljän rivin neliömatriisissaolisi 16 4 tavun kokoista alkiota, jolloin koko muuttujan koko olisi 64 tavua. AR.Drone

30

template <int H, int W>struct matrix {

/* constructors ... */

template<int W2>matrix<H,W2>operator*(const matrix<H,W2> &o) const{ /* ... */ }

matrixoperator*(real_t const v) const{ /* ... */ }

matrixoperator+(const matrix &o) const{ /* ... */ }

staticmatrixidentity(){ /* ... */ }

staticmatrixones(){ /* ... */ }

real_t a[H][W];};

Listaus 8. twirl::matrix -mallin pääpiirteitä.

2.0:n tapauksessa ongelmaa ei pitäisi kuitenkaan olla, koska Linux-ohjelmissa funk-tiokutsupinon kokoa ei yleensä ole rajattu erityisen pieneksi.

Matriisirakenteita voisi käyttää ohjelmakoodissa esimerkiksi listauksen 9 mukaises-ti. Listauksen f-funktiossa luodaan aluksi kahden rivin ja kolmen sarakkeen kokoinenmatriisi, jonka arvot alustetaan paikallisista muuttujista. Toinen, kolmirivinen ja kak-sisarakkeinen matriisi luodaan 1-alkioita sisältävän matriisin alustavalla funktiolla.Matriisien kertolasku tuottaa kaksirivisen neliömatriisin joka annetaan g-funktiolleparametrina.

Matriisien toteutustapa on varsin käytännöllinen käyttää. Toisaalta se voi kuitenkinjohtaa tarpeettoman suureen määrään paikallisia muuttujia. Mikäli riittävän suuri osa

void g(const twirl::matrix<2,2> &mx);

void f(){using twirl::matrix;using twirl::real_t;

real_t const values[] = { 1.0f, 2.0f, 3.0f,4.0f, 5.0f, 6.0f };

auto const m0 = matrix<2,3>(values);auto const m1 = matrix<3,2>::ones();auto const m2 = m0 * m1;

g(m2);}

Listaus 9. Esimerkki twirl::matrix -mallin käytöstä.

31

laskettavien matriisien alkioista tunnetaan nolliksi, voisi mahdollisesti ainakin suori-tuskykykriittisissä osissa ohjelmaa sieventää kertolaskuoperaatiot paperilla ja kirjoit-taa vain sievennetyt lausekkeet ilman tähän työhön toteutettua matriisimoduulia. Lu-vussa 2.5.2 esitettyjen matriisilausekkeiden kirjoittamisessa ratkaisu kuitenkin koettiinhyväksi.

4.1.3. Kannala-Brandt -mallin toteutus

Totetettuun ohjelmistoon kirjoitettiin twirl::kannala -niminen moduuuli joka toteuttaaluvussa 2.5 esitetyt yhtälöt. Moduuli projisoi molempiin suuntiin, eli sille voi sekäantaa valonsäteen tulokulman ja saada vastauksena pikselin sijainnin, että selvittää tu-lokulman joka vastaa jotain tunnettua pikselin sijaintia.

Moduulin laskenta toteutettiin suoraan luvun 2.5 lausekkeista. Osalle lausekkeistaderivoitiin paperilla vastaavat derivaattalausekkeet, mutta polynomilausekkeiden ta-pauksessa voitiin hyödyntää polynomy-moduulin sisäänrakennettua derivaattatoimin-nallisuutta.

Mallin toteutus vaatii monessa kohdassa sinin ja kosinin laskemista (θ, φ)-kulmapa-rin φ-kulmalle. Lisäksi osa funktioista tarvitsi arvot lausekkeille sin(2φ) ja cos(2φ).Tämän takia toteutettiin mallin rajapinta sellaiseksi, että twirl::kannala -moduulinfunktioita kutsuva koodi laskee kyseiset arvot valmiiksi mikäli niitä tarvitaan. Ar-vojen laskeminen tapahtuu käytännössä muuntamalla twirl::ray_direction -muuttujatwirl::kannala::raydir_plus -tyyppiseksi, jolloin tyypin toteutus huolehtii arvojen täyt-tämisestä paikalleen.

Listaukseen 10 on poimittu raydir_plus -tyypin oleellisimmat piirteet. Tyyppi onperiytetty yksinkertaisesta ray_direction -tyypistä, koska sen haluttiin joka tapaukses-sa sisältävän alkuperäisen kulmatiedon. Myöskin on käytännöllistä että tyypin muut-tujia voi suoraan käyttää tilanteissa, missä voi käyttää laajentamatonta ray_direction-muuttujaa. Muodostin raydir_plus -tyypille kuitenkin on sellainen, että korotus su-urempaan tyyppiin pitää tehdä explisiittisesti. Tämä helpotti ohjelmiston kehitystä vai-heessa, jossa sini- ja kosinifunktioiden kutsujen määrää pyrittiin minimoimaan suori-tinaikavaatimusten pienentämiseksi.

Vastaavasti kuin raydir_plus -luokalla laajennettiin twirl::ray_direction -tyyppiä,laajennettiin raydir_plus-tyypistä edelleen raydir_plus2, jossa on myös kaksinkertaisenφ:n sini ja kosini.

4.1.4. Kuvan korjaus perspektiivimallin mukaiseksi

Ohjelmiston reproject -komponentilla voi muuntaa kokonaisia Kannala-Brandt -mallinmukaisia kuvia perspektiivimallin mukaisiksi. Tätä varten toteutettuun ohjelmistiinsisältyy pinhole-nimoinen moduuli, jonka avulla voi laskea, mihin pikseliin jonkinperspektiivikameran havaitsema valonsäde osuu. Vastaavasti kuin Kannala-Brandt -mallille, tästäkin laskennasta on toteutettu myös käänteinen versio joka kertoo, mikävalonsäde vastaa jotain tunnettua pikseliä. Laskenta toteutettiin suoraan yhtälön (5)mukaisesti, jotta sille muodostuva ohjelmointirajapinta olisi mahdollisimman saman-

34

voidcorrect_with_lut(const lut_entry *const lut,

uint32_t const from_pos,uint32_t const to_pos,uint32_t const black,const uint32_t * const data_in,uint32_t * const data_out)

{for (uint32_t pos = from_pos; pos < to_pos; ++pos) {auto const entry = lut[pos];

#ifdef TWIRL_USE_ARM_TWEAKS{

int const pld_offset = 7;const void * const p = lut + (pos + pld_offset);asm("pld [%[foo]]" /* asm */:: /* output operands */[foo] "r" (p) : /* input operands *//* clobber list */

);}

#endif

auto const color =detail::is_invalid(entry) ?black :data_in[entry.offset];

data_out[pos] = color;}

}

Listaus 11. twirl::reproject::correct_with_lut -funktio

Hakutaulun luonti edellyttää funktiota, joka tekee lähes tarkalleen samat asiat kuinluvussa 4.1.4 esitelty mekanismi. Hakutaulua ja listauksen 11 funktiota käyttämälläkorjauksen pitäisi kuitenkin tapahtua huomattavan nopeasti, koska nyt korjausfunktiojoutuu jokaiselle pikselille tekemään vain pienen joukon hyvin keveitä operaatioita.Aluksi haetaan hakutaulusta yksi 32 bitin kokonaisluku, joka kertoo vastinpikselin si-jainnin. Sijaintimuuttujan arvoalueesta arvo 0xffffffff käytettiin merkitsemään korja-tun kuvan sijainteja, joille korjattavassa kuvassa ei ole vastinpikseleitä. Listauksessanäkyvä is_invalid -funktiokutsu tekee siis vain yhtäsuuruusvertailun vakioarvoa vas-ten.

Listauksen 11 TWIRL_USE_ARM_TWEAKS -esikääntäjämakrosta riippuen ehdol-lisesti käännetty lohko on suorituskykyoptimointi, joka ei vaikuta funktion antamiintuloksiin. Optimointi hyödyntää luvussa 3.3 esiteltyä ARMv7-käskykannan PLD-käskyä. Koska lut-parametrina saadun taulukkon alkioita käydään läpi lineaarisesti,voidaan suoritimelle käskyn avulla etukäteen ilmaista, että lut-taulun nykyisen kohdanlisäksi myös seuraavia alkioita tullaan tarvitsemaan pian. Lohkossa käytetty pld_offseton ennakon suuruus, joka kertoo, kuinka monen taulukon alkion päästä esiladataan.Ennakon suuruuden valintaa ja sen vaikutuksia käsitellään jäljempänä luvussa 5.4.7.

Hakutaulukko-optimoitu korjausfunktio koostuu jokaiselle pikselille suoritettavastasilmukasta joka sisältää lähes pelkästään muistin lukemista ja kirjoittamista. Tämänvuoksi on luultavaa, että luvussa 3.3 esitetyllä välimuistin toiminnalla on merkittävävaikutus funktion suorituskykyyn.

35

00000414 correct_with_lut:414: e1510002 cmp r1, r2418: e92d01f0 push {r4, r5, r6, r7, r8}41c: e59d4014 ldr r4, [sp, #20]420: 2a00001e bcs 4a0 <correct_with_lut+0x8c>424: e2815001 add r5, r1, #1428: e1a05105 lsl r5, r5, #242c: e245c004 sub ip, r5, #4430: e0800005 add r0, r0, r5434: e59d5018 ldr r5, [sp, #24]438: e085c00c add ip, r5, ip43c: e5108004 ldr r8, [r0, #-4]440: e2811004 add r1, r1, #4444: e5907000 ldr r7, [r0]448: e28cc010 add ip, ip, #1644c: e3780001 cmn r8, #1450: e5906004 ldr r6, [r0, #4]454: e5905008 ldr r5, [r0, #8]458: e2800010 add r0, r0, #1645c: 17948108 ldrne r8, [r4, r8, lsl #2]460: 01a08003 moveq r8, r3464: e3770001 cmn r7, #1468: 17947107 ldrne r7, [r4, r7, lsl #2]46c: 01a07003 moveq r7, r3470: e3760001 cmn r6, #1474: 17946106 ldrne r6, [r4, r6, lsl #2]478: 01a06003 moveq r6, r347c: e3750001 cmn r5, #1480: 17945105 ldrne r5, [r4, r5, lsl #2]484: 01a05003 moveq r5, r3488: e1520001 cmp r2, r148c: e50c8010 str r8, [ip, #-16]490: e50c700c str r7, [ip, #-12]494: e50c6008 str r6, [ip, #-8]498: e50c5004 str r5, [ip, #-4]49c: 8affffe6 bhi 43c <correct_with_lut+0x28>4a0: e8bd01f0 pop {r4, r5, r6, r7, r8}4a4: e12fff1e bx lr

Listaus 12. twirl::reproject::correct_with_lut -funktion ARM-käännös

Parametrina saatua lut-hakutaulua käydään läpi muistiosoitejärjestyksessä. Tämänperusteella oletetaan, että suurella todennäköisyydellä välimuistirivin alkuun sijoit-tuvan hakutaulukkoalkion jälkeen myös muut samalle välimuistiriville sijoittuvat alkiotluetaan, ennen kuin kyseinen välimuistirivi poistuu välimuistista jonkun muun tiedontieltä.

Korjattavan kuvan pikseleiden osalta tilanne on jännittävämpi. Esimerkiksi siirryt-täessä korjatussa kuvassa yksi pikseli vasemmalta oikealle, siirtyy luultavasti myöskorjattavan kuvan vastinkohta jonkin verran oikealle. Määrä kuitenkin voi olla enem-män tai vähemmän kuin yksi pikseli, ja osassa korjatun kuvan siirtymiä vastinkohta voisiirtyä myös pystysuunnassa. Luultavasti kuitenkin myös korjattavan kuvan sisältävänmuistin osalta laskenta etenee ainakin osan ajasta siten, että ajallisesti lähekkäin la-dataan pikseleitä jotka osuvat samalle välimuistiriville.

Myös korjatun kuvan pikselit kirjoitetaan muistiosoitejärjestyksessä, minkä odote-taan olevan edullinen tilanne suorittimen muistinkirjoituspuskuroinnin kannalta.

Hakutaulukkoa käyttämällä saatua suorituskykyä verrataan perustoteutukseen jäl-jempänä luvussa 5.4.4.

36

4.2. Twirr-kirjasto

Toteutettuun ohjelmistoon sisältyy myös toinen, Twirr-niminen uudelleenkäytettäviäkomponentteja sisältävä moduuli. Erona Twirl-komponenttiin on se, että Twirr sisältäävain toiminnallisuutta joka on yhteistä Twirl:n kehittämisen tukena kehitetyille muilleohjelmille. Twirr sisältää muun muassa komentorivin jäsentämiseen käytettäviä ru-tiineja ja esikääntäjämakroja, joita tarvitaan osassa aputyökalujen lähdekoodia kään-täjäyhteensopivuuden parantamiseksi. Twirr-kirjaston osien ei ole tarpeen olla yhtäjoustavasti käytettävissä eri alustoilla kun laskenta-algoritmien ydinosien. Tämän vuok-si sen toteutuksessa hyödynnetään C++-standardikirjaston tarjoamaa toiminnallisuut-ta.

Eräs Twirr-kirjaston osista suorittaa luvussa 4.1.4 esiteltyjä kuvankorjausrutiinejaniin, että kuorma jaetaan usealle säikeelle. Tämän ei odoteta tuovan suorituskykyhyö-tyä AR.Drone 2.0:n yksiytimisellä suorittimella. Joissain muissa sulautetuissa ARM-suorittimeen perustuvissa järjestelmissä suoritinytimiä kuitenkin on kaksi tai enem-män, eikä yksinkertaisen useaan säikeeseen jakamisen toteuttaminen vaadi suurtalisäystä toteutettuun ohjelmistoon.

Monisäikeistä suoritetusta sovelletaan kuvan perspektiivimallin mukaiseksi korjaa-van funktion perustoteutukseen, ja lisäksi hakutaulun luontiin ja hakutaulukkoa käyt-tävään kuvankorjaukseen. Kaikki näistä toiminnoista on toteutettu siten, että operaatiotuottaa vain osan tuloksena saatavasta kuvasta tai hakutaulukosta.

Kaikki säikeisiin jako toteutetussa ohjelmistossa toimii siten, että kuva tai haku-taulukko jaetaan pystysuunnassa valitulle määrälle säikeitä. Esimerkiksi kolmelle säi-keelle jaettaessa yksi säie saa laskettavakseen korjatun kuvan ylimmät rivit, toinenkeskimmäiset ja kolmas alimmat rivit. Hakutaulukon tapauksessa jako on vastaava,kun tarkastellaan hakutaulukon alkioita vastaavia kuvapisteitä. Koska kuvan korjauk-sen aikana kameramallin kuvaavaa tietorakennetta, lähdekuvaa tai hakutaulukkoa eitarvitse kirjoittaa, voivat kaikki luodut säikeet turvallisesti lukea samaa kopiota niistä.Myös korjatun kuvan kuvapisteiden kirjoittaminen voidaan tehdä siten, että kukin säiekirjoittaa omalla vastuullaan olevan korjatun kuvan pisteet tai hakutaulukon alkiot suo-raan samaan tuloksena saatavaan kuvaan tai hakutaulukkoon.

Säikeisiin jaon toteuttava rutiini suorittaa työn jakamisen ja työn osia vastaaviensäikeiden käynnistyksen. Säikeet käynnistetään C++-standardikirjaston sisältämällästd::async-funktiomallilla. Kun kaikki työn osat on näin käynnistetty, rutiini yksinker-taisesti odottaa säikeiden päättyvän. Tämän ei koeta olevan erityisen elegantti ratkaisu,koska monisäikeisessä sovelluksessa on usein muutenkin säikeitä ja esimerkiksi jonkin-lainen työjono, minkä kautta laskenta kannattaisi järjestää suoritettavaksi. Mikäli valit-tu ratkaisu kuitenkin kykenee yksinkertaisessa käyttötilanteessa parantamaan lasken-nan suorituskykyä, on se riittävän hyvä osoittamaan että säikeistämällä hyötyä saavut-taa.

4.3. Käyttöliittymät ja testaus

Twirl- ja Twirr -kirjastojen lisäksi toteutettuun ohjelmistoon sisältyy noin kaksikym-mentä suoritettavaa ohjelmaa. Ohjelmat eivät ole välttämättömiä Twirl-kirjaston käyt-tämiseen, mutta niillä on suuri merkitys kokonaisuuden kehittämisen kannalta. Suu-

37

rin osa ohjelmista on yksinkertaisia testiohjelmia. Osa testiohjelmista laskee Twirl-kirjaston rutiineilla tuloksia ja ilmoittaa, vastaavatko ne ennalta tunnettuja odotettujatuloksia. Loput testiohjelmat ovat yksinkertaisia työkaluja, jotka tyypillisesti kutsuvatjotain tiettyä Twirl:n funktiota useita kertoja. Näiden työkalujen suoritusaikaa mittaa-malla voi ainakin karkeasti arvioida, miten paljon suoritinaikaa kunkin ohjelman tes-taama funktio vaatii.

Toteutettun ohjelmistoon sisältyy twirl-cmd -niminen komentorivityökalu, jonkaavulla voi muun muassa tulostaa kalibrointiparametritiedoston sisältämät arvot ja kor-jata kuvia perspektiivimallin mukaiseksi. Työkalu on käyttökelpoinen sekä Twirl-kirjaston käyttöesimerkkinä ohjelmoijalle että työkaluna ohjelmiston toiminnallisuu-den testaamiseen.

Kuvien korjaamisen twirl-cmd pystyy tekemään vain PNG -muotoisille kuville,joiden lukemiseen ja kirjoittamiseen se käyttää libpng-kirjastoa. Ohjelman voi tarvit-taessa kääntää myös käyttämättä libpng -kirjastoa, mikäli kuvien korjaustoiminnalli-suutta ei tarvita.

Kuva 9. Kuvankaappaus twirl_viewer -työkalusta.

Komentorivikäyttöliittymän lisäksi toteutettu ohjelmisto sisältää kuvassa 9 esite-tyn, twirl_viewer -nimisen graafisen työkalun. Työkaluun voi ladata Kannala-Brandt -kameramallin parametrit ja kuvia tiedostoista. Ohjelmaan ladatut kuvat korjataan twirl-kirjaston korjaustoiminnolla perspektiivimallin mukaisiksi ja näytetään käyttäjälle kor-jattuna. Työkalun käyttäjä voi myös halutessaan tallentaa korjatun kuvan tiedostoon.Lisäksi twirl_viewer piirtää kahta erilaista kuvaajaa, jotka auttavat hahmottamaan

38

parametrien kuvaaman kameran ominaisuuksia. Kameramallin parametreja voi muut-taa ohjelman vasemman laidan lomakkeen kautta.

Twirl-viewer toteutettiin Qt-sovelluskehyksen avulla. Toisin kuin aiempana mainit-tu twirl-cmd, twirl_viewer käyttää twirl-kirjaston reproject-moduulin funktioita Qt:nQImage-luokan ohessa. Koska QImage-luokka tarjoaa kattavan tuen erilaisten ku-vatiedostoformaattien lukemiseen ja kirjoittamiseen, kykenee twirl_viewer avaamaanPNG-muotoisten kuvien lisäksi myös esimerkiksi JPEG-kuvia. Tarkka tuettujen ku-vatiedostoformaattien joukko riippuu siitä, minkä Qt-version kanssa ohjelmistoa suo-ritetaan.

39

5. TULOKSET

Tässä osassa työtä kuvataan työssä toteutetun ohjelmiston testiympäristö, testaamiseenkäytetyt menetelmät. Lisäksi ohjelmiston suorituskykyä mitataan eri alustoilla ja esi-tetään, miten erilaiset suorituskyvyn parantamiseen tähtäävät ratkaisut onnistuivat.

5.1. Testiympäristöt

Työssä kehitetyn ohjelmiston suorituskykyä havainnoitiin yhteensä neljässä eri jär-jestelmässä, jotka on lueteltu taulukossa 1. Järjestelmistä IGEPv2 ja Jolla perustu-vat ARM -arkkitehtuuria edustaviin suorittimiin. PC-1 ja PC-2 ovat tavanomaisia PC-työasemia.

Testilaittestojen esittelyssä keskitytään ensisijaisesti suorittimen ominaisuuksiin.Suorituskykyä mittaavat ohjelmat kirjoitettiin siten, että niiden ei tarvitse esimerkik-si lukea tai kirjoittaa tietoja massamuisteihin. Tämän vuoksi jätetään huomiotta esi-merkiksi se, että joissain testijärjestelmissä ainoana tallennustilana toimiva SD-korttion perinteiseen kiintolevyyn verrattuna erittän hidas. Lisäksi oletetaan, että testijär-jestelmässä käytetty käyttöjärjestelmä ei suuresti vaikuta mittaustulokseen. Kaikki mit-taukset tehtiin jonkin Linuxiin perustuvan käyttöjärjestelmän alaisena, mutta laitteisto-jen erilaisuudesta johtuen täysin identtisen ohjelmistokokoonpanon käyttäminen olisiollut mahdotonta.

Taulukko 1. Kehitetyn ohjelmiston suorituskyvyn mittauksessa käytetyt järjestelmätNimi Suoritin KäyttöjärjestelmäIGEPv2 Cortex-A8, 720 Mhz Fedora 20Jolla Krait 300, 2 x 1,4 GHz Sailfish OSPC-1 Pentium 4, 2.8 GHz ExherboPC-2 AMD A8-3850, 4 x 2,9 GHz Fedora 20

Testijärjestelmistä eniten AR.Drone 2.0:n tarjoamaa ympäristöä muistuttaa kuvas-sa 10 havainnollistettu IGEPv2. Kuten AR.Drone 2.0:n OMAP3630 -piiri, myösIGEPv2:n OMAP3530 -piiri sisältää Cortex-A8 -suorittimen. Järjestelmät ovat siishuomattavan samankaltaiset, on niiden eroavaisuuksia lueteltu taulukossa 2.

IGEPv2:n käyttöjärjestelmänä käytettiin Fedora 20:n ARMv7-suorittimille kään-nettyä versiota. Käyttöjärjestelmän mukana tulevaa GCC 4.8.2 -kääntäjää käytettiinkaikkien suotituskykytestissä käytettyjen ARM-binäärien kääntämiseen.

Toisena ARM-arkkitehtuuria edustavana testijärjestelmänä käytettiin Jolla Oy:n Jolla-matkapuhelinta. Laitteen Sailfish OS -käyttöjärjestelmä sisältää GNU/Linux -ympäris-

Taulukko 2. AR.Drone 2.0:n ja IGEPv2:n eroavaisuuksiaJärjestelmä AR.Drone 2.0 IGEPv2SoC OMAP3630 OMAP3530Kellotaajuus 1000 MHz 720 MHzL1-välimuisti 32 KiB 16 KiBKeskusmuisti 128 MiB 512 MiB

40

Kuva 10. IGEPv2.

tön, jossa Fedora 20:n ARM-version GCC:lla käännettyjä C++-ohjelmia voi suorittaailman muutoksia. Jollan Qualcomm Snapdragon 400 -piiri on laskentakapasiteetiltaanhuomattavasti suurempi kuin IGEPv2:ssa käytetty OMAP3530. Lisäksi mielenkiin-toisena piirteenä Jollan suoritin on kaksiytiminen.

Kahdesta testeihin käytetyistä PC-työasemasta vanhempi PC-1 on varustettu 32-bittisellä 2,8 GHz Pentium 4 -suorittimella. Suorittimessa on vain yksi ydin, mutta Hy-perThreading -toiminnon takia se voi suorittaa kahta säiettä osittain rinnakkain. PC-1:ntestit käännettiin Exherbon paketoimalla GCC:n 4.8.2 -versiolla.

Käytetyistä testikokoonpanoista suurin laskentakapasiteetti on PC-2:ssa. Sen suoritinedustaa vuoden 2012 tyypillistä pöytätietokoneratkaisua. Suorittimessa on 4 ydintä jase tukee 64-bittistä X86-64 -käskykantaa.

Suorituskyvyn arviointia varten työssä kehitetyn ohjelmiston kääntäjäastukset valit-tiin suorittamalla Cmake-työkalu listauksessa 13 kuvatuilla parametreilla. Cmake käyt-tää annettuja parametreja ja totetutetun ohjelmiston CMakeLists.txt -tiedostoja GCC-kääntäjän parametrien valintaan. Listaukseen 14 on kopioitu yhden projektiin kuuluvantiedoston käännössä käytetyt, Cmaken valitsemat valitsimet. Käytännössä tässä käyte-tyillä, laitteistoriippumattomilla asetuksilla ohjelmiston laitteistolle sovittaminen jääkääntäjän vastuulle. Tässä työssä esiteltyä suorituskykyä saattaa siis olla mahdollinenparantaa ainoastaan kääntäjän asetuksia muuttamalla.

Ellei toisin mainita, luvussa 4.1.5 mainittua PLD-optimointia ei hyödynnetä suori-tuskykymittauksissa. Kyseisellä suoritinkohtaisella optimointimenettelyllä saavutettuanopeusetua käsitellään erikseen luvussa 5.4.7.

41

env \CFLAGS="-Wall -std=c11 -march=native" \CXXFLAGS="-Wall -std=c++11 -march=native" \cmake -DCMAKE_BUILD_TYPE=Release \

-DTWIRL_USE_LIBPNG=ON \-DTWIRL_USE_QT5=ON \-DTWIRL_USE_THREADS=ON ..

Listaus 13. Käännössä käytetyt asetukset

/usr/bin/c++ -Wall -std=c++11 -march=native -O3 -DNDEBUG \-I/home/muep/src/twirl/build-bench-gcc -I/home/muep/src/twirl/include\-o CMakeFiles/bench_reproject_lut_v2.dir/bench_reproject_lut_v2.cpp.o\-c /home/muep/src/twirl/src/benchmarks/bench_reproject_lut_v2.cpp

Listaus 14. Esimerkki GCC-kääntäjälle asetetuista valitsimista

5.2. Kalibrointi

Kannala-Brandt -kameramalli kalibroitiin Matlab-työkalulla [17], joka sovittaa mallinparametrit siten että ne vastaavat mallinnettavan kameran tuottamia kuvia.

Matlab-työkalua hyödynnettiin yhdessä Seppälän [25] kuvaaman kalibrointikuvasar-jan avulla. Kuvasarja koostuu 20 kuvan 11 kaltaisesta kuvasta, jotka on otettu AR.Drone2.0:n kameralla. Kussakin sarjan kuvassa on kuvattu samaa mustavalkoruutuista kalib-rointiobjektia siten, että kalibrointiobjekti sijoittuu eri kohtiin kuvaa.

Kuva 11. Yksi kalibrointikuvasarjan kuvista.

Kuvasta 11 on silmämääräisestikin todettavissa, että ympäristön suorat piirteet eivätole kuvautuneet suoriksi. Esimerkiksi kuvan oikeassa laidassa olevan hyllyn reuna onselvästi kaareva. Lisäksi myös kalibrointiobjektin ruuduissa voidaan havaita selväävääristymää. Suoraan AR.Drone 2.0:n kamerasta saadut kuvat eivät siis noudata pers-pektiivimallia kovin hyvin, vaikka kuvasta voikin vielä helposti hahmottaa, minkälai-sia esineitä kameralla on kuvattu.

43

Toteutetun ohjelmiston twirl-cmd -työkalulla korjattiin kameramallin kalibrointiinkäytettyjä kuvia. Kuvassa 13 on esitetty kuva 11 korjattuna perspektiivimallin mukai-seksi. Toisin kuin kuvassa 11, kuvan 13 sisältämät suorat piirteet ovat myös kuvau-tuneet silmämääräisesti arvioiden suoriksi.

Kuva 13. Perspektiivimallin mukaiseksi korjattu esimerkkikuva.

5.3. Tarkkuus

Suurin osa työssä toteutetun ohjelmiston laskennasta perustuu suoraan Kannalan jaBrandt:n esittämiin suljetun muodon lausekkeisiin. Työssä ei huomioida sitä, ettäliukulukuaritmetiikan pyöristyksistä aiheutuu epätarkkuutta laskennan tuloksiin.

Liukulukujen tarjoaman äärellisen tarkkuuden lisäksi epätarkkuutta aiheutuu kahdes-ta approksimaatiosta, jotka molemmat liittyvät Kannala-Brandt -kameramallin kään-teisprojektiofunktion toteutukseen. Mallin symmetrisessä osassa käytetään Newtoninmenetelmää kasvavan polynomifunktion nollakohdan hakemiseen. Menetelmä mah-dollistaa nollakohdan tarkkuuden valinnan hyvinkin tarkaksi, mutta laskenta-ajan sääs-tämiseksi iteroinnin lopetusehto lopettaa tarkentamisen, kun löydetään kohta, jossapolynomin arvo poikkeaa nollasta vähemmän kuin 0.001 rad.

Nollakohdan haussa tehtyä kompromissia suuremman virheen aiheuttaa luultavastiKannalan esittämä approksimaatio epäsymmetrisen vääristymän käänteisfunktiolle.

Kannala-Brandt -mallin mukaiseen projisointiin ei liity vaiheita, joissa poikettai-siin Kannalan ja Brandt:n esittämistä lausekkeista muuten kuin liukulukuoperaatiois-sa tapahtuvien pyöristyksen osalta. Mallin käänteisprojisoinnin tarkkuutta arvioidaantässä verrattuna eteenpäin projisoinnin tuloksiin. Luvussa 5.2 esitellyllä esimerkkika-libroinnilla laskettiin käänteisprojektio jokaiselle 1280x720-kokoisen kuvan pikselille,mistä tuloksena saatu valonsäteen suunta taas projisoitiin. Mikäli käänteismalli olisiideaalisen tarkka, päästäisiin näin tekemällä samoihin pikseleiden sijainteihin.

44

Käytännössä poikkeamaan tuloksissa kuitenkin esiintyy. Kuvassa 14 on esitetty ero-tus Kannala-Brandt-mallin ja sen käänteismallin välillä. Kuvan valkoisissa kohdissakäänteistprojisoitu ja siitä edelleen eteenpäin projisoitu kuvapiste on noin 0.68 pikse-lin päässä alkuperäisestä kuvapisteestä. Mustissa kohdissa vastaava erotus on pieni.

Kuva 14. Poikkeama Kannala-Brandt -mallin ja käänteismallin välillä.

5.4. Laskennalliset resurssit

Tässä luvussa tarkastellaan, minkälaisia laskennallisia resursseja työssä kehitetyn oh-jelmiston hyödyntämiseen tarvitaan. Aluksi käsitellään itse ohjelmiston koko ja senkäsittelemien tietorakenteiden vaatimaa muistikapasiteettia. Lopuksi mitataan, kuinkapaljon suoritinaikaa kuvan korjauksen perspektiivimallin mukaiseksi vaatii.

5.4.1. Ohjelmiston koko

Kuten listauksessa 15 esitetään, työssä toteutetun ohjelmsiton algoritmiosat sisältävälibtwirl.a -tiedosto sisältää hieman yli 6 kilotavua suoritettavaa ohjelmakoodia. Käytän-nössä ohjelmakoodin vaatima tila on niin vähäinen, että se ei useimmissa ohjelmissamuodosta merkittävää osuutta koko ohjelman koosta. Lisäksi laskenta-algoritmit mah-tuvat kokonaisuudessaan OMAP 3630-järjestelmän L1i -välimuistiin.

Vertailun vuoksi listauksessa 16 on selvitetty kehitettyyn ohjelmistoon kuuluvientyökalujen kokoja. Yksinkertaiset benchmarks-hakemiston testityökalut ovat kooltaanyli kaksinkertaisia libtwirl.a:n sisältämän ohjelmakoodin kokoon verrattuna.

Jos libtwirl.a:n kokoa verrataan myös sitä käyttävien twirl-cmd -työkalun ja twirl-viewer:n kokoon, havaitaan että sen osuus kummastakin on alle kymmenesosa.

45

$ size -t src/twirl/libtwirl.atext data bss dec hex filename2840 0 0 2840 b18 kannala.cpp.o (ex src/twirl/libtwirl.a)48 0 0 48 30 matrix.cpp.o (ex src/twirl/libtwirl.a)328 0 0 328 148 math.cpp.o (ex src/twirl/libtwirl.a)348 0 0 348 15c pinhole.cpp.o (ex src/twirl/libtwirl.a)1228 0 0 1228 4cc polynomy.cpp.o (ex src/twirl/libtwirl.a)1128 0 0 1128 468 reproject.cpp.o (ex src/twirl/libtwirl.a)5920 0 0 5920 1720 (TOTALS)

$

Listaus 15. Kehitetyn ohjelmiston uudelleenkäytettävien osien koko

$ size src/viewers/twirl_viewer\src/tools/twirl-cmd\src/benchmarks/bench_reproject\src/benchmarks/bench_reproject_lut

text data bss dec hex filename73145 3076 224 76445 12a9d src/viewers/twirl_viewer133022 2188 204 135414 210f6 src/tools/twirl-cmd12350 412 8 12770 31e2 src/benchmarks/bench_reproject12426 412 8 12846 322e src/benchmarks/bench_reproject_lut

$

Listaus 16. Kehitettyyn ohjelmistoon kuuluvien työkalujen kokoja

5.4.2. Keskusmuistikapasiteetti

Mikäli toteutetulla ohjelmistolla halutaan laskea vain yksittäisten kuvattujen kolmi-ulotteisten pisteiden vastinkuvapisteitä tai käänteisesti kuvapistettä vastaavia valon-säteitä, ei muistia tarvitse varata paljoa. Kameramallin parametrit voidaan tallentaa23 liukuluvusta koostuvaan rakenteeseen, jonka koko yhteensä 92 tavua. Kuvapisteensijainnin kuvaamiseen, samoin kuin valonsäteen suunnan kuvaamiseen, riittää kaksiliukulukua. Näiden vastaavuuksien laskentaan käytetään kymmeniä paikallisia muut-tujia. Laskentaan ei kuitenkaan liity rekursiivisia funktiokutsuja eikä muuttuvanpituisiataulukoita, joten funktiokutsupinon koko rajautuu pieneksi.

Suurempia muistimääriä joudutaan varaamaan kuvadatalle korjattaessa kokonen ku-va perspektiivimallin mukaiseksi. Korjausta ei pystytä tekemään suoraan korjattavaankuvaan, vaan korjattavasta kuvasta syntyy korjaustoimenpiteen ohessa kopio.

Tämän takia yhden kuvan korjaaminen edellyttää, että vähintään kaksi kuvaa voidaanpitää kerralla muistissa. Ohjelmiston nykyinen toteutus olettaa kuvapisteiden olevan 4tavun kokoisia. Yhden 1280x720-kokoisen kuvan korjaaminen vaatii siis vähintään7372800 tavua eli noin 7 MiB tilaa. Lisäksi kuvan korjauksen hakutaulukkoa hyö-dyntävän version käyttämä hakutaulukko on kooltaan yhtä suuri kuin korjattava kuva.Hakutaulukko-optimoitu 1280x720-kokoisen kuvan korjaus edellyttää siis yli 10 MiBmuistin varaamisen.

Luvussa 3.1.4 havaittiin, että AR.Drone 2.0:n vakio-ohjelmisto sitä tutkittaessa jättinoin 20 MiB keskusmuistista vapaaksi. Tämän perusteella toteutettu ohjelmisto vaatisivähintään noin puolet vapaasta muistista laitteen etukameran kuvien korjaamiseenhakutaulukon avulla.

46

Taulukko 3. Kuvan korjauksen perustoteutukseen kuluva suoritinaika eri testiym-päristöissä

Järjestelmä SuoritinaikaIGEPv2 6400 ms

Jolla 850 msPC-1 450 msPC-2 210 ms

Taulukko 4. Kuvan hakutaulukko-optimoituun korjaukseen kuluva suoritinaika eritestiympäristöissä

Järjestelmä Hakutaulun luonti Yhden kuvan korjausIGEPv2 6400 ms 39 ms

Jolla 850 ms 15 msPC-1 450 ms 5.2 msPC-2 210 ms 3.5 ms

5.4.3. Kuvan korjaus perspektiivimallin mukaiseksi

Testattiin, paljonko suoritinaikaa tarvitaan 1280x720 -kokoisen kuvan korjaamiseksiperspektiivimallin mukaiseksi korjausalgoritmin perusversiolla. Mittaaminen tapahtuisiten, että bench_reproject -työkalu suoritettiin bash-komentotulkin time-komennonkautta. Työkalu suoritettiin parametrilla 10, jolloin se kutsuu kuvankorjausfunktiota 10kertaa. Bash:n time-komennon tulostama real-arvo jaettiin tämän jälkeen kymmenellä.Näin saadut arvot eri testiympäristöissä on koottu taulukkoon 3.

Mittausmenetelmästä on syytä huomioida, että sen ilmaisemaan aikaan sisältyymyös sellaista suoritinaikaa, jota ei käytetty testattavan reproject-funktion suorit-tamiseen.

Jopa nopeimmassa testiympäristössä perustoteutuksella saavutettu suorituskyky onkaukana tasosta, joka vaadittaisiin esimerkiksi 30 kuvan korjaamiseen sekunnissa.

5.4.4. Hakutaulukko-optimoitu kuvan korjaus

Hakutaulukko-optimoidun kuvankorjauksen suoritusaikaa mitattiin samalla menetel-mällä kuin mitä algoritmin perusversioon sovellettiin. Tulokset on esitetty taulukos-sa 4.

Hakutaulukko-optimoinnilla IGEPv2:n Cortex-A8 käsittelee yhden kuvan hiemanalle 40 millisekunnissa. Tämä riittäisi 25 kuvan käsittelyyn sekunnissa reaaliajassa,mikäli järjestelmän ei tarvitsisi tehdä mitään muuta. Käytännössä kuitenkin myös esi-merkiksi kuvadatan siirto korjausalgoritmiin ja sieltä pois vaatisi suoritinaikaa, jota 25kuvan käsittely sekunnissa ei välttämättä jättäisi riittävästi käyttämättä. Hakutaulukko-optimoitu toteutus korjausalgoritmista kuitenkin olisi useita suuruusluokkia nopeampikuin korjauksen perustoteutus. Reaaliaikaiseen korjaukseen voisi päästä esimerkiksipienentämällä korjatun kuvan resoluutiota, jolloin tuotetaan pienempi määrä kuvapis-teitä. Vaihtoehtoisesti järjestelmä voisi korjata vain esimerkiksi joka toisen kuvan.

47

Taulukko 5. Kuvan korjauksen perustoteutukseen kuluva suoritinaika käytettäessä use-ampaa kuin yhtä säiettä

Järjestelmä Säikeiden lukumäärä SuoritinaikaIGEPv2 2 6400 ms

Jolla 2 460 msPC-1 2 310 msPC-2 4 60 ms

Taulukko 6. Kuvan hakutaulukko-optimoituun korjaukseen kuluva suoritinaika käytet-täessä useampaa kuin yhtä säiettä

Järjestelmä Säikeiden lukumäärä Hakutaulun luonti Yhden kuvan korjausIGEPv2 2 6400 ms 61 ms

Jolla 2 500 ms 7.6 msPC-1 2 320 ms 4.9 msPC-2 4 75 ms 1.7 ms

5.4.5. Rinnakkainen kuvan korjaus

Vaikka toteutetun ohjelmiston ydintoiminnallisuuteen laskentakuorman säikeistämi-nen ei kuulukaan, testattiin toteutettujen laskentakomponenttien suorituskykyä myösmonisäikeisessä tilanteessa. Neljällä suoritinytimellä varustetussa PC-2 -testijärjestel-mässä laskenta jaettiin neljään säikeeseen. Muissa järjestelmissä käytettiin vain kahtasäiettä.

Testijärjestelystä jossa ei käytetty hakutaulukko-optimointia mutta jossa lasken-nan jakoa useaan säikeeseen käytettiin on suoritusajat kerätty taulukkoon 5. Yhdel-lä Cortex-A8 -suoritinytimellä varustetussa IGEPv2-järjestelmässä säikeiden käyttöodotetusti ei auttanut lainkaan. Kaikissa muissa järjestelmissä laskennan suorituskykykuitenkin parani merkittävästi.

5.4.6. Rinnakkainen hakutaulukko-optimoitu kuvan korjaus

Koska toteutetun ohjelmiston hakutaulukko-optimoidun kuvan korjaustoiminnon pys-tyy jakamaan useaan säikeeseen, testattiin sen myös suorityskykyä usealle säikeellejaettuna. Suoritusajat ovat taulukossa 6.

Huomattavaa tuloksissa on, että hakutaulukko-optimointia käytettäessä yhden ku-van korjaus ei nopeudu läheskään suoraan suhteessa säikeiden määrään. IGEPv2-järjestelmässä suorituskyky jopa huononee selvästi verrattuna yksisäikeiseen tapauk-seen.

Syyksi huonoon suorituskykyyn epäillään sitä, että käytetty säikeisiin jakomenet-tely tuottaa kutakin korjattua kuvaa kohden joukon hyvin lyhytkestoisia säikeitä.Erityisesti PC-2 -järjestelmässä jokaista noin 1.7 ms kestävää korjaustoimenpidettävarten luodaan neljä säiettä. Neljästä suoritinytimestä huolimatta PC-2:lla korjauksensäikeistäminen vain likimain puolittaa tarvittavan laskenta-ajan. Testijärjestelmistä ai-

48

Taulukko 7. PLD-käskyn ennakon vaikutus hakutaulukko-optimoituun kuvan korjauk-seen

pld_offset Yhden kuvan korjaus0 (ei optimointia) 38.5 ms

1 37.3 ms2 36.9 ms3 34.6 ms4 33.9 ms5 33.5 ms6 33.4 ms7 32.7 ms8 33.1 ms9 34.7 ms

10 34.8 ms11 34.7 ms12 35.6 ms

noastaan Jollan tapauksessa säikeistämällä saatu nopeusetu likimain vastaa laskentaankäytettyjen säikeiden määrää.

5.4.7. Hakutaulukkohaun PLD-optimointi Cortex-A8:ssa

Edellä esitellyt laskenta-ajat mitattiin ilman luvussa 3.3 esiteltyä PLD-esilatauskäskyä.Koska käsky on käytettävissä vain osassa ARM-arkkitehtuuria edustavissa suorittimis-sa ja sen vaikutukset suorittimen toimintaan ovat lisäksi suoritinmallikohtaisia, keski-tytään tässä luvussa sen vaikutuksiin nimenomaan Cortex-A8:n osalta.

Luvussa 4.1.5 sivuutettiin listauksessa 11 näkyvän pld_offset -ennakon arvo. Kos-ka sopivan esilatausennakon valinta muilla keinoin on monimutkaista [21], mitataanohjelman suoritusaikaa eri ennakoilla. Mittaustulokset on kerätty taulukkoon 7.

Mittaustuloksista havaitaan, että PLD-käskyä käyttämällä voi vaikuttaa kuvan haku-taulukkoa käyttävän korjauksen suorituskykyyn mitattavissa määrin. Paras tulos saavu-tetaan, kun hakutaulukon alkiota N käsiteltäessä pyydetään suoritinta esilataamaan al-kioN+7. Tällöin alkuperäinen, yli 38 millisekunnin käsittelyaika supistuu alle 33 mil-lisekuntiin. Jos yhden 1280x720 -kokoisen kuvan tuottaminen kestää 720 MHz suorit-timella 33 millisekuntia, tarkoittaa tämä että yksi hakutaulukon alkio käytetään noin25,8 kellosyklin välein.

Tilannetta havainnollistetaan kuvan 15 avulla. Kuvan pienet nelikulmiot ovat muis-tissa sijaitsevia, 4 tavun kokoisia hakutaulukon alkioita. Kuvan esimerkissä ollaantilanteessa, jossa tämänhenkinen käsiteltävä alkio on juuri 7 alkion päässä seuraavanvälimuistirivin alusta. Alkiota kohdassa pos + 7 tarvitaan noin 180 kellosyklin kulut-tua. Kyseinen alkio luultavasti ei ole ennalta välimuistissa välimuistissa, koska aiem-mat kuvankorjaussilmukan kierrokset ovat aiheuttaneet muun muassa kaikkien aiem-min käytettyjen hakutaulukon alkioiden lataamisen. Mikäli ennakkolatausta ei tehdä,joutuu suoritin todennäköisesti pos+ 7 -alkiota ladatessaan odottamaan sen aikaa, kunkyseinen alkio ja sitä seuraavat 15 alkiota ladataan keskusmuistista L2-välimuistiin.

50

sekuntia. Mikäli lisämuistin käyttäminen hakutaulukolle olisi mahdoton ratkaisu, voisioptimoitujen assembly-kielisten laskentarutiinien kirjoittaminen olla järkevää.

AR.Drone 2.0:n suorittimessa on kaksi kertaa suuremmat välimuistit kuin tässäkäytetyssä IGEPv2-testilaitteistossa. Lisäksi AR.Drone 2.0:n suorittimen kellotaajuuson on korkeampi. Edellä IGEPv2 -laitteistolla saavutetun suorituskyvyn pitäisi siksiolla saavutettavissa myös AR.Drone 2.0:n laitteistolla.

51

6. YHTEENVETO

Työssä toteutettiin ohjelmisto, jonka avulla Kannalan kehittämää kalibrointimenetel-mää [17] voidaan hyödyntää AR.Drone 2.0:ssa tai muussa sulautetussa järjestelmässä.Toteutettu ohjelmisto korjaa kameran vääristyneitä kuvia perspektiivimallin mukaisik-si. Toteutettu ohjelmisto on vain pieni osa kokonaisuudesta, jossa kameran kautta mi-tattaisiin ympäristön geometrisia piirteitä.

Aluksi tutustuttiin kameran kalibrointiin ja muutamaan olemassa olevista kalibroin-tiin käytettävistä kameramalleista. Kannalan ja Brandt:n kehittämä malli poikkeaamerkittävästi perinteisistä perspektiivimallista johdetuista malleista. Malli sopii hyvinAR.Drone 2.0:n kameralle.

AR.Drone 2.0:n laitteistoa ja ohjelmistoa tarkasteltiin sille tarkoitetun ohjelmistonkehittämisen kannalta. Laitteisto on laskentakapasiteetiltaan likimain älypuhelinta vas-taava. Tallennustilaa ja muistia AR.Drone 2.0:ssa on käytettävissä rajallisesti. Ku-vankäsittelytoimintojen todettiin vaativan paljon muistin lukemista ja kirjoittamista.Nykyaikaisissa suorittimissa algoritmin vaatima laskenta-aika voi välimuistin toimin-nan takia riippua merkittävästi siitä, missä järjestyksessä muistia käsitellään.

Ohjelmisto toteutettiin siten, että sen hyödyntäminen myös muissa käyttökohteis-sa olisi mahdollisimman käytännöllistä. Laskentaosien käyttäminen ohjelman osana eiedellytä esimerkiksi tiettyä käyttöjärjestelmää tai suuria projektin ulkopuolisia lasken-takirjastoja. Ohjelmisto on yhteensopiva useiden C++-kääntäjien kanssa ja sopii sekäsulautetussa järjestelmissä yleisille ARM-suorittimille että x86-suorittimille. Ohjelmis-toon toteutettiin myös osia, jotka eivät suoraan ole käyttökelpoisia AR.Drone 2.0:ssa.Esimerkiksi graafista käyttöliittymää ei ole tarpeen suorittaa laitteessa jossa ei ole näyt-töä. Toteutetut lisätoiminnot tukivat kuitenkin ohjelmiston AR.Drone 2.0:lle suunnitel-tujen osien kehittämistä.

Kannala-Brandt -kameramallin mukainen kuvien korjaaminen perspektiivimallinmukaiseksi ilman hakutaulukkoa osoittautui erittän hitaaksi. Jokaiselle kuvapisteelletrigonometria- ja polynomifunktioiden arvojen laskeminen vaatii yksinkertaisesti lii-kaa suoritinaikaa. Hakutaulukko-optimointia käyttämällä ohjelmiston suorituskykyperspektiivimallin mukaisien kuvien tuottamisessa saadaan lähelle reaaliaikaista. Näintekemällä ohjelmiston vaatima muistikapasiteetti kasvaa noin kolme megatavua käsi-teltäessä AR.Drone 2.0:n etukameran kuvia. AR.Drone 2.0:n keskusmustin käyttämät-tä jäänyt 20 megatavun kapasiteetti riittää tästä huolimatta.

Suunnitteluvaiheessa ohjelmiston suorituskyvyn arvioitiin riippuvan merkittävästisuorittimen välimuistin tehokkaasta hyödyntämisestä. ARM-suorittimille toteutetunennakkolatausoptimoinnin onnistumisen perusteella tämä pitääkin paikkansa. Ohjel-miston käsittelemä pakkaamaton kuvadata on kooltaan useita megatavuja, joten useim-missa suorittimissa se tai kuvan korjauksessa käytetty hakutaulukko eivä mahdu edeslaitteiston suurimpaan, uloimman tason välimuistiin. Erityisesti AR.Drone 2.0:n ta-pauksessa suurin välimuistitaso on kooltaan vain 256 KiB.

Viime vuosina myös ARM-arkkitehtuuria edustavissa mobiililaitteissa ovat moniy-timiset suorittimet yleistyneet. Vaikka AR.Drone 2.0:n suoritin on yksiytiminen, to-teutettu ohjelmisto sisältää valmiuden laskennan suorittamiseen osissa. Valmiutta voihyödyntää laskentakuorman usealle suoritinytimelle jakamiseen. Suorituskykymittauk-sissa tämän havaittiinkin merkittävästi vähentävän ohjelmiston vaatimaa laskenta-aikaa. Esimerkiksi kaksiytimisellä ARM-suorittimella varustetussa Jolla-puhelimes-

52

sa laskenta-aika käytännössä puolittuu, kun molemmat ytimet hyödynnetään. Kaikissatestatuissa tapauksissa skaalautuminen ei kuitenkaan ole lineaarista suorittimien yti-mien määrän suhteen. Yksiytimisessä järjestelmässä rinnakkain ajettaviin säikeisiinjakaminen jopa hidastaa laskentaa.

53

7. LÄHTEET

[1] Parrot, Ar.drone 2.0. URL: http://ardrone2.parrot.com/, luettu 6.5.2014.

[2] Parrot AR.Drone Developer Guide SDK 2.0. URL: https://projects.ardrone.org/projects/show/ardrone-api, luettu 6.5.2014.

[3] Parrot AR.Drone 2.0 Quick start guide. URL: http://ardrone2.parrot.com/support/, luettu 6.5.2014.

[4] Sturm P, Ramalingam S, Tardif J P, Gasparini S & Barreto J (2010) Camera mod-els and fundamental concepts used in geometric computer vision. Foundationsand Trends in Computer Graphics and Vision 6(1-2), pp. 1–183.

[5] Kannala J & Brandt S S (2006) A generic camera model and calibration methodfor conventional, wide-angle, and fish-eye lenses. IEEE Transactions on PatternAnalysis and Machine Intelligence 28(8), pp. 1335–1340.

[6] Tsai R Y (1987) A versatile camera calibration technique for high-accuracy 3dmachine vision metrology using off-the-shelf tv cameras and lenses. IEEE journalof robotics and automation RA-3(4), pp. 323–344.

[7] Devernay F & Faugeras O (2001) Straight lines have to be straight. MachineVision and Applications 13(1), pp. 14–24.

[8] Kannala J (2010) Models and methods for geometric computer vision. Väitöskir-ja, University of Oulu.

[9] Grossberg M D & Nayar S K (2001) A general imaging model and a method forfinding its parameters. In: Proceedings of the IEEE International Conference onComputer Vision, vol. 2, pp. 108–115.

[10] Sturm P (2005) Multi-view geometry for general camera models. Proceedings ofthe IEEE Computer Society Conference on Computer Vision and Pattern Recog-nition 1, pp. 206–212.

[11] Grossberg M D & Nayar S K (2005) The raxel imaging model and ray-basedcalibration. International Journal of Computer Vision 61(2), pp. 119–137.

[12] Kannala J, Heikkilä J & Brandt S S (2008) Geometric camera calibration. In:Wiley Encyclopedia of Computer Science and Engineering.

[13] Hartley R & Zisserman A (2003) Multiple View Geometry in Computer Vision.Cambridge University Press, 2nd ed.

[14] Fitzgibbon A (2001) Simultaneous linear estimation of multiple view geometryand lens distortion. pp. I125–I132.

[15] Heikkilä J & Silvén O (1997) A four-step camera calibration procedure with im-plicit image correction. Proc. IEEE Conference on Computer Vision and PatternRecognition, June 17-19, San Juan, Puerto Rico, 1:1106-1112.

54

[16] Xiong Y & Turkowski K (1997) Creating image-based vr using a self-calibratingfisheye lens. In: Proceedings of the IEEE Computer Society Conference on Com-puter Vision and Pattern Recognition, pp. 237–243.

[17] Kannala J (2013), Camera calibration toolbox for generic lenses. URL: http://www.ee.oulu.fi/~jkannala/calibration/.

[18] Texas Instruments OMAP36xx Multimedia Device Technical Reference Manual.

[19] ARM Ltd, Cortex-a8 processor. URL: http://www.arm.com/products/processors/cortex-a/cortex-a8.php, luettu 6.5.2014.

[20] Iordache C & Tang P (2003) An overview of floating-point support and mathlibrary on the intel R© xscaleTM architecture. pp. 122–128.

[21] Drepper U (2007) What every programmer should know about memory. Tech.rep., Red Hat, Inc.

[22] ARM Ltd Cortex-A8 Technical reference manual. Versio r3p2.

[23] ARM Ltd ARM Architecture Reference manual ARMv7-A and ARMv7-R edi-tion.

[24] AVR libc (2014), Memory areas and using malloc(). URL: http://www.nongnu.org/avr-libc/user-manual/malloc.html.

[25] Seppälä M (2014) Ympäristön 3D-mallintaminen quadrokopterilla kuvatun 2D-videon pohjalta. Diplomityö, Oulun yliopisto, tietotekniikan osasto.