Look!

: Framework para Aplicaciones de Realidad Aumentada en Android

Proyecto de Sistemas Informticos a 2010/2011

Facultad de Informtica a Universidad Complutense de Madrid Sergio Belln Alcarazo o Jorge Creixell Rojo Angel Serrano Laguna

Dirigido por Jorge J. Gmez Sanz o

 Nosotros, Sergio Belln Alcarazo, Jorge Creixell Rojo y Angel Serrano Laguo na, creadores del presente documento y del proyecto de Sistemas Informticos a Look!: Framework para Aplicaciones de Realidad Aumentada en Android, autorizamos a la Universidad Complutense a difundir y utilizar con nes acadmicos, e no comerciales y mencionando expresamente a sus autores, tanto la propia memoria, como el cdigo, la documentacin y/o el prototipo desarrollado. o o

Sergio Belln Alcarazo o DNI: 71224978-G

Jorge Creixell Rojo DNI: 54053166-S

Angel Serrano Laguna DNI: 06276034-R

Resumen Se presenta el framework de aplicaciones de realidad aumentada Look!, desarrollado para el sistema operativo mvil Android. Look! pretende aunar en un slo o o framework funcionalidades bsicas requeridas en el desarrollo de aplicaciones de a realidad aumentada. El framework se valida con cuatro desarrollos protot picos: una galer de a imgenes en 3D, un mundo virtual, un juego interactivo en tres dimensiones y a una aplicacin para la creacin de redes sociales con soporte para geolocalizao o cin. o Adicionalmente, se han escrito tutoriales que asistan al uso de este framework, y se ha documentado sucientemente su funcionamiento por si otros equipos quisieran continuar con este desarrollo. Palabras clave realidad aumentada, android, localizacin en interiores, frao mework, arquitectura rest, wi, navegacin inercial o

Abstract This document introduces the application framework for augmented reality Look!, developed for the mobile operating system Android. Look! provides basic functionalities required in the development of augmented reality applications. The framework is validated with four prototypic developments: a 3D image gallery, a virtual world, a 3D game, and a location-based social network. Additionally, tutorials assisting the development of applications through this framework have been written, and it is suciently documented in case this work was continued. Keywords augmented reality, android, indoor location, framework, rest architecture, wi, inertial navigation

 Indice general
1. Introduccin o 10 1.1. Realidad Aumentada . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.3. Estructura del Documento . . . . . . . . . . . . . . . . . . . . . . 12 2. Requisitos 13 2.1. Requisitos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1.1. Capas de Grcos en 2D y 3D . . . . . . . . . . . . . . . 13 a 2.1.2. Construccin de Entidades representables en Realidad Auo mentada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.3. Interaccin con los Objetos Virtuales . . . . . . . . . . . . 14 o 2.1.4. Localizacin en Interiores de Edicios . . . . . . . . . . . 14 o 2.1.5. Servicio de Persistencia de Datos . . . . . . . . . . . . . . 14 2.2. Requisitos No Funcionales . . . . . . . . . . . . . . . . . . . . . . 15 2.3. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3. Estado del Arte 3.1. Frameworks para realidad aumentada . . . . . . 3.1.1. Layar Reality Browser . . . . . . . . . . . 3.1.2. mixare . . . . . . . . . . . . . . . . . . . . 3.1.3. AndAR . . . . . . . . . . . . . . . . . . . 3.1.4. Conclusiones . . . . . . . . . . . . . . . . 3.2. Sistemas operativos . . . . . . . . . . . . . . . . . 3.2.1. Android . . . . . . . . . . . . . . . . . . . 3.2.2. iOS . . . . . . . . . . . . . . . . . . . . . 3.2.3. Tecnolog de escritorio ms webcam . . . a a 3.2.4. Tecnolog escogida . . . . . . . . . . . . a 3.3. OpenGL ES . . . . . . . . . . . . . . . . . . . . . 3.3.1. OpenGL ES 1.1 . . . . . . . . . . . . . . . 3.3.2. OpenGL ES 2.0 . . . . . . . . . . . . . . . 3.3.3. OpenGL ES 1.1 vs 2.0 . . . . . . . . . . . 3.4. Anlisis de Servicios Web . . . . . . . . . . . . . a 3.4.1. Arquitecturas ms comunes para Servicios a 3.4.2. Compatibilidad con Android . . . . . . . 3.4.3. Valoracin . . . . . . . . . . . . . . . . . . o 3.5. Anlisis de Proyectos de Localizacin . . . . . . . a o 3.5.1. PlaceLab . . . . . . . . . . . . . . . . . . 3.5.2. Ekahau . . . . . . . . . . . . . . . . . . . 16 16 17 18 18 19 19 20 21 21 22 22 22 23 23 23 24 24 26 26 26 29

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

3.5.3. Proyecto Indoor Navigation System for Handheld Devices 3.5.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . 3.6. Tcnicas de Localizacin en Interiores . . . . . . . . . . . . . . . e o 3.6.1. Localizacin mediante etiquetas RFID . . . . . . . . . . . o 3.6.2. Localizacin mediante marcas visibles . . . . . . . . . . . o 3.6.3. Localizacin mediante el Clculo del Punto Central a paro a tir de nodos predenidos . . . . . . . . . . . . . . . . . . . 3.6.4. Localizacin mediante Triangulacin de la Seal . . . . . o o n 3.6.5. Localizacin mediante Sistemas Inerciales . . . . . . . . . o 3.6.6. Localizacin mediante Deteccin de Movimiento . . . . . o o 3.6.7. Localizacin mediante Mapas de Radio WiFi . . . . . . . o 3.6.8. Localizacin mediante Mapas de Radio obtenidos Automtio a camente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Arquitectura Global 4.1. Mdulo de Localizacin . . . . . . . . . o o 4.2. Mdulo de Datos . . . . . . . . . . . . . o 4.3. Mdulo de Realidad Aumentada . . . . o 4.4. Uniendo los mdulos para la creacin de o o

30 32 32 33 33 34 35 36 37 38 39 40 41 41 42 42 43 45 45 45 46 46 47 47 51 51 52 53 57 59 60 63

. . . . . . . . . . . . . . . . . . . . . aplicaciones

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

5. Mdulo de localizacin o o 5.1. Orientacin del mvil en Android . . . . . . . . . . . o o 5.1.1. Pitch, azimuth y roll . . . . . . . . . . . . . . 5.1.2. Obteniendo la orientacin: DeviceOrientation o 5.2. Subsistema de Navegacin Inercial . . . . . . . . . . o 5.2.1. Diseo . . . . . . . . . . . . . . . . . . . . . . n 5.2.2. Arquitectura . . . . . . . . . . . . . . . . . . 5.2.3. Implementacin . . . . . . . . . . . . . . . . . o 5.3. Subsistema de Localizacin por WiFi . . . . . . . . . o 5.3.1. Requisitos . . . . . . . . . . . . . . . . . . . . 5.3.2. Diseo . . . . . . . . . . . . . . . . . . . . . . n 5.3.3. Arquitectura . . . . . . . . . . . . . . . . . . 5.3.4. Implementacin . . . . . . . . . . . . . . . . . o 5.3.5. Pruebas . . . . . . . . . . . . . . . . . . . . . 5.4. Integracin de los subsistemas de Localizacin . . . . o o

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

6. Mdulo de datos o 65 6.1. EntityData como unidad bsica de datos . . . . . . . . . . . . . . 65 a 6.2. Conectando los datos con el mdulo de realidad aumentada: Muno do y Entidades del mundo . . . . . . . . . . . . . . . . . . . . . . 67 6.2.1. World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.2.2. WorldEntity . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.2.3. Actualizando el mundo . . . . . . . . . . . . . . . . . . . 69 6.3. Obteniendo y almacenando datos: DataHandler . . . . . . . . . . 69 6.3.1. Obtencin de datos sin persistencia . . . . . . . . . . . . . 70 o 6.3.2. Obtencin de datos con persistencia local . . . . . . . . . 71 o 6.3.3. Obtencin de datos con persistencia remota . . . . . . . . 74 o 6.4. Otras fuentes de datos: Archivos binarios . . . . . . . . . . . . . 84 6.4.1. Administrador de archivos . . . . . . . . . . . . . . . . . . 85

6.4.2. Optimizaciones del administrador de cheros . . . . . . .

86

7. Mdulo de Realidad Aumentada o 87 7.1. Visin general del sistema de capas: LookAR . . . . . . . . . . . 87 o 7.2. Capa 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 7.2.1. Consideraciones con OpenGL ES 1.1 . . . . . . . . . . . . 90 7.2.2. Proyeccin de elementos de coordenadas reales a coordeo nadas OpenGL . . . . . . . . . . . . . . . . . . . . . . . . 90 7.2.3. Situacin de la cmara . . . . . . . . . . . . . . . . . . . . 90 o a 7.2.4. Caracter sticas OpenGL soportadas por Look! . . . . . . . 91 7.2.5. Dibujado de entidades: Entity3D . . . . . . . . . . . . . . 91 7.2.6. ObjMesh3D: cargando mallas desde archivos .obj Wavefront 92 7.2.7. Creacin de texturas: TextureFactory . . . . . . . . . . . 93 o 7.2.8. Funcionalidades geomtricas y colisiones . . . . . . . . . . 94 e 7.3. Integrando cmara y 3D . . . . . . . . . . . . . . . . . . . . . . . 95 a 7.4. Capa 2D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 7.4.1. Canvas vs Proyeccin Ortogonal en OpenGL . . . . . . . 97 o 7.4.2. SurfaceView vs. View personalizada . . . . . . . . . . . . 97 7.4.3. Dibujado 2D . . . . . . . . . . . . . . . . . . . . . . . . . 98 7.5. Animaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 7.6. Interaccin del usuario . . . . . . . . . . . . . . . . . . . . . . . 100 o 7.6.1. Interaccin por teclado . . . . . . . . . . . . . . . . . . . . 100 o 7.6.2. Interaccin tctil . . . . . . . . . . . . . . . . . . . . . . . 100 o a 7.6.3. Interacciones de cmara . . . . . . . . . . . . . . . . . . . 101 a 7.6.4. HUD en 2D . . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.7. Capa HUD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.8. Utilidades: LookARUtil . . . . . . . . . . . . . . . . . . . . . . . 104 8. Construyendo aplicaciones con Look! 8.1. Planteando la aplicacin . . . . . . . . . . . . . . . . . . . . . . . o 8.2. Codicando una aplicacin bsica . . . . . . . . . . . . . . . . . . o a 8.2.1. Creando la Activity principal . . . . . . . . . . . . . . . . 8.2.2. Deniendo los elementos de la aplicacin: EntityData . . o 8.2.3. Deniendo factor de elementos . . . . . . . . . . . . . . as 8.2.4. Aadiendo interacciones . . . . . . . . . . . . . . . . . . . n 8.2.5. Aadiendo un HUD a la aplicacin . . . . . . . . . . . . . n o 8.2.6. Congurando una base de datos . . . . . . . . . . . . . . 8.3. Preparando el Sistema de Localizacin . . . . . . . . . . . . . . . o 8.3.1. Denicin de Nodos y Puntos de Acceso . . . . . . . . . . o 8.3.2. Captura de Datos . . . . . . . . . . . . . . . . . . . . . . 8.3.3. Probando la Localizacin por Wi . . . . . . . . . . . . . o 8.3.4. Ajuste de Parmetros del Sistema de Navegacin Inercial a o 8.4. Integrando localizacin . . . . . . . . . . . . . . . . . . . . . . . . o 9. Experimentacin: Aplicaciones de ejemplo desarrolladas o Look! 9.1. Mundo 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.1.1. Mdulos incorporados . . . . . . . . . . . . . . . . . . o 9.1.2. Denicin de los EntityData . . . . . . . . . . . . . . o 9.1.3. Factor de WorldEntity . . . . . . . . . . . . . . . . . a 105 105 106 106 107 108 111 113 115 116 117 118 120 120 120

con 122 . . 122 . . 123 . . 123 . . 124

9.1.4. Interacciones . . . . . . . . . 9.1.5. Localizacin . . . . . . . . . . o 9.2. Galer Look! . . . . . . . . . . . . . a 9.2.1. Mdulos incorporados . . . . o 9.2.2. Denicin de los EntityData o 9.2.3. Factor de WorldEntity . . . a 9.2.4. Interacciones . . . . . . . . . 9.3. Invaders 360 . . . . . . . . . . . . . . 9.3.1. Mdulos incorporados . . . . o 9.3.2. Denicin de los EntityData o 9.3.3. Factor de WorldEntity . . . a 9.3.4. Interacciones . . . . . . . . . 9.4. Look! Social . . . . . . . . . . . . . . 9.4.1. Descripcin . . . . . . . . . . o 9.4.2. Mdulos incorporados . . . . o 9.4.3. Denicin de los EntityData o 9.4.4. Factor de WorldEntity . . . a 9.4.5. Interacciones . . . . . . . . . 9.4.6. Localizacin . . . . . . . . . . o 9.4.7. Datos remotos . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

124 125 126 126 126 128 129 129 130 130 131 132 132 133 135 135 136 136 137 137 139 139 140 141

10.Apuntes nales 10.1. Problemas encontrados durante el proyecto . . . . . . . . . . . . 10.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A. Sistema de Navegacin Inercial mediante el o plazamiento Relativo A.1. Introduccin . . . . . . . . . . . . . . . . . . . o A.2. Descripcin . . . . . . . . . . . . . . . . . . . o A.2.1. Frmulas . . . . . . . . . . . . . . . . o A.2.2. Eliminacin del efecto de la gravedad o A.2.3. Transformacin de Coordenadas . . . o A.3. Implementacin . . . . . . . . . . . . . . . . . o A.4. Resultados . . . . . . . . . . . . . . . . . . . . A.5. Precisin de acelermetros . . . . . . . . . . . o o

Clculo del Desa 145 . . . . . . . . . . . 145 . . . . . . . . . . . 145 . . . . . . . . . . . 146 . . . . . . . . . . . 146 . . . . . . . . . . . 147 . . . . . . . . . . . 148 . . . . . . . . . . . 148 . . . . . . . . . . . 149

B. Acceso a la API CoreWLAN de Mac OS X desde Java mediante JNI 150 B.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 o B.2. Pasos Necesarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 B.2.1. Creacin del chero de cabecera . . . . . . . . . . . . . . 151 o B.2.2. Mezclando cdigo C y Objective-C . . . . . . . . . . . . . 152 o B.2.3. Accediendo a CoreWLAN . . . . . . . . . . . . . . . . . . 153 B.2.4. Implementacin de la Librer Nativa . . . . . . . . . . . 155 o a B.2.5. Resultado y Conclusin . . . . . . . . . . . . . . . . . . . 158 o C. Exportando mallas .obj con Blender 159 C.1. Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 o C.2. Exportando mallas . . . . . . . . . . . . . . . . . . . . . . . . . . 159

 Indice de guras
1.1. Ejemplo de Realidad Aumentada . . . . . . . . . . . . . . . . . . 3.1. La aplicacin de realidad aumentada Layar . . . . . . . . . . o 3.2. Estrucutra de una aplicacion con mixare . . . . . . . . . . . . 3.3. Captura de mixare . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Esquema del funcionamiento de AndAR . . . . . . . . . . . . 3.5. Mercado Android entre 2009 y 2010 . . . . . . . . . . . . . . 3.6. PlaceLab Stumbler . . . . . . . . . . . . . . . . . . . . . . . . 3.7. PlaceLab Tracker . . . . . . . . . . . . . . . . . . . . . . . . . 3.8. Mapa de Radio resultado del procesado . . . . . . . . . . . . 3.9. Ejecucin de Indoor Navigation System for Handheld Devices o 3.10. Fluctuacin de la seal en redes WiFi . . . . . . . . . . . . . o n 4.1. 4.2. 4.3. 4.4. 4.5. Capas del Diagrama Diagrama Diagrama Diagrama con Look! . . . . . . . . . . . . . . . . . . . . 10 17 18 19 20 21 27 28 31 32 35 41 42 43 44 44 46 46 48 49 50 52 54 54 57 58 59 61 62 62 64 66 66

Desarrollo de Aplicaciones mediante Look . . . . . . . de Componentes de Localizacin . . . . . . . . . . . . o de Componentes del mdulo de datos . . . . . . . . . . o de Componentes de la Interfaz de Realidad Aumentada de componentes general para aplicaciones construidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1. Denicin de pitch, azimuth y roll . . . . . . . . . . . . . . . . o 5.2. Clase DeviceOrientation . . . . . . . . . . . . . . . . . . . . . . 5.3. Diagrama de Flujo: Sistema de Navegacion Inercial . . . . . . . 5.4. Diagrama de Clases INS . . . . . . . . . . . . . . . . . . . . . . 5.5. Diagrama de secuencia INS . . . . . . . . . . . . . . . . . . . . 5.6. Aplicacin de prueba para el subsistema de Navegacin Inercial o o 5.7. Esquema de la localizacion por WiFi . . . . . . . . . . . . . . . 5.8. Ejemplo de seleccion de Nodos . . . . . . . . . . . . . . . . . . 5.9. Red Neuronal Perceptron Multicapa . . . . . . . . . . . . . . . 5.10. Diagrama de clases de la localizacion por WiFi . . . . . . . . . 5.11. Diagrama de Secuencia Servicio Localizacion WiFi . . . . . . . 5.12. Artefactos Generados por el sistema de Localizacion WiFi . . . 5.13. Captura del programa de localizacion WiFi en funcionamiento 5.14. Nodos denidos piso . . . . . . . . . . . . . . . . . . . . . . . . 5.15. Integracin de los subsistemas de Localizacin . . . . . . . . . . o o

6.1. La clase EntityData . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Diagrama de Clases del Acceso a Datos . . . . . . . . . . . . . .

6.3. Diagrama de clases de LookData, World, WorldEntity y EntityData, con sus relaciones. . . . . . . . . . . . . . . . . . . . . . . . 6.4. Actualizacin del mundo . . . . . . . . . . . . . . . . . . . . . . . o 6.5. Relacin de DataHandler con EntityData . . . . . . . . . . . . . o 6.6. Implementacin de BasicDataHandler . . . . . . . . . . . . . . . o 6.7. Implementacin de DBDataHandler . . . . . . . . . . . . . . . . o 6.8. Entidad de tipo user usada en la aplicacin Look! Social . . . . . o 6.9. Diagrama de secuencia para el acceso de datos . . . . . . . . . . 6.10. Diagrama de secuencia para el almacenamiento de datos . . . . . 6.11. Implementacin de RemoteDataHandler . . . . . . . . . . . . . . o 6.12. Diagrama de secuencia de updateDB() . . . . . . . . . . . . . . . 6.13. Arquitectura del mdulo de datos en el servidor . . . . . . . . . . o

68 69 70 70 71 73 75 76 77 78 82

7.1. Situacin de capas de representacin en Look! . . . . . . . . . . . 88 o o 7.2. Diagrama de clases de los mdulos de Realidad Aumentada. . . 88 o 7.3. Relacin de GLSurfaceView con Renderer3D . . . . . . . . . . . 89 o 7.4. La clase Entity3D y sus componentes . . . . . . . . . . . . . . . . 92 7.5. Diagrama de secuencia del dibujado 3d . . . . . . . . . . . . . . . 93 7.6. Clase TextureFactory . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.7. Contenido del paquete es.ucm.look.ar.math.geom . . . . . . . . . 95 7.8. Contenido del paquete es.ucm.look.ar.math.collision . . . . . . . 96 7.9. Diagrama de secuencia del dibujado en dos dimensiones . . . . . 99 7.10. Apariencia de la aplicacin en modo normal. Existen cuatro eno tidades (cuatro imgenes) en cada una de las esquinas . . . . . . 102 a 7.11. Apariencia del buer tctil de la aplicacin anterior. Pueden verse a o las cuatro reas tctiles, cada una de un color distinto (distintos a a tonos de azul) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 7.12. Apariencia del buer tctil de la aplicacin anterior. Pueden verse a o las cuatro reas tctiles, cada una de un color distinto (distintos a a tonos de azul) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 8.1. 8.2. 8.3. 8.4. 8.5. 8.6. Captura de la aplicacin tras aadir un elemento . . . . . . . . . o n Captura de la aplicacin con la nueva factor . . . . . . . . . . . o a La interfaz TouchListener . . . . . . . . . . . . . . . . . . . . . . Captura de la aplicacin tras pulsar uno de los elementos . . . . o La interfaz CameraListener . . . . . . . . . . . . . . . . . . . . . Captura de la aplicacin mientras se enfoca directamente a uno o de los elementos. Puede apreciarse como su representacion 3D ha cambiado de un cubo a un plano. . . . . . . . . . . . . . . . . . . 8.7. Captura de la aplicacin con HUD. Podemos comprobar arriba a o la izquierda como se aadi el botn. . . . . . . . . . . . . . . . . n o o 8.8. Ejemplo de Denicin de Nodos . . . . . . . . . . . . . . . . . . . o 8.9. CCNWi: Deteccin automtica de Puntos de Acceso . . . . . . o a 8.10. CCNWi: Captura de Datos . . . . . . . . . . . . . . . . . . . . . 8.11. CCNWi: Probando la localizacin . . . . . . . . . . . . . . . . . o 9.1. 9.2. 9.3. 9.4. Captura Captura Captura Captura de de de de Mundo 3D . . Galer Look! a Galer Look!, a Invaders 360 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . con una imagen seleccionada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 110 111 112 112

114 115 117 118 119 119 123 127 127 130

9.5. Registro y login de usuario en Look!Social . . . . . . . . . . . . . 133 9.6. Pantalla principal de Look!Social con mens . . . . . . . . . . . . 134 u 9.7. Look!Social : Realidad Aumentada . . . . . . . . . . . . . . . . . . 134 A.1. Accediendo al mando de la Wii . . . . . . . . . . . . . . . . . . . 148 C.1. Creando una malla con Blender . . . . . . . . . . . . . . . . . . . 160 C.2. Creando una malla con Blender . . . . . . . . . . . . . . . . . . . 160 C.3. Exportando la malla a una archivo .obj . . . . . . . . . . . . . . 160

Cap tulo 1

Introduccin o
En la actualidad, las tecnolog mviles, y en concreto el mercado de los as o smartphones, se encuentran en su mayor momento de expansin. Estos nuevos o dispositivos traen nuevas formas de comunicacin entre personas, as como nueo vas formas de interaccin entre usuario y mquina. La posibilidad de llevar un o a smartphone en tu bolsillo a todas partes conectado a Internet da la oportunidad de ofrecer nuevos tipos de servicios: servicios basados en la localizacin o del usuario o en la informacin que proporcionan los sensores y otros elementos o hardware del dispositivo. En concreto, dentro de este nuevo campo de aplicaciones, estn empezando a popularizarse las aplicaciones de realidad aumentada. a Este proyecto analiza la problemtica del desarrollo de este tipo de aplicaciones a y ofrece una solucin a dichos problemas. o En este cap tulo se ofrece una visin general del concepto de Realidad Auo mentada, se describen los objetivos perseguidos en el desarrollo del proyecto Look! y se dene la estructura del presente documento.

1.1.

Realidad Aumentada

En el mundo de los dispositivos mviles se conoce por Realidad Aumentada o (en ingls augmented reality AR) a la tecnolog que permite la superpoe o a sicin, en tiempo real, de imgenes generadas por ordenador sobre imgenes o a a del mundo real. Estos datos superpuestos pueden ser tanto informacin relatio

Figura 1.1: Ejemplo de Realidad Aumentada

10

va a elementos reales que estn siendo visualizados, como datos independientes a asociados a referentes f sicos. En un entorno de este tipo, el usuario puede, adems, interactuar con los objetos virtuales permitiendo, por ejemplo, alterara los o aadir nuevos. En conclusin, se trata de incorporar informacin virtual al n o o mundo real de una manera tal que el usuario pueda llegar a pensar que forma parte de su realidad cotidiana. La Realidad Aumentada es una tecnolog que est experimentando un auge a a en los ultimos aos, quiz debido al abaratamiento de los telfonos inteligentes, n a e y que est llamada a revolucionar nuestras vidas y la forma en la que interaca tuamos con la realidad. Por ello, es un campo abierto y para el que an quedan u innidad de aplicaciones por descubrir. Algunos de los mbitos en los que es poa sible el empleo de Realidad Aumentada son: proyectos educativos (aplicaciones en museos, parques temticos exposiciones), medicina (asistencia al cirujano a o en tiempo real), entretenimiento (aplicacin en nuevos tipos de juegos), simulao cin (de vuelos o trayectos terrestres) servicios de emergencias (evacuaciones o o de edicios)[12, 13, 14, 15, 16]. La implementacin de un sistema de realidad aumentada conlleva la resoluo cin de una serie de problemas de cierta complejidad de entre los que destaca o la obtencin de la localizacin del usuario, el dibujado de las distintas capas o o grcas, la interaccin con los objetos virtuales o el acceso a servicios remotos. a o Una vez resueltos estos problemas, la implementacin de aplicaciones de realio dad aumentada se vuelve ms mecnica. Este proyecto ofrece una solucin a a a o dichos problemas.

1.2.

Objetivos

El objetivo del proyecto es crear un framework de realidad aumentada que resuelva los problemas comunes encontrados en el desarrollo de aplicaciones de este tipo. Adems de otros, se abordarn como principales los siguientes problemas: a a Localizacin en interiores: El problema de localizacin exterior est reo o a suelto en mayor o menor medida con la tecnolog GPS. Sin embargo, la a localizacin en interiores resulta imprescindible para el tipo de aplicaciones o que se desea construir y que proporcionan informacin adicional dentro o de edicios. Representacin grca: El framework pretende aportar funcionalidad o a suciente para permitir la representacin grca de elementos tanto en o a dos dimensiones como tres dimensiones. El objetivo es que el usuario del framework no deba programar los mecanismos de dibujado, sino slo proo porcionar al sistema los datos que deben ser dibujados. Interaccin con los objetos virtuales: El framework proveer un siso a tema de interaccin tctil con los objetos virtuales de forma que el prograo a mador de aplicaciones solo deba preocuparse de indicar el efecto producido por dicha interaccin. o Acceso a Servicios Remotos: Adicionalmente se pretende facilitar el acceso a servicios externos tales como bases de datos alojadas en servidores remotos. 11

Estos objetivos se validan con cuatro desarrollos experimentales: Galer de Imgenes en 3D: Galer de imgenes en tres dimensiones a a a a que permita interactuar con las mismas mediante realidad aumentada y que sirva adems como experimentacin sobre formas diferentes de visuaa o lizar imgenes, aprovechando las tres dimensiones, y ensayo con nuevas a formas de organizacin de contenidos. o Red Social con soporte para Localizacin: Se quiere con esta aplio cacin denir redes sociales que tengan sentido dentro de un edicio. En o concreto, se quiere ensayar formas de comunicacin donde la ubicacin del o o individuo sea relevante, asociando informacin geogrca a documentos y o a deniendo ltros que impiden o autorizan el acceso a los mismos, as como utilizar la informacin de localizacin para encontrar usuarios. o o Mundo Virtual: Mundo de realidad virtual en el que los usuarios pueden desplazarse por medio de la realidad aumentada e interactuar con los objetos virtuales. Juego interactivo: Un juego en el que se muestren las capacidades gra cas y de interaccin entre elementos, y que sirva para poner de maniesto o la introduccin de lgica de cmputo compleja (trayectorias, colisiones, o o o animaciones) entre los elementos de realidad aumentada.

1.3.

Estructura del Documento

La presente memoria se estructura de la siguiente forma: En primer lugar se plantean los requisitos del software a desarrollar y se hace un repaso sobre el estado actual del arte. A continuacin se presenta la arquitectura global del o sistema y se describe en detalle cada uno de los mdulos que la conforman. o Seguidamente se presenta un tutorial para el desarrollo de aplicaciones mediante el framework y se describe el desarrollo de cuatro aplicaciones utilizadas para validar la funcionalidad implementada. Finalmente se incluyen algunos apuntes nales y las conclusiones del trabajo.

12

Cap tulo 2

Requisitos
A la hora de desarrollar un framework de realidad aumentada es necesario especicar una serie de requisitos que sirvan de gu para las labores de diseo a n e implementacin. En el presente cap o tulo se dene en primer lugar la funcionalidad bsica a implementar en forma de requisitos funcionales, y se explica en a detalle cada uno de ellos. Seguidamente se denen una serie de requisitos no funcionales que aportan informacin extra a los requisitos funcionales. Finalmente o se presenta una serie de restricciones adicionales que se deben cumplir.

2.1.

Requisitos Funcionales

Se pretende desarrollar un framework que, con el objetivo de facilitar el desarrollo de aplicaciones de realidad aumentada, proporcione las siguientes funcionalidades: Dibujado de grcos en dos y tres dimensiones. a Construccin de Entidades representables en Realidad Aumentada. o Interaccin con los Objetos Virtuales. o Localizacin en Interiores de Edicios. o Servicio de Persistencia de Datos. A continuacin se describe en mayor detalle cada uno de los requisitos funo cionales.

2.1.1.

Capas de Grcos en 2D y 3D a

Para poder realizar aplicaciones atractivas y vistosas para el usuario, el framework denir herramientas para el dibujado de elementos en dos y tres dia mensiones. Denir objetos comunes en el dibujado, como textos y formas bsicas, y a a ofrecer herramientas para denir los estilos de dibujados, como colores y texa turas. Tambin proveer de funcionalidades geomtricas, para facilitar labores coe a e munes en el desarrollo de grcos: puntos, vectores, matrices, planos y rayos, y a todas las operaciones relacionadas. 13

2.1.2.

Construccin de Entidades representables en Realio dad Aumentada

A partir de una serie de datos caracter sticos sin procesar, debern poder a construirse entidades complejas, de distintos tipos, que puedan ser representadas en realidad aumentada. As la especicacin de los datos que servirn como base para la construccin , o a o de elementos, deber ser lo ms general posible, para permitir la denicin de a a o un mayor nmero de elementos. u A partir de los datos del elemento y su tipo, podrn deducirse cosas coa munes, cmo las representaciones grcas para el elemento, y las interacciones o a permitidas.

2.1.3.

Interaccin con los Objetos Virtuales o

El framework ofrecer procesamiento de eventos tctiles (tocar, arrastrar y a a soltar) y eventos de cmara sobre los elementos de realidad aumentada, propora cionando interfaces para que el programador pueda implementar las respuestas adecuadas a dichos eventos.

2.1.4.

Localizacin en Interiores de Edicios o

Se debe proporcionar un sistema mixto de localizacin en interiores formado o por los siguientes mdulos: o Sistema Primario de Localizacin por medio de seales Wi que proo n porcione una localizacin a intervalos de tiempo denidos1 . o Sistema Secundario de Localizacin basado en Navegacin Inero o cial que complemente el sistema primario de localizacin proporcionando o una posicin en base al movimiento relativo del dispositivo en el espacio. o Integracin de los Sistemas de Localizacin Primario y Secundario. o o Deber ser posible la utilizacin de cada uno de los sistemas de forma sepaa o rada y de ambos de manera combinada, siendo el programador de aplicaciones el encargado de decidir la funcionalidad necesaria para su aplicacin. o

2.1.5.

Servicio de Persistencia de Datos

Se debe proporcionar un servicio de persistencia de Datos que proporcione dos tipos de almacenamiento. Almacenamiento Local, que almacene los datos de la aplicacin durante o distintas ejecuciones o que funcione como una cach de datos para agilizar e las transacciones entre cliente y servidor. Almacenamiento Global donde se guarden los datos de todos los clientes de manera centralizada.
1 Tasa

de refresco denida en la seccin 2.3. o

14

El servicio de persistencia de datos permitir el desarrollo de aplicaciones a multiusuario por medio del acceso concurrente a datos comunes a todos los usuarios, de forma que compartan informacin y se permita la interaccin entre o o ellos.

2.2.

Requisitos No Funcionales

A continuacin se denen los requisitos no funcionales del framework de o realidad aumentada: Interaccin con el usuario por medio de interfaces tctiles. o a Funcionamiento en dispositivos Android versin 2.2 y superior. o No necesidad de Hardware externo al dispositivo. La persistencia deber realizarse en Base de Datos. a Se debe garantizar un funcionamiento correcto en al menos los siguientes dispositivos: Google Nexus One HTC Desire HD HTC Tattoo

2.3.

Restricciones

Las principales restricciones del proyecto son: Precisin de la localizacin en interiores: Precisin a nivel de habio o o tacin. o Tasa de refresco de datos de localizacin: Actualizaciones a intervalos o menores de 5 segundos para garantizar el funcionamiento en tiempo real. Rendimiento: Debe garantizarse uidez en el dibujado de los grcos a sobre la realidad (m nimo 15 fps) en un dispositivo con 528 MHz y 256 MB de RAM.

15

Cap tulo 3

Estado del Arte

