bandapp: monitorización del ritmo respiratorio con ...oa.upm.es/44638/1/tfm_xaime_rivas_rey.pdf ·...

BandApp: Monitorización del ritmo respiratorio con realidad aumentada

SEPTIEMBRE 2016

Xaime Rivas Rey

DIRECTOR DEL TRABAJO FIN DE MASTER:

Kapil Dandekar

Xa

ime

Riv

as

Re

y

TRABAJO FIN DE MASTER

PARA LA OBTENCIÓN DEL

TÍTULO DE MASTER EN

INGENIERÍA INDUSTRIAL

BandApp: Monitorización del ritmo respiratoriocon realidad aumentada

Trabajo Fin de Máster

AutorXaime Rivas Rey

Máster en Ingeniería IndustrialEspecialidad en Electrónica

Universidad Politécnica de Madrid

DirectorKapil Dandekar

Doctor Ingeniero Eléctrico

Madrid, Septiembre 2016

Agradecimientos

"Querer es poder."

María Rivas Rey

En primer lugar me gustaría agradecer a mi hermana pequeña todo lo que me haenseñado y lo que le queda por enseñarme. María tiene síndrome de Down, y cada vezque me enfrento a un problema, pensar en ella, en como supera sus problemas día a día,me da la fuerza que necesito para sonreír y seguir avanzando.

A mis padres por todo el esfuerzo que han invertido en mi y que todavía a día de hoysiguen manteniendo, sin ellos no hubiera llegado hasta aquí. Nunca creí que tendría queirme tan lejos de casa para apreciar verdaderamente la cantidad de cosas que unos padrespueden llegar a hacer por sus hijos.

A mis abuelos por haberme inculcado desde bien pequeño el amor por trabajar con lasmanos. Cosas tan sencillas como una bombilla con dos interruptores o un arco con hilode pescar y un bambú son los detonantes de mi pasión por la ingeniería.

A mis amigos por ayudarme a recordar que la vida no es solo estudiar, también hayque divertirse.

En especial me gustaría agradecer a Diego Vázquez González, fuente inagotable deconocimiento, toda la ayuda que me ha brindado durante estos dos últimos años.

Por último, también me gustaría dar las gracias a Ilhaan Rasheed, al Doctor KapilDandekar y en general al resto de miembros del laboratorio de Sistemas inalámbricos deDrexel (DWSL), donde he realizado este proyecto.

ÍNDICE Salud, sensores y realidad aumentada

Índice

1. Resumen 3

2. Introducción 72.1. Marco del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Estado del arte 113.1. Aplicaciones médicas y la Realidad Aumentada . . . . . . . . . . . . . . . 113.2. Sensor Bellyband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3. SimBaby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4. Objetivo del proyecto 19

5. Selección Entorno de desarrollo 215.1. Entornos de desarrollo multiplataforma . . . . . . . . . . . . . . . . . . . . 21

5.1.1. Unity 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.2. Xamarin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.3. Sencha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.4. Corona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.1.5. Entorno de desarrollo escogido . . . . . . . . . . . . . . . . . . . . . 23

5.2. Herramientas de Realidad Aumentada en Unity 3D . . . . . . . . . . . . . 235.2.1. Herramienta de Realidad Virtual escogida . . . . . . . . . . . . . . 23

6. Desarrollo de la Aplicación 256.1. Tutoriales Unity 3D - Vuforia SDK . . . . . . . . . . . . . . . . . . . . . . 25

6.1.1. Tutorial Unity - �Roll a Ball� . . . . . . . . . . . . . . . . . . . . . 256.1.2. Tutorial Vuforia - �Image Markers� . . . . . . . . . . . . . . . . . . 31

6.2. BandApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2.1. Conexión a la nube . . . . . . . . . . . . . . . . . . . . . . . . . . . 346.2.2. Desarrollo del menú . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.2.3. Visualización de datos . . . . . . . . . . . . . . . . . . . . . . . . . 376.2.4. Integración de la aplicación . . . . . . . . . . . . . . . . . . . . . . 39

7. Resultado Final 41

8. Conclusiones 45

9. Líneas futuras 47

Anexos 53

Xaime Rivas Rey 1


A. Plani�cación Temporal 55A.1. Estructura de Descomposición del Proyecto . . . . . . . . . . . . . . . . . . 57

B. Presupuesto 61Capítulo 1. Ingeniería . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Capítulo 2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Capítulo 3. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Resumen por Capítulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

C. Impacto del Proyecto 67

D. Código C # 73D.1. Script principal - detector del sensor y muestra de datos . . . . . . . . . . 73D.2. Scene Loader - permite cambiar la escena actual en la App . . . . . . . . . 76D.3. Timer en C # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76D.4. Grá�co de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77D.5. Pantalla de inicio - mostrar durante 3 segundos . . . . . . . . . . . . . . . 78D.6. Gestor de pantalla táctil - accionamiento del menú . . . . . . . . . . . . . . 79D.7. Opciones del menú . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80D.8. Animación del Menú . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

E. Glosario y Páginas Web 85

2 Escuela Técnica Superior de Ingenieros Industriales

1 RESUMEN Salud, sensores y realidad aumentada

1. Resumen

El presente trabajo de �n de máster ha sido realizado durante el transcurso del pro-grama de becas EAGLES para estudios de doble titulación en la Universidad de Drexel,Filadel�a. El tutor del mismo es el Dr. Kapil Dandekar, director del "Drexel WirelessSystem Laboratory (DWSL)". La Dra. Teresa Riesgo ha sido la encargada de gestionar elproyecto desde la Universidad Politécnica de Madrid.

Una de las causas más frecuentes de fallecimiento entre niños menores de un año sedebe al "Síndrome de muerte súbita del lactante". El principal problema de este síndromees que no se conoce de forma clara la causa que lo desencadena. Esto supone que no existeningún mecanismo para prevenir o monitorizar dicho fenómeno. Este hecho, ha motivadoque el "Drexel Wireless System Laboratory", de ahora en adelante DWSL, haya desarro-llado un sensor para la detección y prevención de tan alarmante fenómeno.

El desarrollo de dicho sensor, conocido como �Bellyband� ha sido �nanciado por elGobierno de los Estados Unidos a través de la �National Science Foundation Partnershipsfor Innovation: Building Innovation Capacity�, el número de esta beca es el 1430212.

El objetivo de este trabajo de �n de máster ha sido desarrollar una herramien-ta que permita la visualización en tiempo real de los datos del citado sensor.Para tal �n se ha desarrollado una aplicación multi-plataforma (Android, iOS, Windows,Linux) mediante el uso del entorno de desarrollo que Unity 3D ofrece. La citada apli-cación, bautizada como �BandApp� , emplea técnicas de realidad aumentada (RA), esdecir, enriquece el entorno en el que el usuario de la aplicación se encuentre, mostrando losdatos del sensor superpuestos sobre las imágenes provenientes de la cámara del dispositivodonde se esté usando la aplicación.

Xaime Rivas Rey 3


Figura 1: Uso de la aplicación durante las pruebas del sensor.

El desarrollo de esta aplicación ha facilitado enormemente la investigación ydesarrollo del sensor pues evita tener que post-procesar los datos para poder visuali-zarlos. Entre las lineas de trabajo relacionadas con el sensor Bellyband está el mejorar eldiseño de los materiales con los que está fabricado y probar distintas formas de tejer losmateriales que lo conforman.

El dispositivo, que funciona como un medidor de deformación mecánica, está fabricadotejiendo un chip RFID en un bolsillo rodeado de hilo conductor que actúa como antenapara el chip. El bolsillo forma parte de una banda elástica, la cual se coloca en el vientredel infante, de ahí el nombre del sensor �Bellyband� [1, 3, 4].

En la siguiente imagen se puede observar el sensor, el bolsillo en cuyo interior están elhilo conductor y el chip RFID:


1 RESUMEN Salud, sensores y realidad aumentada

Figura 2: Bellyband: Parte frontal del dispositivo

Gracias a la aplicación desarrollada en este proyecto, se pueden probar múltiples di-seños a la hora de tejer los materiales que conforman el sensor, reduciendo enormementeel tiempo necesario para hacer pruebas ya que los datos se pueden consultar en tiemporeal mediante el uso de cualquier smartphone. Evitando tener que postprocesar los datospara poder visualizarlos y descubriendo posibles errores mucho antes.

Palabras clave: Aplicación móvil, Realidad Aumentada, Unity 3D, Sensormédico, RFID.

Xaime Rivas Rey 5

2 INTRODUCCIÓN Salud, sensores y realidad aumentada

2. Introducción

2.1. Marco del Proyecto

El "Síndrome de muerte súbita del lactante" es una de las principales causas defallecimiento entre menores de 12 meses. Dos muertes cada 1000 nacimientos en la UniónEuropea se deben a esta enfermedad. El SMSL está considerado como la primera causade muerte entre bebés sanos después de su primer mes de vida.

Si este hecho no fuera su�ciente por si solo, este tipo de muertes suceden sin previoaviso, hecho que di�culta enormemente su prevención. A pesar de no existir una causaclara, se han identi�cado una serie de factores de riesgo que aumentan las posibilidadesde que se produzca este fenómeno. Entre los más comunes destacan:

+ Exposición del bebé al humo del tabaco.

+ Recostar al infante sobre su abdomen a la hora de dormir.

+ Nacimiento prematuro.

+ Temperatura ambiente demasiado elevada (por encima de los 20o C).

+ Excesiva ropa de cama o muy blanda, provocando la as�xia del bebé.

+ Consumo de drogas durante el periodo de gestación.

+ Carencia de leche materna durante los períodos de lactancia.

+ Sobrepeso de la madre durante el periodo de gestación.

