opracowanie rozszerzonej/wirtualnej rzeczywistości z
TRANSCRIPT
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