Documentaci on nal - Universidad de la República · 2018. 3. 13. · En el transcurso de la...

Universidad de la RepublicaFacultad de IngenieŕıaInstituto de Ingenieŕıa EléctricaSistemas embebidos

Documentación final

Integrantes : Mauricio GonzalezNicolás LamathNicolás Wainstein

Tutor : Leonardo BarboniGrupo : Grupo 1Fecha : 25/06/2013

Sistemas Embebidos para Tiempo Real - Documentación del proyecto -

Índice

1. Introducción 31.1. Descripción del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Objetivos 32.1. Objetivos generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2. Objetivos espećıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3. Alcance 4

4. Diseño 44.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54.2. Contiki OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.2.1. Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54.2.2. Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5. Implementación 65.1. Generación y almacenaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5.1.1. Generación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65.1.2. Interacción entre generación y almacenaje . . . . . . . . . . . . . . . . . 75.1.3. Almacenamiento en memoria FLASH . . . . . . . . . . . . . . . . . . . . 8

5.2. Detección . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85.3. Transmisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.3.1. Módulo ABC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.3.2. Módulo RUNICAST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6. Pruebas 126.1. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6.1.1. Resultados de generación . . . . . . . . . . . . . . . . . . . . . . . . . . . 126.2. Resultados de transmisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

7. Medidas 147.1. Medidas de escritura en la memoria FLASH . . . . . . . . . . . . . . . . . . . . 157.2. Medidas de generación y almacenaje . . . . . . . . . . . . . . . . . . . . . . . . 167.3. Medidas de transmisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

8. Conclusiones 17

9. Bibliograf́ıa 20

10.Anexo 2110.1. Conceptos del curso aplicados al proyecto . . . . . . . . . . . . . . . . . . . . . . 2110.2. Especificación del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2110.3. Planificación del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1


Resumen

Durante la realización del proyecto se exploró la capacidad del nodo TelosB pararealizar tareas de compresión y transmisión de grandes paquetes de información,documentando todas las dificultades que surgen en el proceso. El proyecto consisteen la generación de un patrón de imagen en uno de los nodos, procesamiento delmismo detectando los bordes y transmisión de la imagen a otro nodo. Se esperatomar medidas de tiempo de procesamiento y consumo de cada una de las etapas,aśı como documentar los tamaõs máximos de imagen.

2


1. Introducción

Tradicionalmente los sistemas embebidos son diseñados para realizar tareas muy determina-das que responden a necesidades espećıficas. Dichas tareas se desarrollan con la menor cantidadde recursos posibles, ajustando al máximo el hardware a las necesidades para minimizar loscostos. Sin embargo éste tipo de dispositivo se encuentra evolucionando hacia la implementaciónde redes con técnicas de data fusion, en donde la información que proviene de múltiplessensores distribuidos es combinada y utilizada para construir estructuras más complejas. Elprocesamiento y transmisión de imágenes se encuentra dentro de esta clase de funcionalidadesemergentes para las redes de sensores inalámbricos.

Éstas nuevas aplicaciones surgen debido a la aparición de nuevas generaciones de nodos,sensores, técnicas de procesamiento de información para sistemas con recursos hardwarelimitados y reducida disponibilidad de enerǵıa y mejoras en las formas de implementarcomunicaciones inalámbricas low-rate low-power.

1.1. Descripción del problema

Durante la realización del proyecto se exploraró la capacidad del nodo TelosB[1] para realizartareas de procesamiento y transmisión de grandes paquetes de información, documentando lasdificultades que surjan en el proceso, para lo que se desarrolló una aplicación en dos etapas.En el transcurso de la primera se buscó escribir un patrón de información (una imagen) queocupe gran parte de la memoria flash externa del TelosB, aplicarle un algoritmo de detección debordes y devolverlo al PC comparando el patrón inicial con en generado en la PC por Matlab.El nodo estaba conectado al PC durante esta etapa de prueba y no se realizó ninguna actividadcon la radio del mismo.

Luego, en una segunda etapa se envió el patrón procesado desde el TelosB a otro TelosBconectado a un PC mediante el transceiver RF para luego comparar las señales en el PC.El objetivo de esta etapa es observar el comportamiento de la radio (consumo de corriente ytiempos involucrados) cuando se ordena el transporte de grandes volúmenes de información enbytes.

1.2. Antecedentes

Este proyecto busca encontrar los problemas inherentes de la compresión y env́ıo degrandes paquetes desde un nodo en forma inalámbrica, enmarcándose en el proyecto de gradoPLAGAVISIÓN [2]. Además de enviar las imágenes el sistema debe encargarse de aplicar unalgoritmo de realce de bordes. Entre los antecedentes se encuentra una experiencia similardesarrollada en Italia para controlar plagas en viñedos [3]. Si bien la aplicación de dicho sistemaes muy similar a la nuestra se deberá investigar si el método de análisis de imágenes utilizadoes compatible con nuestras necesidades.

2. Objetivos

2.1. Objetivos generales

1. Aplicar y consolidar los conocimientos adquiridos en el curso de Sistemas Embebidos.

2. Contribuir con información relevante para el proyecto PLAGAVISIÓN.

3


3. Evaluar las capacidades del TelosB para aplicaciones de manejo de imágenes.

2.2. Objetivos espećıficos

1. Implementar la aplicación bajo Contiki OS[4]. Evaluar rendimiento y ventajas de Contikipara este tipo de aplicaciones.

2. Generar un patrón de memoria en el TelosB que cumpla el rol de una imágen en escalade grises.

3. Aplicar un algoritmo de detección de bordes sobre el contenido de la memoria Flash

4. Implementar el env́ıo inalámbrico del patrón de información entre nodos, utilizandocomunicación single hop. Se debe analizar como segmentar la información para que entreen el payload del paquete definido en el estándar IEEE 802.15.4 .

5. Redacción de la documentación correspondiente.

3. Alcance

Este proyecto no incluye ninguna parte del hardware necesario para el proyecto PLAGA-VISIÓN. No se consideró la comunicación del nodo con la cámara que posteriormente seencargará de tomar las imágenes, sino que se utilizó un patrón de señal generado por unalgoritmo.

No se investigaron distintos algoritmos de procesamiento de imágenes. Se elije uno enparticular para estudio (Detección de bordes mediante convolución con kernel)

No se tomararon en cuenta las necesidades de bajo consumo que tiene el proyecto degrado, pero si se tomaron mediciones de las aplicaciones implementadas.

No se consideró el armado de la red de sensores, se asumió comunicación unilateral entreambos nodos (single hop).

La evaluación de las capacidades, ventajas y desventajas de los distintos nodos noestá inclúıda en este proyecto. Se elije la plataforma TelosB.

