3 ROZŠÍŘENÁ REALITA NA NÁHLAVNÍCH PLATFORMÁCH 15 3 Rozšířená realita na náhlavních platformách V kategorii náhlavních souprav existuje velká řada projektů, prototypů a návrhů pro uplatnění v mnoha oborech. V této kapitole budou zmíněni někteří současní komerčně úspěšní zástupci. 3.1 Vojenská řešení Rozšířená realita má dlouhodobě své místo ve vojenském letectví. Piloti letounu F-35 Lightning II disponují helmou se systémy HMDS (Helmet Mounted Display Systems). Klasický heads-up displej s údaji o výšce, rychlosti, azimutu a dalšími důležitými informacemi není umístěn v prostoru kokpitu, nýbrž je vhodně projektován přímo do hledí helmy. Samotný pohled do skutečného světa je zprostředkován šesti infračervenými kamerami rozmístěnými na letadle. Záznam ze všech kamer je souvisle uspořádán vedle sebe tak, že pilot de facto vidí skrze trup letadla, čímž je zajištěn rozhled v rozmezí plných 360 a tím i perfektní přehled o situaci. (F-35 Lightning II, 2017) Součástí virtuálního overlay jsou mj. prostorové naváděcí systémy a rozpoznávání a tracking pozemních vozidel. Celkové vybavení helmy neslouží pouze pro informování pilota o situaci, ale funguje též jako rozhraní pro komunikaci s letounem, díky snímání pohybu hlavy a očí (Youtube, 2014). O tomto systému se dá spekulovat jako o současném vrcholu rozšířené reality co se týče přesnosti, funkcionality a užitné hodnoty. Je však třeba brát v potaz, že peněžní hodnota takové helmy se pohybuje kolem 400 tis. dolarů, nemluvě o tom, že k její funkci je potřeba kabelové připojení k letounu v ceně kolem 100 mil. dolarů (Wired, 2016). Obrázek 2: Vlevo helma HMDS pro letoun F-35 (F-35 Lightning II, 2017), vpravo pohled na zemský povrch z letounu F-35 přes hledí HMDS (Youtube, 2014). Ve vývoji jsou i systémy pro pěchotu, zejména pak QRF (Quick-Reaction Force). Moderní válečnictví stále nabírá na tempu a čas je důležitější než kdy předtím. Kritická rozhodnutí je třeba vykonat v nepohodlně krátkém čase a následky špatného rozhodování mohou být katastrofické (Livingston et al., 2011). Je proto nezbytné, aby zasahující jednotky měly co nejdříve k dispozici co nejpřesnější informace o si-

β 0.001, 0.05

y i = y i 1 + β (x i y i 1 ) π (π π π

( π) α x 1 x 2 c 1 c 2 α = π x 1 = α + c 1 x 2 = α + c 2 c 1 > 0 c 1 0 c 2 < 0 c 2 0 c 1 x 1 x 1 ( π, 0) x 1 π x 1 x 2 β β = 0.0125 y x

10.5 Virtuální overlay 37 10.5 Virtuální overlay Overlay sestává ze dvou hlavních částí: 3D kompas - Linie znázorňující horizont s bodem značícím sever. POIs - jednotlivé geografické body získané ze vstupních dat. 3D kompasu je dosaženo prostým děděním z třídy View a následným vykreslováním linie a bodu na svůj Canvas. POI sestává z Fragmentu obsahujícího layout pro zobrazení údajů o samotném POI (název, popis, vzdálenost), jak je vyobrazeno na obrázku 6. Tento Fragment je zabalen do vlastního FrameLayoutu s překrytým konstruktorem a vykreslovací metodou draw. Z hlediska rotačních a translačních úprav Canvasu POI i 3D kompasu je postup defacto stejný. Jediný rozdíl tkví v tom, že POI do výpočtů zahrnuje kromě orientace zařízení i okamžitý azimut k danému POI. Obrázek 6: Zobrazení POI nad náhledem kamery Po vytvoření View potřebujeme překrýt metodu ondraw v případě 3D kompasu a metodu draw u vlastního FrameLayoutu. Zde nejprve získáme zorné pole kamery. Připomeňme si, že metoda getcamera() v našem případě nevrací objekt android.hardware.camera, ale instanci třídy implementující námi definovaný CameraWrapper, jak je popsán výše a v příloze B. Pro výpočet translace potřebujeme získat hodnotu Field of View kamery zařízení.

x y

β

40 10 IMPLEMENTACE odstranění POI z databáze a virtuálního overlay. Obrázek 8: Vlevo POI zobrazen v rámci View Distance, uprostřed POI skryt mimo rámec View Distance, vpravo dialogové okno nastavení low-pass filtru 10.7 KML data Přístup ke KML datům je umožněn pomocí standardního Storage Access Frameworku, který je přístupný od API 19 (Android 4.4) (Android Developers, 2017). Tento framework umožňuje jednoduchý přístup k dokumentům, obrázkům a dalším souborům v zařízení. Vybraný soubor ve formátu KML je převeden do InputStream a dále je zpracován pomocí instance standardní třídy XmlPullParser, která implementuje parsovací funkcionalitu XMLPULL V1 API (Android Developers, 2017). Po inicializaci parseru a načtení souboru je na řadě samotné parsování, které lze přehledně implementovat pomocí jednoho while cyklu a switch klauzule. Náhled parsovací metody je k dipozici v příloze C. 10.8 Lokální databáze Při parsování KML souboru jsou průběžně ukládány jednotlivé POI do lokální SQLite databáze. Přestože můžeme implementovat vlastní řešení pomocí vlastních SQL příkazů a standardní třídy SQLiteOpenHelper (Android Developers, 2017), je podstatně pohodlnější využít jeden z mnoha dostupných 3rd party modulů pomocí kompilačního nástroje Gradle.