Interacció amb realitat augmentada a partir del dispositiu Kinect

Interacci´o amb Realitat Augmentada a partir del dispositiu Kinect Treball Final de Grau - Mem` oria Otger Rogl`a Pujalt Data de defensa: 27 de Juny de 2014 Director: Antonio Sus´ın S´anchez Departament de Matem`atica Aplicada I (MA1) Ponent: Antonio Chica Calaf Departament de Llenguatges i Sistemes Inform`atics (LSI) Titulaci´o: Grau en Enginyeria Inform`atica Especialitat: Computaci´o Facultat d’Inform` atica de Barcelona (FIB) Universitat Polit` ecnica de Catalunya (UPC) – BarcelonaTech 20 de Juny de 2014 Resum En aquest Treball Final de Grau s’ha desenvolupat un programari que permet simular objectes simples amb certs comportaments f´ısics sobre una escena real captada mitjan¸cant un dispositiu Kinect, dins de l’`ambit conegut com a realitat augmentada. Per tal d’aconseguir-ho s’ha implementat una interf´ıcie gr`afica utilitzant les llibreries QT i OpenCV que permet visualitzar les dades proporcionades per un o m´es Kinects, aix´ı com emmagatzemar-les i reproduir-les. Sobre aquesta interf´ıcie s’ha desenvolupat l’aplicaci´o esmentada, utilitzant la llibreria Bullet per a la simulaci´o f´ısica i OpenGL per la visualitzaci´o de l’escena augmentada. Resumen En este Trabajo Fin de Grado se ha desarrollado un software que permite simular objetos simples con ciertos comportamientos f´ısicos sobre una escena real captada mediante un dispositivo Kinect, dentro del ´ambito conocido como realidad aumentada. Para conseguirlo se ha implementado una interfaz gr´afica utilizando las librer´ıas QT y OpenCV que permite visualizar los datos proporcionados por uno o m´as Kinects, as´ı como guardarlos y reproducirlos. Sobre esta interfaz se ha desarrollado la aplicaci´on mencionada, usando la librer´ıa Bullet para la simulaci´on f´ısica y OpenGL para la visualizaci´on de la escena aumentada. Abstract In this bachelor’s thesis a software has been developed to simulate simple objects having different physical behaviours over a real scene captured through a Kinect, within the field known as augmented reality. To achieve this, a graphical interface has been implemented using the QT and OpenCV libraries which allows the visualization of the data provided by one or more Kinects, as well as to record it and replay it at a later time. The aforementioned application has been developed on this interface, using the Bullet library for the physics simulation and OpenGL to render the resulting augmented scene. 1 ´ Index 1 Introducci´o 7 1.1 Formulaci´o del problema . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2 Objectiusiabast ............................ 8 1.3 Possiblesobstacles ........................... 9 1.4 Actors implicats en el projecte . . . . . . . . . . . . . . . . . . . . . 11 1.5 Integraci´o de coneixements . . . . . . . . . . . . . . . . . . . . . . . 12 1.6 Compet`encies t`ecniques desenvolupades . . . . . . . . . . . . . . . . 13 1.6.1 CCO1.1 ............................. 13 1.6.2 CCO2.2 ............................. 13 1.6.3 CCO2.3 ............................. 14 1.6.4 CCO2.6 ............................. 14 2 Estat de l’art 15 2.1 DispositiuKinect............................ 15 2.2 Simulaci´o f´ısica en realitat augmentada . . . . . . . . . . . . . . . . 18 2.3 Reconstrucci´o d’escenes tridimensionals . . . . . . . . . . . . . . . . 19 2.4 ´ Us i calibratge de color i profunditat . . . . . . . . . . . . . . . . . 19 2.5 Preprocessat de les dades . . . . . . . . . . . . . . . . . . . . . . . . 20 2.6 Acceleraci´o dels c`alculs . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.7 Precisi´o i limitacions del dispositiu . . . . . . . . . . . . . . . . . . 20 2.8 Tractament d’imatges . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.9 ´ Us de m´ultiples dispositius . . . . . . . . . . . . . . . . . . . . . . . 21 2.10Simulaci´of´ısica ............................. 21 2.11Visualitzaci´o............................... 21 3 Metodologia i rigor 23 3.1 M`etodedetreball............................ 23 3.2 Einesdeseguiment ........................... 23 3.3 M`etode de validaci´o . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.4 Canvis en la metodologia . . . . . . . . . . . . . . . . . . . . . . . . 24 2 ´ INDEX ´ INDEX 4 Implementaci´o 25 4.1 Llibreries utilitzades . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1.1 QT................................ 25 4.1.2 OpenCV............................. 26 4.1.3 Bullet Physics Library . . . . . . . . . . . . . . . . . . . . . 26 4.1.4 OpenGL............................. 26 4.2 Interf´ıciegr`afica............................. 27 4.2.1 Dissenygeneral ......................... 27 4.2.1.1 Streams........................ 29 4.2.1.2 Operacions . . . . . . . . . . . . . . . . . . . . . . 30 4.2.1.3 Modes......................... 31 4.2.2 Funcionalitats.......................... 31 4.2.2.1 Visualitzaci´o de les dades dels Streams . . . . . . . 31 4.2.2.2 Llista d’Streams . . . . . . . . . . . . . . . . . . . 32 4.2.2.3 Captura d’Streams . . . . . . . . . . . . . . . . . . 32 4.2.2.4 Reproducci´o d’Streams . . . . . . . . . . . . . . . . 33 4.2.2.5 Calibratge de dispositius Kinect . . . . . . . . . . . 34 4.2.2.6 Vista de l’escena . . . . . . . . . . . . . . . . . . . 35 4.3 Simulaci´of´ısica ............................. 37 4.3.1 Creaci´o del m´on f´ısic . . . . . . . . . . . . . . . . . . . . . . 37 4.3.2 Introducci´o d’objectes senzills . . . . . . . . . . . . . . . . . 37 4.3.3 Determinaci´o del pla de terra . . . . . . . . . . . . . . . . . 38 4.3.4 Esquelets dels usuaris . . . . . . . . . . . . . . . . . . . . . . 38 4.4 Visualitzaci´o de la realitat augmentada . . . . . . . . . . . . . . . . 41 4.4.1 Dibuixat de l’escena real . . . . . . . . . . . . . . . . . . . . 41 4.4.2 Dibuixat de l’escena virtual . . . . . . . . . . . . . . . . . . 41 4.4.3 Oclusi´o.............................. 44 4.4.4 Correcci´o del mapa de profunditat . . . . . . . . . . . . . . 46 4.5 Aplicaci´od’exemple........................... 50 5 Planificaci´o 52 5.1 Consideracions ............................. 52 5.2 Planificaci´oenfases........................... 52 5.2.1 Fase de disseny i planificaci´o . . . . . . . . . . . . . . . . . . 53 5.2.2 Fase de preparaci´o . . . . . . . . . . . . . . . . . . . . . . . 53 5.2.3 Desenvolupament en iteracions . . . . . . . . . . . . . . . . . 54 5.2.4 Fasefinal ............................ 55 5.2.5 Estimaci´o d’hores . . . . . . . . . . . . . . . . . . . . . . . . 55 5.2.6 Plad’acci´o............................ 55 5.3 Planificaci´o inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.4 Alteracions en la planificaci´o . . . . . . . . . . . . . . . . . . . . . . 57 3 ´ INDEX ´ INDEX 5.4.1 Canvis.............................. 57 5.4.2 Efectes sobre els objectius i desenvolupament . . . . . . . . 57 5.4.3 Efectes sobre els costs . . . . . . . . . . . . . . . . . . . . . 58 5.5 Planificaci´ofinal............................. 58 6 Recursos i costs 60 6.1 Recursos................................. 60 6.1.1 Recursoshumans ........................ 60 6.1.2 Recursos materials . . . . . . . . . . . . . . . . . . . . . . . 60 6.1.3 Software............................. 61 6.2 Pressupost................................ 62 6.2.1 Identificaci´o i estimaci´o dels costs . . . . . . . . . . . . . . . 62 6.2.2 Viabilitat econ`omica . . . . . . . . . . . . . . . . . . . . . . 65 6.2.3 Pladecontrol.......................... 65 6.3 Desviacions del pressupost . . . . . . . . . . . . . . . . . . . . . . . 65 7 Sostenibilitat 66 7.1 Impactesocial.............................. 66 7.2 Impacteambiental ........................... 66 7.3 Control de la sostenibilitat . . . . . . . . . . . . . . . . . . . . . . . 67 7.4 Lleisiregulacions............................ 68 8 Conclusions 69 8.1 Assoliment dels objectius . . . . . . . . . . . . . . . . . . . . . . . . 69 8.2 Treballfutur............................... 70 Bibliografia 71 4 ´ Index de figures 2.1 Sensors del Kinect i la seva distribuci´o. . . . . . . . . . . . . . . . . 16 2.2 Model d’esquelet usat pel Kinect. . . . . . . . . . . . . . . . . . . . 17 4.1 Captura d’exemple de la interf´ıcie gr`afica implementada. . . . . . . 28 4.2 Finestra de la interf´ıcie amb la llista d’streams. . . . . . . . . . . . 32 4.3 Finestra de la interf´ıcie de captura d’streams. . . . . . . . . . . . . 33 4.4 Efectes de la compressi´o amb p`erdua d’imatges de profunditat. . . . 33 4.5 Finestra de la interf´ıcie per la vista de l’escena. . . . . . . . . . . . 36 4.6 Exemple del modelat f´ısic d’un esquelet. . . . . . . . . . . . . . . . 40 4.7 Diagrama de la projecci´o en perspectiva. . . . . . . . . . . . . . . . 42 4.8 Matriu de projecci´o en perspectiva d’OpenGL. . . . . . . . . . . . . 42 4.9 Codi del Fragment Shader per a dibuixar l’escena real. . . . . . . . 46 4.10 Exemples de la correcci´o del mapa de profunditat. . . . . . . . . . . 47 4.11 Exemple de la correcci´o del mapa de profunditat amb “mem`oria”. . 48 4.12 Exemple de la oclusi´o amb el mapa de profunditat corregit. . . . . . 49 4.13 Exemple de realitat augmentada amb una torre de caixes. . . . . . . 50 4.14 Exemple de realitat augmentada amb una esfera parcialment oclusa. 51 5.1 Diagrama Gantt de la planificaci´o inicial. . . . . . . . . . . . . . . . 56 5 ´ Index de taules 6.1 Pressupost i dedicaci´o en hores pels rols implicat . . . . . . . . . . 62 6.2 Pressupost de Hardware . . . . . . . . . . . . . . . . . . . . . . . . 63 6.3 Pressupost de Software . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.4 Pressupost de despeses addicionals . . . . . . . . . . . . . . . . . . 64 6.5 Pressuposttotal............................. 64 6 Cap´ıtol 1 Introducci´o 1.1 Formulaci´o del problema En els darrers temps un dels camps de la inform`atica que est`a despertant molt d’inter`es correspon al de la realitat augmentada. Aquesta `area es centra en la captura de dades que representen la realitat, que a continuaci´o solen ser processades per tal d’extreure’n informaci´o, i que abans de ser mostrades en temps real a l’usuari s´on enriquides amb dades virtuals addicionals, “augmentant” aix´ı la realitat. Habitualment les dades capturades s´on imatges, que s´on processades per tal de detectar persones i/o objectes aprofitant t`ecniques del camp de la visi´o per computador. Un exemple cada cop m´es habitual a la vegada que simple es pot trobar en les c`ameres fotogr`afiques, que detecten cares humanes i mostren rectangles al seu voltant. Una aplicaci´o interessant pot resultar d’anar un pas m´es enll`a de la simple addici´o d’informaci´o, i simular la interacci´o f´ısica amb elements virtuals afegits a l’escena. En videojocs, animacions, i d’altres camps, t´ıpicament es simulen entorns de realitat virtual on tots els objectes es generen per computador. Amb realitat augmentada es podrien afegir objectes amb diversos comportaments f´ısics, que interactuessin amb les persones i els objectes de la realitat. Algunes possibles aplicacions d’aquesta tecnologia podrien ser el desenvolupament de videojocs interactius, com per exemple jocs did`actics o simuladors lliures. No obstant, aconseguir realitzar aix`o requereix m´es que un simple processament d’imatges de color: cal poder fer la reconstrucci´o d’un model tridimensional amb elements de l’escena (usuaris, terra, etc.), i per tant cal disposar de m´es informaci´o 7 1.2. OBJECTIUS I ABAST CAP´ ITOL 1. INTRODUCCI ´ O de la que podem obtenir per aquesta via, per tal de poder determinar la posici´o i mida relativa dels objectes de forma m´ınimament fiable. Un element capa¸c de proporcionar aquesta informaci´o addicional ´es el Kinect, de Microsoft, dissenyat inicialment com a un dispositiu d’entrada per a videojocs, per`o que cada vegada guanya m´es rellev`ancia en aplicacions serioses en camps tals com la medicina gr`acies a la seva relativament bona qualitat per un preu molt econ`omic. Aquest dispositiu incorpora una c`amera de v´ıdeo, per`o a la vegada tamb´e disposa d’una c`amera d’infrarojos capa¸c de generar un mapa de profunditat de l’escena captada. A partir d’aquesta informaci´o, el seu software ´es capa¸c de realitzar tasques m´es avan¸cades servint-se d’algorismes complexos, permetent entre altres coses la detecci´o i reconstrucci´o d’esquelets simplificats de les persones dins de l’escena, el modelat d’objectes tridimensionals, etc. Aix´ı doncs, l’objectiu que es proposa aquest projecte ´es desenvolupar un software capa¸c de simular objectes virtuals que segueixen unes certes lleis f´ısiques sobre una escena captada en temps real, realitzant una implementaci´o en el llenguatge de programaci´o C++ i servint-se del dispositiu Kinect i de les seves llibreries. Es busca tant desenvolupar aquest software, com algun escenari senzill que permetin veure’l en funcionament al final. Addicionalment s’explorar`a la possibilitat de combinar les dades de m´es d’un dispositiu Kinect per millorar la precisi´o. 1.2 Objectius i abast El projecte es centrar`a en desenvolupar un software en C++ capa¸c de realitzar la simulaci´o f´ısica d’objectes virtuals en una escena captada de la realitat mitjan¸cant el dispositiu Kinect, utilitzant les llibreries corresponents del sensor i d’altres d’addicionals. No obstant, no es pret´en crear una soluci´o universal capa¸c de realitzar la simulaci´o de qualsevol tipus d’objecte en totes les escenes possibles, ja que aix`o resultaria inviable amb la tecnologia actual i requeriria un temps exorbitant. Dit aix`o, l’objectiu principal ´es aconseguir la capacitat de simulaci´o de cossos r´ıgids amb formes simples (cubs, esferes, etc) a l’escena amb diferents par`ametres f´ısics, fins al punt que resulti possible, aix´ı com desenvolupar com a m´ınim una aplicaci´o senzilla que demostri el seu funcionament. Un cop aconseguit aix`o, s’intentar`a afegir objectes m´es complexos o restriccions de moviment entre aquests per tal d’enriquir la capacitat de simulaci´o, segons el temps i els altres recursos restants arribat el punt. Tamb´e es podran desenvolupar aplicacions de demostraci´o addicionals. 8 Cap´ıtol 2 Estat de l’art Aquest cap´ıtol descriu l’estat de l’art en els temes relacionats amb els diversos subproblemes a resoldre dins del projecte. En un primer apartat es presenten les caracter´ıstiques del dispositiu Kinect aix´ı com les diferents APIs que es proporcionen en la darrera versi´o de la llibreria oficial, i les dades que permeten obtenir. En la resta d’apartats, s’enumeren els diversos subproblemes i l’estat de l’art en cada cas, incloent possibles aproximacions per enfrontar-s’hi, o b´e analitzant i comparant les llibreries que el poden resoldre. 2.1 Dispositiu Kinect El Kinect, desenvolupat per Microsoft, ´es a un dispositiu que cont´e diversos tipus de sensors. Originalment va ser ideat com a sistema de control i interacci´o per la consola de videojocs Xbox 360, permetent als usuaris usar el seu cos com a dispositiu d’entrada sense la necessitat d’haver de posar-se peces de roba o altres elements intrusius. Tot i aix`o, en els darrers anys ha sorgit inter`es per aquest dispositiu en l’`ambit acad`emic i comercial, ja que representa una alternativa molt econ`omica respecte a dispositus amb prestacions similars, i tot i que la qualitat no arriba als nivells d’aquests, per a un gran nombre d’aplicacions ja resulta suficient. La figura 2.1 mostra els sensors dels que disposa el Kinect, aix´ı com la seva distribuci´o. Aquests corresponen a: 15 2.1. DISPOSITIU KINECT CAP´ ITOL 2. ESTAT DE L’ART Figura 2.1: Sensors del Kinect i la seva distribuci´o. Font: Microsoft Developer Network •C`amera de color: una c`amera RGB que captura imatges de v´ıdeo amb una resoluci´o de 1280 x 960 p´ıxels. •C`amera de profunditat: un sistema format per un emissor i un sensor d’infrarrojos (IR) permet fer lectures de les dist`ancies als objectes. L’emissor emet un patr´o de llum estructurada, i el receptor n’interpreta les lectures de manera coordinada. La seva resoluci´o ´es de 640 x 480 p´ıxels. •Micr`ofons: una matriu de 4 micr`ofons que permet capturar so, aix´ı com determinar de manera parcial la seva posici´o. •Acceler`ometre: un acceler`ometre de 3 eixos que permet deterinar la orientaci´o actual del Kinect. Per aquest treball ens interessen els dos primers sensors, i per tant s´on en els que ens centrarem. La c`amera de profunditat representa el sensor m´es caracter´ıstic del Kinect, i el que el diferencia de les c`ameres convencionals. Els seus mesuraments permeten aconseguir funcionalitats com reconstruccions 3D que d’altra manera no es podrien realitzar de manera fiable. Per satisfer la demanda d’una API per a l’´us de la Kinect, Microsoft va proporcionar els controladors per a PC aix´ı com un SDK per a poder accedir a les diverses funcionalitats que implementa, tant des de C++ com des del llenguatge de programaci´o C#. Aquest SDK ha passat per diverses revisions, trobant-se actualment a la versi´o 1.8, on ve separat en dos m`oduls: un de principal Kinect for Windows SDK i un amb components espec´ıfics Kinect Developer Toolkit. La API de C++ del Kinect for Windows SDK presenta un conjunt de funcions globals per a inicialitzar el Kinect i obtenir-ne les dades. A m´es soporta un mode d’´us 16 2.1. DISPOSITIU KINECT CAP´ ITOL 2. ESTAT DE L’ART orientat a objectes pensat per a l’´us de m´ultiples Kinect. Totes aquestes funcions s´on f`acilment identificables ja que comencen per Nui (Natural User Interface). Les principals dades que permet obtenir aquesta API s´on: •Imatge de color: la imatge de la c`amera de color, en format RGB (3 bytes), i en una resoluci´o de b´e 640 x 480, o 1280 x 960 p´ıxels. •Imatge de profunditat: una matriu on cada p´ıxel cont´e dos elements de mida 2 bytes: la profunditat obtinguda per a cada p´ıxel en mil·l´ımetres respecte a la c`amera (valors entre 800 i 4000 mm), i un ´ındex que indica el n´umero d’usuari (si es detecta). Les resolucions suportades s´on: 80 x 60, 320 x 240 i 640 x 480 p´ıxels (en el darrer cas l’´ındex sempre ´es 0). •Esquelets: tamb´e calcula estimacions dels esquelets dels usuaris dins de la escena. Es guarden en una estructura NUI SKELETON FRAME, que cont´e la posici´o de les articulacions corresponents al model d’esquelet utilitzat (figura 2.2). Nom´es pot arribar a calcular les posicions de fins a 4 esquelets a la vegada, i per cada valor inclou flags per informar de si l’ha trobat de manera fiable, nom´es l’ha estimat, o si no l’ha pogut calcular. A m´es, aquesta estructura inclou algunes dades addicionals, entre les que destaquem una estimaci´o del pla del terra. Figura 2.2: Model d’esquelet usat pel Kinect. Font: Microsoft Developer Network 17 2.2. SIMULACI ´ O F´ ISICA EN REALITAT AUGMENTADA CAP´ ITOL 2. ESTAT DE L’ART El Kinect Developer Toolkit, per altra banda, es divideix en diversos m`oduls amb funcionalitats especifiques. Entre aquests destaquem: •KinectFusion: implementa la reconstrucci´o de volums tridimensionals a partir de les lectures de profunditat, que s’integren en un n´uvol de punts. Tamb´e permet la generaci´o de malles de triangles. •KinectInteraction: permet reconeixer gestos amb les mans, com per exemple si s’obren o es tanquen, o si es mouen a posicions donades. 2.2 Simulaci´o f´ısica en realitat augmentada Pel que fa a la tem`atica general d’aquest treball, la simulaci´o f´ısica en entorns de realitat augmentada mitjan¸cant Kinect, existeixen alguns projectes de tem`atica similar, per`o aquests resulten bastant focalitzats en certs tipus d’entorn com per exemple en superf´ıcies de taules [27, 7, 21]. Tamb´e s’han desenvolupat projectes semblants per`o amb dispositius diferents al Kinect. Per una banda, la majoria d’aquests treballs utilitzen dispositius que no disposen d’una manera de mesurar la profunditat, i es troben amb limitacions respecte all`o que poden arribar a fer [14, 2, 1]. Per l’altra banda, hi ha treballs que utilitzen dispositius m´es potents, per`o que a la vegada representen un major cost i en general no es poden trobar en entorns com les llars [10]. Amb aquest projecte es pret´en aconseguir una soluci´o utilitzant un dispositiu de baix cost com ´es Kinect, per`o que resulta potent a la vegada. Per tant, es podran aprofitar components en el desenvolupament, per`o s’haur`a de realitzar el disseny i la implementaci´o de l’esquema general aix´ı com de diverses parts espec´ıfiques ja que no ser`a possible adaptar solucions existents. Finalment, tamb´e cal tenir en compte que existeixen nombrosos estudis te`orics sobre les limitacions del realisme de simular objectes sobre un entorn real [18, 20]. Un exemple resulta la incapacitat dels objectes virtuals d’aplicar forces sobre objectes reals, cosa que en mobiliari o elements estructurals com el terra no tindria un efecte evident, per`o si en el cas d’objectes petits. 18 2.3. RECONSTRUCCI ´ O D’ESCENES TRIDIMENSIONALS CAP´ ITOL 2. ESTAT DE L’ART 2.3 Reconstrucci´o d’escenes tridimensionals S’ha estudiat la possibilitat de modelar f´ısicament, a part del terra i els usuaris, altres objectes de la escena, fet pel qual caldria reconstruir un model de l’entorn processant el mapa de profunditat. Les llibreries est`andard de Kinect proporcionen un m`odul anomenat KinectFusion dedicat precisament a la generaci´o de models tridimensionals d’objectes, amb la possibilitat de moure aquest o b´e el sensor per poder modelar-lo en la seva totalitat [12]. Tamb´e hi ha propostes d’implementacions alternatives, amb els respectius avantatges i inconvenients [13, 29]. La majoria d’aquestes implementacions utilitzen t`ecniques volum`etriques de construcci´o de models, que busquen la creaci´o de models llisos i detallats a partir de varis mapes de profunditat. La complexitat es presenta en forma de que l’algorisme ha de ser robust envers a punts erronis, i que ha de tenir en compte les direccions i el temps intentant aix´ı quadrar les noves dades amb les recollides fins al moment tot acomodant els moviments relatius entre els sensors i l’objecte a modelar. Es serveixen d’una graella tridimensional de v`oxels, i de tra¸cat de raigs, per determinar les cares del model resultant. No obstant, en aquest cas no interessa un nivell de detall molt elevat sin´o m´es aviat el contrari, per tal de poder obtenir models simplificats que facilitin la simulaci´o f´ısica, perqu`e funcioni en temps real. A m´es cal tenir en compte que en la majoria de casos tant els objectes de l’escena com el sensor seran est`atics, i el mapa de profunditat del que es disposar`a ser`a sempre fonamentalment el mateix. 2.4 ´ Us i calibratge de color i profunditat Una possible soluci´o a la potencial manca d’informaci´o del mapa de profunditat ´es utilitzar algorismes que tinguin en compte tamb´e la imatge de color captada per la c`amera [5, 22]. Aix`o presenta un problema d’entrada, que ´es la no correspond`encia directa entre els punts dels mapes de colors i profunditat deguda a que els sensors no es troben f´ısicament a la mateixa posici´o ni tenen les mateixes caracter´ıstiques (angle de visi´o, etc.). Per poder treballar amb els dos mapes cal doncs registrar o calibrar aquests dos sensors. Els m`etodes tradicionals com el d’utilitzar un tauler blanc i negre no es poden aplicar, degut a que el sensor de profunditat no ´es capa¸c de distingir colors. Tot i aix`o existeixen diversos m`etodes, per`o la majoria d’aquests intenten buscar punts d’inter`es comuns en les dues imatges, com podrien ser cantonades d’objectes, per calcular la correcci´o necess`aria a realitzar sobre les dades [33, 30]. 19 2.5. PREPROCESSAT DE LES DADES CAP´ ITOL 2. ESTAT DE L’ART 2.5 Preprocessat de les dades Hi ha propostes de t`ecniques per tal de millorar la qualitat de les dades d’entrada, per exemple aplicant filtres per reduir el soroll d’aquestes. Una d’aquestes ´es l’aplicaci´o d’un filtre bilateral, que intenta reduir el soroll de les zones planes per`o conservar les fronteres o arestes (a difer`encia d’un filtre gaussi`a o passa baixos), i es pot aplicar tant a imatges de color com mapes de profunditat [31]. Tamb´e es proposen altres t`ecniques com mantenir control dels p´ıxels negres deguts a reflexions o altres efectes aix´ı com la confian¸ca en el seu valor, per poder-los tractar convenientment; o tamb´e intentar fer encabir els punts dins de superf´ıcies planes [8]. 2.6 Acceleraci´o dels c`alculs Es podria donar el cas de que la complexitat dels algorismes utilitzats faci inviable la seva execuci´o en temps real a la CPU. Si aix`o succeeix, es podria rec´orrer a utilitzar de manera addicional la capacitat de computaci´o de la GPU de la targeta gr`afica [4], mitjan¸cant llibreries i llenguatges com CUDA [24] o OpenCL [16]. 2.7 Precisi´o i limitacions del dispositiu Durant tot el proc´es ´es important tenir en compte la precisi´o del dispositiu i les seves caracter´ıstiques, temes sobre els quals existeixen nombrosos estudis. Alguns dels aspectes que caldr`a tenir en compte en les imatges s´on la distorsi´o de les lents, que ´es menor al centre que a les cantonades; i que l’error del mapa de profunditat augmenta quadr`aticament amb la dist`ancia, aix´ı com hi decreix tamb´e la seva resoluci´o [15]. Tamb´e cal considerar l’error que pot sorgir pel que fa a la detecci´o dels esquelets, fent que aquests vari¨ın de mida en el temps, o que les articulacions no corresponguin a la seva posici´o real. Per exemple, l’error d’aquestes posicions pot arribar a ser de 10 cm, que a aquesta escala representa un error considerable [26]. 20 2.8. TRACTAMENT D’IMATGES CAP´ ITOL 2. ESTAT DE L’ART 2.8 Tractament d’imatges Per a la implementaci´o de les t`ecniques mencionades caldr`a aplicar diversos algorismes sobre imatges, aix´ı com poder-les mantenir desades a mem`oria i possiblement tamb´e a disc, i tamb´e poder emmagatzemar-les en forma de v´ıdeo per poder reproduir una mateixa entrada varis cops. La llibreria oberta OpenCV [11] proporciona eines per treballar amb imatges i implementacions d’un gran nombre d’algorismes gen`erics per tractar-les, i per tant no resulta necessari invertir esfor¸cos reimplementant-ho. Tot i aix`o si que caldr`a inevitablement dissenyar i codificar a baix nivell varis algoritmes sobre imatges espec´ıfics per a aquest projecte. 2.9 ´ Us de m´ultiples dispositius Es pot obtenir una millora de la precisi´o del sistema de captura tant de profunditats com d’esquelets utilitzant m´es d’un ´unic dispositiu, per`o aix`o resulta en un augment de la dificultat de processat de les dades ja que cal aplicar algorismes per combinar-les de manera adequada, tot intentant minimitzar el soroll [6, 32]. Aix`o tamb´e introdueix el problema addicional de la necessitat de calibrar el sistema, per tal que se s`apiga de la manera m´es precisa possible les dist`ancies i orientacions relatives entre els diferents dispositius. 2.10 Simulaci´o f´ısica Pel que fa a la pr`opia simulaci´o d’interaccions entre objectes, existeix un gran nombre de llibreries que proporcionen un nivell d’opcions m´es que suficient per a les necessitats del projecte, i per tant no resulta necessari realitzar una implementaci´o des de zero. Algunes d’aquestes s´on PhysX de Nvidia [25], o la llibreria oberta Bullet [3]. 2.11 Visualitzaci´o Per tal de dibuixar l’escena tridimensional es poden utilitzar llibreries gr`afiques com DirectX [23] o OpenGL [17]. Existeixen llibreries de m´es alt nivell per tal de tractar escenes complexes, per`o en aquest cas no s’espera un gran nombre d’objectes, i a m´es resulta convenient treballar sobre les imatges a baix nivell. 21 2.11. VISUALITZACI ´ O CAP´ ITOL 2. ESTAT DE L’ART Tamb´e ´es necessari disposar d’un sistema d’interf´ıcie d’usuari. Per una banda hi ha llibreries com SDL [28] que proporcionen sistemes de gesti´o de finestres i d’entrada/sortida directe, ideals per a aplicacions senzilles. En el cas de que es necessitin afegir controls de l’estil botons o caixes d’entrada de text, com es preveu que ser`a el cas, s’hauran d’utilitzar paquets pensats per interf´ıcies avan¸cades que permetin muntar jerarquies de controls est`andards. Tamb´e caldr`a tenir en compte que permetin el dibuixat amb baix nivell amb la llibreria gr`afica utilitzada, i possiblement en v`aries superf´ıcies diferents a la vegada. Un exemple de llibreria que proporciona aquestes funcionalitats ´es Qt [9]. 22 Cap´ıtol 3 Metodologia i rigor 3.1 M`etode de treball Com que el projecte s’ha de realitzar dins d’un l´ımit de temps d’uns 4 mesos, la millor aproximaci´o sembla utilitzar una metodologia de desenvolupament `agil com podrien ser Scrum, Extreme Programming, o Rational Unified Process. Tot i aix`o cal tenir en compte que nom´es hi haur`a un sol desenvolupador i per tant no ´es necessari un sistema tant complex ideat per afavorir el treball en equip i la comunicaci´o, per`o si que se’n poden aprofitar algunes idees principals. Es realitzaran cicles de desenvolupament curts o ”sprints”, per´ıodes de treball de com a m`axim 1 o 2 setmanes de duraci´o que acabaran amb una reuni´o amb el director del projecte on es comuniqui la feina realitzada i es demostri el funcionament dels objectius implementats, i si cal, es corregeixi la planificaci´o o els objectius parcials si sorgissin obstacles. En cas d’aconseguir completar els objectius parcials significativament abans de que acabi el per´ıode establert, s’intentar`a avan¸car la planificaci´o per tal de poder anticipar-se a la possible aparici´o d’obstacles. 3.2 Eines de seguiment Per tal de mantenir el codi a l’abast del director, aix´ı com per fer un seguiment dels canvis, s’utilitzar`a un sistema de control de versions com ´es Git, a trav´es del portal Github. Aquest servei tamb´e permet afegir fites (“milestones”), cosa que permet integrar-hi la planificaci´o i mantenir el control dels objectius parcials assolits i per tant del progr´es del desenvolupament. 23 3.3. M` ETODE DE VALIDACI ´ O CAP´ ITOL 3. METODOLOGIA I RIGOR Tamb´e es mantindr`a el contacte via correu electr`onics i/o programes de missatgeria instant`ania per si cal comunicar-se de manera r`apida, o b´e si per qualsevol motiu no ´es possible realitzar alguna reuni´o de control presencialment. 3.3 M`etode de validaci´o Es realitzaran reunions peri`odiques amb el director del projecte al final de cada iteraci´o d’una o dues setmanes per tal de mostrar el progr´es en forma de prototips parcials, i d’aquesta manera permetre validar els objectius intermedis dels projecte aix´ı com tamb´e per posar de manifest els possibles obstacles que sorgeixin, i donat el cas buscar solucions o alternatives. Tant durant el desenvolupament, com especialment cap al final del projecte, es realitzaran proves del software i de les aplicacions interactives desenvolupades en diversos entorns per tal de validar el seu funcionament, tot i que com ja s’ha mencionat resulta impossible fer-ne un test exhaustiu. A m´es, tampoc es poden establir m`etriques per a determinar amb rigor el seu bon funcionament, com sol passar en les aplicacions d’aquesta tipologia. Es considerar`a que el projecte ha estat exit´os si com a m´ınim ´es capa¸c de simular diversos objectes virtuals senzills en una escena captada de complexitat baixa, i de manera m´ınimament estable i versemblant, complint aix´ı l’objectiu principal. 3.4 Canvis en la metodologia La metodologia de desenvolupament ha seguit tal i com es va establir: reunions presencials gaireb´e cada setmana, mostrant el progr´es i comentant si es troben obstacles o si cal modificar la planificaci´o. Com a resultat d’aquestes s’han realitzat canvis en la planificaci´o i objectius. Aquesta metodologia ha perm`es una retroalimentaci´o `agil, i per no s’ha trobat cap inconvenient que porti a canviar-la. Les eines utilitzades han seguit sent les mateixes establertes inicialment: el sistema de control de versions Git i el portal GitHub per a la compartici´o i manteniment del codi font, i correu electr`onics per a la comunicaci´o. 24 4.2. INTERF´ ICIE GR ` AFICA CAP´ ITOL 4. IMPLEMENTACI ´ O 4.2.1.3 Modes El concepte de mode correspon a un mode d’interacci´o amb les subfinestres de la interf´ıcie. Aquest est`a representat per la classe abstracta Mode, que defineix m`etodes per a processar events d’entrada, tals com el click d’un bot´o del ratol´ı. Amb aquesta separaci´o es permeten implementar eines per treballar sobre les diferents vistes dels stream, permetent per exemple la selecci´o de p´ıxels individuals o b´e regions de la imatge concretes per a ser processades. L’´unic mode implementat actualment correspon al de mesura (classe MeasureMode). Aquest simplement permet llegir la profunditat determinada pel Kinect d’un punt qualssevol, en pr´emer sobre un p´ıxel de la finestra de profunditat. La dist`ancia ´es escrita a la barra d’estat de la interf´ıcie. 4.2.2 Funcionalitats A continuaci´o es descriuen les diverses funcionalitats implementades dins de la interf´ıcie general. Les corresponents a l’objectiu primari del treball es descriuen als apartat d’Implementaci´o corresponents. 4.2.2.1 Visualitzaci´o de les dades dels Streams La funcionalitat principal rau en la visualitzaci´o de les dades proporcionades per un stream, provinents del Kinect, un v´ıdeo, etc. S’han implementat un parell de classes WidgetColorView iWidgetDepthView que hereden de la classe RendererOpenGL, i que dibuixen les dades corresponents als seus noms dins d’inst`ancies de WidgetOpenGL. En el cas del color, simplement es dibuixa la imatge obtinguda. Per a la profunditat, es transforma del rang de valors que pot prendre a escala de grisos. Els valors menors al m´ınim i majors al m`axim s´on saturats a aquests l´ımits. A m´es, els p´ıxels amb valor desconegut (indicats amb valor 0) s´on representats de color vermell. En el cas de l’exist`encia d’´ındexs de jugador no nul al DepthFrame, els p´ıxels corresponents s´on tintats de color violat. La interf´ıcie permet de manera addicional dibuixar els esquelets (si el stream en proporciona) sobre aquests dos tipus d’imatges, transformats adequadament. Aquesta opci´o es presenta activada per defecte per`o es pot desactivar, i est`a implementada com a overlay de RendererOpenGL. 31 4.2. INTERF´ ICIE GR ` AFICA CAP´ ITOL 4. IMPLEMENTACI ´ O 4.2.2.2 Llista d’Streams La classe WidgetStreamManager implementa una interf´ıcie senzilla que mostra els streams oberts en aquest moment. A m´es, disposa de botons per tal d’iniciar el calibratge, que es descriu en detall a l’apartat corresponent. La Figura 4.2 mostra una captura d’aquesta finestra. Figura 4.2: Finestra de la interf´ıcie amb la llista d’streams. 4.2.2.3 Captura d’Streams Una altra funcionalitat important implementada ´es la capacitat de gravar les dades d’un o v`aris Kinect per a una futura reproducci´o. Aix`o permet crear entrades repetibles, i per tant per exemple provar algorismes diferents sota unes mateixes condicions. S’ha dissenyat una finestra que cont´e els controls de gravaci´o i captura d’imatges, permetent la selecci´o de les dades que ens interessen, i del format i el nom de sortida. Aquest widget correspon a la classe WidgetRecorder del codi. A la Figura 4.3 podem veure la seva aparen¸ca. A la llista de l’esquerra podem sel·leccionar quines dades volem desar per a cada Kinect. A la dreta podem escollir per a cada tipus de dada el c`odec de video usat per a la gravaci´o, i el format del nom objectiu dels fitxers creats (que soporta par`ametres). Finalment, un parell de botons permeten capturar un sol Frame, o b´e iniciar/parar el proc´es de gravaci´o. La creaci´o dels v´ıdeos de color i profunditat es realitza mitjan¸cant la classe d’OpenCV cv::VideoWriter. Aquesta soporta uns determinats c`odecs, que s´on els que 32 4.2. INTERF´ ICIE GR ` AFICA CAP´ ITOL 4. IMPLEMENTACI ´ O Figura 4.3: Finestra de la interf´ıcie de captura d’streams. es poden variar amb el camp corresponent de la interf´ıce. Cal tenir en compte, per`o, que la majoria s´on formats de compressi´o amb p`erdua, i aix´o deteriorar la qualitat, especialment en el cas de la profunditat, com es pot veure a la Figura 4.4. Figura 4.4: Comparaci´o d’una imatge de profunditat sense comprimir, i compresa amb p`erdua amb el c`odec HuffYUV (HYUV). Notar els punts vermells que corresponen a valors desconeguts. Com es pot observar, la compressi´o amb p`erdua fa irrecuperables les dades, i genera un soroll molt extrem. Pel que fa als esquelets, aquests es guarden en un format bin`ari propi. La classe SkeletonIO s’encarrega de l’escriptura i lectura de fitxers que emmagatzemen un o m´ultiples frames d’esquelets. 4.2.2.4 Reproducci´o d’Streams Es poden obrir streams a partir de v´ıdeos gravats. En escollir la opci´o corresponent del men´u (“Open recorded stream...”), s’obre un di`aleg que permet escollir v`aris 33 4.2. INTERF´ ICIE GR ` AFICA CAP´ ITOL 4. IMPLEMENTACI ´ O arxius. Per a cada stream que es vulgui obrir, s’ha de realitzar aquest procediment, i sel·leccionar simult`aniament els arxius que contenen les dades de color, profunditat i esquelet (en cas de que es vulguin carregar) per tal de que es carreguin conjuntament al mateix stream. La barra d’eines de la interf´ıcie proporciona controls per a reproduir, pausar, avan¸car un sol frame i rebobinar aquest tipus d’streams, amb el que es permet veure l’efecte d’algorismes pas a pas, entre d’altres coses. La lectura dels v´ıdeos tamb´e es realitza mitjan¸cant OpenCV, en aquest cas la classe cv::VideoCapture. Pels esquelets, es torna a utilitzar la classe SkeletonIO que implementa un format propi. L’stream que implementa aquesta funcionalitat correspon a la classe RecordedStream. Addicionalment, la classe FixedFrameStream permet treballar amb captures formades per un sol frame per cada tipus de dades. 4.2.2.5 Calibratge de dispositius Kinect Durant l’inici del projecte s’ha volgut avaluar si el fet d’utilitzar dos dispositius en comptes d’un permet millorar la precisi´o i reconstruir millor els objectes, utilitzant OpenCV per a calibrar els dispositius i determinar la seva posici´o i orientaci´o relativa. Per a aconseguir realitzar aix`o, s’ha implementat una operaci´o (una subclasse d’Operation) que s’encarrega d’obtenir les imatges al llarg del temps i processares. Aquesta operaci´o apareix dins del codi com la classe Calibrator. Presenta dos modes de funcionament: calibratge de la c`amera de color d’un sol dispositiu (c`alcul dels par`ametres intr´ınsecs), i calibratge d’un conjunt de c`ameres de color de dispositius (c`alcul dels par`ametres extr´ınsecs entre ells). El procediment pels dos casos ´es molt similar: un cop hem introdu¨ıt de par`ametre la mida del tauler d’escacs utilitzat com a patr´o, comen¸ca a capturar imatges de color de tots els streams implicats, intentant agafar-los tots el m´es r`apid possible per reduir els canvis de l’escena, i crida a la funci´o findChessboardCorners d’OpenCV. En cas d’`exit en la detecci´o, crida tamb´e la funci´o d’OpenCV cornerSubPix per a millorar la precisi´o del posicionament dels punts trobats. Aix`o es realitza m´ultiples vegades, guardant en cada cas els punts obtinguts, fins que s’han obtingut un nombre rellevant d’`exits. En aquest punt, els modes divergeixen. Pel cas d’un sol stream, es crida a la funci´o calibrateCamera d’OpenCV, que optimitza les correspond`encies dels punts i 34 4.2. INTERF´ ICIE GR ` AFICA CAP´ ITOL 4. IMPLEMENTACI ´ O c`alcula els par`ametres intr´ınsics corresponents a la c`amera usada en la gravaci´o original de les dades del stream. En el cas del calibratge d’un sistema, la funci´o cridada ´es stereoCalibrate. Aquesta es crida amb parelles de c`ameres, formades per la primera (que correspondr`a a la de refer`encia) i cadascuna de les altres. Per tant, es cridar`a n−1 cops. En cada cas retorna v`aris resultats, dels quals estem interessats especialment en la matriu de rotaci´o Ri el vector de translaci´o T. Aquests dos elements permeten definir la transformaci´o que cal aplicar per passar entre els sistemes de refer`encia de les dues c`ameres, que tamb´e es pot interpretar com la posici´o i orientaci´o relatives de la segona c`amera respecte a la primera. No obstant, un cop implementat, el calibratge ha resultant en valors amb for¸ca variabilitat. Aix`o, juntament amb el fet que utilitzar dispositius provoca interfer`encies que empitjoren la precisi´o de l’esquelet, han fet que finalment no s’utilitzin m´ultiples Kinects per a l’objectiu primari del treball, la realitat augmentada. 4.2.2.6 Vista de l’escena La vista implementada en la classe WidgetSceneView permet visualitzar els elements de la escena en 3D, aix´ı com navegar per aquesta utilitzant el teclat i el ratol´ı per despla¸car-s’hi. Els elements que s’hi mostren actualment s´on els seg¨uents: •La c`amera modelada pel l’stream 0, a l’origen, mitjan¸cant un con. Al pla Y = 0 s’hi representa una graella, on cada l´ınia est`a separada per intervals d’1 metre. A m´es, es dibuixen els eixos de coordenades seguint l’esquema de colors est`andard (X = R, Y = G; Z = B). •En cas d’haver realitzat un calibratge entre varis dispositius, es mostren les c`ameres de les quals es coneix la posici´o relativa amb la que serveix d’origen, tamb´e en forma de cons. •Els esquelets proporcionats per l’stream origen, si en disposa. En aquest cas s’utilitza la classe RenderUtils que implementa funcions est`atiques per a dibuixar els ossos dels esquelets. •Si s’ha compilat la interf´ıcie amb el m`odul de realitat augmentada activat, tamb´e s’hi mostren els objectes virtuals per tal de poder observar amb m´es deteniment les seves posicions. Aix`o inclou el model f´ısic amb el qual es modelen els usuaris. Tot aix`o es descriu en m´es detall a l’apartat d’Implementaci´o corresponent. 35 4.2. INTERF´ ICIE GR ` AFICA CAP´ ITOL 4. IMPLEMENTACI ´ O El dibuixat es realitza amb OpenGL, utilitzant les funcions que ofereix la seva llibreria d’utilitats GLU per a dibuixar els cons i altres formes b`asiques. La Figura 4.5 mostra l’aspecte d’aquesta finestra. Figura 4.5: Finestra de la interf´ıcie per la vista de l’escena. 36 4.3. SIMULACI ´ O F´ ISICA CAP´ ITOL 4. IMPLEMENTACI ´ O 4.3 Simulaci´o f´ısica En aquest apartat es descriu com s’ha integrat la llibreria Bullet Physics i com s’hi ha treballat a sobre per tal s’assolir la simulaci´o dels objectes f´ısics virtuals de manera conjunta amb l’usuari i altres objectes de la escena real. 4.3.1 Creaci´o del m´on f´ısic Per tal d’encapsular el m´on f´ısic i tots els elements relacionats (objeces que determinen els algorismes utilitzats en la simulaci´o) s’ha creat una classe, World. Aquesta s’encarrega d’inicialitzar el m´on de Bullet (que correspon a la classe btDiscreteDynamicsWorld) aix´ı com el detector i el solucionador de col·lisions. D’entrada nom´es s’han considerat objectes formats per a cossos r´ıgids, per`o la Bullet t´e un m`odul per a simular deformables com per exemple roba, que es podria integrar. La classe World crea un thread que s’encarrega d’executar la simulaci´o f´ısica sota d’un framerate determinat. A m´es, rep peri`odicament les dades procedents del Kinect i actualitza el m´on segons correspon. Aix`o s’explica en detall als seg¨uents apartats. 4.3.2 Introducci´o d’objectes senzills Per comen¸car, s’ha establert una classe abstracta base a mode d’interf´ıcie, Object, de la que derivaran tots els objectes f´ısics, i que exposa m`etodes per afegir-los i treure’ls del m´on de Bullet aix´ı com per dibuixar-los en la vista 3D i en la vista de realitat augmentada. Els objectes senzills inclosos han estat cubs i esferes, amb unes classes anomenades Cube iBall respectivament. Aquestes deriven d’una classe intermedia BasicObject que cont´e els elements que cal definir per tots els objectes formats per un ´unic cos r´ıgid simple. Aquests s´on: 1. Forma de col·lisi´o (btCollisionShape): defineix la forma que s’utilitza a l’hora de detectar col·lisions entre objectes. 2. Cos r´ıgid (btRigidBody): cont´e les propietats f´ısiques (massa, in`ercia, etc.). 3. Estat de moviment (btMotionState): emmagatzema la posici´o i orientaci´o del objecte, aix´ı com la seva velocitat. 37 4.3. SIMULACI ´ O F´ ISICA CAP´ ITOL 4. IMPLEMENTACI ´ O A partir d’aqu´ı, incloure nous tipus d’objectes b`asics resulta f`acil. Tamb´e ´es possible incloure objectes composts, descomposant-los recursivament en objectes m´es senzills; o fins i tot models, en aquest cas la complexitat rau en carregar els fitxers necess`aris, fet pel qual seria recomenable usar una llibreria especialitzada. 4.3.3 Determinaci´o del pla de terra Un fet important recau en determinar a quina al¸cada del terra est`a el Kinect. Amb les dades dels esquelets dels usuaris, el Kinect inclou una estimaci´o del pla del terra, en forma dels par`ametres a,b,cidde la equaci´o t´ıpica d’un pla: ax +by +cz +d= 0 No obstant, per la simulaci´o f´ısica ens interessa que el pla estigui recte, ´es a dir, que la seva normal (a, b, c) sigui (0, 1, 0). Altrament alguns objectes podrien tendir a moure’s cap a una certa direcci´o. Sota aquesta assumpci´o, podem obtenir la dist`ancia del Kinect al terra de forma f`acil: y=−d Addicionalment, per tal d’evitar possible soroll degut a una variaci´o petita d’aquest valor, que podria fer que els objectes al terra es moguin, es comprova si la difer`encia entre el nou valor i l’actual ´es superior a un cert llindar. Si no ´es aix´ı, no s’actualitza. Un fet a tenir en compte del terra es que no s’ha de moure en les col·lisions. Aix`o la llibreria Bullet ho permet especificar definint l’objecte com a kinematic, com en aquest cas ens conv´e. Per tal de poder actualitzar la posici´o del terra manualment, s’ha implementat un estat de moviment propi (classe KinematicMotionState) que exposa la funci´o setWorldTransform per canviar la transformaci´o (posici´o i rotaci´o) de l’objecte. 4.3.4 Esquelets dels usuaris Finalment, resta modelar els usuaris dins del m´on virtual. Bullet no presenta de manera nativa suport per a esquelets, aix´ı que s’ha procedit a modelar el cos hum`a a partir d’objectes simples. A m´es, com en el cas del terra, aquests objectes s’han definit com a kinematic ja que no han de canviar la posici´o com a resposta a les 38 4.3. SIMULACI ´ O F´ ISICA CAP´ ITOL 4. IMPLEMENTACI ´ O col·lisions. S’ha creat una classe Skeleton (subclasse de Object) que s’encarrega de representar i mantenir actualitzat l’esquelet. Aquest model del cos hum`a s’ha generat creant objectes r´ıgids amb forma de c`apsula (btCapsuleShape) per a cada parell d’articulacions connectades (ossos) que el Kinect segueix dins del seu model d’esquelet. Addicionalment s’ha afegit una esfera (btSphereShape) per modelar el cap. A cada nou frame d’esquelets s’actualitzen les posicions i mides dels ossos (sempre i quan l’estat de l’os sigui Tracked). La principal complicaci´o la trobem en que la informaci´o que rebem s´on les posicions de les articulacions, i hem de determinar per a aquelles parelles que constitueixen un os, la transformaci´o corresponent per a la c`apsula, que inclou tant la posici´o com la rotaci´o. Les c`apsules a btSphereShape estan definides sobre l’eix Y, amb un extrem situat a l’origen. Per tant, partint de les posicions u1iu2de les dues articulacions hem de definir la matriu de transformaci´o. Per a definir aquesta, ´es necess`ari determinar per una banda el vector de translaci´o (3 components), i per l’altra la matriu de rotaci´o (3 x 3 elements). El vector de translaci´o resulta trivial: es pot prendre directament la posici´o d’una de les dues articulacions, per exemple u1. Per obtenir la rotaci´o partint d’aquests dos punts, ens basarem en el vector que va d’un a l’altre, utilitzant com a origen el mateix que hem usat per la translaci´o: v=u2−u1 Una manera de construir una matriu de rotaci´o coneixent els sistemes de refer`encia inicial i final, correspon a expressar els vectors del final en les coordenades de l’inicial, i col·locar-los de manera adjacent per columnes formant una matriu. En el nostre cas, volem que el vector (0,1,0) (vector que correspon a l’eix principal de la c`apsula) es roti fins estar alineat amb el vector v(que correspon a la direcci´o de l’os). Per la resta d’eixos no ens importa la direcci´o, ja que en rotar una c`apsula sobre el seu eix principal el canvi ´es m´ınim. Tot i aix´ı, cal muntar un sistema de refer`encia ortogonal. Per tant, partint del vector vi d’un altre vector qualssevol (per exemple, el vector up := (0,1,0), podem calcular: right =v×up 39 4.3. SIMULACI ´ O F´ ISICA CAP´ ITOL 4. IMPLEMENTACI ´ O Per definici´o del producte vectorial, right ser`a perpendicular a v. Ara, podem recalcular el vector up com: up =right ×v Obtenint d’aquesta manera un vector perpendicular a right iv(el vector up original en general no ´es perpendicular a v). Aix´ı doncs, si normalitzem aquests 3 vectors, podem construir la matriu de rotaci´o com: rotation =  rightxvxupx rightyvyupy rightzvzupz   Una cosa a notar ´es que el fet d’utilitzar un vector up constant per definir el sistema de refer`encia pot comportar un problema en el cas que v=up, ja que implicaria l’exist`encia d’infinites direccions perpendiculars als dos vectors. Per tant, si els components X i Z de vs´on 0, s’usa el vector up = (0,0,1). Finalment, tamb´e cal definir l’escalat de la c`apsula per tal de que realment arribi fins al punt u2 (no es quedi curt ni es passi). Bullet sempre t´e definit un escalat unit`ari a la matriu de transformaci´o, per`o permet modificar les mides del objecte alterant l’escala del seu shape amb la funci´o setLocalScaling. Aquesta actua sobre el sistema de refer`encia original, on l’eix major de la c`apsula correspon al eix Y, i per tant s’aplica un escalat que correspon a la norma del vector v(|v|) en aquest eix, i un d’unit`ari en els altres dos eixos. Encara que el resultat ´es un model molt simplificat i que no coincideix amb les mides reals del cos, s’ha pogut comprovar que resulta suficient per a la interacci´o. El cap, que s’ha modelat amb una esfera, tamb´e s’ha d’actualitzar, per`o en aquest cas nom´es ´es necessari assignar la seva translaci´o, ja que en ser una esfera la rotaci´o no tindria impacte; i en nom´es dependre d’un sol punt l’escalat no cal que varii. Figura 4.6: Exemple del modelat f´ısic d’un esquelet. 40 4.4. VISUALITZACI ´ O DE LA REALITAT AUGMENTADA CAP´ ITOL 4. IMPLEMENTACI ´ O desconegut, degut per exemple a superf´ıcies reflectants. A m´es, els valors poden oscil·lar durant el temps, cosa que pot generar un efecte de flickering on part d’un objecte s’oclou i deixa d’estar ocl´os continuament. Per tant, s’han provat diverses alternatives per restaurar els p´ıxels desconeguts: 1. Soluci´o simple: seq¨uencialment, omplir cada p´ıxel amb els valors de la fila i/o columna anterior, dels quals per la sequencialitat tenim garantit que ja tindran valor. Aquesta soluci´o naive genera artefactes en forma de diagonal en `arees grans. No obstant, funciona relativament b´e, i t´e l’avantatge que ´es molt r`apida i simple d’implementar. La figura 4.10 mostra el seu efecte. Figura 4.10: Exemples de la correcci´o del mapa de profunditat amb els dos primers algorismes considerats. La imatge de dalt correspon al mapa original. La imatge inferior dreta, a l’algorisme simple, on podem observar els artefactes generats en forma de diagonals. A l’esquerra, l’execuci´o del segon algorisme (amb nom´es 2 nivells). Amb aquests pocs nivells ´unicament corregeix grups de pocs p´ıxels, per`o aquests obtenen uns valors m´es precisos i sense artefactes. 2. Mirar els p´ıxels del voltant: per cada p´ıxel de valor desconegut, mirar a la imatge d’entrada els p´ıxels del voltant, i els p´ıxels del voltant d’aquests, formant dues “anelles”. D’aquestes, prendre la mediana dels valors i posar-lo 47 4.4. VISUALITZACI ´ O DE LA REALITAT AUGMENTADA CAP´ ITOL 4. IMPLEMENTACI ´ O al p´ıxel, si les anelles tenen un m´ınim de p´ıxels coneguts. Aquesta alternativa presenta el problema de que nom´es funciona en p´ıxels puntuals o grups de 2 p´ıxels, i tot i que el resultat en aquests ´es millor, tamb´e ´es m´es costosa. Es podria solucionar augmentant el nombre d’anelles considerades, per`o aix`o a la vegada augmenta el cost quadr`aticament. La figura 4.10 tamb´e mostra el seu funcionament, en aquest cas amb poques anelles. 3. Utilitzant “mem`oria”: en comptes de corregir cada mapa de profunditat de manera independent, fer servir un algorisme que guardi un estat per tal de corregir-los. Aquesta alternativa presenta diverses variacions segons les pol´ıtiques per canviar els valors guardats, i com prendre els valors de sortida. La figura 4.11 mostra un exemple de resultats. Figura 4.11: Exemple de la correcci´o del mapa de profunditat amb “mem`oria”. A la dreta l’imatge original i a l’esquerra la corregida, en un moment puntual despr´es d’haver deixat uns segons d’execuci´o. Es pot observar un problema: molts p´ıxels desconeguts acaben convertits en blancs. Aix`o ocorre en passar objectes per davant de p´ıxels que s´on permanentment desconeguts. Finalment s’ha optat per la primera soluci´o, perqu`e ´es la m´es r`apida (l’algoritme s’ha d’executar en temps real). Com que el mapa de profunditat no s’acaba visualitzant de manera directa, sin´o que ´unicament s’usa per l’oclusi´o, no es nota els artefactes generats de les diagonals. El 3r tamb´e ´es r`apid, per`o ´es menys responsiu a canvis (triga m´es a reflectir-los) i genera fadings de la oclusi´o, que resulten un efecte no desitjat en aquest cas. La figura 4.12 mostra un exemple del resultat obtingut amb l’aplicaci´o d’aquest algorisme en la occlusi´o. Com es pot veure, tot i que els resultats no s´on perfectes, si que es nota significativament la millora. En aquest cas s’ha incl´os una finestra, cas en el qual el Kinect sol presentar problemes en obtenir la profunditat. En cas de valor desconegut, s’ha optat per no realitzar oclusi´o. 48 4.4. VISUALITZACI ´ O DE LA REALITAT AUGMENTADA CAP´ ITOL 4. IMPLEMENTACI ´ O Figura 4.12: Exemple de la oclusi´o amb el mapa de profunditat corregit. A dalt a la esquerra, la imatge original, i a la dreta el mapa de profunditat corresponent. A baix a l’esquerra, el resultat de la oclusi´o amb el mapa de profunditat sense tractar, i a la dreta despr´es d’aplicar-hi l’algorisme “simple”. Tot i aix´o el primer algoritme presenta un problema derivat de les caracter´ıstiques del Kinect. Al mapa de profunditat, a vegades apareix un contorn al voltant dels usuaris i objectes propers amb p´ıxels desconeguts. Degut al funcionament del algoritme, propaga la profunditat d’aquest i fa que en ocloure objectes hi hagi un marge. Aquest problema ha quedat obert. Una soluci´o plantejada passa per comprovar tamb´e l’´ındex de jugador que proporciona el Kinect per a cada p´ıxel del mapa de profunditat, i en aquells on no sigui zero no propagar els valors. Realitzant una segona passada, comen¸cant des de la cantodana contraria, permetria arreglar el problema de manera f`acil. No obstant, no s’han pogut obtenir els ´ındexs dels jugadors i no s’ha pogut comprovar el seu funcionament. 49 4.5. APLICACI ´ O D’EXEMPLE CAP´ ITOL 4. IMPLEMENTACI ´ O 4.5 Aplicaci´o d’exemple Finalment com a aplicaci´o d’exemple s’ha integrat la simulaci´o dins de la interf´ıcie desenvolupada, en comptes de realitzar una aplicaci´o separada. D’aquesta manera s’ha pogut comprovar el funcionament de les diverses parts del sistema (el dibuixat, les oclusions, etc.) m´es profundament, possibilitant la repetici´o de les entrades mitjan¸cant gravacions. Per a aquesta integraci´o s’han afegit botons a la barra d’eines de la interf´ıcie per tal de crear objectes simples (esferes i cubs) de diverses dimensions, que apareixen al centre de la escena i a una altura significativa. D’aquesta manera es poden deixar caure els objectes uns sobre els altres per formar piles, o colpejar-los directament. Un possible ´us directe d’aquest sistema correspon al joc d’esports com per exemple voleibol, en que dos usuaris es passen una pilota entre ells colpejant-la. Tamb´e per un jugador, a colpejar la pilota amb la cama flexionada per tal d’intentar fer rebotar-la sense que caigui al terra, semblant a exercicis de futbol. Tamb´e permet la construcci´o d’estructures mitjan¸cant cubs, com per exemple torres. Les figures 4.13 i 4.14 mostren alguns exemples dels resultats. La primera mostra la interacci´o entre dos caixes virtuals, que es situen sobre el terra; i la segona un exemple d’una esfera que es oclusa de manera parcial per la taula. En aquestes tamb´e es pot veure la integraci´o amb la interf´ıcie. Figura 4.13: Exemple de realitat augmentada amb una torre de caixes. 50 4.5. APLICACI ´ O D’EXEMPLE CAP´ ITOL 4. IMPLEMENTACI ´ O Figura 4.14: Exemple de realitat augmentada amb una esfera parcialment oclusa, i una caixa. 51 Cap´ıtol 5 Planificaci´o 5.1 Consideracions La data d’inici del projecte correspon al 17/02/2014, on es va comen¸car amb la definici´o dels objectius i abast. El termini l´ımit per aquest ´es el 19/06/2014, no incloent la seva defensa que es realitzar`a puntualment el dia 27/06/2014. Per tant, descomptant festius la duraci´o del projecte ser`a del voltant de 15 setmanes. Cal tenir en compte que la planificaci´o que es presenta en aquest apartat s’ha realitzat a priori i ser`a propensa a canvis, degut a que el projecte es desenvolupar`a amb una metodologia `agil i a que poden sorgir obstacles que impliquin un major consum de temps, o s’acabin tasques m´es r`apidament del que s’espera. Tamb´e cal considerar la realitzaci´o o no dels objectius secundaris, que dependran de recursos dels quals en aquest punt no se’n pot determinar la disponibilitat. 5.2 Planificaci´o en fases A continuaci´o es detallen les diferents fases en que s’ha dividit el projecte, i per cadascuna es descriuen les tasques que la conformen, els recursos emprats i els possibles riscs. 52 5.2. PLANIFICACI ´ O EN FASES CAP´ ITOL 5. PLANIFICACI ´ O 5.2.1 Fase de disseny i planificaci´o Correspon a la fase inicial del projecte, on s’han delimitat les seves caracter´ıstiques, metodologia a seguir, etc. Cal notar l’abs`encia del disseny d’una arquitectura del software, ja que en aquest projecte el nombre de components ser`a redu¨ıt per`o a la vegada presentaran certa complexitat i s’hauran d’adaptar a les llibreries usades, cosa que dificulta dissenyar-los formalment a priori. Aquesta fase contindr`a les seg¨uents tasques: •Definici´o de l’abast: el primer pas del projecte correspon a concretar els objectius d’aquest, aix´ı com determinar fins a quin punt es vol arribar. •Planificaci´o: es dissenya una planificaci´o a priori del projecte, tenint en compte les tasques a realitzar en les diferents fases del seu desenvolupament i els recursos emprats. •Proposta de pressupost i an`alisi de viabilitat: s’estimar`a el cost del projecte, tenint en compte els recursos i el temps emprats. Tamb´e s’analitzar`a la viabilitat econ`omica d’aquest, i la seva sostenibilitat social i ambiental. •Contextualitzaci´o: es realitzar`a una cerca bibliogr`afica de documents i “papers” per tal d’elaborar un estat de l’art amb projectes i resultats relacionats amb el projecte. •Informe i presentaci´o de la fita inicial: s’elaborar`a un informe recollint els objectius del projecte aix´ı com altre informaci´o rellevant. Aquest s’haur`a d’entregar, i es realitzar`a una presentaci´o un dia per concretar resumint-lo. 5.2.2 Fase de preparaci´o I Preparaci´o del software: Abans de poder comen¸car en el desenvolupament caldr`a preparar l’entorn, obtenint i instal·lant el software necessari a l’ordinador utilitzat. Aquest es detalla a l’apartat de recursos. II Obtenci´o del Kinect i prova de l’entorn: Per poder comen¸car a treballar caldr`a disposar d’un dispositiu Kinect. Es connectar`a el dispositiu a l’ordinador, i es comprovar`a el seu bon funcionament aix´ı com la instal·laci´o correcta de les llibreries mitjan¸cant les aplicacions de prova proporcionades. III Familiaritzaci´o amb el dispositiu i llibreries: Abans de comen¸car pr`opiament amb la implementaci´o del projecte es procedir`a a realitzar una petita aplicaci´o per tal de veure les dades que pot proporcionar el dispositiu Kinect i com 53 5.2. PLANIFICACI ´ O EN FASES CAP´ ITOL 5. PLANIFICACI ´ O obtenir-les, familiaritzar-se m´ınimament amb les convencions i caracter´ıstiques de la llibreria, i amb la seva integraci´o amb la llibreria de visualitzaci´o utilitzada (OpenGL). Aquesta aplicaci´o obtindr`a la imatge de v´ıdeo del sensor aix´ı com els mapes de profunditat, i els mostrar`a en una finestra tot superposant-hi els esquelets detectats. 5.2.3 Desenvolupament en iteracions Tal com es va exposar en la metodologia, el projecte es realitzar`a en iteracions, generalment de com a m`axim dues o tres setmanes de duraci´o, segons es detallen a continuaci´o. 1. Modelitzaci´o de l’escena: s’intentaran extreure models f´ısics simplificats dels objectes est`atics que es detectin en l’escena capturada, com per exemple taules, aix´ı com tamb´e dels terres i parets, amb la precisi´o que resulti possible. 2. Simulaci´o d’objectes simples: s’introduir`a la simulaci´o f´ısica de cossos r´ıgids virtuals que col·lideixin amb els objectes de l’escena, tant est`atics com amb els esquelets humans. Els objectes virtuals disposaran de diferents caracter´ıstiques (si li afecta la gravetat, massa, etc.), per`o fins aquest punt s’implementar`a nom´es un subconjunt. 3. Millora de la simulaci´o: s’implementaran caracter´ıstiques i comportaments dels objectes addicionals, aix´ı com la possibilitat d’objectes m´es complexos que formes simples. 4. Aplicaci´o d’exemple: es desenvolupar`a una aplicaci´o simple que utilitzi all`o desenvolupat de tem`atica a decidir segons els resultats aconseguits. Una possibilitat podria ser un petit videojoc de puzle. Si es disposa de temps addicional, es realitzar`a m´es d’una. Addicionalment, tal com ja s’ha mencionat en els objectius, s’estudiar`a la possibilitat de millorar la precisi´o utilitzant varis dispositius aix´ı com podria implementarse suport per a Kinect 2. Aquestes tasques, que depenen de la disponibilitat dels recursos s’introduirien com a iteracions (curtes) segons convingu´es. En aquesta fase ´es on es poden trobar els principals riscos. El principal i m´es probable correspondria al sorgiment d’errors de programaci´o que puguin retardar la planificaci´o. Tamb´e poden sorgir problemes amb l’obtenci´o de dades que obliguin a dedicar m´es temps, especialment en la primera tasca. Un altre risc, encara que poc probable, ´es que deixi de funcionar el material utilitzat (ordinador o Kinect), i calgui esperar a disposar d’un altre. 54 5.2. PLANIFICACI ´ O EN FASES CAP´ ITOL 5. PLANIFICACI ´ O 5.2.4 Fase final En aquesta fase s’acabar`a el projecte, i s’analitzar`a el seu resultat. •Redacci´o de la mem`oria: es redactar`a el document recollint tota la informaci´o relacionada amb el projecte, detallant les caracter´ıstiques finals implementades. Tamb´e s’inclouran les desviacions en la planificaci´o inicial i s’analitzaran les seves causes i conseq¨u`encies. •Entrega i lectura del projecte: es defensar`a el projecte davant d’un tribunal, havent realitzat l’entrega de la mem`oria una setmana abans. Aquest esdeveniment tindr`a lloc m´es endavant de la data l´ımit, en un dia encara per concretar. 5.2.5 Estimaci´o d’hores El temps estimat per a la fase de disseny i planificaci´o correspon a 75 hores; la fase de preparaci´o a 20 hores, el desenvolupament a 330 hores, i la fase final a 25 hores. La duraci´o total estimada del projecte ´es de 450 hores. Al punt 5 es mostren les duracions estimades de les tasques. 5.2.6 Pla d’acci´o Com que en el projecte s’utilitzar`a una metodologia de desenvolupament `agil, es podr`a reaccionar a possibles obstacles i adaptar la planificaci´o inicial de manera din`amica, alterant la duraci´o dels cicles d’iteraci´o segons resulti necessari o afegintne si cal. En cas de que una tasca resulti d’una duraci´o menor a la prevista, s’avan¸car`a la planificaci´o i es procedir`a a la seg¨uent iteraci´o per tal de prevenir possibles retards m´es endavant. Si pel contrari una tasca acaba durant m´es d’all`o esperat, inevitablement caldr`a centrar-se en acabar-la encara que aix`o impliqui introduir un cert retard a la resta, degut a que moltes tasques dep`en d’anteriors. Al final de cada iteraci´o es realitzar`a una reuni´o amb el director del projecte per tal de controlar el progr´es, i adaptar el calendari si cal. Les hores assignades a cada tasca ja inclouen un cert marge de temps per a possibles imprevistos menors. S’espera poder acabar el projecte en el termini especificat, per`o si apareix un gran nombre d’obstacles s’intentar`a restringir el nombre de caracter´ıstiques implementades centrant-se en complir els objectius b`asics. 55 5.3. PLANIFICACI ´ O INICIAL CAP´ ITOL 5. PLANIFICACI ´ O 5.3 Planificaci´o inicial Figura 5.1: Diagrama Gantt de la planificaci´o inicial. 56 6.2. PRESSUPOST CAP´ ITOL 6. RECURSOS I COSTS 6.2.1.2 Hardware A continuaci´o es detallen els costos del hardware que ser`a necessari en el desenvolupament del projecte, aix´ı com la seva amortitzaci´o calculada a nivell mensual. No obstant, cal tenir en compte en aquest cas ja es disposa de tot aquest, o b´e s’obtindria per cessi´o temporal sense cap cost. Producte Preu unitari Unitats Vida ´util Amortitzaci´o ASUS K53SV 490 e1 4 anys 10,21 e/ mes Kinect 100 e1 * 4 anys 2,08 e/ mes Kinect 2 ** 295 e0 *** 4 anys 6,15 e/ mes Total 590 e- - 12,29 e/ mes Taula 6.2: Hardware utilitzat, amb el seu cost. * Per a un objectiu opcional serien convenients 2. ** Preu encara no publicat, aquest correspon al d’un paquet d’acc´es primerenc per a desenvolupadors, i per tant s’espera un d’igual o inferior. *** No ´es indispensable, per`o seria convenient per un objectiu secundari, si es pot obtenir. 6.2.1.3 Software Tamb´e ser`a necess`aria l’adquisici´o de diferents llic`encies de software. Tot i que en aquest cas es disposa d’aquest de forma gratu¨ıta mitjan¸cant llic`encies per a estudiants, a continuaci´o es mostren els costs que tindrien en un projecte comercial aix´ı com la seva vida ´util estimada i la amortitzaci´o a nivell de mes. Producte / Llibreria Preu Vida ´util Amortitzaci´o Windows 8.1 Pro 279 e3 anys 7,75 e/ mes Microsoft Office Home & Business 2013 269 e3 anys 7,47 e/ mes Microsoft Visual Studio Pro 2013 646 e3 anys 17,94 e/ mes Kinect for Windows SDK v1.8 / v2.0* 0 e- - Kinect Developer Toolkit v1.8 0 e- - OpenCV 2.4.9 0 e- - Qt 5.0 0 e- - Bullet Physics 2.82 0 e- - Total 1.194 e33,16 e/ mes Taula 6.3: Software necessari pel projecte. En els casos on s’apliqui, nom´es es requereix una sola llic`encia. * La versi´o 2.0 encara no ha estat publicada, per`o s’espera de cost nul, i ser`a necess`aria nom´es si es decideix afegir suport per a Kinect 2. 63 6.2. PRESSUPOST CAP´ ITOL 6. RECURSOS I COSTS 6.2.1.4 Despeses generals Tamb´e cal tenir en compte despeses dels serveis utilitzant durant el desenvolupament del projecte, o per altres conceptes indirectes. Aquestes s’estimaran pels tres mesos i mig del projecte. Concepte Preu Cost estimat Llum 50 e/ mes 175,00 e Connexi´o a internet de banda ampla 35 e/ mes 122,50 e Total - 297,50 e Taula 6.4: Despeses del projecte addicionals a considerar. 6.2.1.5 Imposts En els preus dels productes de hardware i software ja s’han tingut en compte els impostos d’IVA, aix´ı com en el cost dels recursos humans l’IRPF i els altres impostos que procedeixen. Pel que fa a imposts per desenvolupar l’activitat, s’ha considerat que no cal incloure cap. 6.2.1.6 Estimaci´o del pressupost A continuaci´o es sumen els imports estimats dels costs identificats i descrits a l’apartat anterior per tal de calcular el que correspondria al pressupost del projecte. Pel cas del software i hardware s’ha incl`os la part imputada al projecte, que correspon al cost amortitzat en els tres mesos i mig que durar`a el desenvolupament. Concepte Cost estimat Recursos humans 17.050 e Hardware 43,02 e Software 116,06 e Despeses generals 297,5 e Total 17.506,58 e Taula 6.5: C`alcul del cost total estimat mitjan¸cant la suma per conceptes. El cost dels recursos necessaris per a la execuci´o dels objectius opcional no s’ha incl`os, ja que resulten secundaris al desenvolupament del projecte, i la seva disponibilitat no est`a garantida. En qualsevol cas el preu total d’aquests materials s’estima no superior als 400 e, i el cost repercutit inferior als 50 e. 64 6.3. DESVIACIONS DEL PRESSUPOST CAP´ ITOL 6. RECURSOS I COSTS 6.2.2 Viabilitat econ`omica L’objectiu principal del projecte no ´es el disseny i implementaci´o d’un producte que pugui ser comercialitzat directament, sin´o el desenvolupament d’una llibreria per a ser utilitzada per altres aplicacions de software. Per tant, el projecte en si no comportar`a beneficis econ`omics directes, sin´o que per a que resulti viable caldr`a considerar-lo una inversi´o en un marc de recerca i desenvolupament i ser aprofitat en futurs productes. Amb aix`o, com qualsevol projecte d’aquest tipus comporta el risc de que en ´ultima inst`ancia no se li doni ´us i per tant es perdi la inversi´o. En qualsevol cas, la tecnologia implementada permetria el desenvolupament d’aplicacions de tipologies molt diferents, permetent un ampli ventall de possibilitats per explotar el resultat del projecte: videojocs, programes d’aprenentatge, aplicacions “serioses” com per exemple m`ediques, etc. El desenvolupament d’aquestes aplicacions requeriria de relativament pocs recursos addicionals respecte als utilitzats en el projecte, i per tant el projecte resultaria viable. 6.2.3 Pla de control El pressupost calculat pot presentar variacions en els preus de serveis com per exemple la llum, que caldr`a tenir en compte. Amb tot, no s’esperen grans desviacions respecte als costs presentats, exceptuant el risc poc probable per`o present en qualssevol projecte d’haver de reempla¸car els recursos materials degut a la ruptura o a un mal funcionament d’aquests. Les principals modificacions del pressupost, ja previstes, vindrien en la forma de l’execuci´o dels objectius opcionals del projecte, que implicaria disposar de m´es dispositius i per tant caldria sumar el seu cost al total. La seva realitzaci´o caldr`a avaluar-la un cop es disposi de la possibilitat d’obtenci´o del hardware i se’n conegui el seu cost, tot tenint en compte que servir`a per millorar el resultat final del projecte, per`o que en qualsevol cas aquesta modificaci´o no seria obligat`oria. 6.3 Desviacions del pressupost En ´ultima inst`ancia no s’han executat els objectius secundaris plantejats que requerien recursos addicionals. Pel que fa al software utilitzat, tot i realitzar canvis en les llibreries utilitzades aix´ı com l’´us de noves eines, totes aquestes no imposen cap cost econ`omic. Per tant, el pressupost original no ha variat. 65 Cap´ıtol 7 Sostenibilitat 7.1 Impacte social El software derivat d’aquest projecte permetria desenvolupar aplicacions d’interacci´o en realitat augmentada com per exemple jocs seriosos (serious games). Entre aquests es podrien trobar per exemple sistemes de rehabilitaci´o de pacients que amenitzin les tasques i els incentivin a realitzar els exercicis necessaris. Tamb´e permetria la creaci´o de sistemes o videojocs educatius que fomentin bons valors als nens, com podria ser ensenyant-los diversos conceptes f´ısics (gravetat, fricci´o, etc.) mentre es diverteixen. Aix´ı doncs, aquest projecte podria donar peu a la creaci´o d’altres projectes nous, tant per la part de la interf´ıcie gr`afica com en l’expansi´o de la simulaci´o interactiva, generant ocupaci´o encara que de manera modesta. A m´es s’emmarca dins del camp de la realitat augmentada, que resulta relativament nou i per tant ´es un terreny on hi ha oportunitats per innovar i investigar noves tecnologies. 7.2 Impacte ambiental En tractar-se d’un projecte inform`atic, l’impacte ambiental del seu desenvolupament resulta limitat. Aquest es concentra principalment en la empremta ecol`ogica de la fabricaci´o del hardware utilitzat, tant del port`atil com dels dispositius Kinect, i del consum energ`etic provocat pel seu ´us aix´ı com tamb´e de la seva deposici´o un cop s’exhaureixi el termini de vida ´util. 66 7.3. CONTROL DE LA SOSTENIBILITAT CAP´ ITOL 7. SOSTENIBILITAT En el consum energ`etic degut a l’´us dels recursos cal tenir en compte tant l’energia necess`aria per executar el software utilitzat pel desenvolupament a l’ordinador, com la pot`encia que es requereix per tal d’alimentar el dispositiu Kinect que correspon a 12 watts. Aquestes quantitats s´on relativament baixes i per tant l’impacte no resulta excessiu. Tamb´e cal considerar l’impacte futur, que principalment es donar`a en forma del consum energ`etic provocat per la execuci´o del software aix´ı com un altre cop el consum del hardware necessari en el seu ´us. D’aquests dos factors nom´es es pot intentar reduir l’efecte del primer, cosa que es dur`a a terme durant el desenvolupament del projecte intentant implementar, dins del que resulti possible, algorismes i solucions que redueixin l’´us del processador i per tant el seu consum. 7.3 Control de la sostenibilitat Durant el proc´es de desenvolupament del projecte, peri`odicament es realitzar`a un control sobre el hardware per tal de comprovar el seu funcionament correcte, evitant aix´ı que pugui arribar a incrementar el seu consum energ`etic o b´e resultar en contaminaci´o (sonora, visual, etc.) de l’entorn de desenvolupament. A m´es, com ja s’ha mencionat, en la implementaci´o s’intentar`a utilitzar algoritmes i estructures de dades eficients per tal de reduir l’´us del processador de les execucions del software desenvolupat, cosa que est`a relacionada de manera directa amb el seu consum, aconseguint aix´ı que el resultat del projecte sigui m´es sostenible. En general no es preveu necessari l’establiment d’un mecanisme de rendici´o de comptes ni la realitzaci´o d’un accounting, ja que els possibles efectes esmentats s´on molt limitats alhora que dif´ıcils de mesurar utilitzant m`etriques. Per exemple en el cas del consum energ`etic, no es disposa d’un llindar o un valor per poder comparar. 67 7.4. LLEIS I REGULACIONS CAP´ ITOL 7. SOSTENIBILITAT 7.4 Lleis i regulacions Les ´uniques lleis aplicables al projecte s´on les relacionades amb el compliment de les restriccions marcades per les llic`encies de software de les diverses llibreries utilitzades, tant sobre el seu ´us com la seva distribuci´o. Aquestes llic`encies s´on: •QT: GNU LGPL 2.1 1 •OpenCV: OpenCV License (derivada d’una llic`encia BSD) 2 •Bullet: zlib license 3 •OpenGL: cap llic`encia, ´us lliure 4 •Kinect for Windows SDK: Kinect SDK EULA 5 Gaireb´e totes aquestes llic`encies permeten l’´us de la llibreria en qualssevol projecte, comercial o no, i no imposen restriccions respecte a l’´us del seu codi no modificat. Cal mencionar el cas de l’SDK oficial del dispositiu Kinect de Microsoft, que s’ofereix sota uns termes d’´us determinats. Aquestes restriccions ja s’han tingut en compte en el desenvolupament, per`o tamb´e cal considerar les restriccions imposades als usuaris en a una futura distribuci´o. Per tal de distribuir software comercial que l’utilitzi cal disposar d’una llic`encia espec´ıfica. A m´es, l’usuari final no pot utilitzar dispositius Kinect for Xbox 360, sin´o nom´es Kinect for Windows. 1http://qt-project.org/doc/qt-5/lgpl.html 2http://opencv.org/license.html 3http://opensource.org/licenses/zlib-license.php 4http://www.sgi.com/products/software/opengl/license.html 5http://www.microsoft.com/en-us/kinectforwindows/develop/sdk-eula.aspx 68 Cap´ıtol 8 Conclusions 8.1 Assoliment dels objectius L’objectiu principal del projecte, que correspon a la simulaci´o f´ısica sobre una escena real, s’ha assolit amb `exit. S’ha implementat una simulaci´o interactiva integrant v`aries llibreries on l’usuari pot interactuar amb el cos amb objectes virtuals, que s´on dibuixats a sobre de l’escena real aix´ı com oclosos per aquesta. L’objectiu afegit als inicis del treball, la creaci´o de la interf´ıcie gr`afica per a visualitzar i manipular les dades del Kinect, tamb´e s’ha assolit, implementant les funcionalitats b`asiques (visualitzaci´o de les dades, gravaci´o i c`arrega de v´ıdeos, etc.) aix´ı com d’altres d’addicionals com per exemple la cal·libraci´o de dispositius. Aquesta interf´ıcie ha estat pensada per a ser estesa, i ha allotjat l’aplicaci´o d’exemple realitzada per demostrar la simulaci´o interactiva. En refer`encia als objectius secundaris opcionals, l’´us de varis Kinect a la vegada s’ha descartat perqu`e no s’ha estimat necessari i a m´es hauria requerit m´es temps. El suport per a Kinect 2 no s’ha pogut implementar degut a la manca de recursos, i la integraci´o proposada amb un altre projecte per la millora dels esquelets ha resultat inviable degut a conflictes en els terminis. Aquest projecte tamb´e ha servit per a familiaritzar-se amb les diverses llibreries usades: en la majoria de casos no es disposava d’experi`encia pr`evia, i s’ha dedicat una part significativa del temps en aprendre qu`e ofereixen i com utilitzar-les, cosa que ha resultat m´es dif´ıcil de l’esperat degut a documentacions escasses o incompletes. En particular, tamb´e ha servit per descobrir les caracter´ıstiques i possibilitats del Kinect, amb el qual l’autor no havia treballat mai. 69 8.2. TREBALL FUTUR CAP´ ITOL 8. CONCLUSIONS 8.2 Treball futur Aquest treball ha implementat la simulaci´o interactiva que s’havia proposat com a objectiu. Tot i aix`o, encara es podria ampliar de v`aries maneres. S’ha modelat de forma f´ısica els usuaris i el terra de l’escena real. Es podrien modelar altres elements, com les parets o altres objectes, mitjan¸cant la determinaci´o de plans (conjunts de punts coplanars) al mapa de profunditat. Tot i haver-ho plantejat inicialment, s’ha vist que aix`o resultaria un objectiu molt ambici´os que podria donar entitat a tot un TFG, tenint en compte el requisit de temps real. De manera relacionada, tamb´e es podrien determinar les fonts de llum per a aconseguir una il·luminaci´o m´es realista. Aix`o es podria aconseguir, si es disposa de grups de p´ıxels coplanars, mirant els seus gradients al mapa de color (suposant que hi ha una sola llum). Es podrien afegir les ombres dels objectes virtuals projectades al terra (o a altres elements), cosa que generaria un efecte m´es immersiu, i que en aquest cas s’han om`es per evitar una situaci´o de disson`ancia cognitiva. Pel que fa a les oclusions, a vegades es produeixen efectes com la oscil·laci´o de certs punts en les fronteres (deguda al soroll dels sensors) i l’aparici´o de contorns que provoca que s’oclogui menys o m´es del que correspondria. Pel primer cas es podria estudiar amb m´es detall algorismes per a tractar el mapa de profunditat, possiblement servint-se de la GPU. Pel segon, es podria modificar aquest mapa consultant la imatge de color, tot i que aix`o podria resultar en inconvenients que caldria investigar: per exemple, passar a dependre de la il·luminaci´o de la escena. La simulaci´o es podria enriquir amb la incorporaci´o de models complexos, carregats utilitzant llibreries especialitzades. En aquest cas caldria implementar el seu dibuixat, aix´ı com disposar dels models f´ısics corresponents o b´e implementar algorismes per a generar-los mitjan¸cant una simplificaci´o de pol´ıgons. A m´es, la llibreria utilitzada per a la simulaci´o f´ısica, Bullet, tamb´e suporta cossos deformables, tot i que aquests presenten una complexitat addicional en el seu ´us. Finalment, com ja s’ha plantejat, es podria recorre a l’´us simultani de varis dispositius. En aquest cas la principal complicaci´o rauria en la combinaci´o de les dades de manera coherent, ja que la cal·libraci´o ja ha estat implementada. Pel que fa a la part de la interf´ıcie gr`afica, aquesta ja s’ha desenvolupat pensant en la possibilitat d’usar-la de base per a futurs treballs, evitant haver de comen¸car des de zero. Hi queda com a treball futur afegir suport per al Kinect 2, ja que no s’ha pogut disposar d’aquest ni tampoc del seu SDK. 70 Bibliografia [1] D. Beaney i B. MacNamee. ?Forked! A demonstration of physics realism in augmented reality?A: 2009 8th IEEE International Symposium on Mixed and Augmented Reality (2009). doi:10.1109/ISMAR.2009.5336479. [2] Philip Buchanan et al. ?Augmented Reality and Rigid Body Simulation for Edutainment?A: Advanced in Computer Entertainment Technology (ACE 2008). ACM, 2008, p`ag. 17 - 20. doi:10 . 1145 / 1501750 . 1501754.url: http://portal.acm.org/citation.cfm?id=1501754. [3] Bullet Physics Library. Real-Time Physics Simulation. 2014. url:http : //bulletphysics.org/ (cons. 6-3-2014). [4] Paul Caheny. ?GPU accelerated Realtime 3D Modelling with Microsoft Kinect MSc in High Performance Computing?A: (2012). [5] Massimo Camplani, Tomas Mantecon i Luis Salgado. ?Depth-color fusion strategy for 3-d scene modeling with kinect?A: IEEE transactions on cybernetics 43.6 (2013), p`ag. 1560 - 71. issn: 2168-2275. doi:10.1109/TCYB. 2013.2271112.url:http://www.ncbi.nlm.nih.gov/pubmed/24273141. [6] WC C Chiu, U Blanke i Mario Fritz. ?Improving the Kinect by Cross-Modal Stereo?A: BMVC. 2011, p`ag. 1 - 10. isbn: 1-901725-43-X. doi:10.5244/C. 25.116.url:http://www.bmva.org/bmvc/2011/proceedings/paper116/ paper116.pdf. [7] Sam Corbett-Davies, Richard Green i Adrian Clark. ?Physically Interactive Tabletop Augmented Reality Using the Kinect?A: Proceedings of the 27th Conference on Image and Vision Computing New Zealand. IVCNZ ’12. New York, NY, USA: ACM, 2012, p`ag. 210 - 215. isbn: 978-1-4503-1473-2. doi:10.1145/2425836.2425880.url:http://doi.acm.org/10.1145/ 2425836.2425880. [8] M Davoodianidaliki i M Saadatseresht. ?Three pre-processing steps to increase the quality of Kinect Range Data?A: XL.October (2013), p`ag. 5 - 8. 71 BIBLIOGRAFIA BIBLIOGRAFIA [9] Digia Plc. Qt Project. 2013. url:http : / / qt - project . org/ (cons. 6-3-2014). [10] Erol Gelenbe, Khaled Hussain i Varol Kaptan. ?Enabling Simulation with Augmented Reality?A: Performance Tools and Applications to Networked Systems 2965 (2004), p`ag. 290 - 310. doi:10.1007/9783540246633\_14. [11] Itseez. OpenCV (Open Source Computer Vision). 2014. url:http : / / opencv.org/ (cons. 6-3-2014). [12] Shahram Izadi et al. ?KinectFusion: real-time 3D reconstruction and interaction using a moving depth camera?A: Proceedings of the 24th Annual ACM Symposium on User Interface Software and Technology. ACM. 2011, p`ag. 559 - 568. isbn: 9781450307161. doi:10.1145/2047196.2047270.url: http:/ /rogerioferis. com /VisualRecognitionAndSearch/ material/ Class9Kinect1.pdf$%5Cbackslash$nhttp://dl.acm.org/citation. cfm?id=2047270. [13] Klemens Jahrmann. ?3D Reconstruction with the Kinect-Camera?Tesi doct. Favoritenstrasse 9-11/186, A-1040 Vienna, Austria: Institute of Computer Graphics i Algorithms, Vienna University of Technology, 2013. url:http: //www.cg.tuwien.ac.at/research/publications/2013/jahrmann%5C_ klemens%5C_KFR/. [14] Hannes Kaufmann i Bernd Meyer. ?Simulating Educational Physical Experiments in Augmented Reality?A: ACM SIGGRAPH ASIA 2008 Educators Programme. SIGGRAPH Asia ’08. New York, NY, USA: ACM, 2008, 3:1 - 3:8. isbn: 978-1-60558-388-4. doi:10.1145/1507713.1507717.url:http: //doi.acm.org/10.1145/1507713.1507717. [15] Kourosh Khoshelham i Sander Oude Elberink. ?Accuracy and resolution of Kinect depth data for indoor mapping applications?A: Sensors (Basel, Switzerland) 12.2 (gen. de 2012), p`ag. 1437 - 54. issn: 1424-8220. doi:10.3390/ s120201437.url:http://www.pubmedcentral.nih.gov/articlerender. fcgi?artid=3304120%5C&tool=pmcentrez%5C&rendertype=abstract. [16] Khronos Group. OpenCL - The open standard for parallel programming of heterogeneous systems. 2014. url:https://www.khronos.org/opencl/ (cons. 6-3-2014). [17] Khronos Group. OpenGL - The Industry’s Foundation for High Performance Graphics.url:http://www.opengl.org/ (cons. 6-3-2014). 72