Real-Time Moment Rate Constrained Control Allocation for … · 2020. 9. 28. · moment-rate...

Real-Time Moment Rate Constrained Control Allocation forAircraft with a Multiply-Redundant Control Suite

Jeffrey Q. Leedy

Thesis submitted to the Faculty of the

Virginia Polytechnic Institute and State University

in partial fulfillment of the requirements for the degree of

Master of Science

in

Aerospace Engineering

Wayne C. Durham, Chair

Mark Anderson

Frederick Lutze

June 30, 1998

Blacksburg, Virginia

Keywords: Aircraft Dynamics, Flight Control, Aerospace

Copyright 1998, Jeffrey Q. Leedy

Real-Time Moment Rate Constrained Control Allocation for Aircraft with a

Multiply-Redundant Control Suite

Jeffrey Q. Leedy

(ABSTRACT)

The problem of aircraft control allocation is that of finding a combination of control positions

that cause the resulting aircraft moments to most closely satisfy a given desired moment vec-

tor. The problem is easily solved for the case of an aircraft having three control surfaces,

each of which primarily imparts moments in each of the three aircraft axes. In this simple

case, the solution to the control allocation problem is uniquely determined. However, many

current and future aircraft designs employ a larger set of control effectors, resulting in a

control redundancy in the sense that more than one combination of control positions can

produce the same desired moment. When taking into account both the position and rate

constraints of the control effectors, the problem is significantly more complex. Constrained

moment-rate control allocation guarantees a control solution that can achieve every possible

moment that is physically realizable by the aircraft. Addressed here is the real-time per-

formance of moment-rate constrained control allocation as tested on a desktop simulation.

Issues that were deemed interesting or potentially problematic in earlier batch simulation,

such as control chattering due to restoring and apparent control wind-up, are investigated

and an evaluation is made of the overall feasibility of these algorithms. The purpose of the

research is to confirm that the results obtained from batch simulation testing are also valid

using maneuvers representative of real-time flight and representative simulation frame sizes,

and to uncover potential problems not observed in batch simulation.

This research was conducted under NASA Research Grant NAG-1-1449, supervised by John

V. Foster, technical monitor, of the NASA Langley Research Center. Support was also

provided under research contracts with the Naval Air Warfare Center Aircraft Division,

Flight Vehicle Simulation Branch.

Nomenclature

c Mean aerodynamic chord

Ω Set of admissible control solutions

∂(Ω) Admissible control subset boundary

∂(Φ) Attainable moment subset boundary

Φ Set of attainable moments

b Wingspan

Jx x-moment of inertia

Jy y-moment of inertia

Jz z-moment of inertia

Jxz xz-moment of inertia

m Aircraft mass

S Wing planform area

xcgref Reference x-center of gravity

AMS Attainable Moment Subset

CA Control allocation

EOM Equations of motion

Global Global

SL Stick logic

∗ On boundary

⊥ Perp (in null space)

iii

Contents

1 Introduction 1

1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Summary of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Control Allocation 6

2.1 History/Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Direct Control Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Moment-Rate Control Allocation . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Simulation Implementation 12

3.1 Batch Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Real-Time Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

iv

3.2.1 Batch Simulation Modules . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.2 Real-Time Simulation Modules . . . . . . . . . . . . . . . . . . . . . 16

3.2.3 Significant Simulation Code Modifications . . . . . . . . . . . . . . . 16

3.3 Aircraft Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 Control System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4.1 Control System Model . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.4.2 Stick Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4.3 Control Law . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4.4 Control allocator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Null-Space Saturation 25

5 Control Restoring 34

5.1 Restoring to a Known Solution . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Restoring to an Unknown Solution . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Restoring Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3.1 Minimum-Norm Restoring . . . . . . . . . . . . . . . . . . . . . . . . 37

5.3.2 Minimum-Drag Restoring . . . . . . . . . . . . . . . . . . . . . . . . 39

5.3.3 Maximum-Norm Counter-Restoring . . . . . . . . . . . . . . . . . . . 39

v

6 Control Surface Chattering 40

7 Representative Maneuvers 48

7.1 Aggressive Combat Maneuvering . . . . . . . . . . . . . . . . . . . . . . . . 51

7.2 Formation Flying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.3 PIO-like Maneuver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

8 Timing Performance 74

8.1 Computational Intensiveness . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

8.1.1 Sources of Variation in Algorithm Performance . . . . . . . . . . . . . 75

8.2 Timing Performance Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

9 Conclusions 80

A State Variable Time Histories for Representative Maneuvers 84

A.1 Aggressive Combat Maneuver . . . . . . . . . . . . . . . . . . . . . . . . . . 84

A.2 Formation Flying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

A.3 PIO-like Maneuver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

B SimCode 96

vi

List of Figures

3.1 Real-Time Simulation Architecture. . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Modular control system structure. . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Stick logic implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Control inputs which cause migration of control positions from their zero

positions after a maneuver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Migration of control positions from their zero positions after a maneuver. . . 27

4.3 Illustration of null space saturation; mapping of control to moment space . . 31

4.4 Illustration of null space saturation; null-space saturated vs. unsaturated case 32

6.1 Pilot inputs for bank-and-turn task. . . . . . . . . . . . . . . . . . . . . . . . 42

6.2 Influence of minimum-drag restoring minimization parameter Cs on elevator

deflections for bank-and-turn task. . . . . . . . . . . . . . . . . . . . . . . . 43

6.3 Influence of minimum-drag restoring minimization parameter Cs on aileron


vii

6.4 Influence of minimum-drag restoring minimization parameter Cs on rudder


6.5 Influence of minimum-drag restoring minimization parameter Cs on elevator


7.1 Multi-axis maneuver used in batch control allocation testing. . . . . . . . . . 50

7.2 Pilot inputs for aggressive combat maneuvering task. . . . . . . . . . . . . . 52

7.3 Elevator positions for aggressive combat maneuvering task. . . . . . . . . . . 53

7.4 Aileron positions for aggressive combat maneuvering task. . . . . . . . . . . 54

7.5 Combined rudder positions for aggressive combat maneuvering task. . . . . . 55

7.6 Moment time histories for aggressive combat maneuvering task. . . . . . . . 56

7.7 Control vector 2-norm time histories for aggressive combat maneuvering task. 59

7.8 Pilot inputs for formation flying task. . . . . . . . . . . . . . . . . . . . . . . 61

7.9 Elevator positions for formation flying task. . . . . . . . . . . . . . . . . . . 62

7.10 Aileron positions for formation flying task. . . . . . . . . . . . . . . . . . . . 63

7.11 Combined rudder positions for formation flying task. . . . . . . . . . . . . . 64

7.12 Control-generated moments for formation flying task. . . . . . . . . . . . . . 65

7.13 Pilot inputs for a PIO-like maneuver. . . . . . . . . . . . . . . . . . . . . . . 68

7.14 Elevator positions for a PIO-like maneuver. . . . . . . . . . . . . . . . . . . . 69

viii

7.15 Aileron positions for a PIO-like maneuver. . . . . . . . . . . . . . . . . . . . 70

7.16 Combined rudder positions for a PIO-like maneuver. . . . . . . . . . . . . . 71

7.17 Control-generated moments for a PIO-like maneuver. . . . . . . . . . . . . . 72

7.18 Comparison of maximum, produced, and commanded moments in the lateral

direction for a PIO-like maneuver. . . . . . . . . . . . . . . . . . . . . . . . . 73

8.1 Time history of timing statistics averaged over 40 identical simulation runs. . 78

A.1 Time histories of VT , α, and β for aggressive combat maneuvering task. . . . 85

A.2 Time histories of φ, theta, and ψ for aggressive combat maneuvering task. . . 86

A.3 Time histories of north position, east position, and altitude for aggressive

combat maneuvering task. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

A.4 Time histories of total velocity, angle of attack, and sideslip angle for formation

flying task. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.5 Time histories of φ, theta, and ψ for formation flying task. . . . . . . . . . . 90

A.6 Time histories of north position, east position, and altitude for formation

flying task. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A.7 Time histories of VT , α, and β for PIO-like maneuver. . . . . . . . . . . . . . 93

A.8 Time histories of φ, theta, and ψ for PIO-like maneuver. . . . . . . . . . . . 94

A.9 Time histories of north position, east position, and altitude for PIO-like ma-

neuver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

ix

List of Tables

3.1 Input and output files used in the real-time simulation. . . . . . . . . . . . . 17

3.2 Mass and Geometric Data for the F-18 HARV. . . . . . . . . . . . . . . . . . 19

3.3 Control position and rate limits for the F-18 HARV. . . . . . . . . . . . . . . 19

x

Chapter 1

Introduction

1.1 Background

The study of aircraft control allocation has become an increasingly important part of aircraft

control system research since the introduction of aircraft designed with multiply redundant

control effectors. The term effectors is used instead of the more common but restrictive

surfaces to emphasize the generality in mechanisms which could be used to produce aircraft

forces and moments. Any phenomenon, mechanical or otherwise, which could be used to

impart a force or moment on an aircraft in a controlled manner could be considered a

control effector. Use of thrust vectoring or of throttle control are two reasonable examples of

effectors which are not necessarily surfaces. Employing increasingly complex control suites

has a twofold effect on the aircraft. An advantage of control redundancy is the capability

to produce larger moments, which increases the aircraft’s maneuverability. Contrary to

this effect is the increased weight, which inevitably increases aircraft cost and aerodynamic

drag, among others. The search for a control allocation scheme which realizes the aircraft’s

maximum moment-generating capability is obviously of interest in alleviating the above

problems. Such a scheme enables the possibility of downsizing or even eliminating one or

more control surfaces, driving down weight, drag, system complexity, and perhaps most

importantly, cost. Allocation schemes which sacrifice efficiency for computational simplicity

are in certain instances undesirable if another scheme is proven to realize more of the aircraft’s

1

Jeffrey Q. Leedy Chapter 1. Introduction 2

maneuvering potential and does so rapidly enough to allow real-time processing.

Such a scheme which produces control deflections which adhere to the control effector position

and rate constraints (referred to as the set of admissible controls) is realized by constrained

moment-rate control allocation, the origins of which appear in Durham [7]. This method

results in control deflections which produce the desired moment so long as the command is

attainable at all by the aircraft’s control suite.

1.2 Objectives

Constrained moment rate aircraft control allocation is examined in a real-time environment

using a desktop simulation. The current work is an expansion of that found in Bolling [3], in

which a nonlinear, 6 degree-of-freedom aircraft batch simulation was created which employed

the control allocation techniques found in Durham, Bordignon, et al. [1-9,11,12], referred to

in this work as Moment Rate Control Allocation (MRCA). Questions and issues raised by

the previous work include the following, all of which are addressed in this work:

1. Control surface chattering. The results of batch simulation testing revealed a phe-

nomenon in which the control surfaces sometimes exhibited a rapid “chattering” in

which a control oscillated between two distinct positions, seemingly straddling some

desired medium. This phenomenon was identified when certain control surface restor-

ing algorithms were employed, which are discussed in Chapter 5.

2. Timing. Issues relating to the speed at which the algorithms could be performed are

important with regards to the feasibility of employing these techniques real-time on an

aircraft. The nature of MRCA is such that there could be a substantial variance in the

amount of time required to perform the required calculations in a given computational

frame. Factors which affect the calculation time are examined and some preliminary

evaluations are made regarding timing performance in a real aircraft.

3. Control surface windup/“Null-Space Saturation”. Due to the path-dependent nature

of the control solutions given by MRCA, the controls in general can produce desired


moments while themselves being in an unconventional and possibly undesirable con-

figuration. The ramifications of this path-dependence are examined.

This research is intended as a necessary transition between batch simulation testing and

future simulator implementation, with a possible eventual implementation on a real aircraft.

Specifically, the following contributions to the understanding of the performance of moment

rate control allocation algorithms developed at Virginia Tech are as follows:

1. Implementation. Real-time moment rate control allocation is implemented in a desktop

simulation in which a pilot has the ability to control an aircraft and immediately

respond to visual changes in environment using real-time inputs. These inputs can

be representative of realistic inputs which produce realistic maneuvers, which batch

simulation cannot produce.

2. Testing. Testing of the algorithms using maneuvers representative of actual flight is

performed. Issues which arose previously during batch testing are examined using

specific maneuvers thought to expose potential problems or shortcomings of the algo-

rithms. Specifically, the issues described above are examined for the first time in a

real-time context.

1.3 Summary of Results

Real-time testing of the moment-rate control allocation algorithms led to the following sig-

nificant general results:

1. Control surface chattering is found to occur in some situations in which certain control

restoring methods are employed. After allocation of controls based solely on moment

demands, superposition of a restored control solution when restoring to an unknown

desirable solution can result in such an effect. It is difficult to determine how often

chattering occurs in real-time flight, but it is an effect which should be considered when

implementing such a restoring algorithm.


2. Control surface chattering is found to occur during simulation in some situations in

which certain control restoring methods are employed. After allocation of controls

based solely on moment demands, superposition of a restored control solution when

restoring to an unknown desirable solution can result in such an effect. It is shown that

judicious selection of a restoring scaling parameter can effectively reduce the magnitude

of control surface chattering while still affording a reasonable restoring speed.

3. The timing performance of the algorithms with respect to the computational ability of

modern-day flight control computers is inconclusive. A reasonable assumption is that

the time required to perform the control allocation portion of the total control system

computational budget is much larger than that required for most conventional stick

logic schemes and somewhat larger than for most control laws. Industry estimation of

control system computing power in the near future is varied, leaving open the possibility

that the calculations involved in moment rate control allocation are too intensive to be

run at a reasonable (i.e. 80 Hz) frame rate. The simplest remedy would be to simply

allocate at a slower frame rate. Other suggestions for improvement include improving

the method of searching for the AMS facet which is intersected by the desired moment

vector (see Chapter 8), which is the subject of ongoing research. Parallel processing

is another possibility for increasing the computational capability necessary to perform

the control allocation functions. It is surmised that employing one or more of these

remedies would be enough to make implementation of moment rate control allocation

algorithms reasonable for the near-future generation of control system computer. Of

these, simply allocating controls asynchronously (perhaps every .1 or .2 seconds) seems

to be the most reasonable solution.

4. The tendency of the controls to sometimes migrate from a desirable (i.e. minimum-

norm) solution if that desirable criterion is not explicitly considered in the calculations

is examined and methods used to rectify the allocation of unconventional control con-

figurations are presented again. The control redundancy afforded by many control

surfaces coupled with the frame-wise method of allocating controls enables many dif-

ferent control restoring methods to be devised which return the controls to a more

conventional or benign configuration, most likely alleviating possible loss of moment

rate-generating capability caused by such “wild” configurations. Real-time testing con-

firmed the ability of two candidate restoring methods to restore controls in a reasonable

amount of time. Also, simulations in which no restoring was employed suggested that


the lost moment capability due to control positions migrating close to their physical

limits does not seem to cripple the aircraft as was originally feared. This phenomenon

which is somewhat disconcerting at first glance is actually only cosmetically so, and

performance differences which can be directly attributed to different methods of control

restoring are shown to be reasonably slight.

Chapter 2

Control Allocation

2.1 History/Literature Review

The origins of Moment Rate Control Allocation techniques can be found in the work of

Durham and Bordignon. The so-called direct method of solution to the control allocation

problem was first presented by Durham [8]. The motivation behind this method of solution

was the recognition that current solution methods to the control allocation problem, though

sometimes computationally simple, were restrictive in that, in general, the entire moment-

generating capability of the aircraft controls could not be realized by these schemes. A

fairly comprehensive set of control allocation techniques (including direct allocation and

moment-rate allocation as well as other current methods) is presented in Bordignon [4],

and discussion of these other methods here will be minimal. It is desirable to employ a

scheme which uses a fuller set of “known” information to produce the maximum moment-

generating capability of an aircraft. Direct allocation makes use of the inherent geometry of

the problem when the control effector position limits are taken into account. Other schemes,

such as generalized inverse solutions (including the pseudoinverse or minimum-norm solution)

neglect this information and as a result cannot guarantee admissible control solutions given

an attainable desired moment vector. The following discussions are largely taken from the

work of Durham, Bordignon, and Bolling in this area and only relevant material is included

as a brief summary of these control allocation techniques.

6

Jeffrey Q. Leedy Chapter 2. Control Allocation 7

2.2 Direct Control Allocation

The control allocation problem involves solving for a set of control positions u which will

produce a given desired moment vector md. Let m denote the number of controls available

for allocation and n denote the number of objectives to be produced (3 moments in basic

aircraft control allocation applications; frequently expressed in a body-fixed axis system, e.g.

rolling, pitching, and yawing moment). The vectors u and md are related through a matrix

B :

md = Bu (2.1)

where B is an n-by-m control effectiveness matrix:

B ≡[∂m∂u

](2.2)

The B matrix can be time-varying and its entries are usually obtained from table lookups

as functions of angle of attack, sideslip angle, and Mach number, among others. For the

case of redundant controls (m > n), there exist an infinite number of control configurations

which produce a given moment, so long as the moment is not at the limit of the aircraft’s

capabilities. In this case there exists only one control configuration which produces the

desired moment. In the case where the desired moment exceeds the capabilities of the

aircraft’s control surfaces, constrained control allocation seeks to produce the maximum

moment in the direction of md. Other interpretations of the “best” moment in this case are

possible, although they will not be discussed here.

An aircraft’s controls are each subject to position and rate limits. The subset Ω of control

deflections which are admissible with respect to position constraints is defined as

Ω = u ∈ Rm |uimin ≤ ui ≤ uimax ⊂ Rm (2.3)


Since the controls and the moments produced are related through the matrix B , the mapping

of the admissible control subset Ω to moment space is described by:

Φ = m ∈ Rn |Bu = m,u ∈ Ω ⊂ Rn (2.4)

The attainable moment subset (AMS) is denoted Φ and describes in three-space the complete

moment-generating capabilities of the aircraft at the given flight condition. On the interior

of Φ, solutions are not unique if the number of controls exceeds the number of moments to

be produced, and hence there are an infinite number of solutions which lie in the null space

of B . On the boundary of the AMS, denoted ∂(Φ), for a given md there exists a unique set

of control positions which can attain the desired moment.

Determination of the facets (faces formed by the mapping of Ω via B to moment space which

lie on ∂(Φ)) of the AMS is discussed in [4] and is summarized here. This determination can

be facilitated by finding a rotation matrix T which brings one of the three moment axes

