All that is wrong with the MSFS Flight Model (Inertia, Stalling, Pitch Authority, Trim & Sensitivity)

For me its difficult to point out exactly what the problem is with the flight model, maybe someone with in depth knowledge can see what is going wrong from the (long) video below. All of these issues came to light when trying to figure out why all MSFS aircraft are so sensitive and “twitchy” on the flight controls during crosswind landings. A couple of bugs:

  1. First off all to get a proper crosswind at ground level you need to set an insane windspeed at altitude, as MSFS takes the “ground wind” entered by the user, uses that as the geostrophic wind and then modifies it using a very rough rule of thumb which only works for light to moderate wind speeds to a surface wind. In order to have a surface wind of 25 kts, gusting 35 kts for example, you’ll need to select 50 kts gusting 70 kts in the weather menu (!) as MSFS cuts the surface wind in half. This makes simulating a proper crosswind landing with twitchy MSFS aircraft even more difficult and makes it more gusty and turbulent at higher altitude compared to ground level, in the real world it is the other way around.
  1. Seeing that even heavy aircraft like the Airbus A320 and Boeing 747-800 are tossed off flight path really easily with the slightest crosswind or turbulence and are feeling like a Cessna under those conditions, the question about inertia (or the lack thereof) came up. To test this I tried to pull the fully loaded Boeing 748 and Airbus A32N into an accelerated stall. Its difficult to say if there is a real lack of inertia or if there is an issue with elevator effectiveness. It basically comes down to this, when flying the A320 or Boeing 748 and pulling the yoke or stick full back, the aircraft does NOT enter an accelerated stall, instead the aircraft enters a vertical climb or loop. The flightpath of the aircraft does not stay behind sufficiently to increase the AOA passed the stalling angle.
  1. Related to this, when stalling most MSFS aircraft, no matter if it is a Cessna 172 or Airbus A320, no matter the aircraft weight or CG position, the aircraft becomes a falling leaf instead of performing a clean stall break, a wing drop or spin. In a climbing turn or descending turn the correct wing doesn’t stall. Performing a steep turn, you’ll run out of elevator authority before reaching critical angle of attack etc.

I’m not particularly interested in having the simulator simulate the edges of the flight envelope and beyond with perfect realism. But the basics must be right, for anyone using MSFS for training, it is important the correct wing stalls during the base to final turn for example, when being to aggressive on the controls the aircraft should enter an accelerated stall instead of making a GTA V style loop etc.

In the below video I went through all different kinds of maneuvers, trying to demonstrate what is wrong with the MSFS flight model. I tried to have as much information possible on screen, the developer mode PITCH visualization, some basic simulator figures, the sidestick is visible on the bottom left side of the screen, as are the throttles, PFD, ND and ECAMS. The aircraft used is the default A320 with flight computers OFF (direct law mode). I went through basically the same kind of maneuvers on the Boeing 748 with the same results, just to indicate it is not a problem with one particular flight model. I noticed the CG is quite far forward at MTOW in my tests so I went back into the sim with the CG on the aft limit (not recorded) and I found no significant difference.

The Flight Path Vector (FPV) is selected and should give some idea about the AOA (the angle between the FPV and the aircraft symbol) assuming no wind, you can see that the aircraft is able to fly at very low speed (below 40 kts indicated airspeed even) at a positive angle of attack without any stall warning. On the contrary the stall warning sometimes sounds at very low AOA.

image

Maneuvers performed (MTOW):

  • Accelerated stall at 250 kts
  • Accelerated stall at Vmo
  • Full stall in landing configuration
  • Full stall with flaps 1 (forgot the fully retract the flaps)
  • Full stall in clean configuration
  • Stall in 45 degree bank steepturn

Maneuvers performed 10% fuel, no payload:

  • Accelerated stall at 250 kts
  • Accelerated stall at Vmo
  • Full stall in landing configuration
  • Full stall in clean configuration
  • Stall in 45 degree bank steepturn
  • Some more accelerated stalls, full back sidestick and THS full up
  • Some rapid pitch ups and attempted accelerated stalls using outside view so you can see the AOA indicator.
  • Crosswind landing with 25 gusting 35 kts at ground level.

Video

Time stamps added:


Accelerated Stalls

When flying straight and level and pulling the sidestick full back, the nose pitches up but the aircraft keeps following the original flight path initially due to its inertia, this “disconnect” between the aircraft pitch and the flightpath (and therefore relative airflow) causes an increase in AOA passed the stalling angle of attack.

f0005-04

You can see from the flight envelope below the result of using full flight control deflections, below the designed maneuvering speed the aircraft will enter an accelerated stall before reaching the aircraft designed limit loadfactor (+2.5g for most modern air transport aircraft), when flying faster than the designed maneuvering speed the peak loadfactor will be higher than 2.5 g before entering an accelerated stall.

9cfe35735b0375574f504a303529de280d19a63f_2_690x459

You can see that in MSFS the flightpath and pitch rate stay more or less in synch when pitching up sharply and the AOA therefore never exceeds the stalling angle of attack. Result: the aircraft enters a vertical climb until running out of energy or even loops instead of entering an accelerated stall. Even with full up elevator AND full up stabilizer trim, the aircraft won’t enter an accelerated stall. I noticed that the AOA during a sharp pitch-up only changes as a factor of airspeed. During the pull-up at Vmo for example, you can see the AOA stays perfectly within limits, then increases slowly as airspeed decreases. Its a little weird for me, I would expect the elevator and stabilizer are more effective at higher speed and therefore should result in a higher AOA when pitching up sharply at Vmo compared to 250 kts or lower. From the outside view, when looking at the AOA indicator, it almost looks like there is an AOA limiter installed, the AOA rises rapidly towards the stalling angle and then stays just below.

Does anybody understand why the lift vector is negative at a positive angle of attack when flying upside down (at 33:50)??? The lift vector turns around, at some point even pointing directly in the direction of travel…


Maneuvering Speed (Va)

Definition: The Manoeuvring Speed (VA) of an aircraft is an airspeed limitation determined by the aircraft designer. At speeds exceeding the manoeuvring speed, full deflection of any flight control surface can result in damage to the aircraft structure.

https://www.skybrary.aero/index.php/Manoeuvring_Speed

The stallspeed can be calculated by multiplying the 1g stall speed x the squareroot of the loadfactor. According to the sim the estimated stall speed at MTOW is 178 kts and at 10% fuel and no payload 129 kts. With a 1g stall speed of 178 kts it only takes 2g at 250 kts to stall the aircraft, which is the same as a 60 degrees angle of bank steep turn.

MTOW 10% Fuel, No Payload
Loadfactor Stallspeed Loadfactor Stallspeed
1 180 1 130
1.5 220 1.5 159
2 255 2 184
2.5 285 2.5 206
3 312 3 225
3.5 337 3.5 243
4 360 4 260

In short, at MTOW, the designed maneuvering speed is around 285 kts. When pulling the nose up at 285 kts the aircraft will reach a peak loadfactor of 2.5g, the same time the aircraft enters an accelerated stall and loadfactor decreases. For an empty aircraft the design maneuvering speed is only 206 kts. Above those speeds, using full control inputs the aircraft will reach a peak loadfactor above 2.5g before stalling, causing structural damage or even structural failure. Again according to the diagram:

image

You can see that in the sim at MTOW and Vmo, the peak load factor reaches around 2, while the peak load factor at empty weight reaches around 3. In real life, when performing this maneuver above design maneuvering speed you will reach far greater peak load factors and pull the wings straight off.


Full Stalls in 1g - Level Flight

Full stalls (clean and landing config): the aircraft behaves the same as the default Cessna 172 and other aircraft I have tested. The Airbus does not reach stalling angle and makes a stall break, drops a wing or enters a spin, instead become a “falling leaf” and keeps oscillating around the stalling speed, even with full up elevator AND stabilizer trim.


Stall During (Steep) Turn

Stall during (steep) turn: the aircraft starts descending, keeping its AOA below stalling angle with full up elevator and stabilizer trim.


Crosswind

Apart from missing the feel of any mass going down that flight path, the aircraft behaves weird during crosswind conditions, for some reason the aircraft pitches up early during take-off with crosswind, during landing, whilst keeping the elevator in the flare position, the nose stays in the air. When flying in no wind conditions the aircraft does not exhibit this weird pitch behavior.


Conclusion

I think there could be two reasons for this odd behavior:

  1. There isn’t enough inertia simulated and therefore the flight path responds too rapidly and stays in synch with the pitch. This would also explain the sensitivity and twitchiness of the controls, in gusts and in turbulence and the ability to loop a fully loaded aircraft.

  2. The pitch authority is insufficient. Asobo did show in an aerodynamic video that they simulate exceeding the stalling AOA on the horizontal stabilizer during large elevator deflections, maybe they have overdone this effect and the elevator authority is now severely compromised. At 2:00:

In any case, I think we can all agree this behavior isn’t right. If someone has any other ideas, please comment below and lets figure this one out for Asobo.


Edit: Elevator Deflection versus Airspeed

I think I found atleast one of the issues, when looking at the elevator deflection it is somehow depending on the airspeed, so full back sidestick at Vmo only means a few degrees of elevator deflection. I think this is due to another “improvement” they’ve incorporated to make make planes behave more “realistic”. I believe this was explained in some developer Q&A, but I can’t find it.

They’ve explained something like, its harder in real life to pull the stick full back due to the feedback from the flight control system and G-forces so they’ve limited something. Just tested on the Cessna 172, exactly the same thing going on, no full elevator deflection at high speed. This would explain the weird stall dynamics and inability to pull the aircraft in an accelerated stall, it does however not explain or solve the sensitivity issue.

The implementation is done very poorly, to the point that you can’t even stall an aircraft anymore, can’t maintain altitude during a 45 or 60 degree steep turn etc. From the video below, you can see the elevator deflection above my mouse pointer. When inside the cockpit you have no hind that this is even happening as the yoke position mimics your joystick position and is unrelated to the actual elevator position! Not how it works in real life at all of course, totally unrealistic.

I’m thinking they have done this to mask the underlying problem of sensitive and twitchy flight controls. I think they’ve “dumbed down” the up and down draughts for the same reason. If they would get rid of this elevator deflection by airspeed / G-loading effect or open up the up / down draughts fully they will get a lot of complaints as the underlying problem of sensitivity has not been solved. It should not be necessary to have this maximum limit on flight control deflection as a factor of airspeed, even Level-D simulators aren’t able to simulate g-forces, although they do simulate higher stick force at higher airspeed. There is nothing realistic about full scale elevator input being 28 degrees elevator deflection at low speed suddenly becoming only 7 degrees defection at high speed.

Asobo, please, please remove this or make it an option!!!


Elevator Trim

Something else I found out which I thought was interesting is the way MSFS simulates the elevator trim on conventional flight control systems, for example on the Cessna 172. When trimming the elevator the elevator deflection itself does NOT change, but the aircraft somehow does pitch up / down, almost as if the aircraft has a trimmable horizontal stabilizer. I don’t know how other simulators simulate this as there is a limitation here without force feedback and floating in-trim position.

In real life, the trim tab moves the elevator, which in turn creates a nose up / down pitching moment. Since the elevator deflection does not change at all, and the aircraft does not have a trimmable horizontal stabilizer, how on Earth does the aircraft trim in MSFS??? In the real world if you would trim while the elevator is held in position or is jammed / stuck the elevator trimtab itself starts to become a mini-elevator but instead works in REVERSE, i.e. trimming nose up will move the nose down and vice versa. The way MSFS simulate elevator trim should in theory increase the elevator pitch authority. In real life the elevator trim drives the elevator itself to the up or down position, with the trim fully nose up, the elevator (and yoke) would be fully nose up. In MSFS you could trim the nose all the way up and still have elevator in the neutral position, so range left to pitch up even further, unless they somehow compensated for this.

In the photo below you can see the aircraft trimmed nose up with elevator neutral. This would never work in real life, the situation below would actually cause the trim tab to act like a tiny elevator working in reverse, pitching the nose DOWN instead of UP, also there wouldn’t be much pitch authority as the surface area of the tab is very small. The purpose of the trim tab is to move the elevator, in this case to the UP position which in turn pitches the nose up.

In the video below you can see the yoke (and elevator deflection) does not change when trimming. When releasing the aircraft from active pause moving the elevator controls the pitch even further, even though the elevator is already trimmed full up or full down. In real life when the elevator is kept where it is, trimming up or down has only a small (reverse) effect, the aircraft will more or less keep flying level but it will require a lot of stickforce to keep the elevator in this position.

I’m not saying it is wrong and I don’t know how other simulators handle the limitations imposed by using a non force feedback joystick without floating center. I do think the current implementation is a poor way of simulating elevator trim, I think it would be more realistic to approach the joystick inputs as the force applied rather than the absolute control surface position, this would also match their approach with regard to previous topic. If I understand it correctly X-plane uses the force based approach, the deflection of the control from its spring loaded neutral position is taken as the force the pilot applies to the control, rather than the controls absolute position. I think this is a more realistic approach to trimming. MSFS has chosen a strange approach were everything is a weird mix between the joystick controlling absolute control surface deflection at low speed but force based at higher speeds.

The joystick simulating the absolute control surface position rather than force is the core of another problem, in MSFS it is possible to steer the aircraft with the autopilot engaged, this is impossible in real life as you can’t physically move the controls when the autopilot servo’s are engaged. The correct simulation would be to completely ignore the control inputs via your joystick or yoke with the autopilot engaged. When large inputs are given the autopilot should trip offline and hand over controls to the pilot, just as in real life when you apply excessive force on the controls with the autopilot engaged. In every single aircraft I have ever flown, there is not one where I could control the aircraft with the AP engaged, you can’t physically move the controls with the servo’s engaged so below the autopilot disconnect threshold control inputs should be completely ignored.


Elevator Trim Acceleration

Another odd design choice is the weird acceleration in the pitch trim, when trimming for more than a few seconds the rate of trim starts to increase. This is not how trim works in real life, with electrical trim the rate is constant no matter how long you keep trimming. When making large trim changes using a manual trim wheel I would start with large trim wheel inputs and then finetune when getting closer to the in-trim position. The trim accelerating with time is therefore counter intuitive and has nothing to do with the real world. It would be pretty dangerous on aircraft with big trimmable horizontal stabilizers to have the trim running away like that.

This “falling leaf” comparison remains me on the following documentation snippet: “When reaching a certain level of stall, the behavior of the surface is changed using additional parameters so as to follow, broadly speaking, the behavior of a falling plate. Reading the literature about airfoils behavior in stall configurations, it can indeed be shown that local boundary layer detachment leads to a very sudden change in the aerodynamical behavior of the airfoil, that can be assimilated to a falling plate. The interested reader is refered to this NASA experimentally based study.” See file:///C:/MSFS%20SDK/Documentation/03-Content_Configuration/SimObjects/00-Aircraft/Flight_Model.html#complex-physical-phenomena-modelization

Asobo talks about “falling plate”. Anybody found the “NASA experimentally based study”?

Like Aristoteles told “The whole is more than the sum of its parts”. Maybe the “falling plate” additional parameters are enough for simple forms - like plates, but not for shapes like an airplane that is specially constructed to fly “this way” but not fly “that way”. If we knew the shapes in the NASA experiments, we can hopefully see if additional parameters are enough or if much more is needed.

Okay everybody: Can we define a test? A good test has at least two cases. Like “empty airplane = loop possible”, “airplane full of pax, cargo, fuel = loop not possible”. Can we describe such a test for the B747? For me the flight model of the B747 is much easier to change compared to the A320 model.

The Boeing 747 reacts the same, issue is not necessarily the loop, the main problem is that the aircraft can’t be pulled into an accelerated stall. The underlying problem is either inertia or pitch authority. Is there some line in the .cfg file for horizontal stabilator stalling AOA?

1 Like

Hello Nijntje91, this is too much pilot talk. You have to explain me how you get to accelerated stall in a real airplane - on little child level.

Okay, is there a misprint? And again, please explain. There are a lot of parameter that have AOA in the name and some tables, too. But it is always necessary to verify that behind the parameter is machinery (system). Next step, the machinery can be broken and so on. You know the drill.

Simply said, when flying in cruise and pulling the stick full back the aircraft should stall at a speed above the normal 1g stall speed. When you are flying a fully loaded Boeing 748 and sharply pitch-up, the aircraft continues down its original flightpath due to its inertia while the aircraft pitches up, this should exceed the stalling AOA.

f0005-04

In MSFS this doesn’t happen due to either a lack of inertia (the flight path changes too rapidly and is able to catch up and stay in synch with the pitch rate) or the elevator authority is insufficient. Which might have something to do with this (at 2:00):

That is why I’m wondering if there is a stalling AOA for the tail in the .cfg file.

2 Likes

If this is a serious question, how do you ‘improve’ the flight dynamics of MSFS aircraft?

Is inertia modeled in the flight model? If not, then we are back to basic physics about momentum, and the natural tendency of the aircraft to balance all the forces acting on it, by settling on a equilibrium pitch and rate of ascent/descent based on a given set of power settings.

If Asobo is accurately simulating all forces on the aircraft in a physically consistent manner, the model will feel “real” even if the performance numbers are off. If things like momentum and elevator/aileron authority are calculated in a simplistic fashion, the behavior will “feel” wrong.

It’s not about calculating with greater precision, it’s about how the elements are combined to output the flight model for the next time increment.

It’s about how the aggregation of the individual elements geometry, drag, thrust, wind, control surface deflection , AND history from the last compute cycle are integrated to output the next.

An algorithm that uses the ( some weighted ) last values of the model and predicted next set of values to modify the predicted values based on the previous seconds data… is one way “inertia” can be incorporated.

2 Likes

Took a whole afternoon but I think I’ve found the issue, it starts with an A and ends with SOBO:

Edit: I think I found atleast one of the issues, when looking at the elevator deflection it is somehow depending on the airspeed, so full back sidestick at Vmo only means a few degrees of elevator deflection. I think this is due to another “improvement” they’ve incorporated to make make planes behave more “realistic”. I believe this was explained in some developer Q&A, but I can’t find it.

They’ve explained something like, its harder in real life to pull the stick full back due to the feedback from the flight control system and G-forces so they’ve limited something. Just tested on the Cessna 172, exactly the same thing going on, no full elevator deflection at high speed. This would explain the weird stall dynamics and inability to pull the aircraft in an accelerated stall, it does however not explain or solve the sensitivity issue.

The implementation is done very poorly, to the point that you can’t even stall an aircraft anymore, can’t maintain altitude during a 45 or 60 degree steep turn etc. From the video below, you can see the elevator deflection above my mouse pointer. When inside the cockpit you have no hind that this is even happening as the yoke position mimics your joystick position and is unrelated to the actual elevator position!!! Not how it works in real life at all of course, totally unrealistic.

Asobo, please, please remove this or make it an option!!!

2 Likes

The same as I have worked all my life. I learn fast. For example, many years ago I learned to eat, to walk, to talk. Maybe you had similar experiences of learning something you had no clue about?
I found it helpful to say “I know that I don’t know”. The alternative is to say “I know everything”. What is your preference?

The question is serious.

This is from file:///C:/MSFS%20SDK/Documentation/03-Content_Configuration/SimObjects/00-Aircraft/Flight_Model.html#aircraft-mechanical-description

We see a lot of integration. That is, your “An algorithm that uses the ( some weighted ) last values of the model and predicted next set of values to modify the predicted values based on the previous seconds data” is there. But what we don’t know, are these equations executed in MSFS 2020?