Actualmente las medidas para reducir el riesgo de sufrir el SMSL pasan por evitarlos principales factores de riesgo. También se recomienda el uso del chupete. Se cree quela super�cie saliente del mismo puede prevenir la as�xia del bebé mientras duerme puesmantiene la ropa de cama ligeramente levantada [2].

En el año 2014, debido a la carencia de elementos para prevenir de manera efectivaeste tipo de fallecimientos, el DWSL en Filadel�a decidió desarrollar un sensor para po-der monitorizar el ritmo respiratorio de recién nacidos [4]. De esta forma, en caso de quese detecte algún tipo de anomalía en la respiración del bebé es posible adoptar medidaspreventivas.

El citado sensor, conocido como �Bellyband� ofrece un método de monitorización con-tinua no invasiva. Dicho sensor está formado por una serie de materiales textiles en com-binación con tecnologías de comunicación inalámbrica pasivas, �Radio frequency Indenti-�cation� (RFID).

Xaime Rivas Rey 7


El dispositivo Bellyband funciona como un medidor de deformación mecánica, y sefabrica tejiendo un chip RFID en un bolsillo rodeado de hilo conductor, que actúa comoantena para el chip. El bolsillo forma parte de una banda elástica, la cual se coloca enel vientre del infante, de ahí el nombre del sensor �Bellyband� [1, 3, 4]. En las siguientesimágenes se puede observar el sensor y el bebé robótico empleado para realizar las pruebas:

Figura 3: SimBaby: Robot para simular la respiración de un bebé.


2 INTRODUCCIÓN Salud, sensores y realidad aumentada

Figura 4: Parte frontal del sensor Bellyband.

Figura 5: Parte trasera del sensor Bellyband.

En la siguiente imagen puede verse a un usuario empleando la aplicación para com-probar que los datos del sensor que se está registrando son correctos.

Xaime Rivas Rey 9


Figura 6: Muestra de datos en tiempo real - SimBaby.

2.2. Motivación

El desarrollo de este proyecto surge a raíz del "Síndrome de muerte súbita del

lactante" . En el año 2014 el �Drexel Wireless System Laboratory� decide desarrollar unsensor para monitorizar de una forma no invasiva el ritmo respiratorio de infantes conuna edad inferior a los 12 meses.

Uno de las principales causas que ralentizan el desarrollo del citado sensor es la caren-cia de una herramienta que permita visualizar los datos del sensor en tiempo real. En elpasado, la estrategia seguida consistía en realizar una serie de pruebas donde se recogíanlas lecturas del sensor y posteriormente se procedía a su análisis.

El principal problema de esta técnica es que posibles lecturas erróneas o datos de bajacalidad no eran detectados hasta que estos se procesaban, cosa que dependiendo de lacantidad de pruebas realizadas podría suceder al cabo de varios días.

El desarrollo de la aplicación BandApp ha hecho posible visualizar los datos delsensor de una manera muy intuitiva y en tiempo real. Agilizado enormemente las pruebasde distintos modelos del sensor y por tanto reduciendo el tiempo invertido en la recogidade datos.


3 ESTADO DEL ARTE Salud, sensores y realidad aumentada

3. Estado del arte

3.1. Aplicaciones médicas y la Realidad Aumentada

Este es un proyecto completamente novedoso, hasta la fecha no existe ninguna apli-cación comercial de realidad aumentada que permita la visualización de datos médicosprocedentes de un sensor en tiempo real.

En la actualidad, las principales herramientas que emplean realidad aumentada y/orealidad virtual en el ámbito de la medicina se recogen en la siguiente lista:

+ Cirugía no invasiva. Actualmente, con el desarrollo de la realidad aumentada,es cada vez más común superponer las imágenes del paciente al que se procede aintervenir con los resultados de algún escáner como puede ser un TAC (tomografíaaxial computarizada) o unos ultrasonidos. Esto facilita enormemente la interven-ción, haciendola mucho menos invasiva. Algunos ejemplos de cirugías que se venbene�ciadas por esta nueva tecnología son:

o Cirugías de tipo cardiovascular y torácica.

o Cirugías en el ámbito de la otorrinolaringología. Intervenciones en el cerebro ocuello implican un riesgo elevado, el hecho de que el cirujano tenga más informacióna su alcance aumenta enormemente las probabilidades de éxito en la intervención.La �gura 7 muestra como ambas imágenes se superponen.

+ Educación. Alumnos de medicina, enfermería y en general cualquier carrera querequiera un cierto conocimiento del cuerpo humano se puede bene�ciar enormemen-te de la realidad aumentada, pudiendo ver por ejemplo los principales músculos,órganos y huesos superpuestos sobre un cuerpo real. Un ejemplo de esto se muestraen la �gura 8.

+ Cirujanos en prácticas. El realizar intervenciones en un simulador facilita laformación de los cirujanos y no requiere nada mas que las herramientas para realizarla cirugía y un ordenador donde utilizar la herramienta de realidad aumentada. Lonovedoso de incluir técnicas de realidad virtual es el realismo de la intervención.

Xaime Rivas Rey 11


Figura 7: Realidad aumentada en operaciones de la región craneoencefálica.

Figura 8: Realidad aumentada, medicina y educación.

Otro ejemplo donde la realidad aumentada resulta extremadamente útil en interven-ciones a distancia. El cirujano puede realizar su trabajo sin necesidad de estar presenteen la sala de operaciones. Este escenario permite que un doctor puede acceder a un mayornúmero de pacientes pues se elimina la barrera que supone el tener que viajar.



3.2. Sensor Bellyband

El sensor Bellyband es una pieza clave en el desarrollo de este proyecto. Son los datosde este sensor los que se muestran, mediante el uso de Realidad Aumentada, en la apli-cación BandApp, desarrollada en este proyecto.

El sensor forma parte de un sistema de monitorización del ritmo respiratorio. Estesistema se divide en los siguientes componentes:

+ Banda elástica donde se encuentran tanto la antena, formada por tejido conductor,como el chip RFID.

+ Lector RFID, que se encarga de interrogar al chip RFID y obtener una señal enfunción de cuan estirado se encuentre el sensor.

+ EL sensor RFID está conectado a una Raspberry Pi, que se encarga de almacenarlos datos.

A raíz del desarrollo de la aplicación BandApp en este trabajo de �n de máster, elproceso varía ligeramente, subiendose los datos del sensor a la nube en tiempo real. Laaplicación accede a dichos datos a través de la red y los muestra mediante técnicas deRealidad Aumentada.

Actualmente existen múltiples diseños para el tejido que conforma el sensor. De entrelos principales aspectos a tener en cuenta respecto al diseño del sensor, cabe destacar lossiguientes:

+ Materiales de la banda elástica.

+ Técnica de tejido de los distintos materiales.

+ Geometría de la antena conectada al chip RFID.

+ Distancia entre el sensor y el lector RFID que lee sus datos.

+ Efecto del cuerpo humano en la señal RFID recibida.

Xaime Rivas Rey 13


En la siguiente imagen se describe de forma simpli�cada la estructura del sistemaoriginal empleada como base para el desarrollo de este trabajo de �n de máster:

Figura 9: Sistema original de monitorización de la respiración.

El funcionamiento básico del sistema es el siguiente:

1. En primer lugar, es necesario colocar el sensor Bellyband en el abdomen del infante.

2. En función de la respiración, la banda elástica estará más o menos estirada. Es-te movimiento del sensor provoca que la antena, tejida en el interior del mismo,proporcione una respuesta distinta al lector RFID.

3. El lector RFID interroga al sensor con una determinada periodicidad y entrega losdatos a la Raspberry Pi. La Raspberry Pi almacena los datos para que posterior-mente puedan ser postprocesados en un ordenador más potente.

El desarrollo de este proyecto ha facilitado este proceso pues permite visualizar losdatos en tiempo real, permitiendo a los encargados de generar los datos del sensor detec-tar posibles anomalías y corregirlas al instante. La nueva estructura de este sistema demonitorización del ritmo respiratorio para infantes sería el siguiente:



Figura 10: Sistema actualizado de monitorización de la respiración.

La principal diferencia entre este nuevo esquema y el tradicional es que donde antesera necesario postprocesar los datos para poder decidir si eran de calidad o no ahora sepueden visualizar en tiempo real. Esto permite tener una idea muy clara de como estáfuncionando el sensor y si los datos que se está recogiendo son de calidad o si por elcontrario sería necesario hacer algún cambio. Es esta posibilidad de reducir el tiemponecesario para coleccionar los datos la que motiva este trabajo de �n de máster. Esareducción en el tiempo de desarrollo del sensor facilitará enormemente la comercializacióndel sensor en un futuro cercano.

3.3. SimBaby

Una de las piezas clave en el desarrollo del sensor, cuyos datos se emplean en esteproyecto, es el SimBaby. Este dispositivo permite emular el comportamiento de un infantede manera muy �dedigna. En la siguiente lista se resumen las principales situaciones quese pueden simular con este bebé robótico:

+ Respiración espontánea con ritmo variable.

+ Movimiento lateral y bilateral de la caja torácica.

+ Exhalación de CO2.

+ Sonidos pulmonares, para detectar posibles anomalías respiratorias.

+ Retracciones respiratorias.

Xaime Rivas Rey 15


Los comportamientos que interesa simular de cara a la utilización del sensor Belly-band son los movimientos del pecho a distintos ritmos en función del ritmo respiratorio.El sensor emitirá una señal que variará con dicho movimiento y será esta señal la quepermita detectar anomalías en la respiración del bebé. En la siguiente imagen se puedeobservar el SimBaby:

Figura 11: Robot SimBaby.



Figura 12: Robot SimBaby en funcionamiento.

