DroneCharge: A Python Framework for AutomatedQuadcopter Charging

Miroslav Zoricak

IT-University ofCopenhagenmzor@itu.dk

Kamil Androsiuk

IT-University ofCopenhagenkami@itu.dk

Emil Bech Madsen

IT-University ofCopenhagenaebm@itu.dk

ABSTRACTIn recent years, drones have moved out of the science labsand into everyday life, with several commercialized dronesreadily available in stores everywhere. Businesses are start-ing to consider the use of drones in their day-to-day business,such as Amazon recently revealing their intent to providedelivery by quadcopter within a few years. While drones cur-rently have many use-cases, their limited battery life severelyimpedes their usage for long-running tasks such as extendedflight.

While battery-life will surely increase as technology advances,we argue that this problem can be solved in other ways thanmere brute force. In this report, we present a python frame-work for automated quadcopter charging named DroneCharge.With it, a series of drones are utilized to form a swarm ofdrones capable of cooperating to execute tasks. Using thisframework, drones developers using commercially availabledrones are able to add automated charging and task coopera-tion to their repertoire with very little extra code.

Author KeywordsDrone, swarm, automated charging, quadcopter, framework,task execution, cooperation

INTRODUCTIONAerial drones, such as four-propeller quadcopters or single-propeller mini-helicopters, have a lot of potential use, butthe use of commercially available drones is limited by theshort amount of time they can stay airborne before requiringa recharge. Many applications could be considered, where adrone would need to stay airborne for long periods of time todo various tasks. For instance, monitoring areas using varioussensors or spreading pesticide over a field.

Although battery life will increase as technology advances,currently there is need for alternatives. If drones couldrecharge themselves or otherwise could be sustained in the air,this would increase the usage scenarios of drones significantly.Our idea is not to have drones stay airborne indefinitely, butto have the tasks that the drones are performing continue inspite of the need for recharge. This could either be doneby having other (fully-charged) drones take over the task orby allowing the drone to resume its task after it has beenrecharged. In this report, we outline a framework aimed atsimplifying this functionality for drone application develop-ers. We focus on quadcopters such as the AR Drone or theCrazyflie nano-copter, but see no reason this would not work

on any aerial drone capable of stationary hovering such astoy helicopters.

RELATED WORKWhile we did not find previous work that focused on the sameproblem, we found several projects that all did some part ofwhat we wanted, e.g. automated landing, inductive chargingor drone swarms.

Burkle et. al proposed the idea of a swarm of drones fulfillinga task rather than a single drone in their article Towards Au-

tonomous Micro UAV Swarms [5]. They suggested a systemfor inter-drone cooperation to seamlessly orchestrate severaldrones with different types of sensors in an environment.They also utilized simulation to test their system. This sys-tem was far larger than our solution and encompassed severalother aspects that we did not consider. It inspired the ideafor us to simulate drone movement during development for amuch more efficient development process.

Sima Mitra presented an Autonomous Quadcopter DockingSystem [8] that allowed drones to return to a charging stationusing computer vision for locating the docking station. Init, she showed that autonomously returning to a chargingstation was fully possible without a fixed locationing system.Although our framework expects some kind of locationingsystem for the airborne drones, this was useful as it demon-strated the automated landing on a specified target as batterydepletes. The inherent limits of the reliance on computervision were, however, not desirable.

Both Altug et al. [2] and Ducard et. al. [6] demonstratedthe use of visual feedback for positioning and autonomouscontrol of a drone. This was useful for the practical part ofthis project in which a Kinect was used to track drones inorder to autonomously perform tasks.

Also relevant is the work of The Intelligent Mechatronics Labat Boston University, in which a conductive surface was usedto charge a drone without human interaction [4]. This is ofparamount importance in terms of realizing this solution, asfull automation would not be possible unless the drone couldcharge itself without human interference.

Finally, as an alternative to drone swarms, where batteryissues are solved by an abundance of drones, Abidali et. al. [1]offered an alternative through the use of solar power. In theirreport, they outlined the design of SolarCopter, the worlds

1

Aut. UAVSwarms [5]

AutonomousDocking [8]

VisualFeedback [2] [6]

InductiveCharging [4] SolarCopter [1] DroneCharge

Visual control ( )

Auto-landing ( )

Notion of tasks

Extensibility

Inter-drone cooperation ( )

Eval. using simulation ( )

Drone auto-charging ( )

Sustainable

Drone autonomy ( )

Inexpensiveness ( ) ( )

Table 1. Research Topics. Checkmarks in parentheses were less significant to the project in question.

first solar-powered quadcopter capable of sustained flight.

Burkle et al. focused primarily on swarm usage and capa-bilities, but mentioned very little about how the actual re-placement of the drones would work. We left the executionof a task as an extensible abstract concept, and specificallyfocused on providing automatic drone-swapping to imple-menters of these tasks while including implementation ofbasic tasks such as movement and landing.

Ducard et. al. and Altug et. al. both showed that dronecontrol through the use of a visual feedback system waspossible, but the actual execution of tasks were highly specificand non-extensible for the common developer. We aimed atallowing developers the ability to easily define and performtasks with drones, regardless of their tracking system.

Sima Mitra focused on computer vision to return to a charg-ing station. We noted that there are inherent problems inComputer Vision such as the need for an unobstructed viewof the intended target, and argued that absolute positioningschemes such as GPS or external tracking of a drone wouldbe more suitable, especially for swarm-based task executionin which the system needs a complete view of the operatingarea to simultaneously use several drones.

While the work of Boston University indeed showed that con-ductive charging of aerial drones was possible, we primarilyfocused on getting a drone to the charging station, and leftthe addition of conductive charging as a means to furtherautomate task execution efforts.

The SolarCopter provides an alternative to the drone swarm,but adds complications in regards t o drone size and weatherrequirements. One could imagine a mixture, however, inwhich a solar powered drone could charge conventional dronesand act as a swarm staging area.

Table 1 highlights the research topics of the various solutions.While we did not attempt to achieve sustainable drones, wedid, to some degree, deal with all other application areas thatare addressed by the above mentioned solutions. The check-marks means that the paper or project addressed the researchtopic in some way other another. Checkmarks in parentheseswere less significant to the project in question, such as in thecase of Visual Control for DroneCharge, which was used asa locationing system but as such not very important to theframework itself.

METHODOLOGYThe project was developed in two parts; a practical part anda theoretical part. The theoretical part consisted of a sim-ulation of an ideal drone, with which the framework wasincrementally developed. The practical part consisted of avisual locationing system using Microsoft Kinect12 [3], withwhich a quadcopter drone was controlled using the nativeSDK. Initially, a Crazyflie3 drone was used for the practicalpart, but after some difficulties with stability, it was decidedutilize a Wizard-of-Oz [7] approach for drone movement.This allowed us to focus on the framework itself rather thanimplementation issues of a single type of drone. Once theframework was in place, we were offered the use of an ARDrone 4. This enabled us to evaluate our solution through theimplementation of a driver and associated tasks for a specificdrone.

While others such as Mitra and Ducard et al. before ushad attempted to do various parts of this project in isolation,DroneCharge brought together the components in order tocreate a practical solution on a more approachable level. Theswarm concept presented by Burkle et al. also utilized many1http://www.microsoft.com/en-us/kinectforwindows/2https://github.com/OpenKinect/libfreenect3http://www.bitcraze.se/crazyflie/4http://ardrone2.parrot.com/

2

of the same concepts, but in a very large-scale and hardware-expensive fashion out of reach of the common developer.We relied on the various proof of concepts shown by ourpredecessors and envisioned a system in which the variouscomponents were useful without being out of reach for theaverage developer in terms of hardware and time.

DRONECHARGEVisionWe envisioned DroneCharge as a framework to be used bydrone application developers to easily achieve task-executionusing swarms of drones, and as such needed to fit any andall suitable drones. As all drones have their own native APIsfor control, this meant that a driver-oriented architecture hadto be utilized. While the drivers provided us with meansof controlling the drone, we also needed a way of hookinginto the tasks performed by the drones in order to seamlesslyexchange drones when required. This was done by havingdevelopers define tasks in terms of a series of subtasks, andto have our framework execute those tasks in the right order.That enabled us to hook into the execution of a task and toexchange drones when a recharge was needed. As such, theenvisioned system would have the following functionality:

• Automatic recharging of battery-depleted drones• Task pausing and resumption• Drone swapping between tasks• Simplified usage of heterogenous drones for task execution

ArchitectureOur overall architecture is depicted in Figure 1. The mostinteresting concepts are the ideas of drone, task and envi-ronment. A task is performed in an environment that hasa number of drones at its disposal, all of which are config-ured by the individual developer. As a developer, you wouldimplement drivers for your specific drone that inherits fromthe Drone class, and either utilize the built-in tasks or createyour own extension of the Task class. A drone instance repre-senting each physical drone is then added to the environmentalong with their respective charging locations, as well as anynumber of tasks to be performed.

Figure 1. DroneCharge architecture

Language SelectionWe looked at the language support in the libraries of thedrones we considered good match for our goals and it turnedout that most of them have either Python wrappers, or are

written in Python. In addition, it is the case that Pythoncode can easily be ported to other platforms such as .NETthrough IronPython or Java through Jython. This enablesthe driver implementors to write the actual drivers on almostany other platform, which makes the framework compatiblewith most drones, but also allows it to retain a very high levelof abstraction and code readability. One possible drawbackof Python is that because it is an interpreted language, it isslower than some other platforms, but in our testing we didnot perceive this as a real limitation.

It is also the case that Python is very loosely typed, so itallows for a lot of flexibility in the definition of driver andtask interfaces.

EnvironmentThe notion of environment provides an abstraction over thephysical environment. We introduced the idea of an abstractcoordinate system, which lets the implementers use any unitor orientation (GPS coordinates, meters, pixels, or completelyabstract units) as long as they stick to the same unit through-out the drone driver and task definitions. Because it is thedrone driver which is responsible for both supplying andconsuming the current and target positions of the drone, theabstract unit system does not limit the framework to anyparticular assumptions about the positions.

DriversDrivers are, as is the definition, a way for the system tointeract with the hardware devices connected to it withoutknowing the hardware specifications at compile-time. In ourcase, those hardware devices are drones and their locationingsystem. Any developer using DroneCharge must implementa class extending from the Drone-class that implements nec-essary features such as movement as well as battery- andlocation-queries. These are called drone-drivers. Whether adrone has positioning built-in or if it uses a tertiary systemsuch as tracking with a Microsoft Kinect is irrelevant, as longas the drone-driver has the ability to obtain its position. Adrone driver has to be able to identify the position of its as-signed physical drone with a specified precision and performmovement to a target position set by the framework.

TasksInstances of the Task define how individual steps of a taskare performed. They contain a list of capabilities required toperform the task such as movement or video-recording, aswell as instructions on how to perform the task. DroneChargecomes with a limited number of built-in tasks such as move-ment and landing, but any task can be performed by extendingthe task class and explicitly performing the task through thecommands defined in the drone-drivers. The framework willonly assign drones to perform the task if they meet the re-quirements for it, so you are guaranteed to have the right typeof drone as long as your task and required capabilities arealigned. As an example, a custom driver for a drone with avideo camera attached to it could implement a function calledRecordVideo as well as contain the capability recordvideo.You could then define a task whose execution consisted ofturning on a video camera. By specifying recordvideo as a

3

required capability of the task, the framework would not per-form the task until a drone with said capability was available.The framework does not make any assumptions about thetasks, it is the task instance, that is responsible of decidingwhat to perform and when it is complete. This way a user ofthe framework can implement both, the task and the dronedriver and so the task will know how to perform specificfunctionality with a particular drone.

The Task Tree

