People Counter av Christian K Haraldseid, Mikal Svendsen

Transkript

1 People Counter av Christian K Haraldseid, Mikal Svendsen Prosjektrapport i DAT 215, 6 semester - våren Fakultet for teknologi og realfag Universitetet i Agder Grimstad, Juni 2015 Status: Endelig Nøkkelord: OpenCV, Android, Kamera, Kundetelling, Persontelling. Resymé: I anledning vår (forfattere) sin bachelor oppgave ble det etterspurt en løsning for telling av personer / kunder som kunne integreres bacheloroppgaven. Systemet skal kunne oppdage og telle personer inn og ut av et område ved hjelp av et kamera. I oppgaven er OpenCV brukt som et bibliotek for manipulasjon og tyding av bilder. Løsningen består av en Android-enhet med kamera som teller personer inn og ut av et område. Konfigurasjon av enheten gjøres via et webgrensesnitt og statistikk og data sendes til server for videre håndtering.

2 PeopleCounter DAT215 VÅR 2015 Forord Prosjektet er basert på et problem stilt av oppgave eier av bacheloroppgaven som forfatterne utførte våren (se vedlegg) Produktet er ment som et ekstra system som lett skal kunne integreres med løsningen som er presentert nevnt rapport. Kort oppsummert går nevnte oppgave ut på å lage et Infotainment system til bruk i buss, dette systemet skal vise informasjon til passasjerene på en større TV-skjerm montert i bussen. Passasjerer kan så presenteres for ruteinformasjon, reklame, nyheter med mer. Enheten som står for presentasjonen er naturlig nok koblet opp mot internett, dette gir da muligheten for å integrere et statistikk system som en personeller. Det er het denne delen av løsningen kommer inn som et separat prosjekt. Prosjektet er utført under faget DAT215 ved Universitet I Agder våren Bacheloroppgaven er utlyst av problemeier Red Rock A/S, der dette er et underprosjekt til den større bacheloroppgaven. Arbeid og testing er utført hjemme hos studentene, og ved Universitet I Agder.. Grimstad 04. Juni Christian K Haraldseid Mikal Svendsen II

3 PeopleCounter DAT215 VÅR 2015 Innhold 1 Innledning Bakgrunn Problemdefinisjon Forutsetninger og begrensninger Problemløsning Verktøy Rapportstrukturen Teknisk bakgrunn Persontelling ved hjelp av video Virkemåte Android Grunnprinsipper Kamera Google GCM Nodejs ExpressJS EJS GCM-Node OpenCV Løsningsforslag Applikasjon Server Løsning Applikasjon Server Diskusjon Konklusjon Bibliografi Vedlegg III

4 --Side 4 --

5 1 Innledning Prosjektet ble i Januar 2015 tildelt undertegnede studenter av Red Rock A/S. Målet med prosjektet var å utvide den planlagte Infotainment-løsningen med en person-teller, som skulle være billig og effektiv. Målet var å utforske om det er mulig å lage en slik løsning ved hjelp av hardware som allerede var tiltenkt Infotainment målet. Altså lav-kostnads fastvare, og telling ved hjelp av et kamera. På grunn av at system skulle være vedlikeholdsfritt kreves det også muligheter for å konfigurere løsningen fra andre lokasjoner. Resultatet er tilsiktet å være en applikasjon som ved hjelp av et kamera kan telle personer inn og ut av et område. Dette betyr at bilder fra kameraet må prosesseres, og mennesker må identifiseres. Det må så finnes en måte å vurdere hvilken vei personene på bildet går, samtidig som statistikk skal sendes til en server. Bakgrunnen for prosjektet var å utforske mulighetene ved å benytte billig fastvare, dette for å gi kundene en rimeligere pakkeløsning, som igjen hjelper oppdragsgiver inn i markedet. Eksisterende løsninger er gjerne dyre, og persontellere er ofte høyt prises og kommer i et stort antall forskjellige varianter. --Side 5 --

6 1.1 Bakgrunn Det finnes utallige løsninger innen persontelling og teknologiene som blir brukt er mange. Et knippe produkter som er populære er lasere, varmekamera, kamera og ir-sensorer. Virkemåten på de forskjellige produktene er forskjellige, og er veldig opp til teknologien som er brukt. Utfra studiene som ble gjort i begynnelsen av prosjektet kom en fram til at IR-teller og kamera-tellere var populære produkter. Lase-tellere er også mye brukt, men prisen her er høyere. Dog er kvaliteten på resultatene også høyere. En må også tenke på hvor løsningen skal plasseres for å finne riktig teknologi for formålet. En IR-teller fungerer slik at den teller hver gang IR-strålen blir brutt. Problemet med dette er at strålen fungerer dårlig når flere personer går gjennom strålen samtidig. Ved bruk at IR må også to separate stråler benyttes for at en kan vite hvilken vei personen går. [1] En annen teknologi som brukes er kamera-telling. Teknologien benytter som regel en kamera-feed som er koblet til en datamaskin. Datamaskinen prosesserer så strømmen med bilder og prøver å skille ut mennesker som går gjennom. Et slikt kamera er ofte montert i taket, og bruker to ulike linjer for å måle hvilken vei personen beve ger seg. Figur 1 Illustrasjon av linjer som bestemmer retning. [2] Bildet over illustrere den beskrevne virkemåten, kameraet oppdager personene som skal telles, basert på hvilke linjer som blir krysset først kan en vite hvilken vei personen beveger seg. Løsningene som er tilgjengelige i dag finnes i mange varianter. Flere selskaper spesialiserer seg innen teknologien og har brukt masse penger og ressurser på å utvikle nøyaktige algoritmer som er treffsikre og gode på å telle. Et eksempel er «Box & Value» et Amerikansk selskap som monterer løsninger fra flere store leverandører som «IQinVision», «Lilin» og «Milstone». Selskapet skriver på sine sider at de kan garantere en tellingsprosent (for videoløsninger) på opp mot 98% av alle personer som passerer. [3] Med andre ord er teknologien svært utbredt, moden og utviklet. --Side 6 --

