eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Diplomová práce
Roz²í°ená realita pro mobilní multimediální prezentace
Bc. Jakub Král
Vedoucí práce:
Ing. Adam Sporka Ph.D.
Studijní program: Otev°ená informatika, Magisterský
Obor: Softwarové inºenýrství a interakce
2. ledna 2014
iv
v
Pod¥kování D¥kuji rodin¥ a svým p°átel·m za pomoc a podporu.
vi
vii
Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).
V Praze dne 2. 1. 2014
.............................................................
viii
Abstract This thesis analyzes current usage of augmented reality in combination with smart mobile devices, describes the three main types of mobile augmented reality and typical implementations. For the type of the mobile augmented reality with the greatest potential is then implemented a desktop application that is easy to use for creating mobile application without any coding knowledge. At the end of this thesis are this desktop application and one of the generated applications tested for usability.
Abstrakt Práce se zabývá analýzou sou£asného vyuºití roz²í°ené reality v prost°edí chytrých mobilních za°ízení. Jmenuje t°í základní typy mobilní roz²í°ené reality a popisuje jejich typickou implementaci. Pro vybraný typ mobilní roz²í°ené reality s nejv¥t²ím potenciálem je poté implementován desktopový nástroj, který umoº¬uje vytvá°et mobilní aplikace bez jakýchkoliv znalostí programování. V záv¥ru práce je tento nástroj a jedna z vytvo°ených mobilních aplikací podrobena testu pouºitelnosti.
ix
x
Obsah 1 Úvod 1.1 1.2
Cíle práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Roz²í°ená realita 2.1 2.2 2.3
Historie . . . . . . . . . . . . . . . . . . . . . Princip . . . . . . . . . . . . . . . . . . . . . . Sou£asné vyuºití v oblasti mobilních za°ízení 2.3.1 Location based roz²í°ená realita . . . . 2.3.2 Marker based roz²í°ená realita . . . . . 2.3.3 Markerless roz²í°ená realita . . . . . . 2.3.4 Praxe . . . . . . . . . . . . . . . . . .
3 Analýza 3.1 3.2 3.3 3.4
Metaio Creator . . . . . . . . Wikitude Studio . . . . . . . Layar Creator . . . . . . . . . Softwarové poºadavky . . . . 3.4.1 Funk£ní poºadavky . . 3.4.2 Nefunk£ní poºadavky .
4 Návrh 4.1
4.2
Uºivatelské rozhraní . . 4.1.1 Desktopová £ást 4.1.2 Mobilní £ást . . . Export mobilní aplikace
5.1
. . . .
. . . .
. . . .
. . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
5
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. 5 . 6 . 7 . 7 . 9 . 11 . 12
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Mobilní £ást . . . . . . . . . . . . . 5.1.1 Výb¥r AR engine . . . . . . 5.1.1.1 AndAR . . . . . . 5.1.1.2 DroidAR . . . . . 5.1.1.3 Metaio SDK . . . 5.1.1.4 Vuforia . . . . . . 5.1.1.5 Wikitude SDK . . 5.1.1.6 Porovnání výkonu
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
xi
3 3
. . . . . . .
. . . .
5 Implementace
. . . .
. . . . . .
1
13
14 14 15 16 16 17
19
19 19 20 21
25 25 25 26 27 28 28 29 30
xii
OBSAH
5.1.1.7 Výsledek . . . . . . . . . . . . . . . . . . P°izp·sobení AR engine . . . . . . . . . . . . . . . 5.1.2.1 Detekce markeru podle obrazové p°edlohy 5.1.2.2 Vykreslování roz²í°ení . . . . . . . . . . . 5.1.3 Parametrizace mobilní aplikace . . . . . . . . . . . Desktopová £ást . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Roz²i°ovaná scéna . . . . . . . . . . . . . . . . . . 5.2.2 Hodnocení kvality marker· . . . . . . . . . . . . . 5.2.3 Export mobilní aplikace . . . . . . . . . . . . . . . Výsledné °e²ení . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2
5.2
5.3
6 Testování 6.1
6.2
Desktopová £ást . . . . . . 6.1.1 Cíl testování . . . 6.1.2 Cílová skupina . . 6.1.3 Výb¥r participant· 6.1.4 Pr·b¥h testu . . . 6.1.5 Testovací scéná° . 6.1.6 Výsledky . . . . . Mobilní £ást . . . . . . . . 6.2.1 Cíl testování . . . 6.2.2 Cílová skupina . . 6.2.3 Výb¥r participant· 6.2.4 Pr·b¥h testu . . . 6.2.5 Testovací scéná° . 6.2.6 Výsledky . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
32 32 33 36 37 38 39 40 41 42
45
45 45 45 45 46 47 47 48 48 49 49 49 49 50
7 Záv¥r
51
A Seznam pouºitých zkratek
57
7.1 7.2
Zhodnocení spln¥ní cíl· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Doporu£ení pro dal²í rozvoj . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
B Záznam z testování desktopové £ásti B.1 Participant 1 . . . . B.1.1 Screener . . . B.1.2 Záznam testu B.1.3 Dotazník . . B.1.4 Shrnutí . . . B.2 Participant 2 . . . . B.2.1 Screener . . . B.2.2 Záznam testu B.2.3 Dotazník . . B.2.4 Shrnutí . . . B.3 Participant 3 . . . . B.3.1 Screener . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
59
59 59 59 60 60 60 60 61 61 61 62 62
xiii
OBSAH
B.3.2 Záznam testu B.3.3 Dotazník . . B.3.4 Shrnutí . . . B.4 Participant 4 . . . . B.4.1 Screener . . . B.4.2 Záznam testu B.4.3 Dotazník . . B.4.4 Shrnutí . . . B.5 Participant 5 . . . . B.5.1 Screener . . . B.5.2 Záznam testu B.5.3 Dotazník . . B.5.4 Shrnutí . . . B.6 Participant 6 . . . . B.6.1 Screener . . . B.6.2 Záznam testu B.6.3 Dotazník . . B.6.4 Shrnutí . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
C Záznam z testování mobilní £ásti C.1 Participant 1 . . . . C.1.1 Screener . . . C.1.2 Záznam testu C.1.3 Dotazník . . C.1.4 Shrnutí . . . C.2 Participant 2 . . . . C.2.1 Screener . . . C.2.2 Záznam testu C.2.3 Dotazník . . C.2.4 Shrnutí . . . C.3 Participant 3 . . . . C.3.1 Screener . . . C.3.2 Záznam testu C.3.3 Dotazník . . C.3.4 Shrnutí . . . C.4 Participant 4 . . . . C.4.1 Screener . . . C.4.2 Záznam testu C.4.3 Dotazník . . C.4.4 Shrnutí . . .
D Manuál aplikace
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62 63 63 63 63 63 64 64 64 64 65 65 65 66 66 66 67 67
69
69 69 69 69 70 70 70 70 70 71 71 71 71 71 72 72 72 72 72 73
75
D.1 Minimální poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 D.2 Pokyny pro spu²t¥ní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 D.3 P°íru£ka pro programátora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
xiv
E Obsah p°iloºeného CD
OBSAH
77
Seznam obrázk· 1.1
Ukázka b¥ºného vyuºití roz²í°ené reality. Dopln¥ní informací p°i p°ímém televizním p°enosu, Head-Up displej v automobilu, ozna£ení obli£ej· v záb¥ru fotoaparátu, mobilní aplikace vyuºívající roz²í°enou realitu. Zdroje: <
> <
> <
> <
> 2
2.1 2.2
Reality Virtuality kontinuum koncept s p°íklady vyuºití . . . . . . . . . . . 6 Ukázka typické location based roz²í°ené reality. Aplikace Layar s vrstvou Zlaté stránky CZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Hledání markeru pomocí porovnávání features . . . . . . . . . . . . . . . . . . 9 Ukázka typické marker based roz²í°ené reality. Demo knihovny Vuforia . . . . 10
2.3 2.4 4.1 4.2 4.3 4.4 4.5 5.1 5.2 5.3 5.4 5.5 5.6
Editor papírový prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . Koncept otá£ení modelu pomocí my²i. Ovládání je závislé na nato£ení modelu a trajektorii ukazatele my²i v·£i st°edu modelu. . . . . . . . . . . . . . . . . . Koncept otá£ení modelu pomocí my²i. Ovládáno je nato£ení pouze ve dvou osách. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobilní aplikace papírový prototyp. Zleva fotoaparát, nápov¥da a galerie marker· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Wireframe owchart zobrazující návrh pr·vodce exportem aplikace . . . . . . Koncept funk£nosti mobilní aplikace. Zelen¥ jsou znázorn¥ny implementované £ásti, ²ed¥ vyuºité knihovny t°etích stran, bíle standardní sou£ásti Android SDK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ukázka vstup· pro test features detektor· a extraktor·. Po sloupcích zleva marker, size, contrast+, contrast-, perspective . . . . . . . . . . . . . . . . . . Vuforia vytvá°í UDT vºdy z celého aktuálního snímku (zelen¥), scénu je tedy nutné transformovat pouze na registrovaný marker (£erven¥) . . . . . . . . . . Ray Picking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ukázka editoru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ukázka mobilní aplikace snímání scény . . . . . . . . . . . . . . . . . . . . .
xv
20 21 21 22 24
26 34 37 39 43 44
xvi
SEZNAM OBRÁZK
Seznam tabulek 5.1 5.2 5.3
Nam¥°ené hodnoty FPS pro Test 1 M¥°ení hodnoty FPS b¥hem snímání statické scény s markerem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Nam¥°ené hodnoty FPS pro Test 2 M¥°ení hodnoty FPS b¥hem snímání dynamické scény s markerem (O = opoºd¥né vykreslování v·£i fotoaparátu, S = skákání vykreslované scény, Z = £astá ztráta detekovaného markeru) . . . . . 32 Výsledky porovnání feature detektor· a extraktor· na mobilním za°ízení s OS Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
xvii
xviii
SEZNAM TABULEK
Kapitola 1
Úvod Pan Novák práv¥ za°izuje byt, stojí v prázdné místnosti a na svém tabletu si prochází katalog nábytku, namí°í fotoaparát tabletu do st°edu místnosti a umístí tam pohovku, o kousek vedle lampu, konferen£ní stolek, zm¥ní barvu zdí a p°es displej tabletu to vypadá, jako by byl v jiº pln¥ za°ízeném byt¥. Toto není scéna z n¥jakého Sci-Fi lmu, ale pouze vyuºití Roz²í°ené Reality, principu, který upravuje aktuální vnímání reálného sv¥ta. Roz²í°ená realita byla dlouhou dobu záleºitostí pouze armádních projekt·, v¥deckých prací, nebo koní£kem nad²enc· do Computer Vision (po£íta£ového vid¥ní) a to zejména kv·li vysokým poºadavk·m na výpo£etní výkon, nebo nutnosti vlastnit speciální hardware. S postupem £asu se stával výpo£etní výkon stále dostupn¥j²í a roz²í°ená realita si pomalu hledala cestu do ²ir²ího pov¥domí lidí. Zprvu prost°ednictvím medií, coº mnozí lidé moºná ani nepost°ehli, jako r·zné dopl¬ující informace vloºené do obrazu p°i ºivých sportovních p°enosech, nap°íklad vyzna£ení vzdáleností p°i hodu o²t¥pem, které vypadá, jako by bylo sou£ásti stadionu, nebo jako interaktivní mapa zobrazená za moderátorem p°i p°edpov¥di po£así, kde se ve skute£nosti nachází jednobarevné klí£ovací pozadí. Dále se roz²í°ená realita k lidem vkrádala v podob¥ speciálního HW, jako jsou nap°íklad Head-Up displeje v automobilech, které promítají do zorného pole °idi£e r·zné informace, jako jsou pokyny navigace, aktuální rychlost, spot°eba a dal²í. Dnes je jiº ov²em situace úpln¥ jiná, roz²í°ená realita se stala v²ední sou£ástí ºivota lidí, moºná jí stále mnozí neznají jménem, ale s produkty, které ji vyuºívají, se setkávají denn¥, a´ uº se jedná o jiº zmi¬ované Head-up displeje v automobilech, televize, fotoaparáty, chytré mobilní telefony a tablety anebo v posledních pár m¥sících i o chytré brýle1 2 3 . Posledních n¥kolik let, pokud vynecháme boom kolem chytrých brýlí v poslední dob¥, je nejvíce o roz²í°ené realit¥ sly²et p°eváºn¥ ve spojení s chytrými mobilními za°ízeními, jako jsou nap°íklad chytré mobilní telefony a tablety. Tato za°ízení se zdají být pro roz²í°enou realitu doslova jako stvo°ená. V¥t²ina dne²ních za°ízení je vybavena nejr·zn¥j²ími senzory a £ipy, které umoº¬ují zjistit p°esnou polohu a orientaci za°ízení, svým výkonem umoº¬ují provád¥t real-time analýzu obrazu získávaného pomocí vestav¥né kamery a také disponují barevnými displeji s velkým rozli²ením. To v²e v kombinaci s velkou mobilitou a roz²í°ením Google Glass
Oakley Airwave
3 Recon Jet
1
2
1
2
KAPITOLA 1.
ÚVOD
Obrázek 1.1: Ukázka b¥ºného vyuºití roz²í°ené reality. Dopln¥ní informací p°i p°ímém televizním p°enosu, Head-Up displej v automobilu, ozna£ení obli£ej· v záb¥ru fotoaparátu, mobilní aplikace vyuºívající roz²í°enou realitu. Zdroje:
mezi lidskou populací d¥lá z mobilních p°ístroj· ideální kus hardware práv¥ pro roz²í°enou realitu. Dá se tedy °íci, ºe mobilní za°ízení jsou v sou£asnosti jedním z nejlep²ích kanál·, kudy se roz²í°ená realita m·ºe dostat ke koncovým uºivatel·m. Tohoto jsou si v¥domi v²ichni velcí hrá£i na poli roz²í°ené reality a v sou£asnosti orientují portfolio svých sluºeb primárn¥ na mobilní za°ízení. P°esto v²ak aplikací vyuºívajících prvky roz²í°ené reality v sou£asnosti nevzniká tolik, kolik by odpovídalo oblíbenosti mezi uºivateli a £asu, který tu spojení chytré mobilní za°ízení roz²í°ená realita existuje. Toto je zp·sobeno p°edev²ím cenou implementace aplikace s roz²í°enou realitou, kdy mohu z vlastní praxe potvrdit, ºe v¥t²ina projekt· vyuºívajících roz²í°enou realitu je zru²ena ihned po vytvo°ení cenové nabídky. Vysoké ceny vývoje mobilních aplikací s roz²í°enou realitou jsou zp·sobeny p°edev²ím velkými licen£ními poplatky za frameworky, které roz²í°enou realitu podporují a cenou vývojá°·, kte°í mají pot°ebné know how, aby byli schopni takovouto aplikaci vytvo°it. Proto jsem se rozhodl v rámci své práce vytvo°it framework, který vývoj mobilních aplikací s roz²í°enou realitou maximáln¥ uleh£í a dovolí tak vytvá°et aplikace i uºivatel·m, kte°í neovládají programování pro mobilní platformy.
1.1.
1.1
CÍLE PRÁCE
3
Cíle práce
Cílem práce je prostudovat a identi kovat hlavní sou£asné zp·soby vyuºití roz²í°ené reality na mobilních za°ízeních. Na základ¥ získaných dat speci kovat a poté i implementovat framework pro snadné vytvá°ení samostatných mobilních aplikací s vyuºitím roz²í°ené reality pro mobilní opera£ní systém Android. Vytvo°ené °e²ení následn¥ podrobit test·m pouºitelnosti jak z hlediska autora aplikace, tak i koncového uºivatele vytvá°ené aplikace. 1.2
Struktura práce
Celá práce je rozd¥lena do p¥ti navazujících £ástí, kterým odpovídají jednotlivé kapitoly tohoto textu. První £ást se zabývá samotným pojmem roz²í°ená realita. Pokou²í se tento pojem de novat a nastínit základní princip. Dále pak popisuje t°i nej£ast¥j²í implementace roz²í°ené reality v prost°edí mobilních aplikací a v záv¥ru je zmín¥no n¥kolik praktických post°eh· ze sou£asného vývoje mobilních AR aplikací. Druhá £ást se zabývá v sou£asnosti nejºádan¥j²í implementací roz²í°ené reality v mobilním prost°edí. Popisuje vlastnosti typické pro aplikace, které ji vyuºívají, a monitoruje nástroje pro jejich snadnou implementaci. V záv¥ru jsou pak de novány poºadavky na °e²ení vznikající v pr·b¥hu této práce. T°etí £ást práce je v¥nována návrhu vznikajícího °e²ení. Specializuje se pak p°edev²ím na podobu uºivatelského prost°edí a to jak z pohledu tv·rce mobilní aplikace, tak i z pohledu koncových uºivatel· vytvá°ené aplikace. ást £tvrtá se poté zabývá popisem zajímavých £ástí °e²ených p°i implementaci daného °e²ení. V kapitole je obsaºena jak £ást mobilní, tak i ta desktopová. Poslední pátá £ást se poté v¥nuje testování pouºitelnosti vytvo°eného °e²ení. Je testována jak £ást ur£ená pro tv·rce mobilních aplikací, tak i samotná generovaná aplikace.
4
KAPITOLA 1.
ÚVOD
Kapitola 2
Roz²í°ená realita Kapitola v krátkosti popisuje historii pojmu roz²í°ená realita, snaºí se roz²í°enou realitu obecn¥ de novat a stru£n¥ popsat její princip. Dále je v kapitole shrnuto sou£asné vyuºití roz²í°ené reality v oblasti mobilních za°ízení, vyjmenovány a popsány základní t°i p°ístupy vyuºívané v mobilní roz²í°ené realit¥ a n¥kolik post°eh· sou£asného vývoje roz²í°ené reality v oblasti mobilních za°ízení z praxe.
2.1
Historie
V²e za£alo v roce 1968, kdy americký v¥dec Ivan Edward Sutherland sestrojil první systém vyuºívající roz²í°enou realitu [1]. Jednalo se o pr·hledný displej p°ipevn¥ný uºivateli do jeho zorného pole, jehoº pohyb byl registrován pomocí mechanických sou£ástí systému a ultrazvuku. Na základ¥ pohybu displeje poté systém v reálném £ase vykresloval jednoduchá roz²í°ení p°ímo do zorného pole uºivatele. Jako dal²í mezník ve vývoji roz²í°ené reality, je pokládáno vy°£ení samotného slovního spojení roz²í°ení realita, tedy spí²e jeho anglického ekvivalentu augmented reality. To se konalo v roce 1992 na páté mezinárodní konferenci Hawaii International Conference on Systems Science (HICSS), kde ve svém p°ísp¥vku [28] dva auto°i, Tom Caudell a David Mizell spojili slova roz²í°ená realita s principem vkládání po£íta£ov¥ vytvo°ených vrstev do scény reálného sv¥ta. O dva roky pozd¥ji, tedy v roce 1994, svou de nicí Reality Virtuality kontinua p°isp¥li k vymezení pojmu roz²í°ená realita i Paul Milgram a Fumio Kishino. Ve své práci [13] popisují p°echod od reality k virtuální realit¥, v n¥mº se spolu s roz²í°enou virtualitou nachází i roz²í°ená realita. V £lánku auto°i demonstrují, ºe nelze jednozna£n¥ ur£it hranice roz²í°ené reality. Zjednodu²ený Reality Virtuality kontinuum koncept je vid¥t na obrázku 2.1. A jako poslední zmínku z historie roz²í°ené reality uvedu £lánek Ronalda Azuma [25], který je mnohdy ozna£ován jako první p°ehled roz²í°ené reality. lánek nep°iná²í do oblasti roz²í°ené reality nic nového, jedná se ve skute£nosti pouze o souhrn doposud realizovaného vyuºití roz²í°ené reality v armád¥, pr·myslu, léka°ství, popisu vyuºitých princip· a také obsahuje v sou£asnosti v²eobecn¥ uznávanou de nici roz²í°ené reality. lánek de nuje roz²í°enou realitu jako systém, který má následující t°i charakteristiky: 5
6
KAPITOLA 2.
ROZÍENÁ REALITA
Obrázek 2.1: Reality Virtuality kontinuum koncept s p°íklady vyuºití
• Kombinuje realitu a virtualitu • Je schopen interakce v reálném £ase • Respektuje t°etí rozm¥r reálné scény 2.2
Princip
V sou£asnosti existuje spousta rozli£ných technik, jak je dosahováno roz²í°ení reality, av²ak u v¥t²iny t¥chto zp·sob· lze nalézt následující velmi zjednodu²ený základní princip funkce roz²i°ování reality. 1. Snímání reálné scény
• Pokud chceme realitu jakýmkoliv zp·sobem roz²i°ovat, musíme ji nejprve um¥t n¥jakým zp·sobem snímat a zaznamenávat ve formátu, se kterým umíme dále pracovat • Jedná se nap°íklad o snímání reálného sv¥ta pomocí digitální kamery, nebo kombinace kamery a polohových £idel 2. Detekce reálné scény
• Dále je nutné rozeznat nasnímanou reálnou scénu, detekovat záchytné body, abychom v¥d¥li, kterou £ást (výse£) reálného sv¥ta snímáme a um¥li se v n¥m orientovat, v¥d¥li kde je naho°e, kde dole, vlevo vpravo, kudy vede rovina ur£ující nap°íklad zem a podobn¥ • P°íkladem jsou t°eba r·zné techniky po£íta£ového vid¥ní 3. Roz²í°ení reálné scény
• Kdyº máme reálnou scénu a jiº jsme schopni se v ní orientovat, m·ºeme do ní tedy zasadit roz²í°ení • Roz²i°ovat reálnou scénu lze r·znými zp·soby, nap°íklad vypsáním textu, vykreslením 3D modelu, p°ehráním zvuku, atd.
2.3.
SOUASNÉ VYUITÍ V OBLASTI MOBILNÍCH ZAÍZENÍ
7
4. Vykreslení roz²í°ené scény
• Nakonec je ºádoucí n¥jakým zp·sobem zobrazit uºivateli výslednou reálnou scénu dopln¥nou o roz²í°ení, která jsme p°idali v p°edchozím kroku • Výslednou scénu lze zobrazovat mnoha zp·soby, pomocí displeje, reproduktor·, zkrátka záleºí na tom, jak je realita roz²i°ována 2.3
Sou£asné vyuºití v oblasti mobilních za°ízení
Jak jsem se jiº zmínil v úvodu této práce, aktuáln¥ nejv¥t²í mnoºství projekt· vyuºívajících roz²í°enou realitu vzniká ve sfé°e mobilních za°ízení, kde lze v posledních letech pozorovat zajímavý, ale dosti masivní trend vyuºití roz²í°ené reality jako nástroj virálního marketingu1 . Takovéto virální mobilní aplikace mají velmi krátkou ºivotnost a velmi speci cký ú£el, kterým je zaujmout uºivatele a nenásiln¥ propagovat reklamní sd¥lení. Jako nástroj pro zaujetí uºivatele je velmi £asto vyuºit samotný princip roz²í°ené reality, který stále na mnohé p·sobí jako n¥co magického. O ²í°ení aplikace se poté stará snaha lidí pochlubit se ve svém okolí n¥£ím novým a zajímavým, coº ve v¥t²in¥ p°ípad· vyvolává °et¥zovou reakci. Krom¥ reklamy, lze nalézt prvky roz²í°ené reality také snad ve v²ech ostatních kategoriích mobilních aplikací, od sportu, p°es dopravu, volný £as, vzd¥lání aº po hry. Lze tedy nalézt nejr·zn¥j²í vyuºití roz²í°ené reality, navigace, zábava, mysti kace, asistence, vzd¥lávání, komunikace atd. P°esto lze aplikace jednodu²e rozd¥lit do t°í skupin a to podle typu detekce reálné scény. 2.3.1
Location based roz²í°ená realita
První zp·sob detekce reálné scény, který se v prost°edí mobilních za°ízení roz²í°il, je zaloºen na rozeznávání polohy (lokace) za°ízení, proto tedy location based. Poloha za°ízení se detekuje pomocí speciálního HW vybavení dne²ních mobilních za°ízení, jako jsou GSM, GPS a Wi-Fi p°ijíma£e, z jejichº dat se ur£uje co moºná nejp°esn¥j²í poloha za°ízení v·£i reálnému sv¥tu. Dále se tato poloha £asto kombinuje s daty získanými z dal²ích senzor· v za°ízení, jako jsou gyroskop, akcelerometr, kompas, barometr a dal²í, pro zp°esn¥ní polohy a navíc pro zji²t¥ní orientace za°ízení v prostoru reálného sv¥ta. Kombinací takto získaných dat lze vcelku snadno vypo£ítat p°ibliºný cíl, kam nap°íklad sm¥°uje objektiv vestav¥ného fotoaparátu, zjistit tak které objekty zájmu jsou aktuáln¥ ve snímané scén¥ a na základ¥ t¥chto informací dokreslit roz²í°ení do snímané scény. Tento zp·sob detekce reálné scény vyniká nad ostatními zejména svou výpo£etní nenáro£ností a snadnou implementací. Vesm¥s se jedná pouze o jednoduchou kombinaci výstup· z vý²e zmín¥ných senzor· jako je nap°íklad sestavení rota£ní matice [21] z úhlu nato£ení za°ízení kolem kaºdé ze t°í os (XYZ) v prostoru. Detaily o implementaci lze £erpat nap°íklad z knihy Pro Android Augmented Reality [26] anebo rovnou vyuºít n¥kterou z desítek kvalitních a v¥t²inou voln¥ dostupných knihoven2 3 4 . marketingová technika, která pro ²í°ení reklamního sd¥lení vyuºívá samotných p°íjemc· ARviewer SDK 3 junaio 4 mixare Open Source Augmented Reality Engine
1 2
8
KAPITOLA 2.
ROZÍENÁ REALITA
Nevýhodou tohoto °e²ení je jeho p°esnost, ne v²echna za°ízení detekují totoºnou scénu pokaºdé stejn¥, proto se m·ºe stát, ºe bod v rozeznané scén¥ bude vºdy na trochu jiném míst¥, pop°ípad¥ m·ºe samovoln¥ ve scén¥ cestovat, to v²e se odvíjí od kvality a p°esnosti dat získávaných ze senzor· v za°ízení. Jako dal²í nedostatek tohoto zp·sobu detekce reálné scény se dá ozna£it fakt, ºe pro jeho b¥h je zapot°ebí dodate£ných HW senzor·, které ov²em jsou dnes jiº v základním vybavení v¥t²iny mobilních p°ístroj·. Location based roz²í°ená realita je svou povahou vhodná p°eváºn¥ pro outdoor aplikace, tedy aplikace, které jsou ur£eny pro uºívání pod otev°eným nebem, kde lze z pouºívaných senzor· získat nejp°esn¥j²í data. V sou£asnosti nejroz²í°en¥j²ími aplikacemi vyuºívajícími location based roz²í°enou realitu jsou takzvané AR Browsery. Jedná se o aplikace, které slouºí jako agregátor location based roz²i°ujících vrstev. Jde v podstat¥ o aplikace, které poskytují engine, který obstarává location based detekci reality a inzerenti poté do jejich katalog· registrují svá roz²í°ení reality. Takovéto aplikace poté mají vyuºití podle zvolených roz²í°ení, m·ºe se jednat o turistické pr·vodce, katalogy rem, prohlíºe£e virtuálních zajímavostí, hry, záleºí zkrátka na autorech roz²i°ujících vrstev. Mezi nejznám¥j²í katalogové aplikace pat°í Layar5 , Wikitude6 , junaio7 .
Obrázek 2.2: Ukázka typické location based roz²í°ené reality. Aplikace Layar s vrstvou Zlaté stránky CZ Krom¥ aplikací typu AR Browser lze v sou£asnosti nají i jiné vyuºití location based roz²í°ené reality. Zajímavou ukázkou jejího vyuºití je aplikace Zombie run!8 , která realitu Layar Wikitude 7 junaio 8 Zombie run! 5 6
2.3.
SOUASNÉ VYUITÍ V OBLASTI MOBILNÍCH ZAÍZENÍ
9
roz²i°uje pomocí zvuku. Zombie run pracuje na jednoduchém principu, snaºí se uºivateli zpest°it b¥h pomocí navození iluze, ºe jej pronásleduje skupina zombie. Za dal²í povedenou ukázku location based roz²í°ené reality povaºuji hru Ingress9 , která prom¥¬uje nejr·zn¥j²í sochy, street art, monumenty apod. ve virtuální portály, které poté hrá£i pomocí svých mobilních za°ízení obsazují a spojují do portálových polí. 2.3.2
Marker based roz²í°ená realita
Druhý hojn¥ vyuºívaný zp·sob detekce reálné scény je zaloºen na technikách po£íta£ového vid¥ní, konkrétn¥ na detekci p°edem známého obrazového vzoru, tzv. markeru, ve scén¥, odtud tedy marker based roz²í°ená realita. Detekce markeru je nej£ast¥ji zaloºena na principech vyhledávání lokálních feature deskriptor· v obrázcích. Features je souhrnné ozna£ení pro informace relevantní pro vy°e²ení daného problému[16]. V tomto kontextu se jedná o informace získané z obrázku, které jej ur£itým zp·sobem charakterizují. Zjednodu²en¥ °e£eno se jedná o jistý druh popisu obrázku, který je nezávislý na jeho velikosti, orientaci, osv¥tlení atd. Jako features se nej£ast¥ji pouºívají výrazné speci cké struktury obrázku, jako jsou body, hrany, nebo komplexn¥j²í struktury jako jsou výrazné £ásti samotného obrázku, nebo výsledky nejr·zn¥j²ích operací nad daty obrázku.
Obrázek 2.3: Hledání markeru pomocí porovnávání features Pro vyhledávání features se vyuºívá specializovaných algoritm· souhrnn¥ ozna£ovaných jako feature detectors. Jedná se o výpo£etn¥ náro£né algoritmy, které pro kaºdý pixel obrázku rozhodnou, zda se jedná o feature, £i nikoliv. Výsledkem takovýchto algoritm· je jakýsi 9
Ingress
10
KAPITOLA 2.
ROZÍENÁ REALITA
abstraktní popis konkrétního obrázku pomocí klí£ových bod·, neboli sou°adnic nalezených features v obrázku. Abychom ale získali popis obrázku, který bude nezávislý na jeho velikosti, orientaci, sv¥tlosti atd. je nutné takto získané features je²t¥ dále ltrovat a v popisu obrázku ponechat pouze kvalitní features, tzn. ty, které nejsou redundantní a lze je v kontextu obrázku jednozna£n¥ identi kovat, nap°íklad jejich polohou, orientací, okolím atd. To se provádí algoritmy nazvanými feature descriptors, nebo také n¥kdy jako feature (descriptor) extractors. Výsledkem t¥chto algoritm· jsou tzv. lokální feature deskriptory, jedná se v podstat¥ o jednozna£n¥ popsané kvalitní features v kontextu obrázku. P°i detekci markeru ve scén¥ (obr. 2.3) se tedy vytvo°í dvojice mnoºin lokálních feature deskriptor·, jedna mnoºina pro samotný marker a druhá pro snímanou scénu. Následn¥ se pomocí vzájemného porovnávání lokálních deskriptor· nap°í£ mnoºinami zjistí, zda se marker ve snímané scén¥ nachází, £i nikoliv. Z takto získané polohy markeru ve scén¥ jiº není obtíºné vypo£ítat nap°íklad transforma£ní matici[23], se kterou se poté jiº dá dále pracovat p°i roz²i°ování scény. Aplikace vyuºívající marker based roz²í°enou realitu jsou velmi atraktivní pro koncové uºivatele a to zejména z toho d·vodu, ºe na rozdíl od location based roz²í°ené reality mohou takovouto aplikaci vyuºít kdekoliv a kdykoliv, sta£í pouze mít poblíº pot°ebný marker. Hlavní nevýhodou marker based roz²í°ené reality je cena vývoje. Jak jsem psal jiº v úvodu, vytvo°ení takovéto aplikace si zpravidla vyºaduje zaplacení nemalých licen£ních poplatk· za kvalitní AR framework, který je schopen plynulého b¥hu na mobilních za°ízeních anebo najmutí zku²eného vývojá°e, který má pot°ebné know how pro vytvo°ení takovéto aplikace i s vyuºitím voln¥ dostupných knihoven, které ov²em neposkytují takový komfort p°i vývoji a výsledný výkon jako profesionální °e²ení.
Obrázek 2.4: Ukázka typické marker based roz²í°ené reality. Demo knihovny Vuforia Marker based roz²í°ená realita se nejvíce vyuºívá pro implementaci jiº zmi¬ovaných reklamních aplikací, jako je nap°íklad aplikace propagující známý £eský pivovar Pilsner Stories10 , nebo aplikace prezentující novou kolekci muºského spodního prádla IMPETUS Aug10
Pilsner Stories
2.3.
SOUASNÉ VYUITÍ V OBLASTI MOBILNÍCH ZAÍZENÍ
11
mented Reality11 a nebo jako dopln¥k katalogu zobrazující vybrané zboºí ve form¥ 3D modelu, p°íkladem je t°eba aplikace Katalog IKEA12 . Krom¥ reklamy, je marker based roz²í°ená realita hojn¥ vyuºívána i jako zpest°ení nejr·zn¥j²ích knih a £asopis·, mezi nejznám¥j²í pat°í aplikace pro Guinessovu knihu rekord· GWR2014 - Augmented Reality13 , která knihu dopl¬uje o nejr·zn¥j²í videa, 3D modely v ºivotní velikosti a dal²í zajímavé informace. Dále lze roz²í°enou realitu vyuºít i jako dopln¥k moderního um¥ní, jako nap°íklad aplikace MROBOTI 14 , která doprovázela expozici soch nazvanou Roboti VS Lidé, která se uskute£nila koncem léta v jednom z praºských nákupních center. 2.3.3
Markerless roz²í°ená realita
Poslední zp·sob detekce scény je nazývám markerless roz²í°ená realita. V mnoha ohledech je podobná p°edchozí skupin¥, která pomocí technik po£íta£ového vid¥ní hledala marker ve scén¥. Markerless roz²í°ená realita ov²em, jak jiº název napovídá, ºádný marker nepouºívá a v reálné scén¥ vyhledává obecné objekty, kterými m·ºe být v podstat¥ cokoliv, lidský obli£ej, automobil, banán a podobn¥. U tohoto druhu roz²í°ené reality jiº nelze získané features ze snímané scény jednodu²e porovnávat s p°edlohou v podob¥ markeru, ale je nutné zapojit so stikovan¥j²í metody, nej£ast¥ji r·zné druhy klasi kátor·, jako je nap°íklad HAAR klasi kátor[17], který byl jako první pouºit pro detekci lidských obli£ej·. Takovéto klasi kátory ov²em vyºadují trénování15 , coº je mnohdy velmi zdlouhavé. Moºná proto v sou£asnosti existuje pouze hrstka mobilních aplikací, které by ve v¥t²í mí°e vyuºívaly tento typ roz²í°ené reality, výjimku tvo°í snad pouze aplikace fotoaparát·, které dokáºí detekovat a vyzna£it lidské tvá°e v záb¥ru, nebo dokonce vytvo°it snímek aº v moment¥, kdy se v²echny detekované osoby v hledá£ku kamery usmívají. Mezi výhody tohoto °e²ení roz²í°ené reality pat°í hlavn¥ jeho tém¥° neomezené moºnosti, pokud má tv·rce £as a dostatek trénovacích dat pro vytvo°ení kvalitního klasi kátoru, lze vytvá°et velmi zajímavé projekty, p¥kným p°íkladem je aplikace iOnRoad Augmented Driving 16 , která pomocí mobilního telefonu a roz²í°ené reality substituuje drahá vybavení moderních automobil· jako je, hlídání jízdního pruhu, detekce bezpe£ného odstupu, onboard kamera a dal²í. Nevýhodou markerless roz²í°ené reality je stejn¥ jako v p°ípad¥ marker based °e²ení p°eváºn¥ cena vývoje, která je v tomto p°ípad¥ oproti marker based je²t¥ o n¥co vy²²í. Vyuºití markerless roz²í°ené reality ve sfé°e mobilních aplikací není nikterak velké, av²ak existuje aplikace, které je nainstalovaná na tém¥° kaºdém mobilním za°ízení a která vyuºívá principy markerless roz²í°ené reality, tím je jiº zmi¬ovaná aplikace fotoaparátu. V¥t²ina IMPETUS Augmented Reality 12 Katalog IKEA 13 GWR2014 - Augmented Reality 14 MROBOTI 15 Proces, p°i kterém si klasi kátor na základ¥ p°edkládaných vstup· vytvá°í sadu vah a nejr·zn¥j²ích statistik pro rozeznání daného objektu 16 iOnRoad Augmented Driving Pro 11
12
KAPITOLA 2.
ROZÍENÁ REALITA
dne²ních aplikací pro focení, £i nahrávání videa umoº¬uje zapnout mód, ve kterém uºivateli zvýraz¬uje obli£eje v záb¥ru kamery, £i jej upozor¬uje na to, ºe ne v²ichni v záb¥ru se usmívají. 2.3.4
Praxe
Podle zastoupení v obchodech s mobilními aplikacemi v sou£asnosti vzniká nejvíce AR aplikací, které svou implementací roz²í°ené reality spadají do prvních dvou zde zmín¥ných skupin, tedy do location based a marker based roz²í°ené reality. Tento trend mohu potvrdit i ze svého hlediska jakoºto vývojá°e mobilních aplikací pro platformu Android. Nejv¥t²í poptávku po vývoji za poslední dobu p°itom registruji po marker based roz²í°ené realit¥. Je to dáno nejspí²e tím, ºe pro vytvo°ení aplikace s location based roz²í°enou realitou existují desítky nástroj·, které umoº¬ují vytvo°ení mobilní aplikace i bez jakýchkoliv znalostí vývoje. P°íkladem jsou nástroje jako Hoppala Augmentation 17 , buildAR18 , nebo jiº zmi¬ovaní Layar, Wikitude a junaio. Naproti tomu pro marker based roz²í°enou realitu takovýchto nástroj· existuje jen hrstka, v¥t²ina z nich je spojena s nemalými licen£ními poplatky, které svou hodnotou zpravidla p°ed£í samotný vývoj aplikace, dále jsou tato °e²ení omezena pouze na vytvá°ení vrstev do katalog·, které mají podobný ú£el jako jiº zmi¬ované AR Browsery u location based roz²í°ené reality. Ve zbytku práce se budu jiº zabývat pouze marker based roz²í°enou realitou, která je z mého pohledu v sou£asnosti mezi zákazníky nejºádan¥j²í.
17 18
Hoppala Augmentation buildAR
Kapitola 3
Analýza V této kapitole popisuji, jak vypadá typická mobilní prezentace s vyuºitím marker based roz²í°ené reality, její typické chování a pouºití. Dále v kapitole v krátkosti p°edstavuji sou£asné nástroje pro snadnou tvorbu mobilních AR prezentací a na základ¥ jejich analýzy uvádím poºadavky na funk£nost ideálního nástroje. Jak jsem psal v záv¥ru p°edchozí kapitoly, ve zbytku práce se budu zabývat jiº pouze marker based roz²í°enou realitou. Pokusím se vytvo°it nástroj, pomocí kterého bude velmi snadné vytvo°it mobilní aplikaci s vyuºitím roz²í°ené reality. Nástroj bude ur£en p°edev²ím pro vytvá°ení aplikací typu prezentace, jedná se totiº o v sou£asnosti nej£ast¥ji poptávané a realizované aplikace s marker based roz²í°enou realitou. Na ukázku uvádím n¥kolik stru£ných popis· podobných aplikací, s jejichº realizací, £i analýzou jsem se ve své praxi setkal.
• Aplikace zamý²lená jako virální reklama. Aplikace na p°edem de novaném markeru zobrazuje 3D animovaný p°íb¥h zobrazující pov¥st o zaloºení rmy. • Aplikace ur£ená k p°ipomenutí výro£í zaloºení rmy. Aplikace p°es logo rmy zobrazuje video se záb¥ry z historie. • Aplikace ur£ená pro bary. Aplikace má de nováno n¥kolik marker·, kdy na kaºdém markeru je zobrazen 3D model vybraného drinku. • Aplikace pro oºivení katalogu. Aplikace zobrazující na p°edem de novaném markeru 3D modely elektrických vypína£· vybraných z katalogu. V²echny vý²e popsané aplikace mají spole£ný p°ípad uºití. Uºivatel vyhledá marker, spustí aplikaci a pomocí vestav¥ného fotoaparátu v za°ízení za£ne marker snímat. Aplikace po rozeznání markeru za£ne do scény dokreslovat pat°i£ná roz²í°ení (3D animaci, statický 3D model, video, . . . ). Stejné nebo podobné vyuºití má v¥t²ina dne²ních AR aplikací umíst¥ných v obchodech s mobilními aplikacemi. Této skute£nosti si v²imlo i n¥kolik velkých hr᣷ na poli mobilní roz²í°ené reality a rozhodli se toho pat°i£n¥ vyuºít. Za£ali nabízet nástroje, editory, které pomoci gra ckého rozhraní umoº¬ují generovat podobný obsah jako zdroj dat pro jejich katalogové aplikace. Tyto nástroje jsou ur£eny i pro uºivatele, kte°í nemají ºádné znalosti vývoje. Nevýhodou t¥chto °e²ení je fakt, ºe za jejich pomoci nelze vytvo°it samostatnou aplikaci, vesm¥s se vºdy jedná pouze o vrstvu do jejich katalogu. 13
14
KAPITOLA 3.
3.1
ANALÝZA
Metaio Creator
Editor, nazvaný Metaio Creator, je produkt n¥mecké rmy Metaio, která jiº n¥kolik let platí za jednoho z p°edních celosv¥tových leader· v oblasti roz²í°ené reality. Firma Metaio, krom¥ knihoven pro podporu roz²í°ené reality na rozli£ných opera£ních systémech, a´ uº t¥ch mobilních (Android, iOS), tak i t¥ch desktopových (Windows, Mac OS X), je autorem mnoha dopl¬kových sluºeb, které jakkoliv s roz²í°enou realitou souvisí (Metaio Cloud pro snaz²í distribuci nových marker· a model·, skriptovací jazyk AREL pro moºnost vývoje AR aplikací v HTML5, Metaio Toolbox pro pokro£ilej²í aplikaci roz²í°ené reality jako je nap°íklad markerless AR a dal²í). Metaio dále také kaºdoro£n¥ po°ádá evropskou nejv¥t²í konferenci o roz²í°ené realit¥ s názvem insideAR. Moºná proto je její produkt Metaio Creator povaºován za jeden z nejlep²ích a nejpropracovan¥j²ích nástroj· pro snadnou tvorbu AR aplikací. Produkt Meatio Creator je editor pro vytvá°ení program· vyuºívajících roz²í°enou realitu, který je dostupný pro opera£ní systémy Windows a Mac OS X. Editor umí vytvá°et zdrojový kód nativní aplikace pro sou£asné mobilní systémy Android a iOS, pro úsp¥²ný p°eklad kódu je ale nutné zakoupit licenci pro Metaio SDK a mít dal²í znalosti vývoje pro danou mobilní platformu. Creator dále umoº¬uje generovat i desktopové aplikace pro OS Windows a Mac OS X, nebo vrstvy do mobilního AR browseru junaio, jehoº autorem je taktéº rma Metaio. Editor umí lokáln¥ vytvá°et 2D markery z libovolného obrázku a dále podporuje import 3D marker· a map z programu Metaio Toolbox. Creator zvládá de novat n¥kolik marker· sou£asn¥ a dovoluje na marker umístit 3D modely ve formátech *.fbx *.dae *.obj *.md2, fotogra e, videa, zvuky a r·zná tla£ítka s p°ednastavenými akcemi, jako je sdílení na sociálních sítích, otev°ení webové stránky, vloºení události do kalendá°e atd.
Cenová politika1 • Jednorázová licence 490 e • Demo licence s moºností vytvo°it vrstvu s maximáln¥ dv¥ma markery a dvojicí objekt· umíst¥ných na jeden marker. • Pro vytvo°ení samostatné mobilní aplikace je nutné dokoupit Metaio SDK licence od 2 950 e 3.2
Wikitude Studio
Dal²ím zástupcem editor· pro snadné vytvá°ení mobilních AR aplikací je cloudová sluºba Wikitude Studio. Studio pat°í do celé rodiny nástroj· roz²í°ené reality nazvané souhrnn¥ Wikitude. Za celou touto rodinou AR nástroj· (Wikitude Studio, Wikitude Word Browser, Wikitude web based SDK, atd.) stojí stejnojmenná rma Wikitude (d°íve Mobilizy), která má sv·j p·vod v Rakousku. Stejn¥ jako p°edchozí zmín¥né Metaio i Wikitude pat°í mezi sv¥tové ²pi£ky v mobilní roz²í°ené realit¥. Firma Wikitude si navíc m·ºe p°ipsat jedno prvenství v tomto odv¥tví a sice byla první, kdo ve°ejn¥ vyuºil koncept location based roz²í°ené reality pro mobilní telefony[24]. 1
ceny p°evzaty z dne 7. 11. 2013
3.3.
LAYAR CREATOR
15
Jak jsem se jiº zmínil, Wikitude Studio je cloudová sluºba, znamená to tedy, ºe je p°ístupná odkudkoliv za pomoci webového prohlíºe£e. Studio umoº¬uje vytvá°et pouze cloudové aplikace, takzvané sv¥ty (Word), nelze tedy za jeho pomoci vygenerovat p°ímo nativní aplikaci (v p°ípad¥ platformy Android, instala£ní balí£ek *.apk). Vygenerovaný sv¥t lze ve°ejn¥ publikovat prost°ednictvím AR Browser aplikace Wikitude Word Browser, nebo vytvo°ením jednoduché nativní mobilní aplikace, která se pomocí Wikitude SDK spojí s vámi de novaným sv¥tem. Wikitude Studio umoº¬uje vytvá°et vlastní markery z libovolných obrázk·, v jednom sv¥t¥ m·ºete de novat i více marker·. Studio do rozeznané scény umoº¬uje umis´ovat text, obrázky, tla£ítka odkazující na web, vlastní html widgety, online videa, nebo 3D modely, ty ov²em musí být p°evedeny do speciálního Wikitude formátu s koncovkou *.wt3. Pro konverzi model· do tohoto formátu je k dispozici desktopová aplikace ur£ená pro OS Windows a Mac OS X. Aplikace umoº¬uje konverzi pouze dvou formát· a to FBX a Collada.
Cenová politika2 • Od 1,49 eza marker na m¥síc • Trial verze s moºností jednoho sv¥ta s jedním markerem zdarma • Pro vytvo°ení standalone mobilní aplikace je nutné dokoupit wikitude SDK, licence od 99 e 3.3
Layar Creator
Jako poslední ukázku sou£asných nástroj· pro snadný vývoj mobilních aplikací s roz²í°enou realitou jsem vybral sluºbu Layar a její Layar Creator. Layar je ze v²ech zde jmenovaných sluºeb nejmlad²í, vznikl aº v roce 2009 v nizozemském Amsterodamu, ale zato nejznám¥j²í. Layar Creator je, podobn¥ jako Wikitude, cloudová sluºba a stejn¥ jako u Wikitude s jeho pomocí nelze vytvo°it samostatnou nativní aplikaci pro mobilní za°ízení. Vytvo°ené aplikace, tentokrát nazývané jako vrstvy (layer), se ke konzument·m dostávají skrze globální AR browser aplikaci s p°íhodným názvem Layar. Creator se nijak moc neli²í od konkurence a také umoº¬uje vytvá°ení vlastních marker· z libovolného obrázku. Do rozeznané scény poté umoº¬uje vloºit tla£ítka s p°ednastavenými akcemi, jako jsou na£tení webové stránky, vyto£ení telefonního £ísla, odeslání e-mailu, sdílení na sociální sít¥, atd. krom¥ tla£ítek lze do scény vkládat fotogra e, videa, zvuky, webové stránky, a spoustu dal²ích. Jediné co Layar Creatoru oproti konkurenci schází je vloºení 3D modelu.
Cenová politika3 • Od 9,99 eza marker • Layar Creator je poskytován i zdarma, poté jsou ov²em n¥které funkce Creatoru zablokovány a navíc se v detekované scén¥ zobrazuje reklama 2 3
ceny p°evzaty z dne 7. 11. 2013 ceny p°evzaty z dne 7. 11. 2013
16
3.4
KAPITOLA 3.
ANALÝZA
Softwarové poºadavky
Následuje de nice poºadavk·, které by m¥l spl¬ovat ideální nástroj pro snadnou tvorbu aplikací s marker based roz²í°enou realitou. P°i jejich de nici jsem vycházel z analýzy vý²e zmín¥ných sou£asných °e²ení a vlastních praktických zku²eností.
3.4.1
Funk£ní poºadavky
Funk£ní poºadavky ur£ují základní poºadovanou funk£nost nástroje a generované mobilní aplikace. Kaºdý poºadavek je jednozna£n¥ ur£en svým identi kátorem, obsahuje krátký popis a je mu p°i°azena priorita podle metody MoSCoW[19].
ID poºadavku: RF-C1 Priorita: Must have Popis poºadavku: Nástroj musí umoºnit vytvo°ení samostatné mobilní aplikace. ID poºadavku: RF-C2 Priorita: Must have Popis poºadavku: Nástroj musí umoºnit vytvo°ení markeru z libovolného obrázku a zhod-
notit jeho kvalitu.
ID poºadavku: RF-C3 Priorita: Must have Popis poºadavku: Nástroj musí umoºnit vkládat do scény roz²í°ení v podob¥ 3D modelu, 3D animace, obrázku, videa, tla£ítka a textu.
ID poºadavku: RF-C4 Priorita: Must have Popis poºadavku: Nástroj musí umoºnit vkládaná roz²í°ení ve scén¥ pozicovat a transfor-
movat (ve smyslu rotace, zm¥na velikosti, ...).
ID poºadavku: RF-C5 Priorita: Could have Popis poºadavku: Nástroj by mohl umoºnit export uºivatelského obsahu jako knihovny
vhodné pro dal²í vývoj.
ID poºadavku: RF-M1 Priorita: Must have Popis poºadavku: Generovaná mobilní aplikace musí umoºnit zobrazit podporované markery.
3.4.
SOFTWAROVÉ POADAVKY
3.4.2
17
Nefunk£ní poºadavky
Nefunk£ní (systémové) poºadavky kladou nároky na nefunk£ní sou£ásti nástroje a generované mobilní aplikace jako jsou nap°íklad výkon, kvalita, design atd. Op¥t má kaºdý nefunk£ní poºadavek sv·j jednozna£ný identi kátor a krátký popis. Priorita t¥chto poºadavk· není ur£ena.
ID poºadavku: RN-C1 Popis poºadavku: Nástroj musí být schopen b¥ºet na platform¥ s OS Microsoft Windows XP a nov¥j²í.
ID poºadavku: RN-C2 Popis poºadavku: Uºivatelské rozhraní nástroje musí být snadno ovladatelné i pro uºivatele
bez znalostí vývoje software.
ID poºadavku: RN-M1 Popis poºadavku: Generovaná mobilní aplikace musí být schopna b¥ºet na platform¥ s OS
Android 4.0 ICS a nov¥j²í.
ID poºadavku: RN-M2 Popis poºadavku: Generovaná mobilní aplikace by m¥la být schopna na v¥t²in¥ za°ízení b¥ºet minimáln¥ 20FPS.
18
KAPITOLA 3.
ANALÝZA
Kapitola 4
Návrh V této kapitole se v¥nuji návrhu °e²ení, p°edev²ím pak návrhu uºivatelského rozhraní jak desktopového nástroje, tak i generované mobilní aplikace.
4.1
Uºivatelské rozhraní
P°i návrhu uºivatelského rozhraní desktopového nástroje jsem bral ohled na uºivatele bez znalostí vývoje software, jak ur£uje softwarový poºadavek RN-C2 a zárove¬ jsem usiloval o to, aby ve²keré hlavní ovládací prvky byly na první pohled viditelné a uºivatel je nemusel hledat ve sloºitých nabídkách. Dále jsem uºivatelské rozhraní desktopového nástroje p°izp·sobil zvyklostem opera£ního systému Microsoft Windows, jak nazna£uje dal²í softwarový poºadavek RN-C1. P°i návrhu generované mobilní aplikace jsem se snaºil drºet nejnov¥j²ích Androidích guidlines[3]. P°i návrhu uºivatelského rozhraní jsem postupoval metodou papírového prototypování[20]. Prototypy jsem testoval se zástupci cílové skupiny. Následuje ukázka nálních prototyp· 4.1.1
Desktopová £ást
Hlavní obrazovka desktopového nástroje (obr. 4.1) slouºí p°eváºn¥ jako editor roz²i°ující scény. Dominantním prvkem je samotný canvas, na kterém se zobrazuje modelovaná scéna, ten vlevo sousedí s paletou nabízených roz²í°ení, které lze do scény umístit, dole je pás s aktivními markery a vpravo jsou to ovládací prvky, pomocí kterých lze nastavovat aktivní roz²í°ení. B¥hem testování jsem si ov¥°il domn¥nku, ºe uºivatelé z cílové skupiny budou mít problémy s pochopením klasických technik rotace 3D model· pomocí my²i. Jedná se o metody, kdy je model otá£en podle trajektorie ukazatele my²i na obrazovce. Testoval jsem dva hojn¥ vyuºívané p°ístupy, první (obr. 4.2) umoº¬uje otá£et modelem ve v²ech sm¥rech (XYZ), záleºí p°itom p°eváºn¥ na poloze kurzoru my²i v·£i st°edu a nato£ení modelu, nap°íklad pro oto£ení modelu v základní poloze, kdy osa X sm¥°uje horizontáln¥, osa Y vertikáln¥ a osa Z ukazuje na uºivatele, kolem osy X, je nutné my²í pohybovat vertikáln¥ p°esn¥ uprost°ed otá£eného modelu. Participanti u tohoto p°ístupu nedokázali °íct, jak se bude model otá£et 19
20
KAPITOLA 4.
NÁVRH
Obrázek 4.1: Editor papírový prototyp
a prakticky pouze pohybovali my²í do doby, neº se jim model nato£il alespo¬ £áste£n¥ do polohy, do jaké ho cht¥li p·vodn¥ nastavit. Druhý zp·sob (obr. 4.3), který jsem testoval, umoº¬uje p°i pohybu my²í otá£et model pouze ve dvou sm¥rech, op¥t je ale nato£ení ovlivn¥no výchozím nato£ením modelu, av²ak jiº není d·leºité, kde se nachází st°ed objektu. U tohoto p°ístupu je jiº oto£ení modelu v základní poloze kolem osy X o hodn¥ jednodu²²í, sta£í pouze my²í vytvo°it vertikální pohyb. Participanti si ov²em ani u tohoto principu nev¥d¥li moc rady a op¥t se jednalo spí²e o náhodné pohyby my²í. Testováním jsem tedy zjistil, ºe b¥ºn¥ pouºívané techniky nejsou pro tento ú£el vhodné, zvlá²t¥ kdyº jsou zaloºeny na vertikálních, £i horizontálních pohybech, které je velmi obtíºné pomoci my²i vytvo°it. Navrhl jsem tedy zp·sob natá£ení zaloºený na trojici slider·, které model natá£í kaºdý v jednom sm¥ru (XYZ). Tento zp·sob jsem vyuºil jak pro ovládání náhledu na scénu (polohu kamery), tak i na samostatná roz²í°ení vloºená do scény. 4.1.2
Mobilní £ást
U návrhu mobilní aplikace jsem vycházel z praktických zku²eností s aplikacemi podobného typu. Hlavní obrazovka (obr. 4.4) je tvo°ena, jak uº tomu u aplikací tohoto typu bývá zvykem, náhledem fotoaparátu, tedy scénou, kde se odehrává roz²i°ování reality. Dále jsem usoudil, ºe by bylo vhodné uºivateli p°i spu²t¥ní aplikace zobrazit krátký návod jak aplikaci pouºívat (obr. 4.4). Navzdory doporu£ení Android guidlines [4] jsem se rozhodl zobrazovat návod p°i kaºdém spu²t¥ní a to zejména proto, ºe AR aplikace nejsou tak hojn¥ vyuºívané a jejich nej£ast¥j²ím uºitím je p°edvedení dal²ímu uºivateli. Zobrazený
4.2.
EXPORT MOBILNÍ APLIKACE
21
Obrázek 4.2: Koncept otá£ení modelu pomocí my²i. Ovládání je závislé na nato£ení modelu a trajektorii ukazatele my²i v·£i st°edu modelu.
Obrázek 4.3: Koncept otá£ení modelu pomocí my²i. Ovládáno je nato£ení pouze ve dvou osách.
návod také pom·ºe p°ekrýt £as pot°ebný k inicializaci prost°edk· samotné aplikace, který je u AR aplikací velmi dlouhý. Abych splnil softwarový poºadavek RF-M1 a umoºnil uºivateli zobrazit podporované markery, navrhl jsem jednoduchou galerii (obr. 4.4), do které uºivatel p°ejde pomocí gesta p°ejetí prstem od pravého okraje displeje sm¥rem k levému, takzvaný swipe. Tento zp·sob je v systému Android hojn¥ vyuºíván, proto p°edpokládám, ºe s ním uºivatelé nebudou mít váºn¥j²í problémy.
4.2
Export mobilní aplikace
Jeden ze softwarových poºadavk·, konkrétn¥ poºadavek RF-C1 dopln¥ný nefunk£ním poºadavkem RN-M1, vyºaduje, aby nástroj umoº¬oval generování samostatné mobilní aplikace pro mobilní opera£ní systém Android. To krom¥ samotné funkce vytvo°ení instala£ního balíku aplikace, tedy v p°ípad¥ systému Android balíku APK, znamená i dal²í funkce, které
22
KAPITOLA 4.
NÁVRH
Obrázek 4.4: Mobilní aplikace papírový prototyp. Zleva fotoaparát, nápov¥da a galerie marker·
u generované aplikace nastaví pot°ebné parametry tak, aby bylo moºné takovouto aplikaci poté nahrát do za°ízení a p°ípadn¥ i publikovat do n¥kterého z obchod· s mobilními aplikacemi. U aplikací systému Android se jedná o následující parametry.
Balík aplikace Balík slouºí jako identi kátor aplikace samotné, nelze tedy vytvo°it dv¥
aplikace se stejným balíkem, pokud se tak stane, jsou aplikace povaºovány za totoºné a dal²í kroky jsou °ízeny dal²ími parametry.
Podpis aplikace Kaºdá aplikace na platform¥ Android je podepsána pomocí vývojá°ova
certi kátu. Jedná se o nepopiratelný d·kaz, ºe daná aplikace pochází od vlastníka tohoto certi kátu. Tímto je nap°íklad z£ásti zabrán¥no podvrhnutí fale²né aplikace1 . Pokud se vyskytne kon ikt balík· dvou aplikací, p°echází se na kontrolu jejich podpis·. Pokud se podpisy shodují, jedná se o totoºnou aplikaci a postupuje se k dal²ím parametr·m. Pokud jsou podpisy aplikací rozdílné, jedná se o bezpe£nostní riziko a za originál je povaºována star²í aplikace, coº v p°ípad¥ za°ízení znamená ta d°íve nainstalovaná a v p°ípad¥ obchod· s mobilními aplikacemi ta d°íve registrovaná.
Verze Verze aplikace je na platform¥ Android ur£ena dvojicí kód a název. Název je textový
°et¥zec a lze do n¥j vloºit prakticky cokoliv, tento údaj není nijak speciáln¥ zpracováván. Druhý z dvojice, tedy kód, je £íslo, které ur£uje verzi pro pot°eby porovnávání dvou aplikací.
Pokud uºivatel dodrºuje zásady bezpe£nosti a instaluje aplikace pouze z prov¥°ených zdroj· jako je nap°íklad Google Play 1
4.2.
EXPORT MOBILNÍ APLIKACE
23
Toto £íslo musí být v¥t²í neº nula a jeho hodnota musí vºdy stoupat. Pokud tedy nap°íklad se vyskytnou dv¥ aplikace, které mají stejný balík, jsou podepsány stejným certi kátem, tak aby do²lo k jejich updatu, musí mít nová aplikace vy²²í kód verze neº aplikace p·vodní. Tento kód je kontrolován jak v za°ízeních, tak i v obchodech s aplikacemi.
Název aplikace N¥které obchody s aplikacemi p°i registraci aplikace nové vyºadují i uni-
kátní název aplikace, to p°edev²ím proto, aby se uºivatel·m daná aplikace lépe vyhledávala a nedocházelo k jejich zám¥nám vlivem stejného názvu. Aby bylo generování aplikace pro uºivatele co nejsnaz²í, rozhodl jsem se n¥které vý²e zmín¥né parametry pro kaºdý projekt generovat automaticky. Jedná se nap°íklad o název balíku, který budu ve svém nástroji generovat ze statického základu a názvu aplikace. Verzi aplikace budu pro kaºdé generování daného projektu inkrementovat, pokud tedy bude uºivatel pro danou aplikaci vyuºívat stále stejný projekt, nem·ºe ke kon iktu dojít. Díky tomuto p°ístupu bude zapot°ebí od uºivatele získat pouze n¥kolik málo informací, název aplikace, ikonu aplikace, název verze a certi kát. Pro jejich získání jsem navrhl pr·vodce, který ve²keré zadané údaje bude validovat a uºivateli maximáln¥ samotné generování aplikace uleh£í. Návrh pr·vodce si m·ºete prohlédnout na obrázku obr. 4.5.
24
KAPITOLA 4.
NÁVRH
Obrázek 4.5: Wireframe owchart zobrazující návrh pr·vodce exportem aplikace
Kapitola 5
Implementace V kapitole Implementace popisuji vybrané st¥ºejní bloky implementa£ní £ásti této práce. Tato kapitola se stejn¥ jako samotná implementace d¥lí na dv¥ £ásti, £ást mobilní, ve které je popsána mobilní aplikace, která slouºí jako základ pro generování výsledné aplikace a £ást desktopovou, kde je popsána implementace samotného desktopového nástroje. 5.1
Mobilní £ást
Jedná se o zdrojové kódy mobilní aplikace ur£ené pro opera£ní systém Android, která slouºí jako základ generovaných aplikací prost°ednictvím editoru, jehoº implementace je popisována v druhé £ásti této kapitoly. Samotný kód mobilní aplikace obsahuje logiku marker based roz²i°ování reality, tedy principu, který ve snímané scén¥ detekuje marker a pomocí jeho polohy se orientuje ve scén¥. P°i úsp¥²né detekci markeru jsou poté do scény vykreslovány p°íslu²ná roz²í°ení. Jelikoº je kód aplikace vyuºíván jako základ pro generování aplikací, musí být schopen co nejsnadn¥ji p°ijmout nový obsah, tedy nau£it se rozeznávat nové markery a vykreslovat de novaná roz²í°ení scény. Obsah (markery a roz²í°ení) je do kódu p°idáván b¥hem generování aplikace. Na obrázku obr. 5.1 je vid¥t koncept funk£nosti vygenerované mobilní aplikace. Kroky, které vedly k tomuto °e²ení, jsou podrobn¥ji popsány níºe v jednotlivých sekcích této kapitoly. 5.1.1
Výb¥r AR engine
Samotný vývoj celého °e²ení jsem za£al implementací marker based roz²í°ené reality pro mobilní platformu Android. Nejprve jsem experimentoval s vlastním °e²ením implementovaným pomocí oblíbené open source knihovny pro zpracovávání obrazu, knihovny OpenCV1 . Tato knihovna mne zaujala p°edev²ím svým obsahem, jelikoº obsahuje implementaci nejznám¥j²ích algoritm· pouºívaných p°i zpracovávání obrazu, implementuje vhodné datové struktury pro obrazové materiály a´ uº ve form¥ videa, £i statických obrázk· a navíc má kolem sebe ohromnou komunitu, která je vºdy p°ipravena poradit s p°ípadnými problémy. OpenCV má 1
OpenCV
25
26
KAPITOLA 5.
IMPLEMENTACE
Obrázek 5.1: Koncept funk£nosti mobilní aplikace. Zelen¥ jsou znázorn¥ny implementované £ásti, ²ed¥ vyuºité knihovny t°etích stran, bíle standardní sou£ásti Android SDK.
vlastní originální wrapper pro platformu Android, tudíº je její vyuºití pro vývoj mobilních aplikací pod platformou Android velmi jednoduché. Vlastní °e²ení zaloºené na hledání lokálních features, jak je stru£n¥ popsáno v sekci 2.3.2, ani po zna£ných optimalizacích nedosahovalo poºadovaného výkonu, který je vymezen nefunk£ním poºadavkem RN-M2. Zpracování jednoho snímku se v pr·m¥ru pohybovalo kolem 100 ms a to i na moderních výkonných mobilních za°ízeních, coº v d·sledku zp·sobovalo p°ekreslení obrazovky pr·m¥rn¥ desetkrát za vte°inu. Usoudil jsem tedy, ºe bude výhodn¥j²í vyuºít n¥které z jiº hotových °e²ení, které je pln¥ optimalizováno pro b¥h na mobilních za°ízeních a jejich procesorech. Vybral jsem nejznám¥j²í a nejvíce pouºívané knihovny (vycházel jsem z ohlas· na diskuzních fórech a z £lánk· zabývajících se mobilní AR tématikou), které implementují marker based roz²í°enou realitu pro platformu Android a rozhodl jsem se je vzájemn¥ porovnat a na základ¥ nam¥°ených výsledk· vybrat °e²ení, které budu dále pouºívat. Vybrané knihovny zahrnují jak open source °e²ení, tak i bezplatná °e²ení s uzav°eným vývojem, £i £ist¥ komer£ní projekty.
5.1.1.1 AndAR Originální AR projekt pro implementaci marker based roz²í°ené reality na platform¥ Android. AndAR je zaloºen na Open Source knihovn¥ ARToolKit2 , kterou obaluje a pomocí Java Native Interface (JNI)[12] p°evádí její rozhraní do jazyka Java, který je základním programovacím jazykem na platform¥ Android. AndAR je díky ARToolKitu schopen rozeznanou scénu kombinovat s objekty vykreslenými pomocí OpenGL.
• Stránky projektu
• Licence 2
ARToolKit
5.1.
MOBILNÍ ÁST
27
AndAR je stejn¥ jako samotný ARToolKit dvojit¥ licencovaný. Lze vybírat mezi GNU GPL v3 a komer£ní licencí od rmy ARToolworks.
• Programovací jazyk
Java • Dal²í nutné znalosti
Android SDK OpenGL • Výhody
Open Source Java • Nevýhody
Od roku 2010 mrtvý projekt 5.1.1.2 DroidAR P·vodn¥ Android framework ur£ený pouze pro location based roz²í°enou realitu. Postupem £asu ale p°ibyla i marker based roz²í°ená realita, která je ov²em podle dokumentace stále ve fázi vývoje. DroidAR pro detekci markeru vyuºívá klonu knihovny OpenCV.
• Stránky projektu
• Licence
GNU GPL v3 • Programovací jazyk
Java C/C++ • Dal²í nutné znalosti
Android SDK OpenGL • Výhody
Open Source Java • Nevýhody
Prozatím pouze preview
28
KAPITOLA 5.
IMPLEMENTACE
5.1.1.3 Metaio SDK SDK od jiº d°íve p°edstaveného výrobce, který pat°í mezi sv¥tové leadery v oblasti roz²í°ené reality. Metaio SDK je krom¥ mobilní platformy Android poskytováno také pro mobilní platformu iOS a desktopové OS Windows a Mac OS X. SDK krom¥ detekce 2D marker· umí rozeznávat i sloºit¥j²í 3D markery a mapy.
• Stránky projektu
• Licence
Komer£ní Výrobce poskytuje SDK v bezplatné verzi, která má jistá omezení a výsledná aplikace obsahuje watermark s logem výrobce.
• Programovací jazyk
Java • Dal²í nutné znalosti
Android SDK • Výhody
Java Moºnost 3D marker· Spojení s metaio Creatorem Podpora Unity 3D Velké mnoºství dopl¬kových sluºeb
• Nevýhody
Pro plnou funk£nost nutné zakoupit licenci Uzav°ený vývoj SDK 5.1.1.4 Vuforia SDK vyvíjeno p°edním výrobcem hardware pro mobilní telefony, rmou Qualcomm. Vuforia SDK, d°íve také QCAR, bylo od po£átku vyvíjeno jako AR SDK pro mobilní za°ízení s OS Android, SDK je pln¥ optimalizováno pro b¥h na ARM procesorech, zvlá²t¥ pak na procesorech od rmy Qualcomm. V sou£asnosti je Vuforia dostupná jak pro Android, tak i pro iOS. Vuforia pak také vyniká bezproblémovou integrací s herním 3D enginem Unity 3D.
• Stránky projektu
5.1.
MOBILNÍ ÁST
29
• Licence
Komer£ní Výrobce poskytuje SDK zdarma bez jakýchkoliv omezení, zpoplat¬uje pouze dopl¬kové sluºby
• Programovací jazyk
Java C/C++ • Dal²í nutné znalosti
Android SDK Android NDK OpenGL • Výhody
Moºnost 3D marker· Moºnost OCR Runtime vytvá°ení marker· Podpora Unity 3D Velké mnoºství dopl¬kových sluºeb
• Nevýhody
Uzav°ený vývoj SDK Vlastní marker je nutné vytvá°et online, runtime markery nelze uloºit 5.1.1.5 Wikitude SDK Firma Wikitude, jak jsem jiº psal d°íve, pat°í mezi p°ední odborníky na roz²í°enou realitu ve sfé°e mobilních telefon·. A tak není divu, ºe i wikitude má své SDK, za jehoº pomoci lze vytvá°et AR marker based nativní mobilní aplikace. SDK je siln¥ zam¥°eno na multiplatformní vývoj. Celá logika aplikace je popsána za pomoci JavaScriptu a ten je posléze za pomoci platform¥ závislých knihoven interpretován. Díky tomuto je moºné velmi snadno p°evád¥t AR £ást aplikace mezi platformami (Android, iOS, Windows Phone, HTML 5).
• Stránky projektu
• Licence
Komer£ní
30
KAPITOLA 5.
IMPLEMENTACE
Výrobce poskytuje trial verzi, která omezuje funkce SDK a výsledná aplikace obsahuje watermark
• Programovací jazyk
Java JavaScript • Dal²í nutné znalosti
Android SDK • Výhody
Z £ásti multiplatformní vývoj • Nevýhody
Uzav°ený vývoj SDK Pro plnou funk£nost nutné zakoupit licenci 5.1.1.6 Porovnání výkonu Jako metodu porovnání výkonu zde p°edstavených °e²ení jsem vybral m¥°ení po£tu snímk·, které je dané °e²ení schopné vykreslit za jednu vte°inu (FPS).
Nastavení testu
Vytvo°il jsem aplikaci pro kaºdé zde p°edstavené °e²ení, která rozeznává marker a ve výsledné scén¥ jej p°ekrývá pomocí £erveného £tverce. Jelikoº kaºdé °e²ení pouºívá jiný zp·sob rozeznávání markeru, rozhodl jsem se v aplikacích ponechat demo markery kaºdého °e²ení, aby nedocházelo ke sníºení jejich výkonu vlivem ²patn¥ zvoleného markeru. Aplikace jsem dále upravil tak, aby po£ítaly kaºdé vykreslení roz²í°ené scény a za pomoci této informace vypo£ítávali hodnotu FPS. Testování jsem provád¥l na trojici mobilních za°ízení, která pokrývají dnes b¥ºn¥ pouºívané p°ístroje.
Sony Ericsson Xperia PRO • OS: Android 4.0.4 (Ice Cream Sandwich) sestavení 4.1.B.0.587 • Procesor: Qualcomm MSM8255 1 GHz • Pam¥´: 512 MB RAM • Rozli²ení displeje: 480 x 854 • Gra cký £ip: Adreno 205 • Fotoaparát: 3 264 x 2 448, Auto Focus, Zadní
5.1.
31
MOBILNÍ ÁST
Asus Nexus 7 • OS: Android 4.4.2 (KitKat) sestavení KOT49H • Procesor: Nvidia Tegra 3 T30 4x1,3 GHz • Pam¥´: 1 024 MB RAM • Rozli²ení displeje: 800 x 1 280 • Gra cký £ip: Nvidia Tegra 3 T30 • Fotoaparát: 1 280 x 1 024, Fixed Focus, P°ední
LG Nexus 4 • OS: Android 4.4.2 (KitKat) sestavení KOT49H • Procesor: Qualcomm APQ8064 4x1,5 GHz • Pam¥´: 2 048 MB RAM • Rozli²ení displeje: 768 x 1 280 • Gra cký £ip: Adreno 320 • Fotoaparát: 3 264 x 2 448, Auto Focus, Zadní Testy byly provád¥ny za konstantního sv¥tla o hodnot¥ cca 240 Lux. Jednotlivé markery byly zobrazovány pomocí monitoru. Nam¥°ené hodnoty FPS jsou pr·m¥r vytvo°ený b¥hem jedné minuty.
Test 1 M¥°ení hodnoty FPS b¥hem snímání statické scény s markerem
P°ístroj se spu²t¥nou aplikací snímal statickou scénu, ve které byl zobrazen marker. Za°ízení snímalo scénu ze stojanu umíst¥ného ve vzdálenosti jeden metr od markeru. AndAR DroidAR Metaio SDK Vuforia Wikitude SDK
Sony Ericsson Xperia PRO 6,07 17,8 19,9 30,5 18,4
Asus Nexus 7 nelze spustit nelze spustit nelze spustit 30,7 nelze spustit
LG Nexus 4 21,3 nelze detekovat marker 52,0 21,7 30,1
Tabulka 5.1: Nam¥°ené hodnoty FPS pro Test 1 M¥°ení hodnoty FPS b¥hem snímání statické scény s markerem Nam¥°ené hodnoty naleznete v tabulce 5.1. Z výsledk· lze vy£íst, ºe komer£ní produkty mají p°ed t¥mi vedenými jako open source velký náskok. Zajímavé výsledky lze pozorovat u knihovny Vuforia, která byla na slab²ím hw schopna b¥ºet rychleji neº na hw, který má vy²²í výkon. Nejspí²e se jedná o n¥jakou nekompatibilitu knihovny s nov¥j²ími £ipy od samotného tv·rce knihovny, rmy Qualcomm. Na druhou stranu, knihovna vuforia byla jako jediná schopna b¥ºet i na za°ízení, které má k dispozici pouze p°ední kameru.
32
KAPITOLA 5.
IMPLEMENTACE
Test 2 M¥°ení hodnoty FPS b¥hem snímání dynamické scény s markerem
P°ístroj se spu²t¥nou aplikací snímal scénu, ve které se dynamicky pohyboval marker. Pohyb markeru byl konstantní, náhodný, ale vºdy v rámci snímané scény, nedo²lo tedy nikdy ke skrytí markeru. Za°ízení snímalo scénu ze stojanu umíst¥ného ve vzdálenosti jeden metr od markeru. AndAR DroidAR Metaio SDK Vuforia Wikitude SDK
Sony Ericsson Xperia PRO 5,66 (O) 16,7 (S) 19,4 (S) 30,5 18,7 (Z)
Asus Nexus 7 nelze spustit nelze spustit nelze spustit 30,5 nelze spustit
LG Nexus 4 21,5 (S) nelze detekovat marker 51,4 21,8 29,4 (Z)
Tabulka 5.2: Nam¥°ené hodnoty FPS pro Test 2 M¥°ení hodnoty FPS b¥hem snímání dynamické scény s markerem (O = opoºd¥né vykreslování v·£i fotoaparátu, S = skákání vykreslované scény, Z = £astá ztráta detekovaného markeru)
Hodnoty nam¥°ené p°i druhém testu si m·ºete prohlédnout v tabulce 5.2. Výsledky druhého testu se nijak radiáln¥ neli²í od výsledk· testu prvního. Lze tedy °íci, ºe pohybující se marker nemá na výkon zde testovaných °e²ení vliv. Av²ak tento test odhalil jiné problémy a to r·zné poskakování markeru ve scén¥, zpoºd¥ní detekované scény za obrazem z fotoaparátu, £i £asté ztráty detekovaného markeru. N¥které neduhy byly pozorovány pouze na za°ízení se slab²ím HW, n¥které v²ak p°etrvaly i na hw siln¥j²ím. Jediné °e²ení, u kterého nebylo pozorováno ºádné podivné chování je °e²ení Vuforia.
5.1.1.7 Výsledek Na základ¥ výsledk· test· jsem jako engine pro marker based roz²í°enou realitu vybral knihovnu Vuforia, která na v²ech za°ízeních dosahovala pot°ebného výkonu, ukázala se jako nejv²estrann¥j²í, kdyº jako jediná dokázal b¥ºet i na za°ízení s p°ední kamerou a celkov¥ na mne p·sobila nejlep²ím dojmem, co se výsledného efektu roz²í°ení reality tý£e. Knihovna Vuforia je poskytována zdarma a to i pro komer£ní ú£ely, její vyuºití si nevyºaduje ºádné speciální zásahy do aplikace, jako jsou nap°íklad splash, watermarky a podobn¥, coº povaºuji za její dal²í výhodu. 5.1.2
P°izp·sobení AR engine
Jak jsem se jiº zmínil p°i p°edstavení knihovny Vuforia, vytvá°ení vlastních marker· je moºné pouze prost°ednictvím webového nástroje Target Manager, coº je v rozporu se softwarovým poºadavkem RF-C2, který pravý, ºe desktopová £ást musí být schopna sama vytvo°it marker z libovolného obrázku a zhodnotit jeho kvalitu. Abych obe²el nutnost vytvá°et markery prost°ednictvím webového nástroje, vyuºil jsem jiné vlastnosti knihovny Vuforia a sice toho, ºe knihovna umí vytvá°et markery za b¥hu z obrazu snímaného fotoaparátem, takzvané User De ned Targets (UDT). Nevýhodou takto
5.1.
MOBILNÍ ÁST
33
vytvo°ených marker· je fakt, ºe v sou£asnosti je nelze ukládat a tudíº jsou dostupné pouze po dobu b¥hu aplikace. Knihovna Vuforia pracuje v jednoduché smy£ce, kdy vytvo°í snímek scény pomocí fotoaparátu, pokusí se vyhledat markery a spustí p°ekreslení zobrazované scény. Pokud po knihovn¥ poºadujete vykonání n¥jakého nadstandardního p°íkazu, jako je v na²em p°ípad¥ nap°íklad vytvo°ení UDT, je tento p°íkaz proveden p°i nejbliº²ím pr·chodu touto smy£kou. Knihovna dále rozli²uje mezi markery aktivními a neaktivními. Ve scén¥ jsou vºdy vyhledávány pouze aktivní markery. Knihovna také umí vracet aktuáln¥ zpracovaný snímek z kamery. V²echny tyto vlastnosti, spolu se zku²enostmi s vlastním marker based AR enginem, mi pomohli vytvo°it zp·sob, pomocí kterého jsem schopen detekovat libovolný marker ve scén¥ pouze podle jeho obrazové p°edlohy a vyuºít p°itom výkonu knihovny Vuforia pro roz²i°ování reality. Celý proces registrace markeru se poté dá ve stru£nosti popsat takto. Na za£átku je spu²t¥na základní smy£ka knihovny Vuforia, která neobsahuje ºádný marker, dále je vyºádáno vytvo°ení UDT a dotaz na aktuáln¥ zpracovávaný obraz z fotoaparátu. Nov¥ vytvo°ený marker je nastaven jako neaktivní a zpracovaný obraz fotoaparátu je p°edán funkci, která se v n¥m pokusí detekovat registrované markery podle jejich obrazové p°edlohy. Zatímco je obraz z fotoaparátu zpracováván, základním smy£ka knihovny Vuforia b¥ºí dál, tudíº uºivatel nepozoruje ºádné sníºení výkonu. Po dokon£ení analýzy obrazu z fotoaparátu je bu¤ vytvo°ený marker zni£en, £i aktivován, to v p°ípad¥, ºe byl v obraze nalezen n¥který z registrovaných marker·. Pokud po skon£ení tohoto cyklu existují je²t¥ nedetekované markery, celý proces se opakuje.
5.1.2.1 Detekce markeru podle obrazové p°edlohy P°i detekci markeru podle obrazové p°edlohy jsem vyuºil jiº popsaný princip porovnávání lokálních feature deskriptor· dvou obrázk·, který jsem zmínil p°i p°edstavení marker based roz²í°ené reality v sekci 2.3.2. Jako základ jsem pouºil knihovnu OpenCV, která obsahuje jiº n¥kolik optimalizovaných implementací feature detektor· a extraktor·. Abych vybral nejvhodn¥j²í dvojici feature detektor a extraktor pro implementaci, rozhodl jsem se vybrané algoritmy vzájemn¥ porovnat. Pro pot°eby srovnání jsem vytvo°il mobilní aplikaci, ve které jsem pomocí porovnávání lokálních feature deskriptor· hledal jeden obrázek v kontextu druhého, tedy jinak °e£eno marker ve scén¥. P°i porovnávání jsem se soust°edil p°edev²ím na £asovou náro£nost a p°esnost detekce, coº jsou z hlediska zamý²leného vyuºití dva st¥ºejní parametry. Rychlost algoritmu jsem m¥°il jako £as pot°ebný pro vytvo°ení mnoºiny kvalitních feature deskriptor· pro kaºdý z porovnávaných obrázk·, tedy jak pro marker, tak i pro scénu, vzájemné porovnání nalezených deskriptor· a nalezení sou°adnic markeru ve scén¥. Zbytek algoritmu byl pro v²echny p°ípady stejný, proto nem¥lo cenu jej do porovnání zahrnovat. M¥°ený £as se týkal pouze samotného výpo£tu, inicializace byla z m¥°eného úseku vyjmuta. P°esnost jsem se rozhodl m¥°it jako odchylku polohy detekovaného markeru ve scén¥ od jeho reálné polohy. Odchylku jsem po£ítal jako pr·m¥r vzdáleností nalezených roh· markeru v·£i p°edem zm¥°eným reálným hodnotám. Rohy detekovaného markeru jsem získával pomocí vypo£ítané homogra e[10] z porovnávaných lokálních feature deskriptor·.
34
KAPITOLA 5.
IMPLEMENTACE
Jako vstup aplikace pouºívala dvojici obrázk·, jeden obrázek slouºil jako marker, druhý jako scéna. Pro testování jsem pouºíval trojici marker· s tím, ºe jsem pro kaºdý marker vytvo°il n¥kolik r·zných scén viz obr. 5.2, ve kterých byl marker umíst¥n s následujícími parametry.
• Zmen²ený marker dopln¥ný bílým ráme£kem (size) • Marker s upraveným kontrastem na 150% dopln¥ný bílým ráme£kem (contrast+) • Marker s upraveným kontrastem na 50% dopln¥ný bílým ráme£kem (contrast-) • Perspektivn¥ nato£ený marker dopln¥ný bílým ráme£kem (perspective) Jako testovací za°ízení jsem vyuºil Asus Nexus 7.
Obrázek 5.2: Ukázka vstup· pro test features detektor· a extraktor·. Po sloupcích zleva marker, size, contrast+, contrast-, perspective Pro testování jsem vybral £tve°ici kombinací detektor extraktor, jiné kombinace jsem nebyl schopen na mobilních za°ízeních zprovoznit, £i jejich výstup byl natolik ²patný, ºe je nem¥lo smysl do tohoto testu zahrnovat.
• ORB • BRISK • FAST FREAK • MSER FREAK
FAST FAST je samostatný feature detektor. Features hledá pomocí detekce roh·, kdy
kolem podez°elého pixelu vytvo°í kruºnici skládající se z 16 pixel· a porovnává jejich sv¥tlost v·£i podez°elému pixelu. Podrobnosti [7].
5.1.
MOBILNÍ ÁST
35
ORB ORB je detektor i extraktor, který t¥ºí p°edev²ím ze své implementa£ní nenáro£nosti
a je p°eváºn¥ pouºíván na mén¥ výkonných za°ízeních. ORB je v podstat¥ takové vylep²ení a oºivení jiº d°íve popsaných metod. Jako základ pro detektor je pouºit jiº zmi¬ovaný FAST a jako základ pro extraktor je vyuºit princip BRIEF, který k popisu features vyuºívá binární °et¥zce, coº má za následek moºnost velmi rychlého porovnávání feature deskriptor·. Více o ORB viz [8].
BRISK BRISK je také jak feature detektor, tak i extraktor. Stejn¥ jako ORB, i BRISK
vychází z metody FAST. BRISK ov²em ke klasické FAST metod¥ p°idává i hledání features pomocí scale-space teorie, tedy postupu, p°i kterém se pomocí zm¥ny m¥°ítka potla£ují vysokofrekven£ní sloºky signálu, aby se mohlo lépe pracovat se sloºkami nízkofrekven£ními. U obrázk· to lze provád¥t nap°íklad op¥tovnou aplikací gaussovského rozost°ení, která funguje jako nízkofrekven£ní ltr. Více o metod¥ BRISK viz [27]
MSER MSER je samostatný feature detektor, který je na rozdíl od ostatních zde p°edstavených detektor· zaloºen na hledání region· s maximální stabilitou. Maximáln¥ stabilní regiony MSER vyhledává metodou, kdy nad £ernobílým obrázkem postupn¥ provádí thresholding3 s rostoucí hodnotou za ú£elem vytvá°ení binárních4 obrázk·. Za maximáln¥ stabilní region jsou poté povaºovány ty £ásti obrázku, které se objeví v ur£itém procentu výsledk· thresholdu v tém¥° nezm¥n¥né podob¥. Více o implementaci MSER viz [9]. FREAK FREAK je samostatný feature extraktor. FREAK je zaloºen na podobném principu jako BRISK extraktor, ov²em v p°ípad¥ metody FREAK je tento princip upraven podle modelu sítnice v lidském oku. Více o FREAK extraktoru viz [2].
Time (ms) Di (px) Time (ms) BRISK Di (px) Time (ms) FAST - FREAK Di (px) Time (ms) MSER - FREAK Di (px) ORB
size contrast+ contrastperspective m1 m2 m3 m1 m2 m3 m1 m2 m3 m1 m2 m3 306 335 307 328 361 312 318 362 337 310 362 310 0,22 0,93 0,65 1,75 2,26 0,38 0,51 1,09 6,97 8,42 2,96 1,79 150 294 148 171 256 133 118 262 133 160 427 169 n/a n/a 0,76 2,02 0,17 0,41 4,02 0,29 0,31 n/a n/a n/a 803 2938 289 309 5687 229 250 5672 232 646 8882 432 n/a 215,08 n/a 0,03 1,20 0,05 1,28 0,30 0,04 4,65 9,66 3,70 1551 1562 958 1250 1456 856 1142 1444 860 1513 1915 1156 0,41 1,15 0,62 0,51 0,87 0,18 0,82 1,16 0,15 0,93 1,28 0,37
Tabulka 5.3: Výsledky porovnání feature detektor· a extraktor· na mobilním za°ízení s OS Android Výsledky testu jsou znázorn¥né v tabulce 5.3. Z výsledk· lze vy£íst, ºe nejrychleji si na testovacích obrázcích vedl feature detektor a extraktor BRISK, ov²em jeho p°esnost nebyla nejlep²í, zvlá²t¥ pak p°i detekci perspektivn¥ nato£eného, £i zmen²eného markeru, kdy jej Úprava obrázku, p°i které jsou ve²keré pixely s hodnotou v¥t²í neº zadaná mez p°evedeny do sv¥tlé barvy a ty s men²í hodnotou zase naopak do tmavé barvy 4 Obrázek, který obsahuje pouze dvojici barev £erná bílá, takový obrázek poté m·ºe být reprezentován pouze za pomoc bit· 3
36
KAPITOLA 5.
IMPLEMENTACE
nedokázal najít v·bec. Naopak v p°esnosti si nejlépe vedla kombinace feature detektoru MSER a extraktoru FREAK, jehoº detekované polohy markeru se li²ily maximáln¥ o 1,28 pixelu od skute£nosti, ov²em doba jeho b¥hu málokdy spadla pod jednu vte°inu. V kombinaci obou hledisek, tedy rychlosti a p°esnosti, si nejlépe vedla metoda ORB, kterou jsem také zvolil jako feature detektor a extraktor do mého °e²ení. ORB dokázalo na v²ech obrázcích b¥ºet tém¥° konstantní rychlostí, cca 330 ms a jeho p°esnost, kdy se jím detekovaný marker odchýlil maximáln¥ o 8,42 pixelu od skute£nosti, coº je v·£i rozm¥r·m testovacích obrázk· p°esnost zhruba 98,6%, povaºuji za dostate£nou.
5.1.2.2 Vykreslování roz²í°ení Knihovna Vuforia pro vykreslování roz²í°ené scény vyuºívá standardu OpenGL, v p°ípad¥ mobilních za°ízení pak spí²e podmnoºiny OpenGL ES. Roz²í°ení jsou vykreslována pomocí standardních technik OpenGL, tedy jako modely sestavené pomocí primitiv (bod, úse£ka, trojúhelník, mnohoúhelník, . . . ), které se de nují pomocí sou°adnic jednotlivých vrchol· a jejich dat (barva, normála, sou°adnice textur, . . . ). Sou°adnice vrchol· se u OpenGL de nují pomocí trojice £ísel, které ur£ují jejich polohu v 3D prostoru, bod s nulovými sou°adnicemi leºí vºdy uprost°ed modelované scény, v p°ípad¥ Vuforie poté uprost°ed markeru. Dále pak marker svou ²í°kou ur£uje m¥°ítko scény a to tak, ºe p°i vytvá°ení markeru se ur£í jeho ²í°ka v bodech, tuto ²í°ku poté daný marker respektuje v prost°edí OpenGL. Znamená to tedy, ºe pravý okraj markeru má v prost°edí OpenGL vºdy sou°adnici X rovnou polovin¥ daného rozm¥ru a levý to samé, akorát se záporným znaménkem. Výsledná scéna s roz²í°eními je p°i nálním vykreslování transformována pomocí dvojice matic, které knihovna Vuforia vytvá°í p°i kaºdé detekci markeru v kaºdém snímku kamery tak, aby se vykreslovaná roz²í°ení kryla s reálným sv¥tem. První matice je vytvá°ena pro kaºdý detekovaný marker zvlá²´, jedná se o takzvanou modelview matici, která p°evádí modelové sou°adnice na sou°adnice kamery, tedy posouvá, natá£í a upravuje velikost modelu tak, aby se model ze své základní polohy, která je vztaºena v·£i st°edu scény, dostal na pozici, kterou ur£uje detekovaný marker ve výsledné scén¥. Druhá matice, takzvaná projek£ní matice, je poté spole£ná pro v²echny detekované markery v daném snímku kamery. Tato matice ur£uje, co bude vlastn¥ uºivateli vykresleno na displej, stará se o správnou perspektivu, zorný úhel atd. Více o principech OpenGL a transforma£ních maticích najdete na [11]. Problém v na²em p°ípad¥ nastává p°i vytvá°ení UDT, viz obr. 5.3. Knihovna p°i UDT vytvá°í marker vºdy z celého aktuálního snímku kamery a ve²keré d°íve zmín¥né matice tomu p°izp·sobuje. Výsledné roz²í°ení je tedy poté vºdy vykresleno do st°edu takto vytvo°eného markeru. Abych toto napravil, vypo£ítávám p°i kaºdé vlastní detekci markeru podle obrazového vzoru i opravnou transforma£ní matici, která vykreslovaná roz²í°ení posunuje na správné místo. Tento problém lze °e²it velmi jednodu²e a to vypo£tením transforma£ní matice z následující rovnice A ∗ T = B kde A je matice 4 ∗ 3 a obsahuje sou°adnice £ty° roh· markeru v základní poloze, matice B je také matice 4∗3 a obsahuje sou°adnice roh· markeru detekovaného ve snímku z fotoaparátu, matice T je potom neznámá transforma£ní matice o rozm¥rech 3∗3. Problém ale nastává p°i kombinaci OpenCV a OpenGL, knihovna OpenCV totiº vyuºívá jiný sou°adnicový systém neº OpenGL.
5.1.
MOBILNÍ ÁST
37
Obrázek 5.3: Vuforia vytvá°í UDT vºdy z celého aktuálního snímku (zelen¥), scénu je tedy nutné transformovat pouze na registrovaný marker (£erven¥)
Proto jsem se vyuºil stejn¥ jako u porovnávání feature detektor· a deskriptor· výpo£tu homogra e a sou°adnic roh· detekovaného markeru. Za jejich pomoci jsem vypo£ítal posun kolem os X a Y, posun kolem osy Z ponechávám vºdy nulový, a zm¥nu velikosti. Dále pomocí 3D funkcí knihovny OpenCV vypo£ítávám rotace kolem kaºdé z os. Ve výsledku poté z t¥chto údaj· sestavuji opravnou transforma£ní matici 4∗4 vhodnou pro pouºití v prost°edí OpenGL. Tato opravná matice se poté aplikuje na modelview matici daného markeru a upravuje tak pozici vykreslovaných roz²í°ení.
5.1.3
Parametrizace mobilní aplikace
Mobilní aplikace má slouºit jako základ pro generování aplikací vytvo°ených uºivatelem, z toho d·vodu bylo nutné aplikaci uzp·sobit tomu, ºe ve²kerý její obsah bude n¥jakým zp·sobem generován pomocí desktopového nástroje. Mobilní aplikaci jsem tedy implementoval tak, aby pro vytvo°ení obsahu aplikace nebylo nutné jakkoliv m¥nit její kód. Ve²kerý obsah aplikace je ur£en pomocí obsahu sloºky assets5 . Tento zp·sob jsem zvolil také kv·li tomu, ºe jej velmi snadno lze upravit za ú£elem zm¥n obsahu aplikace pomocí webové sluºby, kdy si je aplikace schopna stáhnout nový obsah z internetu a pracovat s ním bez nutnosti vydávat update celé aplikace. 5
Sloºka, jejíº obsah je v nezm¥n¥né podob¥ p°eved a zabalen do výsledného APK souboru aplikace.
38
KAPITOLA 5.
IMPLEMENTACE
Ve sloºce assets je umíst¥na sloºka s názvem CAnAR, která obsahuje sloºky, které reprezentují jednotlivé markery pouºívané v aplikaci. V kaºdé z t¥chto sloºek je umíst¥n obrázek, který slouºí jako obrazová p°edloha markeru, která se vyuºívá pro jeho detekci ve scén¥ a také pro zobrazení podporovaných marker· uºivateli. Kaºdá marker sloºka dále obsahuje sloºky pro jednotlivá roz²í°ení, které se p°i jeho detekci mají vykreslovat. Pro kaºdé roz²í°ení jedna sloºka. Sloºka pro roz²í°ení poté povinn¥ obsahuje json soubor params.json a dále pak data podle typu daného roz²í°ení. Obsah souboru params.json je stejný pro v²echna roz²í°ení a obsahuje identi kátor typu roz²í°ení plus základní parametry spole£né pro v²echna roz²í°ení, které uºivatel nastavuje prost°ednictvím desktopového nástroje. Následuje ukázka obsahu souboru params.json. 1 2 3 4 5 6 7 8 9 10 11 12
{
" type ": 1000 , " translationX ": 0, " translationY ": 0, " translationZ ": 5, " angleX " : 0, " angleY " : 0, " angleZ " : -90 , " scaleX " : 1.35 , " scaleY " : 1.38 , " scaleZ " : 0.59
}
Aplikace poté p°i kaºdém svém spu²t¥ní na£ítá obsah assets sloºky a parsuje informace o svém obsahu. Krom¥ obsahu samotné roz²í°ené reality, je pot°eba u aplikace umoºnit snadno m¥nit její název, ikonu, balík, verzi atd., coº vesm¥s v²echno lze ud¥lat pouhou zm¥nou hodnoty v manifestu, £i v resources aplikace a není proto zapot°ebí zasahovat do kódu aplikace. Výjimku ov²em tvo°í balík aplikace, pokud dojde k jeho zm¥n¥ v manifestu, p°i p°í²tím buildu dojde i ke zm¥n¥ balíku u generované t°ídy R.java, která obsahuje identi kátory pro p°ístup k resources aplikace. Tato t°ída je importována do tém¥° v²ech ostatních t°íd aplikace. Jelikoº by úprava importu ve v²ech t°ídách byla velmi komplikovaná, p°istoupil jsem k °e²ení, kdy jsem aplikaci rozd¥lil na dv¥ £ásti. Samotnou aplikaci, kde je zdrojový kód a Android knihovnu6 , která obsahuje ve²keré resources. V tomto p°ípad¥ jiº zm¥na balíku není problém, jelikoº se v²echny t°ídy odkazují na R t°ídu a resources z knihovny, u které se balík nem¥ní.
5.2
Desktopová £ást
Desktopová £ást °e²ení slouºí jako nástroj pro tvorbu mobilních aplikací vyuºívajících marker based roz²í°enou realitu. K vytvo°ení mobilní aplikace vyuºívá zdrojové kódy aplikace, jejichº implementace byla popisována v p°edchozích sekcích této kapitoly. Speciální Android projekt, který je ozna£en jako knihovna. Android knihovna, n¥kdy ozna£ována také jako AAR, má oproti klasické JAR knihovn¥ tu výhodu, ºe m·ºe obsahovat i Android resources. 6
5.2.
39
DESKTOPOVÁ ÁST
Nástroj funguje jako jakýsi editor, pomocí kterého uºivatelé upravují scénu pomocí vkládání roz²í°ení. Upravovaná scéna je v editoru znázorn¥na pomocí zvoleného markeru a v podstat¥ p°edstavuje reálnou scénu snímanou pomocí výsledné aplikace, ve které byl detekován marker. Nástroj umí generovat obsah ve formátu, se kterým umí pracovat kód mobilní aplikace zmi¬ovaný v p°edchozích sekcích. Dále je nástroj schopen ze zdrojových kód· vytvo°it instala£ní balík aplikace pro opera£ní systém Android. Nástroj jsem se rozhodl psát v jazyce Java, jelikoº s ním mám nejv¥t²í zku²enosti. Pro implementaci UI jsem vyuºil knihovnu Swing[22], která je v sou£asnosti jiº standardní sou£ásti Java SE. Jako základ nástroje pro úpravu roz²i°ované scény jsem vyuºil projekt JOGL[18], který p°iná²í rozhraní standardu OpenGL do jazyka Java. 5.2.1
Roz²i°ovaná scéna
Samotná úprava roz²i°ované scény je implementována jako jednoduchá OpenGL scéna, ve které je na úrovni osy Z = 0 vykreslen zvolený marker. Dále jsou do scény vykreslována roz²í°ení vloºená uºivatelem. Na rozdíl od markeru je u roz²í°ení uºivateli dovoleno m¥nit jejich pozici, nato£ení a sm¥r viz softwarový poºadavek RF-C4. Zm¥ny lze ale provád¥t pouze u ozna£eného roz²í°ení. Ozna£ení roz²í°ení se provádí pomocí my²i, které je implementováno jako takzvaný Ray Picking (obr. 5.4), tedy princip, p°i kterém je od OpenGL kamery vyslán paprsek ve sm¥ru kurzoru my²i skrze celý OpenGL sv¥t, poté první roz²í°ení, se kterým se tento paprsek na své cest¥ setká je ozna£eno. Výpo£et pr·se£íku mezi paprskem a roz²í°ením je z d·vod· optimalizace rychlosti realizován jako výpo£et pr·se£íku s boxem, orientovaným ve sm¥ru základních os (XYZ), který obaluje celý objekt roz²í°ení. Tento princip n¥kolikanásobn¥ zrychluje výpo£et oproti detekci pr·se£íku pomocí výpo£tu kolize mezi paprskem a jednotlivými primitivy, ze kterých je model sloºený, av²ak m·ºe zp·sobovat jistou nep°esnost, nap°íklad v p°ípad¥, sloºit¥ tvarovaných model·, £i orientace modelu mimo základní osy.
Obrázek 5.4: Ray Picking
40
KAPITOLA 5.
IMPLEMENTACE
Modelovanou scénu si m·ºe uºivatel libovoln¥ natá£et a naklán¥t ve v²ech základních osách prostoru. Tato funkce je realizována jako prostý pohyb OpenGL kamerou, n¥kdy nazývanou jako ViewPoint. Nástroj pro kaºdý marker uchovává vlastní parametry OpenGL scény, není proto problém p°epínat se mezi jednotlivými markery. 5.2.2
Hodnocení kvality marker·
Podle softwarového poºadavku RF-C2 musí nástroj um¥t vytvá°et marker z libovolného obrázku a zhodnotit jeho kvalitu. Vytvá°ení nového markeru z libovolného obrázku není díky implementaci mobilní aplikace ºádný problém, marker sta£í uloºit jako obrázek na správné místo v generované aplikaci. Zbývá tedy hodnocení kvality markeru. Správn¥ by m¥la být kvalita markeru hodnocena ze dvou hledisek, jedním je kvalita markeru, která se týká schopnosti rozeznání pomocí vlastní implementace detekce markeru podle obrazového vzoru, tedy takové hodnocení, které vypo£ítá kvalitu pro ORB feature detektor. Druhým faktorem hodnocení by m¥la být kvalita z hlediska knihovny Vuforia. Ale jelikoº Vuforia je projekt s uzav°eným vývojem a nikde není popsáno jaké features tato knihovna pouºívá, nelze toto hodnocení realizovat. Av²ak Vuforia je natolik robustní °e²ení, ºe je schopna detekovat tém¥° libovolný marker, proto posta£í pouze první zmi¬ované posouzení kvality markeru. Posouzení kvality markeru jsem se rozhodl implementovat podobn¥ jako p°i posuzování kvality feature detektor· a extraktor· v jedné z p°edcházejících sekcí 5.1.2.1 a sice jako odchylku detekovaného markeru od jeho reálné polohy v rozli£ných um¥le vytvo°ených scénách. A sice ve scénách, kde se marker nachází s následujícími parametry
• Zmen²ený marker dopln¥ný bílým ráme£kem • Marker s upraveným kontrastem na 150% dopln¥ný bílým ráme£kem • Marker s upraveným kontrastem na 50% dopln¥ný bílým ráme£kem • Nato£ený marker o 45 stup¬· dopln¥ný bílým ráme£kem • Marker viditelný ze dvou t°etin vylézající z pravého okraje scény • Marker viditelný ze dvou t°etin vylézající z levého okraje scény • Marker viditelný ze dvou t°etin vylézající z horního okraje scény • Marker viditelný ze dvou t°etin vylézající z dolního okraje scény Odchylka markeru je hodnocena jako procentuální rozdíl od maximální povolené odchylky na daném markeru. Tedy nulová odchylka je hodnocena 100% a odchylka, která se rovná, nebo je v¥t²í neº maximální povolená odchylka je hodnocena 0%. Maximální povolená odchylka je vypo£tena jako jedna ²estnáctina nejmen²í strany markeru. Výsledné hodnocení markeru je poté spo£teno jako pr·m¥r z výsledk· test· na v²ech scénách.
5.2.
DESKTOPOVÁ ÁST
5.2.3
41
Export mobilní aplikace
Kombinace softwarových poºadavk· RF-C1 a RN-M1 vyºadují, aby nástroj byl schopen generovat standalone mobilní aplikaci pro platformu Android. Aplikace pro platformu Android jsou distribuovány pomocí instala£ních balí£k·, takzvaných APK (podle koncovky *.apk). Jedná se v podstat¥ o kompresní souborový formát zaloºený na ZIP kompresi, ve kterém jsou obsaºeny kompilované zdrojové kódy v DEX formátu, manifest aplikace, p°eloºené knihovny, resources aplikace, soubory obsahující certi kát a podpisy aplikace atd.[14]. Pro vytvo°ení takovéhoto instala£ního balí£ku je zapot°ebí vykonat n¥kolik krok·. Na za£átku jsou zdrojové kódy napsané v jazyce Java, knihovny ve formátu JAR a p°ípadn¥ i knihovny v nativním kódu (C/C++) p°eloºené pro b¥h na mobilních procesorech, resources aplikace (obrázky, texty, de nice UI obrazovek, . . . ) a manifest aplikace (XML soubor). V prvním kroku je celá aplikace p°eloºena jako klasický Java projekt. Pro kaºdou t°ídu zdrojového kódu je vytvo°en p°íslu²ný p°eklad do bytecode[15]. Který je v dal²ím kroku p°eveden do formátu schopného b¥ºet v prost°edí Dalvik7 , do takzvaného Dalvik Executable Format (DEX) formátu [5]. Pokud je v²e p°eloºeno, je vytvo°en archiv APK, který je následn¥ podepsán certi kátem vývojá°e. Jedná se o proces, kdy je pro kaºdý soubor v archivu vytvo°en jeho otisk (hash) a ten je následn¥ podepsán privátním klí£em vývojá°e. Po dokon£ení v²ech t¥chto krok· je instala£ní balík pro platformu Android hotov. Samoz°ejm¥ zde uvedený popis není kompletní, ale jde spí²e o hrubý popis. Mezi zde zmín¥né kroky jsou £asto vloºeny je²t¥ nejr·zn¥j²í procesy, od obfuskace8 p°es optimalizaci kódu (optimalizace cykl·, smy£ek a v¥tvení programu) aº po kompresi celé aplikace. Nástroje pro vývoj aplikací pro platformu Android umoº¬ují provád¥t vý²e zmín¥né kroky tém¥° automaticky. Uºivatelé mají v sou£asnosti na výb¥r z n¥kolika moºností, jak provád¥t build aplikace. První moºností je vytvá°et build prost°ednictvím integrovaného systému ve vývojovém prost°edí Eclipse, které vyuºívá speciáln¥ upravený Ant skript. Toto °e²ení ale není mimo Eclipse IDE pouºitelné. Dal²í moºností je novinka na platform¥ Android a to build systém zaloºený na nástroji pro automatizaci £ehokoli, nástroji Gradle[29]. Tento build systém je ov²em prozatím stále ve stádiu vývoje a v sou£asnosti neumoº¬uje sestavovat aplikace s vyuºitím NDK (aplikace vyuºívající nativní kód (C/C++)). A proto tedy není tento systém pro pot°eby mého nástroje pouºitelný. Poslední o ciální moºností, kterou vyuºiji ve svém nástroji, je pouºití build systému zaloºeného na Apache Ant[6]. Tento build systém je dostupný od po£átku platformy Android a podporuje v²echny sou£ásti procesu sestavení aplikace. Samotný build systém se skládá z Ant skriptu, který v²e °ídí, JAR soubor· obsahujících logiku buildu, Android SDK knihoven a JDK. Abych tedy mohl tento zp·sob vytvo°ení Android aplikace vyuºít, je nutné, aby na uºivatelském po£íta£i byly nainstalované následující sou£ásti a nastaveny p°íslu²né systémové prom¥nné. 7 8
Implementace Virtual Machine na platform¥ Android Proces p°i kterém dochází ke znep°ehledn¥ní p°eloºeného kódu
42
KAPITOLA 5.
IMPLEMENTACE
• JDK • Ant • Android SDK Coº ov²em p°i uváºení softwarového poºadavku RN-C2, který °íká, ºe aplikace musí být pouºitelná i pro uºivatele bez jakýchkoli znalostí vývoje, nelze o£ekávat. Bylo tedy nutné pot°ebné nástroje p°ibalit jako sou£ást aplikace, coº by díky platformní závislosti t¥chto komponent ne²lo, nebýt nefunk£ního poºadavku RN-C1, který de nuje jako cílovou platformu OS Microsoft Windows XP a nov¥j²í. Díky znalosti cílové platformy jsem také mohl upravit spou²t¥ní samotného desktopového nástroje, kdy jsem vyuºil dávkového souboru *.bat, pro do£asné nastavení systémových prom¥nných, které jsem poté vyuºil p°i spou²t¥ní build nástroje. Samotné generování mobilní aplikace za£íná vytvo°ením obsahu aplikace, které je podrobn¥ji popsáno v sekci 5.1.3, jako dal²í krok jsou ze zadaného obrázku vytvo°ené ikony aplikace ve velikostech, pro které dosta£uje jeho rozli²ení, vºdy je v²ak vytvo°ena alespo¬ jedna ikona a to ve velikosti ldpi.
• Low-Density (ldpi) 36x36 pixel· • Medium-Density (mdpi) 48x48 pixel· • High-Density (hdpi) 72x72 pixel· • Extra High-Density (xhdpi) 96x96 pixel· • Extra Extra High-Density (xxhdpi) 144x144 pixel· • Extra Extra Extra High-Density (xxxhdpi) 192x192 pixel· Pokud zadaný obrázek není £tvercový, je na poºadovaný tvar dopln¥n pr·hlednou barvou. Dále proces vytvo°ení aplikace pokra£uje vytvo°ením parametr· pro Ant skript, který dokoná zbytek. Zm¥ní název aplikace, pomocí p°epsání hodnoty v resources, upraví balík aplikace, název a kód verze aplikace prost°ednictvím editace p°íslu²ných parametr· v manifestu a spustí samotný build aplikace. Do parametr· Ant skriptu jsou také zapsány informace o vývojá°ském certi kátu pot°ebné pro podepsání výsledného instala£ního balíku. Ant skript je spou²t¥n prost°ednictvím volání p°íslu²ného p°íkazu v runtime prost°edí, ve kterém je spu²t¥na celá aplikace. 5.3
Výsledné °e²ení
Kompletní °e²ení se de facto skládá ze dvou hlavních komponent popisovaných v p°edchozích £ástech této kapitoly. Editoru ur£eného pro stroje s opera£ním systémem Microsoft Windows, pomocí kterého lze jednodu²e generovat mobilní aplikace pro systém Android. Mobilní aplikace vznikají dodáním obsahu a vytvo°ením instala£ního balíku ze zdrojových kód· prototypu mobilní aplikace, která obsahuje engine podporující marker based roz²í°enou realitu a umí scénu roz²i°ovat a detekovat podle dat získaných z dodaného obsahu.
5.3.
43
VÝSLEDNÉ EENÍ
Editor je zam¥°en na uºivatele, kte°í nemají zku²enosti s vývojem software. Celou mobilní aplikaci lze vytvo°it v gra ckém prost°edí ovládaném pomocí klávesnice a my²i. Uºivatel b¥hem vytvá°ení aplikace nikdy nep°ijde do styku se zdrojovým kódem. Podobu editoru si m·ºete prohlédnout na obrázku obr. 5.5. Celý editor je koncipován tak, aby ve²keré aktuáln¥ d·leºité ovládací prvky byly ihned viditelné a snadno p°ístupné.
Obrázek 5.5: Ukázka editoru V sou£asnosti prototyp editoru umoº¬uje do scény vkládat pouze roz²í°ení v podob¥ obrázku. Av²ak systém ovládání a nastavování parametr· jednotlivých roz²í°ení byl navrhnut tak, aby byl pouºitelný na jakýkoliv typ roz²í°ení. Ovládání vychází z p°edpokladu, ºe ve²kerá roz²í°ení vloºená do scény jsou z pohledu editoru pouze OpenGL modely, tudíº se v²emi zachází totoºn¥, jediné, v £em se roz²í°ení mohou li²it, je jejich zaloºení a vykreslení. P°idání nového typu roz²í°ení tedy spo£ívá pouze v implementaci metod pro vykreslení v prost°edí OpenGL kontextu a v·bec samotného vytvo°ení, tedy jinak °e£eno, získání pot°ebných dat od uºivatele. Krom¥ vytvá°ení samotného obsahu, tedy editace scény, umí editor také generovat mobilní aplikace, které poté vytvo°ené scény um¥jí prezentovat. Aplikace, které editor vytvá°í, jsou plnohodnotné mobilní aplikace ur£ené pro za°ízení se systémem Android, které poté lze ve°ejn¥ publikovat nap°íklad prost°ednictvím obchod· s aplikacemi jako je Google Play. Vytvo°ená aplikace je z pohledu koncového uºivatele velmi jednoduchá, tak jak tomu u po-
44
KAPITOLA 5.
IMPLEMENTACE
dobn¥ zam¥°ených aplikací bývá zvykem. Hlavním prvkem aplikace je náhled fotoaparátu, jehoº prost°ednictvím je uºivateli zobrazováno samotné roz²i°ování aktuáln¥ snímané scény, jak je vid¥t na obrázku obr. 5.6. Krom¥ náhledu fotoaparátu umí vygenerovaná aplikace také zobrazit podporované markery, aby uºivatelé v¥d¥li, jaké vzory mají pro uºití aplikace vyhledávat.
Obrázek 5.6: Ukázka mobilní aplikace snímání scény Pro generování mobilní aplikace vyuºívá editor standardní postup vytvá°ení Android aplikace. Aplikace je sestavována pomocí Ant skriptu za pomoci Java SDK a samotného Android SDK. Jelikoº není zaji²t¥no, ºe bude mít uºivatel tohoto editoru v²echny tyto sou£ásti °ádn¥ nainstalované (u cílové skupiny to nelze ani o£ekávat), je nutné dodávat ve²keré tyto komponenty jako sou£ást celého °e²ení, coº se velmi negativn¥ podepisuje na výsledné velikosti. Díky portabilit¥ v²ech komponent °e²ení není vyºadována ºádná instalace. Sta£í pouze ve²keré sou£ásti °e²ení nakopírovat na umíst¥ní, kde je povolen zápis.
Kapitola 6
Testování Kapitola obsahuje popis zp·sobu testování pouºitelnosti desktopového nástroje a mobilní aplikace. V kapitole jsou také zachyceny výsledky testování v podob¥ identi kace hlavních nedostatk· a návrh· na jejich odstran¥ní. 6.1
Desktopová £ást
6.1.1
Cíl testování
Cílem testování pouºitelnosti desktopové £ásti je ov¥°ení, ºe nástroj je vhodný pro uºivatele z cílové skupiny a ov¥°ení p°ív¥tivosti uºivatelského rozhraní. 6.1.2
Cílová skupina
Nástroj je ur£en pro uºivatele opera£ního systému Windows, kte°í jsou schopni základních úkon·, jako je spou²t¥ní aplikací, organizace dat v adresá°ové struktu°e apod. 6.1.3
Výb¥r participant·
V²ichni participanti musí spadat do cílové skupiny testovaného nástroje. Dále by bylo vhodné, aby mezi vybranými participanty byli zastoupeni jak lidé bez zku²eností s vývojem software, tak i lidé, kte°í jsou znalí vývoje pro mobilní platformu Android. Pro ú£ely výb¥ru participant· jsem sestavil následující malý screener. 1. Umíte spou²t¥t aplikace v prost°edí opera£ního systému Microsoft Windows?
Ano / Ne
2. Vyznáte se v adresá°ové struktu°e?
Ano / Ne
3. Máte zku²enosti s vývojem software?
Ano / Ne
45
46
KAPITOLA 6.
TESTOVÁNÍ
4. Máte zku²enosti s vývojem mobilních aplikací pro os Android?
Ano / Ne
První dv¥ otázky zaji²´ují, ºe participant pat°í do cílové skupiny, proto je nutné, aby v²ichni zú£astn¥ní odpov¥d¥li pozitivn¥. Pomocí dal²ích dvou otázek rozd¥luji participanty do dvou skupin popsaných vý²e. Do první skupiny lidí, kte°í nemají zku²enosti s vývojem, pat°í ti, kte°í odpov¥dí záporn¥ na t°etí otázku. Do skupiny t¥ch, kte°í mají zku²enosti s vývojem pro Android, pat°í ti, kte°í odpov¥dí kladn¥ jak na t°etí, tak i na £tvrtou otázku. Ve výsledné skupin¥ participant· by m¥li být minimáln¥ t°i participanti, kte°í pat°í do první skupiny a t°i, kte°í pat°í do skupiny druhé. 6.1.4
Pr·b¥h testu
Testování probíhalo s vybranými participanty za pomoci prototypu aplikace v klidné místnosti. Jako testovací stroj byl pouºit notebook Lenovo IdeaPad V460 s následující kon gurací
• Intel Core i3 370M • 8 GB RAM • Microsoft Windows 7 Professional SP 1 64 bit • Externí monitor 1920 x 1080 • Externí klávesnice • Externí my² Pr·b¥h jednotlivých test· se zhruba °ídil následujícím rozvrhem
• Uvítání participanta, dohodnutí pravidel testu • Krátký úvod k testované aplikaci • Seznámení uºivatele s terminologií pouºívanou v aplikaci • Seznámení uºivatele s testovacím scéná°em • Test • Dobrovolná diskuze • Zodpov¥zení krátkého dotazníku
Jak se Vám aplikace ovládala? vyuºijte stupnici 1 (výborn¥) - 5 (velmi ²patn¥) P°i²el Vám n¥který úkol t¥ºko proveditelný, pop°ípad¥ který? Uve¤te £íslo úkolu
6.1.
DESKTOPOVÁ ÁST
6.1.5
47
Testovací scéná°
Chcete vytvo°it PF aplikaci pro va²i rmu, která uºivatel·m p°i rozeznání loga spole£nosti zobrazí obrázek s p°áním. 1. Vytvo°te nový marker
Pouºijte obrázek logo.jpg umíst¥ný na plo²e
2. Nov¥ vytvo°ený marker ov²em není správn¥ orientovaný, upravte tedy pohled na marker tak, aby se vám lépe pracovalo 3. Na nov¥ vytvo°ený marker umíst¥te obrazové roz²í°ení
Pouºijte obrázek PF.jpg umíst¥ny na plo²e
4. Roz²í°ení ov²em není na markeru správn¥ orientováno, pokuste se to opravit nato£ením roz²í°ení 5. Upravte roz²í°ení tak, aby zakrývalo celý marker 6. Spus´te pr·vodce pro generování aplikace a postupujte podle pokyn·
Poºadovaná data si vymyslete Jelikoº nevlastníte ºádný keystore s certi kátem, vytvo°te nový a uloºte jej na plochu Výslednou aplikaci také uloºte na plochu
7. Po vygenerování aplikace nalezn¥te výsledný balík aplikace (APK) 6.1.6
Výsledky
Kompletní záznam z testování naleznete v p°íloze B. V²ichni participanti dokázali samostatn¥ vytvo°it ukázkovou mobilní AR aplikaci, která slouºila jako interaktivní PF. Vytvo°ení aplikace zvládli v²ichni participanti pod osm minut, coº povaºuji za skv¥lý výsledek a jako pozitivní záv¥r ov¥°ení, ºe nástroj má p°ív¥tivé uºivatelské rozhraní. V¥t²ina participant· v záv¥ru testu potvrdila, ºe by byla po této zku²enosti s nástrojem dále schopna samostatn¥ pracovat. B¥hem testování bylo nalezeno n¥kolik nedostatk· a chyb, které vedly ke zmatení uºivatel·, £i se rozcházeli s jejich o£ekáváním. Následuje jejich vý£et vºdy s navrhovaným °e²ením a ur£ením priority (Priorita 1 Kritická, má vliv na funk£nost, uºivatelé díky ní nejsou schopni dokon£it sv·j úkol. Priorita 2 St°ední, má velký vliv na efektivní práci s nástrojem, uºivatel díky ní ztrácí sv·j £as. Priorita 3 Nízká, má men²í vliv na efektivitu práce.)
Spojení os a ovládacích prvk· Priorita 2
Ovládání roz²í°ení ve scén¥ je rozloºeno na ovládací prvky pro jednotlivé osy 3D prostoru. Neznalí uºivatelé ov²em nejsou schopni si spojit sm¥r osy s jejím názvem v podob¥ písmene (X, Y, nebo Z). Bylo by proto vhodné vyuºít vykreslované trojnoºky p°i selekci roz²í°ení a barev jejich jednotlivých ²ipek, kdy je kaºdá z nich navíc vykreslena ve sm¥ru jedné z os a stejnou barvou odli²it i ovládací prvky.
48
KAPITOLA 6.
TESTOVÁNÍ
Vstup z klávesnice Priorita 2 V¥t²ina uºivatel· p°i testování aplikace cht¥la nastavovat hodnoty u ovládacích prvk· pomocí klávesnice, které se ov²em chovalo dosti podivn¥. P°i vkládání hodnoty z klávesnice by m¥l ovládací prvek takto nastavené hodnoty brát v potaz.
Ukládání soubor· Priorita 2
P°i ukládání soubor· jsou uºivatelé zvyklí psát pouze název souboru, o dopln¥ní koncovky by se m¥l postarat samotný nástroj. P°i ukládání souboru by m¥l nástroj zkontrolovat, zda soubor obsahuje poºadovanou koncovku a p°ípadn¥ ji doplnit.
Jazyk Priorita 3
Uºivatelé pat°ící do cílové skupiny nemusí vºdy ovládat anglický jazyk a o£ekávali by, ºe nástroj, který je ur£en pro n¥, bude komunikovat v jazyce, kterému jsou schopni porozum¥t. e²ením je p°id¥lat do aplikace podporu lokalizace a také moºnost zm¥nit jazyk aplikace za b¥hu.
Vloºení nového markeru Priorita 3
V¥t²ina uºivatel· p°i testování hledala moºnost vloºit nový marker v nabídce File, tak jak jsou zvyklí z jiných program·. Stálo by proto za zváºení, zda tuto moºnost do této nabídky nep°idat, £i nezaloºit úpln¥ novou nabídku nazvanou Edit, která by poté obsahovala moºnosti jako je práv¥ zaloºení nového markeru, vloºení roz²í°ení, export aplikace atd.
Upozorn¥ní na sekci nastavení Priorita 3
Po selekci roz²í°ení, dojde k aktivaci sekce nastavení p°i pravém okraji nástroje. Tato aktivace je v²ak pro uºivatele velmi málo výrazná a málo kdo si jí v²imne. Poté tato aktivace nep°itahuje tolik pozornosti, kolik by m¥la. Doporu£uji tedy aktivaci sekce ud¥lat výrazn¥j²í, nap°íklad za pomoci barev, £i celou aktivaci p°ed¥lat na zobrazení ovládacích prvk· a deaktivaci naopak na jejich zmizení, místo te¤ implementovaného prostého znep°ístupn¥ní, které není tolik výrazné a nep°itahuje tak uºivatelovu pozornost.
6.2 6.2.1
Mobilní £ást Cíl testování
Díky jednoduchosti mobilní aplikace bylo hlavním cílem testování p°edev²ím ov¥°ení srozumitelnosti nápov¥dy zobrazované p°i jejím spu²t¥ní a dojmu ze samotného efektu roz²í°ené reality.
6.2.
MOBILNÍ ÁST
6.2.2
49
Cílová skupina
Mobilní aplikace je ur£ena pro uºivatele opera£ního systému Android. 6.2.3
Výb¥r participant·
V²ichni participanti testu by m¥li být uºivatelé systému Android. Dále by bylo vhodné, aby mezi participanty byli zastoupeni jak uºivatelé, kte°í znají pojem roz²í°ená realita a jiº n¥jaké podobné aplikace vid¥li, tak i uºivatelé, pro které je podobná aplikace novinkou. Uºivatele jsem se op¥t rozhodl vybírat za pomoci screeneru. 1. Pouºíváte mobilní za°ízení se systémem Android?
Ano / Ne
2. Znáte n¥kterou aplikaci vyuºívající roz²í°enou realitu?
Ano / Ne
První otázka rozhoduje, zda uºivatel pat°í do cílové skupiny uºivatel·, v²ichni participanti na ni musí souhlasn¥ odpov¥d¥t. Druhá otázka rozd¥luje participanty na ty, kte°í znají n¥kterou aplikaci vyuºívající roz²í°enou realitu a ty, pro které je roz²í°ená realita novinkou. Ve vybrané skupin¥ participant· by m¥li být minimáln¥ dva zástupci z první skupiny a dva zástupci ze skupiny druhé. 6.2.4
Pr·b¥h testu
Testování mobilní aplikace probíhalo za pomoci prototypu v klidné místnosti. Jako testovací nástroj byl pouºit mobilní telefon LG Nexus 4, který byl pro ú£ely nahrávání obrazovky p°ipojen kabelem k po£íta£i. Markery byly uºivatel·m zobrazovány na po£íta£ovém monitoru. Pr·b¥h testu se p°ibliºn¥ °ídil stejným rozvrhem jako testování desktopové £ásti. Kone£ný dotazník pokládaný participant· m¥l následující podobu.
• Jak se Vám aplikace ovládala?
vyuºijte stupnici 1 (výborn¥) - 5 (velmi ²patn¥)
• Jaký dojem na Vás ud¥lala roz²í°ená realita v podání testované aplikace?
Pokud chcete, napi²te krátké zhodnocení
6.2.5
Testovací scéná°
1. Vyhledejte aplikaci AnARTest v za°ízení a spus´te ji 2. Seznamte se s ovládáním aplikace 3. Prohlédn¥te si markery, které aplikace registruje 4. Spus´te fotoaparát v aplikaci a pokuste se rozeznat libovolný podporovaný marker 5. Aplikaci ukon£ete
50
6.2.6
KAPITOLA 6.
TESTOVÁNÍ
Výsledky
Kompletní záznam z testování mobilní aplikace naleznete v p°íloze C. Testováním se ov¥°il zp·sob ovládání, který je natolik jednoduchý a srozumitelný, ºe ned¥lal ºádnému z participant· testu sebemen²í problém. Dal²ím cílem testování bylo vyzkou²ení reakce uºivatel· na pouºitý zp·sob roz²í°ené reality. Pro dosaºení tohoto cíle byl ov²em tento test ²patn¥ navrhnut. Prototyp aplikace se uºivatel·m za cílem nahrávání pr·b¥hu testu prezentovala na za°ízení, na kterém má pouºitá knihovna problém plynule b¥ºet, dále byla testovaná prezentace velmi jednoduchá a neukazovala v²echny zamý²lené moºnosti a hlavn¥ po£et testovaných osob byl pro °ádné výsledky p°íli² nízký.
Kapitola 7
Záv¥r 7.1
Zhodnocení spln¥ní cíl·
V rámci práce se poda°ilo analyzovat sou£asné vyuºití roz²í°ené reality ve spojení s mobilními za°ízeními. Byly jmenovány t°i hlavní druhy implementace mobilní roz²í°ené reality, location based roz²í°ená realita, marker based roz²í°ená realita a markerless roz²í°ená realita. Ke kaºdému typu jsem v krátkosti uvedl princip implementace a vztahující se typické druhy mobilních aplikací. Z trojice zmi¬ovaných typ· mobilní roz²í°ené reality jsem zvolil princip s nejv¥t²ím potenciálem, a sice marker based roz²í°enou realitu, která se v sou£asnosti nejvíce vyuºívá pro ú£ely reklamy, £i pobavení. Popsal jsem typický princip aplikace vyuºívající tento druh roz²í°ené reality, identi koval spole£né body, navrhl a posléze i implementoval prototyp nástroje, pomocí kterého lze podobné aplikace snadno vytvá°et. Nástroj se skládá ze dvou hlavních £ástí. Zdrojových kód· prototypu mobilní aplikace pro os Android, která obsahuje engine pro marker based roz²í°enou realitu, který je implementován jako kombinace knihovny Vuforia a implementace detekce markeru pomocí obrazové p°edlohy za vyuºití knihovny OpenCV. Tento prototyp poté slouºí jako základ aplikací generovaných druhou £ástí °e²ení, a sice editoru ur£eného pro stroje se systémem Microsoft Windows. Editor je zam¥°en na uºivatele bez znalostí vývoje software, umoº¬uje vytvá°et aplikace s marker based roz²í°enou realitou prost°ednictvím gra ckého rozhraní, kde uºivatel nep°ijde do styku se zdrojovým kódem. Generované aplikace jsou poté plnohodnotnými aplikacemi ur£enými pro za°ízení se systémem Android a lze je ve°ejn¥ publikovat nap°íklad prost°ednictvím obchod· s aplikacemi jako je Google Play. Celé °e²ení a jeho produkty, tedy editor a generované aplikace, jsem v záv¥ru práce podrobil testu pouºitelnosti s uºivateli z cílových skupin, ve kterých si vedly nad míru dob°e. Lze tedy °íci, ºe v²echny hlavní cíle této práce byly spln¥ny. Byly identi kovány hlavní sou£asné zp·soby vyuºití roz²í°ené reality na mobilních za°ízeních. Na základ¥ t¥chto dat byl navrhnut a poté i implementován nástroj pro snadné vytvá°ení samostatných mobilních aplikací s vyuºitím roz²í°ené reality pro mobilní opera£ní systém Android. A v záv¥ru bylo toto °e²ení otestováno a to jak z hlediska tv·rce aplikace, tak i následného konzumenta generované aplikace. 51
52
KAPITOLA 7.
ZÁV
R
Navíc vzniklý prototyp nástroje lze vyuºít jako základ °e²ení, které doposud na trhu mobilní roz²í°ené reality chybí, a sice nástroje, který umí levn¥ vytvá°et samostatné marker based AR mobilní aplikace. 7.2
Doporu£ení pro dal²í rozvoj
Nástroj, který b¥hem této práce vznikl, lze v sou£asnosti ozna£it pouze za prototyp. Aby mohl být reáln¥ pouºíván, je zapot°ebí na n¥m je²t¥ zapracovat. Jedná se p°edev²ím o dopln¥ní palety vkládaných roz²í°ení a to minimáln¥ do té míry, jak ur£uje softwarový poºadavek RFC3 a dokon£ení implementace funkce pro uloºení a op¥tovné na£tení projektu. Jako dal²í krok je zapot°ebí zapracovat na datové náro£nosti generovaných aplikací a výkonu desktopového editoru. Nástroj pak lze dále rozvíjet a to nap°íklad implementací funkce, která místo samostatné aplikace vytvo°í knihovnu, která poté p·jde vloºit do jiných projekt·. i zakomponováním moºnosti updatovat obsah aplikace prost°ednictvím webových sluºeb.
Literatura [1] Ivan Sutherland. A head-mounted three dimensional display [online]. 1968. [cit. 2. 12. 2013]. Dostupné z: . [2] Alexandre Alahi, Raphael Ortiz, Pierre Vandergheynst. FREAK: Fast Retina Keypoint [online]. 2012. [cit. 24. 12. 2013]. Dostupné z: . [3] Android komunita. Android Design [online]. 2013. [cit. 19. 12. 2013]. . [4] Android komunita. Help [online]. 2013. [cit. 21. 12. 2013]. //developer.android.com/design/patterns/help.html>.
Dostupné z:
Dostupné z:
[5] Android komunita. Dalvik Executable Format [online]. 2013. [cit. 27. 12. 2013]. Dostupné z: . [6] Apache Software Foundation. The Apache Ant project [online]. 2013. [cit. 27. 12. 2013]. Dostupné z: . [7] Edward Rosten, Tom Drummond. Machine learning for high-speed corner detection [online]. 2006. [cit. 24. 12. 2013]. Dostupné z: . [8] Ethan Rublee, Vincent Rabaud, Kurt Konolige, Gary Bradski. ORB: an e cient alternative to SIFT or SURF [online]. 2011. [cit. 24. 12. 2013]. Dostupné z: . [9] J. Matas, O. Chum, M. Urban, T. Pajdla. Robust Wide Baseline Stereo from Maximally Stable Extremal Regions [online]. 2002. [cit. 24. 12. 2013]. Dostupné z: . [10] Martin Beneda. Homogra e a epipolární geometrie [online]. 2010. [cit. 23. 12. 2013]. Dostupné z: . [11] opengl-tutorial.org. Tutorial 3 : Matrices [online]. 2013. [cit. 25. 12. 2013]. Dostupné z: . 53
54
LITERATURA
[12] Oracle. Java Native Interface Speci cation [online]. 2013. [cit. 22. 12. 2013]. Dostupné z: . [13] Paul Milgram, Fumio Kishino. Taxonomy of Mixed Reality Visual Displays [online]. 1994. [cit. 2. 12. 2013]. Dostupné z: . [14] P°isp¥vatelé Wikipedie. APK ( le format) [online]. 2013. [cit. 27. 12. 2013]. Dostupné z: . [15] P°isp¥vatelé Wikipedie. Java bytecode [online]. 2013. [cit. 27. 12. 2013]. Dostupné z: . [16] P°isp¥vatelé Wikipedie. Feature (computer vision) [online]. 2013. [cit. 16. 12. 2013]. Dostupné z: . [17] P°isp¥vatelé Wikipedie. Haar-like features [online]. 2013. [cit. 18. 12. 2013]. Dostupné z: . [18] P°isp¥vatelé Wikipedie. Java OpenGL [online]. 2013. [cit. 27. 12. 2013]. Dostupné z: . [19] P°isp¥vatelé Wikipedie. MoSCoW Method [online]. 2013. [cit. 19. 12. 2013]. Dostupné z: . [20] P°isp¥vatelé Wikipedie. Paper prototyping [online]. 2013. [cit. 19. 12. 2013]. Dostupné z: . [21] P°isp¥vatelé Wikipedie. Rotation matrix [online]. 2013. [cit. 2. 12. 2013]. Dostupné z: . [22] P°isp¥vatelé Wikipedie. Swing (Java) [online]. 2013. [cit. 26. 12. 2013]. Dostupné z: . [23] P°isp¥vatelé Wikipedie. Transformation matrix [online]. 2013. [cit. 16. 12. 2013]. Dostupné z: . [24] P°isp¥vatelé Wikipedie. Wikitude [online]. 2013. [cit. 18. 12. 2013]. Dostupné z: . [25] Ronald Azuma. A Survey of Augmented Reality [online]. 1997. [cit. 2. 12. 2013]. Dostupné z: . [26] SOOD, R. Pro Android Augmented Reality. Apress Media L.L.C., 1st edition, 2012. [27] Stefan Leutenegger, Margarita Chli, Roland Y. Siegwart. BRISK: Binary Robust Invariant Scalable Keypoints [online]. 2011. [cit. 24. 12. 2013]. Dostupné z: .
LITERATURA
55
Augmented reality: an application of heads-up display technology to manual manufacturing processes [online]. 1992. [cit. 2. 12. 2013].
[28] Tom Caudell, David Mizell.
Dostupné z: . [29] Vít Kota£ka. Gradle, moderní nástroj na automatizaci [online]. 2013. [cit. 27. 12. 2013]. Dostupné z: .
56
LITERATURA
P°íloha A
Seznam pouºitých zkratek 3D
trojdimenzionální, trojrozm¥rný
DEX Dalvik Executable Format FPS
Frames Per Second
GPS
Globální Pozi£ní Systém
GSM Globální Systém pro Mobilní komunikaci hdpi
High-Density
HICSS Hawaii International Conference on Systems Science HW
Hardware
ICS
Ice Cream Sandwich
JDK
Java Development Kit
JNI
Java Native Interface
JOGL Java OpenGL ldpi
Low-Density
mdpi Medium-Density OpenGL Open Graphics Library OS
Opera£ní Systém
SDK
Software Development Kit
SE
Standard Edition
UDT User De ned Targets Wi-Fi Wireless Fidelity 57
58
PÍLOHA A.
xhdpi Extra High-Density xxhdpi Extra Extra High-Density xxxhdpi Extra Extra Extra High-Density
SEZNAM POUITÝCH ZKRATEK
P°íloha B
Záznam z testování desktopové £ásti B.1
Participant 1
B.1.1
Screener
Umíte spou²t¥t aplikace v prost°edí opera£ního systému Microsoft Windows? Ano
Vyznáte se v adresá°ové struktu°e? Ano
Máte zku²enosti s vývojem software? Ano
Máte zku²enosti s vývojem mobilních aplikací pro os Android? Ano
B.1.2
Záznam testu
úkol 1 00:10 participant hledá p°idání nového markeru v nabídce "File" 00:15 participant hledá p°idání nového markeru v palet¥ s roz²í°eními 00:26 úkol úsp¥²n¥ dokon£en úkol 2 00:35 participant hledá moºnost nato£ení scény v palet¥ s roz²í°eními 00:45 úkol úsp¥²n¥ dokon£en úkol 3 01:03 úkol úsp¥²n¥ dokon£en úkol 4 01:13 01:17 01:22 01:49
participant se snaºí oto£it roz²í°ením pomocí my²i participant se snaºí oto£it roz²í°ením stejn¥ jako v p°ípad¥ celé scény participant zkou²í, kolem které osy má roz²í°ení nato£it úkol úsp¥²n¥ dokon£en 59
60
PÍLOHA B.
ZÁZNAM Z TESTOVÁNÍ DESKTOPOVÉ ÁSTI
úkol 5 02:07 úkol úsp¥²n¥ dokon£en úkol 6 04:16 úkol úsp¥²n¥ dokon£en úkol 7 04:23 úkol úsp¥²n¥ dokon£en B.1.3
Dotazník
Jak se Vám aplikace ovládala? 2
P°i²el Vám n¥který úkol t¥ºko proveditelný, pop°ípad¥ který?
Ano, bod £íslo 2, jenom náhodou jsem to tre l, ale kdybych nem¥l ²t¥stí, tak by mi to asi trvalo dlouho.
B.1.4
Shrnutí
Vytvo°ení jednoduché mobilní AR aplikace pomocí testovaného desktopového nástroje ned¥lalo prvnímu participantovi v¥t²í potíºe a celou záleºitost zvládl sám za mén¥ neº £ty°i a p·l minuty, coº povaºuji za velmi dobrý výsledek vzhledem k tomu, ºe daný nástroj vid¥l poprvé. Participant p°i testování uskute£nil pouze dv¥ pochybení, jedno hned ze za£átku testu a to p°i vytvá°ení nového markeru, kdy si nev²iml jediného aktivního tla£ítka v nástroji a rad¥ji volbu hledal v nabídce File. Druhé zaváhání p°i²lo na °adu p°i otá£ení vloºeného roz²í°ení, kde se nejprve snaºil aplikovat stejnou logiku jako p°i natá£ení celé scény, ale velmi rychle pochopil, ºe tudy cesta nevede a za£al se správn¥ v¥novat sekci nastavení. Participant poté v záv¥re£ném rozhovoru ozna£il ovládání nástroje jako vcelku povedené a potvrdil, ºe vytvo°ení dal²í aplikace by pro n¥j bylo velmi snadné. B.2
Participant 2
B.2.1
Screener
Umíte spou²t¥t aplikace v prost°edí opera£ního systému Microsoft Windows? Ano
Vyznáte se v adresá°ové struktu°e? Ano
Máte zku²enosti s vývojem software? Ne
Máte zku²enosti s vývojem mobilních aplikací pro os Android? -
B.2.
PARTICIPANT 2
B.2.2
61
Záznam testu
úkol 1 00:03 participant hledá p°idání nového markeru v palet¥ s roz²í°eními 00:10 participant se snaºí p°idat nový marker pomocí drag n' drop 00:24 úkol úsp¥²n¥ dokon£en úkol 2 00:26 participant hledá ten správný slider 00:37 úkol úsp¥²n¥ dokon£en úkol 3 00:59 úkol úsp¥²n¥ dokon£en úkol 4 01:05 01:20 01:37 02:00 02:14 02:35
participant se snaºí oto£it roz²í°ením stejn¥ jako v p°ípad¥ celé scény participant zkou²í, které z nastavení otá£í roz²í°ení participant míjí správný slider a vrací se k natá£ení celé scény participant se vrací ke zkou²ení voleb v sekci nastavení markeru participant o£ekává, ºe lze hodnotu nastavovat pomocí klávesnice úkol úsp¥²n¥ dokon£en
úkol 5 02:50 participant se snaºí opravit polohu roz²í°ení po p°edchozích experimentech 03:33 úkol úsp¥²n¥ dokon£en úkol 6 04:24 05:17 05:53 07:02
participant ukládá sv·j certi kát neznámo kam participant si £te informa£ní popisky aº po vypln¥ní celého formulá°e participant by o£ekával p°edvypln¥ný název generovaného APK úkol úsp¥²n¥ dokon£en
úkol 7 07:10 úkol úsp¥²n¥ dokon£en B.2.3
Dotazník
Jak se Vám aplikace ovládala? 3
P°i²el Vám n¥který úkol t¥ºko proveditelný, pop°ípad¥ který?
Ano, bod £íslo 4, ale moºná kdybych £etla ty popisky, tak by to bylo lep²í.
B.2.4
Shrnutí
Druhý participant si vedl o poznání h·°e neº první testovaný a na vytvo°ení aplikace pot°eboval tém¥° dvojnásobný £as, av²ak stejn¥ jako první participant i on zvládl aplikaci vytvo°it zcela samostatn¥.
62
PÍLOHA B.
ZÁZNAM Z TESTOVÁNÍ DESKTOPOVÉ ÁSTI
Nejv¥t²í problém m¥l participant s oto£ením roz²í°ení, kdy se nejprve pokou²el vyuºit jiº nau£ený vzorec p°i otá£ení celé scény, poté se dal na správnou cestu, av²ak neº na²el správný ovládací prvek, svou snahu vzdal a vrátil se k jiº d°íve zkou²eným akcím. Tyto a dal²í chyby p°isuzuji jeho p°ístupu k ovládání aplikací, kdy, jak pozd¥ji sám potvrdil, ve v¥t²in¥ p°ípad· ne£te zobrazené popisky a snaºí se v²e ovládat podle vlastních zku²eností. B.3
Participant 3
B.3.1
Screener
Umíte spou²t¥t aplikace v prost°edí opera£ního systému Microsoft Windows? Ano
Vyznáte se v adresá°ové struktu°e? Ano
Máte zku²enosti s vývojem software? Ano
Máte zku²enosti s vývojem mobilních aplikací pro os Android? Ano
B.3.2
Záznam testu
úkol 1 00:09 participant hledá p°idání nového markeru v nabídce "File" 00:12 participant zvolil nový projekt 00:28 úkol úsp¥²n¥ dokon£en úkol 2 00:34 participant hledá otá£ení scény v nástrojích pro roz²í°ení 00:49 úkol úsp¥²n¥ dokon£en úkol 3 00:58 participant hledá vloºení roz²í°ení v nabídce "File" 01:09 úkol úsp¥²n¥ dokon£en úkol 4 01:20 participant si v²ímá zm¥ny stavu ovládacích prvk· p°i selekci roz²í°ení 01:43 úkol úsp¥²n¥ dokon£en úkol 5 02:09 úkol úsp¥²n¥ dokon£en úkol 6 04:50 úkol úsp¥²n¥ dokon£en úkol 7 04:55 úkol úsp¥²n¥ dokon£en
B.4.
PARTICIPANT 4
B.3.3
63
Dotazník
Jak se Vám aplikace ovládala? 2
P°i²el Vám n¥který úkol t¥ºko proveditelný, pop°ípad¥ který? Ani ne
B.3.4
Shrnutí
Participant £íslo t°i si p°i testování po£ínal velmi zdatn¥ a nem¥l v¥t²í problémy s ºádným z testovaných úkon·. Jediným, co u tohoto participanta bylo pozorováno, byla skute£nost, ºe p°i vkládání nových v¥cí do modelované scény (úkoly 1 a 3) hledal danou moºnost vºdy nejprve v nabídce File. V pozd¥j²ím rozhovoru mi participant prozradil, ºe mu velmi pomohly jeho znalosti a zku²enosti s vývojem v OpenGL, zejména u otá£ení roz²í°ení, kdy nezaváhal a ihned v¥d¥l kolem které osy se má roz²í°ení oto£it. Jako dal²í výhodu ozna£il znalosti vývoje pro Android, které podle jeho slov, se mu hodily p°i generování aplikace, kdy p°esn¥ v¥d¥l co je keystore, k £emu slouºí alias atd. B.4
Participant 4
B.4.1
Screener
Umíte spou²t¥t aplikace v prost°edí opera£ního systému Microsoft Windows? Ano
Vyznáte se v adresá°ové struktu°e? Ano
Máte zku²enosti s vývojem software? Ne
Máte zku²enosti s vývojem mobilních aplikací pro os Android? -
B.4.2
Záznam testu
úkol 1 00:14 úkol úsp¥²n¥ dokon£en úkol 2 00:34 participant hledá správný slider pro oto£ení scény ve cht¥ném sm¥ru 00:45 úkol úsp¥²n¥ dokon£en úkol 3 01:15 úkol úsp¥²n¥ dokon£en
64
PÍLOHA B.
ZÁZNAM Z TESTOVÁNÍ DESKTOPOVÉ ÁSTI
úkol 4 01:18 participant se pokou²í roz²í°ení oto£it pomocí my²i 01:35 participant hledá správnou sekci nastavení 02:21 úkol úsp¥²n¥ dokon£en úkol 5 02:30 participant místo zv¥t²ení roz²í°ení jej posunuje po ose Z 02:35 participant povaºuje úkol za spln¥ný úkol 6 05:45 úkol úsp¥²n¥ dokon£en úkol 7 05:50 úkol úsp¥²n¥ dokon£en B.4.3
Dotazník
Jak se Vám aplikace ovládala? 2
P°i²el Vám n¥který úkol t¥ºko proveditelný, pop°ípad¥ který? Oto£ení toho obrázku, úkol 4.
B.4.4
Shrnutí
tvrtý participant taktéº dokázal vytvo°it AR mobilní aplikaci zcela samostatn¥, ale p°i jejím vytvá°ení se dopustil jedné chyby, kdy místo roztaºení vloºeného roz²í°ení jej akorát posunul po ose Z, coº z hlediska tv·rce vypadá podobn¥ jako roztaºení, ale pouze do doby, neº si pooto£í scénu, £i nální aplikaci nahraje do za°ízení a vyzkou²í ji. Toto pochybení bylo s nejv¥t²í pravd¥podobností zp·sobeno uºivatelovými p°edchozími pokusy, p°i kterých tuto funkci objevil v kombinaci s nepochopením anglických popisk·. B.5
Participant 5
B.5.1
Screener
Umíte spou²t¥t aplikace v prost°edí opera£ního systému Microsoft Windows? Ano
Vyznáte se v adresá°ové struktu°e? Ano
Máte zku²enosti s vývojem software? Ne
Máte zku²enosti s vývojem mobilních aplikací pro os Android? -
B.5.
PARTICIPANT 5
B.5.2
65
Záznam testu
úkol 1 00:13 participant hledá vloºení markeru v palet¥ roz²í°ení 00:22 participant hledá vloºení markeru v nabídce "File" 00:43 úkol úsp¥²n¥ dokon£en úkol 2 00:59 participant rovnou vkládá roz²í°ení, musel jsem zasáhnout 01:03 participant hledá slider pro nato£ení scény do správné polohy 01:14 úkol úsp¥²n¥ dokon£en úkol 3 01:33 úkol úsp¥²n¥ dokon£en úkol 4 01:36 01:46 01:58 02:21 03:02 03:28
participant otá£í scénou participant se pokou²í o oto£ení my²í za vyuºití zobrazených os participant pouºívá pravé tla£ítko my²i participant p°esouvá pozornost do nastavení a hledá správnou volbu participant o£ekává moºnost ovládat slidery pomocí vstupu z klávesnice úkol úsp¥²n¥ dokon£en
úkol 5 04:03 úkol úsp¥²n¥ dokon£en úkol 6 06:02 participantem zadaná hesla se neshodují 07:12 participantovi se zdá, ºe aplikace se zasekla 07:35 úkol úsp¥²n¥ dokon£en úkol 7 07:40 úkol úsp¥²n¥ dokon£en B.5.3
Dotazník
Jak se Vám aplikace ovládala? 3
P°i²el Vám n¥který úkol t¥ºko proveditelný, pop°ípad¥ který? úkol 4, to otá£ení
B.5.4
Shrnutí
Participant £íslo p¥t pot°eboval na samostatné vytvo°ení aplikace nejdel²í £as ze v²ech zú£astn¥ných, a sice necelých osm minut. Participant se nejdéle zdrºel, stejn¥ jako tém¥° v²ichni ostatní participanti, u úkolu £íslo 4, tedy otá£ení roz²í°ení. Participant se nejprve pokou²el aplikovat zku²enosti, které nejspí²e
66
PÍLOHA B.
ZÁZNAM Z TESTOVÁNÍ DESKTOPOVÉ ÁSTI
získal obsluhou jiných program·, a sice oto£it roz²í°ení pomocí my²i, kdyº ale zjistil, ºe to není moºné, ihned p°esunul svou pozornost do sekce nastavení, kde jiº metodou pokus omyl na²el správnou moºnost. Participant také jako jediný m¥l pocit, ºe b¥hem generování mobilní aplikace do²lo k zaseknutí daného procesu, a sice v dob¥, kdy do okna zobrazujícího progres vytvá°ení nebylo del²í dobu nic vypsáno. B.6
Participant 6
B.6.1
Screener
Umíte spou²t¥t aplikace v prost°edí opera£ního systému Microsoft Windows? Ano
Vyznáte se v adresá°ové struktu°e? Ano
Máte zku²enosti s vývojem software? Ano
Máte zku²enosti s vývojem mobilních aplikací pro os Android? Ano
B.6.2
Záznam testu
úkol 1 00:10 participant hledá vloºení markeru v nabídce "File" 00:28 úkol úsp¥²n¥ dokon£en úkol 2 00:45 participant hledá slider pro nato£ení scény do správné polohy 01:00 úkol úsp¥²n¥ dokon£en úkol 3 01:27 úkol úsp¥²n¥ dokon£en úkol 4 01:40 01:43 01:57 02:25
participant otá£í scénou participant se pokou²í o oto£ení my²í participant nalezl otá£ení roz²í°ením, ale neví kolem které osy úkol úsp¥²n¥ dokon£en
úkol 5 02:44 úkol úsp¥²n¥ dokon£en úkol 6 04:00 participantovi se neda°í uloºit aplikaci, jelikoº soubor se stejným jménem jiº existuje 05:25 úkol úsp¥²n¥ dokon£en
B.6.
PARTICIPANT 6
67
úkol 7 05:30 úkol úsp¥²n¥ dokon£en B.6.3
Dotazník
Jak se Vám aplikace ovládala? 2
P°i²el Vám n¥který úkol t¥ºko proveditelný, pop°ípad¥ který? Ne
B.6.4
Shrnutí
Poslední ú£astník testu také dokázal vygenerovat svou vlastní aplikaci. B¥hem testu se nejvíce zdrºel p°i hledání, kolem které osy se má dané roz²í°ení oto£it, aby bylo ve správné poloze. Participant také narazil na chybu, kdy cht¥l uloºit výslednou generovanou aplikaci, ale nástroj mu hlásil, ºe daná aplikace jiº existuje.
68
PÍLOHA B.
ZÁZNAM Z TESTOVÁNÍ DESKTOPOVÉ ÁSTI
P°íloha C
Záznam z testování mobilní £ásti C.1
Participant 1
C.1.1
Screener
Pouºíváte mobilní za°ízení se systémem Android? Ano
Znáte n¥kterou aplikaci vyuºívající roz²í°enou realitu? Ne
C.1.2
Záznam testu
úkol 1 00:08 úkol úsp¥²n¥ dokon£en úkol 2 00:12 úkol úsp¥²n¥ dokon£en úkol 3 00:18 úkol úsp¥²n¥ dokon£en úkol 4 00:19 aplikace nezaznamenala swipe gesto 00:29 úkol úsp¥²n¥ dokon£en úkol 5 00:35 aplikace byla pouze minimalizována, úkol dokon£en C.1.3
Dotazník
Jak se Vám aplikace ovládala? 1
Jaký dojem na Vás ud¥lala roz²í°ená realita v podání testované aplikace? Je to p¥kný, ale moc nevím, k £emu to je.
69
70
PÍLOHA C.
C.1.4
ZÁZNAM Z TESTOVÁNÍ MOBILNÍ ÁSTI
Shrnutí
P°estoºe první participant vid¥l aplikaci s roz²í°enou realitou poprvé, vedl si p°i testování velmi dob°e, pro²el v²emi testovanými úkoly naprosto bez problém·. V záv¥re£ném rozhovoru mi prozradil, ºe se mu roz²í°ená realita líbí, ale moc neví, k £emu by ji v telefonu poºíval.
C.2
Participant 2
C.2.1
Screener
Pouºíváte mobilní za°ízení se systémem Android? Ano
Znáte n¥kterou aplikaci vyuºívající roz²í°enou realitu? Ne
C.2.2
Záznam testu
úkol 1 00:10 úkol úsp¥²n¥ dokon£en úkol 2 00:15 participant zkou²í, zda není nápov¥da posunovací 00:20 úkol úsp¥²n¥ dokon£en úkol 3 00:30 úkol úsp¥²n¥ dokon£en úkol 4 00:40 úkol úsp¥²n¥ dokon£en úkol 5 00:43 aplikace byla pouze minimalizována, úkol dokon£en C.2.3
Dotazník
Jak se Vám aplikace ovládala? 1
Jaký dojem na Vás ud¥lala roz²í°ená realita v podání testované aplikace? Taková hezká blbost, ale docela mi vadilo, ºe se otá£ela obrazovka.
C.3.
PARTICIPANT 3
C.2.4
71
Shrnutí
Druhý participant taktéº nem¥l sebemen²í problémy s ovládáním aplikace. Jediné nezvyklé chování u n¥j bylo pozorováno, kdyº se pokou²el rolovat nápov¥du nahoru a dol·, jelikoº si myslel, ºe není úplná. V rozhoru po testování mi participant, který vid¥l aplikaci s roz²í°enou realitou poprvé, prozradil, ºe se mu princip roz²í°ené reality líbí a ur£it¥ by se s podobnou aplikací pochlubil i ve svém okolí, av²ak jiný ú£el neº pobavení p°átel v této aplikaci nevidí.
C.3
Participant 3
C.3.1
Screener
Pouºíváte mobilní za°ízení se systémem Android? Ano
Znáte n¥kterou aplikaci vyuºívající roz²í°enou realitu? Ano
C.3.2
Záznam testu
úkol 1 00:08 úkol úsp¥²n¥ dokon£en úkol 2 00:21 úkol úsp¥²n¥ dokon£en úkol 3 00:30 úkol úsp¥²n¥ dokon£en úkol 4 00:50 úkol úsp¥²n¥ dokon£en úkol 5 00:52 úkol úsp¥²n¥ dokon£en C.3.3
Dotazník
Jak se Vám aplikace ovládala? 1
Jaký dojem na Vás ud¥lala roz²í°ená realita v podání testované aplikace?
Dobrý, zvládalo to i velké úhly, sice se to trochu sekalo, ale lep²í neº polovina jiných aplikací.
72
PÍLOHA C.
C.3.4
ZÁZNAM Z TESTOVÁNÍ MOBILNÍ ÁSTI
Shrnutí
Participant £íslo t°i pro²el testované úkoly bez jediného zaváhání. V záv¥re£ném pohovoru jsme se s participantem bavili o pouºitém principu roz²i°ování reality, jelikoº participant je také vývojá° mobilních aplikací. Participant pochválil zorné úhly, které aplikace zvládá a trochu kritizoval plynulost prezentace.
C.4
Participant 4
C.4.1
Screener
Pouºíváte mobilní za°ízení se systémem Android? Ano
Znáte n¥kterou aplikaci vyuºívající roz²í°enou realitu? Ano
C.4.2
Záznam testu
úkol 1 00:10 úkol úsp¥²n¥ dokon£en úkol 2 00:12 participant zkou²í, zda není nápov¥da posunovací 00:13 participant si nápov¥du nep°e£etl úkol 3 00:20 úkol úsp¥²n¥ dokon£en úkol 4 00:21 uºivatel se vrací k nápov¥d¥ 00:40 úkol úsp¥²n¥ dokon£en úkol 5 00:41 úkol úsp¥²n¥ dokon£en C.4.3
Dotazník
Jak se Vám aplikace ovládala? 1
Jaký dojem na Vás ud¥lala roz²í°ená realita v podání testované aplikace? Docela se to seká, ale dob°e si to drºí p°edlohu.
C.4.
PARTICIPANT 4
C.4.4
73
Shrnutí
Posledním participantem byl, stejn¥ jako v p°edchozím p°ípad¥, vývojá° mobilních aplikací, coº moºná zp·sobilo n¥které jeho postupy p°i pln¥ní testovaných úkol·, kdy nap°íklad vynechal seznámení se s nápov¥dou aplikace a rad¥ji zkoumal plynulost animací p°i p°echodech mezi fotogra emi podporovaných marker·. K nápov¥d¥ se pozd¥ji vrátil, kdyº nev¥d¥l jak spustit fotoaparát pro snímání reálné scény.
74
PÍLOHA C.
ZÁZNAM Z TESTOVÁNÍ MOBILNÍ ÁSTI
P°íloha D
Manuál aplikace D.1
Minimální poºadavky
Desktop editor • opera£ní systém Microsoft Windows XP • procesor 1.6GHz • 512MB RAM • 128MB gra cké pam¥ti
Generovaná Android aplikace • opera£ní systém Android 4.0 (Ice Cream Sandwich) • procesor ARM 600MHz • 256MB RAM • OpenGL ES 2.0 • vestav¥ná kamera D.2
Pokyny pro spu²t¥ní
Desktopový editor se spou²tí pomocí souboru run.bat. Pro spu²t¥ní vygenerované aplikace je ji nejd°íve zapot°ebí nainstalovat do za°ízení. Pro tento ú£el lze vyuºít Android SDK, které je sou£ástí editoru, kdy sta£í spustit jednoduchý p°íkaz %slozka_editoru%\tools\android-sdk-windows\platform-tools\adb install %cesta_k_apk%
Nebo APK soubor nakopírovat do za°ízení a pomocí n¥jakého le managera instalovaného v za°ízení vyhledat a nainstalovat. 75
76
D.3
PÍLOHA D.
MANUÁL APLIKACE
P°íru£ka pro programátora
Zdrojové kódy byly vyvíjeny pomocí IDE Eclipse. Kaºdá £ást °e²ení obsahuje projekt, který lze snadno prost°ednictvím Eclipse importovat.
Mobilní £ást Pro editaci mobilní £ásti je nutné mít zprovozn¥né vývojové prost°edí pro
Android. Znamená to tedy mít Eclipse s instalovanými ADT (Android Development Tools) a správn¥ nastavenou cestu k lokáln¥ instalovanému Android SDK se staºeným Android API 19, které aplikace vyuºívá. Krom¥ samotného projektu aplikace je nutné do Eclipse importovat i dvojici projekt·, na kterých je mobilní £ást závislá. Vyºadované projekty jsou vºdy ve sloºce libs
AnAR-Resources Odd¥lený projekt obsahující resources pro snadn¥j²í zm¥ny p°i generování aplikace. OpenCV Library - 2.4.7.1 Projekt poskytující rozhraní knihovny OpenCV Desktop editor Druhou £ást °e²ení lze taktéº snadno importovat do Eclipse pomocí vytvo°eného projektu. Pokud je pro vývoj vyuºíváno prost°edí s 32 bit architekturou, je v projektu zapot°ebí upravit pouºívané knihovny. Ve sloºce libs jsou vºdy ob¥ varianty, jak pro 32 bit, tak i 64 bit. Dále je po importu nutné zkontrolovat hodnotu prom¥nné APPLICATION_PROJECT_PATH ve t°íd¥ cz.kukr.dp.canar.Properties, která musí ukazovat na root sloºku projektu mobilní £ásti. P°i vytvá°ení spustitelného JAR souboru je nutné toto také dodrºet.
P°íloha E
Obsah p°iloºeného CD research/androidAREngine/ Sloºka se zdrojovými kódy Android aplikací vyuºitých p°i testování AR engin· research/featureMatching/ Sloºka se zdrojovými kódy Android aplikace vyuºité pro testování feature detektor· a extraktor· source/android/ Sloºka se zdrojovými kódy Android aplikace vyuºité jako základ pro generování source/desktop/ Sloºka se zdrojovými kódy desktopového editoru text/ Sloºka obsahuje pdf s textem této práce text/latex/ Sloºka se zdrojovým kódem LATEX usabilityTesting/android/ Sloºka se záznamy z testování pouºitelnosti generované mobilní aplikace usabilityTesting/desktop/ Sloºka se záznamy z testování pouºitelnosti desktopového editoru Editor.zip Archiv obsahující spustitelnou verzi celého °e²ení
77
