SZAKDOLGOZAT

Erdős András

Debrecen

2015

Debreceni Egyetem

Informatikai Kar

Térképkészítés és navigálás asszisztív robotok részére

Témavezető: Készítette:

Dr. Oniga István Erdős András

egyetemi docens Mérnök informatikus Bsc

Debrecen

2015

1

Tartalomjegyzék

1 Célkitűzés ........................................................................................................................... 3

2 Asszisztív robotokról .......................................................................................................... 6

3 Felhasznált technológiák .................................................................................................... 8

3.1 Roomba Irobot Create Open Interface............................................................................ 8

3.2 Wifly RN-XV 171 WiFi modul .................................................................................... 13

3.3 ChipKIT MAX32 ......................................................................................................... 14

3.4 Szoftverek és tervezési minták ..................................................................................... 15

4 A térképszerkesztő szoftver felépítése és használata ....................................................... 17

4.1 Általános leírás ............................................................................................................. 17

4.1.1 Szerkesztési felület ............................................................................................. 17

4.1.2 A fő menüsor ismertetése ................................................................................... 17

4.1.3 A jobb oldali menüsor ismertetése ..................................................................... 21

4.1.4 A munkaasztal használata ................................................................................... 21

4.1.5 Az alkalmazás futtatási felülete .......................................................................... 22

4.2 A térképszerkesztő felépítése ....................................................................................... 24

5 PC – Robot kommunikáció .............................................................................................. 31

6 A mikrokontroller programozása...................................................................................... 34

6.1 Általános leírás ............................................................................................................. 34

6.2 Kapcsolatok kialakítása ................................................................................................ 36

6.3 Eszközök vezérlése ....................................................................................................... 37

6.3.1 Roomba Irobot Create Open Interface vezérlése ................................................ 37

6.3.2 Wifly RN-XV 171 WiFi modul konfigurálás ..................................................... 40

6.4 Állapottér reprezentáció ............................................................................................... 44

6.4.1 Állapottér ............................................................................................................ 45

6.4.1.1 Kényszerfeltételek ....................................................................................... 46

2

6.4.2 Kezdőállapot ....................................................................................................... 46

6.4.3 Célállapot ............................................................................................................ 47

6.4.4 Operátorok .......................................................................................................... 47

6.4.4.1 Operátoralkalmazási előfeltétel ................................................................... 47

6.4.4.2 Operátorok hatásdefiníciója ........................................................................ 48

6.4.5 Magasabb szintű mozgásformák ........................................................................ 49

6.5 Legrövidebb út keresés ................................................................................................. 50

6.5.1 Metrika értelmezése ............................................................................................ 52

6.5.2 A kereső felépítése.............................................................................................. 52

6.5.3 Navigálás az előállított útvonalon ...................................................................... 54

6.5.4 A kereső vezérlője .............................................................................................. 55

7 Fejlesztői weboldal, kapcsolat .......................................................................................... 57

8 Aktuális problémák és megoldások .................................................................................. 58

9 Összefoglalás .................................................................................................................... 59

9.1 Fejlesztési lehetőségek ................................................................................................. 59

10 Irodalomjegyzék ............................................................................................................... 61

11 Ábrajegyzék ...................................................................................................................... 64

12 Függelék ........................................................................................................................... 65

A) Felhasznált szoftverek listája ........................................................................................ 65

B) Felhasznált hardverek listája ........................................................................................ 65

C) A térképszerkesztő szerkesztési felületének képernyőképe ......................................... 66

D) A térképszerkesztő futtató felületének képernyőképe .................................................. 67

E) A térképszerkesztő alkalmazás UML diagramja .......................................................... 68

F) A mikrokontroller vezérlőjének UML diagramja ......................................................... 69

13 Köszönetnyilvánítás ......................................................................................................... 70

3

1 Célkitűzés

Egy robot számára a saját környezetének észlelése egy nagyon összetett, komplex

feladat. Egy olyan egyszerű művelet végrehajtása, mint „menj el az ajtóig” rengeteg

megoldandó feladatot jelent számára.

Először is tudni kellene, hogy éppen hol van. Ez elég triviális feladatnak hangzik. Ha

tőlünk megkérdezné valaki, hogy épp hol vagyunk, olyan válaszokat adnánk, hogy „a

szobámban”, vagy „az egyetemen”, és ebből a kérdező máris tudja, hogy hozzá viszonyítva az

távol van-e, el tud-e oda jutni. Egy robot, melyet épp most kapcsoltunk be, nem tud semmit a

környezetéről, fogalma sincs arról, hogy épp az egyetemen van-e, vagy egyáltalán merre lehet

az az ajtó, ahová el akartuk küldeni. Ez a helyzet hasonló ahhoz, mint amikor egy olyan

városban járunk, ahol még sosem jártunk, megkérdezik tőlünk, hogy épp hol vagyunk. Ebben

az esetben mi sem tudnánk helyzetünket semmilyen ismert helyhez viszonyítani, valószínűleg

azt mondanánk, hogy eltévedtünk. Tehát a robotnak szüksége van egy referenciapontra, amihez

képest meg tudja határozni, hogy épp hol van ő, saját maga, illetve az ajtó, ahová el kell menni.

A robot nem tudja, mi az, hogy „ajtó”. Számára nem létezik az a fogalomrendszer, amit

mi szoktunk használni a tárgyak leírására. Képzeljük el, ha egy olyan ételt fogyasztunk, amilyet

előtte még sosem láttunk, és megkérdezik, hogy hogyan hívják, mi sem tudnánk. Helyette

elkezdenénk felsorolni azokat az összetevőket, amelyeket felismerünk belőle. A robot számára

is le kellene írnunk az „ajtó” egyes tulajdonságát, melyből fel tudja ismerni azt. Ha már a robot

tudja, hogy egy adott ponthoz képest hol helyezkedik el, le lehet írni, hogy ugyanezen ponthoz

képest az ajtó hol helyezkedik el. Ezzel megadtuk az ajtó egy tulajdonságát, a helyzetét.

Megadhatjuk, hogy mekkora az ajtó kiterjedése, méretei. Ezek már olyan információk lesznek,

melyet a robot is meg tud érteni.

Meg kell tanítani egy robotnak azt is, hogy hogyan kell „menni”. Hogyan tud eljutni

egyik helyről a másikra. Mi ha megkapnánk ugyanezen feladatot, szétnéznénk, hogy hol van az

a bizonyos ajtó, megnéznénk, hogy a szobában levő tárgyak között hogyan tudnánk eljutni oda.

Nem tűnik fel, de folyamatosan kapcsolatot tartunk a külvilággal, érzékeljük azt, miközben

mozgunk. A robotnak is ugyanezt kell tennie. Érzékelni a tárgyakat a környezetében,

megkeresni az ajtóig vezető utat, elmenni oda. A robot sokkal primitívebb érzékszervekkel van

4

felszerelve, mint mi, emberek, számára a külvilág minden mozzanatának észlelése nem evidens

feladat.

Feladatom, hogy olyan alkalmazást készítsek, mellyel a felhasználók könnyen tudnak a

robot számára térképet készíteni. A szoftverrel szemben bizonyos követelményeket

támasztottam, melyek alapjául szolgáltak a fejlesztéseknek:

Az alkalmazás felhasználói interfésze könnyen kezelhető kell, hogy legyen.

Rendelkeznie kell grafikus megjelenítési felülettel, mely szemléletesebbé teszi a

térképkészítést.

Lehetővé kell, hogy tegye a térképek menedzselését: mentését, betöltését, javítását.

Az alkalmazás könnyen bővíthető kell, hogy legyen új fejlesztésekkel,

funkcionalitásokkal, éppen ezért általános tervezési mintákat, és modelleket kell

megvalósítania.

A megjelenítés, a modell, és a vezérlő teljesen különálló részt kell, hogy alkossanak.

Az alkalmazásnak implementálnia kell egy, a robottal közös protokollrendszert.

Interfészeket kell nyújtania a robot számára, melyen keresztül kétirányú kommunikációt

kell tudnia biztosítani. A térképszerkesztő és a robot között a legkézenfekvőbb megoldás a

széles körben elterjedt IEEE 802.11 szabvány szerinti kommunikáció megvalósítása. Mivel e

szabványon alapuló kommunikáció szinte bármilyen, manapság elterjedt eszközzel

kompatibilis, így ezt választottam az elsődleges csatornának a robot és az alkalmazás között.

Meg kell valósítani a térkép, kezdőpozíció, célpozíció térképméret, elküldését, illetve aktuális

pozícióra vonatkozó adatok fogadását.

A robotnak el kell tudnia jutni a felhasználó által kijelölt célba, a legrövidebb úton. A

robotnak rendelkeznie kell egy kisvilággal, melyre leképezhető a szerkesztett térkép. Ebből

adódóan meg kell tudnia állapítania egy referenciapontot, melyhez az összes többi pont

állapotát tudja viszonyítani, egy kezdőpozíciót, illetve a referenciaponthoz viszonyított

célpozíciót. Az útkeresésnek a térkép méretétől, alakjától, és bármilyen olyan tulajdonságától,

ami a felhasználó igényeitől függ, függetlennek kell lennie. Meg kell találni egy olyan

reprezentációját a térképnek, mely ezen megszorítások mellett is szabadon leképezhető a robot

kisvilágára. Az útkeresés általános jellegű, már használt, és bevált technikákra kell, hogy

épüljön. A robotnak már a mozgás megkezdésekor ismernie kell a teljes útvonalat a

5

célpozícióba, ezzel elkerülve, hogy fölösleges, nem célravezető lépéseket tegyen. Éppen ezért

ajánlott a legrövidebb út keresést két részre bontani, egyrészt meghatározni a legrövidebb utat,

másrészt elmenni a célba a robot mozgatásával. A robotnak képesnek kell lennie környezetének

folyamatos monitorozására, ezzel biztosítva, hogy mozgása során a legkörültekintőbben jár el.

6

2 Asszisztív robotokról

A robotok önálló navigálási képessége a robotika számos területének fontos kérdése.

Szakdolgozatom az informatikai karon működő asszisztív robot fejlesztések részét képezi, ezért

pár szóban bemutatnám, miért fontos, és aktuális e témakör kutatása.

Két főbb kutatási terület fejlődött ki, hogy az idős személyek saját otthoni

környezetükben minél tovább élhessenek. Az egyik terület az intelligens otthonok. A jövőben,

automatizált intelligens otthonok lesznek, amelyekben modern szenzor rendszerek és az

információs technológia segítségével az idős emberek képesek lesznek biztonságban élni saját

otthonaikban. A másik terület az, hogy az intelligens otthonok technológiát mobilrobot

alkalmazásával igyekszik kibővíteni. Az emberek egyre tovább élnek napjainkban. Most az EU

több mint 40 millió lakosa 65 év felett van és így feltételezhető, hogy a lakosság 2050-re, a

duplájára is növekedhet. Ez azt jelentheti, hogy egy idős emberre alig kevesebb, mint két ápoló

jut majd. Mivel valószínű, hogy nem lesz elég humán ápoló, ezért az otthoni körülmények

valamint az életminőség javítása az intelligens otthonok és az asszisztív robotok széleskörű

elterjedésével kompenzálható majd. [1] [2]

A világon számos, asszisztív robottal kapcsolatos kutatás, fejlesztés folyik. Az iRobot

RP-VITA fejlesztése egy autonóm orvosi robot, mely önálló navigációra képes. Hang és

képátvitel megvalósítását teszi lehetővé, mely segítségével könnyen kapcsolatot lehet teremteni

az ápolókkal, családtagokkal. A robot egy átlagos ember nagyságú. Távoli irányítást tesz

lehetővé, ezáltal az orvos távolról megnézheti betegét.

Az iRobot Ava 500 autonóm navigációt tesz lehetővé. Érintés, hang és gesztus útján is

irányítható. Integrált, felhő alapú szolgáltatást biztosít felhasználója számára. Biztonságosan

elkerül mozgó akadályokat is. Több célra is használható, konferenciabeszélgetések kezelését is

lehetővé teszi [1].

Az Aethon TUG egy elsősorban kórházi használatra kifejlesztett, automatizált robot.

Gond nélkül közlekedik a létesítményen belül. Szállításra is alkalmas. Kialakítása révén több

kocsit is lehet hozzákapcsolni, növelve tárkapacitását.

Az asszisztív robotok alkalmazási területe széleskörű, de szinte kivétel nélkül

mindegyiknek közös tulajdonsága, hogy autonóm navigációval rendelkezik, környezetét

7

folyamatosan monitorozva közlekedik, illetve a legnagyobb körültekintéssel jut el a tulajdonosa

által meghatározott helyre [2].

Különösen fontos tehát, hogy a robot, miközben feladatát ellátja, döntéseit egy olyan

környezetben tudja meghozni, melyet teljes mértékben ismer. Ennek alapja, hogy egy jól

meghatározott, pontos térképet ismerjen, illetve ezen a legoptimálisabb útvonalat tudja

meghatározni.

8

3 Felhasznált technológiák

A fejlesztés alatt a legnagyobb hangsúlyt magára a szoftverre helyeztem. Ezért tehát

olyan hardveres interfészeket, és platformokat kerestem, amelyeket könnyű kezelni,

megbízhatóak. Fontos szempont volt, hogy egy-egy eszköz mennyire terheli le a

mikrokontroller erőforrásait, memóriáját, vezérlő egységét. Mivel a mikrokontroller látja el a

legrövidebb út keresés feladatát, mely magába foglalja az állapottér gráf csúcsainak tárolását,

adatbázis építését, karbantartását, az operátorok által előállított csomópontok kezelését,

kényszerfeltételek teljesülésének vizsgálatát, stb., ezért folyamatos iterációt igényelnek, és

magas erőforrás igénnyel rendelkeznek.

3.1 Roomba Irobot Create Open Interface

A Create Open Interface (OI) egy elektronikai és egy szoftveres platformból tevődik

össze, melyen keresztül meg lehet határozni a robot viselkedését, és fogadni a szenzorjaitól

érkező adatokat. Az elektronikai interfész további két részre oszlik: egy 7 ágú Mini-Din

csatlakozóra, mely a töltő felett helyezkedik el, és egy 25 ágú DB-25 csatlakozóra, mely a robot

rakterében helyezkedik el. (1. ábra) A szoftveres interfészen keresztül manipulálható a robot

viselkedése, és a soros parancsokon keresztül olvashatóak a szenzorjaitól érkező értékek, illetve

küldhetőek és fogadhatóak aktuátor-, dallam játszó-, demo-, parancsok a Mini-Din vagy a DB-

25 csatlakozón keresztül PC-re vagy mikrokontrollerre [3].

9

1. ábra A Roomba Irobot Create Open Interface felépítése

Forrás: [3]

A robot használatához mindenképp szükséges egy olyan processzorral rendelkező

eszköz, mely képes soros parancsok generálására, és melyet csatlakoztatni lehet a Mini-Din

vagy a DB-25 csatlakozón keresztül a robothoz. A csatlakozók két irányú, soros kommunikációt

tesznek lehetővé TTL (0 – 5V) szinten. A DB-25 csatlakozót ellátták egy 5V táppal, melyen

keresztül a vezérlő eszközt lehet táplálni. A használt csatlakozók piros színnel vannak

feltüntetve. (2. ábra)

2. ábra DB-25 csatlakozó

Forrás: [3]

10

Az (1. táblázat) tartalmazza a használt csatlakozók leírását:

Sorszám Név Leírás

1 RXD 0-5V Serial input a robot felé.

2 TXD 0-5V Serial output a robot felől.

8 5V0 Szabályozott 5V 100 mA tápot biztosít, és analóg

referencia feszültség, mikor a robot be van

kapcsolva.

14 GND A robot akkumulátorának földje.

1. táblázat A használt csatlakozók neve és leírása

A soros porton keresztül úgynevezett opcode –ok segítségével lehet a robotot utasítani.

Az opcode-okhoz tartozhat paraméter, például sebesség megadása, és lehet visszatérési értékük,

például egy szenzor olvasásnál. Ha egy parancs valamilyen adattal tér vissza, át kell neki adni

egy tárolót, amibe az adatot beleírhatja. Ez legtöbbször egy byte-okból álló sorozat, vagy tömb.

A felhasznált parancsok listája, rövid leírással és használati utasítással [3]:

Start parancs

Opcode: 128

Data Byte: 0

Serial sequence: [128]

A robot sípol egyet, hogy tudassa, bekapcsolt. A bekapcsolást jelző zöld led elalszik,

mikor a vezérlés átadódik a mikrokontrollernek.

Baud parancs

Opcode: 129

Data Byte: 1

Serial sequence: [129][Baud Code]

Baud adat byte 1: Baud code (0-11)

A paranccsal be lehet állítani az átviteli sebességet bit/sec –ban (bps). A mikrokontroller

és a robot közötti kommunikáció a beállított sebességgel fog folyni tovább. Az

alapértelmezett átviteli sebesség 57600 bps.

11

Full parancs

Opcode: 132

Data Byte: 0

Serial sequence: [132]

A parancs átadja a robot teljes vezérlését mikrokontrollernek. Nem lesznek olyan

biztonsági funkciók, mint a kerekek leesésének detektálásakor megállás (leesés a

lépcsőn megakadályozása). A robot minden egyes további parancsot fog fogadni és

futtatni biztonsági kockázatra való tekintet nélkül.

Drive Direct parancs

Opcode: 145

Data Byte: 4

Serial sequence: [145][Jobb sebesség felső byte][Jobb sebesség alsó byte][Bal sebesség

felső byte][Bal sebesség alsó byte]

Drive Direct 1. adat byte: jobb kerék sebessége (-500 – 500 mm/s)

Drive Direct 1. adat bájt: bal kerék sebessége (-500 – 500 mm/s)

A parancs segítségével lehet mozgatni a robot kerekeit előre és hátra, külön-külön

mindkettőt. Négy adatbájtra van szükség, melyek 2-2 darab 16 bites előjeles egész

értékek, kettes komplemenssel ábrázolva. Az első két bájt definiálja a jobb kerék

sebességét mm/s –ban. A második két bájt pedig a bal kerék sebességét, ugyanabban a

formában. Pozitív érték esetén a kerék előre fele fog forogni, negatív érték eseten pedig

az ellenkező irányba, hátra.

Wait Angle parancs

Opcode: 157

Data Byte: 2

Serial sequence: [157][Szög felső byte][Szög alsó byte]

Wait Angle 1-2 adat byte: 16 bites előjeles szög fokokban, a felső byte-ot küldve először

12

A robot a parancs hatására addig fog maga körül forogni, amíg el nem éri a

meghatározott szöget. Amikor a robot az óramutató járásával megegyező irányba forog,

a szög akkor dekrementálódik. Ebből adódóan, ha a parancs paramétere negatív szám,

kettes komplemenssel ábrázolva, a robot az óramutató járásával megegyező irányba,

pozitív szám eseten az óramutató járásával ellentétes irányba fog forogni.

Stream parancs

Opcode: 148

Data Byte: N+1 (N a lekérdezett csomag száma)

Serial sequence: [148][Csomagok száma][Csomag ID 1][Csomag ID 2]… stb.

Stream 1. adat byte: a csomag lekérdezés száma (0-43)

Stream adat byte 2-N: csomag lekérdezés ID-ja (0-42)

A visszatérési érték formája: [19][N-byte][Csomag ID 1][Csomag 1 adat…][Csomag

ID 2][Csomag 2 adat…][Ellenőrző összeg]

Az ellenőrző összeg egy 1 byte –os érték. az adatfolyam végén

Bump and Wheel Drops parancs

Csomag ID: 7

Data Byte: 1 (előjel nélküli)

A robot elejére szerelt ütköző állapotát (0 = nem ütközött), és a kerekek állapotát (0 – a

kerekek érintkezek a talajjal, 1 – nem érintkeznek a talajjal) küldi el bitenként. A

parancsnak nincs opcode –ja, mivel a szenzor csomagban van. A szenzor érték lekérése

a Stream parancs segítségével történik az alábbi módon: [148][1][7][az átadandó byte].

A visszatérési értéke a 2. táblázat szerint alakul:

Bit 7 6 5 4 3 2 1 0

Szenzor n/a n/a n/a Első

görgő

leesett

Bal

kerék

leesett

Jobb

kerék

leesett

Bal

oldala

ütközött

Jobb

oldala

ütközött

2. táblázat Ütközésdetektálás adatfolyamának fogadása

13

A tesztek során a robot precizitásban és megbízhatóságban is megállta a helyét. A

távolságok mérésénél pontos eredményeket adott, kivetél nélkül minden alkalommal,

természetesen ésszerű hibahatáron belül (1 m-en 3-4 cm). Az opcode-okon, és a jól definiált

protokollrendszeren alapuló vezérlés nagyon hasznosnak bizonyult a fejlesztés során. A

mikrokontroller egyetlen feladata, hogy kiküldje az opcode-okat, és míg a robot mozog,

számolhatja a következő koordinátát, ahová mennie kell, párhuzamos végrehajtást téve

lehetővé.

3.2 Wifly RN-XV 171 WiFi modul

A WiFi eszközök között is széles választék kínálkozott. A kiválasztásnál a cél ugyanaz

volt, mint a robot esetében: könnyen kezelhető, kis erőforrásigénnyel rendelkező eszköz legyen.

Az eszköz kiválasztása a kommunikációs megoldások terén robusztus Roving Network vállalat

által gyártott RN 171 termékcsaládra esett. Integrált TCP/IP stack –el rendelkezik. Nagyon

alacsony áramfelvétellel, 4uA alvási, 40mA RX, 180 mA TX rendelkezik. A mikrokontroller

felé szabványos TTR UART interfészt biztosít [4]. Adatsebessége 464 kb./s. Támogatja a WEP,

WPA és WPA2-PSK szabványokon alapuló titkosítást.

A modul lábkiosztását a (3. ábra), a modul előképét pedig a (4. ábra) tartalmazza.

3. ábra RN-XV 171 WiFi modul

lábkiosztás

4. ábra RN-XV 171 WiFi modul

Forrás: [5]

14

A (3. táblázat) a modul felhasznált lábainak neveit és leírásait tartalmazza.

Pin Név Leírás

1 VDD_3V3 3.3 V szabályozott bemenet a modulhoz

2 UART_TX Adatirány: kimenet a modultól. 8 mA, 3V3 toleráns

3 UART_RX Adatirány: bemenet a modulhoz. 3.3V toleráns

10 GND Föld

3. táblázat A WiFi modul használt lábainak neve és leírása

A mikrokontrollerhez csatlakoztatva a modul 1-es és 10-es lábait máris működőképessé

válik. A konfigurálás illetve az adat küldés és fogadás egyaránt soros porton keresztül történik.

3.3 ChipKIT MAX32

Az eszközök vezérlését ChipKIT Max32 board végzi. Az egység vezérlője Microchip®

PIC32MX795F512L típúsú mikrokontroller (80 Mhz, 512K Flash, 128K RAM). Az üzemi

feszültsége 3.3V, a tipikus áramfelvétele pedig 90 mA. Az egység bemeneti feszültségére 7-

15V közötti érték ajánlott, az abszulút maximum 20V. 83 elérhető be/kimenettel rendelkezik,

melyből 16 analóg. Az analóg lábak bemeneti feszültsége 0-tól 3.3V –ig terjedhet [6]. A

digitális lábak +/- 18 mA-ig terhelhetőek (5. ábra).

5. ábra ChipKIT Max32. Forrás: [6]

Az egység hivatalos fejlesztőkörnyezete az MPIDE (Multi Platform Integrated

Development Environment), melynek alapjául az Arduino IDE fejlesztőkörnyezet szolgált,

15

kiterjesztve azt PIC32 támogatással. Az eszköz rendelkezik 3 UART, SPI, I2C és PWM

kimenetekkel. Az eszköz C++ nyelven lett programozva.

3.4 Szoftverek és tervezési minták

A mikrokontroller programozásra a lehető legkényelmesebb, sok kisegítő lehetőséggel

rendelkező integrált fejlesztőkörnyezetet kerestem. Az MPIDE szoftver, mely az Arduino IDE

PIC32 – vel való kompatibilitás megvalósítása érdekében született, nem nyújt széleskörű

támogatást a programozó számára. Támogatja ugyan a szintaxis kiemelést, rendelkezik

beépített soros monitorral, és vannak beépített eszközei a kód mikrokontrollere való

feltöltésére, de hiányoltam az olyan lehetőségeket, mint a projektszerkezet megnyitása, több

forrásfájl egyidejű szerkesztésének támogatása, a hiba és a figyelmeztető üzenetek

megjelenítésének szétválasztása, szintaxis ellenőrzés, az osztálytagok begépelésének

elkezdésével előugró választási lehetőségek, stb.

A nagyobb fejlesztőkörnyezetekhez (NetBeans, Visual Studio, Eclipse, IntelliJ)

megjelentek olyan kiegészítések, melyek támogatják a mikrokontrollerekre való programozást.

Segítségükkel egyszerre ki lelehet használni e fejlesztőkörnyezetek minden előnyét, illetve a

kiegészítés által nyújtott lehetőségeket is, mint a fordítás és feltöltés, mikrokontroller típusának

kiválasztása, beépített soros monitor, hibajavítási eszközök. A választásom egy ilyen környezet

kialakítására esett.

Az általam preferált fejlesztőkörnyezet a Visual Studio, melybe a Visual Micro nevezetű

kiegészítést telepítettem. A Visual Micro egy ingyenes Arduino kompatibilis kiegészítő Visual

Studio 2012-2015 fejlesztőkörnyezethez. Az Arduino IDE wiring keretrendszeren alapul, és a

Visual Micro is teljes mértékben kompatibilis ezzel a keretrendszerrel, illetve kompatibilis

minden más IDE- vel, mely szintén ezen a keretrendszeren alapul. Ez azt jelenti, hogy a

wiring/arduino fordítási eljárás úgyszintén támogatott a Visual Micro által, további szoftverek,

vagy hardverek bevonása nélkül. Támogatása kiterjed a ChipKIT, teensy, és még számos egyéb

kártyákra is. A kód fordítása előtt be kell tallózni, hogy mely fejlesztőkörnyezet által

szeretnénk, hogy leforduljon a kód (esetemben MPIDE), és már lehet is fordítani, illetve

feltölteni. Hasznos összetett, több osztályból álló programok írásakor egy ilyen

fejlesztőkörnyezet összeállítása, mivel átlátható, könnyen kezelhető fejlesztést tesz lehetővé,

mely javítja a kód minőségét, és csökkenti a fejlesztési időt.

16

A térképszerkesztő C# nyelven íródott, (.NET Framework 4.5.1) és rendelkezik grafikus

megjelenítési felülettel a könnyebb kezelhetőség céljából. Az alkalmazás telepítést nem

igényel, csak le kell tölteni1 a „.zip” állományt, kicsomagolni, és futtatni a

„Mapping\Debug\SzakdogaV3.exe” alkalmazást. Az alkalmazás Microsoft Visual Studio 2013

segítségével íródott Windows Form Application, mely futtatható mind x86, mind x64

architektúrájú számítógépeken.

1 Letölthető a http://shrek.unideb.hu/~erdosa/Szakdolgozat/V1.0/PC/App/Mapping_App_V1.0.zip

címről, vagy a http://shrek.unideb.hu/~erdosa/ weblap „Work” menüpontja alatti hivatkozásról. A weboldal

tartalma folyamatosan frissül, és mindig a legújabb verzió érhető el.

17

4 A térképszerkesztő szoftver felépítése és használata

4.1 Általános leírás

A térképszerkesztő szoftverrel lehet megalkotni azt a térképet, amelyen a robot fog

közlekedni A szerkesztő maga két nagy részre különíthető el: szerkesztési felület és futtató

felület. Az alábbiakban e részek kerülnek bemutatásra.

4.1.1 Szerkesztési felület

A felületet a felhasználóval való interakció megvalósítása érdekében hoztam létre.

Fontos szempontnak tartottam, hogy egyszerű, könnyen átlátható megjelenítést biztosítsak,

melyen könnyű és gyors a térképek kezelése, manipulálása.

A szerkesztési felület tartalmazza azokat az eszközöket, amellyel kényelmesen el lehet

készíteni a térképet. Ilyen a jobb oldali eszköztár, mely tartalmazza a palettát, és a zoom opciót,

a felső menüsor, mely lehetőséget nyújt térkép mentésére- és betöltésére a háttértárról, térkép

feltöltésére a robotnak. Itt lehet futtatási nézetre váltani, bezárni, és újranyitni a térképet. A

szerkesztési felület középpontjában maga a térkép alapjául szolgáló munkaasztal áll. Az asztal

méretét a munka megkezdése előtt felugró párbeszédablakban lehet megadni. A felületre

szabad, foglalt és start csomópontokat ábrázoló képeket elhelyezve lehet kialakítani a térképet.

A szerkesztési felület előképét a C) függelék tartalmazza. A fejezet tanulmányozása előtt

érdemes a szoftvert letölteni, kicsomagolni és futtatni. Javallott a szoftver által nyújtott

lehetőségeket kipróbálni az olvasással párhuzamosan.

4.1.2 A fő menüsor ismertetése

A szerkesztőfelület legfelső részén helyezkedik el a fő menüsor (6. ábra), mely a

térképek kezelését végzi. A fejezetben a menüsor által nyújtott lehetőségek kerülnek

bemutatásra.

6. ábra A fő menüsor lehetőségei

18

A „File” menüpont aktiválásával lehetőség nyílik új térkép betöltésére, beállításpanel

megjelenítésére és elrejtésére, a szerkesztési irányok megjelenítésére, a szerkesztett térkép

bezárására, és a programból való kilépésre.

A „New” menüpont aktiválásával („File” „New”) a program első indításakor a

térkép szerkesztését új térkép létrehozásával lehet elkezdeni. Vigyázni kell, ha már egy térkép

szerkesztése folyamatban van, és a „New” menüpont segítségével új térképet hozunk létre, az

előző térkép nem mentett módosításai, és a jobb oldali menü beállításai is elvesznek. Mindig

ajánlott elmenteni a munkát az új térkép szerkesztésének megkezdése előtt. A szerkesztett

térkép elvész akkor is, ha mégsem hozunk létre új térképet, de kilépünk a szerkesztőből. A

menüpont aktiválása után egy párbeszédablakban lehet beállítani, hogy az új térkép alapterülete

mekkora legyen (7. ábra).

7. ábra Az új térkép méretének beállítása

Alapértelmezetten a szerkesztő egy 100 csomópontból álló szerkesztési területet hoz

létre (10 csomópont balról jobbra, és 10 csomópont fentről lefelé). Természetesen ezt