7 1.2 Problemdefinisjon Prosjektet skal utvikles på en svakere type enhet, fra bunn. I utforskningsfasen av prosjektet er det ikke funnet et rammeverk som spesialiserer seg på telling av mennesker. Dette betyr at mye av løsningen må utvikles fra bunn. Mål Mål Prioritet Vanskelighetsgrad Finne en plattform å utvikle mot. Høy Moderat Finne et rammeverk for behandling og Høy Moderat prosessering av bildedata. Implementere metoder for å oppdage objekter. Høy Utfordrende Oppdage bevegende objekter Høy Utfordrende Bestemme retning på objektene Høy Moderat Telle objekter som er passert i ulike retninger Høy Moderat Implementere innstillinger for justering av Middels Moderat applikasjonen for ulike områder. Rapportering av data til ekstern server Middels Enkel Juster innstillinger fra eksternt grensesnitt Lav Moderat 1.3 Forutsetninger og begrensninger Det er ikke poenget i dette prosjektet å slå / eller prøve å matche prosentene som eksisterende full-skala systemer kan oppnå på 98%. Målet med dette prosjektet er å utforske hva som er mulig å få til med fastvaren som er tilgjengelig. I vårt tilfelle er dette lav-kostnads enheter som kjører lettere operativsystemer. Med andre ord siktes prosjekt inn på som en studie i hva som kan utrettes på et semester ved hjelp av teknologien slik den er i dag. --Side 7 --

8 1.4 Problemløsning Første delen av prosjektet tar sikte på å velge teknologi som skal nyttes for å utvikle en løsning. Dette blir forprosjekt perioden som handler om å utforske teknologien som allerede eksisterer. Når deltagerne får en grei innsikt i metoder og prinsipper skal det utformes et løsningsforslag som så skal prøves å settes sammen til et produkt. Målet med prosjekter er å utforske mulighetene en får ved å benytte mindre kostbare enheter som en totalløsningen innen person-telling. Viktig spørsmål som håpes besvart i prosjektperioden er blant annet: - Kan en utvikle en løsning som kan kjøre på nevnt fastvare og fremdeles klare å prosessere all dataen fra kameraet? - Fungerer løsningen tilfredsstillende, og hvordan er resultatet sett opp mot eksisterende systemer? - Kunne systemet fungert i en buss, med forholdene som finnes der? 1.5 Verktøy Under utviklingen ble det benyttet ulike verktøy. Nedenfor finnes den en liste som beskriver alle programmene som ble brukt for å utvikle produktet. Navn Bruksområde Microsoft Office Word Rapportskriving Microsoft Office Visio Figurer og diagrammer Microsoft Office Excel Grafer Android Studio (IntelliJ) Utvikling IDE for Java og Android Git Versjonskontroll IRC Samhandling og koordinering Skype Samhandling og koordinering Brackets Tekstbehandling / utvikling av HTML, CSS, JS. Sublime Text Tekstbehandling / utvikling av HTML, CSS, JS. KiTTY SSH tilgang til webserver. WinSCP SSH overføring av filer via SCP. VmWare ESXi Virtualisering av webserver VmWare vsphere Client Håndtering av virtuelle servere Asus Nexus 7 Nettbrett, til utvikling og testing StackOverflow Nettsted for tekniske spørsmål Photoshop CS6 Editering av bilder og grafikk ClickCharts NHC Flytskjema --Side 8 --

9 1.6 Rapportstrukturen Rapporten har en logisk oppbygning. - Kapittel 1 omhandler prosjektet, og målet bak oppgaven. 1 - Kapittel 2 tar for seg teknologien og forklaringen rundt de større elementene som nyttes i prosjektet. Grunnen til at kapittel to er et teknisk kapittel er for å gi leseren en bedre forståelse av systemet som blir presentert i løsningsforslaget og løsningen. - Kapittel 3 er vårt løsningsforslag, dette illustrerer vår tiltenkte løsning før produktet ble utviklet. - Kapittel 4 er vår løsning, dette kapittelet tar for seg hvordan løsningen ble laget og implementert. - Kapittel 5 er et diskusjonskapittel, her diskuteres resultatene. - Kapittel 6 Konklusjon. --Side 9 --