Antes de empezar el desarrollo del framework de realidad aumentada se ha realizado un estudio sobre el estado del arte. Se pretende conocer un poco ms de cerca cmo ha sido abordado el tema, en qu estado se encuentra en el a o e momento de plantear el proyecto y cules son las tendencias, as como comprobar a si es posible aprovechar alguna de las tecnolog existentes. En este cap as tulo se presentan las tecnolog analizadas y se resumen las conclusiones de dicho as anlisis. a En primer lugar se realiza un anlisis de diferentes frameworks de realidad a aumentada actuales. Una vez demostrado que no satisfac los requisitos prean sentados en el cap tulo anterior, decidimos comenzar al desarrollo de nuestro framework. La siguiente decisin consist en elegir el sistema operativo en el que desao a rrollar el framework. En la seccin 3.2 se analizan los sistemas operativos mviles o o ms relevantes en la actualidad. a Dentro del desarrollo en s se plantearon diferentes caminos para acometer , la parte grca. El dibujado en dos dimensiones est resuelto de manera satisa a factoria para nuestras necesidades por Android. Sin embargo, la aproximacin o al dibujado en tres dimensiones planteaba dos soluciones bien diferenciadas sobre Android, basadas en dos versiones de OpenGL ES. La problemtica de la a eleccin de versin se trata en la seccin 3.3. o o o Tambin es necesario estudiar la integracin de la aplicacin con sistemas e o o remotos, para lo cual, Android plantea varias soluciones. En la seccin 3.4 se o estudian las distintas alternativas disponibles. Finalmente, una aplicacin de realidad aumentada necesita conocer la locao lizacin del usuario en interiores. En la seccin 3.5 se estudian distintas alternao o tivas tecnolgicas existentes, y en la seccin 3.6 diversas tcnicas de localizacin o o e o en interiores. Tras el anlisis de estos problemas, la seccin 3.7 recoge las conclusiones de a o todo lo presentado.

3.1.

Frameworks para realidad aumentada

Puesto que el espectro de aplicaciones abarcando las funcionalidades ofrecidas por Look! resulta bastante amplio, se han escogido las ms representativas y las a

16

que ms funcionalidades de Look! implementan. Dichas funcionalidades son las a siguientes: Sistema de localizacin en interiores. o Capa de representacin grca en 2 dimensiones. o a Capa de representacin grca en 3 dimensiones. o a Interaccin con objetos virtuales. o Integracin con servicios de persistencia remotos. o En la tabla 3.1 se compara la funcionalidad de cada uno de de los sistemas analizados, comprobando si poseen las siguientes caracter sticas: integracin con o cmara, grcos 2D y 3D; integracin y creacin de servicios de persistencia a a o o remotos; localizacin en exteriores e interiores; soporte para sistemas de naveo gacin inercial e interaccin con objetos virtuales. o o

3.1.1.

Layar Reality Browser

Layar 1 es una navegador de realidad aumentada, desarrollado para plataformas mviles como Android o iPhone (ver gura 3.1). Tiene una licencia o privativa por lo que no se dispone de acceso al cdigo fuente. o Est basado en un sistema de capas que funcionan sobre el navegador de a realidad aumentada base, y que el usuario puede decidir si mostrar o no. Cada una de estas capas es desarrollada independientemente por compa personas nas, a t tulo personal o programadores independientes, y representan mundos de realidad aumentada paralelos y disjuntos.

Figura 3.1: La aplicacin de realidad aumentada Layar o

1 http://www.layar.com/

17

Caracter sticas

Sus caracter sticas principales son:

Localizacin basada en GPS. o Capas en dos dimensiones Capas en tres dimensiones Estructura de cliente-servidor, permitiendo la descarga de datos de las capas denidas por los usuarios en tiempo real. Promocin de las capas: las capas denidas por el usuario pueden ser o puestas a disposicin de la comunidad de manera centralizada. o

3.1.2.

mixare

mixare (mix Augmented Reality Engine)2 es un framework de cdigo abierto o para realidad aumentada, publicada bajo la licencia GPLv3 3 . mixare est disa ponible para sistemas Android y para iPhone. Este framework permite construir aplicaciones completas y proporciona funciones para asociar puntos (coordenadas) y texto. Es decir, su funcionalidad se resume a permitir asociar texto a localizaciones (ver gura 3.3).

Figura 3.2: Estrucutra de una aplicacion con mixare

mixare ofrece capacidades de representacin en dos dimensiones limitadas a o cajas de texto e imgenes, localizacin por GPS, y acceso a datos por conexin a o o de red.

3.1.3.

AndAR

AndAR es una aplicacin que permite la representacin de objetos tridimeno o sionales sobre marcas f sicas en el mundo real. Consiste en un visor de elementos 3D, que son situados sobre marcas predeterminadas. Estos elementos se vern afectados por la orientacin y el punto de a o vista del usuario.
2 http://www.mixare.org/ 3 http://www.gnu.org/licenses/gpl-3.0.html

18

Figura 3.3: Captura de mixare

3.1.4.

Conclusiones

Se observa en la tabla 3.1 que AndAR y mixare ofrecen una funcionalidad muy pobre para nuestras necesidades. Layar es la opcin ms completa, pero no o a dispone de localizacin en interiores ni permite extender dicha funcionalidad por o lo que resulta inadecuado para nuestro proyecto. As optamos por desarrollar , el framework desde cero.

3.2.

Sistemas operativos

Para el desarrollo de software de realidad aumentada, son necesarias tecnolog que proporcionen las funcionalidades adecuadas. Se requiere tecnoas log con capacidad de localizacin, capacidad para mostrar imgenes desde as o a una cmara y APIs grcas en dos y tres dimensiones. Adems, es necesario a a a disponer de tecnolog de creacin de interfaces de usuario amigables y que as o provean elementos comunes y sucientemente conocidos (como ventanas, botones, cajas de texto, mens, listas, etc.). u Se pueden catalogar los smartphones actuales en funcin de su sistema opeo rativo. Los smartphones de altas prestaciones se encuentran dominados por dos sistemas operativos mayoritarios: iOS: Se encuentra en los smartphones y tabletas fabricados por Apple (iPhone, IPad ). De naturaleza cerrada, sus aplicaciones deben de ser aprobadas por Apple y estn sometidas a un conjunto de normas ms o menos a a estricto.

19

Figura 3.4: Esquema del funcionamiento de AndAR Aplicacin o Integracin con cmara o a 2D 3D Integracin con Servicios Remotos o Creacin de Servicios Remotos o Localizacin en interiores o Localizacin por GPS o Sistema de Navegacin Inercial o Interaccin con Objetos Virtuales o Look! X X X X X X X X Layar X X X X X X X mixare X X X AndAR X X

Cuadro 3.1: Tabla comparativa de las caracter sticas de Look! con otras aplicaciones realidad aumentada Android: De naturaleza ms abierta, basado en software libre y desarroa llado por Google pero disponible en smartphones de diversos fabricantes ( HTC, Motorola, Sony Ericsson, Samsung, etc.) En concreto, como muestra la gura 3.5, el crecimiento de Android ha sido exponencial en los ultimos aos. Esto es relevante debido a que desarrollar para n dicho sistema supone hoy en d llegar a millones de usuarios de dispositivos a mviles de diferentes fabricantes en todo el mundo, y da una muestra de que o esta tendencia se encuentra lejos de revertirse en un futuro cercano. Esto lo convierte en una plataforma muy atractiva para el desarrollo de nuevas aplicaciones mviles. o En las siguientes subsecciones se explican los principales sistemas operativos consideradas para la implementacin de Look!, sus caracter o sticas, ventajas y desventajas, y nalmente se expone la decisin tomada. o

3.2.1.

Android

Android es un sistema operativo de cdigo abierto basado en Linux dio seado para dispositivos mviles, como smartphones o tablets, desarrollado por n o Google.

20

Figura 3.5: Mercado Android entre 2009 y 2010 Apareci en 2005, y es un sistema relativamente joven e inmaduro. Su ncleo o u est programado en C y C++, y puede ser modicado y compilado para crear a sistemas personalizados. Aunque puede ejecutarse cdigo C directamente sobre el ncleo de la platao u forma a travs del NDK (Native Development Kit), la mayor de aplicaciones e a son programadas a travs del Android SDK, que utiliza el lenguaje Java como e base.

3.2.2.

iOS

iOS es un sistema operativo mvil cerrado de Apple utilizado por el iPhone, o el iPod Touch y el iPad. Es un sistema maduro que permite la programacin de aplicaciones en Objectiveo C, un lenguaje de programacin orientado a objetos creado como superconjunto o de C, pero que implementa un modelo de objetos parecido al de Smalltlak. Para el desarrollo, se utiliza el iOS SDK, que puede ser obtenido de manera gratuita tras registrarse como desarrollador de la plataforma. El desarrollo para iOS debe realizarse desde el sistema operativo Mac.

3.2.3.

Tecnolog de escritorio ms webcam a a

Por la complejidad asociada a los dispositivos mviles, se plantea la posibio lidad de desarrollar el framework a modo prueba de concepto para equipos de escritorio, simulando la realidad aumentada con ayuda de la webcam, con un lenguaje orientado a objetos, como C++ o Java. Esta v aporta una capacidad de cmputo mayor, as como innidad de a o bibliotecas con funcionalidades inexistentes en los sistemas mviles. o Su clara desventaja es que slo ser una prueba de concepto, puesto que la o a realidad aumentada adquiere su mayor sentido en dispositivos mviles. o

21

3.2.4.

Tecnolog escogida a

La tecnolog escogida es Android, por las siguientes razones: a Resultados reales: Aunque la prueba de concepto en una plataforma de escritorio supondr menos l a mites tcnicos y de procesamiento, el desae rrollo directo en la plataforma mvil arrojar unos resultados ms reales o a a de los problemas y soluciones que pueden lograrse. Java: Los miembros del equipo tienen amplios conocimientos de Java, pero no de Objective-C, lo que ahorrar tiempo en el aprendizaje de la a plataforma. Sistema abierto: Android es un framework de cdigo abierto, lo que pero mitir todo tipo de experimentacin necesaria con elementos no ofrecidos a o a priori por el SDK. Plataforma en expansin: Aunque iOS lleva ms tiempo en el mercado, o a Android est sufriendo un crecimiento exponencial en la actualidad, lo que a amplia enormemente el mercado para el framework. Acceso a dispositivos de prueba: Los miembros del equipo cuentan con dispositivos de prueba Android, pero no de iOS. Al momento del inicio del proyecto, Android se encuentra en su versin 2.2. o Esta ser la versin del SDK utilizada en el desarrollo de Look!, no descartando a o utilizar una versin ms moderna si apareciera. o a

3.3.

OpenGL ES

OpenGL4 es una API grca, multilenguaje y multiplataforma, diseada a n para la produccin de grcos 2D y 3D. o a OpenGL ES5 es una versin para plataformas portables de OpenGL. Cono siste en una versin reducida de la versin OpenGL de escritorio, y est pensada o o a para funcionar en sistemas embebidos: consolas porttiles, dispositivos mviles, a o accesorios electrnicos o veh o culos. Android implementa OpenGL ES en sus dos versiones, la 1.1 y la 2.0, pero de diferentes maneras. A continuacin, una breve descripcin para cada una de o o ellas.

3.3.1.

OpenGL ES 1.1

OpenGL ES 1.1 est denida a partir de la especicacin 1.5 de Open GL a o e intenta explotar la aceleracin hardware de los dispositivos. Adems, es como a patible hacia atrs con la versin 1.0. a o Android provee la clase GLSurfaceView, una clase completamente preparada para trabajar con esta versin de Open GL ES y que se maneja como cualquier o otra View de Android. Su programacin es sencilla y puede ser realizada desde o el SDK.
4 http://www.opengl.org/ 5 http://www.khronos.org/opengles/

22

3.3.2.

OpenGL ES 2.0

OpenGL Es 2.0 est denida con base en la especicacin 2.0 de Open GL. a o Utiliza una losof totalmente distinta a su versin predecesora, basado en pipea o line 3D programable y shaders denidos por el OpenGL ES Shading Language. Adems, no es compatible hacia atrs. a a Al inicio del proyecto, en octubre de 2010, la utilizacin de esta versin o o de OpenGL estaba supeditada al uso del NDK (Native Development Kit). El NDK permite ejecutar directamente programas en C o C++ de forma nativa en Android, puesto que el sistema operativo est construido sobre una base Linux. a As slo era posible programar la versin 2.0 en C o C++ a travs del NDK. , o o e En las ultimas versiones de Android, esto ha cambiado, y en la actualidad es posible programar con Open GL ES 2.0 desde el SDK de Android.

3.3.3.

OpenGL ES 1.1 vs 2.0

Aunque la versin 2.0 ofrece mayor rendimiento y mayor funcionalidad, en o Look! se ha decidido utilizar la versin 1.1 por lo siguientes motivos: o Compatibilidad de dispositivos: La versin 2.0 necesita una acelerao cin hardware con la que no cuentan todos los dispositivos actuales. La o versin 1.1, sin embargo, es soportada por todos los dispositivos Android. o Sencillez: Cuando se inici el proyecto, el uso de la versin 2.0 implicaba o o programacin con el NDK, lo que conlleva mayor complejidad en el cdio o go y la programacin, al tener que combinar dos lenguajes distintos. La o versin 1.1 puede ser programada directamente desde el SDK. o Rendimiento adecuado: An siendo la versin 2.0 la de mayor rendiu o miento, la mayor de aplicaciones existentes al inicio del proyecto, funcioa nando con 1.1, mostraban una capacidades grcas similares o superiores a a las buscadas en Look!. As que fue considerado que el equilibrio entre complejidad y resultado era el adecuado.

3.4.

Anlisis de Servicios Web a

Una de las decisiones ms importantes que se deben tomar a la hora de a disear un sistema distribuido es la eleccin de la tecnolog de comunicacin n o a o entre cliente y servidor, ya que marcar las limitaciones del framework para el a acceso a servicios remotos. Por este motivo nos decantamos por un Servicio e Web6 , donde nos conectamos usando el protocolo HTTP, permitindonos elegir el puerto para establecer la conexin. Un servicio web es adaptable a otros tipos o de cliente (Web, Windows, IOS, ...), haciendo posible una futura ampliacin del o framework a otros entornos. A continuacin presentamos un estudio sobre las arquitecturas ms utilizadas o a para dar soporte a servicios web y su compatibilidad con Android. Tras valorar esta comparativa, nos decidimos por RESTful.
6 El consorcio W3C dene los Servicios Web como sistemas software dise ados para soportar n una interaccin interoperable maquina a maquina sobre una red. Los Servicios Web suelen o ser APIs Web que pueden ser accedidas dentro de una red (principalmente Internet) y son ejecutados en el sistema que los aloja.

23

3.4.1.

Arquitecturas ms comunes para Servicios Web a

Remote Procedure Calls (RPC, Llamadas a Procedimientos Remotos): Los Servicios Web basados en RPC presentan una interfaz de llamada a procedimientos y funciones distribuidas, lo cual es familiar a muchos desarrolladores. T picamente, la unidad bsica de este tipo de servicios es la a operacin WSDL (WSDL es un descriptor del Servicio Web, es decir, el o homologo del IDL para COM). Las primeras herramientas para Servicios Web estaban centradas en esta visin. Algunos lo llaman la primera geneo racin de Servicios Web. Esta es la razn por la que este estilo est muy o o a extendido. Sin embargo, ha sido algunas veces criticado por no ser dbile mente acoplado, ya que suele ser implementado por medio del mapeo de servicios directamente a funciones espec cas del lenguaje o llamadas a mtodos. e Arquitectura Orientada a Servicios (Service-oriented Architecture, SOA). Los Servicios Web pueden tambin ser implementados siguiendo los e conceptos de la arquitectura SOA, donde la unidad bsica de comunicaa cin es el mensaje, ms que la operacin. Esto es t o a o picamente referenciado como servicios orientados a mensajes. Los Servicios Web basados en SOA son soportados por la mayor parte de desarrolladores de software y analistas. Al contrario que los Servicios Web basados en RPC, este estilo es dbilmente acoplado, lo cual es preferible ya que se centra en el contrae to proporcionado por el documento WSDL, ms que en los detalles de a implementacin subyacentes. o REST (REpresentation State Transfer). Los Servicios Web basados en REST intentan emular al protocolo HTTP o protocolos similares mediante la restriccin de establecer la interfaz a un conjunto conocido de opeo raciones estndar (por ejemplo GET, PUT,. . . ). Por tanto, este estilo se a centra ms en interactuar con recursos con estado, que con mensajes y a operaciones. Aunque REST no es un estndar, est basado en estndares: HTTP, URL, a a a representacin de los recursos mediante formatos estndar (XML/HTMo a L/GIF/JPEG/...), tipos MIME (text/xml, text/html...).

3.4.2.

Compatibilidad con Android

Analizamos cada una de estas tres arquitecturas evaluando su implementacin en el cliente (Android). o El protocolo elegido para el cliente tambin servir para disear el servidor, e a n ya que este es ms adaptable y puede ser desarrollado en cualquier tecnolog a a. XML-RPC XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML para codicar los datos y HTTP como protocolo de transmisin de mensajes. o Destaca por su simplicidad, a pesar de que la mayor de los protocolos basados a 24

en RPC son muy complejos de utilizar. Los datos en este protocolo son enviados como text/xml y hay librer paa ra casi todos los lenguajes, incluido Android (android-xmlrpc7 ) que simplica el uso de esta tecnolog encapsulando las clases entidad en un XML para su a env o recepcin. o o La desventaja de este protocolo es que a pesar de su sencillez, comunicar tipos u objetos denidos por el usuario se vuelve innecesariamente complejo8 . SOAP SOAP es un protocolo basado en SOA, por el cual la comunicacin se basa o en el env de mensajes entre el cliente y el servidor. Este a pesar de estar muy o extendido entre los Servicios Web, Android lo desaconseja ya que es muy pesado y complejo de implementar. Hay una librer para Android (ksoap2-android)9 que nos permite crear los a objetos SOAP y procesar su env Aunque en nuestras pruebas hemos como. probado que no est del todo estable y esto provoca muchos fallos. a RESTful (HTTP) REST proporciona un protocolo cliente/servidor sin estado: cada mensaje HTTP contiene toda la informacin necesaria para comprender la peticin. Coo o mo resultado, ni el cliente ni el servidor necesitan recordar ningn estado de las u comunicaciones entre mensajes. Un Servicio Web RESTful (tambin llamado RESTful web API) es un e simple servicio web implementado usando HTTP y los principios de REST. Estos son una coleccin de recursos, con estos aspectos denidos: o La URI base para el servicio web, tal como http://example.com/resources/ El tipo de datos soportado por el servicio web. Este es a menudo JSON, XML o YAML pero podemos usar cualquier otro MIME10 (Internet media type). El conjunto de operaciones soportadas por el servicio web usando los mtoe dos HTTP (POST, GET, PUT o DELETE). A diferencia de los servicios web basados en SOAP, no hay ningn estndar u a ocial para servicios web RESTful aunque si nos aconsejan sobre su implementacin. Tambin hay una librer que implementa un servicio web basado en o e a REST, Restlet11 la cual tiene tambin versin para Android. e o
sobre la librer para Android: http://code.google.com/p/android-xmlrpc/ a implementar el mecanismo de serializacin en XML, o el uso de librer externas. o as 9 Ms informacin en la web ocial: http://code.google.com/p/ksoap2-android/ a o 10 Multipurpose Internet Mail Extensions o MIME son una serie de convenciones o especicaciones dirigidas al intercambio a travs de Internet de todo tipo de archivos (texto, audio, e v deo, etc.) de forma transparente para el usuario 11 Ms informacin en la web ocial: http://www.restlet.org/ a o
8 Requiere 7 Informacin o

25

La gran ventaja de usar RESTful es su acogida por parte de Android, quien ha publicado un esquema para su implementacin. Aunque la librer Restlet o a ayude a crear el servicio web, vemos preferible denir los mtodos de la arquie tectura en nuestro framework, ajustndose a los requisitos necesarios, tal como a lo especica Android.

3.4.3.

Valoracin o

Del anlisis anterior, tanto SOAP como RESTful resuelven la misma funcioa nalidad. Aunque nos decantamos por RESTful por tener una mayor acogida y documentacin sobre su uso en Android. o XML-RPC podr haber sido la alternativa a REST, precisamente no hemos a escogido este protocolo para no limitar el Servicio Web. Con RESTful en caso de ampliar el framework para enviar al servidor cheros u objetos complejos no tendr amos problema.

3.5.

Anlisis de Proyectos de Localizacin a o

Uno de los componentes principales del framework de realidad aumentada es la localizacin de un dispositivo mvil dentro de un edicio. Esta funcionalidad o o permite un sinf de aplicaciones, y es una parte esencial en nuestro desarrollo. n Sin embargo, encontrar la solucin a este problema no es en absoluto trivial, ya o que dentro de un edicio no es posible utilizar sistemas GPS, y los requerimientos en cuanto a precisin son mayores. o A la hora de desarrollar un sistema de localizacin en interiores de edicios o para nuestro framework, decidimos realizar en primer lugar un estudio de de proyectos existentes de localizacin desarrollados por diversas empresas y unio versidades con el n de analizar su adecuacin a nuestro proyecto y decidir si o merece la pena hacer un desarrollo desde cero o reutilizar alguno de los proyectos ya existentes. En las siguientes secciones se describen los diferentes proyectos que se han analizado: PlaceLab, Ekahau y Indoor Navigation System for Handheld Devices. Finalmente se enumeran las conclusiones del anlisis. a

3.5.1.

PlaceLab

PlaceLab12 es un proyecto Open Source desarrollado por Intel Research con el objetivo de crear un sistema de geolocalizacin basado en la tcnica conocida o e como Clculo del punto central a partir de nodos predenidos que se explica a en la seccin 3.6.3. La documentacin del proyecto reza que dicha tcnica es o o e vlida tanto para exteriores como para interiores de edicios. a Para ello se vale de fuentes de ondas de radiofrecuencia que pueden ser de tres tipos distintos: Puntos de acceso WiFi. Dispositivos Bluetooth.
12 http://ils.intel-research.net/place-lab

26

Antenas de radio GSM. De esta forma, la informacin recibida en un momento dado se contrasta con o bases de nodos fuente de ondas, conocidos como balizas, y sus coordenadas. Se trata de buscar qu ondas se reciben en cada momento, dnde se encuentran sus e o fuentes y a partir de esta informacin calcular el punto central de todas ellas. o En las siguientes subsecciones se describen los principales mdulos que cono forman la aplicacin, nuestra experiencia utilizando la herramienta y las cono clusiones nales de nuestro anlisis. a Mdulo Stumbler o La localizacin mediante esta tcnica se basa en contrastar las ondas deteco e tadas en un momento dado con bases de datos previamente elaboradas de nodos fuente y coordenadas asociadas. Es necesario elaborar en primer lugar dichas bases de datos. En el caso de PlaceLab, se utilizan bases de datos ya existentes y de acceso pblico provenientes de pginas de War Driving 13 , y tambin utilizan su propia u a e base de datos. Para ello, se utiliza una base de datos local como cach que se e sincroniza con dichas bases de datos de forma peridica. o Adems, el software provee una aplicacin conocida como Stumbler que, a o conectada a un GPS, es capaz de capturar nuevos nodos y aadirlos a la base n de datos cach para su posterior sincronizacin. e o

Figura 3.6: PlaceLab Stumbler

Mdulo Tracker o El tracker es la parte encargada de estimar una localizacin del dispositivo en o base a las balizas detectadas en un momento dado. Existen distintos mtodos e para hacerlo y adems dicha funcionalidad es extensible, permitiendo aadir a n mtodos propios a los ya existentes. e Por defecto, Placelab incluye los siguientes mtodos: e
13 Por

ejemplo http://wigle.net/.

27

Centroid: Consiste en la bsqueda del punto central de las balizas detecu tadas. Filtro de part culas: Se utiliza un ltro de part culas para modelar el movimiento del dispositivo y aplicar modelos estad sticos para predecir la posicin en base a dicha informacin. o o La herramienta Tracker utiliza alguno de estos mtodos para la estimacin e o de la posicin en cada instante. Para ello en primer lugar captura la informacin o o de las ondas de radio en cada instante y procesa la posicin en base al algoritmo o seleccionado.

Figura 3.7: PlaceLab Tracker

Anlisis a A la hora de realizar el anlisis de esta herramienta, nos encontramos con a algunas dicultades debido a que en el momento de realizar las pruebas el proyecto llevaba ya algunos aos discontinuado. Las principales dicultades que n encontramos fueron la siguientes: Bases de datos: Desde la aplicacin nos result imposible cargar las bases o o de datos de puntos wi a la cach local. La base de datos propia de placelab e se encontraba fuera de l nea, y la conexin con la base de datos de wigle.net o se basaba en una API antigua. Por ello, para realizar las pruebas tuvimos que editar manualmente la base de datos cache (HSQLDB) introduciendo manualmente las coordenadas y la informacin de los puntos de acceso a o utilizar. Librer as: Por limitaciones de hardware disponible, las pruebas se realizaron en una mquina con Mac OS X utilizando unicamente puntos de a acceso WiFi. Para ello, debido a la antigedad del software, fue necesario u portar el cdigo encargado de acceso al hardware a librer nativas que o as utilizaran la nueva API de Mac OS X. Se dedica el anexo B para describir este proceso con mayor detalle, ya que no result en absoluto trivial. o

28

Hardware necesario: Para la funcin de captura de nodos (Stumbler) o se requer hardware GPS conectado al puerto de serie, por lo que no fue a posible utilizar dicha funcionalidad. Una vez sorteados los problemas iniciales, se hicieron diversas pruebas con hasta 4 routers colocados a lo largo de un edicio para comprobar la precisin o que es capaz de obtener y la adecuacin a nuestro proyecto. o Es necesario destacar que mediante este sistema de localizacin la posicin o o de los routers es relevante ya que la posicin resultante se inere a travs de las o e posiciones de cada uno de los routers denidos. Sin embargo, ninguno de los algoritmos consigui resultados satisfactorios, o ya que la precisin obtenida fue muy baja. El algoritmo de calculo de la posicin o o central a los nodos es demasiado simple y no tiene en cuenta la intensidad de seal recibida por cada red. Por otra parte, sistemas como el ltro de part n culas puede resultar util en veh culos, donde tiene sentido obtener una prediccin de o la trayectoria, pero no resulta adecuado para personas en interiores. Por otra parte, existe una limitacin aadida debido a que este software no o n est diseado para trabajar en tres dimensiones sino en coordenadas bidimena n sionales, por lo que surge el problema de la deteccin de la planta dentro de un o edicio. Existe un proyecto basado en placelab que ampl las caracter a sticas del software aadiendo soporte para plantas de edicio. n Sin embargo, sus conclusiones no se presentaban demasiado halageas, y u n llegado a este punto, decidimos optar por otras alternativas para la localizacin. o Creemos que este sistema puede resultar util para obtener una localizacin o aproximada en exteriores en situaciones en las que se carece de un sistema de posicionamiento GPS, pero el punto de vista desde el que aborda el problema lo hace inadecuado para las necesidades de precisin de nuestro proyecto, en o torno a unos pocos metros. De todas formas, el anlisis de este proyecto nos a proporcion una valiosa experiencia que utilizamos posteriormente para disear o n sistemas de localizacin ms adaptados a nuestras necesidades. o a

3.5.2.

Ekahau

Se trata de una empresa que ofrece soluciones avanzadas de localizacin en o interiores mediante sistemas wi. En un primer momento tratamos de analizar su sistema de localizacin para comprobar si se adecuaba al nuestro proyecto y si o era posible implantarlo evitndonos tener que disear un sistema de localizacin a n o desde cero. Para ello nos pusimos en contacto con la empresa para tratar de obtener una demo gratuita del producto para analizarla ms en detalle, ya que a la informacin disponible era bastante escasa. Sin embargo, tardamos mucho o tiempo en obtener respuesta y su sistema nos pareci poco aplicable tal y como o estaba planteado el proyecto, adems de tener un coste elevado, por lo que a nalemente decidimos descartarlo en favor de un desarrollo propio acorde a nuestras necesidades.

29

3.5.3.

Proyecto Indoor Navigation System for Handheld Devices

Este proyecto se basa en el trabajo Application of Channel Modeling for Indoor Localization Using TOA and RSS 14 realizado por Ahmad Hatami para el Worscester Polytechnic Institute de Massachusetts, y trata de proporcionar un prototipo utilizando las ideas que se desarrollan en dicha investigacin. o Estas ideas son principalmente la creacin automtica de un mapa de radio o a mediante procesado de mapas por ray tracing15 , la deteccin de movimiento16 o y la combinacin de geolozalizacin por ondas wi y movimiento inercial meo o diante tcnicas estad e sticas. El proyecto en s est formado por dos componentes a principales: Una serie de librer para Matlab para el procesado de mapas y obtencin as o de los mapas de radio. Una aplicacin para Android que implementa la localizacin en funcin o o o de los mapas de radio, y la deteccin de pasos. o En las siguientes subsecciones se describen en mayor detalle cada uno de los mdulos y se presentan las conclusiones del anlisis realizado sobre este o a proyecto. Mdulo de Creacin de mapas de radio mediante ray tracing para o o Matlab Consiste en un conjunto de librer para Matlab que implementa los algoas ritmos para el procesado de mapas y el modelado de la propagacin de la seal o n wi de diferentes puntos de acceso dentro de un edicio. Para ello, es necesario introducir los siguientes parmetros de entrada: a Informacin del Punto de Acceso: o Coordenadas (X,Y). Potencia del punto de acceso, medida a un metro de distancia. Direccin MAC. o Una lista de muros, denidos por sus coordenadas (X1,Y1), (X2,Y2) y el nivel de atenuacin que producen en la seal. o n El resultado del procesado es un mapa de radio como el que se muestra a continuacin, resultado de procesar un mapa de prueba creado para la ocasin. o o

Mdulo de Inferencia de la posicin o o La inferencia de la posicin se encuentra implementada en una aplicacin o o Android que consta de los siguientes mdulos: o Captura de datos wi y contraste con los mapas de radio.
14 http://www.wpi.edu/Pubs/ETD/Available/etd-053106-160141/. 15 Explicado 16 Explicado

en la seccin 3.6.8 o en la seccin 3.6.6 o

30

Figura 3.8: Mapa de Radio resultado del procesado Sistema de navegacin inercial basado en la deteccin de movimiento. o o Combinacin de los sistemas anteriores mediante tcnicas estad o e sticas para la obtencin de la posicin nal. o o La aplicacin se encarga de mostrar la posicin del usuario en el mapa, o o adems de algunas otras funcionalidades tales como el clculo de la ruta entre a a dos puntos del mapa. En la gura 3.9 se aprecia este software funcionando sobre un dispositivo Android y mostrando en un mapa (simplemente un cuadrado en rojo) la posicin del usuario y su orientacin. o o Anlisis a Tuvimos bastantes dicultades para la implantacin de este sistema, ya que o no se trata de un proyecto abierto cuyo cdigo fuente puede descargarse, sino de o un documento en el que parte del cdigo se encuentra disponible en un anexo, o aunque hay partes incompletas. Una vez que conseguimos poner en marcha la funcionalidad principal, realizamos algunas pruebas. Sin embargo, nos encontramos con algunas limitaciones para poder poner a prueba el sistema en situaciones reales: No disponibilidad de mapas de calidad a escala. Desconocimiento de la localizacin exacta de los puntos de acceso. o Finalmente decidimos utilizar las lecciones aprendidas en el estudio de este sistema para el diseo de un sistema de localizacin ms adaptado a las necesin o a dades de nuestro proyecto. Algunas partes, tales como la deteccin de pasos han o sido aprovechadas en buena medida. Otras partes, como la elaboracin de los o mapas de radio, han sido rediseadas. No obstante, el estudio de este proyecto n nos aporto informacin muy valiosa, y sin ello nos habr resultado muy dif o a cil desarrollar nuestro propio sistema de localizacin. o 31

Figura 3.9: Ejecucin de Indoor Navigation System for Handheld Devices o

3.5.4.

Conclusiones

Despus de realizar el anlisis de los sistemas de localizacin anteriormente e a o descritos, se lleg a la conclusin de que ninguno de ellos se ajustaba a las o o necesidades de nuestro proyecto y se decidi hacer un desarrollo desde cero o partiendo de la experiencia adquirida en dicho anlisis. a De entre las lecciones aprendidas, destacamos las siguientes: Los sistemas de localizacin por Wi basados en mapas de radio ofrecen o resultados aceptables sin necesidad de hardware externo. La necesidad de combinar ms de un sistema de localizacin: un sistema a o primario de localizacin por radiofrecuencia y un sistema secundario de o navegacin inercial. o

3.6.

Tcnicas de Localizacin en Interiores e o

Una vez descartada la reutilizacin de proyectos de localizacin existentes y o o tomada la decisin de iniciar un desarrollo desde cero ms adecuado a nuestras o a necesidades, en primer lugar se realiz un exhaustivo anlisis de las posibles o a tcnicas que pueden emplearse para la resolucin de este problema. e o Los requerimientos principales que debe tener nuestro sistema de localizacin o son en primer lugar precisin y versatilidad 17 , y en segundo lugar facilidad de o implantacin y aprovechamiento del hardware existente en dispositivos mviles o o actuales. De entre los mtodos analizados, se realiz una seleccin de los ms prometee o o a dores para un estudio en mayor profundidad, realizacin de pruebas e implemeno tacin de prototipos. Finalmente se opt por una combinacin de las tcnicas o o o e
17 En el sentido de que el usuario no se tenga que preocupar del sistema que subyace para la obtencin de la localizacin. o o

32

descritas en las secciones 3.6.6 (localizacin mediante deteccin de movimiento) o o y 3.6.7 (localizacin mediante mapas de Radio Wi). o En esta seccin se describen las posibles tcnicas anlizadas, sus ventajas e o e a inconvenientes.

3.6.1.

Localizacin mediante etiquetas RFID o

Este fue uno de los primeros planteamientos que se hizo, y consiste en la colocacin a lo largo de todo el edicio de etiquetas RFID. Cada una de las o etiquetas posee un identicador unico que puede ser le por radiofrecuencia, do de forma que al ser detectadas por un lector RFID puede inferirse la posicin a o partir de una base de datos de identicadores y posiciones. Este sistema fue descartado por diversos motivos, entre otros la necesidad de un hardware espec co, su escasa aplicabilidad en edicios grandes debido al nmero de etiquetas necesarias y su dicultad de implantacin. u o Ventajas: Sencillez. Inconvenientes: Necesidad de un gran nmero de etiquetas para que sea preciso, debido a u su escaso alcance. Dicultad de implantacin y poca escalibilidad. o Necesidad de hardware externo al dispositivo y coste asociado.

