UNIVERSIDADE DA CORUÑA

FACULTAD DE INFORMÁTICA Departamento de Electrónica y Sistemas

PROYECTO DE FIN DE CARRERA DE INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS

Análisis, diseño e implementación de un sistema embebido para monitorizar personas dependientes

Autor: Alfonso Nishikawa Muñumer Tutor: Adriana Dapena Janeiro Director: Tiago Fernández Caramés Fecha: 21 de junio de 2011

2

Agradecimientos Agradecimientos a Noe por aguantarme y mantenerme durante todo el tiempo del desarrollo del proyecto, y esperar con paciencia a que terminase. Agradecimientos a Tiago Fernández por la ayuda y trabajo puesto de su parte en la idea y desarrollo del proyecto. Agradecimientos también por ver fortalezas donde no hay más que debilidades, y el apoyo incondicional. Agradecimientos a Jacobo Lobeiras por recordarme frecuentemente que [censurado] para evitar que me perdiese en detalles nimios. La censura sugiere que agradezca el sacrificio realizado por el árbol que hizo posible imprimir la memoria en papel. Agradecimientos a Santiago Barros por su apoyo moral y hardware prestado. Y agradecimientos a Belén Torrente, Jacobo y Santiago por los cafés juntos en los que comentar los escollos del proyecto.

3

4

Resumen Diseño y desarrollo de un prototipo de monitor personal pasivo mediante la plataforma Arduino para estudiar la viabilidad y posibilidades de un dispositivo que posea las siguientes características: comunicación inalámbrica para avisos mediante XBee y flexibilidad con los posibles sensores que se puedan conectar, en este caso acelerómetro para caídas, pletismógrafo y posicionamiento geográfico mediante GPS. También se exponen unas ideas preliminares, a partir del prototipo, sobre las posibilidades de reducción de consumo y de miniaturización.

Palabras clave monitor personal, Arduino, XBee, GPS, acelerómetro Memsic 2125, pletismógrafo.

Hardware utilizado Arduino duemilanove, módulo XBee para Arduino, módulo GPS para Arduino, acelerómetro de 2 ejes Memsic 2125, emisor y receptor infrarrojo, componentes electrónicos varios genéricos. Software utilizado Arduino IDE 0021, Processing, Fritzing, X-CTU, librería GPS de D. Cuartielles.

5

6

Índice General Capítulo 1. Introducción................................................................................................................11 Capítulo 2. Antecedentes...............................................................................................................13 Capítulo 3. Conceptos previos.......................................................................................................15 3.1 Arduino................................................................................................................................15 3.1.1 Hardware.....................................................................................................................15 3.1.2 Shields.........................................................................................................................16 3.1.3 Mods............................................................................................................................17 3.1.4 Alternativas a Arduino.................................................................................................19 3.2 - ZigBee...............................................................................................................................21 3.2.1 IEEE 802.15.4.............................................................................................................21 3.2.2 NWK...........................................................................................................................22 3.2.3 APL..............................................................................................................................22 3.2.4 La red ZigBee..............................................................................................................23 3.2.5 Topología de la red ZigBee.........................................................................................24 3.2.6 Perfiles de Aplicación, Clusters y Endpoints..............................................................24 3.2.7 Vínculos.......................................................................................................................25 3.2.8 XBee............................................................................................................................25 3.3 - Memsic 2125....................................................................................................................28 3.3.1 Funcionamiento detallado...........................................................................................28 3.3.1.1 Modelos alternativos............................................................................................32 3.3.1.2 Modelo convectivo..............................................................................................32 3.3.1.3 Modelo de muelles...............................................................................................33 3.4 - Localización en exteriores (GPS).....................................................................................35 3.5 - Pletismógrafo....................................................................................................................37 Capítulo 4: Desarrollo....................................................................................................................39 4.1 - Sistema de comunicación ZigBee.....................................................................................40 4.1.1 Prueba de comunicación ZigBee-ZigBee....................................................................41 4.1.1.2 Configuración......................................................................................................41 4.1.2 Prueba de comunicación de transmisión periódica.....................................................42 7

4.1.2.1 Configuración......................................................................................................43 4.1.2.2 Código fuente.......................................................................................................44 4.1.3 Prueba de comunicación mediante pulsador...............................................................45 4.1.3.1 Configuración......................................................................................................45 4.1.3.2 Código fuente.......................................................................................................46 4.1.4 Conexión del pin SleepRQ..........................................................................................47 4.1.4.1 Configuración del XBee......................................................................................47 4.1.4.2 Conexión al Arduino............................................................................................48 4.1.4.3 Mejora para reducir el consumo..........................................................................49 4.2 - Detección de caídas..........................................................................................................51 4.2.1 Protocolo de comunicación del Memsic 2125............................................................52 4.2.2 Lectura con Arduino....................................................................................................52 4.2.3 Prueba de verificación del funcionamiento.................................................................52 4.2.3.1 Montaje del circuito.............................................................................................53 4.2.3.2 Código fuente del Arduino...................................................................................53 4.2.3.3 Visualización de los datos....................................................................................54 4.2.4 Lectura mediante interrupciones.................................................................................56 4.2.4.1 Programación.......................................................................................................56 4.2.4.2 Funcionamiento...................................................................................................57 4.2.4.3 Protocolo de envío de datos.................................................................................58 4.2.4.4 Resultados............................................................................................................59 4.2.4.5 Consideraciones posteriores................................................................................59 4.2.5 Determinación de umbrales de caída...........................................................................61 4.2.5.1 Desconexiones del end device.............................................................................61 4.2.5.2 Añadir comandos.................................................................................................61 4.2.5.3 Algoritmo de detección........................................................................................62 4.2.5.4 Preparación de la caja de pruebas de impacto.....................................................62 4.2.6 Algoritmos de detección de caídas..............................................................................65 4.2.6.1 Algoritmo 1..........................................................................................................66 4.2.6.2 Algoritmo 2..........................................................................................................67 4.2.7 Prueba de algoritmos...................................................................................................68 8

4.2.7.1 Algoritmo 1..........................................................................................................68 4.2.7.2 Algoritmo 2..........................................................................................................74 4.2.7.3 Conclusión...........................................................................................................81 4.3 - Localización en exteriores (GPS).....................................................................................82 4.3.1 Librería de Libelium....................................................................................................82 4.3.2 Probando el GPS.........................................................................................................84 4.3.3 Coordenadas en Google Maps.....................................................................................88 4.3.4 Actualizando el protocolo para visualizar la información de posición.......................89 4.3.5 Utilizando el GPS........................................................................................................90 4.3.5.1 Cómo pedir mapas estáticos a Google Maps.......................................................92 4.4 - Monitorización de constantes vitales (pletismógrafo)......................................................93 4.4.1 Montaje........................................................................................................................93 4.4.2 Software para la lectura asíncrona...............................................................................95 4.4.3 Algoritmo de medida de las pulsaciones.....................................................................98 4.4.3.1 Detección de una pulsación.................................................................................98 4.4.4 Bugs y problemas con la lectura del pletismógrafo..................................................101 4.5 - Visualizador desarrollado...............................................................................................102 4.6 - Sobre el consumo de batería del Arduino.......................................................................106 4.6.1 Posibles soluciones....................................................................................................106 4.6.2 Conclusión.................................................................................................................107 Capítulo 5. Conclusiones.............................................................................................................109 5.1 Sobre el acelerómetro........................................................................................................109 5.2 Sobre el pletismógrafo......................................................................................................110 5.3 Sobre el ZigBee.................................................................................................................110 5.4 Sobre el módulo de GPS...................................................................................................110 5.5 Sobre Arduino....................................................................................................................111 Capítulo 6. Líneas futuras de desarrollo......................................................................................113 6.1 Añadir módulo GPRS........................................................................................................113 6.2 Implementación en ensamblador.......................................................................................113 6.3 Miniaturización.................................................................................................................114 6.4 Investigación y desarrollo de sensores en prendas de ropa...............................................114 9

Anexo I: Instalación del IDE de Arduino y carga de programas.................................................115 I.1 Instalación en Windows.....................................................................................................115 I.2 Instalación en Linux...........................................................................................................115 I.3 Programación y carga de programas..................................................................................116 Anexo II: Actualización del firmware del módulo XBee............................................................121 Anexo III: Lectura exacta de pulsos PWM..................................................................................129 Anexo IV: Documentación del shield creado..............................................................................141 IV.1 Módulo para acelerómetros.............................................................................................142 IV.2 Módulo XBee SleepRQ...................................................................................................143 IV.3 Módulo de alimentación..................................................................................................144 IV.4 Módulo de reset...............................................................................................................144 IV.5 Una última consideración de conexión...........................................................................145 Anexo V: Modificaciones a la librería GPS de Libelium (original de D.Cuartielles).................147 Anexo VI: Relación de ficheros incluidos en el CD....................................................................153 Índice de Tablas...........................................................................................................................155 Índice de Ilustraciones.................................................................................................................157

10

Capítulo 1. Introducción Actualmente existen microcontroladores montados en placas que poseen comunidades detrás en internet, de manera que se pueden obtener soluciones a muchas necesidades, muchas de ellas ya probadas. Si a eso le añadimos un bajo coste en un tamaño pequeño, sencillez de programación y disponibilidad gratuita de los diseños hardware, se tienen todos los ingredientes para realizar cualquier proyecto electrónico personal de baja-media potencia de cálculo. El objetivo de este proyecto es probar las capacidades potenciales de un gadget que sirva para la monitorización de personas en entornos relativamente aislados. Con personas en entorno relativamente aislado se trata de englobar a aquellas personas sin atención directa de otras, y que poseen capacidades reducidas o son ancianos, por poner los ejemplos más representativos. Es necesario adquirir y procesar la información en tiempo real para poder transmitir una señal de auxilio en caso necesario. Esto define las necesidades de sensores y actuadores que ha de incorporar el dispositivo, como por ejemplo: acelerómetro para caídas, pletismógrafo para las constantes vitales y GPS para geolocalización, así como la posibilidad de informar: utilización de redes ZigBee o comunicación GPRS. En cualquier caso, se obtiene un incremento de seguridad, prevención y notificación instantánea en caso de algún incidente. La necesidad de varios sistemas de transmisión de alertas viene dado no por la redundancia, sino por la posibilidad de encontrarse en diversos entornos: tanto entornos cerrados como en un entorno rural, e incluso en el mar. Si bien la toma de medidas de sensores es constante, la idea es realizar un monitor personal pasivo. El monitor sólo establecerá una comunicación activa con otros dispositivos en el momento de avisar de incidentes y anomalías en las medidas tomadas, con el objetivo de posibilitar la reducción de consumo. En la actualidad hay cada vez más sistemas susceptibles de servir como monitorizadores. La mayoría se basa en las posibilidades que los móviles actuales brindan de manera integrada: acelerómetro, GPS, SMS, etc... Las aplicaciones de monitorización que poseen los móviles, por el momento, se acercan más a lo lúdico que a lo profesional.

11

Al mismo tiempo, entornos acotados relacionados con la salud poseen monitorizadores con posibilidades restringidas, como el Holter Monitor[1] para llevar un registro cardiológico. Aunando ambas ideas, se puede ver de manera clara el pronto salto que darán las ideas anteriores desde los contextos acotados (hospitales, profesionales de transporte,...) hacia un público más general, de manera más normalizada y genérica: lo que a los dispositivos anteriores les falta es la posibilidad de utilizarse en un entorno abierto, sin sacrificar autonomía, ergonomía, reducido tamaño, coste asequible, y opciones de personalización. Concretando la población que se podría beneficiar de un proyecto como el presente, se encuentran: •

Ancianos, en especial aquellos que viven solos

•

Discapacitados

•

Personas en zonas de baja densidad de población o entornos relativamente inhóspitos: aldeas poco comunicadas, montañistas, ganaderos trashumantes, …

•

Fines médicos: control en tiempo real de la diabetes, niveles de oxígeno en sangre,...

Para la realización del prototipo se utiliza el Arduino Duemilanove con el microcontrolador ATmega16837. El Arduino acepta módulos que ya están preparados para ser conectados: el módulo XBee para comunicación inalámbrica (XBee PRO Series 2) y el módulo GPS (A1037A). Adicionalmente se conecta el acelerómetro de 2 ejes Memsic2125, y un pletismógrafo formado por el emisor infrarrojo LTE-302 y receptor infrarrojo LTR-301. El dispositivo prototipo resultante ocupa un espacio aproximado de 7 x 11 x 10 cm. Mediante ZigBee se comunica con un ordenador en el que se pueden visualizar los datos medidos: aceleración, pulsaciones y posición geográfica.

12

Capítulo 2. Antecedentes En el año 1988 encontramos un monitor personal de arritmias desarrollado por Richard B. Sisken[2], en forma de monitor “de bolsillo” de medio kilo de peso, útil para el campo de emergencias médicas. Sin ningún tipo de posibilidad de comunicación. En el año 2006, S. H. Chew et al. Estudian las posibilidades de localización de personas mediante la localización GPS y celdas GPRS del móvil[3]. En 2008, Ping Wang desarrolla un sistema de monitorización en tiempo real de pacientes[4] basado en ZigBee, que envía las señales de sonido cardíaco, pulso y respiración a un servidor en el hospital, el cual las procesa y avisa en caso necesario. En la actualidad hay cada vez más sistemas que tratan de servir como monitorizadores. La mayoría se basa en las posibilidades que los móviles actuales brindan de manera integrada: acelerómetro, GPS, SMS, etc...; otros son sensores más sofisticados. Desde una perspectiva más nacional, ejemplos de las posibilidades y trabajos realizados son: •

Teléfono móvil emporiaSAFETYplus[5], que mediante un acelerómetro es capaz de avisar indicando la posición mediante el GPS que incorpora. Adicionalmente dispone de un “botón de emergencia” en el reloj.

•

Monitor Holter con dispositivo inalámbrico[6]

•

Lectura de las pulsaciones en un móvil con Android[7]

•

Vídeo del programa Redes Para La Ciencia en el que se presenta la visión de Eric Topol sobre la aplicación de las nuevas tecnologías a la medicina preventiva[8]

•

Monitorización cardíaca al volante mediante electrodos que no están en contacto[9]

•

Prenda con sensores para monitorización en residencias de ancianos(entorno acotado)[10]

13

14

Capítulo 3. Conceptos previos 3.1 Arduino Arduino[11] es una plataforma de prototipado de circuitos, de software libre, basada en hardware y software flexible y fácil de usar. Está destinada a cualquiera que esté interesado en crear entornos u objetos interactivos. Arduino puede ser usado para desarrollar objetos interactivos, que reciben las entradas de una serie de conmutadores y sensores, y controlan luces, motores y otras salidas físicas. Los proyectos en Arduino pueden ser autónomos, o pueden comunicarse con software ejecutándose en un ordenador. Las placas pueden ser soldadas a mano o compradas ya montadas. El IDE es software libre y puede ser descargado gratis. El lenguaje de programación de Arduino es una implementación de Wiring, una plataforma de computación física similar, la cual a su vez está basada en el entorno de programación multimedia Processing. Para los que ya conocen C/C++ es algo sencillo.

3.1.1 Hardware El hardware utilizado por Arduino depende del modelo, como se muestra en la tabla 1. Modelo

Microcontrolador ATmega8 ATmega168 ATmega168 ATmega328 ATmega1280

[antiguos] Diecimila Duemilanove (primera versión) Duemilanove Mega

Tabla 1: microcontrolador por modelo de Arduino

El Arduino utilizado es el Duemilanove con el microcontrolador ATmega168, cuyas principales características explotadas por el Arduino son: • Microcontrolador de 8 bits a 16 MHz

15

• 16KB de memoria flash de programa • 512B de memoria EEPROM • 1KB de memoria SRAM interna • 2 timers/counters de 8 bits • 1 timer/counter de 16 bits • 6 salidas PWM (también funcionan como entrada/salida digital) Ilustración 1: Arduino duemilanove

• 6 entradas analógicas de 10 bits • 6 entradas/salidas digitales • USART serie programable(usado para el USB) • Interfaz serie SPI • Interfaz serie I2C orientada a bytes • Watchdog Los diseños de referencia para el montaje de Arduino están disponibles bajo la licencia Creative Commons.

3.1.2 Shields Los shields (escudos, en castellano), son placas que se conectan encima de la placa de Arduino y que extienden su funcionalidad, como por ejemplo controlar dispositivos, adquirir datos, etc… Pueden estar preparados para ser apilados de manera que se pueden conectar varios distintos. Ilustración 2: Arduino con el 'motor shield'

La filosofía es la misma que la del Arduino: fácil de montar y barato de producir. 16

En la tabla 2 se listan algunos de los shields que se pueden encontrar a la venta. Shield

Descripción

XBee Shield

Permite al Arduino conectarse sin hilos usando ZigBee

Motor Shield

Permite controlar motores DC.

Ethernet Shield

Dota de una interfaz de ethernet al Arduino (no compatible con el Mega)

Gadget Shield

Incorpora sensores y actuadores: acelerómetros de 3 ejes, LEDs, emisor de infrarrojos, sensor de infrarrojos de 38 Khz y potenciómetros.

TellyMate Shield

Añade una salida de televisión de 38×25 caracteres al Arduino.

Liquidware Lithium Backpack

Una batería de litio recargable que se sujeta debajo del Arduino.

Liquidware Input Shield

Un joystick, dos botones y un motor de vibración. Como un mando de consola.

Adafruit GPS

Añade un módulo de GPS que puede registrar la localización, fecha y datos de sensores en una tarjeta de memoria flash.

Liquidware Touch Shield Slide Añade una pantalla táctil resistiva de 320×240 Módulo MicroSD

Permite leer y escribir en una memoria flash microSD. Tabla 2: listado parcial de shields disponibles

3.1.3 Mods Existen Arduinos modificados que son considerados oficiales, que disponen de alguna característica especial que lo hace interesante por encima de un Arduino genérico. En concreto, se puede encontrar en distintas páginas de venta de Arduino y se dispone de la documentación en línea de los siguientes Arduinos:

Nano Arduino montado en una placa compacta que se puede conectar directamente a una placa de prototipos. Se conecta al ordenador mediante un cable USB Mini-B.

Bluetooth También conocido como Arduino BT, contiene un módulo de