10 2 Teknisk bakgrunn I dette kapittelet skal en se nærmere på teknologiene som skal brukes videre i prosjektet, slik at leseren får en forståelse for de ulike hjelpemidlene som er benyttet under utviklingen. 2.1 Persontelling ved hjelp av video Virkemåte Telling ved hjelp av videokamera er en av de mest utbredte måtene og telle personer på. Mange gode algoritmer er utviklet for formålet, og resultatene er ofte gode. I de fleste tilfeller bygges løsningen inn i en felles enhet, på denne måten minimeres behovet for infrastruktur rundt enheten, da det bare er talldata som sendes videre over nettverket. Hovedprinsippet, eller metoden som er mest brukt et bakgrunns-subtraksjon. Denne måten å behandle et bilde på innebærer og sammenligne de ulike bildene fra en strøm av bilder. Ved å trekke resultatet fra de to bildene sitter en igjen med forandringene i bildet (altså hva som er beveget seg) siden forrige bilde. Vegger og tak står som oftest i ro, og derfor er det meget sannsynlig at objektet som har kommet inn i bildet er et menneske (selvfølgelig avhengig av lokasjon på kamera). [4] Dette kan i tillegg settes sammen med algoritmer som bruker statistikk og andre variabler for å få et mer presist resultat. Kort forklart kan en fremgangsmåte være følgende: - Hent inn to bilder fra en videostrøm. - Konverter bildene til gråtoner (farger ikke nødvendig, og det minimerer prosesseringstiden) - Trekk bildene fra hverandre for å få forskjellen på de to bildene. - Bruk forskjellen til å oppdage om det er bevegelse i bildet. - Kombiner overforstående med en egen teknikk for å bestemme retning, størrelse, validitet og så videre. Den viktigste delen av prosesseringen er substruksjonen av to bilder fra strømmen. Metoden lager en maske av objektene som differer på de to ulike bildene. Bildet under illustrerer forskjellen vi får av bildene til høyre, vi har nå en kontur av objektet som er interessant, en kan da bruke videre logikk for å bestemme hvordan en skal behandle objektet. Figur 2 Eksempel på to ulike bilder som er trukker fra hverandre. [5] --Side 10 --

11 2.2 Android Kapittelet tar sikte på å innføre leseren i en forenklet forklaring av Android som utviklingsplattform. Kapittelet forklarer også noen av hovedprinsippene / teknologiene som er brukt under utviklingen. Utviklingen av prosjektet skal skje med Java / Android som plattform. Android er et operativsystem utviklet av Google og er den største mobile plattformen på markedet. Operativsystemet er bygget på toppen av Linux, det har derfor en Linux-kjerne. På toppen av dette kommer Androidrammeverket som gir utviklere tilgang til et omfattende sett av verktøy og funksjoner til utvikling. Fordelen med systemet er at det er godt dokumentert, er optimalisert og åpent samtidig som det er gratis i bruk. (Teksten er hentet fra vedlegg 1) Grunnprinsipper En applikasjon utviklet for Android består i sin minste form av en layout og en «Activity». Videre i rapporten oversetter en engelske betegnelser til en tilsvarende norske ord. «Activity» blir derfor aktivitet videre i rapporten. Aktivitet-klasser interagerer med brukeren, derfor tar denne klassen seg av å lage vinduer og andre visuelle ting som trengs for å vise brukeren layouten som er den andre separate tingen som trengs for en enkel applikasjon. Layouten definerer den visuelle strukturen til et brukergrensesnitt. Android har mange innebygde UI-komponenter som fritt kan benyttes. (Teksten er hentet fra vedlegg 1) Kamera En annen fordel med Android er den tette integrasjonen med kameraet. De fleste mobiltelefoner har i dag et kamera, Android plattformen støtter også tilkobling av eksterne kameraer, noe som gjør det mulig å utvikle en person-teller for «ikke-mobil-enheter» som også kjører operativsystemet. Android har flere innebygde funksjoner for interaksjon med kamera, dette gjør jobben i prosjektet lettere da mange av basiskomponentene ikke behøves å utvikles. Blant annet finnes det et «kamera-view» som er en komponent som presenterer bildestrømmen fra kameraet til brukeren. Denne komponenten er fin å bruke til visualisering av resultatet, på denne måten kan brukeren se hva applikasjonen tolker og gjør. En annen fin funksjon som er innebygget i Android er muligheten for å behandle enkeltbilder fra bildestrømmen, dette betyr i praksis at all funksjonalitet for å gjøre bildene klare til behandling eksisterer i systemet. En klasse kan abonnere på bilder fra bildestrømmen, systemet mater da automatisk alle nye bilder inn til riktig klasse for behandling. [6] Google GCM Google GCM eller «Google Cloud Messaging» er et verktøy som hjelper utviklere å kommunisere med enheter som kjører Android. Systemet er innebygget i Android og holder kontroll på enheter som hører til en GCM «gruppe». Systemet lar en server sende informasjon til alle enhetene i gruppen, uten at utvikleren trenger å holde kontroll på IP-adresser og leveringsforsøk. Systemet leverer automatisk alle beskjeder til riktig enhet basert på en adresse generert av Google første gang enheten registrerer seg i en valgt gruppe. Etter dette kan en sende beskjeder fra server til enheten uten å tenke på selve leveringen. [7] 2.3 Nodejs NodeJS er en åpen-kildekode løsning som leverer en plattform uavhengig utviklingsløsning for server og nettverksapplikasjoner som kan skrives i JavaScript. Node har en handlingsdrevet arkitektur som er ikke-blokkerende, noe som øker skalerbare og effektivitet. NodeJS brukes ofte til sanntids web-applikasjoner. [8] ExpressJS NodeJS bruker som mange andre språk biblioteker / pakker for å gjøre arbeidet enklere for utviklere. En av disse pakkene er ExpressJS. ExpressJS er et lettvekts web-rammeverk som kan --Side 11 --

12 hjelpe utviklere å organisere web-applikasjoner skrevet for NodeJS ved hjelp av JavaScript. ExpressJS er et MVC drevet rammeverk som betyr at logikk, design, og data er skilt fra hverandre på serveren, men presenteres som en helhet til brukeren. ExpressJS gir utvikleren gode verktøy og hjelpemidler for å raskt lage web-applikasjoner. [9] EJS EJS eller Embedded JavaScript er en mal-løsning for bruk ved utvikling av HTML til webapplikasjoner. Syntaksen i seg selv er HTML, men du får også muligheten til å implementere JavaScript i malen som presenteres til brukeren. Dette gjør det lettere å tilby brukeren dynamiske sider. Ikke overraskende er også EJS en mal-teknologi som støttes av ExpressJS. [10] GCM-Node GCM-node er en annen modul som kan legges til i NodeJS applikasjonen. Dette er en modul so forenkler arbeidet med å sende meldinger fra serveren via Google GCM til Android-enheten. 2.4 OpenCV OpenCV er et bibliotek av programmeringsfunksjoner siktet mot sanntids-bildehåndtering. Verktøyet er utvikler av Intel Russia, og er gratis under BSD-lisensen. OpenCV er skrevet primært for bruk ved C++, men det finnes mange «wrappers» som gjør det mulig å bruke biblioteket i andre programmeringsspråk som Phyton og Java. [11] --Side 12 --

