4. Introduction of the Benchmark ProblemsProblems
4.2. Minimising the Vibrations of a Winged Drone
Building a Controller and a Drone Model
Model and controller evolved together, at increasing complexity, until all characteristics of quad-copers, which were of interest, were modeled.
1. The first generation was a rigid point mass actuated by input forces in the reference frame, with positions, velocities and accelerations controlled by forces. Positions and velocities of the simulated rigid mass were used as measurement inputs for the controller. White noise was added to these measurements to test the controller. As the forces can be computed directly from the accelerations by multiplying with the mass, and the resulting acceleration is again the result of dividing with the mass, this is more or less an identity mapping.
Gyroscopic effects were neglected in this step.
Thus, results need to look like the input path and can be debugged quickly.
2. In the next step, gravity was introduced, as well as the fact that a quadcopter is underac-tuated. It can generate thrust only in the direction normal to its rotors. At this point, the quadcopter’s attitude (its orientation in space) was assumed to adjust instantaneously to the necessary attitude. Thus the combination of controller and model again resulted in an identity mapping and allowed the debugging of the attitude representation.
For a smooth attitude representation, quaternions were used. The calculus of quaternions is explained in annex A.
3. The next level of detail introduced the rotational inertia of the drone, as well as gyroscopic effects. The required force and attitude were fed to a second control cycle for the attitude and angular velocities. With a high proportional control coefficient this again degrades to an identity mapping, but as soon as inputs are limited to the rotors thrust limits, the deviations from the reference path can be seen.
4. The last step was an improvement to the controller. Using information on the acceleration necessary in a future time step, the desired attitude can be estimated, allowing some feedforward on rotational velocity and accelerations to improve the quadcopter’s attitude behavior.
This model offered now quite a good estimation for the necessary rotor thrusts as well as a simulation model for any drone based on rotors.
An estimation for the quadcopter’s weight was given by the supervisor - 200g for the hitting mechanism and 500g for the quadcopter. For such a system, a simulated manoeuver starting from hover in the center of the playing area reaching a speed of 20ms at a corner of the playing area (see figure 4.2) in 1 second’s time required 15N maximum thrust per rotor. The thrust curves are given in figure 4.3. The progress of the design space exploration discussed in section 5 relied heavily on this model.
4.2. Minimising the Vibrations of a Winged Drone
Figure 4.2.: One trajectory of the controlled system
Figure 4.3.: The rotor thrusts on this trajectory
Figure 4.4.: A sketch of an UAV, Image Courtesy of Flanders Make
4.2.1. The Subject Under Consideration
A winged drone can be imagined as a small plane. Figure 4.4 gives an impression how it looks like. It consists roughly of
• a body, called fuselage
• main wings
• small wings in front, called canards
• flaps, also called ailerons, mounted to the main wings and, if necessary, also to the canards.
• actuators for these ailerons
• propulsion systems
The goal of the project was to damp vibrations introduced by spontaneous winds (so-called gust loads). The main properties of this scenario can be summed up in three points:
• The problem is dynamic, as the gust load is a short disturbance to the steady flight regime.
Vibrations occur during and in the aftermath of this disturbance.
• It is a coupled problem where the elastic behaviour of the wing and the aerodynamic lift have to be modeled and simulated.
• This makes it a difficult optimisation problem, as:
– Some design parameters are discrete (e.g. number of independent ailerons), others are continuous (position of the ailerons, size of the ailerons), which makes many fast optimisation algorithms unusable. [Lan12]
– The optimisation target is to minimise the vibrations, which are determined by dynamic simulation of a nonlinear, controlled system.
4.2. Minimising the Vibrations of a Winged Drone
4.2.2. The Simulation Model
The model developed by Flanders Make was built in the Matlab/SimScape environment. Sim-Scape was chosen because it allows acausal modeling, which stands in contrast to causal modeling environments (like e.g. SimScape’s little brother Simulink), where each system has a clear direc-tion: signals flow in at the inputs and get transformed to output signals. These causal models are easy to execute, but difficult to build by engineers - e.g. an electric network has first to be transformed into a set of equations to be modelled. This transformation step becomes tedious and error-prone on large and complex systems. The models themselves become bulky and con-fusing.
Acausal modeling is closer to reality, for each of the components (e.g. resistors, transistors,.. ) of the above electric network a virtual equivalent exists. These virtual components are loaded from libraries and then configured and arranged like in the real circuit. The simulation software then extracts the equations. Encoding the mathematical algorithms to come to these relations is a major issue for providers of acausal modeling environments.
The model provided by Flanders Make was created with an acausal modeling paradigm - example tools are Matlab/SimScape and Modelica, which both work with objects and connections. In comparison, Matlab/Simulink or Scicos/Scilab would work with transfer functions and signals.
Contents of Flanders Make’s models are the fuselage, the main wings, the canards and the ailerons on both main wings and canards, plus the disturbance by gust loads. To keep simulation times short enough to allow evaluations of hundreds of configurations, only vertical accelerations (due to gust loads and the drone steering flaps) were taken into account. Thus propulsion could be omitted - the drone travels at fixed speed set by the simulation. Detailed models of the aileron actuators were kept out of scope, too.
The main wing was divided into short segments. For each of these, the mechanic and aero-dynamic equations were modeled to form together a so-called aero-elastic model of the wing segment. This division was also applied to the ailerons - a wing with n segments could thus have up to n actuated ailerons. Yet, the length of wing segments and ailerons was set to an arbitrary but fixed length.
A skyhook controller, similar to controllers used for active suspension systems was used to sta-bilise the system. The idea behind a skyhook controller is to virtually mount the system under consideration to a fixed anchor in the sky via a damper and to actuate the system in a way that the damping coefficient reaches (ideally) an infinite value. The controller was able to stabilise the simulated aircraft after a gust load.
4.2.3. The Test Scenario
A test consisted of three steps.
1. The model setup. The model was built by scripts and compiled before each run. The script was configured through input parameters. Amongst them was the number of wing segments that are present in the main wing and which of them have ailerons.
Here the skyhook controller imposed a limitation, as it could only control one aileron.
2. After building and compiling the model, ten seconds of flight are simulated - this already takes about five minutes on the lab machine (Intel Core i5-2400 @ 3.1GHz with 4GB of RAM). A gust load with a duration of 0.1s is applied near the beginning of the simulation,
then the controlled system is ”left” on its own.
3. The last step is the evaluation and visualisation of the results, the flying aircraft is rendered to a movie with positions of wing segments and angles of ailerons. Important parameters like the maximum acceleration of the fuselage and the quadratic norm of the accelerations are calculated.
This test scenario served to evaluate the possibilities investigated in figure 7 with the software developed in figure 6.
Conclusion
These two design problems will serve as benchmarks for the methods developed and used in the following chapters. Even if a design problem can be solved properly with a design method it does not prove that the method is optimal or well suited for this kind of problems. For such statements at least several projects are needed [BC09]. Usually, each project realised will reveal flaws in the method and new features that could be added. Informally speaking, a method grows with its applications.