Aplikacja mobilna z wykorzystaniem rozszerzonej rzeczywistosci´ · Aplikacja mobilna z...

Politechnika WarszawskaWydział Elektroniki i Technik Informacyjnych

Instytut Informatyki

Rok akademicki 2013/2014

Praca dyplomowa inzynierska

Mikołaj Aleksander Markiewicz

Aplikacja mobilna z wykorzystaniemrozszerzonej rzeczywistosci

Opiekun pracy:

dr inz. Jakub Janusz Koperwas

Ocena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Podpis Przewodniczacego

Komisji Egzaminu Dyplomowego

Specjalnosc: Informatyka –Inzynieria systemów informacyjnych

Data urodzenia: 5 pazdziernika 1991 r.

Data rozpoczecia studiów: 1 pazdziernika 2010 r.

Zyciorys

Nazywam sie Mikołaj Markiewicz, urodziłem sie 5 pazdziernika 1991 roku wWarszawie. W 2010 roku ukonczyłem XLVII liceum ogólnokształcace im. St. Wy-spianskiego w Warszawie i rozpoczałem studia na wydziale Elektroniki i TechnikInformacyjnych Politechniki Warszawskiej. Od kilku lat jestem aktywnym sedziasiatkarskim w Mazowiecko-Warszawskim Zwiazku Piłki Siatkowej. Aktualnie kon-tynuuje studia i zdobywam doswiadczenie zawodowe jako Młodszy Inzynier ds. Pro-dukcji Oprogramowania w firmie Samsung.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .podpis studenta

Egzamin dyplomowy

Złozył egzamin dyplomowy w dn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Z wynikiem .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Ogólny wynik studiów .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Dodatkowe wnioski i uwagi Komisji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Streszczenie

Praca ta prezentuje aplikacje mobilna wykorzystujaca elementy rozszerzonej rze-czywistosci, stworzona w ramach pracy dyplomowej. Poczatek poswiecony jest opi-sowi zakresu pracy oraz jej celowi, którym jest stworzenie gry wieloosobowej. Na-stepnie przedstawiony został opis proponowanej gry i wymagania postawione two-rzonej aplikacji. Przedstawione zostały elementy rozszerzonej rzeczywistosci w kon-tekscie aplikacji na urzadzenia mobilne oraz zwiezły opis ich działania. Zaliczaja siedo nich geolokalizacja, rozpoznawanie obiektów w obrazie i rozpoznawanie gestówprzestrzennych. Omówiono istniejace rozwiazania rozpoznawania gestów wykorzy-stujace tzw. Ukryte Modele Markova i algorytm Dynamic Time Warping. Nastepniezaprezentowano działanie własnej implementacji algorytmu DTW oraz analize jegomozliwosci. Ostatnia czesc zawiera opis implementacji gry wykorzystujacej architek-ture klient-serwer. Przedstawione zostały bardziej interesujace funkcje jak równiezelementy składajace sie na całokształt aplikacji.

Słowa kluczowe: Aplikacja mobilna, Android, Rozszerzona rzeczywistosc, Gesty,Vuforia, Google Services, Google App Engine.

Abstract

Title: Mobile application utilizing Augmented Reality

This paper describes mobile application, which has been created within diplomathesis. Application is utilizing Augmented Reality components. First part is dedica-ted to describe its scope and aim, which is to create multiplayer game. Next partis about gameplay proposal and given requirements to the application. Short actiondescription of Augmented Reality components is presented in mobile application con-text. Description includes geolocation, image and gesture recognition. This paperalso contains demonstration of currently available solutions for gesture recognition,which utilize Hidden Markov Models and Dynamic Time Warping algorithm. After-wards, is presented own implementation of DTW algorithm and analysis of its capa-bilities. Last part contains implementation details about created multiplayer game inclient-server architecture. Only most significant features and gameplay componentshas been presented.

Key words: Mobile application, Android, Augmented Reality, Gestures, Vuforia,Google Services, Google App Engine.

Spis tresci

1. Wstep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1. Cel i zakres pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Zawartosc pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3. Przyjete załozenia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2. Specyfikacja wymagan dla aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1. Przebieg rozgrywki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2. Wymagania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2.1. Wymagania funkcjonalne . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2.2. Wymagania niefunkcjonalne . . . . . . . . . . . . . . . . . . . . . . . . . 4

3. Rozszerzona rzeczywistosc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.1. Wymagania biznesowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2. Lokalizacja geograficzna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3. Czujniki urzadzenia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.4. Rozpoznawanie obrazu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.5. Przeglad dostepnych rozwiazan . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.5.1. Rozpoznawanie obiektów w obrazie . . . . . . . . . . . . . . . . . . . . . 93.5.2. Rozpoznawanie gestów w przestrzeni . . . . . . . . . . . . . . . . . . . . 11

4. Implementacja i analiza wykorzystania algorytmu DTW . . . . . . . . . . . . . . 194.1. Przyjete załozenia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2. Implementacja algorytmu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3. Testy dopasowania gestu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.4. Analiza działania algorytmu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.5. Wnioski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.6. Opis działania aplikacji testowej . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5. Realizacja aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.1. Zastosowane narzedzia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.2. Wykorzystane technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3. Wybór technologii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.4. Architektura rozwiazania . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.5. Struktura aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.5.1. Klient . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.5.2. Serwer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.6. Struktura bazy danych . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.7. Sposób komunikacji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.8. Rozpoznawanie obrazów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.8.1. Zdefiniowane znaczniki . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.8.2. Tworzenie własnych celów . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.9. Przebieg walki miedzy graczami . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.10.Dodatkowe elementy rozgrywki . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.11.Napotkane problemy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.12.Mozliwe kierunki rozwoju aplikacji . . . . . . . . . . . . . . . . . . . . . . . . . 57

6. Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

1. Wstep

Tematem pracy jest aplikacja mobilna wykorzystujaca rozszerzona rzeczywi-stosc. Do stworzenia wybrana została gra wieloosobowa wykorzystujaca elementytakie jak geolokalizacja, rozpoznawanie obiektów w obrazie z kamery oraz rozpo-znawanie gestów przestrzennych. Ze wzgledu na wielkosc zagadnienia jakim jestogólne pojecie rzeczywistosci rozszerzonej (ang. Augmented Reality (AR)), szerszejanalizie została poddana czesc dotyczaca rozpoznawania gestów. W pracy opisanezostały teoretyczne podstawy, technologie wykorzystywane w projekcie oraz two-rzona aplikacja.

1.1. Cel i zakres pracy

Celem pracy jest stworzenie gry wieloosobowej na platforme Android w oparciuo architekture klient-serwer przy wykorzystaniu interakcji ze swiatem AugmentedReality (AR). Składaja sie na nia nastepujace czesci:

— Aplikacja kliencka - działajaca jako warstwa prezentacji dla uzytkownika i po-zwalajaca na jego interakcje, wykorzystujac mozliwosci urzadzenia,

— Serwer - przechowujacy informacje o rozgrywce i odpowiedzialny za jej przebieg.

Dodatkowym elementem jest zgłebienie i wykorzystanie w aplikacji zagadnieniajakim jest rozszerzona rzeczywistosc. Wybrane zostały zagadnienia rozpoznawaniagestów przestrzennych i obiektów w obrazie, w których skład wchodza:

— Analiza mozliwosci rozpoznawania gestów przestrzennych z wykorzystaniem wy-branego algorytmu i jego implementacja,

— Wykorzystanie mozliwosci urzadzenia do rozpoznawania obiektów w obrazie.

Tworzenie wyszukanego graficznego interfejsu uzytkownika (ang. GUI) zostałozaniedbane, gdyz wykracza to poza zakres niniejszej pracy i mogło by byc tematemwielu prac z nia niezwiazanych.

1.2. Zawartosc pracy

Praca została podzielona na 6 sekcji, z których pierwsza zawiera wprowadzeniedo pracy. Opisuje jej cel, forme i wstepne załozenia.

Rozdział 2 przedstawia opis zaproponowanej gry i zebrane wymagania, którepostawiono tworzonej aplikacji.

Rozdział 3 zawiera ogólny opis czym jest rozszerzona rzeczywistosc w kontekscieaplikacji mobilnych oraz podstawy teoretyczne pomagajace w zrozumieniu niniej-szej pracy. W tej czesci przedstawiony został równiez przeglad dostepnych rozwia-zan w zakresie poszczególnych elementów AR oraz schematy działania przykłado-wych implementacji.

1.3. Przyjete załozenia 2

Rozdział 4 poswiecony jest szczegółowemu opisowi własnego rozwiazania w za-kresie rozpoznawania gestów przestrzennych. Zawiera opis zaimplementowanegoalgorytmu DTW i aplikacji stworzonej na potrzeby przeprowadzenia analizy jegomozliwosci. Przedstawione zostały testy i wnioski wyciagniete na podstawie otrzy-manych wyników.

Rozdział 5 opisuje srodowisko pracy i technologie wykorzystane w projekcie.Przedstawiona została architektura projektu i sposób komunikacji poszczególnychelementów. W rozdziale zawarty jest równiez opis poszczególnych elementów stwo-rzonej aplikacji, napotkane problemy oraz rozwazania dalszego kierunku rozwoju.

Ostatni, 6. rozdział zawiera podsumowanie wykonanej pracy. Opis co udało siewykonac w trakcie pracy nad projektem oraz osiagniete cele.

1.3. Przyjete załozenia

Dostepnych jest wiele róznych modeli urzadzen mobilnych z rodziny tzw. smart-fonów (ang. smartphone). Działaja one pod kontrola róznych systemów operacyj-nych, z których najpopularniejsze sa Android, iOS, Windows Phone.

Zwazywszy na te róznorodnosc, poczynione zostały pewne załozenia których nie-spełnienie moze znaczaco obnizyc uzytecznosc tworzonej aplikacji badz jej całko-wita nieprzydatnosc. Do pełnego jej działania wybrane zostały nastepujace ograni-czenia:

— System operacyjny Android w wersji 2.3.3 Gingerbread i wyzsze. Wersja taudostepnia interfejs programistyczny (ang. API) w wersji 10,

— Dostep do internetu przez pakietowa transmisje danych GPRS lub Wi-Fi. Nie jestwymagane nieprzerwane połaczenie ze wzgledu na zastosowanie komunikacji woparciu o zapytania HTTP,

— Nadajnik GPS, wykorzystywany do uzyskania dokładniej lokalizacji,— Aparat (ang. Camera) dostarczajacy kolejnych klatek obrazu w czasie rzeczywi-

stym. Wykorzystanie jest nierozerwalnie zwiazane z przetwarzaniem obrazu wkontekscie AR,

— Akcelerometr, wykorzystywany przy rozpoznawaniu gestów przestrzennych,— Opcjonalnie zyroskop, który zwieksza dokładnosc odczytów akcelerometru1.

Platforma została wybrana z powodu znaczacego udziału w runku urzadzen mo-bilnych. Urzadzenia działajace pod kontrola systemu Android plasuja sie na pozio-mie 81%2. Jest to platforma szeroko wykorzystywana, dobrze udokumentowana iciagle dynamicznie rozwijana.

Drugim znaczacym czynnikiem był fakt posiadania urzadzenia z tym własniesystemem. Ponadto szeroka gama urzadzen wyposazona jest we wszystkie kom-ponenty niezbedne do działania aplikacji dlatego tez istnieje potencjalnie szerokiegrono odbiorców aplikacji.

1 Dokładniejszy opis w sekcji 3.32 http://www.dobreprogramy.pl/Statystyki-urzadzen-mobilnych-w-Q3-2013-Android-

kontynuuje-dominacje-a-Windows-Phone-podwaja-udzial-w-rynku,News,49002.html

2. Specyfikacja wymagan dla aplikacji

W ramach pracy miała powstac aplikacja mobilna w postaci gry wieloosobowejwykorzystujacej elementy rozszerzonej rzeczywistosci. Powinna udostepniac moz-liwosc rozgrywki wielu graczom jednoczesnie i ich wzajemna interakcje. Aplikacjapowinna wykorzystywac elementy AR takie jak geolokalizacja, rozpoznawanie ge-stów i obiektów w obrazie z kamery.

Ponizej przedstawiona została propozycja gry i opis postawionych wymagan.

2.1. Przebieg rozgrywki

Graczem jest uzytkownik wyposazony w telefon komórkowy z dostepem do in-ternetu. Porusza sie on po swiecie rzeczywistym szukajac innych osób bedacychw grze. Gra jest wieloosobowa i pozwala na komunikacje graczy, którzy współza-wodnicza ze soba - wzajemnie sie eliminujac. Gra ma charakter konkurencyjny zelementami współpracy.

Celem gry jest atakowanie przeciwników oraz zdobywanie pieniedzy i punktówdoswiadczenia. Aby to osiagnac, gracze musza znajdowac sie w poblizu swojejlokalizacji. Wtedy tez mozliwa jest ich walka, podczas której dostepna jest zarównomozliwosc obrony jak i kontrataku. Rózne rodzaje broni oraz czary1 zwiekszajaich skutecznosc. Przegrany w pojedynku traci zgromadzone pieniadze na rzeczwygranego. Zwyciezca zdobywa równiez punkty doswiadczenia.

W grze obecne sa dodatkowe elementy pomagajace graczowi w trakcie zabawy.Naleza do nich:— Umiejetnosci - wybierane przez gracza, zwiekszajace jego mozliwosci w walce,— Sklepy - ukryte w rzeczywistych lokalizacjach, do kupowania ekwipunku,— Zlecenia - równiez ukryte w rzeczywistych miejscach, jako dodatkowe zródło

pozyskiwania pieniedzy.Podczas rozgrywki gracz decyduje o nabywanych umiejetnosciach oraz zosta-

wionych zleceniach i wiadomosciach dla innych osób. Wykorzystujac kamere urza-dzenia zostawia wiadomosci widziane przez uczestników rozgrywki. W trakcie walkiwykonuje gest urzadzeniem, rzucajac w ten sposób zaklecie. Kontrolowanie gry wy-maga tylko dotyku ekranu i celowania obiektywem kamery w odpowiednie miejsca.

Gdy gracz rozpoczyna gre musi sie zarejestrowac, a nastepnie zalogowac. Otrzy-muje on domyslne wyposazenie i od razu uczestniczy w rozgrywce. Nastepniegromadzac doswiadczenie zdobywa kolejne poziomy. W trakcie rozgrywki jest nabiezaco informowany o zdarzeniach dotyczacych jego postaci.

1 Dostepne jako forma ataku

2.2. Wymagania 4

2.2. Wymagania

Wymagania jakie postawiono tworzonej aplikacji dziela sie na kilka czesci. Głów-nym aspektem jest mozliwosc czesciowej interakcji miedzy graczami, która jestobecna w kazdej z nich. Mozna wiec wyróznic nastepujace elementy:

— Komunikacja uzytkownika z serwerem gry - ciagłosc połaczenia z serwerem iinformowanie o aktualnym stanie rozgrywki,

— Wykorzystanie AR za pomoca kamery urzadzenia - mozliwosc rozpoznawaniazdefiniowanych znaczników jak i zostawiania wiadomosci w rzeczywistych miej-scach, które beda widoczne przez innych uzytkowników,

— Wykorzystanie AR za pomoca czujników urzadzenia - uzycie rozpoznawaniagestów w trakcie walki jako zdefiniowanych czarów,

— Dodatkowe elementy rozgrywki - urozmaicenie gry przez dodanie elementów ta-kich jak atrybuty opisujace graczy, mozliwosc rozwoju postaci i zakupu przed-miotów w grze.