tetszőleges át lehet méretezni a saját igényeknek megfelelően, szem előtt tartva, hogy a

szerkesztő csak az [1,30] intervallum elemeiből álló értékeket fogadja el lehetséges szerkesztési

alapterületnek. Egy csomópont a számítógép képernyőjén 50x50 pixeles négyzet alakú területet

fog lefedni. A beállításokat az „OK”feliratú gomb megnyomásával lehet véglegesíteni. Ekkor

az alkalmazás elkészíti és megjeleníti a személyre szabott szerkesztőfelületet.

A „Settings” menüpont aktiválásával („File” „Settings”) a jobb oldali menü

megjelenítését lehet beállítani. Ha szeretnénk a térképszerkesztési felületből nagyobb részt

látni, e menüpontban bezárható a jobb oldali menü, és helyét is a térképszerkesztő felület fogja

elfoglalni. (Ajánlott bezárni, ha a térkép kiterjedése balról jobbra nagy, hisz így újra látható lesz

egyben az egész térkép). A szerkesztés alatt bármikor újra előhozható a jobb oldali menüt.

19

A „Directions” menüpont aktiválásával („File” „Directions”) a szerkesztési irányok

jeleníthetőek meg. Ez egy segítség a felhasználók számára abban, hogy a térkép szerkesztésénél

a robot orientációját helyesen mérjék fel. Erről bővebben a 4.1.5 fejezetben lesz szó.

A „Close” menüpont aktiválásával („File” „Close”) lehet bezárni az aktuálisan

szerkesztett térképet. A térkép bezárása előtt ajánlott biztonsági mentést készíteni, mivel a

szerkesztési felület és a jobb oldali menü beállításai egyaránt elvesznek. A bezárást követően

megjelenik a kezdőképernyő, ahol újra lehet kezdeni a munkát (új térképet szerkeszteni, vagy

betölteni egy régebben szerkesztett térképet).

Az „Exit” menüpont aktiválásával („File „Exit”) bezárható a grafikus megjelenítési

felületet, a robottal való kommunikációs csatorna (amennyiben létesítésre került), és az

alkalmazásprogramozási felületet. A szerkesztő helyes bezárása eszközölhető ki a menüpont

aktiválásával.

A „Save to file” menüpont aktiválásával („Save” „Save to file”) elmenthető a

szerkesztett térképét a háttértárra. A mentés csak érvényes térkép esetén lehetséges. A

szerkesztő megvizsgálja mentés előtt, hogy érvényes-e a szerkesztett térkép. Egy érvényes

térkép tartalmaz legalább egy szabad csomópontot, és egy start csomópontot, ahonnan a robot

indulhat. A szabad és a start csomópont egybeeshet. Amennyiben egy nem érvényes térképet

próbálunk meg elmenteni a háttértárra, egy hibaablak fog megjelenni „Put a start position”

felirattal. Az ablakon található „OK” feliratú gomb megnyomásával lehet visszatérni a

szerkesztőbe, és javítani a térképét. Amennyiben a térképet a szerkesztő a mentés

szempontjából megfelelőnek találta, egy párbeszédablakot kezdeményez. Az ablakon keresztül

menthető le a térkép.

Az alapértelmezett mentési hely első mentésnél a „C:\Users\Username\Documents”

mappa, az összes további mentésnél pedig az a mappa, melybe előzőleg került mentésre a

térkép. Az alapértelmezett mentési név „RobotMap”. Amennyiben már létezik egy ilyen nevű

állomány a mentési helyen, az állomány régi tartalma felülíródik, elvész. Ajánlott mindig

egyéni nevet adni a menteni kívánt térképnek. A „Save” feliratú gombbal lehet elvégezni a

mentést. Menteni csak megnyitott, szerkesztett, érvényes térképet lehet. A gomb

megnyomásával egy „.map” kiterjesztésű állomány jön létre a kiválasztott helyen. Az állomány

minden olyan információt tartalmaz, amely alapján a szerkesztő rekonstruálni tudja a térképet.

20

A fájl tartalma megtekinthető úgy, hogy, társítjuk azt bármilyen preferált szövegszerkesztő

programhoz (az állomány érvényes ASCII karaktereket tartalmaz), és megnyitjuk.

A „Load” menüpont aktiválásával lehet térképet betölteni a háttértárról. Térkép

betöltésénél az épp szerkesztett térkép elvész, tehát a menüpont aktiválása előtt, az aktuális

munkáról ajánlott mentést készíteni. A nem mentett térkép el fog veszni, és a későbbiekben sem

lesz lehetőség előhozni. A térkép betöltését a „Save to file” menüponthoz hasonló

párbeszédablak segíti. Az ablak próbál a felhasználó igényeihez alkalmazkodni, a betöltést

mindig abból a mappából kínálja, ahová legutoljára mentett, illetve ha két mentés között

többször is betöltött térképet, akkor a legutóbbi betöltési mappát fogja ajánlani. Miután a

felhasználó kiválasztotta a kívánt „.map” állományt, az „Open” gomb megnyomásával töltheti

be a térképet a szerkesztőbe.

Az „Upload” menüpont aktiválásával lehet a szerkesztett térképet elküldeni a robotnak.

A menüpont csak akkor aktivizálható, ha van érvényes térkép betöltve a szerkesztőbe. A térkép

feltöltése előtt érdemes meggyőződni arról, hogy a robot bekapcsolt állapotban van-e. Azt, hogy

az alkalmazás és a robot között élő kapcsolat van, onnan lehet megállapítani, hogy a robot WiFi

modulján egy zöld LED folyamatosan villog (és egyik másik LED sem ég). Amennyiben még

nem került sor a kapcsolat kialakítására, a feltöltés előtt meg kell tenni.

A kapcsolat kialakításához, Windows operációs rendszeren, az elérhető hálózatok

között ki kell választani az „Erdos_Andris_robotja” nevű hálózatot, majd csatlakozni hozzá. A

hálózati kapcsolat létesítése gyakran fél percig is eltarthat. A feltöltés megkezdésével a WiFi

modulon egy narancssárga led fog gyorsan villogni, a feltöltés befejeződéséig. Amennyiben a

robot kikapcsolt állapotban van, meg kell ismételni a feltöltést. Ha a robot bekapcsolt állapotban

van, de a térképet mégse sikerült feltölteni, akkor probléma van az alkalmazás és a robot közötti

internetkapcsolattal. Ilyenkor érdemes a robotot és az alkalmazást is lecsatlakoztatni a

hálózatról, majd egy rövid idő elteltével (1-2 perc) újra csatlakozni.

A „Run” menüpont aktiválásával lehet átváltani szerkesztői felületből a futtató felületbe.

Ekkor megjelenik az elkészített térkép egy új ablakban. A menüpont csak akkor aktiválható, ha

a szerkesztőbe van betöltve érvényes térkép. Amennyiben a menüpont úgy lett aktiválva, hogy

előtte a térkép nem lett feltöltve a robotnak, a robot a célba az előzőleg feltöltött térkép alapján

fog eljutni (Ha egyáltalán létezik az ő térképén a célterület).

21

4.1.3 A jobb oldali menüsor ismertetése

A jobb oldali menüsor (8. ábra) tartalmazza mindazon szerkesztési eszközöket, melyre

szükség lehet a térkép elkészítése során: paletta, közelítés és távolítás, négyzetrács méretének

beállítása a munkaasztalon.

A paletta tartalmazza egy node összes állapotát. A

csomópont térképszerkesztés alatt lehet szabad, (free node –

ahol a robot szabadon közlekedhet), elérhetetlen (unrichable

node – ahová a robot nem mehet, mert fal, vagy tereptárgy van

ott), illetve start csomópont. Futási nézetben lehet még cél

csomópont is (goal node). Míg szabad és elérhetetlen

csomópontból bárhány lehet, addig start csomópontból csak

egy. Az egyes képekre kattintva aktiválható egy-egy

csomóponti elem, majd a szerkesztőben egy területre kattintva

állítható be a csomópont állapota az aktivált értékre.

Beállítható továbbá egy csomópont mérete. A robot

ekkora távolságot fog megtenni, míg eljut egyik csomópontból

a másikba. Alapértelmezett mértékegység a centiméter, az

alapértelmezett érték pedig 30. Ettől bármilyen más eltérő,

pozitív érték beállítható. Például, ha a térkép szerint a

robotnak 3 csomópontot kell mennie egy irányba (a szerkesztőben 3 egymást követő csomópont

lett szabadra állítva), akkor a robot 0,9 métert fog megtenni.

A „Zoom”, vagy nagyítási és kicsinyítési lehetőség a szerkesztő számára szól.

Segítségével növelhetőek vagy csökkenthetőek a megjelenített csomópontok mérete. A

csomópont alapértelmezett mérete 50x50 pixel. Gyengén látók számára ajánlott lehetőség,

megkönnyíti a térképszerkesztést.

4.1.4 A munkaasztal használata

A munkaasztal teszi ki a megjelenítési felületek legnagyobb részét. Itt lehet

megszerkeszteni a térképet. A felület alapértelmezetten zöld négyzetekből áll. Az ilyen

négyzetek jelzik, hogy arra a területre még nem került semmilyen objektum. Új objektumot

letenni egy területre a paletta segítségével lehet. A palettán a megfelelő objektumot ábrázoló

8. ábra Jobb oldali menüsor

22

képre kattintva (fal, szabad vagy start) állítható be, hogy az egér újbóli kattintásával milyen

objektum kerüljön a munkaasztalra. Például ha a palettán a falat ábrázoló képre kattint a

felhasználó, majd a munkaasztal egy tetszőleges területre, ezen a területen fal objektum fog

megjelenni. Ezután bármely más területre fog kattintani a munkaasztalon belül, a palettán

legutoljára kiválasztott objektum fog megjelenni.

Objektumot törölni a munkaasztalról nem lehet, de felül lehet definiálni azt. Például ha

a felhasználó lerakott egy akadályt jelentő objektumot, akkor azt bármikor szabaddá vagy start

objektummá teheti, csak ki kell választani a palettán a megfelelő elemet és kattintani a

felülírandó területre. Start csomópontot csak akkor lehet letenni a munkaasztalra, ha az még

nem tartalmaz egyet sem. Egy térkép csak egy start csomópontot tartalmazhat, mivel csak egy

robot közlekedhet rajta. Ha a térkép már tartalmaz egy start csomópontot, újabb start csomópont

lerakásával az előző start csomópont helye definiálódik felül. Mivel start csomópontot csak

szabad csomópontra (azaz mielőtt start csomópontot teszünk, előtte kötelező szabad

csomópontot rakni arra a területre) rakható, az előző start csomópont helye szabad csomópont

lesz, és a start áthelyeződik az újonnan kattintott területre. Csomópontot lerakni jobb és bal

egérgomb kattintással egyaránt lehet.

4.1.5 Az alkalmazás futtatási felülete

Miután a térkép a szerkesztési felületen elküldésre került a robot számára, megnyitható

a futtató felületet. Ezen a felületen adható meg a robotnak új célt, és követhető nyomon

helyzete. Itt már csak a robot állapotát befolyásoló legfontosabb tényezők jelennek meg (9.

ábra).

23

9. ábra A térképszerkesztő futtatási felülete

A felületen kirajzolásra kerülnek az akadályok, a szabad helyek, a szerkesztési irányok

és a robot kezdő pozíciója. A cél pozíciót a zöld színű zászló jelenti. Célt úgy lehet lerakni,

hogy az adott területre kell kattintani az egér bal gombjával, majd a felugró menüből

kiválasztani a „Put goal” lehetőséget. Amint a cél meg lett határozva, az aktív kommunikációs

kapcsolaton keresztül a robot megkapja a koordinátákat, és elmegy az adott területre a

legrövidebb úton. A képen látható tájolásban a robot egy csomópontot fog balra menni

(alapértelmezetten 30 cm-t), két csomópontot fog menni úgy, hogy ha kezdetben a felhasználó

vele szemben állt, távolodni fog tőle, és egy csomópontot fog szintén balra menni.

A robotot ábrázoló kép a térképen a robot valóságbeli helyzetét jelöli. A robot mozgása

a térben bármely irányban, a kép mozgását fogja maga után vonni. Amíg a robot nem megy el

a meghatározott cél pozícióba, új cél pozíció nem határozható meg számára. Miután elment a

megadott helyre, a fent leírt módon definiálható a robot számára új célt. Fontos, hogy a futtató

felületen csak egy cél mező lehet. A futtató felületet szabályosan bezárni az ablak jobb felső

sarkában található „Close” ikonnal lehet. Ilyenkor a program visszalép a szerkesztő felületre,

és folytatható a térkép szerkesztését tovább. Futtató környezetbe csak érvényes térkép

szerkesztése esetén lehet átlépni, különben hibaüzenet jelenik meg „Put a start position”

felirattal. A szerkesztés során akárhányszor át lehet lépni futtatási nézetbe, illetve feltöltés után

tesztelhető a szerkesztett térkép a roboton.

24

4.2 A térképszerkesztő felépítése

A fejezet a szerkesztő mögötti programozási logikát, tervezési mintát hivatott

bemutatni. Javasolt a fejezet olvasásával párhuzamosan a dokumentációt is böngészni, mely

elérhető a szakdolgozat honlapján böngészhető formában2, illetve ugyaninnen le is tölthető. A

szerkesztőhöz tartozó UML diagram az E). függelékben érhető el.

A szerkesztő felület középpontjában a „MainForm” osztály áll. Az osztály valósítja meg

az interakciót a felhasználókkal, illetve interfészt biztosít a többi osztály számára. A

„MainForm” egy parciális osztály. Ez a struktúra lehetővé teszi, hogy egy osztályt részeire

bontva több forrásfájlba is szétdarabolhassunk. Az osztály deklarációjában ezt a „partial”

módosítóval kell jelezni [7]. Fordításkor a fordító az osztály összes részét egyesíti. A

„MainForm” osztály továbbá az összes Windows Form komponens (gombok, szövegmezők,

képek, stb.) kinézetét és elhelyezkedését is tartalmazza. Az osztály a „Form” osztályt terjeszti

ki.

A szerkesztett térkép egy négyzethálós felületen helyezkedik el. Minden egyes négyzet

a „MyPictureBox” osztály egy-egy példánya. Az osztály a „PictureBox” osztályból került

származtatásra, mivel ezen osztály a legtöbb olyan tulajdonsággal rendelkezik, melyre szükség

van egy-egy csomópont megjelenítésénél, illetve manipulálásánál. A leszármazott osztály

kibővült olyan adattagokkal, melyek a csomópont állapotát (szabad, fal, még nem szerkesztett,

start, cél) írják le. Rendelkezik még a csomópont azonosítására szolgáló egyedi azonosítóval, a

csomópont helyzetét a térképen leíró (x, y) koordinátapárral. A csomópontokra nézve az

azonosító egyedi. A csomópont a felvehető állapotok közül mindig pontosan egyben lehet, tehát

egy csomópont nem rendelkezhet egyszerre két állapottal, illetve minden csomópont kell, hogy

legyen valamilyen állapotban. Az osztály példányai a példányosítás során „még nem

szerkesztett” állapotban vannak. Az állapotokat boolean típusú adattagok reprezentálják. Az

állapotok hozzáférhetősége {get; set;} property segítségével történik, melyeken keresztül a

program futása alatt a csomópontok állapota lekérdezhető és megváltoztatható.

