Visione artificiale industriale: quattro telecamere via Ethernet con Microchip e NVIDIA

Aggiungere la visione artificiale a una macchina industriale significa costruire una catena affidabile tra ciò che accade sul pezzo e la decisione del sistema di controllo. Le immagini devono mostrare il dettaglio giusto, arrivare in tempo, essere elaborate e rimanere associate al componente corretto. Quando le telecamere diventano due, quattro o più, collegamenti, sincronizzazione e gestione dei dati assumono un peso decisivo quanto quello dell’algoritmo di riconoscimento.

Una novità dagli Stati Uniti rende questo tema particolarmente attuale. L’11 agosto 2026, a Chandler, in Arizona, Microchip ha annunciato la revisione 2.0 del PolarFire FPGA Ethernet Sensor Bridge: una scheda per collegare sensori e telecamere alle piattaforme di elaborazione NVIDIA attraverso Ethernet, utilizzando la tecnologia Holoscan Sensor Bridge.

Il produttore dichiara il supporto fino a quattro telecamere, un ingombro ridotto del 60% rispetto alla prima generazione e un prezzo inferiore. L’interesse per chi costruisce macchine riguarda soprattutto la possibilità di valutare una catena di acquisizione con più telecamere, sulla quale sviluppare controllo qualità, verifica degli assemblaggi e funzioni di visione per la robotica.

Per un’azienda, il punto di partenza è concreto: quale controllo vorremmo automatizzare e quali immagini servono per eseguirlo alla velocità della nostra macchina? Gli scenari e i calcoli proposti in questo articolo sono esempi di valutazione progettuale; le caratteristiche dei prodotti sono ricavate dalle fonti ufficiali collegate.

Cosa cambia con il PolarFire Ethernet Sensor Bridge Rev 2.0

La scheda prodotto MPF200-ETH-SENSOR-BRIDGE-R2 descrive una piattaforma basata su FPGA PolarFire MPF200T, con un adattatore per le telecamere e interfacce di espansione. Questa configurazione permette di separare l’acquisizione dei segnali dal computer che li elabora, mantenendo un collegamento Ethernet tra le due parti.

Il comunicato di lancio segnala anche circuiti per la misura ottica della latenza e la disponibilità di materiale di progetto. Per il team di sviluppo, questi strumenti possono rendere più rapido l’avvio di una valutazione sul banco. Le prestazioni dell’intera macchina restano da misurare nella configurazione applicativa.

Dalle telecamere all’AI: come funziona l’architettura

La documentazione NVIDIA descrive un percorso nel quale l’FPGA acquisisce i dati dei sensori e li invia al sistema host tramite UDP su Ethernet. Il software riceve i flussi e li inserisce nella catena di elaborazione Holoscan, che può comprendere conversione delle immagini, preelaborazione, inferenza e visualizzazione.

telecamere → acquisizione su FPGA → Ethernet → elaborazione NVIDIA → risultato di visione → controllo macchina

Le responsabilità vanno definite per ogni passaggio. Il bridge deve trasferire dati utilizzabili; il software di visione deve produrre un risultato; l’interfaccia verso il controllore deve indicare a quale pezzo appartiene quel risultato e se è ancora valido. La progettazione dell’applicazione collega questi elementi, compresi i casi in cui una lettura manca o arriva tardi.

Il tipo di ricezione dipende dall’host. NVIDIA documenta configurazioni accelerate con interfacce ConnectX capaci di scrivere i dati direttamente nella memoria della GPU, e configurazioni basate sui socket Linux, come quelle del Jetson AGX Orin Developer Kit senza una scheda di rete RDMA. Occorre quindi verificare la combinazione completa di computer, interfaccia di rete e software, anziché estendere le prestazioni di una configurazione a tutte le altre.

Perché più telecamere cambiano il progetto di una macchina