El proyecto cubre la realización del software necesario en Contiki para la escritura enmemoria flash y manipulación del patrón y para la recepción y env́ıo de la misma a travésde la radio.

4. Diseño

Para atacar el problema lo dividimos en cinco tareas fundamentales que corresponden a lasfuncionalidades de nuestro sistema:

1. Generar un patrón de gran tamaño (una matriz que se interpreta como una imagen).

2. Almacenar el dato anterior en la memoria Flash externa.

3. Aplicar un algoritmo de detección de bordes mediante la convolución con un determinadokernel.

4. Almacenar el nuevo patrón en la memoria Flash externa.

5. Enviar este último por el transceiver RF hacia el nodo sink.

4


4.1. Hardware

Los nodos utilizados en el proyecto fueron TelosB compatibles. Éstos son módulos de bajoconsumo diseñados principalmente para WSN. Poseen un microcontrolador de la familia TexasInstruments MSP430.

Las principales caracteŕısticas son:

Transceiver RF Chipcon CC2420 250kbps 2.4GHz IEEE 802.15.4 .

Microcontrolador MSP430 de 16 bits con 8MHz de reloj, 10kB de RAM y 48kB de Flash.

Flash externa de 1MB.

Antena integrada con alcance de 50m en interior / 125m en exterior.

Programación v́ıa USB.

Bajo consumo de corriente.

Comunicación con periféricos v́ıa SPI, UART, I2C, GPIO.

4.2. Contiki OS

Todo éste desarrollo se realizó sobre el RTOS Contiki, por lo que la implementación delos módulos debió ser pensada para su modelo de programación. Contiki está basado enprotothreads, estos son una abstracción de programación que comparte elementos de multi-threading y event-driven, por lo que los procesos se ejecutan en respuesta a eventos a travésdel scheduler. Para esta aplicación decidimos utilizar cuatro procesos: el primero para generarel patrón, el segundo para acceder a la memoria Flash y almacenarlo, el tercero para realizar laconvolución y guardar su resultado en memoria y por último el cuarto proceso para transmitirpor radio. Ésta estructura de procesos responde a la forma en la que se desarrolló el proyecto.

4.2.1. Procesos

La estructura general del código quedó dividida entre las funciones auxiliares y los procesos.Los procesos deben ser declarados al inicio con PROCESS(name, strname). Por otra parte elcuerpo (protothread) del proceso debe ser definido con PROCESS THREAD(name, ev, data).Éste proceso es llamado cuando ocurre un evento cualquiera en el sistema. Todo proceso debecomenzar con un PROCESS BEGIN() y terminar con PROCESS END().

Los procesos pueden tener tres estados:

Llamado (se está ejecutando)

Activado (puede ser llamado)

Desactivado (no puede ser llamado)

Algunas de las funciones que existen para manejar los procesos son:

PROCESS WAIT EVENT(); o PROCESS YIELD();Espera un post de evento para continuar el proceso.

5


PROCESS WAIT EVENT UNTIL(c);

Espera un post de evento para continuar el proceso y a una condición extra.

PROCESS WAIT UNTIL(c);

Espera a que ocurra la condición c .

PROCESS EXIT();

Sale del proceso que se está ejecutando.

4.2.2. Eventos

Los eventos desencadenan la ejecución de un proceso y son guardados en una colacircular siendo procesados en orden cronológico. Estos pueden ser generados por porcesos ointerrupciones. Cada vez que se invoca un evento el kernel env́ıa al proceso a ser despertado elID del evento en ev y eventualmente datos en el puntero data.

La interacción entre los procesos se realiza conprocess post(struct process *p, process event t ev, void *data)

para hacer un post aśıncrono o conprocess post synch(struct process *p, process event t ev, void *data)

para hacer un post śıncrono a un proceso.

Los parámetros son:ev - el evento a ser posteadodata - puntero a la información que será e enviada junto al eventop - el proceso a ser posteado o PROCESS BROADCAST si se desea postear a todos los procesosexistentes

Valores retornados:PROCESS ERR OK (0) - posteo exitosoPROCESS ERR FULL (1) - la cola de eventos se encontraba llena y no fue posible postear elevento

5. Implementación

5.1. Generación y almacenaje

5.1.1. Generación

Para poder aplicar tanto los algoritmos de procesamiento de imágenes como los detransmisión de datos era necesario partir inicialmente de una imagen. Aunque una alternativavalida podŕıa haber sido cargar una imagen en formato matriz al nodo mediante la UART, seoptó por generar una pseudoimagen en el mismo y alojarlo en la memoria Flash, ya que deesta forma se puede evaluar la performance del nodo al realizar operaciones matemáticas. Deaqúı en adelante cuando se hace referencia al “patrón” nos referimos a la pseudoimagen.

Cada elemento del patrón simboliza un pixel de una imagen en escala de grises y para unificarcriterios en el tipo de enteros con respecto a la convolución se decidió que los elementos delpatrón fuesen int8 t, es decir enteros de 8 bit con signo. Más adelante se justificará esta elección.

6


Dado que el patrón simula una imagen, éste se puede ver como una matriz de dimensionesLARGO×ANCHO o también como una función de N2 en N , donde valores de salida mayorescorresponden a mayores valores de blanco. En un comienzo se eligió generar el patrón configuras como conos, cubos, hiperboloides, etc. y se planteó la posibilidad de agregarle una capasinusoidal de baja amplitud, un ruido aleatorio o ambos. El patrón consistiŕıa entonces en lasuperposición de todas las anteriores.

Algunas de estas figuras significaron una verdadera dificultad dado que para generar un conoo una sinusoide es imprescindible contar con funciones de la libreŕıa math.h, la cual no se pudoincluir correctamente en el código de Contiki. Al presentarse este problema se buscó una solucióntanto en la web como en proyectos anteriores del curso. Una de las soluciones encontradas eraincluir al final del archivo Makefile.include la bandera −lm, sin éxito. Luego de lidiar un tiempoconsiderable con este problema se decidió continuar el proyecto generando aquellas figuras quese pudieran construir sin la libreŕıa y dejar de lado, por el momento, aquellas que la necesitaran.

5.1.2. Interacción entre generación y almacenaje

Luego de implementado el proceso encargado de generar el patrón se comenzó a probarsu funcionamiento con dimensiones pequeñas, tales como matrices cuadradas de LARGO yANCHO iguales a 10. Una vez satisfechos con los resultados iniciales se fue incrementando eltamaño de la matriz hasta obtener un patrón de tamaño cercano a 2KB, punto en el cual seobservó que se comenzaba a sobrecargar la memoria RAM del nodo por lo que se concluyó quela memoria RAM del nodo no podŕıa contener un patrón de un tamaño mayor al mismo. Estoconspiraba claramente con los objetivos del proyecto, por lo que se optó como solución generarde a una fila (debe ser de tamaño menor a 2000) y guardarla en la memoria Flash externa antesde generar la próxima.

