Bachelor Thesis Self Deploying Sensor Swarm

EE3842

Bachelor Thesis Self Deploying Sensor Swarm Aansturing UAVs, communicatie, afstandsmeting & collision avoidance

Delft University of Technology

21 juni 2013

J. van den Bor J.P.G. van Dijk

4125886 4065603

2

Voorwoord Dit is de bachelor thesis van Jeffrey van den Bor en Jeroen van Dijk. De opdracht voor deze thesis is het ontwerpen van een Self Deploying Sensor Swarm; een zwerm van Unmanned Aerial Vehicles (UAVs) die grondobjecten kan volgen en monitoren. Deze opdracht is uitgewerkt in een groep van 6 studenten. Ons deel van de opdracht is het realiseren van de aansturing van de UAVs, de communicatie, de afstandsmeting en een collision avoidance tussen de UAVs. De begeleiders voor dit project waren dr. ir. Chris Verhoeven en ir. Steven Engelen. Graag willen wij hen bedanken voor de begeleiding. Wij wensen u veel plezier met het lezen van onze thesis! Jeffrey van den Bor Jeroen van Dijk

i

ii

Samenvatting In dit verslag behandelen we de aansturing van UAVs, afstandsbepaling tussen UAVs, communicatie tussen UAVs en collision avoidance voor een Self Deploying Sensor Swarm (SDSS). Het doel van de opdracht is om een demonstratie te maken van een SDSS waarmee bewezen kan worden dat het concept haalbaar is en dat hierin tevens ook het ‘follow-the-data’ concept kan worden toegepast. Voor de aansturing van UAVs hebben we het mogelijk gemaakt om meerdere UAVs onafhankelijk vanaf het basisstation te besturen. Dit hebben we geïmplementeerd door de UAVs te laten verbinden met één wifi-router. Vervolgens kan elke UAV opstijgen, landen, vliegen en hoveren. Voor de veiligheid is het mogelijk om de UAVs met één druk op de knop onmiddellijk te laten stoppen. Voor de afstandsbepaling hebben we een methode om in alle richtingen de afstand te meten. Hiervoor gebruiken we ZigBee en daarvan lezen we de signaalsterkte. Hierbij zit ook een vorm van identificatie, zodat duidelijk is tussen welke UAVs de afstand is gemeten. Verder hebben we een afstandstabel, mocht een meting misgaan versturen we de vorige waarde. Voor de communicatie hebben we de mogelijkheid dat berichten kunnen ‘hoppen’ tussen de UAVs, indien het basisstation buiten bereik is. Hierdoor krijg je een soort ketting. Verder zorgt een routingbuffer ervoor dat berichten niet dubbel worden verstuurd. Als laatste hebben we nog de collison avoidance. Hiermee wordt voorkomen dat de UAVs tegen elkaar botsen. Hiervoor gebruiken we de afstandsbepaling en wordt gekeken wanneer deze kleiner is dan een bepaalde waarde.

iii

iv

Inhoudsopgave Voorwoord

i

Samenvatting

iii

Lijst van figuren

vii

Lijst van tabellen

ix

Lijst van afkortingen

xi

1

Inleiding 1.1 Opdrachtbeschrijving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 State of the art analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Opbouw thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 2 2

2

Systeemoverzicht en subsystemen 2.1 Systeemoverzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Subsystemen binnen ons deel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 3 6

3

Aansturing UAVs 3.1 Ontwerpeisen . . . 3.2 Ontwerpkeuzes . . 3.3 Implementatie . . . 3.4 Testen en resultaten 3.5 Conclusie . . . . . 3.6 Aanbevelingen . .

4

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

7 7 8 9 15 18 18

Communicatie en afstandsmeting 4.1 Ontwerpeisen . . . . . . . . . 4.2 Ontwerpkeuzes . . . . . . . . 4.3 Implementatie . . . . . . . . . 4.4 Implementatie afstandsmeting 4.5 Implementatie communicatie . 4.6 Overzicht . . . . . . . . . . . 4.7 Integratie . . . . . . . . . . . 4.8 Testen . . . . . . . . . . . . . 4.9 Resultaten . . . . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

19 19 20 27 27 30 34 35 37 43

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

v

INHOUDSOPGAVE

5

6

7

4.10 Conclusie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Aanbevelingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45 47

Reflex 5.1 Ontwerpeisen . 5.2 Ontwerpkeuzes 5.3 Implementatie . 5.4 Testen . . . . . 5.5 Resultaten . . . 5.6 Conclusie . . . 5.7 Aanbevelingen

. . . . . . .

49 49 49 50 52 52 53 53

. . . . .

55 55 58 61 62 62

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

Procesbeschrijving 6.1 Aansturing quadcopters 6.2 ZigBee modules . . . . 6.3 ZigBee collisions . . . 6.4 ZigBee afstandstabel . 6.5 ZigBee communicatie .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

Discussie en Conclusie

63

Bibliografie

65

A AR.Drone V2 Wifi Configuratie A.1 Configuratie van de router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.2 Configuratie van de quadcopters . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.3 Script automatisch uitvoeren bij het opstarten . . . . . . . . . . . . . . . . . . . . .

69 69 69 70

B Aanpassingen Arduino Uno

71

C AR.Drone V2 C/C++ code compileren en uitvoeren C.1 Cross-compiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.2 Uitvoeren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73 73 74

D Code en testresultaten

75

vi

Lijst van figuren 2.1

Blokschema van de demonstratie. De blauwe delen worden in deze thesis behandeld. De groene delen komen in [1] aan bod en de rode delen in [2]. . . . . . . . . . . . .

4

3.1 3.2 3.3

De netwerkconfiguratie van meerdere quadcopters op één router. . . . . . . . . . . . UML diagram van de quadcopter aansturing. . . . . . . . . . . . . . . . . . . . . . De richtingen van de quadcopter voor de move() functie. . . . . . . . . . . . . . . .

10 13 16

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9

Een ketting naar het basisstation. . . . . . . . . . . . . . . . . Mogelijkheden afstandsmeting. . . . . . . . . . . . . . . . . . Het protocol voor de afstandsmeting. . . . . . . . . . . . . . . De DistanceBuffer klasse. . . . . . . . . . . . . . . . . . . De RoutingTable klasse. . . . . . . . . . . . . . . . . . . . Het formaat waarin de berichten op de PC opgeslagen worden. De testopstelling voor de hopping naar het basisstation. . . . . De testopstelling voor afstandsmeting en routing. . . . . . . . Meting en benadering van RSSI tegen de echte afstand, binnen.

22 25 28 30 31 34 41 42 44

6.1

Flowchart van het doorlopen proces van ontwerpkeuze tot implementatie. De dikke lijn geeft het gevolgen pad aan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flowchart van het doorlopen proces van het testen van de ZigBee-module. . . . . . . Opbouw van een data frame in API operation. [3] . . . . . . . . . . . . . . . . . . . Flowchart van het doorlopen proces van het oplossen van het collisions probleem. De dikke lijn geeft het gevolgen pad aan. . . . . . . . . . . . . . . . . . . . . . . . . .

6.2 6.3 6.4

vii

. . . . . . . . . . . . . . . . [2]

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

56 58 59 61

viii

Lijst van tabellen 3.1 3.2 3.3

AT commando’s van de AR.Drone [4]. . . . . . . . . . . . . . . . . . . . . . . . . . Beschrijving van de voorbeeld code. . . . . . . . . . . . . . . . . . . . . . . . . . . Functies van de klasse Quadcopter. . . . . . . . . . . . . . . . . . . . . . . . . . .

9 11 17

4.1 4.2 4.3

Vergelijking verschillende communicatie technieken [5]. . . . . . . . . . . . . . . . Het protocol voor de afstandsmeting. . . . . . . . . . . . . . . . . . . . . . . . . . . Het protocol voor routing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21 28 32

6.1 6.2

Mogelijke data frames in API operation. [3] . . . . . . . . . . . . . . . . . . . . . . De data frame voor het testen van de zender in API operation. . . . . . . . . . . . .

59 60

ix

x

Lijst van afkortingen UAV SDSS AT command UDP IP GUI GCC SDL PC UWB IR GPS MTDOA CTOF RF TOF AM IMU RSSI LQI RTT ToA PCB UART USART API RX TX SDK CSMA-CA MAC ACK SLAM

Unmanned Aerial Vehicle Self-Deploying Sensor Swarm Attention command User Datagram Protocol Internet Protocol Graphical User Interface GNU Compiler Collection Simple DirectMedia Layer Personal Computer Ultra-WideBand Infrarood Global Positioning System Modified Time Difference Of Arrival Combined Time Of Flight Radio Frequency Time Of Flight Amplitude Modulation Inertial Measurement Unit Received Signal Strength Indication Link Quality Indicator Round Trip Time Time of Arrival Printed Circuit Board Universal Asynchronous Receiver/Transmitter Universal Synchronous/Asynchronous Receiver/Transmitter Application Programming Interface Receive Transmit Software Development Kit Carrier Sense Multiple Access with Collision Avoidance Media Access Control Acknowledgement Simultaneous Localization And Mapping

xi

xii

Hoofdstuk 1

Inleiding Het doel van de opdracht is om een demonstratie te maken van een Self-Deploying Sensor Swarm (SDSS) [6] waarmee bewezen kan worden dat het concept van een SDSS levensvatbaar is en dat hierin tevens ook het “follow-the-data” concept kan worden toegepast.

1.1

Opdrachtbeschrijving

De demonstratie bestaat uit de volgende onderdelen: • Crawlers: Relatief simpele objecten die over de grond bewegen en die gevolgd worden door de sensor nodes. De implementatie hiervan wordt overgelaten aan de gebruiker. • Sensor nodes: De sensor nodes zijn in staat om de crawlers te volgen en vormen de zwerm. Door de sensor nodes op UAVs te monteren, kunnen ze zichzelf verplaatsen en crawlers blijven volgen op het moment dat ze buiten bereik van een sensor node dreigen te raken. De beweging van de crawlers is onvoorspelbaar voor de zwerm van sensor nodes. De sensor nodes kunnen de crawlers volgen d.m.v. een tracking systeem, waarvoor indien nodig bakens mogen worden geplaatst op de crawlers. Er mag ook een radio link voor korte afstand bestaan tussen de sensor nodes en de crawlers om informatie over de crawler zelf te communiceren met de zwerm. Om energie te besparen zullen de UAVs voor het grootste gedeelte van de tijd geland zijn. Ze zullen alleen vliegen wanneer er een verplaatsing nodig is om de communicatie binnen de zwerm in stand te houden of de dekking van de crawlers in stand te houden. Naast de communicatie binnen de zwerm zal de data die gegenereerd wordt door de zwerm bij een basisstation moeten aankomen. Op basis van deze algemene beschrijving van het te ontwerpen systeem zijn binnen de opdracht een aantal taken geformuleerd: • Bouw de demonstratie en zorg dat deze veilig is voor het algemene publiek. • Bepaal de grootte van het systeem zodat er een geschikte demonstratie gebouwd kan worden. (Aantal crawlers, aantal UAVs, grootte van het demonstratie oppervlak etc.) • Ontwerp en implementeer een eenvoudige crawler. • Ontwerp de sensor nodes. • Ontwerp de aansturing van de UAV. 1

1.2. STATE OF THE ART ANALYSIS • Zorg dat de demonstratie duurzaam is en eenvoudig te bedienen.

1.2

State of the art analysis

Op het gebied van Self-Deploying Sensor Swarms zijn al een aantal onderzoeken uitgevoerd. In [7] zet een sensor netwerk zichzelf uit. Het netwerk verdeelt zich echter uniform over een ruimte. In [8] wordt een vliegend sensor netwerk geïmplementeerd. Hier wordt echter gebruik gemaakt van vliegtuigen in plaats van quadcopters. Bovendien worden geen objecten op de grond gevolgd. In [9] wordt een zwerm van vliegende sensoren gebruikt om meerdere targets te detecteren en te localiseren. De paper beperkt zich echter tot dit probleem in de theorie, er worden enkel simulaties gedaan. Wel wordt de invloed van parameters onderzocht, zoals de grootte van de zwerm.

1.3

Opbouw thesis

Voor de uitvoering van deze opdracht is eerst het systeem geanalyseerd en zijn de subsystemen binnen de groep verdeeld. Deze analyse en verdeling wordt besproken in hoofdstuk 2. In hoofdstuk 3 wordt vervolgens de aansturing van de UAVs besproken. De communicatie van de zwerm zal besproken worden in hoofdstuk 4. In dit hoofdstuk wordt ook de afstandsmeting beschreven die gebruikt zal worden om de afstand te bepalen tussen de sensor nodes onderling en tussen de sensor nodes en de crawlers. Het laatste subsysteem dat door ons is uitgewerkt wordt beschreven in hoofdstuk 5, waarbij we de collision avoidance tussen de UAVs behandelen. Een procesbeschrijving volgt in hoofdstuk 6 en in hoofdstuk 7 volgt de algemene discussie en conclusie.

2

Hoofdstuk 2

Systeemoverzicht en subsystemen De opdracht is vrij uitgebreid en de beschrijving van het systeem is ook vrij algemeen en laat ruimte over voor verschillende interpretaties. Gedurende de eerste fase van het project is er daarom gewerkt aan een gedetailleerdere systeembeschrijving en is er ook gekeken naar de haalbaarheid van de verschillende taken. Op basis van deze discussie zijn er een aantal grenzen gesteld aan het werk dat binnen dit project uitgevoerd zou gaan worden. Vervolgens is op basis van deze grenzen het gehele systeem opgedeeld in een aantal deelsystemen.

2.1

Systeemoverzicht

Tijdens de eerste fase van het project is er een meer gedetailleerde beschrijving van het te bouwen systeem ontwikkeld wat heeft geresulteerd in een onderverdeling in een aantal deelsystemen zoals weergegeven in figuur 2.1. De ontwikkeling van de groene delen in het schema wordt besproken in [1]. De ontwikkeling van de rode delen in het schema wordt besproken in [2]. In deze thesis zal de ontwikkeling van de blauwe delen van het schema worden besproken. Het eerste grote verschil met de opdrachtbeschrijving in sectie 1.1 is dat er in dit systeem een basisstation is toegevoegd dat verantwoordelijk is voor de aansturing van de UAVs. In de oorspronkelijke opdracht was het de bedoeling dat de UAVs volledig autonoom kunnen vliegen, maar de verwachting was dat het niet haalbaar is om dit binnen de gestelde tijd te implementeren. Daarom is ervoor gekozen om de zwermintelligentie te ontwikkelen voor een basisstation, zodat het ontwerpen van de aansturing van de UAV en de intelligentie tegelijkertijd kan worden uitgevoerd. Het ontwerp van deze delen moet echter wel zo zijn dat het uiteindelijk geïmplementeerd kan worden op de UAV en het basisstation dus niet nodig is voor de intelligentie en aansturing. Voor de verbinding tussen de sensor node op de UAV en de crawlers zijn twee mogelijke situaties die in dit schema besloten zitten. Allereerst is het mogelijk dat de crawlers sensoren bevatten en dat deze data gecommuniceerd moet worden naar de sensor node op de UAV. Daarnaast kan het zo zijn dat de crawler de data is die door de sensor node gedetecteerd moet worden, bijvoorbeeld als de crawlers mensen zijn. In beide gevallen moet echter de positie van de crawler ten opzichte van de UAV bepaald worden. Ook zal in beide gevallen data bestaan in de sensor node van elke UAV die over het netwerk gecommuniceerd moet worden naar het basisstation. 3

2.1. SYSTEEMOVERZICHT

Basisstation

Zwermintelligentie

Data Communicatie

Commando’s aansturing

UAV

Energievoorziening

Sensor node

Afstandsbepaling tussen UAVs Stabilisatie

Collision avoidance

Aansturing

Landen Hoveren

Positie bepaling Opstijgen

Communicatie

Verplaatsing Beacon Energievoorziening

Crawler Aansturing Sensoren

Figuur 2.1: Blokschema van de demonstratie. De blauwe delen worden in deze thesis behandeld. De groene delen komen in [1] aan bod en de rode delen in [2].

2.1.1

Het groene subsysteem

Op het basisstation zal de zwermintelligentie worden uitgevoerd. Hier komt ook de data van de sensor nodes in de zwerm binnen. Verder zullen vanaf het basisstation commando’s verstuurd worden voor de aansturing van de UAVs.

2.1.2

Het blauwe subsysteem

Zoals te zien hebben we het gedeelte UAV opgedeeld in een aantal deelsystemen: communicatie, energievoorziening, aansturing, collision avoidance & afstandsbepaling tussen UAVs. De communicatie zal over twee kanalen beschikken: één voor de data die door de sensor nodes wordt verzameld over de crawlers en één voor de aansturing van de UAVs. Indien nodig kunnen voor deze twee kanalen verschillende draadloze communicatietechnieken gebruikt worden. Hierbij dient opgemerkt te worden dat het communicatiekanaal voor de aansturing bij verdere ontwikkeling van dit systeem zal verdwijnen, omdat de zwermintelligentie geïmplementeerd zal worden op de UAVs zelf. De energievoorziening zal in de demonstratie bestaan uit de accu van de UAV, maar kan in de toekomst uitgebreid worden met kleine zonnepanelen om een duurzamere energievoorziening te realiseren. De aansturing zal uiteraard geleverd worden door de motoren en regeltechniek van de UAV. In figuur 2.1 staan bij de aansturing een aantal acties die m.b.v. de aansturing uitgevoerd moeten worden. De UAVs moeten ook voorkomen dat ze elkaar raken of tegen obstakels botsen, omdat er dan schade kan ontstaan aan de UAVs of andere onveilige situaties zich kunnen voordoen. Hiervoor wordt de afstand gemeten tussen de UAVs en als deze te klein wordt, zal er actie worden ondernomen om deze afstand weer te vergroten. Om te voorkomen dat tegen obstakels gebotst wordt zullen bij de demonstratie aparte bakens geplaatst worden waartoe de afstand bepaald wordt. Als de afstand tot 4

2.1. SYSTEEMOVERZICHT deze bakens te groot wordt, moet de UAV terugkeren. Zodoende kan de demonstratie in een af te bakenen ruimte gedaan worden waarin gegarandeerd geen obstakels aanwezig zullen zijn. Echte obstakelontwijking zal niet geïmplementeerd worden, omdat dit ingewikkeld is en hier apart onderzoek voor nodig is. Als laatste is er de afstandsbepaling tussen UAVs, waarbij deze waarden moeten worden doorgegeven aan de intelligentie. Enkel de afstand is voldoende voor de intelligentie, omdat alleen bepaald moet worden wanneer andere UAVs buiten bereik raken of te dicht bij komen.

2.1.3

Het rode subsysteem

Ook de crawler is opgedeeld in een aantal deelsystemen: de energievoorziening, aansturing, sensoren en een beacon. Deze opdeling is geldig voor de demonstratie, maar moet voor een andere toepassing wellicht anders. Voor de crawler zal een kant-en-klaar platform gezocht worden dat beschikt over een energievoorziening en aansturing waar eenvoudig extra hardware op geplaatst kan worden voor de sensoren en de beacon. Indien nodig zal er nog wel een extra energievoorziening toegevoegd worden, als de energievoorziening van het platform de beacon en sensoren niet kan voeden. De sensoren kunnen indien gewenst voor de toepassing metingen doen aan hun omgeving. De meetdata kan naar de UAVs verzonden worden, zodat de metingen uiteindelijk bij het basisstation terecht komen. De plaatsbepaling van de crawlers gebeurt door de UAVs op basis van de hoek van de crawler t.o.v. de UAV en de afstand tussen de UAV en de crawler. Met deze data kan de absolute positie van de crawler berekend worden als de absolute positie van de UAV ook bekend is. Om deze plaatsbepaling eenvoudiger te maken, wordt er een beacon op de crawler geplaatst, zodat de UAV de crawler eenvoudig kan detecteren.

2.1.4

Grootte van de demonstrator en de uiteindelijke toepassing

Bij de demonstrator moeten maximaal 10 UAVs kunnen worden gebruikt. Dit is ruim voldoende voor het demonstreren van de concepten SDSS en “follow-the-data”. Daarbij gaan we ervan uit dat één UAV maximaal omringd kan worden door zes andere UAVs. Het aantal crawlers dat bij één UAV in bereik kan zijn zal maximaal 10 zijn. Het communicatiebereik moet bij de demonstrator ongeveer 10 meter zijn. Bij een veel kleinere afstand hebben de UAVs te weinig bewegingsvrijheid en bij een grotere afstand is het formaat van de demonstrator te groot om goed te kunnen observeren. De afstandsmetingen moeten eenzelfde bereik hebben. Bij de uiteindelijke toepassing kan het bereik toenemen tot 100 meter en kunnen bij één UAV wel 50 objecten binnen bereik zijn. De gekozen methoden moeten dus schaalbaar zijn en deze aantallen toelaten.

2.1.5

Adresconventies

Bij de demonstrator zal elk object een nummer krijgen voor de identificatie. De aansturing door het basisstation wordt dan mogelijk en het basisstation kan dan ook afleiden van welk object de data komt. Zo kan bijvoorbeeld ook afgeleid worden of twee UAVs eenzelfde crawler detecteren. Voor deze identificatienummers is de volgende adresconventie bedacht: • 0: speciaal, wordt nooit gebruikt • 1-9: gereserveerd voor het basisstation, de bereikbeperkende bakens en eventuele andere bijzonderheden 5

2.2. SUBSYSTEMEN BINNEN ONS DEEL • 10-99: de UAVs • 100-255: de crawlers

2.2

Subsystemen binnen ons deel

Zoals hiervoor beschreven hebben we het systeem rond de UAV opgedeeld in de deelsystemen: communicatie, energievoorziening, aansturing, collision avoidance & afstandsbepaling. In deze thesis richten we ons niet op de energievoorziening, we gebruiken een accu. Eventueel kan er later gekozen worden voor zonnepanelen of het laten vliegen naar een oplaadstation. Hieronder zullen we globaal de eisen voor de onderdelen vastleggen, de uitgebreide eisen zijn te vinden in de bijbehorende hoofdstukken.

2.2.1

Aansturing

Het doel is om meerdere UAVs draadloos te besturen vanaf het basisstation. Het aantal UAVs is afhankelijk van de toepassing, de demonstratie (het concept van follow-the-data) of een uiteindelijke toepassing. Voor de demonstratie zijn het maximaal tien UAVs. Bij de uiteindelijke toepassing ligt dit getal niet vast, te denken valt aan een ordegrootte van vijftig. Belangrijk is dat de uiteindelijke aansturing ook lokaal op de UAVs kan gebeuren als de zwermintelligentie geïntegreerd wordt op de UAVs. De UAVs moeten stabiel kunnen vliegen, landen, opstijgen en hoveren. Verder moeten ze voor de veiligheid te stoppen zijn met een kill switch.

2.2.2

Communicatie en afstandsbepaling

Met het communicatienetwerk moet het mogelijk zijn om berichten te sturen tussen de UAVs onderling en naar het basisstation. Hiervoor moet het mogelijk zijn dat een bericht via andere UAVs loopt als het basisstation buiten bereik is, een soort ketting. Verder moet de draadloze communicatie een afstand van minstens 10 meter kunnen overbruggen bij de demonstratie en 100 meter bij de uiteindelijke toepassing. Voor de afstandsmeting moet de afstand tussen de UAVs worden bepaald, zonder beacons te plaatsen op vaste locaties. De afstand moet in alle richtingen gemeten kunnen worden en hierbij moet ook bekend zijn tot welk object deze meting plaats heeft gevonden. Zo kan namelijk achterhaald worden of twee UAVs dezelfde crawler detecteren.

2.2.3

Reflex

De eerder genoemde collision avoidance zal voortaan reflex genoemd worden, aangezien alleen gekeken zal worden naar het voorkomen van botsingen tussen de UAVs. Deze moet namelijk als een reflex voorkomen dat een commando dat leidt tot een botsing niet tot een werkelijke botsing leidt. Mocht het reflexmechanisme detecteren dat een andere UAV te dichtbij is ( < 2 meter afstand), dan moeten de UAVs elkaar ontwijken door bijvoorbeeld te landen. De bereikbeperkende bakens zullen niet onderzocht worden, omdat dit op hetzelfde principe gebaseerd is: een afstandsmeting zal gebruikt worden om het gedrag te veranderen.

6

Hoofdstuk 3

Aansturing UAVs In dit hoofdstuk wordt de aansturing van de UAVs behandeld. Hiervoor kijken we naar verschillende bestaande oplossingen, en wat voor ons de beste oplossing is bij de opgestelde eisen. Ook behandelen we de directe aansturing via AT commando’s. Vervolgens kijken we naar het aansluiten van meerdere quadcopters op één router en de aanpassingen aan de code voor de aansturing van meerdere quadcopters. Aansluitend behandelen we de tekortkomingen van de bestaande code en onze aanpassingen.

3.1

Ontwerpeisen

Voor de aansturing van de UAVs zijn een aantal eisen, zoals volgt uit de probleembeschrijving (zie sectie 2.2). Verder zullen een aantal eisen de noemer ‘nice-to-have’ krijgen om aan te geven dat zij uiteindelijk gewenst zijn, maar geen prioriteit hebben. • Vanaf het basisstation moeten meerdere UAVs draadloos, onafhankelijk te besturen zijn bij de demonstrator. Het moet mogelijk zijn om zeker tot 10 UAVs aan te sturen vanaf het basisstation. In een uiteindelijke toepassing draait de zwerm intelligentie op de UAV en geeft deze de commando’s meteen door aan de UAV en is de UAV dus volledig autonoom. Schaalbaarheid (meer UAVs bestuurbaar vanaf één basisstation) is hier dus geen eis, maar wel de mogelijkheid tot integratie van de intelligentie op de UAV. • De UAVs moeten in staat zijn om verticaal te landen en op te stijgen, zodat deze tussen het verplaatsen door telkens kunnen landen om energie te besparen. Ze moeten daarbij wel op dezelfde plek in het netwerk blijven. Het landen en opstijgen moet gebeuren op commando van het basisstation. • De UAVs moeten in staat zijn stabiel te vliegen, zodat een commando dat het basisstation verstuurd ook goed overeenkomt met de uitgevoerde beweging. Alleen als dit het geval is, kan het basisstation de UAV nauwkeurig besturen zonder continu te hoeven corrigeren. • De UAVs moeten in staat zijn te hoveren, zonder continu correcties te hoeven sturen. Hiermee kan deze een vaste positie in het netwerk innemen. • De UAVs moeten op commando van het basisstation vliegen in de gewenste op te geven richting. • De UAVs moeten in geval van nood met één druk op de knop onmiddellijk te stoppen zijn, voor de veiligheid. 7

3.2. ONTWERPKEUZES • Nice-to-have: Accu status van de UAV doorgeven aan het basisstation • Nice-to-have: In het geval de verbinding met het basisstation voor de commando’s wegvalt, dienen de UAVs niet door te vliegen in de laatst opgegeven richting, maar te hoveren of te landen. • Nice-to-have: Slim landen, zodat de UAV bijvoorbeeld niet op de rand van een tafel landt en dan op de grond valt.

3.2

Ontwerpkeuzes

Zoals uit de ontwerpeisen blijkt, moet er een UAV gemaakt worden die stabiel kan vliegen en verticaal kan opstijgen en landen. Daarnaast moet deze in staat zijn te hoveren en snel van positie te veranderen. Een quadcopter, aangevuld met software voor het vliegen, is in staat om aan al deze eisen te voldoen. Zodoende is hiervoor gekozen.

3.2.1

Mogelijke autopilots

Omdat de keuze aan quadcopters groot is, hebben we ons eerst gericht op de beschikbare software voor het besturen van de quadcopter. Er bestaan verschillende open-source autopilots die hiervoor geschikt zijn [10]. De autopilots zijn voorzien van zowel hardware als software. Zoals uit de eisen volgt moet de zwermintelligentie uiteindelijk op de quadcopter daaien, hiervoor is het nodig dat meerdere programma’s parallel uitgevoerd kunnen worden (zwermintelligentie, communicatie en de aansturing). Een voorbeeld van een autopilot is Arducopter, gebaseerd op een Arduino [11]. Hierbij is het waarschijnlijk niet mogelijk om de zwerm intelligentie in een aparte thread naast het vliegalgoritme te draaien. Verder is er nog Openpilot [12] die hier op lijkt; deze is zodoende ook niet goed voor de uiteindelijke integratie met de intelligentie op de quadcopter. Een andere optie is Paparazzi [13] [14], die ontwikkeld is door de TU Delft en gebruikt wordt bij het MAVlab. Vanwege de beschikbare ervaring en ondersteuning is dit dus een interessante autopilot. Volgens [10] presteren de bovengenoemde drie allemaal ongeveer gelijk en hebben ze vergelijkbare mogelijkheden.

3.2.2

Mogelijke quadcopter

Toevallig is er onlangs een minor project geweest op de TU Delft waarin de studenten de opdracht kregen om Paparazzi te combineren met de AR.Drone V2 van Parrot [15]. Deze quadcopter heeft ruim voldoende rekenkracht en draait Linux waardoor er de mogelijkheid bestaat om meerdere programma’s tegelijk te draaien. Bovendien heeft de AR.Drone beschikking over een wifi verbinding wat zeer handig is bij het ontwikkelen en testen [16]. Deze quadcopter lijkt bovendien geschikt, omdat hij vaker gebruikt is voor experimenten met meerdere UAVs [17].

3.2.3

Keuze quadcopter en autopilot

Zodoende is gekozen voor de combinatie van Paparazzi met de AR.Drone V2, wegens de beschikbare ervaring en ondersteuning aan de TU Delft en de mogelijkheid om programma’s parallel te draaien. De aanwezige wifi kan daarbij zonder consequenties gebruikt worden voor de commando’s van het basisstation. Dit communicatiekanaal verdwijnt namelijk als overgegaan wordt van de demonstrator op een uiteindelijke toepassing waarbij de intelligentie op de quadcopter aanwezig is. 8

3.3. IMPLEMENTATIE Aangezien de quadcopter op Linux draait, hebben we gekozen om ook Linux te gebruiken bij de software ontwikkeling. Hierdoor kan de geschreven code later eenvoudig op de AR.Drone gebruikt worden.

3.2.4

Herziening

Gedurende het ontwerpproces zijn we erachter gekomen dat Paparazzi voor ons niet nodig is bij het gebruik van de AR.Drone V2. Via de wifi verbinding kunnen direct commando’s verstuurd worden om de quadcopter te besturen, zodoende zal van deze mogelijkheid gebruik gemaakt worden. De stappen die uitgevoerd zijn om tot deze conclusie te komen en die tot de uiteindelijke aanpak geleid hebben, staan beschreven in de procesbeschrijving (zie sectie 6.1).

3.3

Implementatie

In deze sectie behandelen we de uiteindelijke implementatie voor de aansturing van de AR.Drone. Om de quadcopter aan te sturen moet een AT (Attention) commando worden verstuurd. Dit wordt uitgelegd in sectie 3.3.1. Vervolgens gaan we in op de software die deze commando’s gebruikt, zie sectie 3.3.2.

3.3.1

AT commands en data streams

Een AT command is een text string die gestuurd wordt naar de quadcopter. De commando’s moeten worden gestuurd via UDP (User Datagram Protocol) op poort 5556. De mogelijke commando’s zijn te vinden in tabel 3.1. Verder stuurt de quadcopter twee data streams, navigation data (navdata) en de video output. De video stream zal niet gebruikt worden, omdat dit geen toegevoegde waarde heeft voor de toepassing. De navdata is echter wel heel handig, deze geeft de status van de quadcopter door (o.a. de hoeken, hoogte, batterij niveau, emergency status en of de quadcopter geland is). De navdata stream is te ontvangen op UDP poort 5554. Om de quadcopters aan te sturen is dus een UDP verbinding nodig. AT command AT*REF AT*PCMD AT*PCMD_MAG AT*FTRIM AT*CONFIG AT*CONFIG_IDS AT*COMWDG AT*CALIB

Arguments input

Description Takeoff/Landing/Emergency stop command flag, roll, pitch, gaz, yaw Move the drone flag, roll, pitch, gaz, yaw, psi, psi Move the drone (with Absolute accuracy Control support) Sets the reference for the horizontal plane (must be on ground) key, value Configuration of the AR.Drone 2.0 session, user, application ids Identifiers for AT*CONFIG commands Reset the communication watchdog device number Ask the drone to calibrate the magnetometer (must be flying) Tabel 3.1: AT commando’s van de AR.Drone [4].

9

3.3. IMPLEMENTATIE

Figuur 3.1: De netwerkconfiguratie van meerdere quadcopters op één router.

3.3.2

Software voor de aansturing

Op internet is een goed voorbeeld programma gevonden dat de AT commando’s gebruikt [18]. Deze is getest met een Xbox controller en dit werkte naar behoren. De code gebruikt echter ook de video stream en omdat deze niet nodig is, is deze functionaliteit eruit gehaald. Aangezien deze code geen ondersteuning biedt voor meerdere quadcopters en er een bug lijkt te zijn (Eclipse gaf een memoryprobleem), is besloten om de code aan te passen. De gemaakte aanpassingen worden verderop besproken in sectie 3.3.4. Eerst zal beschreven worden hoe meerdere quadcopters met hetzelfde netwerk te verbinden zijn.

3.3.3

Meerdere quadcopters op één router

De AR.Drone wordt aangestuurd via wifi, om meerdere quadcopters te kunnen besturen is het nodig dat ze op hetzelfde wifi-netwerk zitten. Een computer kan namelijk maar met één netwerk verbinden. De quadcopters maken standaard hun eigen netwerk aan, dan kun je maar één quadcopter tegelijk aansturen. Nu zijn er twee mogelijkheden, één quadcopter die als router functioneert waar de anderen op verbinden of een centrale router waar alle quadcopters mee verbinden. Er is gekozen voor de laatste oplossing, aangezien dit netwerk dan altijd blijft werken en niet uitvalt als bijvoorbeeld de router-quadcopter zonder energie zit of buiten bereik is. Zie figuur 3.1 voor een weergave van dit type netwerk. Hierin staan ook de gekozen IP (Internet Protocol) adressen; de router staat standaard op 192.168.1.1, de quadcopters stellen we in op 192.168.1.10 tot en met 192.168.1.99 en de computer vanaf 192.168.1.100. Dit hebben we gekozen zodat we via het IP adres meteen weten of het een quadcopter of crawler is. 10

3.3. IMPLEMENTATIE Source file(s) heli.cpp

CHeli.cpp, CHeli.h

app.cpp, app.h

navdata.cpp at_cmds.cpp

overig

Functionaliteit Bevat de main() functie en maakt hierin een CHeli en CGUI object aan. In een oneindige loop worden vervolgens het keyboard en de joystick uitgelezen, en worden deze waarden doorgegeven aan het CHeli object. Verder wordt met CRecognition en CRawImage aan beeldverwerking gedaan. Houdt bij of de quadcopter geland is en heeft de functies takeoff(), land() en setAngles() om de quadcopter te laten vliegen door aanroep van functies in at_cmds.cpp. Verder zijn er functies om van camera te wisselen en het beeld op te vragen. Bevat de functie appInit() die aangeroepen wordt in de constructor van CHeli (evenzo de functie appDeinit() die aangeroepen wordt in de destructor). De functie appInit() roept functies aan die zorgen voor het starten van de threads: een thread voor de UDP verbinding van de AT commands en een thread voor de UDP verbinding van de navdata. Verzorgt de UDP verbinding van de navdata. In een aparte thread worden alle binnenkomende berichten gecontroleerd en uitgepakt. Verzorgt de UDP verbinding van de AT commands. In een aparte thread worden deze verstuurd. Deze thread zorgt ook voor het opstarten van het ontvangst van navdata berichten. Deze bestanden zorgen voor het weergeven van het camerabeeld in een GUI en bevatten functies voor beeldherkenning. Tabel 3.2: Beschrijving van de voorbeeld code.

Via internet is een oplossing [19] gevonden om de quadcopters te laten verbinden met een bestaand netwerk. Verder is het mogelijk om een script bij het opstarten van de AR.Drone uit te voeren [20]. Dit is handig aangezien de batterij niet zo lang meegaat (ongeveer 15 minuten) en er bovendien mogelijk veel quadcopters geconfigureerd moeten worden. Als resultaat hebben we nu een script dat elke keer uitgevoerd wordt als de AR.Drone V2 opstart en zo de quadcopter met het netwerk verbindt en het juiste IP-adres geeft. Hoe dit moet, staat beschreven in bijlage A.

3.3.4

Analyse van de bestaande code

Voordat de source code herschreven kon worden, is de huidige opdeling en functionaliteit geanalyseerd. Een samenvatting van deze analyse staat in tabel 3.2. Deze bestaande code kent een aantal tekortkomingen. Bij de besturing van de quadcopters bestaat er enkel een klasse CHeli. De threads die hierbij aangemaakt worden zijn geen onderdeel van een klasse. Bij het aanmaken van meerdere objecten van de klasse CHeli zullen er zodoende niet meerdere onafhankelijke threads worden opgestart voor elke quadcopter. Bovendien wordt het standaard IP adres gebruikt bij het maken van de UDP verbindingen. De huidige code ondersteund dus niet het gebruik van meerdere quadcopters. Er zijn een aantal aanpassingen nodig.

3.3.5

Wensen voor de nieuwe code

Zoals eerder vermeld is alle code gerelateerd aan de camera en beeldverwerking verwijderd. Verder zijn er per quadcopter twee threads nodig voor de twee UDP verbindingen (AT commando’s en 11

3.3. IMPLEMENTATIE navdata). Daarbij krijgt elke quadcopter zijn eigen IP adres. De wensen voor de code zijn als volgt: • Een klasse Quadcopter die gebruikt kan worden als interface door de groep die de kunstmatige intelligentie ontwikkeld. Deze klasse moet functies bevatten voor het opstijgen, landen en besturen van de quadcopter. Bovendien moet de status van de quadcopter opgevraagd kunnen worden. Deze status omvat onder andere of de quadcopter geland is, wat de batterij status is en welke snelheid de quadcopter heeft. Daarnaast moet er een emergency functie zijn die de quadcopter uitschakelt in geval van nood. Bij de aanmaak van een object van deze klasse moet een ID meegegeven worden die het IP adres van de quadcopter bepaalt. • Een klasse ThreadATCommand die een thread voor de AT commando’s bestuurt. Elke quadcopter heeft een object van deze klasse, zodat elke quadcopter een aparte thread heeft voor de UDP verbinding voor de besturing (met eigen IP adres). Deze klasse bevat functies die de AT commando’s implementeren. • Een klasse ThreadNavData die een thread voor de navdata bestuurt. Elke quadcopter heeft een object van deze klasse, zodat elke quadcopter een aparte thread heeft voor de UDP verbinding voor de navigatie data (met eigen IP adres). Deze data wordt ook in deze thread gecontroleerd en uitgepakt.

3.3.6

Implementatie van de software

Bij de implementatie zijn de klassen zoals hierboven beschreven geïmplementeerd. Daarbij is voornamelijk gebruik gemaakt van de code uit het voorbeeld. Er zijn echter een aantal belangrijke veranderingen die besproken zullen worden. Klassen Om een overzicht van de verschillende klassen en hun attributen, functies en relaties te krijgen hebben we een UML diagram gemaakt. Zie figuur 3.2. De klasse Quadcopter heeft als attribute een object van de klasse ThreadATCommand en ThreadNavData. Deze vragen allemaal in de constructor om een ID. Dit ID komt overeen met het laatste byte uit het IP adres van de quadcopter. Het object Quadcopter(10) zal dus nodig zijn voor het gebruik van de quadcopter op het IP adres 192.168.1.10. De constructor van ThreadNavData vraagt daarnaast om een referentie naar het bijbehorende (zelfde ID) object van de ThreadATCommand klasse. Dit is nodig, omdat de navdata thread een status ontvangt die opgeslagen moet worden in de ThreadATCommand klasse. Die klasse kan met die status namelijk bepalen of de navdata verder opgestart moet worden, en kan dat dan doen. Standaard worden namelijk niet alle options verstuurd door de AR.Drone V2. Deze status zal ook worden gebruikt bij het opstijgen, landen en andere functies in de ThreadATCommand klasse. De referentie naar de andere thread handler klasse is bovendien nodig om het AT commando AT*COMWDG te versturen als er een communicatie watchdog timeout is. In de bestaande code werd hiervoor een nieuw message buffer aangemaakt en gevuld in plaats van de bestaande functie at_comwdg() te gebruiken. Zulke code clones zijn slecht en zoveel mogelijk verholpen. In de oude code waren de threads die werden opgestart gewone C functies. Nu moeten de threads echter opgestart worden per object van een klasse, dus als een C++ member functie. De gebruikte library voor multithreading, pthread, heeft echter C-style functies die niet met member functies overweg kunnen. Dit probleem is opgelost zoals beschreven in [21]. Verder zijn in de navdata 12

3.3. IMPLEMENTATIE

ThreadATCommands -

Quadcopter -

ID :uint 8_t thread_ contro l :T hread ATComm ands* thread_ data :Thre adNa vDat a*

+ + + + + + + + + + + + + + + + +

con figure() :v oid em erge ncy() :void ge tAltitu de() :dou ble ge tAngl ePhi() :do uble ge tAngl ePsi() :do uble ge tAngl eThe ta() : doub le ge tBatte ry() :doub le ge tState () :u int32 _t ge tVelo cityX () :do uble ge tVelo cityY () :do uble ge tVelo cityZ() :do uble isL ande d() :b ool lan d() : void mo ve(flo at, fl oat, f loat, float) :voi d Qu adco pter(u int8_ t) ~Q uadc opter() takeoff() :voi d

-th read_ control + + + + + + + + + + + + -m anag er + + + + -

ali ve :b ool bu ffer : char ([THREAD_ AT_ COM MANDS_B UFFE R_S IZE]) ga z :flo at ID :uint 8_t ip_ address :c har ([IP_A DDRESS_ BUFFER_ SIZE ]) loc k :pt hread _mu tex_t ph i :flo at seq uenc e_nu mbe r :un signe d int sta te :u int32 _t the ta :f loat thread :pthre ad_t ud p_soc ket : int yaw :flo at AT Com mand () :vo id AT Conf igMa xAltit ude() :void AT Conf igNav Data Demo () :v oid AT Eme rgenc y() :v oid AT Land () :vo id AT Resu meFromEm erge ncy() :voi d AT Take off() :void AT Trim () :vo id AT Watc hdog () :vo id ge tState () :u int32 _t set Input (float , floa t, floa t, flo at) :v oid set State (uint3 2_t) :void set upNa vData () :v oid start() :void sto p() :v oid thread_ main (void* ) :vo id * thread_ main () :vo id * Th readA TCo mma nds(u int8_ t) ~T hread ATComm ands() wri te(ch ar*, in t32_ t) :vo id

-th read_ data Thr eadNav Data -

ali ve :b ool alt itude :dou ble an gle_p hi :d oubl e an gle_p si :d ouble an gle_t heta :dou ble ba ttery :doub le bu ffer : uint8 _t ([T HREA D_NAVDA TA_ BUFFER_S IZE] ) ID :uint 8_t ip_ address :c har ([IP_A DDRESS_ BUFFER_ SIZE ]) ma nage r :Th read ATCo mma nds* thread :pthre ad_t ud p_soc ket : int vel ocity _x :d ouble vel ocity _y :d ouble vel ocity _z :d ouble

+ + + + + + + + + + + +

ge tAltitu de() :dou ble ge tAngl ePhi() :do uble ge tAngl ePsi() :do uble ge tAngl eThe ta() : doub le ge tBatte ry() :doub le ge tVelo cityX () :do uble ge tVelo cityY () :do uble ge tVelo cityZ() :do uble set upUDP() : int start() :void sto p() :v oid thread_ main (void* ) :vo id * thread_ main () :vo id * Th readNavDa ta(ui nt8_t , ThreadA TCom man ds*) ~T hread NavData()

Figuur 3.2: UML diagram van de quadcopter aansturing.

13

3.3. IMPLEMENTATIE verschillende waarden beschikbaar (waaronder de accu status), deze hebben we in de klasse Quadcopter beschikbaar gemaakt waardoor deze op te vragen zijn door andere gebruikers. Verder zijn bij de implementatie de definities die te maken hebben met de AT commando’s geplaatst in het bestand ATCommands.h en de definities die te maken hebben met de navdata in het bestand NavData.h. Een aantal heel algemene functies en definities zijn geplaatst in de bestanden common.cpp en common.h. Gebruikte poorten De AT commando’s worden in de nieuwe code niet meer gestuurd naar het standaard IP adres 192.168.1.1, maar naar het juiste IP adres van de quadcopter zoals eerder beschreven. Er wordt nog steeds poort 5556 op de quadcopter zelf gebruikt, omdat dit de poort is voor AT commando’s. Hetzelfde geldt voor de navdata, daarvoor wordt poort 5554 gebruikt. Voor de UDP verbinding voor de navdata was bovendien nog een andere aanpassing nodig. Deze gebruikt als IP adres voor de ontvangst socket het speciale IP adres INADDR_ANY. Bij het testen van de code bleek dit niet te werken als deze ontvangst socket ook telkens voor elke thread dezelfde poort gebruikt. Om ervoor te zorgen dat elke quadcopter een eigen poort heeft op de PC wordt daarom het ID opgeteld bij de standaard poortnummer. Dit beïnvloed echter niet de schaalbaarheid, er zijn namelijk 65536 UDP poorten mogelijk en die zijn alleen nodig indien een basisstation gebruikt wordt. Code uitvoeren Deze code is gebuild in Eclipse met de Linux GNU Compiler Collection (GCC) toolchain. Daarvoor moesten een aantal build settings veranderd worden. Bij Project > Properties > C/C++ Build > Settings > Tool Settings > GCC C++ Linker > Libraries zijn de libraries pthread en SDL toegevoegd en als library search path “/usr/local/lib”. De library SDL is alleen gebruikt tijdens het testen om de quadcopter aan te sturen met het keyboard en de joystick (een Xbox controller).

3.3.7

Verbeteringen in de software

Bij het herschrijven van de code zijn we een aantal eigenaardige constructies tegengekomen die anders aangeraden worden in de AR.Drone Developer Guide [4]. Landen en opstijgen Bij de oude code gebeurt het landen en opstijgen met een aanroep naar eenzelfde functie at_ui_pad_start_pressed() waarbij lokaal in CHeli bijgehouden wordt of de quadcopter geland is of niet en deze functie dus aangeroepen moet worden om de status te veranderen. De functie at_ui_pad_start_pressed() stuurt het AT commando AT*REF. Daarbij wordt als argument het lokaal opgeslagen laatst verstuurde argument meegestuurd, echter met het start bit (bit 9 in het 32-bits word) geïnverteerd. Dit is niet de juiste manier, omdat als een commando niet juist aankomt of als de code in de verkeerde toestand begint, het voor kan komen dat de computersoftware een verkeerde status heeft van de quadcopter. Dit is ook eenmaal voorgekomen bij het testen van de software. De software dacht dat de quadcopter al geland was, terwijl deze nog in de lucht hing. Landen lukte toen niet meer met de functie land(), maar juist wel met de functie takeoff(). Zodoende is het opstijgen en landen opnieuw geïmplementeerd zoals aangeraden wordt in de AR.Drone Developer Guide. De status van de quadcopter, of deze geland is, wordt daarbij niet lokaal bijgehouden, maar uitgelezen uit de status in de navdata. Verder zijn er aparte functies voor het AT 14

3.4. TESTEN EN RESULTATEN commando voor het opstijgen en het landen. De functie ATLand() stuurt het AT commando AT*REF met het start bit een 0. De functie ATTakeoff() stuurt hetzelfde commando, maar met het start bit een 1. Zo kan eenzelfde commando herhaaldelijk gestuurd worden. De AR.Drone Developer Guide geeft aan dat een commando herhaaldelijk gestuurd kan worden tot de navdata de juiste status vertoond. Of dit gedaan wordt, wordt nog overgelaten aan de gebruiker van deze code. Die heeft nu in ieder geval de mogelijkheid om dit te implementeren mocht dit nodig zijn. Emergency commando De AR.Drone V2 heeft een speciale emergency mogelijkheid waarin de motoren meteen uitgezet worden. Deze emergency state kan ook weer verlaten worden met een commando. Beide commando’s zijn identiek. Om zowel in als uit de emergency te gaan moet het AT commando AT*REF gestuurd worden met het select bit (bit 8 in het 32-bits word) een 1. Of de emergency state ingegaan of verlaten wordt, hangt af van de huidige state (emergency state of normal state). Bij de bestaande code bestond een functie at_ui_reset die dit bit telkens geïnverteerd (t.o.v. het laatste commando) verstuurd. Deze functie werd elke keer voor het opstijgen verstuurd om de quadcopter uit een eventuele emergency state te halen. In de nieuwe code is dit aangepast door in de navdata de huidige state te controleren. De nieuwe functie ATResumeFromEmergency() stuurt het commando AT*REF met het select bit 1 indien de status weergeeft dat de quadcopter zich in de emergency state verkeerd. Evenzo stuurt de nieuwe functie ATEmergency() het commando AT*REF met het select bit 1 indien de status weergeeft dat de quadcopter zich in de normale state bevindt. Drone configuratie In de oorspronkelijke code werd de quadcopter elke keer voor het opstijgen opnieuw geconfigureerd met een aanroep naar de functie at_trim(). Deze misleidende functie trimt de quadcopter niet alleen, maar stelt ook de maximale vlieghoogte in. Het trimmen houdt in dat de quadcopter zich kalibreert als deze zich horizontaal bevindt. In de uiteindelijke toepassing hoeft dit echter niet het geval te zijn elke keer voor het opstijgen. Zodoende is er een aparte functie configure() geschreven die deze kalibratie uitvoert en de maximale vlieghoogte instelt. Voor beide AT commando’s bestaan nu ook aparte functies (ATConfigMaxAltitude() en ATTrim()). UDP connectie timeout Bij een aantal langere tests van de code bleek dat telkens na precies 30 seconden er geen navdata berichten meer binnenkwamen. Dit lijkt een probleem te zijn van de UDP connectie die timeout na 30 seconden als er alleen maar berichten ontvangen worden en niets teruggestuurd wordt. Dit probleem is verholpen door elke 2 seconden een pakketje terug te sturen naar de quadcopter over deze UDP verbinding. Dit pakketje bevat een enkele integer met waarde 1.

3.4

Testen en resultaten

Het is nu mogelijk om vanaf het basisstation meerdere quadcopters onafhankelijk te besturen. De quadcopters zijn aangepast zodat ze automatisch verbinden met onze router. 15

3.4. TESTEN EN RESULTATEN Voor het aansturen van de quadcopters hebben we een klasse Quadcopter gemaakt zodat andere gebruikers eenvoudig meerdere quadcopters kunnen aansturen vanaf één computer. Zie tabel 3.3 voor alle functies die in deze klasse zitten. De werking van deze code hebben we getest door twee keer een Quadcopter aan te maken en vervolgens één aan te sturen via een Xbox controller en de andere via een toetsenbord. Bij het testen hebben we het opstijgen/landen en bewegen in alle richtingen getest, dit werkt allemaal. De quadcopters gaan hoveren na het opstijgen. Verder hebben de quadcopters een emergency stop, waardoor ze meteen op de grond vallen. Doordat de navdata beschikbaar is, kunnen we continu de batterijstatus uitlezen. We hebben hierbij gezien dat de quadcopter niet meer opstijgt als de batterij onder de 20% komt. Ook hebben we nog getest wat er gebeurt in het geval de verbinding met het basisstation wegvalt. Dit hebben we getest door de stekker uit de router te trekken terwijl de quadcopter vooruit vliegt. De interne aansturing van de quadcopter heeft dit door en laat de quadcopter hoveren.

Figuur 3.3: De richtingen van de quadcopter voor de move() functie.

16

3.4. TESTEN EN RESULTATEN Functie Quadcopter(uint8_t ID)

Uitleg Constructor. ID is een getal tussen 10-100 (laatste deel van IP adres). Hierin wordt ook configure() aangeroepen met een hoogte van 5 meter.

∼Quadcopter()

Destructor. De quadcopter stort neer (emergency()) indien de quadcopter nog in de lucht is en de threads worden verwijderd. Configure zet de maximale hoogte, maxaltitude is in millimeter. Verder voert de configure een trim uit, die vertelt tegen de quadcopter dat hij vlak staat. De functie is alleen nodig indien een andere hoogte gewenst is of als de trim niet goed is uitgevoerd.

configure(unsigned int maxaltitude) :void

takeoff() :void

Laat de quadcopter opstijgen vanaf de grond. Deze functie controleert of de quadcopter geland is.

land() :void

Laat de quadcopter landen, alleen als deze in de lucht is.

emergency() :void

In geval van nood, de rotoren stoppen en de quadcopter stort neer.

move(float phi, float theta, float gaz, float yaw) :void Functie getAltitude() :double

Dit beweegt de quadcopter, zie figuur 3.3 voor het verschil tussen phi, theta, gaz en yaw. Stuur move(0,0,0,0) om de quadcopter te laten hoveren. Alle argumenten zijn een waarde tussen -1 en 1, in het figuur is de positieve richting aangegeven. Uitleg Eenheid Geeft de hoogte. [mm]

getAnglePhi() :double

Geeft de ruwe waarde van phi (roll) in milligraden.

[m◦ ]

getAnglePsi() :double

Geeft de ruwe waarde van yaw.

[m◦ ]

getAngleTheta() :double

Geeft de ruwe waarde van theta (pitch).

[m◦ ]

getBattery() :double

Geeft de batterij status.

[%]

getState() :uint32_t

Geeft de volledige status [4]

getVelocityX() :double

Geeft de snelheid in de X-richting.

[mm/s]

getVelocityY() :double

Geeft de snelheid in de Y-richting.

[mm/s]

getVelocityZ() :double

Geeft de snelheid in de Z-richting.

[mm/s]

isLanded() :bool

Geeft true als de quadcopter geland is. Tabel 3.3: Functies van de klasse Quadcopter.

17

3.5. CONCLUSIE

3.5

Conclusie

In deze sectie bekijken we in hoeverre onze oplossing aan de eisen voldoet. De eerste eis is dat meerdere UAVs vanaf het basisstation onafhankelijk te besturen zijn. Hierbij moeten zeker tot 10 UAVs aangestuurd kunnen worden. In onze implementatie is het mogelijk om meerdere quadcopters automatisch te laten verbinden met een router. Theoretisch is het mogelijk om maximaal 254 quadcopters aan te sturen (laatste deel van IP-adres, behalve 0 en 1). Voor de demonstrator is gekozen om de adressen 10-99 te reserveren voor de quadcopters. Wij hebben de werking getest met twee quadcopters. Iedere quadcopter kan apart worden aangestuurd via de Quadcopter klasse. De volgende eis is dat de UAVs op commando in staat moeten zijn om verticaal te landen en op te stijgen. Dit zit standaard in de aansturing van de AR.Drone door een AT commando te sturen. In onze code kan hiervoor de takeoff() en land() functie gebruikt worden. De derde eis is dat de UAVs de commando’s juist moeten volgen, zodat vooruit ook echt vooruit is. Dit hebben we getest door met een joystick alle mogelijke commando’s te geven en te constateren dat dit juist werkt. Hiermee voldoen we ook aan de eis dat de UAVs op commando in de gewenste richting moeten vliegen. Vervolgens moeten de UAVs in staat zijn om te hoveren. Ook dit gebeurt standaard in de AR.Drone. Zowel direct na het opstijgen als bij het sturen van move(0,0,0,0) blijft de quadcopter hoveren. Voor de veiligheid moeten de UAVs met één druk op de knop onmiddellijk te stoppen zijn. Dit werkt door de functie emergency() aan te roepen. Hiermee stoppen de rotoren en stort de quadcopter neer. Deze functie wordt ook aangeroepen bij de destructor (∼Quadcopter()), zodat bij het afsluiten van het programma de quadcopters altijd op de grond zijn. De eerste nice-to-have is het doorgeven van de accustatus van de UAV. Dit geeft de AR.Drone standaard door via navdata en is geïmplementeerd in onze code door de functie getBattery() aan te roepen. Verder kunnen we ook de hoogte, hoeken en snelheden doorgeven aan de gebruiker. De volgende nice-to-have is dat in het geval de verbinding met het basisstation wegvalt, de UAVs niet door vliegen. Dit zit standaard in de AR.Drone, deze laat hem dan hoveren. De laatste nice-to-have om slim te kunnen landen hebben we niet geïmplementeerd. We gaan ervan uit dat voor de demonstrator dit niet nodig is, aangezien dit plaats vindt in bijvoorbeeld een grote hal.

3.6

Aanbevelingen

Onze aanbevelingen zijn voornamelijk gericht op het integreren met de zwerm intelligentie. Hierbij moet getest worden of de commando’s nauwkeurig genoeg worden uitgevoerd. Dit hangt af van de eisen van de uiteindelijke implementatie. Indien dit niet goed genoeg is kan de aansturing aangepast worden. Verder moet er nog getest worden met meer quadcopters. Wij hadden nu alleen de beschikking over twee quadcopters, in een zwerm zijn dit tientallen. Theoretisch werkt dit goed, aangezien ze allemaal een uniek IP adres krijgen op de router. Als laatste kan nog worden gekeken naar manieren om slim te landen. Als een quadcopter bijvoorbeeld moet landen op een trap moet hij naar beneden blijven vliegen tot hij een goede plek vindt om te landen. Hier wordt al onderzoek naar gedaan door o.a. de TU Delft.

18

Hoofdstuk 4

Communicatie en afstandsmeting In dit hoofdstuk bekijken we de communicatie en afstandsmeting. Hiervoor kijken we naar verschillende technieken om aan de ontwerpeisen te voldoen. Vervolgens behandelen we de implementatie waarbij we ook een protocol opstellen. Vervolgens integreren we dit met de hoekmetingen [2]. Hierna voeren we testen uit en behandelen we de resultaten. Als laatst volgt een conclusie en de aanbevelingen.

4.1

Ontwerpeisen

Voor de afstandsmeting tussen de quadcopters zijn een aantal eisen, zoals volgt uit de probleembeschrijving (zie sectie 2.2). Verder zullen een aantal eisen de noemer ‘nice-to-have’ krijgen om aan te geven dat zij uiteindelijk gewenst zijn, maar geen prioriteit hebben. • De afstandsmeting moet met een methode die in alle richtingen afstanden kan meten naar de andere quadcopters. • De afstand moet bepaald kunnen worden tot veel objecten, namelijk tot alle quadcopters die binnen bereik zijn en wellicht ook tot alle crawlers. Voor de demonstratie zijn dit maximaal 15 objecten en in het uiteindelijke product kunnen dit maximaal 50 objecten zijn. Dus voor de schaalbaarheid moet een methode gekozen worden die de afstand zou kunnen bepalen tot een groot aantal objecten. • Van de gemeten afstand moet bekend zijn tot welk object deze gemeten is. • De afstandsmeting moet binnen 1 seconde de afstand kunnen bepalen tot alle andere quadcopters die binnen bereik zijn. Er moet namelijk elke seconde een afstandsmeting gedaan worden. • De gekozen methode moet niet teveel gewicht toevoegen aan de quadcopter en mag niet teveel stroom verbruiken, zodat de quadcopter kan blijven vliegen en de gebruiksduur meer dan 10 minuten blijft. Ook moet deze monteerbaar zijn aan de quadcopter. • Het bereik van de afstandsmeting moet even groot of groter zijn dan het bereik voor de communicatie, omdat de afstandsmeting tot doel heeft te bepalen wanneer de quadcopter buiten communicatie bereik raakt. Verder moet de afstandsmeting goed kunnen onderscheiden wanneer de quadcopters te dicht bij elkaar komen. 19

4.2. ONTWERPKEUZES • Een nauwkeurigheid van circa 2 meter is voldoende. Welke nauwkeurigheid daadwerkelijk vereist is volgt uit de simulaties/praktijk, maar waarschijnlijk is 2 meter voldoende gezien het formaat van de quadcopter en de ruimte waar gevlogen wordt. • De afstandsmeting moet met een methode die onafhankelijk is van beacons op vaste plaatsen. Voor de communicatie tussen de quadcopters en het basisstation bestaan ook een aantal eisen en ‘niceto-haves’: • Alle berichten die vanuit de quadcopters verstuurd worden moeten kunnen overkomen bij het basisstation. Hierbij gaan we ervan uit dat niet alle quadcopters binnen het bereik hoeven te zijn van het basisstation. Een eis is dus ook dat de quadcopters berichten kunnen forwarden. Er zullen maximaal 6 quadcopters in range zijn van een andere quadcopter. • Het bereik van de communicatie moet circa 10 meter zijn voor een goede demonstratie. Dit moet echter vergroot kunnen worden naar circa 100 meter voor een eventuele uiteindelijke toepassing. • Voor de demonstratie moeten de gemeten afstanden tussen de quadcopters, de afstanden naar de crawlers en de hoeken naar de crawlers verstuurd worden over het netwerk. Deze data moet vervolgens bij het basisstation op de PC verwerkt kunnen worden. Dit is een eis voor de mogelijkheid tot integratie. Voor een uiteindelijke toepassing kan dit andere data zijn. • De eisen voor de throughput zijn dat de bovengenoemde data, die ongeveer elke seconde gegenereerd wordt door de quadcopters, verstuurd kan worden. De latency mag maximaal 1 seconde zijn, zodat de software voor de besturing nog tijdig kan reageren op de meetwaarden. • Ook hier geldt weer dat de module niet teveel gewicht mag toevoegen aan de quadcopter en niet teveel stroom mag verbruiken, zodat de quadcopter kan blijven vliegen en de gebruiksduur meer dan 10 minuten blijft. Ook moet deze monteerbaar zijn aan de quadcopter. • Van elk bericht moet de oorsprong bekend zijn, dus door welke quadcopter deze gegenereerd is. • Dezelfde berichten mogen niet meerdere keren op de PC ontvangen worden. • Nice-to-have: acknowledgements als berichten goed ontvangen zijn door alle quadcopters binnen bereik. Zo kan een bericht opnieuw verstuurd worden als er geen acknowledgement ontvangen is.

4.2

Ontwerpkeuzes

In deze sectie bekijken we de mogelijkheden voor communicatie en afstandsbepaling.

4.2.1

Mogelijkheden communicatie

Voor de communicatie zijn verschillende mogelijkheden; de meest gebruikte zijn wifi, bluetooth, ZigBee en Ultra-WideBand (UWB). Deze technieken worden in [5] met elkaar vergeleken. De belangrijkste verschillen staan in tabel 4.1. Uit de eisen blijkt dat het mogelijk moet zijn om vele quadcopters met elkaar te laten praten. Hierdoor valt Bluetooth en UWB af, aangezien hier maar 8 20

4.2. ONTWERPKEUZES nodes kunnen communiceren. Dan blijft de keus tussen ZigBee en Wi-Fi. ZigBee heeft als voordeel dat hij weinig energie gebruikt, waardoor we langer kunnen vliegen. Wi-Fi heeft als voordeel een snellere overdracht. Bereik Signal rate TX vermogen RX vermogen Max nodes

Bluetooth 10 m 1 Mb/s 103 mW 85 mW 8

UWB 10 m 110 Mb/s 749 mW 749 mW 8

ZigBee 10 - 100 m 0.25 Mb/s 74 mW 81 mW 65000

Wi-Fi 100 m 54 Mb/s 723 mW 710 mW 2007

Tabel 4.1: Vergelijking verschillende communicatie technieken [5].

Het soort netwerk wordt een ad-hoc netwerk, dat is een netwerk zonder een centrale computer en zichzelf configureert. Elke node is zowel een host als router, ze sturen de data door waardoor je een ketting kan maken. Het ad-hoc netwerk wordt verder uitgelegd in [22], waarbij ook wordt uitgegaan van een UAV zwerm. Er is net zoals bij ons een vast basisstation waaruit een netwerk ontstaat. Routing Voor de routing, het doorsturen van berichten, zijn twee protocollen mogelijk: flooding en gossip. Bij flooding worden de bericht aan iedereen doorgestuurd, terwijl bij gossip dit met een bepaalde kans gebeurt. In [23] wordt ingegaan op 2 soorten flooding protocollen voor een ad-hoc netwerk. Gossip wordt in [24] behandeld. Verder bestaat er nog een routing protocol waarbij de locatie gebruikt wordt, dit wordt behandeld in [25]. Hiervoor is GPS nodig, dit gebruiken we niet omdat we ook indoor willen werken. Verder wordt er in [26] specifiek ingegaan op een routing protocol voor ZigBee, waarbij ook wordt ingegaan op de betrouwbaarheid en efficiëntie.

4.2.2

Mogelijkheden afstanden

Voor het meten van afstanden zijn een aantal methoden mogelijk. Er zal gekeken worden naar de mogelijkheden van ultrasoon geluid, infrarood licht en het gebruik van radiosignalen. Bij de laatste categorie zal specifiek ingegaan worden op de mogelijkheden die ZigBee biedt, omdat dit ook een interessante kandidaat is voor de communicatie. De methoden moeten bovendien onafhankelijk zijn van beacons op vaste plaatsen. De hieronder genoemde methoden zijn samengevat in figuur 4.2. Ultrasoon In [27] worden twee methoden onderzocht voor het bepalen van afstanden tussen robots door middel van ultrasoon. Voor deze methoden is ook draadloze communicatie nodig. Via dit kanaal kan identificatie van het meetobject uitgevoerd worden. De robots moeten bovendien uitgelijnd worden, zodat ze richting elkaar wijzen. De twee onderzochte methoden zijn MTDOA (Modified Time Difference Of Arrival) en CTOF (Combined Time Of Flight). Voor MTDOA is een derde robot nodig voor de coördinatie van de meting. In [28] wordt de CTOF methode en alignment verder uitgewerkt, bij MTDOA was de meetduur ca. 9 ms bij een afstand van 3 meter. Voor de CTOF methode is de meetduur ca. 38 ms voor een afstand van 3 meter. De twee methodes zijn getest voor een afstand van 100 mm tot 3000 mm, hierbij was een nauwkeurigheid behaald van 7.3 cm bij MTDOA en 4.8 cm bij CTOF. Voor het meten naar elk object moet een uitlijning gedaan worden, deze uitlijning kan 14 seconde duren. 21

4.2. ONTWERPKEUZES

Figuur 4.1: Een ketting naar het basisstation.

In [29] wordt ultrasoon in combinatie met een RF (radio frequentie) link gebruikt. Door middel van TOF (Time Of Flight) kan de afstand en hoek bepaald worden, hiervoor worden meerdere ultrasoon receivers gebruikt. Dankzij een omnidirectionele ultrasoon transmitter is deze methode geschikt voor alle richtingen. Deze optie kan ook gebruikt worden in het geval van meerdere robots, de ultrasoon transmitters mogen echter niet tegelijk zenden, wat dus een beperking geeft. Het stroomverbruik van de meetmodule is 150 mA bij 7.5V, het bereik is 8100 mm en de meting heeft een nauwkeurigheid van 27.18 mm (en 16.93 graden voor de hoek). Infrarood In [30] wordt een systeem voorgesteld dat infrarood (IR) licht gebruikt voor de bepaling van de afstand (en hoek) tot een andere robot. Een verbeterde versie van dit systeem wordt voorgesteld in [31]. De afstand wordt afgeleid uit de lichtsterkte. Het IR kanaal kan bovendien als communicatiekanaal gebruikt worden met een datasnelheid van ongeveer 16 bits/s. Dit zou gebruikt kunnen worden voor de identificatie van de robot, het systeem kan namelijk ook gebruikt worden voor de detectie van meerdere robots. Hij is getest met 8 robots en kan voor alle richtingen gebruikt worden. Het aantal metingen dat gedaan kan worden is 20 metingen per seconde bij het gebruik van één robot. Deze snelheid moet gedeeld worden door het aantal robots in het geval van meerdere robots. Bij 10 robots kunnen dus nog maar 2 metingen per seconde gedaan worden. Het bereik is 3.1 meter, en de nauwkeurigheid was 40 cm en werd verbeterd naar 17.7 cm in [31]. Voor de hoekbepaling was een 22

4.2. ONTWERPKEUZES nauwkeurigheid behaald van 45 graden en deze is verbeterd tot 17.4 graden. In [32] wordt een combinatie van ultrasoon geluid en infrarood licht gebruikt voor de afstandsmeting. Beide signalen worden AM (Amplitude Modulation) gemoduleerd en uit het faseverschil bij ontvangst wordt de afstand bepaald. Ook dit systeem is in staat om de hoek te bepalen. Via het infrarode kanaal zou ook communicatie mogelijk moeten zijn, dit is echter niet geïmplementeerd. Het systeem kan gebruikt worden met meerdere robots, deze mogen echter niet gelijktijdig zenden. Verder is aangetoond dat ultrasoon directioneel van aard is, één meting duurt 53 ms, het bereik is 2,5 meter en de meting heeft een nauwkeurigheid van 7.55 mm Camera, IMU en radiosignalen In [17] wordt specifiek ingegaan op de relatieve locatiebepaling in een formatie van AR.Drones (bij de test zijn 3 AR.Drones gebruikt). Hier worden 3 mogelijkheden onderzocht: met behulp van de camera, met de metingen van de IMU (Inertial Measurement Unit) en met behulp van de signaalsterkte van een radio transceiver. De camera is niet in staat om in alle richtingen een meting te doen. De metingen van de IMU zijn snelheden die geïntegreerd moeten worden om de positie te bepalen. Hierbij is een drift van 3 meter na 10 minuten waargenomen. Hierdoor zijn de camera en IMU niet geschikt, bovendien is niet duidelijk hoe een echte afstandsmeting gedaan kan worden. Bij de RSSI (Received Signal Strength Indicator) van het radio signaal wordt gewezen op de beïnvloeding van de meting door de omgeving en storende elektronica. Deze methode is getest tot een afstand van 150 cm. De ZigBee PRO bleek niet geschikt vanwege zijn hoge uitgangsvermogen. Verder leek de meting van signaalsterkte alleen niet genoeg voor een heel nauwkeurige afstandsbepaling. ZigBee In [33] wordt ZigBee gebruikt voor de afstandsbepaling, hierbij wordt ook de RSSI gebruikt. Om de dynamische variaties in de metingen te verminderen wordt een eenvoudig smoothing algoritme gebruikt. Dankzij dit algoritme is een nauwkeurigheid mogelijk van 1.7 m met een bereik dat getest is tot 28.5 meter. De relatie tussen de RSSI en de afstand wordt gegeven door: RSSI = − (10n log10 (d) + A). Hierin is n de signaal propagatieconstante, d de afstand, en A de signaalsterkte op een afstand van 1 meter. In [34] wordt ook een afstandsmeting gedaan met de ZigBee RSSI, maar er wordt ook de LQI (Link Quality Indicator) gebruikt als afstandsmaat. In een figuur van de RSSI in het paper is te zien dat de afstandsmeting goed gedaan kan worden voor afstanden onder de 6 meter en voor afstanden boven de ca. 26 meter, tot het einde van het bereik van 72 meter. De LQI is getest tot een afstand van 40 meter en heeft een nauwkeurigheid van 5.3 meter (12% v/d range). Een andere mogelijkheid voor afstandsmeting met ZigBee is door middel van bepaling van de RTT (Round Trip Time) [35]. Hierbij is een nauwkeurigheid van 1 meter behaald in 90% van de gevallen, er zijn echter tussen de 100 tot 1000 transmissies nodig voor een goede bepaling. Een meting met 100 transmissies duurt 3 seconde en het bereik is getest tot 30 meter. Het stroomverbruik van de ZigBee module is ca. 18 mA bij 2.1-3.6V. In [36] wordt ook de RTT van ZigBee gebruikt voor een afstandsbepaling. Hier is met 500 transmissies een nauwkeurigheid van ongeveer 20 cm mogelijk. In [37] wordt de afstand gemeten door middel van TDOA (Time Difference Of Arrival) van verschillende ZigBee kanalen. Dankzij het gebruik van alle 16 kanalen is een hoge nauwkeurigheid van 16 cm behaald met een bereik van 15 meter. 23

4.2. ONTWERPKEUZES In [38] wordt ToA (Time of Arrival) bij UWB radio gebruikt waarbij 25 cm nauwkeurigheid gehaald is bij indoor gebruik. Hiervoor is echter een zeer goede klok synchronisatie vereist. De besproken mogelijkheden staan samengevat in figuur 4.2.

4.2.3

Keuze communicatie en afstanden

Voor de communicatie is het aantal ondersteunde nodes zeer belangrijk voor de schaalbaarheid. Zodoende is ZigBee het geschiktst. Deze kan namelijk veel nodes aan en is het energiezuinigst. Voor de communicatie zal gebruik gemaakt worden van flooding, zodat we zeker weten dat berichten aankomen bij het basisstation. De zwerm vormt een ketting naar het basisstation, als dan berichten met een bepaalde kans worden doorgestuurd komen ze niet aan. Zie ook figuur 4.1 voor een illustratie van zo’n ketting. Voor de afstandsmeting is ultrasoon niet geschikt. Uit de papers is gebleken dat deze niet geschikt is voor de meting naar veel objecten. Bij de MTDOA en CTOF moet voor elk object een uitlijning gedaan worden die 14 seconde kan duren. Bij de TOF en de combinatie van IR met ultrasoon is ondersteuning voor meerdere objecten mogelijk, maar mogen ze niet tegelijk een meting uitvoeren. Dit levert een limiet voor het maximum aantal objecten, omdat een meting binnen 1 seconde gedaan moet worden. Bij de methoden die gebruik maken van IR is het bereik niet voldoende om te bepalen wanneer het object buiten de range raakt van de ZigBee communicatie (range van meer dan 10 meter). Zodoende zal voor de afstandsmeting ook ZigBee gebruikt worden, want van UWB is weinig bekend en bij UWB moet een extra module gebruikt worden. Bij ZigBee is geen extra hardware nodig en neemt het gewicht en het energieverbruik dus niet toe. Bovendien is bij het onderzoek van de communicatiemogelijkheden gebleken dat UWB ook niet veel nodes ondersteunt en meer vermogen verbruikt. ZigBee is geschikt, want deze kan in alle richtingen meten en biedt ondersteuning voor meerdere objecten. Via de communicatie kan identificatie plaatsvinden. De RTT methode is niet geschikt, aangezien deze meting 3 seconde duurt. De LQI alleen is niet voldoende, want deze heeft een nauwkeurigheid van 5.3 meter. De RSSI kan gebruikt worden, want deze heeft voldoende nauwkeurigheid. Het bereik is goed genoeg, want deze moet even groot of groter zijn dan het communicatiebereik, en deze is hetzelfde. Er zal zodoende gebruik gemaakt worden van ZigBee voor zowel de communicatie als de afstandsmeting, met respectievelijk flooding en de RSSI. De ZigBee-modules kunnen overweg met zowel 16-bits addressering als 64-bits addressering. Wij hebben ervoor gekozen om gebruik te maken van de 16-bits adressering, omdat dit ruim voldoende is voor onze toepassing. Binnen deze 16-bits adressering gebruiken we bovendien maar de laagste 8-bits. Dit levert nog ruim voldoende adressen voor de demonstrator (zie ook de adresconventies, sectie 2.1.5). Het is duidelijk dat dit nog makkelijk opgeschaald kan worden voor een latere toepassing.

4.2.4

Combinatie afstandsmeting en communicatienetwerk

Voor zowel het communicatienetwerk als de afstandsmeting zullen we ZigBee modules gebruiken. Eén quadcopter beschikt daarbij over één ZigBee module die zowel gebruikt moet worden voor de afstandsmeting als voor het communicatienetwerk. De groep die de detectie van de crawlers implementeert heeft er ook voor gekozen een afstandsmeting door middel van ZigBee te doen [2]. Hiervoor zal ook dezelfde ZigBee-module gebruikt worden om te besparen op gewicht en energieverbruik. Voor het combineren van de afstandsmeting met het communicatienetwerk zijn verschillende mogelijkheden. Allereerst is het mogelijk om uit de signaalsterkte van bestaande communicatieberichten 24

25

Figuur 4.2: Mogelijkheden afstandsmeting.

Opmerking

Geschikt voor alle richtingen Ondersteuning voor veel doelen Identificatie van het meetobject Meetduur/meetfrequentie Stroomverbruik Bereik Nauwkeurigheid

Opmerking

Geschikt voor alle richtingen Ondersteuning voor veel doelen Identificatie van het meetobject Meetduur/meetfrequentie Stroomverbruik Bereik Nauwkeurigheid

40 m 5.3 m

28.5 m / 72 m 1.7 m

RTT [35][36] Ja Onbekend Kan via ZigBee 3 s (100 transmissies) 18 mA bij 2.1‐3.6V 30 m 1 m / 20 cm

ZigBee

Draadloze communicatie vereist. Hoek kan ook bepaald worden

150 mA bij 7.5V 8100 mm 27.18 mm

TOF [29] Ja Ja, maar 1 tegelijk zenden Kan via RF link

2.5 m 7.55 mm

Ultrasoon/IR Difference in phase delay [32] Ultrasoon was directioneel Ja, maar 1 tegelijk zenden Kan via IR 53 ms

15 m 16 cm

TDOA [37] Ja Onbekend

25 cm

UWB ToA [38] Ja Onbekend Kan via UWB

Hoek kan ook bepaald worden. Communicatie Hoek kan ook bepaald worden. mogelijk via IR (16 Communicatie mogelijk via IR bits/s) (niet getest)

3.1 m 17.7 cm

IR RSSI [30][31] Ja Ja Kan via IR 20 Hz / aantal doelen

Communicatie mogelijk via Gelijktijdig Zeer goede kloksynchronisatie Communicatie Communicatie mogelijk ZigBee. 100‐1000 communicatie mogelijk vereist. Communicatie mogelijk mogelijk via ZigBee via ZigBee transmisses vereist via ZigBee via UWB

LQI [34] Ja Ja

RSSI [33][34] Ja Ja

100 mm tot 3000 mm 7.3 cm 4.8 cm Draadloze communicatie vereist. Derde robot nodig voor Draadloze coördinatie communicatie vereist

Ultrasoon MTDOA [27] CTOF [27][28] Nee, uitlijning vereist (kan 14s duren) Voor elk uitlijning vereist Kan via RF link 9 ms (3 meter) 38 ms (3 meter)

4.2. ONTWERPKEUZES

4.2. ONTWERPKEUZES de afstanden te achterhalen. De bestaande communicatieberichten kunnen dan bijvoorbeeld de berichten met de gemeten hoeken zijn. Een andere mogelijkheid is om speciale berichten te gebruiken voor de afstandsmeting. Voordeel van deze laatste methode is dat deze makkelijk te implementeren is en dat zeker de afstand tot elk object bepaald wordt. Bovendien kan een quadcopter dan zelf met een vaste periode een meting starten. Daarnaast is het mogelijk om de afstand nauwkeuriger te bepalen door de RSSI waarde te gebruiken van het bericht dat de meting start en het bericht van de andere quadcopter die de meting beantwoord. Een ander voordeel van speciale berichten voor de afstandsmeting is dat zo ook de afstand tot de crawlers op dezelfde manier bepaald kan worden. De quadcopter start dan een meting door het sturen van een bericht en alle quadcopters èn crawlers binnen bereik kunnen dan een bericht terugsturen om de meting te voltooien tot elk van deze objecten. Vanwege al deze voordelen is ervoor gekozen om speciale berichten te gebruiken voor de afstandsmeting in plaats van de bestaande communicatieberichten. Dit vereist wel dat van elk bericht vastgesteld moet kunnen worden van welk type deze is. Zodoende zal elk bericht een nummer krijgen dat het type bericht aangeeft. Omdat de afstandsmeting tussen de quadcopters identiek verloopt aan de afstandsbepaling vanuit de quadcopter naar de crawlers is er voor gekozen om de taken hieromtrent te verdelen tussen de twee groepen die hiermee te maken hebben. Er is besloten dat wij ons zullen concentreren op de implementatie van de afstandsmeting. Dit houdt in dat wij ervoor verantwoordelijk zijn dat op de PC een reeks gemeten RSSI waarden binnenkomen met daaraan gekoppeld tot welk object (quadcopter of crawler) deze gemeten is. De andere groep zal zich bezighouden met het onderzoeken van de eigenschappen van de ZigBee RSSI als maat voor de afstand. Het resultaat van dit onderzoek zal ertoe leiden dat de gemeten RSSI waarden omgezet kunnen worden naar fysieke afstanden.

4.2.5

Hardware keuze

ZigBee-module We hebben gekozen voor de ZigBee-module XB24-API-001 [3] van DIGI INTERNATIONAL met PCB antenne. Deze heeft in tegenstelling tot de Xbee-PRO versie een indoor bereik van 30 meter in plaats van 100 meter. Dit is voldoende voor de door ons gestelde eis van circa 10 meter. De gekozen versie is beter geschikt voor de demonstratie op kleine schaal, omdat anders alle quadcopters zich al binnen bereik van het basisstation bevinden en het doorsturen van berichten door de quadcopters niet nodig is. Omdat de ZigBee module ook gebruikt zal worden voor de afstandsmeting naar de crawlers is het het makkelijkst om deze op dezelfde print te monteren als het circuit voor de detectie van de hoeken naar de crawlers. Dit circuit komt op de onderkant van de quadcopter zoals door die groep gekozen is. Zodoende is gekozen voor een ZigBee-module met PCB antenne, omdat een andere antenne het landen van de quadcopter belemmert. Bovendien hebben we eerder ervaren dat de antennes op de ZigBee-modules gemakkelijk afbreken. Microcontroller Op elke quadcopter en elke crawler is een microcontroller nodig en ook als basisstation voor de verbinding van het ZigBee-netwerk met de PC is een microcontroller nodig. De microcontroller voor de quadcopter en de crawler moet beschikking hebben over een UART interface voor verbinding met de ZigBee-module. De microcontroller voor de quadcopter moet verder 26

4.3. IMPLEMENTATIE beschikking hebben over een UART interface voor verbinding met de quadcopter voor realisatie van de reflex, zie hoofdstuk 5. De microcontroller voor het basisstation moet ook nog een UART verbinding hebben voor de verbinding met de PC. Verder zou het fijn zijn als er nog een UART verbinding beschikbaar is voor het debuggen. Het liefst gebruiken we op elk object eenzelfde microcontroller. Deze moet over meerdere UART interfaces beschikken zoals beschreven. Omdat er niet veel rekenkracht nodig is, maar het energieverbruik wel belangrijk is, is ervoor gekozen om een eenvoudige 8-bits microcontroller te gebruiken. Op de TU waren veel T-Minus [39] bordjes beschikbaar. Aangezien er veel microcontrollers nodig zijn en dit bordje aan de eisen voldoet en klein en compact is, hebben we ervoor gekozen om deze te gebruiken. Deze bevat een ATmega2560[40] die op 8MHz draait. De microcontroller heeft beschikking over 4 USARTs en het bordje is ontwikkeld als Arduino-variant. Bijkomend voordeel is dat deze een DC/DC-converter bevat en de microcontroller daarmee op 3,3V kan werken. Daarvoor is een jumper op de print gesoldeerd, want standaard is deze 5V. Deze 3,3V voeding kan ook gebruikt worden voor het voeden van de ZigBee-modules die ook op 3,3V moeten werken. Tijdens de ontwikkeling is soms een Arduino Uno gebruikt, hoe deze gebruikt kan worden in combinatie met de ZigBee-module staat beschreven in bijlage B.

4.3

Implementatie

Er is gekozen voor het gebruik van een ZigBee-module voor zowel de afstandsmeting als de communicatie. Dit zorgt voor een verstrengeling van de protocollen en de gemaakte code. Bovendien zal de afstandsmeting naar de crawler op eenzelfde manier geïmplementeerd worden, maar zal deze natuurlijk niet in het communicatienetwerk zitten. De implementatie bevat dus delen voor de crawler, delen voor de quadcopter en ook delen voor het basisstation. De implementatie van de afstandsmeting wordt besproken in sectie 4.4 en de implementatie van de communicatie wordt besproken in sectie 4.5. Een overzicht van de gemaakte code en de functionaliteiten die elk object zal bevatten wordt gegeven in sectie 4.6.

4.4

Implementatie afstandsmeting

Bij de implementatie zijn een aantal milestones afgewerkt voor we tot het gebruik van een bestaande C++ library voor de ZigBee-module zijn overgegaan [41]. Deze library zal gebruikt worden voor het ontvangen en verzenden van berichten. Voor de gebruikte library moeten de ZigBee-modules in API mode 2 (with escaped characters) gezet worden. De API modus is zeer geschikt voor onze toepassing, omdat bij het versturen meegegeven kan worden naar welke module het gestuurd moet worden of dat het gebroadcast moet worden. Bij het ontvangen van een bericht is bovendien bekend van welke module deze kwam en wat de signaalsterkte bij het ontvangst was.

4.4.1

Protocol afstandsmeting

Zoals eerder vermeld gaan we speciale berichten gebruiken voor de afstandsmeting. Hiervoor moet een protocol gemaakt worden. Er is gekozen om het eerste byte van elk bericht aan te laten geven wat voor type bericht het is. Voor de afstandsmeting zijn twee typen berichten nodig: een DistanceRequest en een DistanceAnswer. Door het eerste byte aan te laten duiden wat voor bericht het is, kan later het 27

4.4. IMPLEMENTATIE AFSTANDSMETING

Figuur 4.3: Het protocol voor de afstandsmeting.

protocol gemakkelijk uitgebreid worden om meerdere typen berichten te ondersteunen. Van deze mogelijkheid zal verderop gebruik gemaakt worden bij de implementatie van het communicatienetwerk. Wij hebben bedacht om eerst een request te broadcasten, waarna vervolgens de nodes die het ontvangen (zowel quadcopters als crawlers) een bericht gericht terugsturen. Het adres waarvan het request kwam is bij de ZigBee-module bekend en hoeft dus niet in het request bericht meegestuurd te worden. Zodra een bericht wordt ontvangen is ook de RSSI van dat bericht bekend. In het bericht dat we terugsturen plaatsen we dan ook de RSSI waarde van het ontvangen bericht. Zo krijgt de node die de request stuurde beschikking over twee RSSI waarden, waarmee een gemiddelde (betrouwbaardere) RSSI berekend kan worden. Wij hebben dit geïmplementeerd door de twee RSSI waarden op te tellen, zodat er geen kommagetal ontstaat bij het delen. Zie tabel 4.2 en figuur 4.3 voor het protocol. INDEX 0 DistanceRequest DistanceAnswer

INDEX 1 Received RSSI

Size 1 2

To Broadcast Request address

Tabel 4.2: Het protocol voor de afstandsmeting.

Met de gebruikte library is er een mogelijkheid tot controle van aankomst van een verzonden bericht. Deze controle zal niet geïmplementeerd worden. Voor de berichten die gebroadcast worden (de DistanceRequest en verderop voor de communicatie) zal geen acknowledge van een ontvanger afgewacht worden. Er is geen controle van ontvangst, omdat niet bekend is hoeveel nodes het bericht zullen ontvangen. Voor de specifiek geadresseerde berichten implementeren we in het begin ook geen ontvangstcontrole, dit is een nice-to-have. Deze berichten komen alleen voor bij de DistanceAnswer, maar de DistanceRequest is een broadcast en de aankomst hiervan kan ook niet bevestigd worden. Zodoende is het al niet zeker dat een meting tot een object goed uitgevoerd wordt. De kans wordt wel groter door de controle op een acknowledge, maar het communicatiekanaal wordt voller en zoals verderop blijkt zijn er al problemen met collisions.

4.4.2

Implementatie van het protocol

In de main-loop wordt continu gecontroleerd of er berichten van de ZigBee-module beschikbaar zijn met de methodes readPacket() en getResponse() van het XBee object en of deze van het juiste type zijn (RX Packet with 16-bit Address). Vervolgens wordt de data van dit bericht opge28

4.4. IMPLEMENTATIE AFSTANDSMETING vraagd en wordt het packet type eruit gehaald van index 0. In deze fase van de ontwikkeling kan dat overeenkomen met een DistanceRequest (PacketTypeDistanceRequest) of een DistanceAnswer (PacketTypeDistanceAnswer). In het geval van een DistanceRequest moet een DistanceAnswer gecreëerd worden. Daartoe wordt van het DistanceRequest bericht de RSSI waarde bij ontvangst en de source opgevraagd met de methoden getRssi() en getRemoteAddress16() van het Rx16Response object (deze bevat het data frame). Voor het sturen van het antwoord wordt hetzelfde buffer hergebruikt. Daarin wordt op index 0 het packet type op PacketTypeDistanceAnswer gezet. Op index 1 wordt de eerder opgevraagde RSSI waarde opgeslagen. Dit bericht met lengte 2 wordt vervolgens na een random delay (zie verderop) gestuurd naar de source van het request met de methode send(tx) van het Xbee object (tx bevat het data frame van het antwoord). In het geval van een DistanceAnswer worden wederom de data van het bericht, de source en de RSSI waarde opgehaald. De data bevat daarbij op index 1 de RSSI waarde waarmee het oorspronkelijke DistanceRequest bij het object aankwam. Deze twee RSSI waarden worden bij elkaar opgeteld voor de middeling van de waarden. Hiermee is de afstand bekend, en ook naar welk object deze gemeten is (door de source van het DistanceAnswer). Deze waarden moeten worden opgeslagen, zodat ze later over het netwerk verstuurd kunnen worden. Ze worden opgeslagen in de afstandstabel (distanceBuffer) die verderop besproken wordt. Voor de implementatie resteert nu nog het creëren van een DistanceRequest. Hiervoor is een functie TransmitDistanceRequest gemaakt. Deze verstuurt een enkele byte, het packet type PacketTypeDistanceRequest. Dit bericht wordt gebroadcast dankzij de aanroep tx.setAddress16(BROADCAST_ADDRESS). Een afstandsmeting kan dus gestart worden door een aanroep van de functie TransmitDistanceRequest. Vervolgens zal elk object antwoorden en wordt het resultaat opgeslagen. Elke quadcopter is uitgerust met de code om zowel een meting te starten als te beantwoorden. Een crawler bevat enkel de code om een DistanceAnswer te sturen na een binnenkomende DistanceRequest.

4.4.3

Afstandstabel

Omdat het soms voorkomt dat niet alle reacties terugkomen, is er een tabel gemaakt die ervoor zorgt dat zulke ‘gaten’ in de datastroom opgevangen worden. Het zou namelijk voor de swarm intelligence op de PC vreemd zijn als eerst een afstand gemeten wordt tot een object en deze vervolgens verdwijnt en weer verschijnt in de meting erna. Deze tabel is nog zo eenvoudig mogelijk gehouden. Zo wordt er bijvoorbeeld niet geëxtrapoleerd om een missende afstand te schatten. Dit heeft ook niet veel betekenis, omdat een quadcopter snel van richting kan veranderen. Daarnaast wordt er ook geen rekening gehouden met het feit dat het object ook werkelijk verdwenen kan zijn als deze op de grens van het communicatiebereik was. Hiervoor is gekozen, omdat de buffer de waarden niet te lang onthoudt en bij het buiten bereik raken de waarde alsnog snel genoeg zal verdwijnen.

4.4.4

Implementatie van de afstandstabel

De afstandstabel is geïmplementeerd als een array van een structure type. De structure type stelt een rij in de tabel voor en bevat de velden address, rssi en age. De array moet voldoende groot gekozen worden om de afstand naar het maximum aantal objecten dat zich in het bereik van een 29

4.5. IMPLEMENTATIE COMMUNICATIE

Figuur 4.4: De DistanceBuffer klasse.

quadcopter kan bevinden te kunnen bevatten. De grootte van het array kan ingesteld worden met de define DISTANCE_BUFFER_SIZE en is tijdens het testen op een waarde van 10 ingesteld. Het aantal gemeten afstanden variëert, en de tabel is dus niet altijd geheel gevuld. Een lege rij wordt aangeduid met het address op 0: een speciaal gereserveerd adres dat geen van de objecten zal aannemen (zie ook sectie 2.1.5). De age geeft aan hoe oud de data in de tabel is. Voordat een nieuwe afstandsmeting gestart wordt, wordt alle oude data uit de afstandstabel gehaald. Indien de age groter is dan een in te stellen waarde (DISTANCE_BUFFER_MAXHISTORY), wordt het address op 0 gezet waarmee de data effectief verwijderd is. Om vervolgens van de resterende data de leeftijd op te hogen wordt simpelweg de age verhoogt van elke rij in de tabel. Vervolgens wordt de meting gestart door een DistanceRequest uit te zenden. Elke ontvangen DistanceAnswer wordt vervolgens in de tabel opgeslagen, dit gaat met de functie save() waarvan de implementatie te vinden is in 6.4. Voor het geheel is een klasse DistanceBuffer gemaakt, zie figuur 4.4.

4.5

Implementatie communicatie

Voor de implementatie van de communicatie zal gebruik gemaakt worden van dezelfde ZigBeemodule die ook gebruikt wordt voor de afstandsmeting. Het protocol dat voor de afstandsmeting bedacht is, moet uitgebreid worden. Dit zal besproken worden in sectie 4.5.3. Bij de communicatie moeten de berichten die gegenereerd worden door de quadcopters via het netwerk van quadcopters bij het basisstation aankomen. Voor het doorgeven van de berichten zal gebruik gemaakt worden van flooding zoals uitgelegd is bij de ontwerpkeuzes (sectie 4.2). Het zal duidelijk zijn dat hierbij binnenkomende berichten niet onvoorwaardelijk doorgestuurd kunnen worden over het netwerk. Twee (of meerdere) nodes zouden eenzelfde bericht dan telkens door blijven sturen naar elkaar. Om dit te voorkomen moet dus ook een manier bedacht worden om te voorkomen dat een bericht dat al een keer verstuurd is door een bepaalde node niet nogmaals verstuurd zal worden door die node.

4.5.1

De routing tabel

In de routing tabel moet bijgehouden worden welke berichten door de node zijn doorgestuurd. Hiervoor moet een bericht dus geïdentificeerd kunnen worden. Er is gekozen om hiervoor het adres van de node te gebruiken die het bericht gegenereerd heeft. Dit moet namelijk sowieso bij het basisstation bekend zijn, zoals in de ontwerpeisen beschreven is. Daarnaast zal er een bericht nummer toegevoegd worden die samen met het source adres het bericht identificeert. Dit berichtnummer wordt toegekend door de node die het bericht genereert en deze zal daarvoor telkens het nummer ophogen bij elk volgend bericht. Deze beide nummers (adres en nummer) zijn 8-bits waarden. Zoals bij de keuzes besproken zal bij de demonstrator namelijk een 8-bits adressering gebruikt worden. Voor het berichtnummer zal 30

4.5. IMPLEMENTATIE COMMUNICATIE

Figuur 4.5: De RoutingTable klasse.

ook een 8-bits waarde gebruikt worden, dit staat 256 berichten toe voordat er herhaling optreedt. De routing tabel zal kleiner zijn dan deze 256 waarden, waardoor dit geen problemen geeft. De grootte van de routing tabel moet minimaal zo zijn dat 1 bericht van elke quadcopter in range onthouden kan worden. Volgens de ontwerpeisen zullen dit er maximaal 6 zijn. Hiervoor moet de combinatie van bronadres en berichtnummer opgeslagen worden. Indien het bronadres het adres van de eigen module is, wordt het niet opgeslagen. Aan de routing tabel hoeven alleen items toegevoegd te worden. In het begin kunnen hiervoor lege plaatsen gebruikt worden. Later zal de tabel vol zijn en dient de oudste waarde vervangen te worden bij het toevoegen van een nieuwe waarde. Dit wordt zodoende geïmplementeerd als een ringbuffer.

4.5.2

Implementatie van de routing tabel

De afstandstabel is geïmplementeerd als een array van een structure type. Deze structure bevat de velden source_address en message_number. De grootte van het array bepaalt dus hoeveel berichtenidentificaties onthouden kunnen worden. Dit kan ingesteld worden met ROUTING_TABLE_SIZE en is ingesteld op 20, ruim voldoende zoals hiervoor beschreven is. De ringbuffer is geïmplementeerd door de index van de startpositie bij te houden, start, en het aantal items dat is opgeslagen, count. Het toevoegen van een item aan de routing tabel gaat als volgt (er wordt niet gecontroleerd of de waarde al in de routing tabel staat, daarvoor is een aparte functie geïmplementeerd). De index waar het nieuwe item opgeslagen moet worden, kan altijd als volgt berekend worden: (start + count)%ROUTING_TABLE_SIZE. Op deze index worden dan het meegegeven bronadres en berichtnummer opgeslagen. Vervolgens moet of de start of de count aangepast worden om aan te geven dat een item is toegevoegd. Indien de tabel vol is (count = ROUTING_TABLE_SIZE), moet de startpositie één plek opgehoogd worden. Daarbij moet de startpositie overflowen als deze de hoogste waarde bereikt heeft (bepaald door de grootte van het array). Indien de tabel nog niet vol is, moet simpelweg de count met één opgehoogd worden. Naast het toevoegen van een waarde aan de tabel is een functie geschreven voor het controleren of een combinatie van een bronadres en berichtnummer in de tabel staat. Bij het aanmaken van de tabel moet deze leeg zijn. Zodoende is er ook een functie empty gemaakt die de gehele tabel leegt door start en count op 0 te zetten. Voor dit geheel is een klasse RoutingTable gemaakt, zie figuur 4.5.

4.5.3

Het protocol voor routing

De communicatie bestaat uit berichten die bij het basisstation moeten aankomen. Dit is een nieuw type bericht en dus is er een bericht type voor dit doel bijgemaakt, Routing, die toegevoegd is aan het bestaande protocol. Deze toevoeging is samengevat in tabel 4.3. Index 0 is nu van het type routing. 31

4.5. IMPLEMENTATIE COMMUNICATIE INDEX 0 Routing

INDEX 1 INDEX 2 INDEX 3 Source address Number # Distances ... INDEX 4 INDEX 5+ Size To # Angles Data ≥ 7 Broadcast or to PC Tabel 4.3: Het protocol voor routing.

Een bericht wordt geïdentificeerd met het bronadres en een berichtnummer, deze 2 bytes dienen zodoende ook in het bericht opgenomen te worden op index 1 en index 2. In het bericht volgt vervolgens de hoeveelheid gemeten afstanden (naar de quadcopters en crawlers) en het aantal hoeken (naar de crawlers). Vervolgens volgt de daadwerkelijke data, bestaand uit een (adres, waarde)-paar waarbij de waarde een afstand of hoek is. Voor het protocol is afgesproken om eerst alle paren met afstanden in het bericht te plaatsen en vervolgens alle paren met hoeken. Beperkingen Het is belangrijk om hierbij op te merken dat een ZigBee-packet maximaal 100 bytes aan data mag bevatten [3]. Dit legt een limiet op het aantal metingen dat verstuurd kan worden. Zoals vermeld, wordt gebruik gemaakt van 8-bits adressering. De gemeten RSSI waarde die als afstandsmaat verstuurd wordt (de eigenlijke vertaling naar een afstand gebeurt op de PC) is ook een 8-bits waarde. De adressen van de crawlers bij de hoekmeting zijn ook opgeslagen in een enkele byte. De gemeten hoek zal ook als 8-bits waarde verstuurd worden [2]. Elke meting, van afstand of hoek, bestaat uit één byte voor het adres en één byte voor de waarde. Als we van de beschikbare 100 bytes de grootte van de header van het bericht afhalen (index 0 t/m index 4) is er dus nog plaats voor 95 bytes, oftewel 47 metingen. Voor de demonstrator is dit ruim genoeg, aangezien er maximaal 15 objecten in het bereik van een quadcopter zullen zijn. Er zullen dus minder dan 47 metingen zijn. In de uiteindelijke toepassing met misschien wel 50 objecten is dit niet voldoende. Er kunnen dan aparte berichten gebruikt worden voor het versturen van de hoeken en van de afstanden. Het is echter meer schaalbaar om het bericht te splitsen en een extra nummer toe te voegen dat aangeeft welk deel van de metingen in het bericht staan. Voor dit potentiële probleem zijn dus oplossingen mogelijk en de schaalbaarheid komt dus niet in gevaar.

4.5.4

Protocol voor de communicatie met de PC

De ZigBee-module van het basisstation is verbonden met een PC waarop de zwermintelligentie draait. Volgens de ontwerpeisen mag de data niet dubbel naar de PC verstuurd worden. Hier is dus ook een routing tabel nodig om te voorkomen dat eenzelfde packet meerdere keren naar de PC gestuurd wordt. De werking van de module die aan de PC verbonden is, is dus nagenoeg identiek aan de modules van de quadcopters. Data dat over het netwerk binnenkomt moet alleen doorgestuurd worden indien deze nog niet eerder doorgestuurd is. In het geval van een quadcopter moet het bericht dan gebroadcast worden over het ZigBee-netwerk. En in het geval van het basisstation moet het dan doorgestuurd worden naar de PC. De verbinding met de PC gaat via de Serial (UART0) van de T-Minus. Deze is namelijk verbonden met een serial-naar-USB converter, waardoor de module via een USB kabel aan de PC hangt en er op de PC een virtuele COM-poort is voor deze verbinding. De data wordt voorbewerkt naar de PC 32

4.5. IMPLEMENTATIE COMMUNICATIE gestuurd, zodat deze daar gemakkelijker te parsen is. Het format dat wij daarvoor gekozen hebben is als volgt (in de vorm van leesbare ASCII text), met rechts een voorbeeld: ! bronadres berichtnummer #afstanden #hoeken adres waarde adres waarde adres waarde adres waarde

4.5.5

! 10 23 3 1 14 156 101 122 11 78 101 45

Implementatie van het protocol

Doorsturen van berichten Zoals bij de implementatie van het protocol van de afstandsmeting (sectie 4.4.2) is genoemd, wordt in de main-loop continu gecontroleerd op de aankomst van een bericht. Vervolgens vindt de controle van het berichttype plaats. Hier vindt nu een uitbreiding plaats. Indien het berichttype Routing is (PacketTypeRouting) wordt het bronadres en het berichtnummer uit het bericht gehaald van respectievelijk index 1 en index 2. Indien het bronadres overeenkomt met het eigen adres is er sowieso geen verdere broadcasting van het bericht nodig. In het andere geval wordt gekeken of deze combinatie van bronadres en berichtnummer in de routing tabel staat met de eerder beschreven methode contains van de RoutingTable klasse. Indien de combinatie in de tabel staat hoeft het bericht ook niet verder gebroadcast te worden. Als de combinatie niet in de tabel staat, wordt deze aan de tabel toegevoegd met de methode add van de RoutingTable klasse. Bovendien moet het bericht dan doorgestuurd worden. Voor het geval van een quadcopter kan het bericht onbewerkt doorgestuurd worden. Bij het basisstation (MAIN_NODE is gedefinieerd) moet het bericht naar de PC verstuurd worden in het leesbare formaat dat eerder beschreven is. Genereren van berichten Voor het genereren van de berichten die de metingen bevatten, is een functie TransmitMeasurements gemaakt. In deze berichten moeten de afstandsmetingen en de hoekmetingen komen in de vorm van (adres, waarde)-paren. De afstandsmetingen staan in de afstandstabel DistanceBuffer, waarbij age niet mee verstuurd wordt. De hoekmetingen staan in een 2 dimensionaal array pos_buffer[IR_BUFFER_SIZE] [BUFFER_PARAMS], waarbij pos_buffer[][0] een adres bevat en pos_buffer[][1] de waarde. Een adres van 0 betekent ook hier een array positie dat geen geldige data bevat en niet meegestuurd moet worden. Voor het geval van een quadcopter zorgt de functie CreateMeasurementsPacket() voor het maken van een Routing bericht en vult deze met de meetdata. Deze wordt vervolgens gebroadcast indien deze daadwerkelijk metingen bevat en dus niet leeg is. Bij het basisstation wordt met de functie SendToPC de data naar de PC verstuurd. Het eigen adres Voor de routing is het nodig dat de nodes weten welk adres ze hebben, zodat dit meegestuurd kan worden als bronadres. Een mogelijkheid hiervoor is om dat getal te programmeren in de node. Het 33

4.6. OVERZICHT

Figuur 4.6: Het formaat waarin de berichten op de PC opgeslagen worden.

adres dient echter al geprogrammeerd te worden in de ZigBee-module en dit adres kan door de node uitgelezen worden door middel van AT commando’s. Deze optie is zodoende gekozen, zodat niet elke node apart geprogrammeerd hoeft te worden met een ander programma dat specifiek aangepast is voor de aangesloten ZigBee-module. Bij het initialiseren van de code wordt zodoende eenmalig het adres opgehaald van de ZigBeemodule met het AT commando “MY”. Hiervoor wordt een AtCommandRequest verstuurd en gewacht op een packet met het API ID AT_RESPONSE (zie figuur 6.3). Uit dit packet wordt vervolgens het 16-bits adres gehaald, en daarvan wordt enkel de laagste 8-bits opgeslagen in my_address. Ontvangen van berichten (PC software) De berichten worden via een virtuele seriële poort naar de PC verstuurd volgens het protocol dat beschreven is in sectie 4.5.4. Er is zodoende ook een programma geschreven dat de berichten die via dit kanaal binnenkomen decodeert en in een eenvoudig te gebruiken structure plaatst. Deze structure staat in figuur 4.6. Het gebruik van std::vector zorgt voor een automatisch groeiend array, waarvan ook het aantal items opgevraagd kan worden. De seriële poort wordt op de Linux pc als bestand geopend: fopen(/dev/ttyUSB1", "r+") De functie getNextMessage() geeft vervolgens het bericht door. Daarvoor wordt gewacht tot het speciale start character ‘!’ ontvangen wordt. Vervolgens wordt door middel van aanroepen van fscanf() de data uitgelezen en in de structure geplaatst die met een pointer is meegegeven. Daarbij wordt telkens het aantal uitgevoerde conversies gecontroleerd, en of de uitgelezen waarden binnen het toegestane bereik vallen. Als dit niet klopt returned de functie de waarde -1 en in het geval alles goed gedecodeerd wordt, wordt het aantal metingen gereturned (aantal afstandsmetingen + aantal hoekmetingen).

4.6

Overzicht

Bij de implementatie van de afstandsmeting is genoemd dat de crawler deels andere code bevat dan de quadcopter. Bij de communicatie gedragen de quadcopters zich bijna hetzelfde als het basisstation. Om de overeenkomsten en de verschillen duidelijk te houden, volgt hier een overzicht met de functionaliteiten die op de verschillende objecten aanwezig zijn (schuingedrukt zijn de berichttypen): • Basisstation (adres 1): – Doet hoekmetingen – Start afstandsmetingen (broadcast een DistanceRequest) – Antwoord op een DistanceRequest met een DistanceAnswer – Genereert berichten met gemeten afstanden en hoeken en verstuurt deze naar de PC – Verstuurd binnenkomende Routing berichten die niet eerder verstuurd zijn naar de PC 34

4.7. INTEGRATIE • Quadcopter (adressen 10-99): – Doet hoekmetingen – Start afstandsmetingen (broadcast een DistanceRequest) – Antwoord op een DistanceRequest met een DistanceAnswer – Genereert Routing berichten met gemeten afstanden en hoeken en broadcast deze – Broadcast binnenkomende Routing berichten die niet eerder door deze quadcopter verzonden zijn • Crawler (adressen 100-255): – Zendt een IR signaal uit voor de hoekmeting [2] – Antwoord op een DistanceRequest met een DistanceAnswer • PC van het basisstation – Decodeert binnenkomende berichten met de metingen – Verder draait hier de zwermintelligentie en worden de quadcopters via wifi aangestuurd

4.7

Integratie

Op dit moment zijn alle functionaliteiten aanwezig die een afstandsmeting kunnen starten en de resultaten hiervan kunnen opslaan en bufferen, inclusief de hoekmetingen [2]. Ook bestaan de functionaliteiten voor het creëren van de berichten uit deze buffers en het versturen van de berichten over het netwerk/naar de PC. Nu resteert nog het samenvoegen van deze functionaliteiten. Daarvoor bestaat de wens van drie nagenoeg onafhankelijke tasks. Deze staan in pseudo-code in listing 4.1: • Een ZigBee-task moet alle binnenkomende berichten verwerken. Dit moet met een zo hoog mogelijke snelheid, omdat anders berichten gemist kunnen worden (buffer raakt vol). • Een task voor de afstandsmeting, deze moet elke seconde een meting doen en deze versturen. • Een task voor de hoekmeting, deze moet ook elke seconde een meting doen en deze versturen. Het versturen van de metingen moet echter gekoppeld gebeuren in 1 bericht. Bovendien kan de T-Minus niet zomaar meerdere onafhankelijke tasks draaien. Zodoende is een manier bedacht om deze tasks te integreren in één main-loop.

Listing 4.1: Pseudo-code voor de verschillende tasks 1 2 3 4 5 6

task_zigbee () { while (1) { / / C o n d i t i o n a l l y f o r w a r d i n c o m i n g r o u t i n g m e s s a g e s , a n s w e r i n c o m i n g d i s t a n c e ... r e q u e s t s & save incoming d i s t a n c e answers z i g b e e . CheckAndHandleIncoming ( ) ; } }

7 8 9

task_distance_measurement () { while (1) {

35

4.7. INTEGRATIE d i s t a n c e B u f f e r . removeOldData ( ) ; distanceBuffer . increaseAge () ; TransmitDistanceRequest () ; d e l a y _ 1 s ( ) ; / / Answers ( w i l l r e t u r n w i t h i n 1 s e c o n d ) a r e s t o r e d i n d i s t a n c e B u f f e r TransmitMeasurements ( ) ;

10 11 12 13 14

}

15 16

}

17 18 19 20 21 22 23 24 25 26 27 28 29 30

task_angle_measurement ( ) { while (1) { reset_sensors () ; f or every sensor (8 sensors ) { set_measurement_input ( sensor ) ; d e l a y ( 1 2 0 ) ; / / Measure f o r 120 ms s t o r e _ r e s u l t ( sensor ) ; } calc_new_values ( ) ; update_age ( ) ; TransmitMeasurements ( ) ; } }

De tasks voor de afstandsmeting en de hoekmeting hebben overeenkomsten. Beide voeren circa elke seconde (8 ∗ 120ms ≈ 1s) een meting uit en versturen deze. Daarnaast bevatten deze tasks delays. De ZigBee-task moet zo vaak mogelijk uitgevoerd worden en kan dus in de tijd van deze delays gedaan worden. In de main-loop wordt zodoende continu de ZigBee-task uitgevoerd. Elke 120 ms wordt echter voor korte tijd iets gedaan aan de hoekmetingen en na elke 8 keer (ca. elke seconde) worden de metingen verstuurd en een nieuwe afstandsmeting gestart. Dit ziet er in pseudocode uit als in listing 4.2.

Listing 4.2: Pseudo-code voor de integratie van de verschillende tasks 1 2 3

mainloop ( ) { / / C o n d i t i o n a l l y f o r w a r d i n c o m i n g r o u t i n g m e s s a g e s , a n s w e r i n c o m i n g d i s t a n c e ... r e q u e s t s & save incoming d i s t a n c e answers z i g b e e . CheckAndHandleIncoming ( ) ;

4

i f ( 1 2 0 ms h a v e p a s s e d s i n c e l a s t t i m e ) { / / E v e r y 120 ms i f ( count < 8) { s t o r e _ r e s u l t ( sensor ) ; set_measurement_input ( next sensor ) ; } e l s e { / / This i s a p p r o x i m a t e l y once every second calc_new_values ( ) ; update_age ( ) ; TransmitMeasurements ( ) ;

5 6 7 8 9 10 11 12 13

/ / S e t u p f o r new d i s t a n c e and a n g l e m e a s u r e m e n t d i s t a n c e B u f f e r . removeOldData ( ) ; distanceBuffer . increaseAge () ; TransmitDistanceRequest () ; reset_sensors () ; count = 0;

14 15 16 17 18 19

} c o u n t ++;

20 21

}

22 23

}

Om te bepalen of 120 ms is verstreken wordt een timer gebruikt. Deze is geconfigureerd in CTC (Clear Timer on Compare) mode om elke 120 ms de compare flag te zetten [40]. De if (120 ms have passed since last time) bestaat dus uit het controleren of deze timer flag gezet is. Als dit 36

4.8. TESTEN het geval is, is 120 ms verstreken. De timer flag wordt vervolgens gecleared in de code. De complete code staat in bijlage D. In de code wordt de uitvoering van de verschillende tasks ook gevisualiseerd door middel van het knipperen van de LEDs op het T-Minus bordje.

4.8

Testen

In deze sectie testen we de verschillende onderdelen; de afstandsmeting zonder afstandstabel, de afstandstabel zelf, de routing en de integratie. Ook hebben we gemeten hoeveel vermogen door de module verbruikt wordt.

4.8.1

Afstandsmeting zonder afstandstabel

We hebben ons eerst gericht op een afstandsmeting tussen twee ZigBee’s. Indien dit goed werkt gaan we het ook testen met meerdere. Testen met twee ZigBee’s We hebben de werking eerst getest met twee ZigBee’s die beide de binnenkomende data frames printen. Dit is binnen getest met een afstand tussen de ZigBee’s van minder dan 1 meter. Als de ene ZigBee-module een DistanceRequest stuurt, komt dit op de andere module met een bepaalde RSSI waarde binnen. Deze module verstuurde vervolgens een DistanceAnswer met hierin deze waarde. Dit bericht kwam op de eerste ZigBee-module binnen met een bepaalde signaalsterkte. Deze signaalsterkte kwam goed overeen met de RSSI waarde in het ontvangen bericht. Soms was er een klein verschil in RSSI van maximaal 2 dBm. Zoals later blijkt uit de resultaten (4.9.1) komt dit op een afstand van 1 meter overeen met een afwijking van ongeveer 10cm. Het optellen van deze waarden levert dus een nauwkeurigere inschatting van de afstand, omdat het een middeling van de twee metingen realiseert. Testen met meerdere ZigBee’s Vervolgens hebben we meer ZigBee’s toegevoegd en kwamen we er achter dat er collisions optreden. Vooral als twee ZigBee’s dicht bij elkaar liggen missen vaak berichten. Dit komt waarschijnlijk omdat alle ZigBee’s op hetzelfde moment hun antwoord sturen. Om dit op te lossen hebben we eerst in XCTU instellingen van de ZigBee aangepast, zie de procesbeschrijving (sectie 6.3). De beste resultaten werden echter gekregen door zelf in de software een random delay toe te passen. De microcontroller wacht dan een random tijd van 2 ∗ random(0, 20) ms voor het terugsturen van een antwoord, zodat er vrijwel altijd minimaal 2ms tussen de antwoorden zit. Dit geeft zeer goede resultaten, waarbij meestal alle 4 de reacties van de verwachte 4 binnenkomen. Deze optie geeft 20 mogelijke slots waarin het antwoord teruggestuurd kan worden (de upperbound van de random-functie is exclusive). Bij de demonstrator zullen er maximaal zo’n 15 objecten zijn waarnaar de afstand bepaald moet worden. Er is dan een redelijke kans dat nagenoeg alle afstanden goed bepaald worden. Het aantal mogelijke slots kan verder verhoogd worden, want volgens de eisen is het voldoende als een afstandsbepaling 1 seconde duurt. Verder kan de duur van een slot wellicht verkort worden, omdat momenteel niet de hoogste datasnelheid gebruikt wordt. Zoals beschreven in de procesbeschrijving gebruiken we nu 57600 baud vanwege de mogelijkheid om dan ook met een Arduino Uno te kunnen testen. Deze snelheid is mogelijk te verhogen tot 115200 baud. 37

4.8. TESTEN Deze methode legt dus wel een beperking op het aantal objecten waarnaar een afstand bepaald kan worden, maar door het aantal delay slots te vergroten en de duur van de delay slot te verlagen is het waarschijnlijk goed mogelijk om de vereiste 50 objecten in de uiteindelijke toepassing te ondersteunen. Door bijvoorbeeld een random tijd van random(0, 100) ms te wachten zijn er 100 slots van elk 1 ms (uitgaande van de hogere datasnelheid die mogelijk is). Mocht dit nog te veel collisions leveren dan kan het aantal slots verder verhoogd worden, want de meting mag 1 seconde duren.

4.8.2

Testen van de afstandstabel

Nadat de communicatie geïmplementeerd is hebben we ook de werking van de afstandstabel gecontroleerd. Dit is gedaan door middel van 3 ZigBee-modules: • ZigBee-module (adres 12): deze is verbonden met de PC en stelt het basisstation voor. Deze heeft bij de afstandstabel een DISTANCE_BUFFER_MAXHISTORY van 0. Dit komt overeen met het gebruik van geen buffer voor het opvangen van gaten in de datastroom. • ZigBee-module (adres 10): deze heeft een afstandstabel met een DISTANCE_BUFFER_MAXHISTORY van 3. Dit staat toe dat een meting 3 keer gemist wordt. • ZigBee-module (adres 13): deze heeft ook effectief geen afstandstabel (DISTANCE_BUFFER_MAXHISTORY is 0), maar dat maakt voor de meting niet uit. Dit is namelijk de module die uitgeschakeld wordt (door de spanning te verwijderen) om een gat in de datastroom te creëren. Het resultaat van deze meting staat in de bijlage D. Hierin is te zien dat in eerste instantie elke node metingen verricht naar elke andere node. Vervolgens verdwijnt na het uitschakelen van de spanning van module 13 het bericht hiervan niet meer. Na message number 46 volgen geen berichten meer van deze node. Onduidelijk is of dit ook het precieze uitschakelmoment van de module was, zoals verderop blijkt. Vervolgens zien we in het bericht van module 12 geen meting meer naar module 13. En een aantal berichten later zien we in het bericht van module 10 ook geen meting meer naar module 13. Dit is 2 of 3 berichten later, het precieze onderscheid is niet te maken omdat niet bekend is welke berichten van 10 en 12 bij elkaar horen (M-81-M-82-M-83 of 80-M-81-M-82-M-83-M, met de nummers de message numbers van 10 en M een bericht van 12). Hoogstwaarschijnlijk zijn het de berichten van module 10 met message numbers 80 t/m 82 waarbij geen meting meer bestaat, maar de waarde uit de tabel doorgestuurd wordt. Opvallend is wel dat modules 10 en 12 nog een tijdje een meting naar module 13 hebben, meteen na het niet meer ontvangen van berichten van module 13. Zo bevat message number 78 van module 10 nog zeker een nieuwe meting naar 13 aangezien de gemeten waarde verschilt van de vorige waarde. Waarschijnlijk is het bericht met de metingen van 13 toevallig niet goed ontvangen of verstuurd. Opvallend is verder ook dat module 12 (met een DISTANCE_BUFFER_MAXHISTORY van 0) nog een aantal berichten met een meting naar 13 bevat. Dit is ook te verklaren met de verklaring die hiervoor gegeven is. Daardoor is het moment van uitschakelen van module 13 geen duidelijk aan te wijzen punt. Bewezen is dat een meting een tijdje verstuurd blijft worden in een bericht ook al reageert de module van de betreffende meting niet met een antwoord. Met een grotere waarde van DISTANCE_BUFFER_MAXHISTORY worden duidelijk meerdere gaten opgevangen door langer een meting door te sturen die oud is. 38

4.8. TESTEN

4.8.3

Testen van routing

Voor het testen van de routing hebben we eerst gekeken of de routing tabel werkt. Vervolgens is gekeken of de hopping werkt. Hierna testen we de combinatie van routing en afstandstabel, met vijf modules. Testen van de routing tabel Voor het testen van de werking van de routing tabel is de inhoud van deze tabel ook geprint. Daarbij is enkel de tabel van het basisstation geprint. Het resultaat daarvan staat hieronder, daarbij zijn 4 ZigBee-modules aangesloten en heeft de tabel een grootte van 10: Message > From: 12 (MAIN_NODE) 10 68 14 57 13 56 Routing Table: 13 208 10 164 14 207 13 209 10 165 14 208 13 210 10 166 14 209 Message > From: 13 (211) 14 77 10 49 12 56 Message > From: 10 (167) 12 68 13 46 14 65 Message > From: 14 (210) 13 76 10 68 12 58 Message > From: 12 (MAIN_NODE) 10 68 14 57 13 56 Routing Table:

39

4.8. TESTEN 14 13 10 14 13 10 14 13 10 14

207 209 165 208 210 166 209 211 167 210

Zoals is te zien, bevat de routing tabel eerst 9 waarden en is deze nog niet vol. Vervolgens bevat de tabel na het toevoegen van de 3 nieuwe meting (niet van de MAIN_NODE) 10 waarden. Daarvoor zijn de twee oudste waarden weggegooid ([13,208] en [10,164], deze werden als eerste geprint). De nieuwe waarden staan onderaan de tabel. Hiermee is aangetoond dat de routing tabel werkt. Zowel het groeien als het verwijderen van oude waarden indien nodig werkt. Testen van hopping Zoals eerder besproken kan het voorkomen dat de quadcopters in een ketting komen naar het basisstation. Om dit te testen hebben we vier modules als een ketting uitgelegd. Zie figuur 4.7 voor de gebruikte testopstelling (dit is in de gangen bij TU Delft EWI LH 01.090). • ZigBee-module (adres 10): Verbonden met de PC en stelt het basisstation voor. Ziet alleen module 11. • ZigBee-module (adres 11): Staat in de gang en ziet module 10 en 12. • ZigBee-module (adres 12): Staat aan het einde van de gang en ziet module 11 en 13. • ZigBee-module (adres 13): Staat in een andere gang en ziet alleen module 12. Zie de resultaten hieronder, zoals te zien werkt de hopping functionaliteit zoals we verwachten. De hierboven genoemde modules zien inderdaad de verwachte andere modules. Wat wel opvalt is dat module 13 ook module 11 ziet, maar andersom niet. Dit komt omdat de afstand tussen deze twee modules echt maximaal is. Message > From: 10 (MAIN_NODE) 11 142 Message > From: 13 (29) 11 170 12 140 Message > From: 10 (MAIN_NODE) 11 142 Message

40

4.8. TESTEN

Figuur 4.7: De testopstelling voor de hopping naar het basisstation.

> From: 12 (33) 11 158 13 138 Message > From: 13 (30) 12 138 Message > From: 11 (151) 10 143 12 158

Testen van routing en afstandsmeting Om de situatie te testen dat er veel quadcopters en/of crawlers bij elkaar staan, hebben we de werking getest met 4 ZigBee’s die op ongeveer 10cm afstand van elkaar staan en 1 ZigBee die op 2 meter afstand staat. Zie figuur 4.8 voor de gebruikte opstelling. De resultaten van deze test staan hieronder. Zoals te zien ontvangen we berichten van alle modules en er zitten geen dubbele berichten tussen. De routingbuffer, die bijhoudt welke berichten al ontvangen en verstuurd zijn, werkt dus zoals verwacht. Verder is te zien dat modules 10, 12, 13 en 14 meten dat module 11 verder weg staat (rond de 120 dBm in plaats van 70 dBm voor de andere modules). Vanaf module 11 is dan ook te zien dat de andere modules allemaal ver weg zijn (alle waarden boven 100 dBm). Ook is hier te zien dat de berichten in een willekeurige volgorde binnenkomen. Dit komt door de random delays en het niet gelijktijdig inschakelen van de modules. Message > From: 10 (MAIN_NODE) 11 105 14 84

41

4.8. TESTEN

Figuur 4.8: De testopstelling voor afstandsmeting en routing.

13 85 Message > From: 14 (49) 10 86 12 70 11 125 13 68 Message > From: 12 (117) 13 70 11 117 14 70 10 54 Message > From: 13 (0) 12 71 11 128 14 64 10 85 Message > From: 11 (124) 10 107 12 116 14 126 13 129

4.8.4

Integratietest

Nadat ook de hoekmeting van de andere subgroep [2] is geïntegreerd in de code, is dit natuurlijk ook getest. In deze test hebben we bovendien voor het eerst het officiële protocol voor de communicatie 42

4.9. RESULTATEN met de PC gebruikt (zie sectie 4.5.4). Het resultaat is hieronder te zien: ! 14 144 1 1 10 68 8 45 ! 10 0 1 0 14 68 ! 14 145 1 1 10 66 8 180 ! 10 0 1 0 14 68

Het basisstation heeft hier adres 10, zodoende is van de berichten van adres 10 het berichtnummer telkens 0. Deze berichten bevatten telkens enkel een afstandsmeting, namelijk naar 14. De berichten van 14 bevatten zowel een afstandsmeting als een hoekmeting. Daarbij is de afstandsmeting naar nummer 10 en de hoekmeting naar nummer 8. Deze test heeft aangetoond dat zowel de hoeken als de afstanden gemeten worden en dat deze juist verstuurd worden over het netwerk naar het basisstation. Bovendien zien we dat het protocol voor de communicatie met de PC juist geïmplementeerd is.

4.8.5

Verbruik

Aangezien een laag energieverbruik een van de eisen is, hebben we het verbruik van de T-Minus in combinatie met ZigBee gemeten. Hiervoor hebben we één module op de computer aangesloten en de andere op een labvoeding (Delta Elektronika Power Supply E 015-2). Deze hebben we op 12V ingesteld en nagemeten met een multimeter (Hewlett Packard 34401A). De 12V is gekozen omdat dit ook ongeveer de spanning is van de accu’s van de AR.Drone. Vervolgens hebben we met de multimeter de stroom gemeten, dit kwam uit op ongeveer 24,4mA. Vermenigvuldigd met de spanning geeft dit een verbruik van ongeveer 290mW.

4.9

Resultaten

Zoals te zien bij de testen (4.8) werkt de afstandsmeting naar behoren. Door het optellen van de twee RSSI waardes verkrijgen we een indicatie voor de afstand. Wel treden er soms collisions op tussen de modules, dit hebben we zo veel mogelijk weten te vermijden door een random software delay toe te voegen. Dit geeft echter wel een limiet op de schaalbaarheid. Dit is op te lossen door meer delay slots toe te passen en eventueel een kortere tijd tussen de delay slots. Overigens is het door het gebruik van een afstandstabel niet erg als er soms een meting wegvalt, aangezien dan de laatst bekende waarde wordt doorgestuurd. 43

4.9. RESULTATEN ‐60

ZigBee Afstand‐RSSI

‐80

RSSI

‐100

Meting Benadering

‐120

‐140

‐160

‐180 0

1

2

3

4

5

6

7

8

9

10

Afstand [m]

Figuur 4.9: Meting en benadering van RSSI tegen de echte afstand, binnen. [2]

Verder hebben we getest wat het verbruik is van de T-Minus en ZigBee samen, dit kwam uit op 290mW. Daarnaast is de integratie van de afstandsmeting en communicatie met de hoekmeting getest. Dit werkt ook naar behoren.

4.9.1

Relatie RSSI met werkelijke afstand

De verkregen RSSI waarde kan worden omgezet in een fysieke afstand. Deze conversie wordt behandeld in de thesis van de andere subgroep [2]. Een belangrijk resultaat uit hun meting is dat de gekozen ZigBee chip zonder antenne niet bruikbaar is voor de metingen. Het probleem is namelijk dat verschillende afstanden dezelfde RSSI waarde geven. Voor een goede meting moet een ZigBee met antenne gebruikt worden. Dit hebben zij met metingen bevestigd. Om een gevoel te krijgen van de relatie tussen RSSI en de daadwerkelijke afstand vermelden we hier ook de resultaten. In figuur 4.9 is de meting te zien die gedaan is met twee ZigBee’s met antenne. Hierbij is gebruik gemaakt van onze opgetelde RSSI waarde. Met de meetresultaten hebben we een benadering voor de RSSI waarde opgesteld: RSSI[dBm] = −23, 594 ∗ ln(a f stand[m]) − 104, 32

(4.1)

Deze benadering is ook te zien in figuur 4.9, dit laat zien dat de relatie tussen de RSSI waarde en de afstand logaritmisch is. Deze meting is binnen verricht.

4.9.2

Throughput communicatienetwerk

Een eis voor de throughput bij de demonstrator is dat elke seconde de gemeten afstanden tussen de quadcopters, de afstanden naar de crawlers en de hoeken naar de crawlers verstuurd kunnen worden. Of dit mogelijk is, zal hier berekend worden. Bij de communicatie is de bottleneck waarschijnlijk de verbinding tussen de ZigBee-module en de T-Minus. Deze UART heeft een baudrate van 57600. De ZigBee-module heeft een RF data rate van 250.000 bps. De RF data bevat waarschijnlijk meer data dan wat naar de ZigBee-module gestuurd 44

4.10. CONCLUSIE wordt, wegens een data header en dergelijke. Hoogstwaarschijnlijk is de verbinding tussen de ZigBeemodule en de T-Minus toch de bottleneck en daar zullen we in de berekening zodoende van uitgaan. De UART verbinding verstuurt geen parity, 1 startbit, 8 databits en 1 stopbit. Voor het versturen van 1 byte zijn zodoende 10 bittijden nodig. De baudrate van 57600 zal dus maximaal 5760 bytes/s aankunnen. De hoeveelheid data die verstuurd moet worden wordt overheerst door de Routing berichten, aangezien de DistanceRequest en DistanceAnswer berichten slechts 1 resp. 2 command data bytes bevatten. Zodoende zal in de berekening geen rekening gehouden worden met deze berichten. Verder zal de processing time van de T-Minus niet meegenomen worden in de berekening. Daarnaast worden bij de API 2 modus die wij gebruiken sommige bytes (slechts 4 v/d 256) ge-escaped wat leidt tot een extra byte per byte dat ge-escaped is. Ook dit zal verwaarloosd worden. De routing berichten zijn maximaal 60 bytes lang: • Data frame header en checksum (figuur 6.3): 5 bytes • Routing bericht header (tabel 4.3): 5 bytes • Afstandsmetingen naar quadcopters en crawlers: max. 15 metingen * 2 bytes/meting = 30 bytes • Hoekmetingen naar de crawlers: max. 10 metingen * 2 bytes/meting = 20 bytes 5760bytes/s Er kunnen dus 60bytes/bericht = 96berichten/s verstuurd worden. Dit zijn dus enkel de Routing berichten, maar deze hebben dan wel elk een maximale grootte. Bij de demonstrator zijn maximaal 10 quadcopters die elke seconde 1 zo’n bericht versturen. Dit kan het communicatienetwerk dus ruim voldoende aan. De verwaarlozingen die we gedaan hebben zullen waarschijnlijk niet zo’n grote invloed hebben dat de throughput te laag blijkt.

4.10

Conclusie

In dit hoofdstuk hebben we gekeken naar de afstandsmeting en communicatie. In deze sectie vergelijken we onze resultaten met de eisen.

Afstandsmeting De eerste eis is dat de afstandsmeting een methode moet hebben die in alle richtingen afstanden kan meten naar de andere quadcopters. Dit hebben we gerealiseerd door ZigBee te gebruiken en daarvan de RSSI waarde te lezen. Uit de resultaten blijkt dat dit een goede methode is om de afstand te berekenen. Volgens de tweede eis moet de afstand bepaald kunnen worden tot 15 objecten voor de demonstrator en 50 objecten voor het uiteindelijke product. De keus voor ZigBee laat maximaal 65000 objecten toe, echter hadden we met 5 ZigBee’s al last van collisions. Om dit op te lossen hebben we een random software delay gebruikt, dit beperkt het aantal objecten. Echter, 50 objecten is in theorie nog steeds haalbaar. De volgende eis is een vorm van identificatie, zodat duidelijk is tot welk object de afstand is gemeten. Elke ZigBee module heeft zijn eigen adres en bij het ontvangen van een bericht is te achterhalen van welke module dat kwam. Wij hebben gekozen om de adressen 10 tot en met 99 te reserveren voor quadcopters en 100-255 voor de crawlers. 45

4.10. CONCLUSIE De vierde eis zegt dat de afstandsmeting binnen 1 seconde de afstand moet kunnen bepalen tot alle andere quadcopters die binnen bereik zijn. Hier voldoen we aan, aangezien de bepalende factor hierin de random delay is. Voor de demonstrator is deze delay maximaal 40 ms. Zelfs als voor de uiteindelijke implementatie deze delay 10 keer zo groot wordt is dit nog binnen de eisen. De gekozen methode moet niet teveel gewicht toevoegen aan de quadcopter en mag niet teveel stroom verbruiken. Ook moet deze monteerbaar zijn aan de quadcopter. Voor het verbruik kwamen we uit op 290mW. De accu’s van de AR.Drone zijn 1000mAh, zodoende kunnen we de draadloze communicatie en afstandsmeting voor 1000mAh/24.4mA = 41.0h gebruiken. Aangezien de AR.Drone ongeveer 15 minuten kan vliegen op dezelfde accu, concluderen we dat het verbruik niet te hoog is. Bij de volgende eis moet gelden dat het bereik van de afstandsmeting gelijk of groter is dan het bereik van de communicatie. Aangezien we voor zowel de afstandsmeting als de communicatie dezelfde hardware gebruiken is dit het geval. Verder moet de afstandsmeting kunnen detecteren wanneer de quadcopters te dicht bij elkaar komen. Uit de meetresultaten blijkt dat de ZigBee met antenne dit goed doet, waarbij we ook een benadering hebben opgesteld voor de RSSI tegen de afstand. De volgende eis is dat de oplossing een nauwkeurigheid van circa twee meter moet hebben. Volgens de resultaten van de andere subgroep [2] is dit haalbaar. Een echt getal voor de nauwkeurigheid volgt niet uit de resultaten, maar een nauwkeurigheid van 2 meter is mogelijk tot een afstand van 8 meter, zie ook figuur 4.9. Daarbij mogen geen storende signalen (bijv. wifi) aanwezig zijn op dezelfde frequentie. De laatste eis was dat de meting onafhankelijk moest zijn van beacons op vaste plaatsen. Dit is bij de gekozen methode het geval.

Communicatie Voor de communicatie bestaan ook een aantal eisen en ‘nice-to-haves’. Volgens de eerste eis moeten alle berichten die vanuit de quadcopters verstuurd worden kunnen overkomen bij het basisstation. Hierbij gaan we ervan uit dat niet alle quadcopters binnen het bereik hoeven te zijn van het basisstation. Een eis is dus ook dat de quadcopters berichten kunnen forwarden (hopping). De hopping hebben we getest met 4 ZigBee module’s en dit werkte zoals verwacht. De routing werkt goed, de routingbuffer zorgt ervoor dat berichten niet dubbel aankomen en gaan oscilleren in het netwerk. Wel hebben we gezien dat niet altijd alle berichten binnenkomen, mogelijk zijn er nog collisions. De tweede eis is dat het bereik van de communicatie circa 10 meter moet zijn voor een goede demonstratie. Dit moet echter vergroot kunnen worden naar circa 100 meter voor een eventuele uiteindelijke toepassing. De keus van ZigBee zorgt voor een maximaal (indoor) bereik van ongeveer 30 meter, wat voldoende is voor de demonstratie. Indien de modules buiten worden gebruikt zouden deze 100 meter kunnen halen. Eventueel kan gekozen worden voor een sterkere variant, bijvoorbeeld de XBee-PRO, met een outdoor bereik van 1500 meter. De volgende eis is dat, voor de demonstratie, de gemeten afstanden tussen de quadcopters, de afstanden naar de crawlers en de hoeken naar de crawlers verstuurd worden over het netwerk. Deze data moet vervolgens bij het basisstation op de PC verwerkt kunnen worden. Dit hebben we gerealiseerd door een speciale PC-node te ontwikkelen die de data doorgeeft aan de computer. Op de computer kan vervolgens de data worden uitgelezen via een seriële poort. De eis voor throughput is dat de afstanden en hoeken, die ongeveer elke seconde gegenereerd wordt door de objecten, verstuurd kunnen worden. De berekeningen bij de resultaten laten zien dat de throughput die mogelijk is, veel hoger is dan bij de demonstrator gebruikt zal worden. De latency mag maximaal 1 seconde zijn, zodat de software voor de besturing nog tijdig kan reageren op de 46

4.11. AANBEVELINGEN meetwaarden. In de console is waargenomen dat de metingen binnenkomen voordat nieuwe metingen gestart worden. Aangezien deze elke seconde worden gegenereerd is de latency minder. Bovendien hadden we ook gezien dat bij het weglaten van de routingbuffer het netwerk met een hoge frequentie ging oscilleren (heen en weer berichten sturen). Bij de volgende eis moet gelden dat de module niet teveel gewicht mag toevoegen aan de quadcopter en niet teveel stroom mag verbruiken, zodat de quadcopter kan blijven vliegen en de gebruiksduur meer dan 10 minuten blijft. Ook moet deze monteerbaar zijn aan de quadcopter. Aangezien we voor de communicatie dezelfde hardware gebruiken als bij de afstandsmeting is het verbruik en gewicht gelijk. De gebruiksduur zit zeker boven de 10 minuten indien de quadcopter tussentijds land, aangezien de AR.Drone zonder te landen al 10 minuten kan vliegen. De volgende eis is dat van elk bericht de oorsprong bekend moet zijn, dus door welke quadcopter deze gegenereerd is. De realisatie is al genoemd bij de conclusie van de afstandsmeting; de ZigBee modules hebben elk hun eigen adres. Als laatste eis hebben we dat dezelfde berichten niet meerdere keren op de PC ontvangen moeten worden. Dit is opgelost door in een buffer bij te houden welke berichten al verstuurd zijn. In deze buffer slaan we een adres en volgnummer op. Verder hebben we nog een nice-to-have dat de quadcopters een acknowledgement krijgen als berichten goed ontvangen zijn door alle quadcopters binnen bereik. Zo kan een bericht opnieuw verstuurd worden als er geen acknowledgement ontvangen is. Dit hebben we niet geïmplementeerd omdat dit meestal een broadcast bericht is.

4.11

Aanbevelingen

Voor de afstandsmeting hebben we als aanbeveling om andere manieren te proberen om collisions te voorkomen. Mogelijk werkt het beter om zowel instellingen op de ZigBee te veranderen als een random software delay te gebruiken. Een andere mogelijkheid is dat er berichten verdwijnen doordat wifi signalen storen op dezelfde frequentie. Hiervoor kan ZigBee ingesteld worden op een ander kanaal. Verder kan er nog gekeken worden of een snelheid sneller dan 57600 baud mogelijk is. Voor zowel de afstandsmeting als communicatie kan verder kan nog gekeken worden naar manieren om ontvangstbevestigingen te sturen bij de berichten. Hiermee zouden de berichten gegarandeerd moeten aankomen. Een mogelijkheid is het gebruik van de in ZigBee ingebouwde ACK optie. Voor een broadcast bericht moet echter een andere methode bedacht worden. Verder kan er nog getest worden met meer ZigBee’s. Bij onze testen hadden we maximaal 5 ZigBee’s tot onze beschikking. Mogelijk brengt dit weer andere problemen met zich mee. In de routing zit nu een limiet van 100 bytes aan data dat verstuurd kan worden. Indien grotere pakketten nodig zijn dienen deze opgedeeld te worden en in stukken verstuurd te worden. Dit limiet komt van het ZigBee protocol. Mocht een betere nauwkeurigheid gewenst zijn kan bijvoorbeeld de RSSI meting gecombineerd worden met LQI.

47

48

Hoofdstuk 5

Reflex In dit hoofdstuk bespreken we de reflex. De reflex is nodig om te voorkomen dat de quadcopters tegen elkaar vliegen (collision avoidance). Voor onze groep is de reflex een nice-to-have, aangezien de zwerm aansturing deze botsingen al moet voorkomen. Echter als het basisstation uitvalt of als de intelligentie een verkeerd besluit neemt, willen we graag dat de quadcopters niet botsen. Dit zorgt ook voor een soort ‘instinct’ in de quadcopters, dat ze ook zelf een besluit nemen.

5.1

Ontwerpeisen

Zoals hiervoor vermeld is, is de reflex een nice-to-have. Voor de reflex zijn een aantal eisen die gewenst zijn, zoals volgt uit de probleembeschrijving (zie sectie 2.2). Verder zullen we ook hier een aantal ‘nice-to-haves’ geven om aan te geven dat zij minder prioriteit hebben. • De quadcopters mogen niet botsen met elkaar, ook niet als het basisstation dit als commando stuurt. • De afstand tussen twee quadcopters moet ten alle tijden minimaal 2 meter zijn. • Indien twee quadcopters te dichtbij komen moet er tenminste één landen op de grond. • De reflex moet blijven werken indien de communicatie met het basisstation wegvalt. • Nice-to-have: het uitvoeren van een uitwijkmanoeuvre in plaats van landen. Bijvoorbeeld dat de ene quadcopter omhoog gaat en de andere omlaag.

5.2 5.2.1

Ontwerpkeuzes Mogelijkheden collision avoidance

Een van de mogelijkheden om dit te implementeren is door gebruik te maken van een camera op de quadcopter. De Parrot AR.Drone heeft deze standaard erop zitten. In paper [42] worden een aantal algoritmes gegeven die hiermee een collision kunnen voorkomen. Ze hebben dit getest in een gang en bij trappen, dit werkte in de meeste gevallen goed. Een ander paper [43] gebruikt ook de camera, maar dan met een ‘fuzzy controller’. Deze oplossing is in staat om snel te reageren. 49

5.3. IMPLEMENTATIE Een andere mogelijkheid is het gebruiken van een lasersysteem waarbij de laser continu beweegt om zo een 3D beeld te krijgen [44]. Vervolgens kan met bijvoorbeeld SLAM (Simultaneous Localization And Mapping) een beeld gevormd worden van de omgeving om een botsing te voorkomen. Voorgaande documenten waren vooral handig bij een statische ruimte, echter als opeens een mens door de kamer loopt kan dit problemen geven. Paper [45] gaat over een collision avoidance bij een ruimte met mensen. Dit is gebaseerd op een Quad Virtual Force Field (QVFF). De resultaten zijn zeer goed, het QVFF algoritme was beter dan 5 andere algoritmes waarbij een mens in een onvoorspelbare weg loopt. Een wat eenvoudigere oplossing om een collision tussen de quadcopters te voorkomen is het gebruik maken van een een soort ‘bubble’ om de quadcopter heen [46]. Wanneer daarbinnen een andere quadcopter komt voer je een uitwijkmanoeuvre uit. De minimale straal van deze ‘bubble’ is 5 tot 15 keer de lengte van het toestel.

5.2.2

Keuze collision avoidance

Wij hebben gekozen voor een eenvoudige oplossing, zoals de ‘bubble’, omdat de collision avoidance enkel een reflex is en een botsing eigenlijk niet zou moeten voorkomen. Mogelijkheden als een camerasysteem en SLAM zijn meer bedoeld als ‘ogen’ voor de UAV als hierop de gehele verplaatsing gebaseerd moet zijn. Dit zijn bovendien ingewikkelde onderwerpen waar nog veel onderzoek naar gedaan wordt. Een eenvoudige afstandsbepaling tussen de quadcopters zou voor ons doel moeten volstaan. Deze afstandsmeting hebben we al gerealiseerd met ZigBee. Aangezien de afstandsmeting elke seconde plaatsvindt en daarbij ook de RSSI bekend is, kiezen we ervoor om de reflex te combineren met de huidige afstandsmeting. Hierin zal het programma kijken wanneer de RSSI waarde onder een bepaalde drempel waarde komt. Op de AR.Drone zit een seriële poort, onze keus is om een bericht te sturen vanuit een seriële poort op de microcontroller naar de seriële poort op de AR.Drone. Op de quadcopter zal continu een programma draaien dat de seriële poort uitleest. Indien het bericht ontvangen wordt moet de AR.Drone intern een AT commando sturen om te landen. Deze oplossing voorkomt alleen niet een collision met de muur of obstakels, maar in een eenvoudige ruimte zoals bij de demonstratie wordt daarvoor het bereik beperkt met speciale beacons, zoals vermeld bij het Systeemoverzicht (sectie 2.1).

5.3

Implementatie

In deze sectie beschrijven we hoe we de reflex hebben geïmplementeerd. Dit bestaat uit twee delen, de kant van de microcontroller en de kant van de quadcopter. De hieronder beschreven implementatie is gericht op de AR.Drone V2.

5.3.1

Code op de microcontroller

De communicatie met de AR.Drone gaat via een seriële poort. De gebruikte T-Minus bordjes hebben beschikking over vier seriële poorten, waarvan één al in gebruik door ZigBee en een andere voor communicatie met de PC. In de setup() functie voegen we daarom een nieuwe seriële poort toe: Serial3.begin(115200). De keuze voor 115200 baud is omdat de AR.Drone dit standaard als snelheid heeft op de seriële poort. Vervolgens hebben we in de functie die zorgt voor het afhandelen van binnenkomende DistanceAnswer berichten het volgende toegevoegd: 50

5.3. IMPLEMENTATIE Listing 5.1: Reflex toevoeging aan HandleDistanceAnswer i f ( R S S I v a l u e < MIN_RSSI_DISTANCE && a d d r e s s < 1 0 0 ) { visualizeReflex ( true ) ; f o r ( i n t i = 0 ; i
1 2 3 4 5 6 7 8

De code kijkt wanneer de opgetelde RSSI waarde (de heen en terug RSSI) kleiner is dan een vooraf gedefinieerde waarde en wanneer het adres kleiner is dan 100. Dit is omdat de quadcopters een adres hebben tussen 10 en 100. De crawlers hebben een adres boven de 100 en je wilt niet dat de quadcopter neerstort als hij vlakbij een crawler is. Vervolgens hebben we een functie gemaakt die een aantal LEDs aanzet (visualizeReflex), zodat we kunnen zien dat de reflex werkt. Hierna wordt een aantal keer het bericht ‘stop’ verstuurd over de seriële poort. Het aantal keer dat dit verstuurd wordt is instelbaar en heeft als doel dat we dan zeker weten dat het bericht aankomt. Met de flush() worden de buffers geleegd en het bericht verstuurd.

5.3.2

Code op de AR.Drone V2

Aangezien de AR.Drone Linux draait is het mogelijk om een eigen programma te schrijven dat naast de andere programma’s draait. In ons programma willen we de seriële poort uitlezen en zodra daar het woord ‘stop’ komt, moet het programma intern een AT commando sturen. Ontvangen op de seriële poort Hierbij openen we eerst de seriële poort, vervolgens kijken we per ontvangen karakter of deze overeenkomt met het verwachte karakter uit ‘stop’. Indien dit klopt voor het volledige woord, sturen we het AT commando. Versturen AT commando Door het versturen van AT commando’s is het mogelijk om de AR.Drone te laten landen. Het programma moet de commando’s sturen naar zichzelf, IP adres 127.0.0.1. Om de commando’s te sturen wordt eerst een socket aangemaakt voor de AT commando’s. Vervolgens kan via de volgende code een commando tot landen verstuurd worden:

Listing 5.2: AT comando voor landen/reflex 1 2 3 4 5 6

c h a r command [ 2 5 6 ] ; s n p r i n t f ( command , 2 5 6 , "AT* REF=%d ,%d \ r " , p a c k e t _ s e q ++ , ATREF_DEFAULT ) ; a t _ c o m _ s e n d ( command ) ;

Hierin stelt ATREF_DEFAULT het AT commando voor dat zorgt voor de landing. Hoe de code gecompileerd kan worden voor de AR.Drone V2 en vervolgens hierop uitgevoerd kan worden, wordt beschreven in bijlage C. 51

5.4. TESTEN

5.4

Testen

In deze sectie testen we verschillende onderdelen voor de reflex. Er zijn tests gedaan met het T-Minus bord, met de AR.Drone en met de communicatie tussen beide.

5.4.1

T-Minus bord

Op het T-Minus bord is MIN_RSSI_DISTANCE ingesteld op een waarde van 115, omdat dit overeenkomt met een afstand van 2 meter. We hebben gecontroleerd dat de reflex LEDs aangaan als de afstand kleiner wordt dan circa 2 meter. Bovendien is waargenomen dat de tekst “stop” goed verzonden wordt over de seriële poort (met het juiste aantal). Dit werkt dus naar behoren.

5.4.2

Quadcopter seriële verbinding

Op de quadcopter is gecontroleerd of de ‘stop’ die door de T-Minus verstuurd wordt ook ontvangen en herkend kan worden door de quadcopter. Hiertoe is op het moment dat een match plaatsvindt een bericht geprint door middel van de printf waarvan het resultaat in de telnet verbinding zichtbaar wordt. Verder wordt de ruwe data die op de seriële poort binnenkomt geprint. Er is waargenomen dat niet altijd deze ‘stop’ tekst herkend wordt, omdat niet alle characters goed ontvangen zijn. Zodoende is REFLEX_NUM_SEND op 2 ingesteld om de kans te vergroten dat een stop herkend wordt, als deze verstuurd wordt. In dit geval werd de ‘stop’ altijd gedetecteerd en de eerdere gemiste berichten waren nu herkenbaar. Zo werd regelmatig de ‘stop’ herkend in de string “topstop” waar duidelijk de ‘s’ niet ontvangen werd. Voor de uiteindelijke toepassing is REFLEX_NUM_SEND zelfs op 3 ingesteld om er echt zeker van te zijn dat de ‘stop’ ontvangen wordt. Dit is ook nog even getest en werkt naar behoren.

5.4.3

Quadcopter AT commando’s

Bij de quadcopter is ook getest of deze intern AT commando’s naar zichzelf kan sturen. Daartoe hebben we eerst het AT commando gestuurd voor het laten opstijgen van de AR.Drone en na één seconde sturen we onmiddellijk het commando voor het laten landen. Er is waargenomen dat de motoren aangaan en net voordat de AR.Drone wil opstijgen weer uitgaan. Er kunnen dus intern AT commando’s gestuurd worden. Voor de toepassing van de reflex moeten echter niet alleen de interne AT commando’s uitgevoerd worden, maar ook de externe AT commando’s die via WiFi binnenkomen. Om te controleren of dit nog steeds mogelijk is, is via de eerder geschreven quadcopter aansturing op de PC het commando gegeven om de AR.Drone te laten opstijgen. Meteen nadat de motoren aan zijn gegaan, is via de seriële poort “stopstopstop” naar de quadcopter gestuurd (zoals de T-Minus ook zal doen). In reactie daarop gingen de motoren van de AR.Drone weer uit. Het is dus mogelijk om zowel de interne als de externe AT commando’s uit te voeren.

5.5

Resultaten

Uit de verschillende tests volgt als resultaat dat de meet- en communicatiemodule met de T-Minus kan herkennen wanneer de reflex moet worden uitgevoerd en dan de tekst “stopstopstop” naar de AR.Drone verstuurt. De AR.Drone kan in deze tekst ‘stop’ herkennen en kan in reactie daarop de 52

5.6. CONCLUSIE quadcopter laten landen. Bovendien kunnen er nog steeds AT commando’s vanaf de PC verstuurd en uitgevoerd worden. Theoretisch zal de reflex dus moeten werken. Bij het voorbereiden van de uiteindelijke integratietest is de AR.Drone echter stuk gegaan. Zodoende hebben we de werking van de reflex niet volledig kunnen controleren.

5.6

Conclusie

In dit hoofdstuk hebben we gekeken naar de reflex. Zoals bij de resultaten besproken, hebben we de uiteindelijke werking hiervan niet kunnen controleren. Alle subsystemen werken echter naar behoren. In deze sectie vergelijken we onze resultaten met de eisen. De eerste eis is dat de quadcopters niet met elkaar mogen botsen, ook niet als het basisstation dit als commando stuurt. Dit kon niet gecontroleerd worden, maar wel is bewezen dat alle voorwaarden hiervoor aanwezig zijn. Er is echter misschien nog altijd een mogelijkheid tot botsing. Namelijk als het basisstation herhaaldelijk het commando voor opstijgen blijft sturen terwijl de reflex in werking moet treden en dus herhaaldelijk het commando voor het landen stuurt. Wat in zo’n conflictsituatie gebeurt kon niet getest worden. De tweede eis is dat de afstand tussen twee quadcopters ten alle tijden minimaal 2 meter moet zijn. Deze eis is ook niet getest, maar wel treedt het reflexmechanisme in werking als twee T-Minus bordjes een onderlinge afstand van minder dan 2 meter hebben. Aan de derde en vierde eis wordt ook voldaan indien de integratie werkt. Daarbij zullen nu waarschijnlijk nog beide quadcopters landen. Een eenvoudige maatregel om maar één quadcopter te laten landen is om de quadcopter met bijvoorbeeld het laagste of het hoogste adres te laten landen. Van de meting die de reflex inschakelt is namelijk bekend tot welk adres deze gemeten is.

5.7

Aanbevelingen

Als aanbeveling geldt het testen van de volledige geïntegreerde reflex. Daarbij moet ook onderzocht worden wat gebeurt in de conflictsituatie die beschreven is bij de Conclusie (sectie 5.6). Dit conflict moet eventueel opgelost worden of er moet door middel van een maatregel voorkomen worden dat deze situatie zich voor kan doen. Een andere aanbeveling is om in te stellen dat zo min mogelijk quadcopters landen indien ze te dicht bij elkaar komen, zodat de overige quadcopters zo snel mogelijk kunnen wegvliegen. Daarnaast kan de nice-to-have uitgewerkt worden, zodat de normale zwermintelligentie sneller kan hervatten.

53

54

Hoofdstuk 6

Procesbeschrijving Dit hoofdstuk bevat de onderdelen uit het ontwerpproces die doorlopen zijn, maar uiteindelijk niet in het verkregen resultaat terugkomen.

6.1

Aansturing quadcopters

Het proces dat doorlopen is vanaf de eerste ontwerpkeuze tot het begin met de implementatie is samengevat in de flowchart van figuur 6.1 en zal hieronder beschreven worden. Zoals duidelijk wordt uit deze flowchart zijn niet alle hieronder beschreven mogelijkheden in het uiteindelijke product terug te vinden. Uiteindelijk is een steeds specifiekere en eenvoudigere oplossing gezocht die nog aan onze eisen voldoet.

6.1.1

SDK versie van Paparazzi

In de ontwerpkeuzes (sectie 3.2) is er eerst voor gekozen om Paparazzi in combinatie met de AR.Drone V2 te gebruiken. Deze combinatie is in een minor project aan de TU Delft op twee manieren geïmplementeerd: een RAW versie en een SDK versie. De RAW versie gebruikt de raw data van de sensoren op de quadcopter en berekent hiermee de aansturing voor de motoren. De SDK versie laat de autopilot werken met de software development kit van Parrot. Uit een gesprek met Dino Hensen, die verbonden is aan de verdere uitwerking van deze minor projecten, is gebleken dat voor ons de SDK versie het geschiktst is. De RAW versie is namelijk nog niet af en kan bovendien nog niet heel stabiel vliegen. Ook zijn er nog problemen bij het landen en opstijgen. Als eerste hebben we geprobeerd de Paparazzi autopilot software werkend te krijgen, en wel deze speciale SDK versie voor de AR.Drone V2. De benodigde code hebben we van de github repository https://github.com/RoboticaTUDelft/Paparazzi gedownload. De SDK versie die tijdens de minor ontwikkeld is, is te vinden in de “minor2” branch. Bij het builden van deze software verschijnt echter een error. Na het verhelpen van deze error (een fout in luftboot.c bij de aanroep van een bibliotheekfunctie) lukt het echter wel om de Paparazzi software te builden en vervolgens op te starten. Als men echter vervolgens bij A/C (aircraft) de “ardrone2” kiest en deze code probeert te builden, verschijnen een reeks errors. Zodoende zijn we van deze Paparazzi versie, die tijdens de minor is ontwikkeld, afgestapt. Na wederom contact opgenomen te hebben met Dino Hensen bleek dat we beter de branch 55

6.1. AANSTURING QUADCOPTERS

Figuur 6.1: Flowchart van het doorlopen proces van ontwerpkeuze tot implementatie. De dikke lijn geeft het gevolgen pad aan.

56

6.1. AANSTURING QUADCOPTERS “ardrone_to_master” konden gebruiken. Die versie had hij ontwikkeld uit de code die gemaakt was bij de minorprojecten. Hierbij lukte het wel in één keer om de software te builden en te starten.

6.1.2

Van Paparazzi naar de SDK van Parrot

Uit de werkende Paparazzi software en het bekijken van de source code werd duidelijk dat de SDK versie van Paparazzi eigenlijk enkel GPS functionaliteit toevoegde aan de AR.Drone V2. Het eigenlijke vliegen en de stabilisatie wordt nog door de AR.Drone V2 geregeld. Door het sturen van AT commando’s, die beschreven zijn in de SDK van Parrot, wordt de quadcopter bestuurd. Deze AT commando’s zijn door Parrot bedoeld als manier om de quadcopter van afstand te besturen. Bij Paparazzi wordt echter een applicatie gecreëerd die naast de gewone software op de AR.Drone V2 draait. Via interne communicatie worden vervolgens de AT commando’s verstuurd en data over de status van de quadcopter ontvangen. Wij hebben er echter voor gekozen om geen absolute locatiebepaling te implementeren voor het vliegen met de quadcopter. Deze keuze is met de hele groep gemaakt, met als reden dat een zwerm z’n locatie niet nodig heeft. De zwerm weet alleen welke richting en afstand ze op moeten. Bij het volgen van een grond object is het dus voldoende om de afstand en hoek te weten. De GPS functionaliteit is zodoende niet nodig bij onze toepassing, bovendien zou dit het product ook duurder maken en meer energie verbruiken. Daarnaast is ervoor gekozen om tijdens het ontwikkelen van het product gebruik te maken van een basisstation die alle quadcopters aanstuurt. Dit is tevens besloten binnen onze groep, aangezien we zo eenvoudiger de zwerm kunnen testen. De SDK versie van Paparazzi voegt zodoende geen bruikbare functionaliteiten toe voor onze toepassing in de ontwikkelfase. Later, als de zwerm intelligentie op de quadcopter geïmplementeerd is, is wel deze interne communicatie van AT commando’s nodig en kunnen we hiervoor deze functionaliteit van de SDK versie van Paparazzi gebruiken. Zoals eerder vermeld, beschikt de AR.Drone V2 over een wifi verbinding. Hierover kunnen de AT commando’s verstuurd worden naar de quadcopter door middel van de SDK van Parrot. De tussenkomst van Paparazzi als autopilot is dus niet noodzakelijk gebleken. Zodoende zal direct gebruik gemaakt worden van de SDK van Parrot.

6.1.3

Van de SDK van Parrot naar AT commando’s

De officiële SDK van Parrot is te vinden op [47]. Hierbij zit ook een Developer Guide ([4]) waarin de SDK en de aansturing met AT commands wordt uitgelegd. In de SDK zijn ook enkele voorbeelden van Linux programma’s te vinden. Deze hebben we getest, waarmee we een quadcopter met een Xbox 360 controller konden besturen. Vervolgens zijn we de code gaan aanpassen naar onze wensen. Hier kwamen we er achter dat de SDK te complex is om gemakkelijk aan te passen naar het gebruik van meerdere quadcopters die onafhankelijk bestuurd dienen te worden. Bovendien draait er voor de quadcopter een speciale thread voor de video processing die niet gemakkelijk uit de code te verwijderen is. Bij het gebruik van meedere quadcopters is het niet gewenst deze zware taak er telkens in te laten. Voor de echte aansturing van de quadcopter gebruikt de SDK van Parrot simpelweg de AT commando’s die in de Developer Guide beschreven zijn. Aangezien dit voor ons voldoende is en de SDK weer veel mogelijkheden toevoegt die niet interessant zijn voor onze toepassing, is gezocht naar een voorbeeldprogramma dat de AT commando’s kan versturen. Uit zo’n voorbeeld is ons uiteindelijke product ontstaan. 57

6.2. ZIGBEE MODULES

Figuur 6.2: Flowchart van het doorlopen proces van het testen van de ZigBee-module.

6.2

ZigBee modules

Het proces dat doorlopen is voor het systematisch evalueren van de ZigBee-module als geschikte afstandsmeter en de opstap naar de implementatie zal hier worden beschreven. Dit proces is samengevat in figuur 6.2. Hierbij worden de beide mogelijke operating modes van de ZigBee-module bekeken, met allereerst de default transparent mode die minder geschikt zal zijn en vervolgens de API operating mode.

6.2.1

Transparent operation

De ZigBee-modules staan standaard in transparent operation. In deze modus gedragen ze zich als vervanging voor een seriële verbinding. De RSSI waarde kan enkel opgevraagd worden door in AT Command Mode te gaan. Dit kan als volgt [3]: 1. Eén seconde wachten 2. Binnen één seconde “+++” sturen. 3. Eén seconde wachten Bij succes antwoord de module met “OK”. Vervolgens kan de RSSI waarde opgevraagd worden door “ATDB” afgesloten met een Carriage Return te sturen. De module stuurt dan de RSSI waarde van het laatst ontvangen bericht terug in hexadecimaal als leesbare waarde (bijv. "1D"= 0x1D = 29 = -29dBm). Als er geen RSSI waarde beschikbaar is dan wordt een 0 gestuurd. Dit is geverifieerd in onze onderzoeksruimte en werkt prima. Daarbij zijn twee ZigBee-modules gebruikt die in eerste instantie tegen elkaar gehouden werden. Na het versturen van een bericht door de ene module, is bij de andere ontvangende module de RSSI waarde opgevraagd. Deze had een waarde van -23dBm. Dit is een aantal keer herhaald voor iets grotere afstanden tot 1 meter. Bij een afstand van ca. 1 meter werd een signaalsterkte van -51dBm ± 1dBm gemeten en bij kleinere afstanden een grotere signaalsterkte. 58

6.2. ZIGBEE MODULES

Figuur 6.3: Opbouw van een data frame in API operation. [3] API Type

Modem Status AT Command AT Command - Queue Parameter Value AT Command Response TX (Transmit) Request: 64-bit address TX (Transmit) Request: 16-bit address TX (Transmit) Status RX (Receive) Packet: 64-bit Address RX (Receive) Packet: 16-bit Address

API Identifier 0x8A 0x08 0x09

Richting

Beschrijving

IN OUT OUT

Bij specifieke gebeurtenissen (reset e.d.) Module parameters instellen of opvragen Als AT command, maar wijzigingen worden niet meteen opgeslagen 0x88 IN Bevat de opgevraagde module parameter 0x00 OUT Zorgt voor het versturen van de data naar een meegegeven 64-bits adres 0x01 OUT Zorgt voor het versturen van de data naar een meegegeven 16-bits adres 0x89 IN Status van het verzonden packet 0x80 IN De ontvangen data, met 64-bits source address en RSSI waarde 0x81 IN De ontvangen data, met 16-bits source address en RSSI waarde Tabel 6.1: Mogelijke data frames in API operation. [3]

Nauwkeurigere metingen zijn hier niet verricht, omdat aangetoond is dat de RSSI als maat voor de afstand gebruikt kan worden. Dit was reden om door te gaan met de implementatie van deze meettechniek, zodat gemakkelijker metingen verricht kunnen worden.

6.2.2

API operation

De transparant mode is voor ons niet geschikt, want als er waarden ingesteld (e.g.: destination address) of opgevraagd (e.g.: RSSI waarde) moeten worden, moet overgegaan worden naar de AT Command Mode. Dit kost telkens enige tijd (de wachttijd van 1 seconde kan wel op een lagere waarde ingesteld worden) en is omslachtig. De andere operation mode is de API operation. Met de module wordt dan geïnterfaced door middel van data frames. Deze zien eruit als in figuur 6.3. De mogelijke data frames staan in tabel 6.1. Zoals te zien is, kan bij het versturen meteen het bestemmingsadres meegegeven worden. Een speciaal adres is daarbij gereserveerd voor een broadcast. Bij het ontvangst van een bericht is meteen duidelijk van welk adres deze kwam en wat de signaalsterkte was. Dit is zeer geschikt voor onze toepassing. Testen van de API operation Met behulp van het programma X-CTU hebben we de ZigBee-modules geconfigureerd in API mode 1 (characters not escaped). Bovendien is voor elke module een adres ingesteld beginnend vanaf 10 (hexadecimaal ‘A’). 59

6.2. ZIGBEE MODULES Byte Type Waarde

0 Start delimiter 0x7E

5 Destination address (MSB) 0xFF

1 Length (MSB) 0

6 Destination address (LSB) 0xFF

7 Options

2 Length (LSB) 7 ... 8 RF Data

0x01

inByte

3 API Identifier 0x01

4 Frame ID 0

9 RF Data

10 Checksum

‘B’

checksum

Tabel 6.2: De data frame voor het testen van de zender in API operation.

Vervolgens hebben we voor de microcontroller een eenvoudig programma gemaakt dat telkens als op de serial poort (die met de PC verbonden is) een byte beschikbaar is, deze samen met een vast ander character (‘B’) verstuurd wordt, zie de bijlage voor deze code D. Hiervoor wordt een TX Request met 16-bits adressering gecreërd, deze ziet eruit als in tabel 6.2. Voor het lengte-veld en het checksum-veld worden enkel de 7 bytes van 3 tot en met 9 gebruikt en het frame ID is op 0 gezet zodat er geen response frame komt. Het 16-bits destination address is 0xFFFF wat ervoor zorgt dat het bericht gebroadcast wordt. Het options-veld staat op 0x01, waardoor acknowledges uitgeschakeld zijn. Vervolgens volgt de RF data, hierbij is inByte het databyte dat ontvangen is over de seriële verbinding met de PC. De checksum wordt als volgt berekend (in buffer staat het bericht): " checksum = 255 −

9

∑ buffer[i]

!

# mod 256

i=3

Het gecreëerde bericht wordt vervolgens over de serial die verbonden is met de ZigBee-module verstuurd. Op een tweede ZigBee-module, die rechtstreeks met de PC verbonden was, kregen we vervolgens een RX Packet die correcte waarden in de juiste velden bevatte. Zo klopte het sourceaddress, de data en leek de RSSI waarde correct. De API operation werkt dus naar behoren en kan bij onze implementatie van de afstandsmeting en de communicatie gebruikt worden.

6.2.3

Xbee library

Voor het maken van de berichten en het ontvangen ervan hebben we een C++ bibliotheek gevonden [41]. Hiervoor moeten de ZigBee-modules in API mode 2 (with escaped characters) gezet worden. Deze library hebben we uitgebreid getest. Standaard wordt de serial gebruikt die met de PC verbonden is. Zodoende is met setSerial() Serial1 (UART1) ingesteld, want hierop was de ZigBee-module aangesloten. Bij het zenden hebben we gecontroleerd of we berichten gericht kunnen sturen naar een specifiek adres en of een broadcast werkt. Daarnaast hebben we gecontroleerd of we berichten met meerdere data bytes kunnen versturen en ontvangen. Bij het ontvangen is gecontroleerd of het juiste aantal data bytes achterhaald kan worden en of de data klopt. Verder is gecontroleerd of het source adres en de RSSI waarde juist zijn. Deze zijn namelijk van groot belang voor onze toepassing. De voorbeeldcode gaat ervan uit dat na het verzenden er een TX Status terugkomt. Er is getest of de library ook werkt zonder acknowledges en status controle (DISABLE_ACK_OPTION als TX option en geen controle op TX_STATUS_RESPONSE). Dit werkte naar behoren. Voor de berichten die gebroadcast 60

6.3. ZIGBEE COLLISIONS worden, is deze controle namelijk niet zinnig. Bij de implementatie zal gekozen worden of dit al dan niet geïmplementeerd wordt voor de specifiek geadresseerde berichten. De library is dus geschikt en zal gebruikt worden bij de implementatie.

6.3

ZigBee collisions

Het proces dat doorlopen is voor het oplossen van de collisions tussen de verschillende ZigBeemodules zal hier worden besproken. Dit proces is samengevat in figuur 6.4.

6.3.1

ZigBee-module instellingen

Als eerste hebben we de random delay slots van 0 op 1 gezet, dit is een back-off exponent in het CSMA-CA (Carrier Sense Multiple Access with Collision Avoidance) algoritme. Dit gaf een beter resultaat, maar nog steeds miste we pakketjes. Vervolgens hebben we de baud rate van 9600 verhoogt naar 115200. Dit is de snelheid tussen de ZigBee en computer, heeft geen invloed op de snelheid tussen de ZigBee’s. We gebruikten zowel de Arduino Uno als de T-Minus voor het testen, aangezien op dit moment nog niet genoeg T-Minus beschikbaar waren. Hier kwamen we er achter dat de Uno niet werkt met 115200. Daarna hebben we ze allemaal op een baudrate van 57600 gezet met 1 delay slot, dit gaf hetzelfde resultaat als eerder. Toen hebben we het aantal retries verhoogt naar 3, dit gaf geen merkbare verbetering. Vervolgens hebben we de MAC mode veranderd van 0 (802.15.4 + MAXSTREAM HEADER W/ACK) naar 3 (802.15.4 + MAXSTREAM HEADER NO ACK) met een random delay slot van 0. Hiermee komen er zeker geen acknoledgments, waarmee het kanaal nog meer belast zou worden. Dit werkte slecht, hierbij kregen we telkens maximaal 1 antwoord terug.

Figuur 6.4: Flowchart van het doorlopen proces van het oplossen van het collisions probleem. De dikke lijn geeft het gevolgen pad aan.

61

6.4. ZIGBEE AFSTANDSTABEL

6.3.2

Software oplossing

Omdat het anders instellen van de ZigBee’s nog niet de gewenste resultaten geeft gaan we zelf een random delay in onze code toevoegen. Dit hebben we eerst gedaan als een delay tussen 0 en 10 ms met bij totaal geen acknowledgements en retries. Dit gaf goede resultaten, meestal 2-4 reacties van de verwachte 4. Dit is equivalent met de beste resultaten bij ZigBee instellingen van ACK + retries + delay exponent 3. Vervolgens hebben we de random software delay vergroot naar 2 ∗ random(0, 20) ms, zodat er vrijwel altijd minimaal 2ms tussen de antwoorden zit. Dit geeft zeer goede resultaten, waarbij meestal alle 4 de reacties van de ZigBee’s binnenkomen. Voor deze oplossing is zodoende gekozen.

6.4

ZigBee afstandstabel

Het opslaan in de tabel gaat als volgt. Allereerst wordt gekeken of het adres van het object waarnaar de afstand bepaald is al in de tabel staat. Als dit het geval is, wordt de RSSI waarde opgeslagen in het rssi veld en wordt de age op 0 gezet om aan te geven dat het nieuwe data is. Als het adres nog niet in de tabel staat, dan moet deze op een lege plaats in de tabel gezet worden. Bij het controleren of het adres al in de tabel staat, wordt over elke rij geïtereerd. Op het moment dat voor het eerst een lege plek gevonden is, wordt de index van deze plek opgeslagen. Zodoende kan een nieuwe meting naar een object die nog niet in de tabel stond meteen opgeslagen worden op deze plek. Daartoe wordt wederom de RSSI waarde in rssi opgeslagen en de age op 0 gezet. Bovendien wordt het adres van het object dat het antwoord stuurde opgeslagen in het veld adres. Bij het versturen van de meetresultaten over het ZigBee-netwerk moeten de metingen uit deze afstandstabel gehaald worden. Daartoe wordt over de tabel geïtereerd en wordt van elke rij waarbij het address niet 0 is het address en de rssi in het bericht geplaatst. De age is enkel voor het opvangen van de gaten in de datastromen en is niet interessant voor het basisstation en wordt zodoende niet meegestuurd.

6.5

ZigBee communicatie

Tijdens het testen van de ZigBee communicatie hebben we onder andere getest wat er gebeurt als we de routing tabel weglaten. De noodzaak van de routing tabel is namelijk dat berichten alleen worden doorgestuurd als deze nog niet eerder zijn doorgestuurd. In theorie stuurt node A een bericht en node B stuurt dit door. Vervolgens ontvangt node A dit bericht weer en stuurt deze ook door. Zo zou je een oscillerend effect krijgt. We hebben dit getest en dit gebeurde ook daadwerkelijk, we hebben dus de routing buffer nodig.

62

Hoofdstuk 7

Discussie en Conclusie In deze thesis hebben we gekeken naar de aansturing van UAVs, afstandsbepaling tussen UAVs, communicatie tussen UAVs en collision avoidance voor een Self Deploying Sensor Swarm. Het is nu mogelijk om meerdere UAVs vanaf het basisstation onafhankelijk te besturen. Hierbij is het waarschijnlijk mogelijk om de 10 UAVs bij de demonstratie te kunnen aansturen. In onze implementatie laten we meerdere quadcopters automatisch verbinden met een router. Theoretisch is het mogelijk om maximaal 254 quadcopters aan te sturen, voor de demonstratie is echter gekozen om de adressen 10-99 te reserveren voor de quadcopters. Wij hebben de werking getest met twee quadcopters. Iedere quadcopter kan apart worden aangestuurd via onze Quadcopter klasse. Voor het opstijgen/landen kan de takeoff() en land() functie gebruikt worden. Het hoveren gebeurt direct na het opstijgen en bij het sturen van move(0,0,0,0). Voor de veiligheid moeten de UAVs met één druk op de knop onmiddellijk te stoppen zijn. Dit werkt door de functie emergency() aan te roepen, hiermee stoppen de rotoren en stort de quadcopter neer. Verder geven we de accustatus van de UAV door en kunnen we ook de hoogte, hoeken en snelheden doorgeven aan de gebruiker. In het geval dat de verbinding met het basisstation wegvalt gaat de quacopter automatisch hoveren. De mogelijkheid om slim te kunnen landen hebben we niet geïmplementeerd. We gaan ervan uit dat voor de demonstrator dit niet nodig is, aangezien dit plaats vindt in bijvoorbeeld een grote hal. Bij de afstandsmeting kunnen we in alle richtingen afstanden meten naar de andere quadcopters. Dit hebben we gerealiseerd door ZigBee te gebruiken en daarvan de RSSI waarde uit te lezen. Uit de resultaten blijkt dat dit een goede methode is om de afstand te berekenen. De afstand kan in theorie bepaald worden tot 15 objecten voor de demonstrator en 50 objecten voor het uiteindelijke product, de keus voor ZigBee laat maximaal 65000 objecten toe. Echter hadden we met 5 ZigBee’s al last van collisions. Om dit op te lossen hebben we een random software delay gebruikt, dit beperkt mogelijk de schaalbaarheid. Echter is het waarschijnlijk nog steeds haalbaar om 50 objecten te ondersteunen. Verder hebben we een vorm van identificatie, zodat duidelijk is tot welk object de afstand is gemeten. Elke ZigBee module heeft zijn eigen adres en bij het ontvangen van een bericht is te achterhalen van welke module dat kwam. Wij hebben gekozen om de adressen 10 tot en met 99 te reserveren voor quadcopters en 100-255 voor de crawlers. De afstandsmeting heeft binnen 1 seconde de afstand bepaald tot alle andere quadcopters die binnen bereik zijn. Het verbruik van de T-Minus met ZigBee kwam uit op 290mW. In vergelijking met het verbruik van de AR.Drone zelf valt dit mee. Verder moet de afstandsmeting kunnen detecteren wanneer de quadcopters te dicht bij elkaar komen. Uit de meetresultaten blijkt dat de ZigBee met antenne dit goed doet, waarbij we ook een benadering hebben opgesteld voor de RSSI tegen de afstand. 63

Voor de communicatie moeten alle berichten die vanuit de quadcopters verstuurd worden kunnen overkomen bij het basisstation. Hierbij gaan we ervan uit dat niet alle quadcopters binnen het bereik hoeven te zijn van het basisstation. Een eis is dus ook dat de quadcopters berichten kunnen forwarden (hopping). De hopping hebben we getest met 4 ZigBee module’s en dit werkte zoals verwacht. De routing werkt goed, de routingbuffer zorgt ervoor dat berichten niet dubbel aankomen en gaan oscilleren in het netwerk. Wel hebben we gezien dat niet altijd alle berichten binnenkomen, mogelijk zijn er nog collisions. De keus van ZigBee zorgt voor een maximaal (indoor) bereik van ongeveer 30 meter, wat voldoende is voor de demonstratie. Indien de modules buiten worden gebruikt zouden deze 100 meter kunnen halen. Voor de demonstratie moeten de afstanden tussen de quadcopters, de afstanden naar de crawlers en de hoeken naar de crawlers verstuurd worden over het netwerk. Deze data moet vervolgens bij het basisstation op de PC verwerkt kunnen worden. Dit hebben we gerealiseerd door een speciale PC-node te ontwikkelen die de data doorgeeft aan de computer. Op de computer kan vervolgens de data worden uitgelezen via een seriële poort. De latency mag maximaal 1 seconde zijn, hieraan wordt voldaan. Verder hebben we een nice-to-have dat de quadcopters een acknowledgement krijgen als berichten goed ontvangen zijn door alle quadcopters binnen bereik. Dit hebben we niet geïmplementeerd omdat dit een broadcast bericht is, waarbij er de kans bestaat op veel collisions als iedereen gaat antwoorden. Hier kan wel aan gewerkt worden door bijvoorbeeld weer een delay in te bouwen. Bij de reflex zorgen we dat de quadcopters niet met elkaar botsen, ook niet als het basisstation dit als commando stuurt. Dit kon niet gecontroleerd worden, maar wel is bewezen dat alle voorwaarden hiervoor aanwezig zijn. Er is echter misschien nog een mogelijkheid tot botsing, als het basisstation herhaaldelijk het commando voor opstijgen blijft sturen terwijl de reflex in werking moet treden en dus herhaaldelijk het commando voor het landen stuurt. Wat in zo’n conflictsituatie gebeurt kon niet getest worden. Wel treedt in normale situaties de reflex in werking als twee T-Minus bordjes een onderlinge afstand van minder dan 2 meter hebben. Momenteel laten we beide quadcopters landen, eventueel kan nog gekeken worden naar een andere manoeuvre zodat ze toch in de lucht blijven.

64

Bibliografie [1] W. Heida and D. Kraak, “Zwermintelligentie voor een self-deploying sensor swarm,” Bachelor Thesis, Technische Universiteit Delft, Juni 2013. [2] K. Meun and N. Radeljic-Jakic, “Uav ir & zigbee object tracking,” Bachelor Thesis, Technische Universiteit Delft, Juni 2013. [3] “Xbee product manual.” [Online]. Available: http://www.farnell.com/datasheets/72287.pdf [4] S. Piskorski, N. Brulez, P. Eline, and F. D’Haeyer, AR.Drone Developer Guide SDK 2.0, 2012. [5] J.-S. Lee, Y.-W. Su, and C.-C. Shen, “A comparative study of wireless protocols: Bluetooth, uwb, zigbee, and wi-fi,” in Industrial Electronics Society, 2007. IECON 2007. 33rd Annual Conference of the IEEE. IEEE, 2007, pp. 46–51. [6] C. J. M. Verhoeven, “Self-deploying sensor swarm demonstration,” Opdrachtbeschrijving Bachelor Afstudeerproject, Electrical Engineering, Technische Universiteit Delft, Maart 2013. [7] G. Lee, N. Y. Chong, and X. Defago, “Robust self-deployment for a swarm of autonomous mobile robots with limited visibility range,” in Robot and Human interactive Communication, 2007. RO-MAN 2007. The 16th IEEE International Symposium on, 2007, pp. 925–930. [8] J. Allred, A. B. Hasan, S. Panichsakul, W. Pisano, P. Gray, J. Huang, R. Han, D. Lawrence, and K. Mohseni, “Sensorflock: an airborne wireless sensor network of micro-air vehicles,” in Proceedings of the 5th international conference on Embedded networked sensor systems. ACM, 2007, pp. 117–129. [9] R. W. Deming and L. I. Perlovsky, “Concurrent multi-target localization, data association, and navigation for a swarm of flying sensors,” Information Fusion, vol. 8, no. 3, pp. 316–330, 2007. [10] H. Lim, J. Park, D. Lee, and H. J. Kim, “Build your own quadrotor: Open-source projects on unmanned aerial vehicles,” Robotics Automation Magazine, IEEE, vol. 19, no. 3, pp. 33–45, 2012. [11] “Arducopter.” [Online]. Available: http://code.google.com/p/arducopter/ [12] “Openpilot.” [Online]. Available: http://www.openpilot.org/ [13] “Paparazzi.” [Online]. Available: http://paparazzi.enac.fr/wiki/Main_Page [14] P. Brisset, A. Drouin, M. Gorraz, P.-S. Huard, and J. Tyler, “The paparazzi solution,” MAV2006, Sandestin, Florida, 2006. 65

BIBLIOGRAFIE [15] “Tu delft - autonomous quadrotor.” [Online]. Available: http://paparazzi.enac.fr/wiki/TU_ Delft_-_Autonomous_Quadrotor [16] P.-J. Bristeau, F. Callou, D. Vissière, N. Petit et al., “The navigation and control technology inside the ar. drone micro uav,” in World Congress, vol. 18, no. 1, 2011, pp. 1477–1484. [17] J. Halgašık, J. Zemánek, M. Hromcık, and Z. Hurák, “Affordable multiuav experiments using ar. drone quadrotors.” [18] “Gebruikte code: Ardrone quadcopter in robotics research.” [Online]. Available: //labe.felk.cvut.cz/~tkrajnik/ardrone/

http:

[19] “Multiple ar.drones.” [Online]. Available: https://github.com/AutonomyLab/ardrone_autonomy/ wiki/Multiple-AR-Drones [20] “Softwaremodifications, startup script.” [Online]. Available: ardudrone/wiki/SoftwareModifications

http://code.google.com/p/

[21] “pthread create error in c++.” [Online]. Available: http://stackoverflow.com/questions/6352280/ pthread-create-error-in-c/6352434#6352434 [22] H. C. Christmann and E. N. Johnson, “Design and implementation of a self-configuring ad-hoc network for unmanned aerial systems,” in Proceedings of AIAA InfoTech@ Aerospace conference, 2007, pp. 698–704. [23] H. Lim and C. Kim, “Multicast tree construction and flooding in wireless ad hoc networks,” in Proceedings of the 3rd ACM international workshop on Modeling, analysis and simulation of wireless and mobile systems. ACM, 2000, pp. 61–68. [24] Z. J. Haas, J. Y. Halpern, and L. Li, “Gossip-based ad hoc routing,” in INFOCOM 2002. Twenty-First Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, vol. 3. IEEE, 2002, pp. 1707–1716. [25] W.-H. Liao, J.-P. Sheu, and Y.-C. Tseng, “Grid: A fully location-aware routing protocol for mobile ad hoc networks,” Telecommunication Systems, vol. 18, no. 1-3, pp. 37–60, 2001. [26] G. Ding, Z. Sahinoglu, B. Bhargava, P. Orlik, and J. Zhang, “Reliable broadcast in zigbee networks,” in Proc. Ann. IEEE Comm. Soc. Conf. Sensor, Mesh, and Ad Hoc Comm. and Networks, 2005. [27] M. V. Micea, A. Stancovici, D. Chiciudean, and C. Filote, “Indoor inter-robot distance measurement in collaborative systems,” Advances in Electrical and Computer Engineering, vol. 10, no. 3, pp. 21–26, 2010. [28] M. V. Micea, A. Stancovici, and S. Indreica, “Distance measurement for indoor robotic collectives.” [29] J. Bisson, F. Michaud, and D. Letourneau, “Relative positioning of mobile robots using ultrasounds,” in Intelligent Robots and Systems, 2003. (IROS 2003). Proceedings. 2003 IEEE/RSJ International Conference on, vol. 2, 2003, pp. 1783–1788 vol.2. [30] I. Kelly and A. Martinoli, “A scalable, on-board localisation and communication system for indoor multi-robot experiments,” Sensor Review, vol. 24, no. 2, pp. 167–180, 2004. 66

BIBLIOGRAFIE [31] J. Pugh and A. Martinoli, “Relative localization and communication module for small-scale multi-robot systems,” in Robotics and Automation, 2006. ICRA 2006. Proceedings 2006 IEEE International Conference on, 2006, pp. 188–193. [32] J. Wu, W. Chan, and G. Thomas, “Rapid and accurate inter-robot position determination in robot teams,” Instrumentation and Measurement, IEEE Transactions on, vol. 50, no. 1, pp. 163–168, 2001. [33] E.-E.-L. Lau and W.-Y. Chung, “Enhanced rssi-based real-time user location tracking system for indoor and outdoor environments,” in Convergence Information Technology, 2007. International Conference on, 2007, pp. 1213–1218. [34] J. Blumenthal, R. Grossmann, F. Golatowski, and D. Timmermann, “Weighted centroid localization in zigbee-based sensor networks,” in Intelligent Signal Processing, 2007. WISP 2007. IEEE International Symposium on, 2007, pp. 1–6. [35] P. Corral, V. Almenar, and A. de C.Lima, “Distance estimation system based on zigbee,” in Spread Spectrum Techniques and Applications, 2008. ISSSTA ’08. IEEE 10th International Symposium on, 2008, pp. 817–820. [36] G. Santinelli, R. Giglietti, and A. Moschitta, “Self-calibrating indoor positioning system based on zigbee devices,” in Instrumentation and Measurement Technology Conference, 2009. I2MTC ’09. IEEE, 2009, pp. 1205–1210. [37] S. Schwarzer, M. Vossiek, M. Pichler, and A. Stelzer, “Precise distance measurement with ieee 802.15.4 (zigbee) devices,” in Radio and Wireless Symposium, 2008 IEEE, 2008, pp. 779–782. [38] R. A. Saeed, S. Khatun, B. Ali, and M. Khazani, “Performance of ultra-wideband time-of-arrival estimation enhanced with synchronization scheme,” ECTI Trans. on Electrical Eng., Electronics and Communication, vol. 4, no. 1, 2006. [39] “T-minus engineering flight computer.” [Online]. Available: http://www.t-minus.nl/products/ #Flightcomp [40] “Datasheet atmega2560.” [Online]. Available: http://www.atmel.com/ja/jp/images/doc2549.pdf [41] “xbee-arduino, arduino library for communicating with xbees in api mode.” [Online]. Available: http://code.google.com/p/xbee-arduino/ [42] C. Bills, J. Chen, and A. Saxena, “Autonomous mav flight in indoor environments using single image perspective cues,” in Robotics and automation (ICRA), 2011 IEEE international conference on. IEEE, 2011, pp. 5776–5783. [43] M. A. Olivares-Mendez, L. Mejias, P. Campoy, and I. Mellado-Bataller, “Quadcopter see and avoid using a fuzzy controller,” in Proceedings of the 10th International FLINS Conference on Uncertainty Modeling in Knowledge Engineering and Decision Making (FLINS 2012). World Scientific, 2012. [44] D. Holz, D. Droeschel, S. Behnke, S. May, and H. Surmann, “Fast 3d perception for collision avoidance and slam in domestic environments,” Mobile robots navigation, pp. 53–84, 2010. 67

BIBLIOGRAFIE [45] L. Zeng and G. M. Bone, “Mobile robot collision avoidance in human environments,” Int J Adv Robotic Sy, vol. 10, no. 41, 2013. [46] C.-S. Park, M.-J. Tahk, and H. Bang, “Multiple aerial vehicle formation using swarm intelligence,” in AIAA Guidance, Navigation, and Control Conference and Exhibit, 2003, pp. 11–14. [47] “Parrot ar.drone sdk.” [Online]. Available: https://projects.ardrone.org/projects/show/ardroneapi [48] “Automatically startup custom script on ar.drone v2 on powerup.” [Online]. Available: https://projects.ardrone.org/boards/1/topics/show/5729

68

Bijlage A

AR.Drone V2 Wifi Configuratie Hier wordt beschreven hoe de quadcopters geconfigureerd worden, zodat ze bij het opstarten automatisch met het netwerk verbinden en het juiste IP adres krijgen.

A.1

Configuratie van de router

Onderstaande is uitgevoerd met een Icidu NI-707533 Wireless Gigabit Router 300N die al beschikbaar was op de TU Delft. Het is mogelijk om instellingen te veranderen van de router door te verbinden met 192.168.1.1 met een internetbrowser. Hier hebben we het netwerk een andere SSID (naam) gegeven: TUD_SDSS en gecontroleerd dat hij een onbeveiligd netwerk maakt. De gebruikte guide gaat namelijk uit van een onbeveiligd netwerk [19].

A.2

Configuratie van de quadcopters

Nadat de router is ingesteld beschrijft de guide hoe de quadcopters moeten worden ingesteld. Daarvoor moet verbinding gemaakt worden met de quadcopter. Vervolgens in een terminal: telnet 192.168.1.1 vi /data/wifi.sh In dit bestand moet de volgende code komen, waarbij 192.168.1.10 het gewenste IP adres is van de quadcopter. killall udhcpd ifconfig ath0 down iwconfig ath0 mode managed essid TUD_SDSS ifconfig ath0 192.168.1.10 netmask 255.255.255.0 up Dit werkt zowel voor de AR.Drone V1 als de AR.Drone V2. Dit script kan gestart worden door te verbinden met het eigen netwerk van de quadcopter en vervolgens in een terminal het volgende commando te sturen: echo "./data/wifi.sh" | telnet 192.168.1.1 69

A.3. SCRIPT AUTOMATISCH UITVOEREN BIJ HET OPSTARTEN

A.3

Script automatisch uitvoeren bij het opstarten

Nu moet elke keer als de quadcopter aan wordt gezet opnieuw verbonden worden met de router. Hiervoor hebben we een oplossing gezocht om ons script bij het opstarten meteen uit te voeren. Een oplossing werd gegeven op [20]. Het script wordt toegevoegd aan het einde van /etc/init.d/rcS. Daarvoor moet bovendien het script wifi_setup.sh uit de background modus gehaald worden (verwijderen van het &-teken achter de aanroep [48]).

70

Bijlage B

Aanpassingen Arduino Uno In het begin waren er niet voldoende T-Minus bordjes beschikbaar, maar hadden we wel de beschikking over Arduino Uno bordjes. Deze zijn daarom gebruikt op het moment dat we aan een enkele UART interface voldoende hadden, want de Arduino Uno bevat een ATmega328 die een enkele UART interface heeft. Bij het gebruik van deze UART interface voor de ZigBee-module waren een aantal aanpassingen nodig. Zo moet bij het programmeren van de Arduino Uno de ZigBee-module losgehaald worden, omdat dit anders conflicten geeft. Daarnaast werkt de Arduino Uno op een voedingsspanning van 5V en de ZigBee-module op een voedingsspanning van 3,3V. Deze voedingsspanning kan van het bordje van de Arduino Uno afgehaald worden, want deze bevat ook een spanningsregulator voor 3,3V. Het datasignaal van de ZigBee-module (TX) naar de Arduino Uno (RX) kan rechtstreeks verbonden worden, want de Arduino Uno kon overweg met een logisch hoog ingangssignaal van 3,3V. Andersom kan het datasignaal van de Arduino Uno (TX) niet rechtstreeks verbonden worden met de ZigBee-module (RX), aangezien deze laatste geen 5V op zijn pinnen aankan. Zodoende is hier een spanningsdeler tussen geplaatst op het moment dat we de Arduino Uno gebruiken.

71

72

Bijlage C

AR.Drone V2 C/C++ code compileren en uitvoeren C.1

Cross-compiler

Het compileren van de C/C++ code voor de AR.Drone V2 moet met behulp van een cross-compiler. Wij hebben gebruik gemaakt van de GCC compiler voor ARM Linux. Deze is als volgt onder Ubuntu geïnstalleerd: sudo apt-get install g++-arm-linux-gnueabi sudo apt-get install gcc-arm-linux-gnueabi Dit kan als volgt in een project in de Eclipse IDE gebruikt worden: 1. Creëer een standaard Linux GCC Hello World project: File > New > C++ Project > Hello World C++ Project en selecteer de Linux GCC toolchain. 2. Verander bij Project > Properties > C/C++ Build > Settings > Tool Settings de commando’s: • GCC C++ Compiler: arm-linux-gnueabi-g++ • GCC C Compiler: arm-linux-gnueabi-gcc • GCC C++ Linker: arm-linux-gnueabi-g++ • GCC Assembler: arm-linux-gnueabi-as 3. Stel bij Project > Properties > C/C++ General > Paths and Symbols > Includes het volgende in: • GNU C: /usr/arm-linux-gnueabi/include en selecteer “Add to all configurations” • GNU C++: /usr/arm-linux-gnueabi/include/C++/4.6.3 en selecteer “Add to all configurations” 4. Stel bij Project > Properties > C/C++ General > Paths and Symbols > Library Paths het volgende in: • /usr/arm-linux-gnueabi/lib en selecteer “Add to all configurations” 73

C.2. UITVOEREN

C.2

Uitvoeren

Voordat de code uitgevoerd kan worden, moet de gecreëerde executable (deze heeft geen extensie) op de AR.Drone V2 gezet worden. Dit moet via FTP en kan bijvoorbeeld met FileZilla. Bij de Binary Type moet ‘Binary’ geselecteerd worden, omdat de executable anders niet werkt. Via telnet kan de executable vervolgens gestart worden. De standaard uitvoer van het programma wordt in dit venster getoond.

74

Bijlage D

Code en testresultaten De code voor de aansturing van de quadcopters (QuadcopterControl), de afstandsmeting/communicatie (Zigbee) inclusief de seriële ontvangst op de PC (SerialReceiver) en de reflex (ARDroneReflex) is te downloaden via internet: https://www.dropbox.com/sh/41mni0ecibmiw2t/evBqj4rZaS Of via http://tinyurl.com/BorDijkThesis Hier zijn ook de volledige testresultaten van ZigBee te vinden.

75

Bachelor Thesis Self Deploying Sensor Swarm

Recommend Documents