Camera Full ControlSistemas Embebidos Para Tiempo Real 2015

Autores: Ignacio AbadieAldo VignoneMauro Martínez

Tutor: Leonardo Barboni

INSTITUTO DE INGENIERÍA ELÉCTRICA – FACULTAD DE INGENIERÍA UNIVERSIDAD DE LA REPÚBLICA

1. Resumen

Camera Full Control se enmarca dentro del proyecto de fin de carrera titulado AgroVisión.

Se trabajó sobre un sistema formado por un nodo CC2538 de ARM que maneja una cámara M12x0.5 Camera Lens - LS-20150 f=2.8mm de LinkSprite mediante un driver. El driver fue diseñado por los grupos de Proyecto de fin de Carrera Plagavisión y WSNVisión.

El software en el nodo está implementado en Contiki OS.

Entre las funcionalidades del driver estan: la configuración de la cámara, la orden de tomar una foto para luego solicitar su transmisión y guardarla en la memoria del nodo.

El trabajo de este proyecto consistió principalmente en el estudio del sistema y el driver que lo maneja, incorporar al driver la capacidad de responder frente a errores de datos y pérdida de información durante la transmisión por el puerto de comunicación UART del sistema y el estudio del consumo que tiene el sistema para diferentes configuraciones de la cámara.

Para poder encontrar una solución a los problemas de comunicación en el driver primero se debió estudiar a fondo el módulo de UART de Contiki para comprender cómo maneja estos eventos el sistema. Esto queda comprendido dentro del proyecto.

Dentro de las conclusiones que desprendemos del trabajo remarcamos que cumplimos mayormente con los objetivos planteados al comienzo del proyecto con la salvedad de que aún queda pendiente la estimación de los tiempos de procesamiento del sistema en las diferentes configuraciones de la cámara debido a complicaciones que surgieron durante la realización del trabajo y que serán explicadas más adelante.

1

2. Tabla de contenido

1. Resumen…………………………………………………….. pág. 1

2. Tabla de contenido………………………………………….. pág. 2

3. Introducción………………………………………………….. pág. 3

4. Objetivos……………………………………………………... pág. 4

5. Alcance……………………………………………………….. pág. 5

6. Diseño e Implementación…………………………………... pág. 5

6.1. Driver Cámara……………………………………... pág. 6

6.2. UART……………………………………………….. pág. 6

6.3. Timer………………………………………………... pág. 9

6.4. Verificación de Markers…………………………... pág. 11

6.5. Perfiles de corriente………………………………. pág. 15

7. Evaluación de Performance y Resultados……………...... pág. 17

8. Conclusiones………………………………………………… pág. 18

9. Anexo……………………………………………………........ pág. 19

9.1. Conceptos del curso aplicados al proyecto…….. pág. 19 9.2. Especificación del proyecto………….…………... pág. 20

9.3. Planificación del proyecto……………………….... pág. 28

2

3. Introducción 3.1. Descripción del problema a ser resuelto

Los nodos usados son CC2538 ARM Cortex M3-Based. La placa medidora de consumo de corriente consiste en un integrador LTC4150 y un amplificador de corriente INA139.

Se divide en dos partes:

● Driver Cámara:

Entender el driver de la cámara de WSNvision y agregar a dicho software la capacidad de responder ante cortes en la rafaga de datos cámara-nodo. La pérdida de datos puede ser provocada, por ejemplo, por un contacto oxidado que aísla un pin. (Vale recordar que este dispositivo forma parte de trampas que serán colocadas en el campo, donde estos factores son de gran consideración). Entonces, buscamos garantizar que el driver tenga control sobre dichas fallas, de modo que en la flash del nodo se encuentre el jpeg con todo lo necesario para realizar la reconstrucción de la imagen.

Como complemento a lo mencionado anteriormente, se contemplará también la posible corrupción de los datos. Específicamente se desarrollará un programa que compruebe la integridad de todos los markers que conforman el formato jpeg y que estos toman los valores correctos.

● Consumo de corriente en toma de Imagen:

Medir el perfil de consumo de corriente de la cámara, desde que ésta última se prende hasta que la imagen se encuentra en la flash del nodo variando los parámetros de resolución y compresión de imagen. Tal consumo es para observar la funcionalidad de la cámara y obtener un consumo detallado que hasta ahora no se conoce para el funcionamiento global nodo-cámara-interfaz.

3.2. Antecedentes:

El proyecto de fin de carrera “WSNVisión” diseñó la placa medidora de consumo de corriente. El soldado de la misma fue realizado por el proyecto de fin de carrera “AgroVisión”. Al comienzo del proyecto restaba realizar dos test en la placa: que el amplificador de corriente amplifica según las descripciones de funcionamiento de su datasheet y verificar que el bloque integrador funciona e interrumpe adecuadamente. Para ambas pruebas se utilizaron un osciloscopio digital y un generador de señales.

Se hereda todo el Hardware y Software necesario para obtener una imagen y guardarla en la flash del nodo. La descripción de los componentes se hará en el punto 7.1.

3

Cabe destacar que la placa de medición de consumo de corriente es un instrumento que permite visualizar y entender determinadas características del comportamiento y no es representativo de la finalidad del Proyecto de Sistemas Embebidos.

4. Objetivos

❏ Interiorizarse con:● el CC2538 ● la cámara M12x0.5 Camera Lens - LS-20150 f=2.8mm y el driver de la misma.

