Trabajo Final de Grado - Arctic

ARCTIC: aplicación móvil para la
toma de datos y obtención de
resultados en el esquí alpino.
Convocatoria: 19 de Julio de 2016
Alumno: Enrique Acedo Dorado
Tutores: Dr. Boni García Gutiérrez
Dr. José María Font Fernández
Grado: Ingeniería en Desarrollo de Contenidos Digitales

Agradecimientos
Agradezco a todas las personas que me han ayudado en la consecución de este proyecto,
especialmente a José María Font por la dedicación y el apoyo en la realización de este
documento, a Boni García por la ayuda en todo el desarrollo de la aplicación, a Irene
Luna por la creación y el diseño de ARCTIC y a Carlota Maestro por su ayuda como tester
del producto.

Tabla de contenido
1. Resumen ................................................................................................................... 6
2. Abstract ..................................................................................................................... 7
3. Introducción .............................................................................................................. 8
4. Apps y Desarrollo en Android .................................................................................... 9
4.1. Historia y Actualidad de Android ................................................................... 10
4.2. Versiones ....................................................................................................... 12
4.3. Arquitectura ................................................................................................... 13
4.4. Apps ............................................................................................................... 15
4.4.1. Apps de Salud y Bienestar .................................................................. 16
5. Arduino .................................................................................................................... 18
5.1. Introducción ................................................................................................... 18
5.2. Sketch ............................................................................................................ 19
5.3. Aplicaciones de Arduino ................................................................................ 21
5.4. IMUduino ....................................................................................................... 22
6. Bluetooth ................................................................................................................ 24
7. Planteamiento del problema .................................................................................. 25
8. Solución propuesta ................................................................................................. 28
8.1. Desarrollo del sensor ..................................................................................... 30
8.2. Desarrollo de la aplicación ............................................................................. 34
8.2.1. Entorno y configuración ..................................................................... 34
8.2.2. Requisitos de la aplicación ................................................................. 36
8.2.3. Diagrama de componentes ................................................................ 37
8.2.4. Almacenamiento de datos ................................................................. 38
8.2.4.1. SQLite ................................................................................... 38
8.2.5. Arquitectura ....................................................................................... 40
8.2.6. Comunicación BLE ............................................................................ 43
8.2.7. Interfaz de Usuario ............................................................................. 44
8.2.7.1. Formulario de alta de usuario ............................................ 44
8.2.7.2. Navigation Drawer ............................................................. 46
8.2.7.3. Inicio .................................................................................. 48

8.2.7.4. Emparejamiento de dispositivos ........................................ 50
8.2.7.5. Nueva Actividad ................................................................. 51
8.2.7.6. Formulario de Nueva Actividad ......................................... 52
8.2.7.7. Detalle de Actividad ........................................................... 54
8.2.7.8. Perfil ................................................................................... 56
8.2.7.9. Ajustes ............................................................................... 56
8.2.7.10. Idioma ................................................................................ 57
8.2.7.11. Estructura UI ...................................................................... 58
8.2.8. Análisis de los datos ........................................................................... 59
8.2.8.1. Número de giros ................................................................ 59
8.2.8.2. Puntuación ......................................................................... 60
8.2.9. Publicación en Google Play ................................................................ 62
9. ¿Por qué ARCTIC? .................................................................................................... 64
10. Resultados ............................................................................................................... 65
11. Conclusiones y líneas futuras .................................................................................. 76
11.1. Conclusiones .................................................................................................. 76
11.2. Líneas futuras ................................................................................................. 76
12. Referencias .............................................................................................................. 78

Capítulo 1. Resumen

6
1. Resumen
En este Trabajo Final de Grado se presenta ARCTIC, una app para la toma de datos y
obtención de resultados en el deporte de esquí alpino. Lo hace mediante un sensor
acoplado al esquí que lee los datos y la aplicación móvil que tras procesar los datos
facilita al usuario la visualización de los resultados.
ARCTIC se ha desarrollado usando la tecnología Arduino en cuanto a la implementación
del sensor y la tecnología Android para la implementación de la aplicación. Para la
comunicación entre ellos se ha utilizado la última tecnología Bluetooth, Bluetooth Low
Energy, que permite una conexión eficiente y óptima entre los dos dispositivos.
Para su desarrollo se han seguido los principios de diseño S.O.L.I.D. y de Clean
Architecture que han permitido obtener un código de calidad. Además para el diseño de
la aplicación se ha utilizado Material Design, la guía de estilo de Google para aplicaciones
nativas de Android.
El resultado es una aplicación Android combinado con un sensor Arduino, que permite
al esquiador evaluar su nivel en una bajada de una manera rápida y sencilla.

Capítulo 2. Abstract

7
2. Abstract
This End-of-Degree Project submits ARCTIC, an app that collects data and obtain results
in alpine skiing. It is formed by a sensor attachable to ski and a mobile application that
processes data and shows the results to the user.
ARCTIC has been developed using Arduino technology in terms of the development of
the sensor and Android technology in terms of the development of the app. Bluetooth
Low Energy, the last Bluetooth version, has been used for the communication between
the sensor and the app because it is the best way to communicate them efficiently and
optimally.
For its development it has been used the S.O.L.I.D. and Clean Architecture principles that
have provided a quality code. Besides that, for the app’s design it has been used Material
Design, the Google style guide for Android apps.
The result is an Android app combined with an Arduino sensor, that provides skiers an
evaluation of its downhill run quickly and simply.

Capítulo 3. Introducción

8
3. Introducción
En este Trabajo de Fin de Grado se combina dos de las pasiones del autor. El esquí alpino
y la tecnología. Se entiende que con lo avanzado que está el mundo de la tecnología y
los avances que se pueden ver día a día en ese mundo, en el esquí alpino no se ha visto
ninguna mejora tecnológica aplicada en los últimos años.
Como antiguo corredor de esquí alpino y actual entrenador en un equipo de
competición así como estudiante del Grado en Ingeniería de Desarrollo de Contenidos
Digitales tengo la sensación de que el esquí alpino es un campo que no está explotado
tecnológicamente hablando y que puede ofrecer muchas ventajas para esquiadores
amateurs y para entrenadores y corredores. A unos por el simple hecho de poder medir
lo que hacen y compartirlo, que hoy en día está muy de moda, a otros por el poder
obtener con detalle unos datos no apreciables con la vista y así trabajar de una manera
más eficiente y óptima para la consecución de unos resultados deportivos exitosos.
Es por eso que se va a tratar de dar una solución a través de un producto mínimo viable
aplicando tecnologías de última generación. Para ello se han definido unos requisitos
pensados para que el proyecto sea abarcable. Con esto se pretende abrir el camino de
las tecnologías en el mundo del esquí alpino y en general en el de deportes menos
populares.
Para ello se explicará la actualidad de las tecnologías utilizadas del apartado 3 al 5 con
el fin de entender porque se han utilizado esas tecnologías y qué aportan al proyecto.
En los apartados 6 y 7 se explicará el problema que se ha planteado y que se abordará
en el apartado 9, dónde se explicará la solución que se ha dado y se podrá entender en
detalle el producto mínimo viable obtenido.
Por último, en el apartado 9, se describirán las pruebas realizadas que evaluarán si se
cumplen las expectativas del trabajo.

Capítulo 4. Apps y Desarrollo en Android

9
4. Apps y Desarrollo en Android
En los últimos años los dispositivos móviles han sufrido un gran avance, llegando a
convertirse en ordenadores y llegando a millones de usuarios.
De ahí nace Android, un sistema operativo y plataforma software basado en Linux para
dispositivos móviles (teléfonos, tablets, smartwatches, etc.). Pertenece a la compañía
de Google y es open-source (de código abierto) por lo que cualquiera puede crear sus
propias aplicaciones, widgets e incluso modificar el sistema operativo.

A día de hoy es el sistema operativo para dispositivos móviles de mayor éxito llegando
a estar en casi el 75% de dispositivos móviles del mercado. Apple, con iOS, es la segunda
que más éxito tiene con el 17%. [1]
Las aplicaciones Android se programan mediante el lenguaje de programación Java.
Google nos ofrece el SDK (Software Development Kit) de Android necesario para
desarrollar las aplicaciones y ejecutar el emulador y también nos ofrece el entorno de
desarrollo Android Studio basado en IntelliJ IDEA de JetBrains. También se pueden
utilizar otros IDEs como Eclipse haciendo uso de extensiones. [2]
A continuación se verá más a fondo algunos aspectos de Android que son necesarios
para tener una mejor visión del sistema operativo.

Figura 3: Android y las distintas aplicaciones de Google disponibles en Android [44]


10
4.1. Historia y Actualidad de Android
En este capítulo se presenta el sistema operativo Android, cuya historia se remonta al
momento en el que Andy Rubin, Rich Miner, Nick Sears y Chris White a finales de 2003
fundaron Android Inc., una empresa que se dedicaba al desarrollo de software para
teléfonos móviles. [3]
Mientras tanto, el gigante Google estaba empezando a invertir en startups (“una startup
es una empresa que trabaja para resolver un problema cuya solución no es obvia y cuyo
éxito no está garantizado”-Neil Blumenthal, cofundador y co-CEO de Warby Parker) y
fue en 2005 cuando decidió apostar por Android Inc. y comprarla por 50 millones de
dólares y empezar a desarrollar lo que sería el sistema operativo número uno del
mundo. [4]
Otro momento a destacar fue el nacimiento de Open Handset Alliance, a finales de 2007,
una alianza de 84 compañías (78 en sus inicios) que se encarga de desarrollar estándares
abiertos para dispositivos móviles [5]. Algunas de las compañías miembro son
Telefónica, Google, Samsung, Acer, Dell [6]. Hasta esta alianza, Google había llevado en
secreto todo el proyecto Android.
El momento más importante fue, en Octubre de 2008, cuando publican el proyecto
Open Source Android (bajo la licencia Apache), HTC lanza el primer móvil que funciona
con Android, bajo la versión de Android 1.0 y empieza el Android Market (a partir de
2012 conocido como Google Play). [5]
A partir de ahí, todo lo relacionado con Android va acompañado de la palabra
crecimiento. A finales de 2009 se produce un aumento significativo de la venta de
dispositivos móviles con el sistema operativo Android y se consolida el Android Market
y continúa con un crecimiento exponencial hasta llegar a los 1,4 billones de usuarios a
finales de 2015. [5]
Comparándolo con otros sistemas operativos para móviles, Android es el sistema
operativo más popular y el que mayor crecimiento ha tenido desde su lanzamiento.
Cuando empezó tenía competidores de alto prestigio como Symbian (Nokia), RIM
(Blackberry), iOS (Apple) y Microsoft. El éxito de Android viene dado por la pluralidad de
dispositivos a los que puede llegar. Symbian ha muerto con la caída inesperada de Nokia
[7]. Lo mismo le ha pasado a RIM con la caída de Blackberry aunque sin llegar a
desaparecer [8]. iOS, que tiene el mismo problema que los anteriores(sólo se puede
utilizar en dispositivos Apple), no ha muerto y se mantiene vivo gracias al éxito indudable
del iPhone y, mientras siga ese éxito, iOS siempre estará ahí. Es cierto que Apple se ha
dado cuenta de esa desventaja respecto a Android y está tendiendo a sacar modelos de
iPhone menos potentes y que puedan ser accesibles por un mercado más amplio [1].
Por ejemplo, en Septiembre de 2015 sacaron el iPhone SE por un precio de 489€ , precio


