Repositorio Institucional de Documentos

Trabajo Fin de Máster Máster en Ingeniería Electrónica Sistema de interacción basado en RFID para salas de estimulación multisensorial Centro Politcnico Superior UNIVERSIDAD DE ZARAGOZA Diciembre 2010 Autor: José Miguel Idiago Valero Director: Roberto José Casas Nebra Co-Director: Álvaro Marco Marco Departamento: Ingeniería electrónica y comunicaciones. Área de tecnología electrónica. Agradecimientos A todos mis compañeros de Tecnodiscap que desinteresadamente me han ayudado a realizar este proyecto. iii Resumen Este Proyecto de Fin de Carrera se ha realizado en Tecnodiscap, grupo de investigación del I3A, dentro de la línea de investigación en salas de estimulación multisensorial. Las salas de estimulación multisensorial son aulas situadas en colegios de educación especial con materiales diseñados para que los niños estén expuestos a estímulos controlados, con el objetivo final de favorecer su nivel de integración sensorial facilitando así los aprendizajes básicos. Se ha detectado en las instalaciones actuales una falta de posibilidades de interacción del usuario con el entorno, lo que supone una limitación en el desarrollo de las sesiones terapéuticas. En este proyecto se enmarca dentro del desarrollo de un sistema que permita la interacción del usuario con los diferentes elementos que pueden estar presentes en una sala de estimulación multisensorial. En concreto se ha diseñado un dispositivo basado en RFID y Zigbee que permite la interacción del usuario con otros elementos presentes en el aula. Se pretende que el usuario pueda llevar encima el dispositivo para que cuando se acerque a determinados objetos el sistema lo reconozca y sea capaz de producir un estímulo en el usuario mediante la activación de otros elementos presentes en la sala como luces, sonidos o proyecciones... Además del diseño hardware se ha integrado el dispositivo en un driver zigbee, que permite la auto-detección del dispositivo. Este driver funciona bajo un framework (OSGi) que permite el manejo e interconexión de dispositivos y servicios, de esta manera el objeto software creado por el driver puede interactuar con otros dispositivos o servicios. Por otro lado se ha contribuido al diseñado de la arquitectura software/middleware del sistema completo, tratando de que quede abierto a la incorporación de más elementos en futuros desarrollos en función de las necesidades expresadas por los usuarios. También se ha realizado una colaboración con alumnos de diseño industrial en el diseño del interfaz de usuario, además se ha dirigido un proyecto fin de carrera en el que siguiendo la linea de investigación en aulas de estimulación multisensorial se ha desarrollado un controlador de luces para poder controlar la iluminación del aula. El objetivo principal ha sido añadir un elemento nuevo a las salas de estimulación multisensorial e integrarlo junto con otros dispositivos que se están desarrollando en paralelo, pero a la vez ha obtenido una visión clara del proceso de diseño de un dispositivo, desde la electrónica básica, pasando por el firmware, el funcionamiento de un driver y el control software del dispositivo. v Índice general 1. Introducción 3 1.1. Salas de Estimulación Multisensorial . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Objetivos del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Estado del Arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Diagrama Temporal del Trabajo ............................ 6 2. Desarrollo Hardware 9 2.1. Descripción del Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Firmware y Middleware 15 3.1. Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1.1. Comunicación con el Lector de Skyetek . . . . . . . . . . . . . . . . . . . 16 3.1.2. Comunicación Zigbee .............................. 17 3.1.3. Perfil ZigBee-Tecnodiscap . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.4. Estructura de Mensajes ............................ 18 3.2. Middleware ....................................... 20 3.2.1. OSGi (Open Service Gateway Initiative) ................... 20 3.2.2. OSGi4AmI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.2.3. Relación entre OSGi4AmI y Perfil ZigBee-Tecnodiscap . . . . . . . . . . . 24 3.2.4. Integración en Driver Zigbee de Tecnodiscap . . . . . . . . . . . . . . . . . 25 5. Otros Trabajos Realizados 33 5.1. Colaboración con Alumnos y Profesores de Diseño Industrial . . . . . . . . . . . . 33 vii 5.2. Dirección del Proyecto Fin De Carrera . . . . . . . . . . . . . . . . . . . . . . . . 35 6. Conclusiones y trabajos futuros 37 6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.2. Futuros Trabajos .................................... 38 ANEXOS 43 A. Salas de Estimulación Multisensorial 43 A.1. Estimulación Multisensorial .............................. 43 A.2. Aula Multisensorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 A.3. Áreas de estimulación multisensorial . . . . . . . . . . . . . . . . . . . . . . . . . 44 A.4. Materiales disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 B. Tecnología RFID 51 B.1. ¿Qué es la Tecnología RFID? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 B.2. ¿Cómo Funciona? .................................... 52 B.3. Beneficios de la tecnología RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 C. Protocolo Zigbee 59 C.1. Estándar IEEE 802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 C.2. Tipos de dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 C.3. Topologías y funcionamiento de la red . . . . . . . . . . . . . . . . . . . . . . . . 61 C.4. Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 C.5. Mensajes de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 C.6. Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 C.7. Perfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 C.8. Campos de aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 D. Esquematico y PCB 69 viii Lista de Figuras 1.1. Diagrama temporal de las tareas realizadas ..................... 7 2.1. Diagrama de la Tag v2 ................................. 10 2.2. Esquema dsPic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3. Módulo ZigBee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.4. Diagrama de Conexiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Lector Skyetek M1-mini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.6. Dispositivo para Aulas de Estimulación Multisensorial ............... 14 3.1. Comunicación con el lector RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2. Petición: Microcontrolador –>Lector . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3. Respuest: Lector –>Microcontrolador . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4. Estructura de un paquete tipo Comando ....................... 19 3.5. Estructura de un paquete tipo Evento ........................ 20 3.6. Jerarquización de los dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.7. Ejemplo de Arquitectura con OSGi y OSGi4AmI . . . . . . . . . . . . . . . . . . 23 3.8. Endpoints Implementados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.9. Clusters Implementados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.10. Algunos Comandos y Eventos Implementados .................... 26 3.11. Interfaz OSGi4AmI Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 3.12. Interfaz OSGi4AmI Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 A.1. Columna de Burbujas ................................. 47 ix 6 CAPÍTULO 1. INTRODUCCIÓN Al hilo de aplicaciones de RFID para juegos encontramos propuestas como la de [5] en la que se propone integra además de el lector RFID un acelerómetro para incrementar las posibilidades de juego. Como se verá más adelante nosotros también hemos integrado un acelerómetro, pero no se ha implementado una aplicación de reconocimiento de gestos tan específica como la mostrada en ese artículo. Otra aplicación de RFID para juegos la encontramos en [6], a destacar que aparte de usar un lector RFID y una comunicación Bluetooth se han basado en la plataforma Arduino y en LEGO Mindstrom. Apartándonos un poco de nuestra aplicación encontramos otros ejemplos de interacción con RFID en [11], donde a partir de un dispositivo simular al nuestro se ha implementado un sistema de reconocimiento de gestos basado en la lectura de tags RFID dispuestas sobre el pecho y el abdomen del usuario. Por otra parte encontramos en [9]y[10] dos ejemplos del uso de tecnología RFID integrada en guantes o brazaletes que permiten interactuar con objetos de la vida cotidiana. Por último, en [17] encontramos un sistema de guiado basado en un lector de tags integrado en el zapato, que a su vez está conectado por bluetooth a un dispositivo tipo PDA, este sistema funciona gracias a la lectura de tags que previamente se han colocado en el suelo. De todos estos artículos se han obtenido ideas y mejoras que al final han conducido al dispositivo desarrollado. Destacar que la principal diferencia entre nuestro dispositivo y los expuestos en esta sección es el uso de tecnología ZigBee y la integración del dispositivo en una red de tipo mesh. 1.4. Diagrama Temporal del Trabajo En la Figura [1.1] se muestra el diagrama de Gantt de las tareas llevadas a cabo durante la realización del trabajo fin de máster. 1.4 Diagrama Temporal del Trabajo 7 Figura 1.1: Diagrama temporal de las tareas realizadas 8 CAPÍTULO 1. INTRODUCCIÓN Cap´ ıtulo 2 Desarrollo Hardware En este capítulo vamos a explicar la parte hardware del dispositivo, las principales necesidades del dispositivo son la comunicación inalámbrica y el tamaño reducido. Estas características son fundamentales para que el dispositivo no resulte incomodo en su uso. Otras características que queremos para el dispositivo son: algún tipo de interfaz con el usuario y capacidad de monitorización básica de actividad o movimiento del usuario. Para la comunicación inalámbrica se ha elegido el estándar ZigBee, este estándar se ajusta perfectamente a la aplicación ya que está pensado para maximizar la duración de las baterías de los dispositivos, además el grupo Tecnodiscap tiene experiencia en el desarrollo de dispositivos basados en este estándar. Por otra parte para reducir el tamaño al máximo se han utilizado componentes de montaje superficial y se ha prestado especial cuidado al realizar la PCB del dispositivo. Respecto al tema de sensorización se han integrado el lector RFID, un acelerómetro de tres ejes y un sensor de temperatura, con estos sensores se pretende ser capaz de monitorizar y detectar ciertas actividades del usuario de cara a enviar eventos al sistema global para permitir la interacción con otros elementos de la sala. 2.1. Descripción del Hardware En la Figura [2.1] diagrama de bloques se muestran las distintas partes que integran el dispositivo. 9 10 CAPÍTULO 2. DESARROLLO HARDWARE Figura 2.1: Diagrama de la Tag v2 Figura 2.2: Esquema dsPic Microcontrolador Se utiliza un dsPIC33FJ32GP202 de Microchip (Figura [2.2]). Se trata de un microcontrolador de 16 bits que incluye una unidad de procesamiento de señales digitales (DSP). Integrar tanto el control de todos los dispositivos como el sistema de procesamiento y tiene una velocidad de procesamiento de señales óptima y permite la comunicación con el sensor de temperatura, el acelerómetro, la memoria y el lector RFID de forma sencilla gracias a su bus I2C. 2.1 Descripción del Hardware 11 Figura 2.3: Módulo ZigBee Módulo wireless de comunicaciones Para las comunicaciones ZigBee se ha optado por el módulo ETRX3 de Telegesis (Figura [2.3]). Este módulo permite reprogramar el procesador EM357 interno de manera personalizada o utilizar la API proporcionada por el fabricante. Esta API permite, mediante comandos AT, gestionar la red ZigBee de una forma sencilla. Sensores integrados en la placa Sensor digital de temperatura LM75B de National Semiconductor que suministra a través del bus I2C la temperatura ambiente codificada en 9 bits. Acelerómetro LIS302DL de STMicroelectronics que suministra a través del bus I2C los valores de aceleración correspondiente a cada uno de los ejes X, Y y Z. Lector RFID De cara a mejorar la interacción con el lector se deció incorporar a la placa principal un conector para tener el bus i2c accesible, a este conector se conectará un lector RFID de la empresa Skyetek, concretamente el modelo M1-mini. Se ha elegido este lector por su reducido tamaño, su comunicación i2c que se ajusta perfectamente a las características de nuestro microcontrolador y por la frecuencia de trabajo (13.56 MHz) que es muy apropiada en cuanto a distancia de lectura de nuestra aplicación. En las figuras [2.5] [2.6] podemos ver tanto el lector de forma individual como el dispositivo final ya ensamblado. Destacar en la Figura [2.6] que se han unido la placa principal con el lector mediante cuatro cables trenzados (Vcc, GND, SDA y SCK) y el lector se ha encapsulado en una funda de plástico de la utilizada para coleccionismo de monedas. El diagrama de conexiones puede verse en la 12 CAPÍTULO 2. DESARROLLO HARDWARE Figura [2.4]. Memoria externa Se utiliza una memoria M24M01-RMN6 de STMicroelectronics. Se trata de una EEPROM de 1Mbit que se comunica vía serie por I2C y se utilizará para almacenar los datos obtenidos tras el procesamiento de las muestras de aceleración generadas por el acelerómetro. Interfaz de usuario Se incluyen dos pulsadores y dos leds para interactuar con el usuario. Posibles usos serían informar del estado bajo de la batería mediante la iluminación o parpadeo de un led o el envío de un determinado mensaje si se aprieta el pulsador. Módulo de alimentación Carga de las baterías Las baterías de litio necesitan un sistema de carga especial que controle el voltaje e intensidad suministrada; ello se hace mediante el chip Microchip MCP73812T-420I/OT, el cual, además, protege las baterías contra autodescarga. Estos sistemas facilitan en gran medida la gestión de baterías de iones de litio que requieren unas condiciones de carga muy especiales para no deteriorarse. Las baterías elegidas van a ser las usadas en el iPod nano, ya que su precio es muy reducido debido a la cantidad que se fabrican, además de incorporar un circuito de protección y monitorización que la protegen de un daño prematuro. Alimentación externa La alimentación externa se puede realizar mediante un conector microUSB. Se han instalado este sistema de carga en previsión de que en pocos años todos los móviles deberán tener un cargador común mediante microUSB, así este dispositivo se adelanta a ese evento y ya permite la conexión de este tipo de cargadores cuyo precio será muy reducido al ser un estándar y sobre todo se podrán encontrar en cualquier centro comercial. Regulación de voltaje El voltaje suministrado por la batería de litio depende de su estado de carga, por lo que se necesita un regulador de voltaje capaz de asegurar que la alimentación que llega al resto 2.1 Descripción del Hardware 13 Figura 2.4: Diagrama de Conexiones Figura 2.5: Lector Skyetek M1-mini del circuito es siempre de 3.3V. El circuito integrado usado es el TPS79333DBVRG4. Al ser su tensión de dropout muy baja, el sistema se puede alimentar a una tensión de tan sólo 3.5V, lo que asegura un aprovechamiento máximo de las baterías. Además, dispone de una entrada de habilitación que conectada a otro circuito integrado, el MCP111T, desconecta la alimentación del circuito cuando la tensión de la batería no es la adecuada, con lo que puede provocar un mal funcionamiento del sistema. 14 CAPÍTULO 2. DESARROLLO HARDWARE Figura 2.6: Dispositivo para Aulas de Estimulación Multisensorial Cap´ ıtulo 3 Firmware y Middleware El objetivo de este capítulo es el de exponer las diferentes partes del middleware y firmware que se han usado e implementado en el proyecto. Para comenzar explicaremos brevemente como se realizan tanto las lecturas de las tags RFID y el envío de datos por zigbee, la interacción con los sensores de aceleración y temperatura así como la lectura y escritura en la memoria externa no se han descrito, ya que se trata de una comunicación i2c más simple que la realizada con el lector RFID. De ahí pasaremos a explicar el funcionamiento del perfil privado ZigBee desarrollado por Tecnodiscap, este perfil permite la comunicación entre los nodos de una red ZigBee . En la segunda parte del capítulo explicaremos la capa más baja del software también llamada middleware, ahí introduciremos herramientas como OSGi y OSGi4AmI imprescindibles para realizar una aplicación modular y reutilizable. Por último explicaremos la relación entre el perfil privado ZigBee desarrollado por Tecnodiscap y la ontología OSGi4AmI, en esta última parte expondremos la forma en la que se ha introducido nuestro dispositivo en el driver ZigBee desarrollado por el grupo Tecnodiscap. 3.1. Firmware En este primer apartado primero haremos una breve introducción a la comunicación entre el lector y el microcontrolador, para luego pasar a ver unas pinceladas de los comandos AT con los que se gobierna el módulo ZigBee, por último introduciremos la comunicación llevada a cabo entre el dispositivo y el PC gracias a la implementación del perfil privado Zigbee utilizado en Tecnodiscap, que a partir de ahora nos referiremos a él como Perfil ZigBee-Tecnodiscap. 15 22 CAPÍTULO 3. FIRMWARE Y MIDDLEWARE OSGi4AmI define una formalización de los dispositivos que podemos encontrar en un ambiente inteligente, de forma que puedan ser utilizados por las aplicaciones de forma transparente, independientemente del fabricante del dispositivo, y centrándose sólo en la funcionalidad que requieren las aplicaciones. OSGi4AmI pretende proporcionar una representación virtual de los dispositivos presentes en el entorno físico, de forma que puedan ser utilizados por las aplicaciones del ambiente inteligente sin preocuparse de otra cosa que de la funcionalidad requerida del dispositivo. OSGi4AmI no busca definir todas las características que puede tener un dispositivo, sino sólo aquellas que realmente son relevantes para las aplicaciones, dejando explícitamente a un lado detalles de funcionamiento y configuración de los dispositivos, que en la práctica no son relevantes a las aplicaciones. No es extraño que un mismo dispositivo físico pueda ofrecer distintas funciones relacionadas en mayor o menor medida. En esos casos, no tendremos un dispositivo virtual equivalente al dispositivo real, sino que existirán varios dispositivos simples que ofrecen la funcionalidad completa del dispositivo original. Además de considerar dispositivos particulares, OSGi4AmI contempla atributos y funcionalidades que puedan ser comunes a dispositivos diferentes, agrupándolos en «clusters», de forma que una implementación particular de un dispositivo concreto pueda seleccionar aquellos clusters que pueda ofrecer. OSGi4AmI propone las bases para definir formalmente un dispositivo, pero da la libertad para definir nuevos dispositivos, incluso individuales, combinando las funcionalidades contempladas por los distintos clusters. La ontología OSGi4AmI propone una jerarquización en niveles de los dispositivos, aproximadamente como se ve en la figura [3.6] Todos los dispositivos del entorno inteligente se ajustan a la definición del dispositivo básico BaseDevice, y en función del tipo de dispositivo concreto del que se trate, se ajustarán también a la definición de Sensor, Actuator o SimpleHMI, o de otros tipos que se pudieran definir. OSGi4AmI permite abstraernos de la tecnología con la que estén implementados los dispositivos permitiendo intercambiar dispositivos con la misma funcionalidad aunque estén implementados en tecnologías diferentes. La figura [3.7] muestra la arquitectura del sistema de interacción para aulas de estimulación multisensorial, en él puede verse cómo se utiliza OSGi y OSGi4AmI para combinar dos tecnologías 3.2 Middleware 23 Figura 3.6: Jerarquización de los dispositivos Figura 3.7: Ejemplo de Arquitectura con OSGi y OSGi4AmI 24 CAPÍTULO 3. FIRMWARE Y MIDDLEWARE diferentes: Bluetooth y Zigbee. En la figura se puede ver que existe un driver para cada una de las tecnologías que se ocupa de publicar los diferentes dispositivos físicos como dispositivos software en el framework. Gracias a OSGi4AmI los servicios en capas superiores pueden hacer uso de los dispositivos sin tener en cuenta la tecnología en la que están implementados. Por ejemplo, el servicio de interconexión de dispositivos puede utilizar tanto un acelerómetro basado en Zigbee como otro proveniente de tecnología bluetooth al publicarse ambos con el mismo interfaz OSGi4AmI. Puede encontrase mas información sobre OSGi4AmI en [4] 3.2.3. Relación entre OSGi4AmI y Perfil ZigBee-Tecnodiscap Como hemos explicado en apartados anteriores, un dispositivo ZigBee que obedece al Perfil ZigBee-Tecnodiscap implementa diferentes endpoints atendiendo a las funcionalidades individuales que ofrece y a su vez dentro de cada endpoint implementa diversos clusters que dan funcionalidad específica a cada «sub-dispositivo». Los diferentes clusters que puede implementar un endpoint están muy relacionados con la filosofía que persigue la ontología OSGi4AmI. Por una parte, todo dispositivo definido en OS- Gi4AmI hereda las propiedades y métodos del interfaz «Device», en este interfaz de describen métodos para la habilitación y des-habilitación del dispositivo, así como métodos para fijar y obtener información general del dispositivo. Por otra parte, existe un cluster llamado «Device_Cluster» definido en el Perfil ZigBee-Tecnodiscap que permite en el dispositivo físico realizar las operaciones de habilitación, recuperación de información. . . Puede verse que de esta manera queda enlazadas las operaciones que puede realizar el dispositivo físico con las que permite realizar el objeto software que lo controla en el middleware. Para tratar de aclarar la relación entre Perfil ZigBee-Tecnodiscap y OSGi4AmI, vamos a describir tanto los endpoints y cluster implementados por nuestro dispositivo, así como los interfaces OSGi4AmI que implementara el objeto software. De esta manera se podrá ver la estrecha relación que guardan unos con otros. En las Figuras [3.8], [3.9]y[3.10] se encuentra las tablas de endpoints, clusters y algunos de los comandos y eventos implementados en el dispositivo desarrollado junto con los identificadores de categoría y de dispositivo. En el listado de endpoints destaca que el endpoint O4A_BASE_DEVICE es obligatorio implementarlo en cualquier dispositivo, es el endpoint que se encarga de de informar al software del 3.2 Middleware 25 Figura 3.8: Endpoints Implementados Figura 3.9: Clusters Implementados resto de endpoints implementados en el dispositivo. El resto de endpoints describen las diversas funcionalidades individuales en las que se puede dividir el dispositivo. En estas tablas se puede ver la relación entre el Perfil ZigBee-Tecnodiscap y OSGi4AmI, todo endpoint implementa el cluster DEVICE equivalente al interfaz Device de OSGi4AmI del que heredan todo los dispositivos. A su vez cada endpoint (a excepción del O4A_BASE_DEVICE) implementa uno de los siguientes clusters: SENSOR, ACTUATOR o SIMPLE_HMI, correspondientes a uno de los tres subtipos de dispositivos OSGi4AmI. Para aclarar más estos últimos conceptos puede compararse la definición de los interfaces OSGi4AmI: Device, Sensor (Figuras [3.11] y [3.12]) con los métodos y eventos de los clusters DEVICE y SENSOR (Figura [3.10]).Puede verse una correspondencia directa de métodos. Como resumen decir que OSGi4AmI es una ontología que permite la abstracción del hardware en la capa middleware y el Perfil ZigBee-Tecnodiscap en la forma en la que el middleware se comunica con el hardware, pero diseñados de una manera concordante permiten realizar comunicaciones eficientes debido a que cuando se requiere alguna información del hardware sólo se transmite la información mínima, alargando así la vida de la batería del dispositivo. 3.2.4. Integración en Driver Zigbee de Tecnodiscap Una vez explicados los conceptos de Perfil ZigBee-Tecnodiscap y OSGi4AmI e introducidos los clusters y endpoints Zigbee junto con los interfaces implementados, falta por explicar el 26 CAPÍTULO 3. FIRMWARE Y MIDDLEWARE Figura 3.10: Algunos Comandos y Eventos Implementados 3.2 Middleware 27 Figura 3.11: Interfaz OSGi4AmI Device Figura 3.12: Interfaz OSGi4AmI Sensor 28 CAPÍTULO 3. FIRMWARE Y MIDDLEWARE funcionamiento del driver ZigBee desarrollado por el grupo Tecnodiscap. El driver Zigbee consiste en el middleware que se encarga de gestionar la red ZigBee (crearla, descubrir los dispositivos existentes al inicio, gestionar la aparición de nuevos dispositivos. . . ), también es función de este driver la creación de los objetos software (dispositivos software) que controlan cada dispositivo presente en la red. Por último el driver publica en el framework OSGi los distintos dispositivos software para que puedan ser usados por los servicios de capas mas altas del software. El driver esta desarrollado de tal manera que resulte sencilla la incorporación de nuevos dispositivos desarrollados. Para ello cuando se descubre un nuevo dispositivo se le ejecuta el comando get_type perteneciente al endpoint BASA_DEVICE y cluster DEVICE que devuelve los endpoint implementados en el dispositivo. Contesta información el driver ya es capaz de montar cada uno de los subdispositivos que integran el dispositivo. Como es obvio para que el driver sea capaz de montar los diversos dispositivos software, primero han de estar programadas cada una de las clases que los representan. Pero esta tarea también resulta sencilla gracias a que todas estas clases extienden la clases genérica device, esto nos da acceso al stream de datos que llega por el puerto serie por lo que sólo queda realizar el procesado de estos datos. Para finalizar recalcar que el driver zigbee está implementado de tal manera que se puede implementar un nuevo dispositivo de una manera simple gracias a su implementación modular. Cap´ ıtulo 4 Desarrollo Software En este capítulo vamos a explicar el software creado para la utilización del dispositivo en aulas de estimulación multisensorial. El software desarrollado se ha realizado conjuntamente con Daniel Domínguez ya que él también ha desarrollado un dispositivo para aulas de estimulación multisensorial como proyecto fin de carrera. La dirección de ese proyecto fin de carrera también ha sido tarea de este trabajo fin de máster, las tareas llevadas a cabo durante esa dirección serán explicadas en el siguientes capítulo. 4.1. Aplicación de interacción entre dispositivos En capítulos anteriores hemos visto como a través del framework OSGi y de la ontología OSGi4AmI hemos sentados las bases para la creación de un sistema que permita añadir a las aulas de estimulación multisensorial dispositivos capaces de interactuar entre ellos y con el usuario. En esta sección vamos a mostrar una aplicación desarrollada para permitir a los profesores de educación especial configurar los diferentes dispositivos instalados en la sala para que interactúen unos con otros. Esta idea surge de la colaboración realizada con alumnos de diseño industrial, esta colaboración entre el grupo Tecnodiscap y los alumnos y profesores de diseño industrial se expondrá en el siguiente capítulo. En la Figura [4.1] puede verse el interfaz de usuario de la aplicación, como puede observarse se ha tratado de simplificar al máximo el interfaz dado que los profesores de educación especial no tienen porque estar habituados al manejo del ordenador. Se ha tratado de implementar un sistema intuitivo en el que el profesor sólo tiene que relacio- 29 30 CAPÍTULO 4. DESARROLLO SOFTWARE Figura 4.1: Interfaz de usuario de la aplicación nar un dispositivo tipo «sensor» con un dispositivo tipo «actuador». Se busca que el profesional tenga que relacionar una acción del usuario con una reacción del sistema. Por ejemplo, si el usuario toca o se acerca a algún objeto marcado con una etiqueta RFID concreta que el sistema reaccione cambiado el color de la luz ambiental. Esto se consigue gracias una lista de reglas activas y un método para añadir nuevas reglas. Como puede verse en la Figura [4.1], en la parte inferior de la aplicación puede verse una lista de reglas que pueden estar activas o no, a lección del profesor. También es posible añadir nuevas reglas y borrar las ya existentes. Para añadir nuevas reglas se utiliza la parte superior de la aplicación, en ella puede verse diferentes listas desplegables que permiten elegir los dispositivos sensores y actuadores para crear las nuevas reglas. El profesor debería primero elegir primero el dispositivo sensor, en esa lista aparecerá un nombre amigable para cada dispositivo desarrollado, por ejemplo para el dispositivo desarrollado en este trabajo fin de máster un nombre apropiado podría ser «Guante», una vez elegido el dispositivo, hay que elegir la acción del usuario a detectar, ya que puede darse el caso de que se pueda detectar diferentes acciones del usuario, siguiendo con el ejemplo del guante en la siguiente lista desplegable aparecerían las siguiente opciones: «RFID» o «Actividad», con RFID nos referimos a que se va a detectar la interacción de usuario con objetos marcados con etiquetas RFID; con Actividad nos referimos a que se va a detectar el nivel de actividad mediante el 4.1 Aplicación de interacción entre dispositivos 31 Figura 4.2: Panel para interacción entre RFID y luces acelerómetro que incorpora el dispositivo. Para concretar un poco más la acción a detectar se han añadido las dos listas desplegables siguientes, en la primera hay que elegir el un operador lógico, por ejemplo: =, >,<. . . en la siguiente hay que concretar el valor de comparación. Vamos a poner dos ejemplos aclaratorios, en el caso de haber seleccionado el dispositivo Guante y el sensor RFID, el operador sólo podría ser el simbolo «=», y el campo valor debería contener el identificador de una etiqueta RFID. Por otro lado si se hubiera seleccionado el dispositivo Guante y el sensor «Actividad», podría utilizarse cualquier operador lógico, ya que en la lista de posibles valore sólo aparecerían valores cuantitativos del estilo: poca actividad, actividad media, alta actividad . ..Por último sólo quedaría elegir el dispositivo sobre el que actuar y la acción que debe realizar dicho actuador, por ejemplo podríamos decir que se cambien las luces a un determinado color. En la Figura [4.2] se puede ver como con varias cartulinas de colores y tags RFID se ha realizado un panel para trabajar con la aplicación anterior. Tan sólo habría que incluir cuatro reglas en la aplicación para que cuando se detecte una de las cuatro etiquetas presentes en la cartulina se cambiase el color de las luces. 38 CAPÍTULO 6. CONCLUSIONES Y TRABAJOS FUTUROS perfectamente a las características que podría tener un sistema de sensores y actuadores que interactúan entre si. A parte de OSGi el sistema se fundamenta en un driver ZigBee que publica dispositivos conforme son dados de alta en la red ZigBee. Si a esto añadimos la capacidad de abstracción sobre la tecnología hardware que nos brinda la ontología OSGi4AmI obtenemos una arquitectura robusta que permite el desarrollo de dispositivos y su incorporación al sistema de una manera modular y que se ajusta muy bien a las característica necesarias en una aula de estimulación multisensorial. Basándonos en la arquitectura antes expuesta se ha desarrollado una aplicación básica que permite a los profesores de educación especial configurar los dispositivos presentes en el aula para que interactúen entre ellos. Esta configuración se basa en generar una serie de reglas del tipo «Si X entonces hacer Y». Esta aplicación puede ser mejorada más adelante conforme se vayan desarrollando nuevos dispositivos. Con todo esto se ha sentado las bases para desarrollar un sistema completo de dispositivos interactivos para aulas de estimulación multisensorial, el siguiente paso es validar el trabajo realiza con los profesores de educación especial a la vez que se van desarrollando nuevos dispositivos que complementen el sistema. Como tarea secundaria en este trabajo se ha llevado a cabo la dirección de un proyecto fin de carrera, el proyecto consistía en desarrollar un actuador de luces también para aulas de estimulación multisensorial. La experiencia ha resultado sumamente grata ya que el proyectando comenzó sin tener conocimientos sobre ciertas tecnologías como ZigBee, PSoC, Java. . . y ha acabado teniendo un nivel aceptable en la mayoría de ellas. Para concluir apuntar que la experiencia de diseñar un sistema que auna software y hardware para una aplicación real, en la que hemos tratado con diferentes personas con diferentes perfiles profesionales ha resultado sumamente gratificante y enriquecedora. 6.2. Futuros Trabajos La primera tarea después del desarrollo de los dispositivos y la aplicación de control es la validación con usuarios. Antes de proseguir es conveniente mostrar la aplicación a los profesores de educación especial y recoger sus opiniones y consejos de mejora. Por otra parte es necesario el desarrollo de nuevos dispositivos que aumenten las posibilidades de interacción del sistema. Para ello el grupo Tecnodiscap se encuentra en estos momentos 6.2 Futuros Trabajos 39 realizando propuestas de proyectos de investigación para obtener financiación para acometer los desarrollos. Una vez aparezcan nuevos dispositivos y ayudándonos del «feedback» que nos puedan dar los profesores de educación especial, habrá que acometer mejoras en la aplicación de configuración y desarrollar algún interfaz que permita al profesor controlar la sala en tiempo real mientras trabaja con un niño. Por otra parte y centrándonos en el dispositivo desarrollado una posible mejora es la de integrar en el firmware dispositivo la capacidad de monitorización de movimientos del usuario. Quizás esto requiera de la incorporación de nuevos sensores inerciales como giróscopos o magnetómetros. 40 CAPÍTULO 6. CONCLUSIONES Y TRABAJOS FUTUROS