WYDZIAŁ INFORMATYKI, ELEKTRONIKI I TELEKOMUNIKACJI

KATEDRA TELEKOMUNIKACJI

PROJEKT INŻYNIERSKI

Opracowanie rozszerzonej/wirtualnej rzeczywistości z wykorzystaniemokularów do rozszerzonej/wirtualnej rzeczywistości

Implementation of augmented/virtual reality using augmented/virtual reality goggles

Autor: Antoni Grzanka, Adam NiedziałkowskiKierunek studiów: Teleinformatyka Opiekun pracy: dr inż. Bartosz Ziółko

Kraków, 2016

1

Uprzedzony o odpowiedzialności karnej na podstawie art. 115 ust. 1 i 2 ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (t.j. Dz.U. z 2006 r. Nr 90, poz. 631 z późn. zm.): „ Kto przywłaszcza sobie autorstwo albo wprowadza w błąd co do autorstwa całości lubczęści cudzego utworu albo artystycznego wykonania, podlega grzywnie, karze ograniczenia wolności albo pozbawienia wolności do lat 3. Tej samej karze podlega, kto rozpowszechnia bez podania nazwiska lub pseudonimu twórcy cudzy utwór w wersji oryginalnej albo w postaci opracowania, artystyczne wykonanie albo publicznie zniekształca taki utwór, artystyczne wykonanie, fonogram, wideogram lub nadanie.”, a także uprzedzony o odpowiedzialności dyscyplinarnej na podstawie art. 211 ust. 1 ustawy z dnia 27 lipca 2005 r. Prawo o szkolnictwie wyższym (t.j. Dz. U. z 2012 r. poz. 572, z późn. zm.) „Za naruszenie przepisów obowiązujących w uczelni oraz za czyny uchybiające godności studenta student ponosi odpowiedzialność dyscyplinarną przed komisją dyscyplinarną albo przed sądem koleżeńskim samorządu studenckiego, zwanym dalej „sądem koleżeńskim”, oświadczam, że niniejszą pracę dyplomową wykonałem(-am) osobiście, samodzielnie i że nie korzystałem(-am) ze źródeł innych niż wymienione w pracy.

Antoni Grzanka

Adam Niedziałkowski

2

Spis treści 1.Wstęp................................................................................................................................................5 2.Wirtualna a rozszerzona rzeczywistość (A.Grzanka).......................................................................7

2.1.Kontinuum rzeczywistość-wirtualność.....................................................................................7 2.2.Historia oraz state-of-the-art.....................................................................................................9

3.Wykorzystywany sprzęt (A. Grzanka)............................................................................................15 3.1.Standard Google Cardboard....................................................................................................15 3.2.Sprzęt wykorzystywany w pracy............................................................................................18

4.Implementacja wirtualnej rzeczywistości (A. Grzanka).................................................................21 4.1.Platforma Unity3D..................................................................................................................21 4.2.Struktura projektu w Unity3D................................................................................................21 4.3.Implementacja wykorzystywana w badaniach.......................................................................22

5.Implementacja rozszerzonej rzeczywistości (A. Grzanka).............................................................28 5.1.Biblioteka Vuforia...................................................................................................................28 5.2.Kluczowe elementy biblioteki Vuforia...................................................................................29 5.3.Implementacja wykorzystywana w badaniach.......................................................................31

6.Metodologia badań user experience (A. Niedziałkowski)..............................................................35 6.1.Definicja..................................................................................................................................35 6.2.Cel badań................................................................................................................................35 6.3.Badana próbka........................................................................................................................35 6.4.Przebieg badań........................................................................................................................38

7.Wyniki badań (A. Niedziałkowski)................................................................................................40 7.1.Pytanie pierwsze.....................................................................................................................40 7.2.Pytanie drugie.........................................................................................................................42 7.3.Pytanie trzecie.........................................................................................................................44 7.4.Pytanie czwarte.......................................................................................................................45 7.5.Pytanie piąte............................................................................................................................46

8.Propozycje rozwiązań (A. Niedziałkowski)...................................................................................47 8.1.Platforma Android...................................................................................................................47 8.2.Aplikacja I...............................................................................................................................48 8.3.Aplikacja II.............................................................................................................................49 8.4.Camera API.............................................................................................................................50 8.5.MJPEG....................................................................................................................................55

9.Druga część badań (A. Niedziałkowski)........................................................................................57 9.1.Przebieg badań........................................................................................................................57 9.2.Wyniki badań..........................................................................................................................58 9.3.Pytanie drugie.........................................................................................................................59 9.4.Pytanie trzecie.........................................................................................................................60

10.Podsumowanie pracy....................................................................................................................62 11.Bibliografia...................................................................................................................................63 12.Źródła ilustracji............................................................................................................................65

3

4

1. Wstęp

Tematem pracy jest opracowanie wirtualnej/rozszerzonej rzeczywistości przy wykorzystaniu

okularów wirtualnej/rozszerzonej rzeczywistości. Praca ma charakter badawczy.

Głównym celem pracy jest sprawdzenie czy istnieje możliwość stworzenia niskobudżetowych

implementacji wirtualnej i rozszerzonej rzeczywistości. W tym celu, autorzy wykorzystali okulary

wirtualnej rzeczywistości zgodne ze standardem Google Cardboard oraz smartfony z systemem

operacyjnym Android i stworzyli cztery aplikacje. W celu konfrontacji zaproponowanych

rozwiązań z rzeczywistością, przeprowadzono badania user experience na próbie 78 osób,

wyciągnięto z nich wnioski i zaproponowano kilka możliwych rozwiązań napotkanych problemów.

W rozdziale 2 opisano pojęcia wirtualnej oraz rozszerzonej rzeczywistości, wraz z rysem

historycznym oraz najważniejszymi wydarzeniami z historii jego rozwoju. Informacje te są

szczególnie ważne w kontekście rozwoju ww. dziedzin który odbywa się obecnie.

W rozdziale 3 przedstawiono zasadę działania okularów (gogli) wirtualnej rzeczywistości zgodnych

ze standardem Google Cardboard oraz dokonano charakterystyki wykorzystywanych w pracy

okularów Weebo3D i smartfonów.

W rozdziale 4 opisano implementację systemu wirtualnej rzeczywistości przy wykorzystaniu

platformy Android oraz opisanych wyżej okularów.

Rozdział 5 poświęcony jest dyskusji na temat implementacji rozszerzonej rzeczywistości przy

wykorzystaniu takiego samego sprzętu. Opisano krótko zasadę działania biblioteki Vuforia.

Przedstawiony został również działający prototyp aplikacji.

W rozdziale 6 opisano pokrótce metodologię przeprowadzonych badań user experience.

Przedstawiono zasadność wyboru takiego typu badania.

W rozdziale 7 przedstawiono wyniki badań oraz wyciągnięto z nich wnioski.

W rozdziale 8 autorzy proponują dwa rozwiązania mogące poprawić komfort korzystania z

zaproponowanych implementacji, biorąc pod uwagę wnioski wyciągnięte z przeprowadzonych

badań.

Rozdział 9 zawiera opis kolejnego przeprowadzonego eksperymentu, w którym wykorzystano

zaproponowane w poprzednim rozdziale usprawnienia. Przedstawiono wyniki drugiej części badań

oraz wyciągnięto wnioski.

5

Rozdział 10 stanowi podsumowanie całej pracy. Zebrano wnioski z poszczególnych rozdziałów.

6

2. Wirtualna a rozszerzona rzeczywistość (A.Grzanka)

Przed rozpoczęciem faktycznych rozważań o Wirtualnej i Rozszerzonej Rzeczywistości, warto

usystematyzować definicje tych pojęć oraz różnice między nimi.

2.1. Kontinuum rzeczywistość-wirtualność

Paul Milgram w swojej pracy z 1941 zaproponował usystematyzowanie różnych dziedzin

wirtualizacji rzeczywistości. Stworzył “kontinuum”, skalę od całkowicie realnego do świata

całkowicie wirtualnego (ilustracja 1). Pomimo jej ciągłości, można wyróżnić cztery główne punkty:

• Świat rzeczywisty (rzeczywistość, ang. Reality)

Wszystkie elementy świata są rzeczywiste.

• Rozszerzona rzeczywistość (ang. Augmented Reality)

Świat składa się głównie z elementów świata rzeczywistego, rozszerzony jest jednak o

pojedyncze elementy wirtualne wygenerowane komputerowo. Za przykład może posłużyć

tutaj znany projekt Google Glass.

• Rozszerzona wirtualność (ang. Augmented Virtuality)

Świat składa się główne z elementów wirtualnych wygenerowanych komputerowo,

rozszerzony jest jednak o pojedyncze elementy rzeczywiste. Przykładem może być gra, w

której główny bohater może przyjąć twarz #gracza#.

• Świat wirtualny (wirtualna rzeczywistość, ang. Virtual Reality, Virtuality)

Wszystkie elementy świata są wirtualne i wygenerowane komputerowo. Jako przykład

można podać większość gier komputerowych.

Wszystko, co nie jest czystą rzeczywistością ani czystą wirtualnością określane jest mianem

Mieszanej Rzeczywistości (ang. Mixed Reality).

7

Ilustracja 1: Diagram kontinuum rzeczywistość-wirtualność wg Paula Milgrama

8

W praktyce, istnieje spora różnica w implementacji wirtualnej i rozszerzonej rzeczywistości.

Podczas gdy w tej pierwszej scena generowana jest całkowicie komputerowo i użytkownik ma

wrażenie jakby wcielał się w nieistniejącą, wirtualną postać, w tej drugiej scena generowana jest na

podstawie przetwarzanego w czasie rzeczywistym obrazu z kamer i użytkownik powinien mieć

wrażenie, że pozostaje sobą, a “przenosi się” jedynie do innego świata.

Dla wygody, w dalszej części pracy stosowane są ogólnie przyjęte skrótowce: VR jako „wirtualna

rzeczywistość” (z angielskiego Virtual Reality), AR zamiast „rozszerzona rzeczywistość” (z

angielskiego Augmented Reality) oraz MR oznaczające „mieszaną rzeczywistość” (z angielskiego

Mixed Reality).

2.2. Historia oraz state-of-the-art

Pierwszym który opatentował pomysł wyświetlacza zakładanego na głowę była Thelma McCollum

w 1945 roku [1]. Jej koncepcją były okulary do oglądania telewizji stereoskopowej.

W 1960 Morton Heilig opatentował ulepszenie wyżej wymienionego urządzenia do oglądania

telewizji stereoskopowej z naciskiem na wygodę użytkowania dla jednej osoby [2]. Jego projekty

zdecydowanie bardziej przypominają dzisiejsze gogle VR. Dwa lata później stworzył symulator

Sensorama [3] - urządzenie podobne do znanych dzisiaj kin 5D. Użytkownik wkładał głowę w

specjalne stojące urządzenie, które, poza dźwiękiem i obrazem, oferowało także dużo innych

odczuć takich jak wiatr, zapachy, wibracje etc.

9

Ilustracja 2: Schemat działania Sensoramy.

W 1961 firma Philco zrealizowała pierwszy prototyp urządzeń które dziś znamy pod nazwą Head

Mounted Displays (HMD) - Headsight. Używając hełmu z zamontowanym monitorem CRT oraz

magnetycznego systemu śledzenia ruchu głowy, urządzenie reagowało na ruchy głowy użytkownika

i wyświetlało wideo pod odpowiednim kątem. Warto zauważyć, że Headsight nie tworzył wirtualnej

rzeczywistości - wyświetlanym obrazem było rzeczywiste nagrane wideo.

Kamieniem milowym a zarazem pierwszą udaną implementacją wirtualnej i rozszerzonej

rzeczywistości był projekt Ivana Sutherlanda nazwany “Miecz Damoklesa”. [4] [5] Nazwa wzięła

