Desarrollo de un sistema de transmisión de vídeo con módulos Wifi

Menéndez Blanco, Pablo (2016). Desarrollo de un sistema de transmisión de vídeo con módulos Wifi. Proyecto Fin de Carrera / Trabajo Fin de Grado, E.T.S.I. Industriales (UPM).

Descripción

Título: Desarrollo de un sistema de transmisión de vídeo con módulos Wifi
Autor/es:
  • Menéndez Blanco, Pablo
Director/es:
  • Moreno González, Felix Antonio
Tipo de Documento: Proyecto Fin de Carrera/Grado
Grado: Grado en Ingeniería en Tecnologías Industriales
Fecha: Septiembre 2016
Materias:
Palabras Clave Informales: Arduino, Matlab, Android, Wifi, Nodemcu, ESP8266, cámara OV7670, servidor, PHP, JSON, captura de imágenes
Escuela: E.T.S.I. Industriales (UPM)
Departamento: Automática, Ingeniería Eléctrica y Electrónica e Informática Industrial
Licencias Creative Commons: Reconocimiento - Sin obra derivada - No comercial

Texto completo

[img]
Vista Previa
PDF (Document Portable Format) - Se necesita un visor de ficheros PDF, como GSview, Xpdf o Adobe Acrobat Reader
Descargar (3MB) | Vista Previa

Resumen