2.2.1. Wymagania funkcjonalne

Tworzone aplikacje powinny udostepniac nastepujace funkcje:

1 Przechowywanie danych o przebiegu rozgrywki na zdalnym serwerze,2 Logowanie sie graczy na unikalne konto - mozliwa jednokrotna rejestracja i

mechanizm automatycznego logowania,3 Działanie aplikacji klienckiej jako pierwszoplanowej lub w tle - jako serwis,

jednoczesnie informujac gracza o zdarzeniach,4 Gracz jest opisywany wieloma atrybutami, mozliwy jest wybór jego umiejetnosci

w kolejnych etapach gry,5 Wysyłanie w okreslonym przedziale czasu informacji o aktualnej pozycji gracza,6 Informowanie graczy o zdarzeniach przez uzycie mechanizmu powiadamiania.

Podejscie to nie wymaga ciagłego odpytywania serwera,7 Mozliwosc zaatakowania gracza, gdy znajduje sie w poblizu,8 Wybór rodzaju ataku: pasywnie lub przy uzyciu czaru - wykonanie gestu prze-

strzennego urzadzenia lub rysowanego na ekranie,9 Mozliwosc obrony przed atakiem wykonujac proste zadanie logiczne,10 Zdobywanie pieniedzy i doswiadczenia w momencie wygrania walki,11 Mozliwosc wejscia do ukrytej czesci aplikacji klienckiej przez rozpoznanie zdefi-

niowanego znacznika w obrazie z kamery,12 Mozliwosc zostawiania wiadomosci dla innych uzytkowników, w rzeczywistych

miejscach z uzyciem kamery i aktualnej lokalizacji,13 Mozliwosc wysyłania krótkich wiadomosci do graczy gdy znajduja sie w poblizu,14 Mozliwosc tworzenia zlecenia zabójstwa na przeciwnika spotkanego w przeszło-

sci,15 Mozliwosc kupowania nowych rodzajów broni i czarów.

2.2.2. Wymagania niefunkcjonalne

1 Prosty i intuicyjny interfejs uzytkownika pozwalajacy na sprawne poruszanie siepo aplikacji,

2 Aplikacja powinna działac na jak najwiekszej liczbie urzadzen wyposazonych wsystem Android,

2.2. Wymagania 5

3 Chwilowy brak dostepu do internetu nie powinien wykluczac gracza z rozgrywki.Jest to mozliwe przez zastosowanie bezstanowego protokołu HTTP,

4 Czas realizacji zadania uzytkownika na serwerze nie powinien trwac dłuzej nizsekunde. Oferowane mozliwosci skalowania i replikacji danych na serwerzeGoogle App Engine (GAE) powinny sprostac wymaganiom,

5 Serwer aplikacji powinien byc dostepny 24 godziny na dobe i skalowalny dowymagan uzytkowników.

3. Rozszerzona rzeczywistosc

Rzeczywistosc rozszerzona (ang. Augmented Reality) [11] polega na wykorzy-staniu szeregu informacji zebranych z otoczenia w celu dostarczenia dodatkowychmozliwosci, a co za tym idzie - dodatkowych wrazen dla uzytkownika. Dane od-czytywane sa z otoczenia za pomoca czujników wbudowanych w urzadzenie. Sa tozazwyczaj mniejsze komponenty takie jak akcelerometr, zyroskop, jak i te wieksze- kamera. Dane te sa zbierane i na ich podstawie, na ekranie urzadzenia prezento-wane sa dodatkowe tresci, badz generowane sa róznego rodzaju modele lub efektygraficzne. W znaczacej wiekszosci pozwala to na zwiekszenie interakcje uzytkow-nika z aplikacja.

3.1. Wymagania biznesowe

W pracy postawione zostały wymagania na wykorzystanie elementów umozli-wiajacych interakcje ze swiatem rzeczywistym. Wchodzace w zakres i mozliwe dorealizacji sa nastepujace trzy:

— Pozyskiwanie aktualnej pozycji urzadzenia, wykorzystywanej w grze wieloosobo-wej,

— Zdefiniowanie gestów przestrzennych i mozliwosc ich wykorzystania w aplikacji,— Ukrycie dodatkowych tresci w rzeczywistych miejscach widzianych tylko z po-

moca urzadzenia.

Ponizej przedstawiony został ich opis oraz sugerowane rozwiazania na urzadze-nia mobilne.

3.2. Lokalizacja geograficzna

Lokalizacja (ang. geolocation) polega na wykorzystaniu aktualnej lokalizacji geo-graficznej uzytkownika. Jako ze współczesne urzadzenia mobilne w znacznej wiek-szosci sa wyposazone w nadajniki GPS, mozliwe jest dosc dokładne okreslenie ichpołozenia. W przypadku współczesnych telefonów komórkowych, tzw. smartfonów(ang. smartphone), dodatkowymi komponentami sa takze odbiorniki GSM czy na-wet Wi-Fi. Dostarczaja one w duzej mierze przyblizone połozenie1 jednakze czestow krótszym czasie.

GSM - Siec Komórkowa

Odczyty połozenia z tego zródła naleza do najmniej dokładnych i sa na poziomieod kilkudziesieciu do kilkuset metrów. Wynika to z faktu, ze połozenie jest ustalanena podstawie porównania siły sygnału który jest odbierany z pobliskich stacji

1 Przykład pokazano na rysunku 3.1

3.3. Czujniki urzadzenia 7

Rysunek 3.1. Przyblizone połozenie

bazowych operatora. Znajac ich lokalizacje mozna z pewna dokładnoscia obliczycaktualne połozenie urzadzenia.

Wi-Fi

Okreslenie połozenia nastepuje dzieki wyznaczeniu potencjalnego punktu znaj-dowania sie urzadzenia przez wykonanie triangulacji sygnału - znajac połozenie ibedac w zasiegu sygnału co najmniej 3 punktów dostepowych (ang. Access Point).Metoda ta jest dokładniejsza od poprzedniej jednak wymaga znajomosci lokalizacjipunktów dostepowych i obecnosci w ich zasiegu, który nie jest tak dostepny jaksiec komórkowa.

GPS

Dostarcza danych o połozeniu uzytkownika na podstawie danych odebranych zsatelitów krazacych po orbicie Ziemi. Dokładnosc jest rzedu kilkunastu metrów.Wadami systemu jest to ze do poprawnego działania system musi połaczyc sie zco najmniej kilkoma (˜7) satelitami. Moze to potrwac nawet kilka minut. Dodat-kowo pobór energii jest wiekszy niz w przypadku korzystania z sygnału GSM lubWiFi. Ponadto ze wzgledu na konstrukcje systemu, urzadzenie wymaga działaniana otwartej przestrzeni co dyskwalifikuje go w wielu zastosowaniach takich jakokreslanie pozycji wewnatrz budynków (ang. indoor positioning system), badz donawigacji w tunelach itp.

3.3. Czujniki urzadzenia

Do rozpoznawania gestów urzadzenia mozna wykorzystac poszczególne czujnikibadz tzw. fuzje czujników (ang. Sensor Fusion) [12]. Najczesciej dostepnymiczujnikami sa:

— Akcelerometr - czujnik ruchu, który dostarcza danych o przesunieciu urzadze-nia w trzech jego osiach, na podstawie zmian przyspieszenia działajacego naurzadzenie. Odczytywane wartosci wystepuja w jednostkach m/s2

— Zyroskop - czujnik ruchu, który dostarcza danych o obrocie urzadzenia wzgle-dem niego samego i w trzech jego osiach. Wartosciami odczytywanymi sa zmianyobrotu w jednostkach rad/s.

3.4. Rozpoznawanie obrazu 8

— Czujnik magnetyczny - jest to czujnik połozenia, na którego podstawie moznawyznaczyc kierunek w którym urzadzenie jest zwrócone. Mierzy on dane wtrzech osiach na podstawie odczytów wartosci otaczajacego go pola magnetycz-nego, w jednostkach µT

Połaczenie elementów - Sensor Fusion

Metoda ta polega na wykorzystaniu wielu czujników w celu otrzymania dokład-niejszych odczytów. Mozna to osiagnac dzieki kompensacji błedów pomiarów jed-nego czujnika - odczytami innego.

Konkretne czujniki obarczone sa błedami. W przypadku akcelerometru wyste-puje problem zachowania orientacji tzw. (ang. tilt). Zmieniajaca sie orientacjaurzadzenia wpływa na odczyty akcelerometru powodujac niedokładnosci. Zyroskopnarazony jest na problem przesuniecia (ang. drift), który powstaje przez niedo-kładnosci zwiazane z obliczaniem obrotów urzadzenia. Czujnik ten mierzy zmianyobrotu, które równiez obarczone pewnym błedem. W krótkim czasie pomiaru, niestwarza to problemów, lecz w czasie znaczaco przekłamuje odczyty.

Przykładem zastosowania fuzji czujników jest obecny w systemie An-droid typ sensora TYPE_LINEAR_ACCELERATION2. Dostepny jest równiez typTYPE_ACCELEROMETER, który uwzglednia w swoich odczytach przyspieszenie gra-witacyjne działajace na urzadzenie. W przeciwienstwie do niego, pierwszy próbujewykorzystac wszystkie dostepne czujniki takie jak zyroskop i czujnik magnetycznyw celu lepszego odizolowania siły grawitacji.

3.4. Rozpoznawanie obrazu

Tradycyjne podejscie do rozpoznawania obiektów w obrazie uzywajac niezmien-ników momentowych i cech obiektów nie sprawdziłoby sie w rozpatrywanym za-stosowaniu. Wynika to duzej liczby klatek odczytywanych z kamery na którychobliczenia zajmowałyby zbyt wiele czasu. Dodatkowo uniemozliwiłoby wyszuki-wanie obrazem - charakterystycznej sceny, na co pozwala wykorzystanie innegopodejscia.

Aby udostepnic taka mozliwosc, stosowane sa zaawansowane algorytmypolegajace na znajdywaniu punktów charakterystycznych obrazu takich jakkrawedzie. Wystepuja one czesto na kontrastujacych ze soba czesciach obrazu.Algorytmy działajace na urzadzeniu mobilnym z systemem Android muszawykonywac obliczenia efektywnie, dlatego kod za to odpowiedzialny napisanyjest w natywnym jezyku programowania i kompilowany do postaci bibliotekładowanych dynamicznie (ang. shared libraries).

Ze wzgledu na skomplikowane działanie algorytmów, których implementacja niejest udostepniana, w nastepnej czesci 3.5.1 przedstawione jest działanie metody naprzykładzie jednego z dostepnych rozwiazan.

2 http://developer.android.com/guide/topics/sensors/sensors_overview.html

3.5. Przeglad dostepnych rozwiazan 9

3.5. Przeglad dostepnych rozwiazan

3.5.1. Rozpoznawanie obiektów w obrazie

Istnieje kilka dostepnych bibliotek, które dostarczaja ogromne mozliwosci rozpo-znawania obiektów w czasie rzeczywistym i generowania modeli trójwymiarowychna ekranie urzadzen. Znane sa pod nazwa Augmented Reality SDK. Korzystaniez wiekszosci jest darmowe przy zachowaniu pewnych warunków takich jak np.pokazywanie znaku wodnego (ang. watermark) producenta. Dostepne rozwiazaniana urzadzenia z systemem Android to m.in.:

— Vuforia - biblioteka dostarcza wielu funkcji takich jak rozpoznawanie wieluobiektów jednoczesnie, rozpoznawanie tekstu, tworzenie celów (ang. targets)z obrazu w czasie rzeczywistym itp. Istnieje mozliwosc połaczenia z silnikiemUnity3 w celu generowania modeli i animacji na ekranie urzadzenia. Daje moz-liwosc ingerencji w sekwencje akcji rozpoznawania w warstwie posredniczacejJNI,

— Metaio - dostarcza zblizonych funkcji jak pierwsza z wymienionych bibliotek.Implementuje własny silnik graficzny pozwalajacy w łatwy sposób generowacobiekty 3D. Mozliwe jest tworzenie widoku aplikacji przy uzyciu Augmented Re-ality Expression Language (AREL) - warstwy HTML wykorzystujacej do komuni-kacji jezyk JavaScript,

— Wikitude - biblioteka łaczaca w sobie wykorzystanie geolokalizacji, rozpoznawa-nia obiektów i generowania grafiki na ekranie. Takze oferuje mozliwosc tworze-nia widoku w oparciu o Augmented Reality Markup Language (ARML),

— D’Fusion - rozwiazanie kładace wiekszy nacisk na generowanie modeli trójwy-miarowych i ich interakcje z uzytkownikiem. Dostarcza mozliwosci podobnychjak poprzednik.

Działanie

Opis działania przedstawiony został na przykładzie wykorzystanej w projekciebiblioteki - Vuforii. Posiada ona w swoim asortymencie takie mozliwosci jak roz-poznawanie obiektów w obrazie w czasie rzeczywistym z lokalnego repozytoriumobiektów jak i rozpoznawanie w chmurze4. Pozwala równiez zdefiniowac uzytkow-nikowi koncowemu własne cele (ang. targets), których rozpoznanie mozliwe jest wprzyszłosci. Dostarcza równiez danych o rozmiarze obiektu i kacie pod jakim zostałznaleziony w postaci macierzy pozycji (ang. pose matrix) zilustrowanej na rysunku3.2.

Metoda

Rozpoznawanie obiektów polega na wyznaczeniu naturalnych cech obrazu. Ob-razy sa klasyfikowane na ich podstawie przez 5-cio stopniowy ranking. Obrazyposiadajace ranking 0 nie sa w ogóle rozpoznawane, im lepszy ranking tym łatwiejje rozpoznac.

Cechami charakterystycznymi w obrazie sa ostre i szpiczaste szczegóły.

3 http://unity3d.com/4 Róznice w podejsciu dla biblioteki Vuforia pokazane sa w tabeli na stronie

https://developer.vuforia.com/resources/dev-guide/developer-workflow-image-targets


Rysunek 3.2. Przykład rozpoznania obiektu z wyznaczonym piwotem

Uwaga. Miekkie (ang. soft) rogi nie sa oznaczane jako cechy. Przykładowe cechypokazane zostały na rysunku 3.3 jako zółte krzyzyki.

Rysunek 3.3. Cechy w obrazie

Lokalna baza

Lokalne rozpoznawanie obiektów polega na stworzeniu bazy obrazów przy uzy-ciu narzedzia dostarczanego przez autorów biblioteki. W przypadku Vuforii, narze-dziem tym jest Target Manager5. Po wgraniu plików na serwer sa one analizowanew celu wyznaczenia cech. Nastepnie mozna sciagnac wybrane cele do jednej bazylokalnej. Tworzone sa dwa pliki:

— Plik .xml zawierajacy konfiguracje obiektów przedstawiony na wydruku 3.1,— Plik .dat zawierajacy dane binarne przechowujace informacje o cechach wy-korzystywane w procesie rozpoznawania.

1 <?xml version=" 1.0 " encoding="UTF−8"?><QCARConfig xmlns:xsi=" http://www.w3. org/2001/XMLSchema−instance "

5 https://developer.vuforia.com/target-manager


xsi:noNamespaceSchemaLocation=" qcar_config . xsd"><Tracking>

5 <ImageTarget size="324 283.5 " name="metro " /><ImageTarget size="346 209" name="tram" /><ImageTarget size="432 194" name="bus" /><ImageTarget size="590 300" name=" l i d l " /><ImageTarget size="422.149017 464" name=" frog " />

10 </Tracking></QCARConfig>

Wydruk 3.1. Przykładowy plik lokalnej bazy m.in. dla obiektów przedstawionychna rysunku 5.13