się stąd, że urządzenie było tak ciężkie, że podwieszono je u sufitu nad głową użytkownika - tak jak

mityczny Dionizos zawiesił miecz nad Damoklesem.

10

Ilustracja 3: “Miecz Damoklesa”.

System składał się z komputera i urządzenia wyświetlającego stereoskopowy obraz na soczewkach.

Umożliwiało to śledzenie pozycji oczu użytkownika oraz reagowanie na obroty głowy.

Wyświetlanym obrazem był sześcienny “pokój” wewnątrz którego znajdował się użytkownik.

Co ciekawe, urządzenie implementowało tak naprawdę rozszerzoną rzeczywistość - za obrazem

wyświetlanym na soczewkach, użytkownik mógł zobaczyć swoje otoczenie. Sutherland planował

wykorzystać swoje urządzenie do wyświetlania informacji na temat otaczających przedmiotów -

jest to zatem bezpośredni poprzednik rozwiązań XXI wieku takich jak Google Glass czy Microsoft

HoloLens. “Miecz Damoklesa” uważany jest za prekursora wszystkich urządzeń wirtualnej i

rozszerzonej rzeczywistości.

Pierwszy w pełni mobliny system wirtualnej/rozszerzonej rzeczywistości dokonał się za sprawą

Steve’a Manna i jego projektu EyeTap. Jeszcze jako student liceum, w 1981 udało mu się umieścić

komputer Apple II w plecaku i podpiąć do niego kamerę z małym wizjerem CRT. Obraz z kamery

był przekazywany do wizjera niemal w czasie rzeczywistym i był wzbogacany o dodatkowe

informacje kontekstowe. [6]

11

Od 1981 roku, Steve Mann przez przeszło 25 lat tworzył kolejne prototypy, coraz mniejsze, lżejsze

oraz bardziej wydajne obliczeniowo. Jego firma EyeTap działa aktywnie na rynku do dzisiaj i

produkuje innowacyjne rozwiązania z zakresu wirtualnej i rozszerzonej rzeczywistości. [6]

W latach 80-tych można zauważyć spowolnienie rozwoju rynku VR/AR. Był to czas, w którym

możliwości technologiczne sprzętu nie były w stanie spełnić oczekiwań wynalazców. Moc

obliczeniowa ówczesnych procesorów była zbyt mała a sprzęt był zbyt duży i ciężki.

Sytuacja diametralnie zmieniła się w drugiej dekadzie XXIw. - ze względu na bardzo dynamiczny

rozwój technologii i znaczną miniaturyzację jednostek obliczeniowych, coraz więcej firm decyduje

się na inwestycję oraz tworzenie nowych rozwiązań w tej branży. W 2011 roku osiemnastoletni

Palmer Luckey stworzył protototyp urządzenia nazwanego później Oculus Rift [7]. Luckey

zrezygnował ze skomplikowanych systemów soczewek, obecnych w drogich i komercyjnych

rozwiązaniach, mających za zadanie odpowiednio zniekształcać wyświetlany obraz aby stworzyć

złudzenie trójwymiarowości. Zamiast tego zastosował najprostsze soczewki powiększające, a

12

Ilustracja 4: Steve Mann z kolejnymi wersjami swojego projektu.

Ilustracja 5: Oculus Rift DK1 – przełomowy zestaw wirtualnej rzeczywistości.

wszystkie zniekształcenia zaimplementował programistycznie – na ekranie wyświetlał się już

odpowiednio przetworzony obraz [8]. Pomysł Luckeya zrewolucjonizował rynek wirtualnej

rzeczywistości. Trzy lata później, w 2014 roku amerykańska korporacja Facebook zauważając

potencjał stworzonej technologii, kupiła przedsiębiorstwo młodego wynalazcy za około 2 miliardy

dolarów [9].

W ostatnich latach powstaje również wiele prototypów urządzeń tworzących rozszerzoną

rzeczywistość – należy tu wspomnieć o pionierach jakimi w tej chwili są Google oraz Microsoft

[10].

Wizją twórców projektu Microsoft Hololens jest maksymalne uproszczenie interfejsu człowiek-

maszyna przy pomocy hologramów – wygenerowanych komputerowo obiektów nałożonych na

ekran okularów, przez które użytkownik widzi rzeczywisty świat. W założeniu ma dać to efekt

kojarzony dotychczas jedynie z filmami science-fiction. Obecnie projekt jest w fazie bardzo

szybkiego rozwoju i firmie udało się na konferencji w październiku 2015 roku pokazać działający

prototyp. [11]

Nieco inne podejście zaproponowało Google w swoim projekcie Glass – tutaj elementem

rozszerzającym rzeczywistość jest niewielki ekran wyświetlany użytkownikowi i przysłaniający

część widoku przez okulary. W wizji twórców, Glass ma zastąpić smartfona i implementować

wszystkie jego funkcje. W obecnym stanie produkt jest w fazie testowej i oferuje tylko kilka

kluczowych funkcji (takich jak m.in. nawigacja do określonego miejsca, robienie zdjęć czy też

13

Ilustracja 6: Klatka z prezentacji działającego prototypu Microsoft Hololens w październiku 2015.

wyszukiwanie fraz w Internecie) – obecnie rozwój projektu został wstrzymany na czas

nieokreślony. [12]

14

Ilustracja 7: W projekcie Glass, użytkownikowi wyświetlany jest niewielki obraz nieco z boku jegonormalnego pola widzenia.

3. Wykorzystywany sprzęt (A. Grzanka)

Ogromną zasługę w rozwoju wirtualnej rzeczywistości ma upowszechnienie wydajnych

smartfonów z wyświetlaczami o wysokich rozdzielczościach. Dzięki temu, urządzenie które

niespełna pięćdziesiąt lat wcześniej było tak ciężkie, że musiało zostać podwieszane na suficie

(Miecz Damoklesa Ivana Sutherlanda), można w tej chwili zastąpić przenośnym komputerem

schowanym w kieszeni. Ze względu na założenie dotyczące niskiego budżetu oraz łatwości i

dostępności rozwiązania, autorzy pracy zdecydowali się na skorzystanie ze standardu

opracowanego przez amerykańską korporację Google – Google Cardboard.

3.1. Standard Google Cardboard

Google Cardboard (ang. karton, tektura) to projekt stworzony przez Davida Coza oraz Damiena

Henry'ego, inżynierów Google w ramach Innovation Time Off - polityki pracodawcy nakazującej

pracownikom spędzać jeden dzień roboczy w tygodniu nad rozwojem swoich pomysłów [13]. Ich

propozycją było stworzenie niskobudżetowej platformy do prototypowania i rozwoju aplikacji

wirtualnej rzeczywistości. Zaprojektowali i udostępnili za darmo na stronie internetowej schemat,

na podstawie którego który każdy może zbudować swoje urządzenie [14].

Pomysł Coza i Henry'ego opiera się na wykorzystaniu smartfona jako głównej jednostki

obliczeniowej i wyświetlającej - dzięki czemu zastąpiona zostaje jedna z najdroższych części

komercyjnych urządzeń. Aby użytkownik był w stanie skupić wzrok na wyświetlanym obrazie,

stosuje się odpowiednie soczewki, które powiększają obraz oraz zmieniają ogniskową (ilustracja 8).

Smartfon z odpowiednio przygotowaną aplikacją (wyświetlającą stereoskopowo dwa obrazy)

montowany jest w odpowiedniej odległości od soczewek. Aplikacje korzystają też z wbudowanego

w smartfona akcelerometru, dzięki czemu na bieżąco zmienia się pozycja kamery w scenie.

Google udostępnia SDK (Software Development Kit – zestaw narzędzi dla programistów

wspomagający pracę przy tworzeniu aplikacji korzystających z danego urządzenia czy biblioteki)

dla Google Cardboard m.in. w formie wtyczki do platformy Unity. Jest to znaczne ułatwienie dla

programistów – otrzymują oni gotowy szkielet projektu ze skonfigurowanymi kamerami oraz

widokami przystosowanymi do gogli Cardboard.

15

Elementy niezbędne do zbudowania gogli Google Cardboard przedstawione są na ilustracji.

Głównymi składnikami urządzania są odpowiednio wycięty kawałek kartonu (1), soczewki o

długości ogniskowej 45mm (2) oraz para magnesów neodymowych (3). Ponadto, aby komfortowo

można było korzystać z rozwiązania, dodane zostały rzepy (4) do łatwego składania i rozkładania

oraz gumka (5) służąca do zapewnienia urządzeniu stabilności. Opcjonalnie, Coz i Henry proponują

dodanie specjalnie przygotowanego „tagu NFC” (6) w celu przyspieszenia procesu konfiguracji.

NFC (Near Field Communication, ang. komunikacja bliskiego zasięgu) to krótkozasięgowy

radiowy standard komunikacji. Tagiem NFC nazywamy małe urządzenie działające zgodnie ze

standardem NFC w trybie pasywnym, zasilane mocą pola elektromagnetycznego wytwarzanego

przez urządzenie inicjujące (w tym przypadku smartfon). Po wejściu tagu NFC w pole

elektromagnetyczne smartfona, następuje połączenie, a następnie zapisane wcześniej dane (w tym

przypadku dotyczące m.in. rozstawu soczewek) są przesyłane do smartfona.

16

Ilustracja 8: Schemat działania soczewek w goglach standardu Google Cardboard

Ekran smartfona

Z soczewkami (gogle)

Lewy obraz Prawy obraz

rozstaw źrenic

Lewy obraz Prawy obraz

L P

L Prozstaw źrenic

Ekran smartfona

Bez soczewek

Ilustracja 9: Rozłożone gogle Google Cardboard.

17

Ważnym elementem zestawu są magnesy neodymowe (3). Inżynierowie Google rozwiązali dzięki

nim problem interakcji użytkownika ze smartfonem. Normalnie odbywa się ona przy pomocy

ekranu dotykowego, jednak gdy urządzenie jest schowane w okularach użytkownik nie ma

możliwości dotknąć ekranu. Zamiast tego, może on poruszyć delikatnie magnesem wywołując tym

samym zmianę pola magnetycznego w otoczeniu smartfona. Większość obecnych na rynku

smartfonów wyposażonych jest w magnetometr który jest w stanie wykryć tego typu zmianę a

odpowiednia aplikacja może zareagować na to zdarzenie np. podświetleniem aktualnie

wyświetlanego obrazu. W efekcie uzyskujemy efekt podobny do pojedynczego „kliknięcia”.

3.2. Sprzęt wykorzystywany w pracy

Z uwagi na obawy o wytrzymałość sprzętu wykonanego z kartonu (jedną z części projektu było

przetestowanie rozwiązania na możliwie dużej próbie, o czym mowa dokładniej w rozdziale 6),

autorzy zdecydowali się wykorzystać rozwiązanie bardziej wytrzymałe, jednak nadal zgodne ze

standardem Google Cardboard. W wyniku nawiązanej współpracy z jednym z polskich

producentów okularów VR, w pracy wykorzystano gogle Weebo3D. Jest to stosunkowo nowy

produkt na rynku (pierwsze modele pojawiły się w połowie 2015 roku). Za specyfikacją

producenta, dane techniczne okularów [15]:

• Waga: 165g

• Średnica soczedokwek: 37mm

• Materiał wykonania: sklejka

• Kompatybilne ekrany smartfonów: 4,3” - 6,5”

18

• Gąbki poprawiające komfort (profilowane do twarzy oraz chroniące telefon)

Smartfonami wykorzystywanymi w badaniach były OnePlus One, Samsung Galaxy S4 oraz

Samsung Galaxy S5. Porównanie znaczących dla pracy cech znajduje się w tabeli poniżej.

S. Galaxy S4 S. Galaxy S5 OnePlus One

