Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky

Bakalářská práce

Software pro rehabilitaci paže ve virtuální realitě

Plzeň 2020 Jakub Kodera Místo této strany bude zadání práce. Prohlášení

Prohlašuji, že jsem bakalářskou práci vypracoval samostatně a výhradně s použitím citovaných pramenů.

V Plzni dne 7. května 2020

Jakub Kodera Abstract

Arm rehabilitation software in virtual reality. The work is a part of a larger project, that is trying to achieve rehabilitation of the upper limb, in pa- tients suffering from a neurological disorder, in virtual reality. The result of this work is an application, that allows patients to perform rehabilitation exercises. The technologies used to develop the software are discussed here, mainly the HTC Vive system and the Unity game engine. The application is designed so that it can be further expanded. The application provides patients with a vizualization of the movement, that they are to perform. The therapeut obtains data and statistics of the exercises performed by the patient.

Abstrakt

Práce je součástí projektu, který se zabývá rehabilitací horní končetiny, u pacientů trpících neurologickou poruchou, ve virtuální realitě. Výsledkem této práce je aplikace umožňující provádět rehabilitačních cvičení. Jsou zde probírány technologie použité při vývoji softwaru. Zejména systém HTC Vive a herní engine Unity. Aplikace je navržena tak, aby ji bylo možné dále rozšiřovat. Aplikace poskytuje pacientům vizualizaci prováděného pohybu. Terapeut aplikací získá data a statistiky o cvičeních vykonaných pacientem. Obsah

1 Úvod7

2 Roztroušená skleróza mozkomíšní8 2.1 Průběh nemoci...... 8 2.1.1 Typy roztroušené sklerózy...... 10 2.2 Symptomy...... 11 2.3 Léčba...... 12 2.3.1 Rehabilitace...... 13

3 Virtuální realita 14 3.1 Obecně...... 14 3.1.1 Historie a současnost...... 15 3.1.2 Využití...... 16 3.2 Volba systému VR...... 17 3.3 HTC Vive...... 18 3.3.1 Vznik...... 18 3.3.2 Specifikace...... 19 3.3.3 Systém sledování zařízení...... 21

4 Unity 24 4.1 Obecně...... 24 4.1.1 Editor...... 25 4.1.2 Scény...... 26 4.1.3 Herní objekty...... 26 4.1.4 Skriptování...... 27 4.2 Animace...... 28 4.3 VR integrace...... 30

5 Software 31 5.1 Návrh...... 31 5.2 Možnosti softwaru...... 32 5.2.1 Použití HTC Vive...... 32 5.2.2 Role pacienta...... 33 5.2.3 Role terapeuta...... 35 5.3 Implementace...... 38 5.3.1 Uživatelské rozhraní...... 40

5 5.3.2 Cvičení...... 40 5.3.3 Tunel...... 46 5.3.4 Animace...... 47 5.3.5 Konfigurace...... 48 5.4 Testování...... 50 5.5 Nedostatky a potencionální budoucí rozšíření...... 51

6 Závěr 53

Seznam zkratek 54

Literatura 55

A Přílohy 58 A.1 Seznam obrázků...... 58 A.2 Uživatelská příručka...... 58 A.2.1 Sestavení...... 58 A.2.2 Spuštění...... 58 A.2.3 Binding trackerů...... 59 A.2.4 Definice vlastního pohybu...... 59 A.3 Obsah DVD...... 60

6 1 Úvod

Práce je součástí většího projektu, jehož cílem je umožnit provádění reha- bilitačních cvičení horní končetiny ve virtuální realitě. Práce je zaměřena na pacienty, kteří trpí nějakou neurologickou chorobou, která je v pohybech horní končetinou značně omezuje. Pacienti navštěvují rehabilitace, kde s po- mocí terapeuta provádějí pohyby a hry, které mají za účel jejich zdravotní stav zlepšit. Cílem této práce je vytvořit aplikaci, která pacientům umožní provádět tato cvičení ve virtuální realitě. Aplikace bude schopná pacientům prováděná cvičení vizualizovat ve virtuálním světě a terapeutům by měla poskytnout informace o pacientem vykonaných cvičeních. Při práci probíhala spolupráce s týmem Fakultní nemocnice Královské Vinohrady(FNKV), který se touto problematikou zabývá. Na základě této spolupráce probíhala tvorba specifikace a vlastností softwaru. Tato práce přímo staví na již hotové práci, jejímž výsledkem je modul, umožňující ana- lýzu pohybu v reálném čase [14]. Současně s touto prací probíhá vývoj dalších dvou prací [9][12], které rehabilitační aplikaci poskytují data o terapeutem předcvičených pohybech, na základě kterých proběhne vyhodnocování paci- entova pohybu. V práci bude nejprve probrána jedna z nejčastějších neurologických cho- rob, kterou pacienti trpí. Následně proběhne diskuze technologií použitých při vývoji aplikace. Nakonec bude popsána vlastní implementace rehabilitač- ního softwaru. V práci je postupně popsáno, jaké problémy bylo potřebné při její realizaci řešit.

7 2 Roztroušená skleróza mozkomíšní

Cílem této kapitoly je seznámit čtenáře s nemocí, pro jejíž rehabilitaci byl software primárně vytvářen. Roztroušená skleróza mozkomíšní (Sclerosis multiplex cerebrospinalis) je chronické onemocnění centrální nervové soustavy (mozku a míchy) [1]. V České republice se jedná o poměrně časté onemocnění, trpí jím přibližně 10000 až 13000 lidí [24], tzn. zhruba každý 1000, přičemž výskyt nemoci u žen je asi 2x-3x častější než u mužů [15]. Dodnes nelze jednoznačně říci co je příčinou vzniku nemoci. To má za důsledek, že jí nelze předejít. Její vývoj je dnes přičítán jak faktorům genetickým, tak faktorům zevního prostředí [1]. Na základě praxe a experimentů jsou známy mechanismy a spouštěče, které vedou k rozvinutí nemoci. Nemoc se typicky začne projevovat mezi 20.- 30. rokem života. Dosud nebyl nalezen lék, který by průběh nemoci zastavil úplně. Sama o sobě není smrtelná, ovšem jelikož se jedná o onemocnění celoživotní, může pacienta v určitých oblastech značně omezovat [5].

2.1 Průběh nemoci

Roztroušená skleróza, dále jenRS, se řadí mezi autoimunitní, demyielini- zační choroby [1]. Základní funkcí imunitního systému člověka je chránit tělo před infekcemi a napadání cizích, nebezpečných buněk. U autoimu- nitních onemocnění ovšem dochází k tomu, že buňky imunitního systému začnou napadat a ničit buňky tkání organismu. Takovýchto nemocí je celá řada, typicky se dělí podle toho jaký typ tkáně napadají [15]. PřiRS dochází k tomu, že T-lymfocyty, makrofágy a další bílé krvinky imunitního systému, začnou přecházet přes hematoencefalickou bariéru (přechod mezi vlásečni- cemi krevní soustavy a mozkové tkáně). Následně začnou považovat myelin za cizí a postupně napadají a ničí myelinové pochvy v bílé hmotě mozku a míchy, odtud název demyielinizační. Přičemž nelze jednoznačně určit, co tuto reakci imunitního systému způsobuje [1]. Myelinová pochva vytváří lipidový (tukový) obal okolo axonů, dlouhých výběžků neuronů (buňky nervové soustavy), které zajišťují přenos akčních potenciálů mezi jednotlivými buňkami. Pochva je přerušována Ranvierovými zářezy, viz obrázek 2.1. Myelin je v centrální nervové soustavě tvořen oligo-

8 Obrázek 2.1: Neuron - základní jednotka nervové soustavy1 dendrocyty a jeho účelem je chránit a vyživovat samotná nervová vlákna. Myelin také umožňuje přeskakování impulsů z jednoho Ranvierova zářezu na druhý, místo toho aby se vzruch musel šířit po celém vlákně, čímž šíření jednotlivých signálů značně urychluje [5]. Při rozpadu myelinových pochev dochází ke chronickému zánětu, a vzniká až několik nepravidelně rozmístěných ložisek, kterým se také říká plaky nebo jinak léze. Odtud také pochází název roztroušená skleróza, jelikož po ode- znění zánětu vznikají v místech postižení jizvy, řecké skleros znamená tuhý. Roztroušená protože ložiska mohou vznikat na různých místech mozku a mí- chy. Velikost ložisek může být různá, od milimetrů po centimetry [5]. V urči- tých případech jsou nervová vlákna schopna alespoň částečné reparace, tzv. remyelinizace [1]. Ovšem postupem času dochází k vyčerpání regeneračních schopností oligodendrocytů. Důsledkem toho sice dojde k obnovení vzruchů, jejich vedení je ale pomalejší [5]. V pozdějších, někdy ale i v časných, fázích nemoci může také docházet k úplnému zničení samotných axonů, v takových to případech již není možná obnova funkce dané buňky [1]. Vlastní průběh nemoci je poměrně různorodý a nevypočitatelný, může se

1https://velkaencyklopedie.estranky.cz/fotoalbum/biologie/ biologie-lidske-telo/nervova-soustava/neuron.-.html

9 u každého pacienta lišit [5]. Typickým průběhem nemoci je střídání atak (re- lapsů) a remisí. Ataka je období nemoci, kdy dochází k rozvoji neurologické dysfunkce, tedy období, kdy se buď zhoršují stávající příznaky, nebo dochází k rozvinutí nových. Po atakách následuje období, kdy dochází k úplnému, nebo alespoň částečnému, uzdravení (remisi). Pacient se cítí dobře a neuro- logický nález je také v normě [1]. U některých pacientů dochází k tomu, že první záchvat zanechá trvalé následky, ale nemoc se dále nezhoršuje, nebo může od prvního záchvatu docházet k neustálému zhoršování. Po první atace typicky dochází k dalším relapsům po dvou letech, ovšem může nastat i dříve, ale jsou i případy, kdy se další ataka neprojeví nikdy [5]. První atace nejčas- těji předchází nějaký negativní vnější faktor, například virové onemocnění, psychický a fyzický stres, ale může se projevit i zcela náhle [1]. Podle prů- běhu se RS dělí na benigní a maligní. Benigní forma se projevuje jen malým množstvím atak s nepatrnými následky, maligní typ je charakterizován těž- kými záchvaty s rychlým rozvojem invalidity [5].

2.1.1 Typy roztroušené sklerózy Na základě průběhu nemoci, popsanému výše, se pak nemoc dělí do čtyř kategorií:

• Relaps-remitentní — jedná se o nejběžnější typRS, vyskytuje se u většiny (~85%) pacientů v počátcích onemocnění [16]. Mohou se vy- skytnout spontánní remise, kdy je stav nemocného stabilní, bez jaké- koliv léčby. To lze s největší pravděpodobností připsat procesu remye- linizace [5]. Období trvá přibližně od 5 do 15let. Probíhá zde zánětlivý proces, který je stále ovlivnitelný léky. Zhruba polovina nemocných přejde do deseti let z formy relaps–remitentní do chronicko–progresivní [16].

• Chronicko-progresivní — neboli sekundárně progresivní. V tomto období dochází ke snížení zánětlivé činnosti a naopak růstu neurode- generace.Typicky organismus v této fázi již vyčerpal schopnost remye- linizace a proto zde další poškození způsobené zánětem nese trvalé následky. Ataky proto nebývají tak nápadné a spíše dochází k postup- nému nárůstu invalidity až imobilizaci nemocného. Léčba léky už zde přestává být efektivní a kvalita života pacienta záleží především na jeho životosprávě a rehabilitacích [16].

• Primárně-progresivní — touto formou onemocnění trpí přibližně 10% pacientů, převážně se jedná o muže pozdního věku (40–50 let).

10 U tohoto typu jsou remise velmi málo časté, a tak dochází již od po- čátku onemocnění k pozvolnému nárůstu invalidity [5]. Svým průbě- hem se zcela liší od relaps-remitentní formy, převažuje neurodegenerace a úbytek oligodendrocytů nad zánětlivou činností [16].

• Relabující-progresivní — nejméně často vyskytující se forma. Na druhou stranu také nejhorší ze všech popsaných. Charakterizuje se tím, že po atakách nedochází u pacientů k žádnému zlepšení stavu [5]. Nachází se zde zvýšená jak zánětlivá tak neurodegenerační činnost, které vedou k invaliditě již během pár let od počátku onemocnění [16].

2.2 Symptomy

Příznaky s sebou přináší řadu poruch, které korespondují s konkrétním mís- tem demyelinizace v centrální nervové soustavě. Kromě místa postižení je projev choroby taky částečně ovlivněn velikostí zánětu. Typicky jsou první symptomy onemocnění mírného charakteru, které jsou dosti nespecifické, např. únava, deprese nebo bolesti končetin, pacienti jim nevěnují větší po- zornost, a proto je sdělují lékařům až po delší době [16].

• Senzitivní poruchy — jsou poruchy citlivosti ve smyslu parestézie a dysestésie v různých částí těla především v horních a dolních konče- tinách. Jedná se o nepříjemný pocit brnění, píchání, svědění či pálení kůže. Tyto symptomy se vyskytují zhruba u poloviny nemocných [1] a často jsou přehlíženy jelikož po pár dnech až týdnech odezní [16].

• Poruchy motoriky — jedná se o nejvýznamnější projevyRS, způ- sobené poruchou pyramidové dráhy2 jejíž funkcí je volní3 a především jemná motorika končetin [16]. Poruchy tohoto typu se typicky nepro- jevují na začátku onemocnění, ale až v pozdější fázi [1]. Jedná se pře- devším o parézy (obrny) a spasticitu (porucha způsobená zvýšením to- nických napínacích reflexů, závislých na rychlosti protažení svalu, tedy čím rychleji je prováděn napínací pohyb, tím větší je kladený odpor příslušných svalových segmentů [24]). Poruchy mohou postihnout kte- roukoliv z končetin (i více najednou), nejčastěji se postižení objevuje u dolních končetin [16]. Časté jsou problémy při chůzi, kdy si pacient není jistý vlastní rovnováhou [24]. Pacienti mohou pociťovat svalovou slabost a zvýšení svalového napětí, které vedou až ke křečím, problémy

2Nervová dráha vedoucí z motorické kůry mozku a končící v míšních segmentech. 3Volní motorika je schopnost organismu provádět vůlí cílené pohyby.

11 s ohybem končetin nebo svalový třes. Projevy se mohou v pozdní fázi různě kombinovat, což je nejčastější příčinou vedoucí k invaliditě da- ného nemocného. Při nečinnosti svalů se projevy pouze zhoršují, dají se ovšem ovlivnit léčbou, především rehabilitacemi [16].

• Únava — jeden z nejběžněji vyskytujících se příznaků neurologických onemocnění, který výrazně omezuje společenský život a vykonávání běžných denních aktivit [24]. Jedná se o velmi obtěžující nespecifický symptom, kterým trpí asi 95% osob sRS. U každého se může pro- jevovat trochu jinak. Je pociťována jako nedostatek síly, pocit vyčer- pání bez odpovídající fyzické zátěže a ztráta energie [16]. Na vzniku únavy se podílí například svalová slabost, bolest, různá onemocnění, psychický stav nebo poruchy spánku [24].

• Psychické potíže — jedná se o změny afektivity a to zejména o de- prese nebo někdy o euforie. Intelekt pacienta nebývá nemocí ovlivněn [1]. Depresivní syndromy se vyskytují zhruba u poloviny pacientů a je prokázáno, že u takovýchto pacientů je riziko sebevraždy asi 7x větší než u lidí zdravých, symptomy by se tedy neměly přehlížet. Symptomy se projevují jako nekontrolovatelný pláč, nebo v případě euforie smích. Pacienti pociťují strach, úzkost a sebelítost, což vede ke zhoršení kva- lity života, jelikož mají větší tendence k sociální izolaci, narušování rodinných vztahů. U některých pacientů může také docházet ke zhor- šení kognitivních (paměť, myšlení, koncentrace. . . ) funkcí [16].