By allowing tasks to be added to other tasks, we obtained atree-structure view of tasks which enabled us to do a depth-first search traversal of tasks, and in that way achieve a soundlogical structuring of tasks and subtasks. An example of sucha tree is depicted in Figure 2. The tree is traversed in such away that only leaf-node-tasks are actually performed. Thisenabled developers to logically split their tasks into subtreeshowever they saw fit and gave us increased flexibility. Whena drone was to take over a task, a replacement-task couldeasily be inserted in that tree that moved the drone to theposition of the depleted drone and performed other actionssuch as copying the state of the previous drone, turning onsensors etc.

Figure 2. The Task Tree – NB: Nodes are not ordered in a DFS-like

manner as is the case internally

Assumptions and requirementsWhen using the DroneCharge framework, developers had tobe aware of the assumptions and requirements made in termsof the capabilities and implementation of the drivers and thedrones themselves.

For the drone drivers, we assumed that a drone or its drivercould report its battery level in a linear fashion. That is,the battery could not be reported as full until the batterywas depleted as was the case with some drones such as theCrazyflie. Furthermore, there had to be some way to obtainthe position of the drone in relative or absolute terms. Adeveloper also had to define at what battery level the dronewas considered to be low on battery. It was also required thata charger was available for each individual drone.

In terms of defining tasks, we made the requirement that anysingle leaf-node in the tree could not require more batteryto perform than was considered to be the low battery limit.That is, if the drone was considered to be at low batterywhen it reached 10%, all individual subtasks had to requireno more than 10% power to perform. Finally, the point ofoperation that was the farthest from the charging station couldnot require more than the low battery level to move the dronefrom back to the charger.

Additionally, it was noted that a drone partaking in the execu-tion of a task had to have all capabilities needed to performall subtasks in the task tree in which the current subtask islocated. This is upheld by the framework itself, as it will notchoose drones lacking the capabilities. This ensured that wewould not have to exchange drones due to capabilities butonly due to battery levels.

EVALUATIONIn this section, we will describe the experiences we had us-ing the framework for three separate applications; initialexperiments using the Crazyflie nano copter, a Wizard of Ozapproach in which the frameworks correctness was verified,as well as a practical example using the more suitable ARDrone. Next, we present the results of a survey posted onvarious drone-related internet forums in order to gauge inter-est in the framework. Finally, we move on to evaluating thevarious properties of the architecture and the degree to whichthe framework does as envisioned.

Framework Usage ExperimentsInitial Experiments - The Crazyflie

In the initial stages of this project, we experimented with de-veloping drivers for the Crazyflie nano quadcopter, using theMicrosoft Kinect for location. These efforts provided us withvaluable knowledge on the current state of the art in regardsto drone capabilities. Specifically, while the Crazyflie in andof itself was a suitable drone for freestyle flying, its ratherlimited control mechanisms and lack of hovering functionseverely impeded its use for the DroneCharge framework.It was very difficult if not impossible to make it land closeenough to a charger for any real use, and task execution wasunsafe at best. On a more positive note, it also gave us con-fidence that our driver-oriented architecture was correct, asthe drivers were relatively straightforward to implement —We just could not trust the drone to do as we commandedit. That being said, if the drone firmware was more mature,it would not have been such a problem to employ it in ourframework. It also helped us define the granularity of theinterface between the framework and the drone by givingus some experience with operating drones programmatically,and some changes were made to the drivers in regards to theabstraction-level of drone control.

Simulated approach - Wizard of Oz

While our initial experiments gave us some more ideas onhow to define the drone drivers, it did not allow us to physi-cally test the framework. Instead, we focused on developingthe framework by relying more on simulation and visualiza-tion for validation. We created visualization tools to illustrate

4

the task tree as a coloured graph, and created a usage scenarioin which a Microsoft Kinect tracked a drone. Rather than thedrone moving itself, a Wizard of Oz approach was used inwhich a human actor purposefully moved the drone in thepattern indicated by the framework in order to perform thetask. This was done using the video-feed from the Kinect andadding overlays with markings for the drone and its targetposition. For a video demonstration of the wizard of oz, weuploaded a video on YouTube which can be found in thefootnotes5. A screenshot of the video-feed with the overlaycan be seen in Figure 3.

This approach allowed us to verify that the framework wouldact as intended provided that the drivers being used wereimplement as per specification. While it was not as definitiveproof as a real-life application, it provided us with enoughverification to move on to a real drone.

Driver Implementation - ARDrone

Once the framework was in a relatively stable state, we wenton to evaluate the framework by using it with an AR Drone.We kept the Kinect for tracking, and implemented the driverfor the AR Drone. This was really straightforward, since wealready had a driver for the Crazyflie. Where the Crazyfliewas too unstable to reliably move around, the AR Dronehad none of these problems. since the AR Drones API wasessentially just a drop-in replacement, we only needed toimport the AR Drone library6 and adapt the Crazyflie driverwith a couple of lines of code.

Figure 3. Framework verification using the Wizard of Oz approach for

drone movement.

The bulk of driver implementation was the translation be-tween the locationing system into the Frameworks coordi-nates and vice versa. Because we had already written all ofthis for Crazyflie, swapping it for the AR Drone was donein just a couple of hours with all the testing included. Apartfrom the method and class names that had to be changed,the only difference was in how the tilt angle is normalized5DroneCharge: https://www.youtube.com/watch?v=32yjwRk SrM6ARDrone: https://github.com/venthur/python-ardrone

before being passed on to the driver, which was just a trivialmathematical operation. The AR Drones firmware has provento be much more stable than the Crazyflies. The drone wasable to hold its position when asked, and responded to ourcommands well, which quickly gave us a working prototype.Figure 4 depicts an image of the drone being controlled bythe framework. A video of the working prototype followinga series of movement tasks can be found in the footnotes7.

Figure 4. AR Drone controlled by the framework

All in all, the driver was simple to implement, although we ad-mittedly did have prior knowledge of the assumptions madefor the drivers which simplified the process. However, theamount of code written to create the driver was almost negli-gible which speaks to the power of the approach. The codethat we did have to write we would have written in any caseif we were to do programmatic drone control.

Developer surveyTo gauge whether this would be useful for real-world develop-ers, we posted a survey along with a description of the systemon several of the largest drone-development internet forums.Although only a limited amount of developers replied, fivein total, we felt comfortable that the level of interest wasadequate.

When asked if the proposed framework seemed useful, threedevelopers replied that they either agreed or strongly agreed,one replied neutrally and one developer disagreed. Whenasked whether they had ever faced implementation issues thatthis framework would solve, three developers were neutralwhile one developer agreed and another strongly agreed. Fi-nally, when asked if they would be interested in using such aframework, three developers agreed, one developer stronglyagreed and only a single developer disagreed.

One developer gave us some useful feedback on our initialideas for drone positioning. More specifically, we initially as-sumed that most drones could remain somewhat stationary ata location. The developer noted that drift would influence the7DroneCharge: https://www.youtube.com/watch?v=Ei9mQTNHUgA

5

position, which caused us to alter our approach to movementto take this into account.

All in all, we believe it is safe to say that the interest inautomatic charging of drones is present, although responsesmay have been skewed by the possibility that only interesteddevelopers replied to the survey.

Finding the Right Level of AbstractionIn the beginning of the project, we wanted to also simplifydrone-control implementation by only requiring the devel-oper to implement atomic functions such as a command tomove forward, fly up or down, or left or right. We wouldthen supply high-level commands such as move to specificcoordinates free of charge. However, we soon realized thatdrone control varies based on the type of drone, and thatit was best to leave the specifics of controlling the droneto the implementer. While this left more responsibility tothe implementer, which is arguably a negative property of aframework, it added a necessary degree of flexibility. If wewere to develop high-level commands, it would likely lead toless optimized flying routines and glitchy movement. Lettingeach individual developer do this allowed for very optimizedflying for each individual type of drone, while keeping allthe benefits of the framework routing. We also argue, thatany drone implementer would need to implement drone con-trols to programmatically utilize drones in either case, so theonly thing our framework would then require, was that thecontrol-code was written in a different location.

Assumptions and Ease of UseAs mentioned, we make several assumptions about both thedriver implementation and the drones that are capable of usingthis framework. As a result, the ease of use, which shouldbe a prime target for any framework, suffers. For example,knowing that individual tasks must not exceed the low batterylevel in terms of power usage is of paramount importance,but is not upheld in any way in the framework itself. Animplementer would need to read documentation in order toknow how to implement a task properly. Conclusively, theuse of assumptions diminishes the level of intuitiveness ofthe framework.

FlexibilityThe resulting framework is highly flexible. Theoretically, anytype of copter-drone could be used in the framework with anyfeasible type of locationing system. Even if the movementprecision was very low, tasks that do not require very highmovement precision could still be performed by expandingwhat constitutes a movement task as completed. For instance,by implementing a RoughMovementTask which would beconsidered complete if the drone came within a certain rangeof the target. However, as the main purpose of the frameworkis to allow for recharging of drones, practicality demands thatthe drone be capable of landing within a relatively small areaif automated charging was ever to occur.

Recovery OptionsCurrently, there are no fallback procedures if a drone entersan emergency state. This means, that if a drone was to some-

how become unresponsive, e.g. by crashing into an obstacle,recovery is left solely to the developer. The main issue herestems from the fact that if we were to do recovery operationson the drone, that would mean that the drone was responsive,in which case the framework might as well continue with taskexecution.

On the other hand, if a drone were to be caught in a task, sayfor instance because a movement task attempted to fly thedrone through a wall, there are no built-in contingencies toensure that the task is ever completed. However, this could behandled in the drone driver by detecting abnormal behaviourand altering the route to the target.

Collision Detection and Environment MappingCurrently, there is no notion of environment mapping. Thismeans that for the framework to function, the area of opera-tions must be a clear area with no objects in the way. Thisis naturally not a practical solution for real world tasks, butwas decided for the purpose of simplicity. That there beno objects in the zone includes other drones, which causesproblems when having several drones performing tasks orswapping with each other at the same time. This is, however,mainly a smaller issue as collision detection is something thatis accounted for but was left as an additional module shouldtime permit.

Level of fulfillmentWe argue, that the framework set forth in this report fulfillsthe presented goals; it allows drone implementers to addautomatic recharging and swarm behaviour to their drone-functionality with an acceptable level of additional code.While it does require the developer to adapt to our system oftask execution rather than plug into their existing task execu-tion methods, we argue that it is a small price to pay for thebenefits gained by using DroneCharge.

DISCUSSIONIn this section, we suggest improvements and alterations tothe framework and discuss solutions to various issues men-tioned in the evaluation.

Collision DetectionCollision detection is a very important lacking feature in theframework. It could be done by utilizing the fact that eachdriver constantly attempts to get the drone to a specified target.The framework knows the location and target of each drone,and could thus detect possible collisions and alter the targetposition temporarily for the colliding drones. This wouldalter the routes of each individual drone avoid their collision.This would be the case if the drones themselves did not haveany sort of collision detection built-in. If a drone had that,then it would be a matter of including it in the movementloop in the individual driver.

Environment mappingTo add environment mapping to the framework, we couldintroduce the capability of adding shapes to the environmentsuch as cubes or cylinders to represent objects. The frame-work could then easily alter routes to avoid collision with

6

these objects during task execution. If an implementationused a visual-based locationing system these items could bedynamically tracked through image-recognition.

Recovery OptionsAs is stated, there is no notion of contingency planning. Ifa task never completes, the drone would simply run out ofbattery and fall out of the sky. A few things could be done toalleviate this.

First, the framework should be made capable of determiningwhether a task is stuck. This could be done, for instance, bymeasuring battery usage or by having the developer estimatethe time this task would take to complete by a certain drone.Given this capability, the framework would be able to attemptalternate actions. As tasks need not necessarily be aboutmovement, this alternate action differs from task to task. Itwould be necessary to allow for the developer to implementcontingency tasks if the task fails to complete. In a taskfailing to turn on a camera, the appropriate contingency plancould be landing and informing the developer, or turningdown the quality of the recording.