13 3 Løsningsforslag 3.1 Applikasjon Det ble bestemt av applikasjonen skulle utvikles for Android plattformen. Dette fordi det eksisterende bachelor prosjektet var opprettet ved hjelp av Android, samtidig som Android innehar flere gode funksjoner for interaksjon med kamera. Samtidig som dette var innafor kriteriene som ble stilt i oppgavebeskrivelsen. Mindre kostbare enheter, som igjen måtte bety att større operativsystemer som Windows må vike. Til bildebehandling skal OpenCV benyttes da dette biblioteket innehar mange viktige funksjoner for manipulasjon og prosessering av bildedata. Dette betyr at utviklerne slipper å sette sammen egne algoritmer for de mest basiske funksjonene. Som fratrekking av to ulike bilder for å finne differansen. Det fantes liste informasjon på internett rundt problemet, og alle større selskaper som hadde sofistikerte algoritmer holdt selvfølgelig nevnte algoritmer hemmelig. Dette betød at deltagerne selv måtte sette sammen et produkt utfra verktøyene som var tilgjengelig å prøve å få til et produkt som kunne tilby tilfredsstillende resultater. I grove trekk skulle applikasjonen bestå av følgende komponenter: En layout som kunne vise brukeren hva kameraet behandler, og hvordan det ble behandler. En ønsket markering av objekter som skulle følges gjennom bildet, slik at en kunne tolke hva algoritmen gjorde, og om det fungerte. Figur 3 Mockup av brukerlayout. Figuren over illustrerer visjonen, som viser et objekt på vei mellom to streker som bestemmer retning, objektet skal markeres med røde streker som illustrerer hvor algoritmen oppfatter objektet beveger seg. I tillegg måtte applikasjonen ha en underliggende algoritme som behandlet bildedata og kalkulerte objektene som beveget seg på skjermen. Til dette ble det bestemt å bruke bildesubtraksjon der to ulike bilder fra bildestrømmen trekkes fra hverandre for å få endringene i et bilde. Objektet måtte så følges over skjermen, og det måtte vurderes om objektet passerte telelinjene og om data skulle sendes videre til server som en telling. For å identifisere om --Side 13 --

14 objektene beveger seg i en gitt retting brukes linjene som kan sees på sketsjen over. Om et objekt passerer den nederste linjen, og beveger seg opp og passerer den øverste linjen kan vi tenke oss at objektet har bevegd seg i retning oppover, det omvendte gjelder for objekter som passerer andre vei. Figur 4 En visuell presentasjon av løsningsforslaget. I figuren ovenfor er den tiltenkte løsningen tegnet opp. Dette er en enkelt illustrasjon av hvordan oppgaven skal løsest, uten de store tekniske forklaringene som en kan finne i løsningskapittelet. Forklaring av figuren følger: - Det integrerte kameraet gir systemet en videostrøm. - Videostrømmen vises til bruker som en vanlig strøm av bilder. - Fra videostrømmen vil alle bilder sendes enkeltvis inn til bildebehandlingen som detekterer objekter ved hjelp av funksjoner som finnes i OpenCV kombinert med egen logikk som bestemmer hva som skal oppdages, og hva som skal ignoreres. - Vi følger så objektene på skjermen, bilde for bilde, og tegner hele tiden en kontur rundt objektet som blir presentert som et eget lag over videostrømmen (for brukeren). - Et sett med regler må defineres for å kunne bestemme retting og posisjon, her brukes blant annet telle-linjene som er forklart over, til å bestemme hvilken vei objektet beveger seg. - I tillegg til funksjonene over, skal det også implementeres en konfigurasjonsløsning, som kan endre på innstillinger i applikasjonen fra en ekstern webside. Selve overføringen av nye innstillinger skal skje ved hjelp av Google Cloud Messaging. Da strategien for løsningen var lagt fram, startet arbeidet med utviklingen. Dette var helt nytt for deltagerne, og resultatene var vanskelige og forutsi. Vi regnet med at endelig løsning mest sannsynlig kom til å vike litt med løsningsforslaget, da resultatet var usikkert. --Side 14 --

15 3.2 Server Server-siden av løsningen skulle være relativt simpel, og bestå av en enkelt form der innstillinger kunne endres, for å så sendes til server. Det var også ønskelig at registrerte tellinger kunne overvåkes fra denne websiden. Løsningen ble utviklet ved hjelp av NodeJS, ExpressJS og EJS. Det var ingen spesiell grunn til at det var denne teknologien som skulle brukes, en helt vanlig HTML / PHP løsning hadde også fungert ypperlig. Teknologien ble derfor valgt av nysgjerrighet, og fordi en ønsket å lære noe nytt. Oppsummert så den tiltenkte løsningen slik ut : Figur 5 Oversikt over funksjonr på server. En webside presenterer brukeren med en form, og en oversikt over antall personer som har blitt telt. Brukeren kan så endre instillinger, og sende dem til enheten via Google sitt GCM system. Enheten registrer så endringer. For hver telling utført på enhet, dytter enheten denne informasjonen via et POST HTTP API til websiden. På denne måten kan en alltid se registrerte tellinger på websiden. --Side 15 --

