Újra itt . Folytatódik a 57 napja leadott szakdolgozat további fejlesztése.

GAMF-t befejeztem, diplomára jeles kerül, irány a munkaerőpiac! (jaj )

KÉPAF2011-re a cikk: [pdf]

A távolság probléma meg lett oldva, ennek nagyon örültem (lásd előző poszt).

Fejmozgatás

A szakdolgozathoz 3 kérdést kaptam, ezek közül az egyik, hogy mi történne, ha nem lehetne mozgatni a robot fejét.

Először egy kis ismétlés:

Lényegében a bal képen található (x0,y0) pixelhez úgy keressük meg a párosítást, hogy elindulunk a jobb oldali kép (x0,y0) pixeléből, és végignézünk egy tartományt, hogy melyik pixel illik rá legjobban a bal oldalon található pixelre.
Két fontos paraméter látható a képen:
minDisparity: (x0,y0) ponthoz mennyire térjünk el vízszintesen (ezt a továbbiakban nem bátjuk)
numberOfDisparities: hány pixel legyen az a tartomány, amin keresünk. (továbbiakban NofD)

Ez a bejegyzés több nap eseményeit meséli el, csak már nem emlékszem, mit mikor csináltam.

Ha még emlékeztek rá, a múltkori bejegyzésben azon agyaltam, hogy a tényleges és számított távolságok miért nincsenek még köszönőviszonyban sem.

Három ötletem volt a hibára:
1. kalibráció
2. a disparity map -> 3D megvalósításnál valami nem stimmel az OpenCV-ben
3. Vetítési hiba

Berakom megint a számolt és tényleges távolságokat:

Elkezdtem a próbálgatást, először a vetítési hiba jelenséget akart leellenőrizni magasabb felbontással. Eredetileg 320x240-es képeket használtam, most kipróbáltam 640x480-on. A sebesség se volt borzasztó lassú.
Ehhez az elmozdulásokat számoló BM függvényt is újra be kellett állítani.

Eredmény:

December 10., még 0 nap

Lejárt az idő, végre, szakdoga leadva, befogadva, most már csak azon kell izgulni, nehogy elkeverjék .
Kemény 4 hónap volt, főleg leírni ezt az egészet úgy, hogy az előző két hétben betegeskedtem.

A blogolás bevált, így emlékeztem a bakikra, amiket bele kell írni a dogába és a teszteredmények publikálása is hasznos volt, mert így megvoltak.
Nem is beszélve néhány képernyőmentésről, amit egyszerűen nem találok a vinyón, de itt megvoltak.

Tehát csak tanácsolni tudom, hogy aki diplomamunkát, szakdolgozatot ír, az blogoljon (nyilvánosan, vagy csak magának).

A szakdolgozatból tervezek ide is egy rövidebb cikket, de azt majd február fele.

Október 21., még 49 nap

Hétfőn sikeresen félreértettem a konzulensemet. Nem azt mondta, hogy csináljam meg jobbra, majd balra a 3D-s ponthalmazt, majd abból szűrjek, hanem azt, hogy fogjam a két disparity mapot és abból szűrjek, majd a bal oldali képre csináljam meg a 3D-s ponthalmazt.

A jobb kép 3D-s ponthalmazával az a baj, hogy gyakorlatilag nem nyertem semmit azzal, hogy ki lett számolva. Látszódik persze minden ami kell, de nincs kapcsolat a bal és a jobb halmaz Z értékei között (ami a távolság), nem lehet felhasználni szűrésre. Ha mégis kézzel belövöm a szűrést, akkor bármilyen változtatásnál újra ki kéne kézzel számolni mindent és újra belőni.

Az a terv, hogy "megengedő" BM-t eresztek rá a jobb és a bal képre, majd a nem egyező disparity értékeket törlöm, így a fals adatok kiszóródnak.

Először is tartok egy kis oktatást .

Miért is csinálom ezt.

Október 20., még 50 nap

Az 15. bejegyzésben írtam, hogy balra rosszul lát és ezzel kezdeni kell valamit. Közben rájöttem, hogy azzal nem lehet mit kezdeni, hiszen a kamerák rögzítettek és jobbra is ez a probléma, hogy van egy sáv, amire nincs illesztés.

Több megoldási lehetőség kínálkozik:
1. A robot akkor fordul, mikor még biztonságosan megállapítható, hogy mehet-e balra vagy jobbra, ha szemben akadály van.
Hátrány: szerintem elég csúnyán néz ki, hogy a tárgy előtt nagyon messze már fordul, kicsi teremben meg körbe-körbe forgolódik.
2. A robot használja a fejét, így közelebb engedhetem a tárgyhoz és mégis biztonságosabban megállapítható merre induljon.
Hátrány: konzulensnek nem tetszik .
3. 1. pontban leírtak a javítása. Eddig csak a bal képre volt megállapítva a 3D-s koordináták, most meglesz állapítva a jobb oldalra is, így kicsit biztosabb lesz a 3D-s térkép megállapítása.
Hátrány: ugyanazt mint az elsőnek, csak kicsit talán közelebb lehet engedni.