Second, it should be possible for the framework to alert de-velopers in some kind of UI of the state of the drones. Thisway, if a drone becomes unresponsive, the framework can tellyou exactly where this happened so that the developer can gofind the drone. In a more futuristic approach, a specializeddrone could even go collect it.

Automatically Checked AssumptionsAs mentioned in the evaluation, we do not check that ourassumptions are actually true in the drivers and tasks definedby the individual developer. What would be optimal is ifwe could add compile- or runtime checking to ensure thatthe tasks and drivers implemented by the developers upholdthese assumptions. This could be done, for instance, by ex-plicitly requiring that developers estimate the battery usage ofeach individual task. Naturally, different detection-strategieswould need to be constructed for each assumption.

Alternative UsesOn December 2nd, 2013, Amazon announced its projectAmazon Air Prime, in which drones were to be used to de-liver packages directly to the customer. The main problem,however, remained that the range of drones was limited, andpackages had to be within 12 kilometers of the amazon stor-age facilities. If Amazon was to make this into a real product,they would need new staging areas all over the city to ad-equately cover it. This would require specialized routingsoftware to hop between these staging areas to get to thedesired location. However, with only minor alterations toDroneCharge, this could be implemented at little to no cost.When a delivery drone ran out of power, DroneCharge couldautomatically send it to the nearest charging station, at whichpoint another drone could take over the task or the originaldrone could recharge and resume it. While not the intendedusage for DroneCharge, it certainly would be suitable.

CONCLUSIONIn this report, we have outlined the vision, design, and im-plementation of the DroneCharge framework for automatedquadcopter charging. We discussed various strengths andweaknesses of the framework, and suggested ways to im-prove said weaknesses.

In conclusion, we argue that the DroneCharge framework ful-fills its vision; it is capable of automatically returning dronesto a charging station during a task, and have that task bepaused and resumed by either a secondary drone or the samedrone upon battery-replenishment. The framework allowsdevelopers to view their heterogenous drones as a swarm ofdrones with various capabilities capable of executing taskstogether. Through the use of DroneCharge, drone developersare able to perform long running tasks despite the need toreplenish their drones, which markably extends the potentialuse cases for both commercial and non-commercial drones.

ACKNOWLEDGEMENTSWe would like to thank the the following people for theircontributions to this project; Thomas Pederson and ShahramJalaliniya for feedback and guidance, Sebastian Buttrich forsupplying us with the necessary hardware and for initial in-put on drone recharging, as well as John Paulin Hansen forallowing us to use his personal AR Drone.

REFERENCES1. A. Abidali, I. Burba, P. J. F. Fani, G. Kowfie, and

K. Wojewoda. Solarcopter, 2013.

2. E. Altug, J. P. Ostrowski, and R. Mahony. Control of aquadrotor helicopter using visual feedback. In Robotics

and Automation, 2002. Proceedings. ICRA’02. IEEE

International Conference on, volume 1, pages 72–77.IEEE, 2002.

3. P. Benavidez and M. Jamshidi. Mobile robot navigationand target tracking system. In System of Systems

Engineering (SoSE), 2011 6th International Conference

on, pages 299–304. IEEE, 2011.

4. Boston University Intelligent Mechatronics Lab.Autonomous quadcopter charging station, 2013.

5. A. Burkle, F. Segor, and M. Kollmann. Towardsautonomous micro uav swarms. Journal of intelligent &

robotic systems, 61(1-4):339–353, 2011.

6. G. Ducard and R. D’Andrea. Autonomous quadrotorflight using a vision system and accommodating framesmisalignment. In Industrial embedded systems, 2009.

SIES’09. IEEE international symposium on, pages261–264. IEEE, 2009.

7. J. F. Kelley. An iterative design methodology foruser-friendly natural language office informationapplications. ACM Transactions on Information Systems

(TOIS), 2(1):26–41, 1984.

8. S. Mitra. Autonomous quadcopter docking system, 2013.

7