EESTI INFOTEHNOLOOGIA KOLLEDŽ

Erik Kaju

REAALAJA VIDEOTÖÖTLUSE JÕUDLUSE PARENDAMINE

EESTI INFOTEHNOLOOGIA KOLLEDŽI ROBOOTIKAKLUBI

BOTMASTER PLATVORMI BAASIL

Diplomitöö

INFOTEHNOLOOGIA SÜSTEEMIDE ARENDAMISE ÕPPEKAVA

Juhendaja: Valdur Kaldvee

Tallinn/Stockholm 2013

AUTORIDEKLARATSIOON

Deklareerin, et käesolev diplomitöö, mis on minu iseseisva töö tulemus, on esitatud Eesti

Infotehnoloogia Kolledžile lõpudiplomi taotlemiseks Infosüsteemide arendamise erialal.

Diplomitöö alusel ei ole varem eriala lõpudiplomit taotletud.

Autor E. Kaju ..............................

(allkiri ja kuupäev)

Töö vastab kehtivatele nõuetele

Juhendaja V. Kaldvee ................................

(allkiri ja kuupäev)

2

Sisukord

Lühendite ja mõistete loetelu.....................................................................................................6

Sissejuhatus..............................................................................................................................10

1 Analüüs................................................................................................................................13

1.1 Botmaster platvormi tehniline spetsifikatsioon............................................................13

1.1.1 Tarkvara................................................................................................................13 1.1.2 Riistvara................................................................................................................13

1.2 Videotöötlus ning selle alamprotsessid........................................................................14

1.2.1 Botmasteri videotöötluses kasutatavad värviruumid............................................14 1.2.1.1 YUV..............................................................................................................14 1.2.1.2 RGB(BGR)...................................................................................................15 1.2.1.3 HSL...............................................................................................................16 1.2.1.4 Ühekanaliline binaarne pilt...........................................................................16

1.2.2 Videotöötluse elutsükkel.......................................................................................17 1.2.3 Initsialiseerimine..................................................................................................18

1.2.3.1 HSL värviruumi otsingutabeli genereerimine ning pikslite konverteerimine RGB ja HSL värviruumide vahel...............................................................................18 1.2.3.2 Videohaaramise struktuuri sidumine kaameraga .........................................19 1.2.3.3 Videohaaramise struktuuri seadistamine.......................................................20

1.2.3.3.1 V4L seadistuste rakendamine................................................................20 1.2.3.4 Andmeladu masinnägemise saaduste hoiustamiseks....................................21

1.2.4 Kaadri töötlemine.................................................................................................21 1.2.4.1 Kaadri hankimine..........................................................................................21 1.2.4.2 ROI (Region of Interest) määramine............................................................22 1.2.4.3 Videotöötlusel kasutatavad pildiobjektid ja nende väärtustamine ..............22

1.2.4.3.1 IplImage iseloom...................................................................................23 1.2.4.3.2 Img........................................................................................................24

3

1.2.4.3.3 Work......................................................................................................24 1.2.4.3.4 Binary....................................................................................................24

1.2.4.4 Gaussi filtri rakendamine..............................................................................24 1.2.4.5 Objektide tuvastamine..................................................................................26

1.2.4.5.1 Golfipalli näide.....................................................................................26 1.2.4.5.2 Objektide tuvastamise protsessi kirjeldavad joonised..........................27

2 Praktiline teostus..................................................................................................................30

2.1 Videotöötluse jõudluse mõõtmise vahendi ning metoodika väljatöötamine ...............30

2.1.1 Nõuded.................................................................................................................30 2.1.2 Ajatemplite salvestamine......................................................................................31 2.1.3 Lahenduse disain..................................................................................................32 2.1.4 Tööriista ning selle rakendusliidese kasutamine..................................................33

2.2 Mõõtmise teostamine esialgse platvormi videotöötluse komponendi jõudlusele........35

2.2.1 Tulemused.............................................................................................................36 2.2.2 Hinnang tulemustele ning prioriteetide seadmine................................................40

2.3 Platvormi videotöötluse jõudluse parenduse võimalike metoodikate ja lähenemiste

analüüs.................................................................................................................................41

2.3.1 Üldine ..................................................................................................................41 2.3.2 Hüpotees - Kaadri hankimine...............................................................................42 2.3.3 Hüpotees - Objektide tuvastus..............................................................................43 2.3.4 Hüpotees - Kujutise kuvamine.............................................................................43

2.4 Lahenduste realiseerimine............................................................................................43

2.4.1 Mitmelõimeliste lahenduste realiseerimise võimalused Botmaster platvormis. . .43 2.4.2 Kaadri hankimine – mitmelõimeline lahendus.....................................................46

2.4.2.1 Eesmärk........................................................................................................46 2.4.2.2 Kontseptuaalne lahendus..............................................................................47

2.4.2.2.1 Ülevaade................................................................................................48 2.4.2.2.2 Takistused..............................................................................................48

2.4.2.3 Teostus – Realiseeritud lahendus..................................................................49 2.4.2.3.1 Põhimõte ning iseloomustus.................................................................50 2.4.2.3.2 Lahenduse tehnilised tunnusjooned......................................................51 2.4.2.3.3 Lahenduse väljatöötamine, silumine ning testimine.............................51 2.4.2.3.4 Lahendusega kaasnevad kõrvalmõjud süsteemile.................................52 2.4.2.3.5 Analüüs platvormi parendatud videotöötluse komponendi jõudlusele – mitmelõimeline lahendus......................................................................................53

2.4.3 Kujutise kuvamine – süsteemi paremaks jõudluseks optimeeritud lahendus ......56 2.4.3.1.1 Analüüs platvormi parendatud videotöötluse komponendi jõudlusele – optimeeritud kuvamise lahendus (+mitmelõimeline lah.)....................................57

3 Edaspidised väljavaated.......................................................................................................60

3.1 Objektide tuvastus - binaarpiltide väärtustamise optimeeritud lahendus.....................61

3.2 Objektide tuvastus – mitmelõimeline lahendus...........................................................63

4

4 Lõputöö tulemus..................................................................................................................64

5 Kokkuvõte............................................................................................................................65

6 Enhancement of real-time video processing performance based on EIK robotics club

"Botmaster" platform...............................................................................................................67

7 Kasutatud allikad.................................................................................................................70

8 Lisad.....................................................................................................................................72

5

Lühendite ja mõistete loetelu

Ajatempel Sümbolite jada (timestamp), mis tähistab kuupäeva ja/või aega, mis on seotud mingi kindla sündmusega. [1]

