Implementation av automatisk kranspetsstyrning för slyklippningsverktyg

28 

Full text

(1)

Örebro universitet Örebro University

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

701 82 Örebro

Examensarbete, 15 högskolepoäng

Implementation av automatisk kranspetsstyrning

för slyklippningsverktyg

Alexander Hoey

Maskiningenjörsprogrammet, 180 högskolepoäng Örebro vårterminen 2020

Examinator: Sören Hilmerby

(2)

Sammanfattning

Att klippa sly är en uppgift som behöver uträttas på plats där det växer, vilket oftast är ute i skogen. Skogen är för en maskin sällan en väldefinierad miljö och förhållanden som arbetet ska uträttas i förändras konstant. Att automatisera arbete som ska uträttas i svårkontrollerad miljö innebär många utmaningar, moment som för en människa är triviala är ofta inte möjliga för en maskin som arbetar under föränderliga omständigheter. Det här arbetet undersöker vilka typer av verktyg som kranarm och mjukvara som kan användas för att lösa den typen av problem samt ett förslag till en praktisk lösning på problemet med slyklippning med hjälp av dessa verktyg. Projektet avslutades då lösningsförslaget fortfarande är i prototypstadium och är inte ämnat för industri utan behöver vidare förfining innan lösningen kan tillämpas i praktiken.

(3)

Abstract

Cutting brush wood is a task that needs to be performed where it grows, which is usually in a forest. The forest is an environment that is difficult to map for a machine and the environment the task is to be performed in is constantly changing. To automate a task that is to be

performed in such environment comes with a range of challenges, tasks that are trivial for a human being may not be possible for a machine that is working inside a shifting environment. This thesis is looking at what type of tools such as jib and software may be used to solve these types of problems and will also present a proposed practical solution for brush wood cutting using these tools. The projects cut-off was at a prototype state and is not meant for industrial application but will need some further refinement before it is applied practically.

(4)

Förord

När jag tog mig an det här projektet så hade jag aldrig kunnat ana att den bas av kunskap som jag skulle samla på mig bestod av fler frågor än jag har kunnat hitta svar på. Kanske är det här varför robotik, som ändå har en förhållandevis lång historia, fortfarande med dagens

datorkraft och breda forskning fortfarande har många olösta problem. Det har varit spännande att se vilka problem som existerar och metoderna som tillämpas för att lösa dessa. Många gånger fick jag intrycket att de som utvecklar metoderna bara gör det för att de själva tycker att det är kul. För den som är ny inför akademiskt arbete kan detta säkert vara frustrerande, det var det varje fall för min del då jag kämpade för att hitta något rigoröst att förlita mina

slutsatser på.

De som ska ha tack; Olle Gelin på Skogforsk som gav mig äran att ta mig an den här uppgiften och mina handledare på Örebro Universitet, Jens Ekengren och Todor Stoyanov. Speciellt vill jag tacka Jens för den tid han tog utöver sin arbetstid att hjälpa till och att han rekommenderade mig att ta mig an det här arbetet. Todor ska ha särskilt tack för utöver grundläggande vägledning inom ROS och allmän robotik på kort varsel hoppade in för att hjälpa mig klara av även mer triviala problem med kompilering av kod eller liknande problem.

(5)

Innehållsförteckning

INLEDNING ... 1 1.1 Företaget ... 1 1.2 Projektet ... 1 BAKGRUND... 3 2.1 Problemet ... 3

2.2 Vad har företaget gjort tidigare ... 3

2.3 Vad har andra gjort tidigare ... 3

2.3.1 Manipulatordesign för att skörda frukt och grönsaker ... 3

2.3.2 ROS för att integrera alla delmoment i en process ... 3

2.3.3 MoveIt för att planera komplicerade rörelser... 4

2.4 Beskrivning av teknikområdet ... 4

2.5 Teori ... 4

2.5.1 Kinematik och inverterad kinematik ... 4

2.5.2 ROS ... 6

2.5.3 Rörelseplanering med MoveIt ... 7

2.5.4 Algortimer för rörelseplanering ... 8

METOD ... 10

3.1 Metoder för genomförande ... 10

3.2 Förstudie ... 11

3.3 ROS ... 11

3.4 Strukturering av problemet i mjukvara ... 11

3.5 Hantering av rörelseplanering ... 12

RESULTAT ... 13

4.1 Modellering av den fysiska miljön ... 13

4.2 Hantering av arbetslistor ... 13

4.3 Den resulterande rörelsen ... 16

4.4 Innehållet i ROS-paketet ... 17

DISKUSSION ... 18

5.1 Värdering av resultat ... 18

5.1.1 Mekanisk optimering ... 18

5.1.2 Tillämpning av biblioteket ... 18

5.1.3 Hur MoveIt används och hur det ska användas ... 18

5.1.4 Implementation på andra kranar... 18

5.2 Fortsatt arbete ... 19

5.2.1 Modellering av terräng och hinder ... 19

5.2.2 Optimering av arbetskön ... 19

5.2.3 Utföra en riskanalys ... 19

5.2.4 Klipphöjd... 19

5.2.5 Angreppsvinkel ... 19

(6)

REFERENSER ... 21

BILAGOR

(7)

Inledning

1.1 Företaget