Csomópontok létrehozásáért, törléséért, adminisztrálásáért, eléréséért a „NodeFactory”

osztály felel. Az osztályból csak egy példány létezhet, mely akárhány csomópontot képes

kezelni. Úgynevezett singleton tervezési minta alapján készült. Ez azt jelenti, hogy az

2 A dokumentáció elérhető a http://shrek.unideb.hu/~erdosa/Szakdolgozat/V1.0/PC/Doc/html/index.html

webhelyen böngészhető formában, illetve letölthető a szakdolgozat weboldaláról: http://shrek.unideb.hu/~erdosa/

25

osztálynak maximum egy példánya létezhet. A példány az osztály egy statikus metódusán

keresztül érhető el. A metódus tartja nyílván, hogy létezik-e az osztályból már példány.

Amennyiben létezik, visszatér vele, amennyiben még nem, készít egyet, és úgy tér vissza vele.

Természetesen ez a konstruktor privát láthatósági módosítóval való ellátását vonja maga után.

A tervezési minta nagyobb biztonságot nyújt a programozó felé, mivel így elkerülhető, hogy

egy olyan osztályból több példányt hozzon létre, amelyből csak egyre van szükség. Nagyobb

szabadságot ad a használata során is, mivel hivatkozhatóak a példány szintű metódusai is. A

csomópontok lista adatszerkezetben kerülnek eltárolásra.

Az új térkép szerkesztésének megkezdésekor, miután kiválasztásra került a térkép

mérete, a „MainForm” utasítja a „NodeFactory” –t arról, hány példányt kell létrehozni a „Node”

osztályból (10. ábra).

10. ábra Csomópont létrehozásának koncepció diagramja

A példányok elkészülése alatt beállítódik minden, a szerkesztéskor fontos paramétere:

betöltődik a háttértárról a csomópont állapotát jelző, kezdetben „még nem meghatározott”

bitmap kép (mely egy egyszínű, zöld kép), beállítódik az átméretezhető tulajdonsága,

kiosztódik minden csomópontnak a koordinátája, meghatározódik a képernyőn való

elhelyezkedése és mérete. A „NodeFactory” nem képes kirajzolni a csomópontot, mivel a

26

megjelenítés nem ezen osztály feladata, csak adminisztrálja a csomópontokat, felveszi őket a

tároló konténerbe. A csomópont eseménykezelőjéhez hozzáadja a „Click” eseménykezelőt. Az

eseménykezelő az egér jobb és bal gombjának kattintásával aktivizálódik. Ez azt jelenti, ha a

felhasználó a csomópontra kattint, lefut egy speciális metódus, mely meghatározza, mi

történjen a kattintás hatására. Mivel a csomópontok száma nem egy előre meghatározott érték,

hanem a felhasználó alakítja ki az igényeinek megfelelően, ezeket az adminisztrációs lépéseket

a program futása közben kell tudnia dinamikusan kezelni az osztálynak. Amikor a felhasználó

szerkeszt egy térképet, és újat szeretne nyitni, az osztálynak pontosan meg kell tudnia határozni,

mely csomópontokat kell törölnie, esetleg milyen koordinátával ellátott új csomópontot kell

tárolni, melyik csomópont milyen állapotban van, melyik csomóponthoz milyen

eseménykezelő van értelmezve.

A kattintás hatására tehát, eseménykezelő fut le, melyben meghatározódik a dobott

objektum, és az esemény típusa. Ebben az esetben az objektum a „MyPictureBox” osztály egy

példánya, az esemény típusa pedig a „Click” esemény. Mivel az objektum egyedi azonosítót

tartalmaz, (hiszen ezért lett származtatva, és kiterjesztve adattagokkal) pontosan meg lehet

határozni, hogy melyik csomópont állapotát szeretné a felhasználó módosítani. Így már ismert,

hogy melyik a megváltoztatandó csomópont, mi a koordinátája, elhelyezkedése a térképen,

milyen állapotban van. Már csak egy paraméter hiányzik ahhoz, hogy a metódus olyan

viselkedést legyen képes kiváltani, amilyet a felhasználó elvár: meg kell tudnia határozni, hogy

a felhasználó pontosan milyen állapotra szeretné megváltoztatni a csomópont állapotát (szabad,

elérhetetlen, start vagy cél legyen). Ennek megértése érdekében meg kell ismerni a paletta

működését és a „Globals” osztályt (11. ábra).

A „Globals” osztály, mint ahogy neve is szimbolizálja, az alkalmazás minden osztály

minden metódusa számára elérhető. Az osztály singleton, és egyaránt definiál statikus és

példány szintű adattagokat. Olyan paraméterek érhetőek el az osztályból, mint a háttértárról

betöltendő képek elérési útvonala, a csomópontok egységesen kezelt méretére vonatkozó

információk, a csomópontok maximálisan és minimálisan megengedett darabszáma, a robot

start és cél pozícióit reprezentáló csomópontok, a megjelenítés nagyítási és kicsinyítési

paramétereinek alapszáma.

27

11. ábra Csomópont állapot frissítése

A paletta tartalmazza azt a három állapotot, amelyet a felhasználó értelmezhet egy-egy

csomópontra a szerkesztési folyamat alatt (szabad, fal, start). Az állapotok megjelenítése három

„PictureBox” objektumon keresztül történik. Mindhárom objektum eseménykezelőjéhez hozzá

van adva a „Click” esemény. Ha a felhasználó kattint valamelyikre, a „Globals” osztályban

beállításra kerül, hogy melyik állapotot reprezentáló képre kattintott. Tehát ha a felhasználó a

falat ábrázoló képre kattintott, az egérrel ezután mindaddig falat tud lerakni a térképre, míg a

palettán más képre nem kattint.

A „NodeFactory” „Click” eseménykezelője egy csomópontra való kattintás során

egyszerűen lekéri a „Globals” osztálytól, hogy az egér épp milyen állapotban van, azaz a

palettán utoljára melyik képre kattintott a felhasználó az egérrel, és ennek függvényében állítja

be a csomópont állapotát, illetve változtatja meg a kinézetét befolyásoló kép elérési útvonalát.

Felhívnám a figyelmet, hogy az osztály továbbra sem képes kirajzolni az új állapothoz tartozó

képet, a felhasználói felület módosítása nem ezen osztály feladata.

Tekintsük át, mi történik a csomópontokkal, amikor szerkesztési nézetből a felhasználó

futtató nézetbe vált át.

A futtató nézetben már nincs lehetőség arra, hogy új csomópontot adjon hozzá a

felhasználó a térképhez, viszont itt is tudnia kell megváltoztatni a meglévő csomópont állapotát:

ki kell tudnia jelölni a cél pozíciót, melyet egy zöld zászló reprezentál a felhasználói felületen.

A cél kijelölése egyben utasítás a robot számára, hogy keresheti a legrövidebb utat a térképen,

és elindulhat a megjelölt cél felé. Biztonsági okokból nem megengedhető, hogy a felhasználó

egyszerű kattintással tudja kijelölni a cél pozíciót, úgy ahogy például új, szabad csomópontot

28

tudott lerakni a térképszerkesztőben. Míg a szerkesztőben, ha nem kívánt állapotra változtatta

egy csomópont állapotát, egyszerűen felüldefiniálhatta azt egy másik állapottal, itt viszont a

robotot utasítja mozgásra, mely akár kárt is képes okozni a környezetében. Éppen ezért az egér

jobb gombjával kattintva, az előugró listáról kiválasztva a „Go to goal” opciót lehet a robotnak

célt adni, és ezáltal mozgásra bírni.

12. ábra A futtatói nézet eseményeinek koncepciós diagramja

A futtató nézetbe váltás során (12. ábra) a „RunMap” osztály utasítja a „NodeFactory”

osztályt, hogy adja át az általa jegyzett csomópontokat a „GetNodeList” metódusán keresztül.

A „RunMap” egy új ablakot hoz létre, melynek szülője a szerkesztői nézet ablaka. Ezen

hierarchia kialakításával hozható létre kontrollált kétirányú információáramlás a két ablak

között. Az osztály a futtatási nézet megjelenítéséért felelős. Kirajzolja azokat a csomópontokat,

melyek a futtatás szempontjából fontosak: a falakat, a szabad csomópontokat, illetve a start

csomópontot.

A „NodeFactory” az átadott csomópontok eseménykezelő listájáról eltávolítja a „Click”

eseménykezelőt, és minden egyes szabad csomópontra értelmez egy „ContextMenu” listát (ez

lesz a jobb egérgomb kattintásával előugró lista), majd hozzáadja a listához a „Go to goal”

opciót, melyet egy „MenuItem” objektum reprezentál. A futtató nézetből szerkesztői nézetbe

váltás során e művelet fordítottját végzi el: eltávolítja minden csomópont eseménykezelő

29

listájáról a jobb egérgomb kattintására előugró menü által kiváltotta eseményt, és hozzáadja a

kattintás eseményt.

Az esemény kiváltódásának kezelését a „GoalNodeClicked” metódus végzi. Miután

meghatározta, melyik csomópontra történt kattintás, beállítja azt cél csomópontnak. A

kirajzolás a „RunMap” osztály feladata.

Amennyiben nem támogatott műveletet hajt végre a felhasználó, meghívódik a

„MyErrorForm” osztály. Létrehoz egy külön ablakot, mely tartalmazza a hiba leírását. Az „OK”

gomb „Click” eseménykezelője zárja be az ablakot.

A cél csomópont meghatározásával egy időben elküldődik az a robotnak. A küldést a

„SendCoords” osztály végzi. Csak ezen az osztályon keresztül lehet kommunikációt

kezdeményezni a robottal. Az osztály küldi ki a térkép csomópontjait, a start, cél

csomópontokat, a csomópontok méretét, darabszámát. A térkép kiküldésénél csak a szabad, és

a start csomópontok által tárolt (x, y) koordinátapárok kerülnek kiküldésre. Az osztály

implementálja a kiküldésnél használt protokollrendszert is, melyről bővebben az 5 fejezetben

lesz szó. Miután az osztály utasítást kap adat küldésére, az adatokat becsomagolja a megfelelő

protokoll üzenetbe, és továbbküldi azt.

A becsomagolt adatot a „TcpCommunication” osztály fogadja. Az osztály feladata aktív

kommunikációs csatorna létesítése, fenntartása, és bezárása a robot és az alkalmazás között,

illetve a csatornán adatokat küldeni és fogadni. Az osztály saját eseménykezelőt értelmez, mely

esemény akkor váltódik ki, amikor a robottól üzenet érkezett. A küldés és fogadás ugyanazon

socketen (itt: a socket egy olyan entitás, amely egyértelműen azonosítja egy hálózati

kommunikációs viszony végpontját) keresztül történik. A robot IP címe 169.254.1.2, illetve a

kommunikáció a 2000-es porton keresztül folyik. Fogadáskor a socket hallgatását egy külön

szál végzi. A szál az alkalmazás elindításával automatikusan indul, illetve bezárásával bezárul.

A szál normál prioritással fut. A fogadott adatokat pufferbe gyűjti, mely globális, és a fogadott

esemény kezelője számára mindig elérhető. A fogadott üzenet feldolgozását a „ReceiveCoords”

osztály végzi.

A térkép mentését és betöltését a „MapAdmin” osztály végzi (13. ábra). Az osztály

utasítást csak a „MainForm” osztályon keresztül kaphat betöltésre és mentésre. A mentésnél

egy „.map” kiterjesztésű állományt hoz létre, melynek felépítése:

30

1) Az első sor a térkép méreteit tartalmazza (csomópontok száma X illetve Y irányba)

2) A start csomópont koordinátáit tartalmazza.

3) Az összes többi sor a csomópontok koordinátáit, és állapotát tartalmazza, ahol az

állapot:

a) 0 - start

b) 1 - szabad

c) 2 – fal

Mentés előtt az osztály „SaveToFile” metódusa létrehoz egy példányt a

„SaveFileDialog” osztályból, melyen keresztül ki lehet választani grafikusan a mentés helyét.

A „MainForm” átadja a „NodeFactory” osztálytól lekért csomópontokat az osztálynak. A

háttértárra írást/olvasást csak ez az egy osztály végezheti. (13. ábra)

Térkép betöltésnél az osztály „LoadFromFile” metódusa készít egy példányt az

„OpenFileDialog” osztályból. Ezen keresztül lehet betallózni a megnyitandó file-t. A fájlból a

koordinátákat és állapotukat kiolvasva utasítja a „NodeFactory” osztályt a csomópontok

létrehozására, majd ha végzett, kirajzoltatja őket a „MainForm” osztállyal. (13. ábra)

13. ábra Térkép mentés és betöltés

A fejlesztés során az osztályok log bejegyzéseket készíthetnek tevékenységeikről. A

bejegyzések kezelését a „Logger” osztály végzi. Az osztály csak statikus és publikus

metódusokat tartalmaz, így minden osztály minden metódusa számára elérhető. Amelyik

osztály log bejegyzést szeretne készíteni, meghívja az „AddLog” metódust, melyben feltünteti

az osztály nevét, a metódus nevét, és magát a log üzenetet.

31

5 PC – Robot kommunikáció

A ChipKIT és a térképszerkesztő alkalmazás között kétirányú kommunikációs viszony

áll fent. Így a robot elmozdulásai nyomon követhetőek a térképen, illetve a térképszerkesztőből

is bármikor küldhető utasítás a robot számára. A kommunikáció TCP alapú, és egy

protokollrendszer segítségével történik.

A kommunikációt a résztvevő felek bármelyike kezdeményezheti. Minden megkezdett

kommunikáció a másik fél által küldött nyugtázó üzenettel zárul. A kommunikáció első része

egy parancs vagy egy kérés. Ugyanazon parancs vagy kérés nem küldhető ki újra, míg nem

érkezett meg a nyugta a másik féltől. Más parancs küldhető. A parancsot vagy kérést a parancs

vagy kérés paraméterei követik, melyek tetszőleges hosszúságúak lehetnek. Egy protokoll

sztring általános felépítése:

<{parancsnév, kérésnév, nyugtanév}[&param1=val1… &paramn = valn][&ok]>

A „<” jel új parancs kezdethatárolója.

A „>” jel a parancs végét jelzi.

A parancs, kérés, nyugta neve mindig a „<” jel után kell, hogy álljon.

Pontosan egy parancsnév, kérésnév, vagy nyugtanév lehet.

A parancsnak nem kötelező paramétereket tartalmaznia.

A paramétereket „&” jel határolja el egymástól és a parancsnévtől.

Egy paramétert a (név, érték) páros ír le (Kivétel nyugtánál az „&ok” paraméter).

A paraméter nevéhez tartozó érték csak szám lehet.

A protokoll sztring csak érvényes ASCII karaktereket tartalmazhat.

A parancs nem tartalmazhat nagybetűket

A parancs nem tartalmazhat szóközöket, és egyéb üres hely (white space) karaktereket.

Csak a nyugta üzenet tartalmazhat „&ok” paramétert

Az „&ok” paraméter mindig a „>” jel előtt kell, hogy álljon közvetlenül

Egy parancs után pontosan egy nyugta érkezhet. A nyugta tartalmazza a parancsot,

annak paramétereit, ha vannak, illetve az „&ok” paramétert, mely jelzi, hogy az üzenet egy

nyugta.

32

Egy kérésüzenetre több parancsüzenet is érkezhet. A parancsüzenetek felépítése a fent

