POSEIDON NAVIGATION PROJECT Térkép alkalmazás Pocket PC platformra, GPS támogatással SZAKDOLGOZAT Szerzők Jelen dolgozat szerzője Kozulensek Neumann János Informatikai Főiskolai Kar Informatikai Automatizált Rendszerek Szakirány Bedők Dávid és Szirbik Ferenc Bedők Dávid Vámossy Zoltán (docens) és Molnár András (adjunktus) Dátum 2006. február 04.
1 Tartalomjegyzék 1 TARTALOMJEGYZÉK...2 2 ELŐSZÓ...5 3 CÉL MEGHATÁROZÁSA...6 4 IRODALOMKUTATÁS...8 4.1 AZ ÚTKERESÉSRŐL ÁLTALÁBAN...8 4.2 ÚTKERESÉS A JÁTÉKOK VILÁGÁBAN [2]...8 4.2.1 Szimulációs program: From Game to Map...8 4.2.2 Csapdák...9 4.2.3 Algoritmusok alapja...9 4.2.4 Dijkstra algoritmusa és a Best-First-Search...10 4.2.5 Az A* algoritmus...12 4.3 A HULLÁM-TOVÁBBTERJESZTÉSES ALGORITMUS [3]...13 4.3.1 Legrövidebb út...13 4.3.2 Hullám-továbbterjesztéses algoritmus finomítása...15 4.3.3 Legbiztonságosabb út, Voronoi diagramm...17 4.3.4 Megjegyzések...20 4.3.5 Implementálás...20 4.4 GRÁFOK...21 4.4.1 Gráfok ábrázolása...21 4.4.2 Súlyozott és irányított gráf tárolása...22 4.4.3 Minimális költségtérítésű feszítőfa...23 4.4.3.1 Algoritmusa... 23 4.4.4 Legrövidebb út [5]...24 4.4.4.1 Az algoritmus lényege... 24 4.4.4.2 Az algoritmus részletesebben... 26 4.4.4.3 Az algoritmus pszeudokódja...26 4.4.4.4 Szimulációs program: Graphs and spanning trees... 27 4.4.4.5 Megjegyzések... 27 4.5 GLOBÁLIS HELYMEGHATÁROZÓ RENDSZER [6]...28 4.5.1 Egy kis történelem...28 4.5.2 Mai helyzet...28 4.5.3 Pozíció meghatározás...28 4.5.4 A kommunikáció...29 4.5.5 Felmerülő hibák...29 4.5.6 Zavarás...30 4.5.7 A GPS felhasználása térképprogramok esetén...30 4.6 TESZTELT GPS KÉSZÜLÉKEK...31 4.6.1 µ-blox MS1E GPS vevőmodul...31 4.6.2 Garmin etrex Vista készülék...32 4.6.3 NMEA 0183 kommunikációs szabvány...32 4.7 DESTINATOR 3...33 5 RENDSZERTERV...34 5.1 A KEZDET...34 5.2 A FEJLESZTŐI KÖRNYEZET...34 5.3 POCKET PC TESZTKÉSZÜLÉK...35 5.4 AZ ELSŐ FUTÓ PROGRAM...35 5.5 A.NET RÖVID BEMUTATÁSA...36 5.6 ÚJ PROGRAMNYELV ÉS FEJLESZTŐI KÖRNYEZET...37 2/107
5.7 AZ ELKÉSZÜLT GPS KÉSZÜLÉK...37 5.7.1 A Pocket PC és a GPS összekötése...37 5.7.2 Kommunikáció tesztelés...38 5.8 0. RENDSZERTERV...38 5.8.1 Nulladik rendszerterv modulljai...38 5.8.2 Az egyes modulok kapcsolata...38 5.8.3 Modulok leírása...39 5.8.3.1 Adatbeviteli modul... 39 5.8.3.2 Kapott adat értelmezése... 39 5.8.3.3 Felhasználói felület modul... 39 5.8.3.4 Térképkezelő modul... 39 5.8.3.5 Adatbázis... 39 5.8.3.6 Software frissítések kezelése... 39 5.9 1. RENDSZERTERV...40 5.10 A GRÁF MODELL...41 6 GRAPHS AND SPANNING TREES...44 6.1 A PROGRAMRÓL ÁLTALÁBAN...44 6.2 FELHASZNÁLÓI KÉZIKÖNYV...45 6.2.1 Új gráf létrehozása...45 6.2.2 Gráf megnyitása...47 6.2.3 Globális beállítási lehetőségek...47 6.2.4 Lokális beállítások...48 6.2.5 Új gráf pont felvétele...48 6.2.6 Új él felvétele a gráfba...49 6.2.7 Gráf pontok és élek módosítása illetve törlése...50 6.2.8 Gráf tulajdonságainak utólagos beállítási lehetősége...50 6.2.9 Az aktuális súly illetve gráf pont adat beállítása...50 6.2.10 Gráf mentése...51 6.2.11 Kapcsolatmátrix generálása...51 6.2.12 Legrövidebb út meghatározása Dijkstra algoritmusa alapján...52 6.2.13 Szerkesztés gyorsítása...53 6.2.14 Tömegesen felvett élek és gráf pontok módosítása és törlése...55 6.2.15 Útkeresés egyszerűbb formája...55 6.3 FEJLESZTŐI DOKUMENTÁCIÓ...56 6.3.1 A TObject3D osztály...56 6.3.2 A TGraph osztály...57 6.3.2.1 Algoritmusok... 58 6.3.2.2 A TypeUnit további részei... 60 6.4 TESZTELÉS...60 6.5 BEÁGYAZÁS A POSEIDON NAVIGATION PROJEKTBE...60 7 FROM GAME TO MAP...61 7.1 FELHASZNÁLÓI KÉZIKÖNYV...61 7.1.1 Új terület létrehozása...61 7.1.2 Terület szerkesztése...62 7.1.3 Beállítási lehetőségek...64 7.1.4 Terjes terület törlése...64 7.1.5 Hullámrajzolás...64 7.1.6 Útkeresés...65 7.1.7 Prioritási sor beállítása...66 7.2 FEJLESZTÉSI KÉZIKÖNYV...67 7.2.1 A CTerritory osztály...67 7.2.2 Az osztály attribútumai illetőleg tulajdonágai...68 3/107
7.2.3 Osztálymetódusok...69 7.2.4 Hullám-továbbterjesztés algoritmusa...70 8 GRAPHS AND SPANNING TREES MINI C# VÁLTOZAT...73 8.1 GRAPHS.NET...73 8.2 GRAPHPDA...74 8.3 C# OSZTÁLYOK...75 8.3.1 CWorkFileName osztály...75 8.3.2 CFileGraph osztály...76 8.3.3 CGraph osztály...76 9 A POCKET PC ÉS A GPS ÖSSZEKAPCSOLÁSA...77 10 EREDMÉNYEK...78 11 MELLÉKLETEK...80 11.1 GRÁFOK [4]...80 11.1.1 Egyszerű gráf...80 11.1.2 Izomorfia...80 11.2 GRAPHS AND SPANNING TREES...80 11.3 TOBJECT3D OSZTÁLY...88 11.3.1 A konstansok...88 11.3.2 Típusok...88 11.3.3 Változók...89 11.3.4 Az osztály...90 11.4 TGRAPH OSZTÁLY...91 11.4.1 A konstansok...91 11.4.2 A változók...91 11.4.3 A típusok...92 11.4.4 Az osztály...94 11.5 TYPEUNIT...94 11.5.1 További típusok...94 11.5.2 További eljárások illetve függvények...95 11.6 FROM GAME TO MAP...95 11.7 GRAPHSDOTNET NAMESPACE...100 11.7.1 Struktúrák...100 11.7.2 CGraph osztály...104 12 IRODALOMJEGYZÉK...107 4/107
2 Előszó Jelen dolgozat a i Neumann János Informatikai Főiskolai Karán készült 2004 elejétől 2006 májusáig. Az időszak elején kezdtük el mindketten (Bedők Dávid és Szirbik Ferenc) az Informatikai Automatizált Rendszerek Szakirányt, Vámossy Zoltán Tanár úr vezetésével. A szakirányt megelőzően alapvető ismereteket sajátítottunk el gimnázium illetőleg szakközépiskola alatt, valamint a főiskola első három félévében Turbo Pascal 7 valamint Borland Delphi 7 környezetben, megismerkedve az objektum orientált programozás csírájával. Tanulmányaink ezután kezdtek el rohamos ütemben gyorsulni. Továbbfejlesztettük az OOP-ben eddig megszerzett tapasztalatainkat, megismerkedtünk alapvető képszerkesztési algoritmusokkal, valamint a három dimenziós megjelenítés legegyszerűbb formáival. Programozási ismereteinket a Delphi 7 mellett Microsoft C#.net környezetben is kamatoztattuk. A Poseidon Navigation Project elnevezésű dolgozat készítése során számos hasznos, és életünk során bizonyosan hasznunkra váló ismeretet, tapasztalatot gyűjtöttünk össze. 2004. őszén a Budapesti Műszaki Főiskolán megrendezésre kerülő XXIX. Tudományos Diákköri Konferencián II. helyezést értünk el az Informatikai Rendszerek Szekcióban, majd ezen tanév tavaszán, 2005-ben az Országos Tudományos Konferencián is azonos eredményt szereztünk (Műszaki Tudományi Szekció, Alkalmazott Számítástechnika tagozat). 5/107
3 Cél meghatározása A lehető legrövidebben megfogalmazva egy PDA-ra (tenyérgépre) fogunk elkészíteni egy navigációs programot, mely GPS koordináták segítségével a felhasználó igényeinek és a közlekedési szabályoknak megfelelően járható utakat keres. A térképkészítésnek fantasztikus történelme van, nem véletlenül. Az embert mindig is érdekelte, hogy hol helyezkedik el a világban, és bár mindenre választ nem képes adni, egy fokkal közelebb kerül az igazsághoz, hogyha lejegyzi az eddig látott világokat, és azok elérését, hogy legközelebb is el tudjon jutni oda. Később aztán ezt mások is felhasználhatják arra a célra, hogy számukra idegen helyekre eljussanak, és ott eligazodjanak. Ma már ott tartunk, hogy olyan helyeket is képesek vagyunk feltérképezni, ahova eddig még ember nem jutott el, és sok olyat is, ahova képtelenség is lenne. A GPS, azaz globális helymeghatározó rendszer segítségével pontos adatot kapunk arra nézve, hogy hol helyezkedünk el bolygónk felszínén. Ezt felhasználva software-es támogatást adhatunk a felhasználó kezébe a tájékozódását segítve ezzel. Nem szükséges elemeznie a bonyolult térképeket. Számára csupán az a fontos, hogy eljusson a kívánt céljába. A program, melyet elkészítettünk, és jelen dolgozatban bemutatunk, pont ebben segít neki. Hogy mindezen támogatás mindig elérhető legyen számára, a programot egy Pocket PC-re készítjük el, mely méreténél fogva arra lett tervezve, hogy bárhol, bármikor használhassuk. A kézi-számítógépeknek több nagy csoportjuk is van, az általunk választott gépek valójában egy mini x86-os utasításkészletre épülő lebutított asztali PC-k, melyeken Microsoft Windows Mobile 2003 többfeladatos operációs rendszer futtatnak. Egy térképprogram esetében mit is jelent az a probléma, hogy útkeresés? Ismerünk egy adott pontot (kiindulási pont), ahol éppen mi állunk (GPS szolgáltatja, avagy manuálisan választható). Megjegyezzük, hogy a GPS pontossága vitatható, sőt sokszor nem is határozható meg, mivel a vevő nem lát elég műholdat, avagy azok túl közel vannak egymáshoz képest, így a látott holdak közül kidob a készülék párat. Ilyen esetekben software-es megoldást alkalmazunk majd. Ez azért lehetséges, mert több mint valószínű, hogy az illető annak a pontnak a közelében van, amit az elmúlt pár percben megjelölt a GPS, így a software felajánl egy közeli pontot valahol az előző koordináta, és egy kijelölt cél között, természetesen a felhasználó sebességét is figyelembe véve. Az útkeresés eme előbb említett pont és a cél pont között zajlik majd. Utóbbit vagy kijelöli az illető a térképen (rámutat), avagy beírja szövegesen, hogy mit keres. Miután a program a kérdésekkel egyértelműen beazonosított egy pontot (ami szintén szerepel a térképen) akkor az útkeresés folyamata elindulhat. Ha a térképen lévő pontokat gráf pontoknak tekintjük, akkor az útkeresés a gráf pontjai közötti utak megtalálását jelenti, amennyiben azok léteznek (egy adott térképen szinte mindig létezik út két pont között, lehetne mondani, de ez nem minden esetben van így: pl. ha valaki gyalogosan közlekedik, akkor a folyó, avagy az autópálya négy sávjának közepére nincs út. Ettől függetlenül a program egy figyelmeztetés mellett amennyiben az adott lehetőségekkel út nem létezik, keres alternatív lehetőségeket, tervünk szerint). Van egy olyan lehetőség is, miszerint a térképet grafikusan képzeljük el, és mint képet dolgozza fel a program. Ezt nevezzük pixeles megoldásnak. Ez valószínűleg sokkal pontosabb utat tud meghatározni, ámde felmerül ezzel olyan probléma, hogy GPS koordinátákat képtelenség minden képponthoz tárolni. Mindkét módszernek vannak előnyei, és hátrányai is, ezért talán a legjobb megoldás, ha az előnyüket kivéve egy hibrid módszer megvalósítását tűzzük ki célul. A GPS adatokat egy több szintű gráf-háló tárolja majd (több szint: minden közlekedési módszernek külön gráfháló). 6/107
Lehetőség lesz gráfok unióját is venni annak érdekében, hogy olyan esetekben is találjon a program utat, mikor egy szinten belül erre nincs mód. Mindezekre rákerül egy információgazdag grafikus felület, mely színek segítségével tárol adatokat. Ennek van egy váza, ami tartalmazza azon pontokat, amelyek minden eszköz számára megközelíthetetlenek. Ilyen például egy folyó (híd nélküli része), vagy egy ház alapja. Erre kerülnek rá a közlekedési módszerek különféle sémái. Pl. ha gyalog vagyunk, akkor azon utak jelennek meg, amik gyalogosan elérhetők, a többi út ugyanolyan akadály marad, mint mondjuk a ház alapja. Itt is lehetőség lesz arra, hogy minden felület sémát felhasználjunk, és az uniójuk szerint keressünk utat (vagy bármelyik N uniója szerint). Maga az útkeresés egy végletekig egyszerűsített modell arra nézve, hogy mi általa megtaláljuk helyünket a világban. Tervezzük, hogy térképprogramunkat felruházzuk a lehetőségekhez mérten számos KRESZ és gyakorlati szabállyal, ezzel is javítva a térképprogram hétköznapokban való felhasználásának eredményességét. Így az elején már csak egy dolgot kell tisztázni, hol lesz a kapcsolat a gráf és a grafikus megoldás között? A felhasználó a grafikus felületet látja, amin külön pontok jelzik azon pixeleket, melyek gráf pontok is. Útkeresésnél a felhasználó dönthet, hogy melyik út jelenjen meg, vagy rábízza a készülékre a dolgot. Valahogy így fogalmaztuk meg az ötleteinket, illetve célkitűzéseinket 2004-ben. Ezek után kezdődött a munka tényleges része, melyben természetesen a fenti célok elérésre törekedtünk, azonban néhol be kellett látnunk, hogy nem minden realizálható a mi szintünkön. A Poseidon Navigation Project fejlesztése több fázisban történt. Fél év irodalomkutatást követően elkezdtük kidolgozni a megvalósítás lehetőségeit, illetőleg elkezdtük begyűjteni a szükséges hardware eszközöket. Hardware szempontjából két különféle Pocket PC kézi-számítógéppel dolgoztunk. Mindegyiken Microsoft Windows Mobile 2003 operációs rendszer futott. Ezeken kívül természetesen szükségünk volt a GPS adatokat szolgáltató GPS készülékre, melyből szerencsére többet is tudtunk tesztelni. A hardware eszközök kommunikációját soros port segítségével oldottuk meg, kezdeti sikertelenségek és átmeneti megoldások után. A software mag fejlesztése két irányban haladt. Az egyik irány az adatok tárolását és az útkeresést tűzte ki célul. Ehhez Borland Delphi 7 környezetben készítettünk PC-n futó alkalmazásokat. A másik irány a Pocket PC-n lévő tényleges program fejlesztése volt, melyre a.net framework lehetőségeit kihasználó Microsoft Visual Studio.net C# nyelvét választottuk. A megvalósult program bár nem teljesíti mindazt, amit a cél meghatározásakor kitűztünk, de egy általunk mért térképrészleten valós időben, GPS adatokat felhasználva legrövidebb utat képes meghatározni, és megjeleníteni Pocket PC-n! 7/107
4 Irodalomkutatás Egy nagyobb munka előtt minden esetben célravezető körülnézni, hogy mások milyen megoldást alkalmaztak hasonló helyzetben. Érdemes feldolgozni ezen eredményeket, és megjelölni azon részeket, melyeket majdnem mi is alkalmazni fogunk. Nem szabad azonban figyelmen kívül hagyni, hogy törekszünk munkánk során valami újat is hozzáadni a már létező megoldásokhoz, így néhány esetben fel kell hívni a figyelmet a rendszerek és a rendszerünk különbségeire, az ebből adódó előnyökre és hátrányokra. 4.1 Az útkeresésről általában Az útkeresés problémája az élet sok területén felmerül. Mi a játékok világán keresztül ismerjük meg kicsit alaposabban. Az útkeresés az egyik legkeresettebb mesterséges intelligencia típus a számítógépes játékokban. Sok mindentől függ, hogy egy játék jó lesz-e. Egy ilyen fontos tényező az alkalmazott útkereső algoritmus. Szerencsére ez a probléma ma már többnyire megoldott, de azért az ember nap mint nap találkozhat félresikerült alkotásokkal, melyekben nem gondolták végig, hogy ennek milyen nagy jelentősége van. 4.2 Útkeresés a játékok világában [2] Azt a problémát járjuk körül, hogy egy játékban hogyan lehet egy adott objektumot egy másik (cél) pontba vinni. A téma így megfogalmazva, hogy egy adott pontot hogy lehet eljuttatni egy másikba, teljes mértékben a térképprogram grafikus felületébe illik, hiszen ott is ugyanez a feladat. 4.2.1 Szimulációs program: From Game to Map Az útkeresés problémájának bemutatására két szimulációs program fog elkészülni. Ezek közül az egyik a számítógépes játékokhoz hasonlóan fog működni (ennek elnevezése From Game to Map). A tervek szerint legelső verziójában egy testre, és két dimenzióban akadályokkal övezett területen ad megoldást különféle algoritmusok alapján. A következő verzió a fent leírt dolgokat ellenségekkel övezett területen is végrehajtja. Ellenségnek nevezzük a mozgó akadályokat. Az ezt követő verzióban már három dimenzióban szimulálva hajtom végre ugyanezt, majd a végső programban újfent előjönnek az ellenségek. Amit ebből a térképprogramba fel tudunk majd használni, az a harmadik verzió, ám roppant hasznos lehet egy jól működő végleges is, más feladatok megoldására. A játék szempontjából tárgyalom én is a problémát, persze ettől könnyű elvonatkoztatni. Akadályokat el kell tudnia kerülni az algoritmusnak, szintúgy ellenségeket (például autókat: ha gyalog megyünk, nem mehetünk rá az útra). És ha lehet minimalizálni kell a költségeket. Ez egy összetett kérdés, mivel adott utaknak különféle költségei lehetnek, attól függően, hogy milyen nézőpontból vizsgáljuk. Nézzünk erre egy egyszerű példát: van egy távolság, ami autópályán haladva 50 km távolságban van, de létezik egy földút is, amin haladva 20km alatt el tudjuk érni célunkat. Autópályán haladva 100 km/h-val tudunk haladni, míg földúton esetleg csak 30-al (1. ábra). 8/107
Ábra 1 Súlyozás A sok fékezés és rossz utak miatt a földúton járművünk kétszer annyit fogyaszt, mint a kényelmes autópályán. Mindezek után, ha a legrövidebb utat akarjuk, akkor a földutat választjuk, ismerve kocsink tulajdonságait, de a hosszabb autópálya a benzin, a kocsi állapota szempontjából megfelelőbb költségekkel rendelkezhet. Fel kell készülni arra az esetre is, hogy az objektumok a későbbiekben nevezzük ezeket átvitt értelemben ellenségnek (de ide értve saját társainkat is, ha mondjuk egy stratégiai játékban gondolkozunk) mozognak, így minden ilyen ellenség pontot újra meg kell vizsgálni minden megtett lépés után, és a legrövidebb, avagy legkisebb költségekkel rendelkező utat is újra szükséges számolni. Fontos dolog az is, hogy nehogy beragadjunk, és pár adott pont között mozogjunk oda-vissza. Emlékezet segítségével erre előre fel kell készítenünk algoritmusunkat. Ez a memória változó méretű lehet, tapasztalatok útján fogjuk a megfelelő mélységet beállítani. 4.2.2 Csapdák Ábra 2 Csapda (Forrás: http://theory.stanford.edu/~amitp/gameprogramming/) A 2. ábrán szürkével jelölt területet nevezhetjük csapdának. Ugyanis a felső képen azt láthatjuk, hogy a kiinduló ponttól észleljük a célt, de mikor odaérünk, rájövünk, hogy akadály van előttünk. Amennyiben látjuk előre a teljes akadályt, avagy elérünk egy olyan pontot (detect obstacle here), ahonnan már látjuk, akkor a csapdát elkerülve sokkal rövidebb úton elérhetjük a célunkat. 4.2.3 Algoritmusok alapja Számos útkereső algoritmus a 3. ábrához hasonló gridet használ. A két dimenziós képen jelöltek a kapcsolódási pontok, azaz hogy honnan hova lehet eljutni. A gyorsabb algoritmus 9/107
érdekében ezt a módszert érdemes megfontolni, és felhasználni a térkép grafikus felületén, hogy ott sem minden pixelt veszünk figyelembe, hanem mesterségesen felosztott grid pontokat! (esetleg lehetőség van a teljesen pontos pixeles felosztásra is, ahol nemcsak derékszögű irányváltások léteznek, hanem 360 fokosak is, de nem kizárt ennek túlzott bonyolultsága és lassúsága). Ábra 3 Grid 4.2.4 Dijkstra algoritmusa és a Best-First-Search Dijkstra algoritmusa garantálja nekünk a legrövidebb út megtalálását a start és cél pont között. Ábra 4 Dijkstra (Forrás: http://theory.stanford.edu/~amitp/gameprogramming/) A 4. ábrán látható a kiinduló pont középen, és a kék célpont a színezett rész szélén. A kékes színek azok a területek, amelyeket az algoritmus megvizsgált. A Best First-Search (továbbiakban BFS) algoritmus ehhez nagyon hasonlóan működik, de tartalmaz számos heurisztikát, hogy pl. milyen messze van a cél. A BFS nem garantálja a legrövidebb utat, de sokkal rövidebb idő alatt talál megoldást. Az 5. ábrán a sárga pont jelöli, hogy magas heurisztikus értéke van, azaz messze van a céltól, és fekete jelöli az alacsonyat. 10/107
Ábra 5 Best first serach (Forrás: http://theory.stanford.edu/~amitp/gameprogramming/) Eddig egy egyszerű szituációt vizsgáltunk, de figyeljük meg, mi történik olyan esetben, amikor a térképen akadályok vannak: a 6. ábra felső részén Dijkstra algoritmusát, míg alsó részén a BFS-t láthatjuk. Ábra 6 Akadályok (Forrás: http://theory.stanford.edu/~amitp/gameprogramming/) A lényeg, hogy bár a BFS egyszerű esetekben gyorsnak tűnhet, egy kis probléma esetén a futási idő már sokkal kevésbé szembetűnőbb, ám a megoldás jósága nem is hasonlítható Dijkstra útkereső algoritmusához. Nézzünk most egy olyan algoritmust, mely a fenti két megoldás előnyeit egyesíti! 11/107
4.2.5 Az A* algoritmus Az A* ( A csillag ) algoritmus garantálja számunkra a legrövidebb utat, sőt, ezen kívül heurisztikákat is tartalmaz! Tehát lényegében teljesíti azt, amit fentebb írtam: előnyöket egyesít. Nemhiába ez az algoritmus a legnépszerűbb manapság. Az A* rendkívül rugalmas, és széles körben használható. Ábra 7 A* algoritmus (Forrás: http://theory.stanford.edu/~amitp/gameprogramming/) Egy kis magyarázat a 7. ábrához: a sárga (h) szín jelöli a céltól való távolságot, a cián (g) pedig a kezdőponttól méret. N csúcs van a képen, g(n) reprezentálja az út súlyát a kezdőponttól minden csúcsra. H(n) pedig a heurisztikus értékét képviseli minden pontnak. Így a legrövidebb út f(n) előáll g(n) és h(n) összegeként. 12/107
4.3 A Hullám-továbbterjesztéses algoritmus [3] Valójában két technikáról van szó, mely nagyon hasonló ötleten alapszik. Maga az előző fejezetben említett grid itt is létezik, és itt is hasonló elven tudjuk eldönteni az akadályok helyzetét. Ráadásul az előző fejezetben tárgyalt Dijkstra algoritmusa is ránézésre egyféle hullámterjedést mutatott be, és az is rögtön ki fog derülni, hogy az övé gyorsabban szolgáltat eredményt, mivel ott nem szükséges az egész területet előre ismerni, így szükségtelen bejárni is. Mielőtt előreszaladnánk, térjünk vissza a hullám-továbbterjesztéses algoritmusokhoz. Előre elkészítünk egy mátrixot a teljes térképre nézve. A mátrix elemei itt is bizonyos szempont szerinti heurisztikákat fognak tartalmazni. A hullám-továbbterjesztéses algoritmus egy legrövidebb utat fog megtalálni, avagy egy lehetséges ilyen utat, a legbiztonságosabb út algoritmus pedig azt az utat adja meg, ami a lehető legjobban elkerüli az akadályokat. Azon, hogy egy algoritmus heurisztikákat tartalmaz, azt értjük, hogy ráérzésre kipróbálunk egy lehetőséget a számunkra elérhető számos útból, majd ha megtéve ezt a lépést előrébb jutottunk célunk felé, akkor meghagyjuk, különben visszalépünk. 4.3.1 Legrövidebb út Nézzük, hogy is működnek ezek az algoritmusok. A 8. ábrán fogunk vizsgálódni. Ábra 8 Térkép A célunk az, hogy a lehető legmagasabb heurisztikus értékkel rendelkező ponttól (a kiinduló pont a legmagasabb értékű, hiszen ez van a legmesszebb a céltól a mi szempontunkból!) eljussunk a legalacsonyabb pontig, a 0-ig, azaz a célig (heurisztikus értéket azonosítom a céltól való távolsággal, ami nem teljesen egyértelmű megfeleltetés). A cél távolsága a céltól 0. Az akadályokat egyel alacsonyabb értékkel jelöljük, mint a start pontot, de ennek csak az algoritmus szempontjából van lényeges szerepe (minden cellaérték a példában egy byte-os adatot képes tárolni, ezért vannak így a határok). Ábra 9 Feltöltés 13/107
Először a hullám-továbbterjedéses algoritmust vizsgáljuk meg. Legelső lépésben fel kell töltenünk a mátrixunk még üres mezőit. A céltól fogunk elindulni, és minden szomszédos pontra feljegyezzük, hogy milyen messze van a céltól, azaz mekkora a heurisztikus értéke. Így fog kialakulni a hullámunk. Ezt mutatja a 9. ábra. Feltesszük természetesen, hogy átlósan is tudunk menni, azaz minden esetben, ha nincs akadály, nyolc irány közül választhatunk. A lehetséges út esetében nincs garantálva az, hogy ez a legrövidebb út lesz, mivel ez fog függni a konvencióktól. Az út úgy fog felállni, hogy a kiindulási ponttól elindulunk, és mindig a legalacsonyabb heurisztikus pont felé fogunk lépni. A hullám tulajdonsága miatt arra, hogy beakadjunk két pont között, nincs esély, hiszen biztos, hogy lesz legalább egy, egyel alacsonyabb pont minden mező szomszédságában. Miért is van szükség járulékos szabályokra? Előfordulhat, ráadásul elég sűrűn, hogy egy adott pontból több irányba is tudunk menni! Ahhoz, hogy egyértelmű utat tudjunk meghatározni, ilyenkor meg kell tanítani az algoritmust arra, hogy melyik utat válassza. Ezért egy prioritási sorrendet érdemes felállítani a nyolc lehetséges irány között. Erre egy példát mutat a 10. ábra. Ábra 10 Prioritási sorrend Minél nagyobb a prioritása adott iránynak, annál túlélőbb lesz, ha dönteni kell. A 10. ábra táblázatának a függvényében fog változni maga az út is, ezért nem biztosítható, hogy a legrövidebb utat fogjuk megtalálni. Ezen prioritási kiosztásnak a lehetőségei végesek, így esetlegesen megoldás az, hogy minden lehetőségre megnézzük az utakat, és a legrövidebbet ebből ki tudjuk választani, de ez meglehetősen lassú megoldás. Esetleg ha még gyorsabb megoldást akarunk, nem alkalmazunk prioritási sort, hanem véletlenszerűen fogunk döntéshelyzetben választani. Így is biztos, hogy találunk utat a kiindulási pont és a cél között, és nincs szükség konvenciók meghatározására. A 11. ábrán a fenti prioritási sor, és a térképünk által meghatározott utat látjuk. Ábra 11 Első megoldás Példaképpen nézzünk meg egy másik megoldást is egy másik prioritási mátrix alapján (12. és 13. ábra). 14/107
Ábra 12 Második megoldás Ábra 13 Második prioritási sor A példából is jól látszik, hogy bár egyértelműen más utat találtunk meg, ez is tíz közbülső lépést tartalmaz. Ebből következtethetünk arra, hogy a prioritási mátrixok közötti különbség szinte mérhetetlen, így nem érdemes az összes lehetséges utat megkeresni, és kiválasztani belőlük a legrövidebbet. Még abban sincs különbség a két eset között, hogy hányszor léptünk átlósan, mindkét esetben kilencszer történt ez meg. Úgy kezdtem a hullám-továbbterjesztéses algoritmus leírását, hogy nem biztosítja a legrövidebb utat. Ez hamis feltevés volt, csupán azért állítottam, mert nem voltam meggyőzve arról, hogy a prioritási mátrix egy viszonylag általános esetben nem befolyásolja az eredményt. Mivel a fent vázolt algoritmusnak létezik hatékonyabb változata is, gyorsan át is térek azok tárgyalására. 4.3.2 Hullám-továbbterjesztéses algoritmus finomítása A fenti eredményeket tudjuk pontosítani, amennyiben a hullám terjedését nem nyolc irányba követjük el, hiszen így az átlós iránynak megegyező súlya van a vízszintes, avagy függőleges iránnyal. Nézzünk egy olyan példát, mikor a hullám csak négy irányban terjed (14. ábra). Ábra 14 Négyirányú hullám 15/107
Bár az rögtön szembetűnik, hogy több súlyra volt szükségünk, mint az előző esetben, de ez nem befolyásolja az algoritmus futási idejét, és a megoldás (15. ábra) valamivel életszerűbb lesz (itt is a már sokszor használt nyolcirányú prioritási sort alkalmazva). Ábra 15 Jobb megoldás Ebben az egyszerű példában a kapott megoldás egyetlen egy pontban tér el az első esettől, mégpedig a cél előtt két átlós lépés helyett itt két vízszintes mozgás is elég volt, ami azt jelenti, hogy rövidebb utat kaptunk! Ezek után lehet még jobban pontosítani a számításokat. Most 4+4 irányban fog terjedni a hullámunk, ahol a vízszintes és függőleges terjedés egységnyi, míg az átlós irányok kiszámítva a négyzet átlójának méretét 2 súlyt kapnak. Ez egy nagyon olvashatatlan irracionális szám, a számítógép megfelelően nagy térkép esetén nem adna elfogadható időn belül megoldást a számítások időigénye miatt (viszonyítva előző algoritmusunkhoz). Emiatt egy közelítő értékkel célszerű számolni, mondjuk 7/5-el (7/5 = 1.4 az ~1.4142 helyett)(16. ábra), melyet aztán felszorozva öttel (17. ábra) minden egyes mezőre egész számot kapunk, melyekkel a processzorok gyorsabban képesek műveleteket végrehajtani. Ábra 16 Pontos hullám 16/107
Ábra 17 Felszorzás Ábra 18 Pontos megoldás A megoldás (18. ábra) megegyezik az előbb kapott eredménnyel, azonban sokkal általánosabb esetben ez még pontosabb megoldást szolgáltat. Ha összeadjuk az út során érintett súlyokat, és elosztjuk 5-el az eredményt, akkor kisebb számot kapunk, mint a négy irányú hullám esetében. Ez a kapott szám a súlyokra nézve pontosabb, bár az út fizikailag nem lesz rövidebb (ebben a példában). Az első pont amire rálépünk 12,40-es súlyú (62/5), míg az előző esetben ez 16 volt, ami nyilvánvalóan pontatlanabb távolság érték. 4.3.3 Legbiztonságosabb út, Voronoi diagramm Nézzünk most meg egy másik hullám-továbbterjesztéses algoritmust. Ennek a lényege a legbiztonságosabb út megkeresése. Itt a fentiek alapján már nem fogunk kételkedni abban, hogy ez e a lehető legbiztonságosabb út. A módszer itt is nagyon hasonló, csak most úgy fogunk eljutni a célhoz, hogy mindig a lehető legnagyobb értéket választjuk. Ez azért lesz így, mivel most a hullámokat az akadályoktól (254-es pontoktól) fogjuk kezdeni terjeszteni, így a heurisztikus értékek az akadályoktól mért távolságot fogják jelenteni. Minél nagyobb ez a szám, annál messzebb vagyunk tőlük. Nézzük a mátrix feltöltését (19. ábra), figyelembe véve most azt is, hogy a térkép széle is akadálynak számít, így nekünk azt is a lehető legjobban el kell kerülnünk. 17/107
Ábra 19 A legbiztonságosabb út hulláma A prioritási mátrixunk legyen itt is a már megismert (10. ábra). Mindezek után a lehető legbiztonságosabb utat a 20. ábra mutatja. Ábra 20 A legbiztonságosabb út A fenti példából egy nagyon fontos dolog hiányzik! Mégpedig az, hogy a legbiztonságosabb út keresése közben mi nem egy utat kapunk (a fenti eset kivétel), hanem egy gráfot! Egy adott utat úgy kapunk, ha ennek a gráfnak egy adott (pl. mélységi) bejárását felírjuk. A kapott eredmények közül, ha a legrövidebb utat keressük a gráfban, akkor a lehető legbiztonságosabb és legrövidebb utat fogjuk megkapni. Ezt próbálja szimulálni a 21. ábra. 18/107
Ábra 21 Másik térkép Ebben az esetben is prioritási sort használtam, az elején lévő kacifántos gráf értelmezését a 22. ábra mutatja be. Ábra 22 Ábra pontosítása De ha gráfokról van szó, akkor nincs is szükség itt most prioritási sorra! Jól látszik, hogy a térképen lefelé haladva is van egy hasonlóan biztonságos út, azt mi mégsem találtuk meg. A 23. ábra ezen pontosításokat mutatja. Ábra 23 Prioritási sor nélküli megoldás Az így kapott gráfból bármely bejárással a legbiztonságosabb utat írhatjuk fel. A színekkel azért jelöltem az egyes lépéseket, hogy egyértelmű legyen, hogy a 255-ös mezőből gráf él csak a kettes mezőhöz vezet, így onnan nem is mehetünk egyik egyesre sem a gráf bejárása során. A keletkezett gráfot a 24. ábra mutatja be. 19/107
Ábra 24 A keletkezett gráf Egyetlen egy járulékos szabályt vezettem be a gráf háló felépítése közben: amikor egy pontra nézem a szomszédokat, hogy adott pontból merre lehet továbbhaladni, akkor két változat létezik: - Van olyan pont, amin még nem jártam. - Nincs olyan pont, amin még nem jártam. Az első esetben a szabályom az volt, hogy ilyen esetben minden olyan ponthoz tartozik él, amin még nem jártam, és amin már jártam, ahhoz nem tartozik. A második esetben pedig minden olyanhoz vezet él, amin már jártam. A fenti járulékos szabályok bevezetésével a legrövidebb, legbiztonságosabb utak mindegyikét meg lehet határozni (megjegyzem, hogy a járulékos szabályokra biztosan más lehetőség is van, hogy hasonló eredményt kapjunk). 4.3.4 Megjegyzések A fent ismertetett legbiztonságosabb út megkeresésére biztosan létezik másféle algoritmus is, itt csak azért említettem meg, mert hasonlóan működik a legrövidebb utat szolgáltató algoritmushoz. 4.3.5 Implementálás Kicsit rátérek arra, hogy ezen algoritmusok miképpen építhetők be működő programokba. Felmerül a kérdés, hogy minden esetben szükségünk van-e arra, hogy a teljes térképet előre kiszámoljuk. Én úgy vélem nincs. Dijkstra algoritmusa alapján addig terjesztjük a hullámunkat, amíg a hullám egyik pontja el nem éri a kiindulási pontunkat (255). Ezek után az út keresése már egyértelmű. A hullám terjedését kell még modelleznünk. A pontos specifikáció a From Game to Map elnevezésű szimulátor program leírásában megtalálható. 20/107