Analyse af ruteplanlægningsmetoder for mobile robotter i større domæner

Transkript

1 Analyse af ruteplanlægningsmetoder for mobile robotter i større domæner Forbedring af kørselsalgoritmer for hospitalsrobotter på Bispebjerg hospital af Søren Markersen, s Danmarks Tekniske Universitet Institut for informatik og matematisk modellering Vejleder Thomas Bolander 1. december 2010

2 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone , Fax IMM-M.Sc.: ISSN XXXX-XXXX

3 Abstract Analysis of pathplanning methods for mobile robots With offset in an ongoing projet at Bispebjerg Hospital where a number of robots are to be implemented as a relief for manuel logistic tasks, optimizing of the navigation and movepaterns of the robots are studied. The Bispebjerg Hospital project is a cooperation between DTU Informatik, DTU Management, Force Technology and Bispebjerg Hospital. In the basement underneath the hospital is a larger system of logistic, that are to be partly automated. The robots should work as autonome units, taking care of transport of equipment, beds, garbage and post. The perceptionsystems of the robot make and maintein a map of the area and this map is the basis for optimizing the driving operations. The map is a simple grid-map, existing both as a text based and as graphic based file. The robots can make measure up cells as small as 10 x 10 cm and therefore the map can be large and difficult to handle, with reference to the hardware. For the robot to respond to outer actions, as obstacle avoidance or changes in the enviroment, it is important for the robot quickly to adapt changes. This gives an upper timedemant on calculations og navigation. Besides this, the robot can be limited in its perception and manoeuvring, making it a challenge to find the balance for drivingtime vs. accuracy in pathplanning. This project is about how to practically handle pathplanning in very large maps, as ie. the gridmap of Bispebjerg Hospital, which gives both memory and driving time challenges. In the project an implementation with large maps using classic pathplanning algorithms will be used in benchmark tests and to clarify the challenges in algorithmic. Hereafter a study on alternative map-representations and algorithms ie. topological maps, hybrid maps and hierarchical representation. The result will give an outline of the pathplanning problem for robots in large and complex domains, refering to the robotproject at Bispebjerg Hospital. i

4

5 Resumé Analyse af ruteplanlægningsmetoder for mobile robotter i større domæner. Med udgangspunkt i et konkret projekt, der implementerer robotter som aflastning for manuelle logistiske opgaver på Bispebjerg Hospital, undersøges optimeringen af navigation og kørselsmønstre for et antal robotter. Projektet er et samarbejde mellem DTU Informatik, DTU Management, Force Technology og Bispebjerg Hospital. I kælderen under hospitalet er der et større logistisk system der delvist skal automatiseres. Her skal robotterne fungerer som autonome enheder der varetager opgaver med transport af udstyr, senge, skrald og post. Robotternes perceptionssystemer optegner og vedligeholder selv kortet over området og dette kort er grundlaget for optimeringen af kørslen. Kortet er et simpelt grid-map der eksisterer som både en tekstbaseret og en grafikbaseret fil. Robotterne opmåler ned til 10 x 10 cm felter ad gangen og derfor kan kortet blive stort og uhåndterligt, set i forhold til hardwareunderstøttelsen. For at robotten kan reagere på udefrakommende handliger som for eksempel når der står noget eller nogen i vejen for dens rute, eller når der er forandringer i dens miljø, er det vigtigt at den kan reagere hurtigt og tilpasse sig. Derfor er der et øvre tidsloft på navigationsberegningerne. Desuden er robotten begrænset i sin perception og den er begrænset i sin manøvreevne, som tilsammen gør at det er en udfordring at balancere kørselstiden kontra præcision i ruteplanlægningen. Dette projekt omhandler hvordan man praktisk kan håndtere ruteplanlægning på meget store kort som f.eks. gridet over Bispebjerg Hospital, hvilket giver både hukommelses og køretids -mæssige udfordringer. I projektet vil der blive arbejdet med konkrete implementeringer af store kort med klassiske ruteplanlægningsalgoritmer med henblik på at lave benchmark-tests og afklare de algoritmiske udfordringer. Herefter vil blive undersøgt muligheden for alternative kortrepræsentationer og algoritmer på disse, for eksempel topologiske kort, hybride kort og hierarkiske kortrepræsentationer. Resultatet vil give et overblik over ruteplanlægningsproblemet for robotter i store og komplekse domæner, i særdeleshed med henblik på robotprojektet på Bispebjerg Hospital. iii

6

7 Forord Denne rapport er udarbejdet på Danmarks tekniske universitet DTU, afdeling for informatik og matematisk modellering. Projektet er gennemført i perioden 1. september til 1. december 2010 og er berammet til 30 ECTS point. Vejleder lektor Thomas Bolander tb@imm.dtu.dk. Tak til Thomas for hans vejledning under projektforløbet. Søren Markersen markersen@gmail.com Kongens Lyngby, december 2010 v

8

9 Indhold Abstract Resumé Indhold i iii vii 1 Introduktion Begrænsninger for robotter Motivation Relateret arbejder Arbejdesområde Navigation Navigation Kortrepræsentation Metrisk kort Topologisk kort Hybrid kort Bredde Først Søgning A stjerne Robotters hardware Robotters navigation Hypotese Algoritme Datastruktur simulering Hvad skal simuleres Design og implementering af simulator Resultat af simulation Brug af simulator Fejl og mangler i simulator Cases Kriterier for evaluering Case Formål Konfiguration af Case vii

10 viii Indhold Resultat Case Formål Konfiguration af Case Resultat konklusion på case Data indlæsning Søgning Case Formål Konfiguration af Case Resultat Case Formål Konfiguration af Case Resultat Konklusion på case Data indlæsning Søgning Case Formål Konfiguration af case Resultat og konklusion Case Formål Konfiguration af case Resultat Case Formål Konfiguration af case Resultat Opsumering Konklusion Fremtidigt arbejde A Appendix 43 A.1 Case 1 og A.2 Case 3 og Litteratur 47

11 Kapitel 1 Introduktion Brug af robotter har i den seneste årrække haft et decideret indtog i den vestlige verden. Både som hjælpemiddel i hverdagen i hjemmet og som intelligente, mere eller mindre autonome værktøjer i produktionsmiljøer. Robotter kan ikke bare aflaste men også afløse menneskelig arbejdskraft, og overtage opgaver, både inden for transport og inden for andre monotone opgaver, som fx. udskæringer på slagterier, hvor opgaverne er nedslidende for mennesker og de manuelle processer tidskrævende og dermed løntunge. Et andet eksempel er bilindustrien der har gjort sig meget afhængig af robotter til produktion. Betegnelsen robotter dækker over mange ting, lige fra autonome selvkørende mobile systemer og enheder, som fx. robotstøvsugere til stuen til fæstnede robotarme til fx. bilindustrien, og blandingen som humanuide robotter med arme på. Mange af de nyeste tiltag er baseret på mobilitet og denne opgave udspringer af et projekt med at implementerer et system af transport-robotter på et hospital, til aflastning af portører med de monotone transportopgaver der indebærer fx. postomdeling, transport af senge, vasketøj etc. Robotterne skal kører i kælderregionen, der består af flere kilometer lange monotone gange, men der kan forekomme forhindringer og anden trafik hvor påkørsel skal undgås. Styringen af en robot kan være en udfordring at gøre præcis, da interaktionen med omverdenen ofte er fejlbehæftet og upræcis, pga. den begrænsning der er i sensorer og i fortolkningen af det data de leverer. Sensorerne giver en bred pallet af mulighedder der skal tilpasses de enkelte scenarier hvor robotten skal bruges, men ofte er radar, sonar og kamera de foretrukne valg til perception af omverden. Mobile robotter har også begrænsninger i manøvrering og i det miljø de skal bevæge sig i. For langt de fleste robotter gælder at de skal navigerer i et kendt miljø og indendørs, så der ikke er vejret, ufremkommeligt terræn og andre udefrakommende faktorer at tage hensyn til, men der kan stadig forekomme fejl i bevægelser for robotten. Disse ting med perception og skæve kørsler giver et problem med at kende sin præcise lokation i især miljøer uden fx. GPS dækning, som indendørs og under vand. Dog er der også eksempler på brug af robotter i så forskellige miljøer som i rumforskning, med selvkørende bil på mars, undervands robotter til udforskning af store dybder og flyvende droider til millitert brug, til overvågning af fjendtlige territorier. Global Positioning System, satellit og jordbaseret navigerings system 1