Skogforsk arbetar med forskning inom skogsbruk som “spänner över hela skogsbrukets värdekedja, från ett mikroskopiskt pollen hela vägen till industrin”, enligt deras egna ord. Huvudkontoret ligger i Uppsala och där största delen av forskningsverksamheten bedrivs. Det finns även utposter i Sävar utanför Umeå och Ekebo utanför Svalöv, se karta i figur 1 och 2. I Umeå bedrivs tillämpad forskning på skogsbruk. I Ekebo bedrivs ett omfattande

förädlingsarbete för att förse Sydsvenska skogsbruket med odlingsmaterial.

Figur 1. Skogforsks huvudkontor samt två utposter Bildkälla: Skogforsk.se

Skogforsk har ca 120 anställda varav ett 80-tal är forskare. Nettoomsättningen under år 2019 var drygt 165 Mkr.

Stora delar av projekten drivs av efterfrågan från exempelvis EU. [1] 1.2 Projektet

Projektets syfte var att ta fram ett system som självständigt tar fram en rörelseplan på en robotarm samt ta fram en metod som beskriver hur systemet ska implementeras på en utifrån given robotarm. Eftersom robotarmar kommer i många olika utföranden behöver en metod för rörelseplanering på en godtycklig arm tas fram och utvärderas.

Rörelseplaneraren behöver kunna ta hänsyn till saker som självkollisioner och externa hinder dessutom behöver den kunna utvärdera om den efterfrågade rörelsen är möjlig eller inte. Det främsta kravet på projektet var att leveransen skulle baseras på ROS som plattform

Filialen i Sävar

Huvudkontor i Uppsala

(8)
(9)

Bakgrund

2.1 Problemet

En robotarm som sitter monterad på ett fordon ska klara av att självständigt förflytta sin manipulator från sitt nu-läge till ett, utifrån givet, ändläge med hänsyn till eventuella hinder som kan försvåra rörelsen.

För att en robotarm ska kunna navigera från en bestämd position till en annan given position är det sällan så enkelt att det räcker med att röra på en led. Oftast behöver flera olika rörelser från flera olika leder kombineras för att detta ska uppnås. Om ett hinder dyker upp som inte får vidröras av robotarmen blir det väldigt mycket mer komplicerat att ta fram en lösning på rörelsen.

För en människa som direkt kontrollerar robotarmen eller kranen är det absolut möjligt att hitta en lösning för rörelsen och realisera den, men det är mentalt krävande att direkt

kontrollera aktuatorer på en robotarm. Därför finns det många fördelar med att automatisera rörelsen på robotarmen.

Projektet som beskrivs är en förstudie inför att förenkla eller automatisera kranspetsrörelsen hos ett fordon avsett för att klippa sly. Idag existerar flera olika system som är avsedda för att lösa problemen som uppstår när en robotarm ska navigera bland hinder. Men dessa system är oftast väldigt generella och tar inte automatiskt hänsyn till saker som mekaniska

förutsättningar för robotarmen och kan därför inte direkt appliceras på denna typ av problem. 2.2 Vad har företaget gjort tidigare

Innan kranspetsstyrning implementerats har operatörer av olika kranar fått manövrera kranen genom att manipulera varje enskild led. Detta är det traditionella sättet att styra en kran. Det har visat sig att det tar längre tid att lära sig att operera en kran på det traditionella sättet än om man tillämpar kranspetsstyrning. Det har också visat sig vara en större mental belastning för operatören [2].

2.3 Vad har andra gjort tidigare

2.3.1 Manipulatordesign för att skörda frukt och grönsaker

Den kraftigt varierande miljön utomhus ställer stora krav på hur en manipulator ska designas [3]. fallet där syftet var att skörda paprika visade det sig att nio frihetsgrader var mest effektivt [4].

Som en del av EU-projektet CROPS [5] gjordes försök att ta fram en robot som självständigt kan plocka frukt. Man utgick från en traditionell industrimanipulator med sex kinematiska frihetsgrader. För att utöka arbetsrummet för manipulatorn förlängdes kinematiken med en prismatisk led i manipulatorns bas som möjliggjorde rörelse för hela manipulatorn i vertikalt led [3].

2.3.2 ROS för att integrera alla delmoment i en process

I en rapport som presenterades på konferensen 2017 First IEEE International Conference on

(10)

implementeras som en kontroller i ROS. Utifrån en semantisk specifikation av uppgiften bryts detta automatiskt ned till moment som kan skapa en bevisbart korrekt kontroller och som är mer rimlig för ROS att hantera. [6]

2.3.3 MoveIt för att planera komplicerade rörelser

Vid rörelser som involverar att en robotarm ska navigera i en miljö med fysiska hinder såsom andra objekt eller egna delar användes i flera olika försök det externa ROS-baserade

biblioteket MoveIt för att planera en kollisionsfri rörelse inom ett givet rum.

I ovan nämnt exempel användes MoveIt för att planera hur en robotarm ska röra sig för att kunna plocka upp och släppa föremål med hänsyn till omgivningen, sin egen geometri och objektet som skulle plockas upp [6].

Ett annat team använde MoveIt för att planera mer omfattande uppgifter där en mobil robotarm självständigt ska planera en rörelse på ett oorganiserat industrigolv. Rörelsen

involverar självständig planering av väg och självständig planering av rörelsen på robotarmen. [7]

