¿Cómo reducir la velocidad de datos? (Módulo de cámara OV7670 + AL422B (FIFO))

Compré este módulo: Módulo de cámara OV7670 + AL422B(FIFO) y quiero enviar el video en vivo de la cámara por este NRF24L01 pero tengo varias preguntas.

  • ¿Es adecuado el módulo RF (NRF24L01) para este trabajo?

  • Creo que la velocidad de datos del NRF24L01 no es suficiente para la cámara. ¿cual es tu opinion?

  • Si está de acuerdo conmigo, en su opinión, ¿cómo puedo resolver este problema? (En otras palabras, ¿puedo reducir el tamaño de los datos de la cámara (video)?)

Debo enviar el video por NRF24L01 por 1Mbps o más. además, estoy usando STM32F103RET6 para este trabajo.

¿Tiene un requisito de resolución específico? Dudo que pueda mantener un video "en vivo", pero podría transferir cuadros a una cierta velocidad (más probable que sea inferior a 30 fps).
Pruebe el intercambio de pilas/producción de audio y video y pregúnteles cómo comprimir una salida de video adecuada para la transmisión. Cuáles son los requisitos de hardware. ¡Avísame también! avp.stackexchange.com/questions
@GustavoLitovsky No, creo que 24 fps es adecuado.
@Roh: 24 fps es poco probable. ¿Qué tipo de resolución de imagen necesitas?
@GustavoLitovsky no lo sé exactamente, pero puedo decir que quiero mostrar el video en una pantalla LCD N96 (2,8").
No importa 2.8", ¿qué resolución es?
Entonces, desea escalar la imagen a 320x240 o recortar una sección de la misma, o ambas cosas (suponiendo que no puede configurar la cámara para generar una imagen reducida). Hacer eso en el extremo de la cámara (antes de la transmisión) reduce la tasa de datos masivamente y le da mucho menos trabajo a todo lo demás.
@Roh, ¿qué has decidido? Estoy exactamente con los mismos módulos (ov7670 + nrf24l01) y trato de hacer lo mismo pero con un PIC MCU en su lugar. Estoy pensando en comprimir la imagen de N en N líneas (limitación de RAM). ¿Tienes alguna solución para esta tarea?
@ user2110874 ¡Desafortunadamente no! Creo que tenemos que elegir una MCU más rápida (o tal vez DSP) con una RAM más grande y un módulo más rápido. no parece de ninguna manera (triste)
Estoy pensando en esto: microchip.com/wwwproducts/Devices.aspx?dDocName=en559066 Una SRAM de 1 Mbit para colocar los marcos para que una MCU pueda comprimir los datos y luego enviarlos a través de nrf24l01. Dado que la velocidad de datos del módulo no es tan rápida, creo que cualquier MCU de 40 MIPS puede funcionar (es solo una suposición). Luego, en lugar de una imagen de 600k, tendremos algo alrededor de 40k (formato jpeg).
@ user2110874 De todos modos, creo que 40MIPS es bajo. tal vez 120 sea adecuado porque no puede hacer otro trabajo (finalmente solo puede enviar el video). ¡No está mal para un cuadricóptero! :-)
Es exactamente lo que estoy usando también (cuadricóptero). Pero aún así, tal vez un 40 MIPS dedicado solo para compresión esté bien, ¿no crees? Porque creo que realmente no necesita comprimir a la misma velocidad que la velocidad máxima de salida de datos de la cámara. La verdadera limitación del sistema será el nrf24l01. Tal vez en una tasa de 3 ~ 5 fps debería ser posible. Depende de si esta tasa de fps está bien para ti...

Respuestas (1)

Suponiendo que pueda mantener la tasa de datos máxima para el nRF24L01 ( 2 megabits por segundo ), eso significa que puede moverse, en un mundo perfecto, 200 kilobytes por segundo (suponiendo que no haya sobrecarga).

Entonces, dado esto, y su mínimo deseado de 24 fps, puede calcular cuántos bytes necesita que tenga cada imagen: 200K / 24 = 8.53Kpor cuadro

Ahora no has dicho que resolución quieres, pero la resolución máxima del ov7670 es de 640x480, y usa 16bits por píxel (es un poco más complicado que eso, invito a los curiosos a leer la Hoja de Datos ) .

Como todas nuestras calculadoras conocen 640 * 480 * 2 = 614,400Bytes: 72 veces más que 8.53K por cuadro. De hecho, tomaría aproximadamente 3 segundos por cuadro (6 segundos si se ejecuta a 1 Mbps).

Entonces, para responder a sus dos primeras preguntas: el nRF24L01 no está a la altura de la tarea de transmitir video en vivo de 640x480.

Esto nos deja con su tercera pregunta: ¿ Cómo se reduce el tamaño de los datos de las cámaras?

Hay ( no mutuamente excluyentes) tres formas de hacer esto:

  1. Comprimir las imágenes
  2. Comprimir los datos
  3. Enviar imágenes más pequeñas

