Designspeci kation Autonom spaning med quadcopterDesignspeci kation 2014-10-19 [email protected] Autonom spaning med quadcopter 3 2 Oversikt av systemet Den f ardiga produkten

DesignspecifikationAutonom spaning med quadcopter

Version 1.0

Projektgrupp: KvaddaKopterDatum: 2014-10-19

Status

Granskad MP 2014-10-19Godkand Christian A. Naesseth 2014-10-14

Reglertekniskt Projekt KvaddaKopterDesignspecifikation 2014-10-19 [email protected]

Projektidentitet

E-post: [email protected]: http://www.isy.liu.se/edu/projekt/tsrt10/2014/quadcopter/Bestallare: Christian A. Naesseth, ISY, Linkoping University

Tel.: +46 13 281087, E-post: [email protected]: Maria Andersson, FOI

E-post: [email protected]: Daniel Axehill, Linkopings universitet

Tel.: +46 13 284042, E-post: [email protected]: Clas Veiback, Linkopings universitet

Tel.: +46 13 281890 , E-post: [email protected]

Gruppmedlemmar

Namn Ansvar Telefon E-post(@student.liu.se)

Magnus Blomberg Designasnvarig 073-929 54 57 magbl113Tobias Hammarling Testansvarig 070-425 55 32 tobha614Teodor Johnsson 073-080 74 38 teojo382Emil Klinga Projektledare 070-130 23 49 emikl364Oliver Larsson 076-273 41 82 olila044Anton Niglis 070-360 53 01 antni601Martin Pettersson Dokumentansvarig 070-347 78 90 marpe238

Per Oberg 070-494 82 45 perob757

Dokumenthistorik

Version Datum Utforda andringar Utforda av Granskad1.0 141019 Komplettering av kommentarer

fran BPMP,OL MP

0.2 141012 Andra utkast efter kommentarerfran handledare

KvaddaKopter MP

0.1 141006 Forsta utkast KvaddaKopter KvaddaKopter


Innehall

1 Inledning 1

1.1 Parter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Projektets bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Syfte och mal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3.1 Kortsiktigt mal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3.2 Langsiktigt mal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Anvandning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5 Definitioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Oversikt av systemet 3

2.1 Styrmoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Koordinatsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Huvudbuss 6

3.1 Overgripande design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Granssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 GUI/HMI 9

4.1 Program och sprak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9


4.3 Layout for uppdragsplanering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.3.1 Uppdragstyper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.4 Layout for uppdragsfoljning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.5 Kartor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.5.1 Google Maps API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.5.2 Gmaps FX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Bildbehandling 13

5.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13


5.3 Sprak och bibliotek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.4 Terminologi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

5.5 Maldetekteringsmoduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.5.1 Malbildsmatchning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.6 Fargmatchning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.7 Bakgrundssubraktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.8 Stodfunktioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.8.1 Kalibrering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.8.2 Bildkvalitetsbestamning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.8.3 Malfoljning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.8.4 Malfoljning med multipla mal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6 Uppdragsplanering 22

6.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22


6.3 Program och sprak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.4 Terminologi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.5 Modulbeskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.5.1 Forbehandling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.5.2 Polygrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.5.3 Kostnadsmatris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.5.4 TSP-algoritm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.5.5 Interpolering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.5.6 Tidsberakning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7 Uppdragsfoljning 29

7.1 Sprak och program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.2 Regulatorstrukur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.3 Referensvaljare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8 Signalbehandling 32


8.2 Kalmanfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

9 Kommunikation 34

9.1 Inledning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

9.2 Overgripande Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34


9.4 Termonologi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

9.4.1 Server-sidan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

9.4.2 Klient-sidan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

9.5 Tillstands-data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

9.6 Referens/styr-signaler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

9.7 Videostrom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

9.7.1 Avkodning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

9.8 Rackvidd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

10 Plattform 38

10.1 Forandringar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

11 Sakerhetatgarder 39


Autonom spaning med quadcopter 1

1 Inledning

Detta ar en designspecifikation i projektet ”Autonom spaning med quadcopter”. Projektetgors i samband med kursen TSRT10 - Reglerteknisk projektkurs pa ISY, Instutitionen forsystemteknik, pa Linkopings universitet. Dokumentet presenterar de tillvagagangsattensom ar amnade att anvandas for att losa de uppgifter som foljer av kraven i kravspecifi-kationen [3].

1.1 Parter

De delaktiga parterna i projektet ar som foljande:

• Kund: Maria Andersson, FOI

• Bestallare: Christian A. Naesseth, ISY

• Handledare: Clas Veiback, ISY

• Examinator: Daniel Axehill, ISY

• Projektgrupp: KvaddaKopter

1.2 Projektets bakgrund

Intresset for autonoma och obemannade farkoster (UAV:er) har pa senare tid vuxit enormt.Mojligheterna som lockar ar att kunna utfora speciella typer av uppdrag som ar for far-liga, eller av annan anledning, olampliga for manniskor. Den kanske vanligaste typen avuppdrag ar spaning. UAV:n ar da utrustad med olika sensorer for att samla in data forden specifika tillampningen. Detta skulle till exempel kunna vara overvakning av kritiskinfrastruktur eller overblicksbilder vid nodsituationer. Farkosten skulle i dessa fall varaett valkommet inslag for att minska manskliga fel och malet ar att den fungerar sa valatt den frigor operatoren till att gora annat.

1.3 Syfte och mal

Syftet med projektet ar att tillampa inhamtade kunskaper for att skapa en produkt pa etttillvagagangsatt liknande hur arbetet sker i arbetslivet. Projektet ska anvandas for att geprojektets medlemmar en chans att lara sig mer om hur projektarbete gar till samtidigtsom kunden far en produkt som har reella anvandningsomraden. Projektets mal kan delasupp i kortsiktiga och langsiktiga mal.

1.3.1 Kortsiktigt mal

Det kortsiktiga malet med detta projekt ar att utveckla en demonstrator for enklarehognivaautonomi. Plattformen ska vara baserad pa en quadcopter med tillgang till GPS-och strommad videodata i realtid.

Projektet bestar i att utveckla och implementera funktionalitet, baserat pa en quadcopter-plattform, for:

• Att planera ett autonomt uppdrag dar plattformen soker av ett omrade runt engiven koordinat efter mal.



• Att planera ett autonomt uppdrag dar plattformen overvakar och detekterar mallangs en given stracka eller i ett givet omrade.

• Att utfora planerade uppdrag.

• Att detektera mal i sensordata som levereras fran plattformen da den utfor ettuppdrag.

• Att i man av behov utfora enkel malfolning av detekterat mal.

1.3.2 Langsiktigt mal

Det langsiktiga malet med projektet ar att skapa en bas for en FOI-demonstrator somkan anvandas for att visa pa mojligheterna och nyttan med olika typer av autonom UAV-funktionalitet. Plattformen och den struktur som byggs upp kan aven anvandas for attutveckla och testa nya typer av autonoma funktioner, algoritmer for maldetektion ochalogritmer for malfoljning eller flera samverkande plattformar.

1.4 Anvandning

Slutprodukten kommer att anvandas for att demonstrera anvandningsomraden inom au-tonom spaning med en UAV i form av en quadcopter. Tanken ar att FOI efter projektetsavslutande ska kunna anvanda produkten som demostrator samt som en bas for vidare-utveckling. Med anledning av detta kommer mjukvaran skrivas sa att detta blir sa enkeltsom mojligt.

1.5 Definitioner

I dokumentationen av projektet kommer flertalet omradesspecifika begrepp att anvandas.Dessa ar punktade nedan med tillhorande beskrivning.

Plattform: Med plattform avses quadcoptern sammanlankad med GPS ochvideokamera som en enhet.

Trajektoria: Den kurva som plattformen har som mal att folja vid autonomstyrning.

Standardmal: Enkla geometrier som bildbehandlingsmodulen klarar av attkanna igen.

Tackningsgrad: Andelen av en yta som blivit avsokt.

GUI/HMI: Grafiskt anvandargranssnitt.(eng. Graphical User Interface, Human Machine Interface)

GPS: Globalt positionssystem



2 Oversikt av systemet

