Parameter Estimation User Guide

Contents

Contents ................................................................................................................................................ 1

1 Parameter Estimation Basics ............................................................................................................ 2

1.1 Concept Summary................................................................................................................... 2

2 – Getting Started ................................................................................................................................. 2

2.1 the Run object ......................................................................................................................... 2

2.1.1 Run object definition ........................................................................................................ 2

2.2 Equations and Constants................................................................................................................ 7

2.2.1 Observation Equations ...................................................................................................... 7

2.2.2 State Equations ................................................................................................................ 7

2.3 Defining parameters ................................................................................................................ 8

2.4 Tools Directory ........................................................................................................................ 8

2.5 Starting the run ....................................................................................................................... 8

2.5.1 Pre-processing.................................................................................................................. 8

2.5.2 Simulation........................................................................................................................ 9

3 Output Error Method......................................................................................................................10

3.1 Introduction ...........................................................................................................................10

3.2.1 Coding Procedure: ...........................................................................................................11

3.2.2 Additional Calculations ....................................................................................................12

3.3 Post-processing ......................................................................................................................13

4 Filter Error Method ........................................................................................................................13

4.1 Introduction ...........................................................................................................................13

4.2 Coding procedure ...................................................................................................................14

5 Bifurcation Analysis ........................................................................................................................15

5.1 Introduction ...........................................................................................................................15

5.2 MATCONT ..............................................................................................................................15

5.2.1 Equilibrium......................................................................................................................15

5.2.2 Limit Cycle.......................................................................................................................17

Appendix...............................................................................................................................................18

A1 State Space Formulation – 1DOF..............................................................................................18

A2 Administering trails and tests ..................................................................................................18

A4 Definitions..............................................................................................................................19

References ............................................................................................................................................20

Introduction

This document will guide the user through a complete run of a Numerical Simulation, Output Error Parameter

Estimation, and a Continuation procedure of an aircraft constrained in 1 Degree of Freedom (1DOF), using an

experiment undertaken in the University of Bristol as an example. This package can be modified with ease to use other

estimation methods (Equation Error and Filter Error), and can be applied widely given experimental data and a

numerical model of the experiment exists. J.Pattinson holds credit for adapting this code from the supplements in [1],

for use in his thesis [3]. As part of a project undertaken in 2015, the author used this code for further analysis of the

same problem, but found many difficulties in running it in the same way. This document was written to help the user

understand how the theoretical practices of Parameter Estimation discussed in many documents are implemented

using MATLAB, and how the individual parts interact with each other to come to the correct output. The aim is

provide access to toolbox to aide any work wanting to util ize these methods without prior experience of coding them.

1 Parameter Estimation Basics

1.1 Concept Summary

The concept of Parameter Estimation is relatively easy to grasp. The analogy to l inear regression is the first place

someone struggling to understand it should turn – when two curves of discrete data points exist i n the same domain,

the ‘l ine of best fit’ between them falls where the sum of their differences is minimized . This is commonly known as

‘least squares’ regression and is a well -known foundation of optimisation. Equation Error parameter estimation is

exactly l ike this. One of the discrete curves is experimental data measured under controlled conditions, and the other

is a simulation of the same experiment numerically. The numerical curve is created by integrating a set of differential

equations (A1) and evaluating them at each time point of the experiment; the conditions in the equations will affect

the response to the independent variable being changed in the test. The aim of Parameter Estimation is to find the

line of best fit, and this is achieved by manipulating these conditions, or parameters (1), until the error between the

simulated and experimental curves is minimised. The parameters found for the minimized condition will describe the

real-world model, dependant on the accuracy of the differential equations. A detailed description of the equations

and parameters used in this example can be found in [2]

𝛩 = [𝐶𝐿𝛼𝑤, 𝐶𝐿𝛼ℎ

,𝛼0𝑤, 휀𝐶𝐿

, 𝐶𝑀𝑞𝑤,𝑎1, 𝜏1, 𝜏2, 𝛼 ∗, 𝐶𝐿𝑜𝑓𝑓𝑠𝑒𝑡

]

2 Getting Started

2.1 the Run object

Object Orientated Programming (OOP) is a style of computer programming whereby the programmer uses the

concept of objects, structures containing data fields and procedures, to simplify the management of complex

software. In MATLAB, objects come in classes with properties (data fields) and methods (procedures) to control

multiple functions and scripts from one control. The applications of OOP are richly spread and numerous, but for this

specific code, the use of an object can be seen as the centre of a branch diagram, providing the necessary data for all

functions involved in the programme. This approach increases the flexibility of the code to encompass different

experimental scenarios with ease, which makes for a much more user friendly experience. [9]

The run object only uses its properties field to feed into the many functions that encompass the programme. Rather

than changing these fields individually in each script, the run object will provide that information globally, extending

the use beyond the specified function. The object properties can be edited locally and kept for use in temporary

storage, but care must be taken to clear the object edited fields before each run to revert the object back to its

original conditions. The ‘clear all’ function can do this.

2.1.1 Run object definition

The next 4 pages explain the purpose and format of each entry in the run object fi le. Before starting any run, every

property should be double checked against the description.

(1)

Property Value Description Flag File Reference

state_equations 'xdot_TC13_1DOF_pitch_no_frict' The .m fi le responsible for the state equations ‘X’ in equation 2 being called every time a simulation is required to run or a

state evaluated.

#1,2 -

observation_equations ‘obs_TC13_1DOF_pitch’ The .m fi le responsible for processing the simulated data for

the observation variable ‘Y’ in equation 2. This is processed immediately after the state equations to provide the output comparison to the experimental data

#1,2 -

num_of_states 4 The .m fi le responsible for processing the simulated data for

the observation variable ‘Y’ in equation 2. This is processed immediately after the state equations to provide the output comparison to the experimental data

- -

num_of_observables 2 This value should be consistent with the number of entries in the 1xn state equation fi le output. This must match for the parameter fi le to be generated correctly.

- -

num_of_inputs ‘4’ This value should match the number of inputs in the matrix

used to util ise the OEM’s capability to model noise. In this case, each input correlates to a measured experimental quantity.

#2 -

num_of_parameters ‘11’ This number should match the number of parameters that the

optimiser will recognise and process in the Output Error Method. Be careful in recognising which variables the code views as parameters.

#2 -

run_type ‘1DOF_pitch_only’ This code will tolerate experiments in 1DOF pitch or 2DOF pitch and heave. More types can be added but for the purposes of this code, the two options are ‘1DOF_pitch_only’ and ‘2DOF_pitch_and_heave’.

#2 -

rig_config ‘1’ Retain value of 1 for calculation of the rig influence on the model.

#2 preprocess_data

preprocessing_flags ‘1’ Enables the inclusion of servo data in the main data matrix #2 preprocess_data

