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

http://roberta.obuda.kando.hu/iar/2004_2005/palcom

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, szerszámok mozgatására vagy különböző feladatok végrehajtása

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égy- vagy 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:

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.

1. táblázat: EXPLORATES II és FOBOT összehasonlító táblázata

Test Szélesség Magasság Hossz Súly Haladási sebesség

Explorates II 400 mm 270 mm 600 mm 2,5 kg 400 mm/perc

FOBOT 305 mm 134 mm 432 mm 3,2 kg 3,2–5 m/perc

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 helyzet-meghatá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.

Utóbbi időben kísérletek folynak WLAN hálózatokkal történő háromszögelő helyzetmeghatározásra is.

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]

11

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 konyhát, előbb oda kell vinnünk, lefényképeztetjük vele a helyiséget, elmondjuk neki, mi van a fotón, raktározza, majd, 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.1 ábra: Az intelligens laptop robot

ER1

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:

− 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 omnidirectional-rendszerek és robotos megvalósításuk képei kerültek.

2.7.1 ábra: Különböző visszaverődéses tulajdonságú konvex tükrök [7]

2.7 ábra: RingCam kamerarendszer [6]

14

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.

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.2a ábra: Omnidirectional rendszerrel felszerelt robot [7]

2.7.2b ábra: A mobil robot által bejárt tesztkörnyezet [7]

15

2.7.2c ábra: A robot az élektől való távolságot becsülve kerülte ki az akadályokat.

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.

2.8a ábra: A PAL- optika szerkezete és működése [9]

16

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ó.

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.

2.8b ábrák: Az eredeti, és a hozzá tartozó kiterített kép

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ó.

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.

3. ábrák: Két példa a kezdeti megvalósítandó feladatra(képek a Computer Controlled Car Racing oldaláról [11])

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.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.

4.1.1 ábra: RC autó

19

4.1.2 ábra: 1:14 -s méretarányúModell RC autó

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.

Az autó 9.6V –os tápellátással működik, ami 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)

Jel-átalakítási célokra tökéletesen megfelel az 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.

4.2.1a ábra: CNY 74-4 optocsatoló

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Ω.

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.

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ó

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.

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" 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.

4.2.2b ábra: Közös ponton mért vezérlőjel

4.2.2a ábra: A távirányító elvi kapcsolási rajza (részlet)

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ó.

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!

4.2.2c ábra: Kiegészítő kapcsolás elvi rajza

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.

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.

4.2.2d ábra: A vezérlés blokkvázlata

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 USB- kamerá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.

A Sony panelkamera fényérzékenysége nagyságrendekkel jobb, mint a tesztelt USB- kameráé, 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 RCA-RCA 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

4.3a ábra: A kamera az RC autóra rögzítve és az általa belátott térrész

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 PAL-optika holtterében helyezkedik el a kocsi, ezért annak csak közvetlen környezete látszik.

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.3c ábra: A vezeték nélküli kamera rendszer tartozékai [12]

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 USB-kamerá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ó.

b) A prewitt horizontális és vertikális maszkjai

a) A sobel maszkja

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

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.

PAL - Commander

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.

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.

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

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.

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.2c ábra: Az egyes pixelekhez tartozó USAN terület

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), balra-hátra(10), jobbra-hátra(6), állj(0). Ezek az értékek manuálisan a programból is vezérlehetők.

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 PAL-ké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.

5.2.4 ábra: A robotot az egér és numerikus billentyűzet segítségével is irányítani lehet

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.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 (balra-előre) hatására a mobil robot balra fordul (5.2.4.2b ábra).

5.2.5.1b ábra: PAL-kalibráció és navigációs érzékenység állítása a programban

5.2.5.1a ábra: PAL-kép detektálás szempontjából fontos szerkezeti felépítése

5.2.4.2a ábra: Különböző szögekben detektált kontúrpontok

34

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.

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.

5.2.4.2 b ábra: A robot automatikus navigációnál balra fordul

5.2.4.3 ábra: A robot automatikus navigációnál balra fordul

35

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.

A modulok paraméterezése –tesztelési célokat megkönnyítendő- XML file-ba menthetőek.

5.3 a ábra: A C# keretrendszer felépítése

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.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.

5.3b ábra: A C# pipeline felépítése

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.

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.

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.

5.3.2a ábra: Canny algoritmussal szűrt kép

5.3.2b ábrák A képen HSL szűrést végzünk vörös színre.

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

− 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 degree: a robot maximális fordulási szöge

− 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 degree értékig balra (>90fok) illetve jobbra (

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.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é.

5.3.3.2a ábra:Trackkövetés canny éldetektálással, invertálással és

thresholdozással

5.3.3.1 ábrák: A nyers, és a binarizált képre alkalmazott vonalkövetés

41

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.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.2b ábra: Treshold szűrővel való pályakövetés

5.3.3.2c ábra: HSL szűrés, és binarizálás

42

5.3.3.3 ábra: Az 5.3.2b ábrára binarizálást követő objektumkövetés-teszt eredménye

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.

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

5.3.4a ábra: A Navigation modul

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. Párhuzamos porton fix értékek küldődnek ki az egyes gombok lenyomásával, míg soros porton folyamatosan váltakozóak. Mivel a Modell RC precíziós irányítású, a kézi irányításnál is törekednünk kellett ennek helyes megvalósítására. A kiküldendő adat a megengedett intervallum között addig növekszik, amíg nyomva tartjuk a billentyűt. Ha felengedjük, akkor ugyanolyan mértékkel 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.

Idő

Kiküldendő érték

Állítható m axim um

Állítható m inim um

5.3.4b ábra: Billentyű lenyomása az idő függvényében

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, szaba