En la memoria Flash se guardan las matrices en forma de vector por lo que para poder pasarde una forma sencilla de matriz a vector y viceversa, se deb́ıo establecer una relación biuńıvocaentre los ı́ndices de ambos. Esta relación establece que para el elemento de la fila i y columnaj de la matriz le corresponde el elemento del vector dado por:

Ai,j ⇔ v(i×ANCHO)+j (1)

Esta relación es de gran utilidad dado que se facilita tanto la lectura como la escritura en lamemoria y también permite seleccionar segmentos precisos de la matriz, lo cual se utilizará enel proceso de detección.

Para cumplir con la premisa elegida para la generación y almacenamiento de cada filase implementaron dos procesos distintos, uno encargado de la generación y el otro delalmacenaje, necesitando una correcta interacción entre ambos. Para esto se usaron los comandosprocess post y PROCESS WAIT EVENT UNTIL , por ejemplo cuando el proceso de generación leda paso al de almacenaje lo hace con:

process post(& escritura, buf listo, patron);

PROCESS WAIT EVENT UNTIL(ev==escritura ok);

En la primera instrucción se le hace un post al proceso escritura, con el evento buf listo yademás el puntero a patron en DATA. En la segunda instrucción se queda esperando a que elproceso de escritura le avise que culminó su participación con el evento escritura ok.

7


5.1.3. Almacenamiento en memoria FLASH

Para implementar el almacenamiento de información en la memoria flash se hizo uso de dosherramientas de Contiki OS: el CFS (Contiki File System) y una extensión del mismo llamadoCFS-Coffee.

Las funciones que se utilizaron del CFS-Coffee fueron:

int cfs coffee format( void );

Esta función formatea la memoria FLASH, y retorna un 0 si es exitoso y un -1 si no loes.

void cfs coffee reserve(const char *name, cfs offset t size);

Esta función reserva size lugar en memoria para el archivo name en la memoria

Y las utilizadas de la herramienta CFS fueron:

int cfs open(const char* name, int flags );

Esta función abre el archivo name bajo las opciones declaradas según el valor de flags,estas pueden ser:CFS READ - si se quiere leer el archivoCFS WRITE/CFS APPEND - si se quiere escribir el archivo.

int cfs write(int fd, const void* buf, unsigned int len);

Esta función permite escribir en el archivo identificado por fd una cantidad de bytes iguala len desde el buf.

int cfs seek(int fd, cfs offset t offset, int whence);

Esta función ubica el puntero de lectura en el archivo identificado por fd bajo las opcionesdeclaradas según el valor de whence, estas pueden ser:CFS SEEK CUR - se ubica el puntero a una distancia offset desde la posición actual delmismo.CFS SEEK END - se ubica el puntero a una distancia offset desde el fin del archivo.CFS SEEK SET - se ubica el puntero a una distancia offset desde el comienzo del archivo.

int cfs read(int fd, void* buf, unsigned int len);

Esta función permite leer del archivo identificado por fd una cantidad de bytes igual alen hacia el buf.

int cfs close(int fd);

Esta función cierra el archivo identificado por fd

5.2. Detección

El algoritmo de procesamiento de imagen propuesto consiste en una detección de bordessimple, lograda a partir de la convolución matricial del patrón de memoria generadoanteriormente con un kernel de 3x3.

Éste método se fundamenta en que una imagen en escala de grises puede considerarse comouna función bidimensional de dominio natural donde el valor funcional de un punto es mas alto

8


en tanto su nivel de blanco sea mayor. Los bordes de dicha imagen son en definitiva variacionessignificativas en las derivadas direccionales de la función, es decir en su gradiente. Si calculamosel laplaciano resulta sencillo ver que grandes variaciones en los valores de blanco se correspondencon grandes magnitudes en el gradiente, y como el laplaciano[6] es la divergencia del gradiente,éste presentará una fuerte oscilación entre valores postivos y negativos.

Ahora, si suponemos que trabajamos con la submatriz 2,f[i−1,j−1] f[i−1,j] f[i−1,j+1]f[i,j−1] f[i,j] f[i,j+1]f[i+1,j−1] f[i+1,j] f[i+1,j+1]

(2)la derivada segunda del elemento (i, j) en la dirección de las filas será

δ2P

δ2i= (P[i,j] − P[i−1,j])− (P[i+1,j] − P[i,j]) = P[i+1,j] − 2P[i,j] + P[i−1,j] (3)

El resultado análogo es válido para las columnas. Si calculamos el gradiente

∇f(x, y) = δ2P

δ2i+δ2P

δ2j= P[i+1,j] − 2P[i,j] + P[i−1,j] + P[i,j+1] − 2P[i,j] + P[i,j−1] (4)

O, llevándolo a expresiones matriciales

∇f(x, y) =

f[i−1,j−1] f[i−1,j] f[i−1,j+1]f[i,j−1] f[i,j] f[i,j+1]f[i+1,j−1] f[i+1,j] f[i+1,j+1]

0 1 01 −4 10 1 0

111

(5)Si analizamos esta operación desde el punto de vista los recursos disponibles resulta evidente

la enorme cantidad de memoria necesaria. Si trabajáramos con una matriz de 100 × 100entonces debeŕıamos almacenar 20.000 bytes en la memoria RAM, un valor muy por encimade las capacidades del nodo. Se hace necesario un algoritmo que contemple este problema,minimizando el almacenamiento tansitorio en la RAM.

La solución ideal consiste en retirar los valores de la imagen desde la memoria Flash en formamodular, operar con el fragmento para obtener los valores correspondientes, descartar una partede los valores de imagen alojados en la RAM, cargar otra parte y seguir operando. Esta soluciónpresenta la ventaja de minimizar el acceso a la memoria Flash, pero si los fragmentos que seextraen de la memoria externa son demasiado grandes puede seguir habiendo problemas con lamemoria RAM, mientras que disminúır el tamaño de dichos fragmentos aumenta la complejidaddel código hasta niveles inaceptables.

Una solución alternativa es retirar los valores desde la memoria Flash siempre que se calculeun Laplaciano y no reutilizar ninguno al calcular el valor contiguo. Éste algoritmo resultabastante mas sencillo de implementar que la solución anterior, pero en contrapartida el accesoa la memoria Flash es ineficiente, lo que dispara los tiempos de ejecución y los consumos. Dadaslas limitaciones en el tiempo para la ejecución del proyecto se optó por ésta solución.

Otro aspecto relevante de la convolución matricial es la cantidad de operaciones básicasque requiere. Cada valor puntual del laplaciano requiere nueve multiplicaciones y ocho sumas,por lo que al trabajar con una matriz de, digamos, 640 × 480 será necesario realizar mas de4 millones de operaciones, lo que puede ser significativo en el tiempo de ejecución. Si a esosumamos que en la implementacón realizada cada valor calculado requiere tres accesos a la

9


Flash es de esperar que la operación requiera una cantidad de tiempo considerable.

En definitiva el algoritmo puede resumirse en los siguientes pasos:

1. Iniciar una iteración en i = 2, j = 2

2. Cargar en la RAM la submatriz formada por P(i−1,j), P(i,j), P(i+1,j) y sus vecinos izquierdos

y derechos. Éstos elementos conforman una matriz auxiliar de 3× 3

3. Multiplicar la matriz auxiliar con el kernel elemento a elemento y sumar los nueveresultados

4. Almacenar el resultado final en la posición (i, j) de un archivo de CFS creadoespećıficamente para almacenar los valores de salida

5. Incrementar i y j según corresponda. Se debe buscar que el elemento (i, j) no tome contactocon los bordes. Volver a cargar en RAM los valores necesarios

5.3. Transmisión

En la segunda etapa se buscó resolver el problema de transmitir el patrón desde unnodo TelosB a otro nodo sink conectado a un PC mediante el transceiver RF. Nuevamentenos encontramos con el problema de trabajar con grandes volúmenes de datos. Dadas lascaracteŕısticas de los datos con los que se trabaja, se requiere enviar la información en paquetes,sin errores tanto de información como de sincronización. Estas últimas fueron determinantesen la elección del módulo de Contiki OS Rime [5] a utilizar.

Cabe destacar que el nodo receptor tiene como única tarea recibir los paquetes e imprimiren consola v́ıa UART.

5.3.1. Módulo ABC

En primera instancia se utilizó el módulo ABC (Anonymous best-effort local area broadcast).Este utiliza un sólo canal e implementa una transmisión desde un nodo emisor que env́ıapaquetes a todos los vecinos locales, sin agregar headers a los paquetes de salida.ABC es resulta fácil de utilizar, sólo se necesitan las funciones:

void abc open( struct abc conn *c, uint16 t channel, const struct abc callbacks

*u);

Esta función abre el módulo ABC para env́ıos pasando como parámetros la estructuraabc conn 1, el canal y las funciones de callback2.

void abc close(struct abc conn *c);

Con esta función cerramos ABC antes abierto.

int abc send(struct abc conn *c);

Esta función pasa a una capa más baja llamada broadcast para enviar el o los paquetes quehay en packetbuf , mientras que para el manejo de paquetes se utiliza las funciones depaquetbuf.h como int packetbuf copyfrom(const void *from, uint16 t len) ..

1abc conn tiene los parámetros de la conexión2abc callback son las funciones llamadas internamente por la aplicación al enviar o recibir desde ABC

10


Cuando se logró implementar y probar este módulo se constató que exist́ıa tanto desfasajeen la matriz aśı como pérdida de paquetes. Esto ocurre debido a que, como se mencionó an-teriormente ABC no tiene previsto el control de secuencia de paquetes ni la espera de unacknowledge para seguir transmitiendo.

Por más que se intentó realizar cambios para poder utilizar este módulo, todos ellosresultaron ineficientes o inservibles, por ende se decidió migrar definitivamente la transmisiónpor radio hacia un módulo single hop.

5.3.2. Módulo RUNICAST

El módulo Runicast implementa una comunicación single hop del tipo stubborn unicast apartir de su primitiva Stunicast. Esta env́ıa repet́ıdamente paquetes por un único canal a unnodo vecino direccionado hasta recibir un acknowledge desde el nodo receptor para garantizarla recepción satisfactoria de los datos. Cuando el transmisor recibe el acknowledge el móduloRunicast notifica a la aplicación de env́ıo mediante un callback.

El módulo Stunicast, antes de transmitir un paquete coloca el paquete en una buffer circulary setea un timer, cuando ese timer expira se copia el paquete desde el buffer hacia el buffer deRime y se env́ıa el paquete.

Runicast agrega a Stunicast dos atributos de paquetes: el tipo de paquete y el ID del paquete.Este último corresponde a un número de secuencia de dos bits para los paquetes. Además si sellega al máximo de retransmisiones la aplicación es notificada mediante un callback.

Previo a la descripción de las funciones del módulo Runicast cabe analizar la estructura deconexión runicast conn:struct runicast conn {

struct stunicast conn c;

const struct runicast callbacks *u;

uint8 t sndnxt;

uint8 t is tx;

uint8 t rxmit;

uint8 t max rxmit;

};

La estructura stunicast implementa los atributos de conexionado para el mismo, mientrasque la estructura runicast callbacks contiene punteros a las funciones que son llamadas porla aplicación cuando se recibió un paquete, cuando se mandó un paquete satisfactoriamente(es decir cuando se recibió un acknowledge) o cuando se llegó a la cantidad máxima deretransmisiones.

Luego los enteros sin signo de 8 bits sndnext, is tx, rxmit y max rxmit correspondenal número de secuencia, a un ”booleano”que indica si está transmitiendo, al número deretransmisiones actual y al máximo de retransmisiones respectivamente.

Las funciones de Runicast son:

void runicast open(struct runicast conn *c, uint16 t channel,

const struct runicast callbacks *u);

11


void runicast close(struct runicast conn *c);

int runicast send(struct runicast conn *c, const rimeaddr t *receiver,

uint8 t max retransmissions);

Nodo transmisorLa implementación de la transmisión en el nodo transmisor se realizó mediante un procesollamado radio process. Dicho proceso es activado mediante un process post desde el proceso deconvolución y mediante una iteración desde cero hasta la cantidad de filas de la matriz env́ıade a paquetes la fila entera. Cada fila es dividida por un divisor de manera de no tener queenviar un último paquete con basura para rellenar el mismo. Cabe destacar que se coloca unetimer para generar un tiempo de delay que de lugar al nodo receptor a realizar tareas ajenasa la recepción de los datos.Nodo receptorEl nodo receptor simplemente tiene en su proceso principal un loop infinito mientras tieneactivado el módulo Runicast. Por lo tanto cuando llega un paquete, la aplicación lanza lafunción callback de recepción en la cual se imprime en consola v́ıa UART y se lleva un controlde secuencia comparando el ID de secuencia actual con el anterior.

if (seqno == seq){...imprimo paquete y fin de lı́nea al contar divisiones...

seq++; }else{

seq = 0;

}

6. Pruebas

6.1. Resultados

