Mitä tapahtumapohjainen visioohjelmisto käsittelee?

Tapahtumakamera raportoi kirkkauden muutoksista sen sijaan, että se toimittaisi tavanomaisen videokuvan joka väliajoin. Dekoodattu tapahtuma tyypillisesti tunnistaa pikselin, napaisuuden ja aikaleiman. Sovelluksesi on säilytettävä näiden kenttien merkitys hankinnan, suodatuksen, tallennuksen ja päättelyn avulla. The tapahtumapohjainen vs. kehyspohjainen vertailu selittää, milloin tietomalli on hyödyllinen.

Erottele suunnittelussa kolme muotoa: anturi- tai siirtokoodaus, ohjelmiston käyttämä dekoodattu tapahtumaesitys ja algoritmille välitetty esitys. Raaka-anturipaketteja sisältävä tiedosto, joukko purettuja tapahtumia ja kertynyt kuva palvelevat eri tarkoituksia. Muuntaminen niiden välillä voi muuttaa muistin käyttöä, prosessointikustannuksia ja loppupäässä saatavilla olevia ajoitustietoja.

EdustusHyödyllinenIntegraatiokysymys
Raakapaketit tai toimittajan tallenneToistaa hankinta- ja dekoodauskäyttäytymistäVoiko käytössä oleva dekooderi lukea tarkalleen tämän laite- ja muotoversion?
Dekoodatut tapahtumatSuodatus, ajoitusanalyysi ja tapahtumakohtaiset algoritmitMitkä ovat aikaleimayksikkö, kelloalue ja koordinaattisopimus?
Aikapinnat tai vokselimaiset tensoritAlgoritmit, jotka tarvitsevat strukturoidun ajallisen esityksenMitkä historia-, binning- ja normalisointiasetukset on toistettava?
Kerätyt tapahtumakuvatVisualisointi tai yhteensopiva kuvapohjainen käsittelyvaiheKuinka paljon viivettä ja tiedon menetystä kerääntymisikkuna aiheuttaa?

Tapahtumakameran SDK arvioiminen

Aloita tarkasta anturista, kameran laiteohjelmistosta ja isäntäalustasta. Työpöytäesittely ei tue upotettua Linux-kuvaa, ARM-prosessoria tai tuotantolisenssiäsi. Kysy toimittajalta tuetut käyttöjärjestelmät, CPU-arkkitehtuurit, jakeluehdot ja kameran käyttöliittymävaatimukset. Tarkista sovellus aiotulla alustalla ennen kantajakortti:n käyttöönottoa.

  • Hankinta: laitteen etsintä, konfigurointi, dekoodaus ja virheraportointi.
  • Ajoitus: aikaleiman alkuperä, rollover-käsittely, ulkoiset liipaisimet ja usean laitteen kohdistus.
  • Toistettavuus: tallenteet, konfiguraatiovienti ja tunnistettu ohjelmistoversio.
  • Käyttöönotto: päätön toiminta, tuetut binaarit, uudelleenkäynnistyskäyttäytyminen ja lisenssiehdot.
  • Havaittavuus: tapahtumamäärät, jonon syvyys, pudonneet tiedot ja isäntäresurssien käyttö.

Rakenna putki, jossa on selkeät ajoitusrajat

HankiDekoodaa ja säilytä anturin aika
ValmistauduSuodata, synkronoi ja muotoile ikkunoita
PäätäSeuraa tai päättele ja leimaa tulosteen aikaleima

Pidä hankinta erillään kalliista visualisoinnista, levyn kirjoittamisesta ja mallin päättelystä. Muuten hidas kuluttaja voi viivyttää uutta dataa ennen kuin algoritmi edes käynnistyy. Määritä rajoitettu jono ja eksplisiittinen ylikuormituskäytäntö. Vanhimman ikkunan pudottamisella, kiinnostavan alueen pienentämisellä ja virheellä pysähtymisellä on erilaisia ​​seurauksia; valitse sovellukselle sopiva toiminta ja kirjaa, kun se tapahtuu.

Käytä anturin aikaleimoja kuvaamaan, milloin havainnot tapahtuivat, ja monotonista isäntäkelloa mittaamaan käsittelyn kestoja. Aikaleimojen vähentäminen asiaankuulumattomista kelloista ei tuota kelvollista päästä päähän -latenssia. Jos kamera on yhdistettävä IMU-kameraan tai perinteiseen kameraan, määritä kellosuhde ja kalibrointiprosessi, joka on kuvattu anturin ja fuusion synkronointiopas.

Pieni tallennus-tarkastusesimerkki

Seuraava Python-esimerkki laskee tuetun tallenteen dekoodatut tapahtumat ja raportoi niiden aikaleimien keston. Se käyttää dokumentoitua Metavision-suoratoistoa API ja vaatii yhteensopivan SDK-asennuksen ja -nauhoituksen. Se on tarkastusesimerkki, ei ALVEXIS-kameran benchmark tai ilmaisin.

import argparse
from metavision_sdk_stream import Camera, CameraStreamSlicer

parser = argparse.ArgumentParser()
parser.add_argument("recording")
args = parser.parse_args()
source = Camera.from_file(args.recording)
count, first_us, last_us = 0, None, None