Ilustración 3: Arduino Nano

bluetooth que le permite comunicarse y ser programado sin hilos. Es compatible con los 17

shields de Arduino.

Lilypad Curioso Arduino con forma de flor, está diseñado para ser cosido en prendas de vestir (bastante utilizado en manualidades). Necesita sólo de 1 pila de 1,5V y además es lavable.

Fio

Ilustración 4: LilyPad

Arduino bastante compacto, está diseñado para aplicaciones wireless. Posee una conexión para alimentación mediante una batería de litio y un socket para XBee.

Mini Arduino reducido a la mínima expresión para cuando es necesario reducir espacio. La diferencia frente al Nano es que el Mini carece de controlador de USB, botón de reset, LEDs indicadores, conexión ICSP, además de estar restringido al

Ilustración 5: Arduino Mini

microcontrolador ATmega168.

Pro La placa Pro está diseñada para usuarios avanzados que desean realizar un montaje permanente en un proyecto. La característica es que no trae soldados pines de conexión de manera que permite soldarle los conectores deseados. Es compatible con los shields.

Pro Mini

Ilustración 6: Arduino Pro

Es similar al Mini (aunque incorpora un botón de reset), pero con la filosofía del Pro: no traer pines de conexión ya soldados para que se pueda integrar fácilmente de manera permanente en otros proyectos.

18

Serial Una placa básica que utiliza la interfaz RS232 para la programación y comunicación. Es fácil de montar, incluso como ejercicio de aprendizaje.

Serial Single Sided Diseño especial para ser montado completamente a mano. Si no es posible conseguir un Arduino, ya montado ni la placa, se dispone de los diagramas para grabar la placa PCB y soldar todo a mano.

3.1.4 Alternativas a Arduino

Ilustración 7: Arduino Serial Single Sided

Arduino no es la única plataforma basada en microcontroladores. Hay diversas opciones en función de las necesidades y las restricciones. Unos de los objetivos de Arduino es ser una alternativa barata y fácil frente a plataformas que ya existen, sin olvidar que es una plataforma libre y que existe una comunidad detrás de ella que aporta ideas, soluciones prefabricadas y soporte gratuito (en la medida de lo posible).

Wiring[12] Arduino es una plataforma basada en Wiring. Wiring sin embargo es más caro y posee más potencia. Al menos lo era hasta que Arduino lanzó la versión Mega. Actualmente Arduino es una plataforma más atractiva por la comunidad que tiene detrás.

Microcontroladores ZX

Ilustración 8: Wiring Board

Los microcontroladores ZX basados en AVR están dirigidos a aplicaciones embebidas, automatismo, control industrial y robótica. Son más caros por norma general que Arduino, aunque hay versiones baratas. Se programa en ZBasic, un lenguaje parecido al Visual Basic, y se ejecutan en una maquina virtual preinstalada en la memoria flash al comprar el

19

microcontrolador.

IRX2.2[13] Placa basada en el microcontrolador PIC16F84A, de baja potencia y coste, está diseñado para utilizar con prototipos.

CUI32[14]

Ilustración 9: iRX 2.2

Una de las alternativas a Arduino utilizando un PIC. En este caso es una placa con un microcontrolador de 32 bits muy potente (PIC32MX440F512 a 8 MHz, pero que soporta hasta 80 MHz), a precio más asequible que el Arduino.

Ilustración 10: CUI32

20

3.2 - ZigBee ZigBee es un estándar de comunicación wireless bidireccional, de bajo precio y muy bajo consumo de energía, basado en el estándar IEEE 802.15.4. La tecnología definida por la especificación ZigBee pretende ser más simple y barata que otras WPANs (Wireless Personal Area Networks) como por ejemplo el Bluetooth. Está orientada a aplicaciones inalámbricas que necesiten una tasa baja de transferencia de datos, una vida larga de batería (por su bajo consumo), y seguridad en la red (posibilidad de cifrado), como por ejemplo: electrónica de consumo, automatización del hogar, control industrial, periféricos del PC, aplicaciones de sensores médicos, juegos y juguetes, etc… ZigBee Alliance[15] es un grupo de compañías que mantienen y publican el estándar de ZigBee. Dentro del modelo OSI de red, ZigBee implementa las capas de Red (NWK) y de Aplicación(APL) mientras que las capas Física (PHY) y de Control de Acceso al Medio (MAC) son definidas por el estándar IEEE 802.15.4.

3.2.1 IEEE 802.15.4 El IEEE 802.15.4 es la especificación para redes de área personal de baja velocidad (LRWPANs) de las capas Física y Control de Acceso al Medio del modelo OSI de red. El estándar está orientado a dispositivos de muy baja complejidad, muy bajo coste, consumo energético muy bajo y baja velocidad de transmisión sin hilos. La máxima velocidad de transmisión de datos en bruto que define el estándar es de 250 Kb/s a una distancia de 10m[16], pero con posibilidad de mayor distancia a una velocidad de transmisión menor.

PHY La capa Física es la encargada de la activación/desactivación del emisor de radiofrecuencias, transmisión y recepción de los datos, detección de la energía del canal, selección de la frecuencia del canal e implementar el método CSMA/CA (Carrier Sense Multiple Access With Collision Avoidance) junto con CCA (Copying Collision Avoidance) para evitar

21

colisiones a la hora de transmitir. El estándar define 3 bandas de transmisión: 868 MHz (1 canal), 915 MHz (10 canales) y 2,4 Ghz (16 canales). La más utilizada es la de 2,4 Ghz por estar permitida en todo el mundo.

MAC La capa de Control de Acceso al Medio es la encargada de: generar las balizas de red (beacons) si el dispositivo es un coordinador, sincronización con las balizas, soportar la asociación/desasociación a una PAN (Personal Area Network), soportar la seguridad del dispositivo, emplear el mecanismo CSMA-CA para el acceso al canal, manejo y mantenimiento del GTS (Guaranteed Time Slot) y proveer un enlace fiable entre dos entidades MAC conectadas. Para la seguridad se disponen de suites formadas por AES, CTR, CBC-MAC y CCM que permiten activar control de acceso, cifrado de datos, integridad de los frames y secuential freshness.

3.2.2 NWK Según la especificación de ZigBee, la capa de red maneja las direcciones y enrutado. Concretamente se encarga de: crear una red (como coordinador), asociarse/reasociarse/abandonar una red, asignar direcciones de red, añadir y eliminar dispositivos a la red, descubrir a sus vecinos, enrutar mensajes, aplicar seguridad e implementar el método para descubrir rutas.

3.2.3 APL La capa de aplicación es la capa superior de la pila de protocolo de ZigBee. Está compuesta por el Application Framework, los Objetos de Dispositivo ZigBee (ZDO) y la Subcapa de Soporte de Aplicación (APS).

Application Framework Describe cómo crear y añadir un perfil a la pila de ZigBee. El Application Framework es el entorno en el que se hospedan los objetos de la aplicación (Application Objects) de los 22

dispositivos ZigBee. Se denominan objetos de la aplicación al software que se encuentra en el endpoint de una comunicación.

ZDO Los Objetos de Dispositivo ZigBee se encuentran siempre en el endpoint 0. Presentan una interfaz pública a los objetos de la aplicación para proveer de funcionalidad al dispositivo en función de su rol en la red (coordinador, router o dispositivo final): ensambla información de configuración, implementa descubrimiento, manejo de seguridad, manejo de red y de vínculos.

APS La subcapa de Soporte de Aplicación es la responsable de proveer los servicios de datos a los perfiles de los dispositivos ZigBee. También provee de un servicio para mantener vínculos y la tabla de vínculos.

3.2.4 La red ZigBee Las redes ZigBee contemplan 3 tipos de dispositivos en función de su funcionalidad: • Coordinador: es el dispositivo que crea y controla la red. Almacena información sobre la red, actuando como el centro de confianza (para la seguridad) y repositorio de claves de seguridad. Sólo hay uno por red. • Router: dispositivos que extienden la cobertura de la red, enrutan dinámicamente y proveen rutas de respaldo en caso de fallo o congestión de red. Se pueden conectar al coordinador y a otros routers. • Dispositivos finales (end devices): dispositivos que pueden transmitir y recibir mensajes, pero que no pueden realizar operaciones de enrutado. Obligatoriamente han de estar conectados al coordinador o a un router, y no pueden tener dispositivos hijos dependientes de ellos. El coordinador y los routers se consideran dispositivos de funcionalidad completa (Full Function Device), mientras que los dispositivos finales son dispositivos de funcionalidad reducida 23

(Reduced Function Device).

3.2.5 Topología de la red ZigBee Las redes ZigBee están pensadas para ser redes en malla (en estrella y en árbol son un caso particular de la malla). Los dispositivos de funcionalidad completa (coordinador y routers) se pueden interconectar entre ellos en forma de malla, mientras que los dispositivos de funcionalidad reducida (dispositivos finales) funcionan como simples “hojas” de la malla. La topología en malla permite comunicaciones con múltiples saltos entre nodos, y en el estándar ZigBee se hace hincapié en utilizar las rutas más fiables y de menor coste (entre las múltiples rutas que crean los dispositivos de funcionalidad completa) hasta llegar al destino. Además, esta configuración permite que la red tenga cierta tolerancia a fallos en caso de que un dispositivo falle o experimente interferencias: la red se puede autoorganizar usando el resto de dispositivos. Las redes se identifican por un PAN ID único de 64 bits, junto con un PAN ID de 16 bits que ha de ser único en las inmediaciones de una red. Así mismo, todos los dispositivos poseen una dirección de 64 bits única, asignada durante su fabricación, y una dirección de 16 bits asignada al unirse a una red. De este modo, una red puede contener hasta un máximo de 65534 nodos.

3.2.6 Perfiles de Aplicación, Clusters y Endpoints Un Perfil de Aplicación describe una colección de dispositivos empleados para un fin específico y el esquema de mensajes entre dichos dispositivos. Los dispositivos pertenecientes a un perfil de aplicación se comunican unos con otros a través de los clusters (pueden ser de entrada o salida). Cada cluster posee un ID dependiente del perfil. Un endpoint define una entidad de comunicación en un dispositivo a través de la cual se lleva a cabo una aplicación específica. La librería de clusters de ZigBee (ZCL) La ZCL es una librería de clusters que puede ser utilizada por cualquier aplicación, estando los clusters organizados por dominio funcional (iluminación, sensores, seguridad,…). Esto permite reutilizar clusters. Todo vínculo de cluster posee dos finales: cliente y servidor. 24

Los perfiles de aplicación están formados por diversos clusters de la ZCL de distintos dominios.

3.2.7 Vínculos Los vínculos son conexiones entre dos endpoints de manera que cada vínculo soporta un perfil de aplicación específico y un tipo de mensaje representado por un cluster de ese perfil. Los vínculos pueden ser creados entre endpoints individuales o grupos de endpoints, en los que se correspondan clusters de entrada y salida (mismo ID de cluster).

3.2.8 XBee XBee es un módulo de radiofrecuencia fabricado por Digi International[17] que implementa el estándar ZigBee. Hay 2 gamas de hardware: S2 y S2B. La diferencia radica en que la implementación S2B posee un microcontrolador adicional para poder añadir código al módulo, en caso de necesitar funcionalidades especiales. Existen tres modelos de XBee: XBee(en S2), XBee-PRO(S2) y XBee-PRO (S2B), que difieren en características de potencia de transmisión,

Ilustración 11: XBee shield con el módulo XBee

consumo, etc. El módulo XBee transmite en la frecuencia de 2,4Ghz, con un alcance entre 30 y 100 metros (XBee), y entre 100 y 1500 metros (XBee-PRO) en función del tipo de antena utilizada y la cobertura. Existen módulos con un chip de antena, antena integrada y con un conector para una antena externa. Para poder utilizarlo con Arduino es necesario utilizar el XBee Shield, que conecta el puerto serie del módulo del XBee con el puerto serie del Arduino para poder mandar comandos al módulo y poder transmitir información. La comunicación entre el Arduino y el módulo XBee se realiza a través de una interfaz de puerto 25

serie. El firmware del XBee implementa dos protocolos diferentes de comunicación: el modo AT (o transparente) y el modo API. El módulo XBee se puede configurar por puerto serie utilizando comandos AT, aunque lo más sencillo es utilizar la herramienta X-CTU.

Modo Transparente Cuando se trabaja en modo transparente, el módulo sustituye a la linea serie, de modo que todos los datos recibidos por el UART a través del pin DIN se encolan para transmitir por radio. Todos los datos recibidos se envían al Arduino por el pin DOUT. En este modo, se pasa al modo de comandos AT para configurar el módulo enviándole, con ciertas restricciones, la cadena “+++” por el pin DIN.

Modo API La alternativa al modo AT es el modo API. Este modo se basa en frames, de modo que la aplicación interacciona con el módulo utilizando estructuras predefinidas tanto para la entrada como para la salida. El trabajar en modo API, si bien es más compleja la interfaz, permite obtener e indicar mucha más información, sin necesidad de entrar en el modo de comandos AT: permite soportar comandos ZDO y tráfico de perfil público, así como conocer el remitente de los mensajes, estar informado del éxito/fallo de envíos, etc…

Herramienta de configuración X-CTU Digi pone a disposición una herramienta de configuración para Windows: X-CTU. Esta permite configurar los parámetros del módulo y actualizar el firmware. Además, también permite: • Descubrir todos los dispositivos XBee de la red • Actualizar el firmware de un módulo local (por USB o puerto serie) • Leer y escribir los parámetros de configuración del módulo en un dispositivo local o

26

remoto • Grabar y cargar perfiles de configuración conteniendo configuración personalizada

27

3.3 - Memsic 2125

Montado por Parallax[18], el Memsic2125[39] es un acelerómetro térmico de bajo coste (30$ es algo barato tratándose de un acelerómetro) de 2 ejes, con un rango de medición desde -4 g 1 hasta +4 g, útil para medir inclinación, colisiones, aceleración dinámica y estática y vibración. El consumo es menor de 5 mA. El circuito integrado MX2125 que conforma el sensor dispone de una cámara de gas calentado y cuatro sensores de temperatura alrededor de su eje. Cuando el acelerómetro está en horizontal, todos los sensores de temperatura miden la misma temperatura. Al inclinarlo, el gas caliente se acerca más a uno de los sensores de

Ilustración 12: Memsic2125

manera que comparando las temperaturas se puede detectar tanto la aceleración estática como dinámica. El circuito integrado MX2125 se encarga de convertir las medidas de temperatura en pulsos PWM recibidos por el Arduino. La salida de la medición de los ejes se realiza mediante una señal PWM de 100Hz con ciclo de trabajo proporcional a la aceleración. Con una alimentación de 5V, un ciclo de trabajo del 50% corresponde a una aceleración de 0g, aunque el ciclo de trabajo posee un error de ±1.3% (dependiente de cada unidad), de manera que es necesario tener en cuenta el offset a cero.

3.3.1 Funcionamiento detallado La manera de funcionar del Memsic 2125 al principio parece un poco rara. A la hora de comprender el funcionamiento puede darse el caso de que parezca que “algo no encaja” al mezclar mediciones que involucran aceleración estática y aceleración dinámica.

1 Aceleración correspondiente a 9,81 m/s²

28

Ilustración 13: lectura al aplicar una fuerza vertical positiva

En la ilustración 13 se muestra el acelerómetro bajo la influencia de la gravedad y cómo la gráfica marca +1 g de aceleración (área sobre el gradiente verde). En cierto momento se desplaza el acelerómetro verticalmente en contra de la fuerza de la gravedad, y se muestra en la gráfica cómo la aceleración aumenta hasta +2,5 g (área sobre el gradiente rojo). La fuerza aplicada y la gravedad son de sentido contrario (f hacia arriba y g hacia abajo), mientras que el acelerómetro muestra una adición de aceleraciones. En la ilustración 14 se muestran más datos de aceleración medidos que pueden representar un “comportamiento extraño”.

Ilustración 14: lectura del acelerómetro al caer

En la parte izquierda se puede ver la aceleración medida mientras se sostiene el acelerómetro a 29

unos 2 metros de altura: +1 g. En cierto momento se suelta el acelerómetro dejándolo caer en caída libre, que corresponde a las medidas centrales. El momento del impacto ha quedado registrado con un valor fuera de lo normal; lo que ocurrió es que un cable de alimentación se salió de pin con el impacto, y dicho valor desmedido (y los siguientes) fueron los que llegaron al visualizador tras reconectar la alimentación. Podemos suponer con cierta seguridad que el momento del impacto fue justo antes del valor extraño que se muestra en la frontera derecha. Como curiosidad, según la gráfica, el intervalo de caída ha sido de aproximadamente de 1,25-1,3 unidades horizontales (cada unidad son 0,5 segundos: 50 mediciones). Eso hace una caída de unos 0,625-0,65 segundos, que son entre 1,91 y 2,07 metros. La medida no está mal teniendo en cuenta que cayó desde 2 metros, y es posible que unas cuantas medidas se perdiesen por el retardo entre la medición y el envío por el XBee. Volviendo al “comportamiento extraño”, se puede observar que bajo la fuerza de la gravedad la lectura es de +1 g, y cuando está cayendo la lectura es de 0 g. Parece incongruente que mientras cae y acelera, la lectura en el acelerómetro es de 0 g. Consultando la base teórica: En

el

datasheet

del

circuito

integrado

MXD2125GL[19], que es el que lleva el Memsic mx2125, se lee que “su diseño está basado en la convección de calor y no necesita una masa sólida

de

prueba”

(representación

en

la

Ilustración 15) Basándose

en

Ilustración 15: detección por convección

lo

que

pone,

el

siguiente

razonamiento abductivo que expondré hipotetizando el comportamiento es incorrecto, aunque a priori parezca razonable. Para aceleración estática (gravedad) todo funciona según la intuición. Viendo el esquema de funcionamiento cuando se inclina el acelerómetro uno de los lados se calienta más. Concretamente, en el esquema se ha rotado sobre el eje Y de manera que el detector “-” del eje X se calienta más por convección y el valor medido en el eje X tendería a -1 g. 30

