Interfaz de control de una habitación domótica mediante la posición de los ojos

Texto completo

(1)´ UNIVERSIDAD POLITECNICA DE MADRID ´ ESCUELA TECNICA SUPERIOR DE INGENIERÍA Y ˜ INDUSTRIAL DISENO Grado en Ingenier´ıa Electrónica y Automática Industrial TRABAJO FIN DE GRADO. Interfaz de control de una ´ n domo ´ tica mediante la habitacio ´ n de los ojos posicio Daniel Gómez Vázquez Cotutor: Miguel Hernando Gutiérrez Departamento: Ingenier´ıa Eléctrica, Electrónica Automática y F´ısica Aplicada. Tutor: Alberto Brunete González Departamento: Ingenier´ıa Eléctrica, Electrónica Automática y F´ısica Aplicada. Madrid, Julio, 2017.

(2) ii.

(3) ´ UNIVERSIDAD POLITECNICA DE MADRID ´ ESCUELA TECNICA SUPERIOR DE INGENIERÍA Y ˜ INDUSTRIAL DISENO Grado en Ingenier´ıa Electrónica y Automática Industrial TRABAJO FIN DE GRADO. Interfaz de control de una ´ n domo ´ tica mediante la habitacio ´ n de los ojos posicio. Daniel Gómez Vázquez Miguel Hernando Gutiérrez Alberto Brunete Gonz´ alez.

(4) iv.

(5) v c Copyright 2017. Daniel G´ omez V´ azquez Esta obra est´ a licenciada bajo la licencia Creative Commons Atribución-NoComercial-SinDerivadas 3.0 Unported (CC BY-NC-ND 3.0). Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-nd/3.0/deed.es o env´ıe una carta a Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, EE.UU. Todas las opiniones aqu´ı expresadas son del autor, y no reflejan necesariamente las opiniones de la Universidad Politécnica de Madrid..

(6) vi.

(7) vii. TÌtulo: Robohealth Autor: Daniel Gómez Vázquez Tutor: Alberto Brunete González Cotutor: Miguel Hernando Gutiérrez. EL TRIBUNAL Presidente: Vocal: Secretario:. Realizado el acto de defensa y lectura del Trabajo Fin de Grado el d´ıa ....... de .................... de ... en .........., en la Escuela Técnica Superior de Ingenier´ıa y Dise˜ no Industrial de la Universidad Politécnica de Madrid, acuerda otorgarle la CALIFI´ de: CACION. VOCAL. SECRETARIO. PRESIDENTE.

(8) viii.

(9) Agradecimientos Agradezco a mi familia, en especial a mis padres y hermana, por el esfuerzo realizado durante todos estos a˜ nos y, particularmente, por el u ´ltimo a˜ no y medio y todo lo que hemos pasado desde entonces. También me gustar´ıa agradecer a los compa˜ neros de la universidad por todo el apoyo recibido y haber formado un buen grupo de amigos, aunque en ocasiones nos cueste vernos. Me gustar´ıa agradecer a Alberto y a Miguel por todo lo que me han ayudado durante el tiempo del proyecto, sacándome de más de un apuro en muchas ocasiones y siempre estando dispuestos a ayudarme. As´ımismo, me gustar´ıa también agradecer a las personas que han ayudado a llevar a cabo el proyecto, especialmente a Manu y a V´ıctor, partes indispensables del proyecto integrado. También me gustar´ıa agradecer a todas las personas voluntarias que han realizado las diversas pruebas realizadas durante el proyecto, ayudándonos a sacar todos los resultados obtenidos. Por u ´ltimo, mención especial a mi pareja, que siempre ha estado conmigo durante la ejecución del proyecto aguantando esos momentos en los que no entend´ıa ciertas cosas, y por ser la persona que más pruebas ha realizado sobre la aplicación, dándome siempre una opinión sincera para mejorar el desarrollo realizado.. ix.

(10) x. AGRADECIMIENTOS.

(11) Resumen Este proyecto tiene como objetivo la adaptación y desarrollo a realizar para que la habitación de un hospital donde se encuentre ingresado un paciente pueda ser controlada por éste. Para abarcar la gran diversidad de enfermedades que pueden existir en un entorno hospitalario, se ha adaptado la aplicación desarrollada para que pueda ser controlada empleando la voz, gestos u ojos del paciente. De esta manera, el paciente puede realizar las tareas básicas de una habitación como el encendido o apagado de diversas luces, subida o bajada de persianas o aviso a los servicios médicos en caso de emergencia, entre otros. Para realizar el control de manera satisfactoria, se ha adquirido un controlador de Vera capacitado para realizar la domótica de la habitación. Con respecto a la aplicación desarrollada, se ha realizado empleando un entorno de desarrollo multiplataforma llamado Qt Creator y se ha escrito en código C++. La aplicación final tendrá diversas ventanas por las que el paciente podrá navegar para poder realizar el control de los diversos aspectos de la habitación, como los sensores o actuadores disponibles. El desarrollo realizado en este proyecto se centra especialmente en la construcción de la aplicación destinada a realizar el control sobre la habitación y, adicionalmente, al control de ésta empleando los ojos del paciente. Para ello, se ha adquirido un Eye Tracker de la marca Tobii que realizará el seguimiento de los ojos del usuario, permitiendo que éste interact´ ue con la aplicación gui˜ nando cualquiera de sus ojos, manteniéndolos cerrados o simplemente mirando fijamente. Por u ´ltimo, se ha integrado el software realizado en este proyecto con la interacción empleando la voz (empleando un micrófono) y empleando gestos (con la ayuda de una Kinect), empleando el código realizado por otros estudiantes.. Palabras clave: Eye Tracker, Qt Creator, Surface, Kinect, IoT, Vera.. xi.

(12) xii. RESUMEN.

(13) Abstract This Project has, as objective, the necessary adaptation and development so that the hospital room, where a patient is hospitalized, can be controlled by himself. In order to cover the great variety of diseases which can exist in a hospital environment, the application has been adapted so that it can be controlled by patient voice, signs or eyes. On this manner, the patient can do the basic tasks of a room as turning on or off various lights, up or down blinds or notice to medical services, among others. To make the control on a correct manner a Vera controller, which can perform the home automation of the room, has been bought. Regarding to the application, it has been performed using a multiplatform development environment called Qt Creator and it has been written in C++. The final application will have different windows on which the patient could surf in order to make the control of various devices of the room, like actuators or sensors. The development done in this project is focused, specially, in the construction of the application destined to make the control over the room and, additionally, the control of this room using patient eyes. In order to make it, an Eye Tracker, which will make the tracking of the user’s eyes, has been bought, allowing that the patient can interact with the application by winking, keeping their eyes closed or looking at the screen fixedly. In the end, the software performed in this project has been integrated with the interaction using the voice mode (by a microphone) or doing different signs (by a Kinect), using the code made by other students.. Keywords: Eye Tracker, Qt Creator, Surface, Kinect, IoT, Vera Controller.. xiii.

(14) xiv. ABSTRACT.

(15) Índice general Agradecimientos. IX. Resumen. XI. Abstract. XIII. Índice. XVI. 1. Introducci´ on 1.1. Motivación del proyecto . 1.2. Objetivos . . . . . . . . . 1.3. Materiales utilizados . . . 1.4. Estructura del documento. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 1 1 2 3 3. 2. Estado del arte 2.1. Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1. Emotion Tool . . . . . . . . . . . . . . . . . . . . 2.1.2. Eye Tracker basado en FPGA . . . . . . . . . . . 2.1.3. Movimiento Brazo Robótico . . . . . . . . . . . . 2.1.4. Silla de ruedas inteligente basada en Eye Tracking 2.2. Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1. Neuromarketing . . . . . . . . . . . . . . . . . . . 2.2.2. Autismo . . . . . . . . . . . . . . . . . . . . . . . 2.2.3. Cirug´ıa . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 5 5 5 5 6 7 7 8 8 9. 3. Entorno de trabajo 3.1. Internet de las Cosas (IoT) 3.2. Habitación de Pruebas . . 3.3. Dispositivos . . . . . . . . 3.3.1. Vera . . . . . . . . 3.3.2. Kinect . . . . . . . 3.3.3. EyeTracker Tobii .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 11 11 12 14 14 15 16. . . . . .. 17 17 18 21 23 23. 4. Dise˜ no 4.1. Patron de Dise˜ no . . . . . 4.2. Modelo UML . . . . . . . 4.3. Interfaces . . . . . . . . . 4.3.1. Pantalla Conexión 4.3.2. Pantalla Principal .. . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. xv. . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . ..