Durante el transcurso del proyecto se fue evaluando el funcionamiento de los distintosmódulos. En la primer etapa se evaluó fundamentalmente la generación del patrón (o matrizde imagen) con el nodo conectado al PC y en la segunda etapa se evaluó la convolución y latransmisión por radio hacia el nodo sink.

6.1.1. Resultados de generación

En primera instancia el proceso de generación solo generaba una matriz de tamaño reducidoque pod́ıa ser almacenada en la memoria RAM del nodo TelosB. Luego de que se obtuvo lasalida deseada, se comenzó a implementar y a evaluar la escritura en la memoria Flash a partirdel Contiki File System - Coffee.

En la figura 1 se puede observar una de las salidas3 de matriz de tamaño 640x480. En ella sepueden observar tres prismas (es importante destacar que en esta etapa se generaban prismasy no cubos) superpuestos y tres conos en distintas partes de la imagen.

La ejecución de este algoritmo y su impresión en consola mediante la UART implica untiempo aproximado de 40 minutos. Ese tiempo disminuye a solo 2 minutos 54 segundos si segeneran solamente cubos (en particular tres cubos). Esto ocurre debido a que para generar los

3Las imágenes de salida fueron levantadas con Matlab utilizando imshow y mat2gray

12


Figura 1: Imagen de 640x480 generada por el nodo

conos se deben realizar cálculos de potencias cuadradas. Cabe recordar también que para unamatriz de 640x480 se están guardando 307.200 bytes en la memoria Flash.

Si no se imprimen en consola los tiempos disminuyen drásticamente a 12 segundos 48milésimas en el caso de generar solo tres cubos. Para el caso de tres cubos y dos conos eltiempo sin imprimir en consola es 16 minutos, 46 segundos.

Claramente los tiempos de ejecución son muy grandes en el caso de generarse una matriz conconos y por comodidad (y tiempo) se continuó trabajando con matices sin conos para medidasy evaluación de los distnitos módulos.

En el caso de la convolución se comenzó evaluando matices pequeñas, desde 3×3 a 100×100hasta alcanzar 640 × 480. Las figuras 2(a) y 2(b) muestran la imagen generada por el nodo yla misma imagen luego de aplicarle el algoritmo de detección de bordes.

(a) Imagen de 350 × 350 gene-rada por el nodo

(b) Resultado de la detecciónde bordes de 350× 350

Figura 2: Imágenes desde el nodo en Etapa 1

Se observa que el resultado obtenido es el esperado, es decir existen saltos en los bordesdebido al cambio de concavidad de las figuras.

13


6.2. Resultados de transmisión

Los algoritmos de transmisión se fueron generando a partir de realizar pruebas enviandostrings o arreglos de enteros de un nodo hacia otro mediante módulos de transmisión y recepción.Una vez alcanzado un buen funcionamiento de dichos módulos se integraron al programaprincipal el proceso de transmisión y se realizaron pequeños cambios al módulo para el nodoreceptor.

Se observó que al transmitir matrices de hasta 200 × 200 se obteńıan resultados correctoscomo el de la figura 3(a), donde se resaltan los bordes de dos prismas.

El problema se encontró al enviar matrices de tamaño mayor, si bien no se fue probandocon pequeños aumentos, se conoce que ya para matrices de 300× 300 no se obtiene una imagencorrecta. Un ejemplo del resultado obtenido con estas matrices se puede observar en la figura3(b) con una matriz de 400× 400.

Este error fue causa de varios d́ıas de depuración, se realizaron variantes del programahasta encontrar que al imprimir en consola desde el nodo transmisor la lectura de la fila quese empaqueta para el env́ıo, lo transmitido y lo recibido coincid́ıan. De esta manera, se pudoconcluir que la transmisión en si misma funciona correctamente y el problema se encuentra alutilizar el módulo CFS en el proceso de env́ıo por la radio.

(a) Imagen correcta de 200× 200 (b) Imagen incorrecta de 400× 400

Figura 3: Imágenes recibidas en nodo sink

Se cree que el error está asociado al manejo que hace Contiki para almacenar en Flash, yasea por el offset de memoria o por como está implementado el garbage collector.

7. Medidas

Con el fin de evaluar el rendimiento del nodo se tomaron medidas de los tiempos deejecución de distintos procesos o segmentos de código. Estos fueron los tiempos de generacióndel patrón, de escritura/lectura en memoria FLASH y de transmisión de datos. Estos tiempo

14


fueron medidos dado que se consideran de importancia por dos razones, primero obteniendoel dato del consumo en corriente de la documentación del nodo para cada proceso medido sepuede estimar el consumo y segundo ver si existe una linealidad en cuanto a la cantidad deinformación procesada, con esto se podŕıa extrapolar las medidas a valores ditintos de los usados.

Para efectuar las medidas se eliǵıo un pin de salida, más especificamente se utilizo el pin GIO2(General purpose Input/Output), que se ubica tercero en el 6-pin expansion connector(U28),como se ve en imagen tal. La razón por la que decidio usar dicho pin es que este se puedecontrolar por software, entregando 3V en ON y 0V en OFF. Con la ayuda de un osciloscopiose realizaron las medidas correspondientes.

7.1. Medidas de escritura en la memoria FLASH

En este caso se midieron los tiempos de ejecución de la función cfs write para 1, 10, 50 y100 bytes, para esto se limito la ejecución con el encendido y apagado del pin. Los resultadosobtenidos del osciloscopio se pueden ver en la figura 4, y un resumen de las medidas en la tabla 1

(a) 1 byte TESC = T+ = 220µs (b) 10 bytes TESC = T

+ = 260µs

(c) 50 bytes TESC = T+ = 470µs (d) 100 bytes TESC = T

+ = 730µs

Figura 4: Medidas del tiempo de ejecución del comando cfs write

15


Largo (Bytes) Medidas (µs)

1 22010 26050 470100 730

Cuadro 1: Medidas para la ejecución del comando cfs write para 1, 10, 50 y 100 bytes

Del la tabla 1 se puede concluir que el tiempo de escritura en memoria para 1 o 10 bitses muy similar, esto es debido a que la esritura en memoria se realiza por paquetes. Para laescritura de 10, 50 y 100 bytes si se puede ver un comportamiento más lineal.

7.2. Medidas de generación y almacenaje

Para la generación y posterior almacenaje de una fila de 102 bytes, se realizaron lasmediciones que se pueden ver en la figura 5, donde el tiempo alto corresponde al tiempo degeneración, o sea para cada elemento de una fila y el envio del post, y el tiempo bajo al deescritura, abarca el toggle de un led, el cfs write y el post hacia generación.

Figura 5: TGEN = T+ = 2, 48ms

TESC = T− = 1, 64ms