En esta situación, hipotetizamos mediante abducción que el funcionamiento puede funcionar como un autobús: cuando está acelerando todo el mundo se siente “tirado hacia atrás”. De este modo, al aplicar una fuerza en sentido contrario a la gravedad el calor tendería a centrarse “un poco” haciendo que la parte que antes estaba “fría” ahora esté un poco más caliente, y la caliente se caliente un poco menos, equilibrando un poco la temperatura. Lo esperado es que el acelerómetro tienda a +0 g (por poner un valor), como se muestra en la ilustración 16.

Ilustración 16: hipótesis de funcionamiento: efecto bus

Este razonamiento es erróneo, porque esta situación en la realidad hace que el acelerómetro marque -2 g (similar al primer ejemplo del principio, pero de signo contrario) siendo el efecto el mostrado en la ilustración 17: el calor se desplaza en el sentido de la marcha, y cuanta más fuerza, más calor se desplaza.

31

Ilustración 17: efecto real, en absoluto intuitivo

3.3.1.1 Modelos alternativos Lógicamente no se puede hacer otra cosa más que descartar el modelo hipotetizado de funcionamiento y pensar en otros. En este caso hay 2 modelos que explican perfectamente el comportamiento.

3.3.1.2 Modelo convectivo A pesar de que el datasheet del sensor ya indica explícitamente “su diseño está basado en la convección de calor”, las implicaciones de dicha afirmación no son en absoluto obvias ya que no es algo común ver objetos que funcionan por convección en un encapsulado sobre el que se aplican fuerzas. El modelo convectivo, pues, se basaría en el hecho de que bajo una aceleración, las moléculas más frías “pesan más” y las más calientes “pesan menos” y el calor modifica la densidad, de modo que se ordenan tal y como se ordena la atmósfera por capas en función de la densidad. De este modo, bajo la aceleración de la gravedad tenemos el efecto visto: el calor “va hacia arriba”, pero ¿qué pasa cuando ejercemos una fuerza? (ilustración 17) Para explicar esto hay que diferenciar entre el encapsulado y la cámara con gas: la fuerza se ejerce sobre el encapsulado de forma que es como si hubiese una gravedad mayor, y más calor se dirige al foco que está en la dirección del movimiento, donde estarán las moléculas menos densas y

32

por lo tanto más calientes. El resultado en el ejemplo es que las aceleraciones se han sumado. Todavía queda una cuestión: “g y f son de sentido contrario. ¿Por qué se han sumado?“, es decir: g es en sentido descendente pero se está detectando como “movimiento en sentido negativo(-1g)” donde “negativo” es “hacia arriba”. La respuesta está en que la cámara de gas, aunque el encapsulado está parado, lo detecta como si estuviese acelerando “hacia arriba” (en sentido contrario a la gravedad). Otra forma de verlo es que la pared del encapsulado es la que ejerce una fuerza sobre el gas por la tercera ley de Newton (Ley de acción y reacción). Tras esto, ahora es comprensible que al ejercer una fuerza en sentido contrario a la gravedad, las fuerzas sean aditivas, ya que “virtualmente” el encapsulado se mueve en sentido contrario a la gravedad y además le estamos aplicando una fuerza en el mismo sentido. Así mismo, cuando el acelerómetro está en caída libre, el encapsulado no ejerce la fuerza de la tercera ley de Newton comentada, y por ello la medición indica “0 g”. Conclusiones: una conclusión importante que se extrae de todo esto es que el acelerómetro mide la aceleración estática (gravedad) en sentido contrario, es decir, con el signo cambiado y por lo tanto el vector aceleración es de sentido contrario a la gravedad. Cuestión a tener en cuenta si se desea implementar un sistema de navegación inercial[20]. Otra conclusión que se extrae es que este tipo de acelerómetros es muy útil para medir la inclinación (tilt) en soportes que se sabe que su estado normal/deseado será horizontal, ya que por su funcionamiento indica que se está “mirando hacia arriba” mediante valores positivos y “mirando hacia abajo” mediante valores negativos. El mayor problema es que la aceleración estática y dinámica son indistinguibles y para diferenciarlas sería necesaria la utilización de otros elementos, como por ejemplo giróscopos[21].

3.3.1.3 Modelo de muelles El modelo de muelles es más sencillo de entender, y explica los mismos hechos que el modelo convectivo. El hecho de que el datasheet del sensor indicase que “su diseño está 33

basado en la convección de calor” influye en no considerar este modelo en primera instancia. Supongamos un peso soportado por 4 muelles dentro de un encapsulado al vacío junto con la acción de la gravedad (ilustración 19). La bola estaría desplazada en el sentido de la gravedad lo correspondiente a 1 g. Que la bola sufre una fuerza hacia abajo por culpa de la gravedad es similar a pensar que el encapsulado se está moviendo hacia arriba en contra de la gravedad. Para la bola eso es indistinguible. Al aplicar una fuerza hacia arriba, la bola se acercará más a la parte inferior del encapsulado (ilustración 18), y el sensor detectará que la aceleración se ha incrementado. Aquí se puede comprender que la bola demuestra fácilmente la adición de aceleraciones.

Ilustración 19: modelo de muelles,

Ilustración 18: acción de la

junto con la acción de la gravedad

gravedad y una fuerza externa

En el caso de la caída libre, la bola cae a la misma velocidad que el encapsulado (ley de la gravitación) y por lo tanto marca “0 g”, como viene ocurriendo con el sensor Memsic 2125.

34

3.4 - Localización en exteriores (GPS) La tecnología GPS (Global Positioning System) permite determinar en exteriores la posición de un elemento en la superficie de la tierra. El módulo GPS a utilizar con Arduino está documentado en la web de Libelium[22] donde se puede encontrar un tutorial[23], la documentación de los comandos GPS soportados por el módulo[24] y una librería creada por David Cuartielles con un API que facilita el acceso al módulo[25]. Para incluir la funcionalidad del GPS en el dispositivo se utiliza el módulo GPS que posee el circuito integrado A1037-A (ilustración 21)

Ilustración 21: módulo con el A1037-A

Ilustración 20: módulo con el A1080-B

También existe otro módulo GPS pero que lleva el circuito integrado A1080-B (ilustración 20) En ambos casos es necesario conectarle una antena externa. El módulo se comunica con el Arduino por puerto serie a 4800 bps. Se ha de conectar en los pines 0 y 1, pero como éstos estarán ocupados por el XBee, se utilizarán los pines 8 y 9. Por ello, la lectura se realizará simulando un puerto serie por software. Para leer los datos del GPS se utilizará la librería de Libelium creada por D. Cuartielles, que ya provee las funciones necesarias para la comunicación serie por el puerto 8 y 9. A pesar de que las funciones de envío y recepción por el puerto serie virtual son bloqueantes, en nuestro caso es suficiente dado que sólo leeremos los datos cuando nosotros queramos (no necesitamos recibirlos asíncronamente). Además, dado 35

que la lectura del acelerómetro y la comunicación por XBee son asíncronas, no debería haber ningún tipo de problema al utilizar el módulo GPS. El módulo envía periódicamente información al Arduino mediante comandos. En nuestro caso se configurará el módulo para que envíe al Arduino sólo mensajes GGA, que contienen las coordenadas. La funcionalidad Satellite Based Augmentation Systems permite interpretar las señales de los sistemas WAAS (Wide Area Augmentation System – EEUU, Canadá y Méjico), EGNOS (European Geostationary Navigation Overlay System – Europa, África y Venezuela) y MSAS (Japón, Australia y Hawaii). Estos sistemas permiten que el GPS adquiera información más rápidamente, simplemente indicando un número de región al módulo. A pesar de que nuestro módulo posee un firmware que soporta esta funcionalidad, el circuito integrado no lo soporta (deducimos que es posible que, en nuestro caso, lleve uno de los ejemplos X1037-A, y no el de fabricación masiva comercial A1037-A).

36

3.5 - Pletismógrafo Un pletismógrafo es un dispositivo utilizado para medir el volumen de órganos animales. Dichos cambios de volumen se detectan en base a fluctuaciones de líquidos o gases, generalmente aire o sangre. Debido a que los pletismógrafos permiten controlar el bombeo de sangre, es posible monitorizar el pulso en personas dependientes. Existen diversas formas de implementar un pletismógrafo, pero nosotros nos ceñiremos a las noinvasivas, para evitar infecciones o intervenciones quirúrgicas de cualquier tipo. Hay a la venta circuitos comerciales de tipo no-invasivo (a $60), pero es realmente sencillo montar uno de manera muy barata. Para ello se colocan un emisor y un receptor infrarrojo sobre la yema de un dedo de la mano y el Arduino medirá la variación de tensión producida por la variación de la reflexión de infrarrojos según varía el volumen de sangre.

37

38

Capítulo 4: Desarrollo Al tratarse de un proyecto de diseño y desarrollo de un prototipo, el objetivo es comprobar las posibilidades de integración de los diferentes módulos y proponer ideas para la mejora del prototipo. Un objetivo secundario es reducir el coste, siendo este el criterio más restrictivo para la elección del hardware escogido. La metodología, pues, es seleccionar un hardware de base, analizar si teóricamente podría adaptarse al microcontrolador, y ver si puede coexistir con el resto de componentes dentro de las capacidades del microcontrolador escogido. Hay que tener en cuenta que la falta de información sobre este determinado tema es uno de los puntos que investiga el proyecto. Para el desarrollo software del visualizador no es necesaria una metodología rígida, ya que el objetivo es poder visualizar y comprobar el correcto funcionamiento del dispositivo. El dispositivo final ha ser autónomo. Para ello, el microcontrolador de base es el que posee el Arduino Duemilanove: el ATmega168, a 16 MHz, con 16KB de memoria FLASH de programa y 1KB de RAM. La conexión con la interfaz inalámbrica ZigBee se realiza mediante puerto serie a 9600bps, lo que en principio no entraña problema puesto que el ATmega168 posee un puerto serie por hardware. El módulo GPS se conecta por puerto serie a 4800bps. El microcontrolador no dispone de más puertos serie, pero dado que sólo leeremos la información de posición cuando nos convenga, la solución de un puerto serie por software resulta factible a priori. El acelerómetro Memsic2125 envía una señal PWM de 100Hz por eje (2 en total) al Arduino. El ATmega168 no dispone de lectura nativa de este tipo de señales, pero dada la baja frecuencia, es posible programar rutinas asíncronas que midan los pulsos. El pletismógrafo genera una señal de voltaje como medida. El ATmega168 posee puerto para leer señales analógicas. La frecuencia de las pulsaciones es baja, mucho menor de los teóricos 10Khz que puede leer el microcontrolador. Según el análisis anterior, en teoría es posible comunicarse con los dispositivos sin que estresen 39

mucho el microcontrolador. El siguiente desarrollo muestra el procedimiento, resultados y conclusiones de cada uno de los pasos para incorporar todas las funcionalidades.

4.1 - Sistema de comunicación ZigBee El primero de los pasos es establecer la comunicación mediante ZigBee para poder enviar avisos de incidentes. Durante el desarrollo se utiliza también para el envío de datos a visualizar en una aplicación desarrollada a tal fin. Para conectar el módulo ZigBee al Arduino hay que conectar el módulo XBee Pro ZB con conexión de antena pigtail al shield de comunicación XBee.

Ilustración 23: shield de comunicación XBee Ilustración 22: módulo XBee Pro ZB con conextión pigtail

40

Ilustración 24: XBee shield conectado al Arduino

Si los módulos XBee están configurados para funciona en modo AT, lo enviado por puerto serie a uno de ellos será recibido por el otro (puerto serie en el otro extremo). Para probar la comunicación se realizan varias pruebas.

4.1.1 Prueba de comunicación ZigBee-ZigBee En esta prueba se transmite información de XBee a XBee y se leen los datos en el X-CTU mediante la pestaña “Terminal”. Para ello, se utilizarán dos placas de Arduino sin microcontrolador. El XBee shield se ha de configurar con los pines en “USB” en ambos casos para que el módulo de XBee se comunique con el ordenador.

4.1.1.2 Configuración Coordinador Uno de los XBee tendrá el “ZIGBEE COORDINATOR AT” versión 2070 con la siguiente configuración específica (los datos relevantes): • PAN ID: 3332 • DH: 0 41

• DL: FFFF (Broadcast) • BD: 3 (9600 bps) End Device El otro ZigBee tendrá el firmware “ZIGBEE END DEVICE AT” versión 2870, con los siguientes parámetros AT: • PAN ID: 0×3332 • DH: 0 • DL: 0 (destino: el coordinador) • BD: 3 (9600 bps) • ST: 0xFFFE (Tiempo antes de pasar a dormido) • SO: 2 (Estar todo el tiempo indicado por ST despierto) Tras esto, hay que abrir dos instancias de X-CTU, de manera que cada una esté controlando uno de los Arduinos, y utilizar la pestaña “Terminal”. Todos los datos enviados por uno de los dispositivos es recibido por el otro en pocos milisegundos, y viceversa.

Ilustración 25: prueba de comunicación ZigBeeZigBee

En la ilustración 25, el color azul indica que los datos han sido enviados por el módulo (las letras enviadas por el COM17, recibidas en el COM16), y el color rojo indica los datos recibidos (los números enviados por el COM16 y recibidos en el COM17).

4.1.2 Prueba de comunicación de transmisión periódica En esta prueba se transmite periódicamente un carácter desde un Arduino. La respuesta se lee mediante el X-CTU. Para ello se necesita: 42

• Un Arduino con XBee como end device que transmitirá un carácter por segundo • Un Arduino con XBee pero sin microcontrolador, como coordinador, que recibirá los datos y se leerán mediante el X-CTU.

4.1.2.1 Configuración End Device El XBee Shield del Arduino que funcionará como emisor ha de tener los pines en posición “XBEE” para que sea el microcontrolador el que emita y reciba del módulo XBee. El firmware del XBee será el “ZIGBEE END DEVICE AT” versión 2870, con los parámetros: • PAN ID: 0×3332 • DH: 0 • DL: 0 (destino: el coordinador) • BD: 3 (9600 bps) • ST: 0xFFFE (Tiempo antes de pasar a dormido) • SO: 2 (Estar todo el tiempo indicado por ST despierto) Coordinador El Arduino que funcionará como coordinador deberá carecer de microcontrolador. El XBee Shield deberá ser configurado con los pines en la posición “USB” para que la comunicación sea entre el módulo XBee y el ordenador, en el que se ejecutará el XCTU, conectado al módulo y en la pestaña “Terminal” para poder ver los mensajes de entrada y salida del coordinador. El firmware será el “ZIGBEE COORDINATOR AT” versión 2070 con los siguientes parámetros: • PAN ID: 3332 • DH: 0 • DL: FFFF (Broadcast) • BD: 3 (9600 bps) 43

4.1.2.2 Código fuente El módulo de Arduino que transmitirá el carácter periódicamente ha de llevar el siguiente programa: int i=0; void setup() { Serial.begin(9600) ; } void loop() { delay(1000) ; Serial.print(i++, DEC) ; i=i%10; }

El código lo que hace es enviar la secuencia 0,1,2,…,9 separando cada número 1 segundo. Tras enchufar ambos dispositivos, el coordinador comenzó a recibir los datos, como se puede ver en la ilustración 26.

Ilustración 26: datos recibidos de un emisor intermitente

El hecho de que reciba a partir del 6 es que los primeros números se enviaron mientras el cliente estaba uniéndose a la red.

44

En la ilustración 27 se muestra que tras una desconexión (desenchufando) del coordinador y conexión posterior, el cliente continúa enviando datos.

Ilustración 27: recepción de datos tras desconexión

4.1.3 Prueba de comunicación mediante pulsador En esta prueba se comprobará la respuesta a un pulsador. Se programará el Arduino para que cuando le llegue un determinado carácter, el LED integrado conmute. El emisor será el módulo XBee conectado al X-CTU, utilizando la terminal integrada. Para ello se necesita: • Un Arduino con XBee como end device. • Un Arduino con XBee pero sin microcontrolador, como coordinador, que transmitirá los caracteres mediante la terminal del X-CTU.

4.1.3.1 Configuración End Device El XBee Shield del Arduino que funcionará como receptor ha de tener los pines en posición “XBEE” para que sea el microcontrolador el que emita y reciba del módulo XBee. El firmware del XBee será el “ZIGBEE END DEVICE AT” versión 2870, con los parámetros: • PAN ID: 0×3332 45

• DH: 0 • DL: 0 (destino: el coordinador) • BD: 3 (9600 bps) • ST: 0xFFFE (Tiempo antes de pasar a dormido) • SO: 2 (Estar todo el tiempo indicado por ST despierto) Coordinador El Arduino que funcionará como coordinador deberá carecer de microcontrolador. El XBee Shield deberá ser configurado con los pines en la posición “USB” para que la comunicación sea entre el módulo XBee y el ordenador, en el que se ejecutará el XCTU, conectado al módulo y en la pestaña “Terminal” para poder ver los mensajes de entrada y salida del coordinador. El firmware será el “ZIGBEE COORDINATOR AT” versión 2070 con los siguientes parámetros: • PAN ID: 3332 • DH: 0 • DL: FFFF (Broadcast) • BD: 3 (9600 bps)

4.1.3.2 Código fuente El módulo de Arduino que estará esperando por un carácter estará programado con el siguiente código: // Conmuta el estado del PIN 13 al recibir el carácter 'c' int estado = LOW ; void setup() { Serial.begin(9600) ; pinMode(13,OUTPUT) ; digitalWrite(13, estado) ; } void loop() {

46