(16) ÍNDICE GENERAL. xvi. 4.3.3. Pantalla Configuración 4.3.4. Pantalla Sensores . . . 4.3.5. Pantalla de Actuadores 4.3.6. Pantalla Multimedia . 4.3.7. Cuadro de Diálogo . . 4.4. Modos de Funcionamiento . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 24 26 26 27 27 28. 5. Implementaci´ on 5.1. Controlador de Vera . . . . . . . . . . . . 5.2. Entorno de Desarrollo . . . . . . . . . . . 5.3. Control del Eye Tracker . . . . . . . . . . 5.3.1. Linkado del programa al dispositivo 5.3.2. Widgets especiales . . . . . . . . . 5.3.3. Lectura del Eye Tracker . . . . . . 5.3.4. Click . . . . . . . . . . . . . . . . . 5.3.5. Cierre de Ojos . . . . . . . . . . . . 5.3.6. Interaccion con los usuarios . . . . 5.4. Integración con Voz . . . . . . . . . . . . . 5.5. Integración con Gestos . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. 31 31 32 34 34 35 36 38 38 39 39 39. 6. Resultados y discusi´ on 6.1. Resultados . . . . . . . . . . . . 6.1.1. Tiempos de pesta˜ neo . . 6.1.2. Manejo de la aplicación . 6.2. Discusión . . . . . . . . . . . . 6.2.1. Tiempos de Pesta˜ neo . . 6.2.2. Manejo de la Aplicación 6.2.3. Errores . . . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 41 41 41 42 48 48 49 50. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 7. Gesti´ on del proyecto 51 7.1. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 7.2. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 8. Conclusiones 53 8.1. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 8.2. Desarrollos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 A. Anexo A. 55. Bibliografia. 65.

(17) Índice de figuras 2.1. 2.2. 2.3. 2.4.. Eye Tracker basado en cámara web . . Eye Tracker basado en placa hardware Reconocimiento Ocular . . . . . . . . . Mapa de Calor de Movimiento Ocular .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 6 7 7 8. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6.. Conexiones IoT . . . . Habitación de pruebas Habitación de pruebas Controlador Vera . . . Kinect . . . . . . . . . Tobii EyeX . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 12 13 14 15 16 16. 4.1. Esquema de la aplicación desarrollada . . 4.2. Dise˜ no del patrón MV . . . . . . . . . . 4.3. Diagrama de Clases UML . . . . . . . . 4.4. Diagrama de Secuencias UML . . . . . . 4.5. Diagrama de Actividad UML . . . . . . 4.6. Modos de interaccionar con la aplicación 4.7. Pantalla de Conexión . . . . . . . . . . . 4.8. Pantalla Principal . . . . . . . . . . . . . 4.9. Pantalla de Configuración . . . . . . . . 4.10. Pantalla de Sensores . . . . . . . . . . . 4.11. Pantalla de Actuadores . . . . . . . . . . 4.12. Pantalla Multimedia . . . . . . . . . . . 4.13. Pantalla Imágenes . . . . . . . . . . . . . 4.14. Cuadro de Diálogo . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. . . . . . . . . . . . . . .. 17 18 19 20 21 22 24 25 26 26 27 28 28 29. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 5.1. Signals y Slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.2. Esquema Lógica Comprobación Click . . . . . . . . . . . . . . . . . . 37 6.1. 6.2. 6.3. 6.4.. Programa Cálculo Tiempos . . . . . . . . . . . . . . . . . . . . . . Contestaciones a la pregunta 1 - “Indique su sexo” . . . . . . . . . . Contestaciones a la pregunta 2 - “Indique el perfil empleado” . . . . Contestaciones a la pregunta 3 - “¿Toma medicación habitualmente que pueda afectar a su rendimiento cognitivo?” . . . . . . . . . . . 6.5. Contestaciones a la pregunta 4 - “¿Las instrucciones para la utilización de la aplicación han resultado claras y adecuadas?” . . . . . . 6.6. Contestaciones a la pregunta 5 - “¿Le resulta intuitivo la función de los distintos botones?” . . . . . . . . . . . . . . . . . . . . . . . . . xvii. . 41 . 44 . 44 . 44 . 45 . 45.

(18) ÍNDICE DE FIGURAS. xviii. 6.7. Contestaciones a la pregunta 6 - “¿Le ha resultado sencillo la interacción con los botones mediante el gui˜ no?” . . . . . . . . . . . . . . 6.8. Contestaciones a la pregunta 7 - “¿Le ha resultado sencillo la interacción con los botones mediante la fijación?” . . . . . . . . . . . . . 6.9. Contestaciones a la pregunta 8 - “¿Le ha resultado sencillo realizar el cambio entre ambos modos de funcionamiento?” . . . . . . . . . . . 6.10. Contestaciones a la pregunta 9 - “¿Cree que se entiende en qué estado se encuentra cada actuador?” . . . . . . . . . . . . . . . . . . . . . 6.11. Contestaciones a la pregunta 10 - “¿Le resulta sencilla la interacción con los usuarios disponibles?” . . . . . . . . . . . . . . . . . . . . . 6.12. Contestaciones a la pregunta 11 - “¿En qué grado cree que la aplicación será u ´til para pacientes de hospital?” . . . . . . . . . . . . . . 6.13. Contestaciones a la pregunta 12 - “¿Qué puntuación le dar´ıa a la aplicación tras su experiencia de usuario?” . . . . . . . . . . . . . .. . 45 . 46 . 46 . 46 . 47 . 47 . 47. 7.1. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 A.1. A.2. A.3. A.4. A.5. A.6. A.7. A.8. A.9.. UML Modelo . . . . . UML EyeX . . . . . . Base de Datos UML . Conexión UML . . . . Principal UML . . . . Sensores UML . . . . . Actuadores UML . . . Configuración UML . . Cuadro de Texto UML. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 56 57 58 59 60 61 61 62 63.

(19) Índice de tablas 6.1. Usuarios con gafas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.2. Usuarios sin gafas ni lentillas . . . . . . . . . . . . . . . . . . . . . . . 42 6.3. Respuestas de la encuesta . . . . . . . . . . . . . . . . . . . . . . . . 48 7.1. Presupuesto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51. xix.

(20) xx. ÍNDICE DE TABLAS.

(21) Cap´ıtulo 1. Introducci´ on En la aplicación desarrollada en este proyecto, el usuario realizará el control de una aplicación empleando sus ojos. Este desarrollo forma parte del proyecto Robohealth, que trata de un proyecto coordinado cuyo principal objetivo es el desarrollo de dispositivos de asistencia y rehabilitación a pacientes en general y, especialmente, a personas con necesidades especiales. Este u ´ltimo colectivo está formado por pacientes que padecen diferentes enfermedades como son movilidad reducida, capacidad cognitiva limitada y patolog´ıas crónicas, entre otros. Para poder desarrollar el proyecto Robohealth de manera satisfactoria, se ha dividido en cuatro subproyectos. Este informe se centra en uno de estos mencionados subproyectos, el correspondiente a entornos inteligentes para personas con necesidades especiales que convivan con robots. Particularmente, la tarea principal abordada en este proyecto ha sido el desarrollo de una interfaz multimodal para que el paciente pueda controlar diferentes aspectos de la habitación donde se encuentra hospitalizado. Esto le otorgará un grado de independencia que, de otra manera, tendr´ıan bastante dif´ıcil conseguir. Para conseguir manejar la habitación para la mayor parte de usuarios disponibles, se han habilitado varios modos de funcionamiento y, para ello, se emplean otros proyectos realizados por otros estudiantes.. 1.1.. Motivaci´ on del proyecto. La motivación de este proyecto es tratar de conseguir que personas con diferentes problemas, en concreto pacientes que se encuentran hospitalizados en ese momento, sean menos dependientes de gente externa, pudiendo ellos mismos realizar el control de la habitación donde se encuentran. Como puede tratarse de gente que se encuentre inmóvil, se pensó en desarrollar este control de la habitación empleando los ojos del usuario. Para ello se ha desarrollado esta aplicación con ayuda de un dispositivo para seguimiento de ojos. Adicionalmente y para tratar más posibles problemas de los pacientes, se han implantado diferentes modos de manejo de la aplicación. Por ejemplo, si un usuario se encuentra hospitalizado porque le hayan operado de la vista, este usuario podr´ıa controlar la habitación empleando su propia voz. Si, en lugar de eso, el usuario se encuentra hospitalizado pero s´ı puede realizar movimientos, este paciente tendrá la posibilidad de emplear el modo Gestos y, de esta manera, emplear el que más cómodo le resulte para su salud. 1.