Den fardiga produkten ska mojliggora for en quadcopter att utfora enklare spaningsupp-drag autonomt. I denna kedja ingar uppdragsplanering, uppdragsfoljning, reglering samtbildbehandling for maldetektion. Produkten kan i grova drag delas upp i komponenterenligt figur 1. Varje block i schemat har en specifik uppgift dar tanken ar att varje modulska kunna utvecklas och fungera separat. Pilarna i figuren representerar beroenden ochkommunikationsvagar. I tabell 1 visas en kort forklaring till modulernas ansvarsomraden.

Figur 1: Overgripande flodesschema for systemets generella upplagg

2.1 Styrmoder

Systemet kommer ha tva olika styrmoder for plattformen. Den forsta ar full autonom flyg-ning. Autonom flygning kraver tillgang till GPS-signal for att initieras och ar saledes me-nad for utomhusflygning endast. Vid autonom flygning anvands uppdragsfoljningsmodulenfor styrning av plattformen och uppdragsplanering for att generera referenssignal.

Den andra moden ar manuell styrning, menad for flygning inomhus och eventuella tes-ter utomhus. Manuell styrning ska kunna initieras nar som helst under bade flygninginomhus och utomhus och gors genom GUI. Nar manuell styrning initieras forbikopplasuppdragsplanering- och uppdragsfoljningsmodulen, styrsignaler erhalls da istallet av enjoystick. Plattformen kommer darfor inte ha nagon autonom formaga vid inomhusflygning.



Modul AnsvarsomradeHuvudbuss Kommunikationslager mellan alla systemets moduler.Kommunikation Skoter kommunikation mellan plattformen och huvudbussen.Signalbehandling Mojliggor skattning av fysikaliska tillstand.Bildbehandling Anvander insamlad videostrom for att lokalisera mal.Bildavkodare Ser till att bildbehandlingen har ratt datatyp.Uppdragsplanering Tillhandahaller referenssignaler till uppdragsfoljningsmodulen.Uppdragsfoljning Beraknar styrsignaler till plattformen fran givna referenssignaler.GUI Interaktiv planering och utforande av spaningsuppdrag.Kartor Tillgodoser GUI med oversiktskartor for planering.Lagring Mojliggor persistens av data, t.ex. planerade uppdrag, kartor

och konfiguration.

Tabell 1: Systemets olika moduler och ansvarsomraden.

2.2 Koordinatsystem

I dokumentet kommer tre olika koordinatsystem att anvandas for att kunna beskriva allaolika tillstand och uppkomna situationer. De fyra olika koordinatsystemen ar WGS-84,N-frame, B-frame och T-frame vilka gar att betrakta i figur 2 och ar definierade enligtfoljande.

• ”WGS-84” ar koordinatsystemet som anvands for att beskriva position med GPSkoordinater och ar definierad efter jordens geometri. WGS-84 ar utskrivet somXgps, Ygps dar X = longitud, Y = latitud och H = altitud.

• ”Navigation frame” (N-frame), ar ett lokalt koordinatsystem pa plattformen sominte foljer plattformens rorelser. Det ar utifran denna som yawvinkeln ar definierad.N-axeln pekar alltid mot norr, E-axeln mot oster och D-axeln nedat. Navigationframe ar utskrivet som N,E,D.

• ”Tracking frame” (T-frame), ar ett lokalt koordinatsystem med samma riktningarsom Navigation frame men med origo fixt i plattformens startpunkt.

• ”Body frame” (B-frame), ar aven det ett lokalt koordinatsystem pa plattformen.Detta koordinatsystem foljer plattformens rorelser och vinklar och ar definieradefter plattformens geometri. Koordinatsystemet har x-,y och z-axlarna pekandes raktfram, at hoger och rakt ner (dessa kallas aven roll- tipp- och giraxel), genomgaende irapporten kommer dock de engelska beteckningarna anvandas (roll, pitch och yaw).Bodyframe ar utskrivet som x, y och z.



Figur 2: Overgripande figur som visar hur de tre olika koordinatsystemen hanger ihop.GPS koordinater ar definerade pa sfaren (forestallande jordklotet), bilden till hoger visaren 2-dimensionell bild over hur N-frame och E-frame ligger i varandra men kan ha olikariktningar da D-axeln och z-axeln ligger i varandra.



3 Huvudbuss

Huvudbussen ar karnan for hela systemet och ar den forsta modul som initieras narmjukvaran startas och halls vid liv under hela den tiden programmet ar igang. Modulenar initialt ansvarig for att starta alla systemets ovriga komponenter och fungerar sedansom ett kommunikationslager mellan dessa. Flodet for huvudbussens aktiviteter kan ses ifigur 3.

Figur 3: Flodesschema for huvudbussens tva uppgifter. Initiera moduler och tillgodosemoduler med svar pa de fragor de har.

3.1 Overgripande design

Huvudbussen kommer i implementationen vara ett enda objekt vars yttersta och endaansvar ar att skicka vidare data mellan systemets olika komponenter. Med denna strukturuppnas en hog grad av modularitet da modulerna inte har nagon som helst vetskap omvarandra. Alla fragor en komponent har till det ovriga systemet sker via huvudbussenoch denna ser da till att svara pa ett korrekt satt. Bussen kommer av denna anledningbehova implementera ett granssnitt for att alla mojliga kommunikationsvagar ska varaentydigt definierade. Huvudbussen ska vara ett tradsakert objekt da flera moduler (somkors i separata tradar) kan forsoka skriva/lasa samma variabel.

3.2 Granssnitt

For att veta hur huvudbussen ska svara pa olika fragor kommer denna vara tvungen attimplementera ett granssnitt (eng. interface). Antag scenariot beskrivet i figur 4 och antagfor enkelhetens skull att GUI bara behover veta aktuell hastighet for plattformen ochfragar darfor huvudbussen om denna information. Huvudbussen returnerar da vardet pasin egen medlemsvariabel. Vardet som huvudbussen har tillgang till ska hallas uppdateradav kommunikationsmodulen. Hur dessa varden satts ar definierade i ett granssnitt.



Figur 4: Flodet da en modul behover stalla en fraga till en annan modul.

I detta fall skulle huvudbussen behova implementera ett granssnitt ”MainBusInterface”enligt kodutsnitt 1. Dessa granssnitt definierar fullstandigt kommunikationen mellan detva komponenterna sa att det inte rader nagot tvivel om hur detta ska ga till. Forutomatt detta ger modularitet och tydlig dokumentation om vilka fragor som kan stallas gerdet ocksa en extra kontroll da modulerna kompileras. Skulle en modul inte uppfylla ettgranssnitt gar koden inte att kompilera och kompilatorn talar om vad som inte ar uppfyllt.

Kodutsnitt 1: Exempel pa ett granssnitt.

public interface MainBusInterface {double getCurrentPlattformSpeed ();void setCurrentPlattformSpeed(double speed);//...

}

class MainBus implements MainBusInterface{public void setCurrentPlattformSpeed(double speed){

this.currentPlatformSpeed = speed;}public double getCurrentPlattformSpeed (){

return this.currentPlatformSpeed;}//...

}

class Communication{private void updateSpeed (){

this.mainBus.setCurrentSpeed (55.0);}

}

Pa detta satt kommer granssnitt behova skapas for samtliga moduler. Ett granssnittimplementeras av modulerna sjalva och ett implementeras av huvudbussen. En fullstandiglista over de granssnitt som behover skapas kan ses i tabell 2.

Granssnittets namnMainBussInterfaceGUIInterfaceStorageInterfaceCommunicationInterfaceImageProcessingInterfaceSignalProcessingInterfaceMissionPlannerInterfaceMissionControlInterface

Tabell 2: Alla nodvandiga granssnitt.

Forutom dessa kommer alla moduler aven tvingas implementera ett mer generellt granssnitt”ModuleInterface”. Detta ska tvinga alla moduler att ha gemensamma metoder for att



hantera mer generella uppgifter som att starta och stoppa modulen. Detta ger huvudbus-sen mojlighet att hantera samtliga moduler utan att sjalv behova veta exakt hur dettasker i varje enskild modul. Ett sadant granssnitt kan ses i kodutsnitt 2.

Kodutsnitt 2: Ett generellt granssnitt for alla moduler.

public interface ModuleInterface {void initialize ();void destroy ();//...

}

