Szeptember 3., még 97 nap

Az OpenCV jelenleg két "részből" áll. Az OpenCV 2.0, ami C, és az OpenCV 2.1, ami C++.
A programom C hívásokat tartalmaz, mert a legtöbb neten található forrás, tutorial és példa erre épül. Azonban ezen a napon kicsit utána jártam, hogy Sobel miként néz ki 2.1 hívásokkal.
Nagy nehezen sikerült is, de a szál visszatérésnél az IplImage képadatra mutató pointere egyszerűen "elromlik" (<Bad Ptr>), hiába próbáltam meg egy csomó IplImage felépítő megoldást. Ha a 2.1 legfőbb struktúráját használom (cv::Mat), akkor minden oké.
Most választhattam, hogy teljesen áttérek 2.1-re, vagy maradok, de inkább maradok, mert mint írtam fentebb, minden segédeszközöm 2.0-t használ, és nem biztos, hogy minden 2.0-s függvényt portoltak 2.1-re. Amit meg portoltak, lehet, hogy másképp. Például Sobel, 2.0-ban meg kell adni a forrást, a célt, és hogy x vagy y irányba deriválsz. 2.1-ben már azt is, hogy a cél mátrix milyen típus (pár napja itt rontottam el).

Szeptember 1., még 99 nap

A képfeldolgozással kapcsolatos kódokat átraktam egy új dll-be, hogy jobban elkülönüljenek az ablaktól és a robotvezérlőtől.
Ki kísérleteztem, hogyan rakható egy kamera esetén 2 külön threadbe a kép lehívás, és a sobel feldolgozás. Két kamera esetén már 4 threadről beszélhetünk (bal, jobb lehívás, bal jobb sobel).
Minden rendesen működik, meghozták a várt eredményt. Eredményeket majd holnap.

Szeptember 2., még 98 nap

Canny-val is megcsináltam azt, amit a sobellel tegnap, tehát 1 kamera esetén 1 vagy 2 thread, 2 kamera esetén 1 vagy 4 thread. Sajnos a tegnapi sobeles méréseket dobhattam a kukákba, mert a robotok ma kicsit gyorsabbak voltak, mint tegnap (nem voltak töltve, fizikailag ugyanoda raktam őket, érthetetlen...).

Mérések:
A mérést vpc-ben futó winxp-vel végeztem, ami csak 1 magot lát a processzorból. VS2008 alatt, debug módban futott a program (akár 10-30%-t is megesz így a processzorból). Az FPS kiszámítása úgy történt, hogy 10 másodpercenként összejött framek számát osztotta 10-zel a program, SVS esetén 1 frame, 1 képpárt jelent. A timeoutos részeket nem vettem figyelembe.
Q8: legrosszabb jpeg minőség, Q1: legjobb jpeg minőség

Kicsit egyszerűsítem a dolgokat, mert sajnos kezdődik hamarosan az iskola . Például csak a munkával telt napokat jegyzem fel és a címbe se írok le minden napot, csak az időszakot.

Augusztus 27., még 104 nap

A sobel feldolgozás ötletemhez ismét elővettem a thread linkjeimet, és megoldást kerestem arra, hogyan adhatok adatot a threadnek, és hogyan szerezhetek onnan vissza, globális változók nélkül. Amire "vágytam", azt tesztkódban sikeresen megcsináltam.

Gondoltam először az SVS képlehívását írom át 2db threadbe (a dll-ben), kíváncsiságból, hogy mennyit gyorsul. Olyan szép hibaüzeneteket kaptam, hogy csak lestem . Itt egy [link] nekem is ez volt a bajom, és Napalm megoldása lett jó nálam is, így nem kellett az egész dll-t átalakítani, a másik megoldás amit találtam, az sokkal nagyobb átalakítást igényelt volna.

Augusztus 24., még 107 nap

Konzultációnak vége, a konzulens elégedett az eddig elért eredménnyel, főleg annak, hogy sikerült megoldani a jpeg dekódolást memóriában, és OpenCV-s IplImage-t csinálni.

Gyorsításra is adott pár tippet, pl. nem kell RGB->BGR, elég lenne egy IplImage headert csinálni, memória másolást kiváltani mással (bár azt hiszem csak címet másolok, egyedül akkor másolok (memcpy()), amikor összegyűjtöm a kép bytejait) és SVS esetén a két kép dekódolását külön szál végezze.

Kérése volt, hogy a kamera kalibráció, és a többiek majd külön .dll legyenek, és nem szükséges a grafikusba berakni, elég egy egyszerű konzolost megcsinálni.