(22) ´ CAPÍTULO 1. INTRODUCCION. 2. Con respecto al proyecto Robohealth concretamente (donde está enmarcado este sub-proyecto), el Plan Estatal de Investigación Cient´ıfica, Técnica y de Innovación 2013-2016 define como uno de los retos el de ”Salud, Cambio Demográfico y Bienestar”. Dentro de este reto, aparece un subreto cuya temática es “Rehabilitación y el desarrollo de entornos asistidos y orientados al abordaje de la cronicidad”. Además de esto, el proyecto también se encuadra entre los retos del futuro Programa Europeo de I+D Horizon2020. En este caso, se establecen la creación de robots asistenciales en entornos sanitarios y los robots de rehabilitación como l´ıneas principales de actuación. Por estas razones se decidió llevar a cabo el proyecto Robohealth, incluyendo además dentro del proyecto el desarrollo de entornos inteligentes. Dentro del proyecto se establecen diferentes tecnolog´ıas a estudiar que permitirán desarrollar soluciones robóticas para el colectivo de personas enfermas, discapacitadas y con enfermedades crónicas, colectivo destinatario del reto expuesto previamente.. 1.2.. Objetivos. Los objetivos de la aplicación desarrollada se pueden dividir en función de su importancia. Por un lado tenemos, como objetivos principales, el desarrollo de la aplicación que funcione de manera que el paciente pueda controlar la mayor parte de los aspectos posibles de la habitación empleando sus ojos. Además, se han habilitado dos modos diferentes de funcionamiento para que los pacientes que no sepan gui˜ nar los ojos puedan igualmente emplear esta aplicación explotando todo su potencial. Adicionalmente, algunos de los objetivos principales del proyecto es la integración de otros dos modos de funcionamiento diferentes para que la aplicación pueda ser controlada mediante la voz del usuario o empleando diferentes gestos. Estos dos u ´ltimos modos de funcionamiento tienen los diferentes comandos y gestos reconocidos guardados, no reconociendo el resto como funcionalidades del programa. Además, se plantea la implantación de un men´ u especial para la interacción con el dispositivo espec´ıfico del seguimiento de ojos. De esta manera, cuando a un paciente se le de el alta, la creación del nuevo usuario y la eliminación del anterior se pueda realizar desde la propia aplicación. Esto posibilitará que la aplicación no tenga que ser cerrada nunca, siendo la funcionalidad principal de la surface a la que va conectada. Por u ´ltimo, también se plantea un men´ u de favoritos para que el usuario pueda seleccionar diferentes dispositivos entre los disponibles de la habitación para que estos dispositivos puedan ser controlados desde la pantalla principal como un acceso directo. Por otra parte, como objetivos secundarios se ha pensado en incorporar diferentes aspectos de ocio para el usuario, como la visualización de imágenes o v´ıdeos y la inclusión de diferentes sonidos que puede reproducir el usuario. Otro de los objetivos destacables para el proyecto es la implantación de esta aplicación en una tableta que irá unida a un brazo robótico. Este brazo estará anclado a la cama y tendrá, como funcionalidad, la colocación de la tableta enfrente del usuario para poder realizar el control..

(23) 1.3. MATERIALES UTILIZADOS. 1.3.. 3. Materiales utilizados. El hardware empleado para este proyecto consta de: EyeTracker: Dispositivo empleado para evaluar la posición de los ojos del usuario o hacia dónde se encuentra mirando en un momento determinado. Vera: Controlador empleado para interconectar todos los dispositivos de la habitación con el programa creado. Sensores y actuadores de la habitación de pruebas. El software empleado ha sido el siguiente: Visual Studio: Plataforma en la que se empezó a desarrollar el software creado. QtCreator: Plataforma en la que finalmente se ha desarrollado el software que conecta los dispositivos con el controlador. Aqu´ı se encuentra toda la lógica de funcionamiento de nuestro programa. Tobii EyeTracking: Software proporcionado por el fabricante del EyeTracker empleado para conectar éste al ordenador. BitBucket: Software empleado para realizar un sistema de control de versiones del programa creado.. 1.4.. Estructura del documento. A continuación y para facilitar la lectura del documento, se detalla el contenido de cada cap´ıtulo. En el cap´ıtulo 1 se realiza una introducción al proyecto realizado, donde se especifican los objetivos principales del proyecto. En el cap´ıtulo 2 se hace un repaso del estado actual de la tecnolog´ıa empleada en este proyecto. En este caso, se realiza un breve repaso de los dispositivos parecidos al Eye Tracker empleado y de las aplicaciones encontradas donde se emplean. En el cap´ıtulo 3 se describe detalladamente el entorno de trabajo donde se ha desarrollado el proyecto. Este se refiere al internet de las cosas y a los dispositivos f´ısicos empleados (as´ı como la habitación de pruebas construida). En el cap´ıtulo 4 se muestra el dise˜ no que se ha llevado a cabo en el desarrollo software. Para ello, se ense˜ nan las interfaces y modelo UML empleado, as´ı como el patrón de dise˜ no empleado finalmente. En el cap´ıtulo 5 se desarrolla la lógica empleada para la conexión y control del dispositivo con la aplicación desarrollada. Además, también se crean dos apartados espec´ıficos para la integración de la aplicación con los otros modos de funcionamiento. En el cap´ıtulo 6 se muestran los resultados obtenidos tras las pruebas realizadas, as´ı como las conclusiones obtenidas de esos resultados..

(24) 4. ´ CAPÍTULO 1. INTRODUCCION. En el cap´ıtulo 7 se muestra un diagrama de Gantt donde se especifica cómo han sido las etapas llevadas a cabo hasta completar la aplicación final. En el cap´ıtulo 8 se muestran las conclusiones obtenidas y algunos desarrollos futuros que se podr´ıan llevar a cabo tras la realización de este proyecto..

(25) Cap´ıtulo 2. Estado del arte En este cap´ıtulo se va a dar una visión de las diferentes aplicaciones que tiene actualmente el Eye Tracking, as´ı como de los diferentes dispositivos que se han creado para ello. Exiten plataformas de sotware libre, como Gaze Speaker1 que permiten instalarse de manera gratis en el ordenador del usuario. En concreto, esta plataforma es compatible con el Eye Tracker empleado en este proyecto. Provee al usuario de diferentes pantallas para responder a preguntas o un teclado para poder comunicarse mediante el empleo de los ojos, entre otras cosas.. 2.1.. Dispositivos. A continuación se van a mostrar algunos dispositivos similares al Eye Tracker empleado o diversos estudios en los que se ha desarrollado un Eye Tracker. 2.1.1.. Emotion Tool. Por otra parte, existen otras técnicas de investigación que incluso utilizan datos de parpadeo, velocidad de movimiento y dilatación de la pupila. Este es el caso de la tecnolog´ıa Emotion Tool de iMotions. Este software puede medir la respuesta emocional del ser humano ante un est´ımulo visual mediante el análisis de la expresión facial y movimiento ocular. Por ejemplo, la dilatación de la pupila se ha relacionado con la activación del sistema nervioso simpático. Sin embargo, estos algoritmos resultan complejos debido a las causas externas que provocan variaciones en los ojos. Por ejemplo, el tama˜ no de la pupila también está relacionado con la carga del procesamiento cognitivo y la cantidad de luz del est´ımulo visual o la cantidad de parpadeos con si el usuario recibe un susto o necesita una reacción defensiva. As´ı, estas técnicas son muy valiosas para psicólogos e investigadores de la emoción a la hora de evaluar el comportamiento humano, la memoria o la toma de decisiones. 2.1.2.. Eye Tracker basado en FPGA. También se han realizado diversos estudios donde se desarrollan técnicas de Eye Tracking a partir de una placa FPGA y diversos algoritmos de control ([11]). En este 1 http://www.gazespeaker.org/. 5.

