What is computational flutter?
Computational flutter is an oscillation effect in the flight model that makes aircraft behave in bizarre and incomprehensible ways. Symptoms include sudden uncommanded roll or yaw, unexplainable acceleration, and bizarre uncontrollable bouncing on the landing gear. The flight problems occur most often when you fly fast with low frame rate. The landing gear problems occur most often with skids, also at low frame rate.
To explain how computational flutter works, we first have to explain the basics of how X-Plane manages the flight model. Unlike the real world where physical effects are smooth, continuous functions in time, X-Plane computes the flight model in discrete steps. That is, it does all the math necessary to work out what the plane is doing at some instant in time, adjusts its position and velocity accordingly, and then continues to do it over and over. Each set of computations takes a certain length of time. The interval between each set of computations determines the frame rate.
The way you do a simulation of motion in discreet steps goes as follows:
- From the current situation, determine the forces on the aircraft. (This is where most of X-Plane’s magic lies in terms of airfoils, etc.)
- Divide the forces by the applicable mass or moment of inertia to determine acceleration.
- Multiply acceleration by the time interval between frames and add to the previous velocity to find the new velocity.
- Multiply velocity by the time interval between frames and add to the previous position to find the new position.
The last two steps amount to discrete integration.
Now… how does this cause computational flutter?
Many real world processes are “self-correcting”. That is, motion in response to a force creates an opposite force that damps out the motion. Three examples:
- Push on a spring to make it compress, and it pushes back.
- Accelerate a plane, and air resistence increases to slow it down.
- Roll a plane, and the rising and falling wings cause a downwards and upwards component of airflow that damps out the roll.
Now think about modelling such a process in a discrete simulation. At step n of the simulation you have a certain force on a part of the plane that yields a certain acceleration. You integrate that over the frame rate interval to get the resulting velocity and change in position. What you’ve done is to assume that the force stays constant over the interval. In step n+1, your position and velocity will be different and the resulting force will be different. (In a damped system such as the above examples the net force will be reduced.)
But the real world doesn’t work in discrete steps. In the real world an infinitesimal change in motion or position instantly causes a change in force. In the discrete model, as long as the changes in force, velocity, and position are relatively small from step to step, all is well and the results are pretty close to the real world.
Where you get in trouble is when you get a large enough change from one frame to the next so that the net force is reversed. Think about stepping on a spring. The force of your weight accelerates you and the spring downwards. The longer the integration time (frame to frame time interval), the longer your full weight is applied to the spring, and the further the spring is compressed before the simulation model “notices” that the spring is now compressed. Take this far enough, and in step n+1 the spring is already compressed so far that the opposing force exceeds double your weight. The net force now exceeds your weight, upwards! What happens? You are accelerated upwards, at a higher rate than you came down in the previous step. Look ahead to step n+2: You end up bounced higher in the air than you started at step n; in step n+3 you end up lower with even more spring compression, go even higher in step n+4, etc. The result is divergent oscillation.
“But, but, but… That’s not what I see in the plane’s behavior, ” you say. “What I see is a sudden, increasing roll in one direction, or unexplained acceleration.” (Hmmm… remember the Audi 5000?) When I graph the flight parameters or log them to a disk file, all I see is a steadily increasing force on one direction. What’s going on?
Two important facts come into play:
- X-Plane does two flight model computations for each display frame. The oscillation occurs in alternate frames of the flight model, so in the display you see only one side of the oscillation.
- The disk file data output is logged at about 10 samples per second. Again, you don’t see all the flight model frames. (In fact, if your flight model is running at 20fps, you’ll see every other frame just like on the screen.)
So even though your plane is in a 20Hz roll oscillation (for example), you only see one side of it and it looks like a progressive, uncommanded roll in one direction.
What to do?
X-Plane 7.41 claims to have some measures to detect and control computational flutter. Time will tell how well they work. You can prevent it by staying inside the flight model “envelope”, i.e., by running X-Plane in such a way so that nothing changes too much from frame to frame.
- Fly heavier planes
- Don’t fly too fast
- Keep your frame rate up
You have the highest risk of computational flutter flying light, fast, powerful planes at low altitude in complex areas (where your frame rate will be the worst).
Why does my aircraft drift on the ground?
There have been long-standing complaints that aircraft standing still on the ground don’t stay perfectly still, but drift slowly in response to wind or engine forces. However, in 7.41 the drifting on the ground problem got far worse, with aircraft turning and drifting in the wind at absurdly high rates. Examination of some cycle dumps leads me to the following explanation:
X-Plane models wheel friction as viscous drag with a very large drag coefficient plus a limit on the amount of force that a wheel can generate (which is roughly the CF times weight on wheel).
This model is fundamentally incorrect for a couple of reasons. One is that even when it’s working right, it allows for a very slow rate of motion in response to small forces. (When was the last time you worried about parking your car outside over a windy night?) However, as implemented in X-Plane the rate of drift is slow enough that it’s only a problem if you leave the plane parked for an extended period of time.
But that’s not what we’re seeing in 7.41 – we see planes turning in the wind or drifting off the runway as if they were on ball bearings. The cause of this is computational flutter. (See general description above.) What’s happening for the ground friction case is, a small velocity, coupled with the large drag coefficient, yields a large opposing force. With even a modest frame rate, the opposing force gets integrated to an increased velocity in the opposite direction. In the next flight model frame that velocity translates into an even greater force in the opposite direction, etc., and the computation diverges instead of converging. The divergence stops when the force reaches the static friction limit, at which point you have the tires exerting their maximum static friction in opposite directions in alternate frames, which averages out to no friction at all.
I did a couple of experiments with the F-4 (selected just because it showed the most obviously absurd behavior when I first started looking). If I put it at a simple airport and severely cut back the visibility, I can get the frame rate on my laptop up to almost 40 fps. Under these circumstances the plane sits pretty solidly on the runway. But then I kick up the visibility and turn on the 3D clouds. The frame rate drops below 20 and the plane, with screeching tires, slides off the runway. A cycle dump taken under these conditions shows the lateral gear forces at maximum, with irrational side forces and torques on the plane.
As I mentioned, even with the model working right, the plane doesn’t sit completely still. In the 40 fps configuration, if I put a 20 kt crosswind on the F-4, it turns ever so slowly into the wind (maybe two degrees per minute). Under these circumstances, however, the gear forces in the cycle dump otherwise make sense, so the math is working right.
Fundamentally, the approach to static friction is wrong. Increasing the drag coefficient (to reduce the drift when the model is working) would only make it more prone to computational flutter. What’s needed instead is a special case for the static situation that locks the velocity to zero when the wheel is almost stationary. (This is a little harder than it sounds, because the case needs to be handled individually for each wheel, in the wheel’s frame of reference, for both forward and side forces.)
Later versions (7.62+) of X-Plane have somewhat addressed the ground friction problem by modelling a “breakaway” force on a plane that is stationary on the ground, and by introducing damping to try to eliminate the computational flutter. The problem is significantly improved but not completely eliminated.
kingla 