for batch in CameraStreamSlicer(source.move()):
    events = batch.events
    if events.size:
        start = int(events["t"][0])
        end = int(events["t"][-1])
        first_us = start if first_us is None else min(first_us, start)
        last_us = end if last_us is None else max(last_us, end)
        count += int(events.size)

span_s = 0.0 if first_us is None else (last_us - first_us) / 1_000_000
print({"events": count, "event_timestamp_span_s": span_s})

Aikaleima kattaa ensimmäisestä viimeiseen havaittuun tapahtumaan; se ei mittaa tiedoston kestoa, hankintaviivettä tai käsittelyn suorituskykyä. Tyhjät jaksot ja kellon nollaukset vaativat erillisen käsittelyn tuotannossa. Säilytä laitteen kokoonpano ja tallennuksen metatiedot tiedoston rinnalla, jotta toinen suunnittelija voi toistaa tulkinnan.

Vahvista hiljaiset kohtaukset, kiireiset kohtaukset ja vikojen palautuminen

Testaa paikallaan olevaa kohtausta, edustavaa liikettä ja tarkoituksella vaativaa kohtausta. Välkyntä, kameran värinä ja kuvioitu liike voivat luoda hyvin erilaisia ​​tapahtumia. Kirjaa ylös sekä tyypillinen käyttäytyminen että havaitsemasi pahin tapaus. Toista tallennus ja tietoliikenne aktiivisena, koska nämä työmäärät kilpailevat muistista ja suorittimen ajasta.

TestaaRecordPäätös, jota se tukee
Toista sama tallenneKokoonpano, lähtöerot ja käsittelyn kestoVoidaanko ohjelmiston muutos arvioida toistettavasti?
Lisää kohtauksen aktiivisuuttaJonon syvyys, tapahtuman menetys ja tulosteen ikäPysyykö järjestelmä käyttökelpoinen huippukuormituksen aikana?
Muuta käsittelyikkunaaSovelluksen tarkkuus ja anturin ja ulostulon välinen viiveMikä ajoitus/yksityiskohtien kompromissi sopii vaatimukseen?
Irrota laite ja liitä se uudelleenPalautusaika, kellon nollaus ja tallennuksen jatkuvuusVoiko käyttöön otettu palvelu palautua ennustettavasti?

Kun algoritmi käyttää hermoverkkoa, tarkista tuloksena oleva tensori ja tuetut operaattorit ennen kuin valitset kiihdytin. Tapahtumakamera ei automaattisesti vaadi NPU:tä, eikä NPU automaattisesti hyväksy tapahtumavirtaa. Meidän FPGA, NPU ja MPU arkkitehtuuriopas erottaa hankinta-, esikäsittely-, päättely- ja sovelluspalvelut.

Kysymyksiä ennen ohjelmistopinon valintaa

Voinko käyttää normaalia tietokonenäkömallia?

Vasta sen jälkeen, kun yhteensopiva tuloesitys on määritetty ja sen käyttäytyminen on validoitu. Tapahtumien kerääminen kuviin voi mahdollistaa kuvankäsittelyvaiheen uudelleenkäytön, mutta muuttaa tietojen jakautumista ja lisää ajoitusikkunan. Arvioi täydellinen hakemus edustavien tietojen perusteella.

Todistaako toimiva kannettavan tietokoneen esittely sulautetun yhteensopivuuden?

Ei. Varmista todellisen kohdealustan suorittimen arkkitehtuuri, käyttöjärjestelmä, anturiliitäntä, ohjain, SDK-lisenssi ja jatkuva resurssien käyttö.

Mitä minun pitäisi lähettää integraatiokeskusteluun?

Lähetä kameran tai anturin viite, näytetallennus, suunniteltu lähtö, hyväksyttävä viive, isäntäalusta, käyttöliittymä ja käyttöönottoympäristö. Nämä panokset tekevät keskustelusta riittävän konkreettisen tunnistamaan ensimmäiset integraatioriskit.

Neuromorfinen näkö tietokonenäköputkessa

Tapahtumakameroista keskustellaan usein neuromorfisen näön alla, koska niiden lähtö tallentaa muutoksia yksittäisissä pikseleissä eikä kiinteässä kokonaisten kuvien sarjassa. Tämä dataesitys ei automaattisesti tarjoa objektin havaitsemista tai hermoverkon tulosta. Ohjelmisto tarvitsee edelleen määritellyn tehtävän, yhteensopivan algoritmin ja mitattavissa olevat hyväksymiskriteerit.

Kun integroidaan kehyssuuntautuneiden tietokonenäkötyökalujen kanssa, tapahtumavirta voidaan muuntaa aikaikkunakuvaksi tai muuksi esitykseksi. Säilytä alkuperäiset aikaleimat, jos tehtävä riippuu hienoista ajallisista tiedoista. Arvioi koko muunnos- ja käsittelyputki; houkutteleva rekonstruoitu kuva yksinään ei vahvista lopullisen sovelluksen tarkkuutta tai latenssia.

Suunnittele ajoitus ennen anturifuusio:tä

Tekniset referenssit

Toimittajaesimerkit kuvaavat heidän omaa tuettuaan ekosysteemiään. Vahvista valitun laitteen ja käyttöönoton yhteensopivuus ja lisensointi.

Suunnittele tapahtuma-kameran integrointi.