Varje modul kommer anvanda en egen trad for att dessa ska koras parallellt. Modulernakommer frekvent att skriva och lasa fran huvudbussen och med denna anledning behoverhuvudbussen goras tradsaker. Detta ar en enkel uppgift i Java da primitiva datatyper artradsakra automatiskt och ovriga typer gors tradsakra genom att anvanda ett kodblockenligt kodutsnitt 3. Blocket fungerar som en vakt som bara later en trad i taget anvandaden kod som omsluts. Om flera tradar vill anvanda samma del samtidigt kommer enatkommstko automatiskt att upprattas.

Kodutsnitt 3: Tradsakerhet i Java.

synchronized{// Thread safe code goes here ....

}



4 GUI/HMI

Modulen GUI/HMI ar den modul som ansvarar for att visa slutanvandaren ett granssnittfor att planera och folja uppdrag.

4.1 Program och sprak

For att snabbt och enkelt kunna bygga grafiska granssnitt behovs nagon form av grafik-bibliotek. Sadana bibliotek finns till alla de stora spraken (C++/Java/Python mm) menvalet foll pa ”Java FX”. Detta bibliotek tillsammans med tillagget ”Screen Builder” gordet mycket enkelt att bygga GUI:s med standardkomponenter som flikar, knappar, dialo-grutor. Resultatet fran byggandet ar en XML-fil som med tva rader kod kan importerastill en Java-applikation.


GUI:t har tva huvudsakliga uppgifter, uppdragsplanering och uppdragsfoljning. Slutanvandarenar bara intresserad att na en av dessa delar i taget. Av denna anledning ar det naturligtatt dela in programmet i just dessa tva delar. I anvandargranssnittet sker detta genomatt ha tva flikar (se figur 5) sa att bara en av dessa kan visas i taget.

Figur 5: Anvandargranssnittets huvudsakliga uppdelning.

Denna uppdelning resulterar i tva programklasser som representerar flikarna. Varderaklass ar ansvariga for sin flik och all anvandarinteraktion med denna. Interaktion kant.e.x vara klickande eller skrivandet av ny text i en textruta. Da interaktion med kartorutgor en sa stor del av programmet brots logiken for detta ut till tva separata klasser. Enlista over de fyra huvudklasserna for det grafiska anvandargranssnittet kan ses i tabell 3.

Programklass AnsvarPlanningController Interaktion med planerings-flikenExecuteMissonController Interaktion med utforande-flikenPlanningMap Interaktion med planeringskartanMissionMap Interaktion med karta under uppdrag

Tabell 3: Anvandargranssnittets huvudsakliga programklasser.

4.3 Layout for uppdragsplanering

Under fliken uppdragsplanering finns alla nodvandiga funktioner for att planera uppdrag.En skiss over flikens upplagg kan ses i figur 6. Under planeringen av ett uppdrag skaanvandaren ha mojlighet att specificera ett namn for uppdraget, vilken typ av uppdragdet handlar om samt fran en lista med standardmal kunna valja ett objekt som plattformenska leta efter. Har finns aven alternativ for vilken hojd uppdraget ska utforas pa.



Figur 6: Schematisk skiss over anvandargranssnittet for uppdragsplaneraren.

Nar den grundlaggande informationen om uppdraget finns ska anvandaren via oversiktskartanspecificera relevanta GPS-koordinater for uppdraget. Exakt vilka typer av koordinater be-ror pa vilken typ av uppdrag som valts (se avsnitt 4.3.1). Gemensamt for alla uppdragar dock att forbjuda omraden ska kunna specificeras. Detta gors genom att koordinaterplaceras ut som utgor en godtycklig polygons granser.

Under processen da koordinater placeras ut kan anvandaren nar som helst valja ta bortkoordinater fran kartan som blivit fel.

Nar detta ar fardigt kan uppdraget i sin helhet sparas. Nar detta sker kommer ett objektsom representerar uppdraget skickas till huvudbussen for lagring. Flodet for denna processkan ses i figur 7.

Figur 7: Signalflode vid sparande av ett uppdrag.

4.3.1 Uppdragstyper

Under planeringen ska anvandaren kunna specificera tre olika typer av uppdrag definieradeenligt tabell 4. Indatan kan aven kompletteras med koordinater for forbjudna omraden.

Uppdragstyp Nodvandig indataAvsokning runt punkt En GPS-koordinat och sokradie.Avsokning langs bana Lista med GPS-koordinater som definierar en bana.Avsokning inom omrade Lista med GPS-koordinater som definierar omradets granser.

Tabell 4: Anvandargranssnittets huvudsakliga programklasser.



4.4 Layout for uppdragsfoljning

Nar ett uppdrag har skapats och anvandaren bestammer sig for att utfora detta anvandsfliken uppdragsfoljning. Har valjs ett tidigare sparat uppdrag i en rullista. Uppdragetpresenteras pa oversiktskartan. For att starta uppdraget trycker anvandaren pa knappen”Starta uppdrag”.

Under uppdraget ska granssnittet visa nodvandiga notifikationer, WIFI-status, GPS-status, aterstaende tid, stracka, videostrom och plattformens position pa en karta. Narsom helst under uppdraget ska anvandaren kunna trycka pa ”Avsluta uppdrag”.

Figur 8: Schematisk skiss over anvandargranssnittet for uppdragsfoljningen.

4.5 Kartor

Oversiktskartorna anvands vid planering och vid uppdragsfoljning utgor en stor del avanvandargranssnittet. Anvandaren ska enkelt kunna scrolla runt pa kartan, zooma, placeraut eller ta bort koordinater under planeringen och under utforandet aven kunna foljaplattformen pa kartan da den flyger. For att underlatta detta arbete anvandes existerandebibliotek for att lagga grunden for denna funktionalitet. Ett mycket populart API for dettaar Google Maps.

4.5.1 Google Maps API

Google Maps ar ett mycket valbeprovat bibliotek som ges ut av Google. Dessa kartorhar fran borjan en hel uppsjo av funktionalitet som alldeles utmarkt passar projektetsbehov. Kartorna tar hand om ”klick”-handelser for att placera ut markorer, ger mojlighetatt vaxla mellan olika typer av kartor samt gor det mycket enkelt att utoka befintligfunktionalitet. Google Maps ar dock skrivet i Javascript och ar ursprungligen avsedd foratt visas i webblasaren. Da kartorna ska in-baddas i en Java-applikation kravs nagonform av kompatibilitetslager. Da Google maps anvander Googles servrar kraver dettaatt kartorna laddas over internet. Kartorna kan dock sparas i en ”cache” vilket gor demtillgangliga ”offline”.



4.5.2 Gmaps FX

Gmapsfx ar ett ”open source”-bibliotek som fungerar som en oversattare mellan Java ochJavascript for Google Maps API. Biblioteket gor det mojligt att interagera med kartornamed ren Java-kod (Java FX) istallet for att behova skriva Javascript. Tyvarr ar Gmapsfxfortfarande i sin linda och stodjer bara en brakdel av API:t men detta verkar inte varanagot problem da all funktion som kravs i projektet ar inkluderad. En schematisk bildover signalflodena for kartmodulen visas i figur 9.

Figur 9: Signalfloden for kartmodulen.



5 Bildbehandling

I detta kapitel beskrivs bildbehandlingsmodulens uppgifter och algoritmer for att utforadessa.

5.1 Inledning

Bildbehandlingsmodulen ska skota det datorseende som kravs for att utfora uppdrag. Bild-behandlingsmodulens uppgift ar att ur en bildstrom kunna detektera och folja specifikaforemal. Syftet med denna del ar att ge en overgripande insikt i hur bildbehandlingsalgo-ritmerna kommer att implementeras. Nagon pseudokod presenteras ej utan funktionernasprincipiella utforande ar i fokus.

Detektering ska kunna ske med tre olika algoritmer. Fargmatchning kommer att anvandasfor att detektera objekt med en specifik farg och beskrivs i avsnitt 5.6. Objekt ska kunnaurskiljas genom jamforelse med en mall. Detta gors med malbildsmatchning som byggerpa att jamfora intressepunkter fran bildstrommen med intressepunkter i en mall-bild.Denna metod beskrivs i avsnitt 5.5.1. Den tredje metoden som kommer att anvandasar bakgrundssubtraktion och anvands for att detektera foremal som ror sig. Genom attjamfora med tidigare tillstand kan man pa sa satt bedoma vad som ar bakgrund och vadsom har rort sig. Metoden beskrivs i avsnitt 5.7. Efter detektering ska malfoljning utforas,denna algoritm ar beskriven i avsnitt 5.8.3.

Bildbehandlingsmodulen ska aven kunna kalibereras och bestamma bildkvalitet (hur myc-ket rorelseoskarpa det ar). Dessa algoritmer ar beskrivna i avsnitt 5.8.1 respektive 5.8.2.

Grundlaggande terminologi och bildbehandlingstermer som ar bra att kanna till beskrivsi avsnitt 5.4.


For varje bildruta, fran videostrommen, som ska behandlas anvands designen beskriven ifigur 10. Beroenden framgar av kopplingarna. For att exempelvis malbildsmatchning skakunna koras behover forbehandling och extrahering av intressepunkter koras.



Figur 10: Flodesschema for bildbehandling

Under forbehandlingen kan exempelvis bildkvalitet skattas. De tre beskrivna detektions-metoderna forklaras utforligare under respektive rubrik. De tre detektionsmodulerna harsamma struktur pa utsignalen varfor malfoljningen kan hantera de olika modulernas re-sultat. Utsignalen fran modulerna innehaller bland annat position pa detekterat mal ochmalets storlek.

De maldetektioner som gors i de tre maldetekteringsmodulerna kan visualiseras utan attanvanda malfoljningsmodulen.

5.3 Sprak och bibliotek

Bildbehandlingsmodulen utvecklas i Java med IDE:t Eclipse, detta kan dock komma attandras om det framkommer att ett annat sprak passar projektets helhet battre. Bildbe-handlingsbiblioteket OpenCV anvands for att utfora grundlaggande bildbehandlingsope-rationer for datorseende.

5.4 Terminologi

Nedan beskrivs nagra grundlaggande koncept som kommer att anvandas i bildbehand-lingsalgoritmerna.



Intressepunkter och Deskriptorer: Intressepunkt ar en position i bildrymden. Tillvarje intressepunkt hor en sa kallad deskriptor (feature pa engelska). En deskriptorhaller information om intressepunktens omgivning. Exempel pa sadan informationar ett histogram over fargvardena pa pixlar inom en radie kring intressepunkten.Deskriptorn kan ocksa innehalla en sannolikhet for att intressepunkten ligger pa enkant i bilden.

Overensstammelse: Ett matt pa hur val intressepunkters deskriptorer overensstammermed det sokta intressepunkter hos objektets deskriptorer.

SIFT: SIFT ar en metod for att extrahera skal- och rotationsinvarianta intressepunkter.

Morfning: Morfning innebar att pixelvarden i bilden andras beroende pa narliggandepixlar. Objekt kan expanderas och pa sa vis kan glapp fas bort. Objekt kan avenkontraheras. Dessa metoder kallas erosion och dilation och ar de enklaste morfo-logiska operationerna, men det finns fler. De olika operationerna anvands for atttydliggora hur objektet ser ut.

5.5 Maldetekteringsmoduler

Nedan beskrivs de detekteringsalgoritmer som kommer att anvandas i projektet.

5.5.1 Malbildsmatchning

Malbilder analyseras for att beskriva intressepunkters omgivning i malbilden. Bilder franvideostrommen analyseras pa liknande satt. Intressepunkternas omgivning i de nya bil-derna jamfors med malbildernas intressepunkter. Mangden liknelser i intressepunkter kanantas oka da ett mal, beskrivet av en malbild, finns i videostrommen.

In: Forbehandlad bildUt: Maldata

Figur 11: Flodesschema for malbildsmatchning



Intressepunkter: Intressepunkter och deskriptorer for dessa tas fram i det initiala steget.Deskriptorerna kan tas fram med exempelvis SIFT.

Overensstammelse mot malbilder: Deskriptorerna jamfors med deskriptorer for ma-lbilder och samband mellan dessa beraknas.

Fardig: Om en tillrackligt stor andel matchningar finns i en malbild kan resultatet ansesfardigt och en malbildsmatchning ar klar.

RANSAC: Om behov finns kan resultatet forbattras i RANSAC-steget. En slumpmassigmangd av overensstammelser valjs. En transformering skapas fran nuvarande intres-sepunkter till dess motsvarighet i malbilden. Mangden overensstammelser som valuppfyller transformeringen beraknas. Detta gors till dess att mangden overensstam-melser ar tillrackligt stor. I slutsteget kan transformeringen beraknas med hjalpav alla overensstammande intressepunkter for att forbattra resultatet. Transforme-ringen kan senare anvandas for att exempelvis markera ut en ram runt objektetalternativt en forutbestamd detalj i objektet.

Malfoljning: Informationen skickas vidare till malfoljningsmodulen.

5.6 Fargmatchning

Fargmatchning anvands for att detektera bilddata med en viss farg. Detta kan varalampligt om ett objekt med nagon valdigt specifik farg ska detekteras mot en bakgrundmed annan farg. T.ex rod boll mot gront gras i ett enkelt fall. Algoritmen for fargmatchningsynliggors i figur 12.




Figur 12: En schematisk bild over hur fargmatchningen kommer att ske.

RGB till HSV: I algorithmens forsta steg fors fargskalan over till en mer lattbehandladskala HSV, som star for (Hue-Saturation-Value) och ar en cylindrisk representationav fargskalan.

Troskling av kanaler: I nasta steg trosklas HSV-kanalerna, vilket gor att enbart denonskade fargen tas fram. Trosklingen som gors beror pa vilken farg som ska ex-traheras. Troskelvarden for farger pa de objekt som ska detekteras maste tas redapa.

Morfning: Pixelvarden maste sedan morfas pa ratt satt for att fa bort eventuella luckoroch gora objektet mer igenkannligt.

Formmatchning: En enkel formmatchning gors for att utesluta objekt som ar valdigtolika till form.

Avgransande lador: Varje objekt i rorelse representeras sedan av ett fyrkantigt omradei bilden, en sa kallad avgransande lada. Varje avgransande lada tilldelas ocksa ettid.

Malfoljning: Extraherad information skickas vidare till malfoljningsmodul.



5.7 Bakgrundssubraktion

Denna metod anvands for att detektera och kunna folja objekt som befinner sig i rorelse.Metoden ar illustrerad i flodesschemat nedan. Nedan foljer ocksa en beskrivning av varjedelsteg i flodesschemat.


Figur 13: Flodesschema for Bakgrundssubtraktion

Intressepunkter: I forsta steget extraheras intressepunkter med tillhorande deskriptorerur den inkommande bilden.

Overensstammelse mot foregaende bild: Sedan jamfors den nuvarande bildens de-skriptorer med foregaende bildens deskriptorer. Ur jamforelsen beraknas vilken in-tressepunkt i nuvarande bild som stammer bast overens med en intressepunkt iforegaende bild.

Transformation: Genom att undersoka hur intressepunkterna forflyttat sig kan manberakna hur mycket kameran forflyttat sig. Kameraforflyttningen beskrivs har av



en transformationsmatris. Med hjalp av transformationsmatrisen kan en del av denforegaende bilden transformeras in i den nuvarande bildens koordinatsystem.

(a) Bildtransformation (b) Bildtransformation

Figur 14: Bildtransformation i tva steg

Bakgrundssubtraktion: En pixelvis subtraktion utfors mellan nuvarande bild och dentransformerade foregaende bilden. Subtraktionen kan endast genomforas pa de omra-de dar bilderna overlappar. Om bilderna innehaller ett objekt i rorelse kommerobjektet synas som en differans mellan bilderna.

Morfning: Morfologiska operationer utfors pa resultatet for att sarskilja narliggandesammanhangande omraden och forbattra deras utseende.

Avgransande lador: Varje objekt i rorelse representeras sedan av ett fyrkantigt omradei bilden, en sa kallad avgransande lada. Varje avgransande lada tilldelas ocksa ettid.

5.8 Stodfunktioner

Nedan beskrivs de stodfunktioner som ska implementeras.

5.8.1 Kalibrering

For kunna transformera positioner i 2D bildkoordinater till en 3D position behover man tafram en kameramatris. Vid kamerakalibreringen bestammer man en kameramatris, vilkeninnehaller specifika parametrar for kamerahardvaran. OpenCV erbjuder en kalibrerings-funktion som modulen kommer kunna anvanda sig utav.

5.8.2 Bildkvalitetsbestamning

Innan detekteringsalgoritmerna anvands ska bildens kvalitet bestammas i form av i falletom hur mycket rorelseoskarpa det ar i bilden. Detta gors genom att kolla kanter i bildenoch hur breda de ar. Algoritmen beskrivs av figur 15.

Till graskala: Bildkanalerna transformeras till graskala.

Sobelfilter: Ett sobelfilter anvands for att ta fram kanter i bilden



Figur 15: Flodesschema for bestamning av bildkvalitet

Hitta kantbredd: Lokala maximum i horisontellt och vertikalt led tas fram. Genom attga igenom bilden kolonnvis respektive radvis. Skarpa kanter kommer ge hoga lokalamaximum och oskarpa kanter kommer ge breda laga lokala minimum.

Medelvarde: Medelvarde pa lokala maxima i horisontellt led respektive vertikalt led tasvar for sig. Pa sa vis fas ett matvarde pa estimerad skarphet i de olika leden.

Beslut: Beslut fattas om huruvida bildkvaliteten ar tillrackligt bra for att detekterings-algoritmer ska kunna anvandas. Vad som ar lampligt trosklingsvarde testas fram.

5.8.3 Malfoljning

Malfoljningsmodulen syftar till att forbattra foljning och detektion av mal som befinner sigi bild under langre tid. Modulen har data over vilka mal som fanns i foregaende bild. Nyadetektioner matchas mot tidigare och mal kan darfor foljas over tid. Ett filter ar appliceratpa malens tillstand och mojliggor darfor en battre skattning. Ett linjart Kalmanfilter kanimplementeras och losa de grundlaggande kraven.

Till varje objekt finns information om position och hastighet i varldskoordinater ochbildkoordinater. Varje objekt har aven ytterligare information om exempelvis farg, omdetektionen ar gjord med hjalp av fargmatchning. Koordinaterna beskrivs lokalt i T-frame.



Figur 16: En schematisk bild over hur malfoljningen kommer att ske.

Tidsuppdatering av tillstand: Under tidsuppdateringen uppdateras varje mals till-stand enligt dess rorelsemodell.

Jamfora objekt med tidigare tillstand: Detekterade objekt jamfors med tidigare ob-jekt och en koppling mellan tidigare och nya objekt bestams.

Matuppdatering av tillstand: De positionsmatningar som kan kopplas till ett objektutgor matningar for matuppdateringssteget. Deras skattade nya 2D-bildposition kor-rigeras med hjalp av kameraforflyttningen som ar beraknad i tidigare steg. Un-der matuppdateringen uppdateras tillstandet for objekten med avseende pa de nyamatningarna.

De tre stegen visas grafiskt i Figur 17.

(a) Tidssuppdatering franforegaende tillstand.

(b) Mathching med detekte-rade objekt.

(c) Bestam och uppdateratillstand.

Figur 17: Malfoljning i tre steg

5.8.4 Malfoljning med multipla mal

Ett problem som uppstar med malfoljning ar att multipla mal kan overlappa varandra.Detta ar endast ett problem da malen detekteras av samma modul eller da malen blirsvara att urskilja. Da multipla mal inte behover hanteras enligt krav i kravspecifikationenloses mojliga problem endast i man av tid.



6 Uppdragsplanering

6.1 Inledning

Uppdragsplaneringsmodulens uppgift ar att bestamma plattformens trajektoria vid avsok-ning av en yta eller langs en forutbestamd stracka. Trajektorian beraknas av en algoritmsom har tillgang till ett antal givna GPS-punkter, vilka bildar ett omrade alternativt enstracka. Utsignal fran uppdragsplaneringsmodulen ar referensdata i form av koordinatersom beskriver den beraknade trajektorian. Modulen ar menad att koras innan uppdragetinitieras och generera referensdata som sedan anvands under hela uppdraget.

I man av tid kommer uppdragsplaneringen konstrueras sadan att den inte endast skakoras innan initiering av uppdrag, utan aven ha mojlighet att korrigera for eventuellanytillkomna situationer. Som exempelvis att omraden har missats och behover eftersokasi slutet av uppdraget.


Uppdragsplaneringsmodulen kommer att ta emot objektorienterad data som beskrivervilken typ av uppdrag som ska planeras samt de kriterier som rader. Med kriterier avsesde koordinater som definierar omrade/fardvag samt forbjudana omraden. Denna informa-tion sorteras sedan for att darefter skickas till respektive funktion. Den slutforda processenresulterar i en fullstandig trajektoria. I figur 18 definieras informationsflodet genom mo-dulen. Beroenden framgar av kopplingarna.



Figur 18: Flodesschema for uppdragsplaneringsmodulen.

Under forbehandlingen sorteras datan ut och laggs i olika strukturer sa att den pa etteffektivt och enkelt satt kan anvandas av funktionerna som beskrivs utforligare nedan.Saledes kan indatan vara av varierande karraktar men utdatan kommer alltid att vara entrajektoria bestaendes av koordinater.

6.3 Program och sprak

Mjukvaran kommer att vara skriven i Java for enkel kommunikation med det ovriga syste-met. En av funktionerna kommer daremot att vara skriven i C-kod da detta ar ett externtprogram som loser problem av typen TSP (se sektionen Terminologi).

6.4 Terminologi

Vid utvecklandet av planeringsalgoritmen har en hel del teori fran optimeringslaran imple-menterats. For att enklast beskriva dessa delar kommer darfor de termer som ar specifikafor detta fackomrade att anvandas. Utforligare beskrivningar av dessa kan aterfinnas ne-dan.



TSP: Ordet ar en forkortning av “Traveling salesman problem” som ar ett valkant pro-blem inom optimeringslaran. Det kan beskrivas som problematiken med att hittaden kortaste vagen genom ett givet antal stader med olika positioner. Ett problemvars komplexitet foljer fakultetes funktion och darmed blir valdigt svarlost for ettstort antal noder.

LKH “Lin-Kernighan heuristic”, detta ar i dagslaget den algoritm som lost det storstahandelsresandeproblemet nagonsin av alla befintliga algoritmer, narmare bestamten instans pa 85.900 noder [2].

6.5 Modulbeskrivning

Det finns manga satt att angripa areatackningsproblem, den gemensamma namnaren aratt resultatet nastan alltid blir en kompromiss mellan berakningkomplexitet och optima-litet. Via grundliga forstudier hittades LKH som ska ha en unik losnings-heuristik somgor den valdigt snabb. Enligt specifikationerna bor den darfor inte ha nagra problemmed att losa de aktuella problemen vars nodantal aldrig kommer overstiga cirka 2000noder eftersom den mojliga avsokningsarealen begransas av WIFI-anslutningens rackvidd(forutsatt att kameran har ett omfang pa minst 4m2).

Problemet kommer darav stallas upp som ett handelsresandeproblem dar noder fordelasut over tackningsarean. Hur val trajektorian utformas begransas darfor till kostnadsma-trisen som indirekt blir problemformuleringen, eftersom LKH utlovar en optimal losningutifran hur problemet formulerats. Fordelarna med detta blir aven att de flesta kriteri-erna som forbjudna omraden, omradesgranser och en stravan om trajektoriamonster kanimplementeras som straff direkt i konstnadsmatrisen.

Implementationen delas upp pa olika funktioner som ansvarar for att losa separata delarav huvuduppgiften att ta fram en trajektoria.

Linjesokning Vid linjesokning anvands enbart ett begransat antal av de funktioner-na som finns tillgangliga i modulen. Informationen skickas direkt till interpoleringen, seflodesschema i figur 18.

Areatackning Vid areatackning anvands samtliga funktioner i en ordning enligt flodesschemati figur 18.

6.5.1 Forbehandling

Eftersom modulen har som uppgift att losa olika typer av problem maste inobjektet tolkassa att ratt funktioner kan anropas.

Vid areatackning delas aven informationen upp i modulspecifika strukturer, dar koordi-nater for forbjudna omraden och omradeskoordinaterna laggs var for sig.

Insignal UppdragstypOmradeskoordinater alt. linjekoordinaterForbjudna omraden, koordinater

Utsignal FunktionsanropOmradesgranser (Koordinater)

Tabell 5: Signalflode for forbehandlingen



6.5.2 Polygrid

Funktionen tar emot koordinater som definierar det/de omraden som ska sokas av. Uti-fran dessa bestams en ovre respektive undre omradesgrans for latituden och longituden.Dessa bildar ett rektangulart omrade dar noder placeras ut efter ett forutbestamt an-tal per areaenhet, enligt tidigare resonemang kring WIFI-lankens rackvidd och kameranstackningsgrad bor detta vara runt 0.25 noder/m2.

I ett nasta steg skapas en eller flera polygoner beroende pa hur manga omraden som skasokas av. Darefter tas alla noder som ligger utanfor dessa bort. Sedan subtraheras avende noder som ligger i ett forbjudet omrade ifran losningen. Resultatet ar en lang arrayinnehallandes omradeskoordinater, dvs noder.

Insignal MonstertypOmradesgranser (Koordinater)

Utsignal Noder (i en array)

Tabell 6: Signalflode for polygrid

6.5.3 Kostnadsmatris

Denna funktion skoter all problemspecifiering da trajektorian formas utifran de kostna-derna som ar definierade har.

I ett forsta steg skapas en grundmatris utifran avstanden mellan noderna. Avstandetberaknas som en energi for att eliminera problemet med negativa avstand till foljd avnumeriska koordinater (ekvation 2).

LAT =

lat1 . . . latn...

. . ....

lat1 . . . latn

LON =

lon1 . . . lonn...

. . ....

lon1 . . . lonn

lat = 1, ..., n

lon = 1, ..., n

n = Antal noder

(1)

C =√

(LAT − LATT )2 + (LON − LONT )2 (2)

I ett andra steg studeras trajektoriamonstret med tre olika alternativ. Antingen meden stravan efter att flyga lattitudinellt, longitudinellt eller korsvis. Detta implementerasgenom att minska straffet for de nodpar som ligger pa samma latitud, longitud eller korsvis.For att snabba upp algoritmen undersoks enbart noder i anslutning till varandra samt attenbart den ovre triangeln behandlas, eftersom denna kan speglas da kostnadsmatrisen arsymmetrisk.

Slutligen kollas omradesgranser. Har studeras en eventuell skarning mellan nodpar ochforbjudna omraden alternativt yttre granser, detta illustreras i figur 19. En sadan skarningstraffas additativt sa att vagen mellan tva omraden ska fa likvardigt straff. I annat fallskulle algoritmen alltid strava efter att sluta sa nara ett annat omrade som mojligt avenom detta i meningen av antalet svangar inte skulle vara optimalt.



Figur 19: Omradet i gratt ar sokomradet, nodpar inom detta ar sammanbundna med gronalinjer. Det vita omradet i mitten ar ett forbjudet omrade och alla nodpar som korsar dettahar malats med roda linjer for att illustera att dessa ska straffas.

Insignal NoderOmradesgranser (Koordinater)

Utsignal Kostnadsmatris

Tabell 7: Signalflode for kostnadsmatris

6.5.4 TSP-algoritm

For losning av TSP-problemet kommer som tidigare namnt en extern funktion att anvandas(LKH) [2]. Denna ar en algoritm skriven i C-kod som kommer att anropas ifran Javapro-grammet. Utobjektet ar den sokta trajektorian.

Insignal KostnadsmatrisUtsignal Trajektoria (obehandlad)

Tabell 8: Signalflode for LKH

6.5.5 Interpolering

Denna funktion har tva huvuduppgifter, dels att jamna ut kurvor sa att trajektorian inteinnehaller nagra skarpa kanter samt att interpolera fram ett lampligt antal punkter somstammer overens med systemets uppdateringsfrekvens. Skarpa kanter tvingar plattformentill hastiga rorelser som kan generera stora vinkelutslag vilket i sin tur kan utlosa “Large



Angle Alarm”, en skyddsatgard som stanger av quadcoptern vid for stora vinklar. Darforar detta nagot som bor undvikas i basta mojliga man.

Uppgiften kommer att losas med kubiska spline-funktioner som binds samman med “knot-a-knot” andvillkor. Detta innebar att tredjederivatan ska vara samma vid varje nod, dvs.forandringshastigheten for kurvan blir densamma och darmed kommer trajektorian badefa mjuka kurvor och kunna interpoleras med valfri samplingsfrekvens [1]. Funktionen somska beskriva trajektorian, S(t) kan delas upp i tva subfunktioner beroende pa om de om-givande koordinaterna ligger i linje med varandra eller om trajektorian svanger i enlighetmed ekvation 3.

S(t) =

{kx+m, koord. i linje

a0x3 + a1x

2 + a2x+ a3, kurvor(3)

Insignal Trajektoria (obehandlad)Utsignal Trajektoria

Tabell 9: Signalflode for interpoleringen

Eftersom noderna ar utplacerade sa att hela omradet tacks under forutsattning att varjenod passeras minst en gang kommer interpolationen inte att paverka tackningsgraden.Detta eftersom funktionen S(t) ar uppdelad pa intervall mellan varje nodpar i trajekto-rian. Intervallens olika funktioner ar darav baserade pa “knot-a-knot”-andvillkoren ochnodernas position, varpa deras existens i den slutgiltiga trajektorian kan garanteras.



6.5.6 Tidsberakning

I tidsberakningen utvarderar modulen hur lang tid uppdraget kan forvantas ta, detta ar foratt sakerstalla att uppdraget ar genomforbart med den batterikapacitet som plattformenhar. Tiden for uppdragen blir en relativt vag skattning som baserar sig pa trajektoriansdistans och den hastigheten som plattformen uppskattas kunna halla beroende pa dess ut-formning. Da Uppdragsutforandet forvantas ta langre tid for en valdigt kurvig trajektoriakommer den forvantade hastigheten att anta olika magnituder beroende pa trajektoriansgradient. Tre stycken olika hastigheter kommer att anvandas dar den forsta ar for rak-strackor, den andra for svaga kurvor och den tredje for skarpa kurvor, se ekvation 4 darT ar troskelvarden. Darefter kan tiden integreras fram enligt ekvation 5. Den beraknadetiden syftar enbart till att ge en uppfattning om hur vida det ar mojligt att genomforadet planerade uppdraget, beslutet lamnas saledes at operatoren.

v(t) =

v1 , om 5 S(t) ≤ T1v2 , om T1 ≤ 5S(t) ≤ T2v3 , om 5 S(t) ≥ T2

(4)

t =

∫ s

0

s

v(t)dt (5)

Insignal TrajektoriaUtsignal Tidsskattning

Tabell 10: Signalflode for tidsskattning



7 Uppdragsfoljning

Uppdragsfoljningsmodulen har som uppgift att lasa av referensdata, berakna styrsignaleroch skicka tillbaka dessa till huvudbussen. Informationen mellan huvudbussen och modu-len specificerar ej vilket uppdrag som utfors utan bestar endast av referensdata. Modulenhar darfor ingen vetskap om vilken typ av uppdrag som utfors utan beraknar endast styr-signaler fran den indata som erhalls. Darav bestar uppdragsfoljningsmodulen enbart aven reglerkrets med insignaler i form av referensdata och tillstand, och utsignal i form avstyrsignaler. Alla signaler som uppdragsfoljningen kommer arbeta med finns specificeradei tabell 11.

Regulatorstrukturen kommer besta av flertalet P-regulatorer kopplade pa sadant satt attonskade egenskaper uppnas. Eftersom reglering av position med hjalp utav hastigheter avnaturen ar integrerande racker enbart P-regulatorer for uppgiften. For att regulatorsyste-met ska fa ratt referenssignaler och alla koordinater ska bli bekraftat avsokta kommer enforbehandling av referensdatat att implementeras, kallad waypointmanager.

Insignal TillstandPosition, [Xgps, Ygps]Hastighet, [x, y]Euler vinklar, [φ,θ]Hojd, [h]Yaw, [ψ]ReferensdataReferensposition, [Xgps,ref , Ygps,ref ]Referenshojd, [href ]Referensyaw, [ψref ]

Utsignal StyrsignalerPitch, [θref ]Roll, [φref ]

Yawrate, [ψref ]

Vertikal hastighet, [h]

Styrsignaler (for debugging)

Position, [Xgps,u, Ygps,u]Hastighet, [xref , yref ]

Tabell 11: Signalflode Uppdragsfoljningsmodulen

7.1 Sprak och program

Modulen kommer att skrivas i Java. Detta ar dock nagot som kan komma att andrasberoende pa hur det ovriga systemet utformas da modulen i sig inte ar last till nagotspecifikt sprak.

7.2 Regulatorstrukur

Regulatorkretsen kommer besta av sju stycken P-regulatorer vilka till viss del kommer lig-ga i serie och till viss del parallellt. Regulatorerna bestar av: hojd-, positions-, hastighets-,



pitchvinkel-, rollvinkel- och yawreglering. Kretsen ar uppbyggd sadan att utsignal franpositionsreglering ar en hastighet och saledes ocksa insignal till hastighetsreglering, utsig-nal fran hastighetsreglering ar en roll- och pitchvinkel som i sin tur ar insignal till roll-och pitchvinkelreglering, dessa regulatorer ligger alltsa i serie. Parallellt med dessa liggerhojd- och yawvinkelreglering. En oversiktsbild av regulatorstrukturen gar att beskada ifigur 20.

I positionsregleringen kommer en enkel funktion att omvandla hastigheter i N-frame ko-ordinatsystemet till plattformens eget koordinatsystem, B-frame. Omvandlingen kommerske enligt ekvation (6)

[xy

]=

[cos(ψ) sin(ψ)− sin(ψ) cos(ψ)

]·[N

E

](6)

Figur 20: Regulatorskretsen uppdelad i alla delblock for att askadliggora regulatorstruk-turen.

7.3 Referensvaljare

Referenssignaler i position, hojdled och yawvinkel kommer genomga en viss forbehandlinginnan de anvands av regulatorerna. Forbehandling ar menad att se till att ratt data garvidare till regulatorsystemet och alla referenskoordinater kommer bli nadda. Ett exempelpa hur referensvaljaren kommer arbeta finns presenterad i figur 21.



Figur 21: Ett flodesschema over hur referensvaljaren kommer arbeta och bestamma vilkakoordinater som ska skickas vidare som referens.



8 Signalbehandling

Signalbehandlingsmodulen har till uppgift att med tillgang till all sensordata skatta platt-formens position. Signalbehandlingsmodulen kommer sensorfusionera plattformens in-byggda troghetssensor med en GPS for positionsbestamning. Det skulle ge en mojlighetatt erhalla en hogre uppdateringsfrekvens an om endast en enskild GPS skulle anvandas.

Sensorfusionen ar amnad att kunna kombinera de olika fordelarna hos de tillgangligasensorerna. GPS har hog precision men lag uppdateringsfrekvens (≈ 1 Hz) och kraverkontakt med minst tre stycken satelliter for att fungera. Troghetssensorn ar tvart emothelt lokal pa plattformen och kraver ingen yttre kontakt for att fungera (undantagetWIFI-kommunikation for att sanda sensordata). For att skatta position med hjalp av entroghetssensor kravs att accelerometern integreras tva ganger och fel adderas darfor in iskattningarna. Fordelen ar att sensorn har en mycket hog uppdateringsfrekvens och kanleverera ca 200 matpunkter i sekunden (≈ 200 Hz). Onskemalet ar darfor kombineraGPS:ens hoga precision med troghetssensorns hoga uppdateringsfrekvens och pa sa satterhalla bra positionsskattningar med en hog uppdateringsfrekvens och aven att kunnaskatta positionen trots att GPS-kontakt forloras for en kort stund. For att klara uppgiftenmed sensorfusion kommer ett kalmanfilter att implementeras. Det kommer aven kravas atttransformationsmatriser tas fram for att relatera de olika koordinatsystemen som anvandstill varandra. Pa detta satt kan all nodvandig data utnyttjas.

Amplitudskattningen kommer att realiseras genom en lagpassfiltrering av hojdsignalenfran plattformen som redan ar en fusion mellan sonarn, bildbehandlingen och barometern.Eftersom systemet enbart anvander hojden over marken ar bedomningen att plattformensskattning ar tillracklig da GPS:en inte kan tillfora nagot till denna storhet, varpa det intefinns nagon anledning att forflytta denna funktionalitet utanfor plattformen.

Signalen lagpassfiltreras for att eliminera snabba hojdforandringar som exempelvis ettforemal pa marken skulle kunna ge upphov till. Eftersom systemet enbart ar designatfor att soka av omraden med relativt platt terrang sasom exempelvis en ang eller fot-bollsplan kommer filtreringen inte att ta bort nagon kritisk information for navigeringen.Hinder av storre karaktar som eventuellt skulle kunna stora uppdragets trajektoria somar definierad med en frihojd over marken maste malas upp som ett forbjudet omrade viduppdragsutformningen. Darav kommer en lagpassfiltrering inte att orsaka nagon ovantadinformationsforlust som i sin tur leder till en krasch.


Modulen kommer att skrivas i Java. Detta ar dock nagot som kan komma att andrasberoende pa hur det ovriga systemet utformas da modulen i sig inte ar last till nagotspecifikt sprak.

8.2 Kalmanfilter

Det finns tva olika satt att skatta position med hjalp av en sensorfusion mellan troghetssensornoch GPS. Det ena och lattare sattet ar att anvanda sig av hastighetsdata och eulervinklarfran plattformens egna interna skattning. Skattningarna bygger troligtvis pa en sensorfu-sion mellan alla tillgangliga sensorer pa plattformen och direkt atkomst till radata frantroghetssensorn ar inte nodvandigt. Anvands det sattet kan fusionen ske med ett vanligtkalmanfilter da eventuella olinjariteter behandlas internt pa plattformen. Skulle detta intege en tillrackligt bra skattning ar det andra alternativet att anvanda radata direkt frantroghetssensorn. Da kravs emellertid att fusionen sker med hjalp av ett extended kalman-



filter da diverse olinjariteter maste tas om hand om. Det senare alternativet innebar enmer komplex losning pa problemet och kommer inte undersokas narmare forran det arbekraftat att det forsta alternativet ej ger ett tillfredsstallande resultat.

Insignal TillstandHastighet, [x, y]Euler vinklar, [φ,θ]Hojd, [h]Yaw, [ψ]GPS-position, [YGPS , XGPS ]Ev. radata fran troghetssensorn

Utsignal Skattade tillstand

Position, [XGPS , YGPS ]

Hastighet, [ ˆNGPS ,ˆEGPS ]

Tabell 12: Signalflode for signalbehandlingsmodulen



9 Kommunikation

I detta kapitel beskrivs hur kommunikationsmodulen ska designas och anvands mellanplattfromen och huvudbussen.

9.1 Inledning

Mellan plattformen och huvudbussen sa finns det en tradlos lank som skoter dataoverforin-gen. Denna opererar pa 2.4Ghz bandet och har en teoretisk dataoverforingshastighetpa upp till 300mbit/s om klienten stodjer detta. Standarden som anvands antas varatillrackligt for projektets specificerade applikationer. Natverket ar av typen b/g/n, vilketinnefattar standardprotocoll och kan anvandas av flertalet olika klienttyper, t.ex Android,Windows och Linux.

9.2 Overgripande Design

Kommunikationsmodulens uppgift ar att hantera data som skickas fran plattformen/ser-versidan, till klientsidan som vidarebefordrar informationen till huvudbussen. Det gene-rella upplagget ar att sjalva serversidan ar den befintliga AR.Drone-programvaran somanvander sig av specifika kommunikationsprotokoll specificerade i figur 22. Det som skallupprattas ar programvaran till klientsidan som genomfor kommunikation med server-sidan.

Figur 22: Forklaring av kommunikationen som sker mellan klienten och servern.

For att kontrollera och konfigurera plattformen skickas AT-kommandon till adressen viaUDP pa port 5556. Navigationsdata skickas fran plattformen till klienten pa port 5554via UDP. Navigationsdatan innehaller alla sensordata och status for plattfomen och haren uppdateringsfrekvensdata mellan 15Hz och 200Hz.

Videostrommen fran plattformen skickas till klienten pa port 5555 via TCP. En fjardekommunikationskanal, kontroll-porten kan etableras pa port 5559 via TCP dar kritiskdata hanteras.




Kommunikaitionslanken ar en fristaende modul gentemot plattformen och huvudbussenoch skall kunna ersattas av motsvarande modul. Kommunikationsmodulen kommer skrivasi Java for enkelhetens skull da det har valts som standard for ovrga moduler och medforstandardiserat satt att integrera med huvudbuss.

9.4 Termonologi

UDP: User Datagram Protocol ar ett forbindelselost protokoll for att skicka datagramover IP-natverk.TCP: Transmission Control Protocol ar ett forbindelseorienterat protokoll for palitligadatastrommar mellan tva datorer.AT−Commands: AT-Commands ar en standard for kommunikation over natverk darett kommando initieras med AT foljt av kommando.

9.4.1 Server-sidan

Serversidan bestar av befintlig AR.Drone programvara, vilket tar emot AT-kommandonpa specifika portar definierade i figur 22. Dessa kommandon ar listade nedan:

AT-Command Options BeskrivningAT*REF input Lyfta/Landa/NodstopAT*PCMD flag, roll, pitch, yaw Kontrollera plattformen.AT*FTRIM - Staller referens for horisontalplanAT*CONFIG key, value Konfigurera AR.DroneAT*LED Frekvens, tid Kontrollera LED-animation pa AR.DroneAT*ANIM AT*ANIM Skapa en flyganimation pa AR.DroneAT*COMWDG - Resetta kommunikationens overvakning

Efter initiering sa skickar aven serversidan information i form av tillstandsinformationover 2 olika kanaler, enligt figur 22.

9.4.2 Klient-sidan

Klientsidan bestar av ett Java-program som skoter kontakten mellan klienten och ser-vern. Klientens uppgift ar att ta emot och skicka styrsignaler och navigationsdata mellanhuvudbussen och plattformen.



Figur 23: Flodesschema for att initiera kommunikationslank

For att initiera kontakten mellan klient/server-sidan kravs det att en initieringssekvensgenomfors, se figur 23.

9.5 Tillstands-data

For att kunna genomfora reglering kravs att foljande data skickas till huvudbussen forvidarebefordring:

• Hastighet, [x, y]

• Euler vinklar, [φ,θ,ψ]

• Hojd, [h]

• GPS-position, [Ygps, Xgps]

• Radata accelerometer sensor

Dessa data har hogsta prioritet och kommer kora med en uppdateringsfrekvens som ardet maximala vad plattformen kan leverera, vilket ar 200Hz. Daremot finns det vissa be-gransningar i sensorerna. GPS-modulen har en uppdateringsfrekvens pa endast 1Hz vilketbegransar antalet datapunkter for positionering. Resterande sensorer; gyro,accelorometer,barometer, sonar har en tillrackligt hog uppdateringsfrekvens for specificerade onskemal.

9.6 Referens/styr-signaler

For att styra plattformen sa skickas referenssignaler fran huvudbussen, vilket ar givetnedan:

• Pitch, [θref ]

• Roll, [φref ]



• Yaw, [ψref ]

• Vertikal hastighet, [h]

Dessa ar ocksa av hogsta prioritet och kommer att skickas med uppdateringsfrekvens pa200Hz, precis som utsignalerna. Fran huvudbuss-modulen kommer dessa att skickas franklient-sidan till serversidan for behandling.

Vid manuell styrning kommer styrsignalerna fran regulatorn att ersattas med styrsignalerfran valfri kontrollenhet, sa som joystick/telefon/tangentbord.

9.7 Videostrom

Nedan beskrivs hur videostrommen overfors och sedan avkodas.

Figur 24: Flodesschema for initiering av videostrom

Figur 24 visar initieringssekvensen for att starta en videostrom mellan palttform ochklient.

9.7.1 Avkodning

In: Bildstrom via en portUt: Avkodad bild i BGR-skala

Avkodning ska ske via ett ffmpeg-bibliotek, t.ex. ffmpeg-java1. Avkodaren oppnar en portfor videostrommen och hittar ratt codec for avkodning. Avkodaren leverar bild i BGR-format som gors om till OpenCV:Mat-format vilket kan hanteras i bildbehandlingen.

9.8 Rackvidd

Den tradlosa lankens rackvidd anses vara en begransande faktor och i dagslaget sa upp-skattas den till ungefar 50 meter. Rackvidden kan forstarkas med hjalp av en router vilketkommer goras om 50 meter inte racker till for att fa en tillfredstallande funktion pa slut-produkten.

1 http://fmj-sf.net/ffmpeg-java/getting started.php



10 Plattform

Den plattformen som anvands ar en standard AR.drone 2.0. Det ar en typ av multirotormed fyra stycken rotorer och ett ARM-baserat styrsystem med Linux som operativsystem.Plattformen har som standard en kamera vinklad i horisontalplan framat och en vinkladlodratt nedat. Det ARM-baserade styrsystemet forlitar sig pa inbyggda accelerometraroch gyron for att stabilsera quadcoptern och en barometer och sonar for att reglera hojd.

10.1 Forandringar

For forbattrad bildbehandlingsprestanda kommer den kamera som ar vinklad horisonteltframat att modifieras for att kunna vinklas nedat da denna har hogre upplosning an denkamera som ar fast monterad under plattformen.

Plattformens mjukvara ar last och kommer inte att modifieras.



11 Sakerhetatgarder

Da plattformens mjukvara innefattar viss felhantering, far delar av sakerhetsatgardernavara forlitade pa de inbyggda systemen. T.ex. maste plattformen fa minst 2 kommandonmed mindre an 2 sekunders mellanrum for att inte tappa anslutningen. Om anslutningenforloras kommer plattformen att hovra tills anslutning upprattas eller tills batteriet arlagt vilket kommer initiera att plattformen landar.

Pa GUI:et kommer ett nodstopp att genomfora totalt stopp av samtliga moduler genomatt skicka kommando fran GUI:et genom huvudbussen till kommunikationsmodulen ochsom skickar ett AT*REF for nodstopp till plattformen. Denna sekvens skall alltid haprioritet.

Da totalt nodstopp inte ar nodvandigt annat an vid akuta behov kommer ett mjuktnodstopp finnas dar alla moduler utom kommunikation och GUI ar inaktiverade och darstyrsingaler tas manuellt ifran inmatning i GUI alternativt att AT*ref skickas for att hovraoch AT*REF for landning skickas.

Da batteristatus visas i GUI kommer operatoren att meddelas nar denna narmar sig enkritisk niva och nar en viss batteriprocent nas kommer en inbyggd sakerhet hos plattfomeninitiera en landning.

Det kommer finnas en startsekvens som ligger under huvudbussen som vid varje uppstartgenomgar en kontroll av samtliga moduler, sensorer och GPS status och uppkoppling tillsatelliter. Om nagon modul, sensor eller for fa satelliter hittas skall det inte ga att startaett autonomt program.



Referenser

[1] Elden, L. och Wittmeyer-Koch, L., “Numeriska berakningar”, analys och illustratio-ner med MATLAB, pp. 126-143, 2011.

[2] Helsgaun, K., “Writings on Computer Science”, An Effective Implementation of theLin-Kernighan Traveling Salesman Heuristic., No. 81, 1998.

[3] KvaddaKopter, “Autonom spaning med quadcopter” Kravspecifikation, September2014.

[4] Stephane Piskorski, Nicolas Brulez och Pierre Eline L., “AR.Drone Developer Guide”,Developer Guide, Maj,2011.

[5] FFMPEG-Java, http://fmj-sf.net/ffmpeg-java/getting started.php, Okt,2007

[6] Method to Detect and Track Moving Object in Non-static PTZ Camera, Proceedingsof the International MultiConference of Engineers and Computer Scientists 2013 VolI, IMECS 2013, March 13 - 15, 2013, Hong Kong

[7] Color detection using OpenCv, http://opencv-srf.blogspot.se/2010/09/object-detection-using-color-seperation.html, Sep,2010


Documents

Designspeci kation Autonom spaning med quadcopterDesignspeci kation 2014-10-19 [email protected] Autonom spaning med quadcopter 3 2 Oversikt av systemet Den f ardiga produkten