Amdahli seadus (Amdahl's Law) Matemaatiline arvutusviis, mille abil on võimalik välja selgitada maksimaalne eeldatav programmi jõudluse tõus, kui täiustatakse ainult teatud osa süsteemist.

API Rakendusliides, programmiliides, API-liides. Arvuti operatsioonisüsteemiga või rakendusprogrammiga määratud reeglistik, mille alusel rakendusprogramm kasutab operatsioonisüsteemi või teise rakendusprogrammi teenuseid.[2]

ATmega (Atmel megaAVR)

Atmel firma poolt toodetav mikrokontrollerite seeria .[1]

AVI (Audi Video Interleaved)

Multimeedia konteineri formaat. Avi fail võib sisaldada nii audio kui video andmeid ning võimaldab sünkroonset audio+video taasesitlust.

Binaarpilt vt. Kahendkodeeritud kujutis

Botmaster EIK Robootikaklubi roboti pilditöötlemise- ning juhtimisplatvorm.

CSV Komaeraldusega väärtused. Failivorming, kus andmebaasikirjed on üksteisest eraldatud komadega. [2]

EIK Eesti Infotehnoloogia Kolledž.

EIK Robootikaklubi 2002 aastal asutatud EIK üliõpilaste organisatsioon, mille üks peamisi eesmärke on osaleda Robotex võistlustel ja abistada võistluste korraldamisel. [1]

FireWire (IEEE1394) Jadasiini põhimõttel töötav kiire isokroonne andmeside liides, mis võimaldab andmete edastamist reaalajas. [1]

6

Fps Tele- või videopildi kaadrisageduse mõõtühik - kaadrit sekundis. [2]

Gaussi filter Gaussi filter on ribapääsfilter, millel on kellukakujuline sagedustunnusjoon. Gaussi filtri rakendamisel digitaalsele kujutisele ühtlustatakse läheduses olevate pikslite väärtused.

Gcc GNU kompilaator, millega on võimalik kompileerida C, C++, Objective-C, Fortran, Java, Ada, Go ja mitmetes teistes programmeerimiskeeltes loodud programme. [1]

GNU projekt 1984. aastal algatatud projekt, mille eesmärgiks oli luua UNIX- laadne operatsioonisüsteem, mis sisaldab ainult vaba tarkvara (GNU ei ole UNIX). [1]

GPL (litsents) General Public License - on enim levinud vaba tarkvara litsents, mis loodi GNU projekti jaoks. [1]

HSL Värviruum, kus värvid on defineeritud värvitooni, küllastatuse ja heleduse järgi. [1]

Intel Atom Intel-i poolt toodetud madala voolutarbega protsessorite tootemargi nimi. Intel Atom protsessorid on kasutuses väikest mõõtu mobiilsetes nutiseadmetes, mis vajavad kõrget arvutusvõimsust.

Intel Image Processing Library (IIPL)

OpenCV eelkäija - Intel-i arhitektuuri jaoks optimeeritud C teek, mis võimaldas teostada tüüpilisi pilditöötluse operatsioone. OpenCV C teegi programmiliides on jätkuvalt osaliselt identne IIPL-iga. [3]

Just-in-time initsialiseerimine

Objekti või mooduli initsialiseerimine teostatakse alles siis, kui seda vajatakse esimest korda. Esineb ka “lazy initialization” nime all.

Kaamera indeks Igale USB jadasiini või teise arvuti porti ühendatud kaamerale omistatakse OpenCV teegisisene järjekorranumber, mille abil määratakse, millisest kaamerast pilti/videovoogu lugeda.

Kahendkodeeritud kujutis

Kujutise kahendkodeerimine (image binarization) on masinnägemise protsess, mille abil kujutise pildimaatriksi andmed kahandatakse kahe võimaliku väärtuseni – 1 ja 0. (must ja valge) [4]

Kosteaeg Kosteaeg (latency) on aeg, mis kulub info jõudmiseks sisendist väljundisse (andurite lugemise, planeerimine). [1]

Krominantsus PAL-laadsete televisioonistandardite värvisignaali kodeerimismudelitele iseloomulik kanal, mis määrab kujutise värvi.

Luminents PAL-laadsete televisioonistandardite värvisignaali kodeerimismudelitele iseloomulik kanal, mis määrab kujutise heleduse.

LUT (Lookup-table) Vt. Otsingutabel

Make Utiliit, mis täidab Makefile failis kirjeldatud reeglite alusel erinavaid tegevusi. Kasutatakse tarkvara kompileerimise korralduste

7

automatiseerimiseks ja lihtsustamiseks. [1]

Makefile Spetsiaalse formaadiga fail, mis koos make utiliidiga aitab kompileerida ja hallata projekte. [1]

Masinnägemine MV(Machine vision) - kõrgtehnoloogia, mille eesmärgiks on masinale vahendada analoogselt elusolendi silmaga väliskeskkonna objekte, analüüsida nende objektide olemust ja kujundada masina otstarbekat tegevust nende objektide suhtes.

Matrox Imaging Library (MIL)

Laialdane tarkvaravahendite kogum, mis on mõeldud masinnägemise, kujutiste analüüsi ja meditsiinilise pilditöötluse tarkvara arendamiseks. Teegid toetavad C, C++, C# ja VisualBasic® programmeerimiskeeli. [5]

Monotoonne loendur Taimerites ning ajatembeldamiseks kasutatav loendur, mille näit kasvab vaid monotoonselt ning ei vähene iialgi. Loenduri väärtust ei saa ka muuta. [6]

OpenCV Open Source Computer Vision (OpenCV) on vabatarkvaraline reaalajas videotöötlemiseks mõeldud teek.

Otsingutabel (lookup-table, LUT) on andmete tabel arvutiteaduses, kuhu on salvestatud mingi funktsiooni väärtused, et asendada jooksvalt nende arvutamine [4].

Ov534 Linuxi driver, mis toetab PS3 Eye USB kaamerat. Nimetus tuleneb Omnivision OV534 USB-siinikiibist, mida kasutavad paljud veebikaamerad.

PAL Faasivaheldusega liin (Phase Alternation Line) - on üks kolmest maailmas enamlevinud televisoonistandardist. [2]

piksel(px) Tuletis sõnadest "picture" ja "element" - väikseim digitaalse kujutise element (punkt).

Pikslisügavus Pikslitele iseloomulik võimalike väärtuste amplituud. Näiteks 8-bitine pikslisügavus tähendab, et pikslil võib olla 2^8=256 erinevat väärtust.

Pildimaatriks Kujutise andmete (pikslite väärtused) esitamine andmemaatriksina.

PlayStation Eye (PS3 Eye)

Sony Playstation 3 mängukonsoolile loodud veebikaamera. [1]

POSIX Portable Operating System Interface – Unix operatsioonisüsteemi liides, mis kirjeldab ära, programmide ja operatsioonisüsteemide omavahelise suhtluse. [1]

Qmake Programm, mis automatiseerib Makefile loomise. [1]

Qt Platvormiülene tarkvaraarenduse raamistik, mis põhineb C++ programmeerimiskeelel.

Qt-OpenCV- Avatud lähtekoodiga reaalaja videovöö töötlemise platvorm.

8

Multithreaded Realiseeritud projekt põhineb Qt4, ja OpenCV C++ teekidel.

Raalnägemine Vt. Masinnägemine

RGB (BRG) Värviruum, kus kõik värvid tulevad kolme värvikanali (punane, roheline, sinine) liitmisel. [1]

Ring aquisition Masinnägemises kasutatav tarkvara disainimuster, mille kohaselt üldjuhul on kasutuses mitu vahepuhvrit kaadrite hoiustamiseks ning pidev tsükliline kaadrite hankimine kaamerast on eraldatud ülejäänud süsteemist.

Robotex Alates 2001. aastast toimuv rahvusvaheline robotite võistlus, mida korraldavad Tallinna Tehnikaülikool, Tartu Ülikool ning Eesti Infotehnoloogia Kolledž.

ROI ROI määrab, millist ala video kaadri peal töödeldakse.

SECAM Mäluga jadavärvid (Sequential Couleur Avec Memoire) - värvitelevisiooni standard

Semafor Paralleelprogrammeerimises nimetatakse semaforiks kaitstud muutujat (abstraktandmetüüpi), mida kasutatakse multiprotsessorkeskkonnas juurdepääsu piiramiseks jaosmälule. [2]

Singleton Tarkvara disainimuster, mille kohaselt klassi kuuluva(te) objekti(de) arv on rangelt piiratud ühele ning on ainult üks globaalne ligipääsupunkt. [7]

SVN Apache Subversion – vaba platvormiülene versioonihaldustarkvara.

Tehisnägemine Vt. Masinnägemine

UNIX 1969. aastal loodud hargtöötlusega, mitut kasutajat toetav, raudvarast sõltumatu operatsioonisüsteem.

USB Universaalne järjestiksiin (Universal Serial Bus) on levinud arvuti välissiini standard.

V4L, V4L2 (Video For Linux)

Video salvestamise programmiliides Linux keskkonnale. Toetab laia valikut riistvaralisi seadmeid.

Värviruum (värvimudel)

Abstraktne matemaatiline mudel, mis kirjeldab värvide esitamist aritmeetiliste korteežide abil. Enamasti on kolm või neli väärtust või värvikomponenti.

Video for Windows (VFW)

Vorming video- ja audioinformatsiooni salvestamiseks. Sellele vormingule vastavad failid on varustatud laiendiga *.AVI. [2]

YUV Televisioonis PAL-süsteemi juures kasutatav video värvisignaali kodeerimismudel (värvusruum). Y on heledus, U ja V on värvsussignaalid. [2]

9

Sissejuhatus

Eesti Infotehnoloogia Kolledži Robootikaklubi (EIK Robootikaklubi) on Eesti

Infotehnoloogia Kolledži (EIK) üliõpilaste organisatsioon, mis tegutseb aastast 2002 [8].

Klubi missiooniks on robootika ning teaduse populariseerimine. Põhiline fookus on robotite

ehitamisel. EIK Robootikaklubi osaleb aktiivselt rahvusvahelistel robotivõistlustel.

Traditsiooniliselt on üks nendest iga-aastaselt Eestis toimuv rahvusvaheline roboti võistlus

Robotex [9]. Robotite ehitus ning võistluseks ettevalmistamine on tudengite jaoks

mitmekülgselt arendav tegevus, sest protsessi käigus õpivad üliõpilased oma matemaatika-,

füüsika-, mehhaanika-, programmeerimise- ja elektroonikaalaseid teoreetilisi teadmisi

praktikas rakendama. Robotite ehitamine on meeskondlik tegevus, kus efektiivse töö

eelduseks on tihe koostöö ning teadmiste jagamine. Meeskonna liikmetel kujunevad välja

kindlad rollid, spetsialiseerumine ning kohustused.

EIK Robootikaklubi on aastate jooksul arendanud ainulaadset roboti juhtimisplatvormi

Botmaster [10], mis on kasutusel enamusel EIK Robootikaklubi kõrgema taseme robotitel.

Platvorm on väga paindlik ning võimaldab juhtida üksteisest täielikult erineva mehaanika ja

funktsionaalsusega roboteid. Platvormi tuum jääb samaks, kuid juhtloogika kohandamise teel

on võimalik lahendada erinevaid ülesandeid. Botmasteri platvormil põhinevad robotid on

10

täitnud erilaadseid eesmärke nagu näiteks toa koristamine, linnamaastikul navigeerimine või

võrkpalli ja jalgpalli mängimine [8].

EIK Robootikaklubi Botmaster juhtimisplatvormiga robotid on saavutanud silmapaistvaid

tulemusi rahvusvahelistel robotivõistlusel ning on läbi aegade olnud favoriidid roboti

võistlusel Robotex [8]. Konkurentide tase on väga kõrge ning platvormi edu jätkamine eeldab

arendajate pühendumust, jätkuvat täiustamist ning edasiarendust. Prioriteetsemad eesmärgid

on teha platvorm kiiremaks ja töökindlamaks.

Tänaseks on saavutatud olukord, kus robotites kasutatavad mehaanilised komponendid

ning elektroonika võimaldaksid ülesandeid lahendada oluliselt kiiremini. Samas

Botmaster platvormi masinnägemise komponent on olulisel määral roboti summaarset

jõudlust piirav tegur.

Käesolevas diplomitöös lahendatav probleem

Videotöötlus on arvutusmahukas ning ajakulukas protsess ning mobiilsete robotite

arvutusvõimsus on limiteeritud. On tarvis leida lahendusi, mis võimaldavad olemasoleva

arvutusvõimsuse juures saavutada kõrgemat efektiivsust video töötlemisel.

Robotite liikumiskiirus on piiratud Botmaster platvormi masinnägemise komponendi

kosteaja poolt. Botmasteri videotöötluse komponent on kriitilise tähtsusega ning reaalajas

töödeldav videovoog on roboti puhul tähtsaimaks sisendiks ümbritseva keskkonna kohta.

Robot võtab kaamerast pildi, töötleb seda ning analüüsib tuvastatud objekte. Juhtloogika

tasandil võetakse analüüsi tulemuste põhjal vastu otsuseid, kuidas konkreetses situatsioonis

käituda. Ühe videokaadri töötlemiseks kuluva aja vähendamine võimaldab saavutada

märgatavalt kiiremat roboti reageerimisvõimet, suuremaid sõidukiiruseid, sujuvamaid ning

optimaalseid liigutusi.

Käesoleva diplomitöö eesmärgid

Analüüsitakse ning realiseeritakse meetodid "Botmaster" platvormi masinnägemise

komponendi jõudluse tõstmiseks.

11

Autori eesmärgiks on viia läbi põhjalik uuring Botmasteri videotuvastuse komponendile ning

pakkuda välja võimalusi süsteemi kosteaja vähendamiseks. Kaalutleda erinevaid

realiseeritavaid lahendusi ning valida neist välja sobivaimad. Kavas on realiseerida valitud

lahendus ja seada edasised plaanid platvormi masinnägemise komponendi arenduseks.

Käesoleva diplomitöö tulemus on suunatud eelkõige Botmaster platvormi kasutajatele ehk

roboteid arendatavatele EIK Robootikaklubi liikmetele, kes osalevad robootika võistlustel.

Soovi korral saavad lõputöö tulemusi ära kasutada ka teised, kes tegelevad reaalaja

videotuvastuse/töötluse efektiivsusega ning analoogsete kosteaegade vähendamisega.

Botmaster tarkvara on traditsiooniliselt olnud avatud lähtekoodiga ning EIK Robootikaklubi

jagab soovijatele programmide algtekste.

Diplomitöös sisalduvad peatükid

Sissejuhatusele järgnevas analüüsi osas annab autor ülevaate masinnägemise ja reaalaja

videotöötluse üldistest põhimõtetest. Tehakse ülevaade EIK Robootikaklubi Botmaster

platvormi ülesehitusest, tehnilistest iseärasustest ning funktsionaalsusest. Keskendutakse

platvormi videotöötluse komponendile. Lugejal tekib ettekujutus kogu tehisnägemise

protsessist alates geomeetrilisest optikast ning kujutise kandumisest kaamera

maatrikssensorile ja lõpetades digitaalselt pildilt füüsiliste objektide tuvastamiseks

kasutatavate algoritmidega raalnägemise rakenduses.

Autor analüüsib potentsiaalseid lahendusi eelnevalt püstitatud probleemile. Uurib

analoogseid lahendusi mujalt maailmast. Autor annab hinnangud ning prioriseerib erinevad

võimalikud lahendused ja otsustab sobivaimate kasuks.

Realiseerimise osa kajastab diplomitöö praktilist poolt. Autor tutvustab Botmaster platvormi

masinnägemise mooduli jõudlustestimiseks loodud metoodikat, annab ülevaate

arendusprotsessist ning võtab kokku tehtud töö. Samuti pannakse paika tulevikuplaanid

Botmaster platvormi videotöötluse komponendi edasiseks arendamiseks.

Kokkuvõttes antakse ülevaade tehtud analüüsist, tööst ja tulemustest.

12

1 Analüüs

1.1 Botmaster platvormi tehniline spetsifikatsioon

1.1.1 Tarkvara

• Platvormi tarkvara arendamiseks kasutatavad programmeerimiskeeled: C++, C

• Välised teegid: OpenCV 2.0 – C, Qt 4 – C++

• Haldamine: svn, make, qmake ja gcc

• OS: UNIXi-laadsed operatsioonisüsteemid (Linux Ubuntu 10.04)

1.1.2 Riistvara

• Platvormi tarkvara ühilduvus riistvaraga:

◦ Juhtarvuti: moodsate arvutite seas piirangud puuduvad (Intel® Atom™ D525)

◦ Mikrokontroller: paljud 8-bitised mikrokontrollerid. (ATmega seeria kontrollerid)

◦ Kaamera: kõik OpenCV poolt toetatud (Playstation Eye USB 2.0 + ov534 driver)

◦ Täiturid: lai valik servo- ning alalisvoolumootoreid ning muud elektrooniliselt

juhitavad komponendid.

◦ Andurid: lai valik analoog- ning digitaalandureid

NB! Sulgudes on märgitud antud diplomitöö arendamisel ning testimisel kasutatud komponendid. Edaspidi mõeldakse „Botmaster platvormi“ all vaid tarkvara.

13

1.2 Videotöötlus ning selle alamprotsessid

Süsteemi parendamiseks on kõigepealt vaja anda ülevaade tarkvara komponentidest ja

ülesehitusest. Antud peatükk annab lugejale ettekujutuse tüüpilistest põhimõtetest, mida

kasutatakse tehisnägemise funktsionaalsuste loomisel.

1.2.1 Botmasteri videotöötluses kasutatavad värviruumid

1.2.1.1 YUV

Sony Playstation Eye USB-kaamera väljastab videovoogu YUV värviruumis [11]. Selle

formaadi ajalugu ulatub aegadesse, mil sündis värviline televisioon. Algne YUV kodeering oli

loodud eesmärgiga olla ühilduv nii mustvalgete teleritega kui ka värviliste analoogidega.

YUV mudeli esimene kanal Y, mida nimetatakse luminentsiks sisaldab endas infot

pildipunktide heleduse kohta [13]. Minimaalne väärtus on must ja maksimaalne valge.

Eraldades videovoost ainult selle kanali on tulemuseks mustvalge kujutis. Kaks ülejäänud

kanalit UV (krominantsus) sisaldavad infot pildipunktide värvitooni kohta [14].

YUV on iseloomulik PAL ja SECAM analoogtelevisiooni standarditele ning laialdaselt

kasutatav ka digitaalsetes süsteemides. YUV värvimudeliga kujutise kodeerimine või

dekodeerimine RGB värviruumi on suhteliselt lihtne ja selle tõttu on mõlemad standardid

tänapäeval laialdaselt kasutusel. Botmasteri tasandil toimub YUV-ist RGB-sse teisendamine

OpenCV teegi poolt automaatselt [11]. Konversioon RGB-sse toimub kohe peale kaadri

kaamerast lugemist. Botmasteri algoritm seda protsessi ise ei kontrolli. Koheselt saadakse

kätte RGB värviruumis pilt, kuid on teada, et kaamera ning OpenCV teegi madalamates

kihtides toimub automaatne YUV-RGB konversioon. Vajame edaspidiseks opereerimiseks

RGB pilti.

14

Joonis 1: YUV värviruumi illustreeriv pilt. 1 - YUV/RGB kujutis 2 - Y kanal (luminents) 3,4 – UV kanalid (krominantsus) [12]

1.2.1.2 RGB(BGR)

RGB on tänapäeval tuntuim ning enim kasutatav värviruum. Selle kasutamine on levinud

arvutimonitorides, projektorites, televiisorites ning enamuses teistes seadmetes, mis kuvavad

inimsilmaga nähtavat pildikujutist. RGB värviruum tähendab, et iga värvilist pildipunkti

(pikslit) kirjeldatakse kolme värvikanali abil – punane (Red), roheline (Green) ja sinine

(Blue) [14]. Iga inimsilmaga eristatavat värvi kirjeldatakse nende kolme värvi

kombinatsiooniga. Seetõttu on RGB pilt silmale nähtav värvilisena.

Olenevalt värvisügavusest on igal värvikanalil kindel arv astet, mis kirjeldavad vastava värvi

intensiivsust. Botmasteri platvormi puhul saadakse RGB värviruumis pilt OpenCV

masinnägemise teegi vahendusel pildi laadimisel kaamerast. Botmasteri puhul on kasutatava

RGB värviruumi värvisügavus kaheksa bitine, ehk ühe piksli ühele värvikanalile vastab 256

(0-255) võimalikku täisarvu (2^8=256) [14]. Kolmekanalilises ja kaheksa bitise

pikslisügavusega RGB värviruumis on 256×256×256=16777216 erinevat värvitooni [14].

15

Joonis 2: Lihtne illustratsioon sellest, kuidas kolme värvi abil (Punane, Roheline, Sinine) saadakse muid värvispektri toone [15]

1.2.1.3 HSL

HSL värviruumi peetakse inimmõistusele kõige

enam arusaadavamaks. Levinud standardi järgi

määrab esimene kanal H (Hue) värvitooni. Toon

määratakse vahemikus 0°-359° [17]. Teine kanal S

(Saturation) määrab värvi intensiivsuse vahemikus

0-100% - 0 tähendab mustvalget varjundit ning 100

kõige eredamat [17]. Kolmas kanal L (Lightness)

määrab heledust ning samuti vahemikus 0-100% - 0

tähendab täiesti musta värvi ning 100 valget [17].

Botmasteris on HSLi puhul kasutusel 8-bitine

värvisügavus. See tähendab, et iga piksli H, S ning

L väärtusele vastab number vahemikus 0-255 [17].

1.2.1.4 Ühekanaliline binaarne pilt

Objektide tuvastamisel on kasutusel ka lihtne ühekanaliline

värviruum. Tarkvaras kasutatava OpenCV teegi iseärasustest

tulenevalt ning ülejäänud värviruumidega (RGB ja HSL)

ühildumise eesmärgil on ka siin pikslisügavuseks 8 bitti, kuid

tegelikkuses on programmi töös kasutatavad pikslite

väärtused vaid vahemikus 0-1.

Botmasteris kasutatav binaarne pilt on kahendkodeeritud

representatsioon HSL värviruumis olevast kujutisest (image

binarization) [4]. Tegemist on eriotstarbelise värviruumiga,

mille abil on mugav märkida tuvastatud alasid või huvi

pakkuvaid regioone [4].

16

Joonis 4: Illustreeriv lihtsustatud joonis binaarsest värviruumist. Iga tabeli ruut illustreerib ühte pikslit. Märgitud aladel on pikslite väärtuseks ühed, muudel aladel on nullid.

Joonis 3: HSL värviruumi iseloomustav joonis [16]

1.2.2 Videotöötluse elutsükkel

17

Joonis 5: Botmasteri käivitamise alguses teostatakse mitmed ühekordsed operatsioonid

Joonis 6: Iga kaadri kohta teostatakse rida korduvaid operatsioone, seejärel kuvatakse tulemus.

1.2.3 Initsialiseerimine

1.2.3.1 HSL värviruumi otsingutabeli genereerimine ning pikslite

konverteerimine RGB ja HSL värviruumide vahel

Botmasteri objektide tuvastamiseks kasutatakse kujutist HSL värviruumis. Värvitooni

väärtuse, värvi erksuse ning heleduse põhjal on kõige mugavam tuvastada lihtsamaid

erivärvilisi figuure. Algne RGB värvimudeliga pilt tuleb konverteerida HSL-i ning seda

võimaldab OpenCV teegi funktsionaalsus. Funktsioon cvCvtColor toetab konverteerimist

mitmete erinevate värviruumide vahel [11]. Jõudluse seisukohast on paraku oluliseks

probleemiks antud protseduuri suur arvutusmahukus.

RGB -> HSL konverteerimisel Botmasteris kasutatavate 8-bitiste pikslisügavuste puhul R, G

ja B väärtused konverteeritakse ujukoma kujule ning skaleeritakse vahemikku 0 kuni 1.

Konverteerimisel teostatavad arvutused [17]:

Juhul, kui , siis . Väljundväärtuste kuju: ,

, .

Seejärel väärtused konverteeritakse 8-bitisele pikslisügavusele iseloomulikule kujule:

(väärtuste vahemik 0-255)

OpenCV vahendite kasutamine ei ole kindlasti ainus võimalik viis. Botmasteri loojad on

katsetanud ka konversiooni, kus arvutused teostati täisarvudega ning jõudlus oli märgatavalt

parem.

18

Samas moodsate protsessorite jaoks ei ole ära kirjeldatud ujukomaarvutus sugugi suur

väljakutse. Jõudluse kadu on seotud sellega, et näiteks digitaalse pildi puhul resolutsiooniga

640x480 pikslit, tuleb BGR->HSL konverteerimisel sooritada arvutustehted iga piksli kohta

eraldi, ehk 307 200 korda järjest. Jõudluse tõstmiseks kasutatakse Botmasteris spetsiaalset

otsingutabelit [4].

Otsingutabel (lookup-table, edaspidi LUT) on andmete tabel arvutiteaduses, kuhu on

salvestatud mingi funktsiooni väärtused, et asendada jooksvalt nende arvutamine [4]. Antud

kontekstis on tegu tabeliga, mis sisaldab samale värvitoonile vastavate BGR ja HSL väärtuste

kombinatsioone. Programmi tööajas on otsingutabeli kasutamisest tulenev säästmine väga

suur, sest mälust andmete lugemine on kordades kiirem, kui seda on BGR->HSL arvutustehe.

Otsingutabeli väärtuste paarid arvutatakse programmi initsialiseerimise hetkel, mistõttu on

programmi käivitamine mõnevõrra aeglasem. Tabel salvestatakse operatiivmällu ning

hoitakse seal kuni programmi töö lõpuni. Tabeli maht on ligikaudu 50 megabaiti.

Otsingutabelis on 16777216 kombinatsiooni, ehk kaetud on absoluutselt kõik võimalikud 8-

bit pikslisügavusega RGB toonid.

Seega RGB pildiobjekti konverteerimisel HSL-i, Botmaster programmi töö käigus

arvutustehteid ei teostata, vaid võetakse soovitud HSL piksli väärtus suurest eelarvutatud

tabelist.

1.2.3.2 Videohaaramise struktuuri sidumine kaameraga

OpenCV C teegi videohaaramise (video capture) funktsioonid kasutavad struktuuri

CvCapture, millel ei ole avalikku liidest ning on kasutusel OpenCV funktsioonides

parameetrina [11]. Defineeritud CvCapture struktuur väärtustatakse OpenCV funktsiooniga

cvCaptureFromCAM [18], mis nõuab programmeerijalt teadmist, mis indeksiga kaamerat

tuleb kasutada. Juhul, kui arvutiga on ühendatud ainult üks kaamera, siis tavapärases

olukorras on kaamera indeksiks 0. CV_CAP_ANY[11] või lihtsalt -1 väärtusega atribuut

võimaldab valida esimese ettejuhtuva kaamera indeksi. CvCaptureFromCAM funktsioon

eraldab mälu ning initsialiseerib CvCapture struktuuri kindla kaamera videovoo lugemiseks.

OpenCV C teek toetab nelja erinevat kaameraliidest: Video for Windows (VFW), Matrox

Imaging Library (MIL) Windows keskkonnas ning V4L (Video For Linux) ja FireWire

(IEEE1394) [18]. Hetkel kasutatakse V4L võimalusi.

19

1.2.3.3 Videohaaramise struktuuri seadistamine

1.2.3.3.1 V4L seadistuste rakendamine

Videohaaramise funktsioonide ühiseltkasutataval CvCapture [11] struktuuril on lai valik

seadistamise võimalusi. Seadistamine toimub cvSetCaptureProperty [11] funktsiooni abil,

mis OpenCV teegi tasemel tähendab objekti omaduste muutmist, mis omakorda mõjutab

seda, kuidas riistvaralisel tasemel juhitakse kaamera registreid. See võib tähendada seda, et

kõik OpenCV teegi poolt pakutavad võimalused ei pruugi igal kaameral edukalt rakenduda

ning töövõimeliste seadistuste valik on piiratud kaamera draiveri võimalustega. Botmasteri ja

PS3 Eye kaamera puhul see väljendub selles, et seadistame edukalt kaamerast saadava pildi

mõõtmeid, kuid puudub võimalus OpenCV vahenditega juhtida kaamera kaadrisagedust.

Pildi mõõtmete seadistamiseks kasutame argumente CV_CAP_PROP_FRAME_WIDTH

(kaadri laius) ning CV_CAP_PROP_FRAME_HEIGHT (kaadri kõrgus) [18]. Tähtis on

kasutada vaid selliseid väärtuseid, mis on aktsepteeritavad kaamera ning draiveri poolt. PS3

Eye kaamera on võimeline töötama kahe erineva resolutsiooniga – 320x240 ning 640x480

[19]. Teistsuguste väärtuste kasutamine ei rakendu.

1.2.3.3.1.1 Kaamera ov534 draiveri täiendus

Sony Playstation Eye USB kaamera kasutamiseks Linux keskkonnas on vaja spetsiaalset

draiverit – ov534 [19]. See on GNU GPL litsentsiga levitatav draiver, mille lähtekood on

avalik. Kaamera ning draiver toetavad kaadrisagedust vahemikus 15-60fps resolutsiooniga

640x480px ning 30-125fps resolutsiooniga 320x240px. OpenCV vahenditega ei olnud

võimalik Botmaster rakendusest sättida kaamera videovoo kaadrisagedust (V4L sätestus)

ning resolutsiooni määramisel rakendus vaikimisi sagedus 30fps. Üks võimalik lahendus oli

täiendada ov534 draiverit selliselt, et see toetaks ainult meile vajalikku režiimi 640x480 ning

60fps. (Maksimaalne võimalik kaadrisagedus suurima resolutsiooniga) Sellise muudatuse

teostamine osutus väga lihtsaks. Nimelt ov534 draiveri lähtekoodis on videovoo režiimid

kahes massiivis koos vajalike registrite väärtustega. Ebavajalike režiimide

väljakommenteerimine piirab draiveri funktsionaalsust nii nagu Botmasteris vaja oleks.

Ainsaks võimalikuks kaadrisageduseks 640x480p resolutsiooni juures on nüüd 60 fps ning

kadus vajadus rakendada seadistusi V2L vahendite abil.

20

1.2.3.4 Andmeladu masinnägemise saaduste hoiustamiseks

Videopildil leiduvate esemete tuvastamisel luuakse erinevaid objekte, mida hiljem

kasutatakse roboti juhtloogikas otsuste langetamiseks. Need on erinevad OpenCV objektid

nagu cvSequence, cvContour, cvGraph jne [11][18]. Kuna kaadri puhul ei ole võimalik ette

ennustada, mis mahus kasulikku infot pildilt hangitakse, siis tuleb arvestada, et salvestatavad

andmestruktuurid on dünaamiliselt kasvavad. Mainitud OpenCV andmestruktuuride

salvestamiseks on teegis realiseeritud spetsiaalne objekt cvMemStorage [11]. CvMemStorage

kujutab endast sarnase suurusega mäluplokkide kogumit. Struktuur CvMemStorage sisaldab

endas infot alumise ning ülemise mäluploki kohta. Samuti infot ühe ploki suurusest ja

ülemise ploki vaba mälu kogust baitides. Alumine mäluplokk tähistab andmekogumi algust

ning ülemine tähistab hetkel kasutatavat, kuid tõenäoliselt mitte viimast andmekogumis.

Kõiki mäluplokke alumisest ülemiseni peetakse täielikult hõivatuks ning ülemist poolikult

hõivatuks. Juhul kui mäluplokid saavad otsa, siis reserveeritakse dünaamiliselt mälu uue

ploki jaoks või laenatakse mäluplokk teiselt CvMemStorage struktuurilt, mida päritakse. See

info ei ole programmeerijale üldjuhul vajalik, sest OpenCV teek teostab mäluhaldust

automaatselt. Sellest hoolimata võib rakenduse jõudluse mõjutamise eesmärgil printsiibi

tundmisest kasu olla, sest CvMemStorage konteineri defineerimisel on võimalik määrata ühe

mäluploki andmemaht. See mõjutab otseselt seda, kuidas hakkab toimima dünaamiline

mäluhaldus. Botmasteris defineeritakse CvMemStorage objekt vaikimisi ploki suurusega

64K. Konteineri defineerimiseks kasutatakse funktsiooni cvCreateMemStorage [11].

1.2.4 Kaadri töötlemine

1.2.4.1 Kaadri hankimine

Roboti tehisnägemise elutsükkel algab sellega, et USB kaamerast loetakse uus pildikaader.

See operatsioon teostatakse OpenCV C teegi funktsionaalsusega cvQueryFrame, mis on

tegelikult omakorda kombinatsioon funktsioonidest cvGrabFrame ja cvRetrieveFrame [11].

Esimene on kiire ja optimeeritud viis kaadri eraldamiseks kaamera puhvrist või AVI videost.

Selle funktsiooni eesmärgiks on maksimaalne võimalik kiirus. Hangitud kaader hoiustatakse

teegisiseselt ning see ei ole programmeerijale kättesaadav. Saadud kaader võib olla (olenevalt

21

kaamera/draiveri iseloomust) tihendatud (compressed). CvRetrieveFrame võimaldab

cvGrabFrame funktsiooniga haaratud kaadrile ligi pääseda ning see funktsioon tagastab

mäluviite kaadri objektile. Seega cvQueryFrame oli loodud programmeerija töö

lihtsustamiseks ning koodiloetavuse parandamiseks, sest ühe funktsiooniga täidetakse kaks

eraldiseisvat ülesannet [18]. Ühe kaameraga opereerimisel, nagu Botmasteri puhul, need kaks

käsklust ongi enamasti järjestikuselt teostatavad. Eraldi kasutatakse neid keeruliste

algoritmide puhul sünkroniseerimiseks juhul, kui videokaadreid loetakse samaaegselt

mitmest kaamerast. Botmasteris hetkel selle järgi vajadust ei ole.

1.2.4.2 ROI (Region of Interest) määramine

ROI määrab selle, millist ala video kaadri peal töödeldakse [17][4]. ROI seadistamiseks on

OpenCVs funktsioon cvSetImageROI [18][11]. ROI rakendatakse pildiobjektile ning ala

mõõtmed määratakse nelja koordinaadiga, ehk määratav töödeldav pind on

ristkülikukujuline. Keerulisemate ROI kujundite määramiseks on võimalik kasutada

kombinatsioone erinevatest ristkülikutest. Enamus OpenCV pilditöötluse funktsioone

arvestavad seadistatud ROI-ga, näiteks kõik pikslikoordinaadid pildi töötlemisel arvutatakse

ROI ristküliku ülemisest vasakust nurgast, mitte kaadri enda omast. ROI seadistust on

võimalik muuta rakenduse töö käigus – näiteks saab erineval ajahetkel kasutada erisugust

ROI väärtust või määrata individuaalne ROI erinevate objektide tuvastamiseks. ROI

kasutamisega on võimalik tõsta videotöötluse jõudlust, sest pildikaadrite osaline töötlemine

tähendab väiksemat töödeldavate pikslite arvu.

1.2.4.3 Videotöötlusel kasutatavad pildiobjektid ja nende väärtustamine

Selleks, et töödelda pilti programmiliselt, on olemas spetsiaalsed struktuurid/objektid, mille

abil saab igat videovoo pilti käsitleda iseseisva instantsina. OpenCV C teegis, mida kasutab

Botmaster, on selleks struktuuriks IplImage [11][18]. Erinevalt enamusest OpenCV

terminitest ei alga see “cv” lühendiga. Põhjus seisneb selles, et IplImage pärineb teegist, mis

oli OpenCV eelkäija – Intel Image Processing Library[3][18]. OpenCV uuem alternatiiv on

CvMat [11], mis on väga sarnane, kuid veel ei eksisteerinud ajahetkel, mil arendati esimest

Botmasteri prototüüpi.

22

1.2.4.3.1 IplImage iseloom

IplImage ise on vaid päis pildi kuvandi füüsilistele andmetele. See koosneb kahest osast –

mäluviide pildile ning meta-andmed, mis iseloomustavad kaadrit [18].

ImageData

Kõige tähtsam struktuuri koostisosa on imageData, mis on char tüüpi viit pildi pikslite

tõelistele väärtustele.

meta-andmed

Struktuuris on 21 erinevat parameetrit, mis iseloomustavad kujutise (imageData) tehnilisi

näitajaid. Botmasteri arendaja seisukohast on tähtsamad neist:

• Pikslisügavus (depth). Näiteks kasutades parameetrit IPL_DEPTH_8U, mis määrab

vahemikuks 8-bitise unsigned integeri, on ühe piksli väärtuse võimalik amplituud 0 ja

255 vahel. See on väikseim võimalik vahemik. Alternatiiviks on signed ja unsigned

tüüpi kuni 32-bitised integerid või koguni 64-bitine double-precision floating point.

Botmasteris on kasutusel pikslite väärtused vahemikus 0 kuni 255.

• Kanalite arv (nChannels). Pildi kanalite arv. Üldjuhul määrab see värviruumile

iseloomulikud kanalid, näiteks RGB värviruumi puhul on kolm kanalit – punane,

roheline, sinine. Enamus OpenCV funktsioone on loodud opereerimiseks kuni

neljakanaliste piltidega.

• Kanalite järjestus (dataOrder). Parameeter määrab selle, mis mustri järgi hoiustatakse

infot pildi pikslite kohta. Vaikimisi on andmete paigutus sektsioneeritud kindlas

järjekorras jadamisi, see näeb välja nii: . Alternatiiviks on

kanalite üksteisest eraldamine.

• Algupära (origin). Parameeter määrab, kust alustatakse piksli-koordinaatide

arvestamist – vasak ülemine serv või vasak alumine. Viimane on saanud nimeks

Windows bitmap style ning seletab ära oma päritolu.

• Laius (width) – Pildi laius pikslites.

• Kõrgus (heigth) – pildi kõrgus pikslites.

• ROI – Region of interest koordinaadid. NULL väärtus tähendab, et ROI on kogu pildi

ulatuses.

23

1.2.4.3.2 Img

Botmasteris kasutatav IplImage kujutise objekti viit on kasutusel kogu teostatava

videotöötluse elutsükli vältel. See väärtustatakse viitega pildile, kui kaamerast võetakse

kaader. Sisuliselt on tegemist RGB värviruumis kaadri toorikuga, mis on lähtematerjal pildi

töötlemiseks genereeritavate muude pildimaatriksite loomisel - work ja binary. Samuti

kasutatakse seda objekti pildi kuvamiseks tsükli lõppfaasis. Kõik lisainformatsioon, mis

Botmasteris kaadrile juurde joonistatakse (väravate piirid, pallide asukohad, statistiline tekst

jõudluse kohta jms) rakendatakse just sellele IplImage objektile.

1.2.4.3.3 Work

Pildimaatriks ‘work’ on samuti IplImage objekti viit. See on koopia ‘Img’ maatriksist, kuid

on eelpool mainitud LUT otsingutabeli abil konverteeritud kolmekanalilisse HSL värviruumi.

Pikslite värvitooni, heleduse ja värviküllastuse alusel tuvastatakse selle pildimaatriksi pealt

otsitavad objektid. Leitud objektide asukohad salvestatakse ülal mainitud spetsiaalsesse

andmelattu ning ‘Img’ maatriksile joonistatakse vajadusel info objektide asukoha kohta.

1.2.4.3.4 Binary

‘binary’ on lihtne ühekanalilise värviruumiga pildimaatriks, mille ainsad võimalikud

kasutatavad pikslite väärtused on kas nullid või ühed. See on mõeldud ‘work’ pildiobjekti

abistamiseks. Kui HSL värviruumi abil tuvastatakse objektide asukohad, siis binaarsele

maatriksile need märgitakse. Nullid määravad selle ala, kus otsitavat objekti ei ole ning ühed

määravad selle ala, kus on tuvastatud objekt.

1.2.4.4 Gaussi filtri rakendamine

Robotitel laialdaselt kasutatava PS3 Eye USB-kaamera videopildil esineb tihti teralisust ehk

müra. See on tingitud sellest, et siseruumides jaotub valgus ebaühtlaselt, kaamera sensor on

mõõtmetelt väike ning kaamera säriaeg on lühike. Samuti põhjustavad pildil müra roboti

elektroonilised komponendid, mis tekitavad sensorile elektrilisi laenguid. Kujutise teralisus

takistab pildi töötlemisel objektide tuvastamist. Lihtsalt öeldes müra tõttu tuvastusalgoritmid

leiavad kujutiselt palju väikeseid objekte, mida tegelikult ei eksisteeri. Masinnägemises

kasutatakse teralisuse vähendamiseks udustamist [17][4].

24

Botmasteris rakendatakse pildile gaussi filter, mis on arvutusmahult sobivaim viis mürast

vabanemiseks. Gaussi filtriga silutakse pildimaatriks ‘Work’, sest see on edaspidi sisendiks

teiste maatriksite genereerimisel. Gaussi filter rakendatakse OpenCV vahendite abil.

[20][21]

25

Joonis 7: Müra samasugusel kujutisel erineva sensori valgustundlikkuse (ISO) puhul[20]

Joonis 8: Gaussi filtri rakendamine offset tehnoloogiaga trükitud mustvalgele pildile[21]

1.2.4.5 Objektide tuvastamine

Olenevalt robotivõistluse ülesannetest, muutub igal korral ka raalnägemise funktsionaalsus,

eriti just objektide tuvastamise poolel. Erinevat tüüpi objektide leidmiseks on eraldi

algoritmid, kuid üldised kasutatavad printsiibid on sarnased. Tuvastamiseks kasutatakse

OpenCV masinnägemise funktsioone. Objektide ära tundmiseks kasutatavad parameetrid on

HSL värviruumis pikslitele iseärased tunnused - värvi toon, küllastus ja heledus [4]. Värvi

alusel kindlaks tehtud kontuurid sorteeritakse välja pindala ning kuju alusel. Botmasteri

programmi tasandil kasutatakse värvi tuvastamiseks ülal mainitud pildimaatriksit ‘work’.

Operatsioonideks leitud kontuuridega ja nende füüsiliste omaduste töötlemiseks kasutatakse

pildimaatriksit ‘binary’.

1.2.4.5.1 Golfipalli näide

Golfipalli tuvastamisel on värvuse tasandil tegemist konkreetse oranži värvitooniga, millele

lisanduvad kindel sobiv küllastus ja erksus. Väliskeskkonna valgustus on HSL-i kanalite

puhul kõige enam mõjuv tegur. Seetõttu ei kasutata masinnägemiseks staatilisi väärtuseid,

vaid on kindlad vahemikke, mis võivad sobida. Sobiva värvusega kontuuridest lähtuvalt, on

golfipalli tuvastamise algoritmis realiseeritud vaid ümarate objektide aktsepteerimine.

Pindala poolest on võimalikul pallil konkreetne väärtuste vahemik. Liiga suur tuvastatud

oranž pall on tõenäoliselt mingi viga, liiga väike võib olla lihtsalt müra. Pildi moonutuste

tõttu tohib nähtav pall olla ka ovaalse kujuga. Realiseeritud on ka piir, mis määrab, kus

ovaalsus läheb üle sirgjooneks. Algoritm aktsepteerib ka poolringikujulisi objekte, sest pall

võib olla näiteks osaliselt kaadrist väljas või paista välja mõne muu objekti, näiteks

vastasroboti tagant.

26

1.2.4.5.2 Objektide tuvastamise protsessi kirjeldavad joonised

27

Joonis 9: #1 Kaamerast saadud RGB värviruumis kujutis kirjutati “Img" objekti

Joonis 10: #2 "Img" objekti pikslite andmed konverteeriti HSL värviruumi ning kirjutati objekti "Work"

28

Joonis 11: #3 HSL värviruumis objekti kõik pikslid käiakse läbi ning algoritm valib välja potentsiaalselt sobivad pikslid. Sobivad pikslid väärtustatakse objektis "Binary" ühtedega, ülejäänud nullidega.

Joonis 12: #4 Objektide tuvastamise algoritmid analüüsivad leitud kontuure ning nende vastavust äriloogikaga paika pandud nõuetele. (Kuju, laius, pikkus, pindala jms.) Sobivad kontuurid salvestatakse objektis “CvMemStorage”.

29

Joonis 13: #5 RGB värviruumis objektil "Img" märgistatakse leitud objektid. Märgistamiseks käiakse läbi tuvastatud objektid andmekogumis "CvMemStorage". Vastavalt tuvastatud objekti tüübile valitakse märgistamise viis - näiteks golfipallidele joonistatakse ümber kollane ring. Seejärel rakendus Botmaster kuvab "Img" objekti kujutise koos märgistatud objektidega.

2 Praktiline teostus

2.1 Videotöötluse jõudluse mõõtmise vahendi ning metoodika

väljatöötamine

Masinnägemise komponendi jõudluse parendamisele suunatud produktiivne arendustöö

eeldab mugavat ning kiiret viisi hinnata videotöötluse hetkelist efektiivsust. Autor leidis, et

esimese sammuna videotöötlluse jõudluse parendamisel on vaja luua mugav tööriist, mis

võimaldaks tehisägemise efektiivsust hinnata ning mille mõõtmistulemused oleksid

omavahel võrreldavad.

2.1.1 Nõuded

Visiooni kohaselt olid seatud kindlad eesmärgid:

• Süsteemi jõudlus on kiiresti mõõdetav pärast igat koodimuudatust

• Automatiseeritud jõudlustest on seadistatav

• Automatiseeritud jõudlustest on kasutuskõlblik ka muudes sarnaste kosteaegadega

reaalajasüsteemides

• Automatiseeritud test on käivitatav mõne vajutusega

• Automatiseeritud jõudlustestimise vahendi implementatsioon on lõimeturvaline

30

• Aktiivses ega passiivses olekus mõõtmisvahend ei avalda tajutavat mõju testitava

süsteemi jõudlusele (ei koorma lisaks omakorda protsessorit), pigem on

aktsepteeritav ka suuremahuline operatiivmälu hõivamine.

• Testimisvahendi rakendusliides (API) on lihtsalt loetav/arusaadav ning võimaldab

märgistada mõõdetavaid protsesse piiramata koguses

• Testitulemused on salvestatavad ning töödeldavad levinud andmetöötlustarkvaradega

nagu LibreOffice või MS Excel

• Testitulemused on mugavalt loetavad

• Testitulemuste mõõtmisühikuteks on millisekundid, nanosekundid ning kaadrite arv

sekundis

Botmasteri arendajad on varasemalt samuti tegelenud platvormi kosteaegade mõõtmisega,

kuid kasutatud vahendid ei vastanud lõputöö autori soovidele.

Eelkõige:

• testitulemuste loetavuse seisukohast

• testide paindlikkuse ning seadistatavuse osas

• varasema mõõtmisvahendi tööpõhimõtte kohaselt teostati tulemuste arvutused

mõõdetava süsteemi töö ajal, mis võib avaldada mõju testitulemustele

Siiski oli Botmasteri arendajate varasem kogemus kosteaegade mõõtmisel väga heaks

sisendiks parendatud mõõtmisvahendi loomisel.

2.1.2 Ajatemplite salvestamine

Arvutisiseste sündmuste ajalise kestvuse mõõtmiseks kasutatakse loendureid – ajatempleid.

Loendurite kasutamiseks määratakse kaks hetke, mille vahel soovitakse mõõta ajakulu. See

protsess sarnaneb autode kiiruse mõõtmisele kiirteedel, kus teatud teelõikude alguses ning

lõpus fikseeritakse sõiduki sisenemise ja väljumise ajahetk ning kahe ajatempli võrdlemisel

tuletatakse masina keskmine sõidukiirus mõõdetava sõidudistantsi läbimisel. Botmasteris on

heaks näiteks kaamera pildi lugemine juhtarvuti mällu, kus esimeseks sündmuseks on

kaamerale pildi laadimise käskluse saatmine ja teiseks sündmuseks pildi juhtarvuti mällu

jõudmine. Vahetult enne esimest ning pärast teist sündmust fikseeritakse ajatempel.

31

Varasematele EIK Robootikaklubi kogemustele toetudes sai ajatemplite fikseerimise tarbeks

valitud ka varem kasutusel olnud POSIX [6] programmiliidese funktsionaalsus. Täpsemalt

funktsioon clock_gettime (formaat: time_t, long nanosec), mille parameetriks kasutatakse

monotoonset kella (CLOCK_MONOTONIC [6]). Antud POSIX programmiliidese

funktsionaalsus on väga sobilik Botmasteri testimiseks, kuna kõik EIK Robootikaklubi

robotid kasutavad Botmaster platvormi jooksutamiseks UNIX süsteemil põhinevaid

operatsioonisüsteeme ning clock_gettime [6] tagab väga head näitajad:

• Kõrge efektiivsus – väga väike üldkulu ehk ajatempli väärtuse lugemiseks kuluv aeg.

Väärtus saadakse loetud protsessori taktide jooksul, mis on märkimisväärselt kiire.

• Tulemused esitatakse väga suure täpsusega - täpsusskaalaks on nanosekundid. Üks

nanosekund on 1/1000000000 sekundit.

• Monotoonne loendur tähendab mõõtmistulemuste usaldusväärtust, kuna loenduri näit

kasvab vaid monotoonselt ning ei vähene iialgi. Loenduri väärtust ei saa ka muuta.

Valitud funktsionaalsuse ainsaks piiranguks on see, et ei ole teostatav protsesside mõõtmine,

mis kestavad üle ühe sekundi. See piirang ei ole Botmasteri masinnägemise mooduli jõudluse

mõõtmisel aktuaalne, kuna kõik mõõdetavad protsessid kestavad vaid sekundi murdosa.

2.1.3 Lahenduse disain

Tööriista loomisel on kasutatud singleton tarkvara disainimustrit, mille kohaselt [7]:

• Klassi kuuluva(te) objekti(de) arv on rangelt piiratud ühele ning on ainult üks

ligipääsupunkt - on välistatud olukord, et jõudlust mõõdab samaaegselt mitu

mõõtmisvahendi instantsi.

• "Global point of access" - globaalselt ligipääsetav kõikjal rakenduses. Ei ole

piiranguid, mis komponente ning millal mõõta.

• “Just-in-time“ initsialiseerimine

Märgitud iseärasuste saavutamiseks on kasutusel privaatne konstruktor ning pointer

staatilisele objekti instantsile [7]. Instantsi tagastav funktsioon on avalik ning esmasel

väljakutsumisel algul luuakse objekt ja seejärel tagastatakse. Järgnevatel kordadel toimub

lihtsalt olemasoleva objekti tagastamine.

32

Üldiselt ei soovitata andmeid ja objekte kasutada globaalse kehtivusega, kuid sellel

disainimustril on oma kindel nišš. Näiteks logimise tarkvarad on taolise ülesehitusega.

Samuti soovitatakse rakendada antud mustrit näiteks andmebaasisessioone käsitletavate

moodulite puhul, kui on vaja kindlasti vältida paralleelseid ühendusi. Ning hetkelgi

Botmasteris jõudluse mõõtmiseks see vastas täielikult nõudmistele.

Testi jooksutamise elutsükkel jaguneb kolmeks faasiks:

• Mõõtmise teostamine

• Tulemuste arvutamine, salvestamine

• Tulemuste ning analüüsi kuvamine

Mõõtmine

Testitav süsteem käivitatakse (toimub tavaline Botmasteri töö test-režiimis ehk töötab ainult

videotöötlemine) ning samaaegselt rakendub paika seatud ajatemplite väärtuste salvestamine

operatiivmällu. Tulemuste salvestamisel ei teostata ühtegi muud operatsiooni – kahe

ajatempli jäädvustamine võtab alla 2000ns, mis tähendab, et tööriist võimaldab salvestada

unikaalsete sündmuste ajalisi kestvusi sagedusega pool miljonit korda sekundis.

Tulemuste töötlemine

Testitava süsteemi mõõdetav töö peatatakse. Seejärel loetakse operatiivmälust kogutud

ajatemplid ning algoritm rehkendab koondtulemused. Saadud tulemused analüüsitakse ning

nende põhjal genereeritakse statistilised andmed nagu näiteks iga mõõdetava protsessi

esinemise sagedus või kõige aeglasem protsess. Tulemustest kompileeritakse struktureeritud

csv fail, mis salvestatakse juhtarvuti kõvakettale.

Tulemuste ning analüüsi kuvamine

Viimase sammuna toimub csv faili automaatne avamine, mis kuvab struktureeritud ning

mugavalt loetava tabeli koos tulemustega. Olenevalt seadistusest võib automaatselt

avanevaks redaktoriks olla näiteks Open-Office Calc või mõni lihtsam tekstiredaktor nagu

Gedit.

2.1.4 Tööriista ning selle rakendusliidese kasutamine

Mõõtmisvahend sai ristitud nimega „VisionTime“. Klassides, mille funktsioonide ning

protsesside jõudlust soovitakse mõõta, tuleb lisada VisionTime klassi päis.

33

#include "visiontime.h"

VisionTime liidese juhtimine käib kujul:

VisionTime::DO()->funktsiooniNimi(Parameeter);

Kokku on 6 avalikku juhtimisfunktsiooni.

Esimesed kolm on mõistlik käivitada testitava programmi (nt Botmasteri) main()

funktsioonis.

1. turnOn() funktsioon lülitab sisse VisionTime'i. Kui see välja kommenteerida, siis ülejäänud

VisionTime'i funktsioonid ei tee mitte midagi. (Testikomponendi aktiivne/passiivne olek):

VisionTime::DO()->turnOn();

2. setMeasureNumberOfFrames() - määrab mitme kaadri kohta tulemused arvutatakse.

Nimelt ei ole pilditöötluse kiirus konstantne, see muutub ajas pidevalt. Ühe kaadri mõõtmine

ei ole otstarbekas, sest tegu võib olla kaadriga, mis on tegelikust keskmisest parem/halvem.

VisionTime kogub info etteantud arvu kaadrite kohta ning arvutab keskmised.

VisionTime::DO()->setMeasureNumberOfFrames(90);

3. setMeasuringFromFrame() - määrab mitmendast kaadrist alates alustatakse mõõtmist.

Jällegi pilditöötluse kiirus pole konstante ja kaamera videovoo edastamise alguses on jõudlus

mõnevõrra kehvem ning paari sekundi pärast stabiliseerub.

VisionTime::DO()->setStartMeasuringFromFrame(120);

Järgmised kolm lähevad sinna, kus toimub mõõdetav töötlemistsükkel.

4. newFrame() - lipp, mis määrab uue kaadri alguse.Väljakutse tuleb panna koodis uue kaadri

funktsiooni vahetusse lähedusse.

VisionTime::DO()->newFrame();

5. markBegin() - lipp, mis määrab mõõdetava protsessi alguse. Funktsiooni argumendiks on

protsessi nimetus või lühend - seda kasutatakse lõpus tulemuste kokkuvõttes.

VisionTime::DO()->markBegin("LUT");// Mõõdetav protsess nt 'LUT' vms

6. markEnd() - lipp, mis määrab mõõdetava protsessi lõpu. Argument on sama nagu protsessi

alguse lipu puhul.

VisionTime::DO()->markEnd("LUT");

34

VisionTime aktsepteerib ka "alamprotsesse":VisionTime::DO()->markBegin("Process");VisionTime::DO()->markBegin("Sub-process1");//alamprotsess1VisionTime::DO()->markEnd("Sub-process1"); VisionTime::DO()->markBegin("Sub-process2");//alamprotsess2VisionTime::DO()->markEnd("Sub-process2"); //miskit muudVisionTime::DO()->markEnd("Process");

Kuid alamprotsess ei tohi olla sama nimega:

VisionTime::DO()->markBegin("Nimi");//mingi protsessVisionTime::DO()->markBegin("Nimi");//mõõdetav protsessVisionTime::DO()->markEnd("Nimi"); //Kumb lõpeb?VisionTime::DO()->markEnd("Nimi"); //Kumb lõpeb?

Samuti ei pea mõõdetavad protsessid esinema sama arv kordi. Iga protsessi keskmine

arvutatakse täpselt selle järgi kui tihti selle käivitamiseni programm jõudis. Ainus nõue on

see, et viimase mõõdetava kaadri lõpuks ei tohi olla ühtegi pooleliolevat protsessi.

Videotöötluse puhul on see loomulik, sest uue kaadri alguses on kogu eelmise kaadri

töötlemine juba läbitud.

2.2 Mõõtmise teostamine esialgse platvormi videotöötluse

komponendi jõudlusele

Peale mõõtmisvahendi implementeerimist ning selle töökindluse testimist, oli võimalik

alustada platvormi esimeste mõõtmistöödega. Botmasteri masinnägemise komponendi

allsüsteemidele olid lisatud jõudlustestimise raamistiku rakendusliidese taimerite lipud. Need

lipud jäävad tarkvara koodi kogu praktilise arenduse lõpuni ning võimaldavad iga hetk mõõta

komponentide kosteaegu. Autori visiooni järgi võivad need jääda Botmasteri lähtekoodi ka

pärast lõputöö valmimist ning olla soovi korral jõudluse indikaatoriks ka tulevaste arenduse

35

vältel. Juhul, kui jõudluse automaattestimise raamistik on passiivses olekus (seadistatustud

välja lülitatud olekusse), ei avalda see Botmasterile mingisugust mõju.

Esialgse süsteemi mõõtmine teostati kahe stsenaariumi järgi – täissuuruses pildi (640x480px)

ning poole väiksema resolutsiooniga kaadrite töötlemine (640x240px). Viimane on sarnane

võistlusrobotitel kasutatava seadistusega, kus on vaja maksimaalselt laia, kuid suhteliselt

kitsast pilti. Autor toetus varasematele kogemustele ning oletas, et jõudluse kasv süsteemi

parendamise käigus ei pruugi olla korrelleeruv erinevate resolutsioonide puhul – teisisõnu

tarkvaraline muudatus võib anda erinevat efektiivsuse võitu suurema ja väiksema

resolutsiooniga kaadrite töötluse puhul.

Raalnägemise jõudluse testimisel kasutatakse alati väga sarnast tausta – tulemuste

võrdlemiseks peavad olema mõõtmisel ka sarnased tingimused. Kõige lihtsam on valida

staatiline natüürmort, kus ei toimu mingit liikumist (täpselt samasuguse liikumise korduv

simuleerimine on keeruline). Oli valitud suhteliselt ebaühtlane taust, kus on heledad ning

tumedad varjundid – täpselt samasugust kasutatakse ka edaspidiste mõõtmiste puhul. Tasub

ära märkida, et tegemist on mõõtmise sooritamisega „ideaalsetes tingimustes“. Paralleeliks

võib tuua näiteks sõiduautode tehnilised spetsifikatsioonid, kus on kajastatatud tootjapoolne

ajaline hinnang sõiduki kiirendusele 0-100km/h – päriselus on tulemused mõnevõrra

tagasihoidlikumad, sest mängu tulevad piiravad tegurid nagu ilmastikutingimused (nt

vastutuul), teekatte tingimused, sõitjate ning pagasi kaal, sõiduvahendi amortiseerumine jne.

Ka lõputöös esitatud mõõtmistulemused annavad hea ülevaate jõudluse efektiivsusest ning on

igati võrreldavad omavahel, kuid päris võistlustingimustes võivad numbrilised väärtused olla

teised.

2.2.1 Tulemused

Tulemused näitasid, et esialgse süsteemi masinnägemise komponendi kaadrisagedus on

maksimaalse resolutsiooni puhul 19 ning poole väiksema pildiga 26 kaadrit sekundis.

Tulemist selgus, et kõige aeganõudvam protsess on kaadri hankimine kaamerast. Sinna

alla läheb ajavahemik alustades kaamerale pildi laadimise käskluse saatmisest kuni

töötluseks valmis pildi jõudmiseni juhtarvuti mällu. Olenemata töödeldava pildi

resolutsioonist, alati 14 millisekundit kestvale kaadri laadimisele (kaamerast laetakse iga

kord täismahus kaader, mis hiljem vajadusel lõigatakse väiksemaks - seega selle protsessi

36

ajakulu alati sama) järgneb objektide tuvastamine, mis summaarselt võtab suure

resolutsiooniga 13,5ms ning väikesega 7ms. Objektide tuvastamine jaguneb neljaks osaks –

aeglaseim neist oli musta joone tuvastus (4,5ms ja 2,5ms), mõnevõrra kiirem palli otsimise

algoritm (3,2ms ja 1,5ms) ning viimased kaks omavahel võrdväärsed väravate otsimise

funktsioonid (sama funktsioon käivitatakse erinevate parameetritega kaks korda, mõlemal

korral kosteajad suure pildiga 2,8ms ning väiksega 1,5ms). Järgnes kaadri kuvamine

Botmaster rakenduses. Pildi näitamine nõuab aega 7,5ms, kitsama kaadri puhul 4,2ms.

Natukene kiiremad protsessid olid gaussi filtri rakendamine ja kujutise konversioon RGB ja

HSL pildiruumide vahel, mõlema ajakulu oli täispildi puhul <8ms ning väikese pildiga <5ms.

Ülejäänud protsesside kosteaegade summa on olenemata töödeldava kaadri resolutsioonist

ligikaudu 0,5ms.

37

38

Joonis 14 - Botmasteri masinnägemise protsessid võib jagada kahte gruppi: sisendkaadri töötlemine ning objektide tuvastamine. Joonisel on kujutatud videotöötluse alamprotsesside järjekord ning ajalised kestvused – esialgne süsteemi versioon, resolutsioon 640x480p.

Joonis 15 - esialgne süsteemi versioon, resolutsioon 640x240p.

NB! Sektordiagrammi lilla tulba koosseisu on lisatud ka kõik masinnägemise komponendi mõõtmise skoobist välja jäänud protsessid. Samuti ka platvormi muud kosteajad: roboti juhtloogika täitmine, suhtlus kontrolleriga jms.

39

Joonis 16: masinnägemise komponendi jõudlustestimise raamistikuga saadud tulemused esialgsele Botmasteri versioonile. Tulemused on sorteeritud kosteaegade ajakulu järgi (vasakpoolne tulemuste tulp), aeglasemad eespool.

640x480px 640x240pxFPS 19 26

90 90120 120

Avg_ms Avg_ms1 52.28 37.132 14.14 14.423 13.52 7.044 7.47 4.175 7.33 3.816 7.16 4.887 4.55 2.458 3.2 1.459 2.92 1.61

10 2.75 1.4111 0.34 0.3712 0.1 0.0613 0.04 0.04

14 0.04 0.0415 0.003 0.00316 0.003 0.00317 0.005 0.005

TULEMUSEDEsialgne süsteem (arenduse alguspunkt)

Resolutsioon

Vahelejäetud kaadrid enne Mõõtmise algustMõõdetud kaadrite arv

ProtsessKaader (Kõik kokku)Kaadri hankimineObjektide tuvastusKujutise kuvamineGaussi filterRGB-HSL KonverteerimineMusta joone tuvastusPallituvastusVärava tuvastus 1Värava tuvastus 2Statistika kandmine pildileVisuaalsete kuj kandmine pildileKaadrisageduse kalkuleerimineVärava ääre tuvastus(Musta joone tuvastuse lisa)Pildiobjektide väärtustamineprocfunct_stor_crt?! Mis see onROI määramine

Joonis 17: kosteaegade kestvuste suhe, esialgne süsteem.640x480p

27.05%

14.02%

13.70%25.86%

5.09%

14.29%

Joonis 18: kosteaegade kestvuste suhe, esialgne süsteem. 640x240p

38.84%

10.26%13.14%

18.96%

7.57%

11.23%

2.2.2 Hinnang tulemustele ning prioriteetide seadmine

Esialgse platvormi videotöötluse komponendi jõudluse mõõtmise eesmärgiks oli selgitada

välja kõige aeganõudvamad allsüsteemid – mida kauem kestab operatsioon, seda suurema

tõenäosusega on võimalik leida võimalusi selle optimeerimiseks. Autor toob välja, milliste

protsesside parendus oli valitud prioriteetseks ning millistele ei keskenduta.

Parendamiseks välja valitud allsüsteemid

• Kaadri hankimine – Platvormi kõige aeglasem protsess, mille kestvus jääb samaks

olenemata töödeldava kaadri suurusest. See on kõige prioriteetsem komponent, mida

tasub täiendada.

• Kujutise kuvamine – Aeglane protsess, mis ei mängi videotöötluses funktsionaalset

rolli, kuid on summaarset jõudlust aeglustav tegur. Uue kaadri võtmine ootab eelmise

kaadri kuvamise taga.

• Objektide tuvastus – Koosneb mitmest üksteisest sõltumatust alamprotsessist, mis

viitab sellele, et potentsiaalne optimeerimisvõimaluste spekter on lai.

Allsüsteemid, mille parendamisele ei keskenduta

• Gaussi filter – Gaussi filtri funktsionaalsuse implementeerimine on keeruline ning

väga aeganõudev. Botmasteris kasutatakse OpenCV teegi sisseehitatud

funktsionaalsust, mis ongi kõrgelt efektiivne ning optimeeritud. Autor leiab, et antud

protsessi kiirendamiseks väga palju alternatiive ei ole.

• RGB-HSL konversioon – Botmaster platvormi arendajad kasutavad selles allsüsteemis

väga efektiivset otsingutabelit ning pointer-aritmeetikat. Aja jooksul on korduvalt

tehtud katseid seda protsessi veelgi optimeerida, kuid need ettevõtmised ei ole toonud

soovitud tulemusi. On alust arvata, et oleme väga lähedal maksimaalsele võimalikule

efektiivsusele. Antud lõputöös sellele protsessile ei keskenduta.

• Kõik ülejäänud protsessid – nende summaarne ajaline kestvus on väga väike ning

tegemist on enamasti lihtsate operatsioonidega, mille parendamine antud kontekstis ei

ole otstarbekas.

40

2.3 Platvormi videotöötluse jõudluse parenduse võimalike

metoodikate ja lähenemiste analüüs

Autor valis välja prioriteetsemad masinnägemise komponendi allsüsteemid, mille

täiendamise abil on seatud eesmärgiks platvormi videotöötluse summaarse jõudluse tõstmine.

Antud peatükis tuuakse välja potentsiaalsed lahendused kosteaegade kärpimiseks ning

sõnastatakse hüpoteesid, millele loodetakse leida kinnitust väljavalitud parenduste

realiseerimise tulemusena. Võimalike lahenduste väljapakkumistel tugines autor eelnevale

kogemusele, publikatsioonidele ning sarnaste reaalajasüsteemide arenduses kasutatavatele

disanimustritele. Lisaks uuris autor analoogseid probleemilahendusi teistes projektides.

2.3.1 Üldine

Kindlasti on võimalik saavutada tulemusi riistvaraliste muudatuste abil. Näiteks juhtarvuti

asendamine sellisega, mille protsessoril on suurem taktisagedus ning tuumade arv. Samuti

võib vahetada välja videosisendi riistvaralise komponendi. Praeguse USB 2.0 kaamera

asemel saaks kasutada oluliselt kiiremat USB 3.0 või IEEE 1394 (FireWire) kaamerat. USB

3.0 protokoll on kordades suurema läbilaskevõimega ning IEEE 1394 standard oli loodud

spetsiaalselt pilditöötlusseadmete jaoks. Mainitud lahendused on antud lõputöö skoobist

väljas, kuna autori eesmärgiks on keskenduda vaid Botmaster tarkvara parendamisele ning

tulemus peab olema sõltumatu välistest teguritest nagu riistvara, draiverid, kasutatav

operatsioonisüsteem jms. Kõikide lisaarenduste testimine teostatakse rangelt võrdsetes

tingimustes.

Juhul, kui ülesannete täitmine ei sõltu üksteisest, võib teostada neid samaaegselt. Tuleb

arvestada sellega, et süsteemis oleks selleks piisavalt ressurssi, sest arvutusmaht ühe ajaühiku

kohta tõuseb kordades. Ideaalis võib jõuda tulemuseni, kus mitme paralleelselt lahendatava

ülesande summaarne kosteaeg võrdub kõige pikema ülesande täitmise ajaga.

Siinkohal tuuakse tihti näide auto ettevalmistamisest enne reisi, kus ülesanded jagatakse

järgmiselt: pagasi paigutamine kaheksa minutit, reisijate paigutamine viis minutit ja

tankimine kolm minutit. Tehes kõiki neid ülesanded üksteise järel, kulub nendele aeg 16

minutit. Samas pole ükski ülesanne teisest sõltuv ja need lahendatakse paralleelselt kaheksa

minuti jooksul. Seega on selliselt püstitatud ülesande juures võimalik kokku hoida pool ajast

41

tehes ülesandeid paralleelselt. Ülesannete paralleelne täitmine on levinud võte

reaalajasüsteemides, kus tihti domineerib tsükliline protsesside kulgemine. Autor panustab

võimalustele teostada üheaegselt erinevaid operatsioone või nende detailsemaid samme ning

saavutada sellega lühemat aega ühe kaadri töötlemisel.

2.3.2 Hüpotees - Kaadri hankimine

Autor uuris mujal maailmas realiseeritud videotöötluse lahendusi ning üks

märkimisväärsemaid antud lõputöö kontekstis oli iseenda eest rääkiva nimetusega projekt

„Qt-OpenCV-Multithreaded“ [22]. Tegemist on avatud lähtekoodiga platvormiga, mille

arendaja on otsinud lahendusi sarnasele probleemile. Märkimisväärseks teeb mainitud

projekti selle sarnanus EIK Robootikaklubis kasutatavate tehnoloogiate ning vahenditega.

Projekti arendaja on arendanud platvormi UNIX tüüpi operatsioonisüsteemi suunitlusega,

kasutatud on samasugust Playstation Eye USB kaamerat ning platvormi komponendid on

realiseeritud kasutades Qt ning OpenCV teeke. Projekti peamine fookus on mitmelõimelise

arhitektuuriga pilditöötlemisel. Näiteks on seal implementeeritud kaamerast kaadri võtmine,

mis toimub paralleelselt kaadri töötlemisega (näiteks filtrite rakendamisega). Kahjuks ei ole

võimalik Botmasterisse implementeerida selles projektis toimivaid valmislahendusi, kuna

Botmasteris ning „Qt-OpenCV-Multithreaded“ platvormides on kasutuses erinevad OpenCV

teegid. Botmaster kasutab vanemat C keele teeki, aga välismaises analoogis on C++

versioon. Need kaks teeki omavad sarnaseid funktsionaalsusi, kuid tegelikult on nad väga

erinevad – teistsugune rakendusliides, mäluhaldamise printsiibid jms. OpenCV teegi

väljavahetamine Botmasteris ei ole otstarbekas, kuna see oleks äärmiselt mahukas töö (eriti

objektide tuvastuse pool) ning Botmasteri arendajad on praeguse teegiga väga harjunud. Küll

aga andis mitmelõimelise lahendusega projekt lõputöö autorile ideid ning kinnitust, et

paralleelselt teostatavate protsessidega analoogsed lahendused toimivad ning jõudlus on

efektiivne. Mitmelõimeliste disainimustrite kasutamine on tänapäeval raalnägemises standard

ning kõrge tootlikuse võti [4].

Kaadri hankimise lahenduse ümberdisainimine suure tõenäosusega tõstab platvormi

efektiivsust.

42

2.3.3 Hüpotees - Objektide tuvastus

Autor vaatles seni objektide tuvastamise funktsionaalsusi musta kastina. Iga eraldiseisva

objekti tuvastamise funktsioonide uurimisel selgus, et neis esinevad väga sarnased mustrid

ning korduv funktsionaalsus.

Objektide tuvastamise lahenduse ümberdisainimine suure tõenäosusega tõstab

platvormi efektiivsust.

2.3.4 Hüpotees - Kujutise kuvamine

Kujutise kuvamine on arvutusmahult kallis protsess, mis kaadri töötlemise seisukohast ei loo

lisandväärtust. Kaadrite kuvamine on väga väärtuslik Botmaster tarkvara testimisel, eriti uute

objektide tuvastamise funktsionaalsuste loomisel. Kuid roboti töö ajal (võistlustingimustes)

on praeguse lahenduse disainis parandust vajav puudujääk:

• koormatakse juhtarvuti protsessorit

• uue kaadri võtmine (seega ka kogu uue kaadri töötlemine) ei alga enne kui eelmine

kaader kuvatakse Botmasteri graafilises liideses.

Töödeldava video kuvamise lahenduse ümberdisainimine suure tõenäosusega tõstab

platvormi efektiivsust.

2.4 Lahenduste realiseerimine

2.4.1 Mitmelõimeliste lahenduste realiseerimise võimalused

Botmaster platvormis

Ühelõimelise programmi täiustamine mitmelõimeliseks ning allsüsteemide protsesside

samaaegse täitmise implementeerimine eeldab eelnevat analüüsi. Autor kaardistas

protsessidevahelised sõltuvused, et tuvastada, milliseid neist oleks võimalik täita üheaegselt.

Mitmelõimeliste lahenduste arendamisel kutsutakse sellist võimalust protsesside

asünkroonsuseks (activity asynchrony) [23]. Sõltuvuste kindlakstegemiseks vaadati, kas

operatsiooni teostamine oleneb eelneva(te) allsüsteemi(de) tulemusest. Näiteks gaussi filtri

rakendamine ning RGB-HSL konversioon ei või olla üheaegselt täidetavad, sest eesmärgiks

43

on saada gaussi filtriga silutud kujutis HSL värviruumis. Selle tõttu peab alguses teostama

esimese ning seejärel alles teise operatsiooni ehk ühe protsessi väljund on järgmise sisendiks.

44

Joonis 19: Saab kindlalt öelda, et on võimalik teostada samaaegselt kõikide objektide(erinevat tüüpi) tuvastamist, sest operatsioonid ei ole omavahel seotud. Kõik protsessid sõltuvad kaadri hankimisest, sest kõikide allsüsteemide protsesside puhul on otseseks või kaudseks sisendiks kaamerast saadud kujutis. Kaadri hankimine ise on sõltumatu kõikidest teistest protsessidest – uue kaadri hankimisel ei mängi rolli eelmise kaadri töötluse tulemus.

45

Joonis 20: Autor visualiseeris ühe võimaliku lahenduse.

Joonis 20 kirjeldab, et:

• Uue kaadri hankimist saab teostada kogu pildi töötlemise tsükli vältel. Autor arvutas,

et juhul kui gaussi filtrini jõudmiseks ei oleks vaja lugeda kaamerast pilti, vaid saaks

laadida mälust eelnevalt laetud (paralleelses lõimes) pilt, siis ideaalses olukorras võib

jõudluse efektiivsus tõusta 25-35%. Hinnangulise jõudluse võidu arvutamiseks

kasutati esialgse süsteemi mõõtmistulemusi ning kaadri keskmisest kestvusest lahutati

kaadri hankimiseks kuluv aeg, seejärel liideti eeldatav aeg (alla 2ms), mis kulub

kaadri laadimisele operatiivmälust.

• Kõikide objektide tuvastamise operatsioonide täitmist alustatakse üheaegselt.

Objektide tuvastamine kestab summaarselt sama kaua kui kõige aeglasem

tuvastamise allsüsteem – musta joone tuvastus. Autor arvutas, et ideaalis võib

jõudluse efektiivsus tõusta 15-20%. Hinnangulise jõudluse võidu arvutamiseks

kasutati esialgse süsteemi mõõtmistulemusi ning kaadri keskmisest kestvusest lahutati

palli ning väravate tuvastamisele kuluv aeg.

Mainitud arvutusviis on antud situatsioonis sobiv selleks, et teha kindlaks ligikaudsed

jõudluse paranemise väljavaated. Juhul, kui parendusi planeeritakse mitu korraga, siis on

arvutamiseks soovitatav kasutada Amdahli seadust [24]. See on matemaatiline arvutusviis,

mille abil on võimalik välja selgitada maksimaalne eeldatav programmi jõudluse tõus, kui

täiustatakse ainult teatud osa süsteemist. Seda võtet kasutatakse tihti tarkvaralahenduste

optimeerimisel lõimede abil.

2.4.2 Kaadri hankimine – mitmelõimeline lahendus

2.4.2.1 Eesmärk

Kaadri hankimise allsüsteemi lahenduse optimeerimise eesmärgiks on vabaneda kaamerast

kaadri hankimisele kuluvast ajalisest viivitusest. Mujal maailmas realiseeritud lahendused

annavad kinnitust, et eraldi lõimes kaadri lugemine kaamerast võimaldab saavutada

püstitatud eesmärki.

46

2.4.2.2 Kontseptuaalne lahendus

47

Joonis 21: Olemasolev ning uus kontseptuaalne lahendus

Joonis 21 annab ülevaate disainimuudatustest, mille abil oleks võimalik olulisel määral

parandada süsteemi jõudlust. On välja toodud olemasolev ning uus kontseptuaalne lahendus

ning nendevahelised erinevused.

2.4.2.2.1 Ülevaade

Olemasolev lahendus

• Süsteem toimib ühes lõimes ning protsessid korduvad tsükliliselt alati samas

järjekorras

Kontseptuaalne lahendus

• Süsteemis on kaks lõime, millest üks on orienteeritud ainult kaadri laadimisele

kaamerast

• Punase katkendliku joonega on märgitud kaadri hankimise operatsiooni lõpphetk, mis

ühtib kujutise kuvamise allsüsteemi lõppemisega

• Rohelise katkendliku joonega on märgitud kaadri hankimise operatsiooni alustamise

ajastus

Jooniselt on näha, et kaadri hankimise operatsiooni nihkumine paralleelsesse lõime lühendab

pealõime tsükli kestvust. Tsükkel lüheneb ligikaudu ühe kaadri hankimisele kuluva aja võrra.

2.4.2.2.2 Takistused

Näitena välja toodud kontseptuaalset lahendust on praktiliselt võimatu realiseerida. Takistus

seisneb selles, et puudub võimalus täpselt ajastada kaadri hankimise protsessi alustamist

teises lõimes.

Objektide tuvastuse ning muude allsüsteemide kosteajad olenevad videosisendi visuaalsest

keerukusest (vaatevälja kuuluvate objektide rohkus, valgustustingimused jms). Sarnane mõju

avaldub ka mitmetele teistele allsüsteemidele. Kaadri hankimise alustamist tuleks ajastada

täpselt nii, et operatsioon lõppeks üheaegselt mingi kindla protsessiga programmi peavoos

(olemasoleva süsteemi puhul kujutise kuvamisega) – see on lihtsal viisil praktiliselt

teostamatu, sest puudub võimalus prognoosida nimetatud protsesside ajalisi kestvusi.

Teoreetiliselt oleks võimalik luua algoritm, mis hindaks videokaadri keerukust ning suudaks

tuletada hinnangulisi eeldatavaid kosteaegu näiteks objektide tuvastusele või kujutise

kuvamisele – selline info oleks abiks antud kontseptuaalse lahenduse loomisel. See lisaks

48

programmile arvutusmahtu ning töökindlus oleks vaieldav. Autor kavatseb nimetatud

kontseptsioonile tuua sisse täiendused, et saada toimiv ning robustne lahendus.

2.4.2.3 Teostus – Realiseeritud lahendus

49

Joonis 22: Realiseeritud uuendused – eelnevalt kirjeldatud kontseptuaalse lahenduse täiustatud versioon

Joonis 22 kirjeldab realiseeritud täiendusi kaadri hankimise allsüsteemis. Parenduste

eesmärgiks oli programmi summaarse jõudluse tõstmine. Lahendus põhineb eelnevalt

väljatoodud kontseptuaalsel lahendusel, kuid omab mitmeid täiendusi, mille abil lahendati

ilmnenud probleemid takistuste ja kitsendustega.

2.4.2.3.1 Põhimõte ning iseloomustus

Üldine:

• Süsteemis on kaks lõime, millest üks on orienteeritud ainult kaadri laadimisele

kaamerast.

• Mõlemas lõimes toimuvad järjepidevad tsüklilised protsessid, mis ei ole omavahel

sünkroonis ning on täiesti sõltumatud. Mõlemad kestavad katkematult kuni

programmi töö lõpuni.

Lõim #2 (Kaadri hankimine)

• Kaadri hankimise lõime peamiseks komponendiks on tsükkel, milles toimub

lakkamatu värskete kaadrite laadimine kaamerast. Selline disainimuster on

tehisnägemises tuntud kui „ring acquisition“ ning sümboliseeribki seda, et kaadri

hankimise tsükkel käib konstantselt ringi [4].

• Hangitud kaadrite hoiustamiseks on kaks ühekaadrilist puhvrit, kuhu kordamööda

sisestatakse kaamerast saadud kaadrid. Eelmine puhvris olev kaader kirjutatakse üle

ning jääb kasutamata.

• Vahelüliks pea programmivoo ning kaadri hankimise lõime vahel on viimase

koosseisu kuuluv komponent kaadrite väljastamiseks. Kaadrite edastamiseks

pealõimesse kasutatakse kuhjuvat lähenemist, mida hallatakse põhimõttel: viimasena

sisse ning esimesena välja. Selline printsiip on tuntud LIFO loogika nime all [25]

(LIFO – last in, first out). Kaadri väljastaja teeb kindlaks, millisesse kahest puhvrist

oli viimati paigutatud värske kaader, ning edastab selle. Kaadri väljastamisel toimub

olemasoleva kujutise lugemine puhvrist (operatiivmälust), mis on kiire protsess.

Eeldatav kestvus olemasoleva riistvara puhul <1,5ms.

Lõim #1 (Pealõim)

• Pealõimes toimib kõik sarnaselt esialgsele süsteemile (selle ainsas lõimes), kuid

kaadri hankimise protsess on asendatud pöördumisega kaadri väljastaja poole.

50

2.4.2.3.2 Lahenduse tehnilised tunnusjooned

Protsesside eraldamiseks paralleelsesse lõime kasutati Qt teegi vahendit QThread [26].

Qthread on platvormist sõltumatu viis programmilõimede haldamiseks. QThread

funktsionaalsuse kasutuselevõtt oli tehtud „Qt-OpenCV-Multithreaded“ [22] projekti

eeskujul, kus sarnase eesmärgi täitmiseks kasutati just seda vahendit. Autor lähtus ka

eesmärgist kasutada just Qt alternatiive mitmelõimelise lahenduse implementeerimiseks.

Botmaster platvormis on üsna palju Qt teegil põhinevat funktsionaalsust ning arendajate

jaoks on kindlasti mugav, kui programmi erinevad osad on ühtses stiilis.

Qthreadi iseloomustus – mugav liides võimaldab: [27]

• Lihtsalt ning kiiresti luua funktsionaalsusi, mis peavad olema täidetud eraldi lõimes.

• Pärida infot iga lõime oleku kohta: jooksev, lõpetatud, ootamine.

• Juhtida lõime: käivitamine, peatamine.

• Seadistada igat eraldiseisvat lõime: prioriteet, virnmälu suurus jms.

• Seada lõimede prioritiseerimiseks 8 erinevat taset.

• Hallata signaale lõimede vahel.

Kaadri laadimiseks kaamerast ning kaadrite hoiustamiseks puhvrites on kasutusel samad

printsiibid ja andmestruktuurid, mis esinevad ka esialgses Botmaster platvormis.

2.4.2.3.3 Lahenduse väljatöötamine, silumine ning testimine

Lahenduse realiseerimiseks loodi mitu prototüüpi. Alustatud oli ühe puhvriga. Lõime

muutujate lukustamist testiti samuti erinevate Qt teegi semafor-vahenditega nagu QMutex

või QReadWriteLock [26]. Keeruline puhvriloogika, kus toimus katkematu kaadrite

kirjutamine samasse puhvrisse ning selle tõttu ka pidev elementide olekute muutumine, ei

tundunud autorile piisavalt hea lahendus. Üsna peagi jõuti lahenduseni, kus on kaks

üksteisest sõltumatut ühekaadrilist puhvrit, kuhu kaadrite kirjutamine toimub kordamööda.

Värskeima pildiga puhver ei ole kaadri hankimise lõime poolt lukustatud ning täidab

püstitatud eesmärgi – kiire kaadri edastamine pealõime.

51

2.4.2.3.4 Lahendusega kaasnevad kõrvalmõjud süsteemile

Programmi kõikide muude tegevustega samaaegselt toimub värskelt lisandunud lõimes

intensiivne tegevus - pidev kaadrite laadimine kaamerast ning salvestamine. Selle tulemusena

on kasvanud arvutusmaht ühe ajaühiku kohta ning koormus protsessorile. Robotite riistvaral

on kahetuumaline protsessor, kuid siiski osade protsesside puhul võib täheldada aeglustumist.

See on põhjuseks, miks autor on seni kasutanud võimalike lahenduste analüüsimisel

sõnapaari „ideaalne tulemus“ - parima võimaliku tulemuse prognoosimiseks ei võetud

arvesse lahenduse võimalikku negatiivset mõju muudele protsessidele.

Möödapääsmatu kõrvalnähtuse mõju minimeerimise eesmärgil täiendas autor „ring

aquisition“ mustriga lahendust üsna lihtsamoelise, kuid nutika loogikaga. Vahetult pärast

kaadriväljastaja komponendi poole pöördumist hakati katkestama lühikeseks ajaks kaadrite

laadimist puhvritesse. Kaadrite hankimise protsessi lühiajaline hangumine kujutise

töötlemise operatsioonide alguses aitas vähendada koormust protsessorile. Kirjeldatud

lähenemisviis ning selle edasiarendus võib olla väga kasulik suurema resolutsiooniga

videovoogude puhul, kus töötlemisele kuluv aeg on pikem ning etteaimatavam.

Tõenäoliselt on see potentsiaalne negatiivne mõju suhteliselt marginaalne ning

mõõtmistulemused näitavad, et lahenduse abil saavutati siiski üldine jõudluse võit.

52

2.4.2.3.5 Analüüs platvormi parendatud videotöötluse komponendi

jõudlusele – mitmelõimeline lahendus

NB! Sektordiagrammi lilla tulba koosseisu on lisatud ka kõik masinnägemise komponendi mõõtmise skoobist välja jäänud protsessid. Samuti ka platvormi muud kosteajad: roboti juhtloogika täitmine, suhtlus kontrolleriga jms.

53

640x480px

FPS 19 23

90 90120 120

Avg_ms Avg_ms52.28 44.14 -8.14 +15.57%14.14 1.3 -12.84 +90.81%13.52 14.49 +0.97 -7.17%7.47 9.51 +2.04 -27.31%7.33 8.1 +0.77 -10.50%7.16 7.86 +0.70 -9.78%4.55 4.94 +0.39 -8.57%3.2 3.42 +0.22 -6.88%

2.92 3.06 +0.14 -4.79%2.75 2.94 +0.19 -6.91%0.34 0.4 +0.06 -17.65%0.1 0.12 +0.02 -20.00%

0.04 0.06 +0.02 -50.00%

0.04 0.04 0 0%0.003 0.004 +0.001 33.33%0.003 0.003 0 0%0.005 0.005 0 0%

TULEMUSEDEsialgne süsteem vs. täiustatud mitmelõimeline lahendus

Resolutsioon

Esialgne Täiustatud

Vahelejäetud kaadrid enne Mõõtmise algustMõõdetud kaadrite arv

Protsess Ajaline kestv. (ms) Efekt. Võit %Kaader (Kõik kokku)Kaadri hankimineObjektide tuvastusKujutise kuvamineGaussi filterRGB-HSL KonverteerimineMusta joone tuvastusPallituvastusVärava tuvastus 1Värava tuvastus 2Statistika kandmine pildileVisuaalsete kuj kandmine pildileKaadrisageduse kalkuleerimineVärava ääre tuvastus(Musta joone tuvastuse lisa)Pildiobjektide väärtustamineprocfunct_stor_crt?! Mis see onROI määramine

Summaarne süsteemi jõudluse tõus: 15.57%! (640x480px)

Joonis 23: kosteaegade kestvuste suhe, esialgne süsteem. 640x480p

27.05%

14.02%

13.70%25.86%

5.09%

14.29%

Joonis 24: kosteaegade kestvuste suhe, täiustatud mitmelõimeline lahendus. 640x480p

2.95%18.35%

17.81%

32.83%

6.52%

21.55%

NB! Sektordiagrammi lilla tulba koosseisu on lisatud ka kõik masinnägemise komponendi mõõtmise skoobist välja jäänud protsessid. Samuti ka platvormi muud kosteajad: roboti juhtloogika täitmine, suhtlus kontrolleriga jms.

54

640x240px

FPS 26 41

90 90120 120

Avg_ms Avg_ms37.13 24.12 -13.01 +35.04%14.42 1.2 -13.22 +91.68%7.04 7.04 0 0%4.17 4.23 +0.06 -1.44%3.81 3.89 +0.08 -2.10%4.88 4.96 +0.08 -1.64%2.45 2.48 +0.03 -1.22%1.45 1.46 +0.01 -0.69%1.61 1.59 -0.02 +1.24%1.41 1.4 -0.01 +0.71%0.37 0.35 -0.02 +5.41%0.06 0.07 +0.01 -16.67%0.04 0.05 +0.01 -25.00%

0.04 0.04 0 0%0.003 0.003 0 0%0.003 0.003 0 0%0.005 0.005 0 0%

TULEMUSEDEsialgne süsteem vs. täiustatud mitmelõimeline lahendus

Resolutsioon

Esialgne Täiustatud

Vahelejäetud kaadrid enne Mõõtmise algustMõõdetud kaadrite arv

Protsess Ajaline kestv. (ms) Efekt. Võit %Kaader (Kõik kokku)Kaadri hankimineObjektide tuvastusKujutise kuvamineGaussi filterRGB-HSL KonverteerimineMusta joone tuvastusPallituvastusVärava tuvastus 1Värava tuvastus 2Statistika kandmine pildileVisuaalsete kuj kandmine pildileKaadrisageduse kalkuleerimineVärava ääre tuvastus(Musta joone tuvastuse lisa)Pildiobjektide väärtustamineprocfunct_stor_crt?! Mis see onROI määramine

Summaarne süsteemi jõudluse tõus: 35%! (640x240px)

Joonis 25: kosteaegade kestvuste suhe, esialgne süsteem. 640x240p

38.84%

10.26%13.14%

18.96%

7.57%

11.23%

Joonis 26: kosteaegade kestvuste suhe, täiustatud mitmevooline lahendus. 640x240p

4.98%16.13%

20.56%

29.19%

11.61%

17.54%

Mõõtmistulemuste ülevaadeParendatud süsteemi mõõtmistulemused vastasid ootustele. Ilmnesid mitmed huvitavad

tendentsid.

Üldine

• Suurenenud arvutusmahud ning tõusnud koormus protsessorile avaldas negatiivset

mõju peaaegu kõikidele pealõimes kulgevatele allsüsteemidele. Õnneks uue

lahenduse aeglustav mõju teistele protsessidele on väga väike – enamuse protsesside

puhul praktiliselt tajumatu.

• Täiustatud allsüsteem on eraldi vaadeldavate protsesside seas nüüd lühima kosteajaga

(Eraldi vaadeldavad protsessid esinevad sektordiagrammides). Kolm kõige

aeglasemat allsüsteemi: Objektide tuvastus, kaadri kuvamine ning RGB-HSL

konversioon

Testid resolutsiooniga: 640x480px

• Kaadri hankimise ehk täiustatud allsüsteemi efektiivsus tõusis ~91%. Kosteaeg

vähenes ~13,2ms võrra ning on alla 1,5ms.

• Suurim efektiivsuse langus tabas kujutise kuvamise allsüsteemi. Ühe kaadri kuvamine

on muutunud ~2ms aeglasemaks (efektiivsus langes ~27,5%).

• Platvormi summaarne efektiivsus tõusis ~16%. Kaadrisagedus tõusis 4 kaadri

võrra ning on ~23fps.

Testid resolutsiooniga: 640x240px

• Kaadri hankimise ehk täiustatud allsüsteemi efektiivsus tõusis ~92%. Kosteaeg

vähenes ~13ms võrra ning on alla 1,5ms.

• Suurim efektiivsuse langus tabas gaussi filtri ning RGB-HSL konversiooni

allsüsteemi. Mõlemate protsesside kulgemine on muutunud ~0.1ms aeglasemaks. See

on väga väike erinevus. Võib öelda, et antud resolutsiooni puhul on negatiivne mõju

teistele süsteemidele minimaalne.

• Platvormi summaarne efektiivsus tõusis 35%. Kaadrisagedus tõusis 15 kaadri

võrra ning on ~41 fps.

55

2.4.3 Kujutise kuvamine – süsteemi paremaks jõudluseks

optimeeritud lahendus

Võrreldes teiste käsitletavate

protsessidega, kujutise väljatrükkimise

eripära seisneb selles, et see ei tekita

masinnägemise seisukohast mingit

väärtust. Robot ise liideses kuvatud pilti

ei kasuta. Reaalaja video mängimine on

kasulik masina loojatele: aitab mõista,

mida näeb robot. Roboti arendajad

kasutavad reaalset otsepilti roboti

ruumilise nägemise valemite loomisel,

värvitundlikkuse kalibreerimisel, roboti

testimisel ning roboti sihi etteandmisel

enne võistluse algust. Alates

momendist, kui mobiilne robot on

võistlustules ning liigub iseseisvalt

ringi, on kaadrite kuvamine ainult liigne koormus. Nagu on ilmnenud varasematest

mõõtmistulemustest – kaadrite kuvamine on üsna arvutusmahukas operatsioon, kuid

tõenäoliselt ei ole Botmaster platvormi loojad seda protsessi sellise pilguga testinud.

Lahendus

Autor realiseeris mõned triviaalsed täiendused. Uuendus seisneb selles, et alates roboti

väljumisest kõige esimesest, „stardivalmis“ olekust, kaadreid kuvatakse kas madala

sagedusega või ei kuvata üldse. Teisisõnu, videovoo kuvamine programmiliideses lõpetatakse

kohe, kui robot hakkab võistlusväljakul iseseisvalt tegelema. Väga lihtne lahendus võimaldab

roboti loojal/käivitajal enne stardisignaali kalibreerida tehisnägemise värvitaju ning viia läbi

muud visuaalsest vaateväljast olenevad seadistused. Samal ajal võistlustingimustes on roboti

efektiivsus kõrgem. Antud lahendus on arendaja poolt seadistatav. Näiteks testimise

eesmärgil on võimalik iga hetk jälle lülitada sisse kaadrite pidev kuvamine.

56

Joonis 27: Olenemata roboti juhtloogika keerukusest ning olekute arvust, kaadri kuvamine on otstarbekas ühes ainsas olekus – enne starti.

2.4.3.1.1 Analüüs platvormi parendatud videotöötluse komponendi

jõudlusele – optimeeritud kuvamise lahendus (+mitmelõimeline lah.)

NB! Sektordiagrammi lilla tulba koosseisu on lisatud ka kõik masinnägemise komponendi mõõtmise skoobist välja jäänud protsessid. Samuti ka platvormi muud kosteajad: roboti juhtloogika täitmine, suhtlus kontrolleriga jms.

57

640x480px

FPS 19 28

90 90120 120

Avg_ms Avg_ms52.28 34.96 -17.32 +33.13%14.14 0.77 -13.37 +94.55%13.52 14.6 +1.08 -7.99%7.47 0.003 -7.47 +99.96%7.33 7.46 +0.13 -1.77%7.16 9.32 +2.16 -30.17%4.55 5.14 +0.59 -12.97%3.2 3.36 +0.16 -5.00%

2.92 3.07 +0.15 -5.14%2.75 2.9 +0.15 -5.45%0.34 0.39 +0.05 -14.71%0.1 0.12 +0.02 -20.00%

0.04 0.04 0 0%

0.04 0.02 -0.020 +50.00%0.003 0.003 0 0%0.003 0.004 +0.001 -33.33%0.005 0.005 0 0%

TULEMUSEDEsialgne süsteem vs. täiustatud mitmelõimeline lahendus + optimeeritud kuvamise lahendus

Resolutsioon

Esialgne Täiustatud

Vahelejäetud kaadrid enne Mõõtmise algustMõõdetud kaadrite arv

Protsess Ajaline kestv. (ms) Efekt. Võit %Kaader (Kõik kokku)Kaadri hankimineObjektide tuvastusKujutise kuvamineGaussi filterRGB-HSL KonverteerimineMusta joone tuvastusPallituvastusVärava tuvastus 1Värava tuvastus 2Statistika kandmine pildileVisuaalsete kuj kandmine pildileKaadrisageduse kalkuleerimineVärava ääre tuvastus(Musta joone tuvastuse lisa)Pildiobjektide väärtustamineprocfunct_stor_crt?! Mis see onROI määramine

Summaarne süsteemi jõudluse tõus: 33,2%! (640x480px)

Joonis 29: kosteaegade kestvuste suhe, esialgne süsteem. 640x480p

27.05%

14.02%

13.70%25.86%

5.09%

14.29%

Joonis 28: kosteaegade kestvuste suhe, täiustatud mitmelõimeline lahendus + optimeeritud kuvamise lahendus. 640x480p

2.20%

21.34%

26.66%41.76%

8.03%0.01%

NB! Sektordiagrammi lilla tulba koosseisu on lisatud ka kõik masinnägemise komponendi mõõtmise skoobist välja jäänud protsessid. Samuti ka platvormi muud kosteajad: roboti juhtloogika täitmine, suhtlus kontrolleriga jms.

58

640x240px

FPS 26 49

90 90120 120

Avg_ms Avg_ms37.13 20.25 -16.88 +45.46%14.42 0.81 -13.61 +94.38%7.04 8.07 +1.03 -14.63%4.17 0.004 -4.17 +99.9%3.81 4 +0.19 -4.99%4.88 4.58 -0.30 +6.15%2.45 2.89 +0.44 -17.96%1.45 1.92 +0.47 -32.41%1.61 1.58 -0.03 +1.86%1.41 1.58 +0.17 -12.06%0.37 0.4 +0.03 -8.11%0.06 0.07 +0.01 -16.67%0.04 0.04 0 0%

0.04 0.02 -0.02 -50%0.003 0.004 +0.001 -33.33%0.003 0.004 +0.001 -33.33%0.005 0.005 0 0%

TULEMUSEDEsialgne süsteem vs. täiustatud mitmelõimeline lahendus + optimeeritud kuvamise lahendus

Resolutsioon

Esialgne Täiustatud

Vahelejäetud kaadrid enne Mõõtmise algustMõõdetud kaadrite arv

Protsess Ajaline kestv. (ms) Efekt. Võit %Kaader (Kõik kokku)Kaadri hankimineObjektide tuvastusKujutise kuvamineGaussi filterRGB-HSL KonverteerimineMusta joone tuvastusPallituvastusVärava tuvastus 1Värava tuvastus 2Statistika kandmine pildileVisuaalsete kuj kandmine pildileKaadrisageduse kalkuleerimineVärava ääre tuvastus(Musta joone tuvastuse lisa)Pildiobjektide väärtustamineprocfunct_stor_crt?! Mis see onROI määramine

Summaarne süsteemi jõudluse tõus: 45,5%! (640x240px)

Joonis 30: kosteaegade kestvuste suhe, esialgne süsteem. 640x240p

38.84%

10.26%13.14%

18.96%

7.57%

11.23%

Joonis 31: kosteaegade kestvuste suhe, täiustatud mitmelõimeline lahendus + optimeeritud kuvamise lahendus. 640x240p

4.00%

19.75%

22.62%39.85%

13.76%0.02%

Mõõtmistulemuste ülevaadeParendatud süsteemi mõõtmistulemused vastasid ootustele.

Üldine

• Täiustatud allsüsteem on eraldi vaadeldavate protsesside seas nüüd lühima

kosteajaga, sest mõõtmise ajal (testitakse roboti iseseisva tegevuse olekut) kosteaeg

peaaegu puudus (Eraldi vaadeldavad protsessid esinevad sektordiagrammides). Kolm

kõige aeglasemat allsüsteemi: Objektide tuvastus, RGB-HSL konversioon ning gaussi

filter.

Testid resolutsiooniga: 640x480px

• Kaadri hankimise ehk täiustatud allsüsteemi efektiivsus tõusis 99,9%. kosteaeg on

peaaegu olematu.

• Suurim efektiivsuse langus oli registreeritud objektide tuvastuse allsüsteemis.

Objektide tuvastamine on läinud ~1ms aeglasemaks (efektiivsus langes ~8%).

• Platvormi summaarne efektiivsus tõusis ~33%. Kaadrisagedus tõusis 9 kaadri

võrra ning on ~28 fps.

Testid resolutsiooniga: 640x240px

• Kaadri hankimise ehk täiustatud allsüsteemi efektiivsus tõusis ~99,9%. kosteaeg

on peaaegu olematu.

• Suurim efektiivsuse langus oli registreeritud objektide tuvastuse allsüsteemis.

Objektide tuvastamine on läinud ~1ms aeglasemaks (efektiivsus langes ~15%).

• Platvormi summaarne efektiivsus tõusis 45,5%. Kaadrisagedus tõusis 23 kaadri

võrra ning on ~49 fps.

59

3 Edaspidised väljavaated

Autor kavatseb pärast IT Kolledži lõpetamist jätkata tegevust robotiklubi liikmena ning

panustada organisatsiooni tulevikku. Eesmärgiks on jätkata klubi esindamist võistleja rollis

ning toetada ka uusi liikmeid jagades neile teadmisi ja kogemusi. Kindlasti on kavas jätkata

tööd seoses Botmaster platvormi täiendamisega. Väljakutsete seas on nii edastpidine

süsteemi funktsionaalsuse või jõudluse arengupotentsiaal, aga ka vajadus optimeerida

tarkvara ühildumiseks uute riistvaramoodulitega. Iga-aastaste rutiinide seas on vajadus lisada

või täiendada masinnägemise algoritme. Lõputöö sisukas analüüsi peatükk oli kirjutatud

lootusega luua tulevastele platvormi tehisnägemise komponendi arendajatele õppematerjal/

dokumentatsioon platvormi videotöötlemise kohta. Praktilise teostuse peatükk võib anda

ideid, kuidas analüüsida, realiseerida ning testida uusi lahendusi.

Järgnevad kaks alapeatükki annavad lühikese ülevaate edaspidistest väljavaadetest antud

lõputöö kontekstis – masinnägemise süsteemi seisukohast. Diplomitöö käigus tehtud

arvutused näitavad, et pärast rakendatud täiendusi on kosteaja poolest kõige aeglasemaks

allsüsteemiks jäänud objektide tuvastus. Autor on realiseerinud mitu põhjalikumalt testimata

prototüüpi, mis annavad lootust tõsta probleemse komponendi ning süsteemi summaarset

jõudlust veelgi.

60

3.1 Objektide tuvastus - binaarpiltide väärtustamise optimeeritud

lahendus

Autor teostas staatilise analüüsi Botmaster

platvormis realiseeritud objektide tuvastamise

algoritmidele ning funktsioonidele.

Abstraheerides masinnägemise komponendi

objektituvastuse funktsionaalsusi, võib

märgata, et nad kõik (erinevate objektide

tuvastamiseks on eraldiseisvad funktsioonid)

alluvad teatud mustrile ning sisaldavad

tüüpilisi samme. Mõned sammudest on

täielikult identsed – autor näeb selles

potentsiaali lahenduse efektiivsuse tõstmiseks.

Joonis 33 kirjeldab objektituvastuse

funktsioonides esinevaid samme. Punasega on

märgitud sammud, mis on identsed kõikide

objektide puhul. Rohelisega on märgitud

sammud, mille loogika on tihedalt seotud iga

konkreetse tuvastatava objekti tüübi individuaalse iseloomuga. Binaarpildi väärtustamise

sammus käiakse läbi kõik HSL värviruumis oleva kaadri pikslid ning algoritm valib välja

sobivamad. Aktsepteeritud pikslite asukohad kantakse binaarpildile, mis on sisendiks

järgnevale objektituvastamise loogikale. Praeguse implementatsiooni probleem seisneb

selles, et igat tüüpi objektide tuvastamiseks kontrollitakse kõik kaadri punktid iga kord uuesti

ning see on üsna mahukas protseduur. Autor panustab võimalusele eraldada (mainitud

funktsioonidest) binaarpildi väärtustamise funktsionaalsus ning teostada see vaid ühel korral

enne objektide tuvastamise funktsioonide väljakutsumist. Lahendus tähendaks seda, et ühe

sammuna käiakse läbi kõik HSL värviruumi kujutise pikslid (ainult üks kord kogu kaadri

kohta) ja luuakse eraldi binaarpildid kohe kõikidele objektituvastamise funktsioonidele.

61

Joonis 32: Lihtsustatud joonis tüüpilisest sammudest objektide tuvastamisel Botmaster platvormis

Lahenduse võlu seisneb selles, et mida rohkem erinevaid objekte on tarvis tuvastada

(ülesande suurem keerukus), seda suurem on efektiivsuse võit võrreldes praeguse süsteemiga.

62

Joonis 33: Võimalus teha tulevikus objektide tuvastamine veel efektiivsemaks. Illustreeriv näide kahe erinevat tüüpi objektide tuvastamisega

3.2 Objektide tuvastus – mitmelõimeline lahendus

Peatükis, kus autor käsitles mitmelõimeliste lahenduste realiseerimise võimalusi Botmaster

platvormis, oli välja toodud võimalik lahendus, mis tõi olemasolevasse süsteemi kaks

täiendust. Esimene nendest, kaadri hankimine eraldi lõimes, sai diplomitöö käigus

realiseeritud, testitud ning dokumenteeritud. Teine, objektide tuvastus eraldiseisvates

lõimedes, on prioriteet, mille elluviimine on kavas juba lähitulevikus.

63

Joonis 34: Kõik objektituvastuse funktsioonid käivitatakse paralleelselt

4 Lõputöö tulemus

Diplomitöö tulemusena:

• Valmis põhjalik tehniline analüüs Botmaster platvormi masinnägemise komponendile.

Lõputöö peatükk 1 sobib õppematerjaliks ning dokumentatsiooniks platvormi

tulevastele arendajatele, kes soovivad keskenduda videotöötluse funktsionaalsuste

täiendamiseks.

• Töötati välja mugav ning usaldusväärne videotöötluse jõudluse mõõtmise metoodika

ning automatiseeritud mõõtmisvahend. Realiseeritud automaattestimise raamistik

võib olla kasutatav tulevikus ka muude ülilühikeste kosteaegadega (0.001-99ms)

süsteemide komponentide jõudluse testimiseks.

• Püstitati kolm hüpoteesi platvormi ning selle tehisnägemise komponendi

allsüsteemide jõudluse tõstmise võimalikkusest.

• Süsteemi täiustati kahe uuendusega, mis parandasid platvormi jõudlust. Tänu

implementeeritud täiendustele, kaks püstitatud hüpoteesi osutusid õigeks.

• Pandi paika edaspidine plaan Botmaster platvormi videotöötluse komponendi

arenduseks. Plaan sisaldab konkreetseid väljapakutuid lahendusi mille realiseerimine

ning testimine annab vastuse kolmandale lõputöös püstitatud hüpoteesile.

Lõputöö eesmärk ehk "Botmaster" platvormi masinnägemise komponendi jõudluse

tõstmine, sai edukalt täidetud. Realiseeritud lahendused aitasid tõsta platvormi jõudlust

kuni 45,5%.

64

5 Kokkuvõte

Diplomitöös lahendatavaks probleemiks on arvutusmahuka ja ajakuluka masinnägemise

komponendi jõudlus ning selle piirav mõju mobiilsete robotite üldisele reageerimisvõimele

ning liikumiskiirusele. Videotuvastuse komponent on osa EIK Robootikaklubi

juhtimisplatvormist Botmaster. Botmaster platvorm on EIK Robootikaklubi poolt disainitud,

aastaid arendatud ning aktiivses kasutuses olev paindlik robootikaplatvorm. Platvormi

kasutavad erinevad rahvusvahelisel robotivõistlusel osalevad robotid. Video töötlemine

reaalajas on kaameraga varustatud robotitele esmaseks sisendiks ümbritseva keskkonna kohta

ning roboti juhtloogika täidab käske vastavalt pilditöötluse väljundile. Sellest tulenevalt

piirab platvormi tehisnägemise komponent olulisel määral roboti summaarset jõudlust.

Madala kaadrisagedusega videotuvastus ei võimalda robotitel reageerida kiirelt muutustele

ümbruskonnas ning kontrollida ennast adekvaatselt suurtel sõidukiirustel. Samuti on madala

kaadrisageduse puhul raske optimeerida roboti liigutuste iseloomu ning vältida eksimuse

võimalusi.

Diplomitöö eesmärgiks oli Botmaster platvormi videotuvastuse jõudluse suurendamine, et

parandada platvormi kasutatavate robotite latentsust. Pildi hankimiseks, töötlemiseks ning

65

objektide tuvastamiseks kuluv lühem kosteaeg annaks EIK robotitele hea eelise teiste

võistlustel konkureerivate robotite ees.

Diplomitöö käigus analüüsis autor probleemi ning uuris mujal maailmas analoogsete

probleemide lahendamiseks kasutatud meetodeid. Ühtlasi töötas autor välja mugava

metoodika Botmaster platvormi videotuvastuse komponendi jõudluse mõõtmiseks ning

analüüsimiseks. Spetsiaalse automatiseeritud mõõtmisvahendi loomine oli osa praktilisest

teostusest. Loodud jõudluse automaattestimise raamistik on väga täpne ning sobib

kasutamiseks ka muude lühikeste kosteaegade mõõtmiseks (<1s). Botmaster platvormi

videotuvastuse komponent jaotati detailselt eraldiseisvateks operatsioonideks. Analüüsimisel

mõõdeti iga kaardistatud protsessi kosteaegu ja selle tulemusena leiti operatsioonid, mida

tasub täiustada. Püstitati kolm hüpoteesi erinevate masinnägemise allsüsteemide kohta: EIK

Robootikaklubi roboti platvormi Botmaster videotuvastuse süsteemis esineb mitmeid

operatsioone, mida on võimalik ning tasub täistada. Eeldatavaks tulemuseks oli roboti

videotöötluse jõudluse kasv, mis väljendub roboti masinnägemise kaadrisageduse tõusus.

Pakuti välja detailsed lahendused platvormi täiustamiseks nii antud diplomitöö raames kui ka

edaspidistes arenduse iteratsioonides. Neljas väljapakutud uuenduses olid aluseks:

protsesside paralleelne täitmine eraldi lõimedes, algoritmide optimeerimine ning vabanemine

liigsetest operatsioonidest. Peale parenduste realiseerimist mõõdeti samades tingimustes ning

samal riistvaral töötava Botmaster platvormi tehisnägemise komponendi kosteaega uuesti.

Mõõtmise käigus selgus, et väljapakutud parendused avaldasid jõudlusele positiivset mõju

ning masinnägemise efektiivsus paranes.

Diplomitöös püstitatud hüpoteesid osutusid õigeks ning seatud eesmärgid said täidetud.

Diplomitöö autoril õnnestus ideaalsetes tingimustes tõsta platvormi efektiivsust kuni 45,5%.

Tegemist on EIK Robootikaklubi jaoks pidevas täiustamisfaasis oleva platvormiga. Autor

seadis paika plaanid seoses edaspidiste süsteemi täiendustega. Botmaster platvormi ning selle

videotöötluse rakenduse arendamine jätkub ka pärast käesoleva diplomitöö valmimist ning

autor kavatseb ka tulevikus uuringutega jätkata ning anda edasi teadmised uutele klubi

liikmetele.

66

6 Enhancement of Real-time Video Processing

Performance based on Estonian Information

Technology College Robotics Club Botmaster Platform

The purpose of this diploma thesis was to increase the performance of real-time video

processing system used in robotics. The system has been developed specially for autonomous

mobile robots based on The Estonian Information Technology College (ITC) robot control

platform called Botmaster. The machine vision feature performs computationally intensive

and time-consuming processes that set limits to overall robots' responsiveness and achievable

moving speeds. Botmaster robot control platform is a flexible software framework designed

by EIC Robotics Club. It has been developed for many years and is being actively used on

different purpose robots that compete on international robotics competitions. Real-time video

processing is the main informational input for high level robots equipped with digital camera.

Robot control logic layer generates behavior commands in accordance with the output of

computer vision component. Therefore the machine vision feature significantly constraints

the overall robot performance. Low framerate does not allow to gain rapid reaction time upon

changes in surrounding environment or obtain stability and control over robot on high

speeds. In addition, low framerate makes it very complicated to optimize the nature of robot's

movements and avoid mistakes robot's behavior.

67

Better latency of frame capture, image processing and object detection would provide an

advantage for EIC robots over other competitive machines.

During the thesis, author analyzed the problem and investigated best practises being used to

solve similar system enhancement challenges around the world. In addition, author

developed a convenient methodology for measurement and analysis of computer vision

performance in Botmaster platform. The design of special automated measurement tool was a

part of the practical realization in this thesis. Created performance automated-testing

framework is extremely accurate (nanosecond precision) and can be used for measuring rapid

latencies (<1s) in other systems. The machine vision component was split in detail into many

separate operations. Every single process and its latency were analysed – several operations

that must be improved were pointed out. Hypoteses were proposed about machine vision

component's sub-processes: computer vision component in Botmaster robot control platform

contains several operations that can and must be improved. An expected result was to achieve

growth in real-time video processing efficiency that would lead to higher framerate of

machine vision.

Author provided detailed system improvement solutions for implementation during this

particular thesis and in future development iterations. Proposed enhancement updates were

based on: concurrent execution of processes in separate threads, optimization of algorythms

and displacement of unnecessary operations. The development of provided solutions was

followed by performance measurement of the system again. Tests were executed in similar

conditions and on the same hardware as the initial system. Performance testing results

displayed that proposed solutions caused positive impact on real-time video processing

performance and efficiency of machine vision had been increased.

Hypotheses proposed in this thesis were proved to be correct and established goal was

achieved. The author of this diploma thesis succeeded in increasing the overall effectiveness

of platform in ideal conditions by approximately 45,5%.

The platform is being continuously techincally complemented by EIC Robotics Club. Author

has arranged development plans for near future. The development of Botmaster platform and

68

its machine vision component will be continued after completion of this thesis and author is

intending to continue researches and provide knowledge to new robotics club members and

developers.

69

7 Kasutatud allikad

1. Silver Kuusik, Eesti Infotehnoloogia Kolledži Robootikaklubi roboti juhtimisplatvormi täiustamine. (2011) Eesti Infotehnoloogia Kolledž, Eesti

2. Ingliskeelsete info- ja sidetehnoloogia terminite seletav sõnaraamat (25.05.2013). [www.vallaste.ee]

3. Intel® Corporation: Intel Image Processing Library - Quick Reference, (1997).

4. Alexander Hornberg (2006). Handbook of Machine Vision. WILEY-VCH Verlag Gmbh & Co KGaA: Weinheim, Germany.

5. Matrox Machine vision, image analysis and medical imaging software development kit (25.05.2013). [http://www.matrox.com/imaging/en/products/software/mil/]

6. Robert Love (2007). Linux System Programming: Talking Directly to the Kernel and C Library. O'Reilly Media: Sebastopol, CA, United States of America.

7. Christopher G. Lasater (2007). Design Patterns. Worldware Publishing, Inc.: Plano, United States of America.

8. Eesti Infotehnoloogia Kolledži Robootikaklubi. Saavutused (24.05.2013). [http://robot.itcollege.ee/?q=node/5]

9. Robotex: Where brains and metal meet (24.05.2013). [www.robotex.ee]

10. Robovision (24.05.2013). [http://wiki.itcollege.ee/index.php/Robovision]

11. Gary Bradski and Adrian Kaehler (2008). Learning OpenCV: Computer Vision with the OpenCV Library. O’Reilly Media, Inc.: Sebastopol, California, United States of America.

70

12. Kujutis: PD Photo.org - Royalty Free, Public Domain, Stock Photos: Grant Tetons Barns (23.05.2013). [http://pdphoto.org/PictureDetail.php?mat=pdef&pg=8145]

13. Mats Röjne (2003). Digital-TV via Mark, Satellit och Kabel. Studentlitteratur: Stockholm, Sweden.

14. Pakhira Malay K (2010). Computer Graphics, Multimedia And Animation. PHI Learning: Kalyani, West Bengal.

15. Kujutis: Arvuti graafika blogi: RGB_varvimudel.jpg (23.05.2013). [http://kristjanigraafika.blogspot.se/2011/01/raster-ja-vektor-varvid.html]

16. Kujutis: Wikimedia Commons, the free media repository: Hsl-hsv models.svg (24.05.2013). [http://commons.wikimedia.org/wiki/File:Hsl-hsv_models.svg]

17. Scott E. Umbaugh (2011). Digital Imaging Processing and Analysis: Human and Computer Vision. Taylor & Francis Group, LCC: Boca Raton, United States of America.

18. Intel Corporation, Willow Garage, Itseez: OpenCV v2.1 documentation, (23.05.2013). [http://opencv.willowgarage.com/documentation/c/genindex.html]

19. Ps3eye Linux (23.05.2013). [https://wiki.itcollege.ee/index.php/Ps3eye_Linux]

20. Kujutis: Photography 101 - Shutter speed, ISO and the exposure triangle: iso_settings_example3.jpg (24.05.2013). [http://zeebytes.blogspot.se/2012/09/photography-101-shutter-speed-iso-and.html]

21. Kujutis: Wikimedia Commons, the free media repository: Halftone,_Gaussian_Blur.jpg (24.05.2013). [http://commons.wikimedia.org/wiki/File:Halftone,_Gaussian_Blur.jpg]

22. Nick D'Ademo: Qt-Opencv-Multithreaded Documentation, (25.05.2013). [http://code.google.com/p/qt-opencv-multithreaded/wiki/Documentation]

23. Bo I. Sandén (2011). Design of Multithreaded Software: The Entity-Life Modeling Approach. John Wiley & Sons Inc.: Hoboken, New Yersey, United States of America.

24. Henry H. Liu (2009). Software Performance and Scalability: A Quantitative Approach. John Wiley & Sons, Inc.: Hoboken, New Jersey, United States of America.

25. Maurizio Gabbrielli, Simone Martini (2010). Programming Languages: Principles and Paradigms. Springer-Verlag: London, England.

26. Mark Summerfield (2010). Advanced Qt Programming: Creating Great Software with C++ and Qt 4. Prentice Hall: New Jersey, United States of America.

27. Digia, Nokia: Qt 4.8 Documentation: QThread Class Reference, (25.05.2013). [http://qt-project.org/doc/qt-4.8/qthread.html]

71