Analys av metoder för lokal rörelseplanering

Örebro universitet Örebro University

Institutionen för School of Science and Technology naturvetenskap och teknik SE-701 82 Örebro, Sweden

701 82 Örebro

Datateknik C, Examensarbete, 15 högskolepoäng

ANALYS AV METODER FÖR LOKAL

RÖRELSEPLANERING

Zozk Mohamed

Högskoleingenjör, Datateknik, 180 högskolepoäng Örebro vårterminen 2021

Examinator: Federico Pecora Handledare: Henrik Andreasson

Sammanfattning

Under senare år har vi med hjälp av robotar som använder rörelseplanering kunnat automatisera olika processer och uppgifter. Idag finns det väldigt få strategier för lokal rörelseplanering vid jämförelse med global rörelseplanering. Syftet med det här projektet har varit att analysera tre strategier för lokal rörelseplanering, dessa har varit Dynamic Window Approach (DWA), Elastic Band (Eband) och Timed Elastic Band (TEB).

I projektet har styrkor, svagheter, beteenden och förbättringsmöjligheter för respektive strategi studerats närmare genom att utföra olika simulerade tester. I testerna mätes tid för att nå mål, antal kollisioner och antalet gånger som målet nåddes. Under projektet användes en virtuell allriktad robot från ABB för att testa strategierna. Testerna genomfördes på ett så rättvist sätt som möjligt, där alla strategier fick samma antal försök och hade samma information om robotens begränsningar.

Resultatet visar att TEB är den snabbaste strategin, följt av DWA och sista Eband som var den långsammaste strategin. TEB var också den strategi som presterade bäst vid dynamiska hinder, däremot var den också den strategi som kolliderade mest i testerna, medan Eband kolliderade minst.

Nyckelord: rörelseplanering, lokal rörelseplanerare, dynamic window approach, dwa, elastic

Abstract

In recent years, we have been able to automate various processes and tasks with the help of robots that use motion planning. Today, there are very few strategies for local motion planning when compared to global motion planning. The purpose of this project has been to analyze three strategies for local motion planning, these have been Dynamic Window Approach (DWA), Elastic Band (Eband) and Timed Elastic Band (TEB).

In the project, strengths, weaknesses, behaviours and opportunities for improvement for each strategy have been studied in more detail by performing various simulated tests. The tests measure time to reach the goal, the number of collisions and the number of succeeding attempts. During the project, a virtual omni-directional robot from ABB was used to perform the tests. The tests were performed in as fair a way as possible, where all strategies got the same number of attempts and had the same information about the robot's limitations. The results show that TEB is the fastest strategy, followed by DWA and last Eband that was the slowest strategy. TEB was also the strategy that performed best in dynamic obstacles, however, it was also the strategy that collided most of the tests, while Eband collided the least.

Keywords: motion planning, local motion planner, dynamic window approach, dwa, elastic

Innehållsförteckning

1.5 RAPPORTENS STRUKTUR OCH UPPBYGGNAD ... 6

2 BAKGRUND ... 7

2.1 DEFINITIONER OCH TERMINOLOGIER ... 7

2.1.1 Rörelseplanering ... 7

2.1.2 Global och lokal rörelseplanering ... 7

2.1.3 Costmap ... 7

2.2 STRATEGIER ... 7

2.2.1 Dynamic Window Approach ... 7

2.2.2 Elastic Band ... 8

2.2.3 Timed Elastic Band ... 8

2.3 TEORETISK JÄMFÖRELSE ... 9

3 METODER OCH VERKTYG ... 10

3.1 METODER ... 10 3.1.1 Parametrar ... 10 3.1.2 Utvärdering ... 10 3.1.3 Tester ... 10 3.1.4 Global planerare ... 10 3.2 VERKTYG ... 10 3.2.1 Hårdvara ... 10 3.2.2 Mjukvara ... 11

3.2.3 Programmeringsspråk och programbibliotek ... 11

3.2.4 Plattform från ABB ... 11 3.3 ÖVRIGA RESURSER ... 12 4 SYSTEMARKITEKTUR ... 13 5 GENOMFÖRANDE ... 14 5.1 INSTALLERING ... 14 5.2 UTFORMNING AV TESTER ... 14 5.3 JUSTERING AV PARAMETRAR ... 14 5.4 GENOMFÖRANDE AV TESTER ... 15 6 RESULTAT ... 16 6.1 UTFÖRDA TESTER ... 16

6.2 RESULTAT FRÅN UTFÖRDA TESTER ... 18

6.2.1 Olika breda hinder ... 18

6.2.2 Trång korridor med hinder ... 19

6.2.3 Dynamiska hinder ... 20

6.2.4 Verklighetsbaserad miljö ... 20

6.3 UTFÖRDA FÄRDER... 20

6.3.1 3 meters brett hinder ... 21

7 DISKUSSION ... 23

7.1 UPPFYLLANDE AV PROJEKTETS KRAV ... 23

7.2 RESULTATETS BEGRÄNSNINGAR ... 23

7.3 STRATEGIERS FÖRBÄTTRINGSMÖJLIGHETER ... 24

7.4 SOCIALA OCH EKONOMISKA IMPLIKATIONER ... 24

7.5 PROJEKTETS UTVECKLINGSPOTENTIAL ... 25

7.6 REFLEKTION KRING EGET LÄRANDE ... 26

8 SLUTSATS ... 27

1

Inledning

Under de senare åren har teknik blivit allt mer avancerad där allt fler processer automatiseras med syfte att underlätta, spara tid och resurser. Automatiseringar är ett väldigt brett och stort område som kan handla om allt ifrån system för visualisering till navigering. Robotens utveckling har spelat en stor roll vid automatiseringar. Men för att robotar ska kunna agera autonomt behöver dessa ha möjlighet att navigera och koordinera sin rörelse genom olika miljöer självständigt [1]. För att en robot ska kunna navigera autonomt måste den utifrån den data den får in från sin omgivning analysera och kunna ta effektiva beslut för att nå fram till målet utan kollision. Detta kallas för rörelseplanering. Sedan utvecklingen av den första roboten Shakey [2] som använde rörelseplanering för att kunna gå igenom rum och undvika att kollidera med föremål, har nya och mer effektiva metoder utvecklats.

1.1 Syfte

Syftet med detta projekt är att undersöka och testa Dynamic Window Approach (DWA), Elastic Band (Eband) och Timed Elastic Band (TEB) med hänsyn till tid, antal kollisioner och hur ofta som målet nås. Testerna ska ha som mål att testa svagheter och styrkor hos respektive strategi samt beteende, men även testa hur strategierna presterar i en verklighetsbaserad miljö. Projektet har även till syfte att identifiera förbättringsmöjligheter hos dessa strategier.

Idag finns det väldigt få lokala planerare, speciellt i jämförelse med global rörelseplanerare. Detta projekt kan användas vid utveckling av nya lokala rörelseplanerare, men även som vägledning för företag vid val av planerare och implementering.

1.2 Problemformulering

Vilka är styrkorna respektive svagheterna för Dynamic Window Approach (DWA), Elastic Band (Eband) och Timed Elastic Band. Hur bra presterar dessa i olika tester när det gäller tid, kollision och måluppfyllelse.

