szakdolgozatshrek.unideb.hu/~onigai/szakdolgozatok/2015-2016/erdos... · 2015-11-23 · az irobot...
TRANSCRIPT
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}[¶m1=val1… ¶mn = 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.