16 4 Løsning 4.1 Applikasjon Løsningen ble utviklet ved hjelp av beskrivelsen som ble utarbeidet i løsningsforslaget. Nedenfor er alle de ulike komponentene applikasjonen består av beskrevet i videre detalj. Om en studerer figuren som beskriver løsningsforslaget kan en her se igjen komponentene dog med andre navn. Sammen utgjør klassene den endelige løsningen. PendingBlob PendingBlob er en klasse som representerer et bevegende objekt også kalt en blob. Et Pendingblob objekt kan være i flere forskjellige tilstander som hjelper MotionDetector komponenten å avgjøre hvordan den skal regne. CounterLine CounterLine klassen brukes av MotionDetector og representerer en sone som skal telles. Den inneholder også informasjon om to parallelle linjer og logikk for å sjekke skjæring gjennom disse to linjene. MotionDetector MotionDetector klassen inneholder logikk for analyse av bevegelse og telling. I tillegg utvider klassen et Android View, slik at den kan representeres visuelt på skjermen. Klassen abonnerer også på oppdateringer fra kameraet gjennom et callback interface. Hver frame som fanges av kameraet går gjennom MotionDetector for analyse. Når MotionDetector mottar en frame sendes det videre gjennom klassemetodene for prosessering. Første steg er en nedskalering av bilde, siden kameraet tar opp med veldig høy oppløsning. Nedskaleringsfaktoren har gruppen satt til 8, det vil si at et 1920 x 1080 bilde vil bli nedskalert til 240 x 135. En høyere nedskaleringsfaktor vil gi et mindre bilde å analysere, og dermed mindre tid for å prosessere. Bildet blir også konvertert til gråtoner, da en ikke har bruk for fargedata. Deretter blir bilde lagt til i en buffer, og om størrelsen på denne bufferen er lik 2, så begynner den å søke etter bevegelse. Det brukes parvis sammenligning av bilder for å estimere bevegelse, ved å finne differansen mellom to sekvensielle frames kan en anta at denne differansen representerer bevegelse. Komponenten bruker OpenCV for å produsere et differanse bilde, en glatter det så ut ved hjelp av en blur funksjon. Blur funksjonen gir et resultat som er lettere å jobbe med, noen ganger kan det være områder på et objekt som ikke kommer tydelig nok med i differanse bildet, og blur funksjonen bidrar til å slette ut disse. I tillegg så viste det seg å være et problem med at når et objekt har bevegd seg over to bilder, så vil differansen mellom dem vise objektet der det var før, og der det er etter, altså to objekter. Blur funksjonen hjelper også med å fjerne eventuelle mellomrom slik at resultatet viser et sammenhengende objekt. Deretter filtreres irrelevant støy fra bilde med en threshold funksjon. Resultatet man sitter igjen med er et bilde helt uten fargetoner, altså bare svart og hvitt. --Side 16 --

17 Figur 6 Viser hvordan en ferdig filtrering ser ut Figur 7 viser et eksempel på resultat bildene som det jobbes videre med. I eksempelet er det to mennesker som beveger seg forbi kameraet i forskjellig retning, representert av to svarte klatter som videre kalles «blobs». For applikasjonens mål trengs ikke informasjon om blob fasong, men det trengs informasjon om størrelse og posisjon. Igjen har OpenCV allerede innebygget funksjonalitet for dette, ved hjelp av en funksjon som finner konturer i bildet identifiseres blobs. Deretter produserer et rektangel som omfavner de. Hvert rektangel blir så lagt til i en liste som senere skal filtreres og prosesseres. Når alle bevegende objekter er registret, filtreres objekter som mest sannsynlig ikke er mennesker bort. Det å identifisere et menneske er et veldig stort felt, men gruppen valgte en simpel løsning som baserer seg på den antagelsen at det stort sett vil være mennesker som passerer. Det brukes en nedre og øvre grense for størrelse av rektangel til objektet, eller «bounding boxen». Disse verdiene må kalibreres for forskjellige avstander av kamera montering, men den kan effektivt filtrere ut mindre objekter og blobs som blir detektert på grunn av risting i kameraet. I tillegg krever denne metoden betydelig mindre prosesseringskraft enn alternativene, noe som er viktig i dette tilfellet. Når listen over objekter er filtret kan telling begynne. Det brukes to horisontale linjer parallelt til hverandre, om en blob treffer den nederste linjen først og deretter den øverste beveger den seg oppover, og vice versa. I teorien er dette en enkel oppgave men om en skal kunne håndtere at flere objekter krysser tellelinjene samtidig må en kunne skille mellom flere ulike blobs. Det finnes antakeligvis mange måter å identifisere blobs på, gruppen valgte en løsning som baserer seg på den antagelsen at to objekter som krysser tellelinjene samtidig ikke befinner seg i samme breddeposisjon. Det sjekkes for hvert rektangel etter filtrering om en av tellelinjene skjærer gjennom den. Om det er tilfellet opprettes et objekt av klassen PendingBlob, som legges til i en liste. PendingBlob lagrer informasjon om rektangelet, posisjon, og om den entret via bunnen eller toppen. Men før det opprettes en ny PendingBlob, sjekkes hvert rektangel opp mot hver eksisterende PendingBlob for å se om det allerede finnes en registrert blob i samme breddeposisjon, og som entret fra samme retning. Om dette er tilfellet opprettes ikke en ny PendingBlob, men i stedet oppdateres den med ny informasjon om rektangel størrelse og posisjon, slik at man bevarer til en viss grad tilstand over flere frames. Om det allerede finnes en PendingBlob i samme breddeposisjon som entret fra motsatt retning enn gjeldende rektangel er i, så antas det at dette er samme blob, men at den nå er på vei ut. PendingBlob objektet blir da markert som «exiting». Når en PendingBlob er markert som «exiting» kan en ny blob som entrer fra samme retning registreres, fordi en kan nå anta at dette ikke er samme. Men den kan fortsatt ikke telles eller slettes, fordi så lenge den fortsatt blir skjært gjennom av sin siste tellelinje vil den bli registrert --Side 17 --

