PAL-COMMANDER Mobil robot navigációja PAL-optikás megvalósítással Budapesti Műszaki Főiskola Neumann János Informatikai Főiskolai kar Informatikai és Automatizált Rendszerek szakirány 2005. november 10.
Fejlesztők: Mornailla László, IV. évfolyam Pekár Tamás Gábor, IV. évfolyam Solymosi Csaba Gergő, IV. évfolyam http://roberta.obuda.kando.hu/iar/2004_2005/palcom Konzulens: Vámossy Zoltán főiskolai docens
PAL - Commander
Tartalomjegyzék 1. Bevezetés........................................................................................................6 2. Irodalomkutatás.............................................................................................7 2.1 A robot fogalma...............................................................................................7 2.2 A robotok csoportosítása helyváltoztatási képességük alapján..............................8 2.2.1 Kerekes robotok........................................................................................8 2.2.2 Járó robotok..............................................................................................8 2.2.2.1 EXPLORATES II (1997-1998) [1]..........................................................8 2.2.2.2 FOBOT (2002-2003) [2].......................................................................9 2.2.3 Lánctalpas, gumitalpas robotok...................................................................9 2.2.4 Repülő robotok..........................................................................................9 2.3 A robot navigációja.........................................................................................10 2.4 Térképezésen alapuló navigáció megvalósítása.................................................11 2.5 GPS rendszerrel ellátott mobil robotok térképezésének menete..........................12 2.6 További hasonló projektek...............................................................................13 2.6.1 Evolution Robotics – ER1..........................................................................13 2.6.2 CameraCar – SR04...................................................................................13 2.7 Teljeslátószögű (omnidirectional) rendszerek....................................................14 2.7.1 Omnidirectional-rendszer..........................................................................14 2.7.2 The Caboto projekt [7].............................................................................15 2.8 A PAL – optika...............................................................................................16 3. A rendszer megvalósítási elvei ....................................................................18 4. Hardver elemek............................................................................................19 4.1 Autók............................................................................................................19 4.1.1 RC autó..................................................................................................19 4.1.2 Modell RC autó........................................................................................19 4.2 Távirányítók...................................................................................................20 4.2.1 RC távirányító..........................................................................................20 4.2.2 Modell RC távirányító...............................................................................21 4.3 Kamerák........................................................................................................25 4.4 Feldolgozó egység..........................................................................................26 5. Szoftver elemek............................................................................................27 5.1 Bemutatás.....................................................................................................27 5.2 Delphi fejlesztői környezet...............................................................................27 5.2.1 OpenCV [29]...........................................................................................28 5.2.2 PALCom keretrendszer.............................................................................28 5.2.3 Imagetrans modul...................................................................................29 5.2.3.1 Képfeldolgozási algoritmusok.............................................................29 2
PAL - Commander 5.2.3.2 SUSAN (Smallest Univalue Segment Assimilating Nucleus) élkereső algoritmus [19].............................................................................................31 5.2.4 RadiControl modul...................................................................................33 5.2.5 AI modul.................................................................................................33 5.2.5.1 A PAL-kalibráció működése:...............................................................34 5.2.5.2 Track követés...................................................................................34 5.2.5.3 Vonalkövetés....................................................................................35 5.3 C# keretrendszer...........................................................................................36 5.3.1 Input modul............................................................................................37 5.3.2 Filters modul...........................................................................................38 5.3.3 AI modul.................................................................................................40 5.3.3.1 Vonalkövetés:...................................................................................41 5.3.3.2 Pályakövetés....................................................................................41 5.3.3.3 Objektumkövetés..............................................................................42 5.3.4 Navigation modul.....................................................................................43 5.3.5 Events modul..........................................................................................44 6. Programfejlesztési metodikák......................................................................45 6.1 A fejlesztés módszere.....................................................................................45 6.1.1 Subversion [27].......................................................................................45 6.1.2 Wiki........................................................................................................45 7. Tesztelés.......................................................................................................46 7.1 Hardver tesztelés............................................................................................47 7.2 Szoftver tesztelés...........................................................................................47 7.3 Mérések.........................................................................................................47 7.3.1 Mérés tárgya...........................................................................................47 7.3.2 Mérés célja..............................................................................................47 7.3.3 Mérés menete.........................................................................................47 7.3.4 Mérési eredmények..................................................................................48 7.3.5 Mérés értékelése......................................................................................48 8. Összegzés.....................................................................................................49 9. További lehetséges alkalmazási területek....................................................49 10. Rövid távú továbbfejlesztési irányok.........................................................49 10.1 Hardver.......................................................................................................49 10.1.1 Távirányító............................................................................................49 10.1.2 Iránytű.................................................................................................50 10.1.3 Sebességmérő.......................................................................................50 10.1.4 Kijelző...................................................................................................51 10.1.5 Akkumulátor..........................................................................................51 10.1.6 Töltöttség figyelés..................................................................................52 10.1.7 PAL-optika helyettesítése Omnidirectional-rendszerrel...............................52
3
PAL - Commander 10.2 Szoftver.......................................................................................................52 10.2.1 Távolságmérés......................................................................................52 10.2.2 Térképezés............................................................................................54 10.2.3 Számfelismerés......................................................................................54 10.2.4 GPU (Graphics Processing Unit) alapú képfeldolgozás...............................54 11. Irodalomjegyzék.........................................................................................55 12. Melléklet.....................................................................................................58
4
PAL - Commander
5
PAL - Commander
1. Bevezetés Dolgozatunk témája egy olyan autonóm robot megtervezése és kivitelezése, amely egy homogén, gyengén textúrázott környezet figyelembevételével önálló navigációra képes. Kritérium a robot összeállításához, hogy egyszerű, könnyen reprodukálható komponenseket használjon fel, ezzel stabil alapot nyújtva a további, ilyen irányú kutatásokhoz, és fejlesztésekhez, mind hardver, mind szoftver részről. Hosszú távú elképzeléseink közé tartozik ennek a robotnak oly módon való továbbfejlesztése, hogy alkalmas legyen a vakok, gyengén látók mindennapi életükben való segítségnyújtásra, ismeretlen terepen való tájékozódáshoz. Iskolák, közintézetek területén, illetve minden olyan helyen, ahol a vakvezető kutya használata társadalmi okokból nem elfogadható. A robot képes vezetni a látássérült embereket, és egy adott célállomásra eljuttatni. A készített robotnak dinamikusnak kell lennie a környezet változásaival szemben. Egy valós világban alkalmazott robot legalább három fő komponenssel rendelkezik: szenzor, manipulátor, feldolgozó egység. A fent vázolt célokat szem előtt tartva a robot elkészítéséhez e komponensek az alábbi módon valósultak meg: Szenzornak PAL optikát használtunk. A Panoramic Annular Lens (PAL-optikás) 360°ban látó kamerával felszerelt robotok előnye a hagyományos szenzorokkal ellátott robotokkal szemben, hogy elegendő egy optikai érzékelő a környezet feltérképezésére. A kapott kép panorámikus körkép, mely minden irányba, végtelenbe éles képet mutat. Manipulátornak egy RC modell kocsit alkalmaztunk, mely nemcsak könnyű, és költséghatékony az egyszerű átalakíthatósága miatt, hanem gyors helyzetváltoztató képessége is szerepet játszott. A vakvezetés eléréséhez még nem elegendő, kis mérete miatt, de alapot nyújt a koncepció létrehozásához. A célhoz nagyobb, robusztusabb gépre van szükség, melyre egy „pórázt” felszerelve képes erőt is kifejteni az őt követő egyén karjára, valamint biztonságos sebességgel képes őt vezetni. Feldolgozó egységnek PC-t használtunk. Mivel a feldolgozó egységet nem hardver, hanem szoftver szinten valósítottuk meg, ezen komponens reprodukálásához sem szükséges semmilyen bonyolult eszköz –ellentétben a hardveres megvalósítás pic-égető, stb. eszközigényével.
6
PAL - Commander
2. Irodalomkutatás 2.1 A robot fogalma A robot kifejezésen olyan eszközt, berendezést értenek, amely az ember fizikai és/vagy szellemi munkájához hasonló tevékenységet végez, tehát eleget kell tenniük az intelligencia bizonyos alapfeltételeinek (érzékelés, információ-feldolgozó kapacitás, tudás illetve emlékezet, tanulási képesség és döntéseken alapuló közlési - cselekvési képesség, stb.). Főbb követelmények és jellemzők: -
rugalmas újraprogramozhatóság
-
több szabadságfokú mozgáslehetőség
- anyagok, berendezések, feladatok végrehajtása
szerszámok
mozgatására
vagy
különböző
A robotok generációk szerint csoportosíthatók intelligencia-szintjük (I-III generációs robotok), a külső megjelenésük (robotkarok, mobil robotok), pályavezérlés típusa szerinti (PTP vagy CP), valamint az alkalmazási területük alapján. Míg az I. generációs robotokat egyszerű, alacsony szintű programozás és műveleti képesség jellemzi, addig a II. generációs robotok a környezetet érzékelők segítségével vizsgálják és tevékenységüket a vett jelek alapján a pillanatnyi szituáció figyelembevételével módosítani tudják. Feladataikat magas szintű robotprogramozási célnyelven lehet meghatározni. A III. generációs robotokban kapnak nagyobb szerepet a mesterséges intelligencia elemei. Az érzékelőktől származó jeleket feldolgozzák, a magukról és a környezetről tárolt modellt képesek intelligens módon, önállóan módosítani, képesek információ kiválasztására és kombinálására. Megjelennek az önálló viselkedési algoritmusok és a döntési rendszerek. E generáció működésére az összetett tevékenység és a feladatok magas szintű, általános megfogalmazása jellemző. [30] A mobil robotok helyváltoztatására két alapvető koncepció alakult ki. Az egyik csoportot a kerekes robotok alkotják. A kerekek számát tekintve léteznek három-, négyvagy hatkerekű megoldások. Általában a kisebb akadályok átlépésére sem képesek, az akadályokon inkább a kikerülés taktikájával igyekeznek túljutni. Az átlépés lehetőségének hiányát ellensúlyozza, hogy a kerekes robotok jóval mozgékonyabbak és fürgébbek lábakon közlekedő kollégáiknál. A mobil robotok másik csoportjába a járó robotok tartoznak. E csoporton belül megkülönböztettünk lépegető és mászó típusokat attól függően, hogy közel vízszintes terepen, vagy meredek falakon végzik a feladatukat. A projekt készítése során kerekes mobil robotokat (RC-autókat) használunk fel. Célunk a minél nagyobb megbízhatóság és mobilitás megteremtése, ezért a későbbiekben ki kívánjuk terjeszteni a vezérelhető eszközök típusait, annak érdekében, hogy jobb navigációt érjünk el.
7
PAL - Commander
2.2 A robotok csoportosítása helyváltoztatási képességük alapján A mobil robotok helyváltoztatására négy alapvető koncepció alakult ki.
2.2.1 Kerekes robotok Legegyszerűbb választásnak egy távirányítós autó tűnik, mely szintén többféleképpen csoportosítható: 1. Motor szerint lehet benzinmotoros, illetve elektromotoros. Mi az elektromotor mellett döntöttünk. 2. Mérete szerint kétféle csoportosítás lehet. Egyik a méretarány szerinti. Ha szem előtt tartjuk a gyors irányváltoztatás, mozgékonyság szerepének fontosságát, a kis hely miatt, akkor egyértelműen az 1:20, és kisebb méretű autó az ideális választás. Ha nagyobb helyünk van, akkor kellemesebb megoldás lehet a nagyobb, 1:10 méretarányú autó. Másik csoportosítás lehet az autó típusa, miszerint személyautó, vagy terepjáró az. Ez utóbbi természetesen nagyobb. 3. Irányíthatóság szerint. Léteznek olyan típusok, melyek maximum 8 fajta irányban irányíthatóak (nevezzük ezeket RC-nek), illetve olyanok, melyek úgynevezett precíziós irányíthatósággal rendelkeznek (nevezzük modell RC-nek). 4. Kommunikációs csatorna szerint. Vannak melyek oda-vissza kommunikációra képesek, illetve vannak, amelyeknél az autó csak fogadni képes a távirányító jeleit. Előzőhöz persze ehhez megfelelő távirányító is kell, mely komolyabb, így meglehetősen drága is.
2.2.2 Járó robotok A mobil robotok másik csoportjába a járó robotok tartoznak. E csoporton belül megkülönböztettünk lépegető és mászó típusokat attól függően, hogy közel vízszintes terepen, vagy meredek falakon végzik a feladatukat. Ezen robotok megvalósítása jóval nehezebb, mint a kerekes típusoké, illetve felhasználható lenne már kész koncepció is, például az Aibo robotkutya. Hasonló hazai fejlesztésű projektek:
2.2.2.1 EXPLORATES II (1997-1998) [1] Az EXPLORATES II egy négylábú robot, mely elsőként használta a PAL optikát roboton. A robot demonstrációs, oktatási célokra lett kifejlesztve. A PC oldali vezérlőprogram egy DOS környezet alatt futó grafikus szoftver, mely Borland C nyelven íródott. Az útkeresési stratégiáját egy Back Propogation típusú neurális hálózattal valósították meg. A robot 5 db. ATMEL 89C51-es mikrovezérlővel rendelkezik, mely négy (lábanként egy) a lábak vezérléstét irányítja, az ötödik pedig központi vezérlő, amely összehangolja a processzorok munkáját, illetve a PC-vel tartja a kapcsolatot soros kommunikációs vonalon. 8
PAL - Commander
2.2.2.2 FOBOT (2002-2003) [2] A FOBOT egy hatlábú robot, mely szintén PAL optikával van ellátva. Célja, hogy egyenetlen terepen gyorsan, és stabilan haladjon. A lábakat mozgató motorokat PIC16F873-as mikrovezérlő vezérli. A roboton GPS vevő biztosítja a durva helyzet-meghatározáshoz szükséges koordinátákat. A PC-n térképen követhetjük a mozgást és adhatunk meg célkoordinátákat, vagy bejárandó útvonalat. A PAL optikával készült kép estében – már korábban feltérképezett objektumok ismeretében – az élek megtalálása és azonosítása után háromszögeléssel számítható ki a robot pozíciója. A felhasználó ezek mellett valós időben kiterített PAL optikás képen is vizsgálhatja a robot környezetét. A két robot összehasonlítása: Test
Szélesség
Magasság
Explorates II
400 mm
FOBOT
305 mm
Haladási sebesség
Hossz
Súly
270 mm
600 mm
2,5 kg
400 mm/perc
134 mm
432 mm
3,2 kg
3,2–5 m/perc
1. táblázat: EXPLORATES II és FOBOT összehasonlító táblázata
A táblázatból egyértelműen látszik, hogy a FOBOT mérete kisebb, és nagyobb sebességre képes. Az Explorates II előnye a FOBOT-hoz lépest, hogy képes oldalirányú mozgásra is, percenként 90 mm, ez a tulajdonság a váznak kialakításbeli különbségéből adódik.
2.2.3 Lánctalpas, gumitalpas robotok Ezeknek előnye hogy csupán két kerék meghajtásával (nagyobb típusnál több) akár helyben is képes megfordulni. Ha beltéri használatra szeretnénk, akkor a gumitalpas megoldás tűnik megfelelőnek, így a padlózatot, szőnyeget nem roncsolja a lánctalp.
2.2.4 Repülő robotok Ezt a megoldást már a fejlesztés kezdő szakaszában elvetettük, célkitűzéseinkkel ellentétben nem költséghatékony, másrészt pedig elsődleges célunk beltéri navigáció. A projekt készítése során kerekes mobil robotokat (RC-autókat) használunk fel. Célunk a minél nagyobb megbízhatóság és mobilitás megteremtése, ezért a későbbiekben ki kívánjuk terjeszteni a vezérelhető eszközök típusait, annak érdekében, hogy jobb irányíthatóságot érjünk el.
9
PAL - Commander
2.3 A robot navigációja Pálya- és útvonaltervezésnél megkülönböztetünk durva és finom pályatervezést. Durva pályatervezés esetén a cél a pálya főbb sarokpontjainak megtalálása, míg finom pályatervezéskor (a durva pályatervezés eredményét felhasználva, két sarokpont között) a lehető legfinomabban lebontva kell leírni a bejárandó utat. A pályatervezés készülhet előre ismert, részben ismert, vagy teljesen ismeretlen környezetet feltételezve. Az akadályok elhelyezkedése lehet statikus, vagy időben változó. Ha előírásaink vannak az útvonalon kívül még az időbeli ütemezésre is, trajektória tervezésről beszélünk. Más szempontokat figyelembe véve, szintén megkülönböztethetünk valós időben történő és egylépéses pályatervezést aszerint, hogy az útvonaltervezést csak egy egységnyi távolságra végezzük el, majd rögtön végrehajtjuk, vagy az egész útra előre megtervezzük az útvonalat, s azt a végrehajtás során már nem módosítjuk. A munkatérben elhelyezkedő objektumokat két csoportba sorolhatjuk: céltárgyak és akadályok. A pályabejárás, vagy navigáció során a megtervezett pályát követjük a robottal. Legnagyobb problémát a robot tervezett és realizált helyzete közötti különbség jelenti. Megoldást a nagyszámú környezeti szenzor által szolgáltatott adatok összehangolt feldolgozásával érhetünk el. Annak érdekében, hogy a robot valós környezeti viszonyok között bejárja az előírt pályát elengedhetetlen a pontos helymeghatározás. A helymeghatározásnak megkülönböztetik statikus és dinamikus változatait. Az első esetben a robot szenzorjelek által megadott pozícióját hasonlítják a lehető legpontosabban össze a környezeti modell előzetesen ismert leírásával. A dinamikus helyzet-meghatározás ezzel szemben verifikálás jellegű: a korábbi szenzorjellemzők által szolgáltatott (helyzet, sebesség, stb.) információkból kalkulált helyzetnek és a mozgó robot aktuális állapota közötti különbséget újra és újra ismétlődően kiértékelik, és ha kell, módosítják az adatokat. Figyelembe véve a szenzorjelek pontatlanságát, bizonytalanságát a helyzetmeghatározás gyakran útjelzők használatával történik. Az útjelző a környezet karakterisztikus fizikai jellemzője, amelyet a robot érzékel és a nyert információt a helyzetének pontosítására, vagy esetleg az útvonal követésének ellenőrzésére használ. A robot navigálás során az útjelzőtől útjelzőig mozog. A korábbi kutatások során az útjelzőket binárisnak adatként kezelték, attól függően, hogy érzékelhető-e, vagy sem. Az újabb kutatások azonban figyelembe veszik, hogy a robot és az útjelzők egymáshoz viszonyított helyzetétől nagyban függ a kiértékelés. A mobil robotok főbb jellemzője a helyváltoztatási képesség. Ezt a navigációs rendszere által teheti meg, mely alapulhat térképkészítésen vagy térkép nélkülözése mellett. A projekt jelenlegi állapotában nincs beépített térképezés. A pozicionálásához kellő adatokat a robot kamerakép segítségével a környezetéből veszi. A helyzetének a pontosításához a környezetben elhelyezett jelzések (pl. különböző színintenzitású objektumok, leragasztott csík) adhatnak segítséget. Ezáltal már előre becsülhető egy esetleges akadály vagy kanyar, így irány- és sebesség változtató tényezőként is viselkedhet.
10
PAL - Commander
2.4 Térképezésen alapuló navigáció megvalósítása Két eset létezik. Vagy előre fel van térképezve a robot környezete, vagy a robotnak kell felépítenie saját környezeti térképét. Ahhoz hogy biztos információkat nyerjünk a robot környezetéből a kamerán kívül további szenzorok beépítése ajánlott (lézeres vagy ultrahangos távolságmérők). A legmegfelelőbb helyzet-meghatározó eszköz a GPS. Az utóbbi idők robotos fejlesztései szinte csak erre az eszközre hagyatkoznak térképezés szempontjából. A ljubljanai egyetemen a ViCoS (Visual Cognitive Systems Laboratory) által készített CogVis projekt [3] gráfmodellt épít a térképezéshez.
2.4a ábrák: A 3D-s modell eltárolásra kerül, egyre jobban pontosítva az ideális útvonalat [3]
2.4b ábrák: A robot helyzetének változásával a GPS támogatású rendszer felépíti a környezeti 2 dimenziós térképet [3]
Utóbbi időben kísérletek helyzetmeghatározásra is.
folynak
WLAN
11
hálózatokkal
történő
háromszögelő
PAL - Commander
2.5 GPS rendszerrel ellátott mobil robotok térképezésének menete A navigálás négy lépése: −
érzékelők lekérdezése látás alapú navigálásnál a kamera kép lekérdezése
tájékozódási pontok megtalálása – helyi térkép összeállítása: él detektálás, szűrés, finomítás −
a mért és a várt adatok összeegyeztetése, tájékozódási pontok azonosítása az adatbázis felhasználásával −
−
pozíció kiszámítása
A térkép alapú navigáció követelményei: legyenek elégséges stacionárius, könnyen megkülönböztethető jellemző vonások, melyek az illesztésnél felhasználhatók −
pontosság: a feladattól függően az érzékelő térkép legyen elég pontos a felhasználáshoz −
−
jelentős mennyiségű érzékelési és feldolgozási energia álljon rendelkezésre.
A térképpel szemben támasztott követelmények összefoglalása: meg kell adnia a szükséges információkat és eljárásokat is a környezetben a robot pozíciójának és állásának becsléséhez −
a pályatervezéshez, az akadályelhárításhoz és egyéb navigációs feladatokhoz szükséges információkat is könnyen lehessen szerezni −
− a robot által használt térábrázolási rendszer típusa nyújtson módot arra, hogy következetesen beépítsük az újonnan érzékelt információkat a meglévő világmodellbe
A térképkészítéshez szolgáló érzékelői feldolgozás három fő lépése: −
jellemző vonások kinyerése a nyers érzékelői adatokból
−
a különféle érzékelő típusoktól származó adatok összevonása
− egy környezeti modell automatikus létrehozatala az absztrakció különböző fokozataival.
12
PAL - Commander
2.6 További hasonló projektek 2.6.1 Evolution Robotics – ER1 „Az Evolution Robotics tavaly piacra dobott ER1 „személyi robot-rendszere” nem túl látványos jelenség: kerekes alumíniumvázra erősített laptop, fogantyús karral, USB digitális kamerával. Ám (tervezői szerint) az új generációs félautonóm robotok legelső példánya volt. Elsősorban egy speciális, több cselekvést betanító, idegen környezetben történő zökkenőmentes mozgást biztosító szoftver miatt. Maximum tízezer digitális képet tárol, s bonyolult optikai-számítástechnikai műveletsorokkal érzékeli a körülötte lévő világban történő helyváltoztatásokat. Azaz, ellentétben elődeivel, nem „vak”, és nem rohan egy széknek, miután tíz centivel odébb toltuk. Egyszerű hangutasításokra indul útjára – a tanulási folyamatot követően, természetesen. Ahhoz, hogy megtalálja például a 2.6.1 ábra: Az konyhát, előbb oda kell vinnünk, lefényképeztetjük vele a intelligens laptop robot helyiséget, elmondjuk neki, mi van a fotón, raktározza, majd, ER1 szükség esetén (percenkénti harminc állókép sebességgel) feldolgozza. Az olcsó robotplatform fejlett operációs rendszere miatt egyedi, mely egyben az otthoni barkácsolók dolgát is megkönnyíti. Bill Gross, az egyik alapító a Netscape böngészőhöz hasonlítja Evo Vision szoftverüket: előbbi az Internetet tette tömegesen hozzáférhetővé, utóbbi a robotokkal teszi ugyanezt. Másrészt –(egyelőre kezdetleges) beszédfelismerő rendszerének, digitális kamerájának, mobilitásának köszönhetően – a gyógyászatban is hasznát vehetik robotunknak: ágyhoz viheti a mozgásképtelen betegek gyógyszerét, stb. (Szakértők véleménye szerint, sokkal fejlettebb, többre képes a Sony legendás AIBO-jánál.)”. [4]
2.6.2 CameraCar – SR04 „Az 1995-ös (elenyésző mennyiségű Lego-elemet tartalmazó) CameraCart távirányító segítségével működteti az (emberi) operátor. A vezető szemben ül a televízió-rendszerrel, székéből távirányítja a gépet. Az eredeti modellt fix, előre és kissé lefelé néző kamerával látták el, ami Andersonék amatőr, házukban megrendezett bajnokságain ugyan elegendőnek tűnt, viszont a szabadtéri megmérettetéshez módosításokat kellett véghezvinniük rajta. Miután megtették, a kamera vertikálisan 110 fokos ingásra, horizontálisan 360 fokos forgásra lett képes. Mindez (egyszerű és egyirányú) kommunikációt is lehetővé tesz: feje biccentésével igent, rázásával nemet jelez a robot.” [5] 2.6.2 ábra: A gyors mozgású CameraCar
13
PAL - Commander
2.7 Teljeslátószögű (omnidirectional) rendszerek 3 alapfajtája van a teljeslátószögű érzékelőknek:
2.7 ábra: RingCam kamerarendszer [6] −
több képből állítják össze
−
speciális lencsét használnak fel (PAL-optika)
−
konvex tükröket alkalmaznak
2.7.1 Omnidirectional-rendszer A leggyakoribb 360 fokban látó rendszerekben hagyományos kamerával és konvex tükrökkel érik el a teljes látószöget. Előnyük a megfelelő kialakításnál a lehetséges magas felbontás, azonban méretükből adódóan csak nagyobb mobil robotok esetében használják. A teljeslátószögű rendszerekről kielégítő információt az 6. hivatkozásban található oldalon kapunk. A mellékletbe omnidirectionalrendszerek és robotos megvalósításuk képei kerültek.
14
2.7.1 ábra: Különböző visszaverődéses tulajdonságú konvex tükrök [7]
PAL - Commander
2.7.2 The Caboto projekt [7] Az egyik leginspirálóbb írás a témában a Caboto projekt volt, amely az edinburghi egyetemen készült. Omnidirectional rendszert használ, ami azt jelenti, hogy a 360 fokos látószöget domború tükör segítségével érték el. A robot egy komplett, kerekeken guruló számítógépet takar.
2.7.2a ábra: Omnidirectional rendszerrel felszerelt robot [7]
2.7.2b ábra: A mobil robot által bejárt tesztkörnyezet [7]
A robot feladata mesterségesen felépített környezetben (homogén alapon) való akadálykerülő ütközésmentes navigálás végrehajtása. A linuxot futtató számítógép végezte a képfeldolgozást és az irányítást is. A színes képet 3 színcsatornára lebontva és egyesével canny-éldetektálást alkalmazva a 3 képet összeadták és kirajzolódott a környezet kontúrja.
2.7.2c ábra: A robot az élektől való távolságot becsülve kerülte ki az akadályokat.
15
PAL - Commander
2.8 A PAL – optika A világot oly módon ábrázoljuk, amilyennek látjuk, ahogy a retinán a kép kialakul. Ez azt jelenti, hogy egyszerre csak egy kis környezetet vagyunk képesek belátni, mintha egy ablakon keresztül tekintetnénk ki. Ez nem teszi lehetővé, hogy az egész körülvevő teret egy időben lássuk. Ezért a környező teret nem gömbszerűnek, hanem hengeresnek kell tekinteni, azaz központelvű képalkotási (centric minded imaging, CMI) szemléletet kell követni. A központelvű képalkotásnak nevezett megoldás úgy jön létre, hogy a képtérfogatot elvileg először egy képzeletbeli hengerpalástra vetítjük, melynek sugara megegyezik a mindenkori látótávolsággal, majd az egész így kapott vetületet a henger tengelyére merőleges síkra transzformáljuk. Ennek következében olyan körgyűrű alakú kép jön létre, amelyben a gyűrű szélessége megfelel a képalkotás „függőleges” látószögének, míg a koncentrikus gyűrűk változó „vízszintes” térszögeket jelentenek egy adott „függőleges” térszögben. Más szóval, ezek a gyűrű alakú képek a háromdimenziósan látott geometriai viszonyok kétdimenziós vázát szolgáltatják, vagyis a háromdimenziós látótérben fellépő „mélységbe tűnés” jelenségét, a perspektíva érzetet kétdimenziós felületen, egy pontba való összetartás révén érik el. Egy olyan képalkotó tömb jött létre, melynél a képtömböt körülvevő háromdimenziós térről az optika belsejében egy háromdimenziós miniatűr képtérfogat jön létre. [8] A PAL-optika Greguss Pál professzor találmánya (2.8 ábra). A C felület kiképzése és az optikailag a levegőnél sűrűbb anyag gyűjtőlencseként viselkedik (ez a kagyló szemlencséje). A tárgyról a fény az A homorú tükörre vetődik (ez felel meg a szem homorú gömbtükörének), az optikán belül valódi kép keletkezik a B tükör felületén (a kagyló retinájának felel meg). Műszakilag mi nem tudunk a kagyló retinájának megfelelő görbült érzékelő felületet készíteni, ezért a képet egy domború gömbtükörrel vetítjük ki az optikából. A B tükör és a D felület (törés - sűrűbb közegből ritkább közegbe -) miatt virtuális kép keletkezne az optikán kívül. Emiatt az érzékelő felületre vetítéshez még szükséges egy lencserendszer is.
16
2.8a ábra: A PAL- optika szerkezete és működése [9]
PAL - Commander
A körkép egy egyszerű transzformációval perspektivikus képpé alakítható (2.8b) – ez többletinformációt feldolgozás szempontjából nem nyújt. Egy ilyen transzformáció például, ha a képen egyre nagyobb sugarú köröket veszünk: a kiterített körkép a körön lévő pixelek kiválasztásával áll elő. Körkép[x,y] = eredeti [centery + d * cos(i*2), centerx + d * sin(i*2)] Ahol centerx, centery az eredeti kép középpontja, és „i” 0 – 360 intervallum közé eső ciklusváltozó. PAL-optikából érkező képek esetében a kép közepén elhelyezkedő “holttér” képfeldolgozási szempontból nem rendelkezik információval, elhagyható.
2.8b ábrák: Az eredeti, és a hozzá tartozó kiterített kép
A HPAL (Humanoid Panoramic Annular Lens) egy olyan optika, ahol a PAL optika tengelyében lévő tükröző felület egy részét eltávolították. Így keresztül nézhetünk a leképező tömbön, a panorámikus leképező képesség bármiféle csorbulása nélkül. Így ha egy leképező lencsét helyezünk el az optika elé, akkor a gyűrűs kép közepén lévő holtteret is képpel lehet kitölteni. [10] A feltalálót NASA díjjal jutalmazták (1989), azóta kutatások folynak az optika széleskörű felhasználására az orvostudományban, a hadászatban, és űrkutatásban is. A NASA 1997-es SEDSAT-1 programja keretében is megjárta a Titan nevezetű holdat, de beépítik kisebb műholdakba is. Az űrkutatás mellett katonai alkalmazásokban is szerepet játszik a PAL-optika, jelenleg mind a NATO, mind különböző japán cégek nagy érdeklődést mutatnak iránta.
17
PAL - Commander
3. A rendszer megvalósítási elvei A robot vezérlése a PAL-optikás kamerán keresztül kap információkat a környezetről. A kameráról átküldött videó-jel feldolgozását a számítógép végzi, és az általa nyert információkból a program a soros portra illesztett távirányítón keresztül automatikusan vezérli a robotot. Tervünk önálló, körpályán való ütközésmentes navigáció, akadálykerülés, vonalkövetés, objektumkövetés megvalósítása. A PAL kamerától gyűjtött információfeldolgozás egyszerűsége abban rejlik, hogy a kapott kép nem szokványos, hanem panorámikus körkép. Ez a kép egyszerű transzformálással szokványos képpé alakítható, azonban a körgyűrű kép feltérképezésnél előnyös. A képi adatok rádiójelen keresztül továbbítódnak a számítógépbe, azokat feldolgozva információkat nyerünk ki az irányítás részére, melyet egy külön modul végez. Fontos szempont a fejleszthetőség, további lehetséges modulok beépítése, választható navigációs viselkedési forma. Ezzel a technikával lehetséges a gyorsabb, versenyszerű mobil robot létrehozása, de a lassabb, biztosabb haladás is megvalósítható.
3. ábrák: Két példa a kezdeti megvalósítandó feladatra (képek a Computer Controlled Car Racing oldaláról [11])
A vezérlést végző szoftver először Borland Delphi fejlesztői környezet alatt készítettük el, majd korszerűségi okokból átültettük C#, .NET környezetre. A rendszerek fejlesztése Microsoft Windows rendszeren történt, de az utóbbi könnyen átültethető más operációs rendszerre is. Ennek jelentősége abban rejlik, hogy a feldolgozáshoz nem szükségszerű asztali számítógépet használni, kiváltható olyan mobil (jellemzően CE) eszközökkel, amelyeken van C# / .NET futtatókörnyezet. Az alábbiakban ismertetésre kerül a rendszer konkrét megvalósítása.
18
PAL - Commander
4. Hardver elemek A projekt hardveres alkotóelemei: −
a távirányítású kisautó
−
a távirányító
−
a kamera (lencsével és PAL- optikával)
−
a PC + digitalizáló kártya
4.1 Autók A rádió-távirányítású kisautó szerepe a mobil robot alapját képezi. Erre a elemre van felerősítve a kamera, és ezen találhatóak a megfelelő energiamennyiséget hordozó akkumulátorok. Azért, hogy a projekt számára a legelőnyösebb, költségkímélőbb megoldást hozzuk, ezért olcsó, mégis nagy mobilitással rendelkező távirányítós RC autók mellett döntöttünk. A projekt készítése során két kisautóval dolgozunk. Nevezzük ezeket a későbbiekben RC, és Modell RC-nek. Először az RC autót teszteltük és készítettük el az irányítást, később szükségessé vált a Modell RC kifejlesztése is. A rendszer szoftver része hasznosítható mindegyik modellhez, a kommunikációs hardver kicserélésével.
4.1.1 RC autó Az RC autó kis mérete miatt fordulékonyabb. Hátránya: hogy csak 8 irányt lehet vezérelni. Az autó hat irányban képes helyváltoztatásra, és helyben a balra-jobbra kormányzást is támogatja. Ha az energia kevés, vagy ha gyengül az elem a balra-jobbra irányváltoztatás nehézkesen megy, a kerék nem fordul el teljes mértékben. A kiskocsi 4 darab 1.5V-os ceruzaelemmel működik, viszont a rendelkezésre álló ceruza-akkumulátorok 1.2V feszültséget adnak. Ezért töltöttségtől függően 1 vagy 2 akkuval kipótolva nagyobb tehersúly mellett is megőrzi gyorsulását és kanyarodókészségét.
4.1.1 ábra: RC autó
4.1.2 Modell RC autó Kétféle Modell RC - t teszteltünk. 1:10, és 1:14 típusok között a különbség csupán méreteiben nyilvánul meg, ebből adódóan más és más a kanyarodási tulajdonságuk. Egyik előnye az RC -hez képest, hogy állítható az autó, és a távirányító kommunikációs frekvenciája, így több hasonló Modell RC–t lehet egyidejűleg irányítani. 19
PAL - Commander
Másik fontos előnye a precíziós irányítás, hogy az irányt, és a sebességet tetszőlegesen lehet állítani. Ha a „pisztoly” távirányító „ravaszát” kis mértékben húzom, lassan megy, ha nagy mertekben, akkor gyorsabban. Ezáltal sokkal pontosabb navigációt lehet elérni. Mindenféle plusz súlyterhelés nélkül 20-30km/h-s végsebességre képes. Két motorral rendelkezik, a meghajtómotor, és a szervo motor a kanyarodáshoz. 4.1.2 ábra: 1:14 -s méretarányú
Az autó 9.6V –os tápellátással működik, ami Modell RC autó a két motor működéséhez kell. Ha az akkumulátor merül, a motorok működése lelassul. A kanyarodás lassabb, az előre-hátramozgási irány nehézkesebb lesz. Az akkumulátor 8 cellás, 650 mAh. Szükség esetén pótolni lehet 8db ceruzaakkumulátor soros összekötésével.
4.2 Távirányítók 4.2.1 RC távirányító A távirányító 9V-os elemmel működik. A vezérlés párhuzamos porton keresztül történik. Ha az elektronikus kapcsolóáramkörök megfelelő módon vannak bekötve, akkor megfelelő vezérlőjel hatására a bemenetük és kimenetük között kis ellenállásértékekkel jellemezhető kapcsolatot létrehozzák. Hardverfeltételek: −
kisméretű NYÁK panel, ellenállások
−
25 pólusú párhuzamos porti kábel csatlakozóval
−
optocsatoló (4.2.1a ábra)
−
elektronikus kapcsoló áramkör (CD 4016) 4.2.1a ábra: CNY 74-4
Jel-átalakítási célokra tökéletesen megfelel az optocsatoló optocsatoló, annak is a 4 kapuból álló változata, mivel 4 vonalon érkeznek a jelek a PC-től (előre, hátra, jobbra, balra). Az optocsatoló működése során a bemenetére érkező pozitív feszültség hatására a fotodióda kinyitott állapotba kerül és fényt bocsát ki. Az áramkör másik oldalán található fotótranzisztor a fény hatására kinyit, azaz a kollektora és emittere között szinte rövidzár képződik, a kollektorán jelen levő feszültség kijut az emitterére. Jól látható, hogy az optocsatoló be- és kimenete között nincs galvanikus kapcsolat, tehát ezzel a leválasztás megoldható. Az előzőekbe már szerepelt, hogy a párhuzamos port maximális kimeneti árama 20mA. Ezen a 20mA-es határon belül maradás érdekében biztosítani kell, hogy az optocsatoló bemeneti árama maximum 20mA legyen.
20
PAL - Commander
Ez egy előtét ellenállás beépítésével oldható meg, melynek értéke az Relőtőt=Umax/Imax képlettel számítható. Ahol Umax a párhuzamos port maximális kimeneti feszültsége, ami 5V , Imax pedig az előbb említett 20mA. Ebből az ellenállás értéke minimálisa, szabványérték szerint: R=270Ω.
4.2.1b ábra: A komplett átalakítás megvalósítása
4.2.1c ábra: A párhuzamos portra kötött távirányító
A teljes áramkör működése tehát: a PC felől érkező vezérlőjel aktív magas szintjének hatására az optocsatoló a tápfeszültségnek megfelelő nagyságú feszültséget kapcsol az elektronikus kapcsoló áramkör megfelelő vezérlőbemenetére, ezáltal a kapcsolóhoz tartozó két végpont, amelyek a távirányító megfelelő pontjaira csatlakoznak rövidre záródnak. A távirányító működésbe lép és kibocsátja a megfelelő jelet a mobil robot felé, minek hatására a robot a megfogalmazott parancs szerinti műveletet végrehajtja.
4.2.2 Modell RC távirányító A távirányító 9V-os elemmel működik. Hatótávolsága erősen függ az elem töltöttségétől. Teljes kapacitású elemmel 30–40m hatótávolság érhető el. Az irányítás 2db potenciométerrel történik. Az egyik az előre-hátrahaladási irányok vezérléséhez, a másik a jobbra-balra irányokhoz szükséges. Azt kell megoldani, hogy ne manuálisan, hanem PC-ről lehessen a vezérlő utasításokat kiadni. Erre több lehetőség adódik, egyik a digitális potenciométer alkalmazása, a másik a PIC mikrokontroller családja, emellett döntöttünk. A PIC18F1320 mikrokontroller előnye, a kis mérete, és a többszintű megszakításkezelés.
21
PAL - Commander
Az autó két motorral rendelkezik, a meghajtómotor, és a szervomotor a kanyarodáshoz. A távirányító ezeket a motorokat vezérli. A távirányító elvi kapcsolási rajzából a lányeges részlet a 4.2.2 a ábrán látható. Mivel tranzisztorok alkalmazásával lett megépítve, biztosra létezik benne beavatkozási pont. Ez a közös pont a D1, D3, és D2 diódák anódja. Ezt vezérli a Tr1, és Tr2 tranzisztor.
4.2.2a ábra: A távirányító elvi kapcsolási rajza (részlet)
A vezérlőimpulzusok periódusideje 15ms. Az első impulzust a Tr4 tranzisztor adja, és indítja Tr1 időzítését, amit a távirányító irányvezérlő potenciométere befolyásol. Ha lejárt az idő, akkor jön a második impulzus, ami a Tr2 tranzisztor időzítését indítja és annak lejártát a sebességvezérlő potenciométer befolyásolja. Ha ez az idő is lejárt, akkor jön a harmadik impulzus. Ezt a periódust kell leutánozni a mikrokontrollerrel. A 4.2.2 b/a ábrán a Tr1, Tr2 tranzisztorokhoz tartozó idő egyforma. Az RC első kerekei egyenesen állnak, illetve sebessége 0. A 4.2.2b/b, 4.2.2b/c ábrákon a Tr2 időzítését változtatva a tolatást, illetve a sebesség maximumát állítjuk be. Ezekkel az impulzusokkal kell a mikrokontroller segítségével a közös pontra csatlakozva a távirányítót vezérelni. A PIC programjában egy Timer-rel megszakítást okozunk 15ms-enként. A megszakításkor kiadjuk az első impulzust. Ezzel "egy időben" 4.2.2b ábra: Közös ponton mért vezérlőjel másik Timer-t indítunk egy olyan számláló értékkel, amit a PC-ről kapott vezérlőérték határoz meg (akár lehet ugyanaz is). Ha lejárt ez a számláló, akkor kiadjuk a második impulzust is, miközben a számlálót újraindítjuk a következő vezérlőadattal. 22
PAL - Commander
Mikor ez lejárt, akkor kiadjuk a harmadik impulzust is, és kilépünk a megszakításból. Adatok áttöltésére a PC felől kb. a 15ms időnek a fele áll rendelkezésre. Ez talán elég, hiszen csak néhány bájtot kell átküldeni (irány, sebesség = 2bájt). Tehát az utolsó impulzus után a PIC megszólítja a PC-t. Időt ad neki hogy válaszoljon. Ha időn belül jön válasz, akkor az új adatokkal feltölti a vezérlőadatokat tároló regisztert. Ha nem jön válasz, akkor a régi adatokat veszi aktuálisnak. Az idő, amit adunk a válaszra kb. 3-4ms, mert utána az adatokat kell letölteni, eltárolni, mindezt a 7,5ms-on belül, utána jön az újabb megszakítás. A PIC használatához szükséges elvi kapcsolási rajz a 4.2.2c ábrán látható.
4.2.2c ábra: Kiegészítő kapcsolás elvi rajza
A helyes működéshez az 4.2.2a ábrán D1, D3-nak jelölt diódákat a közös pontról le kell választani és helyette bekötni a 4.2.2 c ábrán D1-nek jelölt új diódát. Továbbá a C4 kondenzátort is le kell választani a két dióda (D2, D4) közül. E két diódának maradnia kell, mert feszültségszintet állítanak be a közös ponton!
23
PAL - Commander
A PC soros porton keresztül kommunikál a PIC-kel. A soros szabvány (RS232) nem TTL szintű jeleket határoz meg, ezért szintillesztéshez MAX232 IC-t kell használni. Előnye, hogy 5V-os feszültséggel kell táplálni. Ez azért előny, mivel a mikrokontroller is 5V-al működik. Az 5V-ot a 7805, a távirányító 9V-ját a 7809 IC-k állítják elő a 12V-ból. A 4.2.2c ábrán Tr1-el jelölt tranzisztor kollektorára rá kell vezetni a 9V-ot, 1k-s ellenálláson keresztül, mert különben a tranzisztor lezártakor a kondenzátor nem sülne ki. A kondenzátor közös pont felőli részén pozitív a feszültség, a tranzisztor zárt állapotában az ellenállás szintén pozitív feszültséget kelt a kondenzátor ezen oldalán is, ezzel az kisül, vagy átpolarizálódik, mert 9V-nál kevesebb a feszültség a közös ponton. Ha jön az impulzus, akkor a tranzisztor kinyit, és „rásüti” a kondenzátort a közös pontra, amitől ott egy negatív impulzus keletkezik. A távirányítóhoz szükséges 9V-ot az R4 ellenállás elől lehet kinyerni.
4.2.2d ábra: A vezérlés blokkvázlata
A panelra kerül még egy RJ11 6/4-es csatlakozó, ami a soros porthoz való csatlakozást segíti elő. A PIC processzor működéséhez 5V egyenáram szükséges. Ennek biztosítása külső tápegységgel történik. Szükség van még egy stabilizátor áramkörre is, hogy ne legyen feszültségváltozás. Ezen cél ellátására a 7805-ös IC szolgál.
24
PAL - Commander
4.3 Kamerák Manapság számos területen alkalmaznak képalkotó eszközzel felszerelt számítógépes rendszereket. A célterület igényeitől függően használhatunk egy vagy több kamerát, mely a felhasználás módjától függően lehet rögzített, vagy mobil eszköz részeként mozgó. Általánosságban elmondható, hogy a gyakorlati alkalmazásukhoz és széleskörű elterjedésükhöz szükséges hardveres feltételek, azaz a kellő teljesítmény csak az utóbbi évek rohamos fejlődésének köszönhetően állnak rendelkezésre. A projekt készítése során alkalmunk volt számos kamera tesztelésére. A projekt korábbi szakaszában USBkamerával történt a képátadás, ami egyrészt előnyt, másrészt hátrányt jelentett. Előnyei közé sorolható az egyszerű csatlakoztatás és nagynak számító 640x480-as felbontás 20 képkocka/másodperc mellett, azonban hátránya a gyenge fényérzékenység kiütközött tesztelésnél, mikor USB hosszabbítás mellett a képen átadott zaj jelentősen megnövekedett. Ez a képelemzésnél már olyan szinten rontotta a végeredményt, hogy az „egyszerűbb” CCD-kamera – digitalizáló kártya választás tűnt előnyösebbnek.
4.3a ábra: A kamera az RC autóra rögzítve és az általa belátott térrész
A Sony panelkamera fényérzékenysége nagyságrendekkel jobb, mint a tesztelt USBkameráé, ezért rosszabb fényviszonyok közt is aránylag jó képet produkál. Hátránya, hogy alacsonyabb felbontással (352x288 pixel) csak szürkeárnyalatos képet tud közvetíteni. Jelen esetben ez a konfiguráció még nem korlátozza a projektet, mivel a videojel 8bit-es átalakításra kerül a képfeldolgozás alatt. A kimenő videojel RCA-RCA kábelen keresztül fut a digitalizáló kártyába. Jelenleg vezeték nélküli kamerarendszert használunk, mely képes audio-, és színes (24bites) képátvitelre. A hatótávolsága 20-70 méter, mely nagymértékben függ a leárnyékolás nagyságától és a kamera tápellátását biztosító feszültségtől (8-12 V). A rendszer 2.4 GHz-en működik. A fogadótól RCARCA kábelen kerül a jel a digitalizáló kártya composite bemenetére. 4.3b ábra: A kamera tápellátásához biztosított 9.6V
25
PAL - Commander
A kamera tápellátása egy 9V-os, 200mAh Ni-MH akkumlátor, vagy ha hosszabb kameraidőt szeretnénk elérni, 8db. AA méretű, 1.2V 2000 mAh-ás sorbakötött akkumlátort használunk (4.3b ábra). Míg az RC-nél a kamera rögzítése fix (25cm), addig a Modell RC-nél változtatható magasságú. Ez azért előnyös, mert ha magasabbra állítjuk, akkor nagyobb terület belátására van lehetőség. A szenzor lefelé néz, így bejárandó utat tudjuk vizsgálni. A PALoptika holtterében helyezkedik el a kocsi, ezért annak csak közvetlen környezete látszik.
4.3c ábra: A vezeték nélküli kamera rendszer tartozékai [12]
4.4 Feldolgozó egység Míg a szoftver futtatása Delphi esetén erősen Pc függő, C# -nál nem platformhoz kötött. Bármilyen C# futtató környezetben működőképes, amennyiben a felhasznált könyvtári függvények (vagy velük ekvivalens funkciók) az adott platformon rendelkezésre állnak. Amennyiben PC-t alkalmazunk feldolgozó egységnek, úgy mind a CCD, mind a vezeték nélküli kamerához szükség van egy digitalizáló kártyára. Gazdaságosabb megoldás egy TV tunner beszerzése, és a composite bemenetének felhasználása. Létezik USB tuner is, ami a rendszer kültéri tesztelését (laptop alkalmazásával) jelentősen megkönnyítené. Egyszerűbb implementálás másik rendszerre. [13]
4.4 ábra: USB-tuner, és tartozékai [13]
26
PAL - Commander
5. Szoftver elemek 5.1 Bemutatás A rendszert Borland Delphi környezet alatt kezdtük fejleszteni. Ez elegendő volt a kezdeti igényeknek, valamint egy működőképes prototípus összeállításához. Nagy segítséget jelentett, hogy számos fejlesztői oldalon találtunk megfelelő beépülőket a programhoz. A forráskódot át kellett dolgozni, mivel a program felépítése nehézkessé tette új modulok beépítését. Ezért úgy döntöttünk, hogy az autonomítás megnövelése, valamint a platformfüggetlenséghez való közelebb kerülés érdekében az új verzió C# alatt, .Net környezetben készült. A program készítése folyamán törekedtünk a modularizáltságra, az egyes modulok / funkcionalitás későbbi újrahasznosíthatóságára, valamint – a keretrendszer sajátosságai miatt (ld: interpreted environment -futtatott környezet) - a sebesség optimalizációra. A C# / .Net architektúra előnyei a Delphihez képest: − A tiszta OOP felépítése miatt jobban támogatja az egységek modularizálhatóságát, illetve a komponensek újrahasznosítását
A kész rendszer viszonylag könnyen átültethető mobil (CE) eszközökre, ezzel a robotot teljesen autonóm eszközzé lehet átalakítani. −
A két rendszer hasonlósága: Belső működését tekintve mindkét keretrendszer pipeline elvű. A képek feldolgozása folyamatosan, egymás után történik, a következő feldolgozandó kép mindig a legfrissebb kép, a kameráról. A feldolgozás 20-30 fps, és minden kép átmegy a teljes pipeline-on.
5.2 Delphi fejlesztői környezet Felhasznált komponensek: − TVideoGrabber VCL component for Delphi and C++Builder [14] – videojel beolvasás USB kameráról és digitalizáló kártyáról −
TComPort [15] – soros port kezelés
−
ZLPortIO [16] – párhuzamos port vezérlése
−
Zprofiler [17] – teljesítménymenedzselést tesz lehetővé
Ajánlott programok: ffdshow [18] – a legelterjedtebb codeceket tartalmazó ingyenes szoftvercsomag, mely megfelelő méretű és minőségű felvételek készítésében jelent nagy segítséget (pl. tesztvideó rögzítés) −
27
PAL - Commander
5.2.1 OpenCV [29] Az OpenCV az Intel® Open Source Computer Vision Library rövid neve. Ez egy olyan algoritmusgyűjtemény C ill. C++ nyelvre, melyben több, mint 300 közép- ill. magas szintű API függvénnyel a legnépszerűbb képfeldolgozási és a gépi látás témakörébe tartozó algoritmus került implementálásra. Az Intel® Integrated Performance Primitives (IPP)-re támaszkodva optimális sebességű kódot ad, és legfőbb előnye, hogy készen kapott függvényekkel dolgozhatunk, ami csökkenti a hibalehetőségeket, illetve javít a kód olvashatóságán. Az OpenCV highgui segítségével könnyen olvashatunk be és jeleníthetünk meg ablakban különböző képformátumokat. Ezeket azután valamilyen függvénnyel manipulálva újra kirajzoltathatjuk, akár másodpercenkénti többszöri frissítéssel is, vibrálás nélkül. Ahhoz, hogy Delphi rendszerbe tudjuk integrálni, az Intel Processing Library felhasználására is szükség van, mivel az OpenCV csak a iplpimage képformátummal tud dolgozni. Ehhez szükséges az IPL 2.5 telepítése is.
5.2.2 PALCom keretrendszer A PALCom a szoftver keretprogramja, mely összefogja az összes többi modult. Egyetlen felhasználói felület van, mely tartalmaz minden szükséges állítási lehetőséget.
5.2.2 ábra: Képernyőkép a PAL-Commander szoftveréből a tesztpályáról
28
PAL - Commander
A keretrendszerben kerül sor a bejövő videojelek (USB-kamera, digitalizáló kártya) beolvasására, melyet a TVideoGrabber komponens végez. Ennek segítségével a maximális 25 fps-sel tudunk rögzíteni, emiatt gyorsabb képkezelést végez, mint a Microsoft WDM Capture (15 fps). A feldolgozási pipeline felépítése: A kameráról beérkező PAL optikás képet a keretrendszer fogadja, majd továbbítja az előfeldolgozó (Imagetrans) részére. A szükséges transzformációk elvégzése után az AI modulhoz kerül a már feldolgozott kép, mely a RadioControl modul segítségével vezérli a robotot.
5.2.3 Imagetrans modul Az ImageTrans modul tartalmazza a képfeldolgozási algoritmusokat. A beérkezett videojelet ahhoz, hogy információt nyerjünk ki belőle előfeldolgozásra kell küldeni. Előfeldolgozás, ami a digitális kép létrehozását, leképezési hibáinak kijavítását, és a további feldolgozáshoz kedvező átalakítását (jellemző tulajdonságok kiemelése, zaj csökkentése) jelenti. Olyan eljárásokat takar, amelyek képből képet állítanak elő. Az előfeldolgozás első lépése a kép zajmentesítése. Erre azért van szükség, hogy az éldetektálás elég hatékony legyen, különben a fel-felvillanó pixelek, apróbb intenzitásváltozások a képben is elég nagy arányban ronthatják a detektálás folyamatát. Ezek a zajok többnyire a rádiójeles továbbításból származnak, azonban a tesztelt USBkameránál is hasonló volt a helyzet hosszabbításos(4m) megoldásnál. Megoldásként különböző szűrőket (gauss, medián) és closing(zárás) algoritmusokat használunk. Ezekkel a nagyobb pixelintenzitásváltozások kiküszöbölhetőek. Ezután tovább lehet küldeni a képet a következő feldolgozási szintre. Az információkinyerés számunkra legfontosabb eleme az éldetektálás. Számos algoritmus beépítésre került. Robinson, kirsh, laplace, prewitt, roberts, sobel és SUSAN élkeresést alkalmazva különböző kimeneti értékeket(képet) produkálva.
5.2.3.1 Képfeldolgozási algoritmusok Morfológiai szűrők: erózió: az ablak pixeleiből vesszük a legkisebb értékűt dilatáció: az ablak pixeleiből vesszük a legnagyobb értékűt opening: először egy erózió, azután egy dilatáció algoritmus lefuttatása closing: az opening algoritmus fordítottja, először dilatáció, azután erózió.
a) A sobel maszkja
b) A prewitt horizontális és vertikális maszkjai
c) Kirsh maszk
d) Robinson maszk
5.2.3.1a ábrák: Kontúrpont kereséshez használt maszkok: a roberts, sobel, kirsh és prewitt
29
PAL - Commander
5.2.3.1b ábrák: A zajszűrt kép jelentős mértékben javíthatja a későbbi detektálás eredményességét.
A closing szűrőt a sötétebb részek megnagyobbítására, valamint a felvillanó zajok eltüntetésére használjuk. Először a képre PreClosing néven zajszűrést, majd másodlagosan a már éldetektált képre végezzük el PostClosing néven. A program képfeldolgozási algoritmusait a főablakban lehet állítani. Jelentős kiterjesztés előtt áll, hiszen az OpenCV utasításkészletének beépítésével jelentős sebességnövekedést lehet elérni a szűrések és PAL-képes tranzícionálás esetén is. A kifeszített panorámakép csak esztétikai szempontból került a programba, feldolgozás hatékonyságát nem befolyásolja. Színmélység változtatás: nagy kontrasztú környezet esetében hatásos lehet éldetektálással párosítva. Binarizálással (2 bit) is hatékony lehet.
5.2.3.1c ábra: Az ImageTrans szűrési kapcsolótáblája
5.2.3.1d ábrák: 24 bites input kép először 8 bitre, majd 4 bitre változtatásakor
30
PAL - Commander
5.2.3.2 SUSAN (Smallest Univalue Segment Assimilating Nucleus) élkereső algoritmus [19] Az alábbi képen látható a kör alakú maszk, amely végigpásztázza a képet. Ennek a maszknak a középső pixelje a nucleus.
5.2.3.2a ábra: A mintán négy kör alakú maszk helyezkedik el különböző pozíciókban
5.2.3.2b ábra: A maszkok érzékenysége különböző telítettségnél
Négy kör alakú maszk hasonlóság alapú színezéssel, az USAN-ok a maszk fehér részeiként vannak ábrázolva. A maszkban található pixelek intenzitása összehasonlításra kerül a nucleus intenzitásával. A maszk területét USAN-nak nevezzük (Univalue Segment Assimilating Nucleus). A SUSAN-elv alapja a kép minden egyes pixelének a környezetében található hasonló intenzitású pixelekkel történő asszociációja. Ez a környezet, azaz az USAN sok információt hordoz a kép felépítéséről. Az USAN mérete, centrális és második nyomatéka alapján élek találhatók. A többi tulajdonság-detektáló algoritmussal ellentétben itt nem használunk származtatott képeket, illetve zajszűrőket.
31
PAL - Commander
Az USAN terület a legnagyobb az azonos pixeleket tartalmazó “sík” területen, kb. felére csökken az élekhez közel, illetve még kisebbre a sarokpontokban. Az elv integráló hatása és a nemlineáris érzékenysége jó zajelnyomást okoz.
5.2.3.2c ábra: Az egyes pixelekhez tartozó USAN terület
A SUSAN Delphi forráskódja, ami FOBOT [2] projektből lett kölcsönözve biztosítja a leghatékonyabb éldetektálást, azonban a futásideje többszöröse a sobel (a másik legjobb élszűrt képet biztosító algoritmus) végrehajtásához képest. Zajos kép esetén szintén zajos outputot kapunk, viszont ha kellően szűrt inputunk van, akkor a kimeneti képet analizálva az AI modul igen nagy hatékonysággal képes helyes döntést hozni az irányításnál.
5.2.3.2d ábrák: A 8bites PAL-kameraképet SUSAN éldetektálóval szűrjük
32
PAL - Commander
5.2.4 RadiControl modul A vezérlés szoftveres megoldásánál figyelembe kell venni a kimeneti eszközök csatornáját. Az RC autó irányítása készült el előbb, így ebben az esetben a párhuzamos portot használtuk a célra. A Zlportio [16] komponens segítségével közvetlenül írunk az eszközre byte nagyságú adatokat. 9 irányváltoztató érték küldhető az irányításnak. Előre(1), balra(8), jobbra(4), balra-előre(9), jobbra-előre(7), hátra(2), balrahátra(10), jobbra-hátra(6), állj(0). Ezek az értékek manuálisan a programból is vezérlehetők.
5.2.4 ábra: A robotot az egér és numerikus billentyűzet segítségével is irányítani lehet
Az automatikus navigálás irányítását AI modul végzi a RadioControl megfelelő függvényeit meghívva. A függvények megfelelő késleltetéssel tetszőleges sorban való meghívása bonyolultabb manőverekre is lehetőséget ad. Az automatikus irányítását az AI modul végzi a RadioControl megfelelő függvényeit meghívva. A függvények megfelelő késleltetéssel tetszőleges sorban való meghívása bonyolultabb manőverekre is lehetőséget ad. A modell RC-nél soros porton való kommunikációt kellett megoldani. TcomPort [15] komponens segítségével küldjük ki a megfelelő vezérlőadatokat a távirányítóval.
5.2.5 AI modul Az irányítás vezérlése a mobil robot intelligenciájának alapja. A projekt szempontjából az intelligencia az ütközésmentes navigálást takarja. Az akadályok detektálása csak akkor lesz megbízható, ha a mobil robot homogén környezetben (pl. folyosón vagy útpályán) helyezkedik el, és az objektumok nagyobb mértékben eltérő színintenzitásúak. A kontúrpontok a navigálás alapját képezik. Ahhoz hogy kellő pontossággal határozzuk meg a robot-akadály távolságot a PALképet kell megfelelően bekalibrálni, melyet manuálisan(a képre kattintva) és automatizálva is el lehet végezni. A PALCenter a középpontot, az r1 (PAL InnerCircle) a belső holttér sugarát, az r2 (PAL OuterCircle) pedig a nagy sugarat jelenti pixelekben. Az automatikus PAL-kalibráció beépítése azért volt fontos a projekt szempontjából, mivel a PAL-optika és lencse felfogatása a kamerára nem stabil, így gyakran elmozdult a beállított helyzetből a kép, ezzel gyakorlatilag elrontotta a helyes detektálás menetét. PAL középpont a kép közepéhez képest kerül meghatározásra, mégpedig a detect algoritmussal. A detect függvény működése során egy meghatározott középponttól (PalX, PalY) meghatározott szögben és tetszőlegesen állítható treshold értékkel pixelekben mért távolsági értéket ad vissza a kontúrponttól.
33
PAL - Commander
5.2.5.1 A PAL-kalibráció működése: PalX = PalX + (Detect(360)-Detect(180))/2 PalY = PalY + (Detect(270)-Detect(90))/2 r1 = Detect(90) r2 = Képmagasság-r1 Ezzel az eljárással meghatározásra került az új, kalibrált középpont és a belső holttér sugara.
5.2.5.1a ábra: PAL-kép detektálás szempontjából fontos szerkezeti felépítése
5.2.5.1b ábra: PAL-kalibráció és navigációs érzékenység állítása a programban
5.2.5.2 Track követés A PalCom AI bekapcsolásával a robot a meghatározott viselkedési formák alapján helyzetváltoztatást végez. Alapelve a következő: ha az irányítás áll (tehát a távirányítónak küldött érték 0) és a detect(90) distance értéktől nagyobb, akkor a RadioControl.Fw (előre) parancs kerül átadásra. Ha a detect(110) < detect(90) < detect(70) akkor RadioControl.FwR (jobbra-előre) utasítás hívódik meg (5.2.4.2 a ábra). Ha a detect(70) < detect(90) < detect(110) akkor RadioControl.FwL (balraelőre) hatására a mobil robot balra fordul (5.2.4.2b ábra). 34
5.2.4.2a ábra: Különböző szögekben detektált kontúrpontok
PAL - Commander
A detect(90) < distance esetben a RadioControl.Stop utasítása 0 jelet küld a távirányítónak. A robot mögötti terület is figyelemmel tartható a bejövő kép panorámikus mivoltából kifolyólag. A detektálás menete hasonló a már leírtakhoz. Ha a mobil robot nincs irányítás alatt (RadioControl.Readport= 0) és detect(270) > distance, a meghívott utasítás a RadioControl.Bw. Ha detect(250) > detect(270) > detect(290) ebben az esetben balra-hátra, detect(290) > detect(270) > detect(250) esetében jobbra-hátra fog a robot tolatni.
5.2.4.2 b ábra: A robot automatikus navigációnál balra fordul
Ezekkel az egyszerű algoritmusokkal remek hatásfokot lehet elérni az ütközésmentes navigációban abban az esetben, ha megfelelő gyorsaságú a képfeldolgozás és a robot sebessége és iránya belátható terület kb. 70%-án belül kontrollálható. A továbbiakban a mobil robot képességeit tervezzük fejleszteni. A feladatul a mozgásdetektálást, objektumkövetést (jellegzetes objektumok felismerésével) és a környezet jeleire való reagálást tekintjük.
5.2.5.3 Vonalkövetés Vonalkövetés során egy meghatározott színintenzitáshoz mérjük a további pixeleket, így becsülve a vonal helyzetét a robothoz képest. A PAL-középpont x koordinátáját tekintve alapértéknek különböző y értékekkel 3 vonalban vizsgáltatjuk azokat. Ahol a színintenzitás többször egymás után is nagyobb (fekete vonal esetén kisebb), az a pont potenciális útnak tekintendő. A 3 detektáló vonal irányát és nagyságát meghatározva irányváltoztató adatot küldünk ki a robot részére. Ha az első vonal mentén az intenzitás alacsony az akadálynak minősül, és ellentétes irányváltoztatásra kényszeríti a robotot. Azonban ha nincs értékelhető vonal vagy akadály, tolatás történik, és a mögöttes rész vizsgálatára is sort kerítve hasonló módszerrel kerestethetünk alkalmas pályát.
35
5.2.4.3 ábra: A robot automatikus navigációnál balra fordul
PAL - Commander
5.3 C# keretrendszer A keretrendszer lehetőséget ad új funkcionalitás gyors, és egyszerű implementálására. Ezek lehetnek: képfeldolgozó eljárások, navigálási programok, egyéb szenzorokból szerzett információk feldolgozását végző modulok. A felhasználói felület a Delphis verzióhoz képest teljesen újra lett gondolva: az egyes modulokhoz tartozó paraméter-módosítási lehetőségek jól elkülönítve helyezkednek el, ezzel az egyedi modultesztelések felgyorsultak, valamint nagymértékben nőtt a felület átláthatósága is. Szoftverfejlesztési szempontból az egyes modulok külön könyvtári állományba (.dll) való helyezése több előnyel is járt. Egyrészt ily módon csökkent a fordítási idő, másrészt miután a közös interface-ben megállapodtunk, a fejlesztés egymással párhuzamosan történt. Az egyes modulokat fejlesztés során önállóan, majd globálisan is tesztelhettük. (A használt programfejlesztési metodikákról lásd a 6. fejezetet) A modulok közül a program alján lehet váltogatni, új modul implementálásakor új lap jelenik meg. A program felső részén található a kameráról szedett kép, vagy a tesztvideó, majd mellette a feldolgozott kép.
5.3 a ábra: A C# keretrendszer felépítése
A modulok paraméterezése –tesztelési célokat megkönnyítendő- XML file-ba menthetőek.
36
PAL - Commander
A feldolgozási pipeline felépítése: a kameráról beérkező képet az input modul szedi le a tuner egységről, innen a keretrendszer továbbítja azt az előfeldolgozók (preprocessor: Filters modul) számára. Az előfeldolgozó a beérkező képen elvégzi a szükséges transzformációkat, majd továbbadja a már feldolgozott képet a keretrendszeren keresztül a döntéshozó modulnak (AI). Amennyiben az AI modul aktív (tehát nem kézi vezérlésen van a robot), úgy a programjának megfelelően meghozza a szükségesnek ítélt változtatást a robot mozgásában, és továbbítja azt a navigációs modulnak (navigation). A navigációs modul pedig a döntést (amelyet vagy a felhasználótól, vagy az AI modultól kapta) átalakítja a megfelelő irányítókód-kombinációra, majd soros illetve párhuzamos porton keresztül kiküldi a távirányítónak.
5.3b ábra: A C# pipeline felépítése
5.3.1 Input modul A kamera kezelése (input modul) a DirectshowNet [28] nevű könyvtár felhasználásával történik: segítségével a Microsoft Windows teljes beépített DirectShow komponense elérhetővé válik. Ennek előnyei, hogy minden, a DirectShow által ismert kameratípust képes kezelni a szoftver. A dekódolási, valamint a kirajzolási fázis a managed kódtól külön szálon fut. Ezzel egyrészt rengeteg processzoridőt nyerünk, másrészt, amikor a managed kód képet vesz le, biztosan az a kép lesz, amit a periféria éppen közöl. Tehát nem léphet fel időelcsúszás az esetleges lassú feldolgozási sebesség miatt. További előnye a DirectShowNetnek, hogy szabadon felhasználható, open source. Hátránya hogy a DirectShow jó néhány funkcionalitása még nem érhető el benne, valamint, hogy olyan könyvtárakra (unmanaged.dll) támaszkodik, ami egyedi a Windows operációs rendszerekre, ezért más rendszerekben való alkalmazáskor vagy emulálni kell ezeket a könyvtári eljárásokat, vagy kicserélni az adott rendszerben megfelelő funkciókra. Az input modul a kamerák kezelésén felül lehetővé teszi, hogy egy korábban rögzített tesztfutást adjon vissza, ily módon az algoritmusokat, valamint a többi modult a hardware használata nélkül is lehet tesztelni; valamint a teszt-futásokat rögzíteni is lehet, későbbi elemzés céljából. 37
PAL - Commander
5.3.2 Filters modul A filters modul a Delphi rendszer ImageTrans moduljának felel meg. Hasonló előfeldolgozó szűrő csak a SUSAN, melynek implementálása nem hozta meg a kívánt eredményt. Helyette hatékonyabb algoritmusokat alkalmaztunk. A SharperCv [20] az OpenCv .NET-es változata, de sajnos kompatibilitási okokból kifolyólag nem teljes értékű átirat. Mivel hasznosnak tartottunk pár algoritmust, ezért végül implementáltuk a C# verzióba. Ebből számunkra egyik leghasznosabb szűrőnek a Canny algoritmus bizonyult (5.3.2a ábra). A beépítésre került HSL szűrő használatával a képet szegmentálhatjuk a színárnyalat, intenzitás és megvilágítottság szerint. A színárnyalat (Hue) 0-360 intervallum közé, az intenzitás (Saturation) és megvilágítottság (Luminance/Brightnes) 0-100 közé esik.
5.3.2a ábra: Canny algoritmussal szűrt kép
HSL szűrést két esetben érdemes alkalmaznunk. Ha a pálya teljesen homogén, akkor hatékony track követés valósítható meg ezzel a módszerrel. Másik alkalmazása objektumkövetés során célszerű, ha az objektum a környezettől jelentősen eltérő színű (pl. vörös árnyalat). A projekt esetében ezt a módszert használjuk.
5.3.2b ábrák A képen HSL szűrést végzünk vörös színre.
Az RGB szűréssel hasonló eredményességet tudunk elérni, és az algoritmus sokkal gyorsabban fut, mint a HSL esetében. A 3 színcsatorna alapján minimum és maximum értékeken belül vizsgáljuk a pixelintenzitást, és ha a határok közé esik, akkor azt megjelenítjük, különben fekete marad. 38
PAL - Commander
A Threshold szűrés segítségével binarizációt érhetünk el, így csak azok a pixelek fognak beleszámítani a detektáló algoritmusba, amelyekre valójában szükségünk van. Ennél a szűrésfajtánál dinamikus értékváltoztatást tudunk kezelni az Autobalance kapcsoló használatával. Abban az esetben, ha a környezetben nagymértékű fényváltozások következnek be, például fényesebb/megvilágítottabb területről árnyékosabb részre haladunk a robottal, akkor egyfajta kiegyensúlyozást kell alkalmaznunk. Ezt úgy érjük el, hogy egy rendelkezésünkre álló komponens használatával (Aforge.Imaging.ImageStatistics [21]) a kép telítettségére következtetünk, és ez alapján a Threshold minimum és maximum értékeit változtatjuk automatikusan.
5.3.2c ábrák: Világosabb területből sötétebbe való áthaladásnál az autobalance kiegyensúlyozza a fényintenzitást
39
PAL - Commander
5.3.3 AI modul A C#-os AI modul megreformálására azért került sor, hogy egy univerzális, egységes algoritmust hozzunk létre a különböző viselkedési formák irányításához. A Delphi verzióban az algoritmus a diszkrét irányítású robotnál kielégítő volt, viszont a C#-os verzióban törekedtünk arra, hogy a precíziós irányítással párhuzamosan is megfelelően működjön. A képeken az irány meghatározására szintén szögeket használunk, például 90fok előre, 270fok hátra... A működőképes algoritmus alapja, hogy megfelelően legyenek bekalibrálva a PAL-kép tulajdonságai: a középpont, a belső holttér sugara (r1) és a külső sugár (r2). (5.3.3a ábra) További alkalmazott értékek (5.3.3b ábra): Distance: a maximális figyelési távolságot százalékban adhatjuk meg az r2-höz képest −
5.3.3a ábra: Pal jellemzők beállítási táblája
−
Scanning degree: a keresési szög 0-180fok-ig terjedhet (90 foktól kezdődően)
−
Threshold minimum: a legkisebb elfogadható pixelintenzitások összege (0-20000)
− Turning fordulási szöge
degree:
a
robot
maximális
Tolerance: a középhez képest tűrt fordulási szög - általában a diszkrét irányításnál van jelentősége, mivel így kis eltérésnél sem fog a robot ingázni (mint Delphi algoritmus esetében). −
Az algoritmus egy olyan irányvonalat határoz meg a képen, mely a középpontban tart össze, a kezdete a középponttól r1 távolságnyira van. A hosszát a distance értékkel tudjuk változtatni (a maximális figyelési távolságot százalékban adhatjuk meg). 90foktól elkezdve a scanning 5.3.3b ábra: Az algoritmus beállítási táblája degree értékig balra (>90fok) illetve jobbra (<90fok) kezd keresni a fokértékek között. A meghatározott vonalak mentén összeadja a pixelintezitásokat, és amelyiknél az érték túllépi a threshold minimum küszöbszámot és a legtöbb, az a szögérték lesz kiválasztva az irányítás számára. (Ez a szögérték később ellenőrzésre kerül, hogy a robot elfér-e az adott szakaszon.) Mivel az algoritmus a problémakörre nézve univerzális, ezért csak a paramétereket kell változtatni a helyes irányítás érdekében.
40
PAL - Commander
5.3.3.1 Vonalkövetés: A distance értéket, vagyis az r1-től r2-ig tartó figyelési távot úgy érdemes beállítanunk, hogy a távoli zavaró objektumok/fények ne kerüljenek bele a vonalba. Ezért ha lehet érdemes az esetünkben 30-60% között tartani. A scanning degree a figyelési szöget jelenti a középhez képest, tehát nem feltétlenül érdemes a robot tényleges kanyarodási szögétől nagyobbra venni. Ha csak kis eltéréseket akarunk korrigálni, akkor elegendő a 10-15 fok is. A helyes threshold minimum érték általában 5000-10000 között szokott lenni binarizált kép esetén, viszont ha hosszabb utat keresünk, akkor ezt érdemes feljebb venni. A tolerance érték 5-8 fok közt már elég jó stabilitást biztosít egyenes haladás esetén. Az algoritmus hatékonyságát Threshold szűréssel növelhetjük, így csak a beállított színintezintásoknak megfelelő utat fogja figyelembe venni.
5.3.3.1 ábrák: A nyers, és a binarizált képre alkalmazott vonalkövetés
5.3.3.2 Pályakövetés A distance értéket általában minél nagyobbra érdemes állítani, hogy a terepet minél jobban „belássa” a detektáló vonal. A scanning degree a robottól függő maximális kanyarodási szög értéke legyen. A threshold minimum érték 10000-20000 között (binarizált kép), annak érdekében, hogy csak olyan terepen haladjon, ahol megfelelő távolságon belül meg tud állni esetleges felbukkanó akadály esetén. A tolerance érték 10-15 fok közt kevesebb ingázást tesz lehetővé.
41
5.3.3.2a ábra:Trackkövetés canny éldetektálással, invertálással és thresholdozással
PAL - Commander Az algoritmus hatékonyságát Threshold szűréssel növelhetjük, így csak a kifejezetten egyszínű utakat fogja figyelembe venni.
5.3.3.2c ábra: HSL szűrés, és binarizálás
5.3.3.2b ábra: Treshold szűrővel való pályakövetés
5.3.3.3 Objektumkövetés Olyan objektumokat képes a rendszer követni, amely nagy mértékben eltér a környezeti színektől. Általában az ilyen színek a világos rózsaszín, világoszöld, piros. A distance érték közepesen nagy legyen (50-80%). A scanning degree a robottól függő maximális kanyarodási szög értéke legyen. A threshold minimum érték kicsi legyen (1000-től) annak érdekében, hogy meglássa a távoli kisméretű objektumot is.
5.3.3.3 ábra: Az 5.3.2b ábrára binarizálást követő objektumkövetés-teszt eredménye
42
PAL - Commander
5.3.4 Navigation modul A modul feladata a robot hardverével való, vezeték nélküli kapcsolattartás. Ez a modul nem része a pipeline vezetéknek. Csak az AI áll vele kapcsolatban.
5.3.4a ábra: A Navigation modul
Lehetőség van manuális irányításra. Ezek közé tartozik az egérrel, illetve billentyűzettel való navigáció. Soros portra csatlakozni kell a megfelelő port, paritás bit, baudrate megfelelő beállítása után. Ezek állítására a Settings menüpont alatt van lehetőség. A csatlakozás megtörténik, ha PIC „OK” visszajelzést ad, erről meggyőződhetünk a státussorba kiírt csatlakozási értékekről. Ha nem érkezik visszajelzés, akkor vagy nincs bekapcsolva a távirányító, vagy nincs összekötve a PC-vel. Ekkor a szoftver felszólítja a felhasználót, a PC és a távirányító csatlakozásának ellenőrzésére. Párhuzamos portot az inpout32.dll segítségével érjük el. Szintén 9 irányváltoztató érték küldhető az irányítónak. Előre (1), balra (8), jobbra (4), balra-előre (9), jobbra-előre (7), hátra (2), balra-hátra (10), jobbra-hátra(6), állj(0). A soros porti kommunikációt C# alatt a System.IO.Ports beépített névtér alól érjük el. Csatlakozás során felépítünk SerialPort objektumot (melyen keresztül tudjuk az irányításhoz szükséges két értéket kiküldeni), majd a program tájékoztat bennünket a sikeres csatlakozásról. Adatot küldeni a send() metódus meghívásával tudunk, miután beállítottuk a speed, valamint a direction globális változókat. A kiküldés akkor veheti kezdetét, mikor a PIC-ről megkapjuk az „R” karaktert. Ilyenkor a távirányító készen áll az új adatok fogadására, a függvény kiküldi a két értéket, rendre direction, speed, majd visszaigazolást vár. Ha a visszakapott értékek megegyeznek a kiküldött adatokkal, a kommunikáció sikeres volt. 9 navigációs függvény van, melyek meghívásával állíthatjuk be a kiküldött értékeket, és hívhatjuk meg a send() metódust. Ezek a Stop(), Fw(), Bw(), L(), R(), FwR(), FwL(), BwR(), BwL(). Az „F” az előre, „B” a hátra, „L” a balra, és „R” a jobbra irányt jelenti. Mivel különböző Modell RC-nél különböző intervallumok közé eshet a kiküldött érték, valamint a középérték sem feltétlenül a matematikai közép, ezek változtatására lehetőség van (Max Forward, Max Baxkward, Speed Center, Max Lef, Max Right, Direction Center). A billentyűzetről, valamint egérről való irányítás a Microsoft DirectX névterének 43
PAL - Commander DirectInput osztály segítségével lett megoldva. A DirectInput lehetővé teszi az egér, illetve a billentyűzet kezelését. Az AI irányítás nem működhet együtt a kézi navigációval, egyszerre csak az egyik lehet aktív. A billentyűzetről való irányítást úgy terveztük meg, hogy kezelése ne okozzon problémát, a felület teljesen intuitív. Ha előre szeretnénk haladni, felfele nyíllal, ha jobbra előre, akkor a jobbra, és felfele nyíl együttes megnyomásával tudunk navigálni, és így tovább. Ez összesen nyolc lehetőség az irányításra. Kik ülde ndő é rté k Párhuzamos porton fix értékek küldődnek ki az egyes gombok lenyomásával, míg soros porton folyamatosan váltakozóak. Állítható Mivel a Modell RC precíziós irányítású, a m axim um kézi irányításnál is törekednünk kellett ennek helyes megvalósítására. A Állítható kiküldendő adat a megengedett m inim um intervallum között addig növekszik, amíg Idő nyomva tartjuk a billentyűt. Ha felengedjük, akkor ugyanolyan mértékkel 5.3.4b ábra: Billentyű lenyomása az idő függvényében csökkenni kezd. A növekmény értéke is változtatható annak függvényében, hogy milyen sebességgel szeretnénk például elindulni (Speed measure, Direction Measure). Ezt az értéket érdemes feljebb állítani, ha az autó akkumulátora merülni kezd, mivel ilyenkor a motorok lassabban reagálnak. Minden egyes változtatásnál meghívjuk a 9 navigációs függvény valamelyikét attól függően, mely billentyűk voltak lenyomva, így valós idejű irányítást érhetünk el. Amennyiben az értékek elérik a beállított középértéket, akkor a STOP() metódus hívásával alaphelyzetbe áll az autó. A különböző Modell RC-k közötti kompatibilitás érdekében nem fix értékkel dolgozunk, hanem százalékos értékekkel változtatjuk a kiküldött adatot az intervallumon belül.
5.3.5 Events modul Az Events modul tartalmazza a naplózási, és mérési osztályokat: 1. A Log osztály szolgál a különféle események fájlba írására. A Log-ot bármelyik modul használhatja, függvényei statikusak. A keretrendszer indulásakor Logs osztály példányosítása megtörténik, mely beállítja a loggoló fájlok helyét, és nevét. Kétféle fájlt használunk, az error.log, és a navigation.log. Az előzőbe tartoznak a mindenféle hibaüzenetek, saját üzenetek, mérések eredményei. A navigation.log tartalmazza a navigation osztály irányítási értékeit, amennyiben a loggolás be van kapcsolva. 2. Az Events osztály segíti a keretrendszer és a modulok közötti visszafele való kommunikációt. 3. A Timer segítségével futási időket tudunk mérni. Az osztály Start(), majd a Stop() metódusának meghívásával mérhető az algoritmusok futásideje. A Duration tulajdonságból kiolvasható az idő ms-ba. 44
PAL - Commander
6. Programfejlesztési metodikák 6.1 A fejlesztés módszere A szoftver alapvetően evolúciós fejlesztéssel készült: a főbb vázlatok egyeztetése után a programot modulokra bontottuk, és az egyes modulokat egymással párhuzamosan készítettük, teszteltük.
6.1.1 Subversion [27] Már a készítés korai stádiumában felmerült arra az igény, hogy az egyik fejlesztőnél történt változtatások a másik fejlesztőhöz minél gyorsabban eljussanak. Ehhez version controlling rendszert használunk, mely bevezetése nem csak erre a problémára adott megoldást. A központosított forrásfa egyben tárolja az összes eddigi változtatást, így, ha a szoftver evolúció valahol zsákutcába torkollik, könnyen vissza lehet térni egy korábbi verzióra. Ráadásul a feltöltött forrásfa tárolja a szoftver teljes aktuális állapotát, íj módon még ha maga a központi forrásfa meg is semmisül valamilyen hardver, vagy szoftver hiba miatt, az aktuális állapot bármelyik fejlesztő számítógépén megtalálható. Ennek köszönhetően a fejlesztés folyamán egyetlen kódsort sem veszítettünk. Az Interneten számos, szabadon használható version controlling rendszer található. Három okból esett a választásunk a Subversion-re. Egyrészt, a Better SCM Initiative oldalán [22] található összehasonlítás, másrészt, a rendszerhez letölthető –ugyancsak open source (GPL)- TortoiseSVN egyszerű, intuitív felhasználói felülete. Harmadrészt a rendszernek mind az adminisztrálásában, mind a használatában volt mar korábbi tapasztalat.
6.1.2 Wiki A fejlesztés során felmerülő problémák szóbeli egyeztetése igénybe vesz legalább két fejlesztőt, ami egyrészt nem biztos, hogy mindig adott, másrészt egy-egy probléma miatt nem lehet megtenni azt, hogy az egész fejlesztést szüneteltetjük. Ennek a problémának a megoldására létrehoztunk egy olyan weblapot, amit bárki szerkeszthet, hozzáfűzhet, elvehet sorokat, képeket, stb. Az ilyen oldalakat, avagy portálokat összefoglaló néven Wikinek hívják. A leghíresebb külföldi wikinek, a Wikipédiának [23] több, mint 796.000 szócikke van a dolgozat írása idején.
45
PAL - Commander
7. Tesztelés Még a projekt kezdeti szakaszában egy PAL-optikás tesztvideó készült USB kamera és laptop segítségével, mellyel az elkészült algoritmusokat tudtuk ellenőrizni. A későbbiekben ahogy állt össze a robot már gyakorlati tesztelésre is szükség volt. A korai szakasz kábeles hosszabbítása miatt a számítógéphez közel kellett homogén tesztkörnyezetet teremteni, így ezt egy lepedővel oldottuk meg. Igaz a nem mindig megfelelő fénymennyiség és a kis kontraszt némileg rontotta a detektálás hatékonyságát, de már impresszív eredményeket értünk el így is vele akadálykerülési téren.
7a ábra: A robot érzékeli az elé kerülő akadályokat, és kísérletet tesz azok kikerülésére
A vezeték nélküli kamera beszerzése nagyobb lendületet adott a projektnek. Folyosón kezdtük a kísérletezést, ahol tesztpályát állítottunk fel, itt a tényleges kanyarodást lehetett vizsgálni. A szabad, ütközésmentes haladást (freefall), körpályán való navigációt, és az objektumkövetést sikeresen teszteltük. A felállított pályán biztonságos navigációt sikerült elérni. A folyosó közepén lévő neon fényvisszaverődés a projekt kezdeti szakaszában jelentősen zavarta a tesztelést, de az új rendszerbe beépített szűrőkkel jelentősen javult a detektálás hatékonysága. A Delphis rendszernek a fekete pálya nyújtott segítséget a probléma kiküszöbölésére. A kamerát magasabbra állítva nagyobb terület vizsgálható egy időben. Mivel sikerült a neoncsík problémát kiküszöbölni, bátran próbálkozhattunk a nagyobb területet bejárni, nagyobb pályát építettünk.
7b ábra: Kezdeti célunk körpályán való automatikus navigáció megvalósítása volt
Freefall navigáció közben a robot abba az irányba halad tovább, amerre a legkisebb valószínűséggel feltételez akadályt.
46
PAL - Commander
7.1 Hardver tesztelés Amíg a Modell RC távirányítója nem készült el, a kapcsolást, és a programot próbapanelon teszteltük. Amikor becsatlakozási ponton mért impulzusok megegyeztek az eredeti távirányító megfelelő helyen mért impulzusaival, kijelenthettük, hogy összeállt egy biztonságos koncepció, a távirányító megépítésre került. A későbbi problémák ekkor ütköztek ki. A fontosabb közé tartozik, hogy a kapcsolat időnként megszakadt. Kezdetben a PC szoftver 3 értéket küldött ki. Ebből kettő az navigációs értékek, harmadik pedig egy lezáró karakter, hogy a PIC tudja, mikor van vége a jelküldésnek. Bizonyos idő után az értékek összekeveredtek, és a PIC nem tudta megfelelően feldolgozni a vett adatokat. Ezt kiküszöbölve csak a két hasznos információt küldjük ki, így ez a probléma megszűnt.
7.2 Szoftver tesztelés A Delphi rendszert az RC autóval teszteltük. Lehetőség lett volna a Modell RC-t is vezérelni, viszont a fejlesztés eme szakaszában a hardver rész még nem állt teljes biztonsággal rendelkezésre. A C# rendszer készítésénél már nagyobb hangsúly kapott a soros porti vezérlés. Elsődleges célnak vettük, hogy a Modell RC- t vezéreljük, mivel így az RC autó irányítása alapvetően megoldott. A tesztelésnél minden modult külön teszteltünk, majd építettük be a keretrendszerbe. Mindkét esetben a tesztelést tesztvideókkal is elősegítettük. Mindezeket szem előtt tartva a következő mérési eredményeket kaptuk:
7.3 Mérések 7.3.1 Mérés tárgya A két elkészített szoftverhez tartozó képfeldolgozási algoritmusok mérése.
7.3.2 Mérés célja Az elkészített szoftverben felhasznált képfeldolgozási algoritmusok futási idejének, valamint processzor kihasználtságának megállapítása egy átlagosnak tekinthető személyi számítógépen (Athlon XP 2500+, 256Mb memória).
7.3.3 Mérés menete A Delphi esetében Zprofiler [17] segítségével történtek a mérések. A C# program esetén egy külső timer célú függvényt vettünk igénybe. A Microsoft Windowsban található kernel32.dll fájlban lévő QueryPerformanceCounter, valamint QueryPerformanceFrequency együttesen sokkal pontosabb eredményt szolgáltat, mint a C# Environment.TickCount változója. Míg az utóbbi maximum tizedmásodperceket képes mérni, az előbbi ezredmásodperce pontos eredményt ad. 47
PAL - Commander
7.3.4 Mérési eredmények A mérési eredményeket százalékos processzorhasználat mellett adjuk meg tesztvideó futtatása közben.
Delphi
Időérték
Processzor használat
Átlagos idő tesztvideóval
1 ms
10 %
Vonalkövetés
2 ms
12 %
Robinson
14 ms
39 %
Kirsh
16 ms
40 %
Prewitt
17 ms
40 %
Laplace
13 ms
34 %
Roberts
9 ms
30 %
11 ms
34%
6 ms
25 %
Susan
22 ms
65 %
Pályakövetés (Susan)
25 ms
70%
Sobel Pixelnoise
C#
Időérték
Processzor használat
Átlagos idő tesztvideóval
< 1 ms
3%
Vonalkövetés
< 1ms
5%
6 ms
35%
43 ms
70%
RGB filter
2 ms
10%
Treshold (Aforge [21])
5 ms
24%
26 ms
60%
Canny HSL
Susan + Gray
2. táblázat: Mérési eredmények a beépített szűrőkről
7.3.5 Mérés értékelése A beépített szűrők közül csupán a SUSAN algoritmus található meg mindkét rendszerben. Ennek sebessége nem tér el jelentősen a két rendszeren. Látható, hogy míg a C# rendszerbe kevesebb szűrőt implementáltunk, mégis gyorsabbak, és hatékonyabbak azok.
48
PAL - Commander
8. Összegzés A hardver értékelése: sikerült egy olyan mobil robot kivitelezése, mely egyszerű felépítéséből adódóan könnyen reprodukálható és alacsony költségvetésű. A szoftver értékelése: a műveletsor hosszúsága ellenére a készített szoftver a kitűzött céloknak megfelel, egy átlagosnak tekinthető PC-n képes volt a program a valós idejű követelményeknek megfelelni. A projekt értékelése: a készített rendszer a kitűzött kritériumainak megfelel. Dinamikus a környezet váltózásaival szemben, autonóm módon képes ütközésmentes navigációra, felfestett pályán való haladásra, valamint objektumkövetésre homogén környezetben. Mind a hardver, mind a szoftver újrahasznosíthatóak, egyszerűen bővíthetőek.
komponensekről
elmondható,
hogy
9. További lehetséges alkalmazási területek A készített rendszer további kutatásokat, és fejlesztéseket vetít előre. A rendszert próbáltuk úgy tervezni, hogy a legegyszerűbb módon más rendszerekbe átültethető legyen. Így nem csak a látássérült emberek számára nyújtana segítséget, hanem mozgássérült embertársainknak is. Tolókocsira szerelve szintén eredményesen lehet használni. A fejlesztés jelenlegi stádiumában már kisebb módosításokkal alkalmazható lehet beltéri szállításra (például raktározás) is, ami irodákban, éttermekben, kiszolgáló egységként tudna nagy segítséget nyújtani.
10. Rövid távú továbbfejlesztési irányok 10.1 Hardver Szükséges hardver továbbfejlesztések egyrészt a térképezés modul segítségét szolgálja, másrészt a mobilitás növelése érdekében történnek.
10.1.1 Távirányító A jelenlegi távirányító hatótávolsága 50 méter körüli, és csak egyirányú kommunikációra képes. Saját távirányító építésével a távolság, illetve a kommunikációs csatornák száma növelhető. Ehhez a microchip által gyártott rádiófrekvenciás mikrokontroller lehet segítségünkre (RF-PIC). Ennek előnye, hogy 2 oldali kommunikáció érhető el, és akár 100-150 méter is lehet a hatótávolsága.
49
PAL - Commander
10.1.2 Iránytű Térképezéshez szükséges megállapítani a robot aktuális helyzetét. Ehhez vagy referenciapontokat alkalmazunk, vagy egy iránytűvel határozzuk meg a kocsi állását. Iránytű lehet egyszerű analóg, folyadékon alapuló gömbiránytű, valamint a földi mágneses tér irányának és nagyságának tisztán elektronikus úton való mérésére használt elektronikus iránytű. Az elektronikus iránytű előnye a pontosabb, és biztosabb mérés. Ilyen például a CMPS03 előre elkészített típus. [26]
10.1.2 ábra: CMPS03 Digitális iránytű [26]
Plusz 5V áramforrás szükséges, áramfelvétele tipikusan 20mA. 0.1 fokonként képes helyes irány adni. Közelében lévő mágnes rontja a mérés eredményét. Kis mérete miatt könnyen felszerelhető a robotra. Másik megoldás egy GPS használata, melybe beépített iránytű segítené feladatunkat. Ilyen irányban folytatunk kutatásokat. Egy Garmin Ertex Vista típusú GPS vevőt sikerül tesztelnünk, mely rendelkezik a kívánt iránytű funkcióval. [24]
10.1.3 Sebességmérő A térképezéshez szükségünk van a sebesség, vagy az elmozdulás mérésére is. Ennek mérésére több lehetőség adódik. 1. A biciklire szerelt sebességmérő elve ideálisnak tűnik. Egy HALL cellát (DN6838) a kerék tengelyével párhuzamosan, a felni széléhez rögzítve, és a műanyag felnibe olvasztott két mágnes elhaladását, az impulzusokat mérve kinyerhető a szükséges információ. Az elhelyezés történhet az első kerékre, illetve a hátsóra. Az első kerékre rögzítés előnye, hogy a kerék nem pörög ki hirtelen indulásnál. Hátránya, hogy a rögzítés nehézkes, mert a kerék elfordul, a tengelye nem fix. Hátsó kerékre a rögzítés egyszerűbb, és ha a robot lassan, kerékkipörgés nélkül indul, akkor ez lenne az egyszerűbb megoldás. 2. Egy görgős egér elektronikáját felhasználva szintén egyszerűen megoldható a feladat. Az egérben lévő tárcsát a tengelyre rögzítve, a szintén az egérből felhasznált kapuval az impulzusok figyelhetők, és pontosabb mérést kapunk. Egy körbefordulás alatt 45 impulzust mérhetünk, kettő helyett. A kerék egy körbefordulással 22 cm-t tesz meg. Ez azt jelenti, hogy egy impulzus 4,8mm út. A fordulatszám maximális sebességnél (~20km/h) 1515 fordulat/perc, az impulzusszám 68181/perc. Ez 1136Hz, amit lehet még mérni. Mind a két hátsó kerékre rögzíteni kell egy elektronikát, mert kanyarban a differenciálműből adódóan a külső kerék többet fordul. Átlagolva pontosabb mérés érhető el. 3. Másik megoldás lehet, hogy mivel a motor szénkefés, így a felvett áramimpulzusból lehetne a fordulatszámot számolni. Így egy kerékfordulatra akár 100 impulzus is juthat, pontosabb mérést eredményezve.
50
PAL - Commander
A motor áramimpulzusát nem könnyű mérni, a HALL cellás megoldás pontatlanabb, ezért a második variáció mellett döntöttünk. Mindegyik megoldás mögött egy PIC mikrokontroller állna, mellyel a kijelzés is megvalósítható. A mikrokontrolleren futó assembly program egyik fő része az impulzusok számmá alakítása lenne, amit a CCP1 modullal, és a hozzárendelt pl. TMR1 számlálóval lehetne megoldani. Két impulzus között a TMR1 beszámlált impulzusok száma fordítottan arányos a sebességgel. A beszámlált értéket egy a felbontástól függően nagy arányszámban kell elosztani, hogy megkapjuk a sebességet, illetve a viszonyszámot. Ha egy viszonyszámot 99-ig mérnénk, akkor a felbontás 0,2 km/h lenne. Az adatokat valamilyen módon el kell juttatni a feldolgozó egységbe. Egyik lehetséges alternatíva, a kamerán lévő hangcsatorna felhasználása. Itt egy modulációval, vagy akár egy 1KHz-es hang szaggatásával lehetne mérni. Másik megoldás, hogy kijelezzük az információt az autó orrán, és kamerával figyeljük a kijelzőt, majd feldolgozzuk a „látott” adatokat.
10.1.4 Kijelző 1. Sebesség kijelzése történhet egy nagy fényerejű LED felvillantásával. Ez nem tűnik optimálisnak, mert ha a robot gyorsan megy, a kiértékelés nehézkes lenne, a feldolgozás nem győzné a felvillanásokat. A kerék átmérője 7 cm, így maximum sebességnél 25-öt forog. 2. LCD kijelző: Törekedünk az olcsóbb, és energiatakarékosabb megoldásra. A mérést végző plusz elektronikát az autó akkumulátorára kötjük. A menetidő csökkenést 4%-nál jobban nem szeretnénk rontani. 3. 7, esetleg több szegmenses display
10.1.4 ábra: 7 szegmensen display
10.1.5 Akkumulátor Nagyobb menetidő elérése érdekében a plusz áramforrást igénylő perifériákat, érdemes lenne egy áramforrásra kötni. Erre a célra zselés akkumulátor terveztünk, mely többféle változatban létezik. Egy 9V12V, 4Ah-7Ah közötti, darab megfelelne. Súlya, és mérete nagyobb mint az eddigiek, de képes lenne biztosítani akár az autó áramigényeit is. 10.1.5 ábra: akkumulátor
51
PAL - Commander
10.1.6 Töltöttség figyelés Mikrokontroller megoldható, hogy figyeljük az akkumulátor töltöttségét. Mikor az egy kritikus érték alá csökken, értesíti a feldolgozó egységet, mely így programból állítani tud az autó paraméterein, valamint figyelmeztetheti a felhasználót.
10.1.7 PAL-optika helyettesítése Omnidirectional-rendszerrel A melléklet 12f ábráján látható kamera – parabolikus tükör párosítású rendszer előnye, hogy a távolabbi területeket nagyobb részletességgel mutat meg.
10.1.7 ábra: Omnidirectional körkép mobil roboton [3]
10.2 Szoftver 10.2.1 Távolságmérés Az omnidirectional rendszerek jellemzője, hogy távolság mérése is lehetséges, ha az objektum a földön helyezkedik el. Ahhoz, hogy távolságot mérhessünk szükségünk van egy egyenletre, amit a lencse görbületének feleltethetünk meg. 20cm-enkénti jelölésekből statisztikát készítettünk.
52
PAL - Commander Érték (pixel) 0 19 37 50 60 68 73 77 82 85
Távolság (cm) 0 20 40 60 80 100 120 140 160 180
3. táblázat: a jelölésekhez tartozó pixeltávolságok
10.2.1a ábra: A forrás kép 20 centimérenkénti beosztással
Harmadfokú polinomiális trendvonal segítségével (10.2.1b ábra) meghatároztuk az egyenletet: y = 0,0004x3 - 0,029x2 + 1,5873x – 0,6183 Így, ha a kamera 45cm magasan helyezkedik el 2 méterig megközelítőleg pontos távolságot tudunk adni az objektumról. y = 0,0004x 3 - 0,029x 2 + 1,5873x - 0,6183
200 180 160 140 120
Adatsor1
100
Polinom. (Adatsor1)
80 60 40 20 0 -20
0
20
40
60
80
100
10.2.1b ábra: A polinomális trendvonal
53
PAL - Commander
10.2.2 Térképezés Az AI modul jelenlegi működését szem előtt tartva egy lehetséges továbbfejlesztési irány egy olyan dinamikus döntéstámogató modul írása, amely képes emlékezni a környezet azon részére, ahol a mobil robot egyszer már járt [mapping / térképezés] . Ennek segítségével lehetővé válna, hogy az AI hosszú távú döntéseket is meg tudjon hozni, úgymint pályatervezés, a környezetben lévő dinamikus (mozgó) elemek felismerése, és elkerülése, …stb. Ehhez szükséges az aktuális pozíció, és irány meghatározása. Ha ez a fentebb ismertetett módszerek segítségével meghatározásra kerül, a PAL-optikából érkező képek normalizálásával, valamint mozgatási, és forgatási transzformáció segítségével egymásra helyezhetőek, és az így készült kép folyamatosan konvergál a környezet képéhez.
10.2.2 ábra: A térképezéshez használható SharperCv szűrő jellegzetes pontok után kutat.
10.2.3 Számfelismerés Kérdéses tényező még a hardver által nyújtott információ szoftverbe való kerülése. Mivel nem szeretnénk új kommunikációs csatornát létrehozni, az autóról való visszajelzéseket a képen továbbítanánk kijelző segítségével. A kijelzett számértékeket valamilyen módon le kell olvasni, és fel kell dolgozni. Erre már vannak kész, felhasználható koncepciók, és algoritmusok. [25]
10.2.4 GPU (Graphics Processing Unit) alapú képfeldolgozás A DirectX9 kompatibilis videókártya és DirectX9 HLSL (High Level Shading Language) segítségével tervezzük elvégeztetni a képműveleti számításokat. Ezáltal nagyobb képeket egyes bonyolultabb szűrők esetén is 100 képkocka/másodperc sebességgel dolgozhatunk fel.
54
PAL - Commander
11. Irodalomjegyzék [1] [2]
EXPLORATES II (1997 – 1998) http://ultra.obuda.kando.hu/~exploratores
2005 október 03.
FOBOT (2002 – 2003) http://roberta.obuda.kando.hu/iar/2002_2003/fobot/fooldal.html
2005 október 03.
[3]
University of Ljubljana, Faculty of Computer and Information Science Visual Cognitive Systems Laboratory - CogVis projekt Cognitive Vision Systems http://cogvis.fri.uni-lj.si 2005 október 03.
[4]
Evolution Robotics ER1 http://www.evolution.com/er1
[5]
2005 október 03.
Mobil robotok http://www.agent.ai/main.php?folderID=169&articleID=833&ctag=articlelist&iid=1 2005 október 03.
[6]
Omnidirectional Vision page http://www.cis.upenn.edu/~kostas/omni.html
2005 október 03.
[7]
Emanuelle Menegatti: The Caboto Project MSc in Artificial IntelligenceDivision of Informatics University of Edinburgh 2000 www.dei.unipd.it/~emg/papers/caboto.pdf 2005 október 03.
[8]
A PAL – optika és a fotózás http://fotomuveszet.elender.hu/0012/001216.html
2005 október 03.
A körpanorámás képalkotás katonai akalmazása http://www.zmka.hu/tanszekek/ehc/konferencia/may/tothimre.htm
2004 október 03.
[9]
A dokumentáció írása idején már nem volt elérhető.
[10] Hajtogatott sugármenetű optika mesterséges hold helyzetmeghatásozásához és egyidejűleg a földfelszín fényképezéséhez http://www.muszeroldal.hu/MMK/nr72/greguss.pdf 2005 október 03. [11] Computer Controlled Car Racing http://algoval.essex.ac.uk/cec2004/race/race.html#Introduction
2005 október 03.
[12] Vezetéknélküli kamera http://minirc.hu
2005 október 03.
55
PAL - Commander
[13] USB tuner http://tven.terratec.net/modules.php?op=modload&name=News&file=article&sid=2 36 2005 október 03. [14] TVideoGrabber VCL component for Delphi and C++Builder http://www.datastead.com
2005 október 03.
[15] TComPort http://www.efg2.com/Lab/Library/Delphi/IO/PortIO.htm
2005 október 03.
[16] ZLPortIO http://www.specosoft.com
2005 október 03.
[17] Zprofiler www.zeknov.com
2005 október 03.
[18] FFDsohw https://sourceforge.net/projects/ffdshow
2005 október 03.
[19] S.M. Smith and J.M. Brady. SUSAN - a new approach to low level image processing. Int. Journal of Computer Vision, 23(1):45–78, May 1997. http://www.geocities.com/ResearchTriangle/Campus/7971/susan.htm 2005 október 03.
[20] SharperCV http://www.cs.ru.ac.za/research/groups/SharperCV
2005 október 03.
[21] Aforge www.codeproject.com/cs/media/Image_Processing_Lab.asp
2005 október 03.
[22] Better SCM Initialive http://scm.berlios.de
2005 október 03.
[23] Wikipédia http://wikipedia.org
2005 október 03.
[24] Garmin Ertex Vista GPS http://www.gpsnow.com/gmetvs.htm#info
2005 október 03.
[25] Neural Network OCR http://www.codeproject.com/csharp/Neural_Network_OCR.asp
2005 október 03.
[26] CMPS03 elektronikus iránytű http://www.robot-electronics.co.uk/htm/cmps3doc.shtml
2005 október 03.
56
PAL - Commander
[27] Subversion http://subversion.tigris.org
2005 október 03.
[28] DirectShowNET Library http://directshownet.sourceforge.net/
2005 október 03.
[29] Open Source Computer Vision Library http://www.intel.com/technology/computing/opencv/index.htm
2005 október 03.
[30] Mesterséges Intelligencia, 18. Robotok fejezet, (Futó I. (Ed.)), AULA Kiadó, Budapest 1999.
57
PAL - Commander
12. Melléklet
12a ábra
12b ábra
12c ábra
12d ábra: Térfigyelésre használatos kamera
12e ábra: Lefkos nevű robot navigációja OD-megvalósítással 12f ábra: CogVis: kamera és hiperbolikus fémtükör párosítása [3]
12g ábra: A Lefkos a környezet jellegzetes pontjai (élek, sarkok) alapján navigál
58
PAL - Commander
12h ábra: 1:10 -es modellautó alapú robot
12i ábra: Az eredeti távirányítóra csatlakoztatott kiegászítő elektronika
59
