Sådan automatiseres overvågning let med dyb læring

Denne artikel er en hurtig tutorial til implementering af et overvågningssystem ved hjælp af Objektdetektion baseret på Deep Learning. Den sammenligner også ydelsen for forskellige objektdetekteringsmodeller ved hjælp af GPU-multiprocessering til inferens på fodgængerdetektering.

Overvågning er en integreret del af sikkerhed og patrulje. For det meste indebærer jobbet langvarige perioder med at kigge efter noget uønsket at ske. Det er vigtigt, at vi gør dette, men det er også en meget dagligdags opgave.

Ville livet ikke være meget enklere, hvis der var noget, der kunne gøre "at se og vente" på os? Nå, du har held. Med de fremskridt, der er gjort inden for teknologi i løbet af de sidste par år, kunne vi skrive nogle scripts til at automatisere ovenstående opgaver - og det også, temmelig let. Men før vi dykker dybere, lad os spørge os selv:

Er maskiner gode som mennesker?

Enhver, der kender Deep Learning, ville vide, at billedklassifikatorer har overgået nøjagtighed på menneskeligt niveau.

Fejlfrekvens på ImageNet-datasættet over tid for mennesker, traditionel computervision (CV) og dyb læring. (Billedkilde: Link)

Så ja, en maskine kan holde øje med objekter på samme standard (eller bedre) sammenlignet med et menneske. Når det er sagt, er det meget mere effektivt at bruge teknologi til at udføre overvågning.

  • Overvågning er en gentagen og dagligdags opgave. Dette kan medføre præstationsdybder for os mennesker. Ved at lade teknologi udføre overvågningen, kunne vi fokusere på at gribe ind, hvis noget går galt.
  • For at undersøge en stor landstrimmel har du brug for masser af personale. Stationære kameraer har også et begrænset udsyn. Med mobile overvågningsbots (såsom mikronedoner) kan disse problemer afhjælpes.

Desuden kan den samme teknologi bruges til en række applikationer, der ikke er begrænset til sikkerhed, såsom babymonitorer eller automatiseret levering af produkter.

Fair nok. Men hvordan automatiserer vi det?

Før vi overvejer komplicerede teorier, lad os tænke over, hvordan overvågning fungerer normalt. Vi ser på et videofeed, og hvis vi ser noget unormalt, griber vi ind. Så i det væsentlige bør vores teknologi gennemgå enhver billedramme i håb om at få øje på noget unormalt. Ringer denne proces en klokke?

Som du måske har gætt, er dette selve essensen af ​​Objektdetektion med lokalisering. Det er lidt anderledes end klassificering, at vi er nødt til at vide den nøjagtige placering af objektet. Derudover kan vi have flere objekter i et enkelt billede.

For at finde den nøjagtige placering skal vores algoritme inspicere hver del af billedet for at finde eksistensen af ​​en klasse. Det er sværere end det lyder. Men siden 2014 har kontinuerlig iterativ forskning i Deep Learning introduceret stærkt konstruerede neurale netværk, der kan registrere objekter i realtid.

Se på, hvordan ydelsen steg med kun en periode på 2 år!

Der er flere Deep Learning-arkitekturer, der bruger forskellige metoder internt til at udføre den samme opgave. De mest populære varianter er hurtigere RCNN, YOLO og SSD-netværk.

Hastighed kontra nøjagtighed afveksling. En højere MAP og en lavere GPU-tid er optimal.

Hver model afhænger af en basisklassificering, hvilket i høj grad påvirker den endelige nøjagtighed og modelstørrelse. Desuden kan valget af objektdetektor kraftigt påvirke beregningskompleksiteten og den endelige nøjagtighed.

Der er altid en hastighed vs nøjagtighed vs størrelsesudveksling, når du vælger en objektregistreringsalgoritme.

I dette blogindlæg lærer vi, hvordan man bygger et enkelt, men effektivt overvågningssystem ved hjælp af Objektdetektion. Lad os først diskutere de begrænsninger, vi er bundet til på grund af arten af ​​overvågningsopgaven.

