práci - Intelligent and Mobile Robotics Group

Transkript

ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE
FAKULTA ELEKTROTECHNICKÁ
DIPLOMOVÁ PRÁCE
Zpracování obrazu jednočipovým
mikroprocesorem
Praha, 2008
Michal Janouch
i
Poděkování
Chtěl bych poděkovat všem, kteří mi pomohli při tvorbě diplomové práce, hlavně pak ing.
Janu Chudobovi za jeho ochotu, připomínky a cenné rady. Dále pak mým kamarádům a
přátelům, bez kterých by roky na vysoké škole nebyly tak příjemné a nezapomenutelné.
V neposlední řadě pak patří mé velké díky mým rodičům za jejich trpělivost a dlouholetou
podporu.
ii
iii
iv
Abstrakt
Diplomová práce se zabývá problematikou zpracování obrazu v reálném čase se zaměřením
na algoritmy použitelné na jednočipových mikroprocesorech. V teoretické části jsou popsány
obecné postupy zpracování obrazu, příklady dostupných kamerových modulů a v poslední
části je uvedeno několik aplikací s kamerovými moduly řady CMUcam, se kterými je čtenář
podrobně seznámen. Praktická část diplomové práce obsahuje rozbor 3 implementovaných
úloh pro kamerové moduly CMUcam2 a CMUcam3. V závěru práce jsou shrnuty možnosti a
výhody, které přináší použití algoritmů pro zpracování obrazu na samostatných modulech
s jednočipovým mikroprocesorem a je také naznačen další možný vývoj implementovaných
algoritmů a jejich praktické využití.
Abstract
This diploma thesis deals with the problems of real time image processing with focus on
algorithms for single chip controllers. Theoretical part describes a general methods on image
processing, examples of available camera modules and finally the CMUcam modules are
introduced and a few applications using these modules are refered. There is a study of 3
implemented projects for CMUcam2 and CMUcam3 in practical part. The futher possibilities
and benefits brought by usage of algorithms for image processing on single chip modules are
concluded and the futher development and usage of implemented algorithms is suggested.
v
Obsah
1
Úvod .............................................................................................................................. 1
2
Zpracování obrazu ....................................................................................................... 3
2.1
Snímání obrazu ....................................................................................................... 3
2.1.1 CCD snímač ....................................................................................................... 5
2.1.2 CMOS (APS) snímač........................................................................................... 6
2.2
Digitalizace ............................................................................................................ 7
2.2.1 Reprezentace barev ............................................................................................. 9
2.3
2.2.1.1
RGB ........................................................................................................... 9
2.2.1.2
CMY ......................................................................................................... 10
2.2.1.3
HSV .......................................................................................................... 11
2.2.1.4
YCrCb ...................................................................................................... 12
Předzpracování obrazu .......................................................................................... 13
2.3.1 Geometrická transformace ................................................................................ 13
2.3.2 Jasová transformace ......................................................................................... 14
2.3.3 Filtrace a ostření .............................................................................................. 15
2.4
Segmentace obrazu ............................................................................................... 16
2.5
Popis objektů ........................................................................................................ 17
2.6
Klasifikace ........................................................................................................... 17
2.7
Zpracování obrazu v reálném čase ........................................................................ 18
2.7.1 Časová náročnost ............................................................................................. 18
2.7.2 Objem zpracovávaných dat ............................................................................... 18
2.7.3 Závislost na typu osvětlení ................................................................................ 20
2.7.4 Nutná znalost dalších parametrů....................................................................... 20
3
Kamerové moduly s jednočipovým mikroprocesorem ............................................. 21
3.1
The Cognachrome Vision System (CVS) .............................................................. 21
3.2
C-EYE Smart Camera........................................................................................... 22
3.3
AVRCam.............................................................................................................. 23
vi
3.4
UCLA-Cyclops..................................................................................................... 23
3.5
CMUcam .............................................................................................................. 24
3.5.1 CMUcam1 ........................................................................................................ 25
3.5.2 CMUcam2 ........................................................................................................ 25
3.5.3 CMUcam3 ........................................................................................................ 27
3.5.3.1
3.6
4
5
Vývoj aplikací ........................................................................................... 28
Vyhodnocení ........................................................................................................ 28
Aplikace s kamerovými moduly CMUcam ................................................................ 30
4.1
LUV ..................................................................................................................... 30
4.2
Hardcore III .......................................................................................................... 31
4.3
Stolní tenis............................................................................................................ 32
4.4
robuDOG.............................................................................................................. 33
Úlohy pro kamerové moduly CMUcam2 a CMUcam3 ............................................. 35
5.1
Uživatelské rozhraní CMUcam2 ........................................................................... 35
5.1.1 Implementace v jazyce Java .............................................................................. 36
5.1.2 Implementace v jazyce C++.............................................................................. 36
5.2
ÚLOHY ZPRACOVÁNÍ OBRAZU ..................................................................... 37
5.2.1 Sledování barevného objektu robotem ............................................................... 37
5.2.1.1
Rozbor úlohy ............................................................................................ 37
5.2.1.2
Implementace............................................................................................ 38
5.2.1.3
Testování programu .................................................................................. 40
5.2.2 Multi-blob finder .............................................................................................. 41
5.2.2.1
Rozbor úlohy ............................................................................................ 41
5.2.2.2
Implementace............................................................................................ 42
5.2.2.3
Testování algoritmu .................................................................................. 46
5.2.3 GeNav .............................................................................................................. 51
6
5.2.3.1
Rozbor úlohy ............................................................................................ 51
5.2.3.2
Implementace............................................................................................ 53
5.2.3.3
Testování algoritmu .................................................................................. 56
Závěr ........................................................................................................................... 62
vii
7
Použitá literatura a zdroje ......................................................................................... 64
Příloha A. Popis adresářové struktury vývojového prostředí CMUcam3 ....................... 66
Příloha B. Popis API multi-blob finder algoritmu ............................................................ 67
Příloha C. Popis API algoritmu hledání cesty pro systém GeNav ................................... 69
Příloha D. Popis komunikačního protokolu mezi kamerovým modulem CMUcam3 a
řídicím počítačem systému GeNav .................................................................................... 71
viii
Seznam obrázků
Obr. 1: Řetězec lidského vnímání obrazu ............................................................................... 1
Obr. 2: Řetězec strojového zpracování obrazu ........................................................................ 2
Obr. 3: Upravený řetězec zpracování obrazu při použití mikropočítače .................................. 2
Obr. 4: Geometrie perspektivního promítání modelovaného dírkovou komorou ..................... 4
Obr. 5: Schéma zobrazení předmětu na fotosensor v kameře .................................................. 5
Obr. 6: Schéma funkce CCD čipu jako posuvného registru .................................................... 6
Obr. 7: Schéma CMOS snímače s aktivním tranzistorem........................................................ 7
Obr. 8: Čtvercová a hexagonální mřížka ................................................................................. 8
Obr. 9: Okolí okamžitého obrazového bodu ve 4-okolí a 8-okolí ............................................ 8
Obr. 10: RGB a CMY barevný model rozprostřený do roviny .............................................. 10
Obr. 11: Reprezentace HSV modelu v kónickém zobrazení .................................................. 11
Obr. 12: Příklad geometrické transformace v rovině ............................................................. 13
Obr. 13: Příklad obrazů před a po ekvalizaci včetně příslušných histogramů ........................ 16
Obr. 14: The Cognachrome Vision Systém........................................................................... 22
Obr. 15: C-EYE Smart Camera ............................................................................................ 22
Obr. 16: AVRCam ............................................................................................................... 23
Obr. 17: UCLA-Cyclops ...................................................................................................... 24
Obr. 18: CMUcam1 ............................................................................................................. 25
Obr. 19: CMUcam2 ............................................................................................................. 26
Obr. 20: Schematický nákres CMUcam2 .............................................................................. 26
Obr. 21: CMUcam3 ............................................................................................................. 27
Obr. 22: Schematický nákres CMUcam3 .............................................................................. 28
Obr. 23: Schéma řídicího machanizmu LUV ........................................................................ 31
Obr. 24: Fotografie robotu Hardcore III s připojenou CMUcam ........................................... 32
Obr. 25: Systém pro odpalování ping-pongových míčů s CMUcam umístěnou nad hracím
stolem .................................................................................................................................. 33
Obr. 26: robuDOG s CMUcam3 umístěnou v díře v hlavě .................................................... 34
Obr. 27: G2BOT s CMUcam2 a krabicí použitou při testování algoritmu .............................. 38
Obr. 28: Vývojový diagram aplikace sledování barevného objektu ....................................... 40
ix
Obr. 29: Příklady možných barevných značek pro identifikaci objektu ................................. 41
Obr. 30: Příklady ohraničení objektů v obraze ...................................................................... 42
Obr. 31: Možné kombinace pro určení příslušnosti sekvence správných pixelů k objektu ..... 44
Obr. 32: Vývojový diagram pro aplikaci multi-blob finder ................................................... 45
Obr. 33: Výsledky multi-blob finder algoritmu..................................................................... 48
Obr. 34: Příklad obrazu pro testování multi-blob finder algoritmu v reálné scéně ................. 50
Obr. 35: Příklad rozložení objektů, kdy jsou 2 z nich v zákrytu ............................................ 50
Obr. 36: Robot Pioneer 3AT s CMUcam3 na sloupku nad robotem ...................................... 52
Obr. 37: Blokové schéma systému GeNav ............................................................................ 53
Obr. 38: Vývojový diagram algoritmu hledání cesty pro systém GeNav ............................... 55
Obr. 39: Rozhodovací algoritmus pro příslušnost pixelu k cestě ........................................... 56
Obr. 40: Cesta a její střed vyznačený pomocí testovacích dat z algoritmu hledání cesty v
systému GeNav .................................................................................................................... 57
Obr. 41: Výsledek algoritmu hledání cesty aplikovaný pomocí definovaných oblastí ........... 57
Obr. 42: Zdrojový obraz pro testování doby hledání cesty .................................................... 59
Obr. 43: Oddělení cesty od okolí pro systém GeNav ve venkovním prostředí ....................... 60
x
Seznam tabulek
Tabulka 1: Parametry vzorové kamery ................................................................................. 18
Tabulka 2: Přenosové rychlosti používaných rozhraní u digitálních kamer ........................... 19
Tabulka 3: Porovnání doby hledání objektů v obraze ........................................................... 47
Tabulka 4: Čas potřebný pro vyhledání cesty v obraze v závislosti na různém nastavení
algoritmu ............................................................................................................................. 58
xi
Seznam zkratek
CCD - charge-coupled device
CMOS - Complementary Metal–Oxide–Semiconductor
APS - active pixel sensor
RGB – Red, Green, Blue
CMY – Cayan, Magneta, Yellow
HSV – Hue, Saturation, Value
YCrCb – luminance, red chrominance, blue chrominance
W – width (šířka)
H – height (výška)
bpp – bit per pixel
fps – frame per second
IEEE - Institute of Electrical and Electronics Engineers, Inc.
USB – Universal serial bus
RS232 - Recommended Standard 232
LED - light-emitting diode
AWB – automatic white balance
AGC – automatic gain control
HW – hardware
SW – software
RAM – Random Access Memory
ROM – Read Only Memory
FAT - File Allocation Table
TCP/IP – Transfer Control Protocol/Internet Protocol
TTL - Transistor–transistor logic
CC2 – CMUcam2
CC3 – CMUcam3
FIFO – first in, first out
GPIO – General Purpose Input Output
xii
SPI – Serial Peripheral Interface
I2C – Inter-Integrated Circuit
jpeg - Joint Photographic Experts Group
ppm - Portable PixMap
API - Application programming interface
xiii
1 Úvod
Jednou ze základních lidských vlastností je zrak. Očima vnímáme obraz světa kolem nás.
Jasová informace zachycená na sítnici oka se přenáší do mozku, kde je zpracována a
vyhodnocena. Na základě toho pak dokážeme určit, co vidíme, jak významné to pro nás
v daném okamžiku je, popř. za použití dalších smyslů jako je hmat, určit i jiné vlastnosti
předmětu zájmu, např. teplotu nebo kvalitu povrchu. Na obr. 1 je zakreslen jednoduchý
řetězec lidského vnímání obrazu.
Oko
Sítnice
Mozek
Vyhodnocení
obrazu
Použití dalších smyslů k upřesnění
vlastností objektu zájmu
Obr. 1: Řetězec lidského vnímání obrazu
Počítačové vidění je obor, jehož cílem je, aby celý proces na obr. 1 byl nahrazen strojovým
zpracováním obrazu, které má za úkol snímanému obrazu porozumět a interpretovat ho jako
model reálného světa. Počítačové vidění nám tak umožňuje nejen obraz automaticky
rozpoznat a vyhodnotit, ale často funguje i jako nástroj pro vizualizaci lidskému oku
neviditelných veličin, které je pak možné reprezentovat do podoby vyhodnotitelné člověkem.
Jak je vidět na obr. 2, existuje mezi strojovým a lidským vnímáním přímá analogie.
V závislosti na typu snímače obrazu můžeme získat nejrůznější informace o obraze. Jedná se
např. o snímání tepla (termovize), magnetického pole (tomograf), rentgenového záření (RTG),
ultrazvuk (sonary) a v neposlední řadě také jas a barva obrazu (fotoaparáty). Zejména
v lékařských aplikacích, kde se musí sejmutá data vhodně vizualizovat, je jejich objem ke
zpracování velký, a proto je nutné používat pro vyhodnocování informací v obraze velmi
výkonnou výpočetní techniku. Je jasné, že úměrně výkonu se zvyšuje jak cena, tak i velikost
takovéhoto zařízení. Navíc je nutné zajistit odpovídající přenosovou cestu mezi snímačem a
počítačem.
1
Objektiv
Snímač
obrazu
Počítač
Vyhodnocení
obrazu
Použití dalších senzorů k upřesnění
Obr. 2: Řetězec strojového zpracování obrazu
Existují ovšem aplikace, kdy není možné použít pro přímé vyhodnocení obrazu výkonný
počítač. Budeme-li uvažovat robotické aplikace, může se jednat např. o robot, který má
pomalou komunikační linku s řídicí centrálou a jeho rozměry a kapacita baterií neumožňují
použít počítač přímo na těle robotu. Zde tedy přichází na řadu využití malých kamer
propojených s mikropočítačem, který obraz vyhodnotí a po komunikační lince posílá pouze
malý objem dat s potřebnými informacemi. Modifikovaný řetězec zpracování obrazu
s použitím mikropočítače je na obr. 3.
Objektiv
Snímač
obrazu
mikropočítač
Vyhodnocení
obrazu
Řídicí počítač
Použití dalších senzorů k upřesnění
Obr. 3: Upravený řetězec zpracování obrazu při použití mikropočítače
Je zřejmé, že vzhledem k výkonu a paměťovým možnostem mikropočítačů není možné
implementovat složité vyhodnocovací algoritmy, které je možné provádět na výkonných
počítačích.
Cílem této práce je najít možnosti, jak efektivně implementovat základní algoritmy pro
zpracování a vyhodnocování snímaného obrazu pomocí jednočipového mikroprocesoru. Dále
pak implementovat aplikace, které budou získané informace využívat k autonomnímu řízení
procesů (např. robotu) nebo je bude možné začlenit do větších systémů, kde budou samostatně
vyhodnocovat obraz a data dále předávat řídicímu počítači.
2
2 Zpracování obrazu
Obecně lze zpracování obrazu chápat jako převod „analogového“ obrazu světa kolem nás do
digitální podoby a jeho další zpracování. Celý proces lze rozdělit do několika kroků. Jejich
rozdělení ovšem není zcela jednoznačné a záleží na konkrétní aplikaci, zda budou provedeny
všechny zde uvedené body a v jakém pořadí. Podrobnými postupy zpracování obrazu se
zabývají práce [1] a [2].
Posloupnost základních kroků zpracování obrazu je:
Snímání
Digitalizace
Předzpracování
Segmentace
Popis objektů
Klasifikace
2.1 Snímání obrazu
Z fyzikálního hlediska můžeme snímání obrazu chápat jako převod vstupní veličiny na
elektrický signál spojitý v čase i úrovni. Vstupní veličinou nemusí být jen jas z kamery, ale
může to být např. i intenzita rentgenového záření, tepelná intenzita, nebo ultrazvuk. Dále
v textu budeme jako vstupní veličinu uvažovat výhradně jas z kamery.
Z geometrického hlediska je snímaní obrazu převod trojrozměrného (3D) obrazu světa kolem
nás do dvojrozměrné (2D) podoby. Tento převod je výsledkem perspektivního zobrazení,
neboli středového promítání. Toto zobrazení je závislé na vlastnostech snímací optiky
(objektiv), ale pro zjednodušení je často modelováno dírkovou komorou, viz obr. 4.
Nechť na obr. 4 jsou x, y, z souřadnice bodu P v 3D scéně a f je vzdálenost obrazové roviny
od středu promítání1. Bod promítnutý do 2D scény nechť má souřadnice x´, y´, potom platí:
1
U objektivů je f rovno ohniskové vzdálenosti
3
(2.1)
Obr. 4: Geometrie perspektivního promítání modelovaného dírkovou komorou, převzto z [3]
Důležitým faktorem ovlivňujícím kvalitu snímaného obrazu jsou externí vlivy jako osvětlení,
povrchové vlastnosti předmětu, tvar předmětu, aj. Znalost těchto vlastností nám pak může
pomoci při zpětné rekonstrukci 3D obrazu z nasnímané scény. Podrobně je jejich vliv na
výsledný obraz popsán v [1].
Aby bylo možné pomocí kamery jas sejmout a převést na elektrický signál, je nutné použít
fotocitlivé snímače dopadajícího světelného záření, viz obr. 5. V dnešní době jsou
nejrozšířenější 2 technologie výroby těchto snímačů:
CCD
CMOS
4
Obr. 5: Schéma zobrazení předmětu na fotosensor v kameře
2.1.1 CCD snímač
Hlavním prvkem každého čidla CCD snímače je Schottkyho dioda, která převádí světelnou
energie na elektrickou. Tímto se v připojených kondenzátorech nahromadí energie úměrná
dopadajícímu záření. CCD čip pak funguje jako analogový posuvný registr. Každý
kondenzátor předává svůj nahromaděný náboj do sousedního kondenzátoru. Poslední z nich je
napojen na výstupní zesilovač, který náboj převádí na elektrické napětí a pomocí A/D
převodníku je toto převedeno do digitální podoby. Schéma CCD čipu je na obr. 6.
Výhody CCD technologie
Velká citlivost
Malý šum
Nevýhody CCD technologie
Vzájmné ovlivňování sousedních pixelů
Malý rozsah intenzit
Nemožnost adresovat jednotlivé pixely
Tato technologie se dnes používá spíše u komerčních nebo profesionálních kamer, kde je
možné docílit větší plochy CCD čipu. Navíc se stále více používa technologie 3-CCD, která
má pro každou barevnou složku RGB signálu vlastní čip.
5
Obr. 6: Schéma funkce CCD čipu jako posuvného registru
2.1.2 CMOS (APS) snímač
Každý pixel CMOS čipu obsahuje fotodiodu, která je napojena na tzv. aktivní tranzistor.
Úměrně velikosti dopadajícího záření se na tranzistoru nahromadí elektrická energie.
Tranzistor je napojen na čtecí a resetovací obvod (obr. 7). Matice takovýchto detektorů tvoří
snímač.
Výhody CMOS snímačů
Náhodný přístup k pixelům
Levné na výrobu
Možnost mít kameru i procesor na jednom čipu
Větší rozsah intenzit než CCD (asi 2x)
Velká rychlost vyčítání
Menší spotřeba než CCD
Nevýhody CMOS
Větší šum než CCD
Tento typ kamer se díky možnosti integrace na jeden čip společně s procesorem používá u
malých kamer pro embedded systémy, v průmyslových kamerách apod.
6
Obr. 7: Schéma CMOS snímače s aktivním tranzistorem
2.2 Digitalizace
Ze snímačů jasu získáme spojitý elektrický signál. Digitalizace je proces převedení tohoto
signálu do digitální podoby.
Digitální obraz je ekvivalentem spojité obrazové funkce f(x, y), kde x a y jsou souřadnice bodu
v obrazové rovině. Je získán vzorkováním obrazu do matice MxN bodů a kvantováním spojité
jasové úrovně každého vzorku do K úrovní. Čím jemnější je vzorkování (čím větší M, N) a
kvantování, tím lépe je aproximován původní spojitý obrazový signál.
Vzorkování spojité funkce musí splňovat Shannonův teorém. Pro zpracování obrazu z něho
plyne, že nejmenší detail v digitálním obraze musí být minimálně dvojnásobkem
vzorkovacího intervalu. Volba vhodného rozlišení je tedy jeden z nejzásadnějších kroků
digitalizace. Při nízkém rozlišení se nám v obraze bude ztrácet informace o detailech a při
velkém se bude zvyšovat následná výpočetní náročnost.
Většina systémů používá kvantování jasu do K stejných úrovní. Je-li pro reprezentaci
informace o obrazovém elementu použito b bitů, je počet úrovní jasu K=2b. Počet úrovní se
volí tak, aby nedocházelo k falešným obrysům. Tento jev pro lidské oko nastává pro počet
kvantizačních úrovní K<50. Tuto hodnotu lze snížit např. použitím nelineárního kvantování.
Další důležitou součástí digitalizace je volba vzorkovací mřížky. Nejčastěji používané jsou
čtvercová nebo hexagonální (obr. 8). Čtvercová mřížka je snadno realizovatelná, ale jsou s ní
spojeny problémy s měřením vzdáleností a spojitostí pixelů. Tyto nedostatky řeší hexagonální
7
mřížka, která ale není vhodná pro některé operace, jako je např. Fourierova transformace.
Podrobnější informace např. v [1]. Dále budeme uvažovat jen čtvercovou vzorkovací mřížku.
Obr. 8: Čtvercová a hexagonální mřížka
S digitalizací obrazu a vzorkovacími mřížkami je dále spojeno několik pojmů a vlastností,
které je nutné vysvětlit:
Pixel – nejmenší a dále již nedělitelný element digitálního obrazu nesoucí informaci o
odpovídajícím obrazovém bodě.
Sousednost pixelů – dva pixely jsou 4-sousedy pokud je jejich vzdálenost D4=1.
Případně jsou 8-sousedy, pokud je jejich vzdálenost D8=1.
Vzdálenost dvou obrazových bodů (x,y) a (h, k) je definována jako
Obr. 9: Okolí okamžitého obrazového bodu ve 4-okolí a 8-okolí
(2.2)
(2.3)
8
Oblast – souvislá množina pixelů navzájem propojených relací sousedství
Souvislé pixely – jsou takové, mezi nimiž existuje cesta
2.2.1 Reprezentace barev
Důležitým parametrem obrazu je jeho barva. Každý pixel nese informaci o všech jednotlivých
složkách použitého barevného spektra kvantovaného do K intervalů. Nejběžněji používané
barevné modely jsou:
RGB
CMY
HSV
YCrCb
2.2.1.1 RGB
RGB je aditivní model fungující na principu míchání světelného záření 3 základních barev
RGB (červená, zelené, modrá). Každá výsledná barva je specifikována mohutností těchto tří
komponent, nejčastěji v rozmezí 0-255. Jsou-li zastoupeny všechny složky s plnou intenzitou,
získáme bílou barvu, je-li intenzita všech složek nulová, získáme černou barvu. RGB model je
zobrazen na obr. 10.
Nejčastěji se tento model používá v zobrazovacích zařízeních (TV, LCD, projektory), kdy je
jeden pixel reprezentován třemi velmi blízkými body jednotlivých složek a podle úrovně
jejich intenzity získáváme na obrazovce požadovanou barvu. Protože jde o míchání
světelného záření, nepotřebují zařízení fungující na principu RGB modelu žádný další vnější
zdroj světla.
9
Obr. 10: RGB a CMY barevný model rozprostřený do roviny
2.2.1.2 CMY
Je subtraktivní barevný model založený na principu míchání tyrkysová (C), purpurové (M) a
žluté (Y) barvy. Mícháním jsou od sebe barvy odečítány, a tedy barevné spektrum odrážející
se od povrchu je omezováno. Vztah mezi RGB a CMY je
(2.4)
Z něho plyne, že je-li intenzita všech složek maximální, získáme černou barvu a je-li nulová,
získáme barvu bílou. Rozložení barevného spektra je na obr. 10.
Tento model se nejčastěji používá v tiskárnách a reprodukčních zařízeních (při tisku bílých
ploch na bílý papír není spotřebována žádná barva), kde se ke třem zmíněným složkám dále
přidává ještě černá barva, která by jinak vznikla smícháním všech tří složek. Tento model je
nazýván CMYK.
10
2.2.1.3 HSV
HSV barevný model nejvíce odpovídá lidskému vnímání barev. Skládá se ze tří složek:
H – hue (barevný odstín) – udává polohu barevného odstínu na standardním barevném
kole (360° = červená, 120° = zelená, 240° = modrá).
S – saturation (nasycení) – v procentech udává množství šedi v poměru k odstínům barvy
V – value (jas) – relativní světlost nebo tmavost barvy.
Nejlépe je barevné spektrum vyjádřené hodnotami HSV vidět na kónickém modelu na
obr. 11.
Obr. 11: Reprezentace HSV modelu v kónickém zobrazení
Převod z RGB spektra do HSV je výpočetně náročný kvůli nelineárnímu výpočtu H
(2.5)
(2.6)
(2.7)
Výpočetní náročnost lze snížit použitím rozhodovacího algoritmu pro převod:
Nechť R,G,B leží v intervalu [0, 1].
11
Nechť max je nejvyšší hodnota z R,G,B.
Nechť min je nejnižší hodnota z R,G,B.
(2.8)
(2.9)
(2.10)
Tento model je používán v počítačovém vidění, protože jej lze lépe přizpůsobit okolním
podmínkám (změna osvětlení odpovídá změně jednoho parametru).
2.2.1.4 YCrCb
YCrCb je subtraktivní model podobně jako CMY. Je složen z jasové složky Y a dvou
chromatických složek.
Převod z RGB spektra do YCrCb je definován
(2.11)
(2.12)
(2.13)
Tento model se využívá v oblasti digitálních fotoaparátů a speciálních videozařízeních
(pomaloběžná televize). Využívá se zejména možnosti jednoduše oddělit černobílý obraz,
který je reprezentovaný jasovou složkou a informaci o barvě, která je reprezentována dvěma
chroma parametry (sytost červené a modré barvy).
12
2.3 Předzpracování obrazu
Cílem předzpracování digitalizovaného obrazu je odstranění zkreslení, které může vzniknout
při samotném pořizování obrazu, odstranění šumu, zvýšení kontrastu a zdůraznění
charakteristik obrazu důležitých pro další zpracování (např. detekce hran).
Zde jsou uvedeny pouze základní postupy. Další podrobnosti o problematice předzpracování
obrazu jsou např. v literatuře [1], [2], [3].
Nejčastěji se jedná o:
Geometrické transformace
Jasové transformace
Filtrace a ostření
2.3.1 Geometrická transformace
Popisuje transformaci nosiče obrazové funkce f(x,y), tj. souřadnic x, y při rotaci, zvětšení,
posunu a dalších složitějších typech zkreslení. Výsledný obraz vzniká transformací vstupního
obrazu pomocí vektorové funkce T, která zobrazí bod se souřadnicemi (x, y) na souřadnice
(x´, y´) podle rovnice 2.14. Určení T může být při složitých typech zkreslení obtížné.
Významné usnadnění práce nám může přinést co největší znalost podmínek pořízení snímků.
Obr. 12: Příklad geometrické transformace v rovině
(2.14)
13
Geometrická transformace se skládá ze dvou kroků:
Transformace souřadnic – počítá novou polohu bodu (x, y) ve spojitých souřadnicích.
Pro tento účel se zavádějí tzv. homogenní souřadnice bodu, které umožňují vyjádřit
rotaci, posun a afinní transformaci jako součin bodu s jedinou maticí. Transformační
vztah je pak vyjádřen rovnicí
(2.15)
aproximace jasové funkce – určuje hodnotu jasu ve výsledném obraze v bodě (x´, y´).
Transformované souřadnice (x´, y´) často leží mimo pravoúhlou vzorkovací mřížku.
Proto je nutné hodnoty jasu z původního obrazu vhodně aproximovat. Nejčastěji
používané typy aproximací pro jasovou funkci jsou:
o Nejbližší soused – přiřadí bodu (x´, y´) hodnotu jasu nejbližšího bodu gs
v diskrétní mřížce původního obrazu
(2.16)
o Lineární interpolace – výslednou hodnotu jasu získáme lineární kombinací
nejbližších 4 bodů diskrétní mřížky. Čím je bod dále, tím menší má na
výsledný jas vliv.
(2.17)
kde
(2.18)
o Bikubická interpolace – jasová funkce je lokálně interpolována pomocí
bikubického polynomu z 16 bodů v okolí.
2.3.2 Jasová transformace
Slouží k úpravě jasu obrazu např. pro lepší zřetelnost detailů pro člověka (tomografie). Je-li
ale obraz určen ke zpracování pouze počítačem, nepřináší jasová korekce žádnou novou
informaci.
14
Jasová korekce umožňuje eliminovat vliv zkreslení jasu při průchodu optickou soustavou.
Pokud je chyba systematická, je možné vytvořit korekční matici a tu při každé úpravě
k získanému obrazu přičítat. Pokud chyba systematická není, je nutné najít korekci pro každý
jasový bod zvlášť.
Transformace jasové stupnice se oproti jasové korekci netýká jednotlivých pixelů, ale
upravuje obraz jako celek.
Ekvalizace histogramu2 - metoda slouží ke zvýšení kontrastu využitím celého spektra
jasové stupnice. Obraz je jasově normalizován3, což je výhodné např. pro srovnávání
obrazů. Výsledek ekvalizace histogramu je vidět na obr. 13.
2.3.3 Filtrace a ostření
Tato fáze si klade za cíl odstranit z digitalizovaného obrazu šum a zviditelnit špatně
rozpoznatelné části.
Filtraci obrazu lze provádět ze dvou pohledů
Filtrace v prostorové oblasti – lineární kombinace vstupního obrazu s koeficienty filtru
(konvoluce)
Filtrace ve frekvenční oblasti – převod obrazu do „frekvenční reprezentace“, následná
úprava a poté převod zpět. Pro převod se používá několika technik jako např.
Fourierova transformace, diskrétní kosinová transformace nebo vlnková transformace.
Filtraci pak zajistí běžné filtry typu horní, dolní a pásmová propust.
2
Histogram je sloupcový graf zobrazující četnosti pixelů připadajících na odpovídající ekvalizační část spektra
3
Jasové úrovně jsou zastoupeny přibližně stejně četně
15
Obr. 13: Příklad obrazů před a po ekvalizaci včetně příslušných histogramů
2.4 Segmentace obrazu
Segmentace obrazu je skupina metod, které slouží k interpretaci částí obrazu jako objektů.
Objektem je zde míněno vše, co je pro další zpracování zajímavé (v závislosti na úloze to
mohou být oblasti, hrany, aj.). Zbývající části obrazu jsou považovány za pozadí. Výstupem
segmentace je seznam objektů, které odpovídají objektům zájmu v reálném světě.
Pokud objekty odpovídají realitě přesně, hovoříme o úplné segmentaci (nutná znalost
řešeného problému – metody učení). Pokud objekt určujeme např. na základě homogenity
pixelů a nalezený objekt neodpovídá realitě přesně, hovoříme o částečné segmentaci. Úplná
segmentace tedy popíše kruh např. polohou středu a poloměrem, zatímco částečná segmentace
najde pouze čtverec, který kruh ohraničuje.
16
Metody segmentace obrazu jsou např:
Segmentace založená na detekovaných hranách – dokáže najít objekty ohraničené
čarami. Problémem jsou hrany, které jsou blízko u sebe.
Segmentace na základě oblastí – nalezne oblasti se stejnými vlastnostmi a oddělí je od
pozadí. Příkladem je mean shift algoritmus, který je popsán v [1], [4].
2.5 Popis objektů
V této části zpracování obrazu je úkolem popsat soubor objektů získaných segmentací. Jsou
zde možné 2 přístupy:
Kvantitativní – číselné charakteristiky nalezených objektů jakou jsou souřadnice,
velikost, kompaktnost, barevný rozptyl, aj.
Kvalitativní – preferuje relace mezi objekty (tvarová podobnost). Výstup je závislý na
postupu při klasifikaci.
2.6 Klasifikace
Rozpoznávání popsaných objektů a jejich zařazení do příslušných skupin známých tříd je
úkolem klasifikace. Podle postupu může být klasifikace:
Příznaková – je spojena s kvantitativním popisem objektů. Využívá příznaky, což jsou
skupiny charakteristických čísel objektu popisujících jeho vlastnosti (velikost, střed,
poloha, atd.). Klasifikace probíhá na základě učení klasifikátoru a to s trénovací
množinou i bez ní. Další často používaná metoda klasifikace je shluková analýza.
Strukturální – jedná se o kvalitativní popis pomocí primitiv objektu, tj. objektu jsou
přiřazeny základní vlastnosti, které objekt charakterizují. Na tyto vlastnosti jsou pak
aplikovány algoritmy rozboru slova popisujícího objekt a kontroly syntaxe pro
definovanou gramatiku, jazyk a abecedu.
17
2.7 Zpracování obrazu v reálném čase
Zpracování obrazu v reálném čase sebou nese řadu problémů, se kterými musíme při
implementaci počítat.
2.7.1 Časová náročnost
Obecně lze říci, že největším omezením je časová náročnost, a to zejména ve fázi
předzpracování a segmentace obrazu. Je nutné si již před implementací algoritmů uvědomit,
jaké informace nás budou zajímat, jak je nutné obraz pro segmentaci připravit a vhodně
navrhnout algoritmy segmentace, aby byly co možná nejefektivnější a využívali nejmenší
nutné množství dat.
2.7.2 Objem zpracovávaných dat
Tento problém přímo souvisí již se samotným snímáním a digitalizací obrazu. Tabulka 1
ukazuje parametry pro modelovou kameru. Z rovnice
(2.19)
získáme objem dat, který je nutné přenést za jednotku času.
Rozlišení obrazu (WxH)
640x480
Počet snímků za vteřinu (fps)
15
Počet úrovní jasu (bpp)
8 bitů (256 úrovní)
Počet barevných kanálů (Chan)
3 (např. RGB)
Tabulka 1: Parametry vzorové kamery
Je patrné, že takto velký objem dat klade ohromné nároky na přenosovou cestu mezi kamerou
a počítačem, na kterém bude obraz dále zpracováván. Nejčastěji používaná rozhraní jsou
uvedena v tabulce 2. Pro zajímavost je uvedeno i standardní sériové rozhraní RS232, které se
používá pro komunikaci s mikroprocesory. Je patrné, že pro přenos kompletního obrazu je
RS232 nepoužitelná.
18
Název rozhraní
Teoretická propustnost
FireWire (IEEE 1394a)
400Mbit/s
FireWire (IEEE 1394b)
800Mbit/s
USB2.0
480 Mbit/s
RS232
až 115kbit/s
Tabulka 2: Přenosové rychlosti používaných rozhraní u digitálních kamer
Dalším problémem spojeným s objemem dat je paměťová náročnost. Ve fázi předzpracování
a segmentaci obrazu je nutné mít jej stále k dispozici, proto a pro něj vyhradit místo v paměti.
Řešení problému objemu dat je několik a přímo vyplývají z rovnice 2.19. Jedná se o:
Snížení rozlišení při snímání obrazu – je dobré si uvědomit, jak velké jsou nejmenší
detaily ve zkoumaném obraze a podle toho určit minimální rozlišení. Některé CMOS
kamery díky možnosti přístupu k libovolným pixelům umožňují měnit rozlišení
nezávisle v obou osách (downsampling).
Snížení fps – počet snímků potřebných za jednu sekundu závisí hlavně na aplikaci, pro
kterou je snímek pořizován. Pokud se jedná např. o řízení systému (robotu), pak
potřebujeme mít informací o okolí co nejvíce; naopak např. pro aplikace typu
bezpečnostní kamery nám postačí jen několik snímků za vteřinu.
Snížení bpp – zde záleží hlavně na vlastnostech snímaného obrazu a na postupu jeho
dalšího zpracování. Někdy nám může postačit čistě binární úroveň jasu, v některých
měřících systémech se pak jeden vzorek může reprezentovat i 12-ti a více bity.
Snížení počtu barevných kanálů – v řadě aplikací nám postačí jen jasová složka (např.
detekce hran).
V kombinaci se snížením rozlišení je možné jako řešení uvažovat i použití CMOS
kamery společně s mikroprocesorem a obrazovou pamětí na jedné desce. Obrazová
data pak mohou být vyčítána velmi rychle. Po sériové lince pak již není nutné posílat
objemná obrazová data, ale pouze potřebné informace o objektech v obraze.
19
2.7.3 Závislost na typu osvětlení
Problém závislosti na typu osvětlení se týká zejména fáze předzpracování obrazu.
Každý druh osvětlení (sluneční světlo, LED, žárovka, zářivka, aj.) má jinou vlnovou délku i
tvar spektra, a proto je jeho vliv na fotocitlivé části snímačů různý. Kamery typu CMOS
většinou nabízejí automatické funkce pro korekci bílé barvy (AWB), regulaci zesílení (AGC)
nebo nastavení doby závěrky. V některých případech ovšem není použití těchto funkcí
vhodné. Jedná se o úlohy, kdy je třeba porovnávat snímky pořízených vždy za stejných
podmínek. Automatické nastavování parametrů pro každý snímek totiž může mít za následek
nedefinovatelné změny v parametrech obrazu.
Pokud tyto funkce nejsou podporovány, je vhodné použít algoritmy pro korekci jasu a barev.
Vyžaduje-li úloha rozpoznávání barev v obraze, pak jsou výsledky na změny parametrů
osvětlení ještě citlivější. Pro tento účel je důležité použít vhodný barevný model reprezentace
dat. Např. při změně intenzity osvětlení se v RGB spektru často výrazně změní všechny 3
hodnoty specifikující barvu, zatímco v HSV spektru dojde k výrazné změně pouze parametru
V a zbylé dva se změní jen velmi málo.
2.7.4 Nutná znalost dalších parametrů
Častým problémem segmentace a klasifikace obrazu je nutná znalost dalších parametrů
objektu zájmu nebo podmínek snímání. Tyto znalosti nám umožní najít a klasifikovat hledaný
předmět mnohem rychleji a přesněji. Také jsou velmi důležité při případné rekonstrukci
obrazu. K získání těchto informací nám slouží doplňkové senzory a čidla (sonary, laserové
měřiče vzdáleností, luxmetr, teplotní čidla, aj.).
20
3 Kamerové moduly s jednočipovým
mikroprocesorem
Na trhu existuje celá řada systémů pro zpracování obrazu, které jsou již předpřipravené pro
různé aplikace. Jedná se o moduly sloužící k monitorování prostředí, detektory pohybu,
rozpoznávání objektů nebo jako multikamerové systémy. Často jsou tyto moduly doplněny o
další senzory. Bližší specifikace těchto produktů je k nalezení např. na webové stránce [5].
Zde se budeme zabývat moduly, které je možné použít pro studijní účely s přihlédnutím
k robotickým aplikacím. Popsané moduly jsou pouze výběrem z mnoha, které jsou k dispozici
a mají za úkol ukázat možnosti, které různé moduly nabízejí.
3.1 The Cognachrome Vision System (CVS)
CVS [6] je systém vyvinutý v Newton Research Labs. S použitím speciální HW akcelerace je
schopný sledovat až 25 objektů s frekvencí až 60Hz při rozlišení 200x250 pixelů a 8 bpp. Je
založen na mikroprocesoru Motorola řady 68332 s 256KB RAM. Poskytuje 1 digitální I/0, 2
asynchronní a 1 synchronní sériovou linku. Dále je k dispozici ve speciálním duálním
zapojení, které umožňuje použít tento modul pro aplikace stereovidění.
Modul je standardně dodáván s SW pro sledování objektů. Je však možné jej libovolně
přeprogramovat s využitím jazyka C.
Největší nevýhody CVS jsou velká spotřeba (až 2W), vysoká cena ($2450) a větší rozměry
(64x160x32mm).
Tento modul byl s výhodou použit v soutěži robotického fotbalu v kategorii MIROSOT pro
sledování a vyhledávání hráčů a míče.
21
Obr. 14: The Cognachrome Vision Systém, převzato z [6]
3.2 C-EYE Smart Camera
C-EYE [7] je malý a levný kamerový modul založený na 16bitovém procesoru řady x86
(186). Spolu s procesorem je na desce CMOS kamerový senzor s maximálním rozlišením
640x480 pixelů. Modul je dodáván s programovacím prostředím a aplikací pro ukládání
snímků. Je plně programovatelný s podporou kódů v jazyce C/C++.
Velkou předností C-EYE je možnost rozšíření o řadu portů, konkrétně o RS485,
CompactFlash rozhraní s podporou FAT16 a ethernetového rozhraní s podporou TCP/IP
umožňující propojení více těchto modulů na jednu síť.
Spotřeba se pohybuje v rozmezí od 1-1,5W a cena je mezi $179-$239 v závislosti na
připojených periferiích.
Obr. 15: C-EYE Smart Camera, převzato z [7]
22
3.3 AVRCam
AVRCam [8] je plně programovatelný kamerový modul založený na procesoru Atmel AVR
mega8. Obraz je snímán CMOS kamerou Omnivision OV6620 s rozlišením 88x143 pixelů.
Spotřeba je 300mW.
Modul je dodáván se SW pro sledování, který je schopný najít až 8 objektů stejné barvy
v obraze s rychlostí 30 fps. Dále je dodáván programátor s kompilátorem jazyka C a zkušební
aplikace.
Cena kompletního setu je $100.
Obr. 16: AVRCam, převzato z [8]
3.4 UCLA-Cyclops
Kamerový modul UCLA-Cyclops [9] je konstruován jako bezdrátový a je určen pro vytvoření
sítě senzorů. Zajímavostí také je, že pro zpracování obrazu sejmutého CMOS
kamerou ADCM-1700 nepoužívá pouze procesor ATMEL ATmega128L, ale stejně jako
např. v projektu [10] je použito programovatelné logické pole FPGA.
Nevýhodou tohoto řešení je malé rozlišení (128x128) a zejména pak pomalý proces
zpracování obrazu (2fps).
23
Obr. 17: UCLA-Cyclops, převzato z [9]
3.5 CMUcam
CMUcam jsou kamerové moduly vyvinuté v robotickém institutu Carnegie Mellon University
[11]. Cílem bylo vyvinout levný a výkonný modul pro zpracování obrazu v reálném čase,
který bude plnit základní úlohy, jako je vyhledávání a sledování objektů v obraze a získávání
statistických dat o nich. Celá koncepce CMUcam již od prvního modelu směřovala k využití
modulů pro řízení robotických systémů. Je to patrné zejména z HW výbavy modulu, ke které
od začátku patří port pro připojení servomotorů, umožňující i jejich automatické řízení údaji
získaných sledovacím algoritmem, a minimálně jedna sériová linka umožňující komunikaci
modulu s řídicím procesorem robotu.
Celá řada CMUcam je založena na CMOS kamerovém čipu Omnivision OV6620 [12], který
nabízí široké možnosti korekce obrazu přímo na čipu (AGC, AWB, nastavení doby expozice,
korekce jasu, kontrastu). Umožňuje získat barevný obraz ve formátu RGB nebo YCrCb
v maximálním rozlišení 352x288 pixelů s rychlostí až 50fps. Velkou výhodou tohoto čipu je
nízká spotřeba, která je při plném vytížení nižší 80mW.
24
3.5.1 CMUcam1
První verze modulu z řady CMUcam [13], [14] byla představena v roce 2002 na konferenci
IROS 2002. Modul byl postaven na procesoru Ubicom SX28 s frekvencí 50Mhz a umožňoval
posílat po sériové lince statistické informace o obraze a informace o sledovaném barevném
objektu. Bylo také možné přímo k tomuto modulu připojit servomotory, které mohly
automaticky řídit pohyb robotu za sledovaným objektem. Rychlost zpracování obrazu ovšem
nebyla vzhledem k použitému procesoru nijak velká. Pohybovala se okolo 17fps.
Obr. 18: CMUcam1, převzato z [13]
3.5.2 CMUcam2
Dalším vývojovým stupněm byla v roce 2003 představená verze CMUcam2 [15], [16]. Tento
modul byl řízen RISC procesorem Ubicom SX52 pracujícím na frekvenci 75Mhz, který má
oproti svému předchůdci dvojnásobnou velikost pamětí ROM a RAM. Dalším rozdílem oproti
starší verzi bylo přidání rychlého FIFO obrazového bufferu. Ten funguje jako spojovací
článek mezi pořízením a zpracováním obrazu a umožňuje tak efektivnější a rychlejší přístup
procesoru k sejmutému obrazu. Standardní rozlišení, se kterým modul pracuje, je 88x144
pixelů. Rozlišení lze softwarově snižovat a to nezávisle v obou osách.
Kromě zvýšení frekvence zpracování obrazu až na 50fps nabídl tento modul i další zajímavé
funkce. Jedná se zejména o frame differencing 4, získání histogramů pro jednotlivé barevné
kanály, volitelné rozšíření statistických informací o objektech v obraze. Funkce vyhledávání a
sledování barevných objektů a přímého řízení servomotorů byly zachovány.
4
Schopnost porovnat každý nový snímek s uloženým vzorem. Vhodné např. pro detekci pohybu v obraze.
25
Obr. 20: Schematický nákres CMUcam2, převzato z [18]
CC2 má definovaný komunikační protokol, který nelze měnit. Data jsou posílána ve formě
textových paketů. Komunikace modulu s řídicím procesorem může probíhat po standardní
sériové lince RS232 nebo po TTL sériové lince. Schematický nákres CC2 je zobrazen na
obr. 20. Současná cena CC2 je $179 [17].
26
Podrobný popis příkazů a komunikačních paketů CC2 je možné najít v uživatelském manuálu
[18], který je k dispozici online na webové stránce [15]. Popis dalších vlastností a principu
funkce tohoto kamerového modulu lze také najít v práci [19].
3.5.3 CMUcam3
CMUcam3 [20] je nejnovější model této řady představený v roce 2007. Stejně jako předchozí
modely má i tento za cíl umožnit zpracování obrazu v reálném čase. Modul je postaven na
mikroprocesoru Philips LPC2106 s ARM architekturou, který je oproti procesorům na
předchozích modelech plně programovatelný v jazyce C. Modul je tak možné přizpůsobit pro
konkrétní aplikaci, což umožňuje mnohem širší využití.
Z hardwarového vybavení má modul oproti předchozím modelům navíc řadič pro MMC kartu
s FAT16, rychlejší FIFO obrazový buffer, GPIO rozhraní a komunikační porty SPI a I2C.
LPC2106 je 32bitový 60MHz mikroprocesor na bázi ARM7TDMI s 64KB RAM paměti a
128KB flash paměti. Pro ukládání snímků z kamerového modulu OV6620 slouží 1MB FIFO,
která odděluje snímací a zpracovávací část modulu. Standardní pracovní rozlišení obrazu je
176x144 pixelů. Rozlišení je však třeba vhodně volit v závislosti na používané aplikaci,
protože paměť na modulu pro uložení zpracovávaného obrazu je omezená. Propojení
jednotlivých částí je naznačeno na obr. 22. Cena tohoto modulu je $239 [17].
27
3.5.3.1 Vývoj aplikací
Všechny prostředky potřebné k vývoji vlastních aplikací pro CC3 je možné získat na
stránkách věnující se kamerovému modulu CC3 [21] v sekci „Software“. Jedná se o
kompilátor jazyka C99 vhodný pro ARM procesory, programátor pro LPC2106 a adresářovou
strukturu obsahující potřebné knihovny, funkce pro propojení do nejnižší hardwarové vrstvy a
vzorové projekty. Popis adresářové struktury je uveden v příloze A.
Obr. 22: Schematický nákres CMUcam3, převzato z [21]
3.6 Vyhodnocení
Při porovnání technických parametrů a ceny jednotlivých modulů byl jako nejvýhodnější
vybrán modul AVRCam. Jeho dostupnost však byla velmi špatná, a proto byl vývoj aplikací
zahájen s kamerovým modulem CMUcam2. Ačkoliv není programovatelný, tak nabízí
dostatečné množství statistických informací o obraze a lze jej jednoduše začlenit do větších
28
projektů. Vzhledem ke zpětné kompatibilitě modulu CMUcam3 s předchozí verzí pokračoval
vývoj aplikací na tomto modulu. Navíc již umožňoval úpravu vnitřních algoritmů pro
zpracování obrazu. Velkou výhodou modulů CMUcam je také jejich dobrá dostupnost a
kvalitní technická podpora včetně řady ukázkových aplikací.
29
4 Aplikace s kamerovými moduly CMUcam
V této části jsou popsány některé projekty využívající moduly CMUcam. Ty jsou vybrány
tak, aby byly patrné výhody použití tohoto modulu pro daný projekt.
Jak již bylo řečeno, kamerové moduly s jednočipovým mikroprocesorem nemohou dosahovat
takového výpočetního výkonu při zpracování obrazu jako běžné PC nebo výkonné procesory.
Přesto mají své opodstatnění a to zejména v projektech, kde je kladen důraz na cenu, spotřebu
a velikost robotu. Stále ovšem musíme brát v úvahu i omezení, která z využití těchto modulů
plynou. Jedná se zejména o nutnost použití pouze základních algoritmů, omezení využitelné
paměti, nutnost optimalizace přenosu dat mezi modulem a řídicím procesorem z důvodu malé
přenosové rychlosti a v neposlední řadě i nižší rozlišení.
4.1 LUV
LUV5 je projekt, který měl za cíl vyvinout levné vozidlo schopné pohybu pod vodou
(ponorka). Hlavním kritériem pro výběr senzorů a řídicího HW byly cena a spotřeba. Senzory
musely být odolné vůči změnám tlaku, vlhkosti a teploty a to zejména z hlediska přesnosti.
Řídicí jednotka byla postavena na mikroprocesoru OOPic s klasickou PIC architekturu. Byl
vybrán, protože disponuje dostatečným množstvím analogových, digitální a optických I/O pro
připojení všech potřebných senzorů a čidel. Úkolem řídicího procesoru bylo vést vozidlo
takovým směrem, aby se vyhnulo všem překážkám a doplulo do cílové pozice. Jako hlavní
navigační člen sloužila CMUcam2.
Modul byl nastaven tak, aby na základě změny barvy dokázal najít a rozpoznat předmět ve
vodě a pomocí dalších algoritmů rozpoznat jeho texturu a tím určit o jaký objekt se jedná
(úkol klasifikace a segmentace obrazu). CMUcam byla vybrána proto, že data dokáže
předzpracovat a řídicímu procesoru posílá již vyhodnocené údaje o poloze překážky. Ve
chvíli, kdy není žádný předmět rozpoznán, nezatěžuje modul procesor žádnými daty. Ten má
tak dostatek procesového času počítat na základě údajů z dalších senzorů (sonar, digitální
5
Low-cost underwater vehicle
30
Obr. 23: Schéma řídicího machanizmu LUV, převzato z [22]
kompas, talkový senzor a akcelerometr) trajektorii pohybu a řídit motory vozidla. Bližší
informace a specifikace jednotlivých částí jsou v [22]. Podobný projekt postavený na stejném
řídicím mechanizmu využívající k navigaci CMUcam3 je popsán v [23].
4.2 Hardcore III
Hardcore III [24] je robot vyvinutý pro soutěž IGVC 6 [25]. V této soutěži mají autonomní
robotická vozidla za úkol projet naplánovanou trasu v co možná nejkratším čase a vyhnout se
jak umělým, tak i přírodním překážkám.
V tomto projektu byla CMUcam2 použita hned ze 2 důvodů. Protože trasa byla vyznačena
bílými pruhy v trávě, bylo velmi jednoduché získat z obrazu trajektorii cesty. Data se tak opět
nemusela přenášet kompletní, ale kamerový modul posílal řídicímu procesoru pouze potřebné
údaje týkající se cesty. Dalším důvodem byl fakt, že umělé překážky měly výrazně oranžovou
6
Intelligent Ground Vehicle Competition
31
barvu. Jejich poloha v obraze je tak pomocí CMUcam2 snadno identifikovatelná a
komunikace s procesorem opět probíhá na základě výměny pouze statistických údajů o poloze
objektu. Modul tak v systému zastupuje funkci 2 algoritmů pro zpracování obrazu, které by
jinak musel provádět řídicí procesor a tím mu znatelně šetří procesní čas.
Obr. 24: Fotografie robotu Hardcore III s připojenou CMUcam, převzato z [24]
4.3 Stolní tenis
Dalším zajímavým projektem je vývoj robotu hrajícího stolní tenis [26]. Úkolem robotu bylo
odehrát ping-pongový míč zpět protihráči. V tomto složitém systému figurovala CMUcam
jako důležitý nástroj pro výpočet trajektorie míče a určení místa dopadu. Kamera byla
umístěna nad stolem tak, aby snímala pouze modrou plochu stolu a bílou dělicí čáru (viz obr.
25). Tím bylo zajištěno, že oranžový míč byl vůči pozadí dostatečně kontrastní. K určení
místa dopadu pak stačí získat informace o 2 místech, kterými míček proletí. Z dat o poloze
řídicí procesor dopočítá pravděpodobnou trajektorii letu a místo dopadu míče.
32
Obr. 25: Systém pro odpalování ping-pongových míčů s CMUcam umístěnou nad hracím stolem, převzato z [26]
4.4 robuDOG
O tom, že kamerové moduly CMUcam nejsou používány pouze k experimentálním účelům,
svědčí např. průmyslový projekt robuDOG [27]. Tento robotický systém ve tvaru psa je
produktem společnosti Robosoft. Robot je možné programovat prostřednictvím dodávaného
softwaru, který umožňuje simulovat pohyb robotu ve 3D prostředí. Celkem je možné
nezávisle ovládat 17 kloubů (4 na každé přední noze, 3 na každé zadní noze a 3 na hlavě).
Přední nohou je možné např. kopat do míče a ve spolupráci s dalšími podobnými roboty hrát
fotbal. Jako inteligentní vizuální senzor je použit kamerový modul CMUcam3, a to zejména
díky možnosti jej podle potřeby přeprogramovat. Modul může být vhodně nastavený např. pro
hledání míče v prostoru a určení směru pohybu k němu. Robot je dále vybaven infra-senzory,
2D akcelerometrem a řadou rozhraní (wi-fi, ethernet, USB).
Robot lze objednat na stránkách výrobce [28] a jeho cena je 3 200 €.
33
Obr. 26: robuDOG s CMUcam3 umístěnou v díře v hlavě, převzato z [27]
Mnoho dalších podobných projektů je možné najít na stránkách CMUcam3 [21] v sekci
Projects (sledovací roboti, kamerové senzory, roboti pro soutěže FIRST). Pokud se v těchto
projektech zaměříme na princip použití kamerových modulů CMUcam, vyjde najevo, že je
pro většinu z nich velmi podobný. Kamerový modul je používán jako podpora pro segmentaci
obrazu a je využíváno toho, že data přenášená mezi modulem a procesorem mají malý objem
a maximální potřebnou informační hodnotu. Řídicí procesor proto nemusí implementovat
algoritmy pro segmentaci obrazu, ale data pouze klasifikuje a tím se zvyšuje jeho rychlost
reakce na změny.
CMUcam3 nabízí další zjednodušení a zrychlení procesu zpracování obrazu, a to zejména
díky možnosti naprogramovat si potřebné funkce přesně pro cílovou aplikaci. Modul
nevykonává pouze segmentaci obrazu, ale může data i klasifikovat, čímž dojde k dalšímu
urychlení při zpracování dat řídicím procesorem.
34
5 Úlohy pro kamerové moduly CMUcam2 a
CMUcam3
Tato část práce se zabývá návrhem a implementací úloh pro zpracování obrazu kamerovými
moduly CMUcam2 a CMUcam3.
5.1 Uživatelské rozhraní CMUcam2
Jak již bylo zmíněno v 3.5.2 má CMUcam2 pevně definovaný komunikační protokol. Ten
specifikuje příkazy pro:
Nastavení registrů kamerového modulu
Nastavení vlastností vyhledávání a sledování objektů v obraze
Nastavení parametrů servomotorů
Získání histogramu obrazu
Získání středních barevných hodnot v obraze
Získání informací o poloze sledovaného objektu
Získání obrazu sejmutého kamerovým modulem
Komunikace modulu s řídicím procesorem je paketově orientovaná. Pakety mohou být
posílány ve formě textového řetězce nebo v bajtové7 formě. Každý paket je tvořen hlavičkou,
tělem a patičkou.
Hlavička je písmeno určující typ paketu a tím i jaká data budou následovat.
CMUcam2 rozlišuje 4 typy paketů:
o F paket – přenos sejmutého obrazu
7
Číselné hodnoty nejsou přenášeny jako ASCII znaky, ale jako jedno číslo. Např. při přenosu čísla 112 se
v textové formě přenesou 3 bajty s číslicemi ‘1‘ ‘1‘ ‘2‘, ale v bajtové formě se přenese pouze 1 bajt odpovídající
dekadické hodnotě 112, tedy písmeno ‘p‘.
35
o H paket – přenos dat histogramu
o T paket – přenos dat o sledovaném objektu
o S paket – přenos dat o středních barevných hodnotách v obraze
Tělo paketu obsahuje přenášená data. Délka těla je proměnlivá a závisí na formě
přenosu dat a v případě textové formy na číselných hodnotách8.
Patička zakončuje každý paket. Je ve tvaru carriage return (‘\r’).
Přesná definice paketů a popis funkce jednotlivých příkazů je v manuálu ke kamerovému
modulu CMUcam2 [18].
Komunikační protokol je implementován v jazycích Java a C++.
5.1.1 Implementace v jazyce Java
Tato implementace je popsána v [19]. Obsluhuje všechny příkazy používané kamerovým
modulem a umožňuje číst a ukládat všechny datové pakety. Dále je možné s výhodou využít
ukázkových programů, ve kterých se může uživatel jednoduše a rychle seznámit s principem
funkce kamerového modulu a s implementací uživatelského rozhraní. Tato verze je vhodná
pro první seznámení a pochopení funkce CMUcam2.
5.1.2 Implementace v jazyce C++
Toto komunikační rozhraní bylo implementováno s cílem použít jej pro řízení robotu.
Umožňuje nastavit všechny registry a parametry důležité pro vyhledávání a sledování
barevných objektů. Z datových funkcí obsluhuje pouze vyhledávací a sledovací funkce,
jejichž výstup je ve tvaru T paketu. Podle potřeby je ale možné jednoduše doplnit i obsluhu
dalších datových funkcí.
8
Čísla nejsou doplňována nulami.
36
5.2 ÚLOHY ZPRACOVÁNÍ OBRAZU
Vlastní úlohy jsou implementovány pro kamerové moduly CMUcam2 a CMUcam3. Díky
možnosti modulu CC3 emulovat chování CC2 je zachována zpětná kompatibilita.
Implementovány jsou tyto úlohy:
Sledování barevného objektu robotem (CMUcam2)
Multi-blob finder (CMUcam3)
GeNav (CMUcam3)
5.2.1 Sledování barevného objektu robotem
5.2.1.1 Rozbor úlohy
Základní úlohou sledování objektů v obraze je jejich nalezení podle zadaných kritérií a jejich
sledování při dalším pohybu. Kritériem může být barva objektu, textura, tvar, poloha, aj.
Využití této aplikace je možné např. v robotickém fotbale, kde umožní hráči vybavenému
kamerovým modulem autonomně najít míč, jet za ním a snažit se jej odrážet na soupeřovu
branku. Další možností je určování směru pohybu k významným bodům v prostředí, kdy
modul pouze předá řídicímu procesoru informace o nalezeném objektu, ten je zpracuje a
vyhodnotí. Kamerový modul může zatím již hledat další určený bod.
Cílem úlohy je implementovat algoritmus pro autonomní sledování barevného objektu
robotem G2BOT [29] na základě údajů z kamerového modulu CMUcam2 upevněného na těle
robotu, viz obr. 27.
37
Obr. 27: G2BOT s CMUcam2 a krabicí použitou při testování algoritmu
5.2.1.2 Implementace
Úkolem CMUcam2 je nalézt v obraze objekt definované barvy a informace o jeho poloze
poslat řídicímu procesoru. Ten je zpracuje a podle potřeby nastaví rychlosti motorů
jednotlivých kol tak, aby objekt byl stále uprostřed kamerovým modulem snímaného obrazu.
Dojde tak k oddělení části pro zpracování obrazu a řízení robotu. Řídicí procesor tak není
zatěžován vyhodnocováním obrazu.
Kamerový modul je s řídicím počítačem robotu propojen prostřednictvím převodníku USBRS232. Algoritmus je implementován v C++.
Popis algoritmu řízení robotu:
Po nastavení parametrů kamerového modulu (AWB, AGC, datový mód) začne vyhledávání
barvy objektu zájmu. Vyhledávací fáze spočívá v otáčení robotu kolem své osy a
vyhodnocování dat z CMUcam2. Ta na příkaz nalezení barvy v obraze vrací data ve formě
T paketu, který má tvar:
T mx my x1 y1 x2 y2 pixels confidence\r
kde:
mx – x souřadnice těžiště nalezené barevné oblasti
38
my – y souřadnice těžiště nalezené barevné oblasti
x1 – x souřadnice levého horního rohu nalezené barevné oblasti
y1 – y souřadnice levého horního rohu nalezené barevné oblasti
x2 – x souřadnice pravého spodního rohu nalezené barevné oblasti
y2 – y souřadnice pravého spodního rohu nalezené barevné oblasti
pixels – počet nalezených pixelů odpovídajících hledané barvě kvantovaných do 255
úrovní podle rovnice
(5.1)
confidence – parametr určující, jak velkou část z celé obdélníkové hraniční oblasti
zabírají správné9 pixely. Maximální hodnota je 255.
(5.2)
Pokud je hledaná barva nalezena, zkontroluje se, zda jsou správné pixely dostatečně
konzistentní. K tomu slouží parametr confidence. Pokud je tato hodnota dostatečně vysoká 10,
jedná se o hledaný objekt a robot přejde do sledovací fáze. V té dochází k vyhodnocení
polohy středu nalezené oblasti správných pixelů. Cílem řízení robotu je udržet tento střed
oblasti uprostřed celého pozorovaného obrazu. Rychlost pohybu robotu se řídí jednoduchým
softwarovým proporcionálním regulátorem, který mění akční veličiny dopředné a úhlové
rychlosti v závislosti na velikosti rozdílu zmiňovaných středů oblasti a obrazu. Pokud robot
předmět ztratí z dohledu, přejde opět do vyhledávací fáze.
Algoritmus řízení robotu je zobrazen v podobě vývojového diagramu na obr. 28.
9
Pixely odpovídající hledané barvě
10
Dobrých výsledků je dosahováno při confidence>20%
39
Start
Inicializace modulu a motorů
Otáčej robota na místě
Hledej barvu objektu
Nalzena
hledaná barva?
NE
ANO
Je hledaného
objektu?
NE
ANO
Je objekt
na středu
obrazu?
Je objekt
v pravé části
obrazu?
NE
ANO
NE
ANO
Jeď vpřed
Zatoč vpravo
Zatoč vlevo
Obr. 28: Vývojový diagram aplikace sledování barevného objektu
5.2.1.3 Testování programu
Při testování algoritmu měl robot za úkol v prostoru najít zelenou krabici, dojet k ní a při
změně polohy ji dále sledovat.
Největším problémem je velká závislost rozpoznávání barvy na typu osvětlení. Pokud není
osvětlení homogenní v celém pracovním prostoru, dochází k chybnému vyhodnocení barvy
krabice, a i když se nachází ve viditelném poli kamerového modulu, není správně rozpoznána
a robot přejde do vyhledávací fáze. Tomuto problému lze předejít vylepšením algoritmu o
40
část, která bude adaptivně měnit parametry hledané barvy podle informací z předchozího
obrazu. Další možností je použití značek umístěných na hledaném objektu tak, aby je mohl
robot vidět. Důležitou podmínkou pro použití takovýchto značek je, že jsou složeny alespoň
z 3 různě barevných tvarů, které mají společné těžiště. CMUcam2 ho dokáže při vyhledávání
jednotlivých barev štítku najít a k úspěšné identifikaci objektu nám pak stačí nalézt v obraze
alespoň 2 barevné oblasti, které si svými těžišti odpovídají. Poslední barva pak může být
identifikována chybně. Příklady možných značek jsou na obr. 29.
Obr. 29: Příklady možných barevných značek pro identifikaci objektu
5.2.2 Multi-blob finder
Z dokumentace k modulu CMUcam2 [16] plyne, že tento kamerový modul dokáže poslat jen
informace o hraniční obdélníkové oblasti okolo všech nalezených správných pixelů.
V reálném měření to znamená, že i když kamera vidí několik objektů stejné barvy, hraniční
oblast je kolem všech těchto objektů, viz obr. 30 b). Je tedy nutné naprogramovat jiný vnitřní
algoritmus inspekce obrazu a ten použít pro hledání více stejně barevných objektů v obraze.
Tuto úpravu vnitřních funkcí nabízí kamerový modul CMUcam3.
Cílem tohoto projektu je implementovat algoritmus pro CMUcam3, který umožní najít
v obraze stejně barevné objekty a pro potřebu dalšího zpracování obrazu získat popis jejich
polohy pomocí těžiště plochy a obdélníkové hranice oblasti. Tento algoritmus bude
v budoucnu použit v rámci dalších projektů.
41
a
b
c
Obr. 30: Příklady ohraničení objektů v obraze: a) bez ohraničení; b) ohraničení CMUcam2; c) požadovaný výsledek
ohraničení CMUcam3 a Multi-blob finder algoritmem
Z principu tohoto problému je jasné, že je třeba provést vždy inspekci celého obrazu. Časová
náročnost tak přímo závisí na použitém rozlišení (čím vyšší rozlišení, tím vyšší doba
inspekce). Standardní rozlišení CMUcam3, které je 176x144 pixelů je pro tuto úlohu, kde
není třeba identifikovat drobné objekty, dostačující. Optimálně by inspekce obrazu měla být
provedena pouze jednou a všechna rozhodnutí o nalezení nebo uzavření objektu vykonána
hned při inspekci.
42
Parametry hledané barvy je možné zadat v RGB nebo HSV modelu v rozmezí 0-255 pro
každou složku.
Hledání objektů je implementováno jako API knihovna pro CMUcam3 a je popsána v příloze
B.
Komunikační protokol je upraven tak, aby se mezi modulem a řídicím počítačem přenášela
jen nezbytně nutná data. Datový paket je textový. Struktura, v níž jsou uloženy informace o
nalezených objektech má tyto proměnné:
x0, y0 – souřadnice levého horního rohu obdélníkové hranice objektu
x1, y1 – souřadnice pravého spodního rohu obdélníkové hranice objektu
centroid_x, centroid_y – souřadnice těžiště nalezeného objektu
pix_cnt – celkový počet správných pixelů v objektu
change_flag – příznak určující otevření/uzavření nalezeného objektu (slouží pro
kontrolu v průběhu inspekce obrazu)
Pro hledání objektů jsou důležité 3 parametry, jejichž správné nastavení je významné jejich
pro úspěšné nalezení. Jedná se o:
noise_filter – určuje minimální počet správných pixelů v řadě, které již lze pokládat za
sekvenci příslušející k objektu. Potlačuje rušení při náhodné identifikaci několika
málo pixelů jako správných.
min_blob_distance – v pixelech určuje minimální vzdálenost mezi objekty. Slouží
k potlačení rušení vlivem nehomogenity povrchu objektů, kdy může být pixel uvnitř
objektu vyhodnocený jako nesprávný. Pokud je v rámci této minimální vzdálenosti
opět nalezna správná sekvence, je tato chyba ignorována a obě přerušené sekvence
spojeny do jedné.
MAX_BLOBS – definuje maximální možný počet objektů v obraze.
Obě datové struktury jsou podrobně popsány v příloze B.
Algoritmus hledání objektů lze rozdělit do 5 fází:
1. inicializace proměnných a parametrů hledání
2. načtení obrazových dat
43
3. nalezení sekvence správných pixelů
4. kontrola integrity nalezené sekvence s neuzavřenými objekty
5. uzavření nepokračujících objektů
kde 4. fáze přichází v úvahu pouze tehdy, je-li ve 3. fázi úspěšně nalezena sekvence. Přesná
posloupnost jednotlivých fází je nejlépe patrná ve vývojovém diagramu na obr. 32.
Nalezení sekvence správných pixelů
Jednotlivé řádky sejmutého obrazu jsou pixel po pixelu procházeny s cílem nalézt homogenní
posloupnost pixelů odpovídajících hledané barvě s ohledem na zadané parametry
(noise_filter, min_blob_distance). Této posloupnosti říkejme sekvence správných pixelů.
Jakmile je identifikován poslední pixel sekvence, přechází algoritmus do fáze kontroly
integrity. Hledání další sekvence pak pokračuje, dokud algoritmus nezkontroluje všechny
pixely aktuálního řádku.
Kontrola integrity dat
V této fázi dochází ke kontrole, zda nalezená sekvence patří některému z neuzavřených
objektů. Probíhá na základě znalosti, že mezi pixely patřící jednomu objektu musí existovat
cesta, a tedy, že alespoň část nalezené sekvence musí mít sousední pixel11 v některém
z neuzavřených objektů. Tento fakt je ilustrován na obr. 31, kde jsou všechny možné
vzájemné polohy objektu (modrá) a nalezené sekvence správných pixelů (červená), kdy jsou
klasifikovány jako k sobě příslušející.
Obr. 31: Možné kombinace pro určení příslušnosti sekvence správných pixelů k objektu
Je-li nalezená sekvence součástí některého z objektů, jsou jeho příslušná data upravena
v závislosti na nové sekvenci. Pokud sekvence součástí žádného z neuzavřených objektů není,
je uložena jako nový objekt.
11
Ve smyslu 4-sousedství
44
Start
Inicializace
Sejmi obraz
Zpracovány
všechny řádky?
ANO
NE
Načti řádek
Zpracovány
všechny pixely?
ANO
Je sekvence
ukončena?
NE
ANO
NE
Načti pixel
NE
ANO
Byl předchozí
pixel správný?
ANO
Byl předchozí
pixel správný?
Je pixel
správný?
NE
NE
ANO
Uzavři sekvenci
Začni sekvenci
Zkontroluj integritu
Přidej k objektu
NE
ANO
Patří sekvence
k objektu?
Jsou v seznamu
nepokračující
objekty?
ANO
Uzavři objekty
Konec
Obr. 32: Vývojový diagram pro aplikaci multi-blob finder
45
NE
Založ objekt
Uzavření nepokračujících objektů
Na konci inspekce každé řádky je provedena kontrola, zda pro všechny neuzavřené objekty
byla v právě prozkoumané řádce nalezena příslušející sekvence. K tomu slouží příznak
change_flag. Ten je inkrementován při každém načtení nové řádky do paměti a resetován,
pokud je v této řádce nalezena sekvence příslušející danému objektu. Pokud ve 2 po sobě
jdoucích řádkách není taková sekvence nalezena, je objekt označen za uzavřený a jsou
vypočítána data o poloze a těžišti objektu. Tato data se již dále nemohou měnit.
5.2.2.3 Testování algoritmu
Testování algoritmu probíhalo při statickém umístění kamery před bílou plochou s červenými
objekty s různým rozmístěním. Plocha byla rovnoměrně nasvícena žárovkou.
Je-li snímané prostředí osvětleno homogenně (nepohybuje se v prostoru), je dobré kamerový
modul kalibrovat pomocí automatického vyvážení bílé barvy a automatické expozice. Modul
si tyto hodnoty upravuje automaticky při načtení snímku do obrazového bufferu. Před
vypnutím kalibračních funkcí je tedy nutné do bufferu nahrát alespoň 5 snímků. Není-li však
osvětlení snímaného povrchu stálé, je vhodné kalibrovat kamerový modul popsaným
způsobem alespoň každých 10 snímků, případně nechat kalibrační funkce stále zapnuté.
Důležitými parametry, které mají přímý vliv na úspěšnost hledání objektů, jsou zmiňované
noise_filter (NF) a min_blob_distance (MBD). Z testování vyplynulo, že příliš malá hodnota
MBD způsobuje u jinak homogenního objektu jeho rozdělení na více malých. Dochází k tomu
zejména v situaci, kdy je povrch objektů lesklý nebo je nerovnoměrné osvětlení. Důvodem je,
že pixely ve středu objektu nemusí být detekovány jako správné a při kontrole integrity pak
není nalezen vhodný objekt, ke kterému přerušenou sekvenci přiřadit. Naopak, příliš velká
hodnota MBD způsobuje „slití“ několika objektů do jednoho velkého, jak je vidět na obr.
33 d). Hodnotu NF je vhodné nastavit na 3-6 pixelů. Při nižší hodnotě mohou totiž jako
objekty být identifikovány i náhodně sejmuté sekvence 1-2 pixelů. Velká hodnota NF způsobí
necitlivost algoritmu vůči malým předmětům (což může být někdy výhodné). Obecně lze říci,
že nastavení obou parametrů je závislé na konkrétním typu úlohy a vlastnostech detekovaných
objektů.
46
Algoritmus byl testován programem Blob-finder, který využíval připravené API knihovny a
byl implementován pro kamerový modul CMUcam3. Program funguje jako uživatelské
rozhraní umožňující měnit parametry hledání objektů (barva objektu, NF, MBD) a zvolit si
požadovaný formát výstupních dat algoritmu (pouze výpis informačních dat o objektech,
výpis hraničních bodů objektů ve všech řádcích nebo binární obraz). Dále je možné získat
sejmutý obraz v grafickém formátu ppm.
Doba hledání (ms)
Zvolené
Skutečný
Počet nalezených
rozlišení
počet objektů
objektů
RGB
HSV
176 x 143
3
3
152
265
176 x 143
4
4
159
269
176 x 143
5
5
164
274
176 x 143
6
6
171
282
176 x 143
7
7
178
288
88 x 143
3
3
91
146
88 x 143
4
4
96
153
88 x 143
5
5
101
158
88 x 143
6
6
107
166
88 x 143
7
7
114
173
88 x 77
3
3
62
91
88 x 77
4
4
68
97
88 x 77
5
5
75
103
88 x 77
6
6
82
107
88 x 77
7
7
88
113
Tabulka 3: Porovnání doby hledání objektů v obraze
47
Jak ukazuje tabulka 3, je doba hledání objektů přímo úměrná zvolenému rozlišení obrazu a
počtu objektů v obraze. Na ploše objektu doba hledání nezávisí, a to proto, že inspekce musí
být vždy provedena nad všemi pixely obrazu a čas potřebný pro kontrolu integrity a uzavření
objektu je na jeho ploše nezávislý. Významný nárůst doby inspekce obrazu je také patrný při
definici parametrů objektu v HSV modelu. Je to proto, že je nutné všechny pixely obrazu
přepočítat12 z RGB do HSV. Celková doba hledání je také ovlivněna množstvím dat, která
potřebujeme mezi modulem a řídicím procesorem přenášet. Parametry vyhledávání byly po
celou dobu měření NF=3 a MBD=10 a hledaná barva byla zadána v RGB13.
Celková doba hledání a počet nalezených objektů v obraze byl brán jako průměr z 10 měření.
Reálně se ale hodnota času měnila maximálně v rámci 2ms a s ohledem na to, že podmínky
při testování byly ideální, byla detekce objektů ve všech případech bezchybná.
a)
b)
c)
d)
Obr. 33: Výsledky multi-blob finder algoritmu: a) Vstupní obraz pro zpracování sejmutý CMUcam3; b) Teoretický
výsledek při použití algoritmu CMUcam2; c) Výsledná segmentace obrazu multi-blob finder algoritmem; d) multiblob finder algoritmus s příliš velkou hodnotou MBD
12
Přepočet je prováděn podle rovnic 2.8, 2.9 a 2.10
13
Rozmezí hledané barvy pro testovací obraz: R=<80,255>; G=<0,30>; B=<0,30>
48
Na obr. 33 a) je příklad rozmístění objektů na ploše. Tento obraz byl vstupem programu Blobfinder a výstupem byla data ve formě textového řetězce ve tvaru:
found 7 blobs
obj nr.1 : x0=79 y0=24 ; x1=107, y1=44 ; Cx=94 Cy=34 ; flag=255
it took 178 ms to track multi color
Výpis programu 1
Kde:
x0, y0 – souřadnice levého horního rohu hraniční oblasti okolo objektu
x1, y1 – souřadnice pravého dolního rohu hraniční oblasti okolo objektu
Cx, Cy – souřadnice těžiště objektu
flag – příznak určující uzavření objektu
Pro názornost jsou tato data přenesena do původního obrazu a výsledek je na obr. 33 c). Žlutá
hranice je oblast, ve které se objekt s jistotou nachází s ohledem na nastavené parametry
hledání. Žlutý čtverec s černým středem znázorňuje těžiště nalezeného objektu. Tento bod
není středem hraniční oblasti, ale přímo závisí na počtu správných pixelů v určité části
hraniční oblasti (čím je hustota srávných pixelů v oblasti vyšší, tím blíže je k ní těžiště).
Další testování probíhalo v podmínkách, které oproti předchozím nebyly ideální. Cílem bylo
nalézt v obraze 4 válcové objekty červené barvy. Bylo použito standardní osvětlení místnosti
a jak je vidět na obr. 34 a) pozadí scény nebylo homogenní. Také je patrný odraz od povrchu,
který je rušivým jevem. Parametry hledané barvy byly zadány v RGB14. Výsledek použití
14
Rozmezí hledané barvy pro testovací obraz: R=<80,255>; G=<0,30>; B=<0,30>
49
multi-blob finder algoritmu je zakreslen na obr. 34 b). Doba inspekce byla v 10 měřeních
průměrně 159ms, což potvrzuje, že doba hledání není závislá na ploše objektů. Oddělení od
odrazů na povrchu plochy bylo zajištěno vhodnou volbou rozmezí hledané barvy.
a)
b)
Obr. 34: Příklad obrazu pro testování multi-blob finder algoritmu v reálné scéně; a) původní obraz scény; b) obraz
scény se zakreslenými výsledky hledání objektů pomocí multi-blob finder algoritmu
Pro zajímavost je na obr. 35 ukázán příklad, kdy jsou 2 objekty v zákrytu a tím dojde k jejich
chybnému vyhodnocení a označení za jeden.
Obr. 35: Příklad rozložení objektů, kdy jsou 2 z nich v zákrytu
Při hledání objektů v reálné scéně je velmi důležité vhodně zvolit rozmezí hledané barvy a
barevný model, který ji definuje. Důkazem toho je poslední testování, kdy bylo použito 50
obrazů s podobnou kompozicí jako na obr. 34. Hledaná barva byla pro polovinu snímků
definována v RGB a pro druhou polovinu v HSV. Světelné podmínky se průběžně měnily
podle osvětlení místnosti. Eliminovat tento jev je částečně možné zapnutím funkce
automatického vyvážení bílé, která vždy při změně osvětlení dokáže během několika nově
načtených snímků obraz vyvážit a díky tomu se hledaná barva porovnává vždy s podobně
barevným obrazem. V průběhu vyvažování často dochází ke špatné detekci objektů v obraze.
50
Ve většině případů je ale nadetekována alespoň část hledaného objektu a i tato informace
může být v některých případech užitečná. Rozdíl mezi zadáním parametrů v RGB nebo HSV
byl nejvýraznější při snaze detekovat společně s objekty i jejich odrazy od povrchu, kdy bylo
použití HSV modelu efektivnější.
Při výše popsaných podmínkách se úspěšnost detekce (včetně částečné detekce) pohybuje
okolo 90%. Tato hodnota se ale pro každou aplikaci může výrazně měnit v závislosti na
okolních vlivech (osvětlení, špatně zvolené pozadí scény) a vlastnostech detekovaných
objektů (lesklý povrch, nevýrazná barva, aj.).
5.2.3 GeNav
GeNav [30] (Gerstner Navigation) je navigační systém pro vyhledávání cest a křižovatek
v obraze, který je snímaný kalibrovanou kamerou zamířenou na oblast před robotem. Systém
byl
vyvinut
v Gerstnerově
laboratoři ČVUT
jako
součást
projektu autonomního
topologického průzkumu prostředí na základě vizuálního rozpoznávání. Vizuální systém je
v původním projektu tvořen jednou kamerou umístěnou na těle robotu a GeNav algortimem,
který je spuštěn na řídicím počítači. Blokové schéma je na obr. 37. Vyhledávání cest a
křižovatek je založené na barevné segmentaci sejmutého obrazu. Úkolem je oddělit oblast
odpovídající barvě cesty od okolí. Barva cesty je určena buď pomocným senzorem, nebo je
předem zadána. Z důvodu větší odolnosti vůči změnám jasu je pro specifikaci barvy cesty
použit HSV barevný model. Cílem algoritmu hledání cesty v systému GeNav je zajistit
polohu robotu uprostřed cesty zatímco se pohybuje vpřed. V případě nalezení křižovatky ji
pak identifikovat, popsat a data předat řídicímu počítači, který ji buď vyhodnotí jako novou
křižovatku a rozhodne o směru dalšího průzkumu, nebo je vyhodnocena jako bázová15 a
prohledávání prostoru je ukončeno.
15
Křižovatka, ve které byl topologický průzkum okolí zahájen
51
Při experimentech popsaných v publikaci [30] byla jako vizuální senzor použita kamera
Fire i-400, která pracovala s rozlišením 640x480 pixelů a poskytovala 15 barevných snímků
za vteřinu. Obrazová data byla přenášena po sběrnici IEEE1394 FireWire a zpracována
počítačem s procesorem Intel Core 2 Duo, který byl zároveň i řídicím počítačem robotu
Pioneer 3AT (viz obr. 36). Obraz byl zpracováván rychlostí 10fps. Vzhledem k tomu, že
zpracování obrazu zabralo velkou část procesorového času, bylo snahou oddělit systém
zpracování obrazu od řízení robotu.
Cílem projektu je nahradit původní vizuální systém kamerovým modulem CMUcam3, na
kterém bude implementován algoritmus hledání cesty a uživatelské rozhraní umožňující
nastavení parametrů hledání. Výstupem algoritmu budou hodnoty určující dopřednou a
úhlovou rychlost, které řídicí procesor použije pro korekci směru robotu.
Obr. 36: Robot Pioneer 3AT s CMUcam3 na sloupku nad robotem
52
Obr. 37: Blokové schéma systému GeNav, převzato z [30]
Algoritmus hledání cesty pro CMUcam3 je implementován obdobně jako v [30] s ohledem na
vlastnosti a parametry kamerového modulu. Z důvodu jednoduššího adresování a efektivnější
práce s pamětí je kamerový modul na těle robotu umístěn tak, že obraz je snímán vzhůru
nohama. To dovoluje provádět inspekci obrazu od první řádky16 a použít tak již
implementované funkce pro práci s obrazem. Algoritmus je implementován jako API
knihovna a její popis je v příloze C.
Algoritmus hledání cesty začíná inspekcí první řádky obrazu, ve kterém je hledána sekvence
pixelů odpovídajících zadané barvě cesty. Pokud je taková sekvence nalezena, je spočítán
horizontální střed cesty a algoritmus přejde k inspekci druhé řádky. Ta je prováděna postupně
do obou stran od středu nalezeného v předchozím kroku. Hledání sekvence je ukončeno, když
jsou nalezeny oba kraje cesty. Pokud je počet správných pixelů sekvence větší než definovaná
hranice, pokračuje algoritmus další řádkou opět od středu předchozí sekvence. Pokud tato
podmínka splněna není, nebo v další řádce není sekvence nalezena vůbec, je inspekce obrazu
zastavena. Ze získaných dat (počet prozkoumaných řádkek a celková odchylka jednotlivých
středů cesty od středu obrazu) jsou spočítány hodnoty určující velikost dopředné rychlosti v a
úhlové rychlosti ω. Tyto hodnoty jsou ve tvaru hexadecimálních čísel, ze kterých řídicí
16
Původní algoritmus prováděl inspekci obrazu od posledního řádku
53
procesor počítá skutečné velikosti příslušných rychlostí. Vztah pro výpočet vstupních hodnot
regulátoru je
(5.3)
kde w je šířka obrazu, mi je odchylka středu cesty od středu obrazu v i-tém řádku, r je počet
řádek obsahujících cestu. Vývojový diagram popsaného algoritmu je na obr. 38.
Rozhodování, zda právě testovaný pixel patří cestě, je založeno na porovnání jednotlivých
barevných složek pixelu s korespondující minimální a maximální hodnotou definující cestu.
Je možné použít HSV nebo RGB barevný model. Dále je možné zadat i barevné parametry
okolí, což umožní robustnější klasifikaci pixelu. Pokud je vyhodnocen jako správný pro
parametry cesty, je ještě otestován, zda-li zároveň není správný i pro parametry specifikující
okolí. Pokud ano, pak je vyhodnocen jako pixel nepatřící cestě. Je-li při inspekci řádky
nalezena sekvence nesprávných pixelů delší než je definovaná mez, je poslední nalezený
správný pixel označen jako kraj cesty (pravý nebo levý, podle aktuálního směru inspekce
řádky od středu cesty). Tento rozhodovací algoritmus je v podobě vývojového diagramu na
obr. 39.
Aby bylo možné algoritmus hledání cesty využít v rámci celého systému GeNav, je
v kamerovém modulu implementováno uživatelské rozhraní umožňující nastavovat parametry
cesty a okolí a získávat další informace. Komunikační protokol je textový a je tvořen:
hlavičkou definující parametry, které se budou nastavovat
tělem obsahujícím číselné hodnoty specifikující maximální a minimální barevné
hodnoty cesty nebo okolí pro použitý barevný model
patičkou zakončující příkaz, pro kterou je použit znak carriage return (‘\r’).
Komunikační protokol je popsán v příloze D.
54
Start
Načti obraz
Je v
prvním řádku obrazu
sekvence pixelů
cesty?
NE
Nastav dopřednou a
úhlovou rychlost na 0
ANO
Najdi střed sekvence
Načti další řádek
Testuj pixely vpravo od
nalezeného středu sekvence
Je
nalezen pravý
kraj cesty?
NE
ANO
Testuj pixely vlevo od
nalezeného středu sekvence
Je
nalezen levý
kraj cesty?
NE
ANO
ANO
Je počet
pixelů sekvence
větší než definovaná
mez?
NE
Spočítej dopřednou a
úhlovou rychlost.
Obr. 38: Vývojový diagram algoritmu hledání cesty pro systém GeNav
55
Start
Načti další pixel
Splňuje
pixel parametry
cesty?
NE
NE
Je počet
nesprávných pixelů
větší než definovaná
mez?
ANO
Splňuje
pixel parametry
okolí?
ANO
ANO
NE
Ulož poslední správný
pixel jako kraj cesty
Označ pixel jako správný
Konec
Obr. 39: Rozhodovací algoritmus pro příslušnost pixelu k cestě
5.2.3.3 Testování algoritmu
Pro testování algoritmu hledání cesty bylo použito zmíněné uživatelské rozhraní. Kamerový
modul CMUcam3 byl umístěn na sloupku nad robotem Pioneer 3AT (viz. obr. 36) tak, aby
snímal prostředí před robotem. Kamerový modul musí být upevněn tak, aby byl snímaný
obraz otočený o 180°. Obraz byl snímán v rozlišení 352x288 pixelů a po prvotní inicializaci
byly automatické funkce vyvážení bílé a nastavení expozice vypnuty. Tím je zaručeno, že
podmínky snímaní jsou po celou dobu sledování cesty stejné. Mez určující minimální šířku
cesty byla 20 pixelů.
Nejdříve byl algoritmus otestován při sledování cesty, která je vůči okolí kontrastní. Pro
simulaci byla použita bílá páska na tmavém podkladu. Barva cesty byla definována v HSV
modelu. Výsledek algoritmu je vidět na obr. 40. V tomto případě je detekce cesty přesná a
56
bezchybná v celé výšce obrazu. Zelené body značí nalezené hranice cesty a červenými body
jsou vyznačeny středy cesty v jednotlivých řádcích.
Obr. 40: Cesta a její střed vyznačený pomocí testovacích dat z algoritmu hledání cesty v systému GeNav (otočeno o
180°)
a)
b)
Obr. 41: Výsledek algoritmu hledání cesty aplikovaný pomocí definovaných oblastí (otočeno o 180°); a) vstupní obraz
s definovanými oblastmi pro výpočet parametrů cesty (modrá oblast) a okolí (žlutá oblast); b) výsledná nalezená cesta
Na obr. 41 je algoritmus hledání cesty použitý v reálném prostředí chodby. Parametry cesty a
okolí byly vypočítány z barevných hodnot jednotlivých pixelů uvnitř modré, respektive žluté
oblasti a definovány byly v HSV modelu. Výsledek detekce cesty je na obr. 41 b). Cesta je
57
opět nalezena v celé výšce obrazu, ale je patrné, že tmavá místa v pravém horním a dolním
rohu jsou označena jako okolí. Dále je dobré si uvědomit, že ačkoliv hranice cesty (zelené
body) v některých řádcích hodně kolísá, je trend jejího středu (červené body) téměř spojitý.
Pro vyhlazení je možné použít vhodný filtr.
Důležitým parametrem algoritmu je doba, za kterou je schopný cestu v obraze detekovat.
Systém GeNav v původní konfiguraci dokázal zpracovat průměrně 10 snímků za vteřinu při
plném vytížení řídicího počítače. Pro správnou funkčnost je třeba s kamerovým modulem
dosáhnout rychlosti alespoň 3 snímků za vteřinu, což odpovídá době hledání maximálně
330ms. Vzhledem k implementaci je doba hledání cesty kamerovým modulem velmi závislá
na sejmutém obrazu. Čas inspekce roste úměrně s počtem řádků, ve kterých je cestu možné
detekovat17 a šířce cesty ve všech detekovaných řádcích. K dalšímu výraznému nárůstu doby
inspekce dojde při použití HSV barevného modelu, protože je nutné každý zkoumaný pixel
přepočítat z RGB. Naopak při definici parametrů hledání barvou cesty i okolí je nárůst času
asi 10%. Přímý vliv těchto omezení ukazuje tabulka 4, kde jsou zaznamenány časy potřebné
k nalezení cesty v obr. 42. Ve druhém měření byla cesta v půlce přerušena. Rozlišení obrazu
bylo po celou dobu měření 352x288 pixelů. Výsledné hodnoty jsou brány jako průměr z 10
měření a přenášena byla pouze tabelovaná data a výstupní paket pro definici rychlostí.
Měření celé cesty
Počet
Počet
řádek
pixelů
HSV – pouze cesta
251
21 652
HSV – cesta, okolí
251
RGB – pouze cesta
RGB – cesta, okolí
Parametry hledání
Měření přerušené cesty
Počet
Počet
řádek
pixelů
429
173
17 746
317
21 670
467
173
17 475
332
248
21 367
283
172
16 848
208
248
21 435
324
172
16 833
237
Čas (ms)
Čas (ms)
Tabulka 4: Čas potřebný pro vyhledání cesty v obraze v závislosti na různém nastavení algoritmu
17
Cesta detekovaná v řádku je širší než 20 pixelů
58
Obr. 42: Zdrojový obraz pro testování doby hledání cesty, otočeno o 180°
Je patrné, že časová podmínka pro detekci cesty v obraze je při použití HSV modelu splněna
jen jednou, a to při omezené hloubce prohledávání a šířce cesty nezabírající celou šířku
obrazu. Se zvyšujícím se počtem testovaných pixelů roste i celková doba běhu algoritmu.
Řešení tohoto problému je několik:
Snížení rozlišení obrazu – kamerový modul umožňuje snížit rozlišení nezávisle
v horizontální i vertikální ose. Tím se sníží počet testovaných pixelů a tedy i celkový
čas potřebný pro vyhledání cesty. Nevýhodou je, že dojde ke snížení citlivosti a
přesnosti algoritmu.
Omezení maximálního počtu testovaných řádek – pro výpočet dopředné a úhlové
rychlosti není nutné mít informace z celého obrazu. Máme-li dostatečný počet řádek a
algoritmus bude dostatečně rychlý, dokážeme v jeho další iteraci najít cestu ve
vynechaných řádkách. Nevýhodou tohoto řešení je, že jedna definovaná hraniční
hodnota nezaručuje dostatečnou robustnost algoritmu. Při pevné hranici bude čas
hledání závislý jen na počtu testovaných pixelů a tato hodnota se může v závislosti na
vlastnostech cesty velmi měnit.
Omezení maximálního času běhu algoritmu – toto řešení se dá označit i jako omezení
počtu testovaných pixelů. Využívá výhod předchozího řešení, kdy není třeba provést
inspekci celého obrazu k získání korektních hodnot dopředné a úhlové rychlosti, ale
zároveň se hloubka inspekce dynamicky mění v závislosti na detekované šířce cesty.
Toto řešení je optimální z hlediska času a efektivity algoritmu.
59
Nelineární krok inspekce řádek v ose y – každá jednotlivá řádka obrazu reprezentuje
v reálné cestě různě dlouhý úsek, přičemž platí, že čím „vzdálenější“ řádka, tím je
reprezentovaný úsek delší a tím i informačně významnější. Navíc informace
v několika po sobě jdoucích řádkách se většinou příliš neliší. Můžeme tedy využít
možnosti, že u délkově méně významných řádek obrazu (např. prvních 100) budeme
několik po sobě jdoucích řádek (např. 2) přeskakovat a informace potřebné pro
výpočet hodnot dopředné a úhlové rychlosti v těchto řádkách budou stejné jako
u poslední zkoumané. U dalších řádek bychom postupovali analogicky, tedy např. pro
řádky 100-200 by se inspekce prováděla u každé druhé a pro zbytek obrazu by se již
zkoumala každá řádka. S výhodou by se pak toto řešení dalo zkombinovat s omezením
doby běhu algoritmu, čímž by došlo ke zvýšení počtu zkoumaných řádek. Nevýhodou
je možnost rizika přeskočení řádek obsahujících překážku v cestě. Je tedy nutné
parametry hledání vždy vhodně nastavit v závislosti na terénu.
Z předchozích možností bylo do vyhledávacího algoritmu implementováno časové omezení
hledání cesty s lineárním krokem při inspekci řádek. V celé výšce obrazu je zkoumána každá
3. řádka a do vynechaných jsou doplněna data z poslední testované řádky. Časové omezení
bylo stanoveno na 300ms. Takové řešení ve většině případů zaručí inspekci obrazu v celé jeho
výšce ve vyhrazeném čase.
Obr. 43: Oddělení cesty od okolí pro systém GeNav ve venkovním prostředí
Takto upravený algoritmus byl použit pro hledání cesty ve venkovním prostředí. Při testování
bylo nutné nechat po celou dobu zapnutou funkci AWB, která umožňovala přizpůsobení
60
vlastností snímání aktuálním světelným podmínkám. Zapnutí této funkce také umožnilo
snazší oddělení cesty od okolí při přejezdu ze světla do stínu. Barevné parametry byly
definovány vyznačením oblastí cesty a okolí stejně jako v příkladu na obr. 41. Nejlepších
výsledků bylo dosaženo při zadání oblastí, které obsahují cestu i okolí jak ve světle, tak ve
stínu. Testování probíhalo v parku na Karlově náměstí. Příklad výsledné segmentace cesty od
okolí je uveden na obr. 43.
Výsledky testování ukázaly, že kamerový modul je dostatečně rychlý pro implementaci
algoritmu hledání cesty a dokáže nahradit stávající vizuální systém. Velkou výhodou tohoto
řešení je snadná přenositelnost na libovolný systém s potřebou minimálních nebo žádných
úprav v samotném algoritmu.
61
6 Závěr
Cílem této diplomové práce bylo seznámit se se základními principy a postupy zpracování
obrazu v kontextu jejich dalšího využití na kamerových modulech s jednočipovým
mikroprocesorem a na základě těchto informací pak navrhnout a implementovat několik úloh
pro kamerové moduly CMUcam2 a CMUcam3, které by pracovali jako systémy pro
předzpracování obrazu.
V projektu sledování barevného objektu robotem byl využit kamerový modul CMUcam2 a
jeho implementované algoritmy pro segmentaci obrazu na základě odlišení barev. Tato
jednoduchá aplikace nabízí další možnosti rozšíření a zdokonalení sledovacího algoritmu,
které jsou v práci uvedeny a je tak možno využít jej např. pro výukové účely.
Multi-blob finder algoritmus byl implementován s cílem jeho dalšího využití na robotických
systémech. Kód je optimalizovaný pro rychlost vyhledávání objektů a z výsledků je patrné, že
úspěšnost hledání objektů je při dobře definovaných parametrech velmi vysoká. Algoritmus
tedy může být využíván v robotických soutěžích např. pro identifikaci jednotlivých robotů
(např. robotický fotbal) nebo při soutěžích typu Eurobot, kdy je cílem autonomně nalézt a
identifikovat různé objekty.
Implementací algoritmu hledání cesty pro systém GeNav bylo dokázáno, že při vhodném
nastavení dokáže kamerový modul s jednočipovým mikroprocesorem nahradit samostatnou
kameru připojenou k výkonnému PC. Výhodou tohoto řešení je nízká cena, snadná
přenositelnost na libovolný systém a vzhledem k rozměrům CMUcam3 i jednodušší
hardwarová instalace. Tento algoritmus však nemá využití pouze pro původní topologický
systém, ale je ho možné použít např. pro autonomní řízení robotu při pohybu po vyznačené
čáře (autonomní automobil). Dalším plánovaným využitím algoritmu je vizuální systém pro
autonomní invalidní vozíky. Úkolem bude zajistit, aby se vozík nedostal mimo definovanou
cestu nebo zastavil před překážkou.
Při vývoji aplikací je proti modulům s definovaným protokolem výhodné použít
programovatelné moduly, jako je CMUcam3. Umožňují totiž mnohem širší spektrum použití
62
a možnost přizpůsobení algoritmu pro výslednou aplikaci. Tím je zaručeno efektivnější a
rychlejší zpracování obrazu.
V úlohách bylo dokázáno, že kamerové moduly s jednočipovým mikroprocesorem dokáží při
vhodné implementaci a nastavení algoritmů pro zpracování obrazu nahradit i výkonnější
systémy. Další vývoj by tedy mohl směřovat k testování dalších, složitějších algoritmů pro
rozpoznávání objektů nebo textur v obraze. Stále je však třeba brát v úvahu omezení velikosti
použitelné paměti na modulu a minimální požadavky na časovou náročnost algoritmů.
63
7 Použitá literatura a zdroje
[1] Hlaváč, V. a Sedláček, M. Zpracování signálů a obrazů. Praha : Vydavatelství ČVUT,
2002. ISBN 80-01-02114-9.
[2] Šonka, M., Hlaváč, V. a Boyle, R. Image Processing, Analysis and Machine Vision. 3rd
edition. Toronto : Thomson Learning, 2007. ISBN 0-495-08252-X.
[3] Hlaváč, V. a Kybic, J. Materiály k předmětu 33ZSL1. [Elektronický dokument]
[4] Hlaváč, V. Materiály k předmětu 33PVR. [Elektronický dokument]
[5] Vision Sensor On GlobalSpec. [Online] [Citace: 23. březen 2008.] http://sensorstransducers.globalspec.com/Industrial-Directory/vision_sensor.
[6] Wright, A., Sargent, R. a Witty, C. Cognachrome Vision System. [Online] [Citace: 23.
březen 2008.] http://www.newtonlabs.com/cognachrome/.
[7] Electronics, Testech. [Online] [Citace: 23. březen 2008.] http://www.testechelect.com/tern/ceye.htm.
[8] Orlando, J. R. JRobot. [Online] http://www.jrobot.net/Projects/AVRcam.html.
[9] Rahimi, M., a další. Cyclops: In Situ Image Sensing and Interpretation. [Elektronický
dokument] San Diego : ACM SenSys, 2005.
[10] Typl, P. DP: Zpracování videosignálu s pomocí FPGA. Praha : ČVUT v Praze, Fakulta
elektrotechnická, 2005.
[11] Robotics Institute - Carnegie Mellon University. [Online] [Citace: 24. březen 2008.]
http://www.ri.cmu.edu/.
[12] Omnivision OV6620 Advanced Information Preliminary. [Elektronický dokument] 2000.
[13] CMUcam Vision System. [Online] [Citace: 24. březen 2008.]
http://www.cs.cmu.edu/~cmucam/home.html.
[14] Rowe, A., Rosenberg, C. a Nourbakhsh, I. A Low Cost Embedded Color Vision
System. [Elektronický dokument] Pittsburgh : Carnegie Mellon University, 2002.
[15] CMUcam2. [Online] [Citace: 24. březen 2008.] http://www.cs.cmu.edu/~cmucam2/.
[16] Rowe, A., Rosenberg, Ch. a Nourbakhsh, I. A Second Generation Low Cost Embedded
Color Vision System. [Elektronický dokument] Pittsburgh : Carnegie Mellon University,
2004.
64
[17] Seattle Robotics. [Online] [Citace: 4. duben 2008.]
http://www.seattlerobotics.com/index.htm.
[18] Rowe, Anthony. CMUcam2 Vision Sensor - User Guide. [Elektronický dokument]
Pittsburgh : Carnegie Mellon University, 2003.
[19] Janouch, M. Semestrální práce: Aplikace modulu CMUcam2+. [Elektronický
dokument] Praha : ČVUT v Praze, 2006.
[20] A., Rowe, Goode, A. a Nourbakhsh, I. Embedded Vision Processor CMUcam3.
[elektronický dokument] Pittsburgh : Carnegie Mellon University, 2006.
[21] CMUcam3. [Online] [Citace: 24. březen 2008.] http://www.cmucam.org/.
[22] Sehgal, Anuj, Kadarusman, Jason a Fife, Leslie. LUV: The Low Cost Underwater
Vehicle. [Elektronický dokument] Laie : Brigham Young University-Hawaii.
[23] Mozeika, Annan, a další. PROWLER V. [Elektronický dokument] New York :
University of Rhode Island.
[24] Umez-Eronini, Iheanyi. HARDCORE III – IGVC Design Report. [Elektronický
dokument] Rochester : Rochester Institute of Technology.
[25] IGVC - Intelligent Ground Vehicle Competiton. [Online] [Citace: 3. duben 2008.]
www.igvc.org.
[26] Van Dyk, Robert. Augmented Reality Table Tennis Robot. [Elektronický dokument]
New York : Rensselaer Polytechnic Institute, 2003.
[27] Robosoft. robuDOG - Programmable 4-legged robot. [Elektronický dokument] Bidart :
Robosoft.
[28] Mobile Robots - Robosoft. [Online] [Citace: 15. duben 2008.]
http://www.robosoft.com/eng/.
[29] Chudoba, Jan. G2BOT - experimentální mobilní robot. [Elektronický dokument] Praha :
ČVUT v Praze, červen 2005. hardwarová dokumentace k projektu.
[30] Košnar, K., Krajník, T. a Přeučil, L. Visual Topological Mapping. [Elektronický
dokument] ČVUT v Praze : The Gerstner Laboratory for Intelligent Decision Making and
Control.
[31] Rowe, A., a další. CMUcam3: An Open Programmable Embedded Vision Sensor.
[Elektronický dokument] Pittsburgh : Carnegie Mellon University, 2007. CMU-RI-TR07-13.
65
Příloha A. Popis adresářové struktury vývojového prostředí CMUcam3
hal/lpc2106-cmucam3
Obsahuje soubory popisující hardwarovou vrstvu modulu CC3. Pokud není k modulu
připojen nový hardware, není třeba tyto soubory upravovat.
include
Obsahuje soubor cc3.h. Ten řeší propojení základních uživatelských funkcí
s odpovídajícím hardwarem. Jedná se o funkce nastavující registry kamerového čipu,
nastavující parametry komunikačních rozhraní, funkce pro práci s obrazovým
bufferem nebo systémové funkce procesoru. Obsahuje také velmi důležitou datovou
strukturu cc3_g_pixbuf_frame, která po celou dobu běžícího programu uchovává
informace o stavu registrů kamerového čipu.
lib/cc3-ilp
Obsahuje knihovny se základními funkcemi pro práci se sejmutým obrazem, jako
např. vyhledávání objektů, získání histogramu nebo jiných statistických údajů, uložení
obrazu na paměťovou kartu aj. Pokud chceme naprogramovat vlastní knihovnu
s funkcemi pracujícími nad daty uloženými přímo v obrazovém bufferu, pak je vhodné
zdrojové kódy umístit právě do tohoto adresáře.
projects
V tomto adresáři jsou vzorové projekty a úlohy od tvůrců CC3. Popis funkce
některých úloh je možné najít v [31]. Pro vlastní projekty je třeba vytvořit makefile a
to nejlépe podle vzoru již naimplementovaných projektů.
docs
Obsahuje soubor s doporučením, jak psát syntakticky správně vlastní zdrojové kódy
pro kamerový modul CMUcam3.
66
Příloha B. Popis API multi-blob finder algoritmu
Zdrojové kódy jsou umístěny v cc3\lib\cc3-ilp\ a jedná se o soubory cc3_track_multi_blobs.h
a cc3_track_multi_blobs.c.
Popis datových struktur:
blob_info_t:
o Struktura obsahující všechny informace o nalezeném objektu.
uint16_t x0, y0
o souřadnice levého horního rohu nalezeného objektu
uint16_t x1, y1
o souřadnice pravého dolního rohu nalezeného objektu
uint32_t centroid_x, centroid_y
o souřadnice těžiště nalezeného objektu
uint32_t pix_cnt
o počet správných pixelů v nalezeném objektu
uint8_t change_flag
o příznak určující, jestli při inspekci řádky došlo k úpravě výše popsaných údajů.
V případě uzavření objektu je hodnota příznaku change_flag=255.
cc3_track_pkt_multi_t:
o Struktura představující datový paket, který je předáván jako parametr pro
funkce hledání objektů v obraze. Tento paket slouží pro nastavení parametrů
hledání objektů a nese i informace o všech nalezených objektech.
blobs_data[MAX_BLOBS]
o udržuje průběžné a finální informace o nalezených objektech v obraze.
Maximální možný počet nalezených objektů je definován parametrem
MAX_BLOBS
noise_filter
o hodnota noise filtru
blob_data_index
o
index prvního neuzavřeného objektu v poli blobs_data[]
min_blob_dist
o hodnota minimální vzdálenosti mezi objekty
track_invert
67
o parametr umožňující hledat v obraze pouze objekty, které jsou mimo
definovanou barevnou hranici
upper_bound
o definice horní barevné hranice objektu
lower_bound
o definice spodní barevné hranice
scratch_x, scratch_y
o dočasné hodnoty polohy testovaných pixelů
print_data
o parametr definující, jaká data se budou tisknout na výstup (0=binární obrázek;
1=nalezené informace o každém řádku; 2=pouze výpis informací o nalezených
objektech)
color_space
o parametr definující použitý barevný model (1=RGB; 2=HSV)
bool HSV_inverted
o parametr umožňující hledat H složku okolí v HSV modelu i přes 0 (např.
v rozmezí 340-40)
Popis funkcí API:
uint8_t cc3_track_multi_blobs(cc3_track_pkt_multi_t * pkt)
o Funkce provádí inspekci obrazu uloženého v obrazovém bufferu na základě
parametrů uložených v *pkt (viz výše). V tomto paketu jsou zároveň uloženy i
výsledné informace o všech nalezených objektech.
Funkce vrací hodnot 1, když inspekce obrazu proběhne úspěšně, jinak vrací
hodnotu 0.
68
Příloha C. Popis API algoritmu hledání cesty pro systém GeNav
Zdrojové kódy jsou umístěny v cc3\lib\cc3-ilp\ a jedná se o soubory cc3_genav_img_proc.h a
cc3_genav_img_proc.c. Zdrojové kódy programu, který API implementuje a funguje jako
komunikační rozhraní mezi řídicím počítačem a kamerovým modulem CMUcam3 je umístěn
v cc3\projects\genav\.
Popis datových struktur:
cc3_genav_pkt_t:
o Struktura představující datový paket, který je předáván jako parametr pro
funkce hledání cesty pro systém GeNav. Tento paket slouží pro nastavení
parametrů hledání cesty jsou v něm uložena i výsledná data nalezené cestě.
uint8_t noise_filter
o hodnota noise filter
uint16_t current_middle
o proměnná, ve které je uložena hodnota středu cesty v aktuálním řádku
cc3_pixel_t path_upper_bound
o definice horní barevné hranice cesty
cc3_pixel_t path_lower_bound
o definice spodní barevné hranice cesty
cc3_pixel_t bcg_upper_bound
o definice horní barevné hranice okolí
cc3_pixel_t bcg_lower_bound
o definice horní barevné hranice okolí
uint8_t color_space
o parametr definující použitý barevný model (1=RGB; 2=HSV)
bool path_only
o parametr definující, je-li inspekce obrazu prováděna pouze na základě
zadaných parametrů cesty nebo cesty i okolí
bool HSV_path_inverted
o parametr umožňující hledat H složku cesty v HSV modelu i přes 0 (např.
v rozmezí 340-40)
bool HSV_bcg_inverted
69
o parametr umožňující hledat H složku okolí v HSV modelu i přes 0 (např.
v rozmezí 340-40)
bool print_line_data
o parametr určující, zda-li se budou tisknout hranice cesty v každém řádku
uint16_t line_cnt
o celkový počet prozkoumaných řádků
int total_diff
o celkový součet odchylek středů prozkoumaných řádků od středu obrazu
int res_x
o výsledná hodnota úhlové rychlosti
int res_y
o výsledná hodnota dopředné rychlosti
Popis funkcí API:
uint8_t cc3_genav_img_proc(cc3_genav_pkt_t *pkt)
o Tato funkce hledá cestu v obraze uloženém v obrazovém bufferu na základě
parametrů definovaných v paketu *pkt (popis parametrů viz výše). Výsledné
hodnoty definující velikost dopředné a úhlové rychlosti jsou pak v tomto
paketu také uloženy.
Funkce vrací hodnotu 0 pokud v první testované řádce obrazu nebyla cesta
nalezena a hodnotu 1 pokud cesta úspěšně nalezena.
70
Příloha D. Popis komunikačního protokolu mezi kamerovým modulem
CMUcam3 a řídicím počítačem systému GeNav
Blok nastavování parametrů hledání cesty je inicializován odesláním příkazu PARAM\r
kamerovým modulem. Následující možné příkazy jsou:
H hmin hmax Smin Smax Vmin Vmax\r – definuje rozmezí barev cesty v HSV18 modelu
h hmin hmax Smin Smax Vmin Vmax\r – definuje rozmezí barev okolí cesty v HSV modelu
R Rmin Rmax Gmin Gmax Bmin Bmax\r – definuje rozmezí barev cesty v RGB19 modelu
r Rmin Rmax Gmin Gmax Bmin Bmax\r – definuje rozmezí barev okolí cesty v RGB modelu
A x0 y0 x1 y1\r – definuje oblast cesty v obraze ohraničenou obdélníkem, kde x0, y0 je
souřadnice jeho levého horního rohu a x1 y1 je souřadnice jeho pravého spodního rohu.
Z této oblasti je pak spočítáno rozmezí barev definující cestu v HSV modelu.
a x0 y0 x1 y1\r – definuje oblast okolí cesty v obraze ohraničenou obdélníkem, kde x0,
y0 je souřadnice jeho levého horního rohu a x1 y1 je souřadnice jeho pravého spodního
rohu. Z této oblasti je pak spočítáno rozmezí barev definující okolí cesty v HSV
modelu.
O\r – zapnutí funkce posílání nalezených krajních bodů cesty pro všechny zkoumané
řádky v obraze. Tyto hodnoty jsou posílány řídicímu procesoru v textové formě ve
tvaru:
H x01 x02 x11 x12 x21 x22 … xr1 xr2\
kde B je hlavička uvozující paket, xi0 je souřadnice levého kraje cesty v i-tém řádku,
xi1 je souřadnice pravého kraje cesty v i-tém řádku, r je celkový počet zkoumaných
řádků, „\“ je zakončovací sekvence přenosu krajních bodů cesty.
o\r – zapnutí funkce posílání nalezených krajních bodů cesty pro všechny zkoumané
řádky v obraze.
I\r – kamerový modul pošle sejmutý obraz řídicímu procesoru ve tvaru paketu:
255I šířka výška RBG0RGB1RGB2 … RGBn255
Paket je uvozen a ukončen bytem s hodnotou 255, I je hlavička paketu, šířka je šířka
obrazu přenášená jako ASCII znaky, výška je výška obrazu přenášená jako ASCII
znaky, RGBi jsou jednotlivé barevné složky i-tého pixelu přenášené v bytové formě.
18
Rozmezí možných hodnot je H=<0, 360>; S=<0, 255>; V=<0, 255>
19
Rozmezí možných hodnot je R=<0, 255>; G=<0, 255>; B=<0, 255>
71
Aby nedošlo k chybnému ukončení přenosu, jsou všechny hodnoty RGB přenášeny
s maximální hodnotou 254.
Povinným výstup z kamerového modulu je paket obsahující hodnoty dopředné a úhlové
rychlosti ve tvaru:
:07xxyy# - je výstupní informace předávaná řídicímu procesoru po každé dokončené
inspekci obrazu, kde :07 je hlavička uvozující paket, xx je velikost spočítané dopředné
rychlosti v šestnáctkové soustavě20, yy je velikost spočítané úhlové rychlosti
v šestnáctkové soustavě s nulovou výchylkou při hodnotě 7Fh, # je znak zakončující
paket.
20
Rozmezí hodnot <00, FF>
72

práci - Intelligent and Mobile Robotics Group

Transkript

Podobné dokumenty

Podpůrný software pro výuku mobilní robotiky

Bulletin 2011 - Česká společnost pro zdravotnickou techniku

Stáhnout PDF.

Import speciálních driverů

Pinnacle Studio 16 Příručky

S. OlivĂk - Západočeská univerzita

Úvod 5 1 Stručná historie a vývoj 6 1.1 1998

04-Zakladni desky - Hotelová škola Teplice

Cvicen´ı 8: Delphi - unita Graph2d, propojen´ı formulár˚u

Systém pro robotickou tele-výuku

TGA-24-9/20

400W 18x 3W LED RGB VHF sada

PŘEPÍNÁNÍ A SMĚROVÁNÍ OPTICKÝCH

Návod k montáži a obsluze WRS-ISM1

AlarmTon

Tomas Krajnik - Research outputs Journals and Magazines Books

Mikrořadiče

BOŽÍ JEDNÁNÍ S PŘÍRODOU A SKRZ NI