TFG_Francisco Jimenez Moral - Ruidera
Anuncio
UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA GRADO EN INGENIERÍA INFORMÁTICA TECNOLOGÍA ESPECÍFICA DE COMPUTACIÓN TRABAJO FIN DE GRADO ShoppingBeacon: Sistema asistencial en superficies comerciales basado en posicionamiento en interiores Francisco Jiménez Moral Septiembre, 2015 S HOPPING B EACON : S ISTEMA ASISTENCIAL EN SUPERFICIES COMERCIALES BASADO EN POSICIONAMIENTO EN INTERIORES UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA Tecnologías y Sistemas de Información TECNOLOGÍA ESPECÍFICA DE COMPUTACIÓN TRABAJO FIN DE GRADO ShoppingBeacon: Sistema asistencial en superficies comerciales basado en posicionamiento en interiores Autor: Francisco Jiménez Moral Director: Dr. Ramón Hervas Lucas Septiembre, 2015 Francisco Jiménez Moral Ciudad Real – Spain E-mail: [email protected] c 2015 Francisco Jiménez Moral Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios son reclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, y cuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos en mayúsculas o como nombres propios. i TRIBUNAL: Presidente: Vocal: Secretario: FECHA DE DEFENSA: CALIFICACIÓN: PRESIDENTE Fdo.: VOCAL SECRETARIO Fdo.: Fdo.: iii Resumen En un mundo en constante evolución en el que las posibilidades de conexión aumentan año tras año, ya que la mayor parte de la población dispone de acceso a redes inalámbricas, existe un gran potencial colectivo y económico en los servicios basados en la localización, que aún no han sido aprovechados. Debido a la fuerte expansión en el mercado de las redes inalámbricas y del GPS, emerge la necesidad de desarrollar servicios de localización en interiores (denominados entornos “indoors”, de interior), ya que la señal de GPS no llega dentro de los edificios. Estos servicios de localización resultan muy útiles cuando se quiere localizar algo o a alguien en el interior de un edificio y dado que pasamos una gran parte de nuestro tiempo en interiores (el 90 % según un artículo de Nokia [Des12]) es indudable la utilidad de este tipo de soluciones. En base a la problemática de la localización indoor, se propone un sistema que se basa en la recepción de señales que permitan localizar al usuario dentro de un edificio en un mapa previamente facilitado y con unos puntos a recorrer para guiar al usuario hasta ellos. En concreto las superficies comerciales, que debido a sus estrategias de marketing, se encargan de redistribuir los productos en las estanterías colocándolos en nuevas posiciones, cada cierto tiempo. Como consecuencia a estos cambios de posición, surgen esas innumerables vueltas que se dan por los pasillos para encontrar todo lo que quiere el usuario. A raíz de estas motivaciones surge la propuesta del presente Trabajo Fin de Grado. Se plantea diseñar y desarrollar un sistema software asistencial bajo la plataforma iOS, para entornos comerciales mediante localización indoor basado en redes inalámbricas. Dicho sistema, se centrará en un organizador de compras para una determinada superficie comercial que esté adaptada mediante el uso de un mapa que muestre la distribución del edificio. De esta manera el usuario tendrá que seleccionar los productos del establecimiento para después ser ubicado y en base a esta localización ser guiado siguiendo un orden de manera que el usuario pase por todos los productos escogidos realizando la ruta de menor coste y ahorrando tiempo y esfuerzo. V Abstract In a world in a constant evolution, where connection availability increases year to year since most of the population has access to wireless networks, there exist a great collective and economical potential in services based on location awareness, from which the most of it has not been made yet. Due to the great expansion in the market of wireless networks and GPS based technologies, the need of developing services based on indoor location awareness has arisen, since GPS signal does not reach the inside of buildings. These location services come to be of great usefulness when something or someone is wanted to be located inside a building and, since we spend a large deal of our time in indoor environments (about 90 % according to an article published by Nokia [Des12]), the utility of this kind of solutions is out of any doubt. Given the problematics of indoor location, thereupon the development of a system is proposed, this being based on the reception of signals which would allow the user to be located inside a building, over the surface of a map previously provided and given a series of checkpoints, along of which the user should be guided. This will be applied to the specific case of shopping centers, which from time to time redistribute the eventual location of their products, according to their marketing strategies. As a consequence of these location changes, the customer is bound to indefinitely roam along the hallways in order to find everything she is in search of. As a result of these motivations the proposal of this Final Degree Project is laid out. The design and development of an assistance software system on the platform iOS is outlined, intended to commercial environments and based on indoor location awareness via wireless networks. Such a system will focus in a shopping assistant for a certain shopping center, which should be adapted through the use of a map which depicts the building’s distribution. This way, the user will select those products of the shopping center she wants to purchase, thereafter being located and guided on such a way that the user picks all of the chosen products, performing the minimal cost route and thus saving time and effort. VII Agradecimientos En este pequeño espacio me gustaría dar las gracias a todas las personas que de una u otra manera han contribuido a que pueda llegar hasta aquí. Por ello, primero me gustaría agradecerles todo esto a aquellas personas que me han brindado esta oportunidad, por su cariño constante, por apoyarme y creer siempre en mí, por todo lo bueno que me han regalado durante el transcurso de mi vida; estoy hablando de mis queridos padres, Francisco y Antoñita. En segundo lugar agradecer al resto de familiares y a mi hermano su confianza en mí, en particular a mi hermano, por todas las conversaciones y sinsentidos nuestros que hacen que ahora no pare de reír, especialmente al recordar los días de vendimia. Gracias a Alba, por su apoyo, por su paciencia, por nuestras historias, por la fuerza que me aporta día a día y especialmente por animarme en cualquier situación. A todos y cada uno de mis compañeros durante esta experiencia universitaria, especial mención se merecen Rubén, iSergio, Anibla, Edu y Javi. Nunca pensé que pudiera reírme tanto viendo un perro conduciendo, siendo testigo de la fusión en directo delante de un reptiliano, el viaje valhállico pactado, el gran cargo de mantener la identidad secreta de MH; podría seguir dando motivos, pero me temo que no terminaría. . . Gracias por todos los momentos que hemos tenido y por brindarme una mano siempre que lo he necesitado. Por último, y no menos importante agradecerle también a mi tutor en este proyecto, Ramón Hervás, por prestarse de forma totalmente desinteresada a la dirección de este proyecto y corregir cual ninja toda la documentación durante el verano cuando mas apurado estaba. A todos vosotros, muchas gracias de corazón. Francisco Jiménez Moral IX Para mis padres, Francisco y Antoñita. xi Índice general Resumen V Abstract VII Agradecimientos IX Índice general XIII Lista de tablas XVII Índice de figuras XIX Índice de listados XXIII 1. Introducción 1 1.1. Contexto del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Evolución de los smartphones . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Elección del SO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.5. Propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.6. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Objetivos y Herramientas 11 2.1. Visión General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2. Lista de objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3. Herramientas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.1. Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.3. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Antecedentes 19 3.1. Trabajos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIII 19 3.2. Apps para realizar listas de la compra . . . . . . . . . . . . . . . . . . . . 19 3.2.1. Análisis Comparativo App para realizar listas de la compra . . . . . 27 3.3. Apps para localización en interiores . . . . . . . . . . . . . . . . . . . . . 29 3.3.1. Análisis Comparativo App para localización en interiores . . . . . . 37 3.4. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4. Arquitectura 41 4.1. Arquitectura General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2. Patrones de Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.1. Delegado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 4.2.2. Target-Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4.2.3. Modelo-Vista-Controlador (MVC) . . . . . . . . . . . . . . . . . . 45 4.3. Posicionamiento en móviles . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.4. Gestión y Almacenamiento . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.4.1. Recuperación de datos externos . . . . . . . . . . . . . . . . . . . 51 4.4.2. Uso de Core Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.5. Ubicación y Guiado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.5.1. Módulo de Comunicaciones . . . . . . . . . . . . . . . . . . . . . 62 4.5.2. Módulo de Tratamiento de Señal . . . . . . . . . . . . . . . . . . . 68 4.5.3. Módulo de Filtrado de Señal . . . . . . . . . . . . . . . . . . . . . 71 4.5.4. Módulo de Posicionamiento . . . . . . . . . . . . . . . . . . . . . 77 4.5.5. Módulo de Enrutamiento y Guiado . . . . . . . . . . . . . . . . . . 81 5. Métodos de trabajo 101 5.1. Metodología de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 101 5.2. Evolución del desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 5.3. Iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6. Resultados 115 6.1. Primera etapa: Análisis del comportamiento de la señal BLE . . . . . . . . 115 6.2. Segunda etapa: Análisis de RRSI . . . . . . . . . . . . . . . . . . . . . . . 117 6.3. Tercera etapa: Desarrollo del experimento . . . . . . . . . . . . . . . . . . 118 6.4. Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 6.5. Modulos funcionales de la aplicación . . . . . . . . . . . . . . . . . . . . . 125 7. Conclusiones y Propuestas 131 7.1. Objetivos Alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv 131 7.2. Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 7.3. Conclusión Personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 A. Fundamentos sobre tecnologías de localización 139 A.1. Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 A.2. Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 A.3. UWB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 A.4. ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 A.5. RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 A.6. Justificación de alternativa seleccionada . . . . . . . . . . . . . . . . . . . 144 B. Calibración del dispositivo iBeacon 149 C. Contenido del soporte fisico adjunto 151 Referencias 153 xv Lista de tablas 3.1. Comparativa de las aplicaciones existentes que permiten realizar la lista de la compra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.2. Comparativa de las aplicaciones que permiten realizar localizacion Indoor . 39 3.3. Características de ShoppingBeacon . . . . . . . . . . . . . . . . . . . . . . 40 4.1. Estructura del Mapa de Potencias . . . . . . . . . . . . . . . . . . . . . . . 80 4.2. Representación del grafo a través de sus aristas . . . . . . . . . . . . . . . 85 4.3. Representación del grafo a través de sus vertices . . . . . . . . . . . . . . . 86 4.4. Matriz de Adyacencia para el ejemplo del cálculo del camino minimo . . . 91 4.5. Matriz de Adyacencia para el ejemplo del cálculo del camino minimo . . . 95 6.1. Resultados de estudio de valores según el plano de orientación. . . . . . . . 117 6.2. Medición de fluctuación de RSSI con diferentes intervalos de repetición de pulsos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.3. Comparativa de proximidad real-media. . . . . . . . . . . . . . . . . . . . 120 6.4. Comparativa de proximidad real-media. . . . . . . . . . . . . . . . . . . . 123 7.1. Características de ShoppingBeacon . . . . . . . . . . . . . . . . . . . . . . 132 A.1. Estándares de Wireless LAN. Figura extraida de [UPM]. . . . . . . . . . . 141 A.2. Tabla Comparativa tecnologías UWB. Tabla extraída de [UPM] . . . . . . 142 A.3. Comparativa de tecnologías de RF. . . . . . . . . . . . . . . . . . . . . . . 145 XVII Índice de figuras 1.1. Predicción de ventas globales de smartphone hasta 2019 . . . . . . . . . . 3 1.2. Tiempo diario de uso de los dispositivos de Apple . . . . . . . . . . . . . . 4 1.3. Tiempo que navegan los usuarios de Android frente a los usuarios de iOS . 5 1.4. Compras realizadas desde tablets . . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Estadísticas de descargas e ingresos de la App Store y Google Play . . . . . 6 1.6. Reparto mundial de empleo en iOS y Android . . . . . . . . . . . . . . . . 7 2.1. Visión General de la Arquitectura del Sistema . . . . . . . . . . . . . . . . 12 3.1. App Shopping List. Lista inicial . . . . . . . . . . . . . . . . . . . . . . . 20 3.2. App Shopping List. Añadir Producto . . . . . . . . . . . . . . . . . . . . . 20 3.3. App LiShop. Lista Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.4. App LiShop. Buscar Producto . . . . . . . . . . . . . . . . . . . . . . . . 21 3.5. App Buy Me a Pie. Creación de listas . . . . . . . . . . . . . . . . . . . . 22 3.6. App Buy Me a Pie. Lista Inicial . . . . . . . . . . . . . . . . . . . . . . . 22 3.7. App ShopShop. Añadir Producto . . . . . . . . . . . . . . . . . . . . . . . 23 3.8. App ShopShop. Mandar lista por correo . . . . . . . . . . . . . . . . . . . 23 3.9. App Lista. Lista Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.10. App Lista. Añadir Producto . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.11. App ShopIt. Lista Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.12. App ShopIt. Lista Final . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.13. App myShopi. Crear Lista Inicial . . . . . . . . . . . . . . . . . . . . . . . 26 3.14. App myShopi. Añadir Producto . . . . . . . . . . . . . . . . . . . . . . . 26 3.15. App Point Inside. Mapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.16. App Point Inside. Servicios disponibles . . . . . . . . . . . . . . . . . . . 29 3.17. App Wifarer. Guiado interior . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.18. App Wifarer. Servicios Ofrecidos . . . . . . . . . . . . . . . . . . . . . . . 30 3.19. App Wifarer. Servicios Ofrecidos . . . . . . . . . . . . . . . . . . . . . . . 30 3.20. Mapa interior aeropuerto de San Francisco. . . . . . . . . . . . . . . . . . 31 XIX 3.21. Adaptacion a gente invidente aeropuerto de San Francisco. . . . . . . . . . 31 3.22. App MIT Mobile. Guiado . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.23. App MIT Mobile. Servicios Ofrecidos . . . . . . . . . . . . . . . . . . . . 32 3.24. App Universidad de Granada. Servicios ofrecidos . . . . . . . . . . . . . . 33 3.25. App Universidad de Granada. Centros de la Universidad . . . . . . . . . . 33 3.26. App University of Alabama. Servicios ofrecidos . . . . . . . . . . . . . . . 34 3.27. App University of Alabama. Directorio de búsqueda . . . . . . . . . . . . . 34 3.28. App GuideURJC. Mapa de interior . . . . . . . . . . . . . . . . . . . . . . 35 3.29. App GuideURJC. Creación de rutas . . . . . . . . . . . . . . . . . . . . . 35 3.30. Localización Indoor dentro del supermercado Carrefour . . . . . . . . . . . 36 4.1. Modelo de arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . 42 4.2. Objetos pertenecientes al patrón MVC . . . . . . . . . . . . . . . . . . . . 46 4.3. Comunicación entre los objetos del MVC . . . . . . . . . . . . . . . . . . 47 4.4. Modelo Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.5. Diagrama entidad-interrelación . . . . . . . . . . . . . . . . . . . . . . . . 52 4.6. Descripción Funcional del módulo de Comunicaciones . . . . . . . . . . . 63 4.7. Estructura de una trama de un iBeacon sobre BLE. . . . . . . . . . . . . . 64 4.8. Diagrama de Secuencia del Módulo de Comunicaciones . . . . . . . . . . . 68 4.9. Descripción Funcional del módulo de Tratamiento de Señal . . . . . . . . . 69 4.10. Diagrama de Secuencia del Módulo de Tratamiento de Señales . . . . . . . 71 4.11. Descripción Funcional del módulo de Filtrado de Señal . . . . . . . . . . . 72 4.12. Fluctuación de la potencia de la señal . . . . . . . . . . . . . . . . . . . . 72 4.13. Rangos de proximidad a un iBeacon . . . . . . . . . . . . . . . . . . . . . 73 4.14. Diagrama de Secuencia del Módulo de Filtrado de Señal . . . . . . . . . . 77 4.15. Descripción Funcional del módulo de Posicionamiento . . . . . . . . . . . 78 4.16. Diagrama de Secuencia del Módulo de Posicionamiento . . . . . . . . . . . 81 4.17. Descripción Funcional del módulo de Enrutamiento . . . . . . . . . . . . . 82 4.18. Estructura de un Grafo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 4.19. Descripción Gráfica del problema . . . . . . . . . . . . . . . . . . . . . . 91 4.20. Recorrido Técnica Fuerza Bruta . . . . . . . . . . . . . . . . . . . . . . . 93 4.21. Recorrido Técnica Programación Dinámica . . . . . . . . . . . . . . . . . 97 4.22. Diagrama de Secuencia del Módulo de Enrutamiento . . . . . . . . . . . . 100 5.1. Evolución de los ciclos de desarrollo de Extreme Programming. Figura extraída de [Bec99] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 xx 5.2. Proceso de desarrollo: Iteración 1 . . . . . . . . . . . . . . . . . . . . . . . 110 5.3. Proceso de desarrollo: Iteración 2 . . . . . . . . . . . . . . . . . . . . . . . 110 5.4. Proceso de desarrollo: Iteración 3 . . . . . . . . . . . . . . . . . . . . . . . 111 5.5. Proceso de desarrollo: Iteración 4 . . . . . . . . . . . . . . . . . . . . . . . 111 5.6. Proceso de desarrollo: Iteración 5 . . . . . . . . . . . . . . . . . . . . . . . 112 5.7. Proceso de desarrollo: Iteración 6 . . . . . . . . . . . . . . . . . . . . . . . 112 5.8. Proceso de desarrollo: Iteración 7 . . . . . . . . . . . . . . . . . . . . . . . 113 5.9. Proceso de desarrollo: Iteración 8 . . . . . . . . . . . . . . . . . . . . . . . 113 6.1. App Estimote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.2. App Particle Detector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.3. Primer Experimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.4. Plano Esquemático del laboratorio . . . . . . . . . . . . . . . . . . . . . . 121 6.5. Plano esquemático del laboratorio con secciones . . . . . . . . . . . . . . . 121 6.6. Nodos de Referencia en topología de malla . . . . . . . . . . . . . . . . . 124 6.7. Catálogo de productos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 6.8. Listas de listas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 6.9. Creación de alertas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 6.10. Selección de fecha y hora . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 6.11. Notificación de alerta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 6.12. Lista de procutos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 6.13. Modficaión de la lista de porductos . . . . . . . . . . . . . . . . . . . . . . 128 6.14. Generar un correo con la lista de la compra . . . . . . . . . . . . . . . . . 129 6.15. Mapa de interior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 6.16. Mapa de interior consecciones . . . . . . . . . . . . . . . . . . . . . . . . 130 A.1. Red de sensores con tecnología ZigBee . . . . . . . . . . . . . . . . . . . 143 A.2. Gráfica de consumo de potencia de tecnologías RF . . . . . . . . . . . . . 146 A.3. Gráfica de coste/complejidad de tecnologías RF para localización en interiores147 B.1. Calibración de un dispositvo iBeacon . . . . . . . . . . . . . . . . . . . . xxi 149 Índice de listados 4.1. Modelo relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.2. Actualización del contenido del array . . . . . . . . . . . . . . . . . . . . 55 4.3. Solicitud de recuperación de datos . . . . . . . . . . . . . . . . . . . . . . 56 4.4. Solicitud de recuperación de datos controllerWillChangeContent: . . . . . . 58 4.5. Solicitud de recuperación de datos forChangeType:newIndexPath: . . . . . 58 4.6. Solicitud de recuperación de datos controllerDidChangeContent: . . . . . . 59 4.7. Solicitud de recuperación de datos de la capa de vista . . . . . . . . . . . . 59 4.8. Identificación y Registro del major de cada dispositivo . . . . . . . . . . . 66 4.9. Definir el UUID y región con los que se va a trabajar . . . . . . . . . . . . 67 4.10. Identificación y Registro del major de cada dispositivo . . . . . . . . . . . 67 4.11. Distinción del tipo de señal segun el major de cada dispositivo . . . . . . . 69 4.12. Pseudocodigo Función Semáforo . . . . . . . . . . . . . . . . . . . . . . . 78 4.13. Pseudocódigo Módulo Enrutamiento . . . . . . . . . . . . . . . . . . . . . 82 4.14. Inicialización Tabla de Distancias . . . . . . . . . . . . . . . . . . . . . . 88 4.15. Rellenar Tabla de Distancias. . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.16. Implementación Técnica Fuerza Bruta . . . . . . . . . . . . . . . . . . . . 91 4.17. Implementación Técnica Fuerza Bruta . . . . . . . . . . . . . . . . . . . . 94 4.18. Implementación Técnica Fuerza Bruta . . . . . . . . . . . . . . . . . . . . 96 4.19. Implementación Técnica Fuerza Bruta . . . . . . . . . . . . . . . . . . . . 98 B.1. Calibración iBeacon. Listado Extraído de [App14a] . . . . . . . . . . . . . 150 XXIII Capítulo 1 Introducción E este capítulo se realiza una introducción al problema que el presente Trabajo Fin de Grado pretende abordar. En primer lugar se presenta el concepto de la localización en interiores y se expone cuál es el problema a resolver y su contexto histórico. Este terreno ha alcanzado una gran popularidad en los últimos años debido a la aparición de aplicaciones para dispositivos móviles que hacen uso de las nuevas tecnologías de localización en interiores y permiten al usuario guiar en un espacio cerrado de manera cómoda. Por ello, se estudiará la evolución de los teléfonos móviles inteligentes o smartphones junto con su enorme crecimiento desde la perspectiva del mercado en los últimos años. A continuación se expone la motivación y en base a ella se detalla la propuesta de trabajo realizando un breve análisis de los principales objetivos del presente Trabajo Fin de Grado. Finalmente se concluye detallando la estructura del presente documento y el contenido que se abordará en cada uno de sus capítulos. N 1.1 Contexto del problema Hoy en día conocer la localización en la que nos encontramos se ha convertido en una necesidad, necesidad que se ha transformado en requisito imprescindible si se quiere hacer uso de las numerosas aplicaciones que ofrecen servicios basados en la posición del usuario. Estos servicios abarcan distintos temas: seguridad, atención socio-sanitaria, ocio, turismo, deportes, etc. Inicialmente todos estos servicios de localización estaban orientados al posicionamiento global y se realizaban en entornos de exterior, sin embargo estos sistemas de posicionamiento no permiten la localización con precisión de dispositivos en espacios cerrados y es por ello que se empezó a realizar un intenso estudio durante los últimos años en busca de una solución adecuada y adaptada a la localización en espacios cerrados dando lugar al desarrollo de los actuales sistemas de posicionamiento o localización en interiores. Los motivos que han obstaculizado el desarrollo han sido tanto técnicos como económicos. Técnicos porque la localización en espacios cerrados presenta retos tecnológicos mayores que la localización en espacios abiertos. Económicos porque la gran parte de estos sistemas requieren gran cantidad de infraes1 tructura fija que hace que aumente el coste. Sin embargo, dichas infraestructuras han reducido los costes haciendo posible que sea viable instalarlos en entornos cerrados. Este área no sólo abre las puertas a nuevos modelos de negocio capaces de revolucionar los modos de rentabilizar estructuras sino que podría beneficiar ampliamente a un importante sector del público, los invidentes o personas con discapacidad visual, los cuales, se aprovecharían de los servicios que este sistema podría ofrecerles, ayudando en tareas rutinarias como puede ser la compra en un supermercado al haberse reubicado los productos. 1.2 Evolución de los smartphones El smartphone es aquel teléfono construido sobre una plataforma móvil que sobrepasa la frontera de los teléfonos móviles tradicionales. La idea principal del smartphone o teléfono inteligente era básicamente la de unir las funciones de un PDA con las de un teléfono para mayor compactibilidad y por tanto comodidad. Todo comenzó en 1992, con la llegada del dispositivo IBM Simon, que unía todas las funcionalidades de un PDA con capacidades telefónicas y de SMS y, a diferencia del resto de PDAs que requerían un puntero, este dispositivo incorporaba una pantalla completamente táctil. Sin embargo no fue hasta la llegada del Ericsson GS88, el cual poseía muchas más funciones como puede ser el correo electrónico, navegación web, conexión a PC entre las más destacables, cuando se acuñó el termino smartphone. No fue hasta la llegada del nuevo sistema operativo Windows Mobile entre los años 2000 y 2005, cuando los dispositivos móviles adquirieron una gran popularidad, especialmente entre los hombres y mujeres de negocios de Estados Unidos. Dentro de este periodo Blackberry lanzó sus primeros modelos de smartphone en 2003 y pasó a disputar la compartición de este liderazgo en 2006, atrayendo no sólo al sector de empresarios y ejecutivos, típicamente asociados con Windows Mobile, sino al sector de la población joven. Sin duda el evento que cambió la percepción de lo que era un smartphone fue el anuncio del iPhone en 2007, revolucionando la industria de la telefonía móvil y de los smartphones, siendo uno de los primeros teléfonos móviles en incluir una interfaz multitáctil para interactuar con el dispositivo y capaz de ofrecer la mejor experiencia en Internet hasta el momento. Meses más tarde, Google presenta su sistema operativo Android y pese a que inicialmente Android contó con un proceso de aceptación lento por parte del público, su popularidad creció enormemente en 2010. Con la llegada de estos dos nuevos participantes en el mercado de smartphones la cuota de mercado hasta el momento acaparada por el resto de fabricantes sufrio un duro golpe, dando lugar a un replanteamiento de estrategias de negocio. En el caso de Microsoft, optó por crear un nuevo sistema operativo desde cero, denominado Windows Phone, ocupando el tercer puesto en la cuota de mercado actual. Nokia abandono Symbian 2 y se unió a Microsoft implantando este nuevo sistema operativo en sus dispositivos. Por último Blackberry también diseñó una nueva versión de su sistema operativo desde cero, denominada Blackberry 10. La adopción de los smartphone por parte del público ha sido masiva, especialmente desde el año 2010, debido en gran parte a la disponibilidad en el mercado de smartphones a precios asequibles y se sigue prediciendo este aumento de ventas durante los próximos años como muestra la Figura 1.1 realizada por la agencia de estadísticas Statista [Sta15]. Figura 1.1: Predicción de ventas globales de smartphone hasta 2019 1.3 Elección del SO A la hora de elegir el sistema operativo se han analizado las dos posibles alternativas con mayor popularidad y tasa de mercado: Android e iOS. iOS de la mano de Apple comprende todas las fases, desde la fabricación hasta el software. En Android por el contrario intervienen tres agentes: Google, los fabricantes de hardware y por último los desarrolladores de software. En lo referente a la tasa de mercado, Google anunció en 2013 que se han activado 900 millones de dispositivos Android en todo el mundo frente a los 580 millones alcanzados por iOS. Tomando este punto de partida lo más conveniente sería emplear el esfuerzo en desarrollar para el sistema operativo Android, sin embargo, iOS sigue siendo la plataforma 3 preferida no de los desarrolladores independientes sino también de grandes empresas como Instagram, que comenzó apostando por la exclusividad como app para iPhone y terminó siendo comprado por 1000 millones de dólares por Facebook al año de estrenarse. En el caso de Flipboard, comenzó siendo exclusivo para iPhone y termino firmando un acuerdo con Samsung para contar con un periodo de exclusividad en el Galaxy 3 [CNE]. Yahoo es otra compañía que tiene por costumbre centrarse primero en mejorar sus aplicaciones para iOS antes de extender los cambios a Android teniendo en Flickr, Tiempo y Mail sus mejores ejemplos. Incluso Google apuesta primero por iOS con el claro ejemplo de Google Maps que estrenó su nuevo diseño en la plataforma Apple meses antes de hacerlo en Google Play; una muestra más evidente de la importancia de iOS para los buscadores [Xat13a]. Finalmente está Twitter que seis meses después de lanzar Vine para iOS y pese a la promesa de una versión para Android, publicaron una segunda app exclusiva de la plataforma Apple: Twitter Music [Xat13c] [Xat13b] [Xatil]. No cabe duda de que Android seguirá madurando como plataforma y es inevitable que en los próximos años se considere optar por el escenario opuesto, es decir, lanzar las aplicaciones primero para el sistema Google y luego en el de Apple. A pesar de que Android tiene una mayor cuota de mercado, un estudio demuestra que los usuarios de Apple son los que más utilizan sus dispositivos, como muestra la Figura 1.2 [Fet13]. Figura 1.2: Tiempo diario de uso de los dispositivos de Apple 4 Según dicho estudio, los usuarios de iPhone pasan 26 minutos más de media que el usuario típico de Android, utilizando el teléfono en menor proporción para llamar y más como smartphone para todo lo demás. Ambas plataformas hacen más o menos lo mismo, por lo menos cuando se trata de funciones básicas en los teléfonos inteligentes, sean llamadas, enviar mensajes, correos electrónicos, navegar por la web, por mencionar algunos. Pero cuando se trata de navegar por la red hay una clara ventaja de la plataforma iOS sobre Android, como demuestra un nuevo estudio realizado por la agencia de publicidad Statista [SMI14], que revela que los usuarios de iOS navegan más en comparación con los usuarios de Android, como se muestra en la Figura 1.3. Figura 1.3: Tiempo que navegan los usuarios de Android frente a los usuarios de iOS De la misma manera que los usuarios de Apple navegan mas por Internet que los de Android, también realizan mas compras desde ellos, incluyendo también a las tablets en el caso de Apple el iPad acaparando el 78 % de las compras realizadas como muestra un estudio realizado por Chitika, en la Figura 1.4. Otro aspecto a destacar son las cifras oficiales de descargas de la App Store y Google Play con 50.000 millones y 48.000 millones respectivamente. La diferencia es escasa, sin embargo hay que tener en cuenta la superioridad que tiene Android en la cuota de mercado y esto es debido a que muchos usuarios de Android no descargan aplicaciones en absoluto, quizás porque ni siquiera saben cómo hacerlo, no les importa o tan solo se llevaron el teléfono que ofrecieron en la tienda. 5 Figura 1.4: Compras realizadas desde tablets A pesar de la diferencia y aunque la tienda de Google ha mejorado, la App Store sigue generando casi el triple de ingresos como muestra la Figura 1.5, teniendo en cuenta el caso mas concreto de los videojuegos de iOS que generan más ingresos que los de las consolas portátiles y dispositivos Android combinados [Ann]. Figura 1.5: Estadísticas de descargas e ingresos de la App Store y Google Play 6 Sin embargo una de las características más determinantes por la que se ha decidido realizar el presente Trabajo Fin de Grado con el sistema operativo iOS ha sido el reparto mundial de trabajo que ofrece este sistema como muestra la Figura 1.6, de cara al posicionamiento en el futuro profesional [ide]. Figura 1.6: Reparto mundial de empleo en iOS y Android 1.4 Motivación En base a la problemática de la localización indoor, se propone un sistema que se basa en la recepción de señales que permitan localizar al usuario dentro de un edificio en un mapa previamente facilitado y con unos puntos a recorrer para guiar al usuario hasta ellos. A base de ejemplo, el presente Trabajo Fin de Grado se va a centrar en un organizador de compras para una superficie comercial con una mapa que muestre la distribución del edificio, de manera que el usuario tenga que seleccionar productos del establecimiento para después, ser ubicado y en base a esta localización ser guiado siguiendo un orden hasta los distintos productos escogidos. 7 Son varias las aplicaciones existentes en el mercado que permiten realizar una lista de la compra en el smartphone para poder recordar cuáles son los productos que hay que comprar la próxima vez que se visite el supermercado, sin embargo todas presentan determinadas carencias como pueden ser la ausencia de una base de datos que permita elegir entre distintos productos catalogados y ordenados, con su imagen y una búsqueda sencilla, ya sea por voz o teclado, de manera que permita al usuario crear sus propias listas de la compra de manera amigable y sencilla con el smartphone. A esto hay que añadir esas innumerables vueltas que se dan por los pasillos para encontrar todo lo que quiere el cliente y no perder el tiempo andando sin rumbo por los supermercados y grandes almacenes. En definitiva, no existe ninguna solución aceptada mayoritariamente que contenga todos estos detalles y proporcione las principales funcionalidades para que el usuario pueda crear sus propias listas de la compra de manera amigable y sencilla y añada la peculiaridad de calcular la ruta con menor coste para optimizar el recorrido del usuario, proporcionando una experiencia agradable al ahorrar todas esas vueltas innecesarias. En base al estudio realizado en la Subsección 1.3 se ha determinado que esta aplicación estará destinada a dispositivos móviles con sistema operativo iOS. 1.5 Propuesta A raiz de estas motivaciones surge la propuesta del presente Trabajo Fin de Grado. Se plantea diseñar y desarrollar un sistema software asistencial bajo la plataforma iOS, para entornos comerciales mediante localización indoor basado en redes inalámbricas. Esta aplicación se basa en la recepción de señales procedentes de balizas BTLE (Bluetooth Low Energy), también denominados beacon. Mediante ellos se localizarán los distintos puntos a recorrer que corresponderán con los productos que el usuario ha seleccionado y se le guiará hasta ellos. Este sistema permite obtener una gran precisión en el cálculo de la posición y además su despliegue es rápido, ya que la instalación de los beacons es muy sencilla. Las funcionalidades principales que esta aplicación ofrecerá a sus usuarios serán las siguientes: El usuario deberá contar con un catálogo de los productos disponibles en la superficie comercial ordenados por categorías. El usuario podrá buscar los productos, a partir del nombre, a través de texto o voz. El usuario podrá guardar varias listas de la compra con productos del supermercado. El usuario podrá crear notificaciones para las distintas listas, cuya función será avisarle en la fecha que seleccione el usuario. El usuario podrá visualizar la ruta que ha de seguir en el supermercado. El usuario será guiado a través de la ruta con el menor coste, que será calculada en 8 base a los productos escogidos. El usuario podrá visualizar su posición dentro del supermercado. El usuario será informado al llegar a un producto. El usuario podrá enviar por correo la lista de la compra a cualquier usuario. La aplicación debe ser capaz de calcular la ruta para cualquier mapa. La aplicación debe contar con un diseño extensible que permita la introducción de mapas correspondientes a diferentes superficies comerciales, siendo capaz de calcular y representar la ruta de manera genérica. 1.6 Estructura del documento Este documento se ha estructurado en base a la normativa del Proyecto Fin de Grado de la Escuela Superior de Informática de Ciudad Real de la Universidad de Castilla-La Mancha. En base a ello, este documento cuenta con los siguientes capítulos: Capítulo 2: Objetivos y Herramientas En este capítulo se proporciona una visión general del sistema que se pretende desarrollar, de la cual se concluyen los requisitos funcionales, para posteriormente desglosar cada uno de estos requisitos en varios subobjetivos. Capítulo 3: Antecedentes En este capítulo se analizan las principales aplicaciones relacionadas a la aplicación que se va a desarrollar en el presente Trabajo Fin de Grado. Atendiendo al carácter de la aplicación que se va a implementar se han agrupado las aplicaciones existentes en dos listas independientes: App de listas App para localización en interiores Se realizará un estudio para la determinación de los objetivos que Shopping Beacon debe cumplir, mediante un análisis de las principales características: puntos fuertes y debilidades de cada una de ellas. Capítulo 4: Arquitectura En este capítulo se describe el diseño e implementación del sistema, detallando los problemas surgidos y las soluciones aportadas. El capítulo se divide en varias secciones correspondientes a los distintos módulos que componen el sistema, describiendo en primer lugar una visión general y funcional del modulo y pasando posteriormente a los detalles técnicos y de implementación, junto con los problemas surgidos en el desarrollo, las soluciones planteadas y los resultados de las distintas pruebas realizadas. 9 Capítulo 5: Métodos de trabajo En este capítulo se analiza la metodología de desarrollo escogida para el desarrollo de la aplicación. También se listan y describen los recursos empleados tanto hardware como software en el proceso de desarrollo. Capítulo 6: Resultados En este capítulo se razonan las decisiones de diseño tomadas durante el periodo de desarrollo de la aplicación aportando datos que las refuerzan. Capítulo 7: Conclusiones y Propuestas En este capítulo se elabora un resumen a modo de conclusión sobre el producto final del desarrollo, indicando las metas que se han conseguido frente a las inicialmente propuestas. Se detalla el posible trabajo futuro y se concluye con una conclusión personal. Anexos En los anexos se presenta material que, dada su naturaleza, no se ha incluido en el grueso del documento. En primer lugar se realiza un estudio sobre las diversas tecnologías de localización más relevantes. En segundo lugar se expone el proceso de calibración de los dispositivos empleados. Finalmente, se lista el contenido del soporte físico adjunto a este documento. 10 Capítulo 2 Objetivos y Herramientas E este capítulo se proporciona una descripción general de la arquitectura del sistema, ofreciendo al lector una idea de su diseño a alto nivel. En segundo lugar se proporciona una lista de objetivos que se proponen para la consecución del desarrollo. Cada uno de estos requisitos se encuentra desglosado en varios subobjetivos concretos, detallando qué se pretende obtener y su alcance. Finalmente se listan y describen todas las herramientas utilizadas en el desarrollo, ya sean hardware o software. N 2.1 Visión General La visión general de la propuesta del Trabajo Fin de Grado es la creación de una aplicación que permita al usuario generar sus propias listas de la compra para una superficie comercial y ésta sea capaz de mostrarle un mapa con la distribución del edificio de manera que el usuario pueda ser guiado hasta los distintos productos escogidos. La aplicación deberá hacer uso de una base de datos que permita al usuario consultar los productos ofrecidos por la superficie comercial y generar y almacenar sus propias listas dentro de la aplicación. Una vez configurada la lista se podrá mandar por correo a cualquier persona o ir a la superficie comercial para realizarla. Si el usuario decide realizar la compra la aplicación debe ser capaz de ahorrar esas innumerables vueltas que se dan por los pasillos generando una ruta con un coste mínimo. Una vez dentro de la superficie comercial la aplicación deberá reconocer los dispositivos que se encuentren y obtener los datos que envíen, independientemente del tipo de comunicación que se realice. Con estas señales la aplicación ha de ser capaz de posicionar al usuario y guiar de manera eficiente durante todo el recorrido generado. La Figura 2.1. sintetiza en un digrama de bloques este enfoque. Se describe a continuación: La aplicación se puede dividir en dos módulos bien diferenciados. En primer lugar se encuentra el módulo encargado de mostrar y generar las listas de la compra del usuario. Este módulo cuenta con una base de datos que será la encargada de almacenar los datos de carácter persistente utilizados por los usuarios de la aplicación. Se 11 Figura 2.1: Visión General de la Arquitectura del Sistema ofrecerá una interfaz de llamadas que permita al controlador de la aplicación abstraerse totalmente de la forma en la que la estructura de la base de datos haya sido implementada. El segundo módulo se encargará de generar la ruta de menor coste con todos los productos seleccionados por el usuario. Una vez generada la ruta, la aplicación reconocerá los dispositivos que se encuentren dentro del recinto comercial y establecerá comunicación con ellos a través de la Interfaz de Conexión del dispositivo. Estos paquetes pasarán a la capa de Decodificación donde se analizarán los paquetes recibidos y, si estos forman mensajes válidos, los convertirá a datos e información válida para las capas superiores. Hasta este punto son capas dependientes del dispositivo. Los datos anteriores pasan a las capas superiores, independientes del dispositivo, donde son procesados antes de ser utilizados por otros componentes de la aplicación. Debido a que habrá varios dispositivos de manera simultánea, cada señal se procesa en una capa de Tratamiento de señal, donde se dividen las señales dependiendo del dispositivo de origen 12 que ha mandado la señal y se almacenan para posteriormete pasarles un filtro para reducir el ruido aleatorio en el dominio de tiempo. El siguiente paso será determinar la posición del usuario mediante las señales ya procesadas en una capa de Posicionamiento. Esta posición se manda a la capa de enrutamiento y guiado encargada de comprobar la posición del usuario, calcular la ruta partiendo de dicha posición del usuario, generar la animación y guiar al usuario mediante comandos de voz. Toda esta información pasará a la capa de controladores que será la encargada de actuar en consecuencia y comunicarse con la vista. 2.2 Lista de objetivos La visión general de la propuesta del Proyecto Fin de Grado es la creación de una aplicación descrita en la Sección 1.5 del Capítulo 1. A partir de dichos requisitos y partiendo de esta descripción, se listan las siguientes funcionalidades, que deberán lograrse a lo largo del proceso de desarrollo del sistema: Diseñar, desarrollar y validar un sistema asitencial para superficies comerciales mediante tecnologías móviles y de posicionamiento en interiores Desarrollo de una aplicación en iOS cuyo uso sea sencillo y abarque el mayor numero posible de dispositivos en base a su versión del sistema operativo. Acceso a un catálogo remoto, sostenido por una base de datos, que permita consultar los distintos productos, ordenados por categorías. Desarrollo de una base de datos interna en el dispositivo del cliente cuyo diseño y arquitectura le permitan ser escalable y eficiente. Independencia de la implementación de la base de datos de la aplicación cliente respecto a la base de datos remota de la que se toman los datos. Búsqueda de productos, mediante teclado o voz. Almacenamiento de varias listas de la compra con productos que existan en el catálogo del recinto comercial. Desarrollo de un algoritmo que permita calcular la ruta: • El algoritmo toma como origen el punto en el que se encuentra el usuario. • La ruta debe de guiar al usuario hasta cada uno de los productos añadidos a la lista. • La ruta debe de tener el menor coste. • El algoritmo ha de contar con un diseño extensible que permita calcular de manera genérica distintas rutas para distintas superficies comerciales. • En el caso de que el usuario se equivoque y tome una dirección errónea, el algoritmo ha de calcular la nueva ruta obviando los productos ya recogidos. Determinar y monitorizar la posición en la que se encuentra el usuario: 13 • La precisión que debe tener la aplicación variará en función de la tecnología utilizada. • Como requisito mínimo y al tratarse de un supermercado debe señalar en qué pasillo o sección se encuentra el usuario. Guiar al usuario mediante comandos de voz: • Informar al usuario de la siguiente dirección que tiene tomar. • Informar al usuario de que ha llegado al pasillo o sección del supermercado donde se encuentra el producto que ha añadido a la lista. Notificar al usuario a modo de recordatorio que tiene que realizar la compra de una lista. Enviar por correo la lista creada a cualquier contacto. 2.3 Herramientas de desarrollo En esta sección se detallan los recursos software y hardware empleados en el proceso de desarrollo. Para cada uno de estos recursos se proporciona una breve explicación, junto con la versión utilizada y la parte del desarrollo en la que ha sido empleado. 2.3.1 Lenguajes Los lenguajes de programación empleados en el proceso de desarrollo son los siguientes: Objective-C: 1 Es el lenguaje principal de programación en Mac OS X e iOS y por tanto el lenguaje empleado para el desarrollo del proyecto. SQL: 2 Es un lenguaje declarativo empleado en la gestión de los datos almacenados en sistemas gestores de bases de datos relacionales. Una de sus características es la realización de consultas y la modificación de datos a través del manejo del álgebra y el cálculo relacional. SQL se ha utilizado en la recuperación de los datos de la base de datos externa. 2.3.2 Hardware A continuación se listan detalladamente el software empleado en la realización del presente Trabajo Fin de Grado. Macbook Pro: Ordenador portátil con el que se va a desarrollar el proyecto, en él se encuentra todo el software necesario para llevar a cabo la construcción de la aplicación. Sus características son las siguientes: Procesador Intel Core i5, 2’4GHz; 4Gb de memoria RAM; nVIDIA GeForce GT 330M; HD 120Gb. 1 Objective-C, https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/ ProgrammingWithObjectiveC/Introduction/Introduction.html 2 Oracle Database Overview, http://docs.oracle.com/cd/E11882 01/server.112/e41084/toc.htm 14 iPad: Tableta que actúa de baliza durante las primeras fases del desarrollo, debido a la falta de balizas iBeacon. Sus características son las siguientes: Procesador Apple A6X dual core; 1.3GHz; 1Gb de memoria RAM; HD 16Gb. iPhone: Smartphone con SO iOS 8.2 con el que también se van a realizar las pruebas pertinentes del sistema durante el desarrollo del sistema. Sus características son las si- guientes: Procesador Apple A6 doble núcleo, 1.3 GHz.; 1Gb de memoria RAM; Pantalla táctil 4 pulgadas. Kit de iBeacons de Estimote: Kit compuesto por tres balizas iBeacon; Versión Developer Preview 2.3.3 Software A continuación se listan detalladamente el software empleado en la realización del presente Trabajo Fin de Grado. Sistema Operativo Mac OX: Sistema operativo desarrollado por Apple Inc., sobre el que se ha desarrollado el sistema. El desarrollo se ha llevado a cabo en la versión OS X Yosemite. iOS: Sistema operativo desarrollado por Apple Inc. ,sobre el que se han desarrollado las pruebas de la aplicación. Las pruebas de las aplicación se han llevado a cabo en la versión 8.3 Software de desarrollo Xcode: 3 Entorno de desarrollo integrado (IDE) de Apple Inc. que se suministra junto con Mac OS X. Trabaja conjuntamente con Interface Builder, una herramienta gráfica para la creación de interfaces de usuario. Se ha empleado en el desarrollo del sistema en la versión 6.4. SQLiteManager: 4 Gestor de Base de datos SQLite, con una interfaz muy clara, empleada para la creación de la base de datos externa. Se ha utilizado la versión 3.8.0. 3 4 Xcode, https://developer.apple.com/xcode/ SQLiteManager, http://www.sqlitemanager.org/en/ 15 Documentación y Gráficos LATEX:5 Sistema de composición de textos de alta calidad orientado especialmente a la creación de documentación técnica y científica. Se ha empleado para realización de la presente documentación. Se ha utilizado la distribución MacTeX-2015 y TeX Live 2015. TeXworks: Herramienta para la creación de documentos con LATEX. Ha sido el editor de LATEX empleado para redactar la documentación. Se ha utilizado la versión 0.4.5 (r.1280). Balsamiq: Herramienta para la creación de bocetos de interfaces de usuario. Ha sido empleado en el diseño de las diferentes pantallas de la aplicación. Se ha utilizado la versión 3.1.9. Visual Paradigm: Herramienta para el diseño de proyectos ágiles. Soporta modelado con estándares como UML, SysML, ERD, DFD, BPN, etc. Proporciona soporte para la identificación de casos de uso, análisis de requisitos y flujo de eventos entre otros. Se ha empleado en la creación de los diagramas de secuencia. Se ha utilizado la versión 12.1. Gannt Project: Herramienta para la planificación y gestión de proyectos. Ha sido empleado en la creación de los diagramas de Gannt reflejando las iteraciones en el proceso de desarrollo. Se ha utilizado la versión 2.6.3. GIMP: Herramienta de manipulación fotográfica multiplataforma, que permite la realización de todo tipo de manipulación de imágenes, incluyendo retoque fotográfico y composición de imágenes. Ha sido empleado en el tratamiento de las imágenes integradas en la documentación, cuando ha sido necesario. Se ha utilizado la versión 2.8.14p2. LibreOffice Draw: Herramienta de dibujado vectorial perteneciente a la suite LibreOffice. Se ha empleado en la generación de diagramas presentes en la documentación. Se ha utilizado la versión: 4.4.4.3. Floorplanner : 6 Herramienta para la creación de planos interactivos en linea. Se ha empleado en la generación del plano de la aplicación. 5 A LTEX6 A document preparation system, http://www.latex-project.org/ Floorplanner, http://es.floorplanner.com 16 Bibliotecas OpenEars: 7 Biblioteca que proporciona reconocimiento de voz y conversión de texto a voz para su uso en dispositivos iOS. iOS SDK: 8 Incluye las bibliotecas y herramientas de desarrollo necesarias para compilar, probar y depurar aplicaciones en iOS. Ha sido utilizado para el desarrollo del sistema, especialmente para el uso de las siguientes bibliotecas: Core Location, Core Bluetooth, Core Data, Core Animation. API Estimote: 9 Biblioteca proporcionada por Estimote para el control y programación de los iBeacons 7 OpenEars, http://www.politepix.com/openears/ iOS SDK, https://developer.apple.com/library/ios/navigation/ 9 API Estimote, http://developer.estimote.com 8 17 Capítulo 3 Antecedentes E este capítulo se analizan las principales aplicaciones existentes que tengan el mismo carácter que la aplicación que propone este Trabajo Fin de Grado, realizando un análisis de las principales características de cada una de ellas, que servirá para la confección de la lista de objetivos que Shopping Beacon debe cumplir. N 3.1 Trabajos relacionados Como ya se ha comentado anteriormente, para conocer el estado actual del problema, es necesario realizar un análisis previo que proporcione una visión general. Es por ello que en esta sección se ha realizado un estudio de las aplicaciones existentes con el fin de adoptar los aspectos conocidos apropiados para el problema y sustituir las carencias que se descubran, mejorándolas o añadiendo las que se necesiten, con la finalidad obtener una solución que se ajuste al problema que se procura resolver. Para ello se han realizado búsquedas, de manera independiente a la plataforma en la que se va a desarrollar la aplicación, introduciendo los términos por los que se ve afectado el carácter de la aplicación, buscados tanto en inglés como en castellano en el buscador web Google, en el buscador de la aplicación App Store, disponible para dispositivos iOS y en el buscador de la aplicación Play Store disponible para dispositivos Android. Como resultado de esta búsqueda y atendiendo al carácter de la aplicación se han agrupado las aplicaciones en dos listas independientes: Apps para realizar listas de la compra Apps para localización en interiores 3.2 Apps para realizar listas de la compra Esta búsqueda se ha orientado a aplicaciones o soluciones que permitan realizar una lista de compra para posteriormente poder comprar en el supermercado o espacio comercial. 19 Shopping List Esta aplicación destinada a realizar la lista de la compra sufre distintas carencias, como puede ser una interfaz nada amigable, ya que el uso no es nada intuitivo. Esta aplicación carece de una base de datos con productos que te permita seleccionar de manera previa y es necesario introducir el nombre de cada uno de ellos para poder guardarlo, hasta un máximo de 30 productos con la versión gratuita de la App. Al no tener una base de datos con los productos tampoco tiene el precio de ellos y por tanto el precio total de la lista que el usuario desea comprar. Tiene la opción de crear distintas listas, pero la aplicación se bloquea al intentar crear una lista distinta de la principal, obligándo al usuario a reiniciar la App. La única opción que parece tener sentido y funciona correctamente es la opción de compartir que permite mandar la lista con los productos añadidos a cualquier dirección de correo. Figura 3.1: App Shopping List. Lista inicial Figura 3.2: App Shopping List. Añadir Producto 20 LiShop LiShop1 es una aplicación destinada a realizar la lista de la compra que tiene una interfaz más intuitiva, ya que cuenta con una base de datos con todos los productos que se pueden seleccionar, sin embargo los productos carecen de foto que haga esa búsqueda del producto más sencilla, aunque esa carencia la suple mediante una ordenación alfabética de los productos, además de poder buscar el nombre del producto o pasar un filtro para que sólo muestre los productos del catálogo que el usuario elija. La aplicación permite añadir productos y asignarles un precio para calcular el precio total de la lista, sin embargo no permite crear distintas listas y tener estas listas ordenadas. Una vez finalizada la creación de la lista permite mandarla a cualquier dirección de correo. Figura 3.4: App LiShop. Buscar Producto Figura 3.3: App LiShop. Lista Inicial 1 LiShop (2015), http://www.lishopapp.com 21 Buy Me a Pie Buy me a Pie2 es una aplicación destinada a realizar la lista de la compra que llama más la atención al incluir más color, sin embargo la base de datos de productos esta incluida en la esquina de la barra de búsqueda de la interfaz por lo que no es intuitivo acceder a ese catálogo, ya que el único objetivo de la barra de búsqueda es escribir un nombre para después buscarlo y no incluir un botón en su esquina. Posee una base de datos con todos los productos pero no incluye ninguna foto ni precio. A la hora de buscar un producto dentro de la barra de búsqueda, aparecen los posibles productos que se pueden buscar por la palabras que ya se han introducido y de esa manera deshacerse de los que no se buscan, por lo que actúa de filtro. A la hora de añadir productos a la aplicación se permite repetir productos, cuando lo normal sería aumentar la cantidad y no que aparezca dos veces, ademas al no ordenar la lista del usuario final, puede encontrarse el mismo producto al final y al principio de la lista. Esta app sí permite crear otras listas y añadirles un nombre, sin embargo sólo se consigue mediante una versión de pago. Al igual que las aplicaciones ya comentadas anteriormente, una vez finalizada la creación de la lista permite mandarla a cualquier dirección de correo. Esta app de origen americano, ofrece una plataforma web que permite realizar la gestión de las compras con una interfaz similar. Figura 3.5: App Buy Me a Pie. Creación de listas 2 Figura 3.6: App Buy Me a Pie. Lista Inicial Buy me a Pie (2013), http://buymeapie.com 22 ShopShop ShopShop3 es una imitación de la aplicación Notas que incorpora el iPhone en la versión 7.1.2, por lo que para aquel usuario que haya usado esta versión de iOS, no le será difícil acostumbrarse, es un diseño simple pero intuitivo. Al ser una imitación de la app Notas, no contiene ninguna base de datos con productos, por lo que es necesario introducir el nombre de cada uno de ellos para poder guardarlo en la lista. Permite crear varias listas donde cada una corresponde a una vista independiente de las otras. Las vistas son personalizables, ya que permite cambiar el color del fondo y el titulo de la lista. Dentro del apartado de configuración permite cambiar el tamaño de la fuente para que se vean los nombre de los productos más grandes y ordenar las listas por orden alfabético; como inconveniente para cambiar de lista se tiene que ir pasando de una vista a otra hasta encontrar la lista deseada, si se tienen pocas listas no se tarda mucho, pero si se tienen varias listas, encontrar la lista deseada puede ser una tarea pesada. Al igual que las aplicaciones ya comentadas anteriormente, una vez finalizada la creación de la lista permite mandarla a cualquier dirección de correo. Figura 3.8: App ShopShop. Mandar lista por correo Figura 3.7: App ShopShop. Añadir Producto 3 ShopShop (2008), http://nschum.de/apps/ShopShop/ 23 Lista Lista4 permite realizar una lista de la compra de una manera más clara, ya que posee una interfaz más intuitiva y tan sólo contiene dos vistas, la primera de ellas con el catálogo de productos y la segunda para añadir la cantidad. Cuenta con una base de datos de productos propia, con una foto del producto deseado y ordenado por categorías, lo que hace fácil de buscar el producto deseado. La app contiene una barra de búsqueda que permite buscar el producto introduciendo texto o dictando el producto, por lo que la función de búsqueda resulta muy sencilla. Una vez seleccionado el producto permite añadirle la cantidad de producto que se desea expresado en kilos o unidades. Como inconveniente, no permite crear distintas listas, sólo contiene 15 productos entre los que poder elegir de manera gratuita. No permite añadir un precio a cada uno de los productos para calcular el precio final. Una vez finalizada la creación de la lista permite mandarla a cualquier dirección de correo. Figura 3.10: App Lista. Añadir Producto Figura 3.9: App Lista. Lista Inicial 4 Lista (2013), http://www.kobiuter.com 24 ShopIt ShopIt5 es otra aplicación destinada a realizar la lista de la compra; tiene una interfaz muy vistosa pero nada intuitiva, ya que su enfoque de simplificar al máximo llega a resultar excesivo. La primera imagen que se encuentra al abrir la aplicación es una tabla con el catálogo de productos, en la que aparece la imagen a la izquierda y el nombre a la derecha de cada celda, dos botones en el margen, el primero de ellos que permite personalizar la tabla con colores y el segundo de ellos para realizar la compra directamente, y por último entre los botones del margen y el catálogo una barra de búsqueda y un espacio en blanco, entonces la pregunta es, ¿cómo se añaden los productos?; la respuesta está en la primera vista que ofrece la aplicación, aquella con el catálogo de productos. Si se deja pulsado cualquier producto se añade al espacio en blanco en forma de cola, es decir, va añadiendo productos y poniéndolos al final de la cola. Sin embargo no permite crear varias listas, ni añadir la cantidad, y si se desea borrar la lista, se tienen que borrar individualmente cada uno de los productos lo que hace una tarea tediosa si se quiere borrar una lista con muchos productos. Una vez finalizada la creación de la lista si se pulsa el botón del margen de comprar permite visualizar la lista de una manera mas cómoda, ya que presenta todos los productos seleccionados en una tabla ordenada por catálogo y mandarla a cualquier dirección de correo. Figura 3.11: App ShopIt. Lista Inicial 5 Figura 3.12: App ShopIt. Lista Final ShopIt (2013), http://129642c2c6c30893af75-8259d49df90b36016edbf45b689de5ec.r28.cf2.rackcdn.com 25 myShopi myShopi6 es la última aplicación que se va a comentar destinada a la creación de la lista de la compra, tiene una interfaz vistosa, intuitiva y muy amigable al usuario final. Está mucho más enfocada a los supermercados, ya que a la hora de crear una lista el nombre que se le asigna a la lista es el de aquel supermercado en el que se va a realizar la compra, eligiendo entre todos ellos a la hora de crear la lista y, en el caso de que no estuviera, con la posibilidad de incluir el supermercado para poder elegirlo. Una vez elegido el supermercado aparecen todas las posibles categorías, y una vez elegida la categoría aparecen todos los artículos que le pertenecen, de la misma manera que si no estuviera la categoría o articulo deseado da la posibilidad de incluirlo. Una vez seleccionada la lista se entra en otra ventana donde se puede editar los artículos elegidos añadiendo una nota, como pueden ser las unidades que se quieren comprar. Dentro de esta misma ventana se tiene la opción de borrar todos los productos, buscar el producto introduciendo texto o dictando el producto en la barra de búsqueda y mandar la lista a cualquier dirección de correo. Un inconveniente que tiene la aplicación es el no tener el precio o no dejar asignárselo a cada producto para así saber el precio final de la lista. Figura 3.13: App myShopi. Crear Lista Inicial 6 Figura 3.14: App myShopi. Añadir Producto myShopi (2014), http://www.myshopi.com 26 3.2.1 Análisis Comparativo App para realizar listas de la compra Una vez comentadas las características de cada una de las aplicaciones, se concluye con un análisis comparativo entre ellas teniendo en cuenta las características más destacables de cada una de ellas y las características que una aplicación destinada a un usuario que quiera realizar una lista de la compra ha de tener. El resultado de la comparación se puede consultar en la Tabla 3.1. El análisis comparativo realizado en la Tabla 3.1, permite visualizar las características de cada aplicación que proveen diferentes servicios a sus usuarios y características deseables para la aplicación y por lo tanto se debe valorar su incorporación en este proyecto. Tras hacer un análisis de las características reales de las aplicaciones examinadas y deseables en una aplicación para el usuario, se ha considerado aconsejable añadir las siguientes características a la aplicación que enlaza al proyecto: La app debe contener una base de datos con los productos del centro comercial al que va a estar destinada la app. Los productos deben contener una imagen que haga más intuitiva la localización dentro del catálogo de productos. Los productos deben tener un precio asignado. Los productos pueden ser buscados de manera escrita o por comandos de voz. El usuario puede crear varias listas. El usuario puede visualizar el precio de la lista con los productos ya escogidos. El usuario puede compartir la lista con cualquier otra persona. El usuario puede añadir una alerta a cada lista para que le avise en una fecha concreta. 27 28 Shopping List LiShop Buy me a Pie ShopShop Lista ShopIt myShopi 7 7 7 7 3 3 3 7 3 3 7 3 3 3 7 7 3 7 7 7 7 Productos Precio 7 3 3 7 3 7 3 Búsqueda Productos Escrita 7 3 3 7 3 7 3 Búsqueda Productos Hablada 7 7 7 3 7 7 7 Crear varias listas 7 7 3 7 7 7 7 Precio lista 3 7 3 3 7 3 3 Compartir lista Tabla 3.1: Comparativa de las aplicaciones existentes que permiten realizar la lista de la compra. Productos Imagen Base de datos Productos 7 7 3 7 7 7 7 Recordatorio lista 7 7 7 7 7 7 3 Centro Comercial 3.3 Apps para localización en interiores Esta búsqueda se ha orientado a aplicaciones o soluciones que permiten una localización en interiores más precisa que la ofrecida por redes móviles y GPS. Point Inside Point Inside7 permite visualizar todos los servicios disponibles en edificios de entidades públicas o privadas tanto mayoristas como minoristas. Estos edificios son aeropuertos, centros comerciales, parques temáticos y museos asociados a América y pueden ser buscados por ubicación y categoría. Muestran los servicios de dichos edificios: baños, cajeros automáticos, estacionamientos, ascensores, etc; y en el caso de minoristas, acceder a ofertas especiales, ofertas y cupones que éstos ofrecen. Además proporciona instrucciones para llegar al destino y cuenta con enrutamiento dentro de la sala de navegación. Ofrece un plano dibujado de cada planta para cada uno de los edificios, y dentro de éste la posibilidad de seleccionar los servicios buscados como pueden ser el aseo o un restaurante. Otra punto fuerte es el amplio repositorio de planos del que dispone, accesible sin conexión a Internet. Figura 3.16: App Point Inside. Servicios disponibles Figura 3.15: App Point Inside. Mapa 7 Point Inside (2011), http://www.pointinside.com 29 Wifarer Wifarer8 facilita el posicionamiento en interiores mediante el uso de la tecnología WiFi de entidades públicas y privadas. Disponible en museos, hospitales, aeropuertos, centros comerciales, minoristas, estadios y universidades de Estados Unidos y Canadá. Los usuarios reciben la localización sin problemas y son guiados sin problemas a través de cualquier complejo hasta su destino con facilidad. Se estudian los comportamientos de los usuarios en las distintas instalaciones, con especial importancia en pacientes, ya que, registran lo que buscan, dónde suelen ir y el tiempo empleado. Además de guiar a sus usuarios en todos los edificios, incluye dos servicios comunes a todos los complejos: El primero es la información que ofrecen sobre los servicios de los que dispone: restaurantes, tiendas de regalos, cafeterías, etc. El segundo tiene en cuenta la accesibilidad para sillas de ruedas, para aquellos usuarios con problemas de movilidad para llegar a su destino. Volviendo al tema de los hospitales los visitantes pueden buscar la clínica o la habitación de un paciente y ser guiados sin necesidad de consultas a recepción. En el caso de los aeropuertos, guía a la puerta de embarque, teniendo en cuenta el tiempo que se tarda en llegar y la distancia que queda. Todos estos servicios, apoyados en mapas precisos de cada una de las plantas, junto con el amplio repositorio de planos del que dispone y su continuo crecimiento, hacen que sea un referente a la hora de tener en cuenta características del futuro proyecto. Figura 3.17: App Wifarer. Guiado interior 8 Figura 3.18: App Wifarer. Servicios Ofrecidos Wifarer (2014), http://www.wifarer.com 30 Figura 3.19: App Wifarer. Servicios Ofrecidos San Francisco Airport usa iBeacons para ayudar a a los invidentes El aeropuerto de San Francisco esta realizando pruebas con iBeacons para ayudar a gente invidente a desplazarse dentro de la terminal, mediante la implantación de 300 balizas distribuidas dentro de la terminal. Gracias a la tecnología iBeacons conectando los teléfonos móviles de los usuarios para recibir información y a la tecnología VoiceOver de Apple que permite leer en voz alta dicha información, se podrá informar al usuario desde donde encontrar una cafetería o una toma eléctrica, hasta desplazarse a localizaciones concretas [Low14]. Figura 3.20: Mapa interior aeropuerto de San Francisco. Figura 3.21: Adaptacion a gente invidente aeropuerto de San Francisco. 31 MIT Mobile MIT Mobile9 está destinada a su uso en el Massachusetts Institute of Technology o más conocido como MIT permite buscar cualquier edificio de manera independiente dentro del campus. Muestra un plano esquemático de todos los edificios sobre un mapa cartográfico y ofrece información acerca de él. Permite al usuario mantenerse en contacto con todo el personal del MIT (docentes, administrativos, estudiantes) proporcionando la información de contacto personal y saber en qué edificio se encuentra para el caso de trabajadores del MIT (docentes y administrativos). Además muestra todos los eventos que se realizan en el centro. Figura 3.23: App MIT Mobile. Servicios Ofrecidos Figura 3.22: App MIT Mobile. Guiado 9 MIT Mobile (2015), http://m.mit.edu/about/iphoneapp.html 32 Se ha realizado una breve búsqueda referente a la universidad poniendo como referencias tres ejemplos: Universidad de Granada La Universidad de Granada10 provee información sobre la Universidad, los centros que la componen y las titulaciones que en ella se imparten, de manera que el usuario sea capaz de conocer la oferta que ofrece la Universidad a la comunidad educativa. Dispone de información como el alojamiento en Granada, el calendario académico, el uso de la tarjeta Universitaria o el proceso para solicitar una cuenta de correo electrónico. La aplicación incluye acceso al directorio de la Universidad, con el que se puede localizar la información sobre los miembros de esta comunidad. También se pueden localizar geográficamente los centros y servicios de la Universidad y visualizar cada uno de los edificios señalados en un mapa cartográfico. Figura 3.24: App Universidad de Granada. Servicios ofrecidos 10 Figura 3.25: App Universidad de Granada. Centros de la Universidad Universidad de Granada (2012), http://cevug.ugr.es/movil 33 Universidad de Alabama De manera similar a la Universidad de Granada, la app University of Alabama11 ofrece una suite de aplicaciones corporativas en una principal, con la diferencia de que permite buscar los edificios por separado en lugar de mostrar todos los edificios sobre el mapa, utiliza un plano dibujado para mostrar los edificios superpuestos y muestra más información del edificio. También muestra el directorio personal de la universidad, ofreciendo la posibilidad de mantenerse en contacto con la persona buscada. Figura 3.27: App University of Alabama. Directorio de búsqueda Figura 3.26: App University of Alabama. Servicios ofrecidos 11 university of Alabama (2012), http://m.ua.edu/app/ 34 Universidad Rey Juan Carlos La Universidad Rey Juan Carlos12 permite al usuario gestionar sus propias guías de ocio o turismo, incluso para personas con discapacidad funcional o que necesiten orientación por todo el campus de la Universidad Rey Juan Carlos ( URJC ) al combinar guiado tanto Outdoor como Indoor ofrece indicaciones dependiendo de la incapacidad que presente (voz para invidentes, gestos y texto para sordos, etc). Figura 3.28: App GuideURJC. Mapa de interior 12 Figura 3.29: App GuideURJC. Creación de rutas Universidad rey Juan Carlos (2013), https://play.google.com/store/apps/details?id=com.dte.guideURJC& hl=es 35 Carrefour Carrefour está probando una nueva tecnología que utiliza Bluetooth Low Energy (BLE), en carros y cestas para seguir el viaje de los compradores de la tienda. Estas balizas unidas a los carros y cestas trabajan en conjunto con sensores colocados en el techo de la tienda que recogen las señales emitidas. Los datos de localización recogidos por los sensores se almacenan en un servidor para su análisis. Estos datos recogen el tiempo total que están en la tienda y en cada pasillo y los pasillos más visitados. Los datos de localización se recogen de forma anónima, pero prevé ampliarse en el futuro vinculando los datos a cada cliente individual. El cambio de los hábitos en un cliente es muy difícil, mediante el uso de estas balizas unidas a carros y cestas se prescinde de que los consumidores necesiten una aplicación o incluso un teléfono móvil, de manera que no se necesite ninguna interacción con el cliente. Sin embargo la tecnología es completamente compatible con el teléfono inteligente, de manera que en un futuro se pueda integrar con su tarjeta de fidelización, por ejemplo. En todo momento lo que se quiere es saber el comportamiento y el flujo de personas dentro de la tienda sin la necesidad de saber quiénes son. Figura 3.30: Localización Indoor dentro del supermercado Carrefour 36 3.3.1 Análisis Comparativo App para localización en interiores De manera análoga al análisis comparativo de las aplicaciones para realizar listas de la compra, se concluye este apartado con un análisis comparativo de las características de las aplicaciones de localización interior mediante la creación de la Tabla 3.2. La comparativa realizada en la Tabla permite visualizar las características de todas las aplicaciones analizadas que proveen diferentes servicios relevantes y por tanto, se debe considerar su incorporación en este proyecto. Sin embargo al tratarse de un usuario que va a realizar la compra a un supermercado, algunas de estas características no sirven y el resto hay que adaptarlas, ya que, en lugar de mencionar edificios, se referirán a productos. A continuación se enumera una adaptación de las diferentes características destacables: Uso de mapa cartográfico: Este punto situará el edificio en el mapa. Indicación sobre mapa de edificios disponibles: Indicación de los productos disponibles, ya sea a través de una lista o presentada en un mapa esquemático dibujado interior si lo tuviera la aplicación. Búsqueda de edificios disponibles: Pasaría a llamarse “búsqueda de productos disponibles” y permitiría buscar si el producto que se desea está en la lista. Uso de plano esquemático dibujado interior: Esta característica es similar, ya que se mostrarían los distintos pasillos que ofrece el supermercado. Posicionamiento interior: Esta característica es la esencia de la aplicación. Visualización de Servicios interiores: Esta característica también se ofrece de la misma manera en una aplicación para edificios y para ir a comprar. Búsqueda de servicios: Esta característica no tiene sentido si se añade la característica anterior, ya que en un supermercado son pocos y son comunes los servicios que se ofrecen a los usuarios en todos los edificios similares, como por ejemplo un aseo. Rutas Origen-Destino: Esta característica junto con el posicionamiento interior es la base de la aplicación. Guiado: Esta característica ofrece indicaciones al usuario a la hora de realizar la ruta. 37 Tras conocer y adaptar todas las características de las aplicaciones de interior se ha considerado recomendable incorporar las siguientes a el proyecto: Indicación de los productos disponibles Búsqueda de productos disponibles Uso de plano esquemático dibujado interior Posicionamiento interior Visualización de Servicios interiores Rutas Origen-Destino Guiado 38 39 Point Inside Wifarer San Francisco Airport MIT Mobile Universidad de Granada Universidad de Alabama Universidad Rey Juan Carlos Carrefour 3 7 7 3 3 7 3 7 3 3 7 3 3 3 3 7 3 3 7 3 7 3 3 7 Búsqueda de edificios disponibles 3 3 3 7 7 7 3 3 Uso de plano esquemático dibujado interior 7 7 3 7 7 7 3 3 3 3 3 7 7 7 7 3 7 7 3 3 7 7 7 3 3 3 3 3 7 7 3 3 Posicionamiento Visualización Búsqueda Ruta en interior de servicios de Origeninteriores servicios Destino Tabla 3.2: Comparativa de las aplicaciones que permiten realizar localizacion Indoor Indicación sobre mapa de edificios disponibles Uso de mapa cartográfico 7 7 3 7 7 7 3 3 Guiado 3.4 Conclusión Una vez finalizado el análisis de las aplicaciones que se han hallado se muestra en la Tabla 3.3 el resultado de todas las características deseables que ha de tener la aplicación. App Listas de la Compra App Localización Indoor Características - La app debe contener una base de datos con los productos del centro comercial al que va a estar destinada la app. - Los productos deben contener una imagen que haga más intuitiva la localización dentro del catálogo de productos. - Los productos deben tener un precio asignado. - Los productos pueden ser buscados de manera escrita o por comandos de voz. - El usuario puede crear varias listas. - El usuario puede visualizar el precio de la lista con los productos ya escogidos. - El usuario puede compartir la lista con cualquier otra persona. - El usuario puede añadir una alerta a cada lista para que le avise en una fecha concreta. - Indicación de los productos disponibles - Búsqueda de productos disponibles - Uso de plano esquemático dibujado interior - Posicionamiento interior - Visualización de Servicios interiores - Rutas Origen-Destino - Guiado Tabla 3.3: Características de ShoppingBeacon 40 Capítulo 4 Arquitectura E este capítulo se describen el diseño e implementación del sistema desarrollado, siguiendo un enfoque top-down en el que en primer lugar se realiza un resumen del sistema sin especificar detalles y a continuación se desarrolla cada parte del sistema con mayor detalle. Como ya se ha comentado, en primer lugar se proporciona una descripción general de la arquitectura del sistema, que sirve de introducción a los contenidos expuestos en el resto del capítulo. En segundo lugar se presenta los patrones de diseño en la que se basa el sistema y finalmente se presenta el estudio del diseño e implementación de cada uno de los módulos del sistema, describiendo las responsabilidades de cada módulo, las alternativas tecnológicas consideradas para su implementación, problemas surgidos en su desarrollo y soluciones planteadas y los detalles técnicos de los mecanismos finalmente planteados. N 4.1 Arquitectura General Ampliando la visión general de la arquitectura proporcionada en la Sección 2.1 del Capítulo 2, las siguientes secciones de este capítulo realizan un análisis de los diferentes aspectos significativos que describen cada una de las partes de la arquitectura. Esta distribución se muestra en la Figura 4.1, tras lo que se realiza un breve reconocimiento de los distintos componentes que comprende la plataforma. La plataforma se halla estructurada siguiendo el patrón MVC como se describe en la Sección 4.2, en el que cada vista posee su controlador y modelo asociado. Siguiendo el orden vertical, el primer nivel que se puede observar es el de presentación o interfaz de usuario (vista) que, como su nombre indica, es el medio a través del cual, el usuario interactúa con el sistema, solicitando la realización de operaciones y recibiendo resultados u otra información como pueden ser las notificaciones. El siguiente nivel se trata de la capa de controladores, responsable de operar directamente con cada una de las dos partes de la que consta la aplicación, ya que es el encargado de recibir a entrada del usuario y reaccionar en consecuencia. A continuación se encuentran de manera paralela las dos partes de la que consta la plataforma: Gestión y Acceso a Datos y Ubicación y Guiado. 41 Figura 4.1: Modelo de arquitectura del sistema Gestión y Acceso a Datos Es aquí donde se encuentra la base de datos de la aplicación. En el se pueden distinguir dos fachadas de operaciones que le permiten comunicarse con los niveles superior e inferior. La fachada de operaciones con listas, encargada de la operación y la comunicación del Módulo de Gestión y Acceso a Datos con el controlador mediante el uso de delegados, como se comenta en la Sección 4.2 y la fachada de operaciones de persistencia de datos se encargará de operaciones con la base de datos mediante una interfaz de operaciones, utilizada para garantizar la independencia entre las diferentes partes de la arquitectura. Ambas interfaces de 42 operaciones actúan sobre la lógica y las entidades de dominio del sistema. También se puede observar otros cuatro módulos cuya utilidad será detallada en el análisis de su arquitectura: Sistema de Consulta de Datos, Sistema de Creación de Listas, Sistema de Modificación de Listas y por ultimo el Sistema de Notificación de Eventos. Finalmente se encuentra la base de datos, encargada de almacenar todos los datos necesarios para la generación de listas y la consulta de datos, incluidas las listas que genera el usuario. Su estructura, analizada posteriormente, se comunica mediante la fachada de operaciones de persistencia de datos. Ubicación y Guiado Como nuestra la Figura 4.1, la arquitectura del sistema se encuentra estructurada modularmente y se compone de: Módulo de Comunicaciones: Se comunica con los distintos dispositivos que se encuentren dentro del recinto comercial para recibir los datos de entrada que serán procesados y convertidos en información válida para el módulo superior. Descrito en la Sección 4.6.1. Módulo de Tratamiento de Señal: Gestiona todas las señales que recibe haciendo una distinción según el dispositivo del que llega la señal. Descrito en la Sección 4.6.2. Módulo de Filtrado de Señal: Una vez conseguido un número determinado de señales de cada dispositivo, se procesan de manera concurrente mediante el uso de hilos para evitar los cuellos de botella y reducir el ruido aleatorio en el dominio de tiempo. Descrito en la Sección 4.6.3. Módulo de Posicionamiento: Una vez determinadas las posibles posiciones calculadas previamente en el módulo anterior, se decide cuál es la posición final del usuario. Descrito en la Sección 4.6.4. Módulo de Enrutamiento y Guiado: Se encarga de generar la ruta de menor coste con todos los productos seleccionados por el usuario, teniendo en cuenta el lugar de partida. Descrito en la Sección 4.6.5. Dispositivos: El sistema debe reconocer y obtener los datos que envíen independientemente del tipo de tecnología empleada (vease Anexo A) y del tipo de comunicación que utilicen. La siguiente posición junto con su descripción para guiar al usuario se mandará al controlador de la aplicación que será el encargado de actuar en consecuencia y comunicarse con la vista. 43 4.2 Patrones de Diseño Una de las cualidades de cualquier framework o SDK es que se deben utilizar los patrones de diseño que ofrecen al desarrollador, para así facilitar la implementación de una app. Dentro del SDK de iOS no es una excepción, y se han utilizado distintos patrones de desarrollo en los que se basa la aplicación y que a continuación se van a detallar. 4.2.1 Delegado Esta clase de patrón de diseño es frecuentemente usada en el desarrollo de aplicaciones en la plataforma iPhone OS. Normalmente suele ser la alternativa a la herencia. La delegación es una forma de extender y reutilizar la funcionalidad de una clase, escribiendo otra clase adicional con funcionalidad extra que usa instancias de la clase original para proveer su propia funcionalidad. Los delegados (delegate) son un patrón en donde un objeto actúa en nombre de un coordinador asociado a otro objeto. Un delegate básicamente delega el control de la interfaz de usuario para un evento, o al menos se le pregunta para interpretar el evento de una manera específica en la aplicación, es decir, mantiene una especie de vínculo con el objeto que le permite recibir los mensajes que el objeto genérico genera. El funcionamiento de un delegate permite coordinar su apariencia y estado con cambios que se producen en otras partes de un programa, cambia generalmente provocado por las acciones del usuario. Más importante aún, los delegates hacen posible que un objeto pueda alterar el comportamiento de otro objeto sin la necesidad de tener una relación de herencia entre los objetos. El delegate es casi siempre uno de los objetos personalizados, y por definición, incorpora la lógica específica de la aplicación que el objeto genérico no conoce. En muchas ocasiones, la delegación resulta más apropiada que la herencia. Por ejemplo, la herencia es útil para modelar relaciones de tipo es-un o es-una, ya que estos tipos de relaciones son de naturaleza estática. Sin embargo, relaciones de tipo es-un-rol- ejecutadopor son mal implementadas con herencia. En este tipo de relaciones, las instancias de una clase pueden jugar múltiples roles. Los métodos definidos con este patrón están agrupados en un protocolo. Los protocolos en iOS son métodos que actúan sobre un objeto y pueden ser implementados por cualquier clase. Básicamente tienen la declaración de una serie de métodos que ejecuta otra clase y se espera que le agreguemos funcionalidad según lo necesite cada una de las clases que invocan esta otra clase. Si una clase se ajusta a un protocolo, entonces garantiza que implementa los métodos obligatorios de ese protocolo, que además puede incluir métodos opcionales. En el caso de la aplicación desarrollada para este proyecto, se han usado muchos de los protocolos delegados que iPhone OS provee a los desarrolladores. Los componentes como la brújula, el acelerómetro o el bluetooh, requieren de la implementación de determinados métodos en las clases en las que se declaran instancias de las clases originales que hacen referencia a estos sensores. De este modo, los sensores envían la información que recogen 44 a los métodos implementados por sus delegados. También las vistas de tablas, las alertas de aviso, el envío de correo, las barras de navegación, etc. Además de los protocolos ya existentes, iOS proporciona la posibilidad de declarar nuevos protocolos de delegados que se adapten a las necesidades de una aplicación en concreto. En el caso de la aplicación desarrollada se ha implementado un protocolo de delegado por cada una de las vistas que aparecen en la aplicación 4.2.2 Target-Action Aunque el patrón delegado es útil para la comunicación entre los objetos de un programa, no es la manera más adecuada de comunicarse con la interfaz de usuario. La interfaz de usuario de una aplicación típica consiste en un conjunto de objetos gráficos y quizás los más comunes sean los controles (boton, slider, casillas de verificación,...). El papel de un control en la interfaz de usuario es simple: Interpreta la intención del usuario y da instrucciones a otro objeto de llevar a cabo esa solicitud. De esa manera, cuando un usuario actúa sobre cualquier control de la aplicación el dispositivo de hardware genera un nuevo evento. El control acepta el evento y lo traduce en una instrucción especifica de la aplicación. Un evento es generado por un usuario mediante cualquier interacción. Por ejemplo, que el usuario haga click sobre un botón generará un evento para que el que existirá un comportamiento predeterminado por parte del sistema. Estos comportamientos pueden ser cambiados ante un evento disparado, es decir se trata de manejadores (handlers). Los eventos, como se ha comentado anteriormente, no dan mucha información acerca de la intención del usuario. Simplemente refleja que el usuario hace click en un botón del ratón o pulsa una tecla, por lo que debe existir algún mecanismo encargado de realizar la traducción entre evento e instrucción. Este mecanismo se denomina Target-Action Este mecanismo se utiliza para la comunicación entre un control y otro objeto. La recepción del objeto, normalmente una instancia de una clase personalizada, se llama el objetivo. La acción es el mensaje que el control envía al objetivo. Por lo que, este patrón es uno de los que permitirá que desde la vista se puedan invocar manejadores del eventos presentes en el controlador. Es decir relacionar un evento de un objeto de la vista con una acción o método de un controlador. La relación será entre el objeto el evento(target) y la acción (action). 4.2.3 Modelo-Vista-Controlador (MVC) MVC define una separación clara entre los componentes críticos de la aplicación (Figura 4.2). Usando este patrón de diseño se obtiene una estructura definida que puede permitir a otros desarrolladores trabajar con el código implementado en un futuro. Además, aplicar esta clase de estructura permite reutilizar partes del proyecto para otras aplicaciones diferentes [Joh10]. Por ejemplo, la clase que pinta un botón en la pantalla, se podría reutilizar en 45 todos los botones que tiene la aplicación siempre y cuando esa sea su única responsabilidad. Si además de pintar un botón en la pantalla tuviese una lógica que se debe ejecutar al pulsar el botón, no se podría reutilizar, obligando a repetir el código que pinta un botón en la pantalla para cada uno de los botones de la aplicación. Como su nombre indica, se definen tres partes de la aplicación: Modelo: Proporciona los datos internos y los métodos que ofrecen información al resto de la aplicación. El modelo no define la apariencia o el comportamiento de la aplicación. Vista: Puede haber dentro de una misma aplicación una o más vistas, formada cada una de ellas por diferentes componentes (etiquetas, campos, botones, etc. ) con los que el usuario interactúa y conforman por tanto la interfaz de usuario. Controlador: Está vinculado a la vista. El controlador es el responsable de recibir la entrada del usuario y reaccionar en consecuencia. Los controladores pueden acceder y actualizar una vista usando información del modelo, así como actualizar el modelo con el resultado de las interacciones del usuario en la vista, es decir, enlaza los componentes del MVC. Es el cerebro de este patrón de diseño, haciendo trabajar a la vista y el modelo en sincronización para que el usuario pueda ver cosas en la pantalla o para que al presionar un botón sea efectuada alguna acción. El patrón MVC se explica mejor con la Figura 4.2: Figura 4.2: Objetos pertenecientes al patrón MVC El usuario interactúa con la aplicación y la vista (U objeto de la vista) a través de la interfaz de usuario. 46 La vista le envía un mensaje al controlador diciéndole por ejemplo que hemos presionado un botón y queremos que esto responda a alguna acción. El controlador recibe el mensaje y contacta con el modelo para realizar la acción y actualizar la información pertinente. El controlador recoge la información requerida por la vista pero actualizada por el modelo y por último actualiza la vista con los cambios que se han realizado sobre en el modelo. Como ya se ha comentado anteriormente, el controlador es el encargado de enlazar los componentes del MVC con los que mantiene una comunicación “ciega” y estructurada. A continuación se explica la comunicación entre los distintos componentes con la Figura 4.3 Figura 4.3: Comunicación entre los objetos del MVC En cuanto a la comunicación con la vista, el Controlador crea un objetivo (target) en si mismo, y repartirá acciones (action) a la Vista. Ésta será la encargada de enviar la acción a este objetivo cuando suceda algún evento en la interfaz de usuario como puede ser una pulsación sobre un botón de la Vista y será el Controlador el encargado de realizar las tareas necesarias para responder a ese evento. A veces, la Vista tiene que sincronizarse con el Controlador (para actualizar los datos de la misma), es entonces cuando este Controlador se fija como delegado de la Vista a través de un protocolo, ya que la Vista no es la propietaria de los datos que está mostrando, y en la mayoría de los casos es el Controlador el que actúa como origen de datos interpretando y formateando la información del Modelo. 47 El objeto encargado de delegar las funciones (en este caso la Vista) mantiene una referencia al otro objeto, el delegado (en nuestro caso el Controlador), y en el momento apropiado envía un mensaje a dicha referencia. El mensaje informa al delegado de un evento que el objeto que delega (la Vista), está a punto de manejar o simplemente ha manejado. El delegado puede responder al mensaje mediante la actualización de la apariencia o estado de la Vista. La principal ventaja de la delegación, es que permite personalizar fácilmente el comportamiento de varios objetos en un objeto central. En cuanto a la comunicación con el Modelo, no hay una comunicación directa, sino que el Modelo utiliza un mecanismo de transmisión que hace de “emisora de radio” permitiendo de esa manera a los controladores (u otros Modelos) poder “sintonizar” las cosas que les interesa. Este mecanismo son Notificaciones y KVO (Key-Value Observing) que permite a los objetos que se les notifique de los cambios en las propiedades de otros objetos. El aislamiento lógico creado entre las partes funcionales de una aplicación hace que el código sea más fácil de mantener, reutilizar y ampliar. El diseño MVC en el kit de desarrollo de Apple es natural. Cualquier proyecto creado en él sigue este patrón. Por lo tanto, el diseño de todas las vistas (capa de presentación) es llevado a cabo por la herramienta Interface Builder mientras que la lógica de la aplicación es implementada en la herramienta Xcode. 4.3 Posicionamiento en móviles Se pretende conseguir la posición más exacta posible del usuario o nodo móvil en tiempo real, de manera que el usuario no intervenga de manera activa en el cálculo de la solución propuesta. Hay múltiples técnicas que te permiten estimar la posición del usuario, procesando las señales recibidas por los nodos de referencia: Técnicas que utilizan el retardo de la señal como pueden ser Time of Arrival, Time Difference of Arrival, Roundtrip Time of Flight. Técnicas que se basan en el ángulo en que llega la señal como es Angle of Arrival Técnicas que se basan en la atenuación de la señal como es el caso de Received Signal Strength. Sin embargo los entornos de interiores presentan problemas de la reflexión de la señal que dificultan en gran medida el uso de estad técnicas. Este es el problema ampliamente conocido como del camino múltiple o multipath. Este problema establece que la señal puede llegar al nodo móvil desde varios lugares y con distintos ángulos, lo que dificulta establecer la posición exacta del nodo emisor de la señal [AMB10]. Este problema impide que un sistema de posicionamiento en un entorno interior pueda 48 basarse en las técnicas que estudian la forma en que llega esta señal, por el problema de los rebotes que se producirán en el entorno, por lo que se ha decidido calcular la posición del usuario utilizando las técnicas que se basan en la atenuación de la señal (RSS). Para la realización del presente Trabajo Fin de Grado se ha basado en la técnica basada en la fuerza de recepción de la señal (RSS). Concretamente se ha decidido utilizar el método RSSI (Received Signal Strength Indicator), basado en el modelo de la pérdida de la señal en el camino, que se produce de manera exponencial durante la transmisión. [BP00] Para ello, los nodos de referencia ofrecen un identificador unívoco. Como solución al problema del multipath y basándose en este identificador unívoco, se usa la fuerza de la señal recibida o RSS en tiempo real para localizar la posición del usuario o nodo móvil, haciendo uso de un sistema de posicionamiento [DC11] que permita consultar las posibles posiciones del nodo móvil según la fuerza de señal que obtiene de los distintos nodos de referencia. Este sistema de posicionamiento contendrá las coordenadas de los distintos nodos de referencia junto con la fuerza de señal que llega a las distintas coordenadas de la superficie comercial. Los motivos que inducen al uso de esta técnica son dos: No se puede usar un posicionamiento basado en un solo nodo, ya que hay una alta probabilidad de que el nodo móvil este a una posición equidistante a varios nodos de referencia. Un promedio de las coordenadas de los nodos de referencia dará una estimación mas cercana a la ubicación real del usuario que utilizando un único nodo de referencia. 49 4.4 Gestión y Almacenamiento Al tratarse de una aplicación para realizar la lista de la compra, la app debe contener dos funcionalidad básicas, la primera de ellas que muestre un catálogo de productos donde el usuario pueda escoger y una segunda funcionalidad básica que le permita crear una lista donde añadir los productos escogidos. Estas funcionalidades implican que la aplicación debe de tener datos que presentar y datos que almacenar. iOS ofrece diversos modos de llevar esto a cabo. Se pueden guardar los objetos sin procesar en un archivo y traducirlos junto con sus relaciones a XML o crear una base de datos SQLite. Con independencia del sistema que se utilice, se pueden escribir muchas rutinas para guardar, leer, encontrar, eliminar o actualizar una lista o producto. Con esta base de datos se gestiona lo principal pero aún se tiene que llevar a cabo trabajo adicional, como definir el modelo de datos SQL o diseñar y escribir consultas SQL. Core Data, la tecnología de almacenamiento de iOS, es un framework de persistencia avanzada que realiza gran parte de este trabajo de forma automática. Core Data no es una simple base de datos, sino mucho más. Incluye muchos comportamientos típicos de un ORM (Object-Relational Mapping) que se encarga de la transformación de las tablas de una base de datos, en una serie de entidades que simplifiquen las tareas básicas de acceso a los datos para el programador, así como otras muchas funcionalidades como pueden ser ordenar, filtrar, e incluso a una clase especial diseñada para trabajar con vistas de tabla, como es el caso del presente sistema, que a la hora de mostrar el catálogo de productos o las listas trabaja constantemente con vistas de tabla. El trabajo con Core Data dentro del presente Trabajo Fin de Grado se va a apoyar principalmente en tres conceptos: Modelado de datos Guardar información Recuperar información Apple recomienda la arquitectura MVC para integrar Core Data, la cual se concentra en la capa “Modelo”, por lo que Core Data se encontrará en la capa modelo de cada una de las vistas. Al igual que en la mayoría de bases de datos, la parte que gestiona los datos de Core Data se divide en tres capas principales: El lugar en el que se almacenan los datos El formato de los mismos Un entorno de acceso a ellos Los datos se guardan en los almacenes, y puede haber más de uno. El formato de los 50 datos se especifica con un modelo de objeto gestionado y el acceso se produce a través de un contexto de objeto gestionado. Podría haber varios contextos activos al mismo tiempo. Las clases correspondientes son las siguientes: NSPersistentStoreCoordinator: Coordina todos los almacenes utilizados para los datos. Para iOS suele haber un solo almacén en el dispositivo. NSManagedObjectModel: Describe todos los tipos de objetos de datos que se utilizan en las aplicaciones. NSManagedObjectContext: Es un gestor para un conjunto de objetos de datos. El contexto incluye las reglas que se usan para encontrar elementos de datos reales en los almacenes, algunos de estos elementos y su estado actual. Es posible tener múltiples contextos activos al mismo tiempo, con los mismos objetos en diferentes estados en cada uno. Los contextos vuelven a escribir los elementos en el almacén solo cuando se guardan. Con la intención de posibilitar la mejora del sistema en un futuro e integrar un servidor desde el que se puedan descargar y actualizar los datos, se ha decidido preparar la arquitectura para permitir añadir una base de datos externa al sistema para captar los datos e incluirlos dentro de un array de la misma manera que si se captaran los datos de un servidor, para posteriormente añadirlos a la tecnología de almacenamiento de iOS, Core Data. Por lo tanto habría dos partes bien diferenciadas: Recuperación de datos externos Uso de Core Data en la app 4.4.1 Recuperación de datos externos Lo que se quiere conseguir en este apartado es acceder a la base de datos externa SQLite para extraer todos los datos y posteriormente crear una base de datos interna en iOS mediante el uso de la tecnología Core Data para añadir todos los datos extraídos. En primer lugar se utiliza un editor visual para definir el modelo, que es un conjunto de objetos que representan los datos y las relaciones entre ellos, para la base de datos de Core Data, como muestra la Figura 4.4. El modelo de base de datos de Core Data presentado en la figura anterior se traduce en el diagrama entidad-interrelación de la Figura 4.5 Al tratarse de una relación de cardinalidad (n, n), además de las dos entidades que se pueden observar se hace necesario crear una tercera tabla que modelará dicha relación estableciendo la existencia de un producto en una lista, junto con el numero de unidades de dicho producto que se desea adquirir. Esto se traduciría en el modelo relacional del Listado 4.1. 51 Figura 4.4: Modelo Base de Datos Figura 4.5: Diagrama entidad-interrelación SShoppingList (index, name) SProduct (name, category, cost, image, position, orientation) SProductInList (index, name, units) SProductInList.index --> SShoppingList.index SProductinList.name --> SProduct.name Listado 4.1: Modelo relacional 52 A continuación se crean los constructores de las distintas entidades que aparezcan en la base de datos del sistema. Una entidad describe las partes de un elemento: los nombres de los atributos, los tipos de atributo y cualquier otra propiedad especial que permita manejar la interacción con la base de datos externa. Los elementos SProduct y SShoppingList corresponden a entidades de la base de datos interna de iOS. El siguiente paso ha sido garantizar que la base de datos tenga una instancia y un único punto de acceso global mediante el patrón de diseño singleton, el cual está diseñado para restringir la creación de objetos pertenecientes a una clase o el valor de un tipo a un único objeto. Una vez inicializada la instancia de la base de datos, se construye una ruta al fichero de la base de datos para acceder a ella. Comprometido con el objetivo de mejorar el sistema en un futuro y añadir una base de datos remota con los productos, se ha simulado una comprobación inicial encargada de registrar los posibles cambios en los productos como puede ser el precio o la ubicación. Al usarse una base de datos externa que no va a ser alterada, los productos añadidos a la tecnología de almacenamiento de iOS no van a cambiar y por lo tanto una vez que se realice el tránsito de datos de una base de datos a otra, no es necesario volver a repetir toda esta operación. Por lo tanto la comprobación inicial se trata de confirmar si es la primera vez que se inicia el sistema. Cada aplicación tiene un sistema de almacenamiento por defecto para cada usuario llamado User Default System (ahora UDS), el cual está compuesto por una base de datos en la que, a través de unos parámetros y métodos, se pueden almacenar y recuperar ciertos valores, que suelen ser pequeñas cantidades de datos que se usan comúnmente en la aplicación. A estos valores por defecto se les llama: preferencias del usuario. Por ejemplo, recordar la última vez que se inició la app, mostrar alarmas en intervalos de tiempo elegidos por el usuario o permitirle a los usuarios elegir cuán periódicamente sincronizar ciertos datos con iCloud, almacenando dichos valores en el UDS y recuperandolos al inicio de la aplicación. La clase NSUserDefaults permite interactuar con el UDS, proveyendo diversos métodos para guardar y recuperar datos desde esta base de datos por defecto. Se quiere comprobar si es la primera vez que se inicia el sistema, por lo que al iniciar el sistema se realiza una llamada al sistema de almacenamiento UDS, comprobando si es así. En el caso de que la contestación sea positiva se abrirá la ruta construida, y una habilitado el acceso a la base de datos externa se procede a recuperar todos los datos. Una vez recuperados los datos, se actualizan las preferencias de usuario indicando que ya no es la primera vez que se inicia la app. El siguiente paso sería añadir los distintos productos de la base de datos externa, a la base de datos interna de iOS. En caso contrario este se omite y se continúa con 53 la ejecución de la app, ya que contiene todos los datos necesarios. 4.4.2 Uso de Core Data Antes de poder usar los datos, se debe inicializar Core Data para la app y por tanto los objetos para cada una de las partes que componen Core Data: NSPersistentStoreCoordinator, NSManagedObjectModel, NSManagedObjectContext. El código para el uso de la tecnología Core Data se añade a la clase AppDelegate, ya que es la encargada de “escuchar y reaccionar” ante cualquier cambio de estado de la aplicación. Una vez inicializada la tecnología Core Data, definido el modelo de la base de datos e implementados los constructores de las entidades que aparecen sólo queda añadir el código para acceder, crear, eliminar y actualizar los datos dentro del sistema. Dentro de la app se presentan distintas vistas donde es necesario hacer uso de las funcionalidades que ofrece Core Data. Todas y cada una de las vistas siguen el patrón MVC, por lo que será el controlador de cada vista el encargado de realizar una petición a su modelo, donde se encuentra implementada la tecnología Core Data. A continuación se van a comentar las distintas acciones que se realizan haciendo uso de la tecnología Core Data: Acceder a los datos a través del contexto de objeto gestionado. Permitir a Core Data la adición y eliminación de productos a una lista. Permitir a Core Data la adición y eliminación de listas. Acceder a los datos a través del contexto de objeto gestionado Permitir a Core Data la adición y eliminación de productos a una lista. Todas las vistas que hacen uso de la tecnología Core Data tienen vista de tabla y trabajan con las entidades: SProduct y SShoppingList, por lo que es imprescindible acceder a la base de datos para consultar los datos que se deben mostrar al usuario. Lo primero que requiere la vista con la que se esté trabajando es una referencia al contexto de objeto gestionado. A continuación, en el Listado 4.2 se define el contenido de un array con los objetos actuales de la entidad con la que se va a trabajar, en este caso SProduct. En primer lugar, para obtener los datos del contexto de objeto gestionado es preciso describir los datos que se desean en una solicitud de recuperación (o FetchRequest). Esto es tan sencillo como especificar todos los objetos de un tipo de entidad determinado, o tan complejo como un filtro y una clasificación. La solicitud se utiliza como parte de executeFetchRequest:error:, un método NSManagedObjectContext para recuperar un array de objetos de datos gestionados. Se usa el mismo 54 método para obtener un conjunto de datos actualizados siempre que hay un cambio, como añadir o eliminar algún objeto. Como el array de productos se actualiza con diversos métodos en el controlador de tabla de productos, la solicitud de recuperación es otra variable de instancia. NSError *error = nil; fetchRequest = [NSFetchRequest fetchrequestWithEntityName: "SProduct"]; arrayOfProdcuts = [managedContextObject executeFetchRequest: fetchRequest error:&error]; if (error != nil){ NSLog("Unresolved error %, %", error, [error userInfo]); abort(); } Listado 4.2: Actualización del contenido del array En el anterior listado ocurre lo siguiente: Se configura la solicitud de recuperación para buscar todas las entidades de clase SProduct. Se establece el array de productos con todos los objetos gestionados en el contexto que cumplen con los criterios de la solicitud, en este caso, todos los productos. Si ocurre un error al leer los objetos, se queda registrado en un archivo para informar al usuario de lo que ocurre y lo que debe intentar. La llamada a abort() proviene de la plantilla proporcionada por el sistema. Lo único que hace es crear un registro de fallos y cerrar la app. Cada vez que se modifica un dato se genera un array nuevo. Esto funciona bien porque no hay muchos datos. Sin embargo a medida que el número de productos crece surgen problemas de rendimiento y posiblemente también de memoria. Además se necesita gran cantidad de código, porque si el contexto del objeto gestionado es encargado de generar el array, debe poseer información sobre la cantidad de productos incluidos y el orden en el que aparecen haciendo necesario tener código para calcular el número de productos, de secciones y de filas en una sección que va a poseer la tabla de la vista con la que se está trabajando, además de actualizar la tabla basándose en los cambios en los datos. En lugar de escribir todo este código, el sistema proporciona NSFetchedResultsController y los protocolos asociados. Están diseñados para facilitar la gestión de las tablas con objetos basados en Core Data haciendo lo siguiente: Configurar la sección y el número de filas de una tabla. Obtener el dato representado por una ruta índice. 55 Devolver títulos de encabezado de sección. Registrar cambios en el contexto de objeto gestionado y posibilitar actualizaciones de tabla mediante un protocolo delegado. Recuperar datos en grupos y en modo opcional almacenar datos en un archivo para mejorar el rendimiento. Se va a transformar la tabla de productos para utilizar un controlador de resultados recuperados para el control básico de la tabla y la presentación. A continuación se añadirán secciones y ordenación. Lo primero que se necesita es una variable de instancia que contenga el controlador de resultados recuperados: NSFetchedResultsController * fetchedResultsController A continuación, como muestra el Listado 4.3, se inicializa el controlador de resultados recuperados, configurando una solicitud de recuperación adecuada, ya que NSFetchedResultsController asocia el resultado de aplicar una solicitud de recuperación a un contexto de objeto gestionado. En el listado 4.3 anteriormente referido se utiliza un simple NSFetchRequest para devolver todas las entidades de SProduct, sin embargo el controlador de resultados recuperados requiere al menos un filtro y una ordenación. El filtro puede ser nulo, pero para ordenar es necesario especificar un criterio como mínimo. - (void)fetchCatalogProduct { NSError *error = nil; self.fetchRequest = [NSFetchRequest fetchRequestWithEntityName:@"SProduct"]; NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc] initWithKey:@"category" ascending:YES]; [self.fetchRequest setSortDescriptors:[sortDescriptor]]; self.fetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:self.fetchRequest managedObjectContext:self.managedContextObject sectionNameKeyPath:@"category" cacheName:nil]; self.fetchedResultsController.delegate = self; 56 [self.fetchedResultsController performFetch:&error]; if (error != nil) { NSLog(@"Unresolved error %@, %@", error, [error userInfo]); abort(); } [self.myDelegate productCatalogControllerModel: self.fetchedResultsController]; } Listado 4.3: Solicitud de recuperación de datos En el anterior listado ocurre lo siguiente: Se configura una ordenación sencilla en función de la categoría del producto. Se definen los descriptores correspondientes de la solicitud de recuperación con el criterio de ordenación nuevo. Se inicializa el controlador de resultados recuperados usando la solicitud de recuperación recién asignada y el contexto de objeto gestionado del delegado de la aplicación. Se indica al controlador que lea el conjunto inicial de datos y gestione cualquier error que pueda ocurrir. Se avisa al delegado, que corresponde a la vista, para que se encargue de actualizar la variable de instancia que contiene el controlador de resultados recuperados, con el que se trabaja en las vistas de tabla para mostrar los datos al usuario. Cada vez que se actualizan los datos del contexto de objeto gestionado añadiendo, eliminando o modificando alguno, se envía performFetch al controlador de resultados recuperados. La llamada resulta en más trabajo en términos de procesamiento que si sólo se actualizaran los datos modificados. El controlador de resultados recuperados tiene la capacidad de observar cambios en el contexto de objeto gestionado y de invocar métodos cuando ocurren estos cambios. Tan sólo es necesario ofrecer soporte al protocolo NSFetchedResultsControllerDelegate y por tanto modificar la declaración del protocolo añadiendo NSFetchedResultsControllerDelegate @interface ProductCatalogTableViewController : UITableViewController <NSFetchedResultsControllerDelegate > A continuación se define ProductCatalogTableViewController como delegado del controlador de resultados recuperados: self.fetchedResultsController.delegate = self; 57 Una vez definido ProductCatalogTableViewController como delegado del controlador de resultados recuperados, éste le envía mensajes siempre que ocurre un cambio en el contexto de objeto gestionado mediante tres llamadas que se encargan de facilitar la gestión de las actualizaciones de la tabla: controllerWillChangeContent: Se invoca cuando parte del contenido va a cambiar pero antes de que se modifiquen los resultados recuperados. - (void)controllerWillChangeContent:(NSFetchedResultsController *)controller { [self.tableView beginUpdates]; } Listado 4.4: Solicitud de recuperación de datos controllerWillChangeContent: controller:didChangeObject:atIndexPath:forChangeType:newIndexPath: Se invoca una vez completado el cambio y actualizados los resultados recuperados. El mensaje se envía una vez con cada cambio y se podría invocar varias veces entre llamadas a controllerWillChangeContent: y controllerDidChangeContent: - (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type newIndexPath:(NSIndexPath *)newIndexPath { UITableView *tableView = self.tableView; //Se determina que tipo de actualizacion hacer en base al tipo de modificacion switch(type) { //Cuando se inserta un objeto nuevo, se inserta tambien una celda en el lugar apropiado de la tabla case NSFetchedResultsChangeInsert: [tableView insertRowsAtIndexPaths:@[newIndexPath] withRowAnimation: UITableViewRowAnimationFade]; break; //Se elimina un objeto, por tanto, se borra la celda correspondiente case NSFetchedResultsChangeDelete: [tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation: UITableViewRowAnimationFade]; break; //Se cambia o se actualiza un objeto. Se actualiza la celda que representa los datos case NSFetchedResultsChangeUpdate: //code to update the content of the cell at indexPath break; //Se traslada la celda de datos de un lugar a otro de la tabla 58 //Se elimina la celda antigua e inserta una nueva case NSFetchedResultsChangeMove: [tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation: UITableViewRowAnimationFade]; [tableView insertRowsAtIndexPaths:@[newIndexPath] withRowAnimation: UITableViewRowAnimationFade]; break; } } Listado 4.5: Solicitud de recuperación de datos forChangeType:newIndexPath: controllerDidChangeContent: Se invoca una vez completados los cambios y actualizados los resultados recuperados. - (void)controllerDidChangeContent:(NSFetchedResultsController *)controller { [self.tableView endUpdates]; } Listado 4.6: Solicitud de recuperación de datos controllerDidChangeContent: Permitir a Core Data la adición y eliminación de productos a una lista La mejor acción sobre la vista que permite añadir o eliminar un producto de la lista consiste en seleccionar la celda del producto y si aparece un tick verde quiere decir que la lista contiene el producto, mientras que si aparece un tick gris quiere decir que la lista no contiene ese producto. Al estar trabajando sobre una lista que puede contener o no los productos seleccionados se debe comprobar si el producto aparece en la lista antes de tomar una decisión. Para ello, lo primero es acceder a los datos a través del contexto de objeto gestionado y a continuación comprobar si el producto que ha seleccionado el usuario aparece en la lista. En el caso de que el producto aparezca en la lista, se elimina de la lista, mientras que en caso contrario se añadiría. Seguidamente se actualiza la lista con la que se trabaja, se guarda la nueva lista en el contexto actual de objeto gestionado, se modifica la celda para cambiar la imagen del tick y finalmente se avisa al delegado, que corresponde a la vista, para que se encargue de actualizar la variable de instancia que contiene el controlador de resultados recuperados con el que se trabaja en las vistas de tabla para mostrar los datos al usuario. - (void)selectCell:(AddProductTableViewCell *)selectedCell shoppingListToView:(SShoppingList *)shoppingListToView{ NSError *error = nil; 59 //Se pasa nuestra lista de productos y el nombre de la celda seleccionada BOOL appear = [self sameObject:selectedCell.title.text]; int index = [self findName:selectedCell.title.text]; if(appear){ NSLog(@"Elemento Repetido"); NSLog(@"Se elimina de la lista: %@",[self.arrayOfProducts[index] name]); [shoppingListToView removeProductObject:self.arrayOfProducts[index]]; } //Sino aparece seleccionada, se selecciona y se incorpora a nuestra lista de productos else{ NSLog(@"Elemento No Repetido"); NSLog(@"Se incorpora a la lista: %",[self.arrayOfProducts[index] name]); [shoppingListToView addProductObject:self.arrayOfProducts[index]]; } //Actualizamos los productos de nuestra lista [self updateListProducts:shoppingListToView]; //Guardamos el resultado [self.managedContextObject save:&error]; [self.fetchedResultsController performFetch:&error]; //Modificamos la Celda [selectedCell modifyImageCell]; [self.myDelegate addProductControllerModel: self.fetchedResultsController]; } Listado 4.7: Solicitud de recuperación de datos de la capa de vista En el Listado 4.7 ocurre lo siguiente: Se comprueba si el producto existe en la lista. Si existe en la lista, se borra de la lista. Si no existe, se añade a la lista. Se actualiza la lista con la que se trabaja. Se guarda la nueva lista en el contexto actual de objeto gestionado. Se indica al controlador de resultados que lea el conjunto inicial de datos y gestione cualquier error que pueda ocurrir. Se modifica la celda para cambiar la imagen del tick. 60 Se avisa al delegado, que corresponde a la vista para que se encargue de actualizar la variable de instancia que contiene el controlador de resultados recuperados con el que se trabaja en las vistas de tabla para mostrar los datos al usuario. Permitir a Core Data la adición y eliminación de listas La creación y adición de nuevas listas se realiza de manera análoga a la creación y eliminación de listas. Los pasos que se deben seguir para la creación de una nueva lista serían los siguientes: Se crea una lista nueva en el contexto actual de objeto gestionado Se inicializan los atributos de la nueva lista Se guarda la nueva lista en el contexto actual de objeto gestionado Se indica al controlador de resultados que lea el conjunto inicial de datos y gestione cualquier error que pueda ocurrir. Se avisa al delegado, que corresponde a la vista, para que se encargue de actualizar la variable de instancia que contiene el controlador de resultados recuperados con el que se trabaja en las vistas de tabla para mostrar los datos al usuario. En el caso de que se quiera borrar la lista, se realiza lo siguiente: Se indica al contexto de objeto gestionado que elimine el objeto SShopingList con el índice perteneciente a la celda que se ha seleccionado. Se indica al controlador de resultados que lea el conjunto inicial de datos y gestione cualquier error que pueda ocurrir. Se avisa al delegado, que corresponde a la vista, para que se encargue de actualizar la variable de instancia que contiene el controlador de resultados recuperados con el que se trabaja en las vistas de tabla para mostrar los datos al usuario. 4.5 Ubicación y Guiado Se encarga de guiar al usuario mediante el estudio de la señal. Para calcular la posición del usuario, se basa en la señal recibida como se ha comentado anteriormente. Sin embargo uno de los grandes problemas es la fluctuación de la potencia de la señal producida por diferentes motivos como pueden ser la Reflexión, la Refracción, la Difracción el Scattering y el Multitrayecto, incidiendo directamente en la perdida de precisión en la localización. Es por ello que la parte de Ubicación y Guiado se ha desarrollado siguiendo una arquitectura modular, en la que cada módulo desempeña un papel fundamental en la localización del usuario. 61 El módulo de comunicaciones será el encargado de recibir el flujo de datos y procesarlos para convertirlos en información válida. Con estos datos y para eliminar el ruido que pueda ocasionarse, todas las señales se pasarán por un filtro que permita eliminar el ruido. Este filtro debe hacer distinción entre las señales de los distintos dispositivos, por lo que antes de pasar el filtro las señales deben ser tratados en un módulo de tratamiento de señal. En dicho módulo serán almacenadas en un buffer y a continuación de manera paralela mediante el uso de hilos para evitar los cuellos de botella cada uno de los buffer pertenecientes a los distintos dispositivos será procesado por el módulo de filtrado de señal que se encargar de eliminar el ruido y determinar cuál es la intensidad de señal. Una vez calculada la intensidad de señal de cada dispositivo se pasará al módulo de posicionamiento que determinará en función de las señales previamente calculadas la posición del usuario. Una vez calculada la posición del usuario, si es la primera vez que se genera una posición y por tanto no hay ruta establecida, se genera una nueva ruta. Si por el contrario ya hay una ruta establecida se comprueba la posición que tiene el usuario y la que debería tener. En el caso de que sea correcta la posición del usuario, se mantiene la ruta y se dan ordenes mediante voz a través del submódulo de Guiado, en caso contrario se genera una ruta nueva con el punto de origen en el que se encuentra el usuario y se vuelve a guiar al usuario a través del submódulo de Guiado. Toda esta información pasará a la capa de controladores, que será la encargada de notificarlo al usuario. 4.5.1 Módulo de Comunicaciones El módulo de comunicaciones es el encargado de recibir el flujo de datos proveniente de los recursos hardware iBeacon. Su función será encargarse de la comunnicación con los dispositivos, recibir los datos de entrada, procesarlos y convertirlos en información válida. Es necesario controlar esa comunicación y administrar los datos que se reciben. Por lo tanto ha de asegurarse la recepción de los datos y, para tratar los casos de diferencia entre frecuencia de recepción de datos y frecuencia de uso de esos datos, algún sistema de almacenamiento intermedio. Para proporcionar la funcionalidad descrita se han diseñado los siguientes submódulos: Un primer submódulo encargado de leer de forma asíncrona todos los datos de entrada. Un segundo submódulo encargado de procesar los datos de entrada para convertirlos en información válida. Un tercer submódulo encargado de recoger los datos ya procesados del segundo módulo y almacenarlos en un buffer intermedio entre el nivel de comunicaciones y el nivel de tratamiento de señal. De esa manera, teniendo una entrada de datos irregular, se puede dar una salida de datos más uniforme. Gráficamente, la descripción funcional del nivel de comunicaciones es la 62 mostrada en la Figura 4.6. Figura 4.6: Descripción Funcional del módulo de Comunicaciones Aunque los dispositivos Bluetooth llevan a cabo una transmisión periódica con una frecuencia casi constante de datos sin establecer conexión con otros dispositivos, esta transmisión puede sufrir pequeñas variaciones debido a retardos aleatorios de 10ms en cada pulso para evitar interferencias entre varios iBeacon situados en el mismo entorno y por tanto una entrada irregular de trama de datos o Payload Data Unit (PDU). Estas tramas se leerán de forma asíncrona sin bloquear la entrada de datos, se procesarán los datos para convertirla en información válida y finalmente pasarán al submodulo de almacenamiento hasta que transcurra un tiempo determinado y se proporcionen los datos almacenados en ese lapso al siguiente nivel. La salida del módulo es regular debido a que el submódulo de almacenamiento informa al nivel de tratamiento de señal con cierta frecuencia, una frecuencia menor que el pulso del dispositivo Bluetooth de manera que sólo mande una trama por cada dispositivo localizado en el recinto, aunque la cantidad de señales que pueda mandar en un instante de tiempo no sea la misma, ya que eso dependerá de la cantidad de dispositivos que se reconozcan en ese determinado instante y por lo tanto la distancia a la que se encuentren. En cuanto a la dependencia con otros módulos, al ser el módulo de menor nivel, no tiene tales dependencias. Es en la salida donde presenta interacción con el módulo de tratamiento de señal, ya que se encarga de proporcionarle un flujo de tramas que éste tiene la responsaibilidad de convertir en información válida para calcular la posición del usuario. Solución El objetivo buscado es que el módulo de Comunicaciones sea capaz de administrar los datos que se reciben de una forma eficiente y robusta. Además debe establecer un almacenamiento adecuado y óptimo para proporcionar al módulo de tratamiento de señal una entrada consistente y constante. Para ello, se establecen una serie de características u objetivos de desarrollo: 63 Se deben leer los datos de forma asíncrona. Se debe procesar la lectura y convertirla en información válida Finalmente almacenar toda la información valida en un array que valga de entrada a el módulo de tratamiento de señal. Antes de comenzar con la resolución del problema se debe saber cómo está formada la trama y es por ello que se va a comentar la estructura de cada una de las tramas emitidas por los distintos dispositivos mediante su representación gráfica como muestra la Figura 4.7. Figura 4.7: Estructura de una trama de un iBeacon sobre BLE. Código de Sincronización: Tiempo que utiliza el iBeacon para transmitir, utilizado por el dispositivo receptor para referenciar la recepción de la señal. Dirección de Acceso: contiene dos tipos de datos: Datos Fijos y preestablecidos: Encargados de referenciar el canal estándar utilizado para comunicaciones Low Energy. Datos Variables del canal: Utilizado por el iBeacon para realizar conexiones. Carga útil: Se trata de la parte que incluye lo necesario para que los dispositivos receptores puedan realizar las diferentes acciones como pueden ser la localización e identificación del iBeacon. Para ello se utilizan diferentes campos que son explicados a continuación [Org]. Cabecera: Indica que se trata de una transmisión en modo broadcast y además informa de la cantidad de datos que se transmitirán posteriormente. AD Address: Indica la dirección MAC del iBeacon y datos específicos del generador de la notificación (empresa, organismo...) [Blu]. AD Structure: Está subdividido en AD type, que indica el tipo de datos a transmitir, AD length, que indica la longitud de los datos transmitidos y AD data, que codifica la notificación que se quiere transmitir. 64 UUID: Se trata de un identificador estándar (norma ISO / IEC11578 [14]) único y universal utilizado en entornos de computación distribuida (no necesita coordinación central). Aparece generalmente representado por 32 dígitos hexadecimales de la siguiente forma [8-4-4-4-12], por ejemplo: 2150d9400-f21b-51e4-b256-416354530000. Su función en un sistema iBeacon es identificar a todas las balizas pertenecientes a un mismo grupo. Major: Especifica un subgrupo de balizas dentro de un grupo principal. Minor: Identifica a una baliza dentro de un subgrupo Tx Power: Indicador de potencia de transmisión del iBeacon (teórica) a un metro de distancia medida en dBm. CRC: Por último la verificación de la trama de datos con un código de detección basado en CRC (Cyclic Redundancy Check). Dentro de esta trama están todos lo datos necesarios para calcular la posición del usuario utilizando las técnicas que se basan en la atenuación de la señal (RSS). Esta técnica denominada posicionamiento por proximidad, esta basada en el cálculo de la distancia de un iBeacon a partir de la potencia de la señal recibida (RSS). La distancia estimada por una baliza se basa en la relación entre la potencia de la señal recibida (RSS) por el dispositivo que capta la señal y la potencia calibrada (Tx Power) de la baliza, obteniendo como resultado el RSSI (Received Signal Strength Indicator) que toma la siguiente expresión: RSSI[dBm] = −(10 ∗ n)log10 (d)A (4.1) Siendo: n = constante de pérdidas por propagación. Toma valores entre 2.7 y 4. Para propagación en el vacío, n= 2. d = distancia entre emisor y receptor en metros. A = Tx power medida en dBm. Despejando el valor d de la expresión 4.1, se obtiene la distancia relativa entre el emisor y receptor. La precisión en la posición dependerá por tanto de la potencia de señal recibida (RSS) y el valor de la potencia calibrada (Tx Power), por lo que es necesario una correcta calibración previa del iBeacon para tener ajustado el valor Tx Power. Un beacon no tiene aplicación por sí mismo, simplemente es un periférico que emite ondas de baja frecuencia de forma continua, cuyo único propósito es avisar de su presencia haciendo que cualquier otro objeto pueda ser localizado de forma sencilla. Se podría colocar un beacon en cualquier lugar alrededor del que se que se quisiera registrar un contexto, notificando a su app pertinente solamente cuando se esté cerca de ese lugar, 65 es decir, cuando es relevante. Esa app debe ser capaz de entender la señal y actuar en función de su contexto. Cada iBeacon lleva asociada información unívoca en cada trama: UUID Major Minor El UUID se encarga de identificar todos los ibeacons que se van a utilizar y el major y el minor se encargan de identificar areas concretas. Adaptando este concepto al uso del presente trabajo, el UUID se encargaría de identificar la cadena de supermercados, el major podría identificar la tienda física y el minor se encargaría de identificar áreas concretas de la tienda física como puede ser la caja o cualquier sección del establecimiento. Al trabajar dentro de un área concreta, no es necesario utilizar los tres identificadores de los iBeacons, sino que bastaría con el UUID que identifique la región en la que se trabaja y cualquiera de los identificadores que se refieren a secciones concretas. De manera indiferente se ha optado por utilizar el major. Al usar tres dispositivos iBeacon hay que saber a cuál hace referencia la señal que se capta y es por ello que se hizo una prueba inicial para identificar el major de cada dispositivo. La prueba consistió en colocar cada uno de los iBeacon cerca del nodo móvil para saber cuál de ellos llega con más frecuencia, procesar la información e identificar el major para acto seguido referenciar cada uno de los major a cada dispositivo iBeacon. Como se ha comentado anteriormente, una vez identificado el major de cada dispositivo se referencia para poder trabajar con ellos: static const unsigned short greenBeacon = 62264; static const unsigned short purpleBeacon = 52895; static const unsigned short blueBeacon = 30039; Listado 4.8: Identificación y Registro del major de cada dispositivo Se debe tener en cuenta que los iBeacons no tienen un centro geográfico (ni un radio como tal). Aquí las regiones las definen los beacons, por lo que se tiene que registrar el id de región con el que se va a trabajar y el UUID. Cuando el sistema detecte un iBeacon le preguntará por el nombre de su región que, se habrá establecido con anterioridad y si resulta que se encuentra dentro de la establecida, la app se limitará a escuchar/monitorizar las balizas que se detecten (quedándose con la más cercana) y a procesarlas según las variables vistas antes: el proximity UUID, el major y el minor. Por lo tanto el siguiente paso es definir el UUID y la región en la que se va a trabajar: 66 static NSString * const kUUID = @"B9407F30-F5F8-466E-AFF9-25556B57FE6D"; static NSString * const kIdentifier = @"LabMami"; Listado 4.9: Definir el UUID y región con los que se va a trabajar Una vez definida la región e identificados los valores de cada iBeacon se procede a localizar las balizas monitorizando la región establecida. Siguiendo los puntos de desarrollo que se han establecido al principio, se necesita comenzar a leer las tramas de forma asíncrona. Para ello iOS proporciona el framework Core Location, que se encarga de la comunicación con los distintos dispositivos iBeacon de forma transparente al desarrollador. También proporciona los mecanismos necesarios para procesar la lectura y convertirla en información válida a la par que la almacena. Para ello lo primero que se debe hacer es añadir el framework Core Location y añadir el protocolo asociado <CLLocationManagerDelegate> a la cabecera de la vista en la que va a ser utilizado. El siguiente paso es definir una región en CoreLocation. Para ello de manera transparente al desarrollador se realiza una llamada al método delegado registerBeaconRegionWithUUID: andIdentifier:, a la hora de definir la región como muestra el Listado 4.3 self.beaconRegion = [[CLBeaconRegion alloc] initWithProximityUUID:proximityUUID identifier: kIdentifier]; [self.locationManager startMonitoringForRegion:self.beaconRegion]; Listado 4.10: Identificación y Registro del major de cada dispositivo Este método delegado será el encargado de registrar la región en la que se encuentran los dispositivos iBeacons con los que se va a trabajar. Una vez registrada la región, se procede a monitorizarla en busca de regiones que contengan su identificador y el UUID de los beacons que se emplean. El siguiente paso es detectar cuándo se encuentra dentro de la región con el método delegado locationManager: didDetermineState: forRegion:. Este método delegado será el encargado de notificar que el dispositivo se encuentra dentro de una región. Una vez localizada la región en la que se encuentran los iBeacons, el siguiente paso es detectarlos implementando el método locationManager: didRangeBeacons: inRegion: que será el encargado de avisar cuando haya iBeacons en las cercanías y devolverá un array de todos ellos, en orden de cercanía (el primero será el que esté más cerca). Como conclusión a la solución, se presenta un diagrama de secuencia correspondiente a la Figura 4.8 67 Figura 4.8: Diagrama de Secuencia del Módulo de Comunicaciones 4.5.2 Módulo de Tratamiento de Señal Este modúlo tiene como función recibir el flujo de datos, procesado y convertido en información válida con la que se pueda tratar proveniente del módulo de comunicaciones y tratarlo haciendo una distinción según el dispositivo del que llega la señal, para a continuación almacenarlo en un buffer correspondiente a cada dispositivo. Para desempeñar estas funciones se han diseñado los siguientes submódulos: Un primer submódulo encargado de leer los datos de entrada pertenecientes a las señales procesadas del módulo de comunicaciones y hacer una distinción, clasificando las distintas señales segun el dispositivo del que procedan. Un segundo submódulo encargado de recoger los datos ya procesados y almacenarlos en el buffer perteneciente al dispositivo al que pertence la señal. Gráficamente, la descripción funcional del nivel de tratamiento de señal es la mostrada en la Figura 4.9 Cuando el sistema informe mediante el método delegado locationManager: didRangeBeacons: inRegion: de la llegada de señales procedentes de iBeacons en las cercanías, con un array con todas las señales, se procesará ese array para distinguir las señales de los distintos dispositivos y clasificarlas en los buffer pertenecientes a cada dispositivo iBeacon. Una vez clasificados y rellenados los buffer de cada dispositivo se pasarán a la capa superior, al modulo de Filtrado de Señal. Este módulo se relaciona por debajo con el módulo de Comunicaciones, del que obtiene las distintas señales y, al producir la salida con el módulo de Filtrado de señal, al que manda los distintos buffer, pertenecientes a cada dispositivo, albergando señales del dispositivo tratado. Este módulo planteó un problema a la hora de determinar la cantidad de muestras que 68 Figura 4.9: Descripción Funcional del módulo de Tratamiento de Señal debía tener para poder procesarlas en el módulo de Filtrado de Señal, ya que si la muestra era demasiado corta, el filtro sería ineficiente y, si por el contrario, la muestra es demasiado grande, la aplicación se quedaría congelada esperando a conseguir ese numero suficiente de señales en cada unos de los buffer de cada dispositivo, antes de poder pasar la información al módulo de Filtrado de señal. Otro problema que surgió y no se había tenido en cuenta fue la frecuencia con la se consultaba si había señales, ya que si la frecuencia era demasiado baja, el usuario podría moverse suficientes metros como para estar en una sección diferente y la aplicación seguiría teniendo las localizaciones anteriores. De la misma manera que se puede modificar la frecuencia con la que se preguntan por nuevas señales, se procede a la búsqueda de referencias e información acerca de la posibilidad de configurar la frecuencia de emisión de señales en dispositivos iBeacon. Solución A la hora de determinar la cantidad de muestras que debía tener cada uno de los buffer de almacenamiento de cada dispositivo se realizaron varias pruebas, obteniendo como conclusión que una cantidad de 10 muestras es idónea, ya que según las pruebas entre 6 y 7 de cada 10 señales son correctas y por lo tanto permite pasarle el filtro correctamente. El primer paso será hacer una distinción de cada una de las señales como se muestra en el Listado 4.4 switch ([beacon.major integerValue]) { case 62264: //Green 69 [self addRssiBeacon:beacon to:self.greenBeaconArray color:1]; break; case 52895: //Purple [self addRssiBeacon:beacon to:self.purpleBeaconArray color:2]; break; case 30039: //Blue [self addRssiBeacon:beacon to:self.blueBeaconArray color:3]; break; default: break; } Listado 4.11: Distinción del tipo de señal segun el major de cada dispositivo Una vez se tengan 10 señales de cada dispositivo se mandan al módulo de Filtrado de señal implementando un enfoque multi-hilo que permita ejecutar el filtro de cada buffer en un hilo de ejecución diferente, de forma que no sobrecargue el hilo principal de trabajo. Para ello Objetive-C proporciona el uso de bloques que, se encarga de la creación y gestión de hilos de forma transparente al desarrollador. En el momento en el que se tengan 10 señales, siempre que llegue una nueva se borrará la última que se encuentre en la cola y se añadirá la nueva al principio de la cola para que de esa manera el filtro sea más eficiente. Para ello las señales deben estar en un contenedor de tipo NSMutableArray que permite añadir y eliminar elementos en el orden que desee el desarrollador. El otro problema se trata de la frecuencia con la que se escanean cambios en la monitorización de regiones. iOS por defecto hace lecturas a 1Hz, es decir, una lectura por segundo aumentando aun más la frecuencia si el usuario se mantiene en movimiento y disminuyendola cuando está quieto en contraposición al consumo de batería que aumenta cuanto mayor es la tasa de actualización. A la hora de buscar la frecuencia de emisión de señales idónea de los dispositivos iBeacon de Estimote se partió del SDK de Estimote. El SDK de Estimote es un wrapper sobre Core Location con funciones añadidas para modificar el UUID, el major, el minor, la fuerza de la señal y la frecuencia de emisión de señales. Por lo tanto se realizó una prueba (consultar Seción 6.2 del Capítulo 6 para mas información) con el fin de analizar cuál es el mejor valor para la frecuencia de emisión de señales. Esta prueba consistió en la toma de 30 medidas conjuntas de RSSI de las tres balizas para intervalos de repetición de pulsos de 100 ms, 500 ms, 1000 ms, 1280 ms y 1500 ms, llevando a cabo el análisis numérico y gráfico de los resultados con el fin de determinar la mejor configuración para una señal estable, obteniéndose un intervalo de repetición de 70 pulsos de 1500 ms, ya que presentan una mayor estabilidad en la propagación con unas estimaciones de distancias aceptables. Por lo tanto, se optó por modificar la frecuencia de emisión de señales a 1500 ms. Como conclusión a la solución, la Figura 4.10 muestra un diagrama de secuencia presentando el comportamiento de este módulo. Figura 4.10: Diagrama de Secuencia del Módulo de Tratamiento de Señales 4.5.3 Módulo de Filtrado de Señal Este módulo tiene como función recibir un array con un conjunto de señales pertenecientes a cada uno de los dispositivos iBeacon que se utilizan para la localización del usuario y procesar las distintas señales para eliminar las posibles fluctuaciones de señal y estimar la señal adecuada. Este módulo se relaciona por debajo con el módulo de Tratamiento de Señal, del que obtiene el array de señales pertenecientes a cada uno de los beacons y al producir la salida con el módulo de Posicionamiento, al que manda la estimación de la señal calculada. Para desempeñar esta labor, se han diseñado dos submódulos: Un primer submódulo encargado de la gestión y control del flujo de entrada. Un segundo submódulo encargado de proporcionar operaciones matemáticas sobre el array de señales que se recibe de entrada para producir la salida deseada. Gráficamente, la descripción funcional del nivel de tratamiento de señal es la mostrada en la Figura 4.11 La necesidad de implementar este módulo es debida a uno de los grandes problemas en un sistema de posicionamiento, la fluctuación de la potencia de la señal [LHCGHCMHJW10]. Incluso en una localización fija, la fuerza de la señal en un punto puede presentar grandes variaciones. Howard, Siddiqi y Sukthane [AH11] han demostrado que esta variación se mantiene en un rango de 10 dB como muestra la Figura 4.12 71 Figura 4.11: Descripción Funcional del módulo de Filtrado de Señal Figura 4.12: Fluctuación de la potencia de la señal Aunque el rango teórico máximo de distancia para un iBeacon es de 70 metros en condiciones ideales, a la hora de calcular una correcta posición, hay varios factores a tener en cuenta que afectan de manera notable a la fluctuación del RSSI. Esta fluctuación puede producirse por diferentes motivos [Gho]: Reflexión: Cambio de dirección de la onda, que al entrar en contacto con la superficie de separación entre dos medios diferentes, regresa al punto donde se originó. Refracción: Cambio de dirección de la onda al pasar de un medio material a otro. Difracción: Desviación de la onda al encontrar un obstáculo. Dispersión(Scattering): Separación de la onda de distinta frecuencia al atravesar un material. Multitrayecto: Propagación de una onda por varios caminos diferentes. Orientación relativa entre emisor/receptor. 72 Al no tenerse en cuenta estos motivos, causantes de la fluctuación de la señal en los cálculos de distancia, se ven directamente reflejados en la distancia entre emisor y receptor (d). Es por ello que el posicionamiento del iBeacon por proximidad utiliza un sistema de referencia relativo y centrado en el receptor estableciendo la situación en tres rangos dependiendo del valor en el que oscila d, como se muestra en la Figura 4.13 Figura 4.13: Rangos de proximidad a un iBeacon Estos tres rangos son: Immediate: Rango comprendido en el intervalo 0.1 <d <1 (metros). near: Rango comprendido en el intervalo 1 ≤ d <10 (metros). far: Rango donde la distancia d ≥ 10 (metros). Solución Este problema de fluctuación de señal, que incide directamente en la pérdida de precisión en la estimación de la localización, trata de minimizarse mediante la aplicación de un filtrado que permita eliminar los valores extremos. Este filtro consiste en una media móvil, es decir, un cálculo utilizado para analizar un conjunto de datos para crear una serie de promedios. Esta media móvil se calcula para una serie temporal con una demanda estable, de manera que permita suavizar las fluctuaciones de plazos cortos y resalte las tendencias o ciclos de plazo largo. En la elección de la media móvil que actúe de filtro se han considerado dos alternativas principales: la media móvil simple y la media móvil ponderada. 73 Moving Average La media móvil simple(Moving Average) consiste en la media aritmética de los n datos anteriores. Haciendo uso de esta técnica se pueden dar dos casos. Si el valor de la n es grande, mayor será la influencia de los datos antiguos, sin embargo si por el contrario el valor de la n es baja, se tendrán en cuenta datos más recientes para la predicción. Por lo que de acuerdo a lo enunciado anteriormente se concluye que la elección de la n influenciaría decisivamente la predicción. Si el valor de la n es bajo, la predicción resultante tendrá una alta capacidad para responder a fluctuaciones o variaciones de un periodo a otro, ya que la predicción será altamente influenciada por efectos aleatorios. Si por el contrario la n es alta, la predicción resultante tendrá una baja capacidad para responder a fluctuaciones o variaciones de un periodo a otro, ya que se filtrará la existencia de efectos aleatorios, debido a que la predicción tendrá en cuenta el valor de datos antiguos. Weighted Moving Average La simplicidad que tiene la técnica de Moving Average, debido a la consideración equitativa de datos recientes y datos antiguos, sobre todo cuando el objeto de predicción son variables cuya variabilidad en el corto plazo es importante para obtener una predicción eficaz, hace que se tenga en cuenta otra alternativa, la media móvil ponderada. La media móvil ponderada es una media que, multiplicada por ciertos factores, asignan determinado peso a los datos. Esta media mejora las predicciones de la media móvil simple, ya que se trata de la media aritmética de los n valores anteriores ponderados. Esta ponderación se asigna según diferentes criterios como puede ser darle más importancia a los datos antiguos o a los datos más recientes. Esta técnica será más eficiente que la media móvil simple a la hora de adaptar rápidamente el valor de la predicción a fluctuaciones en los datos recientes. Sin embargo pueden seguir apareciendo valores extremos dentro de los datos más recientes y de esa manera estropear en menor medida el filtrado de señales. Conclusión Partiendo de que la aplicación trata el caso de un usuario andando por los pasillos de una superficie comercial y en cualquier giro puede cambiar de pasillo y por tanto de localización, el filtro debe de tener las siguientes características: La cantidad de muestras debe ser baja: Si se tuviera una cantidad de datos alta, el usuario debería esperar a que la aplicación consiguiera las n primeras entradas para empezar a trabajar y por lo tanto la aplicación s quedaría congelada. Además se tendrían en cuenta los datos antiguos, afectando a la predicción negativamente, ya que la media de todas las señales 74 obtiene como resultado las localizaciones por las que va pasando el usuario, en lugar de la posición actual del usuario y para que funcionara correctamente el usuario debería andar por secciones y permanecer quieto hasta que la aplicación calcule su posición y le siga guiando en lugar de ir guiando según va andando. obteniendo como conclusión que una cantidad de 10 muestras es idónea, ya que según las pruebas entre 6 y 7 de cada 10 señales son correctas y por lo tanto te permite pasarle el filtro correctamente. El primer paso será hacer una distinción En este caso la cantidad de muestras se ha optado por fijarla a 10, ya que observando las primeras pruebas se obtiene como conclusión que entre 6 y 7 de cada señales 10 son correctas y por lo tanto permite pasarle el filtro correctamente. Capacidad para tratar con valores extremos: Ambas técnicas tratan con valores extremos y lo incluyen a la media aritmética. En el caso de la media móvil simple se trata de una media aritmética de los n valores y por tanto la inclusión de valores extremos afecta negativamente, ya que influiría notablemente en la predicción. En el caso de la media móvil ponderada, se siguen tratando estos valores extremos e incluyendo en la media aritmética con la peculiaridad de que si el valor extremo aparece entre los datos recientes o más antiguos podrá tener mas o menos peso en la decisión final. El problema se radicaría eliminando esos valores extremos y para ello antes de realizar la media aritmética, se han procesado las señales almacenadas y de ha decidido crear un intervalo de confianza y realizar la media con los valores que se encuentren dentro de ese intervalo, de manera que los valores extremos queden descartados y no se tengan en cuenta dando lugar a una predicción mas efectiva. Un intervalo de confianza trata de un par de números entre los cuales se estima que estará cierto desconocido valor con una determinada probabilidad de acierto. Esta probabilidad de acierto en la estimación se representa con 1 - α y se denomina nivel de confianza, donde α es el llamado error aleatorio o nivel de significación, esto es, una medida de las posibilidades de fallar en la estimación mediante tal intervalo. El nivel de confianza y la amplitud varían de manera conjunta en función del nivel de confianza. A mayor nivel de confianza, se obtendrá un intervalo más amplio, y por lo tanto mayor probabilidad de acierto. Por el contrario un menor nivel de confianza, dará lugar a un intervalo más pequeño que ofrece una estimación más precisa. Para la construcción del intervalo de confianza es necesario conocer la distribución teórica que sigue el parámetro a estimar Φ. Por lo tanto la fórmula que se encargará de delimitar los intervalos de confianza será: Intervalo de Confianza I = (X̄ − E, X̄ + E) 75 (4.2) siendo: E = Este valor corresponde al error aleatorio cuya fórmula es la siguiente: σ E = Z α2 · √ n (4.3) X̄ = Este valor corresponde a la media muestral cuya fórmula es la siguiente: N 1 X · xi X̄ = N i=1 (4.4) donde: n = tamaño muestral que corresponde a las señales que contiene el array de entrada con una entrada fija de 10. σ =Este valor corresponde a la desviación tipica cuya fórmula es la siguiente: v u N u 1 X t σ= · (xi − x̄)2 N − 1 i=1 (4.5) Como se ha comentado anteriormente, el nivel de confianza expresa la certeza de que realmente el dato que buscamos esté dentro del margen de error. Realizando unas pruebas previas se concluye que de cada 10 señales se reciben entre 6 y 9 correctas, es decir, entre el 60 % y el 90 % de las pruebas son correctas y existe una tasa de error mínima del 10 % y máxima del 40 %, por lo que se ha decidido implantar un nivel de confianza del 90 %. Dicho de otra manera, si se repitiese 100 veces la misma prueba 90 veces la proporción buscada estaría dentro del intervalo y 10 fuera. Con este nivel de confianza se pretende crear un intervalo menor que ofrezca una estimación más precisa eliminando los valores extremos. Para un nivel de confianza del 90 % Nivel de confianza = 1 – α = 0,9 ; α = 0,1 Se sabe que Φ( zn ) = p( z <z αn ) = 1- α 2 =1- 0,1 2 = 0.95 Usando la tabla de la distribución Z → N(0,1), se obtiene: Z α2 = 1,64 Luego: σ E = 1,64 · √ n Una vez generado el intervalo de confianza, se procesará el array de entrada y se desechan los valores que no estén dentro de este intervalo, eliminando de esa manera los valores extremos. El siguiente paso será realizar la media, mediante la expresión 4.4, de las señales que se conservan en el array de entrada consiguiendo de esta manera una salida mejor estimada. Como conclusión a la solución, se presenta un diagrama de secuencia correspondiente a la Figura 4.14 76 Figura 4.14: Diagrama de Secuencia del Módulo de Filtrado de Señal 4.5.4 Módulo de Posicionamiento El módulo de Posicionamiento es el encargado de recibir la frecuencia estimada proveniente del módulo de Filtrado de Señal, correspondiente a cada uno de los dispositivos que se haya detectado en el módulo de comunicaciones. Su función será recibir los datos de entrada, asegurarse el acceso a recursos compartidos, procesarlos y estimar la posición correcta en base a las distintas frecuencias que recibe. Es necesario controlar esta comunicación y administrar los datos que se reciben de entrada, ya que hasta que no se reciban todas las entradas necesarias, correspondientes a los dispositivos detectados en el módulo de comunicaciones, no se puede calcular la posición estimada. Por lo tanto ha de asegurarse la recepción de frecuencias estimadas mediante algún sistema de almacenamiento. Para proporcionar la funcionalidad descrita se han diseñado los siguientes submódulos: Un primer submódulo encargado de recoger los datos, procedentes del módulo de filtrado de señal. Un segundo submódulo encargado de procesar los datos del primer submódulo y proporcionar la posición estimada, mediante el uso de un sistema de posicionamiento. Un tercer submódulo encargado de recoger las posiciones del segundo submódulo y almacenarlas para realizar un sistema de votaciones que concluya con una posición que servirá de entrada al módulo de enrutamiento. De esta manera, teniendo una entrada con un array de frecuencias estimadas por cada uno de los dispositivos identificados y procesándolos mediante el uso de un mapa de potencias, se concluye con la posición estimada como entrada del módulo de enrutamiento. Gráficamente, la descripción funcional del nivel de posicionamiento es la mostrada en la Figura 4.15. 77 Figura 4.15: Descripción Funcional del módulo de Posicionamiento En cuanto a la dependencia con otros módulos, este módulo se relaciona por debajo con el módulo de Filtrado de señal del que obtiene las distintas frecuencias estimadas y, al producir la salida con el módulo de enrutamiento al que manda la posición estimada. Solución A la entrada del módulo llegan todas las salidas procedentes del módulo de filtrado de señal y se almacenan en un buffer, para a continuación calcular la posición en base a estas entradas. Sin embargo este módulo planteó un problema a la hora de recoger los datos y calcular la posición estimada debido a la entrada asíncrona de frecuencias estimadas proveniente del módulo de Filtrado de señal, ya que al hacer uso de un enfoque multi-hilo los datos llegan de manera aleatoria, según se procesan los datos y producen la salida, que es la entrada del módulo de Posicionamiento. Por lo tanto hay que calcular la posición, única y exclusivamente cuando se tenga la frecuencia estimada de cada uno de los dispositivos detectados en el módulo de comunicaciones. Para ello se emplea el uso de una variable semáforo que impide realizar el cálculo de dicha posición hasta que no contenga la señal estimada que produce la salida del módulo de filtrado de señal de los distintos dispositivos que se hayan detectado en el módulo de Comunicaciones, como muestra el siguiente pseudocódigo. Funcion semaforo(parametros, ...) Si semaforo = 1 Si hay n frecuencias estimadas semaforo = 0 Calcular() Sino wait() Listado 4.12: Pseudocodigo Función Semáforo 78 Como ya se indicó en la Sección 4.4, se va a utilizar un sistema de posicionamiento como solución al problema del multipath usando la fuerza de la señal recibida o RSS para localizar la posición del usuario o nodo móvil. El sistema más usado en sistemas de posicionamiento, se trata del mapa de potencias como se ve en [DC11]. Este sistema de posicionamiento tendrá que almacenar los datos necesarios para realizar la posterior estimación de la localización del nodo móvil, recogiendo los datos en una fase inicial de calibración, en la que se almacenan los pares de coordenadas asociando a cada uno de ellos la lista de potencias de recibidas de los nodos de referencia, entendiendo nodo de referencia como las distintas secciones establecidas dentro del recinto comercial, que permitirá establecer la posición del nodo móvil o usuario. El mapa de potencias tendría, por tanto, una estructura como la mostrada en la Tabla 4.1, donde cada RSS representa la potencia de señal recibida en esa coordenada desde el nodo de referencia por el major del nodo referenciado i(nri ) en las coordenadas (xn , yn ), y estará almacenado en decibelios. de la pagina 80 79 80 . . . rss . . . (xn , yn ) rss . . . rss . . . rss rss rss . . . rss rss nr2 rss . . . rss . . . rss rss rss . . . rss rss nr3 rss . . . rss . . . rss rss rss . . . rss rss nr4 rss . . . rss . . . rss rss rss . . . rss rss nr5 Tabla 4.1: Estructura del Mapa de Potencias rss rss rss rss (x0 , yn ) (x1 , y0 ) (x1 , y1 ) (x1 , yn ) . . . . . . . . . rss rss (x0 , y0 ) (x0 , y1 ) . . . nr1 Coordenadas/Nodos Referencia rss . . . rss . . . rss rss rss . . . rss rss nr6 rss . . . rss . . . rss rss rss . . . rss rss nr7 ... . . . ... . . . ... ... ... . . . ... ... ... rss . . rss . . rss rss rss . . rss rss nri Como ya se comentó en el módulo de Filtrado de Señal, el posicionamiento del iBeacon utiliza un sistema de referencia relativo y centrado en el receptor estableciendo la situación en tres rangos, debido a la fluctuación de la señal. De la misma manera que el iBeacon utiliza un sistema de referencia relativo, el mapa de potencias no va a establecer un valor concreto para el RSS, sino un intervalo, debido a la fluctuación de señal. El tercer submódulo se trata de otro filtro más que asegura que la posición calculada es la correcta, ya que, aunque las señales pasan por un filtro que elimina valores extremos, se puede dar el caso de que en un momento recoja muchos valores extremos y por tanto no los elimine el filtro sino que los interprete como la posición correcta. Es por ello que se implemento un sistema de votaciones que consiste en guardar las ultimas n posiciones estimadas calculadas y posteriormente hacer un recuento de la posición que más aparece de manera que si en algún momento se introdujera una posición no deseada no se tuviera en cuenta. Como conclusión a la solución, se presenta un diagrama de secuencia correspondiente a la Figura 4.16. Figura 4.16: Diagrama de Secuencia del Módulo de Posicionamiento 4.5.5 Módulo de Enrutamiento y Guiado El módulo de enrutamiento es el encargado de recibir la información en formato de coordenadas del movimiento del usuario, proveniente del módulo de posicionamiento. Su función será encargarse de generar la ruta que debe guiar al usuario hasta cada uno de los productos añadidos a la lista con el menor coste. Para proporcionar la funcionalidad descrita se han diseñado los siguientes submódulos: Un primer submódulo encargado de la gestión y control del flujo del módulo. Un segundo submódulo encargado de generar la ruta que le guíe hasta cada uno de los productos añadidos a la lista tomando como punto de origen la posición que ocupe el usuario. 81 Un tercer submódulo encargado de realizar la animación que muestre al usuario la posición que ocupa en el plano. Un cuarto submódulo encargado guiar al usuario mediante voz. Gráficamente, la descripción funcional del nivel de posicionamiento es la mostrada en la Figura 4.17. Figura 4.17: Descripción Funcional del módulo de Enrutamiento En cuanto a la dependencia con otros módulos, este módulo se relaciona por debajo con el módulo de Posicionamiento del que obtiene la coordenada del movimiento del usuario y al producir la salida con el módulo de guiado al que envía la siguiente posición a visitar. Solución Se trata del módulo mas importante y robusto de la aplicación. Este módulo presenta una gran complejidad y diversos problemas en su diseño por lo que no es sencilla su implementación. Funcionalmente el módulo se encargará de tres funciones: Generar la ruta que debe guiar al usuario hasta cada uno de los productos añadidos a la lista con el menor coste. Generar la animación en la pantalla posicionado al usuario en la nueva posición para que se encuentre más orientado. Reproducir la dirección de la siguiente posición de la ruta generada. El listado 4.6 muestra el pseudocódigo del módulo de enrutamiento: Enrutamiento(parametros) Calcular ruta partiendo de la posicion actual del usuario. 82 Mientras no finaliza la compra //productos es distinto a 0 Si cambia posicion del usuario //Si posicion del camino y posicion del usuario iguales Si posicion actual es igual a posicion que deberia ser Comprobacion y Actualizacion de datos Sino Calcular ruta partiendo de la posicion actual del usuario. Animacion a la casilla correspondiente a la posicion del usuario Indicacion guiada Fin Si Fin Mientras Fin Enrutamiento Listado 4.13: Pseudocódigo Módulo Enrutamiento La primera vez que se instancia el módulo de enrutamiento se genera una ruta que pasa por todos los productos seleccionados con menor coste. Esta ruta siempre se generará partiendo de la posición del usuario, de manera que pueda abrir la aplicación en cualquier punto del establecimiento comercial, y contendrá las coordenadas por las que debe pasar. Una vez se comience a comprar, el algoritmo no se detiene hasta que el usuario haya cogido todos los productos seleccionados en la lista que marcó previamente. Cada vez que el algoritmo detecta un cambio de posición, mediante una comprobación de la posición actual, emitida por el módulo de posicionamiento, con una variable encargada de guardar siempre la ultima posición, se genera una comprobación que consiste en verificar si la nueva posición del usuario es la correcta en la ruta previamente generada o si el usuario se ha equivocado. De manera que se comprueba la posición que debería tener y la posición actual, emitida por el módulo de posicionamiento. Se pueden dar dos casos: El primer caso sería que las posiciones fueran iguales. En ese caso el usuario ha seguido la ruta establecida y por lo tanto se realiza: 1. Una comprobación de la nueva posición y por tanto de la nueva sección que ocupa el usuario con las secciones del supermercado en las que aparece algun producto elegido por el usuario, para saber si esa nueva sección contiene algún producto que quiere el usuario. 2. Una actualización de los datos que se muestran en pantalla y los datos internos como borrar la nueva posición de la ruta, guardar la nueva posición para la siguiente comprobación y en el caso de que se haya escogido un nuevo producto borrarlo de la lista de productos restantes, ya que en caso de que el usuario se equivoque de camino y se realice una nueva ruta sólo tenga en cuenta los productos que aun no ha cogido. El segundo caso sería que la posiciones fueran distintas. En ese caso el usuario ha tomado un camino diferente al que marca la ruta y por lo tanto es necesario realizar otra nueva ruta 83 partiendo de la nueva posición, teniendo en cuenta en todo momento cuáles son los productos que aún no ha añadido el usuario a la cesta y obviando los productos ya visitados. A continuación, una vez actualizado el array que pertenece a la ruta, se realiza una animación que muestre al usuario la nueva posición que ocupa en el plano y posteriormente se calcula la siguiente dirección que debe seguir el usuario. Para ello se manda la siguiente posición a visitar en la ruta al submódulo de Guiado y éste se encarga de consultar la sección a la que pertenecen dichas coordenadas y devolver la dirección con el fin de reproducirla. Aunque a simple vista parece simple, este módulo planteó varios problemas de diseño: En primer lugar la generación de la ruta más corta que guíe al usuario hasta cada uno de los productos añadidos a la lista con el menor coste, ya que se pueden se pueden usar dos enfoques distintos a la hora de implementar el algoritmo atendiendo al tiempo de cómputo o al costo en memoria. En segundo lugar la manera de guiar al usuario, enfocando las indicaciones a orientativas y visuales. A continuación se analizan cada uno de los submódulos que conforman el módulo global de Enrutamiento y Guiado Generar Ruta El modelo de la ruta más corta detalla una red en la cual cada arco (i, j) tiene asociado un numero c(sub ij), el cual se interpreta como la distancia (tal vez costo o tiempo) desde el nodo i hasta el nodo j. Una ruta o camino entre dos nodos es cualquier secuencia de arcos que los conecte. El objetivo es encontrar la ruta más corta (de menor costo o más rápida) desde un nodo específico hasta cada uno de los demás nodos de la red. Este es uno de los problemas más comunes al utilizar grafos, encontrar el camino entre dos puntos de tal forma que el peso total de las aristas visitadas sea mínimo. Un grafo(Figura 4.18) es un método para representar objetos y la relación que mantienen entre sí. La rama de las matemáticas que se encarga de su estudio se le conoce como Teoría de Grafos. Un ejemplo clásico es cuando el grafo representa una ciudad donde las aristas son las calles (pueden ser dirigidas o no), los vértices las intersecciones, y el peso de las aristas el tiempo que se tarda en recorrer la calle; Puede interesar encontrar la forma para llegar de un punto a otro de tal forma que el tiempo sea mínimo. Un grafo está compuesto por vértices (también llamados nodos) y aristas como muestra la Figura 4.18 . Los vértices son los objetos que se desean representar, mientras que las aristas son la forma en que están interconectados. De manera general se representa un vértice como un punto o un círculo y a una arista como una línea, aunque se puede elegir cualquier representación ya que las propiedades del grafo no cambian. 84 Figura 4.18: Estructura de un Grafo Para su uso dentro de un programa es necesario representar el grafo a través de sus vértices o a través de sus aristas. Generalmente los vértices van numerados, por lo que lo que interesa es la forma de guardar los vértices. La primera forma, como muestra la Tabla 4.2, es guardar en una lista las aristas junto con sus vértices asociados. En cada casilla del array se tienen dos valores, que son los vértices que conecta la arista. Se pueden incluir datos adicionales, como el peso. Para la gráfica ejemplificada arriba se tendría (considerando que el vértice a se toma como el primero, b el segundo y así sucesivamente): Vi Vj E1 1 2 E2 2 3 E3 1 3 E4 2 4 E5 7 6 E6 4 5 Tabla 4.2: Representación del grafo a través de sus aristas Otra forma para representar el grafo, como muestra la Tabla 4.3, es mediante una matriz de adyacencia. Cada fila y columna representan un vértice, y la matriz representa la forma en que están conectados (comúnmente pesos o número de conexiones). Para el ejemplo anterior, se tendría: Partiendo de la teoría de grafos y adaptándolo a el presente Trabajo Fin de Grado, el grafo representa un supermercado compuesto por nodos que corresponden a los productos y aristas que equivalen a los pasillos y son la forma en que están interconectados los distintos productos del supermercado. 85 V1 V2 V3 V4 V5 V6 V7 V1 0 1 1 0 0 0 0 V2 1 0 1 1 0 0 0 V3 1 1 0 0 0 0 0 V4 0 1 0 0 1 0 0 V5 0 0 0 1 0 0 0 V6 0 0 0 0 0 0 1 V7 0 0 0 0 0 1 0 Tabla 4.3: Representación del grafo a través de sus vertices Para encontrar el camino más corto se aplica el principio de que para que un camino sea óptimo, todos los caminos que contiene también deben ser óptimos y el camino más corto no debe contener ciclos (es un árbol). Dos técnicas de programación que aprovechan esta propiedad son programación dinámica y los algoritmos ávidos (o voraces). Ambas alternativas harán uso de una tabla de distancias que les permite saber la distancia mínima (tal vez costo o tiempo) desde el nodo i hasta el nodo j. Es por ello que hay dos partes bien diferenciadas en el cálculo de la ruta más corta: Tabla de distancias que muestre el coste óptimo de un nodo origen a cualquier otro nodo del grafo. Cálculo del camino óptimo haciendo uso de cualquier técnica de programación. Tabla de distancias Para la realización de la tabla de distancias se ha optado por seguir el modelo de la matriz de adyacencia, ya que cada fila y columna representan un vértice, sin embargo a diferencia de la la matriz de adyacencia que representa la forma en la que están conectados los vértices y las aristas de un grafo, la tabla de distancias representa el coste mínimo de un nodo origen(fila) a un nodo destino(columna). Los vértices que componen la tabla de distancias corresponden a los productos que el usuario ha seleccionado y añadido a la lista. Al ser productos repartidos por todo el establecimiento y seleccionados por el usuario, se puede dar el caso de que un producto no esté contiguo a otro, es decir, no haya ninguna conexión entre ellos y por tanto no se tenga un coste directo. La manera para solucionar este problema ha sido aplicar el algoritmo de Dijkstra. El algoritmo de Dijkstra, también llamado algoritmo de caminos mínimos, es un algoritmo para la determinación del camino más corto dado un vértice origen al resto de los vértices en un grafo con pesos en cada arista. La idea subyacente en este algoritmo consiste en ir explorando todos los caminos más cortos que parten del vértice origen y que llevan a todos los demás vértices. Cuando se 86 obtiene el camino más corto desde el vértice origen, al resto de vértices que componen el grafo, el algoritmo se detiene. El algoritmo es una especialización de la búsqueda de costo uniforme, y como tal, no funciona en grafos con aristas de coste negativo, aunque en este caso y para el presente Trabajo Fin de Grado se han considerado todos los pasillos con el mismo coste. Las características del algoritmo de Dijkstra son: Para grafos dirigidos (la extensión a no dirigidos es inmediata). Genera uno a uno los caminos de un nodo v al resto por orden creciente de longitud. Usa un conjunto de vértices donde, a cada paso, se guardan los nodos para los que ya se conoce el camino mínimo. Devuelve un vector indexado por vértices: en cada posición w se guarda el coste del camino mínimo que conecta v con w. Cada vez que se incorpora un nodo a la solución se comprueba si los caminos todavía no definitivos se pueden acortar pasando por él. Mediante este algoritmo se pretende determinar el camino más corto dado un vértice origen al resto de los vértices en un grafo con pesos en cada arista y de esa manera completar la tabla de distancias. El algoritmo de Dijkstra utiliza las propiedades descritas anteriormente y funciona de la siguiente forma: Primero se marcan todos los vértices como no utilizados. Entre todos los vértices, se busca el que esté más cerca del punto origen, se toma como punto intermedio y se comprueba si se puede llegar más rápido a través de este vértice a los demás. Después se escoge al siguiente más cercano (con las distancias ya actualizadas) y se repite el proceso. Este proceso se lleva a cabos hasta que el vértice no utilizado más cercano coincida con el destino. Al proceso de actualizar las distancias tomando como punto intermedio al nuevo vértice se le conoce como relajación (relaxation). Algo que se puede observar es que al obtener el camino más corto de un punto a otro, también se está obteniendo el camino más corto del primero a todos los vértices intermedios que se tienen que visitar. Por esto, se puede encontrar el camino más corto entre un punto y todos los demás de forma casi igual a como se obtiene la distancia más corta de un punto a otro. Tal y como se muestra en el Listado 4.7 para realizar la tabla de distancias, se comienza creando un array bidimensional de tamaño [Nodos][Nodos] y se añade un -1 a todas las 87 posiciones salvo a aquellas en las que el nodo origen y nodo destino es el mismo, al que se le ha asignado un valor 0, ya que se supone que el camino mínimo de un nodo a sí mismo tiene coste nulo. //Creacion del array de costes/distancias - (void)matrizCostes0:(NSArray *)nodos{ NSMutableArray *coste = [[NSMutableArray alloc] init]; for(int i =0; i < [nodos count]; i++){ NSMutableArray *cols = [[NSMutableArray alloc] init]; for(int j = 0; j< [nodos count]; j++){ if (i == j) { [cols insertObject:@0 atIndex:[cols count]]; } else{ [cols insertObject:@-1 atIndex:[cols count]]; } } [coste insertObject:cols atIndex:[coste count]]; } //Esta es la matriz visual que hemos construido con el codigo anterior /*_coste = @[ @[@0,@-1,@-1,@-1,@-1,@-1,@-1], @[@-1,@0,@-1,@-1,@-1,@-1,@-1], @[@-1,@-1,@0,@-1,@-1,@-1,@-1], @[@-1,@-1,@-1,@0,@-1,@-1,@-1], @[@-1,@-1,@-1,@-1,@0,@-1,@-1], @[@-1,@-1,@-1,@-1,@-1,@0,@-1], @[@-1,@-1,@-1,@-1,@-1,@-1,@0] ];*/ [self.myDelegate updateMatrizCostes0:coste]; } Listado 4.14: Inicialización Tabla de Distancias Lo correcto sería inicializar todas las distancias con un valor infinito relativo, ya que son desconocidas al principio, exceptuando la diagonal principal en la que se debe colocar un 0 debido a que la distancia de un nodo a sí mismo sería 0. Sin embargo, al tratarse de un grafo conexo y no dirigido que representa un supermercado en el que es posible ir a cualquier producto, se ha omitido el valor infinito relativo a la hora de realizar la implementación. Al encontrarse dentro de la capa de modelo se avisa al delegado de la vista para que actualice matriz de costes y pueda hacer uso de ella. Una vez construida e inicialiazada la tabla de distancias, se comienza a rellenar la matriz haciendo uso del algoritmo de Dijkstra como muestra el pseudocódigo del Listado 4.8. 88 Se recorre el array nodos que contiene la posición de cada nodo dentro del plano y se realiza una llamada al algoritmo de Dijkstra para calcular el coste de cada par de nodos por encima de la diagonal principal. Una vez calculados los valores por encima de la diagonal principal y al ser un grafo no dirigido y por lo tanto tener el mismo coste en ir del nodo i a j que ir de j a i, es decir, una matriz simétrica, se copian los valores ya calculados a las posiciones por debajo de la diagonal principal y de esa manera se evitan múltiples llamadas al algoritmo de Dijkstra. //Rellenar la matriz de costes/distancias NSArray *aux = [NSArray array]; //Rellenar la matriz de costes con dijkstra Desde i = 0 hasta numero de filas de tabla de distancias Desde j= 0 hasta numero de columnas de tabla de distancias Si i < j Entonces coste = Dijkstra del nodo i al nodo j tabla de distancias[i][j] = coste Fin Si Fin Desde Fin Desde Desde i = 0 hasta numero de filas de tabla de distancias Desde j = 0 hasta numero de filas de tabla de distancias Si i > j Entonces tabla de distancias[i][j] = tabla de distancias[j][i] Fin Si Fin Desde Fin Desde Listado 4.15: Rellenar Tabla de Distancias. Cálculo del camino óptimo Como ya se ha comentado anteriormente, para encontrar el camino más corto se aplicará el principio de optimalidad, según el cual para que un camino sea óptimo, todos los caminos que contiene también deben ser óptimos y el camino más corto no debe contener ciclos. Se han nombrado dos alternativas (algoritmos voraces y programación dinámica) para realizar el camino óptimo por lo que se va a proceder a analizar cada una de ellas para posteriormente tomar una decisión. 89 Fuerza Bruta La primera técnica se trata de una heurística voraz para resolver el clásico problema del viajante, en la que se trata de encontrar el itinerario más corto que permita a un viajante recorrer un conjunto de ciudades pasando una única vez por cada una y regresando a la ciudad de partida. En este caso el viajante será un usuario que quiera recorrer el supermercado escogiendo los productos que desea. Este algoritmo tiene un ritmo de crecimiento exponencial por lo que no es práctico a la hora de resolver ejemplares “grandes“, por lo tanto se utiliza para problemas pequeños. El problema se suele representar mediante: Un grafo completo no dirigido con un nodo por cada ciudad. Utilizando una matriz de distancias (lo normal es que se trate de una matriz simétrica). Ambas características las posee el problema ya que cada vértice corresponde a un producto seleccionado por el usuario y se va a utilizar una matriz de distancias previamente calculada mediante el algoritmo de Dijkstra, sin embargo se ha optado por usar un grafo dirigido, ya que la extensión a grafo no dirigido es inmediata y por tanto se engloban tanto los grafos dirigidos como no dirigidos. Esta heurística consiste en: Ir desplazándose desde cada producto seleccionado al producto mas próximo no seleccionado. Retornar al producto desde el que se comenzó el recorrido. Con estas dos premisas se intentan todas las posibilidades, es decir, se calculan las longitudes de todos los recorridos posibles y se selecciona la de longitud mínima. Debido a la comprobación de más operaciones de las necesarias para resolver el problema, suele tener un coste alto, creciendo exponencialmente con el número de puntos a visitar. Sin embargo es bastante sencillo de implementar. A continuación, mediante el ejemplo gráfico de la Figura 4.19 se detalla el problema de la ruta de menor coste aplicando la técnica de Fuerza Bruta, en la que un usuario tiene que recorrer los n productos seleccionados y regresar a la posición de salida, en este caso la caja, de tal forma que el peso total de las aristas visitadas, en este caso pasillos sea mínimo. Aunque en el caso del presente Trabajo Fin de Grado se trata de un grafo no dirigido y un coste uniforme de uno para cada arista, se ha implementado con el objetivo de que se pueda utilizar en un grafo dirigido con un coste desigual para cada arista. Como ya se ha comentado anteriormente y basándose en la teoría de grafos, lo primero que se hace es representar cada producto mediante un nodo de un grafo y cada camino como una arista, en este caso dirigida, por lo que finalmente se obtiene un grafo dirigido G = (V, A) donde: V = 1,...,n es el conjunto de vértices (productos). 90 Figura 4.19: Descripción Gráfica del problema A es el conjunto de aristas (i, j) con (i, j) ∈ V (caminos). D(i,j) es la longitud de (i, j) si (i, j) ∈ A o ∞ si (i, j) ∈ / A. De\A 0 1 2 3 0 ∞ 5 2 2 1 3 ∞ 6 5 2 ∞ 4 ∞ 4 3 3 ∞ 6 ∞ Tabla 4.4: Matriz de Adyacencia para el ejemplo del cálculo del camino minimo Suponiendo que la posición de partida es la 0, si se denomina C(i,W) a la longitud del camino mínimo de i a 0 que pasa por todos los vértices de W ⊂ V, siendo 0 ∈ / W, entonces ( C(i, W ) = D(i, 0) si W = ∅ min(D(i, j) + C(j, W − j)) para j ∈ W si W 6= ∅ (4.6) Como inicialmente la posición de partida es la 0, la solución al problema será C(0,V- {0}) y por tanto se cumple el principio de optimalidad. El Listado 4.16 implementa la Técnica de Fuerza Bruta 91 - (void)fuerzaBruta_nodos2:(int)n origen:(int)i conjunto:(NSMutableArray *)conjunto coste:(NSArray *)costes camino:(NSMutableArray*)camino { NSMutableArray *nconjunto = [[NSMutableArray alloc] init]; nconjunto = [NSMutableArray arrayWithArray:conjunto]; [nconjunto removeObject:[NSNumber numberWithInt:i]]; if(nconjunto.count == 0){ if([self Coste:camino coste:costes] <= [self Coste:_camino coste:costes]){ _camino = [NSMutableArray arrayWithArray:camino]; _valorRecorrido = _valoraux; } } else{ for(int j=0; j<n; j++){ if([nconjunto containsObject:[NSNumber numberWithInt:j]]){ [camino insertObject:[NSNumber numberWithInt:j] atIndex:[camino count]]; [self fuerzaBruta_nodos2:n origen:j conjunto:nconjunto coste:costes camino:camino]; [camino removeObject:[NSNumber numberWithInt:j]]; } } } } Listado 4.16: Implementación Técnica Fuerza Bruta Como ya se ha comentado anteriormente, mediante el empleo de la técnica de Fuerza Bruta, el usuario se desplaza desde el punto de origen al producto más proximo no seleccionado, hasta llegar al punto de origen en el que guardará el recorrido con un coste menor y retornará al producto anterior hasta el comienzo del recorrido. Esta técnica recorre todos los caminos posibles y se queda con el camino de menor coste como se muestra en la Figura 4.20 El coste es de O(n!) Programación Dinámica La función anterior repite llamadas para calcular C(i,W), y por tanto es ineficiente, sin embargo utilizando la técnica de programación dinámica se pueden guardar los valores de C(i,W) en una tabla para evitar repetir su cálculo. Programación dinámica (DP – Dynamic Programming) es una técnica de programación que se puede utilizar en problemas que presentan las siguientes condiciones: La solución al problema ha de ser alcanzada a través de una secuencia de decisiones, 92 Figura 4.20: Recorrido Técnica Fuerza Bruta una en cada etapa. Dicha secuencia de decisiones ha de cumplir el principio de optimalidad, es decir, el problema puede ser resuelto de manera óptima si sus partes son resueltas de manera óptima. El principio de optimalidad enunciado por Bellman en 1957, es la base a la solución de problemas mediante la técnica de programación dinámica y dice: “En una secuencia de decisiones óptima toda subsecuencia ha de ser también óptima”. La idea básica de la programación dinámica es guardar los resultados de los subproblemas para no tener que volverlos a calcular después. Con esta simple técnica, se transforman algoritmos que se ejecutan en tiempo exponencial a tiempo polinomial. Este ahorro en tiempo se refleja en la reducción del costo en memoria. Los problemas más comunes que se resuelven mediante esta técnica son los de optimización, donde se pueden encontrar muchas soluciones pero se requiere únicamente la mejor (posiblemente la menor o la mayor, según lo que se esté buscando). Como pueden existir varias combinaciones que resulten en la mejor solución, se dice que se encuentra una respuesta óptima, y no la respuesta óptima. A grandes rasgos, el diseño de un algoritmo de Programación Dinámica consta de los siguientes pasos: 1. Planteamiento de la solución como una sucesión de decisiones y verificación de que ésta cumple el principio de optimalidad. 2. Definición recursiva de la solución. 93 3. Cálculo del valor de la solución óptima siguiendo un enfoque Top-down donde el problema se divide en subproblemas, y éstos se resuelven haciendo uso de las soluciones almacenadas en una tabla por si fuera necesario reutilizar los cálculos. 4. Construcción de la solución óptima haciendo uso de la información contenida en la tabla anterior. Por lo tanto los elementos que identifican a los algoritmos de programación dinámica son: Subestructura óptima: Esto implica que para poder resolver el problema de forma óptima, cualquier subparte del problema también necesita ser resuelto de forma óptima. Si está condición se cumple, también existe la posibilidad de que un algoritmo ávido sea útil. Empalme de subproblemas: La ventaja principal de la programación dinámica es que al tener los resultados de los subproblemas en una tabla, se pueden buscar en tiempo constante. Para poder aprovechar esto, se requiere que al resolver los subproblemas sea preciso emplear resultados anteriores, y que la cantidad de subproblemas no sea excesivamente grande (para poder crear las tablas). Memorización: Esto se utiliza para pasar de un algoritmo recursivo a uno de programación dinámica. Lo que se hace es utilizar el mismo algoritmo, y agregar el uso de la tabla. Cuando se requiere un valor, primero se busca en la tabla, y en caso de que no se encuentre, se busca recursivamente (este sería el enfoque top-down). Para indexar la tabla en la segunda dimensión, se asigna un código único a cada subconjunto W para identificarlo. Puesto que el numero de productos seleccionados por el usuario es n, el numero de posibles subconjuntos es 2n . Si se representa cada subconjunto mediante un vector ( W = [x0 , ..., xn−1 ] con xi = 0 si i ∈ /w 1 si i ∈ w (4.7) entonces, id(W) = x0 20 + x1 21 + ... + xn−1 2n−1 asigna un código único a cada subconjunto. Una vez explicadas las bases de la programación dinámica se muestra el algoritmo implementado que calcula la distancia mínima usando programación dinámica. - (int)dinamica:(int)n origen:(int)i conjunto:(NSMutableArray *)conjunto coste:(NSArray *)costes tabla:(NSMutableArray*)tabla { NSMutableArray *nconjunto = [[NSMutableArray alloc] init]; nconjunto = [NSMutableArray arrayWithArray:conjunto]; [nconjunto removeObjectIdenticalTo:[NSNumber numberWithInt:i]]; 94 if([nconjunto count] == 0) { return [costes[i][0] integerValue]; } if([tabla[i][[self conjuntoId:nconjunto n:n]] integerValue] > 0){ return [tabla[i][[self conjuntoId:nconjunto n:n]] integerValue]; } int dist, dmin = 1000; for(int j = 0; j<n; j++){ if([nconjunto containsObject:[NSNumber numberWithInt:j]]){ dist = [costes[i][j] integerValue] + [self dinamica:n origen:j conjunto:nconjunto coste: costes tabla:tabla]; if( dist < dmin){ dmin = dist; } } } [tabla[i] replaceObjectAtIndex:[self conjuntoId:nconjunto n:n] withObject:[NSNumber numberWithInt:dmin]]; return dmin; } Listado 4.17: Implementación Técnica Fuerza Bruta Para el ejemplo ya expuesto cuya tabla de adyancencia D(i,j) es De\A 0 1 2 3 0 ∞ 3 ∞ 3 1 5 ∞ 4 ∞ 2 2 6 ∞ 6 3 2 5 4 ∞ se ha calculado la tabla de distancias mínimas C(i,W) De\A 0 0 0 0 0 -1 -1 -1 -1 1 -1 -1 -1 -1 2 -1 -1 11 10 3 -1 -1 -1 -1 4 -1 6 -1 6 5 -1 -1 -1 -1 6 -1 -1 -1 11 7 -1 -1 -1 -1 8 -1 ∞ 8 -1 9 -1 -1 -1 -1 10 -1 -1 16 -1 11 -1 -1 -1 -1 12 -1 12 -1 -1 13 -1 -1 -1 -1 14 14 -1 -1 -1 15 -1 -1 -1 -1 Tabla 4.5: Matriz de Adyacencia para el ejemplo del cálculo del camino minimo El coste del algoritmo para completar la tabla C(i, W) supone: Cáculo de C(i, ∅) para i = 1,...,n-1: n-1 consultas a tabla. 95 Cálculo de C(i, W) para 1≤ k = Cardinal(W ) ≤ n-2: n−2 (n − 1) ksumas; 1 (4.8) Cálculo C(0,V): n - 1 sumas. n=2 X n−2 O(2(n − 1) + (n − 1)k ) = O(n2 22 ) k k=1 (4.9) que, anque es exponencial, es de ornde menor que O n! Suponiendo que la posición de partida es la 0, si llamamos C(i,W) a la longitud del camino mínimo de i a 0 que pasa por todos los vértices de W ⊂ V, siendo 0 ∈ / W, entonces ( C(i, W ) = D(i, 0) si W = ∅ min(D(i, j) + C(j, W − j)) para j ∈ W si W 6= ∅ (4.10) A continuación en el listado 4.18 se calcula el itinerario que debe seguir el usuario a partir de la tabla C(i,W) - (void)rutaDinamica:(int)n conjunto:(NSMutableArray *)conjunto coste:(NSArray *)costes tabla:( NSMutableArray*)tabla camino:(NSMutableArray*)camino{ int dist, dmin, jmin = 0; for(int i= 0; i< costes.count; i++){ [camino addObject:@0]; } for(int i = 1; i < n; i++){ dmin = 1000; for(int j = 0; j<n; j++){ if([conjunto containsObject:[NSNumber numberWithInt:j]]){ [conjunto removeObjectIdenticalTo:[NSNumber numberWithInt:j]]; NSNumber *aux = [camino objectAtIndex:(i-1)]; int valorCoste = [costes [[aux integerValue]][j] integerValue]; int valorTabla = [tabla[j][[self conjuntoId:conjunto n:n]] integerValue]; dist = valorCoste + valorTabla; [conjunto addObject:[NSNumber numberWithInt:j]]; if(dist < dmin){ dmin = dist; jmin = j; } } } [camino replaceObjectAtIndex:i withObject:[NSNumber numberWithInt:jmin]]; 96 [conjunto removeObjectIdenticalTo:[NSNumber numberWithInt:jmin]]; } return; } Listado 4.18: Implementación Técnica Fuerza Bruta Para este ejemplo la función anterior devuelve el itinerario que aparece en la Figura 4.21 que efectivamente es el camino de mínima longitud Figura 4.21: Recorrido Técnica Programación Dinámica Generar Animación La tarea de este submódulo consiste en generar la animación del movimiento del usuario en la pantalla. Para desplazar al usuario por el centro comercial se ha creado internamente un mapa del centro compuesto por botones, ya que cada uno de ellos consta de una propiedad llamada tag que actua de identificador unívoco, de manera que cada movimiento del usuario esté representado por un tag que haga más fácil desplazarse a ese punto. Esta función recibe un array con el movimiento del usuario, por lo que tiene un único valor que refleja la posición actual del usuario y por lo tanto el tag al que debe desplazarse. El siguiente paso será sustituir el centro de la esfera que identifica al usuario en el mapa por el nuevo centro del botón. Finalmente se realiza la animación de 3 segundos que consiste en llevar la esfera desde la posición anterior a la nueva posición. 97 Este método recibe un array de posiciones, sin embargo sólo tiene una posición. Esto se podría evitar mandando como parámetro un valor entero perteneciente a la posición actual del usuario, sin embargo a la hora de desplazarse a una posición que no es contigua es necesario pasar por varias posiciones. Esto es lo que se realiza al inicio de realizar la compra, una animación con la ruta completa que debe seguir el usuario. Con esta implementación se pueden realizar todo tipo de animaciones, tanto contigua como recorrer varias posiciones El Listado 4.12 muestra la implementación de la función encargada de generar animaciones. //Realiza la animacion con la matriz que se le pasa - (void)animate:(NSArray*)path withCompletion:(void(^)())completion { NSMutableArray *animatePoints = [NSMutableArray array]; for (UIButton *field in path) { void (^p)(void) = ^{ _beaconView.center = field.center; }; [animatePoints addObject:p]; } float duration = 3.0; long numberOfKeyframes = path.count; [UIView animateKeyframesWithDuration:duration*numberOfKeyframes delay:0.0 options: UIViewKeyframeAnimationOptionCalculationModePaced animations:^{ for (long i=0; i<numberOfKeyframes; i++) { [UIView addKeyframeWithRelativeStartTime:duration*i relativeDuration:duration animations :animatePoints[i]]; } } completion:^(BOOL finished) { completion(); }]; } Listado 4.19: Implementación Técnica Fuerza Bruta Guiado La tarea de este submódulo consiste en realizar las funciones de un audioguía generando las indicaciones necesarias mediante comandos de voz para guiar al usuario hasta el siguiente punto de la ruta. Para la implementación de este submódulo fue necesario recopilar información sobre el entorno en el que se va a realizar la audioguía. Esta información se refiere a las distintas 98 secciones que contiene el supermercado y la posición que ocupan. Este submódulo se puede implementar siguiendo dos alternativas: La primera alternativa se basa en guiar al usuario mediante orientaciones. La segunda alternativa se basa en guiar al usuario mediante visualizaciones. Ambas alternativas son buenas a la hora guiar al usuario; la primera alternativa consiste en guiar al usuario mediante indicaciones basadas en la orientación del dispositivo, dando instrucciones como girar a la derecha, girar a la izquierda, seguir recto o dar la vuelta, mientras que la segunda alternativa consiste en guiar al usuario mediante indicaciones visuales, como seguir por la sección de frutería. A favor de la primera alternativa está la aceptación por parte del público, ya que muchas aplicaciones encargadas de guiar al usuario como puede ser el gps, le dan instrucciones basadas en la orientación, sin embargo en contra de está y como suele ocurrir en entornos de interior, están los fallos de orientación que provocan que el usuario tome la dirección equivocada. La segunda alternativa nace casualmente a la hora de hacer la compra con un familiar de avanzada edad. Este familiar prefería que le dieran una indicación visual y le guiaran hasta el producto que deseaba nombrando las seciones por las que debía pasar, ya que era más fácil de recordar que si le guiaban mediante orientaciones. Esta primera alternativa fue problemática en cuanto a la implementación, ya que para realizar indicaciones basandose en la orientación del usuario es necesario controlar la orientación del dispositivo. En todo momento se conoce la posición actual y la siguiente posición a visitar, por lo que si se sitúa al usuario en el mapa se sabe qué dirección debe tomar; Sin embargo el problema es conocer la orientación del usuario para dar una indicación u otra. Para ello fue necesario orientar el mapa al norte, implementar una brújula y hacer uso del acelerómetro. Sin embargo una vez implementada la brújula y realizadas las pruebas en el laboratorio se descartó esta alternativa debido a los numerosos fallos en la orientación producidos por los campos electromágneticos que generan las luces fluorescentes del laboratorio que hacían que cambiara la continuamente la orientación y por tanto diera instrucciones de guiado erróneas. La segunda alternativa no fue difícil de implementar, ya que como se ha comentado anteriormente, en todo momento se conoce la posición actual y la siguiente posición a visitar, de manera que comprobando a qué sección pertenece la siguiente posición a visitar ya se puede dar una indicación guiada. Para la resolución de esta alternativa se utlizaron las clases NSDictionary y NSMutableDictionary. Los objetos NSDictionary son inmutables (en otras palabras, una vez que se han creado e inicializado su contenido no se puede modificar), por lo que se inicializó agregando todas las entradas pertenecientes a las distintas secciones del supermercado junto con la clave que refleja el tag al que pertece cada sección, de manera que 99 cada par de clave-valor contenido dentro de un diccionario se refiere a una entrada. Finalmente se usa la segunda alternativa, debido en gran parte a los numerosos fallos de orientación que se producen mediante el uso de la brújula. Como conclusión a la solución, se presenta un diagrama de secuencia correspondiente a la Figura 4.22 Figura 4.22: Diagrama de Secuencia del Módulo de Enrutamiento 100 Capítulo 5 Métodos de trabajo E este capítulo se analiza la metodología de desarrollo aplicada para la resolución del presente Trabajo Fin de Grado, es decir, el desarrollo de la aplicación ShoppingBeacon. A continuación se describe la evolución del sistema, detallando las iteraciones realizadas hasta conseguir la versión final del sistema de acuerdo a la metodología seguida. N 5.1 Metodología de desarrollo Como metodología de desarrollo se ha optado por usar una aproximación a la metodología ágil Extreme Programming [Bec99] siguiendo un modelo iterativo e incremental. En el proceso iterativo e incremental cada una de estas iteraciones consta de varios incrementos, como muestra la Figura 5.1, que inician con el análisis y finalizan con la integración y validación del sistema. Figura 5.1: Evolución de los ciclos de desarrollo de Extreme Programming. Figura extraída de [Bec99] Lo que se busca es que en cada iteración los componentes logren evolucionar el producto a partir de los completados en iteraciones previas, logrando una mejora mucho más completa, por lo que este modelo establece prácticas de integración continua, exigiendo que el nuevo código sea integrado en el sistema completo con la menor demora posible tras su producción. Una manera de dirigir este proceso es priorizando los objetivos y requerimientos en función 101 del valor que ofrece al cliente. Por tanto este modelo requiere la involucración y participación directa del cliente en el desarrollo del proyecto, siendo muy frecuentes las reuniones presenciales entre el cliente y el equipo de desarrollo. El modelo de ciclo de desarrollo de Extreme Programming es una evolución del Modelo en Cascada y sus largos ciclos de desarrollo, y del siguiente paso que constituyen los ciclos más cortos e iterativos del Modelo Incremental, como muestra la Figura 5.1. Mediante el empleo de la metodología Extreme Programming se fijan múltiples iteraciones con pequeños objetivos planificados a corto plazo, proporcionando un mayor control sobre el sistema. Esta metodología debe llevarse a cabo en parejas de desarrollo, los cuales proporcionan estimaciones de tiempo y esfuerzo al cliente en las que se basa para decidir el alcance y periodicidad de las entregas. El cliente selecciona un pequeño conjunto de las “historias de usuario” propuestas para la entrega en base a las estimaciones obtenidas. Cada historia de usuario está descompuesta en un conjunto de tareas que tienen que ser llevadas a cabo por los desarrolladores en la siguiente iteración. Por lo tanto como metodología de desarrollo se ha optado por usar una aproximación a la metodología ágil Extreme Programming usando estas historias de usuario, descompuestas en funcionalidades siguiendo un modelo iterativo e incremental. 5.2 Evolución del desarrollo De forma previa al comienzo del desarrollo se llevó a cabo una etapa de estudio de estado del arte de los proyectos existentes exponiendo las principales ventajas y puntos débiles de cada una de ellas y elaborando un análisis comparativo. A continuación se realizó un análisis de requisitos inicial, estableciendo las diferentes funcionalidades que debe ofrecer el sistema al usuario y su arquitectura general. A continuación se procedió al diseño de los módulos y se comenzó su elaboración en iteraciones. 5.3 Iteraciones En este proceso de desarrollo, cuya metodología elegida es una aproximación a la metodología ágil Extreme Programming siguiendo un modelo iterativo e incremental, por los motivos expuestos en la Sección 5.1 del Capítulo 5, la labor del cliente la ha realizado D. Ramón Hervas Lucas, director del presente Trabajo Fin de Grado, con quien se han planificado las diferentes iteraciones del desarrollo y se han seleccionado las historias de usuario pertenecientes a cada iteración. A continuación se muestran las iteraciones realizadas en el desarrollo, describiendo las partes implementadas y los hitos conseguidos en cada una de ellas, junto con sus plazos de tiempo. 102 Iteración 1 El principal objetivo que se persigue en esta iteración es la construcción del prototipo del sistema. Este prototipo debe operar de forma aislada, simulando la operación en colaboración con los demás componentes del sistema, aún no implementados. En el caso de las operaciones que requieran la recuperación de datos de la base de datos, el prototipo operará sobre un conjunto de datos predefinido y almacenado en la aplicación, por lo que los cambios realizados a partir de la acción del usuario no son almacenados de forma persistente, limitándose al contexto de la ejecución de la aplicación. Esta iteración cuenta con las siguientes historias de usuario: Los usuarios pueden visualizar un catálogo de productos. Los usuarios pueden realizar la búsqueda de un producto escribiendo el nombre. Los usuarios pueden realizar la búsqueda de un producto dictando el nombre. Los usuarios pueden realizar la búsqueda aplicando un filtrado progresivo a medida que escriben el producto buscado. Los usuarios pueden visualizar la foto del producto. Los usuarios pueden visualizar la categoría del producto. Los usuarios pueden crear sus propias listas. Los usuarios pueden borrar sus propias listas. Los usuarios pueden añadir productos la lista. Los usuarios pueden eliminar productos la lista. Estas historias de usuario se traducen en las siguientes tareas: Creación de la vista de catálogo Creación de la vista de lista Implementación de las funcionalidad de búsqueda Implementación y Gestión de listas Esta iteración se llevó a cabo desde el 22 de Diciembre de 2015 hasta el 22 de Enero de 2015. La actividad desarrollada a lo largo de esta iteración puede observarse en el diagrama de Gannt de la Figura 5.2. Iteración 2 El principal objetivo que se persigue en esta iteración es la construcción de la base de datos del sistema. Esta base de datos sigue la estructura detallada en la Sección 4.4 del Capítulo 103 4. En esta operación se implementa la base de datos completa, incluyendo las clases de entidades y la interfaz pública de operaciones. Su desarrollo es integrado en cada una de las vistas, observando su correcto funcionamiento. Esta iteración cuenta con las siguientes historias de usuario: Los usuarios deben contar con una base de datos externa que respalde el contenido que pueden visualizar desde la aplicación. Los usuarios deben poder almacenar sus listas en una base de datos interna a la aplicación. Estas historias de usuario se traducen en las siguientes tareas: Diseño y construcción del modelo de base de datos Conexión con base de datos externa Conexión con base de datos interna Interfaz de operaciones públicas Construcción de clases de entidades Integración con el modelo de vistas Actualización automática del contenido de las vistas Esta iteración se llevó a cabo desde el 23 de Enero de 2015 hasta el 27 de Febrero de 2015. La actividad desarrollada a lo largo de esta iteración puede observarse en el diagrama de Gannt de la Figura 5.3 Iteración 3 El principal objetivo que se persigue en esta iteración es la comunicación con los dispositivos iBeacon. Por ello y partiendo del SDK de Estimote se implementa el módulo de Comunicaciones. Una vez implementado el módulo de comunicaciones se realizan las primeras pruebas mediante las aplicaciones Estimote y Particle Detector, en las que se observa que el valor de RSSI presenta variaciones, en principio debidas a la fluctuación de la señal. Sin embargo, mediante la realización de pruebas se llega a la conclusión de que esa fluctuación no es debida sólo a las que suelen ser sus causas principales, como la difracción, refracción y multitrayectos, sino también a una mala calibración del dispositivo por parte del fabricante y a la orientación de las balizas. Finalmente se resuelven ambos problemas mediante una nueva calibración y el estudio de la orientación correcta y la posterior decisión final de colocar los dispositivos en una orientación vertical. Sólo queda el problema de la fluctuación de la señal ocasionado por sus causas típicas, de manera que se estudia la frecuencia de la señal idónea para eliminar esa fluctuación, llegando 104 a la conclusión de que la frecuencia idónea son 1500ms, por lo que se decide modificar el valor de la frecuencia de la señal mediante el SDK de Estimote. Esta iteración cuenta tan sólo con una historia de usuario, que sin embargo es de suficiente magnitud como para ocupar toda la iteración. El dispositivo del usuario debe ser capaz de comunicarse con dispositivos iBeacon. Esta historia de usuario se traduce en las siguientes tareas: Integración de la API de los dispositivos iBeacon Comunicación con los dispositivos iBeacon Primera y Segunda Etapa de pruebas: • Calibración del dispositivo • Prueba Colocación dispositivo • Prueba frecuencia idónea Esta iteración se llevó a cabo desde el 2 de Marzo de 2015 hasta el 23 de Marzo de 2015. La actividad desarrollada a lo largo de esta iteración puede observarse en el diagrama de Gannt de la Figura 5.4. Iteración 4 En esta cuarta iteración el principal objetivo que se persigue es la implementación de una aplicación para realizar las pruebas en el Salón de Grados de la Escuela Superior de Informática. Esta aplicación debe ser capaz de identificar cualquier cambio dentro de las regiones conocidas y estimar la posición del usuario, calcular el camino mínimo y por último visualizar la transición producida por dicho cambio mediante una animación. En esta iteración por lo tanto se hace uso del módulo de Comunicaciones, se implementan el módulo de Tratamiento de Señal para hacer una distinción con el tipo de señal recibida, el módulo de Posicionamiento para asignar a la frecuencia de señal recibida una posición, el algoritmo de Dijkstra para obtener el camino mínimo al realizar cada cambio de posición y finalmente la gestión de animaciones. Para estudiar cómo se desarrollan los cambios, esta aplicación contará con un mapa que simule la sala donde se realizan las pruebas y con los valores RSSI obtenidos de las distintas balizas que reflejen la decisión a los cambios de ubicación del usuario. Esta iteración cuenta con las siguientes historias de usuario: El usuario puede visualizar un mapa de la sala de pruebas. El usuario puede visualizar los valores de la señal de los dispositivos. 105 El usuario puede visualizar su ubicación mediante una animación. El sistema estima la ubicación del usuario. Estas historias de usuario se traducen en las siguientes tareas: Diseño y Creación de un mapa de la sala de pruebas Diseño de la interfaz de prototipo. Calculo del camino mínimo • Representar estructura del grafo • Implementación del algortimo de Dijkstra Tratamiento de señal • Implementación del módulo de tratamiento de señal • Integración hilos Interpretación de señales • Creación de una mapa de potencias • Registro de potencias de secciones registradas • Implementación del módulo de Posicionamiento Interpretación de la señal para determinar ubicación Animación del recorrido Esta iteración se llevó a cabo desde el 23 de Marzo de 2015 hasta el 18 de Mayo de 2015. La actividad desarrollada a lo largo de esta iteración puede observarse en el diagrama de Gannt de la Figura 5.5. Iteración 5 En esta quinta iteración y debido a los resultados obtenidos en las pruebas realizadas en la iteración anterior, el principal objetivo que se persigue es la creación de un filtro que permita eliminar los valores extremos producidos por la fluctuación de la señal. Para ello se implementa un filtro basándose en una media aritmética de todos los valores recibidos(Moving Average), sin embargo los resultados siguen sin ser aceptables y basándose en el mecanismo implementado, en la técnica Weighted Moving Average y la calibración de los dispositivos, se crea un filtro que obtiene mejores resultados al no deshacerse de esos valores extremos. Esta iteración cuenta con la siguiente historia de usuario: El dispositivo del usuario debe ser capaz de filtrar valores extremos producidos por la fluctuación. 106 Esta historia de usuario se traduce en las siguientes tareas: Implementación del módulo de Filtrado de Señal • Moving Average • Filtro con intervalos de confianza Esta iteración se llevó a cabo desde el 19 de Mayo de 2015 hasta el 27 de Mayo de 2015. La actividad desarrollada a lo largo de esta iteración puede observarse en el diagrama de Gannt de la Figura 5.6. Iteración 6 Una vez diseñada, implementada y probada la arquitectura del sistema mediante prototipos de aplicaciones con mapas de prueba en los que sólo se registran los cambios de ubicación y se muestran los valores de RSSI, en esta sexta iteración se crea la aplicación final. Esta aplicación opera en colaboración con los demás módulos del sistema. Se diseña un mapa de la sala y un mapa con las secciones pudiendo cambiar entre ambos modelos, en tiempo de ejecución. Se debe generar una animación inicial de la ruta que debe seguir el usuario y mostrar en todo momento el elemento al que se dirige y el número de elementos que le quedan por coger. Durante la fase de implementación del sistema de guiado surgen dos propuestas, la primera de ellas se basa en guiar al usuario mediante orientaciones y la segunda se basa en nombrar mediante voz qué es lo que puede ver el usuario. Aunque finalmente se opta por la segunda propuesta se comienza a implementar la primera propuesta y se termina descartando. Esta iteración cuenta con las siguientes historias de usuario: El usuario puede visualizar un mapa de una nueva sala de pruebas. El usuario puede visualizar un mapa de una nueva sala de pruebas mostrando las secciones. El usuario puede cambiar el tipo de mapa. El sistema proporciona al usuario la ruta con el camino óptimo. El usuario visualiza una animación de la ruta con el camino óptimo. El usuario puede visualizar el siguiente producto que debe coger. El usuario puede visualizar el número de productos restantes por coger. El usuario puede deshabilitar y habilitar la opción de guiado. El sistema comunica al usuario la siguiente dirección. Estas historias de usuario se traducen en las siguientes tareas: 107 Diseño de mapa sin secciones Diseño de mapa con secciones Nuevos datos para el mapa de posicionamiento Diseño de la interfaz de la aplicación final Implementación del algoritmo de fuerza bruta Implementación del sistema de guiado Guiado Orientaciones • Integración Framework OpenEars • Implementación brújula • Análisis valores brújula • Análisis valores acelerómetro Guiado Visual Esta iteración se llevó a cabo desde el 28 de Mayo de 2015 hasta el 23 de Junio de 2015. La actividad desarrollada a lo largo de esta iteración puede observarse en el diagrama de Gannt de la Figura 5.7. Iteración 7 Una vez terminada la implementación del sistema y realizadas las pruebas, se revisa el código buscando partes susceptibles de ser mejoradas y nuevas funcionalidades. Se consideró oportuno la adición de la clase NSFetchedResultsController y los protocolos asociados para la realizar una solicitud de recuperación de datos. También se realizó una nueva implementación del algoritmo para la búsqueda del camino mínimo mediante el empleo de programación dinámica, suponiendo un mayor coste en memoria en pro de tiempo de cómputo. Esta iteración no contiene historias de usuario , albergando la realización de las siguientes tareas: Implementación del algoritmo de dinámica. Optimización en gestión y almacenamiento. Esta iteración se llevó a cabo desde el 24 de Junio de 2015 hasta el 3 de Julio de 2015. La actividad desarrollada a lo largo de esta iteración puede observarse en el diagrama de Gannt de la Figura 5.8. Iteración 8 108 En esta iteración se añade un sistema de notificaciones que muestre una alerta al usuario en una fecha y hora determinada por éste, en el momento de creación de una nueva lista, y la opción de mandar la lista del usuario por correo. Esta iteración cuenta con las siguientes historias de usuario: El usuario puede configurar una alerta a modo de recordatorio al crear su lista. El usuario puede recibir notificaciones. El usuario puede mandar la lista por correo. Estas historias de usuario se traducen en las siguientes tareas: Implementación del servicio de notificaciones. Integración de la funcionalidad de envío de correos. Esta iteración se llevó a cabo desde el 28 de Junio de 2015 hasta el 2 de Julio de 2015. La actividad desarrollada a lo largo de esta iteración puede observarse en el diagrama de Gannt de la Figura 5.9. 109 110 Figura 5.3: Proceso de desarrollo: Iteración 2 Figura 5.2: Proceso de desarrollo: Iteración 1 111 Figura 5.5: Proceso de desarrollo: Iteración 4 Figura 5.4: Proceso de desarrollo: Iteración 3 112 Figura 5.7: Proceso de desarrollo: Iteración 6 Figura 5.6: Proceso de desarrollo: Iteración 5 113 Figura 5.9: Proceso de desarrollo: Iteración 8 Figura 5.8: Proceso de desarrollo: Iteración 7 Capítulo 6 Resultados E este capítulo se presentan las principales pruebas realizadas junto con los resultados obtenidos tras el desarrollo del sistema iBeacon para la recepción de señales procedentes de balizas BTLE (Bluetooth Low Energy) y posterior localización, animación y guiado al usuario. N En primer lugar se realizan unas pruebas iniciales para observar el comportamiento de las señales. Tras las primeras pruebas y los resultados obtenidos se observan variaciones en la frecuencia y se plantean distintas causas que pudieran provocar dicha variación. Una vez implementadas las soluciones y tras una localización positiva se plantea el escenario de localización de un usuario en una superficie comercial. Por último se realiza una conclusión personal sobre las pruebas obtenidas. De esta manera, los experimentos se han realizado en tres etapas principales y con diferentes objetivos en cada una de ellas. La primera etapa consiste en una primera toma de contacto para observar el comportamiento de la señal Bluetooth. La segunda etapa se ha centrado en el análisis de RSSI en diferentes posiciones, y su relación con la distancia y en base a estos resultados a la configuración del sistema iBeacon con el fin de validar la posibilidad de implementación del sistema de localización basado en iBeacon. Finalmente, en la tercera etapa se simulan distintos entornos de localización con el fin de analizar la viabilidad de implementación del sistema iBeacon como método de localización en interiores. En el desarrollo de las pruebas se han utilizado tres balizas iBeacon para la emisión de las señales Bluetooth y un dispositivo iPhone 5 para la recepción y lectura de RSSI. 6.1 Primera etapa: Análisis del comportamiento de la señal BLE Como ya se explicó en la Sección 4.6.1 del Capítulo 4, un iBeacon se encarga de transmitir paquetes de datos basándose en la tecnología BLE. De estos paquetes de datos se utilizan los valores de UUID, Major, Minor y Tx Power para la identificación del mismo y el cálculo estimado de la distancia a la que se encuentran los dispositivos. En esta primera etapa, como ya se ha comentado, se observa el comportamiento de la señal Bluetooth mediante el uso de diferentes aplicaciones: Estimote y Particle Detector. Este primera etapa se llevó a cabo en el salón de grados de la Escuela Superior de Infor115 Figura 6.1: App Estimote Figura 6.2: App Particle Detector mática colocando tres balizas en la sala. Mediante las pruebas con estas aplicaciones, se comprobó que el valor de RSSI presentaba variaciones. Estas variaciones del valor RSSI, se debían a la fluctuación de la señal haciendo complicada la determinación de la distancia. Sin embargo en una de las pruebas se descubrió que un dispositivo presentaba variaciones del valor de RSSI en igualdad de condiciones que las otras dos, es decir, con la misma posición y la misma colocación. Esta variación perteneciente a la baliza azul se debía a una mala calibración por parte del fabricante de manera que se realizó una calibración del dispositivo(Anexo A). Al realizar esta calibración se obtuvieron resultados similares para las tres balizas. Otro agente que variaba el valor RSSI de las tres balizas fue la colocación de éstas. De la misma manera que el estudio anterior, esta prueba consiste en la toma de 30 medidas de una de las balizas cambiando la orientación de ésta a una distancia de 5 y 10 metros, obteniendo los siguientes resultados: 116 Distancia Real No Mediciones Horizontal RRSI Media Distancia Media Dif. Distancia No Mediciones Vertical RRSI Media Distancia Media Dif. Distancia 5m 30 -63.11 3.21 1.79 30 -65.11 4.06 0.94 10m 30 -68.21 5.70 4.30 30 -72.65 8.84 1.16 Tabla 6.1: Resultados de estudio de valores según el plano de orientación. Como se puede observar en las Tabla 6.1, los resultados más exactos se obtienen colocando la baliza verticalmente. Por lo tanto se decide orientar las tres balizas en su eje vertical. Mediante las pruebas con estas aplicaciones, se comprueba que el valor de RSSI variaba debido a: Colocación de dispositivos. Mala calibración por parte del fabricante. Fluctuaciones. Los dos primeros puntos se consiguen resolver, sin embargo aun quedan por resolver las causas principales de fluctuación de RSSI como son la difracción, refracción y multitrayectos. Por ello se realizó un estudio acerca de la posibilidad de ajustar la potencia de transmisión y la frecuencia de transmisión de pulsos con el fin de minimizar la fluctuación. A la hora de buscar la potencia de transmisión y la frecuencia de emisión de señales idónea de los dispositivos iBeacons de Estimote, se partió del SDK de Estimote. Se obtuvieron resultados positivos, ya que era posible modificar ambos valores, el primero de ellos ya utilizado en la calibración del dispositivo. 6.2 Segunda etapa: Análisis de RRSI La segunda etapa se llevó a cabo en el salón de grados de la Escuela Superior de Informática y consistió en dos fases de mediciones (primera fase a 5 metros y segunda fase a 10 metros), cada una de ellas con 30 medidas de RSSI, colocando las tres balizas verticalmente en la pared. Esta etapa pretende solventar los problemas de fluctuación mediante el estudio de la frecuencia de señal idónea de manera que se toman 30 medidas de RSSI con los siguientes intervalos de repetición: 100 ms, 500 ms, 1000 ms, 1500 ms 2000 ms, llevando a cabo un estudio con el fin de configurar un intervalo de repetición que produzca una señal estable, obteniéndose los datos de la Tabla 6.2. 117 iBeacon1 5m 10m iBeacon2 5m 10m iBeacon3 5m 10m PRI Distancia Real 100 ms RRSI Media(dBm) Desviación Distancia según RRSI -67.12 3.4 5.11 -62.3 1.16 2.92 -68.36 3.02 5.76 -64.11 0.7 3.59 -67.45 1.3 5.31 -70.1 2.01 7.14 500 ms RRSI Media(dBm) Desviación Distancia según RRSI -63.9 1.3 3.48 -67.1 1.89 5.02 -68.5 1.48 5.96 -71.2 3.34 8.18 -65.89 1.5 4.3 -70.17 3.51 7.22 1000 ms RRSI Media(dBm) Desviación Distancia según RRSI -63.49 1.2 3.34 -68.7 1.09 6.11 -64.3 2.2 3.87 -71.47 3.16 8.38 -61 0.88 2.54 -70.97 2.99 7.91 1300 ms RRSI Media(dBm) Desviación Distancia según RRSI -68.63 2.1 6.05 -66.1 3.1 4.79 -68.4 1.1 5.86 -67.6 1.5 5.41 -64.01 2.76 3.55 -67.13 3.68 5.14 1500 ms RRSI Media(dBm) Desviación Distancia según RRSI -63.89 0.54 3.45 -72.18 2.1 8.65 -63.2 0.91 3.24 -71.7 1.8 8.51 -64.2 0.76 3.8 -71.53 1.53 8.45 2000 ms RRSI Media(dBm) Desviación Distancia según RRSI -63.53 1.4 3.26 -70.09 2.99 7.17 -68.71 3.1 6.19 -68.82 1.87 6.25 -68.83 1.56 6.31 -65.17 2.27 4.06 Tabla 6.2: Medición de fluctuación de RSSI con diferentes intervalos de repetición de pulsos. Los valores marcadas en color verde son aquellos que se adaptan con mejor exactitud a la distancia real de medida. Se trata de los valores de desviación típica sobre un valor central y la distancia estimada. Como se puede observar en la tabla 6.2, la señal iBeacon presenta una mayor estabilidad en los valores con un intervalo de repetición de pulsos de 1500ms. De manera que una vez finalizada la segunda etapa y tras los resultados obtenidos se establece el intervalo de pulsos en 1500ms. 6.3 Tercera etapa: Desarrollo del experimento La tercera etapa se llevó a cabo en el salón de Grados y en el laboratorio MAMI de la Escuela Superior de Informática. El objetivo de esta etapa es analizar la viabilidad de implementación del sistema iBeacon mediante el análisis de 3 experimentos, dos de ellos en el Salón de Grados y el tercero en el laboratorio MAMI. Primer Experimento El primer experimento consiste en analizar los cambios que se producen en la sala al cambiar de ubicación. Para ello lo primero que se realizó fue un plano de la sala simulando los pasillos de un supermercado. A continuación se realizó un estudio para identificar el 118 mayor numero de secciones que se pudieran registrar mediante el uso de 3 balizas. Debido al numero reducido de balizas, las medidas de la sala, el ser un espacio abierto y a la distancia mínima y máxima entre balizas que toman los valores de 3 y 10 metros respectivamente, sólo se pudo registrar 4 secciones. Estas secciones corresponden a los tag 01, 05, 31 y 35 de la Figura 6.3. Figura 6.3: Primer Experimento En principio se registraron 6 secciones, sin embargo las dos secciones más apartadas reciben una señal muy similar a los dos secciones más cercanas que pertenecen a los tag 31 y 35, de manera que las pruebas intercambiaban los valores de las dos secciones a la izquierda y las dos secciones a la derecha, por lo que se decidió registrar 4 secciones. El experimento consiste en recorrer cada una de las 4 secciones registradas dos veces de manera aleatoria, de manera que el sistema iBeacon sea capaz de determinar la posición que se ocupa y realizar una animación hasta ese punto. Durante la realización de este experimento se comprobó que el valor de RSSI presentaba variaciones cuando el usuario se acerca a una luz fluorescente produciendo una variación de -65 -75, que equivale a un error de medida de +-2.5metros. Además, cuando se desplaza alrededor de la sala, se descubrió que el propio usuario actúa de pantalla dando al dar la espalda a un dispositivo produciendo una variación en el valor RSSI equivalente a 2-3 metros. 119 Con estos resultados se llega a la conclusión de que el posicionamiento en interiores empleando el uso de iBeacon no está orientado a la exactitud en la posición concreta del usuario, sino que estará enfocado a determinar la sección en la que se encuentra. Segundo Experimento El segundo experimento se realiza en la misma sala con la misma posición de los dispositivos iBeacon y las mismas secciones registradas, sin embargo este experimento consiste en analizar y monitorizar las señales procedentes de las tres balizas a medida que el usuario se desplaza por las 4 secciones establecidas siguiendo un itinerario. Este itinerario consiste en una ruta compuesta por las 4 secciones que contiene la sala. El itinerario comienza en el tag 43, y se visitan en orden los tag: 05, 35, 31, 01, 31, 05 y 03. La ruta se realiza de manera constante usando el sistema implementado que incorpora un filtro. El entorno interior de la sala y sus dimensiones, permiten establecer los dispositivos en un radio no superior a 10 metros, por lo que el rango de proximidad se centrará entre Immediate y Near. Para situar al usuario dentro del entorno se analizara la frecuencia de señal que recibe de cada uno de los dispositivos con posiciones conocidas identificando en que rango de proximidad se encuentran. La ubicación de los iBeacon es: iBeacon Morado colocado en la pared detrás de la posición del usuario. iBeacon Verde colocado en la pared entre los tag 00 y 30. iBeacon Azul colocado en la pared entre los tag 06 y 36. La Tabla 6.3 muestra una comparativa entre los rangos de proximidad real y la proximidad obtenida con la medida de RSSI. Punto de Medida 05 35 31 01 31 05 01 iBeacon Morado Real Medida Near Near Immediate Immediate Immediate Immediate NULO Near Immediate Near Near Near Near Immediate iBeacon Verde Real Medida Near Near Near Near Immediate Immediate Immediate Immediate Immediate NULO Near Near Immediate Far iBeacon Azul Real Medida Immediate Near Immediate Immediate Near NULO Near Near Near Far Immediate Immediate Near Near Tabla 6.3: Comparativa de proximidad real-media. Con estos resultados se finaliza el experimento y se concluye que el dato principal para determinar la ubicación de un usuario es el rango de distancias, haciendo uso de las pro120 ximidades Near e Immediate, que aseguran una localización admisible, obviando el uso de la proximidad Far ya que se utiliza para distancias de más de 10 metros y por lo tanto no permite una correcta localización. Por tanto, si sólo se desea contener proximidades Near e Inmediate, el factor más influyente e importante a tener en cuenta es la correcta colocación de los dispositivos que permita establecer zonas de cobertura comprendidas entre estos dos rangos. Tercer Experimento El tercer experimento se realiza en el laboratorio MAMI, en el que se colocan de manera análoga los tres dispositivos y se registran 4 secciones. Para ello lo primero que se realizo fue un plano del laboratorio simulando un supermercado que contiene varias secciones, distinguiendo dos tipos de mapas: Plano esquemático dibujado del laboratorio, como muestra la Figura 6.4. Plano esquemático dibujado del laboratorio que te permita distinguir las distintas secciones, como muestra la Figura 6.5. Figura 6.4: Plano Esquemático del laboratorio Figura 6.5: Plano esquemático del laboratorio con secciones A continuación y de manera análoga al Experimento 1 se realiza un estudio para identificar el mayor número de secciones que se pudieran registrar mediante el uso de tres balizas. 121 Debido al número reducido de balizas, las medidas de la sala y a la distancia mínima y máxima entre balizas que toman los valores de 3 y 10 metros respectivamente, la cantidad de fluctuación debido a los números dispositivos y fluorescentes que se encuentran en la sala y generan ondas electromagnéticas, se consiguen únicamente 4 secciones a pesar de tener armarios que hacen la función de pasillo y por tanto de pantalla. De manera análoga al experimento 2, este experimento consiste en analizar y monitorizar las señales procedentes de las tres balizas a medida que el usuario se desplaza por las 4 secciones establecidas siguiendo una ruta. Esta ruta, que parte de la posición en la que se encuentra inicialmente el usuario, pasa por las secciones de Perfumería, Mascotas, Bollería y Frutas y Verduras, repitiendo el ciclo dos veces y finalmente regresa a la posición inicial. Por lo tanto, el itinerario comienza en el tag 64, y se visitan en orden los tag: 63, 60, 10, 13, 63, 60, 10 y 13. La ruta se realiza de manera constante usando el sistema implementado, que incorpora un filtro. Al tener este laboratorio unas medidas similares al salón de grados donde tuvo lugar el Experimento 2, se vuelve a establecer el rango de proximidad entre Immediate y Near. El mapa se ha realizado de la misma manera que el usado en el salón de Grados, pero en este caso, se ha dividido el aula en 7 filas y 5 columnas. La ubicación de los iBeacon es: iBeacon Morado colocado en la pared detras del tag 54 que corresponde a la sección de hogar, representada por una pila. iBeacon Verde colocado en la estanteria detras del tag 41 que corresponde a la sección de congelados y bebidas, representado por el símbolo del congelado y una botella. iBeacon Azul colocado en la pared detras del tag 10 que corresponde a la sección de horno y bollería, representado por una rebanada de pan. La Tabla 6.4 muestra una comparativa entre los rangos de proximidad real y la proximidad obtenida con la medida de RSSI. Era de esperar que estos valores fueran peores que en el Experimento 2, debido a la cantidad de fluctuación, sin embargo estos valores sólo son peores en la sección de Frutería cuyo tag es el numero 13 y contiene un único acierto. Esto sucede por no tener ningun dispositivo cerca, y por el contrario el resultado del resto de secciones, al disponer de un dispositivo cerca, es similar al obtenido en el Experimento 2. De igual manera que en el experimento 2 el factor más influyente e importante a tener en cuenta es la correcta colocación de los dispositivos que permita establecer zonas de cobertura comprendidas entre estos dos rangos. Como ya se ha comentado con anterioridad, una vez finalizado el experimento y observando los resultados obtenidos en la Tabla 6.4 se concluye que el dato principal para determinar 122 Punto de Medida 63 60 10 13 63 60 10 13 iBeacon Morado Real Medida Immediate Immediate Near Near Near NULO Near Far Immediate Immediate Near Near Near Far Near Far iBeacon Verde Real Medida Near Near Near Near Near Near Near Near Near Near Near Near Near Far Near NULO iBeacon Azul Real Medida Near Far Near Far Immediate Immediate Near Far Near NULO Near Far Immediate Immediate Near Far Tabla 6.4: Comparativa de proximidad real-media. la ubicación de un usuario es el rango de distancias, haciendo uso de las proximidades Near e Immediate, que aseguran una localización admisible, obviando el uso de la proximidad Far ya que se utiliza para distancias de más de 10 metros y por lo tanto no permite una correcta localización. 6.4 Conclusión Una vez realizadas las pruebas se llega a la conclusión de que el sistema implementado no está orientado a la exactitud en la posición concreta del usuario sino enfocado a determinar la sección en la que se encuentra. Partiendo de esta base se determina que el usuario se encuentra en un rango de distancias, tomando como referencia los rangos establecidos en iOS cuyos valores son: Near: El nodo móvil se encuentra a una distancia menor de 2 metros. Immediate: El nodo móvil se encuentra a una distancia comprendida entre 2 y 10 metros. Far: El nodo móvil se encuentra a una distancia mayor de 10 metros. El radio de acción máximo de los iBeacons está en 70 metros pero en realidad es mucho menor, como se ha podido comprobar en las pruebas realizadas, debido a las interferencias que producen los elementos circundantes tales como mobiliario, paredes, vidrio, hormigón, el propio cuerpo humano e incluso los agentes atmosféricos. Los iBeacons han sido elogiados por su capacidad para proporcionar servicios de localizacion indoor, asegurando que pueden localizar un dispositivo móvil con una precisión de centímetros mediante la triangulación de la señal desde múltiples balizas. Sin embargo tras una búsqueda y realizar las pruebas se puede afirmar que la no hay ninguna función de ubicación por triangulación implementada dentro del Protocolo BLE o API de iBeacons. Además, el rango de localización de un nodo móvil respecto a la posición del iBeacon oscila en metros, de ahí que Apple recomiende [App] usar el valor RSS para la localización, 123 ya que al oscilar el valor en metros, nunca se puede llegar a tener una certeza en la precisión de centímetros y por lo tanto no puede usarse para localizar con exactitud un nodo móvil. Además, dependiendo del sistema operativo, en casos como iOS7 es necesario estar al menos 20 segundos en la zona de cobertura del iBeacon para recibir una notificación [You14]. Si se pretende una localización basada en la exactitud del usuario, sería necesario una mayor cobertura que implique mayor información y mayor fiabilidad, ya que al recibir la señal de múltiples dispositivos y por múltiples caminos se garantiza una mayor exactitud. Para ello sería necesario una red con topología de malla en el que la distancia entre nodos tenga un máximo de 10 metros y un mínimo de 4 metros, de manera que el nodo móvil reciba la señal de un número suficiente de nodos de referencia para realizar una estimación más correcta de la posición del nodo móvil. Para la superficie en la que se han realizado las pruebas, lo idóneo hubiera sido un total de 9 nodos de referencia, donde el esquema de coberturas quedaría como muestra la Figura 6.6. Figura 6.6: Nodos de Referencia en topología de malla Un aumento de los nodos de referencia supondría una mayor exactitud, sin embargo utilizar más nodos de los necesarios supondría una perdida de precisión, ya que lo más lejanos contendrían valores extremos que se utilizarían en la estimación y por tanto corromperían el cálculo de la media de la señal [BP00]. De manera que aunque se tengan multiples nodos de referencia solo se utilizarían los n nodos más cercanos. 124 6.5 Modulos funcionales de la aplicación La estructura de la aplicación ShoppingBeacon se compone de los siguientes módulos funcionales: Catálogo Listas Comprar El acceso a los diferentes módulos se realiza a través de la barra de acceso directo situada en la parte inferior de la pantalla, aunque por defecto aparece el Catálogo de productos. Cada uno de estos módulos es examinado a continuación, incluyendo capturas de la interfaz de usuario que reflejan la operación con cada uno de ellos. Catálogo Permite al usuario buscar cualquier producto mediante la barra de búsquedas que permite localizar el producto de manera escrita o hablada, o de manera manual buscando entre todos los productos del catálogo. Figura 6.7: Catálogo de productos 125 Listas Permite al usuario generar una lista personalizando ésta con el título que desea el usuario. Al generar la lista aparece una ventana emergente, preguntando si se desea realizar una alerta a base de recordatorio. Una vez creada la lista, se puede editar con la incorporación y eliminación de productos. De la misma manera que en el módulo funcional del Catálogo, la obtención del producto que se desea añadir a la lista se puede hacer de manera manual o mediante una barra de búsqueda que permite al usuario escribir el producto que desea o dictarlo. También permite al usuario mandar por correo la lista generada. Figura 6.8: Listas de listas Figura 6.9: Creación de alertas 126 Figura 6.10: Selección de fecha y hora Figura 6.11: Notificación de alerta 127 Figura 6.13: Modficaión de la lista de porductos Figura 6.12: Lista de procutos 128 Figura 6.14: Generar un correo con la lista de la compra 129 Comprar Este módulo presenta un mapa del centro en el que se realiza la compra, pudiendo alternarse con otro mapa de la zona en la que aparecen las secciones. Este módulo comienza calculando la ruta que suponga la ruta de coste mínimo y pase por todos los productos que desea el usuario, y en base a esta ruta genera una animación. A continuación se dedica a la monitorización de señales y a detectar cualquier cambio en la posición del usuario para generar la animación del movimiento. La interfaz muestra en todo momento el siguiente producto a recoger y los productos restantes. Además, el usuario puede añadir la opción de guiado mediante voz. Figura 6.16: Mapa de interior consecciones Figura 6.15: Mapa de interior 130 Capítulo 7 Conclusiones y Propuestas E este capítulo se muestran los objetivos alcanzados durante el desarrollo de este Proyecto Fin de Grado y se detallan el posible trabajo futuro de cara a la mejora o la ampliación del sistema desarrollado. Se finaliza con una conclusión personal de lo que ha supuesto llevarlo a cabo. N 7.1 Objetivos Alcanzados Una vez finalizado, el presente Trabajo Fin de Grado cumple con todos y cada uno de los objetivos que se especificaron en el Capítulo 2. Sin embargo, mas allá de la lista formal de requisitos, el propósito del presente Trabajo Fin de Grado es el que se anunció como motivación en la Sección 1.4 del Capítulo 1: construir un sistema que se basa en la recepción de señales que permitan localizar al usuario dentro de un edificio en un mapa previamente facilitado y con unos puntos a recorrer para guiar al usuario hasta ellos. Por ello y basándose en el análisis de las aplicaciones ya existentes que ofrecen un servicio similar, que se expone en el Capítulo 3, se muestra la Tabla 7.1, señalando las características deseables que ha de tener la aplicación y cuáles han sido alcanzadas, de manera que permita comprobar en qué medida se ha cumplido con esta especificación inicial. Durante el desarrollo del proyecto se ha tratado de utilizar enfoques de diseño y prácticas de programación y herramientas que contribuyan no sólo a un producto final caracterizado por lo que ofrece sino por su calidad. El diseño del sistema se ha realizado tratando de garantizar la independencia de los subsistemas obteniendo un sistema fácilmente mantenible y extensible tanto a la hora de generar rutas en distintas superficies comerciales o la incorporación de más dispositivos beacon que supongan una mayor exactitud. 131 App Listas de la Compra App Localización Indoor Características - La app debe contener una base de datos con los productos del centro comercial al que va a estar destinada la app. 3 - Los productos deben contener una imagen que haga más intuitiva la localización dentro del catálogo de productos. 3 - Los productos deben tener un precio asignado. 3 - Los productos pueden ser buscados de manera escrita o por comandos de voz. 3 - El usuario puede crear varias listas. 3 - El usuario puede visualizar el precio de la lista con los productos ya escogidos. 3 - El usuario puede compartir la lista con cualquier otra persona. 3 - El usuario puede añadir una alerta a cada lista para que le avise en una fecha concreta. 3 - Indicación de los productos disponibles 3 - Búsqueda de productos disponibles 3 - Uso de plano esquemático dibujado interior 3 - Posicionamiento interior 3 - Visualización de Servicios interiores 3 - Rutas Origen-Destino 3 - Guiado 3 Tabla 7.1: Características de ShoppingBeacon 132 7.2 Trabajo Futuro El presente Trabajo Fin de Grado cumple con todos los requisitos descritos en la Sección 2.2 del Capítulo 2, sin embargo durante el desarrollo del sistema surgen nuevas vías de trabajo que pueden mejorar el sistema ShoppingBeacon, y que debido a restricciones temporales no se han llevado a cabo, por lo que se proponen como trabajo futuro. Las siguientes propuestas de ampliación y mejora son: Integración de un servidor de base de datos: Uno de los objetivos del presente Trabajo Fin de Grado es el acceso a un catálogo remoto, sostenido por una base de datos, que permita consultar los distintos productos. Debido a restricciones temporales dicha base de datos externa consiste en un archivo SQLite interno en la propia carpeta de la aplicación. Esta base de datos almacenará los datos de carácter persistente y simula el comportamiento como si de un servidor de base de datos se tratara, al ser necesario realizar consultas a ésta para mostrar los productos. Sin embargo no es posible actualizar de forma remota los datos que almacena y supone un coste añadido en memoria. Es por ello que se propone como trabajo futuro un servidor de base de datos que almacene los catálogos disponibles para el usuario. Con la implementación de este servidor de base de datos se podrá realizar una actualización periódica de los catálogos, como es el caso del precio de los productos o la adición de nuevos productos, sin necesidad de recurrir a actualizaciones de la App. También se propone, de manera análoga a la aplicación myShopi comentada en la Sección 3.2 del Capítulo 3, hacer una distinción inicial con la superficie comercial donde se va a realizar la compra. De esa manera se podría acceder a la lista de productos, precios y mapa de la superficie comercial de cada uno de los supermercados. Toda esta información estaría disponible en el servidor de base de datos por lo que la App realizaría una revisión periódica para mantener los datos accesibles al usuario actualizados. Añadiendo un servidor de base de datos se dispondría de un mayor volumen de memoria, se ofrecería más funcionalidad a la App y se mantendrían los datos actualizados, por lo que tendría una prioridad alta a la hora de realizar el trabajo futuro. Posibilidad de reajustar el algoritmo de localización: Debido a la inexactitud en la localización del usuario producida por la fluctuación de la señal y el uso de tres dispositivos beacon, se determina en la Sección 6.4 del Capítulo 6 que el sistema está enfocado a determinar la sección en la que se encuentra. Sin embargo, si se desea una localización basada en la exactitud del nodo móvil, sería necesaria una mayor cobertura que implique mayor información y por tanto mayor fiabilidad, ya que al recibir la señal de múltiples dispositivos y por múltiples caminos se garantiza una mayor exactitud. Para ello se propone una topología de malla, donde los dispositivos tengan un radio entre ellos en un rango mayor a cuatro metros y menor de diez metros, 133 consiguiendo por tanto que el nodo móvil reciba más señales y de esa manera realice una estimación más correcta. Un aumento de los nodos de referencia supondría una mayor exactitud, sin embargo utilizar más nodos de los necesarios supondría una perdida de precisión, ya que los más lejanos contendrían valores extremos que se utilizarían en la estimación y por tanto corromperían el cálculo de la media de la señal; de manera que aunque se tengan múltiples nodos de referencia solo se utilizarían los k nodos más cercanos. Según muestran Bahl y Padmanabhan en su estudio RADAR [BP00], el número de nodos de referencia idóneo para el posicionamiento es 5. Por lo tanto, para estimar la posición del nodo móvil en el sistema, se utilizaría una sistema basado en la cercanía a múltiples nodos de referencia, usando de igual manera la fuerza de la señal recibida para localizar los 5 nodos más cercanos en localizaciones conocidas al estar almacenados en un mapa de potencias. Una vez almacenados los 5 nodos más cercanos se aplicaría la función propuesta por Serodio y Coutinho [CS] que consiste en una función difusa asignando pesos a los nodos tomados como referencia para calcular las coordenadas del nodo móvil. La asignación de pesos se basa en la proximidad de los nodos de referencia, asignando pesos mayores a los nodos más cercanos, cuyo valor en la ponderación desciende cuando aumenta la distancia desde el nodo móvil. 134 7.3 Conclusión Personal Durante el desarrollo del Trabajo Fin de Grado un Ingeniero debe hacer uso de los conocimientos adquiridos en los años que se ha formado, no sólo pertenecientes a los campos de la informática, sino a muchas más áreas de conocimiento como las Matemáticas, Álgebra, Estadística, incluso Sociología, aunque dadas sus características y las restricciones temporales numerosas áreas no hayan tenido cabida en él. El presente Trabajo Fin de Grado constituye el fin de la formación de un Ingeniero Informático, sin embargo y a pesar de acabar mi formación, durante el desarrollo me he dado cuenta de que la formación adquirida durante estos años es sólo la punta del iceberg y el haber terminado este proceso de formación no implica que haya que dejar de formarse, ya que la nuestra es una ciencia en constante evolución en la que todos los días se aprende algo nuevo. El desarrollo de este Trabajo Fin de Grado ha supuesto la experiencia más cercana durante toda la carrera a un proyecto real y de gran envergadura. Considero que a partir de este momento soy capaz de desempeñar mi labor profesionalmente, debido en gran parte a su desarrollo en el que se establecen unos requisitos y he buscado la solución más apropiada para cada uno de ellos, afrontando varios problemas como puede ser el desconocimiento sobre un área y siendo necesaria la formación autodidacta. Es por ello que me siento orgulloso de haber afrontado y resuelto cada uno de los objetivos establecidos, de haber escogido esta magnífica carrera en la que no se deja de aprender y de ser parte de esta gran área de la ciencia en la que somos capaces de imaginar y desarrollar sistemas capaces de buscar soluciones a las necesidades de las personas y facilitar nuestro día a día. 135 ANEXOS 137 Anexo A Fundamentos sobre tecnologías de localización De manera genérica, un sistema de localización en interiores consiste en un conjunto de estaciones fijas y unos dispositivos inalámbricos asociados a las personas que se desean seguir. A la hora de tener diseñar el sistema se ha de tener en cuenta que debe ser usado por cualquiera, ha de basarse en tecnologías estándares, que se encuentren disponibles a bajo coste en el mercado, al igual que lo referente a la parte de instalar en el recinto el sistema que vaya a implantarse, atendiendo a los costes de implantación y mantenimiento, fundamentales para la posible expansión del sistema. Atendiendo a las consideraciones expuestas y antes de realizar la elección entre las diferentes opciones disponibles para la localización en interiores, es necesario considerar las características que debe satisfacer el sistema: Disponibilidad: Posibilidad de que el sistema, ante una solicitud de localización, consiga una señal precisa para cumplir sus objetivos. Precisión: Dispersión del conjunto de valores obtenidos de mediciones repetidas de una magnitud, es decir, lo cerca que los valores medidos están unos de otros. La precisión puede variar significativamente en función de la aplicación que se pretende implementar, pudiendo variar de centímetros a metros. Latencia: En términos de ingeniería se entiende como el tiempo entre una acción y el resultado de la misma, en este caso, tiempo que pasa desde que un dispositivo se mueve en la realidad, hasta que el sistema reconoce ese movimiento y lo representa en la interfaz de la aplicación. Respuesta en tiempo real: Tiempo mínimo que pasa entre que se realiza una lectura de una posición y la siguiente. Conforme aumente la precisión, también ha de elevarse la frecuencia de actualización y por tanto aumentar la tasa de muestreo. Comunicación: La comunicación entre dispositivo y sistema de localización puede ser unidireccional o bidireccional. En este caso se trata de comunicación unidireccional, ya que el dispositivo inalámbrico será el encargado de enviar información al sistema, y éste tendrá que ser capaz procesar la información para determinar de qué dispositivo 139 se trata y la posición que ocupa. Otra de las consideraciones, más importantes a la hora de diseñar el sistema son los componentes hardware, específicamente los nodos de referencia del sistema que permiten saber la posición del nodo móvil, que se tratará del usuario. Esta elección marcará el diseño del resto del sistema y para ello se han tenido en cuenta varias características que el sistema debe poseer: Bajo coste: A la hora de implantar un sistema con una posible salida al mercado es necesario escoger unos componentes hardware que no impliquen realizar un desembolso importante. Por lo tanto el precio de los mismo y la instalación no deberían suponer un obstáculo para la implantación del sistema de localización y guiado. Fácilmente accesible: Por la misma razón que el punto anterior, la tecnología escogida ha de ser fácilmente adquirible en el mercado, de manera que el acceso a la tecnología no suponga un problema a la hora de implantarse o mantenerse, bien sea por averías o por un aumento en tamaño de la superficie comercial y por tanto el tamaño de la red de nodos fijos del sistema. Estándares: Ya que esáa orientado hacia la mayor implantación posible, es necesario basarse en estándares reconocidos, que faciliten el diseño y desarrollo del sistema. Compatibilidad: Por último y no menos importante, otra característica a tener en cuenta es la compatibilidad en la comunicación de señales entre distintos tipos de nodos de referencia y móviles. Decantándose por aquella que ofrezca más opciones y facilidades, ya que supondrá un mejor resultado en la implantación del sistema. A continuación se detallan las diferentes alternativas tecnológicas consideradas, para la implantación de sistemas de localización en interiores: A.1 Wi-Fi La creciente disponibilidad de dispositivos móviles así como la presencia masiva de redes inalámbricas WiFi, capaces de soportar la localización de éstos, han aumentado en forma significativa el interés del posicionamiento indoor a partir de la infraestructura de estas redes, que permiten que, las aplicaciones basadas en posición en entornos de área local resulten viables. La infraestructura de estas redes cubre zonas de hasta 75 metros en el interior de edificios. Encontrandose Implementadas en un grupo de estándares (Tabla A.1), denominado IEEE 802.11, que comprende varias tipos. La clase más popular es la denominada 802.11b, ampliamente superada por el estándar 802.11a restringida al uso militar en España. donde: 140 Estándar Velocidad Máxima 802.11b 802.11a 802.11g HomeRF2 HiperLAN2 11Mbps 54Mbps 54Mbps 10Mbps 54Mbps Interfaz de aire Ancho de Banda de canal DSSS OFDM OFDM/DSSS FHSS OFHDM 25MHz 25MHz 25MHz 5MHz 25MHz Frecuencia 2.4GHz 5GHz 2.4GHz 2.4GHz 5GHz Tabla A.1: Estándares de Wireless LAN. Figura extraida de [UPM]. DSSS:Direct Sequence Spread Spectrum. OFDM:Orthogonal Frequency Division Multiplexing. FHSS:Frequency Hopping Spread Spectrum. En contra del uso de esta infraestructura, se ecuentran tales como la vulnerabilidad a las interferencias, su señal es afectada por obstáculos móviles que absorben parte de su energía, reflexiones y dispersión. Ambas afectan directamente a la precisión. A pesar de estos contras este sistema no requiere hardware adicional, ya que todos los teléfonos actuales tienen dicha tecnología incorporada. A.2 Bluetooth Aunque en un principio la tecnología Bluetooth no fue pensada como una tecnología de localización, debido a la reciente llegada de la tecnología BTLE(Bluetooth Low Energy) es posible implementar un sistema para calcular la posición de un dispositivo. La tecnología BTLE permite interactuar en un radio de acción de 70 metros con balizas con una precisión de hasta dos metros si procesa medidas de cuatro o más balizas y cuya batería pueda tener una autonomía de hasta 2 años, debido a un consumo de energía relativamente bajo y que por tanto permite colocarlas en puntos fijos sin necesidad de preocuparse por ellas. Esta tecnología utiliza una red de tipo malla colocando las distintas balizas distanciadas unas de otras, normalmente cada 10 ó 15 metros, con el fin de cubrir las distintas zonas que se quiere monitorizar. La manera de actuar del usuario sería escanear el área en búsqueda balizas previamente localizadas y calcular su posición mediante la potencia recibida. Otra ventaja es que todos los teléfonos vienen también con dicha tecnología disponible. Actualmente, existen varias empresas que desarrollan soluciones de localización basadas en Bluetooth como pueden ser Tadlys, BlueLon, Blueposition, etc. Las aplicaciones van dirigidas a proveer localización o grabar rutas, servicios útiles en hospitales, centros de trabajo, colegios, servicios comerciales, etc. 141 A.3 UWB UWB emplea ráfagas de potencia más baja que cualquier otra de las tecnologías mencionadas con una frecuencia amplia (3,1-10,6GHz) y velocidades de transferencia de datos mucho mayores que las tecnologías mencionadas llegando a transferir datos a velocidades de centenares de megabytes por segundo. Esta tecnología está basada en pulsos ultracortos, calculando la distancia al móvil mediante el retardo de un pulso desde que es emitido por el transmisor hasta que llega al receptor permitiendo localizar el terminal móvil con un error mínimo. Debido a su baja complejidad, coste reducido y a la capacidad para solucionar los problemas de precisión y seguridad que caracteriza a la red Wi-Fi, es una tecnología a considerar. Como ejemplo comercial, la empresa Parco PAL que ofrece servicios de localización basados en UWB, para seguimiento de objetos en hospitales. Su bajo nivel de potencia evita las interferencias con equipos médicos y proporciona localización muy precisa. [?] La Tabla A.2 muestra una tabla comparativa en la que se puede observar como UWB tiene una capacidad muy superior al resto, con una potencia de emisión insignificante, pero está limitada en alcance. Tecnología Tasa de datos (Mb/s) Bluetooth IrDA UWB IEEE 802.11a IEEE 802.11b IEEE 802.11g 1-2 4 100-500 54 11 54 Potencia (mW) 100 100 1 40-800 200 65 Alcance(m) 100 1-2 10 20 100 50 Frecuencia 2.4GHz Infrarrojo 3.1-2.6GHz 5GHz 2.4GHz 2.4GHz Tabla A.2: Tabla Comparativa tecnologías UWB. Tabla extraída de [UPM] A.4 ZigBee La tecnología ZigBee está basada en el estándar IEEE 802.15.4, estándar que define el nivel físico y el control de acceso al medio de redes inalámbricas de área personal. Es una tecnología diseñada para ser el estándar de comunicación de las redes inalámbricas de sensores como se puede observar en la Figura A.1 , presentando tres principios básicos de trabajo: low cost, low power y low data rate. Diversos trabajos realizados en la actualidad con esta tecnología ponen en evidencia la viabilidad y opciones que presenta esta tecnología para la localización en interiores, debido principalmente a su bajo coste y baja potencia de emisión. Sin embargo, presenta grandes limitaciones de utilidad para aplicaciones donde sea necesario un cierto volumen de transmisión de datos debido a su limitada tasa de bit. A mayores, 142 Figura A.1: Red de sensores con tecnología ZigBee se producen fluctuaciones de la señal debido a la configuración del entorno o el movimiento de personal, que se ven reflejadas en pérdida de precisión. A.5 RFID El sistema RFID (Radio Frequency Identification) se basa en etiquetas de radiofrecuencia que permiten la identificación a distancia de una objeto o persona. Esta tecnología esta formada por tres componentes: etiquetas que contienen un transpondedor con un chip digital de memoria para comunicarse con los receptores. Los receptores, están formados por una antena encargada de activar la etiqueta y leer los datos almacenados, incluso escribir en la memoria y el sistema central de control. Las etiquetas pueden ser de dos tipos: Pasivas: No poseen ninguna batería, sino un circuito que se activa al recibir la potencia emitida por un receptor. Con esta potencia es capaz de transmitir los datos almacenados en la memoria. Su coste, tamaño y su alcance es bajo, entre decenas de centímetros y algunos metros. Se emplean para reemplazar el sistema de código de barras tradicional. Activas: Poseen una batería que le permite transmitir sus datos de manera autosuficiente. Su memoria, tamaño, coste y alcance es mayor, pasando de algunos metros hasta a decenas de metros. 143 Una etiqueta activa de altas prestaciones combinado con un lector de las mismas prestaciones ofrece hasta 70 metros de alcance, una frecuencia de 100 etiquetas/seg, una memoria de 32KB y una duración de la batería en el mejor de los casos de 5 años, que varía significativamente en función de la frecuencia. Se emplean en la identificación de productos en movimiento como pueden ser palés. En nuestro caso para aplicaciones de localización en interiores, las etiquetas más adecuadas disponibles hoy en día son las activas, principalemten por su mayor rango de lectura. Se recominenda utilizar esta tecnología en una estructura de malla colocando etiquetas RFID de referencia por metro cuadrado, de manera que se consiga una precisión de 1 a 2 metros y se consiga reducir los errores inducidos por la presencia de obstáculos o cuerpos en movimiento. Los principales problemas a los que un desarrollador se enfrenta al usar esta tecnología son: La frecuencia a la que se pueden recibir los datos es muy limitada, para evitar la posibilidad de colisión. Hay variabilidad entre distintas etiquetas, ya que dos etiquetas no emiten en las mismas condiciones la misma potencia, por lo que implica hacer una clasificación previa por potencia. Algunos materiales, como el metal, no son los más adecuados para soportar una etiqueta y actualmente existen productos que no pueden ser envasados de otra forma. Sin embargo la localización mediante RFID no es viable debido a la necesidad de un lector apropiado y a la tecnología NFC cuyo uso es similar y se esta extendiendo no solo en los Smartphones sino en las funcionalidades llendo mas allá del almacenamiento en el uso de mecanismos de control de apertura en productos ligados con la tecnología, gestión de almacén, pago de peajes, control de acceso, etc. La tecnología es madura y el coste de desarrollo e implantación va disminuyendo progresivamente, sin embargo, no dejan de ser aplicaciones de logística y distribución. Hay multitud de empresas que ofrecen y desarrollan soluciones empleando etiquetas RFID: Alien Technologies, Matrics, Deisler Electronics, RFID Inc., AWID, IDENTEC Solutions. . . A.6 Justificación de alternativa seleccionada Tras el análisis de diversas tecnologías, se consideran poderosas alternativas a tener en cuenta en la elección de la tecnología de RF utilizada en ShoppingBeacon los siguientes 4 estándares: UWB (IEEE 802.15.3), ZigBee (IEEE 802.15.4), WiFi (IEEE 802.11.a/b/g) y Bluetooth (IEEE 802.15.1). A continuación se muestra en la Tabla A.3 un resumen de cada una de las tecnologías consideradas para su uso en el desarrollo del presente Trabajo Fin de Grado. 144 145 Estándar \ Caracteristicas Banda de frecuencia Máxima tasa de señal Alcance nominal Potencia nominal de TX Número de canales RF soportados Ancho de Banda de canal 3.1 - 10.6 GHz 110 Mb/s 10 m -41.3 dBm/MHz 1-15 500 MHz - 7.5 GHz 2.4 GHz 1 Mb/s 10 m -10 - 0 dBm 79 1 MHz 0.3/0.6 MHz; 2 MHz 2.4 GHz 250 Kb/s 10-100 m (-25) - 0 dBm 1-10 ; 16 ZigBee Tabla A.3: Comparativa de tecnologías de RF. UWB Bluetooth 22 MHz 2.4GHz; 5GHz 54 Mb/s 100 m 15 - 20 dBm 14 WiFi Como se observa en la Tabla A.3, Bluetooth y ZigBee están principalmente pensados para dispositivos portátiles con alcances relativamente cortos y bajo consumo. En el caso de UWB esta diseñado para tasas elevadas de transmisión de datos a corto alcance, lo que supone un mayor consumo energético. De la misma manera WiFi, implica una conexión y transmisión de datos por lo que estos dispositivos están provistos de fuentes de alimentación. A continuación, la Figura A.3 [Gra] muestra una comparativa de consumo energético referido a la tasa de bit (1 MB/s) Figura A.2: Gráfica de consumo de potencia de tecnologías RF Finalmente, en la Figura A.4 se expone una comparación de tecnologías en lo referente al coste de dispositivos y complejidad para aplicar las tecnologías citadas a la localización en interiores. Tras realizar un análisis de las diferentes tecnologías hasta el momento, se ha optado por el estándar Bluetooh como una tecnología con tasa de bit, alcance, potencias de operación, arquitectura, relación coste/complejidad, rapidez de despliegue, simplicidad de uso, fiabilidad, seguridad y duración de la batería totalmente aceptables y factibles para la ejecución del presente Trabajo Fin de Grado. Como balizas Bluetooth se han utilizado tres dispositivos propiedad de Estimote. Transmisores de bajo consumo capaces de localizar a dispositivos iOS por proximidad, permitiendo el envío de notificaciones push entre dispositivos. Hay multitud de balizas bluetooth, sin embargo se ha optado por la elección de estos transmisores debido en gran medida a las siguientes razones: SDK: Se trata de un conjunto de herramientas de desarrollo de software que permite 146 Figura A.3: Gráfica de coste/complejidad de tecnologías RF para localización en interiores al desarrollador de software crear aplicaciones para el sistemas de los iBeacon. Una baliza para muchas apps: Las balizas iBeacon puedan ser leídas e interpretadas no sólo por una app corporativa de tienda sino por software de terceros. Por ejemplo, un comercio puede desarrollar su propia app compatible con iBeacons desplegados en tienda y al mismo tiempo confiar los identificadores de dichas balizas a un tercero, como Google con su software Google Maps. Compatibilidad de iBeacon con dispositivos Android: Las balizas iBeacon pueden ser leídas por un sistema operativo Android. 147 Anexo B Calibración del dispositivo iBeacon Los beacons suelen venir calibrados de fábrica, sin embargo nunca está de más realizar una prueba inicial y comprobar la potencia de emisión de éstos. Cada uno de los beacon de Estimote, a través de su SDK, aparte de los valores estándares de CLBeacon de Core Location ofrece una propiedad más: measured power. Esta propiedad indica la potencia en dBs que se debería obtener si se pone a un metro del beacon. Otra propiedad que ya se ha nombrado y con la que se trabaja para estimar la posición del usuario, es el valor rssi, que corresponde al valor de la potencia de la señal recibida por el dispositivo desde el que se están monitorizando los beacon, un iPhone en este caso. Por tanto, si se pone a un metro del beacon, el valor rssi y el valor measuredPower deben ser similares como muestra la Figura B.1 Figura B.1: Calibración de un dispositvo iBeacon 149 Al igual que se ha hecho en el resto de las pruebas, se deben almacenar un conjunto de muestras para realizar una media del conjunto, ya que dependiendo de las interferencias que se puedan dar en el momento de la calibración, puede fluctuar bastante. Apple [App14b] recomienda almacenar muestras del valor rssi durante 20 segundos (iOS hace lecturas a 1Hz, es decir, una lectura por segundo) y calcular la media sobre el percentil 80 de los valores almacenados. Aunque en el resto de pruebas se han tomado 30 medidas del valor rssi, que suponen algo más de 30 segundos debido a la pérdida de alguna señal, en este caso se ha optado por tomar valores durante 20 segundos y realizar una media sobree el percentil 80 como recomienda Apple. // Measured power is an average of the mid-80th percentile of RSSI samples. NSInteger balancedRSSI = 0; NSUInteger outlierPadding = allBeacons.count * 0.1f; [allBeacons sortUsingDescriptors:@[[NSSortDescriptor sortDescriptorWithKey:@"rssi" ascending:YES ]]]; NSArray *sample = [allBeacons subarrayWithRange:NSMakeRange(outlierPadding, allBeacons.count - ( outlierPadding * 2))]; balancedRSSI = [[sample valueForKeyPath:@"@avg.rssi"] integerValue]; Listado B.1: Calibración iBeacon. Listado Extraído de [App14a] Las lecturas de rssi se almacenan en la propiedad allBeacons y posteriormente se realizan los cálculos necesario para obtener el valor rssi válido para la calibración del beacon. Una vez obtenida el valor medio del rssi, se debe ajustar la potencia de emisión para que los valores rssi (el valor balancedRSSI del código de arriba) y measuredPower sean los más similares posibles. Para ello se hace uso del SDK de Estimote que permite conectarse al beacon que se desea calibrar a través de Bluetooth para modificar la potencia de transmisión mediante el método writeBeaconPower:withCompletion: de la clase ESTBeacon del SDK de Estimote, y de esa manera el valor rssi y el valor measuredPower sean lo más similares posible. 150 Anexo C Contenido del soporte fisico adjunto El soporte físico adjunto contiene el producto software final resultante del proceso de desarrollo del presente Trabajo Fin de Grado, su código fuente y su documentación, correspondiente al presente documento en versión digital. Todos estos recursos se hallan distribuidos en el CD adjunto a este documento. La estructura de directorios que el CD alberga es la siguiente: Código fuente del producto final Contiene el código fuente del producto final, de acuerdo a su jerarquía de directorios junto con las bibliotecas necesarias para su compilación (excepto aquellas directamente dependientes de iOS que deben encontrarse instaladas en el sistema). Se incluyen también todos los demás archivos necesarios para el proceso de compilación: imágenes y base de datos externa. Código fuente de las App para realizar pruebas Contiene el código fuente necesario de la App para realizar las pruebas, de acuerdo a su jerarquía de directorios junto con las bibliotecas necesarias para su compilación (excepto aquellas directamente dependientes de iOS que deben encontrarse instaladas en el sistema). Se incluyen también todos los demás archivos necesarios para el proceso de compilación: imágenes y base de datos externa. Documentación Contiene la documentación perteneciente al presente documento en versión digital. 151 Referencias [AH11] Gaurav S. Sukhatme. Andrew Howard, Sajid Siddiqi. An experimental study of localization using wireless ethernet. http://www. springerlink.com/content/mu1333820763207h/, Dic 2011. [AMB10] Paula Tarrío Ana M. Bernardos, José R. Casar. Real time calibration for rss indoor positioning systems. International Conference on Indoor Positioning and Indoor Navigation, Sep 2010. [Ann] App Annie. ios app store revenue 2.6x that of google play. blog.appannie.com/app-annie-index-market-q1-2013/. [App] Apple. Documentation class clbeacon. https://developer.apple.com/ http:// library/prerelease/ios/documentation/CoreLocation/Reference/ CLBeacon class/index.html#//apple ref/occ/instp/CLBeacon/ accuracy. [App14a] Apple. Airlocate: Using corelocation to monitor, range, and configure your device as an ibeacon. https://developer.apple.com/library/ ios/samplecode/AirLocate/Introduction/Intro.html, 2014. [App14b] Apple. Getting started with ibeacon. https://developer.apple.com/ ibeacon/Getting-Started-with-iBeacon.pdf, June 2014. [Bec99] Kent Beck. Embracing change with extreme programming. Computer, 23, Oct 1999. [Blu] B. sig,company identifiers. https://www.bluetooth.org/en-us/ specification/assigned-numbers/company-identifiers. [BP00] Paramvir Bahl and Venkata N. Padmanabhan. RADAR: An inbuilding RF-based user location and tracking system, pages 775–784. INFOCOM, 2000. [CNE] CNET. Google y yahoo también se interesan en flipboard: reporte. http://www.cnet.com/es/noticias/google-yahoo-compra-flipboard/. 153 [CS] Hugo Pinto Pedro Mestre Carlos Serodio, Luıs Coutinho. A comparison of multiple algorithms for fingerprinting using ieee802.11. 6-8/06/2011. [DC11] Fang YiYuan. Deng Chen. Improved rssi indoor location system based on fuzzy algorithm. In Computer Science and Automation Engineering (CSAE), Jun 2011. [Des12] Rahul Desai. Nokia leads the way with indoor mapping. http://360. here.com/2012/07/16/nokia-leads-the-way-with-indoor-mapping/, 2012. [Fet13] John Fetto. Americans spend 58 a day on their smarthphones. http://www.experian.com/blogs/marketing-forward/2013/05/ 28/americans-spend-58-minutes-a-day-on-their-smartphones/ ?WT.srch=PR EMS smartphones 052813 press, May 2013. [Gho] C. B. T. C. Avik Ghose. Blueeye – a system for proximity detection using bluetooth on mobile phones. [Gra] F. S. Granja. Sistemas de localización en interiores basados en radiofrecuencia, instituto de automática industrial (csic). www.car. upm-csic.es/lopsi/static/publicaciones. [ide] ideup. desarrollador android vs desarrollador ios. http://www.ideup. com/blog/desarrollador-android-vs-desarrollador-ios. [Joh10] John Ray; Sean Johnson. Desarrollo de aplicaciones para iPhone. Anaya, 2010. [LHCGHCMHJW10] E.H. Lyu-Han Chen Gen-Huey Chen Ming-Hui Jin Wu. International conference on parallel processing workshops. In A Novel RSS-Based Indoor Positioning Algorithm Using Mobility Prediction., number 39, pages 549–553. ICPPW, Oct 2010. [Low14] Josh Lowensohn. San francisco airport testing beacon system for blind travelers. http://www.theverge.com/2014/7/31/5956265/ san-francisco-airport-testing-beacon-system-for-blind-travelers, July 2014. [Org] Bluetooth Org. Core specification - bluetooth. bluetooth.org/docman. 154 https://www. [SMI14] DAVE SMITH. ios continues to dominate android in web traffic read more: http://www.businessinsider.com/chart-ofthe-day-ios-continues-to-dominate-android-in-web-traffic2014-7ixzz3ja73bhks. http://www.businessinsider.com/ chart-of-the-day-ios-continues-to-dominate-android-in-web-traffic-2014-7, Julio 2014. [Sta15] Statista. Global smartphone shipments forecast from 2010 to 2019 (in million units). http://www.statista.com/statistics/263441/ global-smartphone-shipments-forecast/, 2015. [UPM] UPM. de la Tecnologías información. y servicios para la sociedad http://www.upm.es/sfs/Rectorado/ Organos%20de%20Gobierno/Consejo%20Social/Actividades/ tecnologias servicios para sociedad informacion.pdf. [Xat13a] Xataka. Google maps se renueva en android (y en ios, y en versión web). http://www.xatakandroid.com/aplicaciones-android/ google-maps-se-renueva-en-android-y-en-ios-y-en-version-web, Mayo 2013. [Xat13b] Xataka. Twitter music ya está disponible, pero sólo para ios y determinados países. http://www.xatakamovil.com/aplicaciones/ twitter-music-ya-esta-disponible-pero-solo-para-ios-y-determinados-paises Abril 2013. [Xat13c] Xataka. ¿dónde está twitter music para android? http://www.xatakandroid.com/aplicaciones-android/ donde-esta-twitter-music-para-android, Abril 2013. [Xatil] Xataka. Vine llegará a android ’pronto’. http://www.xatakamovil.com/ aplicaciones/vine-llegara-a-android-pronto, 27 Abril. [You14] David mes. G. Young. Background beacon detection ti- http://developer.radiusnetworks.com/2014/03/12/ ios7-1-background-detection-times.html, 155 Marzo 2014. Este documento fue editado y tipografiado con LATEX empleando la clase esi-tfg que se puede encontrar en: https://bitbucket.org/arco group/esi-tfg [Respeta esta atribución al autor] 157
