#442 YASim incorrectly treats a glide angle's vertical (z) component as a sideways (y) component.

[Anonymous]

Originally created by: colin.d.... (code.google.com)@gmail.com

While working on fixing bug 439, and tracing through the handling of glide angle in the YASim code, I've found a strange anomaly.

YASim stores the glide angle specified for cruise and approach configurations in the Airplane class's _cruiseGlideAngle and _approachGlideAngle members, respectively. When the solver performs a cruise or approach run (runCruise() or runApproach() in Airplane.cpp), the first thing it does is to call setupState() (also in Airplane.cpp) with the angle of attack, speed, and glide angle for the run.

setupState does the work of setting up a State object (defined in BodyEnvironment.hpp) containing the desired aircraft state:

void Airplane::setupState(float aoa, float speed, float gla, State* s)
{
    float cosAoA = Math::cos(aoa);
    float sinAoA = Math::sin(aoa);
    s->orient[0] =  cosAoA; s->orient[1] = 0; s->orient[2] = sinAoA;
    s->orient[3] =       0; s->orient[4] = 1; s->orient[5] =      0;
    s->orient[6] = -sinAoA; s->orient[7] = 0; s->orient[8] = cosAoA;

    s->v[0] = speed*Math::cos(gla); s->v[1] = -speed*Math::sin(gla); s->v[2] = 0;

    int i;
    for(i=0; i<3; i++)
    s->pos[i] = s->rot[i] = s->acc[i] = s->racc[i] = 0;

    // Put us 1m above the origin, or else the gravity computation in
    // Model goes nuts
    s->pos[2] = 1;
}

Note the line calculating s->v[] (line 440 in current GIT). In YASim, vectors are specified as [x, y, z], where x (component 0) is forward-back (along the aircraft centerline), z (component 2) is up-down, and y (component 1) is left-right. But here the vertical component of the velocity is assigned to s->v[1]; it should go into s->v[2]. s->v[0] is correct.

This is the result of the patch which added glide-angle support on 2007-01-17:

http://mapserver.flightgear.org/git/?p=flightgear;a=commitdiff;h=53f09ff6a571113640cc9add52e1ca449e3d1b73

Though this would appear simple to fix, note I have not tested a fix, since I don't have a flightgear build environment. This is purely by inspection.

I found this while trying to figure out why an YASim approach configuration wasn't giving me the glide angle I specified. It was producing something close, but the sink rate was somewhat high. Since s->v[0] is calculated correctly, and since the parameters tweaked by the solver (tail incidence and elevator) don't affect the y direction, I assume the solver ends up just converging for the horizontal component and gets something "close enough".

I guess this means that every YASim configuration which specifies a glide angle has always been computed a bit off, and so right now if you want a correct solution, you shouldn't use glide-angle at all. Sigh.

[Anonymous]

Originally posted by: colin.d.... (code.google.com)@gmail.com

Hmm, I'm wondering if perhaps the orientation may also be off. I'm not sure, since I don't know what the reference frame is supposed to be here (aircraft body frame or ground frame?), but perhaps the glide angle should be subtracted from the angle of attack when computing the orientation?

[Anonymous]

Originally posted by: emili... (code.google.com)@gmail.com

Just applied your suggested change. And apart from the obvious needed retuning of the fdm, I don't see any ill effects, but rather improvements.

[Anonymous]

Originally posted by: vivian.m...@lineone.net

glide angle wasn't in Andy's original computations - and I'm not clear that he ever really tested/approved it. You tinker with YASim at your own risk :-)

[Anonymous]

Originally posted by: colin.d.... (code.google.com)@gmail.com

Thinking about it, I'm now pretty sure the orientation is also wrong, if the original code (before glide angle was added) assumed a level flight path. That code had the velocity vector lying entirely on the X axis, with the aircraft's body axis lying within the X-Z plane, rotated upward from the X axis by the angle of attack. Thus the code assumed the X-Y plane was parallel to the ground. To preserve this assumption, the orientation should now have the aircraft rotated upward by (angle of attack - glide angle).

