How to calculate lift?

[unWinged]

I want to start building some planes and spaceplanes, but I want to be able to estimate how much lift will wings generate.

I know that lift and drag are mass dependent. And it can be represented as:

F_lift = mass*lift*v^2*C

where:

F_lift is lift force,

mass is mass of wing,

lift is lift coefficient,

v is velocity,

and C is some magic coefficient dependent on angle of attack and pressure.

I know it's crude, but should be sufficient for start...

To estimate C I made simple experiment:

This is CruiseJake, simple cruise missile

To estimate C I ignored many variables (like engine thrust and that there are more than just main wings on it)

So I got

force of lift equal of force of gravity (should work for simple calculation),

lift rating of wings 1.9,

mass of wings 2*0.07 = 0.14 t,

mass of craft = 6.956 t,

velocity = 149.2 m/s,

gravity = 9.81 m/s^2

and solving my equation for C:

C = mass_craft*g/(mass*lift*v^2)

C = 0.01106

NOTE this value is true for altitide 1350m on Kerbin and Angle of Atteck of 10 degree

I know it will suffice for simple planes and maybe some crude spaceplanes, and I will probably make some better experiments later...

But does anyone know actual lift equation for KSP or have some thoughts, advice or data?

P.S. I don't know why SPH picture is crappy jpg and in-flight one is png...

[numerobis]

Your equation is off in a few key ways:

- KSP lift is linear in airspeed, not quadratic

- It depends (linearly) on air density

- It depends on angle of attack according to some function I don't know. The function is different for control surfaces versus wings.

- It depends (linearly) on the lift coefficient of each wing part

- It does not depend on mass.

- I'm fairly certain the force is directed up compared to the wing (which isn't necessarily up compared to the cockpit).

I suggest a simpler testbed: roll carts down the runway with wings angled at various angles, and note down their takeoff speed. That will let you calculate the force of lift after a bit of trigonometry.

[unWinged]

I assumed that it depends on mass because drag is mass dependent, same with squared velocity.

And your test idea is great, will work with it later

With linear dependency on air density, which can be measured by pressure it should be easy to predict lift at higher altitudes.

Thanks

In my case I designed vessel first then came up with idea to test lift, and everything was done without thinking it through..

[numerobis]

There was a small group of us trying to figure out lift before the forum purge, this is as far as we got. At some point, the aerodynamic model will get improved, but for now, it's possible to get more lift than drag, which gets us the infiniglide bug.

[unWinged]

I hope that after aerodynamic improvements it will be more intuitive to calculate lift... For now I will make myself some kind of table with some basic estimations.

[ChevronTango]

So after some research and digging in the kerbal source binaries, as well as some experimenting with plugins and custom lift equations, along with debugging the forces by drawing in the vectors, I've actually managed to translate the nonsense lift equation kerbal uses into plain english.

CrossProduct(velocity, wingRight) * Cos(StupidAoA) * (1 - Abs(Cos(StupidAoA))) * Cos(AoA) * deflectionLiftCoeff * StaticAirPressure;

where AoA is the angle between the velocity and the forward vector of the wing,

and StupidAoA is the angle between the velocity and the upward vector of the wing,

wingRight is the vector to the right of the wing as placed, or can be thought of as the cross product of the wings up and forward vectors

The practical upshot of this I've found, noticeable when debugging in particular, is when rolling down the runway, quite often I'm producing a massive force downwards into the runway, explaining why I can't take off until I fall off the end of the runway and my angle of attack suddenly changes enough to snap my lift back upwards and I can take off.

The Control surfaces use exactly the same equation, but the velocity fed in is transformed first to adjust the result of the lift equation. I can understand why that's done, and I'll try and post the simple english of that specific transformation in the coming days, but it shouldn't be too hard to guess that.

I'm attaching some debug Plugins I've been using, if you change any control surface or winglet's module from "Winglet" or "ControlSurface" to "WingletDebug" or "ControlSurfaceDebug" respectively in their relevant part.cfg you should see the debug lines for lift and velocity drawn.

http://www./download/3ad8dn5rrk71h78/KSPLiftMarker.dll

[numerobis]

DeflectionLiftCoeff is the lift value listed in the VAB?

Careful with the "up" and "forward" vectors -- for a part in KSP, transform.up means up the stack, which is generally the forward direction of the spacecraft, whereas transform.forward is the axis that points away from the core of the planet when your plane is ready to launch on the runway.

Control surfaces definitely change the velocity a bit to take account of the control input. But the numbers are also different; max around 60 degrees rather than around 30, and max much higher.

[ChevronTango]

DeflectionLiftCoeff is the lift value of the wing specified in the VAB and in the cfg file, yes.

I'm aware of the differences between the up and forward vectors, the one's I've stated up there are the sensible interpretations of forward and up for a wing. (Forward is parrallel to the vector to the planets core when on the runway, not necissarily away from it. With the symmetry in the SPH, one wings' forward will be up and one will be down due to rotation, not reflection.)

The only thing that changes when a control surface is adjusted is the velocity vector that's fed into that lift equation, though I'm still trying to work out the exact tranformations used to adjust it. I imagine if that can be fixed to be more sensible, we may see the infiniglide bug dissapear.

It should be noted that the position on which lift acts on wings and control surfaces are different. With Wings and static lift surfaces the lift is aplied to the joint between the wing and the object its attached to, whilst with control surfaces the lift is applied to the center of the objects surface (read center of mass). The plugin I wrote demonstrates this.

Edited August 14, 2013 by ChevronTango

[Geschosskopf]

So after some research and digging in the kerbal source binaries, as well as some experimenting with plugins and custom lift equations, along with debugging the forces by drawing in the vectors, I've actually managed to translate the nonsense lift equation kerbal uses into plain english.

CrossProduct(velocity, wingRight) * Cos(StupidAoA) * (1 - Abs(Cos(StupidAoA))) * Cos(AoA) * deflectionLiftCoeff * StaticAirPressure;

So, how does wing area play into this? In the VAB and SPH, various parts say they have X amount of "lift", and in general the bigger the part, the higher the "lift" value. Does that mean anything at all?

I want to make an airplane with an insanely low wing loading, so it can fly at low speed even in the thin air of Duna. I have this idea that if I put as many wings on it as possible, it might work. But I don't see anything above about wing area.

[ChevronTango]

So, how does wing area play into this? In the VAB and SPH, various parts say they have X amount of "lift", and in general the bigger the part, the higher the "lift" value. Does that mean anything at all?

I want to make an airplane with an insanely low wing loading, so it can fly at low speed even in the thin air of Duna. I have this idea that if I put as many wings on it as possible, it might work. But I don't see anything above about wing area.

Near as I can make out, the wing area doesn't play a part in any way, only the lift value. The lift value is not calculated, its set by the part in its settings, so no doubt the Kerbal designers put in a higher lift value for larger parts. My advice for high lift to drag and weight ratios is to use delta wings. Angle them back 10 degrees and don't use two many, though for duna or some other atmosphere you'll probably want more.

Some quick calculations of the equations suggests that the ideal angle of attack is 25.7381 degrees. As in that generates the maximum amount of lift for the velocity input.

Edited August 14, 2013 by ChevronTango
Minor maths

[Geschosskopf]

Egad! That's actually depressing. But thanks very much for the pointers.

[The Lone Wolfling]

CrossProduct(velocity, wingRight) * Cos(StupidAoA) * (1 - Abs(Cos(StupidAoA))) * Cos(AoA) * deflectionLiftCoeff * StaticAirPressure;]

What about the drag value of wings?

[ChevronTango]

What about the drag value of wings?

the drag equations for all parts in kerbal are as found on the atmosphere page of the wiki.

the coefficient of Drag used in the wiki is calculated by the winglet thusly:

d = Abs(cos(StupidAoA))*NativeDragCoefficient;

where NativeDragCoefficient is the drag of the wing specified in the parts.cfg for it, and also noted in the VAB and SPH display for the part.

StupidAoA is as mentioned previously, the angle between the velocity vector and the wings upwards vector.

so a wing has no drag when its angle of attack is zero and maximum drag when the wing is perpendicular to the direction of travel, which makes sense when all things are considered.

Edit: It should be noted that with a breif look through the rest of Kerbals Source, this is the only example I can find of a parts drag not being constant

Edited August 19, 2013 by ChevronTango

[The Lone Wolfling]

Lift = CrossProduct(velocity, wingRight) * Cos(StupidAoA) * (1 - Abs(Cos(StupidAoA))) * Cos(AoA) * deflectionLiftCoeff * StaticAirPressure;

Drag = Abs(cos(StupidAoA))*NativeDragCoefficient;

Cannot you rearrange this, as StupidAoA = AoA + pi/2?

Lift = CrossProduct(velocity, wingRight) * sin(AoA) * (1 - Abs(sin(AoA))) * cos(AoA) * deflectionLiftCoeff * StaticAirPressure;

Drag = Abs(sin(AoA))*NativeDragCoefficient;

[ChevronTango]

Lift = CrossProduct(velocity, wingRight) * Cos(StupidAoA) * (1 - Abs(Cos(StupidAoA))) * Cos(AoA) * deflectionLiftCoeff * StaticAirPressure;

Drag = Abs(cos(StupidAoA))*NativeDragCoefficient;

Cannot you rearrange this, as StupidAoA = AoA + pi/2?

Lift = CrossProduct(velocity, wingRight) * sin(AoA) * (1 - Abs(sin(AoA))) * cos(AoA) * deflectionLiftCoeff * StaticAirPressure;

Drag = Abs(sin(AoA))*NativeDragCoefficient;

not quite, and this does raise a slight issue with the terminology I chose.

If you assume velocity is always in the plane created by the upwards and forwards velocities then your reduction hold true, however if there is a sideslip then the AoA I mentioned no longer is completely accurate, as its the angle between the velocity and the forward vector, which is no longer zero, despite the StupidAoA I mentioned staying at pi/2 (ie the wingUp vector is still perpendicular to the velocity) in this example. My naming of variables was a little off here so I apologise for any confusion it may have caused.

Assuming velocity is only ever forward, which for most simple calculations is a fair assumption, your simplification is valid.

Edited August 19, 2013 by ChevronTango

[The Lone Wolfling]

not quite, and this does raise a slight issue with the terminology I chose.

If you assumes velocity is always in the plane created by the upwards and forwards velocities then your reduction hold true, however if there is a sideslip then the AoA I mentioned no longer is completely accurate, as its the angle between the velocity and the forward vector, which is no longer zero, despite the StupidAoA I mentioned staying at pi/2 (ie the wingUp vector is still perpendicular to the velocity) in this example. My naming of variables was a little off here so I apologise for any confusion it may have caused.

Assuming velocity is only ever forward, which for most simple calculations is a fair assumption, your simplification is valid.

Oh, ok. About drag: what about air intakes?

Well, continuing in the same vein, let's assume AoA >= 0, and we're moving straight forwards.

Lift = velocity * sin(AoA) * (1 - sin(AoA)) * cos(AoA) * deflectionLiftCoeff * StaticAirPressure;

Drag = sin(AoA)*NativeDragCoefficient;

Force(Drag) = 0.5 * StaticAirPressure * velocity^2 * Drag * mass + otherDrag

Force(Drag) = 0.5 * StaticAirPressure * velocity^2 * sin(AoA)*NativeDragCoefficient * mass + otherDrag

[ChevronTango]

Oh, ok. About drag: what about air intakes?

Air Intakes are trickier. The base part has a native drag that's static, (for the ram Air Intake 0.3 defined in the part cfg) and that performs universally like all other drag on any object, however there is an additional intake drag on this part aswell which has some interesting maths.

I'll try and sum up both these in one equation to make life easier.

d = NativeDrag + Clamp(0.6 * velocityMagnitude * intakeSurfaceArea * cos(AoA), 0, 2)

where Clamp(in, min, max); is equal to Max(0,Min(1,in));

or rather

Clamp(in, min, max) {

if (in<=min) return min;

if (in>=max) return max;

return in;

}

so in summation the maximum drag for the Ram Air Intake is when its facing the velocity vector dead on and at sufficient speed, at which point the drag becomes 2.3, and when its side on perpendicular or backwards to the direction of travel its 0.3

I'm going to relook at this soon to make sure I haven't done something monumentally thick. The fact that we're using VelocityMagnitude is surprising to me, so if someone can check my research and/or maths I'd apreciate it.

Well, continuing in the same vein, let's assume AoA >= 0, and we're moving straight forwards.

Lift = velocity * sin(AoA) * (1 - sin(AoA)) * cos(AoA) * deflectionLiftCoeff * StaticAirPressure;

Drag = sin(AoA)*NativeDragCoefficient;

Force(Drag) = 0.5 * StaticAirPressure * velocity^2 * Drag * mass + otherDrag

Force(Drag) = 0.5 * StaticAirPressure * velocity^2 * sin(AoA)*NativeDragCoefficient * mass + otherDrag

Assuming those preconditions about the lift surfaces, yes, that's right, where otherDrag presumably is the rest of the craft's drag.

Edited August 19, 2013 by ChevronTango

[The Lone Wolfling]

