Institutt for ingeniørvitenskap og teknologi
Trafikal overvåkning og
deteksjon i tunnel 2017
Bacheloroppgave for ingeniør i automatiseringsteknikk – AUT-2020 SMT-gruppen:
Simon Johannes Hauan Morten Paulsen
Toke Kviesgaard Madsen
Navn eller kandidatnummer
PROSJEKTRAPPORT SIDE 2 Universitetet i Tromsø
Institutt for ingeniørvitenskap og sikkerhet IIS/IVT 9037 TROMSØ
Studieretning: Automasjon År: 2017
Tittel: Trafikal overvåkning og deteksjon i tunnel Dato: 14.05.2017 Gradering: Ingen Antall sider: 37 Vedlegg: 12 Forfattere: Simon Johannes Hauan,Morten Paulsen
og Toke Kviesgaard Madsen
Fortrolighet: Ingen
Veileder: Bernt-Inge Hansen
Oppdragsgiver:
Statens vegvesen region nord
Oppdragsgivers kontaktperson:
Kristian Fløtten
Sammendrag:
Prosjektrapport utarbeidet av SMT-gruppen. Oppdragsgiver ønsket å detektere kjøretøy og syklister i en sektorinndelt tunnel, dette for generelt å øke trafikk- sikkerheten, redusere lys- og ventilasjonskostander og erstatte dagens manuelle
«sykkelknapp». Det er utviklet et løsningsforslag for deteksjon av kjøretøy og syklist ved bruk av bildebehandlingsbiblioteket OpenCV. Basert på testresultater konkluderer SMT-gruppen at løsningsforslagene og forslag til videre arbeid tilfredsstiller problemstilling, og en ser potensialet i bruk av kamera for deteksjon.
Stikkord: Automasjon, bildebehandling, kjøretøydeteksjon, Haar cascade, C++, C#, kamera, blob detection, Statens vegvesen, sykkeldeteksjon, OpenCV,
Sektorinndeling, sykkelknapp
SAMMENDRAG
Statens vegvesen som oppdragsgiver ønsker muligheten for sektorinndeling av en tunnel med tilhørende deteksjon av kjøretøy. Dette bidrar til økt trafikksikkerhet, bedre trafikkavvikling og mulighet for å redusere kostnader med tanke på styring av lys og ventilasjon. Oppdragsgiver ønsker i tillegg at en ser på muligheten for automatisering av dagens sykkelknapp som eksisterer i et utvalg tunneler. Ved å automatisere sykkel- knappen vil dette øke sikkerheten for syklist og øvrig trafikk.
Ref 1: (Figur 11, s.15)
Det er utarbeidet et forslag til løsning bestående av IP kamera, ruter, to konsollprogram, loggfil og et grafisk brukergrensesnitt. Konsollprogrammene utfører deteksjon på hvert sitt område, og er utviklet ved å benytte algoritmer i bildebehandlingsbiblioteket OpenCV.
For deteksjon av syklist er det benyttet en metode kalt «train cascade» der et stort antall bilder benyttes for å bygge opp et treningsgrunnlag for syklistdeteksjon. Informasjonen i bildene blir lagret i en datafil og brukes videre i programmet for deteksjon av syklist.
Resultatene etter testing av løsning viste omlag 97 % korrekt telling av lette kjøretøy, en observerte også noen svakheter vedrørende feiltelling av tyngre kjøretøy. Deteksjon av syklist viste gode resultater ved en begrenset testprosedyre, og det er sett på mulige forbedringer samt videre testing for løsningen.
SMT-gruppen anser forslag til løsning som tilfredsstillende svar på problemstilling gitt av Statens vegvesen.
Figur 1: Deteksjon av kjøretøy
Ref 2: Figur 22, s. 21
FORORD
Bacheloroppgaven representerer avslutningen på et 3-årig utdanningsforløp innenfor automasjon ved UiT - Norges arktiske universitet. Bacheloroppgaven har et omfang på 20 studiepoeng og er utarbeidet av Simon Johannes Hauan, Toke Kviesgaard Madsen og Morten Paulsen våren 2017. Utdanningsinstitusjonen legger stor vekt på prosjektstyring i tillegg til det faglige og denne rapporten. Vi vil dermed også nevne noen av de andre aspektene under prosjektperioden, som ikke har sin naturlige plass i denne rapporten:
• Initialiseringsdokument
• Forprosjektdokument
• Kurs i presentasjonsteknikk
• Tre presentasjoner av vår oppgave
• Stands
• Ganttdiagram
• Dagbok
• Refleksjonsnotat
• Møtereferater
Vi vil rette en stor takk til vår veileder Bernt-Inge Hansen for gode råd og innspill under hele prosessen. Vi ønsker også å rette en stor takk til vår kontaktperson i Statens vegvesen, Kristian Fløtten, for bistand, tildeling av faglitteratur og ikke minst oppgaven.
Kristian arrangerte også en omvisning for SMT-gruppen i Tromsøysund-tunnelen med Rune Lundberg som guide. Dette er noe som vi setter stor pris på, takk.
Vi håper rapporten gjenspeiler arbeidet vårt på en positiv måte og du at finner den interessant.
God lesning!
_________________
___________________ ___________________ _________________
Simon Johannes Hauan Morten Paulsen Toke Kviesgaard Madsen
14.05.17 – Tromsø
INNHOLDSFORTEGNELSE
Prosjektrapport side 2 ... I Sammendrag ... II Forord ... III
1. Innledning ... 1
1.1 Begrepsavklaring ... 1
1.2 Disposisjon av rapport ... 3
1.3 Bakgrunn for valg av oppgave ... 4
1.4 Statens vegvesen ... 4
1.5 Problemstilling ... 4
1.6 Målformulering ... 5
1.7 Begrensninger ... 5
1.8 Kravspesifikasjoner ... 6
2. Teori ... 7
2.1 Tunneler ... 7
2.2 Om brukergrensesnitt ... 11
2.3 Bildeprosessering ... 12
2.4 Digitale bilder ... 13
3. Løsning ... 17
3.1 Sektorinndeling ... 17
3.2 Deteksjon av kjøretøy ... 18
3.3 Deteksjon av syklist ... 21
3.4 Brukergrensesnitt ... 22
4.Test av kjøretøydeteksjon ... 24
4.1 Oppsett og begrensninger ... 24
5. Resultater ... 27
5.1 Resultater fra testing av kjøretøydeteksjon ... 27
5.2 Resultater fra sykkeldeteksjon ... 30
6. Drøfting ... 31
6.1 Diskusjon ... 31
6.2 Begrunnelse for valg av utstyr og metode ... 32
6.3 En erfaring ... 33
6.4 Mulige forbedringer av løsning ... 33
7. Konklusjon ... 36
8. Litteraturliste ... 37
9. Vedlegg ... 37
1. INNLEDNING
Denne rapporten henvender seg i stor grad mot personer som innehar forkunnskaper knyttet til automasjon og programmering, men er likevel skrevet på en lettfattet måte slik at andre også kan dra nytte av å lese den. Kapittelet avklarer en del begrep brukt i oppgaven og presenterer formålet med rapporten.
1.1 BEGREPSAVKLARING
Array - Systematisk arrangement av variabler.
Batch fil - Filtype som inneholder kommandoer for operativsystem. Kan forenkle tid- krevende operasjoner.
Blob - Refereres ofte til som «Blob Tracking», dette er objektet i et bilde som «bounding box» skal omslutte. Blob tracking handler om å gi et objekt en identitet, for å hindre dobbel telling.
Bounding Box - En minst mulig rektangulær omslutning av et objekt i et bilde.
C# - Multi paradigme objektsorientert programmeringsspråk. Ofte brukt til grafisk grensesnitt mellom bruker og programkode.
C++ - Objektsorientert programmeringsspråk.
GUI - Graphical user interface også kalt brukergrensesnitt, bindeledd mellom data- program og bruker.
Haar cascade - Metode for generering av XML-fil, slik at det er mulig å gjenkjenne objekter i et bilde.
IDE - Integrated Development Environment, en samlebetegnelse for alle egenskapene man finner i eksempelvis programmet Microsoft Visual studio 2015. Av egenskaper kan det nevnes: Brukergrensesnitt, koding, feilsøking/testing av kode og mer. Alt dette gjør Microsoft Visual Studio til et kraftig programmeringsverktøy.
IP - Internett protokoll, overføringsprotokoll for data. Må ikke forveksles med kapslings- grad (IP65)
Modbus TCP - En overføringsprotokoll i datakommunikasjonssammenheng.
OpenCV - Open Computer Vision er et bildebehandlingsbibliotek med funksjoner rettet inn mot bildebehandling.
RGB - Rød, grønn og blå, ofte brukt i forbindelse med fargebilder.
RTSP (Real time streaming protocol) - Nettverkskontroll protokoll til bruk i under- holdnings og kommunikasjonssystemer, for å kontrollere strømmende mediaservere.
Tag - Nøkkelord eller uttrykk tildelt ett sett med informasjon.
Train cascade - Metode brukt i oppgaven for deteksjon av syklist.
VLC - Videoavspillingsprogram med stor funksjonalitet.
VTS - Vegtrafikksentral, sentral for styring og overvåking av trafikk.
XML - Filtype med fokus på å inneholde data og uten restriksjoner på tags. I rapporten blir ordene «classifier», «klassifisering» og «klassifiseringsinformasjon» brukt, der det menes informasjonen i denne filen.
ÅDT - Årsdøgntrafikk er antall biler på ett år dividert på antall dager i året (gjennomsnitt).
Dette danner grunnlaget for drifts- og vedlikeholdsutgifter, samt behov for omlegging og utvidelser av veg.
1.2 DISPOSISJON AV RAPPORT
Rapporten er satt sammen av 9 kapitler og tar overordnet for seg følgende:
Kapittel 1: Innledning
Innledningen tar for seg hvem oppdragsgiver er, samt hensikten med denne rapporten. I tillegg introduserer det leseren for resultat-, effekt- og prosessmålene for dette prosjektarbeidet.
Kapittel 2: Teori
Teorien underbygger og introduserer leseren for det teoretiske grunnlaget som de videre kapitelene bygger på. Målet med kapittelet er å underbygge valgene som er foretatt i prosjektet, samt bringe leseren opp på et kunnskapsnivå som er nødvendig for videre lesning av denne oppgaven.
Kapittel 3: Løsning
Dette kapittelet presenterer løsningen på problemstillingene.
Kapittel 4: Test av kjøretøydeteksjon
Presentasjon av oppsett og fremgangsmåte for testing av kjøretøydeteksjon.
Kapittel 5: Resultater
Presenterer resultater fra testing av kjøretøydeteksjon, samt fremgangsmåte og resultater for syklistdeteksjon.
Kapittel 6: Drøfting
Drøfting rundt resultater fra testingen, samt momenter som påvirket systemet.
Kapittel 7: Konklusjon
Konklusjon om målformuleringen for prosjektet er oppnådd, samt videre arbeid for løsningen.
Kapittel 8: Litteraturliste Kapittel 9: Vedlegg
1.3 BAKGRUNN FOR VALG AV OPPGAVE
Før valg av prosjektoppgave hadde gruppen satt noen krav og ønsker knyttet opp mot prosjektet.
• Oppgaven måtte være spennende og givende, da dette er en faktor som gir et godt læringsutbytte, samt virker motiverende under prosjektperioden.
• Videre måtte oppgaven være av en slik vanskelighetsgrad at den var gjennom- førbar innen gitte tidsfrister.
• I tillegg måtte oppgaven være automasjonsrettet, slik at en kunne dra nytte av det en hadde lært gjennom 3 års utdanning ved studieretningen automasjon.
Etter flere spennende tilbud falt valget på en prosjektoppgave tilbudt av Statens vegvesen.
Dette fordi Statens vegvesen er en aktør som er stor på automasjon. I tillegg bidrar de mye til samfunnet, blant annet gjennom sitt fokus på trafikksikkerhet.
1.4 STATENS VEGVESEN
Statens vegvesen er et forvaltningsorgan som har eksistert siden 1864. De er oppdelt i ulike regioner og står for drift og vedlikehold av 55.200 km veg i Norge. I tillegg har de hovedansvaret for kontroll av kjøretøy, førerprøver og ulike tilsynsoppgaver. Det er 7575 ansatte (ved utgangen av 20161) for å håndtere utvikling, utredning og de nevnte oppgavene.
1.5 PROBLEMSTILLING
Overvåking av antall kjøretøy i tunnel
Statens vegvesen ønsker en løsning for sektorinndeling, som gjør at de har oversikt over antall kjøretøy som befinner seg i en gitt tunnel. Dette for å overvåke trafikk, mobilisere nødetater og informere trafikanter ved trafikale hendelser.
Deteksjon av syklist i tunnel
Statens vegvesen ønsker også en løsning som kan erstatte dagens varslingsknapp for syklister i en tunnel. For å varsle andre trafikanter om sin tilstedeværelse, må syklisten i dag manuelt betjene en varslingsknapp.
1http://www.vegvesen.no/_attachment/1830282/binary/1178602?fast_title=%C3%85rsrapport+for+Statens+vegvesen +2016.pdf
1.6 MÅLFORMULERING 1.6.1 EFFEKTMÅL
• Økt trafikksikkerhet for motoriserte kjøretøy og syklister som ferdes i en tunnel
• Gi Statens vegvesen en bredere overvåking av vegnettet i en tunnel
• Muliggjør en bedre lys- og ventilasjonsstyring
• Reduksjon av det totale energiforbruket 1.6.2 RESULTATMÅL
• Utvikle forslag til løsning på sektorinndeling og deteksjon av kjøretøy
• Utvikle forslag til løsning på deteksjon av syklist
• Utvikle brukergrensesnitt for fremvisning av data 1.6.3 PROSESSMÅL
• Oppnå kunnskap innenfor prosjektering og praktisk gjennomføring av større prosjekter
• Tilegne faglig lærdom utenfor fagpensum
• Utvikle gode samarbeidsegenskaper, både innenfor en ekstern gruppe samt ovenfor en ekstern oppdragsgiver.
1.7 BEGRENSNINGER
Prosjektoppgaven har begrensninger med tanke på økonomi og tid. Dette fører til at prosjektets omfang må reguleres med følgende restriksjoner:
• Løsningen er sammensatt av «hyllevare-komponenter» og sees på som en prototype. Dette bidrar til å holde kostnadene på et minimumsnivå.
• Løsningen utgjør ikke en type sektorinndeling slik problemstilling tilsier. Her er det først og fremst prøvd ut med ett kamera, men løsningen er programmert på en slik måte at det lar seg utvide til å danne sektorinndelinger.
• Av sikkerhetsmessige årsaker og tilgjengelighet er testing av systemet utført under åpen himmel og ikke i tunnel.
1.8 KRAVSPESIFIKASJONER
Oppdragsgiver ga relativt frie tøyler for hvordan løsningen skulle utvikles, men noen krav måtte systemet oppfylle. Disse kravene er listet opp nedenfor.
1.8.1 KAMERA
• Må tilfredsstille IP65
• Må kunne detektere i forskjellig belysning
• Må kunne detektere under alle værtyper
• Må være pålitelig og kreve lite vedlikehold 1.8.2 PROGRAM
• Må kunne behandle data effektivt
• Kan ikke forutsette bruk av annen programvare
• Må være mulighet for å skrive logget data til en tekstfil
1.8.3 BRUKERGRESENSN ITT
• Må være oversiktlig
• Må gi mulighet for å hente bilde fra en valgt sektor
• Må visualisere databasevariablene
• Må visualisere lys- og ventilasjonsstatus
• Må visualisere deteksjon av syklist
2. TEORI
Under denne delen i oppgaven vil det gjennomgås en del teoretisk stoff, med det formål å danne grunnlaget for forståelsen av løsningen og argumentere indirekte for hvorfor valgene i løsningen er tatt. I oppgaven skal en se nærmere på overvåking av kjøretøy i en tunnel, det vil derfor være naturlig å se nærmere på litt tunnelteori relatert til denne oppgaven. Videre er det benyttet bildebehandling for deteksjon av kjøretøy og syklist, som krever en liten introduksjon til teorien rundt digitale bilder.
2.1 TUNNELER
Utfordringene har vært store for de som bygger vei, de fleste ønsker å komme raskt frem, og rask transport sparer samfunnet for store beløp. Dette har blant annet vært med på å tvinge frem flere broer og vegtunneler slik som Lærdalstunnelen2 i figur 2, men hva er en vegtunnel? En vegtunnel er definert som et byggverk der vegen føres i en underjordisk eller undersjøisk passasje. En vegtunnel har flere formål, eksempelvis å lede trafikken bort fra tettbebyggelse og sikre god trafikkavvikling i byer. I rasutsatte områder benyttes vegtunnel for å sikre trafikanter samt holde vegstrekninger åpne for fri ferdsel. For å sikre trygg passasje i tunneler, kan det være hensiktsmessig å inndele tunneler i sektorer.
2https://www.geocaching.com/geocache/GC6287J_ku-i-tunnelen?guid=c455754a-04d5-4066-99b5-2b078ae65759 Figur 2: Lærdalstunnelen er per i dag Norges lengste tunnel med en lengde på 24,5Km og ble opprettet som et siste ledd, i en vintersikker forbindelse mellom Oslo og Bergen
SEKTORINNDELING AV T UNNEL
Tanken om sektorinndeling bygger på bruk av to eller flere kameraenheter slik at disse danner en eller flere sektorer i en tunnel. Ved å dele opp en tunnel i sektorer kan en holde oversikt i hver sektor over antall kjøretøy og eventuelt syklister. Det gir også mulighet for å regulere lys og ventilasjon basert på trafikk. Figur 3 viser en sektorinndelt tunnel, hvor sektorene er markert med rosa kvadrater. De rosa kvadratene visualiserer hvordan en sektorinndeling av tunnel kan gjennomføres med tilhørende kameraenheter.
Figur 3: Her ser man hvordan en tunnel eksempelvis kan deles opp i 4 sektorer.
Sektorinndelingen er som nevnt tidligere i kapittel 1.6.1 effektmål, et ledd for å øke trafikksikkerhet og overvåke vegnett i tunnel. For å imøtekomme dette, og gi vegtunneler en rimelig levetid, stilles det en rekke krav til blant annet utforming og elektrisk teknologi herunder lys og ventilasjon. Statens vegvesen har i regi av Vegdirektoratet utformet en serie håndbøker (normaler) som redegjør for disse kravene.
Denne oppgaven omhandler ikke lys og ventilasjon direkte, men er en effekt av problemstillingen. Ved deteksjon av kjøretøy og syklist legges det til rette for at Statens vegvesen kan hente ut informasjon fra tunnel/sektorer og styre lys og ventilasjon på en effektiv og kostnadsbesparende måte. Det vil derfor være naturlig å se litt nærmere på disse to punktene.
Lys
En annen effekt av problemstillingen er å kunne regulere lysmengden i forskjellige sektorer/soner i tunnel basert på trafikk. En tunnel kan inndeles i følgende soner:
innkjøringssone, overgangssone, indre sone og utkjøringssone. Vegtunneler med lengde over 100, eller 25 meter om det er gang eller sykkeltrafikk i tunnelen, skal belyses.3
Øyet behøver tid for å adaptere seg fra dagslys til mørket. Etter 20 sekunder vil øyet kunne orientere seg til omgivelsene, og først etter 30 minutter er øyet fullt adaptert til mørket. Den største faktoren for adaptsjonstiden er differansen mellom dagslys og mørket, hvor yngre mennesker har kortere adaptsjonstid enn eldre. Dette skaper utfordringer for tilpassing av adaptsjonsforholdene for alle trafikanter, slik at trafikk- sikkerheten ivaretas. For å redusere overgangen fra dagslys til mørket inne i en tunnel er det en rekke tiltak som kan iverksettes, her kan blant annet nevnes:
• Å legge tunnelinngangen slik at det blir lite himmellys i synsfeltet frem mot tunnel.
• Å benytte et veldig mørkt asfaltdekke de siste 200 meterne før tunnelinngang
• Overbygg i tunnelinngang som gradvis slipper gjennom lys
Lysmengden og synsforhold inne i tunnel kan økes og forbedres ved å:
• Benytte et lyst asfaltdekke som reflekterer lyset mer og bedre
• Sørge for lyse vegger
• Sørge for godt renhold av lyskilder, vegger og overflater
• Øke lysmengde fra lyskilde ved hjelp av mer effekt og/eller flere lyskilder
• God ventilasjon/ren luft slik at støvpartikler i luften ikke gir lysspredning og sløringsluminans som minsker kontrastene og skaper dårlige synsforhold.
3http://www.vegvesen.no/s/bransjekontakt/Funksjonskontrakt%20dokumenter/Hb164_2013-10.pdf Figur 4: Illustrasjon over viktige soner i en tunnel med tanke på lys.
VENTILASJON
En annen positiv effekt av problemstillingen er en tryggere passasje for syklister som ferdes gjennom tunneler. Dette er viktig når en tenker på at kommune og stat er store pådragsgivere for økt bruk av sykkel som transportmiddel. Dette medfører at tunneler i økende grad kan være aktuelle traséer å benytte seg av, men miljøforholdene inne i en tunnel er langt fra gjestmilde for mennesker.
Luften inne i en tunnel er ofte sammensatt av diverse avgasser og partikler, her kan det nevnes: svevestøv, sotpartikler, CO, CO2 og NOX. Avgassene er svært helseskadelige for mennesker, samt er med på å skitne til lysarmatur, skilting, vegmerking og vegger.
Overvåkning av luftkvalitet skjer ved hjelp av måleutstyr for CO og NO2. Luft- kvalitetsnivå i tunneler som er tillatt for gående og syklister er på henholdsvis 25ppm for CO og 2ppm for NO2. Det stilles også krav om ventilasjonssystem i tunneler med lengde over 1000 meter og ÅDT over 1000.
VEGTRAFIKKSENTRALEN
For å sikre god og sikker transport gjennom lange tunneler, over krevende fjelloverganger samt mange kilometer med veg, er vegtrafikksentralene4 (VTS) et viktig kontaktpunkt for trafikanter.
Gjennom de døgnåpne VTS-ene betjenes årlig ca. 700 000 publikumstelefoner gjennom 175 nummeret, 522 tunneler over-våkes og styres, ca. 60 000 km veg og 21 fjell-overganger styres5 og overvåkes gjennom de regionale VTS-ene. Fire av disse stod ferdig 23. mars 1993 for å dirigere trafikk-flyt og trafikkinformasjon rundt stengte fjell- overganger, vegarbeid og lignende.
For å dekke Sør-Norge, ble VTS-ene strategisk plassert i Trondheim, Bergen, Porsgrunn og Oslo. November samme år ble den femte og siste VTS-en offisielt åpnet i Mosjøen, den skulle dekke de tre nordligste fylkene i landet.
VTS-ene har naturligvis blitt mer høyteknologiske i løpet av de siste årene, dette innebærer omfattende bruk av ITS-verktøy (intelligent trafikkstyring) for overvåkning og sikker trafikkregulering. Denne typen overvåkning er et SCADA system (Supervisory
4https://www.facebook.com/vtsnord/photos/a.258133377655324.1073741826.258130420988953/863293430472646/
?type=1&theater
5http://www.vegvesen.no/om+statens+vegvesen/presse/nyheter/nasjonalt/vts-20-%C3%A5r-som-vegvesenets-
%C3%B8ye
Figur 5: Mosjøen vegtrafikksentral. Her kan operatører overvåke trafikkavvikling, fjelloverganger, og bruer, samt besvare publikumstelefoner og distribuere veg- trafikkmeldinger.
Control And Data Acquisition), som er en betegnelse for et stort «overvåkningsnettverk»
der Statens vegvesen blant annet kan:
• Overvåke vegnett og trafikkavvikling med særlig fokus på tunneler
• Fjernstyre trafikktekniske installasjoner
(stenge/åpne-kjørefelt/omkjøring/informasjonstavler/lysregulering)
• Varsle om drift og vedlikehold på vegnett
2.2 OM BRUKERGRENSESNITT
Data som VTS-ene bruker hentes fra vegnett og bør kunne presenteres både lokalt og sentralt, for den lokale presentasjonen kan det tilknyttes et brukergrensesnitt. Et brukergrensesnitt muliggjør kommunikasjon mellom brukeren og programmet. Tidligere var brukergrensesnittet begrenset til at grafikk ble vist som ren tekst og at kommandoer ble skrevet inn i tekst-terminalen.
Med tiden har designet gått fra å være rent tekstbasert til å inneholde grafiske elementer som enkelt kan betjenes ved eksempelvis en datamus og keyboard. Brukeropplevelsen og valgmulighetene er mer intuitivt der brukeren gjerne har større mulighet for overvåking og utføring av kommandoer.
Før data blir presentert i et brukergrensesnitt, vil den ofte bli prosessert i forskjellige programmer før fremvisning. Eksempel på en slik prosess kan være bildeprosessering.
Figur 6: Kommandotolk i Windows 10 til venstre er et eksempel på et program med tekstbasert brukergrensesnitt, mens bildet til høyre av brukergrensesnittet (Kap 3.4) illustrerer hvordan et grafisk brukergrensesnitt kan se ut.
2.3 BILDEPROSESSERING
Bildeprosessering er et samlebegrep for bildemanipulasjon og ideen ble skapt allerede på 1920-tallet. The Bartlane transmisson system ble utviklet av Harry G. Bartholomew og Maynard D. Mcfarlane6, for overføring av bilder gjennom en kabel som gikk på tvers av Atlanterhavet. De kunne overføre avisbilder over Atlanteren på under 3 timer.
I dag benyttes bildeprosessering innenfor mange ulike fagfelt, eksempelvis:
• Fjernmåling (vær observasjon, jordressurser)
• Inspeksjon og automasjon (robotstyring, sikkerhetsovervåking)
• Medisin (røntgen, tomografi)
• Astronomi (observasjon)
• Med mer
Objektsporing med fokus på kjøretøy og syklist er en av mange fagfelt der man kan bruke bildeprosessering for å spore et objekt, som gjort i denne oppgaven.
OBJEKTSPORING
Å spore et objekt i et bilde er en helt essensiell bit av det å kunne avgjøre hvor mange kjøretøy som befinner seg i en tunnel/sektor. Objektsporing er matematikk tilført et bilde med det formål å manipulere fram et ønsket resultatet. Algoritmen som benyttes i denne oppgaven refereres ofte til som «Blob tracking» og går som følgende:
1. Kalkuler bakgrunnen.
2. Bilde subtraksjon.
3. Beregne differansebilde mellom to bilder.
4. Treshold bildet for å finne blobs.
5. Lokaliser senter av blob, for å lokalisere posisjon til kjøretøy.
Dette gir brukeren av algoritmen mulighet til å detektere bevegelser, og gir en datamaskin mulighet til å analysere hva som skjer i et bilde.
6https://en.wikipedia.org/wiki/Bartlane_cable_picture_transmission_system
OPENCV
Når en skal utføre objektsporing vil det være nødvendig med flere forskjellige matematiske funksjoner. Disse funksjonene er samlet i OpenCV-biblioteket, et sanntids
«computer vision» startet under et prosjekt av Intel Research7. Prosjektet ble senere omgjort til åpen kildekode, under open-source «Berkeley Software Distribution»
lisensen8. Biblioteket er utviklet med tanke på mangfold, det kan derfor brukes opp mot flere programmeringsspråk, eksempelvis C, C++, python, java og matlab. Det er også kompatibelt med en rekke operativsystemer som windows, linux, macOS, blacberry, android og iOS. Mangfoldet gjør at biblioteket er godt dokumentert og utprøvd, og inneholder mange av de funksjonene en trenger for objektsporing og Haar cascade.
HAAR CASCADE
Deteksjon av syklist omhandler metoden kalt Haar Cascade. Metoden er en maskinlære prosess presentert i artikkelen “Rapid Object Detection using a Boosted Cascade of Simple Features” i 2001, publisert av Paul Viola og Michael Jones9. I læringsprosessen er programmet utstyrt med en stor mengde positive bilder (med forskjellige syklister) og negative bilder (uten syklister) for generering av deteksjonsgrunnlaget.
2.4 DIGITALE BILDER
I oppgaven benyttes kamera for innhenting av digitale bilder. Digitale bilder er bygd opp av mange små kvadratiske elementer, kalt piksler. Alle piksel- elementer blir representert i en matrise med M-rader og N-kolonner, hvor hver piksel har sin egen posisjon.
Hver piksel har tre tallverdier, som representerer fargen eller grånyansen (én tallverdi) i det aktuelle punktet i bildet (se figur 7 for illustrasjon av en generell matrise).
På eksempelvis en pc-skjerm gjengis bildet i et (x,y) bildekoordinat-system som korresponderer med matrisen til det digitale bildet, hvor origo ofte er plassert oppe i venstre hjørne (0,0), se figur 7. På den måten kan en enkelt bestemme hvor i bildet en farget piksel skal være. Videre brukes farge, gråskala og binærbilder i bildeprosessering for å løse oppgaven.
7https://en.wikipedia.org/wiki/OpenCV
8https://en.wikipedia.org/wiki/BSD_license
9https://www.cs.cmu.edu/~efros/courses/LBMV07/Papers/viola-cvpr-01.pdf
Figur 7: Matrise med tilhørende koordinatsystem
FARGEBILDER
En har benyttet optisk kamera og fargebilder i et ledd for deteksjon av objekter. Digitale fargebilder bygger på de tre primærfargene rød, grønn og blå (RGB). Disse danner grunnlaget for fargenyansene i et digitalt bilde. Hvis en nå antar at hver primærfarge har 28= 256 fargenyanser (8-bits), gir dette 224≈ 16.7 millioner unike fargekombinasjoner for et digitalt RGB bilde, se figur 9.10
Et digitalt farget bilde er en matrise over 3 plan, som representer fargenyansene rød, grønn og blå. Hver piksel i fargebildet inneholder dermed 3 verdier i sin posisjon, denne verdien beskriver fargen i det gitte punktet. For å visualisere dette består den flerdimensjonale matrisen av et rødt, grønt og blått lag, vist i figur 8.11
GRÅSKALABILDER
I bildeprosesseringen blir fargebildet konvertert til et gråskalabilde, dette for å fjerne unødvendig informasjon og tilrettelegge for videre behandling. Et gråskalabilde består av
10https://processing.org/tutorials/color/
11https://se.mathworks.com/help/vision/ref/pcshow.html?requestedDomain=de.mathworks.com Figur 9: De tre primærfargene (RGB) danner
grunnlaget for fargekombinasjonene
Figur 8: Viser hvordan de 3 lagene ligger ovenfor hverandre i en flerdimensjonal matrise
Figur 10: Gråskala bilde med tilhørende matrise viser nyansen av gråtone i hvert pikselelement.
kun én matrise med forskjellig intensitet istedenfor 3 matriser. Verdien i posisjon 𝑛𝑚, til matrisen gjengir grånyansen og strekker seg fra sort (0) til hvit (255). Figur 1012 på foregående side viser et bilde av en mannsperson i et lavoppløst bilde med korre- sponderende matrise.
For å gå fra RGB til gråskala, må en vekte hver farge med et tall mellom 0 og 1. En kan da sette opp en likning ut fra vektingen GV = 0,2989 · 𝑅 + 0,5870 · 𝐺 + 0,1140 · 𝐵, hvor GV er gråskalaverdien. Vektingen vil variere fra program til program.
Figur 1113 viser et RGB bilde som har gjennomgått gråskala vektingen til programmet Matlab som resulterer i bilen til høyre.
BINÆRE BILDER
Ved å konvertere gråskalabildet over til et sort/hvitt (binært) bilde kan en enklere finne konturene av kjøretøyene i bildet. I binære bilder har hver piksel bare to tilstander, 0 eller 1, der 0 ofte representerer sort og 1 representerer hvit. På grunn av dette eksisterer det ikke lenger noen annen informasjon enn hvit og sort, slik figur 12 viser nedenfor.
Gode eksempler på bruksområder der tolking av et binært bilde kan være aktuelt.
• Kjøretøy deteksjon
• Kant deteksjon av et objekt
• Oppdage et objekt på et samleband
• Fingeravtrykkgjenkjenning
• Tekstgjenkjenning
12http://openframeworks.cc/ofBook/chapters/image_processing_computer_vision.html
13https://ih0.redbubble.net/image.287871575.3819/ap,550x550,16x12,1,transparent,t.u1.png Figur 11: Fargebilde og gråskalavekting
Figur 12: Samme bildet representert i farge og binær
GAUSSIAN BLUR
Når en bildestrøm skal prosesseres inneholder bildene ofte støy i form av enkeltpiksler med signifikant større verdi i forhold til de omkringliggende pikslene. Denne støyen er ofte vanskelig å oppdage for det blotte øyet, men gir store utfordringer for objektsporing og kan resultere i falske deteksjoner. Støy oppleves som en forstyrrelse i bildet og skyldes i hovedsak elektronisk støy fra kameraet selv. Dette kan sammenlignes med støy under måling av et elektrisk signal og kan enkelt elimineres ved hjelp av et lav-pass filter. I bildeprosessering fungerer Gaussian blur som et lav-pass-filter og bidrar til å filtrere vekk støy på følgende måte.
Anta en 50x50 matrise hvor et utdrag er 𝐴 =
1 2 3 4 5 6 7 8 9
, samt Gaussian 3x3 på 𝐺 =
𝑥1 𝑥2 𝑥1 𝑥2 𝑥4 𝑥2 𝑥1 𝑥2 𝑥1 .
Ved å utføre Gaussian på tallet A(2,2), er 5 i vårt tilfelle, får en følgende 𝑜𝑢𝑡 =
1𝑥1 2𝑥2 3𝑥1 4𝑥2 5𝑥4 6𝑥2 7𝑥1 8𝑥2 9𝑥1
. Tallet 5 vil få ny verdi 𝑠𝑢𝑚
𝑑𝑖𝑣 =87
16= 5,44.
Figur 13: Før og etter Gaussian blur
3. LØSNING
En har nå fått introduksjon til elementer i løsningen, som består av kamera, bildebehandling (OpenCV-bibliotek), loggfil og brukergrensesnitt, for å oppnå resultatmålene. I dette kapitlet vil en gjennomgå implementeringen og sekvenseringen til programvare, da en har brukt mye programmering i «C++»-språket for å løse utfordringene, er det rettet stort fokus mot algoritmen i programmene.
3.1 SEKTORINNDELING
Sektorinndeling av tunnel er en konsekvens av ønsket om å holde orden på antall kjøretøy, dette er ikke testet grunnet begrensninger satt i oppgaven, men er tiltenkt å fungere på følgende måte:
• Det må alltid være ett kamera mer enn antall sektorer som skal overvåkes
• Hver enkel kameraenhet trenger hver sin «deteksjon av kjøretøy program»
Figur 14: Systemkart viser hvordan en tunnel med en sektor ser ut.
Figur 15: Her kan en se at det må eksistere et kamera mer enn antall sektorer som skal overvåkes.
Det vil i dette tilfellet være behov for fem deteksjonsprogram.
3.2 DETEKSJON AV KJØRETØY
Problemstillingen, deteksjon av kjøretøy, omhandler behandling av bildestrømmen fra kameraet og som løsning er det utviklet et konsollprogram med følgende funksjonaliteter:
deteksjon, telling, logging, lagring av bilder (for bruk i syklist deteksjonsprogrammet) og gjennomsnittstelling. Matematiske funksjoner er tatt i bruk fra OpenCV-biblioteket og kombinert med algoritme for bevegelsesdeteksjon. Algoritmen for deteksjon av kjøretøy deles i tre deler, hvor emnene «eliminere støy og informasjonsfiltrering», «blob deteksjon og boundingbox», samt «lokasjon og kjøreretning» blir gjennomgått.
Kameraet brukt i oppgaven, leverer opp til 25 bilder per sekund. Ved en oppdaterings- frekvens på 25 bilder per sekund (fps) vil et kjøretøy med en hastighet på 80 km/t bevege seg en distanse lik
80𝑘𝑚/𝑡 3,6
25𝑓𝑝𝑠 = 0,888𝑚 𝑝å 𝑒𝑡 𝑠𝑒𝑘𝑢𝑛𝑑.
Er oppdaterings-frekvensen til kameraenheten for lav i forhold til hastigheten til kjøretøyet, vil dette kunne føre til feiltelling.
ELIMINERE STØY OG INFORMASJONSFILTRERING
Ved hjelp av OpenCV og innholdet i VideoCapture klassen, kan en innhente to bilder via
«rtsp» protokollen. Bildene i figur 16 har noe større tidsavstand mellom hverandre enn i konsollprogrammet, da endringene blir synligere og mer forklarende.
Fargebildene blir lagt i variablene A og B og har 3 matriser hver, en for hver fargekanal.
Informasjonen i fargenyansene prosesseres ikke i programmet (inneholder ikke relevant informasjon) og trengs ikke videre i prosesseringen. En forkaster denne informasjonen ved å vekte fargene 0,299 · 𝑅 + 0,587 · 𝐺 + 0,144 · 𝐵.
Figur 16: Variabel A og B
Støy eller unødvendige detaljer itereres bort ved hjelp av Gaussian blur algoritmen i OpenCV, med en 5x5 matrise. Resultatet vises i figur 18, men mindre visuelt enn det verdiene i matrisen ville gjenspeilet.
En har nå mulighet for subtraksjon mellom matrise A og matrise B på en hensiktsmessig måte. Resultatet vises i figur 19, som representerer endringene mellom bildene. En ser her en betydelig reduksjon i irrelevant informasjon og positivt fokus mot deteksjon av kjøretøy.
Bildet er fortsatt representert i gråskala og videre behandling (deteksjon av blob og samle informasjon om bounding box) av bildene krever en binær representasjon, som har positiv effekt på unødig informasjon i matrisen. Overgangen mellom gråskala og binær representasjon skjer ved at en definerer grensen mellom sort og hvit. Eksempelvis alt under 128 defineres til sort og alt over til hvit. Resultatet vises i figur 20, med ønsket effekt.
Figur 17: Variabel A og B konvertert til gråskala via vektingen
Figur 18: Variabel A og B etter Gaussian blur med 5x5.
Figur 19: Variabel A - variabel B Figur 20: Binært bilde av endringene i variabel A og B
BLOB DETEKSJON OG BOUNDINGBOX Fra den binære utgaven av bildet, kan en nå analysere bevegelser i bildet. OpenCV tilbyr funksjonalitet for å finne konturer rundt kjøretøy i bilde (kalt findContours med Suzuki85 algoritme). En bør ikke legge denne informasjonen til i bildet, da dette ødelegger mulighetene for videre arbeid med matrisen. Figur 21 er bare for visuell fremvisning. I stedet brukes dette som input til «convex hull».
Convex hull itererer gjennom bildet og fyller matrisen med verdier på de punktene funksjonen
«findContours» returnerte. Kjøretøyet i figur 22 frem- står nå som mer helhetlig.
Ved hjelp av OpenCV har en nå mulighet å hente ut informasjon om den minste mulige «bounding box’en»
(figur 23), til videre bruk for telling og kjøreretning.
LOKASJON OG KJØRERETNING
Etter at «bounding box»-informasjonen er returnert fra biblioteket, står en med muligheten for telling av kjøretøy og bestemmelse av kjøreretning. Da «bounding box» koordinatene er kjent vet en også senter av dette rektanglet. Om en nå definerer en rett linje, horisontalt på bildet, er det mulig å teste fra hvilken side senter av kjøretøyet passerer fra. Ut fra dette kan en addere eller subtrahere en variabel, alt ettersom hvilken side kjøretøyet krysser linjen fra. Figur 24 viser en
«bounding box» som ikke omslutter kjøretøyet tilfredsstillende. Dette kommer av avstanden kjøretøyene har mellom bildene, som nevnt innledningsvis. Konsollprogrammet teller opp og ned ettersom trafikken går, samtidig skrives denne informasjonen til tekstfil, for videre bruk til brukergrensesnitt. Konsoll-programmet lagrer et råbilde (ubehandlet bilde fra kamera) med jevne mellomrom, for bruk til deteksjonen av syklister.
Figur 21: Omriss av kjøretøy
Figur 23: Bounding Box Figur 22: Convex Hull
Figur 24: Bilde påført boundingbox
3.3 DETEKSJON AV SYKLIST
Deteksjon av syklist er et konsollprogram utviklet i «C++»-språket. Programmet bruker bildet fra deteksjon av kjøretøy programmet og generert syklist «classifier» til deteksjonen. For løsningen av «deteksjon av syklist» brukes OpenCV (detectMultiScale funksjon) til selve deteksjonen (i konsollprogrammet) og i dette delkapitlet ligger mye av arbeidet i «classifier», ikke konsollprogrammet, og vil derfor ha størst fokus mot treningen av «classifier». Videre i dette kapitlet vil en få innføring i hvordan treningen av en «classifier» forløper.
FORARBEID
En trenger store mengder bilder med og uten syklister, der antallet på negative (uten syklister) bilder skal være høyere enn antall positive bilder (med syklister). I oppgaven er det brukt videoopptak av syklister og ved hjelp av VLC‘s scene filter er bildene ekstrahert ut fra opptaket. Dette lar en lagre hvert tiende bilde fra opptaket, til spesifisert destinasjon på datamaskin. Det er brukt 66 positive mot 101 negative bilder videre i denne oppgaven.
En må klargjøre begge settene med bilder før treningen kan starte, mappen med negative bilder må inneholde en tekstfil med alle navnene til bildene. Dette kan gjøres manuelt, eller en kan opprette og kjøre en batch-fil med følgende innhold: «dir /b *.jpg >bg.txt». De negative bildene brukes til å fortelle konsollprogrammet hva den ikke skal se etter. I oppgavens tilfelle vil det være fordelaktig hvis bildene inneholder gående og biler, men ingen syklister. Målet til forberedelsen av de positive bildene, er å generere et høyt antall positive bilder fra det settet en allerede har. Ved hjelp av OpenCVs beskjærings-program (objectmarker.cpp), kan en beskjære et høyt antall syklister kjapt og effektivt. Ut fra dette lages det en tekstfil med filbane, navn på bildet og koordinatene til syklisten, som vist i figur 25. Med OpenCVs createsamples program og batch-fil kan en generere flere positive bilder. Parameterne brukt i denne oppgaven er som følger: «createsamples.exe -info positive/info.txt -vec vector/vector.vec -num 100000 -w 24 -h 24 -show».
Koden utfører følgende:
• Starter Createsamples.exe
• Sender inn info.txt, som generert tidligere
• Lager vektor-fil kalt «vector.vec»
• Med innholdet til 100 000 genererte bilder dimensjonert etter 24x24 piksler Dette danner grunnlaget for videre trening av classifier.
Figur 25: Utdrag av info.txt fila, for trening av haar cascade
TRENING
En har nå forutsetningene til å starte treningen.
Dette utføres ved bruk av OpenCVs «Haar training» program og batch-fil. Følgende parametere er brukt som input:
«haartraining.exe -data cascades -vec vector/vector.vec -bg negative/bg.txt -npos 60 - nneg 100-nstages 15 -mem 1024 -mode ALL - w 24 -h 24».
Etter generering av «classifier» konverteres denne til xml. En kan nå bruke denne i utviklet konsollprogram, ta inn bilde og oppnå deteksjon av syklister, som vist i figuren til høyre.
3.4 BRUKERGRENSESNIT T
For å få liveview fra kameraet og parameterne er det utviklet et grafisk brukergrensesnitt i Visual Studio. Brukergrensesnittet presenterer bilder fra kamera og visualiserer parameterverdiene på en oversiktlig og god måte. For å skape et levende bilde ble det forsøkt hyppig oppdatering av stillbilder, noe som resulterte i et ineffektivt og ressurs- krevende brukergrensesnitt. For effektiv behandling av videostrøm måtte en finne videokodek (algoritme for koding og dekoding av informasjon) til dette formålet. Ozeki Camera SDK er et utviklerverktøy som lar en utvikle et brukergrensesnitt for innhenting av videostrøm fra kameraet og samtidig visualisere parametere.
Videre følger en enkel presentasjon av brukergrensesnittet.
Figur 26: Haar cascade, bildet viser positivt treff på syklist.
Figur 27: Brukergrensesnittet i sin helhet
Figur 28 viser videostrøm-feltet. For innhenting av videostrøm tastes IP-adresse, brukernavn og passord til kameraet inn i URL feltet. En har også muligheten til å skreddersy sin egen tilkobling og lagre denne til senere bruk.
På figur 29 ser en feltet til indikatorene. Indikatorene viser følgende parametere:
• Antall biler i valgt seksjon
• Det totale antall biler som befinner seg i tunnelen
• Syklistvarsler som skifter farge ved deteksjon av en syklist
• Effekt på belysning i tunnelen
• Effekt på ventilasjon i tunnelen
Parameterne hentes ut ved å lese av en tekstfil bestående av én linje med tekst. Denne tekstlinjen inneholder verdiene til de nevnte parameterne. Når et kjøretøy telles eller en syklist detekteres oppdateres parameterne i tekstfilen, i dette tilfellet kalt temp.txt.
Parameterne som hentes ut av filen legges så på hver sin plass i et array slik figur 30 viser.
array[0] array[1] array[2] … array[n] array[n+1] array[n+2] array[n+3]
Total Seksjon1 Seksjon2 … Seksjon n Syklist detektert
Belysning Ventilasjon
Figur 30: Skisse av arrayet der parameterne blir plassert før de sendes ut på skjermen
Figur 29: Indikatorer for parameterne som hentes inn
Figur 28: Videostrøm
4.TEST AV KJØRETØYDETEKSJON
Utviklingen av programvaren (deteksjon av kjøretøy) forløp over 20 testinger i perioden 12. til 21. april, hvor fauna i og rundt vegbane er preget av snøskavler og vann. I dette kapitlet presenteres oppsett og fremgangsmåte for testing av deteksjon av kjøretøy. På dette grunnlaget kan en argumentere for og imot samt konkludere om resultatmålene er oppnådd.
4.1 OPPSETT OG BEGRENSNINGER
Testoppsett
Testoppsettet er et mobilt testoppsett bestående av egenutviklet programvare og følgende komponenter:
• HIK VISION DS-2CD2042WD-I(4MM): Vanntett nettverkskamera med IR funksjon, 4MegaPixel, 25fps og mulighet for HD video
• Jensen nettverks Ruter AL20150v5: Ruter signal fra kamera trådløst til pc
• 5V dc strømadapter til kamera
• Biltema Power inverter: Spenningsomformer12/230V, 150w kontinuerlig, 300w peak
• 230V forgreiner
• 19V dc strømadapter til ruter
• 12V 65ah startbatteri
• Kamerastativ med kamerafeste
• Nettverkskabel
• Ledningsnett fra batteri med sikringsholder og tilhørende 15A sikring
Begrensninger
Testingen består ikke av flere sektorer slik målformuleringen sier, men er kun testet med ett kamera (1/2 sektor). Det må også nevnes at testing kun er utført under følgende vær- forhold:
• Dagslys med gode solforhold og motlys
• Ingen nedbør
• Is og snøfritt underlag
Figur 31: Viser en enkel prinsippskisse over hvordan oppkoblingen kan se ut.
FREMGANGSMÅTE FOR TESTING
Når system med programkode var klar for testing, valgte en lokasjon på gangbro som krysser Erling Kjeldsens ved siden av institutt for geologi i Tromsø. Systemet ble satt på nordsiden av gangbro for å unngå sjenanse og forstyrrelse av trafikk, samt minimere faren for å miste gjenstander ned på kjørebanen.
Kameraet ble vinklet mot vegbanen med en helningsvinkel α, funnet med hjelp av appen
«smart tools». Før oppstart ble «smart tools»
kalibrert på gelenderet til broen, slik at en kunne bruke denne til måling av kameravinkel.
Figur 32: Plassering helt i nord-enden av gangbro
Figur 33: «Screenshot» av vaterfunksjonen i smart tools, der det vannrette vateret indikerer
helningsvinkel α i forhold til «handlisten».
Etter oppkobling må en rotere kamera slik at passerings-linjen i programmet står tilnærmet 90º på vegskulder. Dette for å skape rom til deteksjon av kjøretøy i underkant av passeringslinjen.
Figur 34: Den røde linjen står her ca. 90º på vegskulderen på venstresiden.
En må kvalitetssikre tellingen til programvaren ved å manuelt telle passerte kjøretøy parallelt med programvaren. For eliminering av manuell feiltelling ble det brukt to kontrolltellere en hver vei, innhentet data ble videre kontrollert opp mot programvaren.
5. RESULTATER
Etter endt testing ble de ni første målingene av kjøretøydeteksjon forkastet grunnet manglende kvalitet. 1891 kjøretøy ble telt opp manuelt i løpet av denne perioden, og sammenlignet med programvaren. Sist i dette kapittelet ser en på «testing og resultater»
for sykkeldeteksjonen.
5.1 RESULTATER FRA TESTING AV KJØRETØYDETEKSJON
Tabell 1 viser alle tellinger utført ved Erling Kjeldsens veg i henhold til testprosedyre.
Tabell 1: Resultater fra testing av kjøretøydeteksjon
Dato Vinkel Manuell telling Langnes
Programtelling Langnes
Manuell telling Breivika
Programtelling Breivika
12.04.17 23 86 112 50 48
12.04.17 23 100 127 50 75
12.04.17 35 97 95 56 61
12.04.17 35 104 119 68 64
13.04.17 35 34 33 19 17
13.04.17 35 95 142 67 94
21.04.17 35 90 162 110 124
21.04.17 35 108 150 130 176
21.04.17 35 112 172 103 124
21.04.17 45 130 210 94 130
21.04.17 45 82 117 106 135
Sum 1038 1439 853 1048
Under de to første tellingene ble det i hovedsak telt lette kjøretøy, med unntak av telling én retning Langnes, hvor det ble observert et uvisst antall tyngre kjøretøy (Fig 36). En ser av diagrammene at en lavere forkomst av tyngre kjørtøy gir mindre avvik mellom program- og kontrollteller.
Telling tre og fire viser større variasjon mellom program- og kontrollteller, da en observerte et større antall tyngre kjøretøy i telling tre. I telling fire registrerte en 24 tyngre kjøretøy med ukjent fordeling i begge retninger.
86
112
50 48
0 20 40 60 80 100 120
Manuell telling Langnes Programtelling Langnes Manuell telling Breivika Programtelling Breivika
Antall kjøretøy
Telling 2
34 33
19 17
0 5 10 15 20 25 30 35 40
Manuell telling Langnes Programtelling Langnes Manuell telling Breivika Programtelling Breivika
Antall kjøretøy
Telling 1
95
142
67
94
0 20 40 60 80 100 120 140 160
Manuell telling Langnes Programtelling Langnes Manuell telling Breivika Programtelling Breivika
Antall kjøretøy
Telling 3
108
150 130
176
200 4060 10080 120140 160180 200
Manuell telling Langnes Programtelling Langnes Manuell telling Breivika Programtelling Breivika
Antall kjøretøy
Telling 4
Figur 37: Ukjent antall tyngre kjøretøy i begge retninger. Figur 38: 24 tyngre kjøretøy registrert, fordelt i begge retninger.
Figur 35: Kun lette kjøretøy i begge retninger. Figur 36: Ukjent antall tyngre kjøretøy i retning Langnes.
Regner en ut avviksforholdet mellom kontroll- og programtellingene for de utvalgte målingene, får en følgende resultater. Her er «UTK» uten tyngre kjøretøy og «MTK»
med tyngre kjøretøy.
Figur 39: Diagram med prosentvis fremvisning av avvik mellom kontroll- og programtelling.
En ser her en økning i avviket mellom UTK og MTK. Det er viktig å presisere at i MTK- avvikene ligger det også en prosentandel UTK-feil, men trenden viser at introduksjon av tyngre kjøretøy skaper et større avvik. En kan heller ikke utelukke feiltellinger utført av kontrollteller.
Under testingen observerte en videre at kameravinkel kunne ha innvirkning på avviket mellom program- og kontrollteller, men denne påstanden lar seg ikke underbygge da avviket i testresultatene overskygges av tyngre kjøretøy.
3% 4%
11%
23% 26% 28% 29% 33%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
UTK UTK UTK MTK MTK MTK MTK MTK
Avvik i prosent, uten og med tyngre kjøretøy
5.2 RESULTATER FRA SYKKELDETEKSJON
Testingen av syklistdeteksjonsprogrammet ble gjort lokalt på datamaskin og ikke ute i felten. Fra tidligere opptak på Dramsvegen i Tromsø ble bilder ekstrahert ved hjelp av VLC og sendt inn i deteksjon av syklist programmet. Bildene måtte ikke være en del av treningsgrunnlaget, da dette gir falskt deteksjonsgrunnlag. Resultatene viste treff på alle bilder av syklister, men også treff på andre momenter i bildet eksempelvis trær, gående og snøskavler.
Figur 40: Utdrag fra testingen av deteksjonsprogrammet
6. DRØFTING
I dette kapittelet vil en diskutere resultatene presentert tidligere, samt argumentere for valg av metode, utstyr og hvilke utfordringer en har hatt gjennom prosjektperioden. I tillegg presenteres forslag til forbedring.
6.1 DISKUSJON Kjøretøydeteksjon
Resultatene viste at programmet telte flere kjøretøy enn faktisk antall passerte. Dette skyldes utfordringer i programmet relatert til større kjøretøy, eksempelvis semitrailere, vogntog og busser. Under testingen kunne en buss og andre større kjøretøy bli tolket som alt fra én til syv i programmet. Årsaken til dette avviket skyldes eksempelvis (ved observasjon av videostrøm under testing) at utforminger på tak, førerhus og tilhengere ble oppfattet som egne kjøretøy med tilhørende boundingbox. På grunn av algoritmen (subtraksjon av to etterfølgende bilder) brukt i programmet vil markante utforminger på kjøretøy fremstå som bevegelse i bildet. En har i «kapittel 6.4 Mulige forbedringer av løsning» foreslått en bedre algoritme, som eliminerer denne utfordringen.
Sykkeldeteksjon
Under testing fikk en treff på alle syklister som ble sendt inn til programmet og en hel del falske deteksjoner. Dette er nokså naturlig, da treningsgrunnlaget er blitt trimmet underveis i treningen og dermed er grunnlaget for treningen blitt tynnere. Grunnlaget er basert på vintermånedene i Tromsø, noe som tilsier lite syklister ute i gatene. Resultatene viser også mulige utfordringer med vinkelen en forsøker å detektere syklistene på og det foreløpige treningsgrunnlaget har problemer med å skille syklister med andre elementer i bildet. Om dette skyldes treningsgrunnlaget ene og alene, er det ikke mulig å svare på.
Men det er rimelig å anta at bedre konturer for et objekt gir bedre grunnlag.
6.2 BEGRUNNELSE FOR VALG AV UTSTYR OG METODE
Følgende punkter vil drøftes da disse ikke er like åpenbare som de andre valgene en har tatt i denne oppgaven:
• Hvorfor kamera når det finnes andre teknologier for å telle kjøretøy?
Per dags dato benytter Statens vegvesen induktive sløyfer nedfelt i asfaltdekket til deteksjon av kjøretøy. Denne teknologien har sine fordeler, men også ulemper i form av hyppig utskifting ved vegarbeid og normal slitasje. Dette medfører økte kostnader for denne teknologien og er ifølge Statens vegvesen under utfasing. Radar er mer brukt i dag til trafikkovervåking, men også dette er en kostbar teknologi. En har i denne oppgaven valgt optisk kamera med infrarød del. Dette gjør det mulig å bruke samme kamera for både deteksjon av kjøretøy og syklist ved hjelp av de samme bildene. Et annet viktig moment er «natt synet» den infrarøde delen i kameraet tilbyr.
• Bruk av nettverkskommunikasjon for overføring av data.
I dagens tunneler benyttes det flere forskjellige dataoverføringsprotokoller blant annet Modbus TCP. I kombinasjon av dette og at kameramodulen støtter nettopp denne typen data overføring, var utslagsgivende for valget av denne typen over- føringsprotokoll.
• Bruk av OpenCV. _______________________________________________
Det eksisterer flere bildebehandlingsbiblioteker en kan bruke Accord Framework, Aforge, Matlab (Image processing toolbox), Simple CV. Tidligere nevnt er OpenCV et godt dokumentert og utprøvd bildebehandlingsbibliotek. Biblioteket inneholder mange funksjoner rettet mot bildebehandling og det støtter mange forskjellige programmeringsspråk. C++ er brukt i denne oppgaven, da også dette er godt dokumentert opp mot OpenCV.
• Hvorfor benytte gangbro over Erling Kjeldsens veg som testlokasjon?
Gangbroen over Erling Kjeldsens veg ble benyttet som testlokasjon, dette er en vegstrekning med stor variasjon av kjøretøy (buss, bil, vogntog) og gir et godt grunnlag for datainnsamling.
6.3 ERFARINGER
Systemet ser ut til å være ressurskrevende. __________________
En prøvde tre ulike pc’er for kjøring av «deteksjon av kjøretøy»-programmet, og erfaringene viste variert ytelse. Datamaskin med I5 4300U 1.9 GHz, 8GB RAM og uten dedikert skjermkort kunne kjøre programmet noen sekunder. Nummer to var I5 4210U 1.7GHz med 6GB RAM og dedikert skjermkort (Nvidia Geforce 840M). Datamaskinen kunne kjøre programmet, men en opplevde tidvis høy forsinkelse mellom kamera og ferdig prosesserte bilder. Siste datamaskin med I7 4510U 2GHz 8GB RAM og dedikert skjermkort (Nvidia Geforce 840M) kjørte programmet uten merkbare forsinkelser. En ser at begrensningene først og fremst ligger i skjermkort, men også hastigheten til prosessor.
6.4 MULIGE FORBEDRINGER AV LØSNING
Etter testing og observasjoner rundt hvordan systemet oppfører seg i gitte situasjoner, ser en noen utfordringer. Mulige løsninger for å eliminere disse, er her foreslått for å oppnå et mer robust system
• Telling av kjøretøy.
Problematikken vedrørende feiltelling av kjøretøy omhandler i stor grad tyngre kjøretøy som nevnt i «diskusjon 6.1». Hvis en nå ser litt tilbake på hvilken algoritme
«deteksjon av kjøretøy» baserer seg på, er en mulig forbedring av denne en ren bakgrunnssubtraksjon. Nåværende løsning benytter bevegelsesdeteksjons algoritme, hvor to innhentede bilder blir subtrahert.
Av figur 41 kommer det frem hvordan algoritmen i dagens løsning opptrer. I figuren ser en at bussen har forflyttet seg en distanse ned i bildet, dette registreres som en endring i bildematrisen mellom to bilder. Dette forårsaker at bussen blir registrert med to eller flere boundingbox’er, som bidrar til feiltelling.
Mulig løsning på dette er introduksjon av ren bakgrunns-subtraksjon i algoritmen.
Ved å ta bilde av vegbanen (uten trafikk) vil en eliminere mange uromomenter i resulterende bilde.
Bildet nederst i figur 42 har fine kontraster, mer informasjon og et bedre utgangs- punkt for videre prosessering i algoritmen. Bussen fremstår nå som ett objekt og en vil få bussen i èn boundingbox. Om en slik algoritme implementeres, bør bakgrunns-
Figur 41: Eksempel på Subtraksjon med bevegelsesdeteksjon på tyngre kjøretøy. Bildet viser en todelt buss.
Figur 42: Subtraksjon med ren bakgrunn som referanse
bildet baseres på forskjellige årstider, lysforhold og miljøet kameraet plasseres i. Med denne metoden er det rimelig å anta at feiltellinger ved tyngre kjøretøy reduseres. I tillegg kan deteksjonsområdet i selve bildet defineres (definere bare veg som deteksjonsområde), slik at programmet krever mindre maskinkraft.
• Sykkeldeteksjon.
For å unngå falske treff i «deteksjon av syklist»-programmet bør trening av xml-fil intensiveres og treningsgrunnlag baseres på bilder vinkelrett på syklister. Bildene (de positive) vinkelrett på syklisten må inkludere størst mulig variasjon, eksempelvis sykkeltype (fatbike, landeveissykkel…) og person på sykkel (barn, dame, mann, sittende, bekledning…). Deteksjonen bør også her trenes opp i miljøet det skal detekteres i, på den måten vil en oppnå varierende treningsgrunnlag (negative) ut fra årstider og lysforhold. En bør også vurdere muligheten for plassering av kamera mot en statisk bakgrunn.
Figur 43: Eksempel på hvordan vinklingen av kamera og statisk bakgrunn er tiltenkt.
• Omfattende test av «detekesjon av kjøretøy- og syklistprogram»
Programmene bør gjennomgå omfattende og grundig testing etter videreutviklingen, under alle tenkelige senarioer.
7. KONKLUSJON
Det er i henhold til resultatmålene gjort følgende.
• Utvikle forslag til løsning for sektorinndeling og deteksjon av kjøretøy.
Satt sammen en løsning bestående av kamera, ruter og egenutviklet konsollprogram, samt tilrettelagt for mulig utvidelse med sektorinndeling. Videre er løsningen funksjonstestet samt testet treffprosent for feiltelling av kjøretøy.
• Utvikle forslag til løsning for deteksjon av syklist.
Benyttet «train cascade» og «haar cascade» for trening av «classifier», samt utviklet konsollprogram. Programmet innhenter bilde fra «deteksjon av kjøretøy» prog- rammet og xml-fil for søk etter syklist i bildet. Testingen viste treff på alle syklister under test.
• Utvikle brukergrensesnitt for fremvisning av data.
Designet og konstruert brukergrensesnitt med forskjellige funksjonaliteter.
Eksempelvis videostrøm, valg av sektor, antall kjøretøy og status for vifte og belysning.
Statens vegvesen ønsker økt trafikksikkerhet, reduksjon av energiforbruk og bredere trafikkovervåking i tunneler. Ved å ta i bruk optisk kamera med bildebehandling har en et system med stort potensiale for utvidelse innenfor funksjonaliteter som eksempelvis tekstgjenkjenning. Det er også en verdig erstatter for induktive sløyfer som gradvis fases ut. En har mulighet til å bruke samme kamera til deteksjon av kjøretøy og syklist, dog er ikke dette anbefalt for videre utvikling av systemet. Det bør brukes separate kameraenheter for hver av deteksjonene, grunnet foreslått kameravinkel på syklist.
Ved å ta i bruk løsningene på resultatmålene presentert i denne oppgaven og videre utvikling av systemet, mener vi i SMT-gruppen at Statens vegvesen på sikt vil oppnå effektmålene.
Det er arbeidet strukturert og systematisk gjennom hele prosjektperioden for å tilegne oss faglig kunnskap innenfor automatiseringsteknikk, spesielt bildebehandling og programmering. Vi har underveis oppnådd større erfaring innenfor prosjektering, gjennomførelse og dokumentering av ett prosjekt, og anser våre prosessmål som oppfylt.