12 2 1. Introduktion 1.1 Begrænsninger for robotter Indenfor feltet med autonome robotter er der udviklet flere metoder til stifinding og navigation der kan kompenserer for robotters usikkerhed med at lokaliserer sig og usikkerhed i udførelsen af bevægelser. Autonome robotter skal derfor have en vis grad af autonom styring og fejlretning for at kunne bevæge sig korrekt eller også gerne en ret detaljeret aftegnelse af omverdenen at forholde sig til. Detaljerede kort kan i rå form fylde en del og kan være ret uhåndterlige, så alt efter robottens og miljøets konfigurationer det en balancegang at finde den rigtige teknik til styring, der også tager hensyn til korrekt navigation og til hurtig reaktion på genplanlægning af rute. Den styring der er valgt til Bispebjerg projektet har en verdensgengivelse på ned til 10 cm x 10 cm celler i et grid over verden og et foreløbigt domæne på ca. 245 m x 172 m og det er ekspanderende. Det giver et grid i rå form så stort, for robotten at søge og navigerer i, at det kræver hardware der normalt ikke benyttes i denne sammenhæng. 1.2 Motivation Selve robotten og softwaren er ved denne rapports tilblivelse valgt til opensource projektet Carmen[6] at styre robotten og der testes mapping med G-mapping[2] biblioteket. Carmen er en samling af styringsmoduler der er generaliseret til at kunne bruges på mange forskellige platforme og i mange forskellige scenarier, også i 3 dimentioner som. fx. i luften eller under vand. Carmen læser og navigerer domæner ned til 10 x 10 cm celler, hvorfor datamængden kan blive betragtelig og derved kan blive en hæmsko for hurtig eksekvering af rettelser i ruten under kørsel. G-mapping er et bibliotek der ved hjælp af filterteknikker på sensordata forsøger at optimerer indput og derved forbedre SLAM (Simultaneous Localization and Mapping). Den metode der i øjeblikket bruges til navigation bygger på et statistisk valg af stedbestemmelse ved navigation og denne metode er ikke altid optimal. Der er flere eksempler på at denne metode er for upræcis for at kompenserer for størrelsen ved for få detaljer. Desuden skal der i miljøet kører flere robotter samtidig og disse kan med fordel dele kortdata for at alle robotter får alle opdateringer samtidig. Derfor kan det være interessant at kigge på hvilke korttopologi der egner sig bedst til dette system. Projektet på Bispebjerg hospital er taget som udgangspunkt og afsæt for denne opgave men de analyser og løsninger der præsenteres i dette projekt er tænkt til at være mere universelle. 1.3 Relateret arbejder Der eksisterer adskellige eksempler på brug af mobile robotter i hospitaler. En af de første service robotter er HelpMate[5] robotten, der kan navigerer i gange og haller, kører i elevator, for at afleverer gods til forudbestemte destinationer. TUG[3] er en anden kommercielt udbredt robot, der transporterer gods i vogne ved at trække dem til deres destination. Et meget similært men helt igennem kommercielt projekt, er Roberta[1] robotten der er i skrivende stund er i færd med at blive testet og implementeret på Svendborg Sygehus, som også har til formål at aflaste portører med specifikke transportopgaver. Roberta er en lav konstruktion der kører med containere på ryggen til og fra for-

13 1.4. Arbejdesområde 3 udbestemte steder. Disse eksempler, med hver deres fordele og ulemper, indikerer en interesse for denne type af robotter. Andre eksempler på generel navigation i større domæner er fx. Google Earth, der navigerer med hele verden som domæne og kan ruteplanlægge både egen navigation og kan planlægge en rejse med offentlig transport. Af alternativer findes også Microsofts Bing maps og Nasa s World Wind og i Danmark kraks kort og så selvfølgelig producenter af dedikeret GPS navigationsenheder, som Garmin, Navigon og Tomtom mf. Alle disse bruger dog GPS til lokation, til forskel fra indendørs robotter. Generelt er søge og navigations -algoritmer allerede et gennemanalyseret felt og det forventes ikke at der fremkommer bidrag til den viden der allerede er opbygget på dette område. Målet er at anvende de allerede kendte teknikker på dette specifikke domæne scenarie og afstemme robottens navigation. 1.4 Arbejdesområde Nogle af de områder dette projekt omhandler er beskrevet i det følgende. Grafsøge algoritmer. For at finde frem til den mest effektive navigation testes ved benchmark de mest almenkendte og erfaringsmessigt mest brugbare ruteplanlægningsalgoritmer i den simulationsopstilling der bruges til at evaluerer de forskellige kortrepræsentationer. Der tages udgangspunkt i det kortmateriale der produceres af robotten på Bispebjerg hospital. Datastruktur. Eftersom kortdata er relativt stor og ekspanderende vil der blive eksperimenteret med datastrukturer af kortet så indlæsningen og søgningen bliver optimal. Kortrepræsentation. Kortet repræsenteres ikke nødvendigvis bedst i den fulde form, så der tilpasses til den algoritme der bruges til at finde den optimale rute. Der kigges på allerede kendte teknikker til at ændre kortet til en håndterlig topologi og det testes med de forbehold der er ved at bruge en robot som aktør.

14

15 Kapitel 2 Navigation Dette afsnit beskriver kort teorien bag navigation og robotik som nævnt i introduktionen. Der kigges på de grafsøge-teknikker der traditionelt anvendes ved søgning af den optimale rute. Desuden kigges på kortrepresentation og til sidst de begrænsninger der er ved at bruge en mobil robot til at navigerer i et fysisk og dynamisk rum. 2.1 Navigation Ordet navigation af latin navigatio betyder at fører skib og navigation som vi kender den i dag stammer fra og kan i mange henseender føres tilbage til skibstrafik. Ved moderne navigation er stjernerne dog oftest skiftet ud med GPS satelitter eller landkendingsmærker med valgte pejlemærker. For moderne navigation gælder samme parametre som for ældre skibstrafik. Man kan stille 4 spørgsmål for at samle sin ruteplan[7]. Hvor skal jeg hen? Dette er ofte en beslutning der ikke er taget af robotten. Enten kommer missionen fra menneskelig indblanding eller gives af et system overordnet robotten. Autonome robotter skal have et mål at kører efter eller en plan med bevægelse for at kunne se frem på den vej den skal kører. Hvilken vej er den bedste? Den bedste vej findes ikke kun ved en søgealgoritme. Dette indbefatter også repræsentationen af kortet. Der skelnes ofte imellem kvalitative (metriske) kort og kvantitative (topologiske) kort. Se beskrivelse af kort i afsnit om kortrepræsentation. Hvor har jeg været? Når robotten kører bør den opdaterer sit kort med forbedringer. Det kan være permanente forandringer så som en ny væg, eller det kan være meget trafik nogle bestemte steder på bestemte tidspunkter. Dette kan lagres og gøre at robotten kan trække på denne erfaring senere og derved forbedre performance. Hvor er jeg? At bestemme hvor i kortet robotten befinder sig er i de fleste udendørs situationer bestemt ved GPS, men indendørs kan det være et meget mere uoverskueligt problem, da der ikke er dækning for GPS signaler. Problemet er at robotten ikke altid er i stand til at stedbestemme så præcist at lokationen er brugbar. Derfor er der forsøgt en del forskellige tilgange til at hjælpe 5

16 6 2. Navigation med at forbedre robottens perception. Den lokation der er indbygget i Carmen API er statistisk baseret[11]. Den teknik gætter ved statistisk vurdering på et sted ud fra de indput man har fra sensorer og sammenligner dem med hvad der burde være i nærheden. En anden strategi der dog kun virker i simulation er at linke pejlemærker med nabopejlemærker og så bruge rækken for at bestemme det første mere præcist[7]. Det viste sig dog ikke at kunne lade sig gøre i den virkelige verden. I dette projekt er der kun taget højde for at der skal køres i et kendt miljø. Der er fx. ikke inddraget teknikker som gør at robotten kan kører i udforsknings tilstand og optegne et kort over et ukendt område og deri kunne overkomme luk-loopet problemet med at genkende et sted man har været før og kæde det sammen med sin optegning. Ej heller er fx. kidnapningsproblemet behandlet. Det går ud på at man tager robotten fra sin kendte position og placerer den et andet sted og robotten skal så selv genkende sin nye lokation. Desuden antages det at robotten har et vist autonomt talent, som fx. selv at kunne kører langs en væg og undgå påkørsel. 2.2 Kortrepræsentation Hospitalsrobotten har gennemkørt sit konfigurations rum og aftegnet et kort over fysiske miljø. Robotten er ført manuelt via en remote kontrol af en person der er gået bag den og derved har robotten via sine sensorer optegnet dele af kælderregionen på Bispebjerg hospital. Foremålet med kørslen var at eksperimenterer med kortoptegning kontra sensor usikkerhed[4]. Figur 2.1: Oversigt over hospitalet med kældergange markeret. Kortet over domænet figur 2.1 er oprindeligt i en opløsning på 1446 x 1442 for et område på 245 m x 172 m. Derved repræsenterer hver pixel en node af ca. 17 cm x 12 cm celler af et grid over hele området af en graf på noder. Størrelsen på noderne er nede i området af minimum og indikerer noget om denne robots konfiguration. Den skal have en ret detaljeret gengivelse af

17 2.2. Kortrepræsentation 7 omverden. Kortet er til simulatoren finpudset, da simulatoren kræver en ren hvid farve til de farbare områder, men som ses i nedenstående figur, er verdensgengivelsen grumset. Der er mere om kortets oprindelse og projektet med optegning på Nestor projektets hjemmeside[4]. Figur 2.2: Robottens optegning over det område den har kørt i en tilrettet udgave. Der er taget udgangspunkt i robottens optegning af kælderen, figur 2.2 da dette kort på mange måder giver et klassisk billede af de fejl der kan opstå ved mobile robotters perception. Dog er den hvide farve i kortet i figur 2.2 rettet til komplet hvis for at kunne læses af simulatoren. Kortet er fejlbehæftet ved at der ikke er helt lige vægge af følge, overgange er skæve, loops er lukket skævt og der er fejl i perceptionen ved at ting der ikke er tilstede er printet som objekter (sorte/grå pletter) på kortet. I 2.3 vises et eksempel på hvad der ligner et forfejlet forsøg på at lukke et loop. Dvs. at robotten har kørt samme strækning 2 gange uden at genkende stedet og opdage at den har været der før. Derfor tegner den en ny gang oven i den gamle, dog opmålt en skævt Metrisk kort Det mest umiddelbare og det mest enkle at gå til er en direkte aftegning af den virkelige verden. Det gør kortet målefast og gør det let at beregne ruter og genkende lokationer. Selv små lokationer kan beregnes med meget stor nøjagtighed og man kan beregne en ret præcis rute ved at ruten er angivet i ret præcise mål. En rute i et metrisk kort kan lyde: kør 8,4 meter drej 60 grader til højre kør 4,45 meter

