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