• Další — mezi další typické příznaky patří například močové potíže, mozečkové poruchy (špatná koordinace, skandovaná řeč. . . ). Pro více informací o těchto a dalších projevech viz [1], [16].

2.3 Léčba

Jak již bylo zmíněno roztroušenou sklerózu není možné zcela vyléčit. U řady pacientů lze ovlivnit průběh nemoci. Léčebný proces se pak rozlišuje na léčbu akutního stavu, kdy dochází u pacienta k relapsům (zhoršení pří- znaků), a na dlouhodobou léčbu, kdy je snaha snížit počet atak a zpomalit rozvoj nemoci [16]. Dále zde léčebné zásahy pro léčbu symptomů a atak popisovat neubudu. Jedná se převážně o podávání léků pacientům, ať už za účelem zlepšení jejich aktuálního stavu, či prevenci jeho zhoršení. Pro více informací na toto téma odkážu na [1] a [16]. Popíši zde proces rehabilitací, který má v rámci kontextu práce větší význam.

12 2.3.1 Rehabilitace „Rehabilitace využívá multidisciplinárních strategií ke zvýšení funkční nezá- vislosti, prevenci komplikací a zlepšení kvality života nemocných. Jde o ak- tivní proces, který pomáhá lidem k zotavení, k zachování optimální fyzické, smyslové, intelektové, psychické a sociální úrovně funkcí a k dosažení co nejvyšší úrovně nezávislosti navzdory omezení, které onemocnění způsobuje [24].“ Rehabilitační postup vychází ze stanovené diagnózy pacienta. Nejprve se určí základní onemocnění, po němž následuje analýza problému reha- bilitačním týmem (lékař, fyzioterapeut, psycholog. . . ) pro stanovení priorit léčby. Léčba je postupně modifikována a hodnocena [24]. Vzhledem k variabi- litě onemocnění je pro každého pacienta vytvořen individuální rehabilitační program, při kterém se mimo jiné bere v potaz i fáze, ve které se nemocný nachází [16]. Častým problémem bývají depresivní syndromy. Jelikož člověk trpící de- presemi není schopen spolupracovat na rehabilitačním procesu, je třeba je včas identifikovat a léčit. Samotné rehabilitace mají poměrně velký vliv na ovlivnění psychiky, a to především rehabilitace individuální, jelikož je snaha vytvářet klidné a bezpečné prostředí. Terapeuti s nemocnými vedou rozho- vor, věnují jim čas a snaží se je nutit na sobě pracovat a zlepšovat se, což vede k lepšímu psychickému stavu [24]. Rehabilitace jsou zaměřeny především na spasticitu, zvýšení svalové síly a poruchu koordinace4 [16]. U těchto poruch nemocný váhá, jak má vlastně daný pohyb udělat a dochází tedy ke zpomalení již naučených činností a zhoršení obratnosti. Cílem rehabilitace je tedy motorické řízení a učení. Nej- prve dojde k plánování pohybové sekvence a po prvním úspěšném výkonu je snaha o naučení dané dovednosti opakujícím se tréninkem, kterým dochází ke zdokonalování provedení pohybu (přesnost, rychlost, plynulost) [24]. Pacient s terapeutem provádí několik cvičení (pohybů). Nejprve je paci- entovi vysvětlen princip řízení daného pohybu a princip jeho terapie. Násle- duje definice pohybu a nastavení pacienta do výchozí polohy pro vykonání. Samotný pohyb pak bývá doprovázen s pomocí terapeuta, který pacienta navádí a pomáhá k tomu, aby byl pohyb vykonáván korektně. Je důležité, aby pohyby byly vykonávány správně, jelikož při špatném provádění cvičení může dojít spíše k prohloubení symptomů [24]. Mezi jednotlivá cvičení patří například správné sezení, zvedání se ze sedu do stoje, chůze, diagonály horních končetin, kreslení spirál nebo špetkový úchop.

4Jedná se tedy o poruchu především motorické.

13 3 Virtuální realita

3.1 Obecně

Virtuální realita, dále takéVR, je trojrozměrné počítačem generované pro- středí, ve kterém se uživatel může volně pohybovat a interagovat s ním. Jedná se tedy o jedno z dalších rozhraní mezi člověkem a počítačem. Na roz- díl od jiných rozhraní, uživatel veVR se stane přímo součástí vygenerova- ného světa. Uživatelé jsou tak přímo vnořeni do vymodelovaného prostředí, ve kterém mají možnost manipulovat s ostatními 3D objekty a ovlivňovat tím dění kolem sebe [2]. Co odlišujeVR od ostatních počítačových rozhraní je snaha úplně izolo- vat uživatele od okolního světa. Cílem je přesvědčit mozek, že vjemy působící z virtuálního prostřední na naše smysly (zrak, sluch, čich, hmat ale i napří- klad rovnováha) jsou skutečné, přestože nejsou [17]. Zde však narážíme na jistou technologickou bariéru, neboť i když jsou dnešní technologie schopny poskytnout věrohodný obraz a zvuk, může dojít ke konfliktu smyslů. Zrak mozku předává informace o tom, že ve virtuálním světě dochází ke zrychlení, ale ostatní smysly, především centrum rovnováhy vnitřního ucha a svalový vzruch, mozku naopak posílají signály o tom, že ne. Tomuto efektu se říká motion sickness a typicky způsobuje nevolnost, závratě nebo únavu [13]. Jak působíme a ovlivňujeme virtuální realitu závisí hlavně na platformě. Některé zatím vydané VR brýle byla navržena k používání v sedě, a pohyb je umožněn ovladači, stejně jako u PC či konzole. Typicky je uživateli umož- něna teleportace ve vykresleném okolí nebo pohyb pomocí tlačítek daného ovladače. Existují ale již zařízení pro volný pohyb. Uživatel pak typicky de- finuje prostor ve kterém se bude pohybovat. Velikost takového prostoru je pak samozřejmě limitována samotným rozměrem místnosti a také systémem, který daná platforma používá pro sledování pohybu. Jak tomu u nových technologií bývá (a virtuální realita stále ještě je re- lativně nová, přestože už tu s námi pár let je, viz sekce 3.1.1), problémem pro běžného uživatele může pořád být cenová nedostupnost. Jelikož nejčas- těji je k samotné VR sadě zapotřebí dostatečně výkonný počítač nebo herní konzole, může se cena kompletní sady pro virtuální realitu vyšplhat až na desítky tisíc korun.

14 3.1.1 Historie a současnost Historie Přestože by se mohlo zdát, žeVR je poměrně nová technologie, její počátky sahají až do šedesátých let minulého století. Jako první koncept virtuální reality tak jak ji známe dnes, můžeme považovat tzv. „Divadlo zážitků“. Jednalo se o prototyp přístroje Sensorama umožňující promítání krátkých filmů, při kterém mohl divák kromě obrazu a zvuku vnímat i vůni. V roce 1968 vznikl první zobrazovací systém, který byl připevněn na hlavu. Jednalo se o poměrně primitivní uživatelské rozhraní a vizuální zážitek. Hardware tohoto systému byl tak těžký, že musel být přimontován ke stropu [7]. V roce 1979 vyvinul Eric Howlett systém LEEP (Large Expanse Ex- tra Perspective). Systém vytvořil stereoskopický obraz s dostatečně širokým zorným polem, aby vytvořil přesvědčivý pocit prostoru. LEEP byl jeden z prvních systémů, který připomínal moderní soupravu proVR, tak jak ji známe dnes. Pojem virtuální realita byl popularizován v 80. letech Jaronem Lanierem, který je považován za jednoho z průkopníkůVR. Jeho společnost vytvořila produkty jako „DataGlove“ rukavice pro sledování dlaní, nebo „EyePhone“, což bylVR headset [7]. Na počátku 90. let vyvinula NASA systém VIEW (Virtual Interactive Environment Workstation), navazující na systém LEEP, vytvořený za úče- lem virtuálního tréninku astronautů. Tento systém využíval zpracování bi- naurálního 3D zvuku1 v reálném čase. NASA také využila VR pro řízení robotů na Marsu v předpokládaném reálném čase navzdory zpoždění sig- nálu mezi planetami. V roce 1991 vytvořila skupina Virtuality stejnojmenný VR systém pro hraní video her. Jednalo se o první masově vyráběné zábavní VR stroje. Headset v reálném čase zobrazoval 3D stereoskopické2 obrázky. Bylo také možné propojit více strojů po síti a hrát tak hry pro více hráčů. Ve stejném roce byl také vydán Sega VR headset. Jednalo se o LCD head- set se sluchátky a senzory, které umožňovaly sledovat jeho polohu. V roce 1992 bylo vynalezeno prostředí CAVE (Cave Automatic Virtual Environ- ment). Jednalo se o tmavou krychlovou místnost, na jejíž stěny se promítalo pomocí zadní projekce (technika, kdy je projektor schovaný za plátnem a neruší tak uživatele). Tento systém má každopádně řadu nevýhod, největší z nich jeho nepřenositelnost, a tak v komerčním světě příliš neujal [7].

1Zvuk, který je do levého a pravého ucha vysílán s mírně odlišnou frekvencí. 2Technika vytvoření iluze hloubky.

15 VR dnes Největší posun ve vývoji ovšem technologie zaznamenala v posledním dese- tiletí. Vzhledem k tomu, že člověk ke vnímání okolí používá asi ze 70% zrak a 20% sluch nebude překvapením, že současné systémy se zaměřily právě na tyto smysly. Faktem je, že člověk reaguje na zvukové podněty rychleji než na podněty vizuální. Pro skutečně pohlcující virtuální zážitek je potřeba zvuky prostředí a prostoru nezanedbat. Přestože audio-vizuální podněty hrají ve VR největší roli, výzkum a vývoj se zabývá i ostatními smysly. Například všesměrové trenažéry, umožňující uživateli pocit, že se skutečně pohybuje ve virtuálním světě, nebo technologie dotykové zpětné vazby [2]. Virtuální realitu dnešní generace lze datovat od roku 2010, kdy se VR začalo znovu dostávat do povědomí širší veřejnosti. Především to bylo díky zařízení Oculus Rift, které vzniklo jako prototyp Palmera Luckeyho a při- neslo s sebou 90 stupňové zorné pole, kterým žádné dosavadní systémy ne- disponovaly. Dalším pokrokem lze považovat průlom v oblasti tzv. displejů s nízkou odezvou objevené a volně sdílené společností Valve Corporation. Displeje s nízkou odezvou jsou podstatnou součástí dnešních zařízení z dů- vodu vyšší ostrosti výsledného obrazu a snížení vlivu motion sickness [7]. V následujících letech se již objevují další zařízení, kde za zmínku stojí pře- devším HTC Vive, Playstation VR, Google Daydream View. V neposlední řadě nový Oculus Quest nebo méně známý Pimax, které nabízejí sledování dlaní bez použití dodatečných ovladačů či rukavicí [2]. Dnešní zařízení pro virtuální realitu typicky sestávají ze dvou částí, kte- rými jsou sledované objekty (HMD, ovladače. . . ) a zařízení, které sleduje polohu a orientaci těchto objektů viz 3.1[2]. HMD (Head-mounted display) je důležité zařízení, které zprostředkovává uživateli audio-vizuální vstup do světa VR. Jedná se o nejvíce rozeznatelnou částVR. Je to headset nebo jakési brýle, typicky se skládající ze dvou displejů, čoček a v některých pří- padech i poloprůhledných zrcadel. Čočky, případně i zrcadla, se používají k roztažení zobrazovaného obrazu, který musí pokrývat co největší zorné pole. Některé typy headsetů používají místo vlastního displeje mobilní tele- fon například Samsung Gear VR. Helma je nejčastěji připojena k externímu zařízení (počítač nebo konzole), které zpracovává výsledný obraz [21]. Dnes již existují headsety, které jsou schopné fungovat jako samostatná jednotka, například Oculus Quest.

3.1.2 Využití Virtuální realita se v dnešní době používá v mnoha odvětvích. Největší vý- hodouVR je, že dění ve virtuální realitě nemá trvalé následky na realitu

16 skutečnou, tzn. tam kde je příliš nebezpečné, nákladné nebo nepraktické dě- lat něco ve skutečnosti, je virtuální realita odpovědí. Největším odvětvím které využíváVR je bezpochyby zábavní průmysl. Především herní prů- mysl značně dominuje, dnes již není neobvyklé, že nově vydaná hra, kromě možností hraní pomocí herního počítače či konzole, přináší také podporu proVR. Do zábavního průmyslu ovšem patří také například interaktivní film, či různé typy zážitků jako je prohlídka památek nebo chůze na Marsu. Virtuální realita má také řadu aplikací v serióznějších oborech. Využívá se pro vizualizaci vědeckých informací ve fyzice nebo chemii. Má své využití i ve vojenských simulacích či vzdělání. V neposlední řadě se takéVR pou- žívá v lékařství, kde například chirurgové mohou trénovat provádění operací, nebo provádět diagnostiku. Koneckonců aplikace tohoto projektu vznikla za účelem experimentální rehabilitační léčby. Jak se náklady na virtuální realitu snižují a postupně se stává běžnější, můžeme předpokládat, že se do popředí dostanou vážnější použití a prav- děpodobně budou vznikat nové, dosud neprozkoumané aplikace. Virtuální realita by mohla podstatně změnit způsob, jakým propojujeme naše digitální technologie [7][17].

3.2 Volba systému VR

Dnes se již na trhu vyskytuje spousta headsetů pro virtuální realitu. Při výběru jaký z nich použít pro realizaci projektu, poměrně suverénně vyhrál VR headset HTC Vive, viz sekce 3.3. Důvodů pro zvolení této soupravy bylo hned několik. Hlavním důvodem proč byl Vive zvolen byl fakt, že umožňuje sledovat zařízení nazývaná trackery, viz sekce 3.3.2. Valná většina ostatních systémů používá pouze headset a ovladače. To je ovšem k řešení problému pro rehabilitační cvičení nedostačující, jelikož kromě polohy a orientace horní končetiny3 hraje svoji důležitou roli i poloha a natočení hrudníku. Dalším rozhodujícím faktorem byla velmi jednoduchá integrace s herním enginem Unity, viz sekce 4.3. Nemalou roli sehrál i fakt, že HTC Vive byl již před začátkem projektu dostupný jak na Fakultě aplikovaných věd Západočeské univerzity, tak ve Fakultní nemocnici Královské Vinohrady. Kromě zvole- ného headsetu jsme v počátcích také experimentovali se senzory. Senzory jsou v tomto případě myšleny dva, a to akcelerometr a gyroskop. Gyroskop je zařízení, které využívá gravitaci Země k určení orientace. Ak- celerometr je kompaktní zařízení určené k měření zrychlení. Když objekt,

3Ovladačem by se dala sledovat pouze pozice dlaně/zápěstí, což by stejně nestačilo jelikož je třeba sledovat i polohu paže.

17 do kterého je integrován, přechází z klidového stavu do jakékoli rychlosti, je akcelerometr navržen tak, aby reagoval na vibrace spojené s takovým pohybem [10]. Většina dnešních mobilních zařízení má v sobě tyto senzory zabudované. Pro práci se senzory vznikla aplikace4, která s pomocí android aplikace Sensorstream IMU+GPS5 zapisovala data z těchto senzorů do sou- borů. Tím jsme získali orientaci a zrychlení mobilního telefonu v konkrétním čase. K řešení problému sledování pohybu horní končetiny ovšem potřebu- jeme zjistit její polohu a orientaci. Polohu je možno ze zrychlení získat jeho dvojí integrací, ovšem z důsledků integrace poměrně nepřesnou. Telefony se také projevily jako poměrně nepraktické pro upevnění na ruku, a tak bylo pro zjednodušení práce od tohoto nápadu odstoupeno. Výhodou senzorů by každopádně bylo odstínění od konkrétníhoVR headsetu, jelikož by odpadla závislost na HTC Vive trackerech. Pro bližší informace o senzorech, více viz bakalářská práce [9].