11
reducido si lo comparamos con el del iPhone 6 de 639€, y con unas especificaciones
menos potentes que las del iPhone 6. [9]

En la Figura 4 se puede ver cómo han ido evolucionando, por cuota de mercado, los
diferentes sistemas operativos para móviles. Estos exitosos números tienen repercusión
en el mercado de las Apps. En febrero de 2016, Google Play llegaba hasta los 2 millones
de aplicaciones.

Figura 5: Cuota de mercado mundial de los principales sistemas operativos móviles [22]


12
4.2. Versiones
En cuanto a las versiones de Android, hasta mayo de 2015 han sacado 11 grandes
actualizaciones del sistema operativo.
En la Figura 6 se puede ver un cronograma temporal de las versiones de Android.

Como se observa en la Figura 7, la versión que más dispositivos abarca es Android 5.0
‘Lollipop’ casi igualada con Android 4.4 ‘KitKat’. La última versión, Android
Marshmallow, no tiene el éxito de las otras porque todavía no es soportada por todos
los dispositivos y depende de cada fabricante.
Cada fabricante tiene la posibilidad de modificar Android para dar su toque personal al
sistema operativo que tengan los dispositivos móviles de su marca y así diferenciarlo del
resto de las marcas. Lo hacen mediante capas de personalización que modifican Android
tanto a nivel visual para el usuario, como a nivel de software para el rendimiento del
dispositivo. Esta capa de personalización hay veces que, si no está desarrollada de una
manera óptima, da problemas de rendimiento y no son más útiles que la versión de
Android pura. Es por eso que la tendencia de estas capas de personalización es la de ser
más limpias y claras. [10]
Figura 6: Cronograma temporal de versiones de Android [15]
Figura 7: Número de dispositivos que ejecutan determinada versión de Android [25]


13
Como curiosidad, destacar que los nombres de las versiones están todos relacionados
con dulces y van en orden alfabético empezando en la C y terminando en la M, así que
la siguiente empezará por N. [11]

4.3. Arquitectura
Android es una plataforma para dispositivos móviles que contiene una pila de software
donde se incluye un sistema operativo, librerías (C, C++), framework para el desarrollo
de aplicaciones y una suite de aplicaciones iniciales. [3]
Como se puede ver en la , en la arquitectura Android se pueden diferenciar las siguientes
capas: [3]
• Núcleo: utiliza el núcleo de Linux 2.6 para abstraerse del hardware disponible en los
dispositivos. En esta capa se encuentran los drives para el uso de los componentes de
hardware.
• Librerías: en esta capa se encuentran las librerías que dan a Android la mayor parte
de sus capacidades más características. Están escritas tanto en C como en C++ y las
principales son: libc, SurfaceManager, OpenGL/SL y SGL, Media Libraries, FreeType,
SSL, SQLite y WebKit. Junto al núcleo, forman la parte central de Android.
• Entorno de ejecución: se sitúa al mismo nivel que las librerías y está formado por las
Core Libraries, que son librerías con clases Java y la máquina virtual Dalvik, que está
específicamente diseñada para Android e interpreta y ejecuta el código escrito en
Java. Ha tenido que ser adaptada a las peculiaridades de los dispositivos móviles y
posee características como menor capacidad de proceso, baja memoria, alimentación
por batería, etc. Dalvik no trabaja directamente con el bytecode de Java, sino que lo
convierte en un código más eficiente que el original. Utiliza la herramienta dx, que
compila los ficheros Java .class en ficheros .dex, que pueden contener varias clases.
Después, los ficheros .dex se comprimen en un archivo .apk (Android Package) que es
el que se distribuye por los dispositivos móviles. Dalvik está basada en registros y no
en pila como otras, lo que implica que las instrucciones son más reducidas y se reduce
el número de accesos a memoria. También nos permite crear varias instancias
simultáneas de la máquina virtual y no permite la compilación Just-in-Time.
• Framework: a partir de este nivel está todo escrito en Java. El framework lo constituye
el conjunto de herramientas que tienen a disposición los desarrolladores de
aplicaciones Android. Toda aplicación que sea desarrollada para Android debe utilizar
el mismo conjunto de API y de framework.


14
• Aplicaciones: este es el último nivel de la arquitectura de Android. En él se incluyen
tanto las aplicaciones incluidas por defecto por Android como las que cada usuario
decide añadir, ya sean de terceras empresas o de su propio desarrollo.

Figura 5: Capas de la arquitectura de Android [12]


15
4.4. Apps
Se define App como un software que proporciona una utilidad para el usuario en un
dispositivo móvil [13]. En general las aplicaciones utilizan recursos que los dispositivos
móviles ofrecen mediante librerías para su funcionamiento. Recursos como: Bluetooth,
Wifi, red móvil, GPS, contactos y otros recursos dependientes del terminal móvil en
cuestión.
Para el uso de esos recursos del sistema, el usuario necesita dar permisos de uso a la
aplicación para cada recurso del móvil que utilice y, si los rechaza, la aplicación no puede
tener acceso a ellos. [14]
Es una de las cosas que tienen que tener en cuenta los desarrolladores a la hora de
realizar una App, ya que a mayor número de recursos utilizados, más probabilidad hay
de que el usuario rechace esos recursos. Además, cuantos más recursos específicos
utilice, menor es el número de dispositivos finales compatibles con la app (en los que se
puede utilizar). Por ejemplo, si se crea una app que utilice recursos como la huella
dactilar, se debe tener en cuenta que son pocos los modelos que tienen el sensor de
huella dactilar, por lo que los usuarios potenciales serán un número menor.
Para publicar una App en Android basta con tener una cuenta de desarrollador de
Google, que en la actualidad cuesta 25$, y cumplir con una serie de requisitos que
impone Google para que te aprueben la aplicación antes de ser subida a Google Play
[15]. Es inevitable no nombrar aquí a Apple, ya que la licencia de desarrollador de Apple
[16] cuesta 99$ anuales y si eres empresa 299$ [17],por lo que los desarrolladores
prefieren desarrollar para Android que para iOS.

Figura 8: Plataformas móviles que utilizan los desarrolladores en Diciembre de 2015 [28]


16
En la actualidad, la cifra de aplicaciones disponibles en Google Play asciende a los 2,2
millones y como se puede ver en la Figura 9, el crecimiento cada vez se produce más
rápido.

Figura 9: Número de aplicaciones disponibles en Google Play [18]
Cada app debe estar en una categoría dependiendo de las funciones que realice y para
lo que le sirva al usuario. Hay un total de 24 categorías seleccionabas en Google Play.
Las más populares son: Educación, Estilo de vida, Ocio, Economía, Personalización,
Herramientas, Libros y obras de consulta, Música y audio, Viajes y guías y Juegos. Los
juegos tienen luego distintas categorías atendiendo a sus géneros, como Arcade, Puzzle,
Multijugador, etc. [19]

4.4.1. Apps de Salud y Bienestar
Las apps de salud y bienestar están en la posición 11 del ranking total de aplicaciones de
las distintas categorías. Y si quitamos los juegos, que tienen categorías diferentes, entran
en el top 10. [20]
Las apps de salud y bienestar son las que aportan al usuario funciones para facilitar el
seguimiento de ejercicios, dietas, bienestar personal, salud y seguridad, etc. [19]
Estas apps están teniendo cada vez más protagonismo por la necesidad de la sociedad
de tener un control por todo lo que se hace y sobre todo por la preocupación por la
salud de las personas [21]. Cada vez son más los wearables (un wearable es cualquier
tecnología que llevamos puesto en forma de prenda o complemento como los
smartwatches o las Google Glass [22]) que miden constantemente la actividad del


17
usuario y gracias a eso se tienen datos que a la larga pueden ser muy interesantes para
el seguimiento médico de los usuarios.
Dentro de esta categoría, las aplicaciones que nos ayudan a llevar un seguimiento de
ejercicios son muy numerosas. Muchas de ellas utilizan sensores del móvil o de un
dispositivo externo para medir los datos con mayor precisión que se comunican con el
dispositivo móvil a través de Bluetooth o Wifi. Esos datos que se recogen nos pueden
servir para mejorar la técnica en distintos deportes como running, futbol, tenis, golf,
béisbol, etc.
Por ejemplo, la marca Garmin ha creado un accesorio que se acopla al palo de golf y
hace mediciones de los golpes que se realizan. [23]
Cada vez son más los accesorios que se venden para una toma de datos precisa,
facilitando datos y mediciones que un dispositivo móvil no puede ofrecer. Por ejemplo,
los sensores de la marca Zepp que aportan datos muy útiles para los deportes de tenis,
golf, béisbol y softbol. [24]
También hay marcas de artículos deportivos que están integrando los sensores en los
artículos que venden. Por ejemplo, Babolat, marca de raquetas de tenis, ya tiene un
modelo de raqueta que se conecta con el móvil y te permite visualizar diferentes datos
[25].

Figura 10: Raqueta Babolat con sensores integrados [25]

Capítulo 5. Arduino

18
5. Arduino
La plataforma Arduino es uno de los productos más populares de electrónica de código
abierto (open-source). Desarrollado por Massimo Banzi y David Cuartielles en 2005,
Arduino es una plataforma de prototipos electrónica de código abierto basada en
hardware y software flexibles y fáciles de usar. [26]
5.1. Introducción
Para programar el microcontrolador de la placa se utiliza Arduino Programming
Language basado en Wiring y el IDE Arduino Development Environment basado en
Processing. Los proyectos de Arduino pueden ser autónomos o pueden estar
comunicándose con otro software ejecutándose independientemente. [26]
El software se puede descargar gratuitamente para Windows, Mac OS X y Linux y hay
diseños de referencia del hardware (archivos CAD) disponibles bajo licencia open-source
para adaptarlos a tus necesidades. [27]
Arduino está compuesto por una placa principal que contiene insertado el
microprocesador y por el resto de controladores y componentes electrónicos. [26]
Arduino tiene una gran variedad de placas con distintas características en sus
componentes principales y diferentes tamaños para poder adaptarse a distintos tipos
de proyectos. [26]

Figura 11: Placa Arduino [26]


