Název: Stereoskopický senzor
Pokyny pro vypracování: Navrhněte a realizujte stereoskopický senzor s USB kamerami, který bude poskytovat dva obrazy vhodné pro prostorové vnímání. Uvažujte možnost natáčení kamer v horizontálním a vertikálním směru pomocí serv. Prostudujte existující algoritmy pro zpracování stereo obrazu a konstrukci 2.5D obrázku. Na embedded platformě s procesorem PowerPC implementujte demo aplikaci, která bude určovat vzdálenosti předmětů před kamerami.
Zde bude oficiální zadání
i
ii
České vysoké učení technické v Praze Fakulta elektrotechnická
Diplomová práce
Stereoskopický senzor Bc. Pavel Staněk
Vedoucí práce: Ing. Miroslav Skrbek, Ph.D.
Studijní program: Elektrotechnika a informatika dobíhající magisterský Obor: Informatika a výpočetní technika Květen 2007
iii
iv
Poděkování Rád bych poděkoval vedoucímu mé diplomové práce Ing. Miroslavu Skrbdovi, Ph.D. za trpělivost a konzultace při její tvorbě. Dále všem pracovníkům z katedry strojového vnímání na Karlově náměstí za jejich čas věnovaný mě a mé práci. Panu Linus Benedict Torvaldsovy za odstartování vývoje operačního systému linux, jehož jádro je díky své otevřenosti základem zde vytvářeného zařízení. A v neposlední řadě bych rád poděkoval mé přítelkyni za její trpělivost a lásku, se kterou mě provázela po celou dobu tvorby mé práce.
v
vi
Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu § 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
V Praze dne 20.5.2005
…………………………………
vii
viii
Abstract The thesis represents my work on implementation of stereoscopic sensor. Also the implementation is focused on embedded system, the design attempt to keep wide universality. The base of system is made by microcontroller with PowePC core cooperating with two USB webcams for snapshot of stereo image. It allows to present image pair or to compute depth map and the distance of the nearest object.
Abstrakt Práce prezentuje moje postupy a výsledky při tvorbě stereoskopického senzoru. I přesto, že půjde o embedded zařízení, bude návrh prováděn s ohledem na co největší univerzálnost. Zařízení bude založené na mikropočítači s PowerPC jádrem a bude spolupracovat se dvěma USB webkamerami, ze kterých sejme stereo pár obrazů. Možné je buď jen zobrazení obrazu nebo další zpracování do hloubkové mapy a následné určení vzdálenosti nejbližšího objektu.
ix
x
Obsah Seznam obrázků
xiii
Seznam tabulek
xv
1 ÚVOD ..........................................................................................................................................1 2 POPIS PROBLÉMU, SPECIFIKACE CÍLE ..........................................................................2 3 ANALÝZA A NÁVRH ŘEŠENÍ...............................................................................................4 3.1 ZÍSKÁNÍ OBRAZU ....................................................................................................................4 3.1.1 BAYER kamery ...............................................................................................................4 3.1.2 YUV kamery....................................................................................................................5 3.1.3 JPEG kamery..................................................................................................................5 3.2 ZPRACOVÁNÍ OBRAZŮ PRO STEREOSKOPII...............................................................................6 3.2.1 Pinhole model kamery ....................................................................................................6 3.2.2 Stereoskopie....................................................................................................................7 3.3 EPIPOLÁRNÍ GEOMETRIE .........................................................................................................8 3.4 STEREOSKOPICKÉ ALGORITMY .............................................................................................10 3.4.1 SSD (traditional sum-of-squared-differences).............................................................13 3.4.2 Depth Discontinuities by Pixel-to-Pixel Stereo ............................................................14 3.4.3 Složitější algoritmy .......................................................................................................15 3.5 POHYBLIVÉ KAMERY ............................................................................................................16 3.6 URČOVÁNÍ VZDÁLENOSTI .....................................................................................................17 3.7 VOLBA SOFTWAROVÉHO PROSTŘEDÍ.....................................................................................19 3.8 VOLBA HARDWARU ..............................................................................................................21 3.9 ZVOLENÝ CÍLOVÝ HARDWARE ..............................................................................................22 3.9.1 Mikropočítač MPC5200B.............................................................................................22 3.9.2 Vývojová deska Lite5200B............................................................................................23 4 REALIZACE ............................................................................................................................26 4.1 USB PORTY ..........................................................................................................................26 4.2 LITE5200B PCI....................................................................................................................27 4.3 PCI USB ADAPTÉRY ............................................................................................................30 4.3.1 OHCI versus UHCI ......................................................................................................30 4.3.2 KOUWELL 2580E 4xUSB, VIA....................................................................................31 4.3.3 KOUWELL 2580N4 5xUSB, NEC ................................................................................33 4.3.4 ST-LAB U-143 5xUSB, NEC ........................................................................................34 4.3.5 SoNNeT Allegro USB 2.0 5xUSB, NEC........................................................................35 4.4 IRQ ROUTOVACÍ TABULKA ...................................................................................................36 4.5 MIZENÍ PCI ZAŘÍZENÍ ...........................................................................................................38 4.6 WEBKAMERY........................................................................................................................41 4.7 UŽIVATELSKÉ ROZHRANÍ ......................................................................................................42 4.7.1 Zachycení stereo obrazu...............................................................................................44 4.7.2 Ovládání zesílení kamer ...............................................................................................45 4.7.3 Zachycení stereo obrazu – webcam.html......................................................................46 4.7.4 Ovládání zesílení kamer – html ....................................................................................47 4.7.5 Zamezení použití cache.................................................................................................48 4.7.6 Hloubková mapa - html ................................................................................................49 4.7.7 Kalibrace kamer - html.................................................................................................50 xi
4.8 STEREOSKOPICKÝ ALGORITMUS........................................................................................... 51 5 TESTOVÁNÍ............................................................................................................................ 52 5.1 STEREO WEBCAM ................................................................................................................. 52 5.2 VÝKON HLOUBKOVÉ MAPY .................................................................................................. 53 5.3 KVALITA HLOUBKOVÉ MAPY ............................................................................................... 53 5.4 VÝSLEDKY KALIBRACE KAMER............................................................................................ 57 5.5 DALŠÍ EXPERIMENTY ........................................................................................................... 59 6 ZÁVĚR ..................................................................................................................................... 60 7 SEZNAM LITERATURY A DALŠÍCH ZDROJŮ .............................................................. 61 PŘÍLOHA A SEZNAM POUŽITÝCH ZKRATEK ............................................................ 66 PŘÍLOHA B
UŽIVATELSKÁ/INSTALAČNÍ PŘÍRUČKA .............................................. 67
PŘÍLOHA C UKÁZKA UŽIVATELSKÉHO ROZHRANÍ ............................................... 68 PŘÍLOHA D OBSAH PŘILOŽENÉHO CD ......................................................................... 70
xii
Seznam obrázků Obrázek 3.1: Princip Bayer kódu
4
Obrázek 3.2: Perspektivní geometrie
6
Obrázek 3.3: Ukázka kalibračního obrazce
7
Obrázek 3.4: Epipolární geometrie
8
Obrázek 3.5: Ukázka rektifikace obrazů z levé a pravé kamery
9
Obrázek 3.6: Porovnání pixelu
10
Obrázek 3.7: Hloubková mapa
10
Obrázek 3.8: Referenční snímek a disparitní obrazy pro d = 10,16,21
11
Obrázek 3.9: Dynamické programování
13
Obrázek 3.10: Princip použitého porovnávání
14
Obrázek 3.11: Úprava výpočtu vzdáleností
18
Obrázek 3.12: Mikropočítač MPC5200B
23
Obrázek 3.13: Blokové schéma LITE5200B
23
Obrázek 3.14: Vývojová deska LITE5200B
24
Obrázek 4.1: Varování na vývojové desce
27
Obrázek 4.2: Blokové schéma NEC D720101
30
Obrázek 4.3: Kouwell 2580E
31
Obrázek 4.4: Kouwell 2580E – PCI konektor strana A
32
Obrázek 4.5: Kouwell 2580E – PCI konektor strana B
32
Obrázek 4.6: Kouwell 2580N4
33
Obrázek 4.7: Kouwell 2580N4 – PCI konektor strana A
34
Obrázek 4.8: Kouwell 2580N4 – PCI konektor strana B
34
Obrázek 4.9: ST-LAB U-143
34
Obrázek 4.10: SoNNeT Allegro USB 2.0
35
Obrázek 4.11: Genius VideoCAM NB
41
Obrázek 4.12: Dvě webkamery na společné základně
42
Obrázek 4.13: Schéma zachytávání obrazu
47
Obrázek 5.1: Záběr z kamer a hloubková mapa
54
Obrázek 5.2: Obraz opěradla a hloubková mapa
55
Obrázek 5.3: Šum produkovaný kamerami
55
Obrázek 5.4: Výsledek průměrujícího filtru
56
Obrázek 5.5: Fungující detekce rohů
57
xiii
Obrázek 5.6: Nefungující detekce rohů
57
Obrázek C.1: Úvodní stránka
68
Obrázek C.2: Mód zobrazení stereo obrazu
68
Obrázek C.3: Mód hloubkové mapy
69
xiv
Seznam tabulek Tabulka 3.1 Dhrystone test
22
Tabulka 4.1: Lite5200B PCI konektor
28
xv
xvi
1 Úvod Má práce je motivována snahou o využití obyčejných USB webkamer při snímání stereo obrazu. Použití pro stereo obraz mohou být různá. Můžeme jej zpět promítat pozorovateli odděleně pro každé oko a tím tak zprostředkovat prostorový vjem na větší vzdálenost. Jinou variantou je počítačové zpracování získaného obrazu. Výsledkem mohou být hloubkové mapy (2,5D obrazy), které převádějí pozorovaný obraz na soustavu ploch barev vyjadřující vzdálenost od kamer. Ještě pokročilejším zpracováním se můžeme dostat až k tvorbě 3D modelu pozorované scény. V mém případě se zaměřím v prvé řadě na návrh malého embedded systému se schopností sejmutí stereo obrazu. V dalším kroku se ho pokusím využít i pro konstrukci 2,5D hloubkové mapy. Cílem práce není návrh nového revolučního algoritmu (či vylepšení současných algoritmů) stereoskopického vidění, toto ponechám kolegům z oblasti počítačového vidění. Pro mou práci bude dostačující použít současných známých algoritmů. Tento krok bude sloužit jako prezentace možností výsledného embedded zařízení. Z hloubkové mapy se pokusím pozorovateli poskytnout informace o vzdálenosti jednotlivých předmětů před kamerami. Při studiu stereoskopického vnímání se ještě zaměřím na možnost kamery natáčet pomocí servomotorů.
-1-
2 Popis problému, specifikace cíle Práce je založena na využití běžného počítačového příslušenství - webkamer v embedded systému. To samo nás staví před otázku, zda konstruovat čistě specializované, přesně definované zařízení. Budeme připojovat webkamery přes USB (Universal Serial Bus) – již v názvu je slovo universal – univerzální. Bylo by proto vhodné být směrem k použitým webkamerám také „univerzální“. V našem konkrétním případě bude návrh prováděn s ohledem na snadnou možnost výměny používaných webkamer, bez nutnosti zásadně měnit celý systém. Samozřejmé je, že ovládání různých webkamer je odlišné a vyžaduje jiné softwarové obslužné rutiny. Budoucí vývojář měnící používané kamery by měl zasahovat jen do subsystémů pro pořízení obrazu. V ideálním případě bude využití již existujících programů pro ovládání nových webkamer, dostačující, případně jejich využití jen s minimální nutnou úpravou. Samotné sejmutí stereo obrazu znamená prozkoumat problematiku kalibrace webkamer. Je zřejmé, že systém musí být navržen takovým způsobem, aby byla zajištěna vzájemná synchronizace kamer. Je nemyslitelné, abychom pozorovateli promítali před jedno oko obraz o sekundu zpožděný před druhým okem. V takovém případě, by vůbec nedocházelo k prostorovému vjemu, a naopak by to vedlo k dezorientaci pozorovatele. Pro zpracování sejmutého páru obrazů použijeme některý z existujících algoritmů tvorby 2,5D mapy. Pro výběr vhodného algoritmu je proto nutné nejprve prostudovat současné existující řešení a celou problematiku stereoskopie. Nabyté znalosti dále využijeme i při určování vzdáleností objektů z hloubkové mapy. Na základě znalostí o kalibraci kamer a stereoskopii budeme následně uvažovat o možnosti pohybování s kamerami. Představa je, co nejvíce se přiblížit principům lidského zraku, kdy je vzdálenost určována nejen z rozdílnosti obrazů každého oka, ale i ze znalosti polohy očních bulv. Jejich vzájemný úhel určuje vzdálenost objektu, na který se člověk soustřeďuje. I u člověka je určování vzdáleností na základě úhlů omezeno jen na velmi malý úsek vzdáleností. Budeme tedy diskutovat o možnosti plně statických i pohyblivých kamer. U pohyblivých hovoříme o možnosti určování vzdálenosti jen na základě jejich vzájemných úhlů či na kombinaci úhlů a stereoskopického zpracování získaného páru obrazů. Vývoj celého systému bude probíhat ve dvou fázích. V první budeme veškeré postupy a programy zkoušet na běžném PC linuxovém stroji. Tato vývojová platforma nám umožní snadno ověřovat funkčnost a schopnosti použitých postupů. Teprve poté zvolené části portujeme na
-2-
cílovou platformu. Z vývojové fáze nám zůstane několik nepoužitých programů, které však můžou být využity do budoucích prací.
-3-
3 Analýza a návrh řešení 3.1 Získání obrazu K pořizování stereo obrazu budou použity dvě USB webkamery. Stream dat z kamer může mít různé formáty. Běžné webkamery používají BAYER, YUV nebo JPEG. U kamer s Bayer a YUV může být k dispozici komprese založena na Huffmanově kódování či RLE. Jedná se o neefektivní způsoby komprese, které nám nijak nepomohou. Proto se při přenosu obrazu budeme potýkat s omezenou přenosovou kapacitou rozhraní USB 1.1. Předpokládám, že náročnost zpracování stereo obrazu bude natolik rozsáhlá, že nebude možné zpracovávat větší množství obrázků během jedné sekundy. Tím nás zatím propustnost rozhraní nebude omezovat. Kamery používající JPEG kompresy budou z pohledu - využití rozhraní - nejlepší, ale za cenu náročnějšího zpracování při dekompresi. Jak uvidíme později, většina známých algoritmů pro zpracování stereo obrazů do hloubkové mapy vystačí s vstupním obrazem jako 8-bit grayscale. Bude nám tedy stačit pouze obraz v odstínech šedi – pro nás je dostatečná jasová složka. Pokud obětujeme výpočetní výkon, je možné zpracovávat i barevné obrazy. Pro získání obrazu z webkamery budeme potřebovat příslušný ovladač a program pro zachycení obrazu (neboli jeho část komunikující s kamerou).
3.1.1 BAYER kamery U BAYER kamer dostáváme z kamery přímé údaje o intenzitě světla dopadajícího do jednotlivých
buněk.
Teprve
interpolací
dostáváme RGB informaci o každém bodu. U vnitřních bodů je jedna složka RGB známá, zbylé dvě se interpolují až ze 4 sousedních buněk. Pokud bychom se omezili pouze na jasovou informaci, musíme ještě uplatnit i
Obrázek 3.1: Princip Bayer kódu
následující vztah: Y = 0.30*R + 0.59*G + 0.11*B
-4-
Výpočet jasové složky můžeme skombinovat s interpolací, a tak veškeré výpočty můžeme provézt v jediném průchodu. Složitost tedy bude lineární spolu s počtem zpracovávaných pixelů.
3.1.2 YUV kamery Kamery nám posílají stream, který již jasovou složku obsahují. Můžeme buď odstranit UV složky nebo upravit všechny příslušné rutiny v stereoskopických algoritmech, aby si z kompletního obrazového streamu použily správné údaje. Postup s vypreparováním Y složky bude pro nás výhodnější. Takto získaná data budeme moci použít pro tvorbu grayscale BMP souboru, který můžeme zobrazovat uživateli. Jedná se pouze o paměťové přesuny s minimální časovou složitostí. Pokud bychom chtěli ukazovat uživateli kompletní barevný obraz, je nutný ještě převod YUV na RGB (U = B - Y, V = R - Y, Y = 0.30*R + 0.59*G + 0.11*B).
3.1.3 JPEG kamery Kamera nám přímo posílá komprimovaný JPEG. Tím je vyřešen problém zobrazování obrazů
uživateli.
Pro
zpracování
ve stereoskopických
algoritmech
je
nutné
JPEG
dekomprimovat. JPEG obsahuje zkomprimované YCbCr složky. Kompletní dekomprese JPEG souboru se skládá z následujících kroků: 1. Remove header info and quantisation factors. 2. Extract data from Huffman encode bit stream. 3. Scale each coefficient by the inverse 'quantisation' factors. 4. Prepare the coefficients for IDCT in 8x8 blocks. 5. IDCT each coefficient block. 6. Put the 8x8 pixel blocks into the image buffer. 7. Scale up the CbCr components. 8. Convert the YCbCr components into an RGB image. Vzhledem k tomu, že nepotřebujeme RGB, můžeme poslední krok vypustit. Stačí nám jen jasová složka, a tak se nám všechny kroky zjednoduší (vypustíme veškeré výpočty Cb a Cr složek) a krok 7 můžeme též vypustit. Nejsložitější ze všech kroků je kosinová transformace - O(n2). Proto je v JPEG formátu používána jen na makroblok 8x8 pixelů. Vzhledem k tomu, že budeme dekomprimovat jen jasovou složku, mohl by být celkový čas dekomprese přiměřeně dlouhý. V současnosti již nemusíme psát vlastní JPEG dekompresor. Kompletní zdrojové kódy pro dekompresi JPEG souborů jsou k dispozici např. od Independent JPEG Group [48] či Small JPEG Decoder Library [49].
-5-
3.2 Zpracování obrazů pro stereoskopii Pro zpracování obrazu potřebujeme znát, jakým způsobem jsou jednotlivé body 3D prostoru promítány na námi získané obrazy v kamerách. K tomu nám poslouží model kamery.
3.2.1 Pinhole model kamery Pinhole model, neboli dírkový model je jeden z nejjednodušších modelů kamery. I přes svou jednoduchost poskytuje dostatečné výsledky. Využívá perspektivní geometrie.
Obrázek 3.2: Perspektivní geometrie
Model obsahuje 11 parametrů. Pět vnitřních popisujících konstrukci kamery a šest vnějších popisujících její polohu. Matematicky můžeme model vyjádřit takto: s*m' = K*[R|t]*M' , neboli u f x s ⋅ v = 0 1 0 Kde
0 fy 0
c x r11 c y ⋅ r21 1 r31
r12 r22 r32
X r13 t1 Y r23 t 2 ⋅ Z r33 t 3 1
(X,Y,Z) jsou světové souřadnice bodu v 3D prostoru, (u,v) jsou souřadnice projekce bodu v pixelech, K je kalibrační matice kamery obsahující vnitřní parametry: cx, cy jsou středy obrazu fx, fy jsou ohniskové vzdálenosti v upravených jednotkách (k pixelu) R,t je matice otočení a posunutí, tvoří vnější parametry -6-
U některých profesionálních kamer jsou vnitřní parametry kamery udávány výrobcem. U webkamer toto nemůžeme čekat, a proto si parametry musíme získat sami. Existují metody kalibrace z neznámé scény, ale ty nepracují spolehlivě. Velmi záleží na pozorované scéně. Spolehlivější metody pracují s kalibrací na známé scéně či za pomoci známého objektu. Právě kalibrace za pomoci známého objektu je ideální metodou. Kamerám předložíme známý obrazec, na kterém umíme snadno najít korespondující si body a z jejich pozice na každém z obrazů odhadneme parametry kamer. K tomuto můžeme například využít OpenComputerVision knihovnu [50]. Obsahuje funkce pro odkad parametrů na základě známých bodů. Tyto body můžeme zjistit v obraze za pomoci jiné funkce pro detekci rohů na šachovnici. Jediné, co budeme muset pro kalibraci kamer udělat, je podržet před nimi na určitý čas černobílou šachovnici.
Obrázek 3.3: Ukázka kalibračního obrazce
3.2.2 Stereoskopie Porovnávání dvou dvourozměrných obrazů je neúnosně složité. Pro každý pixel jednoho obrazu bychom museli hledat korespondenci v celé velké oblasti druhého obrazu. Pro redukci prohledávaného prostoru využívá stereoskopie epipolární geometrie. S její pomocí provedeme rektifikaci (úpravu do epipolární geometrie) obrazu. Ve výsledných obrazech si poté jednotlivé řádky odpovídají, stačí tak porovnávání jen v jednom rozměru.
-7-
3.3 Epipolární geometrie Uvažujme případ dvou kamer, obecně s různými maticemi kalibrace K1, K2, které pozorují
shodnou
scénu.
Promítací paprsky daného bodu X tvoří promítací (epipolární) rovinu,
ta
protíná
průmětny
kamer ve sdružených přímkách (epipolárách).
Vazbu
průměty
X2
X1,
odvodíme
z
mezi
bodu
vlastnosti,
X že
spojnice středů C1, C2 a oba promítací paprsky leží v jedné Obrázek 3.4: Epipolární geometrie
promítací rovině.
Bez újmy na obecnosti můžeme předpokládat, že pevný souřadný systém splývá se souřadným systémem první kamery. Promítací rovnice kamer jsou pak tvaru: X1 = P1X = K1(0, I)X
,
X2 = P2X = K2(R,t)X
vektor t a matice rotace R určují transformaci mezi objektivy kamer. Vhodným skombinováním obou kalibračních matic, rotace a posunutí dostaneme matici F. Nazýváme ji fundamentální matice snímků. Je to matice 3×3 s hodností 2. Pro dva snímky je fundamentální matice určena jednoznačně a obráceně daná fundamentální matice určuje dvojici projekčních matic kamer P1, P2 až na násobení projektivní maticí. Pro stereo analýzu je tedy zásadním úkolem co možná nejpřesnější odhad fundamentální matice. Celkem je pro její výpočet nutné určit 7 parametrů. Pro odhad fundamentální matice je popsán lineární tzv. osmi-bodový algoritmus. Nevýhodou osmibodového algoritmu je, že ačkoliv esenciální matice má jen pět volitelných parametrů, užití tohoto algoritmu vyžaduje alespoň osm dvojic odpovídajících si bodů. Navíc je nutné, aby mezi objektivy kamer bylo nenulové posunutí a pozorované body musí ležet alespoň ve dvou různých rovinách. Pro odhad fundamentální matice můžeme opět využít knihovnu OpenCV [50]. Epipolární geometrie nám zaručuje, že k projekci bodu v prvním obraze bude projekce do druhého obrazu na stejném řádku. Tím se nám prohledávaný prostor zmenší jen na porovnávání odpovídajících si řádků. Úpravu získaných obrazů z kamer do epipolárního prostoru, nazýváme rektifikace.
-8-
Pokud obě kamery řádně zaměříme tak, aby průsečík obou os byl v nekonečnu tzn. aby se obě kamery „dívaly“ do nekonečna, nebude plná rektifikace nutná. Budeme muset jen ošetřit drobné nedostatky v upevnění kamer a jejich snímacích čipů. Je téměř jisté, že dojde k nějakému vzájemnému posunutí či natočení obrazu. K nápravě nám tak bude stačit mnohem jednodušší úprava bez znalosti fundamentální matice. Z detekovaných rohů šachovnice jen určíme co nejoptimálnější afinní transformaci mezi obrazy.
Obrázek 3.5: Ukázka rektifikace obrazů z levé a pravé kamery (vpravo jsou naznačeny epipoláry)
-9-
3.4 Stereoskopické algoritmy Z předchozího již víme, že se nám celý vyhledávací prostor zmenšil jen na vyhledávání v 1D. Problém ilustruje následující obrázek 3.6. Musíme co nejlépe odhadnout kam se nám daný pixel posunul. V případě, že se jedná o pixel pozadí, bude jeho poloha v jednom
obrázku
odpovídat
i Obrázek 3.6: Porovnání pixelu
v druhém.
Pro vyjadřování této vzdálenosti byl zaveden pojem disparity (v podstatě vyjadřující inverzi hloubky). Odpovídající si pixely mají nulovou disparitu. Cílem algoritmu je tvorba hloubkové mapy nebo též disparitní mapy, obsahující odhad disparity pro každý pixel. Samozřejmě porovnávání jediného pixelu by vedlo k nepříliš dobrým výsledkům. Objevovaly by se velmi rozdílné hloubky hned na sousedních bodech. Z těchto důvodů se využívá složitějších postupů, kdy jsou porovnávány celé skupiny pixelů. Očekáváme, že v obraze budou velké plochy s podobnou disparitou, neboli se stejnou hloubkou, a jen občas nějaký výrazný rozdíl, kdy se výrazně mění hloubka viz. obrázek 3.7.
Obrázek 3.7: Hloubková mapa
Pixelovým souřadnicím (x, y) referenčního snímku odpovídají souřadnice (x´, y´) na zkoumaném snímku. Jejich vzájemný vztah je: x´= x + s d(x, y) kde
,
y´ = y
s = ±1 je znaménko zvolené tak, aby disparita byla vždy kladná. d(x, y) je disparita daného bodu.
Velká skupina algoritmů se chová velmi podobně. Jen na určité fáze výpočtu používají jiné funkce s obdobným významem. Fungují tak, že pro několik disparit určují míru podobnosti (či spíše nepodobnosti, nebo také cena za spárování) intenzit odpovídajících si bodů - počítají několik obrazů. Pro každý je - 10 -
definováno konstantní posunutí. Pokud si body přesně odpovídají, obsahuje disparitní obraz nulovou hodnotu. Čím více se intenzity liší, tím větší hodnotu obsahuje. Hodnoty míry podobnosti přes všechny pixely a všechny disparity tvoří prostor disparitních obrazů, který značíme C(x, y, d). Cílem daného algoritmu je nalézt co nejoptimálnější výběr disparit tak, aby co nejvíce odpovídaly povrchům objektů v obraze. Jinak vyjádřeno přes všechny tyto obrazy hledáme, jak z nich vybírat vítěze a přitom moc nepřeskakovat z jednoho na druhý. To jakým způsobem jsou určovány ony míry podobnosti, vyrovnávání se s rychlými změnami podobnosti mezi sousedními pixely a výběrem vítězné disparity, je pro každý z algoritmů specifické.
Obrázek 3.8: Referenční snímek a disparitní obrazy pro d = 10,16,21 Větší černé plochy jsou obrazem shody, malé černé oblasti můžou být chyby vlivem textur na objektech.
Jejich společnou charakteristikou jsou následující 4 fáze výpočtu: 1. 2. 3. 4.
Výpočet mír podobnosti pro veškeré dané disparity Agregace vypočtených mír při dané disparitě Určení výsledné (vítězné) disparity pro každý pixel Doladění výsledné hloubkové mapy
Ad 1. Pro výpočet podobnosti se používá např. squared intensity differences (SD) či absolute intensity differences (AD). Názvy jsou dostatečně vystihující. Jedná se o kvadrát rozdílů jasu či jen jeho absolutní hodnota. Jako další úprava se používá saturace, kdy se hodnoty větší než předem definovaná hodnota změní na tuto hodnotu. Toto omezení přispívá k lepším výsledkům v druhém kroku. Mezi další metody výpočtu míry podobnosti patří normovaná cross korelace či binární porovnání (souhlasí/nesouhlasí). Birchfield a Tomasi navrhli metodu, kdy pixel není porovnáván vůči pixelu druhého snímku, ale vůči funkci, která je lineární interpolací druhého obrázku.
- 11 -
Ad 2. Úkolem agregace je zakrýt drobné výkyvy. U lokálních metod založených na okénku se jedná o součet či průměr daného regionu. Jiné metody využívající informací ze všech disparitních obrazů používají omezení změny disparity či omezení gradientu disparity. Ad 3. Při tomto kroku existují dva rozdílné přístupy – lokální a globální. Lokální metody hledají jen v určitém okolí daného bodu, globální hledají vhodný výběr disparit po celé délce řádku jako jednoho celku (tím mají lepší přehled a často nepotřebují druhou fázi). U lokálních metod existuje jednoduchý způsob výběru výsledné disparity - “winnertakeall” (WTA) – vítězem je pro daný pixel ta disparita, která má nejmenší agregovanou míru podobnosti. Agregace nám zajišťuje souvislejší plochy a vyloučení jednopixelových chyb. U globálních metod se většinou jedná o minimalizaci energie. Úkolem je najít disparitní funkci d, která minimalizuje globální energii: E(d) = Edata(d) + λEsmooth(d). Data term Edata(d) měří, jak moc dobře disparitní funkce d souhlasí s vstupním obrazovým párem. E data (d ) =
∑ C (x, y, d (x, y ))
(x, y )
Kde prostor disparitních obrazů může být dle situace jak počáteční tak agregovaný. Druhý term se většinou omezuje jen na měření rozdílů disparit mezi sousedními pixely. E smooth (d ) =
∑ ρ (d (x, y ) − d (x + 1, y )) + ρ (d (x, y ) − d (x, y + 1))
( x, y )
Kde ρ je určitá monotónně vzrůstající funkce rozdílů disparit. Jakmile máme definovanou energii, můžeme aplikovat mnoho různých algoritmů pro její minimalizaci jako jsou simulované ochlazování, max-flow či graph-cut (převádí problém na hledání příslušnosti pixelu k dané hloubce - labeling problem).
- 12 -
Jiný přístup k globální optimalizaci dynamické
tvoří
např.
programování. přístup
Tento minimální
hledá
cenu
cesty tvořenou
v matici
korespondujícími řádky. Vše ilustruje
následující
obrázek 3.9. Malá písmena (a–k) symbolizují intenzity podél jednotlivých
řádků.
písmena
Velká
symbolizují
hledanou cestu. Odpovídající pixely jsou označeny M.
Částečně
viditelné
pixely
Obrázek 3.9: Dynamické programování
jsou indikovány L či R podle toho, ve kterém obrázku jsou viditelné. Za každý takovýto částečně viditelný pixel je udělena fixní penalta. Pokud omezíme disparitu na hodnoty 0–4, stačí abychom počítali jen na bílých čtvercích. Tím si výrazně omezíme časovou náročnost tohoto řešení. Dalšími možnostmi jsou např. kooperativní algoritmy, které iterativně provádí lokální výpočty vedoucí ke globální minimalizaci.
3.4.1 SSD (traditional sum-of-squared-differences) Jedná se o jeden z velmi jednoduchých algoritmů, který i přesto poskytuje relativně slušné výsledky. Jde shrnout do následujících tří bodů: 1. míra podobnosti je kvadrát rozdílů intenzit při dané disparitě 2. agregace je součtem mír přes čtvercové okno při dané disparitě 3. výsledná disparita je vybrána jako minimální agregovaná hodnota pro každý pixel (WTA). Tento algoritmus a mnohé další jsou implementované v jediném programovém balíku StereoMatcher [43]. Můžeme místo implementace vybraného algoritmu portovat celý balík (či jeho důležité
části) a pak dle dostupného výkonu či požadované rychlosti odezvy využít různých algoritmů.
- 13 -
Je možné např. předpřipravit několik profilů produkujících různě kvalitní výsledky a dát uživateli možnost volby - zda chce přesné výsledky s velmi pomalou odezvou nebo rychlé ale ne tak přesné odezvy.
3.4.2 Depth Discontinuities by Pixel-to-Pixel Stereo (Stan Birchfield, Carlo Tomasi) Autoři definují zajímavý způsob, jak počítat míru podobnosti. Nejedná se o klasickou aplikaci subpixelových výpočtů. Pixel jednoho obrazu xi není porovnáván vůči pixelu v druhém obraze
yi.
Provede
se
interpolace a zjišťuje se minimální hodnota
a
maximální
intenzity
kolem
pixelu (o půl pixelu na obě strany).
Obrázek 3.10: Princip použitého porovnávání
Pokud se zkoumaná intenzita vejde do zjištěného intervalu, je podobnost dokonalá, pokud ne, je spočtena míra podobnosti. Toto zajišťuje mnohem lepší párování a rozdílnost zesílení kamer nebude mít takový vliv na celkovou kvalitu. Určení finální disparity je v algoritmu počítáno za pomoci dynamického programování. Jak bylo dříve řečeno, dynamickým programováním minimalizujeme globální energii. Funkce popisující energii v našem případě je: Nm
γ (M ) = N occκ occ − N mκ r + ∑ d ( xi , y i ) i =1
kde
Nocc, Nm jsou počty nespárovaných a spárovaných úseků (ne pixelů) κocc, κr jsou konstantní penalta nespárovaných a odměna spárovaných úseků
V tomto algoritmu jsou dále použity různé dolaďovací úpravy. Např. dle disparity očekáváme, že nespárované pixely se objeví v levém nebo v pravém obraze, podle toho, kde je bližší objekt. Též během výpočtu dynamického programování je prohledávaný prostor více omezován a jednotlivé cesty optimalizovány. Posledním krokem je pokročilý postprocessing disparitní mapy, tak aby se rozšířily informace z jednotlivých řádků do celé mapy. Jsou hledány souvislé kusy stejné hloubky v obou
- 14 -
směrech - v horizontálním i vertikálním směru a dle nich jsou případně upravovány okolní hloubky pro vyhlazení určitých nerovností. Implementace daného algoritmu je součástí již zmiňované knihovny OpenCV[50].
3.4.3 Složitější algoritmy Složitějších algoritmy (založeny na graph-cut apod.) jsou ve své původní podobě pro naše účely již příliš složité. Je nutná silná optimalizace nikoli na úrovni kódu, ale na úrovni vnitřních optimalizacích jednotlivých postupů. Tyto optimalizace vyžadují rozsáhlé znalosti z teorie zpracování stereovize i grafiky jako takové. To je vzhledem k mému zaměření mimo mé schopnosti. I tak můžeme do finálního stereoskopického senzoru portovat zdrojový kód algoritmu Efficient Belief Propagation for Early Vision (Pedro F. Felzenszwalb, Daniel P. Huttenlocher), který mám k dispozici. Algoritmus je založen na graph cuts a belief propagation, avšak původní postupy jsou nahrazeny výrazně optimalizovanými náhradami produkujícími ekvivalentní výsledky. Výpočetní složitost je odměněna opět lepšími výsledky.
- 15 -
3.5 Pohyblivé kamery Uvažujme nyní možnost pohyblivých kamer. Z předešlého textu je patrné, že rekonstruovat hloubkovou informaci stereoskopickými algoritmy z obrazů bez znalosti geometrie scény je prakticky nemožné. Potřebujeme při pohybu pokaždé upravit příslušné projekční matice kamer. Pokud budeme mluvit o natočení kamery, mohli bychom uvažovat na základě znalostí úhlu natočení upravíme příslušným způsobem matici otočení. Problémem je, že otáčení nebude probíhat ve středu promítání. Trefit se do tohoto středu by znamenalo mít dopředu přesnou znalost o jeho poloze a na základě toho smontovat osu otáčení. Provádět po každém otočení novou kalibraci je nepraktické. Byla by možnost za pomoci několika kalibrací a složitých výpočtů určit přesné parametry celé otáčecí soustavy, a tak určit nutné úpravy matic při otáčení, ale složitost tohoto úkonu je za hranicemi této práce. Mohli bychom opustit principy stereoskopického vidění a vydat se jiným směrem. Uvažujme otočné kamery, u každé je nám znám optický střed a úhel natočení v obou osách. Pokud dostaneme „z hůry“ bod na nejbližším objektu (pro oba obrazy), můžeme využít jiných technik k určení jeho vzdálenosti. Zaznamenáme si parametry daného objektu a budeme kamerou pohybovat tak, aby se střed tohoto objektu srovnal s optickým středem kamery. Toto je ekvivalentní s hledáním pohybu objektu před kamerou. Po jednotlivých snímcích budeme hledat, kam se objekt posunul, jak změnil své parametry a dále jen budeme směrovat do středu kamery. Jakmile bude objekt ve středech obou kamer, můžeme ze znalosti úhlů natočení kamer určit jeho vzdálenost. Problémem zde je získání obou počátečních poloh nejbližšího objektu. Pokud budeme mít jednu, můžeme aplikovat metody hledání známého objektu v obraze. Ze známého obrazu daný objekt převezmeme a budeme hledat co nejpodobnější objekt v druhém obrazu. Hledat samozřejmě budeme od nejpravděpodobnějšího místa tj. ve stejné výšce apod. Pokud bychom byli schopni se s kamerami pokaždé dostat do stejné výchozí pozice, kde budeme mít známou kalibraci, můžeme se zde pokusit aplikovat některý jednoduchý stereoskopický algoritmus a najít tak hledaný nejbližší objekt. Otázkou je, zda přesnost nastavení kamer do výchozí pozice bude dostatečně přesná, aby uložená kalibrace umožňovala adekvátní výsledky stereoskopického algoritmu. Celkově tedy možnost pohyblivých kamer nám spíše „přidělá“ problémy, než aby nám pomohla. Na druhou stranu by tímto bylo možné efektní sledování pohybu již zachyceného objektu a tím průběžné rychlé úpravy jeho aktuální vzdálenosti. Proto od možnosti pohybu s kamerami v naší realizaci upustíme.
- 16 -
3.6 Určování vzdálenosti V našem případě, kdy máme obě kamery paralelně je určování vzdálenosti velmi jednoduché. Stačí nám k tomu jednoduchá podobnost trojúhelníků. V obecném případě bychom museli používat složitější výpočty, tedy nejen jednodušší kalibrace, ale i jednodušší výpočet vzdálenosti nás vedou k potřebě kamer směřující svou osou do nekonečna. Z promítání daného bodu přes čočky objektivu na snímací čipy můžeme snadno sestrojit rovnici: d p = f l Kde
d je hodnota disparity v pixelech p je vzdálenost mezi kamerami v reálných jednotkách (11cm) l je vzdálenost objektu od kamer ve stejných jednotkách jako p f je ohnisková vzdálenost, kterou dostaneme z kalibrace. Není v reálných
jednotkách, ale pojí reálné souřadnice zadané funkcí k velikosti pixelů. U ohniskové vzdálenosti je nutné si uvědomit ještě jeden drobný fakt. Kalibrační funkci předkládáme obrazec a také souřadnice v reálném světě. V našem případě definujeme, že kalibrační obrazec je přesná šachovnice, kde každý dílek má rozměr 1x1 dílek. Spojení dílku s reálnou jednotkou je již jednoduché. Záleží na nás jak velký dílek si vytiskneme, pouze musíme upravit hodnotu ohniskové vzdálenosti. V pokusech na vývojové platformě jsem měl kalibrační obrazec s velikostí dílku 1,8 cm. Hodnota ohniskové vzdálenosti pak byla cca 400 („pixel/dílek“). Můžeme tedy buď upravit výslednou hodnotu ohniskové vzdálenosti nebo udělat výpočet univerzální a upravit vzorec. Pro vzdálenost dostáváme:
l=
k⋅ f ⋅p d
Jak vidíme, je hodnota disparity v jmenovateli. Při nulové disparitě (odpovídající si pixely v obrazech) je hodnota vzdálenosti nekonečná což odpovídá předpokladům. Nyní bychom se ještě měli zabývat myšlenkou nedokonalosti kamer. Snímací čipy nemají nekonečně snímacích bodů, a tak produkují jen diskrétní výsledky. Uvažujme proto případ, kdy se velmi vzdálený bod bude promítat do odpovídajících si bodů v obou kamerách. Takto vzdálený bod je nalezen s nulovou disparitou, to by mělo odpovídat nekonečné vzdálenosti, což
- 17 -
samozřejmě není pravda. Je proto třeba najít maximální vzdálenost pro dané kamery a příslušně upravit přepočet na vzdálenost. K výpočtu maximální vzdálenosti vycházím z pozorovacího úhlu. Ten jsem u kamer odhadl na cca 60°. Při rozlišení 352 bodů odpovídá úhel cca 0,17° na jeden pixel. Pro bod ležící na ose mezi kamerami budeme chtít, aby se promítal do kamer pod maximálním úhlem 0,17°/2. U použitých kamer je maximální vzdálenost cca 33metrů. Vše za touto vzdáleností bude splývat do stejných pixelů. Ve výpočtech vzdáleností zavedeme korekci posunutím celé křivky do požadovaného maximální vzdálenosti viz obr. 3.11
Obrázek 3.11: Úprava výpočtu vzdáleností
Vzhledem k tomu, že prvním krokem stereoskopického algoritmu je drobné rozmazání obrazu může nulové disparitě odpovídat i ještě bližší objekt.
- 18 -
3.7 Volba softwarového prostředí Při volbě implementačního prostředí musíme mít na paměti, že potřebujeme připojovat USB webkamery. Jak bylo dříve zmíněno, bude vhodné, aby nám softwarové prostředí umožňovalo s minimem potřebných změn připojit kamery libovolného typu. Tedy aby i software patřil spíše do oblasti personálních počítačů než do oblasti embedded systémů bez operačních systémů. Ideálně se nám k tomuto účelu bude hodit operační systém linux. Na vývojové platformě můžeme použít kompletní distribuci linuxu. Na cílové platformě se omezíme jen na potřebné minimum. Tedy hlavně linuxové jádro a pár základních komponent systému. Vzhledem k tomu, že celé jádro je postaveno na jazyku C a všemi jeho částmi se prolíná snaha o co největší kompatibilitu a přenositelnost, není v dnešní době problém s crosskompilací na velké množství embedded mikropočítačů. Samozřejmě si nesmí pod touto schopností čtenář představovat kompilaci jádra pro miniaturní 8-bitové mikropočítače. Jedná se o velice pokročilé mikropočítače obsahující 32-bitové jádro s pokročilou podporou běhu operačních systémů. Klasickou ukázkou můžou být např. jádra PDA zařízení, routerů apod. Z teorie operačních systémů jmenujme alespoň jeden z nejhlavnějších požadavků, a to je
řízení úrovní, na kterých daný kód běží. V základu stačí dvě úrovně – jádra a uživatelská. Přičemž nižší uživatelská úroveň nemá práva zasahovat do vyšších úrovní. Přímo v hardwaru je zakomponována (v případě snahy o takovéto narušení) reakce, kdy se vyvolá příslušná rutina jádra. Tímto je zajištěno, že jádro může spravovat běh jednotlivých procesů. Vraťme se nyní k linuxovému jádru. Podpora USB zařízení je v něm obsažena, a tak by neměl být problém vytvořit v našem systému potřebný počet portů. Podpora webkamer jako takových také není problém. Existuje již velká řada ovladačů ve standardním jádře. Případná výměna za jiný typ by pak měla spočívat jen v překompilování jádra s podporou příslušné kamery. Samozřejmě tím je vyřešen pouze problém ovladačů kamery. Grabovací obslužný program se bude muset měnit také. I zde nám, otevřenost linuxu a postavení nad C, pomůže. Stačí mít k dispozici zdrojové kódy a provést příslušnou crosskompilaci. Linuxová komunita je naštěstí dosti rozsáhlá, a tak by neměl být problém ke každé podporované kameře najít i odpovídající grabber včetně zdrojových kódů. K dispozici jsme měli vynikající nástroj ELLINOS 4.0 Jedná se o pokročilý konfigurační nástroj. K dispozici je uživateli ELK - Embedded Linux Konfigurator – grafické konfigurační rozhraní, kde si může uživatel nakonfigurovat podporu jednotlivých zařízení v jádře. Jde i volit zda se má použít jádro 2.4.31 nebo 2.6.12. Podporovány jsou platformy PowerPC, x86, MIPS, ARM, Xscale. Můžeme tak využít velmi širokou škálu různých embedded - 19 -
systémů či jen obyčejné PC. V systému si můžeme i zvolit konkrétní vývojové desky od mnoha různých výrobců (Kontron, MEN, AMCC, Digital-Logic, Freescale, Motorola, Phytec, AMD, Intel, IBM). Systém automaticky předpřipraví potřebné volby pro podporu integrovaných komponent a naopak zablokuje volby chybějícího hardwaru. Následně do ELinOSu přidáváme vlastní zdrojové kódy programů pro přeložení. Na jedno kliknutí uživatele se spustí kompletní crosskompilace jádra dle zvolených parametrů, podpůrných programů i uživatelských kódů do jediného výsledného obrazu, který můžeme nakopírovat na cílovou platformu. Pro podporu manipulace s obrázky zakomponujeme podporu, již zmiňované, OpenCV knihovny.
- 20 -
3.8 Volba hardwaru Jak bylo v předchozí části zmíněno, budeme používat software založený na linuxu. Otázkou zůstává na jakém hardwaru daný software provozovat. Jednou z možných variant by bylo použití upravených osobních počítačů založených např. na standartu VIA EPIA formátu MINI ITX. Jedná se o základní desku (s procesorem a množstvím integrovaných komponent) klasického osobního počítače (IBM PC). Celý návrh této desky se zaměřuje na miniaturní rozměry a malou produkci tepla, tak aby bylo možné celý systém integrovat do malé krabičky např. někam k televizi. Řadí se spíše někam do kategorie osobních počítačů do obývacího pokoje apod. Tímto návrhem bychom dostali dokonale univerzální hardware i s hardwarovou kompatibilitou - s linuxem i386. Nebyla by tedy nutná crosskompilace a nemuseli bychom rozdělovat vývoj pro vývojovou a cílovou platformu. Na druhou stranu by takovéto řešení mělo i velmi mnoho nevýhod. Prototyp by se sice na základní desce vytvořil snadno, ale pokud bychom pak chtěli produkovat finální produkt, zbytečně bychom distribuovali zákazníkům i nepoužívané komponenty a tím prodražovaly celý návrh. Další vlastností je nutnost ATX zdroje. A celkově velmi velká spotřeba a produkované teplo (ve srovnání s embedded systémy). Pokud využijeme vývojovou desku s nějakým klasickým pokročilým embedded procesorem, získáme dostatečně variabilní prostředí pro vývoj prototypu. Teoretická budoucí produkce finálního výrobku by se mnohem snáze optimalizovala na cenu. Z vývojové desky vynecháme veškeré nepoužívané subsystémy a celou desku plošných spojů si navrhneme sami s ohledem na potřebný prostor a použité dodatečné komponenty. Samozřejmě i spotřeba bude v úplně jiných kategoriích. Budeme napájet hlavně embedded procesor, který i přes velké množství komponent a výkon bude mít malou spotřebu. Samozřejmostí u takovýchto procesorů je pokročilá správa řízení napájení, a tak se můžeme snadno zaobírat i myšlenkou velmi úsporného běhu během doby, kdy nejsou na zařízení kladeny výkonnostní nároky.
- 21 -
3.9 Zvolený cílový hardware K dispozici jsem měl vývojovou desku Freescale LITE5200B s procesorem MPC5200B. Jedná se o mikropočítač s powerpc jádrem. Máme tak ideální základ pro provoz linuxového jádra na velmi pokročilém procesoru. Původní powerpc architektura je základem procesorů pro starší desktopové počítače APPLE. Tímto základem v osobních počítačích bude tento procesor poskytovat dostatečně výkonnou platformu.
3.9.1 Mikropočítač MPC5200B Na vývojové desce je osazen mikropočítač MPC5200B, který má tyto vlastnosti:
• • •
Maximální frekvenci 466MHz PowerPC 603e procesorové jádro s FPU jednotkou (double precision), hardwarovou MMU a BestComm DMA. Ve výkonnostním testu Dhrystone 2.1 bylo procesoru naměřeno 885 MIPS (760 MIPS při 400MHz). Pro srovnání výkony klasický PC procesorů najdeme v tabulce 3.1 [52]. Zevrubným porovnáním vidíme, že procesor
MPC5200B má srovnatelný výkon jako Intel Pentium III na 550MHz (v celočíselných operacích). Mnohem
zajímavějším
kontextem
tohoto
porovnání je porovnání spotřeby. Embedded počítač MPC5200B má při frekvenci 400MHz (1,5V napětí jádra, 2,5V DDR, zbytek 3,3V) spotřebu jen cca 1W! (Pentium III 550MHz Slot1 2,0V jádro má spotřebu cca 40W [53]) Co do periferií je v mikropočítači MPC5200B přímo integrováno rozhraní PCI verze 2.2, 2xCAN,
CPU AMD 80386 80486 DX2 Pentium Pentium Pentium MMX Pentium II Pentium III Pentium III Pentium III Pentium 4 Ath4 Barton Pentium 4E Athlon XP Pentium 4 Athlon 64 Core 2 Duo 1 CP
MHz 40 66 75 100 200 300 450 600 1000 1900 1800 3000 2080 3678 2211 2400
MIPS 13,7 35,3 87,1 122 276 477 722 959 1595 2003 3172 3553 3700 4227 4462 6446
J1850, I2C, I2S, sériový UART, USB, SPI, AC97, COP/JTAG, 10/100 Ethernet MAC, IDE/ATA a DDR
Tabulka 3.1 Dhrystone test
paměťový kontrolér. Samozřejmostí je v případě oželení vybraných uvedených funkcí uvolnění jejich I/O pinů na zcela univerzální I/O piny. Vybavenost, výkonnost a komplexnost tohoto embedded mikropočítače vidíme i na jeho blokovém schéma na obrázku 3.12.
- 22 -
Obrázek 3.12: Mikropočítač MPC5200B
3.9.2 Vývojová deska Lite5200B Vývojová deska se dá jednoduše shrnout do blokového schéma viz. obrázek 3.13. Reálný pohled je na obrázku 3.14. K procesoru je připojeno 256MB 266MHz DDR RAM, což bude dostatek pro kompletní běh linuxu i z ramdisku. Dále 32MB flash paměti pro uložení finálního obrazu aplikace. Tuto paměť během vývoje nebudeme využívat,
abychom
zbytečně
nesnižovali její životnost. Jeden sériový port, který půjde použít pro připojení ke
Obrázek 3.13: Blokové schéma LITE5200B
konzoly. Ethernet port bude ideální spojení s okolím. Dále se na desce nachází dva can konektory a IDE kanál, ty však potřebovat nebudeme. Pro připojení kamer je na desce
- 23 -
k dispozici jeden USB port a jeden konektor pro uživatelem dodaný USB transceiver. V neposlední řadě se na desce nachází dva PCI konektory, jejich arbiter v PLA programovatelném obvodu a vývody PCI sběrnice. Přeprogramováním arbiteru a napojením se na vyvedené piny jde počet PCI slotů či připojených PCI zařízení libovolně rozšířit. Další vyvedené piny jsou univerzálním I/O piny. Napájení je řešeno buď jedním 5V napájením, nebo standardním počítačovým molex konektorem. Jak vývojová deska tak procesor mají přívlastek „B“, pokud se podíváme na stránky výrobce zjistíme, že existuje i starší dále nepodporovaná varianta bez „B“. Starší vývojová deska LITE5200 má např. jen jeden PCI slot, menší paměť apod.
Obrázek 3.14: Vývojová deska LITE5200B Na vývojové desce je přednahrán u-boot loader, který nám umožňuje nabootovat systém z mnoha různých zařízení. Ze sítě prostřednictvím TFTP protokolu, BOOTP či přes NFS. Loader může i ovládat ATA a USB zařízení a načíst tak třeba systém z FAT oddílu na disku.
- 24 -
Právě síťové rozhraní tvoří ideální řešení. Počítač s ELinOSem, kde budeme provádět crosskompilaci spojíme s vývojovou deskou počítačovou sítí. Nastavíme parametry na pevné IP adresy aby se zařízení vzájemně viděla. Pak již není problém na vývojovém počítači spustit TFTP server, do kterého uložíme vygenerovaný obraz z ELinOSu. Na vývojové desce můžeme do proměnných prostředí uložených ve flash paměti napevno nastavit, aby se přes TFT protokol stahoval a spouštěl daný obraz. Nemusíme tedy mít připojenu ani sériovou konzolu pro nastartování systému. Při vývoji ji zajisté využívat budeme, uvidíme veškeré hlášky o bootu linuxu, detekovaných zařízeních apod.
- 25 -
4 Realizace Vývoj softwaru na vývojové platformě nepotřebuje žádné větší přípravy. Pro cílovou platformu nám samotná vývojová deska k výslednému stereoskopickému senzoru nestačí. Z těchto důvodů si musíme připravit kompletní hardwarové prostředí. Poté můžeme zkoušet přes ELinOS crosskompilaci připravených programů a hlavně vyladění nastavení jádra pro připravenou platformu. Pokud již budeme mít vyřešenu podporu veškerého hardwaru na cílové platformě můžeme dodávat a odlaďovat další uživatelský software.
4.1 USB porty Vývojová deska lite5200b má vyveden jen jediný USB port. Za pomoci přídavného modulu s transceivery lze použít i druhý port USB hubu. Vzhledem k tomu, že použitý USB root hub je jen revize 1.1 a naší potřebě, co největší šířky pásma, nemůžeme využít druhého portu. Musíme připojit celý další USB subsystém. To můžeme udělat v zásadě dvěma způsoby. V prvním případě využijeme zbylé univerzální IO piny procesoru a na ně připojíme kompletní USB. Toto řešení by zajisté bylo optimální při návrhu finálního minimalizovaného embedded zařízení. V naší fázi vývoje prototypu na vývojové desce zkusíme využít druhý postup a to rozšíření o další USB přes již implementované univerzální rozhraní. Konkrétně použijeme PCI rozšiřující kartu – USB řadič.
- 26 -
4.2 Lite5200B PCI Na vývojové desce Lite5200B jsou dva PCI sloty. Jedná se o 3,3V sloty – neboli konektory mají klíč vpředu (blíže vývodům) na pinech 12 a 13. Většina slotů, se kterými se
člověk dostane do styku – u počítačů typu PC apod. – je s 5V IO logikou. Neboli klíč mají vzadu na pinech 50 a 51. Na současném trhu nenajdeme přídavné karty, které by byly jen na 3,3V IO logiku, existují karty, které jsou pouze do 5V slotů (mají jen jeden zářez) a pak univerzální karty jak pro 3,3V tak 5V. Tyto karty mají klíčovací zářezy dva. Jak jsem zjistil, na univerzálních kartách se s výhodou používají moderní čipy určené i do PC CARD (cardbus) karet. Tyto čipy pracují jen s 3,3V napájením a na svých vstupech jsou pak tolerantní k 5V úrovni. Jak se ukázalo, použité
čipy
nejsou
problémem,
problém
tvoří
nevhodný návrh desky plošných spojů. Už u slotů na vývojové desce je důrazné
varování
upozorňující
na
viz
nutnost
obrázek nahlédnout
4.1, do
Obrázek 4.1: Varování na vývojové desce
manuálu. V příloze B manuálu [34] – PCI Compatibility – je celý problém objasněn. Piny A16, A59, B19 a B59 v PCI konektoru jsou použity pro napájení I/O obvodů (nazvěme je V I/O) a tím v podstatě určovat úrovně na datových pinech. V 5V konektoru je na tyto piny přivedeno napětí 5V a očekává se, že na datových pinech bude úroveň log. 1 reprezentována opět 5V. U 3,3V PCI je analogicky všude 3,3V. Jádrem celého problému je, že u vývojové desky Lite5200B jsou tyto napájecí piny V I/O přímo napojeny na zdroj 3,3V. Pokud je špatně navržená univerzální PCI karta, která spojuje 5V piny s V I/O piny, dojde ke zkratu mezi 5V a 3,3V napájecími obvody a následnému nevratnému poškození určitých obvodů vývojové desky. Pokud by návrháři PCI karet vedli v patrnosti rozdílnost normálních napájecích pinů s 5V a napájecích pinů V I/O, které mohou být jak na 5V tak 3,3V, určitě by je mezi sebou nezkratovávali. Bohužel praxe je jiná. U starších PCI adaptérů určených jen do 5V slotů je spojení obou druhů pinů (5V napájení a V I/O) pochopitelné, dojde k rozložení proudové zátěže jednotlivých pinů. Bohužel při návrhu univerzálních PCI karet vycházeli ze starých plošných spojů a danou problematiku rozdílnosti napětí na V I/O pinech neuvažovali. Při zkoumání problematiky kompatibility PCI revizí jsem narazil na nesoulad informací o V I/O pinech. Dle mých zjištění nejsou v PCI konektoru čtyři V I/O piny ale je jich pět. - 27 -
V manuálu k LITE5200B je kompletní zapojení PCI konektoru viz. Tabulka 4.1. Kde piny A jsou na zadní straně PCI karty a piny B na přední straně – straně osazených součástek. Piny 50 a 51 odpovídají 5V klíči a tudíž jsou na univerzálních PCI kartách nahrazeny zářezem. Porovnáním s popisem zapojení PCI konektoru nalezeným na WWW [51], jsem našel následující shody a nesrovnalosti. Pro lepší orientaci jsou uzemněné piny označeny šedě. Modře označené jsou 5V napájecí piny, které jsou na tomto napětí ve všech zapojeních. Jsou i logicky uspořádány, a proto jsou určeny pro základní napájení 5V částí přídavných karet. V našem případě budou sloužit k distribuci 5V napájení do USB konektorů. Zeleně označené piny na stranách A i B jsou 3,3V napájení. V manuálu k vývojové desce jsou sice piny na straně A označeny jako napájení 3,3V I/O, ale v našem kontextu se jedná o zavádějící označení, neboť nemají nic společného s V I/O. Jsou to piny ve všech specifikacích připojené k 3,3V napětí.
Červeně jsou označeny problémové piny V I/O, které jsou na vývojové desce – v 3,3V PCI slotu na napětí 3,3V a v 5V slotu na 5V. V manuálu je upozorňováno jen na piny A16, A59, B19 a B59. Upozornění na pin A10 chybí. Celkově je tedy nutné sledovat těchto 5 pinů: A10, A16, A59, B19 a B59. Posledním označeným pinem je A14, ten
PIN A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14 A15 A16 A17 A18 A19 A20 A21 A22 A23 A24 A25 A26 A27 A28 A29 A30 A31 A32 A33 A34 A35 A36 A37 A38 A39 A40 A41 A42 A43 A44 A45 A46 A47 A48 A49 A50 A51 A52 A53 A54 A55 A56 A57 A58 A59 A60 A61 A62
PIN_NAME TRST +12V TMS TDI +5V INTA INTC +5V_5 RESERVED3 +3.3V(I/O) RESERVED_4 +3.3V(AUX) RST +3.3V(I/O)_3 GNT GND9 PME AD30 +3.3V(I/O)_7 AD28 AD26 GND10 AD24 IDSEL +3.3V(I/O)_8 AD22 AD20 GND11 AD18 AD16 +3.3V(I/O)_9 FRAME GND12 TRDY GND13 STOP +3.3V(I/O)_10 RESERVED_5 RESERVED_6 GND14 PAR AD15 +3.3V_(I/O)_11 AD13 AD11 GND15 AD09 GND16 GND17 C/BE0 +3.3V(I/O)_12 AD06 AD04 GND18 AD02 AD00 +3.3V(I/O)_4 REQ64 +5V_6 +5V_7
PIN B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11 B12 B13 B14 B15 B16 B17 B18 B19 B20 B21 B22 B23 B24 B25 B26 B27 B28 B29 B30 B31 B32 B33 B34 B35 B36 B37 B38 B39 B40 B41 B42 B43 B44 B45 B46 B47 B48 B49 B50 B51 B52 B53 B54 B55 B56 B57 B58 B59 B60 B61 B62
PIN_NAME -12V TCK GND0 TDO +5V_1 +5V_2 INTB INTD PRSNT1 RESERVED1 PRSNT2 RESERVED_2 GND1 CLK GND2 REQ 3.3V(I/O)_1 AD31 AD29 GND19 AD27 AD25 3.3V_1 C/BE3 AD23 GND20 AD21 AD19 3.3V_2 AD17 C/BE2 GND3 IRDY 3.3V_3 DEVSEL GND4 LOCK PERR 3.3V_4 SERR 3.3V_5 C/BE1 AD14 GND5 AD12 AD10 M66EN GND6 GND7 AD08 AD07 3.3V_6 AD05 AD03 GND8 AD01 3.3V_(I/O)_2 ACK64 +5V_3 +5V_4
Tabulka 4.1: Lite5200B PCI konektor
je opět připojen na 3,3V. V 5V slotu je však označen jako „Reserved VDC“. Je tak
- 28 -
pravděpodobné, že bude na 5V kartách nezapojen. Pro jistotu bychom jej však také měli podrobit kontrole, zda není zkratován na 5V.
- 29 -
4.3 PCI USB adaptéry Při vývoji jsem proto zakoupil či prozkoumal několik PCI USB adaptérů různých výrobců. Samozřejmě se jednalo jen o univerzální adaptéry se dvěma zářezy. Momentálně se na trhu ve větší míře vyskytují karty založené na pouhých dvou chipech. Jsou jimi VIA VT6212 a NEC D720101. Jen velmi malou část trhu obsazují jiné čipy, většinou se navíc jedná jen o 5V PCI karty.
4.3.1 OHCI versus UHCI VIA VT6212 je moderní 3,3V chip s dvěmi UHCI kontroléry a jedním EHCI. UHCI kontroléry obsluhují zařízení pracující na 1,5 a 12 Mbit/s, EHCI kontrolér obsluhuje zařízení standartu USB 2.0 pracující na 480 Mbit/s. NEC D720101 je prakticky obdobný čip, jen USB 1.1 zařízení obsluhují OHCI kontroléry. K těmto čipům můžeme připojit 4 až 5 USB portů tak, že EHCI kontrolér obsluhuje zařízení na libovolném portu, kdyžto UHCI či OHCI kontroléry obsluhují každý jen přesně definovanou polovinu portů. Názorně to vidíme na blokovém schématu NEC chipu viz. obrázek 4.2. Rozdíly mezi OHCI a UHCI jsou vcelku značné. UHCI jsou mnohem jednodušší, část nutné práce se přesouvá do
ovladače,
který
s kontrolérem
komunikuje přes relativně velmi malý prostor PCI I/O adres. OHCI naproti tomu většinu práce provádí přímo v kontroléru, s ovladačem pak kontrolér komunikuje prostřednictvím pár kilo paměti – PCI paměťový prostor adres. Ze
samotné
podstaty,
kdy
chceme malé embedded zařízení plyne,
Obrázek 4.2: Blokové schéma NEC D720101
že komunikační zátěž bychom raději přesunuli do kontroléru než do ovladače. Výkon procesoru je omezený a budeme potřebovat na užitečnější práci.
- 30 -
4.3.2 KOUWELL 2580E 4xUSB, VIA Tuto kartu jsem koupil jako první, je postavena na VIA VT6212L a obsahuje dva UHCI kontroléry (a jeden EHCI) viz. obrázek 4.3.
Obrázek 4.3: Kouwell 2580E Při kontrole návrhu karty jsem zjistil, že veškeré V I/O piny (i A14) jsou nezapojeny. Via chip dokonce ani není napájen ze zdrojů 3,3V v PCI konektoru. Používá k tomu 5V piny na konci desky spolu s 3,3V stabilizátorem (umístěn vpravo dole). Detail zapojení PCI konektoru s vyznačením problematických pinů si můžeme prohlédnout na obrázku 4.4 a 4.5. Kartu bylo možno bez problémů použít v 3,3V PCI slotu.
- 31 -
Obrázek 4.4: Kouwell 2580E – PCI konektor strana A
Obrázek 4.5: Kouwell 2580E – PCI konektor strana B Problémy přineslo teprve její použití v našem softwarovém prostředí. Při inicializaci ovladače nedocházelo k přiřazení IRQ prostředku. Tento problém se mi podařil vyřešit přepsáním kusu kódu linuxového jádra viz. sekce 4.4. Po vyřešení problému, komunikace s touto kartou stále neprobíhala ideálně. Ovladač UHCI kartu nalezl a správně nastavil, po připojení kamer došlo k jejich korektní detekci. Při
- 32 -
pokusu o komunikaci s USB zařízením byla komunikace ukončena s chybou a nebylo možné tato zařízení dále obsluhovat. Jak se později ukázalo, problém nastává při komunikaci prostřednictvím I/O adres. Tento problém, který je někde v použitém jádru linuxu (verze 2.6.12) či UHCI ovladači (verze 2.2), se nepodařilo vyřešit. Řešením bylo použití jiné PCI USB karty. Pro neřešitelný problém s UHCI ovladačem jsem dále hledal pouze PCI USB adaptéry s OHCI jádry, neboli ty s NEC chipem.
4.3.3 KOUWELL 2580N4 5xUSB, NEC Další karta, která se mi dostala do rukou byla od stejného výrobce, avšak s NEC chipem viz. obrázek 4.6. Bohužel se jedná o dokonalý příklad PCI karty neodpovídající specifikacím PCI. Už na první pohled je patrné, že by tato karta poškodila naši vývojovou desku viz. obrázky 4.7 a 4.8.
Obrázek 4.6: Kouwell 2580N4
- 33 -
Piny A10, A16 a A59 (V I/O) jsou přímo spojeny s nedalekými piny A8, A61, A62 (5V). Obdobně na straně B je jasně vidět spojení pinů B59 (V I/O) s B61, B62 (5V). Pro naše potřeby je tedy tento adaptér nepoužitelný.
Obrázek 4.7: Kouwell 2580N4 – PCI konektor strana A
Obrázek 4.8: Kouwell 2580N4 – PCI konektor strana B
4.3.4 ST-LAB U-143 5xUSB, NEC Další kartou s NEC chipem, která se mi dostala do rukou, byla U-143 od dalšího velkého prodejce v naší republice. Od ST-LABu se vyskytují i varianty se 3 USB porty a trochu starší model této 5-ti portové – U-142. Je velice pravděpodobné, že i ostatní návrhy budou, co do zapojení PCI konektoru, obdobné. Při kontrole V I/O pinů jsem objevil kombinaci správného i špatného zapojení. Piny A59 a B59 nebyly
Obrázek 4.9: ST-LAB U-143
spojeny s 5V, ale vedly na Vdd_PCI piny NEC chipu. Takto by měla být správně zapojena karta, kdy použitý chip ví, na kterých napětích funguje PCI rozhraní (NEC D720101 je nativně 3,3V chip s 5V tolerant vstupy).
- 34 -
Bohužel byly velmi viditelně spojeny piny A8 (5V) s A10 a A16 (V I/O). I tato karta je tedy pro nás nepoužitelná.
4.3.5 SoNNeT Allegro USB 2.0 5xUSB, NEC Poslední kartou, která vyřešila veškeré problémy, byla karta od výrobce SoNNeT Technologies. Tato firma vyrábí komponenty primárně pro počítače APPLE. U USB adaptéru není, vzhledem k použitému
čipu NEC D720101, problém s kompatibilitou i s windows a linuxem. Výrobce zde zcela vynechal
většinu
nepotřebných pinů a nechal jen ty potřebné viz. obrázek 4.10. Veškeré V I/O piny jsou zde nezapojeny a karta bez problémů lze použít i v naší vývojové desce (či
Obrázek 4.10: SoNNeT Allegro USB 2.0
jiném 3,3V PCI slotu). S touto kartou jsem rozšířil potřebný počet USB portů pro připojení kamer.
- 35 -
4.4 IRQ routovací tabulka Při připojení USB adaptéru s VIA chipem se ukázalo, že linuxové jádro není schopno přiřadit jednotlivým PCI zařízením (jednotlivým UHCI a EHCI kontrolérům) IRQ prostředky. Při pátrání ve zdrojových kódech jádra a cross referencí jader na internetu se ukázalo, že námi používaná verze není ještě ideálně uzpůsobena na verzi LITE5200B, pouze na starší verzi LITE5200. Mezi hlavní rozdíly patří např. dva PCI konektory místo jednoho a další. Proto v jádře nebylo přiřazování IRQ prostředků připraveno na možnost dvou slotů (různá IDSel – v originálním
Lite5200
je
jen
idsel=24).
Stačilo
opravit
arch/ppc/platforms/lite5200.c dle následujícího kusu kódu: #define PCI_IRQ_TABLE_LOOKUP ({ long _ctl_ = -1; if (idsel >= min_idsel && idsel <= max_idsel && pin <= irqs_per_slot) _ctl_ = pci_irq_table[idsel - min_idsel][pin-1]; _ctl_; })
\ \ \ \
#ifdef CONFIG_LITE5200B static int lite5200_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin) { static char pci_irq_table[][4] = /* * PCI IDSEL/INTPIN->INTLINE * A B C D */ { {MPC52xx_IRQ0, MPC52xx_IRQ1, MPC52xx_IRQ2, MPC52xx_IRQ3}, {MPC52xx_IRQ1, MPC52xx_IRQ2, MPC52xx_IRQ3, MPC52xx_IRQ0}, }; const long min_idsel = 24, max_idsel = 25, irqs_per_slot = 4; return PCI_IRQ_TABLE_LOOKUP; } #else /* Original Lite */ static int lite5200_map_irq(struct pci_dev *dev, unsigned char idsel, unsigned char pin) { return (pin == 1) && (idsel==24) ? MPC52xx_IRQ0 : -1; } #endif
- 36 -
kódy
jádra
–
soubor
Další drobný rozdíl ve verzích byl i v úrovni signálu - je aktivní. Opět stačilo upravit ten samý soubor: /* IRQ[0-3] setup */ intr_ctrl = in_be32(&intr->ctrl); intr_ctrl &= ~0x00ff0000; #ifdef CONFIG_LITE5200B /* IRQ[0-3] Level Active Low */ intr_ctrl |= 0x00ff0000; #else /* IRQ0 Level Active Low * IRQ[1-3] Level Active High */ intr_ctrl |= 0x00c00000; #endif out_be32(&intr->ctrl, intr_ctrl); // OLD CODE ! /* IRQ[0-3] setup : IRQ0 - Level Active Low */ /* IRQ[1-3] - Level Active High */ /* intr_ctrl = in_be32(&intr->ctrl); intr_ctrl &= ~0x00ff0000; intr_ctrl |= 0x00c00000; out_be32(&intr->ctrl, intr_ctrl); */
- 37 -
4.5 Mizení PCI zařízení Během odlaďování funkčnosti Kowell USB adaptéru se objevil další zajímavý problém. Občas se po nabootování obrazu neukázalo některé PCI zařízení a to jak ty na naší přídavné kartě, tak i ty integrované na vývojové desce. Pro diagnostiku PCI zařízení byly do výsledného obrazu zakomponovány i nástroje pro výpis a nastavování PCI zařízení. Za jejich pomoci jsem zjistil, že během výpisu prvních bytů konfiguračního prostoru zařízení (obsahuje např. identifikaci výrobce a typu zařízení, IRQ, capabilities a status bity a jiné) se na určitých bytech přečetly samé hodnoty FF. Tyto hodnoty se načtou i při pokusu o čtení z nepřipojeného zařízení. Pokud se tedy takto chybně načtou hodnoty zařízení během bootu, linuxové jádro je oklamáno a myslí si, že tam dané zařízení není. Opět za pomoci cross reference se podařilo nalézt opravu. Část opravy se týkala chyby samotného procesoru MPC5200 (starší verze námi používaného MPC5200B). Ta však nebyla zásadní, hlavním problémem byla chybějící bariérová synchronizace. Po jejím zařazení a zkompilování již konfigurace PCI zařízení probíhala v pořádku. Je možné, že obdobná chybějící synchronizace, je problémem při komunikaci na PCI prostřednictvím I/O. Tuto domněnku jsem dále nezkoumal. Bylo tedy třeba opravit soubor arch/ppc/syslib/mpc52xx_pci.c následujícím způsobem:
- 38 -
static int mpc52xx_pci_read_config(struct pci_bus *bus, unsigned int devfn, int offset, int len, u32 *val) { struct pci_controller *hose = bus->sysdata; u32 value; if (ppc_md.pci_exclude_device) if (ppc_md.pci_exclude_device(bus->number, devfn)) return PCIBIOS_DEVICE_NOT_FOUND; out_be32(hose->cfg_addr, (1 << 31) | ((bus->number - hose->bus_offset) << 16) | (devfn << 8) | (offset & 0xfc)); mb(); if (bus->number != hose->bus_offset) { switch (len) { case 1: value = in_8(((u8 __iomem *)hose->cfg_data) + (offset & 3)); break; case 2: value = in_le16(((u16 __iomem *)hose->cfg_data) + ((offset>>1) & 1)); break; default: value = in_le16((u16 __iomem *)hose->cfg_data) | (in_le16(((u16 __iomem *)hose->cfg_data) + 1) << 16); break; } } else { value = in_le32(hose->cfg_data); if (len != 4) { value >>= ((offset & 0x3) << 3); value &= 0xffffffff >> (32 - (len << 3)); } } *val = value; out_be32(hose->cfg_addr, 0); mb(); return PCIBIOS_SUCCESSFUL; }
- 39 -
nové
původní
static int mpc52xx_pci_write_config(struct pci_bus *bus, unsigned int devfn, int offset, int len, u32 val) { struct pci_controller *hose = bus->sysdata; u32 value, mask; if (ppc_md.pci_exclude_device) if (ppc_md.pci_exclude_device(bus->number, devfn)) return PCIBIOS_DEVICE_NOT_FOUND; out_be32(hose->cfg_addr, (1 << 31) | ((bus->number - hose->bus_offset) << 16) | (devfn << 8) | (offset & 0xfc)); mb(); if (bus->number != hose->bus_offset) { switch (len) { case 1: out_8(((u8 __iomem *)hose->cfg_data) + (offset & 3), val); break; case 2: out_le16(((u16 __iomem *)hose->cfg_data) + ((offset>>1) & 1), val); break; default: out_le16((u16 __iomem *)hose->cfg_data, (u16)val); out_le16(((u16 __iomem *)hose->cfg_data) + 1, (u16)(val>>16)); break; } } else { if (len != 4) { value = in_le32(hose->cfg_data); offset = (offset & 0x3) << 3; mask = (0xffffffff >> (32 - (len << 3))); mask <<= offset; value &= ~mask; val = value | ((val << offset) & mask); } out_le32(hose->cfg_data, val); } mb(); out_be32(hose->cfg_addr, 0); mb(); return PCIBIOS_SUCCESSFUL; }
- 40 -
4.6 Webkamery Nyní již máme kompletně připravený hardware a můžeme k němu připojit kamery. Pro první verzi stereoskopického senzoru použiji dvojici USB kamer Genius VideoCAM NB. Pro jejich lepší kalibraci jim odstraním jejich stojánek a připevním je na společnou základnu umožňující udržet nám jejich vzájemnou polohu. Každé
USB
zařízení
obsahuje
povinnou sadu registrů, v nich jsou kromě základních konfiguračních a stavových informací
dvě
i
umožňující
zásadní
přesně
informace
identifikovat
dané
zařízení. Jsou to USB Vendor ID a
Obrázek 4.11: Genius VideoCAM NB
Product ID. Neboli jsou to identifikace výrobce a produktu daného výrobce. Na internetu jsou celé velké databáze všech USB zařízení (většinou
spravovaných
linuxovou komunitou), a tak není problém přesně zjistit, které zařízení má
člověk v ruce. K přesnému zjištění
můžeme
linuxem
použít
pod utilitu
lsusb, pod windows xp je situace ještě jednodušší. V ovládacích
panelech
otevřeme systém, záložku hardware správce
a
spustíme zařízení.
Vyhledáme a otevřeme sledované
zařízení.
Obrázek 4.12: Dvě webkamery na společné základně
V podrobnostech je i bez nainstalovaného driveru k dispozici hodnota ID instance zařízení. V této hodnotě je část VID_XXXX a PID_YYYY. - 41 -
Zvolené kamery mají USB VendorID = 0c45 a ProdID = 6001. Ze znalosti těchto hodnot již můžeme dohledat více informací. Hlavní hledanou informací zajisté bude podpora daného zařízení v linuxu. Dobrým zdrojem je internetová adresa http://www.qbik.ch/. Zde se dozvíme informace o driveru sn9c1xx. Za pomoci driveru a dalších informací ze zmiňované stránky jsem zjistil, že v kameře je USB chipset SONiX sn9c101 a snímacím čipem je TAS5110C1B 100K Pixels CMOS. Kamera má tedy 100K senzor (100 tisíc snímací bodů). Použitý chipset je nejnižší z dané „rodiny“, a tak umožňuje jen omezené funkce. Přes daný chipset můžeme dostat obraz buď v bayer kódu (prostá posloupnost informací ze snímacích prvků), nebo v komprimované podobě (huffanovo kódování). Při inicializaci se musí jako jedno z nastavení zvolit požadovaný přenosový kód. Jediná další nastavení, která jsou kamery schopné provézt, je nastavení celkového zisku. Kamery s pokročilejším chipsetem sn9c102 umožňují i pokročilejší změny - jako je jednotlivé nastavování zisku pro jednotlivé barevné kanály, regulace jasu a kontrastu a další.
4.7 Uživatelské rozhraní Při celkovém návrhu, jak bude fungovat interakce uživatele s naším embedded zařízením můžeme volit z několika přístupů. Stěžejní otázkou je, kdo bude vykonávat hlavní část práce. Z tohoto pohledu můžeme mít 4 různé stupně. 1) Téměř vše na straně pozorovatele. Na uživatelově počítači poběží pokročilá aplikace, která si bude pouze obrazová data stahovat ze senzoru. Demoaplikace ve formě počítání hloubky tudíž běží také na počítači uživatele. Vzájemná komunikace by probíhala nejlépe přes ethernet, možný je jak nějaký univerzální protokol typu http, ftp apod. tak i nějaký propreitární protokol napsaný přímo pro tuto aplikaci. Možností, ale ne příliš praktickou, by byl přenos dat po sériové lince. Klady: vysoký výkon uživatelova počítače, rychlé odezvy Zápory: nutnost instalace aplikace na počítač a z toho plynoucí nepřenositelnost 2) Většina na straně pozorovatele, ale univerzálně V tomto přístupu bychom opět všechny hlavní úkoly ponechali na počítači uživatele, ale neakceptovali bychom myšlenku samostatné aplikace na uživatelově počítači. Vše by tak zřejmě prováděla aplikace přepsaná do Javy. - 42 -
Klady: vysoký výkon uživatelova počítače Zápory: Nutná transformace do Javy 3) Na straně pozorovatele jen zobrazení Veškeré výpočty budou probíhat přímo v senzoru. K zobrazování výsledků však stále bude třeba pozorovatelův počítač, ale jen v nenáročné formě. Vzhledem ke grafickým výstupům nepřipadá v úvahu posílaní výsledků přes sériovou linku. Ideálně však můžeme využít ethernet a www server. Veškerá data tak budou uživateli předávána ve formě www stránek. Klady: univerzálnost Zápory: pomalé reakce a celkově velké nároky na výkon senzoru 4) Uživatel nic nepotřebuje Posledním možným přístupem je možnost, kdy senzor bude přímo zobrazovat výsledky na nějakém zobrazovači. Možností by byl připojený monitor či přímo integrovaný display. Jak se ukázalo, myšlenka připojení monitoru by nebyla tak snadná. Vývojová deska sice bude hostit linux, je k dispozici volný PCI slot pro grafickou kartu, ale chybí zde jedna zásadní
část – bios. Veškeré inicializace VGA biosu bychom museli udělat sami. Není to zajisté nerealizovatelná možnost, ale v našem případě se do této možnosti nebudeme pouštět. Lákavější možností by bylo připojení menšího displeje přímo na vyvedené univerzální piny procesoru. Pak by zobrazování prováděla námi napsaná aplikace. Po problémech, které jsme měli s přídavnou USB kartou, je ještě další otázka, zda by se dala vůbec sehnat správná PCI VGA karta, jenž by vyhovovala specifikacím v souvislosti se správným zapojení 3,3V I/O pinů. Na trhu je jen velmi omezená nabídka, k dispozici je např.
•
HIS-Excalibur Radeon 9250, 128MB DDR/64b, TVout, DVI, PCI či
•
Matrox Millenium G450 MMS QUAD
Obě jsou dle obrázků univerzální PCI karty, otázkou zůstává zapojení V I/O pinů. Starší PCI VGA karty, kterých je v bazarech dostatek, však nebudou univerzálními PCI, ale jen na 5V. Klady: univerzálnost, vše dělá senzor, rychlé reakce Zápory: nutný rozsáhlý vývoj zobrazovací části a extrémní nároky na výkon procesoru senzoru.
- 43 -
Já jsem zvolil přístup dle třetího bodu. Senzor bude provádět veškeré činnosti a výsledky své práce prezentovat na www stránce. Uživatel se k tomuto senzoru může připojit prostřednictvím internetu odkudkoli ze světa. Samotné připojení k senzoru je realizováno přes ethernetový kabel do integrované síťové karty. Toto řešení zároveň umožní (za využití vytvořených skriptů) napojení stereoskopického senzoru na budoucí aplikace, kde senzor bude využit jen k získání obrazu a zpracování bude probíhat jinde.
4.7.1 Zachycení stereo obrazu Program pro zachycení stereo obrazu pro dané kamery samozřejmě není nikde k dispozici, musím si jej sám napsat. Přesněji - upravím existující ovládací programy takovým způsobem, aby rovnou ovládaly dvě kamery. Samozřejmě by bylo možné dvakrát spouštět ten samý program pro sejmutí obrazu z jedné z kamer, ale to bychom neměli pod kontrolou časové okamžiky sejmutí. Pro naši potřebu je nezbytné, aby si sejmutý pár byl časově co nejbližší. Při pohybu objektu a rozdílných časových okamžicích by zdaleka nemusel stereoskopický algoritmus být schopný produkovat korektní hloubkovou mapu. Pro naše kamery jsem našel 3 různé programy: pro zachycení statického obrázku nebo pro zobrazení live pohledu z kamery [40]. Principiálně v tom není tak velký rozdíl, a tak jde využít s úpravami libovolný z nich. Pro jistotu jsem jejich přesné fungování důkladně zmapoval. Zjednodušeně všechny programy fungují se třemi částmi. V prvé řadě je to inicializace kamer, pak zachycení dat z kamery a poslední částí je interpretace dat a jejich zobrazení či uložení. Interpretace nasnímaných dat závisí na počáteční konfiguraci, pokud je zapnutá komprese musí se napřed sekvence dekódovat dle Huffmanovy dekódovací tabulky. Po té se provede konverze z Bayer do RGB. Pro lepší dojem z obrazu necháme tuto konverzi, přestože by stereoskopickému algoritmu stačil černobílí obraz (odstíny šedi). Pro čistě stereoskopické aplikace bychom zde mohli trochu urychlit výpočty přímou konverzí z bayer do grayscale. Inicializace kamer je ve všech zkoumaných programech prakticky stejná. Přes ioctl() je kamerám poslána konfigurace, zda mají používat kompresy a nastaven globální zisk. Mnohem zajímavější je část zabývající se získáním surových dat z kamer. Byly použity dva přístupy. Jeden je vcelku jednoduchý. Je přečten stream z virtuálního video zařízení (/dev/video0 apod.) o velikosti odpovídající počtu pixelů obrazu. Pokud by nebyl načten správný počet dat, dojde k fragmentaci obrazu.
- 44 -
Druhý přístup je mnohem zajímavější. Naalokují se paměťové buffery a předají se USB subsystému k dispozici pro ukládání streamu. Dotazem je možné zjistit obsazenost bufferů a vyextrahovat z nich tak nasnímaný obraz. Ukládání do bufferů probíhá na pozadí a mi si pouze v požadovaný okamžik překopírujeme aktuální data. Tento přístup zkusíme použít v senzoru. Jak bylo zmíněno, napřed se musí kamery inicializovat a přiřadit jim buffery. Jejich naplnění, než můžeme sejmout první obraz, také určitou dobu trvá, a tak spouštění pro sejmutí každého obrazu, je nepraktické. Zvolím řešení trvale běžícího programu, který na pokyn uloží nasnímaný pár. Takovýmto signálem bude např. uživatelský signál SIGUSR1 procesu. Pokud budeme chtít zachytit obraz, vyvoláme na www stránce skript, který pošle signál našemu programu a ten uloží získané obrazy.
4.7.2 Ovládání zesílení kamer Během zobrazování stereo obrazu potřebujeme přizpůsobovat jas obrazů. U námi použitých kamer je jediným prostředkem nastavení celkového zesílení čipů. Samozřejmě by bylo realizovatelné vytvořit automatickou regulaci. Nejspíše založenou na histogramu. Automaticky bychom regulovali zisk tak, aby histogram měl své těžiště co nejblíže středu tj. zhruba rovnoměrné zastoupení všech intenzit. Daná myšlenka by nebyla problémem, ale v našem případě chceme co nejméně zatěžovat stereoskopický senzor nepotřebnými činnostmi a věnovat všechen jeho výkon na stereoskopický algoritmus. Proto zvolíme jednodušší variantu, kdy regulaci bude ovládat uživatel. Potřebujeme tedy mechanizmus komunikace s grabovacím programem. Použijeme proto obdobný způsob jako v předchozím případě. Mezičlánkem bude soubor na disku. Skript modifikuje obsah souboru a teprve pak pošle signál (SIGUSR2) grabovacímu programu. V této základní verzi bude ve zmiňovaném souboru jen hodnota zesílení, která se má nastavit. V budoucích pokročilejších verzích by nebyl problém do tohoto souboru ukládat celé povely (např. na nastavení zisku jednotlivých rgb složek) a signálem jen signalizovat nutnost načtení těchto příkazů (naše kamery umí jen toto jedno nastavení a tak není třeba zpracovávat příkazy). Pokud bychom v budoucnu měnili kamery a tedy i zachytávací program, je pro minimální nutné úpravy zbylých částí naprogramovat následující prvky. Existuje jen jeden grabovací program pro obě kamery. Po svém spuštění uloží do souboru své PID (aby ho skript snadno mohl načíst a nebyl závislý na jménu grabovacího programu). Při příchodu signálu SIGUSR1 zachytí obrazy. Při příchodu SIGUSR2 načte soubor gain.txt a upraví dle něj nastavení kamer.
- 45 -
4.7.3 Zachycení stereo obrazu – webcam.html Jak bylo výše popsáno, je třeba pro každé načtení obrazu volat skript, který pošle signál SIGUSR1 grabovacímu procesu. Při zobrazování obraz z kamer budeme chtít pochopitelně co nejrychlejší obnovování obrazu. Z těchto důvodů budeme celé ovládání obnovování řídit v html stránce za pomoci JavaScriptu. Obnovování bychom mohli volat nějakou formou časování – volání funkce v pevných
časových intervalech. Problémem zde je, že nevíme, jak výkonný je přenos dat a reakce stereoskopického senzoru a tedy jaký časový úsek nastavit. Ideálně bychom samozřejmě chtěli obnovovací frekvenci někde na 15 snímcích za sekundu. To vzhledem ke všem latencím nebude možné. Potřebujeme nějaký způsob, který nám zajistí, co nejvyšší obnovovací frekvenci. Základem tedy bude využití události OnLoad. Zaregistrujeme si obsluhu této události u obrázku na naší proceduru, ta pak bude volána kdykoli je dokončeno načítání obrázku. Vzhledem k tomu, že máme stereo obraz, je nutné řešit problém načítání dvou obrazů. Problém vyřešíme jednoduše, budeme se spoléhat na posloupnost načítání. Také zavedeme obdobu double bufferingu. V JavaScriptu vytvoříme dva nové obrázky, do nich necháme načítat data. Po jejich načtení je teprve zobrazíme a necháme je opět načítat. Abychom zajistili, že každé volání způsobí nové načtení, je třeba používat unikátní odkazy. To provedeme přidáním do odkazu unikátní hodnotu. Ideálním kandidátem je čas vyjádřený v milisekundách. Získáme jej voláním: var unique = new Date(); newOdkaz = "cgi-bin/skript.cgi?time=" + unique.getTime();
Problém se dále komplikuje tím, že graber ukládá obrazy v PPM formátu (pro stereoskopický algoritmus), ale ve www prohlížeči jej nezobrazíme. Prohlížeče podporují v základu jen BMP, JPG a PNG. Musíme tedy ještě volat konverzi mezi PPM a BMP (nejbližší podobný formát, tak aby konverze nebyla příliš složitá a časově náročná). Celkově tedy zobrazování bude odpovídat schématu na obrázku 4.13. Z uvedeného schéma je patrné, že na stránce probíhá volání grabovacího skriptu, nikde však nebylo uvedeno, že se bude načítat nová stránka. Je to proto, že toto volání budeme provádět na pozadí, neboli asynchronně, za pomoci technologií AJAX viz. další kapitola. Skript v této podobě je navržen tak, že umožňuje běh v co nejrychlejších smyčkách. Pokud by server dokázal odpovídat velmi rychle nebo v případě nějaké chyby docházelo by k velmi intenzivní komunikaci. Pro její omezení integrujeme ještě bezpečnostní pojistku. V libovolné části skriptu html stránky uděláme test, zda rozdíl nově získaného času je od
- 46 -
minulého průchodu větší než daná konstanta. Pokud ne, nebudeme ve skriptu pokračovat, jen nastavíme timeout, který po uplynutí času znovu vyvolá daný skript. Čas je udáván v milisekundách, a tak můžeme bezpečným způsobem regulovat maximální obnovovací frekvenci. Při nastavení konstanty na 100ms dostáváme maximální obnovovací frekvenci 10 snímků za sekundu. Skutečná obnovovací rychlost bude samozřejmě hlavně závislá na rychlosti stereoskopického senzoru – na rychlostech přenosu dat z kamer a jejich konverze do BMP.
Obrázek 4.13: Schéma zachytávání obrazu
4.7.4 Ovládání zesílení kamer – html Jak bylo dříve zmíněno potřebujeme volat skript, který modifikuje hodnotu zesílení v souboru na file systému a poté vyšle signál SIGUSR2 grabovacímu programu. Veškeré tyto změny nemusí mít projev v html stránce. Proto s výhodou využijeme moderní webové technologie a použijeme AJAX. Jedná se o asynchronně vyslaný požadavek na www server. Pro složitější projekty na bázi AJAXu se využívají AJAXové toolkity. Toto odvětví webových technologií zažívá bouřlivý vývoj a toolkit, který byl vynikající před půl rokem, je nyní v zapomnění. Pro naše potřeby vystačíme s jen základními principy AJAXu, a tak žádný toolkit nepotřebujeme. Veškerá volání si napíšeme sami.
- 47 -
Konkrétně je schéma činnosti následující: Vytvoříme nový XMLHttpRequest, zaregistrujeme si funkci, která bude obsluhovat změnu stavu tohoto objektu. Nastavíme adresu skriptu, který obslouží daný požadavek. Vytvoříme text požadavku a zavoláme funkci pro odeslání. Ve funkci pro obsluhu testujeme stav objektu. Pokud je dotaz dokončen, můžeme se věnovat zpracování odpovědi. Konkrétní aplikace zde uvedených na naše potřeby bude např. následující. Budeme mít ovládací tlačítka pro zvýšení a snížení zisku. Kliknutí na tlačítko vyvolá JavaScriptovou funkci, která vytvoří a odešle XMLHttpRequest, který bude obsahovat údaj o použitém tlačítku. Skript na serveru načte aktuální hodnotu zesílení, dle předané informace jej patřičně upraví, vyšle signál SIGUSR2 grabovacímu programu a aktuální hodnotu zesílení vrátí jako odpověď. Po dokončení požadavku pak můžeme snadno vrácenou aktuální hodnotu zesílení zobrazit uživateli.
4.7.5 Zamezení použití cache Hned během prvních pokusů se zobrazováním obrazu z kamer ve webovém prohlížeči se ukázal jeden z problémů. Vzhledem k unikátnosti dotazů je každé načtení znovu a znovu ukládáno do vyrovnávací diskové cache. Využívání BMP formátu znamená na každé načtení stereo obrazu uložení cca 600 KB dat na disk. Pokud bychom dosahovali obnovovací frekvence 15 snímků za sekundu, byl by to tok 9 MB za sekundu (1 GB dat za 2 minuty). To je nepříjemné vytěžování disku, které způsobí i pomalejší reakce systému. Je také třeba si uvědomit, že většina lidí o této diskové cache ani neví. Mají ji pak nastavenou dle počáteční instalace. Bohužel v tomto směru používané webové prohlížeče nepřistupují k využívání disku příliš přívětivě. V základním nastavení mají např. nastaveno, že disková cache může zabírat 10 % z celkové kapacity disku. Při dnešních běžných velikostech disků kolem 160 GB to znamená možnost uložení až 16 GB zbytečných dat. Bylo tedy nutné řešit tuto problematiku. V HTML je definována možnost řízení používání cache. Jedná se o META tagy v hlavičce HTML dokumentu. Pro zamezení ukládání je tak vhodné přidat následující tagy: <meta <meta <meta <meta
http-equiv="Pragma" content="no-cache"> http-equiv="Cache-control" content="max-age=0, pre-check=0, post-check=0"> http-equiv="Cache-control" content="no-cache, no-store, must-revalidate"> http-equiv="Expires" content="-1">
Bohužel tento snadný způsob není řešením našeho problému. Řízení cache se vztahuje jen na stránku, kde jsou uvedeny a nikoli na jednotlivé další součásti této stránky (na vložené obrázky), což je dosti nepochopitelné. Pokud definuji, že se stránka nemá uložit do cache, pak - 48 -
asi nechci, aby se ukládaly i její obrázky. Nutné je tedy řízení cache pro každou součást. To je možné za pomoci HTTP hlaviček. Tyto hlavičky jsou velmi podobné. Posílá je www server před samotným obsahem. Odpověď www serveru na zaslání obrázku tedy obsahuje údaj o tom, že obsahem je obrázek v daném formátu, další http hlavičky, prázdnou řádku pro oddělení hlavičky od dat a pak už přímo samotné binární data obrázku. Máme tedy možnost řízení cache tím, že modifikujeme www server, aby vkládal potřebné http hlavičky do všech odpovědí. Námi používaný server je jen velmi jednoduchý a znamenalo by to nejspíše modifikovat zdrojové kódy. Další mnohem snadnější možností je využití skriptu. Napíšeme si vlastní skript, který pošle všechny potřebné hlavičky a pak potřebná data obrázku. Všechny stahování obrázků, co jsme popisovali v sekci o zachycení obrazu jsou tak ve skutečnosti voláními skriptu pro správné poslání obrázku (s parametrem udávajícím jméno daného obrázku).
4.7.6 Hloubková mapa - html Mód hloubkové mapy se už od doposud zmíněných postupů nijak neodlišuje. Stejným způsobem zde budeme mít zobrazení stereo obrazu (po úpravě – rektifikaci). Navíc je jen volání dalšího skriptu, který vytvoří hloubkovou mapu. Po jeho dokončení samozřejmě následuje načtení vytvořeného obrázku. Na této stránce bude také vizuálně znázorněna hloubka v obrazu. Zobrazíme tedy pruh všech odstínů a k němu příslušné hloubky. Umístění jednotlivých hloubek není statické, zaleží na kalibraci kamer. Pro daný typ kamer by mělo být konstantní a nutnost změny tedy připadá v úvahu jen při výměně kamer, což je větší zásah do celého systému. Pro univerzálnost je umístění jednotlivých údajů o hloubce přímo počítáno v HTML stránce za pomoci JavaScriptu. Jsou definovány potřebné konstanty a po načtení stránky je ve funkci vypočítána správná poloha. Aby zpočátku hodnoty nerušily dojem na stránce, jsou v úvodu neviditelné. Teprve po správném umístění je zviditelníme. Převod obrazu v PGM formátu, který produkuje stereoskopický algoritmus, spojíme s jeho analýzou a případnými úpravami. Do samostatného souboru se uloží informace o nejbližším detekovaném předmětu. Tyto informace si po načtení hloubkové mapy zjistíme jednoduchým skriptem, odesílající jen obsah daného souboru. Obdobným způsobem jako jsme získali výpočet poloh informací o hloubce, vyhodnotíme informace o nejbližším předmětu a informace zobrazíme uživateli. Na stránce bude také možné spustit kalibraci kamer. - 49 -
4.7.7 Kalibrace kamer - html Pro kalibraci kamer je nutné podržet před kamerami testovací obrazec (šachovnice). Je nutná, aby byla vidět v obou kamerách celá. Z tohoto důvodu je systém kalibrace rozdělen na dva kroky. Napřed je uživateli předložena stránka obdobná s webcam.html, kde vidí obraz z kamer a může si v klidu nastavit polohu testovacího obrázku. Teprve až je připraven, spustí fyzické provedení kalibračního procesu. Tento proces spočívá ve vyvolání kalibračního programu pracující s posledními nasnímanými obrazy. Po dokončení kalibrace jsou zobrazeny detekované vnitřní rohy šachovnice testovacího obrazce a výsledky kalibrace.
- 50 -
4.8 Stereoskopický algoritmus Jak bylo zmíněno v teoretické části, můžeme s výhodou použít StereoMatcher [43], který implementuje hned několik algoritmů, které můžeme vybírat jen vhodnou konfigurací. Celý balík byl proto portovám prakticky beze změn. Pouze byly připraveny správné konfigurační skripty pro jeho běh. Tento přístup na druhou stranu znamená nutnost načtení a parsování konfigurace s každým během algoritmu (vzhledem k délce běhu je ale zanedbatelná). Tím, že konfigurace je řízena jen textovým souborem, může uživatel jednoduše měnit parametry i během běhu stereoskopického algoritmu. Stačí se jen interaktivně přihlásit. K dispozici je buď připojení přes sériovou konzolu nebo přes integrovaný SSH server. Po připojení stačí přejít do adresáře stereoskopického algoritmu a integrovaným editorem vi modifikovat soubor s parametry. Změny se projeví hned v následujícím běhu. Pro kontrolu jsou všechny použité parametry uloženy v souboru groundtruth.txt přístupnému i na www serveru. Význam jednotlivých parametrů je popsán přímo ve zdrojových souborech (StereoParametrs.h a StereoParametrs.cpp) nebo v detailní zprávě autorů softwaru [1].
- 51 -
5 Testování 5.1 Stereo webcam Po zprovoznění live stereo webcam se projevil výrazný nedostatek. Obraz byl o cca pět až šest vteřin zpožděný. Veškeré události před kamerami se prostě zobrazovaly s velkým zpožděním, obraz nevykazoval žádné větší trhání (ve stylu dvě vteřiny funguje v pořádku a pak je vteřinu pauza). Celkově snímková frekvence nebyla moc velká. Dařilo se zobrazovat jen něco přes jeden snímek za vteřinu. Diagnostikou se mi podařilo zjistit, že menší část pomalosti zpracování připadá na grabber a větší na konverzi mezi PPM a BMP. Bylo tedy nutné tuto konverzi přepracovat. Rozdílů mezi PPM a BMP je několik, krom různých záhlaví je hlavním rozdílem pořadí řádek. Je tedy nutné prohodit jejich pořadí. Dalším rozdílem je i pořadí RGB složek. Původní program pro konverzi [46] rozdělil vstupní PPM soubor na jednotlivé RGB složky (pole integerů) Poté po jednotlivých buňkách data přeuspořádat a nakonec jednotlivé složky zpět složil do nového souboru BMP. Provedl jsem proto sadu úprav tak, aby program pracoval s typem unsigned char místo int, a aby nepřesouval jednotlivé buňky, ale celé řádky ve složkách RBG. Rozkládání a skládání na složky jsem musel bohužel ponechat. Úpravou konverzního programu se snímková frekvence upravila na dva až tři snímky za sekundu, což je výrazně lepší výsledek. Problém s velkou latencí má původ již v programu pro zachycení snímků a samotném USB subsystému. V programu je naalokována vyrovnávací paměť o velikosti čtyř snímků, což určitě tvoří část latence, ale neměla by být tak velká. Změnil jsem proto grabovací program tak, aby nealokoval žádnou paměť, ale použil přístup s přímím čtením z virtuálního souboru video zařízení (/dev/video). Při tomto druhém postupu získávání obrazu se snímková frekvence nezměnila, ale latence se výrazně vylepšila. Zpoždění vůči realitě činí jen něco kolem dvou vteřin.
Řízení zesílení kamer funguje spolehlivě a rychle. Změny se projeví také po cca 2 sekundách. Neboli změna zisku je okamžitá a veškeré latence způsobuje jen graber a celkově vyrovnávací paměti v USB subsystému.
- 52 -
5.2 Výkon hloubkové mapy Výkon stereoskopického algoritmu je silně závislý na jeho konfiguraci. Hlavně na velikosti vytvářeného disparitního prostoru. Jako základní nastavení jsem zvolil disparitu od 0 do 50 s krokem 2 pixely. Vlivem rozmazání vstupních obrazů by krok 2 neměl mít tak špatné dopady na kvalitu. Krok po jednom pixelu by byl v souvislosti s přesností lepší, ale čas potřebný na výpočet dvojnásobný. Máme tedy celkem 25 disparitních hladin. Maximální prohledávaná disparita nám určuje i minimální hloubku, kterou je algoritmus schopen správně identifikovat. Jakýkoli objekt blíže než tato vzdálenost způsobí výrazné poškození výsledků. Při testovacím nastavení je minimální vzdálenost cca 1,5m. Výpočet takto rozsáhlého disparitního prostoru zabírá na cílové platformě cca pět vteřin.
5.3 Kvalita hloubkové mapy Kvalita výsledků stereoskopického algoritmu je silně závislá na kvalitě nasnímaných obrazů. Zde se ukázala volba kamer jako velmi nešťastná. Pro budoucí použití je velmi žádoucí je vyměnit za některé jiné. Kamery vykazují několik zásadních problémů. Mezi hlavní patří kvalita zpracování objektivu. Ten je tvořen jen plastovým otočným kolečkem. To je v některých polohách velmi volné a poměrně snadno dochází k jeho pootočení. Při ostření se také projevuje výrazný posuv obrazu v závislosti na úhlu natočení. Je tak patrné, že objektiv nepromítá snímaný obraz na střed snímacího čipu. Do budoucna by bylo lepší mít kamery s velmi precizním objektivem. Zajímavou možností by byly webkamery s automatickým ostřením, které se již začínají objevovat na trhu, v případě ostření programově řiditelného. Mohli bychom snadno nastavit dané zaostření a vnitřní mechanika ostření by nám zaručovala minimální změny při letmém dotyku s objektivem. Propustnost USB 1.1 rozhraní nebyla omezujícím faktorem. Samozřejmě že v webcam módu by bylo lepší, rychlejší rozhraní a posílaní obrazu přímo v JPG. Tím bychom sice získali výrazně rychlejší zobrazování stereo obrazu, ale pro výpočet hloubky bychom museli napřed dekódovat JPG soubor (nehledě na to, že JPG je ztrátová komprese). Jako druhou zásadní negativní vlastnost použitých kamer bych zařadil kvalitu snímacího
čipu. Samotné rozlišení není až takový problém jako míra produkovaného šumu, barevné podání a citlivost na osvětlení. Všechny tyto jmenované „neduhy“ se silně projevují na kvalitě sterea. Proto by pro budoucí výběr kamer měly být stěžejní. Kamery produkují velkou míru šumu při malém osvětlení, naopak pokud trochu zasvítí slunce, produkují velké množství přepalů, kdy jsou celé velké plochy obrazu na maximální
- 53 -
hodnotě jasu. Regulace zesílení má v tomto směru jen malý vliv. Přepaly vznikají nikoli na plochách osvícených přímým sluncem, stačí jen obyčejné plochy osvícené nepřímo. S osvětlením souvisí jeho úhel. I relativně malá rozteč kamer, kterou používáme, způsobí natolik velký rozdíl úhlů, že některé osvícené povrchy jsou snímaný s velmi rozdílným odstínem. Poté samozřejmě porovnávání pixelů z jednotlivých obrazů stále produkuje příliš velké odchylky a vzdálenost daného povrchu není určena správně. I přes zmíněné problémy jde na výsledcích nasnímaných obrazů nalézt správně určené
části a další znaky správně pracujícího základu stereoskopického algoritmu (pokud bychom tedy měli kvalitnější vstupy, dočkali bychom se kvalitních výsledků). Např. na obrázku 5.1 je záběr z levé a pravé kamery s odpovídající hloubkovou mapou.
Obrázek 5.1: Záběr z kamer a hloubková mapa Jsou zde patrné dveře, skříňky i postava která je nejblíže. Pokud se zaměříme na postavu, je patrný jakoby televizní duch napravo od obličeje a jiné artefakty. Tyto problémy jsou typickým projevem velmi blízkého objektu, kterému by odpovídala větší disparita než největší prohledávaná.
- 54 -
Co se zdá být dobře identifikované je rám dveří, ten má dle obrázku disparitu cca 14. To odpovídá vzdálenosti cca 4,8 m (ve skutečnosti byla vzdálenost cca 4,5 metru) Hloubka na skříňce je v různých bodech velmi odlišná. Pokud v grafickém editoru aplikujeme filtry pro průměrování hodnot dostáváme na hraně skříňky hodnoty disparity kolem 25 až 30. Tyto hodnoty odpovídají vzdálenostem 2,9 m až 2,4 m. Hrana skříňky byla ve skutečnosti vzdálena cca 2,9 metru. Hlava postavy by pak podle hloubkové mapy měla maximální možnou disparitu 48 - odpovídá cca 1,6 metrům. Ve skutečnosti byla vzdálena jen cca 1,2 metru a to potvrzuje domněnku vzniku nepříjemných „duchů“. Na následujícím obrázku 5.2 je velmi názorně vidět vliv šumu kamer. Hodnoty odstínů
černého opěradla židle nejsou plynulým přechodem, a proto dochází k přiřazování trochu
Obrázek 5.2: Obraz opěradla a hloubková mapa odlišných hodnot disparit. Ještě názorněji
můžeme
šum
pozorovat na obrázku 5.3, kde je opěradlo upraveno. V dané oblasti byla použita korekce dle histogramu jeho roztažením na plné spektrum. Tím jde velmi úzké
spektrum
odstínů
původního obrázku od sebe dobře odlišit. Na výsledku tedy vidíme, jak velký šum kamery produkují. Část tohoto šumu je
Obrázek 5.3: Šum produkovaný kamerami
- 55 -
kompenzována přímo ve stereoskopickém algoritmu (prvním krokem je totiž rozmazání). I toto opatření nedokáže plně kompenzovat uvedenou míru šumu. Při změně nastavení stereoskopického algoritmu na použití dynamického programování při prohledávání disparitního prostoru se ve výsledné hloubkové mapě objevuje množství velmi malých chyb. Pro jejich odstranění byl dodatečně integrován průměrující filtr. Velmi snadno jej můžeme integrovat do převodu výsledku stereoskopického algoritmu ve formátu PGM do výsledného formátu BMP. Průměr se počítá z 9 sousedních hodnot. Také jsem do převodu přidal odstranění okrajových hodnot. Na okrajích se vlivem kalibrace a samotného principu sterea produkují neodpovídající hodnoty. Výsledek činnosti filtru je vidět na obrázku 5.4.
Obrázek 5.4: Výsledek průměrujícího filtru
- 56 -
5.4 Výsledky kalibrace kamer Zajímavý a bohužel nevyřešený problém způsobila kalibrace kamer. Jak bylo zmíněno v teoretické části, tvoří ji dva hlavní kroky. Po sejmutí obrazu je to v prvé řadě detekce vnitřních rohů kalibračního obrazce a poté výpočet potřebných parametrů. Při přípravě kalibračních programů na platformě PC vše fungovalo v pořádku. I při velmi špatných světelných podmínkách fungovala detekce rohů téměř dokonale. Při lepších podmínkách nemá problémy. Výpočet kalibračních dat již nebyl problém. Jak
jsem
již
zmínil
kalibrace na finální platformě není bezproblémová.
Funkce
pro
detekci vnitřních rohů šachovnice nefunguje správně. Není schopna jakékoli
detekce
rohů
na
šachovnici, naopak spíš se snaží najít rohy kdekoli jinde. Samotná funkce má několik módů běhu, které se mění za pomoci konstant ve volání. Můžeme tak definovat zda má funkce používat pevný
Obrázek 5.5: Fungující detekce rohů
nebo adaptabilní práh při konverzi do černobílého obrazu, či zda se má před aplikací prahu obraz normalizovat histogramu.
za Také
pomoci samozřejmě
definujeme kolik vnitřních rohů daný
kalibrační
obrazec
(šachovnice) má. V základu byl používaný obrazec s 7x7 vnitřními rohy, po zjištění problémů jsem i zkusil používat menší obrazce, ale to na problémy nemělo vliv.
Obrázek 5.6: Nefungující detekce rohů
Analýzou běhu při různých nastaveních je patrné, že ve funkci je někde chyba, která se jen na platformě x86 neprojevuje. - 57 -
Pokud na cílové platformě spustím detekci rohů s adaptivním prahem trvá neúměrně dlouho a zabírá během běhu přes 33% paměti tj. cca 80MB paměti. To je na uložení obrázku o rozměrech 352x288 pixelů a pomocných výpočtů docela hodně. Pokud je funkce volána tak, aby používala i normalizaci, zabírá během běhu i 77% paměti (200MB). To je již evidentní problém. Také délka běhu je zarážející. Na vývojové platformě detekce rohů je otázkou v řádu sekundy, kdyžto na cílové platformě trvala detekce v obou obrazech kolem minuty a půl. Kde konkrétně je ona chyba se mi nepodařilo zjistit. U portace je možný problém s různou velikostí jednotlivých typů a při nečistých programátorských technikách následný problém s pointrovou aritmetikou více než pravděpodobný. Přestože na vývojové platformě byla používána knihovna OpenCV verze 0.9.9 a na cílové platformě 1.0.0 neměl by být problém v této rozdílnosti. Zdrojový soubor obsahující dané rutiny (cvcalibinit.cpp) je v obou verzích totožný. Pro nalezení chyby by bylo třeba detailní pochopení funkce a přesné trasování a porovnávání obou platforem. Během pokusů s kalibrací na vývojové platformě netrvala kalibrace nijak dlouho. Proto bylo v původním návrhu počítáno s tím, že html stránka bude volat kalibrační skript. Atypický průběh na cílové platformě však otevřel další problém. AJAXový požadavek se dostane do dokončeného stavu dříve než se dokončí kalibrace. Už po cca dvaceti vteřinách nastane vnitřní timeout. Výsledek dotazu je pak prázdný. Ještě horší záležitostí je, že na straně html stránky sice dojde k dokončení dotazu, ale na straně serveru kalibrace probíhá dál. Pokud uživatel přepne hned po nedokončené kalibraci na mód hloubkové mapy, začne stereoskopický algoritmus vytěžovat procesor. Budou tak běžet současně dva náročné programy. Tím se pochopitelně prodlouží doba jejich běhu. Pokud by nastala katastrofická situace, kdy se i doba běhu stereoskopického algoritmu prodlouží natolik, že požadavky vyprší před jeho dokončením mohla by tak nastat situace kdy se budou stále spouštět další a další kopie a množit se i množství spuštěných procesů. Tomuto bylo třeba zabránit. A to tím, že změníme způsob volání kalibrační rutiny. Upravíme samotnou kalibrační rutinu tak, že po spuštění smaže obsah specifického souboru (calibrating.txt). Po svém dokončení do tohoto souboru zapíše výsledky. Průběh kalibrace pak bude takový, že napřed se AJAXovým voláním vyvolá skript, který spustí kalibrační rutinu. Po změně jeho stavu tuto žádost zrušíme a začneme v určitém intervalu volat novou funkci getcalib(). Vzhledem k délce kalibrace můžeme použít klidně sekundové intervaly. V této nové funkci se bude volat jednoduchý skript, který přečte daný textový soubor calibrating.txt a odešle jej zpět. Pokud je výsledek volání prázdný (i soubor je prázdný) víme, že kalibrace ještě není dokončena a musíme dále počkat. Pokud je výsledek neprázdný, máme
- 58 -
dokončenu kalibraci. Zrušíme tak periodické volání této ověřovací funkce a můžeme zjišťovat jak kalibrace dopadla. Abych mohl alespoň trochu testovat kvalitu stereoskopického algoritmu musel jsem převzít kalibrační hodnoty z vývojové platformy do cílové. Hodnota ohniskové vzdálenosti není takový problém, ta zůstává vcelku stabilní. Větší problémy činilo pokud možno neměnit nastavení objektivů.
5.5 Další experimenty Během pokusů s kvalitou stereoskopického algoritmu jsem zkoušel i možnosti nápravy získaných obrazů. Implementoval jsem z těchto důvodů program, který v menším obdélníku obrazu provede seřazení dat a zjistí medián. Pokud předložíme kamerám jednobarevný obraz (homogenní šedivý list papíru), můžeme zjistit zda kamery neprodukují nějaké konstantní zkreslení určité barevné složky. Tato domněnka se nepotvrdila. Další pokusy vedly k redukci šumu. V OpenCV knihovně máme několik možností rozmazání obrazu. Pro dostatečné vyhlazení obrazu je však potřeba přílišný počet iterací, které by produkovaly nepříjemné zdržení. Mnohem efektivnějším způsobem redukce šumu bude výměna kamer za kvalitnější.
- 59 -
6 Závěr Implementoval jsem embedded systém pro pořízení a zpracování stereo obrazu z dvojice USB webkamer. Podařilo se mi odhalit a odstranit několik chyb ve vývojovém prostředí k použité vývojové desce Lite5200B. Tuto desku jsem rozšířil o větší množství USB portů s možností použití i standartu USB 2.0. Tím tak vznikla možnost použití tohoto prostředí i pro další budoucí práce. Základem systému je linux portovaný na PowerPC procesor, který nám umožňuje v budoucnu snadno vyměnit použité webkamery za jiné či jakékoliv další rozšiřování a úpravy systému. V systému jsem implementoval uživatelské rozhraní na bázi html stránek a příslušných obslužných skriptů. Kromě zachycování a zobrazování stereo obrazu jsem integroval demo aplikaci počítající s nasnímaných obrazů hloubkovou mapu a určující tak vzdálenost nejbližšího objektu. Použil jsem existující balík stereoskopických algoritmů, ke kterému jsem doimplementoval kalibraci kamer, rektifikaci obrazu a výpočet vzdáleností. Kvalita dosahovaných výsledků by potřebovala vylepšit. Velkou část zhoršených výsledků má na svědomí použití nejlevnějších nekvalitních webkamer. Po přenesení systému do finální platformy jsem objevil, bohužel však neodstranil, závažnou chybu v OpenCV knihovně, která se na platformě x86 neprojevuje. Do budoucna by bylo třeba zaměnit použité kamery za kvalitnější typ. Kvalitní by měl být hlavně objektiv. Druhou možnou změnou je naopak výměna použitého stereoskopického algoritmu a související kalibrace kamer. Zajímavé by tak mohlo být třeba portování projektu [47], který využívá pokročilejší (a také náročnější) způsob rektifikace obrazu.
- 60 -
7 Seznam literatury a dalších zdrojů [1]
Daniel Scharstein, Richard Szeliski: A Taxonomy and Evaluation of Dense Two-Frame Stereo Correspondence Algorithms Dept. of Math and Computer Science, Middlebury College, Middlebury, VT 05753, Microsoft Research, Microsoft Corporation, Redmond,WA 98052, 2002.
[2]
Andrea Fusiello, Emanuele Trucco, Alessandro Verri: A compact algorithm for rectification of stereo pairs Machine Vision and Applications (2000) 12: pages 16–22.
[3]
Uma Mudenagudi, Subhasis Chaudhuri: Depth Estimation Using Defocused Stereo Image Pairs Department of Electrical Engineering Indian Institute of Technology-Bombay, India, 1999.
[4]
Hai Tao, Harpreet S. Sawhney: Global Matching Criterion and Color Segmentation Based Stereo Sarnoff Corporation, 201 Washington Rd., Princeton, NJ 08543, 2000.
[5]
Steve Vallerand, Masayuki Kanbara, Naokazu Yokoya: Binocular Vision-Based Augmented Reality System with an Increased Registration Depth Using Dynamic Correction of Feature Positions Nara Institute of Science and Technology, 8916-5 Takayama, Ikoma, Nara, Japan, 6300101, 2003.
[6]
Reinhard Koch: 3-D Surface Reconstruction from Stereoscopic Image Sequences Institut fur Theoretische Nachrichtentechnik und Informationsverarbeitung, Universitat Hannover, Appelstr. 9A, 30167 Hannover, Germany, 1995.
[7]
Vladimir T ucakov, Michael Sahota, Don Murray, Alan Mackworth, Jim Little, Stew art Kingdon, Cullen Jennings, Rod Barman: Spinoza A Stereoscopic Visually Guided Mobile Robot Laboratory for Computational Intelligence, Department of Computer Science, University of British Columbia, Vancouver, British Columbia, CANADA V6T 1Z4, 1997.
[8]
Stan Birchfield, Carlo Tomasi: Depth Discontinuities by Pixel-to-Pixel Stereo Department of Computer Science, Stanford University, Stanford, California 94305, 1998.
[9]
Pedro F. Felzenszwalb, Daniel P. Huttenlocher: Efficient Belief Propagation for Early Vision Department of Computer Science, Cornell University, 2004.
[10]
Harlan Hile, Colin Zheng: Stereo Video Processing for Depth Map University of Washington, 2004.
[11]
Šárka Voráčová: Aplikace epipolární geometrie 24. konference o geometrii a počítačové grafice, 2004.
- 61 -
[12]
Andrea Fusiello, Emanuele Trucco, Alessandro Verri: Rectification with Unconstrained Stereo Geometry Department of Computing and Electrical Engineering, Heriot-Watt University, Edinburgh, 1998
[13]
Victor S. Grinberg, Gregg Podnar, M. W. Siegel: Geometry of Binocular Imaging Robotics Institute, School of Computer Science, Carnegie Mellon University, 5000 Forbes Ave., Pittsburgh, PA, 15213, 1994.
[14]
Victor S. Grinberg, Gregg W. Podnar, M. W. Siegel: Geometry of binocular imaging II : The augmented eye Robotics Institute, School of Computer Science, Carnegie Mellon University, 5000 Forbes Ave., Pittsburgh, PA, 15213, 1995.
[15]
Maurizio Pilu: Uncalibrated Stereo Correspondence by Singular Value Decomposition Digital Media Department, HP Laboratories Bristol, HPL-97-96, August, 1997.
[16]
Yanghai Tsin, Sing Bing Kang, Richard Szeliski: Stereo Matching with Linear Superposition of Layers IEEE transactions on pattern analysis and machine intelligence, VOL. 28, NO. 2, FEBRUARY 2006.
[17]
Ralf M. Philipp, Viswabharath Reddy, Ralph Etienne-Cummings, M. Anthony Lewis: ARCHITECTURE FOR AN aVLSI STEREO VISION SYSTEM Dept. of Electrical and Computer Engineering, Johns Hopkins University, Baltimore, MD 21218, USA, 2002.
[18]
Wannes van der Mark, Dariu M. Gavrila: Real-Time Dense Stereo for Intelligent Vehicles IEEE TRANSACTIONS ON INTELLIGENT TRANSPORTATION SYSTEMS, VOL. 7, NO. 1, MARCH 2006.
[19]
Kuk-Jin Yoon, In So Kweon: Adaptive Support-Weight Approach for Correspondence Search IEEE TRANSACTIONS ON PATTERN ANALYSIS AND MACHINE INTELLIGENCE, VOL. 28, NO. 4, APRIL 2006.
[20]
Daniel Oram: Rectification for Any Epipolar Geometry Advanced Interfaces Group, Department of Computer Science, University of Manchester, Mancester, M13, UK, 2001.
[21]
Jan Šochman, Tomáš Pajdla: Matematický model kamery v afinním prostoru Research Reports of CMP, Czech Technical University in Prague, No. 11, 2002.
[22]
Daniel T. Oram: Projective reconstruction and metric models from uncalibrated video sequences Department of Computer Science, The University of Manchester, September 2001
[23]
Rhys Hawkins: Digital Stereo Video: display, compression and transmission The Australian National University, February 2002.
- 62 -
[24]
Zhengyou Zhang: A Flexible New Technique for Camera Calibration Technical Report MSR-TR-98-71, Microsoft Research, Microsoft Corporation, One Microsoft Way, Redmond, WA 98052, 1998 updated 2002.
[25]
Changming Sun: A Fast Stereo Matching Method CSIRO Mathematical and Information Sciences, Locked Bag 17, North Ryde, NSW 2113, Australia, 1997
[26]
Tomáš Pajdla: 33PVI Pocitacove videni pro informatiku Poznamky k prednasce, 2001. http://cmp.felk.cvut.cz/cmp/courses/pvi2003/LectureNotesPVI2003/
[27]
SN9C101 Specification Datasheet, SONIX Technology Co., LTD., 2002.
[28]
SN9C102 Specification Datasheet, SONIX Technology Co., LTD., 2002.
[29]
SN9C103 Specification Datasheet, SONIX Technology Co., LTD., 2002.
[30]
TAS5110C1B Brief, Taiwan Advanced Sensors Corp., Hsin Tai Wu Road, Hsi-Chih, Taipei Hsien, Taiwan, R.O.C.., 2002.
[31]
PD720101 Datasheet, Document No. S16265EJ5V0DS00 (5th edition), NEC Electronics Corporation, Published March 2005
[32]
VT602 Datasheet, VIA technologies, inc., 2002.
[33]
ELinOS Documentation, SYSGO Embedding Innovations
[34]
Lite5200B Documentation, Freescale Semiconductor, Inc http://www.freescale.com/
[35]
MPC5200B Documentation, Freescale Semiconductor, Inc http://www.freescale.com/
[36]
Epipolar rectification http://profs.sci.univr.it/%7Efusiello/rect.html
[37]
Tutorial on Rectification of Stereo Images Andrea Fusiello http://homepages.inf.ed.ac.uk/rbf/CVonline/LOCAL_COPIES/FUSIELLO/tutorial.html
[38]
Computer vision books http://homepages.inf.ed.ac.uk/rbf/CVonline/books.htm
- 63 -
[39]
Computer vision http://cat.middlebury.edu/stereo/code.html http://extra.cmis.csiro.au/IA/changs/stereo/ http://gandalf-library.sourceforge.net/ http://homepages.inf.ed.ac.uk/rbf/CVonline/CVentry.htm http://ltilib.sourceforge.net/doc/homepage/index.shtml http://peipa.essex.ac.uk/info/software.html http://people.cs.uchicago.edu/~pff/bp/ http://people.csail.mit.edu/demirdji/download/index.html http://www.cs.cmu.edu/~cil/vision.html http://www.cs.ucf.edu/~vision/ http://www.cs.umd.edu/users/ogale/download/code.html http://www.fi.muni.cz/~xliska/stereo/ http://www.intel.com/research/mrl/research/opencv/ http://www.netnam.vn/unescocourse/computervision/comp_frm.htm http://www.site.uottawa.ca/~laganier/tutorial/opencv+directshow/cvision.htm
[40]
Ovládací software kamer sn9c102 - http://odie.mcom.fr/~clucas/articles/sn9c102.html sonic-snap - http://stolk.org/sonic-snap/ sn-webcam - http://sn-webcam.sourceforge.net/
[41]
SN9C10x Driver http://www.linux-projects.org/modules/mydownloads/viewcat.php?cid=2
[42]
Sn9C101 http://www.sonix.com.tw/sonix/product.do?p=SN9C101 http://bertrik.sikken.nl/webcam/sn9c101.htm
[43]
Stereo Matcher http://www.middlebury.edu/stereo
[44]
Další software Efficient Belief Propagation for Early Vision - http://people.cs.uchicago.edu/%7Epff/bp/ Estereo - https://sourceforge.net/projects/estereo/ StereoFlowMatlab - http://www.cs.umd.edu/users/ogale/download/code.html
[45]
Camera calibration http://research.microsoft.com/~zhang/Calib http://www.cs.cmu.edu/~rgw/TsaiCode.html
[46]
PPM utils http://people.scs.fsu.edu/~burkardt/cpp_src/cpp_src.html
[47]
Uncalibrated Stereo Vision http://www.cs.wisc.edu/%7Echaol/cs766/cs766.html
- 64 -
[48]
Independent JPEG Group http://www.ijg.org/
[49]
Small JPEG Decoder Library http://www.voicenet.com/~richgel/
[50]
OpenComputerVision library http://opencvlibrary.sourceforge.net/
[51]
PCI connector http://pinouts.ru/Slots/PCI_pinout.shtml
[52]
Výkon procesorů http://homepage.virgin.net/roy.longbottom/dhrystone%20results.htm
[53]
Spotřeba procesoru http://www.cpu-world.com/CPUs/Pentium-III/Intel-Pentium%20III%20550%20%2080525PY550512%20(BX80525U550512).html
- 65 -
Příloha A
Seznam použitých zkratek
Ajax – Asynchronous JavaScript and XML – označení pro webové technologie umožňující načítání dat bez nutnosti opětného načítání nové stránky. BMP – bitmap – obrazový formát, bez komprese. BOOTP – Bootstrap protocol – protokol pro start systému přes síť. DMA– Direct memory access – přímý přístup do paměti umožňující přesuny dat bez účasti procesoru EHCI – Extended Host Controller Interface – kontrolér standartu USB 2.0 FPU – floating point unit – jednotka pro počítání v plovoucí řádové čárce IDCT – inverse discrete cosine transform – inverzní diskrétní kosinová transformace JPEG– Joint Photographic Experts Group – skupina definující metody ztrátové komprese obrazu MIPS – 1 VAX MIPS – výkon procesoru DEC VAX 11/780 MMU – Memory management unit – jednotka procesoru pro obsluhu paměti NFS – Network File Systém – síťový protokol OHCI – Open Host Controller Interface - kontrolér standartu USB 1.1 PGM – Portable Gray Map – obrazový formát PPM – portable pixmap – obrazový formát RLE – Run-length encoding – bezztrátová komprese TFTP – Trivial File Transfer Protocol – jednoduchý protokol pro přenos souborů UHCI – Universal Host Controller Interface – kontrolér standartu USB 1.1 USB – Universal serial bus – univerzální sériová sběrnice USB rev. 1.1 – USB o maximální teoretická rychlosti 12 Mbit/s USB rev. 2.0 – zpětně kompatibilní s USB 1.1, rychlost 480Mbit/s YUV – barevný model
- 66 -
Příloha B
Uživatelská/instalační příručka
Připojení kamer proveďte buď před zapnutím systému nebo v pořadí levá kamera a teprve poté pravá. Levá kamera musí být připojena k USB portu přímo na vývojové desce. Pravá pak musí být připojena k USB portu na přídavném PCI USB řadiči. V u-boot loaderu musí být nastavena následující hodnota:
bootargs=devfs=mount rootfstype=tmpfs root=/dev/ram rw Dále by měly být nastaveny potřebné IP adresy:
ipaddr=192.168.1.100 serverip=192.168.1.1 Předpřipravený obraz přeneste do vývojové desky např. TFTP protokolem příkazem:
tftpboot 9000000 /tftpboot/webcam.img
Číselná hodnota odpovídá adrese kam image nahrát. Vzhledem k velikosti je vhodnější konec paměti RAM (rozsah do A000000). Proveďte start systému:
bootm 9000000 Systém je nakonfigurován na statické nastavení IP adres. Po bootu je tak zařízení přístupné na adrese 192.168.1.100. K systému můžete přistupovat na uvedené adrese přes SSH nebo za pomoci sériové konzole (115200 kbit/s, 8N1, bez řízení toku). Výsledky systém prezentuje ve formě www stránek na výše uvedené adrese. Doporučeným prohlížečem je Mozilla Firefox. Po načtení úvodní stránky již máte k dispozici volbu módu provozu.
- 67 -
Příloha C
Ukázka uživatelského rozhraní
Obrázek C.1: Úvodní stránka
Obrázek C.2: Mód zobrazení stereo obrazu
- 68 -
Obrázek C.3: Mód hloubkové mapy
- 69 -
Příloha D Obsah přiloženého CD CD ├───Diplomka │ ├───Dokumenty │ ├───Elinos │ ├───Lite5200B │ ├───Other_hw │ ├───Stereo │ └───Webcam │ ├───Src │ ├───Grabers │ ├───OpenCV │ ├───ppm │ └───Stereo │ ├───Src_elinos │ Webcam.tar.gz │ └───Src_nepouzite ├───Color_calib ├───Epipolar ├───Others ├───Stereo │ ├───BeliefPropagation │ ├───Daio_java │ ├───Estereo │ ├───OpenCVCamCalib │ ├───Rectification │ ├───Rectification2 │ ├───RectifiMatlab │ └───StereoFlowMatlab └───Webcam
Diplomová práce Získaná dokumentace Vývojový software Vývojová deska Přídavné karty a dalším hw Stereoskopie a kalibrace kamer Dokumentace ke kamerám Využité zdrojové kódy Programy pro ovládání kamer Knihovna pro manipulaci s obrázky a stereoskopii Nástroje pro konverzi obrazových formátů Použitý balík stereoskopických algoritmů Kompletní vývojový direktorář s projektem do ELinOSu viz. dále Zdrojové kódy nevyužitých programů Má implementace detekce barevného podání Má implementace zjištění ep. geometrie a rektifikace Nepoužité stereoskopické algoritmy
- 70 -
Webcam.tar.gz ├───app.rootfs │ ├───etc │ ├───stereo │ ├───webcam │ ├───webcam1 │ ├───webcam_b │ └───www ├───boot ├───feature.rootfs ├───kernel.rootfs ├───libs.binary ├───linux │ ├───arch │ │ ├───ppc │ │ │ ├───platforms │ │ │ ├───syslib │ │ │ │ │ └───src ├───etc ├───passwd ├───webcam │ ├───calibrate │ ├───correct │ ├───grab │ ├───grab1 │ ├───grab_unbuff │ ├───opencv │ ├───pgm2bmp │ ├───ppm2bmp │ └───stereo │ ├───files │ └───StereoMatch └───www
Uživatelská část výsledného file systému Stereo algoritmus Zachycení obrazu, kalibrace, konverze Zachytávání obrazu jen z 1 kamery Zachycení obrazu s vyrovnávací pamětí Html stránky a skripty Výsledný obraz pro vývojovou desku Část výsledného file systému Část výsledného file systému - jádro Crosskompilovaná knihovna OpenCV Symbolické linky na kódy jádra Umístění změněných kódů jádra Umístění změněných kódů jádra Umístění uživatelských zdrojových kódů Konfigurace linuxu Konfigurace linuxu Kódy pro kalibraci kamer Kódy pro rektifikaci obrazu Kód pro zachycení obrazu z kamer Kód pro zachycení obrazu z 1 kamery Kód pro zachycení obrazu z kamer OpenCV knihovna Konverze obrazových formátů Konverze obrazových formátů Stereoskopický algoritmus s konfigurací
Html stránky a obslužné skripty
- 71 -
