Story Transcript
UNIVERSITAT JAUME I DE CASTELLÓ Escuela Superior de Tecnología y Ciencias Experimentales IS31 – Proyectos Informáticos de Sistemas Memoria técnica del proyecto
Procesamiento de datos en una red de sensores inalámbrica Director: Gabriel Recatalá Ballester Alumno: Emilio Agut Vilaplana Fecha: 10 – 09 - 2009
Procesamiento de datos en una red de sensores inalámbrica.
AGRADECIMIENTOS
Quiero agradecer la labor de muchas personas que directa o indirectamente han contribuido al desarrollo de este proyecto. En primer lugar, me gustaría agradecer la formación que me han dado todos y cada uno de los profesores a lo largo de la carrera que hoy termino. En especial a Gabriel Recatalá Ballester, el director de mi Proyecto Final de Carrera. Gracias por el trato que he recibido de él y por el buen rollo en cada una de las reuniones que hemos tenido, pero sobre todo, quiero agradecerle su implicación en este proyecto. También quiero agradecer a mi familia el apoyo incondicional ofrecido en todos estos años de estudio, tanto moral como económico. Gracias a Jessica, por quererme, aguantarme y ser un punto de apoyo único e imprescindible en mi vida.
Proyecto final de carrera - IS31
i
ii
AGRADECIMIENTOS
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
RESUMEN
El proyecto ha consistido en el diseño, implementación y validación experimental para el procesamiento de datos en una red de sensores inalámbricos. Los recursos de los que se ha dispuesto han sido varios motes micaz que forman los nodos inalámbricos de la red, una estación base mib520 a la que se le une un mote para recoger datos de la red en un ordenador, y varias placas de sensor mda100cb que recogen del medio en el que se encuentran datos de temperatura y luz ambiental. Estas placas de sensores unidas a los motes han formado la red de sensores inalámbrica. El proyecto se divide en tres aplicaciones en las que se han aprovechado los datos recogidos por los sensores de temperatura y luz ambiental, y la capacidad de movilidad y autonomía de los motes que forman la red de sensores inalámbricos. La primera de las aplicaciones detecta cuando incide un foco de luz artificial sobre un mote. A partir de detectar esta situación, la aplicación será capaz de detectar cuando no está incidiendo ese foco de luz artificial sobre el mote. Es decir, la red de sensores será capaz de determinar cuando una luz está encendida y cuando está apagada en cada uno de sus nodos. La segunda aplicación que forma este proyecto detecta subidas y bajadas bruscas de temperatura en un tiempo determinado. Es por ello que se ha creado una aplicación orientada a saber cuándo hay un posible fuego encendido en un espacio determinado, y cuando se está extinguiendo. En la tercera aplicación, se ha aprovechado el sensor de luz ambiental de la placa de sensor para detectar cuando es de día y cuando es de noche. La aplicación también detectará cuando se está haciendo de día y cuando se está haciendo de noche. Para cada una de las aplicaciones, se han desarrollado conjuntamente aplicaciones para reducir en la medida de lo posible el envío de paquetes innecesarios, contribuyendo de esa forma al ahorro energético en las baterías de los motes.
Proyecto final de carrera - IS31
iii
iv
RESUMEN
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
ÍNDICE AGRADECIMIENTOS ........................................................................i RESUMEN ..................................................................................... iii ÍNDICE ........................................................................................... v TABLA DE ILUSTRACIONES ............................................................ ix 1. INTRODUCCIÓN ......................................................................... 1 1.1. Motivación .................................................................................................. 1 1.2. Objetivos del proyecto ................................................................................ 2 1.3. Conceptos esenciales .................................................................................. 3 1.3.1. Introducción a las redes inalámbricas ................................................. 3 1.3.2. Introducción a las redes de sensores inalámbricos ............................. 4 1.4. Estructura del documento .......................................................................... 6
2. DESCRIPCIÓN DE LOS PROBLEMAS ............................................. 9 2.1. Introducción ................................................................................................ 9 2.2. Problema 1: detección de luz encendida / apagada .................................. 9 2.3. Problema 2: detección de fuego / no fuego ............................................. 10 2.4. Problema 3: detección de día / noche ...................................................... 12 2.5. Enfoque general: ahorro energético......................................................... 14
3. RECURSOS UTILIZADOS ............................................................ 17 3.1. Estructura general .................................................................................... 17 3.2. Recursos humanos .................................................................................... 18 3.3. Hardware de la red de sensores ............................................................... 19 3.3.1. Estación base: MIB520 ....................................................................... 19 3.3.2. Nodo inalámbrico: micaZ ................................................................... 20
Proyecto final de carrera - IS31
v
vi
ÍNDICE 3.3.3. Tarjeta de sensores: MDA100CB ....................................................... 21 3.4. Software de la red de sensores ................................................................. 22 3.4.1. MoteWorks ........................................................................................ 22 3.4.2. Visualizaciór de datos: MoteView ...................................................... 22 3.4.3. Programador de nodos: MoteConfig ................................................. 23 3.4.4. Entorno de programación: programmers Notepad 2 ........................ 25 3.4.5. TinyOs i NesC ...................................................................................... 25 3.5. Entorno de apoyo al desarrollo del proyecto ........................................... 27 3.6. Entorno de presentación: e-portafolio ..................................................... 27
4. PLANIFICACIÓN ........................................................................ 29 4.1. Metodología ............................................................................................. 29 4.2. Lista de tareas .......................................................................................... 30 4.3. Planificación inicial ................................................................................... 31
5. DISEÑO DE LA APLICACIÓN....................................................... 37 5.1. Detección de Luz encendida / apagada.................................................... 37 5.1.1. Enfoque .............................................................................................. 37 5.1.2. Clustering para agrupación de datos ................................................. 38 5.1.3. Diseño basado en el clustering .......................................................... 38 5.1.4. Algoritmo de detección ...................................................................... 39 5.2. Detección de Fuego / no fuego ................................................................. 42 5.2.1. Enfoque .............................................................................................. 42 5.2.2. Algoritmo de detección ...................................................................... 43 5.2.3. Algoritmo de envío ............................................................................. 45 5.3. Detección de Día / noche .......................................................................... 46 5.3.1. Enfoque .............................................................................................. 46
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
5.3.2. Algoritmo de detección ...................................................................... 46 5.3.3. Algoritmo de envío ............................................................................. 49
6. CONFIGURACIÓN Y PUESTA EN MARCHA DEL SISTEMA ............ 51 6.1. Puesta en marcha del sistema .................................................................. 51 6.2. Estructura del proyecto de una aplicación ............................................... 53 6.2.1. Makefile ............................................................................................. 53 6.2.2. Makefile.component .......................................................................... 54 6.2.3. Configuración de la aplicación ........................................................... 54 6.2.4. Módulo de implementación............................................................... 55
7. IMPLEMENTACIÓN ................................................................... 59 7.1. Software de la plataforma (MoteWorks) ................................................. 59 7.1.1. XMesh................................................................................................. 59 7.1.2. XServe................................................................................................. 60 7.2. Tipos de funciones .................................................................................... 60 7.2.1. Funciones para capturar datos .......................................................... 61 7.2.2. Funciones para procesar datos .......................................................... 61 7.2.3. Funciones para enviar datos .............................................................. 62 7.3. Elección de las aplicaciones ...................................................................... 62 7.3.1. Problema 1: detección de luz encendida / apagada .......................... 62 7.3.2. Problema 2: detección de fuego / no fuego ...................................... 63 7.3.3. Problema 3: detección de día / noche ............................................... 65 7.4. Problemas en la implementación ............................................................. 67 7.4.1. Problemas en luz encendida / apagada ............................................. 67 7.4.2. Problemas en fuego / no fuego ......................................................... 68 7.4.3. Problemas en día / noche .................................................................. 68
8. VALIDACIÓN EXPERIMENTAL.................................................... 71 Proyecto final de carrera - IS31
vii
viii
ÍNDICE 8.1. Detección de luz encendida / apagada .................................................... 71 8.2. Detección de fuego / no fuego ................................................................. 74 8.3. Detección de día / noche .......................................................................... 76
9. REVISIÓN FINAL DEL PROYECTO ............................................... 79 9.1. Planificación final ..................................................................................... 79
10. CONCLUSIONES ...................................................................... 83 10.1. Aplicaciones potenciales......................................................................... 83 10.2. Ampliación en futuros proyectos ............................................................ 84
Bibliografía .................................................................................. 85 APÉNDICE A.- CODIGO FUENTE .................................................... 87
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
TABLA DE ILUSTRACIONES
Ilustración 1: Gráfico del mote micaz ................................................................... 5 Ilustración 2: Gráfico de temperatura (pendiente positiva) .............................. 11 Ilustración 3: Gráfico de temperatura (pendiente negativa) ............................. 12 Ilustración 4: Gráfico de luminosidad para día / noche ..................................... 14 Ilustración 5: Estructura general del entorno de desarrollo .............................. 18 Ilustración 6: Estación Base mib520 ................................................................... 19 Ilustración 7: Mote micaz ................................................................................... 20 Ilustración 8: Sensor mda100cb ......................................................................... 21 Ilustración 9: Esquema de una red de sensores inalámbricos ........................... 23 Ilustración 10: Arquitectura XOtap ..................................................................... 24 Ilustración 11: Planificación inicial del 17 de noviembre al 27 de diciembre .... 32 Ilustración 12: Planificación inicial del 28 de diciembre al 7 de febrero ............ 32 Ilustración 13: Planificación inicial del 8 de febrero al 21 de marzo .................. 33 Ilustración 14: Planificación inicial del 22 de marzo al 2 de mayo ..................... 33 Ilustración 15: Planificación inicial de 3 de mayo al 13 de junio ........................ 34 Ilustración 16: Planificación inicial del 14 de junio al 25 de julio ....................... 34 Ilustración 17: Planificación inicial del 7 de agosto al 17 de septiembre ........... 35 Ilustración 18: Valor del umbral en fuego / no fuego ........................................ 44 Ilustración 19: Desplazamiento de muestras en fuego / no fuego .................... 45 Ilustración 20: Tiempo de recogida de muestras en día / noche ....................... 50 Ilustración 21: Interface de MoteConfig............................................................. 52 Ilustración 22: Interface de Programmers Notepad........................................... 52 Ilustración 23: Código de elección para luz encendida / apagada ..................... 63 Proyecto final de carrera - IS31
ix
x
TABLA DE ILUSTRACIONES Ilustración 24: Código de elección para fuego / no fuego.................................. 64 Ilustración 25: Código de my_send_radio_msg2 ............................................... 65 Ilustración 26: Código de elección entre día / noche ......................................... 66 Ilustración 27: Código de my_send_radio_msg3 ............................................... 66 Ilustración 28: Motes ejecutando la aplicación de luz encendida / apagada .... 72 Ilustración 29: Captura de datos en luz encendida / apagada ........................... 73 Ilustración 30: Resultados en luz encendida / apagada ..................................... 73 Ilustración 31: Motes ejecutando la aplicación de fuego / no fuego ................. 74 Ilustración32: Captura de datos en fuego / no fuego ........................................ 75 Ilustración 33: Resultados en fuego / no fuego.................................................. 75 Ilustración 34: Captura de datos en día / noche ................................................ 77 Ilustración 35: Resultados en día / noche .......................................................... 77 Ilustración 36: Planificación final del 17 de noviembre al 27 de diciembre....... 79 Ilustración 37: Planificación final del 28 de diciembre al 7 de febrero .............. 80 Ilustración 38: Planificación final del 8 de febrero al 21 de marzo .................... 80 Ilustración 39: Planificación final del 22 de marzo al 2 de mayo ....................... 81 Ilustración 40: Planificación final del 3 de mayo al13 de junio .......................... 81 Ilustración 41: Planificación final del 14 de junio al 25 de Julio ......................... 82 Ilustración 42: Planificación final del 11 de agosto al 21 de septiembre ........... 82
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
1. INTRODUCCIÓN
En este capítulo se pretende dar a conocer cuáles han sido las motivaciones principales para realizar este proyecto. Además se van a exponer cuales son los objetivos del proyecto y como está estructurado este documento.
1.1. MOTIVACIÓN
Una red de sensores inalámbricos consiste en la posibilidad de un largo número de dispositivos inalámbricos capaces de tomar medidas del entorno. Los ejemplos típicos de estas medidas son temperatura, luz, sonido y humedad. Las lecturas de sensor son transmitidas sobre un canal inalámbrico a una aplicación que se está ejecutando y toma decisiones basadas en esas lecturas de sensor. Hay muchas aplicaciones que han sido propuestas para redes de sensores inalámbricos, y muchas de estas aplicaciones tienen requerimientos de servicios de calidad específicos (QoS) que ofrecen desafíos adicionales al diseñador de la aplicación [1]. Para el desarrollador de este documento la principal motivación ha venido a raíz de tratarse del proyecto final de carrera, así que se pensó en dedicar la última parte de la carrera en algo que tuviera una aplicación real y surgió la idea de la red de sensores inalámbrica. Cuando se empezó a determinar el ámbito de este proyecto, enseguida se pensó en aprovechar las capacidades de los motes, los cuales son capaces de enviar los datos capturados por los sensores unidos a ellos a una estación base, o incluso enviarse la información unos a otros para llegar a la estación base. Entre los objetivos iniciales del proyecto estarían el planteamiento de ciertas situaciones medioambientales en las que pueden ser útiles los datos capturados por los sensores y procesar estos datos capturados por los sensores obteniendo una buena precisión en la medida de lo posible.
Proyecto final de carrera - IS31
1
2
INTRODUCCIÓN
1.2. OBJETIVOS DEL PROYECTO
El objetivo principal del proyecto es diseñar e implementar un sistema de procesamiento de los datos recibidos por los sensores que pueda ser integrado en la plataforma proporcionada de desarrollo utilizada. Una de las funcionalidades soportadas que nos va a ser de gran utilidad son la monitorización de la red y el almacenamiento de la información sobre una base de datos. El segundo de los objetivos será obtener la máxima precisión a la hora de ajustar los parámetros que harán saltar las alarmas en cada una de las tres situaciones comentadas anteriormente. En cada uno de estos tres casos la precisión vendrá dada por el ajuste de ciertos parámetros para identificar i/o distinguir entre las distintas situaciones posibles. El tercer objetivo será disminuir el coste energético en la medida de lo posible. Los nodos están alimentados por baterías y, en la mayoría de las ocasiones, no es viable reemplazarlas, por lo que el ahorro de energía es uno de los aspectos clave porque se desea que los nodos sean independientes y activos el mayor tiempo posible. La acción que más consume energía es el envío de paquetes, por lo que la gestión de este envío y su frecuencia es clave para el ahorro de energía. La prevención de incendios forestales siempre ha sido un tema al que aportar solución, así que se pensó en la posibilidad de aprovechar el sensor de temperatura y la capacidad de la red inalámbrica para prevenir este problema. Para llegar a una solución se podría repartir un conjunto amplio de motes alrededor de un bosque, procesar los datos capturados por el sensor de temperatura de estos motes con la intención de identificar el fuego, y que los motes aprovechen la capacidad de su micro controlador, enviándose unos a otros los datos del entorno y unas alarmas de fuego cuando se requiera. Entonces surgió la idea de crear código que procesara los datos capturados del entorno y no sólo tratar el problema del fuego sino otras dos situaciones como: detectar cuando una luz artificial está encendida y apagada, y detectar cuando es de día y cuando de noche. Obviamente el problema de la luz encendida y apagada se ejecutaría en zonas interiores, y el problema de día y noche en zonas exteriores. El problema del fuego se podría ejecutar tanto en zonas interiores como en exteriores.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
1.3. CONCEPTOS ESENCIALES
1.3.1. INTRODUCCIÓN A LAS REDES INALÁMBRICAS
Las redes inalámbricas son un conjunto autónomo y espontáneo de nodos móviles, conectados por enlaces inalámbricos que no precisan de una infraestructura fija. La red ese denomina inalámbrica porque cada nodo está preparado para reenviar datos a los demás y la decisión sobre qué nodos reenvían los datos se toma de forma dinámica en función de la conectividad de la red. Estas redes se proyectan para operar en ambientes hostiles e irregulares, siendo capaces de modificar su topología para adoptar nuevas formas y mantener la red igual de funcional. Sus aplicaciones en la actualidad resultan ser muy extensas, tales como redes de área personal, entornos militares, entornos ciudadanos, operaciones de emergencia y recolección de información medioambiental, como los más destacados [3]. Las características de este tipo de redes se detallan a continuación: Movilidad: Los nodos pueden ser móviles de manera que la topología de la red pueda cambiar continuamente, creándose y destruyéndose los enlaces dinámicamente.
Nodos autónomos y sin infraestructura: No se dispone de una administración centralizada, cada nodo opera en modo “peer-to-peer” actuando como un router independiente.
Encaminamiento “multihop” (múltiples saltos): No se requiere un router dedicado al encaminamiento, cada nodo de la red se comporta como un router y envía paquetes procedentes de otros nodos.
Ancho de banda limitado: Al disponer de una interfaz inalámbrica las comunicaciones se ven atenuadas por interferencias de señales electromagnéticas.
Proyecto final de carrera - IS31
3
4
INTRODUCCIÓN Consumo de energía: Los nodos están alimentados por baterías. El control de la potencia se vuelve un aspecto clave para estas redes, puesto que se desea que los nodos sean independientes y activos el mayor tiempo posible.
1.3.2. INTRODUCCIÓN A LAS REDES DE SENSORES INALÁMBRICOS
Las redes de sensores inalámbricos han atraído mucho el interés de la industria debido a su gran diversidad de aplicaciones. El rutado es uno de los principales problemas a resolver en redes de sensores inalámbricas. En este proyecto se utilizan unos nodos denominados motes, que son los que forman la red inalámbrica adquiriendo entre ellos la topología que más convenga en cada caso, los motes constan de tres partes fundamentales (ilustración 1): La primera es el sensor, es una placa que se acopla al mote y las hay de varios tipos, en nuestro caso utilizaremos una placa que captura del medio datos de temperatura y luz ambiental.
La segunda parte fundamental es el módulo de cálculo, consta de un micro controlador integrado en el mote que es el que realiza las operaciones necesarias y el que se encargará de procesar los datos capturados por el sensor.
La tercera parte es el módulo de comunicación, en el mote se suele cargar el módulo que corresponda con el tipo de placa de sensor acoplada.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Ilustración 1: Gráfico del mote micaz
Una red de sensores inalámbrica aportará al proyecto muchas características como: [4] Multihop: es la capacidad de enviar mensajes punto a punto hacia la estación base, por ello el rango de extensión es escalable.
Auto - configuración: es la capacidad de formar una red sin intervención humana.
Auto - adaptabilidad: es la capacidad de añadir y borrar nodos en la red de forma automática, esto se consigue sin tener que reiniciar la red.
Enrutamiento dinámico: es la capacidad de adaptabilidad en la determinación del enrutamiento basado en condiciones de red dinámica.
El despliege de una red inalámbrica está formado de tres capas de software distintas. [4] La capa cliente facilita al usuario de un software de visualización y de una interfaz gráfica para poder dirigir la red. Crossbow facilita un cliente gratuito de software (MoteView).
Proyecto final de carrera - IS31
5
6
INTRODUCCIÓN
La capa servidor es una capa que trata la traducción y el buffering de datos de la red inalámbrica y establece un puente entre los motes inalámbricos y los clientes de internet.
La capa de mote es el software que se ejecuta cuando un conjunto de nodos con sensores forman una red inalámbrica de sensores de tipo mesh. Hay un software (XMesh) que facilita los algoritmos de enrutamiento requeridos para establecer una correcta comunicación.
1.4. ESTRUCTURA DEL DOCUMENTO
La presente memoria se estructura en diez capítulos y un anexo. A continuación se ofrece una breve descripción de los contenidos tratados en cada capítulo.
Capítulo 1: Introducción En este capítulo, se ha pretendido dar una visión general de cuales han sido las motivaciones para realizar este proyecto, así como describir los objetivos fundamentales del mismo. La propuesta técnica del proyecto, viene desglosada en tres capítulos que son los tres siguientes: capítulo 2, capítulo 3 y capítulo 4.
Capítulo 2: Descripción de los problemas En el capítulo 2 se presentan los tres situaciones de temperatura y luminosidad que se han abordado en este proyecto sin entrar en detalles, y el porqué se han elegido resolver estas tareas. En cada una de ellas se comenta la importancia del ahorro energético en este tipo de aplicaciones y cuál ha sido la solución que hemos llevado a cabo.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Capítulo 3: Entorno de desarrollo Se pretende dar una descripción del hardware que su utiliza para hacer las capturas de datos así como del software para cargar las aplicaciones en los motes y programarlas. Por último, se explica la importancia que tiene el software de la plataforma y las características del sistema operativo sobre el que funciona la plataforma de trabajo, así como el lenguaje en el que está escrito el código que funciona sobre él.
Capítulo 4: Planificación Se describe la metodología seguida para la realización del proyecto, la lista de las tareas que hemos tenido que ir resolviendo para la ejecución del proyecto, y la planificación inicial de las mismas.
Capítulo 5: Diseño de la aplicación Es en el capítulo 5 en el que se verá la metodología que se ha seguido para crear las aplicaciones en cada uno de los tres problemas abordados. En este capítulo se verá qué es y cuál es la importancia del clustering en relación con el procesamiento de datos.
Capítulo 6: Configuración y puesta en marcha del sistema En este capítulo se verá cual es la estructura que tiene una aplicación y que es lo que hay que hacer para poner en marcha el sistema.
Capítulo 7: Implementación El objetivo de este capítulo, es el de clasificar las funciones utilizadas en tres grupos. También el de dar las instrucciones necesarias para que el usuario de esta aplicación sepa configurar el sistema para usarlo en uno de los tres modos disponibles, luz encendida / apagada, fuego / no fuego, día / noche. Para finalizar se hablará de cuales han sido los principales problemas que han surgido en la implementación de las aplicaciones.
Proyecto final de carrera - IS31
7
8
INTRODUCCIÓN Capítulo 8: Validación experimental Para cada uno de los tres problemas se van a presentar los resultados obtenidos a raíz de una serie de experimentos para validar de forma realista las soluciones propuestas a los problemas considerados.
Capítulo 9: Revisión final del proyecto En este capítulo se mostrará la planificación final del proyecto en comparación con la planificación inicial.
Capítulo 10: Conclusiones Primero se exponen las aplicaciones potenciales, que son una serie de entornos y situaciones en las que este proyecto podría jugar un buen papel, ya que los resultados obtenidos serían de gran ayuda para percatarse desde la estación base de que se están dando ciertas condiciones de temperatura y luminosidad a tener en cuenta. También se darán a conocer las posibles continuaciones que puede tener este proyecto para hacer de él un sistema más completo en muchos sentidos, interfaz gráfica, montaje en robots, sistemas de localización, mapas de coordenadas, etc.
Apéndice A: Codigo fuente En este anexo se volcará el código fuente escrito para cada uno de los problemas implementados.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
2. DESCRIPCIÓN DE LOS PROBLEMAS
En este capítulo se va a abordar la parte principal del proyecto, las cuatro situaciones de temperatura y luminosidad que se quieren monitorizar para obtener información del entorno más concreta, también se hablará sobre el ahorro energético.
2.1. INTRODUCCIÓN
El proyecto consiste en crear ciertas funcionalidades en una red de sensores inalámbricos. Para ello se dispone de un conjunto tan amplio como se quiera de motes con sensores que conforman esta red, así como una colección de archivos los cuales permiten recoger y almacenar los datos leídos de los sensores, así como editarlos para sacar el máximo rendimiento de los motes y los sensores.
2.2. PROBLEMA 1: DETECCIÓN DE LUZ ENCENDIDA / APAGADA
La primera de las situaciones a resolver en el proyecto a la hora de capturar datos con los sensores es la de detectar cuándo una luz está encendida y cuándo está apagada. El mote que lleva conectado el sensor ha de ser capaz de saber cuando un foco de luz está incidiendo sobre él y cuando no. Esto significa que el valor de luz encendida y el valor de luz apagada no será el mismo en todos los emplazamientos en los que pueda encontrarse un mote, ya que no en todas las habitaciones entra la misma luz natural. Así que cuando incida el foco de
Proyecto final de carrera - IS31
9
10
DESCRIPCIÓN DE LOS PROBLEMAS luz sobre un mote dará un valor para luz encendida y otro para luz apagada más alto o más bajo dependiendo de la luz natural que reciba. Al principio de la implementación de este problema el objetivo era conseguir que se clasificaran las muestras, siempre y cuando los valores para determinar que la luz está encendida y apagada fueran los mismos. Cuando conseguimos esta tarea es cuando nos planteamos que existe la necesidad de hacer el clasificador de luz de forma dinámica. Así que la solución estuvo en basarnos en el clustering, cogimos una idea del método de clustering jerárquico y de forma parecida la adaptamos a nuestra situación. En el capítulo 4 se explicará cómo se ha procedido para que la función que procesa la información recibida de los sensores clasifique entre luz encendida y apagada en diferentes condiciones de luz ambiental, también se hablará de la idea del clustering.
2.3. PROBLEMA 2: DETECCIÓN DE FUEGO / NO FUEGO
La segunda de las situaciones a resolver es la de detectar cuando hay un fuego alrededor de un mote y cuando no lo hay, esto es posible gracias al sensor de temperatura que lleva incorporado la placa xmda100cb. Para sacar estos resultados vamos a tomar la diferencia de la temperatura entre n muestras capturadas por el sensor, con esta diferencia y las n muestras se calcula una pendiente que es el resultado de dividir la diferencia de temperaturas entre las n muestras. Si está pendiente sale superior a un umbral se pondrá una señal de alarma en el campo adc6 que hay dentro del paquete de datos enviado por el mote hacia la estación base, indicando que la temperatura en la zona cercana al mote está subiendo (ilustración 6). De igual manera, cuando la temperatura esté bajando la pendiente saldrá negativa, y si el valor absoluto de esta supera el umbral establecido significa que el fuego se está extinguiendo, por tanto se enviará una señal de alarma dentro del campo adc6 indicando que la temperatura en la zona cercana al mote está bajando (ilustración 7). El valor de la pendiente saldrá siempre en valor absoluto ya que el NesC solo permite usar variables enteras sin signo. Así que para saber el signo de la pendiente habrá una variable que lo indique de la siguiente manera, si el valor 1 es menor que el
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
valor n la pendiente será positiva, y si el valor 1 es mayor que el valor n la pendiente será negativa Cabe destacar en esta situación que se ha contribuido al ahorro energético. La solución que se ha llevado a cabo ha sido la de hacer una función para que no se envíen los paquetes de datos con la regularidad que hay por defecto (cada 2 segundos), sino que en este caso los paquetes de datos con las alarmas (campo adc6), valores de temperatura, valores de luminosidad y demás datos, se enviarán hacia la estación base siempre que salte una alarma de fuego encendido o fuego extinguido, o en su defecto cada 50 muestras, es decir, si no salta una alarma al cabo de 50 muestras se enviará el paquete de datos para que el usuario pueda comprobar que todo va bien alrededor de los motes. Esta solución se ha llevado a cabo construyendo una nueva función, que lleva un contador en el que al cabo de 50 muestras o cuando el campo adc6 del paquete de datos es distinto de 0, envía el paquete de datos hacia la estación base.
Ilustración 2: Gráfico de temperatura (pendiente positiva)
Proyecto final de carrera - IS31
11
12
DESCRIPCIÓN DE LOS PROBLEMAS
Ilustración 3: Gráfico de temperatura (pendiente negativa)
Tanto si la pendiente es positiva (subida de temperatura) como si es negativa (bajada de temperatura) se cumple que:
2.4. PROBLEMA 3: DETECCIÓN DE DÍA / NOCHE
La tarea de crear una función que determine si es de día o de noche a partir de los datos de luminosidad recogidos por el sensor en una ubicación en concreto no ha sido fácil, ya que existen gran cantidad de emplazamientos distintos donde colocar un mote y cada emplazamiento tiene unas condiciones de luz ambiental distintas, por ejemplo, no es lo mismo colocar el sensor en un bosque donde no existe contaminación lumínica, que en una terraza ubicada en el centro de una ciudad. En la terraza hay mucha más contaminación lumínica, este tipo de situación nos lleva a plantearnos el siguiente problema.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Si suponemos que el sensor tiene que determinar cuándo se pasa de día a de noche en un lugar donde hay contaminación lumínica, tendremos que tener en cuenta que habrá un momento en el que se encenderán farolas, pasarán coches con los faros puestos y habrá otras situaciones que puedan causar un cambio brusco de luminosidad. Esto es lo que representa la mayor dificultad del problema ya que hay que tener en cuenta este tipo de situaciones. Para solucionar este problema se recurre a la idea de la pendiente usada en el problema de fuego / no fuego, combinada con un valor absoluto por encima del cual diremos que es de día y otro valor absoluto por debajo del cual diremos que es de noche. La idea es tomar muestras de luminosidad cada minuto, y cada n muestras calcularemos la diferencia entre la primera muestra y la enésima. Luego se calcula la pendiente dividiendo esta diferencia entre el número n de muestras tomadas, calculando así la pendiente. A continuación se compara el valor de esta pendiente con un umbral, por debajo del cual se considera que la pendiente es plana y por encima del cual se considera que la pendiente no es plana. Una vez tenemos estos datos, si la pendiente es plana se considerará que es de día o es de noche según sea la última muestra tomada mayor que el umbral de día o menor que el umbral de noche. Si la pendiente no es plana significa que estamos en una situación de transición, es decir, que se está haciendo de día o se está haciendo de noche. Para saber cuál de los dos casos se está dando, se mirará el signo de la pendiente, si el signo es positivo (la primera muestra es menor que la segunda) se considerará que se está haciendo de día, y si el signo es negativo (la primera muestra es mayor que la segunda) se considerará que se está haciendo de noche. En el caso de que la pendiente no sea plana se puede dar el caso de que el valor de luminosidad esté por encima del umbral de día o por debajo del umbral de noche, por lo que se considerará que es de día o de noche respectivamente.
Proyecto final de carrera - IS31
13
14
DESCRIPCIÓN DE LOS PROBLEMAS
Ilustración 4: Gráfico de luminosidad para día / noche
La ilustración 3 muestra gráficamente cuando se considera que una pendiente es plana o no plana y cuáles son los umbrales de día y de noche.
2.5. ENFOQUE GENERAL: AHORRO ENERGÉTICO
Las redes de sensores Crossbow pueden ejecutar diferentes estrategias de consumo de energía. Cada estrategia es una combinación entre el consumo de energía y el rango de datos capturados. Para los sistemas que tienen una alimentación continuada XMesh-HP es la mejor solución. Esta ofrece la mejor captura de datos con más continuación que cualquiera. Para los sistemas que utilizan baterías y requieren tener energía durante varios mese o varios años, XMesh-LP y XMesh-ELP son los que se usan normalmente [6]. En este caso, interesa que se capturen datos de temperatura y luz ambiental a menudo, pero no se quiere que estos datos sean enviados a la estación base a no ser que cambie el estado que corresponda en cada uno de los tres casos ya descritos. Para lograr esto se han hecho unas funciones especiales (my_send_radio_msg), en las que se pondrán las condiciones específicas para las cuales se quiere que se envíen los paquetes de datos, si se cumplen estas condiciones significa que ha
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
cambiado el estado que se está analizando o que ha pasado cierto tiempo sin que cambie el estado, entonces el paquete de datos será enviado. Si no se cumplen estas condiciones no se enviará nada.
Proyecto final de carrera - IS31
15
16
DESCRIPCIÓN DE LOS PROBLEMAS
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
3. RECURSOS UTILIZADOS
Este capítulo describe el software y hardware utilizados, así como del hardware de la plataforma que provee Crossbow para trabajar con redes inalámbricas de sensores. También se habla del sistema operativo y el lenguaje que se ha usado para la realización del proyecto.
3.1. ESTRUCTURA GENERAL
La estructura general del entorno de desarrollo (ilustración 4) consta de una estación base mib520, con un mote conectado sobre ella que es el que se encargará de las comunicaciones a los nodos de la red de sensores inalámbricos. Esta estación base va conectada al ordenador vía usb, y el ordenador se encarga de monitorizar los datos recibidos de la red de sensores gracias al software MoteView. La red de sensores inalámbricos, por su parte, la forman varios motes micaz con una placa de sensor mda100cb conectada a cada mote, estas placas de sensor recogen datos de temperatura y luminosidad del medio en el que se encuentran. Los datos recogidos por la red de sensores serán procesados para una de las situaciones ya descritas, y enviados a la estación base para ser monitorizados. Para hacer los experimentos correspondientes al desarrollo de este proyecto, habrá un usuario humano que usará herramientas de desarrollo i presentación que se usan en el proyecto.
Proyecto final de carrera - IS31
17
18
RECURSOS UTILIZADOS
Ilustración 5: Estructura general del entorno de desarrollo
3.2. RECURSOS HUMANOS
Los recursos humanos que se han utilizado en este proyecto han sido: El director del proyecto: Ha apoyado al alumno en tareas de diseño de las aplicaciones, revisión del código implementado y revisión de la memoria. También ha dado instrucciones a cerca de cómo funciona la plataforma.
El estudiante: Ha desarrollado este proyecto en su totalidad.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
3.3. HARDWARE DE LA RED DE SENSORES
3.3.1. ESTACIÓN BASE: MIB520
La estación base es la encargada de actuar de mediadora entre la red inalámbrica de sensores y el ordenador. Un nodo que se encuentre emplazado sobre la estación base es capaz de recibir paquetes de la red o enviar paquetes vía el puerto USB hacia el ordenador. El modelo de placa del que se dispone usa el puerto USB para las comunicaciones con el PC, pero otros modelos existentes disponen de otros sistemas. El modelo sobre el que se va a desarrollar el proyecto es el mib520 (ilustración 1). El fabricante provee de unos “drivers” para cada modelo de estación base, que generan dos COMMs de comunicaciones, uno para la programación de los nodos y otro para escuchar los paquetes provenientes de la red inalámbrica. Normalmente, el COMM con identificador más bajo es el empleado para la programación y el alto para las comunicaciones. La plataforma, así como los drivers suministrados, se encuentran disponibles solo para entornos Windows, por ese motivo el desarrollo se ha desenvuelto sobre este sistema operativo.
Ilustración 6: Estación Base mib520
Proyecto final de carrera - IS31
19
20
RECURSOS UTILIZADOS
3.3.2. NODO INALÁMBRICO: MICAZ
Los nodos inalámbricos poseen una fuente de energía propia, que no es más que un par de baterías AA emplazadas en el nodo. Como ya se comento anteriormente, este tipo de red se caracteriza por reducir los costes energéticos, consiguiendo así prolongar el tiempo de vida medio de cada uno de los nodos que integran la red. El modelo disponible se corresponde con un micaz a 2.4 GHz. Se componen de un microprocesador, una memoria flash, un modulo de radio, un pin 51 para las conexiones entre dispositivos, tres Leds y un identificador generado por el fabricante.
Ilustración 7: Mote micaz
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
3.3.3. TARJETA DE SENSORES: MDA100CB
En la actualidad, Crossbow ha diseñado una amplia gama de sensores compatibles con su plataforma, los cuales cubren diferentes aspectos según las necesidades que se tengan. El modelo del que se dispone es un modelo empleado en las labores de captura de valores medio ambientales, encontrándose disponibles la medición de la temperatura y la luz ambiental. El modelo recibe el nombre de mda100cb y se puede encontrar una imagen en la ilustración 3. Para los fines fijados en el proyecto se capturarán tanto datos de temperatura come de luz ambiental, y estos datos son los que se van a procesar para sacar información específica a cerca del entorno en el que se encuentran estos sensores.
Ilustración 8: Sensor mda100cb
Proyecto final de carrera - IS31
21
22
RECURSOS UTILIZADOS
3.4. SOFTWARE DE LA RED DE SENSORES
3.4.1. MOTEWORKS
MoteWorks, es una completa plataforma de desarrollo de software para aplicaciones de redes de sensores inalámbricas. Esta plataforma está compuesta de las siguientes partes: Manual de MoteWorks. Instalador de MoteWorks Manual de MoteView Instalador de MoteView Guía de inicio rápido de MoteWorks Manual de XMesh Manual de XServe
3.4.2. VISUALIZACIÓR DE DATOS: MOTEVIEW
MoteView está diseñado para ser una interfaz (de capa cliente) entre el usuario y la red de sensores inalámbricos desplegada. MoteView proporciona las herramientas para simplificar el desarrollo y la monitorización. También resulta fácil conectarse a una base de datos para volcar en ella los resultados obtenidos por los sensores, analizar estos datos y crear gráficos a partir de las lecturas de los sensores [4]. La ilustración 8 representa un esquema en tres partes para desarrollar un sistema de red de sensores. La primera parte es la capa de mote en la cual los motes están programados con un firmware de XMesh / TinyOs para hacer una tarea específica. La segunda capa o capa de servidor proporciona registro de datos y servicios de base de datos, en esta capa es donde llegan las lecturas de los sensores a la estación base y son guardados en un servidor. La tercera parte es la capa del cliente, en la cual las herramientas de software proporcionan visualización, monitorización, y herramientas de análisis para visualizar e interpretar los datos del sensor.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Ilustración 9: Esquema de una red de sensores inalámbricos
3.4.3. PROGRAMADOR DE NODOS: MOTECONFIG
MoteConfig es una utilidad GUI basada en Windows para programar motes. Esta utilidad proporciona una interfaz para configurar y descargar aplicaciones Xmesh/TinyOs de firmware pre-compiladas en los motes. MoteConfig permite al usuario configurar parámetros del mote como el mote ID, el grupo ID, el RF Channel y el RF Power. El usuario puede también habilitar la característica “over-the-airprogramming”, la cual está presente en todo el firmware basado en XMesh. Las aplicaciones XMesh de alta potencia y de baja potencia están disponibles para cada placa de sensor fabricadas por Crossbow como parte de la instalación del MoteView [5]. Over - the - air – programming
La característica “over-the-air-programming” (OTAP) permite al usuario reprogramar un Mote a través de un enlace wireless. OTAP permite que uno o más motes en la red Mesh reciban nuevas imágenes de firmware desde XServe (a través del servicio XOtap). En la Ilustración 9 se muestra el esquema de la arquitectura XOtap. El servicio OTAP está disponible solo cuando los motes están programados con una aplicación de firmware de consumo alto de energía.
Proyecto final de carrera - IS31
23
24
RECURSOS UTILIZADOS Cada mote tiene una memoria flash externa no volátil de 512 KB dividida en 4 slots. Estos slots tienen un tamaño por defecto de 128 KB. El slot 0 está reservado para la imagen OTAP. Los slots 1, 2 y 3 pueden ser usados para firmware de uso específico. Durante el proceso OTAP, el servidor envía un comando al mote para reiniciarlo dentro de la imagen OTAP (slot 0). La imagen de firmware específica para el usuario es dividida en fragmentos, transmitida al mote y guardada en el slot 1, 2 o 3. Así el servidor podrá ahora enviar un mensaje al mote para transferir el nuevo firmware subido a la memoria flash y reiniciar el mote. Para trabajar en modo OTAP, son requeridos los siguientes componentes: XServe y XOtap funcionando en el servidor. Las aplicaciones de firmware que incluyen el componente XOtapLiteM (viene incluido en el XMesh). El mote necesita estar pre configurado con un gestor de arranque en el programa, y tener la imagen OTAP en el slot 0 de la flash externa. Ambas condiciones son alcanzables seleccionando la casilla “OTAP enable” durante el proceso de descarga de MoteConfig.
Ilustración 10: Arquitectura XOtap
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
3.4.4. ENTORNO DE PROGRAMACIÓN: PROGRAMMERS NOTEPAD 2
La plataforma MoteWorks provee de Programmers Notepad 2, una herramienta que dispone de un compilador acondicionado para el sistema operativo TinyOs. Esta ha sido la plataforma sobre la que se ha desarrollado el código del proyecto.
3.4.5. TINYOS I NESC
El sistema operativo que poseen los nodos de la red inalámbrica, recibe el nombre de TinyOs y permite la ejecución de programas en el hardware de que disponen. Está basado en componentes para redes inalámbricas de sensores y escrito en el lenguaje de programación NesC, como un conjunto de tareas y procesos que colaboran entre sí. Su diseño permite la incorporación de nuevas innovaciones rápidamente y hace que funcione bajo las importantes restricciones de memoria que se dan en este tipo de redes [2]. TinyOs proporciona interfaces, módulos y configuraciones específicas, que permiten a los programadores construir programas como una serie de módulos que hacen tareas especificas. Los módulos de TinyOs proporcionan interfaces para los tipos estándar de entradas y salidas de hardware y sensores. A continuación se muestran las características más importantes del lenguaje NesC.
3.4.5.1. CARACTERÍSTICAS DE NESC
NesC (network embedded systems C), es una extensión de C diseñada para el modelo de ejecución y las estructuras del sistema operativo TinyOs. Sus principales características son las siguientes:
Separación de la construcción y la composición: Los programas están compuestos de componentes, que se montan, para formar un conjunto de
Proyecto final de carrera - IS31
25
26
RECURSOS UTILIZADOS programas. Los componentes se definen en dos ámbitos, la especificación (contiene los nombres de las instancias de sus interfaces) y la implementación.
Especificación del comportamiento de los componentes, en términos de un conjunto de interfaces: Las interfaces pueden ser proporcionadas o usadas por el componente. Las que son proporcionadas representan la funcionalidad que el componente proporciona al usuario. Por otro lado, las que son usadas por el componente representan, aquella funcionalidad que el componente requiere para llevar a cabo su trabajo.
Las interfaces son bidireccionales: Las interfaces especifican un conjunto de funciones a ser implementadas por el proveedor de la interfaz (comandos) y un conjunto a ser implementado por la interfaz del usuario solicitante (eventos). Esto permite una única interfaz para representar una interacción compleja entre componentes.
Los componentes son enlazados entre sí a través de sus interfaces: Esto aumenta la eficiencia en tiempo de ejecución, propicia un diseño robusto, y permite un mejor análisis de los programas.
Uso de compiladores específicos: NesC está diseñado bajo la expectativa de que el código será generado por los compiladores compatibles con TinyOs.
Tareas y manejadores de interrupciones: El modelo de concurrencia de NesC está basado en ejecutar tareas al completo, y manejar interrupciones las cuales permitan interrumpir la ejecución de las tareas y otros procedimientos por el estilo.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
3.5. ENTORNO PROYECTO
DE
APOYO
AL
DESARROLLO
DEL
Durante la realización del proyecto, se ha utilizado una herramienta de apoyo al desarrollo, esta herramienta es el entorno Forja UJI, alojado en http://forja.uji.es. Forja UJI reúne algunos de los proyectos llevados a cabo por la universidad Jaume I. Tanto proyectos de alumnos como proyectos institucionales liberados bajo las premisas del "open source". Las herramientas que ofrece forja UJI son: Gestión de usuarios por roles. Foros. Gestión de bugs, tareas, funcionalidades, etc. Gestión de documentación. Noticias. Repositorio SVN. Publicación de “releases”. Wiki: sitio web cuyas páginas web pueden ser editadas por múltiples voluntarios a través del navegador web.
3.6. ENTORNO DE PRESENTACIÓN: E-PORTAFOLIO
Como entorno de presentación del proyecto al tribunal, se ha utilizado una herramienta piloto denominada Mahara, donde se incluye un portafolio en el que presentar el proyecto. Un e-portafolio, portafolio electrónico o dossier electrónico de aprendizaje, es una selección de materiales que demuestran aquello que alguien ha aprendido en un periodo de tiempo determinado. Suele contener tanto los materiales (los trabajos realizados que demuestran unas aptitudes o competencias) como las reflexiones del autor que ponen en relación los diversos elementos entre ellos y con los objetivos de aprendizaje.
Proyecto final de carrera - IS31
27
28
RECURSOS UTILIZADOS El autor de un e-portafolio (el estudiante, aprendiz, etc.) típicamente diseña el portafolio y lo presenta a una cierta audiencia para un propósito determinado. Mahara es la aplicación de portafolio que se usa en las experiencias piloto del proyecto e-portafolio de la UJI.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
4. PLANIFICACIÓN
Tras hacer una introducción de forma general, este capítulo se centrará en la organización inicialmente prevista de los recursos y las tareas a llevar a cabo para realizar este proyecto.
4.1. METODOLOGÍA
Desde un principio como objetivo principal del proyecto se fijaron 3 problemas a implementar, que son los comentados anteriormente, luz encendida / apagada, fuego / no fuego y día / noche. Pero para llegar a abordar este objetivo principal se han tenido que dar muchos otros pasos en cuanto a formación y simulación de los problemas en otras plataformas. El primer paso a dar para empezar a hacer el proyecto es el de la formación. El fabricante de los dispositivos (Crossbow) aporta una serie de manuales donde se explican los aspectos clave para trabajar con esta plataforma, así que para empezar tuve que leer parte de estos manuales y experimentar con los motes para ver como funcionaban. Solo de esta manera tendría claros los conceptos clave de la plataforma. El segundo de los pasos de formación sería aprender el lenguaje NesC, ya que el código de todos los módulos está escrito en este lenguaje, esto no fue tarea fácil ya que el fabricante aporta muy poca información y poco útil a cerca de NesC. Finalmente elegí el lenguaje C para la implementación de las funciones, ya que el compilador también lo entiende. Después hubo un tiempo de reflexión para analizar la manera de diseñar los algoritmos que sería mejor para la óptima obtención de los resultados, una vez se tuvieron más ideas, se pasó a la implementación. Se han pasado por muchas y distintas fases para llegar a la implementación final de las funciones que procesan los datos obtenidos de los sensores. Se puede decir que esta ha sido la parte más larga y costosa del proyecto, ya que trabajaba con un lenguaje desconocido. Proyecto final de carrera - IS31
29
30
PLANIFICACIÓN Para empezar a probar los datos, escribí un programa en C++ al que le pasé un vector de datos como si fueran los datos capturados del sensor. Sobre este programa se hizo la estructura principal de los algoritmos para cada situación, y cuando empezaban a salir los resultados que se esperaban, se incluía el código de este algoritmo en el módulo XMDA100CB.nc para que procesara los datos de la manera que se había simulado anteriormente. Al pasar el código de C++ a NesC donde se quedaría finalmente, se tuvo que someter a algunos cambios, ya que el lenguaje NesC no acepta muchas de las características de la programación orientada a objetos. A partir de la implementación de las funciones que procesaban los datos capturados del entorno, he hecho unas modificaciones para que el envío de paquetes se haga solo en unas determinadas situaciones y no siempre, contribuyendo así al ahorro energético. Para finalizar, la última tarea ha sido la de juntar todos los problemas implementados para contribuir a la fácil configuración del programa según el modo en que queramos que se ejecuten los motes.
4.2. LISTA DE TAREAS
Para ir fijando las tareas a lo largo del proyecto, hemos usado la web de http://forja.uji.es desarrollada por la Universidad Jaume I, la cual permite ir poniendo tareas a lo largo de la realización del proyecto, y la herramienta de Microsoft Office llamada Project 2007. La aplicación ordena las tareas estableciendo una fecha de inicio de la tarea y una fecha de fin, también permite ir poniendo y actualizando el porcentaje completado de la tarea. Las tareas, por orden de fecha, que se han realizado durante todo el proyecto han sido las siguientes:
Determinar el ámbito del proyecto Establecer los requisitos Instalación de la plataforma de trabajo Configuración de la plataforma de trabajo Estudio del MoteView
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Estudio del MoteConfig Experimentación con los motes Estudio del Programmers Notebook 2 Estudio del lenguaje NesC Diseño de luz encendida / apagada Validación del diseño con el profesor Diseño de fuego / no fuego Validación del diseño con el profesor Diseño de día / noche Diseño de funciones de ahorro energético Validación del diseño con el profesor Implementación de luz encendida / apagada Reunión con el profesor Implementación fuego / no fuego Reunión con el profesor Implementación día / noche Reunión con el profesor Validación experimental y correcciones Reunión con el profesor Elaboración de la memoria Elaboración de la presentación
4.3. PLANIFICACIÓN INICIAL
En esta subsección se muestra el diagrama de Gantt correspondiente a la planificación inicial. En él, se desglosa el desarrollo del proyecto en diversas tareas, para las cuales se realizó una estimación previa de su duración. La estructura del diagrama se divide en 5 partes fundamentalmente: planificación, estudio de la plataforma, diseño de las aplicaciones, implementación de las aplicaciones y elaboración de la memoria y presentación. El inicio del proyecto según la planificación estimada es el 17 de Noviembre de 2008 y el final es el 17 de Septiembre de 2009. Las zonas del diagrama resaltadas en gris, corresponden a periodos en los que no se ha realizado proyecto (festivos o
Proyecto final de carrera - IS31
31
32
PLANIFICACIÓN periodos de examen). En total, los días empleados en la realización del proyecto ascienden a un total de 173 días.
Ilustración 11: Planificación inicial del 17 de noviembre al 27 de diciembre
Ilustración 12: Planificación inicial del 28 de diciembre al 7 de febrero
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Ilustración 13: Planificación inicial del 8 de febrero al 21 de marzo
Ilustración 14: Planificación inicial del 22 de marzo al 2 de mayo
Proyecto final de carrera - IS31
33
34
PLANIFICACIÓN
Ilustración 15: Planificación inicial de 3 de mayo al 13 de junio
Ilustración 16: Planificación inicial del 14 de junio al 25 de julio
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Ilustración 17: Planificación inicial del 7 de agosto al 17 de septiembre
Proyecto final de carrera - IS31
35
36
PLANIFICACIÓN
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
5. DISEÑO DE LA APLICACIÓN
En este capítulo se hablará de la forma en la que se han implementado los algoritmos en cada una de las tres situaciones descritas en el apartado anterior. Vamos a entrar en detalles acerca de la implementación en pseudocódigo.
5.1. DETECCIÓN DE LUZ ENCENDIDA / APAGADA
5.1.1. ENFOQUE
El diseño de la aplicación de detección de luz encendida y apagada, se ha hecho en un algoritmo que se incluye en el módulo de XMesh para el sensor mda100cb. La metodología que se ha seguido para crear la aplicación que detectará cuando un foco de luz exterior está encendido y cuando está apagado se ha basado en establecer dos conjuntos: en el conjunto 1 se guardarán los parámetros relativos al estado de luz encendida, y en el conjunto 2 se guardarán los parámetros relativos al estado de luz apagada. La aplicación de detección de luz encendida / apagada, se ejecuta dentro de los motes que conforman la red de sensores inalámbricos. Para que el usuario sepa si la luz está encendida o apagada se usará una variable resultado que se incluirá en el paquete que envían los motes a la estación base. Para identificar estos dos estados se pondrá la variable resultado a 1 si la luz está encendida, y si la luz está apagada se pondrá esta variable a 2. Si la variable resultado está a 0 significará que la aplicación no dispone de muestras suficientes como para determinar si la luz está encendida o apagada.
Proyecto final de carrera - IS31
37
38
DISEÑO DE LA APLICACIÓN
5.1.2. CLUSTERING PARA AGRUPACIÓN DE DATOS
El proceso de Clustering consiste en la división de los datos en grupos de objetos similares. El representar los datos por una serie de clusters, conlleva la pérdida de detalles, pero consigue la simplificación de los mismos. El Clustering es una técnica en la que el aprendizaje realizado es no supervisado (unsupervised learning). Desde un punto de vista práctico, el clustering juega un papel muy importante en aplicaciones de data mining, tales como exploración de datos científicos, recuperación de la información y minería de texto, aplicaciones sobre bases de datos espaciales (tales como GIS o datos procedentes de astronomía), aplicaciones Web , marketing, diagnóstico médico, análisis de ADN en biología computacional, y muchas otras.
5.1.3. DISEÑO BASADO EN EL CLUSTERING
En el diseño de esta situación, se ha pensado en el diseño basado en el clustering para resolver el problema de la clasificación dinámica entre dos conjuntos de datos. Como hándicap a esta solución, no se ha encontrado ningún método de clustering que vaya clasificando los datos en orden de llegada, que es lo requerido para solucionar nuestro problema, sino que todos los métodos empiezan a clasificar los datos cuando están en un único grupo. De todas formas, la idea del clustering ha servido para plantear la idea de establecer varios conjuntos en los que se pueden ir metiendo datos en relación a la comparación entre la media del conjunto con el valor de la muestra que se pretende clasificar. El método de clustering jerárquico tipo bottom up, sirvió para dar una idea de la metodología quemas tarde se seguiría para la resolución de la aplicación de luz encendida / apagada, la cual ha sido descrita en detalle en el apartado 5.1. Éste método consiste en comenzar con clusters de una sola instancia y en cada paso se juntan los dos clusters más cercanos. El diseño de decisión se basa en construir una matriz de distancia entre objetos, luego se construye el árbol jerárquico de clusters de acuerdo a la medida de distancia entre clusters, para finalizar se calculan los clusters reales en base al máximo número de clusters predefinidos.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
5.1.4. ALGORITMO DE DETECCIÓN Se han seguido unas fases para la elaboración del diseño de la aplicación que detecta cuando la luz está encendida y cuando está apagada, estas fases son tres:
FASE 1: Intento de clasificación de la muestra: El objetivo de esta fase es el de clasificar la muestra que ha leído el sensor en una de las dos situaciones, luz encendida o luz apagada. Para cada uno de los conjuntos de datos, el de luz encendida y el de luz apagada, se hará uso de tres variables de conjunto. Estas variables son la suma de los valores leídos por el sensor, el número de muestras tomadas, y la media del conjunto. También habrá un porcentaje de la media de los valores de los conjuntos, que será el 5% de la media del conjunto, y una diferencia, que será el valor leído por el sensor menos la media del conjunto que se quiera analizar. En el algoritmo 1 se muestra el pseudocódigo de la fase 1:
if (C1muestras == 0){ incluir la muestra en el conjunto 1; resultado = 1; } else{ C1media = C1suma / C1muestras; porcentaje = 5% de C1media; diferencia = |C1media – muestra|; if(diferencia = 1){ if(resultado == 1){ if(C1media > C2media){ resultado =1; } else{ resultado = 2; } } else if(resultado == 2){ Proyecto final de carrera - IS31
41
42
DISEÑO DE LA APLICACIÓN if(C1media > C2media){ resultado =2; } else{ resultado = 1; } } } else{ resultado = 0; } } if(C1media < C2media){ Intercambiar las variables de Conjunto 1 y 2 } Algoritmo 3: Detección luz encendida / apagada fase 3
5.2. DETECCIÓN DE FUEGO / NO FUEGO
5.2.1. ENFOQUE
La metodología que se ha seguido para crear la aplicación que detectará cuando un fuego puede estar encendido y cuando se puede estar extinguiendo, ha sido usar un vector de 4 elementos para establecer un umbral entre el primero y el último de los elementos, por encima del cual diremos que hay un fuego encendido. La aplicación de detección de fuego / no fuego, se ejecuta dentro de los motes que conforman la red de sensores inalámbricos. Para que el usuario sepa si se está activando un posible fuego o se está extinguiendo se usará una variable resultado que se incluirá dentro del paquete que envían los motes a la estación base. Para identificar estos dos estados se pondrá la variable resultado a 1 si el fuego se está activando y a 2 si se está extinguiendo. Si resultado está a 0 significará que se produce una situación sin percances, es decir, ni hay un fuego activo ni se está extinguiendo.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
5.2.2. ALGORITMO DE DETECCIÓN
Se han seguido unas fases para la elaboración del diseño de la aplicación que detecta cuando hay un posible fuego activo y cuando no lo hay, estas fases son tres:
FASE 1: Llenar el vector v de elementos: Esta fase solo se ejecuta las n primeras veces que se entra en la función de detección de fuego, porque el vector v necesita estar lleno para poder comparar el primer elemento con el último en la fase 2.
if(i < n){ Almacenar la muestra en el vector v; i = i + 1; } else{ FASE 2 } Algoritmo 4: Detección fuego / no fuego fase 1
FASE 2: Identificar la situación que se produce: Para identificar la situación que se produce se tomará como valor 1 el primer valor del vector v y como valor 2 el último valor de v. También se calculará la diferencia entre este valor 1 y el valor 2 en valor absoluto para almacenarla en una variable “diferencia”, y en la aplicación habrá una variable que se llame valarm, que es la que indicará si la variable diferencia representa una temperatura que está bajando o subiendo. El umbral representa el valor de la pendiente, por encima del cual saltará una alarma en señal de que se está activando un fuego (valarm = 2), o se está extinguiendo (valarm = 1).
Proyecto final de carrera - IS31
43
44
DISEÑO DE LA APLICACIÓN
Ilustración 18: Valor del umbral en fuego / no fuego
valor 1 = v[0]; valor 2 = v[n – 1]; valarm = 0; if(valor 1 > valor 2){ diferencia = valor 1 – valor 2; valarm = 1; } else{ diferencia = valor 2 – valor 1; valarm = 2; } if(diferencia / n > umbral){ adc6 = valarm; } FASE 3 Algoritmo 5: Detección luz encendida / apagada fase 2
Cabe comentar que el valor del umbral que se ha puesto en la aplicación implementada es orientativo y puede que el resultado no se corresponda con un fuego activo real. La tarea de ajustar el umbral al valor real que le
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
corresponda según la zona en la que se encuentren los motes quedaría en manos de expertos medioambientales.
FASE 3: Eliminar la muestra más antigua: En la fase 3 lo único que hay que hacer es eliminar la muestra más antigua mediante un for, la segunda muestra pasará a ser la primera, la tercera pasará a ser la segunda, y la cuarta pasará a ser la tercera. De esta forma se deja un hueco libre en la última posición del vector v para que entre una nueva muestra en la siguiente iteración y vuelva a empezar el proceso desde la fase 2.
Ilustración 19: Desplazamiento de muestras en fuego / no fuego
5.2.3. ALGORITMO DE ENVÍO
Junto a esta aplicación para procesar los datos capturados por el sensor, se ha desarrollado una función especial de envío de paquetes para contribuir al ahorro energético (algoritmo 6). Esta función se ejecutará siempre después de la función de procesamiento de los datos capturados por el sensor. Tiene la tarea de controlar el envío de paquetes, con el fin de contribuir al ahorro energético de la siguiente manera: solo se enviará el paquete de datos a la estación base si la variable resultado es distinta de 0, o si han pasado 50 capturas de datos del sensor sin que la variable resultado sea distinta de 0.
Proyecto final de carrera - IS31
45
46
DISEÑO DE LA APLICACIÓN if (resultado != 0 || contador == 50){ enviar paquete de datos; contador = 0; } else{ contador ++; } Algoritmo 6 : Envío de datos en detección de fuego / no fuego
5.3. DETECCIÓN DE DÍA / NOCHE
5.3.1. ENFOQUE
La metodología que se ha seguido para crear la aplicación que detectará cuando es de día y cuando es de noche, se ha basado en calcular la diferencia entre n valores de luz ambiental capturados por el sensor; esta diferencia junto con el último valor capturado ha servido para determinar si es de día, es de noche, se está haciendo de día o se está haciendo de noche. La aplicación de detección de día / noche, se ejecuta dentro de los motes que conforman la red de sensores inalámbricos. Para visualizar los resultados obtenidos por esta aplicación, se utilizará una variable resultado que se incluirá en el paquete de datos que se envía a la estación base de la siguiente forma: la variable resultado se pone a 1 si se está haciendo de día, a 2 si es de día, a 3 si se está haciendo de noche y a 4 si es de noche.
5.3.2. ALGORITMO DE DETECCIÓN
Para simplificar el proceso de aprendizaje de esta función, se han establecido tres fases: FASE 1: Obtención de datos:
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Esta fase consiste en tomar n muestras para hacer cálculos con ellas en la siguiente fase. Cada vez que se entre en la fase 1 se tomarán n muestras para analizar la situación que se está produciendo de las cuatro comentadas anteriormente. La primera de estas cuatro muestras será guardada en la variable valor 1, y la última será guardada en la variable valor2. La última muestra de un grupo de n muestras (valor 2), pasará a ser la primera del siguiente grupo de n muestras (valor 1). En la implementación de esta aplicación n vale 4. El algoritmo 7 muestra el pseudocódigo de la fase 1:
if(i == 0){ valor 1 = muestra; } else if(i == n-1){ valor 2 = muestra; } i = i+1 if(i == n) FASE 2 Algoritmo 7 : Detección de día noche fase 1
FASE 2: Cálculo de la pendiente: La pendiente es la diferencia entre el valor 1 y el valor 2. Habrá una variable llamada signo_de_pendiente para saber si la pendiente es positiva o negativa. Hay una variable (pendiente_plana) que nos dice si una pendiente es plana o no en función de si supera un umbral o no. En el algoritmo 8 se muestra el pseudocódigo de la fase 2.
if(i == n){ diferencia = |valor 1 – valor 2| if(valor 1 > valor 2){ signo_de_pendiente = 2; } if{ signo_de_pendiente = 1; }
Proyecto final de carrera - IS31
47
48
DISEÑO DE LA APLICACIÓN if(diferencia >= umbral_pendiente_plana){ pendiente_plana = 0; } else{ pendiente_plana = 1; } FASE 3 } Algoritmo 8 : Detección de día noche fase 2
FASE 3: Decisión del estado: La decisión del estado, se basará en la variable pendiente_plana y en los valores de los umbrales de día y de noche. En el algoritmo 9 se muestra el pseudocódigo de la fase 3. Cuando ya se ha decidido el estado, se pone la muestra actual en valor 1 para que la última muestra de un conjunto de n sea la primera del siguiente conjunto de n muestras. Para finalizar, se guarda el valor de resultado, en una variable que se llama “valor_aux”. Esto se hace para que se continúe mostrando el valor del resultado obtenido mientras se estén recogiendo nuevas muestras para analizar el estado siguiente.
if(pendiente_plana == 1){ if(valor 2 > umbral_día){ resultado = 2; } else if(valor 2 < umbral_noche){ resultado = 4; } else{ resultado = 5 } } else{ if(valor 2 > umbral_día){ resultado = 2;
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
} else if(valor 2 < umbral_noche){ resultado = 4; } else if(signo_de_pendiente == 1){ resultado = 1; } else{ resultado =3; } } valor 1 = muestra; i = 1; if(resultado >= 1){ valor_aux = resultado; } else{ resultado = valor_aux; } Algoritmo 9 : Detección de día noche fase 3
En nuestra aplicación, hemos considerado que el umbral de día vale 800, el umbral de noche vale 200 y el umbral de pendiente plana es igual a 2*n. Estos valores son orientativos, para una mayor precisión de los resultados, tendrían que ser expertos meteorológicos los que fijasen estos valores.
5.3.3. ALGORITMO DE ENVÍO
Esta aplicación está hecha para funcionar varios días seguidos, 24 horas al día, así que se tiene que pensar en ahorrar batería de los motes. Junto a la función de procesamiento de los datos capturados por el sensor, se ha implementado otra función de envío de paquetes. Esta función (algoritmo 10) tiene la tarea de controlar el envío de paquetes, de manera que solo se ejecute la función de procesamiento de los datos y se envíe el
Proyecto final de carrera - IS31
49
50
DISEÑO DE LA APLICACIÓN paquete de datos a la estación base, cada 32 lecturas de datos del sensor (32 lecturas = 1 minuto). Con esta función de envío, la función de procesamiento de los datos se ejecutará una vez cada minuto. De esta forma para obtener la diferencia entre valor 1 y valor 2 se necesitarán n-1 minutos y n muestras de luz (ilustración 19), esto permite a la aplicación tener un margen temporal más amplio para poder calcular la pendiente y obtener así resultados más realistas. Con esta solución también se ahorra batería en el mote, ya que los paquetes de datos solo se enviarán cada minuto a la estación base.
if (contador == 32){ ejecutar función de procesamiento de datos; enviar paquete de datos; contador = 0; } else{ Contador ++; } Algoritmo 10 : Envío de datos en detección de día / noche
Ilustración 20: Tiempo de recogida de muestras en día / noche
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
6. CONFIGURACIÓN Y PUESTA EN MARCHA DEL SISTEMA
En este capítulo se va explicar como se debe proceder para poder utilizar las aplicaciones desarrolladas para la red de sensores inalámbricos, así como. la estructura que tiene una aplicación.
6.1. PUESTA EN MARCHA DEL SISTEMA
El primer paso fundamental para poder trabajar sobre el sistema es tener instalado el software proporcionado por el fabricante de los nodos inalámbricos. Este se puede encontrar dentro del CD que Crossbow proporciona en el kit de trabajo. El segundo paso es disponer de los nodos inalámbricos con los programas desarrollados instalados en ellos. Para la instalación de los programas se emplea la herramienta “Programmers Notepad 2” provista por el fabricante de las placas. Se debe abrir el fichero de configuración del modulo a instalar mediante la introducción del siguiente comando en la shell: Make micaz install,X mib520,comY X hace referencia al número del nodo e Y hace referencia al número del puerto COMM de programación. Crossbow proporciona los controladores para el puerto USB, cuando se instalan generan dos COMM nuevos, el de numeración inferior sirve para la programación de los nodos, el otro es empleado para la comunicación de los paquetes procedentes de la red. Finalmente, hay que cargar en el mote la imagen que generará esta instrucción haciendo uso del MoteConfig y hacer clic en el botón Program. Para esto hay que seleccionar la imagen que se quiere cargar, así como los distintos parámetros de direcciones y radio (nodeID, groupID, RFpower y RFchannel). La ilustración 20 muestra la interface del MoteConfig, y la 21 muestra la interface del programmers notepad 2.
Proyecto final de carrera - IS31
51
52
CONFIGURACIÓN Y PUESTA EN MARCHA DEL SISTEMA
Ilustración 21: Interface de MoteConfig
Ilustración 22: Interface de Programmers Notepad
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
6.2. ESTRUCTURA DEL PROYECTO DE UNA APLICACIÓN
Dentro de la plataforma de trabajo empleada llamada MoteWorks, se requieren un mínimo de 4 archivos para poder generar una aplicación para la red de sensores inalámbricos. Según la funcionalidad que implemente la aplicación variara en el numero de módulos que la van a componer. El esqueleto de una aplicación en TinyOs consiste de los siguientes ficheros: Makefile Makefile.component Configuración de la aplicación Módulo con la implementación Radme (opcional)
6.2.1. MAKEFILE
Un Makefile consiste en líneas de texto que definen a un archivo o a un conjunto de ellos, o que definen el nombre de una regla dependiendo de un conjunto de archivos. Los archivos de salida necesitan de sus dependencias, y las dependencias también pueden tener sus propias dependencias internas. A continuación se muestra un ejemplo de Makefile utilizado para generar una aplicación correspondiente al proyecto:
include Makefile.component include $(TOSROOT)/apps/MakeXbowlocal include $(MAKERULES)
El entorno de desarrollo tiene declaradas unas variables de entorno que son empleadas para agilizar la generación de reglas (makerules), así como para referenciar rutas relativas (tosroot). El fichero MakeXbowlocal, proporciona una vía rápida para los cambios que pueda realizar el usuario, sobre la potencia de transmisión, canal de emisión o identificador del grupo de sensores.
Proyecto final de carrera - IS31
53
54
CONFIGURACIÓN Y PUESTA EN MARCHA DEL SISTEMA
6.2.2. MAKEFILE.COMPONENT
Este fichero describe a alto nivel la configuración del componente. Un componente se caracteriza por poseer un nombre que lo identifica y trabajar sobre una placa de sensor en concreto, la cual viene especificada por la marca del modelo. La directiva que identifica el sensor sirve para dar información al compilador sobre las sentencias de compilación que debe utilizar a la hora de generar el código. Un ejemplo de programación de este archivo para el sensor MDA100 empleado en el desarrollo del proyecto seria:
COMPONENT=MiAplicación SENSORBOARD=mda100
6.2.3. CONFIGURACIÓN DE LA APLICACIÓN
El nombre establecido en el Makefile.component debe de corresponderse con el nombre del fichero de configuración, acabado con la extensión “.nc”. Este modulo emplea la interfaz llamada StdControl, la cual proporciona las funcionalidades básicas para la inicialización, puesta en marcha y parada, de una aplicación basada en el sistema operativo TinyOs. Las siguientes líneas son una muestra de la programación para este modulo:
configuration MiAplicacion{ } implementation{ components Main, MiAplicacionM, TimerC, LedsC; Main.StdControl -> TimerC.StdControl; Main.StdControl -> MiAplicacion.StdControl; MiAplicacionM.Timer -> TimerC.Timer[unique(Timer)]; MiAplicacionM.Leds -> LedsC.Leds; }
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Conceptualmente las aplicaciones de TinyOs son una colección de componentes y un planificador llamado “Main”. Este planificador ejecuta las tareas creadas por los componentes que se incluyen en la configuración y es el primero en ejecutarse dentro del sistema operativo. La interfaz “StdControl” utilizada por el planificador permite inicializar y arrancar los componentes preparados para TinyOs. En el componente llamado “MiAplicacionM”, es donde va a residir la implementación de la aplicación. Los componentes “TimerC” y “LedsC” son módulos definidos por el sistema para aprovechar el hardware de los nodos, de los cuales ya se dispone su implementación, actuando como interfaces proveedoras de servicios para otros componentes nuevos. La configuración recoge todos aquellos servicios que son utilizados por un componente, los cuales pueden ser provistos por una o más interfaces. En la implementación se deberá especificar un nombre para la instancia de la interfaz, que debe coincidir con la empleada en este fichero. Un ejemplo serían los nombres “Timer” o “Leds”. La razón por la que existe de modo separado la configuración e implementación, es para proporcionar al desarrollador un conjunto de librerías de componentes que puedan ser reutilizadas en una amplia gama de aplicaciones.
6.2.4. MÓDULO DE IMPLEMENTACIÓN
Este modulo, siguiendo con la nomenclatura del ejemplo, debe ser llamado “MiAplicacionM”, como aparece referenciado en el fichero de configuración. En él es donde se implementa la programación de las funciones proporcionadas por la interfaz Timer, Leds y StdControl. A continuación se expone un ejemplo de implementación:
module MiAplicaciónM{ provides{ interface StdControl; } uses{ interface Timer;
Proyecto final de carrera - IS31
55
56
CONFIGURACIÓN Y PUESTA EN MARCHA DEL SISTEMA interface Leds; } implementation{ //Inicializa el componente. //devuelve SUCCESS siempre command result_t StdControl.init(){ call Leds.init(); return SUCCESS; } //Arranca la aplicación //devuelve SUCCESS siempre command result_t StdControl.start(){ return call Timer.start(TIMER_REPEAT, 1000); } //Pausa la ejecución de la aplicación //devuelve SUCCESS siempre command result_t StdControl.stop(){ return call Timer.stop(); } //Se ejecuta cada vez que termina la cuenta //del temporizador devuelve SUCCESS siempre event result_t Timer.fired(){ call Leds.redToggle(); return SUCCESS; } } }
La interfaz “StdControl” provee tres funciones básicas para el sistema operativo: init(), start(), stop(). La mayor parte de los componentes disponen también de alguna de estas llamadas para su inicialización o parada. El Timer es un ejemplo de ello, el cual hace un start y un stop a la par con el planificador. Por otra parte, una interfaz puede estar formada por algunas funciones las cuales se corresponden a eventos del sistema. La función “timer.fired” es una muestra, se produce cuando el tiempo de reloj fijado expira. Esto es un ejemplo de la
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
bidireccionalidad de la interfaz (proporciona comandos para ser llamados por el usuario y se lanzan eventos que son implementados por el). LedsC además de proporcionar las funciones ya comentadas, posee una funcionalidad mas, empleada en el “debug” de las aplicaciones a modo de punto de referencia para el programador, dando idea de por donde pasa el hilo de ejecución de la aplicación. Esta funcionalidad consiste en iluminar o apagar el led del color especificado en la placa del nodo.
Proyecto final de carrera - IS31
57
58
CONFIGURACIÓN Y PUESTA EN MARCHA DEL SISTEMA
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
7. IMPLEMENTACIÓN
En este capítulo se van a clasificar y explicar las funciones según su tipo. También se va a explicar como elegir cada una de las aplicaciones descritas, y finalmente se van a plantear cuales han sido los problemas que han surgido en la implementación de estas aplicaciones.
7.1. SOFTWARE DE LA PLATAFORMA (MOTEWORKS)
7.1.1. XMESH
La funcionalidad en el nivel del Mote (Nodo) se encuentra recopilada en la librería llamada XMesh. Esta librería desarrolla un protocolo para redes de sensores inalámbricos, donde los nodos pueden comunicarse con el resto y son capaces de enviar mensajes de radio saltando entre los nodos hacia la estación base, la cual actúa de puente entre la red y el ordenador. Esta capacidad de salto amplia el rango de radio de las comunicaciones y reduce la potencia de transmisión de los mensajes, lo cual alarga el tiempo de vida de las baterías que incorporan los nodos [2]. XMesh proporciona dos beneficios importantes, mejora la cobertura de la radio y mejora también la fiabilidad de las transmisiones. Dos nodos no necesitan estar en contacto directo para poder comunicarse entre ellos. Un mensaje puede ser entregado a uno o más nodos en el camino que sigue hasta que llega a su destino. Si existe un nodo caído entre dos nodos, ese obstáculo puede ser salvado encontrando un nodo cercano con el que pueda continuar su camino. Típicamente, los nodos que trabajan en modo de bajo consumo, pasan la mayor parte de su tiempo en un estado de reposo, de modo que puedan mantener su autonomía durante años. Todas las redes mesh requieren una estación base que actúa como puerta de enlace para el PC. La estación base consiste, en el caso de este proyecto, en un nodo Proyecto final de carrera - IS31
59
60
IMPLEMENTACIÓN MicaZ ejecutando el XMeshBase y montado en una placa mib520 de Crossbow, la cual va unida al PC por USB. En el caso del cliente el mote ejecutará el XMesh para MicaZ.
7.1.2. XSERVE
El nivel del servidor por su parte, actúa de puerta de enlace entre la red inalámbrica y las aplicaciones en el ordenador que requieran interactuar con la información que es recibida de ella. Debido a la baja potencia y a los requisitos de memoria que presentan las redes inalámbricas de sensores, la comunicación resulta ser más eficaz a través de mensajes sin formato y los protocolos de la red. Este software servidor es llamado XServe, y proporciona servicios de análisis, transformación y procesamiento de la información recibida desde la red, incluyendo una API XML para la comunicación con otras aplicaciones clientes [2]. Otra funcionalidad que incorpora XServe es el almacenamiento de información en una base de datos, de modo que la información enviada por los sensores pueda ser monitorizada para realizar análisis con las lecturas obtenidas. Esto es muy utilizado para fines agrónomos puesto que los sensores registran los valores medioambientales. La plataforma de trabajo MoteWorks está adaptada para funcionar sobre el sistema operativo Windows, emplea la herramienta denominada Cygwin para proporcionar un comportamiento similar a los sistemas Unix en cuanto a gestión de redes. Posee una biblioteca que implementa la API POSIX usando para ello llamadas a la API nativa de Windows Win32.
7.2. TIPOS DE FUNCIONES
Los diferentes tipos de funciones que hacen falta para que las aplicaciones creadas se ejecuten con normalidad son básicamente tres.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
7.2.1. FUNCIONES PARA CAPTURAR DATOS
Este tipo de funciones son las encargadas de leer una muestra para enviar el paquete de datos a la estación base, cuando esto sucede se obtiene otra muestra del sensor y vuelta a empezar. En el caso de este proyecto las muestras leídas por una placa de sensor, no se enviarán a la estación base hasta que no hayan pasado por otro tipo de funciones que se explican en el subapartado 7.1.2, estas son funciones para procesar datos. Las funciones para capturar datos son las que su nombre termina en “.dataReady”. En el caso del módulo para la placa de sensor xmda100cb, que es la que se usa en el proyecto, primero se inserta en el paquete de datos las muestras de temperatura y luego las de luz ambiental, finalmente se pasa a insertar en el paquete de datos los valores de las variables adc2, adc3, adc4, adc5 y adc6. Es en la función “result_t ADC6.dataReady(uint16_t data)”, donde se invocará a las funciones encargadas de procesar datos y a las encargadas de enviar estos datos. Según sea la aplicación que queremos ejecutar, se llamarán a un grupo de funciones o a otro, esto se explica en el apartado 7.2. En el apéndice A se muestra el código de estas funciones.
7.2.2. FUNCIONES PARA PROCESAR DATOS
Las funciones encargadas de procesar los datos recogidos por la placa de sensor son en las que se ha centrado el proyecto. A estas funciones se les ha denominado “process_sensor_data”. La función “process_sensor_data1” se encarga de procesar los datos para saber si hay una luz encendida o una luz apagada. La función “process_sensor_data2” se encarga de procesar los datos para saber si hay un posible fuego activo o no lo hay. Y la función “process_sensor_data3” se encarga de procesar los datos para saber si es de día o es de noche. El resultado en cada función de procesamiento de datos se ha puesto en el campo adc6 del paquete de datos que envía el mota a la estación base.
Proyecto final de carrera - IS31
61
62
IMPLEMENTACIÓN
7.2.3. FUNCIONES PARA ENVIAR DATOS
La función que se utilizará para enviar el paquete de datos a la estación base será la que viene por defecto en el módulo xmda100cb, se llama “send_radio_msg”. Como se ha dicho en la sección 2.5, en este proyecto se ha querido contribuir al ahorro energético. Es por eso que se han creado funciones especiales para enviar paquetes de datos solo cuando se den ciertas circunstancias. Estas funciones son dos. La primera es “my_send_radio_msg2” y se ha creado para contribuir al ahorro energético en la aplicación del fuego / no fuego, “process_sensor_data2”. La segunda es “my_send_radio_msg3” y se ha creado para contribuir al ahorro energético en la aplicación de día / noche.
7.3. ELECCIÓN DE LAS APLICACIONES
La implementación de los algoritmos vistos en el capítulo de diseño se lleva a cabo en la función ADC6.dataReady del módulo xmda100cb. Para cada uno de los problemas descritos en el capítulo de diseño, se ha creado una función process_sensor_data y send_radio_msg (excepto en el problema de detección de luz encendida o apagada). Para resolver un problema u otro, se harán llamadas a las funciones correspondientes en cada caso dentro de la función ADC6.dataReady del módulo xmda100cb.
7.3.1. PROBLEMA 1: DETECCIÓN DE LUZ ENCENDIDA / APAGADA
Para elegir que se ejecute la aplicación que detecta cuando una luz artificial está encendida y cuando está apagada solo hay que llamar a process_sensor_data1 en la función ADC6.dataReady (ilustración 22), y después de procesar los datos leídos del.sensor, se llamará a send_radio_msg para que se envíe el paquete de datos a la
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
estación base. Este paquete de datos viene como parámetro en la cabecera de la propia función ADC6.dataReady, y lleva, entre otros, el campo adc6 donde se almacena en la función process_sensor_data1 el resultado que queremos monitorizar.
Ilustración 23: Código de elección para luz encendida / apagada
7.3.2. PROBLEMA FUEGO
2:
DETECCIÓN
DE
FUEGO
/
NO
La aplicación que detecta cuando hay fuego o cuando no lo hay, se elige poniendo una llamada a process_sensor_data2 y otra llamada a my_send_radio_msg2 en la función ADC6.dataReady (Ilustración 15). En esta función my_send_radio_msg2 (ilustración 16) es donde se incluye la llamada a send_radio_msg, ya que de esta forma se puede hacer un mejor control de los paquetes enviados con la finalidad de
Proyecto final de carrera - IS31
63
64
IMPLEMENTACIÓN contribuir al ahorro energético. En my_send_radio_msg2, solo se ejecutará la función send_radio_msg cuando el campo adc6 sea distinto de 0 o cuando hayan pasado 50 capturas de datos leídos por el sensor sin que esto ocurra.
Ilustración 24: Código de elección para fuego / no fuego
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Ilustración 25: Código de my_send_radio_msg2
7.3.3. PROBLEMA 3: DETECCIÓN DE DÍA / NOCHE
La aplicación que detecta cuando es de día o cuando es de noche, se elige poniendo una llamada a la función my_send_radio_msg3. Es en esta función donde se ejecutarán las llamadas a process_sensor_data3 y a send_radio_msg (Ilustración 18). La forma óptima de hacer estas llamadas para ahorrar batería en los motes que forman la red de sensores inalámbricos sin que se vean perjudicados la precisión de los resultados de la aplicación, es que cada 32 muestras (32 muestras = 1 minuto), se ejecute process_sensor_data3 y luego send_radio_msg. De esta forma cada minuto se tendrán los resultados esperados y se ahorrará batería en los motes. En la ilustración 17 podemos ver como y donde se ejecuta la llamada a my_send_radio_msg3 dentro de ADC6.dataReady.
Proyecto final de carrera - IS31
65
66
IMPLEMENTACIÓN
Ilustración 26: Código de elección entre día / noche
Ilustración 27: Código de my_send_radio_msg3
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
7.4. PROBLEMAS EN LA IMPLEMENTACIÓN
A continuación se describirán los problemas de implementación que ha habido en las tres aplicaciones. En general hay que decir que el problema más importante ha venido a raíz de tener que trabajar con NesC. Ya que éste no es un lenguaje orientado a objetos, y las nociones principales del programador de este proyecto son referentes a este tipo de programación. En cada una de las aplicaciones desarrolladas, para monitorizar el valor de ciertas variables a modo de traza, se han usado los campos adc2 a adc5 del paquete de datos que se envía a la estación base. Esto ha supuesto una gran ventaja para saber que problemas se han ido teniendo a lo largo del desarrollo de las aplicaciones.
7.4.1. PROBLEMAS EN LUZ ENCENDIDA / APAGADA
Hay que decir que el desarrollo y la implementación de esta aplicación ha sido la tarea más costosa del proyecto, tanto por la complejidad de la aplicación como por ser la primera de las tres aplicaciones que se implementó. Lo cual ha llevado a tener ciertas dificultades como las siguientes.
En NesC solo se pueden usar enteros sin signo: Esta característica del lenguaje NesC hace que en cada asignación a un valor de tipo entero, se tenga que comprobar si el resultado es positivo o negativo, ya que si es negativo no se podrá guardar.
Simulación de la aplicación en C++: Como se ha dicho anteriormente, el lenguaje NesC no es orientado a objetos. Así que hasta que no se tuvo clara la estructura de la aplicación y como tratar los eventos, se tuvo que simular el tratamiento de los datos con un programa creado en C++. Para simular los datos recogidos por el sensor, se pusieron una colección de datos en un fichero al cual iba accediendo el programa.
Proyecto final de carrera - IS31
67
68
IMPLEMENTACIÓN Enteros de 32 bits: Cuando se repasó la aplicación para probarla de nuevo, el desarrollador se fijó en que si se dejaba la luz encendida varios minutos la aplicación empezaba a fallar. Esto era debido a que las variables C1suma y C2suma se almacenaban en un tipo de datos (uint16_t) que era demasiado pequeño para ir almacenando la suma de las muestras capturadas por el sensor. La solución fue sustituir este tipo de datos por otro para almacenar enteros mas grandes (uint32_t).
Fase 2: La redefinición de grupos no se pensó hasta muy tarde, fue entonces cuando los resultados empezaron a salir como se esperaban. Por esta razón se perdió mucho tiempo en la implementación de esta aplicación.
Fase 3: En esta fase hubo que darse cuenta de que había que intercambiar los valores de las variables de los dos conjuntos si la media del conjunto 1 era menor que la del conjunto dos. Por este motivo, la aplicación no termino de funcionar correctamente.
7.4.2. PROBLEMAS EN FUEGO / NO FUEGO
En NesC no se pueden usar floats: Esto llevó a usar métodos alternativos como multiplicar las variables por 10 y asumir un resultadomás grande. Este es el caso del cálculo del umbral en la fase 2.
7.4.3. PROBLEMAS EN DÍA / NOCHE
Fase 1: En esta fase fue difícil encontrar la mejor forma de obtener los datos para que el último de los n datos de un conjunto fuera el primero de los n datos del siguiente. Al final se optó por poner que el valor 1 del siguiente conjunto de datos fuera igual al valor 2 del conjunto que había acabado de ser clasificado.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Pendiente en lugar de ángulo: Uno de los retos de esta aplicación llegó a ser que en lugar de calcular la pendiente, se calculará un ángulo por encima del cual se diría que la pendiente no es plana. Al final se desistió, ya que no se sabía la instrucción para calcular la arco tangente de la pendiente, y el mismo problema se podía resolver de manera más sencilla.
Fase 3: En esta fase, cuando la pendiente no era plana se supuso que se estaba haciendo de día o de noche. Lo que no se tuvo en cuenta es que cuando ya era de día o de noche podía haber un foco de luz artificial que hiciera que la pendiente no fuera plana, por lo que la aplicación creería que se estaba haciendo de día o de noche. Esta situación se solucionó poniendo que para una pendiente no plana, es de día cuando el valor de la muestra esté por encima del umbral de día, y que es de noche cuando el valor de la muestra esté por debajo del umbral de noche.
my_send_radio_msg_3: En la función de ahorro energético asociada a esta aplicación (my_send_radio_msg3), se pretendió enviar el paquete de datos solo cuando adc6 fuera distinto de 0, pero no se pudo.
Proyecto final de carrera - IS31
69
70
IMPLEMENTACIÓN
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
8. VALIDACIÓN EXPERIMENTAL
En este capítulo se van a mostrar resultados de experimentos que simulan situaciones reales de cada aplicación
8.1. DETECCIÓN DE LUZ ENCENDIDA / APAGADA
Para probar esta aplicación, se ha cargado en un mote una imagen compilada del código fuente del módulo mda100cb. Esta imagen, ejecuta la aplicación que detecta cuando una luz está encendida y cuando está apagada. Las imágenes que siguen muestran en qué situación está el mote cuando se ejecuta esta aplicación (ilustración 27). También hay dos gráficos que muestran el valor de los datos capturados por el sensor (ilustración 28) y los resultados que saca la aplicación, luz encendida o apagada (ilustración 29).
Proyecto final de carrera - IS31
71
72
VALIDACIÓN EXPERIMENTAL
Ilustración 28: Motes ejecutando la aplicación de luz encendida / apagada
En la ilustración 27, se puede ver como adc6 vale 1 o 2 dependiendo de si el valor de luz es mayor o menor, en señal de que la luz está encendida o apagada. La imagen de debajo es el paquete de datos entero que envía el mote a la estación base. En este paquete de datos, los dos recuadros rojos de la izquierda son los datos de luz que captura el mote, y los dos recuadros rojos de la derecha son los valores de adc6, 1 para luz encendida y 2 para luz apagada. En esta ilustración la imagen de la izquierda representa un mote sobre el que incide un foco de luz artificial, y la imagen de la derecha representa un mote sobre el que no incide ningún foco de luz. En las dos ilustraciones siguientes se puede ver una gráfico con una captura de datos en la que se ha ido encendiendo y apagando un foco de luz (Ilustración 28), y otro con los resultados que obtiene la aplicación en el campo adc6 del paquete de datos que envía el mote a la estación base (Ilustración 29).
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Ilustración 29: Captura de datos en luz encendida / apagada
Ilustración 30: Resultados en luz encendida / apagada
Proyecto final de carrera - IS31
73
74
VALIDACIÓN EXPERIMENTAL
8.2. DETECCIÓN DE FUEGO / NO FUEGO
Para probar esta aplicación, se ha cargado en un mote una imagen compilada del código fuente del módulo mda100cb. Esta imagen, ejecuta la aplicación que detecta cuando hay un posible fuego activo y cuando no. Las imágenes que siguen muestran en qué situación está el mote cuando se ejecuta esta aplicación (ilustración 30). También hay dos gráficos que muestran la captura de datos del sensor (ilustración 31) y los resultados que la aplicación pone en el campo adc6 del paquete de datos (ilustración 32). Si adc6 vale 0 significa que la temperatura es constante, ni sube ni baja. Si adc6 vale 1 significa que baja la temperatura, y si adc6 vale 2 significa que sube la temperatura.
Ilustración 31: Motes ejecutando la aplicación de fuego / no fuego
En la ilustración 30 el recuadro rojo de la izquierda representa los valores de temperatura capturados por el sensor, y el recuadro rojo de la derecha representa el resultado que está en el campo adc6 del paquete de datos.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Ilustración32: Captura de datos en fuego / no fuego
Ilustración 33: Resultados en fuego / no fuego
Proyecto final de carrera - IS31
75
76
VALIDACIÓN EXPERIMENTAL En la ilustración 31 se ve un gráfico con una captura de datos ejecutando la aplicación de fuego / no fuego. La ilustración 32 es un gráfico que representa los resultados obtenidos en el campo adc6 al ejecutar esta aplicación. Esta aplicación solo marcará la subida ya la posterior bajada de temperatura. De esta forma, cuando la temperatura esté muy alta pero permanezca constante, la alarma del campo adc6 ya no se enviará, ya que la aplicación solo detecta subidas y bajadas bruscas de temperatura. El objetivo de la aplicación es avisar de cuando se puede estar empezando a producir un incendio y cuando se está extinguiendo. El sensor de temperatura de la tarjeta mda100cb, detecta las subidas de temperatura de forma muy rápida, pero las bajadas las detecta de forma más lenta, ya que cuesta más de que se enfríe el sensor que de que se caliente.
8.3. DETECCIÓN DE DÍA / NOCHE
Para probar esta aplicación, se ha cargado en un mote una imagen compilada del código fuente del módulo mda100cb. Esta imagen, ejecuta la aplicación que detecta cuando es de día y cuando es de noche. Luego se ha procedido a monitorizar los datos capturados ejecutando el MoteView. Las imágenes que siguen muestran en qué situación está el mote cuando se ejecuta esta aplicación. También hay dos gráficos que muestran la captura de datos del sensor y los resultados que la aplicación pone en el campo adc6 del paquete de datos. Si adc6 vale 1 significa que se está haciendo de día, si adc6 vale 2 significa que es de día, si adc6 vale 3 significa que se está haciendo de noche y si adc6 vale 4 significa que es de noche. En los dos siguientes gráficos, se muestra una captura de luz en la que se ve como se hace de noche y después de pasar la noche se hace da día (Ilustración 32). También se muestra otro gráfico en el que se ven los resultados obtenidos en el campo adc6 del paquete de datos para los valores capturados por el sensor en la ilustración anterior.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Ilustración 34: Captura de datos en día / noche
Ilustración 35: Resultados en día / noche
Proyecto final de carrera - IS31
77
78
VALIDACIÓN EXPERIMENTAL
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
9. REVISIÓN FINAL DEL PROYECTO
Se puede decir que la ejecución final de las tareas, ha sido un poco distinta que las que habíamos planificado en un principio debido a varios problemas. Las tareas que se pretendían llevar a cabo en un principio son la descritas en el apartado 4.2, pero finalmente se optó por aprovechar la mayoría de ellas y rechazar otras menos significativas para llevar a cabo los objetivos del proyecto.
9.1. PLANIFICACIÓN FINAL
En este capítulo se va a mostrar cual ha sido la planificación final del proyecto, esta planificación es la que resulta después de haber ejecutado todas las tareas que componían la planificación inicial. En las imágenes siguientes se muestra esta clasificación:
Ilustración 36: Planificación final del 17 de noviembre al 27 de diciembre
Proyecto final de carrera - IS31
79
80
REVISIÓN FINAL DEL PROYECTO
Ilustración 37: Planificación final del 28 de diciembre al 7 de febrero
Ilustración 38: Planificación final del 8 de febrero al 21 de marzo
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Ilustración 39: Planificación final del 22 de marzo al 2 de mayo
Ilustración 40: Planificación final del 3 de mayo al13 de junio
Proyecto final de carrera - IS31
81
82
REVISIÓN FINAL DEL PROYECTO
Ilustración 41: Planificación final del 14 de junio al 25 de Julio
Ilustración 42: Planificación final del 11 de agosto al 21 de septiembre
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
10. CONCLUSIONES
En este capítulo se pretenden recoger las conclusiones obtenidas tras el desarrollo del proyecto. Por un lado se propondrán varias situaciones en las que este proyecto podría jugar un buen papel, y por otro se darán ideas sobre como ampliar este proyecto.
10.1. APLICACIONES POTENCIALES
Las principales aplicaciones potenciales de este proyecto se pueden dar en el ámbito de la domótica, algunas aplicaciones prácticas podrían ser las siguientes. Control de persianas: aprovechando la aplicación que permite saber cuando es de día y cuando de noche, se podría controlar la subida y bajada de las persianas de una casa de manera automática.
Control de luces de una vivienda: Como en el control de las persianas, se puede controlar el encendido y apagado de las luces principales de una casa de manera automática, gracias a la aplicación del control de día y de noche creada en este proyecto.
Alarma de incendio: En una casa se puede poner una alarma de incendio gracias a la aplicación de detección de fuego creada en este proyecto.
Control de calefacción: La aplicación de detección de fuego, podría actuar como termostato, de esta manera por debajo de un valor de temperatura se encendería la calefacción de una vivienda, y por encima de otro valor se apagaría. Proyecto final de carrera - IS31
83
84
CONCLUSIONES
Monitorización cualitativa del entorno: Estas aplicaciones permiten una monitorización qualitativa del entorno al identificar estados semánticamente interpretables por un usuario.
10.2. AMPLIACIÓN EN FUTUROS PROYECTOS
Este proyecto deja muchas puertas abiertas en cuanto a realización de futuros proyectos. De momento se podrían explicar una serie de futuros proyectos a realizar, que contribuirían a la mejora de estas aplicaciones: Una de las mejoras que se podrían introducir sería crear un entorno gráfico, desde el que se pudiera elegir una de las tres aplicaciones desarrolladas en este proyecto, para crear la imagen a partir de la compilación. También sería interesante proponer un proyecto, en el que se creara un mapa cartográfico de la zona en la que están ubicados los motes, y se actualizara de forma automática en función de los motes que se van añadiendo y eliminando a la red.
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
BIBLIOGRAFÍA
[1] Ivan Stojmenovid. Handbook of sensor networks, algorithms and architecture. [2] Sandra Pallarés Gual. Sistema de localización para redes inalámbricas de sensores mediante zigbee. [3]
Ad Hoc Mobile Wireless Networks, Prentice Hall Publishers, 2002.
[4] Crossbow Technology, Inc. MoteView Users Manual. Revision A, May 2007. PN: 7430-0008-05. Capítulo 1.1. [5] Crossbow Technology, Inc. MoteConfig Users Manual. Revision A, November 2007. PN: 7430-0112-01. Capítulo 1. [6] Crossbow Technology, Inc. XMesh User’s Manual. Revision C. March 2007. PN: 7430-0108-01 .Capítulo 4.
Proyecto final de carrera - IS31
85
86
Bibliografía
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
APÉNDICE A.- CODIGO FUENTE
En este apéndice se pretende volcar el código fuente de las funciones implementadas en el módulo del sensor xmda100cb.
Las funciones que se han implementado en el módulo mda100cb son: process_sensor_data1, process_sensor_data2, process_sensor_data3, my_send_radio_msg2 y my_send_radio_msg3. A continuación se muestra el código fuente:
Proyecto final de carrera - IS31
87
88
APÉNDICE A.- CODIGO FUENTE
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Proyecto final de carrera - IS31
89
90
APÉNDICE A.- CODIGO FUENTE
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Proyecto final de carrera - IS31
91
92
APÉNDICE A.- CODIGO FUENTE
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Proyecto final de carrera - IS31
93
94
APÉNDICE A.- CODIGO FUENTE
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Proyecto final de carrera - IS31
95
96
APÉNDICE A.- CODIGO FUENTE
IS31 - Proyecto final de carrera
Procesamiento de datos en una red de sensores inalámbrica.
Proyecto final de carrera - IS31
97
98
APÉNDICE A.- CODIGO FUENTE
IS31 - Proyecto final de carrera