Waga 130 g 145 g 162 g

Pamięć RAM 2 GB 2 GB 3 GB

Pojemność baterii 2600 mAh 2800 mAh 3100 mAh

Częstotliwośćtaktowania procesora

1,6 GHz (rdzeniewydajne)

2,5 GHz 2,5 GHz

Liczba rdzeniprocesora

4 (rdzenie wydajne) 4 4

Przekątna wyświetlacza 5” 5,1” 5,5”

Rozdzielczośćwyświetlacza

1920x1080 pikseli 1920x1080 pikseli 1920x1080 pikseli

Kamera 13 MPx 16 MPx 13 MPx

19

Ilustracja 10: Gogle Weebo3D zgodne ze standardem Google Cardboard.

Biorąc pod uwagę założenie o wykorzystywaniu urządzeń ze średniej półki, ostatecznie badania

zostały przeprowadzone na smartfonach Samsung Galaxy S4 oraz Samsung Galaxy S5 .

Smartfon marki OnePlus One był wykorzystywany jedynie w czasie testowania oraz rozwoju

aplikacji, ponieważ odbiega on od urządzeń marki Samsung m.in. dostępną ilością pamięci RAM

oraz znacząco większym rozmiarem wyświetlacza.

20

4. Implementacja wirtualnej rzeczywistości (A. Grzanka)

W celu spójności z pozostałymi aplikacjami, autorzy zaproponowali dość prostą implementację

wirtualnej rzeczywistości. Wygenerowany został pokój z czterema półkami z książkami. Zadaniem

użytkownika, który po założeniu okularów ma wrażenie jakby znalazł się w środku pokoju, było

odnajdywać kolejne książki których tytuły pojawiały się w widocznym dla niego miejscu.

Szczegóły koncepcji przeprowadzonych badań opisano w rozdziale szóstym.

4.1. Platforma Unity3D

Unity3D to jedna z najpopularniejszych platform do tworzenia dwu- i trójwymiarowych gier

komputerowych. Z silnika Unity korzystają tak znane tytuły jak Pillars of Eternity, Cities Skylines

czy Need for Speed. Główną jego zaletą jest elastyczność – odpowiednio skonfigurowany projekt

można wyeksportować na ponad 10 różnych platform, w tym urządzenia mobilne (Android, iOS,

Windows Phone, Tizen), stacjonarne (Windows, Mac), konsole (PlayStation 4, Xbox One, Wii) a

nawet przeglądarki (wspierany jest WebGL). [21] Unity posiada również wsparcie dla urządzeń

wirtualnej rzeczywistości takich jak Oculus Rift, Microsoft Hololens czy Samsung Gear.

4.2. Struktura projektu w Unity3D

• Pojedyncza plansza/pokój nazywana jest sceną (ang. scene). Jedna aplikacja może zawierać

wiele scen, jednak przełączenie się między nimi wymaga ponownego wyrenderowania

wirtualnego środowiska.

• Każdy element który występuje w scenie reprezentowany jest przez obiekt gry (ang. game

object). Każdy obiekt gry zawiera elementy zwane komponentami (ang. components) które

definiują np. jego pozycję i przekształcenie (komponent typu Transform), szczegóły jego

wyświetlania takie jak tekstura (komponent typu Renderer), interakcję z innymi obiektami

gry (komponent typu Collider) czy też skrypty opisujący jego zachowania (komponent typu

Script). To właśnie komponenty stanowią funkcjonalną część aplikacji tworzonych w

Unity3D.

• Każdy obiekt gry jest równocześnie kontenerem i może zawierać w sobie zagnieżdżone

kolejne obiekty gry.

• W celu łatwiejszego wyszukiwania obiektów gry w projekcie, można przypisywać im

krótkie ciągi znaków zwane też tagami.

21

• Aby łatwiej powielać, zarządzać i dzielić się gotowymi obiektami gry wraz z ich

komponentami, istnieje możliwość wyeksportowania ich do obiektu typu prefab (skrócona

wersja ang. prefabricate). Tego typu paczka zawiera wszystkie informacje na temat danego

obiektu gry. Większość obiektów gry udostępnianych w ramach Google Cardboard SDK

istnieje jako obiekty typu prefab.

• Szczególnym typem obiektu gry jest kamera (ang. camera). Pozwala ona zdecydować jaka

część trójwymiarowej sceny ma być w danej chwili wyświetlana na ekranie użytkownika.

Pozycja kamery może się zmieniać w trakcie działania aplikacji co może odpowiadać np.

poruszaniu się gracza w przestrzeni sceny lub obracaniu przez niego głową. Scena może też

zawierać więcej niż jedną kamerę naraz.

• Częścią aplikacji odpowiadającą za dynamikę oraz zachowania obiektów gry są skrypty.

Unity3D pozwala uruchamiać skrypty napisane w językach C#, UnityScript (które jest

składniowo podobne do JavaScriptu) oraz Boo. Autorzy pracy zdecydowali się tworzyć

skrypty w języku C# z uwagi na dwie istotne kwestie:

◦ powszechność - zgodnie z danymi z 2014 roku, ponad 80% programistów

korzystających z Unity3D pisze swoje skrypty w C# [20]

◦ kompatybilność - zarówno Google Cardboard SDK, jak i wykorzystywane w dalszej

części pracy Vuforia SDK, zawierają skrypty napisane w C#

Skrypty dołączane są do obiektów gry przy użyciu wspomnianych wcześniej komponentów

typu Script.

4.3. Implementacja wykorzystywana w badaniach

Głównymi zadaniami były: stworzenie projektu i wirtualnej sceny w Unity 3D, utworzenie

odpowiednich modeli oraz ich oskryptowanie, integracja sceny z Cardboard SDK oraz odpowiednia

konfiguracja kamer. Kolejne etapy pracy nad aplikacją dla porządku zostały opisane w

odpowiednich podpunktach.

1. Stworzenie sceny oraz modelu pokoju

Ściany oraz podłogę stworzono z obiektów gry typu Cube. Korzystając z komponentów

typu Renderer nałożono na nie odpowiednio przygotowane tekstury. Dodano również źródło

światła przy pomocy obiektu gry z komponentem Light.

22

Ilustracja 11: Model pustego pokoju wraz ze źródłem światła.

2. Stworzenie modeli półek na książki oraz samych książek

Półkę na książki, jak i same książki, stworzono z obiektów gry typu Cube. Na półkę

nałożono odpowiednie tekstury a następnie, wraz z modelami książek, powielono

czterokrotnie i ustawiono przy ścianach pokoju. Następnie na wszystkie sześćdziesiąt cztery

książki nałożono odpowiednie tekstury. Główne źródło okładek książek stanowiła lista

bestsellerów jednej z księgarni internetowych. Szesnaście z nich będzie brało udział w

losowaniu – przypisano im specjalne tagi „realbook”.

Ilustracja 12: Wykonany przez autorów model półki z książkami

23

3. Integracja z Cardboard SDK – dodanie i konfiguracja kamery

Następnym krokiem było dodanie kamery do utworzonej sceny. Skorzystano z obiektu typu

prefab CardboardMain, udostępnianego bezpłatnie jako część Google Cardboard SDK.

Obiekt ten zawiera m.in. wstępnie skonfigurowane dwie kamery (odpowiadające lewemu i

prawemu oku użytkownika) oraz kursor odpowiadający punktowi na który użytkownik

patrzy – kursor zawsze utrzymuje się na środku każdej z kamer. Pozwala to programistom

relatywnie łatwo wykryć w swoich skryptach kiedy użytkownik patrzy na dany obiekt gry.

Ustawienia tych kamer zawierają również skrypty obsługujące dane z akcelerometru

smartfona, dzięki czemu widok zmienia się wraz z obrotem głowy.

Po kilku testach autorzy zdecydowali oddalić od siebie lewą i prawą kamerę o 0.06

jednostek sceny (są to względne jednostki przestrzeni używane do mierzenia odległości czy

też rozmiaru obiektów gry) – dało to najlepsze wyniki i widok wydawał się najbardziej

naturalny.

Ilustracja 13: Widok z dwóch kamer po integracji z Cardboard SDK

4. Skrypt losujący książki oraz obsługujący wskazanie na książkę

Badanie zakładało każdorazową zmianę książek, które użytkownik miał znaleźć. Stworzono

skrypt BookManager.cs i, przy pomocy komponentu Script, dodano go do obiektu gry

CardboardMain. Skrypt wyszukuje wszystkie obiekty gry oznaczone tagiem realbook, losuje

24

jeden z nich a następnie przypisuje mu odpowiednie funkcje wywoływane w przypadku

zdarzeń (ang. event). Kiedy znacznik środka ekranu wejdzie w zasięg wylosowanego

obiektu gry, wywoływane są funkcje powiązane ze zdarzeniem PointerEnter – podświetli

się on na żółto. Kiedy natomiast znacznik środka ekranu wyjdzie z zasięgu wylosowanego

obiektu gry (zdarzenie PointerExit), powróci on do swojej oryginalnej tekstury.

Ilustracja 14: Wylosowana książka (trzecia od lewej w dolnym rzędzie) zmienia kolor, gdy wskaźnik wchodzi w interakcję z nią.

5. Skrypt wywoływany po wykryciu poruszenia magnesem

25

W podobny sposób zaimplementowano wykrycie poruszenia magnesem (zmianę pola

elektromagnetycznego,). Cardboard SDK interpretuje te dane samoczynnie i w przypadku

wykrycia wystarczająco dużego odchylenia, wywołuje funkcje powiązane ze zdarzeniem

PointerClick. W przypadku tej implementacji, autorzy zdecydowali się na usunięcie

znalezionej książki ze sceny. Z tym samym zdarzeniem powiązano również wywołanie

skryptu losującego nową książkę – tak, aby po znalezieniu jednej użytkownik mógł od razu

przystąpić do szukania kolejnej.

Ilustracja 15: Po wejściu książki w zasięg znacznika wskazującego i poruszenia magnesem, obiekt gry znika ze sceny i losowana jest kolejna książka.

6. Interakcja z użytkownikiem – wyświetlanie tytułu szukanej książki

26

Aby ułatwić przeprowadzenie badania, oraz zachować spójność z badaniami

przeprowadzanymi w rzeczywistości oraz rozszerzonej rzeczywistości, autorzy zdecydowali

się umieścić na suficie wirtualnego pokoju tytuł poszukiwanej książki. Użytkownik, nosząc

gogle z włączoną aplikacją, podnosząc głowę zobaczy tytuł książki, którą musi znaleźć.

Osiągnięto to dodając kolejną funkcjonalność do skryptu, opisywanego w podpunkcie 4,

losującego książki.

Ilustracja 16: Tytuł poszukiwanej książki wyświetla się nad głową użytkownika.

27

5. Implementacja rozszerzonej rzeczywistości (A. Grzanka)

Rozszerzona rzeczywistość wymaga od twórców aplikacji nieco innego podejścia przy

implementacji. Należy pamiętać, że nie ma się do czynienia z całkowicie wirtualnym środowiskiem

a z „rzeczywistością mieszaną”. Wyzwaniem jest synchronizacja kamery oraz renderowanej sceny

w taki sposób, aby odpowiednie przesunięcie kamery spowodował analogiczny ruch sceny w

dokładnie to samo miejsce lub obrót o dokładnie taki sam kąt. Autorom udało osiągnąć się ten cel

korzystając z platformy Unity3D oraz biblioteki Vuforia (w postaci wtyczki do ww. platformy). Aby

rozszerzona rzeczywistość współpracowała z okularami Google Cardboard dokonano również

integracji z opisywanym wcześniej Cardboard SDK.

5.1. Biblioteka Vuforia

Vuforia to produkt rozwijany przez amerykańskie przedsiębiorstwo Qualcomm. Jest to zestaw