TTOT = T+ + T− = 4, 12ms

En el caso de 50 y 102 filas los resultados se pueden apreciar en la figura 6, en este caso lostiempos de generación y almacenaje se ven sumados como el tiempo alto del pulso, incluyendolas mismas ejecuciones que el ejemplo anterior.

(a) 50 filas TGEN + TESC = T+ = 44ms (b) 10 bytes TGEN + TESC = T

+ = 424ms

Figura 6: Medidas del tiempo de generación + almacenamiento

16


Filas Medidas (ms)

1 4,1210 44102 424

Cuadro 2: Medidas para la Generación y almacenamiento para 1, 10 y 102 filas

En la tabla 2 se muestran todos los resultados de generación y almacenamiento, en estas sepueden apreciar claramente una relación de linealidad.

7.3. Medidas de transmisión

En lo que respecta a la transmisión de datos por la radio se realizaron dos medidas, env́ıode uno y dos paquetes de 50 bytes, a los que se enciende el pin cuando se encola el paquete y seapaga este cuando luego de ejecutar los callbacks se recibe el acknowledgment. Las medicionesse pueden ver en la figura 7 y en la tabla 3.

(a) 1 paquete TTRANS = T+ = 548ms (b) 2 paquetes TTRANS = T

+ = 1, 1s

Figura 7: Medidas del tiempo de transmisión

Cantidad de paquetes Medidas (ms)

1 5482 1100

Cuadro 3: Medidas para la transmisión para 1 y 2 paquetes de 50 bytes

8. Conclusiones

En primera instancia queremos destacar que se alcanzaron y en algunos casos superaronlos objetivos propuestos. Desde un comienzo hubo que superar varios obstáculos al trabajarcon Contiki y al enfrentarnos a las restricciones de hardware teniendo que repensar ciertosalgoritmos estándar para no sobrecargar la memoria RAM, el aprendizaje de conocimientosbásicos de tratamiento de imágenes y por último la transmisión por el transceiver RF y losprotocolos de Contiki.

Con respecto al RTOS utilizado cabe destacar que Contiki presenta muchas ventajas frentea otros sistemas operativos para sistemas embebidos debido a su abstracción de programación

17


que comparte elementos de multi-threading y event-driven pudiendo implementar máquinasde estado muy fácilmente y sin tener que reservar espacio de stack para cada thread. Losmódulos nativos de Contiki resultaron ser de gran utilidad en la mayoŕıa de las ocasiones,sin embargo cada uno consumió un tiempo significativo de estudio y análisis de ejemplosprevio a su utilización, sobre todo en el caso de CFS y Runicast. Estos dos módulos rquirieronrevisar su implementación, y en el caso de CFS modificar el tipo de dato del offset para subuen funcionamiento en este proyecto, ya que se manejaron volúmenes de datos fuera de loconvencional para aplicaciones WSN.

La mayor cŕıtica que se le puede realizar a Contiki es, tal vez, la falta de manuales. Si bienexisten repositorios y una buena API, el tener una mejor documentación de cómo implementaro utilizar ciertos módulos simplificaŕıa su aprendizaje.

En lo respectivo a la generación, se considera un acierto la relación establecida entre losı́ndices, permitiendo poder pasar de trabajar con el patrón de forma matricial a vectorial yviceversa. Esto permitió entre otras cosas poder trabajar por filas, y durante la detección poderobtener la submatriz a la que se le aplicaŕıa la convolución. También funcionó correctamentela interacción entre los procesos de generación y almacenamiento, aprovechando correctamenteel multi-threading que ofrece Contiki.

Se identificó que el tiempo que consume generar los conos es excesivamente grande encomparación con el que consume la generación de un cubo. El tiempo consumido en escribir lamemoria es mucho menor al tiempo consumido en generar la pseudoimagen y más aún en elcontexto de la convolución y transmisión.

La performance del nodo durante la detección fue satisfactoria, ya que el algoritmo correen un tiempo aceptable y los resultados son los esperados. Los bordes pueden apreciarse muyclaramente en las imágenes, quedando resaltados con fuertes oscilaciones.

En el momento de implementar el método de detcción tuvimos el temor de que el acceso pocooptimizado a la Flash disparara los tiempos de ejecución, sin embargo este tiempo se vuelvedespreciable frente a los que insume la transmisión por lo que no impacta fuertemente en elconsumo total del proceso. En una aplicación de consumo cŕıtico puede resultar interesanteencontrar una forma de minimizar el número de accesos a la Flash, ya que éste tipo deoperaciones suele requerir grandes cantidades de enerǵıa. Por otro lado consideramos que elhaber ignorado los pixeles periféricos de la imagen al detectar sus bordes es un gran acierto,ya que simplifica enormemente el código (lo que en definitiva resulta en una disminución en eltiempo de ejecución) y no se pierde información de gran importancia, dado que en general losobjetos a detectar se encuentran centrados.

Seŕıa interesante comparar los resultados del método implementado en este proyecto con otrode los descritos, por ejemplo el de detección por módulo del gradiente. A causa de la limitante detiempo que tiene nuestro proyecto no fue posible realizarlo. Consideramos que haber sustiuidoel algoritmo que se hab́ıa planteado originalmente (compresión de Huffman) por el de detecciónde bordes fue beneficioso para el proyecto, ya que el algoritmo implementado consumió menostiempo de aprendizaje per se y a su vez produce efectos mas apreciables a simple vista. Losdatos obtenidos de este proceso son relevantes para el proyecto de grado.

El env́ıo por el transceiver RF funcionó en una comunicación single-hop, dadas lascomplicaciones inherentes al env́ıo por radio nos encontramos satisfechos con los resultados

18


obtenidos en cuanto a la fiabilidad de los datos recibidos. El haber tenido que reciclar el módulode transmisión y cambiar del ABC al Runicast nos permitió investigar considerablementealgunos detalles de las primitivas de algunos protocolos de comunicación, principalmente enla capa de enlace de datos.

En lo que refiere a las medidas relevadas en esta parte, se tomaron tiempos de ejecuciónefectiva, es decir tiempo entre la carga de paquete por parte de la aplicación al módulo Runicasty el retorno del callback luego de recibir un acknowledge. Dado que no se obtuvieron tiemposcomparativos no se pueden sacar conclusiones de peso respecto a la eficiencia del módulo. Puedeconsiderarse a futuro estudiar las capas bajas de los módulos de transmisión de Contiki paradeterminar tiempos y consumo.

Finalmente queremos enfatizar lo novedoso de este trabajo, en el que un nodo creado paramanejar pequeñas cantidades de información se utilizó para generar, procesar y transmitirgrandes volúmenes de información. Como parte de futuros trabajos al respecto se encuentranpulir los algoritmos, lograr que el sistema funcione en su completitud para matrices mayoresa 200 × 200, realizar un análisis más profundo de consumo y probar otros métodos deprocesamiento que utilicen la convolución (u otros kernels).