leírtak alapján történik, viszont ebben az esetben is minden egyes parancsüzenetet egy

nyugtaüzenet kell, hogy kövessen.

Egy kommunikációs ciklus alatt legalább egy parancsüzenet, és egy nyugta, vagy egy

kérésüzenet, parancs, nyugta kell, hogy szerepeljen.

Példa egy kommunikációs ciklusra (14. ábra):

14. ábra Példa kommunikációs ciklusra

Másik példa, amikor egy kérésre több parancs érkezik, melyeket nyugtázni kell (15.

ábra):

15. ábra Összetett kommunikációs ciklus

33

A parancs, nyugta és kérésüzenetek listáját a 4. táblázat tartalmazza:

Parancs vagy kérés Nyugta Rövid leírás

<mapsize&nodes=x> <mapsize&nodes=x&ok> Kiküldődik, hány

csomópontból áll a térkép

<node&x=a&y=b> <node&x=a&y=b&ok> Kiküldődik egy (x, y)

koordinátájú csomópont

<nodesize&x=a&y = b> <nodesize&x=a&y = b&ok> Kiküldődik, hogy egy

csomópont mekkora méretű.

<start&x=a&y=b> <start&x=a&y=b&ok> Kiküldődik a start

csomópont

<target&x=a&y=b> <target&x=a&y=b&ok> Kiküldődik a cél csomópont

<getnewmap> <getnewmap&ok> Az egész térkép újraküldése

4. táblázat A kommunikációs parancsok nevei és leírása

34

6 A mikrokontroller programozása

6.1 Általános leírás

A vezérlő programozásánál nagy hangsúlyt kapott a modularitás kialakítása. Az

eszközök vezérlése önmagukban, külön-külön is működőképesnek kell, hogy legyenek, az

újrahasznosítás érdekében. Teljesen függetlennek kell lennie a vezérlést adó logikától,

útkeresőtől, állapottér felépítésétől. Éppen ezért minden eszközre, illetve logikailag jól

elkülöníthető részre külön kontroller osztályok lettek implementálva. A kontrollerek külön

osztályokba kaptak helyet, illetve egy telepített eszközhöz csak az eszközhöz tartozó kontroller

osztály férhet hozzá. Ez a tervezési minta hasonlít ahhoz, ahogy a saját számítógépünkön a

driverek segítségével férünk hozzá az eszközökhöz. A program belépési pontja a „.ino”

kiterjesztéssel rendelkező file. Kötelezően egy „void setup()”, mely egyszer fut le, és egy „void

loop()” függvényt tartalmaz, mely folyamatosan fut. Felépítése:

1: #include "DoxigeDoc.h" 2: #include "Logger.h" 3: #include "Node.h" 4: #include "BredthWidthSearch.h" 5: #include "SimpleList.h" 5: #include "Roomba.h" 7: #include "RobotController.h" 8: #include "AIController.h" 9: #include "Communication.h" 10: 11: using namespace CommChannels; 12: using namespace AI; 13: using namespace Controller; 14: Communication* communication =Communication::getInstance(); 15: AIController* aiController = AIController::getInstance(); 16: RobotController* robotController = RobotController::getInstance(); 17: BredthWidthSearch* bredthWidthSearch=BredthWidthSearch::getInstance(); 18: 19: void setup(){ 20: communication->Init(); 21: aiController->Init(); 22: robotController->Init(); 23: bredthWidthSearch->Init(); 24: } 25: 26: void loop(){ 27: communication->Run(); 28: aiController->Run(); 29: robotController->Run(); 30: bredthWidthSearch->Run(); }

35

A file elején (1-9 sor) azon további állományok definíciói szerepelnek, melyből a

program összetevődik. Miután a projekt komponensei definiálva lettek, definiálni kell azokat a

névtereket, melyekben az osztályok szerepelnek. Ezeket a „using namespace” utasításokkal

lehet megtenni (11-13 sor).

A kontroller osztályok singleton tervezési minta alapján készültek (emlékeztető: 4.2

fejezet, 4. bekezdés). Az osztályok példányának lekérése úgy történik, hogy deklarálunk egy

osztályra mutató mutatót, majd a mutatót az osztály példányára állítjuk, mely példányt az

osztály „getInstance()” statikus metódusán keresztül kérünk le (14-17 sor).

A kontroller osztályoknak kötelezően implementálniuk kell a „getInstance”, „Init” és

„Run” metódusokat, melyek kötelezően példányszintű, visszatérési érték nélküli publikus

láthatósági módosítóval ellátott metódusok. Ezen metódusok szolgálnak interfészül a „.ino”

kiterjesztésű fájl számára.

A „setup” függvényben foglalnak helyet a kontroller osztályok „Init” metódusai.

Szintén ugyanitt adhatóak át paraméterül az eszközhöz rendelt lábkiosztás (19-24 sor). Tehát,

ha meg szeretnénk változtatni egy eszköz csatlakoztatását (pl.: a mikrokontroller 71-es lábáról

áthelyezni a 73-as lábára), a programban azt csak ezen az egy helyen kell megváltoztatni. Nem

szükséges ismerni a program egész szerkezetét ahhoz, ha az eszközök fizika csatlakozóinak

helyét meg akarjuk változtatni. Ezzel párhuzamosan a kontroller osztálynak tudnia kell kezelni

az adott eszköztípusból bárhányat. Ez alatt értendő, ha írunk egy kontroller osztályt, mely egy

egyszerű kapcsoló állapotváltozását figyeli, azt úgy kell megírni. hogy bárhány kapcsoló

állapotváltozását tudja kezelni.

A „loop” függvényben kapnak helyet a kontroller osztályok „Run” metódusa (26-31

sor). Amennyiben egy kontroller osztálynak olyan feladata van, melyet periodikusan végre kell

hajtania, azt ebbe a metódusba kell elhelyezni. Erre példa, amikor a robot utasítást kap, hogy

menjen 300 mm-t, folyamatosan figyelni kell, hogy mekkora távot tett már meg. Minden

kontroller osztály egy „szeletet” kap ily módon a futási időből, és periodikusan, egymás után

végezhetik el tevékenységeiket. A minta maga után vonja azt, hogy a „Run” metódusokban, és

általában a kontroller osztályokban nem lehet végtelen ciklus, késleltetés, várakoztatás, hiszen

ekkor a többi kontroller osztály nem futhat addig, míg a vezérlés ebben az osztályban

tartózkodik.

36

6.2 Kapcsolatok kialakítása

A fejezet áttekintést nyújt arról, hogyan történik egy-egy parancs fogadása a

térképkészítő alkalmazástól, illetve milyen folyamatok játszódnak le a parancsok hatására. A

fejezet mélyebb megértése érdekében ajánlott letölteni a forráskódokat, és a dokumentációt a

szakdolgozat weboldaláról3, illetve a fejezettel párhuzamosan áttekinteni ezeket is.

A kommunikáció fenntartását a térképszerkesztő alkalmazással a „Communication”

osztály végzi. A kontroller osztályok „Send” metódusán keresztül küldhetnek ki üzenetet, mely

metódusnév túl van terhelve. A fogadás egy periodikusan ismétlődő esemény, így az „Run()”

metódusban történik. A metódus, mikor a „.ino” fájlban rá kerül a vezérlés, meghívja a

„Collect()” metódust. A metódus feladata, ha van fogadható karakter, azt pufferbe gyűjtse.

Mindaddig gyűjti a karaktereket, amíg a protokoll sztring végét jelző „>” jelet el nem küldték.

Ha ez elküldésre került, meghívja a „Distribute” metódust, és átadja neki a puffert. A metódus

feladata, hogy kiválogassa, melyik kontroller osztályhoz érkezett az üzenet, melyik képes azt

feldolgozni. Megnézi az üzenet első paraméterét, mely az üzenet neve, és ennek függvényében

továbbítja azt a „címzett” osztályhoz. Az üzenetet előkészíti feldolgozásra: feldarabolja azt „&”

jelek mentén, és char** - ként küldi tovább, tehát karakterek tömbjét tartalmazó tömbként. (16.

ábra)

16. ábra Üzenetek szétválogatása

Az osztálynak nem feladata az üzenet feldolgozása, analógiával élve ő tölti be a postás

szerepét: összegyűjti a feladott leveleket, megnézi hová címezték, és kézbesíti azt.

3 http://shrek.unideb.hu/~erdosa/

37

A kontroller osztályoknak kötelezően interfészeket kell implementálniuk a

„Communication” osztály felé. Minden kontroller, mely üzeneteket fogad, rendelkeznie kell az

üzenetet pontosan feldolgozni tudó metódussal.

Az „AIController” osztály „ReceiveMapSizeCommand” metódusát hívja meg a

„Communication” osztály, amennyiben a térkép méretei érkeznek. A metódus megkapja a

karaktertömbök tömbjének méretét, és a leghosszabb karaktertömb méretét, majd a

„Getparams” metódusa segítségével meghatározza a „size=x” paraméterből az x értékét. Ez

fogja jelenteni, hány csomópontot tartalmaz a térkép.

Az üzenetek feldolgozása minden kontroller osztályban egységesen, e minta alapján

történik.

6.3 Eszközök vezérlése

6.3.1 Roomba Irobot Create Open Interface vezérlése

A robot vezérlését a „RobotController” osztály végzi Ez egy általánosan megírt osztály,

mely interfészt biztosít a vezérlő többi osztálya számára, és elrejti a robot konkrét vezérlését.

Kialakításának az oka, hogy az algoritmusok más robotra történő implementálása alatt ne

kelljen az egész vezérlőt átírni, csak ezt az egy osztályt. Az osztály készít a

„Roomba”osztályból egy példányt, mely ténylegesen az OI-t (robotot) vezérli.

A legfontosobb, a robot vezérléséhez kapcsolódó függvény a „GoAhed”, melynek

prototípusa:

uint16_t RobotController::GoAhed(int16_t speed, uint16_t distance)

Az függvény első paramétere mondja meg, hogy milyen gyorsan menjen a robot (mm/s),

a második pedig azt, hogy mekkora távolságot. A függvény visszatérési értéke a megtett

távolság. Ha a visszatérési érték kisebb, mint az átadott távolság paraméter, a robotnak nem

sikerült eljutnia, ahová küldtük, ha megegyezik vele, akkor igen.

1: uint16_t RobotController::GoAhed(int16_t speed, uint16_t atmero){ 2: int8_t distance[2], packetID = 19 len = 2, travelled = 0, carry = 0; 3: uint16_t distCount = 0;

38

4: roomba->driveDirect(speed, speed); 5: roomba->getSensors(packetID, distance, len); 6: do{ 7: if ((carry * 128 + travelled) >= atmero - 10){ 8: roomba->driveDirect(0, 0); 9: return carry * 128 + travelled; 10: }else{ 11: if (distCount > 10){ 12: int IDCliff = 7, lenCliff = 1 13: int8_t destCliff[1]; 14: roomba->getSensors(IDCliff, destCliff, len); 15: if ( destCliff[0] != 0 ){ 16: roomba->driveDirect(0, 0); 17: return carry * 128 + travelled; 18: } 19: distCount = 0; 20: } 21: distCount++; 22: roomba->getSensors(packetID, distance, len); 23: if (distance[1] > 0){ 24: travelled += distance[1]; 25: } 26: if (travelled > 127){ 27: carry++; 28: travelled = 0; 29: } 30: } 31: } while (true); 32: }

A 4. sorban található „Roomba” osztálybeli „driveDirect” függvény két paramétert vár,

a jobb és a bal kerék sebességét mm/s –ban. A robot a paraméterben átadott sebességgel fog

mozogni a függvényhívás után.

A „getSensors” függvény vár egy „packedID” nevű változót, mely azonosítja a

használni kívánt szenzort. Itt a 19 – es azonosítóval ellátott szenzor kell, mivel ez meg tudja

mondani, hogy a szenzor utolsó lekérése óta a robot mekkora távolságot tett meg. A függvény

vár még egy előjel nélküli 8 biten ábrázolható egészeket tartalmazó tömbre mutató mutatót,

mely a „distance” nevű paraméter lesz, illetve várja ennek a tömbnek a hosszát, mely a „len”

változó lesz. A dokumentáció szerint a visszaadott távolság -65565 – 65565 tartományban

mozoghat, emiatt kell az átadott tömbnek 2 hosszúnak lennie. Ezen a függvényen keresztül kell

ciklikusan lekérdezni, hogy mekkora távolságot tett meg a robot, az értékeket összeadni, és ha

már elérte a paraméterben átadott távolságot, megállítani.

39

A függvény az átadott referencián keresztül a „distance[2]” tömbbe pakolja bele a

távolságokat. A „distance [0]” fogja tartalmazni a szám első felét, a felső 8 bájtját, a „distance

[1]” pedig a másikat, az alsó 8 bájtját. A tömbben 2 db előjel nélküli 8 bites egész található. 8

biten 28 db szám fér el, tehát 256 különböző számjegy. Amikor a dest[1] "túlcsordul", vagyis a

benne található bitkombináció mind 1-es, akkor kell a dest[0] -hoz hozzáadni 1-et.

Legyen a függvénytől visszakapott bitsorozat 0000000100001011. Ekkor a dest[0] =

2b'00000001 és dest[1] = 2b'00001011 . A tömbben található érték: 256*20 + 1*11 = 267, tehát

ezeknél az értékeknél 267 mm-t ment előre a robot.

A 6. sortól a 31. sorig egy ciklus segítségével a mikrokontroller lekéri a megtett

távolságot, és összeadja őket. Figyeli, hogy a robot neki ment-e valaminek a

„getSensors(IDCliff, destCliff, len)” függvény segítségével. Amennyiben nekiment, visszatér a

megtett távolsággal, nem sikerült elmenni a célba.

A „GoBack” függvény hasonlóan működik a „GoAhed” függvényhez, különbség, hogy

a robot elindításánál a „driveDirect” függvény jobb és bal kerék sebességének negatív értéket

adunk meg. A „TurnRight” függvényhívás esetében a jobb keréknek 0, a bal keréknek pozitív,

a „TurnLeft”esetében pedig fordítva, a bal keréknek 0, a jobb keréknek pozitív értéket kell

megadni.

A robot minden fordulásnál számon tartja saját orientációját. Az (5. táblázat)

tartalmazza, ha a robotot a különböző irányokba szeretnénk elküldeni, milyen komponensekből

fog összetevődni a mozgása. A „” jel azt jelenti, hogy a robotnak 90 fokot balra, míg a „”

jel azt, hogy 90 fokot jobbra kell fordulni. A „Go” felirat jelöli, ha már az orientáció helyes, a

robot elindulhat.

A valós égtájak A robot orientációja

Észak Kelet Dél Nyugat

40

Észak Go , Go ,, Go ,Go

Kelet , Go Go , Go , , Go

Dél , , Go . Go Go , Go

Nyugat , Go , , Go , Go Go

5. táblázat A robot és a világ orientációja

6.3.2 Wifly RN-XV 171 WiFi modul konfigurálás

A modul kétféle üzemmódban képes működni: van egy szabványos adat küldés, fogadás

üzemmód, és egy konfiguráló üzemmód. A legegyszerűbben az eszközt úgy lehet konfigurálni,

ha készítünk egy programot, mely a mikrokontroller számítógéphez csatlakoztatott soros

portjáról olvas, és a WiFi modul soros portjára ír, illetve fordítva, a WiFi soros portjáról olvas,