18 8 2. Navigation Figur 2.3: Eksempel på fejllæsning af domæne. Dette gør at robotten ikke skal have den store autonomitet, så længe den ved hvor i kortet den er og så længe den har en motorik der kan følge instruktionen. Der er flere tilgange til repræsentation af domæne rummet (konfigurations rum), hvor regulærer grids er det mest brugte. Derudover er Voronoi diagrammer, quadtrees (i flere lag som 3D octrees), graf over kanter og hybrider her imellem andre måder at repræsenterer frirum. Frirum er den plads hvor robotten kan kører, altså hvor der ikke er optaget af vægge, møbler trapper ol. Et Voronoi diagram er ideen om at alle hjørner på objekter og genstande skal forbindes med en linie og midten af den linie er så en Voronoi node. Ved at forbinde alle Voronoi noder med Voronoi kanter har man så en vej lige i midten. Denne Voronoi rute er så fri bane til at passerer igennem et rum. Regulærer grids. Et grid med ensartede celler lægges ned over et billede af konfigurationsrummet. De celler der i sig har noget der ikke er fri rum for robotten at kører i markerer hele cellen optaget. Dette er også kaldet optaget grids (occupancy grids). Der er dog det problem at jo større celler jo mere forkert billede får man af omverdenen, da et lille objekt kan påvirke hele resten af cellen. Et quadtree er opdelingen af en gridcelle i 4 lige store underceller. Derved er der en oversigt og en detaljeret udgave af samme del af konfigurationsrumet og derved kan man nøjes med den detaljerede opløsning hvor der er brug for det, som fx. ved kørsel om hjørner. Denne opgave tager udgangspunkt i et regulært grid på baggrund af figur 2.4. Kortet omsættes til en node for hver pixel og hver kant der forbinder noderne er ikke sat, da der er en fast afstand imellem noderne. Noderne er indlæst som hægtede lister og som et 2 dimentionelt array. Det samme kort er manipuleret til opløsninger på ca. 500 x 500, 1000 x 1000, 1500 x 1500, 8000 x 8000 og x pixel for at simulerer forskellige domænestørrelser Topologisk kort Den mere menneskelige tilgang til en rute er vej hjælp af pejlepunkter. En let forståelig vejbeskrivelse er ikke at gå en bestemt distance, dreje meget præcist, men ved at forholde sig til objekter der

19 2.2. Kortrepræsentation 9 Figur 2.4: Det metriske kort der benyttes. udmærker et sted fra et andet. En topologisk vejbeskrivelse kan lyde: Gå ned til højre til du kommer til kirken drej ad gaden med brosten lige efter fortsæt til det lille gule hus Hvordan man drejer eller hvordan man kommer til pejlepunkterne er ikke defineret og det forudsættes at man genkender de pejlepunkter der benyttes, altså har foruddefineret en kirke. Derfor stiller topologiske kort meget større krav til en robot end at kører efter et metrisk kort. Dog kan der fabrikeres kunstige pejlemærker som fx. reflekser eller chips i vejen, let afkodelige symboler på vægge eller loft eller andet der stikker ud i miljøet som robotten kan finde hver gang. Udfordringen ud over at kende pejlemærket er også for robotten at kunne kaperer at miste et. Hvis robotten skal dreje ved kirken og denne er dækket til eller revet ned, så er robotten mere på afveje end hvis den mister en celle eller to i et metrisk kort. Hvordan pejlemærkerne defineres kommer an på beskaffenheden af det domæne der skal beskrives. I denne opgave er det topologiske kort fremstille manuelt og beskriver hver trafikknudepunkt i kortet, altså en gateway[10]. En gateway er beskrevet som et vejkryds, så der ved hver gateway er et valg om flere nye retninger. Dermed er kortet minimeret til noder der repræsenterer samlingerne af kanter i en graf. Ved at lade hvert pejlemærke repræsenterer en node er fra kortet dannet et graf der er direkte til at præsenterer for en søgealgoritme. Antallet af noder/pejlemærker og søgealgoritme kan optimeres til hvert scenarie med miljø og robot Hybrid kort For at få det bedste fra begge verdener kan den metriske og topologiske strategi blandes. Eftersom topologi kort kan være meget overordnede er de meget lette at søge i og derved være dem der perfor-

20 10 2. Navigation Figur 2.5: Det topologiske kort der benyttes. Tegnet oven i det metriske for at vise noders sammenhæng. mer bedst. Modsat er metriske meget tunge at håndterer når de når en vis størrelse, så at blande dem, så en robot fx. har begge kort ligger lige for at gøre. Derved kan robotten hurtigt finde sin rute ved det topologiske kort, men bruge fx. et metrisk kort at kører efter imellem hvert pejlemærke. Derved har robotten sit overblik og det metriske kort indlæses ad-hoc og sparer plads og ressourcer. Denne teknik er oplagt at bruge til meget store domæner og robotter med dårlig perception, men stiller krav til både kortgenerering af de metriske kort og til pejlemærker i domænet. En anden strategi[8] kan være at efterligne et Quadtree med forskellige størrelser på celler i et grid. Dog er størrelseforskellen at de detaljerede områder beskrevet i et metrisk kort og de store åbne områder et beskrevet i et topologisk kort. Derved kan en verdensgengivelse blive meget dynamisk, da den topologiske del kan antage meget store områder af fx. lange gange, store rum uden forhindringer. De åbne rum er defineret i forhold til robottens evne til at kunne kører selvstændigt, evne til at kunne følge en væg eller genkendelse af pejlemærker. 2.3 Bredde Først Søgning En af de mest simple strategier for grafsøgning er BFS[9]. Den ekspanderer fra startnoden og ensartet (uniformt) ud og når derfor målet (hvis et er tilstede) ved den korteste vej, først. Dvs. alle stier med n steps nås før alle stier med n +1 steps. Derved bliver første sti fundet altid den korteste. Det er en uinformeret algoritme, dvs, den kun kender start og mål -noder og har en beregningstid på O( E + V ) hvor E er kanter og V er noder hvor i værste tilfælde alle gennemløbes. Den benytter en Først-Ind- Først-Ud (FIFO) kø, dvs. et først-til-mølle princip for køen af noder der skal behandles. Der er i denne opgave benyttet en gridbaseret graf, uden afstands/kører værdier og uden retningsbegrænsninger for kanter, så bedste vej er udelukkende baseret på antal noder.

21 2.4. A stjerne 11 Gennemløb af BFS for grafen G = (E, V): Funktion BFS(G, startnode, goalnode): startnode.marked = true enqueue(q, startnode) while Q null do u = dequeue(q) if u = goallnode then break end if for all E u do if u marked then u marked = true u Parent = E enqueue(q, u) end if end for end while Hukommelsesforbruget for en BFS er højt, da algoritmen ser alle noder som potientielle gode og derfor gemmer alle indtil målet er nået. Der er, modsat andre algoritmer ingen vurdering af noderne før målet er nået og der tegnes en vej fra målnoden tilbage til startnoden. Dette gøres ved at følge sporet af forældrenoder tilbage fra mål til start. I familien af simple søge strategier er også DFS (Dybde Først Søgning). Den adskiller sig fra BFS ved at forfølge en node i dybden af træet i stedet for at søge alle nærliggende. Derved kan der være tilfælde hvor den laver et lucky punch og rammer målet inden for kort tid, men dette kan ikke med sikkerhed benyttes. Det har dog den fordel i hukommelsesforbrug at når den har gennemsøgt en hel gren, kan denne række noder frigives fra hukommelsen og sparer plads. DFS er ikke testet i denne opgave, da en strategi med en informeret algoritme virker som et bedre alternativ. 2.4 A stjerne A* algoritmen er en mere raffineret strategi, da den er udstyret med en heuristik[9] der, til forskel fra BFS er informeret og gætter på i hvilken retningen målnoden er. Den er ligeledes komplet og finder altid målet hvis et er til stede. A* tager som BFS udgangspunkt i startnoden, men hvor BFS finder alle nærliggende noder, vurderer A* hver nodes afstand til mål og benytter kun den bedste, dvs. går i dybden først. Dette reducerer antallet af noder der skal gennemsøges betragteligt. Der er forskellige måder at finde afstand til mål og en simpel heuristik (og brugt i dette projekt) er Manhatten. Den tager den tilbagelagte afstand fra start til nuværende node g(n) + for den node der undersøges, den tilbageværende afstand i luftlinie til målet h(n). Dette giver evalueringsfunktionen f(n) = g(n) + h(n) til den pris der er for at bruge n. Dette tager dog ikke højde for forhindringer og lign. på vejen for h(n) og derved er den optimistisk i forhold til aldrig at være større end den optimale vej. Ved at g(n) er kendt overestimerer A* så aldrig den pris der er ved f(n). A* beholder som BFS alle noder som potientielle, men da antallet af noder der undersøges er væsentligt mindre er hukommelsesforbruget

22 12 2. Navigation tilsvarende mindre. A* har en tidskompleksitet afhængig af dens heuristik, men for denne er O( E + V ) hvor E er kanter og V er noder hvor i værste tilfælde alle gennemløbes. Det teoretisk værste tilfælde er at alle noder skal undersøges, men i praksis vil det scenario være højest utænkeligt, da den altid vil søge i retning af mål og derved udelade nogle noder. Gennemløb af A*: Function A*(startnode,goalnode): closedset // Allerede evaluerede noder openset // Noder der skal evaluere g() // Tilbagelagt distance h() // Heuristisk gæt på distance til mål f() // Anslået samlet distance fra start til mål enqueue(openset, startnode) while openset null do x = dequeue(openset) // prioriteret kø, returner den node med mindste f() if x = goallnode then break end if enqueue(closedset, x) for all E x do if E closedset then E.marked = true E.Parent = x enqueue(openset, E) end if end for end while A* kan optimeres på mange områder, fx. kan retningsændring straffes og give en mere jævn kørsel, hver node kan have flere nabonoder end kun nord, øst, syd og vest for en mere direkte kørsel og der kan optimeres på hvordan heuristikken gætter på den resterende afstand. 2.5 Robotters hardware Den robot der foreløbig testes med i på Bispebjerg hospital er ikke nødvendigvis den endelige, så for helhedens skyld er der ikke taget hensyn til en fast robotmodel i denne opgave. Dog har den nogle af de karakteristika der er ved moderne robotter. Bevægelse for robotter foregår ved dens bevægelses-effektorer, som fx. hjul, ben eller bælter. Hvilke bevægelses- effektorer den har til hvilke miljøer har stor indflydelse på dens navigations egenskaber. I miljøer med meget ujævne overflader kan robotten være udstyret på en måde der giver den stabilitet, men derved også begrænsninger i fx. stor dreje/vende radius, hvilket influerer på fx. hvor skarpe sving den kan tage på en bestemt vej. Dette kunne være fx. være en flad robot med 4 eller flere hjul på hver side. Skal robotten bruges til at trække emner er drejeradius ligeledes hæmmet, hvis emnet er langt, som fx. en hospitalsseng. De fleste robotter til indendørs brug er konstrueret holonomisk dvs. de kan dreje om deres egen akse, ved typisk at have 2 trækkende forhjul og et baghjul der bare slæber. Andre kan vende hjulene og kører