narzędzi programistycznych (SDK) do pracy z rozszerzoną rzeczywistością, pozwalający na

wyszukiwanie zadanych elementów w obrazie z kamery i renderowanie w przestrzeni obiektów 3D.

Vuforia nie jest projektem rozpowszechnianym na licencji open source w związku z czym kluczowe

części algorytmu nie zostały opublikowane i są własnością intelektualną przedsiębiorstwa

Qualcomm. Skrótowa zasada działania systemu jest następująca:

1. w każdej klatce obrazu pochodzącego z kamery wyszukiwane są punkty charakterystyczne

(tzw. feature points)

2. rozkład ww. punktów kluczowych jest porównywany z przetworzonymi wcześniej danymi

zadanych obrazów, przechowywanymi w bazie danych

3. w przypadku stwierdzenia bliskiego podobieństwa obrazu z kamery oraz obrazu w bazie

danych, na wyświetlany obraz nakładany jest zdefiniowany wcześniej obiekt 3D

Kluczową zaletą biblioteki Vuforia jest to, że proces porównywania (punkt 2) daje dobre wyniki bez

względu na przekształcenia obiektu źródłowego (tj. obrót, zniekształcenie przestrzenne

spowodowane innym kątem widzenia). Wyrenderowany obiekt obraca się oraz zmienia swoją

pozycję wraz z rzeczywistym obiektem. Innymi słowy – raz wyszukany obiekt jest śledzony.

28

Alternatywą dla wykorzystanej przez nas biblioteki jest m.in. biblioteka Metaio – oferuje podobne

możliwości, jednak ma mniejsze wsparcie społeczności i mniej materiałów do nauki.

Vuforia SDK udostępniane jest w formie wtyczki do platformy Unity.

5.2. Kluczowe elementy biblioteki Vuforia

Biblioteka Vuforia jest w stanie wykrywać obrazy, które wcześniej zostały przetworzone z

wykorzystaniem specjalnego narzędzia udostępnionego w formie usługi na stronie internetowej

producenta. Narzędzie to, nazwane przez twórców Menedżerem Obiektów (ang. Target Manager),

wyszukuje w każdym obrazie punkty charakterystyczne (tzw. feature points) i na podstawie ilości

oraz rozkładu ww. punktów ocenia obraz w skali od 0 do 5. Skala ta informuje użytkownika jak

dobrze żądany obraz nadaje się do działania z biblioteką i jak dobrze będzie wykrywany. Za

podręcznikiem programisty, udostępnianym przez twórców: „ocena 0 informuje, że obraz nie

zostanie nigdy wykryty przez system rozszerzonej rzeczywistości natomiast ocena 5 informuje, że

obraz z łatwością zostanie wykryty oraz śledzony przez system” [16]. Punktem charakterystycznym

jest każdy ostry, szpiczasty element obecny na obrazie.

29

Ilustracja 17: Zrzuty ekranu z przykładowej aplikacji udostępnionej przez producenta. Odnalezionyobraz jest śledzony a wyrenderowany obiekt pozostaje na nim niezależnie od kąta i pozycji.

Ilustracja 18: Kwadrat ma cztery punkty charakterystyczne, po jednym na każdy kąt. Koło nie ma żadnych punktów charakterystycznych ponieważ nie ma żadnych ostrych krawędzi. Bardziej skomplikowane obiekty jak np. gwiazda mają dużo więcej punktów charakterystycznych

Menedżer Obiektów pozwala na wyeksportowanie przetworzonych obrazów do projektu w

środowisku Unity3D za pomocą obiektu DataSet. Jest to kontener na przetworzone przez

Menedżera Obiektów obrazy, które z kolei reprezentowane są przez obiekty typu ImageTarget.

Warto zauważyć, że obiekty typu DataSet mogą być, przy użyciu odpowiednich skryptów,

aktywowane i dezaktywowane w trakcie działania aplikacji. Pozwala to na zmianę aktualnie

śledzonego obiektu bez konieczności wyłączania i włączania aplikacji.

Obiektem gry który spaja działanie całej biblioteki Vuforia jest ARCamera, dostępne w formie

obiektu typu prefab. Jest to specjalna instancja obiektu gry z komponentem Camera, która dzięki

dodatkowym skryptom pozwala m.in. wyświetlać w scenie obraz z kamery smartfona.

Najważniejsze ustawienia obiektu gry ARCamera to:

• maksymalna ilość obiektów śledzonych naraz

• tryb pracy kamery – Vuforia może pracować w trybie zoptymalizowanym względem jakości

obrazu lub szybkości działania

• zmiana kamery – biblioteka może korzystać z tylnej lub przedniej kamery smartfona (jeśli

posiada on takową)

• alternatywne obiekty gry Camera – Vuforia pozwala na wyświetlanie widoku na innych

obiektach gry typu Camera niż te dostarczone z Vuforia SDK; opcja ta pozwala na

integrację np. z Google Cardboard SDK

• wsparcie dla okularów wirtualnej rzeczywistości – biblioteka ma częściowe wsparcie dla

Samsung Gear oraz Google Cardboard, jednak integracja z Cardboard SDK wymaga

30

korekcji również innych ustawień.

• zarządzanie obiektami DataSet – skrypt pozwala użytkownikowi wybrać które obiekty mają

być załadowane do pamięci aplikacji a także które mają być aktywowane/dezaktywowane.

5.3. Implementacja wykorzystywana w badaniach

Dla porządku, kolejne etapy implementacji opisano w odpowiednich podpunktach.

1. Przetworzenie obrazów za pomocą Menedżera Obiektów

Autorzy pracy, w celu spójności z pozostałymi częściami badania, wybrali te same

szesnaście okładek i przetworzyli je przy użyciu Menedżera Obiektów. Upewniono się, że

każda z okładek została oceniona na przynajmniej 3 w skali opisanej w punkcie 5.2.

Utworzone szesnaście obiektów typu DataSet zaimportowano do nowo utworzonego

projektu Unity3D.

Ilustracja 19: Przykładowa okładka książki wraz z zaznaczonymi punktami charakterystycznymi.

2. Integracja z Vuforia SDK – dodanie obiektów gry ImageTarget oraz ARCamera

Korzystając z obiektów typu prefab dostępnych w ramach Vuforia SDK, do sceny dodano

31

obiekty gry ARCamera oraz ImageTarget. W ustawieniach obiektu ARCamera załadowano

oraz aktywowano zaimportowany wcześniej obiekt DataSet. W ustawieniach obiektu

ImageTarget wybrano odpowiednią teksturę. Dodano też obiekt gry typu Cube i

zagnieżdżono go w obiekcie ImageTarget – biblioteka Vuforia automatycznie wyświetli tak

skonfigurowany element w momencie gdy obraz wejdzie w pole widzenia.

Ilustracja 20: Obiekt gry typu ImageTarget umieszczony w scenie.

3. Test implementacji

Autorzy postanowili sprawdzić działanie utworzonego projektu testując go na jednej

przykładowej książce. Wygenerowano odpowiednią aplikację zgodną z systemem Android.

Warto zauważyć, że w tym momencie kamery nie zostały jeszcze zintegrowane z Cardboard

SDK – w scenie obecna jest zatem jedna, domyślna kamera a na ekranie smartfona pokazuje

się jeden spójny obraz.

4. Powielenie struktury utworzonych obiektów

Zgodnie z koncepcją przeprowadzonego badania, aplikacja ma za zadanie wykrywać oraz

śledzić nie jedną, a szesnaście książek. Skopiowano zatem obiekty ImageTarget oraz

odpowiadające im obiekty gry Cube i ułożono je w scenie w formacie siatki 4x4. Każdemu

obiektowi ImageTarget przypisano inną teksturę, odpowiadającą wcześniej

zaimportowanym obiektom typu DataSet wygenerowanym za pomocą Menedżera

Obiektów. Każdy z obiektów DataSet aktywowano, co pozwala aplikacji wykryć każdą z

szesnastu książek jeśli tylko znajdzie się ona w zasięgu widzenia kamery smartfona. Z

uwagi na specyfikę badania, w ustawieniach obiektu gry ARCamera ustawiono liczbę

maksymalnie śledzonych obiektów na 1. Dzięki temu użytkownik nie jest w stanie zobaczyć

dwóch książek podświetlonych naraz.

32

Ilustracja 21: Siatka obiektów typu ImageTarget zaimportowanych do sceny.

5. Integracja Google Cardboard SDK z Vuforia SDK

Następnym krokiem było przystosowanie utworzonego projektu do działania z Google

Cardboard SDK. Podobnie jak w przypadku implementacji wirtualnej rzeczywistości

skorzystano z obiektu prefab CardboardMain, zawierającego wstępnie skonfigurowane

kamery. Korzystając z opcji Bind Alternate Camera udostępnianych w ramach obiektu

ARCamera, dokonano zastąpienia domyślnych kamer biblioteki Vuforia nowo

utworzonymi. Skorygowano ustawienia kamer w taki sposób, aby w ich polu widzenia

znajdowała się cała utworzona w poprzednim punkcie siatka obiektów ImageTarget.

33

6. Skrypt wywoływany po wykryciu poruszenia magnesem

Podobnie jak przy implementacji wirtualnej rzeczywistości, stworzono odpowiedni skrypt

który pozwala użytkownikowi usunąć wykrytą książkę z listy wyszukiwanych książek.

Dzięki temu badany po znalezieniu książki (które sygnalizowane jest przez niego

poruszeniem magnesem) może przystąpić od razu do szukania kolejnej. Można to zrobić na

kilka sposobów:

• deaktywować odpowiedni obiekt typu DataSet w ustawieniach ARCamera

• usunąć odpowiedni obiekt ImageTarget ze sceny

• wyłączyć skrypt ImageTargetBehaviour wyświetlający odpowiedni obiekt gry typu

Cube nad znalezionym obiektem

Autorzy zdecydowali się zastosować ostatnie podejście, z uwagi na niski stopień

skomplikowania tak napisanego skryptu oraz jego elastyczność – wyłączony skrypt można

w przyszłości w równie łatwy sposób włączyć.

34

Ilustracja 22: Projekt w widoku sceny - białymi liniami oznaczono kąty oraz pole widzenia kamer z Cardboard SDK. W prawym dolnym rogu podgląd widoku z kamery.

6. Metodologia badań user experience (A. Niedziałkowski)

6.1. Definicja

W celu zbadania reakcji i odczuć użytkowników na temat opisanych wcześniej aplikacji, autorzy

zdecydowali się przeprowadzić odpowiednie badania user experience. Zgodnie z definicją termin

user experience „obejmuje wszystkie aspekty interakcji użytkownika z firmą, jej usługami i

produktami. Pierwszym z wymogów doskonałego user experience jest spełnienie potrzeb

konsumenta bez zbędnych przeszkód i kłopotów. Następnym jest prostota i elegancja produktów,

których posiadanie jest przyjemnością, przyjemnością użytkowania. Prawdziwe user experience

przekracza dawanie konsumentom tego, o czym mówią, że tego chcą, lub tylko produktu z listą

niezbędnych cech. Aby osiągnąć wysokiej jakości user experience firmowej oferty konieczne jest

płynne przenikanie się wielu dyscyplin, takich jak technologia, marketing, projektowanie graficzne i

użytkowe, czy projektowanie interfejsów”.[22].

Autorzy zdecydowali się dodać również pytania dotyczące sfery używalności zaproponowanego

rozwiązania, w związku z tym wydaje się zasadne by przytoczyć również definicję użyteczności

(ang. usability):

„Użyteczność to miara wydajności, efektywności i satysfakcji z jaką dany produkt może być

używany przez określonych użytkowników dla osiągnięcia określonych celów w określonym

kontekście użycia.”[23]

6.2. Cel badań

