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.