3.3 HTC Vive

3.3.1 Vznik HTC Vive byl vyvinut společností HTC, zaměřena na výrobu mobilních za- řízení, a společností Valve, zaměřena především na vývoj počítačových her. Předtím než Vive vůbec vznikl, obě společnosti začaly zkoumat virtuální realitu samostatně. Už v roce 2012, kdy Oculus Rift odstartoval novou ge- neraciVR headsetů, Valve pracoval na svém vlastním řešení. Vnikly první prototypy sestávající se z HMD, kamery a AprilTags6 pro sledování polohy zařízení. Hlavním problémem, na který společnost narazila, byl fakt, že ob- raz, který displej zobrazoval, byl rozmazaný. Valve bylo jasné, že pro hraní her je nutné, aby displej zobrazoval obraz ostřeji a s nízkou odezvou. Valve sice měla základní fungující řešení, ale vlastní headset v plánu neměla. Nejprve bylo snahou společnosti spolupracovat s Oculusem. Jejich spolupráce ovšem z neznámých důvodů dlouho nevydržela, s největší prav- děpodobností došlo k odlišným vizím jak by mělaVR vypadat. Společnosti HTCVR velmi připomínalo počátky chytrých telefonů a bylo jasné, že to bude nové technologické médium a chtěla být v popředí jeho vývoje. A tak došlo ke schůzce mezi Valve a HTC, která byla očividně úspěšnější.

4Zdrojové kódy dostupné na https://bitbucket.org/frankkuba/vr/src/master/. 5Aplikace volně ke stažení na https://play.google.com/store/apps/details?id= de.lorenz_fenster.sensorstreamgps. Umožňuje sběr dat ze senzorů a pomocí UDP protokolu je po síti posílá na konkrétního klienta. 6Čárové kódy, připomínající jednodušší QR kódy.

18 Práce na první vývojářské edici headsetu začala hned po podepsání do- hody. Vývoj probíhal iteračně, postupně byly probírány návrhy a nápady jak by měl headset vypadat. Bylo odstoupeno od nepraktického systému sledo- vání založeného na AprilTags a vznikly dvě alternativy tzv. dot tracking a laser tracking. U systému dot tracking jsou headset a ovladače pokryté „tečkami“, kamera pak zaznamenává snímky, ze kterých se následně pomocí strojového vidění určí poloha teček a tedy poloha jednotlivých zařízení. Laser tracking se projevilo jako přesnější, a tak probíhaly práce na prototypování tohoto systému. Více o tom jak tento systém funguje, viz sekce 3.3.3. Zhruba šest měsíců po začátcích spolupráce bylo pozváno pár vývojářů do Valve kanceláří, aby si Vive vyzkoušeli. Na základě odezvy byla vydána první verze na konci roku 2014 pro menší skupinu zákazníků. V roce 2015 byl Vive poprvé představen širší společnosti na MWC (světová mobilní konfe- rence) v Barceloně. O rok později pak na stejné konferenci byla vydána první verze pro veřejnost, která od svého prvního představení přinesla pár převážně estetických změn (headset byl více stabilní, senzory byly zakryté. . . ) [18].

3.3.2 Specifikace Základní balení HTC Vive obsahuje HMD, dva ovladače a dvě základní sta- nice. Cena tohoto balíčku je 599$. Kromě základních komponent je možno dokoupit další příslušenství, zde zmíním především trackery a adaptér pro bezdrátové připojení HMD, umožňující volnější pohyb bez omezujících ka- belů [6]. Základní souprava s trackery, viz obrázek 3.1.

HMD HMD má obnovovací frekvenci 90Hz a zorné pole 110 stupňů. Zařízení po- užívá dva OLED panely s celkovým rozlišením 2160 × 1200 (na každé oko tedy 1080 × 1200)[8]. Z obnovovací frekvence vyplývá, že Vive běží na 90FPS(Frames Per Second, neboli počet snímků za sekundu). Skutečný počet FPS pak je samo- zřejmě ovlivněn výkonem a zatížením především grafické karty počítače, ke kterému je Vive připojen. V případě větší zátěže a tedy poklesu FPS pou- žívá systém techniku tzv. interleaved reprojection. To znamená, že za účelem zachování plynulosti vykreslovaného obrazu je počet snímků za sekundu li- mitován na 45 a je tedy vykreslován pouze každý druhý snímek. Později byla přidána technologie tzv. asynchronous reprojection. Ta se aktivuje v případě nižšího poklesu FPS. Funguje tak, že se vezme předchozí snímek, který se na základě aktuálních dat orientace příslušně otočí a posune a následně je

19 Obrázek 3.1: Komponenty pro virtuální realitu technologie HTC Vive7 zobrazen. Výsledkem je tak plynulejší a příjemnější obraz než při interleaved reprojection [3]. Vive používá Fresnelovy čočky, vzdálenost těchto čoček je možné upravit pro dosažení co nejlepší ostrosti obrazu. Vzadu se nachází tzv. Link Box, přes který je headset pomocí USB a HDMI kabelu připojen k počítači. Vpředu headsetu se nachází kamera, která uživateli umožňuje sledovat jeho okolí, aniž by musel headset sundat. Součástí headsetu není souprava pro audio, každopádně se zde nachází 3,5mm jack konektor pro připojení externích sluchátek. Na headsetu jsou infračervené senzory, které detekují světelné a laserové paprsky základních stanic a určují jeho aktuální polohu a orientaci v prostoru, viz sekce 3.3.3. Mezi další senzory patří G-senzor, gyroskop a přibližovací senzor [8].

Ovladače Ovladače disponují trigger tlačítkem na spodní straně, dvěma tlačítky na bocích, dvěma systémovými tlačítky na vrchu, mezi nimiž se nachází trac- kpad. Ovladače jsou zároveň schopny poskytovat zpětnou vazbu v podobě vibrací. Jsou bezdrátové a podobně jako headset mají několik senzorů pro detekci jejich polohy a orientace [8].

7https://static.turbosquid.com/Preview/2017/09/02__14_05_49/HTC_Vive_ set_01.jpg4F083E2C-EA62-415B-BF6B-D43229B2402DZoom.jpg

20 Základní stanice Základní stanice se typicky připevňují na zeď do výšky alespoň dvou metrů. Pro správnou funkčnost by na sebe obě stanice měly „vidět“, respektive by mezi nimi neměla být žádná překážka. Pokud tomu tak není, je nutné pro- pojit je synchronizačním kabelem. Samotné stanice s počítačem vůbec neko- munikují a jsou pouze připojeny k napájení. Dokáží snímat 360-stupňovitý pohyb brýlí, ovladačů a trackerů v prostoru až 15m2. Uživatel se může pohy- bovat a orientovat kdekoliv v dosahu stanic. Umožňují takzvanou full-room experience spočívající ve volném fyzickém pohybu ve zvoleném prostoru. Po- kud by se uživatel dostal na okraj daného prostoru, je mu v rámci bezpečnosti zobrazena ve virtuálním světě zeď indikující tuto skutečnost [8].

Trackery Trackery obsahují, podobně jako headsetu a ovladače, senzory. Je možné je připevnit na libovolný objekt či část těla, za účelem snímání jeho polohy či orientace. Pro zajištění sledování trackerů, musí být pro každý tracker k počítači připojen tzv. dongle8. Trackery hrají v rámci našeho projektu důležitou roli, jelikož je díky nim zajištěno sledování hned několika objektů: horní končetiny, hrudníku a židle.

3.3.3 Systém sledování zařízení Na rozdíl od většiny ostatních dosavadních systémů HTC Vive ke sledování pozice a orientace jednotlivých objektů (HMD, ovladač, trackery, viz sekce 3.3.2) nepoužívá kamery ani strojové vidění. Systém sledování zařízení se u Vive nazývá SteamVR Lighthouse [11]. SteamVR je API(Application Programming Interface, neboli progra- mové rozhraní), které komunikuje se samotným hardware systému Vive a poskytuje vývojářům funkce, které mohou používat pro práci se systémem. Jedná se tedy o vrstvu mezi hardware a samotným software aplikace, která s HTC Vive pracuje. API je vyvíjeno společností Valve a je integrováno do služby Steam. Základní jednotkou Lighthouse sledování je tzv. base station, neboli zá- kladní stanice, viz sekce 3.3.2. Tyto stanice v sobě mají panel s LED diody a dva rotory, jeden umístěný horizontálně a jeden vertikálně, viz obrázek 3.2.

8https://www.vive.com/us/support/wireless-tracker/category_howto/ using-the-dongle.html 9https://www.vrfocus.com/wp-content/uploads/2015/06/ LighthouseBaseStation_1.jpg

21 Obrázek 3.2: Náhled do struktury základní stanice HTC Vive9

Stanice pak provádí následující sekvenci. Nejprve jsou za pomocí diod do prostoru vyslány infračervené paprsky, sloužící k synchronizaci. Sledovaná zařízení, pokrytá četnými foto senzory, tyto paprsky zachytí a odstartují si interní časovač. Následně proběhne rotace horizontálního (na obrázku 3.2 spodního) rotoru, který do prostoru začne vyzařovat laserové paprsky zleva doprava tzn. ve vertikální rovině10. Foto senzor zařízení laserový paprsek zaznamená a zastaví interní časovač. Jelikož se rotory otáčí s konstantní rychlostí a je tedy známá doba otočení zleva doprava je výsledný vertikální úhel senzoru k dané stanici dán vztahem čas_dopadu_laseru y = · FOV celkový_čas_otáčky kde čas_dopadu_laseru je uplynulá doba, od které byl senzorem zazname- nán synchronizační puls do zasažení laserem a celkový_čas_otáčky je 8,3 milisekund. FOV (Field Of View) je pak zorné pole11 základní stanice. Stej- ným principem pak proběhne synchronizace a otočení vertikálního rotoru,

10Vzhledem k tomu, že stanice nemají zorné pole o velikosti 180 stupňů, jsou nejčastěji nakloněny směrem do herního prostoru. Z toho vyplývá, že i samotné roviny, které stanice pokrývá, jsou nakloněné. 11Zorné pole stanic HTC Vive je na základě https://www.vive.com/eu/support/ vive/category_howto/tips-for-setting-up-the-base-stations.html 120 stupňů.

22 pro zjištění horizontálních úhlů senzorů k základní stanici12. Tuto sekvenci stanice provádí s frekvencí 60Hz [23][4][22]. Vizualizaci toho, jak sekvence probíhá je možno vidět na [11]. Data ze senzorů jsou odeslána počítači, kde je proveden samotný výpočet polohy a orientace daného objektu. Jelikož je jeden sledovaný objekt pokryt větším množstvím senzorů (v řádu desítek) a typicky je jich paprsky zasaženo více, lze na základě znalosti umístění daných senzorů na objektu zjistit jeho polohu a orientaci vůči základní stanici. Jedná se o triangulační problém [23][4]. Další možností by bylo přidání druhé stanice, typicky se používají sta- nice dvě, kde druhá je přidána hlavně za účelem redundance a ne přesnosti, viz dále. Je-li více senzorů, tak stačí stanice jedna, viz předchozí odstavec. Stanice paprsky pokrývá dvě roviny, vertikální a horizontální. Průsečíkem těchto rovin vznikne přímka (vektor), na které daný senzor leží. Přidá-li se druhá stanice, jsou přímky dvě. Průsečíkem obou přímek lze následně získat polohu daného senzoru13 [23][4]. Vive primárně pro získání pozice používá IMU(Inertial measurement unit) zařízení využívající akcelerometr a gyroskop, viz sekce 3.2. Výše po- psaný systém je založen především na časování, a jelikož mezi jednotlivými synchronizačními pulzy je určitá časová prodleva, pohybuje-li se daný objekt příliš rychle, byla by do jeho snímané pozice zanesena značná chyba. Proto jsou do výpočtu zahrnuty i data z IMU. Z principu systému však je nutné, aby zařízení byla pro základní stanice viditelná [23][22]. Pokud je objekt před stanicí zakrytý, spoléhá systém pouze na data z IMU a jak je v sekci 3.2 popsáno, ta jsou v čase zanesena poměrně rychle rostoucí chybou14. Dů- sledkem toho se pak může stát, že se daný objekt ve virtuální realitě začne od své pozice vzdalovat.

12Do signálů, které stanice vysílají, je zakódovaná informace o tom o jakou stanici se jedná a ze kterého rotoru byl vyslán. 13Reálně bude výpočet složitější, jelikož je nutné znát vzájemnou polohu obou stanice a velikost sledovaného prostoru. Tato data se získávají při kalibraci systému. 14Optický lighthouse systém se tuto chybu snaží co nejvíce redukovat.

23 4 Unity

4.1 Obecně

Unity je jeden z nejpopulárnějších herních enginů. Je vyvíjený společností Unity Technologies od roku 2005. Herní engine je software, který vývojářům poskytuje nezbytnou sadu funkcí pro vytváření her. Jedná se o framework (jakousi kostru) pro vývoj her, který podporuje a sdružuje několik klíčových oblastí, jako je například vykreslování 3D grafiky, fyzika, detekce kolizí, ani- mace nebo audio. Vývojář pak tyto funkce využívá, aniž by se musel starat o jejich implementaci, což typicky značně zjednoduší postup vývoje, jelikož je možné se zaměřit především na vývoj samotné herní logiky [20]. Samotný Unity engine je napsaný v programovacím jazyce C++, pro vývoj aplikací se používá jazyk C# (C-sharp). Unity podporuje celou řadu platforem. Umožňuje vytvářet především hry pro desktopové počítače, mobilní zařízení, herní konzole, web a v neposlední řadě pro virtuální realitu. Dále je podporována většina populárních operač- ních systémů, pro které lze aplikace sestavit. Je tedy poměrně jednoduché vytvořit jednu aplikaci, která může podporovat více platforem najednou. Unity je sice zaměřená pro vývoj videoher, každopádně vzhledem k vlast- nostem a nabízeným funkcím, které herní engine poskytuje, lze engine využít i pro tvorbu aplikací z jiných oblastí. Nejčastěji jsou tyto aplikace nějakým způsobem provázány s prací s 3D grafikou, ať už pro vizualizaci dat nebo tvorbu prototypů či provádění různých simulací. Herní engine Unity byl již v počátcích projektu zvolen jako vhodné pro- středí pro vývoj aplikace. Ve své podstatě sice software není hrou, určité prvky her ovšem obsahuje, přeci jen v rámci rehabilitací existují typy her nebo aktivit, které pacienti vykonávají za účelem zlepšení hybnosti. Tato práce přímo navazuje a staví na bakalářské práci [14], jejíž výsledkem je .NET knihovna pro analýzu prováděného pohybu v reálném čase, která byla vytvořena přímo pro možnost její integrace do aplikace tvořené v Unity. Důležitou roli při vývoji aplikace v Unity hrají takzvané assety. Jsou to veškeré objekty (zdroje, data), které jsou v projektu použity a společnou integrací tvoří samotnou aplikaci. Některé assety je možné vytvořit přímo z Unity editoru (skripty, scény, primitivní herní objekty. . . ), jiné jsou typicky externí a je možné je do projektu importovat (3D modely, audio soubory, knihovny. . . ). Veškeré assety se v Unity projektu nacházejí ve složce Assets. Assety se při sestavení aplikace stanou přímo součástí spustitelného .exe sou-