Celem badań było zebranie opinii osób badanych na temat rozwiązań mobilnej rozszerzonej

rzeczywistości oraz mobilnej wirtualnej rzeczywistości, które zaproponowali autorzy tej pracy.

6.3. Badana próbka

Badania przeprowadzone zostały w księgarnio-kawiarni przy ulicy Czarnowiejskiej. Zdecydowano

się na takie miejsce z powodu kilku czynników:

• dostępność (łatwiejszy dojazd dla uczestników), potencjalnie zwiększającej ilość osób

zainteresowanych

35

• odpowiednie wyposażenie (w księgarni znajdowała się odpowiednia półka z książkami, tj.

zawierająca powyżej 40 książek a jednocześnie łatwo dostępna)

• zróżnicowanie próbki badanych (autorzy pracy przyjęli założenie, że wybierając miejsce

niezwiązane z żadnym konkretnym wydziałem AGH, zlokalizowanej przy głównej ulicy

uzyskają grupę badanych która będzie możliwie niejednorodna)

Należy zaznaczyć, że ze względu na to, że miejsce przeprowadzenia badania znajduje się blisko

Akademii Górniczo-Hutniczej to nieuniknionym jest, że większość przebadanych będą stanowić

studenci studiów technicznych. Aby upewnić się, że liczba uczestników będzie wystarczająca

stworzono wydarzenie na portalu Facebook zapraszające do udziału w badaniu. W związku z tym

duża część badanych była znana osobom przeprowadzającym eksperyment, co oczywiście mogło

mieć wpływ na wydawane opinie. Poniżej zamieszczono wyniki części statystycznej ankiety

przeprowadzonej po badaniu. Przeanalizowanie tych danych pozwoliło na określenie profilu

badanych a także pomogło analizie odpowiedzi bezpośrednio związanych z samym badaniem.

36

Ilustracja 23: Diagram pokazujący rozkład płci wśród badanych

3543

Mężczyźni

Kobiety

37

Ilustracja 24: Diagram pokazujący rozkład rodzaju wykształcenia wśród badanych

88,40%

11,50%

Studia techniczne

Studia nIetechniczne

Ilustracja 25: Diagram pokazujący rozkład wieku wśród badanych (czerwona linia pokazuje średni wiek badanych)

0

5

10

15

20

25

30

35

Identyfikator badanego

Wie

k

Z powyższych wykresów można wyciągnąć pewne wnioski na temat badanej grupy:

• Próbka jest w stosunkowo zrównoważona jeśli chodzi o płeć, tym co może zaskakiwać, to,

że pomimo że AGH ma status uczelni technicznej, kojarzonej z większą ilością mężczyzn,

stanowią oni mniejszość próbki.

• Prawie 90% badanych to studenci studiów technicznych lub też ukończyli kierunki

techniczne.

• Próbka jest jednorodna pod względem wiekowym. Średnia wieku wyniosła 21,3 lat a

odchylenie standardowe 2,3 lat. Oznacza to, że większość uczestników badania to ludzie

nadal studiujący, w przedziale wiekowym 19-24.

6.4. Przebieg badań

Przebieg badań był następujący:

1. Badany był informowany o tym, że przejdzie dwa testy, czas wykonania tych zadań będzie

mierzony (ze względu na duże błędy w pomiarze czasu autorzy postanowili nie włączać ich

do danych użytych w tej pracy) a następnie otrzyma ankietę do wypełnienia.

2. Badany przechodził pierwsze badanie, zadanie dotyczące rozszerzonej rzeczywistości.

Wykorzystana aplikacja została opisana w rozdziale 5. Osoba badająca informowała

uczestnika o tytule książki, a badany wyszukiwał jej na półce. W momencie w którym

książka została odnaleziona podawany był następny tytuł ksiązki. Po odnalezieniu trzech

obiektów badanie było zakończone.

3. Kolejnym elementem testów było skorzystanie z aplikacji wirtualnej rzeczywistości. Sposób

jej działania został opisany dokładnie w rozdziale 4. Tym razem jednak tytuł nie był

przekazywany przez osobę badającą, a poprzez samą aplikację (tytuł był wyświetlany na na

suficie wirtualnego pokoju).

4. Ostatnim krokiem badania było przeprowadzenie ankiety. Aby uniknąć wpływania na osoby

badane ankieta została wydrukowana i każdy uczestnik badania wypełniał ją samodzielnie.

38

5.

Poniżej przedstawiono pytania zadane uczestnikom badania:

1. Jakie są Twoje odczucia odnośnie badania Wirtualnej Rzeczywistości (wirtualny pokój z

czterema półkami z książkami)? Jakie widzisz wady i zalety tego rozwiązania?

2. Jakie są Twoje odczucia odnośnie badania Rozszerzonej Rzeczywistości (podświetlane

rzeczywiste książki)? Jakie widzisz wady i zalety i tego rozwiązania?

3. Czy widzisz zastosowanie tych technologii, jeśli tak to gdzie?

4. Jak określiłbyś/określiłabyś komfort korzystania z tych rozwiązań ?

5. Jakich poprawek, Twoim zdaniem, powinno się dokonać, aby rozwiązanie było lepsze?

Należy zaznaczyć, że pomiar czasowy i zadanie do wykonania miały jedynie wymiar

psychologiczny, aby użytkownicy mogli skupić się na wykonywaniu pewnej czynności i w ten

sposób w praktyce sprawdzić zaproponowane przez autorów rozwiązanie.

Ze względu na brak możliwości odseparowania od siebie uczestników, badany przed przejściem

testu był świadkiem badania poprzednika. Autorzy nie uważają jednak aby miało to negatywny

wpływ (zaburzający) na wynik eksperymentu. Wynika to z tego, że pytania były otwarte, badani

wypełniali ankiety samodzielnie, również przebieg badania nie był oceniany żadnymi metrykami.

39

7. Wyniki badań (A. Niedziałkowski)

Analizę badań podzielono na mniejsze części dotyczące bezpośrednio zadanych pytań. Autorzy

zdecydowali się na omówienie poszczególnych pytań wraz z prezentacją graficzną w formie mapy

słów. Taki format, o ile jest mniej formalny i nie dostarczający ścisłych danych statystycznych, daje

lepszy ogólny pogląd na sytuację. Pozwala przedstawić dużą ilość danych w zwięzłej formie.

Alternatywą mogło by być stworzenie wykresów słupkowych, zawierających dane na temat

częstości występowania słów, przy czym tego typu wizualizacja była by trudna w odbiorze (ilość

unikalnych wyrazów użytych jest bardzo duża). Inną mozliwością była by prosta kwantyzacja, np.

podział na wypowiedzi pozytywne i negatywne. W ten sposób uzyskanoby dużą przejrzystość, lecz

rówież utraciłoby się wiele informacji oraz kontekst opinii. Wobec tego, decyzją autorów było

wstępne przetworzenie wypowiedzi, ujednolicenie słownictwa a także wyeliminowania wyrazów

nie istotnych, takich jak spójniki czy przyimki. Następnie z przetworzonych danych zbudowano

osobne mapy słów dla każdego pytania. Zostały one przedstawione poniżej. Zbudowano je w taki

sposób by wielkość słowa była proporcjonalna do częstości jego występowania.

7.1. Pytanie pierwsze

Jakie są Twoje odczucia odnośnie badania Wirtualnej Rzeczywistości (wirtualny pokój z czterema

półkami z książkami)? Jakie widzisz wady i zalety tego rozwiązania?

40

Jak wynikało z odpowiedzi badanych cechami najbardziej istotnymi były ostrość, jakość

oraz płynność. Trzeba niestety stwierdzić, że raczej w negatywnym kontekście , były one określane

jako niewystarczające. W szczególności w przypadku szybkich ruchów głową lub na krawędziach

pola widzenia. Przyczyn należy szukać w kilku sferach. Przede wszystkim w jakości obrazu

wyświetlanego na ekranie telefonu. Pomimo, że ekrany telefonów wykorzystanych w badaniu

działają w wysokiej rozdzielczości (wg firmy Apple na tyle dużej, że zwiększenie ilości pikseli było

by już dla człowieka nie zauważnalne) to możliwym jest, że na bardzo krótkich dystansach (oko

znajduje się w odległości około 10cm od ekranu) rozdzielczość 1080p jest niewystraczająca.

Kolejną przyczyną, może być fakt, że podczas użytkowania sprzętu ekranik ze względu na bliskość

ludzkiego ciała zaparowuje, co również obniża jakość obrazu odbieraną przez użytkownika.

Następnym elementem może być jakość przedstawionej grafiki. Tutaj występują dwa aspekty:

jakość platformy Unity oraz jakość modeli budowanych przez Autorów pracy.

Często zgłaszanymi wątpliwościami co do rozwiązania była obawa o możliwość

uszkodzenia ciała lub sprzętu o fizyczne obiekty (np. ścianę lub drzwi) nie widzianych przez

41

Ilustracja 26: Mapa słów występujących w odpowiedziach na pytanie pierwsze. Wielkość słowa proporcjonalna do częstości jego występowania

uczestnika. Jest to słuszna obawa, lecz nie do wyeliminowania w kontekście tego, że prezentowana

aplikacja jest aplikacją wirtualnej rzeczywistości i z definicji nie może zawierać elementów świata

rzeczywistego. Kompromisem było by upewnienie się, że podczas korzystania z aplikacji wirtualnej

rzeczywistości użytkownik jest nieruchomy, np. w pozycji siedzącej. Inna opcja zakłada

zbudowanie systemu ostrzegawczego np. w formie alarmu dzwiękowego.

Uwagami występującymi najczęściej były te dotyczące samopoczucia lub też stanu zdrowia

badanych. Odczucia takie jak zawroty głowy, ból głowy czy też zmęczenie lub ból oczu były dość

często zgłaszane. Może to być głownym elementem ograniczającym możliwości implementacyjne

mobilnych aplikacji wirtualnej/rozszerzonej rzeczywistości.

7.2. Pytanie drugie

Jakie są Twoje odczucia odnośnie badania Rozszerzonej Rzeczywistości (podświetlane rzeczywiste

książki)? Jakie widzisz wady i zalety i tego rozwiązania?

W tym pytaniu najczęściej zgłaszaną wadą rozwiązania była niewystraczająca jakość

42

Ilustracja 27: Mapa słów występujących w odpowiedziach na pytanie drugie. Wielkość słowa proporcjonalna do częstości jego występowania

obrazu. Odnalezienie książki sprawiało badanym duży problem.By odczytać tytuł (w normalnych

warunkach, bez gogli, widocznych z ponad 7-8 m) badani często zbliżali się na kikanaście

centymetrów. W szczególności trudnym było odczytanie tytułów znajdujących się na górnych

półkach, wynika to prawdopodobnie zwiększonej odległości oraz zmieninego kątu widzenia

okładki. W szczególności badani nie radzili sobie w przypadku książek gdzie tytuł miał podobne

barwy jak tło na którym się znajdował.

Kolejną kwestią było podświetlanie wybranych książek, podstawowa funkcjonalność

aplikacji rozszerzonej rzeczywistości. Badani zgłaszali, że książka nie jest podświetlana. Często

miało to związek odległością, z eksperytmentów wynika, że aby obiekt został rozpoznany nie może

znajdować się w odległości większej niż 1.5-2m (w przypadku obiektu wielkości książki).W

związku z tym algorytm nie mógł wykryć dostatecznej ilości punktów charakterystycznych by móc

rozpoznać książkę. Co więcej ludzie są przyzwyczajeni do oglądania półki z większej odległości.

Ma to też duży związek z innym aspektem wizji czyli polem widzenia. Użycie kamery telefonu

znacząco je zawęża, z około 190 stopni do około 60 stopni. W tego powodu badani często cofali się,

aby móc objąć wzrokiem większą ilość książek naraz. Powodowało to spadek jakości obrazu a w