19
5.2. Sketch
Sketch es el nombre que Arduino le da a los programas que se pueden cargar y ejecutar
en sus placas. [26]
Se programan en un lenguaje de programación muy similar a C y tienen la siguiente
estructura: [28]
• Comentarios: Todo sketch suele empezar con una explicación de lo que hace y
para qué sirve el sketch. Como en la mayoría de lenguajes, pueden ocupar una
línea ( // ) o varias líneas ( /* */ ).
• Declaraciones: En esta parte se realizan las declaraciones de librerías y de las
variables que se utilizará a lo largo del programa por lo que suele estar después de
la explicación para que sea la primera parte en compilarse.
• Funciones: como todo programa se crean funciones para con el fin de utilizarlas
durante el programa y hacer un código limpio y ordenado. Hay que destacar dos
funciones principales que tienen que estar en todo sketch de Arduino que son
setup() y loop().
• setup(): es llamada una sola vez cuando el sketch empieza a ejecutarse y es donde
se realizan inicialización de librerías y variables. Es útil para asignar valores que no
van a cambiar durante la ejecución del programa. Un sketch puede ejecutarse
cuando se enciende o se resetea la placa de Arduino.
• loop(): como su nombre dice, se ejecuta una y otra vez hasta que se resetea la
placa o se apaga. Aquí es donde va todo toda la lógica del programa.
Por hacer una comparación con otros lenguajes, el setup() es un constructor o un init y
el loop() es el main del programa.
También se debe tener en cuenta la librería Serial que permite la comunicación entre la
placa Arduino y un ordenador u otros dispositivos. El IDE Arduino Development
Enviroment tiene la herramienta Serial Monitor que permite seleccionar el puerto por
el que se realizará la comunicación. Para la utilización del Serial hay que tener
conocimiento de las siguientes funciones: [29]
• Serial.begin(port): para inicializar el Serial y se debe indicar el puerto por el que se
realizarán las comunicaciones. Suele hacerse en el setup(). Para finalizarlo una vez
se termine el programa se utiliza la función Serial.end(). [30]
• Serial.write(): sirve para enviar datos a través del puerto establecido. Se puede
enviar bytes, strings o un array indicando su longitud. [31]


20
• Serial.readBytes(buffer, length): lee los datos que son enviados por el puerto y los
almacena en el buffer que se le pasa por parámetro y la longitud que también se le
pasa por parámetro. [32] Hay otras funciones para la lectura como readBytesUntil(),
readString() o readStringUntil(). [29]
Para cargar un Sketch a una placa de Arduino hay que compilar el Sketch y si no da
errores seleccionar la placa a la que queremos cargarlo en: Herramientas à Puerto. Una
vez la tengamos seleccionada basta con darle a Subir y la consola nos dará un informe
de la subida.
En la Figura 12 se puede ver un ejemplo de Sketch de Arduino así como la simple
apariencia del IDE de Arduino.

Figura 12: Ejemplo de Sketch de Arduino en el IDE Arduino Development


21
5.3. Aplicaciones de Arduino
A la gran variedad de placas que nos ofrece Arduino se le suma un gran conjunto de
componentes que acoplar a sus placas. [33] Esa gran variedad abre un abanico muy
grande de aplicaciones para Arduino.
Al fin y al cabo Arduino es un mini ordenador que realiza una función muy específica y
que es muy adaptable. Por ejemplo, se puede alojar un boot para Telegram [34], o crear
un Arduino que haga fotos y las publique automáticamente en Tumblr [35].
Otras aplicaciones de Arduino se centran en el Internet de las cosas (IoT) como por
ejemplo un collar de gato que nos dice cuando está dormido. Solo hace falta un
acelerómetro, una placa de Arduino y una batería recargable. El mini ordenador
recogerá los datos y en función de los resultados hará una cosa u otra. Cuando detecte
que esté dormido, utilizará la aplicación IFTTT, que permite realizar acciones como
publicar un tweet automáticamente o mostrar una notificación en el móvil, para avisar
al dueño de que el gato se ha dormido.
Este es sólo un ejemplo de aplicación de Arduino y nos da una visión de la amplia
variedad de productos que se pueden crear gracias a Arduino.
Otro ejemplo algo más complicado es un termostato que se puede controlar con la
aplicación de mensajería de Telegram. En este caso se necesita un sensor de
temperatura, una pantalla LCD y botón que haga de interruptor y el código para que
funcione la aplicación se complica un poco más que el anterior pero el resultado es
increíble ya que además de saber la temperatura a través de la pantalla, permite a
cualquier usuario de Telegram que use el boot, conocer la temperatura del lugar dónde
se encuentre el termostato con una simple pregunta en una aplicación de mensajería.

Figura 13: Diseño con la placa de Arduino y sus componente de Smart Thermostat


22
5.4. IMUduino
El IMUduino (Figura 14) es un microcontrolador (ATMEGA32u4) de 16x42 milímetros y
aproximadamente 2,7 gramos que tiene un transmisor Nordic nRF8001 Bluetooth Low
Energy, un giroscopio y acelerómetro de 6 ejes (MPU6050), un compás digital de 3 ejes
(HMC5883) y un barómetro/altímetro (MS561101BA03-50) [36]. Es una copia del
Arduino Leonardo. Para su funcionamiento necesita estar conectado a una batería
externa y se puede conectar al ordenador vía microUSB. [36]

IMUduino utiliza un sistema de comunicaciones serie UART, acrónimo de Universal
Asynchronous Receiver-Transmitter. Es un chip integrado en la placa que se encarga de
recibir los datos de los sensores e formato paralelo y convertirlos a un formato serie
para enviarlos mediante Bluetooth. [37]
Después de esta descripción técnica, creo que es necesario explicarlo de una forma más
clara. Para eso hay que tener dos conceptos claros: IMU y Arduino. Este último está
explicado en el apartado anterior.
IMU son las siglas de Unidad de Medición Inercial (Inertial Measurement Unit) y es un
sistema cerrado que se usa para calcular la orientación, localización y movimiento. Están
formados por una combinación de acelerómetros y de giroscopios (sensores de
velocidad angular) para saber cómo se mueve y en qué posición está.
Una IMU detecta en cada instante la orientación y los cambios de dirección (i.e. ángulos
de roll, pitch y yaw) y además los integra para saber el cambio sobre la posición inicial.
Este sistema se opone al sistema GPS que utiliza satélites para calcular la posición.
Las IMUs, como todos los componentes de medida, tienen errores de medición. En este
caso, al ir calculando constantemente los cambios detectados en la posición el error se
Figura 14: Placa IMUduino [33]


23
va acumulando. Esto se llama error acumulado o “deriva” que es la diferencia entre la
posición real y la posición hallada por la IMU.
Suelen ser componentes de sistemas de navegación como barcos, aviones y suelen ir
acompañados de otros sistemas como GPS, sistema barométrico o compás magnético
para compensar las limitaciones que tiene una IMU. [38]
El primer uso de una IMU fue en un barco alrededor de 1930 y desde entonces se ha ido
perfeccionando por diferentes instituciones llegando a crear el primer Sistema de
Navegación Inercial. La navegación Inercial ha hecho posible muchos viajes espaciales
como el programa Apolo [39] en el que el hombre pisó por primera vez la Luna en 1969
[40]. Hoy en día casi todas las cosas que calculen de forma electrónica su aceleración,
orientación y/o velocidad llevan integradas una IMU . [38]
Volviendo a la definición IMUduino, es la integración de un sistema IMU en una placa
Arduino que tiene un transmisor Bluetooth Low Energy. Esto hace posible transmitir los
datos recogidos por la IMU a un dispositivo externo para el procesado y visualización de
los mismos mediante un sistema.

Capítulo 6. Bluetooth

24
6. Bluetooth
Bluetooth® es una tecnología concebida como alternativa inalámbrica a las conexiones
por cable mediante el intercambio de datos por ondas de radio. [41] Fue creada en 1994
por la empresa Ericsson y más adelante se formó Bluetooth SIG (Special Interest Group)
cuando otras empresas como Intel, IBM, Nokia, etc. se sumaron al proyecto de Ericsson.
Su nombre está inspirado en un rey de Dinamarca Harald Blåtand, en inglés, Harold
Bluetooth. Según la historia, a finales del siglo X, el rey Harald ayudó en la conversión de
varias tribus vikingas a la religión cristiana y representa la unión [42]. De ahí viene el
nombre, ya que la tecnología Bluetooth fue creada como un estándar global de
comunicación inalámbrica que permite la conectividad (la unión) y colaboración entre
los productos y las industrias dispares. [43]

Figura 15: Logo de Bluetooth®
Bluetooth utiliza ondas de radio en vez de cables para realizar la conexión entre varios
dispositivos. Un producto Bluetooth (un móvil, un reloj, un ratón, etc.) contiene un
pequeño chip con un transmisor Bluetooth y un software que facilita su uso. Para que
haya comunicación entre dos dispositivos vía Bluetooth deben haberse emparejado
previamente. El rango de dispositivos de una conexión Bluetooth es de 2 a 8 dispositivos
y se denomina piconet a la red creada cuando se realiza una conexión de dispositivos
por medio de la tecnología Bluetooth. Cuando se crea una red piconet y se estabiliza,
automáticamente un dispositivo adquiere el rol de master y los demás dispositivos de la
red toman el rol de esclavos. Las redes piconet se estabilizan dinámicamente y
automáticamente según van entrando y saliendo dispositivos del radio de alcance. [43]
La tecnología Bluetooth permite conectar sin cables varios dispositivos. Hasta hace poco
lo normal era conectar el teléfono con el ordenador, con el coche, con unos cascos o con
otro teléfono. Pero cada vez más se está integrando Bluetooth con dispositivos como
televisiones, las luces de casa o una pelota de fútbol. El futuro del Bluetooth es
inimaginable.
En la actualidad, hay muchos tipos de Bluetooth (diferentes versiones) pero los dos tipos
de Bluetooth más comunes son Bluetooth BR/EDR (versión 2.1) y Bluetooth Low Energy
(BLE) o Bluetooth Smart (versión 4.0). Se habla de una nueva versión 5.0 que doblará la
velocidad y cuadriplicará el rango . La última versión de Bluetooth está diseñada para el
internet de las cosas (IoT [44]). La eficiencia energética de esta versión de Bluetooth lo
hace perfecto para dispositivos que se ejecutan durante largos periodos de tiempo con
pequeñas fuentes de energía como pilas de botón o fuentes de energías alternativas.

Capítulo 7. Planteamiento del problema

25
7. Planteamiento del problema
Viendo que los wearables son herramientas del futuro que nos facilitan el trabajo [45] y
sabiendo que una de las tendencias tecnológicas es el uso del Smartphone como
ordenador personal [46] se ha tratado de integrarlo y de aplicarlo a un dominio de
aplicación relevante: el deporte y, para ser más exactos, el mundo del esquí alpino. En
ese deporte últimamente se están introduciendo mejoras tecnológicas cómo cascos [47]
o gafas de esquiar inteligentes [48]. Estos dispositivos permiten la comunicación entre
varios dispositivos iguales y te dan algún dato respecto a la velocidad, la localización, la
altitud y el número de giros.

Figura 16: Vision con las gafas Oakley AIRWAVE [48]

Por otra parte existen aplicaciones móviles que miden datos algo más precisos. Hay
algunas genéricas que no se centran en el esquí como Runtastic [49] que dan datos cómo
velocidad máxima y media, elevación ganada, elevación perdida y la distancia total
recorrida.
En la Figura 17 se puede ver un ejemplo de los datos que muestra a los usuarios la
aplicación Runtastic después de grabar una bajada de esquí.


26

Hay otras aplicaciones que sí son específicas para el esquí que además de los datos de
las aplicaciones más genéricas, nos dan mayor información cómo el número de pistas
bajadas, el número de remontes cogidos, la inclinación de las pistas además de un mapa
con el recorrido realizado y unas gráficas de la altitud y la velocidad como se puede ver
en la Figura 18. [50]

Figura 18: Capturas de pantalla de la aplicación Ski Track para iPhone dónde se puede ver los datos que muestra
despues de una grabacion.

Figura 17: Ejemplo de bajada de esquí grabada con la aplicacion Runtastic


27
Esos avances son significativos pero en este trabajo se ha tratado de ir un poco más allá
con la convicción de que se pueden tomar datos más precisos y más valiosos para que
el usuario pueda visualizar cómo de bien esquía. Además tiene especial interés para el
esquí de competición obtener esos datos más técnicos para poder corregir y mejorar
ciertos detalles que son importantes en el ámbito de la competición para alcanzar
mejores resultados.
Para eso en este trabajo se propone utilizar un sensor que vaya acoplado al esquí y que
se comunique con un dispositivo móvil de una forma eficiente y rápida para que el
usuario pueda ver los resultados lo más rápido y cómodo posible. Se propone una
mezcla de los wearables existentes con la tecnología móvil actual.

Capítulo 8. Solución Propuesta

28
8. Solución propuesta
La solución al problema planteado es un sistema formado por un dispositivo que tome
datos y haga de emisor de esos datos y otro dispositivo que haga de receptor de los
datos y los procese para su visualización. En la Figura 19 se puede ver un esquema muy
simplificado de la solución.

Figura 19: Esquema del sistema de la solución propuesta.
La elección de los dispositivos que actuarán como emisor y receptor ha sido una decisión
importante y decisiva en todo el desarrollo.
En la elección del emisor se han tenido en cuenta los siguientes requisitos:
• Medición de datos como orientación, aceleración, etc. que sean útiles para
obtener datos que nos indiquen cómo de bien esquía el usuario.
• Uso de Bluetooth Low Energy (de ahora en adelante BLE) para el envío de los
datos que toma para un uso reducido de energía.
• Tamaño pequeño para un fácil acople.
• Peso reducido para que no sea molesto para el usuario el utilizar el dispositivo.
• Que sea open-source para poder acoplarlo a nuestras necesidades.
Y en la elección del receptor se han tenido en cuenta los siguientes requisitos:
• Uso de BLE para un consumo reducido de energía.
• Poder procesar y guardar los datos.
• Poder visualizar los datos.
• Que sea accesible por el mayor número de usuarios posible.


29
Con esos requisitos para el dispositivo emisor y para el dispositivo receptor se ha hecho
una búsqueda exhaustiva y se ha llegado a la conclusión de que la solución más óptima
es el uso de un sensor IMUduino basado en Arduino que tome los datos y los envíe vía
Bluetooth Low Energy (a partir de ahora, BLE) y el uso de una aplicación Android que
procese los datos y los muestre al usuario. Esta elección significa que el dispositivo
receptor no es uno sólo, sino que, como ya se explicó en el apartado 1, son un 75% de
los dispositivos móviles del mundo. Aunque en realidad serán menos porque no todos
los dispositivos móviles que utilicen Android tendrán Bluetooth, pero sí una gran
mayoría.
En la Figura 20 se muestra un esquema de los componentes utilizados para la solución
del problema.

Figura 20: Esquema de componentes de la solución

A continuación se explicará cómo se ha llevado a cabo el desarrollo de cada una de las
partes por separado ya que son totalmente independientes aunque sí que hay que tener
en cuenta qué datos que se envían y en qué formato se envían para que el receptor
pueda procesarlos correctamente. Esta independencia se piensa que es buena para
posibles cambios o incorporaciones en un futuro ya que se puede crear una aplicación
para iOS sin tocar nada de la de Android ni del sensor y/o se puede cambiar el sensor
siempre y cuando que se envíen los mismos datos en el mismo formato que se ha
elegido.


30
8.1. Desarrollo del sensor
Para el emisor se ha utilizado un IMUduino que como bien se ha explicado en el apartado
5.4 es un Arduino de pequeñas dimensiones con una serie de sensores y que utiliza BLE
para comunicarse con otros dispositivos.
Se ha trabajado principalmente en el desarrollo del software para el IMUduino aunque
también se ha tenido que trabajar en una pequeña parte del hardware.
IMUduino no viene con batería integrada así que se necesita una fuente de energía para
su uso. IMUduino puede coger la energía a través del puerto Micro-USB que lleva
integrado o por medio de unos pines destinados para conectar la batería. Como solución
se ha pensado en una batería LiPo (batería de polímero de litio), que son recargables,
conectado directamente a la entrada micro-usb. Para eso se ha utilizado los siguientes
componentes:
• Bateria LiPo 3.7V y 680mAh.
• Conector Micro-JSP hembra
• Conector Micro-USB macho
• Cargador batería LiPo

Figura 21: Componentes para suministar energia a IMUduino
Ha sido necesario soldar los cables del conector JSP hembra al conector Micro-USB
macho para poder llevar la energía de la batería LiPo al IMUduino ya que no había ningún
conector JSP macho – Micro-USB macho. Para ello ha sido necesario un soldador de 40W
especial para componentes electrónicos e hilo de estaño para soldadura electrónica. El
cargador no va incluido en el sistema, simplemente se utiliza para cargar la batería.
Se ha decidido no incorporar el cargador de la batería a lo que es el sensor que se
acoplará al esquí para reducir el tamaño. Para cargar la batería habrá que desenchufar
el cable que lo conecta al IMUduino y enchufarlo al cargador.


31
En la Figura 22 se puede ver el resultado de soldar los cables del conector JSP al conector
macho Micro-USB.

Figura 22: conexión JSP macho soldado a macho Micro-USB
En la Figura 23 se puede ver el acople de la batería al IMUduino. Como se puede observar
se ha buscado una batería lo más pequeña posible coincidiendo en el largo con el
IMUduino y siendo un poco más ancha.

Figura 23: IMUduino conectado a la bateria a través del conector Micro-USB

Y por último se puede observar en la Figura 24 cómo quedaría bien acoplado ya
preparado para realizar pruebas. Se puede ver el tamaño respecto a una moneda de 50
céntimos de euro para que se aprecie lo reducido que es el sensor.

Figura 24: IMUduino acoplado a la bateria


32
Solucionado el problema de la batería, se ha trabajado en el sketch de Arduino que se
va a cargar en IMUduino. IMUduino ofrece una librería “FreeIMU.h” que da la opción de
leer los siguientes datos:
• Aceleración
• Rotación
• Ángulos de navegación (Yaw Pitch Roll)
• Temperatura
• Altitud respecto al nivel del mar
• Presión
Sería muy interesante poder leer todos esos datos pero la placa IMUduino tiene una
memoria de 28.672 bytes, lo que limita el tamaño del sketch y la cantidad de datos que
podemos leer.
Para este trabajo se ha decidido utilizar los datos de aceleración, rotación, ángulos de
navegación, temperatura y presión, ya que serán útiles para saber cómo se mueve el
usuario y así poder analizar su forma de esquiar y para otros datos adicionales. El sketch
que se ha creado para coger esos datos ocupa un 98% de la memoria disponible. Si
incluyésemos la altitud se ocuparía el 101% del tamaño por lo que no permite subirlo a
la placa del IMUduino. Tampoco es mucho problema porque viendo las librerías que
ofrece IMUduino, la función que devuelve la altitud utiliza la temperatura y la presión
además de otras constantes, así que para calcular la altitud respecto al nivel del mar se
utilizara el dispositivo que recibe los datos y los procesa.
Como se explicó en el apartado 5.2, en todo sketch de Arduino tiene que haber dos
métodos obligatoriamente que son setup y loop. Para el sketch que se ha desarrollado
para este trabajo en el setup se inicializan los componentes IMU y también se inicializa
el componente Bluetooth Low Energy. También se cambia el nombre del dispositivo BLE
para que cuando se haga el emparejamiento aparezca el nombre que se desee. El
nombre tiene una longitud máxima de siete caracteres así que se ha decidido utilizar el
nombre de ARCTIC, el mismo que el de la aplicación de Android.
En la otra función imprescindible, la función loop, haremos uso de funciones declaradas
en el sketch para realizar el envío de los datos por separado. Por lo tanto se han creado
tres funciones: writeAccel, writeGyro, writeYPR y writeTemPres. Cada una envía por BLE
los datos correspondientes mediante un buffer de bytes que es lo leen de los sensores
IMU. Esas funciones serán llamadas si el estado de del BLE es conectado. El BLE puede
tener tres estados diferentes:


33
• ACI_EVT_DEVICE_STARTED: El dispositivo se ha encendido y es visible a otros
dispositivos.
• ACI_EVT_CONNECTED: Se ha establecido una conexión con otro dispositivo.
• ACI_EVT_DISCONNECTED: Se ha terminado la conexión con otros dispositivos.
También se llamará a la función “pollACI()” que hace que el envío de datos a través del
BLE se haga de una manera ordenada y constante por eso se llama siempre al principio
del loop.
El envío de datos se hace a través de un buffer de bytes así que el receptor recibirá arrays
de bytes que tendrá que decodificar. Para que el receptor sepa que dato recibe cada vez
y los guarde y procese correctamente se ha decidido utilizar un separador para cada
dato que se envía.
Para los datos de la aceleración, rotación y ángulos de navegación siempre se enviarán
triplas con los datos de los ejes X, Y y Z. A cada eje se le destinan 5 bytes y entre cada
uno de ellos se insertará un carácter especial, que los diferencie entre ellos, de tamaño
1 byte por lo que el total de bytes enviados es de 17.
En el caso de la función que envía la temperatura y la presión, envía una dupla con los
datos de temperatura y presión separados por un delimitador. En este caso el tamaño
del bytes enviados es de 11 bytes.
La elección de los delimitadores no ha sido fácil pues no todos los caracteres son
aceptados, por ejemplo, el carácter y el carácter # daba problemas. Al final se ha
decidido utilizar:
• “/” para la aceleración.
• “%” para la rotación.
• “@” para los ángulos de navegación.
• “_” para la temperatura y la presión.

Con el sketch de Arduino terminado y cargado sobre la placa de Arduino y el IMUduino
funcionando de un modo wireless (sin cables), se puede empezar a trabajar en el
dispositivo que recibirá los datos y los procesará para dar al usuario una información
útil.


34
8.2. Desarrollo de la aplicación
Para el receptor y procesador de los datos, así como la visualización de los resultados se
ha decidido desarrollar una aplicación Android.
Se ha desarrollado con el IDE Android Studio que Google pone a disposición a los
desarrolladores de Android facilitando las cosas. Android Studio permite configurar el
entorno de ejecución, visualizar los archivos de un proyecto así como editarlos entre
muchas otras cosas. Es especialmente útil para la edición de los archivos .xml (pantallas
de la aplicación) ya que permite editarlo por código o a través de una interfaz gráfica y
sencilla sin tocar nada de código cómo se pude ver en la Figura 25.

Figura 25: Captura de pantalla del IDE Android Studio

8.2.1. Entorno y configuración
Google también pone a disposición de los usuarios unas herramientas de desarrollo
(SDK) y un conjunto de librerías. Para esta aplicación se ha decidido usar el SDK 24, y la
versión mínima de la API con la que funcionará nuestra aplicación es con la 21, que
corresponde a Android 5.0 (Lollipop). Esto hace que el número de dispositivos dónde se
puede instalar la aplicación sea de 3060. Esa cifra no representa el número máximo de
usuarios que puede tener la aplicación, representa el número de dispositivos que hay
en el mercado en dónde se podrá instalar la aplicación. Ese número nos lo proporciona
Google al subir el apk de nuestra aplicación a Google Play. También nos permite excluir
los dispositivos que queramos (p.e. si sabemos que en un determinado modelo de móvil
no funciona nuestra aplicación).


35
Para el desarrollo de Android existen diferentes herramientas para la automatización de
tareas como compilación, testing, empaquetado, etc. y para la gestión de dependencias.
Se ha decidido utilizar Gradle por su facilidad de uso y su integración con Android Studio.
Consiste en varios archivos en los que se establecen algunos parámetros de
configuración del programa. La última versión es la 2.1.2 y es la que se ha utilizado.
En uno de los archivos de Gradle se indica la configuración por defecto, que incluye:
• applicationId "com.quique.u_tad.arctic"
• minSdkVersion 21
• targetSdkVersion 24
• versionCode 2
• versionName "1.0"

Cada vez que se sube un apk nuevo a Google Play hay que cambiar la versión del código
ya que sino no dejará actualizar la aplicación.
En ese mismo archivo se definen también las posibles distintas configuraciones de
compilación. Para este proyecto se han definido dos distintas configuraciones: release y
debug. En esta configuración se pueden definir variables que luego se pueden utilizar en
el código de la aplicación y puede ser útil para hacer unas cosas dependiendo de si estas
en debug o en reléase. También se definen las opciones de firmado de la aplicación que
exige Google Play para poder publicar una aplicación. La de debug se ha utilizado
mientras se ha estado desarrollando y testando la aplicación y la de reléase se ha
utilizado a la hora de subirla a Google Play.
Y por último, el archivo Gradle nos permite gestionar las librerías y dependencias que se
utilizará en el programa. Cabe destacar que las versiones de las librerías de Google
deben de coincidir con el número de versión del SDK que se está utilizando, así pues, si
se ha trabajado con el SDK 24, las librerías de Google son 24.X.X .
Los archivos de Gradle son los primeros que mirará Android Studio cuando se intente
ejecutar o compilar la aplicación para definir la configuración sobre la que se ejecutará
o compilará el código por lo que es importante tenerlo bien configurado desde el
principio y simplemente ir añadiendo dependencias y librerías según se vayan
requiriendo.
Una vez se tiene el entorno definido y configurado se procede al desarrollo de la
aplicación y para eso se han definido unos requisitos que debe de cumplir la aplicación.


36
8.2.2. Requisitos de la aplicación
Se han definido una serie de requisitos mínimos que debe de cumplir la aplicación.
• Creación de una cuenta con nombre y email.
• Conexión vía Bluetooth al sensor IMUduino.
• Guardar el sensor para futuras conexiones.
• Registro de actividad y guardado de los datos en local.
• Opción de borrar actividad.
• Visualización de los datos y resultados.
• Edición y borrado de perfil.
• Contacto con el desarrollador de la aplicación para quejas y/o sugerencias.
• Compartir el enlace de descarga de la aplicación.
En un principio se definieron más requisitos pero convertía el proyecto en un proyecto
demasiado grande así que se decidió minimizar los requisitos para que el proyecto fuese
alcanzable.
Con esos requisitos de la aplicación se han creado unas historias de usuario que
ayudarán en la distribución de tareas a la hora de desarrollar la aplicación.
• Usuario inicia aplicación por primera vez.
• Usuario se da de alta en la aplicación.
• Usuario hace logout de la aplicación.
• Usuario tiene alguna duda o comentario.
• Usuario quiere grabar una actividad.
• Usuario quiere borrar una actividad.
• Usuario quiere cancelar una actividad.
• Usuario quiere guardar una actividad.
• Usuario quiere ver las actividades guardadas.
• Usuario quiere ver una actividad guardada.


37
• Usuario quiere emparejar el sensor.
• Usuario quiere guardar sensor para no tener que emparejarlo cada vez que
quiere utilizarlo.
• Usuario quiere eliminar el sensor guardado.
• Usuario quiere recomendar la aplicación a alguien.
Después de analizar las historias de usuario y los requisitos se han definido los diferentes
componentes que formarán parte del sistema.
8.2.3. Diagrama de componentes
Para visualizar la estructura de alto nivel del sistema y el comportamiento de los
componentes se ha decidido realizar un diagrama de componentes que se puede ver en
la Figura 26.

Figura 26: Diagrama de componentes del sistema

Cómo se puede observar en el diagrama, se requiere de una base de datos para el
almacenamiento de los datos.


38
8.2.4. Almacenamiento de datos
Para guardar los datos que se leen del sensor para su visualización y los datos del usuario
se utilizará la base de datos local del dispositivo en dónde este instalada la aplicación.
Android ofrece varios sistemas de almacenar información a las aplicaciones:
• SQLite es el sistema que utiliza Android para gestionar bases de datos. Es un
gestor de bases de datos relacional, de dominio público y muy ligero. La
información se guarda en un archivo dentro de la carpeta de la aplicación.
• Content Providers son unos componentes que ofrece Android para guardar
datos y ponerlos a disposición de otras aplicaciones del sistema.
• Shared Preferences son preferencias de la aplicación. Se guardan de la forma
clave-valor y se utiliza para guardar datos específicos.
Para esta aplicación se utilizará la base de datos SQLite para todos los datos del usuario
y para los datos recibidos por el sensor y las Shared Preferences para guardar la dirección
Bluetooth del sensor.

8.2.4.1. SQLite
Del usuario sólo se guardan el nombre, los apellidos y el correo electrónico. A pesar de
ser pocos datos y de sólo permitir un usuario, se ha optado por utilizar SQLite para los
datos de usuario para tener la opción de guardarlos en una base de datos remota en un
futuro.
Para los datos que se reciben del sensor tiene mucho más sentido guardarlos utilizando
SQLite porque son muchos datos y para su procesado se filtrarán y se ordenaran en
función de las necesidades. Cómo no sólo se guardan los datos recibidos del sensor, sino
que también se guarda cuando se ha empezado a leer datos, cuándo se ha parado, cómo
estaba la nieve, cómo se ha sentido el usuario, los giros que ha hecho y una puntuación
de la bajada del usuario, la estructura de la base de datos se complica un poco. En la
Figura 27 se puede observar el esquema de la base de datos utilizada para guardar las
actividades que registra el usuario y los datos que recibe del sensor.
Los datos son normalizados a 100 una vez son recibidos para poder hacer operaciones
con ellos. Para eso, después de insertarlos en la base de datos se ejecuta un update de
todas las tablas dividiéndolo por el máximo valor absoluto de cada fila. Con esta
normalización no sólo se facilita el hacer operaciones con ellos sino que mejora la
visualización de los datos en las gráficas.


39
Para utilizar SQLite con Android se deben de crear clases que extiendan de la clase
SQLiteOpenHelper. Cada clase que extienda de SQLiteOpenHelper deberá sobrescribir
los métodos onCreate y onUpdate. El primero se ejecutará la primera vez que se ejecute
la aplicación así que se crearán todas las tablas y si hay que meter algún dato por defecto
sé hará en ese momento. El método onUpdate recibe por parámetro la versión de la
base de datos actual y la antigua para saber si tiene que realizar algún cambio en la base
de datos. En esa misma clase se crean los métodos que ejecutan las queries de lectura,
escritura y borrado de datos.

Figura 27: Esquema de la base de datos utilizada en la aplicación

La carga de datos recibidos del sensor se ejecuta en segundo plano mediante una clase
que extiende de la clase Asynctask que nos pone a disposición Android para el manejo
de threads y las tareas en segundo plano. Esto hace que el rendimiento y la usabilidad
de la aplicación sean mejores, evitando en caso de una carga muy grande de datos, que
el usuario tenga que esperar a que se realice la carga de los datos y mientras puede
realizar otras tareas.


40
8.2.5. Arquitectura
A la hora de programar y de crear el software se ha intentado crear un software de
calidad y de conseguir un código que fuese robusto, mantenible, modulable y lo
suficientemente flexible para que estuviese abierto al cambio ya que los requisitos no
estaban cerrados y pensando también en un desarrollo futuro.
Para eso se tuvieron en cuenta lo principios de Clean Architecture [51]. No es una
arquitectura en sí, más bien son un conjunto de condiciones que hacen que la
arquitectura se considere “clean” y que hace que se consiga un software de mayor
calidad.
Además Clean Architecture respeta los principios S.O.L.I.D. que están orientados a la
programación orientada objetos e intentan que en lenguajes orientados a objetos se
pongan en práctica los conceptos de herencia, composición, abstracción,
encapsulamiento o polimorfismo y no se queden en simples definiciones.
Los principios S.O.L.I.D. se resumen en:
• Single Responsibility: cada objeto debe tener una única responsabilidad
• Open-Closed: abierto para la extensión, clausurado ante cambios.
• Liskov Substitution: las clases hijas deben poder ser tratadas como las clases
padre.
• Interface Segregation: es preferible muchas interfaces con pocos métodos a
pocas interfaces con muchos métodos.
• Dependency Inversion: los componentes deben depender de abstracciones, no
de implementaciones concretas.
Cómo se puede observar, S.O.L.I.D. corresponde a las iniciales de sus principios, de ahí
el nombre.
Volviendo a Clean Architecture, los principios que lo definen son:
• Independiente de Frameworks.
• Testeable.
• Independiente de la UI.
• Independiente de la BBDD.
• Independiente de cualquier agente externo.


41
Cómo se puede ver en la Figura 28, Clean Architecture estructura el código en capas.
En el ejemplo aparecen 4 capas, pero se puede adaptar a cada software incluyendo
las capas que sean necesarias siempre y cuando se cumpla la regla de dependencia:
las dependencias del código solo deben apuntar hacia dentro y nada dentro de un
círculo debe saber algo acerca del mundo exterior.

Figura 28: Esquema de los componentes de Clean Architecture [52]
En la Figura 28 se pueden diferenciar los siguientes elementos que son claves dentro de
Clean Architecture:
• Entities: objetos que representan el modelo de negocio.
• Use Cases: se encargan de comunicar la capa entities con las demás capas.
• Interface Adapters: se encargan de prearar los datos y darles un formato
adecuado para pasarlos a los casos de uso. Presenters y Controllers pertenecen
a esta capa.
• Frameworks y Drivers: UI, herramientas, frameworks, etc.
En Android lo que se intenta es separar al máximo las capas de negocio de las capas que
más dependen de Android para que el código se portable y facilite el testeo. Se propone
dividirlo en tres capas: presentation ,domain y data tal y como se puede ver en la Figura
29. Además cada capa tiene su propio modelo de datos para que las capas sean
totalmente independientes y no guarden ninguna dependencia.


42

Figura 29: Representación de cómo se aplica Clean Architecture en una aplicación Android [53]

En este proyecto se ha seguido al máximo los principios de Clean Architecture y además
se ha intentado gestionar las dependencias de una forma óptima. Para eso se ha creado
una clase principal App.java que gestiona las dependencias más significativas y cada vez
que se hace uso de ellas, se hace a través de esa clase. De esta forma evitamos el uso
excesivo de “new”.
Con todo lo anterior aplicado a nuestro proyecto queda una estructura de archivos que
se puede ver representada en la Figura 30.

Figura 30: Estructura del proyecto ARCTIC


43
8.2.6. Comunicación BLE
La comunicación con el sensor vía Bluetooth Low Energy es muy importante ya que en
caso de fallo o de pérdida de conexión la aplicación no sería útil. Se realiza mediante un
servicio de Android. Los servicios en Android permiten ejecutar largas tareas en segundo
plano. Como no se sabe cuánto va a durar la conexión se ha decidido utilizar un servicio
en vez de un Asynctask, que es más aconsejable para tareas cortas.
Se ha usado el ejemplo creado y publicado por la empresa Nordic Semiconductor [54]
para entender el funcionamiento de la comunicación y adaptarla a nuestro ejemplo.
Para facilitar la comunicación con el sensor se ha decidido guardar la dirección Bluetooth
del sensor una vez se realice la primera conexión con éxito de tal forma que las
siguientes veces, cuando se pretenda grabar una bajada de esquí, se muestre la pantalla
de empezar a grabar y no la pantalla de emparejar dispositivo. Siempre está la opción
de olvidar dispositivo desde la opción de ajustes.
En la Figura 31 se puede ver el modelado del proceso de conexión con el sensor vía
Bluetooth.

Figura 31: Modelado BPMN de la conexión con el sensor vía Bluetooth.


44
8.2.7. Interfaz de Usuario
La interfaz de usuario se ha hecho siguiendo las pautas que Google propone para el
diseño de aplicaciones Android mediante Material Design.
Para empezar, se ha creado una pantalla de presentación de la aplicación en la que se
realizan tareas en segundo plano cómo la carga de datos o la comprobación de usuario.
En esta pantalla se puede ver el logo de la aplicación con el nombre y el slogan que se
ha elegido. También aparece un círculo de estado animado indicando que se están
ejecutando acciones en segundo plano. El tiempo máximo de esta pantalla es de tres
segundos.

Figura 32: Captura de pantalla de splash screen de la aplicación ARCTIC.
Una de las acciones en segundo plano que se ejecutan en la pantalla de la Figura 32, es
la de comprobar si existe un usuario logeado previamente. En caso negativo la siguiente
pantalla es un formulario para crear un usuario. En caso positivo nos dirige a la pantalla
de Inicio de la aplicación.
8.2.7.1. Formulario de alta de usuario
Para poder empezar a usar las aplicación y hacer uso de todas las funciones disponibles
hace falta rellenar un formulario de alta de usuario que consta de nombre, apellidos y


45
email. Esos datos se guardan en una base de datos local y por lo tanto no sirven más que
para comprobar si hay algún usuario logeado y para utilizar el nombre y el correo para
acciones concretos, es la razón por la que no se piden más datos como contraseña, fecha
de nacimiento o dirección.
Si en un futuro se desease comercializar la aplicación y tener una buena base de datos
de usuario en un servidor externo se deberá modificar este formulario para usuarios
nuevos, y pedir los datos adicionales a los usuarios que ya estén utilizando la aplicación.
El formulario cuenta con una comprobación de campos y en el caso de estar incorrectos
te dice que campos se deben modificar y rellenar correctamente. Para nombre y
apellidos permite utilizar palabras normales y para el email permite ingresar una cadena
de texto de la forma: texto@texto.ext.
En la Figura 33 se puede ver un ejemplo de formulario incorrectamente rellenado y el
mensaje que se muestra al usuario. También se ha utilizado una animación para el
nombre de los campos. Si el campo está vacío, el nombre sale dentro del campo en un
color más suave que el texto normal. Cuando se pulsa en el campo para introducir un
texto, el nombre se sitúa en pequeño en la parte superior izquierda. De esta forma, se
puede saber en todo momento el nombre de cada campo.
Cabe destacar que los datos introducidos en este formulario no son definitivos y se
pueden modificar en un futuro. En esta pantalla también se puede ver el nombre de la
aplicación en la parte superior.


46

Figura 33: Captura de pantalla del formulario de alta de usuario de la aplicación ARCTIC de Android

8.2.7.2. Navigation Drawer
Todas las pantallas de la aplicación una vez el usuario esta logeado están compuestas
por una barra de herramientas (Toolbar) en la parte superior y el resto de pantalla se
dedica a un contenedor de contenido (content layout). Dependiendo de la pantalla
cambia el contenido del contenedor y el título y las herramientas disponibles en el
toolbar. Cómo recomienda Google con el Material Design, el toolbar debe estar en
diferente altura al contenedor ya que es un elemento más importante y se puede
observar que el toolbar crea una pequeña sombra sobre el contenedor.
En la aplicación hay tres pantallas principales desde las cuales se pueden realizar todas
las funciones que tiene la aplicación. Para poder navegar entre esas pantallas, se ha
utilizado un Navigation Drawer, o un menú lateral deslizante. Este tipo de menú es
accesible mediante un botón de menú en la barra de herramientas o mediante la acción
de desplazar el dedo desde la parte izquierda de la pantalla hacia el lado opuesto. Como
se puede ver en la Figura 34, en el Navigation Drawer muestra una breve información
del usuario en la parte superior, formada por el nombre y por el mail del usuario y se
puede acceder a la pantalla de Inicio, la pantalla de Perfil y la pantalla de Ajustes.


47
También se pueden realizar acciones cómo enviar un correo con dudas o comentarios
de la aplicación o compartir mediante correo o redes sociales un enlace para la descarga
de la aplicación.

Figura 34: Captura de pantalla del navigation drawer de la aplicación ARCTIC de Android


48
8.2.7.3. Inicio
La pantalla de inicio es la más importante pues es desde dónde se realizan las acciones
de grabar nueva actividad o de visualizar una actividad guardada previamente.
Para eso se ha incluido una lista con todas las actividades guardadas del usuario. Para la
lista se han utilizado un componente que Google nos ofrece en sus librerías, las cards.
Las cards nos permiten personalizar qué se va a ver en cada elemento de la lista. En este
caso, se ha decidido poner información útil para que el usuario pueda seleccionar bien
la bajada que quiere ver en detalle. Las cards, como se puede ver en la Figura 35, están
formadas por un icono de un esquiador (si en un futuro se incluyen otros deportes con
los que se puedan utilizar el sensor como snow, patines en línea o surf, ese icono
cambiaría), la duración de la bajada guardada, una breve descripción que el usuario
puede añadir para cada bajada, y un texto en la parte derecha que indica cuándo se
realizó la bajada. Ese valor puede ser desde “hace un momento” hasta “hace 2 días”.

Figura 35: Card de una bajada de la lista de bajadas de la pantalla de inicio de la aplicacion ARCTIC de Android.
Se ha implementado una opción en las cards para realizar la acción de borrar actividad
que consiste en un animación mediante la cual aparece un menú con el botón de borrar.
Para eso se debe arrastrar la card hacia la izquierda de la pantalla, gesto conocido como
swipe. Para saber sobre qué card se ha realizado la acción, la card seleccionada se
oscurece para destacar sobre el resto. Si se pulsa en el botón de borrar la card
desaparecerá y se borrará la actividad de la base de datos. Se pueden seleccionar varias
cards a la vez. Para volver al estado inicial y deseleccionarla se debe realizar el swipe en
sentido contrario, es decir, hacia la derecha de la pantalla. En la Figura 36 se pueden ver
distintas cards seleccionadas y con el menú adicional visible para poder realizar la acción
de borrar. En el caso de realizar la acción de borrar, se informará al usuario con un
mensaje de que la actividad se ha eliminado correctamente.


49

Figura 36: Captura de pantalla de inicio con varias cards seleccionadas de la aplicación ARCTIC de Android.
En la lista de actividades guardadas se puede hacer scroll vertical debido a que en una
pantalla no se pueden visualizar muchas actividades, de esta manera se pueden acceder
a todas desde la misma pantalla sin mucha complicación.
En la Figura 36 también se puede observar un Floating Action Button en la parte inferior
derecha. Ese botón especial también es una recomendación de Google. Como
característica principal es que no se mueve si se hace scroll en la lista por lo que es
accesible siempre en esa pantalla. Se utiliza para acciones destacadas, y en este caso, se
utilizar para grabar una nueva actividad. Se ha utilizado un color destacado al resto para
llamar la atención del usuario. Si se pulsa en él se puede observar una animación del
icono del esquiador que contiene.


50
8.2.7.4. Emparejamiento de dispositivos
A esta pantalla se accederá tras pulsar el Floating Action Buttton de la pantalla de inicio
y es la primera vez que se hace o si se ha eliminado el dispositivo Bluetooth en ajustes.
Aparecerá una pantalla para emparejar dispositivos como la de la Figura 37.

Figura 37: Captura de pantalla del emparejamiento Bluetooth con el sensor.
Como se puede observar, aparece el sensor ARCTIC que previamente habíamos
desarrollado. También cabe destacar la diferencia en el toolbar, ya que ahora aparece
un icono diferente que realiza la acción de ir a la pantalla anterior en vez de mostrar el
Navigation Drawer.
También hay un icono en el toolbar secundario que indica cuándo está escaneando
dispositivos Bluetooth y cuando no. Cuando deja de escanear, aparece un icono de
actualizar para que vuelva a escanear en el caso de que no aparezca el sensor ARCTIC a
la primera.
Para realizar el enlace, basta con pulsar sobre el dispositivo Bluetooth ARCTIC. Si se pulsa
sobre otro dispositivo no compatible con la aplicación, mostrará un mensaje informando
al usuario de que ha elegido un dispositivo no compatible. Si se pulsa sobre el dispositivo
correcto, nos llevará a la pantalla de grabar actividad y aparecerá un mensaje que
indicará que el dispositivo está guardado para futuras conexiones.


51
8.2.7.5. Nueva Actividad
A esta pantalla se accederá bien después de emparejar el dispositivo o si se pulsa el
botón de la pantalla de inicio.
Es una pantalla simple que está compuesta por un botón de start/stop y de una imagen
que tiene la misma función de start/stop (Figura 38). Si se pulsa, el botón cambia de
start a stop y la imagen se anima y el dispositivo empieza a recibir datos del sensor.
Además, por precaución, se realiza un bloqueo de las funciones para evitar que se pause
la actividad por accidente. En ese bloqueo de pantalla, el botón y el icono cambian de
color indicando que no están activos. Para poder desbloquear la pantalla y parar la
actividad, se ha creado un botón de desbloquear. Este botón cambia si se pulsa para
poder volver a bloquear la pantalla en caso de que no se quiera parar. Todo esto se
puede ver claramente en las capturas de pantalla de la Figura 39.

Figura 38: Captura de pantalla de nueva actividad de la aplicación ARCTIC de Android


52

Figura 39: Capturas de pantalla bloqueada y desbloqueada una vez iniciada la actividad de la aplicación ARCTIC de
Android
Si se pulsa el botón de stop o el icono estando desbloqueada la pantalla, la actividad se
dará por finalizada y se ira a un formulario para que el usuario añada datos que no se
pueden medir con el sensor cómo el estado de la nieve o cómo se ha sentido en la
bajada.
Si se quiere cancelar la bajada por cualquier motivo, basta con pulsar el botón de atrás
del toolbar, de esa manera no se guardará ningún dato en base de datos y por lo tanto
no aparecerá en el listado de actividades de la pantalla de inicio.

8.2.7.6. Formulario de Nueva Actividad
Para que el usuario pueda completar los datos de la bajada y que en un futuro pueda
comparar y/o analizar resultados, se ha creado un breve formulario para completar
justo después de la bajada. En ese formulario se piden los siguientes datos:
• Estado de la nieve, importante ya que es más fácil hacer una buena bajada con
nieve en buen estado que hacerla con una nieve muy dura o excesivamente
blanda. Los valores pueden ser: Hielo, Dura, Perfecta, Blanda o Agua (es utilizado


53
frecuentemente por esquiadores para indicar que la nieve está excesivamente
blanda).
• Feelings que ha tenido el usuario en esa bajada. Se ha pensado que puede ser
importante para ver si realmente la puntuación corresponde a lo que siente el
usuario. En el caso de haberse encontrado genial y que la puntuación sea baja
significará que está cometiendo errores y que debe trabajar en ellos. Los valores
que puede tomar son: Miedo, Mal, Normal, Bien o Genial.
• Comentarios. Esto permite al usuario hacer alguna anotación extra como la pista
en la que se ha hecho, si era a primera hora del día o cualquier otra cosa que se
le ocurra para poder identificarla. Este comentario es el que luego aparecerá en
la card de la pantalla de inicio.
Para validar el formulario y guardarlo hay un Floating Action Button en la esquina
inferior derecha que llamará la atención del usuario.
Este formulario no es obligatorio por lo que se puede dejar en blanco y darle a enviar o
se puede pulsar el botón de atrás del toolbar sin preocuparse de perder los datos ya que
estos se guardarán.

Figura 40: Captura de pantalla del formulario de nueva actividad de la aplicación ARCTIC de Android


54
Como se puede observar en la Figura 40, para la selección del estado de la nieve y del
feeling del usuario se ha utilizado una barra con botones de selección. Esto hace que
solo se pueda elegir una opción a la vez. En caso de seleccionar alguna, cambiará de
color indicando que está seleccionada.
Cuando se pulse al botón de validar, se redirigirá a la pantalla de inicio y ya aparecerá la
nueva actividad guardada.

8.2.7.7. Detalle de Actividad
Cuando se pulsa una actividad de la lista de actividades de la pantalla de inicio, se
mostrará una información detallada de la actividad en esta pantalla. Se mostrarán los
siguientes datos:
• Número de giros, que se calculan con los datos recogidos con el sensor.
• Duración de la bajada en el formato MIN:SEG.
• Feeling, que es el que indicó el usuario en el formulario de nueva actividad. En
caso de no haberlo completado, el estado será: Normal. Dependiendo del
estado, aparece un emoticono representado el estado.
• Estado de la nieve que también indicó en usuario en el formulario. En caso de no
haberlo completado, el estado de la nieve será: Blanda.
• Puntuación, que se calcula con un algoritmo aplicado a los datos tomados. Se
representa gráficamente con estrellas, de 1 a 5 pudiendo tomar valores medios
como 3,5 estrellas, en ese caso, se pintarán las tres primeras estrellas negras, la
cuarta mitad negra mitad vacía, y la quinta vacía entera.
• Unas gráficas que se dibujan con los datos tomados por el sensor. Aparecen tres
gráficas: Aceleración, Rotación y Yaw Pitch Roll o ángulos de navegación. Para un
usuario estándar no dice mucho, pero para alguien que sepa interpretar los datos
puede resultar muy útil. Para poder mostrar las tres gráficas con un tamaño
aceptable en la misma pantalla sin tener que hacer scroll vertical, se ha optado
por utilizar un sistema de pestañas en las que cada una contiene un gráfico. Se
puede cambiar de pestaña o haciendo swipe hacia los lados o pulsando en la
pestaña que se quiera visualizar. Los gráficos son interactivos, es decir, que se
pueden ampliar y mover para verlo más en detalle. Cuando se selecciona una
gráfica, los datos se dibujan de forma animada.
Se puede ver un ejemplo de pantalla en la Figura 41. En ese ejemplo, el usuario ha
realizado 4 giros, en 35 segundos, se ha sentido genial y la nieve estaba excesivamente


55
blanda. Ha obtenido una puntuación de 5 estrellas. Y también se aprecia la gráfica de
Yaw Pitch Roll.
Para volver a la pantalla de inicio y ver todas las actividades basta con pulsar el botón
de atrás del toolbar.

Figura 41: Captura de pantalla de actividad detallada de la aplicación ARCTIC de Android


56
8.2.7.8. Perfil
Esta pantalla es accesible desde el Navigation Drawer y permite al usuario modificar los
datos introducidos en el formulario de alta de usuario. Cuando se abre, aparece el
mismo formulario que en el de alta de usuario pero esta vez con los datos del usuario
en los campos correspondientes en vez de vacíos.
El funcionamiento es el mismo que el del formulario de alta de usuario, pero esta vez en
vez de un botón de enviar, aparece un botón de guardar. Pulsando en él se guardarán
los cambios y se notificará al usuario mediante un mensaje que se han guardado los
datos correctamente como se puede apreciar en la Figura 42.
También cuenta con una comprobación de campos que notificará al usuario en caso de
no estar rellenos todos o de estar incorrectos.

Figura 42: Captura de pantalla de perfil de la aplicación ARCTIC de Android

8.2.7.9. Ajustes
Por último, está la pantalla de ajustes de la aplicación que están divididos en dos
apartados, Bluetooth y Cuenta. Está diseñado para que en un futuro, si se desea agregar


57
otro apartado con sus ajustes, se haga con relativa facilidad. En estas dos categorías se
permite al usuario realizar las siguientes acciones:
• Olvidar dispositivo Bluetooth emparejado. En caso de haber realizado el
emparejamiento con el sensor, aparecerá la dirección Bluetooth del sensor y un
botón de eliminar. Al ser una acción importante, cuando se pulsa el botón de
borrar aparece una alerta informando de las consecuencias de la acción y
preguntando si desea olvidar el dispositivo Bluetooth. Se puede apreciar en la
Figura 43. Para mostrar esa alerta se ha utilizado un Alert Dialog. Están pensados
para confirmar e informar de acciones que conllevarán cambios en la aplicación.
• Cerrar sesión y borrar datos de la cuenta de usuario. Al ser también una decisión
importante se mostrará un Alert Dialog como se puede apreciar en la Figura 43.

Figura 43: Captura de pantalla del Alert Dialog para confirmar borrado de dispositivo Bluetooth y para confirmar el
logout de la aplicación ARCTIC de Android

8.2.7.10. Idioma
Se ha decidido desarrollar toda la aplicación tanto para inglés como para español. Para
eso se utiliza un archivo “strings.xml” para cada idioma. Ese archivos contendrá los


58
strings que luego se utilizarán en el programa. Se encuentran en la carpeta values de los
recursos. Para cada idioma se crea una carpeta de values-CODIGO_IDIOMA que
contendrá su archivo strings. Es necesario que todos los archivos strings tengan las
mismas variables. Se usará un archivo u otro en función de la configuración de idioma
del móvil. En caso de no tener una carpeta dedicada a ese idioma, se utilizará el de la
carpeta values, que suele ser el de inglés.

8.2.7.11. Estructura UI
La estructura de la interfaz gráfica se divide en carpeta y cada carpeta contiene recursos
que se utilizarán para la interfaz gráfica. En la figura se pueden ver las diferentes
carpetas que forman parte de la estructura.
Las carpetas de drawable contienen los distintos iconos e
imágenes utilizados. Hay varias carpetas drawable en
función de la resolución de la pantalla en dónde se utilicen
los recursos.
La carpeta de anim contiene las animaciones utilizadas en
los iconos.
En la carpeta layout están todas las vistas utilizadas, ahí es
donde están todas las pantallas.
En la carpeta menú se definen los diferentes menús
utilizados, en este caso, el del naviagtion drawer.
Las carpetas mipmap contienen el icono de la aplicación
que se utilizará cuando se instale la aplicación en un
dispositivo.
Y por último la carpeta values que además de contener el archivo strings.xml, se pueden
definir otros archivos cómo colors.xml, dimens.xml, styles.xml, etc.. Se puede ver que
hay varias carpetas values en función del idioma del dispositivo para el archivo
strings.xml y otras en función de la versión del dispositivo o de la resolución de la
pantalla del dispositivo.


59
8.2.8. Análisis de los datos
Con los datos tomados por el sensor del acelerómetro, giroscopio y los ángulos de
navegación, se ha decidido realizar dos cálculos para mostrar el número de giros hechos
en una bajada y una puntuación.
8.2.8.1.Número de giros
Para calcular el número de giros se han tenido en cuenta los datos del eje X del
acelerómetro. Esos datos nos indican que ha habido un movimiento del sensor en ese
mismo eje, siendo positivo hacia un lado y negativo para el lado contrario. Esto significa
que cada vez que la gráfica corte el eje X en 0 se estará realizando un cambio de
dirección, es decir, un giro. Para detectar ese corte del eje X con los datos tomado se ha
creado el siguiente algoritmo en Java:
El algoritmo detecta cuándo la gráfica empieza a tomar datos positivos y cuándo
empieza a tomar datos negativos. Cuando se den esas dos condiciones, se aumenta el
número de giros y se ponen los detectores a false. Después de muchas pruebas,
modificaciones y optimizaciones se ha llegado a un algoritmo bastante preciso.

int giros = 0;
boolean corte_subida = false;
boolean corte_bajada = false;
for(int i = 1; i < data_acc_x.size(); i++){
if(data_acc_x.get(i) > 0){
if(!corte_subida){
corte_subida = true;
}//if
}else if(!corte_bajada){
corte_bajada = true;
}//if-else
if(corte_subida && corte_bajada){
giros ++;
corte_subida = false;
corte_bajada = false;
}//if
}//for


60
8.2.8.2.Puntuación
Desde el primer momento que se pensó en la aplicación, se tuvo la idea de incluir una
puntuación para que el usuario obtuviese algún dato sencillo y útil para interpretar el
resultado. Tras un análisis del esquí, aplicando conocimientos de profesionales y
contando con los datos del sensor, se llegó a un algoritmo basado en la pendiente de la
pista y la angulación del esquí.
Para la pendiente de la pista, se ha utilizado una función que calcula la pendiente media
de la pista. Para ello se ha calculado la media de los valores del eje Y del acelerómetro
que están normalizados a 1, por lo tanto los datos están en el intervalo [-1,1] y luego se
ha hecho la conversión a tanto por ciento. 1 = 100%, 0.5 = 50%.

Figura 44: Imagen aclarativa de la inclinación de la pista.

Se entiende angulación del esquí como el ángulo que forma respecto al eje horizontal.
La angulación del esquí es fundamental a la hora de realizar un buen giro. A mayor
angulación del esquí, menor será el radio de giro por lo tanto se hará un giro más
cerrado. Esto es debido a que cuanto mayor sea la angulación del esquí más presión se
ejerce sobre él y por lo tanto más se dobla y cuanto más doblado esté, el radio de giro
es menor. En la Figura 45 se puede ver claramente qué es la angulación del esquí.
Por otro lado, el contacto de la suela del esquí con la nieve influye en la velocidad del
esquiador pues cuanta mayor superficie de suela esté en contacto con la nieve mayor
será la velocidad que se gana. Los esquiadores profesionales aplican cera fluorada a la
suela para disminuir la fricción y ganar aceleración.
Para calcular la angulación media del esquí se han utilizado los valores que tomaba el
acelerómetro en el eje X normalizados a 1 y luego se ha expresado en tanto por ciento.


61

Figura 45: Imagen representativa de la angulación de los esquís.
Después del análisis realizado y teniendo en cuenta la experiencia, se ha decidido tener
en cuenta los siguientes casos para analizar y puntuar una bajada:
• Si el esquiador está realizando una bajada por una pista con mucha pendiente y
difícil, necesitará realizar giros cortos y controlados para tener en todo momento
el control y llevar una velocidad adecuada a la pista y para eso necesitara realizar
una mayor angulación de esquís.
• En cambio, si el esquiador está realizando una bajada por una pista sencilla con
poca pendiente, le interesará realizar giros más amplios y más suaves para
maximizar el contacto de la suela con la nieve y no perder velocidad.
Teniendo en cuenta esas dos premisas, se ha llegado a la siguiente fórmula para obtener
una puntuación sobre 100.
!"#$"%&'(# = 100 − !.#/'.#$.01234 − %#5"6%&'(#01234
Se utiliza el valor absoluto de la diferencia entre la pendiente media y la angulación
media puesto que a mayor pendiente se necesitará mayor angulación por lo tanto la
diferencia será menor y la puntuación será más alta. Por el contrario, a menor pendiente
se necesitará una menor angulación y por lo tanto la diferencia será menor y la
puntuación será más alta también.
También se han hecho varias pruebas y muchas modificaciones y optimizaciones y al
final los resultados obtenidos parecen bastante óptimos.


62
8.2.9. Publicación en Google Play
Se ha decidido llevar a cabo una publicación beta para el testeo de la aplicación. Para
ello se ha utilizado la plataforma de distribución de aplicaciones Google Play, la más
popular dentro del mercado de los dispositivos Android. Existen otras plataformas como
Samsung Galaxy Apps, sólo para dispositivos Samsung, o Aptoide, una plataforma
independiente de apps para Android.
Para que fuese aceptada en Google Play se han tenido que cumplir una serie de
requisitos que se van a explicar a continuación.
• Clasificación del contenido: mediante esa clasificación se permite al usuario
conocer sobre diferentes clasificaciones populares y relevantes a nivel local
orientando el contenido a la audiencia adecuada. Es necesario contestar un test
sobre el contenido de tu aplicación y automáticamente te calcula la clasificación
de los contenidos. En el caso de la aplicación han salido los siguientes resultados:

Figura 46: Clasificación del contenido para la aplicación ARCTIC

• Precio y distribución. Se ha elegido ponerla gratuita ya que lo que daría
beneficios si se sacase a mercado es la venta del sensor y la distribución se han
seleccionado todos los países posibles.


63
• APK, se ha subido el apk generado con Anroid Studio de la rama release firmada
con una firma digital creada con los datos del autor de este trabajo.
• Ficha del Play Store. Esta ficha es una especie de descripción de la aplicación en
la que hay que rellenar los siguientes campos:
o Título: ARCTIC
o Descripción breve: Guarda y analiza todas tus bajadas de esquí con un solo
click!
o Descripción completa: ARCTIC permite, junto a un sensor acoplado al esquí,
analizar los detalles de tu bajada de esquí y visualizar los resultados.
o Capturas de pantalla: Se han subido las mismas que se han utilizado en este
trabajo.
o Icono de alta resolución:

Figura 47: Icono de alta resolucion 512x512 de ARCTIC
o Imagen destacada:

Figura 48: Imagen destacada de la aplicación ARCTIC de Android

o Categoría: Salud y bienestar.
o Clasificación del contenido: Para todos
o Correo electrónico: kike.acedo@gmail.com

Capítulo 9. ¿Por qué ARCTIC?

64
9. ¿Por qué ARCTIC?
Se ha intentado elegir un nombre original y diferente, que enganchase a la gente y que
tuviese tirón y crease marca.
Para eso se dispuso de la ayuda de una diseñadora, Irene Luna, que fue la que se encargó
de la elección del nombre, de la elección del slogan, de la creación del logo y de la
elección de los colores, siempre contando con mi opinión, mi ayuda y mis críticas.
En la elección del nombre se trató de buscar un nombre fácil de nombrar, corto y que
tuviese relación con el mundo de la nieve y de la montaña. ARCTIC que significa relativo
al Ártico pensamos que es un nombre que diferencia la marca y que representa el hielo.
Por otra parte se pensó en el slogan y se llegó a la siguiente frase: “The future is now.”
Escrita se entiende como que el futuro es ahora. Pero leído se puede entender también
como: “The future’s snow” o La nieve del futuro. Pensamos que esas dos frases:
• El futuro es ahora
• La nieve del futuro
resumen y representan el producto del sensor ya que mezcla la nieve con las nuevas
tecnológicas que es el futuro.
Con el nombre y el slogan definidos, la diseñadora se encargó de realizar el logo y una
imagen del logo con el slogan que se pueden apreciar en la Figura 49.

Figura 49: logotipo y slogan de ARCTIC
Se puede observar que ha jugado con los colores para que en el slogan se diferencie
claramente la palabra SNOW. También cabe destacar los colores del logo, que son los
usados en la aplicación como verde más claro cómo color principal, verde oscuro cómo
color secundario, el negro el color del texto y el blanco el fondo de la aplicación.

Capítulo 10. Resultados

65
10. Resultados
Para probar la calidad del trabajo realizado se han realizado dos tipos de pruebas:
• Pruebas de calidad. Estas pruebas se han pensado para medir la calidad del
código realizado y ver en qué puntos hay que mejorar para conseguir un código
de calidad en un futuro. Para estas pruebas se ha utilizado una herramienta
online de análisis del código llamada Kiuwan [55]. El análisis se ha realizado sobre
el código Java del proyecto y los resultados han sido bastante satisfactorios. En
la Figura 50 se puede ver un resumen del análisis realizado. Cómo se puede
observar, las áreas de seguridad, eficiencia, portabilidad y confiabilidad del
código superan el target establecido (90 sobre 100 por defecto). En cambio en la
mantenibilidad del código esta dos tercios por debajo de lo esperado.

Figura 50: Resumen del análisis de código realizado con la herramienta Kiuwan.


66
• Pruebas funcionales. En este caso se ha trabajado en la funcionalidad de la
aplicación, es decir, se ha comprobado si la aplicación cumple con los requisitos
descritos en el apartado 8.2.2. y para ello se han diseñado una serie de pruebas:
1. Registro de usuario con datos no válidos y con datos válidos.
2. Edición de datos de usuario con datos no válidos y con datos válidos.
3. Logout de la aplicación.
4. Emparejamiento con un dispositivo BLE.
5. Acción de borrar el sensor y volver a emparejarlo.
6. Emparejar con un dispositivo no compatible y tratar de grabar actividad
7. Acción de recomendar aplicación.
8. Acción de enviar comentario al desarrollador.
9. Grabación, visualización de nueva actividad y borrado de una actividad.
10. Cancelación de una actividad.
11. Grabación y visualización de una actividad con una puntuación alta y otra
con puntuación baja
Con esa batería de pruebas se ha intentado abarcar todos los requisitos de la aplicación.
Esta batería de pruebas se ha ido diseñando según se iban implementando
funcionalidades con el fin de probarlas. Y nos han servido para corregir errores y mejorar
la aplicación.
Los resultados de las pruebas funcionales han sido los siguientes:
1. Registro de usuario con datos no válidos y con datos válidos: OK
En la pantalla del formulario de nuevo usuario se ha introducido para el campo
de nombre y de email valores incorrectos. En la Figura 51 se pueden ver las
diferentes capturas de pantalla que se han dado en la prueba. Se puede
observar que el texto “123” no es válido para el nombre y que la dirección de
correo “kike@gmail” tampoco es válida. Una vez corregidos esos campos, sí
que permite crear el usuario correctamente.


67

Figura 51: Resultados de caso de prueba 1


68
2. Edición de datos de usuario con datos no válidos y con datos válidos: OK
En este caso de prueba se ha intentado editar el perfil con unos datos no
válidos. Se ha utilizado el texto “Acedo2” para el campo de apellido y el texto
de “kike. acedo@gmail.com”. Una vez corregido el número del apellido y el
espacio del email, el usuario se ha guardado correctamente.

Figura 52: Resultados del caso de prueba 2
3. Logout de la aplicación: OK
Está situación es muy importante ya que es una acción que puede tener
grandes consecuencias por lo que se esperaban dos cosas. La primera es que
aparezca un alert dialog que pregunte por la confirmación de la acción y en caso
de confirmar, y el otro es que se borren todos los datos.
En este caso, sólo se puede demostrar si aparece el alert dialog con la pregunta
de confirmación. Respecto al borrado de datos, se puede confirmar mediante
el Log de la aplicación que se observa en la Figura 53.

Figura 53: Log del caso de prueba 3


69

Figura 54: Resultado del caso de prueba 3
4. Emparejamiento con sensor: OK
En este test se ha comprobado que se realice el emparejamiento con el sensor
correctamente y que se guarde la dirección Bluetooth para futuras conexiones.

Figura 55: Resultados del caso de prueba 4

Trabajo Final de Grado - Arctic

Trabajo Final de Grado - Arctic

Recomendados

Recomendados

Más contenido relacionado

Similar a Trabajo Final de Grado - Arctic

Similar a Trabajo Final de Grado - Arctic (20)

Último

Último (20)

Trabajo Final de Grado - Arctic