12.10. Conclusión#

Una cámara conectada a un cable USB que transmite fotogramas a un programa anfitrión, acepta actualizaciones de configuración de vuelta desde el anfitrión y sobrevive a desconexiones y reconexiones sin perder la sincronización – con retransmisiones ocultas, múltiples flujos lógicos compartiendo un puerto y cero código de tramado en la aplicación – sale de unas cuarenta líneas de código del lado de la cámara y una cantidad similar en el anfitrión. La biblioteca del protocolo convierte una tubería de bytes en una superficie de canales programable y mantiene invisible todo lo que está por debajo de la aplicación.

12.10.1. Lo que construyó el capítulo#

  • Un modelo mental de cuatro capas de la pila: transporte, tramado, fiabilidad, canales. Cada capa resuelve un problema e ignora todo lo que está por encima.

  • El formato de paquete sobre el cable – cabecera de 10 bytes con CRC, carga útil variable, CRC final. Lo bastante pequeño como para recorrerlo byte a byte.

  • El protocolo de enlace (handshake) que ejecutan la cámara y el anfitrión cuando se conecta un transporte: PROTO_SYNC, intercambio de capacidades, descubrimiento de canales.

  • La maquinaria de fiabilidad por encima: números de secuencia, ACK, NAK, retransmisiones con retroceso exponencial, los diez códigos de estado.

  • El modelo de canales: hasta 32 flujos lógicos con nombre sobre un mismo cable, con stdin / stdout / stream / profile integrados y canales de aplicación registrados por clase de Python.

  • La interfaz de backend – size, read, write, poll, lock / unlock, shape, ioctl, flush, is_active – y cómo la biblioteca del protocolo usa los métodos presentes en un backend para decidir qué admite el canal.

  • El lado del anfitrión: la clase Camera del SDK openmv-python, la velocidad mágica de 921600 baudios que conmuta USB-CDC al modo protocolo, y el patrón de ida y vuelta channel_size / channel_read / channel_write.

  • Un patrón de transmisión de fotogramas – captura en búfer único, readp con un latch, send_event para notificaciones de nuevo fotograma – y un patrón de configuración bidireccional (canal escribible por el anfitrión, ida y vuelta de JSON) que juntos forman la base de toda herramienta de cámara interactiva.

12.10.2. Hoja de ruta de referencia#

Las páginas de referencia de la biblioteca son los destinos de consulta cuando una de estas características aparece en código real:

  • protocol — Canales del protocolo OpenMV – el módulo protocol, protocol.init(), protocol.register(), ProtocolChannel, las constantes de banderas de canal y la tabla de carga útil máxima por cámara.

  • El SDK del anfitrión – pip install openmv, openmv.camera.Camera. Métodos tratados en este capítulo: update_channels(), has_channel(), channel_size(), channel_read(), channel_write(), poll_events(), read_frame(), exec() y stop().

  • El repositorio openmv-projects – herramientas reales construidas sobre la biblioteca del protocolo. El directorio tools/ incluye thermal-overlay-calibration (interfaz gráfica de alineación de RGB + térmico), ccm-tuning (ajustador de la matriz de corrección de color), genx320-event-streaming y genx320-overlay-calibration (herramientas para cámaras de eventos). Cada una usa los patrones de este capítulo de principio a fin.

12.10.3. Hacia dónde llevarlo a continuación#

Algunas direcciones hacia las que avanzan los proyectos de cámara a partir de aquí:

  • Construir una interfaz gráfica de anfitrión. Un canal de fotogramas alimentando un widget de vídeo, uno o dos canales de configuración alimentando deslizadores y botones. Para la propia capa de interfaz gráfica, DearPyGui es la opción natural – puro Python, instalable con pip, lo bastante rápido para una vista previa en vivo, y lo primero a lo que recurre toda herramienta de anfitrión OpenMV existente.

  • Panel de telemetría multicanal. Varios canales de aplicación en la misma cámara (lecturas de sensores, contadores, eventos de estado) refrescados cada uno en su propio callback, y una interfaz gráfica de anfitrión que los lee con un temporizador y renderiza cada uno por separado. El control de flujo independiente de la capa de canales significa que una lectura lenta no bloquea a las demás.

  • Ajuste remoto por UART. Los mismos callbacks de canal; la aplicación llama a protocol.init para cambiar de USB a un transporte UART. La cámara sigue funcionando sin pantalla y un script de Python en una Raspberry Pi o un portátil habla con ella por una línea serie para el ajuste en campo.

El formato sobre el cable, la capa de fiabilidad y la abstracción de canales no cambian. Elegir el transporte que encaje con el despliegue y añadir un canal por cada cosa que el anfitrión necesite ver o establecer es todo el trabajo de ingeniería de aquí en adelante.