23 2.6. Hypotese 13 lige godt fremad som sidelæns, hvilket også gør navigation nemmere. Ved ikke holonomiske robotter foregår styringen ofte som i en bil, ved at dreje på 2 hjul, hvilket giver en større drejeradius. Eller ved at hjulene beholder deres retning i forhold til robotten og kører i forskellige tempi og derved ændre retning på selve robotten. Robottens perception af omverden kan også bruge bevægelses-effektorerne til at opmåle fx. tilbagelagt distance eller antal grader drejet ved sving. Dette kan også være en selvstændig odometrisk enhed, som fx. et ekstra hjul. Der kan forekomme stor usikkerhed ved dårlig kontakt med fx. glat gulv så denne form for passiv perception understøttes også af sensorer, som fx. kamera og de aktive sensorer sonar og radar. De aktive sensorer sender energi ud, for at læse reflektionen der kommer tilbage og derved danner et billede at verden i den retning der måles. Nogle sensorer er baseret på korte men præcise målinger og andre på lange og brede målinger, men kan derved ikke gøres så præcise. For de fleste mobile robotter gælder at de fylder en del i landskabet, på grund af batteri, last, størrelse, design for stabilitet og lign. For at kunne beregne en rute skal der under implementering tages højde for at der beregnes fra robottens midte, så der tages hensyn til bredden. Dette medfører at der er et stykke på hverside af robotten hvor den ikke kan passerer fx. en snæver døråbning og ved den klassiske disciplin, kører efter en væg skal der tages højde for placering af sensorer kontra bredden af robotten. Kører en mobil robot med last efter sig eller har den hjul placeret på en måde at dens drejeradius er forholdsvis stor kan der ruter der ikke kan bruges ved specielle situationer. Fx. hvis hospitalsrobotten kører med en hospitalsseng på slæb vil den have svært ved at komme rundt om et skarpt hjørne, hvorfor at denne rute må regnes for at være ubrugelig Robotters navigation Der er meget forskellige tilgange til robotters kørsel og brug. Den første opdeling kan gøres på om de er guidede eller ej. En guidet robot kan forstå som en der er ført, som man kender det med drenge og deres fjernstyrede biler. En uguidet robot kan være en af flere typer. Enten en der kører efter et spor, som kan være magnetiske eller farvede baner på gulv eller loft, ledninger der er fræset ned i gulvet med et signal i, eller det kan være andre former for virtuelle togskinner. En anden type kan være den autoguidede. Det indebærer at den selv kan finde vej. 2.6 Hypotese Algoritme De 2 algoritmer der er valgt i denne analyseopgave er langt fra dækkende for alle de forskellige afarter og varianter der er i feltet af søgealgoritmer. Derfor er resultatet af søgningen heller ikke dækkende for hvad der kan laves i en samlet løsning til robotnavigation, med tilpasset dataset og -struktur. Dog kan de give et fingerpeg om i hvilken retning der kan optimeres på netop denne konfiguration. Ud fra ovenstående beskrivelse af de 2 algoritmer kan det udledes at A* i de fleste tilfælde vil være BFS overlegen, fordi A* pga. af færre noder at undersøge, vil eksekverer hurtigere. Dette vil komme til større udtryk jo større en graf der skal søge i. Dog er det ikke sikkert at der i denne opgave vil være en forskel at sporer, da søgeområdet er begrænset, men domæneområdet er stort.

24 14 2. Navigation Datastruktur Søgningen af bedste vej i domænet er betinget af en datastruktur der er forenelig med søgealgoritmen. Derfor vil der blive testet de 2, fra erfaringen, mest gængse måder at repræsenterer data. En hægtet liste med noder, der hver især kender egne egenskaber og sine naboer. Et 2D array af noder der er meget mere primitive noder fordi der i arrayet ligger deres placering og der kan itereres over arrayet, til foreskel fra listen, der itererer over hver node. Umiddelbart burde et Array være hurtigere at søge igennem end en liste, da man kan springe direkte til et felt i arrayet, men skal itererer igennem hele listen for hver node der skal findes. Om det har betydning for søgetider i denne opgave er blandt andet et spørgsmål om størrelse på datasæt. Strategien for repræsentation af data til søgealgoritmen er betinget af om algoritmen har brug for teknikker for at minimerer søgetider. De to yderpunkter er et helt målefast kort over omverdenen (metrisk kort) og et kort der kun aftegner pejlemærker (topologisk kort). Den første strategi er udgangspunktet for dette projekt, men der er eksempler på at bliver kortene for store for datastruktur og algoritme, kan en kombination eller hybrid tænkes ind. Enten ved at ændre grid cellernes størrelse alt efter miljøet eller ved at have kort i 2 lag, så man navigerer efter et topologisk, men har metriske kort til kørsel imellem hver topologisk pejlemærke.

25 Kapitel 3 simulering Dette afsnit beskriver design af simulatoren. Der beskrives hvad der skal simuleres, hvordan det simuleres og hvad der forventes af resultat fra simulatoren. Sidst i afsnittet er beskrevet afviklingssekvenserne der er brugt i test cases i afsnit Hvad skal simuleres Som det fremgår af foregående afsnit kan kort over domæner med høj detaljegrad betyde meget store datamængder. Robotter der er afhængige af meget deltaljerede beskrivelser for at kunne kører har brugt teknikker til at dække over lokeringsfejl under kørsel. Foremålet med denne simulator er at beregne en bedste rute i et kort så detaljeret som muligt, uden at korrigerer data. Dette for at simulerer en robot, der får en kørselsopgave og så finde den bedste vej til målet. Simulatoren skal derfor kunne indlæse domænet, tage som indput et start og slut punkt, beregne den bedste vej og leverer resultatet i, for en robot, en brugbar form. Desuden er tilføjet et grafisk resultat for at gøre simulatoren mere anvendelig til indblik i kørsel. Den bedste vej vises både som antal trin imellem start og mål og en grafiske optegnelse. Selvom der som domæne er taget udgangspunkt i en robot der skal kører på Bispebjerg Hospital er der i simulatoren lagt endnu større kort, for at simulerer et endnu større domæne. Det er ikke den fulde kælder der er opmålt på Bispebjerg Hospital og der kunne i fremtiden tænkes at robotterne skal kører andre steder også. En af kompetencerne for simulatoren er at den kan indlæse forskellige størrelse kort og opererer med disse. Målet er at lave en model der med uendelige store kort kan overskues og søges i, for at robotten hurtigt kan finde en rute. Dette inden for en rimelig størrelse af hardware til rådighed. Slutresultatet er en simulator der giver et godt estimat over hvor god en navigation til robotter der ikke har en klar lokationsevne, man kan lave, ved brug af simple teknikker. Der er benchmark for den bedste vej, behandling af største kort og en tidsfaktor for begge. Bedste rute Når robotten får til opgave at kører til et mål skal den finde den bedste rute dertil. I dette tilfælde er det kun antal steps der er successkriterie. Der er ikke parametre som tung trafik, ofte spærringer, dårlig vejforhold og lign. i beregningen. Bliver robottens vej afskåret eller afbrudt på anden måde skal robotten hurtigt kunne genberegne en ny rute. I hvert fald så tilpas hurtigt at der ikke opstår pauser i robottens arbejdsmønster og fx. laver en trafikprop. 15

26 16 3. simulering Figur 3.1: Interface på simulatoren. Største kort Så store og detaljerede kort som muligt skal indlæses og bruges til at finde en rute. Som en del af navigationsrutinen skal dette foregå så tilpas hurtigt at robotten kan bruge sin rutefindings algoritme herpå uden større pauser i robottens bevægelsesmønster. Størrelsen på billedfilen der indlæses, simulerer den detaljeringsgrad som en robot har brug for. I dette tilfælde kan det være ned til 10 x 10 cm og modsat vil større kort simulerer et større domæne. Indput til simulatoren er for hvert scenarie en billedefil i forskellig opløsning, på nær af den testcase der tester indlæsning af tekstfiler. 3.2 Design og implementering af simulator Simulatoren er lavet i C-sharp.net vers. 4.0 på en Win-form. Det er programmeret i Microsofts Visual studio 2010 på OS Windows 7. Der er i de testcases med tidssammenligning eksekveret i den samme applikationstråd, men ved pauser i eksekvering af en Case, er der tilføjet en arbejdstråd til eksekvering og er derfor ikke sammenlignelig på tidsmålinger. De væsentlige klasser ses i 3.2 og er beskrevet herunder. LoadMaps For hver Case kaldes en load funktion i LoadMaps klassen, der returnerer den type kort der ønskes. Dette kort optegnes i det format der returneres, nodeliste, nodearray eller bitmap. Det betyder at hvad der vises grafisk efter indlæsning er optegning af de noder der returneres. Der er 5 kortstørrelser at vælge imellem, men vælges intet, er det mindste størrelse der er default valg. Kortet der skal indlæses køres i et loop igennem og tjekkes for farve. Hvid er farbart område og ikke hvid er blokeret/optaget område for robotten. Der er ikke nuancer i denne implementation, så billedfilerne der benyttes har fået poleret deres hvide farve. I Cases hvor en hægtet liste returneres, er det kun øverste venstre hjørne, dvs. koordinat 0, 0 der