1.3 Uppdragsgivare

Projektet är ett samarbete mellan Örebro Universitet och ABB. ABB är en svensk-schweizisk koncern med över 105 000 medarbetare i fler än 100 länder, varav 3 780 i Sverige utspridda på ungefär 25 orter där huvudkontoret är placerad i Västerås. ABB är en av världens största företag där man jobbar inom bland annat samhälle och industri. Företaget är indelat i fyra divisioner som arbetar inom el, robotik, motorer och automatisering av processer [3]. Detta projekt är intressant för ABB eftersom de är verksamma inom bland annat robotik där det ständigt studeras och utvecklas nya metoder för rörelseplanering. Med studien kan ABB effektivisera rörelseplanering för deras robotar och vidareutveckla nya tekniker. Projektet är ur den synpunkten viktigt, men också för vidare studier där nya strategier för rörelseplanering kan utvecklas.

1.4 Krav

Projektet ska undersöka minst tre strategier för lokal rörelseplanering som redan är implementerad i ROS. Positiva och negativa egenskaper hos strategierna ska lyftas fram. Strategierna ska simuleras och testas genom Gazebo och ROS med den plattformen som ABB ger tillgång till. Strategierna ska testas i både statiska och dynamiska miljöer. Tid, antal kollisioner och antalet lyckade försök ska mätas. Förbättringsmöjligheter hos strategierna ska undersökas och möjligtvis implementeras.

1.5 Rapportens struktur och uppbyggnad

Rapporten börjar med bakgrundsinformation där viktiga termer förklaras, men också klargör vad rörelseplanering, global och lokal rörelseplanering är för något. De lokala

rörelseplanerarna som ska undersökas i detta projekt förklaras även i sektion 2, hur dessa fungerar och jämförs teoretiskt med varandra. Metoder för hur strategiernas prestanda mäts och hur dessa ställts in redogörs i sektion 3. Under samma sektion förklaras även vilka verktyg och program som använts för att genomföra projektet. Sektion 4 redogör projektets alla delar på en abstrakt nivå och hur dessa har samverkat med varandra. Projektets

genomförande gås igenom i sektion 5 på en detaljerad nivå. Sektion 6 presenterar resultatet i projektet och i sektion 7 diskuteras resultatet och vad detta innebär för framtiden.

2

Bakgrund

2.1 Definitioner och terminologier

2.1.1 Rörelseplanering

Rörelseplanering är en viktig del i en robot eftersom det möjliggör en interaktion med den verkliga världen. En rörelse uppgift delas upp i mindre delar som sedan kan optimeras och uppfylla olika begränsningar som kan finnas. När en robot ska navigera i ett utrymme så krävs det inte bara att algoritmen kan hitta den kortaste färdplanen från start till mål, utan även undvika kollisioner med hinder och ta hänsyn till olika begränsningar som kan finnas på rörelsen. Begränsningar kan exempelvis handla om möjliga accelerationer eller hur skarpa svängar som kan utföras av roboten [4]. Rörelseplanering brukar delas in i global- och lokal rörelseplanering [5].

2.1.2 Global och lokal rörelseplanering

Global rörelseplanering kräver att hela ytan är känd och att miljön är statisk. En fullständig färdplan kan genereras för roboten, från start till mål utan att roboten behöver röra sig. Däremot brukar beräkningstiden för att hitta en färdplan vara mycket stor. Lokal

rörelseplanering kräver inte att hela ytan är känd, utan istället planeras färden parallellt med att roboten rör sig. Beräkningstiden brukar vara väldigt lite eftersom lokala planerare behöver en snabb responstid och körs mer ofta än den globala planeraren. Algoritmen använder endast data från sensorer som registrerar närliggande omgivning och uppdaterar data parallellt med rörelsen. Detta gör att lokal planering även kan användas i en statisk och dynamisk miljö, där den planerade färden kan justeras vid hinder eller vid tillfällen då robotens begränsningar överskrids [5].

Man brukar oftast kombinera global och lokal planare för att navigera en robot. Den globala planeraren användas för att ta fram en färdplan från start till mål. Denna färdplan kan ha missat vissa statiska och dynamiska hinder som kan finnas i den genererade rutten. Lokal rörelseplanering används för att följa och optimera rutten som den globala planeraren genererat och upptäckta dynamiska och statiska hinder längs den vägen [5].

2.1.3 Costmap

Costmap är en karta som innehåller information om hinder i världen. Oftast används två olika costmap, en global och en lokal. Den globala costmapen används för att lagra information om hinder i världen långsiktigt. Den används mest av den globala planeraren. Den lokala

costmapen används i syfte att lagra mer tillfällig information som är till nytta för den lokala planeraren. Information som lagras i costmap används i syfte att undvika kollision. För att uppdatera costmapen används information från robotens sensorer [5].

2.2 Strategier

2.2.1 Dynamic Window Approach

Lokala planeraren Dynamic Window Approach introducerades 1997 av Dieter Fox, Sebastian Thrun och Wolfram Burgard. Algoritmen använder ett dynamiskt fönster som är ett begränsat område där sökning sker, för varje iteration flyttas detta fönster. Fönstret innehåller

faser där den första fasen handlar om att minska sökutrymmet och den andra delen om optimering [6].

Under den första fasen börjar algoritmen med att först prova att producera unika cirkulära banor som är optimala för robotens lokala förhållanden inom det dynamiska fönstret. Sedan simuleras dessa banor för att se vad som händer om roboten följer dessa. Banor där roboten inte kan stanna innan det närmaste hindret reduceras bort. Sedan reduceras även banor bort som inte kan fullföljas inom en viss tid på grund av begränsad acceleration med hjälp av det dynamiska fönstret [6].

I den andra fasen av algoritmen så används en kostnadsfunktion för varje bana som är kvar efter den första fasen. Kostnadsfunktionen beräknar ett värde som baseras på den aktuella position och rotation för roboten, men även banans riktning mot målet, avstånd till närmaste hinder och den högsta linjära hastigheten för banan. Den banan med det högsta värdet från kostnadsfunktionen blir vald och proceduren upprepas från tidigare steg tills målet är nått [6].

2.2.2 Elastic Band

Elastic Band strategin presenterades för första gången 1993 av S. Quinlan och Oussama Khatib. Färdplanen från den globala planeraren ses som ett elastiskt band som kan omformas. Denna algoritm använder en serie av så kallade bubblor för att kunna upprätthålla en elastic band, en kollisionsfri färdplan. Bubblor används längst hela färdplanen i syfte att kontrollera att färdplanen är kollisionsfri där varje bubbla representerar lokala fria utrymmen. Roboten kan i en bubbla röra sig i alla riktningar och samtidigt vara garanterad att inte kollidera med objekt. För att färdplanen ska vara kollisionsfri så måste denna färdplan vara i bubblorna och inte utanför. Vid tillfällen då den genererade färdplanen befinner sig långt borta från hinder kan bubblorna ha större storlek och vara mindre i antal. Vid hinder nära vägen så krävs fler och mindre storlek av bubblor. Algoritmen består av två steg [7].

