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

[Starwaster]

Fairing determine what pieces should by calculating the bounds of the fairing object and then searching through the vessel's parts to see if the part origin is inside the fairing. Since KW Rocketry parts have their origins placed at the center of the engine, they should be shielded perfectly fine; I'll investigate and see if I can find any errors.

What about the collision bodies on the piece I'm trying to turn into a fairing? On that interstate it doesn't extend the entire length. Does that matter?

Edit: HMMMMM. If that is whats wrong, maybe I should try moving the attach nodes to the other end and flipping the thing over

Edited December 8, 2013 by Starwaster

[Goozeman]

Fine, I'll leave them then. I'll just shift around the GUI so it's a little clearer (I hope).

Good news, we're getting different atmospheric compositions and more exact supersonic stuff! Eve and Duna are being modeled with CO2 atmospheres, and Jool with an H2 atmosphere. The speed of sound being 800 m/s, even in the upper Joolian atmosphere feels really, really weird. I do worry that the more exact shock relations might be noticeably more computationally intensive than the previous setup, but it was somewhat necessary for the atmospheric composition implementation. Also, I couldn't pass up an exact solution to the θ-β-M equation.

You found the closed form solution? The first time I wrote code to solve oblique shocks, I used a Newton solver, but I have since found a closed form solution. I have it in my compressible flow theory notes if you need it. You end up needing to solve a cubic in sin(β)^2.

[Goozeman]

I just installed kOS today. I'll have to go dig up the example PID code since I've wanted to learn how to do that anyways.

Farram gives you enough information that you can be more refined with your control theory than a simple PID control system. I won't get into the theory here, but the "Dynamic Stability" tab gives the info necessary to define the dynamic nature of the system, and therefore the resulting time-dependent flight characteristics.

[ferram4]

@localSol: Well, it requires spaceplanes with the fuel to return to land at Mach 1. I was able to bring the FAR Velocitas down at Mach 0.7 once, and the change in the speed of sound should be enough to bump that up. This was at one of the low points on the surface.

Don't make the mistake of assuming that gases and liquids behave the same way. Density largely doesn't affect the speed of sound of gases since the density of a gas is generally much lower than that of a liquid, and it is primarily dominated by temperature and the gas compositions. Ultimately, if you assume a calorically perfect gas, the speed of sound is only based on temperature and gas composition. And real gas effects aren't strong enough at most pressures to be worth modeling.

@Camacha: Ah, yeah, I should add the ability to choose the gas composition in the editor analysis to make sure that things are handled properly. I'll add something to the GUI that states the atmospheric composition with the specific gas constant for reference. The actual pressure numbers aren't changing, but I'll look into changing the density numbers so that the pressure-density relationship makes sense, and that will still be available in the GUI. If you want to actually know what's happening pressure or density wise somewhere, you'll have to send a probe down.

@Starwaster: Collision isn't used except for cargo bays, to determine whether they are open or not.

@Goozeman: Yep, sounds like we found the same solution. NASA contractor report 187173.

As an aside, I'm thinking that instead of making Laythe have the same atmosphere as Kerbin, that I'm going to cut in some portion of sulphur dioxide to explain the relatively high temperatures out there and make it more "alien." Now I just need to figure out how much is necessary to keep the same mass fraction of O₂ in the atmosphere so that there isn't a discrepancy between the intake air and the atmosphere.

[Camacha]

Farram gives you enough information that you can be more refined with your control theory than a simple PID control system. I won't get into the theory here, but the "Dynamic Stability" tab gives the info necessary to define the dynamic nature of the system, and therefore the resulting time-dependent flight characteristics.

One of the problems is that kOS can only read out a limited number of system variables, the FAR ones not included. I guess this is fair, as those variables are not easily/at all obtained by making measurements in the system itself (and that is what kOS does), but it limits modeling certain things.

[Goozeman]

@Goozeman: Yep, sounds like we found the same solution. NASA contractor report 187173.

Take a look at NACA TR1135. It has the cone shock solutions as well if you're interested. For slender bodies though, the linear methods usually suffice. Except once you understand that most KSP players don't have a clue about compressible flow theory.

[B787_300]

Are you actuality going to make Mach Calculations so that wasp waisting is a good idea?

[ferram4]

Probably not. The level of calculations that would have to be done to properly account for the area rule would introduce a very noticeable amount of lag for everything, since it would have to be done in real time to handle how the physics would change as the vehicle sideslips. Also, since we don't have parts that we can properly contour to properly area-rule our crafts, it would essentially be a feature that couldn't be properly taken advantage of.

