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.

Ugye mi is így látunk, hogy a két szemből érkező képekből az agyunk rakja össze a 3D-t. Ha közelebb rakjuk az ujjunk a szemünkhöz és pislogunk felváltva, akkor látjuk, hogy jobban "mozog" az ujjunk két pislantás között, míg ha távol van, kevésbé. Magyarán minél nagyobb az elmozdulás, annál közelebb van a tárgy.

Erre van hát szükségem a feladat megoldására, két képen szereplő azonos pontok elmozdulásértékeire.

Két lehetőségem van:
Ritka illesztés: Azt jelenti, hogy a két képen meghatározok jellegzetes pontokat, ilyenek a sarkok. Veszek egy sarkot a bal oldalon, aztán megkeresem a párját a jobb oldalon, veszem a következő balt és így tovább. Ebből lesz egy elmozdulástérképem (disparity map), amivel tudok 3D-t kreálni.
Előnye, hogy gyors, hátránya, hogy nem lesz olyan részletes a térkép.
Sűrű illesztés: Veszem a két képet, "egy szintbe hozom (rektifikálom)", aztán soronként keresem meg a párokat.
Előnye, hogy többet talál, hátrány, hogy lassabb, mint a ritka illesztés.

OpenCV-ben előre megíva a sűrű illesztés van, ez a cvFindStereoCorrespondenceBM(). Ha benne lenne a ritka is, szóljatok, mert akkor elkerültem .

Eddigi posztokban a ezzel szenvedtem, de most már megvan a hiba. BM-t újra be kellett állítani, és most már tényleg utána néztem, hogy a beadható adatok mit is csinálnak.

A BM beállításai 3 részre oszthatóak:
Előszűrés: a keresgélés előtt normalizálja a képet (preFilterType, preFilterSize, preFilterCap)
A keresés beállításai (SADWindowSize, minDisparity, numberOfDisparities)
Utószűrés: a hibás találatok törlése (textureThreshold, uniquenessRatio)

Az eljárás lényege:
Tehát van az a kék tárgy, látja a jobb és a bal is. A kép már rektifikálva van, azért a tárgynak mindkét képen egyező sorban kell lennie (y0), innentől kezdve 1D-s keresés (épp ezért nagyon fontos a rektifikálás).
Meg kell keresni, hogy a bal oldali képhez képest mennyire van "elmozdulva" a másik képen a tárgy. A BM szépen elindul a jobb oldali képen a x0,y0 pontból és megkeresi a pixelt egy adott intervallumban (numberOfDisparities) mozogva. Persze lehet, hogy a bal képre csinálja az egészet, nem néztem meg a BM forrását.

Ha megtalálja, eltárolja a bal oldali x0, y0 pixelhez az elmozdulást az elmozdulástérképbe (=disparity map). Ha nem találja meg, akkor általában a minDisparity-1 értéket rakja oda.

Megcsináltam kézzel az elmozdulásokat, egy képpáron saját szememmel megkerestem a térben ugyanazon pontokat, és lemértem, hogy be tudjam állítani a függvényt:

Katt, hogy látszódjon

Az adatok közül csak az X és Y a fontos. A képeket egymás mellé raktam, ezért a jobb oldali X értékekből 320-t ki kell vonni és úgy kiszámolni pixelben az elmozdulást.

A legnagyobb elmozdulás itt 82 volt, tehát a numberOfDisparities-t ennél kisebbre nem rakhatom. A minDisparity meg azt jelenti, hogy az x0, y0 pont X-ben mennyivel mennyen arrébb a jobb képen. Például =0 értéknél marad a helyén, >0 esetén balra tolódik, <0 esetén jobbra tolódik.

Bal disparity maphoz ezeket az adatok adtam meg (többi érték default):

BMState->numberOfDisparities=96;
BMState->minDisparity=0;

Magyarul x0 és y0 ne változzon, és max. 96 pixeles tartományban kereshet. A numberOfDisparities értékének pozitívnak és oszthatónak kell lennie 16-tal ezért 96 és nem 80.