Först placeras ett visst antal bubblor längst färdplanen som den globala planeraren genererat. Sedan justeras antalet bubblor längst färdplanen för att minska beräkningstiden, men bubblor kan även läggas till för att täppa igen hål längst färdplanen där bubblor saknas [7].

I det andra steget så omformas färdplanen genom att försöka beräkna interna och externa krafter längst vägen. Detta görs genom att använda två tekniker som kallas för contraction force och repulsion force. Tekniken som kallas för contraction force används för att simulera spänningen i färdplanen och möjligtvis stretcha ut denna så att roboten har en chans att röra sig förbi hinder. Den andra tekniken repulsion force avlägsnar roboten från potentiella hinder. Dessa två tekniker gör det möjligt för elastic band strategin att hantera ändringar i miljön och eventuellt omforma färdplanen [7].

2.2.3 Timed Elastic Band

Strategin Timed Elastic Band presenterades 2012 av Christoph Rösmann, Wendelin Feiten, Thomas Wösch, Frank Hoffmann och Torsten Bertram. Den är en vidareutveckling på Elastic Band strategin som optimerar hela färdplanen. Timed Elastic Band däremot optimerar den lokala banan genom att sätta lokala mål. Den försöker att minimera exekveringstiden för banor och nå målet snabbare samtidigt som hänsyn tas till begränsningar som kan finnas. Den globala planen består av vägpunkter som omvandlas till en bana. Algoritmen tar hänsyn till vägpunkter från den globala planeraren genom att vägpunkter attraherar banan och hinder

stöter bort denna [8].

Algoritmen arbetar med så kallade robotposer, där varje robotpose innehåller information om robotens placering och i vilken riktning den är vänd mot. Den lokala planen som skapas av strategin innehåller en sekvens av robotposer. Mellan dessa robotposer finns det krav för den maximala tillåtna tiden för roboten att röra sig från en robotpose till en annan påföljande pose, dessa kallas för tidsskillnader. Strategin definieras som en följd av robotposer och

tidsskillnader [8].

Timed elastic band försöker optimera robotposer och tidsskillnader parallellt med rörelse genom en funktion som tar hänsyn till begränsad hastighet, acceleration, avstånd till hinder, kortaste och snabbaste väg [8].

2.3 Teoretisk jämförelse

När strategierna omformar färdplanen vid optimering eller hinder så omformas endast en lokal del av DWA och TEB medan Eband omformar hela färdplanen. DWA och TEB

optimerar även färdplanen baserad på tid och inte bara på längd som Eband gör. Eband tar inte heller hänsyn till begränsningar som kan finnas för den aktuella roboten som DWA och TEB gör. Dessa strategier skiljer sig också åt när det gäller vilka typer av banor som produceras. DWA producerar endast cirkulära banor och de andra två producerar alla typer av banor. TEB strategin kan användas av alla typer av robotar, medan DWA och Eband endast kan användas av allriktad robotar som möjliggör körning i alla riktningar och differentialhjul robot som använder två hjul på vardera sida för rörelse. DWA är den strategi som kräver minst processorkraft av datorn, TEB däremot är den strategi som kräver mest [1]. Skillnader och likheter mellan strategierna som nämnts ovan presenteras i Tabell 1.

Tabell 1 Sammanställning över likheter och skillnader mellan strategier i detta projekt

Dynamic Window

Approach (DWA) Elastic Band (Eband) Timed Elastic Band (TEB) Omformning av

färdplan Lokal del Hela delen Lokal del

Tidsoptimering Ja Nej Ja

Tar hänsyn till robotens begränsningar

Ja Nej Ja

Typer av banor Endast cirkulära Alla typer Alla typer

Robottyper som stöds

Allriktad och

differentialhjul robot

Allriktad och

3

Metoder och verktyg

3.1 Metoder

För att kunna testa strategierna så utformades ett antal olika tester genom en simulerad värld med hinder och ett givet mål med exakta koordinater. Alla tre strategier genomgår dessa tester med samma antal försök i varje test. I alla tester används en tom global costmap för att

minimera den globala planerarens roll.

3.1.1 Parametrar

Innan testerna kan genomföras så testas parametrarna för de olika strategierna i syfte att säkerställa en rättvis jämförelse. Alla strategier måste ha samma information om robotens begränsningar, exempelvis hastighet, acceleration med mera Detta för att resultatet annars kan bli orättvist och påverka hur strategin normalt beter sig. Under pågående testning av

strategierna ska inga parametrar justeras eftersom det annars kan gynna en viss strategi och vinkla resultatet.

3.1.2 Utvärdering

För att kunna utvärdera och jämföra hur strategierna presterat i testerna så observeras tiden från det att målet skickas till rörelseplaneraren tills en bekräftelse på att målet nåtts. Tiden mäts i sekunder. Dessutom mäts även antal kollisioner med hinder och hur många gånger som målet nås. Under simulering observeras rörelseplaneraren för att kunna identifiera beteende mönster. Dessa mått används vid jämförelsen och för att mäta strategiernas prestanda.

3.1.3 Tester

Idén bakom testerna är att störa färdplanen från den globala planeraren genom att placera hinder av olika storlekar längst vägen och observera hur pass bra strategierna tar sig runt dessa. Ett annat test ska konstrueras för att testa hur bra strategierna hanterar trånga utrymmen. Det ska även finnas ett test för dynamiska hinder som ska testa strategiernas betande och prestanda vid dynamiska hinder. Till sist ska test konstrueras för realistiska utrymmen där roboten kan verka inom.

3.1.4 Global planerare

I projektet används navfn för att generera en global färdplan genom att använda den globala costmapen. Navigeringsfunktionen som används är Dijkstras algoritm. Vid tillfällen då den lokala planeraren upptäcker stora hinder så tillkallas den globala planeraren för att få en ny global färdplan.

3.2 Verktyg

3.2.1 Hårdvara

För att kunna utföra simuleringar och tester användes en dator som har 8 gigabyte ram och använder en fyrkärnig processor som kallas för Intel® Core™ i5-8250U. Datorn använder 64 bitars versionen av operativsystemet Windows 10 Pro version 2004.

3.2.2 Mjukvara

I projektet så användes ett flertal olika mjukvaror för att möjliggöra projektet. Ett av dessa är Hyper-V [9] som gör det möjligt att kunna köra flera olika operativsystem på samma dator genom att skapa virtuella maskiner. Den virtuella datorn som skapades använde Ubuntu 20.04 som operativsystem.

För att kunna skapa och simulera tester så användes simulatorn Gazebo [10] version 11.5. Med detta verktyg kan världar skapas som kan innehålla rum och objekt där tester kan äga rum. Genom verktyget Rviz [11] kan visualisering av vad roboten ser, tänker och gör skapas. Verktyget gör det även möjligt att interagera med roboten. Rviz används i största syfte att observera lokal och global färdplan samt hur roboten reagerar på olika typer av hinder.

3.2.3 Programmeringsspråk och programbibliotek

Vid implementering av strategier användes ramverket ROS [12] för att skriva programvara för en robot. Ramverket erbjuder flera färdiga moduler för robotens olika delar och gör det

