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

[LameLefty]

I've just been learning this myself. I circularize at about 80-90km and then reduce my periapsis to about 30km. The re-entry is super gentle, but you need about 1/4 of the way around Kerbin to decelerate in the end. Also, make sure your ship is stable at high to low Mach when nearly empty.

That has been my general approach so far too. What I'm finding, however, is that if i come in belly-up my spaceplanes end up descending to about 35 km or so, then begin to increase altitude again and skip back up to over 40 km ... If I come in steeply, I lose altitude faster than I lose speed and risk structural failure due to aerodynamic loads. I gotta figure out a good happy medium here. Maybe install some B9 spoliers so I can drop altitude and speed faster when i get to that 35 km range ...

[DivisionByZero]

That has been my general approach so far too. What I'm finding, however, is that if i come in belly-up my spaceplanes end up descending to about 35 km or so, then begin to increase altitude again and skip back up to over 40 km ... If I come in steeply, I lose altitude faster than I lose speed and risk structural failure due to aerodynamic loads. I gotta figure out a good happy medium here. Maybe install some B9 spoliers so I can drop altitude and speed faster when i get to that 35 km range ...

I was varying my periapsis height even down to 0km and still getting the skip at 30km or so. One thing I found that helps is if you do some s-turns in the area of 40-35km. It really kills the speed and helps avoid the bounce.

[Tiron]

@entaran: The thing screwing with SAS is the fact that it isn't tuned for this. Control systems need to be tuned to function properly with the system they're hooked up to. SAS has never worked well with FAR, you just got really lucky with how the vehicle behaved with that particular iteration of FAR's physics.

The general rule is, if your plane needs SAS to fly, and you didn't intend to build the F-16, you designed it wrong. Redesign it to be more stable and stop using SAS as a crutch.

Okay, this I have to comment on.

First off, for minor instability, the SAS still helps quite a bit.

Second, it's a lot more useful than the flight aids, which I've never managed to get to do anything but interfere with the controls while still not really being effective.

Third, there isn't a useful guide I've ever found as to how to use a fair portion of the stuff FAR provides. It took some effort to be able to figure out how to interpret just the static analysis, and it's literally the only thing I use in the VAB because the data+stability derivatives and simulation tabs I have no idea how to set up, and even if I did get it set up right, the results are just meaningless numbers to me. I've glanced at the explanations for what they are, and could probably figure out what the numbers mean if I really wanted to, but I didn't see a thing that indicated that I'd gain any understanding of how to do anything with them other than interpret them.

Matter of fact, for the data+stability derivatives tab's help, the longitudinal and lateral motion tabs... I honestly don't know why 3/4ths of the stuff in those help tabs is even there. It's a lot of stuff about different aerodynamic motion modes (most of which I've heard of), but no indication at all of how that relates to the data. Only about a quarter of each of those tabs actually mentions anything that's included in the data itself, and that's just a key, with no indication of how to apply it. Explanations of Dutch Roll, the Spiral mode, Short Period Motion, and Phugoids are well and good, but not really all that helpful when trying to figure out which of the derivatives relates to the problem in question, let alone how to fix it.

It's a lot of general information, when what's needed is specific information. What types of things cause problems with particular things, how to correct common problems, what numbers to plug in to the various fields in order to get useful results.

The way most of it's set up presumes that the person using it already understands aerodynamics at a fairly advanced level. And if, like the majority of people you don't know squat about aerodynamics (or even if you know a small bit coming in), there's nothing to help you learn enough of it to be able to actually USE most of it.