Begrænsninger for dyb læring i overvågning

Vi vil ofte gerne holde øje med en stor jordstrækning. Dette frembringer et par faktorer, som vi muligvis skal overveje, før overvågningen automatiseres.

1. Video feed

For at holde øje med et stort område kan vi naturligvis kræve flere kameraer. Desuden skal disse kameraer gemme disse data et eller andet sted; enten lokalt eller til et fjerntliggende sted.

Typiske overvågningskameraer. (Foto af Scott Webb på Unsplash)

En video af højere kvalitet kræver meget mere hukommelse end en lavere kvalitet. Derudover er en RGB-indgangsstrøm 3x større end en BW-indgangsstrøm. Da vi kun kan gemme en endelig mængde af inputstrømmen, sænkes kvaliteten ofte for at maksimere lagerpladsen.

Derfor skal et skalerbart overvågningssystem være i stand til at fortolke billeder af lav kvalitet. Derfor skal vores Deep Learning-algoritme også trænes i så lav kvalitet.

2. Forarbejdningskraft

Nu hvor vi har løst inputbegrænsningen, kan vi svare på et større spørgsmål. Hvor behandler vi de data, der er opnået fra kamerakilder? Der er to metoder til at gøre dette.

  • Behandling på en centraliseret server:

Videostrømmene fra kameraerne behandles ramme for ramme på en ekstern server eller en klynge. Denne metode er robust og gør det muligt for os at høste fordelene ved komplekse modeller med høj nøjagtighed. Det åbenlyse problem er forsinkelse; du har brug for en hurtig internetforbindelse for begrænset forsinkelse. Hvis du ikke bruger et kommercielt API, kan serveropsætning og vedligeholdelsesomkostninger desuden være høje.

Hukommelsesforbrug vs inferens GPU-tid (millisekunder). De fleste højtydende modeller bruger meget hukommelse. (Kilde)
  • Behandling på kanten:

Ved at tilslutte en lille mikrocontroller kan vi udføre realtidsinferens på selve kameraet. Der er ingen transmissionsforsinkelse, og abnormiteter kan rapporteres hurtigere end den foregående metode. Desuden er dette en fremragende tilføjelse til bots, der er mobile, så de ikke behøver at blive begrænset af en række tilgængelige WiFi / Bluetooth. (såsom mikrodroner).

FPS-funktion for forskellige objektdetektorer. (Kilde)

Ulempen er, at mikrokontrollere ikke er så magtfulde som GPU'er, og du kan derfor blive tvunget til at bruge modeller med lavere nøjagtighed. Dette problem kan omgås ved hjælp af indbyggede GPU'er, men det er en dyr løsning. En interessant løsning ville være at bruge software som TensorRT, som kan optimere dit program til slutning.

Træning af et overvågningssystem

I dette afsnit vil vi tjekke, hvordan man identificerer fodgængere, der bruger Objektdetektion. Vi bruger TensorFlow Object Detection API til at oprette vores Object Detection modul. Vi vil kort undersøge, hvordan man opretter API'en og træner den til vores overvågningsopgave. For en mere detaljeret forklaring kan du tjekke dette blogindlæg.

Hele processen kan sammenfattes i tre faser:

  1. Forberedelse af data
  2. Træning af modellen
  3. Inferens
Arbejdsprocessen involveret i uddannelse af en objektdetekteringsmodel.

Hvis du har lyst til at se resultaterne ville motivere dig mere til at prøve det, er du velkommen til at rulle ned til fase 3!

Fase 1: Forberedelse af data

Trin 1: Hent datasættet

Overvågningsmateriale taget i fortiden er sandsynligvis det mest nøjagtige datasæt, du kan få. Men det er ofte svært at få sådanne overvågningsoptagelser i de fleste tilfælde. I dette tilfælde kan vi træne vores objektdetektor til generelt at genkende vores mål fra normale billeder.

Eksempel på annoteret billede fra vores datasæt.