perpendicular to a set of potential facets. Consider only the row of T corresponding to

the first moment axis, and denote this row vector t = [t1, t2, ..., tn]. Given a set of parallel

faces, the two facets lie the greatest distance from the origin, so maximizing and minimizing

tBu produces the desired facets. Denoting the controls defining a set of parallel faces as i

and j , we wish to form a vector tB which has zero entries corresponding to the two varying

controls i and j and either positive or negative values for the remaining entries. The resulting

elements of t are: [t1

t2

]=

[Bi ,1 Bj ,1

Bi ,2 Bj ,2

]−1 [Bi ,3

Bj ,3

](2.5)

The matrix tB can be examined and facets determined by the following rules:

1. The facet which maximizes tBu is defined by setting controls corresponding to posi-

tive elements of tB to their maximum positions and setting controls corresponding to

negative elements of tB to their minimum positions.


2. The facet which minimizes tBu is defined by setting controls corresponding to posi-

tive elements of tB to their minimum positions and setting controls corresponding to

negative elements of tB to their maximum positions.

The other parallel faces lie on the interior of the AMS.

A desired moment vector which lies outside of Φ is unattainable by any set of control deflec-

tions. In this case a decision must be made about what constitutes the “closest” attainable

vector to md. A simple and obvious choice is the vector which lies along the direction of

md but which has a magnitude equal to the greatest attainable moment in that particular

direction. Scaling while preserving the directionality of md in this way retains the desired

moment direction, but other considerations may favor other methods of choosing the “clos-

est” attainable desired moment vector. Some of these methods are described in Bodson and

Pohlchuck [2] and include relaxing the control requirements, scaling the reference inputs,

and approximating the commanded accelerations in a least-squares sense.

The process of finding a set of control deflections which produce the desired moment md

provided the moment is attainable by any allocation scheme is straightforward. Given the

knowledge of the global AMS (in contrast to the notion of a “local” AMS to be discussed

later), it is a matter of geometry to find the intersection of md with ∂(Φ). Once this

intersection (denoted m∗) is found, the unique vector of controls which produce the maximum

attainable moment in that direction is easily found as the point in control space which directly

maps to the intersection of md and Φ in moment space. The mapping between ∂(Φ) and

∂(Ω) is one-to-one, so the resulting control vector u∗ is unique. The factor by which the

magnitude of m∗ exceeds the magnitude of md is used to scale u∗, resulting in the desired

control solution u.

2.3 Moment-Rate Control Allocation

The ideas of direct control allocation can be extended to account for the rate limits on the

controls as well as position limits. Moment Rate Control Allocation (MRCA) is essentially

a framewise extension of Direct Allocation, which lends itself to easy implementation in an


aircraft simulation. Given a computational frame size ∆t , the amount of movement possible

by a control ∆u in one frame is the more restrictive of the global control position limits and

the rate limits expressed as the amount of travel possible in one frame, or:

∆umax = min[(umax∆t), (umax − uk )] (2.6)

∆umin = max[(umin∆t), (umin − uk )] (2.7)

Now define ∂(Ω) as the subset of control positions attainable in one computational frame

relative to the last control solution. The resulting “delta-AMS” is the mapping of this control

subset to moment space. In each frame, the delta-AMS describes the moment capabilities

in a local sense (relative to the last produced control-generated moment). Allocation is per-

formed as in Direct Allocation but using the local geometry rather than the global geometry

described by ∂(Ω) and ∂(Φ). Now the current desired local moment ∆mdkis defined as the

vector difference between the previous global attained moment mdk−1and the current desired

global moment mdk. The intersection of ∆mdk

with the boundary of the current delta-AMS

is found, and the control solution ∆uk is found by appropriately scaling the control vector

corresponding to the intersection in moment space m∗k .

There are several advantages to employing a moment-rate control allocation scheme in-

stead of the purely global constrained control allocation scheme from which the moment-

rate scheme originated. The first of these is the fact that both position and rate limits can

be explicitly accounted for when a discretized approach is taken, since maximum rates are

interpreted as nothing more than maximum control distance travelled in a given amount of

time, usually the frame size. Accounting for rate limits is as important as accounting for

position limits since rate limits are just as physical and can frequently be approached and

ridden when intense maneuvering is desired.

A second advantage of moment-rate algorithms is the fact that in real-time flight the frame

size is presumably small, making the assumption of linear control effectiveness expressed in

B more nearly valid, since as t → 0 control effectiveness becomes more linear. In global

constrained control allocation, since a global BGlobal is used, the inevitable nonlinearities in


effectiveness far from the linearization point can be significant.

Chapter 3

Simulation Implementation

A six degree-of-freedom nonlinear aircraft simulation was used to test the moment rate

control allocation algorithms, first in batch by Bolling [3], and then in real-time. The ideas

and algorithms first developed by Durham and Bordignon for Direct and Moment Rate

Control Allocation are present in the batch simulation, which was developed by Bolling from

a much more basic simulation engine given in Stevens and Lewis [14]. The reader is referred

to the Appendices in Bolling [3] for a complete listing of FORTRAN subroutines used in

the batch simulation implementation, which is a full listing of simulation code including

command interpreter and various utilities, with user documentation included.

3.1 Batch Implementation

The Stevens and Lewis simulation is used as the baseline for the batch simulation developed

by Bolling. The simulation given in the book is of an F-16 aircraft with only three primary

sets of control surfaces (elevator, ailerons, and rudder), and aerodynamic lookup tables are

few, with interpolation routines written inline. Therefore, only the very basic structure of

the simulation (equations of motion, integration scheme, linearization routine) is retained in

Bolling’s simulation. Enhancements to this structure include a command interpreter or shell,

an architecture which allows different aircraft to be “plugged into” the simulation, and var-

12

Jeffrey Q. Leedy Chapter 3. Simulation Implementation 13

ious input/output utilities. The batch simulation was initially developed on a MacintoshTM

platform using LS FortranTM and was ported to a Silicon Graphics IndigoTM Workstation

using Unix MiPS Fortran on an IRIXTM operating system. This workstation exhibits a

single 200 MHz processor and has 64 MB of RAM. The user interface consists of simple text

menus and the user issues commands via the keyboard or via input files which can load in

trim conditions, set maneuver generator inputs, or set flags which toggle certain simulation

and aircraft configuration options. The types of available output files include linearization

results (A, B , C , and D matrices), simulation time histories, and diagnostic routines used

to track the performance of the control allocation algorithms.

3.2 Real-Time Implementation

Real-time simulation of moment rate control allocation was desired to examine performance

of the algorithms when maneuvers representative of “real-life” flight were used to generate

moments. With real-time capability the ability of the algorithms to perform as designed

could be more easily tested, eliminating the need to generate artificial maneuvers in which

the pilot would not be responding to visual cues. A real-time simulation would enable test-

ing of the algorithms using maneuvers which would be deemed potentially taxing to the

performance of the algorithms, both in terms of time required for the algorithms to perform

the required calculations and of the probability that rate saturation might occur. Three

such maneuvers—an aggressive combat maneuvering task, a formation flying task, and an

artificially induced PIO-like maneuver—are examined in detail later and the performance of

the control allocation algorithms is evaluated during performance of these maneuvers. The

batch simulation architecture was retained for inclusion in the real-time simulation on the

SGI. Essentially every capability of the batch simulation is present in the real-time simu-

lation. In addition to the Fortran routines developed for the batch simulation, C code is

used for the most part to draw the out-of-window graphics view and to read and interpret

the pilot’s stick inputs during real-time flight. The C code consists of OpenGL calls taken

largely from an unreleased piece of code written by Bruce Jackson of NASA Langley. Fortran

common blocks containing variables needed by the C code drawing functions and stick read

functions are each associated with a structure set up in a C header file. Appendix B presents

a listing of some of the Fortran routines which are significantly changed from the batch sim-


ulation implementation. The routines are presented for reference only, and certain routines

and code sections are omitted for brevity. They are presented merely to give the structure

of one possible real-time implementation of the control allocation algorithms. Significant

changes from the baseline batch simulation include:

1. Modifications to the restoring algorithms presented in the RESTORE U routine found

in Conallo.x.

2. Implementation of the “iron bird” stick logic in the FMODELREAL routine found in

F18 Funs x.f as described in Section 3.4.2.

3. Modifications related to real-time simulation in subroutine REALMAIN found in Real-

main.f and all associated C code called from REALMAIN. This routine contains the

only direct calls of C code from the Fortran portion of the simulation code.

4. Various modifications of input and output routines, most notably in many routines in

the File IO.f source file.

Other changes in the code include the modification of the variable arrays included in the

SIMPRS (simulation parameters), SIMVARS (simulation variables), and A CVARS (aircraft

variables) common blocks.

New functionality of the real-time simulation includes the following features:

1. The ability to record a flight real-time and to visually play back the saved flight using

the AGILE-VU flight visualization software developed by McDonnell Douglas Aircraft

and the Naval Air Development Center. Features of this software include the ability

to play back flights and examine the evolution of variable time histories at different

forward and reverse speeds; the ability to display two or more flights simultaneously;

the ability to graphically depict aircraft body axis reference frames as well as angle of

attack and sideslip, trajectory traces, and altitude bars.

2. The ability to run a simulation real-time and to replay the flight using saved pilot

input information for repeatability.


The simulation architecture is presented in Figure 3.1. The previously developed batch sim-

ulation is shown in the bottom portion. All primary code modules are presented in flowchart

boxes. Modules which are either completely unchanged or changed only cosmetically are

shown in white boxes, while new sections of code and old modules which are significantly

changed are shown in shaded boxes. Code used in the real-time upgrade of the simula-

tion is presented outside the dashed box; this code includes a real-time executive, new file

input/output options, and code which draws the out-of-window cockpit view. A brief de-

scription of each module follows. For a more complete description of the batch simulation

code, the reader is referred to Bolling [3].

3.2.1 Batch Simulation Modules

The following is a list of the batch simulation modules. A star (*) next to the name of a

module denotes that it is an aircraft-specific module; all other modules are general and can

be used essentially without modification regardless of the aircraft database used.

1. a c$getueff*. Gets the control effectiveness data for a specified axis and control.

2. a c$getcstr*. Gets the control position and rate constraints.

3. conallo. Main control allocation executive module which allocates controls given a

desired moment vector. This module performs either global and frame-wise control

allocation depending on the application (linearization and stick logic require global

allocation, real-time control allocation requires frame-wise allocation.)

4. getfacet. Given a pair of allocatable controls, generates the geometry of a valid facet

composing a portion of the AMS boundary.

5. get mat. Generates a 3x3 matrix in moment space composed of the vector pointing

from the origin to a facet vertex (1st column) and the vectors from the facet vertex to

each of two facet edges (2nd and 3rd columns).

6. get u. Takes the facet described by get mat and determines if it is intersected by the

desired moment vector. If so, it calculates the controls needed to produce md.


7. invmat3. Finds the minimum-norm right inverse P for a 3×m matrix B .

8. d3. Calculates the determinant of a matrix.

9. restore u. Performs control restoring algorithms as described in Chapter 5.

10. pinvb4. Finds the minimum-norm right inverse P for a 4×m matrix B .

11. invmat4. Performs a 4× 4 matrix inversion.

12. allodiagsout. Generates diagnostic data for control allocation calculations; useful

in debugging algorithms and examining frame-by-frame status of control allocation

variables.

3.2.2 Real-Time Simulation Modules

1. realmain. Serves as the main real-time simulation executive. Performs calls to aircraft

equations of motion, integration routine, F18Funs; calculates and handles real-time

and timing statistics calculations.

2. F18Funs*. Contains stick logic, flap scheduling, control law, and aircraft database

simplification code. This module also performs the two calls to conallo, the first

of which is a global call used in performing stick logic and the second of which is a

frame-wise call used to allocate the controls.

3. file io*. Performs reading and writing to various input and output files. The types of

input and output files used in the simulation are presented in Table 3.1.

4. our glcockpit.c. Contains platform-dependent routines which draw the out-of-window

view, draw other aircraft, and accept pilot stick and rudder inputs.

3.2.3 Significant Simulation Code Modifications

The shaded boxes in Figure 3.1 which lie within the dashed box denote modules whose

contents have been significantly modified from the baseline batch simulation. These changes

are outlined below.


Table 3.1: Input and output files used in the real-time simulation.

File Type Input/Output Description

States output Aircraft states

State Derivatives output Aircraft state derivatives

Controls output Aircraft control positions

Moments output Aircraft moment vector

Conallo output Control allocation variables

Rates output Control and moment rate variables

Timing output Timing statistics

Misc output Miscellaneous (developer use)

Inputs input/output Pilot inputs (can be used to ’re-fly’ a particular real-time flight)

Bogey1 input/output x, y, and z trajectory of current flight

Bogey2 input/output x, y, and z trajectory of a bogey drawn on the screen

Agile VU output Input to Agile-vu visual flight replay application

1. conallo. This module retains all of its original functionality. In addition, calculation

of the 2-norm of the allocated control vector, actual moments produced, moment and

control rates, and certain control saturation information is performed. Many of these

changes are implemented to account for the fact that conallo is called twice in the

real-time simulation every frame.

2. restore u. This module, called by conallo, includes an alternate implementation

of minimum-norm restoring described in subsection 5.3.1 and includes an additional

option, maximum-norm counter-restoring (see subsection 5.3.3), which is included for

purposes of artificially driving the controls towards a state of null-space saturation as

described in Chapter 4.

3.3 Aircraft Model

The aircraft model tested is the Navy’s F-18 HARV (High Angle-of-Attack Research Vehicle).

The aircaft was so selected because of its redundant control suite, which includes nine control

effectors in all. Table 3.2 shows a summary of aircraft geometric data used in the simulation.


conalloa_c$getueff

a_c$getstr

get_u

invmat4pinvb4restore_u

allodiagsout

get_matget_facet

d3

invmat3

realmain

file_io

call 1 forstick logic

(uses globallimits)

call 2 forallocatingcontrols

(uses frame-wise limits)

reads input from files, writes output to files

our_glcockpit.c

draws out-of-cockpit view

F18Funs

containsstick logic

module

real-time executive

input and outputfiles

batch simulation

Figure 3.1: Real-Time Simulation Architecture.


Table 3.2: Mass and Geometric Data for the F-18 HARV.

Moments of Inertia GeometryJx = 2.317 × 104 sl-ft2 S = 400.0 ft2

Jy = 1.239× 105 sl-ft2 b = 34.72 ftJz = 1.432 × 105 sl-ft2 c = 11.52 ftJxz = −2.971× 103 sl-ft2 xcgref = −0.25 c

m = 1000.0 sl

Table 3.3: Control position and rate limits for the F-18 HARV.

Control Description Deflection Limits Rate Limits Allocation Type

(deg) (deg/sec)

DHTL Left horizontal tail -24.0 / 10.5 40.0 MRCA

DHTR Right horizontal tail -24.0 / 10.5 40.0 MRCA

DAL Left Aileron -25.0 / 25.0 100.0 MRCA

DAR Right Aileron -25.0 / 25.0 100.0 MRCA

DRUD Combined rudders -30.0 / 30.0 50.0 MRCA

DLFL Left leading edge flap

DLFR Right leading edge flap

DTFL Left trailing edge flap

DTFR Right trailing edge flap

The controls and their position and rate limits are given in Table 3.3. Five of the controls

are used in the allocation scheme and the remaining four are either scheduled using flap

scheduling information from table lookups or held at a constant position. The aerodynamic

database of the F-18 HARV used in the simulation was made available by the Navy. The

control allocation techniques are of course easily applicable to an aircraft with more controls,

so long as control effectiveness data is available. The upper limit on the number of controls

is not restricted; however, the computational time necessary to perform the calculations

increases dramatically with each additional control. However, given the startling rate at

which computing power is increasing, it is hypothesized that the computational requirements

of performing the required calculations in a reasonable frame rate is not a large concern.

Timing issues are discussed in more detail in Chapter 8.


3.4 Control System Architecture

3.4.1 Control System Model

The choice of the control system structure is important when considering the type of control

allocation to be used in a given aircraft. Modern control systems to date tend to be complex

in that it is sometimes difficult to identify definitively individual control system components,

which can be delineated as the stick logic, control law, and control allocation components.

Every aircraft control system contains these elements, but frequently their boundaries are

obscure, a fact which should not be surprising since there are a multitude of considerations

present when designing and refining a control system design. Control system software un-

dergoes many developments and refinements in the early stages of development, and even

throughout the life of the aircraft software is often scheduled for periodic update. Also, since

flying qualities are a prime consideration, many different kinds of filters and other block di-

agram elements are often “tacked on” to the design to make an aircraft behave such that

it meets the given flying qualities specifications and other requirements. A key feature of

moment rate control allocation is its well-defined position in the proposed control system

structure. Just as it is desirable to design computer code which is modular, the same could

be said for control system design. Figure 3.2 shows the proposed modular control system

design.

sticklogic

control law

controlallocatorpilot

inputdesiredaircraftbehavior

desiredmoments,m

controlpositions,uδ

d

Figure 3.2: Modular control system structure.

Selection of stick logic and control law are totally independent of the control allocation

scheme. For purposes of control allocation testing in a real-time environment, however,

it is desirable to employ control system components which help make the overall control

system meet the goal of providing the maximum maneuvering capability of the aircraft in

some sense. Control allocation with rate limiting provides the maximum control-generated

moments possible given the appropriate command, so a conversion from pilot input to desired


moment is sought to allow the pilot to command maximum available moments when desired.

3.4.2 Stick Logic

In the proposed modular control system structure, the stick logic is defined as the portion

which interprets the pilot’s inputs (e.g. control stick, yoke, throttle, etc) and interprets

those inputs as commands for some desired aircraft behavior. Generally pilot inputs are

given in some normalized units (-1 to 1 or 0 to 100, for example) and can be interpreted

philosophically as portions of some maximum available capability, such as control-generated

moment in a particular axis. In the case of moment rate control allocation, the knowledge

of the aircraft’s maximum moment-generating capability (the AMS or more accurately the

delta-AMS) gives the required information needed to relate pilot stick inputs directly to the

desired control-generated moment in a particular axis. This information leads to a simple

and intuitive stick logic outlined below.

“Iron Bird” Stick Logic

This method of stick logic is so named because of its similarity to the way all aircraft used

to be controlled: by systems of cables and pulleys mechanically linking the pilot’s control

inceptors to each of the aircraft’s sets of control surfaces. Traditionally, aircraft had three sets