Consideriamo una stazione che deve controllare un componente assemblato. Una vista dall’alto può mostrare la presenza delle parti principali; una vista laterale può aiutare a verificare un inserimento; un’altra inquadratura può leggere un’etichetta. La distribuzione dei controlli tra telecamere può essere utile quando un unico punto di osservazione lascia zone nascoste o non offre abbastanza dettaglio.

Aumentano però le informazioni da coordinare. Il software deve sapere se le immagini appartengono allo stesso pezzo, quale ricetta di controllo applicare e come combinare gli esiti. Se una telecamera restituisce una lettura valida e un’altra non riesce ad acquisire, occorre gestire uno stato incompleto. Trattarlo come un prodotto automaticamente conforme creerebbe un errore nel processo.

In una valutazione tecnica conviene perciò disegnare prima la sequenza di ispezione: ingresso del pezzo, identificazione, acquisizioni, elaborazione, decisione e conferma dell’azione. Questa sequenza chiarisce anche se servano davvero quattro viste, due telecamere ben posizionate o una diversa disposizione del pezzo.

Dimensionare la banda video prima di scegliere la piattaforma

Per un flusso non compresso, una prima stima del volume dei soli pixel si ottiene moltiplicando numero delle telecamere, risoluzione, fotogrammi al secondo e bit per pixel effettivamente trasportati. Il risultato permette di individuare subito configurazioni che richiedono più capacità di quella disponibile.

banda dei pixel = numero telecamere × larghezza × altezza × fotogrammi/s × bit/pixel

Questi valori sono calcoli illustrativi, non benchmark della scheda. Per dimensionare il collegamento vanno aggiunti intestazioni, metadati, eventuali riempimenti del formato e margine. Conta anche dove avviene la conversione: un dato Bayer a 8 bit per pixel inviato sulla rete può diventare un’immagine RGB a tre canali nel computer, con un diverso impegno di memoria.

L’ultima configurazione supera già 10 Gbit/s per i soli pixel. La presenza di due porte richiede comunque di verificare come il progetto distribuisce le sorgenti e come l’host riceve i flussi. Dal numero di connettori non si può dedurre una capacità utilizzabile senza vincoli.

Per contenere il traffico si può valutare l’acquisizione della sola regione utile o un numero di immagini coerente con il controllo. Anche queste scelte devono preservare il dettaglio del difetto e la copertura temporale richiesta. Ridurre la risoluzione indiscriminatamente rischia di eliminare proprio l’informazione che l’algoritmo deve riconoscere.

Latenza, sincronizzazione e tempo utile per decidere

La banda indica quanti dati possono passare; la latenza indica quanto tempo trascorre tra un evento osservato e il risultato disponibile. Una linea può richiedere entrambi: gestire numerosi pezzi consecutivi e consegnare ogni esito prima che il relativo componente raggiunga il punto di selezione.

La guida NVIDIA alla misura della latenza distingue il trasferimento del fotogramma al bridge, la ricezione sul computer e le fasi successive di elaborazione. I metadati comprendono numeri di frame e riferimenti temporali utili a osservare questi passaggi. I tempi riportati negli esempi si riferiscono a configurazioni specifiche.

Nel progetto industriale occorre aggiungere anche l’esposizione della telecamera, la preparazione dei dati per il modello e lo scambio dell’esito con il controllore. Alcune fasi possono sovrapporsi: il tempo complessivo va misurato sul percorso reale. È utile rilevare distribuzione dei ritardi, picchi osservati e decisioni oltre la scadenza, oltre al valore medio.

Il requisito utile è consegnare al controllore un esito valido, riferito al pezzo corretto, entro il tempo disponibile nel processo.

La sincronizzazione richiede una verifica distinta. La nota applicativa PTP di NVIDIA descrive l’allineamento temporale dei bridge e la generazione di segnali di sincronismo per le telecamere. Per allineare le esposizioni servono però sensori, collegamenti e logica configurati a questo scopo. La compatibilità va accertata sulla specifica catena di acquisizione.