You seem to spend a lot of time diagnosing problems with individual people's planes: most of this thread seems to be composed of such. Hell, that tip about the anhedral helped my planes a fair bit. There's probably a bunch more stupid things like that I could do to make them less annoying to fly ('annoying' is the extent of it. They're a TINY bit unstable, not enough to cause crashes unless I do something really stupid, but enough to require some regular tweaking to keep them at a reasonably steady altitude and heading.) But I have no idea what they are, because there's no ready way for me to learn it.

Other than pestering someone to death, which I don't really want to do.

Edited May 20, 2014 by Tiron

[rhoark]

It would be nice if there were some centralized place to find and peruse images of successful, stable FAR planes.

[softweir]

Okay, this I have to comment on.

<<< LOts of well-argued comment >>>

Same here. I spent ages trying to research the functions on the FAR analysis tabs by googling and ended up with a headache, as everything I found was either far too technical, or else far too terse. So I don't use those analyses; I experiment, throw bad ships away, and mainly use FAR to force me to build stack rockets and not go asparagus mad. I've got a long way by using the various rules-of-thumb that Ferram has given out, but I would love to be able to use those analyses and make the work Ferram put into them do something for me.

We really, REALLY, need a step-by-step introduction on all this. At the very least, we need links to digestible, pre-existing tutorials that use the same jargon that FAR uses.

[mdgates]

I empathize wtih the last three posters, and I'd love to see a guide to understanding aircraft stability. The answers you seek are out there, yet not incredibly accessible:

http://undergrad-catalog.buffalo.edu/academicprograms/ase_courses.shtml

MAE 436. BTW, see also MAE 425.

[Taverius]

You guys know there's a wiki right? Here

Add things to it

[softweir]

You guys know there's a wiki right? Here

Add things to it

An empty wiki.

[Tiron]

You guys know there's a wiki right? Here

Add things to it

I can't add things to it if I don't understand the things in the first place, which is kinda the point.

That said, if someone that DID understand it would add some stuff, it could be extremely helpful.

Edit: I'll mention also that the instability of my designs is EXTREMELY minor. The SAS damps what little of it is there most of the time, and the only time it really gets to be an issue is when I'm trying to pull the nose up to gain some altitude after it's dropped a bit too low while I'm in a mach 4.9+ cruise at 20km+. It'll either yaw off, roll off, or both(generally in the form of one and then the other). I can correct it, but it takes a fair amount of fiddling. Once I've got the correction in it's stable enough that the SAS will hold it, although it tends to let the nose drop a bit below where I left it (which I can usually compensate for by setting it higher than I want it.)

It's good enough that I can alt-tab out and only check on it every few minutes to make a correction once it's established.

Changing the wings from one tick of dihedral to one tick of anhedral (fairly minimal change, and still looks good) reduced it a bit.

Edited May 21, 2014 by Tiron

[DivisionByZero]

Here's what I suggest for figuring out how to build the planes: experiment.

Either download an example plane or build a new one. Fiddle and check numbers in the stability analysis. One thing I've noticed, if you're getting pitching moments bad it's a sign you might not have enough lift overall or your CoM/CoL are not in good positions relative to one another. If you have yaw control problems, you might need a bigger tail. But you can check this by doing the calculation with a tail section and then remove the tail altogether and then recalculate the stability. Check out how all the other numbers change when you add a tail, or canards. Sure, there's like 2 dozen numbers, you can start to get a feel.

[Starwaster]

You guys know there's a wiki right? Here

Add things to it

Wait... you're telling people to add to the wiki who you're referring to the wiki because they need information about FAR's aerodynamics and how it's giving them and their planes the shaft.

Question: How are they supposed to add to FAR's wiki if they can't figure out FAR in the first place?

[Drew Kerman]

Third, there isn't a useful guide I've ever found as to how to use a fair portion of the stuff FAR provides.

This will help a little bit, courtesy of the ever-awesome Scott Manley. But in general I agree that I really can't understand a lot of what the FAR analysis windows are telling me, even with the Help windows - which tell me what things are but not how that really applies to the behavior of the aircraft. Mainly, I get as few red numbers in the derivatives as possible, a good curve in the static window and then take her out to the runway and see what happens... usually works enough to see how the aircraft performs and then that sometimes helps me to understand better the data the FAR analysis windows are spitting out.

I'm sure ferram could write up a ton of great docs for us all to understand this better.... but then he wouldn't have any time to work on the plugin.

[HeadHunter67]

Question: How are they supposed to add to FAR's wiki if they can't figure out FAR in the first place?

Bingo. I often hear this kind of suggestion when someone comes asking a question, and I am astonished that you and I seem to be the only ones who've observed the impossibility of such a recommendation.

Those who do not know cannot possibly update the wiki! That should be the task of those who do have the answers - it's up to the author and the "expert users" to share what they ought to understand better than any of the rest of us.

[taniwha]

Tavarius' suggestion is for those who have figured some stuff out. Ie, they should use the wiki to share their information, and even to collect Ferram's rules-of-thumb.

[edit]Also, people can put their questions on the wiki for others to answer.

Edited May 21, 2014 by taniwha

[DaMichel]

It'll either yaw off, roll off, or both(generally in the form of one and then the other). I can correct it, but it takes a fair amount of fiddling.

This reminds me that if your are using procedural control surfaces, try replacing them with other pieces because those procedural control surfaces are slightly bugged (to check F12 -> Debug Log; hover with mouse over control surfaces; hit o on keyboard; see wing parameters; compare original piece with symmetric counter parts; you should see differences in mass, taper ratios and some others)

[thorfinn]

I must admit that yes, I'm also slightly puzzled as to why Ferram wants to teach aerodynamics to each of us one by one, instead of doing it once and for all with a manual

But I can copy here something he wrote me on Reddit one day, which may not be a manual but is still VERY useful.

Generally, the absolute magnitudes matter less than how they compare to each other, because they can scale strangely as the plane grows and different parts get used.Mw tells you whether the plane is pitch-stable. If this is wrong, the plane is going to want to do back-flips or front-flips.

Yb and Nb tell you if the plane is yaw-stable (it's side force due to sideslip and yawing tendency due to sideslip, respectively). These will almost always be the correct sign at the same time (unless you add a massive dorsal fin), and if correct basically make sure that the plane wants to fly straight rather than skate sideways.

Lb tells you if the plane is stable in roll due to sideslip. Roll angle itself doesn't directly cause a roll instability, but roll angle does cause some sideslip (plane's lift and gravity end up in slightly different directions, and this induces a sideslip velocity), and that sideslip can cause the plane to roll like mad. A lot of people who build planes with these afterthought-like vertical tails end up running into issues with this not being large enough compared to the other values.

Zw and Xu are basically just the effects of lift and drag, respectively (Z is positive down) as you increase downwards vertical velocity (increasing angle of attack) the plane makes more lift. As you increase your forwards velocity, the plane makes more drag. If Zw is incorrect, you're plane is very badly designed. If Xu is incorrect, you have summoned the Kraken and should file a bug report.

Mq, Lp and Nr determine whether pure rotation in pitch, roll and yaw (respectively) will damp out. It really shouldn't be possible to get them into the wrong sign without something else being unstable, but I suppose it's possible for very strange configurations.

The δe derivatives all tell you the effect of how the elevators and canards perform. If that's wrong, then somehow you've gotten your controls backwards; you want Mδe as large as possible while Xδe is as small as possible, since that means the most control authority possible with the least additional drag. Zδe is assumed to be correct for a standard tailplane design, so for canard designs it will be wrong (I'll make a change in FAR v0.13 to remove the coloring due to that reason).

Zq and Xq aren't really all that important, but they can make minor changes to the way a plane behaves under very large amounts of pitching.

Generally, Zu and Xw can be disregarded if their magnitudes are much less than the other ones. They basically consider how much additional velocity affects lift and how much additional angle of attack affects velocity, respectively; they can be the "wrong" sign at some angles of attack and Mach numbers due to Mach effects or nonlinear body drag.

Edited May 21, 2014 by thorfinn

[taniwha]

thorfinn: how about copying that to the wiki

[phoenix_ca]

Eugh. Now that I know the wiki exists, maybe I'll look at the wiki and see if I can add information about stability derivatives. But I'm not an aerospace engineer, and rather ill-suited to doing that.

[Tiron]

Eugh. Now that I know the wiki exists, maybe I'll look at the wiki and see if I can add information about stability derivatives. But I'm not an aerospace engineer, and rather ill-suited to doing that.

To be honest, it's not the 'aerospace engineer' version we really need. We need the quick-and-dirty rules of thumb, shortcuts, and 'if this then do that' type stuff. It's like so many things in this game: knowing the 'What' is more important than knowing the 'Why', because there's umpty billion tricks and tools to figure out the 'Why' for you. The 'fly to the Mun' trick is a good example of this: Burn Prograde shortly after the Mun rises in front of you. You don't need to know WHY it works to use it.

Even when you get into more advanced interplanetary transfers, you don't need to have a clue about any of the math or reasons behind a Hohmann transfer(or even that it's CALLED that for that matter), all you need to know is that you need to burn at the right Ejection Angle when your Target is at a particular Phase angle, and what the two angles are (which there's at least four ways to get that I know of.)

FAR seems to already *have* the tools, it's just lacking in explanations for how to turn the data they spit out into useful design information.

Edit: A good example in that thing someone posted up above: "Zδe is assumed to be correct for a standard tailplane design, so for canard designs it will be wrong." All my current planes have at least one thing showing up red, and they all use Canards, so I'm betting that's probably it. (no it's not, it's white.)

Edit2: I'm also having a problem with one of my planes...I went to tweak a couple things slightly and...doing so breaks the simulations entirely. Works fine until I change something, and then boom, sims seem to just crash. Console's full of 'NaN' errors.

Edit3: Okay, having read through that thing Thorfinn posted and looked at the stats on all four variants of my plane (which have some pretty large variances in how they're built), the problem seems to be coming from a large, very negative N-beta.

I also just discovered you can hover over the individual stats to get a directed explanation of what they are and what they should be. Which is...somewhat more helpful. Still doesn't tell me how to fix it (something ferram said about a 'strong vertical tail', on the other hand...)

Edit4: or not...changing the rudders isn't doing a bloody thing to it. It sticks on about -12.8 basically no matter what I do to it. Odd.

Edited May 21, 2014 by Tiron

[phoenix_ca]

To be honest, it's not the 'aerospace engineer' version we really need. We need the quick-and-dirty rules of thumb, shortcuts, and 'if this then do that' type stuff. It's like so many things in this game: knowing the 'What' is more important than knowing the 'Why', because there's umpty billion tricks and tools to figure out the 'Why' for you. The 'fly to the Mun' trick is a good example of this: Burn Prograde shortly after the Mun rises in front of you. You don't need to know WHY it works to use it.

I know, but speaking from experience, it's much, much easier to teach people a complex concept in simple terms when you understand that concept thoroughly. I have to admit I don't understand aerodynamics thoroughly at all, so, more likely to make gross errors.

Ideally there shouldn't be a wiki. Ideally, we'd have tooltips when we mouse-over those stability derivatives that explain them simply and clearly as well as giving ideas for how to fix things when they go wrong.

Good teachers are hard to come by. They need to so completely understand what they are talking about so as to easily explain the same concept in a myriad of ways.

Edited May 21, 2014 by phoenix_ca

[thorfinn]

thorfinn: how about copying that to the wiki

Well...

Tavarius' suggestion is for those who have figured some stuff out.

that might be tricky, I have been playing KSP infrequently these days and never had the time to get as good at FAR as I'd like Also, I didn't know about the wiki until now (like most people I fear). I can try to format that text in a way that works for a wiki though, right....

[DresCroffgrin]

To everyone who would like a guide on what the FAR tools in the VAB do:

I just completed my Junior year in Aerospace Engineering, which included a course in Stability, Control, and Flight Dynamics. I also have quite a bit of free time this week, but I do not have access to my KSP machine (just a laptop that overheats if I leave on KSP for more than a few minutes). I will try to type up some guides for the various aspects of FAR on the wiki, but it would be very helpful if those with questions could collect some specific questions into a cohesive list. Maybe even with some screenshots that I could use .

[thorfinn]

OK, the first thing I'll do is linking the reformatted stuff to you

[LameLefty]

To everyone who would like a guide on what the FAR tools in the VAB do:

I just completed my Junior year in Aerospace Engineering, which included a course in Stability, Control, and Flight Dynamics.

Considering I finished my junior year in Aerospace Engineering a full quarter century ago this week, I think you're the most qualified person for the job!

****

(And considering that until two days ago, I had no idea that there were FAR analysis tools available in the VAB at all, and considering that I've been able to build a number of reasonably functional SSTO spaceplanes already, I think my design intuition is still pretty good )

[DresCroffgrin]

Before writing about the tools in FAR, I am first adding some information about general concepts in aircraft design, so that everyone has a reference for terms and concepts that are dealt with in FAR. I just finished up my bit on static stability (still trying to decide what all to do with dynamic stability - it's important, but very technical). If anyone wants to read it and rate/hate for style, readability, clarity, etc., that would be awesome!