Visión por eventos o fotogramas: comparación

¿Qué es la visión basada en fotogramas?

La visión basada en cuadros captura la escena como imágenes completas a intervalos regulares, por ejemplo 30, 60 o 120 cuadros por segundo. Cada cuadro contiene información espacial densa, lo que hace que las cámaras convencionales sean ideales para el reconocimiento de objetos, el análisis de color, la inspección, el mapeo y el gran ecosistema de software construido alrededor de tensores de imágenes.

La desventaja es que cada fotograma mueve una imagen completa a través del proceso, independientemente de que la escena haya cambiado o no. Para un ciclo de decisión rápido, el tiempo de exposición, el período de fotograma, la lectura del sensor, el transporte, la conversión de imágenes y la inferencia contribuyen a la latencia de un extremo a otro. Una velocidad de fotogramas alta reduce el intervalo de muestreo, pero normalmente aumenta el ancho de banda, el tráfico de memoria, la energía y la carga térmica.

¿Qué es la visión basada en eventos?

La visión basada en eventos utiliza un sensor de imagen basado en eventos cuyos píxeles responden de forma asincrónica a los cambios de brillo. En lugar de entregar una imagen rectangular con una cadencia fija, el sensor produce un flujo que contiene coordenadas de píxeles, polaridad y marcas de tiempo precisas. Por lo tanto, las regiones estáticas generan pocos o ningún dato, mientras que los bordes en movimiento pueden producir eventos con una resolución temporal muy fina.

Esta representación es útil cuando la sincronización del movimiento es más importante que recibir repetidamente una imagen completa. Puede admitir seguimiento de baja latencia, robótica de alta velocidad y transiciones de iluminación difíciles, pero el flujo de eventos no es una fotografía normal. Los algoritmos, las herramientas de visualización, registro y validación deben diseñarse en torno al modelo de datos.

Cómo un sensor de imagen basado en eventos cambia la ruta de los datos

Un sistema de referencia útil expone el camino completo desde la adquisición del sensor, pasando por el filtrado y el procesamiento, hasta la salida de la aplicación. Instrumente esos límites para que las reclamaciones de latencia y velocidad de datos puedan evaluarse de un extremo a otro.

La diferencia arquitectónica clave no es simplemente "una cámara más rápida versus una cámara más lenta". Un proceso de visión convencional a menudo comienza con un búfer de imagen completo. Una canalización basada en eventos puede comenzar a procesar eventos individuales o pequeñas ventanas de eventos tan pronto como llegan. Esto permite que el filtrado, la alineación de la marca de tiempo, la lógica de la región de interés y las funciones de movimiento se ejecuten cerca del sensor sin esperar un fotograma completo.

Sin embargo, los datos de eventos pueden volverse densos en escenas con mucha textura o bajo vibraciones y parpadeos. Por lo tanto, el diseño del sistema debe medir la tasa de eventos en el peor de los casos, la utilización de la interfaz y el ancho de banda de la memoria en lugar de asumir que la detección de eventos siempre significa un ancho de banda bajo.

Visión basada en eventos versus visión basada en fotogramas

Latencia: mida el sensor hasta la decisión, no un componente

Las cámaras de eventos a menudo se seleccionan para una percepción de baja latencia, pero la resolución de la marca de tiempo del sensor no es la misma que la latencia de la aplicación. Una métrica de ingeniería útil es el tiempo transcurrido desde un cambio en el mundo real hasta la decisión que aparece en la interfaz del sistema. Esa ruta incluye respuesta del sensor, transporte, almacenamiento en búfer, preprocesamiento, inferencia o seguimiento, programación de software y comunicación de salida.

La misma regla se aplica a una cámara de marco. Una canalización de alta velocidad de fotogramas bien diseñada con rutas de memoria directas puede superar a una canalización de eventos mal integrada. Por lo tanto, la arquitectura debe compararse con movimiento, iluminación y algoritmos representativos.

Consideraciones sobre el SDK y el software de visión basado en eventos

Una pila de software de visión basada en eventos normalmente necesita configuración del dispositivo, decodificación de eventos, manejo de marcas de tiempo, filtrado, visualización, grabación y reproducción. Un SDK de visión basado en eventos útil también debería facilitar la sincronización de activadores externos y otros sensores, inspeccionar las tasas de eventos y reproducir una secuencia capturada durante el desarrollo del algoritmo.

Para los sistemas de producción, el software debe ir más allá de un SDK de escritorio. Los equipos deben definir cómo se mueven los eventos a los recursos FPGA, MCU, MPU o NPU; cómo se almacena la calibración; cómo se sincroniza el tiempo; y cómo se pueden reproducir los registros de campo. Si un algoritmo convierte eventos en fotogramas acumulados, la ventana de acumulación se convierte en una compensación explícita entre latencia e información.

Dónde es útil la visión basada en eventos

Las aplicaciones típicas de visión basada en eventos incluyen seguimiento de objetivos a alta velocidad, manipulación robótica, flujo óptico, análisis de vibración o movimiento, inspección industrial rápida y percepción autónoma en escenas con grandes cambios de brillo. Los casos de uso más sólidos suelen ser aquellos en los que una estructura temporal fina mejora directamente la decisión en lugar de simplemente reemplazar una cámara convencional.

Visión basada en eventos para defensa y plataformas autónomas.

En defensa, seguridad y sistemas autónomos, la detección de eventos puede ser relevante para señales de movimiento rápido, experimentos de seguimiento, cargas útiles ópticas de baja latencia e investigación de fusión de sensores. El sistema aún tiene que satisfacer requisitos de plataforma como sincronización, interfaces deterministas, diseño ambiental, grabación, ciberseguridad y validación. La detección de eventos es un componente de la cadena de la misión, no una solución de percepción completa en sí misma.

Cuando la arquitectura de una cámara híbrida es mejor

Muchos sistemas prácticos se benefician de la combinación de modalidades. Los marcos pueden proporcionar contexto semántico e imágenes legibles por humanos, mientras que los eventos contribuyen con detalles temporales. Los sensores térmicos, inerciales o de alcance pueden añadir robustez. Fusion es especialmente útil cuando la aplicación necesita "¿qué es?" y "¿exactamente cuándo y cómo se movió?"

Para los sistemas híbridos, el tiempo compartido es fundamental. Se deben considerar los activadores de hardware, los dominios de marca de tiempo y la calibración antes de finalizar los algoritmos.

Una arquitectura práctica de referencia de visión basada en eventos.

Un sistema de referencia puede colocar filtrado determinista y trabajo de marca de tiempo en una FPGA, inferencia de IA en una NPU o acelerador, servicios de aplicaciones en una MPU y supervisión en una MCU o núcleo en tiempo real. La partición correcta depende de la tasa de eventos, la arquitectura del modelo, el ancho de banda de la memoria y las interfaces externas. Nuestro Guía de IA de borde FPGA, NPU y MPU explica esta partición con más detalle.

Lista de verificación de selección

• Defina la latencia máxima aceptable entre el sensor y la decisión.
• Mida la velocidad de movimiento esperada, el alcance de la iluminación y la actividad de la escena en el peor de los casos.
• Decida si se requiere intensidad de imagen absoluta, color o vídeo legible por humanos.
• Calcule el ancho de banda y el movimiento de la memoria para las escenas típicas y del peor de los casos.
• Confirme la madurez del SDK de visión basada en eventos, conjuntos de datos y algoritmos.
• Planifica la sincronización con fuentes de disparo fotograma, térmicas, inerciales o externas.
• Realice una evaluación comparativa de toda la tubería antes de congelar el diseño informático, portador y térmico.