möjligt att justera dessa genom öppen källkod. I detta projekt användes ROS Noetic Ninjemyst som är byggd speciellt för Ubuntu 20.04. För att bygga egna paket eller justera existerande paket användes C++ som är ett objektorienterat programmeringsspråk.

3.2.4 Plattform från ABB

Roboten från ABB består av fyra styrhjul som kan styras helt oberoende från varandra och vinklas i alla riktningar. Detta gör att roboten har en stor frihet vid rörelse jämfört med många andra robotar, däremot kan det finns begränsningar för exempelvis acceleration och hastighet beroende på vinklar för hjulen. Roboten är av typen allriktad och är därför lämplig att

användas av alla tre strategierna i projektet, DWA, Eband och TEB. En allriktad robot som nämndes i inledningen är en robot som möjliggör körning i alla riktningar. Roboten är även utrustad med två sensorer, en fram och en på baksidan som möjliggör ett 360 graders synfält. Figur 1 visar hur robot modellen från ABB ser ut i Gazebo.

3.3 Övriga resurser

I projektet gav ABB även tillträde till ett antal filer som bland annat innehöll en virtuell allriktad robot som var implementerad i Gazebo (Figur 1) och konfigurerad med ROS. Dessutom fanns det även instruktioner för användning, parameterfiler, filer för att starta olika lokala och globala planerare samt start filer för övriga system hos roboten. Parameterfiler för TEB var helt konfigurerad medan DWA och Eband delvis var konfigurerad. Det materiel som ABB gav tillträde till får inte delas med utomstående.

Förutom materialet från ABB användes världar och modeller från Github. Dessa användes för att kunna redigera världar och använda färdiga modeller för att bygga ihop egna tester. Utöver detta så laddades det även ner en tom och färdig costmap från Github.

4

Systemarkitektur

I projektet används ROS för att undersöka olika lokala rörelseplanerare. I ROS så används navigation stack [13] för att navigera en robot och undvika hinder. Målet med navigation stack är att producera kommandon till roboten så att den når det mål som den givits på ett säkert sätt. Navigation stack får in konstant data från roboten den styr och baserar sina beslut på denna data. I Figur 2 visas en förenklad illustration över navigation stack, dess noder och kopplingar mellan dessa.

Navigation stack får data från roboten hela tiden som innehåller data från sensorer,

lokalisering med mera. Den globala planeraren behöver en karta över kända hinder. Den egna noden som skapades i projektet ansvarar för att sända mål till navigation stack från

användaren, utöver detta så mäter den även tidsdifferensen från det att ett mål skickas tills bekräftelse fås om att målet nåtts. Utifrån den datan som navigation stack får in och med hjälp av rörelseplanering så produceras i instruktioner för roboten.

Utöver kommunikation med navigation stacks så anges världar där tester genomförs i simulatorn Gazebo. Den robot modell som ABB gav tillgång till används också i Gazebo. Gazebo och ROS kommunicerar med varandra för att ROS ska kunna uppdatera roboten och få indata av sensorer från världen som roboten befinner sig i. ROS och Rviz kommunicerar med varandra för att Rviz ska kunna visualisera vad som händer i navigation stack.

5

Genomförande

5.1 Installering

Genom Hyper-V skapades en virtuell dator med operativsystemet Ubuntu 20.04, 4 kärnig processor, 3500 megabyte ram och en hårddisk med 128 gigabyte maximala lagringsutrymme. På den virtuella datorn så installerades ROS Noetic och Gazebo 11.5. En catkin workspace mapp skapades genom ROS, där modifikation, byggning och paket kan skapas. De filer som ABB gav tillträde till placerades i denna workspace i src mappen. De lokala rörelseplanerarna DWA, TEB och Eband laddades ner från ROS genom Github.

Catkin workspacet byggdes ihop genom catkin_make. Under uppbyggnaden påpekade programmet att vissa paket saknades i workspacet. För varje paket som saknades så laddades dessa ner genom ROS och workspacet byggdes om på nytt tills att projektet kunde byggas ihop utan problem.

I början var det tänkt att installera ROS och Gazebo direkt på Windowsdatorn, men efter problem med att få ROS att fungera så beslutades det att istället använda Ubuntu. Detta operativsystem valdes även för att det finns mycket mer resurser på nätet om ROS på Ubuntu än Windows.

5.2 Utformning av tester

Världarna som testerna skulle utföras på skapades genom Gazebo. Rummen byggdes genom Build Editor i Gazebo där väggars placeringar och storlek angavs i ett grafiskt gränssnitt. Vissa objekt lades till och ändrades i världarna genom att direkt ändra i XML filen för

världen. Vid det verklighetsbaserade testet laddades ett färdigt bibliotek av olika modeller och världar ner genom Github. Dessa användes vid det verklighetsbaserade testet.

5.3 Justering av parametrar

Innan tester kan genomföras måste strategierna konfigureras. För att kunna avgöra vilka värden som de olika parametrarna för strategierna ska ha så utgicks det från både default värdena i ROS, värden från ABB och värden från en rapport som var skriven av Cybulski, Wegierska och Granosik [1]. Efter att parametrar justeras så simuleras roboten för att upptäcka eventuella problem som kan finnas på grund av felaktiga inställda parametrar. För att minimera rotationer och problem med positionering runt mål så behövdes parametrar för hur stor avvikelse från målet som kunde tolereras justeras. För stora värden hade lett till väldigt varierande lösningar från strategierna, medan ett för lite värde lett till problem med positionering. Under simulering och utförande av tester så hade alla strategier samma värden i parametrarna för hastighet, acceleration och avvikelse från mål. Dessa värden presenteras i Tabell 2.

Tabell 2 Parametrar för strategierna

Parameter Värde Beskrivning

xy_goal_tolerance 0,2 Maximala tillåtna avvikelse från målet i meter

yaw_goal_tolerance 0,2 Maximala tillåtna orienterings avvikelse till målet i _radianer max_vel_x 9 Maximal linjära hastigheten för roboten i meter/sekunder

max_vel_theta 9 Den maximala vinkelhastigheten för roboten i radianer/sekunder

acc_lim 5 Linjär acceleration begränsning i meter/ sekunder2

acc lim theta 5 Vinkelacceleration begränsning i meter/ sekunder2

Det övervägdes även att mäta längden på hur långt som roboten färdats från start till mål, eftersom detta gör det möjligt att mäta hur bra strategierna använder robotens

hastighetsbegränsningar. Med detta togs inte med vid utförande av testerna på grund av komplicerad implementering och tidsbrist.

5.4 Genomförande av tester

Innan testerna kunde genomföras utvecklades ett ROS paket som utgick ifrån ett existerande paket kallat simple_navigation_goals. Paketet ändrades genom C++ kod och roscpp där tidmätning implementerades men även iostream för att få x och y koordinater från användare. Målet från användaren skickas till navigation stack. Paketet mäter tiden det tar från att målet skickas tills en bekräftelse fås att målet har nåtts.