El objetivo principal de este Trabajo Fin de Grado ha sido desarrollar un sistema capaz de adquirir imágenes de una cámara de vídeo y enviarlas por Wifi a un dispositivo receptor para posteriormente procesarlas y mostrarlas al usuario. En esencia, se han utilizado dos módulos: la cámara OV7670, que extrae la información de los píxeles mediante 8 bits, y el Nodemcu esp-12e, una placa de programación con Wifi incorporado. Estos han sido elegidos por varios motivos: bajo coste, bajo consumo, tamaño reducido y fácil programación. Como objetivo secundario, se han analizado las capacidades y limitaciones de este sistema de transmisión de imágenes. Las imágenes se envían sin comprimir a un servidor. Específicamente, se ha conseguido recibir y mostrar las imágenes en el ordenador con Matlab y en el móvil con una aplicación desarrollada en Android Studio. Para empezar este proyecto, se estudiaron en profundidad ambos módulos y se detectaron problemas y necesidades: 1) La placa se programaría mediante el entorno de desarrollo de Arduino, para lo cual se descargó la librería necesaria. Sin embargo, las funciones de Arduino digitalRead() y digitalWrite() podrían ralentizar el programa al utilizar instrucciones de más. Por ello se investigó y se consiguió poder leer y escribir en los registros de las entradas de la placa, acelerando así el programa. 2) Haría falta una señal de reloj que introducir a la cámara para hacerla funcionar. La opción con la que se obtuvieron mejores resultados fue el oscilador de Pierce, que es un circuito compuesto básicamente de: un cristal de cuarzo, un inversor, un par de condensadores y un par de resistencias, una de ellas funciona como filtro de paso bajo y evita sobreoscilaciones. El cristal de cuarzo elegido fue uno de 10MHz, por lo que el circuito también oscila a la misma frecuencia, habiendo ajustado la resistencia mencionada para evitar sobreoscilaciones. Posteriormente, todos los componentes se soldaron en una placa perforada para tener un circuito con todo fijo y que no hubiera problemas por falta de contacto entre componentes. El resultado es una onda casi cuadrada de 10MHz y bastante estable. El pin del oscilador por el que sale esta onda se conecta a la señal XCLK de la cámara, para proporcionarle la señal de reloj que necesita. 3) Haría falta programar los registros de la cámara para configurar ésta, lo cual se debía hacer mediante comunicación SCCB (semejante a la comunicación I2C) a través de dos entradas de la cámara llamadas SIO_C (señal de reloj de la comunicación) y SIO_D (canal de datos de la comunicación). Se estudió el funcionamiento de este tipo de comunicación y, afortunadamente, se encontró un código que funcionó perfectamente. Por si acaso se decidió analizar en el osciloscopio las señales que producía este código, para entender bien su funcionamiento y poder hacer modificaciones si hacía falta. 4) La placa probablemente no tendría suficientes pines para leer todas las salidas de la cámara. Se planteó cuántos pines harían falta y, efectivamente, se necesitaban 4 más de los disponibles. Se probó un DAC (convertidor digital-analógico), para convertir varias señales digitales de la cámara en una señal analógica que leer con el pin analógico de la placa. Pero finalmente esta opción fue descartada debido al tiempo que requiere la función analogRead() de Arduino y a que este pin no era posible leerlo mediante registros. Se decidió entonces utilizar los pines disponibles de la placa para leer las entradas más importantes de la cámara: - VSYNC: señal de salida que indica cuándo acaba una imagen y empieza a salir información de la siguiente. - HREF: señal de salida que indica cuando empieza a salir información de cada línea. - PCLK: señal de salida que indica cuándo sale información de cada píxel (esta iría también a 10MHz si no se prescala). - Bits D de información 7 a 4 (los más significativos, de un total de 8). - SIO_C y SIO_D: entradas para configurar la cámara mediante la ya mencionada comunicación SCCB. 5) También sería necesario poder enviar grandes paquetes de información por Wifi, para después poder descargar dicha información en el móvil. La mejor opción fue el envío de la información a un servidor (concretamente el dominio creado www.esp8266.netai.net alojado en el servidor www.000webhost.com). El programa de la placa hacía un POST (una petición de envío de información) a un archivo .php, programado para guardar la información en un archivo .json, el cual, al almacenar la información con una determinada estructura, permitía que cualquier herramienta que solicitara la información de dicho archivo, pudiera descargarla y ordenarla mediante librerías existentes en internet. Como herramientas para la descarga de dicha información se probaron Matlab y Android, ambas verdaderamente útiles para la visualización de imágenes. La información obtenida de los bits de la cámara se almacena en una matriz de 100x200 bytes, ya que se desea almacenar una imagen de 100x100 píxeles y cada píxel estaba compuesto por 2 bytes de información. Una vez el programa ha obtenido la información deseada de la imagen, realiza un POST al archivo savepixelsYCr.php, enviándole la información (codificada en hexadecimal) de 2 en 2 líneas de la imagen, por lo que dicho archivo .php almacena todas las líneas repartidas en 50 archivos .json. Para acelerar la posterior descarga de la información, se ordena al servidor, mediante otro POST al archivo joinlines.php, que junte la información de esos 50 archivos .json en un solo archivo .json, creando así el archivo imageYCr001.json. La siguiente vez creará el archivo imageYCr002.json, y así sucesivamente. Para obtener dicha información con Matlab, se utiliza la función urlread() y la librería JSON.m (descargada de internet) para analizar la estructura de los mencionados archivos .json. Una vez descodificada la información y obtenidos los colores en el formato YCbCr, estos se convierten a RGB y se almacenan en una matriz de 100x100x3, correspondiendo las dos primeras dimensiones al tamaño de la imagen y la tercera dimensión al color R, G o B. Dicha matriz de colores se muestra por pantalla mediante la función imshow(). Para obtener la información con Android, se ha diseñado una aplicación en Android Studio, en la que, mediante tareas asíncronas para no bloquear el hilo principal del programa, se realiza la obtención de la información del mismo modo que antes, excepto que se usan funciones propias de java y la librería JSON que ya incorpora Android. Además, los colores se guardan en una variable de tipo Bitmap, a la cual se puede asignar un color a cada píxel. El bitmap se muestra por pantalla mediante un imageView, componente visual que nos permite mostrar imágenes en la aplicación. Para líneas futuras se deben investigar: - Placas de desarrollo más veloces. - Métodos más rápidos de envío, almacenamiento y descarga de la información. La mayoría de problemas encontrados se han debido a la velocidad de funcionamiento de la placa. Este problema se agrava al programar en el entorno de desarrollo de Arduino, al no poder saber qué instrucciones ejecuta el programa cuando salta a la rutina de servicio de la interrupción. Se hubiera deseado poder realizar partes del programa o incluso el programa entero en un entorno en el que se pudieran ver las instrucciones resultantes tras la compilación o incluso se pudieran programar las interrupciones en ensamblador, para tener un mayor control del proceso y saber qué cambiar para hacer el programa más rápido y eficaz.

Más información

ID de Registro: 43935
Identificador DC: http://oa.upm.es/43935/
Identificador OAI: oai:oa.upm.es:43935
Depositado por: Biblioteca ETSI Industriales
Depositado el: 19 Nov 2016 17:18
Ultima Modificación: 19 Nov 2016 17:18
  • Open Access
  • Open Access
  • Sherpa-Romeo
    Compruebe si la revista anglosajona en la que ha publicado un artículo permite también su publicación en abierto.
  • Dulcinea
    Compruebe si la revista española en la que ha publicado un artículo permite también su publicación en abierto.
  • Recolecta
  • e-ciencia
  • Observatorio I+D+i UPM
  • OpenCourseWare UPM