Este dispositivo ha sido diseñado y fabricado por la compañía Laerdal y su precioronda los 40,000 e. Para el desarrollo de este proyecto, se ha alquilado el producto alColegio de Medicina de Drexel.

Xaime Rivas Rey 17

4 OBJETIVO DEL PROYECTO Salud, sensores y realidad aumentada

4. Objetivo del proyecto

El objetivo de este proyecto es el desarrollo de una aplicación multiplataforma quepermita la visualización en tiempo real del sensor Bellyband. La motivación para haceresto es múltiple:

+ En primer lugar, el desarrollo de esta aplicación reducirá enormemente el tiem-po empleado en la recogida de datos del sensor. Esto permitirá probar muchosmas modelos del sensor en un menor tiempo, acelerando su desarrollo y por tantopermitiendo que el producto salga al mercado en un menor período de tiempo.

+ Por otro lado, una vez el sensor sea comercializado, esta aplicación puede ser unaherramienta muy útil de cara a la visualización de los datos en un hospital.Con el uso de una cámara se podría ver en tiempo real las constantes del pacientey controlar que su ritmo respiratorio se encuentra en un rango de valores seguro.

Dado que actualmente el sensor Bellyband todavía está en fase de desarrollo, Ban-dApp, nombre con el cual se ha bautizado la aplicación de realidad aumentada desarro-llada en este trabajo de �n de máster se orientará a agilizar dicho desarrollo para podercomercializar el sensor lo antes posible y reducir el número de víctimas del Síndrome deMuerte Súbita del Lactante.

Xaime Rivas Rey 19

5 SELECCIÓN ENTORNO DE DESARROLLO Salud, sensores y realidad aumentada

5. Selección Entorno de desarrollo

Dado que el objetivo del proyecto es realizar una aplicación multiplataforma es ne-cesario escoger, de entre los múltiples entornos de desarrollo existentes en la actualidadaquel que nos permita escribir la aplicación y exportarla de la manera más sencilla posiblea cualquiera de las plataformas requeridas.

Otro requisito para el entorno de desarrollo es que sea compatible con algún módulode realidad aumentada, pues es una de las principales características que se le va a exigira la aplicación.

5.1. Entornos de desarrollo multiplataforma

En la actualidad, existen multiples entornos de desarrollo de aplicaciones multiplata-forma. La ventaja de este tipo de herramientas es que permiten al desarrollador escribir laaplicación en un idioma común y luego exportarla a cualquiera de los principales sistemasoperativos:

+ Sistemas operativos para ordenadores y tablets:

+ Windows.

+ iOS.

+ Linux.

+ Sistemas operativos para dispositivos móviles:

+ Android.

+ iOS.

+ Windows Phone.

+ BlackBerry.

Existen múltiples entornos de desarrollo que nos permiten el desarrollo de aplicacionesmultiplataforma. En la siguiente lista se resumen las más importantes y consideradas paraeste trabajo:

+ Unity 3D.

+ Xamarin.

+ Sencha.

+ Corona.

A continuación se da una descripción de las principales características de estos entornosde desarrollo.

Xaime Rivas Rey 21


5.1.1. Unity 3D

Este entorno de desarrollo multiplataforma permite desarrollar aplicaciones de maneramuy sencilla. La clave de esta herramienta es su fuerte apuesta por permitir al usuariocrear la aplicación de manera visual. Esto quiere decir que para desarrollar la aplicaciónbasta con situar los elementos que queramos en nuestra aplicación y una vez se ha desa-rrollado la parte visual, se puede programar el comportamiento de dichos elementos.

Mediante el uso de escenarios, Unity permite al usuario reutilizar gran cantidad decódigo de forma muy intuitiva. Esto acelera enormemente el desarrollo de la aplicación.La programación de la aplicación se puede realizar tanto en C # como en JavaScript.

En lo que respecta al soporte de herramientas de Realidad Aumentada, Unity 3D escompatible con gran variedad de SDKs, entre ellas destacan:

+ Vuforia.

+ String.

+ Sphero.

+ Xloudia.

5.1.2. Xamarin

Esta herramienta dispone de una versión gratuita. Además ofrece en su versión de pa-go asistencia de cara a la publicación de la aplicación en las tiendas de aplicaciones tantode Google como de Apple. Este entorno de desarrollo facilita el control del rendimientode cualquier aplicación, permitiendo realizat tests virtuales en mas de 1000 dispositivosdistintos. Esto puede ser muy conveniente para comprobar que nuestra aplicación funcio-nará correctamente independiente de la plataforma y/o dispositivo en que se utilice.

El desarrollo de la aplicación se puede hacer tanto en Ruby como C #.

En lo que respecta a los módulos de realidad Aumentada, existe un SDK que permitehacer hasta cierto punto, determinadas aplicaciones de realidad aumentada. El mayor retoen este aspecto es la falta de tutoriales en comparación con otros entornos de desarrollocomo Unity 3D.

5.1.3. Sencha

Este entorno de desarrollo permite desarrollar la aplicación en HTML 5, lenguaje quedispone de una gran cantidad de elementos prefabricados que permiten reducir el tiempode desarrollo para la aplicación.


5 SELECCIÓN ENTORNO DE DESARROLLO Salud, sensores y realidad aumentada

Una vez la aplicación ha sido desarrollada con HTML 5, es necesario emplear otraplataforma que nos permita exportarla a los principales sistemas operativos actuales. Unade las opciones recomendadas es la herramienta de Adobe �PhoneGap�.

5.1.4. Corona

Una de las mayores ventajas de Corona es la posibilidad de poder empezar a progra-mar en cuanto se instala el entorno de desarrollo. Los autores de la herramienta ofrecenuna forma muy rápida de empezar a desarrollar la aplicación.

Respecto al lenguaje de programación, las aplicaciones se desarrollan en Lua, lenguajebasado en C.

El principal problema con este entorno de desarrollo es la falta de soporte con respectoa la Realidad Aumentada, elemento fundamental para este trabajo de �n de Máster.

5.1.5. Entorno de desarrollo escogido

Debido a la gran comunidad de usuarios, precio, soporte para Realidad Aumentaday gran cantidad de ejemplos y tutoriales disponibles en la red, se ha decidido emplearel entorno de desarrollo Unity 3D. Además el poder programar tanto en C # como enJavaScript facilita enormemente el desarrollo de la aplicación.

5.2. Herramientas de Realidad Aumentada en Unity 3D

Unity 3D es compatible con gran variedad de SDKs de Realidad Aumentada, las masdestacadas estan recogidas en la siguiente lista:

+ Vuforia.

+ Xloudia.

+ String.

+ Sphero.

5.2.1. Herramienta de Realidad Virtual escogida

Debido a la gran cantidad de ejemplos y tutoriales disponibles en la red, se ha decidoemplear la SDK de Vuforia.

Xaime Rivas Rey 23

6 DESARROLLO DE LA APLICACIÓN Salud, sensores y realidad aumentada

6. Desarrollo de la Aplicación

En el presente apartado se detallará el proceso de desarrollo de la aplicación. El primerpaso consistió en el estudio de los múltiples tutoriales disponibles en la página web deUnity 3D y Vuforia para explorar todas las posibilidades que dicho entorno de desarrolloofrece. El siguiente paso fue desarrollar la aplicación, dividida en tres grandes bloques decódigo:

+ Acceso a la nube

+ Menú interactivo

+ Visualización de datos con realidad aumentada

+ Grá�co

+ Valor numérico

6.1. Tutoriales Unity 3D - Vuforia SDK

Este subapartado resume, con dos de los múltiples tutoriales realizados previo desa-rrollo de BandApp, las distintas posibilidades que Unity 3D junto con Vuforia ofrece alusuario.

6.1.1. Tutorial Unity - �Roll a Ball�

Este tutorial permite al usuario tener una primera toma de contacto con el entornode desarrollo de Unity 3D. Permite que el desarrollador gane soltura empleando los prin-cipales componentes para desarrollar una aplicación, exportarla a múltiples plataformasy en general tener una primera toma de contacto con el entorno de desarrollo.

Este tutorial muestra al usuario como en menos de una hora se puede desarrollar unjuego completamente funcional que consiste en mover una bola intentando recoger unaserie de elementos dispersos por la escena en el menor tiempo posible.

El primer paso para comenzar a desarrollar la aplicación en el editor de Unity es crearun proyecto y una vez hecho esto ya se puede comenzar a editar la escena que describiráel aspecto visual de nuestra aplicación. El editor de unity está formado por 3 elementosprincipales:

+ Scene view o Modo escenario. En esta parte del editor podemos ver y editar lasescenas que conforman nuestra aplicación. Es decir, cuando sea necesario cambiarel aspecto de nuestra aplicación será aquí donde se pueda hacer.

Xaime Rivas Rey 25

https://unity3d.com/learn/tutorials/projects/roll-ball-tutorial


+ Game view o Modo de juego. En esta parte del editor se ve única y exclusivamentelo que se vería en caso de exportar la aplicación y ejecutarla de forma independientea Unity.

+ Inspector view o Inspector de elementos. Esta parte del editor muestra y permitela modi�cación de los principales elementos que se tengan en las escenas de nuestraaplicación.

En la siguiente imagen se pueden observar las tres partes principales que conformanel editor:

Figura 13: Editor de Unity 3D.

Cualquier aplicación desarrollada en Unity estará formada en general por los siguienteselementos:

+ Una o más escenas, donde se de�nen los elementos visuales de la aplicación.

o Cámara. Su posición de�nirá como se verá la escena en el modo de juego(Game View). En caso de no existir una camara en nuestra escena no será posiblecompilar la aplicación.

o Fuente de luz. Este elemento de�nirá la iluminación de nuestra escena.

