60
'<1$0,&0$12(895(6$1$/<6,6
,QWURGXFWLRQ
When starting to simulate the dynamic manoeuvres new types of flight test techniques were collected and a corresponding input file for every flight record and every TOP were built up. In those input files all the significant parameters were stored and their corresponding values which were recorded concurrently, to make it easier to evaluate the results. As for the analysis of trim conditions, a case.dat file was used as input file for the initial conditions, but a new input file was necessary; the manoeuvre file.
For every condition analysed it was necessary to use and specify a particular manoeuvre file as “match.man”, “turn.man” etc. Manoeuvre Logic subroutines are written by the user to create desktop simulations of specific helicopter manoeuvres. The piloting logic is based on a concept of “piloting goals”; mimicking the methods used by a human pilot to fly complex manoeuvres. A typical manoeuvre subroutine has a structure like this:
Header Block:
Declaration and Data Statements:
Read Manoeuvre input data:
Conversions and initialisation:
Manoeuvre Progress Logic:
Logic for First Piloting Goal:
Collective Channel Logic:
Pitch Channel Logic:
Roll Channel Logic:
Yaw Channel Logic:
Logic for Second Piloting Goal:
Collective Channel Logic:
Pitch Channel Logic:
Roll Channel Logic:
Yaw Channel Logic:
Store local data for next time-step:
From the manoeuvre input file: e.g. catafly.man
Set new piloting goals as manoeuvre progresses and “goto” appropriate code section.
Call Handling Subroutines to achieve the handling goals for each stage of the manoeuvre.
(The manoeuvre may be broken- down into as many “piloting goal”
sections as necessary.)
)LJXUH 0DQRHXYUHVXEURXWLQHVWUXFWXUH
catafly.man. The manoeuvre input filename is specified under the heading 0$12(895(
6(/(&7,21 in the file “case.dat”.
All manoeuvre input data files have a similar format. They consist of:
• Header - With title, version number and date
• Manoeuvre code
• Pitch Attitude Pattern Data
• Roll Attitude Pattern Data
• Collective Channel Input Parameters
• Pitch Attitude Channel Input Parameters
• Roll Attitude Channel Input Parameters
• Yaw Channel Input Parameters
• Simulation Control Parameters
Complex manoeuvre subroutines are normally split into sections, each of which is designed to achieve one stage of the manoeuvre. For example, a take-off might be divided into:
• Initial hover
• Acceleration in level flight
• Climb to TDP
• If engine has failed lower collective to contain rotor droop
As the manoeuvre progresses, the logic uses “triggers” to perform the logic switch. For the take-off example the triggers might be:
• Maintain the initial hover for five seconds (Time is the trigger).
• Accelerate in level flight until 35 KEAS (Airspeed is the trigger)
• Respond to engine failure (recognition of engine failure is the trigger, radar height is used to determine logic)
The choice of trigger parameters and the setting of piloting goals is dictated by the piloting technique, which is normally defined in the rotorcraft flight manual.
62 The piloting goals change as the manoeuvre progresses. If the change in the piloting goal is simply a change in value, for example from one pitch attitude to another, then it is only necessary to change the target value. If the strategy changes, for example from holding a specified pitch attitude to holding a specified speed, then it is also necessary to call a different subroutine.
For the particular case of the match.man manoeuvre, an extra input file is necessary, where data from the flight test was stored in text format as a source. Data was stored for the following parameters: time, collective, pedal, lateral and longitudinal cyclic input, pitch and roll attitude, altitude and torque.
As a compliment to the EUROPA code some dynamic manoeuvre files were already made.
Some of the exiting manoeuvre files are: “turn.man”, “flare.man” and “climdesc.man”, but they would of course not cover all type of dynamic manoeuvres see [16].
As an addition to this a “match.man” (Matching flight test for model validation) file was also available. The purpose of this subroutine is to mimic flight test manoeuvres for model validation and tuning of certain parameters as the engines response. Certain measured flight test parameters are inputs as target values for the pilot model. When run, the piloting logic calculates the control inputs required to duplicate and follow some of the flight test parameters chosen by the user. The simulation input data is adjusted until the simulation and flight test manoeuvres are essentially the same. The accuracy of the simulation was then checked by looking, in detail, at the differences between the simulation and the flight test results.
6WUXFWXUHRIWKHSLORWPRGHO
The EUROPA pilot simulation essentially consists of two types of pilot model subroutine.
For convenience, they are referred to as: the “Manoeuvre Logic”, and the “Handling Subroutines”. The Manoeuvre Logic is a suite of subroutines, each of which is written by the user, to model a specific manoeuvre; for example a Category A airfield takeoff, or a landing on an offshore platform. The Handling Subroutines are subroutines which are called from the Manoeuvre Logic to achieve specific piloting goals; for example to attain and hold a specified airspeed, or to set and hold a specified engine torque.
In normal use the Handling Subroutines are fixed - that is to say that the user should have no need to change the code. On the other hand, the Manoeuvre Logic is variable and new subroutines will be written by the user whenever it is required to model a new manoeuvre - or modified by the user whenever it is necessary to change the way in which a manoeuvre is “flown”. Examples of this work will follow below.
The piloting logic is called at each simulation time-step in order to calculate the control positions. The main pilot model subroutine calls the manoeuvre selection subroutine MANOV.F.
Subroutine MANOV calls a different Manoeuvre Logic subroutine for each manoeuvre to be simulated. The user selects which manoeuvre will be flown by specifying an appropriate manoeuvre file (e.g. turn.man) under the heading “0$12(895( 6(/(&7,21” in the case.dat input file. At the top of the manoeuvre input file there is a “manoeuvre code”
number which is read into the variable IMAN and used in subroutine MANOV to select which of the Manoeuvre Logic subroutines will be called.
The pilot simulation assumes that the piloting task can be separated into four separate sub- tasks, one for each major control function: fore/aft cyclic, lateral cyclic, yaw-pedals and collective. At any time, the pilot will be aiming to achieve a particular piloting goal with each control. For example, the collective may be adjusted to hold height, to set and hold a specified engine torque, or to control rotor speed (post engine failure) etc., whilst the
64 fore/aft cyclic may be used to control attitude, speed, or height. Note that each of these piloting tasks aims to achieve a specific piloting target value (a height, speed or attitude etc.). A “handling subroutine” has exist to mimic the piloting activity required to achieve each goal.
The input to the piloting logic is both the piloting goal (what the pilot is trying to achieve) and the “state” information of the helicopter (what the helicopter is actually doing). Like a human pilot, the simulated pilot moves the flying controls in an attempt to minimise the difference between the “actual” position or state of the helicopter and the “target values”.
The output from the pilot model is the position, at each time step of the simulation, of the four main flying controls:
• the fore/aft cyclic stick position
• the lateral cyclic stick position
• the yaw-pedal position
• the collective stick position
3LORW0RGHO&RQYHQWLRQV
The pilot model controls the simulation by means of feedback control algorithms. Error- signals are generated by finding the difference between target values and the current
“achieved” values. The main “control parameters” and their conventions are given below.
First we will define the EUROPA axis system, which is right hand, X-forward, Y to starboard, and Z-down. The aircraft velocity can be resolved into components along each of the orthogonal aircraft axes. The true air velocities are UAC along the X-axis, VAC along the Y-axis, and WAC along the Z-axis.
X
Y Z
uac
wac vac
)LJXUH (8523$D[LVV\VWHP
The fuselage attitude angles are defined by the displacement between the aircraft axes and a terrain or “world” axis system which moves with the aircraft but remains horizontal. The aircraft heading is the angle in the horizontal plane, between the aircraft X-axis and the
“world” North direction.
66
THETAF
PHIF
)LJXUH )XVHODJHDWWLWXGHDQJOHV
The pilot “target” values are defined in exactly the same way as the aircraft attitude angles.
The feedback control logic moves the flying controls so as to minimise the difference between the target value and the “achieved” value. The sign convention for the flying controls is such that a positive control displacement will result in a positive (right hand rule) rotation about the aircraft axes.
Note, however, that a positive movement of the collective lever increases the main rotor thrust and produces an acceleration which is in the negative Z-direction.
Fuselage attitude control:
$LUFUDIW 7DUJHW 6LJQ&RQYHQWLRQ &RQWURO &RQWURO&RQYHQWLRQ
3LWFK THETAF THEG Nose-up ETAFP Stick back
5ROO PHIF PHIG Right wing down ETALP Stick to right
<DZ HDG HDGR Compass ETARP Right pedal forward
7DEOH)XVHODJHDWWLWXGHFRQWURO
The fuselage rates are defined as right-hand rotations about each axis. Positive movements of the flying controls are intended to result in positive angular accelerations.
X
Y
Z QAC PAC
RAC ETAFP
ETALP
+
+
Cyclic Stick.
)LJXUH )XVHODJHUDWHV
In EUROPA, the flying controls have non-dimensional displacements. The collective stick position can have any value in the range 0 to 1, with 1 being lever full UP. The fore and aft cyclic lever position can have any value in the range -1 to +1, where -1 corresponds to lever full forward (nose-down) and + 1 is lever fully aft. The lateral cyclic stick position can have any value between -1 and +1, with -1 corresponding to a fully left lever position (roll to port) and +1 being fully right (aircraft right roll). The yaw-pedal position can have any value between -1 (left foot forward to swing the nose to port) and +1 (right foot forward - nose to starboard).
68
)HHGEDFNFRQWUROORJLF
The pilot model uses feedback control algorithms to calculate the required flying control displacements. The feedback controllers are almost always of the error, rate and integral type. Each of the handling subroutines is called with a target value, which is normally set immediately before the handling subroutine call. An error signal is generated within the handling subroutine by subtracting the value of the controlled parameter from the target value.
For example: if aiming for a specified vertical speed, the target vertical speed (Z1D - meaning Z one-dot demanded) would be set in the Manoeuvre Logic and the appropriate handling subroutine (DEMZ1) would be called. The error signal in this case would be the target vertical speed minus the helicopter’s achieved vertical speed (Z1), thus: ERROR = Z1D - Z1
Next, the rate of change of the error signal is found (ERRDOT). ERRDOT is used to increase the size of the control input if the error is increasing and decrease the size of the control input if the error is decreasing. This makes the model more responsive and greatly improves the stability by minimising overshoots due to over-control.
With some types of controller small errors can persist. This only occurs if the basic error signal results in a control displacement which fails to close the error. If this proves to be a problem the error signal can be integrated with time (SUMERR) so that the control is further deflected until any small offset is eliminated.
Many of the EUROPA handling subroutines use several levels of feedback controller and include other limits (such as maximum target attitudes and maximum attitude-rates). It is normally the case that EUROPA feedback controllers calculate a control-lever movement- rate, rather than an absolute control position. The control-lever movement-rate is then integrated within the handling subroutine to find the control position. With this type of control algorithm, if there is no error the controls do not move.
ERROR*GAIN1 + ERRDOT*GAIN2 + SUMERR*GAIN3
The values of GAIN1 GAIN2 and (if used) GAIN3 are chosen to give good control and a stable response. In general, increasing the value of GAIN1 will make the control “tighter”
with less tolerance of error - but also less stable. If GAIN1 is too large both the control, and the controlled parameter, will tend to oscillate (over-control). The value of GAIN2 is chosen (usually by trial and error) to improve both the stability and the response to uncommanded (and unwanted) motions (such as the response to gusts or the motion which results from the secondary effects of other control inputs).
Piloting logic gains input file:
PILOTING LOGIC MODEL: EUROPA A109 HELICOPTER - GAINS VERSION: 98.5.4.3, DATED: 06/02/06
0.2D0 0.101D0 -0.915D0 -0.011D0 FCG1,FCGD1,FCG2,FCGD2 Gains for FLYCAS logic 0.1D0 0.001D0 -0.015D0 -0.001D0 FEG1,FEGD1,FEG2,FEGD2 Gains for FLYEAS logic 0.3D0 1.0D0 FHG1,FHG2 Gains for FLYHDG logic
4.0D0 2.0D0 3.0D0 3.5D0 FPG1,FPGD1,FPG2,FPGD2 Gains for FLYPAT logic
2.05D0 3.0D0 1.0D0 4.0D0 5.0D0 FRG1,FRGD1,FRG2,FRGD2,FRGI2 Gains for FLYROL logic 0.8D0 0.2D0 0.8D0 0.2D0 0.02D0 0.02D0 FSG1,FSD1,FSG2,FSGD2,FSGI1,FSGI2
Gains for FLYYSPOT logic
-1.0D0 -1.0D0 2.0D0 2.0D0 FTG1,FTGD1,FTG2,FTGD2 Gains for FLYTRK logic 1.0D0 2.0D0 -0.1D0 -0.03D0 FUG1,FUGD1,FUG2,FUGD2 Gains for FLYUGS logic 1.0D0 1.0D0 0.1D0 0.01D0 FVG1,FVGD1,FVG2,FVGD2 Gains for FLYVGS logic 0.5D0 0.0D0 0.5D0 0.02D0 FDG1,FDGD1,FDG2,FDGD2 Gains for PEDALS logic -10.0D0 -5.0D0 -2.0D0 FLG1,FLG2,FLG3 Gains for PEDBAL logic
3.0D0 1.5D0 FQG1,FQG2 Gains for SETTQ logic -.02D0 -0.05D0 FCZ1,FCZ2 Gains for DEMZ1 logic
)LJXUH 3LORWLQJORJLFJDLQVLQSXWILOH
See also Appendix F for a brief description of the helicopter simulation model.
70
+DQGOLQJVXEURXWLQHV
The handling subroutines calculate the control movements required to achieve specified piloting goals. They are called from the Manoeuvre Logic and call each other (for example the subroutine to hold height calculates a vertical speed requirement and calls the subroutine which calculates the collective movements needed to minimise the vertical speed error). The handling subroutines can conveniently be grouped according to the
“control-axis” to which they belong.
&ROOHFWLYH
From the piloting point of view, the collective can be seen as an “energy” or power control lever. In the hover, and in low speed flight, it is generally used to control the vertical speed. Although, when hovering in-ground-effect, there is a correlation between the stick position and the aircraft’s height, collective is not normally used directly as a height control; the pilot senses a height error and adjusts the collective so as to establish a small vertical speed which will smoothly eliminate the error.
In forward flight (in the cruise at altitude) and when climbing, the collective is used to set the required engine torque. When descending to land, the collective is used to adjust the vertical speed so as to achieve the necessary approach slope.
In the sections below, each of the collective channel Handling Subroutines are described briefly.
+ROG&ROOHFWLYH6WLFN&RQVWDQW6XEURXWLQH&21&2/
This very simple subroutine is called to hold the collective stick constant. It is often used after an engine failure and before the pilot intervenes. There are no input parameters.
9HUWLFDO6SHHG6XEURXWLQH'(0=
DEMZ1 may be called directly from the Manoeuvre Logic, or from other handling subroutines.
+HLJKW+ROG6XEURXWLQH'(0=
Subroutine DEMZ is used to adjust the collective so as to attain and maintain either the helicopter’s radar height (i.e. the height above the ground ) or the altitude (i.e. the pressure altitude). DEMZ is normally called directly from the Manoeuvre Logic.
DEMZ calculates a demanded vertical speed and then calls subroutine DEMZ1 (see also above).
! #"
100 ft 30.5 m
-100 ft -30.5 m -5 m.s-1
-1000 ft/min
5 m.s-1 1000 ft/min (Too High)
(Too Low)
(Descend) (Climb)
Initial Rate of Descent too high: Decrease R.O.D.
Maintain R.O.D.
Increase R.O.D.
)LJXUH '(0=ORJLFZRUNLQJSURFHVV
The target vertical speed is adjusted as a function of the height error, in order to bring the helicopter smoothly to the target altitude.
72
5RWRU6SHHG&RQWURO6XEURXWLQH'(015
Subroutine DEMNR is used to adjust the collective so as to control the rotor speed.
DEMNR is normally called directly from the Manoeuvre Logic, after the Pilot Intervention Delay Time, following an engine failure. It is also called during autorotation.
(QJLQH7RUTXH&RQWURO6XEURXWLQH6(774
Subroutine SETTQ is used to adjust the collective so as to set and hold a specified engine torque. SETTQ is normally called directly from the Manoeuvre Logic to establish a climb or cruise condition. The number two engine torque is used, because, in EUROPA, the number one engine is the engine which is failed.
)RUH$IW&\FOLF
The fore/aft cyclic stick logic is used to control the helicopter’s pitch attitude, and via the pitch attitude, the airspeed, the groundspeed, and the helicopter’s position when in the hover.
3LWFK$WWLWXGH+ROG6XEURXWLQH)/<3$7
Subroutine FLYPAT is used to attain and hold a specified fuselage pitch attitude.
Internally within the subroutine, the cyclic stick is adjusted by means of feedback control logic which works on the fuselage pitch-rate, rather than the attitude. That is to say that the logic assumes that the stick is fundamentally a rate controller. However, the user only has to specify a target attitude, the maximum pitch-rate and the maximum pitch acceleration to be used. The rate and acceleration limits are used to “shape” the attitude change.
$LUVSHHG+ROG6XEURXWLQH)/<&$6
Subroutine FLYCAS is used to attain and hold a specified airspeed. Internally within the subroutine, a target pitch attitude is generated so as to give a small rate of change of airspeed which will tend to eliminate the speed error. Subroutine FLYPAT is called from subroutine FLYCAS to find the longitudinal cyclic required to attain and hold the necessary attitude.
Subroutine FLYCAS is normally called directly from the Manoeuvre Logic, so as to achieve a specified target airspeed. The maximum target fuselage pitch-rate and the maximum target fuselage pitch-acceleration must also be supplied, together with the maximum fuselage nose-up attitude and nose down attitude.
The input parameters are used to control the shape and aggressiveness of the speed change manoeuvre. Note that too small values of pitch-rate and pitch-acceleration can make the speed hold logic unstable. The maximum nose-up attitude limits the rate of change of airspeed when slowing down. At high airspeed, a large nose-up attitude can cause the
74 helicopter to go into autorotation - the limit being the maximum permissible rotor speed without climbing. At low airspeeds the limit is generally pilot or passenger comfort and pilot view. When accelerating, the nose-down attitude is generally limited by piloting and power considerations.
*URXQGVSHHG+ROG6XEURXWLQH)/<8*6
Subroutine FLYUGS is used to attain and hold a specified longitudinal component of groundspeed. The logic is similar to that used by subroutine FLYEAS, except that groundspeed is used instead of airspeed. FLYUGS is called directly from the Manoeuvre Logic and may also be called from other handling subroutines - for example to hold position (hover in a fixed position, relative to the terrain).
/DWHUDO&\FOLF
The lateral cyclic stick logic is used to control the helicopter’s roll attitude and, via the roll attitude, the heading, lateral groundspeed, and the helicopter’s position when in the hover and at low speeds (for example, when tracking along a runway centreline).
5ROO$WWLWXGH+ROG6XEURXWLQH)/<52/
Subroutine FLYROL is the most fundamental of all the lateral cyclic control subroutines.
It can be called directly from the Manoeuvre Logic, but it is also called from all of the other lateral Handling Subroutines. The piloting logic assumes that the pilot will achieve all of the lateral piloting goals by rolling the helicopter to whatever bank angle is appropriate. The cyclic stick is always moved to achieve the necessary roll-rate.
+HDGLQJ+ROG6XEURXWLQH)/<+'*
It is called directly from the Manoeuvre Logic. It calculate the bank angle required to attain and maintain a specified heading - and then call subroutine FLYROL.
/DWHUDO*URXQGVSHHG+ROG6XEURXWLQH)/<9*6
Subroutine FLYVGS may be called directly from the Manoeuvre Logic or from other handling subroutines. It operates by finding the roll attitude required to attain and hold a specified lateral ground speed and then calling subroutine FLYROL.
By making the lateral groundspeed a function of lateral position error, FLYVGS can be made a part of the hover position holding logic. See also Subroutine FLYSPOT.
*URXQG7UDFN+ROG6XEURXWLQH)/<75.
Subroutine FLYTRK may be called directly from the Manoeuvre Logic or from other handling subroutines. It requires that the ground track to be followed lies along the Y=0
76 line, passing through the terrain origin. Subroutine FLYTRK calculates the roll attitude required to stay on the specified ground track and then calls subroutine FLYROL.
3HGDOV
The yaw pedals are used in two ways: in the hover and in low-speed flight they are used to attain and maintain a specified heading; in forward flight the pilot adjusts the yaw pedals so as to maintain the helicopter in “co-ordinated flight” - i.e. with no mean lateral acceleration. The low speed case is simple to understand, but the high speed case is more complex. Basically the aim is to have the helicopter fuselage x-axis pointing into the local airflow (rather than flying sideways). In practice, helicopter pilots use a “slip-ball”, which detects lateral acceleration, to indicate whether the helicopter is “slipping” or “skidding”.
+HDGLQJ+ROG6XEURXWLQH3('$/6
Subroutine PEDALS is called from the Manoeuvre Logic to attain and hold a specified heading. The yaw-pedals are adjusted, to point the fuselage x-axis in a particular direction.
This subroutine is normally called only when the helicopter is in the hover or in low speed flight.
&HQWUH6OLS%DOO6XEURXWLQH3('%$/
Subroutine PEDBAL is called from the Manoeuvre Logic to maintain co-ordinated flight.
This is achieved by making the lateral acceleration as small as possible.
Subroutine PEDBAL has no user defined input parameters.
78
&RPELQHG+DQGOLQJ7DVN6XEURXWLQHV
Some standard handling tasks require control in more than one axis.
+RYHU$ERYHD6SHFLILHG6SRW6XEURXWLQH)/<6327
Subroutine FLYSPOT is normally called directly from the Manoeuvre Logic. It operates by finding the longitudinal and lateral components of ground speed required to bring the helicopter over a selected spot on the ground and then calling subroutines FLYUGS and FLYVGS.
(QJLQHFKHFN
To examine whether the actual engine model for the EUROPA code was functioning properly an engine check was necessary. This was supposed to be carried out before the simulation of the dynamic manoeuvres, because, first of all, it was of great importance that the engine model was considered to be running accurately. Flight test data were collected where engine failures or engines checks were simulated. In those cases the power setting was reduced to either Training mode, OFF or IDLE position. IDLE meaning cutting all the power to zero on one engine without turning it off as in OFF position, while Training mode simulates an engine failure with both the engines operative. OFF and IDLE position flight test tops were chosen. An engine failure by meaning is to apply a normal pilot reaction time and ensure that the main rotor NR does not decrease below OEI limit (90%). There should be no difference noted between the performance on the left and right hand engines and consequently the test was done on both engines.
A certain amount of engine failure control flight tests were collected and examined. In those tests level flight conditions with different speeds from 50 kts up to 127 kts were performed at different altitudes, from 2500 ft to 18000 ft. During those tests either Engine 1 or Engine 2 was cut out. To see how accurate the EUROPA code could match the flight test Torque 1, Torque 2 and the main rotor NR versus time, was plotted in a graph, see Figure.
What happens when one engine is cut “out” is that it drops down in percentage of Torque and the engine “alive” make an effort to recover the power that was lost. So the engine
“out” goes down to zero percent of Torque and the engine “alive” increase the same amount of Torque. Simultaneously whilst one engine is cut out, the main rotor Nr drops down, but as the engine alive recovers for the power loss the main rotor NR can also pick up back to 100% unless there is a power limit due to high altitude and high temperature.
When both engines are operational again they will struggle to reach the same value of percentage of Torque, and from there on work together.
80
0 10 20 30 40 50 60
0 10 20 30 40 50 60 70 80 90 100 110
Limited Engine check Torque and Nr vs Time
15000 ft 52 CAS
Time
Torque
True Engine 1 True Engine 2 True Nr
Simulated Engine 1 Simulated Engine 2 Simulated Nr
(QJLQH IDLOXUHRI$
[s]
[%] Nr [%]
0 5 10 15 20 25 30 35 40 0
20 40 60 80 100 120 140
Limited Engine check Torque and Nr vs Time
8800 ft 100 CAS
Time
Torque
True Engine 1 True Engine 2 True Nr
Simulated Engine 1 Simulated Engine 2 Simulated Nr
(QJLQH (QJLQHIDLOXUHZLWKDWRUTXHOLPLWDWLRQ
The maximum power available for the specific flight tests were calculated by the 2.5 minute Level flight OEI (100% NR) rating, depending on the temperature and the altitude.
First of all a level flight trim condition was simulated before the engine failure. The AEO delta in Torque between the calculated results and the true results were observed. In reality this was actually two deltas as there were two engines and both deltas were later supposed to correspond to one delta in OEI.
The parameters in the engine file that were optimised were the Nr to PGOV feedback gains and the Max spool-up and run down rates. A new parameter in the engine file was introduced, called the Decay constant for failure. This was mainly done to get the ability to effect the slope of the “Engine out”, but it also affected the “Engine Alive” at the same time, as a complementary effect. Since none of the other variables could make this modification, this parameter was introduced as an input in the engine file. It was necessary
[s]
Nr [%] [%]
82 to made it a variable because before this modification, was just a constant inside the code.
It was seen that the Nr to PGOV feedback gains were effecting both the Nr and the Torque simultaneously. The time for actual engine failure was decided in the “match.man” file, where the whole engine failure was simulated. The response of the engines was initially a bit too fast so that was slowed down. Finally, it was understood that the code was calculating sufficient truthful results, it was just a matter of presentation in the plots.
Because is not possible a perfect match in torque starting from a level flight trim condition, some shifting was required for the Torques before the engine failure and also after the engine failure, which was made in the Matlab file, utilising a multiplier factor.
0DWFKPDQ
The purpose of this subroutine is to mimic flight test manoeuvres for model validation.
A copy of the “match.man” manoeuvre input file is listed below:
PILOTING LOGIC – MATCH
VERSION: 98.6.4.5, DATED: 06/02/15 0 : Manoeuvre Code
Pitch attitude pattern data.
~~~~~ ~~~~~~~~ ~~~~~~~ ~~~~
1
0.0 2.0 2.5 ! 1 - Attitude hold
Roll attitude pattern data.
~~~~ ~~~~~~~~ ~~~~~~~ ~~~~
1
0.0 5.0 7.0 ! 1 - Attitude to hold
Collective channel parameters.
~~~~~~~~~~ ~~~~~~~ ~~~~~~~~~~
1 ! Hold specified vert. vel.(=2); follow collective(=1), follow height/Nr(=0) 0.0 ! Lead time for collective trace following (s)
0.0 ! Lead time for height following logic (s) 1.0 ! Pilot intervention delay time (s)
0 ! Post Eng. Fail.: 0 Follow radalt trace, 1 Hold target Nr 100.0 ! Target Nr post engine failure (%)
5.32 ! Specified vertical velocity, +VE down (m/s)
Pitch channel parameters.
~~~~~ ~~~~~~~ ~~~~~~~~~~
0.3 ! Lead time for pitch attitude following logic (s) -0.5 ! Delta pitch attitude (deg)
Roll channel parameters.
~~~~ ~~~~~~~ ~~~~~~~~~~
0 ! 0:Follow flight test roll, 1:Hold lateral position 0.3 ! Lead time for roll attitude following logic (s) 0.0 ! Delta roll attitude (deg)
Yaw channel parameters.
~~~ ~~~~~~~ ~~~~~~~~~~
1 ! 0:Hold initial heading, 1:Fly ball centred
Simulation control parameters.
~~~~~~~~~~ ~~~~~~~ ~~~~~~~~~~
f517ma15.inp ! Input data file
0.0 ! Time to be skipped from flight test (s) 130.0 ! Time for engine failure (s)
0.0 ! Flight test height trace offset
Read simulation parameters.
~~~~ ~~~~~~~~~~ ~~~~~~~~~~
GKN ! Type of flight test data ('GKN' or 'SEE').
84
11 ! Number of simulation parameters.
2 0.01 ! Collective parameter number and conversion factor to fraction of total range.
8 0.3048 ! Radalt parameter number and conversion factor to meters.
6 0.01745329 ! Pitch attitude parameter number and conversion factor to rad.
7 0.01745329 ! Roll attitude parameter number and conversion factor to rad.
)LJXUH 7\SLFDO0DWFKPDQILOH
Certain measured flight test parameters are inputted as target values for the pilot model.
When run, the piloting logic calculates the control inputs required to duplicate the flight test manoeuvres. The simulation input data is adjusted by the user until the simulation and flight test manoeuvres are essentially the same. The accuracy of the simulation may then be checked by looking, in detail, at the differences between the simulation and the flight test results.
Usually the requirements in the file were to follow the collective and the roll movement of the flight test. The simulation “collective” was driven by the collective stick movements measured in flight. The collective movements are relative to the initial “trim” stick position, rather than absolute values. No other collective input parameters were required, other than a “lead time for collective trace following”; which may or may not be required to align the simulation and flight test collective traces and a delta attitude.
Some of the other requirements that stood out in the file are described below:
3LWFK$WWLWXGH&KDQQHO
The simulation uses the measured (flight test) pitch attitude as a target value. The pitch-rate and pitch-acceleration values in the “Pitch attitude pattern data” at the top of the manoeuvre input file (match.man) could be set to a large value, so that they do not limit the manoeuvre. Under the “Pitch channel parameters” heading, the
“lead time for pitch attitude following logic” should be given a value which aligns the simulation and flight test traces.
$WWLWXGH
7LPH
Apply a time lead to eliminate this time lag.
A small “delta” pitch attitude may be required to improve the speed match.
6,08/$7,21
)/,*+77(67
)LJXUH 3LWFKDWWLWXGH
It was discovered that the pitch attitude may be shifted up or down by a small amount to improve the speed match. The aim is to make the simulated manoeuvre look as similar to the flight test manoeuvre as possible. It is much better to have a small (but constant) pitch attitude error than an ever increasing speed error because, as soon as the speed is wrong, the airloads, power required and flight path will all diverge. (The delta pitch attitude required to align the speed traces was input under the “3LWFKFKDQQHOSDUDPHWHUV” heading in “match.man”.)
5ROO$WWLWXGH&KDQQHO
In a similar way to that described above for the pitch channel, a time lead should be input under “Roll channel parameters”, to eliminate any time lag between the simulated and measured roll attitude traces.
<DZ&KDQQHO
86 As currently implemented, the yaw channel logic adjusts the yaw pedals to maintain the initial heading or maintain the slip-ball centred. There are no input parameters.
6LPXODWLRQ3DUDPHWHUV
As described earlier, under this heading is the flight test data filename, and the time lead to synchronise the simulation and flight test engine failure times. The height offset parameter allows the user to add or subtract a constant value from the flight test height data. For example if the helicopter is hovering 10 meters above the ground, but the ground is 300 meters above sea-level, the flight test trace might read 310. So that the simulation ground effect model works correctly, the simulation should be set-up at 10. To match the flight test, an offset value of 300 should be used.
$ERXWWKHPDWFKLQJ
The method of matching flight test data is something of an art. The most basic form of match is produced by: following the flight test pitch attitude data, following the runway centreline, mimicking the collective stick movements, and either holding the heading or centring the slip-ball. However, the most suitable method will obviously depend upon the manoeuvre to be copied.
It is almost always necessary to apply an offset to the pitch attitude in order to give a good speed match, see Figure and Figure. A small positive number will reduce the simulation speed and a small negative number will increase it. Because a helicopter’s power required is so strongly dependent upon the flight speed, it is vital to adjust the pitch attitude to give as close a speed match as possible.
Although height following can be used when matching, this does not normally give as good results as collective movement following. Note that engine torque is strongly influenced by movement of the collective stick and a very good match to the torque variations can often be achieved by following the measured collective stick motion.
right turns, a climb, a flare, a deceleration and a manoeuvre with an acceleration and than two turns (left and right) at different speeds and altitude. The results were extremely satisfactory as can be seen from the subsequent figures.
Worthy of note is the collective channel in the Flare manoeuvre. Unlike the others manoeuvres it was necessary to follow the height instead of collective.
In the subsequent figures blue represent flight test data while green simulated data.
88
0 5 10 15 20
0 50 100
Time [sec]
Torque [%]
0 5 10 15 20
0 50 100
Time [sec]
Collective [%]
0 5 10 15 20
0 50 100
Time [sec]
Pedal [%]
0 5 10 15 20
0 50 100
Time [sec]
Longitudinal [%]
0 5 10 15 20
0 50 100
Time [sec]
Lateral [%]
0 5 10 15 20
1850 1900 1950 2000 2050
Time [sec]
Altitute [ft]
0 5 10 15 20
−40
−20 0
Time [sec]
Roll [deg]
0 5 10 15 20
−4
−2 0 2
Time [sec]
Pitch [deg]
0 2 4 6 8 10 12 14 16 18 20
115 120 125 130
Time [sec]
CAS [Kn]
)LJXUH /HIWWXUQVLPXODWHGZLWK³PDWFKPDQ´
0 5 10 15 20 0
50 100
Time [sec]
Torque [%]
0 5 10 15 20
0 50 100
Time [sec]
Collective [%]
0 5 10 15 20
0 50 100
Time [sec]
Pedal [%]
0 5 10 15 20
0 50 100
Time [sec]
Longitudinal [%]
0 5 10 15 20
0 50 100
Time [sec]
Lateral [%]
0 5 10 15 20
1900 1950 2000 2050
Time [sec]
Altitute [ft]
0 5 10 15 20
0 20 40
Time [sec]
Roll [deg]
0 5 10 15 20
−2 0 2
Time [sec]
Pitch [deg]
0 2 4 6 8 10 12 14 16 18 20
115 120 125 130
Time [sec]
CAS [Kn]
)LJXUH 5LJKWWXUQVLPXODWHGZLWK³PDWFKPDQ´
90
0 5 10
0 50 100
Time [sec]
Torque [%]
0 5 10
0 50 100
Time [sec]
Collective [%]
0 5 10
0 50 100
Time [sec]
Pedal [%]
0 5 10
0 50 100
Time [sec]
Longitudinal [%]
0 5 10
0 50 100
Time [sec]
Lateral [%]
0 5 10
1800 2000 2200
Time [sec]
Altitute [ft]
0 5 10
−2 0 2
Time [sec]
Roll [deg]
0 5 10
0 2 4
Time [sec]
Pitch [deg]
0 1 2 3 4 5 6 7 8 9 10
75 80 85 90
Time [sec]
CAS [Kn]
)LJXUH &OLPEVLPXODWHGZLWK³PDWFKPDQ´
0 20 40 20
40 60 80
Time [sec]
Torque [%]
0 20 40
0 20 40 60
Time [sec]
Collective [%]
0 20 40
20 40 60
Time [sec]
Pedal [%]
0 20 40
20 30 40 50
Time [sec]
Longitudinal [%]
0 20 40
30 40 50
Time [sec]
Lateral [%]
0 20 40
0 100 200
Time [sec]
Altitute [ft]
0 20 40
−10
−5 0 5
Time [sec]
Roll [deg]
0 20 40
0 5 10
Time [sec]
Pitch [deg]
0 10 20 30 40 50
0 20 40 60
Time [sec]
CAS [Kn]
)LJXUH )ODUHVLPXODWHGZLWK³PDWFKPDQ´
92
0 10 20 30
0 50 100
Time [sec]
Torque [%]
0 10 20 30
0 50 100
Time [sec]
Collective [%]
0 10 20 30
0 50 100
Time [sec]
Pedal [%]
0 10 20 30
0 50 100
Time [sec]
Longitudinal [%]
0 10 20 30
0 50 100
Time [sec]
Lateral [%]
0 10 20 30
1.91 1.92 1.93 1.94x 104
Time [sec]
Altitute [ft]
0 10 20 30
−4
−2 0 2
Time [sec]
Roll [deg]
0 10 20 30
2 4 6 8 10 12
Time [sec]
Pitch [deg]
0 5 10 15 20 25 30 35
50 60 70 80
Time [sec]
CAS [Kn]
)LJXUH 'HFHOHUDWLRQVLPXODWHGZLWK³PDWFKPDQ´
0 50 100 0
50 100
Time [sec]
Torque [%]
0 50 100
0 50 100
Time [sec]
Collective [%]
0 50 100
0 50 100
Time [sec]
Pedal [%]
0 50 100
0 50 100
Time [sec]
Longitudinal [%]
0 50 100
0 50 100
Time [sec]
Lateral [%]
0 50 100
1.8 1.9 2
x 104
Time [sec]
Altitute [ft]
0 50 100
−20 0 20
Time [sec]
Roll [deg]
0 50 100
0 2 4
Time [sec]
Pitch [deg]
0 20 40 60 80 100 120
60 70 80 90 100 110
Time [sec]
CAS [Kn]
)LJXUH $FFHOHUDWLRQULJKWDQGOHIWWXUQGXULQJGHVFHQWVLPXODWHGZLWK³PDWFKPDQ´
94
7XUQ
The “turn.man” is a true manoeuvre file compared to the “match.man” which only tries to mimic flight test manoeuvres. It is built up in a similar way as the “match.man” with pitch, roll and collective channels, though it has less input. It is probably one of the simplest already existing manoeuvre files. While match.man just try to follow some “true” available input data coming from flight tests, turn.man put targets for the channels logics.
For the turn several flight test records were collected and examined which were containing coordinated turns as left bank –40° and as well right bank 40°, see subsequent figures. The required inputs for this manoeuvre were the pitch and the roll attitude channels.
PILOTING LOGIC - TURN
VERSION: 98.5.2.1, DATED: 06/02/23 2 : Manoeuvre Code
Pitch attitude pattern data.
~~~~~ ~~~~~~~~ ~~~~~~~ ~~~~
2
10.1 10.0 10.0 ! 1 - Initial level flight 5.0 0.1 1.0 ! 2 - turn
Roll attitude pattern data.
~~~~ ~~~~~~~~ ~~~~~~~ ~~~~
2
0.0 0.0 0.0 ! 1 - Maintain runway centre line 10.0 6.0 10.0 ! 1 - turn
Collective channel parameters.
~~~~~~~~~~ ~~~~~~~ ~~~~~~~~~~
Pitch channel parameters.
~~~~~ ~~~~~~~ ~~~~~~~~~~
Roll channel parameters.
~~~~ ~~~~~~~ ~~~~~~~~~~
40.0 ! Bank angle (deg)
Yaw channel parameters.
~~~ ~~~~~~~ ~~~~~~~~~~
Simulation control parameters.
~~~~~~~~~~ ~~~~~~~ ~~~~~~~~~~
0.5 ! Time to stabilize initial trim condition (s)
)LJXUH 7\SLFDO7XUQPDQILOH
capability to mimic the flight test in all aspects, meaning that all significant parameters were matching accurate enough, even if the piloting logic is totally different. Worth to be mentioned is that the mimic of the roll is a great result of a very good functioning mathematical model. One of the drawbacks of the manoeuvre file was that it only could handle one turn at the time and not multiple turns.
Tests were made to improve the accuracy of the turn.man. The Yaw channel was modified to fly with the slip-ball centred instead to maintain the initial trim pedals position. Another modification was due to the non-perfect flight test results. The turn had to be done without a vertical speed, but this is not the case, so it was necessary to modify the collective channel logic to attain a specific vertical speed instead to fly at constant altitude/height.
96
0 5 10 15 20
0 50 100
Time [sec]
Torque [%]
0 5 10 15 20
0 50 100
Time [sec]
Collective [%]
0 5 10 15 20
0 50 100
Time [sec]
Pedal [%]
0 5 10 15 20
0 50 100
Time [sec]
Longitudinal [%]
0 5 10 15 20
0 50 100
Time [sec]
Lateral [%]
0 5 10 15 20
1900 1950 2000 2050
Time [sec]
Altitute [ft]
0 5 10 15 20
0 20 40
Time [sec]
Roll [deg]
0 5 10 15 20
−2 0 2
Time [sec]
Pitch [deg]
0 2 4 6 8 10 12 14 16 18 20
115 120 125 130
Time [sec]
CAS [Kn]
)LJXUH 5LJKWEDQNHGWXUQVLPXODWHGZLWK³WXUQPDQ´
0 5 10 15 20 0
50 100
Time [sec]
Torque [%]
0 5 10 15 20
0 50 100
Time [sec]
Collective [%]
0 5 10 15 20
0 50 100
Time [sec]
Pedal [%]
0 5 10 15 20
0 50 100
Time [sec]
Longitudinal [%]
0 5 10 15 20
0 50 100
Time [sec]
Lateral [%]
0 5 10 15 20
1850 1900 1950 2000 2050
Time [sec]
Altitute [ft]
0 5 10 15 20
−40
−20 0
Time [sec]
Roll [deg]
0 5 10 15 20
−4
−2 0 2
Time [sec]
Pitch [deg]
0 2 4 6 8 10 12 14 16 18 20
115 120 125 130
Time [sec]
CAS [Kn]
)LJXUH /HIWEDQNHGWXUQVLPXODWHGZLWK³WXUQPDQ´
98
)ODUH
The flare manoeuvre is also a true manoeuvre file as the turn file. The flare is by means a manoeuvre to stop the helicopter when flying converting kinetic energy into maintaining potential energy. That means that all longitudinal, lateral and vertical velocities should be zero. To perform this complex manoeuvre some effort it is required by the pilot, as a lot of control inputs are required.
To run the flare cases corresponding flight test records were collected and as in the same manner for the other dynamic manoeuvres the significant parameters were plotted, see Figure. All optimisations were done in the “flare.man” file and nothing in the input files for the A109 helicopter. Not surprisingly the “flare.man” file is a little bit more sophisticated than the other manoeuvres, depending on its complexity in the manoeuvre.
