2008. tavaszi félév

Sztereó képfeldolgozás mobilrobot­platform tájékozódásához Önálló laboratórium 2007/2008. tavaszi félév

Józsa Csongor Konzulens: Dr. Vajda Ferenc

1/12

1. A probléma ismertetése Mobilis robotok ismeretlen környezetben történő navigációjához szükséges valamilyen eljárás a  környezet feltérképezésére, azaz kell egy módszer, melynek segítségével modellt alkothatunk a robotot  körülvevő objektumok geometriájáról, ami alapján a robot vezérléséről döntéseket hozhatunk.  Ez  a  modellalkotás történhet a környezet letapogatásával, valamilyen aktív eszköz segítségével (pl. SONAR,  LIDAR rendszerek stb.), illetve passzív eszközökkel, azon belül is egykamerás (pl. motion stereo, shape  from shading, shape from texture), vagy többkamerás rendszerek segítségével. Jelen esetben a cél a  sztereó   gépi   látás   megvalósítási   lehetőségeinek   vizsgálata,   illetve   egy   kétkamerás   látórendszer  fejlesztése. A probléma három jól elkülöníthető részre osztható fel, ezek a kamera kalibrációja, a két képen  az   összetertozó   pixelpárok   megkeresése,   illetve   egy   adott   pontnak   a   kamerától   vett   távolságának  kiszámítása, a kamera geometriája, illetve a pontnak a két képsíkra vett vetületének ismeretében. A  kamera kalibrálását Furmann Márton villamosmérnök hallgató végezte, ezért itt csak egy rövid, inkább  elméleti jellegű leírás szerepel.

2. Felhasznált eszközök 2.1 A kamera

fig. 1: Bumblebee sztereó kamera Sztereó képek készítésére a Point Grey Research Inc. Bumblebee [1] modelljét használtuk. Ez  egy kétlencsés kamerarendszer, mellyel másodpercenként 30 színes, 8 bites, 640x480 pixel felbontású  sztereó   kép   készíthető.   A   készülék   IEEE   1394   csatlakozóval   rendelkezik,   a   két   szenzor   egyetlen  virtuális eszközként működik, a szinkronizálást a kamera vezérlő elektronikája automatikusan elvégzi,  azaz a két kameráról garantáltan egy időben készült képet kapunk. A kamerával történő kommunikáció  az IIDC 1394 szabványban foglaltak szerint történhet. Ez egy ipari szabvány, melyet a 1394 Trade  Association adott ki 2000 júniusában és az IEEE 1394­et használó digitális kamerák és PC­k közti  adatátvitel és vezérlés szabványos módját hivatott meghatározni. Többek között definiálja a használt  2/12

képformátumokat,   a   kamerák   működési   módjait,   az   adatátviteli   paramétereket,   illetve   az   ezekhez  tartozó kontrollregiszterek egy halmazát.

2.2 Felhasznált szoftverkomponensek Az általunk készített látórendszer fejlesztése PC­n történik, azonban az elkészült rendszernek  maximális   mértékben   hordozhatónak   kell   lennie,   hogy   a   későbbiekben   beágyazott   platformon,  mikrokontrolleres   környezetben   is   használni   lehessen,   ezért   a   hordozhatóság   az   egyik   elsődleges  szempont volt a felhasználható szoftverelemek kiválasztásánal. Ezt szem előtt tartva a fejlesztést linux  operációs   rendszeren   végeztük.   A   gyártó   egy   elsődlegesen   windows   platformra   írt   keretrendszert  mellékel a termékhez, melynek linuxos verziója csak korlátozott mértékben használható, így a feladatot  nehezíti, hogy egy, a kamera kezelését megvalósító komponenst is el kellett készíteni, melynek során  problémát jelentett, hogy a kameráról csupán minimális jellegű dokumentáció áll rendelkezésre. (Ennek  oka egyrészt a gyártó saját keretrendszerének előtérbe helyezése lehet, másrészt, hogy a kamera már  nincs a támogatott termékek között, a következő generációs Bumblebee2 megjelenése miatt.)

libdc1394

IIDC 1394

video1394 libraw1394