19


9. Bibliograf́ıa

Referencias

[1] STM32WRF Control kit www.willow.co.uk/html/telosb_mote_platform.html

[2] PLAGAVISIÓN, proyecto de grado 2013. Autores: J. Schandy, N. Wainstein, M. González.Tutor: L. Barboni

[3] G. Galassi, R. Oberti, P. Tirelli, N. Borghese, F. Pedersini. Automatic monitoringof pest insects traps by Zigbee based wireless networking of image sensors. Online: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5944204&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5944204

[4] RTOS creado por Adam Dunkels. On line: www.contiki-os.org

[5] El stack de comunicación Rime provee una serie de primitivas livianas de comuni-cación desde singlehop hasta broadcast. On line: http://www.sics.se/~adam/slides/dunkels07adaptive.ppt

[6] I. Olmos Operadores por regiones. Procesamiento digital de imágenes. http://www.cs.buap.mx/~iolmos/pdi/Sesion6_FiltrosRegiones.pdf

20

www.willow.co.uk/html/telosb_mote_platform.htmlhttp://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5944204&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5944204http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5944204&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5944204www.contiki-os.orghttp://www.sics.se/~adam/slides/dunkels07adaptive.ppthttp://www.sics.se/~adam/slides/dunkels07adaptive.ppthttp://www.cs.buap.mx/~iolmos/pdi/Sesion6_FiltrosRegiones.pdfhttp://www.cs.buap.mx/~iolmos/pdi/Sesion6_FiltrosRegiones.pdf


10. Anexo

10.1. Conceptos del curso aplicados al proyecto

En este proyecto se abarcaron varios conceptos introducidos en el curso, entre losmás importantes destacar el uso de un RTOS en microcontroladores, programación en C,programación modular, entre otros. Si bien al utilizar Contiki no se debieron implementar lasrutinas de interrupciones ni configurar las comunicaciones con los periféricos, nunca se perdió devista los requerimientos o las limitantes de hardware.

Poniendo énfasis en el manejo de RTOS, los principales conceptos trabajados son los dekernel, scheduler, procesos, threads, queues,semáforos/post, etc..

10.2. Especificación del proyecto

El documento entregado previamante se encuentra adjunto al final

10.3. Planificación del proyecto

En el comienzo se proyecto la planificación semanal que se aprecia en la tabla 4, losprincipales cambios que se vieron necesarios realizar a las dos semanas fueron cambiar delalgoritmo de Huffman a la convolución bidimensional, y se realizo el trabajo planificado paralas primeras dos semanas en tres. Esto brindó la posibilidad de comenzar a trabajar en latransmisión por radio antes de lo planificado. Cabe destacar de todas maneras que el tiempodedicado al proyecto fue mayor a las ocho horas semanales especificadas para poder alcanzarlas metas planteadas.

Semana Objetivo

1 Introducción a ContikiManejo de aplicaciones básicas con Contiki

Elección del partón a escribir en la memoria flash2 Continuar experimentando enfocándose en escribir el patrón de señal en Flash3 Hito. Comenzar a escribir código de escritura en memoria y Huffman4 Escribir código definitivo y tomar medidas.

Hacer aplicación en Matlab para verificar la eficiencia delalgoritmo,descomprimiendo la señal y verificando que se recupere

la original. Analizar los errores de truncamiento.5 Hito 2 (tentativo). Análisis de la capacidad del transceiver RF.

Aplicación de transmisión y recepción.Reportar medidas

Cuadro 4: Planificación semanal proyectada inicialmente

Al final la planificación sufŕıo además de los cambios antes mencionados, los siguientes:

La escritura del código definitivo y las medidas no se pudieron realizar hasta la últimasemana.

No hay errores de truncamiento en el algoritmo definitivo.

21


Se tomaron las dos semanas posteriores a la culminación del proyecto para efectuar ladocumentación.

La planificación real con la que se concluyó el proyecto se puede apreciar en la tabla 5.

Semana Objetivo


Elección del partón a escribir en la memoria flash2 Continuar experimentando enfocándose en escribir el patrón de señal en Flash3 Hito 1. Comenzar a escribir código de escritura en memoria y de la convolución4 Hacer aplicación en Matlab para verificar la validez del

algoritmo, comparando la señal y verificando que se recuperela original.

Aplicación de transmisión y recepción.5 Hito 2. Escribir código definitivo y tomar medidas.

Análisis de la capacidad del transceiver RF.Reportar medidas

6 y 7 Escribir la documentación.

Cuadro 5: Planificación semanal real

22

Estudio de técnicas y metodoloǵıas para desarrollar eficientementeaplicaciones WSN con funcionalidades de percepción visual

Casos de estudio: i) implementación y evaluación de rendimiento del -Huffman algorithm- en un nodo claseTelosB compatible (i.e. una clase de algoritmo de compresión) y ii) implementación y evaluación de rendimiento de

la comunicación radio con grandes volúmenes de infomación (e.g. 1MB)

Autores: Nicolás Lamath, Nicolás Wainstein, Mauricio González

27 de junio de 2013

1. Descripción del problema bajo estudio

Las redes de sensores inalámbricos, además de registrar magnitudes f́ısicas y responder a eventos mediantealgoritmos predeterminados, ya se encuentran evolucionando hacia la implementación de técnicas de datafusion, en donde la información que proviene de múltiples sensores distribuidos es combinada y utilizadapara construir estructuras mas complejas. El procesamiento y transmisión de imágenes (sentido de visión)se encuentra dentro de esta clase de funcionalidades emergentes para las redes de sensores inalámbricos.Éstas nuevas aplicaciones surgen debido a la aparición de nuevas generaciones de nodos, sensores, técnicas deprocesamiento de información para sistemas con recursos hardware limitados y reducido budget energético,asi como por los avances teóricos en programación con procesamiento simbólico algebraico y mejoras en lasformas de implementar comunicaciones inalámbricas low-rate low-power.

Durante la realización del proyecto se explorará la capacidad del nodo TelosB para realizar tareas decompresión y transmisión de grandes paquetes de información, documentando todas las dificultades quesurjan en el proceso. En este contexto el problema a resolver es recabar información que permita tomardecisiones de dieño para desarrollar eficientemente aplicaciones de redes de sensores inalámbricos confuncionalidades de percepción visual.