24 Obrázek 4.1: Editor herního enginu Unity boru, někdy je ale zapotřebí k assetům přistupovat ze souborového systému. Takové soubory se pak ukládají do speciální složky Assets/StreamingAssets.

4.1.1 Editor Unity editor je volně dostupný1 nástroj, viz obrázek 4.1, vyvíjený Unity Technologies, který umožňuje vývojářům vytvářet vlastní aplikace s využi- tím Unity herního enginu. Práce v editoru se skládá ze dvou základních částí a to je tvorba herního světa a programování jeho vlastností. V samotném editoru se pouze tvoří herní svět, samotné psaní kódu probíhá v externím integrovaném vývojovém prostředí, které lze typicky s editorem propojit. Nejčastěji používané pro- středí bývá Visual Studio, kód je ovšem možné psát v jakémkoliv textovém editoru. Tvorba světa v editoru probíhá pomocí takzvaného drag and drop vývoje. To je způsob, kdy vývojář jednotlivé objekty/komponenty přetahuje například pro umístění ve scéně nebo předání reference mezi komponentami, viz následující sekce. Tento styl vývoje je poměrně jednoduchý, jelikož vývo- jáři umožňuje svět „naklikat“. Pro vývoj v editoru existuje spousta tutoriálů, dokumentace a manuálů od samotné firmy, či bohaté komunity, která okolo vývoje v Unity vznikla. V editoru se nachází několik základních podoken. Budou popsána jed- notlivá okna dle obrázku 4.1, v editoru lze zapnout i další okna, tyto však

1Firma nabízí i placené licence, které poskytují určité rozšiřující možností, které jsou vhodné spíše pro firmy a v rámci projektu nebyly zapotřebí.

25 byly při vývoji nejčastěji používané. Asi nejdůležitější okno je okno Scene, nacházející se uprostřed. Zde se vytváří grafické prostředí aplikace. Rozmis- ťují se zde herní objekty, osvětlení a kamera. Při spuštění aplikace (tlačítko „play“ uprostřed nahoře) se okno přepne do pohledu Game. To slouží k tes- tování provedených změn. Vývojář zde vidí jak bude výsledná hra/aplikace vypadat. Vlevo uprostřed se nachází okno Hierarchy. Zde jsou zobrazeny všechny použité scény a herní objekty nacházející se v dané scéně. Objekty lze v rámci scény strukturovat do stromové hierarchie. Vlevo dole je okno Project, ve kterém je vidět struktura dat daného projektu. Jedná se typický souborový systém, je sem možno importovat externí assety. Z hlediska vývoje je po- měrně důležité okno Console, nacházející se dole uprostřed. Zde se vypisují chybové a varovné hlášky, které v průběhu hry nastanou, případně je zde možné vypsat nějaké informace k ladění projektu. Vpravo se pak nachází okno Inspector. Zde se ukazují informace o aktuálně zvoleném herním ob- jektu z hierarchie.

4.1.2 Scény Scéna v Unity představuje kolekci herních objektů, které spolu nějakým způ- sobem spolupracují a v danou chvíli vytvářejí herní prostředí. Je to vlastně jakýsi kořen stromové hierarchie těchto objektů. Scén může být v rámci pro- jektu více, v danou chvíli je však aktivní pouze jedna a mezi scénami se pak lze programově přepínat. Při sestavení projektu se pak určí jaké scény do něj mají být zahrnuty a nastaví se jejich indexace. Při spuštění aplikace se pak spustí scéna s indexem 0.

4.1.3 Herní objekty Herní objekt (GameObject) je asi nejdůležitější koncept v rámci Unity Edi- toru. Herní objekty jsou jakési kontejnery, které samy o sobě nic nedělají. Z inspektoru editoru jim lze přiřadit tzv. komponenty. Každá komponenta přidává objektu nějakou vlastnost nebo chování, například to může být na- stavení kolizí (Collider), způsob jeho grafického vykreslení (Mesh Rende- rer) nebo skript. Unity má spoustu komponent již v sobě vestavěných. V in- spektoru pak lze také měnit některá nastavení daných komponent. Pro kaž- dou komponentu existuje v Unity Enigne stejnojmenná třída, a lze tak pře- dat odkaz na konkrétní instanci komponenty skriptu a volat jejich metody, viz 4.1.4. Objekty a i jejich komponenty, mohou být ve scéně, ale lze je jak v editoru tak programově deaktivovat. Deaktivované objekty pak sice jsou

26 součástí scény, ale žádným způsobem ji neovlivňují. Pokud je na objektu de- aktivována komponenta, tak ji sice objekt má, ale neposkytuje objektu svoje vlastnosti. Nejdůležitější komponentou herních objektů je jeho transformace Trans- form. Tato komponenta je součástí každého objektu a nelze ji odstranit. Ob- sahuje informace o tom jaká je aktuální pozice objektu ve scéně, jaká je jeho rotace a velikost. Modifikací této komponenty lze pak objekt různě oriento- vat nebo měnit jeho rozměry. Obsahuje také metody pro práci s hierarchií objektu v rámci scény, lze tedy například získat referenci na svého předka, nebo reference na potomky. Pro složitější objekty Unity umožňuje vytvoření takzvaného prefabu. To je jakási šablona pro další tvorbu a vkládání těchto objektů do scén. Obsa- huje pak všechny komponenty a potomky daného objektu, ze kterého byla šablona vytvořena.

4.1.4 Skriptování Kromě využívání vestavěných komponent je nutné do aplikace zavést nějakou vlastní logiku, k tomu slouží skripty. Skript je tedy naše vlastní komponenta, ve které můžeme definovat chování určitého objektu, měnit jeho vlastnosti v čase nebo reagovat na vstup od uživatele. K tomu aby byl kód skriptu vykonáván, musí být přidán jako komponenta některého aktivního herního objektu ve scéně. Pro programování vlastních skriptů je používán objektově orientovaný programovací jazyk C#. Jako skript se pak ve skutečnosti bere třída, která je potomkem třídy MonoBehaviour z Unity Engine API. Třída MonoBehaviour skriptu poskytuje řadu metod, které jsou následně volané z enginu. Skripty mají svůj „životní cyklus“, na základě kterého jsou v konkrétním pořadí dané metody volány. Metody pak lze roztřídit na zá- kladě toho do jaké části cyklu patří. Jedná se o metody inicializační, starající se o herní fyziku, herní logiku, vykreslování a ukončování skriptu. Nejčas- těji používané metody jsou Start(), což je metoda, která je volána pouze jedou za celou dobu existence skriptu a používá se typicky k inicializaci proměnných2, a metoda Update(), která je volána jednou za každý snímek probíhající aplikace. Celý životní cyklus skriptů je možné najít v [19] v sekci Order of Execution for Event Functions. Skriptům je možné definovat atributy, tak jak je tomu v objektově orien- tovaných jazycích zvykem. Je-li atributu nastaven modifikátor public, nebo

2Dalo by se říci, že se jedná o konstruktor skriptu, ovšem voláním této metody instance skriptu nevzniká, o to se stará samotný Unity Engine

27 Obrázek 4.2: Okno pro tvorbu animací v Unity Editoru je mu předána vlastnost [SerializeField]3, je možné nastavit hodnotu či předat referenci na konkrétní instanci z inspektoru Unity Editoru. V editoru je také možné nastavit pořadí v jakém jsou jednotlivé skripty vykonávány.

4.2 Animace

Unity pro práci s animacemi používá systém nazývaný Mecanim. V Unity existuje ještě jeden starší systém, který je označován jako Legacy a již se příliš nepoužívá, v enginu zůstal především pro zachování zpětné kompati- bility starších aplikací. Z tohoto důvodu bude dále popsána práce pouze se systémem Mecanim. Unity používá koncept animačních klipů (AnimationClip). Animace je vlastně pouze postupná změna pozice, rotace nebo velikosti nějakého vy- kreslovaného modelu v čase. Animační klip si je pak možno představit jako „nahrávku“, která obsahuje data o příslušné animaci. Animace se nejčastěji vytvářejí v externích softwarech, ve kterých se tvoří samotný model, jako je například Autodesk Maya, Autodesk 3ds Max nebo Blender. Do Unity je pak možné tyto objekty naimportovat i s jejich animacemi. Vlastní animace je možné tvořit i v samotném Unity Editoru. K tomu slouží okno Animation, viz obrázek 4.2. V okně pak lze nad vybraným herním objektem ze scény vytvořit animaci. Animace je tvořena pomocí klíčových snímků (Keyframe) a animačních křivek (AnimationCurve). Klíčové snímky se z okna dají nahrát kliknutím na červené tlačítko. To umožní zaznamenat transformaci4 objektu ve zvole- ném čase animace. Křivky pak určují jakým způsobem se bude dopočítávat

3Výhodou tohoto přístupu je, že atribut může být nastaven jako privátní, ale jeho hodnotu je stále možné měnit z editoru. Není jej však možné měnit z jiného skriptu. 4Komponenta animovaného herního objektu, viz sekce 4.1.3.

28 (interpolovat) hodnota transformace mezi dvěma po sobě jdoucími klíčovými snímky. Například na obrázku 4.2 je 30. snímek animace klíčový a objekt má y rotaci nastavenou na 90 stupňů. V prvním snímku, který je také klíčový, je tento úhel nastaven na 0, pokud by tedy byla křivka mezi těmito snímky pro daný úhel lineární, bude rotace v 15 snímku nabývat hodnoty 45 stupňů. Pro ovládání animací slouží v Unity Animator Controller. V editoru pro něj existuje vlastní okno. Lze si tento kontrolér představit jako konečný sta- vový automat, kde jednotlivé stavy jsou přidané animační klipy. Přechody mezi klipy jsou umožněny pomocí parametrů, které mohou být různého typu (float, int, bool) a přechod se provede je-li splněna nějaká podmínka se zvo- leným parametrem5. Na animovaný herní objekt se musí přidat komponenta Animator, které je nutné předat referenci na vytvořený kontrolér. Animace je pak možné ovládat pomocí metod, které tato komponenta nabízí. Výše popsaný systém byl používán v prvotních fázích projektu. Roli animovaného objektu v našem případě hraje 3D model horní končetiny. Měli jsme naměřené pohyby a pro ně v Blendru ručně vytvořené animace6. V Unity projektu se pak pro tento objekt vytvořil Animator a Animator Controller, do kterého se jednotlivé animace přidaly. Následně se pak ze skriptu získala reference na Animator a volala se metoda pro přehrávání animace aktuálně vykonávaného pohybu. Postupem vývoje jsme ovšem jako jednu z největších možností aplikace chtěli implementovat definování vlastního pohybu bez nutnosti jejího pře- kladu a znovu sestavení. Šlo by tedy o to, že se naměří nový pohyb, ke kterému by se automaticky vytvořila animace a následně by byla přidána k rehabilitační aplikaci. Ukázalo se ovšem, že pomocí systému Mecanim při- dávat animace za běhu programu nelze. Vznikl tak software, který dokáže z naměřených dat o pohybu automaticky vytvořit animaci pro model horní končetiny, jehož výstupem jsou data o vytvořené animaci. Software pracuje na principu inverzní kinematiky a je výsledkem bakalářské práce Alexe Kö- niga [12]. Animační data jsou pak poskytnutá rehabilitační aplikaci přes StreamingAssets a jsou v aplikaci využívána k animování aktuálně provádě- ného pohybu. Konkrétní implementace, viz sekce 5.3.4.

5Například se definuje parametr typu int a v přechodu mezi dvěma animacemi se nastaví, že k přechodu dojde pokud je jeho hodnota větší než nějaká předem definovaná hodnota. 6Model a jeho animace jsou práce Alexe Königa [12].

29 4.3 VR integrace

Pro integraci virtuální reality s Unity typicky vývojáři daného headsetu po- skytují ostatním vývojářům kteří chtějí pro daný headset tvořit software tzv. SDK(Software Development Kit), tedy sadu vývojových nástrojů, které umožňují práci s danýmVR systémem. Jednotlivé knihovny jsou pak do- stupné buď na Unity Asset Store, nebo je možné je do projektu importovat ze stránek vývojáře. V projektu je pracováno s headsetem HTC Vive, pro který existuje vý- vojová sada SteamVR. Ta je dostupná přímo z Unity Asset Store odkud ji je možno přímo do Unity projektu naimportovat. Po dokončení vlastního importu, je víceméně integrace hotová a dále se jedná pouze o využívání možností, které knihovna poskytuje. Důležitou součástí knihovny je prefab [CameraRig], který reprezentuje kameru, kterou bude vykreslováno na dis- plej samotného headsetu. Prefab také obsahuje ohraničení zvoleného herního prostoru v rámci Vive. Z důvodu omezené práce s ovladači nebyly další mož- nosti knihovny využívány. V projektu je ještě částečně pracováno s další knihovnou, a to Vive Input Utility, která je také dostupná z Unity Asset Store. Knihovna je používaná především za účelem svázání herního objektu s nějakým sledovatelným ob- jektem (headset, ovladače, trackery) systému HTC Vive. Poskytuje skript VivePoseTracker, který je možné přidat jako komponentu herního objektu, který bude představovat příslušný sledovaný objekt. V inspektoru skriptu pak lze nastavit roli. Roli je pak nutné svázat s konkrétním zařízením.

30 5 Software

Cílem této kapitoly je seznámit čtenáře se softwarem, který je výsledkem této bakalářské práce. Nejprve bude popsána hlavní myšlenka daného softwaru a jaké náležitosti bylo zapotřebí brát v úvahu při jeho vytváření, viz sekce 5.1. Následně proběhne popis toho co software umí a nabízí a jakým způsobem s ním může interagovat pacient a terapeut a jakou roli v rámci softwaru každý z nich hraje, viz sekce 5.2. Poté bude popsáno, jakým způsobem jsou jednotlivé vlastnosti a komponenty aplikace implementovány v rámci enginu Unity, viz sekce 5.3. Testování aplikace bude popsáno v sekci 5.4. Nakonec proběhne diskuze možných nedostatků, které se ve výsledné aplikaci nachází, a možných budoucích rozšíření, která by při další práci na projektu mohla být implementována, viz sekce 5.5.

5.1 Návrh

Pacienti s neurologickými potížemi při rehabilitacích provádějí různá cvičení (pohyby a hry), pod dohledem terapeuta, za účelem zlepšení hybnosti horní končetiny. Cílem pacientů by mělo být dané pohyby provádět co nejlépe bez „podvádění“1. Základní myšlenka celého projektu je následující. Bude nutné nasbírat data o jakémsi „perfektním“ pohybu. Perfektním pohybem je myšlen ja- kýkoliv rehabilitační pohyb, který je vykonán zdravým člověkem, nejlépe takovým, který ví, jak by měl být pohyb proveden správně. Nejčastěji se bude pravděpodobně jednat o terapeuta, který s pacientem rehabilitace pro- vádí. Získání dat o tomto pohybu je úkolem aplikace Jakuba Franka [9], která umožňuje nahrání pohybu za pomoci systému HTC Vive. Pohyb je definován polohou a rotací několika senzorů v čase. Senzory podchycující pohyb jsou čtyři, a to HMD a tři Vive trackery, jeden umístěný na zápěstí, jeden na paži a poslední na hrudníku. Výstupem aplikace jsou pak soubory, jeden pro každý senzor, ve kterých se nacházejí data o provedeném pohybu, tedy jednotlivé časové snímky rotace a polohy senzoru. Úkolem pacienta je pak co možná nejlépe předcvičený pohyb replikovat. Cílem rehabilitační aplikace, která je výsledkem této bakalářské práce, je především tedy umožnit pacientům provádět definované pohyby a poskyt- nout terapeutům informace o vykonaných pohybech.

1Pacienti si například pomáhají při pohybu paže vzhůru zvednutím hrudníku.