+ Scripts donde se de�ne el comportamiento de los elementos visuales en cualquierescena. Los scripts estarán escritos en C# o JavaScript.



+ Materiales. De�nen las características visuales de los elementos existentes en laescena considerada.

+ Prefabs. Estos elementos son quizá los más importantes. Es gracias a estos com-ponentes que el desarrollo en Unity es tan rápido y sencillo. Mediante el uso deelementos prefabricados se simpli�ca enormemente el desarrollo de cualquier apli-cación pues es posible reutilizar código de distintas aplicaciones.

En la siguiente imagen se pueden observar los elementos necesarios en la aplicacióncreada siguiendo el tutorial �Roll a Ball�:

Figura 14: Elementos de la aplicación Roll a Ball.

La Escena es el primer y más importante archivo de la aplicación, en el se de�nen losdistintos elementos grá�cos de nuestra aplicación. En la siguiente imagen se muestran loselementos visuales de esta escena:

Xaime Rivas Rey 27


Figura 15: Elementos que conforman la escena de nuestra aplicación.

+ La cámara permite de�nir desde que ángulo observamos la escena cuando ejecutemosla aplicación.

+ El elemento �Directional Light� de�ne la iluminación de nuestra escena.

+ Es necesario de�nir el terreno en el que el jugador (la bola) se va a mover, para tal�n se de�ne un elemento que actúa como suelo �Ground� y cuatro elementos quecon�nan al jugador en un espacio cerrado, �Walls�.

+ El elemento �Player� de�ne el comportamiento de nuestro jugador. En este caso,Unity ofrece la posibilidad de mover el jugador mediante el teclado del ordenadoro mediante los sensores de rotación de un smartphone. Los scripts que hacen estoposible forman parte de las herramientas embebidas en el editor de Unity, siendotan sencillo como seleccionar en el elemento Jugador como va a ser controlado.

+ Los elementos que el jugador debe recoger están de�nidos como �Pick Ups�. En estecaso si es necesario realizar un pequeño script que de�na que debe suceder cuandoel jugador toca cualquiera de estos elementos. Para esta aplicación se ha decido queen caso de colisión entre el jugador y los elementos a recoger estos desaparezcan dela escena.

+ Cuando el jugador consigue recoger todos los elementos se muestra un texto deenhorabuena. Este texto está de�nido en el elemento �Canvas�. El elemento �Even-tSystem� siempre va acompañando, de forma automática, cualquier Canvas quede�namos en la escena.



Para este proyecto ha sido necesario de�nir 3 scripts diferentes. La �nalidad de cadauno se recoge en la siguiente lista:

+ Controlador de la cámara: este script fuerza la cámara existente en nuestra escenaa mantener una distancia constante respecto a nuestro jugador, de manera que sieste se mueve lo que podemos ver en la aplicación imite dicho movimiento.

+ Controlador del jugador: este código controla el número de elementos recogidos ycuando se han recogido todos se encarga de mostrar un texto de felicitación en lapantalla. Este scripts también se encarga de ocultar los elementos que hayan sidorecogidos.

+ Animación de los �Pick Ups�: este código se encarga de hacer rotar los elementosque el jugador debe recoger a lo largo del juego.

A continuación se pueden observar las citados scripts:

Controlador de la Cámara Programa que controla el comportamiento de la cámara.

using UnityEngine;

using System.Collections;

public class CameraController : MonoBehaviour {

public GameObject Player;

private Vector3 offset;

// On the first frame we compute the offset between the camera and the player

void Start () {

offset = transform.position - Player.transform.position;

}

// LateUpdate is like Update but wat for everything else to be computed (We are sure

that the player has pressed to move

void LateUpdate () {

// We make sure the camera has a distance of offset with the player always

transform.position = Player.transform.position + offset;

}

}

Controlador del Jugador Script principal, encargado de manejar al jugador y los ele-mentos que debe recoger a lo largo del juego.

using UnityEngine;

using UnityEngine.UI;


public class PlayerController : MonoBehaviour {

public float speed;// Public to be able to edit it in the inspector view in unity

private Rigidbody rb; //This object will reference to the attach rigid body if there is

one

private int count;

Xaime Rivas Rey 29


public Text countText;

public Text winText;

void Start()// This will be executed when the first fram of the game is processed

{

rb = GetComponent <Rigidbody >();

count = 0;

SetCountText ();

winText.text = "";

}

//Is called before performing any Physics calculation , this is where our physics will

go

void FixedUpdate ()

{

/*If you type ctrl + ' you 'll search in the API reference for whatever you have

selected when doing so*/

float moveHorizontal = Input.GetAxis ("Horizontal");

float moveVertical = Input.GetAxis ("Vertical");

Vector3 movement = new Vector3 (moveHorizontal , 0.0f, moveVertical); // Y is 0 becase

we want the ball cointainend in the plane

rb.AddForce (movement*speed);

}

void OnTriggerEnter( Collider other){

if (other.gameObject.CompareTag ("Pick Up")) {

other.gameObject.SetActive (false);

count = count + 1;

SetCountText ();

if (count >= 8) {

winText.text = "CONGRATULATIONS!";

}

}

}

void SetCountText (){

countText.text = "Count: " + count.ToString ();

}

}

Animación de los �Pick Ups� Script encargado de animar los elementos que el juga-dor debe recoger a lo largo del juego.

using UnityEngine;


public class Rotator : MonoBehaviour {

// Update is called once per frame

void Update () {

transform.Rotate (new Vector3 (15, 30, 45) * Time.deltaTime);

}

}



6.1.2. Tutorial Vuforia - �Image Markers�

Este tutorial tiene como objetivo familiarizar al desarrollador con las principales he-rramientas de Realidad Aumentada que Vuforia ofrece para el editor de Unity 3D. Unavez �nalizado este tutorial, la aplicación desarrollada mostrará un modelo 3D de un edi-�cio siempre y cuando la cámara de nuestro dispositivo esté apuntando a una imagendenominada marcador.

Al igual que en el tutorial anterior, el primer paso es crear el proyecto y la escenaprincipal. Una vez hecho esto, la novedad reside en importar el SDK de Vuforia en nuestroproyecto. En la siguiente imagen se muestra el proceso:

Figura 16: Proceso de importación del paquete de RA de Vuforia.

Una vez hacemos clic en importar nuevo paquete, seleccionamos la SDK de Vuforia.hecho esto debemos seleccionar todos los elementos del paquete, como se muestra en laFigura 17.

El siguiente paso es dotar a nuestra escena de una elemento Prefab denominado �AR-Camera�. Este elemento, desarrollado por Vuforia, dará acceso a la cámara de nuestroordenador y/o móvil a la aplicación, mostrándola en nuestra escena.

Una vez tenemos la cámara de Realidad Aumentada en nuestra escena, el siguientepaso es situar un elemento que actúe como marcador en nuestra aplicación. La �nalidadde este marcador es dar un elemento de referencia a la cámara. Cuando nuestro dispositivodetecte este marcador entre múltiples posibilidades, en este caso simplemente se mostraráel modelo de un edi�cio.

Xaime Rivas Rey 31


Figura 17: Selección de los elementos a importar.

Los elementos necesarios en la escena para que este tutorial funcione son dos:

Figura 18: Elementos presentes en la escena.

+ ARCamera: este elemento Prefab, desarrollado por Vuforia se encarga de detectar



la imagen que actúa como marcador y en caso de que se detecte, mostrar un modelo3D, de un edi�cio en este caso, asociado con dicha imagen.

+ ImageMarker: este elemento se encarga de de�nir que imagen va a actuar comomarcador en nuestra aplicación de realidad aumentada. Asociado a este elementosiempre debe de haber un modelo 3D de algún objeto o algún otro elemento que sequiera mostrar cuando el marcador aparezca frente a la cámara.

En la siguiente �gura puede verse una captura de la aplicación en funcionamiento.Cuando la imagen que actúa como marcador aparece en la escena, superpuesto a dichomarcador se muestra el modelo 3D de un edi�cio. Este modelo se mueve de forma solidariacon el marcador, de forma que si este gira el modelo también lo hace. Si el marcador dejade ser visible el modelo del edi�cio desaparece con él.

Figura 19: Primera aplicación de Realidad Aumentada.

Una vez está aplicación funciona, ya se han presentado los principales elementos quese emplearán para desarrollar la aplicación BandApp en este trabajo de �n de Máster.

Xaime Rivas Rey 33


6.2. BandApp

A la vista de todo lo que se puede hacer con Unity y la SDK de Realidad AumentadaVuforia, en este subapartado se pretende resumir como funcionan las principales partesde la aplicación. BandApp se compone principalmente de tres grandes bloques:

+ Conexión a la nube

+ Menú interactivo

+ Visualización de datos

A continuación se describen individualmente cada uno de los bloques que conformanla aplicación.

6.2.1. Conexión a la nube

El primer paso para desarrollar la aplicación es conectarla a la red y por ende a losdatos del sensor. Los pasos que se han seguido para desarrollar esta parte de la aplicaciónson los siguientes:

1. Realizar peticiones de tipo GET y mostrar la respuesta en la consola del editor.

2. Descargar mediante una petición GET un archivo JSON, pues es el formato en quese almacenan los datos del sensor.

3. Aplicar un JSON parser al documento de manera que extraiga los datos que nece-sitamos mostrar al usuario.

A continuación se muestra una captura del proceso además del código desarrolladopara tal �n:



Figura 20: GET request con Unity 3D

En las anteriores �guras se observa como se descarga el archivo, se analiza medianteun Parser y se extrae el valor de RSSI (Received Signal Strength Indication), valor queinteresa mostrar en la aplicación pues con él se realiza la monitorización del bebé.