3.6.2.

Localizacin mediante marcas visibles o

Este es otro de los mtodos analizados y rpidamente descartados. Consiste e a en la utilizacin de marcas visibles en las paredes que puedan ser detectadas meo diante una cmara y reconocidas por un sistema de visin. Cada marca equivale a o a una posicin espec o ca almacenada en una base de datos. Aunque este mtodo puede tener aplicaciones utiles, por ejemplo en museos, e no cumple con nuestros requerimientos de localizacin ya que se pretende diso poner de una localizacin pasiva en la que el usuario no tenga que preocuparse o de en ningn momento de la forma en que la posicin es inferida. u o Ventajas: Al ser marcas localizadas se consigue gran precisin. o Inconvenientes: Localizacin no pasiva y no continua. o Reconocimiento de marcas no trivial. Deja de funcionar si se interponen obstculos entre la cmara y las marcas. a a

33

3.6.3.

Localizacin mediante el Clculo del Punto Central o a a partir de nodos predenidos

Consiste en la creacin de una base de datos de puntos predenidos, que o pueden ser antenas de telefon puntos de acceso wi, dispositivos bluetooth, a, etc. Estos nodos tienen asociadas en la base de datos sus coordenadas reales. De esta forma, el dispositivo mvil comprueba peridicamente cuntos de estos o o a puntos es capaz de detectar, y a partir de los nodos detectados inere su posicin o mediante el clculo del punto central a todos ellos, tambin conocido como a e Centroid Centro Geomtrico. o e Este mtodo no debe confundirse con el mtodo de inferencia de la posicin e e o mediante la fuerza de la seal recibida para cada punto de acceso, que se comenta n en los apartados 3.6.7 y 3.6.8. La diferencia fundamental radica en que mediante este mtodo no es necesaria la elaboracin de mapas de radio, aunque la precisin e o o disminuye de forma drstica. a Se pueden aplicar diversas mejoras sobre esta tecnolog tales como el uso a, de informacin estad o stica acerca del movimiento del dispositivo para calcular la posicin en base a la probabilidad de que este se encuentre en un punto o determinado. Existen diversos proyectos que utilizan esta tecnolog en conjuncin con a o bases de datos de puntos de acceso obtenidos por war drivingque permiten localizar un mvil con una precisin aceptable sin la necesidad de usar GPS. El o o ejemplo ms claro es Placelab 18 , que se analiza en la seccin 3.5.1. Sin embara o go, esta tecnolog no ofreci los resultados que esperabamos en interiores de a o edicios por varios motivos. En primer lugar, el hecho de que el mecanismo de inferencia se base slamente o en la deteccin o no deteccin de un determinado punto de acceso limita en o o gran medida la precisin que es posible obtener. Esta puede ser suciente para o localizar un mvil en exteriores de manera aproximada, pero no para obtener o un posicin en el interior de un edicio. o Adems, cambios en la deteccin de los puntos de acceso, que pueden uctuar a o mucho dentro de un edicio para una misma posicin (especialmente en redes o wi), producen grandes cambios en la prediccin. Este problema se ilustra en la o gura 3.10, en la cual se aprecian los cambios producidos en la seal de diferentes n puntos de acceso Wi a lo largo del tiempo para un mismo punto. Por tanto esta tecnolog se mostr inadecuada para las necesidades de nuesa o tro proyecto. Ventajas: No requiere hardware externo. Precisin aceptable en exteriores. o Inconvenientes: Precisin insuciente para interiores. Si el alcance a cada emisor es muy o grande la precisin es muy baja incluso en exteriores. o Inestabilidad. Necesita reconocimiento previo de los nodos.
18 http://ils.intel-research.net/place-lab

34

Figura 3.10: Fluctuacin de la seal en redes WiFi o n

3.6.4.

Localizacin mediante Triangulacin de la Se al o o n