❏ En un principio, se quería obtener una medición del consumo de la cámara al momento de obtener una imagen y transmitirla al nodo hasta que la misma se aloje en flash en función de la resolución de imagen y compresión. Dicha información sería de gran utilidad para el proyecto AgroVisión, dado que la vida de las baterías en los nodos del proyecto deberán cumplir un tiempo mínimo de funcionamiento continuo. Lamentablemente debido a ciertas razones que se explicarán en la Sección 6.5, el objetivo se vio modificado a obtener un conocimiento de los perfiles de corriente y los picos de la misma al sacar una foto variando la compresión y resolución.

❏ Agregar al driver de la cámara la capacidad de asegurar que no se pierdan datos. Es decir, que en la flash del nodo se encuentre el jpeg con todo lo necesario para realizar la reconstruir de la imagen. La pérdida de datos puede deberse a cortes en las ráfagas de datos cámara-nodo, provocadas por un contacto oxidado, por ejemplo. (Vale recordar que este dispositivo forma parte de trampas que serán colocadas en el campo, donde este factor es de gran consideración).

❏ Contemplar la posible corrupción de los datos. Específicamente, desarrollar un programa que compruebe la integridad de todos los markers que conforman el formato jpeg y que estos toman los valores correctos.

❏ (Opcional) Comparar los datos obtenidos a partir de las mediciones hechas en el nodo en modos de bajo consumo con los datos proporcionados por el fabricante.

❏ (Opcional) Adicionalmente al realizar el estudio de los perfiles de corriente se obtendrán los tiempos de respuesta al solicitar una imagen.

5. Alcance

Obtener los perfiles de corriente del sistema cámara-interfaz-nodo y consumo de carga cuando el mismo hace uso de la cámara y cuando se encuentra en un estado de bajo consumo. Las mediciones del consumo del nodo por sí solo y comparación con los datos del fabricante es

4

opcional, al igual que los tiempos de respuesta del sistema cámara-interfaz-nodo al solicitar una imagen.

La modificación en el driver de la cámara contempla posibles errores en la imagen recibida por el nodo como pérdida de paquetes y datos corruptos. Sobre esto último, solo se verificará la integridad de los markers.

Se posee en su mayoría de todo el Hardware y Software necesario para realizar el estudio de los objetivos. Faltaría definir el método de prueba para forzar el error en la imagen via hardware que podría demandar minimamente algo de hardware.

6. Diseño e Implementación La solución ideada e implementada para el problema de pérdida de datos de este proyecto, se encuentra justificada a partir de un estudio minucioso del Driver de la Cámara proporcionado por WSNvisión y del entendimiento del funcionamiento y capacidad de respuesta a errores de la UART. La configuración de la misma se da a partir de los modulos uart.c y uart.h, proporcionados por Contiki OS, específicos para el cc2538.

Por otra parte, otro problema a atacar fue el de incorporarle al Driver la capacidad parcial de respuesta a la corrupción de datos. Era de suma importancia para el proyecto de fin de carrera de AgroVisión, dados los objetivos del mismo, asegurar la presencia correcta de todos los markers de la foto guardada en la flash del nodo. Se creó una función int verificar(), la cual verifica la presencia de todos los markers en la foto cuando se encuentra alojada en la flash del nodo.

A continuación se expondrá la funcionalidad del Driver de la Cámara al momento de recepción de la foto en el nodo, la capacidad de reacción de la UART ante errores y las soluciones ante pérdida y corrupción de datos respectivamente.

6.1. Driver Cámara:

El foco de estudio del Driver fue la recepción de la foto en el nodo. La Figura 01 muestra la dinámica del Driver al momento de la recepción a partir de un diagrama de flujo.

5

Figura 01: Diagrama de flujo de la recepción de la foto en el nodo

Dado el funcionamiento del Driver, el nodo solicita la foto a la cámara de a bloques de 112 bytes nombrados BLK. El bug que poseía el Driver era de que al momento de la recepción de un BLK, en caso que hubiese la más mínima pérdida de datos no reaccionaba nunca y continuaba esperando hasta recibir la información de tamaño total a un BLK. Por lo que el primer problema a resolver era investigar si nuestro sistema era capaz de darse cuenta cuando ocurría pérdida de información. Es por ello que hubo que realizar un estudio más profundo de la UART, entender su funcionamiento y las capacidades de reacción y respuesta ante pérdida de datos.

6.2. UARTLos tipos de errores posibles en la UART son tres:

● Overrun Error● Framing Error● Break Error

En nuestro sistema Cámara-Interfaz-Nodo, los tipos de errores más probables que pueden ocurrir son Framing y Break Error. Un Framing Error puede deberse ya sea a la pérdida del bit de Start o Stop, o un bit de data del byte transmitido provocando una descoordinación en la UART de recepción, debido a una ráfaga de viento o insecto que mueva los cables por ejemplo. Un Break Error puede ocurrir por un falso contacto de la comunicación, ya sea por oxidación en los cables o humedad que estropee los componentes eléctricos que conforman el sistema. La ocurrencia de dichos errores, son la causa del bug descripto en la sección anterior, por lo que nos llevó a investigar la capacidad de respuesta a estos errores por parte de la UART.

6

