7. The Generic Approach Applied to the Winged DroneWinged Drone
7.1. Explanation of the Project Stages
7.1.4. Framework Preparation
On the framework side three kinds of elements could be prepared. The first, smallest task, was to build a SysML description of the drone design space. The second, larger task, was to think of combinations of parameters that were contained in this design space described in SysML, but would yield an invalid drone. Rules were formulated to eliminate such combinations. The third task was a small development project to build visualisation tools for the evaluation results. These
all were works which could be done in parallel to the partner who was building the model and the evaluation.
SysML Design Space
Figure 7.7 shows the SysML model of the drone design space. The drone (named UAV - unmanned aerial vehicle) consists of a battery, a main wing and a canard. Additional wings were neglected as there is no space to mount them on the drone body. The lateral position of the battery was fixed to the center of the fuselage for the same reason, as well as to keep a symmetric weight distribution. The battery’s longitudinal position in the fuselage is open to optimisation and can be set to any value between0and 1, with0being the fuselage’s front end and 1representing the rear. The modeling decisions taken by the project partner also had an influence on the SysML description of the design space: Canard and MainWing are both of a newly defined WingSection type, and there may be up to five MainWing sections. As a drone is modelled symmetric, the number of wing sections was specified for one wing. The multiplicity of five was chosen later in the development, to keep the design space small enough to be evaluated in one day.
As it was found out by the project partner that the weight of the actuators had only minor impact on the behavior of the much heavier fuselage and wings, it was neglected. This required reengineering of models and criteria. In this process, an idea came up to model actuated wing sections in a different way, which reduced the complexity of the design space, and thus the time necessary to evaluate all possibilities:
The initial description contained three choices to be made for each wing segment: is there a wing segment at all, does it have an aileron, and how many actuators are mounted on the wing segment?
The new description fused these decisions into the selection of one integer numActuatorsusing the following rules:
• -2 would represent “no wing segment” in this position
• -1 meant a wing segment without aileron
• 0 indicated a wing segment with aileron, but no actuator in this position
• positive non-zero integers i represented a wing segment with aileron and i unit actuators (more precisely, an actuator with the same power asiunit actuators) attached. The number of unit actuators was still relevant to determine the power consumption.
During the project development, the design space matured in three versions, of which the upper is the final one. Setting up the project and SysML profile to support the modifications for the framework took one day’s work. Each version of the design space then was finished in one afternoon’s time of discussions and modelling.
Pruning Rules
Design problems represented like proposed in section 3.6 allow many combinations of parameters that are obvious to result in a malfunctioning system. Algorithms lack this common sense, thus a way to prepare the human’s knowledge in a machine-readable way is necessary. Figure 7.8 shows a valid drone and some combinations of wing setups which are considered invalid. The descriptions of the setups and the rules, why the setups are invalid, are given below.
7.1. Explanation of the Project Stages
Figure 7.7.: The SysML Representation of the Drone Design Space
Figure 7.8.: Some examples of invalid drones
1. A wing which is four segments long. The first three segments contain ailerons and one actuator is located on the third wing segment.
2. The first wing segment is missing, leaving the wing unconnected to the fuselage. The fact, that the actuator is located distant from the aileron is not considered a mistake - the influences of the actuator mass and position might be investigated later on.
3. The second wing segment is missing, leavingparts of the wing unconnected to the rest of the wing.
4. This setup contains only rigid wing sections without any ailerons, hence it is not able to navigate.
5. A setup without actuators is as useless as the setup without ailerons.
6. As the controller was only able to control one aileron, any concept with split ailerons was considered invalid. Besides, this setup would, again, not have any actuator.
Such rules had to be translated to Java code to be of use in the design space reduction. The relevant steps are shown in listing 7.2, with the simple rule checking the connectedness of the wing to the fuselage.
1 // set up d a t a s t r u c t u r e s for f i l t e r i n g
2 ...
3
4 // d e f i n e o r d e r of d e s i g n p a r a m e t e r s
5 f i l t e r G e n o m e . put ( " M a i n W i n g _ 1 . n u m A c t u a t o r s " ,0) ; 6 f i l t e r G e n o m e . put ( " M a i n W i n g _ 2 . n u m A c t u a t o r s " ,1) ; 7 f i l t e r G e n o m e . put ( " M a i n W i n g _ 3 . n u m A c t u a t o r s " ,2) ;
7.1. Explanation of the Project Stages
8 f i l t e r G e n o m e . put ( " M a i n W i n g _ 4 . n u m A c t u a t o r s " ,3) ; 9 f i l t e r G e n o m e . put ( " M a i n W i n g _ 5 . n u m A c t u a t o r s " ,4) ; 10 int [] p a r a m I n d i c e s = new int [ f i l t e r G e n o m e . s i z e () ];
11
12 // c r e a t e m a p p i n g b e t w e e n m o d e l p a r a m e t e r s and f i l t e r a r r a y i n d i c e s
13 ...
14
15 do {
16 // set up d a t a s t r u c t u r e s for c e r t a i n c o n c e p t
17 I t e r a t o r < F i x e d S y s t e m > s o l u t i o n I t e r a t o r = s o l u t i o n s . i t e r a t o r () ; 18 F i x e d S y s t e m [] s o l u t i o n A r r a y = new F i x e d S y s t e m [ s o l u t i o n S i z e ];
19 V a r i a b l e [] g e n o m e A r r a y = new V a r i a b l e [ g e n o m e S i z e ];
20
21 // c o p y d e s i g n p a r a m e t e r s to s o l u t i o n A r r a y and 22 // filter - r e l e v a n t p a r a m e t e r s to g e n o m e A r r a y 23 w h i l e ( s o l u t i o n I t e r a t o r . h a s N e x t () ) {
24 F i x e d S y s t e m s = s o l u t i o n I t e r a t o r . n e x t () ; 25 s o l u t i o n A r r a y [ i ] = s ;
26 I t e r a t o r < String > it = s . g e t V a r i a b l e s () ; 27 w h i l e ( it . h a s N e x t () ) {
28 S t r i n g str = it . n e x t () ;
29 if ( s o l u t i o n I n d i c e s [ v a r C o u n t ] > -1) {
30 g e n o m e A r r a y [ s o l u t i o n I n d i c e s [ v a r C o u n t ]] = new S t r i n g V a r ( str ) ;
31 }
32 v a r C o u n t ++;
33 }
34 i ++;
35 }
36
37 b o o l e a n g o o d = t r u e ;
38 // a p p l y f i l t e r s on g e n o m e A r r a y
39 ...
40 // e . g . c h e c k if the w i n g s e g m e n t n e x t to f u s e l a g e e x i s t s 41 // == c h e c k if w i n g is c o n n e c t e d to f u s e l a g e
42 if ( g o o d && g e n o m e A r r a y [ 0 ] . e q u a l s ( i n e x ) ) {
43 g o o d = f a l s e ;
44 }
45 // f u r t h e r c h e c k s
46 ...
47 // if c o n c e p t p a s s e s all checks , add it to v a l i d s o l u t i o n s 48 if ( g o o d ) {
49 f i l t e r e d S o l u t i o n s . add ( s o l u t i o n A r r a y ) ;
50 }
51 // l o o p o v e r all g e n e r a t e d s o l u t i o n s 52 } w h i l e (! s o l u t i o n s . t i c k () ) ;
53 r e t u r n f i l t e r e d S o l u t i o n s ;
Listing 7.2: Filter Definition for the UAV showcase
The process of setting up the filter structures, identifying the rules behind invalid solutions and encoding them took about a week.
Visualisation of Results
The last thing to prepare were tools to quickly interprete the result data. Certain charts offer graphical representations of numeric values that give a fast and reliable impression on character-istics of the displayed data. Two charts were implemented to load and visualise the result data.
The code was kept flexible to be able to deal with any result file following the framework’s result file format.
• Two-Parameter Bar Chart
The intention of this representation was to compare two design parameters with respect to their impact on one optimisation criterion, if more than one parameter are existent in the design space. An example plot can be seen in figure 7.9. The chart contains the results for an evaluation of the portal robot from figure 3.4. The chart shows the influence of the realisations and is composed as follows:
– The vertical and diagonal axis are made up by the two input parameters. There is one line/column per possible value on those parameters, making each intersection represent one possible combination of these parameters.
– For each intersection, all concepts using the combination of the input parameters are scanned for the two best and worst regarding the specified optimisation criterion.
– The two concepts with the highest result for the optimisation criterion, as well as the two concepts with the lowest result, are plotted with their scores as a mini bar-chart at the intersection point. There are two reasons for this implementation:
∗ First, a maximum value might not be the best one at all - in the charts in the example, the RMS of the positioning error is plotted, thus the minimum value is the most desirable one.
∗ Second, if a certain parameter value can be identified to always result in bad system performance, it can be excluded via the above mechanism for pruning rules.
– The bars for the optimisation criteria are normalised to the minimum and maximum score found in the result file. Hence a full dark bar means the maximum value, a completely white bar the minimum value. Whether this is best or worst depends on the optimisation problem.
In the demonstration bar chart in figure 7.9, the minimum values for the positioning error occur in the lines and colums where a big drive is used for “Drive1” and a small drive used for “Drive2” (right top corner).
As an additional help, clicking a bar in the chart displays additional information on the input parameters.
• Two-Criteria Scatter Plot
In this chart, the results are plotted in the space of two optimisation criteria. This allows to get a quick glance on the question if pareto fronts and dependencies between criteria exist. In the demonstration given in figure 7.10 there are markers in all corners which indicates that the optima for the criteria can be reached independently from each other.
A straight line would indicate, that the criteria are coupled, whereas a blank corner may indicate unreachable combinations. It may, as well, simply indicate, that not all possibilities were tested.
7.1. Explanation of the Project Stages
Figure 7.9.: A Two-Parameter Bar Chart Demo
Figure 7.10.: A Two-Criteria Scatter Demo