Existen dos mtodos de triangulacin para sistemas basados en ondas de e o radio: Triangulacin por tiempo de llegada (TOA): consiste en calcular o el tiempo que tarda una onda desde que sale del dispositivo fuente hasta que llega al dispositivo destino. En base a dicha informacin, y utilizando o al menos tres nodos fuente, se inere la posicin en que se encuentra el o dispositivo mvil. o Triangulacin por intensidad de se al (RSS): consiste en calcular la o n fuerza de la seal que llega de al menos tres dispositivos fuente distintos. n En base a dicha informacin, se inere la posicin del dispositivo o o Ninguno de estos mtodos es aplicable a las ondas wi, ya que dichas ondas e rebotan en el interior, de un edicio, produciendo reexiones y refracciones que alteran el tiempo de llegada y la intensidad de la seal. Adems surge el n a problema de la propagacin multitrayecto, ya que las ondas pueden llegar al o dispositivo destino por multiples caminos, produciendo tiempos de llegada y atenuaciones distintos. Es posible aplicar estos mtodos a las redes de telefon pero debido a la e a, lejan que hay entre las diferentes antenas de telefon la precisin que se a a, o conseguir ser muy baja y en cualquier caso insuciente para la localizacin a a o en interiores. Se han estudiado aplicaciones de estos mtodos para ondas de baja frecuene cia. 19 Sin embargo, esto hace necesaria la disponibilidad de hardware externo
19 En el documento Application of Channel Modeling for Indoor Localization Using TOA and RSS, Worcester Polytechnic Institute (http://www.wpi.edu/) se realiza un estudio sobre este tipo de sistemas y se consiguen resultados aceptables, del orden de 4 metros de precisin, o mediante la combinacin de tcnicas de Ray Tracing y el uso de sistemas de baja frecuencia o e de 500 MHz.

35

espec co, y resulta poco verstil e inadecuado para los nes que persigue nuesa tro proyecto, por lo que este mtodo fue nalmente descartado. e Ventajas: Puede conseguir buenas precisiones. Inconvenientes: No aplicable con el hardware disponible. Implantacin costosa. o

3.6.5.

Localizacin mediante Sistemas Inerciales o

Este mtodo consiste en la utilizacin de sistemas inerciales tales como acee o lermetros20 y giroscopios21 para el clculo del movimiento relativo de un diso a positivo mvil en el espacio. o Para ello, se procesan todos los eventos de aceleracin detectados por el o sensor en cada uno de los ejes cartesianos (X, Y, Z). Es necesario eliminar el efecto de la gravedad en cada uno de los ejes para obtener las aceleraciones absolutas en cada instante. Para ello, se utiliza un ltro que se encarga de calcular la fuerza de la gravedad en cada eje y restarla a la aceleracin detectada. o Una vez hecho esto, se integra la aceleracin respecto al tiempo para obtener o la velocidad, y se vuelve a integrar la velocidad con respecto al tiempo para obtener el desplazamiento. Este desplazamiento resultante es el desplazamiento relativo en ese instante en cada uno de los ejes. Mediante el clculo de los desplazamientos relativos, tericamente, es posible a o obtener la posicin de un mvil en cada instante. Sin embargo, en funcin de o o o la precisin del acelermetro se producirn mayores o menores errores entre o o a cmputo y cmputo que determinarn el tiempo durante el cual el clculo es o o a a able. A partir de cierto tiempo es necesario resetear la posicin para evitar o grandes desfases. Hemos realizado diversos prototipos de sistemas de navegacin inercial, tanto o para el mando de la consola Nintendo Wii como para mviles Android, y en o todos los casos la precisin del acelermetro result ser muy baja y los errores o o o acumulados se volvieron inasumibles, ya que estos errores descompensaban las fuerzas de aceleracin y deceleracin volviendo el sistema rpidamente inestable. o o a
22

Sin embargo, creemos que con acelermetros de mayor precisin23 es posible o o obtener resultados aceptables mediante esta tcnica, siempre y cuando sea come binada con otras tcnicas de localizacin para poder resetear la posicin cada e o o cierto tiempo y evitar grandes errores acumulativos.24 Ventajas:
destinado a medir aceleraciones. utilizado para medir la orientacin. o 22 Estos prototipos se especican en mayor detalle en el Anexo A. 23 Se puede encontrar ms informacin acerca de la precisin de los acelermetros en la a o o o seccin A.5. o 24 Se trata de utilizar una posicin obtenida mediante otras tcnicas de localizacin como o e o base, y entre intervalos de actualizacin utilizar el sistema inercial para calcular la posicin o o relativa en base a dicho punto.
21 Intrumento 20 Instrumento

36

Puede ser un buen complemento a otras tcnicas de localizacin. e o Inconvenientes: Necesidad de hardware de gran precisin. o Error acumulativo. Insuciente como unico mtodo de localizacin. e o

3.6.6.

Localizacin mediante Deteccin de Movimiento o o

Esta tcnica consiste en detectar, mediante el uso de un acelermetro, cundo e o a la persona que porta el dispositivo est caminando, para posteriormente aplicar a una velocidad de paso estndar en la direccin correcta. 25 a o Para ello, se mantiene una lista con las ultimas N mediciones del acelerme o tro, y se calcula su desvacin estndar. Se trata de buscar una desviacin o a o estndar por encima de cierto umbral para detectar movimiento continuado. a Si la persona est en movimiento se producirn variaciones cont a a nuas en la aceleracin que aumentarn la desviacin estndar. o a o a Una vez se ha detectado si la persona est o no caminando, se utiliza la a brjula del dispositivo para calcular la direccin de la persona con respecto al u o Norte magntico de la Tierra, y se aplica una velocidad de paso estndar en e a dicha direccin. o Esta tcnica no debe confundirse con los sistemas inerciales descritos en la e seccin 3.6.5. La diferencia radica en que la primera tcnica trata de obtener los o e valores exactos de desplazamiento relativo por medio de la aceleracin, mieno tras que est tcnica trata de aproximar el desplazamiento por medio de una a e velocidad estndar cuando se detecta que la persona est en movimiento. a a Hemos desarrollado diversos prototipos. y esta tcnica ha resultado en la e prctica comportarse mucho mejor que la anteriormente descrita, detectando a con bastante precisin cundo una persona camina. A pesar de ello, sigue hao a biendo error acumulado tanto por la velocidad de paso aplicada, que no deja de ser una aproximacin, como por los falsos positivos que pudieran darse al deo tectar el movimiento de la persona, por lo que sigue siendo necesario un mtodo e de localizacin auxiliar que permita resetear la posicin cada cierto tiempo. o o Este mtodo ha sido implementado e incluido en el proyecto en conjuncin e o con otros ya que ha sido el sistema de navegacin inercial que mejor se ha o comportado en la prctica. En la seccin 5.2 se describe en mayor detalle la a o implementacin llevada a cabo de este sistema. o Ventajas: Efectivo como mtodo auxiliar de localizacin. e o Aporta precisin extra. o Hardware necesario disponible en telfonos mviles actuales. e o Inconvenientes:
velocidad de paso se hace referencia a una velocidad estndar a la que camina un ser a humano, estimada en 5 Km / hora. La direccin se calcula por medio de un giroscopio, que o puede utilizarse para emular el funcionamiento de una brjula. u
25 Con

37

Error acumulativo, requiere ser reseteado peridicamente. o Insuciente como unico mtodo de localizacin. e o

3.6.7.

Localizacin mediante Mapas de Radio WiFi o

Este mtodo consiste en la obtencin, a partir de un proceso de captura de e o datos, de un mapa de radio (radiomap) de las ondas wi de diferentes puntos de acceso en diferentes nodos previamente denidos. Este mapa de radio es utilizado posteriormente para inferir la posicin del dispositivo mediante distintos tipos o de algoritmos. El primer paso consiste en obtener una lista de los puntos wi que se utilizarn en la creacin del mapa de radio. Estos pueden ser denidos por SSID o a o por direccin MAC de los mismos. o Una vez obtenida la lista de puntos wi, se dene una serie de nodos y se llevan a cabo capturas de datos en cada nodo. En estas capturas se guarda informacin de los niveles de seal de cada uno de los puntos de acceso en ese o n punto. La informacin obtenida en las capturas conforma el mapa de radio. 26 o Obtenido el mapa de radio, la posicin del dispositivo se inere mediante la o captura de datos y bsqueda del nodo con mayor similitud. Esto puede hacerse u con distintos tipos de algoritmos. Mediante este mtodo se han obtenido los mejores resultados, llegando a e conseguir con bastante xito localizacin a nivel de habitacin. En posteriores e o o cap tulos se estudia con mayor detalle la precisin que es posible conseguirse o con este mtodo de localizacin variando distintos parmetros. e o a Ventajas: El mecanismo de entrenamiento asegura una buena precisin. o Hardware necesario disponible en telfonos mviles actuales. e o Inconvenientes: Se requiere captura previa de datos. Los datos obtenidos para un dispositivo pueden no ser vlidos para otro. a Cambios en la estructura del edicio, de mobiliario, etc, pueden invalidar los datos de entrenamiento. A continuacin de presentan los algoritmos utilizados en este proyecto para o la inferencia de la posicin en base a los mapas de radio. o Closest Neighbor Consiste en la bsqueda del nodo con mxima similitud a los datos obtenidos u a en cada medicin. Para ello se calcula la distancia ecucl o dea de cada nodo con respecto a los datos obtenidos, y se devuelve el nodo cuya distancia eucl dea es menor. Este algoritmo ha resultado comportarse realmente bien en la inferencia de la posicin a pesar de su simpleza. o
26 Tambin e

conocido como ngerprint.

38

Redes Neuronales Tambin se han empleado redes neuronales para la inferencia de la posicin e o con respecto a los datos obtenidos. Se trata de utilizar la red para un problema de reconocimiento de patrones. Para ello en primer lugar es necesario de denir el tipo y la arquitectura de la red. En las pruebas se ha utilizado una red neuronal Perceptrn Multicapa, con propagacin hacia atrs y con diversas arquitecturas o o a y nmero de neuronas. Se ha utilizado una codicacin en cdigo Gray para las u o o entradas y una salida para cada uno de los puntos de acceso empleados en la captura de datos, de forma que la salida para cada nodo se encuentra entre 0 y 1 en funcin de su similitud a los datos de entrada. o Antes de proceder a la localizacin es necesario entrenar la red neuronal con o las datos obtenidos para cada nodo. Una vez alcanzado un error en el entrenamiento por debajo de cierto umbral, la red queda entrenada y lsta para recibir nuevos datos de entrada. Los resultados con este mtodo dependen en gran medida de los parmetros e a de la red tales como la arquitectura y el nmero de neuronas utilizadas, y ha u permitido obtener resultados aceptables aunque creemos que an mejorables u con un estudio ms detallado de diferentes tipos de arquitectura para resolver a este problema.

3.6.8.

Localizacin mediante Mapas de Radio obtenidos o Automticamente a

Esta tcnica consiste en la obtencin del mapa de radio mediante el procesado e o de mapas en lugar de en la captura de datos, ya que dicho proceso puede llegar a ser muy costoso. Para ello, se emplean tcnicas basadas en ray tracing para el modelado del e comportamiento de las ondas en el interior del edicio, sus reexiones y refracciones. Para ello, se carga un mapa a escala del edicio y se jan los puntos de acceso y el nivel de atenuacin que producen los muros. Con estos datos, se o lanzan rayos en todas direcciones para cada uno de los puntos de acceso y se trata de calcular de manera aproximada cmo se comportarn las ondas. Con o a esta informacin se crean los mapas de radio para ser utilizados en la inferencia o de la posicin mediante alguno de los algoritmos descritos anteriormente. o Diversas investigaciones, como la llevada a cabo por el Worcester Polytechnic Institute de Massachusetts 27 , arrojan unos resultados prometedores mediante esta tcnica. Sin embargo, nosotros decidimos descartarla debido a que es necee saria informacin acerca de la atenuacin de muros, localizacin exacta de los o o o puntos de acceso y mapas de calidad a escala. Ventajas: Tiene las ventajas de las tcnicas basadas en mapas de radio, pero elimina e la necesidad de realizar capturas de datos previas, que pueden ser muy costosas. Inconvenientes:
27 http://www.wpi.edu/.

39

Al realizarse un modelado, los datos obtenidos son aproximados y pueden ser incorrectos en determinadas zonas del edicio. Requiere informacin de la atenuacin de los muros, colocacin exacta de o o o los puntos de acceso y mapas a escala de calidad.

3.7.

Conclusiones

Ninguno de los framework de realidad aumentada analizados satisface nuestros requisitos, bien porque su funcionalidad es demasiado simple, bien porque o son cerrados y presentan limitaciones: no disponibilidad del cdigo fuente ni poo sibilidad de extensin. Por tanto se ha tomado la decisin de hacer un desarrollo o o desde cero para cubrir el vac existente de frameworks de realidad aumentada o de cdigo abierto y con capacidad de extensin. o o Se ha seleccionado el sistema operativo Android para el desarrollo debido a que es un sistema operativo mvil abierto y en expansin, que nos permite o o trabajar en Java y para el que tenemos acceso a dispositivos. Se ha decidido utilizar OpenGL ES 1.1 debido a su mayor compatibilidad con dispositivos, sencillez y rendimiento suciente para nuestras necesidades. A la hora de incorporar un servicio web al framework, se ha elegido RESTful porque es la arquitectura recomendada por Google para su integracin en o Android y est mejor documentada que el resto de tecnolog a as. Ninguno de los proyectos de localizacin en interiores analizados nos permite o su reutilizacin debido a que no cubren nuestras necesidades de precisin y capao o cidad de integracin en Android. De entre las tcnicas de localizacin analizadas o e o se ha seleccionado una tcnica h e brida basada en las siguientes: Localizacin meo diante Deteccin de Movimiento (seccin 3.6.6) y Localizacin mediante Mapas o o o de Radio WiFi (seccin 3.6.7). o

40

Cap tulo 4

Arquitectura Global
La arquitectura global proporciona una visin general de cmo est construio o a do el framework, qu mdulos lo conforman y cmo se encuentran organizados e o o dichos mdulos. o La construccin de aplicaciones mediante el framework se puede dividir en o dos capas: la capa del framework y la capa de aplicacin, que se construye sobre o la del framework (gura 4.1).

Figura 4.1: Capas del Desarrollo de Aplicaciones mediante Look La capa del framework est formada por los siguientes mdulos: Mdulo de a o o Localizacin, Mdulo de Datos y Mdulo de Realidad Aumentada. Cada uno de o o o ellos se describe en este cap tulo de manera general en su seccin correspondiente o 1 . Finalmente se dedica una seccin a la integracin de los mdulos para la o o o creacin de aplicaciones. o

4.1.

Mdulo de Localizacin o o

El mdulo de localizacin es el encargado de proporcionar la funcionalidad o o relativa al sistema de localizacin. Est formado por los siguientes componentes o a (Figura 4.2) : Localizacin Wi: Encargado de proporcionar un sistema de localizacin o o primario mediante wi.
1 Cada

uno de los mdulos se describe ms detalle en su cap o a tulo correspondiente.

41

Navegacin Inercial: Proporciona un sistema secundario de localizacin o o mediante un sistema de navegacin inercial, con el n de aumentar la o precisin del sistema de localizacin primario, o de utilizarlo como sistema o o de localizacin independiente. o Mdulo de localizacin: Encargado de integrar los sistemas de localio o zacin primario y secundario. o

Figura 4.2: Diagrama de Componentes de Localizacin o La salida obtenida desde el mdulo de localizacin es la posicin del diso o o positivo, con respecto al sistema de referencia denido (se ver con ms detalle a a en el cap tulo 5). Esta localizacin ser recogida y procesada por el Mdulo de o a o Datos.

4.2.

Mdulo de Datos o

El Mdulo de Datos es el ncleo de todas las aplicacin construidas con o u o Look!. Tiene dos funcionalidades muy diferenciadas: la primera, obtiene los datos de una serie de recursos denidos, locales o remotos; la segunda, procesa los datos obtenidos y provee de elementos representables por el Mdulo de Realidad o Aumentada. En la gura 4.3 se muestra una visin conjunta del Mdulo de Datos con los o o proveedores de contenido. Puede congurarse, a travs de interfaces comunes, e de dnde proceden los datos. Pueden estar denidos de manera programtica, o a obtenerse de archivos de recursos (por ejemplo, en formato XML), de una base de datos local o de una base de datos remota. El Mdulo de Datos puede tener acoplado el Mdulo de Localizacin, como o o o una fuente de obtencin de datos ms. o a El Mdulo de Datos y los distintos proveedores de datos se tratarn con o a mayor detalle en el cap tulo 6.

4.3.

Mdulo de Realidad Aumentada o

El mdulo de Realidad Aumentada contiene elementos con capacidades de o representacin grca que sern utilizados para la creacin de la interfaz de o a a o 42

Figura 4.3: Diagrama de Componentes del mdulo de datos o usuario. Existe un mdulo base al que, opcionalmente, pueden ser aadidos cada uno o n de los mdulos de representacin individuales que aparecen en la gura 4.4: o o Cmara: Mdulo que ofrece la visin de la cmara. a o o a Visualizacin 3D: Mdulo para la visualizacin de elementos animados o o o en tres dimensiones. Visualizacin 2D: Mdulo para la visualizacin de elementos animados o o o en dos dimensiones. HUD: Mdulo para albergar elementos adicionales a la interfaz de usuao rio, como botones, cajas de texto o otras View ofrecidas por Android. El mdulo de realidad aumentada debe ser conectado a un mdulo de datos o o que provea de los elementos (WorldEntity) que han de ser representados de manera grca por la aplicacin. a o Se har una descripcin en detalle de todos los mdulos de capas en el a o o cap tulo 7.

4.4.

Uniendo los mdulos para la creacin de o o aplicaciones

Cada uno de los mdulos presentados hasta ahora representa una funcioo nalidad aislada. La combinacin de los diferentes mdulos, dependientes de la o o aplicacin a desarrollar, darn lugar a las aplicaciones. o a En las gura 4.5 se muestra la arquitectura global (en trminos de compoe nentes) de las aplicaciones creadas con Look!. Como base, siempre tendremos el mdulo de datos. Este mdulo utilio o zar el mdulo de Localizacin para actualizar la posicin del usuario, con a o o o un tasa de refresco que puede ser congurada. Por ultimo, el mdulo de realidad aumentada, acceder al mdulo de o a o datos, y representar los elementos obtenidos. a 43

Figura 4.4: Diagrama de Componentes de la Interfaz de Realidad Aumentada

Figura 4.5: Diagrama de componentes general para aplicaciones construidas con Look!

44

Cap tulo 5

Mdulo de localizacin o o
Uno de los pilares bsicos del framework que hemos desarrollado es la capaa cidad de obtener la localizacin de un dispositivo en el interior de un edicio. o Dada la dicultad del problema, se ha invertido gran esfuerzo y tiempo en la investigacin de posibles tcnicas para llevar a cabo esta tarea. Una vez adquio e rida cierta experiencia, y descartada la reutilizacin de sistemas de localizacin o o ya existentes, hemos procedido a disear un sistema propio de localizacin de n o acuerdo a nuestras necesidades. Este sistema se basa en la combinacin de una o tcnica primaria de localizacin mediante wi (explicada en la seccin 3.6.7) y e o o una tcnica secundaria de localizacin mediante un sistema de navegacin inere o o cial (explicado en la seccin 3.6.6). Asimismo, para el funcionamiento de dichos o sistemas, es necesario conocer la orientacin del dispositivo. o En esta seccin se explica en primer lugar cmo se obtiene la orientacin o o o de un dispositivo en Android. Seguidamente se describen los subsistemas de localizacin mediante Navegacin Inercial y mediante Wi que se han impleo o mentado en el framework Look!. Por ultimo, se detalla cmo se integran ambos o subsistemas en un unico API de localizacin accesible de manera global. o

5.1.

Orientacin del mvil en Android o o

Para lograr aplicaciones en realidad aumentada cre bles es necesario conocer la orientacin del dispositivo mvil para poder colocar los elementos de una o o manera lgica. En esta seccin se explica cmo trata Android la orientacin en o o o o sus dispositivos, los pasos esenciales para comprender su funcionamiento y su aplicacin. o

5.1.1.

Pitch, azimuth y roll

Android dene tres rotaciones para el dispositivo: pitch, azimuth y roll, que se denen como las rotaciones en los ejes x, y y z respecto a la posicin de o reposo, como muestra la gura. La posicin de reposo del dispositivo se establece con el mismo formando un o angulo perpendicular respecto a la fuerza de gravedad, y sealando con su parte n superior al norte.

45

Figura 5.1: Denicin de pitch, azimuth y roll o

5.1.2.

Obteniendo la orientacin: DeviceOrientation o

La clase DeviceOrientation implementa el patrn de diseo Singleton y proo n porciona en todo momento la actual orientacin, denida por los tres parmetros o a presentados en la seccin anterior, del dispositivo. o Para su clculo, utiliza dos sensores incorporados en todos los dispositivos a Android: el acelermetro y el medidor de campo magntico. Android proporo e ciona mtodos que, a partir de estos datos, calculan la matriz de rotacin del e o dispositivo, a partir de la cul, se pueden obtener los tres parmetros buscados. a a DeviceOrientation ofrece al framework estos tres parmetros y la matriz de a rotacin, que puede ser aplicada en algunos casos concretos de transformaciones o 3D en Open GL.

Figura 5.2: Clase DeviceOrientation

5.2.

Subsistema de Navegacin Inercial o

En esta seccin se decribe el subsistema de navegacin inercial que se utiliza o o en el mdulo de localizacin. El sistema desarrollado es fruto de diversos experio o mentos realizados en los que se trata de utilizar acelermetros para el desarrollo o

46

de un sistema de posicionamiento en interiores. Su objetivo es estimar el movimiento relativo del dispositivo en base a una posicin de partida. Este trabajo o est basado en el sistema de navegacin inercial descrito en el proyecto Indoor a o Navegation System for Handheld Devices.

5.2.1.

Dise o n

La idea consiste en detectar cundo el usuario est caminando y aplicar a a una velocidad estndar de paso en la direccin adecuada. Para ello se necesita a o obtener informacin de diversos sensores del dispositivo: o Acelermetro para detectar aceleraciones y movimiento. o Giroscopio para detectar la direccin. o Para detectar cundo el usuario est o no en movimiento, en primer lugar se a a guarda una cola con los ultimos N eventos de aceleracin recibidos por el sensor o (acelermetro). Estos eventos se reciben a una tasa de muestreo previamente o jada. Cada vez que se aade un nuevo evento de aceleracin a la cola, en n o primer lugar se comprueba si esta est llena y en caso armativo se desecha el a elemento ms antiguo. a Una vez hecho esto, se calcula la desviacin estndar sobre la magnitud too a tal de aceleracin de todos los elementos de la cola y se comprueba si esta cae o por encima de un determinado umbral. Para calcular la magnitud total de cada evento de aceleracin se calcula la ra de la suma de los cuadrados de cada uno o z de los ejes de coordenadas (X,Y,Z): M=
N i=1

v[i]2

Si la desviacin estndar est por encima del umbral signica que el diso a a positivo est en movimiento, en caso contrario es que el dispositivo no est en a a movimiento. De manera anloga, a intervalos de tiempo jados se actualiza la informacin a o de la direccin del dispositivo a partir de los sensores disponibles. En caso de que o el dispositivo se encuentre en movimiento, se aplica una velocidad estndar de a paso en la direccin correspondiente proporcional al tiempo transcurrido desde o el ultimo evento de aceleracin. o

5.2.2.

Arquitectura

En esta seccin se modela la arquitectura y el comportamiento del sistema o para su posterior implementacin. o Diagrama de Clases A continuacin se describen las principales clases que conforman el subsiso tema de navegacin inercial, representadas en la gura 5.4: o La clase LocationProvider es la encargada de centralizar la funcionalidad del subsistema de navegacin inercial, registrando los listener para los o distintos tipos de eventos y procesndolos segn sea necesario. a u

47

Figura 5.3: Diagrama de Flujo: Sistema de Navegacion Inercial DeviceSensor se encarga de aplicar el algoritmo de deteccin de movimieno to. Positioning es la clase que mantiene la informacin de la posicin, el deso o plazamiento relativo y la deteccin/no deteccin de movimiento. o o InertialNavigationSystem se encarga de realizar los clculos relativos al a desplazamiento producido. Motion representa la informacin de cada uno de los desplazamientos reo lativos.

Diagrama de Secuencia A continuacin se describe el comportamiento del sistema, representado en o la gura 5.5, desde que se recibe un nuevo evento de aceleracin hasta que el o usuario lee la nueva posicin. o 1. La aplicacin crea un nuevo LocationProvider, que registra listeners sobre o los sensores y permanece a la espera de nuevos eventos. Adems, inicializa a el sistema de navegacin inercial. o 2. Se recibe un nuevo evento de aceleracin y se notica tanto a Positioning o como a DeviceSensor. 3. DeviceSensor aplica el algoritmo de deteccin de movimiento. Si se deteco ta movimiento Positioning env un mensaje a InertialNavigationSystem a para que procese el nuevo evento desplazamiento relativo producido. 4. La aplicacin llama a process para calcular la nueva posicin en base a los o o desplazamientos relativos y obtiene la posicin nal. o

48

Figura 5.4: Diagrama de Clases INS

49

Figura 5.5: Diagrama de secuencia INS

50

5.2.3.

Implementacin o

La implementacin se ha realizado para un sistemas Android en su versin o o 2.2 o posterior. Se han dijado los siguientes parmetros de funcionamiento: a HUMAN SPEED WALK: 5 Km / hora. Frecuencia de muestreo: SENSOR DELAY FASTEST. El acceso a los sensores se realiza a travs de la clase SensorManager del e API de Android. mSensorManager = ( SensorManager ) CONTEXT . g e t S y s t e m S e r v i c e ( Context . SENSOR SERVICE ) ; S e n s o r a s e n s o r = mSensorManager . g e t D e f a u l t S e n s o r ( S e n s o r .TYPE ACCELEROMETER) ; S e n s o r msensor = mSensorManager . g e t D e f a u l t S e n s o r ( S e n s o r . TYPE MAGNETIC FIELD ) ; S e n s o r o s e n s o r = mSensorManager . g e t D e f a u l t S e n s o r ( S e n s o r . TYPE ORIENTATION ) ; mSensorManager . r e g i s t e r L i s t e n e r ( t h i s , a s e n s o r , SensorManager . SENSOR DELAY FASTEST ) ; mSensorManager . r e g i s t e r L i s t e n e r ( t h i s , msensor , SensorManager . SENSOR DELAY FASTEST ) ; mSensorManager . r e g i s t e r L i s t e n e r ( t h i s , o s e n s o r , SensorManager . SENSOR DELAY FASTEST ) ; A pesar de que a partir versiones de la API de Android posteriores a la 1.5 se provee acceso directo al giroscopio, y en caso de no estar disponible se emula de manera automtica mediante el acelermetro, al estar basado en un proyecto a o desarrollado para la versin 1.5 calculamos la orientacin a partir de los sensores o o de orientacin y campo magntico de forma manual. A partir de la versin 2.3 o e o de Android el API de acceso a los sensores ha mejorado considerablemente, realizando de manera automtica funciones tales como la eliminacin del efecto a o de la gravedad de la aceleracin. o Para probar este subsistema, lo hemos integrado con una aplicacin desao rrollada mediante nuestro framework que utiliza la informacin de navegacin o o inercial para simular un mundo virtual. Al movernos en el mundo real, nos movemos tambin en el mundo virtual. Los sensores de orientacin permiten adems e o a saber hacia donde se est mirando, de forma que la experiencia de simulacin a o es completa. En la gura 5.6 se muestra una captura de dicha aplicacin. En ella, se o observa el mundo 3D y objetos con los que es posible interactuar. Cuando la persona que porta el dispositivo gira sobre si misma, tambin cambia la perse pectiva en el mundo virtual, y si empieza a andar se detectar dicha situacin a o y se avanzar en el mundo virtual. a

5.3.

Subsistema de Localizacin por WiFi o

El sistema de localizacin mediante Wi que se ha desarrollado consta de o varias fases: una fase de planicacin, una fase de captura de datos y una fase o 51

Figura 5.6: Aplicacin de prueba para el subsistema de Navegacin Inercial o o de localizacin. o En esta seccin se describen los requisitos, el diseo y la arquitectura de o n dicho sistema de localizacin y se explica en detalle cada una de las fases que lo o componen.

5.3.1.

Requisitos

Funcionales Se debe proporcionar un servicio autnomo que provea los siguientes mtoo e dos: Start: Arrancar el servicio de localizacin. o Stop: Parar el servicio. getPosicion: Acceso a la posicin en coordenadas (X,Y,Z), correso pondiente Z a la planta del edicio. Se deber implementar un sistema de logs. Debe ser posible seleccionar un archivo de log como fuente de datos para la realizacin de pruebas. o No Funcionales Precisiones a nivel de habitacin pueden resultar sucientes para algunos o tipos de aplicaciones. Tiempo de actualizacin de la posicin no superior a 10 segundos. o o Hardware disponible en smartphones modernos. 52

5.3.2.

Dise o n

Se ha buscado un diseo que maximice la precisin, aunque ello signice san o cricar la facilidad de implantacin. Para ello, el sistema consta de los siguientes o mdulos: o Un primer mdulo de planicacin en el cual, dado el mapa de un edicio, o o se seleccionan nodos en posiciones relevantes, se enumeran y se etiquetan. El sistema tratar posteriormente de aproximar la posicin actual al nodo a o ms cercano de la lista de nodos denidos. Adems, es necesario decidir a a qu puntos de acceso se utilizarn en la localizacin. Deben ser puntos de e a o acceso estables, a ser posible propios, ya que la desconexin de alguno de o ellos puede producir que el sistema de localizacin deje de funcionar. o Un mdulo de captura de datos, en el cual para cada uno de los nodos o denidos, se registra la fuerza de la seal recibida de cada uno de los n puntos de acceso. El resultado es un mapa de la cobertura wi para cada nodo, conocido como mapa de radio o ngerprint. Dicha informacin se o almacena en un chero para su uso posterior. Para eliminar los efectos del ruido y estabilizar la seal recibida, se muestrea durante varios segundos n y se compactan los datos. Un mdulo de localizacin. En este mdulo, el dispositivo realiza escao o o neos de redes wi a intervalos de tiempo denidos y contrasta la informacin detectada con la almacenada en los mapas de radio. La inferencia del o nodo ms factible se lleva a cabo utilizando diversos algortitmos que se a describen ms adelante. Para eliminar los efectos del ruido y estabilizar a la seal recibida, al igual que en la fase de captura de datos, se muestrea n durante varios segundos y se compactan los datos antes de hacer la comparacin. El resultado corresponde a la informacin del nodo ms parecido o o a a la posicin actual. o En las siguientes subsecciones se describe en mayor detalle cada uno de los mdulos. o En la gura 5.7 se representa la interaccin entre los mdulos desde que o o desde que inicia la planicacin hasta que se inere una posicin. o o Planicacin o En primer lugar se seleccionan los nodos que se utilizarn en el sistema de a localizacin. Conviene que los nodos se encuentren en habitaciones separadas, ya o que la atenuacin que provocan los muros permite diferenciar sucientemente las o seales de forma que el sistema de localizacin se comporte de manera ptima. n o o Para cada uno de los nodos elegidos se debe recopilar la siguiente informacin: 1 o Coordenadas (X,Y,Z), donde Z corresponde al nmero de planta. u N mero de Nodo. Todos los nodos deben estar enumerados para su fcil u a identicacin. o
1 La informacin de los nodos debe recopilarse sobre un mapa y ser incluida en el chero o Lugares.txt de forma manual.

53

Figura 5.7: Esquema de la localizacion por WiFi Etiqueta describiendo a qu posicin hace referencia el nodo dentro del e o edicio.

Figura 5.8: Ejemplo de seleccion de Nodos Tambin es necesario jar los puntos de acceso que se utilizarn en la loe a calizacin mediante una lista de direcciones MAC de los mismos. Se provee o deteccin automtica de puntos de acceso en un edicio si no se desea restringir o a los puntos de acceso a utilizar. Toda esta informacin puede recopilarse de forma manual y debe ser incluida o en los cheros APs.txt y Lugares.txt dentro de la tarjeta SD para ser posteriormente utilizados por el resto mdulos. A continuacin se muestran ejemplos de o o cada uno de los cheros que es necesario generar: APs.txt Lista de direcciones MAC de los puntos de acceso a utilizar. 0 0 : 1 1 : f 5 : a1 : 4 7 : ac 00:1 a :2 b :5 b : f f :28 7 0 : 7 1 : bc : 8 a : 6 b : c f

54

Lugares.txt Id, Planta, Coordenada X, Coordenada Y y Nombre respectivamente. 1 2 3 4 5 5 5 5 14 5 H a b i t a c i o n 8 4 banno 4 4 Cocina 2 1 Salon

Captura de datos En esta fase se muestrea la informacin wi en cada uno de los nodos seo leccionados a n de elaborar un mapa de radio. Se pueden variar los siguientes parmetros de muestreo: a Tiempo de muestreo: Indica el tiempo durante el cual se toman muestras en cada nodo. Esto se hace para evitar problemas derivados de la uctuacin de la seal y el ruido. Se intenta estabilizar la informacin o n o capturado varias muestras y compactndolas en una sola. a N mero de muestras. Es posible capturar ms de una muestra en cada u a nodo, de forma que al hacerse la comparacin en la fase de localizacin o o existan mayores posibilidades de acierto. Tasa de refresco. Intervalo de tiempo entre cada muestra. La compactacin de muestras se realiza de la siguiente manera: o 1. Se guarda la informacin de todos los puntos de acceso detectados en el o total de muestras. 2. Si algn punto de acceso aparece ms de una vez, se calcula la media de u a sus valores de fuerza de seal detectados. n Localizacin o Esta fase trata de obtener una posicin aproximada a partir de los mapas o de radio obtenidos en la fase de captura. Para ello, se capturan datos mediante el escaneo de redes wi y se contrasta la informacin con la almacenada para o cada nodo. Los parmetros que se pueden jar son los mismos que en la fase de entrea namiento. Tiempo de muestreo: Indica el tiempo durante el cual se toman muestras en cada nodo. Esto se hace para evitar problemas derivados de la uctuacin de la seal y el ruido. Se intenta estabilizar la informacin o n o capturado varias muestras y compactndolas en una sola. a N mero de muestras. Es posible capturar ms de una muestra en cada u a nodo, de forma que al hacerse la comparacin en la fase de localizacin o o existan mayores posibilidades de acierto. Tasa de refresco. Intervalo de tiempo entre cada muestra. 55

Para obtener resultados consistentes, la localizacin se debe llevar a cabo con o los mismos valores en los parmetros que los utilizados en la fase de captura. a Una vez compactados los datos del escaneo, se procesan mediante alguno de los algoritmos desarrollados para buscar el nodo con mayor similitud en base a los valores de fuerza de seal detectados. A continuacin se describen dichos n o algoritmos. Algoritmo Closest Neighbor Consiste en la bsqueda del nodo ms parecido de un conjunto de entrenau a miento. Para ello se calcula la distancia eucl dea entre los nodos detectados y los nodos entrenados y se selecciona aquel cuya distancia eucl dea es menor. La frmula para calcular la distancia eucl o dea es la siguiente: D=
N i=1 (ai

qi )

donde D es la distancia obtenida, ai es la fuerza de la seal del punto de n acceso i de el conjunto de entrenamiento y qi es la fuerza de la seal del punto n de acceso i de el conjunto detectado. 2 De esta forma, el nodo seleccionado se elige de la siguiente forma: N odoSel = m n(
N i=1 (ai

qi ))

Las coordenadas del nodo seleccionado se devuelven como coordenadas actuales del dispositivo. Redes Neuronales Consiste en utilizar una red neuronal, entrenada mediante el conjunto de datos obtenidos en la fase de captura, para obtener el grado de similitud del conjunto de datos detectado con cada uno de los nodos del conjunto de entrenamiento. Se trata de un problema de reconocimiento de patrones. Se ha empleado una red neuronal Perceptrn Multicapa con las siguientes caracter o sticas: Capa de entrada: Se codica la informacin de la seal de cada punto o n de acceso en nmeros binarios de 7 bits. 3 Posteriormente se codica la u informacin binaria en cdigo Gray (tambin de 7 bits) para evitar que o o e pequeas variaciones en la seal produzcan variaciones grandes en la con n dicacin de la informacin. Por tanto habr N * 7 neuronas de entrada o o a en la red neuronal, donde N es el nmero de puntos de acceso jados. u Capa Oculta: Se ha utilizado una unica capa oculta con un nmero de u neuronas igual a 50 por limitaciones del hardware que se comentan en la seccin de implementacin. o o
2 Los conjuntos de entrenamiento y detectado contienen el mismo n mero puntos de acceso u gracias a que los puntos de acceso a utilizar estn prejados en la fase de planicacin y a o almacenados en el chero correspondiente. Los puntos de acceso no detectados en el anlisis a se aaden automticamente con valor de atenuacin -100dB, que corresponde a una fuerza de n a o seal igual a 0. n 3 La informacin de se al est en el intervalo [-100, 0] dB. Tomando el valor absoluto, 7 o n a bits son sucientes para representar toda la informacin de la seal o n

56

Capa de Salida: Hay una neurona de salida por cada uno de los nodos. El valor de salida se encuentra en el intervalo [0,1] y corresponde al nivel de similitud entre los datos de entrada y los datos entrenados. Un valor de 0 equivale a ninguna similitud, y un valor de 1 similitud total. Entrenamiento mediante algoritmo de propagacin hacia atrs. o a Funcin de transferencia: Sigmoid. o Tasa de aprendizaje: Se ha jado en 0.5. Valores demasiado altos pueden hacer que el algoritmo de entrenamiento se atasque en un m nimo local. Valores demasiado bajos pueden hacer muy lento el proceso. Condicin de parada: Error en entrenamiento inferior a 0.01. o

Figura 5.9: Red Neuronal Perceptron Multicapa Para entrenar la red se crea un conjunto de entrenamiento en el que los datos de entrada son los datos obtenidos en la fase de captura y la salida esperada es 1 para la neurona que representa el nodo actual y 0 para el resto. Una vez entrenada la red, esta puede utilizarse para la localizacin. Para o ello, se crea un conjunto de entrada a partir de la informacin detectada y se o introduce en la red. Para cada neurona de salida, se obtiene un valor en el intervalo [0,1] correspondiente al nivel de similitud de la informacin con dicho o nodo. Finalmente, se selecciona el nodo cuya similitud es mayor y se comprueba si est por encima de un umbral denido. En caso armativo, se devuelven las a coordenadas de dicho nodo como localizacin actual del dispositivo. o

5.3.3.

Arquitectura

En esta seccin se modela la arquitectura y el comportamiento del sistema o para su posterior implementacin. o Diagrama de Clases A continuacin se describen las principales clases que conforman el subsiso tema localizacin por WiFi representadas en la gura 5.10: o 57

WiLocation corresponde al servicio de localizacin en s Provee mtodos o . e para arrancar y parar el servicio, y un mtodo para acceder a la informae cin de la posicin actual. o o Lugar es la clase que contiene la informacin de un nodo. o Lugares proporciona una abstraccin para el acceso a la informacin de o o los nodos contenida en el chero de descripcin de los nodos. A partir de o un nmero identicador devuelve informacin tal como las coordenadas u o del nodo y su etiqueta. NodoWi contiene la informacin de un punto de acceso. o DeviceReader proporciona acceso al contenido de un chero almacenado en la tarjeta SD. DeviceWriter proporciona funciones de escritura de cheros en la tarjeta SD. DateUtils proporciona funciones de acceso a la hora del sistema.

Figura 5.10: Diagrama de clases de la localizacion por WiFi

Diagrama de Secuencia A continuacin se describe el comportamiento del servicio de localizacin, o o representado en la gura 5.11, desde que se inicia el servicio hasta que se lee la posicin. o

58

1. El objeto cliente llama al mtodo start() para arrancar el servicio de locae lizacin. El servicio registra un listener en el API WiManager de Android o y empieza a recibir eventos de escaneo de redes. 2. Se realizan varios escaneos de redes y se van compactando los datos tantas veces como est denido en el parmetro MAX COUNT, que indica el e a nmero de escaneos a realizar por cada procesamiento de datos. u 3. Una vez hecho esto, se llama el mtodo evaluaPosicion(), encargado de e preprocesar los datos ejecutar el algoritmo de inferencia de la posicin o correspondiente. Se actualiza la informacin de la posicin que el resultado o o de la ejecucin del algoritmo. o 4. Este proceso se repite hasta que el cliente llama al mtodo stop(). El cliente e puede acceder a los datos de localizacin en cualquier momento a travs o e del mtodo getPosicion(). e

Figura 5.11: Diagrama de Secuencia Servicio Localizacion WiFi

5.3.4.

Implementacin o

Para la implementacin, se ha desarrollado una aplicacin para Android que o o implementa todas las fases descritas en este cap tulo. La aplicacin se compone o de los siguientes mdulos: o 59

Deteccin de puntos de acceso: Se encarga de la deteccin automtica o o a de los puntos de acceso y la escritura del chero de puntos de acceso. Esto elimina la necesidad de que el usuario tenga que confeccionar esta informacin a mano. Es posible aadir restricciones tales como la deteccin o n o de puntos de acceso con determinado SSID. Captura de datos: Se encarga de la captura de los datos en cada uno de los nodos y en la creacin del chero que contiene el mapa de radio. o El usuario slo tiene que especicar el nmero de identicador del nodo o u correspondiente, situarse en ese punto y comenzar el escaneo. Entrenamiento: (Slo para redes neuronales). Se encarga de crear la red o neuronal, construir el conjunto de entrenamiento y ejecutar el algoritmo de entrenamiento sobre esta. El resultado de la ejecucin es una red neuronal o entrenada, que se almacena en un chero para ser cargada por el mdulo o de localizacin. Adems crea otros cheros necesarios para la ejecucin del o a o algoritmo de localizacin por red neuronal. o Localizacin: Se encarga de ejecutar el servicio de localizacin, mostrano o do los datos del nodo actual en pantalla. Para ello utiliza los cheros creados en las etapas anteriores y el algoritmo correspondiente. Artefactos Generados En la gura 5.12 se representa un esquema de los artefactos que participan y se generan en cada una de las fases del subsistema de localizacin por Wi: o APs.txt: Direcciones MAC de los puntos de acceso que se utilizarn en a la localizacin. o Entrenamiento.txt: Mapa de radio generado por el mdulo de captura o de datos. nndata.txt: Red neuronal entrenada serializada para su uso en el mdulo o de localizacin. o PostProccess.txt: Entradas y salidas de la red neuronal postprocesadas para su uso en el mdulo de entrenamiento. o Nodos.txt: Informacin de los nodos necesaria para el algoritmo de loo calizacin (Nodos que participan y su orden). o Lugares.txt: Informacin de los nodos: id, coordenadas y etiqueta. o

5.3.5.

Pruebas

Para comprobar la precisin del sistema de localizacin, se han realizado o o pruebas utilizando los dos algoritmos en un piso de 90 metros cuadrados, y registrado el porcentaje de acierto en diferentes nodos. Se han denido 4 nodos correspondientes a distintas habitaciones separados por un espacio de entre 1 y 3 metros. Los nodos son los siguientes: ID: 1: Habitacin o 60

Figura 5.12: Artefactos Generados por el sistema de Localizacion WiFi

61

Figura 5.13: Captura del programa de localizacion WiFi en funcionamiento ID: 2: Bao. n ID: 3: Cocina. ID: 4: Saln. o

Figura 5.14: Nodos denidos piso Se han utilizado 3 puntos de acceso propios colocados de forma estratgica a e lo largo del piso. Se ha realizado el entrenamiento y se ha ejecutado el algoritmo de localizacin 10 veces en cada nodo. El resultado se presenta en porcentaje de o acierto en la siguiente tabla:

62

Algoritmo Closest Neighbor Red Neuronal

4

% Habitacin o 100 % 90 %

% Ba o n 0% 30 %

% Cocina 100 % 30 %

% Saln o 100 % 30 %

Se puede comprobar en los resultados que el algoritmo Closest Neighbor se comporta mucho mejor que la red neuronal a la hora de aproximar los nodos, al menos con la conguracin utilizada en la red neuronal. Esto puede ser debido o a una arquitectura inadecuada de la red neuronal, pero limitaciones del tamao n de la pila de programa de Android nos ha impedido utilizar redes de mayor complejidad. Creemos que un mayor estudio de la aplicacin de redes neuronales o a este problema permitir mejorar en gran medida los resultados obtenidos con a este mtodo. e

5.4.

Integracin de los subsistemas de Localizao cin o

Los subsistemas de localizacin se integran a travs de la clase LocationMao e nager, que proporciona una interfaz global para el acceso al sistema de localizacin. Permite utilizar cada uno de los subsistemas de forma separada ambos o o de forma conjunta de forma transparente para el programador de aplicaciones. En la gura 5.15 se muestra en mayor nivel de detalle cmo se integran dichos o subsistemas.

el algoritmo Closest Neighbor, en todas las ocasiones se detect el nodo nmero o u 2 como el nmero 3. Esto indica que la distancia entre los nodos 2 y 3 es demasiado pequea u n y el nodo 3 solapa al nodo 2 en la prediccin. o

4 Mediante

63

Figura 5.15: Integracin de los subsistemas de Localizacin o o

64

Cap tulo 6

Mdulo de datos o
En esta seccin se detalla qu datos son los m o e nimos indispensables para denir elementos en la realidad aumentada, y cmo estn estructurados en Look!. o a Estos datos se representan con una unidad bsica de datos (EntityData),que a detallamos a continuacin. Adems, para formar el Mundo en la Realidad Auo a mentada se dene la WorldEntity, que se construye a partir de un EntityData. Los datos EntityDatapueden estar almacenados en bases de datos locales o remotas, o denidos de manera programtica. De ello se encarga la interfaz a DataHandler, la cual accede a los datos de una manera transparente a la aplicacin. Tambin comentamos como se representan los datos, el tratamiento de o e la persistencia y las implementaciones llevadas a cabo para ello.

6.1.

EntityData como unidad bsica de datos a

Antes de plantear la estructuracin de los datos, conviene establecer dos o deniciones que sern utilizadas a lo largo del texto: Consideramos un dato a como una propiedad asociada a un valor determinado. Un elemento, se corresponder a un conjunto de datos que representan una entidad de un tipo a determinado. Para permitir el mayor nmero de aplicaciones desarrollables por el frameu work, el modelo de datos debe ser general y exible, permitiendo la denicin o de todo tipo de elementos. La aproximacin bsica sugiere que, para permitir la mayor exibilidad poo a sible, los datos de un elemento podr estar representados por una tabla (iman plementada con un Map de Java), que guardara propiedades asociadas a sus respectivos valores. Sin embargo, existen tres propiedades especiales, compartidas por todos los tipos de elementos, que se destacan sobre las dems: a Identicador: Un identicador unico que permita distinguir los elemen tos entre s . Localizacin: En otros contextos no tendr relevancia, pero en Realidad o a Aumentada, todo los elementos, salvo excepciones, estn asociados a una a 65

posicin en el espacio. o Tipo: La clase de entidad a la que pertenece. Este tipo agrupar elemena tos, y facilitar funciones de ltrado de elementos. a En base a todo lo dicho, en Look!, la unidad bsica de datos est reprea a sentada por la clase EntityData (Figura 6.1). Sus atributos principales son un identicador unico, el tipo, la localizacin, y una tabla de propiedades. Ofrece o mtodos para la consulta y modicacin de todos ellos. e o

Figura 6.1: La clase EntityData

Figura 6.2: Diagrama de Clases del Acceso a Datos

66

6.2.

Conectando los datos con el mdulo de realio dad aumentada: Mundo y Entidades del mundo

Una vez hemos obtenido los datos EntityData de nuestra aplicacin, debemos o convertirlos en entidades reconocibles por el mdulo de realidad aumentada, que o se ver con detalle en el cap a tulo 7. Un WorldEntity es una entidad basada en un EntityData, y es representable por el mdulo de realidad aumentada. o El Mundo, reejado en la clase World, representa el contenedor general y unico de todos los entidades que pueden aparecer.

6.2.1.

World

El mundo World ejerce como contenedor, a todos los efectos, de entidades WorldEntity. Contiene mtodos thread-safe que permiten aadir, consultar y e n eliminar entidades del mundo. Como elemento adicional, el mundo contiene una posicin. Esta posicin o o representa la localizacin actual del usuario, dentro de ese mundo. o Al igual que WorldEntity, World est pensado como una clase base que debe a ser extendida para aportar mayor funcionalidad. LookData contiene un Mundo, y ser lo que procese el mdulo de realidad a o aumentada. En la gura 6.3 puede verse un diagrama de clases en dnde se o relacionan todas estas clases.

6.2.2.

WorldEntity

Cada uno de los elementos contenidos por el mundo es una entidad WorldEntity. Estos elementos estn construidos a partir de un EntityData a travs a e de una factor WorldEntityFactory, que se ver con ms detalle despus. a a a e Contiene atributos relacionados con su representacin grca e interacciones o a permitidas, y que son iniciados a partir de los atributos esenciales anteriormente denidos: Representacin 2D: representacin grca que se le da a la entidad en o o a la capa 2D. Se ver con mayor detalle en la seccin 7.4. a o Representacin 3D: representacin grca que se le da a la entidad en o o a la capa 3D. Se ver con mayor detalle en la seccin 7.2. a o Touch Listeners: lista de listeners que responden y actan ante eventos u tctiles sobre el elemento. a Camera Listeners: lista de listeners que responden y actan cuando el u usuario apunta directamente (con el centro de la pantalla) a la entidad. Tambin cuenta con otros atributos sencillos que sirven para congurar el e comportamiento general de la entidad dentro del mundo: Visibilidad: Si el elemento es visible.

67

Figura 6.3: Diagrama de clases de LookData, World, WorldEntity y EntityData, con sus relaciones. Habilitado: Si recibe eventos tctiles o de cmara. a a Tctil: Si puede recibir eventos tctiles. a a Enfocable: Si puede recibir eventos de cmara. a La clase WorldEntity provee los mtodos necesarios para la adecuada manie pulacin de la entidad. Puede y debe ser extendida y personalizada para lograr o comportamientos ms funcionales. a En el cap tulo 7 se ver con mas detalle las interacciones y las representaa ciones en dos y tres dimensiones.

68

6.2.3.

Actualizando el mundo

Cuando el mtodo LookData.getInstance().update() es invocado, los Entitye Data de la aplicacin son convertidos en WorldEntity, a travs de una factor o e a ( Figura 6.4 ), y se produce la actualizacin del mundo. o

Figura 6.4: Actualizacin del mundo o La factor de elementos WorldEntityFactory tiene un unico mtodo, creaa e teWorldEntity( EntityData data), que se encarga de convertir los datos puros en elementos representables por la realidad aumentada. Esta clase debe ser extendida para crear WorldEntity con apariencias personalizadas.

6.3.

Obteniendo y almacenando datos: DataHandler

Una vez denida la estructura bsica del modelo de datos, conviene prea guntarse de dnde se obtienen esos datos que construyen EntityData, y cmo o o y dnde se guardar nuevos datos aadidos durante la ejecucin de la aplicao an n o cin, en caso de que se requiriera persistencia de datos. o La interfaz DataHandler ofrece mtodos generales para la obtencin, modie o cacin y almacenamiento de datos. Est basado en dos interfaces separadas: o a DataGetter, que agrupa toda la funcionalidad de obtencin de datos, y DataSeto ter, que contiene mtodos para la adicin y modicacin de datos ya existentes e o o (Figura 6.5). Corresponde a cada implementacin concreta denir de dnde se obtienen o o los datos, y dnde se almacenan las modicaciones. o Look! ofrece implementaciones bsicas para tres tipos de acceso a datos: daa tos denidos de manera programtica sin persistencia, datos almacenados en una a

69

Figura 6.5: Relacin de DataHandler con EntityData o base de datos local con persistencia y datos almacenados en una base de datos remota con persistencia. A continuacin, se detalla cada una de ellas. o

6.3.1.

Obtencin de datos sin persistencia o

La clase BasicDataHandler implementa DataHandler y ofrece un administrador de datos bsico. Almacena en una lista los EntityData para la aplicaa cin (Figura: 6.6). o

Figura 6.6: Implementacin de BasicDataHandler o Su utilizacin es sencilla: Tras su instanciacin, al inicio de la ejecucin, se le o o o aadirn de manera programtica los EntityData necesarios para la aplicacin. n a a o Tambin podr aadirse, a travs de l, nuevos EntityData durante la e an n e e ejecucin de la aplicacin, as como manipular propiedades de los ya existentes. o o 70

Cundo la aplicacin naliza, los elementos creados son eliminados. a o Se explicar su uso con mayor detalle en el cap a tulo 8.

6.3.2.

Obtencin de datos con persistencia local o

Para implementar una persistencia de datos en nuestras aplicaciones, necesitamos una estructura que almacene los datos de la aplicacin cundo sta no o a e est en ejecucin. Una estructura a travs de la cul se pueda acceder a los datos e o e a persistentes entre ejecuciones, y que permita las operaciones bsicas de consulta a y modicacin. o La estructura elegida para lograr esta persistencia es una base de datos, puesto que Android permite la creacin bases de datos SQLite. Adems, nueso a tra estructura de datos se ajusta bien a esta representacin. o Para el acceso a los datos extendemos la interfaz DataHandler a la clase DBDataHandler que es la encargada de administrar los datos para la persistencia de una manera transparente a la aplicacin (Figura: 6.7). o A continuacin describimos la estructura de la base de datos y su implemeno tacin mediante un Content Provider 1 . o

Figura 6.7: Implementacin de DBDataHandler o

Content Provider es un proveedor de contenido en Android, permite compartir datos entre aplicaciones usando una base de datos SQLite
1 Un

71

Estructura de la base de datos En la base de datos se almacenan elementos EntityData en forma de tablas. La base de datos est formada por dos tablas: La tabla Main, donde a se almacena un registro por cada entidad, con su posicin y ultima fecha de o actualizacin; y la tabla Properties, dnde se guarda cada una de sus propieo o dades en un registro. El tipo de la entidad se guardar como una propiedad ms. a a Describimos a continuacin cada una de las tablas: o Main Compuesta por 5 campos: id Identicador entero unico para cada entidad, clave primaria de la tabla. En la base de datos del servidor esta clave es adems auto incremental. a As nos aseguramos que no se repita en dos entidades. x Coordenada X con la posicin del objeto en el mundo. o y Coordenada Y con la posicin del objeto en el mundo. o z Coordenada Z con la posicin del objeto en el mundo. o last update Fecha y hora con la ultima actualizacin de esta entidad en o la base de datos.

Tabla Properties Describe cada propiedad mediante los siguientes campos: id Identicador de la entidad, el registrado en la tabla Main. property Nombre de la propiedad, es variable para cada tipo distinto de entidad. value Valor de la propiedad descrita en type.

Nota: No puede haber dos propiedades del mismo tipo (campo property) para la misma id (en la implementacin id y type son claves primarias). o 72

Dependencias Cuando se guarda un elemento se crea un registro en la tabla Main con una id unica. Esta misma id es usada para almacenar cada una de sus propiedades en la tabla Properties. La propiedad type dene el tipo de una entidad. Esta propiedad obligatoria ser denida por cada nueva clase de entidad. El campo property ser type y a a en value ir denido el tipo. a Si las coordenadas del objeto no se indican estas sern inciadas a ( 0, 0, 0 ). a Tambin el campo last update ser inicializado con la fecha y hora del actual2 e a con el siguiente formato YYYY-MM-DD hh:mm:ss, cada vez que es actualizada una instancia en la base de datos, sea la posicin, sea una de sus propiedades, o este dato es actualizado con la nueva fecha y hora de la modicacin. o

Ejemplo de una entidad tipo user :

Figura 6.8: Entidad de tipo user usada en la aplicacin Look! Social o

Implementacin de la base de datos o Para el acceso al contenido de la base de datos SQLite hemos denido nuestro Content Provider denominado LookContentProvider, este se encarga de congurar y actualizar una base de datos SQLite. Un Content Provider es un objeto de la clase ContentProvider de Android el cual permite almacenar datos de un determinado tipo (en la base de datos) para que puedan ser accedidos desde cualquier aplicacin. o La eleccin de usar un Content Provider nos permite que el contenido de o una base de datos sea compartido por dos o ms aplicaciones distintas en el a dispositivo. As podr amos comunicar dos aplicaciones desarrolladas con el framework. LookContentProvider realiza la lgica entre las EntityData y la base de datos o SQLite, para ello dispone de dos clases ms para ayudarnos a generar, modicar a o consultar la base de datos (LookSQLContentProvider y LookSQLHelper). En
2 Si la base de datos es remota, en el caso de querer dar acceso a usuarios internacionales el campo last update almacena la hora local del servidor, por lo que el cliente tendr que a calcular la ultima actualizacin respecto a su zona horaria. o

73

la gura 6.7 se representa la estructura del Content Provider. LookSQLContentProvider En esta clase estn denidos los mtodos Query(), Insert(), Update() y Dea e lete() con las operaciones bsicas de la base de datos SQLite. a El acceso a los datos se realiza mediante URIs (recursos), cada elemento tiene asociada una URI unica que lo representa. Cada una de las tablas de la base de datos se representa como un elemento, por lo que denimos las siguientes URIs: Main URI FROM MAINTABLE = content://APLICACION/lookMain/ Properties URI FROM PROPERTIESTABLE = content://APLICACION/lookProperties/ APLICACION se reere al nombre de la aplicacin a desarrollar. Una o aplicacin con una base de datos nueva tiene que denir un nombre para esta o unico, al igual que las URIs unicas para el acceso a sus elementos. Se explica en detalle en el cap tulo 8. LookSQLHelper En esta clase se denen las constantes con los campos y las tablas de la base de datos. Adems se encarga de crear, abrir o actualizar la base de datos con a los siguientes mtodos: e onCreate(): Se llama la primera vez que ejecutamos la aplicacin para o crear la base de datos. onUpgrade(): Cuando actualizamos la base de datos se llama este mtodo. e Actualmente est vac a o. onOpen(): Se ejecuta cuando cargamos la aplicacin. Actualmente est vac o a o.

6.3.3.

Obtencin de datos con persistencia remota o

Para tratar los datos de las aplicaciones con acceso a servicios remotos, debemos proveer de comunicacin con un servidor al framework. En este apartado o explicamos la gestin de la persistencia sobre la estructura de datos con acceso o a un servicio web. Ahora las EntityData son almacenadas tanto en el servidor (datos globales) como en el cliente (datos locales). En el servidor se guardan en una base de datos MySQL, aqu estarn los datos de todos los clientes y sern actualizados a a por estos con consultas enviadas a travs del servicio web. Gracias a esto cone seguimos reducir las transacciones con el servidor accediendo al l solamente e para aadir / modicar un elemento o para actualizar la base de datos de un n cliente con los datos globales. Para el acceso a los datos del servidor se encarga el servicio web detallado en el siguiente apartado.

74

Una vez que el Servicio Web recoge los datos, estos son almacenados en el cliente en una base de datos SQLite con una estructura similar a la MySQL del servidor, esta representa una pequea copia con los datos que utilizaremos del n servidor. La estructura de las bases de datos es la misma detallada anteriormente en el apartado 6.3.2. La implementacin de la base de datos SQLite se congura con LookCono tentProvider tal como se detall para la persistencia local. Solo que ahora esta o restringido a la consulta de datos (DataGuetter ), para modicaciones o actualizaciones se accede directamente al servicio web. El acceso a los datos est simplicado con estas dos interfaces: a DataGetter: (Lectura de datos) El acceso a los datos (EntityData) estar restringido al Content Provider, el cual es actualizado por medio del a Servicio Web de una manera transparente. Est detallado en Content a Provider.

Figura 6.9: Diagrama de secuencia para el acceso de datos DataSetter: (Modicacin/Actualizacin de datos) Si queremos enviar o o nuevas entidades o actualizaciones de estas se acceder directamente al a Servicio Web que est conectado con el servidor. Lo detallamos en Sera vicio Web. Al igual que para el acceso a los datos sin persistencia o con persistencia local, implementamos DataHandler para crear la clase RemoteDataHandler, encargada de administrar los datos para la persistencia con el servicio web de una manera transparente a la aplicacin (Figura: 6.11). o Servicio Web Para aadir o modicar entidades la aplicacin se utiliza el servicio web, el n o cual env los datos al servidor adems se encarga de actualizar la base de datos a a local del Content Provider para mantener la coherencia. Para esto, est conectado directamente con el Content Provider y cada vez a que el dato enviado es procesado por el servidor, si se almacen correctamente o en los datos globales, se actualiza tambin en la base de datos del cliente (SQe Lite).

75

Figura 6.10: Diagrama de secuencia para el almacenamiento de datos A continuacin describimos los mtodos accesibles en el Servicio Web, reo e presentados en la interfaz llamada DataSetter.

addElement(EntityData) Env una nueva entidad al servidor para que sea almacenada en la baa se de datos global. Tambin la crea en la base de datos local para que e est sincronizada. El servidor devuelve el id unico de la nueva entidad y e la copia en local se almacenar con este id. a La EntityData tambin contiene la posicin de la entidad x, y, z y un Map e o con las propiedades que tend el elemento, en caso de no estar vac sern a o a insertadas en la tabla properties. Adems contiene el tipo representado por a type, este es insertado como una propiedad de esta entidad con el campo property = type. updateElementPosition(id, x, y, z) Actualiza con la posicin recibida (x, y, z) la entidad id. Si hay algn o u error el servidor le enviar una respuesta para informarle. No es necesario a informar al Content Provider ya que este dato solamente es usado para modicar nuestra posicin, la cual procede del Location Provider 3 . o updateOrAddProperty(id, property, value) Para tratar una propiedad de una entidad solamente es necesario accede a este mtodo. Si en la entidad con el id especicado no existe esta e propiedad, es insertada por el servidor. En caso de existir previamente ser modicada por la nueva. Al igual que los mtodos anteriores la base a e de datos local tambin ser actualizada con los nuevos datos. e a
3 Nos

informa de nuestra posicin, sistema de localizacin v Wi e inercial o o a

76

Figura 6.11: Implementacin de RemoteDataHandler o deleteElement(id) Eliminamos una entidad (EntityData) con la identicacin id. Ser elimio a nada de la tabla Main y de Properties (todas sus propiedades) tanto en el servidor como en la base de datos local. updateDB(x, y, z, radius, types) Actualizamos las entidades con los tipos representados en la lista types en el cliente (base de datos local). Estos deben estar dentro del radio indicado respecto a la posicin enviada. o Ese radio ser calculado respecto a las coordenadas x e y, la coordenada a z tiene que ser igual en la entidad. Es decir, el elemento tiene que estar entre ((x - radius/2) AND (x + radios/2)) AND ((y - radius/2) AND (y + radius/2)) Adems comprobamos que fecha de la ultima actualizacin de cada entia o dad con la ultima actualizacin por el cliente, as evitamos descargar al o cliente los datos sin modicaciones. El servidor en este caso solamente realiza una peticin para que devuelva o estos datos, por lo que la base de datos global no ser modicada. a Este mtodo es el encargado de sincronizar la base de datos del cliente con e las actualizaciones de los dems usuarios, cada aplicacin puede llamar a a o este mtodo o automticamente por medio de un thread o manualmente e a (con un botn de actualizar). Al comienzo de cada aplicacin (la primera o o vez que se ejecuta) llamamos a este mtodo sin comprobar fechas ya que e la base de datos SQLite estar vac a a. 77

Figura 6.12: Diagrama de secuencia de updateDB()

doLogin(username, password) Este mtodo es especial, trabaja con las propiedades username y password e de los elementos en la base de datos. Lo hemos implementado porque creemos que casi cualquier aplicacin tendr un mtodo para registrarse, o a e as nos evitamos realizar la lgica para cada aplicacin. o o Es necesario que uno de los elementos de la aplicacin contenga la propieo dad username y password. e NOTA: Eliminar una propiedad no existe como mtodo, en el estado actual del framework consideramos que una vez creada no tiene sentido eliminarla, ya que el nmero de propiedades consideradas es jo. u Conexin con el Content Provider o Para mantener actualizado la base de datos local cada vez que enviamos o recibimos datos del servidor, el servicio web internamente se conecta con el Content Provider para sincronizarlo. Para ello el Content Provider dispone de los tres mtodos siguientes: e updateOrAddElement(id, x, y, z) Si no existe el elemento con este id, este es creado guardndose en l las a e coordenadas (x, y, z). En caso de existir ser actualizada su posicin. a o updateOrAddProperty(id, property, value) Si en la entidad con el id especicado no existe esta propiedad, es insertada. En caso contrario ser modicada con el nuevo valor. a deleteElement(id) Eliminamos la entidad id.

78

Content Provider A continuacin describimos los mtodos accesibles en el Content Provider, o e al igual que en el servicio web, se dispone de una interfaz llamada DataGetter que dene los siguientes mtodos: e

getEntities(x, y, z, radius, types) Obtenemos en una lista de EntityData con todas las entidades de los tipos incluidos en la List types. Estos deben estar dentro del radio respecto a la posicin indicada. o Ese radio ser calculado respecto a las coordenadas x e y, la coordenada a z tiene que ser igual en la entidad. El elemento tiene que estar entre ((x radius/2) AND (x + radios/2)) AND ((y - radius/2) AND (y + radius/2)) getId(type, value) Devuelve el id unico para la entidad que tenga una propiedad cuyos cam pos sean Property = type y Value = value. Si hay ms de una entidad a con esa misma propiedad devuelve la primera de ellas (la primera se corresponde con el elemento ms antiguo). En caso de que no exista en la a base de datos ningn elemento con esta propiedad devolver -1. u a String getPropertyValue(id, propertyName) Devuelve la propiedad propertyName de la entidad id. getPropertiesValue(id, propertiesName); Similar al anterior solo que ahora devuelve una coleccin de Propiedades o de la entidad id. En propertiesName ir una lista con los nombres de cada a propiedad que queremos recibir. La coleccin es un Map(propiedad, valor). o getAllProperties(id); Obtenemos todas las propiedades de la entidad id en un Map (propiedad, valor). getAllIds(typeProperty) Devolvemos una lista con los ids de los elementos cuya propiedad tipo se corresponda con Property = TYPE y Value = typeProperty

Implementacin del Servicio Web o El servicio web ha sido desarrollado tanto en el servidor como en el cliente. En los siguientes apartados hablaremos sobre su implementacin. o Integracin en el servidor o Para el servidor se ha implementado un servicio web RESTful con soporte a persistencia. Este tipo de servicio da soporte a las siguientes operaciones que pueden ser realizadas contra la tabla de una base de datos (operaciones CRUD): 79

create, read, update y delete. El servidor no procesa ningn tipo de lgica sobre u o los datos que contiene. Se limita a servir consultas y procesar modicaciones a travs de las operaciones anteriores. e El servicio web ha sido creado con NetBeans 6.9. Para ello en NetBeans hemos establecido una aplicacin web utilizando el servidor GlassFish 3.1 y Java o EE 6; a sta le aadimos una unidad de persistencia con una base de datos e n MySql 5.1 externa donde se almacenan todos los datos. Las clases generadas en el servidor se dividen en los siguientes paquetes: look : contiene las clases con la representacin de cada una de las tablas de o la base de datos. Main, Properties y PropertiesPK (para identicar la clave primaria de Properties). Se generan una serie de Queries para poder realizar bsquedas sobre las mismas y las anotaciones de relacin u o necesarias para vincularse. service: contiene los servicios web generados y el servicio de persistencia que tiene el acceso al entityManager, que da acceso a la unidad de persistencia. Se crearn dos servicios web por cada entidad, para trabajar con a el listado de entidades y con una entidad individual, y estarn anotadas a con el soporte de jax-ws necesario para que los servicios sean publicados correctamente. converter : contiene un conversor para el servicio web, que es quien hace uso del mimo. Los conversores estn anotados con jaxb y dan el soporte a necesario para la serializacin de ojetos a xml json y viceversa. De este o o modo, cuando se solicita un dato se obtiene la entidad que lo representa y esta es convertida a xml json para su devolucin. La conversin de xml o o json a objeto se realiza en las modicaciones e inserciones, puesto que lo que recibe el servicio web es un xml json que debe ser convertido a entidad para persistirlo.

Acceso a los datos del Servidor Las entidades, al igual que en un Content Provider son identicadas mediante URIs. Una URI es necesaria para poder acceder al recurso en el servidor, y estos se identican con la clave primaria de las entidades. Hay dos tipos de URIs, cada entidad debe tener su propia URI con una apropiada representacin. Adems, la coleccin de recursos es otro recurso. o a o La URI Base de nuestro framework es: "http://serverip/LookServer/resources/" Donde serverip es la direccin IP del servidor, junto con el puerto para la coo nexin, /LookServer la direccin con la aplicacin web y /resources donde se o o o almacenan los recursos.

80

Esta se corresponde con la URL de nuestro servidor y es congurable por el framework con el mtodo setServerURL(String URL) de la clase CongNet. e Representacin de la URI para la consulta de las entidades: o entidad main: Coleccin de recursos de todas las entidades de main o "http://serverip/LookServer/resources/mains/" Entidad 100 de main "http://serverip/LookServer/resources/mains/100" entidad properties: Coleccin de recursos de todas las entidades de proo perties "http://serverip/LookServer/resources/propertiess/" Entidad 103,name de properties "http://serverip/LookServer/resources/propertiess/103,name"

Para almacenar objetos en la base de datos se debe proveer la URI de la coleccin de recursos, en nuestro caso: o Entidad main "http://serverip/LookServer/resources/mains/" Entidad properties "http://serverip/LookServer/resources/propertiess/"

Integracin en el Cliente o Para el desarrollo de RESTful en el cliente implementamos un servicio en Android. El servicio se encarga de procesar la comunicacin entre cliente-servidor, o este se ejecutar de forma automtica en segundo plano y sin depender de nina a guna activity. A grandes rasgos, segn la gura 6.13 podemos aanir / actualizar elementos u n del mundo o hacer peticiones de estos. Para aadir / actualizar un elemento se har una llamada al servicio, el cual n a est conectado con el servidor mediante REST Method, el servidor al recibir a el elemento enviar una respuesta que recoge el servicio, procesa y devuelve a al ServiceManager que devolver como CallBack 4 a la actividad o clase que a envi la llamada. o En caso de solicitar un elemento, se pedir al ContentProvider siendo dea vuelto directamente por este. El contenido del ContentProvider ser actualizado a por el servicio para respetar la coherencia con el servidor.
4 Un

CallBack se reere a una respuesta a la solicitud enviada por una activity / clase

81

Figura 6.13: Arquitectura del mdulo de datos en el servidor o En el prximo cap o tulo entraremos en detalle con la persistencia de la estructura de datos. A continuacin detallamos cada una de las partes de la arquitectura de acceso o a datos en el cliente: ServiceManager Clase Singleton as ncrona a la que se accede en primer lugar. Esta comienza el servicio si este no estaba activo, establecer su conexin y lo para en caso de o estar inactivo. Adems tiene una lista de CallBacks y se encarga de manejar las respuestas a a la activity o clase que gener la llamada al servicio. o Para capturar una CallBack es necesario crear un Handler 5 dentro de de la clase donde ser llamado el servicio e informar al servicio sobre el Handler a activo. Cdigo para crear el Handler que captura la CallBack devuelta por Serviceo Manager: Handler mHandler = new Handler ( ) { public void handleMessage ( Message msg ) { switch ( msg . what ) {
5 Un

Handler es una clase de Android que se encarga de enviar o recibir mensajes

82

// s e l e c c i o n a m o s l a C a l l B a c k a c a p t u r a r , // puede h a b e r v a r i a s d i s t i n t a s . case ACTION CALLBACK 1 : // procesamos l a C a l l B a c k processCallBack ( ) ; break ; default : super . handleMessage ( msg ) ; } } }; Cdigo para informar al servicio sobre el Handler activo: o LookData . g e t I n s t a n c e ( ) . g e t S e r v i c e M a n a g e r ( ) . s e t H a n d l e r ( mHandler ) ;

LookService Esta clase representa el Servicio de Android encargado de pedir los datos al servidor y procesar las respuestas recibidas por este. Cuando recibe la solicitud por parte del ServiceManager, comienza el correspondiente Rest Method (doPost, doPut, doGet, doDelete). Adems recoge la respuesta, la procesa e invoca en el ServiceManager la a nueva CallBack. Para que las respuestas se env en orden por el ServiceManaen ger se guardan en una cola donde se irn desapilando segn se vayan procesando. a u Ese necesario para que los mtodos del servicio sean accesibles desde cuale quier aplicacin fuera del framework, hay que denir los mtodos de este mediano e te una interfaz AIDL6 . Nuestro servicio dispone de dos, una para las peticiones con los mtodos de acceso al servicio web (DataSetter) y otra con los mtodos e e para cada tipo de CallBack (IRemoteServiceCallBack). Cuando hacemos una llamada al servicio web se inicializa en un nuevo thread, para no interrumpir la aplicacin. Adems si se desea se puede mostrar un o a mensaje en pantalla mientras se espera la respuesta con las clases de Android ProgressDialog o ProgressBar Para activar el servicio es necesario incluir en el manifest de cada aplicacin o este cdigo: o <service android:enabled="true" android:name=".data.restful.LookService"></service>
6 (Android

Interface Denition Language) http://developer.android.com/guide/developing/tools/aidl.html

83

Rest Method Esta clase contiene los mtodos de las operaciones bsicas para el env y e a o respuesta de las entidades mediante HTTP : doGet(url) Elimina un recurso (direccin url). o doPost(url, json) Inserta el recurso json en la url indicada. doPut(url, json) Actualiza un recurso con el archivo json enviado doDelete(url) Elimina el recurso. Las respuestas de los mtodos son decodicadas y encapsuladas en un nuevo e objeto json

Transmisin de objetos entre el cliente-servidor o Los datos transmitidos por la red desde el servidor a la base de datos del cliente (o viceversa) pueden representarse tanto en XML como en objetos JSON 7 , aunque en nuestro framework hemos usado solamente JSON por comodidad, ya que Android implementa las librer para su tratamiento. as Un objeto JSON es una coleccin de pares nombre/valor. El formato de los o JSON usados para tratar las tablas del servidor es el siguiente: // formato JSON de un r e g i s t r o de l a t a b l a p r o p e r t i e s properties : { p r o p e r t i e s P K : { i d : x , p r o p e r t y : xxx } , v a l u e : xxx } // formato JSON de un r e g i s t r o de l a t a b l a main main : { i d : x , x : xx , y : xx , z : xx }

6.4.

Otras fuentes de datos: Archivos binarios

Los archivos usados por las aplicaciones como objetos 3D o las imgenes no a son almacenadas en la base de datos, en estas solamente tendremos el nombre de estos o su ruta relativa a una URL base. Para optimizar el uso de la red, disponemos de un administrador de archivos representado en la clase LookFilesManager. Cuando solicitemos un archivo con la ruta descrita en la base de datos primero comprobamos si existe en el sistema de cheros del dispositivo (carpeta
7 Formato

de intercambio de objetos alternativo a XML, http://www.json.org/

84

local dentro del dispositivo), en caso contrario el administrador de archivos se conecta a la URL con la direccin del recurso y lo almacenar en la carpeta o a local. Para acceder a los archivos remotos se realiza una conexin mediante uno de o a estos protocolos 6.4.1 a una URL, usando URLConnection y sern descargados uno a uno a una carpeta local, tratando esta como una cache de archivos. En caso de que una entidad sea modicada o eliminada del servidor, cuando actualicemos el cliente comprobaremos si esta incluye la ruta de objetos (archivos) en sus propiedades y de ser as si el archivo est almacenado en la carpeta , a local ser eliminado; y no volver a estar en el dispositivo hasta que no sea a a solicitado de nuevo.

6.4.1.

Administrador de archivos

El administrador de archivos usa la clase implementada por Android URLConnection para obtener un archivo desde una URL sin necesidad de conocer de antemano su tipo o longitud. La URL se congura desde la aplicacin con el mtodo setFilesURL(String o e URL) de la clase CongNet. Esta se puede congurar con cualquiera de estos protocolos: File Los recursos pueden ser cargados desde el sistema local de archivos usando URIs. Estos solamente pueden ser le dos. FTP Tambin es aceptado el protocolo FTP, las conexiones pueden ser e usadas para entrada o salida de datos pero no ambas a la vez. Por defecto, las conexiones FTP sern hechas usando anonymous como nombre de a usuario y dejando el campo de contrasea vac Para especicar esto hay n o. que seguir la siguiente estructura en la URL: ftp://username:password@host/path. HTTP y HTTPS Se puede hacer referencia mediante las subclases HttpURLConnection y HttpsURLConnection. Tambin es aceptado al crear e una URL con el prejo http:// o https://. Jar Hace referencia a la subclase JarURLConnection. Mediante el siguiente ejemplo se muestra como descargar amos una imagen a nuestro dispositivo: URL u r l = new URL(MyURL) ; URLConnection u r l C o n n e c t i o n = u r l . openConnection ( ) ; InputStream i n = new B u f f e r e d I n p u t S t r e a m ( urlConnection . getInputStream ( ) ) ; l e e r I m a g e n ( readStream ( i n ) ) ; } Esta clase soporta un timeout para la conexin y otro la lectura del archio vo, si las capturamos evitamos un error un fallo en la conexin. Adems con o a 85

IOException nos aseguramos que no ha habido una incoherencia en los datos e intentamos descargar un archivo no existente.

6.4.2.

Optimizaciones del administrador de cheros

Almacenamiento en la tarjeta SD La carpeta /Look mencionada antes la creamos directamente en la tarjeta SD: public static final String directorySD = Environment .getExternalStorageDirectory() + "/Look/"; Compresin de imgenes Mediante el siguiente cdigo guardamos las o a o imgenes en la SD comprimidas, para optimizar ms an el espacio. a a u bitmap.compress(Bitmap.CompressFormat.JPEG, 90, out); //90% de calidad respecto a la original Organizacin por tipos de archivo La carpeta ra usada es /Look, a o z partir de esta creamos para cada tipo de archivo una diferente, para asegurarnos que tenemos los datos organizados adems de permitir nombres a iguales para distintos tipos de archivo (por si extendisemos el framework e a algo como archivos tipo foto y tipo avatar). La carpeta se incluye en la ruta guardada por la base de datos y en la URL remota. Las URL de los archivos tambin estn estructuradas, por ejemplo, las e a imgenes en Look! Social estn almacenadas en: a a public static final String imageURL = "http://www.lookapp.es/look/images/"; NOTA: Actualmente nuestro framework dispone de dos tipos de archivo, objetos 3D e imgenes. Aunque por ahora solamente tratamos de esta manera a a las imgenes. Los objetos 3D al ser muy pocos estn incluidos en el .apk. a a

86

Cap tulo 7

Mdulo de Realidad o Aumentada

En este cap tulo se detalla el sistema de capas de representacin de realio dad aumentada utilizado en Look!. En primer lugar se da una visin global del o mdulo completo, con todas las capas que lo conforman y su distribucin. A o o continuacin, se entra en detalle en cada una de las capas. o Primero, la capa de visualizacin 3D, con algunos fundamentos y consideo raciones de OpenGL, el sistema de entidades 3D seguido para la creacin de o elementos, procesado de texturas y mallas en formato *.obj, y la integracin o con la cmara. a Despus, la capa de dibujado 2D, cmo se dibujan los elementos en ella, y e o cmo se calculan las proyecciones de posiciones en tres dimensiones a coordeo nadas de pantalla en dos dimensiones. Se introduce el sistema de animaciones y las interacciones de usuario. Finalmente, se especica la Capa HUD y su funcionamiento.

7.1.

Visin general del sistema de capas: Looo kAR

Look! dene cuatro capas, de abajo a arriba: cmara, 3D, 2D y HUD. La a inclusin o no de cada una de estas capas es congurable para todas las aplicao ciones. Todo el sistema de capas se encuentra implementado en la Acitivity LookAR. Para Android una Actitvity es un proceso con una interfaz grca. Similar a una a ventana en un sistema de escritorio. As en trminos Android, LookAR es una actividad preconstru que con, e da tiene todas las capas que hayan sido conguradas en su creacin, superpuestas o en el orden que muestra la gura 7.1. En su creacin, tambin pueden ser cono e gurados otros parmetros, como si se desea que la actividad se muestre en a pantalla completa, o la mxima distancia a la que los objetos sern visibles a a para el usuario.

87

Figura 7.1: Situacin de capas de representacin en Look! o o Estas capas son creadas vac y debern ser provistas de elementos a ser as, a representados, ya sea desde el mdulo de datos, a elementos grcos aadidos o a n de manera programtica, por ejemplo en las capas de HUD. a

Figura 7.2: Diagrama de clases de los mdulos de Realidad Aumentada. o Como puede apreciarse en la gura 7.2, las capas de realidad aumentada tienen como base vistas de Android. LookAR es el mdulo completo que agreo ga cada una de las capas. Preview se corresponde con el mdulo de cmara, o a el visualizador 3D se implementa mediante una GLSurfaceView, el visualizador 2D, AR2D, es una View personalizada, el mdulo contenedor del HUD se o corresponde con un FrameLayout.

7.2.

Capa 3D

La capa 3D es la encargada del renderizado de la representacin 3D de las o entidades. Como se explic en el apartado de tecnolog Look! utiliza OpenGL o as, ES 1.1 para renderizado en tres dimensiones, a travs de la vista GLSurfaceView e

88

de Android. GLSurfaceView necesita un Renderer. Renderer es una interfaz de Android que dene, entre otros, el mtodo de dibujado que ha de ejecutarse en la vista. e En Look!, esta interfaz es implementada por la clase Renderer3D.

Figura 7.3: Relacin de GLSurfaceView con Renderer3D o

Tanto el dibujado 2D como el 3D se hace recorriendo la lista de WorldEntity proporcionada por un contenedor World. Como se detall en secciones anterioo res, las entidades WorldEntity contienen un Drawable3D. Drawable3D es una interfaz que dene un unico mtodo draw( GL10 gl). Este mtodo es utilizado e e en la renderizacin 3D de la entidad. o Una WorldEntity no tiene por qu denir una representacin 3D (o 2D) cone o creta. En caso de no tenerla, se ignora y se pasa a la siguiente entidad.

89

7.2.1.

Consideraciones con OpenGL ES 1.1

Antes de pasar a la jerarqu de clases utilizada, unas breves anotaciones a resultado de la experimentacin con esta versin de OpenGL ES. o o OpenGL ES 1.1 est basada en la versin 1.5 de la versin de escritorio de a o o OpenGL, sin embargo, existen diferencias fundamentales en cmo se realizan o algunas de las tareas en cada una de las versiones: Dibujado de primitivas: Por cuestiones de eciencia, OpenGL ES 1.1 carece de las primitivas glBegin() y glEnd() para el dibujado de primitivas. El dibujado se hace a partir de buers que previamente alberguen los datos a dibujar (vrtices, normales y coordenadas de texturas). Esta disposicin e o diculta la modicacin de vrtices concretos en tiempo de ejecucin. o e o Clases de primitivas: OpenGL ES 1.1 slo permite el dibujado de puno tos, l neas y tringulos. No de cuadrilteros y pol a a gonos, como en su versin o de escritorio. Modo seleccin: En la versin de escritorio, existe un modo de renderio o zado (llamado de seleccin), que permite extraer el objeto asociado a uno o o varios p xeles de la pantalla. En este modo, cada p guarda informaxel cin sobre el objeto del que forma parte, haciendo muy sencillo a posterori o la identicacin de los elementos asociados a un p cualquiera. OpenGL o xel ES 1.1 carece de este modo, por lo que se necesitan mtodos adicionales e para la identicacin de objetos pulsados. o

7.2.2.

Proyeccin de elementos de coordenadas reales a o coordenadas OpenGL

Look! utiliza la proyeccin perspectiva en su representacin 3D. Esta proo o yeccin, computa la distancia de los objetos hasta la cmara, y los escala acorde o a a ella, provocando sensacin de profundidad. o Para la colocacin de los objetos, se han tomado escalas relativas medidas o en metros. As si un objeto se encuentra en la posicin (1, 5, 2), se encuentra , o en el punto situado a un metro al norte, cinco metros de altura y dos metros hacia el este. Esta situacin es denida en relacin al origen de coordenadas del mundo, o o que es denido por el usuario, y que debe ser situado antes de la colocacin de o cualquier elemento. Este origen no est contenido de manera expl a cita en ningn u mdulo de Look!. Slo es un punto orientativo que el programador debe utilizar o o cundo localice elementos. a

7.2.3.

Situacin de la cmara o a

El framework provee en el paquete es.ucm.look.ar.ar3D.core.camera dos clases que implementan las funciones de cmara necesarias en la realidad aumena tada.

90

Camera3D: Una cmara esttica. Ofrece funciones para cambiar su poa a sicin, as cmo las operaciones pitch, rool y yaw. o o OrientedCamera: Derivada de la anterior, utiliza el proveedor de orientacin DeviceOrientation para reajustar de manera dinmica su orientao a cin acorde a la posicin actual del dispositivo mvil. o o o

7.2.4.

Caracter sticas OpenGL soportadas por Look!

A d de hoy, Look! implementa las siguientes caracter a sticas 3D: Iluminacin: Puede congurarse si los elementos estn iluminados (hao a ciendo uso de iluminacin por vrtice, basada en normales) o no (shao e deless), dnde el objeto se dibuja con el material seleccionado, sin verse o afectado por la iluminacin. o Texturas: Pueden aplicarse texturas a aquellos elementos que tengan denidos coordenadas de textura. Estas texturas son creadas de manera automtica y transparente para el programador, a partir de una direccin a o de chero o un identicador de recurso, que es asignado a una representacin 3D de una entidad. Las texturas se generan automticamente con o a la la factor TextureFactory. a Transformaciones anes: Los elementos pueden denir traslaciones, rotaciones y escalas propias, que sern tenidas en cuenta durante el renderia zado. La clase Matrix3 guarda la matriz de transformacin del elemento, y o provee de mtodos comunes de transformaciones, eliminando la necesidad e de hacer llamadas expl citas a las funciones de transformacin de OpenGL o (glTranslate, glRotate, glScale). En las siguientes secciones, se detallan estas caracter sticas.

7.2.5.

Dibujado de entidades: Entity3D

La clase Entity3D implementa Drawable3D y ofrece las funcionalidades bsia cas enumeradas en el apartado anterior. Algunos de sus atributos: Matriz de transformacin: La clase Matrix4 representa una matriz o de 16x16, utilizada para guardar las transformaciones anes (traslaciones, rotaciones y escalaciones) de la entidad 3D. Esta clase contiene mtodos e para generar estas transformaciones. Material: Se considera como material el color que ser utilizado cundo a a las caras de esta entidad sean renderizadas. Color4 es una clase que contiene las cuatro componentes de color: rojo, verde, azul y transparencia. Mesh3D: De forma recursiva, Mesh3D es un Drawable3D. Contiene los vrtices y las normales de una malla. Tras ser establecidos las transformae ciones, el color y la textura, Entity3D procede a dibujar esta malla.

91

Figura 7.4: La clase Entity3D y sus componentes

7.2.6.

ObjMesh3D: cargando mallas desde archivos .obj Wavefront

ObjMesh3D es una clase heredada de Mesh3D, la clase que dene una malla de manera general. ObjMesh3D representa un tipo de malla que se construye a partir de un archivo OBJ. OBJ es un formato de denicin de mallas 3D, desarrollado originalmente o por Wavefront Technologies 1 . Dene los objetos 3D en forma de texto, de una manera sencilla y fcilmente procesable. a Un archivo obj tiene el siguiente aspecto: v 1.000000 1.000000 0.000000 v 1.000000 -1.000000 0.000000 v -1.000000 -1.000000 0.000000 v -1.000000 1.000000 0.000000 vt 0.000000 0.000000 vt 1.000000 0.000000 vt 1.000000 1.000000 vt 0.000000 1.000000 vn 0.000000 0.000000 1.000000 f 1/1/1 4/2/1 3/3/1 f 1/1/1 3/3/1 2/4/1 Este archivo est deniendo un cuadrado de lado 2, centrado en el origen. Dea pendiendo del prejo que se encuentre al inicio de cada l nea, los nmeros subu siguientes representarn cosas distintas: a
1 http://www.wvfront.com/

92

Figura 7.5: Diagrama de secuencia del dibujado 3d v: representa un vrtice, formado por sus tres coordenadas x, y y z. e vt: representa las coordenadas x e y de una textura. vn: representa un vector normal. f : representa una cara de la malla. Cada uno de las triplas que lo siguen representa un vrtice de la cara. Este vrtice est formado por tres come e a ponentes: la primera es el ndice del vrtice; la segunda, el e ndice de la textura; y la tercera, el ndice de la normal. Siendo el ndice el nmero de u orden con el que apareci en el archivo. o Esta clase de archivos pueden ser generados por la mayor de programas a de modelado 3D, como 3D Max, Blender, o Maya. El unico requisito a tener en cuenta en la exportacin de *.obj es que las caras se exporten en forma de o tringulos. a En la construccin de un objeto ObjMesh3D, se denir el archivo OBJ o a que debe ser cargado en la malla, y automticamente, la clase MeshObjParser a procesar este archivo y crear una malla renderizable por Look!. a a

7.2.7.

Creacin de texturas: TextureFactory o

Para el rellenado de primitivas, OpenGL utiliza dos cosas: colores y texturas. Para la generacin de texturas, se utiliza la clase TextureFactory. Esta clase, que o implementa el patrn Singleton, ejerce como cach de identicadores de texturas o e OpenGL.

93

Figura 7.6: Clase TextureFactory Fundamentalmente, ofrece dos mtodos para la creacin de texturas: e o Textura a partir de un recurso local: Est mtodo recibe un recurso e e contenido en la aplicacin, cuyo identicador queda denido en los archivos o autogenerados R.drawable, y devuelve la textura OpenGL asociada. Textura a partir de ruta: Recibe la ruta completa de un archivo de imagen y crea la textura OpenGL. Nota: Para evitar problemas de compatibilidad entre dispositivos, las dimensiones de las imgenes utilizadas en la creacin de texturas deben ser potencias a o de dos.

7.2.8.

Funcionalidades geomtricas y colisiones e

En algunas aplicaciones, puede resultar benecioso incorporar caracter sticas como colisiones, o clculos de interseccin entre elementos u objetos. a o Cmo caracter o stica adicional, en el paquete es.ucm.look.ar.math se ofrecen algunas funcionalidades relacionadas con el mbito de la geometr y la f a a sica de colisiones. El paquete es.ucm.look.ar.math.geom ofrece clases para realizar operaciones geomtricas comunes en el espacio tridimensional: operaciones vectoriales, opee raciones matriciales, intersecciones de rayos e intersecciones de esferas. El paquete es.ucm.look.ar.math.collision (Figura 7.8) ofrece un esqueleto bsico para denicin de armaduras en elementos, y mtodos para decisin de a o e o intersecciones con rayos. Armature dene una interfaz general que est asociada a objetos en tres dia mensiones (como Entity3D). Tiene mtodos para decidir si un punto est cone a tenido dentro de la armadura, en que punto interseca un rayo, o si el rayo interseca. Como clase base se ofrece SphericalArmature. Representa una armadura esfrica que recubre un objeto en tres dimensiones, y dene los mtodos exie e gidos por la interfaz. Nota: En la carga de mallas desde archivos *.obj se crean tambin parmee a tros para la denicin de una armadura esfrica para el objeto cargado, calo e culando el punto central de la malla y el radio m nimo que contiene a toda la gura.

94

Figura 7.7: Contenido del paquete es.ucm.look.ar.math.geom

7.3.

Integrando cmara y 3D a

En Look! la capa de cmara esta representada por la clase Preview. a La capa est preparada para adaptarse a todo tipo de pantallas y autocona gurarse sin necesidad de parmetros adicionales, as como para reaccionar ante a los cambios de orientacin del dispositivo. o Para que la capa pueda funcionar adecuadamente, ha de aadirse la siguiente n l nea de cdigo al maniesto de la aplicacin (AndroidManifest.xml ): o o <uses-permission android:name="android.permission.CAMERA" /> Para utilizar determinadas funciones ofrecidas por el sistema operativo, cmo o el acceso a servicios de red, o la cmara, Android dene una serie de permisos a que el usuario debe conceder (o no) cundo instala la aplicacin. a o Con esta l nea incluida en el maniesto, si el usuario accede a ello durante la instalacin, la aplicacin tendr acceso a la cmara, y la capa Preview o o a a funcionar conforme a lo previsto. a Tanto la cmara como la representacin en tres dimensiones estn implea o a mentadas sobre la clase Android SurfaceView. Desde Android se recomienda no superponer SurfaceView s, por posibles problemas de compatibilidad. Sin embargo, actualmente no existe otra manera de combinar 3D e imgenes de la a cmara. a 95

Figura 7.8: Contenido del paquete es.ucm.look.ar.math.collision Para no aadir problemas adicionales, aunque desde la documentacin ocial n o se recomienda utilizar una SurfaceView para dibujado 2D personalizado, se ha optado por utilizar una View personalizada. Uno de los pasos ms problemticos de la interfaz de Look! ha sido la integraa a cin de cmara y 3D. La documentacin ocial de Android no especica nada o a o al respecto, y la propia integracin contradice la advertencia de Android en no o intentar superponer ms de una SurfaceView sobre otra. a An as la experimentacin de las diferentes posibilidades ha llevado a una u , o solucin que parece funcionar en la mayor de dispositivos. A continuacin, se o a o muestra un fragmento del cdigo de la creacin de capas por su especial inters: o o e if (uses3D) container.addView(glSurface); if (usesCamera) container.addView(preview); Es importante notar que el mtodo addView aade una vista encima de las que e n ya contuviera. As en este fragmento de cdigo se aade la vista de cmara , o n a sobre la vista 3D, y el resultado, aunque el resultado esperado pudiera ser otro, es una superposicin de la vista 3D sobre la cmara. o a Este orden de adicin de capas es el utilizado por algunas de las aplicaciones o de realidad aumentada utilizadas como referencia23 .
2

http://code.google.com/p/andar/

3 http://www.mixare.org/

96

7.4.

Capa 2D

En la siguiente seccin se detalla las funcionalidades contenidas en Look! o para la representacin en dos dimensiones de las entidades contenidas en el o mundo.

7.4.1.

Canvas vs Proyeccin Ortogonal en OpenGL o

A la hora de hacer dibujado en dos dimensiones, se nos presentaban dos posibilidades bien diferenciadas: utilizar la API 2D de dibujado (implementada por la clase Canvas) ofrecida por Android en todas sus vistas, o utilizar la proyeccin ortogonal para dibujado en 2D OpenGL, opcin utilizada en muchos o o juegos y aplicaciones 3D. En Look! se ha optado por utilizar la clase Canvas y la API 2D que ofrece, por las siguientes razones: Funcionalidad: El Canvas Android ofrece una rica cantidad de funciones: dibujado de formas (c rculos, rectngulos, l a neas), de textos, imgenes. a Funciones de transformacin (escalaciones, rotaciones, traslaciones), funo ciones de colores y estilos. Por lo ya explicado en secciones anteriores, muchas de estas tareas requieren de una complejidad excesiva en OpenGL ES, y otras son directamente inviables, como el dibujado de texto. As , respecto a funcionalidad 2D ofrecida, el Canvas parece la mejor opcin. o Eciencia: La renderizacin a travs de la GLSurfaceView es ms costosa o e a que a travs del Canvas. Adems, en el framework, todas las capas son e a opcionales. As podr quererse una aplicacin que slo usara represen, a o o tacin en dos dimensiones. Utilizando en esta capa el Canvas, tenemos el o mtodo ms eciente y apropiado. e a

7.4.2.

SurfaceView vs. View personalizada

En la documentacin ocial de Android se sugiere que para el dibujado en dos o dimensiones personalizado, cmo el utilizado en videojuegos u otras aplicaciones o interactivas similares, se ha de utilizar una SurfaceView y un hilo aparte para manejar las actualizaciones. Sin embargo, tambin desde la documentacin de Android, se sugiere que e o no sean superpuestas ms de una SurfaceView sobre otra. En este punto, ya a tenemos denidas dos capas en SurfaceView s: la de la cmara y la capa de a representacin en tres dimensiones. o Diferentes pruebas de posibles superposiciones de SurfaceView s, variando el orden de adicin a la capa base, o congurando los parmetros de transparencia o a de cada uno de ellas, han mostrado comportamiento errticos en distintos dispoa sitivos. Y en todos ellos, los cambios de orientacin del dispositivo provocaban o la desaparicin de al menos una de las capas, normalmente la cmara o el 3D. o a

97

En consecuencia y para intentar mantener la mayor compatibilidad posible, la capa de representacin en dos dimensiones ha sido implementada en una o View de Android personalizada. Se ha sobreescrito el mtodo de dibujado y e se ha creado un TimerTask que ejecuta el refresco de la vista tras un tiempo determinado. La experimentacin y las pruebas han demostrado que, en trminos de ecieno e cia, esta solucin ofrece un rendimiento similar al que ofrecer una SurfaceView. o a

7.4.3.

Dibujado 2D

El dibujado en dos dimensiones (Figura 7.9) se realiza en la clase AR2D y sigue un esquema parecido al dibujado en tres dimensiones. En tres dimensiones, la proyeccin de los elementos es realizada automtio a camente por OpenGL. En dos dimensiones, sin embargo, hay que realizarla a mano. Es lo que realiza el primer bucle del diagarama de secuencia. Cmo se o calcula la proyeccin se explicar despus. o a e Una vez proyectados los elementos, tenemos una lista ordenada con todos las entidades proyectadas. Se hace un recorrido por todas ellas y, despus de e realizar las transformaciones de posicin y escala debidas a la proyeccin, se o o dibuja su Drawable2D, si lo tuviere. Proyeccin en dos dimensiones o An siendo una representacin en dos dimensiones, las entidades del munu o do se encuentran situadas en localizaciones en tres dimensiones. Necesitamos proyectar esas coordenadas de 3D a coordenadas 2D. Es de lo que se encarga el mtodo projecEntities de la clase AR2D. La proyeccin se realiza con las e o siguientes frmulas: o xproyectada = distancia xoriginal /zoriginal yproyectada = distancia yoriginal /zoriginal zproyectada = zoriginal (7.1) (7.2) (7.3)

La variable distancia es un factor corrector dependiente del tamao de la n pantalla y del ngulo de visin denido. a o Adems, debemos encargarnos del control de profundidad. Primero han de a dibujarse los elementos ms alejados del usuario, as los ms cercanos quedarn a a a superpuestos sobre ellos. Por ello, tras realizar la proyeccin de los elementos, o se realiza una ordenacin conforme a su coordenada z proyectada. o Despus, los dibujamos conforme al orden establecido, y adems utilizamos e a ese valor para escalar el elemento, conforme a la distancia que se encuentre del usuario, dando as una mayor sensacin de realismo. o

98

Figura 7.9: Diagrama de secuencia del dibujado en dos dimensiones

7.5.

Animaciones

Las representaciones en dos y tres dimensiones admiten animaciones a travs e del mtodo update, que es invocado con el tiempo, en milisegundos, que transe curri desde la ultima actualizacin. o o El mtodo es invocado antes del dibujado del elemento, y est pensado para e a que, en su implementacin, actualice el estado del elemento, creando as las o animaciones. El estado del elemento puede ser muy variado, desde la rotacin de una malla o 3D que cambia con el tiempo, hasta la actualizacin del frame actual de una o serie de imgenes. a

99

7.6.

Interaccin del usuario o

Necesitamos interactividad en las aplicaciones de realidad aumentada desarrolladas, por ejemplo, para que se nos muestre un texto por pantalla cuando pulsemos un elemento, o que se aada una nueva entidad al mundo cundo n a pulsemos una tecla. Para ello, hemos de denir una serie de interacciones que puedan ser realizadas por el usuario. Adems de los eventos generales de teclado, que son procesados por las cada a una de las capas en su conjunto, se cuenta con una serie de interacciones que pueden ser realizadas sobre las entidades representadas en la realidad aumentada. Look! dene dos tipos: Tctiles: Reejadas en la interfaz TouchListener. Procesa los tres tipos a principales de acciones tctiles de pantalla: posar el dedo, levantar el dedo, a y mover el dedo por la pantalla. Cmara: Una accin de cmara es ejecutada cundo el usuario apuna o a a ta directamente con el centro del dispositivo a un elemento. Est accin a o est reejada en la interfaz CameraListener, que contemplados dos tipos a de eventos: que la cmara enfoque al objeto (onCameraEntered ) y que la a cmara salga del evento (onCameraExited ). a Para versiones futuras, se plantean otros tipos de interacciones, como por ejemplo acciones que se ejecutan por proximidad a objetos.

7.6.1.

Interaccin por teclado o

Para la interaccin por teclado, Look! se vale de los mtodos proporcionados o e por la vistas de Android. La clase View permite dos tipos de interaccin por teclado: reescribiendo el o mtodo onKeyPressed y jando el comportamiento deseado para cada una de e las teclas; o asignando un OnKeyListener 4 a la vista, que ser ejecutado cundo a a reciba un evento de teclado. Look! no ofrece ninguna funcionalidad adicional para este tipo de interaccin, o nativa en Android. Permite el procesamiento de teclado en cada una de las capas de realidad aumentada, pero esta debe ser aadida por el programador de la n manera habitual5 .

7.6.2.

Interaccin tctil o a

Antes de pasar al mtodo utilizado para decidir qu entidad recibe un evento e e tctil, cabe preguntarse, cundo, realmente, una entidad es tocada. a a En Look! una entidad es un elemento con una posicin, que puede tener o una representacin en dos dimensiones y/o tres dimensiones (o ninguna). Si o queremos denir eventos tctiles sobre l (pulsar el elemento en la pantalla del a e dispositivo y qu suceda algo), debemos decidir qu reas de la pantalla deben e ea ser pulsadas para lanzar esos eventos tctiles. a
4 Interface 5 Handling

OnKeyListener: http://developer.android.com/reference/android/view/View.OnKeyListener.html UI Events: http://developer.android.com/guide/topics/ui/ui-events.html

100

Recordemos, cmo se explic en el apartado 7.2 dedicado a la capa 3D, que o o OpenGL ES carece de modo de seleccin, lo que, en el caso de querer determinar o en la capa 3D a que objeto pertenece un p pulsado, obligar a crear algn xel a u tipo de sistema adicional para determinar el elemento seleccionado. Por ejemplo, se podr lanzar un rayo desde el punto dnde se toc la pantalla a o o hacia el mundo 3D, teniendo en cuenta la perspectiva y la distancia focal de la cmara para determinar la direccin correcta del rayo, y ver si colisiona con a o algn Armature. u En el paquete es.ucm.ar.math se ofrecen funcionalidades para montar un sistema basado en intersecciones, que puede ser util en algunos tipos de aplica ciones. Sin embargo, esta aproximacin es muy costosa a nivel de CPU, debido a o todos los clculos geomtricos requeridos. Para el caso general, se utilizar un a e a mtodo menos costoso y ms sencillo, inspirado en el modo de seleccin de la e a o versin de escritorio de OpenGL. o Buer de colores Todas las entidades tienen un identicador unico, representado por un entero. Ese identicador, puede ser convertido a un nmero hexadecimal, y a su vez, u ese hexadecimal, reconvertido a un color. En un bfer, del mismo tamao que la pantalla, cada uno de los elementos u n visibles dibujar su rea tctil (en la que, si el usuario pulsa, lanzar el evento a a a a tctil en el elemento) de un unico color, el obtenido a partir de su identicador. a (Figura 7.11). Cundo el usuario realice el evento tctil, se consultar en el bfer el color del a a a u p pulsado. Este color, por proceso inverso, ser convertido en el identicador xel a de la entidad. Se extraer la entidad del mundo a partir del identicador, y se le comunia car la realizacin del evento, para su posterior procesamiento. a o Todo el proceso de conversin de identicadores a colores y viceversa es o totalmente transparente para el programador, as cmo el pintado del bfer. o u El dibujado del rea tctil es realizado por el mtodo drawTouchableArea dea a e nido por WorldEntity. Por defecto, el rea tctil es un c a a rculo centrado en la posicin de la entidad. Su radio es calculado a partir de sus representaciones o grcas. En el caso del 3D, se suele utilizar el radio de la esfera que envuelve a a la malla, escalado por la distancia al usuario. Si se cuenta con una representacin en dos dimensiones, se suele utilizar como rea tctil el rea dibujada por o a a a Drawable2D.

7.6.3.

Interacciones de cmara a

Look! considera producida una interaccin de cmara cundo un elemento o a a de la realidad aumentada gana o pierde el foco de la cmara. a Esto signica que cundo un elemento ocupe el espacio central de la pantalla a del dispositivo, se considerar que ha recibido el foco del usuario. El elemento a ser noticado y l mismo ejecutar los listener s asociados al evento. a e a

101

Figura 7.10: Apariencia de la aplicacin en modo normal. Existen cuatro entio dades (cuatro imgenes) en cada una de las esquinas a

Figura 7.11: Apariencia del buer tctil de la aplicacin anterior. Pueden verse a o las cuatro reas tctiles, cada una de un color distinto (distintos tonos de azul) a a

102

Se consideran dos tipos de eventos: uno cundo el elemento gana el foco del a usuario; y otro cundo lo pierde. a Para el clculo del elemento que se encuentra en la posicin central del a o dispositivo, se usa el mismo mtodo que para la interaccin tctil, descrita en e o a el apartado anterior, slo que en vez de coger el color del p que devolvi el o xel o evento tctil, se selecciona el p a xel situado en el centro de la pantalla ( ancho de la pantalla / 2, alto de la pantalla / 2 ).

7.6.4.

HUD en 2D

Adems de la capa HUD, la capa 2D ofrece una semicapa adicional a la que a pueden ser aadidos elementos de HUD en dos dimensiones, que sern dibujados n a en la capa ms alta de la aplicacin, slo superadas por el HUD de vistas de a o o Android que se explicar despus. a e

Figura 7.12: Apariencia del buer tctil de la aplicacin anterior. Pueden verse a o las cuatro reas tctiles, cada una de un color distinto (distintos tonos de azul) a a Estos elementos implementan la interfaz HUDElement (Figura 7.12), que dene mtodos de dibujado, determinacin de si un punto se encuentra dentro e o de ellos y mtodos de procesamientos de eventos tctiles. e a Es una manera de dibujar elementos de HUD, aprovechando la potencia de la API 2D ofrecidas por el Canvas. Si por ejemplo, se quiere dibujar un c rculo en el centro de la pantalla, que nos que el punto exacto hacia dnde apuntamos con o el dispositivo, slo deber o amos aadir un HUDElement que dibujara el c n rculo a travs del mtodo addHUDElement de la clase AR2D. e e

7.7.

Capa HUD

Por ultimo, en la capa superior, encontramos la capa HUD, pensada para albergar todo los tipos de vistas ofrecidas por android. En esencia, esta capa es un contenedor (FrameLayout) a la que se pueden aadir View s de Android: botones, campos de texto, scrolls, etc. n Est pensada, por ejemplo, para aadir botones que produzcan acciones en a n la aplicacin. O textos que muestren datos concretos, como la posicin actual o o del usuario. 103

Tambin puede ser combinado con las interacciones de entidades. Por ejeme plo, mostrar un texto (en una TextView 6 ) concreto cundo una entidad reciba a el foco de la cmara, o mostrar una imagen (en una ImageView ImageView 7 ) a cundo se pulse un elemento. a

7.8.

Utilidades: LookARUtil

Adicionalmente, Look! ofrece una clase de utilidades relacionados con el mdulo de realidad aumentada que pueden ser utilizadas desde cualquier punto o del cdigo. Sus funciones son: o getApp: Devuelve el contexto LookAR de la actividad. Este contexto es necesario para lanzar ciertos mtodos, como por ejemplo los referidos a e cambios en la interfaz. getDisplay : Devuelve el Display de la aplicacin. Este objeto tiene inforo macin sobre el dispositivo sobre el que se esta ejecutando la aplicacin, o o como por ejemplo las dimensiones de la pantalla. makeFloatBuer( oat f[]): Crea un buer de oats a partir de un array de oats. Utilizado en la denicin de mallas 3D. o getView( int resource, ViewGroup view ): Construye la vista asociado al recurso pasado como parmetro. Se utiliza para crear vistas desde a archivos XML. getMinimumSize(): Devuelve el valor de la menor de las dimensiones de la pantalla.

6 http://developer.android.com/reference/android/widget/TextView.html 7 http://developer.android.com/reference/android/widget/ImageView.html

104

Cap tulo 8

Construyendo aplicaciones con Look!

En este cap tulo se pretenden exponer los pasos fundamentales para la creacin de aplicaciones utilizando el framework de realidad aumentada Look!. Prio mero se plantearn los pasos necesarios para denir la aplicacin a desarrollar, a o y despus los pasos en la codicacin de una aplicacin sencilla. e o o

8.1.

Planteando la aplicacin o

Antes de lanzarnos a programar nuestra aplicacin en Look!, debemos plano tearnos qu necesitamos hacer exactamente, y qu mdulos vamos a utilizar e e o para ello. No es lo mismo crear una galer de imgenes en tres dimensiones, a a que una aplicacin que nos site con un c o u rculo a otros usuarios en el espacio. Antes de empezar a programar, y con la funcionalidad de la aplicacin de o realidad aumentada detallada, el programador deber hacerse las siguientes a preguntas: 1. Qu tipos de entidades van a ser representadas en la realidad aumene tada. 2. Qu caracter e sticas denen estas entidades. 3. De dnde se obtienen esas entidades y sus caracter o sticas. Podr a accederse a un servidor remoto, si los datos cambian de manera dinmia ca; o albergarse de manera local, si no son susceptibles de cambios, o los datos no son compartidos. 4. Cmo se representarn grcamente. Pudiendo ser dos y/o tres dio a a mensiones. 5. Qu interacciones sern permitidas para cada entidad: e a Efectos al pulsar Efectos al arrastrar Efectos al soltar

105

Efectos al enfocar con la cmara a 6. Si queremos que aparezca de fondo la imagen obtenida por cmara. a 7. Si es necesario localizar al usuario para obtener la funcionalidad buscada. 8. Y de ser as qu tipo de localizacin ser la adecuada: Relativa, con , e o a el sistema inercial; O absoluta, con el sistema de localizacin WiFi. o 9. Qu sistema de referencia se utiliza para situar a los elementos y al e usuario. 10. Dnde est el origen de coordenadas del mundo. o a 11. Si se necesitan a adir elementos extras de interfaz (botones, mens, n u cajas de texto, Activitys secundarias, etc.) para completar la funcionalidad requerida. Una vez tomadas las decisiones, puede comenzar el desarrollo. En las siguientes secciones se resuelve el cmo abordar estos puntos con Look!. o

8.2.

Codicando una aplicacin bsica o a

En esta seccin se explican los pasos a seguir en la codicacin de una o o aplicacin sencilla con Look!. o Se da por supuesto que el lector tiene instalado el SDK de Android en su entorno de programacin, que sabe aadir bibliotecas externas (en este caso, o n Look! ) a nuevos proyectos Android, y que sabe instalar y ejecutar estos proyectos en dispositivos f sicos o en el emulador Android.

8.2.1.

Creando la Activity principal

Look! ofrece en la Activity LookAR el mdulo completo de realidad aumeno tada. El procedimiento habitual ser extender esta clase y realizar las inicialia zaciones pertinentes en el mtodo onCreate (el de creacin de la actividad). El e o constructor de LookAR tiene el siguiente aspecto: public LookAR ( boolean usesCamera , boolean uses3D , boolean uses2D , boolean usesHud , f l o a t maxDist , boolean f u l l s c r e e n ) Como puede observarse, sus parmetros de conguracin son mayoritariaa o mente booleanos que denen si la capa correspondiente de realidad aumentada debe ser aadida. n Tiene dos parmetros ms: maxDist, que dene la mxima distancia (medida a a a en el sistema de coordenadas jado por el programador) a la que una entidad ser visible; y fullscreen, que dene si la Activity es a pantalla completa, elimia nando la barra de tareas de Android. Normalmente, el cdigo de iniciacin de las Activity herederas seguirn el o o a siguiente esquema:

106

public c l a s s MyARActivty extends LookAR { public MyArActivity ( ) { super ( true , true , true , true , 1 0 0 . 0 f , true ) ; } @Override protected void onCreate ( Bundle s a v e d I n s t a n c e S t a t e ) { super . onCreate ( s v a e d I n s t a n c e S t a t e ) ; // I n i t e v e r y t h i n g }

} En esta caso, hemos denido una actividad que muestra todas las capas de realidad aumentada, incluida la camera, a pantalla completa y que muestra elementos a una distancia mxima de 100 unidades. a Recuerda que para que pueda mostrarse la cmara, ha de aadirse el siguiena n te permiso al maniesto de la aplicacin: o <u s e s p e r m i s s i o n android:name= a n d r o i d . p e r m i s s i o n .CAMERA /> Con este paso ya podr amos lanzar la Activity y entrar en la realidad aumentada. Pero an no ver u amos nada, aparte de la cmara de fondo, puesto que a no hemos denido ningn elemento para que sea mostrado. u

8.2.2.

Deniendo los elementos de la aplicacin: Entityo Data

Para mostrar entidades en la realidad aumentada, debemos aadir elementos n EntityData que puedan ser procesados y convertidos en WorldEntity. Modiquemos el mtodo onCreate de MyARActivity, para aadir un elee n mento: @Override public void onCreate ( Bundle s a v e d I n s t a n c e S t a t e ) { super . onCreate ( s a v e d I n s t a n c e S t a t e ) ; // C r e a t e t h e e l e m e n t d a t a EntityData data = new EntityData ( ) ; data . s e t L o c a t i o n ( 1 0 , 0 , 0 ) ; // Add t h e d a t a t o t h e d a t a h a n d l e r LookData . g e t I n s t a n c e ( ) . getDataHandler ( ) . addEntity ( data ) ; // Updates t h e r e c e n t added d a t a 107

LookData . g e t I n s t a n c e ( ) . updateData ( ) ; } Primero creamos un elemento vac y lo situamos en la posicin (10, 0, 0). o, o Despus, lo aadimos al mdulo de datos, y nalmente actualizamos para que se e n o muestren los cambios realizados. Si ahora ejecutamos, veremos que, tras orientar la cmara en la direccin adecuada, aparecer un cubo con un cuadro de texto, a o a que indica el identicador de la entidad y su tipo, en este caso null, puesto que no se deni la propiedad (Figura 8.1). o

Figura 8.1: Captura de la aplicacin tras aadir un elemento o n Esta apariencia es creada de manera automtica por la factor WorldEna a tityFactory, que es la que Look! instancia por defecto. Sin embargo, en nuestras aplicaciones querremos denir nuestras propias apariencias. Para ello deberemos implementar nuestras propias factor Worlas dEntityFactory.

8.2.3.

Deniendo factor de elementos as

Una factor de elementos, heredera de WorldEntityFactory, debe sobreesa cribir un unico mtodo: createWorldEntity(EntityData data). e Supongamos que nuestros elementos tienen una propiedad llamada name, que indica el nombre del elemento. Y una propiedad color, que indica su color. Queremos que, en su representacin, aparezca, en dos dimensiones, un texto con o el nombre del elemento, y en tres dimensiones, un cubo del color indicado por la propiedad. El cdigo para la factor ser el siguiente: o a a 108

public c l a s s MyWorldEntityFactory extends WorldEntityFactory { public s t a t i c f i n a l S t r i n g NAME = name ; public s t a t i c f i n a l S t r i n g COLOR = c o l o r ; @Override public WorldEntity c r e a t e W o r l d E n t i t y ( EntityData data ) { WorldEntity we = new WorldEntity ( data ) ; we . setDrawable2D ( new Text2D ( data . g e t P r o p e r t y V a l u e (NAME) ) ) ; Entity3D drawable3d = new Entity3D ( new Cube ( ) ) ; S t r i n g c o l o r = data . g e t P r o p e r t y V a l u e (COLOR) ; i f ( c o l o r . equals ( red )){ drawable3d . s e t M a t e r i a l (new Color4 ( 1 . 0 f , 0.0 f , 0.0 f ) ) ; } else i f ( c o l o r . equals ( green )) drawable3d . s e t M a t e r i a l (new Color4 ( 0 . 0 f , 1.0 f , 0.0 f ) ) ; // . . . we . setDrawable3D ( drawable3d ) ; return we ; } } Como vemos, primer creamos un WorldEntity que recibe como atributo el elemento con los datos. Despus denimos para su representacin en dos dimene o siones un texto, y para su representacin en tres dimensiones, un Entity3D que o contiene un cubo, y al que se la asigna un color, atendiendo al valor de la propiedad. Ahora debemos comunicarle a LookData qu factor debe utilizar para la e a creacin de entidades. As que aadimos el siguiente cdigo en el onCreate de o n o la aplicacin: o LookData . g e t I n s t a n c e ( ) . setWorldEntityFactory ( 109

new MyWorldEntityFactory ( ) ) ; // Cr e a t e t h e e l e m e n t d a t a EntityData data = new EntityData ( ) ; data . s e t L o c a t i o n ( 1 0 , 0 , 0 ) ; data . s e t P r o p e r t y V a l u e ( MyWorldEntityFactory .NAME, Element 1 ) ; data . s e t P r o p e r t y V a l u e ( MyWorldEntityFactory .COLOR, green ) ; EntityData data1 = new EntityData ( ) ; data1 . s e t L o c a t i o n ( 1 0 , 0 , 5 ) ; data1 . s e t P r o p e r t y V a l u e ( MyWorldEntityFactory .NAME, Element 2 ) ; data1 . s e t P r o p e r t y V a l u e ( MyWorldEntityFactory .COLOR, red ) ; // Add t h e d a t a t o t h e d a t a h a n d l e r LookData . g e t I n s t a n c e ( ) . getDataHandler ( ) . addEntity ( data ) ; LookData . g e t I n s t a n c e ( ) . getDataHandler ( ) . addEntity ( data1 ) ; // Updates t h e r e c e n t added d a t a LookData . g e t I n s t a n c e ( ) . updateData ( ) ; Asignamos la factor y aadimos dos entidades, una roja y otra verde. a n El resultado de la ejecucin de esta aplicacin es el mostrado por la gura o o 8.2.

Figura 8.2: Captura de la aplicacin con la nueva factor o a

110

8.2.4.

A adiendo interacciones n

Cada una de las entidades permiten que le sean aadidos una serie de listen ners que respondan a los distintos eventos que puedan surgir durante la ejecucin de la aplicacin. o o A adiendo procesado de eventos tctiles: TouchListener n a Cuando una entidad reciba un evento tctil, pasar ese evento a todos los a a listeners de su lista de TouchListener. Cmo puede verse en la gura 8.3, la o interfaz dene mtodos para los tres tipos de eventos tctiles principales. Cada e a uno de los mtodos recibe como parmetro la entidad que recibi el evento y e a o las coordenadas de pantalla dnde sucedi. o o

Figura 8.3: La interfaz TouchListener Supongamos que, siguiendo el ejemplo desarrollado hasta ahora, queremos que cada vez que se toque uno de los elementos, ste se desplaza una unidad en e el eje coordenado y. Para lograrlo, implementar amos el siguiente TouchListener : public c l a s s MyTouchListener implements T o u c h L i s t e n e r { @Override public boolean onTouchDown ( WorldEntity e , float x , float y) { P oi nt 3 p = e . g e t L o c a t i o n ( ) ; LookData . g e t I n s t a n c e ( ) . getDataHandler ( ) . u p d a t e P o s i t i o n ( e . getData ( ) , p.x, p.y 1, p. z ); return true ; } @Override public boolean onTouchUp ( WorldEntity e , float x , float y) { return f a l s e ; } @Override public boolean onTouchMove ( WorldEntity e , float x , float y) { return f a l s e ; }

111

Slo nos quedar aadir este listener a la lista de TouchListener de cada o a n una de las entidades. Para ello, aadimos la siguiente l n nea al cdigo de creacin o o de entidades de MyWorldEntityFactory: we . add To uch Lis ten er (new MyTouchListener ( ) ) ; La gura 8.4 muestra una captura de la aplicacin, tras tocar uno de los eleo mentos. Puede apreciarse como el TouchListener ejecut su lgica y traslad la o o o entidad.

Figura 8.4: Captura de la aplicacin tras pulsar uno de los elementos o

A adiendo eventos de cmara CameraListener n a Look! considera un evento de cmara cundo el usuario enfoca (o deja de a a enfocar) directamente una entidad con el centro de su dispositivo. Cmo muestra o la gura 8.5, CameraListener cuenta con dos eventos: uno para cundo el usuario a enfoca la entidad, y otro para cundo deja de enfocarla. a

Figura 8.5: La interfaz CameraListener Es decir, si colocamos el dispostivo tal que una entidad ocupe el centro de la pantalla, se ejecutar el mtodo onCameraEntered. Cundo, tras mover el a e a 112

dispositivo, la entidad abandone la zona central, se lanzar el mtodo onCamea e raExited. Ambos reciben como parmetro el objeto que recibi del evento. a o Supongamos que, en el ejemplo seguido hasta ahora, queremos que al enfocar directamente una entidad, cambie su malla de un cubo a un plano cuadrado, y que recupere su estado original cundo el usuario deja de de enfocar. El cdigo a o necesario ser el siguiente: a public c l a s s MyCameraListener implements Camer aListener { private s t a t i c S q u a r e P r i m i t i v e s q u a r e = new S q u a r e P r i m i t i v e ( ) ; private Drawable3D oldDrawable ; @Override public void onCameraEntered ( WorldEntity e n t i t y ) { oldDrawable = e n t i t y . getDrawable3D ( ) ; e n t i t y . setDrawable3D ( s q u a r e ) ; } @Override public void onCameraExited ( WorldEntity e n t i t y ) { e n t i t y . setDrawable3D ( oldDrawable ) ; } } Ahora deber amos aadir el listener a la lista de CameraListener. Para ello, n aadimos el siguiente cdigo a la factor de elementos: n o a we . addCameraListener (new MyCameraListener ( ) ) ; La gura 8.6 muestra una captura de la aplicacin, mientras el usuario enfoca o directamente a una de las entidades. Puede apreciarse como el CameraListener ejecut su lgica y cambi la malla 3D del elemento. o o o

8.2.5.

A adiendo un HUD a la aplicacin n o

Look! permite aadir vistas Android a modo de HUD. Estas vistas podr n an facilitar la interaccin con el usuario. Por ejemplo, si quisiramos aadir un o e n texto para dar cierta informacin al usuario, podr o amos utilizar una TextView, con el texto requerido, alojada en la capa de HUD. Supongamos que ahora queremos aadir a nuestra aplicacin de ejemplo, n o un botn en la parte superior. De momento solo queremos que aparezca, ya le o aadiremos funcionalidad despus. n e Lo primero que deber amos hacer ser asegurarnos de que la capa HUD a est congurada a true, en la llamada al constructor de LookAR desde MyAa

113

Figura 8.6: Captura de la aplicacin mientras se enfoca directamente a uno de o los elementos. Puede apreciarse como su representacion 3D ha cambiado de un cubo a un plano. RActivity. Despus, denimos una vista con un layout XML de Android, que e contenga lo que buscamos para nuestro HUD (en este caso, un unico botn): o <?xml version= 1 . 0 e n c o d i n g= u t f 8 ?> <L i n e a r L a y o u t x m l n s : a n d r o i d= h t t p : // schemas . a n d r o i d . com/ apk / r e s / a n d r o i d a n d r o i d : o r i e n t a t i o n= v e r t i c a l a n d r o i d : l a y o u t w i d t h= f i l l p a r e n t a n d r o i d : l a y o u t h e i g h t= f i l l p a r e n t > <Button a n d r o i d : t e x t= Button a n d r o i d : i d=@+i d / button1 a n d r o i d : l a y o u t w i d t h= w r a p c o n t e n t a n d r o i d : l a y o u t h e i g h t= w r a p c o n t e n t > </ Button> </ L i n e a r L a y o u t> Supongamos que este archivo es nombrado como main.xml, y est guardaa do en la carpeta de recursos layout de Android. Deber amos aadir el siguiente n cdigo en MyARActivity para que esta vista apareciera como HUD: o @Override public void onCreate ( Bundle s a v e d I n s t a n c e S t a t e ) { // . . . ViewGroup v = t h i s . getHudContainer ( ) ; 114

v . addView ( LookARUtil . getView (R. l a y o u t . main , null ) ) ; } Con getHudContainer obtenemos el contenedor del HUD, al que podemos aadirle vistas. En este caso, utilizamos la funcin de LookARUtil para crear n o una vista a partir de un archivo de recurso, y la aadimos. n El resultado de la ejecucin es el mostrado por la gura 8.7. o

Figura 8.7: Captura de la aplicacin con HUD. Podemos comprobar arriba a la o izquierda como se aadi el botn. n o o

8.2.6.

Congurando una base de datos

Cuando queremos que los elementos que han sido aadidos durante una n ejecucin, sean recordados en subsecuentes ejecuciones, debemos utilizar una o base de datos. Look! ofrece la creacin de una base de datos, a travs de unos pocos pasos. o e Extendiendo el ContenProvider La clase LookSQLContentProvider representa una base de datos genrica, e que el usuario debe extender para utilizarla. La extensin es sencilla, slo neceo o sitamos denir el nombre de la base de datos, y la autoridad. public c l a s s MyContentProvider extends LookSQLContentProvider { public MyContentProvider ( ) { super ( mydatabase . db ,

115

 e s . ucm . m y a r a c t i v i t y . c o n t e n t p r o v i d e r ) ; } } En este caso, el nombre para la base de datos ser mydatabase, y la autoridad, a el nombre del paquete dnde se encuentra alojada la clase. o Ahora, para que la base de datos sea accesible desde la aplicacin, debemos o denir el content provider. Deber amos aadir la siguiente l n nea a AndroidManifest.xml: <p r o v i d e r android:name= e s . ucm . m y a r a c t i v i t y . c o n t e n t p r o v i d e r . MyContentProvider a n d r o i d : a u t h o r i t i e s= e s . ucm . m y a r a c t i v i t y . c o n t e n t p r o v i d e r > </ p r o v i d e r> En name, ponemos la ruta hasta la clase, y en authorities, la autoridad denida en el constructor. Incorporando al DBDataHandler Por defecto, el mdulo de datos LookData, instancia como DataHandler un o BasicDataHandler, que est basado en una lista Java, que contiene todos los a datos. Sin embargo, para manejar la base de datos, necesitamos utilizar un DBDataHandler, y as debemos congurarlo en el onCreate de la aplicacin, con el o siguiente cdigo: o LookData . g e t I n s t a n c e ( ) . s e t D a t a H a n d l e r ( new DBDataHandler ( t h i s ) ) ; El DBDataHandler se encarga de cargar el content provider denido en el maniesto de la aplicacin, y de dar acceso a la base de datos con sus mtodos, o e de manera transparente. Los elementos que se aadan a travs del mtodo addEntity del DBDan e e taHandler sern guardados en la base de datos, y sern accesibles en siguientes a a ejecuciones.

8.3.

Preparando el Sistema de Localizacin o

La localizacin por Wi conlleva una serie de pasos previos de preparacin o o para que esta funcione correctamente. Para ello, junto al framework Look! se provee la aplicacin CNWi que implementa de manera sencilla todos los pasos o necesarios para preparar el entorno de localizacin. o Asimismo, el sistema de navegacin inercial requiere el ajuste de una serie o de parmetros para un funcionamiento adecuado. a En esta seccin se describe cmo utilizar el programa CNWi para llevar a o o cabo la conguracin necesaria y empezar a utilizar el sistema de localizacin o o por Wi en las aplicaciones desarrolladas con el framework, y cmo ajustar los o parmetros de navegacin inercial. a o 116

8.3.1.

Denicin de Nodos y Puntos de Acceso o

Denicin de Nodos o En primer lugar es necesario denir una serie de nodos en el mapa del edicio sobre el que se quiere utilizar la localizacin. Se recomienda una distancia o optima entre nodos de entre 5 y 10 metros en funcin del nmero de puntos o u de acceso a utilizar. 1 Estos nodos se etiquetan con un identicador unico y escriben en un chero de nombre Lugares.txt con el siguiente formato: [Id, Planta, Coordenada X, Coordenada Y, Nombre]
2

En la gura 8.8 se muestra un ejemplo de seleccin y etiquetado de nodos. o El chero resultante se muestra a continuacin: o 1 2 3 4 5 5 5 5 14 5 H a b i t a c i o n 8 4 banno 4 4 Cocina 2 1 Salon

El chero resultante debe incluirse en la raiz de la tarjeta SD del dispositivo.

Figura 8.8: Ejemplo de Denicin de Nodos o

Denicin de Puntos de Acceso o El siguiente paso consiste en la denicin de los puntos de acceso a utilizar en o el sistema de localizacin. Es importante tener en cuenta que aunque un mayor o nmero de puntos de acceso aumentar la precisin, los puntos de acceso deben u a o de ser estables ya que si uno de ellos deja de funcionar afectar al sistema de a localizacin. o Esto paso puede llevarse a cabo de dos formas:
1 Se pueden denir varios nodos para una misma localizacin, de forma que la captura de o datos se realice en diferentes puntos de, por ejemplo, una misma habitacin. Todos los nodos o tendr las mismas coordenadas aunque diferente id. Esto permite aumentar la precisin al an o utilizarse un mayor nmero de muestras en la inferencia de la posicin. u o 2 Si se desea integrar el sistema de localizacin mediante Wi con el sistema de Navegacin o o Inercial, las coordenadas debern estar expresadas en metros. a

117

Denicin Manual o Si se desea restringir los puntos de acceso a utilizar, debern denirse las direca ciones MAC de los puntos de acceso elegidos en el chero APs.txt. A continuacin se muestra un ejemplo del contenido de este chero: o 0 0 : 1 1 : f 5 : a1 : 4 7 : ac 00:1 a :2 b :5 b : f f :28 7 0 : 7 1 : bc : 8 a : 6 b : c f El chero resultante debe incluirse en la raiz de la tarjeta SD del dispositivo. Deteccin automtica o a Tal y como se muestra en la gura 8.9, CNWi proporciona un mtodo de e deteccin automtica de puntos de acceso y creacin del chero correspondiente. o a o

Figura 8.9: CCNWi: Deteccin automtica de Puntos de Acceso o a

8.3.2.

Captura de Datos

El siguiente paso es la captura de datos en cada uno de los nodos denidos para la elaboracin del mapa de radio. Para ello, CNWi proporciona un sistema o automtico de captura de datos, como se aprecia en la gura 8.10. a Para llevar a cabo la captura de datos, el usuario deber colocarse en cada a uno de los nodos denidos en el paso 8.3.1, indicar su id y pulsar en el botn o Entrenar. Cuando haya terminado la captura de todos los nodos, el usuario deber pulsar el botn Guardar para que los datos sean procesados y se genere a o el archivo de mapa de radio. En este punto el sistema est listo para empezar a localizar el dispositivo a desde cualquier aplicacin. o

118

Figura 8.10: CCNWi: Captura de Datos

Figura 8.11: CCNWi: Probando la localizacin o

119

8.3.3.

Probando la Localizacin por Wi o

CNWi proporciona un mdulo para probar la localizacin, mostrando la o o informacin de la ubicacin actual en tiempo real. Este mdulo puede verse en o o o la gura 8.11 y permite asegurarnos de que la seleccin de nodos es la adecuada o y que el sistema de localizacin funciona correctamente. o

8.3.4.

Ajuste de Parmetros del Sistema de Navegacin a o Inercial

Factor de Orientacin o El sistema de navegacin inercial tiene en cuenta la orientacin del dispoo o sitivo para calcular el desplazamiento en las coordenadas (X,Y). Si estamos trabajando sobre un mapa cuyo eje Y no est alineado con el Norte, es necea sario especicar el factor de correccin mediante el parmetro NORTH de la o a clase Mapa contenida en el paquete es.ucm.look.locationProvider.map. Esta informacin se utiliza para mapear las coordenadas reales a coordeo nadas del mapa de manera automtica y transparente para el programador de a aplicaciones. Escala Si se desea hacer un dibujado de la posicin del usuario sobre una imagen, o es posible ajustar este parmetro y utilizar las funciones proporcionadas en a la clase Mapa del paquete es.ucm.look.locationProvider.map para convertir las coordenadas reales a coordenadas de la imagen. Para ello es necesario ajustar el parmetro SCALE contenido en dicha clase a para indicar la correspondencia entre p xeles y metros.

8.4.

Integrando localizacin o

A la hora de integrar localizacin en nuestra aplicacin, en primer lugar se o o debe indicar si se utilizar el subsistema de Localizacin por Wi, el subsistema a o de Navegacin Inercial o ambos de manera combinada. Para ello se debe inio cializar la clase LocationManager 3 con los parmetros correspondientes a cada a uno de ellos: public LocationManager ( Context c o n t e x t , boolean w i f i , boolean i n s ) ; Una vez hecho esto, se puede iniciar y detener la localizacin mediante los o mtodos start() y stop(). Esta clase se encarga de inicializar y parar los servicios e de localizacin necesarios, actualizar los datos de la posicin, combinarlos si es o o necesario y proporcionar acceso a los mismos desde la aplicacin. o En el siguiente ejemplo se muestra como se utilizar el sistema de navegacin a o por Wi desde una aplicacin desarrollada mediante el framework: o LocationManager l o c a t i o n = new LocationManager ( this , true , f a l s e ) ;
3 LocationManager

es la interfaz con el sistema de localizacin. o

120

location . start (); ... P oi nt 3 p o s i c i o n = l o c a t i o n . g e t P o s i t i o n ( ) ; // Para a c t u a l i z a r e l mundo con l a nueva p o s i c i o n : LookData . g e t I n s t a n c e ( ) . getWorld ( ) . s e t L o c a t i o n ( p o s i c i o n ) ; ... l o c a t i o n . stop ( ) ; NOTA: Para que todo funcione correctamente, se deben aadir los siguientes n permisos al maniesto de la aplicacin: o <u s e s p e r m i s s i o n android:name= a n d r o i d . p e r m i s s i o n . CHANGE WIFI STATE /> <u s e s p e r m i s s i o n android:name= a n d r o i d . p e r m i s s i o n . ACCESS WIFI STATE /> <u s e s p e r m i s s i o n android:name= a n d r o i d . p e r m i s s i o n .WRITE EXTERNAL STORAGE />

121

Cap tulo 9

Experimentacin: o Aplicaciones de ejemplo desarrolladas con Look!

Este cap tulo pretende dar una idea general al lector de cmo se construyen o aplicaciones de complejidad media con Look!, desarrollando la aproximacin o general, enfocada a los elementos utilizados del framework, pero sin entrar en detalles concretos de cada aplicacin, relacionados con de programacin de lgica o o o y otros procedimientos no fundamentales de Look!. Para ello, se estudian varias aplicaciones desarrolladas durante el transcurso del proyecto como ejemplos de uso del framework. Por cada aplicacin, se da o una breve descripcin de la misma, se detallan los mdulos incorporados de o o Look! para su implementacin, las propiedades de los elementos que contienen, o las representaciones grcas, las interacciones para los elementos y el uso de a localizacin, adems de otros detalles particulares de cada aplicacin, como el o a o uso del HUD o la persistencia. Cada uno de estos apartados va acompaado de n partes representativas del cdigo desarrollado. o

9.1.

Mundo 3D

Mundo 3D es un mundo virtual tridimensional en el que el usuario puede moverse f sicamente e interactuar con los objetos virtuales. Para avanzar en el mundo virtual el usuario debe caminar en el mundo real, y para mover la cmara a subjetiva deber cambiar su orientacin, por lo que la simulacin de realidad a o o virtual es completa. Cada uno de los objetos virtuales presentes en el mundo interactan de manera diferente cuando son tocados, y muestra un mensaje u distinto cuando son enfocados por el usuario. En la gura 9.1 se observa el mensaje mostrado cuando el usuario enfoca un objeto en el mundo virtual.

122

Figura 9.1: Captura de Mundo 3D

9.1.1.

Mdulos incorporados o

Esta aplicacin utiliza la capa de tres dimensiones del mdulo realidad auo o mentada, y para detectar el movimiento del usuario el sistema de navegacin o inercial del mdulo de localizacin. o o

9.1.2.

Denicin de los EntityData o

En Mundo 3D se dene un tipo de elemento para cada uno de los objetos distintos a representar. Existen tres propiedades comunes: Name, que indica el nombre del objeto, Color, que indica su color, y Message, que representa el mensaje a mostrar en pantalla cuando el objeto es enfocado. Por ejemplo, la creacin de la entidad ufo se hace de la siguiente forma: o EntityData u f o = new EntityData ( u f o ) ; ufo . setLocation (10 , 0 , 1 0 ) ; ufo . setPropertyValue ( MundoVirtualWorldEntityFactory .NAME, u f o ) ; ufo . setPropertyValue ( MundoVirtualWorldEntityFactory .COLOR, g r e e n ) ; ufo . setPropertyValue ( MundoVirtualWorldEntityFactory .MESSAGE, Ya v i e n e n ! ) ; LookData . g e t I n s t a n c e ( ) . getDataHandler ( ) . addEntity ( u f o ) ; Existe un tipo especial de entidad, grid, que representa el suelo y se debe colocar en la posicin (0,10,0): o EntityData g r i d = new EntityData ( g r i d ) ; grid . setLocation (0 , 10 , 0 ) ; grid . setPropertyValue ( MundoVirtualWorldEntityFactory .NAME, g r i d ) ; grid . setPropertyValue ( MundoVirtualWorldEntityFactory .COLOR, b l u e ) ; 123

9.1.3.

Factor de WorldEntity a

La clase MundoVirtualWorldEntityFactory se encarga de la conversin de o EntityData a WorldEntity. En funcin del tipo de objeto, carga la malla correso pondiente y el color denido en su propiedad Color. Adems, aade los listener a n necesarios para cada tipo de objeto para que puedan recibir eventos touch y de cmara: a i f ( data . getType ( ) . e q u a l s ( u f o ) ) { we = new ObjectWorldEntity ( data ) ; Entity3D drawable3d = new Entity3D ( u f o ) ; S t r i n g c o l o r = data . g e t P r o p e r t y V a l u e (COLOR) ; i f ( c o l o r . equals ( red ) ) { drawable3d . s e t M a t e r i a l ( new C o l o r 4 ( 1 . 0 f , 0 . 0 f , 0 . 0 f ) ) ; ... we . setDrawable3D ( drawable3d ) ; we . ad dTo uch Lis ten er ( new O b j e c t T o u c h L i s t e n e r ( ) ) ; we . addCameraListener ( new O b j e c t C a m e r a L i s t e n e r ( ) ) ; Se ha denido la clase ObjectWorldEntity, heredera de WorldEntity y que incorpora funciones para hacer girar los objetos durante un tiempo dado. public void update ( long e l a p s e d ) { ... i f ( girando ) { i f ( g i r o < 1000) { ( ( Entity3D ) t h i s . getDrawable3D ( ) ) . getMatrix ( ) . r o t a t e ( 0 . 0 f , ( 0 . 1 5 f /( elapsed /2))100 , 0.0 f ) ; g i r o ++; } else { giro = 0; girando = false ; } }

9.1.4.

Interacciones

Se han aadido dos tipos de interaccin: eventos de cmara y eventos touch. n o a Para cada uno de ellos se ha creado una clase que implementa la respuesta a los eventos. Por ejemplo, la clase ObjectTouchListener implementa la respuesta los eventos touch haciendo que los objetos se eleven y giren al ser tocados:

124

public boolean onTouchDown ( WorldEntity e , f l o a t x , f l o a t y ) { P oi nt 3 p = e . g e t L o c a t i o n ( ) ; LookData . g e t I n s t a n c e ( ) . getDataHandler ( ) . u p d a t e P o s i t i o n ( e . getData ( ) , p . x , ( p . y ) 1 , p . z ) ; ( ( ObjectWorldEntity ) e ) . g i r a r ( ) ; return true ; } La clase ObjectCameraListener implementa la respuesta a los eventos de cmara, haciendo que se muestre un mensaje cuando el usuario enfoca un objeto a del mundo: public void onCameraEntered ( WorldEntity e n t i t y ) { TextView tv = ( TextView ) LookARUtil . getApp ( ) . findViewById (R. i d . mensaje ) ; tv . s e t T e x t ( e n t i t y . getData ( ) . g e t P r o p e r t y V a l u e ( message ) ) ; tv . s e t V i s i b i l i t y ( TextView . VISIBLE ) ; } public void onCameraExited ( WorldEntity e n t i t y ) { TextView tv = ( TextView ) LookARUtil . getApp ( ) . findViewById (R. i d . mensaje ) ; tv . s e t V i s i b i l i t y ( TextView . INVISIBLE ) ; }

9.1.5.

Localizacin o

Mundo 3D hace uso del sistema de navegacin inercial incluido en el mduo o lo de localizacin para detectar cundo la persona esta caminando y aplicar o a desplazamiento. Para ello, en primer lugar se inicializa el sistema de navegacin inercial o mediante la API de localizacin LocationManager y se consulta si la persona o est caminando a intervalos de tiempo jos mediante un Timer. a l o c a t i o n = new LocationManager ( t h i s . g e t A p p l i c a t i o n C o n t e x t ( ) , true , f a l s e ) ; location . start (); t i m e r = new Timer ( ) ; TimerTask timerTask = new TimerTask ( ) { MundoVirtualWorld w = ( MundoVirtualWorld ) LookData . g e t I n s t a n c e ( ) . getWorld ( ) ; public void run ( ) { 125

i f ( l o c a t i o n . isWalking ( ) ) { w . up ( ) ; } } }; t i m e r . s c h e d u l e A t F i x e d R a t e ( timerTask , 0 , 2 0 0 ) ; } Para aplicar el desplazamiento, se crea la clase MundoVirtualWorld, que hereda de World, y se dene el mtodo up() que actualiza la posicin del usuario e o dentro del mundo virtual avanzando en la direccin correspondiente1 . o public void up ( ) { i f ( ! keepUp ) { f l o a t azimuth = D e v i c e O r i e n t a t i o n . g e t D e v i c e O r i e n t a t i o n ( c o n t e x t ) . azimuth ; f l o a t x = LookData . g e t I n s t a n c e ( ) . g e t L o c a t i o n ( ) . x + DISTANCE ( f l o a t ) Math . s i n ( azimuth ) ; f l o a t y = LookData . g e t I n s t a n c e ( ) . g e t L o c a t i o n ( ) . y ; f l o a t z = LookData . g e t I n s t a n c e ( ) . g e t L o c a t i o n ( ) . z + DISTANCE ( f l o a t ) Math . c o s ( azimuth ) ; LookData . g e t I n s t a n c e ( ) . g e t L o c a t i o n ( ) . s e t ( x , y , z ) ; } }

9.2.

Galer Look! a

Galer Look! es una galer de imgenes interactiva en tres dimensiones. a a a Las imgenes se reparten en el entorno tridimensional alrededor del usuario. a Con el sistema de orientacin, el usuario puede girar en todas las direcciones, o para localizar las imgenes. a Con gestos de arrastre verticales y horizontales, puede pasarse de una la de imgenes a otra y hacer girar la columna de imgenes, respectivamente. a a Cuando el usuario pulsa una de las imgenes, sta se muestra a tamao a e n completo en primer plano, y muestra informacin relacionada, si la tuviera. o Las guras 9.2 y 9.3 muestran capturas de la aplicacin en ejecucin. o o

9.2.1.

Mdulos incorporados o

Esta aplicacin utiliza el mdulo de datos sin persistencia. Del mdulo de o o o realidad aumentada, utiliza las capas de dos y tres dimensiones. Esta aplicacin o no utiliza el mdulo de localizacin. o o

9.2.2.

Denicin de los EntityData o

Para Galeria Look! se ha denido un unico tipo de elementos: Imagen; con una unica propiedad: la ruta al archivo de imagen mostrado.
1 La direccin se obtiene a partir de la informacin de orientacin que se mantiene en la o o o clase DeviceOrientation.

126

Figura 9.2: Captura de Galer Look! a

Figura 9.3: Captura de Galer Look!, con una imagen seleccionada a

127

La carga de datos se hace desde una carpeta llena de imgenes. Una vez a obtenidos las rutas de los archivos, la creacin de elementos se consigue con el o siguiente cdigo: o for ( S t r i n g f i l e : f i l e s ){ EntityData imageData = new EntityData ( ) ; imageData . setPropertyValue ( I m a g e E n t i t y F a c t o r y .IMAGE, f i l e ) ; imageData . setPropertyValue ( I m a g e E n t i t y F a c t o r y . INFO , i n f o [ i ++] ) ; LookData . g e t I n s t a n c e ( ) . getDataHandler ( ) . addEntity ( imageData ) ; } Como se ve, no se dene la posicin del EntityData. Esta posicin es denida o o de manera automtica por ImageEntityFactory, la factor de WorldEntity de a a la aplicacin. Se encarga de situar el elemento para crear la columna alrededor o del usuario.

9.2.3.

Factor de WorldEntity a

La clase ImageEntityFactory se encarga de la conversin de EntityData a o WorldEntity. Parte de su cdigo es el siguiente: o public WorldEntity c r e a t e W o r l d E n t i t y ( EntityData data ) { ImageEntity image = new ImageEntity ( data ) ; image . s e t I m a g e ( data . g e t P r o p e r t y V a l u e (IMAGE ) ) ; // . . . // C a l c u l a t e x , y , z // . . . image . getData ( ) . s e t L o c a t i o n ( x , y , z ) ; image . s e t R o t a t i o n ( accAngle ) ; // . . . return image ; } ImageEntity es una clase heredera de WorldEntity. Construye automticaa mente la malla de la imagen. public ImageEntity ( EntityData data ) { super ( data ) ; e n t i t y = new Entity3D ( s q u a r e ) ; entity . setLighted ( false ) ; t h i s . setDrawable3D ( e n t i t y ) ; // . . . }

128

public void s e t I m a g e ( S t r i n g u r i ) { entity . setTexture ( uri ) ; } ImageEntity est representada por un plano 3D sin iluminacin. A travs a o e del mtodo setImage, invocado desde la factor se le asigna la textura de la e a, imagen representada al plano.

9.2.4.

Interacciones

Cada ImageEntity tiene asociada una unica interaccin: Cuando el usuario o pulsa sobre ella, sta aparece en primer plano, dibujada sobre el HUD. e El HUD, implementado en la clase GestureHUD, est denido en la semicapa a de HUD que ofrece la capa de dos dimensiones AR2D. Tiene dos funcionalidades: mostrar las imgenes en primer plano y procesar los gestos de arrastre vertical a y horizontal. public c l a s s GestureHUD implements HUDElement , TouchListener HUDElement es la interfaz que deben implementar los elementos de HUD de la semicapa de dos dimensiones. Esta interfaz obliga a implementar, entre otros, el mtodo touch(MotionEvent motionEvent). Este mtodo contiene la lgica que e e o procesa los gestos de arrastre. GestureHUD implementa tambin TouchListener para poder aadirlo como e n listener de las entidades. Su cdigo: o public boolean onTouchUp ( WorldEntity e , f l o a t x , f l o a t y ) { ImageEntity i e = ( ImageEntity ) e ; this . setImage ( i e ) ; return true ; } Obtiene la entidad de la imagen, y pone la imagen para mostrarla en el HUD con this.setImage(). El HUD se encarga de obtener informacin relacionada y o de mostrarla como texto. Finalmente, en la factor se aade como listener de la entidad al Gestua, n reHUD. image . ad dTo uch Lis te ner ( gestureHud ) ;

9.3.

Invaders 360

Invaders 360 es un juego desarrollado con Look!. El jugador se encuentra perdido en el espacio. Su nave se ha quedado sin combustible, no puede moverse de su posicin y comienza a verse rodeado por naves enemigas. El objetivo es o destruir el mayor nmero de enemigos, apuntando y movindose en 360o , antes u e de ser abatido. La gura 9.4 muestra una captura de la aplicacin en ejecucin. o o 129

Figura 9.4: Captura de Invaders 360

9.3.1.

Mdulos incorporados o

Esta aplicacin utiliza el mdulo de datos sin persistencia. Del mdulo de o o o realidad aumentada, utiliza las capas de dos y tres dimensiones. Esta aplicacin o no utiliza el mdulo de localizacin. o o

9.3.2.

Denicin de los EntityData o

En Invaders tenemos dos tipos de elemento, uno Enemigo y otro Bala. En el caso de esta aplicacin, la creacin de EntityData no se hace al inicio de o o la aplicacin. Se aade un nuevo enemigo cada cierto tiempo en una posicin o n o aleatoria; y se aade una nueva bala cada vez que el usuario pulsa la pantalla. n Para programar estos comportamiento, debemos extender World, con la clase InvadersWorld con una nueva clase. public c l a s s InvadersWorld extends World { // . . . public void update ( long e l a p s e d ) { // Update game l o g i c timeToEnemy = e l a p s e d ; i f ( timeToEnemy <= 0 ) { timeToEnemy = TIME BETWEEN ENEMIES ; addEnemy ( ) ; } // . . .

130

private void addEnemy ( ) { Vector3 v = new Vector3 ( 0 , 0 , 1 ) ; float angle = ( float ) ( Math . random ( ) 2 Math . PI ) ; v . rotateY ( angle ) ; float y = ( float ) ( 5 . 0 f Math . random ( ) 1 0 . 0 f ) ; EntityData enemy = new EntityData ( ) ; enemy . setType ( enemey ) ; enemy . setLocation ( v . x 50.0 f , y , v . z 50.0 f ) ; LookData . g e t I n s t a n c e ( ) . getDataHandler ( ) . addEntity ( enemy ) ; } public void s h o o t M i s s i l e ( ) { EntityData m i s s i l e = new EntityData ( ) ; m i s s i l e . setType ( m i s s i l e ) ; missile . setLocation (0 , 0 , 0 ) ; LookData . g e t I n s t a n c e ( ) . getDataHandler ( ) . addEntity ( m i s s i l e ) ; } } En el update actualizamos el tiempo que queda para aadir un nuevo enemin go, adems de la lgica del juego. Una vez se ha cumplido, llamamos a la funcin a o o addEnemy, que crea el enemigo, lo sita en una posicin aleatoria y lo aade a u o n los elementos.

9.3.3.

Factor de WorldEntity a

En esta aplicacin, se utiliza la InvadersWorldFactory. Para las naves enemio gas y los misiles, crea una MovableEntity, clase heredera de WorldEntity, que contiene lgica de movimiento con el paso del tiempo a partir de una direccin. o o public WorldEntity c r e a t e W o r l d E n t i t y ( EntityData data ) { i f ( data . getType ( enemy ) { MovableEntity w = new MovableEntity ( data ) ; w . setDrawable3D ( new Entity3D ( ufomesh ) ) ; P oi nt 3 p = w . g e t L o c a t i o n ( ) ;

131

w . s e t D i r e c t i o n ( p . x , p . y , p . z ) ; return w ; } e l s e { // M i s s i l e MovableEntity w = new MovableEntity ( data ) ; w . setDrawable3D ( new Entity3D ( s p h e r e ) ) ; w. s e t D i r e c t i o n ( u s e r D i r e c t i o n . x , userDirection . y , userDirection . z ); return w ; } } ufomesh es un ObjMesh en el que se ha cargado la malla de un archivo *.obj, y sphere representa una esfera.

9.3.4.

Interacciones

En esta aplicacin no existe ni interaccin tctil ni de cmara sobre los obo o a a jetos. Sin embargo, se utiliza el paquete de utilidades geomtricas, para calcular e las colisiones entre enemigo y bala, y as actuar en consecuencia. Por defecto, Entity3D crea un Armature. Esta armadura es la zona de contacto para el elemento. Cuando las Armature de misil y nave enemiga entran en contacto, se produce la colisin, y acta la lgica de colisin. o u o o Esta comprobacin se hace en el update del InvadersWorld. Por cada par o misil-enemigo, se ejecuta el siguiente cdigo: o P oi nt 3 p = new P oi nt 3 ( m i s s i l e . g e t L o c a t i o n ( ) ) ; // . . . i f ( enemy . getArmature ( ) . c o n t a i n s ( p ) ) { enemy . h u r t ( m i s s i l e . getDamage ( ) ) ; // . . . Si el volumen del enemigo contiene el misil, se ejecuta el mtodo hurt, que e hiere al enemigo.

9.4.

Look! Social

Look! Social: Social Network & Augmented Reality implementa una aplicacin de realidad aumentada con tintes sociales. Esta aplicacin es capaz de o o asociar usuarios y mensajes a localizaciones espec cas, y visualizarlos a travs e de realidad aumentada. As podr , amos localizar a un usuario conectado dentro de un edicio, a travs de realidad aumentada, y visualizar los mensajes dejados e por otros usuarios en posiciones completas. La aplicacin an est en un estado inicial, pero el framework permitir o u a a aadir elementos localizados de otros tipos, como imgenes o v n a deos. Adems, a implementa un sistema de logueo en servidor, y la interfaz est traducida al a espaol e ingls. n e

132

9.4.1.

Descripcin o

Al comienzo de la aplicacin, los usuarios tienen que registrarse una nueva o cuenta o identicarse si ya estn registrados. No se permite entrar a la aplicacin a o si no accedes como usuario, ya que para nosotros carece de sentido estar en la red social si no apareces identicado dentro de ella. Para el registro de un nuevo usuario (Figura: 9.5) es obligatorio rellenar los campos: usuario, nombre (lo vern los dems usuarios), y contrasea. a a n Adicionalmente se puede incluir una direccin de email (para compartirla con o los dems), un mensaje de estado (de carcter informativo), y una fotograf La a a a. fotograf se puede elegir de la galer del dispositivo o hacerla en el momento a a con la cmara. a

Figura 9.5: Registro y login de usuario en Look!Social Si se dispone de una cuenta basta con introducir tu usuario y contrasea en n la pantalla de login (Figura: 9.5). Una vez registrado en la aplicacin hay dos opciones disponibles (Figura: o 9.6): Una lista de usuarios: para un vistazo rpido con la informacin de a o cada uno, como estado o correo. La realidad aumentada: La informacin que ve el usuario es una mezo cla de las imgenes obtenidas por la cmara y de una capa de realidad a a aumentada en dos dimensiones que muestra la informacin de mensajes y o usuarios en base a la localizacin. o Los usuarios se representan con la imagen (gura 9.7) creada en el proceso de registro y los mensajes con un icono donde aparece el nombre del usuario que lo env o.

133

Figura 9.6: Pantalla principal de Look!Social con mens u

Figura 9.7: Look!Social : Realidad Aumentada

134

9.4.2.

Mdulos incorporados o

Look! Social se construye usando los siguientes mdulos: o Realidad Aumentada Los elementos que ve el usuario son una mezcla entre la imagen de la cmara y los elementos que componen el mundo en a 2 dimensiones. Localizacin: Obtiene la localizacin del usuario a partir del mdulo de o o o localizacin general que combina, a su vez, los mdulos de localizacin o o o Wi y navegacin inercial. o Datos remotos: Los datos de la aplicacin son manejados por el mdulo o o de persistencia remota. Este nos asegura que todos los usuarios comparten el mismo contenido.

9.4.3.

Denicin de los EntityData o

En esta aplicacin, podemos identicar dos tipos de entidades: usuario y o mensaje. Las propiedades caracter sticas de cada una son las representadas en los cuadros 9.1 y 9.2. Usuario user Propiedades Nombre de la propiedad Descripcin de la propiedad o user Nombre de usuario name Nombre real del usuario state Estado del usuario image Identicador de imagen para el usuario type Cuadro 9.1: Denicin de tipo y propiedades del usuario o

A travs de los mtodos set/getPropertyValue( ... ) pueden asignarse/consule e tarse valores a/de las distintas propiedades. Mensaje message Propiedades Nombre de la propiedad Descripcin de la propiedad o sender El autor del mensaje text El contenido del mensaje date La fecha del mensaje type Cuadro 9.2: Denicin de tipo y propiedades del mensaje o

135

9.4.4.

Factor de WorldEntity a

La clase LookSocialWorldEntityFactory se encarga de la conversin de Eno tityData a WorldEntity. Construye con las propiedades cada tipo de objeto y aade los listener necesarios para para que puedan recibir eventos touch y de n cmara: a c r e a t e W o r l d E n t i t y ( EntityData data ) { i f ( data . getType ( ) . e q u a l s ( u s e r ) ) { UserEntity w = new U s e r E n t i t y ( data ) ; we . addCameraListener ( new O b j e c t C a m e r a L i s t e n e r ( ) ) ; i f ( data . getType ( ) . e q u a l s ( message ) ) { MessageEntity w = new MessageEntity ( data ) ; we . ad dTo uch Lis ten er ( new O b j e c t T o u c h L i s t e n e r ( ) ) ; we . addCameraListener ( new O b j e c t C a m e r a L i s t e n e r ( ) ) ;

9.4.5.

Interacciones

Se han aadido dos tipos de interacciones: n Eventos de cmara: En el caso de estar apuntando a un usuario se a muestra su mensaje de estado, si es un mensaje el texto que este contiene. Eventos de touch: Al tocar sobre un mensaje aparece un campo de texto para editarlo si le pertenece al usuario. Si se toca sobre una parte de la pantalla donde no hay elementos aparecer un campo de texto para insertar un nuevo mensaje. Este ir jado a a con la posicin donde se encuentra el usuario. o Para cada tipo de iteraccin se ha creado una clase que recoge la respuesta o a los eventos: Para los eventos touch, la clase ObjectTouchListener public boolean onTouchDown ( // e l mensaje a s o c i a d o a l a l o c a l i z a c i o n a c t u a l // l o creamos en l a nueva a c t i v i t y LookARUtil . getApp ( ) . s t a r t A c t i v i t y ( new I n t e n t ( LookARUtil . getApp ( ) , NewMessageActivity . c l a s s ) ) ; } La clase ObjectCameraListener implementa la respuesta a los eventos de cmara, haciendo que se muestre un mensaje cuando el usuario enfoca un objeto a tipo user o mensaje 136

public void onCameraEntered ( WorldEntity e n t i t y ) { TextView tv = ( TextView ) LookAugmentedReality . getApp ( ) . findViewById (R. i d . mensaje ) ; tv . s e t T e x t ( e n t i t y . getData ( ) . g e t P r o p e r t y V a l u e ( message ) ) ; tv . s e t V i s i b i l i t y ( TextView . VISIBLE ) ; } public void onCameraExited ( WorldEntity e n t i t y ) { TextView tv = ( TextView ) LookAugmentedReality . getApp ( ) . findViewById (R. i d . mensaje ) ; tv . s e t V i s i b i l i t y ( TextView . INVISIBLE ) ; }

9.4.6.

Localizacin o

Look! Social hace uso del mdulo de localizacin para controlar la posicin o o o del usuario dentro de un edicio. Para ello, en primer lugar se inicializa el sistema de localizacin mediante la API LocationManager. Se utilizarn tanto o a el subsistema de localizacin por wi como el subsistema de navegacin inercial o o para obtener la mxima precisin en el posicionamiento. a o Cdigo necesario para cargar el mdulo de localizacin: o o o l o c a t i o n = new LocationManager ( t h i s . g e t A p p l i c a t i o n C o n t e x t ( ) , true , true ) ; location . start (); t i m e r = new Timer ( ) ; TimerTask timerTask = new TimerTask ( ) { public void run ( ) { P oi nt 3 p o s i c i o n = l o c a t i o n . g e t P o s i t i o n ( ) ; LookData . g e t I n s t a n c e ( ) . getWorld ( ) . setLocation ( posicion ) ; } }; t i m e r . s c h e d u l e A t F i x e d R a t e ( timerTask , 0 , 2 0 0 ) ; } La posicin se consulta y actualiza a intervalos de tiempo jos mediante el o uso de un Timer.

9.4.7.

Datos remotos

Los objetos del mundo virtual se encuentran almacenados en una base de datos remota que son descargados la primera vez que entramos en la aplicacin. o Adems comprobamos peridicamente si hay cambios para actualizar el Mundo. a o Cuando un usuario se registra se env al servidor para que le asigne un a identicador unico y lo almacene en su base de datos, as estar visible a los a 137

dems usuarios. Para cada mensaje insertado se procede de la misma manera. a Para inicializar el servicio web es necesario el siguiente cdigo: o // Comenzar e l s e r v i c i o de d a t o s remoto s e r v i c e m a n a g e r = new S e r v i c e M a n a g e r ( t h i s ) ; servicemanager . s t a r t S e r v i c e ( ) ; servicemanager . bindService ( ) ;

// C o n f i g u r a l a URL d e l s e r v i d o r y l a //URL con l o s a r c h i v o s b i n a r i o s // ( f o t o g r a f i a s de l o s u s u a r i o s ) ConfigNet . s e t N e t C o n f i g u r a t i o n ( h t t p : / / 1 4 7 . 9 6 . 8 0 . 8 9 : 5 0 0 0 / L ookS erve r / r e s o u r c e s / , h t t p : / /www. lookapp . e s / f i l e s / ) ;

138

Cap tulo 10

Apuntes nales
10.1. Problemas encontrados durante el proyecto

Este proyecto fue planteado con unos objetivos muy ambiciosos y un alto grado de incertidumbre desde el principio, lo cual ha condicionado su desarrollo y nos ha planteado una serie de retos. Algunos de ellos han resultado relativamente sencillos de solventar mientras que otros han planteado dicultades que han afectado en mayor o menor medida al progreso del mismo. Una de las mayores dicultades que hemos encontrado deriva del hecho de habernos enfrentado a tecnolog muy novedosas, en algunos casos con un grado as de maduracin bajo. La realidad aumentada es un concepto muy novedoso, y o muchos aspectos, como por ejemplo el mezclado de grcos 3D y cmara en a a Android, no son en absoluto triviales y producen todo tipo de comportamientos extraos (cmo se apunt en la seccin 7.3) que nos han impedido implementar n o o o muchas de las ideas inicialmente planteadas. Adems, algunas partes del desarrollo se centraron en realizar software que a no prove Android, como por ejemplo para la determinacin de la orientacin a o o del dispositivo, o capacidades multitouch, y que han aparecido solucionadas de manera nativa en subsecuentes versiones del SDK. Estas nuevas versiones, aunque han tra mejoras en eciencia, han dejado obsoletas algunas de las do funcionalidades implementadas. La implementacin de un servidor Web mediante la arquitectura REST se ha o visto entorpecida por diversos problemas, tanto en la parte del cliente como en la parte del servidor, y por una documentacin muy escasa para solventarlos. o Esto ha dicultado mucho su desarrollo. Lo anterior, unido al hecho de que uno de los pilares fundamentales del proyecto, el sistema de localizacin en interiores, requer de un trabajo de inveso a tigacin cuyas conclusiones resultaba imposible de determinar hasta una fase o

139

avanzada del proyecto ha planteado importantes riesgos y dicultado la denicin del alcance del proyecto. Sin unos requisitos slidos ha resultado complicao o do avanzar en una unica direccin, lo cual ha entorpecido el desarrollo en gran o medida. La localizacin en interiores es un rea que entraa una gran complejidad y o a n para al que a d de hoy no se han encontrado soluciones ptimas 1 a pesar de los a o diversos esfuerzos dirigidos a ello. Para el desarrollo del sistema de localizacin, o se ha llevado a cabo un importante esfuerzo de investigacin y experimentacin o o con todo tipo de tecnolog que esperamos pueda servir como base para futuros as, trabajos.

10.2.

Trabajo futuro

La realidad aumentada ofrece una inmensidad de posibilidades. En Look! hemos implementado las que nos parecieron las ms interesantes, y aquellas a para las que dispusimos tiempo. Sin embargo, creemos que, como trabajo futuro, podr aadirse algunas caracter an n sticas adicionales: Optimizacin general de cdigo: El resultado nal del framework es o o fruto de la experimentacin, y normalmente ha primado que la funcionao lidad existiera a que fuera eciente. Como resultado, hay mucha funcionalidad a la que podr mejorarse su eciencia. Sobre todo en cuestiones a de dibujado, clculos de proyeccin y refresco de pantalla. a o Separacin de mdulos en bibliotecas: Actualmente, los tres mdulos o o o principales de Look! estn aglutinados en una unica biblioteca. Aquellas a aplicaciones que no utilicen los tres mdulos, contendrn cdigo y clases o a o que jams sern ejecutadas. a a Localizacin en exteriores: Con las interfaces creadas para el mdulo o o de localizacin, podr acoplarse un nuevo mdulo que obtuviera localio a o zacin en exteriores a travs de GPS. Habr que desarrollar un mdulo o e a o que convirtiera latitud y longitud al sistema de referencia de coordenadas locales utilizado por Look!. Actualizacin y borrado de datos: En el estado actual, la coherencia o entre datos locales y remotos no es completamente funcional, puesto que no existe lgica para borrar de los datos locales aquellos datos que fueron o borrados del servidor. Como trabajo futuro, habr que implementar un a nuevo tipo de noticacin que avisara del borrado de entidades. o Renacin de mtodos de localizacin en interiores: Algunos mtoo e o e dos de localizacin en interiores pueden ser renados para obtener mayor o eciencia y precisin mediante el ajuste de los parmetros y una mejor o a integracin entre ellos. o
1 Al menos sin el uso de complejos y caros sistemas de ondas de baja frecuencia, u otro tipo de soluciones poco verstiles y no aplicables al hardware disponible en dispositivos de tipo a smartphone actuales.

140

Mejorar seguridad en datos: No existe ninguna codicacin de datos o ni ningn tipo de seguridad aadida en las conexiones de red. Deber u n an aadirse caracter n sticas que aseguraran estas comunicaciones. Adicin de nuevos tipos de interaccin con las entidades del muno o do: Pueden aadirse nuevos tipos de interaccin, como por ejemplo, por n o proximidad (se lanza un evento cundo pasamos a encontrarnos a una a distancia X de un elemento). Uso de OpenGL ES 2.0: Migracin de OpenGL ES 1.1 a 2.0, tras la o aparicin de esta posibilidad en las ultimas versiones de Android. o Aceleracin por GPU: Inclusin de aceleracin por GPU en el dibujado o o o 2D, ofrecido por las nuevas versiones de Android. Adicin de caracter o sticas OpenGL a n no implementadas: Transu parencias, animaciones de texturas o animaciones de mallas 3D.

10.3.

Conclusiones

El objetivo de crear un prototipo funcional lo antes posible, provoc la poca o profundizacin en alguno de los mtodos que se estaban utilizando, por ejemplo o e en la localizacin, o en las representaciones grcas en Android, lo que en revio a siones posteriores provoc problemas de compatibilidad entre dispositivos, y la o reescritura de muchas partes del cdigo. o Android es un sistema operativo mvil libre, con todas sus consecuencias. o Est implementado en muchos dispositivos distintos, y aunque en teor el a a, SDK ofrece compatibilidad para todos ellos, en la prctica se descubre que hay a elementos dependientes de dispositivo, cmo el cdigo necesario para mostrar o o la imagen de la cmara de manera correcta. En ocasiones, se ha utilizado ms a a tiempo en permitir que el framework fuera compatible en el mayor nmero de u dispositivos que aadiendo y perfeccionando funcionalidades. n La falta de una arquitectura global clara desde el principio del proyecto, provoc que algunos de los mdulos no fueran fcilmente combinables entre s o o a , provocando reestructuraciones de clases y cdigo. o Aunque el objetivo era desarrollar un framework, necesitbamos aplicaciones a precisas que implementaran todas las funcionalidades que ofrec amos. A la postre nos dimos cuenta de que la mayor de aplicaciones no utilizar todos los a an mdulos ofrecidos por Look!, lo que no nos permit desarrollar una aplicacin o a o unica que mostrara todo el potencial del framework. Sin embargo, creemos que el balance del proyecto ha sido muy positivo. A pesar de lo ambicioso del proyecto y de unas expectativas iniciales quizs dea masiado optimistas, creemos que se pueden extraer lecciones muy valiosas de lo aprendido en este proyecto. Esperamos que nuestra experiencia pueda servir de base para futuros desarrollos en este sentido, evitando que se cometan los mismos errores y permitiendo aprender de nuestro trabajo.

141

Queremos agradecer la oportunidad que nos ha brindado este proyecto de adquirir nuevas habilidades tanto tcnicas como personales, y que sin duda nos e sern de gran utilidad en el futuro. a

142

Bibliograf a
[1] Application of Channel Modeling for Indoor Localization Using TOA and RSS. Ahmad Hatami. Worcester Polytechnic Institute. Massachusetts, 2006. [2] Pro Android 2. Sayed Y. Hashimi, Satya Komatineni, Dave MacLean. New York : Apress. 2010 [3] Professional Android 2 application development. Reto Meier. Indianapolis : Wiley. 2010 [4] The Busy Coders Guide to Android Development v 2.1. Mark L. Murphy. CommonsWare. 2009 [5] The Busy Coders Guide to Advanced Android Development v 1.9. Mark L. Murphy. CommonsWare. 2010 [6] Indoor Navigation System for Handheld Devices. Mahn Hung V. Le, Dimitris Saragas, Nathan Webb. Worcester Polytechnic Institute. Massachusetts, 2009. [7] Sistema de deteccin de intrusos en redes de comunicaciones utilizando o redes neuronales. Mej Snchez, J. A. Universidad de las Amricas Puebla, a a e 2004. [8] RADAR: An In-Building RF-based User Location and Tracking System. Paramvir Bahl, Venkata N. Padmanabhan. Microsoft Research. 2000. [9] Location Determination of a Mobile Device Using IEEE 802.11b Access Point Signals. Siddhartha Saha, Kamalika Chaudhuri, Dheeraj Sanghi, Pravin Bhagwat. Indian Institute of Technology Kanpur. India. [10] iPhone 3D programming: developing graphical applications with OpenGL ES. Sebastopol, Calif. : OReilly, 2010 [11] A Combined Genetic optimization and Multilayer Perceptron Methodology for Ecient Digital ngerprint Modeling and Evaluation in Secure Communications. D. A. Karras. Chalkis Institute of Technology and Hellenic Open University. Atenas. [12] Environmental Detectivesthe development of an augmented reality platform for environmental simulations http://www.springerlink.com/ content/2300791305451525/

143

[13] Some Usability Issues of Augmented and Mixed Reality for e-Health Applications in the Medical Domain http://www.springerlink.com/content/ 1210414k80435u45/ [14] Augmented-RealityAssisted Laparoscopic Adrenalectomy http://jama. ama-assn.org/content/292/18/2214.3.short [15] A head-mounted operating binocular for augmented reality visualization in medicine - design and initial evaluation http://ieeexplore.ieee.org/ xpl/freeabs_all.jsp?arnumber=1076043 [16] Applications of augmented reality for human-robot communication http: //ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=583833 [17] Intel Research: Placelab: http://ils.intel-research.net/place-lab [18] Neuroph: Java Neural sourceforge.net/ Network Framework: http://neuroph.

[19] REST vs. SOAP The Right WebService http://geeknizer.com/ rest-vs-soap-using-http-choosing-the-right-webservice-protocol/ [20] XML-RPC: Very thin xmlrpc client library for Android platform: http: //developer.android.com/reference/java/net/URLConnection.html [21] ksoap2-android: A lightweight and ecient SOAP library for the Android platform. http://code.google.com/p/ksoap2-android/ [22] Restlet edition for Android http://wiki.restlet.org/docs_2.1/ 13-restlet/275-restlet/266-restlet.html [23] Google I/O 2010 - Android REST client applications http://www.google. com/events/io/2010/sessions/developing-RESTful-android-apps. html [24] Android Reference: packages.html http://developer.android.com/reference/

[25] Layar Browser Web http://www.layar.com/ [26] mixare Augmented Reality Engine http://www.mixare.org/ [27] AndAR Augmente Reality http://code.google.com/p/andar/

144

Anexo A

Sistema de Navegacin o Inercial mediante el Clculo a del Desplazamiento Relativo

A.1. Introduccin o

Durante el desarrollo del sistema de localizacin por wi, se hizo patente la o necesidad de contar con un sistema navegacin inercial como complemento a este o y que permitiera aumentar la precisin obtenida. Aunque nalmente se opt por o o un sistema de deteccin de movimiento, se investigaron diferentes tcnicas para o e lograr un sistema de posicionamiento a partir de los datos obtenidos por el acelermetro. o Este anexo describe el trabajo de investigacin llevado a cabo para el desao rrollo de este tipo de sistemas y los resultados fruto de este esfuerzo.

A.2.

Descripcin o

Se pretende conocer la posicin de un dispositivo en el espacio a travs de o e una posicin inicial y el clculo de los desplazamientos relativos producidos por o a el mismo a lo largo del tiempo. La aceleracin se obtiene mediante el uso de acelermetros. Se deben tener o o en cuenta los siguientes aspectos: La velocidad devuelta por el acelermetro est afectada por la fuerza de o a la gravedad y es necesario eliminarla para obtener valores de aceleracin o absolutos en cada eje. La frecuencia de muestreo debe ser muy alta para que el sistema funcione correctamente. La precisin del acelermetro debe de ser lo mayor posible para evitar o o errores acumulativos grandes. 145

A.2.1.

Frmulas o

El clculo de los desplazamientos relativos se lleva a cabo integrando la a aceleracin en cada uno de los ejes para obtener la velocidad en ese instante, e o integrando la velocidad para obtener el desplazamiento. t x x0 = t0 v dt v v0 = Por tanto: v(t) = v0 + a t x(t) = x0 + v0 t +
at2 2 t t0

a dt

A.2.2.

Eliminacin del efecto de la gravedad o

Aunque a partir de la versin 2.3 de Android existen APIs para la obteno cin de la aceleracin absoluta sin el efecto de la gravedad, en el momento de o o desarrollar este sistema tuvimos que eliminar dicho efecto de forma manual. Este efecto hace que por ejemplo, estando el dispositivo en reposo encima de una mesa, la aceleracin en los ejes X e Y sea 0, y en el eje Z sea igual a o -9.8, correspondiente a la fuerza de la gravedad. Al girar el mvil la fuerza de o la gravedad se distribuye entre los distintos ejes. Para eliminar la gravedad se ha empleado un ltro de paso bajo que aisla la fuerza de la gravedad en cada eje, y posteriormente lo resta de la magnitud de aceleracin detectada para dicho eje: o double alpha gravity [ 0 ] = (1 gravity [ 1 ] = (1 gravity [ 2 ] = (1 = 1 / ( 1 + dt ) ; alpha g r a v i t y [ 0 ] + alpha ) evt . getXAcceleration ( ) ; alpha g r a v i t y [ 1 ] + alpha ) evt . getYAcceleration ( ) ; alpha g r a v i t y [ 2 ] + alpha ) evt . g et ZA cc el e ra ti on ( ) ;

linear acceleration [0] = evt . getXAcceleration () gravity [ 0 ] ; linear acceleration [1] = evt . getYAcceleration () gravity [ 1 ] ; linear acceleration [2] = evt . getZAcceleration () gravity [ 2 ] ; donde dt corresponde al incremento de tiempo transcurrido desde la ultima muestra. El resultado es la aceleracin lineal en cada uno de los ejes (X,Y,Z). o

146

A.2.3.

Transformacin de Coordenadas o

Debido a que el sistema de coordenadas del dispositivo no es jo sino que depende su orientacin, es necesario aplicar matrices de transformacin para o o poder pasar dicho sistema de coordenadas variable a un sistema de coordenadas jo correspondiente al sistema de coordenadas del mundo real. Para ello se emplean los datos de orientacin obtenidos del giroscopio (roll, pitch y azimuth): o / R ot a c io n en e l e j e X / p u b l i c s t a t i c d o u b l e [ ] getRotacionX ( d o u b l e x , double y , double z ) { double [ ] r e s u l t = { 0 , 0 , 0 } ; result [0] = x; r e s u l t [ 1 ] = Math . c o s ( azimuth ) y ( Math . s i n ( azimuth ) z ) ; r e s u l t [ 2 ] = Math . s i n ( azimuth ) y + Math . c o s ( azimuth ) z ; return r e s u l t ; }

/ R ot a c io n en e l e j e Y / p u b l i c s t a t i c d o u b l e [ ] getRotacionY ( d o u b l e x , double y , double z ) { double [ ] r e s u l t = { 0 , 0 , 0 } ; r e s u l t [ 0 ] = Math . c o s ( r o l l ) x + Math . s i n ( r o l l ) z ; result [1] = y; r e s u l t [ 2 ] = (Math . s i n ( r o l l ) x ) + Math . c o s ( r o l l ) z ; return r e s u l t ; }

/ R ot a c io n en e l e j e Z / p u b l i c s t a t i c double [ ] getRotacionZ ( double x , double y , double z ) { double [ ] r e s u l t = { 0 , 0 , 0 } ; r e s u l t [ 0 ] = Math . c o s ( p i t c h ) x Math . s i n ( p i t c h ) y ; r e s u l t [ 1 ] = Math . s i n ( p i t c h ) x + Math . c o s ( p i t c h ) y ; result [2] = z ; return r e s u l t ; }

147

A.3.

Implementacin o

Este sistema se ha implementado para dos tipos de dispositivo distintos a n de comprobar si resulta viable su utilizacin en el proyecto: o Android: Se ha implementado utilizando la API de acceso a los sensores que proporciona Android. Mando de la consola Nintendo Wii: Se han analizado varias librer as para el acceso al mando de la consola, y nalmente se ha implementado utilizando la librer WiiRemoteJ 1 , que proporciona acceso a diversas a funciones del mando a travs de Bluetooth. Entre ellas proporciona acceso e a los acelermetros. o

Figura A.1: Accediendo al mando de la Wii

A.4.

Resultados

En ninguna de las pruebas realizadas hemos conseguido resultados aceptables con esta tcnica, creemos que debido en buena parte a la precisin de los e o acelermetros empleados. o Un sensor ideal, con una tasa de muestreo muy elevada y precisin total pero mitir captar todas las variaciones en la aceleracin, fueran grandes o pequeas a o n y monitorizar de manera exacta la posicin del dispositivo en el espacio. o Sin embargo, con los sensores que hemos empleado en nuestras pruebas, el error acumulado crece muy rpidamente, haciendo que el sistema se vuelva a
1 http://www.world-of-cha0s.hostrocket.com/WiiRemoteJ/

148

inestable. Creemos que tasas de muestreo ms elevadas y una mayor precisin a o en la deteccin de la aceleracin podr arrojar resultados aceptables por coro o a tos per odos de tiempo, aunque ser necesario resetear la posicin cada cierto a o tiempo para evitar el efecto del error acumulado.

A.5.

Precisin de acelermetros o o

Resulta dif encontrar informacin detallada acerca de la precisin de los cil o o acelermetros incluidos en diferentes dispositivos Android. Los acelermetros o o disponibles en el mercado normalmente son congurables para trabajar con diferentes rangos de aceleraciones. Si la precisin del acelermetro es baja se obo o tendr una mayor precisin con valores bajos de aceleracin, ya que al aumentar a o o el rango disponible se produce un error mayor en la deteccin. o Por ejemplo, el acelermetro del iPhone est jado en el rango [-2.3, +2.3] o a g, por lo que aceleraciones fuera de ese rango no sern detectadas. Es de sua poner que los acelermetros de los dispositivos Android se movern en rangos o a parecidos. Es necesario tener esto en cuenta de cara a la implementacin de un sistema o de navegacin inercial. Existen en el mercado acelermetros de alta precisin o o o capaces de detectar aceleraciones del orden de micro g o nano g, aunque posiblemente una solucin aceptable se encuentre en un trmino medio. o e En la web http://www.dynamoelectronics.com/dynamo-tienda-virtual. html?page=shop.browse&category_id=64 pueden encontrarse acelermetros o de diferente sensibilidad utilizados en robtica o dispositivos mviles con rangos o o de entre +/-1g y +/-11g. La eleccin del acelermetro adecuado depender en o o a gran medida de la experimentacin, ya que resulta complicado establecer a prioo ri cual de ellos ofrecer un resultado aceptable de cara la implementacin de un a o sistema de navegacin inercial. o

149

Anexo B

Acceso a la API CoreWLAN de Mac OS X desde Java mediante JNI

B.1. Introduccin o

Una de las mayores dicultades que tuvimos a la hora de realizar el anlisis a de PlaceLab fue conseguir hacer que dicho software funcionara en una mquina a con sistema operativo Mac OS X 10.6, que era nuestra principal mquina para a realizar las pruebas. Hasta la versin 10.5 de Mac OS X, la API de acceso al hardware WiFi no o estaba disponible para los programadores. Circulaba en internet una API en C obtenida mediante ingenier inversa llamada Apple80211.h. La mayor de los a a desarrollos para Mac OS X hasta esa fecha utilizaban dicha API para realizar las llamadas al sistema necesarias para trabajar con el hardware WiFi, entre ellos PlaceLab. Ejemplos de la funcionalidad provista por dicha API son funciones para realizar escaneos de redes o para conectarse a un red. Sin embargo, a partir de la versin 10.5 Apple elimin dicha interfaz, proo o porcionando la API CoreWLAN para el acceso al hardware wi, rompiendo la compatibilidad con las aplicaciones que hasta ese momento utilizaban Apple80211.h. PlaceLab implementa el acceso al hardware mediante librer nativas en as C para cada uno de los sistemas operativos soportados, accedidas desde java mediante JNI 1 . El problema de la nueva API CoreWLAN es que est implea mentada en Objective-C, y aunque supuestamente es posible utilizar JNI para el acceso a librer nativas en dicho lenguaje, la documentacin es muy escasa as o y el problema no es en absoluto trivial. En este anexo se describe el trabajo llevado a cabo para conseguir ejecutar PlaceLab en Mac OS X y el proceso necesario para poder acceder a la API CoreWLAN, y en general a cualquier API Objective-C desde un programa Java.
1 Java

Native Interface: proporciona acceso a librer nativas desde java. as

150

B.2.

Pasos Necesarios

Para conectar un programa Java con la API CoreWLAN es necesario seguir los siguientes pasos:

B.2.1.

Creacin del chero de cabecera o

En JNI las funciones nativas se implementan en archivos por separado (librer nativas con extensin .jnilib o .dylib). En primer lugar es necesario crear as o una clase Java que declare los mtodos nativos. Por ejemplo en PlaceLab se e denen los siguientes mtodos nativos: e / I n i t i a l i z e t h e s p o t t e r @param w i f i I n t e r f a c e The w i r e l e s s i n t e r f a c e t o u s e . I f n u l l o r t h e empty s t r i n g , u s e t h e f i r s t found w i r e l e s s i n t e r f a c e . @return t r u e on s u c c e s s f u l i n i t / public native void s p o t t e r i n i t ( String w i f i I n t e r f a c e ) throws S p o t t e r E x c e p t i o n ; / Shutdown t h e s p o t t e r . / public native void spotter shutdown () throws S p o t t e r E x c e p t i o n ; / P o l l t h e s p o t t e r . @return an a r r a y o f BSSID s t r i n g s / public native String [ ] spotter poll () throws S p o t t e r E x c e p t i o n ; Para cargar la librer nativa se incluye lo siguiente en la cabecera de la a clase: static { System . l o a d L i b r a r y ( s p o t t e r ) ; } Una vez hecho esto, lo siguiente es compilar la clase y generar un chero de cabecera que se utilizar como base para la implementacin de la librer a o a nativa. Para ello se debe ejecutar: $ javac ClaseJava.java $ javah -jni ClaseJava El resultado es un chero .h similar a este:

151

/ DO NOT EDIT THIS FILE i t i s machine g e n e r a t e d / #i n c l u d e < j n i . h> / Header f o r c l a s s o r g p l a c e l a b s p o t t e r W i F i S p o t t e r / #i f n d e f I n c l u d e d o r g p l a c e l a b s p o t t e r W i F i S p o t t e r #d e f i n e I n c l u d e d o r g p l a c e l a b s p o t t e r W i F i S p o t t e r #i f d e f cplusplus e x t e r n C { #e n d i f / Class : org placelab spotter WiFiSpotter Method : spotter init S i g n a t u r e : ( Ljava / l a n g / S t r i n g ; ) V / JNIEXPORT v o i d JNICALL Java org placelab spotter WiFiSpotter spotter 1init ( JNIEnv , j o b j e c t , j s t r i n g ) ; / Class : org placelab spotter WiFiSpotter Method : spotter shutdown S i g n a t u r e : ( )V / JNIEXPORT v o i d JNICALL Java org placelab spotter WiFiSpotter spotter 1shutdown ( JNIEnv , j o b j e c t ) ; / Class : org placelab spotter WiFiSpotter Method : spotter poll S i g n a t u r e : ( ) [ Ljava / l a n g / S t r i n g ; / JNIEXPORT j o b j e c t A r r a y JNICALL Java org placelab spotter WiFiSpotter spotter 1poll ( JNIEnv , j o b j e c t ) ; #i f d e f } #e n d i f #e n d i f cplusplus

B.2.2.

Mezclando cdigo C y Objective-C o

Objective-C es un lenguaje basado en C. Por lo tanto, es posible escribir un programa utilizando las sintaxis de C y Objective-C de manera simultnea, a siempre y cuando la compilacin se realice con gcc y el framework Foundation o de Mac OS X:

152

$ gcc -framework foundation -std=c99

test.m -o prog1

Por tanto podemos escribir un programa mezcla de ambos lenguajes incluyendo las librer que sean necesarias de cada uno de ellos. En nuestro caso, as implementaremos los mtodos de la cabecera generados por JNI con cdigo C e o estndar y llamadas a mtodos Objective-C. Estos mtodos Objective-C se ena e e cargaran de hacer las llamadas a la API CoreWLAN y devolver los resultados. Como veremos ms adelante, son necesarias algunas conversiones entre tipos a Objective-C y C, ya que JNI depende unicamente de los tipos bsicos C tales a como int, char, oat, etc.

B.2.3.

Accediendo a CoreWLAN

El siguiente paso consiste en implementar nuestras llamadas a la API CoreWLAN para ser accedidas desde los cheros de implementacin de JNI: o / S p o t t e r . h / #d e f i n e SIZEOF SSID 33 #d e f i n e SIZEOF BSSID 18 #d e f i n e MAX APS 32 v o i d t h r o w s p o t t e r e x c e p t i o n ( c h a r message ) ; t y p e d e f v o i d ( SawAPFunction ) ( c h a r b s s i d , c h a r s s i d , i n t r s s , i n t wep , i n t infrMode ) ; void s p o t t e r i n i t ( const char interfaceName ) ; void spotter shutdown ( ) ; i n t s p o t t e r p o l l ( SawAPFunction f n ) ; @end

/ W i f i . h / #import <Cocoa / Cocoa . h> #import <CoreWLAN/CoreWLAN . h> #import s p o t t e r . h @ i n t e r f a c e W i f i : NSObject s t a t i c Wifi i n s t a n c e = n i l ; + ( Wifi ) getWifi ;

( i n t ) s p o t t e r p o l l : ( SawAPFunction ) f n ; ( void ) s p o t t e r i n i t ; ( void ) spotter shutdown ; @end

153

/ W i f i .m / #import w i f i . h @implementation W i f i + ( Wifi ) getWifi { i f ( i n s t a n c e == n i l ) { instance = [ [ super a l l o c ] i n i t ] ; } return instance ; }

( i n t ) s p o t t e r p o l l : ( SawAPFunction ) f n { NSAutoreleasePool pool = [ [ NSAutoreleasePool a l l o c ] i n i t ] ; NSError e r r = n i l ; NSDictionary params = n i l ; NSArray s c a n = [ NSMutableArray arrayWithArray : [ [ CWInterface i n t e r f a c e ] scanForNetworksWithParameters : params e r r o r :& e r r ] ] ; int i = 0; f o r ( i = 0 ; i < [ s c a n count ] ; i ++) { NSNumber N S r s s i = [ [ scan objectAtIndex : i ] r s s i ] ; NSNumber NSsecurityMode = ( [ [ scan objectAtIndex : i ] securityMode ] ) ; i f ( [ NSsecurityMode i n t V a l u e ] > 0 ) NSsecurityMode = [ NSNumber numberWithInt : 1 ] ; NSString NSbssid = [ [ scan objectAtIndex : i ] b s s i d ] ; NSString NSssid = [ [ scan objectAtIndex : i ] s s i d ] ; BOOL N S i n f r = ! [ [ scan objectAtIndex : i ] isIBSS ] ; int r s s i = [ NSrssi intValue ] ; i n t securityMode = [ NSsecurityMode i n t V a l u e ] ; char b s s i d = [ NSbssid UTF8String ] ; 154

char s s i d = [ NSssid UTF8String ] ; i n t i n f r = NSinfr ? 1 : 0; i f ( f n != NULL) { ( fn ) ( bssid , ssid , r s s i , i n f r , securityMode ) ; } [ pool r e l e a s e ] ; return 0; }

( v o i d ) s p o t t e r i n i t {} ( void ) spotter shutdown { [ instance dealloc ] ; } @end Spotter.h es un archivo de cabecera de placelab que dene los tipos bsicos a y mtodos necesarios para la implementacin de las librer nativas. e o as Wi es una clase Objective-C que implementa un patrn singleton y que o proporciona implementaciones de los mtodos spotter poll, spotter init y spote ter shutdown, necesitados por placelab. En la implementacin de Wi (Wi.m) se llevan a cabo las conversiones de o tipos Objective-C (Bool, NSString, NSNumber) a tipos C estndar (char*, int). a

B.2.4.

Implementacin de la Librer Nativa o a

El ultimo paso consiste en la implementacin de el chero de cabecera gene o rado por JNI. En nuestro caso implementaremos las funciones nativas de PlaceLab mediante cdigo C y llamadas a nuestros mtodos Objective-C de acceso o e al hardware wi tal y como se ha explicado en las secciones anteriores: / j n i .m / #import #import #import #import < j n i . h> <s t r i n g . h> o r g p l a c e l a b s p o t t e r W i F i S p o t t e r . h w i f i . h

#import <Cocoa / Cocoa . h> s t a t i c JNIEnv currentJNIEnv ; s t a t i c i n t s p o t t e r i n i t i a l i z e d =0;

155

s t a t i c v o i d saw ap ( c h a r b s s i d , c h a r s s i d , i n t r s s , i n t wep , i n t infrMode ) ; s t a t i c void r e s e t c n t ( ) ; s t a t i c j o b j e c t A r r a y g i m m e j a v a a p s ( JNIEnv env , j o b j e c t obj ) ;

JNIEXPORT v o i d JNICALL Java org placelab spotter WiFiSpotter spotter 1init ( JNIEnv env , j o b j e c t j o b j , j s t r i n g i n t e r f a c e N a m e ) { currentJNIEnv = env ; s p o t t e r i n i t i a l i z e d = 1; }

JNIEXPORT v o i d JNICALL Java org placelab spotter WiFiSpotter spotter 1shutdown ( JNIEnv env , j o b j e c t o ) { currentJNIEnv = env ; s p o t t e r i n i t i a l i z e d = 0; }

JNIEXPORT j o b j e c t A r r a y JNICALL Java org placelab spotter WiFiSpotter spotter 1poll ( JNIEnv env , j o b j e c t o b j ) { currentJNIEnv = env ; Wifi t = [ Wifi getWifi ] ; i f ( ! s p o t t e r i n i t i a l i z e d ) r e t u r n NULL; reset cnt (); i f ( [ t s p o t t e r p o l l : saw ap ] < 0 ) r e t u r n NULL; r e t u r n g i m m e j a v a a p s ( env , o b j ) ; }

// static static static static static static c h a r s s i d s [MAX APS ] [ SIZEOF SSID ] ; c h a r b s s i d s [MAX APS ] [ SIZEOF BSSID ] ; int rsss [MAX APS ] ; i n t aps [MAX APS ] ; i n t weps [MAX APS ] ; i n t sawCnt =0; 156

void t h r o w s p o t t e r e x c e p t i o n ( c h a r message ) { j c l a s s s p o t t e r E x C l s= ( currentJNIEnv)>F i n d C l a s s ( currentJNIEnv , org / p l a c e l a b / s p o t t e r / SpotterException ) ; i f ( s p o t t e r E x C l s != NULL) { ( currentJNIEnv)> ThrowNew ( currentJNIEnv , s p o t t e r E x C l s , message ) ; } ( currentJNIEnv)>D e l e t e L o c a l R e f ( currentJNIEnv , spotterExCls ) ; } s t a t i c void reset cnt () { sawCnt = 0 ; } s t a t i c void saw ap ( c h a r b s s i d , c h a r s s i d , i n t r s s , i n t wep , i n t infrMode ) { i f ( sawCnt > (MAX APS1)) { return ; } s t r c p y ( s s i d s [ sawCnt ] , s s i d ) ; s t r c p y ( b s s i d s [ sawCnt ] , b s s i d ) ; r s s s [ sawCnt ] = r s s ; aps [ sawCnt ] = infrMode ; weps [ sawCnt ] = wep ; sawCnt++; }

s t a t i c jobjectArray g i m m e j a v a a p s ( JNIEnv env , j o b j e c t o b j ) { jstring str ; char l o c S t r [ 6 4 ] ; int i ; j o b j e c t A r r a y newArr = ( env)>NewObjectArray ( env , sawCnt 5 , ( env)> F i n d C l a s s ( env , j a v a / l a n g / S t r i n g ) ,NULL ) ; f o r ( i =0; i <sawCnt ; i ++) { s t r= ( env)>NewStringUTF ( env , b s s i d s [ i ] ) ; 157

( env)>SetObjectArrayElement ( env , newArr , i 5 , s t r ) ; ( env)>D e l e t e L o c a l R e f ( env , s t r ) ; s t r= ( env)>NewStringUTF ( env , s s i d s [ i ] ) ; ( env)>SetObjectArrayElement ( env , newArr , i 5+1 , s t r ) ; ( env)>D e l e t e L o c a l R e f ( env , s t r ) ; s p r i n t f ( l o c S t r , %d , r s s s [ i ] ) ; s t r= ( env)>NewStringUTF ( env , l o c S t r ) ; ( env)>SetObjectArrayElement ( env , newArr , i 5+2 , s t r ) ; ( env)>D e l e t e L o c a l R e f ( env , s t r ) ; s p r i n t f ( l o c S t r , %d , weps [ i ] ) ; s t r= ( env)>NewStringUTF ( env , l o c S t r ) ; ( env)>SetObjectArrayElement ( env , newArr , i 5+3 , s t r ) ; ( env)>D e l e t e L o c a l R e f ( env , s t r ) ; s p r i n t f ( l o c S t r , %d , aps [ i ] ) ; s t r= ( env)>NewStringUTF ( env , l o c S t r ) ; ( env)>SetObjectArrayElement ( env , newArr , i 5+4 , s t r ) ; ( env)>D e l e t e L o c a l R e f ( env , s t r ) ; } r e t u r n newArr ; }

B.2.5.

Resultado y Conclusin o

La librer resultante, libspotter.jnilib, una vez aadida a la carpeta de lia n brer nativas de PlaceLab, funcin correctamente permitindonos realizar un as o e anlisis de dicho software en nuestra mquina con Mac OS X. a a En general, trabajar con JNI entraa bastante complejidad debido a las conn versiones que hay que hacer entre tipos y objetos de cada lenguaje, y creemos que solo merece la pena en aquellos casos en los que no quede ms remedio que a utilizar una librer nativa. a

158

Anexo C

Exportando mallas .obj con Blender

C.1. Introduccin o

Blender es una herramienta gratuita de modelado en 3D dimensiones. Puedes decargarla e instalarla desde su pgina web1 . a Blender permite la exportacin de mallas en formato *.obj, renderizables por o Look!. En el siguiente anexo se explican los pasos a seguir para la exportacin o de mallas en este formato, de modo que sean compatibles con Look!.

C.2.

Exportando mallas

Para exportar mallas en *.obj, debes seguir los siguientes pasos: 1. Crea la malla con blender (Figura C.1) 2. Una vez creada la malla, en Edit mode, elije en el men inferior, Mesh u Faces - Quads to Trs (Figura C.2). Esto convertir todas las caras de tu a malla en tringulo. Paso necesario para que sean procesables por Look!. a 3. Despus, ve al men File - Export - Wavefront (*.obj ) y elige la carpeta e u dnde quieras guardar el archivo, y en las opciones Export OBJ, seleco ciona: Normals, High Quality Normals, UVs. (Figura C.3) Ya tendrs una a archivo de malla 3D para mostrar en Look!.

1 http://www.blender.org

159

Figura C.1: Creando una malla con Blender

Figura C.2: Creando una malla con Blender

Figura C.3: Exportando la malla a una archivo .obj

160