Autonomous Swarm Behaviour

in Mesh Networked Agents

Peter Henderson 260457751 (ECSE 456)Matthew Vertescher 260469756 (ECSE 456)

Supervisor: Mark Coates

December 4, 2014

1

Abstract

In recent years, unmanned aerial vehicles (UAVs) have become commonplace. They have beenused most notably for military purposes, film making, and more recently, parcel delivery. However,current UAV technologies focus on piloted systems. While some focus has been shifted toward fullyautonomous systems with large companies like Google and Amazon investing heavily in such tech-nologies, there is still much technology to be developed for these autonomous systems to becomecommonplace. Most important and lacking is the flight time of these systems. Current batterytechnologies cannot sustain motor function for extensive flight times, particularly in multi-coptersystems, as such these systems still cannot accomplish the tasks they need without manual super-vision to travel safely and recharge. This restriction comes into play heavily with mapping andexploration tasks, which can be beneficial for many industries, particularly agriculture. However,recent developments in coordinated systems of multiple autonomous agents have shown that co-ordinated tasks can be accomplished at a much faster pace and in the available amount of flighttime. As such, we pursue a multi agent system interconnected with mesh networking technologies,which can pursue a mapping and exploration task in a fully decentralized and self-coordinatedautonomous manner. While a complete system including hardware may not be feasible during theyear, we plan to design a software system and choose appropriate technologies to accomplish thistask. Additionally, our goal is to run our designed software system and algorithms in simulationto show its feasibility and the agents’ ability to autonomously make decisions in a decentralizedfashion. During this semester, we designed such a system and its requirements, researched the ap-propriate technologies, and began work on testing basic communication amongst hardware nodes.Finally, we began the development of a simulator which we could test our algorithms in.

Acknowledgements

We would like to acknowledge Frank Ferrie for discussing the idea with us and pointing us in theright direction before we got started.

1

Contents

1 Abbreviations and Notations 3

2 Introduction and Objectives 3

3 Background 33.1 An Overview of Mesh Networking Protocols . . . . . . . . . . . . . . . . . . . . . . . 33.2 Control Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2.1 DDDAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2.2 RHC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4 Requirements 54.0.3 Communication Hardware and Algorithms . . . . . . . . . . . . . . . . . . . . 54.0.4 Decision Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54.0.5 UAV Simulation System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5 Design and Results 65.1 Prototype Communication Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

5.1.1 Hardware Platform: Raspberry Pi and Chipset . . . . . . . . . . . . . . . . . 65.1.2 Mesh Networking Standard: 802.11s . . . . . . . . . . . . . . . . . . . . . . . 65.1.3 802.11s Performance Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85.1.4 Experimental Testbed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.2 Decentralized Coordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95.2.1 Swarm Behaviour Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.2.2 Optimization Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.2.3 Mapping and Exploration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.3 High Level Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135.3.1 Simulator Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145.3.2 Game Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.4 Prototype Autonomous Vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 Plans for Next Semester 15

7 Impact on Society and the Environment 157.1 Environmental benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167.2 Use of Non-Renewable Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167.3 Safety and Risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

8 Report on Teamwork 17

9 Conclusion 17

Appendix A mesh.sh 22

Appendix B install.sh 23

2

1 Abbreviations and Notations

UAV: Unmanned Aerial Vehicle; UGV: Unmanned ground vehicle; MANETS: Mobile Ad-HocNetworks; RHC: Receding Horizon Control; D-RHC: Decentralized Receding Horizon Control;DDDAS: Dynamic Data-Driven Application Systems; RTD: Round Trip Delay;

2 Introduction and Objectives

This design project consists of three objectives. The primary goal is to develop a decentralized com-munication system between multiple autonomous vehicles so they can coordinate between them-selves to map and explore a given area. This requires the development of a communications moduleas well as algorithms for task coordination and obstacle avoidance. Additionally, there are two sec-ondary goals. First, multiple autonomous vehicles should be able to cooperate with each other toe�ciently search for predefined features in a given area. Second, the autonomous vehicles shouldorganize themselves to serve ground clients connected to them and pass information between end-points. We hope to achieve as much as possible, but we focus on the primary goal for the purposesof this design project.

Designing an autonomous UAV swarm is a challenging task that incorporates a plethora ofdisciplines with potential for a major impact on society. Some applications include search andrescue, terrain mapping, inspection, agricultural upkeep, and delivery systems. Furthermore, oneof the key motivating applications is the rapid deployment of the Internet or other network to adisaster area. Given the potential for the project, development is focused on the the crucial partsof the hardware and software of systems, namely communication, computer vision and artificialintelligence. Overall, this design project hopes to explore these topics and achieve a prototypeautonomous UAV system.

3 Background

The following sections provide some useful background information necessary for the design projectitself.

3.1 An Overview of Mesh Networking Protocols

In comparison to wired networks that have a largely static topology, mobile wireless networks(MANETS) have radically di↵erent design constraints. Mobile wireless networks have a dynamictopology and hence require complicated routing by default. Addressing this problem, severalMANET routing protocols have been developed to ensure adequate multi-hop communication. AMANET protocol can be categorized into one of three domains: proactive, reactive and hybrid [1].Proactive protocols keep up to date routing information with a significant overhead cost, but deliverthe lowest communication delay [1]. Destination-sequenced distance vector routing (DSDV) [2], theoptimized link state routing protocol (OLSR) [3] and babel [4] are a few examples of protocols thatstrive to actively maintain all routes in a network. In addition, as a replacement for OLSR, a gossipbased routing protocol called the Better Approach To Mobile Ad-hoc Networking (B.A.T.M.A.N.)was developed [5, 6]. In contrast, reactive routing protocols attempt to eliminate the overhead ofmaintaining a network by finding routes as they are needed. Although this leads to high levels ofdelay [1], particularly when a route needs to be discovered, considerable resources can be saved.The Dynamic Source Routing Protocol (DSR) [7] and Ad-hoc Distance Vector Routing (AODV) [8]

3

are both reactive protocols at their core. Finally, hybrid protocols, featuring a combination of bothproactive and reactive features, o↵er a more balanced solution. Typically, a hybrid solution isboth a proactive protocol and a reactive protocol operating together [9]. This combination helpsto limit the drawbacks of each techniques. For example, the overhead in the proactive part islimited by only keeping routing information for a local zone rather than the entire network, whilea reactive protocol is used to reach destinations outside of the proactive zone [9]. Both the ZoneRouting Protocol (ZRP) [9] and SHARP [10] leverage zones to route appropriately. This approachworks well within a local area, but can su↵er when routing through zones [1]. Alternatively, theHybrid Wireless Mesh Protocol (HWMP) is reactive by default, but can be configured to maintaina proactive spanning tree to a particular node [11]. Though each approach, proactive, reactive andhybrid, have their own strengths and weaknesses, specific network properties ultimately determinethe e↵ective performance of a protocol. With a variety of options, choosing an appropriate protocolis application dependent.

3.2 Control Schemes

In our literature review of various control models, two in particular were encountered with greatfrequency in relation to highly mission critical systems like military applications: Dynamic Data-Driven Application Systems (DDDAS) and Receding Horizon Control (RHC) systems.

3.2.1 DDDAS

The term DDDAS was coined by Dr. Frederica Darema and is described as a system which “entailsthe ability to incorporate additional data into an executing application - these data can be archivalor collected on-line; and in reverse, the ability of applications to dynamically steer the measurementprocess” [12]. This encompasses a wide variety of algorithms and purposes, from wildfire behaviourprediction [13], to disaster management [14] and swarm behaviour [15, 16]. A common motif in allof these, however, is the need for a central command and control centre due to computationallyheavy simulations.

3.2.2 RHC

RHC control systems have been around since the early 1980’s and are often called model predictivecontrol (MPC) systems. In RHC systems, an optimization problem with a set of cost functionsand constraints is minimized for a projected time frame, or more formally, until the next recedinghorizon [17]. Like DDDAS applications, RHC systems are also found in a large application spaceincluding process control mechanisms [18], strategic investment [19] and flight systems in F-16fighter jets [20]. In particular, a decentralized version of RHC (D-RHC) has been used in thecontrol mechanisms of autonomous swarms [21, 22, 23]. One commonality that is clearly visiblebetween these application examples is the use of RHC (and D-RHC) in mission critical systemswhere fast and reliable decision making is needed. With an optimized and appropriate set of costfunctions, it has been shown that a system using RHC can ”perform near its physical limits” [17]and, as such, is ideal for our application. In particular, due to the similarity of our application to[21, 22], we focus on D-RHC as a control scheme. D-RHC models can be generally formulated as:

minimize P(xi, {ey0, . . . , eyn})subject to c

0

(xi, {ey0, . . . , eyn}). . .

cm(xi, {ey0, . . . , eyn})

4

Here xi is some variable, or set of variables, (like the position and velocity of an autonomousagent) that can be minimized. {ey

0

, . . . , eyn} are the predicted states of input data analogous to thepredicted position and velocity states of the neighbour nodes in swarm at the next horizon. P(. . . )is the optimization problem which the D-RHC controller is trying to solve, comprising the internalcosts of the system. {c

0

(. . . ), . . . , cm(. . . )} is the set of constraints for the system based on theaforementioned inputs.

The D-RHC controller first predicts state information of its neighbouring D-RHC nodes andany other variable data inputs at the next time horizon. To make these predictions it uses anymodel information it may have about the optimization functions of the other controllers or simplycurrent state information like velocity. The system then runs a cost minimization algorithm on theoptimization function to determine the appropriate evaluation for a variable it can control, such asthe velocity or position of the agent at the next time horizon. The value is passed to an outputsystem and then the process is repeated for the next time horizon.

4 Requirements

To accomplish the goals for this design project, a list of requirements has been compiled for eachof the three main parts of the project.

4.0.3 Communication Hardware and Algorithms

To facilitate communication between the autonomous vehicles, a modular communication systemshould be chosen. Using the module, agents should be able to communicate relevant informationin a reliable and e�cient manner. A distributed mesh networking protocol should be chosen tofacilitate the communication. The network should be fault-tolerant and should support debuggingand information passing tools to export relevant information to an external endpoint. Testing andanalysis of the message passing should be done on hardware to simulate the mesh network withoutaerial movement first. Furthermore, testing of the communication network while moving the nodesshould also be accomplished pre-integration.

4.0.4 Decision Algorithms

To e↵ectively coordinate agents to map an area, high level decision algorithms must accomplishthe following tasks. First, the agents must be able to safely move as a group to di↵erent pointswithout colliding while finding an e�cient path. Additionally, the agents must be able to divide anexploration task in a decentralized fashion to explore a bounded area. The agents must synchronizetheir knowledge to keep an up to date belief map of the area and they should be able to fully exploreand map the area based on this knowledge. All decision algorithms should be modelled in softwaresimulations taking into account real-world problems that may arise, including loss of communicationbetween nodes. Lastly, agents should be able to operate independently without a connection to therest of the swarm.

4.0.5 UAV Simulation System

Testing the algorithms to run on the autonomous vehicles requires thorough simulation. As such,a robot simulation platform should be proposed to simulate mesh communication as well as co-operation algorithms for searching and network formation. Furthermore, the autonomous vehiclesimulation should be able to handle complex real-world scenarios.

5

5 Design and Results

5.1 Prototype Communication Hardware

The design and development of a hardware system that supports mesh networking will serve as thebasis for communication on our autonomous vehicles. By first addressing the implementation of amodular communication system, the rest of the system can be defined independently. Additionally,ensuring a stable and flexible system to propagate messages is a top priority worthy of a dedicatedprototype. The following sections state the design decisions in relation to the hardware prototype.

5.1.1 Hardware Platform: Raspberry Pi and Chipset

The driving design consideration when choosing a prototype hardware platform was speed by adopt-ing existing tools. Using existing mesh networking tools and developing a system small and e�cientenough to fit on a vehicle limits the available options for both operating systems and hardware.In short, a Linux based board provides the most flexible solution. A variety of open source meshnetworking solutions Babel [24], B.A.T.M.A.N. [5], bmx6 [25], olsrd [26] and open80211s [27] are allbuilt atop the Linux kernel. In particular, B.A.T.M.A.N. and open802.11s are well developed layer2 protocols. Furthermore, other potentially useful packages like OpenCV [28], which will used toprocess image data on board, can build on Linux. Although not a strictly real time solution, Linuxand the open source projects built on it, make it nearly unavoidable solution to bring developmentup to the application layer as soon as possible.

Currently, there are a variety of Linux boards that support the Linux kernel. Of these, theRaspberry Pi [29] is perhaps the most accessible. The Pi ecosystem is actively developed and itis an open source, a↵ordable, Linux-compatible, single board computer backed by a foundationand a significant community, . Furthermore, with lots of support, the Pi’s abilities are activelytested, making its capabilities much more transparent. For these reasons, the Raspberry Pi is awell-rounded choice for mesh networking prototype module.

Finally, with an OS and embedded board established, an appropriate SoftMAC chipset, a devicethat requires that MAC frame management be done in software, can be determined. Documentationfor the entire Linux wireless (IEEE-802.11) subsystem can be found on the Linux wireless wiki [30].The main functionally of the site and its developers is to maintain a comprehensive set of devicedriver modules that target various chipsets. Today, the driver ecosystem is split. Some driversuse the now deprecated Wireless-Extensions (wext) and others the cfg80211/nl80211 [31]. Driversthat do not support wext typically do not support the two wireless modes most important to meshnetworking ad-hoc (IBSS) mode, where devices are free to talk to each other on the same channel,and mesh mode, a special ad-hoc mode that turns the interface into an 802.11s mesh point. Of allsupported drivers, few support both ad-hoc and mesh mode. In fact, of the sixty Linux drivers, lessthan 15 support both mesh point and ad-hoc mode, including only four USB drivers and one SPIdriver. Supporting both ad-hoc and mesh-point mode, the rt2800usb driver, used by the RalinkRT5370 chipset that is found in some common 802.11 USB modules, was chosen for this project.Figure 1 shows where the open802.11s implementation sits in the Linux kernel in relation to thehardware driver. All together, the system was chosen for maximum versatility and ease-of-use as amesh prototyping platform.

5.1.2 Mesh Networking Standard: 802.11s

Of the various mesh networking projects, the IEEE 802.11s-2011 standard, now a part of the currentIEEE 802.11-2012 standard [33], was chosen for a few key reasons. Similar to the way Bridging en-

6

Figure 1: The open802.11s in the Linux kernel.mac80211 is a driver API for SoftMAC devices. Re-produced from [32].

Figure 2: Ad-hoc Distance Vector Routing route re-quest mechanism. Hello packets inform nodes of adja-cent neighbours. If a source S wishes to send a packetto a destination D, a RREQ packet is first sent from S.This is broadcast through the network until it reachesa node that has a fresh route to D, like node 2. Node2 then sends a RREP packet back to S, populating thenext hop field in the routing tables for nodes 1 and S.Finally, data can be sent between S and D. If a linkis broken in the route, the path must be recalculated.Reproduced from [35].

abled multi-hop wired networks in the Ethernet (802.3) standard, 802.11s hopes to create multi-hopWLAN 802.11 networks [32]. Features of 802.11s, like coupled synchronization and power man-agement, medium access control mechanisms to coordinate mesh node transmission with optionalcongestion control, and distributed security mechanisms, help legitimize mesh interactions [34, 32].In addition, 802.11s supports various types of nodes that enable easy integration with 802.11-basedclients as well as other networks as shown in Figure 3.

Most importantly however, the default underlying routing protocol in 802.11s is the HybridWireless Mesh Protocol (HWMP) [34]. HWMP has both reactive and proactive routing character-istics [34]. When no root mesh point is present in the network to initiate proactive tree to rootrouting [11, 34], reactive routing is used by default. The reactive protocol is based on a slight mod-ification of Ad-hoc On-demand Distance Vector (AODV) routing, RM-AODV [11]. RM-AODV isnearly identical to AODV, but features MAC addressed nodes and an airtime metric to determinelink cost. When a route is not known between a source and destination node, path request (PREQ)packets are broadcast throughout the network [11]. When the destination node is found, a pathreply packet is send back toward the source (PREP) [8, 11]. The AODV implementation of thismechanism is shown in Figure 2. As PREQ and PREP packets are processed at nodes, pathsto either the source or destination nodes are updated accordingly in a node route table [8, 11].Sequence numbers are used to judge the freshness of paths [8, 11] and over time, stale paths areremoved from the routing table [8]. In relation to a dynamic network of autonomous vehicles, theon-demand path finding properties of HWMP are well suited to keep overhead low. Furthermore,since the agents will be regularly sending multicast position updates to each other, routes will berefreshed frequently across the network, avoiding a compulsory delay of sending data when therequested routes have not changed. In other words, the overhead of reactive routing is minimizedwith consistent network tra�c, in stable topologies. Overall, the 802.11s standard fits well tofacilitate versatile swarm topologies.

7

Figure 3: Example 802.11s network. 802.11s definesthree types of nodes: regular mesh point (MP) nodeswith core mesh routing functionalities, mesh accesspoints (MAP) that are both mesh points as well as802.11 access points, and mesh portals (MPP) that actas both a mesh point and a gateway to an external net-work. Stations (STA) are 802.11 enabled clients. Thevarious node types enable easy integration of 802.11snetworks with external 802.11 devices and networkslike the internet. Reproduced from [36].

Figure 4: Throughput comparison of OLSR,B.A.T.M.A.N. and open802.11s with variable o↵eredload. The testbed network used consisted of sixstations with a maximum of three hops in betweenany two nodes. The open802.11s implementationshows significant performance decreases at through-puts greater than 1 Mbs. Figure reproduced from [37].

5.1.3 802.11s Performance Notes

In comparison to well tested proactive routing protocols like OLSR and B.A.T.M.A.N., open802.11s,as tested in Wang et al., is shown to have weaker overall performance in certain situations. Specifi-cally since HWMP has to calculate routes on demand, open802.11s has a slightly higher RTDs, evenin lightly loaded networks [37]. Additionally, at increased loads of 1 Mbps or higher, the open802.11simplementation has increased outages and lower throughput. Figure 4 shows a detailed throughputcomparison.

5.1.4 Experimental Testbed

A test bed of five mesh nodes, shown in Figure 5 will be used for experimentation and testing. Byusing a real world test bed with a non-trivial number of modules, experiments can be comparable towhat might be used in real world autonomous vehicle applications. Furthermore, system propertieslike communication latency and power consumption can be observed in a controlled environmentto ensure system stability. The Ethernet ports on the Raspberry Pis can be used to debug theapplication in real time. Appendix A shows the set-up script to turn a Raspberry Pi into an802.11s mesh node. Appendix B shows the install script to enable mesh node creation on poweron. Running the install script on a Raspberry Pi enables plug and play mesh networking.

8

Figure 5: Current mesh networking testbed. It consists of three Model B+ boards (on the left) and twoModel B boards (on the right). The Ralink RT5370 chipset is used by all modules (top USB port). Theboard second from the right is configured with the Raspberry Pi camera module that could be used to forvision based scanning algorithms.

5.2 Decentralized Coordination

To achieve our design goal in creating an autonomous swarm, we must also design a system forthe agents to make coordinated decisions in a decentralized fashion. While much literature focuseson relatively simple tasks such as formation flight [38, 21], we intend to accomplish more complexcoordinated mapping and searching behaviours such as those described in [39, 40]. In the back-ground, we discuss DDDAS algorithms and D-RHC. Several other techniques for swarm controlhave been used throughout literature, including artificial potential functions (AFPs) [41, 42] andartificial pheromones, a derivation of AFPs [43, 44]. Ultimately however, we chose D-RHC as thebasis for our control mechanism as it is used in several proven mission critical systems, as afore-mentioned. Additionally, the flexibility of RHC control mechanisms in optimizing and altering thedecision making process is ideal for our application.

In our model, we formulate the optimization problem of D-RHC as a series of costs to beminimized and a set of constraints based mainly on the agent’s own state, the world state, thecurrent mission or task, and the state of its immediate neighbour. This technique is very similar toKevicky et al.’s work with D-RHC schemes in formation flight [21]. A general high level diagram ofhow our decision making software will be structured can be seen in Figure 6. Briefly, though thiswill be described in more detail later in the report, a knowledge database containing informationabout current agent states, the states of neighbours in the swarm, task related information, etc. isupdated through a manager, which receives information from sensory and communication inputs.An additional task manager will update necessary information in the knowledge bank. A managedoptimization function, represented by the cost manager, will then be modified by task costs inserted

9

and removed by the task manager. The cost manager will then use necessary information fromthe knowledge database to populate and submit the required costs and constraints to the D-RHCoptimization module at the appropriate time horizon. The D-RHC module will then compute anoptimal value and send appropriate feedback to flight controllers or abstracted movement functions.

This diagram parallels Kevicky et al.’s work in [21].

Figure 6: Software process diagram for each autonomous agent. Core functions are divided into severalkey modules. Sensory information and data from the swarm conglomerates in the knowledge managerand database. The knowledge manager delivers its information the cost manager and subsequently tothe Decentralized Receding Horizon module that computes the agents new trajectory. Additionally, theknowledge manager communicates with the task runner, which handles the bidding protocol.

5.2.1 Swarm Behaviour Core

Reynolds formulates a “boids” model for flocking behaviour [45] composed of 3 main laws. Theystate that each agent in a flock aims only to: (1) “keep an individual a certain distance away fromnearby flock mates to avoid collisions”, (2) “attempt to match velocity of an individual with thoseof nearby flock mates”, and (3) “attempt to stay close to nearby flock mates”. While we aim toextract more intelligent function than simple formation flight, to accomplish more complex tasks,we must first ensure that certain basic formation flight principles are obeyed. Building on theseprinciples, more complex strategies will be developed.

Keeping in line with the basic boids rules for swarm behaviour, we want to ensure that ouragents, while able to act on their own, follow these rules to ensure e�ciency. However, in ourmodel, various amounts of leniency will be given to the di↵erent rules. Particularly, (1) will befollowed strictly. (2) will have a high factor of leniency, particularly in heterogeneous systemswhere flight capabilities are varied, but it will still be enforced minimally to ensure the possibilityfor formation flight if needed. Lastly, (3) will be enforced so that the agents can stay within

10

communication distance of one another. If this distance needs to be broken, it can be by a highercost coe�cient, such as the need to return to base to recharge. However, because of the need tostay in communication to improve e�ciency, this cost will still be weighted heavily.

Using the boids model, we formulate these three laws as costs and constraints for our system(similar to [46] in basis). The first law of collision avoidance, since it must be matched strictly, canbe formulated as the constraint:

8j2neighbours distance(pi, pj) > �

min

(1)

Here, pi is the position of the agent for which the optimization function is being minimized,pj is the position of neighbour in the swarm, and �

min

is some constant amount of distance that,at minimum, should be kept between agents. Adding to this, we formulate the second law as thefollowing cost:

Alignmenti = |

~

Sv � ~vi| (2)

Where vi is the velocity of the current agent, and Sv is the average velocity of the swarm,determined as follows:

~

Sv =X

j2neighbours

~vj

||neighbours||(3)

Lastly, we formulate the cost of cohesion, ensuring that the agents stay within communicationrange for swarm behaviour, as the inverse of the nearness factor for a given agent (i), ��1

i , wherethe nearness factor is formulated as the following [40]:

�i = ↵e

d0rc + ↵

2

e

d1rc + · · ·+ ↵

ne

dnrc (4)

Here, {d0

, . . . , dn} is the distance from the current node to each of its n nearest neighbours,sorted from least distance to greatest distance. 1 > ↵ > 0 is a fading factor which puts moreemphasis on staying close to the agent’s nearest neighbours and less emphasis on trying to movecloser to the furthest neighbours. Finally, rc is the communication range of each node, assumed tobe constant throughout the swarm.

While the collision avoidance constraint and the velocity matching cost are somewhat intuitive,the nearness factor is a bit more complex. As such, we validated it with a simple cost minimizationscript in Python. We compared the e↵ects of varying numbers of distances to neighbours andcommunication ranges to demonstrate the e↵ects the algorithm has in determining a new bestposition during cost minimization as shown in Figure 7. We see that increasing the communicationrange, ensures that the agent will move to a position such that it can communicate with moreneighbours in the swarm.

5.2.2 Optimization Formulation

Using the boids costs and constraints, we can now formulate our D-RHC optimization problemgenerally as:

minimize w

c

�

�1

i + w

a

Alignmenti +P

cost2Extra cost(xi, {ey0, . . . , eyn})+P

costt2Tasks costt(xi, {ey0, . . . , eyn})

subject to 8j2neighbours distance(pi, pj) > �

min

c

1

(xi, {ey0, . . . , eyn}). . .

cm(xi, {ey0, . . . , eyn})

(5)

11

Figure 7: Here is a snapshot of two tests with minimization of the inverse nearness factor. Neighbourpositions (red markers) for this test were the 3D coordinates: (5, 5, 5), (5,17, 5), (30,5, 5), (50,50,50),(60,0,100). Initial position of the target agent (blue marker) was (5, 5, 5). For the first test (left), we used acommunication range of 10. The output position (green) with the communication radius visible as a largergreen circle, was (5.26228778, 11, 3.54206507) after cost minimization using the Nelder-Mead method [47].Using Euclidean distances, 2 nodes were found to be within the communication range, confirming the pic-ture. Increasing the communication range to 20, shifted the resulting output to (17.13596657, 10.24159703,6.00843219) and 3 neighbours were found to be in communication range. This demonstrates the validity thatthe cost minimization for nearness will attempt to encompass more nodes if allowed by the communicationrange, with an emphasis on already closer nodes. For this particular experiment an ↵ of .5 was kept stable.Other experiments were conducted, but left out due to space constraints.

Here, we define xi as the variable position for the current agent and {ey0

, . . . , eyn} are the predictedstates at the next horizon of the nearest n neighbours of the swarm. Agents keep these values inan updating knowledge table as in Figure 6. Tasks is the current set of tasks to be accomplishedwhich is variable and swappable: this will be discussed further in the following sections. Extra isassociated with a set of extra costs related to other control functions, such as collision avoidanceusing range-finders or a cost associated proportionally to the battery life and the distance to a basestation where the agent can recharge. This extra charge cost can be formulated simply as:

costcharge = d

�(1�battery)

base

(6)

Here, dbase

is the distance from the current agent to the base where it can recharge, � is somelarge constant to overcome any other costs, and battery is the fraction of battery life remaining.This cost could overcome any other given costs when the charge is low such that the agent has timeto return to the base to recharge. Finally, c

1

(xi, {ey0, . . . , eyn}). . .cm(xi, {ey0, . . . , eyn}) denote anyother possible constraints. These include physical constraints, such as that the evaluated position,xi, of the current agent at the next time horizon cannot exceed its possible real-world positionbased on maximum velocity, acceleration, and the time to the next horizon.

5.2.3 Mapping and Exploration

Adding to the core boids behaviour of the swarm, we attempt to create an e�cient swarm-basedmapping and exploration behaviour that is completely decentralized. We use an approach similar tothat of [40], but modified to match our overall cost minimization model. First, we assume that somebounds are given to the swarm and propagated, indicating a bounded area. In their paper, Shenget al. propose that each agent is in one of several discrete states: sensing, bidding, or travelling.

12

They divide the search area into a grid where only one agent investigates a grid cell at a time. Inthe sensing state, their robot maps its environment; in the travelling state, it goes to the next gridcell; in the bidding state, it determines which grid cell it should go to next. When an agent goesinto the bidding state, it calculates the best grid cell to search based on a bid maximization schemeand then sends out its bid to the rest of the swarm. If there are other bidding agents at the sametime and they receive the bid, but have a higher bid of their own, they will have sent this out,causing the first agent to recalculate its bid and rebid. Once a bid times out, the agent accepts thebid as having won it and goes to the travelling state to explore that grid block. In Sheng et al., abid is formulated according to:

B = maxj

gj (7)

where j is a grid block from the set of possible unexplored grid blocks and:

gj = w

info

Ij + w

dist

Dj + w

near

�ij (8)

�ij is the aforementioned nearness constraint from Equation 4, but predicted at the centre ofthe given grid block. Ij is the information gain of that grid block, Dj is the distance to the centreof the grid block from the current agent, and the w variables are the associated weights.

For mapping and exploration, we propose a similar functionality. Internally to each agent, aknowledge map of the exploration space will be kept, where information decays on a pre-definedtimescale after data acquisition for a continuous mapping functionality. We formulate a bid in thesame way as Sheng et al., using the aforementioned equations.

Rather than having dedicated bidding, travelling, and sensing states, we simply use a taskmanager to monitor certain task costs before bidding. We determined that once an agent hasbid on an area, it no longer has to bid until the area is covered. Once an agent has bid on anarea, defined here as a square cell (but could possibly be a varying polygon surface), the cost ofit exiting that area until it has been explored becomes exponentially high by an added task cost.It is possible to leave the area if for example, an agent needs to recharge, causing the cost of notgoing to a recharging platform to approach infinity. The exit area cost is added to the total costfunction of the agent by a task manager as seen in Figure 6. The task manager monitors this costas it approaches 0 to trigger bidding for another grid cell where it will add the cost of the new gridcell block.

The bidding process itself will remain largely identical to Sheng et al.’s method. Upon winninga bid, an update message will be propagated through the swarm to update agents’ knowledge mapsand mark the grid cell as tentatively covered. In the event of an exit, from the grid cell to recharge,the task manager can update the knowledge map and mark the grid cell as having no informationabout it.

Later on, additional cost functions can be added to perform other tasks such as target acquisitionand capture [48]. This could be helpful for specific search and rescue tasks where the swarm needsto try and coordinate delivery of supplies to a specific target or for herding tasks.

5.3 High Level Simulation

As a complement to the hardware prototype, software simulation of autonomous vehicle cooperationwill be developed. The simulation will serve two purposes. First, algorithms used for coordinationbetween agents for area mapping and exploration will be able to be tested and verified. Second, thesoftware developed to represent a node in simulation will be able to be ported to the hardware pro-totype to perform a real world examination. We first examined various options for existing swarm

13

simulators, including Stage [49], Gazebo [50], and Argos [51]. None of these simulators satisfied ourrequirements for code reuse and high level simulation. Many involved a custom scripting language,which did not allow for code reuse, and others involved low level physics simulations, requiring thedevelopment of a flight system. As such, we began the development of our own simulator usingUnity, a popular game engine, as a renderer for simulated world and agent states.

5.3.1 Simulator Architecture

We formulate our simulator in a client-server model to allow for the code re-use of core swarmfunctionality. This can be seen in Figure 8.

Figure 8: General architecture for the simulator. The core agent program functionality can remain the same,allowing for code re-use. The sensor, movement, and communication APIs of the agent will be swapped outfor simulation APIs. These APIs will communicate with the server rather than a flight controller, sensors, orother swarm members in a mesh. The central simulation server will update the world state, return simulatedreadings, and propagate packets to the appropriate swarm members both within communication range andafter packet loss filters.

The core of the simulator is the server. The server is where basic physics, communicationloss, and world state simulations are run. Additionally, an API will be constructed to abstractcertain layers of the program for communication with the simulator rather than directly with theother autonomous agents. To allow for as much code reuse as possible, we use the same corefunctional code of the autonomous agents while replacing communication, sensor, and movementAPI abstractions with a simulation API which makes the appropriate calls to the simulation server.

An example use case would be as follows. An external input to the simulator indicates amessage sent to all agents to, say, map a given area bounded by coordinates. The simulator willdistribute the message to those agents which are in range of the simulated communication. Theagents themselves will be pinging the simulation server for sensor readings such as GPS, ultrasonic,etc. These abstractions will be presented as API function calls such as getCoordinates(), etc. Inthe field, this API will be replaced with actual calls to various sensors which will be abstracted andpassed to the core functionality code in the same way.

Any communication between the agents will pass through the server allowing for basic simula-tions of packet loss and the proper nodes to be notified of the message as if they were connecteddirectly in the simulated topology. All world states will be conveyed as sensor readings to theagents as they request them.

14

The reason for this server based simulation is that it allows us to use the same external corefunctional code in the field, rather than having to constrain ourselves to a particular scriptinglanguage or framework that cannot be reused.

5.3.2 Game Engine

Currently the chosen game engine to display and simulate the world state is Unity [52]. The corefunctionality is basic enough for the desired simulations. Additionally, Unity allows cross-platformportability. Panda3d was also an option due to its higher level of customizability and simplicity.However, technical support for Unity is better and the amount of information for implementationis much larger.

5.4 Prototype Autonomous Vehicle

Finally, the end goal of the design project is to test the software developed in simulation on multipleautonomous vehicles to accomplish mapping tasks in a controlled environment. These hardwareunits will most likely be composed of low cost kits with a prepackaged flight controller. In fact,there are many hobbyist projects that use the Raspberry Pi to control and even act as a flightcontroller for UAVs [53]. However, due to time, cost, and legal constraints it may not be possibleto test on real UAVs. If UAVs are not possible, we intend to try to replace the UAVs with smallUGVs for the purposes of testing some of the flocking behaviour in the field. Our primary goal,however, is to test our algorithms thoroughly in simulation.

6 Plans for Next Semester

Next semester we plan on doing the bulk of the implementation. While we have already begunthe code outline and a large portion of the simulator, much remains to be done in implementingand testing the software in simulation. In parallel, we are looking to build the mobile hardwareunits to test our software in the field. This however, may not be feasible depending on cost andtime restrictions. Thus, our goal is to thoroughly test our software and algorithms in the simulatorwe develop. Additionally, as we have already begun doing, we plan on testing our software in ourminimal hardware communication test bed if the full autonomous agent is not possible.

7 Impact on Society and the Environment