(26) CAPÍTULO 2. ESTADO DEL ARTE. 6. estudio se desarrollaron estas técnicas empleando una placa FPGA que implementa el algoritmo del centro de gravedad donde la placa FPGA capta la posición del ojo a 500 fotogramas por segundo gracias a un sensor de imagen de alta velocidad. El proceso realizado en este estudio consta de 3 partes bien diferenciadas: 1. Realización de la imagen de binarización, donde la imagen de cada pixel se compara con el valor umbral y, en caso de que sea mayor que éste, la salida es 1, en caso contrario, la salida es 0. De esta manera se forma la imagen en blanco y negro correspondiente. 2. Realización de corrosión y expansión, donde se rellena el área alrededor de la pupila de color blanco para luego poder ser tratado adecuadamente por la FPGA. 3. Implementación de la operación de proyección, donde se realiza el acceso a memoria, la suma de acumulación y la lógica de valores obtenidos de las operaciones previas. 2.1.3.. Movimiento Brazo Rob´ otico. Entre todos los estudios realizados, encontraamos algunos que fabrican dos métodos de Eye Tracking basados en el movimiento de un brazo robótico ([10]). 2.1.3.1.. Eye Tracker basado en c´ amara web. En el primer método realizado colocaron una cámara en un ordenador para, de esta manera, captar el movimiento ocular y tratarlo adecuadamente (ver figura 2.1). Esta solución es similar a la adoptada en este proyecto, con la diferencia de que en este caso se ha empleado un Eye Tracker comercializado y estático. Se dice lo de estático puesto que en el proyecto indicado la cámara web puede desplazarse a lo largo de una barra lateral sobre la que se encuentra instalado para realizar las labores de seguimiento.. Figura 2.1: Eye Tracker basado en cámara web. 2.1.3.2.. Eye Tracker basado en placa hardware. Para el segundo método, los autores desarrollaron una placa hardware con un soporte que se coloca delante del ojo del usuario (ver figura 2.2). De esta manera, esta placa puede captar los movimientos oculares para tratarlos en función de los movimientos de éstos..

(27) 2.2. APLICACIONES. 7. Figura 2.2: Eye Tracker basado en placa hardware. En este estudio ([10]) se concluyó que la velocidad de la segunda versión era más rápida (pero también más costosa) debido a las distancias focales y el n´ umero de fuentes. Una desventaja importante de la primera opción es que sólo pudo ser llevada a cabo en interiores debido a que la luz solar interfiere en la cámara, introduciendo as´ı ruido en el sistema. 2.1.4.. Silla de ruedas inteligente basada en Eye Tracking. También se han realizado estudios en los que las técnicas de eye tracking se realizan mediante una Raspberry Pi y openCV ([8]). Para ello, se instala una cámara en unas gafas que tendrá que llevar el usuario y que irá colocada mirando directamente hacia el ojo de éste. De esta manera, la raspberry graba continuamente su ojo y, mediante openCV se reconoce el ojo del usuario as´ı como sus movimientos (ver figura 2.3). Una vez se analizan, la Raspberry Pi es la encargado de enviar, a través de un módulo destinado para ello, las instrucciones necesarias para que la silla de ruedas realice los movimientos adecuados. Este método se trata de un método más barato que el resto de los estudiados puesto que el u ńico gasto que conlleva es la placa Raspberry Pi empleada, junto con la cámara, puesto que openCV se trata de una librer´ıa de código abierto, es decir, gratuita.. Figura 2.3: Reconocimiento Ocular. 2.2.. Aplicaciones. A continuación se van a exponer diversas aplicaciones en las que se emplea la tecnolog´ıa Eye Tracking. Las aplicaciones desarrolladas se centran en dos campos principalmente, marketing y salud..

(28) CAPÍTULO 2. ESTADO DEL ARTE. 8. 2.2.1.. Neuromarketing. Actualmente, la tecnolog´ıa Eye Tracking se usa, principalmente, en neuromarketing 2 . En este a´mbito se usa como medición biométrica que ayuda a comprender el inconsciente de los sujetos de estudio. La información que recogen estos sistemas sirven a los investigadores para conocer los recorridos visuales de los usuarios y, a su vez, crear mapas de calor (Figura 2.4) que se˜ nalen los lugares a los que el usuario mira durante más tiempo. La imagen se ha obtenido de una noticia disponible en la web3 .. Figura 2.4: Mapa de Calor de Movimiento Ocular. De esta manera, se puede realizar un análisis de folletos, impresos o páginas web estáticas estudiando cuál es la facilidad de los diferentes usuarios en encontrar unos elementos u otros dentro de ellos. 2.2.2.. Autismo. Se han realizado también estudios recientes con esta tecnolog´ıa en pacientes que padecen Trastorno de Espectro Autista (TEA) [1]. Este estudio discute el potencial que pueden tener estas técnicas a la hora de revelar una visión de las dificultades sociales que experimentarán estos pacientes. Esto se puede realizar bajo la premisa de que cuando una persona mira directamente a un objeto (fijación), esta imagen cae sobre la fóvea 4 . Por esta razón, los ojos necesitan moverse para saber cómo es el campo visual detalladamente. De esta manera, se pueden realizar recogidas de datos y combinarlos con diferentes test de conducta cognitiva o reconocimiento de emociones. Uno de los primeros estudios realizados en TEA ([5]) con eye tracking monitorizaba los movimientos del ojo de diferentes adultos con autismo mientras realizaban un test de reconocimiento de emociones con fotograf´ıas. Se concluyó que las personas con autismo pasan menos tiempo examinando las diferentes partes de la cara. De esta manera, si se analizan las fijaciones que una persona con TEA realiza sobre una 2 http://neuromarca.com/neuromarketing/eye-tracking/ 3 https://www.branded3.com/blog/seo-and-eye-tracking/ 4´ area de la retina donde se enfocan los rayos luminosos y se encuentra especialmente capacitada para la visi´ on del color.

(29) 2.2. APLICACIONES. 9. fotograf´ıa de una persona humana, se verá que el tiempo de las fijaciones es menor que en personas que no padecen este s´ındrome. 2.2.3.. Cirug´ıa. Actualmente existen diversos robots empleados como robots para operaciones de cirug´ıa y, también robots auxiliares que puedan ayudar a estos robots principales. Sin embargo, se está intentando ir un paso más alla y se están realizando estudios para poder controlar estos robots mediante los ojos del médico ([9]) mediante la realización de una aplicación con tecnolog´ıa Eye Tracking. En el caso del citado art´ıculo, se emplean unas gafas con esta tecnolog´ıa en lugar de la barra fijada a la pantalla empleada en el proyecto Robohealth. Sin embargo, estas técnicas tienen el problema del ruido ya que, por condiciones externas, los resultados no son tan precisos como para ser empleados en técnicas de cirug´ıa, donde la precisión es muy importante..

(30) 10. CAPÍTULO 2. ESTADO DEL ARTE.

(31) Cap´ıtulo 3. Entorno de trabajo A continuación se va a explicar el entorno necesario para llevar a cabo este proyecto. Aunque el principal componente es el EyeTracking debido a que la principal actividad de desarrollo de este proyecto ha sido la programación sobre éste, han sido necesarios muchos otros dispositivos. Para ello se ha llevado a cabo el montaje de una habitación de pruebas para poder realizar diversos test de los elementos a controlar. En esta habitación de pruebas se han colocado diversos sensores y actuadores que interaccionarán con el usuario. Para realizar esta conexión entre sensores y actuadores de manera inalámbrica, se ha empleado el controlador de Vera que act´ ua como servidor. Sobre este servidor actuará la aplicación desarrollada, tanto para modificar como para leer el estado de los dispositivos instalados. Por u ´ltimo y, como parte más importante, para que esta aplicación pueda ser controlada mediante la vista del usuario se ha comprado y acoplado una barra Eye Tracker, fija en la pantalla del ordenador, de la marca Tobii.. 3.1.. Internet de las Cosas (IoT). El internet de las cosas ([3]) consiste en la formación de una red con diferentes dispositivos, no sólo ordenadores o móviles, sino todo tipo de artilugios. Una vez conectados, éstos se pueden comunicar con otros dispositivos de la misma red para realizar los propósitos deseados (ver esquema de la figura 3.1, obtenida de un enlace web1 ). Para poder implantar esta idea en el proyecto de manera adecuada, se tuvieron que sustituir algunos dispositivos habituales por otros que poseen internamente la conexión con el servidor de manera inalámbrica. Para realizar estas conexiones, los dispositivos implantados poseen, de manera interna, un módulo de conexión que les conecta con el controlador de Vera (se explicará su funcionamiento en 3.3.1). Sin embargo, estas conexiones, aunque siempre se realizan con la misma filosof´ıa, no siempre se hacen de la misma manera (se diferencian unas de otras en el dispositivo que posee el módulo de conexión). Para las bombillas que posee la habitación, por ejemplo, existen 3 maneras de conectarlas con nuestro servidor. Todas ellas poseen un módulo que permite que sean conectadas con el controlador, diferenciándose u ńicamente en el lugar donde 1 https://www.neratec.com/tl_files/article/products-development/Internet-of-Things/IoT-Overview.. png. 11.