Desglosemos cada uno de estos:

Comprimir las imágenes

Podría, por ejemplo, enviar las imágenes como un flujo M-JPEG. Esto ciertamente facilitaría mucho la decodificación de las imágenes en el lado del teléfono y reduciría bastante el tamaño de las imágenes enviadas.

Pero hay un problema: debe poder mantener la imagen completa en la memoria para poder realizar la compresión JPEG (y, por lo tanto, M-JPEG). Su ST32F103RET6 tiene 64K de RAM (IIRC), por lo que no hay forma de que quepa. Y no estoy seguro de un esquema de compresión con pérdida que pueda usar que no necesite toda la imagen a la vez.

Comprimir los datos

Ahora hay una serie de opciones que podría hacer aquí: Huffman, codificación de longitud de ejecución, LWZ, etc. Desafortunadamente, ninguno de estos producirá una cantidad predecible de compresión. Va a depender de las imágenes que envíes.

Pero creo que es seguro decir que no obtendrá los 8.53K que necesitaría para 24 fps.

Enviar imágenes más pequeñas

El OV7670 es bastante flexible cuando se trata de resoluciones. Así que echemos un vistazo a algunas otras resoluciones que podrías usar:

  • QVGA (320x240): 320 * 240 * 2 = 150Kpor fotograma. A este ritmo podrías enviar algo más de 1 fps
  • QQVGA (160x120): 160 * 120 * 2 = 37Kpor cuadro. Este es el primer tamaño de imagen que puede almacenar completamente en RAM
  • QQQVGA (80x60): 80 * 60 * 2 = 9.38Kpor cuadro. Con compresión, debería poder hacer videos de 24 fps
  • QQQQVGA (40x30): `40 * 30 * 2 = 2,35 K por cuadro. ¡En este (sello de correos) de un tamaño que podría vaporizar a 30 fps 1 mbps! Creo que esta es la resolución más baja que admite la cámara.

QQVGA puede ser posible si realiza una compresión JPEG con mucha pérdida y, a continuación, también comprime un poco el flujo de datos. Vas a tener que experimentar para estar seguro.

una posdata

Será difícil encontrar una tecnología inalámbrica más rápida que el nRF24L01 (y sus similares), sin tener que recurrir a wifi (por ejemplo, el módulo Adafruit CC3000 ). Con eso, un microcontrolador con MUCHA RAM y compresión, debería poder transmitir 24-30 fps.

Alternativamente, hay chips de controlador de cámara que hacen la compresión JPEG por usted, por ejemplo, el vc0706. Con eso conectado a una cámara, y usando el enlace SPI de vc0706, debería poder usar incluso un microcontrolador trivial para transmitir los datos.

Todavía tengo que conocer un módulo de cámara con vc0706 que expone los pines SPI, todos son seriales. Uno puede existir, pero no lo he encontrado todavía. Entonces, si sigues esta ruta, es posible que tengas que hacerlo tú mismo...

He estado trabajando MUCHO con nRF recientemente. No hay forma de que te acerques a los 2 Mbps. Unos pocos cientos de kbps es probablemente lo mejor que podría esperar, y eso sería con todos los mecanismos de retransmisión automáticos desactivados.
¿Qué nRF has estado usando? Hay tres rangos de operación, diferentes tipos de antena y luego la distancia. La velocidad y el rendimiento son el factor de múltiples variables. Pero elegí 2Mbps porque era el máximo teórico y, por lo tanto, lo mejor que podría obtener para mostrar cuán pequeño debe ser cada cuadro incluso entonces. Las escalas matemáticas para que pueda simplemente ajustar los números para diferentes velocidades
"Pero hay un problema: debe poder mantener toda la imagen en la memoria para poder comprimir JPEG (y, por lo tanto, M-JPEG). Su ST32F103RET6 tiene 64 K de RAM (IIRC), por lo que no hay forma de que sea va a encajar Y no estoy seguro de un esquema de compresión con pérdida que pueda usar que no necesite toda la imagen a la vez ". Quizás pueda comprimir la imagen a JPEG usando este microcontrolador con RAM limitada usando jpegant. Está diseñado para compresión JPEG en MCU: sourceforge.net/projects/jpegant
@ John3348 El problema es que necesitaría una fuente de imagen direccionable de píxeles, porque la codificación de JPEG requiere que pueda tener el marco completo en la memoria o puede obtener píxeles arbitrarios; ya que utiliza un patrón de escaneo en zigzag. La cámara en cuestión proporciona un flujo de bits lineal, por lo que tendría que mantener el cuadro en la memoria. PNG puede comprimir un flujo de bits lineal, pero al no tener pérdidas no podría llegar a los 37K por cuadro necesarios para 30FPS en todas las situaciones
@ John3348 También un examen rápido de jpegant muestra que, si bien es bastante eficiente con la memoria, requiere acceso al original completo