Uproszczony proces rozpoznawania przedstawiony został na diagramie 3.4. Napoczatku aplikacja inicjuje biblioteke, a nastepnie ramki obrazu z kamery sa pobie-rane w czasie rzeczywistym. Poddawane sa konwersji z formatu kamery np. YUV12do formatu umozliwiajacego rozpoznanie np. RGB565. W momencie trafnego roz-poznania, aplikacja jest powiadamiana wraz z informacjami o obiekcie takimi jaknazwa zdefiniowana w bazie i macierza pozycji na ekranie.

Baza na serwerze

Tworzenie obrazów do rozpoznania odbywa sie w taki sam sposób jak w przy-padku lokalnej bazy - takze przy uzyciu tego samego narzedzia. Róznica jest rodzajbazy która jest tworzona i mozliwosc umieszczenia dodatkowych metadanych dlaobrazu. Kazda utworzona baza udostepnia klucze dostepu dla klienta dzieki którymmozliwe jest wykonywanie zapytan w trakcie rozpoznawania. Klucze te umozliwiajadostep do bazy jak równiez jednoznacznie ja identyfikuja. Dzieki takiemu podejsciuzyskujemy dostep do naszej unikalnej bazy na serwerze.

Uproszczony proces rozpoznawania przedstawiony został na diagramie 3.5. Napoczatku aplikacja poddaje ramke wstepnej selekcji. W momencie gdy zawierajakies cechy, wysyłana jest na serwer w celu analizy. Gdy serwer z sukcesem dopa-suje obraz, jest zwracana pozytywna odpowiedz wraz z metadanymi oraz wygene-rowanym identyfikatorem. Zastosowane sa równiez zabiegi optymalizacyjne, którezmniejszaja liczbe zapytan przez czesciowe składowanie odpowiedzi (ang. caching).

3.5.2. Rozpoznawanie gestów w przestrzeni

Niniejsza sekcja poswiecona jest opisowi juz istniejacych rozwiazan rozpoznawa-nia gestów w przestrzeni. Przedstawione zostana dwa uzyte podejscia wykorzystu-jace tzw. ukryte modele Markova (ang. Hidden Markov Model (HMM)) oraz algorytm„dynamicznego marszczenia czasu” (ang. Dynamic Time Warping (DTW)). Metodyte sa skutecznie stosowane w rozpoznawaniu mowy, a takze sprawdzaja sie przypróbach w rozpoznawania gestów.

Urzadzen które mozna wykorzystac jest wiele. Jednym z czesto wykorzysty-wanych do testów z wykorzystaniem czujników ruchu i pozycji jest kontroler dokonsoli Ninteno - Wii Remote. Jednakze coraz wieksze mozliwosci dostarczaja bar-dzo popularne smartfony (ang. smartphone) wyposazone w coraz to wieksza liczbeczujników.


Rysunek 3.4. Diagram sekwencji rozpoznawania z uzyciem lokalnej bazy

Istniejace metody

Istnieje ograniczona liczba rozwiazan wykorzystujacych HMM gdyz wymagajaone skomplikowanej implementacji. Ze wzgledu na specyfike podejscia, wymagawłozenia wiecej pracy w tworzenie nowych gestów i uczenie algorytmu.

Zastosowan Dynamic Time Warping (DTW) mozna spotkac o wiele wiecej, gdyzcharakteryzuje sie dosc prosta implementacja, a sam algorytm daje zadowalajacerezultaty.

Hidden Markov Model

HMM jest rozszerzeniem definicji łancucha Markova (ang. Markov Chain). Samłancuch opisuje pewien układ, który moze znajdowac sie w jednym ze stanówmodelu, w kazdym dyskretnie obserwowanym momencie. Prawdopodobienstwoprzejscia w nowy stan, zalezy tylko i wyłacznie od stanu modelu w jakim sieznajduje i jest opisywane wzorem 3.1. Prawdopodobienstwo przejsc stanów opisujemacierz 3.2.


Rysunek 3.5. Diagram sekwencji rozpoznawania z uzyciem zdalnej bazy

P (X(n+ 1) = x|X1 = x1, X2 = x2, ..., Xn = xn) = P (X(n+ 1) = x|Xn = xn) (3.1)

P =

[0.3 0.7

0.4 0.6

](3.2)

W klasycznym modelu Markova, stany sa znane obserwatorowi. W przypadkuHMM obserwator widzi tylko efekt funkcji losowych przypisanych do stanów, lecznie one same. Mozna zatem mówic o tzw. ukrytym modelu.

Wartosc ukrytej zmiennej x(t) zalezy tylko od zmiennej x(t−1), tak samo jak war-tosc obserwacji y(t) zalezy tylko od ukrytej zmiennej x(t) zilustrowanej na rysunku3.7.

Mozliwe sa rózne rodzaje modeli, zalezace od dopuszczalnych przejsc pomiedzystanami takich jak:

— ergodyczny - wszystkie przejscia sa dopuszczalne,


Rysunek 3.6. Przykład dwustanowego modelu łancucha Markova

Rysunek 3.7. Przykład schematu ukrytego modelu Markova

— (ang. left-to-right) - mozliwe przejscia tylko do nieodwiedzonych stanów.Wykorzystanie HMM w kontekscie rozpoznawania gestów polega na znalezieniu

prawdopodobienstwa, ze ciag obserwacji Y = (y1, y2, ..., yn) został wyemitowanyprzez ciag X = (x1, x2, ..., xn).

Przed wykorzystaniem metody do rozpoznawania, model wymaga „nauki” da-nymi trenujacymi. Sa one niezbedne do wyznaczenia macierzy prawdopodobien-stwa przejsc jak i okreslenia prawdopodobienstwa wystapienia danej sekwencji.Do trenowania modelu czesto wykorzystuje sie algorytm Bauma-Welcha6 pozwa-lajacy wyestymowac brakujace parametry modelu. Nastepnie na wytrenowanymzbiorze wykorzystuje sie algorytm forward-backward7 do wyznaczenia prawdopo-dobienstwa wystapienia sekwencji w modelu.

Dynamic Time Warping

Metoda ta polega na znalezieniu miary odległosci pomiedzy seriami danych za-leznych czasowo (ang. time-dependant), dodatkowo oznaczonych znacznikiem cza-sowym (ang. timestamp)8. W kontekscie rozpoznawania gestów moga byc to wek-tory odczytanych wartosci przyspieszenia w konkretnych odstepach lub momen-tach czasu.

Opis klasycznej metody i prób poprawy wydajnosci przez zastosowanie metoddajacych przyblizone rozwiazania mozna znalezc w artykułach [17, 18]. Przykładdopasowania dwóch serii danych przedstawiony na rysunku 3.8.

6 http://people.csail.mit.edu/stephentu/writeups/hmm-baum-welch-derivation.pdf7 http://www.cs.columbia.edu/˜mcollins/fb.pdf8 W opisywanym podejsciu nie odgrywa on zadnej roli, gdyz istotne tylko kolejne pomiary przy-

spieszenia


Rysunek 3.8. Przykładowe „marszczenie” dwóch serii danych zaleznych czasowo

Przy uzyciu algorytmu szukamy dopasowania do wzorca zaleznego od kolejnosci- czasu wystapienia danej wartosci. Tworzymy macierz gdzie do wierszy odwzo-rowywany jest jeden wektor (seria danych) wartosci a do kolumn drugi z nim po-równywany. Wyznaczamy dystans pomiedzy poszczególnymi punktami poczawszyod jednego z rogów macierzy. Komórki w których wyznaczany jest dystans mogabyc ograniczone9 - bazuja na tym podejsciu algorytmy poprawiajace wydajnoscalgorytmu.

Rysunek 3.9. Przykładowe ograniczenia: Sakoe-Chuba i Itakura Parallelogram

W momencie gdy mamy wypełniona macierz, ostatnia wyznaczona wartosc -znajdujaca sie w przeciwległym do poczatku rogu, zawiera wynik liczbowy okresla-jacy róznice serii danych. Najkrótsza sciezka powstaje przez wybranie kolejnychpunktów o najmniejszym dystansie, z otoczenia aktualnej pozycji. Pokazuje onatrajektorie algorytmu10. Optymalny poziom dopasowania wystepuje w momenciegdy sciezka jest diagonala stworzonej macierzy.

9 Zakres pokazany na rysunku 3.910 Przykład pokazany na rysunku 3.10


Rysunek 3.10. Przykładowa macierz z wyznaczona najkrótsza sciezka

Istniejace rozwiazania

Ponizej przedstawione zostały istniejace rozwiazania pokazujace skutecznoscomawianych metod. Ich pozytywne wyniki daja podstawe do stosowania ww. po-dejsc.

WiiGee

Jednym z istniejacych rozwiazan korzystajacych z ukrytych modeli Markova dorozpoznawania gestów jest biblioteka WiiGee11. Jest to implementacja w jezykuJava, udostepniona na licencji wolnego oprogramowania (ang. Open Source). Krótkiopis działania w jezyku angielskim mozna znalezc w nieoficjalnym szkicu [19].

Biblioteka powstała podczas pracy z kontrolerem Wii Remote dla którego jest wgłówniej mierze przeznaczona. Istnieje jednak wtyczka (ang. plugin) umozliwiajacauzycie jej na urzadzeniach z systemem Android, aczkolwiek zwazywszy na ubogadokumentacje integracja jest utrudniona.

Dane uzywane do rozpoznawania to trzy wektory liczb. Liczby reprezentuja przy-spieszenie urzadzenia w kazdej z jego trzech osi. Odczytane dane zostaja poddane4 procesom, zilustrowanych rysunkiem 3.11, próbujac rozpoznac odpowiedni gest.

Pierwszym etapem przy odczytywaniu danych jest ich filtracja. Pozwala tona usuniecie wartosci nieistotnych (ang. idle) - wartosci przyspieszenia ponizejpewnego progu. Dodatkowo usuwane sa wektory które sa w pewnym stopniurówne wartosciom jego poprzednika. Nastepnie dane zostaja poddane kwantyzacjiuzywajac algorytmu „k-srednich” (ang. k-mean), gdzie znalezione empirycznie k =14. Kwantyzacja i drugi etap filtracji maja na celu zmniejszenie ilosci danych iuproszczenie obliczen. Tak przerobione dane zostaja podane na wejscie algorytmuHMM, a pózniej wyniki sa oceniane przy uzyciu klasycznego klasyfikatora Bayesa.

11 http://wiigee.org/index.html


Rysunek 3.11. Komponenty systemu rozpoznawania gestu WiiGee

Aby ta metoda działała - rozpoznawała gesty, musi zostac nauczona co marozpoznac. W opisywanej pracy zostało przedstawione, ze nawet dla małej ilosci„treningów” metoda ta daje bardzo dobre wyniki. Z reguły jednak potrzeba mi-nimum 5-10 gestów treningowych. Został równiez przeprowadzony eksperymentz udziałem pieciu uczestników wykonujacych po 15 gestów symbolizujacych pieckształtów pokazanych na rysunku 3.12. Jako dane treningowe do symulacji uzyto14 z 15 gestów kazdego uczestnika i rozpoznawano pozostałe, co dało zadowalajacewyniki12 na poziomie co najmniej 84%.

Rysunek 3.12. Gesty uzyte podczas eksperymentu, (e) symbolizuje serw tenisowy

iGesture

Inne rozwiazanie równiez wykorzystujace algorytm DTW do rozpoznawania ge-stów zostało opisane w pracy magisterskiej [14,15]. W ramach pracy został opraco-wany komponent do juz istniejacego szkieletu aplikacyjnego (ang. framework) iGe-sture13, umozliwiajacego rozpoznawanie gestów 2D. Praca opisuje nowy algorytmrozpoznawania gestów, który powstał z połaczenia algorytmu DTW z algorytmem„k-najblizszych sasiadów” (ang. k-Nearest Neighbour) uzywanego do klasyfikacjinajlepszego dopasowania wzorca gestu.

Analizie zostały poddane trzy podejscia porównania danych wejsciowych odczy-tanych z akcelerometru - macierze uzywane przez algorytm sa generowane przezinne operacje. Pierwsza z nich wyznacza norme Euklidesowa (ang. Euclidean NormMetric) opisana wzorem 3.3 na podstawie wartosci przyspieszenia kazdej z trzechosi urzadzenia.

12 Poszczególne wyniki przedstawione zostały w artykule [19] na rysunku 813 http://www.igesture.org/


||v|| =√v1 · v1 + v2 · v2 + v3 · v3 (3.3)

Przez zastosowanie tego wariantu tracimy dokładnosc opierajaca sie na orienta-cji urzadzenia gdyz ta miara została celowo stworzona jako niezalezna od orientacji(ang. orientation independant).

Drugie podejscie opiera sie na zwykłej metryce polegajacej na róznicy odpowia-dajacych sobie wartosci przyspieszenia wzdłuz kazdej z osi urzadzenia opisywanychwzorem 3.4. Jednakze, tak jak i trzecie podejscie, jest narazone na problem orien-tacji urzadzenia (ang. tilt) powodujace zakłócenia działania algorytmu.

|x1 − x2|+ |y1 − y2|+ |z1 − z2| (3.4)

Trzecie podejscie polega na wyznaczeniu trzech sciezek uzywajac algorytmuDTW dla kazdej osi X, Y, Z osobno i jako wynik podanie ich sumy, zwiekszajacjednoczesnie ilosc obliczen trzykrotnie.

Dla weryfikacji działania algorytmu zostały przeprowadzone eksperymenty wktórych wzieło udział 8 osób. Testy zostały przeprowadzone na symbolach, którezostały wykorzystane juz wczesniej do oceny działania WiiGee z pominieciem gestutenisowego. Wyniki 14 zdaja sie dawac bardzo dobre rezultaty, aczkolwiek dla po-dejscia wykluczajacego element orientacji urzadzenia, procent trafnych dopasowanjest nieznacznie nizszy.

Drugim testem było rozpoznawanie gestów uzywanych w grach do walki bok-serskiej - zostało wyspecyfikowanych piec ruchów pokazanych na rysunku 3.13 ipoddano je testom.

1 Face Jab - proste uderzenie w twarz,2 Body Jab - proste uderzenie w tors,3 Face Hook - cios sierpowy w twarz,4 Body Hook - cios sierpowy w tors,5 Uppercut - uderzenie podbródkowe.

Rysunek 3.13. Gesty bokserskie, kolejno: Face Jab, Body Jab, Face Hook, BodyHook, Uppercut

Wyniki15 zdaja sie byc gorsze. Jednakze zwazywszy na wieksze skomplikowaniegestów, rozpoznanie na poziomie 70-80% jest dobrym rezultatem pokazujacymskutecznosc metody gdy mamy pewna skonczona pule gestów.

14 Przedstawione zostały w pracy [15] w tabelach 5.1, 5.2, 5.315 Przedstawione zostały w pracy [15] w tabelach 5.4, 5.5, 5.6

4. Implementacja i analiza wykorzystaniaalgorytmu DTW

W niniejszej czesci przedstawiona zostanie własna implementacja algorytmu Dy-namic Time Warping i analiza jego działania w kontekscie rozpoznania konkretnego(wskazanego przez uzytkownika) gestu. Algorytm został wybrany ze wzgledu na jegopopularnosc w dziedzinie rozpoznawania gestów i nieduzy stopien skomplikowania.

Poruszony zostanie aspekt wykonania gestu całkowicie nietrafionego i próbaokreslenia progów akceptacji dla gestu rozpoznanego pozytywnie. Wykorzystanezostana rózne metody porównywania odczytanych danych - z uzyciem przyspiesze-nia liniowego (ang. linear acceleration) wykorzystujacego fuzje czujników.