Ugye mindezt fordítva is meg kell csinálnom, hogy a jobboldali képre határozza meg az elmozdulásokat, de a numberOfDisparities nem lehet negatív szám, a pontot meg jobbra kell keresni.

Itt jön a képbe a minDisparity, azt tolom el 96-tal, így a beállítások:

BMState->numberOfDisparities=96;
BMState->minDisparity=-96;

Természetesen a BM meghívásakor is fel kell cserélni a két képet.
Ezzel viszont előfordulhat, hogy hülyeségeket talál, persze alapesetben is találhat nem odaillőket, amiket mégis párosításnak néz. Eredményként a balra csinált elmozdulástérképnek pontosan az ellentétjét kell kapnom (logikus, amit balon +50-re talált meg, azt jobbon -50-nél kell találnia).

A szűrés nagyon egyszerű, ha baloldali képre meghatározott elmozdulás negatív ellentétje van a jobboldali párján, akkor az az elmozdulás jó, megtartjuk, különben minDisparity-1 értéket kapja.

A leszűrt elmozdulástérképet berakom a cvReprojectImageTo3D()-be, aztán ebből a 3D-s ponthalmazból próbálom megállapítani, hogy van-e akadály a robot előtt.

Október 22., még 48 nap

Előző napi dolgokat matlab scripttel tesztelgettem, de ma a kódba berakva is ugyanúgy működik.

Lássuk mit kaptam.

BM default, 3D (minDisparity=0; numberOfDisparities=64)

BM mod, 3D (minDisparity=20; uniquenessRatio=60)

BM bal-jobb szűréssel, a fenti beállításokkal, 3D

Szépen megszűrte a felesleget. Most kérdezhetitek, hogy a BM mod miért nem volt jó.
A BM mod-dal alapvetően az a baj, hogy közelebbi tárgyakat nem találta meg és túl sok elveszett a valós 3D-s pontokból. Szükség volt a "megengedőbb" beállításra, hogy minél több részlet maradjon meg, de a tévedések mégis essenek ki, ezért kellett a bal-jobb szűrés.

Mivel gyakorlatilag megvan minden, a robot mozgásának az algoritmusa van már csak hátra. Terveim szerint kb. fél méteren forduljon ha akadály van előtte, ezért szerintem a fejmozgatást nem úszom meg, mert ilyen távolságon már képtelen balra vagy jobbra látni álló képen, így másképp nem tudja megállapítani, hogy merre van a megfelelő irány.

Október 23., még 47 nap

Implementáltam a robotos programba a bal-jobb szűrés, remekül működik. Az FPS nem csökkent a lehíváshoz képest.

Fogtam az összes adatot, amit csak gyűjtöttem és megalkottam egy algoritmust (ne gondoljatok bonyolultra) ami meglátja a tárgyat. Az adatokat átböngészve pedig a küszöbszámokat is meghatároztam. Mindezt szintén beleraktam a robotos programba, de még csak kiírja. Rövid a bekezdés, de sokáig tartott.

Október 24., még 46 nap

Itt a nagy nap, ma videót kell csinálnom a mozgásról mindenáron.

Elsőként megvizsgáltam, milyen sebességnél nem rázkódnak a kamerák, mely értékeknél fordul megfelelő szöget a robot úgy, hogy ne boruljon fel, kikísérleteztem, hogy a fejmozgatás után mennyi időt kell várni, hogy tiszta legyen a kép. Fontos adatok, mert nagyon fent van súlypontja a robotnak, gyors fordulásnál hatalmasat tud esni.

Csináltam egy ablakot, amivel a fontos adatokat be tudom vinni, mert előfordulhat, hogy majd máshol is felvesszük a mozgását és ott már nem lehet kódot átírogatni.

Felbukkant egy hatalmas bug, aminek egyelőre nem értem az okát. Jelzést adok egy szálnak, hogy leállhat, de mégse áll le. Ugyanúgy van használva, mint az összes többi, de ez valamiért nem áll le. Felvétel miatt később keresem meg az okát.

Végül boldogan jelenthetem, hogy a heti terv teljesítve, van felvétel . Majd a videókat is bemutatom, de azokat csak a védés után, addig nem szeretném.