31 V rehabilitační aplikaci bude potřeba umožnit terapeutovi definovat a přidat nový pohyb. Aplikace pak bude data definující pohyb načítat do struktur. Je tedy potřebné v aplikaci připravit datové struktury, které bu- dou reprezentovat jednotlivá cvičení. Následně je třeba ovládat a analyzo- vat pohyb prováděný pacientem. Za účelem analýzy pohybu v reálném čase vznikla knihovna AAPD(Automatic Arm Position Detection), jež je výsled- kem bakalářské práce Vítka Poóra [14] a dále upravována Jakubem Frankem. Knihovna poskytuje rozhraní, které provádí analýzu prováděného pohybu a poskytuje o něm rehabilitační aplikaci informace. Jedná se o aktuální fázi a kvalitu pohybu. Na základě těchto údajů bude pak možné určit, zda je prováděný pohyb správný nebo není. O pohybu bude možné sbírat další statistky. Samozřejmě bude nutné pacienta i terapeuta informovat o tom, co se aktuálně v aplikaci děje, pomocí uživatelského rozhraní. Největší výhodou aplikace oproti regulérním rehabilitacím pak je možná vizualizace předcvi- čeného pohybu terapeutem pacientovi. Další výhodou je poskytnutí doda- tečných informací o vykonaném pohybu terapeutovi.

5.2 Možnosti softwaru

Software je rozdělen do dvou herních scén. První, konfigurační, která se načte při spuštění aplikace, a druhá, sloužící k provádění rehabilitačních cvičení. Jak bylo výše zmíněno, aplikace je zaměřena pro používání dvěma uživateli, terapeutem a pacientem. V následujících sekcích bude popsáno, jakým způsobem mohou uživatelé v jednotlivých scénách pracovat a jakou hrají v kontextu aplikace roli.

5.2.1 Použití HTC Vive Pro podporu virtuální reality používá rehabilitační aplikace systém HTC Vive, viz sekce 3.3. Ke správnému fungování je používán headset a 6 trackerů. Trackery jsou používány pro sledování pozice a rotace následujících částí těla a objektů: levé zápěstí, levá paže, pravé zápěstí, pravá paže, hrudník a židle, na které pacient bude sedět a provádět cvičení. Teoreticky je možné v danou chvíli používat trackery pouze 4, jelikož jednotlivá cvičení jsou rozdělena podle toho, zda se jedná o cvičení zaměřené na pravou nebo levou horní končetinu. Z toho tedy vyplývá, že při provádění cvičení na pravou ruku není nutné mít nasazené (nemusí být ani zapnuté) trackery pro levou ruku a naopak. Pro jednotlivé trackery byla 3D tiskárnou vytisknuta podstava, která jde k trackeru přišroubovat a provléknout jí páskou se suchým zipem,

32 takže je pak možné tracker připevnit na horní končetinu. Pro připevnění k hrudníku je použit hrudní popruh jaký je používán například pro kamery GoPro. Důležitým aspektem pro funkčnost aplikace je správná pozice a orien- tace trackerů nasazených na příslušných částech těla, jelikož při analýze po- hybu prováděného pacientem dochází k porovnávání aktuální pozice a rotace trackeru vůči nejbližšímu bodu fáze pohybu předcvičeného terapeutem. To znamená, že pro správné vyhodnocování pohybu je nutné, aby měl paci- ent trackery nasazené stejně jako je měl nasazené terapeut při nahrávání daného pohybu. Pokud by tomu tak nebylo, bude logicky pohyb vyhodno- cován špatnou kvalitou, přestože by pohyb byl vykonáván správně. Za tímto účelem vznikla konvence mezi všemi aplikacemi projektu2 pro pozice a ro- tace trackerů, kterou je nutné dodržovat3. Konvence je následující. Trackery na zápěstí jsou umístěny stejným způsobem jako náramkové hodinky a jejich orientace je taková, že LED dioda indikující stav trackeru směřuje směrem k dlani. Trackery na paži jsou umístěny pod deltovým svalem a dioda smě- řuje směrem k lokti. Hrudní tracker by měl být umístěn zhruba uprostřed hrudní kosti mezi prsními svaly a dioda směřuje směrem k hlavě. V aplikaci je nutné ještě příslušné objekty reprezentující trackery spárovat s trackery skutečnými, viz příloha A.2.3. Ovladače systému HTC Vive nejsou v aplikaci nikde použity. Důvodem je fakt, že většina pacientů má problémy s jemnou motorikou, viz sekce 2.2, a tudíž velmi často nejsou schopni ani některé předměty uchopit.

5.2.2 Role pacienta Úlohou pacienta v rehabilitační aplikaci, je provádět předem definovaná re- habilitační cvičení. Cvičeními jsou myšlené jak pohyby, předcvičené terapeu- tem a přidané k aplikaci, tak rehabilitační hry. Pacient je tedy uživatel, který má na sobě sestavu HTC Vive, tak jak bylo popsáno v předchozí sekci. Je vhodné, aby pacient měl dostupný nějaký zdroj zvuku, sluchátka nebo lépe reproduktory4, jelikož aplikace pro určitá oznámení používá audio signály, viz dále. První, tedy konfigurační, scéna je z pohledu pacienta vcelku nezajímavá a bude tedy popsána v následující sekci. Po provedení konfigurace se pacient

2Rehabilitační aplikace, aplikace pro měření rehabilitačního pohybu [9], aplikace pro automatickou tvorbu animací rehabilitačního pohybu [12]. 3Dodržením této konvence dojde ke značnému snížení zanesené chyby vyhodnocování. 4Reproduktory jsou asi lepší volba, jelikož pacient stále může komunikovat s terapeu- tem.

33 objeví v hlavní herní scéně aplikace. Ve scéně se nachází několik prvků, které může pacient vidět. První čeho si nejspíše všimne je samotné virtuální pro- středí, reprezentované 3D modelem5 anglické památky Stonehenge6. Model slouží pouze k oživení prostředí a nelze s ním nijak interagovat. Prostředí je herní objekt, tzn. bylo by poměrně jednoduché přidat prostředí více a umož- nit mezi nimi přepínat. Dalším prvkem jsou herní objekty reprezentující Vive trackery. Konkrétní reprezentace trackeru může být různá dle konfigurace, viz sekce 5.3.5. U modelu se nachází popisek, který určuje, kde by se měl tracker nacházet (levé zápěstí atd.). Pokud jsou trackery nasazeny korektně (ve smyslu rotace), pak by měl být popisek čitelný, jinak bude pravděpo- dobně nějakým způsobem převrácený. Před pacientem je ve scéně plátno, na které se budou vypisovat aktuální pokyny a informace o prováděných cvičeních. Terapeut pacientovi postupně spouští cvičení. V aplikaci se aktuálně na- chází jedna rehabilitační hra, sbírání míčů, viz obrázek 5.1. Jedná se o velmi jednoduchou hru, kde úkolem pacienta je posbírat kuličky (herní objekty reprezentující „míče“), které se ve scéně zobrazí. Pacient se musí dotknout kuliček virtuální dlaní, která se mu při hře zobrazí u zápěstního trackeru. Kulička, kterou je třeba sebrat je obarvena modře, sebrané jsou zelené a ku- ličky, které budou na řadě červené. Při sebrání kuličky je přehrán zvukový signál. Pokud se náhodou kulička, která se má sebrat, nenachází v zorném poli pacienta, zobrazí se mu šipka7, ukazující směrem ke kuličce. Dalšími cvičeními jsou pohyby. Před spuštěním pohybu by se měl pacient dostat do neutrální polohy. Neutrální poloha se používá k transformaci tu- nelu používaného pro analýzu pohybu, viz sekce 5.3.3. Pro naměřené pohyby byla stanovena konvence neutrální polohy, která je zaznamenána aplikací pro sběr dat pohybů [9]. Poloha by měla být v sedě s rovnými zády s dlaněmi položenými na kolenou. Po spuštění pohybu se zobrazí několik nových prvků, viz obrázek 5.2. Je zobrazena vizualizace tunelu. Jedná se o trajektorie, reprezentované barev- nými křivkami, které zobrazují, jakým způsobem probíhal naměřený pohyb pro každý tracker. Ukazuje pacientovi, jak by měl trackery pohybovat pro dosažení „perfektního pohybu“. Dalším prvkem je 3D model horní končetiny, který bude prováděním pohybu animován. Animace je založena na předcviče- ném pohybu, to znamená, že nebude přímo odpovídat aktuálně prováděnému

5Model není naší prací. Byl stažen z: https://sketchfab.com/3d-models/ stonehenge-37cfc2bb99944703b5d57ea281030ca6 a následně importován do Unity pro- jektu. 6https://www.mundo.cz/anglie/stonehenge 7Pokud je tak nastaveno terapeutem, viz sekce 5.3.5

34 Obrázek 5.1: Ukázka prvků hry sbírání míčů pohybu, ale bude ukazovat, jak by paže měla vypadat v ideálním případě. Vyhodnocovaní pohybu začne v momentě, kdy se pacient dostane z neut- rální polohy do počáteční polohy pohybu, viz sekce 5.3.2. Je při tom přehrán zvukový signál indikující, že pohyb začal. Cílem pacienta je dostat se po křivce s dostatečnou kvalitou do nějaké definované fáze. Kvalitu jakou má pohyb mít a cílovou fázi stanovuje terapeut. Po provedení pohybu s dosta- tečnou kvalitou je přehrán zvuk indikující úspěch, a pacient může provádět další opakování, pokud ještě nějaké následuje. Počet opakování pohybu je také stanoven terapeutem. Pohyby jsou rozděleny na dva typy, podle toho zda je počáteční a kon- cová fáze pohybu ve stejné poloze či nikoliv. Pokud tomu tak je a pacientova fáze pohybu, při snaze dostat se do specifikované fáze, nějakým významným způsobem klesne, je přehrán zvukový signál oznamující selhání. Pokud na- stane tato situace, pak se musí pacient vrátit do počáteční polohy a zkusit pohyb znovu, tzn. opakování pohybu se již nebude počítat. Po vykonání každého cvičení se na plátně zobrazí jeho shrnutí a informace o tom, jaké cvičení následuje (pokud takové je).

5.2.3 Role terapeuta Terapeut hraje v rámci rehabilitační aplikace podstatnou roli. Jeho úkolem je aplikaci nastavovat a ovládat. Jelikož pacienti nemohou mít ovladače, je veškerý vstup od uživatele prováděn klávesnicí, a tedy terapeutem. Nastavo-

35 Obrázek 5.2: Ukázka prvků u pohybů váním je myšleno zejména sestavování posloupnosti rehabilitačních cvičení a úprava parametrů v konfiguračních souborech. Konfigurace a její možnosti budou dále popsány v sekci 5.3.5. Terapeut má možnost k aplikaci připojit a definovat nový libovolný rehabilitační pohyb, s využitím vlastností všech tří aplikací8 projektu, viz příloha A.2.4. První, konfigurační scéna, slouží k změření poměru rozměru těla pacienta ku rozměru těla terapeuta9. Tento poměr je pak použit pro úpravu poloh na- měřeného pohybu tak, aby pohyb mohl být vykonáván i pacientem10. Rozměr se měří od hlavy, tedy headsetu, k pravému zápěstnímu trackeru. Logicky vyplývá, že by terapeut i pacient měli být při měření ve stejné poloze. Byla zavedena konvence, že je připaženo, jelikož to je poloha, která by pacien- tům neměla dělat větší potíže, na rozdíl například od upažení. Aplikace si rozměry mezi spuštěními pamatuje, takže je možné rozměr terapeuta změřit pouze jednou a následně měřit pouze pacienty. Ve scéně se nachází tabule, stejně jako v hlavní scéně, na které je popis zda se aktuálně jedná o terapeuta či pacienta. Dále jsou zde vypsány jed- notlivé rozměry uživatelů v metrech. Přepnutí mezi pacientem a terapeutem zajišťuje klávesa S. Změření rozměru těla je provedeno stisknutím mezerníku.

8Rehabilitační, nahrávací a aplikace pro tvorbu animací. 9Respektive uživatele jenž prováděl předcvičení pohybů. 10Například pokud by byl terapeut vysoký a pacient nízký, mohlo by dojít k situaci, že pacient by pohyb ani nemohl vykonat, protože by nemusel dosáhnout tak daleko jako terapeut.

36 Pro přepnutí do hlavní scény slouží klávesa Enter. V hlavní scéně, kromě toho že na monitoru uvidí to co pacient, má te- rapeut ještě vlastní uživatelské rozhraní, které se zobrazuje pouze jemu a nikoliv pacientovi, viz obrázek 5.3. Jedná se o čtyři menší okna, která je možné minimalizovat kliknutím na bílé tlačítko. V levém okně se nacházejí informace o prováděných cvičení, které se vypisují i na plátno ve scéně.

Obrázek 5.3: Uživatelské rozhraní zobrazované pouze na monitoru terapeuta

Dole jsou dvě okna, která slouží k nahrávání a přehrávání pohybů prová- děných pacienty. Levé okno slouží pro nahrávání pohybu, nejprve je nutné zvolit složku, kam se pohyb nahraje. Pak v případě, že pacient provádí pohyb je možné pohyb začít nahrávat. Z pravého okna je pak možné vybrat složku nahraného pohybu a ten přehrát. Tuto akci je možné provést kdykoliv, kdy se neprovádí nějaké cvičení. Pohyb se pak přehrává tak, že se ve scéně zobrazí pohyb trackerů a headsetu, tak jak jimi hýbal pacient, a vizualizace tunelu, který pacient pacient při daném pohybu používal. Z pravého okna pak může terapeut měnit nastavení 3D modelu horní kon- četiny. Je zde možné nastavit jeho průhlednost pomocí posuvníku. V okně je výpis o jaký index nastavení se jedná. Je možné mít pro model více nastavení a pak jedno konkrétní používat. Myšlenka je taková, že každý pacient bude preferovat nastavení trochu jinak a takto je možno udělat nastavení pro více pacientů. Mezi nastaveními se přepíná klávesami 0–9 z horní řady klávesnice (tedy ne z numerické). V okně je ještě možné dopsat nějakou poznámku, tag, který umožní lehčí zapamatování, které nastavení přísluší jakému pa- cientovi, oproti indexu. S nastavením modelu se ještě pojí jeho poloha. Tu terapeut může měnit pomocí šipek a numerických kláves 2 a 8. Šipky vlevo a vpravo slouží k posunu ve směru horizontálním, nahoru a dolu ve směru

37 vertikálním a numerické klávesy v prostoru před či za pacienta. Posuny se vztahují k pravé ruce a levá ruka je pak symetricky posouvána s pravou. Takto je možný posun v daném směru o jeden centimetr, pro větší posun je pak možné použít klávesy s kombinací levý SHIFT pro posun o 10cm nebo levý CTRL posun o 5cm. Tato nastavení jsou perzistentní a při dal- ším spuštění aplikace se použije nastavení používané při předchozím vypnutí aplikace. Terapeut v hlavní scéně spouští jednotlivá cvičení mezerníkem. Po skon- čení všech cvičení se aplikace vypíná kombinací levý ALT + F4, nebo kláve- sou ESCAPE. Po vypnutí aplikace se do složky ExerciseSummaries11 zapíše soubor, obsahující statistiky provedených cvičeních. Soubor je tvořen po- každé nový a obsahuje v názvu datum a čas vypnutí aplikace.

5.3 Implementace