4.1. Przyjete załozenia

Jak mozna zauwazyc, wyniki uzyskane przy uzyciu przedstawionych w poprzed-nim rozdziale metod daja obiecujace rezultaty, lecz zaleza one od sposobu wykorzy-stania odczytanych wartosci przyspieszenia tj. wstepnej ich filtracji i obróbki. Wprzedstawionych rozwiazaniach obliczenia wykonywano na maszynie o duzej wy-dajnosci, gdyz niezbedne było porównanie odebranych danych z cała baza gestóww celu znalezienia najlepszego dopasowania. Na potrzeby analizy testy wykonanobezposrednio na urzadzeniu mobilnym.

Wyniki przedstawione z cytowanych dokumentów pokazuja jednak, ze zawszewystepujace dokładnie jedno dopasowanie gestu. Celem testów jest pokazanie, zenie zawsze jest to oczekiwane zachowanie.

W trakcie przeprowadzania analizy wykorzystanych zostało 5 róznych gestówprzedstawionych na rysunku 4.1.

Rysunek 4.1. Gesty wykorzystane w trakcie analizy - 5. obraz symbolizuje serwistenisowy

4.2. Implementacja algorytmu 20

Problemy orientacji

W przypadku wykorzystania specyficznego kontrolera takiego jakim jest Nin-tendo Wii, wymusza sie sposób wykonania chwytu urzadzenia. W przypadku urza-dzen mobilnych nie ma takiego wymogu, przez co uzytkownik moze trzymac urza-dzenie obrócone w dowolnej pozycji. Wpływa to niekorzystnie na fakt wykorzystaniametod opartych na przesunieciu w konkretnym kierunku.

Sposób w jaki urzadzenie rozpoczyna pozyskiwanie odczytów poteguje ten efektprzez zmiane kierunku osi. W projekcie wykorzystano przycisk odpowiedzialny zagłosnosc w celu rozpoczecia sekwencji gestu. Ich umiejscowienie w urzadzeniach,przedstawione na rysunkach 4.2 i 4.3, uniemozliwia utrzymanie tej samej orienta-cji.

Rysunek 4.2. Układ osi telefonu dla odczytów akcelerometru. 1L i 1P oznaczapotencjalne umiejscowienie przycisków głosnosci w róznych modelach telefonów

Wymusiło to wykorzystanie dwóch podstawowych chwytów urzadzen przedsta-wionych na zdjeciach 4.4 4.5.

4.2. Implementacja algorytmu

W ramach pracy została wykonana własna implementacja algorytmu DynamicTime Warping (DTW) w jezyku Java. Utworzone zostały modele danych wykorzysty-wane w działaniu algorytmu jak i sam algorytm. Właczone do implementacji zostały4 rózne metody1 porównywania serii danych. Wykorzystywane sa do wyznaczaniamacierzy odległosci miedzy odpowiadajacymi punktami.

Metody wyznaczaja odległosc poszczególnych punktów pomiaru. W celu uprosz-czenia zapisu, wzory opisujace wykorzystane metody przedstawione zostały trzemazmiennymi2.

1 Oznaczone kolorem zielonym na diagramie 4.62 W tym przypadku, oznaczajace przyspieszenie liniowe w osiach X, Y, Z


Rysunek 4.3. Układ osi tabletu o przekatnej 10"dla odczytów akcelerometru. 2LPoznacza potencjalne umiejscowienie przycisków głosnosci w róznych modelach ta-

bletów

1 Odległosc euklidesowa pomiedzy punktami,

d =√

(x2 − x1)2 + (y2 − y1)2 + (z2 − z1)2 (4.1)

2 Suma róznicy pomiedzy odpowiadajacymi wartosciami odczytów,

d = ||x2 − x1|+ |y2 − y1|+ |z2 − z1|| (4.2)

3 Róznica wypadkowych wartosci pomiarów,

d = |√x21 + y21 + z21 −

√x22 + y22 + z22 | (4.3)

4 3 Suma wyników wykonanego algorytmu dla kazdej z wartosci pomiaru liczo-nego osobno.

X = (x1, x2, ..., xn); Y = (y1, y2, ..., yn); Z = (z1, z2, ..., zn)

d = Plain(X2, X1) + Plain(Y2, Y1) + Plain(Z2, Z1)(4.4)

Trzy z nich zwracaja takze obiekt, który wizualizuje znaleziona sciezke poka-zana na wydruku 4.1. Podejscie SeparatedPlain wykonuje algorytm metoda Plaindla kazdej z wartosci osobno i przedstawia sumaryczny wynik jako rozwiazanie.Generuje w ten sposób wiele macierzy, dlatego nie moze zostac zwrócona jednasciezka wynikowa.

Filtracja

Po odczytaniu surowych danych z akcelerometru, zostaja one poddane filtra-cji. Zastosowano dwie metody filtrujace, z których pierwsza polega na usunieciu

3 Jest swego rodzaju podejsciem wykorzystujacym jedna z metod


Rysunek 4.4. Wykorzystany chwyt telefonu

danych stanowiacych swego rodzaju szum. Sa to dane nie wnoszace nic do gesturozpoznawanego z pomoca pomiarów akcelerometru, np. urzadzenie nie poruszasie lub porusza sie zbyt wolno. Dane zostaja pominiete w momencie, gdy sumawartosci jest mniejsza od przyjetego progu ε opisanego wzorem 4.5.

|x|+ |y|+ |z| < ε; ε = 1.0 (4.5)

Drugi filtr polega na usunieciu wartosci podobnych wystepujacych w kolejnychpróbkach pomiaru. Polega to likwidacji duplikatów wartosci, rózniacych sie nie-znacznie tj. o wielkosc zdefiniowana jako ∆ opisanej wzorem 4.6. Podobnie jaki poprzedni filtr, ma to na celu zmniejszenie ilosci danych do przetworzenia, nienaruszajac zbytnio ich struktury.

|x2 − x1| < ∆ ∧ |y2 − y1| < ∆ ∧ |z2 − z1| < ∆; ∆ = 0.5 (4.6)

1 Wynik:46.724

Sciezka :[ (0 ,0 ) , ( 1 ,1 ) , ( 2 ,2 ) , (3 ,3 ) , (4 ,4 ) , ( 4 ,5 ) , ( 4 ,6 ) , (4 ,7 ) , (4 ,8 ) ]

5 Macierz :054,041 053,252 043,121 044,016 [046 ,724]052,041 051,838 039,657 041,107 [040 ,724]049,041 048,521 038,657 039,322 [037 ,724]047,627 046,521 037,243 036,322 [033 ,482]

10 038,246 037,247 030,315 029,764 [028 ,583]032,501 032,051 027,315 [027 ,583] 029,315028,142 027,928 [025 ,583] 032,140 037,039018,762 [018 ,654] 025,583 032,140 037,039

[009 ,381] 018,654 025,583 032,140 037,039

Wydruk 4.1. Macierz wynikowa algorytmu dla przykładowych danych. Wartosci wnawiasach kwadratowych odzwierciedlaja sciezke algorytmu

4.3. Testy dopasowania gestu 23

Rysunek 4.5. Wykorzystany chwyt tabletu

4.3. Testy dopasowania gestu

Aby utwierdzic sie w fakcie, iz metoda ta daje oczekiwane rezultaty, wykonanyzostał eksperyment pokazujacy mozliwosc dopasowania wykonanego gestu do ge-stu znajdujacego sie w bazie.

Załozenia testu

Z wykorzystaniem generatora4 stworzonych zostało 5 gestów. Kazdy z nich zo-stał wykonany w wersji z rózna predkoscia: wolno, zwyczajnie, szybko, bardzoszybko. Wyjatkiem jest gest symbolizujacy serwis tenisowy, którego powolne wy-konanie jest niemozliwe i poniekad zwyczajna predkosc jest wzglednie duza. W tensposób powstało 19 wzorcowych gestów.

Wykonano po 10 gestów kazdego rodzaju próbujac go rozpoznac za pomocakazdej z mozliwych metod, których uzywa zaimplementowany algorytm. Daje tołaczna liczbe 50 wykonanych gestów.

Uwaga. Nalezy zaznaczyc, ze osoba wykonujaca gest jest ta sama która utworzyłajego wzorzec.

Do testów wykorzystano predkosc odczytywanych danych akcelerometru zdefi-niowana w systemie Android jako SENSOR_DELAY_GAME5.

Wnioski z testu dopasowania

Jak widac na przedstawionych wynikach w tabelach 4.1 4.2 4.3 4.4, opisywanametoda działa tak jak przewidywano. Jednakze wyniki odnosza sie do gestów gene-rowanych i dopasowywanych na podstawie danych z tego samego urzadzenia. Wy-niki6 porównan na róznych urzadzeniach, jakimi sa telefony komórkowe róznychproducentów, zdaja sie niesc ze soba pewne problemy zwiazane ze specyfikacja oraz

4 Opis aplikacji znajduje sie w rozdziale 4.65 http://developer.android.com/reference/android/hardware/SensorManager.html6 Szerzej opisane w nastepnej sekcji - 4.4


Rysunek 4.6. Diagram klas algorytmu DTW

Tablica 4.1. Wyniki dopasowan przy uzyciu odległosci euklidesowej opisanej przez4.1

trójkat serwis litera „Z” kwadrat okragtrójkat 10.0 0.0 0.0 0.0 0.0serwis 0.0 10.0 0.0 0.0 0.0

litera „Z” 0.0 0.0 10.0 0.0 0.0kwadrat 0.0 0.0 0.0 10.0 0.0okrag 0.0 0.0 0.0 0.0 10.0

projektem (ang. design). Testy na specyficznym kontrolerze jakim jest urzadzeniefirmy Nintendo, nie były narazone na tego typu problem.

Wyniki dopasowania gestów uzyskane zostały na podstawie porównan danychuzyskanych i wzorcowych, wygenerowanych na urzadzeniu Samsung Galaxy SPlus. Nalezy równiez zauwazyc fakt, iz urzadzenie było trzymane mniej wiecej wtej samej pozycji. Dopasowania sugeruja pewne podobienstwo wartosci mierzo-nych dla róznych gestów. Wskazuja na to czeste pomyłki rozpoznawania niektórychgestów przy uzyciu metody wykorzystujacej wypadkowa wartosci. Kształt figur geo-metrycznych równiez znaczaco wpływa na mozliwosci dopasowania. Przykładowo -pomijajac fakt rogów, trajektoria ruchu dla figury kwadratu przypomina trajektorieruchu dla okregu.


Tablica 4.2. Wyniki dopasowan przy uzyciu róznicy poszczególnych wartosci po-miarów opisanych przez 4.2



Tablica 4.3. Wyniki dopasowan przy uzyciu porównania wartosci wypadkowej po-miarów opisanej przez 4.3



Tablica 4.4. Wyniki dopasowan przy uzyciu oddzielnych przebiegów opisanychprzez 4.4



4.4. Analiza działania algorytmu 26

4.4. Analiza działania algorytmu

Przedstawione w niniejszej czesci rozwazania zostały opisane na przykładziewybranego gestu - litery „Z” w wersji wykonania o zwyczajnej predkosci. Kolejnozbierane dane beda porównywane z wzorcem przy uzyciu zaimplementowanegoalgorytmu.

Gest wzorcowy wykonany przy uzyciu telefonu składa sie z 31 wartosci przy-spieszenia, podczas gdy przy uzyciu tabletu jest ich tylko 12. Wynika to z faktumniej zaburzonych odczytów w drugim z nich, gdyz urzadzenie to wyposazone jestw dodatkowy czujnik - zyroskop.

Uwaga. Dane zostały poddane filtracji z takimi samymi parametrami ε = 1.0; ∆ =0.5.

Dla celów dalszej analizy oznaczmy urzadzenia przez przyporzadkowanie imidentyfikatorów:

— Smartfon Samsung Galaxy S Plus ˜ #1— Tablet Samsung Galaxy Note 10.1 ˜ #2

Pozytywne dopasowanie

Wykonanych zostało 10 gestów przy wykorzystaniu kazdego z urzadzen. Poniz-sza tabela 4.7 przedstawia otrzymane minimalne, maksymalne i srednie wyniki.Gesty zostały porównane w 4 konfiguracjach:

— wzór #1 - odczyt #1,— wzór #2 - odczyt #2,— wzór #1 - odczyt #2,— wzór #2 - odczyt #1.

Rysunek 4.7. Wyniki dopasowan gestów do wzorów

4.4. Analiza działania algorytmu 27

Tablica 4.5. Wyniki pojedynczego dopasowania

Metoda WynikEuklides 53,39978747Róznica 79,30804889

Wypadkowa 15,02976471Osobna 79,30804889

Tablica 4.6. Wyniki porównania niekreslonego, chaotycznego gestu

Liczba pomiarów Euklides Róznica Wypadkowa Osobna9 122,093927 175,4816583 82,49824335 151,871465314 261,2262055 358,7833478 227,1774762 243,893372322 249,2701477 364,1245493 200,6910554 335,41494431 438,5024744 601,2797234 390,7340121 559,246601138 647,3425842 917,2282668 610,8324714 909,646111473 1194,338975 1777,027559 1117,099869 1718,338715

Mozna szybko zauwazyc, ze srednie wyniki uzyskane przy uzyciu urzadzenia#2 sa znacznie lepsze w przypadku tego testu. Zaskakujacym moze byc fakt,iz porównane wyniki dla pomiaru #2 - #1 sa dwukrotnie lepszy niz wyniki dlapomiaru #1 - #2. Spodziewanym problemem było rózne skierowanie osi urzadzeniaujawniajace sie w wynikach niektórych metod. Jednakze metody te w wiekszoscioperuja na wartosciach bezwzglednych, a osie urzadzen w testowanych chwytachbyły zwrócone przeciwnie, dlatego tez wyniki moga sie czesciowo kompensowac.

Błedne dopasowanie

W tej czesci rozwazano problem wykonania całkowicie nietrafionego gestu. Takjak w poprzedniej sekcji do testu wykorzystano ten sam gest litery „Z”.

Dla pierwszego porównania7 wzieto jeden pomiar odczytanego przyspieszeniaze wzorcowego gestu i porównano go z nim. Dla drugiego porównania8 wykonanoniekreslone i chaotyczne ruchy, generujac w ten sposób pewne pseudo losowe dane.Istnieje tez problem gestów o podobnej trajektorii poruszony w czesci 4.3.

Jak mozna zauwazyc, wyniki dla jednego pomiaru moga sugerowac wystapieniegestu. Do takiej sytuacji moze dojsc po filtracji danych, gdy gest jest niewystar-czajaco dynamiczny, a co za tym idzie - zmiany przyspieszenia sa za małe by gorozpoznac. Rozwiazaniem moze byc proste odrzucanie sytuacji, w której ilosc da-nych jest zbyt mała, traktujac to jako brak dopasowania. Nalezałoby w tym celuokreslic próg wymaganej ilosci odczytów. Empiryczne testy drugiego przypadkuwykazały, ze powinno byc to co najmniej 10 odczytów.

Oczywiscie istotnym faktem jest predkosc wykonywania gestu. Pomiar polegana analizie zmiany przyspieszenia, dlatego odpowiednio wolne poruszanie urza-dzeniem zostac potraktowane jako trafny gest choc nim nie był. Przykładem jestwynik pomiaru dla metody wypadkowej i 9 odczytów9, który nie jest bardzo duzymniedopasowaniem.