filter_span ‘3’ The window half width used for differentiating the values of tunnel velocity using an inverse Taylor Series approach.

Nominally set as 3 but play around to get the best results.

#2 preprocess_data


filter_order ‘2’ The order of the derivative approximation made – this can be bigger than what you want out, so set as 2 for a first order differential l ike dVt.

#2 preprocess_data

method ‘OEM’ Decision of which approach to take for the Parameter

Estimation part of the code. A choice of EEM, OEM, or FEM.

#2 Define_case

method_opt ‘OEM_GN’ Controls which optimisation method will be undertaken: Gauss-Newton or Levenberg-Marquardt. A choice of OEM_GN, OEM_LM, EEM_LM, OEM_GN, EEM_GN

#2 Define_case

line_search 1 Used to induce the line search function in the Gauss Newton

optimisation procedure to optimise in a certain direction.

- Define_case

run_start_time {340} The starting time of the numerical simulation. Used in graphing for experimental comparison and normalised during the simulation.

#3 Define_case

run_end_time {400} The ending time of the numerical simulation. Same uses as

above.

#3 Define_case

data_from_file {'090622_20ms_1dof_ramp_part2_processed'}

This property calls the results fi le that may or may not exist depending on previous runs of the same fi le. The user can define any name for this fi le but for convenience the same name as the core experimental data fi le has been used.

#1,2,3 Define_case

nzi ‘1’ The number of time segments (or data fi les) used in the processing. The requirement to use sequential data fi les is not uncommon, but will take a longer time, so l imiting to two large fi les would be sensible.

#2 Define_case

exp_obs_data_index {'theta_a', 'dtheta_a'} This singular matrix defines which variables in the chosen ‘BigMat’ data fi le that the estimation tool will take as the observation variables.

#2,3 Define_case

exp_inp_data_index {'hawk_servo1','Vt','qbar','dVt'} This singular matrix defines which variables in the chosen ‘BigMat’ data fi le that the estimation tool will take as the input variables. These will be measured experimental values.

#2,3 Define_case


compute_x0 1 This programme has the capability of defining the initial conditions for each of the states simply by referencing the BigMat data fi le at the initial time point specified in Define_case. If the user does not want these values or they are

not producing a good output, select ‘0’ and create the x0 matrix yourself, ensure the dimensions and orientation are the same.

- Define_case

directly_obs_states [1,1] This matrix triggers the use of the observation variable generated in the simulation for use in further processing. The matrix must be the same dimension as the observation

variable ‘Y’. The entries match up with the entries in this variable. A value of 0 will mask the chosen entry. For most purposes, this should always be populated with ones.

#4 Define_case

params_from_csv_or_mat

‘csv’ The parameter values at the starting, latest and saved points will be recorded into a file, which MATLAB will process into a csv (comma separated values) or a mat (MATLAB matrix) file. The choice of which will be specified here. Choosing csv makes editing and viewing simpler, but calling simplicity would favour a mat file.

#2 load_and_check_parameters

results_file ‘090622_20ms_1dof_ramp_part2_processed’

This string defines the name of the results fi le the final parameters post estimation are output to. Can be any name

but for ease of tracking the same name as the input fi le is used throughout.


which_parameters ‘start’ This string will decide whether the starting, latest or saved parameters saved in the parameter csv/mat fi le are used in

the latest run of the state equations. Start, latest or saved.


obs_plot_mask [1,1] A value of 0 in these entries masks the plotting of the observation variable in question. Matrix must be consistent with the size of the observation variable matrix.

#4 plot_output

inp_plot_mask [1,1,1,1] A value of 0 in these entries masks the plotting of the input variable in question. Matrix must be consistent with the size of the input variable matrix ‘Uinp’.

#4 plot_output


static_type ‘ramp_lin’ This property should be defined according to the type of l inear progression the input takes. This is for setting up the function that trims the input to help the user match the output after one iteration. A constant initial condition (X0), a single point

(single) or a l inear ramp (ramp_lin) are the options.

#2 generate_trim_points

ramp input [1] Verify input of a ramp type #4 generate_trim_points

trim_switch 4 Decision out of 1, 2, 3 or 4 of which trim path to take. This property is related to input type and is described in the function.

- generate_trim_points

velocity_states 0 The number of velocity states in the trim input – set to zero - generate_trim_points

generate_static_file 1 1 to generate a new fi le of static points, 0 to ignore. - generate_trim_points

static_file 'TC_13_static_results' Name of static fi le if decided to create one #2 generate_trim_points

input_delay_mask ‘nomask’ This property defines whether or not a delay is required in the

input fi le. If this property is a number (1), the function will generate a delay and rewrite the Uinp variable. If it is a string (mask), the delay creation will be masked.

#2 compute_cost

parameter_step_function 1e-3 This property will control the size of step taken when varying the parameters in each iteration.

- oem_func

convergence_tolerance 1e-3 This property will define the limit of accuracy the optimiser will take between trails until a solution is reached that has a

difference of less than this value

- oem_func

num_iterations 1 This property defines the number of Parameter Estimation iterations taken. Each iteration will take the new parameters estimated from the previous iteration and use them as the

new X0. For a full run of the current experiment (600 seconds), more than one iteration will take a very long time (1hr+).

- oem_func

Flags

#1 - full fi le name without the .m

#2 - string type therefore inside quotation marks for compatibil ity

#3 - singular matrix definition required therefore include curly brackets for compatibil ity

#4 - singular matrix numeric definition required therefore include square brackets for compatibil ity

2.2 Equations and Constants

The equations required for numerical simulation should be held in two fi les – the state equations and the observation

equations, and should be kept in the >Models directory. Wihin these fi les however, as many functions and constants

can be called as desired, in accordance with how the user wants the simulation to run.

2.2.1 Observation Equations

As an example, obs_TC13_1DOF_pitch outputs the observation variable Y given an input from the state integration of

(2). This output is used in the cost function to directly compare against the experimental data, and is simply an

augmentation of rig pitch and pitch rate. Table 1 shows the MATLAB requirements for the function.

Inputs time ¦ state ¦ inputs ¦ parameters

Outputs Y (observation vector) Table 1 – list of input and outputs of the observation equations function

2.2.2 State Equations

xdot_TC13_1DOF_pitch_no_frict outputs a state vector of values that are integrated to form the numerical simulation,

and are slightly less flexible in terms of format. For the integration to work, the inputs must include time previous

state values input variables for each time step and a vector of parameters .This vector of parameter s is important to

define correctly. An efficiency of this programme is its use of a single equations fi le for each operation - integration,

estimation and continuation. The estimation segment requires categorisation of the parameters in order to optimise

them, whereas the other operations do not, so the parameters are defined as variables in stages 6 and 7, and