La figura 02 muestra gran parte de la void uart_isr() (función de atención a la interrupción de la UART). La función REG, implementada en el módulo reg.h proporcionado por Contiki OS para el cc2538, es utilizada tanto para realizar lectura de registros como para escribir en los mismos. Lo primero que realiza la función uart_isr() es realizar una lectura del registro MIS (Masked Interrupt Status Register) y un posterior clear del mismo registro. Dicho registro posee una flag para cada interrupción provocada por los Framing (UART_MIS_FEMIS), Overrun (UART_MIS_OEMIS) y Break Error (UART_MIS_BEMIS), la recepción de un byte (UART_MIS_RXMIS) y Time-out en recepción (UART_MIS_RTMIS). La estructura principal de la rutina de atención a la interrupción está compuesta por un if , el cual pregunta si en el registro MIS se encuentran seteadas las flags de recepción de byte o time-out en recepción. En caso afirmativo (true), la rutina se encarga realizar el correcto manejo de los bytes recibidos. En caso negativo (false), pregunta por el valor de las tres flags de error en UART anteriormente mencionadas. Como se puede apreciar, la acción que toma la uart_isr() en este último caso es llamar a la función void reset(uint32_t uart_base).

Figura 02: Gran parte del código de void uart_isr()

7

Figura 03: Función void reset(uint32_t uart_base) utilizada por void uart_isr()

La función void reset(uint32_t uart_base) (ver Figura 03) recibe como parametro un uint32_t, uart_base, el cual es la dirección en memoria inicial de la UART0 (el cc2538 posee dos módulos UART configurables, UART0 y UART1. En nuestro sistema la UART utilizada es la UART0). Algunas de las constantes con direcciones a registros de la UART (ej: UART_MIS, UART_CTL, etc.) estan definidas con direcciones relativas a uart_base. Básicamente, la función reset deshabilita la UART, escribiendo en el registro de UART_CTL el valor de UART_CTL_VALUE. Limpia el registro UART_ECR (UART Receive Status and Error Clear), guarda la configuración de la UART (UART_LCRH - Line Control Register) utilizando la variable auxiliar lcrh, limpia los FIFOs de recepción y transmisión, retorna la configuración y habilita la UART.

Por lo que la capacidad de respuesta de la UART ante algún tipo de error es básicamente la de reiniciarse y retomar la recepción en el siguiente byte, ocurriendo pérdida de datos. Como anteriormente se explicó, la carencia que tenía el Driver de la Cámara es que ante la mínima pérdida de información, ya sea un bit, el Driver queda esperando hasta recibir el tamaño total de BLK.

La solución tomada a este problema fue la de añadir al Driver un timer, el cual cada vez que empiece a recibir BLK’s de una foto, dispare el timer y en caso de que haya pérdida de datos en la recepción, el conteo a cero del timer llamará a una función (void timeout_callback (void *in) ), la cual se encargará de solicitar a la cámara el último BLK de foto que no fue recibido por completo.

8

Dado que se pretendía el mínimo consumo de energía por parte del sistema, la elección de la constante del timer era de vital importancia. Tiempos de espera innecesarios para realizar la solicitud del último BLK incompleto a la cámara podrían provocar un consumo de corriente considerable. El mínimo valor de la constante del timer es el máximo tiempo de recepción de los BLK’s de la foto, por lo que se ideó un método por software de estimación del tiempo de recepción para todos los BLK’s, el cual será descripto a continuación junto con la descripción del funcionamiento del timer y la dinámica que el mismo impone en el Driver de la Cámara.

6.3. Timer

El problema de la pérdida de información a través de la UART descripto en el punto anterior se resolvió agregando un timer al proceso “foto” del DriverCamara.

La foto es transmitida de a bloques de tamaño fijo (BLK) y el proceso espera a que un bloque llegue entero antes de solicitar el próximo. Esto se hace a través de un contador (cont) que lleva la cuenta de bytes recibidos por la UART; al recibir BLK+10 bytes (estos últimos 10 son el frame de la respuesta de la cámara ante la solicitud del bloque) se indica que el bloque llegó por completo y se lo graba en la memoria. En caso de no recibir el bloque completo, el driver se mantenía en espera hasta ser reseteado ya que no había un manejo ante este caso.

Figura 04: Incorporación de ctimer al proceso foto

Se agregó un ctimer (ct) al proceso luego de la solicitud de cada bloque. Un ctimer es un timer que al vencer su tiempo de seteo llama a una función. La función a la que llama el ctimer (timeout_callback) hace lo siguiente:

- lleva el contador a BLK+10 para que el proceso entienda que llegó el bloque completo.- resta BLK al puntero address (puntero a la dirección a la que se solicitará el próximo

bloque) para que se vuelva a solicitar el mismo bloque del que se perdió alguna parte.

9

- se levanta la bandera timeout_flag, que evita se escriba el último bloque recibido en la memoria.

- se vuelve al proceso foto.

Figura 05: Función timeout_callback

De esta forma se vuelve a pedir un bloque del que se perdió parte de la información al ser transmitido.

La otra parte del problema a resolver fue la de definir el tiempo (TIMEOUT) del ctimer.

Este tiempo debía ser lo suficientemente grande para no interrumpir innecesariamente el proceso, es decir que no se generara una interrupción porque no se dió el tiempo suficiente al bloque para ser transmitido por completo, pero no tan grande como para quedar esperando un tiempo en el que ya se sabe que el bloque no va a llegar completo.