[likke_A_boss]

Probably not. The level of calculations that would have to be done to properly account for the area rule would introduce a very noticeable amount of lag for everything, since it would have to be done in real time to handle how the physics would change as the vehicle sideslips. Also, since we don't have parts that we can properly contour to properly area-rule our crafts, it would essentially be a feature that couldn't be properly taken advantage of.

Lag is bad. Lag is very bad. Stay away from lag. He's mean.

[BrickedKeyboard]

For us newer aerodynamics optimizers, is there a way to tell how much delta V a rocket lost to friction? It occurs to me that the easiest way to refine a rocket design would be to just A:B test. For instance, does a procedural fairing help much? Leave the fairing part off the rocket in the VAB and launch. Check the delta V lost to friction. Then launch the same rocket with the fairing. In theory we could answer a lot of questions this way, including things like whether an extremely long and skinny rocket is better than a shorter and fatter one. It would also tell us how much delta V we are losing with horrendous Asparagus designs, versus a tall and skinny rocket.

[Camacha]

For us newer aerodynamics optimizers, is there a way to tell how much delta V a rocket lost to friction? It occurs to me that the easiest way to refine a rocket design would be to just A:B test. For instance, does a procedural fairing help much? Leave the fairing part off the rocket in the VAB and launch. Check the delta V lost to friction. Then launch the same rocket with the fairing. In theory we could answer a lot of questions this way, including things like whether an extremely long and skinny rocket is better than a shorter and fatter one. It would also tell us how much delta V we are losing with horrendous Asparagus designs, versus a tall and skinny rocket.

Correct me if I am wrong, but can't you do that already? It could be as simple as comparing how much fuel is left at a certain waypoint, but you could always calculate the delta v. If you want consistent flights to compare, you could always use MechJeb or kOS.

[taniwha]

simplest (and most repeatable) test: burn straight up, check apoapsis when your fuel runs out.

[DaMichel]

Hey Ferram, i just wanted to thank you for your hard work

I got into KSP after watching ramjbs aircraft design video and have been using FAR since the beginning. Very nice. Also the structural strengthening plugin. For everyones amusement here are some of my creations, because everyone likes pictures, right?

Javascript is disabled. View full album

The space plane is pretty cool. It uses the nukes from Interplanetary, so in theory it should fly on any planet with an atmosphere and make it back into space. I'm looking forward to trying it with your atmospheric improvements. Keep it up!

[rosenkranz]

I'm sure this has been asked before but the size of this thread....

I'm having trouble with landings. Normally without FAR I can land on a dime just using the landing marker from the MJ landing AP. But with FAR, I absolutlely suck at hitting a target. Is there any way for MJ to talk to FAR to at least ball park a landing trajectory? Barring that, have you considered adding a Estimated landing marker function? Barring that, any tips or tricks to landing with FAR in an atmosphere because I'm seriously not getting it. Any help at all would be greatly appreciated.

[Garek]

IIRC the problem with FAR and trans-atmospheric precision landing is that drag is no longer purely a function of the parts of the vessel, but very dependend on both it's shape and orientation. So for any kind of landing prediction to work, it would have to know your orientation during descend, when you activate the chutes, etc. And even for a specific descend profile, this would probably be excessivly complicated and (run-)time consuming (aka lagging). I think it's the same problem aerobraking calculations have with FAR: even given a specific descend profile, you need some time beforehand to calculate, and if you don't execute that profile exactly, the calculated results are worthless.

The simple solution of course is to just try repeatedly and get a feeling where you end up landing in relation to both vessel shape and descend profile.

EDIT: Real space agencies run simulations for stuff like this, I think. But in KSP, the equivalent would probably be Quicksave, try, Quickload instead of having FAR running a simulation which might not work out as stated above.

Edited December 10, 2013 by Garek

[rosenkranz]

heh, yes, i'm quite familiar with f5/f9. But even light can't escape the suckage of my landings.

However, even if FAR just gave a balistic impact projection based on current Cd (or a rolling average Cd to keep jitter down) would be better than what i'm seeing now.

So far I've tried leading the target landing zones by various distances and I can't get any consistency on hit or even coming close

[Garek]

Hm, doing a ballistic reentry with a capsule I can get it right into booster bay (aka in the water next to KSC) on a good day. I just do a deorbit burn to a ~20km Periapsis somewhere in front of the next continent after KSC (don't remember the exact location, and it varies depending on initial orbit). This isn't anywhere near precise enaugh for something like a base, but it's sufficient for we-don't-want-out-kerbals-to-walk-across-the-globe. I'm not sure how I would go about landing a base on an atmospheric planet. Some kind of indicator would be very helpful there, I agree. I also thought about writing some kind of self-correcting descend program in kOS, which would integrate using current drag loss, but that is still very much theoretical.

[Goozeman]

IIRC the problem with FAR and trans-atmospheric precision landing is that drag is no longer purely a function of the parts of the vessel, but very dependend on both it's shape and orientation. So for any kind of landing prediction to work, it would have to know your orientation during descend, when you activate the chutes, etc. And even for a specific descend profile, this would probably be excessivly complicated and (run-)time consuming (aka lagging). I think it's the same problem aerobraking calculations have with FAR: even given a specific descend profile, you need some time beforehand to calculate, and if you don't execute that profile exactly, the calculated results are worthless.

The simple solution of course is to just try repeatedly and get a feeling where you end up landing in relation to both vessel shape and descend profile.

EDIT: Real space agencies run simulations for stuff like this, I think. But in KSP, the equivalent would probably be Quicksave, try, Quickload instead of having FAR running a simulation which might not work out as stated above.

The trick with running re-entry simulations with FAR is that your vessel needs a stable axis to re-enter on. For example, the capsules are stable entering rear end first. Coefficient of drag is then only velocity (Mach number) dependent, and a simulation could be performed in such a configuration. A lifting-body reentry could still be done using a linear CL vs. Alpha and CD vs. Alpha plot. Probably wouldn't be quite as accurate, but that's the point of having a lifting body for reentry: you can tweak the trajectory as you reenter.

In order to take advantage of an entry profile like this with a more complex machine (rover/lander), you need to create an aeroshell with these properties. Playing with deadly reentry makes this a necessity for ANY atmospheric landing.

Also, purely ballistic reentries are not all that accurate. For example, the Mars Exploration Rovers (Spirit/Opportunity) had "landing ellipses" that were about 20km wide by 150km long. Mars Science Laboratory (Curiosity), by virtue of its powered decent, was able to attain a much smaller landing ellipse, but it was still about 20km long as I recall.

[drtedastro]

Ok, I am sure that I must be doing something simply wrong. I have MJ, latest dev build and update from MechJebFar running and latest FAR. I am 'trying' to use the MechJeb landing Guidance to help with pinpoint (closer than 3km) landings. I have, well I 'think' I have all FAR systems turned off. None of the tabs are selected and green. But, when trying to use LG, the craft makes initial deorbit burn ok, but then gets 'lost' and starts doing / going other places. I have read where MJ and FAR have issues on some points, but i 'thought' that by making sure that none of the tabs were selected that FAR was not being used. Seems I am wrong and thus, need some help.

Any thoughts, help would be greatly appreciated....

[gre8]

God, why did I take so long to download this? Flying planes is enjoyable again; I can even glide my spaceplanes to a smooth landing!

Hope Squad implements this as their vanilla aerodynamic algorythim.

[ferram4]

@BrickedKeyboard: Ultimately, the only way to measure that would be test flights. Most of the reasoning behind picking one aerodynamic configuration over another isn't so much to reduce the drag losses but more to protect the rocket from becoming unstable or breaking under the loading.

@rosenkranz & drtedastro: Yeah, MJ currently doesn't know how to handle FAR's aerodynamics, nor does it even detect that it's there and that the stock aerodynamic model it's using is wrong. I think that's currently being worked on for MJ, but any type of FAR-internal landing prediction is out of the plugin's scope. It would also be horribly inaccurate due to how much user inputs can change the trajectory in-atmo.

[drtedastro]

Ok, thanks for info. Is there anyway to be able to use FAR for ascent phase and then completely disable it for landing??

Thanks.

[taniwha]

drtedastro: difficult landings are the price for easy launches

[drtedastro]

Well put... Very well put.....

[Autochton]

For vehicles with atmospheric maneuvering, it might be worth it to watch what Scott Manley does in the 15th episode of his KSP Interstellar Quest series (

): He's built a vehicle on the same lines as the Space Shuttle, and reenters it much the same way: Turning in the high atmosphere at hypersonic speeds to bleed off velocity at a minimal cost in heating. By basically surfing back and forth between north and south of his target (the space center), he drains it of speed well before atmosphere becomes thick enough to cause problematic heating. It takes a while to do, but it seems a good use for remaining RCS fuel, although you could probably manage it on airfoils alone (in the case where your RCS has run out) with the right ship design.