För att minska den globala planerarens roll så användes en tom global costmap i alla testerna. Denna laddades ner från Github och upplösningen ändrades för att göra denna större. Även startposition i mappen för roboten ändrades beroende på vilket test som genomfördes. Testet genomfördes genom att roboten startade i samma position och fick samma mål i alla testerna genom det paket som skapades tidigare. Under simulering observerades beteendet i Rviz och eventuella kollisioner eller misslyckanden. Tiden som det egna anpassade paketet skriver ut i konsolen antecknades ner i en tabell tillsammans med om roboten nått målet och om kollision inträffat. För att ändra vilken strategi som skulle navigera så modifierades launch filen till move base där färdiga launch filer för strategierna från ABB användes. För att ändra vilket test som skulle genomföras så klistras koden in från den värld som skulle genomföras till den aktuella world filen i Gazebo mappen.

Vid tester med dynamiska hinder så startades planeraren manuellt genom att observera rörelsen för hindren. När dessa dynamiska hinder hamnade på en förutbestämd position så startades planeraren. Detta för att alla strategier ska ha lika stora förutsättningar och få en likvärdig chans i testet.

6

Resultat

6.1 Utförda tester

Under projektet har varje strategi genomgått totalt 6 olika tester där varje test upprepats minst 10 gånger. I alla tester hade roboten samma startposition (0,0,0). I de första tre testerna så ska roboten röra sig 15 meter framåt, ungefär 11,5 meter framför roboten finns en vägg som sensorerna inte kan registrera vid start för att inte den lokala planeraren ska kunna reagera på denna innan roboten flyttat sig. I testerna hade väggen en bredd på 1, 3 respektive 5 meter och var centrerade längst y axeln. I Figur 3 visas testerna i a, b och c där den svarta fyrkanten representerar robotens startposition och den streckade kvadraten målet. Syftet med dessa tester var att undersöka hur bra strategierna kan hantera olika stora hinder längst den planerade färdplanen.

Figur 3 Illustration över test med 1, 3 och 5 meters bredd vägg

Det fjärde testet består av en lång och smal korridor som var 3 meter bredd och 30 meter lång. I mitten av korridoren placerades 7 lådor som var statiska längst varannan vägg med 1,5 meters avstånd. Roboten fick instruktioner om att köra 28 meter framåt. I Figur 4 illustreras testet, där den svarta kvadraten visar startposition för roboten och den streckade målet. De grå fyrkanterna längst väggen representerar lådorna i testet. Syftet med testet var att se hur bra strategierna klarar av trånga gångar och hinder.

Det femte testet bestod av två boxar som rörde sig fram och tillbaka i 4 meters bredd och 12 respektive 16,5 meter ifrån robotens startposition, centrerad runt y axeln. En fram och tillbaka rörelse för boxarna tog 7,5 sekunder att genomföra. Figur 5 visar illustration av testet där den svarta kvadraten representerar robotens startposition och den streckade kvadraten robotens mål. De grå kvadraterna representerar de dynamiska hindrets startposition och den streckade kvadraten till vilket position lådan rör sig. Lådan rör sig tillbaka efter att ha nått det streckade kvadraten. Denna rörelse upprepas i oändlighet. Detta test har till syfte att testa hur bra strategierna kan hantera dynamiska hinder och undvika att kollidera med dessa.

Figur 5 Illustration över test med dynamiska hinder

I det sista testet så skapades en verklighetsbaserad miljö där roboten kan verka. Miljön är en kontors liknande med bord och stolar. I kontorsmiljön placerades även två människor som gick runt i kontoret. Roboten fick som mål att ta sig till en position som låg bredvid ett skrivbord och vägg. I Figur 6 presenteras en illustration av miljön, samt start och målposition för roboten. Syftet med testet var att undersöka hur strategierna verkar i en verklighetsbaserad miljö med många olika typer av hinder där människor kan finnas.

Figur 6 Illustration över verklighetsbaserad test

6.2 Resultat från utförda tester

De lokala planerarna Dynamic Window Approach (DWA), Elastic Band (Eband) och Timed Elastic Band (TEB) genomgick ungefär 10 försök per test. Resultatet från testerna presenteras i tabellerna 2, 3, 4, 5, 6, 7 och 8. Alla tabeller har likadana kolumner men med olika värden från testerna för respektive strategi. Värdena som presenteras i tabellerna är medelvärdet av tiderna (Medel), kortaste tiden (Min), den längsta tiden (Max), standardavvikelsen (SD), förekommande av kollision och lyckade försök. Medelvärdet, minsta tiden, maxtiden och standardavvikelsen anges i sekunder medan kollision och lyckade försök anges i procent.

6.2.1 Olika breda hinder

Under de första tre testerna som innehöll 1, 3 och 5 meters bredda väggar så hade TEB ibland problem med att ta sig runt kanten på väggen då den tenderar att optimera färden för mycket så att roboten körde alldeles för nära kanterna och kolliderade. Detta var ett väldigt stort problem för TEB med 3 meters bredd vägg då den kolliderade med kanten av väggen väldigt ofta. Eband hade inte detta problem.

I tabell 3, 4 och 5 kan man se att TEB var mycket snabbare på att köra förbi hinder vid

jämförelse med DWA och Eband. När DWA och Eband upptäcker väggen och ska planera om färdplanen så behöver dessa tid att planera om. De kan först välja att köra om på ena sidan och köra mot denna sida men kan sen välja att byta sida och köra om därifrån. Detta var särskilt ett stort problem för Eband som gjorde att det tog längre tid att nå målet på grund av att en sida till sida rörelse gjordes. TEB är mer bestämd vilken sida om väggen som den ska köra om, vilket förklarar den snabbare tiden.

Tabell 3 Resultat över test med 1 meter bredd vägg

Strategi Medel Min Max SD Kollision Lyckades

DWA 31,958 30,951 38,194 2,091 0 % 100 %

Eband 33,365 32,914 33,953 0,312 0 % 100 %

TEB 19,330 18,501 22,081 1,015 0 % 100 %

Tabell 4 Resultat över test med 3 meter bredd vägg

Strategi Medel Min Max SD Kollision Lyckades

DWA 34,321 32,825 36,061 1,015 0 % 100 %

Eband 36,550 35,853 38,650 1,073 0 % 90,91 %

TEB 23,726 21,073 27,781 2,185 54,55 % 100 %

Tabell 5 Resultat över test med 5 meter bredd vägg

Strategi Medel Min Max SD Kollision Lyckades

DWA 40,095 37,936 53,569 4,497 9,09 % 100 %

Eband 62,264 51,191 78,201 6,813 0 % 100 %

TEB 31,429 27,474 47,058 5,633 9,09 % 100 %

6.2.2 Trång korridor med hinder

Vid test med den långa korridoren och boxar placerade längst väggen så presterade även TEB bäst i testet då den var snabbast utan att fastna eller kollidera. DWA körde genom hindren mestadels i en rak bana utan att köra slalom, men med en lägre hastighet än TEB. Eband körde i en väldigt låg hastighet när roboten närmade sig hindren och när det blev trångt för roboten att köra förbi. Detta resulterade i att det tog mycket längre tid för strategin att nå målet.