Código del JSON parser y gestión de datos Script encargado de animar los ele-mentos que el jugador debe recoger a lo largo del juego.

/* Script to get a json file with a GET request , parse it and extract the

RSSI field. If you want to parse other JSON , just put the new name where

rssi.*/

using System.Text.RegularExpressions;

using UnityEngine;


using SimpleJSON;

public class parsing : MonoBehaviour {

//JSON file. No http for PC, use it for Android!

private string json_url = "https ://raw.githubusercontent.com/Xaimerr/test -repo/master/

out_seconds1.json?token=AQHDDoR2Y04iK7gzDJBfo4nFqCkHWAjxks5X2uC2wA %3D %3D";

private string receivedHTML = "";

private Vector2 m_Position = Vector2.zero;

private string [] data = new string [0];

public string field = "rssi";

// Use this for initialization

IEnumerator Get ()

{

// Create a download object

Xaime Rivas Rey 35


WWW download = new WWW( json_url);

// Wait until the download is done

yield return download;

// Check for errors

if(! string.IsNullOrEmpty(download.error))

{

print( "Error downloading: " + download.error );

}

else // If there is none , proceed to parse the JSON

{

receivedHTML = download.text;

var N = JSON.Parse(receivedHTML);

int numberDataPoints = N["data"].Count;

string [] str = new string[numberDataPoints ];

for (int i = 0; i < numberDataPoints; i++)

{

str[i] = N["data"][i][field];

}

data = str;

}

}

void OnGUI()

{

if (GUI.Button (new Rect (500, 20, 80, 40), "Parse?"))

{

StartCoroutine(Get());

}

m_Position = GUILayout.BeginScrollView(m_Position);

if(data.Length >0)

{

for (int i = 0; i < data.Length; i++)

{

GUILayout.Label(field+" = "+data[i]);

}

}

GUILayout.EndScrollView ();

}

}

6.2.2. Desarrollo del menú

Una vez se ha conseguido descargar los datos del sensor y a falta de visualizarlos, esinteresante desarrollar un menú interactivo que permita al usuario moverse entre distintasescenas. las escenas que se desarrollarán en este proyecto son 4:

+ Visualización del valor numérico de la señal del sensor junto con un pequeño grá�co.

+ Visualización de un grá�co a tamaño completo, superpuesto a las imágenes del bebé.

+ Visualización de una escena de demostración donde ver como se muestran grá�ca-mente los datos sin necesidad de tener el sensor funcionando.



+ Escena de ayuda donde se describa el funcionamiento de la aplicación.

Para invocar el menú de la aplicación es necesario pulsar dos veces la pantalla. Encaso de estar empleando un ordenador con hacer clic con el ratón sería su�ciente, en elcaso de un dispositivo con pantalla táctil basta con tocar la pantalla dos veces.

En las siguiente imagen se puede ver el resultado �nal de este menú:

Figura 21: Menú de la aplicación.

En los anexos de este documento se encuentra todo el código empleado. En particular,para el menú se han empleado los códigos D.6 D.7 y D.8. El primer código se encarga decontrolar si el usuario ha tocado la pantalla dos veces y en caso de ser así abrir el menú.El segundo código se encarga de de�nir las opciones del menú y lo que sucede cuando pul-samos los diferentes botones del mismo. El último código se encarga de animar el menú,es decir, cuando se activa o desactiva el menú este se deslizará hasta situarse en el centroen caso de abrir el menú o desaparecer en el caso de cerrarlo.

6.2.3. Visualización de datos

Respecto a la visualización de datos existen dos posibilidades:

+ Mostrar el valor numérico del sensor en tiempo real y un pequeño grá�co.

+ Mostrar un grá�co a tamaño completo donde se vea claramente la tendencia en losvalores del sensor para un cierto periodo de tiempo, facilitando la toma de decisiones.

En las siguientes imágenes se observan los distintos modos de funcionamiento de laaplicación:

Xaime Rivas Rey 37


Figura 22: Aplicación en modo valor numérico y pequeño grá�co.

Figura 23: Aplicación en modo de pantalla completa.

Los código empleados en esta parte de la aplicación son D.1 y D.4. El primer código se



encarga de mostrar tanto el grá�co como el texto en cuanto se detecta la imagen marcador.El segundo código se encarga de gestionar la expresión grá�ca de datos.

6.2.4. Integración de la aplicación

Los tres bloques que conforman la aplicación (acceso a la nube, menú interactivoy la visualización de datos) se han desarrollado de forma independiente. Un paso muyimportante en el desarrollo de BandApp ha sido integrar las distintas partes del proyectode forma que la aplicación funcione correctamente.

Xaime Rivas Rey 39

7 RESULTADO FINAL Salud, sensores y realidad aumentada

7. Resultado Final

En el siguiente vídeo puede observarse la aplicación funcionando en tiempo real mos-trando los datos del sensor en el modo de pantalla completa.

Figura 24: Logo de la aplicación.

Figura 25: Imagen mostrada al iniciar la aplicación.

Xaime Rivas Rey 41

https://youtu.be/VRqj7PY9iDA


Figura 26: Modo 1 de visualización de datos.

Figura 27: Modo 2 de visualización de datos.


7 RESULTADO FINAL Salud, sensores y realidad aumentada

Figura 28: Menú de la aplicación.

Xaime Rivas Rey 43

8 CONCLUSIONES Salud, sensores y realidad aumentada

8. Conclusiones

El objetivo de este Trabajo de Fin de Máster era el desarrollo de una aplicación multi-plataforma que permita la visualización en tiempo real de los datos del sensor Bellyband.La motivación para esto era principalmente reducir el tiempo empleado en la recogidade datos del sensor Bellyband. Permitiendo probar un mayor número de modelos delsensor menos tiempo, acelerando su desarrollo y por tanto permitiendo que el productosalga al mercado en un menor período de tiempo.

Tras los resultados obtenidos, se puede concluir que se ha cumplido el objetivo de esteTrabajo de Fin de Máster. La aplicación es capaz de mostrar en tiempo real los datosproporcionados por el sensor. Además se emplea realidad aumentada, cuando la aplicacióndetecta mediante el uso de una cámara que estamos apuntando al sensor, se muestran losdatos superpuestos a la imagen del paciente.

Figura 29: Muestra de datos en tiempo real - SimBaby.

Xaime Rivas Rey 45

9 LÍNEAS FUTURAS Salud, sensores y realidad aumentada

9. Líneas futuras

El desarrollo de esta aplicación abre la puerta a otras posibles aplicaciones, en elcampo de la medicina principalmente, donde se aprovechen tecnologías como la RealidadAumentada para facilitar el trabajo de doctores y demás personal de un hospital a la horade monitorizar el estado de los pacientes.

En la siguiente lista se resumen algunas de las posibles lineas futuras de investigaciónde este Trabajo de Fin de Máster:

+ Identi�cación automática de pacientes basada en la base de datos del hospital ylas fotografías más recientes de los mismos. Esta linea de futuro pretende generalizarel uso de la aplicación. Extendiendo su uso más allá de la visualización de datos de unsensor. Accediendo a las fotografías que un hospital tiene de sus pacientes, es posibleidenti�car a una persona cuando asiste a una consulta. Mediante reconocimientofacial, se podría dar acceso a su historial médico.

+ Mostrar datos de múltiples sensores, siendo posible monitorizar no solo el ritmorespiratorio sino también el ritmo cardíaco, niveles de oxígeno, glucosa...

+ Generalizar la aplicación para que muestre datos de cualquier sensor. Un ejemploen el campo de la educación podría ser el de las galgas extensiométricas en unensayo a tracción. Sería interesante mostrar de forma visual las cargas a las que estásometido el elemento, donde sucederá la rotura y otros datos de interés.

+ Sería interesante realizar una serie de encuestas a personal médico donde serecojan las opiniones de distintos profesionales del sector respecto a que datos seríainteresante visualizar en la aplicación y no solo eso, sino en que formato deberíaverse (Un simple número, un código de colores que alerte en caso de riesgo, ungrá�co temporal).

Xaime Rivas Rey 47

REFERENCIAS Salud, sensores y realidad aumentada

Referencias

[1] D. Patron;, WilliamMongan, Timothy P. Kurzweg, Adam Fontecchio, Genevieve Dion,Endla K. Anday, and Kapil R. Dandekar. On the Use of Knitted Antennas andInductively Coupled RFID Tags for Wearable Applications. IEEE Transactions onBiomedical Circuits and Systems, PP:1932�4545, 2016.

[2] De-Kun Li, Marian Willinger, Diana B Petitti, Roxana Odouli, Liyan Liu, and Ho-ward J Ho�man. Use of a dummy (paci�er) during sleep and risk of sudden infantdeath syndrome (SIDS): population based case-control study. BMJ (Clinical researched.), 332(7532):18�22, 2006.

[3] W. Mongan, E. Anday, G. Dion, A. Fontecchio, K. Joyce, T. Kurzweg, Y. Liu, O. Mont-gomery, I. Rasheed, C. Sahin, S. Vora, and K. Dandekar. A Multi-Disciplinary Frame-work for Continuous Biomedical Monitoring Using Low-Power Passive RFID-BasedWireless Wearable Sensors. 2016 IEEE International Conference on Smart Compu-ting, SMARTCOMP 2016, 2016.

[4] Ilhaan Rasheed, Bryce Walburn, David Lee, and Van Le Nguyen. Wireless RespirationMonitoring System. 2015.

Xaime Rivas Rey 49

ÍNDICE DE FIGURAS Salud, sensores y realidad aumentada

Índice de �guras

