How does KSP calculate drag?

[Xoxix]

I'm building a numerical model of KSP for a physics project. (i haven't a clue why my teacher lets me use a game for a school project either

I want to research the influence of launch angles and the timing of the in my ascent. For this, i need to know how drag is calculated in KSP.

Does it (I'm pretty sure it does) or where does it differ from the real thing?

[Black_Tomcat]

It differs quite greatly from the real thing, it really is just a placeholder right now.

It is calculated using the drag coefficient and the weight of the part (yep, the weight).

Here in the wiki is the whole formula: http://wiki.kerbalspaceprogram.com/wiki/Atmosphere

[Xoxix]

thanks!

how could I look over the wiki...

[K^2]

Real atmospheric drag can be modeled extremely well using F_d = C_d P_dyn A. Here, P_dyn = (1/2) ÃÂv² is dynamic pressure of the air flow of density àand velocity v. C_d is the drag coefficient. KSP uses a fairly small constant value for C_d specified for each part. Furthermore, real C_d depends a bit on velocity. It's going to be fairly constant at subsonic speeds, spike through the transonic region, settle on a new nearly-constant value in the supersonic, and start climbing again in hypersonic. Finally, A is the cross-section area as per the article linked above.

The way you'd typically use this is bunch together some of these constants, like k = (1/2) C_d A. That way, drag is simply F_d = kÃÂv². You can then experimentally measure k by measuring terminal velocity. Since at terminal velocity drag cancels weight, mg = F_d = kÃÂv_t², or k = mg/(ÃÂv_t²). The reason this works is that most imperfections of the model are absorbed into the value of C_d. If you were to try and compute it from the shape of the object, you are likely to end up being way off. But if you establish it experimentally, the rest of the equation works extremely well, and you can apply it towards anything from a bullet to a rocket.

Edited November 14, 2013 by K^2

[Traches]

If you're doing a physics project and want a better drag model, you should look into a mod called Ferram Aerospace Research. KSP's stock drag model is not even remotely realistic; a full tank creates more drag than an empty one, nose cones actually add drag rather than reduce it, and you can create infinite gliders by flapping control surfaces. FAR fixes that.

[Nuke]

Real atmospheric drag can be modeled extremely well using F_d = C_d P_dyn A. Here, P_dyn = (1/2) ÃÂv² is dynamic pressure of the air flow of density àand velocity v. C_d is the drag coefficient. KSP uses a fairly small constant value for C_d specified for each part. Furthermore, real C_d depends a bit on velocity. It's going to be fairly constant at subsonic speeds, spike through the transonic region, settle on a new nearly-constant value in the supersonic, and start climbing again in hypersonic. Finally, A is the cross-section area as per the article linked above.

The way you'd typically use this is bunch together some of these constants, like k = (1/2) C_d A. That way, drag is simply F_d = kÃÂv². You can then experimentally measure k by measuring terminal velocity. Since at terminal velocity drag cancels weight, mg = F_d = kÃÂv_t², or k = mg/(ÃÂv_t²). The reason this works is that most imperfections of the model are absorbed into the value of C_d. If you were to try and compute it from the shape of the object, you are likely to end up being way off. But if you establish it experimentally, the rest of the equation works extremely well, and you can apply it towards anything from a bullet to a rocket.

cD is a lets see what happens variable. when you design an aerospace structure its usually a big unknown, and has to be determined experimentally. literally stick it in the wind tunnel and see what it could do. you control all the variables so its easy to determine the cD from the data with math. you can then determine which regime of flight the structure is most useful. in a simulation this is probibly best represented as a curve (probibly based on a real world analog like a concorde fusalage or a naca 2412 airfoil) in the velocity domain from standstill into hypersonic.

cross sectional area can be tested procedurally in real time. the wind vector will always be changing so just using a dimensionless area area doesn't quite work out. the wind will always change aoa on the pitch and yaw axis and therefore the area exposed will not be constant. so in my last attempt at a flight model i used values for the cross section on all 3 orthogonal planes, placed into a vector and then dotted with the normalized wind vector (which was rotated into model space). i was rather happy with the result.

actually the hardest thing i had with my drag model was barometric pressure calculations. i started with a flat gradient, but apparently that is not a very accurate model for a planet's atmosphere. tempurature is a factor as well as density. i learned that real world avionics were calibrated around a more scientifically accurate model, so i used the standard atmosphere. looking around i found one for mars as well.

thats about as far as i got. my blob model as i now call it has one major problem, there is only one blob. i never got around to implementing multi-blob systems. im not sure what to do about blobs in front of other blobs. my theory is once you figure out the exposed cross sectional area for all the blobs, use that as the radius for a circle centered on the blob in the plane perpendicular to the wind vector. circle-circle intersection can be used to determine what factor overlaps between any two circles, just check every circle against every other circle and store the factor of overlap somewhere with subsequent factors multplied into it. then its just the sum of all the areas times all the factors. with that data i can not only determine total linear drag for the whole system, but also drag for each blob individually, giving me a means to compute torque induced by drag for the whole system. i never got around to implementing this idea, since i suck at math.

Edited November 15, 2013 by Nuke
oops

[K^2]

cross sectional area can be tested procedurally in real time. the wind vector will always be changing so just using a dimensionless area area doesn't quite work out. the wind will always change aoa on the bitch and yaw axis and therefore the area exposed will not be constant. so in my last attempt at a flight model i used values for the cross section on all 3 orthogonal planes, placed into a vector and then dotted with the normalized wind vector (which was rotated into model space). i was rather happy with the result.

That's basically what I did, except that C_D can also be different in different directions, so I absorbed the (1/2)AC_D into a single value, and built a drag tensor D out of it. Then the total drag was just ÃÂ(vDv). This probably isn't accurate enough for a real flight simulation, but for a game it works great.

But no, unfortunately, you can't use a bunch of these, one for each part, to figure out the total. Not in general. For an airplane, having drag center for fuselage and one for each lifting surface works well enough. I've built a pretty nifty simulator based on this idea. But if, say, your fuselage is built out of parts, you can't just look at how much of each "blob" is exposed. The total quadratic drag is due to a combination of a form drag and skin drag. For a long narrow body, nearly all of the form drag comes from the end points, but nearly all of the skin drag comes from the length of the object. And you can't really tell how much of your C_D is due to form and how much is due to skin.

[Nuke]

thats good to know. didnt want to implement a complex system that probibly doesn't work. since my game is not going to be a building game, i just need a way to describe the aircraft to the flight model. so a small number of blobs with no occlusion should be a sufficient abstraction.

[K^2]

Yup. And the only reason you need more than one is because difference in drag/lift on wings during turn is actually a significant effect while flying. Say you are in level flight and you decide to yaw left using the pedals. Plane ends up banking left as well. Why? Because your right wing is moving just a little faster than your left wing and generates just a little bit more drag. If you don't take this into account in your flight model, the plane will actually bank right due to torque from the rudder. On the other hand, when performing a roll, you'll also end up experiencing different drag on two wings, since the wing that generates less lift generates less drag as well. So all of these effects work together.

In principle, if you have a very simple airplane, you might only need the drag tensor for the body, and for the wings just do F_D = F_L/Constant. Except, you want to reduce lift past critical AoA only after you computed drag, so drag of stalled wing remains high. But with a more complex aircraft, you probably want to have engines have their own drag tensor, for example. Adding landing gear with its own drag tensor that turns "on" and "off" when gear is deployed or retracted is also a good idea.

But I don't know exactly what sort of craft you were planning on modeling. If it's something different from conventional airplanes, it might be way off.

By the way, having a bit of flight experience helps a lot. So if you are serious about writing a good flight model, you might want to invest in a few flight lessons. Just enough to get a feel for it.

[Nuke]

what i have in mind is a ground to orbit (perhaps beyond) combat flight sim in a scifi universe. so aircraft will essentially be aerospace fighters.

[K^2]

That's... Different. You'll have to get transitions between different regimes right, each with its own characteristics. With an airplane, you just aren't ever going to have to model the belly-forward flight correctly. With a re-entering SSTO fighter, you really do. And the problem there is that center of pressure is going to move as you change the AoA.

Ok, here is what I would do. I would still have only one form/skin drag computation per ship. I would model each lifting surface with one or more center of lift points. These would generate their own drag, but only lift-related. The fact that you might be re-entering belly-forward, with wings generating much of your shock wave, I would absorb into the body drag. The body drag object is going to be way more complicated now, however. I'd still keep 3 axes, but with each one I'd associate a center of drag and a C_D curve. The later should depend on velocity and absorb the effects of wave drag in transonic regions and increasing drag in hypersonic. Keeping in mind that transition regions are going to depend on speed of sound in your atmosphere, which depends primarily on temperature.

This is a pretty complicated model, but doable.

I was playing around with building an orbital combat game myself, but I wasn't really planning to touch atmosphere, at least initially. I got basic planet rendering going, and was working on ships. Got swamped in building ship computer systems. I wanted the thing to be very customizable, down to the firmware running on each ship.

[Nuke]

its also going to make weapons systems interesting. some weapons wont be possible to use in certain flight regimes. conventional guns for example probibly wont work past supersonic. some guns will fire scramjet and rocket equipped rounds so they can operate at higher mach numbers. space combat will feature recoil effects, and there will be some recoilless weapons. rounds fired will follow ballistic arcs. there will also be missiles and laser weapons as well. heat will be an issue, especially in space where you dont have airflow cooling the weapons, so care needs to be taken not to overheat, which causes jams and weapon failures (both accuracy reducing and weapon destroying). in space im going to use arc compensated telescopic gunsights so that very long shots can be pulled off.

[K^2]

For space combat, take a look at how Babylon 5: I've Found Her handled it. It's a free game, so just search for it. Go through tutorials. The way they did targeting system is pretty much perfect. Also, save for unrealistic accelerations and fighter dV resource, this is probably the most realistic space combat game I've ever seen.

[Nuke]

il be sure to check it out (its already downloading), b5 was awesome. i will probibly also need to also take some liberties with propulsion as well, such as engines with ridiculously high isp and exotic propellants like metallic hydrogen. engines will also be dual mode and capable of running on a large number of atmospheric compositions, so no propellant need be used while in the atmosphere. ships will have a compact fusion reactor of sorts to augment thrust through thermal or ionization effects. theres really no way around that, space fighters in general tend to spit in the face of hard sci-fi, so there will be some handwavium and unobtanium in there.

[CaptKasper]

Yup. And the only reason you need more than one is because difference in drag/lift on wings during turn is actually a significant effect while flying. Say you are in level flight and you decide to yaw left using the pedals. Plane ends up banking left as well. Why? Because your right wing is moving just a little faster than your left wing and generates just a little bit more drag. If you don't take this into account in your flight model, the plane will actually bank right due to torque from the rudder. On the other hand, when performing a roll, you'll also end up experiencing different drag on two wings, since the wing that generates less lift generates less drag as well. So all of these effects work together.

By the way, having a bit of flight experience helps a lot. So if you are serious about writing a good flight model, you might want to invest in a few flight lessons. Just enough to get a feel for it.

The reason an aircraft banks when yawing is because the outside wing in the yaw has an increased velocity of the relative wind. This generates more lift on the outside wing L=V²(D)(S)(AoA)/2. The reason the aircraft then yaws back is due to adverse yaw. For instance, if you yaw left your right wing will rise due to the increase in lift on the right wing in respect to the lift on the left wing. The aircraft then yaws back to the right because of adverse yaw. Adverse yaw is caused by induced drag on the raised wing. There is an increase of induced drag on the right wing because of the increase in lift. Any lift generated with a positive Angle of Attack will create an increase in induced drag.

[PakledHostage]

The reason an aircraft banks when yawing is because the outside wing in the yaw has an increased velocity of the relative wind.

Yaw-roll coupling in fixed wing aircraft is a complex subject. You are partly right but there are additional geometric and aerodynamic factors as well. In addition to induced drag and airspeed effects, there are induced angle of attack, pressure and geometric factors that also come into play. These are a consequence of wing dihedral angle, wing sweep angle, pressure fields induced by the location of engine nacelles and fuselage on the wing, etc. The vertical stabilizer plays a roll as well. Some aircraft (including most commercial airliners) even require active damping systems to damp out oscillations about their yaw-roll axes that result from their configurations.

Edited November 20, 2013 by PakledHostage
Tried to clarify a sentence

[K^2]

The reason an aircraft banks when yawing is [...]

I mistyped "drag" instead of "lift" where you highlighted, yes.

[Requiem762]

Each part is assigned a number that says how much drag it has.

[PlonioFludrasco]

Cross sectional area (A) is calculated as 0.008 x mass (m).

The question is: the considered mass is the dry mass (then it remains constant until you jettison something) or the fuel mass is included?

[K^2]

Cross sectional area (A) is calculated as 0.008 x mass (m).

The question is: the considered mass is the dry mass (then it remains constant until you jettison something) or the fuel mass is included?

Fuel mass is included. So the drag changes as fuel is used up, but terminal velocity remains the same. (Except for minor variations in drag coefficient.)

[ThinkOutsideTheHangar]

KSP just assigns a drag value to each part. So yes, a pancake shaped rocket could go into space. Try the Ferram Aerospace Research addon if you want realistic aerodynamics.