27 3.2. Design og implementering af simulator 17 Figur 3.2: Klassediagram for simulatoren. returneres som handle til listen. Hvor der returneres et array er det hele arrayet der returneres. I tilfælde med topologiske kort er det hele bitmap filen der returneres. Der er bliver brugt 2 nodetyper: Figur 3.3: De 2 node typer for henholdsvis hægtet liste og array.

28 18 3. simulering TreenodeBFS bliver brugt til hægtet liste se figur 3.3. Den indeholder forældre, nabo-noder i 4 retninger, status som optaget eller fri, koordinat og rutelængde f(n) = g(n) + h(n) hvor g(n) er tilbagelagt rute og h(n) er afstand til mål. PointNode er det objekt der bruges i arrayet. Det indeholder information om sit koordinat, forældre og rutelængde f(n) = g(n) + h(n) hvor g(n) er tilbagelagt rute og h(n) er afstand til mål. Algorithms er klassen der har ansvar for de søgealgoritmer der benyttes. Klassen returnerer den bedste rute og de noder der også er undersøgt i hver sin liste af den nodetype der bruges til pågældende Case. Der er 2 trin i afvikling af en simulation for Case 1-5. Dels er der indlæsningen af kort og dels søgningen i kortet. Dette er opdelt i 2 sekvenser for at kunne benchmarke hver sekvens. For Case 6-7 søges der i samme sekvens som der indlæses. For at give den bedste sammenligning af de forskellige Cases er valgt samme start og stop punkter, ud fra samme punkt på den grafiske visning. Dette gør ruteberegningen mere sammenligenlige. Startpunkt er 22, 435, nederst i venstre hjørne og slutpunkt er 460, 148 er længst til højre i simulatorens visning på 500 x 500 punkter. Disse standard punkter dækker den længste rute i kortet og imellem dem er flere vejkryds hvor søgealgoritmens egenskaber kan komme til udtryk. Mulighedder for opsætning af simulator: Mapsize Vælg størrelse på kort, vælges intet, er det mindste kort gældende. Case Vælger den algoritme og datastruktur der er tilknyttet hver testcase. Indlæsning af kort går i gang. Hide map Tilvælges hvis der ikke skal vises grafisk resultat af indlæsningen. View search progress Sætter en pause mellem hver nodeberegning så fremdriften af rutesøgningen kan følges. Set test points Sætter start og slut punkter på kortet. Disse punkter tilpasses automatisk til hver kortstørrelse. Start og Goal -point Manuelt valg af start og mål -punkter i kortet. Clear window Sletter resultater i tekstvinduet. Memory use Viser den øjeblikkelige brug af hukommelse. Bruges inden hver indlæsning for at udregne forbrug. Run Starter beregning af bedste rute. Resultat vises i antal steps i tekstfeltet og grafisk på kortet. 3.3 Resultat af simulation For indlæsnings sekvens. Simulationen indlæser kortet. Simulatoren skriver i tekstvinduet om det gik godt, hvor stort kortet er, tid for indlæsning, tid for gentegning af kort og hukommelsesforbrug

29 3.4. Fejl og mangler i simulator 19 for hele applikationen. Fordi gentegning er baseret på de noder der kommer tilbage fra LoadMap klassen tager det tid at læse hver node i listen/arrayet og tegne på det bitmap der vises. Derfor er der opdelt i 2 tider. Tidsangivelsen er i timer:minutter:sekunder:millisekunder. Memory forbrug er vist i bytes. For rutesøge sekvens er resultatet antal noder den fundne rute består af, hvor mange noder der er undersøgt i alt og tiden for søgninge. Desuden vises rute og undersøgte noder i hver sin farve i det grafiske område. For indlæsningen af kort er der en stor foreskel i forbruget af hukommelse med og uden optegning af bitmap med resultatet af indlæsningen. For eksempel for 8017 x 7995 kortet svinger det imellem 77MB til 335MB. Derfor er i afsnit 4 testet uden grafik af resultat for dataindlæsning Brug af simulator For at gøre testcasene ens er der lavet samme trin for afvikling af simulering. Vælg kort Vælg størrelse på kort, vælges intet, er det mindste kort gældende. Vælg testcase Vælg den algoritme og datastruktur der skal testes. Indlæsningen af data går i gang. Vælg start og stop punkter på kortet Der skal inden for det hvide område (kældergange) vælges et start og et slut punkt for ønsket rute. Vælges der udenfor gangarealet svarer det til at robotten kører uden for gangen og simulatoren returnerer med fejl. Der kan sættes et fast start og slut punkt for sammenligningen ved at trykke på set test points. Start rutesøgningen ved run Simulatoren beregner den bedste vej og viser den grafisk. Bemærk at ikke alle trin kan afvikles i alle cases. Se hver case for konfiguration. 3.4 Fejl og mangler i simulator Der er ved implementering af simulatoren taget valg der har indflydelse på det grafiske resultat. Desuden er følgende fejl er ikke rettet og skal tages i betragtning ved eksekvering af simulatoren: Centrering af start og slut punkter Der er for punkter på den grafiske visning markeret farver for en node, men markeringen går over flere noder. Dog er det øverste venstre node der er den gældende. Dette kan ved fx. topologiske ruter vise en rute der går frem og tilbage for at nå frem til denne node. Tilnærmelser til topologiske punkter I case 6 og 7 søges der i et topologisk kort. Start og slut punkterne ligger sjældent lige oveni de pejlemærker der er repræsenteret ved noderne i det topologiske kort. Derfor er der lavet en tilnærmelse fra det valgte punkt til den nærmeste topologiske node. Denne tilnærmelse er ikke retningsbestemt. Det vil sige at den kan risikerer at gå baglæns i stedet for i retning mod slutnoden og ved mål gå forbi mål til nærmeste pejlepunkt til slut på ruten.

30 20 3. simulering Samling af kanter ved hybrid kort Der er i Case 7 en metrisk søgning for hver kant i et topologisk kort og disse er ikke samlet i henhold til den samlede rute. Det vil sige at fejlen med tilnærmelser til de topologiske noder kan videreføres til tilnærmelser til bedste overgang til næste metriske kort, uanset topologisk node placering i overgangen. Nulstilling Ved gentagende tests kan den automatiske oprydning (garbargecollection) ikke følge med, så tidsmålingerne bliver ikke optimale fordi de tidligere tests stadig er loadet. Genstart af applikation tilrådes.

31 Kapitel 4 Cases Dette afsnit omhandler de forskellige testcases der er gennemført og resultatet af deres eksekvering. Test casene er udviklet iterativt, men der er lagt fokus på 2 områder. Dels testes søgealgoritmer for bedste og hurtigste vej og deres indbyrdes forskelle for dette scenarie. Dernæst er testet repræsentationen og datastrukturen for domænet ud fra forskellige kendte teser om problematikken med meget store og detaljerige domæner. Som kort er brugt den optegning over kælderregionerne på Bispebjerg Hospital som robotten selv har optegnet, ved hjælp af sensorer og G-Mapping biblioteket[2]. Dette kort et manipuleret til forskellige størrelser og opløsninger. Eftersom hver pixel repræsenterer en celle i det fysiske grid er hver pixel oversat til en node i gridet over domænet. Derfor er pixelstørrelsen ændret for at simulerer mindre celler og derved en optegning af kælderen på Bispebjerg Hospital i større detaljer. Case 1: Der indlæses forskellige størrelser af kort, til en hægtet liste datastruktur. Der testes BFS algoritmen på denne. Case 2: Der indlæses forskellige størrelser af kort, til en hægtet liste datastruktur. Der testes med A* algoritmen på denne Case 3: Der indlæses forskellige størrelser af kort, til en 2D array datastruktur. Der testes BFS algoritmen på denne. Case 4: Der indlæses forskellige størrelser af kort, til en 2D array datastruktur. Der testes med A* algoritmen på denne Case 5: Der indlæses forskellige størrelser af kort, til en hægtet liste datastruktur fra en filstream i stedet for et billede. Case 6: Der benyttes A*, på et kort med topologisk datarepræsentation. Case 7: Der mixes den bedste fra case 1-4 med case 6, for en effektiv hybrid struktur. 21

