[1.3.1] Ferram Aerospace Research: v0.15.9.1 "Liepmann" 4/2/18

[blowfish]

1 hour ago, AdmiralTigerclaw said:

@ferram4 

Are the following log entries produced by FAR during vessel construction?

*snip*

If so, I may have a really hard to trace CTD issue.

Some of them are, but they're 100% normal.  If you're crashing without an exception, it might be the infamous mystery crash, particularly if it happens when deleting a part or at scene changes.  This exception has been reproduced sporadically on all platforms and for both modded and stock installs.  It seems to be very configuration dependent too - changes such as removing or even adding a mod can cause it to appear/disappear.

[Van Disaster]

2 hours ago, cantab said:

Seemed to work in this. Flew nicely, albeit twitchy, normally, then went wild when I took it down to stall speed. Although I don't really know how to recognise a spin.

The start of a spin is one wing stalling - you can provoke it by giving a bootful of rudder when you're about to stall.

[AdmiralTigerclaw]

1 hour ago, blowfish said:

Some of them are, but they're 100% normal.  If you're crashing without an exception, it might be the infamous mystery crash, particularly if it happens when deleting a part or at scene changes.  This exception has been reproduced sporadically on all platforms and for both modded and stock installs.  It seems to be very configuration dependent too - changes such as removing or even adding a mod can cause it to appear/disappear.

 

Yeah, notice they're normal.  But I'll describe this CTD behavior for you.

 

As you mentioned, it behaves similar to the mystery crash.  However, it occurs not when I delete a part, but when I place a part off to the 'side' to hold it while I reorganize something.  It doesn't always happen, but it seems to only be when I place a part or part off to the side.  The CTD always, ALWAYS happens the moment I click to release the part into the open space of the build screen.  The only real clue I might have is if I say, duplicate a part using the ALT key.  That seems to greatly increase the tendency for this to happen from that part, and any other duplicates.  I also noticed a warning around that time about a part not being a child of a parent part. 

 

In the case of the above log, you're seeing the log up to the instance of the crash.  The crash occurred when I removed a solar particle experiment part (D-magic) and 'set it aside' because I wanted put a battery disk below it on an octo.  Normally, I notice, when I remove a part and set it aside, the voxelization log entry is the first message when I click to either add a part to a rocket, or release it to float in the build screen (effectively finalizing the change).  I suspected something in FAR could have been a problem from some kind of voxelization glitch with parts that are there, but not part of the vehicle.  Now, however, from what you said, and from that warning message I remember seeing, it may have to do with something about assigning ownership to a free floating part.  If it somehow loses what or where the free-floating part belongs, I could see it puking out a CTD from being unable to find that value.  If you want to pass this info along to someone who'd make good use of it, go for it.

[Kitspace]

10 hours ago, cantab said:

Seemed to work in this. Flew nicely, albeit twitchy, normally, then went wild when I took it down to stall speed. Although I don't really know how to recognise a spin.

I find a fair few of my FAR aircraft are hard to stall simply because they lack pitch authority, and if you can't stall her you can't spin her. No such problems with the above design.

That is exactly what I was talking about here previously.

Even if by constantly pulling up one gets the speed below what would be the stall speed for this plane the surfaces will stall partially but before they stall significantly or fully the plane will pitch back down and behave stable even if you keep pitching up.

And if you do not pull up on the stick the plane will just fly prograde like a ballistic shell down to almost zero speed just increasing the rate of descent as the lift decreases.

If you keep the speed from increasing somehow of course.

If you apply rudder here the plane will start to oscillate left and right wildly but will not spin.

And if the speed is high and you want to stall in a very tight turn for example the plane will just bounce off of the critical angle of attack and keep bouncing while you keep pulling on the stick no matter what your control authority is.

With the current aerodynamic modeling proper deep stalls and spins appear to be impossible or at least way harder to achieve than they should.

The real life planes just do not behave this way.

Edited May 22, 2016 by Kitspace

[ferram4]

First, talking about stall speed in relation to aerodynamics is (frankly) kinda silly.  It's a lie to children that engineers and designers give to pilots so they can use the readout they're more familiar with and more likely to have.  Never worry about stall speed, only worry about the angle of attack that you stall at.  And funny enough, if you can't reach the angle of attack that you stall at, you will never stall, and so never spin.  That is a realistic behavior and FAR won't compromise aerodynamic fidelity to make stalls happen at unrealistically low angles of attack to cover up poor plane design, nor will FAR boost control surface effectiveness well above where it should be.

Spins are possible, but most common KSP designs will naturally come out of spins because that's what they would do in real life.  If the tail stalls at a higher AoA than the main wing, the plane will easily come out of a stall or spin because it will pitch down very hard when that happens, just like in real life.  While PARE is very helpful for marginal planes or for getting out of spins faster, for many designs the plane will enter a spin, naturally spin around once or twice and then exit it.  Getting into stalls is harder since most KSP planes are absurdly over-stable compared to their real-life counterparts.

Also, if you continue to insist that these things don't happen, I've seen it happen developing planes for BD Armory battles; the AI manages to spin the plane and it easily goes into a steady tailspin until the AI lets the plane settle out (if it ever does).  Tailspins they tend to come out of, flat spins they never do.

Real life planes do behave this way, so long as they are designed identically to their KSP counterparts.

[larkvi]

2 hours ago, ferram4 said:

  If the tail stalls at a higher AoA than the main wing, the plane will easily come out of a stall or spin because it will pitch down very hard when that happens, just like in real life. 

Does one of the numbers in the data view specifically record this? I am prone to creating planes which enter flat spins, and if there is one number I need to pay more attention to, I would be interested. (I suspect the answer, as so often here, is a bigger tail, but I was trying to avoid adding more than I need to.)

[ferram4]

The stability derivatives are not used for that purpose.  Never use the stability derivatives for figuring out any behavior very far from the angle of attack that the sim calculates for steady flight in those conditions.  Instead, use the static analysis angle of attack sweep.  Forward surfaces stalling first creates a strong pitch-down moment, so that will appear on the graph as a severe drop in the moment coefficient (yellow) line when that happens.

The general way to achieve that is to make your tail have greater sweep or a lower aspect ratio than the main wing or forward surface.  Alternatively, if you don't care about easily coming out of stall regardless of whether you're pulling positive or negative AoA, you can build some angle of incidence into the main wing so that it is always at a slightly higher angle of attack compared to the tail.

[cantab]

3 hours ago, ferram4 said:

That is a realistic behavior and FAR won't compromise aerodynamic fidelity to make stalls happen at unrealistically low angles of attack to cover up poor plane design, nor will FAR boost control surface effectiveness well above where it should be.

And this is one of the reasons I'm so committed to and grateful for FAR. You have a clear goal of realistic physics, one that I think is in accordance with KSP itself, and you've stuck to it and done an excellent job.

(The other reason is that I consider the Analysis Tools basically "KER for planes")

[Kitspace]

@ferram4

I do strongly agree with your position on keeping things as realistic as possible at all times. After all that is exactly the thing I love the mod for and I think that is what most of those who use it love it for as well.

Therefore I would never suggest changing things towards decrease of realism. What I am trying to do here is to get an understanding of why things behave in the way the do and whether that is the intended behaviour. I never meant to offend you in any way and do apologize if it sounded that way.

Is not stall speed defined as the speed at which level flight is no longer possible as the angle of attack required starts to exceed the critical value?

You said that kerbal planes tend to be absurdly over stable compared to real ones most of the time. Why does that happen and how to deal with it? What is the realistic balance of stability and control authority then? As I understand most of real life planes do pitch down when the main wing stalls because delaying the stall of the tail plane and the elevator means maintaining pitch control authority for longer. Right? Then does the difficulty of stalling an average kerbal plane only come from the over stability?

If kerbal planes do not achieve the critical angle of attack even at maximum control deflection then where does the oscillation come from? For example roll the plane on its side and pull back on the elevator gradually increasing the deflection to maximum and keeping it there as if you want to make a very tight turn. Unless the plane is just heavy and bulky it is very likely to oscillate noticeably and constantly in the pitch channel. Even if you keep the controls steady for a minute this may not stop at at all. How to prevent that happening?

Thank you!

Edited May 23, 2016 by Kitspace

[ferram4]

2 minutes ago, Kitspace said:

Is not stall speed defined as the speed at which level flight is no longer possible as the angle of attack required starts to exceed the critical value?

That is correct.  Note that it assumes the ability to increase the angle of attack to the point where the plane stalls.  Yet your complaints seem to be about planes that will never drop down to stall speed because they lack the pitch authority to bring their angle of attack to the point where the plane actually stalls.  The wings remain completely unstalled even as the plane slows down and can't remain in the air.

7 minutes ago, Kitspace said:

You said that kerbal planes tend to be absurdly over stable compared to real ones most of the time. Why does that happen and how to deal with it? What is the realistic balance of stability and control authority then? As I understand most of real life planes do pitch down when the main wing stalls because delaying the stall of the tail plane and the elevator means maintaining pitch control authority for longer. Right? Then does the difficulty of stalling an average kerbal plane only come from the over stability?

The balance is almost always less stability than what KSP planes have.  Players simply over-stabilize their planes once they learn to build stable planes and also tend to build too small elevators.  Most flight being limited to -1, 0, 1 pitch inputs because of keyboard flight just encourages that. So move the CoM further back, the CoL further forward, and larger control surfaces.  But if it flies fine and it is stall-proof, why would you break it?

9 minutes ago, Kitspace said:

If kerbal planes do not achieve the critical angle of attack even at maximum control deflection then where does the oscillation come from? For example roll the plane on its side and pull back on the elevator gradually increasing the deflection to maximum and keeping it there as if you want to make a very tight turn. Unless the plane is just heavy and bulky it is very likely to oscillate noticeably and constantly in the pitch channel. Even if you keep the controls steady for a minute this may not stop at at all. How to prevent that happening?

Initially, that sounds like a simple short-period oscillation.  Simply stated: the plane has angular momentum.  That takes time to damp out.  Until that happens, the plane will oscillate in pitch, but that should disappear over a second or two.

Sustained oscillations, especially ones that jerk down quickly point to the plane stalling in the turn.  Maintaining control in this simply indicates that the plane's wings have stalled evenly, so there is no roll moment or yaw moment to throw it into a spin.  Given that most KSP planes are jets and that FAR does not model propwash for those that aren't, there is no source of roll or uneven flow in a zero-yaw stall.  So the plane pitches down and recovers.  If the plane is given aileron input or is yawed to the side then it will enter a spin, the severity of which depends heavily on how unevenly the wings stalled.

[kingstevenrules]

@ferram4 Dear Ferram,

Hi, I'm kingstevenrules, but just call me Steven. Anyway, I'm wondering if you still have a download available for KSP 1.0.5. My exact build is 1.0.5.1028.

Thanks,

Steven

[NoClass]

We should all probably stop and take note of Ferram's awesome explainer, above. From it, one can not only learn a bit about aerodynamics, but also how to teach aerodynamics. No easy feat. 

[blowfish]

26 minutes ago, kingstevenrules said:

@ferram4 Dear Ferram,

Hi, I'm kingstevenrules, but just call me Steven. Anyway, I'm wondering if you still have a download available for KSP 1.0.5. My exact build is 1.0.5.1028.

Thanks,

Steven

All previous releases are available here: https://github.com/ferram4/Ferram-Aerospace-Research/releases.  Looks like the latest version for KSP 1.0.5 was v0.15.5.7.

[kingstevenrules]

4 minutes ago, blowfish said:

All previous releases are available here: https://github.com/ferram4/Ferram-Aerospace-Research/releases.  Looks like the latest version for KSP 1.0.5 was v0.15.5.7.

Thanks!

[blowfish]

48 minutes ago, kingstevenrules said:

@ferram4 Dear Ferram,

Hi, I'm kingstevenrules, but just call me Steven. Anyway, I'm wondering if you still have a download available for KSP 1.0.5. My exact build is 1.0.5.1028.

Thanks,

Steven

Oh, and I forgot, welcome to the forums!

[kingstevenrules]

Lol, thank you for the welcome!