Para tener una idea del orden de este tiempo, se hizo una primera aproximación tomando el tamaño del bloque (112 bytes) y el baudrate de la comunicación UART (115200bps). Esto nos dió un tiempo aproximado de 8ms, con lo que estimamos que el tiempo del timer debería estar en este orden.

Seguidamente se tomaron los tiempos en ticks del sistema del momento antes de setear el ctimer y el momento posterior a que el bloque llegó completo y se detuvo el ctimer para que no interrumpiera. La diferencia entre éstos tiempos se guardó en un arreglo en la memoria para cada uno de los bloques de la foto. Esta prueba se realizó para 3 fotos con la siguiente configuración de la cámara:

- tamaño: 1024x768- compresión: 0xA0

El tiempo máximo para un bloque fue el tomado para el tiempo de interrupción. Este tiempo fue de 4 ticks del sistema que equivale a 31.25ms (cada tick se aproxima a 7.8125ms). Para realizar estas pruebas el ctimer se seteo en un tiempo de 1s para evitar que interrumpiera durante estas medidas.

10

Figura 06: Cálculo de bloque_tiempo: tiempo de TIMEOUT

Figura 07: Tabla de tiempos en ticks que tarda en llegar un bloque

6.4. Verificación de Markers

Por otro lado, se pretende que el driver contemple la posible corrupción de datos, la cual se limitará, como se mencionó anteriormente, a verificar que se encuentren todos los Markers de la imagen en formato JPEG, una vez que esta se encuentra en la flash del nodo.

Entonces, en primer lugar, nos dispondremos a explicar brevemente el formato JPEG. Este es un método muy utilizado para la compresión de imagenes digitales. Básicamente se trata de un stream de datos compuesto por varios bloques, donde cada uno contiene información tal como: tamaño de la imagen, número de componentes, tablas de huffman, tablas de compresión, segmento de aplicación, entre otras.

11

Figura 08: Fracción de archivo JPEG

Cada uno de estos bloques tiene asociado un Marker que identifica al mismo. Estos Markers son de la forma “FF XX” y algunos de ellos se pueden apreciar en azul en la Figura 08.

Otra característica a destacar, es que luego del Marker que identifica al bloque se tienen dos bytes destinados a indicar el tamaño del bloque, lo cual destacamos en la figura anterior con los recuadros en rojo. Esta observación será fuertemente explotada, ya que se puede interpretar como el salto que uno tiene que dar (en bytes) para encontrar el próximo Marker.

Luego de tomar varias imagenes con la cámara, variando la compresión y la resolución de la misma, se observó que los Markers que se encuentran presente en la imagen, son siempre los mismos. Estos son:

❏ FF D8 SOI: Start of Image

❏ FF E0 APPo: Aplication segment

❏ FF DB DQT: Define Quantization Table

❏ FF C4 DHT: Define Huffman Table

❏ FF C0 SOFo: Baseline DCT

❏ FF DA SOS: Start Of Scan

❏ FF D9 EOI: End Of Image

Por lo tanto el objetivo es chequear que la imagen tenga presente todos y cada uno de los Markers anteriores una vez que esté alojada en la flash del nodo, de modo de poder reconstruir la imagen correctamente. Esto es de particular interés para nosotros ya que posteriormente en el marco del proyecto “AgroVisión”, se pretende procesar la imagen para obtener el conteo de las polillas. Por lo que, la verificación de los Markers resulta un paso previo fundamental.

12

Entonces, para cumplir con el cometido anterior, se implementaron 2 funciones:

❏ int verificar(): La función que chequea que los markers llegan correctamente

❏ void corromper(): Función que corrompe los markers. Esta se desarrolló para comprobar el correcto funcionamiento de la función anterior.

En la siguiente figura se muestra el diagrama de flujo de la función int verificar().

Figura 09: Arriba: Diagrama de flujo de la función que verifica los Markers. Abajo: Pasos que sigue la función

Como se podrá apreciar, la función se divide en tres pasos. El primero, es chequear la integridad del primer Marker. Luego, se chequean los restantes Markers excepto el último, teniendo en cuenta el salto de un Marker a otro. Y finalmente se chequea el último Marker.

Para poder fijar las ideas anteriores, en la Figura 10,11 y 12 se muestra el código de la función implementada.

13

Figura 10: Código primer paso de la función verificar

Figura 11: Código segunda etapa de la función implementar

Ahora, para chequear el último marker tenemos en cuenta que la imagen llega al nodo de a bloques y que en particular el último Marker se encuentra en el último bloque. Por lo tanto, levantamos de la flash del nodo el último bloque y es allí que realizamos la búsqueda y verificación.

Figura 12: Código tercera etapa función verificar (Parte 1)

14

Figura 13: Código tercera etapa función verificar (Parte 2)

Finalmente, como se mencionó, se implementó una función void corromper() para comprobar que la función int verificar() cumple con su cometido.

Para implementar la misma, se razonó de manera análoga a como se hizo anteriormente, solo que en lugar de chequear los Markers, estos fueron corrompidos imponiendo un “00” luego de cada “FF”. A continuación se muestra un diagrama de flujo de la aplicación.

Figura 14: Diagrama de flujo de la función que corrompe los markers

6.5. Perfiles de corrienteEl sistema anteriormente descripto, forma parte de una red de sensores inalámbrica (RSI). Por lo cual, es de vital importancia conocer cuál es la corriente que demanda el sistema frente a los distintos modos de operación, los cuales se pueden discriminar según la cámara esté encendida o apagada. A su vez, como se está trabajando sobre la plataforma Contiki, la cual