32 22 4. Cases Kriterier for evaluering For hver enkelt testcase er evalueret ud fra ønsket om at finde en balance imellem tid og kvalitet. Hver case er beskrevet med måleresultat og sammenlignet grafisk. Underordnet hardware for simulatoren er taget udgangspunkt forskellen i tiden for at indlæse domænet, størrelsen af det indlæste domæne, søgetid i domænet og optimal vej. Den optimale vej er vurderet grafisk også. Hver case er gennemløbet mindst 5 gange og resultatet er et gennemsnit af disse. Det er gjort for at kompenserer for evt. udfald på hardware med multitasking hvor andre processer kan kræve resourcer fra simulatoren. Med udgangspunkt i Carmen API[6] der i værste fald læser sin omverden i celler ned til 10 x 10 cm og den fysiske kælderregion på ca. 245 m x 172 m er de 5 kort henholdsvis en verdensrepræsentation på: For de 5 forskellige kortstørrelser er de 3 mindste relevante for projektet på Bispebjerg, Kortstørrelse Cellestørrelse 514 x 513 0,48m x 0,34m 1014 x ,24m x 0,17m 1469 x ,17m x 0,12m 8017 x ,03m x 0,02m x ,02m x 0,014m Tabel 4.1: Cellestørrelse repræsentation i henhold til den fysiske verden. mens de 2 større er til test af det generelle tilfælde, hvor et større domæne eller en mindre opløsning er ønsket. Der er for hver størrelse af kort lavet et gennemløb i simulatoren der optalte alle farbare noder og dette giver i gennemsnit ca. 12 % af det samlede areal til farbart område. Der er en anelse udsving for farbart område som opløsningen ændre sig for kortet. Der er for hver Case lavet plots af resultaterne. Plots er vedlagt i appendiks. 4.1 Case 1 Denne case består af 5 delelementer. Der indlæses 5 forskellige størrelser af kort, til en hægtet liste datastruktur. Der testes med BFS algoritmen for hver delcase. Afviklingssekvensen for simulatoren er beskrevet i afsnit om simulation Formål Formålet med denne første test er at prøve at finde en balance imellem tid for indlæsning og størrelsen af kort, for dermed at kunne vurderer hvilken detaljegrad der kan forventes. Desuden testes søgningen efter bedste rute med BFS(Bredde Først Søgning). Kan der indlæses og søges inden for rimelig tid? Størrelserne på kortet valgt til ca. 500 x 500, 1000 x 1000 og 1500 x 1500 for at se efter en lineær sammenhæng. Desuden er der kort på ca x 8000 og x for at finde en øvre grænse.

33 4.1. Case Konfiguration af Case Case 1 starter sin sekvens med at indlæse et kort, se afsnit om simulatoren for afviklingsvarianter. Ved indlæsning gennemløbes kortet pixel for pixel og hver pixel repræsenteres ved et node-objekt (ThreeNodeBFS) der kender sin status som fri eller optaget og kender sine naboer i 4 retninger. Der måles for tid på indlæsning og størrelse på datastruktur. Dernæst søges efter en rute i det indlæste datasæt med BFS. Det værste tilfælde for størrelse og tid på BFS søgningen kan beregnes af O( E + V ) (4.1) hvor der i kortet ikke er forhindringer. Det kort der benyttes er begrænset af at der kun er smalle gange tilgængeligt for en bedste vej og derved bliver den reelle værste sti minimeret til det totale antal farbar noder. Der er benyttet standard start og slut punkter for alle gennemløb og der er fravalgt den grafiske visning af indlæsningen Resultat Der er opdelt de to primære fokusområder, indlæsning og søgning. For hver af de 5 størrelser af kort er der lavet en måling på samme måde så resultatet er direkte sammenlignenligt. Figur 4.1: Resultat af BFS søgning i 514 x 513 kortet, med undersøgte noder og bedste rute.

34 24 4. Cases Kortstørrelse Indlæs tid Indlæst størrelse 514 x 513 1,1 sek 18MB 1014 x ,6 sek 66MB 1469 x ,2 sek 121MB 8017 x ,04min* 1807MB* x * * Tabel 4.2: Gennemsnit af 5 indlæsninger af hægtet liste repræsentation. * kort ikke indlæst. Der er for de 2 største kort 8017 x 7995 og x ikke fuldført en indlæsning. Systemets egen øvre grænse for hukommelsesforbrug bliver ramt ved ca. 1,8 GB ramforbrug. Dette sker efter ca. 4 minutter. Derfor er der ikke søgetider og størrelse på disse to scenarier. Kortstørrelse Søgetid bedste sti total søgesteps 514 x 513 0,35sek x ,7sek x ,0sek x 7995 * * * x * * * Tabel 4.3: Gennemsnit af 5 BFS søgninger for hver af de 5 kortstørrelser. * kort ikke indlæst. 4.2 Case 2 Case 2 er en forlængelse af case 1. Der indlæses samme 5 kort på præcis samme måde. Forskellen er at der søges med en A* i stedet for en BFS. Der er ikke beskrivelse af indlæsning, da det er en gentagelse af indlæsningen i Case Formål Formålet med denne case er at kunne sammenligne BFS søgning fra case 1 med en A* søgning. Søgningen forventes ved en A* at være mere optimal end BFS hvorfor der forventes mindre søgetider Konfiguration af Case Case 2 starter sin sekvens med at indlæse et kort, se afsnit om simulatoren for afviklingsvarianter og konfiguration af case 1. Ved indlæsning gennemløbes kortet pixel for pixel og hver pixel repræsenteres ved et node-objekt der kender sin status som fri eller optaget og kender sine naboer i 4 retninger. Det er samme node type (ThreeNodeBFS) som i Case 1. Det værste tilfælde for størrelse og tid på A* er søgningen kan beregnes af O( E + V ) hvor der i kortet er alle noder farbare. Heuristikken i denne A* er Manhatten, baseret på f(n) = g(n) + h(n) hvor g(n) er den tilbagelagte sti beregnet som den absolutte værdi af sidste nodes X og Y,

35 4.2. Case 2 25 trukket fra startpunkts X og Y. h(n) er beregnet med den absolutte værdi af den nye nodes X og Y trukket fra målnodens X og Y. Det kort der benyttes er som i case 1 begrænset af at der kun er smalle gange tilgængeligt for en bedste vej og derved bliver den reelle værste sti minimeret til det totale antal farbar noder. Der er benyttet standard start og slut punkter for alle gennemløb Resultat Der er i denne case kun lagt fokus på søgningen efter den bedste sti i kortet. For hver af de 5 størrelser af kort er der som i case 1 lavet måling på tid, størrelse og bedste vej så resultatet er direkte sammenlignenligt. Der er til start testet en Heuristik hvor g(n) er den tilbagelagte sti beregnet som den Figur 4.2: Visuel verificering af A* gennemløb ved 514 x 513 pixels/noder. Der er 22 undersøgte noder ud over bedste rutes 792 noder. Kortstørrelse Søgetid bedste sti total søgesteps 514 x 513 0,3 sek x ,9 sek x ,8 sek x 7995 * * * x * * * Tabel 4.4: Gennemsnit af 5 A* søgninger for hver kortstørrelse. * kort ikke indlæst.

36 26 4. Cases optimale rute, via forældrenoder tilbage til startnoden. Denne beregning tager væsenligt længere tid end beretning direkte på koordinater, selvom resultatet er samme rute, med samme antal steps og antal undersøgte noder. Beregning af tilbagelagt rute, er på grund af søgetiden er valgt at være baseret Kortstørrelse g(n) koordinat søgetid g(n) forældre søgetid 514 x 513 0,3 sek 18 sek 1014 x ,9 sek 2,4 min 1469 x ,8 sek 12 min 8017 x 7995 * * x * * Tabel 4.5: A* søgning i hægtet liste. Sammenligning af søgetider for 2 versioner af g(n). på beregningen via koordinater. 4.3 konklusion på case Data indlæsning Indlæsningen af data er fra samme kilder for begge cases og til samme struktur, en hægtet liste. Noderne kender deres position, forældre, naboer og om de er frie felter eller ej. Tiden det tager at indlæse det mindste kort er på ca. 1 sek. og vil for en robot i fart ikke forsinke ret meget at skulle indlæse et nyt kort. Ved ca x 1000 noder er indlæsningstiden ca. 6 sek. og det plus en søgetid kan være nok til at en robot der skal genplanlægge sin rute under kørsel vil stanse et øjeblik. Størrelsen på de første 3 kort på op til ca. 120MB er ikke kritisk for hardware der må forventes i en robot. For indlæsningstider for ca x 1500 kortet på over 10 sek. skal det nok ikke være ofte at kortet skal genindlæses, i et miljø hvor en robot med last kan holde og spærre en passage og lign. Under gennemløbet af kortbilledet for konvertering af hvert pixel til noder tjekkes farven i billedet for at se om noden er fri eller optaget. Dette tjek er på ARGB farven hvid for fri og ikke hvid er optaget. Da robotten optegner sin omverden er det med mange nuancer. Derfor er der stor forskel på det oprindelige kort og det der tegnes med de indlæste noder. Især når størrelsen øges på kortet bliver overgangen imellem grå og hvid endnu mere uskarp. Dette ses ved rute langs med en væg. For de to største kort er det ikke muligt at indlæse med den konfiguration simulatoren har nu. RAM forbruget når sit maximum for standard indstillinger for miljøet og med mellemtider på 4 minutter og derover virker det ikke realistisk at kunne bruge så store kort i et dynamisk miljø. Der er ved begge tests brugt en retning på 4 noder, dvs. en nord, øst, syd og en vest. Der er ikke testet med de mellemliggene, nord-øst, syd-øst, syd-vest og nord-vest, dvs. 8 retninger, for at se om dette kunne have øget tiden til beregning og oprettelsen af hvert nodeobjekt. Der er testet med at lave begrænsninger for robotten, ved at tage højde for en robot på 1 meter i bredden, men alle gange er meget ens i bredden, så resultatet i dette scenarie er, at enten er alle gange farbare eller også er ingen, og der er ingen rute til målet. Desuden er prøvet at lave større drejeradiuser, ved kun at dreje ved hjørner der har mindst 3 nabonoder imellem sig. Det har heller ingen effekt i et miljø hvor alle hjørner er tæt på 90 grader. Begrænsninger for robotten er fjernet igen da de ingen effekt havde.

