Mikä on kehyspohjainen visio?
Kehyspohjainen visio tallentaa kohtauksen kokonaisina kuvina säännöllisin väliajoin, esimerkiksi 30, 60 tai 120 ruutua sekunnissa. Jokainen kehys sisältää tiheää paikkatietoa, mikä tekee tavanomaisista kameroista luonnollisen sopivan kohteen tunnistamiseen, värianalyysiin, tarkastukseen, kartoitukseen ja suureen ohjelmistoekosysteemiin, joka on rakennettu kuvatensorien ympärille.
Kompromissi on, että jokainen kehys siirtää koko kuvan liukuhihnan läpi riippumatta siitä, onko kohtaus muuttunut tai ei. Nopeaa päätössilmukkaa varten valotusaika, kuvajakso, anturin lukema, siirto, kuvan muuntaminen ja päättely vaikuttavat kaikki päästä päähän -latenssiin. Suuri kehysnopeus pienentää näytteenottoväliä, mutta yleensä lisää kaistanleveyttä, muistiliikennettä, tehoa ja lämpökuormitusta.
Mitä on tapahtumapohjainen visio?
Tapahtumapohjainen visio käyttää tapahtumapohjaista kuvakennoa, jonka pikselit reagoivat asynkronisesti kirkkauden muutoksiin. Sen sijaan, että anturi toimittaisi suorakaiteen muotoisen kuvan kiinteällä poljinnopeudella, se tuottaa virran, joka sisältää pikselikoordinaatit, napaisuuden ja tarkat aikaleimat. Staattiset alueet tuottavat siksi vähän tai ei ollenkaan dataa, kun taas liikkuvat reunat voivat tuottaa tapahtumia erittäin hienolla ajallisella resoluutiolla.
Tämä esitys on hyödyllinen, kun liikkeen ajoitus on tärkeämpää kuin täydellisen kuvan toistuva vastaanottaminen. Se voi tukea matalan latenssin seurantaa, nopeaa robotiikkaa ja vaikeita valaistussiirtymiä, mutta tapahtumavirta ei ole tavallinen valokuva. Algoritmit, visualisointi-, tallennus- ja validointityökalut on suunniteltava tietomallin ympärille.
Kuinka tapahtumapohjainen kuvasensori muuttaa datapolkua
Hyödyllinen vertailujärjestelmä paljastaa koko polun anturin hankinnasta suodatuksen ja käsittelyn kautta sovelluksen ulostuloon. Instrumentoi nämä rajat niin, että latenssi- ja tiedonsiirtonopeusvaatimukset voidaan arvioida päästä päähän.
Tärkein arkkitehtoninen ero ei ole vain "nopeampi kamera verrattuna hitaampaan kameraan". Perinteinen visioputki alkaa usein täydestä kuvapuskurista. Tapahtumapohjainen putkisto voi aloittaa yksittäisten tapahtumien tai pienten tapahtumaikkunoiden käsittelyn heti niiden saapuessa. Tämä mahdollistaa suodatuksen, aikaleiman kohdistuksen, kiinnostuksen kohteena olevan alueen logiikan ja liikeominaisuudet toimivat lähellä anturia odottamatta täydellistä kuvaa.
Tapahtumatiedot voivat kuitenkin tiivistyä erittäin teksturoiduissa kohtauksissa tai tärinän ja välkkymisen alaisena. Järjestelmän suunnittelussa tulisi siksi mitata pahimman tapauksen tapahtumanopeus, käyttöliittymän käyttö ja muistin kaistanleveys sen sijaan, että oletetaan, että tapahtuman havaitseminen tarkoittaa aina pientä kaistanleveyttä.
Tapahtumapohjainen visio vs kehyspohjainen visio
| Mitat | Kehyspohjainen visio | Tapahtumapohjainen visio |
|---|---|---|
| Anturin lähtö | Tiheitä kuvia määrätyin välein | Asynkroniset kirkkauden muutostapahtumat |
| Aikatiedot | Valotus ja otospoljinnopeus rajoittavat | Yksittäisiin tapahtumiin liittyvät hienot aikaleimat |
| Staattiset kohtaustiedot | Täydelliset kehykset saapuvat jatkuvasti | Vähän toimintaa muuttumattomilta alueilta |
| Tila-/värikonteksti | Vahva; absoluuttinen kuvan voimakkuus ja kypsä värikuvaus | epäsuora; tapahtumavirta kuvaa muutoksia perinteisen kuvan sijaan |
| Nopea liike | Vaatii riittävän valotuksen ja kuvanopeuden | Sopii hyvin nopeisiin ajallisiin muutoksiin |
| Ohjelmistoekosysteemi | Erittäin kypsä CV ja syvään oppivat työkalut | Erikoistuneet algoritmit, esitykset ja tietojoukot |
| Paras istuvuus | Yleinen kuvantaminen, tunnistus, tekstuuri ja ihmisen luettavissa oleva kuva | Nopea dynamiikka, ajalliset ominaisuudet ja matalan latenssin liikkeen havaitseminen |
Latenssi: mittaa anturista päätökseen, ei yhtä komponenttia
Tapahtumakamerat valitaan usein alhaisen viiveen havaitsemiseksi, mutta anturin aikaleiman tarkkuus ei ole sama kuin sovelluksen viive. Hyödyllinen suunnittelumittari on aika todellisesta muutoksesta järjestelmän käyttöliittymässä näkyvään päätökseen. Tämä polku sisältää anturin vasteen, kuljetuksen, puskuroinnin, esikäsittelyn, päättelyn tai seurannan, ohjelmistojen ajoituksen ja lähtöviestinnän.
Sama sääntö pätee kehyskameraan. Hyvin suunniteltu korkean kehysnopeuden liukuhihna suorilla muistipoluilla voi toimia paremmin kuin huonosti integroitu tapahtumaliukuhihna. Sen vuoksi arkkitehtuuria tulisi vertailla edustavan liikkeen, valaistuksen ja algoritmien kanssa.
Tapahtumapohjainen visioohjelmisto ja SDK-näkökohdat
Tapahtumapohjainen visioohjelmistopino tarvitsee tyypillisesti laitteen konfiguroinnin, tapahtuman dekoodauksen, aikaleiman käsittelyn, suodatuksen, visualisoinnin, tallennuksen ja toiston. Hyödyllisen tapahtumapohjaisen vision SDK pitäisi myös helpottaa ulkoisten liipaisujen ja muiden antureiden synkronointia, tapahtumatiheyden tarkastamista ja kaapatun sekvenssin toistamista algoritmin kehittämisen aikana.
Tuotantojärjestelmissä ohjelmistojen on ulotuttava pöytäkoneen SDK ulkopuolelle. Tiimien tulee määrittää, miten tapahtumat siirretään FPGA-, MCU-, MPU- tai NPU-resursseihin. kuinka kalibrointi tallennetaan; kuinka aika synkronoidaan; ja kuinka kenttälokit voidaan toistaa. Jos algoritmi muuntaa tapahtumat kertyneiksi kehyksiksi, kerääntymisikkunasta tulee eksplisiittinen latenssi vs. tieto kompromissi.
Missä tapahtumapohjaisesta visiosta on hyötyä
Tyypillisiä tapahtumapohjaisia näkösovelluksia ovat nopea kohteen seuranta, robottikäsittely, optinen virtaus, värähtely- tai liikeanalyysi, nopea teollinen tarkastus ja autonominen havainto kohtauksissa, joissa on suuria kirkkausmuutoksia. Vahvimpia käyttötapauksia ovat yleensä sellaiset, joissa hieno ajallinen rakenne parantaa suoraan päätöstä sen sijaan, että se korvaa vain perinteisen kameran.
Tapahtumapohjainen visio puolustukseen ja autonomisiin alustoihin
Puolustus-, turvallisuus- ja autonomisissa järjestelmissä tapahtumien havaitseminen voi olla merkityksellistä nopean liikkeen vihjeissä, seurantakokeissa, matalan latenssin optisissa hyötykuormissa ja anturifuusiotutkimuksessa. Järjestelmän on silti täytettävä alustavaatimukset, kuten synkronointi, deterministiset rajapinnat, ympäristösuunnittelu, tallennus, kyberturvallisuus ja validointi. Tapahtuman havaitseminen on yksi osa tehtäväketjua, ei täydellinen havaintoratkaisu sinänsä.
Kun hybridikameraarkkitehtuuri on parempi
Monet käytännön järjestelmät hyötyvät modaliteettien yhdistämisestä. Kehykset voivat tarjota semanttista kontekstia ja ihmisen luettavissa olevia kuvia, kun taas tapahtumat tuovat mukanaan ajallisia yksityiskohtia. Lämpö-, inertia- tai mittausanturit voivat lisätä kestävyyttä. Fusion on erityisen hyödyllinen, kun sovellus tarvitsee molempia "mikä se on?" ja "täsmälleen milloin ja miten se liikkui?"
Hybridijärjestelmille yhteinen aika on välttämätöntä. Laitteiston liipaisimet, aikaleima-alueet ja kalibrointi tulee harkita ennen algoritmien viimeistelyä.
Käytännöllinen tapahtumapohjainen visioviittausarkkitehtuuri
Referenssijärjestelmä voi sijoittaa deterministisen suodatuksen ja aikaleimatyön FPGA:hen, tekoälyn päättelyn NPU:hen tai kiihdytin, sovelluspalvelut MPU:hen ja valvonnan MCU- tai reaaliaikaiseen ytimeen. Oikea osio riippuu tapahtumanopeudesta, mallin arkkitehtuurista, muistin kaistanleveydestä ja ulkoisista liitännöistä. Meidän FPGA vs NPU vs MPU reunatekoälyopas selittää tämän osioinnin yksityiskohtaisemmin.
Valinnan tarkistuslista
- Määritä suurin hyväksyttävä anturien välinen viive.
- Mittaa odotettua liikkeen nopeutta, valaistusaluetta ja pahimman mahdollisen kohtauksen aktiivisuutta.
- Päätä, vaaditaanko kuvan absoluuttinen voimakkuus, väri vai ihmisen luettava video.
- Arvioi kaistanleveys ja muistin liike sekä tyypillisissä että pahimmissa kohtauksissa.
- Vahvista algoritmin, tietojoukon ja tapahtumapohjaisen vision SDK kypsyys.
- Suunnittele synkronointi runko-, lämpö-, inertia- tai ulkoisten laukaisulähteiden kanssa.
- Testaa koko putkisto ennen laskennan, kantoaallon ja lämpösuunnittelun jäädyttämistä.
Valitse havainto, jota sovellus tarvitsee
| Sovelluksen kysymys | Lähestymistapa arvioida ensin | Mitä testata |
|---|---|---|
| Onko painettu tarra tai väri oikea? | Kehyspohjainen kuvantaminen | Resoluutio, valaistus, valotus ja tarkastustarkkuus |
| Milloin nopeasti liikkuva reuna ylitti alueen? | Tapahtumapohjainen tunnistus | Ajoituksen laatu, kohtauksen toiminta, väärät tapahtumat ja täydellinen ulostuloviive |
| Mikä esine on läsnä ja kuinka tarkasti se liikkuu? | Hybridikehys ja tapahtumaputki | Kalibrointi, yhteinen aika, edustus ja fuusioetu |
| Toimiiko järjestelmä vaihtuvan valon tai tärinän kanssa? | Molemmat ehdokkaat samoin ehdoin | Sovelluksen tarkkuus, tapahtumanopeus tai kehysten laatu ja resurssien käyttö |
Käytä samaa tehtävää ja kohtausta, kun vertaat ehdokkaita. Terävä visualisointi ei sinänsä ole havaitsemistulos, eikä suuri tapahtumamäärä ole todiste hyödyllisestä tiedosta. Sovi tulosmittari ennen vertailun tallentamista.
Käytännöllinen tapa rakentaa latenssibudjetti
Kun 60 kehystä sekunnissa, kehysväli on noin 16.7 ms. Yksinkertaistetussa mallissa, jossa kohtauksen muutos tapahtuu tasaisesti hetkellisten näytteiden välillä, keskimääräinen odotus seuraavaan näytteeseen on noin 8.3 ms. Altistuminen, lukeminen, kuljetus ja käsittely ovat lisävaikutuksia. Tämä aritmetiikka kuvaa näytteenottovälin; se ei ole mitattu kameran latenssi.
Tapahtumaputkessa on myös suunnitteluvaihtoehtoja, jotka lisäävät viivettä. Jos sovellus odottaa 5 ms -tapahtumaikkunan sulkeutumista ennen käsittelyä, tapahtuma lähellä kyseisen ikkunan alkua voi odottaa melkein 5 ms yksin tässä vaiheessa. Hienot anturin aikaleimat eivät poista tätä puskurointivaihtoehtoa. Käytä näitä esimerkkejä mittaamisen arvoisten vaiheiden tunnistamiseen, äläkä vaadi kiinteää etua kummallekaan anturille.
| Raja | Runkoputki | Tapahtumaputkisto |
|---|---|---|
| Havainto | Valotus ja näytteen ajoitus | Kirkkauden muutosvaste ja aikaleiman luominen |
| Kuljetus | Luku-, linkki- ja isäntäpuskurit | Tapahtumakoodaus, linkki- ja dekooderipuskurit |
| Valmistelu | Kuvan muuntaminen, koon muuttaminen ja tensorin valmistelu | Suodatus, aikaikkunat ja esityksen rakentaminen |
| Päätös | Algoritmi ja tulostuksen ajoitus | Algoritmi ja tulostuksen ajoitus |
Mittaa tulosteen ikä siten, että havaintokellon ja tuloskellon välinen suhde on kelvollinen. Ohjelmiston aikaleima kameran lukupuhelun lopussa ei välttämättä edusta valotusaikaa. Samoin tarkka tapahtuman aikaleima voi kuulua kelloon, joka ei ole vielä kohdistettu isäntäkoneeseen.
Suunnittele vertailu, jonka toinen insinööri voi toistaa
- Määritä tehtävä, kohteen liike, valaistusalue ja vaadittu teho ennen asetusten valitsemista.
- Asiakirjan optiikka, näkökenttä, anturiasetukset, ohjelmistoversiot ja kalibrointi.
- Tallenna edustavia olosuhteita, mukaan lukien vaikeat kohtaukset, kuten välkkyminen tai tärinä tarvittaessa.
- Arvioi yhdessä tehtävän tarkkuus, ulostuloviive, tiedonsiirtonopeus ja jatkuva käsittelykuorma.
- Säilytä tallenteet ja asetustiedostot, jotta algoritmien muutoksia voidaan verrata samoissa tuloissa.
Toteutusvaiheessa meidän tapahtumakameraohjelmisto ja SDK-opas kattaa tietojen esittämisen, tallennuksen ja käyttöönoton. Käytä aikasynkronointiopas modaliteettien yhdistämisessä.
Mikä kamera kannattaa arvioida laaduntarkastuksessa?
Aloita havaitsemastasi viasta. Puuttuva komponentti, painettu etiketti tai pintamerkki voi sopia hyvin perinteiseen kehyskuvaukseen, jossa on ohjattu optiikka ja valaistus. Kun tärkeä signaali on nopea liike tai muutoksen tarkka ajoitus, arvioi tapahtuman havaitseminen samaa tehtävää vastaan.
Kirjoita muistiin pienin asiaankuuluva ominaisuus, kohteen nopeus, näkökenttä, valaistuksen vaihtelu ja käytettävissä oleva päätösaika. Säilytä arvioinnissa normaali tuotantovaihtelu: eri erät, työvuorot, pintakäsittelyt ja osien sijainnit. Vertaa puuttuvia vikoja ja vääriä hylkäyksiä sekä käsittelynopeutta.
Tapahtumatunnistin on testattava, ei vaatimus jokaisessa tarkastusjärjestelmässä. Katso meidän teollinen visio ja laadunvalvontaratkaisu kameran ja koneen väliseen integrointiin ja pilottihanke-suunnitteluun.
Tapahtumapohjainen visio UKK
Mitä on tapahtumapohjainen visio?
Tapahtumapohjainen visio on tunnistusmenetelmä, jossa pikselit raportoivat paikallisista kirkkauden muutoksista asynkronisesti sen sijaan, että odotettaisiin täydellistä kuvakehystä. Jokainen tapahtuma sisältää tyypillisesti pikselikoordinaatit, polariteetin ja aikaleiman, mikä mahdollistaa liikkeeseen liittyvän tiedon saavuttamisen käsittelyputkistoon hienolla ajallisella resoluutiolla.
Mitä eroa on tapahtumapohjaisella visiolla ja kehyspohjaisella visiolla?
Kehyspohjainen näkemys tallentaa kokonaisia kuvia määrätyin väliajoin, kun taas tapahtumapohjaiset näköraportit muuttuvat sitä mukaa kuin niitä tapahtuu. Kehyskamerat tarjoavat tiheän tila- ja värikontekstin; tapahtumaanturit voivat vähentää redundantteja staattisia kohtaustietoja ja parantaa nopean liikkeen ajoitusta. Paras arkkitehtuuri riippuu tehtävästä, valaistuksesta, ohjelmistopinosta ja vaaditusta päätösviiveestä.
Mitä ohjelmistoa tai SDK:tä tarvitaan tapahtumapohjaiseen visioon?
Tapahtumapohjaisen visioohjelmiston on käsiteltävä asynkronisia tapahtumavirtoja tavanomaisten kuvatensorien sijaan. Käytännön SDK:n tulisi tukea anturin konfigurointia, tapahtumien suodatusta, aikaleiman käsittelyä, visualisointia, tallennusta, toistoa, kalibrointia, synkronointia ja muuntamista seuranta- tai hermoverkkoputkilinjojen vaatimiksi esityksiksi.
Missä tapahtumapohjaista visiota käytetään?
Tyypillisiä tapahtumapohjaisia visiosovelluksia ovat nopea robotiikka, liikkeenseuranta, autonomiset järjestelmät, teollinen valvonta ja tunnistus, jossa nopeat näkymän muutokset tai vaikea valaistus tekevät ajoituksesta tärkeän. Se voi myös täydentää perinteisiä kameroita hybridihavaintojärjestelmissä.
Miten tapahtumapohjaista visiota voidaan käyttää puolustusalustoissa?
Puolustus- ja autonomisissa alustoissa tapahtumaanturit voivat tukea alhaisen latenssin liikemerkkejä, seurantaa ja havaitsemista suurella dynaamisella alueella tai nopeassa liikkeessä. Käyttöönotettavissa oleva järjestelmä vaatii edelleen determinististä aikaleimaa, kestäviä rajapintoja, synkronoitua anturifuusio:tä, validoitua ohjelmistoa ja huolellista pahimpien tapausten tapahtumien mittaamista.
Onko tapahtumapohjainen kuvasensori aina pienempi kaistanleveys?
Ei. Staattiset kohtaukset saattavat tuottaa vähän tietoa, mutta tärinä, välkyntä tai erittäin teksturoitu liike voivat luoda tiheitä tapahtumavirtoja. Liitäntä- ja muistisuunnittelun tulisi siksi käyttää mitattuja pahimman tapauksen tapahtumia sen sijaan, että oletetaan, että tapahtuman tunnistus on aina pieni kaistanleveys.
konenäkö, lämpökuvaus ja tarkastuskysymys
Tietokonenäkö on laaja ala, jossa visuaalisesta tiedosta saadaan hyödyllistä tietoa. Teollisessa konenäkö:ssä järjestelmän on myös annettava toistettava tarkastustulos linjan valaistus-, liike- ja ajoitusrajoitusten alaisena. Valitse kehyspohjaisen tai tapahtumapohjaisen havainnoinnin välillä testaamalla vika tai liikeominaisuus, jota sovelluksen todella tarvitsee tarkkailla.
lämpökuvaus lisää uuden mittausulottuvuuden: pintalämpötilaan liittyvän infrapunasäteilyn. Näkyvä kamera voi paljastaa kokoonpano- tai pintavirheitä, kun taas lämpökamera paljastaa lämpötilakuvioita. Nämä menetelmät voivat täydentää toisiaan, mutta kumpikaan ei takaa jokaisen vian näkyvyyttä. Määritä kohdistus, mittausolosuhteet ja päätössäännöt ennen niiden yhdistämistä tarkastusjärjestelmään.
Tutustu visuaaliseen ja lämpölaadun tarkastukseen
Tekniset referenssit
- Gallego et al.: Event-based Vision — A Survey
- Prophesee: tapahtumien suoratoisto ja ikkunallinen pääsy
Ajoitusesimerkit ovat havainnollistavia laskelmia. Tuotetason latenssi- ja havaitsemisvaatimukset edellyttävät koko toteutuksen mittauksia.
Arvioi tapahtumapohjaista näkemystä todellisesta päätössilmukastasi.
Jaa kohde, liikeprofiili, liitännät, ympäristö ja pilottihanke-määrä. Voimme kartoittaa vaatimuksen anturiksi, FPGA:ksi ja paikallisen laskenta-arkkitehtuuriin.