konsewencji też efektywność podświetlania książek. Kolejnym elementem utrudniającym mogła

być sama implementacja „podświetlenia”. Działało ono poprzez nałożenie prostokąta o barwie

czerwonej na wykryty obszar (okładkę książki), jest do dobrze widoczne na ilustracjach nr 20.

Badani zgłaszali, że w praktyce obraz zdawał się ciemniejszy niż „niepodświetlony” co mogło

prowadzić do pominięcia ksiązki podczas poszukiwań.

43

7.3. Pytanie trzecie

Czy widzisz zastosowanie tych technologii, jeśli tak to gdzie?

Najczęściej pojawiającymi się odpowiedziami było te dotyczące rozrywki, gier oraz

symulacji. Są to wyniki zgodne z tym co można obserwować w działaniach korporacji zajmujących

się dziedziną wirtualnej lub rozszerzonej rzeczywistości (takich jak Microsoft, Samsung czy

Google). Autorzy również zgadzają się, że jest to najbardziej oczekiwany kierunek rozwoju

wirtualnej i rozszerzonej rzeczywistości, również w kontekcie wielkości rynku gier

komputerowych. Pojawiały się jednak również odpowiedzi mniej oczekiwane, takie jak archiwa,

wojsko czy medycyna. Można było napotkać również na bardziej ambitne zastosowania jak

rehabilitacja dla ludzi z defektami wzrokowymi, czy testy spostrzegawczości np. stosowane

podczas szkoleń dla kierowców. Ciekawą propozycją był trening równowagi, polegający na

utrzymywaniu głowy w jednej pozycji, co mogło by być realizowany poprzez porównywanie

obrazu nagrywanego ze znanym wzorem określającym poziom.

44

Ilustracja 28: Mapa słów występujących w odpowiedziach na pytanie trzecie. Wielkość słowa proporcjonalna do częstości jego występowania

7.4. Pytanie czwarte

Jak określiłbyś/określiłabyś komfort korzystania z tych rozwiązań ?

W tym pytaniu najczęściej pojawiały się odpowiedzi mówiące o dyskomforcie użytkownia.

Wyraźnych problemach z płynnością obrazu, opóźnieniami w przypadku ruchu głową. Istotnymi

były również kłopoty ze skupieniem wzroku na konkretnym punkcie i wynikające z tego problemy

z samopoczuciem. W szczeóglności takie jak ból głowy, zaburzenia równowagi, wrażenie podobne

do stanu nietrzeźwości czy nudności. Poruszanie się było określane jako utrudnione, ze względu na

inną niż w przypadku nieużywania gogli perspektywę oraz płaskość obrazu pomimo iluzji

stereowizji. Dodaktowym utrudnieniem mógłbyć fakt, że kamera aparatu nie znajduje się centralnie

przed badanym a na krawędzi jego głowy, stąd kąt patrzenia jest inny niż zwykle. Z drugiej jednak

strony warto zaznaczyć, że badani widzieli potencjał w rozwiązaniu pomimo jego wad. Byli

pozytywnie zaskoczeni możliwością obserwowania świata poprzez ekran telefonu.

45

Ilustracja 29: Mapa słów występujących w odpowiedziach na pytanie czwarte. Wielkość słowa proporcjonalna do częstości jego występowania

7.5. Pytanie piąte

Jakich poprawek, Twoim zdaniem, powinno się dokonać, aby rozwiązanie było lepsze?

Odpowiedzi udzielane w tym pytaniu są ściśle związane z poprzednimi odpowiedziami. Zasadniczo

odnosiły się do kwestii omówionych wcześniej, jednak w kontekście ulepszenia rozwiązania. Co

bardzo dobrze widoczne jest na powyższej mapie słów najcześciej pojawiającym się słowem było

poprawić. Nie powinno to dziwić, wynika to wszakże z treści zadanego pytania. Bardziej

interesujące są jednak kolejne co do wielkości słowa czyli „ostrość”, „jakość” i „zmniejszyć”. O ile

pierwsze dwa były omiawiane wcześniej, to brak lub bardzo niewiele było uwag dotyczących

samego sprzętu Weebo3D. Badani, jeśli już zwracali uwagę to na wielkość gogli a także na ich

wagę, co wraz ze zbyt słabym mocowaniem sprawiało dyskomfort. Jednakże nie było to zgłaszane

przez wszystkich uczestników, mógł więc w tej kwestii mieć znaczenie kształt lub wielkość głowy.

Co więcej, ze względu na fakt, że podczas działania aplikacji telefon pobierał znaczne ilości energii.

W pewnym stadium eksperymentu konieczne było przyczepienie do gogli powerbank'a

(przenośnego zasilania) co również wpłyneło na wagę całej instalacji.

46

Ilustracja 30: Mapa słów występujących w odpowiedziach na pytanie piąte. Wielkość słowa proporcjonalna do częstości jego występowania

8. Propozycje rozwiązań (A. Niedziałkowski)

Jak wynika z poprzedniego rozdziału głównymi elementami wymagającymi poprawy są:

• Ostrość obrazu

• Płynność obrazu

• Jakość obrazu

• Wąski kąt widzenia

W związku z tym autorzy zdecydowali się na zaproponowanie dwóch aplikacji, które miałyby

poprawić niektóre z powyższych aspektów rozszerzonej rzeczywistości. Należy jednakże

zauważyć, że niektóre zgłaszane wady wynikają bezpośrednio z wykorzystanej technologii tj.

smartfonów ze średniej półki. Poniżej opisane rozwiązania skupiają się więc na pewnym wycinku

spektrum całego problemu, należy je rozpatrywać w kontekście próby odpowiedzenia na pytanie

czy wszystkie ograniczenia są bezpośrednio związane z charakterystyką sprzętową lub czy istnieje

pole do poprawy obecnej techonologii na warstwie oprogramowania.

8.1. Platforma Android

Android jest aktualnie najpopularniejszym systemem operacyjnym na rynku urządzeń mobilnych.

Dane z drugiego kwartału 2015 wskazują, że stanowi on ponad 80% rynku. [17] Co więcej, w

przeciwieństwie do systemu iOS tworzenie aplikacji na Androida nie wiąże się z żadnymi opłatami.

Z tych właśnie powodów autorzy zdecydowali się napisać aplikację mobilne na platformę Android.

Innym atutem jest to, że system wspierany jest przez firmę Google, jedną z największych korporacji

na świecie. Dzięki temu ilość danych i publikacji jest ogromna, co stanowi bogate źródło

informacji. Warto również zaznaczyć, że dokumentacja stworzona przez tą firmę stoi na szczególnie

wysokim poziomie.

Android jest systemem opartym o jądro Linuxa, zaprojektowanym do obsługi urządzeń mobilnych

(telefonów, tabletów). Istnieją dwa języki w których można tworzyć aplikacje na tę platformę: C++

oraz Java. Ze względu na swoje doświadczenie a także łatwiejsze ewentualne utrzymywanie kodu w

dobry stanie autorzy zdecydowali się na Javę. Na rynku istnieje wiele wersji Androida. Do budowy

aplikacji w tym rozdziale zostały wykorzystane dwie wersje: Kitkat (Android 4.6) w Aplikacji I

47

oraz Lollipop (Android 5.1). Wybrano te właśnie wersje z dwóch powodów: są one w tym

momencie najbardziej popularne na rynku oraz umożlwiają pokazanie dwóch różnych API do

obsługi kamery w telefonie.

8.2. Aplikacja I

Pierwsza zaproponowana aplikacja ma za zadanie sprawdzić czy możliwa jest poprawa jakości oraz

płynności obrazu jedynie poprzez zmianę modułu obsługującego kamerę. Zamiast implementacji z

Unity autorzy stworzyli własną opartą o natywne funkcje platformy Android. W celu skorzystano z

camera API (SDK w wersji 19, Android Kitkat). Oprócz tego koniecznym było użycie cardboard

Sdk, biblioteki stworzonej przez korporację Google w celu umożliwienia programistom tworzenia

aplikacji zgodnych ze standartem Google Cardboard.

Kluczowymi elementami potrzebnymi w tej implementacji były:

CardboardView.StereoRenderer [24] oraz CardboardActivity [25]. CardboardActivity jest

odpowiedzialne za ułatwienie implementacji aplikacji korzystających z GoogleCardboard. W

szczególności posiada funkcje odpowiednialne za obsługę wydarzeń związanych z tym standartem,

takich jak obsługa bocznego przycisku (magnesu). Implementując interfejs

CardboardView.StereoRender konieczne jest zaimplementowanie następujących funkcji:

• onDrawEye – metoda odpowiedzialna za stworzenie nowej ramki dla oka (łącznie z

przekształceniem geometrycznym).

• onFinishFrame – funkcja wywoływana po narysowaniu danej ramki.

• onNewFrame – metoda wywoływana tuż przed narysowaniem nowej ramki.

• onRendererShutdown – funkcja wywoływana na wątku Renderer'a, w momencie

zakończenia wątku.

• onSurfaceChanged – metoda wywoływana w przypadku zmiany rozmiaru powierzni na

której wyświetlane są ramki.

• onSurfaceCreated – funkcja wywołana po utworzeniu lub odtworzeniu powierzchni

wyświetlania.

48

8.3. Aplikacja II

Następnym krokiem w celu poprawy zgłaszanych wad rozwiązań z rozdziału piątego i szóstego

było zwiększenie kątu widzenia. Ze względu na brak możliwości ingerencji w parametry samej

kamery oczywistym sposobem zwiększenia pola widzenia jest dodanie drugiego źródła obrazu.

Dzięki temu nie tylko poprawiony by został wyżej wymieniony element, można by również

wprowadzić faktyczną stereowizję zamiast symulowanej (jak to miało miejsce w poprzednich

aplikacjach). Autorzy musieli się jednak zdecydować w jaki sposób zrealizować wprowadzenie

dwóch źródeł obrazu, możliwości było kilka:

• Telefon z dwoma kamerami (np. HTC One (M8))

• Zewnętrzna kamera (np. kamera IP)

• Dwa telefony

Pierwsza możliwość została odrzucona ze względu na brak możliwości zdobycia takiego telefonu,

choć jest to potencjalnie dobre rozwiazanie. Wątpliwym jest jedynie to, czy odległość pomiędzy

kamerami jest na tyle duża by efektywnie zwiększyść pole widzenia. Autorzy nie zdecydowali się

na drugą propozycję, gdyż jest ona obarczona wieloma problemami natury technicznej. Po

pierwsze, sposób przekazywania obrazu z kamery do telefonu wyświetlającego. Komunikacja

mogłaby się odbywać poprzez port micro USB (znaczy stopień skomplikowania dostępu do danych,

konieczność posiadania przewodu w systemie) lub bezprzewodowo poprzez sieć. W drugim

przypadku taka kamera musiała by posiadać bezprzewodową kartę sieciową, co zwiększa pobór

mocy a także cenę urządzenia. Jest to szczególnie istotne w kontekście założenia autorów, iż

rozwiązania powinny być możliwie jak najtańsze tj. bazować już na posiadanych przez

potencjalnych użytkowników urządzeniach. Kolejną wadą rozwiązania z kamerą jest kwestia

zasilania. Autorom nie udało się znaleźć na rynku kamery bezprzewodowej z autonomicznym

zasilaniem (do 300 zł), co oznacza że całość obciążenia energetycznego spoczywałaby na telefonie.

Biorąc pod uwagę, że podczas wstępnych badań pobór mocy bardzo ograniczał żywotność baterii

(do około dwóch godzin), przypięcie dodatkowego urządzenia mogłoby wykluczyć zasadność

rozwiązania. Ostatecznie zdecydowano się na rozwiązanie z dwoma telefonami. W takim układzie