Tabell 6 Resultat över test med en lång korridor och 7 boxar

Strategi Medel Min Max SD Kollision Lyckades

DWA 54,366 53,923 54,758 0,238 0 % 100 %

Eband 104,62 101,55 107,33 1,896 0 % 100 %

6.2.3 Dynamiska hinder

I det dynamiska testet presterade TEB bäst både när det gäller tid och kollisioner. TEB körde roboten oftast genom det dynamiska hindret istället för att köra runt som DWA och Eband tenderar att göra. Detta resulterade i att färden blev både kortare med avseende på längd men också tid då TEB använde en högre hastighet än de andra två strategierna gjorde.

När dessa strategier ska köra förbi det dynamiska hindret görs detta i en låg hastighet som leder till att det dynamiska hindret som undveks istället kommer tillbaka mot roboten och kolliderar. Vid tillfällen då Eband inte klarar att nå målet beror detta på att roboten tidigare kolliderat med hinder.

Tabell 7 Resultat över test med dynamiska lådor

Strategi Medel Min Max SD Kollision Lyckades

DWA 67,649 61,718 81,769 5,381 45, 45 % 100 %

Eband 78,418 51,007 120,301 18,073 72,73 % 90,91 %

TEB 34,347 25,713 43,202 4,871 36,36 % 100 %

6.2.4 Verklighetsbaserad miljö

Under det verklighetsbaserade testet hade inga strategier problem med att ta sig förbi

människor som rörde sig eller andra hinder då inga kollisioner skede. Som tidigare tester visat var även TEB i detta test snabbast och presterade bättre än de andra strategier. DWA och Eband presterade väldigt likvärdigt i detta test, men DWA har en större standardavvikelse vid jämförelse med Eband. Vid detta test körde även DWA och Eband långsammare än TEB trots att de följde samma färdplan. Eband hade problem med vid ett tillfälle att ta sig till målet under simulering. Detta berodde på att en simulerad människa kom för nära roboten.

Tabell 8 Resultat över test i en verklighetsbaserad miljö

Strategi Medel Min Max SD Kollision Lyckades

DWA 32,908 27,648 39,770 3,617 0 % 100 %

Eband 34,546 33,900 36,353 0,860 0 % 90,91 %

TEB 15,047 14,351 16,000 0,410 0 % 100 %

6.3 Utförda färder

Vid testning av olika lokala planerare så resulterade detta i att roboten färdades annorlunda beroende på vilken lokal rörelseplanerare som användes.

6.3.1 3 meters brett hinder

För testet med den 3 meters bredda väggen skilde sig planerarna åt hur nära väggen som roboten närmade sig och hur hastigheten använts under färden. I Figur 7 visas robotens positioner tills den når målet för testet med den 3 meters bredda väggen i Rviz för alla strategier i projektet. Positionering har tagits med samma intervall för alla strategier. Avståndet mellan robotens positioner avslöjar hur hastigheten för roboten har sett ut under färden. Långa avstånd mellan robotens positioner tyder på att en hög hastighet använts medan korta avstånd att en låg hastighet använts.

Genom Figur 7 kan man se i b) att Eband hade den jämnaste hastigheten och höll största avståndet till hindret. DWA a) hade också en jämn hastighet, men närmade sig lite mer hindret än vad Eband gjorde. TEB c) hade den mest ojämna hastigheten av alla strategier där den använde en hög hastighet i början och sedan när roboten närmade sig hindret så saktade TEB ner hastigheten, men sen så ökades denna efter hindret. TEB var också den strategi som närmade sig hindret mest, detta förklarar varför kollision i Tabell 4 var så mycket i jämförelse med de andra strategierna.

Figur 7 Bilder från Rviz med robotens positioner tills den når mål med 3 meters brett hinder

6.3.2 Lång korridor med boxar

När det gällde testet med den långa korridoren och 7 boxar som var placerade i mitten av korridoren, så skiljde sig strategierna från varandra främst när det gäller hastigheten vid boxarna. I Figur 8 visas robotens position tills den når målet för testet med den långa korridoren och 7 boxarna i Rviz för alla strategier i projektet. Positionering har tagits med samma intervall för alla strategier. Avståndet mellan robotens positioner avslöjar hur hastigheten för roboten har sett ut under färden. Långa avstånd mellan robotens positioner

tyder på att en hög hastighet använts medan korta avstånd att en låg hastighet använts. I Figur 8 kan man se att när roboten använde TEB c) så hade den en hög hastighet vid jämförelse med de andra strategierna, men vid start och slut samt vid boxarna så minskas hastigheten något. DWA a) hade en av de jämnaste hastigheterna, det är bara vid start och slut som hastigheten minskas något. Däremot så kör både DWA och TEB väldigt nära boxarna. Eband b) kör med en väldigt låg hastighet vid boxarna samtidigt håller den roboten i mitten av boxarna.

7

Diskussion

7.1 Uppfyllande av projektets krav

Innan projektet påbörjades så sattes ett par krav upp som skulle vara uppfyllt vid projektets slut. Ett av kraven var att undersöka minst tre lokala planerare, i projektet undersöktes Dynamic Window Approach (DWA), Elastic Band (Eband) och Timed Elastic Band. Dessa jämfördes teoretiskt och praktiskt med varandra. Den praktiska jämförelsen genomfördes genom tester som skapades i Gazebo, ROS och den robot modell som ABB gav tillträde till. Tester utformades som innehöll både dynamiska och statistiska hinder. Under testning observerades flera parametrar utifrån kraven som ställdes innan.

Kravet på att implementera förbättringar för strategierna har inte uppfyllts. Detta beror på flera anledningar, bland annat på att tiden inte räckte till då testning och konfigurering av parametrar för strategierna tog längre tid än planerad. Att modifiera strategierna och förbättra dessa kräver mer kunskaper och djupare förståelse för hur strategierna är implementerade i ROS. På grund av tiden fanns denna möjlighet inte, men det är något som förhoppningsvis kan göras i framtiden.

I början var det tänkt att byta ut operativsystemet på datorn från Windows till Ubuntu för att kunna använda Gazebo och ROS. Men genom Hyper-V så undveks detta. Men det

introducerades nya problem med Gazebo, främst när det gäller rendering då denna var väldigt sakta med låg uppdatering vilket försvårade observation av testerna. Dessutom fanns det vissa funktioner i Gazebo som inte gick att använda. Exempelvis var det inte möjligt att generera grafer för hur hastigheten såg ut för strategierna. För att undvika dessa problem så hade Ubuntu behövts installeras direkt på datorn istället för Hyper-V, eftersom Hyper-V inte utnyttjar datorns prestanda fullt ut.

7.2 Resultatets begränsningar

Det resultat som erhållits från detta projekt har några begränsningar och felfaktorer som man bör ta hänsyn till. Resultatet är starkt beroende av vilka värden som parametrarna för

strategierna antar. Under projektet har många tester fått göras om eftersom nya

