Desarrollo de una aplicación de posicionamiento mediante Wifi ...

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

INGENIERÍA EN INFORMÁTICA

PROYECTO FIN DE CARRERA

Desarrollo de una aplicación de

posicionamiento mediante Wifi en

plataforma Android

PABLO SUAZO FERNÁNDEZ

MADRID, febrero de 2010

Autorizada la entrega del proyecto al alumno:

Pablo Suazo Fernández

EL DIRECTOR DEL PROYECTO

Giovanni Arturo Vecchione

Fdo: Fecha:

EL CO-DIRECTOR DEL PROYECTO

José Luis Gahete Díaz

Fdo: Fecha:

Vº Bº del Coordinador de Proyectos

David Contreras Bárcena

Fdo: Fecha:

Agradecimientos iii

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

INGENIERÍA EN INFORMÁTICA

PROYECTO FIN DE CARRERA

Desarrollo de una aplicación de

posicionamiento mediante Wifi en

plataforma Android

PABLO SUAZO FERNÁNDEZ

MADRID, febrero de 2010

Agradecimientos iv

El futuro tiene muchos nombres.

Para los débiles es lo inalcanzable.

Para los temerosos, lo desconocido.

Para los valientes es la

oportunidad.

Victor Hugo

Agradecimientos v

Agradecimientos

No ha sido fácil y he recorrido un gran camino para terminar este proyecto, aunque no

habría sido posible sin el apoyo y la ayuda de muchas personas.

En primer lugar, me gustaría agradecer a mis padres el apoyo recibido, en todos los

momentos de mi vida en que me han hecho falta y en especial en este proyecto, gracias

por vuestra confianza en mí.

También querría agradecer a todos mis amigos, por estar a mi lado y ayudarme a

desconectar cuando era necesario. No podría haber hecho esto solo y me alegro de

haber contado con vosotros.

No podría desaprovechar la ocasión para agradecer a Jose Luis Gahete Diaz todo el

apoyo e interés que ha demostrado durante mi paso por la Universidad, más allá de la

mera obligación académica.

Mis agradecimientos para la Universidad y para todos los profesores y demás personas

que han contribuido a mi formación como ingeniero y como persona, me he cruzado

con gente magnífica.

Gracias a GMV por permitirme realizar este proyecto. En especial quiero agradecer a

Manuel Toledo y a Jose Javier Rosales por contactarme y elegirme para el proyecto y a

Giovanni A. Vecchione por ayudarme en el día a día.

A todas las personas que me han apoyado y han creido en mí, muchas gracias por

todo.

Resumen vi

Resumen

La idea de este proyecto ha surgido por el vacío tecnológico existente en relación al

posicionamiento en interiores. El propósito del mismo consiste en el desarrollo de una

aplicación que sea capaz de establecer la posición del usuario en interiores mediante la

detección de la potencia de las redes WiFi colindantes. La implementación realizada se

ejecuta en un teléfono móvil que emplea el sistema operativo para dispositivos móviles

desarrollado por Google: Android.

Se ha preferido esta plataforma; Android; sobre otras al considerar múltiples

aspectos positivos que justifican esta elección. Está basada en código fuente abierto, por

lo que el soporte es global, con un montón de programadores en todo el mundo

dispuestos a corregir errores. Las aplicaciones se desarrollan en Java, un lenguaje

maduro y ampliamente adoptado. Está basada en el concepto de aplicaciones “en la

nube”, es decir, emplear aplicaciones online para realizar el trabajo que hasta ahora se

hacía mediante aplicaciones instaladas en el equipo del usuario y utilizar como medio

de almacenamiento un espacio virtual localizado en un servidor de Internet. No

debemos olvidar que detrás de esta iniciativa está la Open Handset Alliance, una

asociación entre empresas fabricantes de móviles y proveedores de telefonía móvil.

Destacar a Google como el principal impulsor de dicha alianza. Es de suponer que esta

plataforma dará mucho de qué hablar en un futuro, y ciertamente está logrando una

gran expectación y predisposición de los fabricantes de hardware y del público

especializado (y cada vez ampliándose a más tipo de público).

La memoria tiene unas partes teóricas para entender los conceptos y diseñar la

solución, otras prácticas que describen el proceso de construcción y funcionamiento de

la aplicación y los manuales necesarios para configurar el entorno de desarrollo y

utilizar el prograa. Además, en los anexos se incluye el código fuente agrupado en

paquetes, por si se desea conocer la solución adoptada o es necesario revisar algún

aspecto de la implementación.

En estas páginas se van a explicar algunas características de la señal utilizada en

802.11, para seguidamente describir las técnicas que explotan dichas características y

por tanto pueden ser aprovechadas para resolver el problema del posicionamiento en

interiores. El siguiente paso es el estudio de los diferentes algoritmos de

Resumen vii

posicionamiento y sus ventajas y desventajas. Hasta aquí la parte teórica de la

memoria. La conclusión de esta parte es que lo más conveniente es emplear la potencia

recibida de señal como punto de partida para resolver el problema.

Respecto al algoritmo de posicionamiento, se ha escogido, por su sencillez de

implementación y sus bajos requisitos técnicos (tanto de CPU como de memoria)

consecuencia de su baja complejidad, el KNN (K-nearest neighbours). Es un algoritmo

de clasificación supervisada que permite establecer, gracias a un entrenamiento previo,

una estimación de la posición que ocupa el usuario de la aplicación. La elección parece

adecuada al ser la primera versión de la aplicación, puesto que al ser un dispositivo

móvil con menores recursos y autonomía que un ordenador convencional el encargado

de ejecutarla, se debe comenzar el desarrollo empleando algoritmos sencillos que

permitan concentrarse en obtener una solución al problema, sin distracciones causada

por las limitaciones del dispositivo.

El proyecto cuenta con una componente de Inteligencia Artificial, ya que KNN es

empleado para solucionar con éxito problemas de otra índole, combinado con el

fingerprinting. Básicamente, se debe crear una base de datos con unas muestras en

determinados puntos del lugar donde se quiere realizar posteriormente el posicionado.

Estas muestras contienen la potencia recibida desde los diferentes puntos de acceso

detectados. El algoritmo permitirá establecer qué posiciones dentro del sistema son

posibles y en qué grado, obteniendo una localización aproximada.

En la parte práctica, se puede encontrar un manual de instalación donde se podrá

poner a punto el entorno de desarrollo de una manera fácil y cómoda. Se ha incluido

por considerar que el conocimiento sobre Android aún es escaso. Es de esperar que, a

medida que aumenten tanto el número de dispositivos que lo emplean como el número

de desarrolladores y de aplicaciones, los conceptos en este campo serán más valorados.

Seguidamente se describe el proceso de desarrollo de la aplicación, tanto su diseño

como programación. El lenguaje empleado, como se ha mencionado anteriormente, es

Java. Se emplea una API publicada por Google y que se actualiza en cada nueva

versión del Sistema Operativo. Se ha prestado especial atención a documentar todas las

clases que conforman este programa, empleando diagramas de clases para visualizar

sus relaciones y dependencias. También se incluyen las pruebas, las mejoras

consideradas y el desarrollo futuro.

Resumen viii

Como resultado de las pruebas, no sólo se puede decir de manera cualitativa que el

posicionamiento indoor es posible, sino que los resultados cuantitativos reflejan un

error de posición menor de 3 metros. Se puede decir que esta aplicación es el esqueleto

de un programa que podría servir para el posicionamiento en cualquier circunstancia,

combinando técnicas de posicionamiento tanto en interiores como en el exterior (GPS,

por ejemplo). El valor de la aplicación podría ser bastante elevado, al cubrir una

problemática para la que aún no hay muchas soluciones precisas.

Se deben mencionar futuras mejoras del algoritmo, que incluyen el empleo de

algoritmos probabilísticos u otros métodos pertenecientes a ámbito de la Inteligencia

Artificial, uso de preprocesado y postprocesado, como el filtrado de Kalman con objeto

de mejorar la precisión y exactitud de la estimación respecto a la posición real.

No se podía completar este trabajo sin incluir un manual de explotación, que

permitirá a usuarios sin conocimientos usar la aplicación. Se adjuntan capturas de

pantalla de la aplicación para explicar mejor su uso.

Para finalizar la memoria, se incluye tanto el presupuesto como la planificación que

se han seguido a lo largo del proyecto. Indicar que se han cumplido los plazos y el

presupuesto ha sido bastante reducido, por lo que se puede decir que se han

optimizado los recursos.

Por último, añadir que la realización de este proyecto abarca dos grandes temas que

serán cada vez de mayor importancia en el futuro: la localización en interiores y

Android, por lo que adquirir destrezas en ambos supone un gran valor añadido para

un Ingeniero Informático. La investigación de los algoritmos de posicionamiento y el

desarrollo en una plataforma nueva como Android, han puesto a prueba muchos

conceptos aprendidos durante la carrera, permitiendo realizar un proyecto interesante

y actual.

Summary ix

Summary

The lack of a reliable service for indoor positioning has been the main motivation

for starting this project. The scope of this project is developing an application that will

be able to establish the user's position by polling the received signal strength of the

surrounding Wi-Fi networks (RSSI); the final implementation may run on a mobile

phone using Android, the operating system for mobile devices developed by Google.

This platform is preferred because for its multiple advantages: it is based on open

source code, so the support is global, with a lot of programmers around the world

willing to correct bugs and improve its functionality. Android is based on the concept

of “cloud computing”, i.e. employing online applications to make the work and using

as storage medium the virtual space on an Internet server, instead of using programs

installed on the user's computer, the main language for development is Java, a mature

and widely adopted language.

The Android project has been launched by a consortium of company (the Open

Handset Alliance) composed by the major handset produces and mobile operators,

with Google as a main actor. The platform has been adopted by the marked with much

interest and presumably, this platform will continue to grow up in the future,

practically every month new handsets with Android are presented by hardware

manufacturers gaining the favor of the market.

The report is divided in several parts: the first part of the report contains the theory

supporting the adopted solution, then the development and testing of the application

is described. Last part contains a description about the necessary steps to configure the

integrated development environment successfully and a user manual.

The signal characteristics of 802.11 will be explained on these pages: this is useful to

understand the positioning algorithm used to solve the indoor positioning problem.

Here the state of the art of positioning algorithms has been analyzed: as a conclusion it

has been highlighted that using the received signal strength is the best choice to solve

the problem.

The positioning algorithm used is the K-nearest neighbors (KNN), chosen for its

easy implementation and its low technical requirements, both CPU and memory. It is a

Summary x

supervised classification algorithm that, using some previous training examples,

estimates the position of the user; as already said this algorithm doesn’t have high

complexity which makes it suitable for a portable device implementation. The

development must start using simple algorithms that allows focusing on getting a

solution to the problem, not necessarily the best but eliminating distractions caused by

the hardware limitations of the device.

The project has an AI (Artificial Intelligence) component, since KNN is successfully

used to solve other problems, combined with the fingerprinting technique. It creates a

database with samples points of the place where indoor positioning will be used, these

samples contain the received signal strength of all the access points detected, using this

database the algorithm will determine which positions within the system are possible

and more probable, obtaining an approximate location.

The last part of the report contains a user manual, which describes the process for

tuning the development environment in an easy and convenient way. It is included

because the knowledge about Android is still low. Hopefully, as the number of devices

that use it as the number of developers and applications increase, the concepts in this

field will be more appreciated.

Below the development process of implementation is described, both the design and

application programming. The language used, as mentioned above, is Java, it uses an

API released by Google that is updated with each new OS version. It has paid

particular attention in the documentation of all the classes that conforms the program,

using class diagrams to visualize their relationships and dependencies. Tests,

improvements and future development are also included.

As a result of the tests, not only it can be said that the indoor positioning is possible

in a qualitative form, but quantitative results reflect a positioning error less than 3

meters. This application is the skeleton of a program that could be used for positioning

in any circumstance, combining both indoor and outdoor positioning techniques; i.e.

GPS. The application value could be quite high, covering a problem for which many

solutions are not very precise taking advantage also by the use of COTS (Commercial

Off-The-Shelf) equipment.

Summary xi

Future improvements of the algorithm, including the use of probabilistic algorithms

or other artificial intelligence methods, the use of preprocessing and post processing

such Kalman filtering are foreseen to improve precision and accuracy.

This report cannot be finished without the inclusion of a user’s guide allowing

inexperienced users to be managed using the application. Find attached some

screenshots of the application to explain its use in a better way.

To close this report, it is included both the budget and planning that have been

followed throughout the project. The deadlines have been met and the budget was

fairly small, so it can be said that resources are optimized.

Finally, the realization of this project comprises two main issues that will become

more important in the future: the indoor location and Android. Acquiring skills in both

issues is a great value for a Computer Engineer. Investigation of positioning algorithms

and developing in a new platform as Android have been tested many concepts learned

during the career, allowing to realize an interesting and a very up-to date project.

Índice xii

Índice

1 CONCEPTOS SOBRE LAS CARACTERÍSTICAS DE LA SEÑAL EN 802.11 ...................... 21

1.1 Introducción ...................................................................................................... 21

1.2 Potencia de señal .............................................................................................. 21

1.3 Potencia RSS ...................................................................................................... 21

1.4 Calidad de la señal ........................................................................................... 22

1.5 Ratio Señal-Ruido ............................................................................................. 22

1.6 Sensibilidad del receptor ................................................................................. 23

1.7 Margen de atenuación ..................................................................................... 23

2 ALGORITMOS DE LOCALIZACIÓN ......................................................................................... 26

2.1 Introducción ...................................................................................................... 26

2.2 Técnicas de localización mediante señales electromagnéticas .................. 26

2.2.1 TOA 26

2.2.2 TDoA 27

2.2.3 AoA 27

2.2.4 RSS 28

2.3 Fingerprinting ................................................................................................... 28

2.3.1 Fase de entrenamiento 29

2.3.2 Fase de obtención de la posición 30

2.3.2.1 Algoritmo determinista .............................................................................................. 31

2.3.2.2 Algoritmo probabilístico ............................................................................................ 33

2.3.2.3 Otros algoritmos .......................................................................................................... 33

2.4 Mejoras en el algoritmo de localización ........................................................ 33

2.4.1 Preprocesado 33

2.4.2 Postprocesado 34

2.4.2.1 Filtrado de Kalman ..................................................................................................... 34

3 ENTORNO DE DESARROLLO ..................................................................................................... 37

3.1 Introducción ...................................................................................................... 37

3.2 Elección del sistema operativo ....................................................................... 37

3.2.1 Windows 37

3.2.2 Linux 38

3.2.3 Linux vs Windows 39

3.3 Instalación de Java ............................................................................................ 40

Índice xiii

3.4 Instalación del entorno de desarrollo: Eclipse ............................................. 41

3.5 Instalación del Android SDK .......................................................................... 42

3.6 Instalación del plugin en el entorno de desarrollo: Eclipse ....................... 43

3.7 Emulador de Android ...................................................................................... 45

3.7.1 Creación dispositivo virtual 45

3.7.2 Ejecución del dispositivo virtual 48

3.7.3 Observaciones sobre el emulador 50

3.8 Consideraciones para el desarrollo en Ubuntu 64 bits ............................... 51

4 DESARROLLO DE LA APLICACIÓN ......................................................................................... 53

4.1 Introducción ...................................................................................................... 53

4.2 Fase de diseño ................................................................................................... 53

4.3 Fases de desarrollo ........................................................................................... 54

4.3.1 Generación base datos 55

4.3.2 Generación archivos 55

4.3.3 Wipode 56

4.3.4 Portar Generación base datos 56

4.3.5 Integración módulos 57

4.3.6 Pruebas usuario 57

4.4 Descripción de las clases ................................................................................. 57

4.4.1 Paquete gmv.android 58

4.4.2 Paquete gmv.android.archivo 58

4.4.3 Paquete gmv.android.bd 59

4.4.4 Paquete gmv.android.configuracion 61

4.4.5 Paquete gmv.android.debug 61

4.4.6 Paquete gmv.android.localizacion 62

4.4.7 Paquete gmv.android.localizacion 64

4.4.8 Paquete gmv.android.notificaciones 64

4.4.9 Paquete gmv.android.proceso 65

4.4.10 Paquete gmv.android.wifi 66

4.5 Diagramas de clases ......................................................................................... 66

4.5.1 Menú principal 67

4.5.2 Generación Archivos 67

4.5.3 Generación BD 68

4.5.4 Wipode 69

4.6 Fase de pruebas ................................................................................................ 69

4.6.1 Pruebas batch 70

Índice xiv

4.6.2 Pruebas online 70

4.6.3 Pruebas rendimiento 70

4.6.3.1 Menú principal ............................................................................................................ 71

4.6.3.2 Generación archivos ................................................................................................... 72

4.6.3.3 Generación BD ............................................................................................................. 73

4.6.3.4 Wipode ......................................................................................................................... 74

4.7 Planificación ...................................................................................................... 74

4.7.1 Planificación de tareas 75

5 PRESUPUESTO ................................................................................................................................ 79

5.1 Introducción ...................................................................................................... 79

5.2 Presupuesto ....................................................................................................... 79

6 CONCLUSIONES Y TRABAJOS FUTUROS .............................................................................. 82

6.1 Conclusiones ..................................................................................................... 82

6.2 Trabajos futuros ................................................................................................ 82

6.2.1 Algoritmo de localización 82

6.2.2 Sensores 83

6.2.3 Localización exteriores 83

6.2.4 Configuración 83

6.2.5 Empleo servidor 83

6.2.6 Multimapa 84

6.2.7 Uso del contexto 84

6.2.8 Guiado 84

6.2.9 Facilidades para ciegos 85

6.2.10 Localización dispositivo 85

7 BIBLIOGRAFÍA ................................................................................................................................ 87

8 ANEXOS ............................................................................................................................................. 90

A MANUAL DE EXPLOTACIÓN ..................................................................................................... 92

A.1 Introducción ...................................................................................................... 92

A.2 Instalación .......................................................................................................... 92

A.3 Ejecución ............................................................................................................ 95

A.4 Menú principal ................................................................................................. 95

A.5 Generación archivos ......................................................................................... 96

A.6 Generación base datos ................................................................................... 102

A.7 Wipode ............................................................................................................. 104

A.8 Control de errores .......................................................................................... 107

Índice xv

A.8.1 Generación arc hivos 107

A.8.2 Generación base datos 108

A.8.3 Wipode 109

B LAYOUTS ........................................................................................................................................ 111

B.1 Main.xml .......................................................................................................... 111

B.2 GenArch.xml ................................................................................................... 114

B.3 Wipode.xml ..................................................................................................... 119

C MANIFEST, STRING Y PROPIEDADES .................................................................................. 122

C.1 Manifest ........................................................................................................... 122

C.2 Strings.xml ....................................................................................................... 125

C.3 default.properties ........................................................................................... 126

Índice de Figuras xvi

Índice de Figuras

Figura 1. Obtención de la posición ........................................................................................................ 31

Figura 2. Cálculo de distancia j .............................................................................................................. 32

Figura 3. Cálculo del centro de masas .................................................................................................. 32

Figura 4. Filtrado de Kalman ................................................................................................................. 35

Figura 5. Gestor del SDK de Android .................................................................................................. 42

Figura 6. Instalación del plugin de Android en Eclipse ..................................................................... 44

Figura 7. Configuración del plugin de Android en Eclipse ............................................................... 45

Figura 8. Opciones de creación de un dispositivo virtual ................................................................. 46

Figura 9. Confirmación en la creación del dispositivo virtual .......................................................... 47

Figura 10. Administrador de dispositivos virtuales ........................................................................... 47

Figura 11. Dispositivo virtual cargando Android ............................................................................... 48

Figura 12. Dispositivo virtual bloqueado ............................................................................................. 49

Figura 13. Escritorio del dispositivo virtual ........................................................................................ 49

Figura 14. Dispositivo virtual en modo panorámico .......................................................................... 50

Figura 15. Instalación ia32-libs .............................................................................................................. 51

Figura 16. DFD Aplicación ..................................................................................................................... 54

Figura 17. Fases de desarrollo, pruebas y entregables ....................................................................... 54

Figura 18. Diagrama de clases del menú principal ............................................................................. 67

Figura 19. Diagrama de clases de Generación archivos ..................................................................... 67

Figura 20. Diagrama de clases de Generación BD .............................................................................. 68

Figura 21. Diagrama de clases de Wipode ........................................................................................... 69

Figura 22. Uso CPU Menú principal ..................................................................................................... 71

Figura 23. Uso Memoria Menú principal ............................................................................................. 71

Figura 24. Uso CPU Generación Archivos ........................................................................................... 72

Figura 25. Uso Memoria Generación Archivos ................................................................................... 72

Figura 26. Uso CPU Generación BD ..................................................................................................... 73

Figura 27. Uso Memoria Generación BD .............................................................................................. 73

Figura 28. Uso CPU Wipode .................................................................................................................. 74

Figura 29. Uso Memoria Wipode .......................................................................................................... 74

Figura 30. Diagrama Gantt de la planificación del proyecto ............................................................. 76

Figura 31. Icono del instalador de Wipode .......................................................................................... 92

Figura 32. Ventana de detalles del paquete ......................................................................................... 93

Figura 33. Confirmación de la instalación ........................................................................................... 93

Figura 34. Proceso de instalación .......................................................................................................... 94

Figura 35. Notificación de instalación completada ............................................................................. 94

Índice de Figuras xvii

Figura 36. Icono ejecución de Wipode .................................................................................................. 95

Figura 37. Menú principal ...................................................................................................................... 96

Figura 38. Ventana principal de Generación de archivos .................................................................. 97

Figura 39. Introducción de coordenadas .............................................................................................. 97

Figura 40. Especificación del retardo .................................................................................................... 98

Figura 41. Activación Wifi en la Generación de Archivos ................................................................. 99

Figura 42. Comienzo del muestreo ....................................................................................................... 99

Figura 43. Proceso de muestreo ........................................................................................................... 100

Figura 44. Finalización del muestreo .................................................................................................. 101

Figura 45. Resumen del muestreo ....................................................................................................... 101

Figura 46. Comienzo del procesado de archivos .............................................................................. 102

Figura 47. Procesando archivos ........................................................................................................... 103

Figura 48. Fin de proceso ..................................................................................................................... 103

Figura 49. Wipode ................................................................................................................................. 104

Figura 50. Activación de Wifi .............................................................................................................. 105


Figura 52. Posición determinada por Wipode ................................................................................... 106

Figura 53. Desactivación Wifi .............................................................................................................. 106

Figura 54. Mensaje de error por no informar las coordenadas ....................................................... 107

Figura 55. Mensaje de error por introducir caracteres no váldos en las coordenadas ................. 108


Figura 57. Error en Wipode al no existir la base de datos ............................................................... 109

Índice de Tablas xviii

Índice de Tablas

Tabla 1. Tabla con las posiciones y sus vectores de potencia asociados .......................................... 29

Tabla 2. Planificación proyecto .............................................................................................................. 75

Tabla 3. Presupuesto del proyecto ........................................................................................................ 79

1 Conceptos sobre las

características de la señal en

802.11b/g

1 Conceptos sobre las características de la señal en 802.11b/g 21

1 Conceptos sobre las características de la señal en 802.11b/g

1.1 Introducción

Las tecnologías wireless empleadas actualmente; más concretamente el estándar

802.11; introducen unos nuevos conceptos relacionados con la señal. Si bien el

significado de estos conceptos puede inferirse de manera intuitiva, al ser conceptos

interrelacionados pueden ser empleados de manera incorrecta o inexacta. Es por esto

que a continuación se explicarán algunos de estos conceptos y su importancia a la hora

de crear una red inalámbrica.

1.2 Potencia de señal

La potencia de la señal recibida, se mide, normalmente, en mW o dBm.

Se usa dBm por ser más simple a la hora de representar la potencia de una señal.

Las fórmulas para calcular la equivalencia dBm-mW son:

dBm = log (mW) * 10

mW = 10 ^(dBm/10)

De manera intuitiva, si la potencia medida en mW se reduce a la mitad, esto supone

un descenso de aproximadamente 3 dBm, y si la potencia medida en mW aumenta al

doble, esto supondrá un incremento aproximado de 3 dBm.

1.3 Potencia RSS

La potencia de señal RSS1 utilizada en 802.11 es un valor entero que depende del

fabricante del chip inalámbrico empleado. Entre dos fabricantes no tiene por qué haber

una conversión o equivalencia directa, por lo que las mediciones realizadas con el chip

1 Received Signal Strength (Potencia señal recibida)


de un fabricante no son válidas para otro chip de otro fabricante. Esto es porque cada

fabricante calcula este valor de una forma distinta y la escala no es igual.

Por ejemplo, Atheros usa una escala de 0-60, Symbol una escala de 0-31 y Cisco una

escala de 0-100.

En general, valores mayores denotan una mayor potencia de señal recibida. Estos

valores son usados de manera interna por el controlador, para, por ejemplo, saber

cuándo cambiar a otro AP2 con mayor potencia, qué modulación se debe usar, la

potencia de emisión…

1.4 Calidad de la señal

La calidad de la señal es calculada a partir del número de errores que se produzcan

en la capa de enlace. Por lo tanto es un buen indicador de las perturbaciones o

interferencias que produce el entorno en la señal recibida desde el emisor.

Como en el caso de la Potencia RSS, cada fabricante usa su propio método para

calcular la calidad de la señal.

1.5 Ratio Señal-Ruido

Este término suele ser incorrectamente definido por una confusión de conceptos.

Desde el punto de vista de un diseñador de un chip de radiofrecuencia, el ratio

señal-ruido se referirá a la potencia de la señal recibida respecto al ruido producido por

el chip. Este ruido es producido por el simple hecho de la circulación de electricidad y

del calor que ésta genera. Esto es conocido como ruido Boltzmann.

Desde el punto de vista de un administrador de 802.11, el ratio señal-ruido podría

ser interpretado como la señal recibida respecto al ruido ambiente (interferencias

producidas por el entorno). Esto es incorrecto, ya que esto debería ser definido como el

ratio señal-interferencias.

2 Access Point (Punto Acceso)


1.6 Sensibilidad del receptor

