aspects by employing a form of auto-tuning of the
conditions leading to running the control logic.
2) An indication for running the control logic may
originate from different sensors, at different rates,
and asynchronously with respect to each other.
A problem is thus how to handle the possible interleavings. Moreover, not running the control loop for
too long may negatively affect the drone’s stability,
possibly preventing to reclaim the correct behavior.
We tackle these issues by only changing the
execution of the control logic over time, rather than the
logic itself.
3) Reactive control must run on resource-constrained
embedded hardware. When implementing reactive
control, however, the code quickly turns into a “
call-back hell” 10 as the operation becomes inherently
event-driven. We experimentally find that, using
standard languages and compilers, this negatively
affects the execution speed, thus limiting the gains. 7
We design and implement a custom realization of
Reactive Programming (RP) techniques3 to tackle this
problem.
The context where we are to address these issues shapes
the challenge in unseen ways. For example, aerial drone
demonstrations exist showing motion control in tasks such
as throwing and catching balls, 21 flying in formation, 23 and
carrying large payloads. 14 In these settings, the low-level control does not operate aboard the drone. At 100Hz or more, a
powerful computer receives accurate localization data from
high-end motion capture systems, runs sophisticated control algorithms based on drone-specific mechanical models
expressed through differential equations, and sends actuator commands to the drones. Differently, we aim at improving the performance of mainstream low-level control on
embedded hardware, targeting mobile sensing applications
that operate in the wild.
On the surface, reactive control may also resemble the
notion of event-based control. 1 Here, however, the control
logic is often expressly redesigned for settings different
than ours; for example, in distributed control systems to
cope with limited communication bandwidth or unpredictable latency. This requires a different theoretical framework. 1 In contrast, we aim at re-using existing control logic,
whose properties are well understood, and at doing so with
little or no knowledge of its corresponding implementation
and its parameter tuning. Different than event-based control, in addition, reactive control is mainly applicable only
to PID-like controllers where the Proportional component
dominates.
3. REACTIVE CONTROL
The key issues we discussed require dedicated solutions, as
we explain here.
3. 1. Conditions for reacting
Problem. It may seem intuitive that the more “significant” is
a change in a sensor reading, the more likely is the necessity
to run the control loop. Such a condition would indicate that
for example, in human tracking applications for function-
ality such as fall detection. 15
2. 2. Intuition
Through our continuous work with drones as mobile computing platforms, 16, 19 we eventually noticed that the autopilots’ PID controllers are mostly tuned so that it is the
Proportional component to dictate the actual controller
operation. The Derivative component can be kept to a minimum though a careful distribution of weights, 6, 11 whereas
precise sensor calibration may spare the Integral component almost completely. 6, 11, 22
As a result of this observation, we concluded that a simple relation exists between current inputs from the navigation sensors and the corresponding actuator settings.
With little impact from the time-dependent Derivative and
Integral components, and with the Proportional component dominating, small variations in the current sensor
inputs likely correspond to small variations in the actuator
settings. As an extreme case, as long as the sensor inputs
do not change, the actuator settings should remain almost
unaltered. In such a case, at least in principle, one may not
run the control logic and simply retain the previous actuator settings.
Reactive control builds upon this intuition. We constantly
monitor the navigation sensors to understand when the control logic does need to run as a function of the instantaneous
environment conditions. These manifest as changes in the
inputs of navigation sensors. If these are sufficiently significant to warrant a change in the physical drone behavior to be
compensated, reactive control executes the control logic to
compute new actuator settings. Otherwise, reactive control
retains the existing configuration.
As we explain next, reactive control abstracts the problem
of recognizing such significant changes in a way that makes
it computationally tractable with little processing resources.
Moreover, because of the aforementioned characteristics of
sensor hardware on autopilot boards, monitoring the sensor
readings at the maximum possible rate usually bears very
little energy overhead. Reactive control, nonetheless, makes
it possible to rely on the low-power interrupt-driven modes
if available.
As a result, when sensor inputs change often, reactive control makes control run repeatedly, possibly at rates higher
than the static settings of a time-triggered implementation.
When sensor inputs exhibit small or no variations, the rate of
control execution reduces, freeing up processing resources
that may be needed at different times.
2. 3. Challenge
Realizing reactive control is, however, non-trivial. Three
issues are to be solved, as we illustrate in Section 3:
1) What is a “significant” change in the sensor input
depends on several factors, including the accuracy of
sensor hardware, the physical characteristics of the
drone, the control logic, and the granularity of actuator output. We opt for a probabilistic approach to
tackle this problem, which abstracts from all these