Designspecifikation Autonom spaning med quadcopter

Transkript

1 Designspecifikation Autonom spaning med quadcopter Version 1.0 Projektgrupp: Datum: Status Granskad MP Godkänd Christian A. Naesseth Designspecifikation

2 Projektidentitet E-post: Hemsida: Beställare: Kund: Kursansvarig: Christian A. Naesseth, ISY, Linköping University Tel.: , E-post: Maria Andersson, FOI E-post: Daniel Axehill, Linköpings universitet Tel.: , E-post: Clas Veibäck, Linköpings universitet Tel.: , E-post: Gruppmedlemmar Namn Ansvar Telefon E-post Magnus Blomberg Designasnvarig magbl113 Tobias Hammarling Testansvarig tobha614 Teodor Johnsson teojo382 Emil Klinga Projektledare emikl364 Oliver Larsson olila044 Anton Niglis antni601 Martin Pettersson Dokumentansvarig marpe238 Per Öberg perob757

3 Dokumenthistorik Version Datum Utförda ändringar Utförda av Granskad Komplettering av kommentarer MP,OL MP från BP Andra utkast efter kommentarer MP från handledare Första utkast Designspecifikation

4 Innehåll 1 Inledning Parter Projektets bakgrund Syfte och mål Kortsiktigt mål Långsiktigt mål Användning Definitioner Översikt av systemet Styrmoder Koordinatsystem Huvudbuss Övergripande design Gränssnitt GUI/HMI Program och språk Övergripande design Layout för uppdragsplanering Uppdragstyper Layout för uppdragsföljning Kartor Google Maps API Gmaps FX Bildbehandling Inledning Övergripande design Språk och bibliotek Terminologi Måldetekteringsmoduler Målbildsmatchning Färgmatchning Bakgrundssubraktion Stödfunktioner Kalibrering Bildkvalitetsbestämning Målföljning Målföljning med multipla mål Uppdragsplanering Inledning Övergripande design Program och språk

5 6.4 Terminologi Modulbeskrivning Förbehandling Polygrid Kostnadsmatris TSP-algoritm Interpolering Tidsberäkning Uppdragsföljning Språk och program Regulatorstrukur Referensväljare Signalbehandling Språk och program Kalmanfilter Kommunikation Inledning Övergripande Design Språk och program Termonologi Server-sidan Klient-sidan Tillstånds-data Referens/styr-signaler Videoström Avkodning Räckvidd Plattform Förändringar Säkerhetåtgärder 39 Designspecifikation

6 Autonom spaning med quadcopter 1 1 Inledning Detta är en designspecifikation i projektet Autonom spaning med quadcopter. Projektet görs i samband med kursen TSRT10 - Reglerteknisk projektkurs på ISY, Instutitionen för systemteknik, på Linköpings universitet. Dokumentet presenterar de tillvägagångsätten som är ämnade att användas för att lösa de uppgifter som följer av kraven i kravspecifikationen [3]. 1.1 Parter De delaktiga parterna i projektet är som följande: Kund: Maria Andersson, FOI Beställare: Christian A. Naesseth, ISY Handledare: Clas Veibäck, ISY Examinator: Daniel Axehill, ISY Projektgrupp: 1.2 Projektets bakgrund Intresset för autonoma och obemannade farkoster (UAV:er) har på senare tid vuxit enormt. Möjligheterna som lockar är att kunna utföra speciella typer av uppdrag som är för farliga, eller av annan anledning, olämpliga för människor. Den kanske vanligaste typen av uppdrag är spaning. UAV:n är då utrustad med olika sensorer för att samla in data för den specifika tillämpningen. Detta skulle till exempel kunna vara övervakning av kritisk infrastruktur eller överblicksbilder vid nödsituationer. Farkosten skulle i dessa fall vara ett välkommet inslag för att minska mänskliga fel och målet är att den fungerar så väl att den frigör operatören till att göra annat. 1.3 Syfte och mål Syftet med projektet är att tillämpa inhämtade kunskaper för att skapa en produkt på ett tillvägagångsätt liknande hur arbetet sker i arbetslivet. Projektet ska användas för att ge projektets medlemmar en chans att lära sig mer om hur projektarbete går till samtidigt som kunden får en produkt som har reella användningsområden. Projektets mål kan delas upp i kortsiktiga och långsiktiga mål Kortsiktigt mål Det kortsiktiga målet med detta projekt är att utveckla en demonstrator för enklare högnivåautonomi. Plattformen ska vara baserad på en quadcopter med tillgång till GPSoch strömmad videodata i realtid. Projektet består i att utveckla och implementera funktionalitet, baserat på en quadcopterplattform, för: Att planera ett autonomt uppdrag där plattformen söker av ett område runt en given koordinat efter mål. Designspecifikation

7 Autonom spaning med quadcopter 2 Att planera ett autonomt uppdrag där plattformen övervakar och detekterar mål längs en given sträcka eller i ett givet område. Att utföra planerade uppdrag. Att detektera mål i sensordata som levereras från plattformen då den utför ett uppdrag. Att i mån av behov utföra enkel målfölning av detekterat mål Långsiktigt mål Det långsiktiga målet med projektet är att skapa en bas för en FOI-demonstrator som kan användas för att visa på möjligheterna och nyttan med olika typer av autonom UAVfunktionalitet. Plattformen och den struktur som byggs upp kan även användas för att utveckla och testa nya typer av autonoma funktioner, algoritmer för måldetektion och alogritmer för målföljning eller flera samverkande plattformar. 1.4 Användning Slutprodukten kommer att användas för att demonstrera användningsområden inom autonom spaning med en UAV i form av en quadcopter. Tanken är att FOI efter projektets avslutande ska kunna använda produkten som demostrator samt som en bas för vidareutveckling. Med anledning av detta kommer mjukvaran skrivas så att detta blir så enkelt som möjligt. 1.5 Definitioner I dokumentationen av projektet kommer flertalet områdesspecifika begrepp att användas. Dessa är punktade nedan med tillhörande beskrivning. Plattform: Trajektoria: Standardmål: Täckningsgrad: GUI/HMI: GPS: Med plattform avses quadcoptern sammanlänkad med GPS och videokamera som en enhet. Den kurva som plattformen har som mål att följa vid autonom styrning. Enkla geometrier som bildbehandlingsmodulen klarar av att känna igen. Andelen av en yta som blivit avsökt. Grafiskt användargränssnitt. (eng. Graphical User Interface, Human Machine Interface) Globalt positionssystem Designspecifikation

8 Autonom spaning med quadcopter 3 2 Översikt av systemet Den färdiga produkten ska möjliggöra för en quadcopter att utföra enklare spaningsuppdrag autonomt. I denna kedja ingår uppdragsplanering, uppdragsföljning, reglering samt bildbehandling för måldetektion. Produkten kan i grova drag delas upp i komponenter enligt figur 1. Varje block i schemat har en specifik uppgift där tanken är att varje modul ska kunna utvecklas och fungera separat. Pilarna i figuren representerar beroenden och kommunikationsvägar. I tabell 1 visas en kort förklaring till modulernas ansvarsområden. Figur 1: Övergripande flödesschema för systemets generella upplägg 2.1 Styrmoder Systemet kommer ha två olika styrmoder för plattformen. Den första är full autonom flygning. Autonom flygning kräver tillgång till GPS-signal för att initieras och är således menad för utomhusflygning endast. Vid autonom flygning används uppdragsföljningsmodulen för styrning av plattformen och uppdragsplanering för att generera referenssignal. Den andra moden är manuell styrning, menad för flygning inomhus och eventuella tester utomhus. Manuell styrning ska kunna initieras när som helst under både flygning inomhus och utomhus och görs genom GUI. När manuell styrning initieras förbikopplas uppdragsplanering- och uppdragsföljningsmodulen, styrsignaler erhålls då istället av en joystick. Plattformen kommer därför inte ha någon autonom förmåga vid inomhusflygning. Designspecifikation

9 Autonom spaning med quadcopter 4 Modul Huvudbuss Kommunikation Signalbehandling Bildbehandling Bildavkodare Uppdragsplanering Uppdragsföljning GUI Kartor Lagring Ansvarsområde Kommunikationslager mellan alla systemets moduler. Sköter kommunikation mellan plattformen och huvudbussen. Möjliggör skattning av fysikaliska tillstånd. Använder insamlad videoström för att lokalisera mål. Ser till att bildbehandlingen har rätt datatyp. Tillhandahåller referenssignaler till uppdragsföljningsmodulen. Beräknar styrsignaler till plattformen från givna referenssignaler. Interaktiv planering och utförande av spaningsuppdrag. Tillgodoser GUI med översiktskartor för planering. Möjliggör persistens av data, t.ex. planerade uppdrag, kartor och konfiguration. Tabell 1: Systemets olika moduler och ansvarsområden. 2.2 Koordinatsystem I dokumentet kommer tre olika koordinatsystem att användas för att kunna beskriva alla olika tillstånd och uppkomna situationer. De fyra olika koordinatsystemen är WGS-84, N-frame, B-frame och T-frame vilka går att betrakta i figur 2 och är definierade enligt följande. WGS-84 är koordinatsystemet som används för att beskriva position med GPS koordinater och är definierad efter jordens geometri. WGS-84 är utskrivet som X gps, Y gps där X = longitud, Y = latitud och H = altitud. Navigation frame (N-frame), är ett lokalt koordinatsystem på plattformen som inte följer plattformens rörelser. Det är utifrån denna som yawvinkeln är definierad. N-axeln pekar alltid mot norr, E-axeln mot öster och D-axeln nedåt. Navigation frame är utskrivet som N, E, D. Tracking frame (T-frame), är ett lokalt koordinatsystem med samma riktningar som Navigation frame men med origo fixt i plattformens startpunkt. Body frame (B-frame), är även det ett lokalt koordinatsystem på plattformen. Detta koordinatsystem följer plattformens rörelser och vinklar och är definierad efter plattformens geometri. Koordinatsystemet har x-,y och z-axlarna pekandes rakt fram, åt höger och rakt ner (dessa kallas även roll- tipp- och giraxel), genomgående i rapporten kommer dock de engelska beteckningarna användas (roll, pitch och yaw). Bodyframe är utskrivet som x, y och z. Designspecifikation

10 Autonom spaning med quadcopter 5 Figur 2: Övergripande figur som visar hur de tre olika koordinatsystemen hänger ihop. GPS koordinater är definerade på sfären (föreställande jordklotet), bilden till höger visar en 2-dimensionell bild över hur N-frame och E-frame ligger i varandra men kan ha olika riktningar då D-axeln och z-axeln ligger i varandra. Designspecifikation

11 Autonom spaning med quadcopter 6 3 Huvudbuss Huvudbussen är kärnan för hela systemet och är den första modul som initieras när mjukvaran startas och hålls vid liv under hela den tiden programmet är igång. Modulen är initialt ansvarig för att starta alla systemets övriga komponenter och fungerar sedan som ett kommunikationslager mellan dessa. Flödet för huvudbussens aktiviteter kan ses i figur 3. Figur 3: Flödesschema för huvudbussens två uppgifter. Initiera moduler och tillgodose moduler med svar på de frågor de har. 3.1 Övergripande design Huvudbussen kommer i implementationen vara ett enda objekt vars yttersta och enda ansvar är att skicka vidare data mellan systemets olika komponenter. Med denna struktur uppnås en hög grad av modularitet då modulerna inte har någon som helst vetskap om varandra. Alla frågor en komponent har till det övriga systemet sker via huvudbussen och denna ser då till att svara på ett korrekt sätt. Bussen kommer av denna anledning behöva implementera ett gränssnitt för att alla möjliga kommunikationsvägar ska vara entydigt definierade. Huvudbussen ska vara ett trådsäkert objekt då flera moduler (som körs i separata trådar) kan försöka skriva/läsa samma variabel. 3.2 Gränssnitt För att veta hur huvudbussen ska svara på olika frågor kommer denna vara tvungen att implementera ett gränssnitt (eng. interface). Antag scenariot beskrivet i figur 4 och antag för enkelhetens skull att GUI bara behöver veta aktuell hastighet för plattformen och frågar därför huvudbussen om denna information. Huvudbussen returnerar då värdet på sin egen medlemsvariabel. Värdet som huvudbussen har tillgång till ska hållas uppdaterad av kommunikationsmodulen. Hur dessa värden sätts är definierade i ett gränssnitt. Designspecifikation

12 Autonom spaning med quadcopter 7 Figur 4: Flödet då en modul behöver ställa en fråga till en annan modul. I detta fall skulle huvudbussen behöva implementera ett gränssnitt MainBusInterface enligt kodutsnitt 1. Dessa gränssnitt definierar fullständigt kommunikationen mellan de två komponenterna så att det inte råder något tvivel om hur detta ska gå till. Förutom att detta ger moduläritet och tydlig dokumentation om vilka frågor som kan ställas ger det också en extra kontroll då modulerna kompileras. Skulle en modul inte uppfylla ett gränssnitt går koden inte att kompilera och kompilatorn talar om vad som inte är uppfyllt. Kodutsnitt 1: Exempel på ett gränssnitt. 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) ; } } På detta sätt kommer gränssnitt behöva skapas för samtliga moduler. Ett gränssnitt implementeras av modulerna själva och ett implementeras av huvudbussen. En fullständig lista över de gränssnitt som behöver skapas kan ses i tabell 2. Gränssnittets namn MainBussInterface GUIInterface StorageInterface CommunicationInterface ImageProcessingInterface SignalProcessingInterface MissionPlannerInterface MissionControlInterface Tabell 2: Alla nödvändiga gränssnitt. Förutom dessa kommer alla moduler även tvingas implementera ett mer generellt gränssnitt ModuleInterface. Detta ska tvinga alla moduler att ha gemensamma metoder för att Designspecifikation

13 Autonom spaning med quadcopter 8 hantera mer generella uppgifter som att starta och stoppa modulen. Detta ger huvudbussen möjlighet att hantera samtliga moduler utan att själv behöva veta exakt hur detta sker i varje enskild modul. Ett sådant gränssnitt kan ses i kodutsnitt 2. Kodutsnitt 2: Ett generellt gränssnitt för alla moduler. public interface ModuleInterface { void initialize (); void destroy (); //... } Varje modul kommer använda en egen tråd för att dessa ska köras parallellt. Modulerna kommer frekvent att skriva och läsa från huvudbussen och med denna anledning behöver huvudbussen göras trådsäker. Detta är en enkel uppgift i Java då primitiva datatyper är trådsäkra automatiskt och övriga typer görs trådsäkra genom att använda ett kodblock enligt kodutsnitt 3. Blocket fungerar som en vakt som bara låter en tråd i taget använda den kod som omsluts. Om flera trådar vill använda samma del samtidigt kommer en åtkommstkö automatiskt att upprättas. Kodutsnitt 3: Trådsäkerhet i Java. synchronized { // Thread safe code goes here... } Designspecifikation

14 Autonom spaning med quadcopter 9 4 GUI/HMI Modulen GUI/HMI är den modul som ansvarar för att visa slutanvändaren ett gränssnitt för att planera och följa uppdrag. 4.1 Program och språk För att snabbt och enkelt kunna bygga grafiska gränssnitt behövs någon form av grafikbibliotek. Sådana bibliotek finns till alla de stora språken (C++/Java/Python mm) men valet föll på Java FX. Detta bibliotek tillsammans med tillägget Screen Builder gör det mycket enkelt att bygga GUI:s med standardkomponenter som flikar, knappar, dialogrutor. Resultatet från byggandet är en XML-fil som med två rader kod kan importeras till en Java-applikation. 4.2 Övergripande design GUI:t har två huvudsakliga uppgifter, uppdragsplanering och uppdragsföljning. Slutanvändaren är bara intresserad att nå en av dessa delar i taget. Av denna anledning är det naturligt att dela in programmet i just dessa två delar. I användargränssnittet sker detta genom att ha två flikar (se figur 5) så att bara en av dessa kan visas i taget. Figur 5: Användargränssnittets huvudsakliga uppdelning. Denna uppdelning resulterar i två programklasser som representerar flikarna. Vardera klass är ansvariga för sin flik och all användarinteraktion med denna. Interaktion kan t.e.x vara klickande eller skrivandet av ny text i en textruta. Då interaktion med kartor utgör en så stor del av programmet bröts logiken för detta ut till två separata klasser. En lista över de fyra huvudklasserna för det grafiska användargränssnittet kan ses i tabell 3. Programklass PlanningController ExecuteMissonController PlanningMap MissionMap Ansvar Interaktion med planerings-fliken Interaktion med utförande-fliken Interaktion med planeringskartan Interaktion med karta under uppdrag Tabell 3: Användargränssnittets huvudsakliga programklasser. 4.3 Layout för uppdragsplanering Under fliken uppdragsplanering finns alla nödvändiga funktioner för att planera uppdrag. En skiss över flikens upplägg kan ses i figur 6. Under planeringen av ett uppdrag ska användaren ha möjlighet att specificera ett namn för uppdraget, vilken typ av uppdrag det handlar om samt från en lista med standardmål kunna välja ett objekt som plattformen ska leta efter. Här finns även alternativ för vilken höjd uppdraget ska utföras på. Designspecifikation

15 Autonom spaning med quadcopter 10 Figur 6: Schematisk skiss över användargränssnittet för uppdragsplaneraren. När den grundläggande informationen om uppdraget finns ska användaren via översiktskartan specificera relevanta GPS-koordinater för uppdraget. Exakt vilka typer av koordinater beror på vilken typ av uppdrag som valts (se avsnitt 4.3.1). Gemensamt för alla uppdrag är dock att förbjuda områden ska kunna specificeras. Detta görs genom att koordinater placeras ut som utgör en godtycklig polygons gränser. Under processen då koordinater placeras ut kan användaren när som helst välja ta bort koordinater från kartan som blivit fel. När detta är färdigt kan uppdraget i sin helhet sparas. När detta sker kommer ett objekt som representerar uppdraget skickas till huvudbussen för lagring. Flödet för denna process kan ses i figur 7. Figur 7: Signalflöde vid sparande av ett uppdrag Uppdragstyper Under planeringen ska användaren kunna specificera tre olika typer av uppdrag definierade enligt tabell 4. Indatan kan även kompletteras med koordinater för förbjudna områden. Uppdragstyp Avsökning runt punkt Avsökning längs bana Avsökning inom område Nödvändig indata En GPS-koordinat och sökradie. Lista med GPS-koordinater som definierar en bana. Lista med GPS-koordinater som definierar områdets gränser. Tabell 4: Användargränssnittets huvudsakliga programklasser. Designspecifikation

16 Autonom spaning med quadcopter Layout för uppdragsföljning När ett uppdrag har skapats och användaren bestämmer sig för att utföra detta används fliken uppdragsföljning. Här väljs ett tidigare sparat uppdrag i en rullista. Uppdraget presenteras på översiktskartan. För att starta uppdraget trycker användaren på knappen Starta uppdrag. Under uppdraget ska gränssnittet visa nödvändiga notifikationer, WIFI-status, GPSstatus, återstående tid, sträcka, videoström och plattformens position på en karta. När som helst under uppdraget ska användaren kunna trycka på Avsluta uppdrag. Figur 8: Schematisk skiss över användargränssnittet för uppdragsföljningen. 4.5 Kartor Översiktskartorna används vid planering och vid uppdragsföljning utgör en stor del av användargränssnittet. Användaren ska enkelt kunna scrolla runt på kartan, zooma, placera ut eller ta bort koordinater under planeringen och under utförandet även kunna följa plattformen på kartan då den flyger. För att underlätta detta arbete användes existerande bibliotek för att lägga grunden för denna funktionalitet. Ett mycket populärt API för detta är Google Maps Google Maps API Google Maps är ett mycket välbeprövat bibliotek som ges ut av Google. Dessa kartor har från början en hel uppsjö av funktionalitet som alldeles utmärkt passar projektets behov. Kartorna tar hand om klick -händelser för att placera ut markörer, ger möjlighet att växla mellan olika typer av kartor samt gör det mycket enkelt att utöka befintlig funktionalitet. Google Maps är dock skrivet i Javascript och är ursprungligen avsedd för att visas i webbläsaren. Då kartorna ska in-bäddas i en Java-applikation krävs någon form av kompatibilitetslager. Då Google maps använder Googles servrar kräver detta att kartorna laddas över internet. Kartorna kan dock sparas i en cache vilket gör dem tillgängliga offline. Designspecifikation

17 Autonom spaning med quadcopter Gmaps FX Gmapsfx är ett open source -bibliotek som fungerar som en översättare mellan Java och Javascript för Google Maps API. Biblioteket gör det möjligt att interagera med kartorna med ren Java-kod (Java FX) istället för att behöva skriva Javascript. Tyvärr är Gmapsfx fortfarande i sin linda och stödjer bara en bråkdel av API:t men detta verkar inte vara något problem då all funktion som krävs i projektet är inkluderad. En schematisk bild över signalflödena för kartmodulen visas i figur 9. Figur 9: Signalflöden för kartmodulen. Designspecifikation

18 Autonom spaning med quadcopter 13 5 Bildbehandling I detta kapitel beskrivs bildbehandlingsmodulens uppgifter och algoritmer för att utföra dessa. 5.1 Inledning Bildbehandlingsmodulen ska sköta det datorseende som krävs för att utföra uppdrag. Bildbehandlingsmodulens uppgift är att ur en bildström kunna detektera och följa specifika föremål. Syftet med denna del är att ge en övergripande insikt i hur bildbehandlingsalgoritmerna kommer att implementeras. Någon pseudokod presenteras ej utan funktionernas principiella utförande är i fokus. Detektering ska kunna ske med tre olika algoritmer. Färgmatchning kommer att användas för att detektera objekt med en specifik färg och beskrivs i avsnitt 5.6. Objekt ska kunna urskiljas genom jämförelse med en mall. Detta görs med målbildsmatchning som bygger på att jämföra intressepunkter från bildströmmen med intressepunkter i en mall-bild. Denna metod beskrivs i avsnitt Den tredje metoden som kommer att användas är bakgrundssubtraktion och används för att detektera föremål som rör sig. Genom att jämföra med tidigare tillstånd kan man på så sätt bedöma vad som är bakgrund och vad som har rört sig. Metoden beskrivs i avsnitt 5.7. Efter detektering ska målföljning utföras, denna algoritm är beskriven i avsnitt Bildbehandlingsmodulen ska även kunna kalibereras och bestämma bildkvalitet (hur mycket rörelseoskärpa det är). Dessa algoritmer är beskrivna i avsnitt respektive Grundläggande terminologi och bildbehandlingstermer som är bra att känna till beskrivs i avsnitt Övergripande design För varje bildruta, från videoströmmen, som ska behandlas används designen beskriven i figur 10. Beroenden framgår av kopplingarna. För att exempelvis målbildsmatchning ska kunna köras behöver förbehandling och extrahering av intressepunkter köras. Designspecifikation

19 Autonom spaning med quadcopter 14 Figur 10: Flödesschema för bildbehandling Under förbehandlingen kan exempelvis bildkvalitet skattas. De tre beskrivna detektionsmetoderna förklaras utförligare under respektive rubrik. De tre detektionsmodulerna har samma struktur på utsignalen varför målföljningen kan hantera de olika modulernas resultat. Utsignalen från modulerna innehåller bland annat position på detekterat mål och målets storlek. De måldetektioner som görs i de tre måldetekteringsmodulerna kan visualiseras utan att använda målföljningsmodulen. 5.3 Språk och bibliotek Bildbehandlingsmodulen utvecklas i Java med IDE:t Eclipse, detta kan dock komma att ändras om det framkommer att ett annat språk passar projektets helhet bättre. Bildbehandlingsbiblioteket OpenCV används för att utföra grundläggande bildbehandlingsoperationer för datorseende. 5.4 Terminologi Nedan beskrivs några grundläggande koncept som kommer att användas i bildbehandlingsalgoritmerna. Designspecifikation

20 Autonom spaning med quadcopter 15 Intressepunkter och Deskriptorer: Intressepunkt är en position i bildrymden. Till varje intressepunkt hör en så kallad deskriptor (feature på engelska). En deskriptor håller information om intressepunktens omgivning. Exempel på sådan information är ett histogram över färgvärdena på pixlar inom en radie kring intressepunkten. Deskriptorn kan också innehålla en sannolikhet för att intressepunkten ligger på en kant i bilden. Överensstämmelse: Ett mått på hur väl intressepunkters deskriptorer överensstämmer med det sökta intressepunkter hos objektets deskriptorer. SIFT: SIFT är en metod för att extrahera skal- och rotationsinvarianta intressepunkter. Morfning: Morfning innebär att pixelvärden i bilden ändras beroende på närliggande pixlar. Objekt kan expanderas och på så vis kan glapp fås bort. Objekt kan även kontraheras. Dessa metoder kallas erosion och dilation och är de enklaste morfologiska operationerna, men det finns fler. De olika operationerna används för att tydliggöra hur objektet ser ut. 5.5 Måldetekteringsmoduler Nedan beskrivs de detekteringsalgoritmer som kommer att användas i projektet Målbildsmatchning Målbilder analyseras för att beskriva intressepunkters omgivning i målbilden. Bilder från videoströmmen analyseras på liknande sätt. Intressepunkternas omgivning i de nya bilderna jämförs med målbildernas intressepunkter. Mängden liknelser i intressepunkter kan antas öka då ett mål, beskrivet av en målbild, finns i videoströmmen. In: Förbehandlad bild Ut: Måldata Figur 11: Flödesschema för målbildsmatchning Designspecifikation

21 Autonom spaning med quadcopter 16 Intressepunkter: Intressepunkter och deskriptorer för dessa tas fram i det initiala steget. Deskriptorerna kan tas fram med exempelvis SIFT. Överensstämmelse mot målbilder: Deskriptorerna jämförs med deskriptorer för målbilder och samband mellan dessa beräknas. Färdig: Om en tillräckligt stor andel matchningar finns i en målbild kan resultatet anses färdigt och en målbildsmatchning är klar. RANSAC: Om behov finns kan resultatet förbättras i RANSAC-steget. En slumpmässig mängd av överensstämmelser väljs. En transformering skapas från nuvarande intressepunkter till dess motsvarighet i målbilden. Mängden överensstämmelser som väl uppfyller transformeringen beräknas. Detta görs till dess att mängden överensstämmelser är tillräckligt stor. I slutsteget kan transformeringen beräknas med hjälp av alla överensstämmande intressepunkter för att förbättra resultatet. Transformeringen kan senare användas för att exempelvis markera ut en ram runt objektet alternativt en förutbestämd detalj i objektet. Målföljning: Informationen skickas vidare till målföljningsmodulen. 5.6 Färgmatchning Färgmatchning används för att detektera bilddata med en viss färg. Detta kan vara lämpligt om ett objekt med någon väldigt specifik färg ska detekteras mot en bakgrund med annan färg. T.ex röd boll mot grönt gräs i ett enkelt fall. Algoritmen för färgmatchning synliggörs i figur 12. In: Förbehandlad bild Ut: Måldata Designspecifikation

22 Autonom spaning med quadcopter 17 Figur 12: En schematisk bild över hur färgmatchningen kommer att ske. RGB till HSV: I algorithmens första steg förs färgskalan över till en mer lättbehandlad skala HSV, som står för (Hue-Saturation-Value) och är en cylindrisk representation av färgskalan. Tröskling av kanaler: I nästa steg trösklas HSV-kanalerna, vilket gör att enbart den önskade färgen tas fram. Trösklingen som görs beror på vilken färg som ska extraheras. Tröskelvärden för färger på de objekt som ska detekteras måste tas reda på. Morfning: Pixelvärden måste sedan morfas på rätt sätt för att få bort eventuella luckor och göra objektet mer igenkännligt. Formmatchning: En enkel formmatchning görs för att utesluta objekt som är väldigt olika till form. Avgränsande lådor: Varje objekt i rörelse representeras sedan av ett fyrkantigt område i bilden, en så kallad avgränsande låda. Varje avgränsande låda tilldelas också ett id. Målföljning: Extraherad information skickas vidare till målföljningsmodul. Designspecifikation

23 Autonom spaning med quadcopter Bakgrundssubraktion Denna metod används för att detektera och kunna följa objekt som befinner sig i rörelse. Metoden är illustrerad i flödesschemat nedan. Nedan följer också en beskrivning av varje delsteg i flödesschemat. In: Förbehandlad bild Ut: Måldata Figur 13: Flödesschema för Bakgrundssubtraktion Intressepunkter: I första steget extraheras intressepunkter med tillhörande deskriptorer ur den inkommande bilden. Överensstämmelse mot föregående bild: Sedan jämförs den nuvarande bildens deskriptorer med föregående bildens deskriptorer. Ur jämförelsen beräknas vilken intressepunkt i nuvarande bild som stämmer bäst överens med en intressepunkt i föregående bild. Transformation: Genom att undersöka hur intressepunkterna förflyttat sig kan man beräkna hur mycket kameran förflyttat sig. Kameraförflyttningen beskrivs här av Designspecifikation

24 Autonom spaning med quadcopter 19 en transformationsmatris. Med hjälp av transformationsmatrisen kan en del av den föregående bilden transformeras in i den nuvarande bildens koordinatsystem. (a) Bildtransformation (b) Bildtransformation Figur 14: Bildtransformation i två steg Bakgrundssubtraktion: En pixelvis subtraktion utförs mellan nuvarande bild och den transformerade föregående bilden. Subtraktionen kan endast genomföras på de område där bilderna överlappar. Om bilderna innehåller ett objekt i rörelse kommer objektet synas som en differans mellan bilderna. Morfning: Morfologiska operationer utförs på resultatet för att särskilja närliggande sammanhängande områden och förbättra deras utseende. Avgränsande lådor: Varje objekt i rörelse representeras sedan av ett fyrkantigt område i bilden, en så kallad avgränsande låda. Varje avgränsande låda tilldelas också ett id. 5.8 Stödfunktioner Nedan beskrivs de stödfunktioner som ska implementeras Kalibrering För kunna transformera positioner i 2D bildkoordinater till en 3D position behöver man ta fram en kameramatris. Vid kamerakalibreringen bestämmer man en kameramatris, vilken innehåller specifika parametrar för kamerahårdvaran. OpenCV erbjuder en kalibreringsfunktion som modulen kommer kunna använda sig utav Bildkvalitetsbestämning Innan detekteringsalgoritmerna används ska bildens kvalitet bestämmas i form av i fallet om hur mycket rörelseoskärpa det är i bilden. Detta görs genom att kolla kanter i bilden och hur breda de är. Algoritmen beskrivs av figur 15. Till gråskala: Bildkanalerna transformeras till gråskala. Sobelfilter: Ett sobelfilter används för att ta fram kanter i bilden Designspecifikation

25 Autonom spaning med quadcopter 20 Figur 15: Flödesschema för bestämning av bildkvalitet Hitta kantbredd: Lokala maximum i horisontellt och vertikalt led tas fram. Genom att gå igenom bilden kolonnvis respektive radvis. Skarpa kanter kommer ge höga lokala maximum och oskarpa kanter kommer ge breda låga lokala minimum. Medelvärde: Medelvärde på lokala maxima i horisontellt led respektive vertikalt led tas var för sig. På så vis fås ett mätvärde på estimerad skarphet i de olika leden. Beslut: Beslut fattas om huruvida bildkvaliteten är tillräckligt bra för att detekteringsalgoritmer ska kunna användas. Vad som är lämpligt trösklingsvärde testas fram Målföljning Målföljningsmodulen syftar till att förbättra följning och detektion av mål som befinner sig i bild under längre tid. Modulen har data över vilka mål som fanns i föregående bild. Nya detektioner matchas mot tidigare och mål kan därför följas över tid. Ett filter är applicerat på målens tillstånd och möjliggör därför en bättre skattning. Ett linjärt Kalmanfilter kan implementeras och lösa de grundläggande kraven. Till varje objekt finns information om position och hastighet i världskoordinater och bildkoordinater. Varje objekt har även ytterligare information om exempelvis färg, om detektionen är gjord med hjälp av färgmatchning. Koordinaterna beskrivs lokalt i T- frame. Designspecifikation

26 Autonom spaning med quadcopter 21 Figur 16: En schematisk bild över hur målföljningen kommer att ske. Tidsuppdatering av tillstånd: Under tidsuppdateringen uppdateras varje måls tillstånd enligt dess rörelsemodell. Jämföra objekt med tidigare tillstånd: Detekterade objekt jämförs med tidigare objekt och en koppling mellan tidigare och nya objekt bestäms. Mätuppdatering av tillstånd: De positionsmätningar som kan kopplas till ett objekt utgör mätningar för mätuppdateringssteget. Deras skattade nya 2D-bildposition korrigeras med hjälp av kameraförflyttningen som är beräknad i tidigare steg. Under mätuppdateringen uppdateras tillståndet för objekten med avseende på de nya mätningarna. De tre stegen visas grafiskt i Figur 17. (a) Tidssuppdatering från föregående tillstånd. (b) Mathching med detekterade objekt. Figur 17: Målföljning i tre steg (c) Bestäm och uppdatera tillstånd Målföljning med multipla mål Ett problem som uppstår med målföljning är att multipla mål kan överlappa varandra. Detta är endast ett problem då målen detekteras av samma modul eller då målen blir svåra att urskilja. Då multipla mål inte behöver hanteras enligt krav i kravspecifikationen löses möjliga problem endast i mån av tid. Designspecifikation

27 Autonom spaning med quadcopter 22 6 Uppdragsplanering 6.1 Inledning Uppdragsplaneringsmodulens uppgift är att bestämma plattformens trajektoria vid avsökning av en yta eller längs en förutbestämd sträcka. Trajektorian beräknas av en algoritm som har tillgång till ett antal givna GPS-punkter, vilka bildar ett område alternativt en sträcka. Utsignal från uppdragsplaneringsmodulen är referensdata i form av koordinater som beskriver den beräknade trajektorian. Modulen är menad att köras innan uppdraget initieras och generera referensdata som sedan används under hela uppdraget. I mån av tid kommer uppdragsplaneringen konstrueras sådan att den inte endast ska köras innan initiering av uppdrag, utan även ha möjlighet att korrigera för eventuella nytillkomna situationer. Som exempelvis att områden har missats och behöver eftersökas i slutet av uppdraget. 6.2 Övergripande design Uppdragsplaneringsmodulen kommer att ta emot objektorienterad data som beskriver vilken typ av uppdrag som ska planeras samt de kriterier som råder. Med kriterier avses de koordinater som definierar område/färdväg samt förbjudana områden. Denna information sorteras sedan för att därefter skickas till respektive funktion. Den slutförda processen resulterar i en fullständig trajektoria. I figur 18 definieras informationsflödet genom modulen. Beroenden framgår av kopplingarna. Designspecifikation

28 Autonom spaning med quadcopter 23 Figur 18: Flödesschema för uppdragsplaneringsmodulen. Under förbehandlingen sorteras datan ut och läggs i olika strukturer så att den på ett effektivt och enkelt sätt kan användas av funktionerna som beskrivs utförligare nedan. Således kan indatan vara av varierande karraktär men utdatan kommer alltid att vara en trajektoria beståendes av koordinater. 6.3 Program och språk Mjukvaran kommer att vara skriven i Java för enkel kommunikation med det övriga systemet. En av funktionerna kommer däremot att vara skriven i C-kod då detta är ett externt program som löser problem av typen TSP (se sektionen Terminologi). 6.4 Terminologi Vid utvecklandet av planeringsalgoritmen har en hel del teori från optimeringsläran implementerats. För att enklast beskriva dessa delar kommer därför de termer som är specifika för detta fackområde att användas. Utförligare beskrivningar av dessa kan återfinnas nedan. Designspecifikation

29 Autonom spaning med quadcopter 24 TSP: Ordet är en förkortning av Traveling salesman problem som är ett välkänt problem inom optimeringsläran. Det kan beskrivas som problematiken med att hitta den kortaste vägen genom ett givet antal städer med olika positioner. Ett problem vars komplexitet följer fakultetes funktion och därmed blir väldigt svårlöst för ett stort antal noder. LKH Lin-Kernighan heuristic, detta är i dagsläget den algoritm som löst det största handelsresandeproblemet någonsin av alla befintliga algoritmer, närmare bestämt en instans på noder [2]. 6.5 Modulbeskrivning Det finns många sätt att angripa areatäckningsproblem, den gemensamma nämnaren är att resultatet nästan alltid blir en kompromiss mellan beräkningkomplexitet och optimalitet. Via grundliga förstudier hittades LKH som ska ha en unik lösnings-heuristik som gör den väldigt snabb. Enligt specifikationerna bör den därför inte ha några problem med att lösa de aktuella problemen vars nodantal aldrig kommer överstiga cirka 2000 noder eftersom den möjliga avsökningsarealen begränsas av WIFI-anslutningens räckvidd (förutsatt att kameran har ett omfång på minst 4m 2 ). Problemet kommer därav ställas upp som ett handelsresandeproblem där noder fördelas ut över täckningsarean. Hur väl trajektorian utformas begränsas därför till kostnadsmatrisen som indirekt blir problemformuleringen, eftersom LKH utlovar en optimal lösning utifrån hur problemet formulerats. Fördelarna med detta blir även att de flesta kriterierna som förbjudna områden, områdesgränser och en strävan om trajektoriamönster kan implementeras som straff direkt i konstnadsmatrisen. Implementationen delas upp på olika funktioner som ansvarar för att lösa separata delar av huvuduppgiften att ta fram en trajektoria. Linjesökning Vid linjesökning används enbart ett begränsat antal av de funktionerna som finns tillgängliga i modulen. Informationen skickas direkt till interpoleringen, se flödesschema i figur 18. Areatäckning i figur 18. Vid areatäckning används samtliga funktioner i en ordning enligt flödesschemat Förbehandling Eftersom modulen har som uppgift att lösa olika typer av problem måste inobjektet tolkas så att rätt funktioner kan anropas. Vid areatäckning delas även informationen upp i modulspecifika strukturer, där koordinater för förbjudna områden och områdeskoordinaterna läggs var för sig. Insignal Utsignal Uppdragstyp Områdeskoordinater alt. linjekoordinater Förbjudna områden, koordinater Funktionsanrop Områdesgränser (Koordinater) Tabell 5: Signalflöde för förbehandlingen Designspecifikation

30 Autonom spaning med quadcopter Polygrid Funktionen tar emot koordinater som definierar det/de områden som ska sökas av. Utifrån dessa bestäms en övre respektive undre områdesgräns för latituden och longituden. Dessa bildar ett rektangulärt område där noder placeras ut efter ett förutbestämt antal per areaenhet, enligt tidigare resonemang kring WIFI-länkens räckvidd och kamerans täckningsgrad bör detta vara runt 0.25 noder/m 2. I ett nästa steg skapas en eller flera polygoner beroende på hur många områden som ska sökas av. Därefter tas alla noder som ligger utanför dessa bort. Sedan subtraheras även de noder som ligger i ett förbjudet område ifrån lösningen. Resultatet är en lång array innehållandes områdeskoordinater, dvs noder. Insignal Utsignal Mönstertyp Områdesgränser (Koordinater) Noder (i en array) Tabell 6: Signalflöde för polygrid Kostnadsmatris Denna funktion sköter all problemspecifiering då trajektorian formas utifrån de kostnaderna som är definierade här. I ett första steg skapas en grundmatris utifrån avstånden mellan noderna. Avståndet beräknas som en energi för att eliminera problemet med negativa avstånd till följd av numeriska koordinater (ekvation 2). LAT = C = lat 1... lat n..... lat 1... lat n LON = lon 1... lon n..... lon 1... lon n lat = 1,..., n lon = 1,..., n n = Antal noder (1) (LAT LAT T ) 2 + (LON LON T ) 2 (2) I ett andra steg studeras trajektoriamönstret med tre olika alternativ. Antingen med en strävan efter att flyga lattitudinellt, longitudinellt eller korsvis. Detta implementeras genom att minska straffet för de nodpar som ligger på samma latitud, longitud eller korsvis. För att snabba upp algoritmen undersöks enbart noder i anslutning till varandra samt att enbart den övre triangeln behandlas, eftersom denna kan speglas då kostnadsmatrisen är symmetrisk. Slutligen kollas områdesgränser. Här studeras en eventuell skärning mellan nodpar och förbjudna områden alternativt yttre gränser, detta illustreras i figur 19. En sådan skärning straffas additativt så att vägen mellan två områden ska få likvärdigt straff. I annat fall skulle algoritmen alltid sträva efter att sluta så nära ett annat område som möjligt även om detta i meningen av antalet svängar inte skulle vara optimalt. Designspecifikation

31 Autonom spaning med quadcopter 26 Figur 19: Området i grått är sökområdet, nodpar inom detta är sammanbundna med gröna linjer. Det vita området i mitten är ett förbjudet område och alla nodpar som korsar detta har målats med röda linjer för att illustera att dessa ska straffas. Insignal Utsignal Noder Områdesgränser (Koordinater) Kostnadsmatris Tabell 7: Signalflöde för kostnadsmatris TSP-algoritm För lösning av TSP-problemet kommer som tidigare nämnt en extern funktion att användas (LKH) [2]. Denna är en algoritm skriven i C-kod som kommer att anropas ifrån Javaprogrammet. Utobjektet är den sökta trajektorian. Insignal Utsignal Kostnadsmatris Trajektoria (obehandlad) Tabell 8: Signalflöde för LKH Interpolering Denna funktion har två huvuduppgifter, dels att jämna ut kurvor så att trajektorian inte innehåller några skarpa kanter samt att interpolera fram ett lämpligt antal punkter som stämmer överens med systemets uppdateringsfrekvens. Skarpa kanter tvingar plattformen till hastiga rörelser som kan generera stora vinkelutslag vilket i sin tur kan utlösa Large Designspecifikation

32 Autonom spaning med quadcopter 27 Angle Alarm, en skyddsåtgärd som stänger av quadcoptern vid för stora vinklar. Därför är detta något som bör undvikas i bästa möjliga mån. Uppgiften kommer att lösas med kubiska spline-funktioner som binds samman med knota-knot ändvillkor. Detta innebär att tredjederivatan ska vara samma vid varje nod, dvs. förändringshastigheten för kurvan blir densamma och därmed kommer trajektorian både få mjuka kurvor och kunna interpoleras med valfri samplingsfrekvens [1]. Funktionen som ska beskriva trajektorian, S(t) kan delas upp i två subfunktioner beroende på om de omgivande koordinaterna ligger i linje med varandra eller om trajektorian svänger i enlighet med ekvation 3. { kx + m, koord. i linje S(t) = a 0 x 3 + a 1 x 2 (3) + a 2 x + a 3, kurvor Insignal Utsignal Trajektoria (obehandlad) Trajektoria Tabell 9: Signalflöde för interpoleringen Eftersom noderna är utplacerade så att hela området täcks under förutsättning att varje nod passeras minst en gång kommer interpolationen inte att påverka täckningsgraden. Detta eftersom funktionen S(t) är uppdelad på intervall mellan varje nodpar i trajektorian. Intervallens olika funktioner är därav baserade på knot-a-knot -ändvillkoren och nodernas position, varpå deras existens i den slutgiltiga trajektorian kan garanteras. Designspecifikation

33 Autonom spaning med quadcopter Tidsberäkning I tidsberäkningen utvärderar modulen hur lång tid uppdraget kan förväntas ta, detta är för att säkerställa att uppdraget är genomförbart med den batterikapacitet som plattformen har. Tiden för uppdragen blir en relativt vag skattning som baserar sig på trajektorians distans och den hastigheten som plattformen uppskattas kunna hålla beroende på dess utformning. Då Uppdragsutförandet förväntas ta längre tid för en väldigt kurvig trajektoria kommer den förväntade hastigheten att anta olika magnituder beroende på trajektorians gradient. Tre stycken olika hastigheter kommer att användas där den första är för raksträckor, den andra för svaga kurvor och den tredje för skarpa kurvor, se ekvation 4 där T är tröskelvärden. Därefter kan tiden integreras fram enligt ekvation 5. Den beräknade tiden syftar enbart till att ge en uppfattning om hur vida det är möjligt att genomföra det planerade uppdraget, beslutet lämnas således åt operatören. v 1, om S(t) T 1 v(t) = v 2, om T 1 S(t) T 2 (4) v 3, om S(t) T 2 t = s 0 s dt (5) v(t) Insignal Utsignal Trajektoria Tidsskattning Tabell 10: Signalflöde för tidsskattning Designspecifikation

34 Autonom spaning med quadcopter 29 7 Uppdragsföljning Uppdragsföljningsmodulen har som uppgift att läsa av referensdata, beräkna styrsignaler och skicka tillbaka dessa till huvudbussen. Informationen mellan huvudbussen och modulen specificerar ej vilket uppdrag som utförs utan består endast av referensdata. Modulen har därför ingen vetskap om vilken typ av uppdrag som utförs utan beräknar endast styrsignaler från den indata som erhålls. Därav består uppdragsföljningsmodulen enbart av en reglerkrets med insignaler i form av referensdata och tillstånd, och utsignal i form av styrsignaler. Alla signaler som uppdragsföljningen kommer arbeta med finns specificerade i tabell 11. Regulatorstrukturen kommer bestå av flertalet P-regulatorer kopplade på sådant sätt att önskade egenskaper uppnås. Eftersom reglering av position med hjälp utav hastigheter av naturen är integrerande räcker enbart P-regulatorer för uppgiften. För att regulatorsystemet ska få rätt referenssignaler och alla koordinater ska bli bekräftat avsökta kommer en förbehandling av referensdatat att implementeras, kallad waypointmanager. Insignal Utsignal Tillstånd Position, [X gps, Y gps ] Hastighet, [ẋ, ẏ] Euler vinklar, [φ,θ] Höjd, [h] Yaw, [ψ] Referensdata Referensposition, [X gps,ref, Y gps,ref ] Referenshöjd, [h ref ] Referensyaw, [ψ ref ] Styrsignaler Pitch, [θ ref ] Roll, [φ ref ] Yawrate, [ ψ ref ] Vertikal hastighet, [ḣ] Styrsignaler (för debugging) Position, [X gps,u, Y gps,u ] Hastighet, [ẋ ref, ẏ ref ] Tabell 11: Signalflöde Uppdragsföljningsmodulen 7.1 Språk och program Modulen kommer att skrivas i Java. Detta är dock något som kan komma att ändras beroende på hur det övriga systemet utformas då modulen i sig inte är låst till något specifikt språk. 7.2 Regulatorstrukur Regulatorkretsen kommer bestå av sju stycken P-regulatorer vilka till viss del kommer ligga i serie och till viss del parallellt. Regulatorerna består av: höjd-, positions-, hastighets-, Designspecifikation

35 Autonom spaning med quadcopter 30 pitchvinkel-, rollvinkel- och yawreglering. Kretsen är uppbyggd sådan att utsignal från positionsreglering är en hastighet och således också insignal till hastighetsreglering, utsignal från hastighetsreglering är en roll- och pitchvinkel som i sin tur är insignal till rolloch pitchvinkelreglering, dessa regulatorer ligger alltså i serie. Parallellt med dessa ligger höjd- och yawvinkelreglering. En översiktsbild av regulatorstrukturen går att beskåda i figur 20. I positionsregleringen kommer en enkel funktion att omvandla hastigheter i N-frame koordinatsystemet till plattformens eget koordinatsystem, B-frame. Omvandlingen kommer ske enligt ekvation (6) [ẋ ] [ ] [Ṅ ] cos(ψ) sin(ψ) = ẏ sin(ψ) cos(ψ) Ė (6) Figur 20: Regulatorskretsen uppdelad i alla delblock för att åskådliggöra regulatorstrukturen. 7.3 Referensväljare Referenssignaler i position, höjdled och yawvinkel kommer genomgå en viss förbehandling innan de används av regulatorerna. Förbehandling är menad att se till att rätt data går vidare till regulatorsystemet och alla referenskoordinater kommer bli nådda. Ett exempel på hur referensväljaren kommer arbeta finns presenterad i figur 21. Designspecifikation