2.4 Beskrivning av teknikområdet

Området som avhandlas är robotik. Robotik är ett väldigt brett ämne som kan innebära allt från automatisering av en modul i produktionslinje till att ta fram en humanoid maskin som rör sig och pratar som en människa. Den här rapporten avhandlar hur automatisering av en rörelse av en ospecificerad från en position till en annan med avseende på hinder och självkollision, i en odefinierad miljö.

Ett krav för att implementera projektet är att ROS (Robot Operating System) ska användas. Detta ställer krav på att kunskap omkring det systemet och flera av dess moduler måste finnas. För att bygga egna moduler inom ROS är det också nödvändigt att ha viss kännedom om programmering i C++.

2.5 Teori

I den här delen presenteras en del fundamental teori för robotik. Först hur kinematik och koordinatsystem beskrivs och hanteras. Denna kunskap är nödvändig för att det ska vara möjligt att orientera sig bland verktygen som ROS erbjuder, sedan en kort genomgång om hur ROS är strukturerat och sist en översikt om hur rörelseplaneraren som används fungerar.

2.5.1 Kinematik och inverterad kinematik

Kinematik är läran om hur saker rör sig. Inom robotik handlar det ofta om långa kedjor av aktuatorer som rör sig och då används kinematik för att bestämma var en punkt i kedjan befinner sig efter en operation [8, Forward Kinematics]. När man löser kinematikproblem är det ofta en pose som eftersöks. En pose beskriver en position och en orientering och

representeras ofta med två stycken kvarternioner. En kvarternion är en position i en

fyrdimensionell rymd som representeras av fyra tal, detta än förlängning av komplexa tal som är en position i tvådimensionell rymd. I robotiksammanhanget representeras de nästan alltid av en vektor med fyra rader. I figur 2 ser vi en enkel robotarm med två roterande leder och två länkar. Origo noteras med {0}. För att lösa ut posen på spetsen {E} används ekvation 1.

(11)

𝜉𝐸(𝑞) = ℛ𝑧(𝑞1) ⨁ 𝒯𝑥(𝑎1) ⨁ ℛ𝑧(𝑞2) ⨁ 𝒯𝑥(𝑎2) (1)

𝜉𝐸(𝑞) innebär att koordinatsystemet {E}’s position och orientering i det globala

koordinatsystemet beskrivs som en funktion av ledernas tillståndsvektor, q. Om {E} med avseende på {B} eftersöks noteras det istället genom att skriva 𝐵𝜉

𝐸(𝑞) och modellera

ekvationen därefter.

𝑧(𝑞) innebär en rotation av leden q kring z-axeln. Axelns koordinatsystem är lokal till leden, I det här fallet innebär det att ℛ𝑧(𝑞1) beskriver en rotationsled vars rotationsaxel är placerad i det globala koordinatsystemets origo och är orienterad längs den globala z-axeln.

Rotationssteget ℛ𝑧(𝑞1) vrider det lokala koordinatssystemet pekar länken a x-axel längs med länken som går till leden 𝑞2.

𝒯𝑥(𝑎) innebär en translation längs med x-axeln för staget a. I det här fallet är stagen stela och därför är detta en konstant.

Operationen ⨁ innebär att vi skapar vektorkompositioner mellan det som står på vänster och höger sida om operatören. Operationen är inte kommutativ.

Ekvation 1 relaterar till det globala koordinatsystemet och därför skrivs inte {0} med. Posen 𝜉𝐸(𝑞) är ett kvartnionpar där den ena kvarternionen representerar positionen för {E}

och den andra orienteringen för {E}.

Figur 2. En enkel robotarm med två roterande leder med origo markerat med {0} och lokala koordinatsystem märkta i rött. Ändeffektorns koordinatsystem, position och orientering ges av {E}. Inverterad kinematik är när en målposition och orientering är given men aktuatortillståndet som krävs är okänt. Den här typen av problem är svårare att lösa eftersom många

aktuatorsystem är överaktuerade. Detta innebär att det ofta finns oändligt många lösningar som tillfredsställer målets position och orientering. I figur 3 syns två möjliga lösningar till målpunkten markerade som streckade linjer. Om en tredje roterande länk fästs på armens spets innebär det att en stor mängd av punkterna som är inom räckhåll för roboten har

(12)

oändligt många lösningar om krav på orientering utelämnas. Ytterligare en länk ger en oändlig lösningsmängd även om krav på orientering ställs. Den matematiska notationen för inverterad kinematik läggs ut i ekvation 2.

𝑞 = 𝒦−1(𝜉) (2)

𝜉 är den sökta posen, exempelvis {E} från figur 3 och q är ledernas tillstånd i systemet. Enligt Peter Corke [8, Inverse Kinematics] finns det två sätt att lösa ut q. Det första sättet är ett analytiskt angreppssätt som ger en exakt lösning. Detta sätt blir dock besvärligare att arbeta med när flera leder läggs till och roboten blir mer och mer överaktuerad, det vill säga att fler leder än minsta möjliga antal som krävs för att hitta en lösning existerar i systemet. För ett överaktuerat system kan det existera flera lösningar för en specifik pose. För vissa system existerar ingen exakt lösning. Det andra angreppssättet är numeriskt och approximativt, vilket innebär att man iterativt testar olika möjliga lösningar tills en godtagbar lösning hittats. Detta är väldigt beräkningsintensivt och kräver i princip alltid datorstöd. [8]

Figur 3. Samma robotarm som i figur 2 med två möjliga lösningar till målet visualiserade.

2.5.2 ROS

ROS, Robot Operating System är grunden som projektet bygger på och allt som avhandlas kommer att vara beroende av kompatibilitet med ROS. ROS är framtaget för att kringå problemen som kan uppstå vid återanvändning av mjukvara för robotar, som krav på kunskap om hela stacken i robotens drivsystem [9].

Utvecklingen av ROS påbörjades under år 2007 på Stanford University och har sedan dess kontinuerligt utvecklats [10]. Hela projektet är i öppen källkod.

Systemet bygger på noder som samtliga arbetar självständigt men kan kommunicera med varandra. Kommunikation förs genom topics. Noder som kommunicerar gör det genom att publicera ett meddelande på en topic som andra noder som ligger på samma ROS-kärna kan

(13)

abonnera på. En topic måste i förväg formateras för att kunna bära den önskade datatypen. Dessa noder kan länkas till en robotkontroll och på sätt styra över en verklig robot. För simuleringar används istället en virtuell kontroll.

För att själv bygga ett system baserat på noder behövs kunskaper om programmering inom C++ eller Python.

Alla komponenter i ROS är indelade i paket som är formaterade på ett sådant sätt att de lämpligen kan läggas upp på en git och enkelt klonas ned till ett arbetsutrymme. Dessa paket behöver uppfylla tre villkor:

1. Alla filer måste ligga i en egen mapp med samma namn som paketet.

2. En .xml-fil som innehåller metainformation om paketets innehåll och vad som behövs för att kunna köra och kompilera innehållet.

3. En CMakeLists.txt-fil som beskriver hur paketet ska länkas och kompileras. För en mer detaljerad beskrivning hänvisas läsaren till [11]

2.5.3 Rörelseplanering med MoveIt

Rörelseplanering är centralt för att roboten ska kunna arbeta i en svårkontrollerad miljö. Syftet med en rörelseplanerare är att hitta en väg som roboten rör sig i utan att kollidera med omgivning eller sig själv. Rörelseplaneraren som används i det här projektet använder en slumpmässigt iterativ metod.

För rörelseplanering av robotar används verktyget MoveIt. MoveIt är ett ramverk byggt för ROS som erbjuder kraftfulla verktyg som kinematiklösare och rörelseplanerare. Detta ramverk är centralt för att implementera ett system som självständigt kan planera en rörelse med hänsyn till hinder och självkollision.

MoveIt tar en modell av en given robot och delar upp alla leder med associerad geometri och skapar en abstraktion av roboten som MoveIt lättare kan hantera. Där ingår kollisionsmatriser som gör det möjligt att skapa en rörelseplan där roboten inte krockar med sig själv eller annan extern geometri, minst en move group (rörelsegrupp) som är en lokal samling av leder och associerad geometri, inte nödvändigtvis hela roboten, som rörelseplaner kan associeras med och appliceras på. Precis som i ROS behövs kunskaper inom programmering för att hantera gränssnittet för MoveIt.

För att använda MoveIt behövs en robotmodell med en associerad MoveIt-konfiguration. Denna konfiguration skapas med hjälp av ett verktyg som följer med MoveIt. Förkravet är att det finns en fil som innehåller information om roboten såsom geometri och leder, en så kallad URDF eller SRDF-fil.

Specifikationer av mål kan ges till MoveIt på flera olika sätt. De enklaste sätten är att en specifik position för spetsen önskas alternativt en specifik orientering. Dessa två metoder går dock ej att kombineras och kommer vid körning av genererad rörelseplan att vid specificerad position ge en slumpmässig orientering och vid specificerad orientering kommer en

(14)

slumpmässig position av ges. För att bestämma både position och orientering kan en pose, som innehåller information om orientering och position, specificeras som mål. I samtliga av dessa fall krävs det en invers kinematik-lösning. Ett annat sätt att specificera mål på är att specificera inställningen för samtliga leder. Detta kan vara lämpligare att tillämpa om ingen specifik position eller orientering på armen är nödvändig men tillståndet som övriga armen befinner sig i är av vikt.

Om ytterligare yttre hinder behöver läggas till finns det tillgång till planning_scene

planneringsscen) som är en representation av den fysiska miljön som roboten befinner sig i. Där kan primitiv geometri läggas till som kollisionsobjekt och är något som rörelseplaneraren undviker kollisioner med när rörelseplan för roboten tas fram.

2.5.4 Algortimer för rörelseplanering

MoveIt erbjuder flera olika algoritmer för rörelseplanering. Det här projektet använder en variant av en RRT-algoritm. RRT står för Rapid exploration of Random Trees och innebär att algoritmen med ett givet mål och en given robot iterativt och slumpvis skapar ett ”träd”, som är ett slags graf, med ett stort antal grenar som har sin rot i robotens utgångsläge. Trädet växer ut tills en lösning har hittats eller ett stoppvilkor uppfylls, vilket brukar vara att maximal tid har passerat utan att en giltig rörelseplan har hittats.

Trädet innehåller flera slumpmässigt utvalda konfigurationer av roboten som har itererats fram och där inga konfigurationer medför någon kollision med yttre hinder eller sig själv för roboten, se figur 4. Sedan väljs en lämplig väg ut från trädets rot till målet som garanterar att roboten inte krockar. Den här typen av algoritm har visat sig vara väldigt effektiv när den tillämpas i praktiken.

En förbättring av RRT är RRT* som innebär att när en lösning är funnen kopplas lämpliga noder om och vägen slätas ut en aning för att optimera kostnaden för rörelseplanen, exempel i figur 5. [11]

(15)

Figur 4. Ett fiktivt träd där endast grenarna som leder till en lösning är synliga. Startläget i blått och tolererat mål i den lila kvadraten. Det svarta området är hinder. Det övriga området

representerar en konfiguration som inte medför någon kollision.

Figur 5 Trädet från figur 4 efter att noderna har kopplats om och slätats ut.

(16)

Metod

I det här kapitlet avhandlas metodiken för projektet. Första delen beskriver hur projektet planerades innan verktygen som tillämpas vid implementationen var kända och hur

tillvägagångssättet för att ta hitta dessa gick till. En stor del av tiden lades ner på att ta hitta lämpliga verktyg och utforska dessa med avseende på hur vad de begränsas av, vilka verktyg de erbjuder samt hur de kan implementeras.

3.1 Metoder för genomförande

Uppgiften behandlas som en förstudie och metodiken som valdes är därmed generaliserad för att göra att en förstudie som ett självständigt projekt. I stora drag delas förstudiemodellen in i fyra steg. [12]

• Problemanalys och effektmål. • Nulägesbeskrivning.

• Behovsanalys. • Lösningsförslag.

För att reda ut vad som krävs för att genomföra just detta projekt används artiklar som genomfört liknande projekt samt undersökning av problemet som ska avhandlas i den här rapporten. Detta kan delas upp i några enklare delmål:

• Ta fram en avgränsning för vilken typ av fysisk utrustning som krävs.

I det här fallet innebär det mer specifikt en beskrivning av vilket antal och vilka typer av kinematiska frihetsgrader robotarmen eller kranen som ska användas kommer att behöva utan att vara specifik.

• Undersök vilka verktyg som är lämpligast för att manipulera robotarmen. • Ta fram ett gränssnitt mellan operatören och roboten.

Utifrån förstudiemodellen och delmålen kan en WBS, som syns i figur 6, konstrueras som sedan ligger till grund för projektets genomförande.

(17)

Figur 6. Work Breakdown Structure för projektet.

Vad som är viktigast är att leveransen utgår från ROS och därför ska inte verktyg som inte är kompatibla med ROS användas i leveransen. Eftersom projektet är strängt avgränsat till ROS begränsar det var efterforskning för externa verktyg sker.

3.2 Förstudie

För att hitta nödvändig information om vilka resurser som är nödvändiga gjordes

databassökningar efter ROS tillsammans med nyckelorden Motion Planning, agriculture och

pruning. Detta gav ett gott underlag för att förstå vilka verktyg som kan vara lämpliga att

tillämpa för att fylla ut projektets avgränsningar. 3.3 ROS

ROS är kärnan i projektet men eftersom ROS är väldigt omständigt att arbeta med utan extra verktyg är den direkta interaktionen med ROS begränsad.

För att skapa ett projekt i ROS skapades ett paket utformat efter standarden för ROS-paket där flertalet mindre applikationer skapades. Alla dessa applikationer arbetar mot ROS-kärnan och är beroende av att de körs under exekvering.

För att kunna skapa ett gränssnitt mellan en användare och ROS där en i förväg utvald robot är involverad skapades en .launch-fil som innehåller information om vilken robotmodell det är som ska laddas in i ROS och vilka komponenter som behöver vara aktiva.

3.4 Strukturering av problemet i mjukvara

Ramverket MoveIt ger möjligheten att beskriva primitiva geometrier som cylindrar, rätblock, koner och sfärer. Dessa geometrier kan sedan fungera som objekt som rörelseplaneraren undviker. Detta implementeras i ett objekt som representerar ett arbete som roboten ska utföra. Objektet har attribut som position, kollisionsgeometri och en flagga som indikerar om arbetet är avslutat eller inte.

(18)

För att hantera arbeten tas ett objekt fram som fungerar som arbetshanterare. Objektet innehåller en lista med alla arbeten och en lista med all extern kollisionsgeometri.

Arbetshanteraren håller reda på vilka arbeten som är avslutade och vilka arbeten som inte är det. Arbetshanteraren har direkt åtkomst till planneringsscenen och rörelsegruppen för att enkelt kunna lägga till föremål till planneringsscenen och och uppdatera den vid förändring. Arbetshanteraren planerar arbete med en algoritm som iterativt jobbar genom kön av arbeten och upprepar detta till att alla arbeten är avklarade eller inga arbeten är möjliga at klara av längre. Uppbyggnaden av algoritmen är baserad på idéen om bevisbart korrekta kontroller som demonstreras i källa [6]. Genereringen av algoritmen är dock inte automatiserad som de som presenteras i den rapporten är.

3.5 Hantering av rörelseplanering

För att ta fram en rörelseplan för robotarmen utifrån enklare parametrar används MoveIt. En applikation skapas utifrån MoveIt’s API där all direkt tillgång till kinematiklösare och rörelseplanerare finns.

Innan en implementation i MoveIt kan tas fram behöver en robotarm specificeras. Därför användes en färdig MoveIt-konfiguration för robotarmen Universal Robot 10 som Örebro Universitet gav tillgång till.

Rörelseplanen genereras utifrån arbeten som ligger i kön. Hela rörelsen är indelad i två delar, först en rörelse som tas fram genom en sökning med RRT* fram till första målpositionen, sedan en kartesisk rörelse rakt mot målets origo. En målposition och målorientering för armens spets tas fram från målets origo relativt robotens origo där målpositionen befinner sig på ett förinställt avstånd från målets origo. Orienteringen på målpositionen är sådan att ändeffektorn pekar rakt från robotens origo mot målets origo.

(19)

Resultat

4.1 Modellering av den fysiska miljön

Modellering av miljön som roboten navigerar i görs med hjälp av primitiva geometriska former som cylindrar och rätblock. Träd representeras av cylindrar och stenar representeras av rätblock, se figur 6.

Figur 7. En visualisering av en robotarm I tänkt arbetsmiljö. De gröna objekten får ej vidröras av robotarmen.

4.2 Hantering av arbetslistor

Eftersom slyet kan betraktas som ett hinder innan det är bortröjt kan det medföra problem då det finns mer än ett mål för armen att jobba med om mål som ska röjas förhindras av andra mål som ligger längre ned på kön. För att lösa det implementeras en enkel algoritm som ser till att alla mål som är möjliga avklaras, se figur 8.

(20)

Figur 8. Algoritmen som hanterar arbetskön i form av en systemskiss.

I algoritmen finns en kö av arbeten som ska avklaras. Arbetshanteraren gör ett försök att göra alla uppgifter i ordning förutsatt att uppgiften inte redan är avklarad sedan tidigare. Om en uppgift misslyckas hoppar arbetshanteraren över den och fortsätter till nästa i kön. Om arbetshanteraren kommit till slutet av kön utan ha avklarat någon uppgift, om flagga A är satt till Falskt, innebär det att arbetshanteraren har avklarat alla uppgifter som är möjliga för den att klara. Om flaggan är satt till Sant går arbetshanteraren till början av kön. Algoritmen är utformad på ett sådant sätt att inga oändliga loopar är möjliga.

Tidskomplexiteten för algoritmen är 𝑂(𝑛2) och 𝛺(𝑛) Som innebär att i värsta fall så kommer

algoritmen att köras lika många gånger som det finns antal arbeten i kön och bästa fall köra rakt genom kön och klara av alla arbeten på en gång.

I figur 9 syns en visualisering av en robotarm och några uppgifter satta i kösystemet som algoritmen i figur 8 ska hantera. Här är det troligt att roboten inte kommer att kunna hitta någon rörelseplan för att ta mål nummer 1 och 2.

(21)

Figur 9. En visualisering av en fiktiv arbetsmiljö med fyra ordnade mål.

Efter misslyckade försök att planera på mål 1 och 2 hoppar roboten över dessa och fortsätter med mål 3, enligt figur 9.

Figur 10. Mål 1 och 2 strukna ur aktuell köcykel.

När mål 3 och 4 är avklarade och bortplockade från kön ser visualiseringen ut som enligt figur 10, hindren som utgjordes av mål 3 och 4 är borta och flagga A är satt till Sant, därmed kommer roboten att börja om från början i kön. När mål 1 och 2 sedan är avklarade och roboten är i slutet av kön är flagga A satt till Falskt och körningen av algoritmen avslutas.

(22)

Figur 11. Mål 3 och 4 avklarade och köcykeln omstartad.

Detta är inte alltid ett optimalt sätt att arbeta igenom kön, men det garanterar att roboten iterativt gör varje uppgift och successivt skapar bättre förutsättningar för att lösa resterande uppgifter eftersom varje uppgift som avklaras innebär att ett hinder röjs bort. Om körningen avslutas utan att alla jobb är avklarade innebär det att roboten inte hade klarat av alla

uppgifter oavsett given ordning på kön. 4.3 Den resulterande rörelsen

Armens rörelse för att uträtta ett enskilt arbete delas in i två mål som armen måste nå. I figur 12 till 14 syns en förklaring över hur rörelsen går till. I figur 12 är armen i sitt utgångsläge och har hittat en godkänd rörelseplan för att ta sig till huvudmålet.

Figur 12. En robot i startläge med rörelseplan.

I figur 12 har armen hittat sitt första mål i rörelsen vilket är en punkt som befinner sig någonstans på den linje som bildas mellan armens origo och målet och som har ett i förväg angivet avstånd till målet. Detta är nödvändigt för att verktyget som sitter på armen inte ska krocka med målet under rörelsen.

(23)

Figur 13. Roboten placerar ändeffektorn i rätt pose

I läget som armen står i vid första delmålet låses riktningen på armens spets så att verktyget behåller sin riktning mot mitten på målet. Sedan beräknas en kartesisk rörelse, som syns i figur 14, av armens spets in mot målet till dess att verktyget befinner sig på rätt plats för att genomföra klippningen.

Figur 14. Ändeffektorn förs in med en rätlinjig rörelse

Efter att klippningen är genomförd och bekräftad uppdateras armens startposition till aktuellt läge och eventuellt nytt arbete börjar planeras enligt algoritmen i figur 8.

4.4 Innehållet i ROS-paketet

ROS-paketet är projektets leverans. Paketet kommer enbart att kunna köras på ROS, och sannolikt endast distributionen ROS Melodic. Innehållet är beroende av flertalet andra ROS-paket som specificeras i dokumentationen.

Paketet innehåller ett bibliotek som förser användaren med funktioner som sköter om alla steg som specificerats i avsnitt 3.4 – 4.3 och en konfigurationsfil som låter användaren specificera saker som klipphöjd, rörelseplanerare, maximal planeringstid och andra parametrar. Se bilaga A för hela filen i aktuellt tillstånd.

(24)

Diskussion

5.1 Värdering av resultat

5.1.1 Mekanisk optimering

En mekaniskt god rörelse innebär få stötar och låg energiåtgång vid rörelse. Detta är inte saker som RRT*-algoritmen tar i åtanke när en rörelseplan tas fram utan den fokuserar

primärt på att efter förmåga förenkla en redan funnen lösning. Detta kan dock medföra en viss förbättring av rörelsen med avseende på mekanik men det är inte garanterat. Det tycks vara mindre troligt att rörelsen skulle försämras av en förfining av rörelseplanen men för att reda ut det behövs en bredare undersökning göras. Troligtvis så är det bästa sättet att mekaniskt optimera en rörelse att tillämpa en rörelseplanerare som inte är slumpmässig. I det fallet kan man ha rörelseplaneraren i åtanke vid val av kranarm.

Ett annat sätt att närma sig detta är om tillämpning av en deterministisk rörelseplanerare så man lättare kan förutse vilka stötiga rörelser som kommer att uppstå och anpassa hastigheten därefter. Stöd för det finns i MoveIt men kan vara svårt att implementera.

5.1.2 Tillämpning av biblioteket

För att biblioteket som levereras ska kunna tillämpas praktiskt i en större skala behöver vidare utveckling av biblioteket göras eftersom stöd för mer komplicerade geometrier bland hinder saknas. Stöd för externt visionsystem kan dock läggas till som en separat modul parallellt med biblioteket och implementeras till en ny programvara där informationen från visionsystemet översätts till den typ av information som biblioteket hanterar.

Eftersom rörelseplaneraren utgår från att miljön inte förändras under körning så är biblioteket implementerat på ett sådant sätt att kranarmen förväntas vara förankrad på samma plats under hela körningen. Detta är utifrån studien som genomförts inte en okonventionell lösning på problemet då rörelseplanering i en dynamisk miljö är känt för att vara väldigt svårt att hantera.

5.1.3 Hur MoveIt används och hur det ska användas

Det verkar inte finnas någon tydlig konsensus om hur MoveIt tillämpas för att lösa problem, om det fungerar så är det bra nog är attityden som genomsyrar dokumentationen och

hjälpforumen. Detta medför att det är svårt att veta hur programvaran ska designas för att göra den skalbar och lätt att bygga vidare på och vilka verktyg som är lämpligast för olika typer av problem.

Mycket av tiden gick åt till att justera olika parametrar i MoveIt och prova olika lösningskoncept och mindre av tiden gav något konkret resultat.

5.1.4 Implementation på andra kranar

Eftersom verktygen som tagits fram teoretiskt sätt klarar av att hantera den robotmodell man väljer att använda sig av så behöver den som implementerar det här på en ny arm göra

bedömningen om utrustning är lämplig till arbetet som den ska utföra. Om miljön som arbetet ska utföras i inte är väldigt väldefinierad så bör en överaktuerad arm väljas för att öka chansen att arbetet kan utföras.

(25)

5.2 Fortsatt arbete

Här presenteras förslag till fortsatt arbete som kan ta vid där det här arbetet slutar utan ett stort glapp.

5.2.1 Modellering av terräng och hinder

För att det här projektet ska vara användbart i mer realistiska miljöer kommer det vara viktigt att skapa en mer realistisk bild av miljön som robotarmen är tänkt att operera i.

Implementation av ett system som kan modellera en miljö i 3 dimensioner och ge en mer realistisk bild av hur terrängen och eventuella hinder ser ut kommer högst sannolikt visa sig vara nödvändig förr eller senare eftersom marken utomhus sällan kan approximeras till ett plan.

5.2.2 Optimering av arbetskön

Algoritmen som beskrivs under avsnitt 4.3 är sannolikt inte optimal för alla situationer. Om det med tiden visar sig att mycket tid förloras på grund av dålig prioritering av arbeten kan en möjlig lösning vara att i förväg beräkna alla rörelseplaner. Efter att samtliga beräkningar har gjorts kan man sedan tillämpa en sökalgoritm, exempelvis Dijkstras algoritm, för att hitta den optimala ordningen. Detta är dock en väldigt krävande strategi om utrustningen som används har begränsad datorkapacitet, rekommendationen är att tillämpa en flertrådad lösning för att beräkna rörelseplaner för att inte riskera att förlora tid.

5.2.3 Utföra en riskanalys

Hur risker ser ut i samband med implementering av det här projektet i en verklig maskin är svår att göra när ingen maskin är specificerad och är därför inte inkluderad i denna leverans. Då det finns en risk att människor eller djur kommer i vägen för roboten under arbete kan lämpliga metoder för att förebygga skada behövas tas fram.

En annan viktig sak att titta på är den mekaniska stabiliteten i systemet som roboten sitter på, troligtvis ett fordon. Eftersom en rörelseplanerare kan ta väldigt oväntade vägar är det viktigt att ha det i åtanke.

5.2.4 Klipphöjd

En parameter som helt utelämnats i den här rapporten är klipphöjd vid slyklippningen. Anledningen till det var att det skulle medföra ytterligare en dimension för rörelseplaneraren att iterera igenom och potentiellt medföra höga tidskostnader vid beräkning. Det var också en del som jag tidigt insåg att jag kommer behöva inkludera i fortsatt arbete eftersom klipphöjd kan behöva bero av hur terrängen ser ut, särskilt om terrängen är väldigt ojämn.

5.2.5 Angreppsvinkel

Angreppsvinkeln för klippverktyget är just nu fast i att utgå från robotens origo rakt mot målet. Detta är inte alltid optimalt och skulle potentiellt kunna medföra att en del arbeten inte kan utföras. Detta är dock ett väldigt underbestämt problem och informationen som det här projektet bearbetar räcker inte till för att göra en bedömning om vilken angreppsvinkel som är lämpligast.

(26)

Slutsatser

Implementationen är i prototypstadie och behöver breddas för att kunna tillämpas praktiskt. Utförligare definition för vilken typ av kranarm som ska användas bör tas fram med avseende på frihetsgrader och dimensioner.

Lösningen kan kompletteras med ett visionsystem. Viss modifikation av biblioteket kan dock vara nödvändig eftersom geometrin som beskriver hinder är väldigt primitiv och begränsad i det här stadiet.

Köhanteringen kommer sannolikt inte vara flaskhals för prestation om antalet mål som hanteras vid ett tillfälle inte är stort. Om antalet däremot är väldigt stort så bör en annan lösning implementeras eftersom maximal tidskomplexitet ökar kvadratiskt med antalet arbeten i kön.

(27)

Referenser

[1] Skogforsk [internet] Uppsala: Skogforsk 2020. [citerad 2020-05-27]. Hämtad från www.skogforsk.se

[2] Englund M, Mörk A, Gelin O, Elisson L, Påverkan av kranspetsstyrning på nya skogsmaskinförares utveckling [internet]. Uppsala: Skogforsk 2018. ARBETSRAPPORT 968-2018. [citerad 28 April 2020].

Hämtad från:

https://www.skogforsk.se/cd_20190114162645/contentassets/58179ee4fe374aacb3143faf6fae 33de/arbetsrapport-968-2018.pdf

[3] Schütz C, Pfaff J, Baur J, Buschmann T, Ulbrich H, A Modular Robot System for

Agricultural Applications, International Conference of Agricultural Engineering. Zürich 2014. [4] Hemming J, Bac C. W, van Tuijl B, Barth R, Bontsema J, Pekkeriet E, A robot for

harvesting sweet-pepper in greenhouses, International Conference of Agricultural Engineering. Zürich 2014.

[5] Wageningen University & Research, Clever Robots fOr croPS [internet]. Wageningen: Wageningen Univeristy & research; c2019 [citerad 4 Maj 2020] Hämtad från:

http://crops.sweeper-robot.eu/

[6] Wong K W & Kress-Gazit H, From High-level Task Specification to Robot Operating System (ROS) Implementation, First IEEE International Conference on Robotic Computing. 2017.

[7] Deng H, Xiong J, Xia Z, Mobile Manipulation Task Simulation using ROS with MoveIt, Proceedings of The 2017 IEEE International Conference on Real-time Computing and Robotics. 2017.

[8] Corke P, Robotics, Vision and Control. 1 uppl. Berlin: Springer-verlag; 2011.

[9] Quigley M, Gerkey B, Conley K, Faust J, Foote T, Leibs J et al, ROS: an open-source Robot Operating System. Stanford: Stanford University [okänt år]

[10] ROS history [internet] 2020. [läst 2020-06-03]. Hämtad från https://www.ros.org/history/ [11] Karaman S, Frazzoli E, Sampling-based Algorithms for Optimal Motion Planning. Cambridge: Institute of Technology, the Laboratory for Information and Decision Systems; 2011.

[12] Bo Tonnquist, Projektledning. 6 uppl. Stockholm: Bo Tonnquist och Sanoma Utbildning AB. 2016

(28)

Bilaga A Bilaga A. Konfigurationsfil

#ifndef CONFIG_H #define CONFIG_H

#include <string>

// Radius of the brush wood

static const double RADIUS = 0.04; // Height of the brush wood

static const double HEIGHT = 2.0; // The predetermined cutting height

static const double CUT_HEIGHT = 0.3;

// Lenght required from the end effector for a cartesian approach

static const double EE_LEN = 0.2;

// The amount of the cartesian path that need to be completed // for the task to pass as completed.

static const double CARTESIAN_LIMIT = 0.6; // The name of the move group to be used

static const std::string PLANNING_GROUP = "manipulator"; // The name of the motion planner to be used

static const std::string MOTION_PLANNER = "RRTstarkConfigDefault"; // The maximum time allowed for the planner

static const double PLANNING_TIME = 10.0; #endif

Figur

Updating...

Relaterade ämnen :