constants for the remaining operations. Table 2 shows the MATLAB requirements for the function.

Note: the equations must be written in state space form (A1).

𝑌 = 𝑋(𝜃)

Inputs time ¦ state ¦ inputs ¦ parameters

Outputs xdot (state vector) Table 2- list of input and outputs of the state equations function

The first l ines of the state equations fi le (figure 1) should define the function inputs as variables in the equation:

States should correspond to the ‘x’ input: a [n,d] matrix, where n=run.num_of_states and d=length(data file)

– the number of discrete data points.

Equation inputs can come from any number of variables in the function definition; however it is easier to

manage a single vector usually labelled ‘u’.

The constants of calculation (Centre of Gravity position, rig moments of inertia etc.) are externally derived –

they are kept in a single fi le for global applicability. For the purposes of Pattinsons experiments, the constants

come from the wind tunnel rig and test model – a Bae Hawk, therefore the >Hawk and >Rig directories hold

the information fi les related to each element of the experiment. hawk_constants is a function that when

(2)

Figure 1- first lines of state equations used for input definition

called in any function will output only the constants required for the specified analysis type, ensuring the size

of the constants matrix will always be compliant with what is required of it. All constants should be changed

in this fi le.

2.3 Defining parameters

The parameter definition is l ittle more involved and easy to do wrong, however the steps are simple.

1. Locate the equation fi le that includes the use of any estimation parameters. This may be the straight state

equation fi le, or it may be a nested function inside of here – in test case 13, the nested function

Hawk_2DOF_M05 is responsible for the core physical calculations (the xdot fi les simply prepare the states for

processing in this fi le).

2. Create a _spec fi le with the same fi le name (i.e. Hawk_2DOF_M05_spec.m), following the same format as the

current _spec fi les.

3. Create enclosed strings with entries exactly the same as the variable names described in hawk_estimates.

The _spec fi le will use this string to call the ‘estimates’ matrix created i n hawk_estimates, and then create a

new matrix based on the finding of matching strings, populated with the numeric values associated with

those entries. This matrix becomes part of the results fi le which stores the initial values in the estimates fi le,

then updates once new values are found from the estimation process.

4. Save fi les, then define each corresponding variable in the nested function fi le as param(n), where

n=run.num_of_parameters. The vector ‘param’ will automatically become the dimensions of n and be

populated with the initial estimates.

2.4 Tools Directory

The >Tools directory holds the majority of the functions spread out over the programme. This should be the first

reference when trying to locate a function. The only other options are the >Matlab_tools and the

>Output_error_method directories for general arithmetic OEM specific functions.

2.5 Starting the run

Once the properties in the runA object are defined, the programme needs to be started. The programme is built up in

stages, to enable individual sections to be run and reduce run times. The PE_control fi le (table 3) holds all the function

calls for each stage, and includes an input handle that calls each stage. To run a stage, a separate fi le must be created

that runs the PE_control function. This has been called ‘run_TC13’ in the examples. Highlighting each command (i),

right clicking, and selecting Evaluate Section will run a single stage only.

𝑟𝑢𝑛 = 𝑃𝐸_𝑐𝑜𝑛𝑡𝑟𝑜𝑙 (𝑟𝑢𝑛𝐴, 𝑥, 𝑥, 𝑛)

Stage Description

1-3 Pre-processing 4/5 Plotting and cost function calculation

6/7 Parameter Estimation steps 8-22 Plotting and post-processing

22-26 Continuation and plotting Table 3- summary of the operations included in PE_control

2.5.1 Pre-processing

add_remove_paths - MATLAB requires information of where each individual fi le is stored to be able to access it: this

allows the user to logically create folders and avoid single folders with huge numbers of fi les. The function

add_remove_paths will do this automatically given a description of each folder location. This will need to be changed

for each new use of the programme. An input of ‘1’ will add the fi les, whereas an input of ‘-1’ will remove them from

the path. You can check the paths MATLAB is aware of by selecting Home>Set Path.

(i)

Figure 2- toolbar choices for accessing the MATLAB path

Pre_process -The raw data in the experimental fi les needs to be processed into a single matrix of values for global use.

Upon loading, the BigMat matrix holds all of this data, with the BigMat_names (table 4) cell separately defining each

column. Raw data is kept in the >Experimental_data directory. Any additional fi les of this type should be stored here.

1 2 3 4 5 6 7 8 9 10

time rig_roll rig_pitch rig_yaw model_ pitch

model_ yaw

encoder0 encoder1 encoder 2 encoder3

11 12 13 14 15 16 17 18 19 20

comp_ servo0

comp_ servo1

comp_ servo2

comp_ servo3

hawk_ servo0

hawk_ servo1

hawk_ servo2

hawk_ servo3

hawk_ servo4

Vt

21 22 23 24 25 26 27 28 29 30

qbar hawk_ servomdl0

hawk servomdl1

hawk_ servomdl2

hawk_ servomdl3

hawk_ servomdl4

Vt_ smooth dVt encoder0_smooth

encoder1_smooth

31 32 33 34 35 36 37 38 39 40

encoder2_smooth

encoder3_smooth

theta_a dtheta_a ddtheta_a hawk_de hawk_ den alpha_a dalpha_a M_a

Table 4 – BigMatnames matrix corresponding to the example only

The pre-processor includes calculation of wind angles and rig influence, producing the last 8 columns in the matrix.

generate_parameter_file - The parameter fi le to hold the initial, latest and saved parameters must be generated for

use in the estimation segment. The output is a .csv or .mat fi le that can be viewed in the >Results_new directory. An

extra set of rows is added to the parameter vector ‘param’ which are populated by the initial conditions ‘X0’, a vector

of length [n,1] where n=run.num_of_states.

Define_case - This fi le is critical to the overall operation of the programme: every variable the test case could need is

set up in this fi le and saved to a local workspace inside the routine. This workspace is not visible if running the

programme directly from PE_control, therefore this function must be run alone before any trails or tests can be

administered (A2). The function is split into segments to allow easier tracking of the variables being generated. ‘X0’,

the initial conditions (IC’s) of the states can be evaluated and stored here if run.compute_x0 returns 1. If the

computed IC’s are unsatisfactory, an independent matrix can be written here.

2.5.2 Simulation

The first phase of the processing part of the code is to compute the value of the primary cost function, done so from

the compute_cost_and_plot function. The function call path is as below:

compute_cost – first checks whether a simulation already exists, then concatenates the system parameters and initial

conditions into one vector, providing an input to costfun_oem. The simulation check is done so that a lengthy repeat

of the simulation is not required when the optimiser attempts to run one again.

costfun_oem – runs a time integration using run_sim as the function controlling the integrator. Once this is complete,

