Joonas Sarajärvi Reaaliaikainen kuvaprosessointi robottihelikopterissa

Transkriptio

1 TIETOTEKNIIKAN OSASTO Joonas Sarajärvi Reaaliaikainen kuvaprosessointi robottihelikopterissa Diplomityö Tietotekniikan koulutusohjelma Toukokuu 2014

2 Sarajärvi L.J. (2014) Reaaliaikainen kuvaprosessointi robottihelikopterissa. Oulun yliopisto, Tietotekniikan osasto. Diplomityö, 54 s. TIIVISTELMÄ Kameran kalibrointi on menettely, jolla selvitetään kameran tuottamien kuvapisteiden ja kameralla kuvatun näkymän geometrian suhde. Tavallisesti suhde esitetään kameramallin avulla. Tyypillisesti kalibrointimenetelmät sovittavat jonkin kameramallin parametrit vastaamaan kameran kuvista tehtyjä havaintoja. Kalibrointi on tarpeellinen, mikäli kameran kuvasta mitataan geometrisia suureita. Tässä työssä toteutetaan ohjelmisto, joka noudattaa Oulun yliopiston konenäön tutkimuskeskuksessa kehitettyä kameramallia. Ohjelmiston avulla AR.Drone 2.0 -robottihelikopterin kameralle suoritettua kalibrointia voi hyödyntää AR.Drone 2.0:n omalla suorittimella. Ohjelmisto sopii myös muihin sulautettuihin järjestelmiin ja PC-tietokoneisiin. Taustatietona tarkastellaan olemassa olevia kameramalleja ja verrataan toteutuksen noudattamaa kameramallia näihin malleihin. AR.Drone 2.0:n laitteistoa ja ohjelmistoa tarkastellaan toteutettavan ohjelmiston kohdealustana toimimisen näkökulmasta. Toteutetuista kuvankäsittelymenetelmistä esitetään perustoteutus ja sitä nopeuttavia optimointeja. Erityisesti ohjelmiston ja suorittimen välimuistin vuorovaikutukseen kiinnitetään huomiota. Valittujen menetelmien todetaan soveltuvan myös jaettavaksi usealle suoritinytimelle rinnakkaiseen laskentaan. Lopuksi toteutetun ohjelmiston suorituskykyä arvioidaan sekä ARMsuoritinarkkitehtuuria edustavissa sulautetuissa järjestelmissä että PC-työasemissa. Toteutetulla ohjelmistolla voi korjata kalibroidun kameran kuvia perspektiivimallin mukaiseksi. ARM Cortex-A8 -suorittimella ohjelmisto kykenee korjaamaan AR.Drone 2.0:n kameran tuottamia kuvia reaaliajassa. Avainsanat: kameran kalibrointi, sulautettu järjestelmä, välimuistin optimointi

3 Sarajärvi L.J. (2014) Real time image processing in a robot helicopter. University of 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 produced by a camera and the geometry of the scene that is imaged. Usually the relationship is expressed as a camera model. Typically, calibration techniques fit the parameters of a specific camera model to match observations made from images produced by a camera. A calibration should be performed for a camera if images produced by it are used for measurement of geometric attributes. In this work, a camera model developed at the Center for Machine Vision Research of Oulu University is implemented in software. The implemented software can be run on the AR.Drone 2.0 robot helicopter, enabling application of calibration to the camera that is used in the device. The software is also suitable for being run in other embedded systems and in conventional personal computers. For background, a number of existing camera models are discussed. The model used in the software implementation is compared to other models. The computer hardware and software present in the AR.Drone 2.0 is discussed from the point of view of writing software for them. Of the implemented algorithms, both a basic implementation and various optimiziation techniques are described. This thesis focuses on the interaction between software and the CPU caches. A description on how the algorithms are suitable for concurrent processing on multiple CPU cores is given. Finally, the performance of the implemented software is evaluated on ARM-based systems and personal computers. The software implemented as part of the work can be used for correcting images produced by a calibrated camera to obey the perspective model. On an ARM Cortex-A8 CPU, the images taken by an AR.Drone 2.0 can be corrected in real time. Keywords: camera calibration, cache optimization, embedded system

4 SISÄLLYSLUETTELO TIIVISTELMÄ ABSTRACT SISÄLLYSLUETTELO ALKULAUSE LYHENTEIDEN JA MERKKIEN SELITYKSET 1. JOHDANTO 8 2. KAMERAN KALIBROINTI Kameramallit Geneeriset kameramallit Aksiaaliset kameramallit Pistemäiset kameramallit Perspektiivikameramalli Laajennettu perspektiivimalli Xiong-Turkowski -malli Kannala-Brandt -malli Mallin yksityiskohdat Käänteinen malli Mallin valinta KUVAPROSESSOINTI SULAUTETUSSA OHJELMISTOSSA Kohdejärjestelmän kuvaus OMAP ARM Cortex-A Signaalinkäsittelysuoritin AR.Drone 2.0:n vakio-ohjelmistot Yhteensopivuus Välimuisti Ohjelmointikielet Pohdinta KEHITETTY OHJELMISTO Twirl-kirjasto Polynomit Matriisit Kannala-Brandt -mallin toteutus Kuvan korjaus perspektiivimallin mukaiseksi Korjauksen hakutaulukko-optimointi Twirr-kirjasto Käyttöliittymät ja testaus

5 5. TULOKSET Testiympäristöt Kalibrointi Tarkkuus Laskennalliset resurssit Ohjelmiston koko Keskusmuistikapasiteetti Kuvan korjaus perspektiivimallin mukaiseksi Hakutaulukko-optimoitu kuvan korjaus Rinnakkainen kuvan korjaus Rinnakkainen hakutaulukko-optimoitu kuvan korjaus Hakutaulukkohaun PLD-optimointi Cortex-A8:ssa Pohdinta YHTEENVETO LÄHTEET 53

6 ALKULAUSE Tämä diplomityö kirjoitettiin keväällä 2014 Oulun yliopiston tietotekniikan osastolle. Haluan kiittää ohjaajiani Jari Hannukselaa ja Jani Boutellieria kannustavasta ja rakentavasta opastuksesta. Lisäksi kiitän Juho Kannalaa ja Antti Tikanmäkeä asiantuntijaavusta työhön liittyvien teknisten yksityiskohtien selvittämisessä. Työnantajaani Embelin 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 ansaitsee myös vaimoni Kati, jonka piristävä tuki on toistuvasti kannustanut selvittämään hankalatkin ongelmat. Oulussa 22. toukokuuta 2014 Joonas Sarajärvi

7 LYHENTEIDEN JA MERKKIEN SELITYKSET (a, b) T ARM DRAM GCC GiB KiB MiB OMAP PNG SoC SRAM (u, v) T WLAN x86 Sarakevektori ARM Holdings:n kehittämä suoritinarkkitehtuuri Dynamic Random Access Memory GNU Compiler Collection Gibitavu, tavua Kibitavu, 1024 tavua Mebitavu, tavua Open Multimedia Applications Platform Portable network graphics, kuvatiedostoformaatti System-on-Chip Static Random Access Memory Kuvapisteen sijainti pikseleissä Wireless Local Area Network, langaton lähiverkko Intel 386-suorittimen kanssa yhteensopivat suoritinarkkitehtuurit x86-64 x86-suoritinarkkitehtuurin 64-bittinen laajennos x = (x, y) T Kuvapisteen sijainti kameran sensorissa

