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.