Preprint version 2013 6th European Conference on Mobile Robots, Barcelona, Catalonia, Spain

The TeleKyb Framework for aModular and Extendible ROS-based Quadrotor Control

Volker Grabe, Martin Riedel, Heinrich H. Bulthoff, Paolo Robuffo Giordano, Antonio Franchi

Abstract— The free and open source Tele-Operation Platformof the MPI for Biological Cybernetics (TeleKyb) is an end-to-end software framework for the development of bilateralteleoperation systems between human interfaces (e.g., hapticforce feedback devices or gamepads) and groups of quadrotorUnmanned Aerial Vehicles (UAVs). Among drivers for devicesand robots from various hardware manufactures, TeleKybprovides a high-level closed-loop robotic controller for mobilerobots that can be extended dynamically with modules for stateestimation, trajectory planning, processing, and tracking. Sinceall internal communication is based on the Robot OperatingSystem (ROS), TeleKyb can be easily extended to meet futureneeds. The capabilities of the overall framework are demon-strated in both an experimental validation of the controller foran individual quadrotor and a complex experimental setup in-volving bilateral human-robot interaction and shared formationcontrol of multiple UAVs.

I. INTRODUCTION

The challenges inherent to software development for arobotic platform have constantly changed over the lastdecade. Initially, the program code for robotic platformscomprising a certain set of sensors, actuators and controllerswere developed solely for a specific hardware architecture,making the reuse of software complicated and thus oftenimpractical. Recently, the design of robotic platforms hasmoved to setups that are more modular and allow for a sim-plified integration or exchange of individual hardware com-ponents [1]. Therefore the underlying software architecturesthat operate these robots required a fundamental paradigmshift consisting of, e.g., the introduction of increasing levelsof abstractions.

Since then, robotic middleware solutions migrated to athin-design paradigm that supports the development of mod-ular components and increases the ability to reuse existingcode. Several frameworks follow this new paradigm (see,e.g., [2], [3]) with the Robot Operating System (ROS) beingone of the most popular [4]. Since its release in 2007, severalhundred packages have been published.

Despite the clear benefits that ROS introduced to therobotic community, the concept of ROS is not particularlynew, but it is actually comparable to existing solutions such

V. Grabe, M. Riedel, H. H. Bulthoff and A. Franchi are with theMax Planck Institute for Biological Cybernetics, Spemannstraße 38, 72076Tubingen, Germany. E-Mail: {volker.grabe, martin.riedel, hhb,antonio.franchi}@tuebingen.mpg.de.

P. Robuffo Giordano is with the CNRS at IRISA, Campus de Beaulieu,35042 Rennes Cedex, France prg@irisa.fr.

V. Grabe is additionally with the University of Zurich, Andreasstr.15, 7050 Zurich, Switzerland. H. H. Bulthoff is additionally with theDepartment of Brain and Cognitive Engineering, Korea University, Seoul,136-713 Korea.

as, e.g., the Inter Process Communication (IPC) library [5].That is, ROS provides mainly a communication interfacebetween independent pieces of a framework together with aplatform to share released code. In order to implement theiralgorithms on a particular robotic platform, roboticists arestill forced to develop the appropriate drivers and controllersand to link them into a reliable framework. While drivers forseveral hardware components have been gratefully sharedby other scientists through ROS, the development of anappropriate control framework still remains a challenging andtime-consuming task, for example in the popular researchfield on Unmanned Aerial Vehicles (UAVs).

Over the last years, use of small quadrotor UAV platformshas gained immense popularity in the robotics communitydue to their small costs, robustness, flexibility, and hoveringcapabilities. However, at the best of our knowledge, onlyfew research labs publicly released their complete quadrotorcontrol frameworks. Moreover, each framework is typicallylimited to a particular chain constituted by a specific controldevice, a specific state estimator, and specific flight con-troller and vehicle driver. For the commercially availableAR.Drone1, a position controller has been released [6]:this is based on the velocity controller provided by themanufacturer. However, this solution is highly specific toquadrotor platforms that are endowed with an on-boardvelocity sensor and accept velocity commands. Similarly, acontrol framework restricted to quadrotors from AscendingTechnologies2 has been published [7]. Both frameworksinclude an estimator of the the quadrotor state that exploitsa low-frequency visual-based pose estimation together withacceleration and angular velocity readings from the on-boardinertial measurement unit (IMU).