8 8 1. JOHDANTO Viime vuosina markkinoille on ilmaantunut suuret määrät edullisia, alle tuhannen euron hintaisia pienoisilma-aluksia, joita periaatteessa kuka hyvänsä asiasta kiinnostunut pystyy hankkimaan ja käyttämään. Leluluonteisten tuotteiden lisäksi saatavilla on myös vakavammin otettavaksi tarkoitettuja laitteita, joilla esimerkiksi voi edullisesti ottaa ilmakuvaa lähiympäristöstä. Yksi suosittu tuote on Parrot:n valmistama AR.Drone 2.0 -lentolaite, joka on alle puolen 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ä ohjauskomentoja ja lähettää reaaliaikaista videokuvaa kameroistaan. Laite on sellaisenaan pitkälle tuotteistettu, eikä sen ohjaaminen vaadi erityistä harrastuneisuutta pienoisilmailuun. [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ä vakaana paikallaan, mutta suuri osa toiminnasta perustuu käyttäjältä, lentolaitteen ulkopuolelta vastaanotettuihin komentoihin. Mielenkiintoiseksi erilaisiin harraste- ja tutkimusprojekteihin AR.Drone 2.0:n tekevät laitteen matala noin 300 euron hinta ja se, että ohjaamiseen käytettävät protokollat ovat julkisesti saatavilla [2]. Protokolladokumentaatio on parantanut Parrotin ulkopuolisten tahojen mahdollisuuksia kehittää omia työkaluja laitteen ohjaamiseen. Viestiliikennettä laitteen kameroiden, sensorien, ohjainpiirien ja WLAN-liitännän välillä ohjaa AR.Drone 2.0:ssa OMAP3630 -piiri, jossa suoritetaan Linuxiin perustuvaa käyttöjärjestelmää [3]. Piirin 1 GHz kellotaajuudella toimiva Cortex-A8 -suoritin on laskentakapasiteetiltaan vastaava kuin esimerkiksi monien älypuhelinten suorittimet. AR.Drone 2.0:n sisäistä ohjelmistoa ei varsinaisesti ole tarkoitettu käyttäjän vaihdettavaksi, mutta niin pystyy tekemään laitteen tarjoamista verkkorajapinnoista. Tämän takia laite on houkutteleva kokeilualusta erilaisiin lentäviä robotteja koskeviin projekteihin. Mikäli AR.Drone 2.0:n tai muun vastaavan laitteen haluttaisiin kykenevän suorittamaan tehtäviä itsenäisesti ilman jatkuvaa ulkopuolista ohjausta, voitaisiin videokuvaa lähettävät toiminnot korvata laitteen sisäisessä suorittimessa toimivalla automaattiohjauksella. Automaattiohjauksen avulla laite voisi suunnistaa haluttuun kohteeseen ja sieltä takaisin itsenäisesti. Maanpinnan lähellä ilma-alusta ei kuitenkaan voi ohjata pelkästään esimerkiksi GPS-paikannuksen avulla, vaan laitteen tulee esimerkiksi pystyä havaitsemaan ja kiertämään ympärillä olevat esteet. Usein ympäristön kartoittamiseen kameran kuvan avulla käytetyt menetelmät vaativat tai vähintään hyötyvät siitä, että kuvasta havaittujen piirteiden suunnat suhteessa kameraan tunnetaan riittävän tarkasti. Perinteistä perspektiivimallia noudattavien kameroiden optiikassa esiintyy kuitenkin tyypillisesti vääristymää, joka heikentää mittausten tarkkuutta erityisesti kuvien reuna-alueilla. Esimerkiksi AR.Drone 2.0:n kameran kuvissa vääristymä on todettavissa silmämääräiselläkin tarkastelulla. Lisäksi osa laajakulmaisista kameraratkaisuista ei noudata perspektiivimallia lainkaan. Kuvasta havaittujen piirteiden koordinaatit voidaan määrittää tarkemmin, jos kamera kalibroidaan. Kalibroidusta kamerasta tunnetaan tarkasti, missä suunnassa mikäkin havaittu 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.Dronen kaltaisessa sulautetussa järjestelmässä on vaikeaa. Muita kuin Matlabilla toteutettuja ratkaisuja 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 sulautettuun järjestelmään soveltuva kuvankorjausohjelmisto, joka noudattaa Oulun yliopiston konenäköryhmässä [5] kehitettyä menetelmää. Ohjelmisto mahdollistaa perspektiivimallista poikkeavien kuvien korjaamisen perspektiivimallin mukaisiksi, mikä helpottaa kuvatun esineen tai ympäristön geometrian mittaamista. Lisäksi kuvan korjaaminen 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 ja tuottaa x720 pikselin kuvaa sekunnissa. Alas päin osoittava kamera tuottaa kuvia 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.Drone 2.0:ssa toimiva ohjelmisto tarvitsisi tietoa jokaisesta etukameran kuvasta esimerkiksi oman nopeutensa seuraamiseen, sille jäisi noin 33 millisekuntia yhden kuvan käsittelyyn. Kellosykleinä tämä olisi kymmeniä miljoonia, mutta etukameran kuvassa on pikseleitäkin lähes miljoona. Käsiteltävän kuvadatan määrää voi tarvittaessa pienentää alinäytteistämällä videokuvaa paikkatasossa tai jättämällä osan kuvista käsittelemättä. Tämä on tarkkuuden kannalta kompromissi, mutta useimmissa sovelluksissa suoritinaikaa pitää jättää käytettäväksi myös muille toiminnoille kuin kuvan perspektiivikorjaustoiminnolle. Jotta tasapainoilua laskennan nopeuden ja tarkkuuden välillä tarvitsisi tehdä mahdollisimman vä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älaiset valmiudet ohjelmistojen suorittamiseen AR.Drone 2.0 tarjoaa. Kun oleellisimmat työhön liittyvät taustatiedot on käsitelty, esitellään työn osana toteutetun ohjelmiston teknisiä ratkaisuja. Lopuksi tarkastellaan toteutetun ohjelmiston suorituskykyä ja soveltuvuutta käyttötarkoitukseensa. 9

10

11

12

13 13 Mikäli tunnetaan kameran R 3 -koordinaatistossa oleva piste (x, y, z), voidaan edellä mainitun merkintätavan mukainen esitys tulokulmalle laskea sijoittamalla x, y ja z piste yhtälöön Φ = ( ) θ = φ ( ) arctan( x2 + y 2, z). (2) arctan(y, x) Yhtälössä (2) käytetään kaksiparametrista arctan-funktiota, joka tässä työssä määritellään perinteisen yksiparametrisen arctan-funktion kautta yhtälön arctan(y/x) : x > 0 π/2 : x = 0, y > 0 arctan(y, x) = π + arctan(y/x), : x < 0, (3) π/2 : x = 0, y < 0 0 : x = 0, y = 0 mukaisesti. Määritelmän arctan(0, 0) = 0 -haara on mielivaltaisesti valittu. Käytännössä tässä työssä ei ole väliä sillä, mikä arvo φ-kulmalle valitaan silloin kun valonsäde tulee suoraan kameran edestä. Kannalan ym. [12] mukaan myös useimmat sellaiset kamerat, jotka eivät ole pistemäisiä, ovat kuitenkin häviävän pieniä verrattuna kameralla kuvattavaan järjestelmään. Tällaisessa tilanteessa kameraa voidaan kohdella pistemäisenä ja käyttää pistemäistä kameramallia Perspektiivikameramalli Kameramalleista mahdollisesti perinteisin on pistemäisiin kameramalleihin kuuluva perspektiivikameramalli, joka on tunnettu jo ainakin renessanssista asti [11]. Perspektiivimallin mukaista kameraa kutsutaan perspektiivikameraksi. Vaikka perspektiivikameramalli muistuttaa suuresti perinteisen neulanreikäkameran geometriaa, on Grossbergin mukaan myös muita kameroita rakennettu siten, että ne noudattavat samaa mallia [11]. Myös Kannalan ym. [12] mukaan perspektiivikameramallia voi soveltaa useimpiin tavanomaisiin kameroihin. Perspektiivikameramalli noudattaa yhtälöä ( x y ) = ( f X/Z f 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 kuvautuminen kuvatasoon voidaan esitttää P 2 :n projektiivisena muunnoksena. Projektiivinen muunnos kuvaa suorat suoriksi. [13 s. 25] Tämän lisäksi perspetiivikameran tuottamaan kuvaan voidaan soveltaa myös muita projektiiviseen geometriaan nojaavia menetelmiä. Kannalan mukaan perspektiivikameraa voi pitää suuntailmaisimena, joka kuvaa kunkin kameraan tulevan valonsäteen suunnan joksikin pikseliksi seuraavan yhtälön ( x y ) = tan(θ) ( cos(φ) sin(φ) ) (5)

14 14 mukaisesti. Kannalan mukaan yhtälön perusteella on selvää, että perspektiivikameran kuvakulman 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 algoritmit hyödyntävät perspektiivimallia. Grossberg:n ja Nayar:n [9] mukaan sekä optiikkaa että konenäköä kehitettäessä on keskitytty juuri perspektiivimallin ominaisuuksiin. Lisäksi esimerkiksi Fitzgibbon [14] esittää algoritmeja, joiden tarkkuus edellyttää, että kuvien vastinpisteet haetaan perspektiivimallin mukaisista kuvista. Koska perspektiivimalli on yksinkertainen, yleinen ja hyvin tunnettu, usein kuva korjataan perspektiivimallin mukaiseksi Laajennettu perspektiivimalli Koska suuressa osassa perspektiivimallin mukaisiksikin tarkoitettuja kameroita esiintyy perspektiivimallin vastaisia vääristymiä, on usein päädytty laajentamaan perspektiivimallia 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. Vaihtoehtoisesti voidaan korjata vääristyneestä kuvasta havaittuja koordinaatteja vastaamaan paremmin kuvattujen esineiden todellisia sijainteja. Laajennoksia perspektiivimallille on esitetty useita. Esimerkiksi Heikkilä ja Silvén [15] ovat käyttäneet mallia, jossa perinteisen perspektiivimallin antamaa kameratason sijaintia (x, y) vastaa yhtälön ( u v ) = G(x, y) = [ Du s u (x + x(k 1 r 2 + k 2 r ) + 2p 1 xy + p 2 (r 2 + 2x 2 )) D v (y + y(k 1 r 2 + k 2 r ) + p 1 (r 2 + 2y 2 ) + 2p 2 xy) mukainen kuvapiste. Yhtälössä (6) r saadaan suoraan lausekkeesta x 2 + y 2, kun taas {k 1, k 2,...}, p 1 ja p 2 ovat mallin vääristymän kuvaavia parametreja, jotka voidaan selvittää Heikkilän ja Silvén:n esittämällä kalibrointimenettelyllä. ] (6) 2.4. Xiong-Turkowski -malli Xiong ja Turkowski [16] esittivät vuonna 1997 pistemäisen kameramallin, joka poikkeaa huomattavasti perspektiivikameramallista ja sen laajennoksista. Perspektiivimallia ei käytetty mallin perustana varsinkin siksi, että se erittäin laajakulmaisten linssien koko kuva-alaa ei saada perspektiivimallilla mallinnettua. Malli esittää yhtälön (1) kaltaisten (θ, φ) -parien kuvautumisen valosensorin pinnalle yhtälön. ( ) ( ) x cos(φ) = r(θ) (7) y sin(φ) mukaisesti. Yhtälössä (7) funktio r(θ) kuvaa kameran akselin ja valonsäteen välisen kulman etäisyydeksi sensorin keskipisteestä yhtälön r(θ) = c 1 θ + c 2 θ 2 + c 3 θ (8)

15

16 16 missä r(θ) on yhtälön r(θ) = k 1 θ + k 2 θ 3 + k 3 θ 5 + k 4 θ 7 + k 5 θ (11) mukainen parittomia kertoimia sisältävä polynomifunktio. Yhtälöissä (10) ja (11) θ on kameran symmetria-akselin ja kameraan tulevan valonsäteen välinen kulma ja φ kierto symmetria-akselin ympäri. Epäsymmetrinen vääristymä mallinnetaan erikseen radiaaliseen ja tangentiaaliseen suuntaan. Radiaaliseen suuntaan vääristymän suuruus on yhtälön r (θ, φ) = (l 1 θ + l 2 θ 3 + l 3 θ 5 )(i 1 cos φ + i 2 sin φ + i 3 cos 2φ + i 4 sin 2φ) (12) mukainen. Vääristymän suuruus riippuu siis θ:n ja φ:n avulla ilmaistusta havaitun valonsäteen tulokulmasta. Tangentiaaliseen suuntaan epäsymmetrisen vääristymän suuruus kuvataan yhtälön t (θ, φ) = (m 1 θ + m 2 θ 3 + m 3 θ 5 )(j 1 cos φ + j 2 sin φ + j 3 cos 2φ + j 4 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 aiheuttaman poikkeaman kuvatasossa kuvaava funktio S yhtälön s = S(Φ) = r (θ, φ)u r (φ) + t (θ, φ)u t (φ) (14) mukaisesti. Mallin epäsymmetrisen osan yhdistäminen symmetriseen osaan on esitetty yhtälössä ( ) xd x d = = x + s = r(θ)u r (φ) + r (θ, φ)u r (φ) + t (θ, φ)u t (φ), (15) y d missä x d on symmetrisen mallin antaman tuloksen ja epäsymmetristen vääristymien summavektori, u r (φ) on yksikkövektori kameran sensorin koordinaatistossa radiaaliseen suuntaan ja u t (φ) on yksikkövektori tangentiaaliseen suuntaan. Kuvatason koordinaatit valosensorin pikseleiden koordinaateiksi kuvaa malliin sisältyvä affiini H -muunnos määritellään kertoimien {m u, m v, u 0, v 0 } kautta yhtälön ( ) [ ] ( ) ( ) u mu 0 xd u0 = + (16) v 0 m v mukaisesti. Yhtälön voi järjestää uudelleen muotoon ( ) ( ) u mu x = H(x v d, y d ) = d + u 0. (17) m v y d + v 0 y d v Käänteinen malli Yhtälössä (15) määritelty malli on funktio, joka kuvaa kameran keskipisteen läpi kulkevien valonsäteiden kulmat sijainneiksi kameran sensorikennolla. Usein on kuitenkin myös tarpeen selvittää, mitä valonsädettä jokin pikseli vastaa. Tämän kulman

17 17 laskemisesta kutsutaan käänteiseksi projisoinniksi (eng. backprojection). Yhtälöä (9) vastaava käänteinen projisointi voidaan kuvata yhtälön ( ) θ = Pc 1 (u, v) = (F 1 D 1 H 1 )(u, v) (18) φ mukaisella Pc 1 -funktiolla, jonka komponentit ovat suoraan yhtälön (9) käänteisoperaatioita. 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 (x d ) x d ( I + Yhtälössä (15) S on yhtälön Φ ( ) (( ) ) 1 1 S F Φ F 1 (x d ) Φ F 1 (x d )) (S F 1 )(x d ) S Φ = ( sx θ s y θ s x φ s y φ ) (19) (20) mukainen osittaisderivaattamatriisi ja F Φ F Φ = on yhtälön ( x θ y θ x φ y φ ) (21) mukainen osittaisderivaattamatriisi Mallin valinta AR.Drone 2.0:n etukameralle aksiaaliset ja täysin geneeriset kameramallit ovat tarpeettoman 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ä se on helposti havaittavissa silmämääräisestikin tarkasteltuna. Jokin perspektiivimallin vää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 soveltuu Kannalan ja Brandt:n [5] mukaan soveltuu tavanomaisille kameroille yhtä hyvin kuin perinteisemmät kameramallit. AR.Drone 2.0:n kamera ei ole niin laajakulmainen että Kannala-Brandt -mallin sopivuudella kalansilmälinsseille olisi tässä sovelluksessa merkitystä. Mahdollisuus myös kalansilmälinssien käyttämiseen jossain muussa sovelluksessa tai esimerkiksi optiikaltaan muunnellussa AR.Drone 2.0:ssa on hyödyllinen piirre. Lisäksi mallin odotetaan olevan yksinkertaisempi, kuin vääristymän huomioivaksi laajennettu perspektiivikameramalli.

18 18 3. KUVAPROSESSOINTI SULAUTETUSSA OHJELMISTOSSA Tässä osassa työtä kuvataan seikkoja, jotka huomioidaan kirjoitettaessa ohjelmistoa sulaututettuun järjestelmään tai muuhun ympäristöön, jossa laskennalliset resurssit ovat rajalliset. Muut sulautettujen järjestelmien erityispiirteet jäävätkin toteutettavan ohjelmiston laskentapainotteisuuden takia vähälle huomiolle Kohdejärjestelmän kuvaus Työssä kehitetyn ohjelmiston halutaan olevan yhteensopiva erilaisten laitealustojen kanssa. Toisaalta sen suorituskykyyn nimenomaan AR.Drone 2.0:n sisältämässä laitteistossa kiinnitetään erityistä huomiota. Tässä luvussa esitellään AR.Drone 2.0:n ominaisuuksia ohjelmoijan näkökulmasta OMAP3630 AR.Drone 2.0 sisältämä [3], Texas Instrumentsin kehittämä OMAP3630-piiri on integroitu kokonainen tietojärjestelmä eli niinsanottu SoC (eng. System-on-Chip). 1 GHz ARM Cortex-A8 -suorittimen lisäksi OMAP3630 sisältää useita muita laitteita yhtenä kokonaisuutena. Integroituna OMAP3630:ssa on muun muassa 64 KiB SRAMmuistia, 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-muisteja [18]. AR.Drone 2.0:ssa SDRAM-muistia on 128 MiB [3] ARM Cortex-A8 Cortex-A8 on ARM Holdings plc:n kehittämä suoritinydin, joka toteuttaa 32-bittisen ARMv7-A -käskykannan. ARMv7-A:n pakollisen toiminnallisuuden lisäksi Cortex- A8 tukee sekä VFPv3-D32 -liukulukukäskyjä että NEON -liukulukukäskyjä. Suorittimen kellotaajuus on tyypillisesti 600 MHz - 1 GHz. L1 -välimuistia suorittimessa on 32 tai 64 kilotavua datalle ja 32 tai 64 kilotavua käskyille. L2-välimuistin koko on laitevalmistajan mukautettavissa, mutta sitä voi olla korkeintaan 1 MiB. [19] ARDrone 2.0:n OMAP3630 -SoC sisältämässä Cortex-A8:sa välimuistien kapasiteetit on valittu siten, että L1-välimuistit ovat 32 KiB kokoisia ja L2-välimuistin koko on 256 KiB [18] Signaalinkäsittelysuoritin OMAP3630-piiriin sisältyy komponenteista on IVA 2.2-signaalinkäsittelylohko, joka perustuu Texas Instruments:n TMS320DMC64X+ -suorittimeen. Suoritin on 32- bittinen kiinteäpisteistä aritmetiikkaa käyttävä signaalinkäsittelysuoritin, joka on op-

19 19 timoitu erityisesti kuvan- ja videonkäsittelyyn. Suoritin pystyy suorittamaan jopa kahdeksan operaatiota kellosyklissä. [18]. Tässä työssä signaalinkäsittelysuoritinta ei juuri huomioida, koska ohjelmistokehitys signaalinkäsittelysuorittimille vaatii usein enemmän työtä kuin vastaavan ohjelmiston kehittäminen yleiskäyttöiselle suorittimelle. Ohjelmistokehitys signaalinkäsittelysuorittimelle vaatii usein suoritinkohtaisia erikoistyökaluja ja erityisosaamista. Yleiskäyttöiselle suorittimelle ohjelmoitaessa työkalut ovat kehittäjille usein ennalta muista projekteista tuttuja. Työssä kehitetyn ohjelmiston osalta työmäärää olisi kasvattanut erityisesti TMS320DMC64X+-suorittimen vaatima kiinteän pisteen aritmetiikan käyttö. Voi olla, että toteutettu ohjelmisto tai osia siitä lopulta on sovitettavissa signaalinkäsittelysuorittimelle. Alustana TMS320DMC64X+:a yleisemmät tavanomaiset ARMsuorittimet ovat kuitenkin ainakin projektin alkuvaiheessa paljon houkuttelevampi kohdealusta AR.Drone 2.0:n vakio-ohjelmistot Parrot:n mukaan [1, 3] AR.Drone 2.0 -laitteeseen sisältyy Linux. Ohjelmistoa ei kuitenkaan ole dokumentoitu muuten kuin sen käyttämien verkkoprotokollien osalta [2]. Jotta toteutetun ohjelmiston soveltuvuutta vakio-ohjelmiston rinnalle voitaisiin arvioida, 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 normaalisti laitetta käytettäessä yhdistetäisiin älypuhelimella laitteen ohjaamista varten [3]. Myös muita WLAN-sovittimella varustettuja laitteita voi kuitenkin käyttää. Tässä kuvattua tarkastelua 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 kautta. Kun laitteeseen yhdistää telnet-asiakasohjelmalla, päästää AR.Drone 2.0 ilman salasanakyselyä käyttämään AR.Drone 2.0:ssa suoritettavaa BusyBox -komentokehottetta. 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ärjestelmää pystyy tutkimaan hyvin esteettömästi. Tietoturvan kannalta voi pitää arveluttavana laitetta, joka käynnistyttyään automaattisesti luo avoimen WLAN-verkon ja lisäksi antaa ilman salasanakyselyä suorittaa komentokehotteen kautta mitä tahansa laitteen ohjelmistoja pääkäyttäjänä. Ratkaisun suojaamattomuus kuitenkin luultavasti haittaa laitteen käyttäjiä hyvin vähän, koska normaalissa käytössä AR.Drone 2.0:n tietojärjestelmä on käynnissä vain jotain kymmeniä minuutteja kerrallaan. Tämän työn kannalta ratkaisu on erittäin käytännöllinen, koska se mahdollistaa sekä vakio-ohjelmiston tutkimisen että mahdollisen muokkaamisen ja korvaamisen. Komentokehotteesta järjestelmää tutkimalla havaitaan, että suuri osa järjestelmän komentorivityökalusta hakemistoissa /bin, /sbin, /usr/bin ja /usr/sbin ovat symbolisia linkkejä /bin/busybox -työkaluun. Tämä on normaali käytäntö järjestelmässä, jossa BusyBoxia käytetään toteuttamaan suuri osa Linux-ytimen ulkopuolisesta käyttöjärjestelmästä.

20 20 Järjestelmästä tarkasteltiin ajossa olevia prosesseja. Havaittiin, että prosessien lukumäärä on noin 20. Määrä on Linuxiin perustuvalle järjestelmälle pieni. Suurin osa prosesseista, esimeriksi tutkimisen mahdollistava telnetd -prosessi ja WLAN-verkon osoitteita jakava udhcpd-palvelin, ovat BusyBoxin osia. Järjestelmän vapaan muistin määrä selvitettiin free-komennolla, jonka tuloste on listauksessa 1. Listauksen perusteella muistista on vakio-ohjelmistolla käytettynä noin kolme neljäsosaa. Käyttämätöntä muistia on KiB, eli noin kaksikymmentä megatavua. Ohjelmiston lisäämisen kannalta selvästi tarpeellista on, että lisättävät ohjelmistot eivät käytä kymmeniä megatavuja muistia. Jonkin verran muistia olisi tarpeen jättää myös käyttämättä. total used free shared buffers Mem: Swap: Total: Listaus 1. Keskusmuistin käyttö AR.Drone 2.0:n vakio-ohjelmistossa. Keskusmuistin lisäksi myös tallennustilaa laitteessa on rajallisesti. Listauksessa 2 olevan df-komennon tulosteen perusteella käyttämätöntä levytilaa on ohjelmisto-osiolla noin 12 megatavua ja erillisellä dataosiolla noin 50 megatavua. Tilan arvioidaan olevan enemmänkin kuin riittävä pienelle määrälle ylimääräisiä laskentarutiineja. Filesystem Size Used Available Use% Mounted on ubi1:system 26.3M 12.8M 12.2M 51% / tmp 57.7M 632.0K 57.1M 1% /tmp dev 57.7M M 0% /dev ubi0:factory 4.8M 80.0K 4.5M 2% /factory ubi2:update 13.2M 28.0K 12.5M 0% /update ubi2: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 huomattavasti perusteellisempaa tutkimista, kuin mitä tässä on tehty. Tässä esitetty katsaus kuitenkin vä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 yleinen ja laajasti tunnettu Yhteensopivuus Kuvankäsittelyalgoritmit itsessään eivät edellytä minkäänlaista vuorovaikuttamista ulkomaailman 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 tarvitsee liitännän laskennan parametrien siirtämiseen ohjelmistoon sisään ja ulos, mutta se on syytä tehdä mahdollisimman geneerisiksi ja laitteisto- ja käyttöjärjestelmäriippumattomaksi. 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 21 Vaikka ohjelmiston toisaalta haluttaan toimivan riittävän nopeasti juuri tietyntyyppisellä ARM-suorittimella, haluttiin sen olevan helposti hyödynnettävissä myös muunlaisella laitteistolla. Markkinoilla olevien robottihelikoptereiden tarjoamat suorittimet voivat ajan kuluessa vaihtua, ja kameran kalibrointia voi muutenkin hyödyntää robottihelikopterisovellusten ulkopuolella. helpottavan ohjelman hyödyntämistä muissa kuin tämän työn esittämässä Lisäksi mahdollisuus suorittaa ohjelmaa tai sen osia tavanomaisella PC-työasemalla helpottaa koko kehitysprosessia. Osassa suorittimia, erityisesti sulautettuihin järjestelmiin tarkoitetuissa, ei ole liukulukulaskentayksikköä. Liukulukujen laskentaoperaatioiden käyttäminen tällaisella suorittimella voi olla hidasta. Esimerkiksi Iordachen ja Tang:n [20] mukaan tehokas ohjelmistopohjainen liukulukujen toteutus ARMv5 -käskykannan toteuttavalle Intel XScale-suorittimelle käyttää yli 30 kellosykliä liukulukujen yhteenlaskuun. Työssä kehitettävän ohjelmiston halutaan toimivan, mikäli vähintään normaalin tarkkuuden liukulukuoperaatiot ovat kohdealustalla käytettävissä. Vaikka työssä on tarkoitus toteuttaa siirrettävä ohjelmisto, voidaan hyväksyä se että se toimii hitaammin laitteistolla joka soveltuu huonosti liukulukujen laskemiseen Välimuisti Nykyaikaisen tietokoneen keskusmuisti on lähes aina hidasta verrattuna suorittimen omaan laskentakapasiteettiin. Tämän takia muistia lukeva tai kirjoittava operaatio voi kestää satoja suorittimen kellosyklejä. Käytännön sovellukset vaativat yleensä suhteellisen suurikapasiteettista muistia, mutta sekä nopeudeltaan että kapasiteetiltaan suuret muistit ovat epäkäytännöllisen kalliita. Tyypillisesti tietokoneet piilottavat suurikapasiteettisen keskusmuistin pitkän vasteajan käyttämällä pienikapasiteettista, nopeaa muistia välimuistina. Välimuisti on yleensä toteutettu niin, että sen toiminta on ohjelmoijalle läpinäkyvää. Järjestys, jossa ohjelma käsittelee muistissa olevaa tietoa, voi kuitenkin vaikuttaa ohjelmiston suorituksen vaatimaan aikaan jopa useita suuruusluokkia. [21] Tyypillisesti välimuistin kannalta muisti on jaettu välimuistiriveihin (eng. cache line), jotka tavallisimmin ovat 64 tavun kokoisia. Osasta keskusmuistin sisällöstä pidetään kopioituna välimuistiin. Kun suoritin pyytää muistista tietoa josta on kopio välimuistissa, tilannetta kutsutaan välimuistiosumaksi (eng. cache hit). Välimuistiosuman tapauksessa tietoa muistista lataava käsky saadaan suoritettua nopeasti, koska hidasta keskusmuistia ei jouduta odottamaan. Kun muistista tarvitaan sellaista dataa joka ei satu olemaan välimuistissa, joudutaan välimuistihuti (eng. cache miss) käsittelemään lataamalla haettu tieto keskumuistista. [21] DRAM-muistin liitäntä tyypillisesti vaatii useita muistin kellosyklejä, että muistiväylää pitkin lähetetty komentosekvenssi tuottaa muistin sisältöä väylälle. Sekvenssiä hieman pidentämällä voidaan kuitenkin ladata kerralla useita tavuja. Välimuistihuti kä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 ja peräkkäisten muistinkäsittelyoperaatioiden välillä. Suuremmilla tietomäärillä erot ovat kuitenkin hyvin merkittäviä. Drepper:n käyttämässä esimerkkitapauksessa yksinker-

22

23 23 käsittelyjärjestyksen voi valita vapaasti, kannattaa se valita siten että kaikki samaan välimuistiriviin sisältyvät pikselit käsitellään peräkkäin. Tällöin yhteen välimuistiriviin sisältyvän pikseliryhmän käsittelyssä muut kuin ensimmäinen käsiteltävä pikseli ovat todennäköisesti valmiiksi L1d-välimuistissa kun niitä tarvitaan. Cortex-A8-suorittimessa ohjelmoija voi tehostaa välimuistimekanismin toimintaa käyttämällä ARMv7-käskykannan PLD-käskyä. PLD-käskyllä suorittimelle kerrotaan, että jostain muistiosoitteesta tullaan lataamaan hetken kuluttua. Dokumentaation mukaan Cortex-A8 reagoi PLD-käskyyn lataamalla käskyn parametrina annetun muistiosoitteen L2-välimuistiin mikäli se ei jo valmiiksi ole L1d-välimuistissa tai L2-välimuistissa. [22] PLD-käskyllä voi vähentää L2-hudista aiheutuvaa viivettä, koska välimuistirivien lataaminen välimuistiin saadaan sen avulla aloitettua jonkin verran ennen kuin se tehtäisiin ilman PLD-käskyä. PLD-käskystä saatava hyöty on kuitenkin hyvin suoritinriippuvainen, koska ARMv7-arkkitehtuuridokumentaation mukaan suorittimen toteuttajalla on hyvin vapaat kädet sen suhteen, miten käskyyn reagoidaan. Eräs sallittu ratkaisu on esimerkiksi jättää käsky kokonaan huomiotta. [23] Drepper [21] varoittaa ennakkolataamisen olevan haasteellista. Eräs mainittu ongelma on, että liiallinen ennakkolataaminen voi korvata välimuistista hyödyllisiä välimuistirivejä vähemmän hyödyllisillä. Kuvankäsittelyrutiineissa esimerkiksi kuvadatan liiallinen ennakkolataaminen voisi huonontaa suorituskykyä, mikäli ennakkolataaminen todennäköisesti aiheuttaisi kameran kalibrointiparametrit sisältävän välimuistirivin ennenaikaisen poistumisen välimuistista. Lisäksi sopivan latausennakon valitsemiseen 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 ennen kuin se hyödynnetään. Mikäli ennakkolataamista hyödynnetään vain huolella valituissa osissa ohjelmistoa, voi niiden hyödyllisyyden varmistaa mittaamalla niistä saatavan nopeusedun Ohjelmointikielet Linux-käyttöjärjestelmäytimen päällä on mahdollista suorittaa ohjelmia, jotka voivat olla toteutettu millä tahansa suuresta joukosta ohjelmointikieliä. Esimerkiksi C, C++, Java ja Python olisivat tarvittaessa käytettävissä. Työssä toteutettava ohjelmisto on kuitenkin erityisen mielekäs toteuttaa matalan tason kielillä, koska toteutettaviin algoritmeihin ei liity lainkaan esimerkiksi tietoverkkojen käyttöä tai tekstimuotoisen datan käsittelyä. Toisaalta algoritmit toteutetaan juuri numeerisen laskennan kautta, jolloin on edullista suorittaa ohjelmakoodia suoraan prosessorilla eikä esimerkiksi javan virtuaalikoneen tulkkaamana. Lisäksi AR.Drone 2.0:n tapauksessa käytettävän laitteiston tallennuskapasiteetti kokonaisuudessaan on 128 MiB, joten korkean tason toteutusalustan vaatimat ajonaikaiset kirjastot (eng. runtime) voivat kokonsa puolesta olla ongelmallisia. Yleinen piirre korkean tason kielissä on myös se, että ohjelmoija ei välttämättä voi helposti vaikuttaa siihen, miten käsiteltävä muisti jaetaan eri osiin muistia. Luvussa 3.3 mainitut välimuistien erityispiirteet on siksi helpompi huomioida ohjelmoitaessa matalan tason kielillä.

24 24 Sulautetuissa järjestelmissä yleisiä matalan tason ohjelmointikieliä ovat C ja C++ ja suoritinarkkitehtuurikohtaiset assembly-kielet. Näistä jälkimmäisten käyttäminen on ristiriidassa sen kanssa, että toteutettava ohjelma on yhteensopiva erilaisten suorittimien kanssa. C ja C++ kuitenkin ovat molemmat mahdollisia ratkaisuja. Sekä C:n että C++:n määritelmissä osa kielen semantiikasta on jätetty kieltä toteuttavan tahon määriteltäväksi. Esimerkiksi int-muuttujatyypin tallentamiseen jokin toteutus voi käyttää kaksi tavua, jolloin sen arvoalue olisi kokonaisluvut alkaen luvusta ja päättyen lukuun Jossain toisessa toteutuksessa int-tyypin koko voi olla neljä tavua, missä tapauksessa int-tyyppisen muuttujan arvo voisi olla vähintään ja korkeintaan Muun muassa tästä, mutta myös muista eroista johtuen sama ohjelma voi käyttäytyä eri kielen toteutuksilla eri tavalla. Esimerkiksi listauksen 3 funktio parametrilla 200 palauttaa tuloksenaan luvun , mikäli int-tyypin koko on 2 tavua. Jos taas int-tyypin koko on 4 tavua, saadaan tuloksena int foo(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äytymisessä voi havaita. Esimerkiksi GNU GCC kääntäjän long-tyyppi on 4 tavun kokoinen ARMv7-suoritimelle ohjelmia kääntävässä kokoonpanossa, mutta 8 tavun kokoinen käännettäessä X86-64:lle. Tämän vuoksi listauksen 4 ohjelma tulostaa eri tekstin 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 siitä, mitä ohjelmointikielen toteutusta käytetään. Yksikään edellä mahdollisiksi ohjelmiston toteutuskieliksi esitetyistä ohjelmointikielistä ei ole määritelty siten, että kaikki määritelmän mukaiset ohjelmat tuottaisivat kaikissa tapauksissa samat tulokset. Tämän vuoksi ohjelmistoa kehitettäessä kiinnitetään erityistä huomiota siihen, että valitun kielen toteutusten erot eivät vaikuta ohjelmiston käyttäytymiseen.

25 Pohdinta AR.Drone 2.0:n tarjoamat laskennalliset resurssit ovat sulautetuksi järjestelmäksi suhteellisen suuret. Kokonaisia kuvia käsittelevät toimenpiteet, kuten kuvan korjaus perspektiivimallin mukaiseksi, ovat kuitenkin käytettävissä oleviin resursseihin nähden raskaita. AR.Drone 2.0:n etukameran tuottamat x720 -kokoista kuvaa sekunnissa tarkoittavat, että 1 GHz suorittimella on noin 36 kellosykliä aikaa yhden kuvapisteen käsittelyyn. Yksittäinen muistia lukeva käsky voi huonossa tapauksessa vaatia jopa satoja kellosyklejä suoritinaikaa. Jos muistin lukemisesta aiheutuu näin suuri viive jokaisen korjattavan kuvan kuvapisteen kohdalla, on selvää, että kaikkia 30 kuvaa sekunnissa ei ehditä korjata. Luvussa 3.3 esitettyihin ilmiöihin huomiota kiinnittämällä huolehditaan siitä, että suorittimen välimuistijärjestelmä saa lyhennettyä muistin käytöstä aiheutuvaa viivettä. Kohdejärjestelmän tarkastelusta päätellään, että kovin suurta ohjelmistoa AR.Drone 2.0:ssa ei voi suorittaa. Levytilan määrä on rajallinen, mutta erityisesti keskusmuistia ei 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 toteutuksessa on tarve voida hallita muistin käyttöä sekä määrällisesti että asettelun ja tietorakenteiden osalta, matalan tason ohjelmointikielten käyttö toteutukseen on luontevaa. Uudelleenkäytettävyyden maksimoimiseksi kannattaa kuitenkin mahdollisimman suuri osa ohjelmistosta toteuttaa alustariippumattomaksi.

26 26 4. KEHITETTY OHJELMISTO Opinnäytetyön ohjelmisto-osuus toteuttaa luvussa 2.5 esitellyn Kannala-Brandt -kameramallin mukaisia menetelmiä. Toteutetun ohjelmiston avulla voi sulautetussa järjestelmässä hyödyntää Kannalan kirjoittaman kalibrointiohjelmiston [17] suorittamaa kameran kalibrointia. Ohjelmisto on vapaasti hyödynnettävissä ja ladattavissa osoitteesta Työssä toteutettu ohjelmisto koostuu noin 8000 rivistä C++-lähdekoodia. Ohjelmisto on yhteensopiva ainakin GNU GCC 4.8 -kääntäjän ja LLVM Clang 3.3 -kääntäjän kanssa. Ohjelmiston keskeisimmät osat ovat yhteensopivia myös Microsoft Visual Studio Express 2013 for Windows -kääntäjän kanssa. Perinteisemmän C-kielen sijaan C++-kieltä käytetään sen tarjoamien lisäominaisuuksien takia. Toteutettu ohjelmisto koostuu joukosta moduuleja, joiden piirteitä esitellään jäljempänä. Ohjelmiston keskeisin osa on kuvaprosessointirutiinit toteuttavasta lähdekoodista koostuva Twirl-kirjastomoduuli. Kirjasto toteuttaa joukon puhtaita laskentaoperaatioita ja tarjoaa helppokäyttöisen ohjelmointirajapinnan niiden käyttöön. Muita toteutetun ohjelmiston moduuleita ovat uudelleenkäytettäviä apurutiineita sisältävä Twirr-kirjasto, suorituskyvun mittauksessa käytettävä benchmarks-työkalukokoelma, kalibrointiobjektin kontrollipisteitä havaitseva ctrlpoint_extractor -työkalu, twirl-cmd -komentorivityökalu, graafinen twirl_viewer -työkalu ja joukko automaattisia testejä Twirl-kirjasto Twirl-projektin twirl -kirjasto sisältää kameraa mallintavia laskurutiineja. Rutiinien toteutuksessa 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 dynaamisesti ohjelman ajon aikana, on sen varaaminen jätetty täysin kirjastoa käyttävän ohjelman vastuulle. Kirjasto itse käyttää vain paikallisia muuttujia ja kutsuvasta ohjelmasta välitettyä muistia tietojen tallentamiseen ja käsittelyyn. Dynaamisen muistinvarauksen välttämisellä voidaan jonkin verran parantaa ohjelman siirrettävyyttä. Esimerkiksi AVR-mikrokontrollereilla malloc -funktion käyttö on usein vaativaa [24]. Muistin varaamisen lisäksi Twirl-kirjastossa vältetään myös kaikenlaisia muita sivuvaikutuksia, kuten tiedostojen tai globaalien muuttujien kirjoittamista. Kaikki kirjastossa käsiteltävä tieto on siis joko sen paikallisissa muuttujissa tai kirjastoa kutsuvan ohjelman varaamassa muistissa. Siten esimerkiksi monisäikeinen ohjelmisto voi kutsua kirjaston funktiota ongelmitta monesta säikeestä, kunhan se varmistaa että muut säikeet eivät kirjoita samoihin osoitin- tai viittausparametreina välitettyihin muistin osiin.

27 27 namespace twirl { struct polynomy { /*... */ real_t derivative(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äyttämään vain sellaisia, joista ei aiheudu merkittävää eroa suorituskyvyssä tai siirrettävyydessä verrattuna C-kieliseen vastaavaan ohjelmaan. Näiltä osin täysin ongelmattomia piirteitä ovat esimerkiksi nimiavaruudet, viittaukset ja muuttujien tyypin automaattinen valinta (ns. auto -tyypiset muuttujat). Edellä mainittujen funktioiden toteutuksessa C++:n template-toimintoja käytetään huolimatta siitä, että niiden varomaton käyttö saattaa paisuttaa käännetyn ohjelman kokoa. Kääntäjän generoiman konekielisen koodin kokoa seuraamalla voi kuitenkin havaita 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 muun muassa poikkeukset, virtuaaliset luokkien jäsenfunktiot ja dynaaminen muistin varaaminen. Näistä rajoituksista johtuen myöskin C++:n standardikirjaston käyttö rajattiin twirl-kirjaston ulkopuolelle. Kirjasto toteutettiin siten, että sen käyttämän liukulukutietotyypin voi valita käännön asetustentekovaiheessa. Käytännössä tätä mahdollisuutta ei juuri hyödynnetty ja kaikissa tämän työn osissa voi olettaa että twirl::real_t on oikeasti float. Ohjelmistossa käytetyn twirl::real_t -tyypin voi kuitenkin tarvittaessa vaihtaa helposti tarkoittamaan C++:n double-tyyppiä Polynomit Kannala-Brandt -kameramallin määritelmässä esiintyy polynomifunktioita ja niiden derivaattoja ja käänteisfunktioita. Niiden laskemiseen toteutettiin polynomy-niminen moduuli, joka tarjoaa funktiot edellä mainittuihin toimintoihin. Moduulin toteutuksessa tärkeimpiä osia on twirl::polynomy::derivative -funktio, joka laskeen N:n asteen polynomifunktion M:nnen derivaatan kohdassa x, missä N voi olla 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 tarpeettoman joustava. Joustavuudesta funktion konekieliseen vastineeseen seuraa ehdollisia 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 ei ennakoi ehdollisen hyppykäskyn jälkeistä ohjelmalaskurin arvoa oikein [22].

28 28 namespace twirl { /*... */ real_t polynomy::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 aste ja nollasta poikkeavien kertoimien sijannit ovat kiinnitettyjä. Tämän vuoksi usein toistuville erikoistapauksille polynomy-moduulissa on omat funktionsa, joissa rajapinta ei ole derivative-funktion tavoin joustava. Esimerkiksi listauksen 6 value_135-funktion, laskee arvon polynomille jossa vain ensimmäisen, kolmannen ja viidennen asteen kertoimet ovat nollasta poikkeavia. Toteutus value_135 -funktiolle kirjoitettiin siten, että se luo vaaditut ylimääräiset parametrit paikallisiksi muuttujiksi ja kutsuu yleiskäyttöistä derivative-funktiota. Suoraan käännettynä tällaisen funktion toteutus olisi korkeintaan yhtä nopea kuin sen kutsuma derivative-funktio. Käytännössä kääntäjän on mahdollista tuottaa huomattavasti derivative-funktiota nopeampi konekielinen vastine value_135-funktiolle. Nopeaan toteutukseen käännetään mukaan inline-kopio sellaisesta derivative-funktiosta, jossa value_135:ssa vakioksi asetetut parametrit ovat vakioita. Esimerkiksi työssä käytetty GCC 4.8 -kääntäjä tuottaa value_135:sta listauksen 7 mukaisen konekielisen vastineen. Koska kääntäjä havaitsee, että derivative-funktion silmukan kierrosmäärä on annetuilla parametreilla 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 rekistereihin. Konekielisen ohjelman ei tarvitse esimerkiksi luoda muistiin kuuden alkion real_t -taulukkoa tai silmukkarakenteita, vaikka lähdekoodia seuraamalla sellaiset voi havaita. Laskenta pystytään siis määrittelemään yhden kerran joustavarajapintaisella, hitaalla funktiolla, josta kääntäjä optimoi nopeammin toimivan erikoistapauksen. Testatuista kääntäjistä sekä Clang että GCC tuottivat myös x alustalla value_135-funktiosta vastaavanrakenteisen konekielisen funktion.

29 c <twirl::polynomy::value_135(float const*, float) const>: 44c: ed9f7a1d vldr s14, [pc, #116] ; 4c8 450: eef07a47 vmov.f32 s15, s14 454: 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, s14 470: ed905a04 vldr s10, [r0, #16] 474: edd16a02 vldr s13, [r1, #8] 478: ed906a05 vldr s12, [r0, #20] 47c: e24dd018 sub sp, sp, #24 480: ee223a83 vmul.f32 s6, s5, s6 484: ee407a03 vmla.f32 s15, s0, s6 488: ee633a87 vmul.f32 s7, s7, s14 48c: eef05a47 vmov.f32 s11, s14 490: ee207a00 vmul.f32 s14, s0, s0 494: ee477a23 vmla.f32 s15, s14, s7 498: ee644a24 vmul.f32 s9, s8, s9 49c: ee207a07 vmul.f32 s14, s0, s14 4a0: ee477a24 vmla.f32 s15, s14, s9 4a4: ee655a25 vmul.f32 s11, s10, s11 4a8: ee207a07 vmul.f32 s14, s0, s14 4ac: ee477a25 vmla.f32 s15, s14, s11 4b0: ee200a07 vmul.f32 s0, s0, s14 4b4: ee267a26 vmul.f32 s14, s12, s13 4b8: ee477a00 vmla.f32 s15, s14, s0 4bc: eeb00a67 vmov.f32 s0, s15 4c0: e28dd018 add sp, sp, #24 4c4: e12fff1e bx lr 4c8: word 0x Listaus 7. twirl::polynomy::value_135 -funktion ARM-käännös Matriisit Pienten matriisien perusoperaatioiden laskemiseen kirjoitettiin C++-malli (eng. template), jonka toteutuksen oleellisimpia piirteitä on poimittu listaukseen 8. Malli kokonaisuudessaan on saatavilla toteutetun ohjelmiston tiedostosta include/twirl/matrix.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 tietorakenteiden kirjoittaminen. Tässä tapauksessa mallissa ei ollut tarvetta hyödyntää useita 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 matriiseja eri tyyppeinä. Matriisityypeille tämä sopii erityisen hyvin, koska matriisien kertolaskuoperaatiot on perinteisesti määritelty vain yhteensopivan kokoisille matriiseille. Kuten listauksen 8 viimeisistä riveistä havaitaan, ovat mallin luomat tyypit rakenteeltaan C-tyylisiä 2-ulotteisia taulukoita (eng. array), jotka on pakattu struct:n sisään. Tämä sopii hyvin tavoitteeseen välttää dynaaminen muistin varaaminen. Toisaalta valittu toteutus voi käyttää suhteellisen paljon muistia paikallisille muuttujille, mikä joissain järjestelmissä voisi olla ongelma. Esimerkiksi neljän rivin neliömatriisissa olisi 16 4 tavun kokoista alkiota, jolloin koko muuttujan koko olisi 64 tavua. AR.Drone

30 30 template <int H, int W> struct matrix { /* constructors... */ template<int W2> matrix<h,w2> operator*(const matrix<h,w2> &o) const { /*... */ } matrix operator*(real_t const v) const { /*... */ } matrix operator+(const matrix &o) const { /*... */ } static matrix identity() { /*... */ } static matrix ones() { /*... */ } 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 funktiokutsupinon kokoa ei yleensä ole rajattu erityisen pieneksi. Matriisirakenteita voisi käyttää ohjelmakoodissa esimerkiksi listauksen 9 mukaisesti. Listauksen f-funktiossa luodaan aluksi kahden rivin ja kolmen sarakkeen kokoinen matriisi, jonka arvot alustetaan paikallisista muuttujista. Toinen, kolmirivinen ja kaksisarakkeinen matriisi luodaan 1-alkioita sisältävän matriisin alustavalla funktiolla. Matriisien kertolasku tuottaa kaksirivisen neliömatriisin joka annetaan g-funktiolle parametrina. Matriisien toteutustapa on varsin käytännöllinen käyttää. Toisaalta se voi kuitenkin johtaa 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 31 laskettavien matriisien alkioista tunnetaan nolliksi, voisi mahdollisesti ainakin suorituskykykriittisissä osissa ohjelmaa sieventää kertolaskuoperaatiot paperilla ja kirjoittaa vain sievennetyt lausekkeet ilman tähän työhön toteutettua matriisimoduulia. Luvussa esitettyjen matriisilausekkeiden kirjoittamisessa ratkaisu kuitenkin koettiin hyväksi Kannala-Brandt -mallin toteutus Totetettuun ohjelmistoon kirjoitettiin twirl::kannala -niminen moduuuli joka toteuttaa luvussa 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ää tulokulman joka vastaa jotain tunnettua pikselin sijaintia. Moduulin laskenta toteutettiin suoraan luvun 2.5 lausekkeista. Osalle lausekkeista derivoitiin paperilla vastaavat derivaattalausekkeet, mutta polynomilausekkeiden tapauksessa voitiin hyödyntää polynomy-moduulin sisäänrakennettua derivaattatoiminnallisuutta. Mallin toteutus vaatii monessa kohdassa sinin ja kosinin laskemista (θ, φ)-kulmaparin φ-kulmalle. Lisäksi osa funktioista tarvitsi arvot lausekkeille sin(2φ) ja cos(2φ). Tämän takia toteutettiin mallin rajapinta sellaiseksi, että twirl::kannala -moduulin funktioita kutsuva koodi laskee kyseiset arvot valmiiksi mikäli niitä tarvitaan. Arvojen laskeminen tapahtuu käytännössä muuntamalla twirl::ray_direction -muuttuja twirl::kannala::raydir_plus -tyyppiseksi, jolloin tyypin toteutus huolehtii arvojen täyttämisestä paikalleen. Listaukseen 10 on poimittu raydir_plus -tyypin oleellisimmat piirteet. Tyyppi on periytetty yksinkertaisesta ray_direction -tyypistä, koska sen haluttiin joka tapauksessa sisältävän alkuperäisen kulmatiedon. Myöskin on käytännöllistä että tyypin muuttujia voi suoraan käyttää tilanteissa, missä voi käyttää laajentamatonta ray_direction -muuttujaa. Muodostin raydir_plus -tyypille kuitenkin on sellainen, että korotus suurempaan tyyppiin pitää tehdä explisiittisesti. Tämä helpotti ohjelmiston kehitystä vaiheessa, jossa sini- ja kosinifunktioiden kutsujen määrää pyrittiin minimoimaan suoritinaikavaatimusten 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 Kuvan korjaus perspektiivimallin mukaiseksi Ohjelmiston reproject -komponentilla voi muuntaa kokonaisia Kannala-Brandt -mallin mukaisia kuvia perspektiivimallin mukaisiksi. Tätä varten toteutettuun ohjelmistiin sisältyy pinhole-nimoinen moduuli, jonka avulla voi laskea, mihin pikseliin jonkin perspektiivikameran 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-

32

33

34 34 void correct_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 kuin luvussa esitelty mekanismi. Hakutaulua ja listauksen 11 funktiota käyttämällä korjauksen pitäisi kuitenkin tapahtua huomattavan nopeasti, koska nyt korjausfunktio joutuu jokaiselle pikselille tekemään vain pienen joukon hyvin keveitä operaatioita. Aluksi haetaan hakutaulusta yksi 32 bitin kokonaisluku, joka kertoo vastinpikselin sijainnin. Sijaintimuuttujan arvoalueesta arvo 0xffffffff käytettiin merkitsemään korjatun kuvan sijainteja, joille korjattavassa kuvassa ei ole vastinpikseleitä. Listauksessa näkyvä is_invalid -funktiokutsu tekee siis vain yhtäsuuruusvertailun vakioarvoa vasten. Listauksen 11 TWIRL_USE_ARM_TWEAKS -esikääntäjämakrosta riippuen ehdollisesti käännetty lohko on suorituskykyoptimointi, joka ei vaikuta funktion antamiin tuloksiin. Optimointi hyödyntää luvussa 3.3 esiteltyä ARMv7-käskykannan PLDkä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 kohdan lisäksi myös seuraavia alkioita tullaan tarvitsemaan pian. Lohkossa käytetty pld_offset on ennakon suuruus, joka kertoo, kuinka monen taulukon alkion päästä esiladataan. Ennakon suuruuden valintaa ja sen vaikutuksia käsitellään jäljempänä luvussa Hakutaulukko-optimoitu korjausfunktio koostuu jokaiselle pikselille suoritettavasta silmukasta joka sisältää lähes pelkästään muistin lukemista ja kirjoittamista. Tämän vuoksi on luultavaa, että luvussa 3.3 esitetyllä välimuistin toiminnalla on merkittävä vaikutus funktion suorituskykyyn.

35 correct_with_lut: 414: e cmp r1, r2 418: e92d01f0 push {r4, r5, r6, r7, r8} 41c: e59d4014 ldr r4, [sp, #20] 420: 2a00001e bcs 4a0 <correct_with_lut+0x8c> 424: e add r5, r1, #1 428: e1a05105 lsl r5, r5, #2 42c: e245c004 sub ip, r5, #4 430: e add r0, r0, r5 434: e59d5018 ldr r5, [sp, #24] 438: e085c00c add ip, r5, ip 43c: e ldr r8, [r0, #-4] 440: e add r1, r1, #4 444: e ldr r7, [r0] 448: e28cc010 add ip, ip, #16 44c: e cmn r8, #1 450: e ldr r6, [r0, #4] 454: e ldr r5, [r0, #8] 458: e add r0, r0, #16 45c: ldrne r8, [r4, r8, lsl #2] 460: 01a08003 moveq r8, r3 464: e cmn r7, #1 468: ldrne r7, [r4, r7, lsl #2] 46c: 01a07003 moveq r7, r3 470: e cmn r6, #1 474: ldrne r6, [r4, r6, lsl #2] 478: 01a06003 moveq r6, r3 47c: e cmn r5, #1 480: ldrne r5, [r4, r5, lsl #2] 484: 01a05003 moveq r5, r3 488: e cmp r2, r1 48c: 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än perusteella oletetaan, että suurella todennäköisyydellä välimuistirivin alkuun sijoittuvan hakutaulukkoalkion jälkeen myös muut samalle välimuistiriville sijoittuvat alkiot luetaan, ennen kuin kyseinen välimuistirivi poistuu välimuistista jonkun muun tiedon tieltä. Korjattavan kuvan pikseleiden osalta tilanne on jännittävämpi. Esimerkiksi siirryttäessä korjatussa kuvassa yksi pikseli vasemmalta oikealle, siirtyy luultavasti myös korjattavan kuvan vastinkohta jonkin verran oikealle. Määrä kuitenkin voi olla enemmän tai vähemmän kuin yksi pikseli, ja osassa korjatun kuvan siirtymiä vastinkohta voi siirtyä myös pystysuunnassa. Luultavasti kuitenkin myös korjattavan kuvan sisältävän muistin osalta laskenta etenee ainakin osan ajasta siten, että ajallisesti lähekkäin ladataan pikseleitä jotka osuvat samalle välimuistiriville. Myös korjatun kuvan pikselit kirjoitetaan muistiosoitejärjestyksessä, minkä odotetaan olevan edullinen tilanne suorittimen muistinkirjoituspuskuroinnin kannalta. Hakutaulukkoa käyttämällä saatua suorituskykyä verrataan perustoteutukseen jäljempänä luvussa

36 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 muille ohjelmille. Twirr sisältää muun muassa komentorivin jäsentämiseen käytettäviä rutiineja ja esikääntäjämakroja, joita tarvitaan osassa aputyökalujen lähdekoodia kääntäjäyhteensopivuuden parantamiseksi. Twirr-kirjaston osien ei ole tarpeen olla yhtä joustavasti käytettävissä eri alustoilla kun laskenta-algoritmien ydinosien. Tämän vuoksi sen toteutuksessa hyödynnetään C++-standardikirjaston tarjoamaa toiminnallisuutta. Eräs Twirr-kirjaston osista suorittaa luvussa esiteltyjä kuvankorjausrutiineja niin, että kuorma jaetaan usealle säikeelle. Tämän ei odoteta tuovan suorituskykyhyötyä AR.Drone 2.0:n yksiytimisellä suorittimella. Joissain muissa sulautetuissa ARMsuorittimeen perustuvissa järjestelmissä suoritinytimiä kuitenkin on kaksi tai enemmän, eikä yksinkertaisen useaan säikeeseen jakamisen toteuttaminen vaadi suurta lisäystä toteutettuun ohjelmistoon. Monisäikeistä suoritetusta sovelletaan kuvan perspektiivimallin mukaiseksi korjaavan funktion perustoteutukseen, ja lisäksi hakutaulun luontiin ja hakutaulukkoa käyttävään kuvankorjaukseen. Kaikki näistä toiminnoista on toteutettu siten, että operaatio tuottaa vain osan tuloksena saatavasta kuvasta tai hakutaulukosta. Kaikki säikeisiin jako toteutetussa ohjelmistossa toimii siten, että kuva tai hakutaulukko jaetaan pystysuunnassa valitulle määrälle säikeitä. Esimerkiksi kolmelle säikeelle jaettaessa yksi säie saa laskettavakseen korjatun kuvan ylimmät rivit, toinen keskimmäiset ja kolmas alimmat rivit. Hakutaulukon tapauksessa jako on vastaava, kun tarkastellaan hakutaulukon alkioita vastaavia kuvapisteitä. Koska kuvan korjauksen aikana kameramallin kuvaavaa tietorakennetta, lähdekuvaa tai hakutaulukkoa ei tarvitse kirjoittaa, voivat kaikki luodut säikeet turvallisesti lukea samaa kopiota niistä. Myös korjatun kuvan kuvapisteiden kirjoittaminen voidaan tehdä siten, että kukin säie kirjoittaa omalla vastuullaan olevan korjatun kuvan pisteet tai hakutaulukon alkiot suoraan samaan tuloksena saatavaan kuvaan tai hakutaulukkoon. Säikeisiin jaon toteuttava rutiini suorittaa työn jakamisen ja työn osia vastaavien sä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 yksinkertaisesti 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 jonkinlainen työjono, minkä kautta laskenta kannattaisi järjestää suoritettavaksi. Mikäli valittu ratkaisu kuitenkin kykenee yksinkertaisessa käyttötilanteessa parantamaan laskennan suorituskykyä, on se riittävän hyvä osoittamaan että säikeistämällä hyötyä saavuttaa Käyttöliittymät ja testaus Twirl- ja Twirr -kirjastojen lisäksi toteutettuun ohjelmistoon sisältyy noin kaksikymmentä suoritettavaa ohjelmaa. Ohjelmat eivät ole välttämättömiä Twirl-kirjaston käyttämiseen, mutta niillä on suuri merkitys kokonaisuuden kehittämisen kannalta. Suu-

37 37 rin osa ohjelmista on yksinkertaisia testiohjelmia. Osa testiohjelmista laskee Twirlkirjaston rutiineilla tuloksia ja ilmoittaa, vastaavatko ne ennalta tunnettuja odotettuja tuloksia. Loput testiohjelmat ovat yksinkertaisia työkaluja, jotka tyypillisesti kutsuvat jotain tiettyä Twirl:n funktiota useita kertoja. Näiden työkalujen suoritusaikaa mittaamalla voi ainakin karkeasti arvioida, miten paljon suoritinaikaa kunkin ohjelman testaama funktio vaatii. Toteutettun ohjelmistoon sisältyy twirl-cmd -niminen komentorivityökalu, jonka avulla voi muun muassa tulostaa kalibrointiparametritiedoston sisältämät arvot ja korjata kuvia perspektiivimallin mukaiseksi. Työkalu on käyttökelpoinen sekä Twirlkirjaston käyttöesimerkkinä ohjelmoijalle että työkaluna ohjelmiston toiminnallisuuden testaamiseen. Kuvien korjaamisen twirl-cmd pystyy tekemään vain PNG -muotoisille kuville, joiden lukemiseen ja kirjoittamiseen se käyttää libpng-kirjastoa. Ohjelman voi tarvittaessa kääntää myös käyttämättä libpng -kirjastoa, mikäli kuvien korjaustoiminnallisuutta ei tarvita. Kuva 9. Kuvankaappaus twirl_viewer -työkalusta. Komentorivikäyttöliittymän lisäksi toteutettu ohjelmisto sisältää kuvassa 9 esitetyn, twirl_viewer -nimisen graafisen työkalun. Työkaluun voi ladata Kannala-Brandt - kameramallin parametrit ja kuvia tiedostoista. Ohjelmaan ladatut kuvat korjataan twirlkirjaston korjaustoiminnolla perspektiivimallin mukaisiksi ja näytetään käyttäjälle korjattuna. 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 muuttaa ohjelman vasemman laidan lomakkeen kautta. Twirl-viewer toteutettiin Qt-sovelluskehyksen avulla. Toisin kuin aiempana mainittu twirl-cmd, twirl_viewer käyttää twirl-kirjaston reproject-moduulin funktioita Qt:n QImage-luokan ohessa. Koska QImage-luokka tarjoaa kattavan tuen erilaisten kuvatiedostoformaattien lukemiseen ja kirjoittamiseen, kykenee twirl_viewer avaamaan PNG-muotoisten kuvien lisäksi myös esimerkiksi JPEG-kuvia. Tarkka tuettujen kuvatiedostoformaattien joukko riippuu siitä, minkä Qt-version kanssa ohjelmistoa suoritetaan. 38

39 39 5. TULOKSET Tässä osassa työtä kuvataan työssä toteutetun ohjelmiston testiympäristö, testaamiseen käytetyt menetelmät. Lisäksi ohjelmiston suorituskykyä mitataan eri alustoilla ja esitetään, miten erilaiset suorituskyvyn parantamiseen tähtäävät ratkaisut onnistuivat Testiympäristöt Työssä kehitetyn ohjelmiston suorituskykyä havainnoitiin yhteensä neljässä eri järjestelmässä, jotka on lueteltu taulukossa 1. Järjestelmistä IGEPv2 ja Jolla perustuvat ARM -arkkitehtuuria edustaviin suorittimiin. PC-1 ja PC-2 ovat tavanomaisia PCtyöasemia. Testilaittestojen esittelyssä keskitytään ensisijaisesti suorittimen ominaisuuksiin. Suorituskykyä mittaavat ohjelmat kirjoitettiin siten, että niiden ei tarvitse esimerkiksi lukea tai kirjoittaa tietoja massamuisteihin. Tämän vuoksi jätetään huomiotta esimerkiksi se, että joissain testijärjestelmissä ainoana tallennustilana toimiva SD-kortti on perinteiseen kiintolevyyn verrattuna erittän hidas. Lisäksi oletetaan, että testijärjestelmässä käytetty käyttöjärjestelmä ei suuresti vaikuta mittaustulokseen. Kaikki mittaukset tehtiin jonkin Linuxiin perustuvan käyttöjärjestelmän alaisena, mutta laitteistojen erilaisuudesta johtuen täysin identtisen ohjelmistokokoonpanon käyttäminen olisi ollut mahdotonta. Taulukko 1. Kehitetyn ohjelmiston suorituskyvyn mittauksessa käytetyt järjestelmät Nimi Suoritin Käyttöjärjestelmä IGEPv2 Cortex-A8, 720 Mhz Fedora 20 Jolla Krait 300, 2 x 1,4 GHz Sailfish OS PC-1 Pentium 4, 2.8 GHz Exherbo PC-2 AMD A8-3850, 4 x 2,9 GHz Fedora 20 Testijärjestelmistä eniten AR.Drone 2.0:n tarjoamaa ympäristöä muistuttaa kuvassa 10 havainnollistettu IGEPv2. Kuten AR.Drone 2.0:n OMAP3630 -piiri, myös IGEPv2:n OMAP3530 -piiri sisältää Cortex-A8 -suorittimen. Järjestelmät ovat siis huomattavan samankaltaiset, on niiden eroavaisuuksia lueteltu taulukossa 2. IGEPv2:n käyttöjärjestelmänä käytettiin Fedora 20:n ARMv7-suorittimille käännettyä versiota. Käyttöjärjestelmän mukana tulevaa GCC kääntäjää käytettiin kaikkien suotituskykytestissä käytettyjen ARM-binäärien kääntämiseen. Toisena ARM-arkkitehtuuria edustavana testijärjestelmänä käytettiin Jolla Oy:n Jollamatkapuhelinta. Laitteen Sailfish OS -käyttöjärjestelmä sisältää GNU/Linux -ympäris- Taulukko 2. AR.Drone 2.0:n ja IGEPv2:n eroavaisuuksia Järjestelmä AR.Drone 2.0 IGEPv2 SoC OMAP3630 OMAP3530 Kellotaajuus 1000 MHz 720 MHz L1-välimuisti 32 KiB 16 KiB Keskusmuisti 128 MiB 512 MiB

40 40 Kuva 10. IGEPv2. tön, jossa Fedora 20:n ARM-version GCC:lla käännettyjä C++-ohjelmia voi suorittaa ilman muutoksia. Jollan Qualcomm Snapdragon 400 -piiri on laskentakapasiteetiltaan huomattavasti suurempi kuin IGEPv2:ssa käytetty OMAP3530. Lisäksi mielenkiintoisena 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 HyperThreading -toiminnon takia se voi suorittaa kahta säiettä osittain rinnakkain. PC-1:n testit käännettiin Exherbon paketoimalla GCC:n versiolla. Käytetyistä testikokoonpanoista suurin laskentakapasiteetti on PC-2:ssa. Sen suoritin edustaa vuoden 2012 tyypillistä pöytätietokoneratkaisua. Suorittimessa on 4 ydintä ja se tukee 64-bittistä X käskykantaa. Suorituskyvyn arviointia varten työssä kehitetyn ohjelmiston kääntäjäastukset valittiin suorittamalla Cmake-työkalu listauksessa 13 kuvatuilla parametreilla. Cmake käyttää annettuja parametreja ja totetutetun ohjelmiston CMakeLists.txt -tiedostoja GCCkääntäjän parametrien valintaan. Listaukseen 14 on kopioitu yhden projektiin kuuluvan tiedoston käännössä käytetyt, Cmaken valitsemat valitsimet. Käytännössä tässä käytetyillä, laitteistoriippumattomilla asetuksilla ohjelmiston laitteistolle sovittaminen jää kääntäjän vastuulle. Tässä työssä esiteltyä suorituskykyä saattaa siis olla mahdollinen parantaa ainoastaan kääntäjän asetuksia muuttamalla. Ellei toisin mainita, luvussa mainittua PLD-optimointia ei hyödynnetä suorituskykymittauksissa. Kyseisellä suoritinkohtaisella optimointimenettelyllä saavutettua nopeusetua käsitellään erikseen luvussa

41 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 mallin parametrit siten että ne vastaavat mallinnettavan kameran tuottamia kuvia. Matlab-työkalua hyödynnettiin yhdessä Seppälän [25] kuvaaman kalibrointikuvasarjan avulla. Kuvasarja koostuu 20 kuvan 11 kaltaisesta kuvasta, jotka on otettu AR.Drone 2.0:n kameralla. Kussakin sarjan kuvassa on kuvattu samaa mustavalkoruutuista kalibrointiobjektia 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ät ole kuvautuneet suoriksi. Esimerkiksi kuvan oikeassa laidassa olevan hyllyn reuna on selvä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 perspektiivimallia kovin hyvin, vaikka kuvasta voikin vielä helposti hahmottaa, minkälaisia esineitä kameralla on kuvattu.

42

43 43 Toteutetun ohjelmiston twirl-cmd -työkalulla korjattiin kameramallin kalibrointiin käytettyjä kuvia. Kuvassa 13 on esitetty kuva 11 korjattuna perspektiivimallin mukaiseksi. Toisin kuin kuvassa 11, kuvan 13 sisältämät suorat piirteet ovat myös kuvautuneet silmämääräisesti arvioiden suoriksi. Kuva 13. Perspektiivimallin mukaiseksi korjattu esimerkkikuva Tarkkuus Suurin osa työssä toteutetun ohjelmiston laskennasta perustuu suoraan Kannalan ja Brandt: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 kahdesta approksimaatiosta, jotka molemmat liittyvät Kannala-Brandt -kameramallin käänteisprojektiofunktion toteutukseen. Mallin symmetrisessä osassa käytetään Newtonin menetelmää kasvavan polynomifunktion nollakohdan hakemiseen. Menetelmä mahdollistaa nollakohdan tarkkuuden valinnan hyvinkin tarkaksi, mutta laskenta-ajan säästämiseksi iteroinnin lopetusehto lopettaa tarkentamisen, kun löydetään kohta, jossa polynomin arvo poikkeaa nollasta vähemmän kuin rad. Nollakohdan haussa tehtyä kompromissia suuremman virheen aiheuttaa luultavasti Kannalan esittämä approksimaatio epäsymmetrisen vääristymän käänteisfunktiolle. Kannala-Brandt -mallin mukaiseen projisointiin ei liity vaiheita, joissa poikettaisiin Kannalan ja Brandt:n esittämistä lausekkeista muuten kuin liukulukuoperaatioissa tapahtuvien pyöristyksen osalta. Mallin käänteisprojisoinnin tarkkuutta arvioidaan tässä verrattuna eteenpäin projisoinnin tuloksiin. Luvussa 5.2 esitellyllä esimerkkikalibroinnilla laskettiin käänteisprojektio jokaiselle 1280x720-kokoisen kuvan pikselille, mistä tuloksena saatu valonsäteen suunta taas projisoitiin. Mikäli käänteismalli olisi ideaalisen tarkka, päästäisiin näin tekemällä samoihin pikseleiden sijainteihin.