18 som en ny blob så fort den blir slettet. Derfor holdes objektet helt til rektangelet ikke lenger befinner seg innenfor telleområdet, og først da kan det telles ut. Om en PendingBlob ikke er markert som «exiting», men alikevel forsvinner så markeres den som «missing», og etter et gitt antall ganger der den er markert som forsvunnet vil den regnes som en feilregistrering og slettes. Som en View komponent tegner MotionDetector opp sine to tellelinjer, gjeldende nummer, rektangler for objektene, og differanse bilde opp på skjermen slik at man får et visuelt overblikk av hva som skjer. CameraPreview CameraPreview er en hjelpeklasse for å vise sanntids oppdateringer av kamera på skjermen. Klassen følger et oppsett fra Androids offisielle guider. Klassen inneholder enkel logikk for å håndtere ting som for eksempel endring mellom landskaps og portrett visning, og for å sette en passende input oppløsning på kameraet. I dette prosjektet brukes standard oppløsningen på 1920x1080, som senere nedskaleres til en mer passende oppløsning for prosessering. Dette gir en fin høyoppløst kvalitet i forhåndsvisningsvinduet, mens selve bildeprosesseringen går relativt fort. Virkemåte Flytdiagrammet ovenfor viser hvordan de forskjellige komponentene relaterer til hverandre. CameraPreview viser sanntidsoppdatering av kameraet, som igjen MainActivity legger til i sitt visningsvindu. MotionDetector er uavhengig av CameraPreview, og abonnerer selv på oppdateringer fra kameraet. MotionDetector oppretter flere PendingBlob objekter, og en CounterLine, og bruker OpenCV pluss egen logikk for å telle bevegende objekter. --Side 18 --

19 Følgende illustrasjoner demonstrerer virkemåten til tellealgoritmen. Figur 7 Telle strategi 1 Figuren ovenfor viser fire objekter plukket opp av MotionDetector komponenten. Tre av disse har blitt tildelt et unikt navn for illustrasjon, disse har alle fått opprettet et eget PendingBlob objekt. Det fjerde objektet skjærer ingen linjer, og er derfor ignorert på dette tidspunkt. Figur 8 Telle strategi 2 I neste frame har alle objektene bevegd seg videre. De forandrer gjerne fasong fra bilde til bilde, men posisjonen er noenlunde lik. Blob_2 treffer sin siste linje, og markeres som «exiting», den skal slettes og telles for så fort den ikke lenger skjæres av linjen. Blob_3 har bevegd seg litt nedover, men skjæres fortsatt bare av sin første linje. Ingenting blir oppdatert for blob_3. Blob_1 skjæres nå av begge linjene, men siden den er registrert ved nedre linje først, så settes den også nå som «exiting», den skal slettes og telles først når den ikke lengre skjæres av en linje. Blob_4 som tidligere var ignorert treffer sin første linje og får tildelt et PendingBlob objekt. --Side 19 --

20 Figur 9 Telle strategi 3 I tredje frame er det bare en blob som fortsatt regnes som relevant av MotionDetector, blob_4. Det som mest sannsynlig en gang var blob_3 og blob_1 er ikke lenger innenfor tellesonen, og blob_2 er sporløst forsvunnet. Det er nå PendingBlob objektenes interne tilstand som bestemmer hvordan MotionDetector regner videre. Inngangsretning Nådd Eksisterer timeout Konklusjon utgangslinje Blob_1 Under Ja Nei 0 Opp++, riktig Blob_2 Under Ja Nei 0 Opp++, riktig Blob_3 Over Nei Nei 1 Timeout++, ingen telling, feil Blob_4 Over Ja Ja 0 Ned++ så fort den er borte, riktig Tabellen viser de interne tilstandene til de fire PendingBlob objektene som traverserte gjennom tellesonen. Blob_1 og blob_2 har sjekket ut og ble korrekt registrert, blob_4 ligger an til en korrekt telling, mens blob_3 klarte å passere sin utgangslinje uten å blir skjært av den. Om et objekt beveger seg veldig fort, eller om tellelinjene er for nærme så kan dette være en vanlig grunn til at applikasjonen ikke klarer å registrere den. Når et PendingBlob objekt forsvinner uten å ha skjært sin utgangslinje så inkrementeres en integer variable kalt timeout, og om et gitt antall frames går forbi uten at den er registrert så antar MotionDetector at dette var en feilregistrering, eller at objektet endret retning. --Side 20 --

21 Figur 10 Presentasjon av resultatet På figuren over visest det endelige resultater, (skjermen på enheten) en kan her se at kameraet henger i taket. På bildet er to personer nettopp passert linsen, og en kan se at disse er på vei ut av bildet. Om en merker seg punkt nummer «1» er dette en visuell representasjon av hva resultatet er etter at alle elementer er filtrert ut. En kan også legge merke til at denne representasjonen henger litt etter. Dette er fordi bruker-interfacet får en bildestrøm rett fra kameraet, den visuelle representasjonen av bildene etter det er behandlet i algoritmen er først klar når selve bildemanipulasjonen er funnet sted. Dette er naturligvis en liten stund etter at objektene har passert et gitt punkt. Noe som også er grunnen til at firkantene som representerer oppdagede «bobs» («3» og «4») henger etter personene som har passert kameraet. Av bildet som en ser på «1» kan en se at kameraet og applikasjonen fint har klart å filtrert ut personene som har krysset øvre og nedre grense («5» og «6»). Det er disse linjene som er omtalt som tellelinjer. Det markerte området «2» illustrere telling, indikatoren viser hvor mange personer som har passert linjene oppover og nedover. --Side 21 --

