12.10. Riepilogo#

Una camera collegata a un cavo USB che trasmette frame a un programma host, accetta aggiornamenti di configurazione di ritorno dall’host e sopravvive a scollegamenti/ricollegamenti senza perdere la sincronizzazione – con le ritrasmissioni nascoste, piu flussi logici che condividono una sola porta e zero codice di framing nell’applicazione – nasce da una quarantina di righe di codice lato camera e una quantita simile lato host. La libreria del protocollo trasforma una pipe di byte in una superficie di canali programmabile e mantiene invisibile tutto cio che sta sotto l’applicazione.

12.10.1. Cosa ha costruito il capitolo#

  • Un modello mentale a quattro livelli dello stack: trasporto, framing, affidabilita, canali. Ogni livello risolve un solo problema e ignora tutto cio che sta sopra.

  • Il formato del pacchetto sul filo – intestazione di 10 byte con CRC, payload variabile, CRC finale. Abbastanza piccolo da poterlo esaminare byte per byte.

  • L’handshake che camera e host eseguono quando un trasporto si connette: PROTO_SYNC, scambio delle capacita, scoperta dei canali.

  • Il meccanismo di affidabilita sovrastante: numeri di sequenza, ACK, NAK, ritrasmissioni con backoff esponenziale, i dieci codici di stato.

  • Il modello dei canali: fino a 32 flussi logici denominati su un solo filo, con i canali incorporati stdin / stdout / stream / profile e i canali applicativi registrati tramite classe Python.

  • L’interfaccia di backend – size, read, write, poll, lock / unlock, shape, ioctl, flush, is_active – e come la libreria del protocollo usa i metodi presenti su un backend per decidere cosa il canale supporta.

  • Il lato host: la classe Camera dell’SDK openmv-python, la velocita magica di 921600 baud che commuta la USB-CDC in modalita protocollo, e lo schema di round-trip channel_size / channel_read / channel_write.

  • Uno schema di streaming dei frame – acquisizione a buffer singolo, readp con un latch, send_event per le notifiche di nuovo frame – e uno schema di configurazione bidirezionale (canale scrivibile dall’host, round-trip JSON) che insieme formano la base di ogni strumento camera interattivo.

12.10.2. Mappa di riferimento#

Le pagine di riferimento della libreria sono le destinazioni da consultare quando una di queste funzionalita compare nel codice reale:

  • protocol — Canali del protocollo OpenMV – il modulo protocol, protocol.init(), protocol.register(), ProtocolChannel, le costanti dei flag dei canali e la tabella del payload massimo per camera.

  • L’SDK host – pip install openmv, openmv.camera.Camera. Metodi trattati in questo capitolo: update_channels(), has_channel(), channel_size(), channel_read(), channel_write(), poll_events(), read_frame(), exec() e stop().

  • Il repository openmv-projects – strumenti reali costruiti sulla libreria del protocollo. La directory tools/ include thermal-overlay-calibration (GUI per l’allineamento RGB + termico), ccm-tuning (regolatore della matrice di correzione del colore), genx320-event-streaming e genx320-overlay-calibration (strumentazione per camere a eventi). Ciascuno usa gli schemi di questo capitolo dall’inizio alla fine.

12.10.3. Dove andare poi#

Alcune direzioni in cui i progetti con camera si muovono da qui:

  • Costruire una GUI host. Un canale per i frame che alimenta un widget video, uno o due canali di configurazione che alimentano slider e pulsanti. Per il livello GUI vero e proprio, DearPyGui e la scelta naturale – puro Python, installabile via pip, abbastanza veloce per l’anteprima dal vivo, ed e cio a cui ricorre per primo ogni strumento host OpenMV esistente.

  • Dashboard di telemetria multicanale. Diversi canali applicativi sulla stessa camera (letture dei sensori, contatori, eventi di stato) ciascuno aggiornato nella propria callback, e una GUI host che li legge su un timer e ne rappresenta ciascuno separatamente. Il controllo di flusso indipendente del livello dei canali fa si che una lettura lenta non blocchi le altre.

  • Regolazione remota su UART. Le stesse callback dei canali; l’applicazione chiama protocol.init per passare da USB a un trasporto UART. La camera continua a funzionare senza interfaccia e uno script Python su un Raspberry Pi o un laptop comunica con essa su una linea seriale per la regolazione sul campo.

Il formato sul filo, il livello di affidabilita e l’astrazione dei canali non cambiano. Scegliere il trasporto adatto al deployment e aggiungere un canale per ogni cosa che l’host deve vedere o impostare e l’intero lavoro di ingegneria da qui in avanti.