Es un valor que va asociado con una tasa de bits. Suele medirse en dBm y es

indicado por el fabricante tras realizar una serie de pruebas a sus productos. Por

ejemplo, un receptor indica que puede recibir datos a 1 Mbps con una potencia de

señal de -95 dBm, esto revela que si la señal recibida tiene al menos dicha potencia, se

garantiza que los datos se recibirán a una tasa de 1 Mbps. Por lo tanto se deduce que

cuanto menor sea la sensibilidad (mayor valor negativo) más facilidad tendrá para

recibir datos en casos en que la potencia recibida sea muy baja.

Se suelen indicar intervalos en los que se muestran diferentes tasas de datos para

cada sensibilidad. Si se requieren tasas de datos deseadas, la potencia recibida deberá

ser mayor que si se requieren menores tasas de datos, siempre en el caso de que se

refieran al mismo receptor.

1.7 Margen de atenuación

Es un margen de seguridad que se establece para garantizar una calidad mínima de

la señal.

Por ejemplo, se requiere que en un enlace haya una tasa de datos mínima de 11

Mbps, y el receptor tiene una sensibilidad para dicha tasa de -80 dBm. Esto significa

que la potencia de la señal recibida deberá ser en todo momento mayor o igual a 80

dBm.

Como las señales inalámbricas está sujetas a muchas interferencias producidas por

el entorno, se deberá establecer un margen de seguridad para poder garantizar que la

potencia recibida siempre supere el valor mínimo, ya que interferencias puntuales

podría provocar que no se cumpliera el requisito de potencia y, por tanto, la tasa de

datos no se mantenga al valor deseado.


Normalmente, los administradores de 802.11 determinan que un margen de

atenuación de 10 dB suele ser suficiente, aunque este valor podrá incrementarse en

caso de que se necesite una mayor seguridad.

2 Algoritmos de localización

2 Algoritmos de localización 26

2 Algoritmos de localización

2.1 Introducción

En los últimos años ha habido un incremento en las investigaciones para poder

desarrollar sistemas de localización en interiores. Se pueden encontrar numerosas

soluciones tecnológicas que de una manera más o menos elegante (y precisa) cubren

esta necesidad. La mayoría suelen ser soluciones propietarias, que no siguen ningún

estándar y con poca documentación al respecto.

Centrándose en la localización mediante Wifi, se pueden encontrar muchos estudios

de calidad, realizados en su mayoría por Ingenieros para sus tesis o para la publicación

de artículos. Cabe destacar el sistema RADAR, desarrollado el departamento de

investigación de Microsoft y que supone el punto de partida para los posteriores

estudios que han ido surgiendo.

2.2 Técnicas de localización mediante señales electromagnéticas

Existen varias técnicas de localización que emplean alguna característica de la

sseñales electromagnéticas para determinar la posición. A continuación se detallan

algunas de ellas.

2.2.1 TOA3

Es una técnica basada en el tiempo de propagación de una señal electromagnética.

Ya que existe una relación lineal entre el tiempo de propagación y la distancia entre un

emisor y un receptor, se podría, con un único receptor (con una posición a determinar)

y con varios emisores (cuya posición es conocida), triangular la posición del receptor

basándose en las distancias a los emisores del receptor.

3 Time of Arrival (Tiempo de llegada)


Para calcular dichas distancias, será necesario que los relojes de los emisores y los

receptores estén sincronizados y la distancia sea calculada a partir del tiempo de

propagación desde que es emitida hasta que es recibida.

La principal desventaja de esta técnica es que tendrá que emplear un algoritmo de

sincronización de relojes muy robusto, además del empleo de relojes muy precisos,

para minimizar el error.

2.2.2 TDoA4

Esta técnica es similar a la anterior, en cuanto que emplea la relación lineal que

existe entre el tiempo de propagación y la distancia recorrida, pero en este caso no

necesita que los relojes entre emisores y receptores estén en sincronía. Para ello se

emplea una señal acústica y una electromagnética que se emiten simultáneamente.

Como su velocidad de propagación es distinta (la acústica se propaga a la velocidad

del sonido y la electromagnética a la de la luz), el receptor podrá calcular la distancia

al emisor mediante la diferencia temporal entre la recepción de la señal

electromagnética y la señal acústica.

La ventaja de esta técnica respecto al ToA, es que usa medidas de tiempo relativas,

por lo que se eliminan los errores que pueden aparecer por pequeñas diferencias entre

los relojes.

2.2.3 AoA5

Se basa en el cálculo de la posición mediante el cálculo del ángulo de llegada de la

señal.

Esta técnica tiene dos inconvenientes principales. El primero, que es determinante y

por el cual no la hace válida para posicionamiento indoor, es que requiere que el

emisor y el receptor tengan línea directa de visión para evitar el multipath y poder

4 Time Difference of Arrival (Diferencia de tiempo entre llegadas)

5 Angle of Arrival (Ángulo de llegada)


calcular el ángulo correctamente. El segundo, es que requiere múltiples antenas para

poder calcular el ángulo, por lo que se requiere hardware adicional.

2.2.4 RSS

Su fundamento está basado en la atenuación que sufre la señal a medida que se aleja

de la fuente emisora. Calculando la atenuación sufrida, se puede calcular la distancia al

emisor.

El principal problema es que la atenuación es muy variable ya que depende de

factores externos (además de la distancia) como pueden ser paredes, interferencias de

otras señales, agentes atmosféricos (lluvia, iones, temperatura, luz solar), reflexiones,

objetos, personas…

Aunque este inconveniente puede sugerir que esta técnica no será fiable a la hora de

determinar una posición, finalmente será la opción elegida ya que es la más sencilla de

implementar y no requiere hardware adicional. Asimismo no requiere cálculos ya que

es el propio controlador el que calcula la potencia de la señal recibida.

En vez de emplear la triangulación para calcular la posición, se empleará el

fingerprinting o reconocimiento de patrones, ya que de esta manera se minimiza el

error introducido por los factores externos que contribuyen a la volatilidad de la

atenuación.

2.3 Fingerprinting

Se basa en el reconocimiento de patrones. Para ello, se parte de un área en la cual se

quiere ser capaz de determinar la posición de un receptor. Dicha área debe recibir señal

de varios APs. La señal de los APs debe cubrir todo el área y debe recibirse señal en

todos los puntos del área de al menos 3 APs distintos. Mediante la potencia de la señal

recibida (RSS) de cada AP en un punto, se puede inferir la posición. Al conjunto de

todas las potencias de los APs recibidas en un punto, se le denomina vector de

potencias.

Consta de dos fases:


2.3.1 Fase de entrenamiento

En esta fase, se debe determinar el área que se requiere cubrir. A continuación se

fijarán unos puntos en el interior del área donde se deberán realizar mediciones para

determinar el vector de potencias recibido en cada punto. Se deben estipular el mínimo

número de puntos necesarios para que el error cometido entre la posición calculada y

la real sea aceptable. A mayor número de puntos, serán mayores las necesidades de

almacenamiento, y el uso de memoria y de tiempo de proceso. Aún así, aunque se

dispongan de suficientes recursos, a partir de un determinado número de puntos de

entrenamiento, aunque se incremente el número de puntos, el error no se reduce.

Para reducir errores, es recomendable que en cada punto, la medición del vector de

potencias se realice a distintas horas del día y con distinta orientación del receptor y se

calcule la media. Esto es necesario ya que el propio cuerpo humano atenúa la señal (ya

que opera en la banda de 2,4 GHz, que es justamente la frecuencia de excitación de la

molécula de agua, por lo que al contener el cuerpo humano un 70% de la misma,

absorbe la señal y produce una atenuación), y por esto por lo que se debe el receptor en

varias direcciones en un mismo punto. Además, se debe realizar a distintas horas del

día, porque los factores externos que influyen en la atenuación pueden variar su

influencia dependiendo de la hora (mayor afluencia de personas, temperatura,

máquinas funcionando…).

Finalmente, las posiciones y sus vectores de potencia asociados, se almacenarán en

una tabla del tipo:

X1 Y1 RSSAP1,1 RSSAP2,1 … RSSApi,1 … RSSAPm,1

X2 Y2 RSSAP1,2 RSSAP2,2 … RSSApi,2 … RSSAPm,2

… … … … … … … …

Xj Yj RSSAP1,j RSSAP2,j … RSSApi,j … RSSAPm,j

… … … … … … … …

Xn Yn RSSAP1,n RSSAP2,n … RSSApi,n … RSSAPm,n

Tabla 1. Tabla con las posiciones y sus vectores de potencia asociados


Donde n será el número de puntos que se muestrearán y se almacenarán en la tabla.

El número total de APs será m, que aunque no tengan porque ser todos los que existan

en el área, sí que es necesario que se almacene la potencia recibida de cada uno de ellos

en cada punto.

Por tanto, la potencia RSSApi,j denota la potencia recibida del AP i en el punto j.

Hay que tener en cuenta que estas mediciones serán válidas siempre que no cambie

la posición de ninguno de los APs o se introduzcan nuevos objetos u otros agentes que

puedan atenuar la señal.

2.3.2 Fase de obtención de la posición

En esta fase se obtiene la posición. Para estimar la posición, es necesaria la matriz de

posiciones obtenida en la fase anterior y el vector de potencias de la posición a calcular.

Lo que varía es el algoritmo empleado para realizar la estimación. Principalmente hay

dos tipos de algoritmos empleados en el fingerprinting, los algoritmos deterministas y

los probabilísticos. Ambos tipos de algoritmos son heurísticos, ya que a partir del

entrenamiento previo, se encargan de calcular la posición más aproximada según la

información de entrada y de descartar posiciones para reducir las posibilidades.


Matriz de posiciones

Vector potencias

Algoritmo de localización

(X,Y)

Posición calculada

Figura 1. Obtención de la posición

2.3.2.1 Algoritmo determinista

El principal algoritmo determinista empleado es el KNN (K-Nearest Neighbours),

que trata de obtener los K puntos de la matriz de posiciones más cercanos al vector de

potencia medido. Una vez obtenidos, se promedian y con ello se obtiene la posición.

El algoritmo se describe a continuación:

Se considera el conjunto de mediciones {F(p1), F(p2),… F(pn)} obtenidas de la matriz

de posiciones, siendo F(pj) = (µj1, µj2, …, µjm) donde µjm denota el RSS del AP m en la

posición pj.

Se define r = (r1, r2, …, rm) como el vector de potencias obtenido en la posición a

determinar.

Para cada vector de potencia almacenado en la matriz de posiciones, se calcula su

distancia usando la fórmula de la distancia euclídea, siendo m el número total de APs:

2m

j

22

j

221

j