15

no se logró encontrar una herramienta de “debugg”, el estudio de los perfiles de corriente nos permitiría conocer en mayor medida, cuál es el comportamiento real del sistema. Realizados los test correspondientes sobre la placa medidora de consumo heredada de WSNVisión que se planeó utilizar para este punto, se observó que había un problema de hardware en el circuito del integrador, por lo que se descartó su uso para este proyecto.En cuanto al amplificador que iba a ser utilizado para obtener una mejor resolución del perfil de corriente se quemó en una de las pruebas que se realizaron. Además, la placa se deterioró bastante durante las pruebas por lo que se resolvió utilizar una nueva placa. Lamentablemente, esta placa, pedida el 5/6 , tardó más de lo esperado y no llegó antes de la fecha de finalización del proyecto por lo que se debió recurrir a otro método para realizar los perfiles de corriente. Las medidas se realizaron utilizando una resistencia de valor conocido (1,1 Ohm) y un multímetro. Esto nos permitió conocer el consumo instantáneo del sistema. Se intentó tomarlas con un osciloscopio pero dado el bajo consumo del sistema el ruido no nos permitió ver una señal detallada.

En la Tabla 01 se presentan los valores obtenidos de dicho ensayo, al variar la resolución y la compresión de las imagenes.

Tabla 01: Picos de corriente que toma el sistema en función de la compresión y la resolución cuando la cámara está apagada/encendida.

Se puede apreciar que los picos de corriente del sistema no varían prácticamente en función de la resolución y compresión. Lo que se pudo apreciar al momento de las medidas fue que cuanto menor la compresión y mayor la resolución, el tiempo en el cual la cámara se encontraba prendida era mayor, lo cual tiene mucho sentido común.

16

7. Evaluación de performance y resultados

En un principio, para evaluar que el software implementado para contemplar la pérdida de datos en la transmisión Cámara-Nodo funciona correctamente, se buscó lograr una desconexión de la UART de recepción del nodo utilizando un TXB0104 de Texas Instruments (ver Figura 15).

Figura 15: TXB0104 4-Bit Bidirectional Voltage-level Translator

Según el entendimiento de la datasheet del mismo, ubicándolo entre la conexión UART de la interfaz del nodo y el mismo nodo se podía lograr una desconexión parcial cortocircuitando VccA o VccB con GND (ver Figura 15). Se logró comprobar el funcionamiento utilizando señales en continua, pero al momento de probar con señales de tipo onda cuadrada (misma caso que en el de las señales en la UART), pudimos observar utilizando un osciloscopio que a partir de una frecuencia de 200 KHz aproximadamente la señal de salida del TXB0104 se veía completamente distorsionada y los escalones tenían forma de “olas”. Las pruebas que se hicieron incluyendo el circuito de Texas en nuestro sistema Cámara-Interfaz-Nodo no fueron exitosas debido a la gran distorsión que ocurría. Teóricamente, según la datasheet del TXB0104, el mismo era perfectamente utilizable para señales de hasta 10 MHz y las señales de comunicación que se manejan en nuestro sistema son de 115200 Hz.

Es por esto que para realizar las pruebas de desconexión de la UART desconectamos manualmente la conexión de recepción de UART del nodo. Haciendo esto se lograba provocar una cierta pérdida de datos con la cual en un principio, antes de proporcionarle capacidad de respuesta ante pérdida de datos al Driver, el sistema quedaba a la espera de esos datos que nunca iban a llegar. Se pudo observar que con la implementación del Timer, ante la provocación de la falla antes mecionada, la comunicación se retomaba perfectamente

17

solicitando el último BLK que no había sido recibido completo y posteriormente se hacía el pedido de los BLK’s restantes.

Luego, lo que respecta a la corrupción de datos nos limitamos, como ya se mencionó, a verificar la presencia de todos los Marker en la imagen. Para ello, una vez que se tiene una imagen en la flash del nodo, corrompemos sus Markers utilizando la función void corromper(), luego corremos el verificador implementado por la función int verificar(), y observamos que ambas cumplen su cometido. Cabe destacar que este procedimiento se realizó con el primer marker, luego con los del medio, el último y finalmente con todos los Markers. De esta forma se garantiza que todos los Markers son verificados.

Por último, observamos los perfiles de corriente para distintas resoluciones y compresiones. En un principio esta prueba estaba pensada para ser desarrollada con la placa amplificadora, pero debido a un inoportuno explicado anteriormente en la Sección 6.5 no se pudo utilizar. Es por esta razón que que dicha prueba fue realizada con una resistencia de valor 1,1 Ohm y un multímetro, obteniendo así los valores de la Tabla 01. Es claro que esta prueba es muy limitada, pero de todos modos pudimos apreciar un valor aproximado de la corriente que toma el sistema cuando la cámara está apagada/encendida.

8. ConclusionesComo primera conclusión a destacar, es que a partir del entendimiento del funcionamiento de la UART se logró agregar al driver la capacidad de respuesta ante pérdida y corrupción parcial de datos, lo cual representaba el cometido principal del proyecto.

A su vez, se observó que el tipo y tamaño de los Markers no varía en función de la compresión y resolución de la imagen, al menos para la cámara utilizada.