Analizujac wyniki mozna dojsc do wniosku, iz kryterium odrzucajacym całko-wite niedopasowanie gestu jest rózne dla kazdej z wykorzystanych metod. Jednakze

7 Wyniki przedstawiono w tabeli 4.58 Wyniki przedstawiono w tabeli 4.69 Umieszczony w tabeli 4.6

4.5. Wnioski 28

z empirycznych testów wykonanych w trakcie pracy nad projektem, sensownymwydaje sie byc ustalenie jego wartosci na liczbe co najmniej 200.

4.5. Wnioski

Duzo lepsze dopasowania otrzymuje sie w przypadku wykorzystania urzadze-nia wyposazonego w zyroskop. Odczytane dane sa znacznie mniej zaszumione nizw przypadku urzadzenia bez tego czujnika. Innym mozliwym czynnikiem wyka-zujacym te róznice jest fakt iz wykorzystany telefon był przeznaczony na rynekmiddle-end, a tablet high-end, przez co klasa wykorzystanych czujników moze sieznaczaco róznic.

Przedstawiona metoda posiada pewne braki. Jednakze ciagły rozwój technologiia co za tym idzie ulepszane czujniki, moga zaowocowac jeszcze lepszymi wynikamidziałania algorytmu.

Niewatpliwie metoda ta moze byc z powodzeniem stosowana przy ustaleniu pew-nych załozen takich jak chwyt urzadzenia, ustandaryzowana predkosc poruszanianim, czy nawet jego model. Wyniki otrzymywane za pomoca algorytmu DTW wstosunku do prostoty wykorzystania na pewno znajda zastosowanie w wielu przed-siewzieciach takich jak tworzona aplikacja.

4.6. Opis działania aplikacji testowej

Do wykonania testów rozpoznawania gestów przestrzennych została stworzonaprosta aplikacja - generator, pozwalajaca na rejestrowanie danych z akcelerome-tru. Ponizej znajduje sie krótki opis jej działania. Składa sie ona z kilku czesciodpowiadajacych za:

1 Zapis danych akcelerometru i punktów na ekranie,2 Porównanie wyników metod dla załadowanego gestu,3 Dopasowanie gestu do załadowanej listy przy uzyciu wybranej metody,4 Wykresy odczytanego i załadowanego gestu dla trzech osi.Nagrywanie gestu zaczyna sie w momencie wcisniecia przycisku odpowiedzial-

nego za zmniejszenie lub zwiekszenie głosnosci. Konczy sie wraz z jego puszcze-niem. Nastepnie przeprowadzana jest filtracja odczytanych danych. Tak przechwy-cone i obrobione dane wykorzystywane sa do porównywania w aplikacji.

Pierwsza czesc daje mozliwosc zapisywania odczytanych pomiarów jako da-nych wykorzystywanych do rozpoznawania gestów. Dane zapisywane sa w postaciznacznik_czasu|wartosc_pomiaru[|wartosc_pomiaru...]10.

1 # znacznik_czasu wartosc_x wartosc_y wartosc_z1386537350106|0.30531442165374756|0.40948712825775146|0.53038024902343751386537350166|0.25445377826690674|1.1045472621917725|0.73415374755859381386537350206|0.3891463875770569|1.7476787567138672|0.9478845596313477

5 1386537350246|0.34111690521240234|2.362583875656128|0.9659986495971681386537350346|0.6997952461242676|2.0075700283050537|0.35235691070556641386537350406|0.8565775752067566|1.2798352241516113|−0.44041061401367191386537350446|1.051574945449829|0.5137985944747925|−0.27817249298095703. . .

10 Przykładowe wartosci pokazane na wydruku 4.2

4.6. Opis działania aplikacji testowej 29

Wydruk 4.2. Format danych gestu zapisywanych do pliku

Druga czesc odpowiada za obliczanie dopasowania dla wybranego gestu wczyta-nego z pliku i gestu odczytanego przez urzadzenie. Wynik dopasowania dla kazdejzaimplementowanej metody przedstawiony jest na ekranie po nacisnieciu przyci-sku.

Trzecia czesc ma za zadanie dopasowac najbardziej trafny gest - tj. ten dlaktórego wynik algorytmu jest najmniejszy. Przechwycone dane akcelerometru po-równywane sa wybrana metoda z danymi odczytanymi z plików umiejscowionychw wybranym katalogu.

Ostatnia, czwarta czesc odpowiedzialna jest za przedstawienie graficznego podo-bienstwa danych gestu wzorcowego i wykonanego przez uzytkownika. Przykładowedane wynikowe pokazane na rysunku 4.8 przedstawione zostały na wykresach 4.9.

Rysunek 4.8. Ekrany aplikacji dla danych gestu litery „Z”

4.6. Opis działania aplikacji testowej 30

Rysunek 4.9. Wykresy porównujace dane gestu listery Z. Pierwsze trzy dla odpo-wiednich osi X, Y, Z. Czwarty dla wartosci wypadkowych. Piaty przedstawia od-

wzorowanie punkt-punkt róznicy wypadkowych danych

5. Realizacja aplikacji

Projekt w którego skład wchodza serwer i aplikacja kliencka, został wykonanyw wiekszosci przy uzyciu jezyka Java. Aplikacja mobilna wykorzystuje równiezczesc natywna, napisana w jezyku C++. Kod ten jest dołaczony w postaci bibliotekładowanych dynamicznie (ang. shared libraries), a łacznikiem odpowiadajacym zakomunikacje pomiedzy warstwami jest Java Native Interface (JNI).

Ze wzgledu na specyfike plików konfiguracyjnych aplikacji tworzonych na sys-tem Android, w duzym stopniu wykorzystywany był równiez jezyk XML.

5.1. Zastosowane narzedzia

W trakcie prac wykorzystano narzedzia programistyczne zwiekszajace efektyw-nosc i ułatwiajace tworzenie aplikacji. Uzyte zostało zintegrowane srodowisko pro-gramistyczne (ang. Integrated Development Environment (IDE)) Eclipse w wersji 4.3(Kepler) z wtyczkami (ang. plugins):

— Android Development Tools (ADT)1 w wersji 22.0.5 - do budowania aplikacjina platforme Android,

— Google Plugin for Eclipse (GPE)2 w wersji 3.4.2 - do budowania i tworzeniaaplikacji bazujacych na komunikacji z serwerem (ang. cloud-based).

Dodatkowo aby wprowadzic zabezpieczenie kodu i utrzymanie informacji owprowadzanych zmianach, wykorzystano system kontroli wersji - Git, z pomocaktórego stworzone zostało zdalne (ang. remote) repozytorium. Całosc zostałaskonfigurowana tak aby działała na systemie operacyjnym Windows 7.

Do uruchamiania aplikacji mobilnych, mozna wykorzystac dostarczany w ra-mach wtyczki ADT emulator systemu Android. W porównaniu do rzeczywistychurzadzen działa on wolno i nie posiada wielu funkcji wykorzystywanych przez apli-kacje. Naleza do nich np. serwisy udostepniane przez firme Google3 (ang. GooglePlay Services). Istotnym faktem jest całkowity brak mozliwosci wykorzystania czuj-ników wykluczajacym uzycie emulatora do zagadnien AR.

Zwazywszy na powyzsze ograniczenia, w trakcie prac zostały wykorzystane dwadostepne urzadzenia:

— Smartfon Samsung Galaxy S Plus z systemem Android w wersji 2.3.5— Tablet Samsung Galaxy Note 10.1 z systemem Android w wersji 4.3

1 http://developer.android.com/tools/sdk/eclipse-adt.html2 https://developers.google.com/eclipse/3 http://developer.android.com/google/play-services/index.html

5.2. Wykorzystane technologie 32

5.2. Wykorzystane technologie

Ponizej przedstawiony został krótki opis technologii i bibliotek wykorzystywa-nych przez stworzone aplikacje.

Android SDK

Dostarcza API w postaci bibliotek i narzedzi niezbednych do budowania, testo-wania i debugowania aplikacji dedykowanych na system Android. Wykorzystanezostało API 10. poziomu odpowiadajace wersji 2.3.3 Gingerbread. SDK dostepnejest pod adresem: https://developer.android.com/sdk/

Google Cloud Messaging

Jest serwisem4 pozwalajacym na wysyłanie wiadomosci z serwera na urzadzeniamobilne działajace pod kontrola systemu Android. Serwis sam obsługuje wszelkieaspekty kolejkowania i dostarczania wiadomosci na urzadzenia docelowe. Systemjest darmowy i moze byc wykorzystywany bez ograniczen. Dokładniejszy opis iwykorzystanie przedstawione zostały w sekcji 5.7. Informacje dostepne sa podadresem: http://developer.android.com/google/gcm/

Google Maps v2

Dostarcza mozliwosci wykorzystania map na urzadzeniu mobilnym. UdostepniaAPI do rysowania własnych figur na jej powierzchni i dostosowania znaczników(ang. markers) prezentowanych uzytkownikowi. Dokumentacja dostepna jest podadresem: https://developers.google.com/maps/documentation/android/

Vuforia Augmented Reality SDK

Biblioteka pozwala na tworzenie aplikacji wykorzystujacych rozszerzona rzeczy-wistosc oparta na wizji (ang. vision-based). Oferuje szeroki wachlarz mozliwosciz których moga korzystac deweloperzy. Pozwala na rozpoznawanie obiektów reje-strowanych przy uzyciu kamery w czasie rzeczywistym i generowanie wirtualnychobiektów 3D na jej podgladzie. Głównymi cechami sa:

— Lokalne rozpoznawanie obiektów,— Rozpoznawanie obiektów w chmurze5,— Definiowanie obiektów do rozpoznania przez uzytkowników koncowych,— Rozpoznawanie tekstu,— Jednoczesne rozpoznawanie wielu obiektów.

Dokładniejszy opis wykorzystanych funkcji został przedstawiony w roz-działach: 3.4 3.5.1 5.8.2. Biblioteka dostepna jest pod adresem:https://developer.vuforia.com/

GSON

Słuzy do konwersji obiektów z jezyka Java do ich reprezentacji tekstowej wformacie JSON, a takze w druga strone. Biblioteka dostepna jest pod adresem:https://code.google.com/p/google-gson/

4 http://developer.android.com/google/play-services/index.html5 Przeprowadzanie obliczen na serwerze

5.3. Wybór technologii 33

Google Datastore

Magazyn danych zapewniajacy przechowywanie obiektów bez wczesniejszegodefiniowania ich schematu w postaci skryptu SQL. Jest swego rodzaju baza da-nych typu NoSQL (ang. Not only SQL). Dostarczany Java Datastore SDK za-pewnia implementacje interfejsów Java Data Objects (JDO) i Java PersistenceAPI (JPA), a takze niskopoziomowy dostep do danych. Baza wchodzi w składplatformy Google App Engine (GAE)6, a jej opis dostepny jest pod adresem:https://developers.google.com/appengine/docs/java/datastore/

Objectify

Jest to interfejs programistyczny API dostepu do danych zaprojektowanyspecjalnie dla magazynu danych Google App Engine. Zapewnia on ła-twy i bardziej transparentny dostep niz JDO czy JPA. Został wybrany,gdyz jest dedykowanym rozwiazaniem oraz wciaz jest rozwijany i posiada ak-tualna dokumentacje. Repozytorium projektu dostepne jest pod adresem:https://code.google.com/p/objectify-appengine/

Google App Engine Services

Sa to rozszerzenia dostarczone przez firme Google w ramach platformy GoogleApp Engine (GAE). Daja ogromne mozliwosci tworzenia skalowalnych aplikacji iznaczaco ułatwiaja wykonanie czesci serwerowej aplikacji. W pracy wykorzystanezostały przedstawione ponizej funkcje. Ich zbiorcza dokumentacja dostepna jestpod adresem: https://developers.google.com/appengine/docs/java/apis

Google Cloud Endpoints

Umozliwia proste tworzenie zewnetrznego interfejsu REST API serwera przezzastosowanie adnotacji klas odpowiedzialnych za komunikacje. Dzieki wy-korzystaniu GPE mozliwe jest generowanie zewnetrznych bibliotek dla sys-temu Android wspomagajacych komunikacje. W projekcie wykorzystane jestjako srodek dostepu do danych rozgrywki przez zapytania HTTP. Szczegó-łowy opis znajduje sie w sekcji 5.7. Dokumentacja dostepna pod adresem:https://developers.google.com/appengine/docs/java/endpoints/

Task Queues

Umozliwia kolejkowanie zadan w taki sposób aby aplikacje mogły wyko-nywac prace niezaleznie od zadan które zainicjowali uzytkownicy. Gdy apli-kacja potrzebuje wykonac operacje w tle, moze do tego uzyc dostepnegoAPI do stworzenia tzw. zadan7. Dokumentacja dostepna pod adresem:https://developers.google.com/appengine/docs/java/taskqueue/

5.3. Wybór technologii

Projekt wykonano w architekturze klient-serwer. Stworzona została aplikacja- klient, na urzadzenia z systemem Android oraz aplikacja - serwer w oparciu oplatforme Google App Engine.

6 https://developers.google.com/appengine/7 Krótki opis znajduje sie w czesci 5.7

5.4. Architektura rozwiazania 34

Nacisk połozony został na czesc logiki odpowiedzialna za funkcjonowanie apli-kacji, przy wykorzystaniu dostepnych technologii. Aspekt wygladu - Graphical UserInterface został odłozony na drugi plan, gdyz wykracza poza zakres niniejszej pracy.

Serwer

Wybrana do projektu platforma serwerowa Google App Engine dostarcza wszel-kiej niezbednej funkcjonalnosci aby spełnic wymagania stawiane grze. W jej składwchodzi równiez baza danych wykorzystywana z pomoca dedykowanego szkieletuObjectify. Dostepnych szkieletów jest kilka, jednakze tylko ten posiada aktualnadokumentacje techniczna co zdecydowało o wyborze.

Do komunikacji uzyto prostego protokołu HTTP z wykorzystaniem dodatkowejfunkcji oferowanej przez GAE. Jest nia mozliwosc generowania pomocniczych, ze-wnetrznych bibliotek dla platformy Android. Dzieki takiemu podejsciu implemen-tacja została znacznie uproszczona.

Dodatkowym elementem usprawniajacym rozgrywke jest wykorzystanie powia-domien z serwera bezposrednio na urzadzenia mobilne, który jest dostepny naplatformie Android. Mechanizm powiadamiania nie wymaga ciagłego odpytywa-nia serwera aplikacji o stan rozgrywki co znaczaco ogranicza ilosc niepotrzebnychzapytan.

Augmented Reality SDK

W rozdziale 3.5.1 przedstawione zostały dostepne biblioteki na platforme An-droid. Na podstawie analizy mozliwosci, do projektu została wybrana Vuforia. Dajeona mozliwosc wgladu w czesc sekwencji realizujaca rozpoznawanie po stronie na-tywnej. Dodatkowym atutem przemawiajacym za wyborem, były empiryczne testydziałania dwóch testowanych bibliotek (Vuforia i Metaio). Wybrana biblioteka lepiejradziła sobie ze znajdowaniem obiektów, a znalezione obiekty stabilniej utrzymy-wały wyznaczone raz połozenie na ekranie.

Pomimo iz biblioteka dostarcza wielu mozliwosci, w projekcie zostało wykorzy-stanych jedynie kilka z nich. Wykorzystano funkcje rozpoznawania zdefiniowanychwczesniej obrazów z lokalnej bazy. Uzyty został równiez mechanizm tworzenia wła-snych celów przez uzytkowników koncowych (ang. user defined targets) połaczonez ich rozpoznawaniem w chmurze8.

