Arra gondoltam, írok mégegy bejegyzést, mert a motorvezérlések órát nagyon unom... Beszámolok a fejleményekről. Kezdeném a legutóbbi videóval... Az a rózsaszín cetlis. Bármennyire is bonyolultnak tűnik, egy elég egyszerű alkalmazásról van szó.
Legelső lépés: fogjuk a kamera grafikus felületét, s készítünk vele pár képet a követni kívánt objektumról. (Sajnos képeket most nem tudok berakni...) Ha ez megvan, megvizsgáljuk, hogy az illető szín milyen tartományokon belűl van. Ez a legfontosabb paraméter a színkövetésben. A tartomány. A rózsaszín színnek a következő paraméterei vannak : R : 170-190 ; G : 40-60; B : 30-50;
Addig már eljutottunk (korábbi bejegyzések segítségével), hogy megérkezik a képinformáció az FPGA-ba. Végigmegyünk egy for ciklussal a pixeleken és megvizsgáljuk, hogy melyik pixel van a megjelölt tartományon belül. Ha elég pontosan adtuk meg a tartományokat, akkor még azt is meg tudjuk határozni, hogy milyen távol van az illető objektum a kamerától. De ne szaladjunk ennyire előre. For ciklus. Végigpásztázzuk a képet, megvizsgáljuk, hogy hol vannak olyan pixelek, amelyek az illető tartományon belül van. Ha találunk egy ilyen pixelt, annak az X és Y koordinátáját eltároljuk valahová. Ha végeztünk a pásztázással, összeadjuk az X koordinátákat külön illetve az Y koordinátákat külön és elosztjuk a talált pixelek számával (vagyis átlagot számolunk belőle). Ha ezzel megvagyunk, megkapjuk az illető objektum közepét (persze ez nem mindig így működik... ha nem volt elég pontos a színbeállítás, akkor lehetnek elég komoly eltérések). A jobbra-balra irányban mozgató szervó 80 és 180-as PWM kitöltési tényező között mozoghat, hogy ne ütközzön bele a saját lábába (azt tudjuk, hogy a szervónak a két végállását a 0 és 255 közötti PWM kitöltési tényező adja). A koordináták, amit kapunk valahol 0 és 90 között vannak, mivel a kép horizontálisan tömörítve van egy kicsit (részletekért lásd a CMUCam3 felhasználói kézikönyvet). Ezt kell átalakítani kitöltési tényezővé. A fel-le irányú mozgás koordinátája 0 és 145 között mozog, ezt is szintén 80 és 180 közötti kitöltési tényezővé kell átalakítani...
Franc essen bele.. nem tudok normálisan fogalmazni... Ez volt a baj a dokumentációnál is. Próbáltam nem konyhanyelven fogalmazni, de szinte mindíg belebonyolódtam a saját mondatomba. A kivonatomról nem is beszélve... Ezer karakterben mit lehet leírni? Vagy több kell oda, vagy kevesebb... De ezer karakter? Olyan, mint egy tizenhét másodperces trailer... Nem tudod, hogy mit tegyél bele...
Na ott tartottunk, hogy megvan az X és Y koordináta. Megadunk egy semleges tartományt (a közepét a kinyerhető pixelértékeknek, vagyis fel-le irányban 65-75, jobbra-balra irányban 40-50 között). Ha a tárgyunk középpontja ezen a tartományon belül van, akkor nem mozgatjuk a egyik szervót sem. Ha X<40 && Y<65, akkor a kamera (hátulnézetből) jobbra és felfele fog mozogni. A többit meg ki lehet innen következtetni.
Fejlesztési lehetőség: felhasználni a konkrét középpont értékeket, hogy tudjuk, meddig kell elmozdítani a kamerát, s nem csak arrafele húzni, hogy "majdcsak odaér valamikor"... Ez a legrövidebb idő tipusú vezérlés. Kisebb helyen vizsgálni a pixelértékeket (mert ha egyszer megtaláltuk a kép jobb felső sarkában, akkor valószínűsíthető, hogy a következő képen is valahol a környéken lesz... Ergo a középpont plussz minusz 40 pixel tartományban vizsgálni a pixelértékeket). Legrövidebb idő, legkevesebb energiafelhasználás. Mozgás érzékelés bevitele... Ezt bonyolult elmagyarázni... Egyszer körbenéz, választ refernciapontokat, s azokhoz viszonyítva megállapítja, hogy a képen hol van mozgás és csak ott vizsgálja az illető pixel értékeket. Utolsó ötlet: felhasználni a leftmost-rightmost pixelértékeket, illetve a talált pixelek mennyiségét és ez alapján meghatározni, hogy milyen messze van az illető tárgy a kamerától. S ha ez megvan, akkor a pók testét is mozgatni ennek függvényében előre vagy hátra. ha kevés pixel van, akkor előre, ha sok pixel van, akkor hátra.
S ha minden jól megy, ez utóbbit meg is valósítom nemsokára... Csak legyenek meg az alumínium lábak...
Új téma: arcfelismerés. Szó volt róla korábban, hogy a tanítóhalmaz felépítéséhez 18*18 méretű képet használtam. A matlabban is erre a méretre volt megírva minden, illetve az FPGA programjában is erre volt optimalizálva minden egyes kód és minden egyes tulajdonság. S nemrég elértem az FPGA-s projekttel is oda, hogy nagyobb méretre is végigpásztázzam a képet arcok után. Ekkor derült ki, hogy az általam használt méretek nem egyeznek meg a matlabban használt méretekkel (ha nem 18*18-as csúszóablakot használok). Most azon töröm a fejem, hogy mi lesz a megoldás. Van egy "négermunkás" megoldós, ahol minden egyes tuladonságot újra át kell írni matlabból ANSI C-re, és be kell illesszteni egy plusz for ciklust, ami végigmegy, s mindenhonnan kivon egyet, ahol nem zéró van eredetileg. Vagy deklarálok mégegy tömböt, egy maszkot, amivel maszkolom a kapott értékeket. Vagy kitalálok valami újat (ami eddig még nem jutott eszembe), ahogy meg lehet oldani ezt a feladatot. Mindenképp hétvégén ezen is fogok dolgozni...
Még valamit akartam írni, de már nem jut eszembe...
Return top
0 megjegyzés:
Megjegyzés küldése