37 4.3. konklusion på case Søgning For BFS når søgningen næsten hele det frie område af gridtet igennem. Det tager en anelse mere tid at skulle søge så meget, men vejen er faktisk kortere end søgningen med A*. For kort af en størrelse der kan indlæses med den nuværende hardware konfiguration er forskellen på søgealgoritmen ikke markant forskellig. For den visuelle validering af A* ses tydeligt at der er fundet forskellige veje for Kortstørrelse algoritme Søgetid rute total søgesteps 514 x 513 BFS 0,3 sek x 513 A* 0,3 sek x 1011 BFS 1,7 sek x 1011 A* 0,9 sek x 1465 BFS 3,0 sek x 1465 A* 2,8 sek x 7995 BFS * * * 8017 x 7995 A* * * * x BFS * * * x A* * * * Tabel 4.6: Sammenligning af performance for BFS søgning i hægtet liste og A* i samme liste. * kort ikke indlæst. BFS og A*. BFS har fundet en kortere, men A* har pga. heuristik fundet en mere direkte rute til mål, der dog er længere pga. gangenes udformning. A* kommer her til kort ved at være en dybde først søgning. Hvis den havde søgt i bredden, som fx. Dijstras må det antages at den havde fundet samme vej som BFS. A* s brug af en manhatten heuristik ses på at ruten er kvadratisk. Med det menes at ruten ikke er særlig tilbøjelig til at ændre retning og kun gør det ved retvinklede ændringer. Denne implementation af Manhatten tager tilbagelagt afstanden ved X, Y koordinater og afstand til mål ved X, Y koordinater. Når der tilføjes et step til g(n) og trækkes 1 fra h(n). Derfor vil f(n) være en meget statisk værdi. Dette kunne undgås ved at benytte Tie Break. Tie Break er en værdi p (ikke random) der lægges til h(n) eller g(n) for at gøre alle f(n) forskellige. Værdien p kan komme fra forskellige sammenligninger af h(n) og/eller g(n) der alle giver forskellige fordele/ulemper. Derimod kan den euclide afstand, en direkte luftlinie, være mere direkte og være tilbøjelig til at klæbe sig mere imod væggene i målretningen og gå på skrå i retning af målet. Den Euclide afstand er: h(n) 2 + g(n) 2 (4.2) Den har dog sin fordel ved grids hvor den kan gå i alle retninger og ikke kun i 4. I scenariet hvor der ikke opdeles i indlæsning og søgning, men hvor der søges direkte i billedfilen, må det antages at A* har større potientielle, ved at søge færre noder igennem og søge retningsbestemt. Ved at der søges i samme sekvens i en fil der ikke så tung som den fulde hægtede liste vil A* komme til sin ret og jo større domæne der søges i jo mere effektiv vil A* være pga. de færre noder at undersøge.

38 28 4. Cases 4.4 Case 3 Denne case består som de foregående cases af 5 delelementer. Der indlæses 5 forskellige størrelser af kort, til en datastruktur af et 2D array. Der testes med BFS algoritmen på hver kortstørrelse. Afviklingssekvensen for simulatoren er beskrevet i afsnit om simulation Formål Formålet med denne første test er at prøve at finde en balance imellem tid for indlæsning til 2D array og størrelsen af kort, for dermed at kunne vurderer hvilken detaljegrad der kan forventes. Desuden testes søgningen med BFS. Kan der indlæses og søges inden for rimelig tid? Størrelserne på kortet valgt til ca. 500 x 500, 1000 x 1000 og 1500 x 1500 for at se efter en lineær sammenhæng. Desuden er der kort på ca x 8000 og x for at finde en øvre grænse Konfiguration af Case Case 3 starter sin sekvens med at indlæse et kort, se afsnit om simulatoren for afviklingsvarianter. Ved indlæsning gennemløbes kortet pixel for pixel og hver pixel repræsenteres som et element (PointNode objekt) i et 2D byte array, der med koordinat fra kortet læses direkte over med sand for status som fri eller falsk for status som optaget. Der måles for tid på indlæsning og størrelse på datastruktur. Næste sekvens er søgning med BFS. Der er benyttet standard start og slut punkter for alle gennemløb Resultat Der er opdelt i indlæsning og søgnings sekvenser efter de to primære fokusområder. For hver af de 5 størrelser af kort er der lavet en måling på samme måde så resultatet er direkte sammenlignenligt. For indlæsning af de 3 mindste kort er både tiden og størrelsen acceptabel for den databehandling Kortstørrelse Indlæs tid Indlæst størrelse 514 x 513 0,6 sek 3 MB 1014 x ,4 sek 10 MB 1469 x sek 22 MB 8017 x ,4 min 77 MB x ,1 min 170 MB Tabel 4.7: Gennemsnit af 5 indlæsninger af 2D array repræsentation der må forventes på en moderne robot. For de 2 største kort kan tiden være en faktor, men størrelsen burde ikke være et problem. Søgningen i kortstørrelserne på ca x 8000 og x er ikke fuldført, da søgetiderne kommer langt over hvad der er anvendeligt i et scenarie som dette.

39 4.5. Case 4 29 Figur 4.3: Resultat af BFS søgning i 514 x 513 array med undersøgte noder og bedste rute. Kortstørrelse Søgetid bedste sti total søgesteps 514 x sek x ,2 min x ,11 min x 7995 * * * x * * * Tabel 4.8: Gennemsnit af 5 BFS søgninger for hver af de 5 kortstørrelser. * Søgning opgivet efter 3 timer. 4.5 Case 4 Brug A* på kort repræsenteret ved et 2D array. Der indlæses som i case 3, forskellige størrelser af kort, til en datastruktur af et 2D array. Der testes med A* algoritmen på hver kortstørrelse for at se forskelle imellem BFS og A*. Afviklingssekvensen for simulatoren er beskrevet i afsnit om simulation.

40 30 4. Cases Formål Formålet med denne Case er at testes søgningen med A* imod den søgning der er lavet med BFS i Case 3 og mod A* søgning i hægtet liste i Case Konfiguration af Case Case 3 starter sin sekvens med at indlæse et kort. Ved indlæsning gennemløbes kortet pixel for pixel og hver pixel repræsenteres i et 2D byte array, der for hvert koordinat fra kortet læses direkte over til et objekt (PointNode) der kender sin status som sand for fri eller falsk for optaget. Desuden beregner noden selv sin tilbagelagte afstand g(n) og sin afstand til mål h(n) og kan derved selv beregne sin f(n). Der er ved A* heuristik brugt Manhatten i 2 versioner, som i Case 2, der tæller g(n) ved at beregne værdier fra nodens X, Y til startnodens X, Y og i en version der tæller bedste rute via forældre tilbage til startnoden. Der måles for søgetid, længde på bedste rute og antal undersøgte noder i alt. Der er benyttet standard start og slut punkter for alle gennemløb Resultat For hver af de 5 størrelser af kort er der lavet en måling på samme måde som foregående Cases, så resultatet er direkte sammenlignenligt. Dog er der for denne Case som i Case 2 forsøgt med flere versioner af A*, med Manhatten heuristik. Først er der testet A* med g(n) baseret på koordinater og derefter en h(n) baseret på forældrene. For at kunne sammenligne på samme præmis er valgt at bruge Manhatten heuristik baseret på g(n) beregnet ud fra koordinater, for at kunne sammenligne resultat med Case 2. Kortstørrelse Søgetid Rute steps total søgesteps 514 x sek x ,8 min x ,3 min x 7995 * * * x * * * Tabel 4.9: Gennemsnit af 5 A* søgninger for hver af de 5 kortstørrelser, med g(n) baseret på koordinat beregning. * Søgning opgivet efter 3 timer. Kortstørrelse Søgetid Rute steps total søgesteps 514 x sek x ,5 min x ,4 min x 7995 * * * x * * * Tabel 4.10: Gennemsnit af 5 A* søgninger for hver af de 5 kortstørrelser, med g(n) bregnet ved forældre-listen. * Søgning opgivet efter 3 timer.

41 4.6. Konklusion på case Figur 4.4: Resultat af A* søgning i 514 x 513 kortet, med g(n) baseret på koordinater, med undersøgte noder og bedste rute. Der er for de 2 forskellige søgning er med A*, med Manhatten heuristik meget forskellige resultater, se figur 4.4 og 4.5. Dels er ruten anderledes og dels er søgetiden højere med afstand baseret på koordinat beregning. Der undersøges flere noder, men ruten der findes er ens i længde. Dette kan som i Case 2 skyldes at der med forældre metoden gives en anden retning ved bedste tilbagelagte rute end med koordinat beregningen, der ikke ændre retning ved samme f(n) værdier. 4.6 Konklusion på case Data indlæsning Indlæsningen af data er fra samme kilder for alle 4 ovennævnte Cases. For Case 1 og 2 er et billede indlæst til en hægtet liste og i Case 3 og 4 er det indlæst til et array. Der er ved brug af array en hurtigere indlæsningstid i forhold til en hægtet liste, ca. den halve tid og hukommelsesforbruget lavere, ca. 1/3. Dette kan til dels skyldes at noderne i et array er meget mere primitive end noderne i en hægtet liste, der skal indeholde meget mere information. Beregningen af hver node af arraytypen er mindre, da liste typen skal kende sine naboer. Arraystrukturen kan indlæse selv det største kort på ca x noder til ca. 170MB, hvilket ligner mere en størrelse pr. node der er brugbar. Størrelsesmessigt kan det håndteres af de fleste moderne robotter. Tiden til indlæsning af de største

42 32 4. Cases Figur 4.5: Resultat af A* søgning i 514 x 513 kortet, med g(n) baseret på forældrelisten, med undersøgte noder og bedste rute. kort på over 5 minutter kan til gengæld blive en hæmsko ved opdateringer. Der er ved indlæsning til de 2 forskellige datastrukturer konstateret en lille forskellighed i udfald på trods af samme kilde og samme kriterier for beregning af noder. Ved overgang mellem hvid og farvet område er der små forskelle i fortolkningen, hvilket giver forskellige yderpunkter for algoritmen at følge Søgning Hvor der for indlæsningen af data er tid at sparer ved en arraydatastruktur i forhold til datastruktur med hægtede lister, er det i rutesøgningen omvendt tidsperformance. Selve ruten er den samme for hver størrelse kort men tiden det tager at beregne en rutesøgning er højere end ved en datarepræsentation og især ved de større kort kommer det til udtryk. BFS søgningen er med samme antal steps, resultatmessigt ens for begge datastrukturer på trods af forskellige ruter, se tabel Grunden til at antallet af undersøgte noder i Case 3 er mindre end i Case 1 findes ved forskelle i hvor mange noder der er indlæst. Visuelt er Casene ens men der er ikke i Case 3 samme For A* er sammenligningen ved g(n) værdier beregnet ved koordinater. Dog er resultaterne af de 2 Cases forskellige. Dels finder de forskellige ruter og dels er der ikke som med BFS samme længde rute. Som det fremgår af tabel 4.12 finder Case 2 en længere rute som den bedste og dette kunne tyde på at der er forskel i datastrukturen, da algoritmen er den samme.