Október 18., még 52 nap

A robot következőt fogja csinálni: megy, míg túl közel nem kerül egy tárgyhoz, aztán elfordul valamerre, aztán tovább halad. Megpróbálok egy elég nagy tesztpályát készíteni, ami teli lesz szórva dobozokkal.

Az adatok megfelelőek, megkaptam a zöld jelzést, most már pontos adatok alapján kidolgozhatom azt az algoritmust, ami a fenti cselekvést meg tudja csinálni.

Persze ezzel vannak gondok, mert jelenleg a bal képre készül el a 3D-s ponthalmaz, ezért balra rosszabbul lát. A másik probléma, hogy a kamerák távol vannak, kicsi a látószög. E két nagyobb probléma miatt a robot kénytelen lesz látványosan hamarabb fordulni.
Van két ötlet ennek a leküzdésére, majd később leírom.

Csináltam egy képsorozatot, ahol centivel szépen lemértem minden távolságot, elkezdtem a kapott OpenCV eredményeket hozzárendelni a valósághoz.

Ígértem egy olyan képet is, ahol nem merőlegesen, hanem élével szemben áll egy doboz a robottal, íme:

Október 16., még 54 nap

Feljegyzés, az 1. és 2. képsorozat 54:50-s fejpozíciónál készültek

Ma csak egy fejlesztés történt, a párhuzamosan végrehajtható dolgokat külön threadbe raktam. A sebesség fontos . Mérések holnap, mert lámpafénynél eléggé ugrálnak az eredmények, de így is látható gyorsulás. Threadbe rakáson kívül van még egy lehetőség a gyorsításra: kiszedem a megjelenítést. A rektifikált kép és a látható disparity kép előállítása is időbe telik.

VS2008 is tud szép hibákat irkálni:

Pedig a parancsot az msdn oldaláról néztem, és csak a kernel32.dll volt megadva függésnek.

Debug módban nem ilyeneket kéne feldobnia...

Október 11., még 59 nap

Csak kiderült, hogy valami nem stimmel.
A teszthez használt képekkel van egy nagy baj: a sakktábla.
Ugyanis a BM párokat keres a két kép között, a sakktábla mintái pedig ismétlődnek, így mindig a bal szélén találja meg (ha balról kezdi, nem néztem utána) a keresett pontot, hiába van az mondjuk a sakktábla jobb szélén. Pontosan ezért volt egy kupacban minden talált pont, aaaaaah.

Első körben saját képek kellettek, amiket lementek a programmal, mert robottal rohangászva nem lehet mindig ugyanolyan képeket csinálni.

Rectify és remap a menüből átköltözött ide, a képmentést egyelőre a normálhoz raktam.

Gondoltam a kép neveket a rand() nevű csoda függvénnyel teszem különbözővé, hát nem eléggé random . Később átjavítom időbélyegre.

Szeptember 20., még 80 nap

Ebben a postban kicsit benéztem, OpenCV a C-s és a C++-s rész is 2.1-s: [link].

Következő lépés: A két képből 3D-s adatokat nyerni.

Október 8., még 62 nap

Visszatértem, elég sokat szenvedtem a 3D-s adatokkal eddig.
Elvileg az OpenCV-ben van egy függvény, cvReprojectImageTo3D, amivel elvileg rögtön 3D-s ponthalmaz nyerhető a cvFindStereoCorrespondenceBM eredményéből. Itt egy bizonyíték.

Sajnos nálam valami nem klappol. Most a különböző próbálgatásoknak a beállításai és eredményei lesznek felsorolva.

Magyarázat:
Kalibrálás: mikor az opencv meghatározza, hogyan kell javítania a képet
Remap: a kalibrációs adatok alapján rektilineárissá (lásd előző poszt) teszi.

Kitérő

Az OpenCV-s példák között találtam:

screenshot

Jó sokáig futott, több percig. Nagyon érdekes, a keresett dobozos képen felvesz valami szisztéma alapján pontokat, majd a székes képen is ugyanúgy. Párosítja a pontokat, így egész pontosan meg tudja mondani, hogy a székes képen hol helyezkedik el a doboz.

Szeptember 6., még 94 nap

Ami tegnap nagyon zavart, hogy az ablakkezelőbe kellett raknom a kamera kalibrálást, az megoldódott, át tudtam rakni a képfeldolgozóba. Bár ez a megoldás se tetszik 100%-san, de sokkal jobb, mint az előző.