(32) CAPÍTULO 3. ENTORNO DE TRABAJO. 12. Figura 3.1: Conexiones IoT. tengan ubicado este módulo. As´ı, en esta habitación de pruebas encontramos que esos módulos de conexión se pueden encontrar en el casquillo de la bombilla, en el interruptor o en un dispositivo colocado previo a la bombilla para regular la iluminación de ésta. Las conexiones integradas en el proyecto se podr´ıan catalogar de dos maneras diferentes. Por un lado, si lo que tenemos es un actuador, el controlador se conecta directamente con el módulo de conexión y éste realiza la acción adecuada (cambiar de posición en caso de un interruptor, por ejemplo) para que pase lo que el usario pide a través del controlador. En caso contrario, si el usario realiza una acción sobre la habitación directamente (pulsar el interruptor, por ejemplo), este módulo es el encargado de enviar la información al controlador de Vera para que haga los cambios oportunos en los datos que posee internamente. Por esta razón la conexión entre ellos es bidireccional. Sin embargo, entre el dispositivo que posee el módulo de conexión y el actuador no es necesaria la conexión bidireccional, puesto que el actuador funcionará dependiendo de lo que le diga el módulo, y nunca ocurrirá al contrario. En caso de sensores, sin embargo, la conexión es directa entre éstos y el controlador puesto que son los propios sensores los que poseen el módulo de conexión. De esta manera, si los sensores se activan, env´ıan la información al servidor mientras que, por otra parte, el servidor permite que ellos dispongan de infrmación sobre si están habilitados o no (en caso de que el usario no quiera), por lo que la conexión tiene que ser bidireccional.. 3.2.. Habitaci´ on de Pruebas. Para la realización de las pruebas necesarias para comprobar el funcionamiento de la aplicación se ha llevado a cabo la construcción de una habitación de pruebas (como se puede ver en la figura 3.2). Dentro de esta habitación de pruebas se colocará el controlador de Vera empleado para el desarrollo de la aplicación y, para la construcción de la habitación se colocaron diversas paredes y una puerta con una cerradura electrónica. Para finalizar con la habitación de hospital, se ha comprado y colocado una cama regulable y se ha instalado al lado de ella un brazo robótico.

(33) ´ DE PRUEBAS 3.2. HABITACION. 13. que será el encargado de colocar la tableta enfrente del paciente para su uso (como se puede ver en la figura 3.3).. Figura 3.2: Habitación de pruebas. Además, se retiraron los interruptores convencionales por unos interruptores especiales (estos interruptores poseen un módulo interno que estará conectado al controlador empleado). Estos módulos de conexión poseen diferentes entradas que hubo que conectar a la red eléctrica y a la bombilla empleada de manera directa. Adicionalmente, se conectaron dos bombillas más con diferentes módulos de conexión. Una de ellas tiene el módulo de conexión directamente en el portalámparas, de tal manera que se conecta como cualquier bombilla convencional. Por u ´ltimo, hay otra bombilla que tendrá conectado el módulo entre la bombilla y la red. De esta manera este disposiitivo puede regular la intensidad de la luz de la bombilla empleada en función de lo que las instrucciones que le mande el controlador. Para terminar con los actuadores instalados hasta el momento, también se instaló una sirena que, en función de la intensidad que se le indique a través del controlador, se activará empleando luz sólamente o luz y sonido. Sin embargo, por funcionalidad, en la habitación de pruebas se ha desarrollado para que la sirena sólamente emplee luz cuando se active desde la aplicación, siendo muy sencillo poder implantar también el sonido si se desea..

(34) CAPÍTULO 3. ENTORNO DE TRABAJO. 14. Figura 3.3: Habitación de pruebas. Adicionalmente, se instalaron diferentes sensores (todos ellos son inalámbricos) que poseen el módulo de conexión dentro del propio sensor. De esta manera, cuando cualquiera de los sensores se activa, éste informa al controlador del evento que ha ocurrido. De esta manera, la aplicación leerá cualquier cambio que haya en el controlador y, de esta manera, estos cambios en los sensores podrán ser tratados de manera adecuada. Todas las conexiones empleadas en la habitación de pruebas estarán explicadas en 3.1. Además, se pueden a˜ nadir diversos dispositivos de ambos tipos sin dificultad gracias a la interfaz de VeraLite.. 3.3.. Dispositivos. A continuación se van a explicar los dispositivos empleados para llevar a cabo este proyecto. Estos dispositivos son empleados para realizar el control sobre la habitación y los necesarios para los diferentes modos de uso desarrollados en la aplicación. 3.3.1.. Vera. Vera es la plataforma empleada para desarrollar toda la estructura del IoT. En el caso de este proyecto, se ha empleado un controlador de Vera llamado VeraLite. Se trata de un controlador ([7]) que emplea el protocolo de comunicación Z-Wave 2 . Un controlador con este protocolo necesita que los dispositivos a los que está conectado utilicen el mismo modo de comunicación. Se puede ver cómo es el controlador en la figura 3.4. 2 http://www.z-wave.com/.

(35) 3.3. DISPOSITIVOS. 15. Figura 3.4: Controlador Vera. Z-Wave es la tecnolog´ıa l´ıder en el mercado de automatización de hogares de manera inalámbrica. Se trata de una alianza que formaron diferentes empresas y con la que colaboran otras muchas actualmente. Z-Wave es tan destacada porque es una tecnolog´ıa usada para integrar sensores y actuadores a una radio frecuencia determinada. De esta manera, esta frecuencia no es interferida por otras como las conexiones Wifi. Esta tecnolog´ıa se utiliza, principalmente, para servicios de automatización y hogares inteligentes. Este controlador VeraLite se puede manejar mediante una red local o internet debido a que las peticiones se pueden enviar mediante protocolo UPnP o peticiones HTTP. UPnP [6] es una tecnolog´ıa (con el soporte del protocolo TCP/IP) y que tiene como objetivo permitir a los dispositivos conectarse entre s´ı, integrando dispositivos de diferentes fabricantes. Cuando se a˜ nade un nuevo dispositivo a la red, se obtiene automáticamente su dirección IP, pudiendo ser manejado por un controlador de propia red. HTTP (Hypertext Transfer Protocol) [2] es el tipo de tráfico más usado en Internet. Principalmente consiste en peticiones y respuestas HTTP. Normalmente, los buscadores web env´ıan peticiones HTTP a puertos que ciertos servidores están escuchando y, una vez lo reciben, éstos env´ıan una respuesta al cliente. En el caso de este proyecto, el método empleado para la comunicación entre VeraLite y los actuadores es el protocolo HTTP. 3.3.2.. Kinect. Uno de los dispositivos empleados para controlar la habitación ha sido una kinect (controlador desarrollado por Microsoft). Para poder emplear este dispositivo, será necesario un ordenador con sistema operativo Windows 8 o superior y, además, un puerto USB 3.0. Aunque hay distintas variedades, el dispositivo adquirido posee una sóla cámara colocada en uno de los lados de la parte frontal de éste, como se puede apreciar en la figura 3.5. La imagen se ha obtenido a partir de un enlace web3 . 3 https://images-na.ssl-images-amazon.com/images/I/41xEXTsbrDL._SX355_.jpg.