konfigureringar för strategierna hittats som gjort att det presterat avsevärt bättre. Vilket öppnar möjlighet för strategierna att prestera ännu bättre än vad det gjort i detta projekt. I alla tester så var TEB snabbare på att nå målet än vad DWA och Eband var, men med andra konfigureringar kan DWA och Eband prestera bättre än TEB. I projektet försöktes alla tester genomföras på ett så rättvis sätt som möjligt, men det hade behövts göras en djupare analys av konfigurering av strategierna för ännu rättvisare resultat.

Vid testet så observerades om strategierna kolliderade med hinder under testet. Dessa observationer gjordes manuellt genom Rviz, på grund av den mänskliga faktorn kan vissa kollisioner ha missats eller att kollision uppfattats men det inte skett. Det hade varit bättre om kollisioner räknades automatiskt i programmet. Detta försöktes implementeras, men på grund av tekniska problem så beslutades det istället att göras manuellt.

När det dynamiska testet skulle genomföras så startades planeraren manuellt när de dynamiska hindren befann sig på en förutbestämd position. Detta kan ha lett till en viss varians för när planerarna startats och kan ha gett en fördel under vissa tester. Här hade det varit bättre med att testerna startades automatiskt för att få ett ännu mer rättvist resultat.

En annan begränsning av resultatet är att projektet gjordes i en simulerad plattform och inte i en fysisk. Resultatet från simulerad och fysiska tester kan skilja sig väldigt mycket, vilket den bland annat gjorde i en studie som genomförde av Cybulski, Wegierska och Granosik [1]. Men att implementera strategierna i en fysisk plattform innebär nya problem uppstår och med den tid som fanns så hade detta troligtvis inte varit möjligt att genomföra.

7.3 Strategiers förbättringsmöjligheter

Under testning har flera problem med strategierna upptäckts. När det kommer till TEB så presterade denna bra i alla tester när det kommer till tid, men när det gäller kollisioner så fanns det en del problem. Det största problemet med TEB var att den närmade sig alldeles för mycket kanten på hindren. Detta beroende på den optimering som gjordes, vilket resulterade i att kollision skede. En förbättring på detta problem hade varit för strategin att hålla ett större avstånd till hinder som den passerar och vara mer försiktig vid optimering runt dessa. Det enklaste sättet att lösa detta är att justera parameterfilerna för strategin. Men utöver detta kan även bubblor användas vid robotposer som är nära hinder likt Eband. TEB har också problem med dynamiska hinder, då den tenderar att köra igenom dessa med hög fart. Det hade varit bättre om TEB gjorde som DWA och Eband då dessa saktar ner farten och försöker åka runt det dynamiska hindret. Detta kan göras genom att sakta ner och observera åt vilket håll som det dynamiska hindret rör sig mot och köra runt det motsatta hållet eller i vissa fall köra runt hela det dynamiska hindret.

Vid testning av DWA upptäcktes två problem, köra förbi stora hinder och undvika kollision med dynamiska hinder. Vid testning med 5 meter breda väggen så tenderar DWA att närma sig väggen väldigt mycket innan denna försökte reagera på hindret. För att undvika detta problem borde DWA försöka planera längre fram och reagera tidigare. Ett annat alternativ hade varit för DWA att backa back om den skulle fastna och låta den globala panneraren generera en ny färdplan som ett sista försök. Problem med dynamiska hinder var främst att DWA körde sakta när den försökte svänga förbi hindren. Hade DWA istället kört snabbare vid svängar eller försökt optimera vid exempelvis tillfällen då hindren rör sig mot ett håll, så kunde algoritmen kört förbi från motsatt håll. Detta hade resulterat i både färre kollisioner och att målet nåtts snabbare.

Eband hade liknande problem som DWA när det kom till dynamiska hinder, men var i övriga tester väldigt bra på att undvika kollisioner. Ett problem som DWA inte hade var att denna vid testet med den långa korridoren och 7 boxarna körde väldigt sakta, vilket resulterade i att denna fick ett sämre resultat än de övriga strategierna. Men under det testet höll Eband bäst avstånd till boxarna. En lösning för detta hade varit att konfigurera bubblorna till att tillåta en högre hastighet vid trånga utrymmen än vad som gjordes i testet, men tillåta ett mindre avstånd till hinder.

7.4 Sociala och ekonomiska implikationer

Det pågår idag många studier om lokal rörelseplanering där fokus ligger väldigt mycket på att försöka minimera färdtiden och optimera färden. Detta projekt likt många andra studier har inte studerat närmare hur dessa strategier interagerar med människor. I framtiden kommer förmodligen människor och robotar behöva arbeta tillsammans och interagera med varandra.

Det kan därför ställas krav på rörelser som inte bara rör kortaste kollisionsfria färder, men också färder som utförs på ett säkert sätt för människor runtomkring. Det kan handla om att fart sänks och säkert avstånd hålls till människor som gör att människor känner sig trygga med robotar i sin miljö. Exempelvis att roboten använder hastigheter runt människor som gör det möjligt för den att stanna om något oväntat händer. Människor kan känna en viss

otrygghet med robotar som gör snabba, häftiga och plötsliga rörelser. I vårt fall med den allriktad roboten så kan 90 graders svängar genomförs. Men dessa kan vara olämpliga vid tillfällen då människor befinner sig i närheten på grund av att det kan upplevas som en

oväntad rörelse eftersom roboten inte på förhand indikerar sin avsikt. Med detta projekt har vi konstaterat svagheter och styrkor hos strategierna, men vissa svagheter när det gäller

prestanda kan vara en styrka när det kommer till att interagera med människor. Exempelvis Ebands låga hastighet vid hinder.

Människor som befinner vid en robot med autonom navigering måste på förhand veta robotens avsikt. Detta kan handla om att roboten vänder sig mot den riktning som denna ska köra mot och på så sätt indirekt indikerar sin avsikt för sin omgivning, precis som vi

människor rör oss på eller kör bil. Roboten måste vid interaktion med människor röra sig på ett liknande sätt som vi människor är vana vid, men även förstå indirekta sätt som människor kommunicerar, exempelvis om man tittar på ett område så kan detta indikera på att man har för avsikt att gå mot detta håll eller markera detta med kroppsrörelse.

Vissa miljöer kan ha ett flertal robotar och dessa kan inte navigera helt själva utan måste koordinera sin rörelse tillsammans med andra robotar. Detta är viktigt för att både spara tid och vara effektiv, men också för att samarbete mellan robotar underlättar navigering. Det kan exempelvis handla om att en robot väntar tills en annan robot passerat en trång dörr och att den andra roboten på förhand fått information om att roboten inväntar denna. Vilket skulle betyda att kommunikation med närliggande robotar kan behövas implementeras i den lokala rörelseplaneraren eller i en annan del.

Då allt fler processer automatiseras och börjar övergå till att drivas av elektricitet så måste även strategierna ta hänsyn till detta. För att undvika brist på elektricitet i världen så måste alla maskiner och processer agera sparsamt. Rörelseplanering är inget undantag. Dagens rörelseplanerare tar inte hänsyn till elförbrukning och det finns väldigt lite studier om detta. I framtiden kan elektricitet vara en begränsad resurs. Viktigt att påpeka är framtidens drivmedel för robotar inte nödvändigtvis behöver vara just el, det kan dyka upp andra drivmedel som exempelvis vätgas. Batterier idag kräver väldigt stora koldioxidutsläpp för att tillverkas och dess kapacitet blir sämre med tiden och kan behövas bytas ut. Därför är det inte säkert att mobila robotar kommer använda batterier för att lagra energi i framtiden. Alternativa medel kan komma. Men det är viktigt att använda dessa resurser på ett sparsamt sätt. Strategierna kan spara på energi genom bland annat försöka hålla en konstant hastighet, inte gör häftiga rörelser som accelerera eller bromsa i onödan.