Our system, along with several similar systems being developed at companies such as Google andAmazon [54], can have a significant impact on society and the environment. Already, we are seeing asignificant push to pass legislature in the USA regarding the use of UAVs, particularly autonomousUAVs. This can be seen in the bill which was signed into law: HR658: FAA Modernization andReform Act of 2012 [55], which forces the FAA to propose a plan for integrating UAVs into USairspace by 2015. Due to this, NASA is also developing protocols to autonomously keep UAVswithin designated tra�c patterns [54]. While these systems focus on singular agents, they certainlystill apply to our design. Our own swarm based system would also have a significant impact onsociety due to the its fully autonomous nature. For a live system to be accepted, it must meetmany safety standards within inhabited areas. Were it to be accepted, it would open up a myriadof lucrative opportunities for business, government use, and environmental protection.

The business opportunities are fairly straight forward and easy to imagine. As Amazon andGoogle propose with singular UAV systems, the swarm could be used for autonomously coordinated

15

delivery where the drones themselves decide the best path and could coordinate to pass alongpackages and rotate between recharging. Potentially, the autonomous swarm could be also used tocheaply map large portions of the Earth or other planets [56] without supervision. Furthurmore,this would give higher resolution or even live imagery for an application like Google Maps.

Governmental use again creates a significant impact on society. While some governments coulduse the autonomous swarm for potentially life saving purposes such as search and rescue or coordi-nated fire fighting, it is possible that an abusive government could use such an autonomous swarmto constantly monitor its citizens and even for automated capture or crowd control of potentialhuman targets as with [57]. These malevolent purposes should always be kept in mind when de-signing such a system, but we believe by commercial implementation of such as system, decisionscan be made to restrict the use of the autonomous swarm for such purposes.

To protect the environment, these autonomous systems could be used to monitor protectedwildlife habitats. Additionally, they could be used to map and survey areas that are being harmedby humans (such as heavily deforested areas in Brazil) so as to help determine and eliminate causes.With deforestation [58] and illegal tra�cking of endangered species [59] still a prevalent problemin many areas of the world, autonomous UAVs could potentially make a large di↵erence in theprotection of wildlife. In fact, swarm UAV systems have already been used in tracking taggedwildlife [60].

7.1 Environmental benefits

Autonomous swarm UAV systems could potentially impact the environment in an extremely pos-itive way, similar to the way electric cars could have in relation to the environmental impact ofthe automotive industry [61]. Package delivery, aerial imagery, etc. all use a significant amount offossil fuels and result in a heavy carbon footprint. Not only can the swarm UAVs reduce this costby using renewable energy stations to recharge, but they improve e�ciency by coordinating tasks,potentially reducing overall energy use in certain cases.

7.2 Use of Non-Renewable Resources

Our system is intended to be used with batteries that can be recharged with renewable resources likeas solar panels or wind farms. While certain parts of the UAVs may not be completely renewable,such as the batteries, this is still a significant improvement over fuel burning systems like planes,helicopters and trucks that are currently used to accomplish similar tasks. Future iterations of thedesign could even include a heterogeneous mixture of worker UAVs and base charging stations,which setup solar panels autonomously to recharge the swarm. During the manufacturing phase,there is bound to be more pollution and a higher environmental footprint, particularly in themanufacturing of battery packs [62]. Distribution potentially has the same impact as the industrythat the UAVs could be used to replace, because of the use of non-renewable resources for delivery.This could potentially be o↵set by self delivery of the UAV from the manufacturing facility. Manyparts of the drones could potentially be made out of recyclable materials and as such might not havea huge impact on the environment, but this is entirely dependent on the mechanical and materialdesign of the UAV.

7.3 Safety and Risk

As aforementioned, autonomous UAV systems carry a lot of risk. One of these systems could failand crash into a person or piece of infrastructure as has happened already in some cases [63]. Itis important to build comprehensive safety measures into an autonomous UAV production system.

16

Heavy consideration needs to be placed in preventing the breach and takeover of the swarm, whilestill providing a manual override for a pilot to safely guide the swarm in case of a software malfunc-tion. Additionally, making the systems themselves lightweight enough so any collisions or failureswould have a relatively minor impact, would also reduce potential risk.

8 Report on Teamwork

While both team members contributed fairly evenly to the project, Peter focused slightly moreon the simulator and decision making algorithms, while Matt focused more on communicationprotocols and the communication hardware.

9 Conclusion

This semester, we managed to plan out our design and architecture for our software, began runningtest experiments on a non-mobile test bed for communication and began work on a simulator fortesting our software. We did a significant amount of research surrounding autonomous roboticsand read a number of papers before choosing the right communication methods, the best hard-ware board, simulator, and decision making algorithms. In brief, we chose 802.11s as our meshnetworking protocol, the Raspberry Pi as our main processing board, the Ralink RT5370 chipsetfor communication, and D-RHC as a general base for our control mechanism. While this is anambitious project, here we propose steps toward a feasible solution.

The next step for the project is implementation and testing of our software against our simulatorand in our hardware test bed. With some insight into the field of autonomous robotics, we hopeto get as close to a real world implementation of swarmed agents as possible. Ultimately however,a fully implemented simulator and working simulations remain a top priority for the Spring.

Overall, our design project so far has focused on building a solid foundation for the successfuldevelopment and deployment of a UAV swarm. In a new and rapidly evolving field such as au-tonomous swarm robotics, there are a multitude of design vectors to process and optimize. Ourapproach of a decentralized, meshed networked, cost function based swarm should highlight thechallenges of autonomous vehicle systems. In conclusion, we have successfully established a thor-oughly researched specification and implementation outline. We hope to optimize our system,gather conclusions, and obtain publishable results in the near future.

17

References

[1] E. E. Lawrence and R. Latha, “A comparative study of routing protocols for mobile ad-hocnetworks,” 2014.

[2] C. E. Perkins and P. Bhagwat, “Highly dynamic destination-sequenced distance-vector rout-ing (DSDV) for mobile computers,” in ACM SIGCOMM Computer Communication Review,vol. 24, no. 4, 1994, pp. 234–244.

[3] T. Clausen, P. Jacquet, C. Adjih, A. Laouiti, P. Minet, P. Muhlethaler, A. Qayyum, andL. Viennot, “Optimized link state routing protocol (OLSR),” 2003.

[4] J. Chroboczek, “The babel routing protocol,” 2011.

[5] J. P. Lang, “B.A.T.M.A.N.” http://www.open-mesh.org/projects/open-mesh/wiki, accessed:2014-10-26.

[6] Z. J. Haas, J. Y. Halpern, and L. Li, “Gossip-based ad hoc routing,” IEEE/ACM Transactionson Networking (ToN), vol. 14, no. 3, pp. 479–491, 2006.

[7] D. B. Johnson and D. A. Maltz, “Dynamic source routing in ad hoc wireless networks,” inMobile computing. Springer, 1996, pp. 153–181.

[8] C. E. Perkins and E. M. Royer, “Ad-hoc on-demand distance vector routing,” in Proc. MobileComputing Systems and Applications (WMCSA), 1999, pp. 90–100.

[9] N. Beijar, “Zone Routing Protocol (ZRP).”

[10] V. Ramasubramanian, Z. J. Haas, and E. G. Sirer, “SHARP: A hybrid adaptive routingprotocol for mobile ad hoc networks,” in Proc. International Symposium on Mobile Ad HocNetworking & Computing, 2003, pp. 303–314.

[11] S. Bari, F. Anwar, and M. Masud, “Performance study of Hybrid Wireless Mesh Protocol(HWMP) for ieee 802.11s WLAN mesh networks,” in Proc. Computer and CommunicationEngineering (ICCCE), 2012, pp. 712–716.

[12] F. Darema, “Dynamic data driven applications systems: A new paradigm for applicationsimulations and measurements,” in Computational Science-ICCS 2004. Springer, 2004, pp.662–669.

[13] C. C. Douglas, J. D. Beezley, J. Coen, D. Li, W. Li, A. K. Mandel, J. Mandel, G. Qin, andA. Vodacek, Demonstrating the validity of a wildfire DDDAS. Springer, 2006.

[14] G. R. Madey, A.-L. Barabasi, N. V. Chawla, M. Gonzalez, D. Hachen, B. Lantz, A. Pawling,T. Schoenharl, G. Szabo, and P. Wang, “Enhanced situational awareness: Application ofDDDAS concepts to emergency and disaster management,” in Computational Science–ICCS.Springer, 2007, pp. 1090–1097.

[15] R. R. McCune and G. R. Madey, “Swarm control of uavs for cooperative hunting withDDDAS,” Procedia Computer Science, vol. 18, pp. 2537–2544, 2013.

[16] G. R. Madey, M. B. Blake, C. Poellabauer, H. Lu, R. R. McCune, and Y. Wei, “ApplyingDDDAS principles to command, control and mission planning for UAV swarms,” ProcediaComputer Science, vol. 9, pp. 1177–1186, 2012.

18

[17] J. Mattingley, Y. Wang, and S. Boyd, “Receding horizon control,” Control Systems, IEEE,vol. 31, no. 3, pp. 52–65, 2011.

[18] S. J. Qin and T. A. Badgwell, “A survey of industrial model predictive control technology,”Control engineering practice, vol. 11, no. 7, pp. 733–764, 2003.

[19] F. Herzog, Strategic portfolio management for long-term investments. Diss., EidgenossischeTechnische Hochschule ETH Zurich, Nr. 16137, 2005, 2005.

[20] T. Keviczky and G. J. Balas, “Receding horizon control of an F-16 aircraft: a comparativestudy,” Control Engineering Practice, vol. 14, no. 9, pp. 1023–1033, 2006.

[21] T. Keviczky, K. Fregene, F. Borrelli, G. J. Balas, and D. Godbole, “Coordinated autonomousvehicle formations: decentralization, control synthesis and optimization,” in American ControlConference, 2006, 2006, pp. 6–pp.

[22] T. Keviczky, F. Borrelli, and G. J. Balas, “Decentralized receding horizon control for largescale dynamically decoupled systems,” Automatica, vol. 42, no. 12, pp. 2105–2115, 2006.

[23] H. Duan and S. Liu, “Non-linear dual-mode receding horizon control for multiple unmannedair vehicles formation flight based on chaotic particle swarm optimisation,” Control Theory &Applications, IET, vol. 4, no. 11, pp. 2565–2578, 2010.

[24] J. Chroboczek, “Babel a loop-avoiding distance-vector routing protocol,”http://www.pps.univ-paris-diderot.fr/ jch/software/babel/, accessed: 2014-10-26.

[25] J. P. Lang, “BMX6 mesh networking protocol,” http://bmx6.net/projects/bmx6, accessed:2014-10-26.

[26] A. Tonnesen, T. Lopatic, H. Gredler, B. Petrovitsch, A. Kaplan, and S.-O. Tcke, “olsrd,”http://olsr.org/, accessed: 2014-10-26.

[27] cozybit Inc., “open80211s,” http://open80211s.org/open80211s/, accessed: 2014-10-26.

[28] Itseez, “Opencv,” http://docs.opencv.org/, accessed: 2014-10-26.

[29] Raspberry Pi Foundation, “Raspberry pi,” http://www.raspberrypi.org/, accessed: 2014-10-26.

[30] “Linux wireless,” http://wireless.kernel.org/en/users, accessed: 2014-10-26.

[31] M. Vipin and S. Srikanth, “Analysis of open source drivers for IEEE 802.11 WLANs,” in Proc.Wireless Communication and Sensor Computing (ICWCSC), 2010, pp. 1–5.

[32] G. R. Hiertz, D. Denteneer, S. Max, R. Taori, J. Cardona, L. Berlemann, and B. Walke,“IEEE 802.11s: the WLAN mesh standard,” Wireless Communications, IEEE, vol. 17, no. 1,pp. 104–111, 2010.

[33] IEEE Standards Association, “802.11-2012-IEEE Standard for Information technology–Telecommunications and information exchange between systems local and metropolitan areanetworks–Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) andPhysical Layer (PHY) Specifications,” 2012.

19

[34] G. R. Hiertz, S. Max, R. Zhao, D. Denteneer, and L. Berlemann, “Principles of IEEE 802.11s,”in Proc. Computer Communications and Networks, 2007, pp. 1002–1007.

[35] I. D. Chakeres and E. M. Belding-Royer, “AODV routing protocol implementation design,” inProc. Distributed Computing Systems Workshops., 2004.

[36] M. Bahr, “Update on the Hybrid Wireless Mesh Protocol of IEEE 802.11s,” in MASS, 2007,pp. 1–6.

[37] J.-P. Wang, B. Hagelstein, and M. Abolhasan, “Experimental evaluation of IEEE 802.11s pathselection protocols in a mesh testbed,” in Proc. Signal Processing and Communication Systems(ICSPCS), 2010.

[38] G. Vasarhelyi, C. Viragh, G. Somorjai, N. Tarcai, T. Szorenyi, T. Nepusz, and T. Vic-sek, “Outdoor flocking and formation flight with autonomous aerial robots,” arXiv preprintarXiv:1402.3588, 2014.

[39] S. Waharte, N. Trigoni, and S. J. Julier, “Coordinated search with a swarm of uavs,” in Proc.Sensor, Mesh and Ad Hoc Communications and Networks Workshops (SECON), 2009, pp.1–3.

[40] W. Sheng, Q. Yang, J. Tan, and N. Xi, “Distributed multi-robot coordination in area explo-ration,” Robotics and Autonomous Systems, vol. 54, no. 12, pp. 945–955, 2006.

[41] D. H. Kim, H. Wang, and S. Shin, “Decentralized control of autonomous swarm systems usingartificial potential functions: Analytical design guidelines,” Journal of Intelligent and RoboticSystems, vol. 45, no. 4, pp. 369–394, 2006.

[42] V. Gazi, “Swarm aggregations using artificial potentials and sliding-mode control,” Robotics,IEEE Transactions on, vol. 21, no. 6, pp. 1208–1214, 2005.

[43] H. V. D. Parunak, M. Purcell, F. C. S. SIX, and R. O’Connell, “Digital pheromones forautonomous coordination of swarming UAV’s,” Ann Arbor, vol. 1001, pp. 48 105–1579, 2002.

[44] J. A. Sauter, R. Matthews, H. Van Dyke Parunak, and S. A. Brueckner, “Performance ofdigital pheromones for swarming vehicle control,” in Proc. of the fourth international jointconference on Autonomous agents and multiagent systems, 2005, pp. 903–910.

[45] C. W. Reynolds, “Flocks, herds and schools: A distributed behavioral model,”SIGGRAPH Comput. Graph., vol. 21, no. 4, pp. 25–34, Aug. 1987. [Online]. Available:http://doi.acm.org/10.1145/37402.37406

[46] Y.-W. Chen, K. Kobayashi, X. Huang, and Z. Nakao, “Genetic algorithms for optimization ofboids model,” in Knowledge-based intelligent information and engineering systems. Springer,2006, pp. 55–62.

[47] D. M. Olsson and L. S. Nelson, “The Nelder-Mead simplex procedure for function minimiza-tion,” Technometrics, vol. 17, no. 1, pp. 45–51, 1975.

[48] P. Pirjanian and M. Mataric, “Multi-robot target acquisition using multiple objective behaviorcoordination,” in Proc. Robotics and Automation (ICRA), vol. 3, 2000, pp. 2696–2702.

[49] R. Vaughan, “Massively multi-robot simulation in stage,” Swarm Intelligence, vol. 2, no. 2-4,pp. 189–208, 2008.

20

[50] N. Koenig and A. Howard, “Design and use paradigms for gazebo, an open-source multi-robotsimulator,” in Proc. Intelligent Robots and Systems (IROS), vol. 3, pp. 2149–2154.

[51] C. Pinciroli, V. Trianni, R. O’Grady, G. Pini, A. Brutschy, M. Brambilla, N. Mathews, E. Fer-rante, G. Di Caro, and F. Ducatelle, “ARGoS: a modular, parallel, multi-engine simulator formulti-robot systems,” Swarm intelligence, vol. 6, no. 4, pp. 271–295, 2012.

[52] Unity3d, “Unity,” http://unity3d.com/, accessed: 2014-11-20.

[53] A. Baker, “The MagPi: Issue 19 - Building an airborne autobot,”http://www.themagpi.com/issue/issue-19/, accessed: 2014-11-1.

[54] C. Dougherty, “Drone developers consider obstacles that cannot be flown around,” The NewYork Times, 2014. [Online]. Available: http://www.nytimes.com/2014/09/01/technology/as-drone-technology-advances-practical-obstacles-remaiT

[55] U. S. House of Representatives, “Reform Act of 2012 (FAA Reauthorization Act), Pub. L. No.112-95, § 211, 126 Stat. 11, 44,” Report from the ADS-B In Aviation Rulemaking Committeeto the Federal Aviation Administration.

[56] W. Truszkowski, M. Hinchey, J. Rash, and C. Rou↵, “NASA’s swarm missions: The challengeof building autonomous software,” IT professional, vol. 6, no. 5, pp. 47–52, 2004.

[57] S. Gallagher, “Riot control drone armed with guns and lasers,” Wired Magazine, 2014.[Online]. Available: http://www.wired.co.uk/news/archive/2014-06/20/skunk-octocopter

[58] A. Baccini, S. Goetz, W. Walker, N. Laporte, M. Sun, D. Sulla-Menashe, J. Hackler, P. Beck,R. Dubayah, and M. Friedl, “Estimated carbon dioxide emissions from tropical deforestationimproved by carbon-density maps,” Nature Climate Change, vol. 2, no. 3, pp. 182–185, 2012.

[59] L. Wilson-Wilde, “Wildlife crime: a global problem,” Forensic science, medicine, and pathol-ogy, vol. 6, no. 3, pp. 221–222, 2010.

[60] A. Jensen and Y. Chen, “Tracking tagged fish with swarming unmanned aerial vehicles usingfractional order potential fields and kalman filtering,” in Unmanned Aircraft Systems (ICUAS),2013, pp. 1144–1149.

[61] T. R. Hawkins, O. M. Gausen, and A. H. Strømman, “Environmental impacts of hybrid andelectric vehicles, a review,” The International Journal of Life Cycle Assessment, vol. 17, no. 8,pp. 997–1014, 2012.

[62] L. Gaines and M. Singh, “Energy and environmental impacts of electric vehicle battery pro-duction and recycling,” SAE Technical Paper, Tech. Rep., 1995.

[63] A.P., “Dutch tourist drone pilot fined for yellowstone flight,” BBC News, 2014. [Online].Available: http://www.bbc.com/news/world-us-canada-29420039

21

A mesh.sh

#!/bin/bash

MESH_ID="MeshID"

MESH_IFACE="mesh"

CHANNEL="1"

IP="192.168.10."$1

if [ "$#" != "1" ]; then

echo "Give a mesh number arg"

exit

fi

echo "Creating mesh interface: "$MESH_IFACE

sudo iw dev wlan0 interface add $MESH_IFACE type mp

# Get rid of wlan0

sudo iw dev wlan0 del

echo "Setting mesh channel: " $CHANNEL

sudo iw dev $MESH_IFACE set channel $CHANNEL

#echo "Bringing up mesh interface"

#sudo ifconfig $MESH_IFACE

# 192.168.10.0/28 subnet

echo "Setting mesh static ip: " $IP

sudo ifconfig $MESH_IFACE $IP

echo "Joining mesh network with id: " $MESH_ID

sudo iw dev $MESH_IFACE mesh join $MESH_ID

# To remove the interface:

# sudo iw dev mesh0 del

echo "Done , showing station dump"

sudo iw dev $MESH_IFACE station dump

echo "Showing mpath dump"

sudo iw dev $MESH_IFACE mpath dump

22

B install.sh

#!/bin/bash

NODE_NUM=$1

NAME="start -mesh"

PATH="/etc/init.d/"

if [ "$#" != "1" ]; then

echo "Give a mesh number arg"

exit

fi

# Overwrite file

echo ’#!/bin/sh ’ > "./" $NAME;

# Append run mesh command

echo "sudo /home/pi /802.11s-pi/mesh.sh $NODE_NUM" >> "./"$NAME;

# Echo the rest of the commands

echo ’Run the following commands:’

# Copy script into init.d

echo "sudo cp ./ $NAME $PATH"

# Make the script executable:

echo "sudo chmod 755 $PATH$NAME"

# Register script to be run at startup:

echo "sudo update -rc.d $NAME defaults"

# Remove temp script

echo "rm -f "./"$NAME"

# Stop script from running at startup

#sudo update -rc.d -f $NAME remove

23