Overhauls for 1.0

[NathanKell]

Which is 1/2 * density * velocity squared. If in SI (with kg and meters and seconds) the result is in Pascals.

[Gfurst]

Q is dynamic pressure.

Which is 1/2 * density * velocity squared. If in SI (with kg and meters and seconds) the result is in Pascals.

Ohhh okay!

Correct me if I'm wrong... density will remain constant during transonic region? I've mean, will dynamic pressure continue to increase proportionally to the square of velocity? (not sure how this goes in RL)

In any case it should make things simpler... back to the floatcurve drawing board...

[NathanKell]

Dynamic pressure is calculated according to the static density, yes.

[Claw]

All,

Thanks to the Clawerator, I was able to understand how the wing lift is computed in KSP. It basically takes the lift rating of the part, adjusts it IAW the spline curves in the physics.cfg for Mach and attack angle, then proceeds normally with density and airspeed. I *THINK*...

But drag has me stumped. What value does it begin with for drag calculations? Do all wings with the same lift rating generate the same drag? Does it start with the wing's lift rating, or drag box value, or something else?

Thanks,

-Slashy

I cut this quote from another thread, but since I plan on really diving in, I thought it best to post this in here.

*cracks knuckles* Okay, lets see if I can do this thing...This is talking about wings only. Drag cubes and how they apply to other parts is a whole 'nother topic.

---

---

---

Real Life:

This is the venerable V^2 (V-squared) lift model. It's important to note here that this is a pure aero discussion. Inertia and rigid body interactions are not considered.

Factors inherent in flying, and not specified by the model itself:

• Rho (Density) - Comes from your flight regime, and is looked up in KSP through a curved value to approximate an Earth atmosphere.
  
• Velocity - Comes from your flight regime, and is used on a per-part basis, vice the whole craft. So, in fact, a plane that starts to yaw in flight produces ever so slightly more lift for the wing moving forward as compared to the one moving backward. One of the outcomes of this is that planes in KSP can simulate spins under the right conditions.
  

Factors inherent in design, and specified within KSP:

• Cl (Coefficient) - As noted in the slide, real life Cl is a complex interaction of events. This is the meat of KSP's aeromodel calculations, and is discussed heavily below.
  
• S (Wing Area) - KSP uses deflectionLiftCoefficient here. That is why deflectionLiftCoefficient is dependent on the part's physical surface area (but not thickness). So wings of equal surface area should have similar deflectionLiftCoefficient values.
  So, because deflectionLiftCoefficient is normalized to the wing's surface area, and all stock wings use the same Cl model, it results in consistent behavior for the "lego" style wings. Build a "lego wing" that sums up to 5 Lift Rating and it will act the same as a single wing that has 5 Lift Rating (from an aero model standpoint).
  

How does KSP build off of this equation is probably the root of what is being asked. The KSP model is as straight forward as "remove variable X and replace with Y". However, variable Y is actually a function (or series of functions).

---

---

KSP Coefficient of Lift Calculation

So Cl is really the piece that needs to be expanded upon. I know drag is what you are asking about, but at the basic level, lift and drag both use the same sort of calculation methodology. Since you say you understand Lift calculations, I'm going to re-explain all that to reinforce it, then discuss drag in a moment.

First, lets take a look at Porkjet's Delta Wing (delta.cfg) guts, pasted below...I've highlighted the relevant bits.

PART
{
	name = deltaWing
	module = Part
	author = Porkjet
	rescaleFactor = 1
	node_attach = 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 1
	CoLOffset = -1.2, 0.4, 0
	CoPOffset = -1.2, 0.4, 0
	TechRequired = aerodynamicSystems
	entryCost = 6400
	cost = 600
	category = Aero
	subcategory = 0
	title = Delta Wing
	manufacturer = C7 Aerospace Division
	description = Standard Delta configuration wings. These wings provide high lift and a stable center of gravity for your everyday lifting needs.
	attachRules = 0,1,0,1,1
	mass = 0.2
	thermalMassModifier = 8.0
	// heatConductivity = 0.06 // half default
	emissiveConstant = 0.95
	[COLOR="#0000FF"]dragModelType = none[/COLOR]
[COLOR="#FF0000"]	maximum_drag = 0.02
	minimum_drag = 0.02[/COLOR]
	[COLOR="#0000FF"]angularDrag = 2[/COLOR]
	crashTolerance = 15
	maxTemp = 2400
	explosionPotential = 0.1
	fuelCrossFeed = True
	bulkheadProfiles = srf
	MODEL
	{
		model = Squad/Parts/Aero/wings/delta
	}
	MODULE
	{
		name = ModuleLiftingSurface
		[COLOR="#FFA500"]useInternalDragModel = True
		deflectionLiftCoeff = 2.0[/COLOR]
[COLOR="#FF0000"]		dragAtMaxAoA = 0.6
		dragAtMinAoA = 0.0[/COLOR]
	}
}

The Red highlight is what was used in pre-1.0 KSP, and is now the "spherical model." This info has zero applicability in KSP 1.0.X aero. And to be complete, I don't know that any meaningful testing has been done to ensure that the old "spherical model" still uses this properly. I've seen zero posts from people on the forum who might still be using it (not to say that people aren't). The dragAtMaxAOA and dragAtMinAoA is unused in 1.0.X KSP aero.

The Blue highlight is info that was used in pre-1.0 KSP, and is still used but isn't strictly for lifting surfaces. The angular drag is really more of a rigid body thing (for all parts, vice specific for wings). "dragModelType = none" turns off the drag cubes for wings, whereas other parts specify "dragModelType = cube". It's entirely possible to have both drag cubes and wing lift/drag models active at the same time. Although that's likely to yield poor results...

The Orange highlight are the parts that are relevant for calculation of the lift and drag values. deflectionLiftCoeff is the same old variable it was in 0.90 KSP aero, just used as a scalar now (akin to Wing Surface Area -> S). useInternalDragModel specifies which of the Lift/Drag (AoA/Mach) curves to use from the Physics.cfg. This allows lifting surfaces to all use the ModuleLiftingSurface module, but can specify a different set of curves (Ignore this for now).

And here are the relevant pieces from physics.cfg which have to do with lifting surfaces (so lift and drag for the lifting surface). This is the default set of curves, which is used for wings and control surfaces.

[COLOR="#0000FF"]liftMultiplier = 0.036[/COLOR]
[COLOR="#008000"]liftDragMultiplier = 0.015[/COLOR]
...
LIFTING_SURFACE_CURVES
{
	LIFTING_SURFACE
	{
		[COLOR="#FF0000"]name = Default[/COLOR]
[COLOR="#0000FF"]		lift
		{
			key = 0 0 0 1.965926
			key = 0.258819 0.5114774 1.990092 1.905806
			key = 0.5 0.9026583 0.7074468 -0.7074468
			key = 0.7071068 0.5926583 -2.087948 -1.990095
			key = 1 0 -2.014386 -2.014386
		}
		liftMach
		{
			key = 0 1 0 0
			key = 0.3 0.5 -1.671345 -0.8273422
			key = 1 0.125 -0.0005291355 -0.02625772
			key = 5 0.0625 0 0
			key = 25 0.05 0 0
		}[/COLOR]
[COLOR="#008000"]		drag
		{
			key = 0 0.01 0 0
			key = 0.3420201 0.06 0.1750731 0.1750731
			key = 0.5 0.24 2.60928 2.60928
			key = 0.7071068 1.7 3.349777 3.349777
			key = 1 2.4 1.387938 0
		}
		dragMach
		{
			key = 0 0.35 0 -0.8463008
			key = 0.15 0.125 0 0
			key = 0.9 0.275 0.541598 0.541598
			key = 1.1 0.75 0 0
			key = 1.4 0.4 -0.3626955 -0.3626955
			key = 1.6 0.35 -0.1545923 -0.1545923
			key = 2 0.3 -0.09013031 -0.09013031
			key = 5 0.22 0 0
			key = 25 0.3 0.0006807274 0
		}[/COLOR]
	}

For each part (lift and drag) there are global multipliers and two curves: Cx(AoA) and Cx(Mach).

So lets look at Lift first, and all it's relevant bits. There's:

• liftMultiplier - Specified as a global tweakable value (in the Debug menu). Acts as a straight scalar for the whole model.
  
• lift (a float curve) - Specified how much to scale the lift force as a function of AoA. AoA is used as an index into the float curve, which returns a value. That returned value is used to scale the model.
  
• liftMach (a float curve) - Species how much to scale the lift force as a function of airspeed. Mach is used as an index into the float curve, which returns a value. That returned value is used to scale the model.

How does this really tie together. Well, recall that we are expanding Cl from the basic aero V^2 model. Cl ends up being a product of several look-up values, specifically lift and liftMach, while the liftMultiplier is a static scalar.

----> Cl = liftMultiplier(Constant) * lift(AoA) * liftMach(Mach)

Why are they set up this way?

• LiftMultiplier is needed to tweak the whole model up or down for changes. It makes model adjustment much easier on a global scale, vice including it in all the other curves and math.
  
• Lift(AoA) is needed so that wings actually act like what you would expect wings to act like. Pull back on the stick, you get more lift. This is just like a "real life" Cl curve.
  

LiftMach is the tricky one. It's really needed because the game consists of a series of lego parts all stuck together. So rather than trying to determine wing sweep, aspect ratios, and other things, the game simply uses this lookup curve.

Now we delve into Philosophy

The default LiftMach, or Cl(Mach) curve, generally scales lift UP as the craft goes slower, and scales lift DOWN as the craft goes faster. There's a variety of reasons for this, but the end result is that if you fly glider like planes at slow speeds, they fly like gliders. If you fly space planes or supersonic jets, they fly like supersonic jets. The pitfall to this is as I've stated elsewhere, you can create things that are "unrealistic" and you aren't bound by true physics.

This is the sticking point that seems to upset most people. "You worked so hard to create a real model, then do something like this." Well, we can debate about that all day, but rather than get drawn off onto that tangent, accept that this is the reality of KSP's aero model, and abuse it accordingly.

Recall that KSP is a game about building what ever you want. So this becomes a bit of a compromise. Players who want to build realistic designs are rewarded with mostly realistic behavior (from a game that focuses on space flight). While players who want to build wacky stuff can (for the most part) still get away with it. i.e. You want to build a sandwich stack of wings? You still can. Don't want to do that? Then simply don't do it. The user has a choice in the matter.

MODERATOR WARNING: Do not drag this thread off into a realism debate. This thread is about the nuts and bolts of KSP's aero model, not about the philosophy. If you want to discuss philosophy of aero modeling, go here.

---

---

Drag, You Promised Me Drag!

So lets start off with this again...

• Factors inherent in flying, and not specified by the model itself are still Rho (Density) and Velocity (V).
  
• Cd is calculated in exactly the same way as Cl, except that it uses the drag curves instead of the lift curves.
  
• The area in this slide is listed as A vice S, but in either case the game still uses coefficientLiftRating in the same way as described above. Recall that coefficientLiftRating is based on the wing's physical surface area (but not thickness).
  

The one notable exception with the wing-drag model vice the wing-lift model is the following, from Physics.cfg:

liftDragMultiplier = 0.015

This simply acts like another global modifier, which scales the coefficientLiftRating. This allows global adjustment to "how much drag per lift" is generated.

---

---

I think I'm done, my fingers hurt.

Cheers,

~Claw

Edited September 6, 2015 by Claw

[GoSlash27]

Okay, so I've been through this thread and picked up a lot, but I'm seeing something that seems to defy expectation:

For some reason the shock cone seems to exhibit less drag than the Tail Connector A.

Type/area/Cd/Depth

Tail Conn/1.21/.132/4.68

Shock Cone/1.21/.300/1.18

Surf. drag mult @ M1= 0.0025

Any ideas on why my empirical results aren't matching the prediction?

Thanks,

-Slashy

[The_Rocketeer]

[*] Velocity - Comes from your flight regime, and is used on a per-part basis, vice the whole craft. So, in fact, a plane that starts to yaw in flight produces ever so slightly more lift for the wing moving forward as compared to the one moving backward. One of the outcomes of this is that planes in KSP can simulate spins under the right conditions.

Does this mean that autogyro design should work in KSP? I'd never even considered this before...

Edited September 23, 2015 by The_Rocketeer

[Claw]

Yes. You can build helicopter-like bladed craft that will autorotate. In fact, I have some pictures here somewhere. There are some wacky things you can do with the "flaps" too, though they have quirks.

[The_Rocketeer]

I'm gonna have to try this now... thanks for the tip-off Claw!

[Claw]

The real trick is getting them airborne in the first place, since there aren't any stock actuators and such to be able to move the blades after launch. So you either end up with a blender going uphill, or you have to get creative.

Hence the "flaps" hint. Don't forget, there are also some cargo bays that might be of use. And if you don't mind the drag, couple a second set of counter-rotated blades behind the first. Then (when it's time) get rid of the second set...

You know, I've waited about 8 months for someone to figure this out.

Cheers,

~Claw

[The_Rocketeer]

You know, I've waited about 8 months for someone to figure this out.

Hahaha, well glad to oblige.

I built a successful autogyro and flew it in a short stint this evening. I slightly cheated by using bits from the KAX mod. The Kuey rotor (unpowered) made a great lifting rotor, and the Turboprop Aerosport prop (in reverse thrust) for propulsion. I had a few issues keeping my orientation on take-off, so I added a torque wheel and a few control surfaces, but once the rotor was up to speed I could turn off the SAS and had almost perfect level flight in a very gentle climb (about 1m per 5 seconds) steady at ~50m/s.

I tried to float down onto the VAB heli pads but that didn't end to well. Without the forward thrust the lift drops off very rapidly.

Sadly no pics tonight, but I'll try to put some up tomorrow when I've refined my design a bit. Thanks again for bringing this to my attention, now I feel like I've caught up since Slashy blew me away with his parasail.

Edited September 24, 2015 by The_Rocketeer

[The_Rocketeer]

I spent a long time today trying to build an all-stock autogyro with a stock rotor, but in the end I just had to admit that my stock bearing-making skills just weren't up to snuff. I managed to get the rotor/bearing freewheeling under a test using sepratrons to thrust them round, but every time I went for a take-off the thing either span too slowly or just didn't spin at all. It's not that I wasn't generating lift or even uneven lift, but the bearing was too friction-y and too loose, and the rotor just jammed in low-rotation-drag part of it's cycle.

I did get airborne a couple of times, but not in any sense that you could call a success.

So, in my weakness, I returned to KAX. Below are some pictures of a modded autogyro demo, including how it eventually killed Jeb. Note the lifting rotor, although technically an engine, is at no time activated or producing thrust.

Javascript is disabled. View full album

[mcirish3]

On 5/3/2015 at 2:20 PM, Claw said:

- Because of how drag cubes are built, open ended model parts can cause problems. Not all of these parts were adjusted to account for this, which is why there is some imbalance.

Was this not fixed a while back or is it still true?  If fixed you should correct the OP.

Also is there anything you can do to fix the highlighting issue in this post?

http://forum.kerbalspaceprogram.com/index.php?/topic/107254-overhauls-for-10/&do=findComment&comment=2165453

[NathanKell]

They should all be fixed in 1.0.5. Stock parts, that is, mod parts...heh.

[Claw]

22 hours ago, mcirish3 said:

Also is there anything you can do to fix the highlighting issue in this post?
 

I'll have to look and see if there's a way to color code manually in the code blocks. The editor does not allow coloring text directly when the text is in a code block.