1 )µ...()µ()µ(1 m

j rrrm

Dist


Figura 2. Cálculo de distancia j

Una vez que están todas las distancias calculadas para todos los vectores de la

matriz de posiciones, se seleccionan los K vectores cuya distancia euclídea al vector de

potencia medido sea menor.

Para promediar los vectores recuperados de la matriz de posiciones, se puede usar

la media aritmética o, preferiblemente, calcular el centro de masas de manera

ponderada, tomando como pesos la inversa de la distancia euclídea calculada, para

otorgar mayor peso a los vectores de potencia más cercanos al vector de potencia

medido.

K

i i

K

i i

i

Dist

Dist

p

p

1

1

1

Figura 3. Cálculo del centro de masas

Este método tiene la ventaja de que es muy fácil de implementar y no requiere

cálculos complejos. Obtiene la posición desde la primera medición y no es necesario un

período de arranque hasta que empiece a proporcionar valores válidos.

El problema que puede surgir es que cuanto mayor sea la matriz de posiciones;

tanto por la longitud de los vectores de potencia (que depende de los diferentes APs

almacenados), como por el número de posiciones almacenadas; mayor será la

complejidad del método.

A pesar de la simplicidad de este método, en pruebas ha demostrado que las

posiciones calculadas son bastante precisas, con un error típico de 3 metros.


2.3.2.2 Algoritmo probabilístico

El principal algoritmo probabilístico empleado es el método del kernel. Este método

estima la posición a partir del cálculo de la función de densidad de las posibles

ubicaciones del entorno.

Con éste algoritmo se suele conseguir una mejor estimación de la posición que con

el KNN, aunque es un poco más compleja la implementación y la ejecución.

2.3.2.3 Otros algoritmos

Otros algoritmos que se podrían emplear podrían ser aquellos basados en redes

neuronales. Se definirían los tamaños de las capas y los pesos asociados a las diferentes

conexiones entre capas y se entrenaría la red con varios ejemplos o con la base de datos

de posiciones y vectores de potencia asociados. Este algoritmo requeriría un mayor

trabajo previo para ajustar la red y permitir que se obtengan buenos resultados.

2.4 Mejoras en el algoritmo de localización

Hay tres formas de mejorar el algoritmo de localización. Una sería realizar un

preprocesado, otra realizar un postprocesado y la tercera sería emplear información

recibida de otros sensores. Estas tres maneras de mejorar la precisión del algoritmo

pueden ser combinadas entre sí aunque hay que tener en cuenta que aumentarían los

requisitos de memoria y procesador, por lo que habría que estudiar la conveniencia de

emplear cada una. Seguidamente se explicará cada alternativa.

2.4.1 Preprocesado

La principal técnica a emplear en esta etapa sería el filtrado espacial. Esto consiste

en eliminar algunas posiciones de la base de datos por ser imposibles o poco probables.

Por ejemplo, una vez que el algoritmo ha arrancado y se conoce una posición válida,

cuando haya que conocer la posición en el siguiente instante de tiempo, lo más


probable es que la posición sea adyacente o cercana, por lo que se podría descartar

puntos de la base de datos que estén muy alejados.

La ventaja del preprocesado es que si se elige una función sencilla que filtre las

posiciones, se puede ahorrar tiempo de proceso cuando el algoritmo calcule la posición

en el siguiente paso, ya que tendrá que calcular las distancias de menos puntos.

Un inconveniente del preprocesado podría aparecer en el caso de que la función que

se escoja no contemple ciertos casos y elimine puntos que deberían ser candidatos, por

lo que el algoritmo perdería precisión.

2.4.2 Postprocesado

Se puede emplear un postprocesado para corregir la posición del sistema como

consecuencia de errores de medida o de ruido. El postprocesado también puede ser útil

para predecir la posición o posiciones que podría tener el sistema en el próximo paso.

2.4.2.1 Filtrado de Kalman

El filtrado de Kalman se encarga de estimar la posición del sistema mediante un

sistema de retroalimentación. Se compone de dos tipos de ecuaciones. El primer tipo de

ecuaciones sirve para predecir la posición en el siguiente paso. El segundo tipo de

ecuaciones se utiliza para corregir la posición y además para ajustar las ecuaciones de

predicción.


Predicción Corrección

Comprobación

Ajuste

Posición anterior

Posición predichaPosición predicha

Posición calculada

Figura 4. Filtrado de Kalman

3 Entorno de desarrollo

3 Entorno de desarrollo 37

3 Entorno de desarrollo

3.1 Introducción

Para implementar la aplicación, la solución más sencilla es la recomendada por

Google en su portal para desarrolladores de Android. Google sugiere emplear el

entorno de desarrollo Eclipse, con el plugin ADT6 que permitirá integrar el SDK7 de

Android para poder utilizarlo en Eclipse.

A continuación se muestran los diferentes pasos que se deben seguir para poner a

punto el entorno de desarrollo, que nos permitirá una programación más eficiente y

por tanto obtener resultados rápidamente.

3.2 Elección del sistema operativo

Google pone a disposición de los desarrolladores un SDK para tres plataformas:

Windows, Mac OS X y Linux.

Por carecer de un ordenador equipado con Mac OS X, no se ha podido probar el

funcionamiento del SDK y su integración con el entorno de desarrollo en este sistema

operativo. En cambio, se ha podido configurar satisfactoriamente el mismo tanto en

Windows como en Linux. La instalación en ambos sistemas operativos no difiere

significativamente en ningún paso por lo que no se hará una distinción entre los

mismos, aunque se expondrán la ventajas e inconvenientes de cada uno y la

recomendación sobre cuál utilizar.

3.2.1 Windows

Se ha empleado como sistema operativo Windows 7 Ultimate en su versión de 64

bits, ya que el ordenador empleado tiene 4 GB de memoria RAM y las versiones de 32

bits sólo pueden direccionar hasta 3.3 GB de memoria física.

6 Android Development Tools (Herramientas de desarrollo de Android)

7 Software Development Kit (Kit desarrollo software)


Aunque usar una versión tan reciente de Windows para un entorno de desarrollo

puede resultar contraproducente al poder aparecer fallos porque el sistema operativo

aún no esté maduro, se ha preferido esta opción por ser el sistema operativo que

presumiblemente más se empleará para desarrollar en un futuro bajo Windows, sobre

todo después de la poca aceptación que ha tenido Windows Vista en las empresas de

desarrollo y el interés de Microsoft por la migración a Windows 7 desde Windows

Vista y Windows XP. Microsoft está realizando un gran esfuerzo por la poca

aceptación que ha tenido Windows Vista entre los desarrolladores, que permanecen

anclados a Windows XP por no considerar que Windows Vista aporte un valor

añadido que justifique la migración.

La principal ventaja de emplear este sistema operativo, es que es el más extendido

en entornos de usuario y porque muchas de las aplicaciones comerciales no son

compatibles con Linux (siempre que no se hable de proyectos como Wine, que ya

permiten instalar y ejecutar aplicaciones nativas de Windows, tales como Office en

cualquiera de sus versiones mediante la emulación del API Win32).

Algunos de los inconvenientes de utilizar este sistema operativo se describen a

continuación. El pago de licencias de uso (319€ de la versión Windows 7 Ultimate que

se reducen a 299 € en caso de actualización desde versiones anteriores). La

imposibilidad de ver el código fuente del sistema, por lo las correcciones tendrán que

venir siempre desde Microsoft además de no poder colaborar en su solución, por lo

que puede tardar más de lo debido.

A pesar de que puede haber más inconvenientes, el desarrollo de aplicaciones

Android en Windows es posible, aunque en el apartado de consideraciones de

rendimiento, se verá si es lo más conveniente.

3.2.2 Linux

Linux se está imponiendo en los últimos años como una alternativa plausible a

Windows en el entorno de usuario. Cada vez más aplicaciones comerciales son

compatibles con este sistema operativo, y siempre se pueden encontrar alternativas de

calidad a dichas aplicaciones, con lo que el pago de licencias deja de ser un

impedimento para el empleo de tecnologías de información. Aunque en la actualidad


podemos encontrar muchas distribuciones de Linux, una de las más extendidas y que

más ha mimado la facilidad de uso es Ubuntu. Como en el caso de Windows, se ha

empleado la última versión disponible, la 9.10 (distribuida en Octubre de 2009).

La instalación del entorno de desarrollo en este sistema operativo es muy sencilla,

además de que hay múltiples manuales en la red y muchos foros de soporte en el caso

de que aparezcan problemas.

Utilizar Windows para desarrollar es posible, aunque en el apartado de Linux vs

Windows, se verá si es lo más conveniente.

3.2.3 Linux vs Windows

Tras haber instalado y configurado el entorno de desarrollo en ambos sistemas

operativos y haber desarrollado en ambos, se extraen varias conclusiones que inclinan

la balanza hacia el empleo de Linux.

A la hora de configurar el entorno en Linux, se han debido realizar dos pasos

adicionales para instalar el SDK de Android y solucionar un bug de Eclipse, por lo que

aquí Windows es el ganador aunque estos pasos no son complicados y no llevan

mucho tiempo, aparte de que estuvieron documentados en diversas páginas web tan

pronto como los desarrolladores detectaron el problema. Este bug sólo está presente en

la última versión de Ubuntu, la 9.10.

En el apartado de funcionalidad, no se ve ninguna diferencia entre un sistema

operativo y otro, en ambos se dispone de las mismas herramientas y posibilidades de

desarrollo

A la hora de obtener soporte, se pueden encontrar foros para ambos sistemas

operativos, aunque en el apartado de desarrollo en Android, es independiente el

sistema operativo ya que el empleo del lenguaje es el mismo al ser la plataforma final

(el sistema operativo Android) común para ambos sistemas operativos.

La principal desventaja de emplear Windows viene a la hora de comparar el

rendimiento en ambos sistemas. La ejecución inicial de Eclipse en Linux es de 10

segundos aproximadamente, aumentando este tiempo a 30 segundos


aproximadamente en Windows. Tras cargar el entorno de desarrollo, se realiza

automáticamente la carga del SDK de Android. En Linux esta carga apenas toma 5

segundos, en Windows tarda hasta un minuto. Haciendo diferentes pruebas, se pueden

atribuir estas diferencias al empleo de antivirus en Windows, aunque con el antivirus

desactivado, los tiempos de carga siguen siendo mayores. Aún así, aún en la ejecución

del emulador de Android para probar y detectar fallos en aplicaciones que están

siendo desarrolladas, el rendimiento es mejor en Linux, cuya carga y respuesta son

mejores que en Windows.

Como conclusión, se recomienda realizar los desarrollos bajo Linux, ya que aunque

la configuración inicial puede tomar un poco más de esfuerzo (aunque en ningún caso

más de 5 minutos adicionales y ninguna complicación técnica), el rendimiento

posterior la compensará con creces, facilitando un entorno de desarrollo más veloz,

eficiente y con mejor sensación de respuesta para el usuario.

3.3 Instalación de Java

La instalación de Java en Ubuntu es muy sencilla, puesto que basta con instalar el

paquete sun-java6-jdk desde el gestor de paquetes, aunque también se puede usar apt

en una consola de comandos.

A pesar de que en algunos sitios recomiendan la utilización de la versión 5 de Java

ya que la 6 puede tener incompatibilidades con la utilización del indicador @Override,

he podido constatar que se puede trabajar con ambas versiones de manera

transparente. SUN ya no ofrece soporte para la versión 5 y se recomienda que se

emplee la versión 6.

Aún así, a continuación se describe el procedimiento para instalar Java 5 en Ubuntu

9.10 por si fuera necesario para el desarrollo. Como en los repositorios de Ubuntu 9.10

ya no está el paquete correspondiente a Java 5, se deberán emplear los repositorios de

la versión anterior de Ubuntu, la 9.04, para ello debemos editar el fichero sources.list

situado en /etc/apt/ ejecutando:

$ sudo gedit /etc/apt/sources.list

Se deberán añadir las siguientes líneas:


deb http://us.archive.ubuntu.com/ubuntu/ jaunty multiverse

deb http://us.archive.ubuntu.com/ubuntu/ jaunty-updates multiverse

A continuación se deberá guardar y cerrar el archivo. El siguiente paso es actualizar

la información de los repositorios e instalar el paquete necesario, lo cual se realiza con

los siguientes comandos:

$ sudo apt-get update

$ sudo apt-get install sun-java5-jdk

Por ultimo, se deberá ejecutar el comando:

$ sudo update-alternatives --config java

Este comando sirve para indicar al sistema que debe emplear Java 5 por defecto, por

lo que al ejecutarlo se debe seleccionar la opción java-1.5.0-sun

3.4 Instalación del entorno de desarrollo: Eclipse

La instalación del entorno de desarrollo Eclipse se limita a bajar el fichero zip

correspondiente al sistema operativo, descomprimirlo y ejecutarlo. En Ubuntu también

se puede emplear el gestor de paquetes, que se encargará de descargar e instalar el

entorno de desarrollo. Tras la primera ejecución, se pide al desarrollador que escoja su

carpeta de trabajo, que será el directorio donde se almacenen los diferentes proyectos

que se desarrollen en Eclipse. Con dicha carpeta se deberá tener especial cuidado,

realizando backups periódicos ya que su pérdida supondría la pérdida del trabajo

realizado. Esta carpeta también nos permitirá mover proyectos entre diferentes

entornos de trabajo siempre que se emplee como entorno de desarrollo Eclipse.

En Ubuntu 9.10, hay un bug que produce que no se detecten correctamente las

pulsaciones en los botones de la aplicación, por lo que habrá que emplear un script

sencillo para lanzar la aplicación y así no sufrir el molesto bug (en versiones anteriores

de Ubuntu no se produce este bug). El script es el siguiente:

#!/bin/sh


export GDK_NATIVE_WINDOWS=1

/RUTA_DONDE_ESTA_INSTALADO_ECLIPSE/eclipse

3.5 Instalación del Android SDK

Para instalar el SDK de Android, se debe obtener de la dirección

http://developer.android.com/sdk/ la versión correspondiente a Linux en este caso.

Se deberá bajar el .zip y descomprimir. Tras esto, se debe entrar en la carpeta del sdk y

acceder al directorio tools, ejecutando el archivo android (también se puede hacer por

ventana de comandos).

Figura 5. Gestor del SDK de Android

Tras la ejecución, se abrirá el gestor del SDK de Android, que permite:

Descargar diferentes versiones del SDK (1.1, 1.5, 1.6, 2.0, 2.0.1, 2.1 …)

Actualizar las herramientas a la última versión disponible.

Bajar las Google APIs, que permiten el uso de interfaces para utilizar

funcionalidad de aplicaciones de Google como Maps, Gmail, etc.

http://developer.android.com/sdk/


Asegurarse de que se dispone de la última versión de la documentación.

Obtener el driver USB para conectar el dispositivo y permitir opciones

avanzadas de depuración.

3.6 Instalación del plugin en el entorno de desarrollo: Eclipse

Se debe integrar el SDK de Android en Eclipse, para permitir que se añadan las

siguientes funcionalidades:

Creación proyectos Android.

Acceso a la documentación de las funciones mientras se programa.

Utilización del autocompletado.

Compilación.

Empleo del emulador.

Debug en tiempo de ejecución.

Creación de apks, dichos ficheros son los que sirven para instalar la

aplicación desarrollada en diferentes dispositivos que empleen Android

como sistema operativo.

Para instalar el plugin, se deberá ejecutar Eclipse, a continuación pulsar en el menú

Help y en la opción Install new software. Seguidamente se debe pulsar en Add, asignar

un nombre (cualquiera es válido) y añadir la dirección de descarga del plugin:

https://dl-ssl.google.com/android/eclipse/ tras lo cual se debe pulsar en OK. Si todo

ha ido correctamente, deberá aparecer una ventana parecida a esta:

https://dl-ssl.google.com/android/eclipse/


Figura 6. Instalación del plugin de Android en Eclipse

Se deben seleccionar ambos paquetes, y pulsar en next. Eclipse se encargará de

revisar las dependencias e instalar paquetes adicionales en caso necesario (lo más

probable es que sí). Para comenzar la descarga habrá que pulsar en finish. La descarga

puede tardar un rato pero cuando finalice habrá que reiniciar Eclipse para que integre

los nuevos paquetes descargados.

Tras reiniciar Eclipse, se debe indicar al plugin la ruta de instalación de la carpeta

que contiene el SDK de Android. Para ello se debe seleccionar en el menú Window la

opción Preferences y se deberá abrir una ventana como esta:


Figura 7. Configuración del plugin de Android en Eclipse

En SDK location habrá que pegar la ruta del SDK o pulsar el botón browse para

localizar la carpeta. Se debe pulsar en Apply. Si la ruta es correcta, el plugin detectará

las versiones del SDK y de las Google APIs que hayamos descargado. Se debe pulsar

entonces en OK.

Habrá aparecido en el menú Window una nueva opción llamada Android SDK and

AVD Manager que permitirá gestionar los emuladores, la actualización del SDK, etc. Es

similar al gestor del SDK mencionado anteriormente.

3.7 Emulador de Android

3.7.1 Creación dispositivo virtual

Para probar las aplicaciones a medida que se desarrollan y poder emplear el

debugger en Eclipse, se debe crear un dispositivo virtual. Para ello se debe acceder, en

Eclipse, al llamada Android SDK and AVD Manager y seleccionar la opción Virtual


Devices. A continuación se debe pulsar en el botón New. Se deberá abrir una ventana

como la mostrada a continuación.

Figura 8. Opciones de creación de un dispositivo virtual

En esta ventana se deberá asignar un nombre al dispositivo virtual, teniendo

cuidado porque hay caracteres que no se pueden emplear (tampoco se permite usar

espacios), aún así se mostrará una advertencia en caso de que se asignen caracteres

prohibidos.

En target se debe seleccionar la versión de Android que se quiere utilizar. Las

opciones a elegir dependerán de los SDKs que se hayan descargado.


En SD Card, se puede crear una memoria externa virtual del tamaño que se

especifique. Este archivo, si queremos ver o modificar su contenido sin emplear el

emulador , puede ser montado en Linux como una imagen iso.

Para el resto de opciones es recomendable no cambiar nada. Tras ajustar las

opciones, se debe pulsar en Create AVD. Al cabo de unos segundos, debe aparecer el

siguiente mensaje informando de que el proceso de creación del dispositivo virtual ha

finalizado correctamente.

Figura 9. Confirmación en la creación del dispositivo virtual

Una vez pulsado el botón de Ok, volveremos al gestor de dispositivos virtuales, que

mostrará el nuevo dispositivo creado.

Figura 10. Administrador de dispositivos virtuales


3.7.2 Ejecución del dispositivo virtual

Para ejecutar el emulador, se deberá acceder al administrador de dispositivos

virtuales, seleccionar el dispositivo a emular y pulsar en Start. Se preparará el

emulador y se abrirá una nueva ventana como la que se enseña.

Figura 11. Dispositivo virtual cargando Android

El emulador mostrará los botones, el teclado y la pantalla del dispositivo virtual y

procederá con la carga del sistema operativo. La carga puede tardar entre unos

segundos y varios minutos, dependiendo de la máquina donde se ejecute el emulador,

aunque hay que decir que el uso de CPU se disparará al 100% durante la carga. La

memoria usada por el emulador no suele superar los 150 MB de RAM.


Figura 12. Dispositivo virtual bloqueado

Tras cargar el sistema operativo, debería aparecer en la pantalla del emulador el

mensaje de Pantalla bloqueada, por lo que se deberá pulsar el botón de menú para

desbloquearla y poder acceder al escritorio y a las diferentes aplicaciones del

emulador.

Figura 13. Escritorio del dispositivo virtual


Para poder poner la pantalla en modo panorámico, se deberá pulsar la combinación

CTRL + F11 en el teclado del ordenador.

Figura 14. Dispositivo virtual en modo panorámico

3.7.3 Observaciones sobre el emulador

El emulador de Android es muy completo, tiene algunas características avanzadas

que en combinación con Eclipse permite emular llamadas de teléfono, posiciones

GPS… Pero en el caso de este proyecto, no ha sido de mucha utilidad ya que no

permite emular Wifi.

Otros problemas que se encuentran en el emulador son su eficiencia y la memoria

disponible. Se ha podido observar que las aplicaciones se ejecutan mucho más despacio

en el emulador, además de dar problemas de Stack Overflow en la pila de Java a la

hora de realizar tratamiento de ficheros, al usar mucha memoria o al generar muchos

objetos temporales. El Garbage Collector en este caso acaba consumiendo mucho

tiempo de ejecución, ralentizando el proceso. Si se prueba la misma aplicación en un


dispositivo real, estos problemas no aparecen, por lo que parece que es el emulador el

que introduce estas limitaciones. Estas limitaciones pueden tener sentido en el caso de

que el objetivo sea que si una aplicación funciona correctamente en el emulador,

debería funcionar sin problemas en cualquier dispositivo. La realidad es que el

emulador se queda bastante corto con dicha limitación de la memoria además de que la

emulación es muy lenta (aunque se ha ejecutado en máquinas de todo tipo, incluso en

las más potentes la emulación no acaba de ser fluida).

3.8 Consideraciones para el desarrollo en Ubuntu 64 bits

Si la versión de Ubuntu a emplear es de 64 bits, los pasos a seguir son los mismos,

excepto que será necesario instalar previamente el paquete ia32-libs. Esto es así ya que

tanto Eclipse, como Java, como el SDK están compilados en 32 bits y se debe añadir la

compatibilidad para aplicaciones de 32 bits instalando estas librerías.

Figura 15. Instalación ia32-libs

4 Desarrollo de la aplicación

4 Desarrollo de la aplicación 53

4 Desarrollo de la aplicación

4.1 Introducción

Antes de comenzar el desarrollo de la aplicación, ha habido un proceso de

documentación acerca del posicionamiento Wifi y del desarrollo en Android.

Durante el proceso de desarrollo se ha consultado frecuentemente la API de Java y

de Android para obtener información acerca de las clases y sus funciones. También se

ha barajado la posibilidad de utilizar el NDK de Android para embeber código C en las

funciones más críticas o más pesadas y para acceder al driver Wifi de forma directa.

Se ha prestado atención durante el desarrollo a los hardcodes. Se ha minimizado el

uso de éstos y en caso de que se hayan utiliziado, están localizados en las clases

contenidas en el paquete gmv.android.configuracion ya que en un futuro se

implementarán ventanas de configuración para la aplicación.

Finalmente el desarrollo se ha realizado íntegramente en Java ya que existen clases

que permiten obtener información del driver Wifi de manera sencilla y que

proporcionan los datos necesarios sin necesidad de realizar accesos complejos.

Además se ha constatado que la potencia del sistema Android y de su máquina virtual

(Dalvik) son suficientes para que todas las funciones de procesado de la aplicación se

ejecuten en tiempo real.

4.2 Fase de diseño

Se ha decidido dividir la aplicación en tres módulos según la funcionalidad deseada

en cada uno de ellos. Se muestra el DFD al más alto nivel de la aplicación, que muestra

las entradas y salidas de cada módulo.


Generación archivos

Generación BD

Wipode

Interfaz Wifi Tarjeta SD

Solicitar escaneo

Resultados

Solicitar escaneo

Resultados

Archivo muestreo posición

Archivos muestreo posición

Solicitar lista archivos

Base datos

Base datos

Figura 16. DFD Aplicación

4.3 Fases de desarrollo

Para desarrollar la aplicación se ha optado por subdividir el trabajo en 6 fases. En

cada una de ellas hay un proceso de diseño previo para buscar la mejor

implementación.

Generación BD(Java)

Generación archivos (Android)

Wipode(Android)

Portar Generación BD(Android)

Integración módulos(Android)

Pruebas usuario(Android)

BatchGeneración BD

Pruebas unitarias

Pruebas unitarias

Pruebas unitarias

Pruebas unitarias

Pruebas integradas

Módulo Generación

archivos

MóduloWipode

Módulo Generación BD

Aplicación Wipode

Aplicación Wipode

versión final

Figura 17. Fases de desarrollo, pruebas y entregables


4.3.1 Generación base datos

Como toma de contacto, se desarrolla en Java, sin emplear la API de Android, el

módulo que se encarga de generar la base de datos a partir de los archivos que

contienen los muestreos.

En éste módulo, lo más importante es diseñar una base de datos compacta y con

accesos rápidos. Se deciden usar HashTables para almacenar los datos de una manera

eficiente. Para almacenar la base de datos en el disco se emplea la serialización, que

permite guardar un estado persistente y poder recuperla posteriormente desde otro

módulo.

Se realizan diferentes pruebas para mejorar el control de errores e incrementar el

rendimiento del módulo sobre todo en la gestión de archivos y en el uso de memoria.

Este módulo servirá durante todo el desarrollo para realizar pruebas batch en

offline.

4.3.2 Generación archivos

En esta fase se comienza el desarrollo en Android, para ello se configura Eclipse y se

crea un nuevo proyecto.

En esta fase, el principal desafío consiste en acceder al driver Wifi para realizar

escaneos periódicos y recuperar los resultados de los escaneos para almacenar las

mediciones. Además, es necesario que la interfaz gráfica responda a las órdenes del

usuario y que de una sensación de ejecución en todo momento, evitando congelaciones

de la interfaz y tiempos de respuesta elevados.

Para solucionar estos problemas, se han usado Handlers, Semáforos y Threads,

además de variables compartidas.

Los archivos generados por el módulo, se procesan posteriormente por el módulo

de Generación de archivos para obtener retroalimentación y comenzar con las pruebas

de integración.


4.3.3 Wipode

Esta fase contiene la lógica de localización y la generación del mapa en la interfaz

visual. Se debe acceder al driver Wifi e implementar el método heurístico elegido para

estimar la posición.

Es necesario controlar si existe la base de datos para cargarla en memoria. Una vez

cargada, se comenzará con la localización, teniendo en cuenta que se debe informar de

la posición calculada tanto gráfica como textualmente.

Es necesario emplear threads y handlers para evitar que la interfaz gráfica quede

bloqueada.

4.3.4 Portar Generación base datos

En este hito del desarrollo, la aplicación ya es funcional. Se pueden crear los

archivos con el muestreo en cada posición para posteriormente tratarlos en el proceso

de generación de base de datos. El problema es que aún no está automatizado el

trabajo, ya que los archivos se generan en el dispositivo que ejecuta Android para

luego transferirlos a un ordenador que contiene el módulo que crea la base de datos.

Posteriormente la base de datos debe ser transferida al dispositivo. Esto crea una

cadena que puede ser automatizada, para evitar errores de tipo humano (confundir

localización de carpetas, copiar archivos erróneos o incompletos, pérdida de datos…)

El proceso de portar el programa de Java a Android no es trivial, ya que

originalmente estaba desarrollado en Java para funcionar desde línea de comandos y

ahora debe informar gráficamente de su proceso. Se decide integrar directamente en el

menú principal por no considerar necesario el emplear una ventana nueva.

Otro problema del proceso de portabilidad es que la potencia del dispositivo

Android es más reducida que la de una estación de trabajo, por lo que se vuelve a

optimizar el código, prestando especial atención al uso de memoria, limitando la

creación de objetos temporales para evitar saturar la pila de la máquina virtual y

reducir las recolecciones de basura.


4.3.5 Integración módulos

La aplicación debe ser autónoma, por lo que se deben integrar los módulos para que

puedan ser ejecutados desde el dispositivo directamente. Se debe prestar especial

atención en las rutas y archivos de salida de un módulo que son la entrada de otro.

Tras la integración, se realizan las pruebas integradas correspondientes y se genera

el paquete que contiene la aplicación para realizar las pruebas de usuario.

4.3.6 Pruebas usuario

Las pruebas de usuario se realizan en un entorno real, probando que la aplicación

funciona correctamente y responde a los requisitos solicitados.

Se realizan diversos cambios para limitar las acciones disponibles para el usuario y

así evitar comportamientos anómalos de la aplicación.

4.4 Descripción de las clases

Se han distribuido las clases en paquetes según la funcionalidad predominante de

cada una. Seguidamente se describirán los diferentes paquetes, las clases contenidas en

cada uno y su funcionalidad y los métodos más importantes.

Todas las clases que almacenan datos, tienen sobreescrito el método toString() para

permitir visualizar más fácilmente su contenido.

Las clases que necesitan que sus objetos sean ordenados por algún parámetro,

tienen sobreescrito el método compareTo (Object o) para realizar un ordenamiento por

otro criterio distinto al estándar.

Cabe destacar que para algunas clases que son índices de una tabla hash, se ha

sobreescrito el método hashCode() para evitar colisiones o para localizar índices que

aunque sean objetos diferentes, los valores de los atributos son comunes.


Se han empleados semáforos y handlers para evitar espera activa, que produce la

sensación de que la interfaz se ha bloqueado o puede llegar a bloquear la ejecución del

programa.

Los objetos o archivos almacenados en disco, son siempre comprimidos en zip. Son

muy susceptibles a ser comprimidos al contener texto plano los archivos y valores

comunes los objetos.

4.4.1 Paquete gmv.android

Este paquete agrupa la clase principal, que se encarga de invocar a los diferentes

módulos de la aplicación.

4.4.1.1 Clase Main.java

Esta clase se encarga de generar la interfaz gráfica del menú principal y de llamar a

los diferentes módulos de la aplicación. Contiene la visualización del proceso de

Generar BD y la lógica de proceso y acceso a archivos.

4.4.2 Paquete gmv.android.archivo

Este paquete agrupa las clases necesarias para el módulo de Generación de archivos.

4.4.2.1 Clase GenArch.java

El propósito de esta clase es crear la interfaz gráfica del módulo de Generación de

archivos y el control de la entrada del usuario.


4.4.2.2 Clase GenerarArchivoPosicion.java

Se encarga de realizar el proceso de obtener los datos del controlador Wifi, tratarlos

y almacenarlos en el archivo de muestreo. Además, actualiza los contadores de la

interfaz. Los objetos que instancia son threads, para evitar bloqueos de la interfaz y

realizar sus funciones en otro proceso aparte del principal.

4.4.3 Paquete gmv.android.bd

Contiene las clases relacionadas con la creación, gestión y almacenamiento de la

base de datos. Las clases BaseDatos, VectorPotencia, Potencia y Lectura son

serializables para poder conservar su estado de forma persistente y poder utilizar la

base de datos en futuras ejecuciones del programa.

4.4.3.1 Clase BaseDatos.java

Contiene la lógica de base de datos necesaria para insertar elementos, hacer cálculos

sobre ellos, verificar la existencia, etc. Contiene una tabla hash cuyos son las posiciones

y como elementos el vector de potencia asociado a cada posición.





Contiene un método para vaciar las lecturas de la base de datos, que permite reducir

el tamaño de la misma en memoria y en disco. Aunque se vacíen las lecturas, la media

y la varianza de las lecturas permanece.


4.4.3.3 Clase GenerarBD.java

Su misión es instanciar un thread que preparará el procesado de archivos para

generar la base de datos y que evitará bloqueos del interfaz. Actúa como conector entre

la interfaz gráfica y el proceso de archivos.

4.4.3.4 Clase GestorBaseDatos.java

Sus tareas son las relacionadas con la creación, alimentación, guardado y

recuperación de la base de datos. Asimismo, realiza la gestión de archivos que deben

leerse para generar la base de datos.

4.4.3.5 Clase Lectura.java

Almacena la potencia y el timestamp de un elemento del muestreo.

4.4.3.6 Clase Potencia.java

Recopila todas las lecturas asociadas a una dirección MAC en un ArrayList.

Igualmente, calcula la media y la varianza de las lecturas recopiladas.

4.4.3.7 Clase VectorPotencia.java

Esta clase sirve para instanciar un objeto por cada posición. Contiene una tabla hash

para almacenar las direcciones MAC y sus potencias asociadas. Se encarga de añadir

nuevas lecturas cuando se procesan los archivos de muestreo.






4.4.4 Paquete gmv.android.configuracion

Almacena las clases encargadas de la configuración de parámetros en el programa.

Aunque en estas clases se usan hardcodes, es un paso intermedio antes de que se

añadan nuevas opciones en la interfaz, que permitan cambiar estos valores de forma

dinámica.

4.4.4.1 Clase Mac.java

Almacena las direcciones MAC que pertenecen a puntos de acceso o estaciones

permitidas que se emplearán tanto a la hora de procesar los archivos para generar la

base de datos como posteriormente en la localización.

4.4.4.2 Clase Puntos.java

Su función es delimitar los archivos de muestreo a emplear. Sólo se utilizarán los

archivos cuya posición de muestreo se referencie aquí.

4.4.5 Paquete gmv.android.debug

Reúne las clases encargadas de controlar el flujo del programa para pruebas y

localización de errores.


4.4.5.1 Clase Log.java

Permite introducir trazas. Almacena de una manera sencilla mensajes de error en un

fichero de log desde cualquier punto del programa con una simple llamada. También

permite almacenar los muestreos realizados durante la localización para poder

comprobar posteriormente si el algoritmo de localización tiene fallos o puede ser

mejorado.

Se emplean métodos estáticos y sincronizados. Estáticos por no haber necesidad de

instanciar la clase y sincronizados para asegurarse de que se realiza el volcado a disco

antes de que continúe la ejecución del programa.

4.4.6 Paquete gmv.android.localizacion

Recoge las clases necesarias para el proceso de localización.

4.4.6.1 Clase Controlador.java

Se encarga de interactuar con el interfaz Wifi y recibir los resultados del muestreo,

procesando los datos, enviándolos a las clase encargada de calcular la posición.

Avisa a la interfaz cuando varía la posición para que se actualice el mapa y los

valores.

Hereda de Thread, ya que realiza un proceso pesado y en otro caso aumentaría el

tiempo de respuesta del programa o podría causar bloqueos.

4.4.6.2 Clase Distancia.java

Almacena la distancia de un vector de potencia asociado a una posición al vector de

potencia medido.


4.4.6.3 Clase KNN.java

Implementa la lógica asociada al método de los K-nearest neighbours. Permite que

se utilice de manera online u offline en un proceso batch. En el método online recibe

del controlador las medidas y calcula la posición y en el modo batch procesa un

archivo con mediciones y calcula las distintas posiciones en cada instante.

Realiza un acceso intensivo a la base de datos y por tanto a memoria, por lo que se

ha optimizado al máximo para que en el modo online pueda calcular posiciones con el

retardo mínimo y siempre antes de que se dispongan de nuevas muestras para calcular

una nueva posición.

4.4.6.4 Clase Medida.java

Cada objeto de esta clase almacena un muestreo asociado a una estación móvil o

punto de acceso y el momento en que se midió.

4.4.6.5 Clase Posicion.java

Almacena las coordenadas correspondientes a una posición.

4.4.6.6 Clase Procesador.java

Se encarga de procesar las medidas recibidas por el controlador para generar la lista

que se utilizará para calcular la posición.

4.4.6.7 Clase Refinador.java

Introduce una ventana de tiempo para evitar picos y suavizar la medición. Evita

transiciones brusas entre posiciones y saltos por medidas erróneas en un instante.

Devuelve la media de las mediciones realizadas durante un número de muestreos

determinado.


4.4.6.8 Clase Wipode.java

Contiene la lógica para verificar que la base de datos existe.Prepara la interfaz

gráfica y se encarga de instanciar el objeto que dibujará el mapa, introduciendo las

coordenadas de los puntos del mapa en un array.

Se encarga además de actualizar los valores de la interfaz a medida que varíe la

posición y de avisar al mapa para que actualice la posición.

4.4.7 Paquete gmv.android.localizacion

Recoge las clases necesarias para el proceso de localización.

4.4.7.1 Clase Mapa.java

Verifica las coordenadas de los puntos del mapa para verificar que son correctas.

Traza el mapa ajustándolo al tamaño de la pantalla. Dibuja un punto que simboliza la

posición del usuario en la habitación.

4.4.7.2 Clase SistemaCoordenadas.java

Realiza las transformaciones pertinentes entre sistemas de coordenadas.

4.4.8 Paquete gmv.android.notificaciones

Reúne las clases encargadas de notificar al usuario del progreso o de algún error de

la aplicación.


4.4.8.1 Clase AccionProgreso.java

Genera dos tipos de popups para informar al usuario de que una acción se está

realizando y está en progreso.

El primer tipo de popup se utiliza para procesos que no se puede cuantificar su

duración.

El segundo tipo permite indicar con una barra el porcentaje completado del proceso.

Ambos permiten ajustar el mensaje al usuario y modificarlo en tiempo real.

4.4.8.2 Clase Alerta.java

Muestra un cuadro de diálogo con un título y un mensaje de Alerta al usuario.

Bloquea la interfaz gráfica hasta que el usuario pulse en aceptar.

4.4.8.3 Clase RevisarTexto.java

Revisa que las coordenadas introducidas por el usuario son válidas. En caso de que

el usuario introduzca algún valor erróneo, se deshace la acción e informa al usuario.

4.4.9 Paquete gmv.android.proceso

Almacena las clases encargadas de procesar los archivos que contienen los

muestreos.

4.4.9.1 Clase Archivo.java

Se encarga de abrir, procesar y devolver un ArrayList con los muestreos. Este

ArrayList será empleado por el gestor de base de datos para alimentarla.


El proceso de archivos es un proceso lento, que utiliza la cpu y la memoria de

manera intensiva. Ha sido difícil de implementar en Android ya que provocaba tanto

que el recolector de basura se iniciara muy a menudo, penalizando el rendimiento

como el desbordamiento de la pila de Java, abortando el programa.

La solución fue prescindir de muchos objetos temporales, utilizando código menos

entendible pero más eficiente.

4.4.10 Paquete gmv.android.wifi

Incorpora las clases responsabilizadas de controlar el interfaz Wifi.

4.4.10.1 Clase Estado.java

Se encarga de almacenar parámetros sobre el interfaz Wifi, como el retardo,

situación…

4.4.10.2 Clase ModificarEstadoWifi.java

Se encarga de activar o desactivar Wifi en el dispositivo cuando la aplicación lo

requiera para ahorrar batería.

4.5 Diagramas de clases

A continuación se muestran los diagramas de clases correspondientes a cada

módulo de la aplicación. Se muestran las relaciones y dependencias más importantes.


4.5.1 Menú principal

Figura 18. Diagrama de clases del menú principal

4.5.2 Generación Archivos

Figura 19. Diagrama de clases de Generación archivos


4.5.3 Generación BD

Figura 20. Diagrama de clases de Generación BD


4.5.4 Wipode

Figura 21. Diagrama de clases de Wipode

4.6 Fase de pruebas

A pesar de que no se han podido realizar un banco de pruebas completo para

mejorar y afinar el proceso de localización se han realizado unas pruebas tanto batch


como online. Adicionalmente, se han realizado pruebas de rendimiento para

comprobar los requisitos técnicos de la aplicación.

4.6.1 Pruebas batch

Se han utilizado para verificar la implementación del algoritmo KNN. En un futuro

se podrían emplear para comparar el comportamiento de diferentes algoritmos y las

posiciones informadas con las mismas muestras.

Para estas pruebas, se realizaron varios desplazamientos a lo largo de unas

posiciones para calcular el mejor número de candidatos que se deben emplear para el

algoritmo KNN. El valor óptimo es el 4.

Durante estas pruebas, una vez ajustado a 4 el parámetro del algoritmo KNN, el

error medio fue siempre inferior a 4.

4.6.2 Pruebas online

Se han realizado de forma cualitativa, usando el programa mientras se recorría una

habitación. Se ha constatado que detecta la posición de manera coherente, con errores

dentro de un rango de 3 metros alrededor del sujeto.

Durante esta fase se han realizado pruebas para comprobar la tolerancia del

algoritmo desactivando o añadiendo nuevos puntos de acceso. El algoritmo fue capaz

de seguir determinando la posición, aunque con la ausencia de ciertos puntos de

acceso, el error aumenta. Si se añaden nuevos puntos de acceso, no se perjudica al

algoritmo.

4.6.3 Pruebas rendimiento

Con objeto de comprobar que el programa puede ser ejecutado en cualquier

dispositivo que emplee Android, se han realizado unas pruebas de uso de cpu y de


memoria de cada módulo mediante la herramienta DDMS8 incluida en el SDK de

Android.

La aplicación se identifica por la etiqueta gmv.android

4.6.3.1 Menú principal

El uso de procesador en este modo es nulo, ya que sólo necesita dibujar la interfaz

una vez y luego queda a la espera de que el usuario elija una acción.

El uso de memoria también es mínimo.

Figura 22. Uso CPU Menú principal

Figura 23. Uso Memoria Menú principal

8 Dalvik Debug Monitor Server (Depurador de la máquina virtual)


4.6.3.2 Generación archivos

En éste módulo el consumo de procesador apenas representa el 25% del total de la

capacidad de la CPU, aunque se incluyan todos los subprocesos (sistema y wifi)

requeridos para que el módulo funcione.

El uso de memoria, aunque se incrementa respecto del menú principal, es bastante

reducido.

Figura 24. Uso CPU Generación Archivos

Figura 25. Uso Memoria Generación Archivos


4.6.3.3 Generación BD

Este módulo es el más intensivo en términos de utilización del procesador y de la

memoria. Este proceso es el que se ha adaptado de un modo batch que se ejecutaba en

un ordenador de sobremesa (con mayor capacidad tanto de procesamiento como de

memoria) a la plataforma Android.

Si bien el uso de CPU ronda el 55 – 60% (no llega al 100 % ya que hay muchas

operaciones de E/S y aunque se empleen Buffers, Android no brilla precisamente por

su eficiencia en la gestión de archivos), el uso de memoria no supera el 15%. Esto es

porque se procesa cada archivo secuencialmente y se libera memoria de la base de

datos antes de procesar el siguiente archivo.

Figura 26. Uso CPU Generación BD

Figura 27. Uso Memoria Generación BD


4.6.3.4 Wipode

Este modo debería ser el más utilizado una vez que esté calibrada la base de datos.

Se puede observar que el consumo de CPU (10- 15%) y el de memoria (5%) son muy

reducidos por lo que le consumo de batería no será muy alto, dotando a la aplicación

de gran autonomía.

Figura 28. Uso CPU Wipode

Figura 29. Uso Memoria Wipode

4.7 Planificación

El proyecto se inició el 21 de septiembre de 2009 y se considerará como concluido el

14 de febrero al finalizar las correcciones de la memoria que se consideren pertinentes.


4.7.1 Planificación de tareas

Durante el proyecto se han identificado 5 tareas principales:

Fase diseño

Fase desarrollo

Optimización y mejoras

Documentación

Realización de la memoria

Seguidamente, se muestra la tabla con la duración y precedencias de cada una de las

tareas. Adicionalmente, la tarea “fase de desarrollo” se ha descompuesto en subtareas

para detallar aún más la planificación seguida.

Tabla 2. Planificación proyecto

Se puede observar que la tarea por la que se comienza es por la documentación. Esta

tarea se realizará durante toda la vida del proyecto ya que es imprescindible tanto para

el diseño, como para el desarrollo, la optimización y mejoras y la realización de la

memoria.


La fase de diseño es previa a la de desarrollo ya que aquí se especifican las subtareas

necesarias para completar el proceso de desarrollo y las pruebas para confirmar la

consecución de los hitos.

La optimización y mejoras, surgen a partir del proceso de documentación y afectan

tanto al diseño como al desarrollo de la aplicación.

La memoria como tal, se comienza según se indica en la tabla, aunque hay que tener

en cuenta que previamente a su inicio, se ha recopilado información y se ha comenzado

tanto el diseño como el desarrollo.

Esta tabla también puede ser representada con un diagrama Gantt, que se incluye a

continuación para clarificar aún más la planificación seguida.

Figura 30. Diagrama Gantt de la planificación del proyecto


5 Presupuesto

5 Presupuesto 79

5 Presupuesto

5.1 Introducción

En este capítulo se expondrá el presupuesto necesario para cubrir los diferentes

costes del proyecto. Destacar que el coste de este proyecto es muy reducido al no

haberse requerido ningún elemento tecnológico caro ni adquirir ninguna licencia para

el uso de algún programa especializado. El coste principal es el concerniente al salario

del programador, que al estar en régimen de becario y no tener experiencia sobre

Android, no es excesivo.

5.2 Presupuesto

Este proyecto incurre en unos costes para poder ser realizado. Aunque hay muchos

costes asociados, se van a tener en cuenta sólo los costes directos, desechando los

indirectos por ser difíciles de cuantificar (luz, agua, llamadas telefónicas, seguridad,

administración…)

Concepto Cantidad Duración/tipo cambio Total

Personal 3.000 €

Salario programador becario dedicación exclusiva 4 h / día 588 €/mes 5 meses 2.940 €

Retención IRPF 12€ /mes 5 meses 60 €

Equipamiento 384 €

Teléfono Desarrollo Google ION 399 $ 0,7 € / $ 279 €

Gastos de manipulación y envío teléfono 150 $ 0,7 € / $ 105 €

Routers para pruebas 0 € / router 4 uds 0 €

Terminal desarrollo 0 € 1 ud 0 €

Sistema operativo Ubuntu 0 € 1 ud 0 €

Plataforma desarrollo Eclipse 0 € 1 ud 0 €

SDK Android 0 € 1 ud 0 €

Total presupuesto 3.384 €

Tabla 3. Presupuesto del proyecto

5 Presupuesto 80

6 Conclusiones y trabajos futuros

6 Conclusiones y trabajos futuros 82

6 Conclusiones y trabajos futuros

6.1 Conclusiones

La aplicación ha servido para demostrar que el posicionamiento en interiores

mediante Wifi es posible, permitiendo mejorar en un futuro su precisión y exactitud

mediante el empleo de algoritmos más complejos y otras técnicas como el

preprocesado o postprocesado.

El empleo de Android como plataforma ha resultado exitoso, la combinación de una

API accesible y bien documentada junto con el despliegue del sistema en numerosos

teléfonos móviles permiten preveer que en un futuro cercano tanto el número de

aplicaciones como la necesidad de desarrolladores en este ámbito aumente, por lo que

la experiencia adquirida durante el desarrollo de este proyecto será muy valorada.

Este proyecto ha permitido descubrir otra característica funcional de los teléfonos

móviles: su utilización como dispositivos de guiado en interiores mediante el empleo

de las redes Wifi colindantes. Este hecho abre las puertas a multitud de nuevas

posibilidades de aplicaciones para el usuario y la industria.

6.2 Trabajos futuros

Esta aplicación tiene muchos puntos de mejora para añadir nuevas funcionalidades.

Se describen algunas características que serían deseables para futuras versiones con

objeto de mejorar la experiencia para el usuario final y Extender el ámbito de

aplicación del programa.

6.2.1 Algoritmo de localización

Se podrían implementar nuevos algoritmos, además de agregar pre y postprocesado

para mejorar la precisión y reducir el error.


6.2.2 Sensores

La utilización de la brújula para realizar las mediciones y el calibrado podría ser

muy útil a la hora de emplear el algoritmo de localización, ya que así se podría conocer

la orientación del usuario y reducir los errores provocados por la atenuación de la

señal producida por el cuerpo humano.

El acelerómetro podría servir para calcular un vector de dirección y velocidad y

predecir la siguiente posición.

6.2.3 Localización exteriores

Se podría combinar el posicionamiento indoor con el posicionamiento mediante

GPS. Esto permitiría aumentar el número de situaciones en que la aplicación puede ser

utilizada. La API de Android permite acceder a las posiciones facilitadas por el GPS de

una manera sencilla, así que se podría utilizar el posicionamiento indoor cuando el

GPS no esté disponible. Por ejemplo, en túneles, subterráneos o edificios.

6.2.4 Configuración

Sería deseable que la aplicación permitiera mayor libertad al usuario a la hora de

cambiar opciones. Se podría personalizar la ruta de los archivos, modificar parámetros

de manera dinámica o a medida que la aplicación se desarrolle, acceder a funciones

avanzadas.

6.2.5 Empleo servidor

Una arquitectura cliente-servidor sería la evolución lógica de la aplicación.

El servidor sería el encargado de almacenar la BD y los mapas de las distintas

habitaciones. Esto libera a la aplicación que se ejecuta en el dispositivo del usuario final

de las tareas de consulta a la BD y almacenado de los mapas, delegando estas tareas en

peticiones al servidor, por lo que se reducen los requisitos de almacenamiento en el

dispositivo.


La lógica de la aplicación, podría ser también ejecutada en el servidor, por lo que el

dispositivo simplemente tendría que visualizar el resultado en un mapa, por lo que se

reduce el consumo de CPU y memoria del programa, aumentando la autonomía.

El principal inconveniente de esta solución, es que en caso de fallo o sobrecarga del

servidor o de la red, los dispositivos no serán capaces de funcionar correctamente. Para

evitar este problema, habrá que realizar un estudio para dimensionar correctamente el

servidor e introducir servidores redundantes o incluso distribuir las peticiones entre

servidores, además de realizar un correcto diseño de la red.

6.2.6 Multimapa

Actualmente el mapa es estático, ya que la aplicación por ahora sólo sirve para

posicionarse en una única habitación. En un futuro, la aplicación podría cargar

múltiples mapas, realizando una transición entre ellos cuando se cambie de habitación.

6.2.7 Uso del contexto

La aplicación podría realizar distintas acciones según dónde se encuentre el usuario.

Por ejemplo, cuando se aleje del puesto de trabajo podría bloquear automáticamente la

pantalla de la estación de trabajo, o cambiar el estado de un cliente de mensajería a

ausente o modificar el perfil de sonidos del dispositivo… La posibilidades son infinitas,

incluyendo integración con redes sociales, twitter, etc.

6.2.8 Guiado

Sería muy interesante contar con un navegador, que guíe de la posición actual a un

destino especificado por el usuario. Este destino podría ser una posición concreta, o

una localización asociada a una posición (por ejemplo objetos como fotocopiadoras, o

despachos, o aulas…).


6.2.9 Facilidades para ciegos

Android, en su API, pone a disposición de los programadores una librería para

sintetizar voz. Esto, convinado junto con el guiado, podría permitir a una persona que

con dificultades o carencia de visión más facilidad a la hora de desenvolverse en sitios

interiores.

6.2.10 Localización dispositivo

Podría existir una opción, que permita ejecutar de manera remota el programa en el

dispositivo, para que nos envíe su localización en caso de extravío.

7 Bibliografía

7 Bibliografía 87

7 Bibliografía

Tesis Design of indoor positioning systems based on location fingerprinting

technique. (Kamol Kaemarungsi)

Estado del arte en sistemas de localización en interiores basados en RF (Fundación

Deusto)

A Practical Evaluation of Radio Signal Strength for Ranging-based Localization.

Whitepaper. (Kamin Whitehouse, Chris Karlof David Culler)

Indoor Location (Z. Weissman)

UltraWideBand Indoor Positioning (S. Ingram)

RADAR: An In-building RF-based User Location and Tracking System (P. Bahl,

V.N. Padmanabhan)

On the feasibility of power control in current IEEE 802.11 devices (Fehmi Ben

Abdesslem, Luigi Iannone, Marcelo Dias de Amorim, Konstantin Kabassanov, Serge

Fdida)

Area Localization using WLAN (V.N. Padmanabhan)

7 Bibliografía 88

Advanced Integration ofWiFi and Inertial Navigation Systems for Indoor Mobile

Positioning (Frédéric Evennou and François Marx)

Enhancements to the RADAR User Location and Tracking System (P. Bahl, V.N.

Padmanabhan)

Etude de l’hybridation d’un récepteur GPS avec des capteurs bas coûts pour la

navigation personnelle en milieu urbain (Damien Kubrak)

Wireless Location Technologies (Nobuo Kawaguchi)

http://developer.android.com/index.html

http://developer.android.com/index.html

8 ANEXOS

8 ANEXOS 90

8 ANEXOS

A Manual de explotación

A Manual de explotación

A.1 Introducción

Wipode es la aplicación de localización en interiores desarrollada para Android.

Está diseñada de forma que la instalación y manejo sean sencillos. Además, no exige

conocimientos específicos de informática; desde la propia aplicación se pueden realizar

todos los pasos necesarios para calibrar el mapa y poder navegar por la estancia. No es

necesario ningún equipo externo para que la aplicación funcione, con el dispositivo

Android que ejecute la aplicación es suficiente.

En los siguientes puntos se detallarán las diferentes opciones de la aplicación y la

forma de uso de cada una de ellas. La explicación se complementará con capturas de la

aplicación para ayudar a la comprensión.

A.2 Instalación

Para instalar la aplicación, sólo es necesario el paquete apk llamado Wipode. Este

deberá copiarse al dispositivo Android. Después, se deberá abrir el explorador de

archivos y localizar el paquete Wipode.apk

Figura 31. Icono del instalador de Wipode

A continuación se deberá pulsar sobre el archivo para ejecutarlo e iniciar la

instalación. Antes de instalar el paquete, Android mostrará información sobre el

mismo. Se deberá pulsar en install.

Figura 32. Ventana de detalles del paquete

Se mostrarán los diferentes permisos que se le van a asignar a la aplicación. Se debe

pulsar en Instalar para comenzar la instalación.

Figura 33. Confirmación de la instalación

El proceso de instalación dura unos segundos.

Figura 34. Proceso de instalación

Tras instalar la aplicación, se podrá elegir entre ejecutarla y comenzar a utilizarla o

volver al explorador de archivos.

Figura 35. Notificación de instalación completada

A.3 Ejecución

Para la ejecución, se deberá abrir el menú de aplicaciones de Android y localizar el

icono de WIpode con el texto: “Menú principal”

Figura 36. Icono ejecución de Wipode

A.4 Menú principal

Tras ejecutar la aplicación, aparecerá el menú principal. Los tres primeros botones

permiten acceder a las diferentes funciones del programa. EL botón Salir finaliza la

aplicación.

Figura 37. Menú principal

A.5 Generación archivos

Este módulo de la aplicación realiza las mediciones de las potencias de señal en los

diferentes puntos de la habitación que se especifiquen. Este es el paso previo que es

obligatorio realizar para calibrar el mapa. Tras pulsar el botón correspondiente a

Generación de Archivos se mostrará la ventana que permite configurar la medición.

Se recomienda realizar mediciones con una distancia máxima de 3 metros (tanto

horizontal como verticalmente), distribuidas como una cuadrícula.

Figura 38. Ventana principal de Generación de archivos

Se deberán introducir las coordenadas X e Y en los cuadros de texto habilitados al

efecto.

Figura 39. Introducción de coordenadas

Tras especificar las coordenadas, es necesario ajustar un retardo entre mediciones.

Estos es necesario para permitir que el proceso de escaneo de señales Wifi se realice

correctamente ya que sino el controlador Wifi se satura de peticiones y no devuelve

resultados correctos. El mínimo recomendado son 500 milisegundos.

Figura 40. Especificación del retardo

Tras haber establecidos las coordenadas y el retardo deseados, se puede pulsar en el

botón Comenzar para iniciar el muestreo y la Generación del archivo con la

información de la potencia de las señales detectadas en la posición establecida en las

coordenadas. En el momento de comenzar el muestreo, se debe estar situado en la

posición correspondiente a las coordenadas que se han facilitado a la aplicación.

Si el archivo correspondiente a dicha posición ya existía, se sobreescribirá sin

solicitar confirmación.

Figura 41. Activación Wifi en la Generación de Archivos

Si el Wifi estaba desconectado, se activará para permitir realizar el muestreo.

Cuando esté activado completamente, se cerrará la notificación y se comenzará el

muestreo.

Figura 42. Comienzo del muestreo

Una vez que comienza el muestreo, la aplicación no empezará a registrar las

mediciones como válidas y a registrarlas hasta después de un intervalo inicial. Este

intervalo se introduce con objeto de estabilizar las mediciones, ya que las primeras

pueden informar valores inexactos.

Una vez que se empiezan a registrar y a almacenar las muestras, los contadores

empezarán a incrementarse.

Figura 43. Proceso de muestreo

El contador de mediciones realizadas lleva la cuenta de los muestreos. El contador

de registros almacenados representa el número de medidas unitarias realizadas,

entendiendo por medida unitaria el valor de la medida correspondiente a un punto de

acceso o estación wifi detectados. También se informa del tiempo transcurrido desde

que se comenzó el proceso de muestreo.

Se recomienda finalizar el muestreo pulsando en el botón parar cuando haya unas

100 mediciones realizadas.

Figura 44. Finalización del muestreo

Al pulsar el botón parar, se desactivará el Wifi para ahorrar batería mientras no se

use. Se volverá a la ventana de Generación de archivos, donde se mostrará el resultado

del muestreo y se podrán especificar nuevas coordenadas para realizar un nuevo

muestreo.

Figura 45. Resumen del muestreo

A.6 Generación base datos

Tras generar los archivos correspondientes a los muestreos realizados en cada

posición, deberán ser procesados para generar la base de datos empleada por Wipode

para estimar la posición. Para ello, en el Menú principal se deberá pulsar el botón

correspondiente a Generación base datos. El proceso puede tardar entre unos segundos

y unos minutos, dependiendo del número de archivos y de mediciones realizadas.

Figura 46. Comienzo del procesado de archivos

A medida que se vayan procesando archivos, el indicador de progreso irá

incrementando e informando del proceso.

Figura 47. Procesando archivos

Una vez que el proceso termine y la base de datos sea generada, se informará al

usuario.

Figura 48. Fin de proceso

A.7 Wipode

Una vez procesados los archivos de posición y generada la base de datos, se puede

comenzar a utilizar Wipode para localizar la posición del usuario. Para ello, se debe

pulsar el botón correspondiente a Wipode en el Menú Principal.

Figura 49. Wipode

Una vez ejecutado Wipode, se mostrará el mapa correspondiente a la habitación en

la que vamos a emplear la aplicación. Para comenzar la localización, se debe pulsar en

Comenzar, tras lo cual se activará el módulo Wifi si no estuviera activado.

Figura 50. Activación de Wifi

Tras activar Wifi, se mostrará el mapa con el mensaje Posición desconocida.


Una vez que se empiecen a determinar posiciones válidas, se mostrarán las

coordenadas con un mensaje y un punto que representa la posición del usuario dentro

de la estancia.

Figura 52. Posición determinada por Wipode

Para dejar de utilizar Wipode, se debe pulsar en el botón Parar, tras lo cual se

detendrá la localización y se desactivará Wifi para ahorrar batería.

Figura 53. Desactivación Wifi

A.8 Control de errores

Se ha realizado un control de errores tanto a nivel de aplicación (gestión de

archivos, memoria, métodos, etc) como control de las entradas del usuario.

Seguidamente se muestran algunos de los mensajes de error que puede generar la

aplicación y su causa.

Cabe destacar que siempre se desactivan los botones y los elementos que no deben

ser usados por el usuario en determinados momentos para evitar comportamientos

inesperados de la aplicación.

A.8.1 Generación arc hivos

Si no se informa valor en ambas coordenadas y se pulsa en comenzar, se mostrará

un mensaje de error.

Figura 54. Mensaje de error por no informar las coordenadas

Si se trata de introducir valores que no sean numéricos en las coordenadas, también

se mostrará un mensaje de error.

Figura 55. Mensaje de error por introducir caracteres no váldos en las coordenadas

A.8.2 Generación base datos

Si se intenta generar la base de datos sin que exista ningún archivo de posición se

informará al usuario.


A.8.3 Wipode

Si se intenta comenzar lo localización sin generar la base de datos, el programa

mostrará un error.

Figura 57. Error en Wipode al no existir la base de datos

B Layouts

B Layouts 111

B Layouts

B.1 Main.xml

<?xml version="1.0" encoding="utf-8"?>

<AbsoluteLayout android:id="@+id/abslay"

android:layout_width="fill_parent" android:layout_height="fill_parent"

android:background="#ff449801"

xmlns:android="http://schemas.android.com/apk/res/android">

<Button android:id="@+id/boton_GenArch"

android:layout_width="wrap_content"

android:layout_height="wrap_content" android:text="Generacion

archivos"

android:layout_x="80px" android:layout_y="105px">

</Button>

<Button android:id="@+id/boton_GenBD"


android:layout_height="wrap_content" android:text="Generacion base

datos"


</Button>

<Button android:id="@+id/boton_Wipode"


android:layout_height="wrap_content" android:text="Wipode"


B Layouts 112

</Button>

<Button android:id="@+id/boton_Salir" android:layout_width="wrap_content"

android:layout_height="wrap_content" android:text="Salir"


</Button>

<TextView android:id="@+id/selarch" android:layout_width="wrap_content"

android:layout_height="wrap_content" android:text="Seleccione para

crear archivos de posición"


</TextView>

<TextView android:id="@+id/selbd" android:layout_width="wrap_content"


generar la base de datos"


</TextView>

<TextView android:id="@+id/selwipode"



comenzar la localización"


</TextView>

<TextView android:id="@+id/selsalir" android:layout_width="wrap_content"

B Layouts 113


salir"


</TextView>

<TextView android:id="@+id/titulo" android:layout_width="wrap_content"

android:layout_height="wrap_content" android:text="Wipode"

android:textSize="50px" android:layout_x="70px"

android:layout_y="0px">

</TextView>

</AbsoluteLayout>

B Layouts 114

B.2 GenArch.xml


<AbsoluteLayout android:id="@+id/widget29"




<TextView android:id="@+id/widget31"


android:layout_height="wrap_content" android:text="Coordenadas

(X,Y): "

android:layout_x="30dip" android:layout_y="40dip">

</TextView>

<EditText android:id="@+id/coordenada_X"


android:layout_height="wrap_content" android:textSize="15sp"

android:layout_y="30dip" android:lines="1" android:maxLines="1"

android:selectAllOnFocus="true" android:minEms="3"

android:layout_x="175dip"

android:isScrollContainer="false" android:maxEms="4"

android:cursorVisible="true" android:ems="4"

android:longClickable="false">

</EditText>

<EditText android:id="@+id/coordenada_Y"


B Layouts 115

android:layout_height="wrap_content" android:textSize="15sp"

android:layout_y="30dip" android:lines="1" android:maxLines="1"

android:selectAllOnFocus="true" android:minEms="3"

android:layout_x="255dip"

android:isScrollContainer="false" android:maxEms="4"

android:cursorVisible="true" android:ems="4"

android:longClickable="false">

</EditText>

<Button android:id="@+id/boton_Comenzar"


android:layout_height="wrap_content" android:text="Comenzar"


</Button>

<Button android:layout_width="wrap_content"

android:layout_height="wrap_content" android:text="Parar"

android:layout_x="130dip" android:layout_y="385dip"

android:id="@+id/boton_Parar">

</Button>




android:id="@+id/boton_Salir">

</Button>

B Layouts 116



android:layout_height="wrap_content" android:text="Mediciones

realizadas:"


</TextView>



android:layout_height="wrap_content" android:text="Registros

almacenados:"


</TextView>



android:layout_height="wrap_content" android:text="Tiempo

transcurrido (seg):"


</TextView>

<TextView android:id="@+id/num_mediciones"


android:layout_height="wrap_content"

android:text="0" android:layout_x="240dip" android:layout_y="185dip"

android:clickable="false">

</TextView>

B Layouts 117

<TextView android:id="@+id/num_registros"



android:text="0" android:layout_x="240dip" android:layout_y="235dip"


</TextView>

<TextView android:id="@+id/num_segundos"


android:layout_height="wrap_content" android:text="0"



</TextView>

<ProgressBar android:layout_x="136dip" android:id="@+id/barraprogreso"

android:layout_y="320dip" android:layout_height="wrap_content"

android:layout_width="wrap_content">

</ProgressBar>

<SeekBar android:layout_x="30dip" android:layout_y="130dip"

android:id="@+id/frecuencia_actualizacion"

android:isScrollContainer="false"

android:longClickable="false" android:progress="0"

android:max="5000"


android:layout_width="220dip">

</SeekBar>

B Layouts 118

<TextView android:layout_height="wrap_content"

android:layout_width="wrap_content" android:layout_x="30dip"

android:layout_y="90dip" android:text="Retardo muestreos (msg):"

android:id="@+id/widget62"></TextView>

<TextView android:layout_height="wrap_content"

android:layout_width="wrap_content" android:layout_x="240dip"

android:text="0" android:id="@+id/text_retardo"

android:layout_y="90dip"></TextView>

</AbsoluteLayout>

B Layouts 119

B.3 Wipode.xml


<AbsoluteLayout android:id="@+id/widget0"




<gmv.android.map.Mapa android:id="@+id/superficieMapa"

android:layout_width="320px" android:layout_height="310px"


</gmv.android.map.Mapa>

<Button android:id="@+id/boton_Comenzar"


android:layout_height="wrap_content" android:text="Comenzar"


</Button>


android:layout_height="wrap_content" android:text="Parar"


android:id="@+id/boton_Parar">

</Button>



B Layouts 120


android:id="@+id/boton_Salir">

</Button>

</AbsoluteLayout>

C Manifest, String y propiedades

C Manifest, String y propiedades 122

C Manifest, String y propiedades

C.1 Manifest


<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="gmv.android" android:versionCode="1"

android:versionName="1.0">

<application android:icon="@drawable/icon"

android:label="@string/app_name">

<activity android:name=".Main" android:label="@string/app_main"

android:icon="@drawable/icon"

android:screenOrientation="portrait">

<intent-filter>

<action android:name="android.intent.action.MAIN" />

<category

android:name="android.intent.category.LAUNCHER" />

</intent-filter>

</activity>

<activity android:name=".archivo.GenArch"

android:label="@string/app_genbd"



<intent-filter>

<category

android:name="android.intent.category.DEFAULT" />


</intent-filter>

</activity>

<activity android:name=".localizacion.Wipode"

android:label="@string/app_wipode"



<intent-filter>

<category

android:name="android.intent.category.DEFAULT" />

</intent-filter>

</activity>

</application>

<uses-sdk android:minSdkVersion="4" />

<uses-permission

android:name="android.permission.ACCESS_COARSE_LOCATION" />

<uses-permission

android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

<uses-permission

android:name="android.permission.ACCESS_CHECKIN_PROPERTIES"></uses-

permission>

<uses-permission android:name="android.permission.WAKE_LOCK"></uses-

permission>

<uses-permission android:name="android.permission.INTERNET"></uses-

permission>


<uses-permission

android:name="android.permission.ACCESS_NETWORK_STATE"></uses-

permission>

<uses-permission

android:name="android.permission.CHANGE_NETWORK_STATE"></uses-

permission>

<uses-permission

android:name="android.permission.CHANGE_WIFI_MULTICAST_STATE"></uses-

permission>

<uses-permission

android:name="android.permission.ACCESS_WIFI_STATE"></uses-permission>

<uses-permission

android:name="android.permission.CHANGE_WIFI_STATE"></uses-permission>

<uses-permission

android:name="android.permission.READ_PHONE_STATE"></uses-permission>

<uses-permission

android:name="android.permission.MODIFY_PHONE_STATE"></uses-permission>

<uses-permission

android:name="android.permission.WRITE_SETTINGS"></uses-permission>

</manifest>


C.2 Strings.xml


<resources>

<string name="app_name">Wipode</string>

<string name="app_main">Menu principal</string>

<string name="app_genbd">Generacion Archivos</string>

<string name="app_wipode">Wipode</string>

</resources>


C.3 default.properties

F# This file is automatically generated by Android Tools.

# Do not modify this file -- YOUR CHANGES WILL BE ERASED!

#

# This file must be checked in Version Control Systems.

#

# To customize properties used by the Ant build system use,

# "build.properties", and override values to adapt the script to your

# project structure.

# Indicates whether an apk should be generated for each density.

split.density=false

# Project target.

target=android-4

apk-configurations=

Desarrollo de una aplicación de posicionamiento mediante Wifi ...

Documents