Som omtalt tidligere fodres billederne i dit kamera måske af lavere kvalitet. Så du skal træne din model til at arbejde under sådanne forhold. En meget elegant måde at gøre det på er ved at udføre dataforøgelse, som forklares detaljeret her. Grundlæggende er vi nødt til at tilføje noget støj for at forringe billedkvaliteten af ​​datasættet. Vi kunne også eksperimentere med slør- og erosionseffekter.

Vi bruger TownCentre-datasættet til vores objektdetekteringsopgave. Vi bruger de første 3600 billeder af videoen til træning og validering og de resterende 900 til test. Du kan bruge scripts i min GitHub-repo til at udtrække datasættet.

Trin 2: Bemærk datasættet

Du kan bruge et værktøj som LabelImg til at udføre kommentarerne. Dette er en kedelig opgave, men alligevel vigtig. Bemærkningerne gemmes som XML-filer.

Heldigvis har ejerne af TownCentre Dataset afgivet kommentarer i csv-format. Jeg skrev et hurtigt script for at konvertere kommentarerne til det krævede XML-format, som du kan finde i min GitHub-repo.

Trin 3: Klon depotet

Klon depotet. Kør følgende kommandoer for at installere krav, kompilere nogle Protobuf-biblioteker og indstille sti-variabler

pip installere -r krav.txt
sudo apt-get install protobuf-compiler
protoc object_detection / protos / *. proto --python_out =.
eksport PYTHONPATH = $ PYTHONPATH: `pwd`:` pwd` / slank

Trin 4: Forbered de understøttende indgange

Vi er nødt til at tildele en ID til vores mål. Vi definerer ID'et i filen kaldet label_map.pbtxt som følger

vare {
 id: 1
 navn: 'mål'
}

Dernæst skal du oprette en tekstfil med navnene på XML og billedfiler. Hvis du f.eks. Har img1.jpg, img2.jpg og img1.xml, img2.xml i dit datasæt, skal din trainval.txt-fil se sådan ud:

img1
img2

Opdel dit datasæt i to mapper, nemlig billeder og kommentarer. Placer label_map.pbtxt og trainval.txt i din annotationsmappe. Opret en mappe med navnet xmls i annotationsmappen, og placer alle dine XML'er inde i den. Dit kataloghierarki skal se sådan ud:

-base_directory
| -images
| -annotations
|| -xmls
|| -label_map.pbtxt
|| -trainval.txt

Trin 5: Opret TF-poster

API accepterer input i TFRecords-filformatet. Brug filen create_tf_record.py, der findes i min repo, til at konvertere dit datasæt til TFRecords. Du skal udføre følgende kommando i din basiskatalog:

python create_tf_record.py \
    --data_dir = `pwd` \
    --output_dir = `pwd`

Du finder to filer, train.record og val.record, når programmet er færdig med udførelsen.

Fase 2: Træning af modellen

Trin 1: Modelvalg

Som nævnt før er der en afvejning mellem hastighed og nøjagtighed. Det ville også være ekstremt tidskrævende at bygge og træne en objektdetektor fra bunden. Så TensorFlow Object Detection API leverer en masse foruddannede modeller, som du kan finjustere til din brugssag. Denne proces kaldes Transfer Learning, og den fremskynder din træningsproces med en enorm mængde.

En masse modeller, der er foruddannet på MS COCO-datasættet

Download en af ​​disse modeller, og tag indholdet ud i dit basismap. Du modtager modelkontrolpunkter, en frosset inferensgrafik og en pipeline.config-fil.

Trin 2: Definition af træningsjobbet

Du skal definere “træningsopgaven” i filen pipeline.config. Placer filen i basismappen. Hvad der virkelig betyder noget er de sidste par linjer i filen - du behøver kun at indstille de fremhævede værdier til dine respektive filplaceringer.

gradient_clipping_by_norm: 10.0
  fine_tune_checkpoint: "model.ckpt"
  fra_detektion_checkpoint: sandt
  num_steps: 200000
}
train_input_reader {
  label_map_path: "annotations / label_map.pbtxt"
  tf_record_input_reader {
    input_path: "train.record"
  }
}
eval_config {
  num_eksempler: 8000
  max_evals: 10
  use_moving_a gennemsnit: falsk
}
eval_input_reader {
  label_map_path: "annotations / label_map.pbtxt"
  blanding: falsk
  num_epochs: 1
  num_readers: 1
  tf_record_input_reader {
    input_path: "val.record"
  }
}

Trin 3: Start træning

Udfør nedenstående kommando for at starte træningsjobbet. Det anbefales at bruge en maskine med en stor nok GPU (forudsat at du installerede gpu-versionen af ​​tensorflow) til at fremskynde træningsprocessen.

python object_detection / train.py \
--logtostderr \
--pipeline_config_path = pipeline.config \
--train_dir = tog

Fase 3: Inferens

Trin 1: Eksporter den træne model

Inden du kan bruge modellen, skal du eksportere de uddannede checkpoint-filer til en frosset inferensgrafik. Det er faktisk lettere gjort end sagt - bare kør koden nedenfor (udskift 'xxxxx' med kontrolpunktets nummer):

python object_detection / export_inference_graph.py \
--input_type = image_tensor \
--pipeline_config_path = pipeline.config \
--trained_checkpoint_prefix = tog / model.ckpt-xxxxx \
--output_directory = output

Du får en fil med navnet fryste_inferens_grafik.pb sammen med en masse checkpoint-filer.

Trin 2: Brug den på en videostrøm

Vi er nødt til at udtrække individuelle rammer fra vores videokilde. Det kan gøres ved hjælp af OpenCVs VideoCapture-metode, som følger:

cap = cv2.VideoCapture ()
flag = sandt
mens (flag):
    flag, ramme = cap.read ()
    ## - Objektdetektionskode -

Den dataekstraktionskode, der bruges i fase 1, opretter automatisk en mappe 'test_images' med vores testsætbilleder. Vi kan køre vores model på testsættet ved at udføre følgende:

python object_detection / inference.py \
--input_dir = {PATH} \
--output_dir = {PATH} \
--label_map = {PATH} \
--frozen_graph = {PATH} \
--num_output_classes = 1 \
--n_jobs = 1 \
--delay = 0

Eksperimenter

Som nævnt tidligere er der handel mellem hastighed og nøjagtighed, mens man vælger en objektdetekteringsmodel. Jeg kørte nogle eksperimenter, som målte FPS og tæller nøjagtighed for de mennesker, der blev opdaget ved hjælp af tre forskellige modeller. Desuden blev eksperimenterne kørt på forskellige ressourcebegrænsninger (GPU-parallelismebegrænsninger). Resultatet af disse eksperimenter kan give dig nogle værdifulde indsigter, mens du vælger en objektdetekteringsmodel.

Opsætning

De følgende modeller blev valgt til vores eksperiment. Disse er tilgængelige i TensorFlow Object Detection API's Model Zoo.

  • Hurtigere RCNN med ResNet 50
  • SSD med MobileNet v1
  • SSD med InceptionNet v2

Alle modeller blev trænet på Google Colab i 10 k trin (eller indtil deres tab var mættet). Som inferens blev der anvendt en AWS p2.8xlarge-forekomst. Tællernes nøjagtighed blev målt ved at sammenligne antallet af mennesker, der blev detekteret af modellen og jord sandheden. Inferenshastigheden i Frames per Second (FPS) blev testet under følgende begrænsninger:

  • Enkelt GPU
  • To GPU'er parallelt
  • Fire GPU'er parallelt
  • Otte GPU'er parallelt

Resultater

Her er et uddrag fra output produceret ved hjælp af FasterRCNN på vores testsæt. Jeg har også vedhæftet en video, der sammenligner output produceret af hver model nær slutningen af ​​denne blog. Du er velkommen til at rulle ned og tjek det!

Træningstid

Plottet nedenfor viser den tid, der er nødvendig for at træne hver model i 10 k trin (i timer). Dette er ekskluderet den tid, der kræves til en hyperparameter-søgning.

Når din applikation er meget forskellig fra den forudbestemte model, du bruger til overførselslæring, kan det være nødvendigt at du justerer hyperparametrene kraftigt. Når din ansøgning ligner, behøver du dog ikke foretage en omfattende søgning. Ikke desto mindre kan du stadig kræve at eksperimentere med træningsparametre som indlæringshastighed og valg af optimizer.

Hastighed (rammer pr. Sekund)

Dette var den mest interessante del af vores eksperiment. Som nævnt tidligere målte vi FPS-ydelsen for vores tre modeller på fem forskellige ressourcebegrænsninger. Resultaterne er vist nedenfor:

SSD'er er ekstremt hurtig og let slår hurtigere RCNN's hastighed, når vi bruger en enkelt GPU. Hurtigere RCNN indhenter imidlertid hurtigt SSD, når vi øger antallet af GPU'er (der arbejder parallelt). Naturligvis er SSD med MobileNet meget hurtigere end SSD med InceptionNet i et lavt GPU-miljø.

En bemærkelsesværdig funktion fra ovenstående graf er, at FPS falder lidt, når vi øger antallet af GPU'er til SSD med MobileNet. Der er faktisk et simpelt svar på dette tilsyneladende paradoks. Det viser sig, at vores opsætning behandlede billeder hurtigere, end de blev leveret af billedlæsefunktionen!

Hastigheden af ​​dit videobearbejdningssystem kan ikke være større end den hastighed, hvorpå billeder føres til systemet.

For at bevise min hypotese gav jeg billedlæsefunktionen et forsprang. Plottet nedenfor viser forbedringen i FPS for SSD med MobileNet, da der blev tilføjet en forsinkelse. Den lille reduktion i FPS i den tidligere graf skyldes den involverede omkostning på grund af flere GPU'er, der anmoder om input.

Naturligvis observerer vi en kraftig stigning i FPS, hvis vi indfører forsinkelser. Hovedpunkterne er, at vi skal have en optimeret billedoverførselsrørledning for at forhindre en flaskehals for hastighed. Men da vores tilsigtede brugssag er overvågning, har vi en ekstra flaskehals. FPS for overvågningskameraet sætter den øvre grænse for FPS for vores system.

Tæl nøjagtighed

Vi definerer tællerøjagtighed som den procentdel af mennesker, der korrekt genkendes af vores objektdetekteringssystem. Jeg følte, at det er mere passende med hensyn til overvågning. Sådan fungerer hver af vores modeller:

Naturligvis er hurtigere RCNN den mest nøjagtige model. Også overraskende klarer MobileNet bedre end InceptionNet.

Baseret på eksperimenterne er det åbenlyst, at der faktisk er en hastighed versus nøjagtighed, der udveksles. Vi kan dog bruge en model med høj nøjagtighed til en god FPS-hastighed, hvis vi har ressourcer nok. Vi observerer, at hurtigere RCNN med ResNet-50 tilbyder den bedste nøjagtighed og en meget god FPS-klassificering, når de installeres på 4+ GPU'er parallelt.

Det var mange trin!

Nå .. jeg ville ikke argumentere. Det er faktisk mange trin. Desuden ville det være byrdefuldt og dyrt at indstille en cloud-instans for denne model til at fungere i realtid.

En bedre løsning ville være at bruge en API-service, der allerede er implementeret på servere, så du bare kan bekymre dig om at udvikle dit produkt. Det er her, Nanonets sparker i. De har deres API implementeret på hardware af høj kvalitet med GPU'er, så du får vanvittig ydelse uden noget af besværet!

Jeg konverterede mine eksisterende XML-kommentarer til JSON-format og fodrede dem til Nanonets API. Faktisk, hvis du ikke ønsker at annotere dit datasæt manuelt, kan du bede dem om at kommentere det for dig. Her er den reducerede arbejdsgang, når Nanonets tager sig af den tunge løft.

Nedsat arbejdsgang med Nanonets

Tidligere nævnte jeg, hvordan mobile overvågningsenheder som mikro-droner i høj grad kan forbedre effektiviteten. Vi kan oprette sådanne droner ganske let ved hjælp af mikrokontrollere, såsom Raspberry Pi, og vi kan bruge API-opkald til at udføre inferencer.