La corriente instantánea que demanda el sistema cuando la cámara está prendida/apagada es prácticamente constante (17,3 mA con cámara apagada y 100,5 mA con cámara prendida promediando) y no varía al utilizar diferentes compresiones y/o resoluciones. Queda pendiente realizar los perfiles de corriente para determinar los tiempos de procesamiento en cada una de éstas configuraciones.

Por otro lado, dada la experiencia que se obtuvo a lo largo del proyecto, es de vital importancia para nuestro Proyecto de Fin de Carrera “AgroVisión”, investigar sobre algún IDE que soporte la plataforma utilizada. Fue muy tedioso programar y probar el software desarrollado sin ninguna información de valores en tiempo real de registros y variables.

9. Anexo18

9.1. Conceptos del curso aplicados al proyecto

Entre los conceptos aplicados del curso se puede destacar lo aprendido sobre el lenguaje C, así como las experiencias que se tuvieron estudiando las hojas de datos del hardware utilizado.

En lo que más se invirtió el tiempo fue en el estudio del driver de la cámara para entender su funcionamiento y poder desarrollar este trabajo.

9.2. Especificación del proyecto y planificación

Nombre del proyecto: Full camera control

Integrantes:

Aldo Vignone, Mauro Martínez, Ignacio Abadie

Tutor:Leonardo Barboni

1- Descripción del problema a ser resuelto

Los nodos usados son CC2538 ARM Cortex M3-Based. La placa medidora de consumo de corriente consiste en un integrador LTC4150 y un amplificador de corriente INA139.

Se divide en dos partes:

● Driver Cámara:

Entender el driver de la cámara de WSNvision y agregar a dicho software la capacidad de responder ante cortes en la rafaga de datos cámara-nodo. La pérdida de datos puede ser provocada, por ejemplo, por un contacto oxidado que aísla un pin. (Vale recordar que este dispositivo forma parte de trampas que serán colocadas en el campo, donde estos factores son de gran consideración). Entonces, buscamos garantizar que el driver tenga control sobre dichas fallas, de modo que en la flash del nodo se encuentre el jpeg con todo lo necesario para realizar la reconstrucción de la imagen.

Como complemento a lo mencionado anteriormente, se contemplará también la posible corrupción de los datos. Específicamente se desarrollará un programa que compruebe la

19

integridad de todos los markers que conforman el formato jpeg y que estos toman los valores correctos.

También se realizarán mediciones del consumo del sistema cámara-interfaz-nodo cuando el driver de la cámara establezca un modo de pleno bajo consumo y verificar si realmente se encuentra en el mismo. Se compararán resultados de las mediciones con los datos del fabricante del nodo.

● Consumo en toma de Imagen:

Medir el perfil de consumo de corriente de la cámara, desde que ésta última se prende hasta que la imagen se encuentra en la flash del nodo variando los parámetros de resolución y compresión de imagen. Tal consumo es para observar la funcionalidad de la cámara y obtener un consumo detallado que hasta ahora no se conoce para el funcionamiento global nodo-cámara-interfaz.

2- Antecedentes:

El proyecto de fin de carrera “WSNVisión” diseñó la placa medidora de consumo de corriente. El soldado de la misma fue realizado por el proyecto de fin de carrera “AgroVisión”. Falta realizar dos test en la placa: que el amplificador de corriente amplifica según las descripciones de funcionamiento de su datasheet y verificar que el bloque integrador funciona e interrumpe adecuadamente. Para ambas pruebas se utilizará un osciloscopio digital y un generador de señales. Para la primera descrita, se pondrá como entradas determinadas señales y se verificará a la salida del amplificador la amplitud de la señal y para la segunda, a partir de una señal de continua con amplitud prefijada en la entrada, se comprobará si la cantidad de interrupciones por parte de la es cercana a lo esperado.

El funcionamiento de la placa medidora de consumo es el siguiente: A partir de una resistencia de sensado externa, monitorea la corriente entre la terminal positiva de la batería del nodo y la carga (nodo). Luego a través de un conversor de voltaje a frecuencia, transforma el voltaje sensado a una serie de pulsos en el pin de interrupción del Cortex. Estos pulsos corresponden a una cantidad fija de carga consumida desde la batería los cuales son contabilizados por software en el nodo.La utilidad del amplificador de corriente es la de poder caracterizar en detalle con el uso de un osciloscopio los perfiles de corriente. Posee una ganancia de 1 a 100 regulable a partir de una resistencia externa.

20

El software que se encargará de contabilizar las interrupciones será realizado para el proyecto de fin de carrera Agrovision y se encontrará pronto para el inicio del proyecto de Sistemas Embebidos.

Se hereda todo el Hardware y Software necesario para obtener una imagen y guardarla en la flash del nodo. La descripción de los componentes se hará en el punto 7.1.

Cabe destacar que la placa de medición de consumo de corriente es un instrumento que permite visualizar y entender determinadas características del comportamiento y no es representa a la finalidad del Proyecto de Sistemas Embebidos.

3- Objetivos del proyecto:

● Interiorizarse con:● el CC2538● la cámara M12x0.5 Camera Lens - LS-20150 f=2.8mm y el driver de la misma.

● Obtener una medición del consumo de la cámara al momento de obtener una imagen y transmitirla al nodo hasta que la misma se aloje en flash en función de la resolución de imagen y compresión. Dicha información será de gran utilidad para el proyecto Agrovision, dado que la vida de las baterías en los nodos del proyecto deberán cumplir un tiempo mínimo de funcionamiento continuo.