[Kitspace]

@ferram4

First of all thank you for your detailed response.

Is the over stability also related to the very unhealthy mass of the kerbal cockpits that pull the centre of mass forward?

Also if kerbal planes are more stable than real ones should they not oscillate less rather than more when they achieve equilibrium? Yet they seem to oscillate much more than real ones. I have never seen a real life plane make more than one or two slight pitch wobbles before stabilising almost instantly even after very sudden and quick stick movements. Talking about fighters and aerobatic planes here. Why is that?

[ferram4]

53 minutes ago, Kitspace said:

Is the over stability also related to the very unhealthy mass of the kerbal cockpits that pull the centre of mass forward?

Some of it is that, yes.  A lot more is people deliberately building over-stable designs, as I said.

54 minutes ago, Kitspace said:

Also if kerbal planes are more stable than real ones should they not oscillate less rather than more when they achieve equilibrium? Yet they seem to oscillate much more than real ones.

Not if they have less damping, whether that's a result of simply having small tail / canard surfaces or simply a higher angular moment of inertia.

56 minutes ago, Kitspace said:

I have never seen a real life plane make more than one or two slight pitch wobbles before stabilising almost instantly even after very sudden and quick stick movements. Talking about fighters and aerobatic planes here. Why is that?

Because

1. many real life planes are designed with fast-damping short-period modes.
2. many have stability augmentation systems to damp out those motions automatically.
3. virtually all have a self-correcting system called a "pilot" who has analog control over the system

Most KSP designs lack 1, 2 is often either off or not tuned properly, and virtually none of the tests in KSP are done with 3.

And in the end, nearly all of these come down to players not designing their craft to be identical to real life designs.  The only ones that are arguably not due to that are 2 and 3.

[Kitspace]

So things are pretty obvious about the two and three but how to achieve realistic results with number one?

What exactly does it depend upon that kerbal designs tend to lack?

[Klish]

First of all, thank you for this mod, it’s always the first one I look for when a new update rolls out!

I have two potential bugs to report, which I could not find prior record of. In my hard, 100+ mod career game, I had an early jet plane could not take off, as it insisted on spinning out on flat ground around 50-80m/s with no control input. The stability derivatives were all green at the default Mach 0.35, but in the 0.15-0.20 range, several turned red, including Xu. The cheatsheet I’ve written down from some of the guides on this forum says that positive Xu means there is a bug. Figuring another mod might be an issue, I downloaded a fresh install of KSP and manually installed FAR (and the dependencies) from SpaceDock. The craft still had the issue and I started playing with individual parts to isolate it.

I have found that there are several parts that appear to have a positive Xu at Mach 0.35 when initially placed, including the spaceplane cockpits, some landing gear, and cargo bays (not an exhaustive list). It will become appropriately negative if the parts are rotated. They all seem to seem to be parts with aerodynamic shapes/small cross sections perpendicular to the direction of travel so I would expect drag increase with increased speed to be small, but not for it to be the inverse! However, I am not an aerodynamic expert like you are, perhaps this is somehow expected behavior, or perhaps something wrong with just my computer?

As a result of this toying around, I have also found that the SPH FAR window will freeze, go blank, and requiring exiting and re-entering the building if you ask it to calculate stability derivatives when there are no parts placed.

I know that most people don’t build single part planes or calculate the stability derivatives of nonexistent parts. However, in the first case, adding more parts doesn’t seem to fix the issue, only mask it by outnumbering the bad parts with good ones, which can lead to problems with small planes and at low speeds. Thank you again for your continual work on this mod, and let me know if you need any more info!
 

 

 

Edited May 24, 2016 by Klish
Fixed picture link

[Bookstore44]

1. I think I found a bug: Placing M-2x2 Structural Panels at the front of a rocket caused a pitch down moment at high angle of attack, making the rocket very difficult to flip when it's traveling at high speed. Placing them in the back (like a lawn dart) caused a pitch up moment at high angle of attack, which made the rocket easily spin out of control. I am using KSP 1.1.2  on Windows with Ferram_Aerospace_Research-v0.15.6.5_Knudsen, and no other mods. I tested this using the ksp.exe and ksp_x64.exe; I assume ksp.exe is 32 bit.