This is a design document. And if you have a good methodology, the design document gets updated after the implementation. At the moment Asobo is still struggling with the implementation - the flight dynamics bug is not this far away. I think nobody at Asobo has time right now to write down what is really happening in the implementation.

For example: Did you know that rudder_limit = 0 crashes MSFS 2020 version 1.14.5.0? I found this tiny bug because Aircreation 582SL has no rudder and therefore no need for rudder_limit. My workaround? Write rudder_limit = 0.1 and hunt the next bug. And yes, there was a next bug.

1 Like

I suppose the tricky thing there is that there’s no resistance in the yoke/stick when you’re sat at your desk, so you can yank the thing right back and in the in cockpit one just follows your input visually.

No doubt if it was modelled to follow the behaviour of the elevators instead, people would be out with the pitch forks and burning torches saying it was a bug la de la.

I don’t know, maybe Force Feedback or some other ‘resistance’ system would be a step in the right direction, where the feedback was aligned with, and proportionate to, the elevator movement and any associated resistances for the given situation, instead of the current setup.

1 Like

Sure, but limiting it in such a way that you can’t even perform a stall or a steep turn? Goes a little far…

:slight_smile: The theory is correct… implementation is a whole other story :slight_smile:
I remember classes on closed loop and open loop feedback systems too… !! I am sure all that lovely PID control theory is there as well!

Also the equations relate to calculating the moment of inertia around a point, are different from those computing the “intertia” of momentum … though related.

Going to be a grumpy git now, and roll my eyes at the disappointing lack of interest in this thread and some of the other posts related to this issue.

Funny old world where it’s all guns blazing and bordering on a virtual riot because some trees have disappeared, or the rivet heads on the model are the wrong colour, yet something like this that’s a fundamental part of the simulation just get’s drowned out or ignored. Bizarre. :man_shrugging:

22 Likes

Level D sims also don’t simulate G-forces, only accelerations, so it won’t be that unrealistic to just ditch it. The problem of sensitive and twitchy controls has a different root cause I think…

1 Like

I sincerely hope that this gets some traction though and someone at Asobo has read what’s been written, (which is constructive, well evidenced and backed up with experience) and it helps inform some changes.

I also hope they ditch this ‘most votes get’s the cookie’ style of feedback that seems to steer what they look at as well.

8 Likes

This succinctly sums up the current flight model issues in FS. Inertia modelling and its relationship to AoA is not calibrated properly and combining that with the interference between controller inputs and flight control surfaces is I think what’s causing the unnatural handling characteristics.
In a post I made in another thread I looked at the aileron deflection vs roll rate and noticed that when the aircraft is rotating around the longitudinal axis and the ailerons are then applied in the opposing direction of the roll, the surfaces did not deflect into the opposing airflow to create a resulting moment and arrest the roll, they were neutral passing reversal of roll direction. Implying that there is no longitudinal axis inertia there to be countered.

@Grinde81 Found some pretty interesting stuff when he tested various aircraft control response.


I think these graphs have something to do with the inertia problem and limit on surface max deflection rate. To my simplistic mind it appears if they were to remove the restrictions on max control deflections (and rates of deflection) that the aircraft would become uncontrollably sensitive due to lack of inertia

4 Likes

Good examples. Asking this basic question (accelerated stall) looks to me that you are trying to run before knowing how to walk.

Most likely because there are very few people who know a lot (or even anything) about flight models and their design.
More important, they don’t really care because they don’t know what to expect.

When I was designing flight dynamics it was difficult to convice companies to pay for flight models because they correctly assume that ~95 of the users don’t know anything about it, so why should they pay for high quality flight dynamics?

Despite having many years of experience in aviation and flight model design I’m also not taking part in this discussion, because I still know way too little about the new FDM.
It’s a very complex theme.
My initial impression is that the inertia simulation is still a leftover from FSX which means that it’s too high.
Why you can’t force accelerated stalls is still not clear to me and looking at dedicated flight model design forums, there’s a lot still in dark.

4 Likes