1. Uso de la aplicación durante las pruebas del sensor. . . . . . . . . . . . . . 42. Bellyband: Parte frontal del dispositivo . . . . . . . . . . . . . . . . . . . . 53. SimBaby: Robot para simular la respiración de un bebé. . . . . . . . . . . 84. Parte frontal del sensor Bellyband. . . . . . . . . . . . . . . . . . . . . . . 95. Parte trasera del sensor Bellyband. . . . . . . . . . . . . . . . . . . . . . . 96. Muestra de datos en tiempo real - SimBaby. . . . . . . . . . . . . . . . . . 107. Realidad aumentada en operaciones de la región craneoencefálica. . . . . . 128. Realidad aumentada, medicina y educación. . . . . . . . . . . . . . . . . . 129. Sistema original de monitorización de la respiración. . . . . . . . . . . . . . 1410. Sistema actualizado de monitorización de la respiración. . . . . . . . . . . . 1511. Robot SimBaby. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1612. Robot SimBaby en funcionamiento. . . . . . . . . . . . . . . . . . . . . . . 1713. Editor de Unity 3D. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2614. Elementos de la aplicación Roll a Ball. . . . . . . . . . . . . . . . . . . . . 2715. Elementos que conforman la escena de nuestra aplicación. . . . . . . . . . . 2816. Proceso de importación del paquete de RA de Vuforia. . . . . . . . . . . . 3117. Selección de los elementos a importar. . . . . . . . . . . . . . . . . . . . . . 3218. Elementos presentes en la escena. . . . . . . . . . . . . . . . . . . . . . . . 3219. Primera aplicación de Realidad Aumentada. . . . . . . . . . . . . . . . . . 3320. GET request con Unity 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . 3521. Menú de la aplicación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3722. Aplicación en modo valor numérico y pequeño grá�co. . . . . . . . . . . . . 3823. Aplicación en modo de pantalla completa. . . . . . . . . . . . . . . . . . . 3824. Logo de la aplicación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4125. Imagen mostrada al iniciar la aplicación. . . . . . . . . . . . . . . . . . . . 4126. Modo 1 de visualización de datos. . . . . . . . . . . . . . . . . . . . . . . . 4227. Modo 2 de visualización de datos. . . . . . . . . . . . . . . . . . . . . . . . 4228. Menú de la aplicación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4329. Muestra de datos en tiempo real - SimBaby. . . . . . . . . . . . . . . . . . 4530. Estructura de Descomposición del Proyecto. . . . . . . . . . . . . . . . . . 57

Xaime Rivas Rey 51

Anexos

Plani�caciónTemporal

A PLANIFICACIÓN TEMPORAL Salud, sensores y realidad aumentada

A.1.

EstructuradeDescomposicióndelProyecto

BandApp

1.Proyecto

2.Estudiosprevios

3.Software

4.Pruebas

5.Integración

De�nicióndel

alcance

Plani�cación

temporal

Redacción

documentos

Revisiónbi-

bliográ�ca

Viabilidad

legal

Tutoriales

Accesoala

nube

Menúinter-

activo

Visualización

dedatos

Tutoriales

Menúinter-

activo

Accesoala

nube

Visualización

dedatos

Integración

software

Figura

30:Estructura

deDescomposicióndelProyecto.

Xaime Rivas Rey 57

2016

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

1.

Pro

yecto

1.1.D

efinicion

del

alcance

1.2.P

lanifi

caciontem

poral

1.3.R

edaccion

de

docu

men

tos

2.

Estu

dio

sp

revio

s

2.1.R

evision

bilb

iografica

2.2.E

ntorn

ode

desarrollo

3.

Softw

are

3.1.T

utoriales

3.2.A

ccesoa

lanub

e

3.3.M

enu

interactivo

3.4.V

isualizacion

de

datos

4.

Pru

eb

as

4.1.T

utoriales

4.2.A

ccesoa

lanub

e

4.3.M

enu

interactivo

4.4.V

isualizacion

de

datos

5.

Inte

gra

cion

5.1In

tegracionsoftw

are



A PLANIFICACIÓN TEMPORAL Salud, sensores y realidad aumentada

El proyecto se estructura en 5 grupos de tareas:

1. Proyecto

1.1. De�nición del alcance: esta tarea comprende la de�nición de los objetivosque se busca cumplir con este trabajo de �n de máster.

1.2. Plani�cación temporal: una vez se conocen los objetivos y tareas a realizares necesario establecer una plani�cación temporal donde se asignen los recursosnecesarios y se puede observar el camino crítico. El resultado de esta tarea es elDiagrama de Gantt del proyecto.

1.3. Redacción del documento: esta tarea consiste en la redacción del presentedocumento, siguiendo las guías para trabajos de �n de máster de la UniversidadPolitécnica de Madrid, en concreto las establecidas por la Escuela Ténica Superiorde Ingenieros Industriales.

2. Estudios previos

2.1. Revisión bibliográ�ca: esta tarea consiste en realizar una búsqueda de queaplicaciones existen en el campo de la medicina y la realidad aumentada.

2.2. Entorno de desarrollo: existen múltiples entornos de desarrollo para aplica-ciones multiplataforma, esta tarea consiste en escoger el que mejor se adapte a lasnecesidades del proyecto.

3. Sotfware

3.1. Tutoriales: esta tarea consiste en la realización de tutoriales de Unity 3D yVuforia para probar las distintas opciones disponibles para posteriormente desarro-llar la aplicación.

3.2. Acceso a la nube: la aplicación necesita comunicarse con la nube, esta tareaconsiste en desarrollar el código necesario para tal �n.

3.3. Menú interactivo: la aplicación debe tener un menú, esta tarea consiste enla realización del mismo.

3.4. Visualización de datos: por último es necesario expresar grá�camente lodatos del sensor en tiempo real mediante realidad aumentada. Esta tarea consisteen la realización de dicho código.

4. Pruebas

4.1. Tutoriales: es necesario hacer pruebas con los códigos desarrollados siguien-do los tutoriales.

4.2. Acceso a la nube: prueba del código para acceder a la nube.

4.3. Menú interactivo: prueba del código que implementa el menú de la aplica-ción.

Xaime Rivas Rey 59


4.4. Visualización de datos: prueba del código que expresa grá�camente los datosmediante realidad aumentada.

5. Integración

5.1. Integración del software: una vez se ha comprobado que los códigos desa-rrollados funcionan correctamente es necesario integrarlos y desarrollar el producto�nal, que es la aplicación BandApp.


Presupuesto

B PRESUPUESTO Salud, sensores y realidad aumentada

Presupuesto

Capítulo 1. Ingeniería

UNIDADES DESCRIPCIÓN PRECIO UNITARIO TOTAL e

540 Horas Horas de ingeniería 50, 00e/hora 27. 000, 00e

TOTAL CAPÍTULO 1. INGENIERÍA 27.000,00 e

Capítulo 2. Software


1 Ud.Windows 10 Pro - Ver-sión 64 bits

199, 99e 199, 99e

1 Ud. Vuforia Classic SDK 499, 99e 499, 99e9 Meses Unity Pro Version 125, 00e/mes 1. 125, 00e

TOTAL CAPÍTULO 2. SOFTWARE 1.824,98 e

Capítulo 3. Hardware


1 Ud. Alquiler SimBaby 6. 000, 00e 6. 000, 00e

1 Ud.Sistema de monitori-zación (sensores, lectorRFID y complementos)

2. 000, 00e 2. 000, 00e

1 Ud.Ordenador intel core i7,pantalla LED 21� y acce-sorios

1. 500, 00e 1. 500, 00e

TOTAL CAPÍTULO 3. HARDWARE 9.500,00 e

Xaime Rivas Rey 63

B PRESUPUESTO Salud, sensores y realidad aumentada

Resumen por Capítulos

Capítulo 1. Ingeniería .......................................................................... 27. 000, 00 e

Capítulo 2. Software .............................................................................. 1. 824, 98 e

Capítulo 3. Hardware ............................................................................ 9. 500, 00 e

Importe de Ejecución Material ......................................................... 38. 324, 98 e

13% Gastos generales ............................................................................... 4. 982, 25 e

6% Bene�cio industrial ............................................................................ 2. 299, 50 e

Importe de Ejecución ......................................................................... 45. 606, 73 e

21% IVA .................................................................................................... 9. 577, 41 e

Importe de Contrata .......................................................................... 55. 184, 14 e

El importe de contrata para este proyecto es de cincuenta ycinco mil ciento ochenta y cuatro euros y catorce céntimos.

Xaime Rivas Rey12 de Septiembre de 2016

Xaime Rivas Rey 65

Impacto

del proyecto

C IMPACTO DEL PROYECTO Salud, sensores y realidad aumentada

Impacto medioambiental del proyecto

Dado que el entregable �nal de este proyecto es una aplicación de software, el impac-to medioambiental del mismo se reduce a la energía necesaria para el desarrollo de laaplicación.

Con el objetivo de evaluar el impacto medioambiental, se pueden estimar los kilosequivalentes de CO2 que se generan durante el desarrollo de este proyecto. Para ello bastacon multiplicar el total de horas de ingeniería por el consumo de energía eléctrica incurridopor los principales componentes electrónicos empleados en el mismo:

+ Ordenador y accesorios: 150 [W]

+ Sensor, radio y Raspberry Pi: 50 [W]

Con el objetivo de tener en cuenta otros posibles consumos de energía puntuales seaplica un factor correctivo de 1.5. En total podemos suponer que la potencia requeridapara el desarrollo de este proyecto es de 300 [W]. Empleando la tabla de equivalenciasproporcionada en la web del Ministerio de Energía y Turismo sabemos que por cada[KWh] de energía eléctrica se generan 0,24 kg CO2 equivalentes.

Teniendo en cuenta que el total de horas de ingeniería para este proyecto asciende a540 podemos calcular los kilos equivalentes de CO2 generados de la siguiente manera:

540[h] · 0, 3[KW ] · 0, 24[Kg CO2eq/KWh] = 38,88[Kg de CO2]

El total de kilos de CO2 generados por este proyecto asciende a 38, 88 Kg. Para daralgún sentido a dicho valor numérico, cabe destacar que en 2012 la cantidad de toneladasde CO2 emitidas a la atmósfera en España ascendía a 350 millones por lo que la cantidadaquí generada se puede suponer irrelevante.

Impacto social del proyecto

Respecto al impacto social, esta aplicación se caracteriza por acelerar el desarrollode un sensor que ayuda a prevenir el Síndrome de Muerte Súbita del Lactante. Al acelerardicho desarrollo se consigue que el sensor se ponga a la venta en un tiempo menor y portanto se está aumentando el número de bebés que se pueden bene�ciar de su uso. Se puedeconcluir por tanto que el impacto social es positivo.

Xaime Rivas Rey 69


Impacto legal del proyecto

Los datos que se muestran en la aplicación son de tipo médico. Si bien en la faseactual estos datos provienen de una simulación, en un futuro serán datos provenientesde pacientes. Por este motivo se debe tener especial cuidado respecto al tratamiento dedichos datos y cumplir con la Ley orgánica de protección de datos vigente en el país dondese utilice la aplicación.


Código

D CÓDIGO C # Salud, sensores y realidad aumentada

D. Código C #

D.1. Script principal - detector del sensor y muestra de datos

using UnityEngine;



using System.Collections.Generic;

using DG.Tweening;

namespace Vuforia

{

public class ADefaultTrackableXaime : MonoBehaviour ,

ITrackableEventHandler

{

private float X;

private int flag = 0;

private float Xold = 0;

private float starttim;

public Text XText;

public GameObject textBackground;

public GameObject graphPrefab;

// public WMG_X_Dynamic realtime;

public static int myVar = 0;

private TrackableBehaviour mTrackableBehaviour;

//For RealTime

// public GameObject graphPrefab;

public WMG_Axis_Graph graph;

public bool performTests;

public bool noTestDelay;

public float testInterval;

public float testGroupInterval = 2;

public Ease easeType;

public GameObject realTimePrefab;

private float oldValue;

private float newValue;

GameObject realTimeObj;

float animDuration;

WaitForSeconds waitTime;

private WMG_Series s1;

private GameObject graphGO;

private WMG_Data_Source ds1;

void Start()

{

flag = 0;

X = 0;// We need to initilize the value of the variable

SetXText ();

myVar = 0;

textBackground.SetActive (false); // We disable the text background

realTimePrefab.SetActive (false);

starttim = Time.time;

mTrackableBehaviour = GetComponent <TrackableBehaviour >();

if (mTrackableBehaviour)

{

mTrackableBehaviour.RegisterTrackableEventHandler(this);

}

graphGO = GameObject.Instantiate(graphPrefab) as GameObject;

graph = graphGO.GetComponent <WMG_Axis_Graph >();

graph.changeSpriteParent(graphGO , this.gameObject);

Xaime Rivas Rey 73


graph.changeSpritePositionTo(graphGO , Vector3.zero);

graph.graphTitleOffset = new Vector2(0, 0);

graph.autoAnimationsDuration = testInterval - 0.1f;

graph.graphTitleString = "RSSI Real -time plot";

StartCoroutine(startTests ());

}

IEnumerator startTests () {

StartCoroutine(realTime ());

StartCoroutine(realTime ());

yield return new WaitForSeconds(testGroupInterval);

yield return new WaitForSeconds (6);

graph.graphTitleString = "Demo Completed Successfully :)";

}

IEnumerator realTime () {

if (flag == 0) {

//Debug.Log ("1");

// This is very similar to the dynamic data population via reflection.

// Main difference being the use of some WMG_Axis_Graph functions to start and

stop real -time updating / and the x-axis updates based on time.

ds1 = graph.lineSeries [0]. AddComponent <WMG_Data_Source > ();

// WMG_Data_Source ds2 = graph.lineSeries [1]. AddComponent <WMG_Data_Source >();

ds1.dataSourceType = WMG_Data_Source.WMG_DataSourceTypes.

Single_Object_Single_Variable;

// ds2.dataSourceType = WMG_Data_Source.WMG_DataSourceTypes.


// WMG_Series s1 = graph.lineSeries [0]. GetComponent <WMG_Series >();

s1 = graph.lineSeries [0]. GetComponent <WMG_Series > ();

// WMG_Series s2 = graph.lineSeries [1]. GetComponent <WMG_Series >();

realTimeObj = GameObject.Instantiate (realTimePrefab) as GameObject;

graph.changeSpriteParent (realTimeObj , this.gameObject);

ds1.setDataProvider <Transform > (realTimeObj.transform);

// ds2.setDataProvider <Transform >( realTimeObj.transform);

ds1.setVariableName ("localPosition.x");

// ds2.setVariableName (" localPosition.y");

s1.realTimeDataSource = ds1;

// s2.realTimeDataSource = ds2;

graph.xAxis.AxisMinValue = 0;

// graph.xAxis.AxisMaxValue = 15;

graph.yAxis.AxisMinValue = -60;

graph.yAxis.AxisMaxValue = -50;

//s1.seriesName = "RSSi";

// s2.seriesName = "Hex Y";

s1.UseXDistBetweenToSpace = false;

// s2.UseXDistBetweenToSpace = false;

graph.xAxis.SetLabelsUsingMaxMin = true;

graph.xAxis.LabelType = WMG_Axis.labelTypes.ticks;

graph.xAxis.numDecimalsAxisLabels = 1;

flag = 1;

}

graph.xAxis.AxisMinValue = 0;

// graph.xAxis.AxisMaxValue = 15;



s1.StartRealTimeUpdate ();



// Necesary a wait at least as big as the time used in every WMG_Anim

WMG_Anim.animPosition(realTimeObj , 0, Ease.Linear , new Vector3 (-56,-56,0));

WMG_Anim.animPosition(realTimeObj , 0.1f, Ease.Linear , new Vector3 (-59,-51,0));

yield return new WaitForSeconds (0.1f);










yield return new WaitForSeconds (1f);



s1.StopRealTimeUpdate ();

}

// Function to compute the time

void SetXText (){

if (myVar == 1) {

//XText.text = "RSSI = " + X.ToString ();

if (XText.text == "RSSI = -54") {

XText.text = "RSSI = -56";

} else if (XText.text == "RSSI = -56") {


}

else {


}

} else {

XText.text = " ";

}

}

void Update () {

if (Input.GetKeyDown ("space")) {


} else {

}

}

public void OnTrackableStateChanged(

TrackableBehaviour.Status previousStatus ,

TrackableBehaviour.Status newStatus)

{

if (newStatus == TrackableBehaviour.Status.DETECTED ||

newStatus == TrackableBehaviour.Status.TRACKED ||

newStatus == TrackableBehaviour.Status.EXTENDED_TRACKED && myVar == 0)

{

myVar = 1;

X = (int)(Time.time - starttim);

SetXText ();

textBackground.SetActive (true);

Xaime Rivas Rey 75


StartCoroutine(realTimeTests ());

}

else

{

myVar = 0;


SetXText ();

textBackground.SetActive (false);

}

}

}

}

D.2. Scene Loader - permite cambiar la escena actual en la App

using UnityEngine;



public class SceneLoader : MonoBehaviour

{

public float loadingDelay = 3.0F;

void Start()

{

StartCoroutine(LoadNextSceneAfter(loadingDelay));

}

private IEnumerator LoadNextSceneAfter(float seconds)

{

yield return new WaitForSeconds(seconds);

// buildIndex () returns the index of the scene in the Build settings.

UnityEngine.SceneManagement.SceneManager.LoadScene(UnityEngine.SceneManagement.

SceneManager.GetActiveScene ().buildIndex +1);

}

}

D.3. Timer en C #

using UnityEngine;



public class ValueDisplayer : MonoBehaviour {

private int X;


public Text XText;

// Intilization of the variable holding the value to display

void Start () {


SetXText ();


}

// Function to compute the time

void SetXText (){

XText.text = "Belly Band Value = " + X.ToString ();

}

// We update the value every frame



void Update (){


SetXText ();

}

}

D.4. Grá�co de datos

using UnityEngine;


using System.Collections.Generic;

using DG.Tweening;


public class WMG_X_Dynamic : MonoBehaviour {

public GameObject graphPrefab;

public WMG_Axis_Graph graph;

public bool performTests;

public bool noTestDelay;

public float testInterval;

public float testGroupInterval = 2;

public Ease easeType;

public GameObject realTimePrefab;

private float oldValue;

private float newValue;

GameObject realTimeObj;

float animDuration;

WaitForSeconds waitTime;

void Start() {

GameObject graphGO = GameObject.Instantiate(graphPrefab) as GameObject;

graph = graphGO.GetComponent <WMG_Axis_Graph >();

graph.changeSpriteParent(graphGO , this.gameObject);

graph.changeSpritePositionTo(graphGO , Vector3.zero);

graph.graphTitleOffset = new Vector2(0, 0);

graph.autoAnimationsDuration = testInterval - 0.1f;

realTimePrefab.SetActive (false);

waitTime = new WaitForSeconds(testInterval);

animDuration = testInterval - 0.1f; // have animations slightly faster than the test

interval

if (animDuration < 0) animDuration = 0;

//if (performTests) {


//}

}

public void test(){

Debug.Log ("Testing");

}

public IEnumerator startTests () {

//yield return new WaitForSeconds(testGroupInterval);

// real -time tests

graph.graphTitleString = "RSSI Real -time plot";

Xaime Rivas Rey 77


StartCoroutine(realTimeTests ());

//if (! noTestDelay) yield return new WaitForSeconds (17);

//yield return new WaitForSeconds(testGroupInterval);


graph.graphTitleString = "Demo Completed Successfully :)";

}

public IEnumerator realTimeTests () {

Debug.Log ("1");

// This is very similar to the dynamic data population via reflection.

// Main difference being the use of some WMG_Axis_Graph functions to start and stop

real -time updating / and the x-axis updates based on time.

WMG_Data_Source ds1 = graph.lineSeries [0]. AddComponent <WMG_Data_Source >();

ds1.dataSourceType = WMG_Data_Source.WMG_DataSourceTypes.


WMG_Series s1 = graph.lineSeries [0]. GetComponent <WMG_Series >();

realTimeObj = GameObject.Instantiate(realTimePrefab) as GameObject;

graph.changeSpriteParent(realTimeObj , this.gameObject);

ds1.setDataProvider <Transform >( realTimeObj.transform);

ds1.setVariableName("localPosition.x");

s1.realTimeDataSource = ds1;



//s1.seriesName = "RSSi";

s1.UseXDistBetweenToSpace = false;

graph.xAxis.SetLabelsUsingMaxMin = true;

graph.xAxis.LabelType = WMG_Axis.labelTypes.ticks;

graph.xAxis.numDecimalsAxisLabels = 1;

s1.StartRealTimeUpdate ();

// Need the wait for at least as long as the time used in WMN_Anim

WMG_Anim.animPosition(realTimeObj , 0, Ease.Linear , new Vector3 (0,-56,0));















s1.StopRealTimeUpdate ();

//Need this or returns an error


}

}

D.5. Pantalla de inicio - mostrar durante 3 segundos

using UnityEngine;




using UnityEngine.SceneManagement;

public class Timer : MonoBehaviour {

private int X;// Is the timer in seconds


public int timeAnim = 3;

public string SceneToLoad = "graph";

//Start up time

void Start () {



}

// We updte the value every frame

void Update (){


if (X >= timeAnim) {

SceneManager.LoadScene (SceneToLoad);

}

}

}

D.6. Gestor de pantalla táctil - accionamiento del menú

using UnityEngine;


public class TapHandler : MonoBehaviour

{

private const float DOUBLE_TAP_MAX_DELAY = 0.5f;// seconds

private int mTapCount = 0;

private float mTimeSinceLastTap = 0;

private MenuAnimator mMenuAnim = null;

void Start()

{

mTapCount = 0;

mTimeSinceLastTap = 0;

mMenuAnim = FindObjectOfType <MenuAnimator >();

}

void Update ()

{

if (mMenuAnim && mMenuAnim.IsVisible ())

{

mTapCount = 0;


}

else

{

HandleTap ();

}

#if UNITY_ANDROID

// On Android , the Back button is mapped to the Esc key

if (Input.GetKeyUp(KeyCode.Escape))

{

#if (UNITY_5_2 || UNITY_5_1 || UNITY_5_0)

Application.LoadLevel("Vuforia -1-About");

Xaime Rivas Rey 79


#else // UNITY_5_3 or above

UnityEngine.SceneManagement.SceneManager.LoadScene("Vuforia -1-About");

#endif

}

#endif

}

#endregion // MONOBEHAVIOUR_METHODS

#region PRIVATE_METHODS

private void HandleTap ()

{

if (mTapCount == 1)

{

mTimeSinceLastTap += Time.deltaTime;

if (mTimeSinceLastTap > DOUBLE_TAP_MAX_DELAY)

{

// too late for double tap ,

// we confirm it was a single tap

OnSingleTapConfirmed ();

// reset touch count and timer

mTapCount = 0;


}

}

else if (mTapCount == 2)

{

// we got a double tap

OnDoubleTap ();

// reset touch count and timer


mTapCount = 0;

}

if (Input.GetMouseButtonUp (0))

{

mTapCount ++;

}

}

protected virtual void OnSingleTapConfirmed ()

{

CameraSettings camSettings = GetComponentInChildren <CameraSettings >();

if (camSettings)

{

camSettings.TriggerAutofocusEvent ();

}

}

protected virtual void OnDoubleTap ()

{

if (mMenuAnim && !mMenuAnim.IsVisible ())

{

mMenuAnim.Show();

}

}

}

D.7. Opciones del menú

using UnityEngine;





using Vuforia;

using UnityEngine.SceneManagement;

public class MenuOptions : MonoBehaviour

{

private CameraSettings mCamSettings = null;

private TrackableSettings mTrackableSettings = null;

private MenuAnimator mMenuAnim = null;

protected virtual void Start()

{

mCamSettings = FindObjectOfType <CameraSettings >();

mTrackableSettings = FindObjectOfType <TrackableSettings >();

mMenuAnim = FindObjectOfType <MenuAnimator >();

}

//We check the scene we are in, if it's the one we select just close the menu

public void ShowNormalScreen ()

{

Scene scene = SceneManager.GetActiveScene ();

if(scene.name == "graph"){

CloseMenu ();

}

else{

UnityEngine.SceneManagement.SceneManager.LoadScene("graph");

}

}


public void ShowDemoScreen ()

{


if(scene.name == "demo"){

CloseMenu ();

}

else{

UnityEngine.SceneManagement.SceneManager.LoadScene("demo");

}

}


public void ShowFullScreen ()

{

Scene scene2 = SceneManager.GetActiveScene ();

if(scene2.name == "graphFullScreen"){

CloseMenu ();

}

else{

UnityEngine.SceneManagement.SceneManager.LoadScene("graphFullScreen");

}

}


public void ShowHelpScreen ()

{

Scene scene3 = SceneManager.GetActiveScene ();

if(scene3.name == "help"){

Xaime Rivas Rey 81


CloseMenu ();

}

else{

UnityEngine.SceneManagement.SceneManager.LoadScene("help");

}

}

public void ToggleAutofocus ()

{

Toggle autofocusToggle = FindUISelectableWithText <Toggle >("Autofocus");

if (autofocusToggle && mCamSettings)

mCamSettings.SwitchAutofocus(autofocusToggle.isOn);

CloseMenu ();

}

public void ExitApplication ()

{

Application.Quit();

}

public void NameScene ()

{


Debug.Log (scene.name);

}

public void SelectCamera(bool front)

{

if (mCamSettings)

mCamSettings.SelectCamera(front ? CameraDevice.CameraDirection.CAMERA_FRONT :

CameraDevice.CameraDirection.CAMERA_BACK);

CloseMenu ();

}

public void CloseMenu ()

{

if (mMenuAnim)

mMenuAnim.Hide();

}

}

D.8. Animación del Menú

using UnityEngine;


public class MenuAnimator : MonoBehaviour

{

private Vector3 mVisiblePos = Vector3.zero;

private Vector3 mInvisiblePos = -Vector3.right * 2000;

private float mVisibility = 0;

private bool mVisible = false;

private Canvas mCanvas = null;

private MenuOptions mMenuOptions = null;

[Range (0,1)]

public float SlidingTime = 0.3f;// seconds

void Start ()

{



mInvisiblePos = -Vector3.right * (2 * Screen.width);

mVisibility = 0;

mVisible = false;

this.transform.position = mInvisiblePos;

mCanvas = GetComponentInChildren <Canvas >();

mMenuOptions = FindObjectOfType <MenuOptions >();

}

void Update ()

{

mInvisiblePos = -Vector3.right * Screen.width * 2;

if (mVisible)

{

// Switch ON the UI Canvas.

if (! mCanvas.enabled)

mCanvas.enabled = true;

if (mVisibility < 1)

{

mVisibility += Time.deltaTime / SlidingTime;

mVisibility = Mathf.Clamp01(mVisibility);

this.transform.position = Vector3.Slerp(mInvisiblePos , mVisiblePos ,

mVisibility);

}

}

else

{

if (mVisibility > 0)

{

mVisibility -= Time.deltaTime / SlidingTime;

mVisibility = Mathf.Clamp01(mVisibility);

this.transform.position = Vector3.Slerp(mInvisiblePos , mVisiblePos ,

mVisibility);

// Switch OFF the UI Canvas when the transition is done.

if (mVisibility < 0.01f)

{

if (mCanvas.enabled)

mCanvas.enabled = false;

}

}

else

{

this.transform.position = mInvisiblePos;

}

}

}

public void Show()

{

mVisible = true;

if (mMenuOptions)

mMenuOptions.UpdateUI ();

}

public void Hide()

{

mVisible = false;

}

public bool IsVisible ()

{

Xaime Rivas Rey 83


return mVisibility > 0.05f;

}

}


Glosarioy Páginas web

E GLOSARIO Y PÁGINAS WEB Salud, sensores y realidad aumentada

Glosario

+ DWSL - Drexel Wireless System Laboratory+ AR - Augmented reality+ RA - Realidad Aumentada+ SDK - Software Development Kit+ RFID - Radio Frequency Identi�cation

Páginas web consultadas

Factores de emisión de CO2 - Ministerio de Energía y Turismo. Agosto de 2016.

Página de desarrollodores - Vuforia

Documentación Unity 3D.

Emisiones de CO2 en España 1992 - 2012

Xaime Rivas Rey 87

http://www.minetur.gob.es/energia/desarrollo/EficienciaEnergetica/RITE/propuestas/Documents/2014_03_03_Factores_de_emision_CO2_y_Factores_de_paso_Efinal_Eprimaria_V.pdf

https://developer.vuforia.com

http://docs.unity3d.com/ScriptReference/index.html

http://awsassets.wwf.es/downloads/informe_de_emisiones_de_gei_en_espana_1990_2012.pdf