of control surfaces which each had a primary purpose—elevators for pitch control, ailerons

for roll control, and rudder for yaw control. Essentially, a pilot’s longitudinal input would

impart a pure pitching moment, a lateral input would impart primarily a rolling moment,

and a rudder pedal input would impart primarily a yawing moment. The effects of pilot

inputs are essentially the same in the so-called “iron-bird” stick logic, which means that

although in the brand of modern flight control system considered the control surfaces are

almost certainly not directly mechanically linked to the pilot’s command inceptors, inputs

have a similar effect on the aircraft’s performance to that of “iron-bird” aircraft.

This method of interpreting the pilot’s stick commands is illustrated in Figure 3.3. For

illustration a two-input, two-moment problem is examined, although it is noted that the


γ

P

md

Cm

Cl

δ(Φ)

2-d Moment Space

γ

δlong,%

δlat,%

δlong,max

δlong,min

δlat,min δlat,max

P

δlong

δlat

2-d 'Stick Space'

Figure 3.3: Stick logic implementation.


extension to the standard three-input, three moment problem is easily made. Considered

here in the top portion of the figure is the “stick space”, or the available control stick travel

in terms of longitudinal and lateral stick inputs. The pilot input vector δ occurs at an

angle γ with respect to the horizontal input axis, defining a desired ratio of longitudinal to

lateral input. This angle γ is taken to be the desired ratio of commanded moments. The

intersection of δ with the rectangle formed by the stick travel limits is denoted P. The

attainable moment subset Φ is shown in the lower portion of the figure. The intersection of

the desired moment vector with the AMS boundary ∂(Φ) is also denoted by P, indicating

a direct mapping of the stick space onto the moment space. This direct mapping illustrates

the key desirable feature of iron-bird stick logic: maximum pilot inputs produce moments

on the boundary of the AMS. The key implication of this feature is that the pilot is in no

way restricted by the control system logic in producing moments which are attainable by

the aircraft, e.g. full longitudinal stick deflection produces the maximum available pitching

moment during a given frame. The stick logic algorithm can be implemented as follows:

1. Interpret the pilot’s stick command as a ratio of desired moments.

2. Use direct global constrained control allocation to find the intersection of the desired

moment vector with the attainable moment subset. The resulting moment vector from

the origin in moment space to the AMS boundary is the maximum available moment

in that direction, denoted m∗.

3. Form a scaling factor s, where s is defined by

s = max(|δlat|, |δlong|, |δdir|) (3.1)

where δlat and δlong are defined in Figure 3.3 and δdir is the directional input, generally

produced by a set of rudder pedals.

4. Scale the maximum moment vector m∗ by s:

md = sm∗ (3.2)

The desired moment vector md can then be used as the input to the moment rate control

allocator.


3.4.3 Control Law

The control law portion of the control system is here defined as the link between the desired

capabilities the aircraft is commanded to obtain by the stick logic portion and the desired

moments needed as input to the control allocator. This definition is somewhat different from

the common usage of the term, in which the control law is often inclusive of certain elements

of the stick logic and/or control allocation elements as defined here. The distinction between

definitions is important since the control allocator and control law are, in the proposed

control system architecture, distinct and can be considered completely separately from each

other for design purposes.

A control system utilizing the iron-bird stick logic described above actually needs no control

law; the desired aircraft behavior is already in terms of desired moments, so in this case

the link is trivial. However, in general, a stick logic component may not output moments

directly, and a control law element is necessary for the translation. In these cases the

distinction between stick logic and control law elements is less obvious, but presumably this

distinction can be made. Candidate control law types which could fit well into the modular

structure are model-following control or dynamic inversion as discussed in [13] and [1].

3.4.4 Control allocator

The third piece of the modular control system structure is the control allocator. The allocator

takes the desired moment vector md and calculates the necessary (but not necessarily unique)

control positions needed to attain it. In general, the control allocation portion of the control

system need not account for control position and rate limits; in fact, other control allocators

do not make use of this information in the same way moment rate control allocation does.

For purposes of discussion, from here on the terms Control Allocator and Control Allocation

refer to the type of moment-rate control allocation previously described.

Chapter 4

Null-Space Saturation

An inevitable property of the moment-rate control algorithms is that controls are free to

migrate away from some median position after maneuvering even when rate and position

demands are lessened. An example of this phenomenon is presented in Figures 4.1 and 4.2.

The maneuver simulated begins from a quiescent state where moment demands and control

deflections are small, indicative of a near straight-and-level trimmed state. The maneuver is

initiated at about 0.5 seconds, at which time a moderately intense maneuver is commanded

in both lateral and longitudinal channels. The lateral command is a roll at approximately

half of maximum capability (commands of -1 and +1 would be maximum capability) for

about 1.5 seconds, followed by a return to zero command for a short period and then a

quick back-and-forth lateral command, terminating by t = 5 seconds. In the longitudinal

channel a short steady nose-up command is followed by a forward-and-back command, also

terminating by t = 1.5 seconds. The maneuver, although not representative of a well-defined

maneuver or task, was flown because it causes the controls to migrate far from their zero

positions, even after moment demands essentially return to zero.

As can be seen in Figure 4.2, each of the five allocated controls reconfigure themselves

quite rapidly during the maneuver, as would be expected of any control allocation scheme.

However, when demand returns to zero near t = 5 seconds, each of the controls remain far

from their original positions, seen most obviously in the movement of left elevator to about

-13 degrees from an initial position of 0 degrees, while the left aileron moves to about +22

25

Jeffrey Q. Leedy Chapter 4. Null Space Saturation 26

0 1 2 3 4 5 6 7 8 9 10-1

-0.5

0

0.5

1

Late

ral c

omm

and

LATCON

0 1 2 3 4 5 6 7 8 9 10-1

-0.5

0

0.5

1

time, sec

Long

itudi

nal c

omm

and

LONGCON

Figure 4.1: Control inputs which cause migration of control positions from their zero posi-tions after a maneuver.


0 1 2 3 4 5 6 7 8 9 10

-20

-15

-10

-5

0

5

10

Ele

vato

r, d

eg DHTLDHTR

0 1 2 3 4 5 6 7 8 9 10-30

-20

-10

0

10

20

30

time, sec

Aile

ron

and

rudd

er, d

eg

DAL DAR DRUD

Figure 4.2: Migration of control positions from their zero positions after a maneuver.


degrees from 0 degrees. These two controls, since they each contribute significantly to the

production of rolling moment, are producing moments counter to each other, but along with

the other three allocated controls still produce the desired moment. This result is expected

since there is no information being provided to the control system regarding a “good” or

“logical” set of control deflections which produce a desired result.

The fact that the controls can configure themselves in such an unusual way seems unset-

tling, since one would expect controls to work together in an expected manner to produce

desired moments. It is expected that control surfaces which produce moments in the same

axis (ailerons and elevators, for instance) should be allocated in directions which produce

moments with a like sign (i.e. left aileron moving up and left elevator moving up to produce

a left wing down moment). Even accounting for the fact that in such an allocation scheme

each control surface can be performing the dual task of contributing toward both rolling and

pitching moment, strange control configurations still arise.

The reason for the strangeness in allocated control positions from moment-rate control allo-

cation is twofold. For one, the algorithms operate in a frame-wise manner, with each change

in allocated controls being produced based only on the controls allocated in the previous

frame and without knowledge of what is a “good” global configuration. Second, the pres-

ence of control redundancy (evident since m > n) means that control configurations which

produce a given moment are not unique. The null space of B is every solution u to

Bu = 0 (4.1)

Solutions to the control allocation problem u1 and u2 can be linearly combined to form

another solution in the null space u⊥. The following relationships hold:

BGlobal(u2 − u1) = md −md = 0⇒ (4.2)

(u2 − u1) ∈ u⊥ (4.3)

This ability to combine solutions to form another control solution will be used later in

Chapter 5 when control restoring is discussed.


We speak of the null space of B loosely, referring to all control configurations u which produce

a given moment m but which is not necessarily the zero vector. The size of the null space is

in some sense the degree of freedom in which a control solution can be different from another

and still produce the desired moment. The null space is extended by two factors, the first of

which is the number of redundant controls and the second of which depends on how similar

the moments which are produced by given pairs of controls are. So in cases where m is

significantly greater than n, or the degree of control redundancy is great, there is significant

opportunity for the controls to configure themselves in an unconventional manner.

Although the control configuration chosen by moment-rate control allocation is not arbitrary,

the path which can be commanded of the local moment vector in a real-time simluation is

significantly different for different flights, rendering prediction of the particular control con-

figuration chosen by MRCA very difficult. With significant opportunity for control solutions

to travel far from a “good” solution in the null space of B , the possibility arises that controls

could travel into a corner near the limits of many controls in control space. This could result

in reduced control rate capability should a subsequent moment be commanded which de-

mands high control rates. Whereas a control solution which is not near global control limits

would be able to evolve while being restricted by only the specified rate limits, a control

solution “in a corner” could take sufficiently longer to evolve if it had to travel a long way

from one frame to the next. In this case there would be an additional rate limit imposed

on the controls due to the operation of the algorithms. Since other control solutions pre-

sumably exist which allow more immediate freedom for control movement, the performance

of moment rate control allocation in these cases is less than optimal. The implications of

this possible degradation in performance is dependent on how often this situation occurs

in real-time flight and how easily the algorithm returns the controls to positions which are

closer to zero.

We label this phenomenon in which control solutions migrate towards undesirable positions

null space saturation (NSS). Previously this condition had been termed windup , but this

carries negative connotations which are not necessary, since null space saturation is not

necessarily a crippling problem in terms of aircraft maneuverability. Predicting how often

NSS occurs in a real-time simulation is difficult, although it is assumed that since in non-

restored control allocation algorithms (restored algorithms are addressed in Chapter 5) there

is nothing used to keep the control positions “in check”, this situation is likely to arise.


An illustration of what is meant by null space saturation is given in Figures 4.3 and 4.4.

Shown in the figures is the simplified case of two moments generated by three control effectors.

Figure 4.3 shows the mapping of the global admissible control subset via BGlobal into moment

space. In control space, the available travel of each of the three control surfaces is shown

by a three-dimensional box. Because BGlobal is wide (having m = 3 and n = 2 rows),

the three dimensions of control space collapse into two dimensions in moment space when

controls and moments are related through BGlobal. In moment space, the attainable moment

subset appears as a rotated and dilated three-dimensional figure, although moment space

is actually only two-dimensional. In the moment space portion of the figure, each pair of

mapped control limits is labeled with the appropriate control. The boundary of the attainable

moment subset is composed of only those control limits which are mapped to the exterior

of the box in moment space, denoted by solid lines. On the boundary, control solutions are

unique, while on the interior there exist many control solutions for each point in moment

space. Therefore, there is a non-trivial null space existing perpendicular to the page, which

enables many different control solutions to occupy the same point in moment space.

In Figures 4.3 and 4.4, a null-space saturated case occurs when the desired moment md

is attained by a control configuration lying very close to the far corner, marked by the

intersection of the three interior lines inside the global AMS. This portion of the global AMS

is expanded at the top of Figure 4.4. Another control configuration producing the same md

but lying well away from any control position limits can be thought of. This configuration

would be far enough away from position limits so that the desired ∆md does not violate any

control position limits. An expanded view of this case is shown at the bottom of Figure 4.4.

It is easily seen that the two attainable moment subsets are not equal, and that for the NSS

case the ∆AMS is significantly smaller than for the non-saturated case. In fact, at this

global control configuration only 1/8 of the possible md directions are attainable in the NSS

case assuming umin = umax .

The unsettling possibility of NSS is serious only if it occurs often enough to hinder the

maneuvering performance of the aircraft significantly, so the question of whether or not

NSS “cripples” the aircraft for a time is important. The mere occurrence of NSS does not

itself necessarily render the aircraft crippled. Although moment-generating performance is

degraded when NSS is occurring, it is possible that this performance is not significantly less

than what is needed. In cases where the performance penalty is significant, a remedy is


control space

moment space

u1

u2

Cm

Cl

admissible control subset

m B uglobal=

md*md

u1

u2

u3

u3

Figure 4.3: Illustration of null space saturation. The desired moment md can be obtainedby an infinite number of control solutions, one of which occurs when the controls are all attheir position limits. Other solutions which are not null space-saturated are possible.


Null-Space Saturated Case (control solution in rear ÔcornerÕ of global AMS; Dmd not attainable)

Non-Saturated Case (control solution neither in ÔcornerÕ nor on near facet of global AMS; Dmd attainable )

Dmd (framewise)

u1

u2

u3

md (global)

Dmdmd (global)

|DAMSNSS| < |DAMSnon-saturated|

DAMSNSS

DAMSnon-saturated

Figure 4.4: Illustration of null space saturation. In the null-space saturated case, ∆md isnot attainable in the current frame since to do so would violate the u1 position limit. In thenon-saturated case, ∆md is attainable since the current global control solution is sufficientlyfar from global control position limits.


presented in the following chapter which restores control solutions to more desirable ones in

an attempt to keep control solutions away from their position limits.

Chapter 5

Control Restoring

As discussed in Chapter 4, moment-rate control allocation methods operating in their basic

mode allocate control positions which may produce the desired moment but do not appear

to be “logical” in at least an aesthetic sense. Due to the control redundancy which exists

when m > n, there exist infinitely many control configuration possiblities. Moment rate

control allocation by itself runs freely, producing control positions which are desirable from

the moment-generating standpoint, but which are unchecked relative to some global criterion

we would deem desirable. Control restoring methods are defined as algorithms which, after

moment demands have been met by the free-running control allocation algorithms, use any

additional available position and rate capability of the control effectors to restore the control

solution towards some desirable goal. It is possible to restore to a known or unknown

solution or criterion, and it is also possible to think of several different desirable restoring

objectives. A discussion of restoring algorithms which utilize a few of these criteria are

outlined and examined in terms of their effect on real-time performance of the moment-rate

control allocation algorithms.

The term desirable will be used to describe a global control configuration which, in addition to

producing the md requested by the pilot (through some stick logic and control law), satisfies

some other global criterion deemed desirable. This additional criterion can be either specified

in an attempt to satisfy some desirable characteristic completely separate from moment

generation or to indirectly aid in the generation of moments (control restoring to alleviate

34

Jeffrey Q. Leedy Chapter 5. Control Restoring 35

null space saturation, for instance).

Real-time control allocation without control restoring results in control positions specified

by

uk = u0 +

k∑i=1

∆ui (5.1)

where u0 is some initial (presumably desirable) global control configuration. Subsequent

frames allocate ∆ui ’s which do not attempt to make sure the progressing solution stays

desirable. Over time, it is possible for each solution to stray farther from desirable, forcing

the global solution into a region where null space saturation may occur. To account for this,

restoring methods in each frame first allocate controls without restoring, then allocate an

additional control vector ∆urest to be summed with the unrestored solution:

uk = uk−1 + ∆uk + ∆urest (5.2)

The following sections deal with selection of the restoring vector ∆urest.

5.1 Restoring to a Known Solution

Sometimes the desirable restoring criterion is easily described and the most desired solution

is known. As mentioned earlier, the first step is to allocate controls using moment rate

control allocation without restoring, then adding a vector ∆urest to move the solution to

a more desirable position. In general, BGlobal, which describes the global effectiveness at

a linearization point, is different from Bk , which describes the control effectiveness about

the current control solution. Therefore, any ∆urest must be calculated using Bk so that it

contributes to uk without affecting the moment produced by ∆uk . ∆urest can be calculated

if the desired solution is known simply as a scaling factor Cs times the difference between

the current control solution and the desired solution. The scaling factor is calculated as that

scalar which satisfies

∆uRest,k = (∆uk + Csu⊥k ) ∈ ω (5.3)


where ω is the more restrictive of the global position and rate limits for the current frame.

5.2 Restoring to an Unknown Solution

When a desired solution is not explicitly known, it is still possible to restore towards that

solution. This type of restoring can be accomplished through a minimization procedure.

The primary objectives ∆md are augmented by a parameter which describes the secondary

objective ∆yn+1. Control effectiveness in terms of ∆yn+1 must be known, and from this

information an augmented desired objective vector ∆yAug and control effectiveness matrix

BAug,k can be formed:

∆yAug =

∆m

∆yn+1

,BAug,k ≡

[Bk

∂yn+1/∂u

]uk

(5.4)

As before for restoring towards a known solution, the unrestored solution uunrest is calculated

first and augmented by a vector ∆urest. Then the augmented B matrix is used to calculate

∆u⊥k in equation 5.5:

BAug,k∆u⊥k =

∆yk = 0

Cs

(5.5)

The desired primary objective during this restoring calculation is set to zero so as not to

further change the moment attained. Cs is specified as a negative scalar which is calculated

such that the total frame-wise change in control solution falls within the allowable delta-AMS

ω. A negative value for Cs ensures restoring towards the minimum of yn+1.

5.3 Restoring Objectives

Any objective that can be formulated in terms of control effectiveness can be used for restor-

ing. The most obvious objective is perhaps the minimum-norm of the control vector. Other

possibly desirable objectives include minimum control-induced drag and minimum observ-


ability due to control surface positions. Drag information is relatively easy to obtain as it

is frequently included in aerodynamic databases. A reasonable description of the effect of

control positions on observability is unknown to the author, although such information may

exist currently or in the near future for certain candidate aircraft.

5.3.1 Minimum-Norm Restoring

Minimum-norm restoring is the simplest type of restoring to define, being that which drives

the controls towards the solution which has the minimum Euclidean 2-norm while still pro-

ducing the desired moment. This can be accomplished in at least two ways, one in which

the minimum norm solution is calculated directly, and another in which the minimum norm

solution is not known but is continually approached by the simple minimization procedure

described previously.

Minimum-Norm: Solution Known

The inverse which results in a control vector with the minimum Euclidean 2-norm is the

pseudoinverse. This inverse is the “known solution” desired, and it is defined by the following:

P = BT (BBT )−1 (5.6)

The procedure outlined in section 5.1 can be used when the pseudoinverse can be calculated.

The secondary criterion is taken to be 12uTu. The two valid control solutions used to form

a third (restored) solution as described in 4.2 are:

u1 = (uk−1 + ∆uk) found using Bk (5.7)

u2 = uPseudo,k = Pkyk found using Pk (5.8)

Forming the difference results in the restored solution urestored, which produces the same

moment as u1 and u2:

urestored = u1 − u2 = (uk−1 + ∆uk − uPseudo,k) (5.9)


This type of minimum-norm restoring is employed in the real-time simulation module re-

store u.

Minimum-Norm: Solution Unknown

When the pseudoinverse cannot be calculated, a second method of restoring towards the

minimum-norm solution can be employed. This method steps toward the unknown solution

in multiple steps rather than one step (if possible) as is the case for the above minimum-norm

restoring method. We wish to minimize 12uTu, so the ∂yn+1/∂u found in Eq. 5.4 is simply

uT . The minimum-norm augmented problem is therefore given by:[Bk

uT

]uk

∆u⊥k =

∆yk = 0

Cs

(5.10)

(5.11)

where the augmented B matrix on the LHS is (4 x m), ∆u⊥k is (m x 1), ∆yk is (3 x 1),

and Cs is a scalar. The control limits required to solve this problem are given by ∆u′min =

∆umin−∆uk and ∆u′max = ∆umax−∆uk , where ∆uk is the unrestored control solution for

the current frame. The value Cs in Eq. 5.10 is chosen negative with a magnitude calculated

so as to ensure that the restored solution urestored does not violate constraints.

An unfortunate result of this type of restoring is the tendency of the control solutions

to “chatter” about some minimum norm solution. This phenomenon occurs because the

minimum-norm solution is unknown, and the magnitude of the step taken toward the min-

imum in each frame can be too great, straddling the desired solution. This type of rapid

oscillation, if it occurs frequently, is undesirable from a structural fatigue standpoint, possibly

causing unneccessary wear on the actuators.


5.3.2 Minimum-Drag Restoring

A second type of restoring is minimum-drag restoring, which aids in alleviating unnecessary

control-induced drag, possibly slightly enhancing range and endurance. The mechanics are

similar to those for minimum-norm restoring when the solution is unknown. This type

of restoring requires knowledge of[∂CD

∂u

]k, which is used as the fourth row in BAug . The

augmented minimum-drag problem is given by[Bk

Bk,4

]uk

∆u⊥k =

∆yk = 0

Cs

(5.12)

In this case the scaling factor Cs is chosen to ensure admissibility as above for minimum-

norm.

5.3.3 Maximum-Norm Counter-Restoring

Maximum-norm counter-restoring is a useful method used to force control positions to move

away from the minimum-norm solution. Obviously, this has no practical value in real-life

flight, but in simulation can be used to investigate worst-case scenarios in terms of null-space

saturation. Verifying that maneuvering performance is not significantly degraded even when

maximum-norm counter-restoring is employed provides confidence that null-space saturation

will not “cripple” the aircraft at any time. The maximum-norm solution is not known, so the

algorithm for minimum-norm restoring presented in subsection 5.3.1 is used with a positive

Cs , forcing the control solution to maximize the Euclidean 2-norm.

Chapter 6

Control Surface Chattering

Previous batch testing of moment rate control allocation employing the control restoring

algorithms presented in Chapter 5 revealed the possibility that control surfaces sometimes

exhibited chattering . Chattering is defined here as the tendency for the rate of the control

solution to change sign rapidly without a corresponding rapid change in moment demands.

Chattering is undesirable because it places unnecessary physical demands on the control

actuators while giving essentially no positive return. Frequent or sustained periods of control

chattering could possibly lead to premature fatigue of the actuators, so it is of interest to

isolate the cause of chatter and present methods which help to alleviate it.

Chattering in general has many different causes which may or may not be easy to diagnose.

According to an industry rule of thumb (as related by one Lockheed Martin control engineer),

chattering is considered benign if the magnitude of the oscillations is smaller than about

1/500 of the total available travel of the particular control surface. Chattering characterized

by magnitudes greater than this criterion is considered undesirable.

When employing control restoring towards an unknown solution (see Section 5.2), chattering

can occur if the value of Cs is not chosen judiciously. Recall that in this type of restoring, after

allocating to a pre-restored control solution, the pseudoinverse of an augmented B matrix as

defined in Equation 5.4 is calculated. The factor Cs is used to control how fast the restoring

algorithms will cause the controls to move towards the unknown solution. For purposes

40

Jeffrey Q. Leedy Chapter 6. Control Surface Chattering 41

of illustration, we consider a particular type of restoring towards an unknown solution,

minimum-drag restoring. Early implementation of minimum-drag restoring indicated that

there are at least two reasons for not stepping directly to the pseudoinverse. The first

is important only for purposes of demonstration of minimum-drag restoring; it is desired

when comparing minimum-drag solution to non-restored solution time histories to be able

to observe the gradual departure of the two solutions. The second reason for reducing the

step towards the pseudoinverse solution is to help reduce chattering, which is important in

real-time flight.

Consider the simple real-time flight with pilot inputs given in Figure 6.1. The pilot stick

input limits are given as -1 to +1, where full stick deflection in a direction is interpreted as

a command for maximum available moment in that direction (see Subsection 3.4.2). Inputs

are representative of a moderate bank and turn to the left, making necessary adjustments

to return to level flight and to account for the relatively poor handling qualities afforded by

the direct stick logic-to-control allocator structure of the control system. To examine the

effect of the Cs parameter on the level of control surface chattering, four simulation runs are

compared, each having a different value of Cs . Resulting control time histories are given in

Figures 6.2, 6.3, and 6.4. Shaded sections of the plots indicate periods where at least one

control surface is rate-saturated. Control position limits are indicated by horizontal dashed

lines.

In each of the plots shown, evidence of restoring-induced chatter can be seen in elevator,

aileron, and rudder deflections. As the minimization parameter Cs increases, a larger step

is taken towards the minimum-drag solution given by the pseudoinverse of the augmented

B matrix. During periods of chatter, the control solution “straddles” the desired minimum

drag solution because the step taken is too large to arrive near the minimum of the drag

curve.


0 2 4 6 8 10 12 14 16 18 20−1

−0.5

0

0.5

1

Late

ral i

nput

, −1

to +

1

0 2 4 6 8 10 12 14 16 18 20−1

−0.5

0

0.5

1

Long

itudi

nal i

nput

, −1

to +

1

0 2 4 6 8 10 12 14 16 18 20−1

−0.5

0

0.5

1

Dire

ctio

nal i

nput

, −1

to +

1

time,sec

Figure 6.1: Pilot inputs for bank-and-turn task.


DH

TL,

deg

0 2 4 6 8 10 12 14 16 18 20−25

−20

−15

−10

−5

0

5

10

15

DH

TR

, deg

time, sec0 2 4 6 8 10 12 14 16 18 20

−25

−20

−15

−10

−5

0

5

10

15

no restoring

Cs = 0.1

Cs = 0.3

Cs = 0.5

Figure 6.2: Influence of minimum-drag restoring minimization parameter Cs on elevatordeflections for bank-and-turn task.


DA

L, d

eg

0 2 4 6 8 10 12 14 16 18 20−30

−20

−10

0

10

20

30

DA

R, d

eg

time, sec0 2 4 6 8 10 12 14 16 18 20

−30

−20

−10

0

10

20

30

no restoring

Cs = 0.1

Cs = 0.3

Cs = 0.5

Figure 6.3: Influence of minimum-drag restoring minimization parameter Cs on aileron de-flections for bank-and-turn task.


DR

UD

, deg

time, sec0 2 4 6 8 10 12 14 16 18 20

−30

−20

−10

0

10

20

30 no restoring

Cs = 0.1

Cs = 0.3

Cs = 0.5

Figure 6.4: Influence of minimum-drag restoring minimization parameter Cs on rudder de-flections for bank-and-turn task.


DH

TL,

deg

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2−4

−3

−2

−1

0

1

2

3

4

DH

TR

, deg

time, sec0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2

−4

−3

−2

−1

0

1

2

3

4

no restoring

Cs = 0.1

Cs = 0.3

Cs = 0.5

Figure 6.5: Influence of minimum-drag restoring minimization parameter Cs on elevatordeflections for bank-and-turn task. Chattering is evident in the Cs = 0.3 and Cs = 0.5 cases;reduction of Cs to 0.1 alleviates appreciable chatter.


An example of restoring-induced chattering is easily seen in Figure 6.5, which shows the

elevator deflections for each of the four cases from t = 0 to 2 seconds. For the unrestored

case there is no evidence of chattering. For the minimum-drag restoring cases, chattering

becomes more evident as the minimization factor Cs is increased, corresponding to a larger

step taken towards the minimum-norm solution. For Cs = 0.1, there appears to be no

appreciable chattering, which is a desirable result. The tradeoff for the reduced chattering,

however, is slower convergence to the minimum-drag solution. It is therefore seen that the

choice of the minimization factor Cs is important in finding a compromise between speed of

minimization and alleviation of chatter.

Control-induced chattering should not be confused with other types of chattering phenomena

which can appear regardless of the use of restoring. Situations arise in simulation in which

one or more control surfaces exhibit a type of chattering due to the direction of the desired

moment vector md being very close to the edge between two facets on the AMS. In such a

case, it is possible for very slight changes in pilot input (intentional or otherwise) to cause

the intersected facet to oscillate rapidly, thereby causing control deflections to oscillate as

well.

Chapter 7

Representative Maneuvers

Moment rate control allocation has been shown to produce any desired moment lying within

or on the boundary of the AMS; this result has been verified in batch simulation [3]. Batch

verification has been performed using canned moment inputs in all three moment axes includ-

ing the maneuver reproduced in Figure 7.1. This maneuver, although serving its intended

purpose by producing desired moments in all three axes simultaneously, is not necessarily

representative of a “real-world” maneuver. That is, canned inputs, by definition, are inputs

which are commanded without the pilot in-the-loop and therefore perhaps do not verify the

operation of the control allocation algorithms in the real-world sense that is desirable. The

next obvious step in the process of verifying the expected performance of the algorithms and

investigating possible problems in certain flight regimes is to perform real-time simulation

using actual pilot-in-the-loop inputs. Examined here are three maneuvering tasks which

require the pilot to constantly respond to events occurring before him: 1) an aggressive

combat maneuvering task, 2) a formation flying task, and 3) an artificially induced PIO-like

maneuver.

For each of the three maneuvers simulated, four separate cases are run, distinguished by

the type of control restoring employed. Maneuvers are run using 1) no control restoring,

2) minimum-norm restoring (as presented in Subsection 5.3.1), 3) minimum-drag restoring

(Subsection 5.3.2), and 4) maximum-norm counter-restoring (Subsection 5.3.3). For each

maneuver, a baseline case was flown using real-time pilot inputs. This set of inputs was

48

Jeffrey Q. Leedy Chapter 7. Representative Maneuvers 49

recorded and used to fly each of the other three cases so that performance comparisons

could be made. Restoring should have minimal effect on maneuvering performance unless

control position and/or rate limits are exceeded for one or more cases, in which case moments

produced using each type of restoring can become different.


Figure 7.1: Multi-axis maneuver used in batch control allocation testing. Source: Imple-mentation of Constrained Control Allocation Techniques Using an Aerodynamic Model of anF-15 Aircraft (Bolling, 1997).


7.1 Aggressive Combat Maneuvering

Aggressive combat maneuvering for the purpose of maintaining an offensive position against

a foe, requires the pilot to make frequent and significant control input adjustments, especially

when an enemy pilot is aware of the aggressor’s presence. Therefore, it is a control-intensive

task, both in terms of the frequency and magnitude of changes in control deflection and also

in terms of control rates. For this reason this type of maneuver is selected as a test case

which is likely to tax the control allocation algorithms and possibly reveal potential concerns

with respect to the maneuvering capability available to the pilot.

Simulation of an aggressive combat maneuvering task is simple given the recording capabil-

ities of the real-time simulation developed here. A recording of the trajectory (x-, y-, and

z-position variables) and Euler angles (φ, θ, and ψ) of the enemy aircraft are the only pieces

of information required. First the simulation is run real-time with the pilot apparently aware

of the presence of the aggressor, resulting in a flight which is difficult for another aircraft

to track given no foreknowledge of the aircraft’s maneuvers. In reality, the pilot has no

knowledge of the aggressor’s position but is maneuvering as if to avoid being caught in the

gunsight of the aggressor. This initial flight is recorded to a data file which is then used

as input to the second simulation run, in which the pilot is now attempting to maintain

an offensive position behind the aggressively maneuvering recorded target. For this case,

maintaining an offensive position against the target meant keeping the recorded aircraft in

the pilot’s forward field of view defined by a 20 degree cone emanating from the pilot’s

eye parallel to the x-body axis. All pertinent moment and control data is recorded and is

presented in Figures 7.2, 7.3, 7.4, 7.5, and 7.6. Time histories of velocity, angle-of-attack,

sideslip, Euler angles, and position variables are given in Appendix A. Shaded areas on the

control surface position plots indicate periods in which at least one control surface is rate

limited. Physical control surface position limits are indicated by dashed horizontal lines on

each plot. Four simulation runs are made using identical pilot input time histories, one for

each type of restoring employed (no restoring, min-norm restoring, min-drag restoring, and

max-norm counter-restoring).


0 1 2 3 4 5 6 7 8 9 10−1

−0.5

0

0.5

1

Late

ral i

nput

, −1

to +

1

0 1 2 3 4 5 6 7 8 9 10−1

−0.5

0

0.5

1

Long

itudi

nal i

nput

, −1

to +

1

0 1 2 3 4 5 6 7 8 9 10−1

−0.5

0

0.5

1

Dire

ctio

nal i

nput

, −1

to +

1

time,sec

Figure 7.2: Pilot inputs for aggressive combat maneuvering task.


DH

TL,

deg

0 1 2 3 4 5 6 7 8 9 10−25

−20

−15

−10

−5

0

5

10

15

DH

TR

, deg

time, sec0 1 2 3 4 5 6 7 8 9 10

−25

−20

−15

−10

−5

0

5

10

15

no restoring

min−norm

min−drag

max−norm

Figure 7.3: Elevator positions for aggressive combat maneuvering task.


DA

L, d

eg

0 1 2 3 4 5 6 7 8 9 10−30

−20

−10

0

10

20

30

DA

R, d

eg

time, sec0 1 2 3 4 5 6 7 8 9 10

−30

−20

−10

0

10

20

30

no restoring

min−norm

min−drag

max−norm

Figure 7.4: Aileron positions for aggressive combat maneuvering task.


DR

UD

, deg

time, sec0 1 2 3 4 5 6 7 8 9 10

−30

−20

−10

0

10

20

30

no restoringmin−norm min−drag max−norm

Figure 7.5: Combined rudder positions for aggressive combat maneuvering task.


0 1 2 3 4 5 6 7 8 9 10−0.2

−0.15

−0.1

−0.05

0

0.05

0.1

0.15

0.2

Cl

0 1 2 3 4 5 6 7 8 9 10−0.2

−0.15

−0.1

−0.05

0

0.05

0.1

0.15

0.2

Cm

0 1 2 3 4 5 6 7 8 9 10−0.2

−0.15

−0.1

−0.05

0

0.05

0.1

0.15

0.2

Cn

time, sec

no restoring

min norm

min drag

max norm

Figure 7.6: Moment time histories for aggressive combat maneuvering task.


Pilot inputs for this task were moderate-to-heavy, with two short periods in which maxi-

mum pitching moment was commanded. Directional commands were zero throughout. It

is important to note that the flying qualities of the aircraft without a control law (recalling

the direct stick logic-to-control allocator structure mentioned in Chapter 3) are not good

by any standard. As mentioned earlier, real aircraft would implement some type of control

law to ensure that handling qualities are acceptable according to military specifications. In

the simulation, it was very difficult to maintain the offensive position desired; therefore, the

pilot inputs given here are most likely artificially more intense than they would be on a real

aircraft. Since the inputs are characteristic of the type of inputs indicative of aggressive com-

bat maneuvering, this flight will be examined to determine if problems and issues described

earlier can be observed.

It is seen from Figures 7.3- 7.5 that there are several short periods in which one or more

control surfaces are rate limited. During these periods, there is no additional rate capability

available which can be used for control restoring. This is indicated by the parallel control

position traces of the four cases. When rate saturation is occurring, there is no ability for

the control solution to be restored within the null space. Outside of these periods, the four

traces are not restricted in such a way because the null space allows a certain range of control

movement which does not affect the moments produced.

Because different restoring methods in general produce different control positions for the

same input at a given time, some controls migrate closer toward their limits for certain

types of restoring than for others. This migration results in slightly different periods of rate

saturation between the four cases. The shaded areas overlaid on the control position plots

are the periods of rate saturation for the non-restoring case. Periods of rate saturation are

very similar, although not exactly the same, for each of the other three cases.

Figure 7.7 shows the Euclidean 2-norm of the control vector for each of the four restoring

cases. The max-norm restoring case tends to produce the largest control deflections, as is ex-

pected. Similarly, the min-norm restoring solution tends to produce a smaller control vector

norm. The minimum-drag solution and the non-restored solutions usually fall somewhere

in between. It should be noted that the solution employing maximum-norm restoring does

not always produce the largest norm of the four cases, nor does the minimum-norm solution

always produce the smallest. This result is possible since each of the four control solutions


evolves independently, and at any instant the framewise control movement capabilities for

each of the four cases is different. Also, since the max-norm and min-drag restoring methods

are classified as “unknown solution” methods, the control solutions for these methods are

in general not at the absolute maximum norm or minimum drag positions since each only

approaches the desired criterion instead of stepping directly to a known desired criterion.

Control surface chattering does not appear to be significant for this case, suggesting that an

appropriate (sufficiently small) selection of Cs has been made with regard to chattering.

Figure 7.6 shows the actual moments attained during the maneuvering task. For the first

two seconds of the flight, attained moments are essentially equal for all four cases, an ex-

pected result since moment demands during this period are small, and movement of control

solutions from the no-restoring case is done in the null-space of the control effectiveness ma-

trix B . Evidence of null-space saturation is not evident during this maneuver. Performance

differences appear most significantly in the 4 to 6 second range for the max-norm counter-

restoring case, and to a lesser extent for the other two restoring methods. During this period

the moments attained are somewhat different, but it is difficult to determine whether or not

the difference in performance is significant or undesirable at all. Interestingly, from t = 5.0 to

5.5 seconds, the max-norm solution is the only solution to attain the correct direction of the

desired moment, which is counterintuitive since the max-norm solution is intended to provide

a worst-case situation in which moment-generating performance penalties are greatest.


0 1 2 3 4 5 6 7 8 9 100

5

10

15

20

25