2. The structural panels have higher lift coefficients than wings. Also much, much higher drag. Is the higher lift coefficient normal?

3. Google searches told me that tapered, swept-back wings stall from the tip, causing dangerous pitch-up stalls. I did not observe this in FAR. Is this effect real? If so, is it modeled?

4. The wikipedia page on stalls says that some planes, notably T-Tailed planes, experience "deep stall", where turbulent air from the main wings blankets the rudder, and makes it ineffective. Is this effect modeled in FAR?

5. Sometimes, when I move a wing around, the static analysis graph shows two stalls, like a staircase, one after the other. Usually, throwing out the wing, then grabbing it again from the parts menu fixes this, so there's only 1, clean, stall. Also, when i move a wing, then immediately run a static analysis scan, i get wrong info. waiting a bit before running the scan, and/or running the scan again fixes this.

6. The static analysis graph shows a small spike in the lift coefficient for dihedral and anhedral wings at 75 degrees angle of attack. I have nothing to say about it, i just thought it was weird and interesting.

7. Yeah, making a stable plane is easy, making an unstable plane is easy, but making a plane which tailspins must require advanced aerodynamics knowledge or something.

[Gordon Dry]

Two wishes:

• Non through-clickable windows
• Remembering windows positions

[ferram4]

@Klish: The Stability Derivative window starts by finding an AoA that allows the vehicle to achieve steady, level flight at the input conditions.  If that is impossible, it will return impossible numbers.  Very few single parts are capable of steady, level flight at Mach 0.35 at SL.

The window thing does sound like a bug though, but that should be a quick fix.

@Bookstore44: 1) that sounds about right.  Similar mechanism to how body lift works on command pods, in this case it's just the body lift having a greater moment lever than the drag so it has a greater effect.

2) That would be news to me; I can't substitute structural panels for wings in any situation and achieve flight.  You may also want to check the reference area for the vehicle, considering that will change and comparing coefficients from vehicles with different reference areas is invalid.

3) Real, implementation waits for wing overhaul.

4) Also waits for wing overhaul, if I can even find a way to implement it.

5) Dunno what's causing that, I can't reproduce the issue.

6) *shrug* not sure if that's valid, high angle of attack is very strange.

7) It's called, "making the wings stall unevenly" which will happen with high yaw (or less yaw and swept wings), aileron inputs at stall, or generally anything that causes more than pure pitch motion.  It's not difficult to do at all.

@Gordon Dry: 1) Already implemented for editor GUI, cannot be implemented for Flight GUI.

2) Already implemented.

[Gordon Dry]

Already implemented for the next release?

[Bookstore44]

@ferram4

1. are you sure? I mean, this rocket is incredibly stable (confirmed with flight test):

 

 

and this one is incredibly unstable, once its slightly off center (confirmed with flight test) :

Both pictures were taken inside SPH. Moving the panels farther from the center enhances the effect, so it must be a force on the panels, using the length of the rocket as a lever. But the lift must be positive, and the drag must be positive, so what force could it be? Whatever it is it would have to be stronger than the combined lift and drag forces on the panels, which are pulling the rocket off-center in situation A, and stabilizing it in situation B. This effect is really unintuitive to me. 

 

 

2. Yeah, you're right. It was the fuselage that had the high lift coefficient, not the panels, and I assume that the high Cl is intended in that case. I stacked 2 panels per wing so they looked like they were the same size as the wing connector type B i was comparing them to, but I guess the reference area was smaller. Is there a way to see/calculate the reference area, or the total lift produced by the plane at various angles of attack, so as to not get tripped up this way? 

 

 

5. It happens regularly when I attach a wing connector type B to the end of another wing connector type B.  I have a screenshot of it happening without stacking wings onto the ends of wings, and i managed to reproduce that once, but I can't find a reliable way to do it. Putting two wings really close together, such as a tail fin and a wing connector type B, also sometimes has a similar effect, but I can't find a reliable way to do that either.

Here are photos of two wing connector type B's attached end to end, and the two possible behaviors: