5T746, Graduation project

Eindhoven University of Technology

Thales Nederland B.V

Store-and-Forward Networking Solutions with

Autonomous Aerial Vehicles
Robotics and Networking
Shyam Balasubramanian (Embedded Systems, 0785610)

Committee:
Prof. Dr. H. Corporaal (TU/e)
Dr. Ir. P.H.F.M. Verhoeven (TU/e)
Ir. M. Wijtvliet (TU/e)
Dr. Ir. M de Graaf (Thales)
Dr. Ir. G.J. Hoekstra (Thales)

January 2, 2014
Abstract

In this thesis, the technology of Mobile Ad-Hoc Networks (MANETs) along with Disruption Tol-
erant Networking (DTN), a store-and-forward approach, is made to interact with the navigation
software of a multirotor aircraft to perform certain tasks during navigation, autonomously.
The MANET is a popular research topic that deals with the routing of information between
systems in motion. The DTN is a fairly new field of research that enables networking in extreme
environments that may lack continuous network connectivity. Most of the prior work in the area
of MANETs and DTN have been performed using simulations. This research aims to extend the
mobile networking with DTN technology in order to improve the robustness of communication.
A practical implementation presents the complex dynamics of wireless environments and poses
new challenges.
The multirotor is chosen as the mobile node and is made to fly to several waypoints (base sta-
tions) using GPS. It hovers in the given region by establishing an on-the-fly network connection.
Exchange of required data such as files, video or any critical data exchange is initiated upon
a successful connection. This concept leads us to diverse potential applications where network
infrastructure is unavailable; such as in the field of military operations, surveillance of civilian
areas and forwarding video images during search and rescue operations.
The main focus of this research is on the deployment of an autonomous mobile node to exchange
data with other static nodes, using DTN technology. Further, extensions to DTN are proposed
and a new algorithm is developed to make autonomous networking more intelligent. Additional
research and development has been carried out to improve the stability of the hovering platform
and to extend the flight times.

Keywords

DTN - Disruption Tolerant Networking

MANET - Mobile Ad-Hoc Networks
UAV - Autonomous Multirotor, Multicopter, Micro-Aerial Vehicles or Drones

1
Acknowledgements

This thesis is written as part of my master degree in Embedded Systems at Eindhoven University
of Technology. The work in this thesis is conducted at Thales Nederland B.V., at Huizen.
I have always had a deep interest for how stuff works and this especially applies to embedded
systems and aerial robotics. The main motivation of this work is towards application specific
multirotors. Implementing, experimenting and extending the state-of-the-art multirotor tech-
nology has been a perfect assignment for me. Working in the area of wireless networks has been
an equally rewarding experience.
I would like to extend my gratitude to prof. dr. Henk Corporaal, my graduation supervisor
at Eindhoven University of Technology. His timely guidance and encouragement to explore the
amazing world of multirotors has helped me immensely. I thank ir. Mark Wijtvliet whose ideas
in thesis have helped me reflect on my work. I would like to show my appreciation to dr. ir.
Richard Verhoeven for accepting to be part of this committee.
At Thales Nederland B.V, I have been given the freedom to explore and to pursuit any new idea
that I have come up with. For giving me such freedom in my work, and for their guidance, I
would like to thank dr. ir. Maurits de Graaf and dr. ir. Gerard Hoekstra, my daily supervisors
at Thales. My appreciation to Robert Hodkinson, for all the fruitful technical discussions we
have had during my tenure. I thank my colleagues Javier, Stefan and Gertjan for critical review
of my work and their timely feedback. My colleagues Sunil John, Suhas Pai and Ashwin Bhat,
at the University of Eindhoven, who have encouraged me to pursue my dream.
In the end, I offer my special thanks to Vimitha for her love and care and to make me into
a better person. My family in India, for without whose love and encouragement I would have
forgot to innovate.
Shyam Balasubramanian
Hilversum, January 1, 2014

2
About Thales

Thales is a French company with top market presence, in both military and civilian domains.
Thales is one of the most well known companies in the sectors of defense, ground transportation,
civil security and aerospace.

Figure 1: Thales Group logo.

Thales Nederland B.V is a Dutch brand of Thales group, has about 2,000 employees working
at various branches, located in Hengelo (HQ), Enschede, Eindhoven, Delft and Huizen.
Thales, located at Huizen, is the leading defence communications company in The Netherlands.
It is a supplier of high quality integrated communications equipments for both the military and
commercial organisations, with requirements for high technology multimedia networks.

3
Contents

List of Abbreviations 7

1 Introduction 13

2 Related Work 17

3 Mobile Platform Selection 21

3.1 Classification of aerial vehicles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Multicopter platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3 Networking platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Wireless Networking 34
4.1 Internet protocol stack (TCP/IP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Wireless networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Mobile ad-hoc network (MANET) . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 MANET routing protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 Selection of OLSR routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5 Disruption Tolerant Networking 43

5.1 DTN history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Features of DTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 Bundle layer protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4 IBR-DTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5 IBR-DTN mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.6 Limitations of DTN design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.7 Extending the DTN design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6 Network Setup on Raspberry Pi 56

6.1 Node configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.2 MANET setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3 Mesh network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.4 OLSR plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.5 OLSR and IBR-DTN configuration settings . . . . . . . . . . . . . . . . . . . . . 66
6.6 Communication between layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7 Multicopter Hardware 69
7.1 System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.3 Flight controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.4 Electronics and actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4
 7.5 Power supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.6 Communication equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.7 Frame specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
7.8 Networking hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.9 List of components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

8 Multicopter Software 84
8.1 Mathematical model of the quadcopter . . . . . . . . . . . . . . . . . . . . . . . . 84
8.2 Sensor Fusion Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8.3 Quadcopter configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
8.4 Software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8.5 Modes of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8.6 Flight configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

9 Performance Analysis and Improvements 93

9.1 Measures to improve stability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.2 Hover tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
9.3 Power consumption tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
9.3.1 Power consumed by networking hardware . . . . . . . . . . . . . . . . . . 98
9.3.2 Power consumed by aerial vehicle . . . . . . . . . . . . . . . . . . . . . . . 99

10 Aerial Network Protocol 101

10.1 Extended network stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
10.2 Background of the protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
10.3 Aerial-network protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
10.3.1 XML Configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
10.3.2 Query the OLSR and DTN . . . . . . . . . . . . . . . . . . . . . . . . . . 104
10.3.3 Client server architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
10.3.4 Network flight interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

11 Waypoint Networking 109

11.1 ETX Measurements with antenna orientation . . . . . . . . . . . . . . . . . . . . 109
11.1.1 Tests with antenna orientation . . . . . . . . . . . . . . . . . . . . . . . . 112
11.2 Mission Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
11.3 Waypoint networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
11.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

12 Analysis of Interferences 117

12.1 Wireless devices on multicopter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
12.2 Understanding power scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
12.3 Frequency bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
12.3.1 2.4 GHz spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
12.3.2 1.5 GHz spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

13 Extended Flight Times 127

13.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
13.2 Factors affecting flight time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
13.3 Selection of components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
13.4 Power analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
13.5 Energy source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
13.6 Flight time results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

5
14 Conclusions 138
14.1 Summary of contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
14.2 Insights and conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
14.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

A Hardware and Software Details 142

B Networking Principles 146

C Complete Network Configuration 149

Bibliography 173

6
List of Abbreviations

AHRS Attitude and Heading Reference System

AP I Application Programming Interface
BP A bundle protocol agent
dB Decibel
dBm decibel-milliwatt
DCM Direction Cosine Matrix
DHT Distributed Hash Table
DSSS Direct Sequence Spread Spectrum
DT N Disruption Tolerant Networking
EEP ROM Electrically Erasable Programmable Read-Only Memory
ESA European Space Agency
ESSID Extended Service Set Identification
ET X Expected Transmission Time Metric
ET X Expected Transmission count metric
F AA Federal Aviation Administration
F HSS Frequency Hopping Spread Spectrum
HT T P Hypertext Transfer Protocol
ICM P Internet Control Message Protocol
IET F Internet Engineering Task Force
IM U Inertial Measurement Unit
ISM Industrial, Scientific and Medical band
LOS Line-of-Sight
M AC Media Access Control
M AN ET Mobile Ad-Hoc Networks
M AV Micro Aerial vehicles

7
N ASA National Aeronautics and Space Administration
OLSR Optimized Link State Routing
OSI Open System Interconnection
P 2P peer-to-peer
PC Personal Computer
P ID Proportional-Integral-Derivative
PWM Pulse Width Modulation
QoS Quality of Service
RF Radio Frequency
RT C Real-time clock
SAN ET Static Ad-Hoc Networks
SenSaf ety Sensor Networks for Public Safety
SN R Signal-to-noise ratio
SQL Structured Query Language
TTL Time-to-live
U ART Universal Asynchronous Receiver and Transmitter
U AV Unmanned Aerial Vehicle
WP Waypoint
TTL Time-to -live

8
List of Figures

1 Thales Group logo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1 Aerial Vehicle Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Effect of torque on a helicopter. The tail rotor compensates for the main rotor’s
torque. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Various multicopter designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Open-source quadcopter hardware (a) Paparazzi, (b) Openpilot, (c) ArduPilot,
(d) Pixhawk, (e) Mikrokopter, (f) KKmulticopter, (g) MultiWii, (h) Spiri Images
may not be to scale, source [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 A screenshot various processor boards that can be used for networking, (a)BeagleBoard-
xM, (b)BeagleBone Black, (c)Raspberry Pi, (d)PandaBoard, (e)Android phone,
(f )TP-Link Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 The Internet Protocol Suite (TCP/IP) five-layered model. . . . . . . . . . . . . . 34

4.2 Infrastructure (Centralized) Vs. Ad-Hoc modes (Decentralized). Source: [2]. . . . 36
4.3 A possible path for a route request/reply from source (A) to Destination (D) in
AODV. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 MPR node sends Topology control (TC) messages, Source: [3]. . . . . . . . . . . 41
4.5 Zone routing protocol. The intra-zone uses proactive while the inter-zone uses
reactive protocol. Source: [4]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1 Store-and-forwarding message switching technique. . . . . . . . . . . . . . . . . . 44

5.2 Comparison of the Internet protocol stack(left) with the DTN protocol stack(right).
DTN bundles can only be transmitted to/via nodes that follow the DTN protocol,
Source [5]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Nodes with bundle protocol supports communication with other DTN nodes with
heterogeneous underlying protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 IBR-DTN architecture overview, taken from [6]. . . . . . . . . . . . . . . . . . . . 48
5.5 Mechanism of bundle transmission and reception between two nodes. . . . . . . . 51
5.6 Solution of event based trigger and handling on bundle reception. . . . . . . . . . 54

6.1 Figure shows the standard 13 channels, as per 802.11 standard. Each channel
has a bandwidth of 22 MHz; taken from Wikimedia commons(2.4 GHz Wi-Fi
channels). The 14th channel is only available in Japan. . . . . . . . . . . . . . . 57
6.2 A study of wireless devices sensed in the laboratory, using aircrack-ng, an open-
source network tool. The BSSID (MAC addressed) of the systems have been hashed. 57
6.3 Settings used for the ad-hoc network setup. . . . . . . . . . . . . . . . . . . . . . . 58
6.4 The encircled number indicates the sub-network address. The ’X’ refers to the
range of 1-255 devices or node identifiers. . . . . . . . . . . . . . . . . . . . . . . 58
6.5 The wireless interface configuration (iwconfig) after set up. . . . . . . . . . . . . 59

9
6.6 The resulting interface configuration. Notice the hardware(MAC) address of the
wireless device, along with broadcast address, transmitted and received packets. . . 59
6.7 Indication of different (unnecessary) processes using the wireless interface. . . . . 60
6.8 Modifying ifplugd daemon to prevent it from using the wireless interface. . . . . . 60
6.9 Tests performed between two static Raspberry Pi nodes. Effect of HELLO interval
tuning on neighbour discovery times, (a) establishes a reliable link with neighbour
node in 29 seconds, (b) establishes a reliable link with neighbour node in 8 seconds. 62
6.10 The network outlay consisting of six nodes, three of them are Raspberry Pi’s, two
are TP-Link routers and one is a PC. . . . . . . . . . . . . . . . . . . . . . . . . 63
6.11 Overview of currently available OLSR connections as seen by the TP-Link router.
The current node’s static IP considered is 192.168.13.207. Note that there is a
slight ambiguity in values with respect to Figure 6.10. The link costs are refreshed
continuously. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.12 The response received back from the local port immediately after the query. The
figure shows three nodes discovered by the local node, each having a different cost. 65
6.13 Illustration of communication between two nodes using OLSR and DTN, on the
extended TCP/IP protocol stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.1 Schematic overview of the hardware . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.2 MPU6000 integrates accelerometer and gyroscope on a single chip, Source . . . . 70
7.3 Figure shows a the 3-axis HMC5883L magnetometer . . . . . . . . . . . . . . . 71
7.4 Figure shows the XL-Max Sonar sensor, MB 1200, used with the quadcopter . . . 71
7.5 Figure showing multiple satellites that revolve around the earth’s orbit at all times 72
7.6 ArduPilot, hardware v2.6, Taken from [7] . . . . . . . . . . . . . . . . . . . . . . . 73
7.7 Inside the brushless outrunner motor, AC2830-358 850Kv . . . . . . . . . . . . . 74
7.8 Figure shows a 20 Amp, Electronic speed control or ESC that provides varying
high frequency AC voltage to the brushless motor . . . . . . . . . . . . . . . . . . 75
7.9 A LIPO battery that delivers 1000mAh current at 30C, 11.1V. This figure is only
used only for illustration purposes. A Zippy 5000mAh, 20C at 11V is used for
the quadcopter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.10 Non-linear effect of increase in weight against flight time, taken from [8]. . . . . 77
7.11 Power module provides a clean power supply to on-board electronics and for volt-
age, current measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.12 Power distribution board to distribute power to the four ESCs, flight controller
and Networking hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.13 Two radio modules with antennas. . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.14 The hand held transmitter sends control signals to the receiver on flight. . . . . . 80
7.15 Figure shows the TP-Link wireless dongle based on 802.11g/n standards. . . . . . 80
7.16 Figure shows the quadcopter constructed with aluminium frame. . . . . . . . . . . 81
7.17 Figure shows the Raspberry Pi processor interfaced TP-Link WN722N wireless
adaptor and a 5 Mega Pixel HD camera. . . . . . . . . . . . . . . . . . . . . . . . 81

8.1 Quadcopter model, quantities and angles . . . . . . . . . . . . . . . . . . . . . . . 84

8.2 i, j, k are unity vectors co-directional with the body frame x, y, and z axes. Oxyz
represents the body and OXYZ represent the global frame. . . . . . . . . . . . . . 86
8.3 Pitch, roll and yaw rotations are produced by varying the speed of the rotors in
the two configurations. Yaw rotation is indicated only for ’+’ configuration. . . . 87
8.4 An overview of the software architecture with hover and navigation control. The
hover controller is used as a backbone for waypoint navigation. . . . . . . . . . . 89

10
8.5 The RC controller displays the different controls available in terms of switches
and knobs. The mode is changed via the 3-position switch. . . . . . . . . . . . . . 90
8.6 Illustration of steps taken for controller tuning. . . . . . . . . . . . . . . . . . . . 91

9.1 Application of double layered anti-vibration foam pads. Each pad measures 1.5
cm in thickness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
9.2 The 3-axis accelerometer data recorded during hover. . . . . . . . . . . . . . . . . 94
9.3 Result of controller tuning for roll axis. The controller output tries to converge
to its input. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.4 Use of Aluminium foil minimize the magnetic interference on compass. . . . . . . 96
9.5 An near-linear deviation of compass with increasing throttle. . . . . . . . . . . . . 96
9.6 Test to verify the stability of the platform in autonomous hovering mode. . . . . . 97
9.7 Hovering test in a windspeed of 18 kmph. The graph shows the attitude and thrust
variations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
9.8 Raspberry Pi running OLSR actively, with an external power source. . . . . . . . 98
9.9 Test conducted to determine the power required for hovering. . . . . . . . . . . . . 99

10.1 Extended TCP/IP network stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

10.2 Illustrates the role a (static or mobile) node during network transactions, at a
waypoint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
10.3 Illustrates how the tasks are interpreted from the XML file. Each task, node is
an object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
10.4 Illustrates the network flight interaction. The aerial-network protocol runs on the
networking hardware, the Raspberry Pi. . . . . . . . . . . . . . . . . . . . . . . . 107

11.1 A mobile node (quadcopter) is used along with other static nodes in the MANET,
during waypoint networking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
11.2 A 4 dBi detachable wireless antenna with TP-Link WN722n wireless adapter. . . 110
11.3 The figure shows, (a) the radiation pattern of a simple omnidirectional antenna,
(b) and (c) shows the 4 dBi antenna gain pattern from a vertical and horizontal
plane of view. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
11.4 Neighbour discovery tests performed with respect to antenna orientation. The
tests are conducted between a static node placed on the ground and a mobile node
hovering at a height of 5 meters. . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
11.5 An illustration of an indoor hovering, at Thales Nederland B.V. The mobile node
exchanges data with the static node below. . . . . . . . . . . . . . . . . . . . . . . 112
11.6 Mission waypoint planning. Three waypoints are plotted on this map. The take
off point is marked as Home. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
11.7 The scenario tested during waypoint navigation. A total of three waypoints are
planned. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
11.8 Measured link quality (ETX) during the waypoint network navigation. . . . . . . 116

12.1 The four wireless devices used on our multicopter. Top left: TP-Link WiFi (2.4
GHz); top right: 3DR telemetry (900 MHz); bottom left: FlySky RC receiver (2.4
GHz); bottom right: u-blox GPS receiver (1.575 GHz). . . . . . . . . . . . . . . . 117
12.2 Using a spectrum analyser to study the DSSS, FHSS of the 2.4 GHz transmitter
and the 2.4 GHz WiFi signal from Raspberry Pi’s wireless adapter. . . . . . . . . 122
12.3 Data collected during actual flight. The graph shows sudden reduction of GPS
satellite count at the time of camera trigger that resulted in a sudden bizarre flight
behaviour. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
12.4 Using a spectrum analyser to study the interference due to the camera. . . . . . . 124

11
12.5 Measures taken to minimize the interference created from the camera ribbon cable.125

13.1 Illustrates the induced air velocity below the propeller plane. . . . . . . . . . . . . 128
13.2 Illustrates the chosen 360 kV motors and propellers (not to scale). . . . . . . . . 132
13.3 After the integration of all components on the carbon fibre frame. . . . . . . . . . 133
13.4 Illustrates the different tested motor mount orientations. . . . . . . . . . . . . . . 134
13.5 An unconventional design that reduces the power consumed for hover, due to
reduction in air drag on the quadcopter frame. . . . . . . . . . . . . . . . . . . . . 134
13.6 Illustrates the Li-ion cells, when connected in 5S-4P configuration, supplies enor-
mous power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
13.7 Putting together the Li-ion pack to be used on the quadcopter. . . . . . . . . . . . 135
13.8 An outdoor test flight. The flight is autonomous and locked in GPS mode. Note
that the motors are mounted in an inverted fashion. . . . . . . . . . . . . . . . . 136

A.1 Attitude tracking response of a quadcopter. Ardupilot based controller is found

to be more accurate than other OSP controllers, based on ground-truth. The
delay between reference and measured signal is due to the communication delay,
Reference: The desired angle, Roll, Theta: Measured attitude of the quadcopter
by Vicon, Source:[1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
A.2 A screenshot of Ground station control available for different OSPs, (a) Pa-
parazzi, (b) Openpilot, (c) Ardupilot, (d) Pixhawk, (e) Mikrokopter . . . . . . . . 145

B.1 The OSI standard is followed for network communication across all vendors. . . . 147
B.2 An experiment conducted when an obstacle is brought in between two nodes, spo-
radically. It can be seen the data rate is affected due to packet loss. . . . . . . . . 148

C.1 Real-time clock interfacing with the Raspberry Pi. . . . . . . . . . . . . . . . . . . 153

12
Chapter 1

Introduction

Until the last decade, the term Unmanned Aerial Vehicle (UAV) was associated with large-sized
drones used for autonomous missions by the military. Starting recently, the terminology of Micro
Aerial Vehicles (MAVs) have emerged, made possible by the improvement in multiprocessor,
sensors and actuator technologies. MAVs are usually categorized as small sized aerial vehicles
weighing anywhere from a few grams to a few kilograms. Aerial robotics is a fast growing
field with tremendous civil and military applications. It has lately seen increased popularity
of multirotor aircraft such as the quadcopter. Extensive research is ongoing in the field of
MAV platforms, for tracking robotics tasks in complex, three dimensional, indoor and outdoor
environments.
Most of the research in the field of MAV is concerned with improving surveillance features and to
improve autonomous navigation capabilities of the vehicle themselves. However, as far as we are
aware, little practical insight exists on the use of UAV or MAV for improving the communication
network. The research in this thesis is exactly concerned with that, i.e. improving the capability
of a wireless ad-hoc communications network by using a MAV.
In the field of wireless networking, Mobile Ad-Hoc Networks (MANETs) have emerged that deal
with routing of information between systems in motion. Military vehicles, as an example, are
nodes where all have equal access (i.e. each node acts as an access point) and rely on MANETs
for peer-to-peer communications. MANETs impose several challenges such as efficient routing
of data, shortest data path to destination and battery efficient algorithms.
Alongside, Disruption Tolerant Networking (DTN) is an up-and-coming technology that enables
networking in extreme environments that may lack continuous network connectivity. Mission
to Mars, planned networks in space, getting the internet to sub-Saharan villages, have all some-
thing in common. These are all examples of networking in extreme (terrestrial) environments
that overwhelm traditional technology and demands new communication solutions. The DTN
technology has been adopted by National Aeronautics and Space Administration (NASA) and
European Space Agency (ESA) for interplanetary space communications, in the year 2012. This
technology, proposes a store-and-forward approach to handle disruptions in communications;
and delivers required data to the destination at the earliest time, whenever possible.
This research is conducted at Thales in the context of Sensafety1 . The research aims to bring
closer the diverse technologies of mobile mesh networks and DTN to closely interact with
the aerial platform. The concept in this project opens up an additional direction for future
research.
1
SenSafety, is a COMMIT project, that centers on safety and security in public spaces.

13
Contribution of this thesis
In the context of both wireless networking and MAVs, most of the prior work has been conducted
with simulation as a tool of choice. Implementations in each of these categories exist but the
study of wireless networking in combination with MAVs, is a new field of research.
MANETs has remained a popular research topic since the mid 1990s. Many academic papers
evaluate protocols and study their abilities with varying degrees of mobility within a bounded
space, usually with nodes reachable within a few hops of each other. MANET is a potential
candidate for applications where networked mobility is important. With DTN, research and
development is ongoing and its impact on applications in terrestrial environments is slowly
being realized. Autonomous navigation with MAVs is not yet completely mature, due to the
regulations imposed by FAA that dictates aerial vehicles to be in the Line-of-Sight (LoS) of the
user.
At the time of this writing, there is no practical insight available using all the three concepts
integrated together i.e. MANET, DTN and autonomous multirotors, and analysis of its be-
haviour. In this thesis, we pursue research, propose new concepts and importantly, implement
the new concepts in a working multirotor system. The integration and implementation of these
three concepts in a single autonomous flying system is in itself a significant step forward with
regard to the state of the art.
Alongside, one of the major factors that limits the use of small-sized unmanned aerial vehicles,
is the short flight times. It is shown in this research that this limitation can be overcome to a
good extent. The following are the core contributions of this research:
1. Tests with MANET, DTN : Analysis and integration of MANET routing protocol and the
DTN technology on resource constrained embedded systems and testing its use case with
several nodes in the network.
2. Applicability of DTN : In this report, several improvements to the DTN architecture are
proposed and implemented that make DTN better for use with applications. For example,
four key aspects of DTN are addressed that currently limit its use on an application level.
These are determining the source of the data sent, event based trigger on data reception,
finding the received data’s file format and clock synchronization between sending and
receiving nodes. This is interesting in the context of military applications with DTN.
3. Aerial-network protocol : Development of Aerial-network protocol that enables interaction
between the navigation software and the other protocols on the networking stack. For ex-
ample, autonomous network search of other (static) nodes and decisions on bi-directional
exchange of data are established on the fly with this protocol. This is done on hovering
in a region, to disseminate to or request data from other nodes while using a store and
forward technique such as DTN. The network parameter such as link quality is determined
to alter the behaviour of the hovering platform during a data exchange.
4. Hovering capability: Improve the hovering precision of the multirotor platform by research-
ing and experimenting several methods such as vibration control, reduction of on-board
magnetic field interference that directly affect the flight characteristics. The result is the
multirotor hovering with sub-meter accuracy.
5. Study of on-board Interference: Analysis and resolution of unexpected on-board interfer-
ences on the mobile platform due to the use of multiple wireless devices, for communica-
tion.

14
 6. Extended flight times: Flight times have been a major limitation of MAVs. Complemen-
tary to this research, a multi-rotor is hand designed with custom components. It is shown
that this design significantly extends the flight times over contemporary multirotors. Fur-
ther, an unconventional method is introduced by inverting the motor orientation on the
multirotor leading to increase in flight time. The motivation for this development stems
from understanding the power requirements for a given design.

Disciplines Involved
1. Wireless networking
In the field of wireless networking, the research involves understanding the existing proto-
cols for inter-node communication in Wide Area Networks (WAN). The concept of DTN
is used in the context of wireless networks and improvements are proposed. The DTN
technology being relatively new, requires study and experimentation before putting to
use. The various networking tools such as arp and wireshark, serve as a useful aid while
studying network behaviour and to troubleshoot problems.
The aerial networking platform hosts four different wireless frequencies in the MHz to
GHz range. The implications of wireless interferences in a practical setup is analysed and
several insights are obtained.
2. Embedded systems
The software for both navigation and networking are implemented on embedded hardware.
The challenge lies in understanding the hardware components and implementing software
that results in an expected behaviour. Navigation imposes certain real-time constraints
that have to be met for a smooth flight operation. For embedded networking require-
ments, the protocols used or developed are based on C++, python and bash scripting
languages. The ground control software is written in C# language for interaction with
the flight controller via Universal Asynchronous Receiver and Transmitter (UART) inter-
face. Suitable data logging has been performed at various stages to study the flight and
networking characteristics and to troubleshoot problems.
3. Control
The stable control of flight requires understanding the behaviour of closed loop systems.
The software for any navigation system employs (several) closed loop mechanisms to main-
tain the stability of the platform. One of the important aspects of stability is governed
by the Proportional-Integral-Derivative (PID) controller. A PID controller computes the
error difference between the input from the sensor board and the desired target. The
controller attempts to minimize this error by adjusting the output of the actuators, in-
directly affecting the input. Tuning multiple PID controllers for the improved controller
response, is part of this work.
4. Mechanical systems
Amongst the most popular multirotor designs being researched, the quadrotor or quad-
copter is the most popular. The structure of the frame design in general, must adhere to
a specific weight distribution, uniformity and rigidity. During the phase of this research,
three quadcopters are used at Thales. One mechanically constructed quadcopter is pur-
chased for faster set up and for demonstration purposes. The other two are built from
scratch, for raw experimentation and to serve as a backup. The weight of the aerial vehicle
plays an important role with respect to its flight times. Thrust tests are performed for
the analysis of predictable hover times.

15
Chapter Overview
Related work are described in Chapter 2. The selection of hardware for flight navigation and
networking for the mobile platform is introduced in Chapter 3. The basics of wireless network-
ing concepts is presented in Chapter 4. Some of the most popular Mobile Ad-Hoc Network
(MANET) routing protocols proposed by the Internet Engineering Task Force (IETF) are also
presented in this chapter. In Chapter 5, Disruption Tolerant Networking (DTN) is discussed
in detail. The improvements made towards the applicability of DTN for applications, is also
presented. Chapter 6 discusses the setup of OLSR (Optimized Link State Routing) and DTN
bundle protocol, analysis and its operation on embedded systems.
Chapter 7 and 8, introduces the basic building blocks of multirotor hardware and discusses all
components in detail. Further, an overview of the software architecture for the multicopter
is presented. In Chapter 9, the analysis of the multicopter platform is discussed along with,
methods that are used to improve the flight characteristics and its behaviour in real-flight,
derived from the logged data.
In Chapter 10, the aerial-network protocol developed for autonomous data transfer is discussed.
This protocol is an extension of the TCP/IP network stack and takes advantage of the MANET
routing and DTN protocol beneath it. Chapter 11 discusses the waypoint navigation and
interaction of networking with autonomous flight. The analysis of the on-board interference
due to different wireless devices are discussed in Chapter 12. This shows the interference can
lead to bizarre aircraft behaviour. Analysis is presented and measures are described to minimize
these effects.
In Chapter 13, the design of the hand-built multicopter is discussed in detail. This proposes con-
siderable improvement over contemporary multirotor flight times using custom components and
different energy source. Comparison of flight times is shown between two different multicopters
with the same payload.
Finally, conclusion is presented in Chapter 14.

16
Chapter 2

Related Work

The work in this thesis spans three important areas namely, Mobile Ad-Hoc Networks (MANETs),
Disruption Tolerant Networks (DTN) and autonomous aerial robotics. Only a brief mention of
the significant work in the area of this thesis is mentioned in this chapter.

Focus of this thesis

The main focus of literature survey is in the following area:
• Ad-hoc network capability of the autonomous robot such that it can act as a mobile node
to bridge the gap between two sub-networks.
• Integration of Disruption or Delay Tolerant Network (DTN) as a store and forward net-
work strategy, for reliability of data transfer between regions of no-connectivity.
• Deployment of an autonomous robot capable of flying waypoints

Relevant literature and contributions

1. An Autonomous Flying Robot for Network Robotics:
In prior work to the paper, found in [9], large amount of theoretical work exists using
simulation as a tool of choice. These often make simplified assumptions about the envi-
ronment however, fail to capture complex dynamics of wireless environments. This area is
only recently gaining popularity with ground wheeled robots in a mesh network. Integrat-
ing robots in real world in large scale wireless networks, specifically outdoors has seldom
been the vision. This paper proposes and conducts experiment with a mobile platform in
real wireless networks.
In this paper, the author studies the effect of the parameters of the wireless networks
such as signal-to-noise plus interference (SNIR), packet delivery rate (PDR) and packet
error rate (PER) for the noisy environment. These parameters are affected due to exter-
nal interferences that include cell phone devices and non-communication devices such as
microwave ovens.
The experiments are conducted in the HU-Berlin Adlershof campus with multiple indoor
and outdoor nodes. The indoor Wi-Fi nodes are placed in several buildings, forming a
fully connected wireless network.

17
 Contributions

Two experiments are conducted in this paper. In the first experiment, a mobile laptop is
carried on foot around the campus for wireless network measurements and to study the
noisy outdoor environment. The results indicate that the presence of two-ray interferences
and reflections influence the wireless channels.
In another experiment, an autonomous robot is used as the mobile platform. In au-
tonomous mode, the processor executes the algorithm under investigation. The idea is
to cope with the uncertain and noisy dynamic environment by adjusting the position of
the robot to improve network performance based on the network parameters. The use of
the robot is only done indoors for network measurements. The author has suggested the
use of warping, a technique to guide the robot to achieve intelligent flight, however this
is reserved as future work.
2. On Controlled Node Mobility in Delay-Tolerant Networks of a UAV :
Mobile ad-hoc networks(MANETs) are playing an increased role of making ubiquitous
computing and communication into a reality. In [10], two model based approaches to ferry
data between regions of no connectivity is discussed. The route model designs discussed
are namely, the chain-relay model and conveyor-belt model. Evaluation of the proposed
route designs take into account the node velocity, node range, data rate and buffer size
of the nodes. Further, a new route design has been suggested which takes into account
multiple data rates with separation distance from a node. Initial evaluation suggests
performance improvements over existing approaches on using this new route design. The
models are based on simulation.

Contributions

This paper presents two models of communication and a new route design based on data
rates.
Chain-Relay Model : In this model, it is assumed that all participating nodes (i.e. ferries)
are distributed along the connecting path between source and destination nodes, repre-
senting a chain. The source node passes the data to the first (nearest) ferry, which then
transports it physically by movement to the next ferry along the path and returns to its
original position. This hand-off process is repeated, until the last ferry or the destination
node receives the data sent.
Conveyor-Belt Model : In this model, it is assumed that each ferry travels the complete
distance from the source to the destination before returning to its original position. It
is noted that multiple ferries that share the same path increases the throughput and
robustness of the system.
A mathematical evaluation of these two models are studied based on node buffer size, the
separation distance between successive nodes, radius of the coverage area of a node and
the data rate in the coverage area.
Variable Data Rate Communication Model This model makes use of variable data rates
provided by IEEE 802.11 wireless interfaces. When the ferry is close to a node or another
ferry, the communication rate is high and lowers with distance from the node; The rate
decision is based on the Signal to noise power (SNR) and the packet success rate over the
channel.

18
 The ferry loads data from the source node and travels towards the destination. The ferry
travels only as much distance as is necessary to transmit half the required data and then
returns back the same path towards the source completing the remaining half of data
transfer. This method has the advantage that it saves the total travel time and makes the
process of data transmission or reception more efficient, in theory. This way the vehicle
only moves as close to a node as necessary to complete the data transfer.
3. Robust Exploration Strategies for a Robot exploring a Wireless Network
In [11], the importance of the integration of robots into wireless networks for a number
of scenarios is presented. It introduces the concept of network exploration by finding the
physical outline of the network with a mobile robot. For this algorithm, the robustness
against noise is studied for several sensory inputs.

Contributions

The author proposes an algorithm for determining the physical layout of the wireless
mesh network using a mobile robot. With no prior knowledge about the network, the
integration of a robot into a wireless network is performed to gain knowledge about the
physical and topological characteristics of this network. In other words, the robot explores
the network. The first tasks to be solved for this include finding the nodes and outlining
the network.
Two basic assumptions are made. The mobile robot knows which general direction the
network is located in and if a node is reachable via hop from another node. This paper
suggests that relying on the Received Signal Strength Indication (RSSI) to determine a
node’s location is a tedious task. The difficulties arise due to the non-linear relationship
between RSSI and node distance.
The algorithm consists of measuring only the relative direction of the nodes and to use
the RSSI measurements in a minimum way. A directional antenna is used to determine
the direction towards a node. The robustness of the algorithm is determined in terms of
sensory noise for both direction estimation and RSSI measurements.
A number of simulation runs and parameter study in the amount of noise for both pa-
rameters is conducted. This work proposes the algorithm. The author has reserved the
robot to integrate itself into a wireless network as a future work.
4. Information delivery scheme of micro UAVs having limited communication range during
tracking the moving target:
In [12], the concept of a group of UAVs interacting together is mentioned. A micro UAV
is used to find the moving target and number of other UAVs are constantly moved to
provide information to the base station, while the target is moving. After locating the
target within the search area, the UAVs move toward the base station to transmit this
information using multihop ad-hoc connectivity. The UAVs have a limited range and
information transmission is only possible through ad-hoc communication among these
UAVs.

Contributions

In this paper, the concept of DTN technology is used. When communication among
the UAVs is not possible when the target moves too far away from the base station,
the UAVs retain the information of the target. Whenever a UAV node meets the other

19
 UAV node, the information is transmitted via a store-and-forward approach, using DTN.
The performance of the proposed methodology is evaluated using the NS-2 (Network
Simulator).
The prior work found in the area of this thesis, touch upon the concepts of aerial robotics, mobile
ad-hoc routing and DTN technology. Many of them use simulation as a tool for evaluation.
The prior work gives an idea on what contributions are already made in these areas and where
it can be improved upon.
This thesis draws motivation from [9], to integrate a mobile robot in wireless mesh networks.
The concepts of MANETs and DTN are studied, to be implemented on the mobile node.
Motivation from [10] is drawn to have a model similar to the data rate model discussed. We
make use of the network parameter such as the link quality to adjust the behaviour of the
hovering platform during data transactions.

20
Chapter 3

Mobile Platform Selection

This chapter introduces the various platforms that can be used for aerial networking. In the
first section 3.1 the reader is presented with different categories of aerial platforms in use today,
followed by their benefits and drawbacks. The next section 3.2, discusses different multicopter
designs and the various software and hardware projects available for use. The final section 3.3,
lists the hardware choices available for use with networking.

3.1 Classification of aerial vehicles

The introduction of the term unmanned or drone has emerged only since the past decade with
the idea of giving a flight more autonomy than with a manned flights. Figure 3.1 shows the
different types of aerial vehicles in use today.

(a) Unmanned balloon (b) RC airplane (fixed wing)

(c) Helicopter, with a main (d) Quadrotor or Quad-

rotor and tail rotor copter, with four rotors

Figure 3.1: Aerial Vehicle Categories

21
Figure 3.1a shows an individual holding a balloon with an orange parachute and a dropper reel
that lowers the payload containing various sensors for atmospheric measurements. This balloon
is two meters in diameter, is filled with helium gas and travels to about 35 km for atmospheric
measurements.
Figure 3.1b and 3.1c depicts airplane and helicopter, respectively, that have been in use since
1920s. Gliders and jet engines also participate in this category as were used during the world
war. Under the same category, are Radio Controlled (RC) helicopters and airplanes in existence
since 1980; being smaller in size are able to be remotely controlled by a hand held transmitter.
The growth of the word autonomous (associated with the word drone) has been in use by
military for a few decades now, the potential possibilities only being realized recently with
small sized unmanned drones for the civilian market.
Figure 3.1d shows a multicopter with four rotor blades. This category of aerial vehicles has seen
a continuous rise in popularity due to its small size, flexibility, Vertical Take Off and Landing
(VTOL) capability and ease of maintenance compared to its counterparts. The multicopter
branches out into various sub categories, such as hexacopter (6 rotors), octocopter(8 rotors),
decacopter(10 rotors), dodecacopter (12 rotors) and custom hybrid copters of different shapes
and sizes.
Nowadays, prototypes of hybrid copters can be seen emerging, an example prototype developed
by TU-Delft, Netherlands (Quadshot), makes use of a quadcopter built over an RC airplane
structure. It claims to achieve long distance flight at the speed of an RC airplane and hovering
capability of a quadcopter, though has been found tedious to control due to its mixed nature
of operation.

Aerial platform comparison

Balloon

The air balloon structure equipped with electronics is one of the possible candidates for Micro
Aerial Vehicle (MAV). The balloons are usually used for inspection or data gathering at high
altitudes (using hydrogen as the payload carrying medium). A recent development demon-
strated the Raspberry Pi hardware coupled with various sensors for high altitude monitoring.
It reached a peak height of of 39,994 meters with a payload of 200g, baloon volume of 3m2 with
hydrogen as the carrying medium[13]. The flight time recorded was 24 hours.
• Advantage:
1. Longer flight times due to hydrogen as a carrying medium.
• Disadvantage:
1. A need for accurate setup, launch and monitoring on a regular basis from various
GCS (Ground Control Station).
2. The user may have no control of adjusting its position in the air as it drifts away
with wind.

RC airplane (Fixed wing)

RC airplane have been in use for over three decades now. They are categorized as gas based
that runs on fuel or electric based that runs on batteries. Both types are controlled via a user

22
controlled RC transmitter that communicates with an RC receiver on board the flight. The
characteristic of an RC airplane matches closely with that of a commercial airplane.
• Advantage:
1. Fast and continuous movement enables to reach long distances over a short time.
2. Models have been developed where an RC airplane propels itself on launch from
hands of the user.
3. Fixed-wing airplanes are useful for high-altitude or long-range applications such as
search and rescue, surveying and mapping large areas and crop inspection (when
made autonomous). Moreover, they are ideal for aerial mapping and terrain mod-
elling large areas, undertaking topographic surveys and mine sites.
• Disadvantage:
1. RC airplanes have continuous movement thus, cannot be used to hover in air.
2. They require costly maintenance with gas based engines.
3. Occupies space due to large wing span of the RC airplane.

RC helicopter (rotary)

In recent years, a new type of Micro Air Vehicle (MAV) has emerged as the small-scale equivalent
of the full-sized helicopter. Radio-controlled helicopters are model aircraft that are distinct from
RC airplanes due to the differences in construction, aerodynamics, and flight operation.

Figure 3.2: Effect of torque on a helicopter. The tail rotor compensates for the main rotor’s
torque.

The helicopter is a rotary or propeller-based system. Several basic designs of RC helicopters

exist, of which some are more maneuverable than others based on its construction. Unlike the
fixed wing models, these small sized copters are able to fly in every direction, horizontally and
vertically, as well as able to hover in a fixed position. The cyclic controls (pitch and roll) and
the tail rotor (yaw) are used to control the movement of the helicopter. The torque balancing is
performed by the tail rotor pushing the air in the opposite direction of the main rotor’s torque
as shown in Figure 3.2. Without the tail rotor, due to torque imbalance, the helicopter would
spin almost as fast as the propeller and lose control.
• Advantage:
1. Vertical Take Off and Landing (VTOL) and the ability to hover for an elongated
period of time.

23
 2. Applications such as detailed inspection or surveying hard-to-reach areas such as
pipelines, power lines, bridges and rail tracks are possible.
• Disadvantage:
1. The helicopter design comes with the presence of a large main rotor blade which can
be unsafe in control for indoor flight tests.
2. Helicopter may require careful maintenance due to presence of delicate components
such as swash plates which help to point the helicopter’s main rotor to a specific
direction during pitch.
3. The main rotor blade creates significant noise during its operation.

Multicopter
In contrast to the helicopter design that incorporates of two rotors, a multicopter or multirotor
is a rotor craft having more than two rotors.
Multicopters are able to hover and fly at low altitudes and low speeds, making them suit-
able for applications such as aerial photography, aerial video, power line inspections and land
mapping operations. The multicopter closely resembles the helicopter in terms of capabilities
and operation, however it adds to several other advantages in terms of ease of control and
maneuverability.

(a) Tricopter (3 rotors) (b) Quadcopter (4 rotors)

(c) Hexacopter (6 rotors) (d) Octocopter (8 rotors)

Figure 3.3: Various multicopter designs

• Advantage:
1. With a traditional helicopter design, a large primary rotor is used to generate lift,
and changes in thrust are generally achieved by varying the pitch of the rotor blades.
The changing of the speed of one large rotor requires too much time. Further, the

24
 mechanical parts needed to adjust the pitch of the fast-spinning blade are complex
and difficult to maintain. In case of Quadcopters, they are able to achieve thrust
changes by varying the speed of each one of the smaller and lighter rotors thus, able
to avoid using complicated variable pitch components[14].
2. A traditional helicopter must require a tail rotor to counteract the torque created
by the primary rotor. Quadcopters, on the other hand, do not require a tail rotor,
since the counter-rotating rotors cancel out each other’s torques[14]. These primary
differences lead quadcopters towards a simpler design that is cheaper to build and
easier to maintain.
• Disadvantage:
1. Quadcopters are difficult to control since its mass is concentrated in a small area,
the rotors must react very quickly to counteract the tendency to tip over. Although
simpler in mechanical construction, a quadcopter requires complicated electronics
and software. The hardware controller feeds the corrective forces for balancing each
of the motors at least 50 times per second.
2. For a given thrust, it is more efficient to have a single large rotor blade and multiple
small blades. Quadcopters are relatively less efficient than a helicopter of the same
size.
The table 3.1 identifies the key characteristic of each of the various multicopter designs. This
analyses would further help us to choose the appropriate design based on the requirement in
this project. Please note that the octocopter has been omitted from the discussion for brevity
reasons. The interested reader can extrapolate the understanding derived from the given table
to understand its characteristics.
This research is directed towards one of the requirements of Sensafety (also, mentioned in the
Introduction). The research challenge is to monitor specific regions during a public event and
forward data gathered using wireless networking. A prior work conducted at Thales by Heimans,
et.al, in the context of Sensafety, is available in [15].
A quadcopter is chosen as the platform for research for the following reasons:
1. VTOL and ability to hover about a specific region in space.
2. The cost of a quadcopter design is economical as compared to a hexacopter. With more
rotors, quadcopter makes a better choice than a tricopter design (refer to table 3.1).
3. Many Open Source Project (OSP) choices for hardware and software are available for a
quadcopter design, see Appendix A.
4. The payload used in this project would amount to about 100 grams, that includes the
networking hardware and a small high definition (HD) camera. A quadcopter platform
can handle any given payload based on the motors and propeller combination used. The
quadcopter platform with standard components weighs about 1.3 kgs without payload.
For the given payload, the flight time will not be significantly affected.

25
 Features Tricopter Quadcopter Hexacopter
Tricopters have to tilt
Quads are simpler and Similar to a quad
the rear motor using a
more reliable as the construction but due
Simplicity servo for movement
only moving parts are to increased rotors is
and are relatively
the propellers slightly tedious
tedious to control.
More expensive than a More expensive than a
Least expensive (3
Cost tricopter (4 motors, 4 quadcopter (6 motors,
motors, 3 ESCa )
ESCs) 6 ESCs)
Comparable to a Two additional rotors
With a (large)
tricopter. With an provide increased
propeller diameter
additional rotor, thrust that
Flight time and less weight, a
thrust compensates compensates for slight
slight increase in flight
for slight increase in increase in total
time can be expected
total weight weight
Greater payload due Can carry greater
Payload Lesser payload
to slight additional payload than a
capacity capacity
thrust quadcopter
Better for aerial
Applications where Suitable to heavier
photography in
Application agility is more cameras for
monitoring specific
important photography
regions
Stable but slow
Better stability than a With six rotors,
reaction to heavy
Stability tricopter due to more improved stability can
winds due to lesser
rotors be expected
rotors
Survive malfunction of
a failed rotor by
Hexacopter will
A Tricopter has higher giving up yaw control
perform fairly well
Failure chances of failure due torque and using
with one less rotor
to rotor malfunction remaining props to tilt
available
the axis of rotation
(via software control)
Most popular Useful to address
Feasibility Less design choices are
multicopter design applications having
for the available for frame
and multiple frame higher payload
project construction
types are available requirements

Table 3.1: Comparison between different types of Multicopters

a
ESC: Electronic Speed Controllers are used to convert DC voltage from energy source along with Pulse Width
Modulated(PWM) output signal from controller board to varying AC voltage to the brushless motors.

26
3.2 Multicopter platforms
This section presents an overview of the publicly available OSPs for a quadcopter. The OSPs
help talented individual developers to contribute their knowledge on a common platform that
results in faster development of hardware and software features, tested by many different com-
munity members. In addition, these projects allow researchers to extend the existing work done
by others and provide a baseline comparison of various approaches. The term autopilot is often
used, which is a hardware-software solution that offers algorithms to assist in navigation of the
aircraft. The OSPs provide such autopilots and remain highly competitive with other commer-
cial alternatives. They have proved to be successful for many research based applications [1].
The description of state-of-the-art OSPs available are presented as below:

Figure 3.4: Open-source quadcopter hardware (a) Paparazzi, (b) Openpilot, (c) ArduPilot, (d)
Pixhawk, (e) Mikrokopter, (f) KKmulticopter, (g) MultiWii, (h) Spiri
Images may not be to scale, source [1]

1. Paparazzi
Paparazzi is one of the oldest used OSPs and in existence since 2003. It is an open
source autopilot system oriented toward inexpensive aircraft. It started originally as a
fixed-wing autopilot that now has extended its configuration for use with quadcopters.

27
 The Paparazzi unmanned systems project is now being used and developed at the ENAC
University and the MAVlab of the TU-Delft[16]. It provides Graphical User Interface
(GUI) based Ground Control Station (GCS) and provides flight-path scripting that makes
outdoor missions convenient. More information can be found in [16].
2. Openpilot
This project features a real-time operation system modified from FreeRTOS, which is an
open source operating system. Openpilot supports fixed-wing and helicopter with some
changes in software configuration. This platform is used by researchers and hobbyists
working on aerial robotics or other mobile vehicular platforms where stabilization and
guidance are required[17]. A GUI based GCS helps to tune the PID1 gains of the flight
response. More information can be found in [17].
3. ArduPilot
ArduPilot is an autopilot project that is based on AVR architecture (extended to ARM
architecture, in 2013). It supports both fixed-wing and multicopter platforms. The key
highlights of this platform is the use of a well developed software interface GUI that is
used as a research tool for data analysis, display flight information and tuning of controller
gains. It supports configuration with several different GCS such as Mission Planner and
Qgroundcontrol. More information can be found in [7]. It uses a combination of Lesser
GPL and GPL v.3 license for its software unlike other OSPs that use only GPL license.
4. Pixhawk
Pixhawk uses onboard computer-vision algorithms developed by ETH Zurich, Computer
Vision Group [18]. Among the OSPs introduced in this section, only Pixhawk has com-
puter vision and designed to support indoor navigation. It also provides GCS based
Qgroundcontrol support that uses MAVLink protocol2 . This project has merged with the
Ardupilot project in 2013 and the autopilot is now commonly called 3DR Pixhawk (3DR
is the official manufacturer of open source hardware for Arducopter).
5. Mikrokopter
Mikrokopter is a quadcopter autopilot system developed since 2006. A GUI based software
for PID gain tuning and flight analysis is provided with this OSP. It may be interesting
to note that in 2010, the University of Tasmania and the Australian Antarctic Division
made use of Mikrokopter to monitor moss bed in Antarctica [1, pg.35].
6. KKmulticopter
This project has become KKmulticopter targets the hobby market interested in aerial
photography using quadcopters. However, compared to other projects this provides the
most basic configuration devoted to manual flight. It provides a tri-axial gyroscope for
inertial measurement3 and a microcontroller for control. It provides no GCS and PID
tuning is done using on board potentiometers.
7. MultiWii
MultiWii is based on an Arduino board as the main processor. For inertial measurement,
it uses accelerometers and gyros of the commercial off-the-shelf Wii motion controller from
Nintendo[1, pg.36]. It provides a GCS for flight data analysis.
1
PID refers to Proportional-Integral-Derivative, the tuning gains that determine the responsiveness of the
controller, and thus the flight
2
MAVLink: A protocol library for lightweight communication between Micro Air Vehicles (such as quadcopter)
and ground control station(GCS)
3
Inertial measurement: An algorithm that runs on a dedicated hardware that measures and reports on a craft’s
orientation, velocity and gravitational forces, using a combination of accelerometers and gyroscopes, sometimes
also magnetometers.

28
 8. Spiri
Spiri is the latest addition to the OSPs, that started as a kickstarter project in mid 2013
and has seen rising popularity ever since. This platform is dedicated to quadcopters alone
and aims as a developer-friendly small-scale quadcopter. It is a linux-based quadcopter
that runs Ubuntu Linux with ROS (Robot Operating System); comes integrated with sen-
sors, camera and Wifi. In addition, it allows to integrate cloud support and development
tools. This platform has been prototyped and proven to work but not yet available.
9. Parrot AR.Drone
Parrot AR.Drone is a radio controlled flying quadcopter built by the French company
Parrot that has gained wide popularity since its inception in 2010. It is a light weight
(≈400g) out of the box, ready to fly vehicle without requiring any specific configuration.
The brain of the processor runs on a 1 GHz, 32 bit ARM Cortex A8 processor with
800MHz video DSP TMS320DMC64x. It consists of 3-axis gyroscope, accelerometers,
magnetometers respectively, a down facing and front facing camera for image processing
needs alongside a WiFi 802.11b/g standard hardware. Moreover, it comes with relatively
soft props and a foam protective ring. It is a good choice for research, however the
following points are taken into consideration before choosing our platform:
(a) Limited functionality extension: AR.Drone is a proprietary platform that provides
Open API model that exposes high level functions to send/receive certain commands
using its standard protocol. It does however, allow developers to alter its firmware
or make improvements in its software.
(b) Upgrade to a newer firmware: Upgrading to the newer firmware usually means pur-
chase of the newer processor that supports this firmware. AR.Drone 2.0 came with
an newer firmware and support of limited GPS interface functionality.
(c) Limited range of flight: The flight range and height is limited to the maximum range
the Wi-Fi provides.
(d) AR.Drone’s controller is a black box and its flight parameters come pre-tuned for
use. Addition of payload will cause instability to the flight.
(e) Operating outdoors: An important focus in this project is on outdoor navigation.
AR.Drone is optimized for indoor use, provides good stability and reliability, however
it is susceptible to winds due to its light weight and motor-propeller design.
10. Miscellaneous
The platforms mentioned thus far are the most popular platforms in existence. There are
however other flight controllers such as DJI Naza, Wookong and from Hobbyking. The
former allows autonomous flight but comes packaged with a proprietary software that
cannot be changed, while some others are either clones or not as popular as others. We
limit our analysis to the platforms already described so as to keep our discussion succinct.
Interested reader may explore the other platforms at his/her own discretion.

Quadcopter platform selection

To build a multicopter, the hardware design and component choices are very important. From
the above description, we select most likely candidates for our platform selection and specify
their on board components. We omit further discussion of OSPs such as KKmulticopter, being
used mainly for manual flight control due to limited sensors; Spiri as it is not yet released;
MultiWii board has only partial support for altitude hold and functionality after GPS integra-
tion; AR.Drone is a partial open source hardware and software project with certain limitations

29
already discussed.
The interested reader can go through Appendix A where details of hardware and software for
the various OSPs are listed. Each of the important parameters in hardware such as types of
sensors used, controller board and its features are discussed. In terms of software, the various
attitude estimation algorithm that OSP provides have been closely studied and its description
is given. In the end, the controller evaluation in terms of probable stability an OSP could offer
along with its GCS support is illustrated.
Given the various choice of OSPs and their detailed comparison(see appendix A), it was decided
to use Ardupilot for research purposes. In summary, the ArduPilot offers:
1. Employment of onboard MPU-6000 Invensense chip having a small footprint that incor-
porates 3-axis acceleromter and 3-axis gyroscope onto a single chip. The flight controller
itself weight ≈ 35g.
2. Multiple interfaces(such as I2C, SPI) and GPIO pins for interfacing external sensors such
as sonar and magnetometer (i.e. compass).
3. Usage of Non-Linear Complementary Filter(NCF) uses a P-I closed loop controller feed-
back between the measured and desired attitude value, to minimize the error obtained.
This results in a smooth attitude estimation.
4. Mature GCS that can be exploited for our own use and provides libraries for waypoint
navigation. The GCS is programmed in C# and supports python scripting for extensions.
The flight controller hosts the Atmega2560 microcontroller, and supports an extension of
C++. More information can be found in appendix A.
The ArduPilot OSP is used primarily for running the algorithms for stabilization and navigation.
The stability of platform is of prime importance without which other tasks such as waypoint
navigation, stable hovering and networking tasks cannot be performed reliably. The next section
discusses the chosen of platform for networking.

3.3 Networking platforms

The primary requirement in this research is to develop a mobile networking platform. There is
a need to isolate the microcontroller that is used as the flight controller from the networking
process. This isolation helps keeping the two functionalities separate and detecting possible
problems that may arise with the integration of the two. For instance, with both functionalities
(navigation and networking) running simultaneously on a dedicated hardware may cause the
aircraft to crash in case of a networking reset due to overload of packets or sudden surge of
power.

Mobile networking requirements

We start by listing our networking requirements before looking at the various alternatives for
hardware selection:
1. Host a linux based Operating System (OS). Linux OS is the preferred option due to its
ability to support a wide range of networking capabilities and security options. Examples
of commonly used linux based OS are ubuntu, debian, fedora, openwrt, android, etc.
2. Sufficient support for wireless adapters that allow to run Ad-Hoc mode.

30
 3. Availability of General Purpose Input and Output(GPIO) for interfacing. We could use
GPIO pins to interface the networking hardware with the flight controller board, or other
interfacing requirements.
4. Available forums for discussion of issues arising out of the use of hardware, wireless
adapters4 and OS in general.
5. Easy integration of camera hardware for experimentation.
6. As a rough estimation, the hardware should be kept within a margin of 100-200 grams
inclusive of the wireless adapter and camera. The weight of the hardware increases the
total weight of the aerial platform and directly affects the total flight time.

Hardware options

We discuss the various alternatives in choosing the right hardware. Figure 3.5 shows the various
processors that are discussed below.

Figure 3.5: A screenshot various processor boards that can be used for networking,
(a)BeagleBoard-xM, (b)BeagleBone Black, (c)Raspberry Pi, (d)PandaBoard, (e)Android phone,
(f )TP-Link Router

1. BeagleBoard:
The beagleBoard-xM hosts a 1 GHz Cortex-A8 CPU, 512 MB of RAM, and plenty of
GPIO pins. It is low in power and supports many modern operating systems. This is the
best candidate for selection as it sufficiently supports most of our project requirements. It
has various options of connectivity such as on-board four-port hub with Ethernet,HDMI
port and USB host. The drawbacks being the cost of board (120 e), additional cost of
the High-Definition camera and a footprint of 3.25” x 3.25”, which is considered slightly
large.
4
A Wi-Fi dongle is also called a wireless adapter.

31
2. BeagleBone Black:
BeagleBone Black is a credit-card-sized Linux computer that has evolved out of the long
lineage of BeagleBoard products into the current version; a small form-factor, powerful
and expandable product. It is essentially a stripped down version of the BeagleBoard
discussed above. It has a stable OS support for Angstrom linux, Android and Ubuntu.
As of June 2013, its costs dropped by half to around 40 e. It has the option to boot either
directly from the on-board chip or from the SD card. An external USB camera can be
interfaced.
3. Raspberry Pi:
Raspberry Pi is a low-cost and relatively high performance miniature computer based on
Debian operating system. It runs on 700 MHz ARM11 processor, with 512MB of RAM.
It has an ethernet port, two USB ports, one HDMI and several GPIO pins. At the time of
this writing, Raspberry Pi released its 5 Mega Pixel High-Definition camera module that
costs less than 20 e. The Raspberry Pi runs Raspbian OS which is a modified version of
Debian OS and has stable support for device drivers for different wireless adapters.
4. PandaBoard:
The PandaBoard is a miniature powerhouse, [19]. It hosts a dual-core Cortex A9 CPU
with 1GB of RAM. It comes with a LAN port, Wi-Fi, Bluetooth and with addition of
expansion connectors. The cost of the hardware is valued at 140 e. The PandaBoard
supports a 5 Mega Pixel auto focus camera module(e-CAM57 MI5640 MOD) that can be
bought separately.
5. Android Phone:
An Android phone has lately become the trend globally and offers various functionalities.
The android OS is open source and has support for the wireless Ad-hoc mode. However,
it is to be noted that not all versions of android have support for the routing protocols
that we employ in our research and thus, compatibility may become a problem. More-
over, the cost of the phone overruns the cost of a processor hardware that can support
extended functionalities. With limited options of interfacing being a slight drawback, a
USB interface is the only option left to communicate with the the flight controller.
6. TP-Link Router:
The TP-Link wireless router is a combined wired/wireless network connection device
designed specifically for office and personal use. It costs less than 30 e and runs an
open source OpenWRT operating system that is based on the linux kernel. OpenWRT is
primarily meant for routers and networking functionalities. It consists of mutiple ethernet
port with multiple antennae for increasing the wireless range. It is an ideal candidate for
use in mobile networking as it has clean support for the necessary routing protocols to be
tested at Thales in addition to support of languages such as C++, python and bash that
are used to develop the algorithms. The drawback however is the lack of GPIO pins for
communication and the bulk size of the router.
At the time of this writing, TP-Link introduced a pocket sized wireless router (TP-Link
TL-WR702N) that is based on IEEE 802.11b/g/n standards. It is similar to the standard
TP-Link router however is smaller in size with one ethernet interface. An ethernet to usb
interface can help with communication with the flight controller however, interfacing a
supported camera may pose problems.

32
Networking platform selection

Given the various choice of networking platforms, we attempt to narrow down on the BeagleBone
and Raspberry Pi hardware, both based on ARM architecture, a low-cost solution and adheres
well to our requirements. A further classification is made between the two to bring out relevant
features imposed by our requirement. Multiple boards would need to be purchased to create
nodes in the mesh network. It can be seen from the comparison depicted in Table 3.2, the
characteristic of both processors are nearly the same.

Features BeagleBone Black Raspberry Pi

Base Price 45 e 35 e
1GHz TI Sitara AM3359 ARM
Processor 700 MHz ARM1176JZFS
Cortex A8
RAM 512 MB DDR3L, 400 MHz 512 MB SDRAM, 400 MHz
2 GB on-board flash and
Storage external SD card
MicroSD
Operating Angstrom (Default), Ubuntu,
Raspbian, Ubuntu, Android
Systems Android
xPower
210-460 mA @5V 150-350 mA @5V
Draw
2 USB hosts, 1 micro USB
1 USB host, 1 mini-USB client,
Peripherals Power, 10/100 Mbps Ethernet,
10/100 Mbps Ethernet
RPi camera connector
GPIO pins 65 pins 21 Pins

Table 3.2: Comparison between BeagleBone Black and Raspberry Pi as networking hardware.

With the requirement of a camera on our mobile platform, the Raspberry Pi supports a 5 MP
High Definition(HD) camera that is capable of 1080x720 pixels of video at 30 fps. The camera
weighs just over 3g and has a dimension of 25mm x 20mm x 9mm. The camera is supported
in the latest version of Raspbian. The overall weight of our networking hardware including the
wireless adapter, camera and Raspberry Pi processor board weighs just over 100g.
In conclusion, we choose the Raspberry pi due to its better support for camera, light weight
and adheres well to our stated networking requirements.

33
Chapter 4

Wireless Networking

This chapter starts out with a discussion of the basic layers of an TCP/IP model that forms the
backbone for rest of the chapters related to networking. The section 4.2, presents an introduction
to wireless networks. The section 4.3 and 4.4 discusses the MANETs and the routing protocols
in use today. The last section 4.5 presents an analysis for choice of the MANET routing protocol
used in this research project.

4.1 Internet protocol stack (TCP/IP)

The Internet Protocol Suite, TCP/IP, is a model of protocols used for communication over the
internet and other similar networks. It is a five-layered networking model that emerged from
the standard Open System Interconnection (OSI) seven-layered model.

Figure 4.1: The Internet Protocol Suite (TCP/IP) five-layered model.

The TCP/IP or OSI reference model is adhered by all networking equipment and gives them
the liberty to implement their own choice of protocol based on the application. Figure 4.1 shows

34
the standard five-layers of the model. The term TCP/IP refers to the TCP layer that resides
over the IP layer in the protocol stack. For more details on OSI and TCP/IP suite, please
refer to the Appendix B. Below, the description of each layer is given in brief with respect to
Figure4.1.
• Application layer :
The end system generates or consumes user data.
• Transport layer :
The responsibility of this layer is end-to-end reliability in communication. The TCP
transport protocol breaks the user data into manageable chunks called segments at the
source. The segments are reassembled into user data at the destination. Two protocols
can be used at this level, namely TCP and UDP. The choice to use which protocol is made
based on the application’s transmission reliability requirements. On the internet, TCP is
used.
• Network layer :
The routing and delivery of data is the key responsibility of this layer and a crucial
component of this architecture. The IP network layer protocol encapsulates the TCP
segments into datagrams. Routers primarily work at this level, as their function is to
route or forward packets.
• Data Link layer :
The link layer protocol encapsulates IP datagrams into frames. This layer addresses the
link-to-link transmission and reception of user data along with error control.
• Physical layer :
The physical protocol transmits and receives a sequence of frames as continuous bit
streams. The bit stream is transmitted or received via physical media such as coaxial
cable, fiber optics, and RF.
In this research, we mainly focus on Network and Transport layers. We extend the TCP/IP
model by adding extra layer(s) on top of the transport layer, discussed in Chapter 5 and Chapter
10.

4.2 Wireless networks

The fundamental difference between wired and wireless network is the broadcast nature of the
transmission. A network that sends data over a cable from one point to the other, is known as a
wired network or forms a local area network (LAN). On the other hand, data transmission over
a wireless medium such as radio waves, is called a wireless network and forms a wireless local
area network (WLAN). Wireless access is made possible by using wireless network adapters,
devices that allows a system to join a another wireless device within its range. These adapters
contain a radio transmitter and receiver that supports the IEEE 802.11 standards for Wi-Fi.
Examples of devices using wireless adapters are home or office routers and Wi-fi dongles. Below
we discuss the fundamental features of wireless LAN.

Wireless LAN features

The wireless LAN is based on the following features:

1. It uses the unlicensed signalling frequency of 2.4 GHz and 5Ghz, part of the Industrial,
Scientific and Medical (ISM).

35
 2. Most devices use WLAN 802.11 IEEE standards. There are various versions of the 802.11
standard (such as 802.11b/g or n) where the network bandwidth supported varies between
2 Mb to 54 Mb per second, respectively.
3. It mainly operates under two modes namely, Infrastructure and Ad-Hoc mode.
4. The wireless nodes in the 802.11 standards are limited in range. Their usual range is
between a few meters to 300 meters based on the device, frequency, transmission power
and antenna characteristics.
5. The IEEE 802.11b/g/n utilizes the 2.40 - 2.48 GHz spectrum, as one of the ISM bands.
This spectrum is sub-divided into various sub-frequencies or channels with a center fre-
quency and bandwidth. Any wireless adapter operating in the 2.4 GHz spectrum operates
in one of these 13 channels.

Wireless LAN modes

• Infrastructure networks:
An Infrastructure network is a Point-to-Multipoint connection. A single point or an
intermediate access point (such as a router or PC running an access point software) is
connected to one or many wireless devices. The various devices can be connected via a
wired or wireless connection to the main base station or access point. The data from all
connections pass through this access point. Figure 4.2 (a).

Figure 4.2: Infrastructure (Centralized) Vs. Ad-Hoc modes (Decentralized). Source: [2].

• Ad-Hoc networks:
An Ad-Hoc network is deployed where wireless network infrastructure unavailable, also
called an infrastructure-less network. It is a point-to-point or peer-to-peer (P2P) connec-
tion. It allows each node to wirelessly connect to the other node without the need of an
intermediate access point (or infrastructure), Figure4.2(b). There is no restriction on any
node to leave or join the wireless network. Ad hoc networks are classified as either Static
Ad-Hoc Networks (SANET) or Mobile Ad-Hoc Networks (MANET). Traffic is transmit-
ted to neighbours only when within its radio range when using ad-hoc mode, therefore a
MANET routing protocol sets up and maintains traffic paths [4, Sec 2.1].

36
 Infrastructure network
Based on an access point and
Cost
requires additional cost and set up
Offers the advantage of scalability
Scalability with more clients and with higher
bandwidth
More coverage due to higher power
Range
of fixed access point
In an infrastructure network, the
Topology variation of throughput and range
can be anticipated
Due to direct connectivity with an
Data path access point, the data path is
certain
Strong levels of security are
Security available with the infrastructure
mode
Uses LAN or WLAN for connection
Extension and access point provides the
internet
Based on the idea of a (immovable)
Application
access point in the given region
The failure of access point brings
Failure
down the complete network
Ad-Hoc network
Easier to set up, no additional
network hardware beyond the nodes
With many nodes on the same
channel, the amount of interference
grows and performance suffers
Generally shorter working range
due to limited power of the (mobile)
ad-hoc nodes
Due to the constant change in
network topology, throughput and
range varies
No control over the path the data
takes. The data from source to
destination may hop over several
nodes on the way
Does not implement the strongest
levels of security with ad hoc
network
Cannot bridge to wired LAN or to
Internet without the use of
special-purpose gateway
Used only with WLAN and is
meant for mobile of nodes that
appear and disappear constantly
Failure of a node, allows traffic to
be routed via other nodes in range

Table 4.1: Comparison between Infrastructure and Ad-Hoc networks

Table 4.1 shows the comparison between the Infrastructure and Ad-Hoc networks of operation.
Although, the Infrastructure network offers several advantages over Ad-Hoc networks, the Ad-
Hoc network offers advantage in terms of mobility and independent wireless discovery of other
nodes.

4.3 Mobile ad-hoc network (MANET)

A Mobile Ad-Hoc Network or MANET is a collection of wireless nodes dynamically forming a
communication network without the use of centralized or pre-existing infrastructure [20]. The
network consists of nodes that are independent in nature, that may be fixed or mobile and
allowed to move in every direction. In MANETs, the nodes act as routers, forwarding traffic
from source to destination node in multiple hop fashion [3, p.18].
MANET is an improved IP-based networking technology and offers many advantages to organi-
zations that require wireless roaming. MANETs can be used with diverse applications such as
in emergency services, battlefield, fire/safety/rescue that requires rapidly-deployable commu-
nications with efficient dynamic networking. Further, the nodes may be located on airplanes,
ships, or ground vehicles; an army personnel can carry a small router configured to be part of
a MANET, in his backpack, also referred to as wearable computing and communications. With
the devices having a smaller footprint and given the potential impact this technology will have

37
in near future, other applications not yet realized will soon emerge [21]. In this thesis, we apply
the concept of MANET with an autonomous UAV.

MANET features

Before we proceed to discuss the routing protocol used by nodes in a MANET used to forward
traffic between nodes, it is necessary to understand the various features and limitations in a
MANET. The following are important points derived from RFC2501 for MANETs [21]:
1. Wireless equipment:
A wireless node consists of transmitter, receiver and an antenna that can be omnidirec-
tional (broadcast) or direction (point-to-point) or any other hybrid antenna.
2. Node Configuration:
All nodes in a MANET operate on a specific channel or a frequency, along with the same
SSID, to make it possible to communicate.
3. Dynamic topologies:
The nodes are free to move and data is forward to one another typically via multi-hop
fashion. The network topology often changes frequently and routing in nodes are designed
to cope with these changes.
4. Bandwidth-constrained, variable capacity links:
The efficiency of wireless links are lower than their hardwired counterparts. The maximum
throughput may be lowered due to multiple interferences, fading, noise, etc. in the chosen
frequency of operation.
5. Energy constrained operation:
It can be understood that some or all of the nodes in a MANET rely on battery. One of the
important system design criteria is thus, the need of optimization for energy conservation
[21]. An efficient algorithm for energy conservation in MANET has been developed by
Lopez, et al., Thales [2].
6. Limited Physical Security:
Mobile wireless networks are prone to increased eavesdropping, denial-of-service attacks
and spoofing on their respective channels, in contrast to wired networks. As a benefit,
decentralized nature of network control help MANETs cope with single node failures.
This is due to clever routing strategies to get data to the destination.
7. Goal of MANETs:
The goal of MANET is to provide effective operation over a wide range of mobile networks.
In addition, MANETs should react efficiently to traffic demand and topological changes
while maintaining effective routing in the mesh network [21]. In this respect, various
routing protocols are discussed in literature to cope with the dynamic nature of MANET.

4.4 MANET routing protocols

In the last decade, MANET has undergone large amounts research regarding the various routing
strategies suited to the dynamic nature of MANET. Routing in MANETs is a tedious task due
to the mobility of the nodes. The mobility causes frequent changes in network topology and
requires robust mechanisms to search for the nodes and maintain routes. When a node moves,
the established paths with neighboring nodes may break which results in re-establishing new
routing paths by searching for other possible routes, dynamically. Due to the inherent nature
of wireless networks, error rates may be high and the different power levels between different

38
mobile nodes, make routing protocols more complicated. Many protocols have been proposed
for MANETs. These routing protocols are classified as reactive, proactive or hybrid, each of
with their own trade-off relative to the other. In the section below, a high level overview of the
various routing protocol is given.

Reactive protocols

In this routing scheme, route to a destination is only determined on explicit demand by flooding
the entire network with Route Request packets (RRQ). The disadvantage using this scheme
of protocol is high latency time in finding the route and extensive flooding can cause network
clogging. Such protocols however, can reduce routing overhead in large networks on which there
is no data-traffic, thereby is very appealing in the resource-limited environment. Examples of
protocols in this scheme are: Ad hoc On-demand Distance Vector (AODV) routing, Dynamic
Source Routing (DSR). Both of these routing, protocols have become well known standards for
use in MANETs.
• Ad hoc On-Demand Distance Vector Routing (AODV)

Figure 4.3: A possible path for a route request/reply from source (A) to Destination (D) in
AODV.

The AODV is a reactive routing protocol in MANETs, where a route to a destination is

established, only on demand. With AODV, no resources is expended when no route is
required. When a route is needed and not yet available in its routing table, a so called
Route-Request (RREQ) packet is broadcasted. The route request packet is forwarded by
all receiving nodes eventually reaching the destination. Once the RREQ packet arrives at
the destination node, a Route-Reply (RREP) packet is returned along the same path to
the source node, Figure 4.3.
In case a node detects a broken link, a Route-Error (RERR) packet is sent to the affected
nodes as per its routing table. There are many more design considerations not discussed
here. More information can be found in RFC3561 [22].

Proactive protocols

A proactive approach to MANET routing seeks to keep a constantly updated network topology
understanding in all nodes. In theory, the complete network must be known to all nodes. This
results in constant overhead of routing traffic, but avoids an initial delay in communication [4,
Sec 2.2]. The proactive protocols are also referred to as Table driven protocols as each node
in the network maintains the list of its neighbors. Some examples of protocols in this scheme
are: Optimized Link State Routing (OLSR) , Destination Sequenced Distance Vector (DSDV)

39
routing, Better Approach To Mobile Adhoc Networking (BATMAN). The first two protocols
are RFCs1 and the third protocol is yet to become a standard. The OLSR protocol (RFC 3626)
is discussed below.
• Optimized Link State Routing Protocol (OLSR)
In OLSR, each node in the network maintains an updated list (routing table) containing
the route to all destination nodes. The topology information is exchanged between the
nodes on periodic basis. The main objective of OLSR is to minimize the control traffic
by selecting a small number of nodes, known as Multi Point Relays (MPR) for flooding
topological information [23]. MPR’s are used in in route calculation, and help in forming
an optimal route from a given source to any destination.
OLSR being a table-drive protocol, its operation mainly consists of maintaining and up-
dating (route) information in a variety of tables. The data in these tables is based on the
received control traffic from other nodes, and control traffic is generated based on data
gathered from these tables. The route calculation is itself driven based on these table [4].
OLSR, generally proposes four types of periodic control messages:
1. HELLO - ’Hello’ messages are exchanged periodically with the one-hop neighbors to
obtain neighborhood information. Using this information, each node in the network
is able to construct a Multi Point Relay(MPR) set. Every node determines its MPR
node based on the one-hop node that offers the best routes to the two-hop nodes and
keeps a list of MPR nodes in the network. The ’Hello’ messages are sent in regular
time intervals (e.g. 5 seconds) and are used for finding the information on link status
and neighboring nodes. Figure 4.4 shows the MPR nodes in the mesh network that
broadcast the route packets.
2. TC - Topology control messages are used for broadcasting information about its own
advertized neighbours that includes its MPR set [23]. Hello messages are sent to
only one hop neighbors whereas the TC messages are broadcasted throughout the
entire network.
3. MID - Multiple Interface Declaration messages are transmitted by nodes that run
OLSR and run on multiple interfaces (such as LAN and WAN). These messages lists
all IP addresses in use the by node.
4. HNA - Host and Network Association (HNA) messages provide external routing
information that makes it possible to connect to external addresses. HNA messages
calculate this based on the IP address and the netmask address, to compute the
resulting broadcast address.
A drawback with OLSR is with the overhead caused while maintaining routes to all nodes,
which is often found unnecessary. Insufficient provision of security is another drawback
that is an area of current research [24]. On the other hand, all nodes can quickly obtain
route information and establish a session, thereby resulting in faster forwarding of packets
on request.
1
A Request for Comments (RFC) is a publication of the Internet Engineering Task Force (IETF) and the
Internet Society, the principal technical development and standards-setting bodies for the Internet,Source

40
 Figure 4.4: MPR node sends Topology control (TC) messages, Source: [3].

Hybrid protocols

Hybrid methods combine proactive and reactive approaches to find efficient routes, with less
control overhead [25]. An example of such a protocol is Zone Routing Protocol (ZRP).
• Zone Routing Protocol (ZRP)

Figure 4.5: Zone routing protocol. The intra-zone uses proactive while the inter-zone uses
reactive protocol. Source: [4].

Zone Routing Protocol ZRP divides the topology into routing zones and aims to utilize
different routing protocols within and between these zones depending on the strengths and
weaknesses of these protocols. The zone size is defined by a parameter 0 r0 that dictates
the radius in hops. Intra-zone routing is carried out by a proactive protocol and inter-
zones communicate via reactive protocol4.5. Within a zone, an up-to-date topological
information on nearby nodes is available with no startup delay. While the inter-zone
routing with reactive protocol, eliminates the need for nodes to keep an updated state of
the entire network [4].

4.5 Selection of OLSR routing

In this research, OLSR protocol being an established proactive protocol is used on all nodes.
Hybrid protocols are not applicable since the size of the network used is small. The aerial vehicle
is considered as the mobile router node. It is important to note that all nodes in the network

41
must use the same routing protocol. Each routing protocol has its own control mechanism for
finding routes. In this respect, the following factors are of importance:
• Quick route discovery
• Greater throughput
• Low power consumption
In [3], simulation was conducted on multiple nodes with OLSR (proactive), DSR and AODV
(Reactive) routing protocols with respect to delay, network load and throughput performance in
the MANET. It was found that OLSR offers low load on the network as compared to the other
two protocols, up to 20 nodes. With increasing the number of nodes from 20 to 80, the network
load using OLSR increases slightly. In terms of network load and throughput performance,
OLSR showed the best result even for 80 nodes that were simulated in this experiment.
To conclude, the OLSR protocol is chosen as it determines optimal routes between any two
nodes (in terms of number of hops). It is suitable for dense and large networks and only dis-
tributes partial link state (trace of network topology and changes) information via MPR nodes.
Additionally, the OLSR gathers link quality information (by using the Expected Transmission
Time Metric (ETX) - A metric to assert link quality between nodes). Links that fail to main-
tain the quality requirements are considered disconnected. It is also to be noted that Thales
Nederland B.V has researched OLSR routing in its other research projects [2]. It has been
determined that OLSR serves better for routing in mobile mesh networks with respect to other
state-of-the-art routing protocols.
Experiments have been conducted for testing the power consumption with the OLSR protocol
and its impact on the performance of the aerial vehicle. This is discussed further under section
9.3 in Chapter 10.

42
Chapter 5

Disruption Tolerant Networking

Disruption or Delay Tolerant Networking (DTN), is an approach to computer networking that

seeks to address the technical issues arising in heterogeneous networks that may lack instan-
taneous end-to-end paths. Examples are networks that operate over long haul in outer space,
systems in motion or in extreme terrestrial environments. In this chapter, the history and an
overview of DTN is presented in the first couple of sections. Section 5.3 presents overview of the
DTN bundle protocol. Section 5.4 discusses IBRDTN, an implementation of DTN architecture
and its associated utilities. In the last two sections we discuss the issues based on the current
design of DTN and how this is resolved and extended to effectively use it during autonomous
navigation.

5.1 DTN history

Disruption tolerant networking (DTN) is a relatively new area in the research field of network-
ing communications. DTN concept originally emerged for use with deep interplanetary space
communications (also called, Interplanetary networks or IPN), where communication suffers
loss due to significantly long distances. The problems include:
• Small window of time frame when communication can be attempted, also referred to
as opportunistic contacts. This often is the case in space communications, due to the
very nature of orbits of the planets. Point-to-point communications cannot always be
continuous between satellites on different planets and data loss cannot be afforded due
to disruption in communication (for instance, sun coming in between planet Earth and
Mars). Just to establish a connection alone between two stations using TCP/IP, may take
many hours.
• Long delays produced by large distances in space.
In case of terrestrial environments, MANETs also suffer similar problems. With mobile nodes,
communication may not be continuous and often leads to disruptions in communication links.
This occurs either due to the nodes being at a distance from each other or due to extreme
conditions that persist in the environment causing high delays. To tackle these problems, the
concept of interplanetary networks(IPN) has gradually been adapted to tackle communication
problems in terrestrial networks.

43
5.2 Features of DTN
The usability of standard IP routing protocol is assumed to have the following characteris-
tics:
1. Source and destination have continuous bi-directional end-to-end path.
2. Short round trip times between nodes.
3. Low error rates, i.e. relatively little loss or corruption of data on each link[Pg. 6]dtntuto-
rial.
4. Bi-direction symmetric data rates.
5. Based on TCP/IP internet protocol suite and uses packet switching, see chapter on Wire-
less Networks, Figure 4.1.
There are however, many evolving and potential communication environments that do not
conform to the Internet’s underlying assumptions [5]. These environments can be characterized
by:
• Intermittent connectivity due to the absence of direct end-to-end path between the source
and the destination. In these cases, application of TCP/IP cannot be applied.
• Long or variable delay due to the long propagation delay and queuing delays at nodes
that result in a loss of data. This implies that internet protocols cannot be relied upon,
as most networks expect quick acknowledgement of data.
• High bit error rates occur with the data lost in channels that results in retransmissions and
increased network traffic. For a given link error rate, fewer transmissions can be expected
with shorter hop-by-hop forwarding than internet-type end-to-end transmissions.
As an example, military mobile ad-hoc networks are prone to the problems on intermittent
connectivity, long variable delays and high error rates, due to the constant military movement
and enemy jamming. Other networks where DTN is useful are with sensor networks in motion
that rely on limited battery life; such nodes may not have continuous connectivity. The long
distance (satellite) networks have significant delays where TCP/IP packet retransmissions can
become costly. DTN overcomes these problems by employing a store-and-forward message
switching in its core architecture, Figure 5.1. The email systems, also use store and forward
technique, however they are different from DTN as these are not node-to-node relays. Email
systems store the message in the central storage system which is independently queried by the
destination host. With DTN, the complete message or fragments of data are moved hop-by-hop
from one storage place to the next, along a path that eventually reaches the destination.

Figure 5.1: Store-and-forwarding message switching technique.

44
Each of the DTN (router) nodes necessitates a persistent storage for their queues. This is
required because the communication link to the next hop node may not be immediately available
and retransmission of message may occur. By moving messages in a single transfer on a hop-
by-hop basis via message switching provides the network nodes with immediate knowledge of
size of messages and intermediate storage requirements [5].

5.3 Bundle layer protocol

The DTN architecture implements a store-and-forward message switching by introducing a new
protocol layer, referred to as the bundle protocol hosted between the transport layer and the
application layer. Figure 5.2.

Figure 5.2: Comparison of the Internet protocol stack(left) with the DTN protocol stack(right).
DTN bundles can only be transmitted to/via nodes that follow the DTN protocol, Source [5].

The Bundle Protocol Agent (BPA) is a daemon (a process that persistently runs in the back-
ground) that assists to store-and-forward messages (bundles). Every node follows the same
DTN bundle protocol. The DTN layer enables interoperability between diverse sub-networks
having their own lower-layer protocols. As an example, a flying vehicle with TCP/IP, military
network with UDP and the internet network can all be connected together via DTN interoper-
ability.
Bundles extend the data encapsulation hierarchy performed by the internet protocols [5]. The
BPA inserts a few control messages via headers and trailers along with the application mes-
sage that convey how the bundles should be processed, stored and handled by the next-hop
neighbour, along with the user data.
In intermittent communication links, the conversational TCP protocols (TCP involves multi-
ple source-to-destination signalling round trips during data transfer), may involve significant
time-lapse during end-to-end round trips and may fail completely. In contrast, DTN nodes

45
Figure 5.3: Nodes with bundle protocol supports communication with other DTN nodes with
heterogeneous underlying protocols.

communicate using simple sessions with minimal or no round trips [5], see Figure 5.3. The
DTN protocol supports an optional acknowledgement for the transmitted messages to the des-
tination.

Role of DTN Nodes

A DTN node may act as a source, destination or forwarder of bundles.

• DTN hosts: Only send or receive bundles, but does not forward them (like routers).
• DTN routers: Forwards the bundles received, to nodes that implement the same lower-
layer protocols.
• DTN gateways: These can be considered as special DTN routers that forward bundles to
other nodes that implement different lower-layer protocols. This is how the bundle layer
overlay supports different underlying architectures.
In addition, DTN assigns unique identifiers for each node that may identify them based on a
given region. A simple example for identifiers with two DTN nodes can be dtn : //node1 and
dtn : //node2. The identifier naming can get more complex with more regions and nodes.

Classes of bundle service

The DTN bundle protocol features the following class of service for a bundle:
• Custody transfer:
Custody refers to the bundle that is detained by a node and is considered its responsibility
to deliver it to the destination Custody transfer is an optional service offered by the
DTN that adds additional reliability. The retransmission responsibility of the bundle is
delegated to the next-hop DTN node, so that the former can free its resources.
• Return of receipt:
This is a confirmation by the destination (not necessarily the next-hop neighbour) to the
source that it has received the bundle. When this confirmation is received by the source

46
 node, its resources are freed. This is different from custody transfer, where custodians are
involved.
• Time-to-live(TTL):
A countdown timer is set upon release of a bundle by a custodian (owner). This is the time
after which the bundle will be deleted or freed from the source node’s storage (memory
or file system).
• Priority of delivery: Mainly three modes of delivery are present namely, bulk, normal and
expedited. However, this is not discussed further as it is not used within the scope of our
research.
A time-to-acknowledge timer is initiated with every bundle that requests an acknowledgement
(either custodian or return receipt). When this timer expires and an acknowledgement is still
not received, the bundle transfer is re-initiated but not removed from its file system yet.

DTN Routing Mechanisms

Routing in the MANETs is performed at the IP level (Network layer, see Figure 4.1, Chapter 4).
This layer is responsible for determining the next-hop neighbours and finding a path to deliver
the given message fragments. MANETs are still based on the TCP/IP protocol suite and alone
inefficient to use when disconnections occur [2, sec 6.2]. In order to deliver a bundle (say, a file)
to the next available DTN node, the DTN routing mechanism determines the next-hop DTN
node to which a bundle may be forwarded. Different routing mechanisms have been developed
in literature, such as static neighbour routing, PRoPHET routing and Epidemic routing in DTN.
Some of the available routing mechanisms are briefed below:
1. Default static neighbour routing: The bundle protocol agent or the daemon, only delivers
bundles to its target DTN neighbours by a one-to-one transaction.
2. Epidemic routing: This is a flooding based protocol that increases the probability of
delivery of a message by replicating it across all DTN neighbours the node comes in
contact with. This is considered as the preferred routing protocol in critical military
operations as it offers a higher guarantee for deliverance of a message. It is however, not
very efficient in terms of storage capacity. Flooding creates multiple copies of the bundle
and fills up the buffer (queue) of nodes. It is removed only when TTL of the bundle
expires (which may be many hours long) or an acknowledgement from the destination is
received.
Quality of Service(QoS) is implemented with such routing, that assigns priority to bundles
and makes bundle management more affordable. Interested reader can refer to the work
done by Lopez et. al in [2], defines policies for queuing and bundle management with
QoS.
3. PRoPHET routing: Epidemic routing is resource hungry as it does not deliberate to
eliminate replication of messages and still improve the probability of message delivery. The
Probabilistic Routing Protocol using History of Encounters and Transitivity (PRoPHET)
protocol, maintains a set of probabilities of nodes encounters and uses it for successful
delivery to known destinations in DTN.
Note: A node that does not implement the DTN protocol layer cannot accept bundles from a
node that uses DTN. In summary, all nodes need to run the DTN bundle protocol agent to
accept and forward bundles. However, a non-DTN node can communicate with the DTN node
on the IP level (network layer).

47
5.4 IBR-DTN
In the recent years, the DTN research has seen potential growth with many different implemen-
tations being developed based on DTN architecture. ION, DTN2 and IBR-DTN are currently
the most preferred implementations of DTN.
The Interplanetary Overlay Network (ION) software distribution is an implementation of DTN
architecture, a product of Jet Propulsion Laboratory by Ohio University. It is designed specif-
ically for the requirements of communication with space aircrafts.
DTN2 is the DTN implementation reference project developed under Delay Tolerant Networking
Research Group [sec. 6.3][2]. This is a direct implementation of DTN architecture, however
provides only basic features for bundle management.
IBR-DTN currently in development by Institute of Operating Systems and Computer Networks
at TU Braunschweig in Germany, is a C++ implementation of the DTN bundle protocol. It is
a portable and light weight development that can be used and extended for embedded systems.
It supports portability to different architectures such as MIPS, ARM and x86. In addition,
IBR-DTN is already used for experiments with routers at Thales Nederland B.V., and makes
it a good case to go with this implementation of DTN.
The IBR-DTN implementation of DTN is chosen for experimentation, as a proof of concept
with the aerial vehicle. IBR-DTN is used on all communicating nodes. The source is compiled
on the Raspberry Pi hardware, binaries are installed on the TP-Link router and linux based
desktop systems, for use in our research.

IBR-DTN architecture

Figure 5.4 shows the IBRDTN architecture, an implementation of DTN.

IBR-DTN is a modular approach to DTN, where users can extend the existing design and add
their own modules.

Figure 5.4: IBR-DTN architecture overview, taken from [6].

IBR-DTN is event driven architecture. The seven modules are discussed briefly only for com-
pleteness. Interested reader can get more information from [5] on this architecture.
• Event Switch: Core module of IBR-DTN. It allows modules to register themselves and
supports raising of events. Event switch enables the interaction between various modules.
• Bundle Storage: The bundles can be stored before transmission (store and forward) or
retrieved after reception from the bundle storage. The options of storage are in memory

48
 (RAM), SQL database or persistent file system.
• Connection Manager : Provides the facility to interact between the transport layer (TCP,
UDP, HTTP) and the bundle layer. This mechanism is supported by a so called, conver-
gence layer.
• Discovery Agent: The Discovery Agent implements the DTN node awareness by support-
ing various discovery plug-ins. It supports two compatible plug-ins: the IP-Discovery
frames compatible to DTN2 and DTN IP Neighbour Discovery [2, Sec 6.3].
• API Server : It provides a socket based Application Programming Interface (API) that
comes from the TCP convergence layer. This interface could be a Unix domain socket or
TCP based socket [2, Sec 6.3].
• Wall Clock : It reads the clock of the host to determine the global time. The timestamp
provided by the wall clock is used as a reference for determining when a bundle should
expire. This is done in order to synchronize time for all nodes.
• Base Router : This module is responsible for the different routing protocols implemented
as plug-ins in IBR-DTN. The base router module communicates with the discovery agent
module through events, to know when a DTN node has been discovered.

5.5 IBR-DTN mechanism

The IBR-DTN daemon

DTN daemon is the background process that is run on every DTN node. This daemon is an
implementation of the IBR-DTN architecture discussed in Section 5.4. It hosts a central bundle
management framework that enables modules to communicate with each other. Each DTN
node is configured to use an interface such as wlan0 (wireless interface), and can therefore,
actively use this interface to transmit and receive bundles.
In order to transmit and receive bundles, the IBR-DTN features mainly three important tools
for testing, the dtnsend and dtnrecv (abbreviated for dtn receive) and dtnping.

DTNSEND

The dtnsend is a tool that allows users to generate bundle from a file and send it across to the
destination. It connects to the dtn daemon using the DTN API and injects the bundle to the
DTN. This is an executable and is run at the source node. By default, dtnsend provides a set
of options defining properties of the bundle to be sent. The following are its properties:
1. filename: Specify the file to transfer.
2. destination: Set the destination node identifier (e.g. dtn://node name/filetransfer). The
filetransfer is an arbitrary name of the type of the message.
3. lifetime: Specifies how long the bundle stays in the repository before expiring, in seconds.
This is also known as the time-to-live (TTL).
4. priority: Set the bundle priority (0 = low, 1 = normal, 2 = high). In the work of Lopez,
et.al [2], introduced further levels of priority for a bundle aiming at QoS (Quality of
Service).
5. Other properties such as custody transfer, number of copies, encryption of the bundle,
destination group are also available.

49
The command below, when executed, sends a file from the source node pi1 to destination node
pi2 with address dtn://pi2. An expiry time of 600 seconds indicates that this bundle will
expire and fail to be sent, if pi2 is not discovered within this time frame. When the bundle is
successfully delivered, the source node deletes the delivered bundle from its repository.
user@pi1: $ dtnsend dtn://pi2/filetransfer <filename> −−lifetime 600

DTNRECV

On the other hand, dtnrecv must be executed at the destination node before receiving the
bundles. The tool waits until the bundle that is initiated by the sending node, is received.
On reception of the bundle, it displays the information received at the console output. It is
however, important to note, that the bundle will be received by the dtn daemon automatically,
when the two nodes discover each other. This is a tool that allows visible reception, for testing
purposes. By default, dtnrecv provides a set of options defining properties of the bundle to be
received. The properties of the expected bundle must match the properties of the bundle sent.
The following are its properties:
1. filename: Write the incoming data to a file rather than the standard console output.
2. name: The type of the bundle sent. If dtnsend is initiated with an arbitrary type of
’filetransfer’, this must specified for the reception as well.
3. timeout: How long should we wait before the bundle arrives.
4. count: The number of bundles expected to be received.
5. Group: Receive the bundle destined for a specific group that the receiver is part of (set
by source of the bundle).
The command below, when executed expects to receive a bundle with the type indicated as
filetransfer and stores the stream of bytes received into a file.
user@pi2: $ dtnrecv −−name filetransfer dtnsend −−file <filename>

DTNPING

As the name suggests, this generates the ping or short packet bursts from the source. This
works similar to the IP level ping on layer 4 of TCP/IP model, that uses Internet Control
Message Protocol between any two nodes. The dtnping works between the DTN layers of the
two DTN nodes, to know their presence.
The command below, sends a request from node pi1 to node pi2. If a reply is sent back to node
pi1, indicates that that the two DTN nodes can see each other. This is used solely for tests
between the DTN layers.
user@pi1: $ dtnping dtn://pi2/echo

Working outline

After reviewing the IBR-DTN architecture and understanding how it works, we now discuss
the outline on how it functions. Figure 5.5 shows the mechanism of the bundle transmission
and reception between two nodes.

50
 Figure 5.5: Mechanism of bundle transmission and reception between two nodes.

1. The DTN daemon, as indicated in the figure, manages tight coupling between all blocks
in the DTN architecture 5.4. This is run on all nodes, at all times.
2. The Discovery Agent discovers the neighbours of the node. The bundle initiated via
dtnsend by a node is ready for dispatch once a node is available. If a node is not available,
the bundle remains stored in the memory, file system or database, until the time-to-live of
the bundle expires or the bundle is received by the destination. If the Discovery Agent is
able to find its DTN neighbour (or an intermediate DTN node), the Base Router module
is triggered via an event.
3. The Base Router module uses the configured DTN routing protocol settings such as static
or epidemic, see Figure 5.4, to transmit the bundle. It first checks for presence of a bundle
in system storage and if present, dispatches it via the daemon.
4. At the receiving end, the dtnrecv waits for the bundle, and stores the incoming stream of
bytes (bundle) into the repository as a file or display it at the console.

51
5.6 Limitations of DTN design
With the knowledge on how the DTN architecture is implemented, exposed certain limitations
with DTN from an application point of view. The DTN architecture allows a bundle to be
received at the destination, however the bundle reception is done solely at the bundle protocol
layer. The bundle protocol layer does the bundle management, processing and dispatching
bundles to the target node. It hides all information pertaining to the properties of a bundle.
At the end user side, the layer higher than the bundle layer, is unaware of the properties of the
received bundle. It therefore, severely limits the use of DTN beyond node to node transfers.
The following lists the current design features:
1. Source of bundle: The end user receives the bundle sent, but does not know who sent it.
2. No trigger on bundle reception: The end user does not have the immediate knowledge of
reception of a bundle. A constant check is necessary to determine the presence of any
received bundles, either in the file system or memory. The dtnrecv has the limitation that
it needs to be executed before reception of a bundle. The dtnrecv writes incoming data
stream into a file or displays at the console.
3. Indeterminate file format: The end user receives the contents into a file but not know the
format of the file that is sent. Each bundle received is stored with a randomly created
file name. Any bundle received is by default, stored with an alias such as 5bd650302346-
hk3k556nn4m432mm. From the alias of the bundle, it is not possible to easily determine
if the bundle sent is a text file, a video message or a voice message.
4. Problem with clock synchronization: Before initiating a bundle transfer, the bundle layers
of all network nodes synchronize time among themselves. This is required for consistent
calculation of contact schedules and managing the bundle time-to-live throughout the
DTN [5]. If the clocks on any of the nodes are found to be out of sync (even by a few
seconds), the transaction is not initiated. This poses a severe challenge during testing. In
our case, the bundle protocol is run on embedded systems. Having the correct time for all
nodes poses a challenge. The possible solutions are a real-time clock or a gateway (access
to internet connectivity) for clock synchronization, the latter which is not always feasible
in MANETs.

5.7 Extending the DTN design

Solutions are found to overcome the shortcomings of the current IBR-DTN architecture, as
discussed. The solutions by means of extension, are discussed below:
1. Know the source of bundle:
Before a bundle is sent from the source node, the data is wrapped with trailers and head-
ers by the bundle layer. This is shown in Table 5.1, where the user data constitutes
the intended data to be sent and the others are headers and trailers. When the bun-
dle is received at the destination, it uses the user data for processing and extracts the
application-specific data for storage. However, no direct provision is offered by the bundle
layer to know where the bundle came from.

52
 Parameter Value
Source earth.sol.int, src: jpl.nasa.gov:6769
Destination mars.sol.int, dst: jpl.nasa.gov:6769
Class of service
Custody transfer, Normal priority, Time-to-live = 36 hours
(CoS)
Signature <bundle-specific signature using source’s private key>
Application-specific data, including instructions to the des-
User Data tination for processing, storage, disposal and error handling.
User data is not visible to bundle-protocol agents

Table 5.1: Displays the contents within a bundle, referred from [5].

The only way to the knowledge of source of a bundle is to understand how the bundle
management takes place at the receiving end. It is then, necessary to capture the source
of the payload (data) before the extracted data is stored into the system’s repository.
2. Trigger on bundle reception: The dtnrecv is a C++ program, when executed, waits for a
bundle to be received. When the bundle (stream of bytes) is received, the data is copied
to the local storage. This process is meant to be executed on a per transaction basis.
Once the bundle is received, the process terminates.
The dtnrecv process is redesigned to run as an independent background process, and
trigger an event whenever a bundle is received by the node. This frees us from executing
the dtnrecv process, time and again, on a per transaction basis.
Also, the source and data are extracted from the bundle, every time any bundle destined
for this node is received. This pair of information is then sent as parameters to an external
script, to handle the received source and data. Figure 5.6 shows the algorithm devised to
improve upon the dtnrecv mechanism.

Bundle processing algorithm

Algorithm 1 is based on Figure 5.6, describes the procedure to handle any number bundles
received at any time. The client (host process) connects to the local DTN daemon server
via a socket. As soon as the bundle is received by the beneficiary, an external bundle
processing is initiated. The data are processed externally using a script and stores it in
the desired location. The script can make use of the knowledge of the source, which is
lacking with dtnrecv. After the data is handled, the temporary file created is removed.
Three processes are involved in this operation. One is the DTN daemon server that is the
heart of DTN, the external script for received bundle management and the host process
that connects to the server. The host process is made to run actively, listening for bundles.

53
Algorithm 1 Received bundle processing
Require: key bundleT ype, port, group, client, bundle, payload, source, tempP ath, active, ack
Ensure: DTN daemon is running and active is set to true.
1: while active 6= false do
2: client ← createClient(bundleType, port, group)
3: ConnectToServer(client) [Wait for DTN daemon to respond]
4: bundle ← getBundle() [Get reference to the bundle received]
5: payload ← getPayload(bundle) [Extract the payload from the bundle]
6: source ← getSource(bundle) [Get the source from the bundle]
7: tempPath ← writeToTempFile(payload) [get the path of the temporary file created]
8: result ← externalScript(tempPath, source) [Process externally]
9: if result then
10: deleteFile(tempPath)
11: else
12: THROW Exception [Error processing bundle)
13: false → active

Figure 5.6: Solution of event based trigger and handling on bundle reception.

54
3. Tackling the file name, format problem: As described already, this is a concern if one
wishes to store a received bundle and forward this bundle to some other node, in future.
The bundle received by a node is stored with a randomly created file name. Further,
the format of the file is unknown. This severely limits the possibility of information
forwarding.
As per the implementation in DTN architecture, it is not possible to know the name or file
format of the data sent. This knowledge is not encrypted into the DTN bundle. A clever
way found is to get around this problem is to archive (i.e. tar) the data before sending
and on reception, this data is unarchived (i.e. untar). This offers a two-fold advantage:
• Many data (files) can be clubbed together for sending to a destination node, rather
than separate (dtnsend) transit of files.
• The name and file format is now known. Possibilities emerge, to retransmit this data
to other nodes, as required. Further, this information can be used on an application
level. The solution devised by archiving and unarchiving of data, is used in the
protocol developed for aerial data exchange, Chapter 10. No visible overhead is
found with tar, untar as the size of file remains nearly the same.
4. Solution to clock synchronization problem: Two solutions have been devised to tackle the
time-synchronisation problem. One is with the use of an external clock source with the
hardware. The other is a software solution.
(a) As per DTN design, each node’s timestamp requires to be synchronized with the
other nodes timestamp. Even a slight difference in timestamps can cause a failed
transaction. The DTN protocol is used on the Raspberry Pi hardware. Since, the
Raspberry Pi is not always connected to the internet, it is not possible to keep track
of the exact time.
In order to have a sense of time, a solution is to interface a real-time clock (RTC)
with the Raspberry Pi hardware. This enables it to keep up to the current time. An
RTC module in interfaced with the Raspberry Pi hardware. For more information,
please refer to Section C of appendix.
(b) It is tedious to have an RTC interfaced on all DTN nodes in the network. A software
solution is more preferable. Certain modifications are made to the start up script of
IBR-DTN daemon to remove the time-synchronization dependency altogether. This
enables all nodes to smoothly transit bundles without worrying about the time sense.
This solution is used hereafter, and has been found to be useful for demonstrations.
More on this is detailed in Section C of appendix.

55
Chapter 6

Network Setup on Raspberry Pi

This chapter is about setting up of ad-hoc routing, OLSR and DTN protocols on the various
nodes in the network as part of this research conducted at Thales Nederland B.V. In Section
6.1, the steps with respect to ad-hoc network setup on Linux based systems such as Raspberry
Pi, personal computer and TP-Link routers is presented. The MANET configuration using
OLSR is discussed in Section 6.2. The development and analyses of MANET nodes is presented
in Section 6.3. The ability to retrieve useful information from the OLSR routing table, by the
use of plugins is explained in Section 6.4. The essential configurations in OLSR and DTN is
tabulated in Section 6.5. In the end, Section 6.6, illustrates how the communication between
any two end-points in the network will work after a successful setup.
The idea is to first set up an ad-hoc network in the laboratory and conduct experiments.
Further, the IP routing protocol such as OLSR is tested on every node to extend the range of
the network by two hops. The DTN is then integrated to make the store and forward approach
possible. The main focus in this chapter is network setup on the Raspberry Pi. This applies
equally well to other systems such as desktop PC running a Linux distribution and TP-Link
routers that run OpenWRT operating system. Finally, the integration of one of the nodes with
the UAV is established, to make it truly a MANET node.

6.1 Node configuration

Prior to the ad-hoc mode set up, the Raspberry Pi node is installed with the Raspbian OS, a
Linux distribution based on Debian. Please refer to C for Raspbian OS installation instruc-
tions. The following are the five most essential parameters required for the ad-hoc network
setup.
1. Mode: All nodes are configured to be ad-hoc, by setting the mode property of wireless
device.
2. Network name: Nodes are configured with the same network name or Extended Service
Set Identification (ESSID). It is used to identify a group of nodes that are connected
together in the network.
3. Frequency or Channel : The nodes must operate on the same channel or frequency. Wire-
less channels are translated into a radio frequency. As per the EU standards, selection
from channel 1 to 13 is allowed in the 2.4 GHz spectrum, Figure 6.1 shows the various
channels in this range.

56
 4. Cell Identity (Cell-ID): Set the cell-identity of the ad-hoc network. The cell-identity offers
a set of unique hex-value pairs that force the network card to register the given access-
point or ad-hoc network. The Cell-ID is derived from the ESSID and channel used. E.g.
00:60:1F:0D:B2:45
5. Transmission power : The transmission power of the wireless device can be set from 0
dbm (1 mW) upto 20 dBm (100 mW), as the maximum permissible limit.
A table detailing this setup is listed in appendix, under Section C.

Figure 6.1: Figure shows the standard 13 channels, as per 802.11 standard. Each channel has
a bandwidth of 22 MHz; taken from Wikimedia commons(2.4 GHz Wi-Fi channels). The 14th
channel is only available in Japan.

Channel selection

In the laboratory, where experiments are conducted, the presence of many wireless devices such
as routers and other wireless equipment often result in interference on certain channels in the 2.4
GHz spectrum. In order to set up six nodes, all configured in ad-hoc mode, a channel selection
is required. This is an important consideration as otherwise it becomes tedious to narrow down
problems. A possible problem is with unexpected packet loss caused due to surrounding wireless
interferences.

Figure 6.2: A study of wireless devices sensed in the laboratory, using aircrack-ng, an open-
source network tool. The BSSID (MAC addressed) of the systems have been hashed.

The 2.4 GHz Wi-Fi (802.11 b/g/n) spectrum is part of the ISM band is 83.5 MHz wide (2.4
GHz - 2.4835 GHz). It is made up of 13 channels, with 11 commonly used channels. Channels
12 and 13 are normally not used to avoid any potential interference in the adjacent restricted
frequency band (2.48 - 2.5 GHz band). All channels occupy 22 MHz in the spectrum and all

57
adjacent channels are separated by 5 MHz. There is a minimum of 10 MHz overlap with the
adjacent channels, see Figure 6.1. When set to channel 6, it invariably occupies the bandwidth
of channel 5, 7 and half the bandwidth of channels 4 and 8. As a rule of thumb, it is suggested to
be atleast 25 MHz away from neighbouring networks in order to avoid overlapping frequencies.
Channels 3 and 10 were found to relatively safer while finding a suitable channel to use.
Figure 6.2 displays all the available networks sensed in the vicinity after setup. The ad-hoc
channel 10 with an arbitrary ESSID irt-ah-inria is chosen for our experiments. The Beacon
frames contain certain control information and are transmitted periodically in each of the 11
channels to announce the presence of a wireless network. A higher beacon count indicates a
minimum collision and a higher throughput.

Interface setup

Figure 6.3 displays the settings used for configuring the network interface. The settings used for
the configuration is based on the parameters discussed in Section 6.1. WLAN0 is the default
name given to the wireless interface card and settings are made for this wireless interface used on
a node. Note that the manual setting for the Cell-ID is in theory, not required. However, when
a wireless adapter is used on a node, it is on certain occasions found to change to a different
Cell-ID. One of the possible reason for this behaviour is due to the drop in power available to
run the wireless device. This forces the wireless adapter to switch to another frequency as a
counter measure, resulting in change of its ESSID. This ultimately, leads to a disconnection
from other ad-hoc nodes in the network. Forcing the Cell-ID permits to retain the frequency
and thus the connection, even in case of a power drop.

Figure 6.3: Settings used for the ad-hoc network setup.

Figure 6.4: The encircled number indicates the sub-network address. The ’X’ refers to the range
of 1-255 devices or node identifiers.

All nodes in the mesh network are configured with a static IPv4 IP address. To use a DHCP
(to dynamically assign IP addresses) is not practical. A solution would be to use IPv6 stateless
address configuration, where a unique IPv6-address can be constructed using MAC (Media

58
Access Control, has a unique number, for each wireless card). Figure 6.4 shows the ad-hoc
nodes in two unique networks on the IP. To enable the devices to communicate with each other,
we set the netmask of the node. A broadcast address is then computed by using the netmask
and IP address of the node. The broadcast is set by the wireless device, that specifies to what
all (external) networks it can reach based on the given netmask.

Figure 6.5: The wireless interface configuration (iwconfig) after set up.

Figure 6.6: The resulting interface configuration. Notice the hardware(MAC) address of the
wireless device, along with broadcast address, transmitted and received packets.

The configuration after the wireless device setup in the ad-hoc mode is shown in Figure 6.5.
Channel 10 is used on all nodes and maps onto a frequency of 2.457 GHz. Figure 6.6 shows the
interface configuration details with broadcast address.

Freeing the interface

A mention of a problem that is technical in nature is discussed here, for completeness. The
steps detailed so far is expected to result in a peer-peer ad-hoc connection between Raspberry
Pi nodes. However, it was noticed that even after several attempts it resulted in unpredictable
communication. After analysis with networking tools such as airmon-ng, indicated that some
processes use the wireless interface. Airmon-ng is a network analysis tool that amongst other
features helps indicate the processes that use the specified interface. To get ad-hoc to work
properly, it is required to terminate all the services that airmon-ng complains about. The
following observations are noted:
root@pi2: $ airmon-ng start wlan0
Figure 6.7 shows the different processes contending the use of wlan0 wireless interface. The
wpa cli, wpa supplicant are used for the infrastructure mode while ifplugd is a daemon that
automatically detects and configures interface(s) at boot time. The different processes take their
turn in using the wireless interface. The wpa processes are terminated and ifplugd configuration
is modified using the configuration file, as below:
root@pi2: $ nano /etc/default/ifplugd
In the configuration shown in Figure 6.8, the parameters INTERFACES and HOTPLUG INTERFACES
can be removed or changed to point to interfaces such as eth0. Setting it to auto, all enables

59
 Figure 6.7: Indication of different (unnecessary) processes using the wireless interface.

Figure 6.8: Modifying ifplugd daemon to prevent it from using the wireless interface.

the daemon to be configured for all interfaces including wireless wlan0 interface, which is un-
desirable.
The next section discusses the MANET setup using OLSR protocol. The ad-hoc network setup
is an essential first step in making sure that one-hop communication between nodes work.

6.2 MANET setup

As discussed in Chapter 4, we use the OLSR protocol as our MANET protocol for communi-
cation between all static ground nodes and the aerial mobile node.
OLSR routing protocol is implemented by OLSR open source group [26]. The OLSR source
code is compiled for the Raspberry Pi that hosts an ARM processor. The compiled binaries are
used on the TP-Link router, that is based on MIPS architecture running the OpenWRT OS.
The Eclipse framework is used for programming in the Linux platform, refer to Appendix C for
OLSR compilation procedure for the Raspberry Pi.
OLSR creates a routing table that lists the other IP addresses it has connection to. In MANETs,
nodes often come and go and for this reason the process of detection of nodes must be automatic.
The OLSR carries along with it a daemon that runs as a background process to do this task.
This daemon is called olsrd.

Tuning the OLSR

With the mobile node as focus, it is required that when the aerial vehicle starts to hover in a
region, it establishes a reliable connection with the ground node as early as possible. For this
reason, we must judiciously tame the OLSR protocol to meet our expectations. OLSR provides
a configuration file olsrd.conf, that consists of several parameters. The complete configuration
file is found in the Appendix C. The following parameters are of prime importance:

60
1. HELLO Interval :
OLSR sends periodic HELLO messages to locally detect neighbour changes and exchanges
topology information among all nodes in the network to discover routes. These mes-
sages are generated and transmitted to all one-hop neighbours to achieve link-sensing,
neighbour-sensing, two-hop neighbour-sensing and MPR selector sensing [4, Sec 3.6], al-
ready discussed in Chapter 4.
In [27], the impact of setting the time refresh interval of OLSR hello messages on varying
node density and node speed is studied, where simulation is conducted using NS2 network
simulator. A couple of observations in this paper [27], are as follows:
The impact of tuning the HELLO interval increases with increased node speed.
When the network is relatively stable with less mobility, tuning HELLO interval
has smaller impact than with high mobility. The average throughput decreases
almost linearly with the increase of the HELLO interval.
In our case, we deal with communication with the mobile node and consider to tune
this parameter. Also, the OLSR must start its detection as early as it nears a given
waypoint where the node is placed. As soon as it starts hovering in the given region,
the data transaction is initiated as the connection is already sensed. There is a tradeoff
between routing overhead increase and route stability improvements. This overhead can
be expected to be minimum, as the nodes in our network are small.
Inference from [27] is derived to reduce the Hello Interval by a multiple of 4, 5 or 10.
The default HELLO interval is 5 seconds. With a factor of 5x5, this interval is reduced
to 0.2 seconds. This decision is taken after testing different values for this parameter and
our understanding based on simulation results already available in literature. We take
minimum number of nodes used in the mesh network, to our advantage.
2. HELLO validity time:
This interval determines how long does a node consider a link to be valid based on the
past HELLO messages. In other words, a node connection is considered valid until this
interval expires. For a mobile node, we reduce this time interval by the same factor of
5x5, to arrive at 1.6 seconds from the default 40 seconds (originally meant for static or
semi-mobile nodes).
3. There are many other parameters that OLSR uses, that are listed at the end of this
chapter, in Section 6.5. The same setup is maintained on all nodes for a predictable
neighbour discovery.

61
 (a) HELLO interval of 1.0 second (b) HELLO interval of 0.2 seconds

Figure 6.9: Tests performed between two static Raspberry Pi nodes. Effect of HELLO interval
tuning on neighbour discovery times, (a) establishes a reliable link with neighbour node in 29
seconds, (b) establishes a reliable link with neighbour node in 8 seconds.

Shown in Figure 6.9 is the effect HELLO interval has on reliable discovery characteristics of
one node as seen from the other. The two static nodes are placed 10 meters apart, both with
a transmission power of 20dBm (100 mW). A reliable discovery is when the link quality, based
on Expected Transmission Count (ETX) metric is close to 1.0 and below 2.0. The ETX value
of 1.0 means a perfect link without any packet loss. ETX is discussed in the next section.
In Figure 6.9a, both nodes are configured with the same HELLO interval of 1.0 second which
results in achieving a reliable link quality in approximately 29 seconds. In Figure 6.9b, both
nodes are configured with the HELLO interval of 0.2 seconds, results in a faster convergence to
a reliable link quality in approximately 8 seconds. It is to be noted that the HELLO validity
time is reduced by the same factor as HELLO interval for both nodes.
The results show that the reduction in HELLO interval and validity times can help estimate
faster, the link quality with the neighbour nodes. We limit our case of HELLO interval times to
0.2 seconds after validating the applicability of [27] and performing tests on HELLO intervals.
Lowering this time would result in a higher contention in the network in the presence of more
nodes. Also, in practice, the effective ping times between nodes can exceed 100 milliseconds,
resulting in a higher rate of packet loss. In the case of the mobile node, a faster estimation of
reliable link is preferable. Further, this will directly reduce the hovering time required during
the data exchange.

6.3 Mesh network

Figure 6.10 shows a network setup in our laboratory, with six nodes. Notice how a chain of
links tie all of the sparsely connected nodes together.
The setup includes the following:
1. Nodes with IP’s 192.168.10.51, 52 and 53 are Raspberry Pi networking nodes.
2. IP 192.168.20.220 is associated with a PC (Personal Computer.

62
Figure 6.10: The network outlay consisting of six nodes, three of them are Raspberry Pi’s, two
are TP-Link routers and one is a PC.

3. IP 192.168.13.207 and 192.168.11.207 are OpenWRT running on TP-Link wireless routers.

It can be noticed that all nodes have directly or indirectly the knowledge of the farthest node.
For example, node with IP ending .53 is connected to .220 and .52 via two hops. Note that the
direct link (1-hop neighbours) between .53 and .207 shows Infinite. This is an indication that
the link connecting the two nodes is very weak. In such a case, OLSR may choose another link
say, via .51 to reach .207, or whichever link’s expected retransmission count(ETX) is lower to
reach the target node. Refer to table in Figure 6.11.

Figure 6.11: Overview of currently available OLSR connections as seen by the TP-Link router.
The current node’s static IP considered is 192.168.13.207. Note that there is a slight ambiguity
in values with respect to Figure 6.10. The link costs are refreshed continuously.

The LQ, NLQ and ETX parameters together determine how good the link to the neighbour
node is. A source node determines these parameters by exchanging periodic HELLO messages
between each other, and studies packet loss by doing so.
• Link Quality(LQ):
This is the quality of the link as determined by the source node. This represents the
probability that a packet our neighbour sends reaches us.

63
 • Neighbor Link Quality(NLQ):
This is the quality of the link as determined by the next-hop node. This represents the
probability that a packet that the source node sends reaches the neighbour. In other
words, this is the neighbour’s view of the link quality. The value of LQ and NLQ is
between 0 and 1. A value of 1 indicates a noise free channel.
• Expected Transmission count metric (ETX):
The ETX of a link is defined as the predicted number of transmissions and retransmissions
required to send a packet over a link. The ETX of any given route is the sum of ETX of
individual links in the route. For example, the ETX of a four-hop route with perfect link
is four; the ETX of a one-hope route with 25% delivery ratio is 4. The table in Figure
6.11 shows clearly, the weakness of link between .53 and .207.
ETX is also referred to as forward and reverse delivery ratios of the link, i.e. LQ and
NLQ parameters. The sender will retransmit a packet not acknowledged in time. Every
attempt to transmit a packet can be considered a Bernoulli trial, thus the expected number
transmission is computed using the LQ and NLQ parameters, as:
1
ET X = (6.1)
(LQ)x(N LQ)
The ETX parameter varies between 1.0 and ∞. An ETX metric having an ∞ value,
indicates that either the link is bad, or the node just got disconnected. How fast, this is
updated depends mainly on the HELLO interval settings.

6.4 OLSR plugins

Plugins provide an extension to OLSR to query its internal database and gain some valuable
information from a higher layer of network abstraction. A handful number of OLSR plugins
exist such as Txtinfo, JSONinfo, NL80211 LQ plugins [26]. In order to derive the information
on the discovered neighbours and the link quality measurements based on ETX metric, the
Txtinfo plugin is used.

Txtinfo plugin

To enable the Txtinfo plugin, the following command is appended to the standard OLSR con-
figuration file.
LoadPlugin ”olsrd txtinfo.so.0.1”
{
PlParam ”port” ”2008”
PlParam ”accept” ”127.0.0.1”
}
This indicates that the port 2008 can be queried over the localhost. There are several commands
that can be queried to this port and reply received from this port may be filtered out as
desired.
For example, the following command, ”/link” can be sent to the port 2008 by opening a local
socket programmatically. The OLSR will return the current routing status as shown in Figure
6.12 in the form of a table. The figure displays the link cost obtained for each of the discovered
nodes, also referred to as the ETX metric. This cost depends primarily on two factors, one being
the interference in the channel and the other being the distance. A shorter distance between

64
two nodes would in most case, lead to lower cost. This cost will be used on our mobile node to
determine the connection quality. This real-time knowledge of the connection quality thus, is
used to make appropriate altitude adjustments autonomously, during the data exchange.

Figure 6.12: The response received back from the local port immediately after the query. The
figure shows three nodes discovered by the local node, each having a different cost.

For other possible commands using Txtinfo or other plugins, refer to the plugins section in
[26].

65
6.5 OLSR and IBR-DTN configuration settings
OLSR configuration changes

Table 6.1 lists the summary of the settings used in OLSR configuration file, olsrd.conf in PC
based and Raspberry Pi environments, refer to the Appendix C for complete settings file.

Parameter Value Notes

Interface ”wlan0” The chosen wireless interface (please verify your
interface name via ifconfig)
Ip4Broadcast 192.168.255.255 Broadcast IP for OLSR discovery
HelloInterval 0.2 Sets the interval of HELLO messages transmit-
ted on this interface, in seconds
HelloValidityTime 1.6 Validity of HELLO messages generated, in sec-
onds, on this interface. Set this to atleast
3*HELLO interval
TcInterval 2.0 Sets the interval of TC messages, in seconds
TcValidityTime 256.0 Sets the validity time announced in TC mes-
sages, in seconds, generated on this interface.
Set this to atleast 3*TcInterval
IpVersion 4 Olsrd supports both IP version 4 and 6
Hna4 enabled Hosts in the OLSR routed network may an-
nounce connectivity to external networks via
HNA messages. Enable this option block for
IPv4 networks
Willingness 7 Allows a node to act as relays of OLSR traffic.
Can be set between 0-7
LinkQualityLevel 2 Computes link quality information based on in-
formation from other available nodes. Can be
set between 0-2. Set to 2 to distribute all link
quality information, for all nodes
Pollrate 0.05 Sets the interval, in seconds, when olsrd event
scheduler should be poll for updates. Default is
0.1
TcRedundancy 2 Specifies on how much neighbour information
should be sent in TC messages, can be set be-
tween 0-2.
Txtinfo plugin - Refer to OLSR plugins, Section 6.4

Table 6.1: The final OLSR configuration settings used for OLSR routing, OLSR v0.6.6 .

IBR-DTN configuration changes

There are two important files that have been modified. The first one is the IBR-DTN configu-
ration file (ibrdtnd.conf ) that lists all settings pertaining to running the daemon. The changed
settings relevant to our study is given in Table 6.2.
The other file is a script that initiates the daemon process (ibrdtnd ). Certain arguments can
be appended to the daemon script to run the daemon with.

66
 Parameter Value Notes
local uri dtn://node.dtn The node is replaced by local dtn address. e.g.
dtn://pi2.dtn. Leave it at its default
logfile /home/pi/ibrdtn/ The path of the log file. This can be changed by
ibrdtn.log the user
limit blocksize 1.0G Limit the block size of all bundles. By default,
1.3 G (Gigabyte) is used
limit foreign 500M Manage the space allotted for foreign bundles,
blocksize when the current node acts only as an intermedi-
ate node. Kept at its default 500M (Megabyte)
api port 4550 The port the daemon uses to bind on. Make sure
it does not clash with other local application
ports
fragmentation yes Yes, to enable bundle fragmentation
limit payload 2M The bundle size when bundle fragmentation is
enabled. Default is 500K (Kilobyte)
storage path /home/pi/ibrdtn/ The storage path of bundles in transit
bundles
limit storage 500M Total space allotted for bundles. Change it ac-
cording to your local memory constraints
net interfaces wlan0 The interface to be used by DTN protocol layer
routing epidemic The various routing options are: default (static
neighbour routing), epidemic and prophet, refer
to Chapter chp:dtn on DTN
routing forwarding yes Forward the bundles to other nodes
dht enabled yes Default is set to No. Enable the DHT (Dis-
tributed Hash Table), a lookup table access for
knowledge of other DTN nodes.

Table 6.2: The final DTN configuration settings used for bundle protocol, IBR-DTN v0.10.0.

Parameter Value Notes

DAEMON ARGS –badclock Append the badclock parameter in the daemon
script, if it is required to completely avoid the
time synchronization for bundles
DAEMON ARGS -i wlan0 Append the interface name to the daemon
script, if it is required to override the
ibrdtnd.conf interface settings

Table 6.3: The final DTN daemon script settings used with IBR-DTN v0.10.0.

The reader can reproduce this work by following the step by step setup instructions for installa-
tion in the Appendix C. The various configuration files for ad-hoc network configuration, OLSR
and DTN configurations are also included in the appendix.

67
6.6 Communication between layers
By following all the steps given so far and in Appendix C, the reader should be able to success-
fully set up the OLSR and DTN protocols. One can now interact between the respective layers.
Figure 6.13 shows the communication between two Raspberry Pi nodes. Each node has two
primary addresses, a static IP address and an address for the DTN node. The OLSR protocol
helps extend the node discovery by multiple hops.

Figure 6.13: Illustration of communication between two nodes using OLSR and DTN, on the
extended TCP/IP protocol stack.

68
Chapter 7

Multicopter Hardware

This chapter introduces the reader to the components necessary for the operation of a (medium-
sized) quadcopter, subset of the multicopter, also referred to as multirotor. The necessary
hardware components with respect to flight operation and networking along with the design
decisions are discussed. It should however be noted, that all of the component types described
herein can be used to build a hexacopter, octocopter or any custom designed multicopter; the
modifications being in software and addition of actuator related components.

Figure 7.1: Schematic overview of the hardware

69
7.1 System architecture
Figure 7.1 shows the architecture of the entire system. The various hardware blocks are colored
differently to enable the user to identify the component categories clearly.

7.2 Sensors
The various sensors used on board the quadcopter are discussed. The level of autonomy required
by the aircraft dictates what sensors are in use.

Accelerometer

An accelerometer is an electromechanical device that measures acceleration forces. It senses

the resulting total acceleration composed of static (gravity) and dynamic (sudden start/ stop)
accelerations. By measuring the amount of static acceleration due to gravity, we can measure
the angle the device is tilted with respect to the earth. By sensing the dynamic acceleration, it
is possible to analyse the way the device is moving. Its unit of measurement is either in m/s2
or in G-force(g). 1g equals the earth’s gravity at sea level.
In order to measure acceleration of a stationary platform in all directions, a 3-axis accelerometer
is used. However, things start to get much more complicated when the platform starts moving.
When accelerating in a particular direction, this acceleration is added to whatever acceleration
is provided by earth’s gravitation pull, making it tedious to distinguish the two. In addition,
accelerometers are limited in their accuracy due to factors like vibration of the aircraft frame.
So, accelerometers cannot be used alone to help keep an aircraft correctly oriented.

Gyroscope

The gyroscope measures the rate of rotation around a particular axis. The purpose of gyroscope
is the same as that of an accelerometer, that is to provide an attitude estimate for the device.
If gyro is used to measure the rate of rotation around the roll axis of an aircraft, it will register
a non-zero value until the aircraft stabilizes about this axis, when it would read a zero. To get
an estimate of the orientation about an axis, we integrate the roll rate or roll angular velocity
over time. However, gyros are prone to a known phenomena called gyro drift. The integration
of discrete time samples results in accumulation of error over time and change in offset occurs
with temperature differences. This leads to a slow drift of the measured orientation for an
axis of the aircraft. Therefore, gyros alone cannot be used to keep an aircraft in a particular
orientation.

Figure 7.2: MPU6000 integrates accelerometer and gyroscope on a single chip, Source

A MEMS three-axis accelerometer and three-axis gyroscope are integrated on the same In-
vensense MPU-6000 chip, Figure 7.2. The values from this chip are read using the SPI1 interface,
1
The SPI or Serial Peripheral Interface bus is a synchronous serial data link that operates in master/slave
mode where the master device initiates the data frame

70
by the flight controller.

Magnetometer

By utilizing an accelerometer and gyroscope, a relative orientation can be measured for a

quadcopter. It would however be of advantage to have some type of absolute reference, that
both accelerometer and gyroscope do not provide.

Figure 7.3: Figure shows a the 3-axis HMC5883L magnetometer

A magnetometer measures the geomagnetic field, providing an absolute reference for rotation
of the aircraft with respect to the earth’s magnetic poles. The HMC5883L, a triaxial digital
magnetometer is used by the flight controller over an I2C interface, to provide this reference for
the mobile platform.

Barometer

A barometric pressure sensor or a baro sensor enables to monitor the changes in atmospheric
pressure. The air pressure increases or decreases steadily due to changing altitude and allows
the sensor to have a measurable relationship with altitude.
The MS5611 pressure sensor measures changes in air pressure and temperature. The tempera-
ture compensation is used along with measured air pressure to compute changes in height. The
baro sensor is embedded onto the flight controller board itself. The controller reads the data
from this sensor using the SPI interface.

Sonar

The sonar sensor, similar to the pressure sensor is used to indicate the relative distance from a
source or obstacle. A sonic pulse is emitted from the sensor and waits to receive an echo back
as it bounces from the object it has hit. By measuring the time it takes for the pulse to be
returned, the distance to the object can be computed.

Figure 7.4: Figure shows the XL-Max Sonar sensor, MB 1200, used with the quadcopter

The XL-Maxsonar-EZ0 sensor is used below the platform of the quadcopter to measure the
height of the platform and to stabilize itself about this stable height using feedback loop in
software. The sonar sensor is susceptible to interference with nearby noise sources. One of the
reasons for selection of this sensor is its inbuilt real-time noise rejection algorithm that results

71
in virtually noise free distance readings, as per its datasheet[28]. Its accuracy ranges from a
minimum of 20cm to about 700cm. Beyond, 7 meters of height, we rely more on the air pressure
as the sonar sensor becomes less accurate for height measurements.
One of the drawbacks of using ultrasonic sensors is that the pulse emitted by this sensor is a
wide beam cone shaped signal. Due to the shape of this pulse, an echo is returned by all objects
the pulse comes in contact with. This is a reason why the pressure sensor along with sonar
sensor is used for height measurements for reliability. In addition, a GPS receiver as discussed
below, would enable a higher precision to height measurements.

Global positioning system (GPS)

The three sensors, the accelerometer, gyroscope and compass helps identify the orientation of
the body about its center of rotation (i.e. the relative orientation of the aircraft’s body (θ, φ
,ψ) with respect to its inertial frame of reference and does not have a knowledge of the global
coordinates(x, y, z) that determine the position in 3D; refer to chapter 8. These sensors can
hold the copter’s position well in a relatively windless environment (without external applied
forces). However, with an external force would make the quadcopter move away from its current
position (x,y,z ) and stabilize itself again about the target attitude. The air pressure and sonar
sensors are used to estimate the altitude or height of the platform (i.e. the z coordinate). In
order to get an idea of (x and y) coordinates, either an optical flow camera (that maps the
pixels on the surface below the aircraft to measure any deviation due to movement) or a GPS
to determine the latitude and longitude (i.e. x and y coordinate positions).

Figure 7.5: Figure showing multiple satellites that revolve around the earth’s orbit at all times

GPS, or global positioning system, is a satellite-based navigation system consisting of 24 satel-

lites placed into the earth’s orbit. Each satellite circles the earth in a very precise orbit twice
a day, at a distance of 12,000 miles, Figure 7.5. The signals from these satellites are emitted
via radio signals, and transmit signal information such as their current location and the exact
time to a precision of a billionth of a second.
The GPS receivers on ground, receive the information from various visible satellites and use
the well known triangulation or trilateration method to compute the user’s exact location[29].
This method determines the relative position of objects by using the geometry of triangles; the
receiver measures distance using time travel of radio signals. The accuracy of position estimation
depends on the number of satellites that a GPS receiver is able to see. A GPS receiver must lock
onto the signal of atleast three satellites to compute a 2D position (i.e. latitude and longitude),
while with greater number of visible satellites, the receiver can compute the user’s 3D position

72
(i.e. latitude, longitude and altitude or x, y, z coordinates). With the current user’s position,
the receiver is also able to calculate other information, such as ground speed, altitude, hdop
(the horizontal dilution of precision in cm), etc. We use a sub-meter GPS precision LEA-6H
chipset from uBlox as our GPS receiver for the quadcopter.

7.3 Flight controller

Figure 7.6 shows an overview of the main components on the ArduPilot flight controller. The
key features with the controller we use for the quadcopter are listed below.

Figure 7.6: ArduPilot, hardware v2.6, Taken from [7]

• Uses the Invensense 6DoF MPU-6000 with MEMS acceleromter and gyros; described in
section A. The same board hosts a barometric pressure sensor.
• Availability of dedicated pins for interfacing external magnetometer and sensors such as
sonar and a GPS module of our choice.
• A Telemetry port to send wireless commands to the ground station.
• On-board 16 MB dataflash to log flight data. Custom data can be logged by writing to
the dataflash’s EEPROM.
• External IO pins for interfacing with external hardware. In this project, we interface a
Raspberry PI using UART2
2
UART: Universal Asynchronous Receiver and Transmitter. This is a standard interface to communicate
between a serial device and a microcontroller.

73
 • Input and output pins for interfacing the RC receiver’s PWM (Pulse Width Modulation)
output3 to feed output of microcontroller to the (four) Electronic Speed Controllers(ESC),
respectively.

7.4 Electronics and actuators

The selection of the required components for the electronics and actuators is based solely on the
user’s requirements. Our requirement is to get a hovering time of about 15-20 minutes; going
beyond this margin involves further research and increased costs. The design should afford
addition of extra payload and sustain the flight time. The flight time is affected by the choice
of motors, battery and the propeller used. The state-of-the-art quadcopters fly an estimated
7-20 minutes.

Brushless motors

A quadcopter has four motors, each with a propeller attached to it. In almost all multicopter
designs, a brushless outrunner motor is used to drive the propellers. A reason to use this motor
as compared to a normal DC motor is that they provide higher speeds and use less power to
provide for the same speed. The brushless motors are more efficient (≈ 80%) and dissipate
less heat as compared to DC motors that contain brush-transitions that result in a loss of
efficiency.

Figure 7.7: Inside the brushless outrunner motor, AC2830-358 850Kv

The name outrunner comes from the fact that the outside of the motor turns, contrary to the
inner part of the motor. The outer part as seen from Figure 7.7 contains a series of magnets
that provide the magnetic force to interact with the electromagnets on the stator, the inside
part of the motor. The motors are activated using three wires that provide current to these
electromagnets. These motors are also called multi-phase AC motors. The ESCs, discussed
next, provide the required AC power to activate these motors.
For the given AUW (All Up Weight) of 1.6 kgs, each motor would require at least 400g of thrust
for take-off. To hover or fly at a suitable height, it can be expected to have a slightly greater
thrust than 400g. As a general rule of thumb, the total thrust-to-weight ratio should be atleast
2 : 1, not adhering to which adversely affects the flight capability.
Brushless motors come in many different varieties, where their size, current consumption and
number of coil windings differ. The most important parameter in selection of a motor is Kv. It
refers to the maximum revolutions per minute (RPM) the motor provides per volt. An 850Kv
motor at 11V, for example, would provide 9350 RPM. For the requirements in this project,
3
PWM: Pulse Width Modulation (PWM) is a technique to represent an analog signal in the digital domain.
For the digital signal, the duty cycle of the wave varies in accordance to the analog signal’s amplitude.

74
we choose the AC2830-358 850Kv motor with 10”x4.7 propeller4 . Table 7.1 shows the thrust
generated versus power consumed for a AC2830-358 850Kv motor. The specifications take into
account usage of a 10” propeller and a 3S LIPO power source. The weight of the motor is
62g.

25% 50% 70% 100%

Amp 1A 3.4A 9A 12.2A
Wattage 11W 38W 100W 135W
Thrust 170g 433g 855g 1095g

Table 7.1: The table lists the ampere draw, power consumed and thrust(in grams) obtained at
different levels of activation. The specification differs slightly with different manufacturers.

It is found during analysis in this thesis that there is the non-linear relation between thrust and
power consumed above the take-off point until hover. Please refer to Chapter 9.

Electronic speed controller (ESC)

The brushless motors used are true 3-phase AC motors. An ESC converts the DC power
from the battery to AC power to the motors. They vary the amount of power by taking the
(pwm) signal from the microcontroller. An ESC internally, is a trapezoidal wave generator
that produces three separate waves (one that goes to each wire of the motor). It controls the
speed (RPM) of the 3-phase AC motor by changing the frequency of the waves. The higher the
frequency, the faster the props on the motors would turn.

Figure 7.8: Figure shows a 20 Amp, Electronic speed control or ESC that provides varying high
frequency AC voltage to the brushless motor

In Figure 7.8 notice the three (blue) wires that connect to the three wires of the brushless motor,
as in Figure 7.7. The other side of the ESC receives the voltage (+/-) on red/black wires. Most
modern ESCs incorporate a battery eliminator circuit (or BEC) to provide constant voltage for
the on board electronics and RC receiver, removing the need for an extra battery for powering
the receiver. The 3-wire servo lead as seen in this figure, receives varying pwm pulse from the
microcontroller(white wire) and outputs a 5V signal to power the receiver (red/black wires).
It is important to note that all on board electronics work at either 3.3V or 5V. The battery
source for the quadcopter provides us with a much higher voltage that requires to be stepped
down.
4
For a propeller (10x4.7): The first number indicates the blade length in inches and the latter indicates how
far the propeller travels with each rotation.

75
ESCs come in different shapes and sizes and are categorized on how many amperes it can
support. In Table 7.1 we discussed about the amperes drawn for the 850Kv motor and prop
combination. 12.2A is found to be the maximum power consumed by this motor at full throttle.
In order to keep a safe margin, a 20A ESC is suitable to keep it within limits of maximum
current draw and to let it run cooler. Also, the specifications from the manufactures are based
on work-bench results and may not truly depict the situation when the motors are moving in
the air.
As the last step towards selection, it is convenient for the ESCs to be programmable. The ESC
comes with different firmwares, each having a different performance on the motor control. Simon
K firmware is chosen for these four ESCs being optimized for the use of multicopters. Most
ESCs receive information from microcontroller at 400Hz, with the maximum frequency being
500Hz (i.e. maximum of 2 ms PWM pulse width from microcontroller). SimonK’s firmware
increases the rate at which the ESC sends the speed changes directly to the motor and removes
the averaging function common to most regular ESCs; results in smoother motor accelerations
and makes a difference in stability. An AVR programmer can be used to upload this firmware
and make suitable modification via its flash tool. More information can be found in [30].

7.5 Power supply

The Lithium Polymer or LIPO batteries power RC models and plays an important part in the
design. The LIPO batteries are chosen over other energy sources such as NiCd, NiMH or Li-Ion
as they have the potential to deliver high discharge current at higher voltages, in other words
deliver the high power required for the flying vehicles. From experience, the power required
for hovering varies between 150 W for smaller aerial vehicles weighing approx. 1 kilogram, to
about 1500 W for 7 kilogram vehicles.

Figure 7.9: A LIPO battery that delivers 1000mAh current at 30C, 11.1V. This figure is only
used only for illustration purposes. A Zippy 5000mAh, 20C at 11V is used for the quadcopter.

There are several numbers that classify the LIPO battery:

1. mAh rating: Determines how much power can be stored in a battery in relation to time.
A 1000mAh battery can deliver a constant 1 Ampere of current for an hour.
2. C rating: The C rating is a measure of the maximum continuous current a battery can
safely deliver. A 30C rating specifies, 30x1000mAh, or 30A of continuous current can
be drawn at a time. Drawing current at 30A, however would drain the battery faster.
For our design, the maximum current each of the four ESCs can handle is 20A. A low
C-rated battery would supply low currents, thus not able to support a high kV brushless
motor, making the motors less responsive to speed changes. On the other hand, a very
high C-rating may indicate a heavier battery and inadvertently affect the flight time.
3. Number of Cells: The number of cells in the battery determine the voltage of the
battery. Each cell measures a base voltage of 3.3V/cell and fully charged voltage of
4.2V/cell. A 3S (3 series cell) battery has a base voltage of 9.9V, nominal voltage of 11.1
V and fully charged voltage of 12.6V. A 3S-3P battery indicates 3 cells in series and 3 cells

76
 in parallel leading to 11.1 V nominal voltage with thrice the amount of current capacity.
A 1S and 2S batteries provide low power and are commonly used for powering receivers
and for micro vehicles. 3S batteries are the standard batteries used for quadcopters while
a 4S batteries are used for speed planes.

LIPO selection criteria

LIPO batteries are high energy density batteries and can be dangerous if not treated properly.
As a first step it is necessary to go with known brands such as Turnigy and Zippy amongst
others. Based on the parameters for LIPO batteries described, they come in different shapes,
sizes and combinations. The LIPO battery is usually the heaviest part of the aerial vehicle and
its selection would directly affect the flight time. As a basic rule, the power P (measured in
Watts (W)) required to develop thrust (i.e. lifting capacity) T, expressed in Newton (N) is
given by:

√
P ∝ T3
∼

An interesting paper on this subject is found in [8] that depicts the non-linear effect of weight
on flight times, also see Figure7.10.

Figure 7.10: Non-linear effect of increase in weight against flight time, taken from [8].

The selection procedure is given below:

• Current to drive motors: Current/ESC x 4 = 20A x 4 = 80A
• Number of cells: We select the 3S LIPO battery. A 4S battery is also a possible, though
a 3S is found to perform better on a medium sized quadcopter, for the given motor and
propeller combination.
• Select the battery (manufacturer) that provides a higher power for a given weight.
With each of the four ESCs drawing 20A current, the maximum current draw is 80A. A 3S
5000mAh, 20C LIPO, would be able to deliver 5Ah x 20C = 100C of current that suits our
requirement. With the idea of keeping the weight to the minimum and getting maximum power,
a 5000mAh LIPO is found to be better in comparison to 2200 mAh, 3600mAh, 6000mAh in
the same category. A Zippy LIPO 3S, 5000mAh, 11.1V battery is 470g and is found to be 25g
lighter than its Turnigy counterpart.

77
Power module

The power module provides an easy way of supplying a clean power to the flight controller from
a LIPO battery along with the current consumption and battery voltage measurements all via
a 6-wire cable. It includes an on-board switching regulator that outputs 5.3V and a maximum
of 2.25A, Figure 7.11. The thick red/black of the power module outputs 11.1V and connects to
the power distribution unit that supplies the power to ESCs.

Figure 7.11: Power module provides a clean power supply to on-board electronics and for voltage,
current measurements

Power distribution

The power distribution, as the name suggests supplies power to all ESCs. It systematically
organizes the various wires through a one power distributor PCB. Figure 7.12 shows the power
distribution unit that is placed in the center of the quadcopter to power the four separate
ESCs.

(a) Power distribution board(PDB) soldered (b) The PDB at the center of quad-
with deans connectors copter

Figure 7.12: Power distribution board to distribute power to the four ESCs, flight controller and
Networking hardware

7.6 Communication equipment

Telemetry radio

We use a pair of wireless devices operating at 433MHz (EU standards) to set up a wireless
link between the quadcopter and the ground station. Real time flight data is displayed on the
ground station and flight commands can be sent to the flight control in real time. It uses a

78
protocol called Micro Aerial Vehicle Link(or MAVLink) to transmit or receive data between
the two. Figure 7.13 shows the ground module along with the air module. An FTDI to
USB cable is usually used to connect the different modules to the flight controller and laptop,
respectively.
Note: The telemetry modules may have to be configured for use with the given power, air
data rate, etc. This can be done using the GUI provided by manufacturer, for configuring the
telemetry via FTDI.

Figure 7.13: Two radio modules with antennas.

Radio transmitter and receiver

A radio controlled(RC) transmitter is used for manual control of the flight usually when being
within the line of sight(LOS). We use a 9-channel user RC transmitter and an 8-channel RC
receiver on flight.
Each channel of the transmitter is assigned different functions. An example is presented be-
low:
• Channel 1,2,3,4: Pitch, roll, yaw, throttle
• Channel 5: This is a 3-position switch. It is set to work in Manual control, Hover and
Autonomous mission modes. The action is taken on the flick of the switch.
• Channel 6: This is a potentiometer knob. In flight PID tuning of parameters can be
achieved such as tuning the Proportional value for the roll axis. This is discussed further
in chapter 9.
• Channel 7,8: Not currently used.
The RC transmitter uses a transmitter module on its back that combines each of the 9 PWM5
channels (≈2ms each) into a PPM signal on the transmitter (≈20ms) and modulates it to 2.4GHz
frequency before transmission. The receiver demodulates the signal and feeds the decoded PPM
signal directly to the flight controller. The flight controller reverse engineers the PPM signal
into various PWM channels for its use. Figure 7.14 shows the a)FlySky FS-TH9X Transmitter
with 2.4GHz DJT Module b) FrSky D4R-II Receiver.
The RC transmitter usually comes already flashed with the latest ER9X firmware for use with
multitrotors.
5
PWM stands for Pulse Width Modulation and PPM stands for Pulse Position Modulation. PPM is combi-
nation of several PWM signals lined up back to back.

79
 (a) FlySky FS-TH9X Transmitter with
2.4GHz DJT Module (b) FrSky D4R-II Receiver

Figure 7.14: The hand held transmitter sends control signals to the receiver on flight.

Wireless LAN (WLAN)

Wi-Fi is an accessory allowing computers, phones, routers or other devices to connect to the
internet or communicate with one another wirelessly in a particular area. Wi-Fi is a wireless
local area network (WLAN) product based on IEEE 802.11 standards. A Wi-Fi hardware is also
called wireless adaptor. We test three different Wi-Fi wireless adaptors for use in our research
namely, Wi-Pi 802.11n wireless adapter, Edimax ew-7811un and TP-Link WN722N.
Wireless adaptors are used for bi-directional communication of data with other nodes in the
mesh network. Figure 7.15 shows the TP-Link wireless adaptor that is used in our project.

Figure 7.15: Figure shows the TP-Link wireless dongle based on 802.11g/n standards.

7.7 Frame specifications

The frame of the quadcopter is the structure that holds all the components together. The
frame should be rigid, able to survive crashes and to minimize the vibration coming from the
motors.
A medium-sized quadcopter is built with off-the-shelf hollow aluminium frames. Aluminium
frames are chosen with the objective of outdoor navigation. An aluminium frame provides
greater resistance to crash compared to a carbon fiber frame. The hollow aluminium arms
weigh approx. 360g.
With respect to the arm length, the term motor to motor(M2M) distance is often used. It

80
 Figure 7.16: Figure shows the quadcopter constructed with aluminium frame.

indicates the distance between the center of one motor to that of another motor of the same
arm, Figure 7.16. The M2M distance usually depends on the diameter of the propellers used.
There should be sufficient space between the propellers so as to avoid hitting each other. For
the given design, 56 cms was found to be sufficient as per the manufacturers frame design.

7.8 Networking hardware

In the previous chapter 3, the different hardware that support networking were studied. The
Raspberry Pi processor is found to be the preferrable choice.

Figure 7.17: Figure shows the Raspberry Pi processor interfaced TP-Link WN722N wireless
adaptor and a 5 Mega Pixel HD camera.

Figure 7.17 shows TP-Link wireless adaptor connected to Raspberry pi. An 8GB SD card is
used with the raspberry pi that runs the Raspbian operating system and also used for storage of
data. Also notice in the figure, the (video) camera shown is interfaced with Raspberry pi.
Raspberry pi is used as one of the nodes in the network of nodes (i.e., mesh network). All nodes
are configured in ad-hoc mode. One of the nodes is a mobile node (i.e. quadcopter) with other
nodes being (static) routers. The TP-Link based wireless adaptor is found to have a better
performance with the mobile node in terms of its wireless range and optimized device driver
support for ad-hoc mode. We later used the same wireless adaptor on all nodes, for consistency
of results. Raspberry Pi is interfaced with the flight controller via its GPIO pins.

7.9 List of components

The list of components purchased is presented in Table 7.2.
Note: This table lists the base components required for construction of a quadcopter. Please

81
note that the spare components in various categories, wires, and connectors were bought and
delivery charges are not included. Total estimate is ≈ 1150 e6
Table 7.2 is a reference list for the final components that are used. All the three quadrotors in
this project use similar parts but from different manufacturers. The software on all quadrotors
adhere to the same platform for consistent results. Only one quadrotor at Thales, is used for
demonstration purposes.

6
Price at the time of writing, August 2013

82
 Description Qty Price( e)∗ Notes
ArduPilotMega(APM) Flight controller board consists of
1 107
v2.6 MPU6000 sensor, pressure sensor
3DR ublox GPS with uBlox LEA-6H GPS module with an
1 55
Magnetometer external magnetometer
3DR Radio 433Mhz
1 62 Used for communication with GCS
”Air” module (EU)
Sonar sensor
1 30 XL-MaxSonar-EZ0, long range (≈7m)
(MB1200)
3DR Quad arms
4 10 Aluminium arms provide durability
(black, blue)
Power Distribution Distributes current to speed controllers
1 12
board (PDB) (oe ESCs) from energy source
Conects directly to battery and supplies a
APM Power Module
1 11 clean 5 volt power supply to flight
(for 5V supply)
controller
ESC is used with SimonK firmware.
20 Amp ESCs 4 13
Converts DC to AC signal.
Brushless Outrunner
Receives varying voltage from ESCs to
Motor (AC2830-358, 4 16
turn the rotors
850Kv)
APC Propeller set,
4 6 Standard propellers for 850kV motors
10X47 SFP Style
RSSI (PWM) and CPPM output. FrSky
FrSky D4R-II
1 16 RC receiver is compatible with many
Receiver
other transmitters models.
FlySky FS-TH9X The transmitter operates in 9 different
Transmitter, RF 1 85 channels. A FrSky DJT module is used as
module the RF module at 2.4 GHz
Turnigy Accucel 6 Upto 6 Cell balancer and charger for
1 25
charger LIPO, Pb, NiCd batteries
LIPO batteries 2 22 5000mAh batteries, 11.1 V(≈490g)
Networking Includes Raspberry Pi, SD card, HDMI
1 120
Accessories cable and other relevant components

Table 7.2: List of components for quadcopter and networking accessories. Base cost of ≈ 747 e.

83
Chapter 8

Multicopter Software

In order to control the movements of the multicopter, it must be able to follow a reference
position signal. The reference signal is generated by a higher level of control, that can either
be the directed through the input of the RC transmitter or from a control algorithm that uses
GPS or visual aid to provide this reference.
This chapter describes the software to handle the task of following the reference signal, also
referred to as local control. First, a simple mathematical model of the quadcopter is presented.
This is followed by an overview of the functional blocks that describe autonomous tracking of
a target and waypoint navigation using GPS. The same software can be used for quadcopter,
hexacopters and other designs, with slight modifications.

8.1 Mathematical model of the quadcopter

This section defines a simple mathematical model of a quadcopter, that is used to derive a
(local) controller. This model is based on the model proposed in literature, found in [31]. 2The
introduction in this section is very brief and only defines the basic relations without actually
2 them,
deriving Mathematical model
please refer to [31] for of quadcopter
the derivations and details.
Figure 8.1 is taken from [31] and depicts the structure of the model of a quadcopter, the
The quadcopter
quantities used and itsstructure is presented
angles. The in Figure
origin of the 1 including
global axis frame of the x, y, z is located
corresponding
reference, an-
in the of mass of the quadcopter. The x
gular velocities, torques and forces created by the four rotors (numbered from 1 to the
center axis is defined as always pointing towards
4).
f4 f1
ω4 zB ω1
z
τM4 τM1

yB xB
y x f3 f2
φ ψ

τM3 τM2
θ
ω3 ω2

Figure 8.1: Quadcopter model, quantities and angles

Figure 1: The inertial and body frames of a quadcopter

84
The absolute linear position of the quadcopter is defined in the inertial frame x,y,z-
axes with ξ. The attitude, i.e. the angular position, is defined in the inertial frame
with three Euler angles η. Pitch angle θ determines the rotation of the quadcopter
around the y-axis. Roll angle φ determines the rotation around the x-axis and yaw
north, while the z axis is defined as pointing towards the zenith. With the use of the right-hand
axis frame, the y axis always points to the west. The body axis frame xB , yB , zB has the origin
at the origin of the global axis frame, but the axis of the body frame of reference always aligns
with the arms of the quadcopter [32].
The attitude of the quadcopter (and thus, the body axis frame relative to the global axis frame)
is denoted by the angles φ, θ and ψ. Roll, is the rotation around the x axis, is indicated with
angle φ. Pitch, corresponds to rotation around the y axis, denoted by the angle θ, and angle
ψ denotes ’yaw’, the rotation around the z axis. In this manner, the total position (linear and
angular) of the quadcopter is given by the vector q, defined as follows:
q = [x, y, z, φ, θ, ψ]> (8.1)

The quadcopter is assumed to be a rigid body that is completely symmetrical around the z-axis,
in terms of both weight distribution and size. This results in a diagonal inertia matrix:
 
Ixx 0 0
I =  0 Iyy 0 
0 0 Izz
The values of the elements of I are determined by the actual weight distribution and size of the
quadcopter.
Each of the four rotors, indexed by i ∈ {1, 2, 3, 4}, generate an upward force fi perpendicular
to the zB -axis, the z axis of the body frame of reference, since they are connected to the
propellers. ωi denotes the angular speed of rotor i. Since, the rotors and the propellers have a
certain weight, a torque τMi around the rotor axis is generated by the rotation of each of the
rotor [32, Chp. 3].
fi = kωi2 (8.2)
τMi = bωi2 + IM ω̇i (8.3)

In this equation, k is a lift constant, b is a drag constant and IMi is the moment of inertia of
the rotor i. The total thrust T generated by the propellers is in the direction of the zB -axis and
is normal to the earth’s surface when the roll and pitch angles are 0◦ . The angular torque τ~B
expresses the torque in the body frame as a function of the rotor velocities [32, Chp. 3]. The
torque τ~B determines the change in attitude, i.e. the roll, pitch or yaw angles.

4
X 4
X
T = fi = k ωi2 (8.4)
i=1 i=1
 
  lk(−ω22 + ω42 )
τφ  lk(−ω12 + ω32 ) 
 
τ~B = τθ  = 

X4  (8.5)
 
τψ TMi
i=1

where, l is the distance from the center of the quadcopter to the center of the rotors.
Shown in (8.4) and (8.5), the rotor speeds ωi determine the total thrust that in turn corresponds
to the height of the quadcopter, and the change in roll, pitch and yaw angle. The task of the
quadcopter stabilization thus, is to accurately control these speeds in a way that the roll, pitch,
yaw and thrust converge to the desired values as early as possible. The interested reader can
refer to the controller loop design that ArduPilot flight controller uses, found in [1, p. 38-
41]

85
8.2 Sensor Fusion Algorithm
To be able to find a reliable estimate of the orientation of the quadcopter in a 3D space, the
data from different sensors requires to be fused together. The gyroscope can only measure the
displacement relative to its starting position. The accelerometer can determine the absolute
position but it is noisy and inaccurate when the object is in motion. The compass (or magne-
tometer) measurements are often corrupted by the induced magnetic fields due to the nearby
rotors, ESCs and on-board electronics.
There are multiple methods to reliably estimate the orientation of an object in 3D space. One
of the most reliable methods is to use a Kalman filter approach. The Kalman filter estimates
the noise on each of the sensors in order to optimize the reliability of the filtered position
[33]. However, a Kalman filter comes at the cost of high computational load and complexity in
implementation [32]. The term Inertial Measurement Unit (IMU) is often used to denote the
sensor fusion algorithm that is implemented either in software or in hardware. The Ardupilot
uses the MEMS accelerometers and gyros, that are read in software. The IMU is implemented
in software.

Direction Cosine Matrix (DCM) approach

DCM is a sensor fusion algorithm to estimate the attitude of a rigid body in 3D space using
multiple sensors. It is an alternative to the Kalman filter approach that faces complexity in
implementation and high computational load.
In this algorithm, the translation from the earth frame of reference to the body frame is captured
as a 3x3 matrix, also referred to as the DCM-matrix. The orientation kinematics deals with
calculation of the relative orientation of a body relative to a global or earth coordinate systems.
It is thus, useful to attach a coordinate system to our body frame and refer to it as Oxyz. The
other one is attached to our global frame and we refer to it as call OXYZ, Figure 8.2. It is
assumed that during calibration (i.e. when the quadcopter is kept still), both the global and
the body frames of reference have the same fixed origin at O.

Figure 8.2: i, j, k are unity vectors co-directional with the body frame x, y, and z axes. Oxyz
represents the body and OXYZ represent the global frame.

During flight, the data from the sensors is used to estimate how body frame moved relative to
the global frame [33]. The gyros are used as the primary source of orientation information. It
is important to note, that the gyros are prone to a phenomena called gyro drift due to the inte-
gration of the sensor values estimated over time and result in numerical errors. Accelerometers
on the other hand, have no drift. A feedback loop mechanism is used with gyros, accelerometers
and compass with a PI (Proportional-Integral) controller to determine the orientation of the

86
body in 3D space. The end goal being able to estimate the pitch, roll and yaw angles using this
algorithm. The gyros and accelerometers when used together are found to sufficiently diminish
the gyro drift on its 3-axis to less than 2 degree/ minute, due to the feedback mechanism that is
employed in DCM. Further, the use of compass and GPS that provide a reference for the yaw,
eliminates this drift almost entirely. From the 9 elements of DCM matrix, the three angles of
orientation of the quadcopter may be determined as:
θ or PITCH = -atan2(dcmMatrix[6],dcmMatrix[8])
φ or ROLL = atan2(dcmMatrix[7], dcmMatrix[8])
ψ or YAW = atan2(dcmMatrix[3], dcmMatrix[0])
The interested reader can refer to DCM algorithm in [34], for derivations of these equations. A
DCM-based algorithm is included in most open source multicopter firmwares.

8.3 Quadcopter configuration

Figure 8.3 shows four rotors placed in a square shaped form. The rotors next to each other spin
in the opposite direction to maintain the inherent stability of the quadcopter. The four rotors
work together to provide an upward thrust such that each rotor provides enough thrust to lift
1
4 of the quad’s weight. The movement of the quadcopter is controlled by varying the relative
thrusts of each of these four rotors to provide the lateral movement (pitch and roll) and change
in direction (yaw), as discussed in Section 8.1.

Figure 8.3: Pitch, roll and yaw rotations are produced by varying the speed of the rotors in the
two configurations. Yaw rotation is indicated only for ’+’ configuration.

Depending on the orientation of the rotors with respect to the body coordinate system, there
are two basic types of quadcopter configurations: plus and cross configurations as shown in
Figure 8.3.
• In the plus configuration, a pair of rotors spinning in the same direction are placed in the
x and y directions, respectively. With this configuration, it is easier to control the aircraft,
as each movement requires the controller to adjust the speeds of two rotors placed in the
desired direction [35, Sec 2.3]. For example, to tilt or pitch forward, the motor 4 increases
its thrust while decreasing the thrust of motor 3 providing a lean angle towards the front.

87
 • The cross configuration, on the other hand, requires all four rotors to vary their rotation
speed for any movement. For instance, to pitch or tilt forward, motors 2 and 4 provide
an upward thrust while reducing simultaneously, the thrust of motors 1 and 3. Although
the control system looks more complex, the cross configuration brings along an important
advantage.
The yaw rotation is the vehicle’s rotation about the center of mass. Yaw is induced by un-
balanced aerodynamic torques. The quadcopter consists of opposite pair of rotors rotating
Clockwise (CW) and Counter Clockwise (CCW), respectively; see Figure 8.3. The aerody-
namic torque of one rotor pair cancels out the torque created by the second pair of rotors which
rotates in the opposite direction. If all the four rotors apply an equal thrust, the quadcopter
will stay pointing towards the same direction by effectively cancelling out the rotation torque.
It is necessary to understand that the amount of torque required to rotate the aircraft is very
similar for both configurations. A quadcopter with a payload, is less likely to reach its satura-
tion (peak current usage), when using a cross configuration. In a cross configuration, for change
in direction (or yaw) all four rotors change their speed in contrast to a plus configuration where
only two rotor blades are used by doubling the amount speed change. Therefore, changing the
speed of each rotor by a small amount is, as opposed to changing only two rotors speed at
double the amount would keep the system safe from reaching the saturation point [35].

8.4 Software architecture

Figure 8.4 shows the software architecture of the multicopter with a functional block diagram.
The same architecture applies to all designs of a multicopter. The various blocks are explained
as under:
• Read inertial sensors
The input to this block are the 3-axis accelerometers and gyroscopes, respectively. The
MEMS sensors integrates these two sensors on a single chip, described in Chapter 7. The
raw values read from each of the sensors are used by the sensor fusion algorithm.
• AHRS (Attitude and Heading Reference System)
The AHRS receives the input from the Inertial sensor block, the 3-axis compass, GPS
ground course and the barometer sensor. The GPS ground course helps in estimating
the true north, measured in degrees. The values from all these sensors are combined in
the sensor fusion algorithm to determine the attitude or true orientation of the aircraft
(or quadcopter). The AHRS in general, forms the backbone of any navigation software.
Many other advanced functionalities exist such as estimation of the navigation airspeed
and GPS ground velocity that are used as part of the algorithm, not discussed in this
thesis.
• Altitude controller : The altitude controller receives inputs from the barometer and sonar
sensors to estimate the altitude. It runs a closed loop feedback mechanism to minimize
the error between the current and desired altitude.
• Hover controller
The hover controller primarily uses GPS sensor to obtain the latitude and longitude (x
and y axis), amongst other parameters. The altitude (z − axis) is determined by the
altitude controller, that is fed to this block. This forms the basis of autonomous hover,
where a closed loop control feedback loop is used to minimize the error in the 3D position.

88
 • WP navigation
The foundation of the Waypoint (WP) navigation block is the hover controller. This takes
the list of waypoints that the aircraft is instructed to navigate to, from the EEPROM
(Electrically Erasable Programmable Read-Only Memory) memory. The user provides
the waypoints via a GUI software, available to some open-source platforms. The AUTO
mode is triggered from the RC transmitter to switch from a manual control to autonomous
waypoint navigation.

Figure 8.4: An overview of the software architecture with hover and navigation control. The
hover controller is used as a backbone for waypoint navigation.

8.5 Modes of operation

Figure 8.5 illustrates the description of the RC controller with six functionalities, namely, Chan-
nel 1-4 (Roll, pitch, yaw and thrust), Channel 5 (A three-position mode switch) and Channel 6
(controller tuning knob).
The Channel 5 is used as a position mode switch. It has three positions, low, medium and high,
is used to switch between the MANUAL mode, HOVER mode and AUTO mode of control.
The MANUAL mode is a user control mode, where the user navigates the aircraft himself. The
HOVER is the autonomous mode, that uses GPS for its position correction. The AUTO mode
triggers the autonomous navigation of waypoints. The list of waypoints are read from memory
and the aircraft navigates to the planned waypoints. The user can intervene at any point in
time, by switching back to the MANUAL mode of operation, as a safety measure.
The transmitter offers a total of nine different functionalities represented as 9 unique channels.
However, for our purpose, we make use of only 6 channels.

89
Figure 8.5: The RC controller displays the different controls available in terms of switches and
knobs. The mode is changed via the 3-position switch.

8.6 Flight configuration

In order to develop a multicopter that offers an expected behaviour, correct components require
to be chosen along with the use of a stable software. The selection of components is described
in Chapter 7.
When the open-source software is built on the chosen flight controller, most often, does not
lead to an expected flight behaviour. Often, changes are required to be done in software and
certain procedure needs to be followed to make the multicopter behave as desired. The most
important steps followed in almost all multicopter designs are listed below.
1. Accelerometer calibration
The accelerometer calibration is performed to calibrate the 3-axis of the accelerometer
sensor. This is an essential one-time step that tells the flight controller where each of
the three axes point to. The flight controller must be placed on a plane surface when
the accelerometer is calibrated and must be kept away from vibrations. This procedure
determines the global frame of reference that is later used in flight as a reference for
stabilization algorithm, refer to Section 8.1 on mathematical model of quadcopter.
2. Flight controller tuning
There are various controllers defined in software. The most essential are the rate con-
troller, hover controller (also referred to as the loiter controller, in ArduPilot open-source
platform) and navigation controller. Each controller attempts to minimize a given error
created within its controller loop. The controller forces the output to become closer to
the input value, in the earliest possible time. In controller references, the P, I and D gain
terms define the controller response.
A mathematical representation of the relation between input and output of a basic closed
loop controller is given by its transfer function u(t), see equation 8.6. The closed loop
controller attempts to make the response of a non-linear system linear.

Z t
d
u(t) = Kp e(t) + Ki e(t) dt + Kd e(t) (8.6)
0 dt

90
 (a) The GUI provided by the ArduPilot open-source platform for
modifying the controller parameters.

(b) On-bench setup for controller tuning.

Figure 8.6: Illustration of steps taken for controller tuning.

The Proportional, P depends on the present error, Integral, I on the accumulation of

past errors, and Derivative, D is a prediction of future errors, based on the current rate
of change. Figure 8.6a shows the parameters used for controller tuning. A lousy PID
tuning of the controller can lead to the quadcopter going astray during actual flight. The
PID setting highly depends on the thrust to weight ratio of the quadcopter. Figure 8.6b
displays the on-bench setup during the controller tuning process. The reference to only
two of the controllers are discussed below.
(a) Rate controller : The P-I-D gains of the Rate controller relates to the stabilization
characteristics of the quadcopter, on its three primary axes. Each of the gains in
Rate Pitch, Rate Roll and Rate Yaw are tuned to make the quadcopter responsive
on its three axes. This controller does not use GPS. The values of the P, I, and D
usually remain in the range of 0.000 to 0.6000. The values determined after tuning
are indicated in Figure 8.6a.
The Rate controller gains can be tuned in flight using the transmitter’s CH6 knob.
For more information, please refer to Tuning section in [7].
(b) Rate Loiter controller : The loiter or hover controller uses the GPS. It computes
the error between the desired 3D location (latitude, longitude, altitude) against the
computed location from the GPS. The tuning of this controller determines how well

91
the quadcopter tracks its desired position. The response of the hover controller also
depends on the number of visible satellites.

92
Chapter 9

Performance Analysis and

Improvements

In order to perform successful networking transactions by hovering, it is desired that the multi-
copter presents stable hover characteristics. This chapter discusses several techniques that are
researched to improve the hovering precision of the multicopter. The Section 9.1 discusses the
measures taken to improve the stability of the platform. The tests performed during actual
hover are illustrated in 9.2. The energy consumed by the MANET networking protocol run on
the embedded systems is analysed in Section 9.3. In addition, thrust tests conducted to measure
the amount of power consumed for hovering is also discussed. This leads us to estimate to flight
time achievable with our design for performing networking tasks.

9.1 Measures to improve stability

1. Reduction in vibrations:
Accelerometers are prone to noise due to external vibrations. The accelerometers are
used in sensor fusion algorithm to estimate the attitude or orientation of the flying vehi-
cles. The spinning motors induce vibrations on the air frame that eventually reach the
accelerometer. Further, the wind affects the stability of the system as well. When the
accelerometer readings are noisy, it affects the attitude estimation adversely.

Figure 9.1: Application of double layered anti-vibration foam pads. Each pad measures 1.5 cm
in thickness.

During a hover, the GPS velocity readings received from the satellites is used to determine
the acceleration of the vehicle (acceleration is determined by taking the derivative of GPS

93
 (a) Accelerometer (x,y,z) reading before vibration damping

(b) Accelerometer (x,y,z) reading after vibration damping

Figure 9.2: The 3-axis accelerometer data recorded during hover.

velocity over time). The readings from the X and Y axes of the 3-axis accelerometer are
compared with the acceleration as determined by the GPS, to compute the average accel-
eration. When the accelerometer is noisy, this affects the GPS position accuracy. With
increased noise on accelerometers, results in increase in multicopter vibrations. This in
turn results in inaccurate hovering characteristics and slightly higher power consumption
(due to non-linear surge of power for stabilization).
As part of this research, various methods have been tried to reduce the noise on the
accelerometers. The idea is to isolate the accelerometer from high frequency vibrations,
but conduct the lower frequency vibrations that might represent small changes in attitude.
The techniques such as application of moon gel1 , rubber dampeners and anti-vibration
foam pads are used. The best results are obtained using two consecutive layers of anti-
vibration foam pads applied below the surface of the flight controller, see Figure 9.1. The
1
Moongel is a translucent sticky, gel-like substance used for vibration damping

94
 results without and with the double-layered anti-vibration foam pads are shown in Figure
9.2a and Figure 9.2b, respectively.
2. Controller tuning:
The controller tuning is introduced in Chapter 8. The controller tuning plays an essential
role in stability of the multicopter. In order for the aerial platform to react swiftly to
external disturbances, the controller gains must be chosen wisely. Figure 9.3 shows the
controller’s response to the Roll axis. The data is logged at 10 Hz and the tests are
conducted outdoors. The wind speed recorded during this test is 11 kmph. The steady
state error obtained is approx. 2 degrees. The PID gains for the roll axis are found to
be (0.13, 0.13, 0.0090), refer to Section 8.6 in Chapter 8. The pitch and yaw axis (not
shown) are tuned similarly.

Figure 9.3: Result of controller tuning for roll axis. The controller output tries to converge to
its input.

3. Magnetic interference on compass:

The on-board compass provides an absolute reference for rotation of the aircraft with
respect to the earth’s magnetic field. Thus, it is an essential sensor component for attitude
estimation. The drawback is that the compass is susceptible to the magnetic interference
created from the power-distribution-board, wires, ESC, motors and power source. This
is one of the major drawbacks using a compass on any typical multicopter. With this
in mind, the first step that is taken is to interface an external compass instead of using
the on-board compass that the ArduPilot flight controller already provides. As a general
practice, the compass is kept as far away from the sources of magnetic interference. As the
second step, a few layers of aluminium foil are placed directly under the flight controller
to minimize the magnetic field interference from the power distribution board, see Figure
9.4.

95
 Figure 9.4: Use of Aluminium foil minimize the magnetic interference on compass.

It is noticed that the magnetic interference on compass is directly proportional to the

current drawn by the motors. The interference is linear with current drawn but not
perfectly linear with throttle. A test is conducted to see the effect the throttle has on
compass readings, shown in Figure 9.5. The figure shows a linear deviation of Z-component
of compass with throttle. An available algorithm for compensation of magnetic field on
compass is taken from the open-source platform, [7]. The algorithm computes the offsets
for x, y and z components of the compass based on the static throttle tests. The static
throttle tests are conducted (on ground) by varying the throttle values to determine the
offsets required for the three axes. These offsets are saved in the EEPROM memory.
During the actual flight, these offsets are added to the compass readings based on throttle
required to hover. These offsets compensate for the change in compass readings due to
magnetic interferences.

Figure 9.5: An near-linear deviation of compass with increasing throttle.

4. Barometer sensitivity to light:

The barometric pressure (MS5611 sensor) on the flight controller is used to determine the
altitude of the hovering platform. The datasheet for some of the popular pressure sensors
indicate sensitivity to light, an example is Model 092 barometric pressure sensor, found
in [36]. It is found that the MS5611 sensor is no different and is also sensitive to light.
This came as a surprise since this behaviour is not indicated in its datasheet [37].
Tests conducted with simple torchlight on and off, on the pressure sensor chip indicates

96
 drastic change in altitude readings. This behaviour lead to unexpected jumps in the
quadcopter when it was flown at different times of the day. When this chip is covered
with a black foam, the jumps vanished as the chip is now protected against direct sunlight.

9.2 Hover tests

After the measures taken to improve the stability of the hovering platform, tests are conducted
outdoors. Figure 9.6 displays the autonomous hovering of the quadcopter. When one of the
switches of the RC transmitter is switched high, the quadcopter goes into the autonomous
hovering state. The hover test is conducted at 6 m, with a recorded windspeed of 8 kmph.
The real-time data is logged onto the dataflash memory of the flight controller at a frequency
of 20 Hz. It is seen from the figure, when the throttle input (marked red) is kept constant,
the controller adjusts the thrust applied to the motors. The smooth line (indicated by blue)
shows the platform is very well stabilized in the hover mode. A sub-meter hovering precision is
obtained with 8 visible GPS satellites. The number of satellites visible are seen to vary from 7
to 14 during the day, over the Netherlands.

Figure 9.6: Test to verify the stability of the platform in autonomous hovering mode.

Figure 9.7 illustrates another example of the flight tests with wind speeds of 18 kmph. The
throttle output (marked as green) is adjusted rapidly to cope up with sudden bursts of wind.
The reader should note that the throttle output also changes to compensate for the roll, pitch
or yaw variation. For instance, when the wind from one direction pushes against the hovering
platform, the motors are given an appropriate thrust. This thrust is directed in such a way
so as to keep the hovering platform’s position intact. The effect of wind burst is clearly seen
from the graph. There are only certain instances where the roll, pitch variations are seen, that
translate to the output throttle to the motors. Also, it is seen that over a time duration of 3.5
minutes of recording, there is no visible yaw drift (marked in black).
These tests are a direct indication of the stability achieved with the hovering platform.

97
Figure 9.7: Hovering test in a windspeed of 18 kmph. The graph shows the attitude and thrust
variations.

9.3 Power consumption tests

This section studies the power consumption by the networking hardware and the aerial vehicle,
separately. This analysis is essential to estimate the impact the networking will have on the
overall flight time after integration with the aerial platform.

9.3.1 Power consumed by networking hardware

The reasons for selection of the OLSR protocol were discussed in section 4.5, Chapter 4. OLSR
is preferred in terms of quick route discovery and greater throughput. To test the power
consumption for a node in MANET, test is conducted with a Raspberry Pi hardware running
OLSR protocol, with an external energy source. The energy source used is a 5V, 2600mAh
Lithium-Ion battery. The wireless adapter used is TP-Link WN722n. The energy consumed by
running the respective routing protocol is directly proportional to the average power dissipated
by the hardware for handling the network load.

Figure 9.8: Raspberry Pi running OLSR actively, with an external power source.

With the battery fully charged, data was continuously logged to a file using a script to keep

98
track of the time. When the battery is emptied, the last time logged is noted. It is seen that
with the OLSR proactive protocol, the battery lasted for 2 hours and 46 minutes. We compute
the power dissipated using the following benchmark:
• Nominal voltage: 5V
• Battery current: 2600mAh
• Energy (in Watt-hours): 13 Wh
13Wh is consumed by the Raspberry Pi running for 2.77 hours, thus energy required by it is
≈ 4.7W h. In other words, it consumes 4.7W of continuous power every hour. Without the
OLSR running, the Raspberry pi consumes ≈ 3.5W h of energy. This leads us to a 1.2 Wh
estimate by the protocol alone.
The power consumed by the camera is not considered as it is used only at specific instances,
when required. As per the specifications, it requires 250 mA to operate.

9.3.2 Power consumed by aerial vehicle

A flying vehicle, such as a mid-sized quadcopter built in this project, uses the following config-
uration for its energy source:
• Nominal voltage: 11.1V
• Battery current: 5000mAh
• Energy (in Watt-hours): 55 Wh

Figure 9.9: Test conducted to determine the power required for hovering.

An experiment is conducted to estimate the amount of power required by the quadcopter to start
hovering. The quadcopter design incorporates 850 kV motors, 10-inch propellers and weighs
approx. 1.5 kg. With this experiment, a watt-meter is used, connected between the battery
source and the quadcopter’s power distribution unit. The watt-meter measures the amount of
current drawn, remaining battery voltage and the power consumed by the quadcopter. These
experiments impart the knowledge of the take-off power for the vehicle and amount of time it
is expected to hover in air.
Figure 9.9 displays a test conducted for current draw against the power consumed by the
quadcopter. The test reveals that the quadcopter starts hovering (at approx. 0.5 meter) with
19 A of current. The remaining battery voltage is measured at 12.3 V, during this experiment.
This directly indicates that the power required to hover is approx. 235 W. It can also be

99
reasoned out that hovering would lead to a better flight performance in terms of the flight time
than flying. Flying leads to non-linear increase and decrease of current leading to more stress on
the battery. The current slowly increases as the voltage decreases to maintain a constant power
output. The tests reveal that the power consumed for hovering is an important consideration
for performing networking tasks. More power drawn indicates less flight times and thus, the
inability to perform tasks for a long duration of time.
It is observed that our quadcopter consumes ≈ 235W of power for hovering alone (measured
using a Watt-meter, indoors); can hover for 14 minutes continuously consuming 235W h, before
draining the energy source.
It can be well understood that energy consumed by using the networking hardware (with OLSR
proactive protocol) does not significantly affect the hovering time. For micro-UAVs however,
the study of energy consumption using different routing protocols and consideration of the
weight of the hardware may prove more useful in their objective selection.

100
Chapter 10

Aerial Network Protocol

This chapter introduces the aerial-network protocol that closely interacts with the flight con-
troller to accomplish tasks at a given waypoint. The chapter is divided into three main sections.
The network stack extension is presented in Section 10.1. In Section 10.2, the background of
the aerial-network protocol and its purpose is detailed. The various components of this protocol
along with its working is described in Section 10.3.

10.1 Extended network stack

Similar to how the DTN is introduced over the transport layer protocol (layer 4) in the TCP/IP
network stack, the aerial-network protocol is designed on top of the DTN layer (layer 5). The
aerial-network protocol is designed to handle the bi-directional communication between the
flight controller and the networking hardware. In addition, it brings together the implemen-
tation of existing and the developed DTN extensions, addresses a robust bundle management
system and forwarding strategy, and listens to service requests from other nodes in the mesh
network. Figure 10.1 shows the various protocols in the extended network stack. The layer 3,
Network (IP) runs the OLSR protocol; layer 5, runs the DTN protocol and the aerial-network
protocol runs on a layer above it.

Figure 10.1: Extended TCP/IP network stack.

10.2 Background of the protocol

The idea behind the aerial-network protocol is to bring together the concepts discussed so far, in
Chapter 4 on MANET protocols, the DTN protocol in Chapter 5 and the multicopter software

101
discussed in Chapter 8. In other words, the aerial vehicle acts as a mobile router with the
ability to store and forward data and adjust its navigation behaviour based on the networking
parameters.
All nodes in the mesh network use the same network stack, as seen in Figure 10.1. The purpose
of the aerial-network protocol is to receive requests from other nodes in the network and service
them. In addition, data is forwarded to or requested from the other nodes in the network. In
summary, it functions as a publish all, subscribe network where nodes publish all information
available to the network and the ones interested in a specific information can request the data.
The publish and subscribe service is provided for data files such as photos, videos or text
messages that need to be forwarded from one place to the other, over unreliable networks,
irrespective of distance.

Figure 10.2: Illustrates the role a (static or mobile) node during network transactions, at a
waypoint.

Figure 10.2 shows the roles taken up by a node in the mesh network. Each node simultaneously
assumes the role of a data receiver by listening to other nodes for requests and a data sender,
to forward the bundles to other nodes. The following assumptions are valid for each node in
the MANET:
1. Each node operates in the ad-hoc mode and is on the same wireless channel. Channel 10
is chosen, refer to Chapter 6.
2. The OLSR routing protocol is run on each node for one hop and two hop neighbour
discovery.
3. Each node in the MANET is considered a DTN node. Thus, the DTN mechanism in built
into every node.
4. Each node runs the aerial-network protocol.

10.3 Aerial-network protocol

On every node, the aerial-network protocol is responsible for the following operations:
1. Read the configuration file based on an XML. The XML configuration defines a node’s
properties and the properties of tasks to initiate.
2. Trigger the OSLR, DTN daemons and received bundle processing. Access the internals of
OLSR and DTN protocols to gather interesting network information. For the algorithm
developed on ’received bundle processing’, refer to Section 5.7, in Chapter 5.
3. Initiate threads to listen to service requests from other nodes.

102
 4. Initiate bi-directional communication between the flight controller and the (mobile) node.
The networking hardware (Raspberry Pi) instructs the flight controller to hover, reduce
its altitude based on the network parameters.
Each of the points presented above are discussed below.

10.3.1 XML Configuration file

All nodes in the network, use an XML configuration file that defines certain properties of the
node and the tasks required to be accomplished with other nodes during the mission. Through
this configuration file, a node can be defined as either static or mobile. The XML configuration
is read by each node at runtime, i.e. when the node is powered up. As an example, the XML
configuration for a node is given below:
<Tasks>
<!−− I s s u e s e r v i c e r e q u e s t t o Node ’ pi1 ’ −−>
<Task name = ’ Recv ’ Id=”Rcv1” depends on =’’>
<rxfrom>pi1 </rxfrom>
<r e q u e s t s e r v i c e >v i d e o s , photos , today </ r e q u e s t s e r v i c e >
</Task>

<!−− Send a data f i l e t o Node ’ pi3 ’ −−>

<Task name = ’ Send ’ Id=”Snd1” depends on = ””>
<d e s t >pi3 </d e s t >
<f i l e n a m e >c r i t i c a l d a t a . mp4 , o p e r a t i o n . txt </f i l e n a m e >
</Task>
</Tasks>

<!−− Shoot a v i d e o ( i n s e c o n d s ) and f o r w a r d t o Node ’ t p l i n k 1 ’ −−>

<Task name = ’ Video ’ Id=”Vid1 ” depends on = ”Rcv1”>
<v i d e o t i m e >30</v i d e o t i m e >
<waypoint ></waypoint>
<f o r w a r d t o >t p l i n k 1 </f o r w a r d t o >
</Task>

<Nodes>
<Node name=’ pi1 ’ i p = ’ 1 9 2 . 1 6 8 . 1 0 . 5 1 ’ dtnAddr=’ dtn : / / pi1 ’ WaypointId =’’/>
...
</Nodes>

<A c c e s s o r i e s >
<CurrentNode>pi2 </CurrentNode>
<NodeKind>mobile </NodeKind> <!−− m o b i l e o r s t a t i c −−>
<ACK Port>8888</ACK Port>
<!−− s t o r a g e path f o r incoming data −−>
<S t o r a g e p a t h >/home/ p i / i b r d t n </S t o r a g e p a t h >
...
</ A c c e s s o r i e s >

The XML file presented above defines three tags namely, Tasks, Nodes and Accessories. An
XML file is composed of tags and attributes. The various tags and attributes are explained
briefly below:

103
 1. Tasks tag: Three unique tasks can be defined. These are receive service (data), send data
file and shoot video and forward. Each task also specifies a dependency. For instance, the
task Vid1 is only initiated after the completion of task Rcv1, denoted by the depends on
attribute.
• Recv : Defines the service request to be issued to other nodes. These can be the
request for videos and photos that have been obtained today.
• Send : Defines the data that is to be sent across another node, marked as dest
(destination). The data is delivered whenever the node is visible.
• Video: Defines a video task that is initiated, denoted in seconds. When the videotime
attribute is set to 0, a picture is taken instead of a video. Optionally, this data can
be forwarded to other DTN nodes.
2. Nodes tag: List of nodes the current node expects to forward the data to. It consists of
the following attributes:
• name: The alias for a node, e.g. ’pi1’.
• ip: The IP address of the node. This is only required when a service is requested
from another node. The client (current node) contacts the server of another node in
such a case.
• dtnAddr : The DTN address of a node. See Section 5.5 in Chapter 5.
• WaypointId : This property is used only for the node that is defined as a mobile,
i.e. for the aerial vehicle. An ID is associated with a node’s location. For e.g., in a
mission with three waypoints, the static node’s placement can be identified with an
ID.
3. Accessories tag: The properties that each node uses internally, in its algorithm.
• CurrentNode: The alias for the current node, e.g. ’pi2’.
• NodeKind : The type of the current node. It can either be a static or a mobile node.
For waypoint navigation, one of the nodes is defined to be mobile whereas other
nodes use the static properties for this attribute.
• Storage path: The storage path for the received or transmitted data (bundles).
• ACK Port: Each node runs a server to service the requests issued by other nodes.
It spawns a thread per client. The acknowledgement port opens up a socket for its
connection.
Figure 10.3 illustrates the use of the XML configuration and its interpretation. An object-
oriented programming approach is used to convert the various task and node XML tags into
task and node objects, respectively. The dependency block keeps track of the task objects in a
queue and triggers the tasks based on its dependency. The miscellaneous accessories deal with
the storage of data and other properties such as display the received data on the monitor (not
shown as part of XML tags). These objects define the ’what’ part of aerial networking.

10.3.2 Query the OLSR and DTN

The OLSR and DTN daemons are triggered via a script, run on every node. The OLSR
determines the one hop and two hop neighbours, whereas the DTN addresses store-and-forward
of bundles between nodes.

104
Figure 10.3: Illustrates how the tasks are interpreted from the XML file. Each task, node is an
object.

With the help of OLSR Txtinfo plugin, discussed under Section 6.4, the OLSR is queried on
its port over the localhost1 . The information returned by OLSR is filtered out to obtain the
information on the ETX metric of the neighbouring node(s). The ETX metric determines the
quality of connection. Based on the value of this metric, the altitude of the hovering platform
is altered accordingly.
The internals of DTN is queried in a similar fashion to the OLSR plugins, to determine the
neighbour DTN nodes. The DTN is queried on its local port (defined in the DTN configuration
file), to obtain this information as a list. This information is requested at 5 Hz and used for
data logging purposes.
Alongside running OLSR and DTN daemons, the received bundle processing is also run as a
separate process. This process is an improvement over the DTNRecv process, discussed in
Chapter 5, is an event based mechanism to manage the reception of any number of bundles
received at any time. The bundles are stored systematically in the file system on reception.

10.3.3 Client server architecture

Each node simultaneously, acts as both a client and a server for data transactions. The node is
a client because it issues data request to other nodes. The node is a server because it services
the requests from other nodes. The server runs on each node and has a socket that is bound
to a specific port number. All (service) requests coming to this port is analysed and serviced,
1
A localhost is that standard hostname given to the (current) machine itself.

105
when possible.
The Algorithm 2 listed, runs as a separate background thread. It depicts the creation of a
thread per client service request. The request received from a client is based on certain tags
such as video, today, from pi3. Once the server receives this tag, it queries its repository based
on this tag. It determines if a video has been received from the node ’pi3’, today. If the query
succeeds, the required data is sent to the requesting node (the client) via DTN.

Algorithm 2 Server processing

Require: HOST, PORT, sock
Ensure: socket sock object is initialized, HOST = ” (accept request from any IP) and PORT
= 8888 (as set in XML configuration file)
1: bindToSocket(HOST, PORT) [Bind to a port]
2: sock.startlisten() [Start listening on the socket]
3: while true do
4: conn, addr = sock.accept()
5: start new thread(clientthread, conn) [Start a new thread for each client. The service
request from each client is analysed and appropriate action is taken]

10.3.4 Network flight interaction

The flight controller is responsible for navigation of the aircraft from one waypoint to the
other. The networking hardware, instructs the flight controller on actions the aircraft must
take to successfully complete a data transaction. Figure 10.4 shows the interaction between the
networking hardware (Raspberry Pi) and the flight controller.
The Algorithm 3 presents the reader with the network flight interaction. The flight controller
triggers an event as soon as it is reaches a radius of 5 meters around a waypoint. The networking
hardware is informed of the aircraft’s arrival. If a task is found for this waypoint, the aircraft
is informed to hover for a fixed time (kept as 60 seconds). During this time, the networking
takes control and issues commands based on the completeness of the task back to the flight
controller. The following commands are issued between the flight controller and the networking
hardware.

Flight controller commands

The following are the commands issued by the flight controller to the networking hardware.
1. REACHED: This command is sent to the networking hardware when a waypoint is
reached. The ID of the waypoint (WP ID) is also sent alongside.
2. ACK WP DONE : This command is only an acknowledgement from the flight controller,
in response to the task complete command (NEXT WP).
3. TIMEOUT : The flight controller has its own timer that is run during the hover, at a
waypoint. The time is set to be 5 minutes. Within this time, it is assumed that all tasks
will be completed. When this timer expires, it interrupts the networking hardware to stop
its current activities before it moves on to the next waypoint.
4. INTERRUPT : This command is passed to the networking hardware, whenever the user
switches from the AUTO to MANUAL mode of control.

106
Figure 10.4: Illustrates the network flight interaction. The aerial-network protocol runs on the
networking hardware, the Raspberry Pi.

Networking hardware commands

The following are the commands issued by the networking hardware to the flight controller.
1. HOVER: Requests the flight controller to hover for 60 seconds. This command is issued
only once, each time a waypoint is reached, by default.
2. ADJ ALT : The navigation controller of the aircraft is informed to adjust the altitude
based on the given link quality determined by OLSR. The altitude is adjusted either
when a node is not found or when a node is detected but the ETX value is more than 3.0
during a data transaction. The altitude is reduced by half and is done once. The aircraft
always stays 5 meters from the ground.
3. CIRCLE : If a pending task exists at the current waypoint and the task is not found in
60 seconds since its initiation, triggers the circle mode. In the circle mode, the aircraft
navigates in a circular fashion around a Region of Interest (ROI), with a given radius (4
meters) and is initiated when atleast 5 meters above the ground. The circle mode is used
but not fully tested. The implementation of CIRCLE mode is part of the open-source
firmware. More information can be found in the Arducopter section in [7].
4. HOVER EXT : Forces a hover extension by 15 seconds when the estimated time for the
task is exceeded but the network is still busy with a transaction.
5. NEXT WP : This command instructs the flight controller to move on to the next waypoint,
if there is one. This command is issued when there is no pending task, or the task is
completed or the max permissible time is exceeded.

107
Algorithm 3 Network flight interaction
Require: running, wp cmd, extension, done, time, max time, task started, adj alt, WP,
CMD [enums]
Ensure: running = true, serial object is initialized
1: readXML() [Read the XML configuration settings for this node]
2: StartDaemon() [Start the OLSR, DTN, bundle processing process]
3: listenToClients() [Initiate the server for this node]
4: while running do
5: wp cmd, wp ID ← readSerial() [Read the incoming commands]
6: if wp cmd is WP.REACHED then
7: wp busy ← true
8: task started ← initiateTasks(wp ID) [Search and initiate pending tasks]
9: start timer()
10: send Cmd(HOVER)
11: else
12: if wp cmd is WP.TIMEOUT or WP.INTERRUPT or WP.ACK WP DONE then
13: wp busy ← false extension ← 0
14: stop timer()
15: if wp busy then
16: time ← readTimeElapsed()
17: done ← checkTaskCompleted()
18: max time = transactionManager() [Give a rough estimate the time required for current
task(s)]
19: logData(wp cmd, max time, wp ID)
20: if task started 6= true and time ≥ 60 then
21: send Cmd(CMD.CIRCLE)
22: task started ← initiateTasks(wp ID)
23: if done is true and time ≤ max time then
24: send Cmd(CMD.NEXT WP)
25: adj alt ← adjustAltitude() [Based on ETX metric]
26: if adj alt and time ≤ max time then
27: send Cmd(CMD.ADJ ALT)
28: if time (max time + extension*15) then
29: if extension ≤ 10 and transaction busy() then
30: send Cmd(CMD.HOVER EXT, 15)
31: extension = extension + 1
32: else
33: send Cmd(CMD.NEXT WP)
34: if not running then
35: logData(wp cmd, max time, wp ID)
36: return [In case, of an exception]

In summary, this chapter discusses the extension of the network stack with the aerial-network
protocol. It is shown how the network transaction is carried out with other nodes with the help
of MANET, DTN protocols and its extensions such as with the use of ETX quality metric. In
the mesh network, one mobile node along with other static nodes are used. The next Chapter 11
presents the reader with the concept of waypoint navigation, scenarios and the results.

108
Chapter 11

Waypoint Networking

This chapter presents the application of the concepts discussed in this thesis. Tests are con-
ducted outdoors with a number of static nodes and a mobile node. All nodes are part of the
same mesh network. The static nodes are placed at a distance from each other such that each
creates isolated regions of network. These nodes are placed at certain strategic locations as
determined by the GPS coordinates. The multicopter’s flight plan is plotted on a Google map
interface with these GPS coordinates, marked as waypoints. It flies to each of these waypoints,
establishes a network connection with the node at this waypoint and carries out the required
data transaction.

Figure 11.1: A mobile node (quadcopter) is used along with other static nodes in the MANET,
during waypoint networking.

The chapter starts out with an analysis of the node’s antenna orientation, Section 11.1. Tests
are conducted with a mobile node that is made to hover above a static node, placed on the
ground, to determine the correct antenna orientation. The change in orientation of the antenna
affects the time to discover its neighbours. In Section 11.2, mission planning is discussed.
Mission planning is the first step to be performed before waypoint navigation. The networking
tests conducted during the mobile navigation of waypoints is presented in Section 11.3. The
final section 11.4, discusses the results obtained.

11.1 ETX Measurements with antenna orientation

A classification of antennas can be based on:

109
 • Frequency and size: Antennas used for HF (High frequency) are different from antennas
used for VHF (Very high frequency) and antennas for microwave. Our interest lies in
working in the microwave range especially 2.4 GHz range. At 2.4 GHz, the wavelength is
found to be 12.5 cm.
• Directivity: Antennas can be classified as omnidirectional or directional. Omnidirectional
antennas radiate the same signal around the antenna in a 360◦ radiation pattern. The
most popular omnidirectional antennas are the dipole or monopole. Directional antennas
radiate in a specific area. The beam pattern of 120◦ , 60◦ or much narrower beam width
are quite common. Directional antennas have the highest gain and therefore, are used for
long distances. Table 11.1 lists the various antenna types in the two respective categories.

Antenna types Examples

Dipole, Monopole, Collinear,
Omnidirectional
Slotted waveguide
Patch, Sectorial, Yagi, Biquad,
Directional
Dish, Cantenna, Sectorial

Table 11.1: Various antenna types available.

Usually, the wireless adapters can attach any antenna type. One of the requirements framed
in this research is that the mobile node is able to hover and communicate with the static node
placed below it, on the ground. The static node is placed at a waypoint that the mobile node
flies to. This waypoint is based on the planned GPS coordinates. It can be understood that
an omnidirectional antenna will prove more of a logical choice than a directional antenna. This
enables the static node to be placed in the region around the waypoint, rather than at the exact
GPS coordinates.

Antenna selection

Figure 11.2: A 4 dBi detachable wireless antenna with TP-Link WN722n wireless adapter.

We use a detachable omnidirectional dipole antenna with a gain of 4dBi1 , with the TL-WN722N
wireless adapter, Figure 7.15. The antenna with a higher gain is more effective in its radia-
tion pattern. Every antenna designed raises power in the wanted direction and reduces power
in unwanted directions. However, an antenna does not add additional power to the wireless
adapter. This antenna can be rotated and adjusted in different directions to fit the various
operation requirements. A much higher gain antenna may become detrimental to the system
performance, since the mobile node must be able to have reception over a larger area.
1
For antennas, a common reference unit used is the dBi. It is the gain of an antenna with reference to a
ISOTROPIC source. An Isotropic source is a perfect omnidirectional radiator and does not exist in nature.

110
Figure 11.3: The figure shows, (a) the radiation pattern of a simple omnidirectional antenna,
(b) and (c) shows the 4 dBi antenna gain pattern from a vertical and horizontal plane of view.

(a) Antenna orientation vertically downwards

(b) A horizontal antenna orientation

Figure 11.4: Neighbour discovery tests performed with respect to antenna orientation. The tests
are conducted between a static node placed on the ground and a mobile node hovering at a height
of 5 meters.

Figure 11.3(a) shows the radiation pattern with an omnidirectional antenna. Figure 11.3(b)
and (c) shows the theoretical antenna pattern with a 4 dBi antenna gain. The antenna lobes
in the top and bottom of the antenna are reduced as compared to the horizontal plane.

111
11.1.1 Tests with antenna orientation

Each node in the network should have the correct antenna orientation with respect to the target
node. The orientation of the antenna as discussed, can adversely affect its transmission and
reception range. Tests are conducted to determine how the antenna orientation affects the
discovery of nodes and the estimation of the node’s link quality based on ETX metric. For this
test, a static node is placed on the ground with a horizontal antenna orientation whereas, the
mobile node is made to autonomously hover at a height of five meters. Figure 11.4 illustrates
the two different antenna orientations tested on the mobile node and measurements made on
this mobile node. A number of tests conducted convey consistently, the horizontal orientation
of the antenna helps in a faster convergence to a link quality of approx. 1.8, in comparison
to a vertical orientation. This can be attributed to the longer range with the omnidirectional
antenna in a horizontal orientation and also verifies the theory of having a horizontal antenna
orientation, see Figure 11.3.

11.2 Mission Planning

Before introducing the mission planning and waypoint navigation, we discuss the concept of
hovering for data exchange, with an example. Figure 11.5, shows a mobile node hovering above
a static node, placed on the ground. This scenario is similar to the one that is encountered
during waypoint navigation and networking. The mobile node establishes an ad-hoc network
connection and uses the Aerial-network protocol to initiate and complete the data transactions.
The reader should note that this protocol can also be used without waypoint navigation by
setting the NodeKind property in the XML configuration, please refer to Chapter 10.

Figure 11.5: An illustration of an indoor hovering, at Thales Nederland B.V. The mobile node
exchanges data with the static node below.

For outdoor navigation, some of the open-source platforms such as ArduPilot provide a GUI
for planning waypoints. This GUI is called Mission Planner [7]. The Google maps interface is
used by the GUI for mission planning. The waypoints can be plotted by marking points on the
map, Figure 11.6. The points marked on the map are translated to a latitude and a longitude.
The user can provide the altitude for each waypoint via the GUI. The (latitude, longitude and
altitude) for each waypoint are then encapsulated into an object, along with other parameters
and sent to the flight controller’s internal EEPROM memory via UART or telemetry.
Static nodes are placed at waypoints marked Home and 3, respectively. The dotted circles

112
around waypoints Home and 3 indicate the presence of static nodes in that region (used for
illustration purposes). In order to give the flight controller the knowledge of presence of a node
at a waypoint, an identifier is assigned for those regions. The waypoints marked Home and 3
are sent to the flight controller, as additional parameters indicating presence of a node. This is
done in order make sure that the aircraft does not keep searching for a node at each waypoint.
The reader should note that waypoint 2, does not contain any static node. Thus, the aircraft
does not assume a node’s presence at this waypoint.

Figure 11.6: Mission waypoint planning. Three waypoints are plotted on this map. The take off
point is marked as Home.

11.3 Waypoint networking

The concept of waypoint networking is that the mobile node navigates autonomously to where
the static nodes are placed. It then tries to establish connection and carry out the data trans-
actions with the help of the various networking protocols described. The mobile node has no
knowledge of which node is present where. It just knows that a node is present at a given
waypoint and the task(s) for a node that require to be completed, if any. The static nodes only
know their region ID’s, the waypoints where they are placed, marked as Home and 3. However,
they do not know if and when a mobile node will arrive to initiate data transactions.
Figure 11.7 shows one of the tested scenarios for waypoint networking. At waypoint Home, a
static node (a laptop, marked ubuntu) is placed. Similarly, at waypoint 3, another static node
(Raspberry Pi, marked pi1) is placed. We will call the mobile node as pi2, as it contains a
Raspberry Pi node running networking algorithms. The distance between the two static node
placements is approx. 40 meters. The power of the static nodes is reduced to 10 dBm, which
limits the wireless range of the nodes sufficiently. This is done so that they do not see each
other.

113
Tasks during the mission

Table 11.2 lists the tasks performed during the mission. The size of the data file is mentioned in
the last column. The size of data.jpg is already known, however the size of video file (generated
in real-time during navigation) is unknown. A 30 second video footage with 15 fps with the
Raspberry Pi’s camera is estimated to be approx. 11,500 KB. The time taken to transmit or
receive a file is directly proportional to its size. A higher file size increases the total mission
time. We try to keep the scenarios as simple as possible, in order to test the concept.

Task Sender node Target node Waypoint Data size

Send data.jpg ubuntu pi1 - 172 KB
Send Video.mp4 pi2 ubuntu 2 ≈11,500 KB

Table 11.2: The list of tasks performed during the mission.

The task defined by the static node ubuntu is given below. The target node is defined to be pi1,
located at waypoint 3. It should be clear by now, that the two networks created by static node
ubuntu and static node pi1, cannot see each other. The only way is to transport the data via
another node that passes by. We use DTN epidemic routing on all nodes to spread the bundles
across to other nodes in the vicinity. This increases the probability that the data eventually
reaches its destination.
<!−− Task i n i t i a t e d by ubuntu ( s t a t i c node ) ’ −−>
<!−− Send a data f i l e t o node ’ pi1 ’ −−>
<Task name = ’ Send ’ Id=”Snd1” depends on = ””>
<d e s t >pi1 </d e s t >
<f i l e n a m e >data . jpg </f i l e n a m e >
</Task>

The task defined by the mobile node pi2 is given below. This task states that a video must be
taken for 30 seconds at waypoint 2. The video footage obtained will be forwarded to the node
’ubuntu’, whenever it is visible in future. The name for the video, Video.mp4, is shown only
for illustration. The name for the video is automatically generated through software and the
video remains stored in the repository until it is delivered to its target node.
<!−− Task i n i t i a t e d by ’ pi2 ’ ( m o b i l e node ) ’ −−>
<!−− Shoot a v i d e o ( i n s e c o n d s ) , f o r w a r d t o node ’ ubuntu ’ −−>
<Task name = ’ Video ’ Id=”Vid1 ” depends on = ””>
<v i d e o t i m e >30</v i d e o t i m e >
<waypoint >2</waypoint>
<f o r w a r d t o >ubuntu</f o r w a r d t o >
</Task>

1. The multicopter takes off from waypoint Home.

2. Hovers in this region at a default height of 15 meters (defined during the mission waypoint
planning). The mobile node has the knowledge that a node is placed at this waypoint. It
tries to first establish a connection with the static node. If a connection is not established,
the altitude is lowered by half (7.5 meters, in this case). The ETX metric (link quality)
is continuously determined to notify the action to be taken for adjusting the altitude, in
case the node is not found. If the node is still not found within a given duration, the
CIRCLE mode is initiated (i.e. if above 5 meters), in which the mobile node traverses

114
 around the waypoint region with a (4 meter radius) to determine the static node. After
a given timeout, if a connection is still not established, the mobile node navigates the
next mission waypoint. The CIRCLE mode is part of the open-source software algorithm
that has been used in the flight controller [7]. For more information on working of the
Aerial-network protocol, please consult Chapter 10. If the data transaction is successful,
the data meant for node pi1 is received by the mobile node, through DTN’s epidemic
routing.
3. Travel to waypoint 2, and take a video footage.
4. Travel to the next waypoint 3, and send the data (data.jpg) meant for node pi1, if available.
5. Return to the where it started from. When the mobile node returns to its home location,
it forwards the video previously taken at waypoint 2 to node ubuntu.
6. The mobile node lands itself safely.
More complicated scenarios can be generated by using XML configuration with more nodes in
the network, please refer to Chapter 10.

Figure 11.7: The scenario tested during waypoint navigation. A total of three waypoints are
planned.

11.4 Results
The Figure 11.8 shows the measurement of link quality (ETX metric) as determined by the
mobile node. This is the result with the experiment of the waypoint navigation and networking,
discussed in this chapter. The figure is sufficiently annotated for the reader to understand. The
sudden disappearance of the ETX measurement in the figure, indicates the multicopter going
out of range of the networking zone. The interpretation of the results are as follows:
1. The multicopter (mobile node) is started at time 0. At this time, the OLSR is triggered
and takes time to bring down the ETX value. The mobile node takes off at the 13th
second. There is a slight glitch in the ETX parameter since the mobile node flies upwards
and worsens the link quality temporarily. The static node is already active and tries to

115
 Figure 11.8: Measured link quality (ETX) during the waypoint network navigation.

send the data.jpg file to the mobile node as soon as the network allows. The mobile node
receives this file at approx. 25th second.
2. At waypoint 2, the video is triggered by the camera and the footage is taken as planned,
for 30 seconds.
3. The mobile node navigates to waypoint 3 where it completes the transaction and transfers
the file data.jpg, in a short duration.
4. The mobile node now travels back to the base, waypoint Home, where it is expected
to transfer the video footage taken at waypoint 2. It gets interesting at approx. 110th
second, where the node encounters a poor link quality. The mobile node descends down
by reducing its altitude by half. It waits to gain a better link quality. It is seen that to
transfer a video file from a height of 7.5 m, it took approx. 122 seconds to complete.
The results present an objective analysis of the success of the transactions with the designed
algorithms. The files are received by its respective nodes, shows the working concept of DTN
with the application of mobile nodes in MANETs. The ETX measurements are carried out on
the mobile node and gives us sufficient information on the behaviour during network navigation.
The tests are conducted with a horizontal antenna orientation.

116
Chapter 12

Analysis of Interferences

In this research, the multicopter integrates several on board wireless devices each serving a
different purpose. All these devices, as per wireless regulations, require to operate in a narrow
band of frequencies. The on-board wireless devices all being active at the same time, can be a
potential cause of mutual interference or interference with surrounding wireless devices in the
environment. The result of this interference can be dangerous and can lead to indeterministic
navigation characteristics that is hard to debug and resolve. This chapter studies the operat-
ing frequency of each of these devices, discusses the interference problems faced and suggests
methods incorporated to mitigate these interference effects.

12.1 Wireless devices on multicopter

Each of the devices listed below are present on the multicopter.

Figure 12.1: The four wireless devices used on our multicopter. Top left: TP-Link WiFi (2.4
GHz); top right: 3DR telemetry (900 MHz); bottom left: FlySky RC receiver (2.4 GHz); bottom
right: u-blox GPS receiver (1.575 GHz).

1. RC receiver operates at 2.4 GHz for receiving (manual) control signals from the hand held
user transmitter. The RC receiver also receives the command to switch to autonomous
mode from manual control, and vice-versa.
2. WiFi wireless adapter runs at 2.4 GHz as per 802.11 b/g/n standards. This module is
used for communication with other nodes in the mesh network (in ad-hoc mode).

117
 3. Telemetry operates at 433 MHz as per EU standards. This device is used for long distance
(upto 1 mile) directional communication between the GCS and the multicopter. The GCS
is the software that runs on a laptop, tablet or mobile phone to stream real-time data
from the multicopter and issues commands during flight.
4. GPS receiver operates at its carrier frequency of 1.575 GHz. GPS receivers are sensitive
devices with received power of approx. 10−18 W.
In general, it is a practice to use an RC receiver on all multicopters. The GPS is an accessory
that assists in autonomous navigation. The telemetry is not mandatory, it is used to establish a
two-way communication between the multicopter and GCS to keep track of the vehicle during
navigation. The WiFi on the other hand, is used for networking. Figure 12.1 shows the four
devices used on board.
Each of these devices emit and/or receive electromagnetic (EM) waves in their designated
frequencies. The powerful emissions from these devices can create electromagnetic interference
and degrade performance of other sensitive wireless devices operating at nearby frequencies.
The challenge is to study the possible interferences that can be created when using all these
devices at the same time. Also, it is a good practice to narrow down on potential problems as
much as possible before the actual flight.

12.2 Understanding power scale

All wireless devices operate around their center frequency having certain power. An interference
occurs when different signals at same or nearby frequencies interference with each other. A high
Signal-to-noise ratio (SNR) for a signal is desirable, to minimize this interference. It is essential
to understand the power scale when studying wireless interferences. The power as we know
is measured in Watt (W). When measuring radio frequency, or RF power, it is often easier to
measure the power level as comparison between two levels. Decibel (dB) is the unit used to
express relative differences in signal strength whereas, dBm or decibel-milliwatt is the power
measured in decibels relative to 1 milliwatt (mW). The relation of dBm to watts is given
by:
Power in mW
dBm = dB milliwatt = 10 x log10
1 mW

The RF equipments including signal generators and spectrum analysers have calibrations in
dBm or dBW. The power level measured for usual applications varies in the range of megawatts
(106 watts or 100 dBm) for radar applications to attowatts (10−18 watts or approx. -130dBm),
the received power in GPS receivers. The Table 12.1 summarizes the power level encountered
in various applications we see from day to day life.

118
 dBm level Power Encountered In
100 dBm 10 Megawatts Power used in radar transmissions. This can cause serious injury
80 dBm 100 kilowatts Typical transmission power of FM radio station (50-km radius)
60 dBm 1 kilowatt Combined radiated RF power of microwave oven elements
30 dBm 1 watt Typical RF leakage from a microwave oven, (maximum) power
radiated from an amateur RC transmitter
20 dBm 100 milliwatts Maximum radiated power for IEEE 802.11b/g wireless modules in
the 2.4 GHz (e.g. WiFi wireless adapter)
0 dBm 1 milliwatt Bluetooth standard (Class 3) radio, 1 m range
-20 dBm 10 microwatts Observed maximum received signal power of wireless networks
-30 dBm 1 microwatt -
-60 dBm 1 nanowatt The Earth receives one nanowatt per square metre from galactic
stars of defined magnitude
-80 dBm 1 picowatt Maximum radiation allowed by regulations is in the range of (-60
to -80 dBm) [38]
-111 dBm 8 femtowatt Thermal noise floor for commercial GPS single channel signal
bandwidth (2 MHz)
-127 dBm 127 attowatt Typical received signal power from a GPS satellite

Table 12.1: Power level in dBm and its applications. Source: [Wiki] reference, as on 20-Dec,
’13

Some considerations

From the table above, it can be inferred that in the 2.4 GHz band we use two on board wireless
devices. The RC transmitter radiates power upto 30 dBm whereas, the WiFi wireless adapter
radiates power upto 20 dBm. The power radiated by an RC transmitter can be upto 10 times
greater than that of the WiFi device. If both these devices were to operate in the same channel
(or sub frequency within 2.4 GHz spectrum), the SNR of the WiFi signal would drop down
considerably. The signal strength is also affected with distance. The reverse effect, i.e. WiFi
affecting the transmitter’s signal can occur, when the multicopter’s distance results in a drop
in received transmitter signal strength.
The telemetry operates in the 900 MHz frequency band. As there are no other device on board
to interfere at this frequency, this should not be a cause of concern.
An interesting problem encountered during this research is the interference of the Raspberry Pi
camera with the GPS receiver. This problem is dealt with in Section 12.3.2. In the following
sections, we focus on the study of 2.4 GHz band devices and the 1.575 GHz band, where the
GPS receiver operates.

12.3 Frequency bands

12.3.1 2.4 GHz spectrum

As per the 802.11 standard, the 2.4 GHz band uses radio frequencies in the range of 2.412 -
2.484 GHz. The standard splits up this band into a set of 13 unique channels numbered 1-14.
Each of these channels are spaced 5 MHz apart in the 2.4 GHz range. Please refer to the section
on channel selection in Chapter 6.
The multicopter in this research, operates two devices in the same 2.4 GHz spectrum. One is the

119
WiFi wireless adapter operating on a designated channel as per our ad-hoc mode configuration.
The other device operating in the same band, is the RC receiver that receives control signals
from a remote hand held RC transmitter. Precaution must be taken against interference while
operating these two devices together in a small enclosed space.
In the initial stages, a low cost transmitter available locally was used for testing. While using
both WiFi and RC receiver, resulted in intermittent reset of the hand held RC transmitter.
The reason at first, was not apparent, but a close analysis revealed the problem being the
interference between the two.
Once the problem was clear that it occurred due to the use of both devices together on board,
solution had to be found to mitigate this unwanted effect. To minimize the probability of
interference on this band there are two possible options:
• Choose a different channel on which WiFi module operates in order to avoid interference
with the RC receiver.
• Find a transmitter with suitable modulation scheme such that it minimizes the probability
of interference.
Selection of a suitable channel for the WiFi would in turn require to determine the channel
the RC transmitter operates on. The radio controlled transmitters often operates on a wide
band of spectrum. Attempt was made to change the WiFi channel used. However, this solution
could not be relied upon as interference still occurred, although less frequently. Moreover, the
transmitter that is used initially (not shown) had an internal transmitter module and lacked
the external connector for testing the frequency via spectrum analyser.
Another solution is to find an appropriate transmitter with a robust modulation scheme and
incorporates techniques to avoid interference. The next section discusses this selection.

Finding the right transmitter

There are various transmitters available on the market nowadays for a similar price range. The
RC systems operating in the 2.4 GHz spectrum work on a wide-band of radio spectrum with
a minimum of 1 MHz channel spacing. This is in contrast to to traditional narrow-band RC
systems, that operated between 27-72 MHz range with a 20 kHz channel spacing. In practice,
the narrow band signal is relatively easy to jam or intercepted as compared to wider band signal.
Multiple devices simultaneously operating in the same narrow-band will result in interference
and cause glitches or lock-outs.
Typically, the RC transmitters operating in the 2.4 GHz band use the Spread Spectrum(SS)
technology as a modulation scheme. Spread spectrum is a form of wireless communication
where the frequency of the transmitted signal is varied deliberately and/or the signal is spread
out over a larger portion of the radio frequency spectrum than strictly necessary. This makes
the signal more resistant to radio noise and interference. It takes up more space but this allows
for redundancy in data transmission. Moreover, the interference is allowed to affect a portion of
this spectrum while still succeeding in successful transmission. There are two variants of spread
spectrum used for digital signal transmission over the airwaves, in different transmitters:
• Direct Sequence Spread Spectrum (DSSS):
In DSSS, the signal transmitted takes up more bandwidth that the information signal
that modulates the carrier (or broadcast) frequency. Each DSSS channel bandwidth is
approx. 22 MHz wide and the information is thus, spread across the entire bandwidth in
this 2.4 GHz channel. This prevents interference from blocking out the entire signal.

120
 The DSSS makes the transmitter use wide spread of frequencies to send data to the
receiver. A DSSS system will not be affected adversely, when the strength of the WiFi
interferes with it. It can be argued that the WiFi signal may only block a small portion
of the signal being sent. At least, some of the signal from the transmitter will get through
to deliver the control inputs to the receiver on board.
• Frequency Hopping Spread Spectrum (FHSS):
In An FHSS system involves the transmitter and receiver to constantly change their oper-
ating frequency within the allowed limits of the 2.4 GHz band [39]. FHSS radio systems
work by constantly hopping between a number of frequencies thus, covering a whole range
of channels within this band instead of having a fixed frequency. Clearly, this makes a
FHSS system a difficult target for interference to hit. An FHSS based transmitter will
make the right choice.
Amongst the currently available 2.4 GHz spread spectrum systems, all use some form of DSSS,
while others such as Spektrum/JR, Futaba FASST and FrSky DJ systems use other techniques
to offer even greater protection from interference [39]. A better technology generally, also
means an increased cost. The 9 Channel FlySky transmitter with FrSky DJT 2.4 Ghz module
is carefully chosen for the use with the multicopter. This RC system offers a blend of DSSS
and FHSS. It adds to the advantage that not only is the signal spread across the whole channel
but also supports continuous hops from one channel to the other. Further, this system also
supports a fail safe1 Figure 12.4 shows some tests performed with a spectrum analyser to study
the wireless signal from the RC transmitter and the Raspberry Pi’s wireless adapter.
In Figure 12.2a, the FrSky DJT 2.4 GHz module is presented. The 9 different PWM channels
from the transmitter represent the information signal. This signal is modulated onto the 2.4
GHz carrier wave. For more information, please refer to Section 7.6 [Chp. 7].
Figures 12.2b and 12.2c shows the analysis with the spectrum analyser after connecting 2.4 GHz
transmitter module via the connector. It can be seen that there are several peaks that emerge
on the analyser. This is due to the frequency hop technique. The three peaks are seen together
on the spectrum analyser as it is unable to keep up with the switching speed of frequencies of
the RC transmitter. In practice, at any time instant, there is only one frequency hop that is
initiated.
The Figure 12.2d shows the 2.4 GHz signal from the wireless adapter connected to the Raspberry
Pi. The analyser shows the ad-hoc device working around the assigned frequency of 2.457 GHz
(channel 10).
1
A fail safe is a mechanism to take suitable action when exceptions occur. For example, when the multicopter
flies beyond the range of RC transmitter signal, the receiver fail safe kicks in. In such a case, the multicopter
can take relevant action such as return to origin using a GPS.

121
 (a) The RC transmitter module. Modulates the (b) Testing the RC transmitter (module) signal
9 channel PWM signals onto a 2.4 GHz carrier. on a spectrum analyser.

(c) Test with the RC transmitter. Analyser

shows the FHSS and DSSS in action. (d) Test of 2.4 GHz WiFi signal.

Figure 12.2: Using a spectrum analyser to study the DSSS, FHSS of the 2.4 GHz transmitter
and the 2.4 GHz WiFi signal from Raspberry Pi’s wireless adapter.

12.3.2 1.5 GHz spectrum

The satellites broadcast information on its two carrier frequencies, 1.57542 GHz and 1.2276
GHz. Only one of these is for the civilian use. The civilian carrier is 1575.42 MHz [40, Chp. 3].
A GPS receiver on earth, is used to receive signal from a number of satellites to determine its
position on earth. At least three satellites are required to determine the position of the GPS
receiver. The computation of a position with three satellite signals is termed as a 2D position fix
(two dimensional determination of position). By receiving signals from four or more satellites,
the GPS receiver is able to compute an absolute position in three dimensional space. A 3D
position fix gives us the altitude above the earth’s surface, in addition to latitude and longitude.
The greater the number of visible GPS satellites, the more accurate the position estimation will
be. We use the u-blox GPS receiver on the multicopter.
The Raspberry Pi’s camera and GPS receiver are installed on-board the multicopter. During
autonomous hover, the multicopter relies on GPS for an accurate 3D position estimation. How-
ever, it was noticed that when the camera was started for a videoshoot, the multicopter started
introducing bizarre behaviour and lead to several crashes, resulting in costly repairs. This prob-
lem was discovered by chance and for long, the source of this problem was not apparent as it
used to happen at odd times.

Determining source of the problem

As the first step to narrow down the problem, the camera was triggered during manual control
of the flight. It is noticed that the problem did not occur in such a case. Only in the case when

122
a hover is initiated (that uses GPS) and camera triggered during this duration, the unexpected
behaviour resulted. This problem is not found in the literature and was discovered by chance.
At this point, it was clear that there is an interference problem the GPS faces when using the
camera. The following reasonings were made to find the source of the problem:
1. Disproportionate current draws:
The camera and GPS both drew current from the same voltage regulator, that provides
3 A of current. This lead to the thought that this may minimize the current drawn
by the GPS receiver, being the reason of the bizarre behaviour. After looking at the
specifications of the Raspberry Pi camera, it is found that it draws 250 mA of current at
3.3 V, when triggered; specifications are found in [41]. The u-blox GPS draws upto 25
mA at 3.0 V. Thus, the assumption that the current drawn by the GPS is minimized may
be incorrect. Further, measures were taken to supply current to both these devices using
separate voltage regulators. It was noticed that there was no change in the behaviour
and the problem reoccurred. Thus, further steps were needed to root out the cause of the
problem.
2. Presence of interfering sources:
Another possible reason for this behaviour is attributed to the presence of sources that
emit power at frequencies used by the GPS carrier wave. However, this is difficult to
confirm since this behaviour does not occur without the on-board camera.
In the quest to find the source of interference, the data from the GPS is logged every second.
Tests were conducted at Thales Nederland B.V. laboratory with the GPS and camera, without
taking actual flight. When triggering the camera, a sudden drop of GPS satellite count resulted.
This showed a visible indication of interference. Moreover, this phenomenon only occurred when
the camera was oriented at a certain angle. Figure 12.3 shows the result from an actual flight
where the data is logged. The sudden drop of GPS signal down to zero, around the 5th minute,
resulted in sudden and bizarre flight maneuver; before triggering manual flight control to prevent
further mishap. A sudden drop of GPS satellite count to zero is highly unlikely and unusual
that can lead to bizarre consequences for a flying vehicle. This is a major cause of concern,
especially when using GPS and camera together on board.

Figure 12.3: Data collected during actual flight. The graph shows sudden reduction of GPS
satellite count at the time of camera trigger that resulted in a sudden bizarre flight behaviour.

The jamming source is found to be the camera ribbon cable that acts as an antenna with a
greater power near the GPS carrier frequency, overriding the GPS signal. It is also found that

123
the jamming signals are often caused by the harmonics of these spurious signals. Figure 12.4a
shows the interference found at the GPS carrier frequency, when the camera is triggered. Figure
12.4b shows a study conducted with a spectrum analyser to determine a noise source present
around the GPS frequency. This figure shows an example of a spurious signal emanating from
the camera module. The frequency of this spurious signal is found to be at 1.4284 GHz. The
power of this signal is at -48.19 dBm (i.e. -58.18 dBm plus 10 dBm of spectrum analyser
attenuation). In contrast, the GPS receiver captures extremely weak signal in the order of -127
dBm (127 attowatt), please refer to Table 12.1. It is interesting to note that the power of these
spurious signals is about 109 times greater than the signal GPS receives from satellites. The
reader must take notice that there are other spurious signals that emanate around 1.575 GHz
(not shown), that cause the actual interference with the GPS receiver.

(a) Jamming of GPS receiver signal by nearby noise sources.

(b) The camera introduces about -40 dBm of spurious sig-

nals that overpower the GPS receiver.

Figure 12.4: Using a spectrum analyser to study the interference due to the camera.

Minimizing the interference

With the technology available today, for a vehicle to navigate autonomously, has to rely on the
GPS for position accuracy and for navigation of waypoints. The jamming of a GPS receiver
with or without intention even for a fraction of second can cause trouble for the vehicle to keep
up with its correct position. The jamming of GPS receivers with drones is not a well studied
area and not much can be done in order to prevent it. There are two ways to mitigate this
problem. One of these is to shield the camera cable with a suitable material forming a faraday
cage. The other is to build an algorithm in software, whereby, if the number of visible satellites
drops significantly lower than a threshold, the vehicle decides to land or keeps hovering until
the GPS signal is restored.

124
 (a) Camera ribbon cable acts as a half- (b) The source of interference is
wave dipole antenna. RF field only for shielded by a special copper tape and
illustration purposes. grounded.

Figure 12.5: Measures taken to minimize the interference created from the camera ribbon cable.

1. Shielding and cable orientation:

Tests are conducted to determine the type of antenna the camera cable projects. It is
found to act as a half-wave dipole antenna, see Figure 12.5a. This understanding indicates
that the antenna can be placed in a certain orientation so as to minimize the interference
with the GPS.
Cable shielding is commonly used for signal and data cables. The design of cable shielding
and grounding is an important factor for the reduction of electromagnetic interference.
Figure 12.5b depicts the shielding of the camera cable, the determined source of interfer-
ence, with a special copper tape. This shielding keeps the RF (Radio Frequency) from
escaping the design. Further, the orientation of the camera with respect to GPS is chosen
such that the camera cable is kept perpendicular to the GPS receiver antenna. Tests indi-
cate that the intensity and power of the spurious signals have been reduced significantly to
at least approx. -110 dBm. As per the specifications of u-blox GPS receiver found in [38],
a u-blox 5/6 receiver can handle interference that is 25 dBm stronger, before suffering a
degradation of GPS signal by half. In other words, the u-blox GPS receiver can filter out
noise as long as the received signal is above approx. -100 dBm.
Although, measures are taken to mitigate the interference effects after close analysis. Our
conclusion is that the Raspberry Pi’s camera is the main cause of the interference. This
leads to the fact that this camera has not passed through all stages of EMC compliance
tests and use of the Raspberry Pi camera V.2 must be avoided in projects that may employ
this during outdoor navigation, when using civilian GPS receivers.
2. GPS lapse software protection:
As a safety precaution, a GPS protection mechanism is built in the source code. The
algorithm is built on the idea that whenever the position of the multicopter exceeds beyond
a defined radius, or when the acceleration exceeds a certain threshhold, the system detects
this lapse and forces the multicopter to land at the immediate spot. Only the function
for the lapse is presented in Algorithm 4. The function is computed each time the GPS
position is updated. If a lapse in GPS position is determined, based on the result of this
function, a relevant action such as to land is immediately initiated. The algorithm for
GPS lapse protection is presented below.

125
Algorithm 4 GPS lapse
Require: radius cm, max accel, time passed, dist cm, accel dist, curr gps, prevpos, now,
prev time, GP S3DF IX, gps, prev gps, gps lapse, allok
Ensure: gpslapse is set to false, prev time, gps, prev gps object are initialized, GPS3DFIX =
3, radius cm )in cm) and max accel (in sm2 ) are assigned a required value.
1: if gps.getstatus() ≤ GP S3DF IX then
2: gps lapse ← true [If there is no 3D fix] return
now = get curr time();
3: time passed ← now - prev time [Compute time since the last gps check]
4: curr gps.lat = gps.lat [Get current gps location]
5: curr gps.lat = gps.lon
6: dist cm = getdist cm(prev gps, curr gps) [Compute distance based on current estimate]
7: if dist cm ≤ radius cm then
8: allok ← true
9: else
10: accel dist = 12 * max accel * time passed2 [Find distance based on acceleration]
11: allok ← (accel dist ≤ max accel)
12: if allok then
13: prev time = now
14: prev gps.lat = gps.lat
15: prev gps.lon = gps.lon
return allok

126
Chapter 13

Extended Flight Times

The contemporary low-cost electric driven Micro Aerial Vehicles (MAVs) are limited by their
flight times. This limitation prevents them being used in useful applications. The flight time
is influenced by a lot of important details of the MAV and the flight conditions. The possible
flight time is influenced by factors such as selection of the battery, electronic equipment, the
mechanical design, motors and propellers. This chapter discusses the build and design of a low-
cost quadcopter aircraft that can hover for an elongated periods of time and reach 82 minutes
of continuous hover outdoors.
We begin with the motivation for this design, in Section 13.1. In Section 13.2, the various
factors that limit the flight time of the quadcopter is discussed. The component selection
for this design is detailed in Section 13.3. Further, in Section 13.4, critical analysis of an
unconventional method proposed to increase the flight time is discussed. The Lithium-ion as
an alternative energy source is presented in Section 13.5. Finally, the flight time results and
the efficiency of the system is given in Section 13.6.

13.1 Motivation
The main motivation of a new quadcopter design is the power analysis carried out in Chapter
9. It was shown that a medium-sized quadcopter such as the one used in this research that
weighs approx 1.5 kg. It consumes 235 W of power for hover, with a nominal battery voltage
of 11.1 V. This is the power required by most typical quadcopters. The flight times registered
with small to medium quadcopter designs that weigh 1-2 kg, are anywhere from 6 to 18 minutes
as per author’s experience. To achieve flight times beyond 20 minutes, by itself, is an aspect of
research that is in high demand in commercial industry, as well as in the military. Effort is spent
to analyse ways to reduce the power consumption for a quadcopter that weighs about 1.5 - 2
kg. The analysis is carried out by experimenting different components and energy source.
With commercially available quadcopters, two organizations have recently caught customer
attention. They have proposed increased flight times with their designs; the cost of these
designs however, vary greatly. A list of these manufacturers are given below:
• The turbo-ace-x830 from Turbo-Ace manufacturer, offers a flight time of 23-30 minutes
and states it as having the industry’s longest flight times for the given price [42]. This
quadcopter design costs $ 2,800.95.
• The Microdrones, a company from Germany supplies its quadcopter aircraft targeted
to the military and high-end consumers. They offer the md4-1000 quadcopter vehicle

127
 that provides upto 88 minutes of flight. This platform costs £40, 000; a statement from
Microdrones found in [43], is given below.
Depending on attached payload, battery and environmental conditions like wind
speeds and ambient temperature the system can achieve flight durations of up
to 88 minutes.
On the contrary, this research proposes a low-cost design analysis, targeted at improved flight
times. The author addresses several crucial parameters that lead to an improved flight time in
comparison to contemporary quadcopter designs. The vehicle used is an in-house development
of the author and weighs about 2 kg.

13.2 Factors affecting flight time

There are four main influencing factors that when put together affect the flight time, for any
multicopter aircraft design. These are the rotor swept area, energy density of power source,
take-off weight of the aircraft and the total efficiency of the system. In this section, we address
each of these factors one by one.
1. Rotor swept area: The swept area refers to the area of the circle created by the propeller,
as it sweeps through the air. The diameter of the propeller directly influences the amount
of air swept under it and thus, the power required by the system to produce this thrust.
During hover, the propellers move large volumes of air in a downward direction. This
pumping process uses lots of power and accelerates the air to relatively high velocities.
The air flow pattern due to a propeller rotation is illustrated in Figure 13.1.

Figure 13.1: Illustrates the induced air velocity below the propeller plane.

From [44], the equation of induced thrust power is given as:

(m · g)1.5
P =√ (13.1)
2·ρ·A

kg
where, ρ is the density of air [1.25 m 2 ],
A, is the rotor swept area (m2 ),
m, is the mass of the vehicle (kg),
g, is the acceleration due to gravity [9.81 sm2 ],
(m · g), thrust developed by the rotor blade (N)
A direct inference from the equation above indicates that the induced power is directly
proportional to the mass of the vehicle and inversely proportional to the area of swept

128
 blade; considering acceleration due to gravity and density of air to be constant. A heavy
quadcopter with smaller propellers need more power. To hover with a smaller amount of
power, it is required to have larger propeller blade. A low mass of the quadcopter leads
to reduced power required for hover.
The derivation of (13.1) is based on Bernoulli’s principle of air flow and mass flow rate1 .
The interested reader can refer to its derivation in [45, p.25].
2. Energy density:
Energy density is the amount of energy stored per unit volume or per unit mass. The
mass of the battery (mbattery ), is related to the energy density (E) by its specific power
J
(Sp )2 of the battery ( kg ):

E = mbattery · Sp (13.2)

The total flight time is dependent on the energy density of the storage cell. The total
flight time, T in terms of energy content of the storage cell (E) and power dissipated by
the aircraft (P), is given by the relation:

E
T = (13.3)
P

Cost/ Wh Energy density

Storage type
($) (Wh/kg)
Carbon-zinc 0.31 36
NiCad 1.50 39
Lead-acid 0.17 41
NiMH 0.99 95
Alkaline
0.19 110
long-life
Lithium
Polymer 0.24 70-120
(LIPO)
Lithium-ion 0.47 128-250
Fuel cells 2.25 500
Lithium
Thionyl 1.16 700
Chloride

Table 13.1: Classifications of available storage types in the industry. Source: [46], available
23-Dec-2013.

Table 13.1 presents the popular electrochemical storage technologies in use today. In
all state-of-the-art multicopter designs, LIPO (Lithium-Polymer) storage types are used,
since they are able to deliver extremely high continuous currents at higher voltages typi-
cally required by a multicopter. Apart from LIPO cells, the fuel cells and Lithium-ion cells
are especially interesting. The fuel cell is an upcoming technology. However, these are
1
Mass flow rate is the mass of air that passes down through the propeller plane, per unit time
2
Also referred to as the power density, is the ratio of the power available from a battery to its volume

129
 not considered in our study as they are not available for commercial sale. The available
fuel cell kits puts them out of reach of the consumers due to their high price. Further,
they are not feasible for high power applications such as a multicopter, that are power
hungry. The Lithium Thionyl Chloride cells have the most energy density of the order of
700 Wh/kg, however are suitable for extremely low power applications that require less
than 100 mA of continuous current.
On the other hand, Li-ion cells used in electronic devices such as mobile phone and laptops,
are considered in this thesis. They are not comparable to high current LIPO batteries,
but do have greater energy density. They may be able to provide sufficient power for
hovering if the individual cells are stacked up together and if the power requirements are
low. All the other cell technologies, listed in the table are not considered as they have
relatively less energy density.
3. Take-off weight:
It is a known hovering aircraft design principle that the power required to hover is non-
linear with the weight of the aircraft. This principle is clearly depicted with the Power vs.
Weight equation defined in [8]. The power P (in Watt (W)) required to develop a thrust
(i.e. lift capacity) T, expressed in Newton (N) is given by:

√
P ∝ T3 (13.4)
∼

For the graph of this relation, please refer to Chapter 7, under LIPO selection criteria.
It is clear that weight is one of the most crucial parameters that directly affects the
hovering capability. In typical quadcopter designs, the study of power required to hover is
often given less importance and focus is given more on reduction of weight. The motivation
in this part of thesis is to understand the power requirements of a typical quadcopter
design. The reduction of the power required to lift the aircraft will directly increase the
time of hover.
The power measurements done with the quadcopter that has been used throughout this
research, registers a hover time of 14 minutes. It requires 235 W of power with a current
consumption of 19 A at a registered battery voltage of 12.36 V. This is the minimum
power required to hover at approx. 0.5 m. For more details, please refer to Chapter 9.
The hover time and power required is typical of most quadcopter designs.
The effect of take-off weight is explained by Equation (13.4). It is preferred to have a
light structure, especially made with a carbon fibre or similar materials. A carbon fibre
structure is light weight as compared to an aluminium structure, yet sturdy. A number
of carbon fibre rods are used to construct the frame structure, for our build.
4. Total efficiency of the system:
In practice, it is not possible to achieve close to 100% efficiency for a system. There are
losses in the system caused by losses in the battery, electronics, motors and propellers.
We add all the losses in one efficiency factor, for the complete system [44], given by:

Tef f ective = η · T (13.5)

Where, Tef f ective represents the achieved practical flight time, T is the theoretically esti-
mated time and η is the efficiency factor that depends on the overall system.

130
The mass of the system can be split into mass of the structure itself and the mass of the battery.
From (13.1), (13.2) and (13.3), we obtain the following relation:

√ √
E E· 2·ρ·A mbattery · Sp · 2 · ρ · A
T = = = (13.6)
P (g · (mstructure + mbattery ))1.5 (g · (mstructure + mbattery ))1.5

Now, we estimate the relation between effective flight time vs. theoretical flight time. Consid-
ering the nominal cell voltage for LIPO, Li-ion cells to be 3.7 V and substituting the value of
kg m
density of air [1.25 m2 ], gravity [9.81 s2 ] in (13.5), results in:

√ capacity
Tef f ective Nrotors · drotor · Ncells · [mAh]
= 0.32 · η · mbattery 1.5 (13.7)
[minutes] ( mstructure
[gram] + [gram] )

The number of rotors (Nrotors , diameter of the rotors (drotor ), number of cells (Ncells ) and
storage capacity have been introduced into the equation, please refer to [44].
The above equation is generic that applies equally well to helicopters and multirotors. In [44],
the author has analysed different LIPO battery capacities to estimate the best possible capacity
to be used with small-sized quadcopters. In this research, we take a step forward and analyse
other energy sources that can be used on a quadcopter and its component selection.
It is clear by analysing Equation 13.7 that, with a propeller having a large diameter, the best
possible energy source, low weight of frame structure and efficient components (such a motors)
will contribute to the flight time enormously.

13.3 Selection of components

The construction of the quadcopter and the components chosen for the build are discussed
below.
1. Motors and propellers:
The most important criteria to address is the selection of motors and propellers.
(a) Selection of motors:
When selecting motors, the following specifications are taken into consideration:
• Kv rpm
v : Kv refer to the rpm constant of a motor. It indicates the number of
revolutions per second (rpm) that the motor will turn when 1 V (one volt) is
applied and no load is attached.
• Weight (g): The weight of the motor in grams.
• Maximum voltage (V): The maximum voltage that can be applied across its
ends.
• Thrust efficiency (g/W): This is the amount of thrust produced for a unit of
power. It is preferable to have a high value for this parameter.
• Other parameters such as maximum current, diameter, number of windings, no
load current, etc. are other parameters mentioned in the motor specifications.
The rpm constant of the motor, Kv, is the most important of all. It relates the
power output from a motor, or in other words the torque level of a motor. The Kv

131
 is determined by the number of windings on the brushless DC motor’s armature and
the strength of the magnets. A low Kv motor has more windings of thinner wire and
carries more volts at less amps. It provides high torque and is one of the reason why
such motors are used on RC planes. In small-to-medium sized quadcopters, high Kv
motors are used. High Kv motors have less windings of thicker wire that carry more
amps at low voltage and spin a smaller propeller at high speeds. With reference to
Equation 13.7, to use a propeller with a larger diameter, we need to choose a low Kv
motor.
The motors on the quadcopter seen in the earlier chapters in this thesis, uses a 850
Kv motor. For our new build, we narrow down motors that offer a lower Kv suitable
to large diameter propellers. For our analysis, the weight and thrust efficiency (g/W)
of three low kV motors have been analysed. This is listed in Table 13.2. From the
table, it is apparent that the 5010-14 DC motor model has a better thrust efficiency
and lower weight as compared to the others, see Figure 13.2a.

Brushless DC Thrust efficiency

Weight
Motor (g/W)
HQMod A4008 620Kv 112 g 11.2 (g/W)
HQMod A4008 530Kv 108 g 10,0 (g/W)
5010-14 360KV 99 g 12.1 (g/W)

Table 13.2: The motor model, weight of the motor and thrust efficiency (g/W) is listed. Tests
are done with 2.0 A of current draw with a 15-inch prop. Please note that the values vary
between manufacturers and may be inaccurate to some extent, [47], [48]

(a) 5010-14, 360 kV brushless DC motor (b) 17-inch props used on the
used on the quadcopter. quadcopter.

Figure 13.2: Illustrates the chosen 360 kV motors and propellers (not to scale).

(b) Selection of propellers:

The selection of propellers go in accordance with the type of motor selected. In
the market, the usual propellers vary from 10-14 inches. Larger diameter propellers
are not so common or widely used. For selection of the propeller, two criteria are
important:
i. Diameter: This is the tip-to-tip length of the propeller blade.
ii. Pitch: The pitch is defined as the distance travelled by one single propeller
rotation, in degrees.

132
 The pitch of a prop has a direct relation to the power consumption and torque
produced. A prop with low pitch number (such as 13 x 4, where 4 is the pitch),
generates more torque. Therefore, the motors draw less current. A low pitch prop is
suitable to our analysis, as one of our main requirements is reduction in power. On
the other hand, a higher pitch number (such as 13 x 8) means a slower rotation, as
it moves greater amount of air and uses more power, see see Figure 13.2b.
At the time of purchase, the largest propeller available in the market was 17-inch
propeller with a 4.4◦ of pitch.
2. Frame construction:
Carbon fibre is a light weight material that is sturdy in operation. It is used for many
quadcopter constructions and is not new. The frame construction involves placing together
four carbon fibre rods each with a 12 mm diameter to form the structure. The center
plate of the structure is printed using a 3D printer. The weight of the frame structure
(without electronic components and batteries), is approx. 220 g.

Figure 13.3: After the integration of all components on the carbon fibre frame.

3. Remaining components:
The other components such as ESCs used is 20 A, flashed with the Simon K firmware.
The flight controller board, GPS, wires and cable are bought separately and are same as
the one chosen for the primary quadcopter used at Thales Nederland B.V.

13.4 Power analysis

Power analysis is carried out on two different motor mount orientations. The idea is to analyse
the power consumed in different orientations.
1. Figure 13.4a shows the contemporary design employed by contemporary multicopter de-
signs. In this design, the motors lie above the plane of the frame.
2. Figure 13.4b, shows an unconventional design proposed by the author, where the motors
are mounted in an inverted fashion, i.e. the motors lie below the plane of the frame.
The power required for hovering is compared between the two designs in Figure 13.5.

133
 (b) The motor facing downwards. This is
(a) Normal motor orientation in contemporary an unconventional design that proposes to
designs. reduce the power consumption.

Figure 13.4: Illustrates the different tested motor mount orientations.

Figure 13.5: An unconventional design that reduces the power consumed for hover, due to
reduction in air drag on the quadcopter frame.

Interpretation of results

The results are very interesting due to the following reasons:

1. With all motors mounted inverted under the frame, the power required to reach the
hovering state is reduced. This is a direct inference from the fact that the drag on the
air frame is avoided when propellers are mounted below the air frame. This results in
approx. 11% reduction in power.
2. With this design, the vibration on the frame is minimized. This is again, because the air
drag on the frame due to the propeller is almost nullified. This statement in its practical
implication is true however, is yet to be verified with vibration analysis.

134
13.5 Energy source
Two sources of energy are tested with this new design. One of them is the standard LIPO,
5000 mAh, 11.1 V battery, already used in this project. This LIPO pack can provide 55 Wh of
energy.
The other source of energy is the Li-ion cell. The motivation for the use of Li-ion instead of
LIPO battery is that they provide a higher energy density and can provide sufficient current
if connected together in series and parallel combination. There are various manufacturers of
Li-ion cells and choosing the correct cell with the right specifications for our power requirement
is essential. The Panasonic ncr-18650 PF, Li-ion cell provide 3,400 mAh of current at 3.7 V,
nominal voltage. Figure 13.6 shows that when such Li-ion cells are connected together is a
5S-4P configuration, can provide upto 17 A of current at 14.8 V. This indicates that when these
cells are soldered together into this configuration will provide 273.8 Wh of energy.

(a) ncr-18650 PF, 3400 mAh, 3.7 V, Li-ion (b) 5S4P (5-Series, 4-Parallel combination
cells. to give 17,000 mAh at 14.8 V.

Figure 13.6: Illustrates the Li-ion cells, when connected in 5S-4P configuration, supplies enor-
mous power.

(a) The lithium cell 5S-4P pack, weighs

951 g. With 20 cells, each weighing 46 g. (b) Quadcopter carrying the Li-ion cell pack.

Figure 13.7: Putting together the Li-ion pack to be used on the quadcopter.

135
13.6 Flight time results
In this section, we compare the theoretical results obtained with the application of Equation
13.7 discussed earlier in this chapter. The practical flight time obtained is compared with the
theoretical results. This will help us compute the overall efficiency of the system of the new
carbon fibre build with separate energy sources. Figure 13.8 shows one of the practical tests
done with the new build outdoors.

Figure 13.8: An outdoor test flight. The flight is autonomous and locked in GPS mode. Note
that the motors are mounted in an inverted fashion.

• Configuration 1:
– Carbon fibre build
– Storage type: LIPO (Lithium-Polymer)
– Nominal voltage: 11.1V
– Battery current: 5000 mAh
– Energy (in Watt-hours): 55 Wh
– Weight of battery (420 g)
– Weight of the system (including battery): 1530 g
– Motors mounted inverted
– The number of cells used are 3
– Calculated flight time (without efficiency):
√
4 · 431.8 * 3 * 5000
0.32 ∗ = 70min (13.8)
(1110 + 420)1.5

where, 431.8 is the diameter of the propeller (17-inch) in mm.

Practical flight time: 35 minutes
Efficiency: η = 35 : 70 => η = 0.50

136
 • Configuration 2:
– Storage type: Li-ion (Lithium-ion)
– Nominal voltage: 14.8 V
– Battery current: 17,000 mAh
– Energy (in Watt-hours): ≈ 274 Wh
– Weight of battery (951 g)
– Weight of the system (including battery): 2061 g
– Motors mounted inverted
– Here, the number of cells used are 4, (4S-5P configuration)
– Calculated flight time (without efficiency):
√
4 · 431.8 * 4 * 17,000
0.32 ∗ = 202min (13.9)
(1110 + 951)1.5

Practical flight time: 82 minutes

Efficiency: η = 82 : 202 => η = 0.41

Interpretation of the results

The two configurations presented above provide us with different flight time estimates. This is
clearly seen due to the use of Li-ion cells. Both these tests are conducted in wind conditions of
about 10 kmph. An indoor test flight will certainly provide with an improved estimate for η, and
thus an increase in flight time. In reality, to achieve η close to 100% is not possible. However,
improvements can be made to the system in the area of aerodynamics, selection of a suitable
motor-propeller combination and better tuning of the control system. The equation 13.7 is
found to be very useful for validating the results as well as coming up with your own design.
The cost to build this system is approx. e 600 and provides flight time over 80 minutes, that
is atleast four times greater in comparison to contemporary quadcopters for a similar weight
range.

137
Chapter 14

Conclusions

The work on this master thesis has been very interesting and many lessons have been learned
along the way. In this chapter, the insights gained during the implementation and testing
process are described as possible additions to near-future technological applications. The future
of DTN with small-scale UAVs and extensions are also discussed, and some final conclusions
are drawn.

Combining the technologies

The time has come when terrestrial applications of DTN have started getting attention. DTN
is a fast growing technology and especially interesting from a military standpoint, as it makes
networks robust against temporary disruptions. It is interoperable with different existing com-
munication technologies such as between satellites, planes, mobile phones, etc. can all use DTN
irrespective of underlying implementation of other protocols. DTN can be used with or without
wireless networking. With advanced security features added to routing in MANETs and lower
layers, the use of DTN with ad-hoc routing becomes all the more useful and feasible.
The use of medium-sized multirotor vehicles are preferred to traditional helicopters, as they are
simplified in design, require less maintenance and offer a low cost solution. Furthermore, these
multirotors have a smaller diameter for each individual rotors to equivalent helicopter rotor,
allowing them to possess less kinetic energy during flight. This reduces the potential damage
caused in an accident. Multirotor is the solution for maneuvering challenging environments and
for safer interaction.
Various organizations such as NASA, Google and Amazon amongst others are taking advantage
of the multirotors for diverse applications. The applications include closed-circuit television ca-
pabilities to provide an eye in the sky to study activities below, nuclear sites surveillance, search
and rescue operations, goods delivery and filming. Going beyond the prescribed applications
with micro UAVs, also provide the opportunity to extend and improve the communications in
a multihop ad-hoc network, as addressed by this thesis.

14.1 Summary of contributions

• Extension with DTN
The IBR-DTN implementation of DTN provides a test bed to the user for testing the con-
cept of store and forward. It implements robust bundle management in its architecture
and supports transmission and reception of bundles as messages between two end points.

138
 However, there are situations where multiple end points are involved, such as in military
scenario and an algorithm is required to extend the existing use of basic end-to-end store
and forward. Complications creep in when scenarios involve inter-message dependencies,
multiple classes of tasks that need to be accomplished at different times. In this research,
an algorithm and protocol have been devised and implemented on embedded systems ad-
dressing these scenarios. Prior to devising this concept, several additions have been made
with IBR-DTN that improve the usability with applications. The additions address de-
coding of source information of the received bundle, timely bundle reception management
and ability to send multiple individual files as a single package from source to destination.
The algorithm is modular and object oriented and can be extended as required.
• Aerial-network protocol
This protocol complements the work done with the extension of DTN and existing work
on MANETs. It enables management of data received, stored and/or forwarded to its
future destination. Further, it is a protocol because it enables bidirectional communication
between sockets of the end points before and after data exchange, to ensure fair knowledge
of transaction of data. To fulfil the networking requirements for a given region, the
multirotor autonomously alters its navigation behaviour from simple hovering to change in
altitude based on the connection quality or circle around a given waypoint in an attempt to
find a static node. To achieve this, requires a good coordination between the autonomous
flying and the networking activities, which is addressed by the Aerial-network protocol.
• Multirotor hover
Several useful strategies have been shown to work to improve the multirotor hover to
sub-meter accuracy, with GPS. The importance of vibration control, magnetic field inter-
ference, controller tuning and using multiple sensors for improved stability are discussed.
• Flight times
With the current technology, flight time of the multirotor is considered as the number
one setback for applications requiring long duration flights. Many companies are looking
towards the realization of greater duration flights. The flight time for aerial platforms
have a non-linear relationship with its weight. It also depends on the energy source used
and the aerodynamic efficiency of the flight. The contemporary multirotors with a few
kilograms of payload hover for less than 20 minutes. To extend the flight times beyond
this limit is by itself, a challenging research aspect. In addition to the contribution to this
thesis, a new multirotor is hand designed with the aim to improve the flight times. The
design focuses on three unique aspects, i.e. mechanical component selection, energy source
selection and efficiency of aerodynamics to reduce the power required to hover. With this
new design, flight times of over 80 minutes have been achieved with autonomous flight.
The potential of this design can be enormous and leads us to explore applications such as
execution of long duration networking tasks.

14.2 Insights and conclusions

• Insights
1. In a practical setup, there is a need to study the interferences caused in the network.
The civilian drones use on-board wireless devices that operate at near-by frequencies,
as per the wireless regulations. The GPS is very sensitive to interference and plays
an important part in navigation. A close understanding of possible interferences is

139
 required to avoid potential catastrophic scenarios, leading to a crash.
2. To improve flight time of an aerial vehicle, effort is often invested in reduction of
its weight. This is an important aspect, however, selection of suitable components
based on its power analysis will reap great benefits. The analysis of aerodynamic
effects of your aerial vehicle will also improve its efficiency.
3. The ETX metric is extracted from OLSR, that represents the quality of the network.
This, when used in conjunction with a mobile node, can help to alter the navigation
characteristics to suit the networking requirements. This insight is found especially
useful.
• Conclusions
1. From the work presented in this thesis, it is found that DTN technology can be
integrated with a UAV. The extensions proposed to the current DTN design makes
it more flexible for use with mobile applications.
2. The Aerial-network protocol proposed and implemented in this thesis, successfully
brings together the concepts of MANET and DTN. It enables the autonomous net-
work transactions with a multirotor and alters its navigation behaviour based on
studied network parameters such as link quality. The protocol is carefully designed
to handle any given task, in a robust way.
3. The use of wireless networking with UAV requires the resolution of several interfer-
ence problems. Some of the problems caused when using it with an aerial robot are
analysed and measures are discussed to mitigate those effects.
4. It is determined that smarter multirotor designs are possible where the flight times
can be significantly extended by addressing certain design considerations such as
using different energy source, unconventional orientation for the motors and custom
chosen components. A gain of atleast 4X times in flight times is noticed, to the
contemporary multirotor designs available.

14.3 Future work

Wireless technology has already reached a mature state of development used by every one of us
everyday. The DTN technology is about to mark the future of applications that wish to tolerate
delayed networking needs or in extreme terrestrial environments where network infrastructure
may not always be available. In future, every military personnel in movement can be seen
to possess an ad-hoc node with DTN capability, for unscheduled discovery and peer-to-peer
communication whenever encountering each other within their range.
Currently, DTN is feasible on networks with large amounts of local storage and end-to-end
bandwidth relative to expected traffic. This inefficiency is outweighed by the shortened delivery
times taking maximum advantage of unscheduled forwarding opportunities. The development
of efficient routing algorithms in DTN such as PRoPHET1 routing based on probability of node
encounters and ORWAR2 that takes in account speed, direction of movement and radio range
amongst others, is in research.
The work in this thesis proposes extensions with DTN and an algorithm for aerial networking.
This algorithm uses these extensions by interacting with an autonomous multirotor to pursue
1
Probabilistic Routing Protocol using History of Encounters and Transitivity
2
Opportunistic DTN Routing with Window-aware Adaptive Replication

140
networking tasks. The algorithm is easily extendible and Quality-of-Service (Qos) extensions are
possible. This implementation may be found useful for applications requiring the use of DTN
technology. For example, an interesting work done in [12], on a swarm of UAVs interacting
together using DTN, can benefit with this extension.
With the rapid growth of small-sized aerial vehicles, its applications are in demand and awaiting
FAA clearance. With integration of additional sensors, the multirotor will act to be more
intelligent and able to perform tasks beyond our imagination. The future of swarm aerial
robotics with DTN technology will be very interesting. MANET will need to be used for fully
self configuring and secure solution to multi-hop forwarding data traffic.
In the end, the practical work done on increasing flight times over contemporary multirotors and
breaking that necessary boundary is achieved with this work. It points to us the importance of
correct design and where our focus must lie if the goal is to improve flight times. The analysis
done by testing an unconventional inverted motor placement is seen to improve the overall
efficiency of the system further, by 11%. This concept may be used in future work to improve
flight times further. The work done in this master thesis is a proof of concept that shows a
promise of further development in the field of application specific multirotors.

141
Appendix A

Hardware and Software Details

Hardware Components
Table A.1 shows the details of the various sensors and controllers used on each of the OSP’s
used for the multicopter platform.

Description Paparazzi Openpilot ArduPilot Pixhawk Mikrokopter

Dimension(mm) 51x25 36x36 66x40.5 40x30.2 44.6x50
Weight(g) 10.8 8.5 23 8 35
Processor STM32 F1a STM32 F1 ATmega2560 LPC2148 ATmega644
Speed(MHz) 60 72 16 60 20
Gyroscope MPU-6000 ISZ/IDC-500 MPU-6000 ISZ/IDC-500 ADSRS610
Accelerometer MPU-6000 ADX330 MPU-6000 SCA3100 LIS344ALH
Compass HMC5843 HMC5843 HMC5883L HMC5843 KMZ51
Barometer MS5611 BMP085 MS5611 BMP085 MPX4115A
a
The STM32 chips are grouped into related series that are based on the same 32-bit ARM processor core.

Table A.1: Main components used in OSP quadcopters. Citation: ([1],[18],[7],[17])

Sensors

All the OSPs (Open Source Projects) listed in the table use the primary two sensors for attitude
estimation 1 i.e. an accelerometer and a gyroscope in addition to a compass for heading and a
barometric pressure sensor for height estimation. For the accelerometer, four different chips are
used in the different OSPs. Three unique chips are used in case of the gyroscopes. Compass
is used to estimate the drift of gyroscopes and barometer pressure sensor helps estimate the
height of the copter. The details of the various components are discussed further in Chapter
7.
Out of the various sensor systems used, ArduPilot and Paparazzi use MPU-6000 chip; contains
integrated MEMS 3-axis accelerometer and MEMS 3-axis gyroscope integrated on a single chip,
with a dimension of ≈ 3.36mm3 [1]. It is designed for low power, low cost and high performance
requirements. Moreover, the chip also contains a Digital Motion Processor (DMP) that has
1
Attitude defines the body’s position or orientation in a 3-dimensional space, identified by pitch, roll and yaw
parameters.

142
inherent cost advantages compared to discrete accelerometer and gyroscope solutions as in
other OSPs. When using the internal sensor fusion processor of the MPU-6000, a significant
amount of the main controller board’s capacity is freed for processing other needs. Further, it
enables to take input from other sensors such as compass and barometer via I2 C bus, for sensor
fusion, without intervention of the main controller board. For compass and barometer chips,
most OSPs use similar chips.

Controller Board

A controller board interacts with various sensors and hosts the microcontroller. The Ardupilot
and Mikrokopter are based on Arduino and use the AVR 8-bit microcontroller whereas the others
are based on ARM 32-bit microcontroller. AVR boards are suited for real-time operations but
have relatively lesser processing power and memory as compared to its counterpart. With
arduino based boards, it is easier to prototype, set up and comes with rich set of device drivers
for sensors and actuators. If on-line image processing were a requirement, ARM based board
would prove to be a better choice due to higher processing capability. However, an external
interfaced board with AVR based board can be an option, otherwise.
It would be interesting to note that as of late 2013, ArduPilot project is merged with Pixhawk
project, that gives the versatility of Ardupilot’s OSP in addition to the processing capability of
Pixhawk that supports real-time computer vision.

Software Features
Table A.2 depicts the overall software configuration that can be set up for each of the OSPs.

Functionality Paparazzi Openpilot ArduPilot Pixhawk Mikrokopter

Attitude estimation NCF EKF NCF EKF LCF
Waypoint Navigation X ∆ X ∆
Computer vision X
GCS provided X X X X
Airframe design X X

Table A.2: OSP software possibilities. X: Supported libraries, ∆: Partially supported, Citation:
[1]

Attitude Estimation

Each of the OSP implements its own attitude estimation algorithm as seen from Table A.2.
Due to the very nature of accelerometer that is susceptible to noise and gyroscope sensors
that are susceptible to gradual drift due to integration over discrete time samples and due to
temperature change, the sensor data from the individual sensors do not perfectly reflect the
rigid body’s orientation (further explained in Chapter 8). In order to overcome the limitations
imposed by individual sensor readings, the data from these sensors are mixed or merged together
to minimize the errors to get close to the true attitude estimates for the orientation of the rigid
body. Different implementations exist for attitude estimation such as using Extended Kalman
Filter (EKF), Linear Complementary Filter (LCF) and Non-linear Complementary Filter (NCF)
based on certain trade-off between them. Below, we give a very brief overview of the strategies
involved; the interested reader is suggested to refer to the citations given alongside.

143
 • Extended Kalman Filter (EKF):
A Kalman filter is used for measurements observed over time, containing noise and other
inaccuracies, and to predict values that tend to be closer to the true values of the mea-
surements. It is based on weighted average filter of the predicted value and the measured
value. The most weight is assigned to the value with the least uncertainty. This is a
widely used filtering strategy in space and military technology. For the linear system,
linear Kalman filter is applied and for the non-linear system, Extended Kalman Filter
(EKF) is used. The EKF model, linearizes the non-linear models such that the tradi-
tional linear Kalman filter can be applied thereafter. However, it has been observed to be
difficult to tune the filter and application of Kalman filter to non-linear systems can be
difficult in practice. Kalman filters are responsive to vibrations but are computationally
power hungry to be run on a dedicated microcontroller[49].
• Linear Complementary Filter (LCF):
This strategy employs the use of low-pass filters to filter out high frequency noise from
the accelerometer (such as during sudden movement or vibration) and a high-pass filter to
filter out low frequency signals (such as drift from gyroscope). By combining these two fil-
ters, a reliable estimate comparable to an EKF can be obtained without the complications
of a Kalman filter[50].
• Non-linear Complementary Filter (NCF):
The name of this filter is due to the structural similarity with the linear complementary
filter. This filter just like LCF, relies vastly on the gyroscope sensor for the rigid body’s
orientation and uses the accelerometer vector to provide a better attitude estimate. In the
Non-linear complementary filter, it makes use of a PI (Proportional-Integral) controller
closed feedback loop between the measured attitude value and desired attitude value,
to minimize the attitude error obtained. This results in a more accurate and smoothed
attitude data. From the estimated vector that is obtained, the pitch, roll and yaw can be
derived mathematically. Please refer to [51] and [34, p.3] for more details.

Controller Evaluation

In [1], five quadcopters are built using different OSP’s namely, the Paparazzi, ArduPilot,
Mikrokopter, MultiWii and KKMulticopter.
Amongst these, Paparazzi, ArduPilot and MultiWii share the same controller model with a
complementary filter. For qualitative evaluation, markers are mounted on the quadcopter to
acquire ground-truth data 2 using Vicon Motion Capture System that offers milli-meter resolution
of 3D spatial displacements, see Controller Evaluation in [1, p.43].
The desired angles are sent to the quadcopter by the user and the quadcopter attitude from
the Vicon and transmitted signals are recorded simultaneously. The attitude tracking result is
shown in FigureA.1. It is found that the ardupilot’s attitude response when tested with ground
truth is found to be better than other state-of-the-art OSP controllers.

Ground Station Control (GCS)

A well developed GCS is essential to study the vehicle’s behaviour via serial USB or wireless
telemetry. It was found that Ardupilot and Openpilot have features such as script support
for waypoint mission planning, google maps integration for waypoint navigation that can be
2
Ground truth: It refers to the process of gathering proper objective data for a test conducted.

144
Figure A.1: Attitude tracking response of a quadcopter. Ardupilot based controller is found to be
more accurate than other OSP controllers, based on ground-truth. The delay between reference
and measured signal is due to the communication delay, Reference: The desired angle, Roll,
Theta: Measured attitude of the quadcopter by Vicon, Source:[1]

extended by user and support on different Operating systems. Figure A.2 displays a screen shot
taken from various GCS shown only for completeness.

Figure A.2: A screenshot of Ground station control available for different OSPs, (a) Paparazzi,
(b) Openpilot, (c) Ardupilot, (d) Pixhawk, (e) Mikrokopter

145
Appendix B

Networking Principles

OSI Model Overview

In 1970s the International Standards Organization(ISO) developed an abstract description for
network protocol design called Open Systems Interconnect(OSI). This started as an effort to
standardize network communications between diverse applications and equipment, is a reference
model that describes how protocols should interact with one another. The OSI is a seven layer
model, in which each layer serves a unique purpose. The solutions offered by one layer do not
conflict with other layers thus, limiting complications between the layers. The Internet protocol
stack(TCP/IP), a five-layered model is an implementation of a computer networking protocol
suite derived from the OSI model.
Figure B.1 shows the sending and receiving systems, also called end points. In order to get data
running from a device running application A to a device running application B, the data needs
to descend the layers of the former and then ascend the layers of the latter(the layers are also
called, the IPS or Internet Protocol Stack)[52].
The upper layers deal with application related issues and implemented in software. The lower
layers carry out the transportation of data[53]. The data link and the physical layers are
implemented in hardware and firmware level. The lowermost layer, the physical layer, is closest
to the physical medium (such are ethernet cable, wireless medium) and places data on the
medium. Each layer adds its own headers and trailers over the raw data at the sending side and
these headers and trailers are stripped off at the receiving end by respective layers to retrieve
the actual data. The functions of each layer and associated protocols prescribed within these
layers are described.
• Layer 7 - Application
The application layer is at the highest level in the OSI hierarchy and is closest to the
end user. The application layer offers services to support the user interfaces, email clients
and file access. The file transfer mechanism between computers is an important function
initiated at this level. Examples of protocols at this level are FTP, Telnet and HTTP
amongst others.
• Layer 6 - Presentation
This layer is where application data is either packed during transmission or unpacked after
reception. Since different computers use different formats, this layer manages the proto-
col conversions, encryption/decryption and compression based on a standard format[52].
Protocols at this layer are ASCII, EBCDIC, JPEG, etc.

146
Figure B.1: The OSI standard is followed for network communication across all vendors.

• Layer 5 - Session
In order for computer systems to communicate with one another reliably, the session layer
opens, uses and closes the communication link using so called sessions. For instance,
during a file transfer a check point may be inserted in its transmission, to keep track of
the data transfer. In case of a disconnection, the file transfer may proceed from where
it was interrupted. This is an important layer for E-commerce websites that work on
dedicated user sessions [52, Pg.2]. Protocols used by this layer are SQL and RPC.
• Layer 4 - Transport
This layer provides a transparent transfer of data between the end systems. The data
received from session layer is broken into data packets before handing it onto the network
layer. At the destination, the data packets are combined back to their original state.
The Request for retransmission occurs at this layer where packets that have been lost or
damaged during transfer are resent. Two protocols that play a major role at this level are
namely, UDP and TCP. The TCP is connection-oriented ; the end points need to establish
a connection prior to transmission. It keeps track of the packet delivery order and resends
a packet when failure occurs. On the other hand, UDP is a connectionless communication
and does not guarantee packet delivery between end points. UDP is relatively faster for
sending small amounts of data since no connection set up is required.
• Layer 3 - Network
The network layer deals with the switching and routing of packets from source to desti-
nation and provides the best path to do so. There are usually two ways in which packets
are routed. Static routing, is where the route through the entire network is not changed,
whereas dynamic routing changes the path for the packets in order to avoid bottlenecks

147
 (i.e. due to network traffic). The routers work at this level, Figure B.1. Protocol examples
at this level are the well know IP(Internet Protocol), ICMP, ARP.
• Layer 2 - Data Link
At the data link layer all data packets are encoded and decoded into bits. This layers
is further divided into Media Access Control(MAC) and Logical Link Layer(LLC) layers.
The former is responsible for moving data packets to and from one Network Interface
Card(NIC) to another across the physical medium . The latter controls frame synchro-
nization, flow control and error checking.
• Layer 1 - Physical
The physical layer is the lowermost layer of the OSI model and defines the physical and
electrical characteristics of the network[52]. The bit stream is converted into an electrical
or radio signal and provides the hardware means to send or receive these signal on a carrier
medium. Examples of protocols at the physical layer are Fast Ethernet, RS232 and ATM
protocols.
It is important to note that most protocols in day to day use a slightly different version of
OSI model. In TCP/IP mode of the Internet for example, uses a 5-layer model than a 7-layer
model[52, Pg.1].

Lossy Links

Figure B.2: An experiment conducted when an obstacle is brought in between two nodes, spo-
radically. It can be seen the data rate is affected due to packet loss.

Figure B.2 depicts the data rate and signal-to-noise ratio(SNR) during communication between
two ad-hoc nodes. The circles marked in the figure, are instances when an object is brought in
front of the node affecting its data rate. A similar effect is seen with a decrease in SNR (though
not very apparent in the figure). A 3 dB drop in signal is equivalent to half the signal strength
being lost.

148
Appendix C

Complete Network Configuration

This appendix covers the installation and configuration for networking and is a follow up of
Chapter 6. The Section C lists the various tools used for network analysis and troubleshooting.
The set up of OLSR and IBR-DTN are explained in Section C and C along with the listing
of their configuration files, respectively. This setup is common across systems (MIPS, ARM or
x86 based) with any linux based operating system. The installation required on the Raspberry
Pi is explained in Section C.

Networking tools
1. Eclipse platform: As all of the networking in this project is established on linux based sys-
tems, we use the Eclipse platform for programming in the C++ and Python environments
(Python uses PyDev plugin on Eclipse).
2. Wicd Network Manager : A preferred tool to switch between ad-hoc mode and Infrastruc-
ture mode on your linux distribution.
3. Airmon-ng, Aircrack-ng: These two tools come in pair and allow to study all the other
wireless devices in all channels in the vicinity, as seen by the current wireless chipset. In
addition, it displays the MAC address, signal strengths, beacon information and other
network parameters of interest. This is achieved by using the monitor mode on wireless
interfaces. Further, they also indicate all the processes that interact with the (wireless)
interface on a node (in our case WLAN).
4. Wireshark : Wireshark is a popular network protocol analyser used on Linux. The packet
information between the various nodes in the network can easily be studied with it and
comes in handy during network troubleshooting.
5. Win32diskimager : This tool is used as an SD card backup Image utility (v0.8-binary) on
Windows 7 platform.
6. Ibrdtnd : Ibrdtn is the name of the group that has created a usable package using the
’Disruption Tolerant Networking’ concept. This is a daemon (process) that is run in the
background on every node for node discovery and bundle exchange. The source can either
be compiled or binaries can be used directly. It is however recommended to compile
the latest source directly due to binary revision mismatch available for different linux
distributions.
7. minicom: A tool to analyse serial data from the flight controller on ad-hoc nodes.

149
 8. Python package: Install py-serial, a package on python to enable serial communication.
The installation can be done directly on the Raspberry Pi via terminal. More information
can be found in [54].

Ad-Hoc setup, step by step

For wireless ad-hoc setup, we use two tools, ifconfig and iwconfig.
• iwconfig: This facilitates the configuration of wireless devices using the Linux Wireless
Extension.
• ifconfig: This is a system administration utility in Unix-like operating systems. With the
help of a command line interface such as a terminal, we can configure, control or query
TCP/IP network interface parameters.
Open the linux terminal and edit the following:
sudo nano /etc/network/interfaces
Please follow the below steps for ad-hoc network setup:
1. Append this file with: iface wlan0 inet static
The other basic settings can be looked up from the table below to be appended following
the above command. For advanced settings, please refer to [55].

Parameter Notes
Set the static IP address of your device here. E.g,
address
192.168.10.50
This tells the current node on what other IP addresses can
netmask it reach to. For reaching other nodes in any subnet, set it
to 255.255.0.0
wireless-channel Set the channel you wish to be in, between channel 1-13
wireless-essid Set the network name of your device. E.g. ’mynetworkname’
wireless-mode To be in ad-hoc mode, set this to ad-hoc, without quotes
This is the access point. Set it to any hex value such as
wireless-ap
F2:34:A1:A7:BD:CE

Table C.1: Settings for ad-hoc network.

Note: Make sure the wireless-ap is manually edited. If it is not done manually, the device
driver will set it to auto. This can seldom create problems leading to sudden broken
connections.
2. Reboot your system, type: reboot
3. Attach your wireless adapter (Wi-Fi dongle). wlan* should be detected automatically.
By default, wlan0 is detected.
4. Open the linux terminal and type: ifconfig.
The user must be able to see the configuration with ifconfig for wlan0. Make sure to verify
the broadcast address. It should be X.X.255.255, suggesting that it can see all other sub
networks. For details pertaining to necessary steps to be taken while configuration such
as terminating processes, please follow Chapter chp:adhoc parallelly.

150
 5. With the linux terminal open, type: iwconfig.
The user must be able to see the edited settings reflected for the device. Make sure the
wireless channel and corresponding frequency are correct.
6. If the settings are done on multiple other devices, they should be able to ping each other.
Open a terminal and type:
ping [target-IP]
If the ping is successful, a one-hop ad-hoc network has been successfully established.
The next step is to install a MANET routing protocol such as OLSR used in this research.
Following this, the installation of DTN is detailed.

OLSR setup
OLSR is a daemon that discovers neighbouring nodes via single or double hops. It is an extension
of the standard ad-hoc routing protocol. In addition, the user can enable plugins that are used
to extend the OLSR functionalities. The backbone of OLSR is its configuration file (olsrd.conf),
that is referred to when the OLSR daemon is executed. In this section we discuss the steps to
install the OLSR and its plugin, either directly via binary or via source compilation on your
local system.

Install via binary

Installing the binary directly on your distribution is fairly straightforward.

• Direct install (for the available version with your linux distribution):
sudo apt-get install olsrd olsrd-plugins
Note: There have been minor noticeable backward version incompatibilities as the older version
on one node may not be compatible with a later version on another node. It may be suitable
to make sure to have similar or closer version for all nodes used in the network. This is
especially necessary if you are using different OS on different nodes. E.g. TP-Link router
running OpenWrt and your PC running an Ubuntu linux distribution.

Install via source

Please follow the below commands step by step, to install source code version and build it
on your local distribution. This would install both olsrd and its plugins. Open a terminal in
Ubuntu/ Raspbian:
1. mkdir /olsr src
2. cd olsr src
3. wget http://www.olsr.org/releases/0.6/olsrd-<version>.tar.bz2 [E.g. version at the time
of this writing was olsrd-0.6.6. Check Downloads page in [26], for your version number]
4. tar –strip 1 -xjf olsrd-<version>.tar.bz2
5. rm olsrd-<version>.tar.bz2
6. sudo apt-get install bison flex
7. sudo make build

151
Note: The cross compilation for Raspberry Pi is initially carried out, performed via Eclipse.
Lately, the OLSR provides direct source code that can be built for ARM architectures, making
it less time consuming.

Using OLSR

The OLSR uses a configuration file to read the user parameters and uses these parameters
during execution.
• OLSR configuration file: This is usually located by default in /etc/olsrd/olsrd.conf. The
user is allowed to set various parameters and tame it as per his needs.
• OLSR daemon: The OLSR daemon can be run like this:
root@pi1: $ sudo olsrd -f /etc/olsrd/olsrd.conf -d 1
The -d option specifies the level of debug, varies between 0 to 7.
The olsrd configuration file is listed at the end of this appendix.
Note: Administrative privileges may be required to run the commands. OLSR configuration file
is found to be slightly different for OpenWRT dedicated to routers and for other systems. Thales
already uses OpenWRT routers. Irrespective of this factor, the settings discussed are suited to
all systems. Please compare and make suitable changes, as necessary.

IBR-DTN setup
The IBR-DTN setup is similar to the OLSR, i.e. download via direct binaries or compiling the
source code directly.
There are some instructions and settings that the user requires to perform before successful
installation. All instructions to download binary or compile source for different distributions
are listed under [project-cm-2012-ibrdtn/wiki/download] in [56].
As of mid 2013, the instructions to compile the source code on ARM architectures is available
through the same link.

Using IBR-DTN

The IBR-DTN just like OLSR, uses a configuration file to read the user parameters and uses
these parameters during execution.
• IBR-DTN configuration file: This is usually located by default in /etc/ibrdtn/ibrdtnd.conf,
if direct binaries are installed. If the package is compiled via source, this path can be dif-
ferent. The user is allowed to set various parameters and tame it as per his needs.
• IBR-DTN daemon: The ibr-dtn daemon can be run like this:
root@pi1: $ sudo /etc/init.d/ibrdtnd
The process can be appended with the options such as start, stop and restart, before
execution. Please use –help, for more information.
• IBR-DTN tools: The tools used are DTNSend and DTNRecv. Their usage is already
discussed under Chapter 5.
The ibrdtn configuration file along with the script to run the daemon (minor tweaks are done
to eliminate the time-synchronization dependency) are listed at the end of this chapter.

152
Note: Administrative privileges may be required to run the commands.

Raspberry Pi setup
There are two installations performed on a Raspberry Pi. One of them is the installation of the
OS and the other is used for the set up of the camera. Further, a real-time clock is optional
(to use with DTN), interfaced with the Pi to enable it to keep track of the current time, even
when Pi is powered off.
1. Make sure to find the right SD card for the OS setup. Some SD cards may not be
compatible. Please refer to [41].
2. The OS needs to be installed on an external SD card. The Raspbian is a linux distribution
based on Debian platform and is considered stable. Please follow the instructions to install
Raspbian OS on Raspberry PI. The detailed instructions are given under the wiki section
of Raspberry Pi homepage, found in [41]. Raspberry pi camera setup: Please refer to the
extensive details of camera setup and usage, available online in [41], under Raspberry Pi
camera setup.
3. Real-time clock : The real-time clock is an external chip with its own battery (that can
last upto two years without replacement). It keeps track of the current time even when
Raspberry Pi is powered off.
(a) Obtain the source code for the real-time clock from [57], extract the zip and copy
the files to the Raspberry Pi’s SD card.
(b) The self-explanatory pin-out diagram with the Raspberry Pi is given in Figure C.1.

Figure C.1: Real-time clock interfacing with the Raspberry Pi.

(c) Compile the source by following these steps:

1. cc rtc-pi.c (This creates a file name a.out)
2. mv a.out rtc-pi (rename the file)
3. chmod +x rtc-pi (Give permissions)
4. Append sudo ./rtc-pi to the /etc/rc.local file. It starts the executable on boot up
to read the latest time.
To set the date and time on the real-time clock module, execute:
sudo ./rtc-pi CCYYMMDDhhmmss

(d) When using Raspberry Pi (v.2 board), the following modifications are done to rtc.c
code, for using GPIO pin 27 (GPIO pin number has changed compared to earlier
revision), found online in forums.

#d e f i n e SCLK OUTPUT ∗ ( g p i o+GPIO SEL2 ) &= 0xFF1FFFFFL

153
 #d e f i n e SCLK HIGH ∗ ( g p i o+GPIO SET) = 0 x08000000L
#d e f i n e SCLK LOW ∗ ( g p i o+GPIO CLR) = 0 x08000000L

(e) A pull up resistor may be required between DAT and VCC pins, see Figure C.1. A
10K resistor is suitable.

OLSR configuration

This is the OLSR configuration file, as used on all (Raspberry Pi) nodes. The changed settings
have been tabulated in Chapter 6.
###################################################
# v0 . 6 . 6 − MODIFIED OLSR CONFIGURATION FILE ,
BY SHYAM BALASUBRAMANIAN, THALES NEDERLAND B .V
###################################################
#
#
# o l s r . o r g OLSR daemon c o n f i g f i l e
#
# L i n e s s t a r t i n g with a # a r e d i s c a r d e d
#
# This f i l e was s h i p p e d with t h e d e b i a n o l s r d package
#

# This f i l e i s an example o f a t y p i c a l
# c o n f i g u r a t i o n f o r a mostly s t a t i c
# network ( r e g a r d i n g m o b i l i t y ) u s i n g
# t h e LQ e x t e n t i o n

# Debug l e v e l (0 −9)
# I f s e t t o 0 t h e daemon r u n s i n t h e background

DebugLevel 0

# I n t e r f a c e s and t h e i r r u l e s
# Omitted o p t i o n s w i l l be s e t t o t h e
# default values . Multiple i n t e r f a c e s
# can be s p e c i f i e d i n t h e same b l o c k
# and m u l t i p l e b l o c k s can be s e t .

# ! !CHANGE THE INTERFACE LABEL( s ) TO MATCH YOUR INTERFACE( s ) ! !

# ( eg . wlan0 o r e t h 1 ) :
#
# t h i s i s ( i n most c a s e s ) t h e o n l y c o n f i g u r a t i o n you need t o change

#I n t e r f a c e ” e t h 1 ” ” e t h 0 ” ” wlan0 ” ” wlan1 ” ” ath0 ” ” ath1 ”

I n t e r f a c e ” wlan0 ”
{

# IPv4 b r o a d c a s t a d d r e s s t o u s e . The

154
# one u s e f u l l example would be 2 5 5 . 2 5 5 . 2 5 5 . 2 5 5
# I f not d e f i n e d t h e b r o a d c a s t a d d r e s s
# e v e r y c a r d i s c o n f i g u r e d with i s used

# Modify t h i s a c c o r d i n g l y f o r Raspberry Pi
Ip4Broadcast 192.168.255.255

# IPv6 a d d r e s s s c o p e t o u s e .
# Must be ’ s i t e −l o c a l ’ o r ’ g l o b a l ’

# Ip6AddrType s i t e −l o c a l

# IPv6 m u l t i c a s t a d d r e s s t o u s e when
# u s i n g s i t e −l o c a l a d d r e s s e s .
# I f not d e f i n e d , f f 0 5 : : 1 5 i s used

# Ip6MulticastSite ff05 ::11

# IPv6 m u l t i c a s t a d d r e s s t o u s e when
# using global addresses
# I f not d e f i n e d , f f 0 e : : 1 i s used

# Ip6MulticastGlobal ff0e ::1

# Emission i n t e r v a l s .
# I f not d e f i n e d , RFC p r o p o s e d v a l u e s w i l l
# be used i n most c a s e s .

# Hello i n t e r v a l in seconds ( f l o a t )
HelloInterval 0.2

# HELLO v a l i d i t y time
HelloValidityTime 1.6

# TC i n t e r v a l i n s e c o n d s ( f l o a t )
TcInterval 2.0

# TC v a l i d i t y time
TcValidityTime 256.0

# MID i n t e r v a l i n s e c o n d s ( f l o a t )
MidInterval 18.0

# MID v a l i d i t y time
MidValidityTime 324.0

# HNA i n t e r v a l i n s e c o n d s ( f l o a t )
HnaInterval 18.0

155
 # HNA v a l i d i t y time
HnaValidityTime 108.0

# When m u l t i p l e l i n k s e x i s t between h o s t s
# t h e w e i g h t o f i n t e r f a c e i s used t o d e t e r m i n e
# t h e l i n k t o u s e . Normally t h e w e i g h t i s
# a u t o m a t i c a l l y c a l c u l a t e d by o l s r d based
# on t h e c h a r a c t e r i s t i c s o f t h e i n t e r f a c e ,
# but h e r e you can s p e c i f y a f i x e d v a l u e .
# Ol s r d w i l l c h o o s e l i n k s with t h e l o w e s t v a l u e .

# Weight 0

# I f a c e r t a i n r o u t e s h o u l d be p r e f e r r e d
# o r i g n o r e d by t h e mesh , t h e Link Q u a l i t y
# v a l u e o f a node can be m u l t i p l i e d with a f a c t o r
# e n t e r e d h e r e . In t h e example t h e r o u t e
# u s i n g 1 9 2 . 1 6 8 . 0 . 1 would r a t h e r be i g n o r e d .
# A m u l t i p l i e r of 0.5 w i l l r e s u l t in a small
# ( bad ) L i n k Q u a l i t y v a l u e and a h i g h ( bad )
# ETX v a l u e .

# LinkQualityMult 1 9 2 . 1 6 8 . 0 . 1 0 . 5

# This m u l t i p l i e r a p p l i e s t o a l l o t h e r nodes
# LinkQualityMult d e f a u l t 0 . 8

# F i s h e y e mechanism f o r TC m es sag es 0= o f f , 1=on

LinkQualityFishEye 1

# i g n o r e t o p o l o g y i n f o r m a t i o n from nodes f u r t h e r than 3 hops away

#
# update t o p o l o g y i n f o r m a t i o n e v e r y 3 . 0 s e c o n d s
# ( on s l o w e r embedded hardware with more than 100 nodes u s e
something l i k e 9 s e c )

# COMMENT THIS FOR RASPBERRY PI Node

# LinkQualityDijkstraLimit 3 3.0

# IP v e r s i o n t o u s e ( 4 o r 6 )

IpVersion 4

156
# C l e a r t h e s c r e e n each time t h e i n t e r n a l s t a t e c h a n g e s

ClearScreen yes

# HNA IPv4 r o u t e s
# s y n ta x : n e t a d d r netmask
# Example I n t e r n e t gateway :
# 0.0.0.0 0.0.0.0

Hna4
{
# I n t e r n e t gateway :
# 0.0.0.0 0.0.0.0
# more e n t r i e s can be added :
# 192.168.1.0 255.255.255.0
}

# HNA IPv6 r o u t e s
# s y n ta x : n e t a d d r p r e f i x
# Example I n t e r n e t gateway :
Hna6
{
# I n t e r n e t gateway :
# :: 0
# more e n t r i e s can be added :
# f e c 0 : 2 2 0 0 : 1 0 6 : : 48
}

# Should o l s r d keep on r u n n i n g even i f t h e r e a r e

# no i n t e r f a c e s a v a i l a b l e ? This i s a good i d e a
# f o r a PCMCIA/USB hotswap environment .
# ” y e s ” OR ”no”

AllowNoInt yes

# TOS( type o f s e r v i c e ) v a l u e f o r
# t h e IP h e a d e r o f c o n t r o l t r a f f i c .
# I f not s e t i t w i l l d e f a u l t t o 16

#TosValue 16

# The f i x e d w i l l i n g n e s s t o u s e (0 −7)
# I f not s e t w i l l i n g n e s s w i l l be c a l c u l a t e d
# d y n a m i c a l l y based on b a t t e r y / power s t a t u s
# i f such i n f o r m a t i o n i s a v a i l a b l e

Willingness 7

# Allow p r o c e s s e s l i k e t h e GUI f r o n t −end

157
# t o c o n n e c t t o t h e daemon .

IpcConnect
{
# Determines how many s i m u l t a n e o u s l y
# IPC c o n n e c t i o n s t h a t w i l l be a l l o w e d
# S e t t i n g t h i s t o 0 d i s a b l e s IPC

MaxConnections 0

# By d e f a u l t o n l y 1 2 7 . 0 . 0 . 1 i s a l l o w e d
# t o c o n n e c t . Here a l l o w e d h o s t s can
# be added

Host 127.0.0.1
#Host 10.0.0.5

# You can a l s o s p e c i f y e n t i r e net−r a n g e s

# that are allowed to connect . Multiple
# e n t r i e s are allowed

#Net 192.168.1.0 255.255.255.0

}

# Wether t o u s e h y s t e r e s i s o r not
# H y s t e r e s i s adds more r o b u s t n e s s t o t h e
# l i n k s e n s i n g but d e l a y s n e i g h b o r r e g i s t r a t i o n .
# Used by d e f a u l t . ’ yes ’ o r ’ no ’
# Do not u s e h y s t e r e s i s with ETX!

UseHysteresis no

# H y s t e r e s i s parameters
# Do not a l t e r t h e s e u n l e s s you know
# what you a r e d o i n g !
# S e t t o auto by d e f a u l t . Allowed
# values are f l o a t i n g point values
# in the i n t e r v a l 0 ,1
# THR LOW must always be l o w e r than
# THR HIGH .

#H y s t S c a l i n g 0.50
#HystThrHigh 0.80
#HystThrLow 0.30

# Link q u a l i t y l e v e l
# 0 = do not u s e l i n k q u a l i t y
# 1 = u s e l i n k q u a l i t y f o r MPR s e l e c t i o n
# 2 = u s e l i n k q u a l i t y f o r MPR s e l e c t i o n and r o u t i n g

158
# Defaults to 0

LinkQualityLevel 2

# Link q u a l i t y window s i z e
# D e f a u l t s t o 10

#L i n k Q u a l i t y W i n S i z e 100

# Polling rate in seconds ( f l o a t ) .

# Default value 0.05 sec

Pollrate 0.05

# TC redundancy
# S p e c i f i e s how much n e i g h b o r i n f o s h o u l d
# be s e n t i n TC me ssa ge s
# Possible values are :
# 0 − o n l y send MPR s e l e c t o r s
# 1 − send MPR s e l e c t o r s and MPRs
# 2 − send a l l n e i g h b o r s
#
# d e f a u l t s to 0

TcRedundancy 2

#
# MPR c o v e r a g e
# S p e c i f i e s how many MPRs a node s h o u l d
# t r y s e l e c t t o r e a c h e v e r y 2 hop n e i g h b o r
#
# Can be s e t t o any i n t e g e r >0
#
# d e f a u l t s to 1

MprCoverage 1

# Ol sr d p l u g i n s t o l o a d
# This must be t h e a b s o l u t e path t o t h e f i l e
# o r t h e l o a d e r w i l l u s e t h e f o l l o w i n g scheme :
# − Try t h e p a t h s i n t h e LD LIBRARY PATH
# environment v a r i a b l e .
# − The l i s t o f l i b r a r i e s cached i n / e t c / l d . s o . c a c h e
# − / l i b , f o l l o w e d by / u s r / l i b

# C o n f i g u r a t i o n examples f o r p l u g i n s :
# s e e / u s r / s h a r e / doc / o l s r d −p l u g i n s / f o r some f o r documentation

159
LoadPlugin ” o l s r d t x t i n f o . s o . 0 . 1 ”
{
PlParam ” p o r t ” ”2008”
PlParam ” a c c e p t ” ” 1 2 7 . 0 . 0 . 1 ”
}

IBR-DTN configuration

This is the IBR-DTN configuration file for user settings. The changed settings have been
tabulated in Chapter 6.
# IBR−DTN daemon
###################################################
# v0 . 1 0 − MODIFIED IBR−DTN CONFIGURATION FILE ,
BY SHYAM BALASUBRAMANIAN, THALES NEDERLAND B .V
###################################################
#
# t h e l o c a l e i d o f t h e dtn node
# d e f a u l t i s t h e hostname
#
#l o c a l u r i = dtn : / / node . dtn

#
# s p e c i f i e s an a d d i t i o n a l l o g f i l e
#
#l o g f i l e = / var / l o g / i b r d t n / i b r d t n . l o g
l o g f i l e = /home/ p i / i b r d t n / i b r d t n . l o g

#
# timezone o f f s e t in hours
#
#t i m e z o n e = +1

#
# Limit t h e b l o c k s i z e o f a l l b u n d l e s .
#
# The v a l u e a c c e p t s d i f f e r e n t m u l t i p l i e r s .
# G = 1 ,000 ,000 ,000 bytes
# M = 1 ,000 ,000 bytes
# K = 1 ,000 bytes
#
#l i m i t b l o c k s i z e = 1 . 3G

#
# Limit t h e b l o c k s i z e o f f o r e i g n b u n d l e s .
# F o r e i g n b u n d l e s a r e not a d d r e s s from o r t o t h e
# l o c a l node .
#
# The v a l u e a c c e p t s d i f f e r e n t m u l t i p l i e r s .
# G = 1 ,000 ,000 ,000 bytes

160
# M = 1 ,000 ,000 bytes
# K = 1 ,000 bytes
#
#l i m i t f o r e i g n b l o c k s i z e = 500M

#
# Limit t h e o f f s e t o f p r e d a t e d timestamps t o a max v a l u e .
# Bundles with an i n v a l i d timestamp w i l l be r e j e c t e d .
#
#l i m i t p r e d a t e d t i m e s t a m p = 604800

#
# Limit t h e max . l i f e t i m e o f a bundle .
# Bundles with a l i f e t i m e g r e a t e r than t h i s v a l u e w i l l be r e j e c t e d .
#
#l i m i t l i f e t i m e = 604800

# l i m i t t h e numbers o f b u n d l e s i n t r a n s i t ( d e f a u l t : 5 )
#l i m i t b u n d l e s i n t r a n s i t = 5

# bind API t o a named s o c k e t i n s t e a d o f an i n t e r f a c e

#a p i s o c k e t = /tmp/ i b r d t n . s o c k

# d e f i n e t h e i n t e r f a c e f o r t h e API , c h o o s e any t o bind on a l l i n t e r f a c e s

#a p i i n t e r f a c e = any

# d e f i n e t h e p o r t f o r t h e API t o bind on
#a p i p o r t = 4550

#
# enable fragmentation support
# ( default is disabled )
#
#f r a g m e n t a t i o n = y e s

#
# i f f r a g m e n t a t i o n i s enabled , i t i s p o s s i b l e t o s p l i t up
# b u n d l e s l a r g e r than a s p e c i f i c l i m i t i n t o f r a g m e n t s
#
# l i m i t p a y l o a d = 500K

#
# Record t r a f f i c i n a l l c o n v e r g e n c e l a y e r s
# ( t h i s i m p l i e s a p e r f o r m a n c e drawback i f e n a b l e d )
#
#s t a t s t r a f f i c = y e s

#####################################
# storage configuration #
#####################################

161
#
# d e f i n e a f o l d e r f o r temporary s t o r a g e o f b u n d l e s
# i f t h i s i s not d e f i n e d b u n d l e s w i l l p r o c e s s e d i n memory
#
#b l o b p a t h = /tmp
#b l o b p a t h = /home/ p i / i b r d t n / b l o b s /
#
# d e f i n e a f o l d e r f o r p e r s i s t e n t storage of bundles
# i f t h i s i s not d e f i n e d b u n d l e s w i l l s t o r e d i n memory o n l y
#
#s t o r a g e p a t h = / var / s p o o l / i b r d t n / b u n d l e s
s t o r a g e p a t h = /home/ p i / i b r d t n / b u n d l e s

#
# d e f i n e s t h e s t o r a g e module t o u s e
# d e f a u l t i s ” s i m p l e ” u s i n g memory o r d i s k ( depending on s t o r a g e p a t h )
# s t o r a g e s t r a t e g y . i f c o m p i l e d with s q l i t e support , you c o u l d change
# t h i s to s q l i t e to use a s q l database f o r bundles .
#
#s t o r a g e = d e f a u l t

#
# Limit t h e s i z e o f t h e s t o r a g e .
# The v a l u e a c c e p t s d i f f e r e n t m u l t i p l i e r s .
# G = 1 ,000 ,000 ,000 bytes
# M = 1 ,000 ,000 bytes
# K = 1 ,000 bytes
#
l i m i t s t o r a g e = 500M

#####################################
# convergence layer c o n f i g u r a t i o n #
#####################################

#
# d i s c o v e r y o v e r UDP/ IP
#
# You can s p e c i f y an m u l t i c a s t a d d r e s s t o l i s t e n t o f o r d i s c o v e r y announcements .
# I f no a d d r e s s i s s p e c i f i e d t h e m u l t i c a s t e q u i v a l e n t o f b r o a d c a s t i s used .
#
discovery address = ff02 ::142 224.0.0.142

# S p e c i f y t h e t i m e o u t . I f no f u r t h e r d i s c o v e r y announcement i s r e c e i v e d
# f o r x s e c o n d s , t h e daemon assume t h a t t h e node has went away .
d i s c o v e r y t i m e o u t = 10

# u s e s h o r t IPND b e a c o n s
#d i s c o v e r y s h o r t = 0

162
# s p e c i f y t h e d i s c o v e r y mechanism t o u s e
# 0 = DTN2 c o m p a t i b l e d i s c o v e r y
# 1 = IPND v e r s i o n 0
# 2 = IPND v e r s i o n 1 ( d e f a u l t )
discovery version = 2

# To d i s a b l e d i s c o v e r y announcements , s e t t h i s o p t i o n t o z e r o .
# ( d e f a u l t i s 1)
#
#d i s c o v e r y a n n o u n c e = 0

# Enable c r o s s l a y e r d i s c o v e r y
# I f d i s a b l e d t h e daemon do not d i s t r i b u t e i t s own a d d r e s s e s v i a
# IPND . I n s t e a d we e x c e p t t h a t t h e r e c e i v e r e x t r a c t t h i s i n f o r m a t i o n
# u s i n g t h e s e n d e r IP a d d r e s s .
#
#d i s c o v e r y c r o s s l a y e r = y e s

#
# a l i s t ( s e p e r a t e d by s p a c e s ) o f names f o r c o n v e r g e n c e l a y e r i n s t a n c e s .
#
n e t i n t e r f a c e s = eth0

#
# Try t o c o n n e c t t o o t h e r nodes each x s e c o n d s .
# This o p t i o n k e e p s c o n n e c t i o n s up a l l t h e time .
#
#n e t a u t o c o n n e c t = 60

#
# D e f i n e s t h e i n t e r f a c e with g l o b a l i n t e r n e t a c c e s s . With t h i s d e f i n i t i o n
# t h e daemon can d e t e c t i n t e r n e t a c c e s s by i t s own and might assume s p e c i f i c
# nodes a s a v a i l a b l e o r u n a v a i l a b l e depending on t h e i n t e r n e t s t a t e .
#
#n e t i n t e r n e t = e t h 0

#
# c o n f i g u r a t i o n f o r a convergence l a y e r named l a n 0
#
n e t l a n 0 t y p e = tcp # we want t o u s e TCP a s p r o t o c o l
n e t l a n 0 i n t e r f a c e = eth0 # l i s t e n on i n t e r f a c e e t h 0
n e t l a n 0 p o r t = 4556 # with p o r t 4556 ( d e f a u l t )

#
# c o n f i g u r a t i o n f o r a convergence l a y e r named l a n 1
#
#n e t l a n 1 t y p e = udp # we want t o u s e UDP a s p r o t o c o l
#n e t l a n 1 i n t e r f a c e = e t h 0 # l i s t e n on i n t e r f a c e e t h 0
#n e t l a n 1 p o r t = 4556 # with p o r t 4556 ( d e f a u l t )

163
#
# TCP t u n i n g o p t i o n s
#
# NODELAY o p t i o n i n TCP d i s a b l e s t h e n a g l e a l g o r i t h m , i f s e t t o y e s ( d e f a u l t ) .
#t c p n o d e l a y = y e s

# The b u n d l e s a r e s p l i t i n t o chunks w h i l e they a r e t r a n s m i t t e d o v e r

TCP. This parameter d e f i n e s t h e s i z e o f t h e s e chunks ( 4 0 9 6 i s t h e
default ).
#t c p c h u n k s i z e = 4096

# The t i m e o u t f o r i d l e TCP c o n n e c t i o n i n s e c o n d s . 0 = d i s a b l e d
#t c p i d l e t i m e o u t = 0

#####################################
# P2P c o n f i g u r a t i o n #
#####################################

#
# D e f i n e t h e path o f t h e w p a s u p p l i c a n t c o n t r o l i n t e r f a c e
#
#p 2 p c t r l p a t h = / var / run / w p a s u p p l i c a n t / wlan1

#####################################
# routing configuration #
#####################################

#
# routing strategy
#
# v a l u e s : d e f a u l t | e p i d e m i c | f l o o d i n g | p r o p h e t | none
#
# In t h e ” d e f a u l t ” t h e daemon o n l y d e l i v e r s b u n d l e s t o n e i g h b o r s
and s t a t i c a v a i l a b l e nodes . The a l t e r n a t i v e module ” e p i d e m i c ”
s p r e a d a l l b u n d l e s t o a l l a v a i l a b l e n e i g h b o r s . F l o o d i n g works l i k e
epidemic , but do not send t h e own summary v e c t o r t o n e i g h b o r s .
Prophet f o r w a r d s based on t h e p r o b a b i l i t y t o e n c o u n t e r o t h e r nodes
( s e e d r a f t −i r t f −dtnrg−prophet −09).

routing = epidemic

#
# f o r w a r d b u n d l e s t o o t h e r nodes ( y e s /no )
#
routing forwarding = yes

164
# S c h e d u l i n g adds a s o r t e d bundle i n d e x t o t h e daemon i n s t a n c e which i s used
# t o o r d e r t h e b u n d l e s u s i n g t h e p r i o r i t y d e f i n e d i n t h e S c h e d u l i n g B l o c k and
# several other i n d ic a t o rs .
#
#s c h e d u l i n g = no

#
# s t a t i c routing rules
# − a rule i s a regex pattern
# − format i s <t a r g e t −scheme> <r o u t i n g −node>
#
# r o u t e a l l b u n d l e s f o r ” dtn : / / ∗ . moon . dtn /∗” t o dtn : / / r o u t e r . dtn
#r o u t e 1 = ˆ dtn : / / [ [ : a l p h a : ] ] . moon . dtn / [ [ : a l p h a : ] ] dtn : / / r o u t e r . dtn
#r o u t e 1 = dtn : / / p i 1 . dtn ∗ dtn : / / p i 2 . dtn

#
# s t a t i c connections
# f o r c o n f i g u r e s t a t i c c o n n e c t i o n s i t i s i m p o r t a n t t o b e g i n with ” s t a t i c 1 ”
# and count up ( ” s t a t i c 2 ” , ” s t a t i c 3 ” , . . . )
#

### p r o p h e t c o n f i g u r a t i o n ###
#p r o p h e t p e n c o u n t e r m a x = 0 . 7
#p r o p h e t p e n c o u n t e r f i r s t = 0 . 5
#p r o p h e t p f i r s t t h r e s h o l d = 0 . 1
#p r o p h e t b e t a = 0 . 9
#prophet gamma = 0 . 9 9 9
#p r o p h e t d e l t a = 0 . 0 1
#p r o p h e t t i m e u n i t = 1
#p r o p h e t i t y p = 300
#p r o p h e t n e x t e x c h a n g e t i m e o u t = 60
#p r o p h e t f o r w a r d i n g s t r a t e g y = GRTR
#prophet gtmx nf max = 30
#s t r a t e g y
#a f f e c t s how s t r o n g t h e p r e d i c t a b i l i t y i s
#i n c r e a s e d on an e n c o u n t e r
#t h e p r e d i c t a b i l i t y o f a n e i g h b o r on t h e
#f i r s t e n c o u n t e r
#l o w e s t p r e d i c t a b i l i t y when n e i g h b o r s
#p r e d i c t a b i l i t i e s a r e f o r g o t t e n
#Weight o f t h e t r a n s i t i v e p r o p e r t y
#Determines how q u i c k l y p r e d i c t a b i l i t i e s
#age
#(1− d e l t a ) i s t h e maximum p r e d i c t a b i l i t y
#time u n i t i n s e c o n d s
#t y p i c a l time i n t e r v a l between two node
#e n c o u n t e r s
#t i m e o u t how o f t e n handshakes s h o u l d be
#e x e c u t e d
#The f o r w a r d i n g s t r a t e g y used GRTR | GTMX
#Maximum t i m e s t o f o r w a r d i n t h e GTMX

#####################################
# bundle s e c u r i t y p r o t o c o l #
#####################################

#
# the l e v e l s p e c i f i e s the s e c u r i t y c o n s t r a i n s
#
# 0 = no c o n s t r a i n s ( d e f a u l t )
# 1 = accept only authenticated bundles

165
# 2 = accept only encrypted bundles
# 4 = accept only signed bundles
#
# Combination i s a l l o w e d by adding v a l u e s
# e . g . 5 = a c c e p t o n l y b u n d l e s which a r e s i g n e d AND a u t h e n t i c a t e d
#
#s e c u r i t y l e v e l = 0

#
# bab d e f a u l t key
#
#s e c u r i t y b a b d e f a u l t k e y = / e t c / i b r d t n / b p s e c / d e f a u l t −bab−key . mac

#
# key path
#
#s e c u r i t y p a t h = / e t c / i b r d t n / b p s e c / k e y s

#
# TLS f o r TCP c o n v e r g e n c e l a y e r
# A u t h e n t i c a t i o n and e n c r y p t i o n ( o p t i o n a l ) s u p p o r t f o r e v e r y
# t c p c o n n e c t i o n between t h e daemons .
#
# c e r t i f i c a t e s i g n e d by t h e a u t h o r i t y ( p u b l i c key )
#s e c u r i t y c e r t i f i c a t e = / e t c / i b r d t n / t l s / l o c a l . c r t

# l o c a l TLS key
#s e c u r i t y k e y = / e t c / i b r d t n / t l s / l o c a l . key

# path t o t r u s t e d c e r t i f i c a t e s
#s e c u r i t y t r u s t e d c a p a t h = / e t c / i b r d t n / t l s /

# s e t t o ’ yes ’ i f t c p c o n n e c t i o n s w i t h o u t TLS a r e not a l l o w e d

#s e c u r i t y t l s r e q u i r e d = y e s

# s e t t o ’ yes ’ t o d i s a b l e e n c r y p t i o n i n t h e TLS s t r e a m s
#s e c u r i t y t l s d i s a b l e e n c r y p t i o n = y e s

#####################################
# time s y n c h r o n i z a t i o n #
#####################################

#
# s e t t o y e s i f t h i s node i s c o n n e c t e d t o a h i g h p r e c i s i o n time r e f e r e n c e
# l i k e GPS, DCF77 , NTP, e t c .
#
#t i m e r e f e r e n c e = y e s

166
# s y n c h r o n i z e with n e i g h b o r s
#
#t i m e s y n c h r o n i z e = y e s

#
# announce time sync c a p a b i l i t i e s i n d i s c o v e r y m es sa ges
#
#t i m e d i s c o v e r y a n n o u n c e m e n t s = y e s

#
# Parameters f o r t h e QoT a g i n g p r o c e s s .
#
#t i m e s i g m a = 1 . 0 0 1
#t i m e p s i = 0 . 9
#t i m e s y n c l e v e l = 0 . 1 5

#
# Adjust t h e c l o c k o f t h e h o s t on each sync
#
#t i m e s e t c l o c k = no

#####################################
# DHTNameService s e t t i n g s #
#####################################

#
# Enable t h e DHT, i f i t was c o m p i l e d
# D e f a u l t i s no
#
dht enabled = yes

#
# Set the udp port , t h e DHT s h o u l d working on
# Default i s 9999
# I f Port i s 0 , a random Port w i l l be c h o s e n f o r each run
#
#d h t p o r t = 9999

#
# Here you can c h o o s e a s t a t i c DHT ID , which i s v e r y common
# D e f a u l t i s none −> a random ID p e r run w i l l be g e n e r a t e d
#d h t i d = <randomstring >

#
# Enables DHT on IPv4 s o c k e t
# Default i s yes
#
#d h t e n a b l e i p v 4 = y e s

167
#
# Enables DHT on IPv6 s o c k e t
# Default i s yes
#
#d h t e n a b l e i p v 6 = y e s

#
# Bind t h e DHT t o a s p e c i f i c IPv4 Address
# D e f a u l t i s t h e any d e v i c e
#
#d h t b i n d i p v 4 = 1 2 7 . 0 . 0 . 1

#
# Bind t h e DHT t o a s p e c i f i c IPv6 Address
# D e f a u l t i s t h e any d e v i c e
#
#d h t b i n d i p v 6 = : : 1

#
# S p e c i f y t h e f i l e , where t h e DHT can s a v e a l l good nodes
# f o r f a s t e r r e s t a r t on next s e s s i o n
# D e f a u l t i s no f i l e , but i t s h o u l d be s e t
#
#d h t n o d e s f i l e = <f i l e p a t h >

#
# Enable DNS B o o t s t r a p p i n g f o r t h e DHT
#
#d h t b o o t s t r a p p i n g = y e s

#
# DNS B o o t s t r a p p i n g by g i v i n g domain names o f wellknown nodes
#d h t b o o t s t r a p p i n g d o m a i n s = [ domain ] [ . . . ]
#
# Example :
#d h t b o o t s t r a p p i n g d o m a i n s = dtndht . i b r . c s . tu−bs . de
#
# D e f a u l t i s an empty s t r i n g
#d h t b o o t s t r a p p i n g d o m a i n s =

#
# IP B o o t s t r a p p i n g from wellknown IP ( and p o r t ) a d d r e s s e s o f nodes
#d h t b o o t s t r a p p i n g i p s = [ i p [ p o r t ] ] ; [ i p [ p o r t ] ] ; . . .
#
# Example :
#d h t b o o t s t r a p p i n g i p s = 1 9 2 . 1 6 8 . 0 . 1 ; 1 9 2 . 1 6 8 . 0 . 2 8 8 8 8 ;
#
# D e f a u l t i s an empty s t r i n g
#d h t b o o t s t r a p p i n g i p s =

168
#
# B l a c k l i s t s u p p o r t o f t h e DHT can be s w i t c h on and o f f
#
# Default i s yes
#d h t b l a c k l i s t = y e s

#
# Announcing m y s e l f on t h e DHT
#
# Default i s yes
#d h t s e l f a n n o u n c e = y e s

# I f t h e r a t i n g o f an incoming i n f o r m a t i o n i s lower , i t w i l l be i g n o r e d
#
# Default i s 1
#d h t m i n r a t i n g = 1

#
# Allow announcing n e i g h b o u r s
#
# Default i s yes
#d h t a l l o w n e i g h b o u r a n n o u n c e m e n t = y e s

#
# Allow a l l n e i g h b o u r s announce them t o be n e i g h b o u r t o me
# For p r i v a c y r e a s o n s , you c o u l d t u r n t h i s o f f
#
# Default i s yes
#d h t a l l o w n e i g h b o u r s t o a n n o u n c e m e = y e s

#
# I g n o r i n g t h e n e i g h b o u r i n f o r m a t i o n s e n t by a node , found on t h e DHT
#
# D e f a u l t i s no
#d h t i g n o r e n e i g h b o u r i n f o r m a t i o n s = no

IBR-DTN daemon script

This is the script used to start the DTN daemon. The script has minor modifications to the
original available. Due credit is given to the author Morgenroth, J of IBR-DTN. The script is
located in /etc/init.d/ibrdtnd. The changed settings have been tabulated in Chapter 6.

#!/ b i n / sh
### BEGIN INIT INFO
# Provides : ibrdtnd
# Required−S t a r t : $ r e m o t e f s $network $ l o c a l f s
# Required−Stop : $ r e m o t e f s $network $ l o c a l f s
# D e f a u l t −S t a r t : 2 3 4 5
# D e f a u l t −Stop : 0 1 6
# Short−D e s c r i p t i o n : IBR−DTN Daemon

169
# Description : IBR−DTN daemon bundle p r o t o c o l
# s t a c k f o r d e l a y t o l e r a n t networks .
### END INIT INFO

# Author : Johannes Morgenroth <morgenroth@ibr . c s . tu−bs . de>

# PATH s h o u l d o n l y i n c l u d e / u s r /∗ i f i t r u n s a f t e r t h e mountnfs . sh s c r i p t
PATH=/s b i n : / u s r / s b i n : / b i n : / u s r / b i n
DESC=i b r d t n d # Introduce a short d e s c r i p t i o n here
NAME=i b r d t n d # I n t r o d u c e t h e s h o r t s e r v e r ’ s name h e r e
PNAME=dtnd # I n t r o d u c e t h e p r o c e s s name
DAEMON=/u s r / s b i n / dtnd # Introduce the server ’ s l o c a t i o n here
PIDFILE=/var / run / i b r d t n /$PNAME. p i d # Path where t h e p i d f i l e i s s t o r e d
SCRIPTNAME=/ e t c / i n i t . d/$NAME # Name o f t h i s s c r i p t
DAEMON ARGS=”−D −p $ {PIDFILE} −−b a d c l o c k ” # Arguments t o run t h e daemon with

# E x i t i f t h e package i s not i n s t a l l e d
[ −x $DAEMON ] | | e x i t 0

# Exit i f e x p l i c i t l y t o ld to
[ ”$ENABLED” != ”0” ] | | e x i t 0

# Read c o n f i g u r a t i o n v a r i a b l e f i l e i f i t i s p r e s e n t
[ −r / e t c / d e f a u l t /$NAME ] && . / e t c / d e f a u l t /$NAME

# set quiet option i f requested

[ −n ”$ {DAEMON OPTS}” ] && DAEMON ARGS=”${DAEMON ARGS} $ {DAEMON OPTS} − i wlan0 ”

# set user i f s p e c i f i e d in defaults

[ −n ”$ {DAEMON USER}” ] && DAEMON USER START ARGS=”−−c h u i d $ {DAEMON USER}”
[ −n ”$ {DAEMON USER}” ] && DAEMON USER STOP ARGS=”−−u s e r $ {DAEMON USER}”

# Load t h e VERBOSE s e t t i n g and o t h e r r c S v a r i a b l e s

. / l i b / i n i t / v a r s . sh

# D e f i n e LSB l o g ∗ f u n c t i o n s .
# Depend on l s b −b a s e (>= 3.0 −6) t o e n s u r e t h a t t h i s f i l e i s p r e s e n t .
. / l i b / l s b / i n i t −f u n c t i o n s

#
# Function t h a t s t a r t s t h e daemon/ s e r v i c e
#
do start ()
{
# c r e a t e t h e PID d i r e c t o r y
PIDDIR=‘ dirname ${PIDFILE } ‘
i f [ ! −d $ {PIDDIR} ] ; then
mkdir −p $ {PIDDIR}
chown $ {DAEMON USER} ${PIDDIR}
chgrp ${DAEMON USER} ${PIDDIR}

170
 fi
echo ”\ n S t a r t e d i b r d t n now . . ”
# Return
# 0 i f daemon has been s t a r t e d
# 1 i f daemon was a l r e a d y r u n n i n g
# 2 i f daemon c o u l d not be s t a r t e d
s t a r t −stop−daemon −−s t a r t −−q u i e t $ {DAEMON USER START ARGS}
−−e x e c $DAEMON −−t e s t > / dev / n u l l \
| | return 1
s t a r t −stop−daemon −−s t a r t −−q u i e t $ {DAEMON USER START ARGS}
−−e x e c $DAEMON −− \
$DAEMON ARGS \
| | return 2

echo ” I am h e r e . . ”
# Add code here , i f n e c e s s a r y , t h a t w a i t s f o r t h e p r o c e s s t o be ready
# t o h a n d l e r e q u e s t s from s e r v i c e s s t a r t e d s u b s e q u e n t l y which depend
# on t h i s one . As a l a s t r e s o r t , s l e e p f o r some time .
}

#
# Function t h a t s t o p s t h e daemon/ s e r v i c e
#
do stop ()
{
# Return
# 0 i f daemon has been s t o p p e d
# 1 i f daemon was a l r e a d y s t o p p e d
# 2 i f daemon c o u l d not be s t o p p e d
# other i f a f a i l u r e occurred
s t a r t −stop−daemon −−s t o p −−q u i e t −−r e t r y=TERM/30/KILL/5 −−
p i d f i l e $PIDFILE −−name $PNAME ${DAEMON USER STOP ARGS}
RETVAL=”$ ?”
[ ”$RETVAL” = 2 ] && r e t u r n 2

s t a r t −stop−daemon −−s t o p −−q u i e t −−oknodo −−r e t r y =0/30/

KILL/5 −−e x e c $DAEMON $ {DAEMON USER STOP ARGS}
[ ” $ ?” = 2 ] && r e t u r n 2
# Many daemons don ’ t d e l e t e t h e i r p i d f i l e s when they e x i t .
rm −f $PIDFILE
r e t u r n ”$RETVAL”
}

#
# Function t h a t s e n d s a SIGHUP t o t h e daemon/ s e r v i c e
#
do reload () {
#
# I f t h e daemon can r e l o a d i t s c o n f i g u r a t i o n w i t h o u t
# r e s t a r t i n g ( f o r example , when i t i s s e n t a SIGHUP) ,

171
 # then implement t h a t h e r e .
#
s t a r t −stop−daemon −−s t o p −−s i g n a l 1 −−q u i e t −−
p i d f i l e $PIDFILE −−name $PNAME
${DAEMON USER STOP ARGS}
return 0
}

c a s e ” $1 ” i n
start )
[ ”$VERBOSE” != no ] && log daemon msg ” S t a r t i n g $DESC ” ”$NAME”
do start
RETVAL=$ ?
i f [ ”$VERBOSE” != no ] ; then
c a s e ”$RETVAL” i n
0 | 1 ) log end msg 0 ; ;
2) log end msg 1 ; ;
esac
fi
;;
stop )
[ ”$VERBOSE” != no ] && log daemon msg ” S t o p p i n g $DESC” ”$NAME”
do stop
RETVAL=$ ?
i f [ ”$VERBOSE” != no ] ; then
c a s e ”$RETVAL” i n
0 | 1 ) log end msg 0 ; ;
2) log end msg 1 ; ;
esac
fi
;;
status )
s t a t u s o f p r o c ”$DAEMON” ”$NAME” && e x i t 0 | | e x i t $ ?
;;
reload )
log daemon msg ” R e l o a d i n g $DESC” ”$NAME”
do reload
log end msg $?
;;
r e s t a r t | f o r c e −r e l o a d )
#
# I f t h e ” r e l o a d ” o p t i o n i s implemented then remove t h e ’ f o r c e −r e l o a d ’ a
#
log daemon msg ” R e s t a r t i n g $DESC” ”$NAME”
do stop
c a s e ” $ ?” i n
0|1)
do start
c a s e ” $ ?” i n
0) log end msg 0 ; ;

172
 1 ) l o g e n d m s g 1 ; ; # Old p r o c e s s i s s t i l l r u n n i n g
∗) log end msg 1 ; ; # Failed to s t a r t
esac ;;
∗)
# Failed to stop
log end msg 1 ; ;
esac ;;
∗)
echo ” Usage : $SCRIPTNAME { s t a r t | s t o p | s t a t u s | r e s t a r t | r e l o a d | f o r c e −r e l o a d }
exit 3 ; ;
esac

173
Bibliography

[1] I. Robotics and A. magazine 2012, “Quadrotor open source platform comparisons,” pp.
18–44, 2012. [Online]. Available: http://www.ieee-ras.org/publications/ram
[2] A. Lopez, G. Hoekstra, and M. de Graaf, “Energy efficient algorithm and dtn implemen-
tations in manets (thales group),” 2013.
[3] S. Ali and A. Ali, “Performance analysis of aodv, dsr and olsr in manet,” in Proceedings
on Seventh International Conference on Wireless Systems, 2009, p. 34.
[4] A. Tønnesen, “Impementing and extending the optimized link state routing protocol,”
2004.
[5] W. Forrest and W. Associates, “Delay- and disruption-tolerant networks (dtns) tutorial,”
2012. [Online]. Available: www.dtnrg.org
[6] S. Schildt, J. Morgenroth, W.-B. Pöttner, and L. Wolf, “Ibr-dtn: A lightweight, modular
and highly portable bundle protocol implementation,” Electronic Communications of the
EASST, vol. 37, 2011.
[7] Arducopter project, open-source hardware and software. [Online]. Available: http:
//ardupilot.com/
[8] J. Borenstein, “The hoverbot–an electrically powered flying robot,” Ann Arbor, vol. 1001,
pp. 48 109–2110, 1992.
[9] C. Blum and V. V. Hafner, “An autonomous flying robot for network robotics,” in Robotics;
Proceedings of ROBOTIK 2012; 7th German Conference on, 2012, pp. 1–5.
[10] D. Henkel and T. X. Brown, “On controlled node mobility in delay tolerant networks of
unmanned aerial vehicles,” in International Symposium on Advance Radio Technolgoies
(ISART), pp. 7–9.
[11] C. Blum and V. V. Hafner, “Robust exploration strategies for a robot exploring a wireless
network,” Electronic Communications of the EASST, vol. 56, 2013.
[12] H. H. Choi, S. H. Nam, T. Shon, and M. Choi, “Information delivery scheme of micro uavs
having limited communication range during tracking the moving target,” The Journal of
Supercomputing, pp. 1–23, 2013.
[13] D. Akerman, “Raspberry pi in the sky, available as on nov’ 2013.” [Online]. Available:
http://www.raspberrypi.org/archives/tag/dave-akerman
[14] J. Villbrandt, “The quadrotors coming of age,” Comm. Mag., vol. 12, no. 2, 2010.
[15] D. Heimans, D. R. Carloni, M. de Graaf, and G. Hoekstra, “Using quadcopter camera
images for event protection,” University of Twente - Robotics and Mechatronics, 2012.

174
[16] P. Brisset, M. Gorraz, P. Huard, and J. Tyler, “”the paparazzi solution”, sandestine,
florida,” 2006.
[17] Openpilot project, open-source hardware and software. [Online]. Available: http:
//www.openpilot.org/
[18] L. Meier, P. Tanskanen, F. Fraundorfer, and M. Pollefeys, “Pixhawk: A system for au-
tonomous flight using onboard computer vision,” in Robotics and Automation (ICRA),
2011 IEEE International Conference on, 2011, pp. 2992–2997.
[19] Pandaboard, low-cost single-board computer development platform by texas instruments.
[Online]. Available: http://pandaboard.org/
[20] P. Sharma, A. Kalia, and J. Thakur, “Performance analysis of aodv, dsr and dsdv rout-
ing protocols in mobile ad-hoc network (manet),” Journal of Information Systems and
Communication, vol. 3, no. 1, 2012.
[21] J. Macker, “Mobile ad hoc networking (manet): Routing protocol performance issues and
evaluation considerations (rfc2501),” 1999.
[22] C. Perkins, E. Belding-Royer, S. Das et al., “Rfc 3561-ad hoc on-demand distance vector
(aodv) routing,” Internet RFCs, pp. 1–38, 2003.
[23] D. Vir, S. Agarwal, and S. Imam, “Power management in optimized link state routing
(olsr) protocol.”
[24] S. Rana and A. Kapil, “Defending against node misbehavior to discover secure route in
olsr,” in Information Processing and Management. Springer, 2010, pp. 430–436.
[25] M. Nishanthy, T. SenthilMurugan, and E. Kannan, “A novel rebroadcasting algorithm for
manets.”
[26] Optimized link state routing group. [Online]. Available: http://www.olsr.org
[27] Y. Huang, S. Bhatti, and D. Parker, “Tuning olsr,” in Personal, Indoor and Mobile Radio
Communications, 2006 IEEE 17th International Symposium on, 2006, pp. 1–5.
[28] Xl-maxsonar- ez series, sonar sensor. [Online]. Available: http://www.maxbotix.com/
documents/XL-MaxSonar-EZ Datasheet.pdf
[29] Gps methodology and its operation. [Online]. Available: http://www8.garmin.com/
aboutGPS/
[30] Simon k firware, flash instructions. [Online]. Available: https://github.com/sim-/tgy
[31] T. Luukkonen, “Modelling and control of quadcopter,” Aalto University, Tech. Rep., aug
2011.
[32] S. Balasubramanian, M. Cox, and L. Waeijen, “Design and implementation of a quadcopter
with visual control, 5hc99 embedded visual control,” Technical University Eindhoven, Tech.
Rep., Sept 2012.
[33] S. B. et al, “Stabilization of a two-axis camera mount for a uav, 5l990 internship report,”
Technical University Eindhoven, Tech. Rep., Mar 2013.
[34] W. Premerlani and P. Bizard, “Direction cosine matrix imu: Theory,” DIY DRONE: USA,
pp. 13–15, 2009.

175
[35] M. Orsag and S. Bogdan, “Influence of forward and descent flight on quadrotor dynamics,”
2012.
[36] Model 092 barometric pressure sensor, available dated 20-dec-2013. [Online]. Available:
http://s.campbellsci.com/documents/us/manuals/092.pdf/
[37] Ms5611- barometric pressure sensor datasheet, available dated 20-dec-2013. [Online].
Available: http://www.meas-spec.com/downloads/MS5611-01BA03.pdf
[38] A. Thiel and M. Ammann, “Anti-jamming techniques in u-blox gps receivers,” Oct. 2009.
[Online]. Available: http://www.u-blox.com/en/whitepapers.html
[39] R. Pickholtz, D. Schilling, and L. Milstein, “Theory of spread-spectrum communications–a
tutorial,” pp. 855–884, May 1982. [Online]. Available: http://ieeexplore.ieee.org/
[40] M. Kennedy et al., The global positioning system and GIS: an introduction. Wiley Online
Library, 2002.
[41] Rapsberry pi homepage, os installation and camera setup. [Online]. Available:
http://www.raspberrypi.org/
[42] Turbo ace, world class multicopter specialists and multi-rotor drones, available
20-dec-2013. [Online]. Available: http://www.turboace.com/
[43] Microdrones, world class multicopter design specialists, available 20-dec-2013. [Online].
Available: http://www.microdrones.com
[44] K.-P. Neitzke, “Rotary wing micro air vehicle endurance.”
[45] S. R. Hall, K. Y. Yang, and K. C. Hall, “Helicopter rotor lift distributions for minimum-
induced power loss,” Journal of aircraft, vol. 31, no. 4, pp. 837–845, 1994.
[46] Battery-energy and their comparison, available 23-dec-2013. [Online]. Available:
http://www.allaboutbatteries.com
[47] Brushless dc motors specifications from lipoly, germany. available 25-dec-2013. [Online].
Available: http://www.lipoly.de
[48] Brushless dc motors specifications from rctimer. available 26-dec-2013. [Online]. Available:
http://www.rctimer.com
[49] S. J. Julier and J. K. Uhlmann, “New extension of the kalman filter to nonlinear systems,”
in AeroSense’97. International Society for Optics and Photonics, 1997, pp. 182–193.
[50] R. Mahony, T. Hamel, and J.-M. Pflimlin, “Complementary filter design on the special
orthogonal group so (3),” in Decision and Control, 2005 and 2005 European Control Con-
ference. CDC-ECC’05. 44th IEEE Conference on. IEEE, 2005, pp. 1477–1484.
[51] R. .Mahony, T. Hamel, and J.-M. Pflimlin, “Nonlinear complementary filters on the special
orthogonal group,” in Automatic Control, IEEE Transactions on. IEEE, 2008, pp. 1203–
1218.
[52] N. Briscoe, “Understanding the osi 7-layer model,” PC Network Advisor, vol. 120, no. 2,
2000.
[53] M. Meyers, Mike Meyers’ CompTIA Network+ Certification Passport. McGraw-Hill, Inc.,
2009.

176
[54] Python homepage, installables and instructions. [Online]. Available: http://www.python.
org/
[55] Advanced settings for configuring wireless ad-hoc modes, iwconfig. [Online]. Available:
http://www.linuxCommand.org
[56] Ibr-dtn homepage, originators of the ibr-dtn bundle protocol implementation, installables
and instructions. [Online]. Available: http://trac.ibr.cs.tu-bs.de/
[57] Raspberry pi real-time clock, source code. [Online]. Available: http://www.hobbytronics.
co.uk/download/rtc-pi.zip

177