However, both systems lack the support for other hardwareplatforms, are limited to a single mode of operation, anddo not support the simultaneous control of a swarm ofquadrotors for cooperative operations. Furthermore, theyhave not been designed to facilitate input modalities otherthan the specification of predefined waypoints and thus donot allow for a bilateral control in telepresence situationsusing, e.g., force feedback devices as in [8].

In order to compensate for this lack of basic features, inthis paper we propose a complete modular control frame-work for a generic quadrotor UAV based on ROS. Byproviding structured interfaces, the user can dynamicallyextend the framework, while still maintaining basic security

1http://ardrone2.parrot.com2http://asctec.de

mechanisms, like state supervision and fall-back modules.The full control chain released to the public is completelyextendable and already includes support for various inputdevices, multiple heterogeneous UAVs, and different stateestimators.

The remainder of this paper is structured as follows. Themain components and interfaces of the proposed frameworkare discussed in Sec. II. In Section III, all componentsinvolved with the actual control of the quadrotor UAVs arediscussed in more detail and we summarize the modulesincluded in the open source code release of this project inSec. IV. Finally, we present and discuss our experimentalevaluation in Sec. V and VI before the paper is concludedin Sec. VII.

II. MAJOR COMPONENTS OF TELEKYB

TeleKyb is an extensive software framework consistingof more than 50 ROS packages for the end-to-end solutionof quadrotor based setups. This includes a human interfacelayer for direct modes of interaction with the human op-erator, a control layer for motion planning and actuationof the quadrotor, and a hardware interface layer used tointerface the particular quadrotor hardware. In the following,we describe the main components of TeleKyb as illustratedin Fig. 1.

A. Human Interface

Human input appliances that feed back haptic cues tothe operator have become a popular field of research in thehuman-robot interaction community [9]. Since the variety ofhaptic-device manufacturers all use different SDKs for theirhardware, TeleKyb Haptics provides a unique interface forthe common types of haptic devices and thus implements thehaptic control algorithm using standardized methods. Thesemethods are then implemented by the specific hardwaredriver. Currently, TeleKyb supports all device classes ofForce Dimension3.

Human input devices which do not provide haptic feed-back, such as common joysticks and gamepads, can bedirectly used with TeleKyb if they are natively supportedby the operating system.

B. TeleKyb Base

TeleKyb Base provides a variety of helper classes whichare aimed to support the roboticists in the development ofcontrol algorithms. Among an improved memory manage-ment and multiple conversion functions for various purposes,the ROS parameter system has been greatly extended.

TeleKyb Options provide a mechanism to expose parame-ters of any node to external entities which can be updated atrun-time. Thus, they combine the capabilities of the defaultROS parameters and the ROS dynamic reconfigure4 package.However, as opposed to the original ROS parameters, theOption class supports optional bounds, read-only options,handles the correct namespace automatically and is not

3http://forcedimension.com/4http://ros.org/wiki/dynamic reconfigure

restricted to the native datatypes integer, double, and string.For example, it is possible to handle matrices or vectors asparameters.

C. TeleKyb Core

TeleKyb Core is a high-level closed-loop robotic controllercomposed of four main elements with distinct functionali-ties. The State Estimator estimates the current pose of therobot, the Trajectory Behavior unit computes the next desiredposition and velocity, the Trajectory Processor implementsadditional functionality such as obstacle avoidance, and theTrajectory Tracker computes the next commands which arethen sent to the robot as explained in more detail in Sec. III.

D. ROS–Simulink Bridge

MATLAB/Simulink is a popular tool for the simulationand control of dynamic systems, including robots. However,depending on the release, it links against older versions ofcertain libraries (e.g., boost) than those present on currentunix operating systems and which are therefore used whenTeleKyb is built. To the best of our knowledge, all thecurrently available ROS–MATLAB interfaces provide com-munication between MATLAB and other ROS nodes viarelatively slow network transmission rather than a nativeintegration.

To overcome this limitation, we setup an environment tocompile ROS against specific MATLAB versions and oper-ating systems. The resulting shared libraries are then linkedagainst MATLAB S-functions to implement the Simulinkside of the ROS interface. Thanks to this setup, genericS-function publisher and subscriber blocks use the nativeROS communication stack for the exchange of message withother nodes. We have recently joined efforts with MathWorksto integrate this ROS interface into coming versions ofMATLAB.

Within TeleKyb, this allows for the use of MAT-LAB/Simulink on top of the TeleKyb Core and Simulinkcan be utilized for the implementation and evaluation ofhigher-level algorithms or alternative controllers. Similarly,the ROS–MATLAB bridge can be utilized for the integrationof human input devices with existing ROS drivers into MAT-LAB programs. Our bridge has already been successfullyapplied in various setups [10], [11].

E. Obstacle Provider

Applications for mobile robots often include the neces-sity to detect and dynamically react to obstacles in theenvironment. For this purpose, TeleKyb uses an ObstacleProvider which maintains a list of obstacle modules. TeleKybprovides modules for the definition of constant obstacles,fixed geometric structures, and dynamically moving obsta-cles provided from either on-board observations or externalsources such as motion tracking systems.

F. Robot Interface

TeleKyb is in general not restricted to be only usedwith quadrotors UAVs, but can rather be employed with a

Preprint version 2 2013 ECMR

Touch-Based

Joysticks

Haptic

ROS Inter-Process Communication

TeleKyb

RobotInterface

Mobile Robot

Simulator

Sensors

Human Device Hardware / Simulation

Hardware / Sensor InterfaceControl

External Control Interfaces:

- Higher Level Controller (e.g., MATLAB/Simulink)- Playback of predefinedTrajectories- External Trajectory Input

3rd Party ROS Tools

TeleKyb Core

Experimental Flow Manager

State Estimator

TrajectoryBehavior

TrajectoryTracker

TeleKybBase

TrajectoryProcessor

Human Interface

SimulatorInterface

SensorInterfaces

DHD / PhantomDriver

TeleKybHaptics

ROS-iO

S Bridge

TeleKybJoystick

TeleKyb Core Interface

iTeleKyb

Supervisor

Supervisor Supervisor Supervisor

Loaded Modules:

ROS Nodes

Libraries

Devices / HW / Simulation State Message

Trajectory MessageSensor Input / Command OutputRun-time Modules

Active Modules:

Fig. 1: High-level overview of major TeleKyb components. TeleKyb bridges the gap between user interfaces and robot hardware byintroducing the TeleKyb interface layer.

wide variety of mobile robots since the implementation ofhardware interfaces is strictly separated from the underlyingalgorithms. For each vehicle, suitable controller modules (seeSec. III) have to be provided together with an implementationof the Robot interface. This interface allows for both highfrequency messages (such as control commands and sensordata) and asynchronous communication that can be used,e.g., to update controller gains or trigger an emergencyprocedure. Incoming data from the robot can be examinedto react automatically on certain events such as low batteryor detection of unexpected changes in some variables of thesystem. All communication can be exposed to ROS topicsfor monitoring or visualization purposes.

G. Simulator Interface

Robotic simulators provide both the simulation of a partic-ular robotic hardware and the environment surrounding therobot. For the use of TeleKyb with a simulation, both a robotinterface and a state estimation module (as introduced inSec III-A) have to be provided. Currently, TeleKyb providesfull supports for SwarmSimX [12], while an integration ofv-rep5 is under active development.

III. TRAJECTORY PROCESSING AND CONTROL

In this section, the details of the TeleKyb Core and thedifferent stages of our universal quadrotor controller areexplained.

5http://coppeliarobotics.com

A. State Estimation

The State Estimator consists of a Supervisor and a numberof run-time loadable modules that provide the actual stateestimation functionality. While the Supervisor is responsiblefor loading, unloading, and transition between the individualestimator modules, the currently active module generatesa standardized state message (p, p, q, ω), where p, p, q, ωdenote the position, velocity, orientation and angular velocityof the robot, respectively. This message is then distributedto the other parts of the controller within the TeleKyb Core.The active state estimation module can be changed at run-time, which allows for a safe fall-back state estimator moduleonce another, e.g. vision based, estimator becomes too noisyor returns unreliable data. Also, estimators based on differentsensors can be used for different behaviors of the flight, e.g.,during the take-off or cruse phase, as described in Sec. III-B.

For external optical tracking systems, TeleKyb supports allsystems that implement the free and open VRPN standard.In particular, this is the case with both the Vicon6 andthe OptiTrack7 tracking systems. Since the state messagerequires the additional knowledge of the linear and angularvelocities p and ω, they are numerically computed from thepose p and the orientation q as obtained from the trackingsystems using the signal filtering libraries provided withTeleKyb.

6http://vicon.com7http://naturalpoint.com/optitrack

Preprint version 3 2013 ECMR

TrajectoryB

ehavior

TrajectoryTracker

Position ErrorChecker

Trajectory Processor

State MessageTrajectory MessageObstacle Points

Behavior Change

Velocity Saturation

Obstacle Avoidance

Fig. 2: Priority list of Trajectory Processor modules as they dy-namically alter the current trajectory message before it is executed.

B. The Behavior System

The Trajectory Behavior system is one of the most pow-erful components of the control framework and contributeslargely to its flexibility. Similar to the State Estimator , aSupervisor manages individual modules which provide theactual functionality, in the following referred to as Behaviors.The active behavior is responsible for the generation of atrajectory message every time a new state was made availableby the State Estimator .

Behaviors dynamically generate trajectories for any giventask during a robotic experiment. While many default behav-iors such as Take-Off, Hover, Fly-To, Trajectory Following,Human Control and Land are already included with TeleKyb,the user can easily add new behaviors by implementing aprovided interface. Consequently, the Supervisor can switchbetween individual behaviors in order to describe higher-level motions such as Take-Off → Brake → Hover → Land.Therefore, the behavior system is equivalent to a finite-state machine with exactly one active behavior at any timeand well-defined rules for the transitions. To ensure safetransitions, a type is assigned to each behavior and transitionsare only allowed between behaviors of certain types, e.g.,Ground → Take-Off, Air → Air, . . . . Additionally, they canbe linked by defining a pointer to the next behavior. Thisbehavior will then become active once the previous oneterminates. This termination criterion can be either definedwithin each behavior or triggered by user input. A behaviorwithout a follow-up element will be automatically followedby the Brake behavior which in turn will be followed by theHover behavior until a new behavior is requested.

Since behaviors can be chained and each sequence formsa more complex behavior again, this simple design princi-ple allows to accommodate a wide range of experimentalconditions.

C. The Trajectory Processor

The Trajectory Processor maintains multiple modules ableto dynamically alter the trajectory message generated fromthe active Behavior before it is passed on to the TrajectoryTracker . Several modules can be active at the same time andare applied to each trajectory message in sequential order, asshown in Fig. 2.

Generally, trajectory processor modules can either alterthe trajectory message directly, e.g., to implement obstacleavoidance, or influence the system in a more indirect way byinitiating a Behavior switch, e.g., to brake if some unexpectedconditions were detected. Furthermore, modules can observe

and interact with other components of the TeleKyb Corethrough the option system and, e.g., change the gains of thecontroller to less aggressive settings.

D. The Trajectory Tracker

The Trajectory Tracker computes the needed robot com-mands from both the current state and trajectory message.

The control design is based on the natural decouplingbetween attitude and linear dynamics (the former is indepen-dent from the latter). The design is then made in two stepsin a classical cascade fashion: first, a fast attitude controllerenforces tracking of a desired attitude unit quaternion qdes(t)to the current quadrotor orientation q(t) by exploiting thefull actuated rotational dynamics for quadrotor UAVs (threeavailable torque inputs). Then, a slower position controllergenerates the attitude set-point qdes(t) needed to properly re-orient the direction of the fourth input (thrust) so as to obtainthe desired translational motion, i.e., for eventually letting theposition p(t) to track a desired reference pdes(t). Comparedto other control designs (e.g, feedback linearization), thissolution can result in a less performant transient behaviorbut benefits from a higher robustness w.r.t. disturbances,parametric and modeling uncertainties thanks to the afore-mentioned dynamical separation.

E. The on-board Low-Level Controller

While TeleKyb supports UAVs from Ascending Technolo-gies, KMel Robotics8, and MikroKopter9, the integration ofquadrotors from MikroKopter is currently most advanced duethe possibility to implement the on-board low-level controllermanually.

The on-board low-level controller is in charge of letting thequadrotor orientation q(t) track a desired reference qdes(t).As classically done, this is achieved by neglecting thecouplings among the three body axes, and by treating eachindividual rotation (roll, pitch, yaw) as a separate channelmodeled as a double integrator with input the correspondentbody torque. The adopted controller is then a simple PIDwith saturated integral term in order to prevent wind-upissues. Readings from the on-board gyros are exploited asvelocity feedback, while a complementary filter provides es-timates of the UAV attitude by fusing together accelerometerand gyro readings from the IMU.

F. TeleKyb Core Interface

The TeleKyb Core Interface allows to dynamically load andconfigure the Estimation, Behavior , Processing and Trackingmodules. Furthermore, it provides automatic callbacks totrack certain events such as a behavior transition in theTrajectory Behavior stage.

G. Experimental Flow Manager

The Experimental Flow Manager controls the flow of anentire experiment consisting of one or more TeleKyb Cores,one for each robot. For this purpose, it can be launched from

8http://kmelrobotics.com9http://mikrokopter.de

Preprint version 4 2013 ECMR

TABLE I: Hardware supported with TeleKyb download

Input Devices Gamepads, Devices from Force-DimensionTracking Systems Vicon, OptiTrack, and others with VRPN supportUAVs MikroKopter (with provided extended low-level

firmware), AscTec UAVs (beta version only)

Fig. 3: The quadrotors used for the evaluation: Nano+ from kmel(left) and a MK-Quadro from MikroKopter (right).

anywhere in the network. Using the TeleKyb Core Interface,the TeleKyb Cores can be configured and manipulated on-line, e.g., to specify when Behaviors become active andhow they are configured. In this role, the Experimental FlowManagers can be used to trigger events on the TeleKyb Cores,for example when requested by input devices connected tothe network. Additionally, the Experimental Flow Managercan be informed by a TeleKyb Core to react on events such asthe termination of a Behavior . This concept was also used toimplement control through a touch-based hand-held device.

IV. SOURCE CODE RELEASE

We released all major components ofTeleKyb under the BSD license. A currentversion of TeleKyb can be obtained fromhttps://svn.tuebingen.mpg.de/kyb-robotics/

TeleKyb/trunk. Table I lists the hardware driversprovided with TeleKyb. A documentation including quickstart instructions has been integrated into the ROS Wiki athttp://ros.org/wiki/telekyb. For license reasons, wewere not allowed to provide the communication interfacefor the vehicles from KMel Robotics. Please note that,according to the BSD license, the software is provided ’asis’ and we cannot be hold responsible for any damage orharm caused by the use of our software.

V. EXPERIMENTS

In order to both evaluate the accuracy of the controllerincluded with TeleKyb, and the ability to design complex ex-periments, we conducted two individual sets of experimentsdescribed in Sec. V-A and Sec. V-B, respectively.

As for the hardware setup, we used two different types ofquadrotors, a Nano+ from KMel Robotics with a diameterof 0.19m and a weight of 0.230 kg, and a MK-Quadro fromMikroKopter with a diameter of 0.50m and a weight of1.050 kg. Both are shown in Fig. 3.

The state of the robot was retrieved via an externalmotion capture system at the frequency of 120 Hz and sub-millimeter precision. The desired roll, pitch, yaw-rate, andthrust commands computed by the controller are sent toattitude controller implemented on the micro controller bymeans of a wireless serial communication.

Both UAVs were flown using the same controller gains.A mass estimator included in TeleKyb estimated the actualquadrotor mass starting from a rough initial estimate: thisallowed to autonomously compensate for the different char-acteristics of the two vehicles. The velocity was restrictedto 1.0m/s through configurable options for safety reasons.Likewise, the maximum tilt angle was limited to 20◦, thusalso limiting the maximum achievable linear acceleration.

A. Experiment for Evaluation of the Controller

The first set of experiments was designed to evaluate theTeleKyb controller. In an initial setup, we aimed to testthe Trajectory Tracker which provides appropriate orientation(i.e., attitude) and thrust commands to the UAVs given thedesired positions, velocities, and accelerations at each controliteration. Both UAVs were flown along the same trajectory(a ‘eight’ shape) with a given velocity profile defined priorto the experiment. One loop along whole curve lasted 10 swith a peak velocity of 0.65m/s.

In a second experiment, the whole controller chain, includ-ing a Fly-To Behavior that computes the trajectory towardsa defined target on-line, was investigated. Both UAVs werecommanded to fly to a target location approximately 2mfrom the hovering UAV and stop there.

B. Experiment with a Swarm and Human In-the-loop

To demonstrate the capabilities of the TeleKyb frameworkwith respect to more complex scenarios including presence ofmultiple UAVs, obstacle avoidance, human-robot interactionand haptic control, we designed an experimental setup withfour MK-Quadro UAVs implementing various Behaviors andProcessor Modules.

The following ROS nodes are running during the experi-ment: 4 MikroKopter Interfaces, 4 TeleKyb Cores, 4 ObstacleProviders providing dynamic and static obstacle boundaries,1 VRPN tracking node, 1x haptic device node, and 1Experimental Flow Manager which loads and configures allBehaviors and reacts to user input and dynamic callbacksfrom the TeleKyb Cores.

VI. RESULTS AND DISCUSSION

A. Experiment for Evaluation of the Controller

In Figure 5, the results of the first set of experiments aredemonstrated. The desired trajectory was compared to theachieved trajectory for both vehicles. For the heavy MK-Quadro, we measured an average position error of 0.034mand an average velocity error of 0.042m/s. The error did notexceed 0.062m and 0.104m/s, respectively. For the lighterNano+, we found smaller average position errors of 0.021mwhich did not exceed 0.039m. The velocity error was inaverage 0.026m/s and always less than 0.058m/s for the

Preprint version 5 2013 ECMR

Ground

Take Off

Brake

Hover

FormationReconfiguration

(Square)

Semi-AutonomousFormation

FormationReconfiguration

(Equilateral Triangle)

Semi-AutonomousFormation

Ground

FlyTo

Take Off

Trajectory Playback

Formation Reconfiguration

(Tetrahedron)

Formation UAVstim

e

Brake

Hover

Semi-AutonomousFormation

Land (vertically)

Ground

Scene:

Land (at Position)

10

14

21

21

24

343x

Single UAV

72

81

114

120

121

125

146

150

158

160

3x

3x

s

Automatic Transitions

Event / User triggeredTransitions

Single UAV dynamically added to

the list ofobstacle points of

the Formation UAVs

Single UAV dynamically removed

from the list of obstacle points of

the Formation UAVs

Fig. 4: Experimental flow during the human controlled swarmexperiment as described in Sec. V-B. The left and right col-umn list the currently active Behavior for the quadrotorsin the swarm and the individual vehicle respectively. Thetime line is aligned to the attached video, also accessibleat http://antoniofranchi.com/videos/telekyb.html (seeSec. VI-B).

Nano+ when ignoring an outlier caused by the trackingsystem at time 3 sec.