fig. 2: Felhasznált szofterkomponensek A kamera kezeléséhez a libdc1394 függvénykönyvtárat [2] használtuk. Ez a nyílt forráskódú  könyvtár   használható   a   legnépszerűbb   operációs   rendszereken,   segítségével   vezérelhetőek   az   IIDC  szabványnak   megfelelő   digitális   kamerák.   Beállíthatóak   a   kívánt   átviteli   paraméterek,   a   használt  képformátum, valamint lehetőséget nyújt a kamera regiszterszintű konfigurálására is. A   libdc1394   az   alacsonyszintű   IEEE   1394­en   történő   átvitelt   megvalósító   libraw1394   linux  kernelmodult használja, azonban amennyiben ki akarjuk használni a DMA átvitel előnyeit, a video1394  kernelmodulra is szükség van, mely magasabbszintű hozzáférést biztosít a firewire interfészekhez. A magasabb szintű képmanipulációs műveletek megkönnyítésére a képek kezeléséhez az Intel  Open Source Computer Vision Library­t (opencv, libcv) [3] használtuk. Ahogy a neve is mutatja, ez  egy nyílt forráskódú, szabadon felhasználható függvénykönyvtár. Támogatja a legtöbb Windows verziót  és   UNIX­jellegű   operációs   rendszert.   Elsősorban   gépi   látással   kapcsolatos   és   képfeldolgozási  feladatokat ellátó rendszer fejlesztéséhez nyújt segítséget. Számunkra külön hasznos, hogy az alapvető  szűrőkön   és   algoritmusokon   túl   a   háromdimenziós   rekonstrukcióhoz   és   a   kamerakalibrációhoz   is  implementál néhány széles körben használt eljárást.

3/12

3. A kamera által használt képformátum Mint   korábban   említésre   került,   a   két   kamerát   a   PC­n   futó   program   egyetlen   eszközként  érzékeli. Ennek megfelelően a kamera egy speciális képformátumot használ az átvitel során. A 3. ábrán  látható a kameráról érkező nyers adat RGB képformátumban elmentve.

fig. 3: A kamerából kinyerhető nyers adat illusztrálása A kép valójában 3 képet tartalmaz egymással átlapolva (ezt RGB formátumban értelmezve az  első kép a vörös, a második a zöld, a harmadik a kék csatornán fog megjelenni). Ha a kamerák képeit  külön   szeretnénk   feldolgozni   először   is   a   három   csatornát   külön   kell   választanunk.   Ennek  eredményeként kapott képek láthatóak a 4., 5. és 6. ábrán.

4/12

fig. 4: Az első csatorna

fig. 5: A második csatorna

5/12

fig. 6: A harmadik csatorna Jól látható, hogy az első kép a jobb, míg a második a bal oldali kamera képét tartalmazza. A  harmadik kép valószínűsíthetően a két képből számolt valamiféle mélységi információt tartalmazhat,  azonban ennek pontos formátumára nincs utalás a kamera technikai adatlapjában. Megfigyelve a két kamera képét, látható, hogy a pixelek intenzitása egy jellegzetes ismétlődő  mintázat szerint változik a képen, ugyanis a képek nem szürkeskálás, hanem színes képek, azonban  nem   RGB   formátumban,   hanem   Bayer   elrendezésben,   vagyis   közvetlenül   a   CCD   szenzorok  elrendezésének megfelelő formátumban kapjuk az intenzitásértékeket. 

fig. 7: Bayer mintázat variációi A 7. ábrán a Bayer elrendezés 4 variációja látható, ezek közül a Bumblebee a jobb felsőt, azaz a  BG elrendezést használja. Az opencv számos képkonverziós eljárást megvalósít, ezek között szerepel  egy Bayer­RGB interpolációs szűrő, melynek segítségével könnyebben kezelhető, hagyományos RGB  6/12

formára hozhatjuk a képeket. A konverzió eredményét a 8., 9. és 10. ábrán láthatjuk.

fig. 8: A jobb oldali szenzor képe

fig. 9: A bal oldali szenzor képe Láthatjuk tehát, hogy az első csatorna tartalmazza a jobb oldali, a második csatorna pedig a bal  oldali szenzor által készített képet. A harmadik csatorna elsőre véletlen zajnak tűnhet, azonban a kép  bizonyos területein korrelál a bal oldali kamera képével. Lehetséges, hogy valamilyen térbeli  információt hordoz, azonban ennek formátumáról nem áll rendelkezésre információ. Ha ez valóban egy  mélységi térkép, akkor sem lehet kielégítően finom felosztású, mivel a kép hisztogramját megvizsgálva  7/12

látható, hogy az csupán 16 diszkrét értéket tartalmaz (10. ábra).

fig. 10: A harmadik csatorna hisztogramja A fent ismertetett folyamat megtalálása, melynek segítségével a két szenzor képe kinyerhető a  kamerából, dokumentáció hiányában nem volt magától értetődő feladat, a helyzetet nehezítette az is,  hogy a használt PC firewire interfész kártyáján lévő két port közül az egyiken hibás adat érkezik, ez  azonban   csak   az   algoritmus   elkészülte   után   vált   egyértelművé.   Egy   ilyen   hiba   elrontja   a   Bayer  mintázatot, a képben csíkok jelennek meg (ez a nyers képen általában nem túl feltűnő, azonban a végső  RGB   formába   konvertált   kép   nyilvánvalóan   teljességgel   használhatatlan   lesz).   Ez   többször   tévútra  vezetett, mivel a hibát nem a hardverben, hanem a használt algoritmusban kerestem. A 11. ábrán látható  egy hibás, átalakítás nélküli kép, melynek alsó harmadán jól láthatóak a fent említett zavaró csíkok.

8/12

fig. 11: Hibás kép, feldolgozás nélkül

4. A kamera kalibrációja Pinhole   kamera   modellt   alkalmazva,   a   kamera   által   végzett,   háromdimenziós   térből   a  kétdimenziós síkba történő leképezés az ún. perspektív transzformációval modellezhető:

 

Ix w⋅i x f x 0 c x R 11 R12 R 13 T 1 I w⋅i y = 0 f y c y ⋅ R 21 R22 R 23 T 2 ⋅ y Iz w 0 0 1 R 31 R32 R 33 T 3 1

 



A   homogén   osztást   elvégezve   megkaphatjuk   a   térbeli   pont   képsíkra   vetített   megfelelőjének  koordinátáit. A transzformáció a fent is látható módon két jól elkülöníthető részre bontható. A jobb  oldalon álló mátrix függ a világkoordinátarendszer megválasztásától, illetve a gimbális közép aktuális  pozíciójától és orientációjától, ennek elemei az ún. extrinsic paraméterek, míg a bal oldali ún. kamera  mátrix   csak   és   kizárólag   magára   a   kamerára   jellemző   paramétereket   tartalmaz   (fókusztávok,  képközépre való eltolásértékek). A   legtöbb   kamera   rendelkezik   valamilyen   nemlineáris   lencsetorzítással   is.   Ezt   általában  9/12

valamilyen polinomos közelítéssel érdemes figyelembe venni. Az opencv kalibrációs függvényei az  alábbi másodfokú közelítést használják: 2

2

2

2 2

2

2

2

2 2

2

2

2

i x ' =i x⋅1k 1⋅i x i y k 2⋅i x i y  2⋅p 1⋅i x⋅i y  p2⋅i x i y 2⋅i x  2

2

2

i y ' =i y⋅1k 1⋅i x i y k 2⋅i x i y   p1⋅i x i y 2⋅i y 2⋅p 2⋅i x⋅i y

Látható,   hogy   a   torzításnak   van   egy   radiális   és   egy   tangenciális   komponense,   utóbbi   egyébként   a  Bumblebee esetében elhanyagolható mértékű. Háromdimenziós információ kinyeréséhez szükséges a fent felsorolt paraméterek meghatározása  valamilyen kalibrációs eljárás segítségével, egyrészt a nemlineáris torzítás kiküszöböléséhez, másrészt  a kamerák geometriájának leírásához, mely elengedhetetlen a távolságértékek kiszámításához, illetve a  pixelpárok megtalálásának általam választott, a későbbiekben ismertetésre kerülő módjához.

5. Összetartozó pixelek keresése Az összetartozó pixelek kereséséhez valamilyen mértéket kell találni, mellyel a pixelek  egymástól való különbözőségét mérjük és melynek alapján megtalálhatóak az egymásra legjobban  hasonlító pixelek a két képen, valamint érdemes valamilyen kényszert (vagy kényszereket) is bevezetni,  amit alkalmazva a keresési halmaz leszűkíthető. A pixelek összehasonlítására az intenzitásvektorok különbségének normanégyzetét használjuk,  a kényszert pedig epipoláris geometriai megfontolások adják, amit a 12. ábra szemléltet.

