ACCELBIKE

ACCELBIKE RODRIGO CLAUDIO MIGUEZ REIN DAVID MUÑOZ LORENZO ALEXIS VIZCAYA HERVELLA GRADO EN INGENIERÍA DEL SOFTWARE. FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID Trabajo Fin Grado en Ingeniería del Software 17 de Junio de 2016 Directores: José Ignacio Gómez Pérez Luis Piñuel Moreno Autorización de difusión 17 de Junio de 2016 Los abajo firmantes, matriculados en el Grado en Ingeniería del Software de la Facultad de Informática, autoriza a la Universidad Complutense de Madrid (UCM) a difundir y utilizar con fines académicos, no comerciales y mencionando expresamente a sus autores el presente Trabajo Fin de Grado: “ACCELBIKE”, realizado durante el curso académico 20152016 bajo la dirección de José Ignacio Gómez Pérez y Luis Piñuel Moreno en el Departamento de Arquitectura de Computadores y Automática, y a la Biblioteca de la UCM a depositarlo en el Archivo Institucional E-Prints Complutense con el objeto de incrementar la difusión, uso e impacto del trabajo en Internet y garantizar su preservación y acceso a largo plazo. Rodrigo C. Míguez Rein David Muñoz Lorenzo Alexis Vizcaya Hervella Resumen en castellano Este proyecto consiste en el diseño e implementación de un dispositivo que permite el registro de los datos de acelerometría de un trayecto realizado por un ciclista para medir el esfuerzo experimentado por éste. Este dispositivo se fijará al manillar o la tija de una bicicleta de montaña y se complementará con la información proporcionada por el GPS de un móvil. Los datos de acelerometría registrados por el dispositivo se enviarán a dicho dispositivo móvil mediante Bluetooth Low Energy, cuyo funcionamiento se explicará durante el transcurso de esta memoria. Palabras clave Bluetooth Low Energy, Bluetooth Smart, I2C, Android, App, ARM mbed, Ciclismo, Acelerómetro Abstract This project consists in presenting the design and implementation of a specific device which allows for registering accelerometry data obtained from a route made by a cyclist, for measuring the effort that he/she experiences. This device will be fixed to the handlebar or the seatpost of a mountain bicycle and it will be complemented by information that is provided by the mobile phone’s GPS. The data registered by the sensor will be sent to the mobile phone using Bluetooth Low Energy, whose functioning is also explained in this memory project. Keywords Bluetooth Low Energy, Bluetooth Smart, I2C, Android, App, ARM mbed, Cycling, Accelerometer Índice general Índice i List of Figures iii Agradecimientos iv 1. Introducción 1 1.1. Entornosdedesarrollo .............................. 3 1.2. Bluetooth Smart: Bluetooth de bajo consumo . . . . . . . . . . . . . . . . . 3 1.3. Especificación del objetivo del proyecto . . . . . . . . . . . . . . . . . . . . . 4 1.4. Contribuciones Personales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4.1. Rodrigo Claudio Miguez Rein . . . . . . . . . . . . . . . . . . . . . . 5 1.4.2. DavidMuñozLorenzo .......................... 7 1.4.3. Alexis Vizcaya Hervella . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Bluetooth Low Energy 12 2.1. Comparación con Bluetooth Clásico . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. Tecnología..................................... 14 2.2.1. Controlador................................ 14 2.2.2. Anfitrión.................................. 15 2.2.3. Aplicación................................. 18 2.3. Descubrimiento de dispositivos y enlazado . . . . . . . . . . . . . . . . . . . 18 2.3.1. ModoBroadcast ............................. 19 2.3.2. ModoConexión.............................. 20 2.4. Generic Attribute Profile (GATT) . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4.1. Roles.................................... 21 2.4.2. Jerarquíadedatos ............................ 22 2.4.3. UUIDs................................... 25 3. Exploración Hardware 27 3.1. Selección de plataformas de desarrollo . . . . . . . . . . . . . . . . . . . . . . 29 3.1.1. Análisis de las plataformas escogidas . . . . . . . . . . . . . . . . . . 30 3.2. Conclusión..................................... 32 4. Instalación de entornos de desarrollo y primeros desarrollos HW 34 4.1. Pruebas iniciales con Cypress y Nordic . . . . . . . . . . . . . . . . . . . . . 34 4.2. Acerca de los entornos de desarrollo . . . . . . . . . . . . . . . . . . . . . . . 37 4.2.1. ARMmbed ................................ 37 i 4.2.2. Cypress PSoC Creator . . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.3. Conclusión tras las pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5. Desarrollo Hardware 42 5.1. Comunicación con el acelerómetro por I2C . . . . . . . . . . . . . . . . . . . 42 5.1.1. Lecturadedatos ............................. 43 5.1.2. Filtrado .................................. 46 5.2. Comunicación Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 6. Aplicación Android 49 6.1. Front-End..................................... 50 6.1.1. Vistaprincipal .............................. 51 6.1.2. Configuración y Ayuda . . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.1.3. Vista resumen de sesión . . . . . . . . . . . . . . . . . . . . . . . . . 52 6.2. Funcionamiento.................................. 53 6.2.1. Conexión al dispositivo BLE . . . . . . . . . . . . . . . . . . . . . . . 53 6.2.2. GPS .................................... 54 6.2.3. Funcionamiento durante la marcha . . . . . . . . . . . . . . . . . . . 55 6.2.4. Generación de mapas tras marcha . . . . . . . . . . . . . . . . . . . . 57 7. Mediciones y calibrado 59 7.1. Medicionesdeconsumo.............................. 59 7.2. Calibrado ..................................... 61 8. Conclusiones y trabajo futuro 63 8.1. Trabajofuturo .................................. 64 Bibliography 66 A. Repositorios de código 67 A.1.CódigonRF51-DK ................................ 67 A.2.AplicaciónAndroid................................ 67 ii Índice de figuras 1.1. Esquema del funcionamiento del proyecto . . . . . . . . . . . . . . . . . . . . 5 2.1. Estructura hardware de un dispositivo BLE . . . . . . . . . . . . . . . . . . 14 2.2. División de la banda de frecuencia ISM . . . . . . . . . . . . . . . . . . . . . 15 2.3. EjemplodeescaneoBLE............................. 19 2.4. Esquema de Scan Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.5. Esquema de la estructura de datos de GATT . . . . . . . . . . . . . . . . . . 22 3.1. Esquema de la disposición de pines de la placa nRF51-DK de Nordic . . . . 31 3.2. CypressPSoC................................... 32 3.3. PSoC 4 BLE, placa de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . 33 4.1. Diagrama de pines para el conversor A/D MCP3008 . . . . . . . . . . . . . . 35 4.2. Circuito realizado para la prueba MCP3008 . . . . . . . . . . . . . . . . . . 35 4.3. Aplicación piloto para comprobar la conexión Bluetooth . . . . . . . . . . . 37 4.4. Entorno de desarrollo mbed . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.5. Entorno de desarrollo PSoC Creator . . . . . . . . . . . . . . . . . . . . . . . 39 5.1. Cableado del acelerómetro por I2C . . . . . . . . . . . . . . . . . . . . . . . 44 5.2. Registros del acelerómetro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.3. Rango de datos del acelerómetro . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.1. Diagrama de clases general de la aplicación Android . . . . . . . . . . . . . . 50 6.2. Menú deslizable de la aplicación Android . . . . . . . . . . . . . . . . . . . . 51 6.3. Vista principal de la app Android . . . . . . . . . . . . . . . . . . . . . . . . 52 6.4. Vista de configuración y de ayuda . . . . . . . . . . . . . . . . . . . . . . . . 53 6.5. Vista de resumen de sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.6. Diagrama de las clases que intervienen en una conexión BLE . . . . . . . . . 55 6.7. Diagrama de las clases que intervienen en una sesión . . . . . . . . . . . . . 56 7.1. Primera gráfica de corriente . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 7.2. Segunda gráfica de corriente . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 iii Agradecimientos A nuestras familias y amigos, que nos han estado apoyando todo este tiempo, y con los que no habría sido posible llegar hasta aquí. A nuestros tutores, que nos han motivado a seguir adelante durante este año. iv Capítulo 1 Introducción Entre los años 2008 y 2009 se comenzó a usar el concepto Internet de las cosas (abreviado IoT) como una apuesta hacia el futuro, cuyo objetivo era interconectar dispositivos digitales a internet. Esto ya es una realidad, con mayor frecuencia encontramos nuevos dispositivos capaces de conectarse a internet, permitiendo al usuario su manejo desde cualquier parte del mundo. Con ello se abre camino a nuevas oportunidades haciendo la vida más cómoda al usuario y proporcionándole mayor seguridad y control. Según empresas del sector tecnológico, en 2016 se espera que haya más de 6.000 millones de dispositivos basados en este concepto. El concepto del internet de las cosas agrupa múltiples capacidades, algunas de ellas han sido utilizadas en el proyecto, estas se nombran a continuación: Comunicación y cooperación: Dispositivos capaces de conectarse a la red de internet y entre ellos, intercambiando datos y comunicándose con servidores. Direccionamiento: Los objetos serán localizables y configurables desde cualquier lugar de la red de internet. Identificación: Los objetos se identificarán en la red por medio de tecnologías como RFID (Radio Frecuency Identification), códigos de barras ópticos, NFC (Near Field Communication) y otras muchas formas. Localización: Se podrá saber la ubicación física del dispositivo en cualquier momento. 1 una señal digital para poder enviársela a la placa de desarrollo. Participé en la creación de dicho circuito así como en las pruebas de desarrollo para realizar la conexión por SPI y recibir los datos que transmitía la fotoresistencia. Tuvimos que familiarizarnos con el entorno de desarrollo llamado mbed que utilizaba la placa de Nordic. En su repositorio11 pudimos probar ejemplos de conexiones SPI que adaptamos a la placa utilizada, mirando en su ficha técnica7la correcta conexión de sus pines. La manera de interactuar con la fotoresistencia a través de la placa fue activar los LEDs que esta contiene, alternándolos según su valor de entrada. De esta forma verificamos que el paso de datos funcionaba correctamente. La siguiente prueba de conexión fue a través de I2C, tuvimos que investigar y documentarnos bien sobre este bus de datos. Se cambió el circuito por un acelerómetro que conectamos por I2C a la placa de desarrollo. En este punto fue necesario investigar la forma de crear una aplicación en Android, de tal forma que esta pudiera conectarse por Bluetooth Low Energy a la placa nRF51DK de Nordic y visualizar los datos recibidos. Para realizar la prueba de conexión por Bluetooth encontramos en el repositorio de mbed algunos ejemplos que nos ayudaron a poder implementar el módulo BLE. Realicé una maqueta visual (mockup) de cada vista para poder tener un primer diseño de la aplicación en el que fijarnos. Participé en la creación de la aplicación en Android desarrollando la interfaz de usuario y su estructura. Estructuré la aplicación con un tipo de componente de Android llamado Fragment que se usa mucho en la actualidad y que sirve para separar las diferentes vistas para que puedan tener su propia lógica de manera independiente. Quise darle un aspecto y usabilidad propios de las nuevas aplicaciones de última generación utilizando componentes gráficos de Material design de Google9. De esta forma nuestra aplicación se beneficia de los últimos avances visuales asegurando una óptima experiencia de usuario. 8 Realicé pruebas obteniendo los datos del GPS del móvil y realizando la petición a través de un servicio interno. Utilicé la interfaz LocationListener que nos permite conectarnos con los servicios de ubicación del dispositivo móvil. Pude obtener la latitud y longitud de la ubicación en la que nos encontramos y a través de unos parámetros podemos cambiar la distancia ( metros ) que actualiza el GPS así como configurar la frecuencia de muestreo ( milisegundos ) de las coordenadas. Posteriormente se utilizó un hilo para poder recibir los datos del acelerómetro aunque la aplicación estuviera activa en segundo plano. Debíamos mostrar el circuito recorrido por un ciclista desde que se pone en marcha hasta que finaliza su recorrido. Para visualizar el mapa utilizamos la API de Google Maps1. Para poder utilizar sus funcionalidades principales tuve que registrarme en la API de Google Maps, incorporamos al proyecto una clave única que para tener acceso a las funcionalidades de su servidor. Activé los permisos necesarios para obtener el mapa de Google y sus configuraciones necesarias para ajustarlo a nuestra aplicación. Utilizando la clase polilíneas de Google pude crear las líneas sobre el mapa, se pudo visualizar con éxito en la vista Actividades. 1.4.3. Alexis Vizcaya Hervella Mi contribución al proyecto ha sido principalmente la de estructurar el código de la aplicación Android, centrándome en la parte del análisis de los datos y los cálculos realizados con ellos, así como de la lectura y escritura de los mismos. En el primer cuatrimestre iniciamos en conjunto una investigación general haciendo un análisis de los dispositivos que incorporaran la tecnología Bluetooth Low Energy (BLE) disponibles en el mercado que se ajustaran a los requisitos del proyecto, comparamos precios, características, etc. y finalmente escogimos las placas de desarrollo de Cypress (PSoC 4 BLE) y Nordic (nRF51-DK). Una vez elegidas las placas, investigué los buses de datos I2C y SPI puesto que estas eran las tecnologías disponibles en ambas para la comunicación con un acelerómetro. Además inicie el proceso de familiarización con los entornos de desarrollo. 9 En una primera etapa realice ejemplos con la placa de Cypress en su entorno de desarrollo (PSoC Creator) ya que descubrimos la existencia de un repositorio en GitHub que contenía 100 proyectos de ejemplo, probé con varios ejemplos para comprender la forma de diseñar pequeños programas en dicha placa, además disponía de una app para el teléfono móvil para poder conectar con la placa y así poder realizar estos ejemplos. Con la placa de Nordic ocurrió algo similar, con su entorno de desarrollo mbed, cuyo repositorio oficial contiene multitud de ejemplos, con los que empecé a investigar acerca del funcionamiento de esta. Como por ejemplo uno con el que empecé a establecer la conexión Bluetooth con el móvil, consistente en detectar la pulsación de un botón en la placa y mandar la información del estado de éste a una app. Una vez finalizada esta etapa de aprendizaje hicimos pruebas de conexión entre la placas y un circuito MCP mediante SPI. El circuito constaba de una fotorresistencia conectada a un ADC con la que comprobamos que al cambiar la luminosidad que recibía la resistencia los datos que obteníamos en la placa variaban. El siguiente paso fue conectar un acelerómetro mediante I2C a la placa de Nordic. Pudimos comprobar que los datos se recibían correctamente a través de los LEDs de los que disponía la placa, y una vez comprobado el correcto funcionamiento, nos dispusimos a realizar la conexión mediante BLE entre una pequeña app y la nRF51-DK. Una vez decidida la placa con la que íbamos a afrontar el proyecto, comenzamos con el diseño de la aplicación Android. Dado que nunca había programado una app para móviles, y ya que esta iba a ser para dispositivos Android, empecé un proceso de aprendizaje sobre esta plataforma y del entorno de desarrollo Android Studio. Para ello encontré ejemplos en la página oficial de Google, Android Developers, y diversos tutoriales, que me ayudaron a empezar a hacer pequeñas aplicaciones para comprender su funcionamiento. Una vez asimilados los conceptos básicos, formé parte del diseño de la estructura mediante un patrón Modelo Vista Controlador (MVC) y en el desarrollo del menú principal de la aplicación. 10 A partir de aquí me centré en la parte de lectura y escritura de la información recibida a través de Bluetooth Low Energy y el GPS del móvil, decidiendo cómo se iban a llevar a cabo estos dos procesos. Sobre la lectura desarrollé la funcionalidad por la cual se finaliza una sesión y se traslada toda la información a un vista con un mapa de Google Maps con la ruta dibujada en forma de polilínea y una serie de campos para mostrar la información procesada. Sobre la escritura, elegí la forma de guardar los datos en la memoria externa del teléfono móvil. El proceso de guardado se realiza periódicamente, recogiendo los últimos valores recibidos, tanto del GPS como del acelerómetro, escribiendo una línea nueva en el archivo con esta información. Para recoger los datos de las diferentes fuentes, programé la estructura de hilos que se utiliza en la aplicación, ya que teníamos que tener un control para asignar diferentes periodos de tiempo, debido a que por ejemplo no es necesario recopilar la información del GPS tan a menudo como la del acelerómetro. 11 Capítulo 2 Bluetooth Low Energy Bluetooth Low Energy (BLE, también denominado Bluetooth Smart) empezó como parte de la Bluetooth 4.0 Core Specification. Diseñado originalmente por Nokia bajo el nombre de Wibree, fue luego adoptado por el Bluetooth Special Interest Group (SIG).13 12 4 El objetivo de Bluetooth Low Energy es complementar al Bluetooth clásico y ser la tecnología inalámbrica con el menor consumo energético posible. También tiene como objetivo llegar a una gran cantidad de objetos que hasta ahora no disponían de ninguna conectividad inalámbrica. Para lograr abarcar tantos escenarios, se necesita tener un coste muy bajo, lo cual se consigue con tres elementos clave: Banda ISM: BLE utiliza la banda ISM (Industrial, Scientific and Medical) de 2,4GHz, que, a pesar de tener numerosos problemas como poco rango o interferencias por otras tecnologías como WiFi, etc, está disponible en todo el mundo con las mismas reglas y no tiene requisitos de licencia. Licencia: Cuando la tecnología Wibree estuvo lo suficiente madura como para unirse con un grupo de estándares inalámbricos, Nokia decidió elegir al Bluetooth Special Interest Group por su excelente reputación y su política de licencias. Esta política, comparada con la de otros grupos bajo la política Fair, Reasonable and Non-discriminatory, significa que los costes de licencia de un dispositivo Bluetooth se reducen significativamente. Con un menor coste de licencia se reduce el coste por dispositivo. 12 Bajo consumo: La mejor forma de producir un dispositivo con bajo coste es reducir el coste de sus materiales, por ejemplo las baterías. Un dispositivo BLE puede funcionar perfectamente alimentado por una simple pila de botón CR2032. 2.1. Comparación con Bluetooth Clásico Aunque comparta con Bluetooth su nombre y mucha de la tecnología utilizada, se deben considerar diferentes tecnologías, ya que tienen objetivos de diseño completamente diferentes. El Bluetooth clásico (también conocido como BR/EDR4) se diseñó para conectar diferentes dispositivos, empezando por teléfonos móviles y ordenadores, y con el tiempo añadiendo más casos de uso como auriculares inalámbricos, streaming de música, impresión inalámbrica, etc. Cada uno de estos casos requería cada vez más ancho de banda, por lo que se fueron añadiendo radios cada vez más rápidas (la primera versión transmitía a 1 Mbps, aumentando a 3 Mbps en la versión 2.0, hasta los cientos de megabits por segundo en su versión 3.0) Bluetooth Low Energy está optimizado para tener un consumo de energía muy bajo, por lo que se reduce el ancho de banda, y está pensado para aplicarse en dispositivos con un coste muy bajo, con una complejidad a su vez baja. Cada capa de su arquitectura se ha optimizado para reducir el consumo de energía al realizar una determinada tarea. Por ejemplo, relajando los parámetros de la radio usada por la capa física, comparándola con la radio del Bluetooth clásico, se puede usar menos energía cuando se está transmitiendo o recibiendo datos. Precisamente por tener estos objetivos tan diferentes, Bluetooth clásico y BLE pueden coexistir en la misma aplicación en lo que se denomina Modo Dual (en inglés Dual-Mode), de modo que se puede conectar por ejemplo a unos auriculares inalámbricos por medio de BR/EDR mientras se accede a un dispositivo de bajo consumo, como un wearable, por BLE. 13 2.2. Tecnología Un dispositivo BLE se divide en tres partes: controlador, anfitrión y aplicación. Cada una de estas partes se divide a su vez en distintas capas que proveen la funcionalidad necesaria para operar. En la Figura 2.1 se muestra un esquema de esta estructura. Figura 2.1:Estructura hardware de un dispositivo BLE 2.2.1. Controlador Capa Física (Physical Layer, PHY). La capa física es la que contiene los circuitos capaces de comunicarse de forma analógica, modulando y demodulando las señales analógicas y transformándolas en digitales. Como ya se ha mencionado, la radio usada para BLE utiliza la banda ISM de 2,4 GHz. Esta banda se divide en 40 canales, desde los 2,4000 GHz 14 hasta los 2,4835 GHz. De estos canales, 37 se utilizan para el envío de datos y los 3 restantes como canales de anuncio, para iniciar conexiones y mandar datos de broadcast. Figura 2.2:División de la banda de frecuencia ISM en 40 canales Para evitar interferencias con otros dispositivos transmitiendo en la misma banda, mayormente WiFi y Bluetooth clásico, el estándar BLE utiliza una técnica llamada frequency hopping spread spectrum, que hace que la radio “salte” entre los distintos canales en cada conexión. Capa de Enlace (Link Layer). Es la parte que actúa de interfaz de la capa física. Normalmente se implementa como una mezcla de software y hardware personalizado. Es responsable de anunciar, escanear, crear y mantener las conexiones. También se encarga de asegurar que los paquetes están correctamente estructurados. Por ello es probablemente la capa más compleja de la arquitectura BLE. Interfaz Anfitrión/Controlador (Host/Controller Interface, HCI). Muchos dispositivos separan el Anfitrión del Controlador, y para estos casos, el HCI provee una interfaz estandarizada para comunicar los dos dependiendo del método de transporte físico de los datos. Entre estas interfaces se incluyen USB, SDIO o variantes de UART. 2.2.2. Anfitrión Control Lógico de Enlace y Protocolo de Adaptación (Logical Link Control and Adaptation Protocol, L2CAP). Esta capa provee dos funcionalidades: actúa como 15 capa multiplexora de los protocolos, es decir, recibe los protocolos de las capas superiores y los encapsula en el formato de paquete estándar BLE (y viceversa). Asimismo, fragmenta los paquetes que se le envían desde las capas superiores para que quepan en los 27 bytes que tienen como máximo los paquetes de transmisión y vuelve a combinar los paquetes fragmentados que recibe. Protocolo de Atributos (Attribute Protocol, ATT). Define una serie de reglas para acceder a los datos de un dispositivo. Propone una manera de encapsular estos datos en forma de atributos, que permiten identificarlos asignando a cada uno un handle de 16 bits y un Identificador Único Universal (Universal Unique Identifier, UUID) y restringir su acceso mediante una serie de permisos. Los campos que forman un atributo se explicarán más adelante en la Sección 2.4.2. En resumen, ATT un protocolo muy simple, en el que un cliente puede acceder a los atributos de un servidor. Para definir la comunicación eficaz de estos atributos entre el cliente y el servidor, ATT define seis tipos de mensajes: Solicitudes enviadas desde el cliente al servidor. Respuestas del servidor a una solicitud del cliente. Comandos enviados del cliente al servidor que no necesitan respuesta. Notificaciones enviadas desde el servidor al cliente que no necesitan confirmación. Indicaciones enviadas desde el servidor al cliente. Confirmaciones enviadas por el cliente en respuesta a una indicación. De este modo ambos pueden establecer una comunicación con mensajes que requieran o no respuesta. Perfil de Atributo Genérico (Generic Attribute Profile, GATT). Este perfil se asienta en el Protocolo de Atributos, y define los tipos de atributos y cómo se utilizan. Para 16 ello utiliza una jerarquía de capas y un modelo de abstracción de datos. Los datos ahora se encapsulan en servicios, que a su vez consisten en una o más características que pueden estar definidas por un descriptor. Estas capas se sirven de metadatos para dar más información sobre los datos que se están manejando, como nombres, unidades, etc. Este perfil es importante a la hora de comunicar dispositivos por BLE, y se usa como base para generar perfiles específicos para determinados casos de uso, como la medición del ritmo cardíaco de una persona o el acceso al nivel de batería disponible de un dispositivo. En la Sección 2.4 se detallarán los componentes de un perfil GATT. Perfil de Acceso Genérico (Generic Access Profile, GAP). Define cómo los dispositivos realizan procedimientos de control como el descubrimiento de otros dispositivos, conexiones entre éstos o la seguridad, es decir, dicta cómo interactúan dos dispositivos en un nivel más bajo. GAP establece diferentes normas y conceptos para regular y estandarizar las operaciones a bajo nivel de los dispositivos: Roles en los que los dispositivos pueden operar, estableciendo restricciones e imponiendo determinados comportamientos. Se explican con más detalle en las secciones 2.3.1 y2.3.2. Modos operacionales, que establecen estados a los que un dispositivo puede cambiar durante un determinado periodo de tiempo para lograr un objetivo, como por ejemplo permitir su descubrimiento o de qué modo permite realizar la conexión. Procedimientos operacionales para asegurar una comunicación constante mediante una secuencia de acciones. Aspectos de la seguridad, incluyendo modos y procedimientos. Formatos de datos adicionales para datos no protocolarios. Gestor de Seguridad (Security Manager, SM). Define los protocolos y sus modos de operar para gestionar la integridad de los enlaces, la autenticación y el cifrado entre 17 inválido, por lo que el rango de handles disponible es de 0xFFFF (65535), aunque en la práctica el número de atributos en un servidor es más cercano a la docena. Tipo. Esta parte consiste en un UUID de 16, 32 o 128 bits que determina qué tipo de datos están presentes en el campo de valor del atributo, permitiendo por ejemplo mecanismos para encontrar un atributo directamente por su tipo. En la Sección 2.4.3 se muestra cómo se forman los UUIDs para su uso en BLE. Permisos. Los permisos son metadatos que especifican qué operaciones se pueden ejecutar en cada atributo y con qué requisitos de seguridad. ATT y GATT definen los siguientes permisos: •Permisos de acceso: similares a los permisos presentes en un archivo. Define si se puede acceder a un valor como sólo de lectura, de escritura, de ambos o de ninguno. •Encriptación: determina si es necesario algún nivel de encriptación para acceder al valor. Puede no necesitarla, o exigir una encriptación con o sin autenticación. •Autorización: determina si se necesita o no permiso del usuario para acceder al atributo. Valor. Contiene los propios datos sin restricción de qué tipo sean, aunque con un máximo de 512 bytes según la especificación. Dependiendo del tipo de atributo, puede contener información adicional sobre el atributo o un valor útil. Servicio. Los servicios agrupan atributos conceptualmente relacionados. La forma de definir un servicio es a través de uno o más atributos denominados definición de servicio, de los cuales el primero es el que actúa de declaración de servicio y el resto pueden definir las siguientes capas, como características y descriptores. Se puede comparar un servicio con una clase en cualquier lenguaje de programación orientado a objetos. 24 Característica. Las características se pueden entender como contenedores para los datos del usuario. Siempre incluyen dos atributos: la declaración de la característica, que ofrece metadatos sobre los datos en sí, y el valor de la característica, que es un atributo completo con los datos del usuario. Adicionalmente, una característica puede contener un descriptor, que es un atributo que provee de más metadatos. Descriptor. Se utilizan principalmente para proveer al cliente con información adicional sobre las características y su valor. Se ubican siempre entre la definición de la característica y el valor del atributo de la característica y están compuestos por un único atributo cuyo UUID define el tipo de descriptor y el campo de valor contiene lo que esté definido para ese tipo de descriptor. A continuación se detallan algunos de los descriptores más utilizados: Descriptor de usuario de una característica: contiene una descripción que el usuario puede leer consistente en una cadena de caracteres en UTF-8. Por ejemplo “Temperatura en el salón”. Descriptor de configuración de la característica por el cliente: actúa como un “interruptor”, deshabilitando las actualizaciones que envía el servidor. Descriptor de formato de presentación de una característica: contiene el tipo de variable de la característica, por ejemplo booleano, cadena de caracteres, enteros, etc. 2.4.3. UUIDs Un Identificador Único Universal (UUID) es un número de 128 bits (16 bytes) que garantiza (al menos con una gran probabilidad) que es único globalmente. UUID es usado en otros protocolos aparte de Bluetooth, y su formato, uso y generación se especifican en el ISO/IEC 9834-8:2005. Dado que 16 bytes ocuparía gran parte del tamaño disponible en los 27 bytes de los paquetes de datos, la especificación BLE añade dos formatos adicionales: UUIDs de 16 o 32 25 bits, y se forman definiendo un “final” del UUID que es constante en todos los dispositivos BLE, en los que se sustituyen los 32 primeros bits: xxxxxxxx-0000-1000-8000-00805F9B34FB donde xxxxxxxx son los bits a sustituir. 26 Capítulo 3 Exploración Hardware El primer hito a nivel técnico era encontrar una placa de desarrollo que incluyera Bluetooth de bajo consumo y permitiera conectar un sensor de acelerometría, ya que eran indispensables para la transmisión de datos entre la placa y el dispositivo móvil. Desde el punto de vista comercial, la intención ha sido buscar el componente con mejores prestaciones en calidad y precio con el objetivo de preparar un producto final que pudiera competir con otras opciones del mercado. Destacamos las placas con Bluetooth incorporado y un microprocesador. En la tabla 3.1 observamos el análisis de cada elemento que se ha considerado. Dada la naturaleza de nuestro proyecto no necesitábamos un gran poder de procesamiento ni una gran capacidad en cuanto a memoria RAM y flash, ya que el código iba a ser muy sencillo. Los dos factores principales a tener en cuenta eran que incorporase la tecnología Bluetooth Low Energy y que permitiese la conexión y el envío de datos con el acelerómetro, ya fuera mediante I2C, SPI, UART... CHIPS CON BLUETOOTH EMPRESA MODELO PROCESADOR FLASH RAM I/O Nordic PTR9022 ARM Cortex-M0 256 KB 16 KB SPI, 2-WIRE, UART Nordic nRF51-DK ARM Cortex-M0 256/128KB 32KB/16KB SPI Master/Slave, 2-wire, UART, 31 GPIO Nordic nRF51422 ARM Cortex-M0 256/128KB 16KB SPI Master/Slave, 2-wire, UART, 31 GPIO TI CC2540 / CC2541 8051 128/256KB 8KB 2 USART, ADC, 21 GPIO, SPI TI CC2640F128RGZT ARM Cortex-M3 128KB 20KB I2C, I2S, SPI, UART Cypress 4 BLE/PRoC BLE ARM Cortex-M0 128/256KB 16/32KB 2 SCBs, configurable como I2C, SPI o UART Cypress PSoC 4XX7-BLE ARM Cortex-M0 128KB 16KB I2C, SPI, UART, 36 GPIO Cuadro 3.1:Placas que integran radio Bluetooth Low Energy. Se destacan las alternativas seleccionadas para la siguiente fase de exploración 27 Realizando el primer filtro pudimos observar que algunas características eran comunes entre los SoC’s elegidos: En materia de procesadores encontramos dos opciones comunes: Cortex-M0 de ARM (Advanced RISC Machines) y 8051 de Intel. Al ver que la mayoría de los chip elegidos montaban el procesador de ARM, claramente observamos que domina el mercado de los sistemas empotrados y las empresas han optado por utilizarlo. Esto se debe a que el modelo de negocio utilizado por ARM consiste en la venta de licencias de sus núcleos3, lo que permite a otros fabricantes diseñar su propio System On Chip (SoC) integrando tecnología ARM. ARM Cortex-M0 nos parecía una opción más interesante, ya que este procesador tipo RISC, cuenta tanto con una arquitectura de 32 bits (frente a los 16 de Intel 8051) como con la arquitectura Thumb, que mejora la densidad del código para ocupar menos espacio tanto en memoria RAM como en flash. La cantidad de memoria RAM disponible más común para este tipo de dispositivos es de 8, 16 o 32 kilobytes. La segunda opción nos pareció más que suficiente para albergar un programa sencillo como el nuestro y las variables necesarias. En cuanto a capacidad de almacenamiento, todas las placas cuentan con memoria flash, que pueden variar entre 128 y 256 Kilobytes. De nuevo, la complejidad de nuestro programa no iba a generar un fichero compilado de gran tamaño, y no necesitábamos guardar nada más, por lo que 128 KB nos parecieron adecuados. En cuanto a los periféricos de entrada/salida, la mayoría de las placas de desarrollo incluyen los protocolos SPI e I2C. El protocolo SPI consiste en el envío de la señal de reloj del maestro y en cada impulso de reloj se envía un bit al esclavo y recibe un bit de éste. Los nombres de las señales son SCK para el reloj, MOSI para el Maestro Out Esclavo In, y MISO para Maestro In Esclavo Out. El protocolo I2C, usa dos cables, uno para el reloj (SCL) y otro para el dato (SDA). El 28 maestro y esclavo envían datos por el mismo cable, el cual es controlado por el maestro, que crea la señal de reloj. Este protocolo utiliza direccionamiento, es decir, el primer byte enviado por el maestro se forma de 7 bits para la dirección (así que permite comunicarse con hasta 127 dispositivos) y un bit de lectura/escritura, indicando si el próximo byte vendrá desde el maestro o el esclavo. Esta tecnología se ampliará en el Capítulo 5.1.1. 3.1. Selección de plataformas de desarrollo Una vez recopilados los modelos de que observamos en la Tabla 3.1, hemos destacado 2 placas de prototipado que cumplen con los requisitos del proyecto. Este tipo de placas ofrecen más características de las que necesitamos para el proyecto, pero suponen un primer paso para poder programar y realizar pruebas antes de pasar a chips más simples y con un menor coste. Por un lado escogimos la placa de desarrollo de Cypress con el kit PSoC BLE y modelo de la placa con Bluetooth CY8CKIT-042-BLE certificado para sistemas de bajo consumo. Es un kit provisto de un chip que ofrece un procesador ARM Cortex-M0 y capacidad y conectividad suficiente como para utilizarlo de base para el proyecto. El entorno de desarrollo para las plataformas de Cypress es un software de escritorio llamado PSoC Creator, en el cual podemos diseñar sistemas a través de un panel gráfico. Nos ofrece multitud de librerías disponibles para la placa utilizada y es posible codificar, compilar, y depurar código. Consideramos también la placa de Nordic modelo nRF51-DK por ser un kit de desarrollo que ofrece el mismo procesador que Cypress, conectividad tanto I2C como SPI para realizar las pruebas con el sensor. Este modelo ofrece compatibilidad con la plataforma de desarrollo mbed de ARM, es una opción que nos resultó interesante a la hora escogerla. Dispone de una gran comunidad y soporte lo cual es de agradecer. 29 En la Sección 3.1.1 hablaremos más sobre los aspectos específicos de ambos entornos de desarrollo. Al considerar que era más interesante tener una placa con procesador, sensores y periféricos descartamos los chips individuales y optamos por una opción más completa. 3.1.1. Análisis de las plataformas escogidas Rápidamente observamos dos grandes empresas especializadas en el sector como son Nordic y Cypress. Tienen gran variedad de microprocesadores y placas de desarrollo que cumplen con nuestras expectativas. Elegimos el kit de desarrollo de Nordic (nRF51-DK), que incluye Bluetooth Smart e incorpora un núcleo ARM Cortex-M0 32-bit como la mayoría de los chips que encontramos. Una memoria flash a 256/128KB con RAM de 32KB/16KB para mejorar el rendimiento de las aplicaciones. El kit permite el acceso a todas las interfaces de entrada y salida como SPI Master/Slave, 2-wire, UART y 31 GPIOs a través de conectores. Tiene 4 LED’s y ofrece también 4 botones que son programables por el usuario. Utiliza un cable micro USB 2.0 para conectarse a uno de los puertos USB de el PC. Esto proporciona alimentación a la placa, y es compatible con la programación de destino. La carga de programas resulta sencilla, ya que una vez conectado al ordenador, el sistema de archivos se monta como una unidad extraíble, por lo que solo debemos abrir un explorador de archivos y podremos cargar los programas a la placa arrastrando y soltando hacia la unidad. La placa de desarrollo nRF51-DK es compatible con el entorno ARM mbed, que es una plataforma gratuita de prototipado rápido y experimentación con microcontroladores ARM. Provee a los desarrolladores una plataforma para realizar pruebas y prototipos en el lenguaje de programación C++. Incluye una amplia variedad de librerías, tutoriales y ejemplos, además de contar de una gran comunidad online de desarrolladores de software, 30 Figura 3.1:Esquema de la disposición de pines de la placa nRF51-DK de Nordic cuyos códigos son habitualmente accesibles a toda la comunidad. Otro chip con procesador que nos pareció interesante fue el modelo CY8CKIT-042BLE de la empresa Cypress Semiconductor que soporta 2 dispositivos: PSoC 4 BLE y PRoC BLE. El modelo escogido es el PSoC 4 BLE que provee de una completa solución para conectividad Bluetooth Low Energy. También monta una procesador ARM Cortex-M0 con una memoria flash de 128kB/ 256kB y RAM de 16kB / 32kB. Dispone de 4 TCPWM1, 2 SCBs2, LCD4, I2S5, y 36 GPIOs. El kit incluye una memoria extraible que conecta la placa por Bluetooth llamado Dongle USB CySmart (BLE Dongle) que se empareja con la herramienta de emulación principal CySmart. El emparejamiento con un entorno Windows hace que sea un potente entorno de 31 Figura 3.2:Cypress PSoC. Esta placa contiene el microchip y todos los conectores necesarios como para usarla directamente como producto final depuración de Bluetooth LE. Este kit de desarrollo de Cypress es compatible con diseños a nivel de sistema mediante PSoC Creator, un software de desarrollo que contiene numerosos proyectos de ejemplo para proporcionar diseños integrados de señal mixta Bluetooth de baja energía, el lenguaje utilizado es C. Es sencilla diseñar pues con arrastrar y soltar los componentes se añaden al panel principal obteniendo máxima flexibilidad de diseño. 3.2. Conclusión Tanto la placa nRF51-DK de Nordic como CY8CKIT-042-BLE de Cypress son dos placas de desarrollo perfectas para iniciar un proyecto con conectividad Bluetooth, las dos tienen idénticas características, conectores y periféricos, se les puede incluir una pila de botón CR2032 para darles autonomía y les respalda un software para desarrollo de las mismas. En este punto tuvimos cierta controversia, ya que el software de Mbed de Nordic nos da la posibilidad de compilar código C++ en cualquier PC con internet gracias a su versión web. Nos ofrece una gran comunidad que es de agradecer y mucho contenido de ejemplos y 32 Figura 3.3:PSoC 4 BLE, placa de desarrollo, en esta placa se conecta el PSoC para poder programarlo, y añade más funcionalidad incorporando elementos como botones programables, un LED RGB, un panel deslizante, etc. tutoriales en la web oficial. Por contra no tiene modo depuración por pasos y eso dificulta su seguimiento y depuración. Por otro lado, PSoC Creator de Cypress nos ofrece un completo programa de escritorio muy visual al diseñar circuitos y un sistema “drag and drop” muy intuitivo. Permite modo depuración facilitando su programación. Por contra nos hemos encontrado con ciertas dudas que han sido difíciles de resolver en foros debido al poco contenido sobre el tema. Debido al gran parecido entre las características de una placa y otra, y a que los entornos de desarrollo tienen cada uno sus pros y sus contras, nos resultó difícil elegir una de las dos para finalizar el proyecto. En el Capítulo 4se hablará de las pruebas que realizamos con ambas y qué nos motivó a escoger la placa de Nordic frente a la de Cypress. 33 arrastrarla hasta la vista de diseño, y elegir la opción Generar Aplicación para generar el código necesario para interactuar con BLE, creando un archivo de encabezado BLE.h y uno de código BLE.c. Cypress también pone a disposición del desarrollador tutoriales en vídeo y una serie de ejemplos de código denominada 100 projects in 100 days 5, subida a un repositorio en GitHub, de las que pudimos tomar ejemplo para avanzar con las pruebas. Sin embargo, la comunidad de desarrolladores era más pequeña que la de mbed, probablemente por ser esta plataforma específica para productos de Cypress, mientras que en el ecosistema de mbed se encuentran multitud de fabricantes. A diferencia de mbed, PSoC Creator sí ofrece herramientas de debug, con puntos de ruptura y visualización del estado de las variables. 4.3. Conclusión tras las pruebas Tras realizar las pruebas definidas en la Sección 4.1, aprendimos a desarrollar rápidamente códigos para lograr la funcionalidad deseada. Los ejemplos de uso de Bluetooth Low Energy nos ayudaron a comprender los pasos que se debían dar para establecer correctamente una conexión, aunque tuvimos que informarnos más para comprender qué era exactamente lo que sucedía en cada paso. Una vez entendimos el procedimiento para conectar por SPI el circuito mencionado anteriormente y la lógica que había que seguir para programar la interacción tanto con la placa de Cypress como la de Nordic, realizar la transición a I2C para conectar el acelerómetro fue un paso sencillo, pues las API de ambas placas gestiona de manera similar los dos protocolos. Como ya mencionamos en el Capítulo 3, la decisión de continuar la fase final del proyecto con una placa u otra fue difícil, pues ambas tienen características similares y sus entornos de desarrollo tienen sus pros y sus contras, pero finalmente escogimos la placa de desarrollo 40 nRF51-DK de Nordic por la facilidad de encontrar información y ayuda en los foros de la comunidad. Los ejemplos ofrecidos en el repositorio propio de mbed fueron de gran ayuda para consolidar el aprendizaje con dicha placa y la propia herramienta nos pareció una gran apuesta para dispositivos IoT. Cabe destacar que la opción de Cypress podría haber sido viable perfectamente. 41 Capítulo 5 Desarrollo Hardware Una vez terminado el período de pruebas, ya con el kit de desarrollo nRF51-DK de Nordic como opción principal y con la placa XTRINSIC-SENSE-BOARD de Element 14, que incorpora el acelerómetro MMA84910 de 3 ejes, pudimos comenzar a desarrollar la parte hardware de este proyecto. El desarrollo se centró en dos elementos: la comunicación por I2C entre la placa de desarrollo y el acelerómetro y el envío de datos mediante Bluetooth Low Energy desde la placa hacia un dispositivo móvil. A continuación se describirán los pasos realizados. 5.1. Comunicación con el acelerómetro por I2C El modelo nRF51-DK utiliza GPIO (General Purpose Input/Output), que son unos pines genéricos que pueden programarse como entrada o salida. Dos de estos pines se pueden configurar como un bus I2C, que se usa para comunicarse con una gran variedad de dispositivos externos, en este caso la placa XTRINSIC-SENSE-BOARD. I2C es un bus de datos con conexión serie síncrona unidireccional (half-duplex) que se puede dar de 2 tipos: Maestro/Esclavo Esclavo/Maestro 42 Maestro. Inicia la transferencia generando las condiciones de inicio y parada de la señal de reloj. Transmite la dirección del esclavo y determina el sentido de la transferencia (lectura-escritura). La comunicación siempre la inicia el Master y el esclavo espera órdenes. Esclavo. Este responde sólo cuando se dirigen a él. La temporización se controla mediante la línea de reloj del bus. La transmisión de información se hace a través de 2 cables, uno para transmitir los datos (SDA) y otro para transmitir la señad del reloj (SCL). Otro cable para activar el acelerómetro (ENABLE) y otros 2 cables de toma de tierra (GND) y corriente (VDD) con este cablado tenemos conectado el sensor con la placa de desarrollo. 5.1.1. Lectura de datos El acelerómetro MMA8491Q tiene 7 registros donde se guardan los datos de acelerometría que han sido recogidos en la lectura. El primer registro es un registro de estado en el que se indica si alguno de los ejes ha cambiado desde la última muestra, los 6 registros siguientes dividen cada eje en los 8 bits más significativos y los 6 menos significativos, haciendo un total de 14 bits por eje. En la tabla que se muestra en la Figura 5.2 se puede observar la información de los 7 registros. Estos 14 bits se utilizan para especificar los valores de cada eje en un rango de +8000 mg a -8000 mg. Para ello utilizan el formato de la tabla que se puede ver en la Figura 5.3 sacada del datasheet6. Se puede observar que se utiliza un Complemento a 2 para definir los números negativos. La forma de parsearlos se explicará más adelante. El acelerómetro establece una serie de pasos para poder establecer la comunicación por I2C en el modo Multiple Byte Read, que apunta al siguiente registro una vez concluida la lectura del anterior: Se manda el comando Start condition con la dirección 0x55 y 1 bit de lectura-escritura 43 Figura 5.1:Cableado del acelerómetro por I2C a 0 para indicar escritura, el esclavo responde con una trama ACK. Se transmite la dirección del registro que se quiere leer y el esclavo manda una trama ACK. Se transmite el comando Repeated Start Condition con la dirección del acelerómetro, y esta vez el bit de lectura-escritura a 1 indicando lectura. El esclavo manda una trama ACK y transmite los datos del registro indicado. Por último, se transmite una trama ACK y una señal de stop para finalizar. Una vez recibidos estos datos en la placa de Nordic, se juntan y se parsean siguiendo la siguiente fórmula: 44 Figura 5.2:Tabla con los registros del acelerómetro6 Figura 5.3:Rango de datos del acelerómetro6 WORD = (MSB << 6) | (LSB >> 2 ); i f (WORD >= 0x2000 ) WORD −= 0x4000 ; NATURAL = (1000 ∗WORD + 512) >> 10; Donde MSB es el byte con los bits más signigicativos, LSB es el byte con los bits menos significativos, y WORD y NATURAL son variables enteras. El resultado, de 14 bits, se guarda en una variable de 16, que luego se dividirá en 2 bytes separados para poder enviarlos 45 mediante Bluetooth. Paso por paso, lo que hacemos es: Concatenamos los dos grupos de bits leidos por separado del bus. Cambiamos el signo si es negativo, almacenandolo como un numero negativo de 16bits. Cambiamos la escala de -8192 / 8191 a -8000 / 8000 5.1.2. Filtrado En un entorno ideal, los datos que recoja el acelerómetro en un período en el que se encuentre estático deberían ser únicamente el valor de la gravedad (1g) repartido entre los 3 ejes, ya que es una aceleración constante que experimenta cualquier objeto en este planeta. Lejos de ese caso, la información que recibimos varía ligeramente, normalmente en una escala de unos pocos mg. Para eliminar este ruido realizamos un filtrado consistente en recoger una muestra de 10 valores e insertarlos en un Búfer circular para poder filtrarlos a través de una media ponderada. El dar pesos a los datos permite que los últimos valores no se pierdan y que la media se actualice lo suficientemente rápido en caso de cambios bruscos. 5.2. Comunicación Bluetooth Como mencionábamos en el Capítulo 2, hemos elegido el Modo de Conexión para realizar el enlace y el intercambio de datos entre la placa de Nordic y el dispositivo móvil. En este caso tendremos los roles GAP y GATT (Explicados en las Secciones 2.3.2 y2.4.1, respectivamente) que se muestran en la Tabla 5.1. El dispositivo móvil actúa como Central, ya que realiza el escaneo y la conexión, y como Cliente porque es el que envía las peticiones para recibir la información. La placa nRF51-DK actúa como Periférico, pues manda paquetes de anuncio y acepta las conexiones entrantes, y como Servidor, al ser el que guarda la información y responde a las peticiones. 46 GAP GATT Dispositivo Móvil Central Cliente Placa nRF51-DK Periférico Servidor Cuadro 5.1:Roles GAP y GATT del dispositivo móvil y de la placa nRF51-DK Empezamos configurando el Perfil de Acceso Genérico (GAP) para establecer la información que incluyen los paquetes de anuncio: El dispositivo es sólo BLE y no utiliza Bluetooth clásico. Se le permite a otros dispositivos su descubrimiento. La lista de servicios que contiene, en la que aparecerá el servicio mencionado anteriormente. El nombre del dispositivo, dado por una cadena de caracteres. El método de conexión. Toda esta información estará disponible para cualquier dispositivo que se encuentre escaneando. Seguidamente configuramos el Perfil de Atributo Genérico (GATT). Definimos el dispositivo como servidor GATT y, para encapsular los datos del acelerómetro, creamos un servicio con UUID 0xA000, al que le asignaremos una característica con UUID 0xA001. Esto se hace mediante las clases GattService yGattCharacteristic que nos ofrece la API de mbed. Estas clases permiten establecer los siguientes parámetros: Característica. Le podemos definir un tamaño máximo y mínimo de los datos que van a contener, en nuestro caso siempre va a tener 6 bytes (3 ejes divididos en 2 bytes cada uno). También especificamos aquí que este valor es de sólo lectura. Servicio. Le asignamos una lista en la que únicamente aparecerá nuestra característica. 47 Como se ha explicado en la Sección 5.1.1, los datos extraídos del acelerómetro se guardan en la nRF51-DK en tres variables de 16 bits, aunque la API BLE de mbed obliga a actualizar el valor de una característica utilizando un array de variables de 8 bits, por lo que necesitamos dividir los 16 bits de cada eje en dos bytes separados. Esto hace que el dispositivo móvil reciba la información también de este modo, por lo que se tienen que juntar de nuevo al recibirlos. 48 Capítulo 6 Aplicación Android La parte del servidor Bluetooth se ha implementado sobre la plataforma Android. La principal razón por la que optamos por esta plataforma es la de que para programar una aplicación en iOS es necesario disponer de un ordenador Macintosh, condición que no cumplíamos, y debido a que de los tres componentes del grupo, dos teníamos disponible un dispositivo Android, nos pareció un paso lógico. Hay numerosos frameworks disponibles para programar aplicaciones Android, pero nos decantamos por la herramienta que ofrece Google, Android Studio, que al estar basado en la plataforma Eclipse nos resultó familiar, a la vez que proveía muchas funcionalidades específicas para Android. Una aplicación Android se implementa en Java para especificar la funcionalidad y en XML para estructurar la parte gráfica. Aunque tuvimos que familiarizarnos con el modo de gestionar las vistas en Android, el hecho de basar la funcionalidad en Java nos ha facilitado desarrollar rápidamente aplicaciones sencillas para probar funcionalidades y, eventualmente, la aplicación final. Hemos basado el diseño en el patrón Modelo-Vista-Controlador, comunicando la vista y la funcionalidad mediante comandos. En la siguiente imagen se muestra un diagrama de clases para ver cómo hemos estructurado el código de la app. 49 Figura 6.7:Diagrama de las clases que intervienen en una sesión UUID 0xA001, que es la que nos interesa para obtener la información del acelerómetro. Para descubrir este servicio, se puede realizar lo que se llama escaneo de servicios, que devuelve una lista de los servicios del dispositivo, pero como ya conocemos de antemano el UUID, podemos acceder a él directamente. Para recoger la información del acelerómetro, se accede la característica mencionada a través de su identificador, lo que devuelve una clase de Android llamada BluetoothGattCha56 racteristic, que podemos usar para leer el valor del GATT. CoordenadasThread accede periódicamente a la última localización guardada en LocationManager, como se explicaba en la sección anterior. FileThread se encarga de lanzar los dos hilos de BluetoothThread y CoordenadasThread y, periódicamente, recoge los datos obtenidos por ambos. Estos son guardados mediante una clase llamada FileManager que es la encargada del manejo de archivos. El formato del archivo que se crea consiste en una línea por cada muestreo dividida de la siguiente manera: (latitud);(longitud);(coordenadaX);(coordenadaY);(coordenadaZ) con una última línea indicando el tiempo total de la sesión de la siguiente manera: T(tiempo en milisegundos) Este archivo se guarda en una carpeta en el almacenamiento externo del móvil llamada accelbike; si no existe dicha carpeta, la clase se encarga de crearla. Para detener la sesión aprovechamos una característica de los hilos en Java que nos permite diferenciarlos de manera única a través de un nombre dado por una cadena de caracteres. De este modo podemos detener un determinado hilo a través de este nombre, por lo que basta con finalizarlos para que se termine la sesión. 6.2.4. Generación de mapas tras marcha Una vez hemos terminado una sesión, o bien hemos cargado una sesión anterior desde la vista de actividades, volvemos a llamar a la clase FileManager, esta vez para cargar el archivo. Se parsea el archivo y se agrupan las localizaciones de dos en dos calculando la distancia entre ellas y creando una polilínea a la que se le da color con los datos del acelerómetro. Cada polilínea se guarda en un array, que junto el tiempo y la distancia se inserta en una clase que actúa como Transfer. Este transfer se devuelve a la vista MapFragment, que se 57 encarga de mostrar los datos de velocidad media, distancia y tiempo y utilizar el array de polilíneas para pintar la ruta en un mapa de Google Maps. 58 Capítulo 7 Mediciones y calibrado 7.1. Mediciones de consumo El objetivo principal de Bluetooth Low Energy es incorporarse a dispositivos de bajo consumo, y ser lo más eficiente posible energéticamente. Por ello decidimos comprobar la eficiencia de consumo de energía de nuestra placa, conectándola a un osciloscopio y recogiendo los datos del amperaje durante la ejecución del programa, en el que se recogen los datos del acelerómetro, se envían por BLE y se entra en un estado de espera. La gráfica resultante se muestra en la Figura 7.1. Se puede comprobar que no tiene un consumo muy elevado, con un máximo algo menor que 9.5 mA, que es cuando realiza la comunicación por BLE y un mínimo de cerca de 5 mA en los períodos inactivos. En los períodos de inactividad observamos que consume más de lo cabría esperar. Esto es debido a que pensábamos erróneamente que la función que utilizábamos para realizar la espera pondría al procesador en modo deep sleep, que permitiría disminuir todo lo posible el uso de energía. Buscando en la API de mbed, encontramos la forma de entrar en este modo, que se realiza con la función sleep( ms )2. Esta función ejecuta lo que se denomina un Wait for Interrupt, que es una instrucción del repertorio de instrucciones de ARM que deja al procesador en modo de bajo consumo, parando todas las funcionalidades para ahorrar energía hasta que llegue una interrupción. La función sleep que implementa la API de mbed determina 59 Figura 7.1:Primera gráfica de corriente. Durante esta prueba el tiempo de espera estaba establecido en 0.1 s dinámicamente en qué modo de bajo consumo se entrará. El punto negativo de esto es que no hace discriminación entre los tipos de interrupción, por lo que puede salir del modo sleep aunque no se lo hayamos indicado. Para evitar esto utilizamos un callback que se ejecutará cada segundo, activando una variable booleana. Esta variable controla un bucle en el que, si sale del modo sleep y no es por nuestra interrupción, vuelve a ejecutar un sleep. Una vez implementada esta funcionalidad, volvimos a realizar la prueba de consumo y esta vez obtuvimos resultados más satisfactorios, como se puede apreciar en la Figura 7.2. Como se puede ver, el consumo ha disminuido notablemente después de utilizar la función comentada, con mínimos en torno a 1.25 mA en los períodos de sleep. En estas pruebas observamos la existencia de unos picos de consumo cada 50 ms, que no se aprecian en la imagen ya que la recogida de datos se daba cada segundo. Estos picos se dan durante el período de bajo consumo, y sabemos que son debidos a la componente BLE 60 Figura 7.2:Segunda gráfica de corriente. Cada segundo vemos un pico, que es cuando se despierta del sleep puesto que realizamos pruebas con este módulo desactivado y no se presentaban, aunque no sabemos exactamente por qué se producen. 7.2. Calibrado Para conocer qué rangos de los datos de acelerometría podían ser interesantes para representarlos en la ruta, realizamos una serie de pruebas para obtener valores reales y luego los analizamos para sacar conclusiones. Pronto nos dimos cuenta de que dependiendo de la posición en la que se encuentre nuestro dispositivo, los resultados pueden variar en gran medida. Por lo que sería necesario un proceso de calibración antes de empezar la marcha. Para nuestro proyecto, nos hemos centrado en el eje x para determinar la aceleración en cada momento. Decidimos establecer una serie de umbrales para colorear la ruta en el mapa generado, de modo que si detectamos un valor negativo, es decir, una deceleración, usamos el color azul. Si estamos en un valor cercano a 0, usamos el verde. En cuanto aceleramos ligeramente (hasta los 100 mg), usamos el amarillo, y a partir de ahí cuando se acelera aún mas usamos el rojo. Debido a la presencia constante de la aceleración de la gravedad en cualquier objeto, 61 el acelerómetro recoge siempre este valor, repartido entre los ejes (x, y, z). En llano, la aceleración o deceleración se produce sólo en el eje x, pero cuando nos hallamos en una pendiente este valor se reparte entre los ejes (x, z), por lo que parte de la aceleración se juntará con el valor de la gravedad. 62 Capítulo 8 Conclusiones y trabajo futuro Este proyecto nos ha permitido explorar tecnologías hardware con las que no habíamos trabajado nunca, como Bluetooth Low Energy y protocolos como SPI o I2C, lo que nos ha dado unas competencias en otros campos que no son específicamente los nuestros. Hemos aprendido a programar una placa desde cero, investigando la documentación que pone a nuestra disposición el fabricante y encontrando ejemplos para lograr los objetivos propuestos. En el campo del desarrollo software, hemos trabajado por primera vez en el desarrollo de una aplicación Android, familiarizándonos con el entorno de programación Android Studio. La línea de aprendizaje que hemos recorrido (en la que hemos empezado haciendo numerosas pruebas pequeñas antes de continuar con el proyecto final) nos ha permitido empezar por conceptos sencillos y fáciles de entender que nos permitían avanzar rápidamente a casos mas complejos. Finalmente, hemos logrado producir una aplicación que se puede utilizar en entornos reales, con la que, fijando la placa BLE en una bicicleta, podemos realizar una ruta y visualizar correctamente los datos generados durante la misma. Bluetooth Low Energy es un concepto muy interesante, y abre las puertas para comunicar gran cantidad de dispositivos. Con esta tecnología podríamos realizar más proyectos útiles que hasta ahora no eran posibles. 63 8.1. Trabajo futuro Aunque la aplicación es funcional y cumple con los requisitos del proyecto, siempre es interesante la idea de ampliar la utilidad de nuestra aplicación. Un ejemplo claro es el de poder aprovechar aún más el hecho de tener la aplicación ejecutándose en un dispositivo móvil, ofreciendo la posibilidad de compartir las sesiones realizadas en las redes sociales (Twitter, Facebook, ...). Otra posibilidad que sería de utilidad es la de fijar una luz de freno a la placa, que al detectar una deceleración se encienda para indicar a conductores, peatones, etc. que se está reduciendo la velocidad para evitar accidentes. En relación con esto, otro punto importante de cara al futuro es el de utilizar los datos que se recogen de acelerometría para comprobar movimientos muy bruscos (como los que se darían en caso de accidente) para activar un sistema que avise a los servicios de emergencia en caso de que el usuario no responda en un breve tiempo. Se podrían realizar más cálculos con los datos obtenidos para poder sacar más información de la ruta. Además, aprovechando que la placa XTRINSIC-SENSE-BOARD contiene, aparte del acelerómetro que usamos, un magnetómetro y un sensor de presión, se podría recoger mucha más información sobre el esfuerzo realizado durante el trayecto. 64 Bibliografía [1] Api de google maps. https://developers.google.com/maps/documentation/ android-api/?hl=es. [2] Api para deep-sleep de mbed. https://developer.mbed.org/teams/SiliconLabs/ wiki/Using-the-improved-mbed-sleep-API. [3] Arm system ip. http://www.arm.com/products/system-ip. [4] Bluetooth core specification. https://www.bluetooth.com/specifications/ bluetooth-core-specification. [5] Cypress 100 projects in 100 days. https://github.com/cypresssemiconductorco/ PSoC-4-BLE/tree/master/100_Projects_in_100_Days. [6] Datasheet para el acelerómetro mma8491q. http://www.element14.com/community/ servlet/JiveServlet/previewBody/54565-102-1-273580/Datasheet_MMA8491Q. pdf. [7] Datasheet para el kit nrf51-dk de nordic. http://www.mouser.com/ds/2/297/ nRF51-DK%20-%20User%20Guide%20v1_0-706637.pdf. [8] Datasheet para el kit psoc 4 ble de cypress. http://www.cypress.com/file/137466/ download. [9] Material design de google. https://material.google.com/. [10] Página de tutoriales de cypress. http://www.cypress.com/training/ psoc-4-ble-101-video-tutorial-series-how-create-products-using-psoc-4-ble. [11] Repositorio mbed. https://developer.mbed.org/activity/code/. 65