The results for the flight to a distant target are shown inFig. 6. Both UAVs received the command after 0.3 secondsand accelerated up to their predefined maximum velocity.The heavier MK-Quadro started deceleration shortly beforethe Nano+ in order to stop and hover above the assigned goallocation. Both vehicles stopped within 0.02m of the target.

B. Experiment with a Swarm and Human In-the-loop

The experiment of the more complex swarm flight demon-strated the capabilities of the behavior based architecture.

−1 −0.8 −0.6 −0.4 −0.2 0 0.2 0.4 0.6 0.8 1

−0.4

−0.2

0

0.2

0.4

0.6

y

x

MK−Quadro

Nano+

Desired trajectory

(a)

0 1 2 3 4 5 6 7 8 9 100

0.05

0.1

0.15

0.2

time [s]

Positionandvelocity

error

Velocity error MK−Quadro [m/s]

Position error MK−Quadro [m]

Velocity error Nano+ [m/s]

Position error Nano+ [m]

(b)Fig. 5: Trajectory of the Nano+ and the MK-Quadro along a eightshaped against the desired trajectory. (a) Position of the quadrotorstogether with the desired trajectory and (b) Norm of the positionand velocity tracking errors during one traversal of the trajectoryfor both vehicles.

0 0.5 1 1.5 2 2.5 3 3.5 4

0

0.5

1

1.5

2

time [s]

Distance

totarget

[m]

MK−Quadro

Nano+

Fig. 6: Distance to the target for a Nano+ and an MK-Quadro ina sidestep maneuver. Both velocity and acceleration were saturatedfor safety reasons as evident from the plots.

Fig. 4 depicts the experimental flow during this demonstra-tion. Additionally, a descriptive video of this experimentis attached to this submission and can also be accessed athttp://antoniofranchi.com/videos/telekyb.html.

At multiple times (e.g., at 24, 34, 72, 81, 146, 150 sec)the 4 UAVs switched from or to a formation which requiredan exchange of some information among the robots suchas current poses and inter-distances of neighboring UAVs.Note that formation control was implemented in a completelydecentralized way, thus not requiring the Experimental FlowManager or any other centralized controller.

At second 34, a single UAV left the formation and theremaining UAVs rearranged into a equilateral triangle. Si-multaneously, the Experimental Flow Manager reconfiguredthe Obstacle Avoidance Processor Module of the remainingswarm to consider the single UAV as an obstacle. At sec-ond 81, this UAV landed at a predefined position to undergoa simulated maintenance, while the remaining UAVs keptbeing in control of the human operator. After having taken

Preprint version 6 2013 ECMR

off again, the single UAV entered a circular trajectory untilit rejoined the formation at second 146 upon user command.After 160 sec, all UAVs landed vertically.

VII. CONCLUSION

In this paper, we introduced a control framework forquadrotor UAVs called TeleKyb. We demonstrated thatTeleKyb presents a complete end-to-end solution containingall the necessary components from drivers for human inputdevices to hardware support for quadrotors from differentmanufacturers. Complex experimental setups for high-levelrobotic tasks such as exploration or mapping can be createdwithout in-depth knowledge of control theory. Nevertheless,by relying on ROS for inter process communication and welldefined interfaces, TeleKyb can be easily extended to meetnew requirements. The controller included in TeleKyb wasproven to work well with completely different quadrotorUAVs. In the past, early versions of TeleKyb have beenalready used successfully for various applications [8], [13],[14].

With the release of the TeleKyb source code into a publicROS repository, we are hoping for contributing the sharingour knowledge with the robotics community, as well asreceiving a valuable feedback on our work.

A. Future Work

Currently, we are working on the integration of a filter toallow for the use of TeleKyb with noisy low-frequency posi-tion data from, e.g., GPS or on-board visual state estimates.

VIII. ACKNOWLEDGEMENTS

Volker Grabe wishes to thank Dr. Davide Scaramuzza forhosting his visit at the University of Zurich in 2012/2013 andfor providing the Nano+ quadrotor used in the experiments.

REFERENCES