és a számítógép soros portjára ír. A soros port ajánlott beállításai:

Baud rate: 9600

Data bit: 8

Parity bit: 1

Stop bit: 1

A konfiguráló sketch megírása után (17. ábra), a soros port monitor megnyitása

következik (Arduino IDE környezetben a jobb felső sarokban található). Ahhoz hogy a WiFi

modul adat küldés és fogadás üzemmódból konfigurációs üzemmódba váltson, be kell írni a

soros monitor bemeneti mezőjébe „$$$” parancsot, majd elküldeni úgy, hogy a végére a

monitor hozzáfűzzön egy kocsi vissza jelet. Amennyiben megérkezett a „CMD” válaszüzenet,

folytatható tovább a konfigurálás. Amennyiben a modul a begépelt parancsot, vagy semmit sem

küldött vissza, ajánlott megismételni a műveletet.

41

17. ábra A WiFi modul konfiguráló programkód

Az AP parancsok listája a microchip4 honlapján is elérhetőek. A modul alapértelmezett

firmware verziója 4.00. Az alapértelmezett IP címe, mikor ad-hoc módban üzemel 1.2.3.4. Ezt

legkönnyebben úgy lehet ellenerőzni, ha telnet segítségével kapcsolatot alakítunk ki számítógép

és a modul között a 2000 –es porton. Ha a kapcsolat kialakítása sikerült, a modulon egy zöld

led fog folyamatosan világítani.

Ajánlott először a konfigurálást a WiFi modul alaphelyzetbe állításával kezdeni. Ezt

hardveresen és szoftveresen is meg lehet tenni. Hardveresen a modul 8-as lábát kell magasra

(3.3V) majd alacsonyra állítani, egymás után 5 alkalommal, maximum 200 ms késleltetési

idővel. Ha sikeres volt a művelet, egy kis idő elteltével (nagyjából fél perc) megjelenik a modul

hálózati SSID –je a számítógép hálózati kapcsolatai között. Az alapértelmezett SSID „Wifly-

EXZ-XX”, ahol „XX” a modul MAC címének utolsó két bájtja. Szoftveresen az alábbi

parancssorozat kiadásával lehet a modult visszaállítani a gyári beállításokra:

1) factory RESET

2) save

3) reboot

Ugyanazon eredményt lehet így elérni, mint a hardveres alaphelyzetbe állítással.

4 http://ww1.microchip.com/downloads/en/DeviceDoc/rn-wiflycr-ug-v1.2r.pdf

42

Amennyiben meg szeretnénk tekinteni a modul kapcsolatainak beállítását, be kell írni a

soros monitor beviteli mezőjébe a „get ip” parancsot, ha a modul minden beállítását szeretnénk

megnézni, akkor a „get everithyng” parancsot.

A modul az adatokat kétféle infrastruktúrán keresztül képes küldeni. Az egyik, az

úgynevezett „AP mode”, mely segítségével vezeték nélküli hozzáférési ponthoz (például

router) csatlakozva képes kommunikálni, illetve a „soft AP mode”, mely segítéségével ő maga

létesít vezeték nélküli hozzáférési pontot (úgy lehet csatlakozni hozzá számítógéppel, ahogyan

egy routerhez).

„AP mode” kialakítása konfigurációs parancsok segítségével:

$$$

Belépés konfigurációs módba. Ezt az egy parancsot kocsi vissza végjellel kell küldeni.

Az összes többit végjel nélkül. Minden parancs után a modul küld visszajelzést.

(helytelen begépelés esetén is).

factory RESET

Gyári beállítások visszaállítása.

save

Elmenti a gyári beállításokat.

reboot

Újraindítja a modult. Ilyenkor kilép a konfigurációs módból.

$$$

Újra belép konfigurációs módba.

set ip dhcp 1

A modul használjon DHCP-t. A 0 érték jelenti azt, hogy ne használjon.

set wlan phrase <passphrase-for-the-SSID>

Beállítja a hálózati jelszót. Ha nem szeretne jelszót, ezt a lépést hagyja ki.

43

set wlan ssid <SSID>

Jelzi az SSID –t az AP számára, hogy csatlakozni szeretne hozzá.

set wlan auth 4

Megmondja a hálózati jelszó titkosításának típusát. A 4-es érték WPA2-PSK.

set wlan join 1

Csatlakozik a hozzáférési ponthoz.

set ip localport 80

A modult a 80-as porton lehet majd elérni. Ezen porton, amennyiben HTML

szabványnak megfelelő üzeneteket küld, akár web böngésző segítségével is meg lehet

jeleníteni a fogadott tartalmat.

set sys autoconn 1

Jelzi, ha az AP elérhető, mindig szeretne csatlakozni hozzá ezentúl

save

Elmenti a konfigurációs beállításokat.

exit

Kilép a konfigurációs módból, és átvált adat küldés és fogadás módba.

Előfordulhat, hogy az „AP mode” nem támogatott a modulon. Ennek oka, hogy egy

régebbi firmware típust használ, melyet előbb frissíteni kell.

„Soft AP mode” kialakítása konfigurációs parancsok segítségével:

$$$

factory RESET

save

reboot

$$$

set ip address <pontozott decimális alak>

44

Beállítja az eszköz ip címét, például 169.254.1.1

set ip netmask <az IP-hez tartozó netmask>

Beállítja az IP címhez tartozó hálózati maszkot, például 255.255.0.0

set wlan SSID <saját ad hoc hálózat>

Beállítja, hogy az eszköz milyen néven látszódjon a hálózaton.

set wlan chan 1

Beállítja, hogy milyen csatornán kommunikáljon (nincs mód dinamikus

csatornakiosztásra).

set ip dhcp 0

A modul ne használjon DHCP-t

save

reboot

Ezen konfigurációs lépések végrehajtása után kezdődik meg a kommunikáció a

mikrokontroller és a számítógépes alkalmazás között. A modul „Soft AP mode” szerint van

felkonfigurálva, melynek hálózati azonosító címe: "169.254.1.2", illetve a 2000 porton

keresztül kommunikál.

6.4 Állapottér reprezentáció

A robot a szerkesztett és feltöltött térképen egy bizonyos szabályrendszer szerint

mozoghat. A szabályrendszer tartalmazza mindazon térbeli, és orientációbeli változásokat,

amelyet a robot végezhet mozgása során. Továbbá a térkép szerkesztésére vonatkozó

mindennemű megszorítást. A szabályrendszer pontos definiálása lesz az állapottér-

reprezentáció.

Legyen p egy probléma. A probléma meghatározása során megkeressük a probléma

világának a probléma szempontjából fontosnak vélt tulajdonságait (véges sok lehet). A

tulajdonságok számszerűsíthetőek kell, hogy legyenek, és minden tulajdonsághoz értékeket

rendelünk. Amennyiben a megadott tulajdonságok (h1 … hn) értékkel rendelkeznek, akkor a p

világa az érték n-essel leírt állapotban van. Ezen állapotok halmaza lesz az állapottér. [8]

45

Azt mondjuk, hogy a p problémát állapottér-reprezentáltuk, ha megadtuk az

<A, Kezdő, Cél, O>

négyest, azaz

- az A ≠ 0 halmazt, a probléma állapotterét,

- a Kezdő ∈ A kezdőállapotot,

- a célállapotok Cél⊂A halmazát, és

- az operátorok O ≠ 0 halmazát. [8]

A robot mozgása során ismernie kell a térképet, amelyen operálnia kell, tudnia kell,

hogy a térkép mely pontján helyezkedik el, ami a start helyzete lesz. Tudnia kell, hogy hová

akar menni, tehát adni kell neki egy cél pozíciót. Tudnia kell, hogy milyen szabályok szerint

tud elmenni az adott pozícióba. Végül pedig tudnia kell azt is, hogy a térkép egyes pontjait

melyik irányból közelítette meg. Ez utóbbi meghatározás fogja adni a robot orientációját.

6.4.1 Állapottér

Legyen az X egy halmaz, úgy hogy X = {∀x ∈ X | x ∈ Z }

Legyen az Y egy halmaz, úgy hogy Y = {∀y ∈ Y | y ∈ Z}

Legyen a TÍPUS egy halmaz, úgy hogy TÍPUS = {SZABAD, AKADÁLY, CÉL, START}

Legyen az ORIENTÁCIÓ5 egy halmaz, úgy hogy ORIENTÁCIÓ = {ÉSZAK, KELET, DÉL,

NYUGAT}

A NODE halmaz az X halmaz, Y halmaz, TÍPUS halmaz és ORIENTÁCIÓ halmaz

Descartes-szorzata, mely a térképen elhelyezett csomópontokat fogja definiálni:

NODE = {X * Y * TÍPUS * ORIENTÁCIÓ}

Az (X * Y) halmazok Descartes-szorzatát nevezhetjük koordináta-pároknak is, melyek

egy-egy csomópont helyzetét azonosítják a síkon.

5 A robot minden egyes állapotban számon tartja saját orientációját. Kezdetben a robot mindig északnak néz, illetve

minden fordulásnál ehhez az értékhez viszonyítva frissíti az orientáció állapotát

46

6.4.1.1 Kényszerfeltételek

Az állapottérre vonatkozó kényszerfeltételek megadása kötelező. Ezektől a feltételektől

függ, hogy a térképszerkesztőben hogyan szerkesztő a térkép. A kényszerfeltételek

implementálva vannak az alkalmazásba, így kikényszerítve azt, hogy csak olyan térképet

lehessen szerkeszteni, mely az állapottér reprezentációnak megfelel. A feltételek az alábbiak:

Minden új csomópontnak kell, hogy legyen legalább egy, de maximum négy

szomszédja.

∀n’(X’, Y’, TÍPUS’, ORIENTÁCIÓ’) ∈ NODE ⊃ ∃n (X, Y, ORIENTÁCIÓ) ∧ n (X, Y, TÍPUS, ORIENTÁCIÓ) ∈ NODE ∧ (X’ =

X+1 ∨ X’ = X-1) ∧ (Y’ = Y+1 ∨ Y’ = Y-1)

Maximum egy cél csomópont létezhet.

0 ≤ |{∀n (X, Y, TÍPUS, ORIENTÁCIÓ) | n (X, Y, TÍPUS, ORIENTÁCIÓ) ∈ NODE ∧ TÍPUS = CÉL}| ≤ 1

Pontosan 1 start csomópont létezhet

|{∀n (X, Y, TÍPUS, ORIENTÁCIÓ) | n (X, Y, TÍPUS, ORIENTÁCIÓ) ∈ NODE ∧ TÍPUS = START}| = 1

Minden új, szabad csomópontnak kell, hogy legyen legalább egy, de maximum négy

olyan szomszédja, mely szabad

∀n’(X’, Y’, TÍPUS’, ORIENTÁCIÓ’) ∈ NODE ∧ TÍPUS = SZABAD ⊃ ∃n (X, Y, TÍPUS, ORIENTÁCIÓ) ∧ n (X, Y, TÍPUS,

ORIENTÁCIÓ) ∈ NODE ∧ TÍPUS = SZABAD ∧ (X’ = X+1 ∨ X’ = X-1) ∧ (Y’ = Y+1 ∨ Y’ = Y-1)

A kezdő csomópontnak legalább egy szabad szomszédja kell, hogy legyen

∀n’(X’, Y’, TÍPUS’, ORIENTÁCIÓ’) ∈ NODE ∧ TÍPUS = START ⊃ ∃n (X, Y, TÍPUS, ORIENTÁCIÓ’) ∧ n (X, Y, TÍPUS,

ORIENTÁCIÓ) ∈ NODE ∧ TÍPUS = SZABAD ∧ (X’ = X+1 ∨ X’ = X-1) ∧ (Y’ = Y+1 ∨ Y’ = Y-1)

A cél csomópontnak legalább egy szabad szomszédja kell, hogy legyen

∀n’(X’, Y’, TÍPUS’, ORIENTÁCIÓ’) ∈ NODE ∧ TÍPUS = CÉL ⊃ ∃n (X, Y, TÍPUS, ORIENTÁCIÓ) ∧ n (X, Y, TÍPUS,

ORIENTÁCIÓ) ∈ NODE ∧ TÍPUS = SZABAD ∧ (X’ = X+1 ∨ X’ = X-1) ∧ (Y’ = Y+1 ∨ Y’ = Y-1)

6.4.2 Kezdőállapot

Kezdőállapotnak minden olyan állapot megfelel, melyben az állapottér tartalmaz

csomópontokat, és tartalmaz pontosan egy START csomópontot. A kezdőállapot lesz az az

állapot, amikor a robotot leteszi a felhasználó a térképen megjelölt helyre.

47

Kezdő = {|NODE| > 0 ∧ ∃(n (X, Y, TÍPUS, ORIENTÁCIÓ) ∈ NODE ∧ TÍPUS = START)}

6.4.3 Célállapot

Célállapotnak bármilyen állapot megfelel, ahol az állapottér tartalmaz csomópontokat,

tartalmaz továbbá egy START és egy CÉL csomópontot, illetve a kezdő csomópont és a cél

csomópont (x, y) koordinátája egybeesik.

Cél = {∃n’(X’, Y’, TÍPUS’, ORIENTÁCIÓ’) ∈ NODE ∧ ∃n’’(X’’, Y’’, TÍPUS’’, ORIENTÁCIÓ’’) ∈ NODE ∧ TÍPUS’ =

START ∧ TÍPUS’’ = CÉL ∧ X’ = Y’ ∧ X’’ = Y’’}

6.4.4 Operátorok

A robot a térképen való mozgása során egy csomópontot mehet észak, kelet, dél vagy

nyugat irányába, rendre az E (előre), H (hátra), FJ (fordulj jobbra), FB (fordulj balra) sorozatos

alkalmazásával. Ezen operátorok alkotják az operátorok halmazát:

O = {E, H, FJ, FB}

6.4.4.1 Operátoralkalmazási előfeltétel

Az előre és a hátra operátor alkalmazására igaz, hogy akkor és csak akkor alkalmazható,

ha létezik olyan szomszédos csomópont, mely állapota szabad. Azt, hogy melyik szomszédos

csomópontra kell, hogy teljesüljön a feltétel, az orientáció dönti el. Például, ha a robot

orientációja KELET, illetve az (5,5) koordinátájú csomóponton áll, akkor, és csak akkor

alkalmazható az előre vagy a hátra operátor, ha az állapottér tartalmaz egy (6,5) koordinátájú

csomópontot is, mely csomópont állapota szabad.

Az E(X, Y, TÍPUS, ORIENTÁCIÓ) és a H(X, Y, TÍPUS, ORIENTÁCIÓ) operátor alkalmazható ∀a ∈ A

állapotban, melyben teljesül, hogy

dom(E(X, Y, TÍPUS, ORIENTÁCIÓ)) = dom(H(X, Y, TÍPUS, ORIENTÁCIÓ)) =

{a ∈ A | ORIENTÁCIÓ = ÉSZAK ∧ TÍPUS = START ⊃ ∃(n’(X’, Y’, TÍPUS’, ORIENTÁCIÓ’) ∈ NODE ∧ Y’ = Y+1 ∧ TÍPUS = SZABAD ) } ∨

{a ∈ A | ORIENTÁCIÓ = KELET ∧ TÍPUS = START ⊃ ∃(n’(X’, Y’, TÍPUS’, ORIENTÁCIÓ’) ∈ NODE ∧ Y’ = X+1 ∧ TÍPUS = SZABAD ) } ∨

