Cos’è la visione basata su frame?
La visione basata su fotogrammi cattura la scena come immagini complete a intervalli regolari, ad esempio fotogrammi 30, 60 o 120 al secondo. Ogni fotogramma contiene dense informazioni spaziali, che rendono le telecamere convenzionali una soluzione naturale per il riconoscimento di oggetti, l'analisi del colore, l'ispezione, la mappatura e il grande ecosistema software costruito attorno ai tensori di immagine.
Il compromesso è che ogni fotogramma sposta un'immagine completa attraverso la pipeline indipendentemente dal fatto che la scena sia cambiata o meno. Per un ciclo decisionale rapido, il tempo di esposizione, il periodo del fotogramma, la lettura del sensore, il trasporto, la conversione delle immagini e l'inferenza contribuiscono tutti alla latenza end-to-end. Un frame rate elevato riduce l'intervallo di campionamento, ma solitamente aumenta la larghezza di banda, il traffico di memoria, la potenza e il carico termico.
Cos’è la visione basata sugli eventi?
La visione basata sugli eventi utilizza un sensore di immagine basato sugli eventi i cui pixel rispondono in modo asincrono ai cambiamenti di luminosità. Invece di fornire un'immagine rettangolare a una cadenza fissa, il sensore produce un flusso contenente coordinate di pixel, polarità e timestamp precisi. Le regioni statiche quindi generano pochi o nessun dato, mentre i bordi in movimento possono produrre eventi con una risoluzione temporale molto fine.
Questa rappresentazione è utile quando la tempistica del movimento è più importante della ricezione ripetuta di un'immagine completa. Può supportare il tracciamento a bassa latenza, la robotica ad alta velocità e le transizioni di illuminazione difficili, ma il flusso degli eventi non è una fotografia normale. Gli algoritmi, gli strumenti di visualizzazione, registrazione e validazione devono essere progettati attorno al modello dati.
Come un sensore di immagine basato sugli eventi modifica il percorso dei dati
Un utile sistema di riferimento espone il percorso completo dall'acquisizione del sensore attraverso il filtraggio e l'elaborazione fino all'output dell'applicazione. Strumentalizza questi confini in modo che le richieste di latenza e velocità dei dati possano essere valutate end-to-end.
La differenza architetturale chiave non è semplicemente “fotocamera più veloce rispetto a fotocamera più lenta”. Una pipeline di visione convenzionale spesso inizia con un buffer di immagini completo. Una pipeline basata su eventi può iniziare a elaborare singoli eventi o piccole finestre di eventi non appena arrivano. Ciò consente il filtraggio, l'allineamento del timestamp, la logica della regione di interesse e le funzionalità di movimento di funzionare vicino al sensore senza attendere un fotogramma completo.
Tuttavia, i dati degli eventi possono diventare densi in scene altamente strutturate o soggette a vibrazioni e sfarfallio. La progettazione del sistema dovrebbe quindi misurare la frequenza degli eventi nel caso peggiore, l'utilizzo dell'interfaccia e la larghezza di banda della memoria anziché presumere che il rilevamento degli eventi significhi sempre una larghezza di banda ridotta.
Visione basata sugli eventi vs visione basata sui frame
| Dimensione | Visione basata su frame | Visione basata sugli eventi |
|---|---|---|
| Uscita del sensore | Immagini dense a intervalli fissi | Eventi asincroni di cambiamento di luminosità |
| Informazioni sull'ora | Limitato dall'esposizione e dalla cadenza dei fotogrammi | Timestamp precisi associati a singoli eventi |
| Dati statici della scena | Continuano ad arrivare fotogrammi completi | Poca attività da regioni invariate |
| Contesto spaziale/cromatico | Forte; intensità dell'immagine assoluta e imaging a colori maturi | Indiretto; il flusso di eventi descrive i cambiamenti piuttosto che un'immagine convenzionale |
| Movimento ad alta velocità | Richiede un'esposizione e un frame rate adeguati | Ben si adatta ai rapidi cambiamenti temporali |
| Ecosistema software | CV molto maturo e strumenti di deep learning | Algoritmi, rappresentazioni e set di dati più specializzati |
| La migliore vestibilità | Imaging generale, riconoscimento, consistenza e immagini leggibili dall'uomo | Dinamica veloce, caratteristiche temporali e percezione del movimento a bassa latenza |
Latenza: misura dal sensore alla decisione, non da un componente
Le telecamere per eventi vengono spesso selezionate per la percezione a bassa latenza, ma la risoluzione del timestamp del sensore non è la stessa della latenza dell'applicazione. Una metrica ingegneristica utile è il tempo che intercorre tra un cambiamento nel mondo reale e la decisione che appare sull'interfaccia del sistema. Tale percorso include la risposta del sensore, il trasporto, il buffering, la preelaborazione, l'inferenza o il tracciamento, la pianificazione del software e la comunicazione dell'output.
La stessa regola vale per una fotocamera frame. Una pipeline con frame rate elevato ben progettata con percorsi di memoria diretti può sovraperformare una pipeline di eventi scarsamente integrata. L’architettura dovrebbe quindi essere confrontata con movimento, illuminazione e algoritmi rappresentativi.
Software di visione basato sugli eventi e considerazioni su SDK
Uno stack software di visione basato sugli eventi richiede in genere la configurazione del dispositivo, la decodifica degli eventi, la gestione del timestamp, il filtraggio, la visualizzazione, la registrazione e la riproduzione. Un’utile visione basata sugli eventi SDK dovrebbe anche facilitare la sincronizzazione di trigger esterni e altri sensori, ispezionare la frequenza degli eventi e riprodurre una sequenza catturata durante lo sviluppo dell’algoritmo.
Per i sistemi di produzione, il software deve estendersi oltre il desktop SDK. I team dovrebbero definire come gli eventi vengono spostati nelle risorse FPGA, MCU, MPU o NPU; come viene memorizzata la calibrazione; come viene sincronizzato il tempo; e come riprodurre i registri sul campo. Se un algoritmo converte gli eventi in frame accumulati, la finestra di accumulo diventa un esplicito compromesso tra latenza e informazioni.
Dove la visione basata sugli eventi è utile
Le tipiche applicazioni di visione basate sugli eventi includono il tracciamento di target ad alta velocità, la manipolazione robotica, l'analisi del flusso ottico, delle vibrazioni o del movimento, l'ispezione industriale rapida e la percezione autonoma in scene con grandi cambiamenti di luminosità. I casi d’uso più efficaci sono solitamente quelli in cui la struttura temporale precisa migliora direttamente la decisione anziché limitarsi a sostituire una fotocamera convenzionale.
Visione basata sugli eventi per la difesa e piattaforme autonome
Nella difesa, nella sicurezza e nei sistemi autonomi, il rilevamento degli eventi può essere rilevante per segnali di movimento rapido, esperimenti di tracciamento, carichi utili ottici a bassa latenza e ricerca sulla fusione dei sensori. Il sistema deve ancora soddisfare i requisiti della piattaforma quali sincronizzazione, interfacce deterministiche, progettazione ambientale, registrazione, sicurezza informatica e convalida. Il rilevamento degli eventi è una componente della catena della missione, non una soluzione completa di percezione di per sé.
Quando un'architettura di fotocamera ibrida è migliore
Molti sistemi pratici traggono vantaggio dalla combinazione delle modalità. I frame possono fornire contesto semantico e immagini leggibili dall'uomo mentre gli eventi contribuiscono con dettagli temporali. I sensori termici, inerziali o di misurazione possono aggiungere robustezza. Fusion è particolarmente utile quando l'applicazione necessita sia di "che cos'è?" e "esattamente quando e come si è mosso?"
Per i sistemi ibridi, il tempo condiviso è essenziale. Trigger hardware, domini di timestamp e calibrazione dovrebbero essere considerati prima di finalizzare gli algoritmi.
Un'architettura pratica di riferimento per la visione basata sugli eventi
Un sistema di riferimento può posizionare attività di filtraggio deterministico e timestamp in uno FPGA, inferenza AI su uno NPU o acceleratore, servizi applicativi su uno MPU e supervisione su uno MCU o core in tempo reale. La partizione corretta dipende dalla frequenza degli eventi, dall'architettura del modello, dalla larghezza di banda della memoria e dalle interfacce esterne. Il nostro Guida FPGA vs NPU vs MPU Edge AI spiega questo partizionamento in modo più dettagliato.
Lista di controllo della selezione
- Definire la latenza massima accettabile dal sensore alla decisione.
- Misura la velocità di movimento prevista, la portata dell'illuminazione e l'attività della scena nel caso peggiore.
- Decidi se è necessaria l'intensità assoluta dell'immagine, il colore o il video leggibile dall'uomo.
- Stima la larghezza di banda e il movimento della memoria sia per le scene tipiche che per quelle peggiori.
- Conferma della maturità dell'algoritmo, del set di dati e della visione basata sugli eventi SDK.
- Pianifica la sincronizzazione con fonti di trigger frame, termiche, inerziali o esterne.
- Confronta l'intera pipeline prima di congelare calcolo, baseboard e progettazione termica.
Scegli l'osservazione di cui l'applicazione ha bisogno
| Domanda di candidatura | Approccio da valutare prima | Cosa testare |
|---|---|---|
| L'etichetta stampata o il colore sono corretti? | Immagini basate su fotogrammi | Risoluzione, illuminazione, esposizione e accuratezza dell'ispezione |
| Quando un bordo in rapido movimento ha attraversato una regione? | Rilevamento basato sugli eventi | Qualità del timing, attività della scena, falsi eventi e ritardo completo dell'uscita |
| Quale oggetto è presente e con quanta precisione si muove? | Un frame ibrido e una pipeline di eventi | Calibrazione, tempo condiviso, rappresentazione e beneficio della fusione |
| Il sistema funzionerà con cambiamenti di luce o vibrazioni? | Entrambi i candidati alle stesse condizioni rappresentative | Precisione dell'applicazione, frequenza degli eventi o qualità dei frame e utilizzo delle risorse |
Utilizza la stessa attività e scena quando confronti i candidati. Una visualizzazione nitida non è di per sé un risultato del rilevamento e un numero elevato di eventi non è prova di informazioni utili. Concordare la metrica di output prima di registrare il confronto.
Un modo pratico per costruire il budget di latenza
A 60 fotogrammi al secondo, l'intervallo dei fotogrammi è di circa 16.7 ms. In un modello semplificato in cui il cambio di scena avviene in modo uniforme tra campioni istantanei, l'attesa media per il campione successivo è di circa 8.3 ms. L'esposizione, la lettura, il trasporto e l'elaborazione sono effetti aggiuntivi. Questa aritmetica descrive un intervallo di campionamento; non è una latenza misurata della fotocamera.
Una pipeline di eventi presenta anche scelte di progettazione che aggiungono ritardo. Se un'applicazione attende la chiusura di una finestra di eventi 5 ms prima dell'elaborazione, un evento vicino all'inizio di quella finestra può attendere quasi 5 ms solo in quella fase. I timestamp precisi del sensore non rimuovono tale scelta di buffering. Utilizzare questi esempi per identificare le fasi che vale la pena misurare, non per rivendicare un vantaggio fisso per entrambi i sensori.
| Confine | Conduttura del telaio | Conduttura degli eventi |
|---|---|---|
| Osservazione | Esposizione e timing del campione | Risposta al cambiamento di luminosità e generazione di timestamp |
| Trasporti | Buffer di lettura, collegamento e host | Buffer di codifica degli eventi, collegamento e decodifica |
| Preparazione | Conversione delle immagini, ridimensionamento e preparazione del tensore | Filtraggio, finestre temporali e costruzione della rappresentazione |
| Decisione | Algoritmo e pianificazione dell'output | Algoritmo e pianificazione dell'output |
Misurare l'età dell'output con una relazione valida tra l'orologio di osservazione e l'orologio dei risultati. Un timestamp software al termine di una chiamata di lettura della fotocamera non rappresenta necessariamente il tempo di esposizione. Allo stesso modo, un timestamp preciso di un evento può appartenere a un orologio non ancora allineato con l'host.
Progetta un confronto che un altro ingegnere possa riprodurre
- Definire l'attività, il movimento del target, la portata dell'illuminazione e l'output richiesto prima di selezionare le impostazioni.
- Ottica del documento, campo visivo, impostazioni del sensore, versioni del software e calibrazione.
- Registra condizioni rappresentative, comprese scene difficili come sfarfallio o vibrazioni, ove pertinente.
- Valuta insieme l'accuratezza dell'attività, il ritardo nell'output, la velocità dei dati e il carico di elaborazione sostenuto.
- Conserva le registrazioni e i file di configurazione in modo che le modifiche dell'algoritmo possano essere confrontate sugli stessi input.
Per la fase realizzativa, il ns software della fotocamera per eventi e guida SDK copre la rappresentazione, la registrazione e la distribuzione dei dati. Usa il guida alla sincronizzazione dell'ora quando si combinano le modalità.
Quale fotocamera dovresti valutare per l'ispezione di qualità?
Inizia con il difetto che devi osservare. Un componente mancante, un'etichetta stampata o un segno sulla superficie possono essere adatti all'imaging del telaio convenzionale con ottica e illuminazione controllate. Quando il segnale importante è il movimento veloce o la tempistica precisa di un cambiamento, valutare il rilevamento degli eventi rispetto allo stesso compito.
Annotare la più piccola caratteristica rilevante, la velocità dell'oggetto, il campo visivo, la variazione di illuminazione e il tempo decisionale disponibile. Mantenere nella valutazione la normale variazione della produzione: lotti, turni, finiture superficiali e posizioni delle parti diversi. Confronta i difetti mancati, i falsi scarti e la velocità di elaborazione.
Il rilevamento degli eventi è un candidato da testare, non un requisito per ogni sistema di ispezione. Vedi il nostro soluzione di visione industriale e controllo qualità per l'integrazione da telecamera a macchina e la pianificazione pilota.
Domande frequenti sulla visione basata sugli eventi
Cos’è la visione basata sugli eventi?
La visione basata sugli eventi è un approccio di rilevamento in cui i pixel segnalano i cambiamenti di luminosità locale in modo asincrono invece di attendere un fotogramma completo dell'immagine. Ogni evento in genere porta le coordinate dei pixel, la polarità e un timestamp, consentendo alle informazioni relative al movimento di raggiungere la pipeline di elaborazione con una risoluzione temporale precisa.
Qual è la differenza tra visione basata su eventi e visione basata su frame?
La visione basata su frame acquisisce immagini complete a intervalli fissi, mentre la visione basata su eventi segnala i cambiamenti man mano che si verificano. Le fotocamere frame forniscono un contesto spaziale e cromatico denso; i sensori di eventi possono ridurre i dati ridondanti della scena statica e migliorare i tempi per il movimento rapido. L'architettura migliore dipende dall'attività, dall'illuminazione, dallo stack software e dalla latenza decisionale richiesta.
Quale software o SDK è necessario per la visione basata sugli eventi?
Il software di visione basato sugli eventi deve gestire flussi di eventi asincroni anziché solo tensori di immagini convenzionali. Un pratico SDK dovrebbe supportare la configurazione del sensore, il filtraggio degli eventi, la gestione del timestamp, la visualizzazione, la registrazione, la riproduzione, la calibrazione, la sincronizzazione e la conversione in rappresentazioni richieste dal tracciamento o dalle pipeline della rete neurale.
Dove viene utilizzata la visione basata sugli eventi?
Le tipiche applicazioni di visione basate sugli eventi includono la robotica ad alta velocità, il tracciamento del movimento, i sistemi autonomi, il monitoraggio e il rilevamento industriale in cui i rapidi cambiamenti della scena o l'illuminazione difficile rendono importante il tempismo. Può anche integrare le telecamere convenzionali nei sistemi di percezione ibridi.
Come può essere utilizzata la visione basata sugli eventi nelle piattaforme di difesa?
Per le piattaforme di difesa e autonome, i sensori di eventi possono supportare segnali di movimento, tracciamento e percezione a bassa latenza in condizioni di elevata gamma dinamica o movimento rapido. Un sistema implementabile richiede ancora timestamp deterministico, interfacce robuste, fusione di sensori sincronizzati, software convalidato e un’attenta misurazione dei tassi di eventi peggiori.
Un sensore di immagine basato su eventi ha sempre una larghezza di banda inferiore?
No. Le scene statiche possono generare pochi dati, ma vibrazioni, sfarfallio o movimenti altamente strutturati possono creare flussi di eventi densi. La progettazione dell'interfaccia e della memoria dovrebbe pertanto utilizzare tassi di eventi misurati nel caso peggiore anziché presupporre che il rilevamento degli eventi abbia sempre una larghezza di banda ridotta.
Riferimenti tecnici
- Gallego et al.: Visione basata sugli eventi: un sondaggio
- Profeesee: streaming di eventi e accesso in finestra
Gli esempi di tempistica sono calcoli illustrativi. Le dichiarazioni di latenza e rilevamento a livello di prodotto richiedono misurazioni dell'implementazione completa.
Valuta la visione basata sugli eventi sul tuo ciclo decisionale effettivo.
Condividi il target, il profilo di movimento, le interfacce, l'ambiente e la quantità del pilota. Possiamo mappare i requisiti in un sensore, FPGA e un'architettura di calcolo locale.