[1] A. Makarenko, A. Brooks, and T. Kaupp, “On the benefits of makingrobotic software frameworks thin,” in Workshop on Measures andProcedures for the Evaluation of Robot Architectures and Middlewareat the 2007 IEEE/RSJ Int. Conf. on Intelligent Robots and Systems,San Diego, CA, Oct. 2007.

[2] A. Brooks, T. Kaupp, A. Makarenko, S. Williams, and A. Oreback,“Orca: A component model and repository,” in Software Engineeringfor Experimental Robotics, ser. Tracts in Advanced Robotics, D. Bru-gali, Ed. Springer, 2007, vol. 30, pp. 231–251.

[3] G. Metta, P. Fitzpatrick, and L. Natale, “YARP: Yet Another RobotPlatform,” International Journal of Advanced Robotic Systems, vol. 3,no. 1, pp. 43–48, 2006.

[4] M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs,R. Wheeler, and A. Y. Ng, “ROS: an open-source Robot OperatingSystem,” in Workshop on Open Source Software in Robotics at the2009 IEEE Int. Conf. on Robotics and Automation, Kobe, Japan, May2009.

[5] R. Simmons and D. James, Inter-Process Communication A ReferenceManual. Carnegie Mellon University, 2011. [Online]. Available:http://www.cs.cmu.edu/ipc/

[6] J. Engel, J. Sturm, and D. Cremers, “Accurate figure flying with aquadrocopter using onboard visual and inertial sensing,” in Workshopon Visual Control of Mobile Robots (ViCoMoR) at the 2012 IEEE/RSJInt. Conf. on Intelligent Robots and Systems, Vilamoura, Portugal, Oct.2012.

[7] M. Achtelik, M. Achtelik, S. Weiss, and R. Siegwart, “Onboard IMUand monocular vision based control for MAVs in unknown in- andoutdoor environments,” in 2011 IEEE Int. Conf. on Robotics andAutomation, Shanghai, China, May 2011, pp. 3056–3063.

[8] A. Franchi, C. Secchi, M. Ryll, H. H. Bulthoff, and P. Robuffo Gior-dano, “Shared control: Balancing autonomy and human assistance witha group of quadrotor UAVs,” IEEE Robotics & Automation Magazine,Special Issue on Aerial Robotics and the Quadrotor Platform, vol. 19,no. 3, pp. 57–68, 2012.

[9] B. Hannaford and A. M. Okamura, “Haptics,” in Springer Handbookof Robotics, B. Siciliano and O. Khatib, Eds. Springer, 2008, pp.719–739.

[10] C. Masone, A. Franchi, H. H. Bulthoff, and P. Robuffo Giordano,“Interactive planning of persistent trajectories for human-assisted nav-igation of mobile robots,” in 2012 IEEE/RSJ Int. Conf. on IntelligentRobots and Systems, Vilamoura, Portugal, Oct. 2012, pp. 2641–2648.

[11] M. Riedel, “Telekyb: A modular software framework for bilateralteleoperation scenarios and its applications in robotics research,”Master Thesis, Eberhard Karls Universitat Tubingen, 2012.

[12] J. Lachele, A. Franchi, H. H. Bulthoff, and P. Robuffo Giordano,“SwarmSimX: Real-time simulation environment for multi-robot sys-tems,” in 3rd Int. Conf. on Simulation, Modeling, and Programmingfor Autonomous Robots, Tsukuba, Japan, Nov. 2012.

[13] A. Franchi, C. Masone, V. Grabe, M. Ryll, H. H. Bulthoff, andP. Robuffo Giordano, “Modeling and control of UAV bearing-formations with bilateral high-level steering,” The International Jour-nal of Robotics Research, Special Issue on 3D Exploration, Mapping,and Surveillance, vol. 31, no. 12, pp. 1504–1525, 2012.

[14] A. Franchi, C. Secchi, H. I. Son, H. H. Bulthoff, and P. RobuffoGiordano, “Bilateral teleoperation of groups of mobile robots withtime-varying topology,” IEEE Trans. on Robotics, vol. 28, no. 5, pp.1019–1033, 2012.

Preprint version 7 2013 ECMR