In un sistema con oggetti in movimento, questo controllo aiuta a evitare che viste raccolte in momenti diversi vengano interpretate come simultanee. Se le telecamere ispezionano stazioni successive, può invece essere più importante la corretta associazione delle immagini all’identificativo del pezzo.

La qualità dell’immagine comincia da ottica e illuminazione

Prima di scegliere la potenza di calcolo bisogna verificare che il difetto sia visibile. Una superficie riflettente, un bordo in ombra o un pezzo mosso durante l’esposizione possono rendere instabile il controllo già nella fase di acquisizione.

La documentazione tecnica Basler sulla qualità delle immagini ricorda che aumentare il tempo di esposizione migliora la luminosità, ma può aumentare il mosso e ridurre la frequenza di acquisizione. Aumentare il guadagno amplifica anche il rumore. Sono compromessi da affrontare insieme alla scelta della luce e dell’obiettivo.

Per una prima prova conviene usare pezzi reali, compresi quelli con difetti difficili da distinguere, e riprodurre distanza, orientamento e velocità della macchina. Il dettaglio minimo da riconoscere deve occupare un numero di pixel adeguato alla tecnica scelta. Se il controllo dipende da dimensioni o posizione, occorre inoltre valutare calibrazione e stabilità del montaggio.

Un criterio pratico è verificare quanto cambia l’immagine tra lotti, turni e normali variazioni di processo. Questa prova aiuta a individuare interventi sull’acquisizione prima di investire nello sviluppo del modello.

Quando usare l’AI e quando valutare algoritmi di visione classica

La piattaforma di acquisizione può essere utile anche per elaborazioni che non richiedono una rete neurale. Presenza di un foro, allineamento di un bordo o lettura di un codice possono essere affrontati inizialmente con strumenti di visione classica, se le condizioni ottiche permettono risultati sufficientemente stabili.

Per difetti con forme variabili o classificazioni difficili da descrivere con regole, un modello AI è un’opzione da confrontare sperimentalmente. Il confronto dovrebbe usare gli stessi campioni e gli stessi obiettivi: difetti mancati, pezzi conformi scartati, tempi di elaborazione e casi che richiedono una verifica umana.

Nel proof of concept conviene riservare alla verifica finale immagini di pezzi e lotti diversi da quelli usati per costruire la soluzione. L’obiettivo è capire come il sistema affronti variazioni reali, oltre alle immagini già incontrate durante lo sviluppo.

Come confrontare il bridge con altre soluzioni di visione

L’annuncio Microchip aggiunge un’opzione a un insieme di architetture già disponibili. Nel confronto va considerato anche GigE Vision, che definisce un’interfaccia per il trasferimento delle immagini e l’interoperabilità tra prodotti di visione su Ethernet. Utilizzare lo stesso mezzo di trasporto non rende automaticamente equivalenti le interfacce applicative.

Questa è una griglia di scelta progettuale. Vanno confrontati anche costo complessivo, spazio, cablaggio, dissipazione e lavoro di manutenzione. Una soluzione più flessibile può essere vantaggiosa se quella flessibilità serve al prodotto; altrimenti un sottosistema di visione già completo può ridurre l’impegno di integrazione.

Software: le verifiche da fare prima di avviare il prototipo

La nota applicativa ufficiale Microchip contiene esempi per streaming video, elaborazione e uso di più telecamere. Offre quindi un punto di partenza per provare l’acquisizione prima di sviluppare la funzione specifica della macchina.

Alla verifica del 7 settembre 2026, la stessa documentazione segnala che la revisione R2 non è ancora supportata nel repository NVIDIA per Holoscan Sensor Bridge SDK 2.7.0 e rimanda temporaneamente a un ramo software dedicato. Questo dettaglio va considerato nella preparazione del banco di prova e nella scelta delle versioni da mantenere.

Per rendere ripetibile lo sviluppo conviene registrare revisione della scheda, configurazione FPGA caricata, sensori, driver e pacchetti software utilizzati. Un aggiornamento va verificato sulla catena completa: immagini ricevute, riconoscimento, tempi e comunicazione con il controllore.

Serve inoltre progettare il comportamento in caso di interruzione del flusso, riavvio di una periferica o saturazione delle code. L’applicazione dovrebbe distinguere un pezzo non conforme da una misura non disponibile. Questa distinzione rende più chiara la diagnosi e permette al controllo macchina di applicare la gestione prevista per ciascun caso.

Un esempio progettuale: controllo di assemblaggio su una linea

Immaginiamo una linea che trasporta piccoli gruppi meccanici. L’azienda vuole verificare la presenza di una guarnizione, l’inserimento di un connettore e la corretta etichetta. È uno scenario illustrativo, sul quale impostare requisiti e misure.

Quattro punti di osservazione possono essere una prima ipotesi: tre dedicati ai controlli e uno alla visione complessiva del pezzo. Durante la prova si potrebbe scoprire che bastano meno telecamere, oppure che una delle verifiche richiede un’ottica diversa. Il bridge è una possibile base per questa valutazione.

Assumiamo un nastro a velocità costante di 2 m/s e una distanza di 20 cm tra il punto di osservazione e quello di espulsione. Il tempo di percorrenza è 100 ms. Se ipotizziamo 30 ms per la risposta dell’attuatore e riserviamo 20 ms di margine, restano 50 ms per acquisizione, elaborazione e consegna del comando.

tempo disponibile per visione e comunicazione = (0,20 m ÷ 2 m/s) − 30 ms − 20 ms = 50 ms

Questi numeri definiscono un requisito ipotetico; il banco di prova deve stabilire se la configurazione scelta lo rispetti. È necessario verificare anche la cadenza dei pezzi: più componenti possono trovarsi contemporaneamente tra la stazione di ripresa e quella di espulsione.

L’interfaccia verso il PLC può associare a ogni controllo un identificativo, un esito, uno stato di validità e un riferimento temporale. Se un risultato arriva oltre la scadenza, non deve essere applicato al componente successivo. Anche il comportamento in caso di lettura incompleta va concordato con chi gestisce il processo.

Una dashboard può raccogliere frequenza dei difetti, immagini selezionate e motivi delle letture non valide. La scelta di cosa conservare dipende dall’utilità per qualità e assistenza: salvare ogni flusso video continuo richiede un dimensionamento diverso rispetto a registrare esiti e campioni rappresentativi.

Dal proof of concept a una funzione utilizzabile in produzione

Una valutazione efficace produce elementi per decidere. Prima delle prove vanno definiti controlli richiesti, campioni disponibili, velocità della linea e criteri di accettazione. Successivamente si raccolgono immagini, si confrontano le opzioni di elaborazione e si misura l’esecuzione sull’hardware scelto.

requisito di ispezione → immagini rappresentative → scelta dell’architettura → prototipo → misure sulla linea → integrazione nel prodotto

Il risultato dovrebbe comprendere almeno l’architettura proposta, gli esiti sui campioni, i tempi osservati, le condizioni che rendono una lettura non valida e il lavoro ancora necessario. Prove continuative aiutano poi a valutare temperatura, stabilità e recupero dopo le interruzioni previste.

Per l’azienda, questi dati permettono di confrontare l’investimento con obiettivi concreti: ridurre controlli manuali, intercettare determinati errori prima delle lavorazioni successive o migliorare la tracciabilità. Eventuali benefici economici devono essere stimati usando volumi, costi e risultati del processo reale.

Domande frequenti sulla visione industriale con Microchip e NVIDIA

La scheda Microchip esegue direttamente il riconoscimento AI?

Nella catena qui descritta, il bridge acquisisce e trasporta i dati verso il sistema NVIDIA. Il modello di riconoscimento viene eseguito sulla piattaforma di elaborazione collegata. Acquisizione e inferenza sono quindi due parti del progetto da dimensionare insieme.

Quattro ingressi garantiscono quattro telecamere 4K a 60 fps?

No. Il funzionamento contemporaneo dipende da formato dei pixel, configurazione dei sensori, progetto FPGA, distribuzione dei flussi e capacità dell’host. I calcoli di banda riportati nell’articolo mostrano perché il numero degli ingressi, da solo, non descriva la prestazione complessiva.

È necessaria una connessione cloud per controllare i pezzi?

Il percorso di elaborazione può essere progettato per funzionare localmente sulla macchina. L’eventuale invio di risultati a un server, la gestione remota e l’archiviazione sono funzioni ulteriori, da definire secondo le esigenze operative.

Si può collegare qualsiasi telecamera MIPI CSI-2?

La scelta richiede verifiche su collegamenti elettrici, alimentazione, formato dei dati e software di configurazione. Il supporto di uno specifico sensore va accertato nel progetto FPGA e nella catena software adottata.

È utilizzabile per aggiornare una macchina già esistente?

Può essere valutato in un progetto di retrofit. Occorre verificare spazio per le riprese, illuminazione, alimentazione, cablaggio e scambio dei risultati con il controllore. Una prova con i pezzi reali chiarisce la fattibilità prima dell’integrazione definitiva.

Da cosa dipende il costo di una prima valutazione?

Dal controllo richiesto, dalla disponibilità dei campioni e dall’impegno per acquisizione e integrazione. Difetto da riconoscere, dimensioni del pezzo, velocità e hardware esistente sono le informazioni più utili per definire un’attività circoscritta e una stima motivata.

Come Silicon LogiX può supportare la valutazione

Silicon LogiX può affiancare aziende e team tecnici nella definizione di una funzione di visione embedded, partendo dal problema da risolvere e dai vincoli della macchina. L’attività iniziale può includere l’analisi delle immagini disponibili, il confronto delle architetture e la definizione di un proof of concept misurabile.

Il lavoro può proseguire con AI e machine learning on-device, integrazione su Linux embedded, logica FPGA e firmware embedded per le funzioni di acquisizione e comunicazione. Software di diagnostica, HMI e dashboard possono completare il sistema quando servono a operatori e assistenza.

La piattaforma Microchip-NVIDIA è una delle opzioni da esaminare. La proposta tecnica deve motivare la scelta rispetto a dati, tempi, disponibilità hardware e impegno di sviluppo, indicando cosa è già dimostrato e quali aspetti richiedono ulteriori prove.

Conclusione

Il nuovo bridge Microchip offre un punto di partenza concreto per valutare acquisizione da più telecamere ed elaborazione su piattaforme NVIDIA. Per un costruttore di macchine, l’opportunità è sviluppare una funzione di ispezione coerente con il proprio processo, sfruttando una base hardware e software documentata.

La qualità del risultato dipende dall’intera catena: dettaglio visibile, immagini correttamente associate, trasporto dimensionato, riconoscimento verificato e decisione consegnata in tempo. Portare questi requisiti sul banco di prova permette di trasformare una novità tecnologica in una scelta motivata per il prodotto.

Riferimenti ufficiali

1. Microchip, annuncio del PolarFire Ethernet Sensor Bridge Rev 2.0, 11 agosto 2026.
2. Microchip, scheda tecnica della piattaforma MPF200-ETH-SENSOR-BRIDGE-R2.
3. Microchip, progetto di riferimento e nota applicativa per telecamere MIPI, incluse le indicazioni sul supporto software della revisione R2.
4. NVIDIA, introduzione a Holoscan Sensor Bridge: acquisizione, trasporto e requisiti dell’host.
5. NVIDIA, misura della latenza in Holoscan Sensor Bridge.
6. NVIDIA, nota applicativa PTP e sincronizzazione delle telecamere.
7. Basler, ottimizzazione della qualità delle immagini: esposizione, guadagno e movimento.
8. Association for Advancing Automation, GigE Vision: interfacce di visione e interoperabilità su Ethernet.