Tworzenie grafiki trójwymiarowej zostało pominiete, a generowane przez biblio-teke zdarzenia sa propagowane do czesci napisanej w jezyku Java i prezentowaneprzy uzyciu standardowych widoków systemu Android.

5.4. Architektura rozwiazania

Koniecznosc komunikacji pomiedzy uzytkownikami i utrzymanie stanu roz-grywki, wymusza architekture typu klient-serwer. Wykorzystywana funkcja roz-poznawania gestów wymagała równiez stworzenia prostej aplikacji pomagajaca wich analizie. W pracy mozna zatem wyróznic trzy odrebne czesci - aplikacje:

— Klient - odpowiadajacy za interakcje z uzytkownikiem, odpowiednia prezen-tacje informacji uzyskanych z serwera i wykorzystanie mozliwosci urzadzeniamobilnego,

8 Dokładniej opisane w rozdziale 5.8.2

5.5. Struktura aplikacji 35

— Serwer - odpowiada za utrzymanie stanu rozgrywki oraz odpowiedzi na za-pytania uzytkowników. Wykonuje cykliczne zadania stwarzajac pozory gry wczasie rzeczywistym tj. generuje zdarzenia i uzupełnia informacje o graczach,

— Analizator gestów - aplikacja stworzona w celu wykonania analizy rozpozna-wania gestów oraz generowania danych je opisujacych, wykorzystywanych waplikacji klienckiej.

Podział projektu

Na potrzeby pracy, stworzone zostały 4 odrebne projekty dla kazdej czesci funk-cjonalnej:

— Dwie aplikacje na telefon - klient i analizator gestów,— Aplikacja serwerowa,— Implementacja algorytmu DTW jako zewnetrznej biblioteki.W celu unikniecia dublowania kodu wydzielona została czesc wspólna pomiedzy

serwerem i klientem. Diagram 5.1 przedstawia uproszczony podział architektury9

Uwaga. Czesc obiektów utrwalanych w bazie danych jest wygodnym sposobemprzechowywania informacji po stronie aplikacji klienckiej. Z tego powodu wyko-rzystano te same klasy w kontekscie modelu danych. Sa to obiekty pozbawionelogiki - jedynie przechowujace dane tzw. Plain Old Java Objects (POJOs)10.

Rysunek 5.1. Podział komponentów - aplikacji

5.5. Struktura aplikacji

Ponizsze diagramy 5.2 5.3 przedstawiaja podział aplikacji na moduły - pakiety.Poszczególne ich czesci opisane zostały w nastepnych czesciach rozdziału.

5.5.1. Klient

Aplikacja kliencka podzielona została na nastepujace czesci:

9 Szczegółowy diagram przedstawiony jest w sekcji 5.510 W projekcie przyjeto skrót pdo - Plain Data Object

5.5. Struktura aplikacji 36

Rysunek 5.2. Diagram struktury aplikacji klienckiej

— activity, zawieraja klasy aktywnosci podzielone ze wzgledu na wykorzystanie:+ base, klasy bazowe pomagajace w uniknieciu duplikowania kodu,+ main, główny widok, opcje i sekwencje logowania,+ user, wyswietlanie informacji o graczu, jego nabytych umiejetnosci i wiado-

mosci,+ shop, czesc zwiazana z zakupem czarów i broni,+ hunt, czesc zwiazana z polowaniem - zlecaniem zabójstw i informacji o nich,+ battle, prezentowanie przeciwników oraz walka z nimi:

- spell, wykonywanie czarów z uzyciem 3 metod: mowy, rysowania poekranie i uzywania gestów,

- defend, wykonywanie akcji obronnych,— camera, czesc zwiazana z wykorzystaniem kamery, wywołujaca natywnefunkcje,

— JNI, czesc napisana w jezyku C++ wykorzystujace mozliwosci rozpoznawaniaobiektów wykorzystujac QCAR API z biblioteki Vuforia,

— manager, odpowiedzialne za zapisywanie danych na urzadzeniu i opakowaniemetod wywołujacych zapytania do serwera,

— db, definicje klas opisujace lokalna baze danych do zapisywania tymczaso-wych danych (ang. caching),

— views, klasy własnych elementów widoku wykorzystywanych w aplikacji orazadaptery list11,

— util, narzedzia pomocnicze takie jak Loger i stałe pomocnicze,— objectify, namiastki (ang. stubs) stworzone w celu wykorzystania klas modeludanych opisanych adnotacjami z czesci serwerowej.

11 http://developer.android.com/reference/android/widget/ListAdapter.html

5.6. Struktura bazy danych 37

Rysunek 5.3. Diagram struktury aplikacji serwerowej

5.5.2. Serwer

Aplikacja serwera podzielona została na 4 główne czesci realizujace funkcjo-nalnosc: logike gry, dostep do danych, zaplanowane zadania oraz udostepnianiezewnetrznego API. Przedstawiono je kolejno na ponizszej liscie.

— service, zawiera cała logike gry wywoływana po stronie serwera podzielona namniejsze czesci funkcjonalne,

— manager, realizuje funkcje dostepu do danych w bazie przy uzyciu bibliotekiObjectify. Klasy rozszerzaja funkcje tzw. Data Access Object (DAO) wykonujacoperacje na wielu typach obiektów na raz,

— task, serwlety odpowiedzialne za odbieranie zadan zaplanowanych zadan ser-wera i wykonywanie odpowiednich akcji z nimi zwiazanych. Wykonywane akcjezwiazane sa z utrzymaniem ciagłosci rozgrywki przez symulowanie jej jako od-bywajacej sie w czasie rzeczywistym. Dodatkowo weryfikowane sa zaleznosciograniczen czasowych w grze,

— endpoint, klasy opisane adnotacjami do generowania bibliotek wykorzysty-wanych w komunikacji12.

Projekt zawiera takze czesc współdzielona zawierajaca model danych zapisy-wanych w bazie i opisany w czesci 5.6 oraz kody wykorzystywane w komunikacjiprzedstawione na diagramie 5.4 .

5.6. Struktura bazy danych

Z uwagi na sposób komunikacji wykorzystujacej serwisy (ang. web service) zuzyciem Google Endpoints platformy GAE, klasy modelu dziedzicza po PdoEntitypokazanym na diagramie 5.8. Obiekt ten zawiera pole przeznaczone na kod zwra-cany z serwera informujacy o niekonwencjonalnej akcji takiej jak np. „Brak pie-niedzy do zakupu czaru”. Jest to uzyteczne do okreslenia rodzaju błedu po stronieaplikacji klienckiej w przypadku posiadania przez nia nieaktualnych danych, za-miast wyswietlania informacji o nieudanej akcji.

12 Opis znajduje sie w czesci 5.7

5.7. Sposób komunikacji 38

Rysunek 5.4. Kody wykorzystywane w komunikacji

Sam model opisany został adnotacjami szkieletu (ang. framework) Objectify.Ma to na celu dostosowanie obiektów do zapisania w magazynie danych (ang. da-tastore) przy uzyciu tego szkieletu. Wykorzystano podstawowe adnotacje opisujace„byty” - @Entity, „byty” zagniezdzone - @Embed oraz indeksowanie - @Index.

Na diagramach 5.5 5.6 5.7 5.8 przedstawiony został model klas składajacychsie na całokształt bazy danych.

5.7. Sposób komunikacji

Do komunikacji aplikacji klienckiej z serwerem wykorzystano protokół HTTP zreprezentacja danych w formacie JSON. Podejscie to nie wymaga ciagłego połacze-nia z serwerem dzieki czemu chwilowy brak połaczenia z internetem, nie wykluczygracza z rozgrywki tylko opózni jego udział. W celu zmniejszenia ilosci tworzonegokodu, wykorzystano mechanizm udostepniania API serwera przy uzyciu technologiiGoogle Cloud Endpoints (GCE).

Sam mechanizm GCE polega na stworzeniu internetowego interfejsu (ang. webAPI) dostepnego z róznych urzadzen, niezaleznie od ich systemu. Przez odpowied-nie opisanie metod tworzonych klas, tworzone sa dostepne przez siec serwisy. GPEumozliwia generowanie zewnetrznych bibliotek dla systemu Android odpowiedzial-nych za komunikacje oraz plików13 odkrywajacych API.

13 Przykładowy plik opisujacy API w projekcie: war/WEB-INF/messageEndpoint-v1.api


Rysunek 5.5. Diagram klas - model gracza

Przykłady innych serwisów oferowanych przez Google takich jak CalendarAPI, Drive API, Translate API, YouTube Data API, mozna znalezc pod adresemhttps://developers.google.com/apis-explorer/?hl=pl#p/. Dostepna jestrówniez aplikacja internetowa14 wykorzystujaca ten mechanizm, która pozwala natestowanie udostepnionych funkcji. Na rysunku 5.9 przedstawiony został przykła-dowy ekran z prostym interfejsem stworzonym na podstawie pliku .api.

Na ponizszych wydrukach przedstawiono wymagany kod sekwencji logowaniapo stronie serwera - wydruk 5.1 i klienta - wydruk 5.2.

Uwaga. Obecne sa adnotacje, lecz czesc odpowiedzialna za wykonanie logiki logo-wania nie została pokazana, gdyz nie ma zwiazku w przedstawionym kontekscie.

1 @Api ( root = UrlAdresses .MAIN + "/_ah/api " , name = "mainEndpoint" ,namespace = @ApiNamespace (ownerDomain = "edu. pl " , ownerName = "edu. pl " ,packagePath = "pw. elka .mmarkiew.game. endpoint " ) )

public class MainEndpoint {5

@ApiMethod (name = " login " , httpMethod = HttpMethod .GET)public User login (@Named( UrlParameters .EMAIL) String email ,

@Named( UrlParameters .DEVICE_ID) final String deviceId ,@Named( UrlParameters .LOGIN_PASSWORD) final String password ) {

10 email = URLDecoder . decode ( email , "UTF−8" ) ;

UserService us = new UserService ( ) ;User user = us . loginUser ( email , password , deviceId ) ;

15 return user ;}

}

14 localhost:8888/_ah/api/explorer dla serwera lokalnego działajacego na porcie 8888


Rysunek 5.6. Diagram klas - model walki

Wydruk 5.1. Logowanie przy uzyciu GCE - serwer

1 MainEndpoint service = new MainEndpoint . Builder ( AndroidHttp. newCompatibleTransport ( ) , new GsonFactory ( ) , null ) . build ( ) ;

Login login = service . login ( email , deviceId , md5( password ) ) ;User user = login . execute ( ) ;

Wydruk 5.2. Logowanie przy uzyciu GCE - klient

Łatwo zauwazyc mała ilosc kodu, potrzebna do wykonania zapytania. Głównymzadaniem jest opisanie klas przy uzyciu adnotacji.

Uwaga. Zapytania na urzadzeniu mobilnym nalezy wykonywac w oddzielnymwatku, nie blokujac interfejsu uzytkownika.

Powiadamienie typu PUSH

W aplikacji wykorzystano mechanizm powiadamiania oparty na Google CloudMessaging (GCM), który oferuje dwa ich rodzaje:

— Powiadomienie (ang. „send-to-sync” message) - jedynie informuje aplikacje owystapieniu zdarzenia (ang. ping)15,

— Wiadomosc z ładunkiem (ang. Message with payload) - informuje aplikacje owystapieniu zdarzenia dodatkowo niosac ze soba do 4kb danych16.

15 Google gwarantuje dostarczenie wiadomosci przez jej kolejkowanie w razie braku połaczenia zurzadzeniem

16 W tym przypadku nie ma gwarancji dostarczenia wiadomosci


Rysunek 5.7. Diagram klas - model wiadomosci

Dzieki wykorzystaniu mechanizmu, aplikacja nie musi cyklicznie odpytywacserwera (PULL) o jakikolwiek status. Wiadomosc z serwera jest wysyłana (PUSH)asynchronicznie do klienta z informacja o zdarzeniu.

Uwaga. Rozwiazanie to na urzadzeniu z systemem Android jest mozliwe pospełnieniu okreslonych warunków. Wymagany jest system w wersji co najmniej2.2 z zainstalowana aplikacja Google Play Store lub z co najmniej jednym zsyn-chronizowanym kontem Google w przypadku wersji mniejszej od 4.0.4. Mechanizmjest dostepny, gdyz serwer Google utrzymuje stałe połaczenie z urzadzeniem naktórym zainstalowana jest wspomniana aplikacja.

Schemat działania mechanizmu przestawiono na diagramie 5.10, a oznaczeniakomunikatów opisane zostały na ponizszej liscie.

1 Aplikacja działajaca na urzadzeniu rejestruje sie na serwerze Google,2 W odpowiedzi na rejestracje wysyłany jest identyfikator zarejestrowanej apli-kacji z danego urzadzenia lub informacja o błedzie,

3 Aplikacja wysyła otrzymany identyfikator na serwer gry,4 Serwer gry zapisuje identyfikator urzadzenia w bazie danych,a Serwer gry wysyła powiadomienie z identyfikatorem urzadzenia na serwer Go-ogle,

b Serwer Google wysyła powiadomienie na urzadzenie.W aplikacji wykorzystano ten system do informowania o zdarzeniach na serwe-

rze takich jak atak przeciwnika lub odebranie nowej wiadomosci. Wraz z powiado-mieniem wysyłany jest kod17 identyfikujacy zdarzenie oraz ewentualnie dodatkowyidentyfikator. Nastepnie aplikacja na podstawie otrzymanego kodu powiadamiazainteresowane aktywnosci18 przez mechanizm rozgłaszania (ang. local broadcast).

17 Kod z klasy GCMCodes przedstawiony na diagramie 5.418 http://developer.android.com/guide/components/activities.html


Rysunek 5.8. Diagram klas - modele pomocnicze

Wewnetrzna komunikacja przy uzyciu kolejkowania zadan

Aktualny stan gry w całosci przechowywany jest na serwerze, a jego zmianywywoływane sa przez wykonanie zadania do serwera. W celu zapewnienia wrazeniapłynnosci gry nalezy zastosowac pewne zabiegi, aby wykonanie niektórych akcjibyło niezalezne od wywołan graczy. Z pomoca przychodzi mechanizm zadan (ang.tasks).

Google App Engine oferuje kolejkowanie zadan wykorzystujace dwa ich rodzaje:Push Queues i Pull Queues. Pierwszy z nich umozliwia dodawanie i reczne usuwa-nie zadan z kolejki. Wykorzystany w projekcie drugi typ, sam wykonuje wyjmujezadania z kolejki, w okreslonym czasie je wykonuje i usuwa gdy wykonanie zadania

Rysunek 5.9. Zrzut ekranu z aplikacji internetowej - Api Exlporer


Rysunek 5.10. Google Cloud Messaging - rejestracja i powiadamianie

sie powiodło. W przeciwnym wypadku zadanie zostaje ponownie wstawione do ko-lejki. Zadanie realizowane jest przez wykonanie zadania HTTP z uzyciem podanegoadresu URL i przekazanych parametrów.

W grze zadania wykorzystane zostały do egzekwowania ograniczen czasowych:— w trakcie walki graczy,— przeterminowania zlecen zabójstw,— wysyłania opóznionych powiadomien bez blokowania odpowiedzi serwera,— do regeneracji zycia graczy, generacji zlecen zabójstw i sztucznych przeciwni-ków19.

19 GAE działajace w srodowisku Windows nie udostepnia funkcjonalnosci planowania zadan zwykorzystaniem demona cron. Kolejki zadan wykorzystano do symulacji tego mechanizmu

5.8. Rozpoznawanie obrazów 44