7.5 Projektets utvecklingspotential

Detta projekt är långt ifrån färdigt och det finns många intressanta områden som bör

undersökas. Som nämnts tidigare har resultatet av strategiernas prestanda varit starkt beroende av konfigurering av parametrarna. Därför hade det behövts en djupare analys av

konfigureringar av dessa parametrar med en metod som tas fram för detta ändamål. Projektet kan även utvecklas genom att försöka minimera felfaktorer i testet, genom att automatisera

testerna. Men även ta med fler parametrar i jämförelsen som minnesåtgång, längden på den utförda färden eller energiförbrukning. På detta sätt kan man få ett mer tillförlitligt och rättvist resultat. Slutsatser från resultatet hade också kunnat göras mer säkert om fler tester hade genomförts. Det hade även varit intressant att implementera förbättringar som föreslogs tidigare i rapporten för strategierna. Men även undersöka hybridlösningar som kombinerar flera strategier. De förbättrade strategierna kan sedan jämföras med varandra och ursprungliga strategier för att se hur pass mycket resultatet påverkas. Projektet kan även utvecklas

ytterligare genom att analysera och jämföra fler strategier. Det har nyligen utvecklats en ny lokal rörelseplanerare som kallas för Model Predictive Control (MPC) som hade varit intressant att ha med i jämförelsen. Nästa steg är att utföra samma tester i detta projekt fast i verkligheten. Genom detta kan slutsatser göras genom både simulerad och

verklighetsbaserade tester.

7.6 Reflektion kring eget lärande

Under projektets gång har kunskaper erhållits inom området rörelseplanering. Där relevanta metoder för lokal rörelseplanering studerats närmare, hur dessa fungerar och tanken bakom dessa algoritmer. Kunskaper har också uppnåtts om likheter och skillnader mellan dessa algoritmer, men även problem som dessa har och eventuella lösningar. Kunskaper inom interaktion mellan lokal rörelseplanering och övriga delar i en robot har också erhållits. Vid testning av olika strategier har kunskaper inom ROS och Gazebo uppnåtts. Bland annat vilka delar som finns i ROS och kopplingar mellan dessa, hur projekt och egna noder skapas samt hur dessa byggs ihop. Men även kunskaper om hur egna modeller och världar skapas i Gazebo och kopplingen till ROS har erhållits.

Genom projektet har teoretiska kunskaper erhållits främst genom att söka information via Google, IEEE och ROS egen webbplats. Vetenskapliga artiklar har fått sorteras baserade på relevans för projektet och lämplig information från dessa har tagits med i projektet.

Vid en vidareutveckling av projektet behövs djupare kunskaper inom ROS och hur olika lokala planerare är implementerad för att kunna implementera egna förbättringar. Det hade även varit intressant att studera fler lokala planerare och testa hur dessa presterar i projektets tester. För att implementera och testa strategierna på en fysisk plattform hade även kunskaper behövts för hur ROS implementeras för en verklig robot.

8

Slutsats

Vid jämförelse mellan de tre lokala rörelseplanerare DWA, Eband och TEB i testerna så har olika resultat observerats. Enligt resultatet är TEB den snabbaste strategin för att nå målet, följt av DWA och Eband. Men det är också den strategi som har störst problem med kollision vid hinder. Eband är den strategi som kolliderar minst och håller störst avstånd till hinder, speciellt vid trånga utrymmen. Eband var också den strategi som höll den jämnaste

hastigheten i testet. Men resultatet påvisade också att Eband var den långsammaste strategin på att nå målet. Vid dynamiska hinder presterade TEB bäst, detta beror främst på TEBs snabba rörelser då de andra två strategierna rörde sig långsammare.

Detta projekt har stor utvecklingspotential med en framtid framför oss där fler processer automatiseras och kräver rörelseplanering. Rörelseplanering kommer förmodligen bli mer vanligt i våra vardagliga liv i framtiden. Frågor som rör hur dessa planerare ska samverka med människor på bästa sätt och samtidigt köra på ett miljövänligt och sparsamt sätt måste studeras vidare.

9

Referenser

[1] B. Cybulski, A. Wegierska och G. Granosik, ”Accuracy comparison of navigation local planners on ROS-based mobile robot,” i 2019 12th International Workshop on Robot

Motion and Control (RoMoCo), Poznan, IEEE, 2019, pp. 104-111.

[2] C. David, ”Remembering Shakey, the First Intelligent Robot,” The New Stack, 5 Mars 2017. [Online]. Available: https://thenewstack.io/remembering-shakey-first-intelligent-robot/. [Använd 17 April 2021].

[3] ABB Ltd, ABB, [Online]. Available: https://new.abb.com/se. [Använd 18 April 2021]. [4] Michigan Robotics, ”Motion Planning,” University of Michigan, [Online]. Available:

https://robotics.umich.edu/research/focus-areas/motion-planning/. [Använd 17 April 2021].

[5] P. Marin-Plaza, A. Noureldin, A. Hussein, D. Martin och A. d. l. Escalera, ”Global and Local Path Planning Study in a ROS-Based Research Platform for Autonomous Vehicles,” Journal of Advanced Transportation, vol. 2018, p. 1–10, 2018.

[6] D. Fox, . S. Thrun och . W. Burgard, ”The dynamic window approach to collision avoidance,” IEEE Robotics Automation Magazine, vol. 4, nr 1, pp. 23-33, 1997. [7] O. Khatib och S. Quinlan, ”Elastic bands: connecting path planning and control,” i

Proceedings IEEE International Conference on Robotics and Automation, vol. 2,

Atlanta, IEEE, 1993, pp. 802-807.

[8] C. Roesmann, W. Feiten, T. Woesch, F. Hoffmann och B. Torsten, ”Trajectory modification considering dynamic constraints of autonomous robots,” i ROBOTIK

2012; 7th German Conference on Robotics, Munich, VDE VERLAG GmbH, 2012, pp.

1-6.

[9] ”Introduction to Hyper-V on Windows 10,” Microsoft, 26 Juni 2018. [Online].

Available: https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/about/. [Använd 20 Maj 2021].

[10] ”Why Gazebo?,” Gazebo, [Online]. Available: http://gazebosim.org/. [Använd 20 Maj 2021].

[11] W. Woodall, ”rviz,” ROS.org, 16 Maj 2018. [Online]. Available: wiki.ros.org/rviz. [Använd 20 Maj 2021].

[12] ”About ROS,” ROS, [Online]. Available: ros.org/about-ros/. [Använd 16 Maj 2021]. [13] ”navigation,” ROS.org, 14 September 2020. [Online]. Available: