F-22 pitching up at initialization #604

m-ple · 2022-03-17T13:59:06Z

m-ple
Mar 17, 2022

Hello team,

I am new to JSBSim and experiencing a problem with the F-22 (that I must use for a project).

With the gear up, and all commands set to zero, the airplane is constantly pitching up when I start a flight with speed and altitude.
Modifying the .xml file to prevent the FCS from reacting doesn't change a thing: the aircraft pitches up until it reaches very high AoA and then stalls. Even with thrust vectoring control, elevator, tail-edge flaps and leading-edge flaps artificially disabled.

I first thought it could be an aerodynamic reaction due to my initial conditions that could be wrong, but I tried a lot of different configurations without noticing any change.

Here is the configuration I use:
JSBSim 1.1.11 runs along with the Matlab S-function. The aircraft file used is f22.xml.
Initial conditions are called from an init file:

<altitude unit="FT"> 10000.0 </altitude>
<vt unit="FT/SEC"> 750.0 </vt>
<gamma unit="DEG"> 0.0 </gamma>
<latitude unit="DEG"> 47.0 </latitude>
<longitude unit="DEG"> 122.0 </longitude>
<phi unit="DEG"> 0.0 </phi>
<psi unit="DEG"> 225.0 </psi>
<beta unit="DEG"> 0.0 </beta>

In Matlab, throttle command, runset, and mixture are set to 1.0. Every other S-function input is set to 0.0.

I am not sure to have fully understood how I should use the initial conditions vectors that are within the S-function, it seems to me that it does the same thing as the init file, but removing the init file generates an error when I try to run the sim.

I tried to run a script to force a "do simple trim" but the trim fails, and trying to manually counteract this phenomenon had been ineffective.

Would somebody have an idea about the origin of this pitch moment? Or an error I could make using JSBSim?

Thank you for your help!
Regards.

bcoconni · 2022-03-17T14:09:38Z

bcoconni
Mar 17, 2022
Maintainer

I tried to run a script to force a "do simple trim" but the trim fails, and trying to manually counteract this phenomenon had been ineffective.

Could you provide the failure message that you get when trying to run a simple trim ?

9 replies

m-ple Mar 18, 2022
Author

Thank you, I corrected this mistake.
With both engine started at the beginning and providing thrust, I still have a problem of throttle. The command and the position of the throttle are both assigned to 1.0 at the beginning of the run (at 0.00833 sec, fcs/throttle-pos-norm = 1.0). But at 0.108333 fcs/throttle-pos-norm is suddenly 0.101754, which I don't understand.

Also, even scripting this :

<condition> simulation/sim-time-sec ge 0.0 </condition>
<set name="simulation/do_simple_trim" value="1"/>

results in a trim failure, apparently due to wdot, udot, qdot, vdot, pdot, and rdot too high for trim tolerance.

Besides, a 3D representation of the plane gives the impression that it pitches up constantly, with or without thrust to stabilize it.

bcoconni Mar 18, 2022
Maintainer

The command and the position of the throttle are both assigned to 1.0 at the beginning of the run (at 0.00833 sec, fcs/throttle-pos-norm = 1.0). But at 0.108333 fcs/throttle-pos-norm is suddenly 0.101754, which I don't understand.

Weird, the trim algorithm is supposed to restore all the controls to their initial value when failing. Could you please share your script ?

Also, even scripting this :

<condition> simulation/sim-time-sec ge 0.0 </condition>
<set name="simulation/do_simple_trim" value="1"/>

results in a trim failure, apparently due to wdot, udot, qdot, vdot, pdot, and rdot too high for trim tolerance.

I just re-read the initial conditions (IC) that you have shown on your original post and it may be that your IC are too constrained and that the trim algorithm fails to match all of them. Could you try with less requirements ? Something like:

<altitude unit="FT"> 10000.0 </altitude>
<vt unit="FT/SEC"> 750.0 </vt>
<latitude unit="DEG"> 47.0 </latitude>
<longitude unit="DEG"> 122.0 </longitude>
<psi unit="DEG"> 225.0 </psi>

m-ple Mar 18, 2022
Author

The script used is the following:

<?xml version=”1.0” encoding=”utf-8”?>
<?xml-stylesheet type=”text/xsl” href=http://jsbsim.sf.net/JSBSimScript.xsl ?>

<runscript xmlns:xsi=https://www.w3.org/2001/XMLSchema-Instance
	Xsi:noNamespaceSchemaLocation=http://jsbsim.sf.net/JSBSimScript.xsd
	Name=”Cruise trim in F22”>
<use aircraft = ‘’f22’’ initialize="f22_cruise_init"/>
<run start=”0” end =”10” dt=”0.008333”>
	
	<event name=”Gear up”>
		<condition> simulation/sim-time-sec ge 0.0 </condition>
		
		<set name=”gear/gear-pos-norm” value=”0”/>
		<set name=”gear/gear-cmd-norm” value=”0”/>
		<set name=”propulsion/set-running” value=”-1.0”/>
		<set name=”fcs/throttle-cmd-norm” value=”1.0”/>
		<set name=”fcs/throttle-cmd-norm[1]” value=”1.0”/>
		<set name=”fcs/throttle-pos-norm” value=”1.0”/>
		<set name=” fcs/throttle-pos-norm[1]” value=”1.0”/>
		<set name=”propulsion/engine/n1” value=”100.0”/>
		<set name=”propulsion/engine/n1[1]” value=”100.0”/>

	</event>
</run>
</runscript>

Unfortunately, even with less restrictive IC, the issue is still the same.

Something though, intrigues me. When I run the script, and monitor the position of the control surfaces (elevator, rudder, ailerons) in Simulink, I can see that they keep constantly at zero. But changing the lag time in <actuator name="fcs/elevator-act"> for example, induces surface control reactions during the pitch up phase (elevator goes down mainly).
I tried several values of lag time from 1.0 to 0.001.
I don't really manage to explain this phenomenon, but I tried loading the yf22.xml aircraft file instead of f22.xml. I don't encounter the pitch up reaction and the trim ends with success.
The FCS and pitch moment calculations are way simpler in the YF-22, do you think the problem may be related?

Thank you again for your enlightenment.

m-ple Mar 18, 2022
Author

Finally, by commenting through the <lag> and <rate_limit> bloc of the F-22 actuators, I managed getting a behavior that should meet the requirements for my project. Thank you for your help about ICs, it certainly helped me distinguishing what was wrong and from where the solution could come!

bcoconni Mar 18, 2022
Maintainer

Something though, intrigues me. When I run the script, and monitor the position of the control surfaces (elevator, rudder, ailerons) in Simulink, I can see that they keep constantly at zero. But changing the lag time in <actuator name="fcs/elevator-act"> for example, induces surface control reactions during the pitch up phase (elevator goes down mainly).

Indeed the <lag> parameters are set to 0.0 for all 4 <actuator> elements:

jsbsim/aircraft/f22/f22.xml

Lines 545 to 553 in 5e81b6d

    
           <actuator name="fcs/aileron-act"> 
        
               <input> fcs/roll-reg-scale</input> 
        
               <lag> 0.00 </lag> 
        
               <rate_limit> 2.29 </rate_limit> 
        
               <clipto> 
        
                   <min> -1 </min> 
        
                   <max> 1 </max> 
        
               </clipto> 
        
           </actuator>

jsbsim/aircraft/f22/f22.xml

Lines 683 to 693 in 5e81b6d

    
           <actuator name="fcs/rudder-act"> 
        
               <input> fcs/yaw-reg-scale</input> 
        
               <lag> 0 </lag> 
        
               <rate_limit> 2.673 </rate_limit> 
        
               <clipto> 
        
                   <min> -1 </min> 
        
                   <max> 1 </max> 
        
               </clipto> 
        
           </actuator>

jsbsim/aircraft/f22/f22.xml

Lines 1007 to 1016 in 5e81b6d

    
           <actuator name="fcs/elevator-act"> 
        
               <input> fcs/el-reg-scale</input> 
        
               <lag> 0.0 </lag> 
        
               <rate_limit> 2 </rate_limit> 
        
               <clipto> 
        
                   <min> -1 </min> 
        
                   <max> 1 </max> 
        
               </clipto> 
        
               <output>fcs/elevator-pos-norm</output> 
        
           </actuator>

jsbsim/aircraft/f22/f22.xml

Lines 1343 to 1352 in 5e81b6d

    
           <actuator name="fcs/tvc-act"> 
        
               <input> fcs/tvc-reg-scale</input> 
        
               <lag> 0.00 </lag> 
        
               <rate_limit> 2 </rate_limit> 
        
               <clipto> 
        
                   <min> -1 </min> 
        
                   <max> 1 </max> 
        
               </clipto> 
        
               <output>fcs/tvc-pos-norm</output> 
        
           </actuator>

However according to the code in src/models/flight_control/FGActuator.cpp, this means that ca is always 0.0 and cb is always 1.0:

jsbsim/src/models/flight_control/FGActuator.cpp

Lines 306 to 312 in 5e81b6d

    
           void FGActuator::InitializeLagCoefficients() 
        
           { 
        
             lagVal = lag->GetValue(); 
        
             double denom = 2.00 + dt * lagVal; 
        
             ca = dt * lagVal / denom; 
        
             cb = (2.00 - dt * lagVal) / denom; 
        
           }

As a consequence, Output is stuck to the value of PreviousLagOutput:

jsbsim/src/models/flight_control/FGActuator.cpp

Lines 214 to 218 in 5e81b6d

    
             Output = ca * (input + PreviousLagInput) + PreviousLagOutput * cb; 
        
           } 
        
           PreviousLagInput = input; 
        
           PreviousLagOutput = Output;

And since PreviousLagOutput is initialized to 0.0 then the <actuator> output is frozen to 0.0 as well:

jsbsim/src/models/flight_control/FGActuator.cpp

Lines 53 to 61 in 5e81b6d

    
           FGActuator::FGActuator(FGFCS* fcs, Element* element) 
        
             : FGFCSComponent(fcs, element) 
        
           { 
        
             // inputs are read from the base class constructor 
        
             PreviousOutput = 0.0; 
        
             PreviousHystOutput = 0.0; 
        
             PreviousRateLimOutput = 0.0; 
        
             PreviousLagInput = PreviousLagOutput = 0.0;

jsbsim/src/models/flight_control/FGActuator.cpp

Lines 134 to 140 in 5e81b6d

    
           void FGActuator::ResetPastStates(void) 
        
           { 
        
             FGFCSComponent::ResetPastStates(); 
        
             PreviousOutput = PreviousHystOutput = PreviousRateLimOutput 
        
               = PreviousLagInput = PreviousLagOutput = Output = 0.0; 
        
           }

seanmcleod · 2022-03-18T14:25:27Z

seanmcleod
Mar 18, 2022
Maintainer

Can you give us some more details on what you did to the F-22 xml. Does it now trim with your changes?

What are the requirements for your project?

I was going to ask if you really want to use the F-22 given it has such a complicated FCS.

3 replies

bcoconni Mar 18, 2022
Maintainer

@m-ple, I'd be interested in your results as well since I have been unable to trim the f-22 so far. Commenting out the <lag> elements and the <rate_limit> elements makes no difference.

The problem with the <lag> elements set to zero really makes me wonder if the f-22 FCS is functional at all ?

m-ple Mar 21, 2022
Author

I commented the <lag> under all <actuator ="..."> component of the F-22. But I am not able to trim either.

The only requirement for my project is, as of right now, to have a "stable" fighter aircraft at the beginning of the simulation to be able to test different control laws with Matlab.

seanmcleod Mar 21, 2022
Maintainer

Then I suggest you don't use the F-22 or F-16 that ship with JSBSim which come with their own control laws implemented in the FCS section. That's only going to really complicate things if you're trying to implement your own control laws with Matlab.

Choose something like the A-4 which has no control law implemented, it's FCS is pretty trivial in terms of mapping an inceptor command directly to a control position angle.

And I know the A-4 model can be trimmed, even inverted 😉 - https://seanmcleod.github.io/2021/06/inverted-trim/

seanmcleod · 2022-03-18T17:06:18Z

seanmcleod
Mar 18, 2022
Maintainer

I've been wondering if the JSBSim trim routines will actually work with a FBW FCS command law.

Forget about the super complicated F-22 FCS, let's assume we have a simple pitch rate command law. So a centered stick commands a zero pitch rate and greater stick deflection/command commands an increasing pitch rate.

And by definition to be in trim the pitch rate has to be 0. Now to balance the pitch moments the trim routine will run through the -1 to +1 range for the longitudinal inceptor. But any non-zero value will have the FCS trying to move the control surfaces to generate a non-zero pitch rate via it's feedback controller etc.

1 reply

bcoconni Mar 18, 2022
Maintainer

Well, the only way to know is to build an example and conduct some tests 😉

seanmcleod · 2022-03-18T17:11:48Z

seanmcleod
Mar 18, 2022
Maintainer

Actually I guess in this case the trim routines just need to zero in on using 0 for the stick's pitch cmd. The FCS controller then should drive the control position via it's feedback loop to the required position to achieve a zero pitch rate which is what the trim routine is looking for.

0 replies

seanmcleod · 2022-03-18T17:14:35Z

seanmcleod
Mar 18, 2022
Maintainer

Actually as long as the FCS feedback loops run for long enough during each trim solution time step?

1 reply

bcoconni Mar 18, 2022
Maintainer

Not sure what you mean but the trim algorithms suspend the integration i.e. set the time step dt to 0.0:

jsbsim/src/initialization/FGTrim.cpp

Lines 201 to 202 in 5e81b6d

    
           fdmex->SetTrimStatus(true); 
        
           fdmex->SuspendIntegration();

jsbsim/src/FGFDMExec.h

Lines 541 to 542 in 5e81b6d

    
           /// Suspends the simulation and sets the delta T to zero. 
        
           void SuspendIntegration(void) {saved_dT = dT; dT = 0.0;}

seanmcleod · 2022-03-21T16:50:18Z

seanmcleod
Mar 21, 2022
Maintainer

I'm no expert on the trim routines, but at a high level my assumption having glanced at the trim code a while ago is that the trim routines set the inceptor commands as opposed to directly setting the control surface positions. During the iteration of trying a range of inceptor commands the trim code then executes a single time step to see whether this inceptor command results in zero translational acceleration and zero angular acceleration.

So now in the case where the FCS isn't simply a simple mapping of inceptor command [-1, +1] to control position [-x deg, +y deg] (having an actuator in between is fine since during trim the lag and rate limiting is disabled) but rather the inceptor command is converted into a command law input, e.g. pitch rate command, g-command etc. then in this case we'll have something like a PID controller in the loop now.

So I assume during the single time step the PID controller will sample say the current pitch rate to compare it to the commanded pitch rate. However I'm not certain what the current pitch rate will be in this circumstance, maybe 0? And so the PID won't command the elevator to move since it thinks the current pitch rate matches the commanded pitch rate.

But given the current elevator position, possibly 0, the trim routine will see that the angular acceleration isn't 0 and so won't recognize that for a 0 pitch rate the inceptor command has to be 0.

Plus later on it may find that a non-zero inceptor command which gets turned into a non-zero pitch rate command does so happen to move the elevator via the PID controller to a position that results in zero angular acceleration and so thinks that this non-zero inceptor command is a valid command.

However at time 0 the aircraft will be in trim, but immediately afterwards given the non-zero inceptor command the trim solution found the FCS will start demanding a non-zero pitch rate, i.e. putting the aircraft out of trim.

Which is why I'm wondering if the current trim routines will really work with an FCS that implements a command law.

3 replies

bcoconni Mar 26, 2022
Maintainer

So I assume during the single time step the PID controller will sample say the current pitch rate to compare it to the commanded pitch rate. However I'm not certain what the current pitch rate will be in this circumstance, maybe 0? And so the PID won't command the elevator to move since it thinks the current pitch rate matches the commanded pitch rate.

IMHO it's not the D of the PID that is a problem for trimming since, as you mentioned, rates can be assumed to be 0 since we are looking for a stable configuration which, by definition, has null rates. The problem is rather the I (integration) for which I'm struggling to see which value should be set for a stable configuration ?

Which is why I'm wondering if the current trim routines will really work with an FCS that implements a command law.

I am in complete agreement with you. The only way out that I can think of is a special trim mode that would explicitly be implemented in the FCS i.e. a <system> that would be triggered when a property simulation/trim-status would be non-zero for instance.

seanmcleod Mar 26, 2022
Maintainer

I was thinking of even just a P controller with some gain for the difference between the current pitch rate and the commanded pitch rate. So if during this timestep the P controller saw the error as being 0 then it wouldn't move the elevator.

For this example, pitch rate command law FCS, and in general for command law FCS there would need to be some extra knowledge or communication between the trim algorithm and the FCS.

So for a basic pitch rate command law case you would have the trim routines drive the position of the control surface, elevator in this simple example until it found a trim solution for some specific elevator angle. Then via some knowledge/communication it would know that the pitch command that needed to be initialised via the pitch input command needs to be 0.

But this can get fairly complicated with advanced command law FCS systems, e.g. there may be multiple control surfaces driven by a single channel input, e.g. say for roll control, the FCS may move the all moving horizontal tails differentially as well as moving a set of ailerons etc.

So for say a steady heading sideslip trim case with a command law based FCS how does the trim routine know what set of surfaces to try moving etc.

Not as trivial as the C-172 in terms of trim solutions 😉

bcoconni Mar 27, 2022
Maintainer

I was thinking of even just a P controller with some gain for the difference between the current pitch rate and the commanded pitch rate. So if during this timestep the P controller saw the error as being 0 then it wouldn't move the elevator.

I agree. I was more focused on the I controller as this is what the FCS of the F-22 model uses but indeed, the result is the same for P and I controllers: if the control laws bypass commands when the error is zero then the trimming has no effect.

Not as trivial as the C-172 in terms of trim solutions 😉

You are completely right: the trim algorithms are designed for a standard aircraft layout such as the C-172.

If we want to extend the capability of the trim algorithm to other configurations, we will need the model designer to provide some dedicated <system> elements that get their inputs from the trim algorithm and set the aircraft FCS and control surfaces to states that correspond to the current trim configuration candidate.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

F-22 pitching up at initialization #604

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 6 comments 17 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

F-22 pitching up at initialization #604

m-ple Mar 17, 2022

Replies: 6 comments · 17 replies

bcoconni Mar 17, 2022 Maintainer

m-ple Mar 18, 2022 Author

bcoconni Mar 18, 2022 Maintainer

m-ple Mar 18, 2022 Author

m-ple Mar 18, 2022 Author

bcoconni Mar 18, 2022 Maintainer

seanmcleod Mar 18, 2022 Maintainer

bcoconni Mar 18, 2022 Maintainer

m-ple Mar 21, 2022 Author

seanmcleod Mar 21, 2022 Maintainer

seanmcleod Mar 18, 2022 Maintainer

bcoconni Mar 18, 2022 Maintainer

seanmcleod Mar 18, 2022 Maintainer

seanmcleod Mar 18, 2022 Maintainer

bcoconni Mar 18, 2022 Maintainer

seanmcleod Mar 21, 2022 Maintainer

bcoconni Mar 26, 2022 Maintainer

seanmcleod Mar 26, 2022 Maintainer

bcoconni Mar 27, 2022 Maintainer

m-ple
Mar 17, 2022

Replies: 6 comments 17 replies

bcoconni
Mar 17, 2022
Maintainer

m-ple Mar 18, 2022
Author

bcoconni Mar 18, 2022
Maintainer

m-ple Mar 18, 2022
Author

m-ple Mar 18, 2022
Author

bcoconni Mar 18, 2022
Maintainer

seanmcleod
Mar 18, 2022
Maintainer

bcoconni Mar 18, 2022
Maintainer

m-ple Mar 21, 2022
Author

seanmcleod Mar 21, 2022
Maintainer

seanmcleod
Mar 18, 2022
Maintainer

bcoconni Mar 18, 2022
Maintainer

seanmcleod
Mar 18, 2022
Maintainer

seanmcleod
Mar 18, 2022
Maintainer

bcoconni Mar 18, 2022
Maintainer

seanmcleod
Mar 21, 2022
Maintainer

bcoconni Mar 26, 2022
Maintainer

seanmcleod Mar 26, 2022
Maintainer

bcoconni Mar 27, 2022
Maintainer