5.8. Rozpoznawanie obrazów

W aplikacji wykorzystano 3 mozliwosci jakie oferuje biblioteka Vuforia:— Rozpoznawanie wczesniej zdefiniowanych celów,— Tworzenie własnych celów,— Rozpoznawanie własnych celów w chmurze20.Dla kazdej z nich stworzone zostały odpowiednio 3 klasy przedstawione na dia-

gramie 5.11, realizujace poszczególne funkcje oraz wspólna klasa bazowa odpowie-dzialna za inicjalizacje biblioteki.

Rysunek 5.11. Diagram klas namierzajacych obiekty (ang. trackers)

Zdefiniowany cel - obraz, mozna wgrac na serwer przez narzedzie (ang. TargetManager), badz za pomoca aplikacji tworzacej zdefiniowany przez uzytkownika cel(ang. User Defined Target (UDT)). Moze sie on znajdowac w jednym z czterechstanów pokazanych na diagramie 5.12. Cel jest „rozpoznawalny” tylko wtedy, gdyznajduje sie w stanie aktywnym.

Uwaga. Z niewiadomych jednak przyczyn, stanem posrednim w aktywacji i dezak-tywacji celu jest przetwarzanie.

Czesc funkcjonalnosci odpowiedzialnej za rozpoznawanie i tworzenie obiektównapisana jest przy uzyciu Android Native Development Kit (NDK) w jezyku C++ zwykorzystaniem warstwy posredniczacej JNI. Kod kompilowany jest do bibliotekidynamicznej .so i ładowany przy pierwszym jej wykorzystaniu w aplikacji.

5.8.1. Zdefiniowane znaczniki

Sekwencja opisujaca rozpoznawanie obiektu przedstawiona została w jednej zpoprzednich czesci, na diagramie 3.4. Funkcja ta w grze została wykorzystana doznajdowania zdefiniowanych wczesniej celów przedstawionych na rysunku 5.13. Wmomencie rozpoznania, zostaje wywołana metoda klasy aktywnosci, która wyswie-tla jedyny punkt wejscia (ang. entry point) do „ukrytej” czesci aplikacji widocznejna rysunku 5.14.

Główna funkcja odpowiadajaca za odrysowywanie ramki i propagacje danych oznalezionych obiektach przedstawiona została na wydruku 5.3.

1 JNIEXPORT void JNICALLJava_pl_edu_pw_elka_mmarkiew_game_camera_target_TargetActivity_renderFrame

(JNIEnv∗ , job ject ){

20 Tj. na serwerze Vuforii


Rysunek 5.12. Stany przetwarzania celu na serwerze Vuforii

5 glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) ;// Pobranie stanu tracker ’aQCAR: : State state = QCAR: : Renderer : : getInstance ( ) . begin ( ) ;// Odrysowanie t la − ramkiQCAR: : Renderer : : getInstance ( ) . drawVideoBackground ( ) ;

10 // I l osc znalezionych celowi f ( state . getNumTrackableResults ( ) > 0) {

// I te rac ja po wynikachfor ( int tIdx = 0; tIdx < state . getNumTrackableResults ( ) ; ++tIdx ) {

const QCAR: : TrackableResult∗ trackableResult =15 state . getTrackableResult ( tIdx ) ;

const QCAR: : Trackable& trackable = trackableResult−>getTrackable ( ) ;// Pobranie celu wynikowego ( typu obrazkowego )assert ( trackableResult−>getType ( ) ==

QCAR: : TrackableResult : : IMAGE_TARGET_RESULT) ;20 const QCAR: : ImageTargetResult∗ imageTargetResult =

static_cast<const QCAR: : ImageTargetResult∗>( trackableResult ) ;// Pobranie srodka znalezionego/rozpoznanego obiektuconst QCAR: : CameraCalibration& cameraCalibration =

QCAR: : CameraDevice : : getInstance ( ) . getCameraCalibration ( ) ;25 QCAR: : Vec2F cameraPoint = QCAR: : Tool : : projectPoint ( cameraCalibration ,

trackableResult−>getPose ( ) , QCAR: : Vec3F(0 ,0 ,0) ) ;QCAR: : Vec2F xy_point = cameraPointToScreenPoint ( cameraPoint ) ;


Rysunek 5.13. Wykorzystane w grze zdefiniowane cele

// Wywolanie funkc j i wykonujacej propagacje do aktywnosci30 showTrackerButton ( xy_point . data [0 ] , xy_point . data [1 ] ,

trackable .getName ( ) ) ;

// Pobranie wielkosci znalezionego/rozpoznanego obiektu/∗QCAR: : Matrix34F pose = trackableResult−>getPose ( ) ;

35 QCAR: : Vec3F posi t ion ( pose . data [ 3 ] , pose . data [ 7 ] , pose . data [ 1 1 ] ) ;f l oa t distance = sqrt ( posi t ion . data [ 0 ] ∗ posi t ion . data [ 0 ] +

posi t ion . data [ 1 ] ∗ posi t ion . data [ 1 ] +posi t ion . data [ 2 ] ∗ posi t ion . data [ 2 ] ) ;

QCAR: : Vec2F targetSize = imageTargetResult−>getTrackable ( ) . getSize ( ) ; ∗/40 }

} else i f ( ! isTrackerHide ) {// Brak znalezionych celow − propagacja do aktywnosci// z informacja o braku rozpoznaniahideTrackerButton ( ) ;

45 }

// Koniec ewentualnego generowania gra f ik iQCAR: : Renderer : : getInstance ( ) . end ( ) ;

}

Wydruk 5.3. Główna funkcja petli zdarzen

5.8.2. Tworzenie własnych celów

Definiowanie własnych celów polega na przechwyceniu obrazu z kamery i wyko-rzystanie go do stworzenia nowego celu. Sekwencja pokazujaca działanie przedsta-wiona jest na diagramie 5.15, a ponizej znajduje sie jej opis.

Po przechwyceniu ramki i analizie jej jakosci (rankingu)21, wartosc przekazy-wana jest do watku widoku aplikacji i przedstawiana uzytkownikowi w postacioceny (ang. rating) widocznej na rysunku 5.1622.

Uzytkownik naciska przycisk gdy zdecyduje sie na stworzenie celu z obrazu.Nastepnie ramka jest przechwytywana i tworzony jest obiekt w natywnej czesciaplikacji. Wykorzystywany jest on tak samo jak zdefiniowany cel i nastepuje jegorozpoznawanie.

21 Mozliwy ranking przedstawiony został w tabeli 5.122 Wyznaczone cechy obrazu przedstawione zostały na rysunku 5.17


Rysunek 5.14. Zrzut ekranu - znaleziony cel

Tablica 5.1. Zdefiniowana w bibliotece ocena jakosci obrazu

Wartosc numeryczna ZnaczenieFRAME_QUALITY_NONE brak cech, niemozliwe do rozpoznaniaFRAME_QUALITY_LOW mało cech, mozliwe problemy z rozpoznaniemFRAME_QUALITY_MEDIUM przecietna ilosc cech, dobry celFRAME_QUALITY_HIGH wiele cech, bardzo dobry cel

Gdy uzytkownik stwierdzi, ze cel jest dobrze rozpoznawany, wpisuje tresc wia-domosci i wysyła obraz na serwer. Dane zapisywane sa na serwerze aplikacji iwysyłane do obróbki na serwer biblioteki, aby stał sie rozpoznawalny w chmurze.

Uwaga. Wgranie zdefiniowanego celu bezposrednio z urzadzenia mobilnego nieudało sie pomimo licznych prób. Mechanizm działa jedynie z serwera, gdzie wprzeciwienstwie do telefonu - zadanie przechodzi proces autoryzacji.

Nastepnie serwer aplikacji zaczyna odpytywac o stan przetwarzania w jakimznajduje sie stworzony cel. W przypadku aktywacji lub błedu, serwer powiadamiagracza o stanie obiektu. Sekwencja ta została przedstawiona na diagramie 5.18.

Cele na serwerze

Rozpoznawanie zdefiniowanych celów pokazuje przedstawiony wczesniej dia-gram sekwencji 3.5. W momencie pozytywnego rozpoznania, identyfikator celuwysyłany jest na serwer aplikacji w celu pobrania wiadomosci zdefiniowanej przezuzytkownika. Na serwerze nastepuje sprawdzenie czy aktualna pozycja graczaznajduje sie w poblizu miejsca zdefiniowania celu. W przypadku pozytywnego re-zultatu, zwracana jest wiadomosc lub kod błedu gdy sprawdzenie nie powiodło sie.

5.9. Przebieg walki miedzy graczami 48

Rysunek 5.15. Diagram sekwencji - tworzenie własnego celu

Zrzuty ekranu 5.19 i 5.20 przedstawiaja proces skanowania celu i wyswietleniewiadomosci. Dodatkowo zastosowano proste zanikanie wiadomosci w zaleznosci od„wieku” utworzonego celu.

5.9. Przebieg walki miedzy graczami

Jednym z załozen gry była mozliwosc walki miedzy graczami. Podczas aktuali-zacji własnej pozycji, pobierana jest informacja o graczach znajdujacych sie w oto-czeniu. Gdy w zasiegu uzytkownika znajdzie sie inny gracz, wysyłane jest lokalnepowiadomienie informujace o tym zdarzeniu. Wtedy jest tez mozliwe zaatakowaniewroga.

W momencie ataku, na serwerze jest tworzony i zapisywany w bazie danychobiekt identyfikujacy nowa walke. Walka traktowana jest jak maszyna stanowa,w której wystepuje atakujacy i obronca. Mozliwy wynik walki przedstawiony jestna diagramie 5.21. Przebieg walki jest utrwalany w postaci wiadomosci23, napodstawie których mozna go łatwo odtworzyc.

23 Struktura wiadomosci przedstawiona jest na diagramie 5.6


Rysunek 5.16. Zrzut ekranu - tworzenie własnego celu. Zielone gwiazdki u góryekranu symbolizuja jego jakosc

Atak

Mozliwy jest atak przeciwnika za pomoca wybranej broni lub czaru, które moznanabyc w odpowiednim sklepie. Po wykonaniu ataku przeciwnik ma szanse naobrone. Polega ona na wykonaniu prostego zadania np. podania rozwiazania rów-nania lub dotkniecie kolejnych punktów generowanych na ekranie przez okreslonyczas itp.

W momencie wykonania ataku, na serwerze wyznaczany jest czas na obrone.Tworzone jest zadanie (ang. task) odroczone o zadany okres czasu, zeby dokonacsprawdzenia czy obrona została wykonana. W przypadku jej braku, przeciwnikzostaje trafiony i zmniejszany jest poziom jego zycia. Czas obrony, wielkosc obrazenoraz zasieg, wyznaczane sa na podstawie uzytej broni i umiejetnosci które graczzdobył w przeszłosci.

Wprowadzonych zostało kilka ograniczen dotyczacych walki. Naleza do nichm.in. nastepujace dwa: kolejny atak gracza nie moze nastapic przed upływemczasu na obrone pierwszego, jak równiez przeciwnik nie moze wykonac ataku domomentu wykonania własnej obrony (udanej lub nie).

Walka moze skonczyc sie na 3 sposoby:— Jeden z graczy zginie - zwyciezca otrzymuje połowe pieniedzy przeciwnika iobliczona ilosc doswiadczenia,

— Jednemu z graczy wygasnie sesja, ucieknie poza zasieg widocznosci przeciw-nika lub zostanie zabity przez innego gracza - wynikiem walki jest remis,

— Jeden z graczy podda sie - zwyciezca otrzymuje połowe pieniedzy przeciwnika.


Rysunek 5.17. Cechy wyznaczone na przechwyconej ramce obrazu

Graczowi który przegra walke ustawiany jest czas ochrony (ang. spawn protection)(30 min). Do czasu jego upłyniecia, gracz nie moze zostac zaatakowany jak równieznie moze on zaatakowac innego przeciwnika.

Czary

Druga z mozliwosci wykonania ataku jest rzucenie czaru za pomoca jednej z 4metod:

1 Wybranie czaru z listy - zapewnione 15% siły ataku,2 Wymówienie nazwy zaklecia - 30% siły ataku,3 Narysowanie wzoru zaklecia na ekranie - maksymalnie 50% siły ataku,4 Wykonanie gestu urzadzeniem - maksymalnie 100% siły ataku.

W zaleznosci od wybranej metody, obliczany jest rózny poziom obrazen. W drugiejmetodzie, poprawne dopasowanie wyrazenia24 uznawane jest jako udany atak.

Trzeci rodzaj ataku polega na narysowaniu przedstawionego na ekranie urza-dzenia wzoru, bez odrywania palca. Przykładowy zrzut ekranu znajduje sie narysunku 5.22.

Do obliczenia poziomu dopasowania wykorzystany został zaimplementowanyalgorytm DTW. Dane w serii definiujacej wzór składaja sie z dwóch wartosci.Pierwsza okresla procentowa wartosc połozenia punktu w stosunku do szerokosciekranu, a druga w stosunku do jego wysokosci. Schemat przedstawiony został narysunku 5.23. Dzieki takiemu podejsciu, wzory nie sa zalezne od rozdzielczosciekranu. Jednakze odrysowany gest nie moze byc przesuniety wzgledem wzoru, corówniez pokazane zostało na rysunku 5.23. Mozliwe jest jednak wyrównywaniewartosci do punktu (0, 0) ekranu w celu zniwelowania problemu.

24 Wykorzystany został SpeechRecognizer systemu Android

5.10. Dodatkowe elementy rozgrywki 51

Rysunek 5.18. Diagram sekwencji - wysyłanie celu na serwer

Ostatni, trzeci rodzaj ataku polega na wykonaniu gestu urzadzeniem. Dlazadanego gestu wyliczany jest wynik działania algorytmu DTW kazda z czterechmetod opisanych w czesci 4.2. Wyznaczana jest srednia wyników uzyskanychkazda z metod dla wszystkich jego predkosci (wolno, zwyczajnie, szybko, bardzoszybko). Jako wynik zwracane jest najlepsze dopasowanie.

5.10. Dodatkowe elementy rozgrywki

Na całokształt gry składa sie dodatkowo szereg mniejszych elementów. W tejczesci zostały przedstawione i krótko opisane.

Wiadomosci

W trakcie trwania rozgrywki gracze sa na biezaco informowani o zdarzeniach dlanich istotnych. Mozliwe jest równiez wysłanie prostej wiadomosci do przeciwnikaznajdujacego sie w poblizu.

Rozróznianych jest wiele typów wiadomosci identyfikowanych kodami25, którezawieraja specyficzne dla siebie dane. Klasy je reprezentujace zostały przedsta-wione na diagramie 5.7 i podzielone na trzy rodzaje:

— Informujace o pierwszym ataku wroga i wyniku walki,— Informujace o wynikowym stanie zleconego zabójstwa/polowania,

25 Kody oznaczajace typy wiadomosci przedstawione sa na diagramie 5.4


Rysunek 5.19. Zrzut ekranu - skanowanie w poszukiwaniu celu. Kropki oznaczajapotencjalne cechy obrazu

— Informujace o wiadomosci od innego uzytkownika.Mozliwe jest przegladanie i lokalne usuwanie odebranych wiadomosci. Do infor-

mowania o nowych wiadomosciach wykorzystany został opisany wczesniej mecha-nizm powiadamiania.

Informacje uzytkownika - umiejetnosci

Gracz opisywany jest kilkoma atrybutami. Naleza do nich:— Poziom zycia - zwiekszany cyklicznie do poziomu 100%,— Ilosc pieniedzy - zdobywane z wygranych walk i wykonanych zlecen26,— Punkty doswiadczenia - zdobywane na podstawie wygranych walk w zalezno-sci od poziomu przeciwnika,