22 Ekstern kommunikasjon I tillegg til selve regnemetodene inneholder også applikasjonen funksjoner for kommunikasjon med en ekstern server. Meldinger fra server til applikasjon sendes ved hjelp av Google GCM som er beskrevet i kapittel 2. Når enheten mottar nye innstillinger fra serveren lagres dette i internminnet til applikasjonen. Ved tilgang på nye innstillinger resettes applikasjonen og de nye innstillingene trer i kraft. Mulige innstillinger som kan endre på er: Navn COUNT_LINE_Y COUNT_LINE_DELTA BLOB_MARGIN BLOB_MISSING_LIFETIME SENSITIVITY_VALUE BLUR_VALUE DOWN_SAMPLE_FACTOR HUMAN_FILTER_UPPER HUMAN_FILTER_LOWER Funksjon Hvor på skjermen de to telelinjene skal være i Y-posisjon. Avstanden mellom de to tellelinjene. Setter hvor stor margin som er akseptabelt mellom to ulike «blobs» før det skal regnes som to separate objekter. Angir hvor mange «frames» et «blob» objekt kan være bort fra skjermen før det regnes som tapt. Hvor sensitiv applikasjonen skal være for bevegelse. Hvor mye blur skal legges på bildet for å filtrere bort unødvendige elementer og gi et bedre resultat. Hvor mye skal bildet som skal prosesseres skaleres ned. (Mindre bilde raskere prosessering, men mindre detaljer) Hvor stort objekt skal registreres. Hvor lite objekt skal registreres. I tillegg til server klient kommunikasjon er det også klient server kommunikasjon. Klienten poster resultatene til et HTTP API på serveren, som lagrer tallene klienten rapporterer. Det brukes et HTTP POST kall fra Android for å sende resultater til serveren. --Side 22 --

23 4.2 Server Figur 11 Skjermdump av server-applikasjonen. Selve serveren kjører som beskrevet i løsningsforslaget ExpressJS, ved hjelp av NodeJS. Det er definert to forskjellige «routes» i server-applikasjonen. Et HTTP POST interface, som tar imot tall fra enheten, dette tallet blir så lagret internt i løsningen og presentert for brukere som besøker konfigurasjonssidene. I tillegg til fremvisning av tall, kan en også editere innstillingene til applikasjonen. Brukeren blir presentert med en egen form, som sendes videre til et bibliotek kalt NODE-GCM. Det er en NodeJS plugin til bruk med Google sitt GCM system. Denne gjør det enkelt å sende informasjon til klienten som også implementerer GCM mottageren. --Side 23 --

24 5 Diskusjon Løsningen teller og fungerer etter planen slik den skulle. Det er dog enkelte områder som har klare problemer som bør utbedres. Blant annet klarer ikke applikasjonen i nåværende form å skille mellom mennesker og andre objekter som måtte krysse bildestrømmen da den ganske enkelt jobber med «blobs» som er uavhengige type objekter som krysser. Dette kan gjøres litt opp for mot å stille inn størrelsen på objektene som skal telles med, men dette gir bare en halvveis løsning på problemet. Et annet problem som er ganske klart er sammenhengende objekter, for eksempel en person med handlevogn, eller flere objekter av samme størrelse gående rett bak hverandre. I testene som er utført viser det seg at enkelte av disse objektene blir regnet som ett enkelt objekt. Et eksempel på dette problemet vises på bildet under. Figur 12 Illustrasjon som beskriver feilhåndtering av "blobs" som ett enkelt objekt. [12] Her går flere personer under linsen samtidig. Problemet som oppstår er at personene blir oppfattet som ett enkelt objekt av algoritmen på grunn av avstanden mellom personene. Dette var et problem vi visste kom til å oppstå. Samtidig var dette gjennomtenkt når mulighetene for å stille inn applikasjonen ble implementert. Resultatet var dog uvisst før vi fikk prøve applikasjonen i et praktisk element. Under testing fant vi raskt ut av innstillingene som var satt opp, raskt kunne forbedre resultatene kraftig. Figur 13 Applikasjonen testes, og enheten er hengt opp i taket for å simulere en inngang. --Side 24 --