fig. 12: Epipoláris geometria Ha adott egy P1  pont az egyik kamera képsíkján, és ismerjük a kamera F1  fókuszpontjának  helyét, akkor meghatározható az ezeket összekötő egyenes. Ez az egyenes nem más, mint a P1 ponthoz  10/12

tartozó vetítési sugár, tehát az eredeti háromdimenziós térbeli pont (az ábrán P­vel jelölve) biztosan  illeszkedik erre az egyenesre. Ha ezt az egyenest levetítjük a másik kamera képsíkjára ­ azaz vesszük a  P1, F1 és F2   pontok által meghatározott, ún. epipoláris síkkal vett metszetét (ahol F2 a második kamera  fókuszpontja) –, akkor megkapjuk a P1 ponthoz tartozó epipoláris egyenest (az ábrán zölddel jelölt e  egyenes). Az epipoláris egyenes a P1­hez tartozó lehetséges P  pontok leképezése a másik képsíkra, a P1  párját tehát elegendő ezen egyenes mentén keresni. Ezt kihasználva a keresés lépésszáma O n⋅m ­ ről  O nm ­re redukálódik (n és m a kép szélessége, illetve magassága), valamint csökken a hibás  találatok esélye is. A   fent   leírtak   implementálása   az   opencv   segítségével   viszonylag   egyszerű,   hiszen   beépített  függvényeket   tartalmaz   mind   a   két   kamera   közti   epipoláris   leképezés   adott   pontpárokból   történő  becslésére, mind az adott ponthoz tartozó epipoláris egyenes számítására.

6. További feladatok, nyitott kérdések 6.1 Az algoritmus tesztelése A   továbbiakban   szükség   lesz   valamilyen   eljárásra   az   algoritmus   által   megtalált   pixelpárok  helyességének   ellenőrzésére.   Erre   használhatóak   például   a   kamera   által   készített   képek,   vagy  valamilyen számítógépes grafikával generált képpár is, előbbi előnye, hogy olyan problémákra is fényt  deríthet,   melyekre   a   generált   kép   nem   (például   kalibrációs   pontatlanságból,   kamera   egyéb   fizikai  tulajdonságaiból   eredő   problémák),   utóbbi   viszont   egzakt   eredményeket   szolgáltathat   a   módszer  hatékonyságáról.

6.2 Hibák detektálása és kezelése, takarás problémája A   párosítások   között   nyilvánvalóan   előfordulnak   majd   hibásak   (például   az   egyik   kamera  szemszögéből   takart   pontok   esetén),   ezeket   valahogyan   detektálni   kell   és   a   hibát   kezelni,   például  interpolált   távolságértéket   rendelni   hozzájuk.   A   hibák   detektálása   történhet   például   kétirányú  párosítással, vagy a kiugró értékek, a mélységi térképben megjelenő “tüskék” figyelésével.

6.3 Előfeldolgozás A rendszer hatékonysága nagy mértékben függhet az algoritmus bemenetére adott képen végzett  előfeldolgozási   lépéseken.   Az   algoritmus   futási   idejét   befolyásolja   a   kép   mérete   (elképzelhető  valamilyen   szegmentálás   alkalmazása   is),   a   kimeneti   értékek     helyességét   pedig   az   alkalmazott  11/12

zajszűrés, élkiemelés stb. 

6.4 Mélységi információ számítása A  működőképes   rendszerhez  implementálni  kell  még  a  fenti  módszer  szerint  meghatározott  pixelpárokhoz   tartozó   eredeti   pontok   megtalálását   végző   komponenst.   Ez   különösebb   elméleti  nehézséget nem jelent, hiszen a két ponthoz tartozó vetítési sugár egyértelműen meghatározza azt. 

Képek forrása: fig 1. ­ http://www.ptgrey.com/

Hivatkozások: [1] – http://www.ptgrey.com/products/legacy.asp [2] ­ http://damien.douxchamps.net/ieee1394/libdc1394/ [3] ­ http://www.intel.com/technology/computing/opencv/

12/12