Etapa 1: Escribir un patrón de información que ocupe toda la memoria flash externa del nodo TelosB,aplicarle compresión de Huffman y devolverlo al PC, comparando el patrón inicial con la reconstrucciónen la PC. El nodo estará conectado al PC durante esta etapa de prueba, y no se realizá ningunaactividad con la radio del mismo. También se medirá el consumo de corriente durante la ejecución delalgoritmo, información muy relevante como medida de su eficacia. Esto se implementará escribiendo elcódigo en Contiki y un módulo que se acoplará al SO.

Etapa 2: Opcionalmente (si el tiempo lo permite al terminar la etapa 1) se enviará el patróncomprimido desde el TelosB a otro TelosB conectado a un PC mediante el transceiver RF, para luegocomparar las señales en el PC. El objetivo de esta etapa es observar el comportamiento de la radio (e.g.consumo de corriente y tiempos involucrados) cuando se ordena el transporte de grandes volúmenesde información en bytes.

2. Antecedentes

Este proyecto busca encontrar los problemas inherentes de la compresión y env́ıo de grandes paquetes (e.g.imágenes) desde un nodo en forma inalámbrica, enmarcándose en el proyecto de grado PLAGAVISIÓN

1

Sistemas Embebidos para Tiempo Real - Entrega definitiva del proyecto - R.15/5- 11:00am

[1]. Además de enviar las imágenes el sistema debe encargarse de modificar ciertos aspectos de las mismas(como por ejemplo resaltar los bordes de los objetos fotografiados, comprimir al máximo zonas donde no seencuentre ningún objeto, o alguna otra acción a definir).Entre los antecedentes se encuentra una experiencia similar desarrollada en Italia para controlar plagas enviñedos [2]. Si bien la aplicación de dicho sistema es muy similar a la nuestra se deberá investigar si el métodode análisis de imágenes utilizado es compatible con nuestras necesidades.

3. Objetivos del proyecto

3.1. Objetivos generales

Aplicar los conocimientos adquiridos en el curso de Sistemas Embebidos.

Lograr escribir un módulo en Contiki que escriba un patrón en la memoria flash externa de un TelosB,aplicarle el algoritmo de compresión de Huffman, evaluar ejecución y posteriormente enviarlo por eltransceiver RF a otro nodo TelosB conectado a un PC y comparar el patrón inicial con la final. Evaluarla performance del sistema al aplicar el algoritmo de procesamiento y el desempeño de la radio paratransportar grandes volúmenes de información (eficacia de la capa MAC implementada en Contiki).(Este objetivo involucra la etapa 1 y la etapa 2 )

3.2. Objetivos espećıficos

1. Probar el funcionamiento del algoritmo de compresión de Huffman en un nodo. Éste objetivocontibuirá al estudio de algoritmos de procesamiento de datos visuales que se realizará en el proyectoPLAGAVISIÓN.

2. Implementar dichas técnicas bajo el OS Contiki. Evaluar rendimiento y ventajas de Contiki para estetipo de aplicaciones.

3. Si el tiempo lo permite implementar el env́ıo inalámbrico del patrón de información entre nodos,utilizando comunicación single hop. Se debe analizar como segmentar la información para que entre enel payload del paquete definido en el estándar IEEE 802.15.4

4. Redacción de la documentación correspondiente.

4. Alcance del proyecto

Este proyecto no incluye ninguna parte del hardware necesario para el proyecto PLAGAVISIÓN. Nose considerará la comunicación del nodo con la cámara que posteriormente se encargará de tomar lasimágenes, sino que se utilizará un patrón de señal generado mediante Matlab.

No se investigarán distintos algoritmos de procesamiento y compresión de imágenes.Se elije uno enparticular para estudio (Huffman)

No se tomarán en cuenta las necesidades de bajo consumo que tiene el proyecto de grado, pero si semedirán consumos de corriente y tiempos de ejecución de las aplicaciones implementadas.

No se considerará armar una red de sensores, a lo sumo se asumirá una comunicación unilateral entreambos nodos (single hop).

La evaluación de las capacidades, ventajas y desventajas de los distintos nodos no está incluida en esteproyecto. Se elije la plataforma TelosB.

Realización del software necesario en Contiki para la escritura en memoria flash y manipulación delpatrón y para la recepción y env́ıo de la misma a través de la radio en caso de ejecutar la etapa 2.

2

Sistemas Embebidos para Tiempo Real - Entrega definitiva del proyecto - R.15/5- 11:00am

5. Criterios de éxito

Consideraremos que el proyecto fue exitoso si:

• El patrón de señal que se escribe en la memoria puede ser procesado por el nodo en tiemporazonable (el tiempo razonable es una variable con sentido abierta aún y que se definirá duranteel transcurso del proyecto), lo que se traducirá en un consumo de corriente de bateria bajo.

• El algoritmo de compresión de Huffman funciona correctamente.

• La transmisión de datos entre nodos se produce correctamente y/o si aparecen problemas soncorrectamente reportados.

Si no se logra la transmisión entre nodos no se considerará como fracaso puesto que creemos que elaprendizaje del OS Contiki, aśı como la implementación del algoritmo y manejo de la flash requerirá unnúmero de horas de estudio y trabajo considerable. La etapa 2 de este proyecto queda abierta anegociación con el tutor, pudiéndose eliminar completamente si se encuentra que se debe profundizarestudio y actividades en la etapa 1 por la relevancia de los resultados que se puedan ir obteniendo.

6. Planificación semanal

Cuadro 1: Planificación semanal

Semana Objetivo


Elección del partón a escribir en la memoria flash2 Continuar experimentando enfocándose en escribir el patrón de señal en Flash3 Hito. Comenzar a escribir código de escritura en memoria y Huffman4 Escribir código definitivo y tomar medidas.

Hacer aplicación en Matlab para verificar la eficiencia delalgoritmo,descomprimiendo la señal y verificando que se recupere

la original. Analizar los errores de truncamiento.5 Análisis de la capacidad del transceiver RF.

Aplicación de transmisión y recepción.Hito 2 (tentativo). Reportar medidas

Referencias

[1] PLAGAVISIÓN, proyecto de grado 2013. Autores: J. Schandy, N. Wainstein, M. González. Tutor: L.Barboni

[2] G. Galassi, R. Oberti, P. Tirelli, N. Borghese, F. Pedersini Automatic monitoring of pest insects traps byZigbee based wireless networking of image sensors On line: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5944204&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%

3D5944204

[3] STM32WRF Control kit www.willow.co.uk/html/telosb_mote_platform.html

3
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5944204&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5944204http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5944204&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5944204http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5944204&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5944204www.willow.co.uk/html/telosb_mote_platform.html

Documentaci on nal - Universidad de la República · 2018. 3. 13. · En el transcurso de la...

Documents

Transcript of Documentaci on nal - Universidad de la República · 2018. 3. 13. · En el transcurso de la...