● Agregar al driver de la cámara la capacidad de asegurar que no se pierdan datos. Es decir, que en la flash del nodo se encuentre el jpeg con todo lo necesario para realizar la reconstruir de la imagen. La pérdida de datos puede deberse a cortes en las ráfagas de datos cámara-nodo, provocadas por un contacto oxidado, por ejemplo. (Vale recordar que este dispositivo forma parte de trampas que serán colocadas en el campo, donde este factor es de gran consideración)

● Contemplar la posible corrupción de los datos. Específicamente, desarrollar un programa que compruebe la integridad de todos los markers que conforman el formato jpeg y que estos toman los valores correctos.

● (Opcional) Comparar los datos obtenidos a partir de las mediciones hechas en el nodo en modos de bajo consumo con los datos proporcionados por el fabricante.

21

● (Opcional) Adicionalmente al realizar el estudio de los perfiles de corriente se obtendrán los tiempos de respuesta al solicitar una imagen.

4- Alcance del proyecto:

Obtener los perfiles de corriente del sistema cámara-interfaz-nodo y consumo de carga cuando el mismo hace uso de la cámara y cuando se encuentra en un estado de bajo consumo. Las mediciones del consumo del nodo por si solo y comparación con los datos del fabricante es opcional, al igual que los tiempos de respuesta del sistema cámara-interfaz-nodo al solicitar una imagen.

La modificación en el driver de la cámara contempla posibles errores en la imagen recibida por el nodo como pérdida de paquetes y datos corruptos. Sobre esto último, solo se verificará la integridad de los markers.

Se posee en su mayoría de todo el Hardware y Software necesario para realizar el estudio de los objetivos. Faltaría definir el método de prueba para forzar el error en la imagen via hardware que podría demandar minimamente algo de hardware.

5- Descripción del sistema:

5.1- Descripción funcional:

● Verificación de que la imagen haya llegado entera (datos corruptos y/o pérdida de paquetes).

● En caso de que no se cumpla lo anterior, si la imagen se sigue encontrando en la flash de la cámara se deberá solicitar el reenvío de la misma y sino se deberá solicitar a la cámara por una nueva imagen. La situación quedará determinada por la forma en la que la cámara almacena y transfiere datos, por lo que esto se resolverá una vez que se haya estudiado la cámara y sus funcionalidades.

5.2- Diagrama de bloques:

22

Hardware: En particular la camara.

Interface: La interfaz es vista como una especificación que existe entre el hardware y el software. Llamando instrucciones de una interfaz, los programas se pueden comunicar con el hardware subyacente. Sobre la interfaz, la funcionalidad del hardware está disponible, pero la realización concreta del hardware es desconocida.

Software: Basado en instrucciones disponibles en la interfaz, un programa es una secuencia estructurada de instrucciones.

6- Requerimientos y restricciones del sistema:

6.1- Procesamiento y memoria:

● 60 KBytes de imagen en flash del nodo● Tamaño del driver de la cámara y código en general en memoria del nodo a determinar.

El nodo cuenta con 512 kB de flash y 32 kB de ROM.

6.2- Tiempo de respuesta(opcional):

A determinar a partir de los perfiles de corriente. Entre los tiempos a determinar se encuentran la toma de la foto desde que llega la orden y el tiempo de transferencia de la imagen a la flash del nodo.

7- Diseño preliminar:

7.1- Diseño de Hardware:

23

● CC2538 ARM Cortex M3-Based● La placa medidora de consumo de corriente consiste en un integrador LTC4150 y un

amplificador de corriente INA139● Interfaz Cámara-Nodo

● Cámara LS-Y201-2MP de LinkSprite y lente M12x0.5 Camera Lens - LS-20150 f=2.8mm.

Todo el Hardware listado anteriormente será heredado del grupo de proyecto de fin de carrera WSNvision. El único hardware adicional será el que se utilice para generar rupturas en los mensajes entre la cámara y el nodo. Esto es descripto entre las pruebas a realizar en la sección de planificación.

7.2- Arquitectura de Software:

● Contiki-OS 2.7 en el entorno de desarrollo Instant Contiki.● La implementación se encuentra a definir en base a lo descripto en el punto 5.1.

8- Planificación:

8.1- Actividades/Tareas:

● Tarea 1:

Nombre: AprendizajeDescripción: Interiorizarse con el funcionamiento de la placa medidora de consumo de corriente diseñada por WSNVisión, su uso e interpretación de los datos que se obtendrán con ella, el CC2538 y la cámara junto con el

24

driver de la misma. Estudio del estándar jpeg para la compresión de imágenes que utiliza la cámara.Duración: 1 semana.

● Tarea 2:

Nombre: Implementar capacidad de excepción a error al driverDescripción: Agregar al driver de la cámara la capacidad de responder a una excepción cuando la cámara no mande bien la imagen entera (pérdida de paquetes y datos corrompidos). Se forzarán los errores de la forma descrita en el punto 8.2. Se iterará entre la programación y las pruebas de errores hasta lograr el manejo de las excepciones.Duración: 2 semanas.

● Tarea 3:

Nombre: Estimación de consumo de corriente de la cámara-Descripción: Obtener una medición del consumo de la cámara al momento de obtener una imagen y transmitirla al nodo hasta que la misma se aloje en flash en función de la resolución de imagen y compresión. También se verificará si el consumo de la cámara cuando la misma no es utilizada es nulo. Dado que el integrador de carga de la placa medidora es para medidas de largo tiempo (días), dicha tarea que parecería corta a primera vista, demandará unos cuantos días de proyecto.Duración: 1 semana.

● Tarea 4:

Nombre: Documentación y presentación final e hitos.Descripción: Realizar la documentación completa del proyecto y diapositivas para la presentación en los hitos y al final del proyecto.Duración: 1 semana.

8.2- Pruebas a realizar:

● Forzar el error de imagen por hardware (colocando resistencia de pull-up en el bus de datos del orden de Mega Ohms o cortocircuitar un pin del nodo al bus de datos a través de una interfaz. La finalidad de ambos métodos es la de corromper el flujo de datos. La

25

elección de uno de los dos o de un tercero se encuentra a determinar) y posteriormente verificar el reenvío y recepción de la imagen de forma correcta.

● A partir de la placa medidora de consumo de corriente y un osciloscopio digital se obtendrá consumo del uso de la cámara, los tiempos del uso de la cámara y consumo en modo de bajo consumo del nodo (estas últimas 2 pruebas son de tipo opcional).

8.3- Hitos intermedios:

● Hito 1: Se habrán realizado para este hito las primeras dos tareas propuestas. Se prevé para esta presentación tener resuelto e implementado cómo se procede ante un error en la transmisión de una imagen.

● Hito 2: Finalización del proyecto. Se prevé llegar con todos los objetivos del proyecto cumplidos.8.4- Cronograma:

11/05 18/05 25/05 01/06 08/06 15/06

● Tarea1 ● Tarea2 ● Tarea2 ● Hito1● Tarea3

● Tarea4 ● Hito2● Defensa

26

9.3. Planificación del Proyecto:A continuación, en la Tabla XX se muestra la planificación inicial del proyecto, donde posteriormente se detallan las tareas respectivas:

11/05 18/05 25/05 01/06 08/06 15/06

● Tarea1 ● Tarea2 ● Tarea2 ● Hito1● Tarea3

● Tarea4 ● Hito2● Defensa

Tabla 02: Planificación inicial del Proyecto

● Tarea 1:

Nombre: AprendizajeDescripción: Interiorizarse con el funcionamiento de la placa medidora de consumo de corriente diseñada por WSNVisión, su uso e interpretación de los datos que se obtendrán con ella, el CC2538 y la cámara junto con el driver de la misma. Estudio del estándar jpeg para la compresión de imágenes que utiliza la cámara.Duración: 1 semana.

● Tarea 2:

Nombre: Implementar capacidad de excepción a error al driverDescripción: Agregar al driver de la cámara la capacidad de responder a una excepción cuando la cámara no mande bien la imagen entera (pérdida de paquetes y datos corrompidos). Se forzarán los errores de la forma descrita en el punto 8.2. Se iterará entre la programación y las pruebas de errores hasta lograr el manejo de las excepciones.

27

Duración: 2 semanas.

● Tarea 3:

Nombre: Estimación de consumo de corriente de la cámara-Descripción: Obtener una medición del consumo de la cámara al momento de obtener una imagen y transmitirla al nodo hasta que la misma se aloje en flash en función de la resolución de imagen y compresión. También se verificará si el consumo de la cámara cuando la misma no es utilizada es nulo. Dado que el integrador de carga de la placa medidora es para medidas de largo tiempo (días), dicha tarea que parecería corta a primera vista, demandará unos cuantos días de proyecto.Duración: 1 semana.

● Tarea 4:

Nombre: Documentación y presentación final e hitos.Descripción: Realizar la documentación completa del proyecto y diapositivas para la presentación en los hitos y al final del proyecto.Duración: 1 semana.

Inicialmente se subestimó mucho el aprendizaje y entendimiento del Driver de la Cámara proporcionado por WSNvisión. El mismo no se encontraba perfectamente comentado, lo cual nos llevo a gastar varias horas en descifrar detalles del código que en otro caso serían triviales. Otro tema que dificulto mucho fue la imposibilidad de “debugging” a la hora de programar. La única posibilidad para leer registros y variables era escribirlas en memoria y leerlas posteriormente. El problema de esto, aparte de ser muy tedioso, es que al realizar una lectura de la flash del nodo a partir del programa Flash Programmer 2 proporcionado por Texas Instruments para utilizar junto con la SmartRF 06 Evaluation Board, la misma ocasionaba un reset sobre el nodo. Lo anteriormente descrito, se refiere a las Tareas 1 y 2, por lo que el tiempo real invertido en ellas fue mayor al planificado.

25/05 18/05 25/05 01/06 08/06 15/06 22/06 29/06

Tarea1 Tarea1 Tarea2 Hito1 Tarea2 Tarea 2 Defensa Entrega

28

Tarea2 Tarea3 Tarea 3Tarea 4

Tarea 4 Documentación

Tabla 03: Cronograma real final del Proyecto

La Tabla XX muestra lo que fue el desarrollo real de las tareas al finalizar el proyecto. Se estimaron aproximadamente 40 horas invertidas en el proyecto por persona, por lo que mas allá de cierta desviación en la planificación inicial comparada con la real, se cumplieron los objetivos y se invirtió aproximadamente el tiempo justo para lo que era el Proyecto de Sistemas Embebidos.

29