Wyzwania architektoniczne w tworzeniu aplikacji na okulary Rzeczywistości Rozszerzonej
Tworzenie oprogramowania na okulary Rzeczywistości Rozszerzonej (systemu łączącego świat rzeczywisty z generowanym komputerowo [1]) wymaga podejmowania decyzji w zakresie lokalizacji komponentów w kontekście nietypowych możliwości technicznych tego rodzaju urządzeń. W artykule dokonano identyfikacji wytycznych w zakresie tworzenia odpowiedniej architektury aplikacyjnej [1] ze szczególnym podkreśleniem roli złożoności sterowania, złożoności przetwarzania i zakresu wykorzystywanych czujników. Przedstawiono klasyfikację okularów AR oraz zaproponowano reguły podejmowania decyzji projektowych prowadzące do właściwej alokacji komponentów aplikacyjnych zlokalizowanych w różnych elementach architektur sprzętowych.
Klasyfikacja okularów Rzeczywistości Rozszerzonej
Poniżej przedstawiono autorską klasyfikację urządzeń posiadających możliwość wyświetlania obrazów w bliskiej odległości od oczu użytkowników. Bazuje ona na różnicach w zakresie: możliwości mocy przetwarzania danych jako niezależnych komputerów, posiadanie funkcji analizującej położenie okularów w przestrzeni (SLAM [4][5][6][7]) i wynikającego z tego zdolności do wyświetlania i pozycjonowania obiektów 3D w przestrzeni, posiadania lub nie własnego komputera.
Pozwoliło to sformułować 4 główne grupy urządzeń:
1. Naoczne wyświetlacze strumieni danych: Wyświetlacze AR (AR Displays)
2. Naoczne komputery Rzeczywistości Rozszerzonej: Okulary AR (AR Glasses)
3. Naoczne komputery Rzeczywistości Mieszanej: Okulary MR (Mixed Reality Glasses)
4. Naoczne wyświetlacze Rzeczywistości Mieszanej: Wyświetlacze MR (Mixed Reality Displays)
Poniżej przedstawiono opis podanych klas urządzeń.
Naoczne wyświetlacze strumieni danych: Wyświetlacze AR (AR Displays)
Urządzenia należące do tej grupy mają funkcjonalność wyświetlania obrazów przed oczami użytkownika nie posiadając przy tym własnego komputera z systemem operacyjnym - odbierają pakiety danych z zewnętrznych urządzeń. Modelowe okulary tego typu to Epson BT-35E [9]. Urządzenie to podpina się przez port HDMI/USB do strumieni danych video. Wyświetlacze prezentują dwuoczny czysty obraz w relatywnie dużej rozdzielczości. Nie jest możliwe sterowanie tym obrazem w rozumieniu jego wyłączania lub modyfikacji. Okulary mogą posiadać IMU po to by np. obracać się w filmie sferycznym. Wyświetlacz tego typu nie może wykonywać operacji innych niż tylko pasywne wyświetlanie.
Wyświetlacze strumieni danych mogą znaleźć zastosowanie zawsze tam, gdzie potrzebne jest przekazanie przed oczy użytkownika strumienia video z kamer, ekranów komputera, danych z systemów monitoringu. Posiadają bardzo skromne możliwości sterowania oraz podstawowy zestaw czujników.
Naoczne komputery Rzeczywistości Rozszerzonej: Okulary AR (AR Glasses)
Modelowe okulary Rzeczywistości Rozszerzonej spełniać powinny następujące wymagania:
1. Własny komputer z systemem operacyjny
2. Wyświetlacz przykrywający co najmniej 14 stopni pola widzenia
3. 9-osiowe IMU (akcelerometr, kompas, żyroskop)
4. Zestaw czujników: natężenie otaczającego światła, czujnik ciśnienia, inne
5. Kamera wizyjna
6. Zdolność do komunikowania się przez Bluetooth, wifi, port USB
7. Mikrofon
8. Głośniki wbudowane
Zakłada się, że okular należący do tej grupy prawidłowo wyświetli piktogramy, napisy, obrazki, video, ale nie jest on przeznaczony do generowania i animowania złożonych obiektów 3D. Pola widzenia okularów Rzeczywistości Rozszerzonej to zakres 9 do 23 stopni a dominującą rozdzielczością jest 480px. Niemal wszystkie okulary typu AR są jednooczne. Wynika to najprawdopodobniej ze konieczności zapewnienia efektywności energetycznej przy ogólnie akceptowalnym dla człowieka użyciu jednego oka.
Okulary te mają podstawowe możliwości sterowania bazujące zwykle na taczpadzie w samym okularze lub urządzeniach zewnętrznych: taczpad przypięty na kablu, joystick Bluetooth. Niektóre z nich dysponują rozpoznawaniem prostych komend głosowych. Istotnym elementem ich działania jest aplikacja „kompanion” instalowana na smartfonie, z której można zarządzać swoim okularem lub korzystać z niej jako wirtualnego taczpadu (Vuzix Blade). Aplikacją „kompanion” przyjęto nazywać każdą aplikację, która wspomaga komponent aplikacyjny działający na okularach - nie musi to być wyłącznie aplikacja wspomagająca sterowanie samym okularem.
Okulary AR te nie posiadają funkcji SLAM Simultaneous Localisation and Mapping – analiza komputerowego tworzenia mapy nieznanego otoczenia wraz z zapisem lokalizacji użytkownika [4][5][6][7]. Urządzenia te orientują się w przestrzeni za pomocą IMU: akcelerometr, żyroskop, kompas + GPS. W grupie podstawowych urządzeń tego typu umieszczono: Vuzix Blade [8], North Focals [14], Epson Moverio BT300 i BT350 [9], Google Glass 2.0[13], Madgaze X5[11].
Istnieje podgrupa okularów AR o wysokich parametrach obliczeniowych dedykowana do przemysłu. Zaliczono do niej modele Vuzix M300XL [8], Vuzix M400[8], VuzixM4000[8] i RealWare HMT1[17]. W przypadku tych okularów AR architektura aplikacyjna bazuje głównie na przetwarzaniu na samym okularze, bez konieczności dodatkowego przetwarzania na smartfonie lub serwerze. Tego typu okular AR staje się urządzeniem mobilnym, od którego oczekuje się przetwarzania jak na wydajnym tablecie.
Naoczne komputery Rzeczywistości Mieszanej: Okulary MR (Mixed Reality Glasses)
Okulary Mixed Reality to grupa urządzeń „świadomych” swojego otoczenia, a więc szybkich komputerów analizujących w czasie rzeczywistym miejsce, w którym znalazł się użytkownik (SLAM [4][5][6][7]).
Okulary MR mają wszystkie cechy mocnego obliczeniowo okularów AR oraz dodatkowo posiadają:
1. SLAM (zestaw czujników i oprogramowania pozwalający na mapowanie bliskiego otoczenia)
2. Dodatkowe kamery i czujniki (np. lidar, czujnik temperatury, czujniki mierzące pozycję gałek ocznych)
3. Dodatkowe metody sterowania (gesty, ruchy głowy, ruchy gałek ocznych)
W grupie tej znalazły się trzy modele: Microsoft Hololens 2[10] o wadze 566 gramów, MagicLeap 1 i 2 oraz stosunkowo lekkie, bo ważące 180 gramów Thirdeye X2 MR[12]. Okulary MR stawiają sobie za cel intensywne wzbogacenie rzeczywistości, dlatego też mają szerokie pola widzenia, sterowanie oparte o gesty, wyraźne i kolorowe obiekty 3D w swoich wyświetlaczach. Microsoft Hololens 2 dysponuje najbogatszymi na rynku zdolnościami analizy otoczenia, potrafi śledzić ruchy gałek ocznych użytkownika, rozpoznaje gesty, dźwięki. Jest to urządzenie przeznaczone dla bardzo wymagających aplikacji.
Urządzenia Hololens i Thirdeye posiadają swoje jednostki centralne wbudowane w bryłę główną okularów. MagicLeap wyprowadza swoją jednostkę centralną kablem aby umieścić ją w kieszeni (jest zbyt duża aby zamocować ją na głowie). Część optyczna MagicLeap nie ma jednak możliwości podpinania się do smartfonów.
Naoczne wyświetlacze Rzeczywistości Mieszanej – Mixed Reality Displays
Intensywne prace badawczo-rozwojowe dwóch wielkich firm tj. MagicLeap i Microsoft dały inspiracje innym firmom do stworzenia zaskakująco efektywnych rozwiązań MR w innej architekturze sprzętowej. Podobnie jak w przypadku wspomnianych firm celem było osiągnięcie dużego wzmocnionego pola widzenia gotowego do obsługi złożonych obiektów 3D. Aby umieszczać w tym polu obiekty i animacje 3D konieczne jest posiadanie funkcji SLAM. Urządzenia te zwykle ją posiadają. Projektanci wyświetlaczy MR rozwiązali lokalizację komputera inaczej - wynosząc go z bryły okulara na zewnątrz – w postaci własnej jednostki obliczeniowej lub niezależnego smartfonu podpiętego przez kabel USB. Powstała nowa gałąź okularów, które nie posiadają własnego komputera konsumując obliczenia wykonywane przez inne jednostki.
W urządzeniach tych zastosowano mechanizm strumieniowania w orientacji pionowej, za pomocą układu optycznego OLED, soczewka, lusterko. Uzyskano dzięki temu pole widzenia (FOV) rzędu 42-52 stopnie przy rozdzielczościach 720x1080 pikseli co jest bardzo dobrym wynikiem. Nie odbyło się to bez kompromisów. Optyka tych okularów ma charakterystycznie przesłonięte górne części pól widzenia, co sprawia, że użytkownik musi nienaturalnie unosić głowę chcąc dostrzec obiekty zlokalizowane nad nim. Wyświetlacz MR jest relatywnie lekki, ale odstaje od głowy. Nie udało się ostatecznie schować pokaźnych rozmiarów układu optycznego. Komputer pochodzi albo ze smartfona albo z dedykowanego urządzenia komputerowego, dokładnie tak jak rozwiązał to Epson w modelach Moverio BT300, BT350 [9]. W przypadku gdy urządzeniem komputerowym jest telefon konieczne jest zapewnienie integracji poprzez oprogramowanie działające na tym telefonie. Okulary czerpią wówczas z telefonu energię oraz komunikują się z systemem operacyjnym tego urządzenia.
Rozdzielnie przetwarzania na dwa urządzenia jest krokiem, który być może okaże się kluczowym z punktu widzenia niskiej masy takich okularów. Trzymanie przy sobie silnego komputera przenośnego (z baterią) lub smartfona nie jest dla wielu użytkowników problematyczne. Przykładami urządzeń tego typu są Nreal [15], Madgaze Glow [11] oraz 0Glasses Real-X [16].
Autor przewiduje, że w niedalekiej przyszłości kierunek rozwoju okularów AR/MR polegać będzie na dalszej redukcji przetwarzania w bryle urządzenia na rzecz obliczeń w chmurze i komunikacji 5G. Prawdopodobnie okulary AR i MR w roku 2025 będą przede wszystkim naocznymi wyświetlaczami uzbrojonymi w IMU, SLAM z modułami łączności 5G. Obniży to wymagania energetyczne i rozmiar urządzeń zapewniając jednocześnie praktycznie nieograniczone możliwości obliczeniowe.
Kluczowe wymagania w projektowaniu rozwiązań na okulary AR
W ramach prac badawczych autora sformułowano tezę, że poprawna architektura komponentów aplikacyjnych systemów tworzonych na okulary AR różnić się będzie w zależności od siły oddziaływania 3 kluczowych wymagań: złożoności przetwarzania wyświetlanych informacji, złożoności sterowania, zakresu wykorzystania czujników w okularach.
Złożoność przetwarzania wyświetlanych informacji. Najprostszym obrazem będzie tekst, najbardziej złożonym będzie skomplikowana animacja 3D (np. bijące serce człowieka)
Im bardziej złożone jest przetwarzanie wyświetlanego obrazu tym bardziej rosną wymagania na procesor i pamięć. Lokalizacja tego przetwarzania musi być umieszczona na urządzeniu o odpowiedniej mocy obliczeniowej. Niskie i średnie wymagania obliczeniowe obsłuży sam okular, wyższe telefon, bardzo wysokie wymagania obsłużą komputery i serwery. Lokalizacja przetwarzania determinuje wszystkie integracje i opóźnienia komunikatów w działaniu systemu.
Opracowano uproszczone skalowanie złożoności przetwarzania wyświetlanych informacji:
0 – wyświetlanie tekstów
1 – wyświetlanie obiektów 2D bez kontekstu przestrzeni (statyczne)
2 – wyświetlanie obiektów 2D lokalizowanych w przestrzeni
3 – wyświetlanie obiektów 3D bez kontekstu przestrzeni (statyczne)
4 – wyświetlanie obiektów 3D zlokalizowanych w przestrzeni
5 – wyświetlanie animacji 3D w przestrzeni
Zakres wykorzystania czujników okularu. Najmniej wymagające aplikacje nie korzystają z IMU. Najbardziej wymagające korzystają z wszystkich dostępnych czujników SLAM, IMU, kamera i inne.
Im szersze jest wykorzystanie czujników okularowych tym silniejsza jest potrzeba wykonywania aplikacji na samym okularze AR (ze względu na opóźnienia i ewentualne niespójności wskazań czujników, jeśli są one odczytywane np. z telefonu, prowadząc do dezorientacji użytkownika).
Opracowano skalowanie zakresu wykorzystania czujników:
0 – brak
1 – jeden prosty czujnik
2 – złożony czujnik np. kamera video użyta do analizy obrazów
3 – IMU i dodatkowe czujniki np. kamery lidar
4 – SLAM
5 – SLAM, IMU, dodatkowe czujniki
Złożoność sterowania aplikacjami: od braku interakcji do złożonych interakcji typu edycja tekstu, obrazu, edycja filmu i dźwięku.
Opracowano skalowanie złożoności sterowania:
0 – uruchamianie aplikacji, bez sterowania
1 – akceptacje, przewijanie, cofnięcia
2 – jak w 1 + edycja tekstu
3 – jak w 2 + wskazywanie pozycji
4 – jak w 3 + edycja mediów i złożona edycja tekstów
5 – jak w 4 + złożone wyszukiwanie i wybieranie danych
Wyróżniono następujące metody sterowania w architekturach opartych o okulary AR/MR:
Wprowadzanie tekstu przez taczpad
w okularze
w aplikacji kompanion w telefonie/tablecie
poprzez klawiaturę bluetooth podpiętą do okulara
Wprowadzanie tekstu poprzez głos
Wskazywanie pozycji wskaźnika
w okularze poprzez taczpad
w aplikacji kompanion poprzez wirtualny taczpad
poprzez myszkę bluetooth
poprzez pozycję głowy (kontrola spojrzeniem, ang: „gaze control”)
Przyciski w bryle okulara: next/back, accept/go up itd
Komendy głosowe typu: open, close, next, back, accept
Mruganie powiekami mające znaczenie: open, close, next, back, accept
Gesty dłońmi w polu widzenia kamery okulara mające znaczenie zbliżone do komend głosowych oraz wskazywanie punktu myszką
W Tabeli 1 przedstawiono metody sterowania używane w architekturach AR pod kątem czasu ich obsługi oraz bezbłędności (zakłada się ze błąd we wskazaniu danej metody wymaga jej ponowienia). Posortowano je od metod najbardziej precyzyjnych do najbardziej błędogennych. Użytkownicy systemów AR/MR będą po pewnym czasie preferować metody szybkie i bezbłędne. Wpływa to bardzo istotnie na liczbę urządzeń w architekturze rozwiązania.
Tabela 1 Pomiary efektywności metod sterowania (badania autorskie)
Metoda sterowania okularem
Przybliżony czas poświęcany przez użytkownika na przekazanie jednej informacji sterującej: znaku, fonemu, wskazania, kliknięcia w sekundach
Bezbłędność (% poprawnych wskazań) i konieczność powtórki przy błędzie.
Wprowadzanie tekstu przez taczpad w aplikacji kompanion
0,2
99%
Wprowadzanie tekstu poprzez klawiaturę bluetooth
0,2
99%
Wskazywanie pozycji wskaźnika przez myszkę bluetooth
0,2
99%
Wskazywanie pozycji wskaźnika poprzez taczpad w aplikacji kompanion (wirtualny taczpad)
0,5
90%
Wskazywanie pozycji wskaźnika poprzez pozycję głowy
1-2
90%
Przyciski w bryle okularu: next/back, accept/go up itd
0,2
90%
Mruganie powiekami jako komendy: open, close, next, back, accept
0,2
90%
Komendy głosowe typu: open, close, next, back, accept
0,5
80%
Gesty dłońmi w polu widzenia okularów
2 – 5
80%
Wskazywanie pozycji wskaźnika poprzez taczpad w okularze
2 – 5
70%
Wprowadzanie wolnego tekstu przez taczpad w okularze
5
60%
Wprowadzanie dowolnego tekstu poprzez głos
0,2
60%
Okular zwykle nie posiada metod złożonego, precyzyjnego i szybkiego sterowania. Dlatego im bardziej złożona jest aplikacja od strony sterowania tym silniej dąży się do obsługi na urządzeniach innych niż sam okular AR. Użytkownicy z czasem wybierają najszybsze i najbardziej bezbłędne metody – korzystając z listy metod dostępnych w danym urządzeniu (lub zestawie urządzeń).
Poniżej przedstawiono wykres natężenia występowania podanych wymagań kluczowych dla wybranych, popularnych aplikacji.
Rysunek 1 Ocena kluczowych wymagań w popularnych aplikacjach
Rysunek 1 obrazuje typowe zależności w aplikacjach uruchamianych na okularach. Aplikacje strumieniowe: Youtube, Neflix, Zoom mają bardzo małe wymagania na przetwarzanie w okularach, sterowanie i czujniki, ponieważ większość ich przetwarzania wykonują serwery a po stronie użytkownika zostaje uruchamianie i odbieranie/nadawanie strumieni danych. Aplikacje edycyjne: Word, Excel, Statistica oraz Facebook i Messenger wymagają bardzo złożonych metod wprowadzania, edycji, wyszukiwania informacji co skutkuje koniecznością zapewnienia dodatkowych narzędzi sterowania typu wirtualny taczpad lub klawiatura bluetooth. Aplikacje AR/MR typu: holograficzna konferencja, gra MR, wizualizacja animacji bijącego serca, mają duży zakres wykorzystywanych czujników, korelujący istotnie ze złożonością przetwarzania. Jeśli posiadają przy tym duże wymagania na sterowanie to zwykle wykonują je gestami w polu widzenia kamer okulara. Możliwe jest stwierdzenie, że po pewnym czasie sterowanie za pomocą gestów zostanie zredukowane do przewijania elementów i otwierania (akceptowania) podczas gdy np. wprowadzanie danych tekstowych będzie musiało oprzeć się o dodatkową klawiaturę.
Opracowanie aplikacji wymagającej dużej mocy obliczeniowej, korzystającej ze wszystkich czujników, wymagającej złożonego wprowadzania danych (czyli w naszym skalowaniu posiadającej oceny 5,5,5) wymagałoby oparcia jej na najbardziej wydajnych okularach MR albo rozdzielenia przetwarzania na większą liczbę komputerów (i opracowania adekwatnych integracji). W zakresie sterowania nie do uniknięcia jest dodanie urządzeń sterowania typu myszka i klawiatura bluetooth.
Reguły decyzyjne w zakresie alokacji komponentów oprogramowania w rozwiązaniach AR
Przedstawioną w poprzednim rozdziale klasyfikacja aplikacji wg wymagań kluczowych, zestawiono z możliwościami technicznych poszczególnych okularów AR. Pozwoliło to zdefiniować następujące reguły architektoniczne:
Jeżeli złożoność sterowania jest większa niż 3 oznacza to, że wskazane jest zastosowanie w rozwiązaniu dodatkowego sterowania opartego o aplikację kompanion lub klawiaturę i myszkę. Złożoność sterowania mniejsza niż 3 nie wymaga dodatków sprzętowych.
Jeżeli złożoność sterowania jest równa 5 oznacza to, że aplikacja nie powinna być uruchamiana w środowisku AR. Korzystanie z niej jest mniej efektywne niż w klasycznych środowiskach opartych o komputer stacjonarny. Jeśli jednak inne cechy tej aplikacji (np. intensywne korzystanie z czujników) wymuszają korzystanie z niej w środowisku AR, to koniecznym jest zapewnienie klawiatury i myszki.
Jeżeli złożoność przetwarzania jest większa niż 3 oznacza to, że prawdopodobnie zabraknie mocy obliczeniowej i konieczne będzie rozdzielenie komponentów systemu na okular i telefon lub należy wybrać taki okular AR, który dysponuje dużą mocą obliczeniową.
Jeśli wykorzystanie czujników przekracza wartość 3 oznacza to, że konieczne jest zainstalowanie aplikacji na samym okularze. Ewentualne wspierane się czujnikami z zewnętrznych urządzeń nie może opóźniać przetwarzania aplikacji ani wprowadzać dezorientacji u użytkownika.
Przykładowe konfiguracje wymagań, dobór sprzętu oraz architektury aplikacyjnej uzyskane dzięki stosowaniu opisanych reguł:
Sterowanie = 2, Przetwarzanie = 1, Czujniki = 5.
Rekomendacja: optymalny rodzaj urządzenia AR: Okular AR. Aplikacja wykonywana lokalnie na okularze w dowolnej technologii, z opcją na komunikację poprzez usługi sieciowe.
Sterowanie = 2, Przetwarzanie = 4, Czujniki = 5.
Rekomendacja: optymalny rodzaj urządzenia AR: Okular MR. Aplikacja wykonywana lokalnie na okularze w technologiach grupy Unity, Vuforia, z opcją na komunikację poprzez usługi sieciowe.
Sterowanie = 1, Przetwarzanie = 4, Czujniki = 1.
Rekomendacja: optymalny rodzaj urządzenia AR: Wyświetlacz AR. Aplikacja wykonywana na telefonie lub komputerze stacjonarnym przesyłająca strumień danych na wyświetlacz AR.
Sterowanie = 4, Przetwarzanie = 4, Czujniki = 4.
Rekomendacja: optymalny rodzaj urządzenia AR: Okular MR. Aplikacja wykonywana okularze MR. Wymagane dodatkowe urządzenia sterujące, np. klawiatura i myszka bluetooth albo aplikacja kompanion wykonująca jednocześnie przetwarzanie zewnętrzne.
Sterowanie = 4, Przetwarzanie = 4, Czujniki = 1.
Rekomendacja: optymalny rodzaj urządzenia AR: Wyświetlacz MR. Aplikacja wykonywana na telefonie lub komputerze stacjonarnym przesyłająca strumień danych na wyświetlacz MR. Wymagane dodatkowe urządzenia sterujące, np. klawiatura i myszka bluetooth albo aplikacja kompanion wykonująca jednocześnie przetwarzanie zewnętrzne.
W autorskiej aplikacji VEO Navigation tj. systemu nawigacyjnego na okulary AR, konfiguracja kluczowych wymagań była następująca: Sterowanie = 4, Przetwarzanie = 2, Czujniki = 3. Aplikacja wymaga edycji tekstów przy podawaniu adresów, selekcji pozycji geograficznych, ustawiania waypointów na mapie, przybliżania i oddalania tras, selekcji tras. Ocena złożoności sterowania jest zatem wysoka. Komponent aplikacji działający w okularze AR przetwarza obiekty 2D i pozycjonuje je w sferze w czasie rzeczywistym (ocena 2). W zakresie czujników wykorzystuje IMU okulara oraz GPS otrzymane z telefonu komórkowego. Telefon ze względu na dużo wyższą jakość pomiaru lokalizacji GPS w porównaniu do GPS okularowego stał się dodatkowym czujnikiem z punktu widzenia okularów AR. Na telefonie funkcjonuje aplikacja kompanion, która jest głównym systemem przetwarzania i edycji danych. Podsumowując, architektura tego systemu to:
Około 20 usług API serwerów własnych i publicznych, z których korzysta aplikacja kompanion
Aplikacja kompanion (moduł główny)
Rest API modułu głównego przeznaczone do wysyłania danych do okularów (komunikacja poprzez Bluetooth)
Aplikacja okularowa czytająca API i wyświetlające te dane w kontekście IMU
System jest w ostatniej fazie testów. Założenia architektoniczne zostały już potwierdzone jako prawidłowe.
Podsumowanie
Prawidłowa alokacja komponentów aplikacji między dostępne urządzenia to podstawa tworzonych architektur oprogramowania. Determinuje ona liczbę integracji a te stanowią zwykle miejsca problematyczne i kosztowne w rozwoju każdego oprogramowania. Po zatwierdzeniu alokacji decydują już wybory technologiczne, a więc rodzaj języka programowania, komponenty możliwe do reużycia, komponenty własne do napisania. Decyzje te odbywają się w kontekście szczegółowych wymagań co do funkcjonalności produktu. Lokalizacja poszczególnych komponentów w architekturze sprzętowej wpływa na doświadczenia użytkownika tj. czas działania operacji w systemie, satysfakcję z funkcjonalności, synchronizacji danych w komponentach, awaryjność rozwiązania.
Okulary AR stanowią duże wyzwanie w projektowaniu architektury oprogramowania ze względu na swoją unikalną cechę wyświetlania obiektów przed oczami użytkownika przy jednoczesnej skromności metod sterowania i niewielkiej mocy obliczeniowej. Przedstawione w artykule reguły decyzyjne pozwalają unikać trudnych do naprawienia błędów w architekturach opartych o okulary AR.
Podsumowanie
Literatura
Marcin Januszka, Metoda wspomagania procesu projektowania i konstruowania z zastosowaniem technik ,,poszerzonej rzeczywistości'', Marek Wyleżoł (red.), 2012, ISBN 978-83-60759-22-6.
Andrzej Grabowski, Wykorzystanie współczesnych technik rzeczywistości wirtualnej i rozszerzonej do szkolenia pracowników, „Bezpieczeństwo Pracy: nauka i praktyka”, 4, 2012, s. 18-21.
Użyteczność i UX – Komunikacja człowiek-komputer, kck.wikidot.com [dostęp 2019-02-22].
Durrant-Whyte, H.; Bailey, T. (2006). "Simultaneous localization and mapping: part I". IEEE Robotics & Automation Magazine. 13 (2): 99–110. CiteSeerX 10.1.1.135.9810. doi:10.1109/mra.2006.1638022. ISSN 1070-9932.
Bailey, T.; Durrant-Whyte, H. (2006). "Simultaneous localization and mapping (SLAM): part II". IEEE Robotics & Automation Magazine. 13 (3): 108–117. doi:10.1109/mra.2006.1678144. ISSN 1070-9932.
Cadena, Cesar; Carlone, Luca; Carrillo, Henry; Latif, Yasir; Scaramuzza, Davide; Neira, Jose; Reid, Ian; Leonard, John J. (2016). "Past, Present, and Future of Simultaneous Localization and Mapping: Toward the Robust-Perception Age". IEEE Transactions on Robotics. 32 (6): 1309–1332. arXiv:1606.05830. Bibcode:2016arXiv160605830C. doi:10.1109/tro.2016.2624754. hdl:2440/107554. ISSN 1552-3098.
Perera, Samunda; Barnes, Dr.Nick; Zelinsky, Dr.Alexander (2014), Ikeuchi, Katsushi (ed.), "Exploration: Simultaneous Localization and Mapping (SLAM)", Computer Vision: A Reference Guide, Springer US, pp. 268–275, doi:10.1007/978-0-387-31439-6_280, ISBN 9780387314396
Serwis internetowy https://www.vuzix.com/
Serwis internetowy https://www.epson.com/
Serwis internetowy https://www.microsoft.com/
Serwis internetowy https://www.madgaze.com/
Serwis internetowy https://www.thirdeyegen.com/
Serwis internetowy https://www.google.com/glass/start/
Serwis internetowy https://www.bynorth.com/
Serwis internetowy https://www.nreal.ai/
Serwis internetowy http://www.0glass.cn/
Serwis internetowy https://www.realwear.com/
Tytuł i streszczenie w języku polskim:
Tytuł
Wyzwania architektoniczne w tworzeniu aplikacji na okulary Rzeczywistości Rozszerzonej
Streszczenie
Artykuł omawia klasyfikację okularów Rzeczywistości Rozszerzonej oraz podejście do tworzenia architektury aplikacyjnej na te urządzenia. Opisano kluczowe wymagania determinujące alokację komponentów tych aplikacji: złożoność sterowania, złożoność przetwarzania wyświetlanych informacji, zakres wykorzystywanych czujników. Zaproponowano reguły decyzyjne korzystające z pomiaru skali tych wymagań i przedstawiono przykładowe architektury oparte na tym podejściu.
Słowa kluczowe: AR, Augmented Reality, Rzeczywistość Rozszerzona, okulary AR, oprogramowanie