Implementace rehabilitační aplikace proběhla v herním enginu Unity12, viz kapitola4. Jak již bylo zmíněno, aplikace je tvořena dvěma herními scénami. V první probíhá krátká konfigurace a ve druhé je možné provádět samot- nou rehabilitaci. První scéna je velmi jednoduchá a obsahuje pouze jeden skript SetUpManager, který pouze změří vzdálenost mezi trackerem na zá- pěstí a HMD kamerou, voláním metody Vector3.Distance() pro zvoleného uživatele, viz sekce 5.2.3. Změřené hodnoty uloží pomocí metody Player- Prefs.SetFloat(), a jejich poměr je předán nastavení knihovny AAPD. Při dalším spuštění aplikace jsou rozměry zpětně získané metodou Player- Prefs.GetFloat(). Dále bude popsána hlavní funkcionalita druhé scény, nebude zde popiso- vaná veškerá implementace, ale pouze části, které jsou důležité nebo nějakým způsobem zajímavé. Veškeré zdrojové kódy aplikace jsou dostupné na repo- sitáři https://gitlab.com/frankkuba/vr-arm-motion a v příloze práce, viz sekce A.3. Herní objekty tvořící druhou scénu je možné rozdělit do několika katego- rií. Objekty reprezentující jednotlivé trackery, 3D modely (horní končetiny, dlaně, židle, a vlastní virtuální prostředí), objekty tvořící uživatelské roz- hraní, a pak typicky prázdné objekty, které slouží pouze jako kontejnery pro běžící skripty. Skripty těchto objektů typicky načítají konfiguraci, nebo dále ovládají chod aplikace.

11Adresář se vytvoří v kořenovém adresáři aplikace. 12V projektu jsou použity různé metody a třídy poskytované z API tohoto engine, viz [19], v textu nebude zmiňováno zda se jedná o vlastní třídu/metodu nebo zda je z Unity API.

38 Obrázek 5.4: Graf stavů aplikace a jejich přechodů