— Poziom energii (tzw. (ang. mana)) - zwiekszany cyklicznie do poziomu 200pkt,wymagany do rzucania zaklec.W trakcie trwania rozgrywki uaktualniane sa liczniki informujace o osiagnie-

ciach gracza. Liczony jest czas zalogowania uzytkownika, liczba wykonanych za-bójstw, liczba smierci gracza, liczba poddanych walk oraz liczba upolowanych prze-ciwników.

Dostepne sa równiez umiejetnosci, których poziom gracze zwiekszaja wraz zezdobywaniem doswiadczenia. Gracz zdobywa kolejne punkty do wykorzystania, aumiejetnosciami sa:

— Szpiegowanie - zwieksza zasieg radaru gracza,— Celowanie - zwieksza poziom obrazen przy ataku bronia,

26 Krótki opis w nastepnej czesci 5.10


Rysunek 5.20. Zrzut ekranu - wiadomosc zostawiona przez gracza

— Obrona - zmniejsza poziom doznanych obrazen,— Magia - zwieksza poziom obrazen przy uzyciu czarów i szybkosc regeneracjienergii.W aplikacji mozliwy jest podglad aktualnych danych, których przykład przed-

stawia rysunek 5.24.

Zlecenia - polowanie

Co okreslony czas za posrednictwem zaplanowanego zadania demona (ang.cron), generowane jest zlecenie zabójstwa losowego gracza. Wyznaczany jest ter-min wygasniecia i nagroda pieniezna. Gracze moga podazac za generowanymi zle-ceniami lub tworzyc własne. Gdy gracz posiada aktywne zlecenia i wygra walkez przeciwnikiem widniejacym na tej liscie, dostaje dodatkowe pieniadze. Zlecenieprzechodzi w stan wykonany i tak samo jak w przypadku anulowania lub wyga-sniecia, zostaje wysłana informacja do zainteresowanych nim graczy.

Podazanie za zleceniami i ich tworzenie mozliwe jest przez znalezienie jednegoze znaczników komunikacji miejskiej27. W celu doprowadzenia do ostatniej znanejpozycji gracza bedacego celem, wykorzystana została nawigacja urzadzenia.

Radar

Dostepny jest prosty radar przedstawiony na rysunku 5.25 i pokazujacy prze-ciwników w otoczeniu gracza. Zasieg widocznosci okreslany jest na podstawie po-ziomu posiadanej umiejetnosci szpiegowania (ang. Spy) i wynosi r = 500 + spy ∗ 20metrów. Po nacisnieciu w dymek znacznika na mapie, mozliwe jest rozpoczeciewalki lub wysłanie wiadomosci do przeciwnika.

27 Znaczniki przedstawione na rysunku 5.13


Rysunek 5.21. Diagram stanów - wynik walki

Gracz zgodnie z ustawionym w opcjach aplikacji odstepem czasu wysyła swojaaktualna pozycje i odbiera informacje o graczach bedacych w jego otoczeniu. Wmomencie pojawienia sie kolejnego wroga wysyłane jest powiadomienie na paskupowiadomien (ang. Status bar).

Sklep

Mozliwe jest kupowanie dodatkowych egzemplarzy broni i nowych czarów. Abyto uczynic, uzytkownik aplikacji musi znalezc odpowiedni sklep reprezentowanyznacznikiem28. Stanowi on punkt wejscia do sklepu z wykorzystaniem zdefiniowa-nych wczesniej celów opisanych w sekcji 5.8.1.

Kazda bron rózni sie celnoscia i siła, a zaklecia dodatkowo poziomem energiiwymaganym do ich uzycia. Produkty opisane sa równiez cena i minimalnym po-ziomem doswiadczenia pozwalajacym na zakup. Wszyscy gracze posiadaja ponadtodomyslna bron.

28 Znaczniki przedstawione na rysunku 5.13

5.11. Napotkane problemy 55

Rysunek 5.22. Przykładowy rysowany wzór dopasowania

5.11. Napotkane problemy

W trakcie trwania prac nad projektem zostało napotkanych kilka problemów.Ponizej zostały one przedstawione i krótko opisane ich rozwiazanie.

Znaczniki

Załozeniem gry było rozpoznanie obiektu w rzeczywistym miejscu - np. szyld rze-czywistego sklepu. W trakcie prac nad aplikacja napotkano problem z wykryciempotencjalnego oszustwa zwiazanego z drukowaniem znaczników29 i wykorzystywa-niem ich jako punktów wejscia do ukrytej czesci aplikacji.

Podjete zostały próby wyeliminowania takiej mozliwosci. Pierwsza była próbaokreslenia odległosci od celu i wyznaczenie jego rozmiaru. W przypadku szyldów,rzeczywisty rozmiar byłby rzedu kilku metrów, jednakze nie jest mozliwe obliczeniewielkosci celu na podstawie płaskiego obrazu. Drugim mozliwym rozwiazaniemjest zdefiniowanie połozenia w których mozna znalezc cele i tylko w ich obrebiepozwalac na pozytywne rozpoznanie. Wymaga to jednak recznego wprowadzaniatakich wartosci, które moga zmieniac miejsce.

Zdecydowano sie proste zabezpieczenie polegajace na wykorzystaniu sygnałuGPS. Nie ma mozliwosci wejscia do ukrytej czesci aplikacji gdy sygnał GPS nie

29 Powszechnie wykorzystywanego przy testach działania aplikacji, w trackie jej tworzenia

5.11. Napotkane problemy 56

Rysunek 5.23. Metryka zapisywanych danych wzoru i problem dopasowania przyuzyciu DTW

jest dostepny. Wynika to z faktu, iz wymusza obecnosc uzytkownika w otwartymterenie, gdzie dostepny jest sygnał satelitarny. Niestety zastosowane rozwiazanienie rozwiazuje problemu, a jedynie wprowadza proste ograniczenie.

Walka

W trakcie prac nad aplikacja napotkano problemy zwiazane z zapisem danychdo bazy typu NoSQL. Bazy tego typu zaprojektowane sa do przechowywania wiel-kich wolumenów danych i efektywnego do nich dostepu. Jest to mozliwe dziekizastosowaniu konfiguracji magazynu danych składajacego sie z wielu serwerów(ang. High Replication Datastore (HRD)). Zapewniany jest wtedy dostep do danychnie gwarantujacy ich najswiezszych wersji (ang. eventual consistency).

Do przeprowadzenia walki graczy, która opiera sie na odpowiedniej koordyna-cji czasowej (ang. timing), wymagane sa aktualne dane. Dzieki kilku zabiegom30

mozliwe jest uzyskanie silnej spójnosci danych (ang. strong consistency). Pole-gaja one na uzyciu zapytan z uzyciem przodków (ang. ancestor queries) dla grupobiektów (ang. entity groups). Dodatkowym zabiegiem zastosowanym w aplikacjibyło wyłaczenie mechanizmu pamieci podrecznej (ang. cache) powodujacego odczyt

30 https://developers.google.com/appengine/docs/python/datastore/structuring_for_strong_consistency

5.12. Mozliwe kierunki rozwoju aplikacji 57

Rysunek 5.24. Zrzut ekranu - widok z informacjami o graczu

nieaktualnych danych. Nie jest to rozwiazanie doskonałe, jednakze sprawdza sie waktualnym zastosowaniu.

Baza danych

W trakcie generowania bibliotek udostepniajacych API wspomnianych usług,wystapiły problemy z nieobsługiwanymi typami generycznymi. Miało to miejsceze wzgledu na dosyc młoda i ciagle rozwijana implementacje technologii tworzonaprzez firme Google. Wymusiło to zastosowanie dodatkowego opisu niektórych pólklasy przez adnotacje @ApiResourceProperty(ignored = AnnotationBoolean.TRUE) istworzenie dodatkowych namiastek (ang. stubs) po stronie klienta.

Serwer

Pełne wykorzystanie mozliwosci aplikacji serwerowej po publikacji (ang. deploy)na serwerze Google31 nie jest mozliwe. Wynika to z koniecznosci właczenia rozli-czenia (ang. billing) za niektóre czesci systemu takie jak wykonywanie zadan przezserwer. Mozliwym rozwiazaniem jest stworzenie lokalnego deweloperskiego serwerai odpowiednie przekierowanie portów wykorzystujac własne połaczenie internetowe.

5.12. Mozliwe kierunki rozwoju aplikacji

W trakcie pracy nad projektem, poznano wykorzystywane technologie. Zostałopracowany swego rodzaju szkielet, który mozna rozszerzac o kolejne funkcje. Na-lezy w prosty sposób dodac nowe API serwera opisywane w rozdziale 5.7 i stworzycodpowiednie aktywnosci klienta, które z nich korzystaja.

Dodatkowym aspektem pominietym w pracy jest grafika. Jest to jeden z głów-nych elementów przyciagajacych uzytkowników i dlatego dopracowanie wygladu

31 http://appspot.com

5.12. Mozliwe kierunki rozwoju aplikacji 58

Rysunek 5.25. Zrzut ekranu - widok radaru

interfejsu uzytkownika GUI oraz dodatnie efektów graficznych znaczaco polepszy-łoby wizerunek aplikacji. Proces ten jest zmudny i potrzeba czasu na dobre jegodopracowanie.

Nalezy zauwazyc, ze ograniczenia czasowe nie pozwoliły na przetestowanie dzia-łania aplikacji na duzej liczbie uzytkowników. Warto przeprowadzic testy obcia-zeniowe, celem sprawdzenia zachowania aplikacji w momencie gdy korzysta z niejwielu graczy jednoczesnie.

6. Podsumowanie

Tematem pracy było stworzenie aplikacji mobilnej, która wykorzystuje elementyrozszerzonej rzeczywistosci. Główny nacisk został połozony na element rozpozna-wania gestów przestrzennych, a stworzona aplikacja jest gra wieloosobowa wyko-rzystujaca architekture klient-serwer. Realizacja projektu wymagała zapoznania siez zagadnieniami rozszerzonej rzeczywistosci oraz technologiami przeznaczonymi naurzadzenia mobilne i platformy serwerowe.

Postawione wymagania i cele pracy udało sie zrealizowac w znaczacej czesci. Zewzgledu na ograniczenia czasowe nie została osiagnieta pełna funkcjonalnosc gry.Jednakze pominiete zostały elementy dodatkowe - urozmaicajace rozgrywke, niemajace duzego znaczenia w kontekscie tematu niniejszej pracy.

Dowiedziono mozliwosci rozpoznawania gestów z uzyciem algorytmu DynamicTime Warping wykorzystujac dane z akcelerometru urzadzenia. Pokazane zostałyrówniez jego słabe strony i ograniczenia. Niemniej jednak wykazano słusznosc jegozastosowania ze wzgledu na prostote implementacji.

W trakcie prac nad projektem napotkano problemy natury programistycznej,czesto zwiazanymi z wykorzystaniem specyficznych technologii. Kwestia problema-tyczna była implementacja i testowanie aplikacji rozproszonych, które opieraja siena rzeczywistych ograniczeniach czasowych. Udało sie jednak im sprostac, czegowynikiem jest niniejsza praca.

Pozostaje jeszcze wiele mozliwych sciezek rozwoju aplikacji. Zaczynajac od im-plementacji pominietych funkcji, a konczac na stworzeniu przyciagajacego inter-fejsu uzytkownika. Dodatkowym punktem do zastanowienia moze byc przenie-sienie na serwer czesci odpowiedzialnej za obliczenia wykorzystanego algorytmuDTW. Zmniejsza to wykorzystanie mocy obliczeniowej urzadzenia lecz niesie zasoba ograniczenia zwiazane z obsługa operacji sieciowych.

Bibliografia

[1] Android NDKhttp://developer.android.com/tools/sdk/ndk/index.html.

[2] Developing with Vuforiahttps://developer.vuforia.com/resources/dev-guide/getting-started.

[3] Google App Engine restful interfacehttp://c.appengine-examples.com/learn/endpoints.

[4] Google Maps Android API v2https://developers.google.com/maps/documentation/android/.

[5] Java Service APIshttps://developers.google.com/appengine/docs/java/apis?hl=pl.

[6] metaio Developer Portalhttps://dev.metaio.com/sdk/getting-started/.

[7] Motion Sensorshttp://developer.android.com/guide/topics/sensors/sensors_motion.html.

[8] objectify-appenginehttps://code.google.com/p/objectify-appengine/.

[9] Sensors Overviewhttp://developer.android.com/guide/topics/sensors/sensors_overview.html.

[10] Structuring Data for Strong Consistencyhttps://developers.google.com/appengine/docs/java/datastore/structuring_for_strong_consistency.

[11] 7 things you should know about augmented reality, 2005.http://net.educause.edu/ir/library/pdf/ELI7007.pdf

[12] Sensor Fusion on Android Devices: A Revolution in Motion Processing, 2010http://www.youtube.com/watch?v=C7JQ7Rpwn2k.

[13] Dariusz Banasiak. Sztuczna inteligencja - wykładhttp://www.mimuw.edu.pl/ tiuryn/zajecia/wykl_mon_05/hmm.pdf.

[14] Johan Bas. 3-dimensional gesture recognition: Algorithms and applications, 2011http://wise.vub.ac.be/content/3-dimensional-gesture-recognition-algorithms-and-applications.

[15] Johan Bas. A 3d gesture recognition extension for igesture. Praca magisterska, VrijeUniversiteit Brussel, 2011http://wise.vub.ac.be/sites/default/files/theses/thessisBasJohan.pdf.

[16] Shane Conder, Lauren Darcey. Android. Programowanie aplikacji na urzadzenia prze-nosne. Wydanie II. Helion, 2011.

[17] Meinard Müller. Information retrieval for music and motion. rozdzia/l 4 - DynamicTime Warping. Springer, 2007http://www.springer.com/cda/content/document/cda_downloaddocument/9783540740476-c1.pdf?SGWID=0-0-45-452103-p173751818.

[18] Stan Salvador, Philip Chan. Fastdtw: Toward accurate dynamic time warping in lineartime and space, 2004http://cs.fit.edu/ pkc/papers/tdm04.pdf.

[19] Thomas Schlomer, Benjamin Poppinga, Niels Henze, Susanne Boll. Gesture recogni-tion with a wii controller. University of Oldenburg and OFFIS Institute for Information

Bibliografia 61

Technology, 2007http://www.wiigee.org/download_files/gesture_recognition_with_a_wii_controller-schloemer_poppinga_henze_boll.pdf.

[20] J. Tiuryn. Wstep do obliczeniowej biologii molekularnejhttp://www.mimuw.edu.pl/˜tiuryn/zajecia/wykl_mon_05/hmm.pdf.

[21] uWave: Accelerometer-based Personalized Gesture. Jiayang liu and zhen wang andzhong and lin and jehan wickramasuriya and venu vasudevan, 2008http://www.ruf.rice.edu/ mobile/publications/liu09percom.pdf.

[22] Adam Witczak, Jakub Tezycki. Zastosowanie zaawansowanych kontrolerów gier dotworzenia naturalnych interfejsów uzytkownika. Praca magisterska, PolitechnikaWarszawska - wydział Matematyki i Nauk Informacyjnych, 2009.

Aplikacja mobilna z wykorzystaniem rozszerzonej rzeczywistosci´ · Aplikacja mobilna z...

Documents

Transcript of Aplikacja mobilna z wykorzystaniem rozszerzonej rzeczywistosci´ · Aplikacja mobilna z...