{a ∈ A | ORIENTÁCIÓ = DÉL ∧ TÍPUS = START ⊃ ∃(n’(X’, Y’, TÍPUS’, ORIENTÁCIÓ’) ∈ NODE ∧ Y’ = Y-1 ∧ TÍPUS = SZABAD ) } ∨

{a ∈ A | ORIENTÁCIÓ = NYUGAT ∧ TÍPUS = START ⊃ ∃(n’(X’, Y’, TÍPUS’, ORIENTÁCIÓ’) ∈ NODE ∧ X’ = X-1 ∧ TÍPUS = SZABAD ) }

48

Az FJ (fordulj jobbra) és FB (fordulj balra) operátorokat alkalmazva az adott

koordinátán levő robot orientációja változik csak. A robot a forgás során ugyanazon a

csomóponton forog, saját középpontja körül. Az FJ operátor egyszeri alkalmazása a robot

elfordulását jelenti 90°-al az óramutató járásával megegyező irányba, míg az FB operátor az

óramutató járásával ellentétes irányba 90°-al. Ennek megfelelően változik a csomópont

orientációja is.

Az FJ(X, Y, TÍPUS, ORIENTÁCIÓ) és a FB(X, Y, TÍPUS, ORIENTÁCIÓ) operátor alkalmazható ∀a ∈ A

állapotban:

dom(FJ(X, Y, TÍPUS, ORIENTÁCIÓ)) = dom(FB(X, Y, TÍPUS, ORIENTÁCIÓ)) = {∀a ∈ A }

6.4.4.2 Operátorok hatásdefiníciója

Az E és H operátorok alkalmazásával az új csomópont, ahová a robot eljutott start

csomóponttá válik, ahonnan eljutott, az pedig szabaddá.

Az előre (E) operátor hatásdefiníciója:

a ∈ dom(E(X, Y, TÍPUS, ORIENTÁCIÓ))

E(X, Y, TÍPUS, ORIENTÁCIÓ) = (X’, Y’, TÍPUS’, ORIENTÁCIÓ’)

TÍPUS’ = START

TÍPUS = SZABAD

A hátra (H) operátor hatásdefiníciója:

a ∈ dom(H(X, Y, TÍPUS, ORIENTÁCIÓ))

H(X, Y, TÍPUS, ORIENTÁCIÓ) = (X’, Y’, TÍPUS’, ORIENTÁCIÓ’)

TÍPUS’ = START

TÍPUS = SZABAD

Az FJ és FB operátorok alkalmazásával a robot saját tengelye körül fog elfordulni, tehát

csak az orientációja változik.

Az FJ (fordulj jobbra) operátor hatásdefiníciója:

49

a ∈ dom(FJ(X, Y, TÍPUS, ORIENTÁCIÓ))

FJ (X, Y, TÍPUS, ORIENTÁCIÓ) = (X’, Y’, TÍPUS’, ORIENTÁCIÓ’)

ORIENTÁCIÓ’=ORIENTÁCIÓ/{ÉSZAK, KELET, DÉL, NYUGAT}∧|ORIENTÁCIÓ’|= 1

Az FB (fordulj balra) operátor hatásdefiníciója:

a ∈ dom(FJ(X, Y, TÍPUS, ORIENTÁCIÓ))

FB (X, Y, TÍPUS, ORIENTÁCIÓ) = (X’, Y’, TÍPUS’, ORIENTÁCIÓ’)

ORIENTÁCIÓ’=ORIENTÁCIÓ/{ÉSZAK, KELET, DÉL, NYUGAT}∧|ORIENTÁCIÓ’|= 1

6.4.5 Magasabb szintű mozgásformák

Az O halmaz elemeit sorozatosan alkalmazva felépíthető olyan bonyolultabb mozgási

forma, mint „menj északra”, „menj keletre”, „menj délre”, „menj nyugatra” egy csomópontot,

az alábbi szabályrendszert alkalmazva:

Legyen n(X, Y, TÍPUS, ORIENTÁCIÓ) ∈ NODE. Ekkor:

Menj északra:

ORIENTÁCIÓ = ÉSZAK ⊃ alkalmaz (E)

ORIENTÁCIÓ = KELET ⊃ alkalmaz (FB), alkalmaz (E)

ORIENTÁCIÓ = DÉL ⊃ alkalmaz (FB), alkalmaz (FB), alkalmaz (E) ∨ alkalmaz (H)

ORIENTÁCIÓ = NYUGAT ⊃ alkalmaz (FJ), alkalmaz (E)

Menj keletre:

ORIENTÁCIÓ = ÉSZAK ⊃ alkalmaz (FJ), alkalmaz (E)

ORIENTÁCIÓ = KELET ⊃ alkalmaz (E)

ORIENTÁCIÓ = DÉL ⊃ alkalmaz (FB), alkalmaz (E)

ORIENTÁCIÓ = NYUGAT ⊃ alkalmaz (FJ), alkalmaz (FJ), alkalmaz (E) ∨ alkalmaz (H)

Menj délre:

50

ORIENTÁCIÓ = ÉSZAK ⊃ alkalmaz (FB), alkalmaz (FB), alkalmaz (E) ∨ alkalmaz (H)

ORIENTÁCIÓ = KELET ⊃ alkalmaz (FJ), alkalmaz (E)

ORIENTÁCIÓ = DÉL ⊃ alkalmaz (E)

ORIENTÁCIÓ = NYUGAT ⊃ alkalmaz (FB), alkalmaz (E)

Menj nyugatra:

ORIENTÁCIÓ = ÉSZAK ⊃ alkalmaz (FB), alkalmaz (E)

ORIENTÁCIÓ = KELET ⊃ alkalmaz (FJ), alkalmaz (FJ), alkalmaz (E) ∨ alkalmaz (H)

ORIENTÁCIÓ = DÉL ⊃ alkalmaz (FJ), alkalmaz (E)

ORIENTÁCIÓ = NYUGAT ⊃ alkalmaz (E)

6.5 Legrövidebb út keresés

Megadtuk az állapottér leírását az <A, Kezdő, Cél, O> négyes segítségével. Ez a

reprezentáció egy irányított gráfot határoz meg. Az A állapottér elemei a gráf csúcsai. Ha

bevezetjük az a ∈ A csúcsra az na jelölést, akkor N = {na | a ∈ A}. A gráf csúcsai közül

megkülönböztetünk startcsúcsot, (nstart vagy S), és terminális csúcsokat (T = {nc | c ∈ Cél}),

melyek a célállapotokat szemléltetik. Minden csúcsból irányított élt húzva abba a csúcsba,

amely közvetlenül elérhető az adott csúcsból

E = {(na ,na’) | a, a’ ∈ A és a ⇒ a’}

megkapjuk az

<A, Kezdő, Cél, O> állapottér reprezentációhoz tartozó <N,S,T,E> [8] állapottér gráfot.

Az útkeresés kiválasztásánál szem előtt kellett tartani, hogy a robot a legrövidebb úton

találjon el a célba, ne kerüljön zsákutcába, miközben halad. Képzeljünk el egy olyan helyzetet,

melyben a robot mozgása közben határozza meg, hogy melyik legyen az a csomópont,

amelyikre menni szeretne (18. ábra).

51

18. ábra Egy helytelen útkeresés szemléltetése

A robot az első lépés megtétele után döntési helyzetbe kerül, hogy a zöld nyíllal jelölt

utat kövesse, vagy a pirosat. Mivel a keresőalgoritmus nem állította elő az összes lehetséges

útvonal közül a legoptimálisabbat, így mozgás során fog ez kiderülni számára. Azt, hogy a

robot a piros vagy a zöld nyíllal jelölt utat fogja követni, ebben az esetben implementációfüggő,

nem evidens. Amennyiben a robot a piros nyíllal jelölt utat választja (metrika vagy bármely

más okból), a keresőalgoritmus rá fog jönni, hogy zsákutcába került, és visszalépést fog

alkalmazni. Tehát ez a robot számára nem a legrövidebb út lesz. A kereső algoritmust tehát két

részre kell bontani:

1. A robot mozgatása nélkül meg kell határozni a legrövidebb utat, azaz az összes lehetséges

út közül ki kell választani azt az egyet, amelyen a robot a legkisebb távolság megtételével

a célba tud érni. A keresés során tekintettel kell lenni arra, hogy a térkép gráfja köröket

tartalmazhat, mivel ha az egyik csomópontból egy másik elérhető, akkor ez fordítva is igaz.

2. A robotot végig kell vezetni az 1. lépésben meghatározott úton.

Olyan algoritmust kellett tehát szerkeszteni, mely heurisztikus, visszalépéses,

körfigyeléses legrövidebb útkereső algoritmus. Az algoritmus két részét pedig egy vezérlőnek

kell összekapcsolnia, mely koordinálja és biztosítja a két rész közötti megfelelő

információáramlást.

52

6.5.1 Metrika értelmezése

Legyen C(X’, Y’, TÍPUS’, ORIENTÁCIÓ’) ∈ Cél és N(X, Y, TÍPUS, ORIENTÁCIÓ) ∈ A. Ekkor az

<A,Kezdő,Cél,O> állapotérhez tartozó <N,S,T,E> állapottér gráf csúcsai között legyen

értelmezve az alábbi M metrika ∀N ∈ A esetén:

𝑁𝑚𝑒𝑡𝑟𝑖𝑘𝑎 = √( 𝑋′ − 𝑋 )2 + ( 𝑌′ − 𝑌 )2

A metrika legyen tehát minden csúcsra vonatkozóan az adott csúcs, és a cél csúcs

közötti euklideszi távolság.

6.5.2 A kereső felépítése

A kereső első lépésben megkeresi a legrövidebb utat a térképen a startból a célba, a

robot mozgatása nélkül. kialakít egy útvonal nyilvántartást, mely alapján a második lépésben

végigvezeti a robotot a célig. Mielőtt belekezdenénk a konkrét algoritmusok magyarázatába,

egy példán keresztül szeretném szemléltetni, miért volt szükséges a keresőnek ilyen struktúrát

kialakítani.

19. ábra A kereső működése

A (19. ábra) csomópontoknak egy halmazát tartalmazza, melyeket élek kötnek össze.

Minden csomópont felső részén a csomóponthoz rendelt metrika (526.5.1 fejezet alapján) áll.

A középső részén a csomópont egyedi azonosítója, vagy koordinátája, és az alsó részén pedig

53

jelölésre került, hogy start vagy cél csomópont-e. A kereső mindig a legkisebb heurisztika felé

megy. Az ábrán tehát a ( (2;0), (2;1), (3;1), (4;1) ) csomópontokat fogja bejárni. Miután

zsákutcába került, visszalép mindaddig, míg nem talál olyan csomópontot, amelyiknél másik

irányba is mehet. A visszalépés során az adott csomópontokat elfelejti. Ez a ( (4;1), (3;1), (2;1))

csomópontok bejárása lesz. A (2;1) csomópontból a kereső a ( (1;1), (0;1), (0;2), (0;3), (1;3),

(2;3), (3;3), (4,3)) csomópontokat bejárva jut el a célba. A kereső 12 csomópontot járt be, mire

megtalálta a 10 csomópontból álló legrövidebb utat (mivel azokat a csomópontokat, amelyekről

visszalépett, elfelejti). Könnyen belátható, hogy az útkeresés alatt a robotot célszerű nem

mozgatni, a keresést csak logikailag elvégezni. A megtalált legrövidebb úton a kereső második

felében a robot mozgatásával végig lehet menni. Az, hogy ez az út valóban a legrövidebb, a

kereső első fele garantálja.

A keresés első lépésében a kereső nyílván tartja az összes csomópontot a térképen,

ahová a robot mehet. Minden csomópontot ellát heurisztikával. Kiterjesztésre kiválasztja az

aktuális csomópont minden egyes, közvetlenül elérhető szomszédját, majd alkalmazza rá az

összes operátort. Az előállt új csomópontokat összegyűjti a nyíltak közzé, majd kiválasztja a

legkisebb heurisztikájút. Az aktuális csomópontot beteszi a zártak közzé. Az új aktuális

csomópont a legkisebb heurisztikájú lesz. Aktuális csomópont választásnál a szülő

csomópontot választja legutoljára, még akkor is, ha kisebb a heurisztikája, mint bármelyik más

szomszédjának

1: function Legrövidebb_út_kereső(<A,Kezdő,Cél,O>)

2: visited ← NULL

3: path ← NULL

4: calcHeuristic(<A,Kezdő,Cél,O>)

5: while IGAZ do

6: if Kezdő = Cél then

7: return path

8: end if

9: visited ← Kezdő

10: northNode ← Választ(cs | cs ∈ A ∧ cs[x]=akt[x] ∧ cs[y]=akt[y+1] ∧ cs[szülő] ≠ northNode)

54

11: eastNode ← Választ(cs | cs ∈ A ∧ cs[x]=akt[x+1] ∧ cs[y]=akt[y] ∧ cs[szülő] ≠ eastNode )

12: southNode ← Választ(cs | cs ∈ A ∧ cs[x]=akt[x] ∧ cs[y]=akt[y-1] ∧ cs[szülő] ≠ southNode )

13: westNode ← Választ(cs | cs ∈ A ∧ cs[x]=akt[x-1] ∧ cs[y]=akt[y] ∧ cs[szülő] ≠ westNode )

14: northNode[Szülő] ← eastNode[Szülő] ← southNode[Szülő] ← westNode[Szülő] ← act

15: if northNode ∪ eastNode ∪ southNode ∪ westNode = {∅} then

16: pathlist ← pathlist \ act

17: act ← act[Szülő]

18: else

19: act ← MinHeuristic(northNode, eastNode, southNode, westNode)

20: pathList ← act

21: end if

22: end while

23: end function

6.5.3 Navigálás az előállított útvonalon

A kereső második lépésben az előállított útvonalon mozgatja végig a robotot. Minden

esetben (ha sikerült eljutni a célba, ha nem), értesíti a vezérlőt a feladat sikerességéről vagy

sikertelenségéről. Azokat a magasabb szintű mozgásformákat használja, amit az állapottér-

reprezentáció operátorok halmazából következtet az 6.4.5 alfejezetben leírtak alapján. (menj

északra, menj keletre, menj délre, menj nyugatra)

A kereső felépítése:

1: function Menj_A_Célba(<A,Kezdő,Cél,O>, pathList)

2: for all cs ∈ pathList do

3: if cs[X] = Kezdő[X] and cs[Y] = Kezdő[Y+1] then

4: menj_északra()

5: start ← cs

6: end if

7: if cs[X] = Kezdő[X+1] and cs[Y] = Kezdő[Y] then

55

8: menj_keletre()

9: start ← cs

10: end if

11: if cs[X] = Kezdő[X] and cs[Y] = Kezdő[Y-1] then

12: menj_délre()

13: start ← cs

14: end if

15: if cs[X] = Kezdő[X-1] and cs[Y] = Kezdő[Y] then

16: menj_nyugatra()

17: start ← cs

18: end if

19: end for

20: if act = Cél then

21: return true

22: else

23: return false

24: end if

25: end procedure

6.5.4 A kereső vezérlője

A vezérlő biztosítja a kereső helyes működését, információt szolgáltat a két alrendszer

számára, illetve a külvilág felé interfészekkel rendelkezik. A vezérlő fogadja a térképet,

adminisztrálja azt, létrehozza a csomópontokat, meghívja a keresőt, döntést hoz abban az