(36) CAPÍTULO 3. ENTORNO DE TRABAJO. 16. Figura 3.5: Kinect. Figura 3.6: Tobii EyeX. 3.3.3.. EyeTracker Tobii. Por u ´ltimo, el dispositivo hardware alrededor del que gira la parte principal del proyecto es el EyeTracker. El EyeTracker obtenido ha sido una barra fija de la marca Tobii conocida como Tobii EyeX (se muestra el dispositivo en la figura 3.6. Como se puede ver en la figura, este dispositivo posee cámaras de alta velocidad (3 concretamente) y va fijado a la pantalla del ordenador. Para que el dispositivo funcione correctamente, es necesario que el PC tenga, al menos, un procesador i5 y una capacidad RAM de 6GB de memoria, además de un puerto USB 3.0. Este dispositivo recoge automáticamente el tama˜ no de la pantalla para poder calcular el punto donde mira el usuario. Las coordenadas donde se encuentre mirando el usuario se referencian con respecto a la esquina superior izquierda de la pantalla, de tal manera que el eje positivo en X es horizontal hacia la derecha y el eye Y es vertical y hacia abajo. Para leer estas coordenadas, Tobii EyeX recoge los datos de manera normalizada y los convierte en los p´ıxeles adecuados donde está mirando. Por u ´ltimo, también cabe destacar que el Tobii EyeX es capaz de calcular dónde se encuentra mirando el usuario pero, también, cuál es la posición de los ojos del usuario con respecto al centro de la pantalla del ordenador. Gracias a esta u ´ltima utilidad es como se puede calcular cuándo el usuario ha gui˜ nado un ojo ya que, cuando alg´ un ojo se encuentra cerrado, el EyeTracker recoge que los ojos se encuentran en la posición 0.0 en todas las coordenadas respecto del centro de la pantalla..

(37) Cap´ıtulo 4. Dise˜ no Para la aplicación final, se ha desarrollado un programa cuya lógica se puede entender viendo el diagrama de la figura 4.1. Como se expresa en este diagrama, los actuadores y sensores están directamente conectados con el controlador de Vera de manera bidireccional, ya que tanto sensores como actuadores necesitan modificar ´ datos del controlador como a la viceversa. Estos se conectan a la Surface adquirida mediante internet y la Surface es la encargada del desarrollo de la aplicación y de la programación necesaria para los diferentes modos de funcionamiento.. Figura 4.1: Esquema de la aplicación desarrollada. Para el desarrollo software se ha empleado un patrón MV (Model-View), donde se han creado diferentes ventanas para formar la interfaz del usuario para que éste pueda controlar la habitación de diversas maneras.. 4.1.. Patron de Dise˜ no. El patrón de dise˜ no empleado para este proyecto ha sido un patrón MVC (ModelView-Controller). Esta arquitectura [4] considera los 3 componentes y sus interacciones como una unidad básica, tratando las aplicaciones multipágina como aplicaciones de una sóla página. En este patrón, la vista se le presenta al usuario y, cuando éste 17.

(38) ˜ CAPÍTULO 4. DISENO. 18. Figura 4.2: Dise˜ no del patrón MV. interacciona con ella, se informa directamente al controlador, que modifica el modelo de manera adecuada en función de lo que haya recibido. Después, el modelo informa al controlador de que han realizado los cambios y éste decide cómo se tiene que modificar la vista para el usuario. Sin embargo, al emplear Qt Creator, en lugar de este patrón se ha empleado un patrón MV (Model-View) debido a las utilidades de QtCreator. Esto es as´ı porque no es necesario tener un controlador que lea las interacciones del usuario ya que, mediante las clases propias provistas por Qt Creator, éste paso se hace automáticamente mediante Signals y Slots (explicado en 5.2). De esta manera, la vista y el controlador están unidos y cuando se crea la vista, se definen las conexiones que tienen los diferentes widgets con el modelo. Cuando un usuario hace click en un botón, por ejemplo, y se ha definido a qué slot está unido la función predefinida para la acción de click sobre un botón, se realiza la función que está dentro de ese slot (normalmente en el modelo). Entonces, el modelo realiza las acciones pertinentes y es él mismo el que modifica la vista que tiene el usuario. Por tanto, la lógica que se sigue con este patrón de dise˜ no es que cuando un usuario realiza una acción sobre un botón, la propia vista le informa al modelo de lo que ha pasado, siendo éste el que tiene que decidir qué es lo siguiente a hacer y, en caso de que sea necesario modificar la vista, mostrar la pantalla correspondiente (se muestra un peque˜ no esquema de funcionamiento en la figura 4.2).. 4.2.. Modelo UML. La aplicación realizada finalmente tiene diferentes pantallas para poder organizar mejor todas las funcionalidades de la habitación. Además, se han implantado diferentes botones para efectuar las acciones necesarias sobre cada actuador. Finalmente, y empleando el patrón MV (explicado en el apartado 4.1), el diagrama de clases realizado es el mostrado en la figura 4.3. Las clases Como se puede ver en el digrama UML expresado anteriormente, se ha creado una clase llamada “BBDD” para que act´ ue como una base de datos. A esta clase sólo puede acceder el modelo y en ella se guardan diversos aspectos de la aplicación. Todos los datos fijados (como los tiempos, usuarios, favoritos, etc...) se guardan y actualizan.

(39) 4.2. MODELO UML. 19. Figura 4.3: Diagrama de Clases UML. mediante esta clase para luego poderlos usar en el modelo. De esta manera, cuando el modelo quiera realizar una operación concreta, en muchas ocasiones tendrá primero que consultar en qué estado se encuentran diversas variables de la base de datos. Por ejemplo, si el usuario cierra los ojos durante más del tiempo especificado para el cierre, el modelo tendrá que consultar la base de datos para comprobar que se encuentra activo el modo “Ojos” antes de realizar el cambio de modo. Por otra parte, el modelo también tiene conexión directa con el controlador del Vera, con el controlador de la kinect y con el controlador del Eye Tracker adquirido. De esta manera, tanto el modelo puede avisar a éstos de cuándo tienen que empezar a recoger los datos como se puede hacer la conexión al revés, de tal manera que los dispositivos informen al modelo de diversos cambios que se puedan producir, como un cambio en los dispositivos de la habitación o la lectura de ojos y gestos. Finalmente, el modelo tiene conexión con todas las pantallas creadas. Todas estas pantallas descienden de QWidget y su u ńica función será la de mostrar al usuario la pantalla deseada y recoger cuándo un usuario interacciona con ellas mediante los botones o deslizantes, entre otras cosas. Se mostrarán todos los diagramas UML de las clases desarrolladas en A. Adicionalmente, se ha llevado a cabo la realización de un diagrama UML de secuencias que muestra una consecución de mensajes determinada entre los distintos actores de la aplicación desarrollada. En este diagrama (ver figura 4.4) se muestra la secuencia producida desde que un usuario enciende la aplicación, representando además el bucle que se realiza continuamente para estudiar tanto la posición de los ojos como el click o el cierre de ojos..

(40) ˜ CAPÍTULO 4. DISENO. 20. Figura 4.4: Diagrama de Secuencias UML. Por u ´ltimo, también se ha realizado un diagrama UML de actividades que muestra el flujo de trabajo de un software determinado. De esta manera, resulta sencillo comprender cómo funciona el software y quién realiza cada acción determinada. En el diagrama de la figura 4.5 se muestra el flujo correspondiente desde que un usuario inicia la aplicación hasta que cambia de modo de funcionamiento, realizando interacciones sobre el controlador de Vera..

(41) 4.3. INTERFACES. 21. Figura 4.5: Diagrama de Actividad UML. 4.3.. Interfaces. Debido a la posibilidad de la gran cantidad de dispositivos que pueda tener el entorno hospitalario, se ha pensado en desarrollar esta aplicación para que sea multipantalla. De esta manera, los usuarios tendr´ıan una pantalla principal y desde ella podr´ıan acceder a una ventana diferente correspondiente a sensores o a actuadores, por ejemplo, seg´ un deseen. Para la realización de esta aplicación y de las diferentes vistas se han empleado diversas clases que heredan de QWidget 1 (clase base de todos los objetos de la interfaz de usuario). Esta clase está dise˜ nada para recibir interacciones con el ratón o teclado, entre otros y representar diferentes objetos en la pantalla. Para representar estas interfaces de usuario, QtCreator provee una clase llamada QGraphicsView que muestra en pantalla un QWidget concreto. Además, QtCreator permite al programador emplear dos métodos para realizar el dise˜ no de la aplicación. Este dise˜ no se puede realizar de manera visual (colocando directamente los botones, 1 http://doc.qt.io/qt-4.8/qwidget.html.

(42) ˜ CAPÍTULO 4. DISENO. 22. Figura 4.6: Modos de interaccionar con la aplicación. cuadros de texto, etc... sobre la pantalla) o mediante lenguaje de programación. El método empleado en este proyecto ha sido el u ´ltimo, en el que el programador tiene que crear todos los componentes que van a colocarse en la pantalla, además de colocarlos en ésta mediante código escrito. Para ello, QtCreator proporciona clases para organizar los widgets de manera vertical, horizontal o tipo red, entre otros. Estas clases permiten organizarlos de tal manera que los widgets se espacien de manera automática, ocupando todos los mismo. Además, estos layouts pueden colocarse dentro de un objeto o dentro de otro layout, haciendo que las posibilidades del programador sean muy grandes. Por ello, para realizar los layouts de manera adecuada, se han empleado las clases proporcionadas por QtCreator. Las clases usadas para ello han sido QGridLayout (que te coloca los widgets como en una red, donde el programador tiene que especificar la fila y la columna de comienzo, además del ancho y alto que quiera que ocupen dentro del layout), QVBoxLayout (que te coloca los widgets de manera vertical) y QHBoxLayout (que te los coloca de manera horizontal). Un ejemplo de esta manera de realizar el dise˜ no de la aplicación se ve muy bien en la figura 4.6, donde se muestra un layout vertical que contine una etiqueta y 2 layouts horizontales, dentro de los cuales hay, en cada uno, un botón, un deslizador y una etiqueta. Para realizarlo de manera adecuada, es necesario crear un objeto de un layout vertical y otros dos de un layout horizontal y, cuando se tengan todos los widgets necesarios a˜ nadidos en cada uno de los layouts horizontales (mediante el método addWidget), a˜ nadir éstos al layout vertical mediante el método llamado addLayout. Para que el layout final pueda ser representado es necesario llamar al método del objeto de la clase QGraphicsView llamado setLayout y, posteriormente mostrarlo mediante el método show o showMaximized para que se pueda mostrar. Cuando queramos cambiar de pantalla, será imprescindible esconder la que tenemos mediante el método hide del objeto de QGraphicsView. Para entenderlo mejor, se muestra a continuación cómo se hace esto para la clase conexión, con un sólo tipo de layout (pantalla inicial). C´ odigo 4.1: Dise˜ no de la conexión (conexion.h) 1 2 3 4 5 6. c l a s s Conexion p u b l i c QWidget { ... private : QGraphicsView ∗ v i s t a ; QGridLayout ∗ l a y o u t ;. 7. QLineEdit ∗ i p ; QPushButton ∗ c o n e c t a r ;. 8 9 10 11. public : void show ( ) ; void h i d e ( ) ;. 12 13 14. }.

(43) 4.3. INTERFACES. 23 C´ odigo 4.2: Dise˜ no de la conexión (conexion.cpp). 1 2 3 4. Conexion : : Conexion ( ) { l a y o u t = new QGridLayout ( ) ; v i s t a = new QGraphicsView ( ) ;. 5. i p = new QLineEdit ( ) ; c o n e c t a r = new QPushButton ( ) ;. 6 7 8. l a y o u t −>addWidget ( i p ) ; l a y o u t −>addWidget ( c o n e c t a r ) ;. 9 10 11. v i s t a −>s e t L a y o u t ( l a y o u t ) ;. 12 13. }. 14 15 16 17 18. void Conexion : : show ( ) { v i s t a −>show ( ) ; }. 19 20 21 22 23. void Conexion : : h i d e ( ) { v i s t a −>h i d e ( ) ; }. Siguiendo esta lógica, se pueden crear vistas con gran variedad y libertad por parte del programador, ya que se podr´ıan crear más layouts y luego hacer que todos sean contenidos por el mismo. Sin embargo, utilizando esta manera, para hacer peque˜ nas modificaciones respecto a tama˜ nos o modificaciones de los diferentes widgets dentro de un layout, es bastante más dif´ıcil para el programador que empleando el método visual. De esta manera, se han creado diversas clases que sólo se emplean para realizar la representación visual. Estas clases contienen diferentes botones propios, listas, etc... Pero, además, en cualquier momento de la programación se pueden a˜ nadir más widgets simplemente recurriendo al método de las l´ıneas 9 y 10 del código 4.2 y la vista se actualizará automáticamente, sin necesidad de hacer más modificaciones. As´ı, la aplicación que se ha creado posee diferentes ventanas para que el usuario pueda navegar por la aplicación, pudiendo realizar las tareas adecuadas en cada momento. Estas ventanas creadas serán explicadas a continuación. 4.3.1.. Pantalla Conexi´ on. Se ha creado una ventana Conexi´ on que se puede ver en la figura 4.7 (mostrada cuando se inicia la aplicación). Esta ventana u ńicamente contiene un cuadro de texto editable con la dirección IP del controlador de Vera (se ha realizado editable porque, de esa manera, se podr´ıa tener más de un controlador, eligiendo el usuario a cuál se quiere conectar) y un botón conectar que, cuando se pulse, comprobará si la dirección IP es válida. En caso de que sea válida, se realiza la conexión entre el modelo y el controlador de Vera y, además, el programa leerá los datos contenidos en el controlador (dispositivos disponibles y estado actual). En ese caso, esta pantalla se cerrará, no volviéndose a mostrar durante todo el programa y dando paso a la pantalla principal. 4.3.2.. Pantalla Principal. La pantalla Principal es la mostrada cuando se realiza correctamente la conexión entre la aplicación y el controlador (se muestra en la figura 4.8). Como se puede ver.

(44) ˜ CAPÍTULO 4. DISENO. 24. Figura 4.7: Pantalla de Conexión. en la imagen, tiene diferentes sub-apartados a tener en cuenta por el usuario. Por una parte, en la parte izquierda de la pantalla principal, se encuentran todos los botones correspondientes a las diferentes pantallas a las que se puede acceder (que serán explicadas más adelante). En la parte de la derecha de la pantalla se muestran los diferentes sensores/actuadores que seleccione el usuario desde la pantalla configuración. De esta manera, se puede tener un acceso directo a los dispositivos más empleados sin tener que pasar, necesariamente, por las diferentes pantallas que se tienen. En esta parte de la pantalla se establece siempre, como el primer dispositivo de la lista, el botón Alerta para que el usuario pueda pulsarlo en cualquier momento sin tener que pasar por la pantalla de Actuadores. La parte más importante de esta pantalla (puesto que sólo aparece en ella) es la elección del modo de funcionamiento (se explicará más detalladamente en 4.4). Se trata de un cuadro localizado en la parte inferior de la pantalla que tiene como posibilidades los diferentes modos de funcionamiento de la aplicación. Estos son el modo Ojos, Táctil, Voz y Gestos. Cuando se selecciona cualquiera de estos botones, la aplicación sólo se puede manejar empleando ese método concretamente (salvo el modo táctil, que se puede emplear siempre para asegurarnos de que, si los dispositivos de lectura de Ojos, Voz o Gestos fallasen, el usuario podr´ıa realizar las acciones necesarias para evitar que la aplicación realizase cambios indeseados en la habitación por errores de lectura). Adicionalmente, se ha incluido una etiqueta debajo del botón de Ojos que especifica qué modo de click se tiene seleccionado en cada momento y, debajo del botón Gestos, qué dispositivo se tiene seleccionado en cada momento para saber sobre qué dispositivo se realizarán los cambios. 4.3.3.. Pantalla Configuraci´ on. Cuando se acceede a la pantalla Configuraci´ on, empleando cualquier modo de funcionamiento, se establece automáticamente el modo táctil como modo activo.

(45) 4.3. INTERFACES. 25. Figura 4.8: Pantalla Principal. para evitar que se puedan realizar cambios indeseados en la configuración de la aplicación. A esta ventana sólo se puede acceder pulsando el botón Configuración de la pantalla principal. En esta ventana se realizan todos los cambios relacionados con la configuración de la aplicación. Posee dos partes diferenciadas y separadas mediante cuadros y, en la parte superior, un botón Volver que, una vez pulsado, hará regresar a la aplicación a la pantalla principal (ver figura ??). Justo debajo del botón volver se encuentra el men´ u favoritos donde aparece, en la lista de la izquierda, todos los dispositivos disponibles en la aplicación. Para a˜ nadir un dispositivo al men´ u Favoritos de la pantalla principal basta con seleccionar un dispositivo de esta lista y pulsar el botón A˜ nadir Favorito. De esta manera, este dispositivo se posiciona también en la lista de la derecha (donde aparecen los favoritos seleccionados) y, en caso de que se quiera eliminar, bastará con seleccionarlo en la lista de favoritos y pulsar el botón Eliminar Favorito. Para evitar problemas, se ha establecido que, si se realiza una acción errónea (como pulsar a˜ nadir favorito sin tener seleccionado ning´ un dispositivo de la lista o eliminar un favorito cuando no existen) se crea un cuadro para informar al usuario de que la acción cometida ha sido errónea y por qué. Por u ´ltimo, en la parte inferior de la pantalla aparece el men´ u del dispositivo Eye Tracker. En este men´ u aparecen, a la izquierda, el usuario activo en ese momento de la ejecución (ya que cada dispositivo tiene una calibración y datos independientes, como si lleva o no gafas) y justo debajo de esta etiqueta aparece una lista con todos los usuarios disponibles en el dispositivo. A la derecha de esta lista aparecen todas las acciones que se pueden realizar sobre el dispositivo, como cambiar el usuario disponible o la creación de un usuario nuevo. En la parte inferior de este men´ u aparecen dos botones donde el usuario pueda seleccionar el modo de click activado en cada momento (Fijación o Gui˜ no) y dos deslizantes para cambiar el tiempo m´ınimo de cada modo para considerarlos como un click. Adicionalmente, aparece un deslizante creado para que se pueda modificar el tiempo necesario para que un cierre de ojos provoque un cambio en el modo de click seleccionado en cada momento..

(46) ˜ CAPÍTULO 4. DISENO. 26. Figura 4.9: Pantalla de Configuración. 4.3.4.. Pantalla Sensores. En la pantalla Sensores aparecerán, inicialmente, el botón Alerta (para avisar de un problema) y el botón Volver (para regresar a la pantalla principal). Debajo de estos dos botones obligatorios aparecerán los diferentes sensores disponibles en la habitación con un código de colores determinado (ver figura 4.10). Además, sobre estos dispositivos el usuario no puede realizar ninguna modificación ya que son sólo para consultar el estado de la habitación en un momento determinado. De esta manera, el usuario puede observar cómo se encuentra cada sensor de la habitación pero no puede desactivarlos ni realizar ninguna acción indebida por mirar a los diferentes sensores, aunque sea durante mucho tiempo.. Figura 4.10: Pantalla de Sensores. 4.3.5.. Pantalla de Actuadores. En esta pantalla aparecerán inicialmente los mismos botones que en la pantalla sensores (ver seccion 4.3.4) y con la misma función (los botones alerta y volver)..

(47) 4.3. INTERFACES. 27. Adicionalmente, aparecerán todos los dispositivos considerados como actuadores en el controlador para que el usuario pueda realizar las modificaciones oportunas sobre ellos (ver figura 4.11). Además, también se ha creado un código de colores diferente a los sensores para que el usuario pueda conocer el estado de cada actuador (cada tipo de actuador lleva un color diferente). En el caso de las luces, además, se ha a˜ nadido una etiqueta que indica el estado actual del actuador de manera gráfica. En el caso de los deslizantes (luces regulables, por ejemplo), se ha creado un cuadro que tendrá como elementos un botón menos (para bajar un 10 % la intensidad), un botón más (para subir un 10 % la intensidad) y la etiqueta en el centro de ambos con el nombre del actuador.. Figura 4.11: Pantalla de Actuadores. 4.3.6.. Pantalla Multimedia. La pantalla multimedia (ver figura 4.12) es una pantalla creada para el ocio del usuario. Esta ventana contiene otras tres ventanas posibles dentro de s´ı. Estas ventanas disponibles son Imágenes, Sonidos y V´ıdeos (aunque en este proyecto sólo se ha habilitado la ventana Imágenes, ver figura 4.13). Para acceder a ella basta con pulsar el botón Imágenes y se crea otra ventana con diferentes imágenes y dos botones para poder navegar por las imágenes establecidas. Las imágenes se han predefinido por nosotros como prueba de funcionamiento y para acceder a ellas simplemente se guardarán con nombres de n´ umeros enteros y en formato jpg aunque en el futuro se pueda modificar. 4.3.7.. Cuadro de Di´ alogo. Por u ´ltimo, se ha creado un cuadro de diálogo para que el programa pueda informar al usuario de cualquier problema que haya podido ocurrir. Este cuadro de diálogo tendrá un tama˜ no suficientemente grande para que pueda verse con claridad y dispondrá de un botón de aceptar que el usuario tendrá que pulsar para seguir con el programa. Cuando pulse ese botón aceptar, se cerrará el cuadro de diálogo (ver figura 4.14, donde se ha pulsado el botón A˜ nadir Favorito de la pantalla Configuración sin tener ning´ un dispositivo seleccionado)..

(48) ˜ CAPÍTULO 4. DISENO. 28. Figura 4.12: Pantalla Multimedia. Figura 4.13: Pantalla Imágenes. 4.4.. Modos de Funcionamiento. Para realizar las conexiones entre la aplicación y el controlador de Vera se partirá de un código realizado previamente por otro estudiante. Este código pose´ıa la lógica necesaria para el funcionamiento del controlador de Vera en función de los diferentes botones. Para la aplicación desarrollada en este proyecto se han tenido que modificar ligeramente ciertos métodos empleados en la clase VeraController.h y eliminar algunos que no se van a emplear para esta aplicación como son los correspondientes a las luces deslizantes. Además, se han tenido que realizar diversas modificaciones sobre el programa desarrollado inicialmente, ya que en las versiones iniciales se empleaba cURL para peticiones web, mientras que finalmente se ha empleado la librer´ıa QURL de QtCreator debido al código empleado por el otro estudiante. Además, para continuar con la lógica empleada por este estudiante, las interfaces de la aplicación se han desarrollado mediante código de manera completa y no usando el QtDesigner, que se emplea especialmente para la interfaz de usuario. La aplicación desarrollada en el proyecto se ha pensado para que tenga cuatro modos diferentes de funcionamiento. Se han establecido el modo “Táctil”, el modo “Ojos” (para poder interactuar mediante la vista), el modo “Voz” (para poder in-.

(49) 4.4. MODOS DE FUNCIONAMIENTO. 29. Figura 4.14: Cuadro de Diálogo. teractuar mediante la voz, con unos comandos establecidos previamente) y un modo “Gestos” para poder controlarlo mediante movimientos de los brazos del usuario. En el modo Táctil se controlará la habitación directamente mediante la pulsación de los botones de las interfaces dise˜ nadas y explicadas en el apartado 4.3. En el modo Ojos se puede controlar la habitación de la misma manera, pero en este caso, el método de hacer click en cada uno de los botones puede ser o bien mirando fijamente a un botón durante un tiempo establecido, o bien gui˜ nando cualquier ojo mirando a ese botón. El tiempo para considerar una fijación o un gui˜ no como click puede ser modificado por el usuario desde la pantalla configuración y el método empleado (sólo puede haber uno activo al mismo tiempo), también se puede modificar desde esta pantalla o bien se puede modificar manteniendo los ojos cerrados durante un tiempo m´ınimo (a especificar en la pantalla configuración también). Además, en esa pantalla configuración se pueden realizar acciones directamente sobre el usuario, como recalibrar el dispositivo o cambiar de usuario, en caso necesario. En el modo Voz se controlará la habitación mediante unos comandos de voz determinados previamente. Para que el programa empiece a escuchar bastará con decir la palabra “Hola” y, posteriormente, se podrá navegar por la aplicación mediante los comandos preestablecidos indicados anteriormente. En el modo Gestos se pueden realizar acciones sobre algunos dispositivos, como las luces, de tal manera que si el usuario coloca cualquiera de los brazos en posición horizontal frente a la kinect, el dispositivo seleccionado cambiará al siguiente (si es el brazo izquierdo) o al anterior (si es el brazo derecho). Para cambiar el estado de la bombilla seleccionada bastará con colocar cualquiera de los brazos de manera vertical apuntando hacia arriba..

(50) 30. ˜ CAPÍTULO 4. DISENO.