Először is, tesztet kell végeznem, hogy a robot éldetektálása gyorsabb-e, vagy az, ha számítógép végzi el (sobel + canny) és milyen a minőségük. Természetesen SVS robot esetén is, két képpel.

Augusztus 21., még 110 nap

Egy dolgot kifelejtettem a grafikus programból, az SRV távolságérzékelőjét. Elég katasztrofálisan mér, nem is hiányzik igazából, de azért beraktam, ha már a .dll-be implementáltam.

Lásd kép:
Egy fehér falra nézett a robot, merőlegesen. Három távolságból mértem le (zárójelben az igazi távolság): 22 cm (45 cm), 17 cm (30 cm), 13 cm (20 cm).
A robot a kamerája segítségével határozza meg a távolságot, valamilyen belső függvénnyel. Ha a robot nem merőlegesen néz a falra, vagy valamelyik lézerpont nem látszódik, akkor teljesen random mér.

Mérések

screenshot

Itt egy példa, mikor nem a fehér fal felé néz...
screenshot

Augusztus 17., még 114 nap

Feljegyzés

Ma is sok guglizás volt .
Első probléma az volt, hogy a log területen, ha már túl sok a sor, nem scrollozik az utolsó üzenethez -> megcsinálva.
Másik a checkbox értékének lekérdezése -> megcsinálva.
Harmadik, az még nem lett implementálva, de majd a folyamatos kamerakép kijelzésnél fog előjönni. Ehhez thread-t kell majd használni, mert nélküle befagy az ablak. Ezt a két oldalt tanulmányoztam jó sokáig: Creating Threads és Process and Thread Functions
Csak újabb problémák jönnek elő. Ha épp kamera képet fogad, akkor más üzenetet nem lehet küldeni, mert elvileg elrontja a kép fogadását, tehát versenyhelyzet alakulhat ki.
Valami szemaforos megoldást kell találnom (hátha thread leírásban van, csak eddig elkerülte a figyelmem).

Ha már kódolás van orrvérzésig, egy rövid bejegyzéssel tisztelgek egy régi művem előtt.

Nevezhetném minimal játéktesztnek .

"Ajánló"

Böngészés közben eszembe jutott egy régi házim, amit java-ban kellett írni (senki ne várjon nagyon bonyolult progit, csak azért az ember szívéhez nő az a program, amit egyedül, sok idő ráfordításával valósított meg).
Egy régi "szállj le a platformra" típusú játék, ha elvétetted a platformot, vagy kirepültél a pályáról, akkor halál.

Így indul a játék, a platform egy bizonyos sávban random helyen jelenik meg. Az űrhajót a 4 kurzorral lehet irányítani. Ha nem nyúlunk semmihez, az űrhajó gyorsulva elindul lefele.

Augusztus 13., még 118 nap

Feljegyzés

A .dll-be rakás simán sikerült, azzal nem lesz baj a továbbiakban. Ezt és ezt a videót használtam fel. Sajnos eléggé tré a minőség, de kivehető, hogy mit kell csinálni.

Viszont ismét egy nagyobb akadályba ütköztem.

Mindegyik verziónál kell egy grafikus konzol, ma már minimum.

Jó ötletnek tűnt a .NET C++ alatt WinForms, de megint túl optimista voltam .
Az a gyanúm, hogy .NET C++ alatt megfekszik az egész beigazolódott. Most nem irkálom, hogy mi a gubanc, egyébként natív vs. felügyelt, egy rövid magyarázat mi a különbség köztük.: [link].

Augusztus 10., még 121 nap

Pár OpenCV link

OpenCV C++ Ref.
OpenCV Examples Part 1
OpenCV Examples Part 2
Introduction to programming with OpenCV
CV Reference Manual
Noah Kuntz - Tutorials

Kiegészítés SDL-hez

SDL-hez még két dolog kell:
1. Win32 projektet kell létrehozni (azon belül mind1 mit)
2. main-nak így kell kinéznie:

Augusztus 9., még 122 nap

Történések

Hirtelen ötlettől vezérelve elkezdtem vizsgálni, hogy csak SDL-el meg lehet-e csinálni a kép átalakítását IplImage-ra, ugyanis SDL-nek van SDL_image része is, és már két forrást is találtam ([link], [link]), ami csak SDL-el dolgozik.

Láss csodát, sikerült..., csak RGB-ben kapom meg a pixeleket és át kell alakítani BGR-re, mert IplImage ezt használja. (cvCvtColor(srcimg,destimg,CV_RGB2BGR);)

Balra: SDL képe, jobbra: OpenCV képe, és nincs CxImage, a szín OK
Egyik fenti forrás átalakítva a teszthez

screenshot