esetben, ha sikerült elmenni a célba, vagy ha nem. Feladata biztosítani és összehangolni a két

alrendszer munkáját. Amikor a vezérlő parancsot kap, hogy el kell juttatnia a robotot egy

megadott pontba, az alábbiakat teszi:

1: procedure vezérlő(<A,Kezdő,Cél,O>)

2: sikereses = false

3: while IGAZ do

4: pathList ← Legrövidebb_út_kereső(<A,Kezdő,Cél,O>)

56

5: sikeres ← Menj_A_Célba(<A,Kezdő,Cél,O>, pathList)

6: if sikeres = true then

7: break

8: end if

9: end while

10: end procedure

57

7 Fejlesztői weboldal, kapcsolat

A szakdolgozat témája egy nagyobb projekt mérföldköve. A fejlesztés elindítása,

átláthatósága, karbantarthatósága végett készült a projekthez egy fejlesztői oldal. Az oldal

tartalmaz egy rövid leírást a fejlesztés történetéről és szükségességéről, magáról a szoftverről,

illetve arról a fejlesztési filozófiáról, amit támogatunk, és folyamatosan szem előtt tartunk.

Letölthető a térképkészítő futtatató állománya (.exe), forráskódja, a mikrokontrollerre írt

kódok. Részletes dokumentáció készült mind a PC, mind a ChipKIT oldali kódokról. A

dokumentáció letölthető tömörített állományként, illetve lapozható html nézetben. Az oldalon

lehetőség van kapcsolatfelvételre is a fejlesztőkkel. Elérhetősége:

http://shrek.unideb.hu/~erdosa

Az oldal kinézete, mintatervezése a w3layouts „Bloom”6 sablon alapján készült, JavaScript és

PHP technikák alkalmazásával.

A dokumentáció Doxygen dokumentáció készítő program segítségével íródott. A

Doxygen alapértelmezettől eltérő beállításai:

Projekt neve: Robot navigation

Projekt szinopszis: Find the sortest route.

Projekt verzió: 1.0

Projekt logó: a Debreceni Egyetem Informatikai Kar logója

Dokumentáció elkészítése: vonatkozzon a dokumentum összes entitására.

Optimalizált programnyelv: C++

Kereszthivatkozások a dokumentációban: igen

Kimenet: HTML formátum navigációs panellel

Almappák készítése: igen

Kódolás: UTF-8

Megjelenítés: privát, csomagszintű, statikus adattagokat, lokális metódusokat is.

Bemenet: rekurzívan, az almappákat is.

A weboldal tartalmazzon keresőt: igen

6 https://w3layouts.com/bloom-portfolio-single-page-responsive-website-template/

58

8 Aktuális problémák és megoldások

A felépített kisvilág, amelyben a robot mozog a négyzethálón alapul. Négyzeteken

közlekedhet egyikről lépkedve a másikra. Léteznek viszont olyan elrendezések, amikor a robot

nem épp a legoptimálisabban fog közlekedni. A 20. ábra szemlélteti, ha a robotnak átlósan kell

közlekednie, az a piros nyilakkal jelült útvonalon fogja megtenni, az optimális útvonalat a zöld

nyíl szemlélteti. A felépített kisvilágban, amely a robot mozgását, állapotterét írja le a piros

nyíllal jelült lesz az optimális útvonal.

20. ábra A robot legrövidebb útvonala

Problémát jelentett a modularitás, és az újrafelhasználhatóság kérdése. A robot

vezérlőjét úgy kellett megírni, hogy az a hardverelemektől csak nagyon kis mértékben függjön,

egy-egy hardverem cseréje ne jelentse azt, hogy az egész vezérlőt át kell írni. Ennek megoldása

érdekében születtek meg a singleton osztályok, és a kontrollerek. Ugyanezen problémákat

kellett megoldani a PC oldalon is: a megjelenítés, és a funkcionalitás két, külön egységet kell,

hogy alkossanak. Itt több lehetőség állt rendelkezésre, felhasználtam, hogy az objektumok

eseménykezelők segítségével kommunikáljanak egymás között.

Felvetődött, hogy mit tegyen a szoftver, ha a robot „eltéved”. Ez előfordulhat, ha nem

pontosan azt a távot teszi meg, amit a vezérlő előír (ennek lehetnek mechanikai okai is). Ennek

megoldása, hogy az egész térképet újra el kell neki küldeni.

59

9 Összefoglalás

A szakdolgozat keretein belül megvalósítottam egy robot vezérlést, és egy

térképszerkesztő szoftvert. A szoftver segítségével lehetővé tettem a robot számára térképek,

útvonalak menedzselését. Lehetővé tettem térképszerkesztés, mentés, betöltés vizuális

megjelenítését, ezáltal egy könnyen kezelhető interfészt biztosítottam a felhasználók számára.

A robot központi egységét olyan algoritmusokkal láttam el, melyek képesek meghatározni a

kezdő és cél pozíció közötti legrövidebb utat, függetlenül a térkép méretétől vagy formájától.

A fejlesztésem egy nagyobb rendszer része, mely a karon készült asszisztív robothoz,

intelligens környezet kialakításához kapcsolódik. A robot e környezet részét képezi.

9.1 Fejlesztési lehetőségek

A továbbiakban tervezem a robot mozgását még négy iránnyal bővíteni. Eddig észak,

kelet, dél és nyugati irányokba mehetett, és 90 fokos szögben tudott elfordulni. Precízebb, a

több lehetőséget kínál, ha a robot képes mozogni észak-kelet, dél-kelet, dél-nyugat és

északnyugat irányokba is, illetve képes 45 fokos szögben elfordulni. Ezzel egy-egy csomópont

leírása több adatot igényel, illetve a csomópontok között több kapcsolatot kell létesíteni (szám

szerint kétszer többet). Az adatok helyigénye a mikrokontroller memóriájában jelenne meg. Az

ötletet továbbgondolva a térképet, mely a kereső adatbázisául szolgál, egy külső eszközre

kellene telepíteni, mely akár egy számítógép memóriája, vagy felhő alapú tároló.

Egy felhő alapú szolgáltatás integrálhatná a jelenleg is fejlesztés alatt álló

betegmonitorozó rendszer, az intelligens környezet koncepció, és a robot térképeit egy egységes

rendszerré. Az összegyűjtött adatok így egységesen tárolva, egy nagy rendszer részét képezné.

Az integrálás megkönnyítené az adatok kezelését, összefüggések keresését, kapcsolatok

kialakítását az egyes rendszerek között. Erre egy példa lehet, amikor az életjel monitorozó

rendszer folyamatosan adatokat küld egy központi tárolónak. Amennyiben az adatok

rendellenességet mutatnak, a tároló utasítja a robotot, hogy menjen át a beteg szobájába, és

kezdeményezzen hívást családtagjaival.

A robot minél több „érzékszervvel” rendelkezik, annál pontosabb képet tud alkotni

környezetéről. A továbbiakban a mozgás pontosítása, a környezetében levő tárgyak pontos

észlelése, és sértetlensége érdekében a robotra szerelhetőek kifinomultabb mérést lehetővé tevő

60

eszközök. Ilyen a lézeres távolságmérő, különböző magasságokban elhelyezett ultrahangos

szenzorok. Ezek telepítését úgy kell elvégezni, hogy a lehető legnagyobb szöget tudják belátni.

Így a vezérlést illetően többszörösen visszacsatolt rendszer is kialakítható, mely

akkurátusabb vezérlést tesz lehetővé.

61

10 Irodalomjegyzék

[1] S. Eszenyi, „Infokommunikációs eszközök készítése, időskorúak életvitelének segítése,

asszisztív robot fejlesztése (Szakdolgozat),” 2014. [Online]. Available:

https://dea.lib.unideb.hu/dea/bitstream/handle/2437/191506/EszenyiSzabololcs_Szakdo

lgozat_titkositott.pdf?sequence=1&isAllowed=y.

[2] S. Nagy, „Infokommunikációs eszközök készítése, időskoruak életvitelének segítésére

(Szakdolgozat),” 2014. [Online]. Available:

https://dea.lib.unideb.hu/dea/bitstream/handle/2437/201870/NagySandor_Szakdolgozat

_titkositott.pdf?sequence=1&isAllowed=y.

[3] „iRobot® Create Open Interface,” 2006. [Online]. Available:

http://www.irobot.com/filelibrary/pdfs/hrd/create/Create%20Open%20Interface_v2.pdf

.

[4] „WiFly Command Reference, Advanced Features and Applications User’s Guide,”

2013. [Online]. Available: http://ww1.microchip.com/downloads/en/DeviceDoc/rn-

wiflycr-ug-v1.2r.pdf.

[5] „RN-171-XV 802.11 b/g Wireless LAN Module,” 29 10 2012. [Online]. Available:

http://ww1.microchip.com/downloads/en/DeviceDoc/rn-171-xv-ds-v1.04r.pdf.

[6] „chipKIT™ Max32™ Board Reference Manual,” 27 1 2015. [Online]. Available:

http://www.digilentinc.com/Data/Products/CHIPKIT-

MAX32/chipKIT_Max32_RM.pdf.

[7] I. Reiter, C# programozás lépésről lépésre, Budapest: Jedlik Oktatási Stúdió Kft., 2012.

[8] L. Csige, Szerző, Mesterséges Intelligencia I jegyzet. [Performance]. 2014.

[10] B. W. Kernighan és . R. M. Dennis, A C programozási nyelv, Budapest: Műszaki

Könyvkiadó, 1994.

62

[11] D. B. Horvath és J. Liberty, Tanuljuk meg a C++ programozási nyelvet - 24 óra alatt,

Budapest: Kiskapu Kiadó, 2008.

[12] B. Stroustrup, A C++ Programozási nyelv, Budapest: Kiskapu kft., 2001.

[13] A. S. Tanenbaum, Számítógéphálózatok, Budapest: Panem Könyvkiadó Kft., 2004.

[14] P. Norvig és S. J. Russel, Mesterséges intelligencia - Modern megközelítésben,

Budapest: Panem Kft., 2005.

[15] „2.4 GHz IEEE Std. 802.11 b/g Wireless LAN Module,” 2014. [Online]. Available:

http://ww1.microchip.com/downloads/en/DeviceDoc/70005171A.pdf.

[16] „chipKIT Max32 Reference Design,” 15 3 2011. [Online]. Available:

http://www.digilentinc.com/Data/Products/CHIPKIT-

MAX32/chipKIT%20Max32_bysa_sch.pdf.

[17] „chipKIT Max32 Jumper Settings,” 23 5 2011. [Online]. Available:

http://www.digilentinc.com/Data/Products/CHIPKIT-MAX32/chipKIT-Max32-

Jumpers.pdf.

[18] „AVR Assembler User Guide,” 01 1998. [Online]. Available:

http://www.atmel.com/Images/doc1022.pdf.

[19] M. Verle, PIC Microcontrollers - Programming in Basic, mikroElektronika, 2010.

[20] D. Ibrahim, Advanced PIC Microcontroller Projects in C, London: Elsevier Ltd, 2008.

[21] D. Ibrahim, Microcontroller Based Applied Digital Control, West Sussex: John Wiley

& Sons Ltd, 2006.

[22] R. Cseh, Arduino Programozási Kézikönyv, Budapest: TvIR, 2011.

[23] B. V. Evans, Arduino Programming Notebook, 2008.

[24] J. Arndt, Matters Computational, Berlin: Springer-Verlag Berlin, 2011.

63

[25] B. Almási, 12 4 2012. [Online]. Available:

http://www.inf.unideb.hu/kmitt/konvkmitt/szamitogep-

halozatok_oktatasi_segedlet/book.xml.html.

[26] U. Frese és L. Schröder, Closing a Million-Landmarks Loop, Universitat Bremen.

[27] R. Michael, K. Rainer, G. Giorgio és B. Wolfram, Highly Accurate Maximum

Likelihood Laser Mapping.

[28] H. Shoudong, W. Zhan, D. Gamini és F. Udo , A sparse local submap joining

algorithm with improved consistency.

[29] E. Szabolcs, Infokommunikációs eszközök készítése, időskorúak életvitelének,

Magyarország, 2014.

[30] N. Stéfán, Kártyajáték fejlesztése Java technológiával, Magyarország, 2015.

64

11 Ábrajegyzék

1. ábra A Roomba Irobot Create Open Interface felépítése ....................................................... 9

2. ábra DB-25 csatlakozó............................................................................................................ 9

3. ábra RN-XV 171 WiFi modul lábkiosztás ........................................................................... 13

4. ábra RN-XV 171 WiFi modul .............................................................................................. 13

5. ábra ChipKIT Max32. Forrás: [6] ........................................................................................ 14

6. ábra A fő menüsor lehetőségei ............................................................................................. 17

7. ábra Az új térkép méretének beállítása ................................................................................. 18

8. ábra Jobb oldali menüsor ...................................................................................................... 21

9. ábra A térképszerkesztő futtatási felülete ............................................................................. 23

10. ábra Csomópont létrehozásának koncepció diagramja ....................................................... 25

11. ábra Csomópont állapot frissítése ....................................................................................... 27

12. ábra A futtatói nézet eseményeinek koncepciós diagramja ................................................ 28

13. ábra Térkép mentés és betöltés ........................................................................................... 30

14. ábra Példa kommunikációs ciklusra ................................................................................... 32

15. ábra Összetett kommunikációs ciklus................................................................................. 32

16. ábra Üzenetek szétválogatása ............................................................................................. 36

17. ábra A WiFi modul konfiguráló programkód ..................................................................... 41

18. ábra Egy helytelen útkeresés szemléltetése ........................................................................ 51

19. ábra A kereső működése ..................................................................................................... 52

20. ábra A robot legrövidebb útvonala ..................................................................................... 58

21. ábra A szerkesztési felület elő nézete ................................................................................. 66

22. ábra A térképszerkesztő futtató felületének előképe .......................................................... 67

23. ábra A térképszerkesztő UML diagramja ........................................................................... 68

24. ábra A mikrokontroller vezérlőjének UML diagramja ....................................................... 69

65

12 Függelék

A) Felhasznált szoftverek listája

1) Windows 8.1 Pro operációs rendszer

2) Visual Studio Professional 2013

3) Visual Micro Arduino Plugin for Visual Sturdio

4) Arduino 1.6.2

5) MPIDE with Arduino 0023 Compatibility

6) Atmel Studio 6.2

7) Express SCH 7.0.1

8) Doxygen 1.8.10

9) WinSCP 5.7.5

B) Felhasznált hardverek listája

1. Roomba Irobot Create Open Interface

2. Wifly RN-XV 171 WiFi breakout board

3. ChipKIT MAX32

4. ASUS X550C

66

C) A térképszerkesztő szerkesztési felületének képernyőképe

21. ábra A szerkesztési felület elő nézete

67

D) A térképszerkesztő futtató felületének képernyőképe

22. ábra A térképszerkesztő futtató felületének előképe

68

E) A térképszerkesztő alkalmazás UML diagramja

23. ábra A térképszerkesztő UML diagramja

69

F) A mikrokontroller vezérlőjének UML diagramja

24. ábra A mikrokontroller vezérlőjének UML diagramja

70

13 Köszönetnyilvánítás

Szeretnék köszönetet mondani témavezetőmnek, Oniga Istvánnak, aki szakmai

hozzáértésével, tanácsokkal, eszközökkel, és bizalmával támogatott az alkalmazás és a robot

programozás elkészítése folyamán.