the covariance matrix R (3) (the maximum likelihood estimate of the output errors ) is calculated, and then the

determinant of its diagonal evaluated to give the value of the current cost function (4).

𝑅 =1

𝑁∑ [𝑧(𝑡𝑘

) − 𝑦(𝑡𝑘)][𝑧(𝑡𝑘

) − 𝑦(𝑡𝑘)]𝑇𝑁

𝑘=1

𝐽(𝛩, 𝑅) =1

2∑ [𝑧(𝑡𝑘

) − 𝑦(𝑡𝑘𝑁𝑘=1 )]𝑇 𝑅−1[𝑧(𝑡𝑘

) − 𝑦(𝑡𝑘)]

run_sim – this function controls the integration step, processes the results through the observation equations and

outputs this as a single variable Y (figure 4). The options associated with the ODE solver are declared here, as well as

the global variables inside the state equations for storing the evaluated values of state (A3).

(3)

(4)

Figure 3 – function structure within compute cost and plot

ode15s – is a standard MATLAB ODE solver for stiff differential equations. The output xs is a matrix of state solutions

with length equal to the number of discrete data points. The ‘options’ values should be closely checked to ensure the

time induces the same number of points. This solver is variable step, which dramatically affects the outcome when a

time delayed input is involved (A3).

ODE solver format – the common format exercised in all MATLAB solvers is as follows [11]:

options = odeset (‘option_choices’)

[time_points, state_solution] = solver (@equationhandle, time_vector, IC_vector, options, equation_inputs )

@state_eqs_with_artifical_stability – in test case (TC)13, the equations called are xdot_TC13_1DOF_pitch_no _frict,

and obs_TC13_1DOF_pitch, however they are called through state_eqs_with_artifical_stability in ode15s as this

function includes a small l ine of code in interpolate the input values, creating a subtle but important difference in the

input of each time period. Obviously, a handle to the original equations would work fine, but the format will be

different.

Once the simulation is run and the cost function stored, compute_cost will output the current cost, the covariance

matrix and its augmentations, and the observation solutions computed by the ODE solver. The cost function is

displayed, leaving the next stage ready to optimise the parameters.

Figure 4 – successful simulation of a limit cycle overlaid on experimental data

3 Output Error Method

3.1 Introduction

Once the Maximum likelihood estimate of the parameter vectors has been established and subsequently the cost

function determined (4) the minimisation of this function can begin. A singular condition exists for this to occur

𝐽(𝛩)

𝜕𝛩= 0

The partial differentiation of 𝐽(𝛩) (4) returns

𝜕𝐽(𝛩)

𝜕𝛩= −

1

𝑁∑ [

𝜕𝑦(𝑡𝑘)

𝑑𝛩]

𝑇

𝑅−1[𝑧(𝑡𝑘) − 𝑦(𝑡𝑘

)]𝑁𝑘=1

which is simple to compute – the measured data z, the computed variables y and response gradient 𝜕𝑦(𝑡𝑘)

𝑑𝛩 all exist in

the code, as does the computed value of 𝑅−1. This expression however, cannot explicitly compute the parameter

update which is required as the second gradient 𝜕2 𝐽(𝛩)

𝜕𝛩2 is not established. Attempting to do so in the same manner as

before is however time consuming and computationally expensive, therefore the change in the computed variables

must be approximated using Quasi -l inearization:

50 100 150 200 250 300 350 400 450 500 550

10

20

30

Pit

ch

an

gle

(deg

.)

090622_20ms_1dof_ramp_part2_OEM Results

50 100 150 200 250 300 350 400 450 500 550-100

-50

0

50

Pit

ch

rate

(deg

./s)

50 100 150 200 250 300 350 400 450 500 550

-15

-10

-5

haw

kserv

o1

50 100 150 200 250 300 350 400 450 500 550

20.3

20.4

20.5

Win

d t

un

nel

velo

cit

y

(m/s

)

50 100 150 200 250 300 350 400 450 500 550248

250

252

254

Dyn

am

ic p

ressu

re

(Pa)

50 100 150 200 250 300 350 400 450 500 550

-0.4

-0.2

0

0.2

0.4

Win

d t

un

nel

accel.

(m/$

m s

2$)

Time (seconds)

Exp Sim

(5)

(6)

𝑦(𝛩) = 𝑦(𝛩0 + ∆𝛩) ≈ 𝑦(𝛩0 ) +𝜕𝑦

𝛿𝛩∆𝛩

Substitution of this into equation (4) leads to a system of separate, l inear equations, which can be represented as

𝛩𝑖+1 = 𝛩𝑖 + ∆𝛩 𝑎𝑛𝑑 𝐹∆𝛩 = −𝐺

𝐹 = ∑ [𝜕𝑦(𝑡𝑘)

𝛿𝛩]

𝑇

𝑅−1 [𝜕𝑦(𝑡𝑘 )

𝛿𝛩]

𝑁

𝑘=1

𝑎𝑛𝑑 𝐺 = − ∑ [𝜕𝑦(𝑡𝑘)

𝛿𝛩]

𝑇

𝑅−1[𝑧(𝑡𝑘) − 𝑦(𝑡𝑘

)]

𝑁

𝑘=1

F is the known as the information (or Hessian) Matrix, and is physically the matrix of second gradients. G is known as

the gradient vector, and with knowledge of both and using linear algebra, 𝛿𝛩 can be solved for. This gives 𝛩𝑖+1, which

is the solution to each iteration that we are looking for.

3.2.1 Coding Procedure:

run_optimiser – given the input decision in run.method, either the OEM or Filter Error Method (FEM) is chosen as the

estimation method, with the plot functions for the convergence criteria found at the end of the function.

ml_oem_func – this function is the command station for the maximum-likelihood parameter estimation process that

accounts for the measurement noise found in the experiment. The algorithm has 2 stages

1. Explicit estimation of R

2. Gauss-Newton or Levenberg-Marquardt optimisation of the cost function w.r.t parameters.

The optimisation method can be chosen using run.method_opt. and the first few segments of code are assigned for

selecting the estimation options, all of which can also be changed using the run object.

The first iteration loop begins with an estimation of the cost function using costfun_oem – this has been calculated

already therefore a lengthy simulation is not necessary. The difference between the previous and current cost

function values is stored as an absolute value, and if the current cost is less than the previous, the optimiser has

verified its functionality and stores the parameters and standard deviations in the results matrix. A number of error

and state checks are implemented before the next stage begins.

Optimisation problem:

Determination of the parameter vector 𝛩 which minimises det(𝑅) - the cost function.

First, the perturbations of each parameter (par_del) are calculated using run.paramater_step object as the scaling

constant. This matrix is then fed into grad_FG_new.

grad_FG_new - simulations of the experiment with added perturbations are completed using run_sim and stored in

cell array YP. This is run as an iteration of one parameter at a time, and then subsequently with the initial conditions

changed by their individual perturbations.

Debugging –this stage takes the most time in the parameter estimation process, as each perturbation simulation

takes as long as a single run of run_sim as used in the programme before. Any trail runs of the user’s specific code to

debug problems should avoid this section of the code until necessary due to the large time expenditure (A2)

F and G should have no null columns, and to test for this the user should be looking at the H matrix computed after

the simulations have taken place. The H matrix is the response gradient𝜕𝑦(𝑡𝑘)

𝛿𝛩(9). q, the variable that defines the

numerator of H, is evaluated by taking the difference of the perturbed solution matrix YP at each time step, and the

previous iteration solution matrix Y. 𝛿𝛩 is simply the numerical change for each parameter (par_del) and defines the

denominator of the response gradient. This definition is useful to know, as the H matrix should in theory have no null

columns due to the difference in solution never yielding exactly zero. If a column does return a null solution, then

either

The parameter step is not defined or is zero

The parameters have not been defined correctly and the optimiser does not recognise them.

(7)

(8)

(9)

50 100 150 200 250 300 350 400 450 500 55010

20

30

Pitch a

ngle

(deg.)

090622_20ms_1dof_ramp_part2_OEM Trim curve with data

Exp Trim

50 100 150 200 250 300 350 400 450 500 550-100

-50

0

50

Pitch r

ate

(deg./

s)

50 100 150 200 250 300 350 400 450 500 5500

1

2

50 100 150 200 250 300 350 400 450 500 550

-15

-10

-5

haw

kserv

o1

50 100 150 200 250 300 350 400 450 500 550

20.3

20.4

20.5

Win

d t

unnel velo

city

(m/s

)

50 100 150 200 250 300 350 400 450 500 550

250

255

Dynam

ic p

ressure

(Pa)

Time (seconds)

It is worth double checking these variables and any other inputs that can influence the definition of the parameters, as

this is the most common error to have during the PE process.

Now that the response gradient has been established, the last step of the function is to define F and G through simple

l inear algebra, with the new values added onto the previous each iteration.

𝐻 = 𝜕𝑦(𝑡𝑘 )

𝛿𝛩

improv – the optimisation segment of the code is selected using run.method_opt, choosing either improv or

LM_method for the Gauss-Newton or Levenberg-Marquardt method respectively. Either method is acceptable and [1]

explains the subtle differences very well.

Assuming a fully populated F matrix, its inverse can be calculated. The fact that F is symmetric and positive-definite

can be used to the situation’s advantage. Numerical inversions can be inaccurate especially when dealing with large

batches of data, therefore the code makes use of a Cholesky factorisation to create the upper -triangular matrix (UTM)

needed to create an inversion [4]. The chol function does this efficiently and is integral to the MATLAB script, requiring

no path definition. The essential matrix of parameter changes (𝛿𝛩) is described by delPar and is the explicitly the

inverse of F multiplied by G. Using the Cholesky method, this calculation is done by dividing the UTM by its transpose,

then multiplying this by G.

3.2.2 Additional Calculations

As the line search segment is turned on (run.line_search = 1), the directional optimisation routine is allowed to take place. minf_quad is responsible for the core mathematics involved in this process, and the user should refer to [5] for further information. minf_quad yields an updated parameter vector which is used as the final output of the function.

Conditions for optimality for the variables are stored using chk_lub_opt and any free parameters are dealt with given they exist.

The updated parameter vector is an output of improv and is fed back into ml_oem_func for reassembly in the main parameter fi le. Both the original and latest matrices are stored, the final parameter estimates, standard deviations and correlation coefficients are printed, then convergence plots are drawn in run_optimiser using plot_convergence_and_param_deviations, completing PE phase 7.

static_optimiser – run using PE_control phase 8, this segment of functions generates trim points from the experimental data and the numerical run wherever the motion of the inputs and outputs are supposed to be static. For example, using the ‘ramp_lin’ property in the run object, a static point would be generated for every step change

in the elevator ramp – every 10 seconds in the experiment. The new points are

x_obs - the maximum and minimum of the observation variables for each static section

t_new - the midpoints in time of each of the static sections

Uinp_new – the mean of the inputs in each static section.

The new vectors are then used in perform_trim to revaluate the F and G matrices, to output a new estimate of the parameters and a new vector of the solution states x_new. This completes the optimisation iteration and the cycle is repeated inside static_optimiser.

(9)

Figure 5 – trim points overlaid on experimental data

3.3 Post-processing

PE phase 9 can be run to save the parameter values that have resulted from a convergence, and sent to the global parameter fi le using PE phase 10. Through to PE phase 19, various plotting functions can be called to display and

compare the data that has been processed. The user can choose to change and adapt anything in this section with no consequence to the final parameters in the output of the estimation.

4 Filter Error Method

4.1 Introduction

The user should take account for the fact that the OEM used above directly accounts for turbulence in the experiment:

the input variables Uinp are measures of the wind components and are fed directly into the estimation routine with

l ittle requirement to alter it. However, this approach relies on the measurement of said variables being both precise

and accurate, as both the wind angles and aerodynamic derivatives are calculated using this data. In practice, the

process of setting up and recording of Vt may not be easy or possible, therefore it would be useful to all parties to

have the capability of mathematically modelling turbulence and estimating parameters from this data. The

complication that ensues from this difference is however not trivial.

𝑥 = 𝐴𝑥(𝑡) + 𝐵𝑢(𝑡) + 𝐹𝑤(𝑡) + 𝑏𝑥, 𝑥(𝑡0) = 0

𝑦(𝑡) = 𝐶𝑥(𝑡) + 𝐷𝑢(𝑡) + 𝑏𝑦

𝑧(𝑡𝑘) = 𝑦(𝑡𝑘

) + 𝐺𝜗(𝑡𝑘), 𝑘 = 1,2 … , 𝑁

The non-measureable process noise is included in the state equations as a noise distribution matrix ‘F’ (9), and as a

result the system becomes stochastic – unpredictable due to the influence of a random variable [6]. An estimator is

required to generate the values of the state at each time period, therefore states get ‘propagated’, not integrated [2].

This is a key difference that underpins fi lter error methods.

𝐽(𝛩, 𝑅) =1

2∑ [𝑧(𝑡𝑘

) − 𝑦(𝑡𝑘𝑁𝑘=1 )]𝑇 𝑅−1[𝑧(𝑡𝑘

) − 𝑦(𝑡𝑘)]

𝑦, the output of the system incorporating the predicted states is the first thing that must be calculated for the cost

function to be optimised. To do this, a classical l inear quadratic estimator (LQR) is required: a Kalman fi lter [12]

provides everything that is required and is flexible enough to be extended for non-linear equations, and works in a

two-step routine:

Prediction

𝑥(𝑡𝑘+1) = 𝑓𝑛(𝛷 , 𝛹)

𝑦(𝑡𝑘) = 𝑓𝑛(𝑥, 𝑢)

Correction

𝑥(𝑡𝑘) = 𝑥(𝑡𝑘

) + 𝐾[𝑧(𝑡𝑘) − 𝑦(𝑡𝑘

)]

K, the Kalman Gain Matrix, can be formulated from C, P and R, the observation matrix, the sta te prediction errors and

the covariance matrix of the square errors respectively. Whereas the calculation of R in the OEM was done using an

integrator and matrix algebra, the s tochastic nature of the equations means the prediction error must be taken into

account here as well, resulting in the equation

𝐾 = 𝑃𝐶 𝑇 𝑅−1

𝑅 = 𝐺𝐺𝑇 + 𝐶𝑃𝐶 𝑇

This simple structure (15) (16) makes up the skeleton of the FEM, but the formulation of the prediction error matrix is

again not trivial and involves some complicated arithmetic. The importance of this initial formulation should not be

understated; however the application of the process to non-linear equations is far more useful, therefore the key

(9)

(10)

(11)

(12)

(13a)

(13b)

(14)

(15)

(16)

(17)

differences shall be explained here in addition to the linear counterpart, as the code used in the programme is built

upon non-linear state equations (17) (18).

𝑥(𝑡) = 𝑓[𝑥(𝑡), 𝑢(𝑡) , 𝛽] + 𝐹𝑤(𝑦) 𝑥(𝑡0) = 𝑥0

𝑦(𝑡) = 𝑔[𝑥(𝑡) , 𝑢(𝑡), 𝛽]

The difficulty compared to l inear systems is in the way the states and the cost gradients are computed. The numerical

method of differentiation used in the OEM is applicable to the non-linear case ONLY when a first order approximation

is made of the state and measurement equations. Thankfully, the equations used in Pattinsons case are already first

order and therefore the approximation is exact. If the system model is time invariant or quasi -time invariant, a steady

state as opposed to a time variant fi lter can be used for the state estimation: this is the process developed in the

programme. By using the system equations described above in the general cost function (12), the non-linear extended

Kalman fi lter algorithm can be administered, in the key steps described below:

1) Specify some starting values for the parameter vector (𝛩) consisting of parameters appearing in the system

functions f and g, initial conditions x0 and elements of the process noise distribution matrix F.

2) Specify suitable start values for or generate an estimate of R.

3) Do the state estimation by applying the extended Kalman fi lter – computing gain matrix K, numerical

integration (propagation) of the state equations and computation of the predicted observation variables 𝑦.

4) Generate R classically.

5) Apply Gauss-Newton/Levenberg-Marquardt optimisation to update𝛩.

6) Repeat until converged.

4.2 Coding procedure

ml_fem_func – called from run_optimiser in place of the OEM function, this function starts by making an initial

estimate of the R matrix using the method found in the OEM: integration of the state equations and the

determinant/inverse of the residuals (errors). This is the only operation and output of costfun_fem. The next call is to

gainmat to calculate the Kalman gain matrix for the current cost values.

gainmat – although the non-linear state equations are functions (f and g), the elements of the system (A and C)

remain in matrix form as in (9) however they must approximated due to the stochastic reasoning described above.

The approximation is one of central difference, hence sysmatA and sysmatC create A and C respectively by evaluating

the sum of the state equations at two discrete points a small perturbation in state value between each other, then

dividing by the absolute value of this difference. x0 is updated at each PE iteration to make this approximation

accurate each time.

𝐴 =(𝑥2(𝑡𝑘) − 𝑥1(𝑡𝑘))

𝑑𝑥

The state prediction error covariance matrix element of K must next be calculated, and is done so by solving a Ric cati

equation: (20)

𝐴𝑃 + 𝑃𝐴𝑇 −1

∆𝑡𝑃𝐶 𝑇𝑅−1𝐶𝑃 + 𝐹𝐹𝑇 = 0

The Riccati Equation – a first order ordinary differential equation that is quadratic in the unknown function

𝒚′(𝒙) = 𝒒𝟎(𝒙) + 𝒒𝟏

(𝒙)𝒚(𝒙) + 𝒒𝟐(𝒙)𝒚𝟐(𝒙)

where q0 and q2 are not equal to zero. If q0 were zero, the equation would be a Bernoulli equation, and q2 being zero

would reduce the equation to a first order ODE. [7]

The adaption of the solution to a classical ODE formulation is that there are many solution methods to choose from

that have been proven effective and where efficient coding already exists. gainmat makes use of ‘Potters Method’,

which does not require derivation here, but it is enough to know that it is based on eigenvalue decomposition [1]. The

rest of the fi le follows a standard Potters Method, and hence P is calculated, allowing the output K to be compiled

from P, C and R using simple matrix algebra:

𝐾 = 𝑃𝐶 𝑇 𝑅−1

(18)

(19)

(20)

(15)

ml_fem_func (cont) – the precomputed value of the F matrix is corrected using the new value of R estimated in

gainmat using a halving sequence to check for intermediate divergence and prevent it. Once the pre-calculation

checks have been completed to ensure divergence does not occur, the gradients matrices of the cost function (F and

G) can be calculated. gainmat_pert calculates the K matrix for a small perturbation in the matrix of parameters to be

estimated (THETA) for use in the linearization approximation when using gradFG. This is exactly the same formulation

as in the OEM but with the difference that 𝑦 is used instead of y. After this calculation, it is possible for the parameters

to be updated using the quasi -l inearization approach in (14), therefore a second gain matrix procedure needs to occur

to calculate the cost function without the initial estimates and save the new parameters. The sequence of

ml_fem_func is described below for use in (14):

Kgain (initial estimate) ¦ Kgain (perturbations) ¦ Kgain (new parameters)

The current cost is carried through into run_optimiser where the code continues in the same way as before, which

concludes the FEM inclusion in the process once the iterations have caused convergence.

5 Bifurcation Analysis

5.1 Introduction

The state equations that were used for the numerical simulation stage in this programme have many more

applications. Continuation and Bifurcation methods are powerful tools in the analysis of many fl ight dynamics stability

problems, and make use of the state equations to derive the steady states of the model they present. A continuation

creates an approximate solution to a set of differential equations given an arbitrary initial condition [ 8] very much like

a time integration, with the key difference that time is not the variable being changed. This ‘continuation parameter’

can be any input into the system given it has more than a null effect; as an example, the elevator angle in Pattinsons

experiment [2]. The parameter increased or decreased in sequence, and the output of the state equations recorded.

The field of study of Bifurcations is rich and varied, with many articles and books capable of describing the bas ic

concept and further details [8]. This part of the guide wil l help the user understand the set up process and run their

own continuation using MATCONT.

Integral to the programme is MATCONT 2.5.1, a continuation programme with a vast capability for dealing with

different types of state equation in the input. Due to the knowledge of the type of output expected, the run is split

into two parts: equilibrium continuation and a l imit cycle continuation from the transition point. Note: this is not the

most updated version of MATCONT. Newer versions exist with a helpful GUI to help navigate the mainframe, which the

user can download if interested, but the two versions are not simp ly ‘copy-and-paste’ acceptable.

The point of transition between an equilibrium (or otherwise) state and a l imit cycle is known as a ‘Hopf point’ (figure

6), which occurs due to a pair of complex conjugate eigenvalues crosses into the positive plane of the real axis. [8]

5.2 MATCONT

PE_control phase 22 and 23 define the equilibrium and limit cycle segments of the continuation respectively.

5.2.1 Equilibrium

plot_bf_diagram – this function is separate from any of the continuation subsections: it is responsible for plotting the

experimental bifurcation diagram recorded in the data matrix Bigmat. Entries can be changed to plot whatever the

user wants, however in the current setting the function plots elevator angle against pitch angle. The output of the

function is the figure handle ifigure, a single value fed into MATCONT to ensure the continuation is overlaid.

run_equillibrium_continuation – the user must first define the continuer directories and put them on the current path.

Inside the ‘cd’ and ‘path’ input field, the origin directory must be set to wherever the fi les were downloaded to (i.e.

‘C:\Documents\PE_download…’), allowing access to the MATCONT base code. Results will be saved in a sub -directory

‘Results_new>Continuation_results’ which the programme will create, with fi lenames of run.result_file with the tag

‘results_bf_diag’ as set by the code in l ine 10 of this function. MATCONT keeps its input and output data in one .mat

fi le labelled ‘S’ (table)

S Description

x points on the curve v tangent vectors along the curve s found singularities h continuation process variables

f phase response curve for l imit cycles Table 5 – description of the elements in S

If this fi le already exists, then the continuer will simply use this fi le to run the continuation and update the attached

results fi le. If the fi le doesn’t exist, the input conditions must be set up – this starts at l ine 39.

Options: 1DOF_pitch_only ¦ 2DOF_pitch_and_heave

1DOF – the pre-processing of the data begins by setting Uinp (dVt) to 0 then creating a new matrix p of the saved

parameters and external inputs concatenated together. This matrix is a vector fi le of single values, not a matrix with

every step included. This is different to how the PE stages ran and the user must be aware of this difference. The

active parameter ‘ap’ is the continuation parameter and is defined as 11 – the 11th entry in ‘p’, which is the elevator

angle input. The choice of continuation parameter should be established here. Next, the state equations are specified,

and nested function ‘@manorig1D’ called to manipulate them into a useable form.

@manoorig1D – this simple function sets the matrix state equations up for use in point by point analysis – ‘dydt’ is the

unintegrated state variables vector. The second function attached in the fi le simply evaluates the state equations over

a time period. This is an attempt to account for the difficult time dependency that is incorporated into the state

equations (A3i)

init_EP_EP – the equations and parameters must be set in the format MATCONT requires. This function defines ea ch

parameter within the global variables that MATCONT recognises, and outputs a single initial condition vector, and a

tangent vector for the starting point.

run_equillibrium_continuation (cont) – the next stage of this function is to establish the options that MATCONT refers

to when initializing its core procedures (Table 5). The continuer stores the handle to the options in ‘cds.options’.

Option Description Value

MaxNumPoints maximum number of points on the curve 100

MaxNewtonIters maximum number of Newton-Raphson iterations before switching to Newton-Chords in the corrector iterations

200

MaxCorrIters maximum number of correction iterations 20

VarTolerance tolerance of coordinates 1e-8

FunTolerance tolerance of function values 1e-8

TestTolerance tolerance of test functions 1e-4

MoorePenrose 1/0 indicating the use of the Moore-Penrose continuation as the Newtonlike corrector procedure

1

Increment the increment to compute first order derivatives

numerically 1e-6

Backward 1/0 indicating the direction of the continuation 0

MaxStepSize the maximum stepsize 3e-2

MinStepSize the minimum stepsize to compute the next point 1e-12

InitStepSize the initial stepsize 1e-12

Eigenvalues 1/0 indicating the computation of the eigenvalues 1

Singularities 1/0 indicating the presence of a singularity matrix 1 Adapt number of points after which to call the adapt-function 1

Table 6 – description of input options for MATCONT from manual [13]

Singularities must be set to 1 as the continuation needs to recognise the Hopf point which will occur when the limit

cycle (LC) starts. MaxNumPoints has a direct correlation with the time taken to process the section, therefore take

care when choosing more points. For the equilibrium continuation, fewer points are required as the local variation is

low.

cont is called next – this is the continuer stored in the MATCONT fi les and has no need to be changed. A call to this fi le

will run a continuation using the options, initial conditions and equations handle, and will output an S structure. The

results are saved and the function ended. The final curve is plotted against the experimental continuation diagram for

reference.

5.2.2 Limit Cycle

run_LC_cont_from_hopf – Since the equilibrium continuation has already been run, the S structure exists and the Hopf

point has been labelled and saved in S.s, meaning the preliminary 65 lines of code can be neglected, as they exist for

cases where the LC has been previously computed. The same continuation code is used to run the sequence; however

the options fi le which is defined in ‘cds’ is different. The Hopf point labels must also be defined so the continuer

knows where to start: ‘ntst’, ‘ncol’ and ‘hopf_pt’ must all be defined by the user and must match the labels given in

the output of the equilibrium continuation. For example, ‘hopf_pt=2’ will cause the ‘x’ solution at the Hopf point with

label 2 to become the starting vector. Once this is done, the continuer must be told that the continuation is periodic

and must be adapted to account for this.

init_H_LC – as well as setting a MATCONT format, an initial cycle from the Hopf point detected on the equilibrium

curve must be calculated. The same tangent vector and initial conditions are outputted, however the 3 labels defined

by the user must be stated in the input.

The continuer is then started again using ‘cont’, the results plotted, and the results saved in >Continuation_results.

PE_control can be followed to make use of the different plotting functions, as well as run a 2 parameter bifurcation

using the last two phases. This concludes the continuation phase of the code, as well as the whole programme. The

user is now left with a parameter fi le with the estimates made by either the OEM or the FEM, data for plotting the

numerical simulation of the state equations, and bifurcation curve that can be overlaid onto exp erimental data.

Having run this code successfully, the user will now have knowledge of several tools that can be extremely useful in