d = NativeDrag + Clamp(0.6 * velocityMagnitude * intakeSurfaceArea * cos(AoA), 0, 2)

What about when closed? Just the native drag?

Also, this seems suspect. The radial air intake at 0 speed displays a drag coefficient of 0 open, and 0.2 closed.

The 0.2 closed suggests that it displays the total drag, but the 0 open suggests that it displays the additional drag only.

What gives?

[ChevronTango]

What about when closed? Just the native drag?

Also, this seems suspect. The radial air intake at 0 speed displays a drag coefficient of 0 open, and 0.2 closed.

The drag is just nativeDrag when the intake is deactivated/closed. This is yet another bug in the game, where when deactivated we set the intakedrag variable, which isn't being used by anything, to equal the nativeDrag variable, presumably as placeholder. The Upshot of this however is that the variable is used in the GUI, so when closed its simply the nativeDrag and when open its the intakeDrag without the NativeDrag. I shall lodge another bug report on this one. My decompiler didn't quite catch all the private properties and variable names correctly with this one so I can't be as specific in the bug report as I'd like.

Edited August 20, 2013 by ChevronTango

[numerobis]

The "NativeDrag +" bit is newish; used to be you could close intakes and they'd actually have zero drag. It changed in 0.20 I think, or maybe 0.19.

The dependence on area is a nuisance. If you have a part with an intake and you scale it up to twice the diameter (4x the intake), it now has 4x the drag at low speed. I've noticed this, though not I hadn't tracked down the exact code.

By the way, the reason I hadn't tracked down the exact code is that officially, Squad look down on decompiling their work -- and I don't really blame them.

[ChevronTango]

By the way, the reason I hadn't tracked down the exact code is that officially, Squad look down on decompiling their work -- and I don't really blame them.

I don't want to get into a debate on the subject, I'd feel antsy about it if I were them I suppose, but whatever happens now and however you look at it, we at least now have some solid formula's for lift and drag and a couple bug reports lodged that should hopefully help a few people out.

Edited August 20, 2013 by ChevronTango

[The Lone Wolfling]

So, with the proceeding data in mind, I decided to make a table to see what wings are the best. The results are... surprising-ish.

Name				Mass	Lift	Drag	Total Drag	L/D Ratio	L/M Ratio
Small Control Surface		0.01	0.5	0.5	0.005		100		50
Delta-Deluxe Winglet		0.02	0.7	0.6	0.012		58.33333333	35
Swept Wings			0.05	1.6	0.6	0.03		53.33333333	32
Structural Wing			0.05	1	0.4	0.02		50		20
Wing Connector			0.05	1	0.4	0.02		50		20
Delta Wing			0.07	1.9	0.6	0.042		45.23809524	27.14285714
AV-R8 Winglet			0.02	0.4	0.5	0.01		40		20
Standard Canard			0.04	0.7	0.5	0.02		35		17.5
Advanced Canard			0.04	0.7	0.5	0.02		35		17.5
Standard Control Surface	0.04	0.7	0.5	0.02		35		17.5
Tail Fin			0.02	0.3	0.5	0.01		30		15
AV-T1 Winglet			0.05	0.3	0.5	0.025		12		6

First off, interestingly enough, the best wings in terms of Lift/Drag ratio are the same best wings in terms of Lift/Mass ratio, with the exception of the delta wing.

Second, the basic swept wings are better than the various delta wings.

Also, the small control surface is the best, but the standard control surface is near the worst. Weird, huh.

Also, have you figured out the control surface calculations yet, ChevronTango?

Edited August 21, 2013 by The Lone Wolfling

[Radam]

So correct me if Im wrong, but at 23km at 1200ms lift for delta wing at 10° would be:

L=1200ms*0.01bar*1.9*0.141=0.03 t? For a spaceplane with 10 of those it would be 0.3t which is basically nothing.

[Radam]

Do rotating wings still work in 0.21?

[hydropos]

So after some research and digging in the kerbal source binaries, as well as some experimenting with plugins and custom lift equations, along with debugging the forces by drawing in the vectors, I've actually managed to translate the nonsense lift equation kerbal uses into plain english.

CrossProduct(velocity, wingRight) * Cos(StupidAoA) * (1 - Abs(Cos(StupidAoA))) * Cos(AoA) * deflectionLiftCoeff * StaticAirPressure;

Is this force acting in the direction orthogonal to the wing surface, or is this only the vertical component? If the former, then high AoA's would be bad, since a substantial part of the wing force would be fighting the engines.