43 4.7. Case 5 33 Kortstørrelse algoritme Søgetid rute total søgesteps 514 x 513 case 1 0,3 sek x 513 case 3 1,19 min x 1011 case 1 1,7 sek x 1011 case 3 9,2 min x 1465 case 1 3,0 sek x 1465 case 3 34,11 min x 7995 case 1 * * 8017 x 7995 case 3 * * x case 1 * * x case 3 * * Tabel 4.11: Sammenligning af BFS søgning i hægtet liste i case 1 og array baseret kort i case 3. * kort ikke indlæst. Kortstørrelse algoritme Søgetid rute total søgesteps 514 x 513 case 2 0,3 sek x 513 case 4 17,8 sek x 1011 case 2 0,9 sek x 1011 case 4 3,1 min x 1465 case 2 2,8 sek x 1465 case 4 18,3 min Tabel 4.12: Sammenligning af A* søgning i hægtet liste i case 2 og array i case 4. Søgninger for kortstørrelser 8017 x 7995 og x er ikke gennemført. 4.7 Case 5 Der indlæses forskellige størrelser af kort, til en hægtet liste datastruktur fra en filstream i stedet for beregning af hvert pixel i et billede Formål Denne Case tager udgangspunkt i, at indlæsningen af data i Case 1 og 2 tager tid i forhold til søgetiden og kunne optimeres. Umiddelbart kunne det tænkes at være hurtigere at læse datastrukturen end at beregne den og derved kan der spares tid. Denne testcase sammenligner de 2 forskellige tilgange til dataopbevaring Konfiguration af case Der er forud for denne Case genereret 3 filer med hver af de 3 hægtede lister fra de første 3 test i ccase 1. De 3 hægtede lister er serialiseret til en tekstfil og denne Case undersøger indlæsningen. Der er valideret visuelt og ikke testet rutesøgning.

44 34 4. Cases Resultat og konklusion Filen der indlæses fra, streamer til den data objekt struktur der benyttes i Case 1 og 2. Bedømt på selve filernes størrelse er de i nærheden af hukommelsesforbruget indlæst i RAM se tabel Indlæsningen fra en tekstbaseret fil tager væsentligt længere tid end læsningen af en billedfil og beregningen af denne. Det må antages at være størrelsen der gør tekstfilen tung at behandle. Billedfilen Kortstørrelse Type indlæsning Tid Størrelse 514 x 513 case 1 1,1 sek 18 MB 514 x 513 case 5 20 sek 17,5 MB 1014 x 1011 case 1 5,6 sek 66 MB 1014 x 1011 case 5 1,6 min 55 MB 1469 x 1465 case 1 10,2 sek 121 MB 1469 x 1465 case 5 14,7 min 148 MB Tabel 4.13: Sammenligning af indlæsningstider fra henholdsvis en tekstfil og en billedfil. Der indlæses til en hægtet liste struktur. der både indlæses og beregnes er i formatet.png. Tekstfilen er ukomprimeret og skal ikke beregnes så hvis tekstfilen kunne komprimeres kunne der være tidsoptimering. Til sammenligning tager det OS miljøet 35 sek. at åbne tekstfilen på 148 MB, så en anden og komprimeret teknik til at gemme kan måske overvejes og her er billedkomprimering oplagt. I den kommende Cases 7 læses der direkte fra billedfilen, uden at der dannes datastruktur i en separat sekvens inden, så her vil det vises om en dataopbevaring på ned til få KB vil være mere effektiv for samme datasæt end ukomprimeret tekstfil. 4.8 Case 6 Der benyttes A*, på et kort med topologisk datarepræsentation Formål Formålet med denne Case er at teste den topologiske repræsentation af domænet. Dette giver en kraftig reduktion af antal noder og derved en hurtig eksekvering Konfiguration af case Det topologiske kort er lavet manuelt, hvor hver node definerer et trafikalt knudepunkt ( en gateway), altså et kryds eller et T-kryds. Nodernes placering scaleres til den størrelse kort der loades. Der er i kortet ikke afstande eller andre værdier på kanterne, så bedste rute er alene baseret på antal noder. Der benyttes A* til at søge efter bedste rute. Kortetene der vises er samme bitmap der indlæses i case 1-4, men her vises de som bitmap og loades ikke i en datastruktur. De er lagt som baggrund for at kunne orienterer sig og vælge nodekoordinater til test der giver mening. Det der indlæses som

45 4.8. Case 6 35 noder er manuelt oprettede noder. Der er testet med samme standard start og slut punkter som i de 5 foregående Cases Resultat Resultatet er en hurtig eksekvering og en kort liste med noder til den bedste rute. Der er kun sorteringen i listen der holder styr på rækkefølgen af noderne i stien. Hvorvidt en robot kan kører efter dette er op til konfigurationen af robotten, men beregningen er selv for det største kort hurtig og uden udfordring af hukommelsen. Figur 4.6: Resultat af A* søgning i 514 x 513 kortet med topologiske noder. Bedste rute og alle topologiske noder er markeret. Fordi hver node repræsenterer et punkt i et kryds kan en rute komme til at kører forbi noden med en margin, som robotten selv skal tage højde for. Søgetider er alle under 0,1 sek og ens da de søger i samme antal noder. Derfor er søgetider ikke listet i denne case. Størrelsen på brug af hukommelse er absolut i den lave ende og der er ingen indlæsnings eller søge -tider der ikke kan benyttes i en robot under operation.

46 36 4. Cases Kortstørrelse Indlæs tid Indlæst størrelse 514 x 513 0,01 sek 1,3 MB 1014 x ,04 sek 3 MB 1469 x ,4 sek 7 MB 8017 x ,5 sek 9 MB x ,7 sek 24 MB Tabel 4.14: Indlæsningstider og størrelse af topologisk kort. 4.9 Case 7 Der blandes den bedste fra Case 1-4 med Case 6, for en effektiv hybrid struktur, hvor der effektivt traverseres i henhold til et metrisk kort imellem de topologiske nodesteps Formål Der kombineres en topologisk strategi med en metrisk, for at få det bedste fra begge teknikker. Fra Case 6 fyldes mellemrummene mellem pejlepunkterne med den Case der antageligt er mest lovende Konfiguration af case Søgningen foregår af 2 sekvenser. Der indlæses data mens der søges efter bedste rute, men første søgning er i det topologiske kort. Derefter søges der metrisk for hver kant imellem noderne i den fundne topologiske rute. Der indlæses metrisk data efter Case 2 eksempel og dette sker også i en sekvens, hvor der søges bedste rute direkte i billedfilen Resultat Resultatet af en hybrid struktur med et overordnet topologisk kort og et lazy loaded metrisk kort virker hurtigt og effektivt. Visuelt viser Case 7 den samme rute som A* fandt i Case 2 og 4, dette dog uden søgesteps til sammenligning. Søgning af rute imellem hvert topologisk punkt er hurtigt og selv ved største kort med lange passager søges der relativt hurtigt. En rute med X koordinat fra 529 til og Y kordinat fra til 3549 på lidt over 1 minut er hurtigt set i forhold til søgning i Case 1-4. Både opdeling af søgning til en kant ad gangen og det at der søges i et datasæt der er størreksmessigt overskueligt (en billedfil som figur 4.7) gør søgning meget effektiv. Som det ses af figur 4.7 er samlingen af de ruterne på kanterne ikke optimal, da ruten på næstsidste node går i modsat retning for at nå noden og tilbage ad samme vej for at komme videre ad ruten. Hukommelsesforbruget er stort ved de største kortrepræsentationer og kunne antageligvis minimeres ved at benytte et seperat kort for hver kant.

47 4.10. Opsumering 37 Figur 4.7: Resultat af A* søgning i 514 x 513 kortet med hybrid datastruktur og lazy load af metriske kort for kanter. Kortstørrelse Indlæs tid Indlæst størrelse søgetid 514 x 513 0,02 sek 1,3 MB 0,4 sek 1014 x ,04 sek 3 MB 0, 4 sek 1469 x ,06 sek 7 MB 0,9 sek 8017 x ,3 sek 260 MB 29,4 sek x ,8 sek 450 MB 1,1 min Tabel 4.15: Indlæsningstider, størrelse og søgetid af hybrid kort Opsumering Der er for de første 4 test Cases en modsætning i at de størrelser af kort der indlæses relativt langsomt med en hægtet liste søger hurtigt og de kort der indlæses hurtigt til et array søger langsomt. Både A* og den teoretisk mindre effektive BFS bekræfter dette ved de størrelser af datasæt der bruges i de 4 første Cases. Manglen på en effektiv datastruktur minimerer forskellen på de 2 søgealgoritmer. I Case 7 søges der uden brug af en fuld indlæst datastruktur og her søges der hurtigt og uden hukommelsesbegrænsninger i selv store kort. Case 5 bekræfter at hukommelsesforbruget for datasæt og ikke formatet er begrænsningen for en hurtig rutesøgning. Den topologiske opdeling af mindre bidder af metriske kort giver en endnu mere effektiv og samtidig detaljeret søgning.