exclusively works in software, reactive control also requires
no hardware modifications. We provide concrete evidence
of these benefits across different aerial drone applications,
based on 260+ hours of test flights in three increasingly
demanding environments, using a combination of three
aerial drones, three autopilot software, and three embedded hardware platforms. Our results indicate, for example,
that reactive control obtains up to 41% improvements in
the accuracy of motion, and up to a 22% extension of flight
The remainder of the paper unfolds as follows. Section 2
provides the necessary background, elaborates on the
fundamental intuitions behind reactive control, and outlines the issues that are to be solved to make it happen.
Section 3 describes the specific techniques we employ
to address these issues. Section 4 reports on the performance of reactive control compared with traditional
time-triggered implementations, whereas Section 5 studies the impact of reactive control in a paradigmatic end-user application. We conclude the paper in Section 6 by
discussing our current work towards obtaining official
certifications to fly drones running reactive control over
2. BUILDING UP TO REACTIVE CONTROL
Reactive control relies on concepts and techniques germane
to statistics, embedded software, programming languages,
control, and low-power hardware. In the following, we try
and smooth the waters for the readers by walking them
through the characteristics of target platforms, the key
observations leading to reactive control, and the issues that
are to be solved to concretely realize it.
2. 1. Autopilots
Drones can be regarded as a cruder form of modern robotics. 9 The high-level inputs coming from the GCS may be a
waypoint or a trajectory. Autopilots implement the low-level
control in charge of translating these inputs into commands
for the drone actuators.
Ardupilot ( goo.gl/x2CHyM) is an example autopilot
implementation, providing reliable low-level control for
aerial drones and ground robots. The project boasts a large
on-line community and is at the basis of many commercial
Software. Figure 2 shows the execution of Ardupilot’s
low-level control loop, split in two parts. The fast loop
only includes critical motion control functionality. The
time left from the execution of fast loop is given to an
application-level scheduler that distributes it among non-
critical tasks that may not always execute, such as logging.
The scheduler operates in a best-effort manner based on
programmer-provided priorities. Many autopilots share
similar designs. 7
Initially, fast loop blocks waiting for a new value from
the Inertial Measurement Unit (IMU). This provides an
indication of the forces the drone is subject to, obtained
by combining the readings of accelerometers, gyroscopes,
magnetometers, and barometer. Once a new value is available, IMU information is combined with GPS readings to
determine how the motors should operate to minimize the
error between the desired and actual pitch, roll, and yaw,
shown in Figure 3. Multiple PID controllers inside fast loop
are used to this end.
In Ardupilot as well as the vast majority of autopilots,
the control rate is statically set to strike a reasonable trade-off between motion accuracy and resource consumption,
based on a few “rules of thumbs.” 6, 25 For example, Ardupilot
runs at a fixed 400Hz on the hardware we describe next.
This rate is not necessarily the maximum the hardware
supports. The 400Hz of Ardupilot, for example, are thought
to leave enough room—on average—to the scheduler. In
short bursts, control may run much faster than 400Hz, as
long as some processing time is eventually allocated to the
Hardware. Autopilots typically run on resource-constrained
embedded hardware, for reasons of size and cost. A primary
example is the Pixhawk family of autopilot boards (goo.
gl/wU4fmk), which feature a Cortex M4 core at 168MHz
and a full sensor array for navigation, including a 16-bit gyroscope, a 14-bit accelerometer/magnetometer, a 16-bit 3-axis
accelerometer/gyroscope, and a 24-bit barometer. Most often,
at least a sonar and a GPS are added to provide positioning
and altitude information, respectively.
Interestingly, the sensors on Pixhawk have similar
capabilities as those on modern mobile phones. In fact,
many argue that without the push to improve sensors due
to the rise of mobile phones, drone technology would have
not emerged. 9 Such sensors support energy-efficient high-frequency sampling and often provide interrupt-driven
modes to generate a value upon verifying certain conditions.
The ST LSM303D mounted on the Pixhawk, for example, can
be programmed to generate an Serial Peripheral Interface
(SPI) interrupt based on three thresholds. This is useful,
Fast loop Scheduler Setup
Figure 2. Ardupilot’s low-level control loop. The time for a single
iteration of the loop is split between fast loop, which only includes
critical motion control functionality, and an application-level
scheduler that runs non-critical tasks.
Figure 3. Control based on raw, pitch, and yaw.