the post processing of dynamical tests on aircraft. The limit to 1DOF in the examples provided by no means is the limit

of either the Parameter Estimation or Continuation code, and many examples exist within the original code from

Jategaonkar [1] and in the MATCONT folder which the user is encouraged to try.

Figure 6 – continuation curve overlaid on experimental data

-18 -16 -14 -12 -10 -8 -6 -4 -25

10

15

20

25

30

35

40

Hawk elevator (deg.)

Pitch a

ngle

(deg.)

Appendix

A1 State Space Formulation – 1DOF

A simple example to help the user grasp the concept of writing equations of motion: example used mirrors the

equations of motion of the manoeuvre rig in [2].

1) Second order ODE that describes a general spring-mass damper

𝐼𝑦𝑦 �� + 𝐶𝜃 �� + 𝐾𝜃 𝜃 = 𝑀

2) This equation is adapted to the manoeuvre rig – the assumptions include zero damping and no friction, and

an inversion changing the moment into its coefficient form.

�� =𝑀

𝐼𝑦𝑦

�� =𝐶𝑀

𝐼𝑦𝑦

=��𝑆𝑐𝑀

𝐼𝑦𝑦

3) A second order variable takes longer to integrate than a first order; therefore the state space form is required

to change the problem to one of the first order. An arbitrary variable y is defined to equal the derivative of

the state variable, then this variable differentiated to equal the double derivative. A third and final equation

�� (see [2]) is added as it is a first order differential equation that can be integrated, and needs to b e referred

to in the same way as the 1DOF variable.

𝑦 = �� = �� =𝐶𝑀

𝐼𝑦𝑦

�� = 𝑓𝑛(𝑋, 𝛼)

4) A single state vector is formed of the three first order differential equations – this is much quicker to

integrate and formulate using MATLAB.

𝑠𝑡𝑎𝑡𝑒 𝑒𝑞𝑢𝑎𝑡𝑖𝑜𝑛𝑠 = [

𝑦 ��

��

] = 𝑥𝑑𝑜𝑡

A2 Administering trails and tests

Trails and tests on the code are l ikely to be desired by the user for both debugging and adaption purposes; however it

is not immediately obvious how to do so. The structure of PE_control means a workspace is not saved in-between

each of its stages – in fact it is entirely internal and functions are written to keep it the programme this wa y. The user

must run functions individually and work around the processing problems that occur.

The first place to start in ‘opening up’ the code is to create a usable workspace:

1) Open the PE_control run fi le (‘run_TC13’), highlight the stage 1 control , right click and select ‘Evaluate

Section’, or press F9. This pre-processes the data to get it into a useable format, and creates the run object to

be sent to the workspace for use by other functions.

2) Open test_Define_case. This function will take the output vector from Define_case and relabel each entry as

an individual variable with the same name. Every function called after Define_case works off some derivation

of these variables therefore anything can be run with a visible output.

Tests can be simply running different functions to see their numerical output: in this case when the function is part of

a loop, other input vectors must be created to simulate the state values at that particular iteration. Individual test fi les

can also be created that extract some key part of the code to run without having to run the entire fi le. Some of these

are l isted below for comparison:

test_xdot_solver

test_run_sim

test_ode

test_Define_case

(21)

(22)

(23)

(24)

A3 Equations and Inputs

Figure 8 – time series of measured inputs in Uinp vector

A4 Definitions

Cost function - A cost function 𝐶(𝑞)is a function of𝑞 , which calculates the minimum cost for producing 𝑞 units.

Handle – A function handle is a MATLAB value that provides a means of call ing a function indirectly .

Measurement noise – the noise in taking measurements of the input values in Uinp.

Procedure noise – the noise inherent to the experiment (turbulence).

0 100 200 300 400 500 600-20

-10

0

Time (s)

de

0 100 200 300 400 500 600

20.4

20.6

Time (s)

Vt

0 100 200 300 400 500 600240

250

260

Time (s)

qbar

0 100 200 300 400 500 600-0.5

0

0.5

Time (s)

dV

t

Figure 7 – ODE solver sequence for example

References

[1] Jategaonkar, R. V. (2006). Flight Vehicle System Identification (1st ed.). American Institute of Aeronautics and Astronautics.

[2] Pattinson, J., Lowenberg, M. H., & Goman, M. G. (2013). Investigation of Poststall Pitch Oscillations of an Aircraft Wind-Tunnel

Model . Journal of Aircraft, 50(6), 1843–1855. doi :10.2514/1.C032184

[3] Pattinson, J. (2010). Development and Evaluation of a Wind Tunnel Manoeuvre Rig, (November).

[4] MATHWORKS. (2015). Cholesky factorization. Available: http://uk.mathworks.com/help/matlab/ref/chol.html. Last accessed

18/8/2015.

[5] Elmer Forsythe, G., Malcolm, M. A., & Moler, C. B. (1977). Computer Methods of Mathematical Computations. (Prentice-Hall,

Ed.) (1st Edi tio., p. 200).

[6] Origl io, Vincenzo. "Stochastic." From MathWorld--A Wolfram Web Resource, created by Eric W. Weisstein. http://mathworld.wolfram.com/Stochastic.html

[7] Weisstein, Eric W. "Riccati Differential Equation." From MathWorld--A Wolfram Web Resource.

http://mathworld.wolfram.com/RiccatiDifferentialEquation.html

[8] Thompson, J. M. ., & Stewart, H. . (2002). Nonlinear Dynamics and Chaos (Second., pp. 106–131).

[9] MATHWORKS. (2015). Object Orientated Programming in MATLAB. Available: http://uk.mathworks.com/discovery/object -

oriented-programming.html. Last accessed 20/06/2015.

[10] Chia -Hui Chen, course materials for 14.01 Principles of Microeconomics, Fall 2007. MITOpenCourseWare (http://ocw.mit.edu),

Massachusetts Institute of Technology

[11] MATHWORKS. (2015). Ordinary Di fferential Equations. Available: http://uk.mathworks.com/help/matlab/math/ordinary-

di fferential-equations.html. Last accessed 08/08/2015.

[12] Welch, G., & Bishop, G. (2006). An Introduction to the Ka lman Filter. In Practice, 7, 1–16. doi :10.1.1.117.6808

[13] W. Govaerts, Y. a . K., & V. De Witte, A. Dhooge, H.G.E. Meijer, W. Mestrom, a . M. R. and B. S. (2011). MATCONT and CL

MATCONT: Continuation toolboxes in matlab. … Gent, Belgium and …, 1–100. Retrieved from

http://uploads.tombertalan.com/12fall2012/502cbe502/hw/hw3/manual.pdf

Parameter Estimation User Guide

Documents

Transcript of Parameter Estimation User Guide