Data jsou aplikaci předávána pomocí konfiguračních souborů, viz sekce 5.3.5, ze kterých jsou načítány a tvořeny instance příslušných datových struk- tur (budou popsány v dalších sekcích). Skripty si pak kromě herních objektů předávají reference na datové struktury. Důležitou strukturou aplikace je třída AppStateManager, obsahující sta- tickou vlastnost (C# property) CurrentAppState typu AppState. AppState je enum, jehož hodnoty reprezentují jednotlivé stavy aplikace. Skripty pak na základě aktuální hodnoty vlastnosti provádí různé akce a podle dění v apli- kaci stav mění. Hodnoty a jejich přechody je možné reprezentovat grafem, viz obrázek 5.4.

39 5.3.1 Uživatelské rozhraní Uživatelská rozhraní, dále zkráceně GUI(Graphical User Interface), jsou v aplikaci řešena pomocí Unity komponenty Canvas. Potomci herního ob- jektu s touto komponentou jsou jednotlivé objekty tvořící prvky GUI (texty, tlačítka. . . ). Pro zobrazení jednotlivých textů GUI byla použita knihovna TextMesh Pro, která oproti nativním textům Unity poskytuje výrazně lepší kvalitu vykreslování. V komponentě Canvas je možno určit, kde se bude zobrazovat, tzv. render mode.

• Screen Space - Overlay — GUI je vykresleno přes obrazovku displeje.

• Screen Space - Camera — GUI je vykresleno před vybranou kamerou.

• World Space — GUI je vykresleno ve scéně je viditelné všemi kame- rami.

V aplikaci je využíváno všech tří možností. Overlay je využíváno pro zobra- zení GUI terapeutovi, tedy pouze na obrazovku monitoru. Camera se pou- žívá pro zobrazení pomocné šipky před HMD pacienta, při hře sbírání míčů. World Space je používáno pro zobrazování pláten v obou scénách. Pro každou ze tří možností pak existují skripty, které zajišťují vykreslo- vání textů, případně obsluhu tlačítek. Bude popsána implementace plátna ve scéně, pro GUI monitoru je implementace velmi podobná. Plátno reprezentuje herní objekt UI, který má jako komponentu pře- daný skript UIController. Objekt jako potomky obsahuje prázdné herní objekty, které slouží pouze pro sdružování textů, které jsou zobrazeny spo- lečně. Skript tedy při inicializaci (metoda Start()) nejprve podle názvu me- todou Find() najde tyto potomky. Následně pak v metodě LateUpdate(), na základě aktuálního herního stavu AppStateManager, aktivuje příslušného potomka a zbytek deaktivuje. Z potomků se najdou příslušné instance textů TextMesh Pro a je jim předaná hodnota formátovaného řetězce metodou Language.GetString() (třída Language bude popsaná v sekci 5.3.5). Data pro formátované řetězce jsou typicky nějaké hodnoty o prováděných cviče- ních. Reference na cvičení jsou UIControlleru předána ze skriptu Exerci- seController, viz sekce 5.3.2.

5.3.2 Cvičení Pro práci s cvičeními vzniklo několik datových struktur a skriptů. Jelikož mají všechna cvičení určité společné vlastnosti, vznikla abstraktní třída

40 Exercise. Společnými vlastnostmi cvičení jsou: jejich definice, abstraktní třída ExerciseDefinition, statistky cvičení, abstraktní třída Exercise- Stats a jméno daného cvičení. Třída Exercise poskytuje základní kon- struktor, kterému je jako parametr předána reference na definici cvičení. Instance této třídy reprezentují cvičení, která se budou v průběhu rehabili- tace provádět. ExerciseDefinition specifikuje data, která jednoznačně definují cvi- čení. Každá definice cvičení obsahuje ID, unikátní řetězec, pomocí kterého lze definice rozlišovat. Dále obsahuje stranu, enum Side, obsahující hodnoty RIGHT a LEFT, která určuje na kterou horní končetinu je cvičení zaměřeno. Z těchto hodnot je tvořen konstruktor třídy. ExerciseStats slučuje společné statistiky jednotlivých cvičení, což je mezi všemi cvičeními pouze čas trvání prováděného cvičení. Třída také po- skytuje abstraktní metodu WriteToXML(), která pomocí předaného XMLWri- teru umožňuje zápis statistik do souboru. Konkrétní cvičení, definice a statistiky pak dědí od těchto abstraktních tříd, viz dále. Cvičení ovládá skript ExerciseController, jenž je komponentou stej- nojmenného herního objektu. Skriptu je z inspektoru předána reference na instanci UIController, viz sekce 5.3.1, a instanci ConfigDataReader. Při inicializaci si skript převezme referenci na seznam cvičení z ConfigData- Reader pro rehabilitaci. Pokud načtení cvičení neproběhlo bez problémů, přepne skript aplikaci do stavu ERROR. Pokaždé když se aplikace dostane do stavu START, vybere ze seznamu další cvičení a uloží si na něj referenci do atributu CurrentExercise, kterou dále předá UIController. Podle typu instance cviční pak přepne aplikaci do stavu MOVEMENT_START či GAME_START a předá tak zodpovědnost pro kontrolu daného cvičení jinému kontroléru, viz následující podsekce. Při vypnutí aplikace skript zapíše do souboru statistiky o provedených pohybech a hrách.

Pohyby

Pro práci s pohyby vznikly datové struktury Movement, MovementDefini- tion, MovementStats, které dědí od příslušných abstraktních tříd popsa- ných výše, a skript MovementController, který ovládá průběh pacientem vykonávaného pohybu. Tyto třídy již abstraktní nejsou a pouze rozšiřují im- plementaci jejich předků. Všechny zatím definované pohyby splňují stejné vlastnosti, takže nebylo třeba pro každý tvořit vlastní třídu/skript. Dělí se pouze na dva typy, který specifikuje jejich definice, viz dále. Movement obsahuje oproti generickému cvičení několik dalších atributů.

41 Jsou to atributy načítané z konfiguračního souboru, viz sekce 5.3.5. Pha- seTarget, cílová fáze pohybu do které se musí pacient dostat, Quality- Threshold, reprezentující kvalitu pohybu, kterou pacient musí po celou dobu provádění pohybu splňovat, RepetetionsToHit, počet opakování to- hoto pohybu, které má pacient vykonat, a pak atributy indikující, zda se má nějaká část vizualizace tunelu schovat či nikoliv, viz sekce 5.3.3. Další atributy třídy jsou modifikovány při průběhu pohybu. InitialStarting- Position indikující, zda se pacient dostal do počáteční polohy, a pak jsou zde aktuální hodnoty fáze CurrentPhase, kvality CurrentQuality a počtu splněných opakování CurrentRepetitions. Definici pohybů rozšiřují následující atributy. DataPath, což je souborová cesta k adresáři, kde se nacházejí naměřená data předcvičeného pohybu tera- peutem. AnimationData, třída obsahující načtená data pro práci s animací 3D modelu horní končetiny, viz sekce 5.3.4. A atribut HasApex, který indi- kuje zda má pohyb vrchol či nikoliv. Pohyb má vrchol, jestliže se z počáteční polohy dostane do jakéhosi maxima, ze kterého se následně vrací stejnou trajektorií zpět do počáteční polohy, kde opakování pohybu končí13. Vrchol pohybu automaticky určí knihovna AAPD. Tento atribut pohyby dělí na dvě skupiny, a s každou je potřeba pracovat trochu jinak, viz dále. Tím, že lze definiční data pohybů předávat jako soubory, které lze poměrně jednoduše načítat, je zajištěna možnost definice nového pohybu bez nutnosti překladu aplikace. Kromě doby trvání vykonání pohybu jsou v průběhu sbírány ještě další dvě statistiky. Jedná se o průměrnou kvalitu vykonaného pohybu a prů- měrné vzdálenosti pozic trackerů pacienta při vykonaném pohybu od pozic trackerů předcvičeného pohybu terapeutem14. Průměrná kvalita je počítána váženým průměrem, kde váha pro každou aktuální kvalitu je doba trvání této kvality, tedy Time.deltaTime, jelikož čas mezi voláními Unity metody skriptů Update() má proměnlivou délku. Třída také překrývá metodu Wri- teToXML(), kde je implementována funkcionalita zápisu statistik pohybu do xml souboru. MovementController je skript, a tedy komponentou stejnojmenného her- ního objektu, který je potomkem herního objektu ExerciseController.

13Pro ilustraci máme například naměřené pohyby diagonál a spirál. Diagonála je pohyb, kdy pacient hýbe horní končetinou například od kotníku a snaží se ji zvednout nad hlavu. Z pozice nad hlavou se pak vrací zpět ke kotníku, tzn. pozice nad hlavou je vrchol pohybu. Kdežto u spirály je provedena spirála pouze jedním směrem a není nutné se zpětně vracet stejnou trajektorií. 14Pokud by tedy vzdálenosti byly nulové, tak to znamená, že pacient naprosto přesně kopíroval pohyb terapeuta. Což je samozřejmě ve skutečnosti nemožné, pacient by se každopádně měl snažit aby vzdálenosti byly co nejmenší.

42 Z inspektoru je skriptu předána reference na transformaci trackerů (bez trac- keru židle), reference na 3D modely horní končetiny a instanci skriptu Tun- nelController, blíže popsán v sekci 5.3.3. Skript pak v metodě Update() provádí obsluhu na základě toho v jakém stavu AppState se aplikace na- chází. Pokud se aplikace nenachází ve stavu MOVEMENT_START či MOVEMENT, tak skript pouze deaktivuje modely horních končetin a nic jiného nedělá. Ve stavu MOVEMENT_START je především provedena inicializace struktury Tunnel. Nejprve je na základě definice pohybu vytvořen IDataProces- sor, který je společně s pohybem předán metodě CreateNewTunnel() ze třídy TunnelController. Tyto struktury jsou součásti knihovny AAPD, viz [14][9]. Tunnel a jeho procesor dohromady tvoří analyzátor aktuálně prováděného pohybu. Tunel si lze představit jako jakési okolí (prostor) okolo naměřených dat předcvičeného pohybu, ve kterém se může pacient pohy- bovat, aby byl jeho pohyb započítán. S vyšším nárokem na požadovanou kvalitu (QualityThreshold) se tento prostor zužuje. V tomto stavu je ještě na základě strany Side pohybu připraven příslušný model horní končetiny a trackery, ze kterých bude prováděna analýza pohybu. Je zde také připravena instance třídy AnimationPlayer, pro přehrávání animace, viz sekce 5.3.4. Po provedení inicializace se pak čeká na vstup od terapeuta, tedy na stisk mezerníku. V tu chvíli je aplikace přepnuta do stavu MOVEMENT a je volána metoda TunnelController.StartProcessing(), viz sekce 5.3.3. V každém volání metody Update() je prováděna následující sekvence. Nejprve je dato- vém procesoru předána transformace všech trackerů, voláním metody IDa- taProcessor.Input(). Pak je volána metoda IDataProcessor.Process(), která na základě předaných dat z trackerů spočítá aktuální fázi a kvalitu po- hybu. Jsou to hodnoty z intervalu

h0; 1i kde fáze je poměrná část předcvičeného pohybu ve kterém se pacient nachází. Kvalita je hodnota reprezentující jak dobře je předcvičený pohyb replikován. Nejprve se čeká na to, dokud se pacient nedostane do počáteční fáze pohybu. Do počáteční fáze pohybu se pacient dostane tak, že jeho aktuální fáze je v rozmezí 5% od začátku pohybu, nebo vyšší než 95% pro pohyb s vrcholem15. Poté co se pacient dostane do počáteční polohy se zahájí sběr statistik. V průběhu pohybu se kontroluje, zda se pacient dostal nad poža- dovanou fázi a pokud ano, je mu započítané opakování a čeká se na to až se dostane zpět do počáteční polohy, odkud může provádět opakování další. U pohybů s vrcholem je logika trochu složitější. Opakování je započítáno

15Pohyb s vrcholem začíná a končí ve stejné poloze.

43 až poté, co se pacient dostane zpět do počáteční polohy za podmínky, že se nejprve dostal do požadované fáze. Pokud se pacient začne v rámci po- hybu vracet16, a přitom se nedostal za vrchol nebo požadovanou fázi17, není započítáno opakování a pacient ho musí provést znovu. Nakonec je volána metoda pro animování modelu horní končetiny, viz sekce 5.3.4, a zkontroluje se, zda byl dosažen počet opakování. Po dokon- čení opakování je aplikace přepnuta do stavu MOVEMENT_SUMMARY a je volána metoda TunnelController.HideTunnel().

Hry U většiny her je potřebná určitá forma interakce s uživatelem. Jelikož v apli- kaci není pracováno s Vive ovladači, viz sekce 5.2.1, je vývoj her značně ome- zen. Jak již bylo zmíněno byla provedena implementace pouze jedné velmi jednoduché hry. Každopádně při implementaci bylo snahou systém her na- vrhnout tak, aby bylo možné další hry v budoucnu přidat. Z principu her však na rozdíl od pohybů není možno přidat bez potřeby překladu aplikace, jelikož je minimálně potřebné definovat jejich logiku. Další hry by pravděpo- dobně nebylo možné ovládat dostatečně genericky, takže je rozšíření o něco komplikovanější a bude popsáno níže. Pro práci s hrami vznikla abstraktní třída Game, potomek Exercise, od které budou konkrétní hry dědit. Třída poskytuje následující abstraktní metody: ReadGameData(), která má za úkol načíst herní data z předaného XML uzlu. Třída poskytuje konstruktor, který tuto metodu volá. Cvičení, která mají být provedena, se načítají z jednoho souboru, viz sekce 5.3.5, ve skriptu ConfigDataReader se tvoří jejich instance. Očekává se tedy, že konkrétní data pro hru budou načítána při její inicializaci. Metoda ShowCa- nvasGameUI(), jejímž parametrem je herní objekt, jehož potomci jsou gui prvky. Metoda GUI prvky podle jména vyhledá vypíše na ně aktuální infor- mace o průběhu hry. Metoda ShowCanvasSummaryUI() funguje stejně jako metoda ShowCanvasGameUI(), ale vypíše na gui informace o shrnutí hry. Tyto metody pro práci s GUI volá skript UIController, který tak pře- nechává zodpovědnost o vykreslení informací hře, a tak tedy jejímu progra- mátorovi. To znamená, že při implementaci vlastní hry je potřeba definovat i vlastní UI prvky, viz dále. Třída GameDefinition je koncipovaná jako enum v programovacím ja- zyce Java. Jsou zde tedy konstanty definic jednotlivých her obsahující ID a stranu, na kterou končetinu je hra zaměřena. Na základě ID, a tedy dané

16Aktuální fáze pohybu začne významněji klesat. 17Požadovaná fáze může být teoreticky před vrcholem.

44 konstanty, se pak při vytváření instance hry pozná, jaká se má vytvořit kon- krétní hra. Pro budoucí hry je tedy nutné definovat vlastní konstantu. Třída GameStats pouze sbírá počet bodů dosažených při hře. Pro komplexnější hry by bylo nutné vytvořit vlastní třídu a od této dědit, a tak definovat další statistiky. Pro práci s GUI a hrami je skript GameUIController, který propojí kon- krétní třídu hry s herními objekty UI předanými z inspektoru. Myšlenka je taková, že nově definovaná třída nesoucí data hry bude propojena18 s defi- novanými UI objekty. Reference na skript je předána UIControlleru, který volá metodu GameUIController.Get...UI(), která podle třídy vrací svá- zaný objekt. Získaný objekt je pak předán metodě Game.ShowCanvas...UI() pro vykreslení UI. Nově přidané hře bude nutné definovat logiku. Skript GameControlle- rActivator propojuje, stejným způsobem jak bylo popsáno výše, třídu hry s herním objektem jehož komponentou je skript, který herní logiku provádí. Při přepnutí aplikace do stavu GAME_START skript vybere podle třídy hry, které se bude provádět, objekt pro ovládání hry a ten aktivuje, zbytek deak- tivuje. Tím je zajištěno, že pro konkrétní hru běží její nadefinovaná obsluha. Hra spojování míčů je implementovaná třídou BallConnectingGame a skriptem BallConnectingGameController. Třída implementuje metody zdě- děné z třídy Game. Data pro hru tvoří pozice míčů, které je nutné ve scéně na- sbírat. Pozice míčů je možné definovat v externí aplikaci, vytvořené Jakubem Frankem. Výstup aplikace je soubor obsahující nadefinované pozice, který je třídou načítán. Skript funguje na podobném principu jako MovementCont- roller. Tedy na základě herního stavu jsou prováděny různé obsluhy. Při spuštění hry, tedy stisknutím mezerníku terapeutem, jsou ve scéně vytvořeny míče. To je zajištěno Unity metodou Instantiate(). Pozice objektu (míče) je pak nastavena jako jeho načtená pozice přenásobená poměrem rozměrů uživatelů a posunutá vůči aktuální pozici pacienta19. Aplikace je přepnuta ze stavu GAME_START do GAME. Pak se postupně kontroluje, zda došlo ke kolizi mezi objektem míče a objektem středu dlaně. Pokud došlo, tak je míčům změněna barva a čeká se na kolizi s dalším míčem v pořadí, dokud nedojde k sebrání všech míčů. Po jejich sebrání je aplikace přepnuta do stavu GAME_SUMMARY.

18Pomocí slovníků (Dictionary), kde klíč je třída a hodnota UI objekt. 19Je posunuta vůči pozici hrudníku, jelikož se pacient s největší pravděpodobností ne- nachází ve stejné oblasti, jako byl terapeut při definování pozic míčů.

45 5.3.3 Tunel Jak bylo popsáno v sekci 5.3.2 je pro analýzu prováděného pohybu pou- žíván tzv. Tunnel z knihovny AAPD. Pro práci s touto strukturou byla v rehabilitační aplikaci ještě vytvořena nadstavba v podobě skriptu Tun- nelController. Skript poskytuje skriptu MovementController metody pro sestavení tunelu a práci s jeho vizualizací. Metoda CreateNewTunnel() vrací referenci na vytvořenou instanci no- vého tunelu na základě předané instance pohybu (Movement) a datového pro- cesoru (IDataProcessor). Je volána metoda DataCollection.LoadData() knihovny AAPD, která načte data předcvičeného pohybu ze souboru kon- krétního trackeru. Pole20 kolekcí dat je pak společně s instancí IDataPro- cessor předáno konstruktoru Tunnel. Nad tunelem se ještě volá metoda pro načtení dat reprezentující neutrální polohu předcvičeného pohybu. Metoda StartProcessing() transformuje data předcvičeného pohybu na základě aktuální transformace hrudního trackeru pacienta a následně zob- razí vizualizaci tunelu. Transformace dat je provedena voláním metody Tun- nel.TransformTo(). Data je nutné transformovat, jelikož pacient se může nacházet v prostoru jinde, než kde se nacházel terapeut při nahrávání po- hybu21. Vizualizaci provádí metoda DisplayTunnel(). Je provedena vizualizace trajektorie předcvičeného pohybu, kterou má pacient následovat. Základní vizualizace je řešena pomocí Unity komponenty LineRenderer. Komponenta mezi předanými body vykreslí přímku. Pro každý tracker tak existuje jedna komponenta vizualizující jakým způsobem jím bylo pohybováno v průběhu předcvičení. Body pro vizualizaci jsou získané z Tunnel.RawData, která vrací již transformovaná data pohybu. Přestože provádění pohybu je spojitá čin- nost, jeho zaznamenání je však diskrétní, jelikož transformace trackerů jsou vždy zaznamenány pouze v jednotlivých snímcích metody Update(). Vy- kreslením úsečky mezi dvěma po sobě jdoucími body pak zajišťuje spojitou vizualizaci. Jednotlivé body, které jsou použité k vizualizaci, mohou být různé na zá- kladě konfigurace a typu pohybu. Pokud pohyb nemá vrchol, viz sekce 5.3.2, pak jsou vždy zobrazeny všechny body. Pokud vrchol má, tak je ještě možné nastavit aby se zobrazovala buď jen část pohybu od počátku do vrcholu, nebo je možné nastavit, že se bude přepínat mezi trajektorií od počátku do vrcholu a z vrcholu do konce22, tzn. je vizualizována trajektorie na základě

20Pro každý tracker jedna kolekce. 21To by mělo značný vliv na analýzu pohybu, která je postavená na principu hledání nejbližšího bodu. 22Při pohybu s vrcholem je sice pohyb tam a zpět prováděn po relativně stejných

46 fáze pohybu, ve které se pacient nachází. Získání rozsahu bodů umožňuje metoda GetBounds() a přepínání SwapTunnel(). Vizualizované křivky je možno vypnout pro jednotlivé trackery jak již bylo popsáno u atributů Movement. Do křivek jsou ještě vložené kostky. Kostky jsou umístěné na bodech tvořící křivku. Jelikož bodů je hodně, je kostka zobrazena pouze na každém 20. bodu. Kostka má obarvené stěny a je orientovaná tak, jak byl orientovaný tracker při nahrávání pohybu. Je-li nastaven model trackeru také na kostku, pak by při provádění pohybu měla její orientace (a tedy orientace trackeru) odpovídat kostkám ve křivce.

5.3.4 Animace Jak bylo popsáno v sekci 4.2 bylo nutné, za účelem definování vlastního pohybu, pracovat s animacemi 3D modelu horní končetiny trochu jinak, než je tomu v Unity zvykem. Tvorbu vlastních animací pohybů provádí aplikace Alexe Königa [12]. Animační data jsou předána rehabilitační aplikaci, ve které je s nimi dále pracováno. Třída AnimationData reprezentuje načtená data animace. Vlastní ani- mace je vlastně tvořena pouze lokálními rotacemi kostí v jednotlivých sním- cích. Soubor nesoucí data je pak strukturován podle snímků následovně. První řádka snímku obsahuje rotace ramenní a předloketní kosti. Následuje 21 řádek, kde na každé řádce je rotace jedné z kostí dlaně. Struktura první řádky je tedy a zbylé řádky snímku . Třída metodou ReadData() z předaného souboru data načte, a kolekci snímků uloží. Pro samotné přehrávání animací pak slouží abstraktní třída Animati- onPlayer a její konkrétní implementace RotationAnimationPlayer. Třída z konstruktoru převezme objekt, který bude animovat, a definici pohybu (MovementDefinition), ze které získá referenci na AnimationData. Pře- hraní animace v konkrétní fázi prováděného pohybu provádí metoda Pla- yAnimation(). Metoda volá AnimationData.GetBonesRotations(), která vrátí příslušný snímek rotací dle předané fáze. Následně je kostem modelu nastavena jejich lokální rotace ze získaného snímku23. trajektoriích, pohyb ovšem nikdy nebude tak perfektní aby byly identické. 23Animace je pouze závislá na aktuální fázi pohybu pacienta, tzn. pokud se fáze nemění, tak objekt není animován, respektive se nemění rotace jeho kostí.

47 5.3.5 Konfigurace Konfigurace rehabilitační aplikace je prováděna nastavováním parametrů několika konfiguračních souborů. Všechny konfigurační soubory jsou typu XML. Pro každý soubor existuje třída/skript, která se stará o jeho načítání. Soubory se musí nacházet v adresáři StreamingAssets. Dále budou popsána struktura souborů a jejich parametry. config.xml Soubor config.xml slouží jako hlavní konfigurační soubor aplikace. O jeho načítání se stará třída ConfigDataReader. Hlavní účel souboru je defino- vání posloupnosti cvičení, která budou pacientem prováděna, tzn. samotnou rehabilitační sekvenci. Dále se zde nastavují nějaká dodatečná globální na- stavení (třída GlobalSettings). Možná jednoduchá struktura souboru: czech false Cube false false

threeballs 0.9 0.3 5 Parametry cvičení byly popsány v sekci 5.3.2. Tag lang specifikuje, jaký bude použit jazyk textů GUI. V aplikaci jsou podporované dva jazyky: češ- tina a angličtina, viz sekce 5.3.5. Tag hide_hint_arrow indikuje, zda bude zobrazována šipka při hře spojování míčů. Při hodnotě false bude šipka zobrazena, při hodnotě true se šipka zobrazovat nebude. Tag tracker_- model definuje, jaký bude model trackerů v hlavní scéně. Modely jsou dva: Cube, model trackerů bude krychle s obarvenými stěnami, stejné jako krychle

48 v trajektoriích tunelu, viz sekce 5.3.3, a Capsule, model trackerů je barevný plošný tvar, jehož barva odpovídá barvě trajektorie tunelu pro daný trac- ker. Tag hide_cubes_in_tunnel umožňuje schovat kostky v trajektoriích tunelu. Hodnota tagu show_tunnel_only_to_apex indikuje, zda bude zob- razena trajektorie tunelu pouze od začátku do vrcholu tunelu, nebo jestli bude mezi trajektoriemi přepínáno. movement-definitions.xml V tomto souboru jsou jsou definovány všechny pohyby, které je možné po- užít v sadě cvičení souboru config.xml. Definice ze souboru načítá skript MovementDefinitionsReader. Struktura souboru s jedním definovaným po- hybem: diag1_l left Data/diagonal1-left/ AnimationData/diagonal1-left.csv true Parametry definující pohyb jsou popsané v sekci 5.3.2. Souborové cesty musí být relativní vůči adresáři StreamingAssets. language.xml V souboru jsou definovány jednotlivé řetězce použité pro texty GUI v apli- kaci. Aktuálně je podporovaná čeština a angličtina. Je zde možné přidat překlady pro další jazyky. V souboru jsou definované názvy cvičení v daném jazyce. Left1 diagonal Leva1 diagonala

49 Soubor načítá třída Language, která poskytuje statickou metodu GetStr- ing(). Metoda podle jména řetězce vrací jeho načtenou hodnotu. U názvů cvičení musí hodnota atributu name, tagu string, odpovídat definovanému id. tunnel-config.xml V souboru je možné nastavit různé parametry analyzátoru pohybu knihovny AAPD. Nastavují se zde především váha pozice a rotace jednotlivých trac- kerů. Váha může být hodnota z intervalu (0;1>, která reprezentuje jaký bude mít vliv při analýze prováděného pohybu.

5.4 Testování

Aplikace byla vyvíjena a její funkcionalita testována v laboratoři pro vir- tuální realitu na Katedře informatiky a výpočetní techniky Fakulty apliko- vaných věd. Vývoj aplikace probíhal iteračním způsobem. Jednotlivé verze softwaru byly dodávány týmu FNKV. Tým FNKV s jednotlivými verzemi prováděl experimentální měření s cílovou skupinou pacientů. Tím tak byla ověřována dosud implementovaná funkcionalita. Při měření se samozřejmě objevila celá řada chyb, které při testování v laboratoři nalezeny nebyly. Chyby softwaru bylo vždy snahou do další pře- dávané verze opravit. Zároveň probíhala s týmem diskuze o tom, co by se v další verzi mělo objevit nebo co je nutné vylepšit. V dalším vývoji pak vždy byl brán zřetel na odezvu pacientů, kteří se do experimentů zapojili, a terapeuta, který experimenty prováděl. Na základě diskuzí a odezvy uživa- telů byla implementovaná nová domluvená funkcionalita, která byla nejprve otestovaná veVR laboratoři a po odladění nedostatků znovu dále předána. Tým FNKV provedl pilotní studii, ke které byla využita jedna z verzí vytvářeného softwaru. V této studii proběhlo patnáct jedno hodinových re-

50 habilitačních schůzek. Některá cvičení, například pohyb vstávání, proběhla v rehabilitační aplikaci. Studie se zúčastnily tři ženy, v průměrném věku 59 let, trpící roztroušenou sklerózou typu relaps remitentní, viz sekce 2.1.1. Výsledkem této studie bylo určité zlepšení v provádění pohybů, ale zároveň došlo ke zhoršení rychlosti jejich provedení. Pacienti se po studii cítí výrazně lépe. Výsledky tak naznačují, že by software mohl pacientům, trpícím touto chorobou, v rehabilitacích napomáhat. Nicméně pro ověření tohoto výsledku je nutné provést studii s větším počtem pacientů. Aktuálně je v přípravě od- borný článek, který bude výsledky této studie shrnovat. Výslednou verzi softwaru, této bakalářské práce, bylo v plánu ve Fakultní nemocnici zprovoznit a následně provést další experimentální měření. To se bohužel zatím nestalo z důvodu vypuknutí pandemie virové choroby Covid- 19.

5.5 Nedostatky a potencionální budoucí roz- šíření

Jedním nedostatkem aplikace je fakt, že aktuálně dokáže podporovat pouze jednoho terapeuta. První, konfigurační, scéna umožňuje změření rozměrů pacienta a terapeuta. Je předpokládáno, že měřený terapeut je ten, který prováděl předcvičení všech naměřených pohybů přidaných k aplikaci. To v průběhu vývoje nebyl problém, jelikož probíhala spolupráce pouze s jedním terapeutem FNKV. Pokud by však došlo k situaci, kdy budou do aplikace přidány pohyby naměřené několika různými terapeuty a pohyby by následně byly zahrnuty do sestavy cvičení pacienta, nastal by problém. S největší prav- děpodobností by terapeuti byli různých fyzických rozměrů. Jelikož je možné změřit pouze jednoho terapeuta, nedošlo by ke správnému nastavení pohybů naměřených ostatními terapeuty. Nejjednodušším řešením tohoto problému by bylo rozměr terapeuta měřit přímo před prováděním předcvičovaného pohybu a údaj uložit společně s daty naměřeného pohybu. V rehabilitační aplikaci by pak bylo prováděno měření rozměrů pouze pacientů a u každého pohybu by byl určen jeho poměr s konkrétním terapeutem. Aplikace neprovádí kontrolu všech vstupních hodnot. Pokud je tedy za- dána nějaká hodnota parametru špatně, aplikace se s tímto stavem nemusí vypořádat a nebude tak fungovat správně. To znamená, že aplikace funguje s předpokladem, že dostane korektní hodnoty parametrů. To samozřejmě není ideální situace a je to určitě funkcionalita, kterou by bylo potřebné dodělat. S tím je spojený další nedostatek a to, že aplikace spoléhá na dodržo-

51 vání několika konvencí. Nejdůležitější z nich je správné nasazení trackerů. Bylo by vhodnější aby aplikace sama dokázala automatickou detekci špatně nasazeného trackeru a uživatele na to upozornila. Aplikace aktuálně načítá sadu cvičení pouze z jednoho konfiguračního souboru, viz sekce 5.3.5. Terapeut typicky pro pacienta připraví sadu cvičení na základě toho, jakou část horní končetiny s ním chce procvičit. Z toho důvodu by asi bylo vhodnější umožnit terapeutovi výběr z více souborů. Nemusel by pak sadu cvičení pokaždé definovat znovu, ale pouze by došlo k definici jedné sady, která by se dala použít několikrát. Jedním z možných rozšíření je přidání dalších rehabilitačních her. V apli- kaci je vytvořen systém, kdy je další hry možné doprogramovat, viz sekce 5.3.2. Každopádně jak je v sekci poznamenáno, je u her problém především interakce s uživatelem, kvůli nemožnosti použití Vive ovladačů. Možným ře- šením tohoto problému by mohlo být prozkoumání technologie Leap Motion, která umožňuje sledování pohybů dlaní a prstů bez nutnosti použití jakého- koliv ovladače či rukavice. Pacienti by tak mohli lépe interagovat s virtuálním prostředím aplikace, což by mohlo otevřít i další, nejen herní, možnosti. Dal- ším řešením by mohl být přechod ze systému HTC Vive na Oculus Quest, který možnost sledování dlaní umožňuje také. S přechodem na jiný systém by však nejdříve bylo nutné vyřešit problém nahrazení Vive trackerů, na kterých celý projekt stojí. Osobně si myslím, že by bylo potencionálně lepší, kdyby byl projekt tvořen pouze jednou aplikací. Aktuálně projekt tvoří aplikace pro nahrání pohybů, generaci animací, generování pozic míčů hry a rehabilitační. Pokud by došlo k integraci všech aplikací v jednu, bylo by nutné umožnit jejich ovlá- dání z uživatelského prostředí. Tím by se dle mého názoru značně ulehčila práce terapeuta. Nemusel by ovládat aplikace čtyři ale pouze jednu. Záro- veň by nemusel přistupovat ke konfiguračním souborům přímo z nějakého souborového průzkumníka, ale aplikace by se o ně starala automaticky. Určitě by stálo za to, poskytnout terapeutům podrobnější analýzu po- hybu. Aplikace umožňuje terapeutům nahrávat data pohybů prováděných pacienty. Z těchto dat lze řadu věcí změřit/spočítat. Bylo by pak především na týmu FNKV, jaké hodnoty by se jim hodily.

52 6 Závěr

Výsledkem práce je funkční, konfigurovatelná a především dále rozšiřitelná rehabilitační aplikace, implementovaná v herním enginu Unity. I přes určité nedostatky byly splněny hlavní cíle práce. Výsledná aplikace umožňuje tera- peutům sestavit pro pacienty sadu rehabilitačních cvičení. Pacienti tato cvi- čení provádí ve 3D virtuálním prostředí pomocí systému HTC Vive. Cviční je možné rozdělit do dvou kategorií, pohyby a hry. Pohyby fungují na principu analýzy dat o pozici a rotaci senzorů sys- tému HTC Vive v reálném čase. Pacientem prováděný pohyb je porovnáván se správně vykonaným pohybem figuranta (terapeuta). Data správně vyko- naného pohybu jsou v aplikaci pacientovi ve virtuálním světě vizualizována v podobě trajektorie, kterou pacient musí při pohybu následovat. Aplikace umožňuje terapeutovi definovat jakýkoliv další pohyb, který je možné k apli- kaci přidat bez nutnosti aplikaci znovu sestavit. Implementace her byla, především z důvodu omezené interakce s pacien- tem, značně limitovaná. Součástí aplikace je jedna jednoduchá hra, nicméně byl navržen systém, který umožňuje další hry doprogramovat. Výstupem aplikace jsou data a statistiky cvičení, která byla pacientem vykonána. Největším přínosem aplikace je především vizualizace pohybů, kterou pacient v reálném světě nezíská. Vizualizace by tak měla pacientovi daný pohyb značně zjednodušit.

53 Seznam zkratek

3D trojdimenzionální 14, 15, 24, 29, 32, 34, 37, 38, 42, 43, 47, 53

AAPD Automatic Arm Position Detection 32, 38, 42, 43, 46, 50

API Application Programming Interface 21, 27

FNKV Fakultní nemocnice Královské Vinohrady7, 50–52

FOV Field Of View 22

FPS Frames Per Second 19

GPS Global Positioning System 18

GUI Graphical User Interface 40, 44, 45, 48, 49

HMD Head-mounted display 16, 18, 19, 21, 31, 38, 40

IMU Inertial measurement unit 18, 23

RS Roztroušená skleróza8, 10–12

SDK Software Development Kit 30

UDP User Datagram Protocol 18

VR Virtuální realita 14–18, 30, 50

54 Literatura

[1] Ambler, Z. Základy neurologie. Galén, spol. s r.o., 2006. ISBN 80-246-1258-5.

[2] Bardi, J. What is Virtual Reality? [Definition and Examples] [online]. Marxent, 2019. [cit. 2020/04/07]. Dostupné z: https://www.marxentlabs.com/what-is-virtual-reality/.

[3] Brennan, D. SteamVR Update Adds Asynchronous Reprojection [online]. Road To VR, 2016. [cit. 2020/04/18]. Dostupné z: https://www.roadtovr. com/steamvr-update-adds-asynchronous-reprojection/.

[4] Buckley, S. This Is How Valve’s Amazing Lighthouse Tracking Technology Works [online]. Gizmodo, 2015. [cit. 2020/04/19]. Dostupné z: https://gizmodo.com/ this-is-how-valve-s-amazing-lighthouse-tracking-technol-1705356768.

[5] Co je to RS? [online]. 2020. [cit. 2020/03/01]. Dostupné z: http://ereska.cz/rs/index.html.

[6] Corporation, H. HTC Vive product [online]. HTC Corporation, 2020. [cit. 2020/04/17]. Dostupné z: https://www.vive.com/eu/product/#vive%20series.

[7] Education, V. Virtuální realita – historie a současnost [online]. VR Education, 2020. [cit. 2020/04/07]. Dostupné z: https: //vreducation.cz/virtualni-realita-historie-a-soucasnost/.

[8] Computing History, T. C. HTC Vive Virtual Reality [online]. The Centre for Computing History, 2020. [cit. 2020/04/17]. Dostupné z: http://www. computinghistory.org.uk/det/52936/HTC-Vive-Virtual-Reality/.

[9] Frank, J. Sběr 3D dat pro rehabilitační software ve virtuální realitě [online]. Jakub Frank, 2020. [cit. 2020/04/16].

[10] Goodrich, R. Accelerometer vs. Gyroscope: What’s the Difference? [online]. LiveScience, 2018. [cit. 2020/04/12]. Dostupné z: https: //www.livescience.com/40103-accelerometer-vs-gyroscope.html.

[11] Heaney, D. How VR Positional Tracking Systems Work [online]. UploadVR, 2019. [cit. 2020/04/19]. Dostupné z: https://uploadvr.com/how-vr-tracking-works/.

55 [12] König, A. 3D animace paže podle naměřených dat pro účely rehabilitace ve virtuální realitě [online]. Poór, Vítek, 2020. [cit. 2020/04/24].

[13] McIntosh, C. W. Understanding Simulator Sickness [online]. Children’s Hospital of Philadelphia, 2018. [cit. 2020/04/07]. Dostupné z: https://injury.research.chop.edu/blog/posts/ understanding-simulator-sickness.

[14] Poór, V. Automatická analýza pohybu ramene pro účely rehabilitace ve virtuální realitě [online]. Poór, Vítek, 2019. [cit. 2020/04/24]. Dostupné z: https://bitbucket.org/Custom666/aapd/src/master/AAPD_ BakalarskaPrace.pdf.

[15] O roztroušené skleróze [online]. Nadační fond impuls, 2020. [cit. 2020/03/01]. Dostupné z: https://www.nfimpuls.cz/index.php/ roztrousena-skleroza/o-roztrousene-skleroze/ 161-roztrousena-skleroza-mozkomisni-co-by-mel-nelekar-vedet.

[16] Snopková, N. Kvalita života pacienta sroztroušenou sklerózou [online]. 2020. [cit. 2020/03/18]. Dostupné z: https://dspace5.zcu.cz/bitstream/11025/17937/1/Nikola% 20Snopkova%20%28MVS%202%29%20Kvalita%20zivota%20pacienta%20s% 20roztrousenou%20sklerozou.pdf.

[17] Society, V. R. What is Virtual Reality? [online]. Virtual Reality Society, 2017. [cit. 2020/04/07]. Dostupné z: https: //www.vrs.org.uk/virtual-reality/what-is-virtual-reality.html.

[18] Souppouris, A. How HTC and Valve built the Vive [online]. Engadget, 2016. [cit. 2020/04/16]. Dostupné z: https: //www.engadget.com/2016-03-18-htc-vive-an-oral-history.html.

[19] Unity Technologies. Unity User Manual (2019.3) [online]. Unity Technologies, 2020. [cit. 2020/04/24]. Dostupné z: https://docs.unity3d.com/Manual/index.html.

[20] Unity Technologies. Game engines—how do they work? [online]. Unity Technologies, 2020. [cit. 2020/04/24]. Dostupné z: https://unity3d.com/what-is-a-game-engine.

[21] Xinreality. Head-mounted display [online]. Xinreality, 2018. [cit. 2020/04/09]. Dostupné z: https://xinreality.com/wiki/Head-mounted_display.

[22] Xinreality. Lighthouse [online]. Xinreality, 2017. [cit. 2020/04/19]. Dostupné z: https://xinreality.com/wiki/Lighthouse.

56 [23] Yates, A. SteamVR’s "Lighthouse"for Virtual Reality and Beyond [online]. Tested, 2015. [cit. 2020/04/19]. Dostupné z: https://www.youtube.com/watch?v=xrsUMEbLtOs.

[24] Řasová, K. Fyzioterapie u neurologicky nemocných (se zaměřením na roztroušenou sklerózu mozkomíšní). CEROS Centrum komplexní neurorehabilitační péče pro nemocné s roztroušenou sklerózou, o.p.s, 2007. ISBN 978-80-239-9300-4.

57 A Přílohy

A.1 Seznam obrázků

2.1 Neuron - základní jednotka nervové soustavy...... 9

3.1 Balíček HTC Vive...... 20 3.2 Základní stanice HTC Vive...... 22

4.1 Unity Editor...... 25 4.2 Okno pro tvorbu animací v Unity Editoru...... 28

5.1 Hra sbírání míčů...... 35 5.2 Prvky pohybů...... 36 5.3 Uživatelské rozhraní terapeuta...... 37 5.4 Aplikační stavy...... 39

A.2 Uživatelská příručka

A.2.1 Sestavení Aplikace byla vyvíjena v Unity editoru verze 2019.3.0, která je dostupná ke stažení na adrese https://unity3d.com/get-unity/download/archive. Po otevření projektu aplikace1 v Unity editoru je pro sestavení nutné kliknout na File > Build Settings. Objeví se okno, ve kterém je možné provedení sestavení. Pro správné fungování aplikace je nutné do aplikace zahrnout obě scény, SetUpScene a MainScene, přičemž je nutné, aby scéna SetUp byla jako první2. Následně je nutné zvolit platformu PC, Mac & Linux Standa- lone. Po zvolení cílové platformy je možné kliknout na tlačítko Build.V zobrazeném dialogu je nutné zvolit adresář do kterého se aplikace sestaví. Po zvolení adresáře proběhne sestavení aplikace.

A.2.2 Spuštění Po sestavení aplikace je ji možno spustit dvojklikem na soubor VR Rehabi- litation.exe, nacházející se ve zvoleném adresáři. Možnosti aplikace byly

1Projekt je dostupný na CD v příloze této práce, nebo na git repositáři https:// gitlab.com/frankkuba/vr-arm-motion. 2Přetažením je možné scény prohodit.

58 popsány v sekci 5.1. Konfigurace v sekci 5.3.5.

A.2.3 Binding trackerů Při konfiguraci je nutné spárovat všechny trackery s příslušnou rolí, jinak software nebude fungovat správně a bude docházet k prohazování trackerů. Pro spárování trackerů stiskněte po spuštění aplikace současně pravý SHIFT + B. Pro svázání jednotlivých rolí je potřeba zvolit požadovanou kartu, poté vybrat požadované zařízení a přiřadit mu předem určenou roli. Zařízení se vybírá z přehledové mapy scény v pravém dolním rohu kliknutím levým tla- čítkem myši. Pokud již nějaké zařízení spárováno, lze toto nastavení smazat pomocí kliknutí na křížek v příslušném řádku. Před opuštěním konfigurace je nutné uložit změny. Zavedenou konvenci pro bindingu zařízení je možno vidět v tabulce A.1.

Umístění Binding role Barva podstavy headset head hrudník tracker1 popruh na hrudník levé zápěstí tracker2 bílá levá ruka tracker3 červená pravá ruka tracker4 fialová pravé zápěstí tracker5 žlutá židle tracker6 modrá (úchyt na židli)

Tabulka A.1: Tabulka zavedené konvence pro binding trackerů

A.2.4 Definice vlastního pohybu Dále popisovaný postup předpokládá, že již byla získána data z aplikací3 pro nahrání pohybu [9] a data animace nahraného pohybu [12]. Uvedené souborové cesty jsou relativní ke kořenovému adresáři sestavené aplikace. Složku s daty pohybu je potřeba nakopírovat do složky VR Rehabili- tation_Data/StreamingAssets/Data/. Soubor s daty animace je potřeba na- kopírovat do složky StreamingAssets/AnimationData/. Následně je potřeba do souboru movement-definitions.xml nacházející se ve složce VR Rehabili- tation_Data/StreamingAssets přidat nový záznam o pohybu, viz sekce 5.3.5. Na závěr je nutné definovat název pohybu. Ten se definuje v souboru VR Rehabilitation_Data/StreamingAssets/language.xml, viz sekce 5.3.5. Tímto

3Aplikace se nacházejí na CD v příloze práce.

59 je pohyb přidán do aplikace a je možné ho zapojit do cvičení ze souboru VR Rehabilitation_Data/StreamingAssets/config.xml, viz sekce 5.3.5. V případě že by se nejednalo přidání zcela nového pohybu, ale například pouze přeměření, není nutné definovat další pohyb ale pouze u stávajícího změnit data.

A.3 Obsah DVD

• Animation Generation Build.zip — soubor obsahují adresář se se- stavenou aplikací, vyvinutou Alexem Königem, pro generaci animací nových pohybů

• Bakalarska prace.pdf — soubor s textem této práce

• Ball Configuration Project.zip — soubor s adresářem Unity pro- jektu aplikace, vyvinutou Jakubem Frankem, pro definici pozic míčů hry

• Data Recorder Project.zip — soubor s adresářem Unity projektu aplikace, vyvinutou Jakubem Frankem, pro nahrávání pohybů

• Movement Videos.zip — soubor obsahují adresář s videi, která uka- zují předcvičování pohybů, které jsou součástí rehabilitační aplikace

• VR Rehabilitation Build.zip — soubor obsahující adresář s již se- stavenou rehabilitační aplikaci

• VR Rehabilitation Project.zip — soubor obsahující adresář Unity projektu rehabilitační aplikace

60