[Anonymous]

Originally posted by: bcoco... (code.google.com)@gmail.com

I would agree with the inversion error between s->v[1] and s->v[2].

However I don't think the glide path angle should be subtracted from 'AoA'. Indeed YASim seems to improperly call AoA the angle that the aircraft X axis makes with the ground (assumed horizontal). This is different from the definition of the angle of attack which is basically the angle between the aircraft and its velocity vector.

I would therefore say that although the naming AoA is confusing, the angles as they are entered currently in YASim will result in the correct calculations (provided that s->v[1] and s->v[2] are corrected as you suggests).

Labels: YASIM

[Anonymous]

Originally posted by: colin.d.... (code.google.com)@gmail.com

I've been thinking about making a further remark here for a while, but I've been putting it off. However, after this latest comment, I really need to speak up, because I think the comment is incorrect. I know I'm sticking my neck out by contradicting a developer, but so be it.

After working on tuning a YASim model for a while, and trying to understand how the code works, I now think that the idea behind the glide-angle option is simply broken, at least for approach, and it should not be used at all, because it violates the code's original assumptions. (This would fit with Vivian's assertion that Andy may have never tested or approved the glide angle addition.)

YASim is not using "AoA" to mean the angle that the aircraft makes with the ground. Rather, YASim is using a reference frame in which the relative wind is along the X axis, which may not be parallel with the ground. The glide angle code fails to take this into account.

This is confirmed by checking the solution reported by the command-line YASim solver from within Flightgear. Start with a working YASim configuration in which glide angle is not specified. Run it through the command-line solver, and note the elevator setting in the output. Then run it in the simulator using this same elevator setting, with everything else (weights and control and power settings) exactly matching that in the approach configuration. (Be sure that default settings assumed by YASim are also matched.) You will see that the angle of attack value is identical, or nearly identical, to that in the YASim approach configuration. The flight profile, however, will probably not be level unless you happened to pick a configuration which results in level flight. Rather, it may be a glide, or even a climb.

Indeed, YASim doesn't need to specify a glide angle to arrive at a solution at all. Once the speed, the angle of attack, the available thrust, and the drag produced have all been specified, there is only one stable solution in which the airplane is flying through the air at the specified airspeed and angle of attack. If the power required to move at this speed is less than the available power, the airplane will climb, increasing its potential energy at the rate needed to consume the excess power available. If power required and available exactly match (drag and thrust match), the airplane will fly level. If power required is greater than power available, the airplane will descend, losing potential energy at a rate sufficient to make up the power required.

Of course, YASim has to know the drag produced at that speed, but it seems that it has already determined this via other aspects of the configuration.

[Anonymous]

Originally posted by: colin.d.... (code.google.com)@gmail.com

Well, I'll be goddamned.

The state orientation matrix *is* supposed to be a global-to-local transform matrix, at least according to the comments in BodyEnvironment.hpp, which is consistent with how it is used to transform gravity in Model::calcForces() in Model.cpp. Which means that the orientation being specified in setupState() is indeed for a relative wind that lies parallel to the ground.

Yet, despite this, if you give YASim an approach config which actually requires a descent or climb, it seems that YASIM solves it, and the result configuration performs a descent or climb. But that would mean the forces were actually oriented differently from YASIM's assumptions.

Am I understanding this right? I'm getting quite confused.

[Anonymous]

Originally posted by: kanto... (code.google.com)@gmail.com

Colin, as I read the Yasim sources, I got confused myself.
I am still confused on some aspects even today, although I now have a better understanding of the code than 6 months ago.
What I can tell you is that some solutions adopted in the code, even if they seem wrong, are in fact based on real equations and correct within the framework.
There *are* subtle issues, like the fact that after drag calculations the fuselage does not see lift modifiers applied, the stall behaviour equations which are somewhat voodooish, the gear impact calculations which I have provided a patch for (that was unfortunately ignored :) ), the vstabs affecting solution and others.
I think you may be looking for issues in the wrong place.
Regards,
Adrian

[Anonymous]

Originally posted by: bcoco... (code.google.com)@gmail.com