if (Serial.available()>0) { char dato_b = (char) Serial.read() ; if (dato_b == 'c' || dato_b == 'C') { // 'c'onmutar if (estado == LOW) estado = HIGH ; else estado = LOW ; digitalWrite(13,estado) ; delay(250) ; } } }

Cuando recibe el carácter ‘c’ o ‘C’, conmuta el pin 13 de manera que se enciende y se apaga el LED integrado que lleva el Arduino.

Tras comprobar la simplicidad de ZigBee para transmitir datos y su bajo consumo, es positivo incluirlo en el proyecto, ya que permitiría funcionalidades como: • Monitorización en un ordenador de distintas variables medidas por el dispositivo. • Configuración de parámetros de la aplicación en el Arduino. • Aviso automático (a través de una conexión a un ordenador) de problemas del portador. Hay que hacer hincapié en la cuestión energética: la necesidad de utilizar la funcionalidad del XBee de dormir bajo demanda, de modo que el Arduino controle cuándo despertar para ahorrar todavía más energía. Esto se realiza a través del pin 9 del XBee (Sleep Request / SleepRQ).

4.1.4 Conexión del pin SleepRQ 4.1.4.1 Configuración del XBee Para poder dormir el módulo XBee desde el Arduino primero hay que configurar el módulo XBee. Hay que establecer la siguiente configuración mediante el X-CTU: • SM = 1 (Sleep Mode = Pin hibernate) • D7 = 0 (control CTS desactivado) 47

• PR = 0 (Resistencias de pull-up desactivadas para ahorrar energía) Se desactiva la línea /CTS porque el XBee Shield está diseñado para poder resetear el Arduino al poner a 1 la línea DIO7 remotamente, que está compartida con /CTS. Si no se desactiva desactiva esta línea ni se pone a 0, el Arduino se reseteará cuando el módulo de XBee se ponga a dormir, porque el XBee pondrá a 1 /CTS (ya que al dormir no acepta datos). La conexión afectada se puede ver en el esquema del XBee Shield[26].

4.1.4.2 Conexión al Arduino El módulo XBee PRO (S2) funciona con un voltaje entre 3V y 3,4V, de manera que el valor lógico HIGH es a partir de 2,4V. El voltaje de salida del Arduino en los pines digitales es dependiente del voltaje de alimentación, siendo el rango de salida de 2,3V a 4,2V. Para poder acoplar la salida del Arduino con la entrada del XBee, con el objetivo de consumir lo mínimo posible cuando se desee dormir el módulo XBee, una solución es aprovechar el pin de 3,3V que tiene el Arduino (gracias al chip FTDI FT232RL) como señal de entrada al módulo XBee mediante un transistor MOSFET de canal N. La ilustración 28 muestra la conexión del Arduino al pin SleepRQ del XBee mediante una resistencia R1 de 100Kohm y un transistor Q1 modelo 2N7000[27].

48

Ilustración 28: esquema de conexión del pin SleepRQ

En el circuito propuesto, cuando el pin D12 esté a LOW (0V), el transistor Q1 estará al corte y el pin D9 estará a 3,3V, de modo que el XBee estará dormido. El consumo será mínimo: las fugas por el transistor por la tensión entre el drenador y la fuente, y las fugas por el pin 9 del XBee (en conjunto, inferior al μA). Cuando el pin D12 esté a HIGH(4,2V-5V), el transistor Q1 estará en la zona de saturación y pondrá el pin 9 del XBee a LOW, lo que mantendrá al módulo XBee despierto. El consumo en este estado es el correspondiente a la corriente de fuga por el transistor puerta-fuente (despreciable) y la corriente que pasa a través de la resistencia R1: 33 μA.

4.1.4.3 Mejora para reducir el consumo Teniendo en cuenta que los pines del XBee que están al aire se consideran que están a alta, es posible simplificar y al mismo tiempo reducir a completamente despreciable el consumo de la interfaz adaptadora entre el Arduino y el XBee. 49

En la ilustración 29 se muestra el esquema de conexión de bajo consumo utilizando sólo un transistor.

Ilustración 29: esquema de bajo consumo de conexión del pin SleepRQ

En él, la interfaz es inversora. Cuando el pin 12 del Arduino se pone a 5V, el pin 9 del XBee se pone a 0V y por lo tanto se despierta. Cuando el pin 12 del Arduino se pone a 0V, el pin 9 del XBee queda virtualmente al aire y se duerme por considerarse un 1 lógico. El consumo sólo aparece por las pérdidas entre Gate y Source cuando el Arduino pone el pin a 5V. Según el datasheet del 2N700027, el consumo debería estar entre 10 y 100 nA.

50

4.2 - Detección de caídas Con el fin de poder detectar caídas del usuario, el sistema lleva un acelerómetro encargado de medir la aceleración en distintos ejes. En concreto, el acelerómetro es el Memsic 2125 montado por Parallax. Se trata de un acelerómetro térmico de bajo coste (30$ es algo barato tratándose de un acelerómetro) de 2 ejes, con un rango de medición desde -4g hasta +4g, útil para medir inclinación, colisiones, aceleración dinámica y estática y vibración. El consumo es menor de 5 mA. En las ilustraciones 30 y 31 se muestra el Memsic2125 y su esquema.

Ilustración 30: Memsic2125

Ilustración 31: esquema del Memsic2125 mostrando las conexiones del C.I. MX2125

Las conexiones del Memsic2125 que van conectadas al Arduino son las mostradas en la tabla 3.

51

Pin Nombre Función 1 Tout Señal analógica indicando la temperatura 2 Yout Señal PWM con la medida del eje Y 3 Gnd Ground o no conectado (internamente conectado, según el 4 Gnd/NC esquema) 5 Xout Señal PWM con la medida del eje X Tabla 3: conexiones del Memsic2125

4.2.1 Protocolo de comunicación del Memsic 2125 La salida de la medición de los ejes se realiza mediante una señal PWM de 100Hz con ciclo de trabajo proporcional a la aceleración. Con una alimentación de 5V, un ciclo de trabajo del 50% corresponde a una aceleración de 0g, aunque el ciclo de trabajo posee un error de +-1.3% (dependiente de cada unidad), de manera que es necesario tener en cuenta el offset a cero.

4.2.2 Lectura con Arduino Para leer el acelerómetro con el Arduino se utilizará la función pulseIn() que está incluida por defecto en Arduino. La función pulseIn() devuelve un unsigned long indicando el número de microsegundos que dura un pulso positivo en un pin. Para convertir la lectura del pulso en un valor entre -1000 y 1000, la función es la siguiente: f(x) = (x-5000)/5

4.2.3 Prueba de verificación del funcionamiento Para verificar el funcionamiento se conectará el acelerómetro Memsic 2125 al Arduino, y este transmitirá por puerto serie las lecturas al ordenador. En el ordenador se ejecutará un programa escrito en Processing[28] que mostrará la salida.

52

4.2.3.1 Montaje del circuito Para la verificación del funcionamiento del acelerómetro Memsic 2125 es necesario realizar el montaje que aparece en la ilustración 32, de modo que la lectura del eje X se realizará por el puerto 2, y la lectura del eje Y por el puerto 3. La patilla del sensor de temperatura del Memsic 2125 se deja desconectada.

Ilustración 32: conexión del Memsic 2125 al Arduino

4.2.3.2 Código fuente del Arduino El Arduino enviará la siguiente información al ordenador de manera cíclica: X\n \n Y\n \n

Para ello, se cargará el siguiente programa: // Pines de lectura Xout, Yout int pinX=2 ; int pinY=3 ; // Microsegundos leídos unsigned long Xmicros ;

53

unsigned long Ymicros ; void setup() { Serial.begin(115200) ; pinMode(pinX,INPUT) ; pinMode(pinY,INPUT) ; } void loop() { // Leer la longitud de pulso positivo Xmicros = pulseIn(pinX,HIGH) ; Ymicros = pulseIn(pinY,HIGH) ; Serial.println("X"); Serial.println((Xmicros-5000)/5) ; Serial.println("Y") ; Serial.println((Ymicros-5000)/5) ; }

4.2.3.3 Visualización de los datos Para visualizar los datos se utiliza una aplicación realizada en Processing. El programa abre el puerto serie en el que está conectado el Arduino y lee los datos según el formato expuesto más arriba.

Ilustración 33: boceto inicial del visualizador de datos

54

El funcionamiento del programa es sencillo. Primero hay que enchufar el Arduino al ordenador para que el sistema operativo detecte el puerto USB. Al ejecutar el programa listará los puertos detectados y será suficiente con seleccionar el puerto. Acto seguido, el Arduino se reseteará y comenzará a enviar los datos, que serán leídos por la aplicación (ilustración 34).

Ilustración 34: visualizador inicial, sólo para datos del acelerómetro. Notar los 52 datos/s

Tras 1000 datos recopilados, por los que se pueden navegar mediante los botones con las flechas, se han de borrar los valores mediante el botón “Borrar valores” para adquirir más datos.

55

Ilustración

35:

programa

que

muestra

la

inclinación del Arduino

También se ha desarrollado otro programa que muestra una representación 3D de la posición del sensor (ilustración 35), funcionando simplemente con seleccionar el puerto serie en el que está enchufado el Arduino.

4.2.4 Lectura mediante interrupciones Una gran mejora es leer las señales del Memsic 2125 sin realizar una espera activa en la lectura, es decir, sin utilizar pulseIn() ya que éste realiza la lectura mediante un bucle y mantiene el procesador al 100% de trabajo. Por la forma en que está programada la función pulseIn(), la mitad de las lecturas del Memsic se pierden ya que se leen alternativamente los datos del eje X y el Y y no se puede solapar dicha lectura. La solución propuesta hace uso del Timer/Counter2, con una resolución de 8 bits, a costa de perder la funcionalidad PWM en los pines digitales 3 y 11, y leer los datos mediante interrupciones.

4.2.4.1 Programación 1. Configurar la ejecución de interrupciones Pin Change para los pines en los que se conecta el Memsic (D2 y D3) (en setup()): 56

PCMSK2 |= B00001100 ; // PCINT18-19 (D2,D3) - Pin Change Mask PCICR |= B00000100 ; // Enable PCIE2 - Pin ChangeInterrupt Enable 2

2. Definir la función que servirá la interrupción: //PC en D2-3 = PCINT18,19 de PCINT2_vect(23..16) ISR(PCINT2_vect,ISR_BLOCK) { // Código del servicio }

3. Configurar el Timer 2 para que se ejecute 100 veces por segundo (en setup()) OCR2A = TC2_TOP_VAL ; // Valor máximo de conteo TCCR2A = B00000010 ; // TCT mode TIMSK2 = B00000010 ; //Activar T/C2 Output Compare Match A Interrupt TCCR2B = B00000111 ; // Prescaler de 1024 . Empezar a contar!

4. Definir la función de la interrupción asociada Timer 2 Compare Match A, que se ejecuta cada vez que el Timer/Counter2 llega a TC2_TOP_VAL // Timer 2 Compare Match A ISR(TIMER2_COMPA_vect,ISR_BLOCK) { // Código del servicio }

El valor TC2_TOP_VAL para que se ejecute la interrupción 100 veces por segundo se calcula según la fórmula: #define CICLOS_POR_PWM_HZ (F_CPU/100) #define PRESCALER 1024 #define TC2_TOP_VAL (unsigned char)((CICLOS_POR_PWM_HZ)/PRESCALER)-1

4.2.4.2 Funcionamiento Las señales PWM en los pines 2 y 3 correspondientes al Memsic 2125 se leen mediante las interrupciones de Pin Change, que son ejecutadas cuando cambia el valor de un pin. Para el caso de los pines digitales D2 y D3, la interrupción es PCINT2. Los momentos temporales se guardan en la estructura TimeStamp definida como: typedef struct { unsigned int hi ;

57

unsigned char lo ; } Timestamp ;

Como ejemplo, dentro de la interrupción Pin Change Interrupt 2 (PCINT2) se puede ver cómo la parte ‘hi’ es el valor t2Overflow, que es incrementada por el timer2 cada vez que hay un overflow del valor TOP (ver la ISR de TIMER2_COMPA_vect), y la parte ‘lo’ es el valor del contador: TCNT2. ISR(PCINT2_vect,ISR_BLOCK) { Timestamp tsNow = {t2Overflow, TCNT2} ; ... }

Cuando se detecta que una de las señales en un pin pasa a HIGH, se guarda el timestamp del momento (momento en que se llama a la ISR). Cuando se detecta que una de las señales en un pin pasa a LOW, se calcula el tiempo que ha estado a alta (resta de tiempos) y se indica que el valor ha de ser enviado. En el bucle loop()  se comprueba si hay algún valor para enviar, y en caso afirmativo se envía por puerto serie. La interrupción Pin Change Timer 2 descrita no es suficiente para la lectura PWM porque el Memsic 2125 envía señales constantes LOW o HIGH (en función de la aceleración) cuando tiene mucha aceleración en un eje durante más de 1/100 segundos, por lo que es necesario “cortar” dichos intervalos por software. Aquí es donde entra en juego la interrupción Timer 2 Compare Match A, configurada para ejecutarse 100 veces por segundo. Cada vez que se ejecuta se incrementa el contador t2Overflow para llevar la cuenta de tiempo, y se comprueba si alguna de las señales en un pin lleva demasiado tiempo a HIGH o LOW. Si este es el caso, recarga el timestamp para dicha señal y la marca para enviar. El rango de valores que toman las lecturas es [0 - T2_TOP_VALUE] por que se utiliza un contador de 8 bits.

4.2.4.3 Protocolo de envío de datos El protocolo ha sido modificado para simplificarse, aprovechando que los valores de las lecturas ocupan 1 byte sin signo. Los mensajes son: 58

XYXY...

El código del visualizador de los datos ha sido modificado para adecuarse al nuevo protocolo y para tener en cuenta el valor de T2_TOP_VALUE. El valor para el que la aceleración se considera 0 es T2_TOP_VALUE/2.

4.2.4.4 Resultados Tras las modificaciones, la respuesta a los movimientos es muy notable y mucho más fluida. Se puede observar que el número de datos por segundo recibidos se duplica (ilustración 34 frente a la ilustración 36). El tiempo de CPU utilizado para las lecturas, al ser mediante interrupciones, se ha reducido considerablemente.

Ilustración 36: 102 datos por segundo

4.2.4.5 Consideraciones posteriores Lectura de los pines con las señales PWM Para la lectura de los pines con las señales PWM se ha leído directamente el puerto D (PIND) en la interrupción para ahorrar tiempo: lectura de todos los pines en una sola instrucción, utilización de máscaras de bits para comprobar los puertos afectados,… Los pines digitales D2 y D3 del Arduino se corresponden con los bits 2 y 3 de PIND 59

respectivamente. Ejecución de la interrupción TIMER2_COMPA En la ejecución de la interrupción Timer 2 Compare Match A, el valor de OCRA (Output Compare Register A) es borrado y puesto a 0, por lo que ha de ser recargado con el valor T2_TOP_VALUE cada vez que se ejecuta dicha interrupción. Este no debería ser el comportamiento según lo descrito en el datasheet. Paso a modo idle Se ha aprovechado para poner el Arduino en modo idle de bajo consumo en el bucle principal. Cada vez que ocurre una interrupción el Arduino se despierta, ejecuta la interrupción, envía los datos pendientes y se vuelve a dormir. Para poder pasar a modo idle, hay que incluir la cabecera: #include

Y después, para dormir el Arduino se configura y permite dormir (esto se hace en una instrucción) y se llama a sleep_cpu(). Tras despertarse se recomienda impedir el dormir (para que no pase a modo idle sin querer por algún tipo de error). SMCR = B00000001 ; // Permitir dormir sleep_cpu() ; SMCR = B00000000 ; // Prohibir dormir

El bit 0 de SMCR es el que habilita e inhabilita el pasar a modo de bajo consumo (instrucción sleep). Escritura por puerto serie: bloqueante Un problema añadido es el hecho de que la librería de Arduino tiene implementada la función de envío de caracteres por el puerto serie de manera que es bloqueante. En una ristra de bytes, el envío es bloqueante, excepto el último byte, que no es bloqueante. A 9600 bps, enviar 2 bytes por segundo significa derrochar malamente unos 16500 ciclos, mientras que el hecho de enviar 11 bytes seguidos hace que se desperdicie un 10% de procesador (166 Kciclos). Una mejora es aumentar la velocidad de envío del puerto serie a 115200 bps, de manera que se desperdician 1388 ciclos por byte enviado. Concretamente, a 100 lecturas por

60

segundo por eje, como son 2 bytes por lectura en 2 ejes, en el mejor de los casos se pierde tiempo en 2*100 bytes, y en el peor 3*100, lo que significa un desperdicio de 277 Kciclos y 416 Kciclos: entre un 1,7 y un 2,6% de procesador. Deseable sería, de todos modos, que el envío no fuese bloqueante y pasar el procesador a idle.

4.2.5 Determinación de umbrales de caída Para determinar el umbral de caída hay que tener en cuenta las siguientes cuestiones: • Desconexiones del end device • Añadir un comando que indique al visualizador que el Arduino ha detectado una caída • Características del algoritmo de detección

4.2.5.1 Desconexiones del end device Esta es una cuestión que afecta a la visualización. Hay que tener en cuenta que en cualquier momento puede ocurrir una desconexión del end device. Una desconexión por parte del end device deja, como mucho, un byte corrupto (el resto de datos se pierden), por lo que, si el byte es de indicación de eje, se ignorará, mientras que si es de dato se visualizará una medición errónea. El error no iría más allá de uno o dos datos erróneos (el segundo en la reconexión).

4.2.5.2 Añadir comandos Se aprovechará para modificar el protocolo de comunicación (tabla 4) entre el Arduino y el visualizador. Aprovechando que el rango de valores de los ejes no es 0-255, se irán asignando los números superiores a los diferentes comandos. Esto permitirá un mayor blindaje frente a errores de envío, ya que será más difícil confundir un comando con un valor de eje.

61

Comando dato eje X dato eje Y caída detectada

byte (decimal) 255 254 253

byte (hexadecimal) 0xFF 0xFE 0xFD

Tabla 4: comandos iniciales para visualizar las señales del acelerómetro

Cuando el Arduino detecte una caída informará al visualizador enviándole el byte ’253′. Hay que tener en cuenta que en caso de desconexión, el byte de información de caída no llegará al visualizador, pero esto no es importante por el momento, porque el objetivo es sólo detectar umbrales y algoritmos.

4.2.5.3 Algoritmo de detección El algoritmo para la detección de caídas debería cumplir como mínimo las siguientes características características: • Ser de cálculo rápido • No consumir mucha RAM • Ser robustos frente a posibles valores erróneos aislados de lectura: cuando por algún motivo extraño uno de los valores es de manera llamativa muy superior a todos los circundantes. Una pregunta que surge es: ¿Es necesario tener en cuenta los dos ejes conjuntamente, o se pueden tratar los ejes independientemente? Como primer algoritmo, se propone utilizar un simple umbral de 2g (correspondiente a 2/3 del valor máximo en positivo y negativo de los ejes). Será necesario probar si se ha de verificar en ambos ejes en una ventana temporal el mismo suceso, o simplemente tenerlo en cuenta para un eje. Para la robustez, se verificará una ventana de valores antes y después, para comprobar si es un valor aislado.

4.2.5.4 Preparación de la caja de pruebas de impacto Tras comprobar que el Memsic 2125 funciona correctamente y que es posible su utilización 62

con el Arduino, es momento de preparar una caja acolchada para las siguientes pruebas. Así mismo hay que preparar la circuitería en la que irá conectado el acelerómetro.

Ilustración 37: caja acolchada para la prueba de impactos

Es espacio interior que queda es de un tamaño muy parecido al Arduino, lo que hará que en los impactos no se desplace mucho en su interior. Para conectar el memsic2125 al Arduino se ha creado un shield personalizado (ilustración 38). En el Anexo IV se detalla el shield completo.

Ilustración

38:

shield

personalizado

acelerómetro

63

para

conectar

el

Este shield permite la conexión de 2 Memsic 2125 para el caso de desear controlar 3 ejes, se se colocarían uno en horizontal(slot del medio) y otro en vertical (slot inferior derecha). La orientación de conexión es, en este mismo sentido, con el nombre Mx2125 hacia arriba como se puede observar en la siguiente imagen en la que el shield está conectado al Arduino:

Ilustración 39: shield conectado al Arduino

El acelerómetro que se inserta en horizontal (en la imagen el que está insertado) está conectado a los pines 2(eje X) y 3(eje Y), mientras que el acelerómetro que se inserta en vertical (no conectado en la imagen) está conectado a los pines 4(eje X) y 5 (eje Y). Las resistencias que aparecen en la imagen son de 1Kohm, conectadas a los pines de lectura, como recomienda el datasheet del Memsic[29] (aunque indica 220 ohm, a falta de tales resistencias las de 1K sirven perfectamente). Sobre el shield creado se pueden apilar más shields. En este caso, el XBee (ilustración 40).

64

shield

Ilustración 40: Arduino, shield personalizado con el acelerómetro y XBee shield

Finalmente sólo queda ponerlo en la caja con alimentación externa, conectar la antena y cerrar la caja. Al conectar la alimentación el XBee comenzará a enviar los datos leídos del acelerómetro.

Ilustración 41: todo empaquetado

4.2.6 Algoritmos de detección de caídas Tras el análisis del funcionamiento detallado del Memsic 2125, se analizan posibles algoritmos. El modo de utilizar un acelerómetro lo podemos clasificar en las siguientes categorías: • Para detectar inclinación: el Memsic no es capaz de diferenciar entre aceleración 65

estática (gravedad) utilizada para medir la inclinación y aceleración dinámica, por lo que utilizar un acelerómetro para medir la inclinación sólo es útil si las condiciones de funcionamiento son conocidas, como por ejemplo un dispositivo que se ha de mantener en horizontal. La inclinación en sistemas con mucha aceleración • Detectar colisiones: simplemente se trata de detectar una aceleración muy grande. Puede realizarse midiendo el valor absoluto y considerando colisión al pasar de cierta cantidad de g, o como valor relativo de diferencia de valores en un intervalo de tiempo. En ambos casos lo que se pretende es “detectar el golpe”. Esta detección es apta para sistemas que posean una aceleración limitada y distinguible de golpes. • Detectar caídas: la detección de caídas es algo especial. El detectar caídas con 2 ejes es posible si el acelerómetro está configurado de manera que la gravedad es conocida y no hay efecto de aceleración estática con la que se pueda confundir. En este caso, cuando la medida correspondiente a la gravedad disminuya a 0g significará que el dispositivo está en caída libre, durante todo el tiempo que dure dicha disminución. Es una simplificación muy concreta de un sistema de navegación inercial. • Ser un sistema de navegación inercial: para tener las capacidades de un sistema de navegación inercial se necesitarían 3 ejes y giróscopos para determinar la orientación y discriminar la gravedad. La aceleración se tomaría como el vector diferencia entre el vector medido y el vector gravedad deducido. Tras este análisis, podemos determinar que las opciones, dado que sólo disponemos de un acelerómetro de 2 ejes, se limitan a detectar colisiones como tal (el golpe) y descartar el resto de posibilidades. Aunque existen otras posibilidades dependientes del caso concreto, como por ejemplo monitorizar a una persona en silla de ruedas, vamos a proponer aquellas soluciones que parecen más genéricas. En el caso de la silla de ruedas, por no dejar con la duda, es posible que la solución más sencilla sea la de detectar inclinación para el caso de una caída.

4.2.6.1 Algoritmo 1 Detección de caídas basándose en la colisión, midiendo el valor absoluto del golpe: cuando 66

la aceleración detectada es mayor que un determinado valor, se considera caída. En el caso de que la aceleración deseada sea de 2G, el algoritmo sería: boolean verificarCaida1 (ArrayCircular& a) { if(a.getLast()>TC2_TOP_VAL*6/8 || a.getLast()=a.numElements()-TIMESTEPS ; --i) {

67

if (a.get(i)>max_val) max_val=a.get(i) ; if (a.get(i) COLISIONACC) { return true ; } return false ; }

El algoritmo lo que hace es: para los últimos valores (los 20 últimos en el ejemplo) comprueba si el incremento de aceleración es mayor que cierto valor (aceleración de colisión COLISIONACC). • Ventajas: es independiente de la gravedad. El único caso en el que la gravedad influye es en el caso de que el acelerómetro rote rápidamente, de manera que la gravedad pase a hacer efecto, al mismo tiempo que recibe un impacto, es posible que el efecto final se considere colisión. • Desventajas: es más complicado porque hay que determinar 2 variables: el número de timesteps y la aceleración de colisión, que si bien ambos definen una única derivada, el intervalo de tiempo sigue siendo necesario que esté definido.

4.2.7 Prueba de algoritmos 4.2.7.1 Algoritmo 1 Se ha procedido a evaluar diferentes situaciones. Como primeras pruebas, el parámetro de colisión se ha configurado a 2 g (valor 38). Las primeras pruebas son caídas desde 30 cm partiendo de una posición horizontal, en la que los acelerómetros no marcan nada.

68

Ilustración 42: caída de 30 cm desde posición horizontal

Ilustración 43: caída desde 30 cm sobre cojín

69

Como se puede observar en las las ilustraciones 42 y 43, en ambos casos la colisión se detecta como aceleraciones mayores de 2 g en alguno de los ejes. En la ilustración 44 se muestra la señal para una caída realizada con el acelerómetro en vertical. Se puede apreciar la caída como un valle que tiende hacia 0 g y la posterior colisión marcada en rojo.

Ilustración 44: caída de 30 cm desde posición vertical

Así mismo, las caídas desde 90cm presentan unos resultados similares (ilustración 45) a los vistos en caídas desde 30 cm.

70

Ilustración 45: caída desde 90 cm partiendo de posición horizontal

Las siguientes gráficas muestran actividades normales que conllevan cierto movimiento teniendo el monitor a la altura de la cadera pegado al cuerpo. La ilustración 46 muestra una caída sobre el suelo (golpe realista). El movimiento normal no se considera colisión, mientras que lo marcado en rojo es el choque contra el suelo.

71

Ilustración 46: caída realista sobre el suelo

La ilustración 47 muestra el efecto de sentarse en una silla más o menos como peso muerto.

Ilustración 47: sentarse como peso muerto

72

Las ilustraciones 48 y 49 muestran acciones normales como caminar y barrer (respectivamente).

Ilustración 48: caminando

73

Ilustración 49: barriendo

4.2.7.2 Algoritmo 2 Como prueba para el algoritmo 2 se han utilizado los siguientes parámetros: • timesteps a tener en cuenta: 15 • aceleración máxima tolerable: 2 g (38) , más implica colisión En las ilustraciones 50 y 51 se puede observar cómo no hay diferencia con respecto al algoritmo 1 en cuanto a la detección de caídas desde 30 y 90 centímetros sobre un cojín, ya que los valores de colisión son demasiado grandes como para poder ser discriminados mediante alguno de los dos algoritmos.

74

Ilustración 50: caída desde 30 centímetros sobre cojín

Ilustración 51: caída vertical de 90 cm sobre cojín

75

La diferencia que se aprecia es que las zonas marcadas en rojo como colisión son más anchas porque considera colisión lo que corresponde a una ventana de tamaño configurado (en este caso, 15 timesteps). Se puede apreciar sobre todo en la última imagen cómo la ventana puede que sea demasiado grande, y comprobamos que tal vez para colisiones sea suficiente una ventana de 7 timesteps (o incluso menos). Durante las pruebas de este algoritmo se ha dado un caso de interés en la prueba de caminar (ilustración 52). Al ser éste el segundo algoritmo, no se ve afectado por el hecho de que el eje Y esté centrado sobre -1 g (gravedad). La colisión detectada, que supera los -2 g, en realidad es una aceleración de 1 g en el mismo sentido de la gravedad, pero con los parámetros configurados es detectado como colisión por el algoritmo 2.

Ilustración 52: caminando. Falso positivo.

Resulta un falso positivo inevitable en el algoritmo 1, pero totalmente evitable en el algoritmo 2. En la ilustración 53 se muestra la causa.

76

Ilustración 53: Causa del falso positivo, que ayuda a configurar la ventana de timesteps

En verde está marcada la ventana de aceleración. Disminuyendo a la mitad la ventana (7 timesteps) ya no se detectaría este falso positivo, y sí se detectarían los verdaderos positivos de los ejemplos anteriores, en los que también se sugería una reducción de los timesteps. Además, aumentar la aceleración a 2,2 g, o incluso 2,5 g proporcionaría todavía mayor robustez. Nuevos parámetros: • timesteps: 7 • aceleración: 2,5 g (48) Se han repetido algunas pruebas. La ilustración 54 muestra la señal recibida al sentarse en una silla cayendo como “peso muerto” (es decir, si te sientas en una silla un poco bruscamente).

77

Ilustración 54: sentándose en una silla. Algoritmo 2 con los nuevos parámetros

El pico en el eje Y que no se considera colisión (el algoritmo1 sí que lo consideraría) ya que la caída ha sido de casi 2,5 g. En la ilustración 55 se analiza el comportamiento del algoritmo 2.

78

Ilustración 55: Análisis de la caída

En verde está la mayor caída, que en la ventana de 7 timesteps es de unos 2 g. En azul la recuperación, que en la ventana de 7 timesteps es de 1,5 g. Concluimos que la caída no era muy peligrosa (y es que, efectivamente, no era peligrosa). La prueba de caminar se muestra en la ilustración 56.

79

Ilustración 56: caminando. Algoritmo 2

Caminar no presenta ningún problema. El algoritmo 1 habría considerado una colisión en el pico prominente que supera los -2 g, y es posible que el algoritmo 2 con los parámetros iniciales también lo considerase colisión (la diferencia parece ser de unos 2 g, aunque tal vez por poco no lo sea). Esta vez no aparece ese falso positivo. Por último, la ilustración 57 muestra una caída real sobre unos cojines (pero caída).

80

Ilustración 57: caída de verdad

4.2.7.3 Conclusión Sin ninguna duda, el algoritmo 2 con los últimos parámetros (timesteps:7 y aceleración: 2,5 g) parece ser un algoritmo aceptable para detectar colisiones genéricas sin que se vea afectado por tareas normales. Aún sin pretender ser repetitivo, es necesario recordar que para usos concretos siempre estaría bien considerar otros algoritmos más específicos para la situación de trabajo.

81

4.3 - Localización en exteriores (GPS) Para incluir la funcionalidad del GPS en el dispositivo se utilizará el módulo GPS de Libelium que posee el circuito integrado A1037-A. La conexión al Arduino es sencilla: se conecta el módulo a los pines 8-13, y un cable externo de alimentación (también desde el Arduino). La comunicación se realiza mediante puerto serie, por el que se leen los comandos MNEA con la información de posición. Para tal fin, se utiliza la librería de Libelium, creada por D. Cuartielles. En el caso concreto del módulo que estamos utilizando, la información de firmware es: $PSTMVER,GPSLIB_04.30.03+PAL ARM - Jul 28 2006 12:23:26,SW COMMANDS rel.1.0 (Aug 07 2006 09:16:31)*6a

4.3.1 Librería de Libelium Tras descargar la librería25, para instalar la librería de Libelium simplemente hay que copiar la carpeta /LB_GPS del .zip descargado en /Arduino/libraries, y de este modo estarán disponible automáticamente en el editor de Arduino tanto la librería como los ejemplos.

Ilustración 58: librería GPS correctamente instalada

82

Ilustración 59: los ejemplos que vienen con la librería GPS

La librería de Libelium declara un objeto global GPS cuya clase es LB_GPS. El GPS se ha de inicializar mediante la función init(), a la que opcionalmente le podemos pasar unas coordenadas y la hora para realizar un “inicio en templado”. El modo de comunicación con el Arduino se configuraría mediante setCommMode(). Las opciones son: por software o por hardware, pero actualmente el módulo sólo funciona por software. Los pines de comunicación se configuran en el fichero LB_GPS.h: // GPS Software Serial pins #define GPS_RX 9 // default RX pin for the software serial method #define GPS_TX 8 // default TX pin for the software serial method

Se puede reiniciar, apagar y dormir el GPS mediante la función setGPSMode(). Cuando se reinicia, el modo de reinicio puede ser en “caliente”, “templado” o “frío”: • Inicio en caliente (Hot Start): El receptor GPS recuerda su última posición calculada, qué satélites estaban a la vista, el almanaque utilizado y la hora UTC. Realiza un reset y trata de encontrar los satélites y calcular la nueva posición en base a su información previa. Es el método más rápido de calcular la nueva posición. • Inicio en templado (Warm Start): El receptor GPS recuerda su última posición calculada, el almanaque usado y la hora UTC, pero desconoce qué satélites estaban a la vista (efemérides). Realiza el reset y trata de detectar la señal de los satélites y calcular la nueva posición. El receptor tiene una idea general de qué satélites buscar porque conoce 83

su última posición y el almanaque ayuda a identificar qué satélites son visibles en el cielo. Se tarda más que con un inicio en caliente, pero no tanto como en frío. • Inicio en frío (Cold Start): El receptor descarta toda la información almacenada, y tras el reseteo trata de encontrar los satélites y calcular su posición. Es el método que más tarda porque no tiene nada de información y el receptor trata de leer información de todos los satélites mediante polling, cosa que lleva mucho más tiempo que saber qué satélites buscar. Este método puede llevar hasta 20 minutos. La librería no permite cambiar el modo de reinicio, y simplemente presupone que el módulo llevará a cabo un reinicio en caliente. Al establecer el modo ON mediante setGPSMode(), lo que se realiza es un simple reset. Mirar el apartado de bugs y modificaciones en el Anexo V para ver el código añadido. Para leer la información de posición hay 3 maneras: • Leer la información de caché del objeto, mediante los atributos públicos (char*)coordinates, (float) latitude, (float) longitude, (float) speed, (float) altitude, (float) course, que guardan el valor de la última lectura. • Leer la información llamando previamente a getLocation(), que actualizará las variables anteriores. Al mismo tiempo, la función dataValid() indicará si los datos leídos mediante getLocation() eran válidos y por lo tanto los atributos han sido actualizados, o no. • Establecer el tipo de mensajes a recibir con GPS.setSentences(), leer un mensaje con GPS.getRaw() y parsearlo con GPS.GPSStringExplode(GPS.inBuffer,’,') de manear que los tokens estarán en el array GPS.arguments[].

4.3.2 Probando el GPS En montaje del dispositivo se muestra en la ilustración 60, donde está todo conectado: el shield personalizado con el acelerómetro en vertical, el XBee y el GPS.

84

Ilustración 60: Arduino + acelerómetro + ZigBee + GPS

El acelerómetro se leerá en los puertos 4 y 5, mientras que el GPS se leerá por software en los puertos 8 y 9. El siguiente código ha de enviar al ordenador, utilizando el puerto serie del Arduino, las sentencias GGA: #include "LB_GPS.h" void setup(){ Serial.begin(19200); Serial.println(GPS.getLibVersion()); // GPS warm-up time delay(1000); // Localización inicial en mi librería: Betanzos GPS.init(); GPS.setDate("01,03,2011");

85

GPS.setTime("11,00,00"); // done! Serial.println("done!"); } void loop(){ Serial.println(GPS.getRaw(100)); delay(5000); }

Tras realizar pruebas y llegar a la conclusión de que el cable de conexión de la antena del GPS estaba defectuoso (el de color blanco conectado al módulo GPS), el GPS ha encontrado hasta 6 satélites. En la ilustración 61 se muestran las sentencias GGA recibidas.

Ilustración 61: sentencias GGA recibidas

El significado de los campos marcados es: • Hora UTC: 123101 = 12:31:01 • Latitud: 43º 21,118 minutos N • Longitud 8º 23.506 minutos W • 1 : Valor GPS válido

86

• 05: 5 satélites a la vista • 11.8: Dilución de precisión horizontal (en este caso, medida “pasable”) • 54.7: Altura de la antena en metros. Podemos consultar el log para extraer conclusiones sobre el funcionamiento: V01a-fix done! GPGGA,105949.000,4328.193,N,00821.111,W,0,00,99.0,053.0,M,53.0,M,, [1] ... GPGGA,110530.000,4328.193,N,00821.111,W,0,00,99.0,053.0,M,53.0,M,, [2] GPGGA,115321.000,4328.193,N,00821.111,W,0,00,99.0,053.0,M,53.0,M,, [3] GPGGA,115352.000,4328.193,N,00821.111,W,0,01,99.0,053.0,M,53.0,M,, [4] ... GPGGA,122245.000,4328.193,N,00821.111,W,0,01,99.0,053.0,M,53.0,M,, [5] GPGGA,122316.000,4328.193,N,00821.111,W,0,02,99.0,053.0,M,53.0,M,, [6] ... GPGGA,122622.000,4328.193,N,00821.111,W,0,02,99.0,053.0,M,53.0,M,, [7] GPGGA,122653.000,4328.193,N,00821.111,W,0,04,31.0,053.0,M,53.0,M,, [8] GPGGA,122724.000,4320.986,N,00823.543,W,1,04,29.9,041.4,M,52.9,M,, [9] GPGGA,122755.000,4321.017,N,00823.519,W,1,04,28.5,0012.9,M,52.9,M,, GPGGA,122826.000,4321.060,N,00823.507,W,1,05,10.3,0046.4,M,52.9,M,, GPGGA,122857.000,4321.088,N,00823.504,W,1,05,10.6,0053.1,M,52.9,M,, ... GPGGA,123305.000,4321.115,N,00823.503,W,1,05,12.3,0057.8,M,52.9,M,, GPGGA,123336.000,4321.123,N,00823.503,W,1,06,1.7,0053.6,M,52.9,M,, [10] GPGGA,123407.000,4321.132,N,00823.504,W,1,07,1.3,0049.1,M,52.9,M,, GPGGA,123438.000,4321.134,N,00823.505,W,1,06,1.9,0045.3,M,52.9,M,, ... GPGGA,124733.000,4321.131,N,00823.508,W,1,05,2.0,0066.5,M,52.9,M,, GPGGA,124804.000,4321.131,N,00823.508,W,1,04,2.5,0067.4,M,52.9,M,, GPGGA,124835.000,4321.130,N,00823.508,W,1,04,2.5,0067.7,M,52.9,M,, GPGGA,124906.000,4321.130,N,00823.507,W,1,04,2.4,0069.4,M,52.9,M,, GPGGA,124937.000,4321.134,N,00823.508,W,1,03,9.2,0070.6,M,52.9,M,, GPGGA,125008.000,4321.133,N,00823.508,W,1,03,8.8,0070.4,M,52.9,M,,

Las coordenadas iniciales añadidas al código de la librería son las correspondientes a Betanzos ( 4328.193,N,00821.111,W), y aparecen a partir de [1].

87

Notar que antes de indicar que ha encontrado 1 satélite ([4]), actualiza la hora al horario UTC ([3]). El tiempo de adquisición del primer satélite fue de unos 7 minutos. El tiempo hasta adquirir 4 satélites ([8]) fue de unos 40 minutos, a pesar de que el valor es inaceptable (error más o menos 30), pero ya marca el dato “fix” como 1, que significa “válido” ([9]). El tiempo de adquisición de 6 satélites ([10]) y comenzar a calcular un posicionamiento considerado “excelente” es de unos 45 minutos. Los valores de error menor de 2 (excelente) aparecen cuando se encuentran 6 o más satélites, aumentando el error hasta casi 10 al perder satélites y quedarse con 3. La medición con 4 satélites, tras tener 6 satélites previamente, se mantiene en “buena” con un valor de error entre 2 y 3. Comentar que, a pesar de que el GPS indica un valor “excelente”, comprobando en Google Maps[30] y SIGPAC[31], muestra un error de unos 30 metros.

4.3.3 Coordenadas en Google Maps Al tratar de visualizar coordenadas en Google Maps, si se utiliza directamente el valor devuelto por el GPS se comprobará que no son coordenadas aceptadas, y en el supuesto caso de que simplemente cambiemos el punto decimal de las coordenadas detrás de los grados (4321.133N a 43.2133N,o incluso 43º 21′ 133”N) nos dará la sensación de que el GPS posee muy poca precisión. En todos los casos, se ha de seguir el valor de coordenada con N,S,E,W, o anteponer la coordenada con el signo menos ‘-’ en el caso de que sea sur(S) u oeste(W) si se omite la letra de punto cardinal. El formato que devuelve el GPS es el siguiente: • Para latitud: GGMM.MMMMM. Es decir, las 2 primeras cifras para grados y el resto son los minutos en decimal. • Para longitud: GGGMM.MMMMM. Es decir, las 3 primeras cifras para grados y el resto 88

son los minutos en decimal. El formato aceptado por Google Maps son 3: • Posición en grados decimales: 43.352216 • Posición en grados, minutos y segundos: 43º 21′ 8” • Un tercer modo que se describe más abajo Ambos ejemplos anteriores corresponden al valor del GPS 4321.133 ¿Cómo funciona la conversión? Lo único que hay que tener en cuenta es que 1 grado decimal son 60 minutos y 1 minuto son 60 segundos. Por ello, para pasar de grados-minutos-segundos a grados decimales, la operación es: grados+minutos/60+segundos/3600. El tercer modo es aprovechar que Google Maps realiza la conversión entre grados-minutossegundos y grados decimales automáticamente, de manera que le indicamos los grados y los minutos decimales: 43º21.133′N; la conversión a este formato desde el valor recibido del GPS es algo sencillo.

4.3.4 Actualizando el protocolo para visualizar la información de posición Para que el visualizador pueda mostrar información del GPS hay que actualizar el protocolo de comunicación entre el Arduino y el visualizador. Para ello, se añadirán los siguientes comandos: Comando

byte (decimal) 248 247

byte (hexadecimal) 0xF8 0xF7

Satélites a la vista

246

0xF6

Precisión horizontal

245

0xF5

Latitud Longitud

formato ggmm.mmmmm(N|S)\n gggmm.mmmmm(E|W)\n número\n (entero en forma de cadena de texto) número\n (flotante en forma de cadena de texto) número\n

Altura

Dato válido

244

0xF4

243

0xF3

(flotante en forma de cadena de texto) (1 | 0)\n (cadena de texto)

Tabla 5: actualización del protocolo para visualizar los datos de posición

89

Por otro lado, el Arduino aceptará un comando para pedir la actualización de estos datos (y que los envíe al visualizador): Comando Datos GPS

byte

byte

(decimal)

(hexadecimal)

242

0xF2

parámetros Enviar el siguiente byte: 0×01. Pide toda la información GPS

Tabla 6: comando enviable al Arduino para pedir los datos de posición

4.3.5 Utilizando el GPS En el visualizador se ha añadido una pestaña que muestra la información del GPS bajo demanda (botón 'Refrescar' mostrado en la ilustración 62).

Ilustración 62: pestaña de visualización GPS con los datos no actualizados

La información que se muestra al refrescar es: la latitud, la longitud, los satélites a la vista, la precisión horizontal (buena medida entre 1 y 3), la altura en metros y si la posición se considera válida o no. En caso de haber perdido la conexión con los satélites se mostrará la última posición, aunque el valor de “Dato válido” será “No”. 90

Como se puede ver en la ilustración 63, el dato es válido (Dato válido: sí) con 4 satélites, una precisión 2.8 (buena) y se muestra la posición del GPS.

Ilustración 63: dato válido: sí. Posición actualizada y correcta

En la ilustración 64 se puede ver que al perder satélites y tener menos de 3, el dato no es válido pero el GPS devuelve información útil, como se comentó antes.

91

Ilustración 64: aunque el dato sea inválido, la posición se recuerda

El mapa estático mostrado se pide a Google Maps.

4.3.5.1 Cómo pedir mapas estáticos a Google Maps Pedir mapas estáticos es la manera más sencilla de obtener una imagen de la posición. Se realiza una petición a “http://maps.google.com/maps/api/staticmap?” de manera que se indica la posición mediante el parámetro markers, el zoom deseado mediante zoom, el tamaño de la imagen, el formato (jpg en nuestro caso), el tipo de mapa (roadmap) y también se indica si la posición se ha obtenido mediante un sensor o no. http://maps.google.com/maps/api/staticmap?&markers=color:blue| 43.27437N,8.21747W&zoom=14&size=400×520&format=jpg&maptype=roadmap &sensor=true

Para mostrarlo en el visualizador se hace uso de las funcionalidades de Processing: se carga un objeto de clase PImage mediante requestImage() pasándole la URL anterior, y se muestra mediante una llamada a image() pasándole el objeto de clase PImage.

92

4.4 - Monitorización de constantes vitales (pletismógrafo) Un pletismógrafo es un dispositivo utilizado para medir el volumen de órganos animales. Dichos cambios de volumen se detectan en base a fluctuaciones de líquidos o gases, generalmente aire o sangre. Debido a que los pletismógrafos permiten controlar el bombeo de sangre, es posible monitorizar el pulso en personas dependientes. Existen diversas formas de implementar un pletismógrafo, pero nosotros nos ceñiremos a las noinvasivas, para evitar infecciones o intervenciones quirúrgicas de cualquier tipo. Hay a la venta circuitos comerciales de tipo no-invasivo[32], pero es realmente sencillo montar uno de manera muy barata. Tras realizar muchas pruebas en la placa de prototipos, las especificaciones concretas para conseguir la lectura del pulso son las siguientes: •

Emisor infrarrojo LTE-302

•

Receptor infrarrojo LTR-301

•

Resistencia en serie con el emisor: 220Ohm

•

Resistencia en serie con el receptor: 10KOhm, montaje en inversor

•

Emisor y receptor coplanares apuntando al mismo sentido, y no contrapuestos en puntos contrarios del dedo.

•

Espacio entre sensores: 6mm. Espacio entre centros (del centro del LED donde emite, al centro del sensor, done recibe): 1cm. No se ha llegado a determinar la distancia óptima.

•

Colocación del dedo: yema de la última falange longitudinalmente con el LED emisor cercano a la articulación. Apenas sin presión. Con presión, es posible que la sangre no sea capaz de cambiar su volumen y por ello no se detecta. La detección en la segunda falange resulta muy débil; la luz parece llegar con poca intensidad en este caso.

4.4.1 Montaje La ilustración 65 muestra las medidas de separación entre emisor y receptor comentadas más 93

arriba.

Ilustración 65: medidas de separación entre emisor LED y sensor

El pletismógrafo se ha de alimentar con 5V provenientes del Arduino, y la lectura se realiza en el puerto analógico 0. La ilustración 66 muestra el esquema del circuito.

Ilustración 66: esquema del circuito del pletismógrafo

En la ilustración 66 se muestra el pletismógrafo montado sobre una tira de velcro conectado al Arduino.

94

Ilustración 67: pletismógrafo conectado al Arduino

La mejor posición es colocar el sensor en la 3ª falange, con el emisor bastante cerca de la articulación y el receptor hacia la punta del dedo. Con algo de presión, ya que la tira de velcro tiene cierta elasticidad.

Ilustración 68: pletismógrafo colocado en el dedo

4.4.2 Software para la lectura asíncrona La lectura del pletismógrafo se realiza a una frecuencia fija de 30Hz (aunque se podría a 50 Hz, 100Hz o más) utilizando el modo de bajo ruido de lectura analógica del Arduino (para lo que es 95

necesario dormirlo). Se puede realizar la lectura en modo normal, aunque el propio trabajo que esté realizando el Arduino puede introducir cierto ruido. Para iniciar conversiones a intervalos regulares, el Timer1 está configurado en modo CTC match ICR1. Con ICR1=65535, se ejecuta la interrupción a 30Hz; con ICR1=20000 se ejecuta la interrupción a 100Hz. El Timer1 se ha de configurar para ejecutar la interrupción TIMER1_CAPT_vect cuando TCNT1 llegue al valor en ICR1, y al mismo tiempo se resetee al llegar a dicho valor: TIMSK1 = B00100000 ; // 00,ICR1 match interrupt:1,00,match B int:0, match A int:0, Overflow interrupt: 0 TCCR1A = B00000000 ; ICR1= 65535 ; // 20000(p8)=> 100Hz con prescaler 8 TCCR1C = B00000000 ; TCCR1B = B00011010 ; // 00-,Modo CTC con ICR1: 11, prescaler de 8:010

El módulo de conversión A/D se configura para utilizar como referencia los 5V del Arduino, leer del puerto A0, utilizar el menor prescaler de reloj con el fin de tener lecturas de 10bits que permiten una sensibilidad de 4mV, y ejecutar la interrupción ADC_vect cada vez que se termina una conversión. ADMUX = B01000000 ; // REF:01, ADLAR:0,0,ADC0:0000 DIDR0 = B00111111 ; // Disable digital inputs, menor ruido y consumo ADCSRB = B00000000 ; ADCSRA = B10001111 ;// Enable:1,Start:0,Autotrigger:0,Interrupt flag:0 // Interrupt enable:1, prescaler:111

La interrupción TIMER1_CAPT_vect (lanzada 30 veces por segundo en este caso) es la encargada de iniciar las conversiones. En el siguiente código se indica también cómo iniciar la conversión sin entrar en modo de bajo ruido: ISR(TIMER1_CAPT_vect ,ISR_NOBLOCK) { SMCR = B00000011 ; // 0000, ADC noise reduction: 001, sleep enable:1 sleep_cpu() ; // Al dormir, se inicia automáticamente la conversión, gracias a la configuración en SMCR SMCR = B00000000 ; // power mode idle:000, sleep disabled:0

96

//

Se

puede

iniciar

una

conversión

sin

entrar

en

modo

sleep

de

conversión A/D de bajo ruido mediante // ADCSRA |= B01000000 }

Al terminar cada conversión se ejecuta la interrupción ADC_vect, donde se puede leer el valor de la conversión accediendo al registro ADC (16 bits) o a ADCH + ADCL: ISR(ADC_vect,ISR_NOBLOCK) { uint8_t analogLow = ADCL ; uint8_t analogHigh = ADCH ; Serial.print(0xF1,BYTE) ; // Envío del comando con el dato leído al visualizador Serial.print(analogHigh) ; Serial.print(analogLow) ; }

Ilustración 69: señal del pletismógrafo leída por el Arduino

97

La señal de la ilustración 69 muestra un salto de 4-5 unidades (16-20mV) en 3-4 unidades de tiempo. Esto se utiliza para detectar las pulsaciones.

4.4.3 Algoritmo de medida de las pulsaciones Para medir las pulsaciones primero se desarrolla un método para detectar cada pulsación. Para calcular las pulsaciones en un minuto y obtener una medida rápido, una opción es leer durante 7,5 segundos y multiplicar por 8, o leer durante 15 segundos y multiplicar por 4. En nuestro caso se utilizan las lecturas durante 7,5 segundos. Para poder visualizar la información, el protocolo de comunicación entre el Arduino y el visualizador es el siguiente: Comando Dato pulsación Número

Byte

formato (hexadecimal) 0xF1 0xF1

pulsaciones Pulsación detectada

0xF0

0xF0

0xE9

0xE9

Tabla 7: protocolo para visualizar los datos del pletismógrafo

4.4.3.1 Detección de una pulsación El método de detección es dependiente de la frecuencia de muestreo. A 30Hz la señal tarda entre 2 y 4 ticks en pasar del mínimo valor al máximo con cada pulsación. El algoritmo utilizado guarda el incremento acumulado de los últimos 4 ticks. Es un método eficiente para calcular el incremento acumulado en O(n): volatile uint8_t beats = 0 ; // Pulsaciones contadas en un intervalo de 7.5 segundos volatile uint8_t ticks = 0 ; // Lecturas del pletismógrafo realizadas. En 7.5 segundos serán 225 volatile uint8_t ticks_new_beat = 0 ; // Número de lecturas realizadas entre pulsaciones. Utilizaremos un mínimo de 10 ISR(ADC_vect,ISR_NOBLOCK) {

98

static uint16_t old_value = 0; static int8_t valores[4] = {0,0,0,0} ; // Guardará las derivadas de los últimos 4 valores con los 4 anteriores int8_t derivada = ADC - old_value; // Incremento del valor respecto del tick anterior old_value = ADC ; for (int i=1; i10) { Serial.print(BEAT,BYTE) ;

// Enviar el comando que informa de que se ha

detectado una pulsación beats++ ;

// Incrementamos el número de pulsaciones

detectadas ticks_new_beat=0;

// Reseteamos el contador de manera que no

leemos dos veces una misma pulsación }

En cada lectura del pletismógrafo se actualizan los contadores necesarios: // Timer1 que desencadena la lectura del pletismógrafo ISR(TIMER1_CAPT_vect,ISR_NOBLOCK) { ticks++ ; ticks_new_beat++;

99

// Opción de lectura de bajo ruido, durmiendo el Arduino // SMCR = B00000011 ; // ADC noise reduction: 001, sleep enable:1 // sleep_cpu() ; // SMCR = B00000000 ; // power mode idle:000, sleep disabled:0 // Opción de lectura sin dormir ADCSRA |= B01000000 ; }

Finalmente, cada 7,5 segundos se envía el valor que indica el número de pulsaciones: // Cada 30Hz * 7.5 segundos = 225 ticks if ((uint8_t)ticks>=(uint8_t)225) { beats*=8 ; // Multiplicamos por 8 el número de pulsaciones detectadas en 7.5 segundos Serial.print(NUMPULSACIONES,BYTE)

;

//

Comando

de

"numero

pulsaciones" Serial.print(beats,BYTE) ; beats=0; // Reiniciar el contador de pulsaciones leídas ticks=0; // Reiniciar el contador de frecuencia de envío }

Ilustración 70: Visualizador mostrando 80 pulsaciones por minuto (calculado por le Arduino)

100

de

4.4.4 Bugs y problemas con la lectura del pletismógrafo Los microcontroladores ATmega168 y Atmega328 (sólo se ha comprobado en estos), presentan los siguientes problemas: • La asignación de un valor a OCR1A antes de asignar un valor a TCCR1A implica que OCR1A será borrado en la asignación de un valor a TCCR1A. • El modo CTC mediante match OCR1A: 01 en TCCR1B no funciona. • Si el módulo de conversión está activado (ADCSRA:7 = 1), entrar en modo sleep IDLE inicia una conversión A/D, cuando no debería.

101

4.5 - Visualizador desarrollado El visualizador de datos está desarrollado en Processing[28]. Para utilizarlo simplemente hay que descargarlo[33] y descomprimirlo. Se programa en java, y dispone de una serie de librerías para facilitar el dibujo en 2D y 3D, interacción con el usuario (ratón y teclado), reproducción de vídeo, conexión de red y puerto serie, generación de PDFs,... Está diseñado para ser ejecutado como aplicación, como applet en una página web, o en dispositivos con sistema operativo Android.

Ilustración 71: interfaz de Processing

102

Al pinchar en el icono “Run”

, se ejecuta el programa.

La pantalla inicial que aparece es la correspondiente a la pestaña “Acelerómetro”, que muestra los datos del acelerómetro.

Ilustración 72: pestaña inicial, con los datos del acelerómetro

En la columna derecha de la ilustración 72 aparecen listados los puertos USB disponibles. Al pinchar en uno de los puertos (en el que esté el Arduino), el visualizador se conecta a dicho Arduino reseteándolo. Es posible recargar la lista de USBs mediante el botón “Rescan USB”, ya que si el Arduino se conecta después de abrir el visualizador, su puerto USB no aparece en el listado. Los distintos visualizadores tienen un buffer de manera que es posible navegar por datos anteriores mediante los botones de desplazamiento. Cuando dicho buffer se llena es necesario pinchar en el botón “Borrar valores” para que se vacíe el buffer y se añadan los siguientes datos. Para el acelerómetro es posible escoger el algoritmo de detección de caídas. Por defecto está 103

configurado el Algoritmo 2 (visto en el apartado del acelerómetro).

La pestaña “GPS” (ilustración 73) permite visualizar la posición mediante el Google Maps. Sólo posee un botón: “Refrescar”, y al pinchar en él se actualiza la información del GPS en el visualizador y se pide la imagen satélite al Google Maps.

Ilustración 73: pestaña con los datos del GPS

La pestaña “Pulsaciones” (ilustración 74) muestra la gráfica con los datos del pletismógrafo, las pulsaciones por minuto calculadas y parpadea en rojo el cuadro de pulsaciones con cada pulsación detectada.

104

Ilustración 74: pestaña con los datos del pletismógrafo

105

4.6 - Sobre el consumo de batería del Arduino ¿Cuánto dura el Arduino sin cambiar/recargar la batería? El ATmega168 consume 9.5mA a 5V y 16 MHz. Utilizando una batería de 9V recargable de 200 mA, debería durar unas 21 horas. En modo idle(inactivo) consume 2.4mA, lo que permitiría que la misma batería durase unas 83 horas: 3 días y medio. Sin embargo, esto se aleja de cualquier realidad simplemente por el hecho de que el Arduino lleva el regulador de voltaje MC33269-5G, que posee un consumo en torno a los 5.5mA. Por ello, no se puede esperar que mi batería de 200mA dure más de 13 horas con el Arduino en activo, ni más de 25 con el Arduino en idle. Adicionalmente, el XBee Shield y el GPS Shield poseen cada uno su propio regulador de voltaje, que habría que unificar y utilizar uno de bajo consumo.

4.6.1 Posibles soluciones Con el fin de alargar la vida del Arduino con sólo 200mA entre las medidas a tomar hay 2 importantes: Sustituir el regulador de voltaje Habría que utilizar un regulador de voltaje ultra low-quiescent, es decir, de bajo consumo en inactivo (y por lo tanto poco consumo). El MC78LC00H consume sólo 1.1 μA, el MCP1702 con un consumo de 2 μA, o alguno de la serie TPS72xx con un consumo de 180 μA. Reducir la frecuencia del microcontrolador Utilizando el modelo ATmega168V a 1.8V y 1 MHz, el consumo en activo es de 0,25 mA. Esto permitiría que la batería dure unas 800 horas: unos 33 días. El consumo en idle es de 0.04 mA, que se traduce en 5000 horas de funcionamiento: unos 200 días.

106

4.6.2 Conclusión Los cálculos sugieren que sería factible el desarrollo de un producto basado en el microcontrolador del Arduino (concretamente el Arduino LyliPad se basa en el ATmega168v a 1.5V) que dure bastante tiempo, si se dispone de una batería de mayor capacidad y se aprovecha correctamente la posibilidad de poner el micro en modo idle de bajo consumo.

107

108

Capítulo 5. Conclusiones En este proyecto se ha construido un dispositivo capaz de leer los datos de un acelerómetro de 2 ejes y un pletismógrafo, tratar las señales, y en caso de detectar una anomalía avisar a un receptor. Los avisos son enviados por métodos inalámbricos, y es posible enviar la geolocalización. Gracias al presente trabajo se han estudiado los distintos módulos implicados, y se han integrado en un único dispositivo desarrollando un software específico para ello. A pesar de basarse inicialmente en la plataforma Arduino, ha sido necesario utilizar funcionalidades del microcontrolador para las que la plataforma Arduino no posee soporte en sus librerías. Sobre los elementos que conforman el dispositivo final, se exponen las valoraciones y dificultades:

5.1 Sobre el acelerómetro El acelerómetro Memsic2125 posee la gran ventaja de tener un bajo coste. El que sólo mida la aceleración en 2 ejes no parece ser un impedimento para detectar caídas (de todos modos habría que investigar más profundamente este punto). El hecho de que las señales de los ejes estén codificadas en formato PWM es una desventaja porque el Arduino sólo dispone de un Timer/Counter con captura, lo que fuerza a tener que realizar por software la lectura de varias señales simultáneamente, cuestión que ha causado múltiples problemas. Con un microcontrolador con varios Timer/Counter con captura (ATmega128/640/1280/2560) la lectura de señales PWM se convierte en algo trivial y sencillo. Otros acelerómetros disponibles en el mercado codifican las señales de los ejes como valores de voltaje, y el Arduino está capacitado para adquirir hasta 10.000 muestras por segundo. Es posible que este enfoque resultase en medidas con menor ruido, mayor sencillez y permitir tener el Arduino en modo dormido. Por último, quedaría comparar el consumo de energía del Memsic2125 frente a otras opciones.

109

5.2 Sobre el pletismógrafo El pletismógrafo desarrollado no parece muy apto para un uso real. Es un poco sensible a movimientos, demasiado tosco (sensor cosido sobre una tira de velcro), y de uso difícilmente adaptable a otras zonas distintas al dedo. Comentar que es necesario especificar exactamente la colocación en el dedo para poder obtener una señal útil. Sin embargo, ha cumplido su objetivo: estudiar las posibilidades de lectura de señales analógicas, con la conclusión de que el Arduino está perfectamente capacitado para ello. El consumo se puede optimizar si se controla mediante el Arduino el momento en que alimentar el LED infrarrojo y así sólo consumir corriente en el momento de realizar una lectura.

5.3 Sobre el ZigBee Excelente sistema de comunicaciones. El hecho de que se comunique por puerto serie con el microcontrolador es un punto muy positivo. La parte negativa del módulo utilizado es que por defecto no se puede poner en modo dormido, aunque eso se ha solucionado en este proyecto mediante un transistor. La mayor dificultad es la configuración inicial cuando se está teniendo contacto con la tecnología por primera vez.

5.4 Sobre el módulo de GPS Módulo muy sencillo de fácil comunicación mediante puerto serie. Se hecha de menos una librería con una API más elaborada. El módulo prefabricado para Arduino tiene el problema de no ser posible configurarlo para entrar en modo dormido, con el consiguiente desperdicio de energía.

110

5.5 Sobre Arduino El modelo utilizado tiene la gran ventaja de tener un consumo muy bajo. Se ha exprimido considerablemente las posibilidades del microcontrolador ATmega168 mediante la utilización de todos los Timer/Counter disponibles, la lectura analógica, puerto serie software y puerto serie hardware. Como parte negativa, añadir un dispositivo que se comunique mediante puerto serie implica la necesidad de programar en ensamblador una librería de puerto serie o multiplexar por hardware. La opción más sencilla es utilizar un modelo de microcontrolador con más puertos series, aunque esto incrementa el consumo. En cuanto a temporizadores, en principio con uno solo es suficiente para leer señales PWM, pero si se necesitan leer señales con mayor resolución o menor ruido, la opción más sencilla es utilizar un modelo de microcontrolador con más temporizadores con modo de captura, aunque esto también incrementa el consumo. Comentar la limitación de lectura de señales analógicas a 10 Kmuestras/s. En nuestro caso no ha sido un problema, pero en otra situación podría ser un factor limitante aunque se pueden leer más muestras por segundo sacrificando resolución. Un aspecto muy negativo del Arduino son los bugs comentados en el proyecto: •

Problemas de configuración de registros que se resetean (apartado 4.4.4)

•

Imposibilidad de entrar en modo dormido sin lanzar una conversión A/D (apartado 4.4.4)

•

Modo de temporizadores CTC que no funcionan (apartado 4.4.4)

Otro aspecto muy negativo es el pobre código que genera el compilador GCC haciendo que se desperdicie mucha capacidad de cómputo. En concreto se trató de implementar una librería de puerto serie por software y no era capaz de leer y enviar por dos puertos serie a 4800 bps debido a que las grandes latencias de las interrupciones generaban dessincronizaciones.

111

112

Capítulo 6. Líneas futuras de desarrollo El dispositivo desarrollado es un prototipo; difícilmente una persona llevaría una caja intentando desarrollar una vida normal. Además, es buena idea mejorar algunas funcionalidades ya existentes y añadir ciertas otras interesantes.

6.1 Añadir módulo GPRS Algo que se echa de menos es la posibilidad de enviar mensajes sms como aviso. El módulo GPRS de Arduino sirve para este fin. Además, posibilita el envío de datos por internet mediante la tarifa de datos, siendo posible visualizar las constantes tanto en un ordenador personal como en un dispositivo móvil (con el desarrollo también de una aplicación para dicho dispositivo). Adicionalmente, permite mejorar el posicionamiento dentro de edificios mediante la utilización de celdas de conexión de los móviles.

6.2 Implementación en ensamblador Utilizando el mismo microcontrolador utilizado en el presente proyecto (Atmega168), si bien la versión actual funciona aceptablemente estando programada en C/C++, sería deseable programar ciertas partes de la aplicación en ensamblador para mejorar las medidas de los sensores y el tiempo de respuesta. En concreto, habría que optimizar lo siguiente: •

Puerto serie por software. La librería de puerto serie utilizada es síncrona y muy sensible a las interrupciones. El objetivo sería desarrollar una librería asíncrona de puerto serie por software. Para el caso del ATmega168 sería deseable que pudiese recibir datos de varios dispositivos al mismo tiempo, para, por ejemplo, poder tener una comunicación bidireccional con el módulo GPRS

•

Algoritmo de lectura PWM. Una ejecución de baja latencia de las interrupciones (disminuyendo el preámbulo) mejoraría las mediciones.

113

6.3 Miniaturización La miniaturización sería un paso previo a la explotación industrial. Mediante la miniaturización se obtiene varios beneficios, como reducción del consumo, reducción del tamaño, incremento de la ergonomía. Sería deseable también cierta tolerancia al agua. En relación al hardware, las medidas de los distintos componentes son (aproximadamente): •

Microcontrolador ATmega128RFA1: microcontrolador más potente que el ATmega168, con ZigBee integrado. 1 cm x 1 cm.

•

Receptor GPS A1037-A de Tyco Electronics': 1,6 cm x 1,9 cm

•

Acelerómetro MXD2125GL: 0,5 cm x 0,5 cm

•

Regulador de tensión MC78LC00H: empaquetado SOT-23, 0,3 cm x 0,25 cm

Se podrían tener todos los componentes esenciales en una superficie de 4 cm x 4 cm. Las antenas y sensores irían colocados externamente.

6.4 Investigación y desarrollo de sensores en prendas de ropa Lo propuesto es intentar desarrollar sensores en prendas de ropa, mínimamente invasivos, así como facilidad de conexión con el microcontrolador. Un ejemplo es el cinturón desarrollado por J. Mühlsteff et al.[34] que monitoriza durante 2 días una señal de electrocardiograma y la actividad del individuo para ser analizadas offline. Estaría bien poder monitorizar durante la noche, bien por tener sensores en el pijama, en la almohada o en la cama, idealmente sin necesidad de conectar cables. Al mismo tiempo, utilizar los mismos principios para colocar y conectar antenas que estarían en la ropa.

114

Anexo I: Instalación del IDE de Arduino y carga de programas El entorno de desarrollo de Arduino dispone de un editor de texto gratuito para escribir el código, junto con un área de mensajes, una consola de texto, una barra de herramientas y una serie de menús. El propio IDE se conecta al Arduino para cargar programas en él, y para comunicarse. Los pasos de instalación son sencillos. El IDE se distribuye como un “stand-alone”, de manera que sólo hay que descargar, descomprimir y ejecutar, pudiéndose llevar en una memoria flash.

I.1 Instalación en Windows 1. Descargar y descomprimir el IDE desde http://arduino.cc/en/Main/Software 2. Enchufar el Arduino a un puerto USB 3. Instalar los drivers (en Vista/7 no es necesario) siguiendo los pasos: 1. Cuando pregunte si conectar a Windows Update para buscar software, responder: “No” 2. Seleccionar: “Instalar desde una lista o localización específica (Avanzado)” 3. Marcar “Buscar el mejor controlador en esta localización”, y marcar “Incluir esta localización en la búsqueda”, indicando el directorio “drivers/FTDI USB Drivers” que viene en la distribución de Arduino del punto 1. 4. La ventana de nuevo hardware aparecerá de nuevo. Repetir los pasos en 3. Esta vez se encontrará un “USB Serial Port”.

I.2 Instalación en Linux La instalación depende de la distribución de Linux. Se indica a continuación la manera de instalar el IDE en Ubuntu.

115

Ubuntu Maverick (10.10) En Ubuntu Maverick se dispone del paquete “Arduino” en el repositorio universe. Se puede instalar mediante el Centro de Software de Ubuntu, o cualquier otro gestor de paquetes (apt-get install Arduino, por ejemplo ). Disponible para i386 y para amd64.

Ubuntu karmic (9.10) y Lucid (10.04) mediante paquete Existe una versión PPA (Private Package Archive) de la versión Arduino-0018. No es una versión oficial, y el código fuente original del IDE está parcheado para que se pueda empaquetar para Ubuntu. Para instalarlo hay que ejecutar: sudo add-apt-repository ppa:Arduino-ubuntu-team sudo apt-get update sudo apt-get install Arduino

Ubuntu sin paquete Arduino 1. Descargar la versión deseada de linux desde http://arduino.cc/en/Main/Software 2. Instalar las dependencias: apt-get install sun-java5-jre gcc-avr avr-libc

3. En algunos casos conviene desinstalar, si no es necesario, el programa “britty”. Éste se encarga de permitir el acceso al terminal a personas ciegas a través de un dispositivo especial en braille. Síntomas de que es necesario desinstalarlo (si no lo hemos hecho) son: no aparece la opción /dev/tty/USB0 en el menú “Tools > Serial Port”, o que el LED Rx del Arduino se ilumina de 3 a 5 veces cada 5 o 6 segundos. apt-get remove brltty

I.3 Programación y carga de programas Para ejecutar el IDE de Arduino, si la instalación es de paquete, estará disponible un icono en el menú “Programación > Arduino”. Si la instalación es el fichero descomprimido descargado desde la página www.arduino.cc, simplemente habrá que ejecutar el script ./arduino de la raíz. En la ilustración 75 se puede ver el IDE. 116

Ilustración 75: IDE del Arduino

Lo primero que hay que hacer es seleccionar el tipo de placa de Arduino que se utilizará en el listado del menú “Tools > Board”. En nuestro caso “Duemilanove” en un Atmega168 (ilustración 76)

117

Ilustración 76: selección del tipo de placa

También es necesario indicar en qué puerto está conectado el Arduino al ordenador para enviarle el programa. Con el Arduino enchufado, hay que indicarlo en “Tools > Serial Port”. En nuestro caso /dev/ttyUSB0 (ilustración 77).

118

Ilustración 77: selección de puerto USB

Una vez configurado el tipo de placa y el puerto, sólo queda escribir el programa en el IDE y cargarlo en el Arduino. Para ello, hay que compilar el código (aunque en el Arduino se denota como verify) mediante el botón de play (ilustración 78)

Ilustración 78: verify = compilar el código

Si no hay ningún error de compilación, en el área de notificación nos indicará que la compilación ha terminado y mostrará información del tamaño del programa (ilustración 79)

119

Ilustración 79: compilación completada

Finalmente, para cargar el programa en el Arduino, se pincha en el botón upload (ilustración 80) para que se transfiera el programa al Arduino. Se podrá observar en los LEDs TX y RX parpadeantes del Arduino la transferencia del programa.

Ilustración 80: botón 'upload'

Si no se ha producido ningún error en la carga, el área de notificación indicará que la carga se realizado (ilustración 81).

Ilustración 81: carga del programa terminada

ATENCIÓN: Para cargar un programa en un Arduino es necesario que no esté conectado el XBee Shield.

120

Anexo II: Actualización del firmware del módulo XBee Hay que comprobar la versión del firmware de los módulos (tanto cliente como servidor), cuyo modelo es el XBee-PRO ZB RF. Para ello hay que seguir los siguientes pasos.

1 Descargar e instalar la herramienta de configuración X-CTU Utilizaremos la herramienta X-CTU versión 5.1.4.1 que se puede descargar[35] desde la página de Digi.

Ilustración 82: página de descarga de X-CTU

Instalaremos con las opciones por defecto. 121

Ilustración 83: instalación de X-CTU

La instalación preguntará si se desea comprobar en Digi si hay actualizaciones de firmware, a lo que responderemos sí.

2 Descargar los drivers USB Los drivers se pueden descargar[36] desde la página de Digi.

122

Ilustración 84: página de descarga de los drivers de X-CTU

Descargar y descomprimir los drivers para ser utilizados en el paso II.4.

3 Configuración del Arduino para la comunicación con el ordenador Para que el X-CTU se pueda comunicar con el módulo de XBee es necesario configurar los jumpers del XBee Shield en la posición “USB” y quitar el microcontrolador ATmega de la placa. De este modo, el ordenador tiene comunicación directa con el módulo XBee. Si los jumpers se configuran en posición “XBee”, es el microcontrolador el único capaz de enviar datos al módulo XBee, aunque también se puedan leer en un ordenador a través del puerto USB (los datos se envían por USB y por wireless al mismo tiempo). Hay una opción para no tener que quitar el microcontrolador de la placa a la hora de querer comunicarse con el módulo XBee. Lo que hay que hacer es un puente entre el pin Gnd y el de Reset en el Arduino, de manera que el microcontrolador esté permanentemente en estado de reset y no interfiera con la comunicación ordenadorXBee.

123

4 Enchufar el Arduino e instalar los drivers USB Tras enchufar el Arduino (sin microcontrolador), en el asistente de nuevo hardware de Windows habrá que indicarle que instalaremos desde una ubicación específica, siendo dicha ubicación el directorio hemos descomprimido los drivers en el paso 2. Instalará los drivers “USB High Speed Serial Converter” y “USB Serial Port” (puerto COM virtual).

5 Ejecutar el X-CTU Al ejecutar el X-CTU mostrará un listado de puertos (ilustración 85). Hay que escoger el “USB Serial Port” que estará en un puerto COM dependiente del sistema. ATENCIÓN: La captura de pantalla tiene el valor ‘HARDWARE’ en ‘Flow Control’, pero ha de configurarse como ‘NONE‘.

Ilustración 85: pantalla principal de X-CTU

124

Las opciones de configuración para la comunicación son: • Baud: 9600 • Flow Control: NONE • Data Bits: 8 • Parity: NONE • Stop Bits: 1

6 Leer la configuración actual Simplemente hay que seleccionar la pestaña “Modem Configuration” y pinchar “Read”. Si no surge ningún problema, los LEDs Rx/Tx del Arduino parpadearán un poco y aparecerán todas las opciones de configuración del módulo (ilustración 86). La pestaña de configuración indica que el módulo enchufado es XBEE-PRO, modem XBP24ZB, con Function Set = ZIGBEE ROUTER AT (un router en modo AT) y la versión 2270. Los parámetros mostrados en verde son aquellos que todavía están en su valor por defecto; los mostrados en azul son los que han sido modificados, y los que aparecen en negro son parámetros de sólo lectura.

125

Ilustración 86: opciones de configuración y sus valores

7 Seleccionar el firmware deseado y grabar En nuestro caso vamos a cambiarle el firmware a Coordinador en modo AT, versión 2070 (la última que muestra el desplegable). Para ello seleccionamos la nueva configuración y pinchamos en “Write”.

126

Ilustración 87: selección y grabado del firmware y las opciones

Una barra de progreso indicará el estado de la grabación del nuevo firmware y después grabará las opciones AT.

127

128

Anexo III: Lectura exacta de pulsos PWM O al menos lo más exacta posible. Hasta ahora había pasado desapercibido el hecho de que las las mediciones del tamaño del pulso PWM tenían algo de ruido. Si bien para muchas aplicaciones sería totalmente aceptable, personalmente para mí resulta irritante. La ilustración 88 muestra el problema.

Ilustración 88: inicio y fin del error cíclico

Se trata de un error cíclico que dura entre 3 y 4 segundos (en el ejemplo), en ambos ejes, y en

129

diferente momento. He tomado una captura donde se pueden ver ambos. En rojo están marcados el inicio y fin del período de error que se repite tras unos segundos. En dichos períodos, las mediciones tomadas tienen un error de una unidad (positiva o negativa). Además de ello, vemos que hay una cantidad considerable de dientes.

1 Mejora del algoritmo de lectura PWM Que aparezcan dientes en la lectura es normal: si el acelerómetro está en una posición en la que la señal fluctúa entre 2 valores porque el valor que correspondería sería sería “el medio”, es normal que cualquier mínima vibración pueda generar dicho ruido. Sin embargo, cuando en todo momento y posición hay ruido, lo más probable es que otro sea el problema. Para tratar de mejorar la lectura, lo primero que hay que hacer es permitir que el servicio de las interrupciones sea no bloqueante (permitir anidación de interrupciones). Esto podría causar un desbordamiento de pila en el peor de los casos, pero en el nuestro no debería. Tras modificar el código para que realice las operaciones críticas al principio de la interrupción de manera atómica (con las interrupciones deshabilitadas), y permitir interrupciones después, el resultado se muestra en la ilustración 91. Con esa modificación se han eliminado casi todos los dientes de la señal (más detalle sobre esto más adelante), pero el error cíclico no. ¿Qué es lo que puede estar ocasionando un error de una unidad?

130

Ilustración 89: se han conseguido eliminar casi todos los dientes

2 La resolución de medida y el desfase incremental (prescaler) El timer/contador de 0-255 es configurable mediante un prescaler de 1,8,16,32,64,128,256 o 1024, de manera que la cuenta sólo se incrementa cada tantos ciclos como indica el prescaler. Configurado con un prescaler de 1024, un ciclo PWM del acelerómetro corresponde con 156,25 unidades. He aquí, una fuente de error: hay un desfase entre los ciclos PWM y la resolución de medida, de manera que se acumula un desfase de 0,25 unidades (256 ciclos). En la ilustración 90 se suponen grupos compuestos por 156 unidades (aunque no se dividen en 156 por motivos de visibilidad).

131

Ilustración 90: efecto del desfase acumulado de 0,25 unidades

¿Qué supone un desfase incremental? La ilustración 91 demuestra que una señal de longitud 2,5 unidades puede tomar diferentes valores en función del desfase acumulado.

Ilustración 91: Efecto de un desfase dentro del prescaler en la medida de la señal

En la señal azul, que comienza cerca del principio de la cuenta del prescaler, la longitud de la señal medida es “3-1=2″ unidades. Similar al caso de la señal roja. Sin embargo, la señal verde, de igual duración que las anteriores, al comentar cerca del final de la cuenta del prescaler, su longitud medida es “4-1=3″ unidades. Es decir, la misma señal genera medidas distintas, por lo que obtendremos unos dientes en la señal medida. Dado que el desfase teórico es de 0,25 unidades, se podría multiplicar por 4 la resolución utilizando un prescaler de 256 (4 veces menos que 1024), por lo que cada ciclo PWM duraría 624 unidades exactas de timer. Necesitamos aumentar la resolución del timer por software 132

porque el máximo es 255 unidades. Como ejemplo explicativo en la ilustración 92 se muestra el ejemplo anterior habiendo dividido las unidades de tiempo en 2 (duplicada la resolución), de manera que el valor es la diferencia de tiempo dividida a la mitad (redondeada hacia abajo).

Ilustración 92: Aumentamos la resolución y el desfase deja de afectar (ejemplo explicativo)

En el caso de las señales azul y roja: (6-1)/2 = 5/2 = 2.5 => 2 unidades En el caso de la señal verde: (7-2)/2 = 5/2 = 2.5 => 2 unidades De todos modos, el desfase de 0,25 unidades no es suficiente razón para crear el error cíclico que encabeza este artículo, sino que sería motivo para tener tres datos con error cada 4 lecturas (que en otras pruebas se aprecia más).

3 La solución aplicada hasta ahora 1 – Incrementar la resolución de nuestro timer mediante software. El Memsic2125 tiene una resolución de mg, lo que significa que para 8 g se necesitaría una resolución de 8000 unidades. Al disminuir el prescaler a 256 multiplicamos la resolución por 4 hasta 624, que después redondearemos a 0-155. No necesitamos una altísima resolución porque nuestro objetivo no es tomar medidas precisas, así que utilizar una resolución de 620 para redondear posteriormente da un buen resultado. 2- Definir los servicios de interrupciones como no bloqueantes. Realmente lo que se hace es definirlas como bloqueantes, ejecutar todo el código crítico al principio del servicio, y activar las interrupciones de nuevo. De este modo los timestamps son mucho más fiables y, recordemos, 133

con más resolución (con prescaler de 1024 el error estaba asegurado).

4 La frecuencia variable Seguimos, pues, teniendo un error cíclico. En las pruebas, el visualizador muestra que la recepción de datos fluctúa entre 99 y 102 datos por segundo a pesar de que el datasheet del Memsic2125 dice que la señal es de 100Hz; aunque este valor es un redondeo y el visualizador lo calcula de manera poco precisa, al fluctuar más allá de entre 2 valores da la idea “de que algo pasa”. Puede ser que el motivo sea que el oscilador interno del sensor fluctúa sensiblemente (sea debido al propio sensor, a la temperatura, al ruido que pueda introducir el Arduino en la alimentación, error del reloj de Arduino, …). Hay que tener en cuenta que esto implica que: 1. No podemos calcular de manera exacta el valor máximo del timer: el valor máximo 156,25 (o 625) dependen del hecho de que la señal sea de 100Hz. 2. Aumentar la resolución modificando el prescaler no evita las “décimas de unidad” de duración que causan desfase, como el visto más arriba, de la señal. 3. El inicio de cada ciclo PWM se dessincronizará del reloj del Arduino.

5 Determinación de la frecuencia Para la determinación de la frecuencia he desarrollado un pequeño sketch de Arduino que permite medir la duración de los ciclos PWM (de flanco de subida a flanco de subida). Para ello, permite elegir entre utilizar el Timer/counter1 (16bits) con la funcionalidad de Input Capture, o utilizar el Timer/counter2 realizando la captura por software mediante la interrupción Pin Change. Medida con el timer/counter1: Para utilizar el modo de captura (Input Capture mode) del timer/counter1, la señal a medir ha de estar obligatoriamente conectada al pin 8 del Arduino. Cada vez que la señal tiene un flanco positivo, el valor del timer/counter1 se copia automáticamente en el registro temporal de captura ICR1, de modo que aunque el timer/counter1 siga contando, podemos consultar el momento exacto en el que ocurrió el flanco positivo. En el 134

código es necesario configurar el registro TCCR1B con los valores de prescaler del contador según el datasheet del ATmega168[37]. Por el puerto serie (a 115200 bps) el sketch mostrará los distintos valores máximo y mínimo leídos en el tiempo (previo descarte de los 10 primeros por ser posiblemente erróneos). Los resultados de duración de ciclo del acelerómetro medidos mediante Input Capture Mode mostrando el mínimo valor y máximo valor se muestran en la tabla 8. prescaler 8 64 256 1024

mínimo valor de

máximo valor

desfase de valor con

Frecuencias

ICR1 19926 (9,963 ms) 2490 (9,96 ms) 623 (9,968 ms) 155 (9,92 ms)

de ICR1 19942 (9,971 ms) 2493 (9,972 ms) 624 (9,984 ms) 156 (9,984 ms)

relación al máximo 16 unidades => 0,08% 3 unidades => 0,12% 1 unidad => 0,16% 1 unidad => 0,64%

mínima/máxima 100,290… Hz / 100,37…Hz 100,280..Hz / 100,40..Hz 100,16..Hz / 100,32..Hz 100,16..Hz / 100,80..Hz

Tabla 8: duración de un ciclo medidas mediante Capture Mode

• desfase de valor con relación al máximo: [[ 100 x (máximo-mínimo)/máximo ]] • frecuencias

mínima-máxima:

1000ms/tiempo_mínimo,

1000ms/tiempo_máximo

Se presupone que el valor máximo corresponde a 1Hz – cosa que no es correcta del todo, pero se simplifica la fórmula. La completa sería: [[ (máximo-mínimo)/máximo * 10ms/ (tiempo_maximo_ms) ]] • duración del ciclo: [[ 1/desfase_temporal ]] Medida con el timer/counter2: Para utilizar el timer/counter2 para medir la longitud de ciclo, la señal a medir ha de estar conectada al pin 2 del Arduino, ya que el software está programado para que esté en dicho pin. El funcionamiento es distinto. El timer/counter2 no dispone de la funcionalidad de captura, por lo que es necesario realizar el proceso por software. Se programa el servicio de interrupción de Pin Change, de modo que cada vez que se detecta un flanco positivo en el pin2, se envía por puerto serie el valor del timer/counter2 (no sólo el máximo/mínimo, sino que se envían todos). Se podría aumentar la resolución por software, pero por simplicidad y porque era la prueba preliminar de medida del ancho del ciclo, no se ha llevado a cabo.

135

6 ¿En qué influye la frecuencia variable? Lo primero de todo, resolución y fiabilidad de la lectura. La resolución de la señal PWM es del orden de 1 mg, por lo que la señal PWM tiene hasta 8000 mg (desde -4 g hasta +4 g). Resolución: ¿Es posible medir todo el rango de 8000 mg? 8000 mg*100Hz (frecuencia PWM) = 800.000 mg/s. Sería necesario poder discriminar todos y cada uno de ellos. Esto implica disponer de 20 ciclos de reloj por mg (en el peor de los casos, leer una señal de 1mg). Se necesitaría un software bastante dedicado para poder leer un único mg, ya que la entrada y salida de la interrupción consumen 8 ciclos de reloj, y la programación en C añade irremediablemente un preámbulo al servicio de la interrupción. En ensamblador, 12 ciclos se tendrían para poder leer 1 único mg. Para leer una señal de 7999 mg el problema sería parecido ya que 40 ciclos después se ejecutaría de nuevo la interrupción marcando el inicio del siguiente ciclo PWM. Sin embargo, para valores intermedios no debería presentar problema, ya que el espaciado en el tiempo sería suficiente evitando que el número de ciclos disponibles para procesar fuese crítico. Para leer 1 mg se necesitaría utilizar un contador e 16bits con modo captura y prescaler de 8, donde cada 1 mg equivaldría a 2,5 unidades de contador (en teoría). Se podría utilizar el prescaler de 1 si se incrementa la cuenta máxima del timer mediante software. En nuestro caso no necesitamos una resolución grande, ya que el objetivo no es “medir la inclinación”, sino detectar colisiones. Por motivos de haber utilizado al principio el timer/counter2 con prescaler de 1024, cualquier medición se mapea a un valor 0-155, por lo que nos serviría utilizar el prescaler 1024 (156 valores) o 256 (624 valores). Menos prescaler indica más consumo, así que los prescalers 64 y 8, en principio, quedarían descartados. Fiabilidad de la lectura: En un principio parece que el error de la duración de cada ciclo PWM (desde 0,08% hasta 0,64%) es insignificante. Notar el hecho de que ninguno de los ciclos dura los 10 milisegundos que deberían durar de media a 100 Hz. Teniendo en cuenta los dos datos anteriores, la primera conclusión que se extrae es que los datos son más fiables (de manera absoluta, no relativa) cuanto menor es el pulso PWM: Leer unos pocos mg tiene un error acumulador que puede ser imperceptible; leer 2000 mg con prescaler 8 tiene incorporado hasta 1,6 unidades de error (0,8% de 2000); leer 6000 mg tiene un error de 136

hasta 4,8mgs (0,8% de 6000). La fiabilidad, de todos modos, se puede calcular a partir de los resultados de frecuencias mínimas y máximas calculadas para el caso de prescaler 8 y el efecto de ellas en el desfase incremental (comentado más arriba). Suponiendo que la frecuencia PWM oscila entre 100,29Hz y 100,37Hz (esto es mucho suponer porque podría aumentar o desplazarse el rango por temperatura u otras variables ocultas), podemos calcular el valor mínimo y máximo que darían los distintos prescalers. prescaler 8 64 256 1024

ICR1 a 100,37 19926,27.. 2490,78.. 622,69.. 155,67..

ICR1 a 100,29Hz 19942,167.. 2492,727.. 623,19.. 155,798..

Tabla 9: valor de Timer para leer 1 Hz con distintos prescalers

• ICR1 = 16 MHz/frecuenciaPWM x 1/prescaler En todos los casos de la tabla 9 hay una fracción de contador que no se puede medir y que origina en todos los casos un desfase incremental en las medidas. Gracias a estos cálculos podremos estimar cuál es la mayor resolución con la que podremos leer en cada uno de los prescalers. En el caso de utilizar el prescaler 1024, el incremento/decremento de la longitud PWM de un ciclo a otro, teniendo en cuenta que las medidas sufren el desfase incremental, hacen que una misma longitud pueda ser leída como 3 valores distintos dependiendo de si aumenta o disminuye la frecuencia en un ciclo dado y en función del desfase acumulado.

7 Solución al desfase incremental producido por la frecuencia variable Para solucionar el desfase incremental lo que se hace es resetear el prescaler al inicio del ciclo PWM (flanco positivo). El ATmega168 comparte prescaler entre el Timer0 y el Timer1, y el Timer2 dispone de su propio prescaler. Los resultados son los siguientes:

137

prescaler 8 64 256 1024

rango de valores ICR1 19982-19992 2496-2499 624 155-156

moda ICR1 19988-19991 2498 624 156

unidades de error 10 4 0 1

Tabla 10: lectura de valor del Timer si se resetea el prescaler antes de cada lectura

Como se puede apreciar en la tabla 10, las lecturas han mejorado mucho. Algo a tener en cuenta es que a pesar de las fluctuaciones dentro de un rango, hay un valor moda. Variaciones como las apreciadas con prescaler 8 podrían ser debidas diversas variables como las nombradas más atrás (temperatura, …). Para prescalers altos (64,256,1024) la moda es un único valor.

8 Solución a la frecuencia variable El problema de la frecuencia variable no se puede solucionar incrementando la resolución de lectura (y después dividiendo). Hacer esto puede ser beneficioso , dado que se disminuye la ventana de error y por lo tanto, al dividir, la lectura es más estable. Sin embargo, la ventana de error sigue existiendo en las inmediaciones de una unidad de contador y la siguiente, sensible a la mínima variación de frecuencia. La solución óptima sería medir la duración del pulso PWM y la del ciclo PWM. Tras obtener estos dos valores, calcular la duración del pulso con respecto al ciclo.

9 Solución técnica Se ha mejorado el algoritmo para la lectura de pulsos PWM, pero dado que vamos a leer 2 señales PWM con el mismo Timer (Timer2), no es posible evitar el desfase incremental de manera efectiva reseteando el prescaler (tenemos que leer 2 señales, por lo que esta solución no es aplicable), por lo que se utilizará la resolución de 624 unidades y su posterior redondeo para disminuir un poco la ventana de error. Definir las interrupciones como no bloqueantes (tanto la de Compare Match A como la de Pin Change) pero dejando bloqueantes las secciones críticas de adquisición del timestamp:

138

9.1 Compare Match A 1. DEFINIRLA COMO BLOQUEANTE y poner al principio de la interrupción ATOMIC_BLOCK(ATOMIC_FORCEON)

–

Bloque

atómico

(interrupciones

deshabilitadas) y tras finalizar el bloque se fuerza la habilitación de interrupciones. 2. Actualizar

la

variable

Overflow

(que

debería

llamarse

“variable_interna_de_veces_contadas_hasta_156 “) y de Output Compare Register 2A(para que cuente de nuevo hasta 156 – no debería ser necesario pero parece que este valor se borra automáticamente) 3. Borrar a mano Output Compare Flag 2A (OCF2A) para que la interrupción de Pin Change no se equivoque si nada más terminar este bloque atómico salta una de ellas (ver más abajo) 4. Desbloquear (permitir interrupciones)

9.2 Pin Change 1. DEFINIRLA COMO BLOQUEANTE y poner al principio de la interrupción ATOMIC_BLOCK(ATOMIC_FORCEON) 2. Guardar un timestamp del momento de la interrupción 3. Tener en cuenta que si el flag de COMPARE MATCH está activo y el TCNT2 es