Section: New Results

Control and scheduling co-design

Participants : D. Simon [ contact person ] , O. Sename, E. Roche, M. Ben Gaid [ IFP ] .

Control and real-time computing have been associated for a long time, for the control of industrial plants and in embedded or mobile systems, e.g. automotive and robotics [41] . However both parts, control and computing, are often designed with poor interaction and mutual understanding. We propose here an Integrated control and scheduling co-design approach, where closing the loop between the control performance and the computing activity is promising for both adaptivity and robustness issues ([46] , [40] ).

Control with adaptive variable sampling

In the past years we developed a variable sampling control methodology based on the LPV (Linear Parameter Varying) framework and control synthesis ([42] ), where the sampling interval is used as a known and controlled variable. Few assumptions about sampling are needed for this control design : the main point is that the control interval is known and lies between the predefined bounds [h_min;h_max] , whatever the origin of the control interval variations, its speed and its frequency, e.g. Figure 14 a which simulates data dropping due to a (m,k)-firm sensing policy. Within the timing schemes of Figure 13 two cases may be considered :

Figure 13. Scheduled varying sampling scheme

• the control interval is a control variable which can be used by a feedback scheduler to manage the CPU load share : in that case the desired control interval is computed by a scheduling controller and sent to the real-time scheduler which manages the control tasks execution ;

• the control interval variations may be due to sensor scheduling, e.g. induced by a communication channel between the sensor and controller nodes : in that case the interval between the successive expected appearance of data at the controller input are delivered by the scheduling policy controller, as it may be the case inside a swarm of underwater vehicles.

Figure 14. LPV with :a) (1-3)-firm input scheduling – b) unmodeled output delay

The approach has been cleaned in [8] . Beyond the initial goal, where the control interval is assumed to be controlled and known, case studies simulations (e.g. Figure 14 b) show that the method has a good robustness w.r.t. to unmodelled delays, such as latencies due to networking, computing and preemption activities. Further work plans to specifically analyse, understand and exploit this robustness.

Robust control of underwater vehicles

In the framework of the Connect and FeedNetBack projects, the /LPV approach has been applied to an AUV ([36] ). The 3D coordinated control of an autonomous underwater vehicle is not straightforward : indeed the model of the vehicle has important non-linearities and several poorly known parameters which lead up to robust control. Moreover the limited capabilities of underwater acoustic links and limited embedded computing power and on-board energy induced serious timing disturbances and scheduling constraints. These problems make AUVs good testbeds for control/computing co-design.

In this preliminary work, the approach is chosen for the control of the whole vehicle. The method requires the linearization of the vehicle model, but has the advantage to guarantee good robustness margins with respect to the nominal plant. The control of the vehicle is separated according the 3 axes of the referential (Ox, Oy and Oz). So the control of the whole vehicle involves the synthesis of 3 different controllers.

The first controller is computed for the control of the longitudinal speed of the vehicle by the propeller. The second one addresses the control of the altitude z. A constraint on the pitch angle is added to enforce the vehicle to climb up the slope parallel to the roof (this constraint allows a more effective control by limiting the drag effort). The third controller concerns the yaw angle. Some problems due to the use of fins by two controllers have been solved by choosing different weights for shared fins (small) than for devoted ones (high). (For example, the considered AUV has tree fins at the tail of the vehicle, one horizontal and the two others inclined by angle plus or minus 120 degree. The horizontal fin is only used by the yaw angle controller, whereas the others fins are also used by the altitude controller).

Figure 15. AUV robust control in bottom following mode

The discretization of the controllers has been done using classical tool, with constant sampling period. As the measure of the distance with respect to sea bottom is not know at constant period (due to different altitude or loose of data), this controller can be seen as a periodic controller with variable sampling time.

These first results foster ongoing research to better understand how the LPV approach can be used to efficiently and robustly control such autonomous vehicle, subject to timing uncertainties. In particular it is intended to combine several uncertain parameters, including computing and communication resources related disturbances like computing and networking induces delays.

Hardware-in-the-loop simulation of a quadrotor drone

In the framework of the SafeNECS project (see 8.1.1 ), a hardware-in-the-loop experiments using Orccad has been set up to provide a safe environment for both algorithms and software validation, prior to experiment with the real (expensive and fragile) quadrotor.

Figure 16 describes the control and diagnostic setup used for testing purpose [24] . In this block-diagram the blue boxes represent the user-provided modules (i.e. functions) interconnected by their input/output ports (respectively blue/red). From the real-time point of view, each module is implemented by a real-time task possessing its own programmable timer. Therefore all the modules can be run asynchronously at their own (possibly varying) sampling frequency. In this diagram one of the modules implements a feedback scheduler: it monitors the controller's real-time activity and may react by setting on-the-fly the tasks and messages scheduling parameters, e.g. their firing intervals or priority. For example it may be used to implement a (m,k)-firm dropping policy ( [60] ) or hybrid priority schemes over the CAN bus [43] , [44] .

Figure 16. Control and diagnosis block-diagram

To set up a “hardware-in-the-loop” real-time simulator, the multitasks controller running on the embedded target is connected via a Can (or Ethernet) link running a numerical integrator, calling a model of the drone, of its sensors and of its actuators. This setup allows for ultimate tuning of the control algorithms before launching the real and fragile system. Daemons are also added to simulate various kind of failures and evaluate fault detection filters and fault tolerant control recovery efficiency. Finally the Orccad controller has been succesfully integrated in the real drone, and the preliminary experiments are coherent with those from the real-time simulator.