GUIDIN: generador interactivo de instrucciones de guía para usuarios con necesidades especiales sobre plataformas móviles

GUIDIN: Generador interactivo de instrucciones de guía para usuarios con necesidades especiales sobre plataformas móviles Trabajo de n de grado Jorge Almendros Fresnillo Luis Hernández Donadeu Departamento de Ingeniería del Software e Inteligencia Articial Facultad de Informática Universidad Complutense de Madrid Junio 2015 Documento maquetado con TEX i S v.1.0. GUIDIN: Generador interactivo de instrucciones de guía para usuarios con necesidades especiales sobre plataformas móviles Memoria que presenta para el Trabajo Fin de Grado Jorge Almendros Fresnillo Luis Hernández Donadeu Dirigida por: Gonzalo Méndez Pozo Raquel Hervás Ballesteros Departamento de Ingeniería del Software e Inteligencia Articial Facultad de Informática Universidad Complutense de Madrid Junio 2015 Copyright c  Jorge Almendros Fresnillo Luis Hernández Donadeu Autorización Se autoriza a la Universidad Complutense de Madrid a difundir y utilizar con nes académicos, no comerciales y mencionando expresamente a sus autores, tanto la propia memoria, como el código, los contenidos audiovisuales incluso si incluyen imágenes de los autores, la documentación y/o el prototipo desarrollado. Jorge Almendros Fresnillo Luis Hernández Donadeu v Agradecimientos La elaboración de este proyecto a requerido de mucho esfuerzo y dedicación por parte de los dos integrantes del grupo. Pero al nal ha sido posible sacarlo adelante, en parte gracias a las aportaciones, ánimos y empuje que nos han dado amigos y familiares, y por ello queremos aprovechar estas lineas para agradecerles el esfuerzo. Por otro lado, también se merecen una mención en este apartado nuestros tutores, Gonzalo Méndez Pozo y Raquel Hervás Ballesteros, que nos han ayudado siempre que lo hemos necesitado, nos han guiado, soportado, aguantado retrasos (½y qué retrasos!) y metido presión cuando ha hecho falta. Gracias a todos. vii Resumen Dada la situación actual en la que nos encontramos en el mundo del posicionamiento wi-, se nos plantea el reto de realizar una aplicación que sea capaz de servir de guía a personas con discapacidad, con la complejidad añadida de guiarlas en el interior de edicios. GuiDIn (Guía para personas con Discapacidad en Interiores) será el nombre que reciba nuestra aplicación. Consiste en posicionamiento en interiores basado en WPS. La aplicación es capaz de guiar a una persona, con discapacidad o no, dentro de la Facultad de Informática de la Universidad Complutense de Madrid. El dispositivo sabe en todo momento donde se encuentra el usuario y le indica el camino que debe seguir para llegar al lugar indicado por éste. El posicionamiento se ha realizado mediante triangulación de intensidades de señal wi-, aunque se han valorado otras opciones, al nal se concluyó que esta era la mejor opción. Se llevó a cabo un estudio sobre aplicaciones similares y no se encontró ninguna aplicación que estuviese orientada a personas con discapacidad, por lo que la idea de este proyecto es original e innovadora, siendo además el posicionamiento en interiores un tema también actual y sobre el que merece la pena investigar. La plataforma sobre la que se ha desarrollado esta aplicación a sido Android. Se han tenido en cuenta otras posibilidades pero se descartaron por diversos motivos que se explican mas adelante. Entre estos motivos tenemos la facilidad de acceder a los sensores del dispositivo, además de la facilidad de acceso a las herramientas para su desarrollo. Para la elaboración de este proyecto se ha llevado a cabo una gestión del proyecto que incluye gestión de requisitos y de riesgos. De igual modo se realizó una planicación del proyecto para poder cumplir con los tiempos establecidos para la realización el mismo. El proyecto está dividido en dos grandes secciones, la parte del cliente que consiste en una aplicación Android que se ejecuta sobre un dispositivo móvil con este sistema operativo, y por otro lado la parte del servidor, un ordenador que se encarga de realizar todos los cálculos necesarios para la correcta ejecución de la aplicación que además libera de carga de trabajo al dispositivo. ix Índice Autorización v Agradecimientos vii Resumen ix Abstract xiii 1. Introducción 1 1.1. Motivación ............................ 1 1.2. Objetivos ............................. 2 1.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . 2 2. Introduction 5 2.1. Motivation............................. 5 2.2. Objectives............................. 5 2.3. Document structure . . . . . . . . . . . . . . . . . . . . . . . 6 3. Estado de la cuestión 9 3.1. Sistemas de posicionamiento . . . . . . . . . . . . . . . . . . . 9 3.1.1. Posicionamiento mediante triangulación . . . . . . . . 9 3.1.2. Posicionamiento GPS . . . . . . . . . . . . . . . . . . 9 3.1.3. Posicionamiento bluetooth . . . . . . . . . . . . . . . . 11 3.1.4. Posicionamiento wi- . . . . . . . . . . . . . . . . . . . 11 3.2. Aplicaciones de guía en interiores . . . . . . . . . . . . . . . . 12 3.2.1. Google indoor maps . . . . . . . . . . . . . . . . . . . 12 3.2.2. Infsoft........................... 13 3.2.3. Redpin........................... 14 3.3. Trabajos previos . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.1. Avanti: Sistema de asistencia a la evacuación de incendios2009-2010 ...................... 14 3.3.2. Sistema de guía por voz en interiores 2012-2013 . . . . 15 xvii xviii Índice 3.3.3. Generador interactivo de instrucciones de guía sobre plataformas móviles 2013-2014 . . . . . . . . . . . . . 16 4. Tecnologías utilizadas 17 4.1. Android.............................. 17 4.2. Sistemasdevoz.......................... 18 4.2.1. Reconocimiento de voz . . . . . . . . . . . . . . . . . . 19 4.2.2. Reproducción de voz . . . . . . . . . . . . . . . . . . . 20 5. Gestión del proyecto 21 5.1. Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . 21 5.1.1. Encuestas con usuarios nales . . . . . . . . . . . . . . 21 5.1.2. Requisitos......................... 22 5.2. Gestión de riesgos . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.1. Análisis de los riesgos . . . . . . . . . . . . . . . . . . 24 5.2.2. Estudio de los riesgos . . . . . . . . . . . . . . . . . . 25 5.3. Planicación del proyecto . . . . . . . . . . . . . . . . . . . . 28 6. Arquitectura de GUIDIN 31 6.1. Características del proyecto . . . . . . . . . . . . . . . . . . . 31 6.2. Comunicación........................... 32 7. Diseño del cliente 35 7.1. Introducción............................ 35 7.2. Descripción de las clases utilizadas . . . . . . . . . . . . . . . 36 7.3. Diagramas de casos de uso . . . . . . . . . . . . . . . . . . . . 41 7.4. Diagramas de secuencia . . . . . . . . . . . . . . . . . . . . . 42 7.5. Manual de usuario . . . . . . . . . . . . . . . . . . . . . . . . 45 7.5.1. Pantalla de inicio de la aplicación . . . . . . . . . . . . 45 7.5.2. Pantalla de registro de la aplicación . . . . . . . . . . 45 7.5.3. Menú principal . . . . . . . . . . . . . . . . . . . . . . 45 7.5.4. Menú para Usuarios . . . . . . . . . . . . . . . . . . . 46 7.5.5. Menú para Administradores . . . . . . . . . . . . . . . 48 8. Diseño del servidor 51 8.1. Introducción............................ 51 8.2. Descripción de la Base de Datos . . . . . . . . . . . . . . . . . 52 8.3. FicherosPHP........................... 53 8.4. AplicaciónJava.......................... 55 8.4.1. XML............................ 55 8.4.2. Java............................ 58 Índice xix 9. Conclusiones y trabajo futuro 61 9.1. Descripción de los resultados obtenidos . . . . . . . . . . . . . 61 9.2. Conclusiones ........................... 62 9.3. TrabajoFuturo.......................... 62 10.Conclusions and future work 63 10.1. Description of results . . . . . . . . . . . . . . . . . . . . . . . 63 10.2.Conclusions............................ 63 10.3.futurework ............................ 64 11.Trabajo individual 65 11.1. Jorge Almendros Fresnillo . . . . . . . . . . . . . . . . . . . . 65 11.2. Luis Hernández Donadeu . . . . . . . . . . . . . . . . . . . . . 66 A. Manual de instalación 69 A.1.Requisitos............................. 69 A.2. Instalación en Android Studio . . . . . . . . . . . . . . . . . . 69 A.3. Instalación en un dispositivo móvil . . . . . . . . . . . . . . . 70 A.4. Instalación del servidor . . . . . . . . . . . . . . . . . . . . . . 70 B. Extensión de la aplicación 71 B.1. Conexión cliente servidor . . . . . . . . . . . . . . . . . . . . . 71 B.2. Crear base de datos . . . . . . . . . . . . . . . . . . . . . . . . 72 B.3. Enlace cliente - base de datos . . . . . . . . . . . . . . . . . . 72 B.4. Medir intensidades wi- . . . . . . . . . . . . . . . . . . . . . 73 B.5. Creación de los XML relativos a la estructura del edicio . . . 73 B.6. Establecer destinos . . . . . . . . . . . . . . . . . . . . . . . . 73 B.7. Compilar y ejecutar la aplicación . . . . . . . . . . . . . . . . 74 B.8. Añadir discapacidades . . . . . . . . . . . . . . . . . . . . . . 74 C. Formularios pasados a personas con discapacidades 75 Bibliografía 79 Lista de acrónimos 81 Índice de guras 3.1. Posicionamiento por triangulación. . . . . . . . . . . . . . . . 10 3.2. Google indoor maps . . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Insoft1............................... 14 3.4. Insoft2............................... 14 3.5. Redpin............................... 15 6.1. Estructura............................. 32 6.2. Comunicación Cliente con BBDD . . . . . . . . . . . . . . . . 33 6.3. Comunicación Cliente con la aplicación Java . . . . . . . . . . 33 7.1. PaqueteHTTP........................... 37 7.2. PaqueteSockets. ......................... 37 7.3. PaqueteWPS. .......................... 38 7.4. Paqueterutas. .......................... 38 7.5. Clases principales del cliente. . . . . . . . . . . . . . . . . . . 40 7.6. Caso de uso usuario. . . . . . . . . . . . . . . . . . . . . . . . 41 7.7. Caso de uso administrador. . . . . . . . . . . . . . . . . . . . 42 7.8. Diagrama de secuencia Login. . . . . . . . . . . . . . . . . . . 43 7.9. Diagrama de secuencia Medir intensidades. . . . . . . . . . . . 43 7.10. Diagrama de secuencia Posición en el mapa. . . . . . . . . . . 44 7.11. Diagrama de secuencia Indicar destino. . . . . . . . . . . . . . 44 7.12. Inicio de la aplicación. . . . . . . . . . . . . . . . . . . . . . . 46 7.13. Pantalla de registro. . . . . . . . . . . . . . . . . . . . . . . . 46 7.14.Menúdeusuario ......................... 47 7.15. Pantalla de indicar destino . . . . . . . . . . . . . . . . . . . . 47 7.16. Pantalla de posición en el mapa. . . . . . . . . . . . . . . . . 48 7.17. Menú de administradores. . . . . . . . . . . . . . . . . . . . . 48 7.18. Pantalla de actividad wi- . . . . . . . . . . . . . . . . . . . . 49 7.19. Pantalla de detalle de red wi- . . . . . . . . . . . . . . . . . 49 7.20. Pantalla de acelerómetros. . . . . . . . . . . . . . . . . . . . . 50 7.21. Pantalla de medir intensidades. . . . . . . . . . . . . . . . . . 50 xxi xxii Índice de figuras 8.1. Comunicacion PHP con BBDD . . . . . . . . . . . . . . . . . 51 8.2. TablasdeBBDD......................... 52 8.3. Nuevaposición .......................... 54 8.4. Dameposiciones ......................... 54 8.5. Login ............................... 55 8.6. Diagrama de clases Java . . . . . . . . . . . . . . . . . . . . . 58 8.7. Secuencia Calcula Ruta . . . . . . . . . . . . . . . . . . . . . 60 A.1. Instalación en el dispositivo móvil . . . . . . . . . . . . . . . . 70 B.1. Lanzamiento de la ejecución en consola . . . . . . . . . . . . . 72 C.1. Formulario para personas con discapacidad visual. . . . . . . 76 C.2. Formulario para personas con discapacidad auditiva. . . . . . 77 Índice de Tablas 5.1. SQAS-SEI............................. 24 5.2. Criticidad de los riesgos encontrados . . . . . . . . . . . . . . 25 xxiii Capítulo 1 Introducción 1.1. Motivación Hoy en día prácticamente todo el mundo posee un teléfono inteligente, o smartphone , y cada vez son más utilizados para tareas que nos facilitan la vida o nos entretienen. Entre estas tareas encontramos la de guiar a las personas, que nos da la posibilidad de llegar a multitud de sitios de forma rápida y precisa sin necesidad de estar buscando tediosamente como llegar a nuestro destino. Para ello se empezó a utilizar el GPS (Global Positioning System) , para guiarnos hasta lugares tan distantes entre sí como podamos imaginar. Sin embargo, el problema ante el cual nos encontramos ahora es el de navegar dentro de edicios, donde el GPS no es capaz de guiarnos con precisión. Actualmente la mayor parte de los dispositivos móviles que lleva la gente siempre encima posee tecnología inalámbrica wi- para conectarse a Internet. Sin embargo, esta tecnología no sólo sirve para esta función sino que también puede resultar bastante útil para posicionar un dispositivo a través de varias intensidades de señales wi-. Aparte de lo ya mencionado, una de nuestras grandes motivaciones es la de poder hacer llegar esta tecnología a personas con discapacidad, facilitándoles la vida en todo lo que nos sea posible. Nuestra aplicación estará centrada en ayudar a personas con discapacidad visual y auditiva. Por lo tanto, nuestra problemática además del posicionamiento en interiores es la de conseguir que estas personas con las discapacidades mencionadas sean capaces de utilizar la aplicación de la mejor manera posible. Para ello se ha realizado una investigación relacionada con este tema y se han llevado a cabo encuestas para poder dar el mejor servicio posible. 1 Capítulo 3 Estado de la cuestión Este capítulo trata sobre los diferentes sistemas de localización que existen actualmente y se hace una valoración acerca de por qué se han utilizado para desarrollar la aplicación o por qué no. El mayor problema que nos hemos encontrado ha sido la falta de precisión, así como la falta de medios que es necesario desplegar para algunos tipos de posicionamiento. También se hace un estudio de algunas aplicaciones similares ya existentes en el mercado, además de una pequeña descripción de los proyectos anteriores de los que parte este mismo proyecto. 3.1. Sistemas de posicionamiento 3.1.1. Posicionamiento mediante triangulación La triangulación (Wikipedia, c) es una técnica de posicionamiento que necesita al menos tres señales. El origen de estas señales es conocido y lo único que hace falta es conocer la distancia a cada de ellas. Con estos datos se puede trazar una esfera alrededor de las señales con radio la distancia al dispositivo receptor de la señal, de esta forma las esferas generadas se cortarán unas a otras produciendo un único punto donde coincidan todos los cortes siendo ese el punto donde se encontrará el dispositivo que se quiera localizar. Si se desea conocer la altitud es necesario que como mínimo existan cuatro emisores de señales. Este sistema es aplicable a cualquier tipo de posicionamiento, ya sea GPS, bluetooth, wi-, etc. La Figura 3.1 muestra una aproximación de cómo funciona este tipo de posicionamiento 3.1.2. Posicionamiento GPS El sistema de posicionamiento por GPS (Global Positioning System) es el más extendido y conocido mundialmente. El GPS (Wikipedia, b) es un ob9 10 Capítulo 3. Estado de la cuestión Figura 3.1: Posicionamiento por triangulación. jeto que permite a una persona determinar en todo el mundo la posición de un objeto, una persona o un vehículo con una precisión hasta de centímetros (si se utiliza GPS diferencial), aunque lo habitual son unos pocos metros de precisión. El sistema fue desarrollado, instalado y empleado por el Departamento de Defensa de los Estados Unidos. El sistema GPS está constituido por 24 satélites y utiliza la triangulación para determinar en todo el globo una posición con una precisión de más o menos metros. El GPS funciona mediante una red de 24 satélites en órbita sobre el planeta tierra, a 20.200 km de altura, con trayectorias sincronizadas para cubrir toda la supercie de la Tierra. Cuando se desea determinar la posición, el receptor que se utiliza para ello localiza automáticamente como mínimo cuatro satélites de la red, de los que recibe unas señales indicando la identicación y la hora del reloj de cada uno de ellos. Con base en estas señales, el aparato sincroniza el reloj del GPS y calcula el tiempo que tardan en llegar las señales al equipo, y de tal modo mide la distancia al satélite mediante método de triangulación inversa, la cual se basa en determinar la distancia de cada satélite respecto al punto de medición. Conocidas las distancias, se determina fácilmente la propia posición relativa respecto a los satélites. También se consigue una exactitud extrema en el reloj del GPS, similar a la de los relojes atómicos que llevan a bordo cada uno de los satélites. La antigua Unión Soviética construyó un sistema similar llamado GLONASS, ahora gestionado por la Federación Rusa. Actualmente la Unión Eu- 3.1. Sistemas de posicionamiento 11 ropea está desarrollando su propio sistema de posicionamiento por satélite, denominado Galileo. A su vez, la República Popular China está implementando su propio sistema de navegación, el denominado Beidou. Sin embargo, el gran problema ante el que se encuentra este tipo de posicionamiento son los obstáculos. El posicionamiento GPS funciona perfectamente cuando hay conexión directa con los satélites, pero en el momento que hay algún obstáculo de por medio, es muy probable que se pierda la conexión. Un claro ejemplo de esto es cuando un coche que se va guiando por satélite entra en un túnel, ya que en ese momento la conexión se pierde. La solución que intentan implementar estos aparatos es que intuyen donde debería estar el coche basándose en la velocidad y el camino que sigue la carretera, siendo un sistema poco able y no utilizable para guiar a personas. 3.1.3. Posicionamiento bluetooth La conexión bluetooth es una red inalámbrica de área personal (WAPN), que permite la conexión y transferencia de datos entre varios dispositivos. La parte positiva de esta conexión la encontramos en el consumo, ya que ofrece consumos muy bajos tanto para los emisores como para los receptores. Por otro lado tenemos el alcance de estas redes. Incluso en sus ultimas versiones (4.0) no supera los 10 metros por lo que sería necesario disponer de un numero de balizas demasiado grande para cubrir toda la supercie que ocupa el edicio en el que se intenta hacer la navegación (Retana, 2010). De la misma forma la velocidad de transmisión también es un problema en este tipo de redes, ya que no se acercan a las velocidades que pueden ofrecer las conexiones wi-, por ejemplo. 3.1.4. Posicionamiento wi- Las redes wi- son redes inalambricas de area local (Wireless Local Area Network o WLAN). Existen diversos tipos de wi-, basado cada uno de ellos en un estándar IEEE 802.11 aprobado. Los estándares IEEE 802.11b, IEEE 802.11g e IEEE 802.11n disfrutan de una aceptación internacional debido a que la banda de 2.4 GHz está disponible casi universalmente, con una velocidad de hasta 11 Mbit/s, 54 Mbit/s y 300 Mbit/s, respectivamente. En la actualidad ya se maneja también el estándar IEEE 802.11ac, conocido como wi- 5, que opera en la banda de 5 GHz y que disfruta de una operatividad con canales relativamente limpios. La banda de 5 GHz ha sido recientemente habilitada y, además, no existen otras tecnologías (bluetooth, microondas, etc.) que la estén utilizando, por lo tanto existen muy pocas interferencias. Su alcance es algo menor que el de los estándares que trabajan a 2.4 GHz (aproximadamente un 10 por ciento), debido a que la frecuencia es mayor (a mayor frecuencia, menor alcance). La idea de localización a través de señales wi- (Wikipedia, d) (Chen 12 Capítulo 3. Estado de la cuestión and Kobayashi, 2002) consiste en que un dispositivo capta la señal wi- de un dispositivo de red. Una vez conocida su dirección MAC, el dispositivo se conecta a una base de datos en la que hay almacenadas diferentes coordenadas cartesianas asociadas a diferentes señales MAC (en caso de haberlas) y la intensidad que la señal wi- del dispositivo de red alcanza en ese punto. De este modo, se puede interpolar entre la intensidad captada por el dispositivo y la guardada en la base de datos para conocer la posición en la que se encuentra el dispositivo de red. Este tipo de posicionamiento permite localizar un dispositivo con un margen de error de un metro como máximo, lo cual es considerado un margen bastante pequeño y aceptable para la realización de nuestro proyecto. Hay que tener en cuenta que se pretende guiar a personas con discapacidad visual y la precisión es un factor muy importante, ya que habrá que pasar por zonas con cierta estrechez tales como puertas o ascensores. Estos hechos nos han llevado a tomar la decisión de que el posicionamiento por wi- haya sido el elegido para desarrollar nuestra aplicación. Este modo de posicionamiento nos aporta precisión, velocidad de transmisión, relativa facilidad de implementación, y suciente alcance de las señales wi-. 3.2. Aplicaciones de guía en interiores A continuación se explicarán como funcionan algunas aplicaciones similares, que también intentan realizar guía en interiores mediante intensidades de señal wi-. 3.2.1. Google indoor maps Google indoor maps (Google, 2014) es un proyecto de Google con el que se pretende ampliar la funcionalidad de la aplicación Google maps. Esta aplicación permite visualizar mapas de prácticamente todo el mundo, incluso con imágenes reales. Sin embargo hasta hace poco tiempo no se ha incluido la posibilidad de visualizar el interior de las estructuras de los edicios, en concreto edicios públicos como aeropuertos, centros comerciales, hospitales, etc. de los cuales podemos observar incluso las diferentes plantas de las que esté compuesto el edicio. Como se puede observar en la Figura 3.2 la interfaz que ofrece esta aplicación es muy similar a la aplicación de exteriores. Para localizar el dispositivo dentro del edicio utilizan intensidades de señales wi- . Esta aplicación está todavía en desarrollo, aunque ya está disponible para su descarga y uso. La incorporación de mapas se hace mayormente por los propios usuarios que se tienen que encargar de localizar donde se encuentra el 3.2. Aplicaciones de guía en interiores 13 Figura 3.2: Google indoor maps lugar donde se encuentra el edicio, subir el mapa de cada planta que quieran incluir y por último alinearlo para que encaje con los mapas de Google. Una de las ventajas de esta aplicación es que al ser de Google, una de las empresas más grandes del mundo, la visibilidad y el alcance de cualquier aplicación que utilice esta tecnología puede ser muy grande. Sin embargo, por lo que hemos podido investigar el posicionamiento no es muy preciso, utilizan el mismo sistema de posicionamiento que para los mapas en exteriores, ayudándose un poco de las intensidades de wi-, pero estas son solo recolectadas gracias a la información que envían sus teléfonos sin que los usuarios se den cuenta, y por lo tanto la precisión no es muy buena. 3.2.2. Infsoft Esta empresa alemana (Infsoft, 2015) se dedica tanto al posicionamiento en interiores como en exteriores. Para el posicionamiento en interiores, que es el que nos atañe, utilizan todo tipo de sensores disponibles en el dispositivo móvil, como GSM, 3G/4G (LTE), wi-, campos magnéticos, presión del aire, barómetros, acelerómetros, giroscopios, bluetooth y GPS. Con todo esto son capaces de dar una precisión de menos de un metro. Proporcionan además información de la ruta por texto además de mostrarla en un mapa. También han implementado un sistema de realidad aumentada que muestra las indicaciones sobre las imágenes que muestra la cámara. Las Figuras 3.3 y 3.4 muestran esta aplicación en funcionamiento. Además, proporcionan herramientas para subir y editar mapas, y también para calibrar las posiciones. Trabajan sobre todo tipo de plataformas móviles, ya sea Android, IOS, Windows Phone o Blackberry por lo que pueden llegar a un gran público. 14 Capítulo 3. Estado de la cuestión Figura 3.3: Insoft1 Figura 3.4: Insoft2 3.2.3. Redpin Redpin (Redpin, 2008) es un sistema open source que fue desarrollado con la meta de proporcionar precisión a nivel de habitación. El sistema es capaz de identicar el que habitación se encuentra un dispositivo pero no de indicar el punto exacto. Su sistema se basa en ngerprints o huellas que asignan a cada zona. De cada una de ellas recolectan cierta información como la intensidad wi-, con lo que luego son capaces de indicar en que zona se encuentra el dispositivo. La aplicación posee clientes para Android e IOS, pero su gran ventaja es que desde su página ocial se puede descargar todo el código para poder utilizarlo. La gura 3.5 muestra una de las pantallas de esta aplicación. 3.3. Trabajos previos Como ya se ha mencionado anteriormente este proyecto surge como una evolución de otros proyectos ya desarrollados en la Facultad de Informática. Lo que hace diferente a GuiDIn de los trabajos previos es la adaptación a las personas con discapacidad. Este proyecto, al igual que los anteriores, se encuentra englobado en el proyecto MILES (TIN2009-14659-C03) del departamento de Ingeniería del Software e Inteligencia Articial de la Facultad de Informática de la Universidad Complutense de Madrid. Gran parte del trabajo previo ha sido de mucha utilidad para el desarrollo de nuestra aplicación. A continuación se detallan los proyecto llevados a cabo en años anteriores de los cuales parte GuiDIn. 3.3.1. Avanti: Sistema de asistencia a la evacuación de incendios 2009-2010 Avanti fue el proyecto original del cual han partido todos los posteriores, incluido este mismo. Fue un proyecto de Sistemas Informáticos llevado a cabo 3.3. Trabajos previos 15 Figura 3.5: Redpin por Enrique Lopez Mañas, Francisco Javier Moreno y Javier Plá Herrero (E. López Mañas, F. J. Moreno y J. Plá Herrero, 2010). Dicho proyecto se planteó como un sistema capaz de guiar a las personas durante un simulacro de incendio. Desde este proyecto se utilizó el posicionamiento mediante wi- para realizar la guía en interiores, porque como ya se ha demostrado es la opción más viable. Además de esto se emplearon los acelerómetros del dispositivo para estimar mejor la posición del usuario, y poder posicionar al usuario incluso en zonas donde la señal wi- apenas llega. Un gran atractivo de esta aplicación era el uso que se hacía de la realidad aumentada, para que a través de la cámara del dispositivo se pudiesen mostrar unos fuegos simulados sobre la propia Facultad de Informática 3.3.2. Sistema de guía por voz en interiores 2012-2013 Trabajo de Fin de Grado realizado por Mariana MartínCalderín de la Villa (Mariana Martín-Calderín de la Villa, 2013). Este proyecto se centró en la guía en interiores. Se utilizó el mismo tipo de posicionamiento por wi-, pero se mejoraron las ayudas al posicionamiento a través del acelerómetro y la brújula del dispositivo y además se adaptó a las nuevas versiones de Android. También se incluyeron sistemas de reconocimiento y reproducción de voz utilizados para pedir el destino y para reproducir las instrucciones generadas 16 Capítulo 3. Estado de la cuestión por el calculo de la ruta. 3.3.3. Generador interactivo de instrucciones de guía sobre plataformas móviles 2013-2014 Proyecto de n de carrera de Ingeniería Informática realizado por Víctor Gutiérrez Rodríguez, Juan Diego Lozano Martín y Víctor Manuel Pose Murga (Víctor Gutiérrez Rodríguez, Juan Diego Lozano Martín y Víctor Manuel Pose Murga, 2014). Este proyecto consistió básicamente en una mejora sobre el proyecto anterior. Se mejoró el posicionamiento ya que se implementó la posibilidad de realizar la guía a través de varias plantas del edicio, ademas de que se facilitó la posibilidad de llevar la aplicación a otros edicios. Se mejoró también la generación de instrucciones, creando unas instrucciones mas simples, intuitivas y ecaces. Conclusiones Los sistemas de posicionamiento analizados tienen sus ventajas y sus desventajas como se ha explicado en este capítulo, y teniendo esto en cuenta se ha elegido el sistema de posicionamiento wi-. Sin duda es el que mejor se adapta a las características del proyecto ya que no requiere ningún tipo de instalación de material para llevarlo a cabo, como por ejemplo requiere el posicionamiento por bluetooth. El posicionamiento GPS se descartó desde el principio ya que en interiores en totalmente inservible este tipo de posicionamiento. Sin embargo, sí se usa la triangulación, ya que lo que se hace con las intensidades de señal wi- es triangularlas para conseguir localizar el dispositivo. Respecto a los proyectos anteriores se puede decir que han sido muy útiles sobre todo para realizar el posicionamiento en el cliente así como para tener una buena base de los algoritmos que calculan la ruta. Nuestro trabajo ha consistido en adaptar estas funcionalidades a personas con discapacidad, teniendo que realizar modicaciones en las rutas generadas teniendo en cuenta la discapacidad del usuario. De la misma forma la aplicación cliente requiere las adaptaciones necesarias para que un discapacitado visual o auditivo sea capaz de usarla sin problema, lo que conlleva un uso exhaustivo de las funciones de reproducción y reconocimiento de voz además de proporcionar las indicaciones de una forma u otra también en función de la discapacidad. Capítulo 4 Tecnologías utilizadas Este capítulo describe el sistema operativo Android (Google, 2015a), utilizado para el desarrollo de la aplicación, y explica por qué se ha usado como plataforma. Por otro lado también se abordará el tema de los sistemas de voz utilizados, ya sea para pasar texto a voz o viceversa. 4.1. Android Este sistema operativo, basado en el kernel de Linux, fue diseñado desde un principio para dispositivos táctiles, tales como móviles y tabletas, aunque más recientemente se ha empezado a utilizar en relojes, televisiones y coches, para las que se han desarrollado las versiones especícas Android Wear, Android TV y Android auto respectivamente. Inicialmente el proyecto fue desarrollado por la empresa Android Inc. la cual recibía ayudas de Google, y nalmente en 2005 se llevó a cabo la compra por parte de Google, actual propietaria del sistema operativo. La primera versión fue presentada en el 2007 pero no fue hasta nales del 2008 cuando se lanzó el primer teléfono al mercado, el HTC Dream (Google, 2015b). Este sistema operativo posee una gran comunidad de desarrolladores creando aplicaciones para extender la funcionalidad de los dispositivos. Recientemente se ha superado el millón de aplicaciones, de las cuales dos tercios son gratuitas. La estructura del sistema operativo Android se compone de aplicaciones que se ejecutan en un framework Java de aplicaciones orientadas a objetos sobre el núcleo de las bibliotecas de Java en una máquina virtual Dalvik con compilación en tiempo de ejecución. Las bibliotecas escritas en lenguaje C incluyen un administrador de interfaz gráca (surface manager), un framework OpenCore, una base de datos relacional SQLite, una Interfaz de programación de API gráca OpenGL ES 2.0 3D, un motor de renderizado WebKit, un motor gráco SGL, SSL y una biblioteca estándar de C Bionic. El sistema operativo está compuesto por 12 millones de líneas de código, 17 24 Capítulo 5. Gestión del proyecto Los riesgos serán analizados de forma pro activa, de tal forma que serán identicados antes de que alguno ocurra, de esta forma se podrán prevenir y dar soluciones si se llegan a producir. Una vez no se haya podido evitar un riesgo, lo identicaremos, así como sus causas y se asignarán recursos para evitar que suponga un problema para el correcto desarrollo del proyecto. Se creará una lista para cada uno de los riesgos, recogiendo el nivel que presenta cada uno, teniendo en cuenta la relación entre la probabilidad y la severidad de que ocurran. Este nivel queda reejado en la técnica SQASSEI (Department of Energy Quality Managers, Software Quality Assurance Subcommittee, 1999) (Tabla 5.1) dónde se establecen los siguientes valores: Probabilidad/ severidad Frecuente Probable Ocasional Remoto Improbable Catastróco Intolerable Intolerable Intolerable Alto Medio Crítico Intolerable Intolerable Alto Medio Bajo Serio Alto Alto Medio Bajo Tolerable Menor Medio Medio Bajo Tolerable Tolerable Insignicante Medio Bajo Tolerable Tolerable Tolerable Tabla 5.1: SQAS-SEI 5.2.1. Análisis de los riesgos Resumimos los riesgos encontrados en la Tabla 5.2, de acuerdo a estos parámetros: Nombre Probabilidad Severidad Nivel de Criticidad Quedan organizados en función de su nivel de criticidad. Los riesgos más graves serán aquellos de nivel de criticidad más alto: 5.2. Gestión de riesgos 25 Nombre Probabilidad Severidad N. Criticidad Abandono de un integrante del equipo Remoto Crítico Medio Falta de tiempo de dedicación debido al trabajo Frecuente Menor Medio Desconocimiento de las tecnologías Ocasional Insignicante Tolerable Estimaciones poco realistas Probable Serio Alto Problemas con el servidor Remoto Serio Bajo Problemas con la red wi de la facultad Probable Serio Alto Complicaciones con proyectos anteriores Remoto Menor Tolerable Fallo en la adaptación de la guía a la discapacidad Probable Serio Alto Posibilidad de bloqueo de APIs utilizadas Improbable Crítico Bajo Tabla 5.2: Criticidad de los riesgos encontrados 5.2.2. Estudio de los riesgos - Abandono de un integrante del equipo Descripción: Uno o varios miembros del equipo abandonan el proyecto. Probabilidad: Remoto. Severidad: Crítica. Nivel de Criticidad: Medio. Posibles causas: Problemas en otros ámbitos. Indicadores: Falta de asistencia las reuniones No realización del trabajo asignado. Plan de mitigación: Redistribución de las tareas asignadas a cada miembro. Eliminación de alguna de las funcionalidades a cubrir en el sistema. - Falta de tiempo de dedicación por culpa del trabajo Descripción: Debido a que ambos miembros trabajamos podría ser que en algún momento no tuviésemos el tiempo necesario para dedicárselo al proyecto. Probabilidad: Frecuente. Severidad: Menor. Nivel de Criticidad: Medio. 26 Capítulo 5. Gestión del proyecto Posibles causas: Entrega de proyectos. Fechas de cursos. Indicadores: No realización del trabajo asignado. Plan de mitigación: Redistribución de las tareas asignadas a cada miembro. Intentar recuperar el tiempo en el siguiente intervalo. - Desconocimiento de las tecnologías Descripción: Las tecnologías utilizadas en las versiones anteriores podrían ser desconocidas para los nuevos desarrolladores. Probabilidad: Ocasional. Severidad: Insignicante. Nivel de Criticidad: Tolerable. Posibles causas: Uso de librerías o funciones desconocidas para los miembros. Indicadores: Ralentización del trabajo propuesto. Plan de mitigación: Como es algo que será muy normal que pase, se tomará esto en cuenta cuando se haga la estimación en los tiempos de entrega. - Estimaciones poco realistas Descripción: Ponemos fechas a los objetivos planteados que no pueden cumplirse. Probabilidad: Probable. Severidad: Serio. Nivel de Criticidad: Alto. Posibles causas: Problemas en las entregas de los deadlines. Indicadores: No se realizan las entregas a tiempo. Plan de mitigación: Redistribución de las tareas asignadas a cada miembro. Bajar las expectativas hasta volver al tiempo base. - Problemas con el servidor Descripción: El servidor se encuentra inaccesible. Probabilidad: Remoto. Severidad: Serio. Nivel de Criticidad: Bajo. Posibles causas: El servidor está apagado. Indicadores: No se puede conectar al servidor. Plan de mitigación: Reiniciar el servidor y ver por qué se ha apagado. 5.2. Gestión de riesgos 27 - Problemas con la red wi de la facultad Descripción: Los datos recogidos de la wi- pueden ser incorrectos o haber cambiado desde que se recogieron. Probabilidad: Probable. Severidad: Serio. Nivel de Criticidad: Alto. Posibles causas: Reajuste de las redes wi-. Cambio en los routers de la facultad. Indicadores: Posicionamiento erróneo. Plan de mitigación: Actualizar la información de la wi de la facultad. - Complicaciones con proyectos anteriores Descripción: Algún modulo puede llegar a presentar incompatibilidades con las nuevas versiones. Probabilidad: Remoto. Severidad: Menor. Nivel de Criticidad: Tolerable. Posibles causas: Problemas en el trabajo heredado . Indicadores: Fallo en el posicionamiento. Fallo en la ruta generada cuando no se tienen discapacidades. Plan de mitigación: Investigar y corregir el fallo en la versión anterior. - Fallo en la adaptación de la guía a la discapacidad Descripción: No se puede adaptar la ruta alguna discapacidad concreta. Probabilidad: Probable. Severidad: Serio. Nivel de Criticidad: Alto. Posibles causas: Discapacidad no contemplada o fallo al generar la ruta por que no se puede llegar al destino con una determinada discapacidad. Indicadores: La ruta no es válida. Plan de mitigación: Re adaptación del código al generar las rutas a las nuevas discapacidades. Informar correctamente de que el destino existe pero no es alcanzable por la discapacidad del usuario. 28 Capítulo 5. Gestión del proyecto - Posibilidad de bloqueo de APIs/librerias utilizadas Descripción: puede suceder que algún elemento de las APIs/librerias utilizadas sean bloqueadas por parte del desarrollador de las mismas. Probabilidad: Improbable. Severidad: Critica. Nivel de Criticidad: Bajo. Posibles causas: Cambio de políticas en las API's/librerias utilizadas. Indicadores: Errores de funcionamiento de la aplicación. Plan de mitigación: Cambió a alguna de las otras tecnologías evaluadas que sean viables. 5.3. Planicación del proyecto El proyecto estaba denido en base a los objetivos que indicaba el plan del proyecto. Los objetivos que había que cumplir era la actualización de la aplicación de guía en interiores desarrollada en años anteriores para personas con discapacidad. Como no se indicó para que discapacidades concretas había que desarrollar el proyecto decidimos centrarnos en dos de ellas. Las elegidas fueron la discapacidad auditiva y la discapacidad visual. Para llevar el control del proyecto se establecieron reuniones con los directores del proyecto. Estas reuniones se producían cada dos semanas, y en ellas hablábamos de lo realizado hasta la fecha, de los problemas surgidos y del siguiente grupo de objetivos que teníamos que alcanzar. Como ya se ha mencionado anteriormente, este proyecto es una evolución de otro existente. Por lo tanto la primera tarea lógica que apareció fue el análisis y estudio del estado de la aplicación, para detectar donde debíamos centrarnos. El código estaba bien comentado, aunque algunas veces esos comentarios no eran totalmente correctos, pero nos sirvieron para hacernos una idea de cómo funcionaba la aplicación. Uno de los mayores problemas de este proyecto es la necesidad de encontrarse en el edicio de la facultad para realizar las pruebas, sobre todo las de posicionamiento. Por lo tanto había veces que el trabajo realizado en casa no se podía probar correctamente hasta que íbamos a la facultad. La primera tarea de desarrollo que nos planteamos fue migrar a la aplicación Android a un proyecto nuevo, y de esta forma eliminar el código obsoleto que había en ella. Después de esto hubo dos líneas de trabajo en paralelo, la primera consistía en adaptar la parte de generar rutas, la cual se encuentra en el lado del servidor, para que tuviese en cuenta los obstáculos y las discapacidades existentes, y la otra línea fue la adaptación de la aplicación para personas con discapacidad. Para ello hicimos una serie de cuestionarios a diferentes personas, con diferentes discapacidades, de tal forma que 5.3. Planicación del proyecto 29 desarrollamos la aplicación en base a estos datos. Durante estos procesos hubo que actualizar los modelos usados para que se ajustasen a las nuevas funcionalidades y la implementación de las nuevas librerías. Estas dos tareas junto con la tarea de hacer que se comunicasen correctamente ambas partes con los nuevos modelos fue la parte que más tiempo nos acaparó. El último paso que hubo que hacer fue ajustar la generación de las instrucciones correctamente a cada discapacidad, mejorando el sistema cada vez que lo usábamos hasta que obtuvimos los resultados que deseábamos. Capítulo 6 Arquitectura de GUIDIN 6.1. Características del proyecto En esta sección trataremos las características del proyecto en su conjunto. El proyecto está dividido en dos módulos principales, conectados entre sí. Estos son un programa cliente y un programa servidor (Matsudaira., 2012). La división entre cliente y servidor es debida al gran coste computacional (Arora, 2009) que supone el calculo de ruta, y dado que el terminal móvil ya realiza muchas funciones se optó el realizar estas tareas en un servidor, descargando de esta forma la carga del terminal. Aprovechando la necesidad de tener un servidor para el calculo de ruta se decidió usar también el servidor para almacenar la Base de Datos de la aplicación. De tal forma que en el servidor se generan las instrucciones para la ruta y el terminal móvil es un cliente Android que proporciona al usuario el resto de servicios. En la aplicación Android se establecerá el destino al que se quiere llegar y ésta enviará al servidor dicha información. Dado que la aplicación está dirigida a personas con discapacidades la selección de destino se puede hacer tanto por voz como por teclado, haciendo que la aplicación sea más accesible. A su vez la aplicación reproducirá las instrucciones recibidas del servidor y reproducirá éstas según las necesidades del usuario, el cual habrá indicado como preere recibir las instrucciones. Para mostrar la ruta hasta el destino nos basamos en los datos que hemos recopilado al preguntarle a personas con diferentes discapacidades, decidiendo que para personas con deciencia auditiva mostraremos la ruta de una forma y para personas con deciencia visual de otra. El algoritmo usado para el posicionamiento bajo redes wi- es el algoritmo de los k-vecinos más cercanos, o k-nn por sus siglas en inglés, el cual se ha reutilizado partiendo de los proyectos anteriores. El servidor es el encargado de recoger la información que le envía la aplicación Android y a través de diferentes archivos calcular la ruta óptima al destino. De tal modo que con esta serie de archivos será el servidor el encar31 32 Capítulo 6. Arquitectura de GUIDIN gado de encontrar la ruta óptima para cada usuario, teniendo en cuenta el origen, el destino y el grado de discapacidad. La ruta generada será preparada en una serie de instrucciones que serán enviadas al móvil para que éste las interprete y se las muestre al usuario de forma legible. Tanto el cliente como el servidor deberán estar en contacto de forma periódica, tanto para ver que el usuario no se ha desviado de la ruta o por el contrario para ver si lo ha hecho y recalcular la ruta que el usuario debería seguir. Cliente y servidor se comunican mediante un sistema de red, por el cual intercambian la información necesaria. Los datos del posicionamiento wi- son cargados en el cliente, y el módulo WPS se encarga de estimar nuestra posición, generando las coordenadas correspondientes. Figura 6.1: Estructura Como se reeja en la Figura 6.1 y como ya se ha comentado anteriormente esta sería la estructura de la aplicación. 6.2. Comunicación El cliente y el servidor tienen dos formas de comunicarse: la primera está preparada para la comunicación con la Base de Datos, mientras que la segunda está preparada para la comunicación con la aplicación Java. Como ya se ha mencionado anteriormente, y como se puede observar en la Figura 6.2, la comunicación con la Base de Datos se realiza a través de un chero PHP, al cual se le envían los datos por método GET. Éste los recoge y los compara con los que hay en Base de Datos. Tras comprobarlo devuelve al cliente si los resultados son positivos o negativos. 6.2. Comunicación 33 Figura 6.2: Comunicación Cliente con BBDD Figura 6.3: Comunicación Cliente con la aplicación Java Para la comunicación con la aplicación Java se usa un socket que conecta ambas aplicaciones (Figura 6.3), al establecer la conexión con el socket se conecta con la aplicación Java y le envía los datos para generar la ruta. La aplicación generará la ruta según los datos recibidos y tras generarla usará el socket para devolver la ruta en formato de lenguaje natural. Por último la aplicación cerrará la conexión con el socket dando así por nalizada la petición por el cliente y se volvería a congurar en modo de espera del siguiente socket. 40 Capítulo 7. Diseño del cliente destino. Una vez hecha la consulta se volverá a iniciar el bucle con los nuevos cuadrantes. Por el contrario si el usuario efectivamente está en la ruta se muestra por pantalla o por voz en función de la discapacidad la instrucción de la siguiente posición a la que el usuario deberá ir. Al llegar a la posición indicada se proporcionan las siguientes instrucciones necesarias para llegar al siguiente punto. La Figura 7.5 muestra el diagrama de las clases Acelerómetro, Login, Registro, Menu, Wis, Medir e Indicar destino. Figura 7.5: Clases principales del cliente. 7.3. Diagramas de casos de uso 41 Las interfaces grácas de la aplicación están representadas a través de archivos XML lo cuales se encuentran dentro del paquete res y dentro de este se encuentran en la carpeta layout , ruta genérica de Android para almacenar las interfaces grácas. 7.3. Diagramas de casos de uso En esta sección se muestran los diagramas de caso de uso para el caso de un administrador y de un usuario normal. La Figura 7.6 muestra el diagrama para el caso del usuario, y la Figura 7.7 muestran el caso del administrador. El caso de uso del usuario muestra las posibles funciones que puede llevar a cabo, siendo estas mas limitadas que las opciones para el caso de uso del administrador, el cual puede realizar las mismas funciones que el usuario además de otras funciones como medir intensidades, ver los acelerómetros y ver las redes wi-. El usuario normal solo cuenta con las funciones de Indicar destino, Mostrar la posición en el mapa, y Cerrar sesión. Figura 7.6: Caso de uso usuario. 42 Capítulo 7. Diseño del cliente Figura 7.7: Caso de uso administrador. 7.4. Diagramas de secuencia En esta sección se muestran mediante diagramas de secuencia el ujo de ejecución de las principales funcionalidades de la aplicación. La Figura 7.8 muestra el diagrama de la función Login. En ella se aprecia que el usuario dispone de la opción de seleccionar la opción de registrarse, interactuando con la clase httpServices para realizar la conexión con la base de datos y con la clase Registro para rellenar los datos. En el caso de ya estar registrado solo se comprueba si el usuario introducido es correcto mediante una conexión con la base de datos utilizando la clase ya mencionada. La Figura 7.9 muestra el diagrama de la función Medir intensidades. Para llevar a cabo esta funcionalidad se hace uso de la clase medir que proporciona la interfaz necesaria para que el usuario introduzca las coordenadas de la posición que se quiere registrar. La clase WPS es la encargada de recoger la información de las redes wi- detectadas por el dispositivo. Por último se envía la información a la base de datos haciendo uso una vez mas de la clase httpServices para ello. La Figura 7.10 muestra el diagrama de la función Posición en el mapa. La clase posición se encarga de mostrar el mapa de la planta en la que se encuentre el usuario y la información del lugar exacto donde se encuentra, para ello utiliza las clases ThreadDatos y ThreadUbicación, encargadas de conseguir esta información. La posición mostrada se recalcula constantemente al realizar cualquier movimiento sobre la pantalla. 7.4. Diagramas de secuencia 43 Figura 7.8: Diagrama de secuencia Login. Figura 7.9: Diagrama de secuencia Medir intensidades. En último lugar, La Figura 7.11 muestra el diagrama de la función Indicar destino.La clase Indicar destino es la encargada de solicitar el destino y una vez introducido solicitar todos los datos necesarios para indicar la ruta. Primeramente se necesita la localización inicial del dispositivo y para ello se usa la clase WPS de forma similar que para la función posición en el mapa. 44 Capítulo 7. Diseño del cliente Figura 7.10: Diagrama de secuencia Posición en el mapa. Una vez calculada la posición se envían los datos al servidor mediante la clase Client que se encarga también de almacenar la ruta devuelta por el servidor. Una vez obtenida la ruta la clase indicar destino va mostrando la ruta al usuario según la va necesitando. Esta clase funciona con un Timer , que ejecuta el método calcularRuta cada segundo para comprobar la posición del usuario y seguir mostrando una ruta correcta. Figura 7.11: Diagrama de secuencia Indicar destino. 7.5. Manual de usuario 45 7.5. Manual de usuario En esta sección se explica como usar la aplicación, tanto desde el punto de vista de los usuarios normales, como el de los administradores. Se detallará como usar cada pantalla tanto si el usuario sufre discapacidad visual o auditiva como si no padece ninguna, ya que la aplicación es útil también para personas sin discapacidad. 7.5.1. Pantalla de inicio de la aplicación Esta pantalla, que podemos apreciar en la gura 7.12 es la de inicio de la aplicación que nos da la posibilidad de entrar al menú rellenando los campos usuario y contraseña si el usuario se ha registrado previamente, o si por el contrario el usuario quiere darse de alta para poder usar la aplicación se pulsará el botón Registrarse. Respecto a la adaptación para personas con discapacidades, nada más iniciar la aplicación se reproducirá una voz que preguntará por voz al usuario si tiene discapacidad visual y le indicará que ha de decir y cuando para poder interactuar con esta pantalla, ya sea por voz o a través de las teclas físicas del dispositivo. 7.5.2. Pantalla de registro de la aplicación Esta pantalla (Figura 7.13) permite a un usuario darse de alta en nuestra base de datos. Se solicita la discapacidad y en caso de que la haya, se pide que seleccione en una lista los obstáculos que puede superar, ya sean escaleras, ascensores, puertas o rampas. Si se ha llegado a esta pantalla través de un comando de voz se asume que el usuario es invidente y se empiezan a solicitar los datos por voz, como si de una conversación se tratase. Una vez rellenos todos los datos, se pulsará el botón Aceptar y se volverá a la pantalla de inicio para realizar el inicio de sesión y poder empezar a usar la aplicación. 7.5.3. Menú principal Existen dos menús en la aplicación, una para usuarios y otro para administradores. Los usuarios solo dispondrán de opciones relacionadas con el posicionamiento y la sesión. En concreto tendrán la opción de indicar un destino para generar las instrucciones hasta el punto indicado, mostrar la posición en el mapa del edicio, o cerrar sesión. Los administradores contarán además de con las opciones descritas, con otras opciones necesarias para el desarrollo de la aplicación y para el mapeo 46 Capítulo 7. Diseño del cliente Figura 7.12: Inicio de la aplicación. Figura 7.13: Pantalla de registro. del edicio, como son: ver los acelerómetros o medir intensidades de las señales wi-. Todas estas opciones se detallan en los siguientes puntos. 7.5.4. Menú para Usuarios Esta pantalla consiste básicamente en un menú como se puede apreciar en la Figura 7.14 que muestra las opciones principales de GuiDIn: Indicar destino, Posición en el mapa, y Cerrar sesión. Las opciones son leídas por la aplicación si el usuario es discapacitado visual, y tendrá la opción de seleccionarlas mediante las teclas de volumen y la tecla de botón atrás. El botón Subir volumen permite seleccionar Indicar destino, el de Volumen abajo permite seleccionar Posición en el mapa, y por último la tecla de botón atrás permite volver a la página de inicio cerrando la sesión. 7.5.4.1. Indicar destino Ésta es la primera opción del menú de usuarios la cual permite generar las instrucciones necesarias para llegar al destino indicado. El destino se solicita por voz o teclado en función de la discapacidad del usuario, y las instrucciones se muestran por pantalla o las lee la aplicación también en función de la discapacidad del usuario. Posee una interfaz muy sencilla como se puede ver en la Figura 7.15 7.5. Manual de usuario 47 Figura 7.14: Menú de usuario Figura 7.15: Pantalla de indicar destino 48 Capítulo 7. Diseño del cliente 7.5.4.2. Posición en el mapa La función de esta pantalla (Figura 7.16) es mostrar el mapa de la planta donde se encuentra el usuario e indicarle donde se encuentra, para que le sirva para orientarse y como ayuda para la guía. Si el usuario sufre discapacidad visual se le indicará por voz donde se encuentra. 7.5.4.3. Cerrar sesión Esta opción cierra la sesión del usuario y nos devuelve a la pantalla de inicio de la aplicación. 7.5.5. Menú para Administradores Como se dijo al inicio de esta sección, los administradores contarán con más opciones en el menú de la aplicación. En la Figura 7.17 se pueden observar todas las opciones. A continuación se detallan cada una de ellas. Figura 7.16: Pantalla de posición en el mapa. Figura 7.17: Menú de administradores. 7.5. Manual de usuario 49 7.5.5.1. Actividad wi- Esta opción nos lleva a una primera pantalla (Figura 7.18) en la que se muestra la lista de repetidores wi- que está recibiendo el dispositivo en el momento que se selecciona esta opción. Si se pulsa en una de ellas la aplicación nos lleva a otra pantalla en la que veremos la red seleccionada en detalle (Figura 7.19). En concreto se muestra el SSID, el BSSID, la frecuencia y la potencia de la red wi- seleccionada. Figura 7.18: Pantalla de actividad wi- Figura 7.19: Pantalla de detalle de red wi- 7.5.5.2. Ver acelerómetros Esta pantalla (Figura 7.20) muestra la lista de acelerómetros con los que cuenta el dispositivo y muestra el valor de cada uno de ellos. 7.5.5.3. Medir intensidades Esta función es de gran utilidad para los administradores ya que permite almacenar toda la información recibida por el dispositivo de las redes wi- de las que recibe señal. El procedimiento que hay que seguir es indicar el punto en el que se está del edicio a través de los botones + y - correspondientes con los ejes, x, y, z como se puede apreciar en la Figura 7.21 y posteriormente 56 Capítulo 8. Diseño del servidor En el XML de los edicios se tiene que indicar todas las plantas del mismo y hay que poner el nombre de la planta el nombre del chero XML que contendrá la información de la planta, pero sin la extensión XML. Ejemplo XML de una planta: <? xml version =' 1.0 ' encoding='UTF − 8'?> <planta> <Z>1</Z> <estancia id=" pasillo1 "> <tipo>PASILLO</tipo> <cuadrantes> <cuadrante idc="0"> <SE> <X>3</X> <Y>13</Y> </SE> <NW> <X>0</X> <Y>16</Y> </NW> <conectado> <norte> − 1</norte> <sur> − 1</sur> <este>1</ este> <oeste> − 1</oeste> </conectado> <objetos> <objeto id="objeto1"> <tipo>mesa</tipo> <total>f alse</ total> <posicion> <X>1</X> <Y>1</Y> </posicion> </objeto> <objeto id="objeto2"> <tipo>mesa</tipo> <total>f alse</ total> <posicion> <X>1</X> <Y>2</Y> </posicion> </objeto> . . . </objetos> </cuadrante> 8.4. Aplicación Java 57 <cuadrante idc="1"> <SE><X>6</X> <Y>13</Y> </SE> <NW><X>3</X> <Y>16</Y> </NW> <conectado> <norte> − 1</norte> <sur> − 1</sur> <este>2</ este> <oeste>0</oeste> </conectado> <objetos> <objeto id="objeto1"> <tipo>fuente</tipo> <total>f alse</ total> <posicion> <X>1</X> <Y>3</Y> </posicion> </objeto> </objetos> </cuadrante> . . . </cuadrantes> </estancia> . . . </planta> En este elemento tenemos una planta por chero, la planta esta dividida por estancias, y a su vez, las estancias están divididas por cuadrantes. Las estancias se identican por ids al igual que los cuadrantes. La lista de elementos que contiene este chero, que corresponde a una planta determinada, es: Z: Altura de la planta, única por chero también Estancia: División principal del mapa, cada planta puede tener n estancias. • Cuadrante: Cada estancia tendrá un numero n de cuadrantes 58 Capítulo 8. Diseño del servidor ◦ SE: Posición X e Y que indica la esquina Sur-Este del cuadrante ◦ NW: Posición X e Y que indica la esquina Nor-Oeste del cuadrante ◦ Conectado: Índica el id del cuadrante con el que esta conectado y en que dirección. ◦ Objetos: Lista de objetos que contiene el cuadrante.  Objeto: Objeto concreto identicado por id  Tipo: Tipo de objeto que estamos tratando  Total: Si es un obstáculo total o no.  Posición: Posición del objeto en el cuadrante 8.4.2. Java La aplicación Java tiene la estructura que se muestra en la Figura 8.6 Figura 8.6: Diagrama de clases Java Main: Clase encargada de ejecutar la aplicación. Cuadrantes: Clase que engloba toda la información de un cuadrante. Estancias: Clase que engloba toda la información de una estancia. GenrarRuta: Clase con los métodos para generar la ruta óptima. LectorDestino: Transforma el destino escrito a un cuadrante concreto. 8.4. Aplicación Java 59 ListaCuadrantes: Contiene una lista de cuadrantes. Objeto: Clase que engloba la información relativa a un objeto. Posicion: Clase que simboliza una posición en el mapa. TipoObjeto: Enumerado con el tipo de objetos que tenemos. Persona: Clase que engloba la información de una persona. CargaXML: Clase encargada de leer los XML y transformarlo a las clases correctas. Edicio: Clase que engloba un edicio entero. 8.4.2.1. Diagramas de secuencia En la Figura 8.7 se representa la secuencia que sigue el proceso encargado de generar las ruta. La conexión entre el servidor y la aplicación cliente se realiza mediante un socket (Wikipedia, a) en la clase Main, la cual espera hasta que una aplicación se conecta y va esperando hasta que recibe toda la información necesaria. Una vez que recibe toda la información forma un elemento de tipo Persona, el cual contiene la posición inicial, el destino y la información del edicio. Con toda esta información la clase Persona genera la ruta. Para hallar el camino optimo usa una búsqueda por anchura generando un árbol de búsqueda con la información del edicio, siendo el padre el inicio y el objetivo el destino. El método de búsqueda es parte de lo que estaba implementado del año anterior. En esta versión hemos añadido el tipo de obstáculos y comprobamos antes de pasar de un cuadrante a otro si puede pasar por ese obstáculo. Si no es así se toma como que no hay camino entre esos dos cuadrantes y seguirá buscando. Una vez obtenido la ruta óptima lo transformamos a un camino legible a través de la clase GeneraRuta. Por último se utiliza el socket creado al principio para enviar por este medio la ruta de forma legible al dispositivo. 60 Capítulo 8. Diseño del servidor Figura 8.7: Secuencia Calcula Ruta Capítulo 9 Conclusiones y trabajo futuro 9.1. Descripción de los resultados obtenidos El primer objetivo que pretendíamos cumplir era conseguir localizar a un individuo dentro del edicio de la Facultad de Informática. Este objetivo a supuesto un reto debido a diversos problemas relacionados con la red wi- de la Facultad de informática. Sin embargo, nalmente este objetivo ha sido cumplido y se ha podido posicionar un dispositivo que se encuentre dentro del edicio mencionado. Otro de los objetivos primarios fue el de conseguir adaptar la aplicación a personas con discapacidad visual o auditiva. Para ello se han hecho modicaciones tanto en el dispositivo móvil como en el servidor, todas ellas destinadas a lograr este objetivo. Todo ello ha sido añadido al proyecto satisfactoriamente y el resultado ha sido una aplicación completamente accesible para personas con alguna de estas discapacidades mencionadas. Una de nuestras pretensiones era la de mejorar el posicionamiento. Esta mejora no ha sido posible llevarla a cabo. Sin embargo esto no supone un impedimento a la hora de usar la aplicación ya que el margen actual es sucientemente preciso. Por último se propusieron dos objetivos secundarios, no por ello menos importantes, que servían como mejora de la aplicación. Dichos objetivos son, por un lado el incremento de destinos a los que se puede llegar con la aplicación y por otro la mejora de las instrucciones guía proporcionadas. Este objetivo es importante si tenemos en cuenta el tipo de usuarios a los que va dirigida la aplicación. El lenguaje utilizado para proporcionar las instrucciones es más humano y conexo, además cada instrucción es dada en el momento en el que se completa la instrucción anterior. 61 62 Capítulo 9. Conclusiones y trabajo futuro 9.2. Conclusiones La mayor parte de resultados obtenidos han sido positivos ya que se han alcanzado la mayor parte de los objetivos que se habían propuesto. La accesibilidad para personas con discapacidad visual o auditiva ha sido realizada satisfactoriamente. Por otro lado, las instrucciones son ahora proporcionadas en lenguaje mas natural. Siempre queda cierto margen de mejora en este aspecto, pero respecto a la versión anterior se puede apreciar dicha mejora. En siguiente lugar, y relativo a la propuesta de incremento de destinos, podemos concluir que este objetivo ha sido claramente cumplido ya que para la versión anterior sólo se contemplaban un par de destinos y actualmente se contemplan la mayor parte de destinos posibles dentro de las zonas mapeadas del edicio. En último lugar, el posicionamiento de un dispositivo ha sido conseguido con la misma precisión que se consiguió en versiones anteriores. Por lo tanto, se ha conseguido posicionar pero no ha sido posible mejorar el margen de precisión. 9.3. Trabajo Futuro Tal y como está diseñada la aplicación GuiDIn, es muy fácil reutilizar la aplicación para cualquier edicio público. Por lo tanto, sería una opción viable extender la aplicación a todas las facultades de la Universidad Complutense, o incluso a algún museo o centro público, lugar donde sería de gran utilidad una aplicación de estas características. El sistema de mapeo implementado para representar los edicios es sencillo y fácil de replicar. Otra posible ampliación sería añadir más discapacidades ya que actualmente solo se contempla la discapacidad visual y la auditiva, siendo fácilmente implementable añadir cualquier discapacidad. Una gran mejora sería añadir una interfaz de guía similar a un GPS para exteriores, algún tipo de echa o indicador que funcione sobre el mapa o utilizando realidad aumentada sobre el propio edicio. Esta aplicación podría llegar a ser realmente útil si se llegase a ampliar la funcionalidad de guía también en exteriores, utilizando por supuesto el GPS del dispositivo. De esta forma la guía sería completa y podría guiarse a una persona, con discapacidad o, no desde cualquier punto hasta el interior de un edicio. Por ultimo, para poder llegar a un número de personas mayor, se podría añadir la opción del multilenguaje, y así llevar la aplicación a lugares de habla no hispana. Capítulo 10 Conclusions and future work 10.1. Description of results The rst goal we wanted to accomplish was to locate an individual within the building of the Facultad de Informática. This goal has been a challenge because of various problems related to the wi- network at the Facultad de Informática. Eventually, however, this objective has been achieved and has been able to position a device that is within the listed building. Another of the primary objectives was to get to adapt the application to persons with visual or hearing disability. This has required to made changes to both, the mobile and server, all aimed at achieving this goal. This has been successfully added to the project and the result is a fully accessible for people with disabilities mentioned in this application. One of our aims was to improve the position. This improvement has not been possible to carry it out. However this is not an impediment to using the application because the current margin is suciently precise. Finally, two secondary objectives that served as improved application implementation were proposed. These objectives are, on the one hand the increase in destinations that can be reached with the application and on the other improving the guidance instructions provided. This goal is important if we take into account the type of users that the application is directed. The language used to provide instructions is  human  and connected, each instruction is also given at the time that the previous instruction is completed. 10.2. Conclusions Most results have been positive since we have achieved most of the goals proposed. Accessibility for people with visual or hearing disability has been performed successfully. 63 64 Capítulo 10. Conclusions and future work Moreover, the instructions are now given in more natural language. There is always some room for improvement in this respect, but the improvement respect to the previous versions, can appreciated. In the next place, and on the proposed increase of destinations, we can conclude that this objective has been clearly fullled regarding the previous version, in which only have a few destinations are watched and currently it have the most possible destinations contemplated within the zones mapped the building. Finally, the positioning of a device has been achieved with the same precision as was achieved in previous versions. Therefore, it has managed to position but has not been possible to improve the margin of accuracy. 10.3. future work As the GuiDIn application is designed, it is very easy to reuse the application to any public building. Therefore, would be a viable option to extend the application to all the faculties of the Universidad Complutense, or even to a museum or public institution, where it would be very useful. The mapping system implemented to represent the buildings is simple and easy to replicate. Another possible extension would be to add more disabilities, currently only the visually impaired and hearing are contemplated, being easily implementable to add any other disability. A big improvement would be to add a user interface similar to a GPS guide for outdoor, some kind of arrow or indicator that works on the map or using augmented reality on the building itself. This application could become really useful if you were to extend the functionality of guide also outdoors, using of course the GPS device, the guide would be complete and would be guided to a person, disabled or not from any point to the interior of a building. Finally, in order to reach a larger number of people, you could add the option of multilingual, and thus lead to the application of non-Spanish speaking places. Capítulo 11 Trabajo individual Al ser un proyecto pensado para dos personas hemos intentado repartir el trabajo de la forma más justa posible, trabajando más un miembro del grupo cuando el otro estaba más ocupado y viceversa. Una parte de este proyecto ha sido hecha de forma conjunta, pero también hay partes que se han hecho individualmente. A continuación se explica que ha hecho cada componente de la pareja. 11.1. Jorge Almendros Fresnillo Nada más empezar quisimos entender en qué consistieron los proyectos anteriores, ya que como se ha dicho antes ésta es la cuarta versión de un proyecto que lleva desarrollándose durante los últimos cuatro años en la Facultad de Informática. Por lo tanto nuestra primera tarea consistió en leer individualmente las memorias de los trabajos previos y posteriormente observar y entender el código generado en la versión anterior principalmente para ver qué podríamos reutilizar para esta versión, tanto en la parte del cliente como en el servidor. Hecho esto, el siguiente paso fue migrar la parte que se ha reutilizado, adaptarla a la versión de Android utilizada y aplicarle nuestras mejoras. Jorge se encargó de gran parte del proceso de migración, debido a que se ha reutilizado una parte importante del código relativa al posicionamiento y a la medición de intensidades. Para hacer la adaptación a personas con discapacidad se plantearon varias opciones, pero al no estar seguros si lo que nosotros pensábamos que era lo correcto era la mejor opción decidimos crear unas encuestas para que las realizasen posibles usuarios de la aplicación que sufriesen alguna de las dos discapacidades contempladas. Se crearon dos formularios, uno para cada discapacidad en los que se hacían preguntas acerca del uso de la aplicación y sobre como debía proporcionarse la guía. Los resultado fueron tenidos en cuenta a la hora de desarrollar la aplicación. Jorge fue el encargado de crear 65 72 Apéndice B. Extensión de la aplicación Figura B.1: Lanzamiento de la ejecución en consola dor, como el puerto de escucha. Para ello, importamos el proyecto en Android Studio, o Eclipse y nos vamos al paquete sockets y en la clase Client.java modicaremos las siguientes variables: String adresaServer ='dirección servidor'; int PORT = XX; Ha de ser el mismo que el establecido en la aplicación servidor B.2. Crear base de datos Como se explica en el capítulo referente a la Base de Datos (8.2), es necesario disponer de una base de datos, tanto para almacenar los usuarios como los datos de las mediciones de intensidad wi-. Esta base de datos debe mantener la estructura detallada en el dicho capítulo. Por otra parte también será necesario alojar en el servidor los archivos php necesarios para la conexión entre la aplicación y la base de datos. B.3. Enlace cliente - base de datos El cliente debe modicar los archivos que contienen la información de la conexión con la base de datos, en concreto hay que modicar la clase HttpServices que se encuentra en el paquete http. Se modicarán las variables: String Host: se le asignará la dirección IP del hosting elegido. String Port: contendrá el puerto del hosting B.4. Medir intensidades wi- 73 String urlServer: contendrá algo similar a 'http://direccionWEB'; Por otra parte también será necesario modicar todos los archivos php que deben estar alojados en el servidor. Se modicará la variable conexión y quedará de la siguiente forma: $conexion = mysql_connect('dir IP',`usuario BBDD','contraseña BBDD'); B.4. Medir intensidades wi- Una vez creada la base de datos ya es posible utilizar la aplicación cliente para llevar a cabo la medición de intensidades wi-. El uso de esta funcionalidad se detalla en el Capítulo 7.5.5.3. Será necesario denir un eje de coordenadas x,y,z sobre el edicio que se quiera mapear, siempre siendo el eje z el indicador de planta en la que se está midiendo la intensidad. Cuanto mayor sea el número de intensidades medidas mayor será la precisión obtenida por la aplicación B.5. Creación de los XML relativos a la estructura del edicio El edicio está representado mediante unos cuantos archivos XML. En concreto debe existir uno que dena el edicio (edicio.xml) y adicionalmente un archivo por cada planta que se quiera representar. El XML del edicio tiene la función de índice, basta con añadir la planta que queramos incluir. Según esta representación existirán los archivos nombreFichero.xml que contendrán las descripción de cada planta. La estructura de las plantas se encuentra en la sección de XML anteriormente mencionada. Estos cheros deberán estar alojados en el servidor, dentro de una carpeta llamada xml, en el mismo directorio en el que se encuentre la aplicación .jar. Para ver un ejemplo del formato de los XML así como información de todos los campos disponibles se puede ver la sección propia de los cheros en el capitulo del servidor 8.4.1. B.6. Establecer destinos Todos los posibles destinos dentro de un edicio son almacenados en un chero JSON. La estructura es la siguiente: [ { ' lugar ' : ' sala de juntas ' , ' cuadrante ' : '14 ' ,} , 74 Apéndice B. Extensión de la aplicación { ' lugar ' : ' aula 13 ' , ' cuadrante ' : '15 ' ,} ] Lugar representa la estancia a la que nos referimos. Cuadrante hace referencia al identicador del cuadrante en el que se encuentra el destino. El chero ha de llamarse destinos.json y estará alojado en el servidor, en el mismo directorio que la aplicación .jar. B.7. Compilar y ejecutar la aplicación Por último, con la aplicación servidor ya compilada y corriendo en un .jar, se compilará la aplicación cliente con el Eclipse o el Android Studio y se generará el archivo .apk el cual será enviado al dispositivo Android donde se instalará y ejecutará. B.8. Añadir discapacidades Añadir discapacidades es relativamente sencillo. En la parte del cliente habría que añadir la posibilidad de que el usuario al registrarse pueda seleccionarla. Además si las formas ya existentes en las que se muestra la información de la ruta no se adaptan a la nueva discapacidad habría que añadir esta nueva funcionalidad. Se modicaría la clase indicarDestino.java en la que se tendría en cuenta la discapacidad para generar la información de la manera más adecuada a la discapacidad. En el servidor no es necesario hacer ninguna modicación, la ruta se genera igualmente en función de los superables que haya seleccionado el usuario y se adaptará perfectamente a la discapacidad. Apéndice C Formularios pasados a personas con discapacidades A continuación se muestra el formulario relleno por personas con discapacidad visual en la Figura C.1 y el formulario relleno por personas con discapacidad auditiva en la Figura C.2. Estos formularios han servido para obtener información relativa a cómo dar las instrucciones de guía, para poder adaptarlas lo máximo posible a cada discapacidad además de para conseguir información muy valiosa acerca de como puede utilizar un discapacitado visual o auditivo una aplicación móvil. 75 76 Apéndice C. Formularios pasados a personas con discapacidades Figura C.1: Formulario para personas con discapacidad visual. 77 Figura C.2: Formulario para personas con discapacidad auditiva. Bibliografía Arora, Sanjeev; Barak, B. (2009). Computational Complexity: A Modern Approach . Cambridge Press. Chen, Y. and Kobayashi, H. (2002). Signal strength based indoor geolocation . Proceedings of the IEEE International Conference on Communications. Cormen, T. H., Leiserson, C. E., Rivest, R. L., and Stein, C. (2001). Introduction to Algorithms . MIT Press and McGraw-Hill. Department of Energy Quality Managers, Software Quality Assurance Subcommittee (1999). Software risk management a practical guide. Oce of the Chief Information Ocee , In Press. E. López Mañas, F. J. Moreno y J. Plá Herrero (2010). Avanti: Sistema de asistencia a la evacuación de incendios. Google (2014). Google maps indoor. Google (2015a). Android. Google (2015b). Historia de android. Google (2015c). Texttospeech. Infsoft (2015). Infsoft. Mariana Martín-Calderín de la Villa (2013). Sistema de guía por voz en interiores. Matsudaira., K. (2012). Scalable web architecture and distributed systems. Oracle (2015). Mysql documentation. Redpin (2008). Redpin. Retana, J. A. C. (2010). Sistema de posicionamiento en interiores mediante balizas bluetooth . Universidad Ponticia Comillas Escuela tiécnica superior de ingeníeria. 79 80 BIBLIOGRAFÍA Richardson, L. S. R. (2007). RESTful web service . O'Reilly Media. Tamada, R. (2014). Android speech to text tutorial. Víctor Gutiérrez Rodríguez, Juan Diego Lozano Martín y Víctor Manuel Pose Murga (2014). Generador interactivo de instrucciones de guía sobre plataformas móviles. Wikipedia. Network socket. Wikipedia. Sistema de posicionamiento global. Wikipedia. Triangulación. Wikipedia. Wi-Fi positioning system. BIBLIOGRAFÍA 81 acr!