25 I begynnelsen merket gruppen varierende resultater som i utgangspunktet var skuffende. Applikasjonen klarte ikke henge med på selv lette tellinger med personer som bevegde seg sent under linsen. Mye forbedret seg da vi lot applikasjonen håndtere flere bilder fra bildestrømmen. Under utvikling var ytelse i tankene våre, og det ble derfor bestemt at applikasjonen bare skulle behandle hver femte bilde. Resten skulle forkastes, dette gjorde til at applikasjonen regnet registrerte «blobs» som tapt, da personen som gikk under linsen hoppet gjennom linjene. Dette ble raskt endret ved å la enheten prosessere alle bilder som kom inn. Overraskende nok klarte den også dette fint, og resultatene ble kraftig forbedret. Videre fant vi ut av innstillingene gjorde underverker ved telling. I starten hadde gruppen problemer med å telle flere mennesker på en gang, samtidig som det var vanskelig for applikasjonen å telle personer som bevegde seg raskt forbi linsen. Avstanden på mellomrom mellom «blobs» og høyde og bredde på «blobs» ble justert. Det viste seg også at en skygge som ble laget av sola ble registret, en skrudde derfor ned sensibiliteten og justerte blur verdien. Resultatet var positivt og applikasjonen viste seg å håndtere raskt bevegende objekter godt. I tester som ble utført klarte applikasjonen å telle stort sett alle objekter som beveget seg frem og tilbake. Ved endring av innstillinger for avstand mellom «blobs» håndterer også applikasjonen flere personer som krysser linjen samtidig. Vedlagt rapporten ligger flere videoer som illustrerer dette. For å få en bedre forståelse for resultatet henvises det til disse. I prosjektperioden har deltagerne fått en større forståelse for bildebehandling og teknikker knyttet til dette. Deltagerne har også blitt kjent med OpenCV biblioteket, samt oppnådd en grunnleggende forståelse for håndtering og prosessering av live-data. I tillegg har deltagerne tilegnet seg kunnskap innen NodeJS og noen av verktøyene knyttet til dette programmeringsspråket for webutvikling. Deltagerne synes det har vært særs artig å jobbe med live-data fra den «virkelige verden». En annen viktig ting som hele tiden har vært en tanke i prosjektet er prosesseringskraven som er knyttet til behandling av store mengder data på kort tid. Gruppen innser at nøyaktige resultater krever mye prosesseringskraft eller veltenkte optimaliserte løsninger. --Side 25 --

26 6 Konklusjon Gruppen er fornøyd med å ha implementert en tellemodul som fungerer. Det har vært mye jobb og research for å få alle biter til å jobbe sammen. OpenCV er et veldig stort bibliotek, det har vært mye prøving og feiling for å komme frem til løsninger som fungerer. I tillegg har JavaCV som tilbyr OpenCV funksjonalitet for Java ingen dokumentasjon, så det ble ekstra arbeid da det var små men vanskelig å finne forskjeller i funksjonsnavn og parameter. Heldigvis finnes det et relativt stort OpenCV nettsamfunn, og JavaCV kom med flere eksempler. Det var tidskrevende og vanskelig å teste applikasjonen godt under utvikling, da kameraet måtte befinne seg i en viss høyde for å kunne spore mennesker. Men gruppen lærte mye om bildebehandling og bevegelse sporing under prosjektets periode, og ikke minst om Android sin kamera funksjonalitet og OpenCV. Alt i alt er produktet et resultat av den tiden som var tilgjengelig. Det er langt ifra perfekt, men utfører de oppgavene som vi ønsket å få til. Det var aldri vår intensjon å utvikle en løsning som stiller på linje med kommersielle produkter. Til bruk i buss er nok ikke vårt produkt egnet, gruppen er usikre på om video-telling er en god løsning i en buss i hele tatt. Det skal godt gjøres å plassere et kamera slik at det ikke oppfatter noen form for bevegelse når bussen kjører. Samtidig er det mange ulike elementer som skygger / lysforhold, vibrasjoner med mer som kan ødelegge resultatene. Gruppen konkluderer med at vår løsning ikke kan benyttes i buss, og mener at en IRteller eller noe lignende kan være den mest aktuelle løsningen for det gitte bruksområdet. --Side 26 --

27 Bibliografi [1] AXIOMATIC TECHNOLOGY LTD, «People Counting - IR,» [Internett]. Available: [2] Mayflex, «Vi-system - Maiflex,» Maiflex, [Internett]. Available: [Funnet ]. [3] Box & Value, «BoxandValue,» [Internett]. Available: [Funnet ]. [4] Wikipedia, «Wikipedia - People Counting,» Wikimedia Group, [Internett]. Available: [Funnet ]. [5] OpenCV Docs, «OpenCV docu,» [Internett]. Available: [Funnet ]. [6] Google, «Android Developer - Camera Preview Callback,» Google, [Internett]. Available: [Funnet ]. [7] Google, «Google Developers GCM,» [Internett]. Available: [Funnet ]. [8] Wikipedia, «Wikipedia - Node.js,» Wikimediagroup, [Internett]. Available: [Funnet ]. [9] ExpressJS, «ExpressJS.com,» [Internett]. Available: [Funnet ]. [10] EmbeddedJS, «EmbeddedJS,» [Internett]. Available: [Funnet ]. [11] Wikipedia, «Wikipedia - OpenCV,» Wikimediagroup, [Internett]. Available: [Funnet ]. [12] Dosch Design, «Dosch Design - People Walking,» - -. [Internett]. Available: [Funnet ]. --Side 27 --

28 Utvidelser brukt i arbeidet. JavaCV Boostrap ExpressJS EJS Node-gcm En wrapper for OpenCV bibloteket. Twitter utviklet rammeverk for utvikling innen web. Stiler for HTML og CSS komponenter for rask utvikling av brukerelementer. Web-rammeverk utvidelse til NodeJS Stil-layout for bruk med Express sammen med NodeJS. En node-modul som hjelper til med sending av data til Android telefoner som implementerer Google GCM. Vedleggsliste Vedlegg A Infotainment System (Bachelor-rapport) Vedlegg B - Ulike videofiler som illustrerer resultatet. --Side 28 --

29 Vedlegg <A, B eller hvilket det er> Vedlegg Vedlegg A Bachelor-rapport (Infotainment) Vedlegg B Videofiler Dobbel_telling.mp4 (Illustrerer rask krysning av flere personer) Rask.mp4 (Illustrerer en rask krysning av en enkel person) Samtidig.mp4 (Illustrer krysning samtidig) -- Side --