jeden z telefonów byłby urządzeniem nagrywająco-wyświetlającym (obraz z kamery byłby

wyświetlany na połowie ekranu) a drugi tylko nagrywającym. Wówczas obraz z drugiego z nich

byłby przesyłany do telefonu wyświetlającego i pokazywany na pozostałej połowie ekranu.

49

8.4. Camera API

Pierwsza aplikacja jest prostym przykładem na wykorzystanie natywych bibliotek do obsługi

kamery (aparatu) w telefonie (camera API [18]). Wykorzystywane jest SDK w wersji 19 (Android

Kitkat). Jest to o tyle istotne, że wraz z przejściem na API 21 (Android w wersji Lollipop) API do

obsługi kamery (android.hardware.camera2) zostało zmienione. Poniżej zostanie to

pokrótce omówione, gdyż zmiany sięgają bardzo głęboko i choć autorzy nie wykorzystują w pełni

konfiguralności nowej wersji oprogramowania, informacje o potencjalnych zmianach w przyszłości

mogą być istotne dla wydźwięku tej pracy.

Charakterystyczne dla API kamery w pierwszej wersji (android.hardware.Camera) jest określanie

jej jako tzw „black-box”, czyli czarnej skrzynki. Oznacza to, że kontrola nad działaniem

oprogramowania kamery była bardzo ograniczona. Lista dostępnych (w praktyce często

używanych) komend zawierała tylko kilka pozycji. Całość kodu koniecznego do uruchomienia

kamery (poza ustawieniem koniecznych uprawnień dla aplikacji tj. dostępu do sprzętu kamery)

50

Ilustracja 31: Uproszczony schemat działania zaproponowanej aplikacji.

zawiera się w zaledwie paru linjkach:

camera = Camera.open();try{ camera.setPreviewTexture(surface); camera.startPreview();}catch (IOException ioe){ // kod wykonywany w przypadku błędu // podczas podłączenia się do kamery}

Jak wynika z powyższego kodu aby uruchomić kamerę i rozpocząć przesyłanie obrazu na wybraną

powierzchnię wystarczy wywołać statyczną funkcję Camera.open(), przypisać (wcześniej

utworzoną powierzchnię) i na koniec wywołać funkcję camera.startPreview() Diagram przepływu

danych w tym przypadku wygląda następująco:

Jeżeli chodzi o camera API 2 sytuacja jest bardziej skomplikowana. Autorzy SDK zdecydowali się

udostępnić programistom więcej opcji poprzez zezwolenie im na ingerencję w przepływ danych

pomiędzy obiektami tworzącymi camera API. Po zmianach uruchomienie kamery, w najprostyszym

przypadku, analogicznym do poprzedniego (wykorzystania camera API 1) wygląda następująco:

CameraManager manager = (CameraManager)

activity.getSystemService(Context.CAMERA_SERVICE);

try { if (!mCameraOpenCloseLock.tryAcquire(2500, TimeUnit.MILLISECONDS)) { throw new RuntimeException("Time out waiting to lock camera opening."); } manager.openCamera(mCameraId, mStateCallback, mBackgroundHandler);} catch (CameraAccessException e) { e.printStackTrace();} catch (InterruptedException e) { throw new RuntimeException("Interrupted while trying to lock camera opening.", e);}

51

mPreviewRequestBuilder =

mCameraDevice.createCaptureRequest(CameraDevice.TEMPLATE_PREVIEW);

mPreviewRequestBuilder.addTarget(surface); // Here, we create a CameraCaptureSession for camera preview. mCameraDevice.createCaptureSession(Arrays.asList(surface), new CameraCaptureSession.StateCallback() { @Override public void onConfigured(@NonNull CameraCaptureSession cameraCaptureSession) { // The camera is already closed if (null == mCameraDevice) { return; } // When the session is ready, we start displaying the preview. mCaptureSession = cameraCaptureSession; try { // Auto focus should be continuous for camera preview. mPreviewRequestBuilder.set(CaptureRequest.CONTROL_AF_MODE, CaptureRequest.CONTROL_AF_MODE_CONTINUOUS_PICTURE); // Flash is automatically enabled when necessary. mPreviewRequestBuilder.set(CaptureRequest.CONTROL_AE_MODE, CaptureRequest.CONTROL_AE_MODE_ON_AUTO_FLASH); // Finally, we start displaying the camera preview. mPreviewRequest = mPreviewRequestBuilder.build(); mCaptureSession.setRepeatingRequest(mPreviewRequest, mCaptureCallback, mBackgroundHandler); } catch (CameraAccessException e) { e.printStackTrace(); } } @Override public void onConfigureFailed( @NonNull CameraCaptureSession cameraCaptureSession) { showToast("Failed"); } }, null );} catch (CameraAccessException e) { e.printStackTrace();}

52

W celu uproszczenia korzystania z aplikacji autorzy zdecydowali się na połączenie ich w jedną.

Każda z nich działa jako tzw. Fragment.

53

Ilustracja 32: Diagram przedstawiający HAL3 (Hardware Abstraction Layer) pokazujący jakskomplikowaną operacją jest obsługa kamery w API 21

Na ilustracji nr 33 widać jak wygląda ekran główny aplikacji. Można na nim wybrać czy chce się

włączyć funkcjonalność opisywaną w tej pracy jako Aplikacja I (tzn wizję z jednej kamery w

telefonie wyświetlającym) czy stereo wizję (obraz z kamery telefonu wyświetlającego oraz telefonu

przesyłającego obraz). Przycisk „Start streamer” w momencie publikacji wyników nie powoduje

żadnej akcji. Aplikacja przesyłająca obraz działa niezależnie.

54

Ilustracja 33: Zrzut ekranu aplikacji mobilnej. Menu główne

8.5. MJPEG

W przypadku aplikacji wyświetlającej obraz z dwóch telefonów koniecznym jest przesyłanie obrazu

telefonu nagrywającego do telefonu wyświetlająco nagrywającego. W związku z tym autorzy pracy

musieli podjąć decyzję, w jaki sposób przesyłać dane. Jako że telefony mają wbudowane moduły

internetowej karty bezprzewodowej zdecydowano się przesyłać dane poprzez sieć. Utworzono hot-

spot (otwarty punkt dostępu) na telefonie przesyłającym, a następnie do powstałej sieci podłączono

telefon wyświetlający. Ostatnim krokiem był wybór standardu przesyłania obrazu. Możliwymi

wyborami były H.264 (MPEG-4) lub MJPEG. Zdecydowano się na ten ostatni z kilku powodów:

1. MJPEG nie dokonuje kompresji między kolejnymi ramkami obrazu, każdy jest osobno

kompresowany zgodnie ze standartem JPEG. Wobec tego obciążenie dla procesora (a w

konsekwencji również zużycie baterii) będzie znacząco mniejsze. Jest to bardzo istotne w

przypadku urządzeń mobilnych, gdyż jak wykazały wstępne próby, pobór mocy w

przypadku aplikacji rozszerzonej/wirtualnej rzeczywistości jest bardzo duży.

2. Autorzy założyli, że zmienność przesyłanego obrazu będzie duża (okładki książek znacząco

się od siebie różnią) w związku z tym zalety technologii bazującej na kompresji czasowej

(międzyramkowej) są ograniczone.

3. Warunki w których przeprowadzany będzie eksperyment mogą być potencjalnie

niekorzystne (duża ilość osób w otoczeniu – wysokie tłumienie sygnału) oprócz tego z

doświadczenia autorów wynika, że połączenia między telefonami mogą być niestabilne.

Biorąc pod uwagę powyższe zagrożenia, kompresja przestrzenna jest lepszym wyborem od

kompresji międzyramkowej ze względu na większą odporność na utratę przesyłanych

ramek.

Przesyłanie obrazu zostało przeprowadzone poprzez protokół HTTP (Hypertext Transfer Protocol).

Telefon wyświetlający wysyłał zapytania HTTP typu GET:

Pole Wartość

Content-Type text/plain; charset=utf-8

Telefon nagrywający czyta dane z bufora przypiętego do obiektu kamery, a następnie wysyła

odpowiedź:

55

Pole Wartość

Server EgineerThesis

Connection close

Max-Age 0

Cache-Control no-store,no-cache,must-revalidate,pre-check=0,post-check=0,

max-age=0

Pragma no-cache

Access-Control-Allow-Origin *

Content-Type multipart/x-mixed-replace;boundary=--gc0p4Jq0M2Yt08jU534c0p----gc0p4Jq0M2Yt08jU534c0p--

Najciekawszym elementem powyższego nagłówka odpowiedzi jest ostatnie pole, „Content-Type”.

W przypadku gdy odpowiedź na zapytanie http na więcej niż jedną część, konieczne jest

wykorzystanie wartości multipart w polu Content-Type. Po wysłaniu takiego nagłówka możliwym

jest wysyłanie kolejnych wiadomości jako „body” (treści wiadomości), koniecznym jest jednak by

zawierały one pole „Content-Type” oraz podaną w pierwszym nagłówku wartość boundary (w tym

przypadku -–gc0p4Jq0M2Yt08jU534c0p) . [19]

Każda kolejna wiadomość będzie poprzedzona nagłówkiem zawierającym następujące pola:

Pole Wartość

Content-type image/jpeg

Content-Length Długość bufora

X-Timestamp Czas wykonania kolejnej klatki zdjęciaTransmisja zostaje zakończona po wysłaniu wiadomości kończącej w tym przypadku zawierającej

ciąg gc0p4Jq0M2Yt08jU534c0p--.

56

9. Druga część badań (A. Niedziałkowski)

Po zaimplementowaniu rozwiązań omówionych w rozdziale ósmym autorzy postanowili

ponowić badania na użytkownikach. W założeniu przetestowane miały zostać obydwie aplikacje,

ale ze względu na ograniczeniu czasowe zdecydowano o przetestowaniu jedynie Aplikacji II. Warto

zaznaczyć, że wykorzystano w niej wszystkie technologie użyte w Aplikacji I, wobec tego

wykorzystanie pierwszej aplikacji nie jest istotnym uszczerbkiem na wartości naukowej tej pracy.

Dlatego też pytanie pierwsze , dotyczące wyłączenie Aplikacji I, zostało wykreślone z ankiety.

9.1. Przebieg badań

Przebieg badań był następujący:

1. Badanemu zakładał gogle z zamocowanym tefonem wyświetlającym. Następnie

otrzymywał drugi telefon z uruchomioną aplikacją przesyłającą obraz z kamery i jego

zadaniem było takie ustawienie telefonu względem gogli by wyświetlany obraz z obydwu

oczu zsynchronizował się, tj żeby obydwa obrazy dobrze się nałożyły, a efekt był możliwie

naturalny.

2. Użytkownik miał chwilę na oswojenie się z nowym sposobem widzenia, poza tym miał

pełną dowolność jeżeli chodzi sposób wykorzystania sprzętu.

3. Na końcu, podobnie jak w przypadku pierwszej serii badań proszony był o wypełnienie

krótkiej ankiety.

Poniżej przedstawiono pytania zadane uczestnikom badania:

1. Jakie są Twoje odczucia odnośnie rozwiązania z jednym telefonem? Jakie widzisz jego

wady i zalety?

2. Jakie są Twoje odczucia odnośnie rozwiązania z dwoma telefonami? Jakie widzisz jego

wady i zalety?

3. Jak określiłbyś/ określiłabyś komfort korzystania z tych rozwiązań ?

57

Ilustracja 34: Jedna z osób badanych podczas eksperymentu II

9.2. Wyniki badań

Podobnie jak w przypadku poprzednich badań autorzy zdecydowali się na podział analizy wyników

według pytań. W taki sam sposób zostało również omówione dane, stworzono mapę słów dla

każdego pytania, a następnie autorzy krótko podsumowali wnioski wyciągnięte z wypowiedzi

ankietowanych. Jak zostało to wspomniane w poprzednim podrozdziale pominięte zostało pytania

pierwsze, gdyż w kontekscie braku wykorzystania Aplikacji I w badaniu, jest ono bezzasadne.

58

9.3. Pytanie drugie

Jakie są Twoje odczucia odnośnie rozwiązania z dwoma telefonami? Jakie widzisz jego wady i

zalety?

W pierwszym pytania uczestnicy zwracali głównie uwagę na problem z konfiguracją całości

systemu. Mieli problem z poprawnym ustawieniem telefonu. Wynikało to przede wszystkim z braku

jasnej instrukcji w jaki sposób to uczynić, odbywało się metodą prób i błędów. Uczestnicy nie byli

informowali w jaki sposób należy ustawić obydwa telefonu względem siebie dlatego, iż jak

wynikało ze wstępnych badań (co również zostało potwierdzoone w tym eksperymencie) jest to

sprawa bardzo indywidualna. W gre wchodzą trzy czynniki: wysokość, odległość od telefonu

zamotowanego w goglach oraz kąt nachylenia telefonu. Poniżej przedstawiono zdjęcia na których

widoczne jest jak różne były konfiguracji w których badani zgłaszali, że „widzą poprawnie”.

Autorzy zamierzali zamontować drugi telefon na stałe na goglach np. przy pomocy rzepu. Okazało

się jednak, że aby obraz poprawnie się nałożył konieczna jest albo bardzo wysoka precyzja albo

ciągłe kompensowanie niedoskonałości poprzez poruszanie ruchomym telefonem. Ze względu na

59

Ilustracja 35: Mapa słów występujących w odpowiedziach na pytanie drugie. Wielkość słowa proporcjonalna do częstości jego występowania

brak możliwości tak dokladnego zamontowania telefonu (biorąc pod uwagę, że musiał być on co

jakiś czas demontowany) zdecydowano, że wariant z kompensowaniem niedokładności przez

użytkownika jest lepszym rozwiązaniem. Wartym uwagi jest jednak, że pomimo oczywistych wad

rozwiązania opinie badanych były pozytywne. Często próbowali wykorzystać sprzęt do czynności

nieprzewidzianych przez autorów np. podnosili telefon nad głowę by móc obserwować

pomieszczenie z innej perspektywy. W ankietach pojawiały się również takie sformułowania jak :

"cudowny sposób na zmianę punktu widzenia" czy "bardziej naturalnie niż przy jednym telefonie".

Innym bardzo często wymienianym aspektem na który zwracano uwagę było poszerzenie pola

widzenia. Był to jeden z głównych problemów opisanych w Rozdziale 7, które były zgłaszane

podczas piewszych badań.

9.4. Pytanie trzecie

Jak określiłbyś/ określiłabyś komfort korzystania z tych rozwiązań ?

W drugim pytaniu ankietowani zwracali szczegolną uwagę na niską komfortowość rozwiązania w

którym koniecznym jest by jeden telefon trzymany był w ręce. W szczegolności, ze już niewielkie

ruchy ręką doprowadzały do rozsynchronizowania obrazu. Dodatkowym elementem utrudniającym

60

Ilustracja 36: Mapa słów występujących w odpowiedziach na pytanie trzecie. Wielkość słowa proporcjonalna do częstości jego występowania

poprawe ustawienie sprzętu był fakt, że ,jak zgłaszali badani, mózg buntował się w sytuacji w której

obraz był diametralnie inny niż naturalnie. Objawiało się to między innymi: bólem głowy, bólem

oczu i zaburzeniami równowagi. Pozytywnie natomiast została oceniona ostrość (lepiej niż w

przypadku rozwiązań opartych na Unity) jak i płynność obrazu nadawanego z telefonu

wyświetlającego. Zauważalne były jednak opóźnienia pomiędzy obrazem widzianych przez prawe

oko, tj. nadawanego z drugiego telefonu. Drugi obraz został również oceniony jako mniej ostry.

Jako najbardziej uciążliwą sytuację badani zgłaszali szybkie ruchy głową (obraz przesyłany

MJPEGiem był opóźniony)

61

10. Podsumowanie pracy

W tej pracy autorzy starali się odpowiedzieć na kilka pytań. Przede wszystkim ich zadaniem była

niskobudżetowa implementacja rozszerzonej oraz wirtualnej rzeczywistości. Dzięki dostępnym

obecnie zaawansowanym a bezpłatnym narzędziom, takim jak platforma Unity3D oraz biblioteka

Vuforia, okazało się to zadanie w pełni wykonalne. W kontekście pierwszych prób konstruowania

systemów wirtualnej/rozszerzonej rzeczywistości opisanych w rozdziale 2, można zauważyć jak

ogromny przeskok technologiczny dokonał się na przestrzeni lat.

Implementacja wirtualnej rzeczywistości udowadnia, że dzisiejsze telefony ze średniej półki mają

wystarczającą moc obliczeniową a także rozdzielczość ekranu by efektywnie tworzyć wirtualny

świat. Implementacja rozszerzonej rzeczywistości, podświetlająca książki w rzeczywistym świecie,

pokazuje, że rozszerzona rzeczywistość może być bardzo pomocna w codziennym życiu.

Badania user experience przeprowadzone przez autorów pokazały, że rozwiązania mają

zastosowanie pomimo swoich niedoskonałości. Badani pozytywnie wypowiadali się w kontekście

wykorzystywania tego typu technologii w codziennym życiu, zarówno w formie rozrywki jak i

pomocy w podstawowych czynnościach. Zauważali też potencjał proponowanych rozwiązań oraz

wyrażali zainteresowanie rozwojem tych dziedzin nauki w przyszłości.

Udało się również zdefiniować główne aspekty wymagające poprawy. Ze względu na ograniczenia

samych telefonów, poprawa ostrości czy jakości obrazu była możliwa tylko w pewnym zakresie.

Autorzy sądzą, że rozwiązanie z systemem dwóch połączonych telefonów, choć nie idealne, może

okazać się dużym udogodnieniem w dziedzinie niskobudżetowej mobilnej rozszerzonej i wirtualnej

rzeczywistości.

Podsumowując, zdaniem autorów obecne możliwości telefonów ze średniej półki umożliwiają

efektywną implementację wirtualnej i rozszerzonej rzeczywistości. Wiele jej niestety jeszcze

brakuje do etapu w którym mogłaby konkurować z rozwiązaniami takimi jak Oculus Rift (wirtualna

rzeczywistość) czy Microsoft HoloLens (rozszerzona rzeczywistość). Biorąc jednak pod uwagę

ciągłą miniaturyzację sprzętu jak i pomysłowość programistów na całym świecie, w najbliższych

latach można spodziewać się kolejnych, coraz tańszych i lepszych rozwiązań w tej dziedzinie.

62

11. Bibliografia

1. T. Mccolum, Stereoscopic television apparatus. US Patent #2,388,170 (1945).

2. M. L. Heilig, Stereoscopic-television apparatus for individual use. US Patent #2,955,156

(1960).

3. M.L. Heilig, Sensorama simulator. US Patent #3,050,870 (1962).

4. I. E. Sutherland, The Ultimate Display. Proceedings of IFIP 65, vol 2, pp. 506-508 (1965).

5. I. E. Sutherland, A head-mounted three dimensional display. Proceedings of AFIPS 68, pp.

757-764 (1968).

6. S. Mann i inni, Designing EyeTap Digital Eyeglasses for Continuous Lifelong Capture and

Sharing of Personal Experiences. (2005)

7. P. Rubin, The Inside Story of Oculus Rift and How Virtual Reality Became Reality. Wired

2014. Dostęp 8.01.2016. http://www.wired.com/2014/05/oculus-rift-4/

8. T. Clark, How Palmer Luckey Created Oculus Rift. Smithsonian Magazine 2014. Dostęp

8.01.2016. http://www.smithsonianmag.com/innovation/how-palmer-luckey-created-oculus-

rift-180953049/?no-ist

9. Facebook to acquire Oculus. Notatka prasowa. 2014. Dostęp 8.01.2016.

http://newsroom.fb.com/news/2014/03/facebook-to-acquire-oculus/

10. S. Cass, C. Q. Choi, Google Glass, HoloLens, and the Real Future of Augmented Reality.

Spectrum IEEE 2015. Dostęp 8.01.2016. http://spectrum.ieee.org/consumer-

electronics/audiovideo/google-glass-hololens-and-the-real-future-of-augmented-reality

11. Microsoft Hololens demo at Windows 10 devices event. Film dostępny w serwisie YouTube.

Dostęp 8.01.2016. https://www.youtube.com/watch?v=C3rNIxMlKmI

12. Google Glass sales halted but firm says kit is not dead. BBC News, 2015. Dostęp 8.01.2016.

http://www.bbc.com/news/technology-30831128

13. N. Statt, Facebook has Oculus, Google has Cardboard. Cnet 2014. Dostęp 8.01.2016.

http://www.cnet.com/news/facebook-has-oculus-google-has-cardboard/

14. Strona twórców Google Cardboard. Dostęp 8.01.2016.

https://www.google.com/intl/pl_ALL/get/cardboard/get-cardboard/

63

15. Strona twórców okularów Weebo3D. Dostęp 8.01.2016. www.weebo3d.pl

16. Poradnik dla programistów pracujących z biblioteką Vuforia. Dostęp 8.01.2016.

https://developer.vuforia.com/library/articles/Solution/Natural-Features-and-Ratings

17. Smartphone OS Market Share, 2015 Q2. IDC 2015. Dostęp 8.01.2016.

http://www.idc.com/prodserv/smartphone-os-market-share.jsp

18. Poradnik dla programistów pracujących z Android SDK. Dostęp 8.01.2016.

http://developer.android.com/reference/android/hardware/Camera.html

19. N. Borenstein, N. Freed, MIME (Multipurpose Internet Mail Extensions), rozdział 7.2.

RFC1341. Dostęp 8.01.2016. http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

20. Documentation, Unity scripting and you. Post na blogu Unity3D, 2014. Dostęp 8.01.2016.

http://blogs.unity3d.com/2014/09/03/documentation-unity-scripting-languages-and-you/

21. Strona twórców platformy Unity3D. Dostęp 8.01.2016. https://unity3d.com/learn

22. Witryna UXDesign. Dostęp 8.01.2016. http://uxdesign.pl/problemy-z-terminologia/

tłumaczone z http://www.nngroup.com/about/userexperience.html

23. Guidance on Usability. ISO 9241-11.

24. Dokumentacja projektu Google Cardboard. Dostęp 8.01.2016.

https://developers.google.com/cardboard/android/latest/reference/com/google/vrtoolkit/card

board/CardboardView.StereoRenderer

25. Dokumentacja projektu Google Cardboard. Dostęp 8.01.2016.

https://developers.google.com/cardboard/android/latest/reference/com/google/vrtoolkit/card

board/CardboardActivity

64

12. Źródła ilustracji

M.L. Heilig, Sensorama simulator. US Patent #3,050,870 (1962) - 2

Wikimedia Commons – 4, 5, 7

Microsoft Hololens demo at Windows 10 devices event. Film dostępny w serwisie YouTube. Dostęp

8.01.2016. https://www.youtube.com/watch?v=C3rNIxMlKmI – 6

Witryna Muzeum Historii Komputerów w Mountain View, CA. Dostęp 8.01.2016.

http://www.computerhistory.org/revolution/input-output/14/356/1830 - 3

Witryna projektu Google Cardboard. Dostęp 8.01.2016. https://www.google.com/get/cardboard/ - 9

Witryna producenta okularów Weebo3D. Dostęp 8.01.2016. - 10

Witryna projektu Android. Dostęp 8.01.2016. - 32

Wykonanie własne - pozostałe

65