30

35

40

time, sec

Euc

lidea

n 2−

norm

of c

ontr

ol v

ecto

r, d

eg

no restoring

min−norm

min−drag

max−norm

Figure 7.7: Control vector 2-norm time histories for aggressive combat maneuvering task.


7.2 Formation Flying

A formation flying task is also selected as a test case since it requires frequent pilot control

adjustments and is therefore deemed to be possibly taxing to the algorithms. Instead of

being characterized by moderate-to-large amplitude pilot inputs, a formation flying task

requires smaller but more rapidly changing inputs which change sign more often. Presented

in Figures 7.8- 7.12 are time histories of a ten-second simulation representative of a formation

flying task. Time histories of other states are given in Appendix A. In this case the pilot

attempts to fly directly behind an aircraft that is making only small deviations from straight-

and-level flight.

The shaded vertical bars in Figures 7.9- 7.11 indicate several very short periods during which

rate saturation occurs. During the longest of these, from t=8.15 to 8.30, control surface

solution traces are similar as for the aggressive combat maneuvering case, again indicating

that during these periods no excess control rate capability is available for restoring towards

a desirable solution.

Figure 7.10 shows the aileron positions approaching very closely their position limits for the

max-norm case. It is in this region where null-space saturation is possible and moment-

generating performance could be compromised. Examination of Figure 7.12 shows that this

may in fact contribute to a small difference in moment-generating performance relative to the

unrestored case. From t = 0.0 to about 6.5 seconds, pitching, rolling, and yawing moments

are essentially equal for the four cases. During this period pilot inputs are relatively small

and control surface positions do not approach their limits very closely. Thereafter, aileron

positions for the max-norm case do approach their limits, and the result is perhaps a slightly

degraded moment-generating capability. Overall, though, differences in actual moments

produced over the ten-second run are small, indicating that null-space saturation does not

have excessive adverse effects on moment-generating capability in this case.


0 1 2 3 4 5 6 7 8 9 10−1

−0.5

0

0.5

1

Late

ral i

nput

, −1

to +

1

0 1 2 3 4 5 6 7 8 9 10−1

−0.5

0

0.5

1

Long

itudi

nal i

nput

, −1

to +

1

0 1 2 3 4 5 6 7 8 9 10−1

−0.5

0

0.5

1

Dire

ctio

nal i

nput

, −1

to +

1

time,sec

Figure 7.8: Pilot inputs for formation flying task.


DH

TL,

deg

0 1 2 3 4 5 6 7 8 9 10−25

−20

−15

−10

−5

0

5

10

15

DH

TR

, deg

time, sec0 1 2 3 4 5 6 7 8 9 10

−25

−20

−15

−10

−5

0

5

10

15

no restoring

min−norm

min−drag

max−norm

Figure 7.9: Elevator positions for formation flying task.


DA

L, d

eg

0 1 2 3 4 5 6 7 8 9 10−30

−20

−10

0

10

20

30

DA

R, d

eg

time, sec0 1 2 3 4 5 6 7 8 9 10

−30

−20

−10

0

10

20

30

no restoring

min−norm

min−drag

max−norm

Figure 7.10: Aileron positions for formation flying task.


DR

UD

, deg

time, sec0 1 2 3 4 5 6 7 8 9 10

−30

−20

−10

0

10

20

30


Figure 7.11: Combined rudder positions for formation flying task.


0 1 2 3 4 5 6 7 8 9 10−0.2

−0.15

−0.1

−0.05

0

0.05

0.1

0.15

0.2

Cl

0 1 2 3 4 5 6 7 8 9 10−0.2

−0.15

−0.1

−0.05

0

0.05

0.1

0.15

0.2

Cm

0 1 2 3 4 5 6 7 8 9 10−0.2

−0.15

−0.1

−0.05

0

0.05

0.1

0.15

0.2

Cn

time, sec

no restoring

min norm

min drag

max norm

Figure 7.12: Control-generated moments for formation flying task.


7.3 PIO-like Maneuver

Pilot-induced oscillations (PIOs) are a significant concern in the modern era of aircraft

control. Research into accidents in which pilot-induced oscillations have been observed cite

actuator rate limiting as a primary contributor. An artificially-generated PIO-like maneuver

is presented here as a test case since actuator rate limiting is significant and it is of interest

to determine the behavior of the control restoring algorithms presented in the transition

from non-saturated to saturated periods of flight. In this maneuver, the pilot’s lateral inputs

and the aircraft response are out-of-phase by approximately 180 degrees, so in this sense it

exhibits certain characteristics found also in PIO’s.

Figure 7.13 shows the pilot input time histories for this simulated lateral PIO maneuver.

Lateral input magnitudes are very large and change sign several times. Longitudinal inputs

are essentially zero except when necessary to attempt to keep the aircraft’s nose pointed

at the horizon, and directional inputs are zero. Figures 7.14- 7.16 show the control surface

position time histories. Shaded areas denote periods of rate saturation, and horizontal

dashed lines again designate control position limits. Other state information is presented

in Appendix A. For the first two seconds of the simulated maneuver, moment demands

are relatively small, leaving a significant portion of the control rate capability available to

perform restoring. This result is confirmed by the rapid separation of control position traces

between cases over this period. At 2.2 seconds the max-norm left horizontal tail solution has

migrated up against its positive position limit. Shortly thereafter, pilot inputs cause rate

saturation to occur and for most of the following 6 seconds one or more control surfaces are

rate limited. During the remaining period from about t = 9 to 10 seconds, rate saturation

is not occurring and the control position traces diverge again.

A function of rate limiting appears to be the tendency of control surface traces to come

together, even after periods in which they are allowed to diverge from each other. This

is not surprising since during these periods solutions appear similar because there is no

restoring capability which could differentiate the slopes of the position traces. During rate

saturation, rates of all four methods are the same, so position traces are parallel. Since there

are slight differences in the periods during which rate saturation occurs between the four

cases, traces are not always parallel within the shaded areas. As before for the aggressive


combat maneuvering task, the shaded area shows periods in which rate saturation occurs in

the unrestored case.

A more interesting result is seen during the periods of rate saturation. For much of the period

during which saturation occurs, the four traces are nearly coincident. For instance, during

the period near 5.9 seconds, the control time histories of all four restoring methods become

coincident. Upon comparing the maximum attainable moment in the desired direction and

the actual moment produced (Figure 7.18), since a full lateral command is given it appears

that all four solutions have converged at some point at the boundary of the global AMS. At

this global boundary, solutions are unique, so after these solutions converge at the boundary

solutions are coincident for the duration of the rate-saturated period.

Figure 7.17 shows the actual moments attained for each case. In all three axes, differences in

moments produced are very slight, except for the period from t = 2.4 to 3.0 seconds, where

the min-norm solution deviates from the other three traces. After the onset of rate saturation

at just before t = 2 seconds, the moment traces come together and remain essentially so for

the remainder of the flight.


0 1 2 3 4 5 6 7 8 9 10−1

−0.5

0

0.5

1

Late

ral i

nput

, −1

to +

1

0 1 2 3 4 5 6 7 8 9 10−1

−0.5

0

0.5

1

Long

itudi

nal i

nput

, −1

to +

1

0 1 2 3 4 5 6 7 8 9 10−1

−0.5

0

0.5

1

Dire

ctio

nal i

nput

, −1

to +

1

time,sec

Figure 7.13: Pilot inputs for a PIO-like maneuver.


DH

TL,

deg

0 1 2 3 4 5 6 7 8 9 10−25

−20

−15

−10

−5

0

5

10

15

DH

TR

, deg

time, sec0 1 2 3 4 5 6 7 8 9 10

−25

−20

−15

−10

−5

0

5

10

15

no restoring

min−norm

min−drag

max−norm

Figure 7.14: Elevator positions for a PIO-like maneuver.


DA

L, d

eg

0 1 2 3 4 5 6 7 8 9 10−30

−20

−10

0

10

20

30

DA

R, d

eg

time, sec0 1 2 3 4 5 6 7 8 9 10

−30

−20

−10

0

10

20

30

no restoring

min−norm

min−drag

max−norm

Figure 7.15: Aileron positions for a PIO-like maneuver.


DR

UD

, deg

time, sec0 1 2 3 4 5 6 7 8 9 10

−30

−20

−10

0

10

20

30


Figure 7.16: Combined rudder positions for a PIO-like maneuver.


0 1 2 3 4 5 6 7 8 9 10−0.2

−0.15

−0.1

−0.05

0

0.05

0.1

0.15

0.2

Cl

0 1 2 3 4 5 6 7 8 9 10−0.2

−0.15

−0.1

−0.05

0

0.05

0.1

0.15

0.2

Cm

0 1 2 3 4 5 6 7 8 9 10−0.2

−0.15

−0.1

−0.05

0

0.05

0.1

0.15

0.2

Cn

time, sec

no restoring

min norm

min drag

max norm

Figure 7.17: Control-generated moments for a PIO-like maneuver.


0 1 2 3 4 5 6 7 8 9 10−1

−0.8

−0.6

−0.4

−0.2

0

0.2

0.4

0.6

0.8

1

time, sec

moment produced maximum moment moment command (nd)

Figure 7.18: Comparison of maximum, produced, and commanded moments in the lateraldirection for a PIO-like maneuver.

Chapter 8

Timing Performance

8.1 Computational Intensiveness

It is of interest when implementing computer code in a real-time application to determine, in

some sense, the computational intensiveness of the set of instructions comprising the piece

of code. There are several possiblities for calculating this somewhat vague metric, each

of which has its advantages and disadvantages. The basic problem with performing such

a computation is that there exist a multitude of computing platforms, each of which are

dependent on the speed of the processor(s), the amount of physical and virtual memory

available, and load determined by such non-deterministic and uncontrollable factors such

as the intensiveness of processes initiated by other users on a multi-user system and of

those performed periodically by the processor(s) regardless of how many users are taking up

computing resources. On most systems, code compilers have the ability to perform multiple

levels of optimization if so desired by the programmer, adding another dimension of difficulty

in determining the speed of the simulation.

In the simulation described here, other factors in addition to those already mentioned affect

its performance in terms of speed. Apart from the simulation shell, data input and output

routines, and other portions of the simulation which could be considered overhead, the nature

of the control allocation algorithms themselves is such that the amount of computations

74

Jeffrey Q. Leedy Chapter 8. Timing Performance 75

performed varies considerably depending on a number of factors. Some of these are outlined

below.

8.1.1 Sources of Variation in Algorithm Performance

The moment rate control allocation algorithms outlined are somewhat unusual in the sense

that, compared to other allocation methods used in practice and presented in literature, the

amount of computations performed in a given frame depend significantly on a number of

factors not easily controlled in flight. One significant source of variation is the brute-force

method of searching for the facet intersected by the projection of the desired moment vector

(see Bolling [3]).

This facet search solves the geometrical problem of determining the intersection of the desired

moment vector md with the boundary of the attainable moment subset. This search is

conducted once in a global sense for the iron-bird stick logic described here and in a local

sense for performing control allocation. In a global sense, the facet search is conducted by

taking the md (measured from the origin in moment space) and generating in a given order

facets formed in moment space by the mapping via B of a control configuration having all

but 2 of its controls at one of their position constraints. In a local sense, the facet search

looks for the intersection of the frame-wise desired moment vector ∆md with the mapping of

the control configuration having all but 2 of its controls at one of their rate limits. The facet

search algorithm generates these facets as it is searching, terminating the search when the

appropriate facet is found. The maximum number of facets which could need to be searched

is n(n − 1), so as the number of controls present on the aircraft increase, the time required

to perform this search could increase significantly.

Once the algorithm has found the first such facet, for the frame following there is difficulty

in determining the next facet which is likely to be intersected by the new desired moment

vector. In the current implementation the most obvious choice, the intersected facet found

in the previous frame, is searched first. If this same facet no longer intersects the desired

moment vector, the algorithm performs a brute-force search for the new facet, with the order

of the search completely arbitrary. A more intelligent implementation would recognize the


probability that the adjacent facets are then the most likely to intersect the desired moment

vector, perhaps then followed with a cascading search for adjacent facets to the first set of

adjacent facets, and so on in a cascading fashion. At present such an algorithm has not been

developed.

Perhaps the only purely direct method for determining the computational intensiveness of a

set of algorithms is to perform a calculation of the number of floating point operations (flops)

performed in a given simulation frame, similar to the MATLAB command flops. Barring

a similar utility for a simulation composed of FORTRAN and C code, timing performance

may be evaluated in terms of statistical measures based on many simulation runs on a given

platform. This method is by no means precise, but gives a reasonable estimation for the

level of computing power required to run the algorithms in an actual flight control computer.

Should the level of computing power deemed reasonable to run the complete set of control

system algorithms not be feasible, the control allocation algorithms could simply be run at

a slower frame rate or spread across multiple processors.

8.2 Timing Performance Results

Without more specific timing performance goals at present, some preliminary timing statis-

tics from real-time implementation on the desktop simulation will be presented. Using the

simulation hardware previously described, various types of flights were run real-time to gen-

erate some statistical measures of computational intensiveness of the control system and

more specifically the control allocation portion of code. The system clock is called once per

simulation frame, resulting in a real total simulation time step ∆tTOTAL. This total time

step is broken down as follows:

∆tTOTAL = ∆tCA + ∆tSL + ∆tEOM + ∆tOTHER (8.1)

where

• ∆tCA is the time spent strictly allocating controls

• ∆tSL is the time spent performing stick logic (includes facet search)


• ∆tEOM is the time spent calling and integrating the aircraft equations of motion

• ∆tOTHER is the remainder of the total time not explicitly accounted for

In a simulation, equations of motion x = f(x,u) must be integrated and solved, whereas in

actual flight this is done naturally without computation, so ∆tEOM does not cut into the

timing budget. The ∆tOTHER is assumed negligible since it accounts for only small amounts

of time taken up by the actual calls to the system clock and other overhead not really

attributable to the control allocation, including the code which calculates the time statistics

itself. Recall that in this implementation no control law is used, so in other implementations

a ∆tCL, the time spent performing control law functions, would also be present in Eq. 8.1.

Therefore, the measures of most interest here are ∆tCA and ∆tSL.

It is difficult to determine an absolute worst-case scenario in which the previously described

facet search always searches through a large number of candidate facets, so several different

types of flights were investigated. Presented in Figure 8.1 is a sixty-second flight with mod-

erate and varied pilot inputs. The timing statistics presented are averages of timing statistics

from 40 runs of the same flight. The variation between runs originates from variations in

processor load (including those induced from processes belonging to other users and other

unrelated system tasks) which are considered quasi-stochastic. This averaging results in

timing estimates which are slightly higher than actual because they include these variations.

Figure 8.1 shows the ∆tCA portion of the total time needed to perform the control system

calculations. This measure is perhaps not the best for evaluating the performance of a

control system employing the stick logic described earlier, since the stick logic portion takes

up approximately the same amount of time as does the control allocator. A measure of the

sum of ∆tCA and ∆tSL would be considered a worst-case stick logic performance, although

it is likely that this logic would be replaced by a less computationally-intensive method on

a real aircraft. For less computationally-intensive stick logic, ∆tCA is the better estimate.

In the worst-case, the average amount of frame time required is about 0.0063 seconds (158

Hz), while the most intensive searches took less than .008 seconds (125 Hz).

Neglecting the amount of time required to perform the given stick logic, we see in Figure 8.1

that the simulation requires between .0027 and .0044 seconds (227 to 370 Hz) to perform


0 10 20 30 40 50 600

1

2

3

4

5

6x 10

−3

time, sec

∆ t C

A, s

ec

∆ tMEAN

=0.0031 sec

∆ tMAX

=0.0044 sec

∆ tMIN

=0.0027 sec

∆ tCA

Figure 8.1: Time history of timing statistics averaged over 40 identical simulation runs.


control allocation. Using less sophisticated stick logic is certainly possible, and affords a

significant time savings. In addition to developing a more intelligent facet-searching strategy,

one way of alleviating the time burden caused by control allocation calculations include

allocating at a lower frame rate than the rest of the calculations performed by the flight

control computer.

These figures are of course platform-dependent, so a realistic estimate of computing power

in near-future flight control computers is needed to determine if this level of performance is

acceptable.

Chapter 9

Conclusions

Moment-rate control allocation algorithms previously developed which attain essentially the

entire set of moments attainable by any control allocation scheme were implemented in a real-

time simulation for the first time. Several issues which were left unresolved during previous

batch simulation testing were addressed, including the phenomenon of null-space saturation,

control surface chattering, and timing performance of a simulation employing these moment

rate control allocation algorithms. Moment rate control allocation algorithms have been

shown to perform similarly in real-time testing as was observed in batch simulation. No

significant new problems or issues were found which were not observed in batch simulation.

Some example maneuvers representative of real-life flight which tax the algorithms’ ability

to perform as intended are presented. An aggressive combat maneuvering task, a formation

flying task, and a PIO-like maneuver are all flown to test the performance of the algorithms

in situations where control position and rate saturation is likely to occur, as it was predicted

that such situations could present problems in terms of their ability to generate desired

moments. Performance of each of these maneuvers is evaluated in terms of the primary issues

of concern left over after batch testing. For the formation flying and PIO-like maneuvers,

there is little difference in the moment time histories generated, indicating that performance

is acceptable regardless of the restoring method employed. Results are more inconclusive for

the aggressive combat maneuvering task, in which the moment time histories are observed

to be significantly different during some periods, although it is difficult to determine which

80

Jeffrey Q. Leedy Chapter 9. Conclusions 81

method would be deemed worst at generating moments.

In regards to the issue of null-space saturation, it is surmised that, although it is true that

this phenomenon can and does occur in real-time flight, it is not crippling to the aircraft’s

ability to perform maneuvers. A certain level of maneuvering performance degradation is

acceptable, and for cases where it is not, several candidate restoring algorithms can be

employed to reduce the possibility that such a situation should occur.

Control surface chattering, a phenomenon first revealed in batch testing, is seen as well in

real-time simulation. When utilizing types of restoring which restore towards an unknown

solution, an appropriately small choice the minimization factor Cs is important in alleviating

chattering.

The timing performance of the algorithms is examined statistically, although it is recognized

that more precise measures are desired to quantify the ability of the algorithms to execute

in a given ∆t . Difficulty in quantifying the amount of computing power available in the

next generation of fighter aircraft for control system calculations adds uncertainty to the

statement that the algorithms are able to be performed “fast enough”. However, regardless

of the speed of these computers, moment-rate control allocation can be performed at a frame

rate slower than that of other calculations, introducing only a small penalty in maneuvering

capability.

Future work in implementing moment rate control allocation algorithms in real aircraft

will possibly include the more precise quantification of timing performance requirements,

the reduction of time necessary to perform the algorithms (through more intelligent facet

search algorithms, for example), and the modification of the simple stick logic presented

here. Integration of the stick logic, control law, and control allocation portions of the control

system architecture will be important, as flying qualities specifications have not considered

in this research to date.

Bibliography

[1] Adams, R.J., Buffington, J.M., and Banda, S.S., “Design of Nonlinear Control Laws

for High Angle-of-Attack Flight”, AIAA Journal of Guidance, Dynamics, and Control,

Volume 17, Number 4, July-Aug 1994.

[2] Bodson, Marc and Pohlchuck, William A., ”Command Limiting in Reconfigurable Flight

Control”, AIAA Guidance, Navigation, and Control Conference, New Orleans, LA, Aug.

11-13, 1997.

[3] Bolling, J., Implementation of Constrained Control Allocation Techniques Using an

Aerodynamic Model of an F-15 Aircraft, Masters Thesis, Virginia Polytechnic Institute

and State University, Blacksburg, VA, 1997.

[4] Bordignon, K. A., Constrained Control Allocation for Systems with Redundant Con-

trol Effectors, PhD Dissertation, Virginia Polytechnic Institute and State University,

Blacksburg, VA, 1997.

[5] Bordignon, K., and Durham, W., ”Closed-Form Solutions to the Constrained Control

Allocation Problem”, AIAA Journal of Guidance, Control, and Dynamics, Volume 18,

Number 5, September-October 1995.

[6] Durham, W., ”Attainable Moments for the Constrained Control Allocation Problem”,

AIAA Journal of Guidance, Control, and Dynamics, Volume 17, Number 6, 1994.

[7] Durham, W., ”Constrained Control Allocation”, AIAA Journal of Guidance, Control,

and Dynamics, Volume 16, Number 4, July-August 1993.

[8] Durham, W., ”Constrained Control Allocation: Direct Method of Solution”, AIAA

Guidance, Navigation, and Control Conference, Hilton Head, South Carolina, August,

1992.

82

Jeffrey Q. Leedy Chapter 9. Conclusions 83

[9] Durham, W., ”Constrained Control Allocation: Three Moment Problem”, AIAA Jour-

nal of Guidance, Control, and Dynamics, Volume 17, Number 2, 1994.

[10] Durham, W., ”Control Stick Logic in High Angle-of-Attack Maneuvering”, AIAA Jour-

nal of Guidance, Control, and Dynamics, Volume 18, Number 5, September-October

1995.

[11] Durham, W. and Bordignon, K., “Multiple Control Effector Rate Limiting”, AIAA

Journal of Guidance, Control, and Dynamics, Volume 19, Number 1, January-February

1996.

[12] Durham, W., Bolling, J., and Bordignon, K., “Minimum Drag Control Allocation”,

AIAA Journal of Guidance, Control, and Dynamics, Volume 20, Number 1, January-

February 1997.

[13] Durham, W.C., Lutze, F.H., Barlas, M.R., and Munro, B.C., “Nonlinear Model-

Following Control Application to Airplane Control”, AIAA Journal of Guidance, Dy-

namics, and Control, Volume 17, Number 3, May-June 1994.

[14] Stevens, B. L. and Lewis, F. L., Aircraft Control and Simulation , John Wiley and Sons,

Inc., New York, 1992.

Appendix A

State Variable Time Histories for

Representative Maneuvers

This appendix contains state variable time histories for the representative maneuvers de-

scribed in Chapter 7.

A.1 Aggressive Combat Maneuver

Figures A.1 through A.3 show the state variable time histories for the sample aggressive

combat maneuvering task.

84

Jeffrey Q. Leedy Appendix A. State Variable Time Histories 85

0 1 2 3 4 5 6 7 8 9 10380

390

400

410

420

430

440

450

460

VT, f

ps

0 1 2 3 4 5 6 7 8 9 10−5

0

5

10

15

20

25

α, d

eg

0 1 2 3 4 5 6 7 8 9 10−20

−10

0

10

20

30

β, d

eg

time, sec

no restoring

min−norm

min−drag

max−norm

Figure A.1: Time histories of VT , α, and β for aggressive combat maneuvering task.


0 1 2 3 4 5 6 7 8 9 10−100

−50

0

50

100

150

200

φ, d

eg

0 1 2 3 4 5 6 7 8 9 10−15

−10

−5

0

5

10

15

20

25

θ, d

eg

0 1 2 3 4 5 6 7 8 9 10−70

−60

−50

−40

−30

−20

−10

0

10

ψ, d

eg

time, sec

no restoring

min−norm

min−drag

max−norm

Figure A.2: Time histories of φ, theta, and ψ for aggressive combat maneuvering task.


0 1 2 3 4 5 6 7 8 9 100

500

1000

1500

2000

2500

3000

3500

4000

Nor

th, f

t

0 1 2 3 4 5 6 7 8 9 10−1400

−1200

−1000

−800

−600

−400

−200

0

200

Eas

t, ft

0 1 2 3 4 5 6 7 8 9 10750

800

850

900

950

1000

1050

Alti

tude

, ft

time, sec

no restoring

min−norm

min−drag

max−norm

Figure A.3: Time histories of north position, east position, and altitude for aggressive combatmaneuvering task.


A.2 Formation Flying

Figures A.4 through A.6 show the state variable time histories for the sample formation

flying task.


0 1 2 3 4 5 6 7 8 9 10200

250

300

350

400

450

500

VT, f

ps

0 1 2 3 4 5 6 7 8 9 10−15

−10

−5

0

5

10

15

α, d

eg

0 1 2 3 4 5 6 7 8 9 10−15

−10

−5

0

5

10

15

β, d

eg

time, sec

no restore

min−norm

min−drag

max−norm

Figure A.4: Time histories of total velocity, angle of attack, and sideslip angle for formationflying task.


0 1 2 3 4 5 6 7 8 9 10−15

−10

−5

0

5

10

15

θ, d

eg

0 1 2 3 4 5 6 7 8 9 10−15

−10

−5

0

5

10

15

ψ, d

eg

time, sec

0 1 2 3 4 5 6 7 8 9 10−30

−20

−10

0

10

20

30

φ, d

eg

no restore

min−norm

min−drag

max−norm

Figure A.5: Time histories of φ, theta, and ψ for formation flying task.


0 1 2 3 4 5 6 7 8 9 100

1000

2000

3000

4000

5000

Nor

th, f

t

0 1 2 3 4 5 6 7 8 9 10−100

−50

0

50

100

Eas

t, ft

0 1 2 3 4 5 6 7 8 9 10500

1000

1500

Alti

tude

, ft

time, sec

no restore

min−norm

min−drag

max−norm

Figure A.6: Time histories of north position, east position, and altitude for formation flyingtask.


A.3 PIO-like Maneuver

Figures A.7 through A.9 show the state variable time histories for the sample PIO-like

maneuver.


0 1 2 3 4 5 6 7 8 9 10350

400

450

VT, f

ps

0 1 2 3 4 5 6 7 8 9 10−15

−10

−5

0

5

10

15

α, d

eg

0 1 2 3 4 5 6 7 8 9 10−15

−10

−5

0

5

10

15

β, d

eg

time, sec

no restore

min−norm

min−drag

max−norm

Figure A.7: Time histories of VT , α, and β for PIO-like maneuver.


0 1 2 3 4 5 6 7 8 9 10−15

−10

−5

0

5

10

15

θ, d

eg

0 1 2 3 4 5 6 7 8 9 10−15

−10

−5

0

5

10

15

ψ, d

eg

time, sec

0 1 2 3 4 5 6 7 8 9 10−60

−40

−20

0

20

40

60

φ, d

eg

no restore

min−norm

min−drag

max−norm

Figure A.8: Time histories of φ, theta, and ψ for PIO-like maneuver.


0 1 2 3 4 5 6 7 8 9 100

2000

4000

6000

8000

10000

Nor

th, f

t

0 1 2 3 4 5 6 7 8 9 10500

1000

1500

Alti

tude

, ft

time, sec

0 1 2 3 4 5 6 7 8 9 10−200

−150

−100

−50

0

50

100

150

200

Eas

t, ft

no restore

min−norm

min−drag

max−norm

Figure A.9: Time histories of north position, east position, and altitude for PIO-like maneu-ver.

Appendix B

SimCode

This appendix contains a portion of the simulation code changed significantly from Bolling’s

batch control allocation simulation.

96

Jeffrey Q. Leedy Appendix B. Simulation Code 97

SUBROUTINE REALMAIN(Done)*------------------------------------------------------------------------------* Purpose:* Serves as the main executive for the simulation* in realtime mode.*------------------------------------------------------------------------------** Declaration Section**------------------------------------------------------------------------------

IMPLICIT NONE*------------------------------------------------------------------------------* Local Variables*------------------------------------------------------------------------------

INTEGER Max_ControlsPARAMETER (Max_Controls = 20)INTEGER I, numlinesREAL DT, T, NITER, BatRun, RealRun, ITPW, RUNTIMEREAL RTOD, TERM_UPDATE_HZ, MODEL_DT, SPEEDUP, IO_DTREAL P, Q, R, VT, ALFATRIM, BETATRIM, PHI, THETA, PSI, ALT, POWREAL DUMT, MOMCMD(3), LMOM, MMOM, NMOM, MAXMOM(3)INTEGER MULTILOOP, COUNT, ProcessIOStringDOUBLEPRECISION T1,T2,STEPSIZE(10000),READCLOCK(10000)DOUBLEPRECISION T1A,T2A,T3,T4,T5,T6,T7,T8,T9,T10LOGICAL Do_AGILEVU, Done, ReadStickFileLOGICAL Do_Fmod, Do_Conallo, Do_Store, SaveXs, SaveXDs, SaveMomsLOGICAL SaveCons, SaveSelect, Fexist, Do_Flapscd, SaveConalloLOGICAL SaveInputs, SaveRates, SaveMisc, Do_Bogey_InputLOGICAL MomScale, SaveTiming, DoTiming, DrawGraphics, EndOfRunLOGICAL Do_Bogey_Output1, Do_Bogey_Output2LOGICAL Do_All_Output_Files, Do_No_Output_Files, DisableStickCHARACTER*4 Fileext, Default_ext, Output_ext, AV_ext, FiletypePARAMETER (Default_ext = ’.dat’, AV_ext = ’.flt.’)CHARACTER*16 FilenameCHARACTER*20 HeaderCHARACTER*30 FilepathCHARACTER*80 Dummy, HOMEDIR, Message(1), OutputFormatREAL U(Max_Controls), UCMD(Max_Controls)INTEGER IOStatINTEGER ispace, bogeycountREAL USAT(Max_Controls)REAL TERM_UPDATE_HZ2, RUNTIME2REAL TIME, X(30), XD(30)

*------------------------------------------------------------------------------** (new) COMMON/DATA Section**------------------------------------------------------------------------------

INCLUDE ’INCLUDES/a_cvars.com’INCLUDE ’INCLUDES/simvars.com’INCLUDE ’INCLUDES/simprs.com’INCLUDE ’INCLUDES/flags.com’INCLUDE ’INCLUDES/bogey.com’INCLUDE ’INCLUDES/gencon.com’INCLUDE ’INCLUDES/timing.com’INCLUDE ’INCLUDES/allocat.com’INCLUDE ’INCLUDES/filenames.com’INCLUDE ’INCLUDES/fileunits.com’INCLUDE ’INCLUDES/controlblock.com’INCLUDE ’INCLUDES/xyzbogeyblock.com’

*------------------------------------------------------------------------------** Initialization Section


**------------------------------------------------------------------------------

* Equivalences:*--------------*** <equivalences deleted>

*---------------------

ABORT = 0

T = 0.0GEARDOWN=.FALSE.BRAKEON=.FALSE.

EndOfRun = .FALSE.IF (OutputFormat(1:6).EQ.’matlab’) THEN

Output_ext = ’.m’ELSEIF (OutputFormat(1:12).EQ.’cricketgraph’) THEN

Output_ext = ’.dat’ELSE

write (*,*) ’Sorry, file extension screwup’stop

ENDIF

MODEL_DT= 1/TERM_UPDATE_HZSTEPCOUNT=0 ! initializationT1=0.0 ! initializationT2=0.0 ! initialization

*------------------------------------------------------------------------------** Execution Section**------------------------------------------------------------------------------

Fexist = .TRUE.Message(1) = ’Running Out-of-Window Simulation...’IOStat = ProcessIOString(Message,1,0,0)

!----------------------------------------------------------! Open and read data from input files (read data to arrays)!----------------------------------------------------------

CALL PROCESS_INPUT_FILE

!--------------------------------! Open and setup all output files!--------------------------------

IF (Do_All_Output_Files) THENDo_Store = .TRUE.SaveXs = .TRUE.SaveXDs = .FALSE.SaveMoms = .TRUE.SaveCons = .TRUE.SaveConallo = .TRUE.SaveInputs = .TRUE.SaveRates = .TRUE.SaveMisc = .TRUE.SaveTiming = .TRUE.Do_AGILEVU = .TRUE.Do_Bogey_Output1 = .TRUE.Do_Bogey_Output2 = .TRUE.

ELSEIF (Do_No_Output_Files) THEN


SaveXs = .FALSE.SaveXDs = .FALSE.SaveMoms = .FALSE.SaveCons = .FALSE.SaveConallo = .FALSE.SaveInputs = .TRUE.SaveRates = .FALSE.SaveMisc = .FALSE.SaveTiming = .FALSE.Do_AGILEVU = .FALSE.Do_Bogey_Output1 = .TRUE.Do_Bogey_Output2 = .FALSE.

ENDIFIF (Do_Store) THEN

CALL PROCESS_OUTPUT_FILE(’open’)CALL PROCESS_OUTPUT_FILE(’init’)

ENDIF

! Set READSTICKINPUT flag for use in gl_cockpit:IF (Do_Conallo) THEN

IF (ReadStickFile.OR.DisableStick) THENREADSTICKINPUT = 0

ELSEREADSTICKINPUT = 1

ENDIFTHTL = 0.0LONGCON = 0.0LATCON = 0.0LATDIRCON = 0.0

IF (Do_Bogey_Input) THENDRAWBOGEYAC = 1CALL GET_BOGEY_GEOMETRY

ELSEDRAWBOGEYAC = 0

ENDIFEND IF

*-------------------* Begin Simulation*-------------------

DT = MODEL_DT

*------------------------* Initialize simulation*------------------------! Enable moment scaling of realtime stick inputs:

MomScale = .TRUE.! Initialize output data files

Fexist = .FALSE.

*----------------------* Set up to read stick:*----------------------

IF (DrawGraphics) THENCALL opencalltm ! call C routine which calls open_flybox

ENDIF

*---------------------------* Schedule flaps if desired:*---------------------------

IF (Do_Flapscd) THEN


CALL FLAPSCDENDIF

! note the call to Conallo.f is done via the above call to A_CCONTROL, which! calls Conallo to perform stick logic (moment scaling) as well as to allocate! controls. Therefore the following conditional structure calls CONALLO only! if Do_Fmod is false

*-------------------* Allocate controls:*-------------------

! the following call to CONALLO is now performed in FMODELREAL!! IF (Do_Conallo) THEN! CALL CONALLO! ENDIF

*----------------------------* t = 0.0 (initial conditions*----------------------------

I = 1CALL F(TIME,X,XD)IF (ReadStickFile) THEN

LATCON = LATARRAY(I)LONGCON = LONGARRAY(I)LATDIRCON = LATDIRARRAY(I)THTL = THTLARRAY(I)

ENDIFIF (Do_Bogey_Input) THEN

X_BOGEY = X_BOGEY_ARRAY(I)Y_BOGEY = Y_BOGEY_ARRAY(I)Z_BOGEY = Z_BOGEY_ARRAY(I)PHI_BOGEY = PHI_BOGEY_ARRAY(I)THETA_BOGEY = THETA_BOGEY_ARRAY(I)PSI_BOGEY = PSI_BOGEY_ARRAY(I)

ENDIFIF (Do_Store) THEN

CALL PROCESS_OUTPUT_FILE(’write’)ENDIF

*---------------------------------------* Main realtime simulation loop:*---------------------------------------

I = 1CALL ms_time(T1)STEPCOUNT = 0DO WHILE (T.LT.(RUNTIME-.0005).AND.ALT.GE.0.0)

CALL ms_time(T1A)CALL ms_time(T3)CALL F(TIME,X,XD)CALL ms_time(T4)IF (ReadStickFile) THEN

LATCON = LATARRAY(I)LONGCON = LONGARRAY(I)LATDIRCON = LATDIRARRAY(I)THTL = THTLARRAY(I)

ENDIFIF (Do_Bogey_Input) THEN

X_BOGEY = X_BOGEY_ARRAY(I)Y_BOGEY = Y_BOGEY_ARRAY(I)Z_BOGEY = Z_BOGEY_ARRAY(I)


PHI_BOGEY = PHI_BOGEY_ARRAY(I)THETA_BOGEY = THETA_BOGEY_ARRAY(I)PSI_BOGEY = PSI_BOGEY_ARRAY(I)

ENDIF

IF (Do_Fmod) THENCALL FMODELREAL(T7,T8,T9,T10)

ENDIF

IF (Do_Flapscd) THENCALL FLAPSCD

ENDIF

STEPCOUNT=STEPCOUNT+1

IF (DrawGraphics) THENCALL ls_cockpit() ! C routine which draws graphics

ENDIF

*----------------------* start of timing stuff*----------------------

IF (SaveTiming) THENCALL ms_time(READCLOCK(STEPCOUNT))CLOCKTIME = READCLOCK(STEPCOUNT)IF (STEPCOUNT.NE.1) THEN

READCLK0 = READCLOCK(STEPCOUNT-1)ELSE

READCLK0 = T1ENDIFREADCLK1 = READCLOCK(STEPCOUNT)IF (STEPCOUNT.NE.1) THEN

STEPSIZE(STEPCOUNT-1) =. READCLOCK(STEPCOUNT) - READCLOCK(STEPCOUNT-1)

STEPSIZE0 = STEPSIZE(STEPCOUNT-1)! only ’really’ do realtime when DoTiming is .true.

IF (DoTiming) THENIF ( STEPSIZE(STEPCOUNT-1) .LT. DT) THEN

! *** pause ***DOWHILE (CLOCKTIME .LT. (READCLOCK(STEPCOUNT)+

. (DT-STEPSIZE(STEPCOUNT-1))) )CALL ms_time(CLOCKTIME)ENDDO

ELSEWRITE (*,*) ’I = ’, IWRITE (*,*) ’Sorry, calculations were too slow this’WRITE (*,*) ’frame. ’WRITE (*,*) ’STEPCOUNT = ’,STEPCOUNTWRITE (*,*) ’DT = ’,DTWRITE (*,*) ’ACTUAL STEPSIZE = ’,STEPSIZE(STEPCOUNT-1)IF (SaveTiming) THEN

CALL PROCESS_OUTPUT_FILE(’finish’)ENDIFSTOP

ENDIFENDIF ! endif (DoTiming)

ELSESTEPSIZE0 = 0

ENDIFENDIF

*--------------------


* end of timing stuff*--------------------

CALL ms_time(T5)CALL RK4CALL ms_time(T6)CALL ms_time(T2A)

! calculate times for eom, rk4, ca:

EOMTIME = T4 - T3RKTIME = T6 - T5CATIME = T10 - T9LOGICTIME = T8 - T7REALTIME = CATIME + LOGICTIMEIF (EOMTIME .LE. 0.0) EOMTIME = 0.0IF (RKTIME .LE. 0.0) RKTIME = 0.0IF (CATIME .LE. 0.0. or. CATIME .GE. 1.0) CATIME = 0.0IF (LOGICTIME .LE. 0.0) LOGICTIME = 0.0IF (Do_Store) THEN

CALL PROCESS_OUTPUT_FILE(’write’)ENDIFIF (ABORT.EQ..TRUE.) GOTO 10I = I+1

ENDDO ! DO WHILE (T.LT.(RUNTIME-.0005).AND.ALT.GE.0.0)CALL ms_time(T2)

*---------------------------------* End of Realtime Simulation Loop*---------------------------------

*-----------------------------------------------* Close data files and set ABORT and Done flags:*-----------------------------------------------

IF (Do_Store) THENEndOfRun = .TRUE.CALL PROCESS_OUTPUT_FILE(’finish’)EndOfRun = .FALSE.

ENDIFIF (ABORT .EQ. 1) THEN

Message(1) = ’ABORTED’Done = .FALSE.

ELSEMessage(1) = ’Done’Done = .TRUE.

END IFIOStat = ProcessIOString(Message,1,0,0)

*-------------------* Timing statistics:*-------------------

10 CONTINUE

WRITE (6,*)WRITE (6,*)WRITE (6,*) ’Real time statistics: ’WRITE (6,*) ’Desired end time is ’,RUNTIME,’ sec’WRITE (6,*) ’Desired step size is ’,MODEL_DT,’ sec’WRITE (6,*) ’Number of multi-loop calls is ’,MULTILOOPWRITE (6,*)WRITE (6,*) ’Actual end time was ’,T2-T1,’ sec’WRITE (6,*) ’Actual step size was ’,(T2-T1)/STEPCOUNT, ’sec’


IF (DrawGraphics) THENCALL closecalltm ! close joystick port (in openclose_tm.c)

ENDIF

*---------------------* END OF SIMULATION*---------------------

* Return to menus:Done = .TRUE.RETURN

* --------------------* Format statements:* --------------------

600 FORMAT(A)601 FORMAT(’Time:’,A1,F6.2)602 FORMAT(5X,5(F10.3,A1),/,5X,5(F10.3,A1))!603 FORMAT(5X,5(F10.3,A1),/,5X,5(F10.3,A1),/,5X,5(F10.3,A1))603 FORMAT(5X,5(F10.3,A1))605 FORMAT(5X,3(F12.6,A1),/,5X,3(F12.6,A1))700 FORMAT(5X,5(F10.3,A1))1040 FORMAT (’Opened file ’,I2,’ named ’,A80,’ successfully’)1041 FORMAT (’Closed file ’,I2,’ named ’,A80,’ successfully’)1042 FORMAT (’Closed file ’,I2,’ successfully’)2000 FORMAT (13e5,3X)

END*------------------------------------------------------------------------------** End of Module REALMAIN**------------------------------------------------------------------------------

C23456789012345678901234567890123456789012345678901234567890123456789012

!! File: F18Funs_x_sl.f!

SUBROUTINE FMODELREAL(T7,T8,T9,T10)! ----------------------------------------------------------------------!! Function: ESTIMATES AERODYNAMIC PARAMETERS FROM AEROMOD AND! FINDS THE REQUIRED MOMENTS NEEDED TO SATISFY THE PILOT! COMMANDS SENT FROM MODULE GIF /*BY DYNAMIC INVERSION*/!! ----------------------------------------------------------------------!! MODIFICATIONS:! Date Purpose By! JUL 28 1995 Decreased LAMDAV,LAMDAW,LAMDAP,LAMDAQ,LAMDAR! 50% JB! SEPT 1 1995 moved the above parameters to the settings! file JB! JAN 29 1996 added logic for auto throttle JB! JUL 03 1996 Added new COMMON and EQUIVALENCE Info for! F-18 V1.2 JB!! ----------------------------------------------------------------------!! Glossary Section!! ----------------------------------------------------------------------


! Global Variables!! Name | Type | Description*ALFA REAL Angle of attack (degrees)*BETA REAL Sideslip angle (degrees)*VT REAL Aircraft total velocity (Ft/sec)*ALT REAL Altitude (ft)*P REAL Body axis roll rate (sec^-1)*Q REAL Body Axis pitch rate (sec^-1)*R REAL Body axis yaw rate (sec^-1)*DHTL REAL Left stabilator def. (deg)*DHTR REAL Right stabilator def. (deg)*DAL REAL Left aileron deflection (deg)*DAR REAL Right aileron deflection (deg)*DRL REAL Left rudder deflection (deg)*DRR REAL Right rudder deflection (deg)*THETA REAL Euler pitch angle (rad)*PHI REAL Euler roll angle (rad)*PSI REAL Euler heading angle (rad)*LAMDAV REAL Control Law parameter*LAMDAW REAL Control law parameter*THTLTRIM REAL Trimmed Throttle position*LAMDAP REAL Control law parameter*LAMDAQ REAL Control law parameter*LAMDAR REAL Control law parameter*Do_Conallo LOGICAL Status of Control Allocation*MomScale LOGICAL Flag used in Conallo (use global AMS)*VTCMD REAL Velocity command (ft/sec)*THTL REAL Throttle position (ND)*LMOM REAL Output from Control allocation (Cl or dCl)*MMOM REAL Output from control allocation (Cm or dCm)*NMOM REAL Output from control allocation (Cn or dCn)*MOMCMD() REAL Commanded control generated moments*ALFACMD REAL ALFA Command (rad)*BETACMD REAL BETA Command (rad)*PCMD REAL Roll rate command (sec^-1)*MAXMOM REAL Maximum moment in direction of desired moment;* used in stick logic moment scaling! ----------------------------------------------------------------------

IMPLICIT NONE! ----------------------------------------------------------------------!! Declaration Section!! ----------------------------------------------------------------------

INTEGER Max_ControlsPARAMETER (Max_Controls = 20)

REAL ALFA, BETA, VT, ALT, P, Q, R, DHTL, DHTR, DAL, DAR, DRL,. DRR, THETA, PHI, PSI, LAMDAV, LAMDAW, THTLTRIM, LAMDAP,. LAMDAQ, LAMDAR, VTCMD, MOMCMD(3), LMOM, MMOM, NMOM,. ALFACMD, BETACMD, PCMDREAL U(Max_Controls),UCMD(Max_Controls)REAL MAXMOM(3), STKSATREAL GetUEff

REAL TIMELOGICAL Do_Conallo

DOUBLEPRECISION T7,T8,T9,T10! -------------------------------Locals---------------------------------

INTEGER NN, I, J, kPARAMETER (NN=30)REAL T, XM(NN), XMD(NN)REAL QCMD,RCMD,VDOTCMD,WDOTCMD,PDOTCMD,QDOTCMD,RDOTCMD


REAL CYX,CZXREAL CD,CY,CL,CZREAL D2R,R2DREAL U_,V,WREAL ALPHA,AMACH,QBAR,PSREAL CALP,SALP,CBTA,SBTA,STH,CTH,SPH,CPH,SPSI,CPSI,QSB,QSC,QSPHREAL S,B,CBAR,RM,XCGR,GREAL QS,RMQS,GCTH,IXX,IYY,IZZ,IXZREAL BETARREAL KTHTLLOGICAL Do_U_Effects, MomScalePARAMETER (KTHTL = 0.0375)

! ----------------------------------------------------------------------!! Common Section!! ----------------------------------------------------------------------

INCLUDE ’a_cvars.com’INCLUDE ’simvars.com’INCLUDE ’simprs.com’INCLUDE ’gencon.com’INCLUDE ’rateincs.com’INCLUDE ’aerovars.com’INCLUDE ’allocat.com’INCLUDE ’usats.com’INCLUDE ’timing.com’

! ----------------------------------------------------------------------!! Equivalence Section!! ----------------------------------------------------------------------

*** <equivalences deleted>! ----------------------------------------------------------------------

DATA S,B,CBAR,RM,G,IXX,IYY,IZZ,IXZ/400,34.72,11.52,1.0E-3,32.174,. 23168.0,123936.0,143239.0,-2970.75/DATA R2D,D2R / 57.29578, 0.01745329/DATA Do_U_Effects/ .TRUE./

! ----------------------------------------------------------------------!! Run Section!! ----------------------------------------------------------------------

ALPHA = ALFA*D2RBETAR = BETA*D2RCALL ADC(VT, ALT, AMACH, QBAR, PS)

CALL AEROMOD( CD, CY, CL, C1, CM, CN,. ALFA, BETA, AMACH, P, Q, R,. DHTR, DHTL, DAR, DAL, DRR, DRL,. Do_U_Effects, .TRUE.)

CALP = COS(ALPHA)SALP = SIN(ALPHA)CBTA = COS(BETAR)SBTA = SIN(BETAR)U_= VT * CALP * CBTAV= VT * SBTAW= VT * SALP * CBTASTH = SIN(THETA)CTH = COS(THETA)


SPH = SIN(PHI)CPH = COS(PHI)SPSI = SIN(PSI)CPSI = COS(PSI)QS = QBAR * SQSB = QS * BQSC = QS * CBARRMQS = RM * QSGCTH = G * CTHQSPH = Q * SPH

CZ = -CD*SALP*CBTA-CL*CALPCYX = CY-DCYDR*RCZX = -(CD-DCDDQ*Q)*SALP*CBTA-(CL-DCLDQ*Q)*CALP

! INTERPRET PILOT COMMANDS

! MOMENT EQUATIONS (no control law):

! Given: LATCON, LONGCON, LATDIRCON (each -1 to 1)

MomScale = .TRUE. ! Flag used in Conallo.fCALL ms_time(T7)

! Give initial desired moment direction so algorithm can find intersection! with AMS:

MOMCMD(1) = -LATCONMOMCMD(2) = -LONGCONMOMCMD(3) = LATDIRCON

CALL CONALLO ! Find int of desired moment with global AMS for! use in scaling; makes full stick deflection command! full attainable moment in that particular direction

! (logic if SATM or STKSAT = 0)

IF (SATM.ne.0) THEN ! only allocate if saturation not negligible

! the following should make sure that these controls for max moment are! on the AMS boundary:

DO 1045 J = 1,MIF (SATM.LT.1.0) THEN

USAT(J) = UALLO_SL(J)/SATMELSE

USAT(J) = UALLO_SL(J)ENDIF

1045 CONTINUE

! FIND MAX MOMENT

DO 1005 I = 1,3MAXMOM(I) = 0.0DO 1006 J = 1,M

BMAT(I,J) = GETUEFF (I, IU(J), 0.0)MAXMOM(I) = MAXMOM(I) + BMAT(I,J)*USAT(J)

1006 CONTINUE1005 CONTINUE


! calculate stick saturation:

IF ( ABS(LATCON) .GE. ABS(LONGCON) ) THENSTKSAT = ABS(LATCON)

ELSESTKSAT = ABS(LONGCON)

ENDIF

! finally, the moment inputs to the call to CONALLO for its intended purpose,! allocating controls:

MOMCMD(1) = -STKSAT*MAXMOM(1)MOMCMD(2) = -STKSAT*MAXMOM(2)MOMCMD(3) = STKSAT*MAXMOM(3)

CALL ms_time(T8)

! call CONALLO again to calculate the actual controls (not max)

CALL ms_time(T9)

MomScale = .FALSE. ! Flag used in Conallo.fCALL CONALLO

ELSE ! (else SATM does equal zero; don’t allocate)Do_Conallo = .false.

ENDIFIF (.NOT. Do_Conallo) THEN

LMOM = MOMCMD(1)MMOM = MOMCMD(2)NMOM = MOMCMD(3)

END IF

A_CVARR(56) = THTL ! can’t use EQUIVALENCE statement here! since THTL is in another common block

CALL ms_time(T10)! ----------------------------------------------------------------------!! End Of FMODEL!! ----------------------------------------------------------------------

RETURNEND

C23456789012345678901234567890123456789012345678901234567890123456789012* File: Conallo.f: Control Allocation Software Version 4.0a* Contents:* CONALLO: Main Control Allocation executive module.* ALLODIAGSOUT: Writes the ConAllo diagnostic output.* RESTORE_U: Control restoring algorithms.* GET_FACET: Facet searching algorithm.* GET_MAT: Formulates the geometry defining matrix for a* specific facet.* GET_U: checks a facet and allocates controls if pos-* sible.* PINVB3: Pseudo-Inverse calculation of a 3xm matrix.* PINVB4 Pseudo-Inverse calculation of a 4xm matrix.* INVMAT3: 3X3 matrix inversion.* INVMAT4: 4x4 matrix inversion.* D3: Determinant of a 3X3 matrix*


C23456789012345678901234567890123456789012345678901234567890123456789012! ----------------------------------------------------------------------!! Module Name: CONALLO! Called By: SHELL_CONALLO, TRIMMER, LINRIZE, SIMBATCH! Calls to: A_CGETUEFF, GET_FACET, A_CGETCSTR!! ----------------------------------------------------------------------SUBROUTINE CONALLO! ----------------------------------------------------------------------!! Function: Main Control Allocation executive!!! ----------------------------------------------------------------------!! Modifications:! Date Purpose By! JUL 09 1996 Created. (Based on major revisions to version! 3.0) JB! SEPT 11 1996 Added calls to a new aircraft-specifc module! "A_CGETCSTR" to take care of all of the! constraints, and the module "A_CTFORM" which takes! care of any transformation tricks of BMAT JB! OCT 11 1996 Removed calls to A_CTFORM, (not used anymore) JB! JAN 11 1997 Added the diagnostics output subroutine ALLODIAGS-! OUT. JB! MAR 08 1997 changed the argument list that is sent to A_CGET-! CSTR. Also made modifications so that Conallo cal-! culates the control constraints based on position! and rate info from A_CGETCSTR (which is where it! was previously done). Finally, gains were added to! the final commanded deflections during run time! to overdrive the actuators so that max rate command! equals max deflection rate. (yeah, confusing, but! TRUST ME, IT WORKS) One more thing, I put some more! logic in to bypass restoring (if enabled) when the! rate saturation in moment space is greater than 1.! This is done because the restoring algorithms gen-! erally don’t give maximum rate deflections which are! required when RSAT > 1.0 JB! MAR 23 1997 Changed the argument list to GETCSTR for the last! time. JB!! ----------------------------------------------------------------------!! Glossary Section!! ----------------------------------------------------------------------! Global Variables!! Name | Type | Description*Trimming LOGICAL Status of Trimmer*RealRun LOGICAL Realtime run status*MomScale LOGICAL True if calling Conallo to scale desired moment*Do_Linrize LOGICAL Status of Linearization Utility*Initialized LOGICAL Initialization flag*Do_Diags LOGICAL Diagnostics flag*DT REAL Time step (sec)*MOMCMD(1) REAL Commanded Cl (control generated)*OLDMOM(1) REAL Actual Cl due to controls (previous iter.)*LMOM REAL Input to Control allocation (Cl or dCl)*MMOM REAL Input to control allocation (Cm or dCm)


*NMOM REAL Input to control allocation (Cn or dCn)*U(1) REAL Control 1 deflection (deg)*PSAT REAL Control Position saturation flag*PSATOLD REAL % control rate saturation; used only for writing* to an output data file*RSAT REAL % control rate saturation*NCTRLS INTEGER Number of configurable controls*UCMD(1) REAL Control 1 def. Command (deg)*IFAIL(1) INTEGER Failure Status: Control 1*UTAU(1) REAL 1st order time constant U(1)!! CONALLO Globals!! Name | Type | Description*MF INTEGER Number of failed controls*M INTEGER Number of controls to allocate*U1 INTEGER Number of 1st control defining facet*U2 INTEGER Number of 2nd control defining facet*IU(M) INTEGER UALLO(IU(M)) <-> U(M)*RTYPE INTEGER Type of restoring logic to use***URMIN(M) REAL The deflection rate limits (min. direction)*URMAX(M) REAL The deflection rate limits (max. direction)*UMIN(M) REAL The minimum control deflection constraints*UMAX(M) REAL The maximum control deflection constraints*BMAT(3,M) REAL Control power matrix (local or global)*UALLO(M) REAL The allocated control deflections*MOM(3) REAL Commanded moment inputs (deltas or global)*SATM REAL saturation level (taken in moment space)*RSATU REAL maximum rate saturation level (control space)*!! Local Variables!! Name | Type | Description*Allocated LOGICAL TRUE if allocation successful*Isfailure LOGICAL TRUE if there is a failure present*Use_Globals LOGICAL TRUE if global limits and eff. is to be used**UFAIL(MF) REAL vector of failed controls*IUF(MF) INTEGER UFAIL(IUF(MF)) <-> U(MF)*MAXMOM(3) REAL maximum moment in direction of desired moment;* used in stick logic moment scaling*ACTMOM(3) REAL Actual moments produced*MOLD(3) REAL Moments at previous iteration*MDOT(3) REAL Moment rates*UDOT(3) REAL Control deflection rates*UOLD(3) REAL Control deflections at prev. iter*NORMU REAL Norm of control deflections! ----------------------------------------------------------------------


INTEGER Max_ControlsPARAMETER (Max_Controls = 20)

LOGICAL Trimming, Do_Linrize, Initialized, Do_Diags, RealRunLOGICAL MomScaleINTEGER IFAIL(Max_Controls)


INTEGER NCTRLSREAL DTREAL MOMCMD(3), OLDMOM(3), LMOM, MMOM, NMOM, PSAT, RSAT, PSATOLDREAL RSATO, RSATUOLDREAL U(Max_Controls), UCMD(Max_Controls), UTAU(Max_Controls)REAL UOLD(Max_Controls), UDOT(Max_Controls), DU(Max_Controls)REAL ACTMOM(3), MOLD(3), MDOT(3), NORMU, ACTMOM_DEL(3)REAL MAXMOM(3)

! -------------------------------Locals---------------------------------LOGICAL Allocated, Isfailure, Use_GlobalsINTEGER I, J, K, MF, IUF(Max_Controls), ISTATUSREAL UFAIL(Max_Controls),SECNDSCHARACTER*80 MSGREAL ETOTAU,GK

! ---------------------------Shared Library-----------------------------REAL GETUEFF

! ----------------------------------------------------------------------!! Common Section!! ----------------------------------------------------------------------

INCLUDE ’INCLUDES/a_cvars.com’INCLUDE ’INCLUDES/simvars.com’INCLUDE ’INCLUDES/simprs.com’INCLUDE ’INCLUDES/flags.com’INCLUDE ’INCLUDES/allocat.com’INCLUDE ’INCLUDES/allodiags.com’


*** <equivalences deleted>

! ----------------------------------------------------------------------!! Initialization Section!! ----------------------------------------------------------------------

! ----------------------------------------------------------------------!! Run Section!! ----------------------------------------------------------------------

DG_ET = SECNDS(0.0)MF = 0Allocated = .FALSE.Isfailure = .FALSE.SATM = 0.RSATU = 0.ISTATUS = -99MSG = ’ ’

! Get the approximate control generated moments for current frame using! the slope at the origin method.

DO 1005 I = 1,3OLDMOM(I) = 0.0DO 1006 J = 1,NCTRLS

BMAT(I,J) = GETUEFF(I,J,0.0)


OLDMOM(I) = OLDMOM(I) + BMAT(I,J)*U(J)1006 CONTINUE1005 CONTINUE

! Use local effectiveness and contraints during RUNTIME, and use the! slopes at the control origins and global constraints during! TRIM, LINEARIZATION.

IF (Trimming .OR. Do_Linrize .OR. MomScale) THENUse_Globals = .TRUE.

ELSEUse_Globals = .FALSE.

END IFDG_U_Globals = Use_Globals

! See if all of the controls are working and reconfigure the controls! to allocate if we have to.

J = 1M = NCTRLSDO 1020 I = 1,NCTRLS

IF (IFAIL(I) .NE. 0) THENIsfailure = .TRUE.M = M - 1MF = NCTRLS - MIUF(MF) = IUFAIL(MF) = U(I)IF (U1 .GT. M .OR. U2 .GT. M) THEN

! the column for the control eff. of the control that worked last! frame has changed. We better search from scratch.

U1 = 0U2 = 0

END IFELSE

IU(J) = IJ = J + 1

END IF1020 CONTINUE

DO 1025 I = 1,MUALLO(I) = 0.0

1025 CONTINUE

! Can we still allocate? If not, get out.

IF (M .LT. 3) THENWRITE(6,’(1x,A)’) ’Too few controls to allocate--EJECT! EJECT!’ABORT = 1RETURN

END IF

! Get the control power matrices for the controls (that work).

DO 1030 I = 1,3DO 1031 J = 1,M

IF (Use_Globals) THENBMAT(I,J) = GETUEFF(I,IU(J),0.0)

ELSEBMAT(I,J) = GETUEFF(I,IU(J),U(IU(J)))

END IF1031 CONTINUE1030 CONTINUE

! Set the control minimum and maximum contraints for allocation. This


! is done by getting the position limits and rate limits and then taking! the most restrictive of either the position limit or the amount that! a control can move in one frame (for run mode only, otherwise, we! take the position limits)

CALL GETCSTR(M, IU, UMAX, UMIN, URMAX, URMIN)

IF (.NOT. Use_globals) THENDO 1035 I = 1,M

UMIN(I) = AMAX1((UMIN(I) - U(IU(I))),-URMIN(I)*DT)UMAX(I) = AMIN1((UMAX(I) - U(IU(I))), URMAX(I)*DT)

1035 CONTINUEEND IF

! Input moment commands. (we use absolute moment commands when! TRIMMING. For RUNMODE, we use "delta" moment commands.)

IF (.NOT.MomScale) THENIF (Use_Globals) THEN

MOM(1) = LMOMMOM(2) = MMOMMOM(3) = NMOM

ELSEDO 1042 I = 1,3

MOM(I) = MOMCMD(I) - OLDMOM(I)1042 CONTINUE

END IFENDIF

IF (MomScale) THENMOM(1) = MOMCMD(1)MOM(2) = MOMCMD(2)MOM(3) = MOMCMD(3)

ENDIF

! Check for any position saturation of controls

if (.NOT.MomScale) THENPSAT = 0.0DO 1050 I = 1,M

IF (UMAX(I) .EQ. 0.0 .OR. UMIN(I) .EQ. 0.0) THENPSAT = 1.0

END IF1050 CONTINUE

endif

! Check to see if we even need to allocate or not

IF (.NOT.MomScale) THENIF (MOM(1) .EQ. 0. .AND. MOM(2) .EQ. 0. .AND. MOM(3) .EQ. 0.) THEN

Allocated = .TRUE.END IF

END IF

IF (.NOT. Allocated) THEN

! Start Control Allocation. We check the facet that worked last frame! right now.

IF (U1 .NE. 0 .AND. U2 .NE. 0) THENif (MomScale) then

CALL GET_FACET(UALLO_SL, Allocated, SATM, ISTATUS, MSG,. BMAT,U1, U2, UMIN, UMAX, MOM, M, MAXMOM, IU)


elseCALL GET_FACET(UALLO, Allocated, SATM, ISTATUS, MSG,

. BMAT,U1, U2, UMIN, UMAX, MOM, M, MAXMOM, IU)endifIF (Allocated) THEN

GO TO 1059END IF

END IF

! Oh man! now we have to start searching from scratch.

DO 1051 U1 = 1,M-1DO 1052 U2 = U1+1,M

if (MomScale) thenCALL GET_FACET(UALLO_SL, Allocated, SATM, ISTATUS,

. MSG,BMAT,U1, U2, UMIN, UMAX, MOM, M, MAXMOM, IU)else

CALL GET_FACET(UALLO, Allocated, SATM, ISTATUS,. MSG,BMAT,U1, U2, UMIN, UMAX, MOM, M, MAXMOM, IU)

endif

IF (Allocated) THENGO TO 1059

END IF


END IF

1059 CONTINUE ! we’re done allocating

IF (.NOT. Use_Globals) THENRSAT = SATM ! Rate Saturation (moment space)

! Time for some control restoring algorithms

IF (RTYPE .GT. 0 .AND. RSAT .LT. 1.0) THENCALL RESTORE_U (MOMCMD, U, DU) ! returns DU

ELSE ! allocated delta DU = 0 since no restoring performedK = 1DO WHILE (K .LE. M)

DU(K) = 0.0K = K+1

END DOEND IF

! Calculate the allocated controls (after restoring if selected):

RSATU = 0.DO 1947 I=1,M

RSATO = RSATUUALLO(I) = UALLO(I) + DU(I) ! UALLO is the restored controlIF (UALLO(I) .LT. 0.) THEN

RSATU = 1. - (UMIN(I)-UALLO(I))/UMIN(I)ELSE

IF (UALLO(I) .GT. 0.) THENRSATU = 1. - (UMAX(I)-UALLO(I))/UMAX(I)

ELSERSATU = 0.

END IFEND IFRSATU = AMAX1(RSATU,RSATO)


1947 CONTINUERSATUOLD = RSATU

! Calculate the actual moments produced (incrementally building up):

DO 1053 I = 1,3ACTMOM(I) = 0.0DO 1054 J = 1,M

ACTMOM(I) = ACTMOM(I) + BMAT(I,J)*UALLO(IU(J))1054 CONTINUE

ACTMOM_DEL(I) = ACTMOM(I)ACTMOM(I) = MOLD(I) + ACTMOM_DEL(I)

1053 CONTINUE

! Calculate the moment rates. The MOLDs are initilized to zero in BDInit

DO 1057 I = 1,3MDOT(I) = (ACTMOM(I) - MOLD(I)) / DTMOLD(I) = ACTMOM(I)

1057 CONTINUE

! Calculate the control rates. The UOLDs are initialized to zero in! BDInit

DO 1055 I = 1,NCTRLSUDOT(I) = (UALLO(I) - UOLD(I)) / DTUOLD(I) = UALLO(I)

1055 CONTINUE

! Get allocated Control commands. (The UTAU()/DT factor is the gain re-! quired to overdrive the control commands so that max rate command =! max rate deflection

DO 1060 I = 1,MUCMD(IU(I)) = U(IU(I)) + UTAU(IU(I))/DT*UALLO(I)

ELSE ! if (Use_Globals)

! Here we are dealing with global positions not deltas

IF (MomScale) THENPSAT = SATM ! Position saturation (moment space)

ENDIF

IF (.NOT.MomScale) THENDO 1070 I = 1,M

UCMD(IU(I)) = UALLO(I)1070 CONTINUE

ENDIF

END IF

DG_ET = SECNDS(DG_ET)DG_ET = AMAX1(0.0,DG_ET)DG_ISTAT = ISTATUSDG_IMSG = MSGIF (Do_Diags) THEN

CALL ALLODIAGSOUTEND IF

! ----------------------------------------------------------------------!! End of CONALLO!


! ----------------------------------------------------------------------RETURNEND

C23456789012345678901234567890123456789012345678901234567890123456789012! ----------------------------------------------------------------------!! Module Name: RESTORE_U! Called by: CONALLO! Calls to:!! ----------------------------------------------------------------------

SUBROUTINE RESTORE_U (MOMCMD, U, DU)! ----------------------------------------------------------------------!! Function: Performs various control-restoring techniques! according to RTYPE.!! RTYPE = 0 -> No Restoring! RTYPE = 1 -> Restore towards the Minimum Norm solution.! RTYPE = 2 -> Restore towards the min CD solution.! RTYPE = 3 -> Restore towards the ’Maximum Norm’ solution.!! ----------------------------------------------------------------------!! Modifications:! Date Purpose By! JUL 09 1996 Created, JB! OCT 21 1996 Rewrote the minimum-norm restoring logic. Instead! of using the null-space projection method of the! pseudo inverse, we use a least squares approach! by specifying a function of the the squares of the! controls.! MAR 23 1997 Removed the RSAT argument (Now defined in ALLOCAT! Common block) JB! ----------------------------------------------------------------------


INTEGER Max_ControlsPARAMETER (Max_Controls = 20)REAL CS_MINDRAG

! -------------------------------Locals---------------------------------REAL UP(Max_Controls), DU(Max_Controls), U(Max_Controls),

. PMAT(Max_Controls,3), MOMCMD(3), RSAT, SC, SC1INTEGER I,JREAL P4(Max_Controls,4), ROW4(Max_Controls),

. B4MAT(4,Max_Controls), DELO(4)REAL UPSEUDO(Max_Controls)

! ---------------------------Shared Library-----------------------------REAL GETUEFF

! ----------------------------------------------------------------------!! Common Section!! ----------------------------------------------------------------------

INCLUDE ’INCLUDES/simvars.com’INCLUDE ’INCLUDES/a_cvars.com’INCLUDE ’INCLUDES/allocat.com’



EQUIVALENCE (SIMVARR(172), CS_MINDRAG)

! ----------------------------------------------------------------------!! Run Section!! ----------------------------------------------------------------------

IF (RTYPE .EQ. 1) THEN! ----------------------------------------------------------------------! Minimum-Norm restoring! ----------------------------------------------------------------------

! Mod to simplify this procedure wcd 2/17/98

! Get the pseudoinverse of BMAT. Ideally this would be the Global B,! but we have to use the same B matrix (local) as the rest of the restoring! algorithm is using, otherwise we are not moving in the null space.! In any event BMAT -> BGLOBAL as U -> 0, which is where we are most! interested in getting the min norm.

CALL PINVB3 (M, BMAT, PMAT)

DO 1941 I=1,MUPSEUDO(I) = 0.0

1941 CONTINUEDO 1943 I=1,M

DO 1942 J=1,3UPSEUDO(I)=UPSEUDO(I)+PMAT(I,J)*MOMCMD(J)


! UPSEUDO is the control position that yields min norm! for the desired moment (MOMCMD).

! Calculate DU.! Vector U is old position, and UPSEUDO is where we’d like to! get to if we can. We want U + UALLO + DU = UPSEUDO, but may! have to scale DU to stay within rate constraints.

DO 1944 I = 1,MDU(I) = UPSEUDO(I)-U(I)-UALLO(I)

1944 CONTINUE

! Now scale DU s.t. DU + UALLO does not! violate local (frame-wise) limits.

SC = 1.0DO 1945 I=1,M

SC1 = SCIF (DU(I) .GT. (UMAX(I) - UALLO(I))) THEN

SC1 = (UMAX(I) - UALLO(I))/DU(I)END IFIF (DU(I) .LT. (UMIN(I) - UALLO(I))) THEN

SC1 = (UMIN(I) - UALLO(I))/DU(I)END IFSC = AMIN1(SC,SC1)


1945 CONTINUE

IF (SC.NE.1.0) THENDO 1946 I = 1,M

DU(I) = SC*DU(I)1946 CONTINUE

ENDIF

END IF ! endif (RTYPE=1)! ----------------------------------------------------------------------! End of Minimum-norm Restoring! ----------------------------------------------------------------------! ----------------------------------------------------------------------

IF (RTYPE .EQ. 3) THEN! ----------------------------------------------------------------------! Maximum-Norm restoring! ----------------------------------------------------------------------

! Get the 4th row of the B matrix (Y’ = .001745*U)

DO 2012 I=1,3DO 2013 J=1,M

B4MAT(I,J) = BMAT(I,J)2013 CONTINUE2012 CONTINUE

DO 2014 J=1,MB4MAT(4,J) = 1.74533E-3*U(IU(J))

2014 CONTINUE

! make the objective vector (0,0,0,-1)^t

DELO(1) = 0.DELO(2) = 0.DELO(3) = 0.DELO(4) = 1.0

CALL PINVB4(M, B4MAT, P4)

! find a solution u satisfying u = P4*DELO

DO 2015 I = 1,MDU(I) = 0.DO 2016 J = 1,4

DU(I) = DU(I) + P4(I,J)*DELO(J)2016 CONTINUE2015 CONTINUE

! now check that the pseudo inverse solution has not violated constraints! and fix if necesary

SC = 1.DO 2020 I=1,M




2020 CONTINUE

! apply minimization factor to the scale factor also and scale controls


DO 2025 I = 1,MDU(I) = 0.1*SC*DU(I)

2025 CONTINUE

END IF ! endif (RTYPE=3)! ----------------------------------------------------------------------! End of Maximum-norm Restoring! ----------------------------------------------------------------------

IF (RTYPE .EQ. 2) THEN! ----------------------------------------------------------------------! Minimum drag restoring! ----------------------------------------------------------------------

! Get the 4th row of the B matrix (corresponding to drag)

DO 1952 I=1,3DO 1951 J=1,M

B4MAT(I,J) = BMAT(I,J)1951 CONTINUE1952 CONTINUE

DO 1953 J=1,MB4MAT(4,J) = GETUEFF(4,IU(J),U(IU(J)))

1953 CONTINUE

! make the objective vector (0,0,0,-1)^t

DELO(1) = 0.DELO(2) = 0.DELO(3) = 0.DELO(4) = -1.0

CALL PINVB4(M, B4MAT, P4)

! find a solution u satisfying u = P4*DELO

DO 1060 I = 1,MDU(I) = 0.DO 1061 J = 1,4

DU(I) = DU(I) + P4(I,J)*DELO(J)1061 CONTINUE1060 CONTINUE

! now check that the pseudo inverse solution has not violated constraints! and fix if necesary

SC = 1.DO 1066 I=1,M




1066 CONTINUE

! apply minimization factor to the scale factor also and scale controls

DO 1067 I = 1,MDU(I) = CS_MINDRAG*SC*DU(I)

1067 CONTINUE


! Calculate the restored controls and rate saturation

END IF ! endif(RTYPE=2)! ----------------------------------------------------------------------! End of minimum drag Restoring! ----------------------------------------------------------------------! ----------------------------------------------------------------------!! End of RESTORE_U!! ----------------------------------------------------------------------

RETURNEND

Jeffrey Q. Leedy

Jeffrey Quentin Leedy was born in the sleepy, backwater (but generally friendly) town ofPrinceton, West Virginia* on August 26th, 1973. Jeff himself is the product of Bruce andSandra Leedy, who begat also another, Kathy. Jeff became interested in flight at an early

age, and upon graduation from Princeton High School in the spring of 1991 he quicklymade a flight across his state’s largely unguarded southern border, ending up in

Blacksburg, Virginia, where he sometimes applied himself in the pursuit of a bachelor’sdegree in Aerospace Engineering which he earned in the spring of 1996. After a relaxingand pleasurable stint working at a newsstand in the bohemian capital of North Carolina,

Chapel Hill, in the summer of 1996, he returned to “the Burg” to pursue a master’s degreewhich he (finally) earned in the waning days of 1998. Along the way he married his firstand only love Misty. And all the days of Jeffrey have been twenty-five years. And Jeffreyand Misty begat a daughter in their own likeness, and called her name Aislinn, which isunusual but not a family name. Upon graduation, Jeff became employed by the militaryindustrial complex helping to make things which hurt other people more than the things

which the other people make hurt his people.

*You may recognize Princeton as the home of TV’s Gilligan, who in the last days of themillineum was arrested for receiving a shipment of marijuana in the mail from—who

else—Mary Ann.

Real-Time Moment Rate Constrained Control Allocation for … · 2020. 9. 28. · moment-rate...

Documents

Transcript of Real-Time Moment Rate Constrained Control Allocation for … · 2020. 9. 28. · moment-rate...