Det er ret simpelt at komme i gang med Nanonets API til objektdetektion, men for en godt forklaret guide kan du tjekke dette blogindlæg.

Resultater med Nanonets

Det tog ca. 2 timer for Nanonets at afslutte træningsprocessen. Dette inkluderer den tid, der kræves til hyperparametersøgning. Med hensyn til den tid, det tager at træne, er Nanonets den klare vinder. Nanonets besejrede også FasterRCNN med hensyn til tællerøjagtighed.

Hurtigere RCNN-nøjagtighed = 88,77%
Nanonets tællerøjagtighed = 89,66%

Her er ydeevnen for alle fire modeller på vores testdatasæt. Det er tydeligt, at begge SSD-modeller er lidt ustabile og har lavere nøjagtighed. Selvom FasterRCNN og Nanonets har sammenlignelige nøjagtigheder, har sidstnævnte endvidere afgrænsningsbokse, der er mere stabile.

Er den automatiske overvågning ansvarlig?

Deep learning er et fantastisk værktøj, der giver eksemplariske resultater med lethed. Men i hvilket omfang kan vi stole på vores overvågningssystem til at handle på egen hånd? Der er nogle få tilfælde, hvor automatisering er tvivlsom.

Opdatering: I lyset af GDPR og de nedenfor anførte grunde er det vigtigt, at vi tænker over lovligheden og de etiske spørgsmål vedrørende automatisering af overvågningen. Denne blog er kun til uddannelsesmæssige formål, og den brugte et offentligt tilgængeligt datasæt. Det er dit ansvar at sikre dig, at dit automatiserede system overholder lovgivningen i din region.

1. tvivlsomme konklusioner

Vi ved ikke, hvordan en dyb læringsalgoritme kommer til en konklusion. Selv hvis datafodringsprocessen er upåklagelig, kan der være en masse falske hits. For eksempel fjernede dette AI bandeordfilter, der blev brugt af britiske politiet, billeder af sandklitter og troede, at de var uanstændige billeder. Teknikker som guidet bagpropagering kan forklare beslutninger til en vis grad, men vi har stadig en lang vej at gå.

2. Adversarial Attacks

Deep Learning-systemer er skrøbelige. Adversarial angreb er beslægtet med optiske illusioner for billedklassifikatorer. Men den skræmmende del er, at en beregnet ubemærket forstyrrelse kan tvinge en dyb læringsmodel til at klassificere forkert. Ved hjælp af det samme princip har forskere været i stand til at omgå overvågningssystemer baseret på dyb læring ved hjælp af ”modstridsbriller”.

3. Falske positive ting

Et andet problem er, hvad gør vi i tilfælde af falske positiver. Problemets sværhedsgrad afhænger af selve applikationen. For eksempel kan en falsk positiv på et grænsepatruljesystem være mere markant end et havenovervågningssystem. Der bør være en vis mængde menneskelig indgriben for at undgå uheld.

4. Lignende ansigter

Desværre er dit look ikke så unikt som dit fingeraftryk. Det er muligt for to personer (eller flere) at se meget ens ud. Identiske tvillinger er et af de vigtigste eksempler. Det blev rapporteret, at Apple Face ID ikke kunne skelne mellem to uafhængige kinesiske kolleger. Dette kan gøre overvågningen og identificeringen af ​​mennesker sværere.

5. Manglende mangfoldighed i datasæt

Deep Learning-algoritmer er kun så gode som de data, du leverer dem. De mest populære datasæt af menneskelige ansigter har kun prøver af hvide mennesker. Selvom det kan virke indlysende for et barn, at mennesker kan eksistere i forskellige farver, er Deep Learning-algoritmer en slags stum. Faktisk kom Google i problemer, fordi det forkert klassificerede en sort person som en gorilla.

Om Nanonets: Nanonets bygger API'er for at forenkle dyb læring for udviklere. Besøg os på https://www.nanonets.com for mere)