It seems we are all getting confused here :)

Colin,

While re-reading my comment I realized that it was not very clear. When I was referring to 'AoA', I was talking about the variable 'aoa' in the code snippet you copied in the first comment of this bug report. I was not referring to the 'aoa' tags that are found in the XML definition file.

Furthermore, I now think you are right : it is the difference between the 'real aoa' and the glide path angle that should be entered in Airplane::setupState. And the variable 'aoa' in Airplane::setupState must definitely be renamed to something more meaningful like 'pitch' or 'pitchAngle' or 'phi'. This will definitely help people including myself to understand the code.

As a side note, fell free to tell me that I am saying rubbish things :) I am not a developer of YASim and even if I was one, I could be wrong anyway.

Bertrand.

[Anonymous]

Originally posted by: colin.d.... (code.google.com)@gmail.com

> While re-reading my comment I realized that it was not very clear. When I was
> referring to 'AoA', I was talking about the variable 'aoa' in the code snippet you
> copied in the first comment of this bug report. I was not referring to the 'aoa'
> tags that are found in the XML definition file.

Actually, I understood what you meant. I was simply wrong about the assumptions the code was making. It was realizing that which triggered my "well, I'll be goddamned" remark.

> Furthermore, I now think you are right : it is the difference between the 'real
> aoa' and the glide path angle that should be entered in Airplane::setupState.

Yeah, that would make sense, if the axes are assumed to be parallel with the ground.

> And the variable 'aoa' in Airplane::setupState must definitely be renamed to
> something more meaningful like 'pitch' or 'pitchAngle' or 'phi'. This will
> definitely help people including myself to understand the code.

I can understand why you'd want to rename it, but for gnarly code like this, unless you're absolutely dead certain about how things currently work, it's possible that renaming variables to better match what you think they represent may actually confuse matters further. The fact that the variable is currently named "aoa" implies that the code may be making hidden assumptions which are important elsewhere.

[Anonymous]

Originally posted by: bcoco... (code.google.com)@gmail.com

Colin wrote :
> Indeed, YASim doesn't need to specify a glide angle to arrive at a solution at
> all. Once the speed, the angle of attack, the available thrust, and the drag
> produced have all been specified, there is only one stable solution in which the
> airplane is flying through the air at the specified airspeed and angle of attack.
> If the power required to move at this speed is less than the available power, the
> airplane will climb, increasing its potential energy at the rate needed to consume
> the excess power available. If power required and available exactly match (drag
> and thrust match), the airplane will fly level. If power required is greater than
> power available, the airplane will descend, losing potential energy at a rate
> sufficient to make up the power required.

I think this behavior is definitely not acceptable since -according to the code- YASim is trying to trim the aircraft so that its vertical acceleration is zero. See the code below extracted from Airplane::setupState()

1036        if(abs(xforce/_cruiseWeight) < STHRESH*0.0001 &&
1037           abs(alift/_approachWeight) < STHRESH*0.0001 &&
1038           abs(aoaDelta) < STHRESH*.000017 &&
1039           abs(tailDelta) < STHRESH*.000017)
1040        {
1041            // If this finaly value is OK, then we're all done
1042            if(abs(elevDelta) < STHRESH*0.0001)
1043                break;

According to line 1037, YASim assumes 'it is done' when 'alift/weight' is very small ie when the acceleration in the vertical direction is almost zero. Therefore the vertical velocity should be constant ...but YASim also assumes the glide path angle to be zero as well. So the vertical velocity should be zero and remain so. This is obviously not confirmed by your tests.

I have my idea why YASim does not trim correctly in approach : the user should not be allowed to choose the thrust, it should be imposed by YASim. The problem is that the lift that YASim will calculate will depend linearly on the thrust chosen by the user (the slope is equal to the AoA). If the user puts too much thrust then the lift will be underestimated (assuming a positive AoA) and the other way around.

I will fill a bug report about that later on.

Bertrand.

[Anonymous]

Originally posted by: cumuluni... (code.google.com)@gmail.com

Ping?

Status: Stalled