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

[the_machemer]

6 minutes ago, ferram4 said:

@the_machemer: There is no bug.  You just have to turn the flight assistance off.  It's going to do what you tell it to do, unfortunately mind reading is not something I can code.  Everyone having problems needs to stop forgetting that they left the flight assistance on.

My bad, i forgot to mention that it keeps happening with the flight assistance turned off. I even restarted the game and it still persists.

Edited February 17, 2016 by the_machemer

[ferram4]

Then it is not caused by FAR.  The Flight Assistants are only ever active if they are activated by you.

[the_machemer]

1 minute ago, ferram4 said:

Then it is not caused by FAR.  The Flight Assistants are only ever active if they are activated by you.

Alright, thanks for the speedy reply.

[ferram4]

@Rodhern: Follow up; found the issue, turns out that it was the little zero-crossing marks that the graph adds.  When simulating a cylinder from the side, little numerical errors cause the lift, moment and L/D ratios to all hover around 0, but not quite on it, jumping above and below it every data point or so.  So it's trying to add a couple hundred zero marks and that gets expensive.  Added a quick sanity check to say that there are only ever gonna be 4 zero-crossings per line at most and otherwise to ignore them and it's fixed.

@m4ti140: Sorry, missed this initially.  Yeah, that's the long-term plan.  Ideally not providing the airfoils themselves, but instead families that you can tweak the camber and thickness of as necessary.  Ideal starting profiles will be the NACA 4-digit airfoils, the NACA 6A-series of airfoils, and likely supersonic diamond airfoils (which will likely not be camberable because camber in supersonic flight isn't very helpful).  But first I need to get the wing overhaul working.

[tetryds]

@FourGreenFields And once again you forgot that past the transonic regime the drag is a relationship between the transonic and supersonic drag 
 

[FourGreenFields]

8 hours ago, tetryds said:

@FourGreenFields And once again you forgot that past the transonic regime the drag is a relationship between the transonic and supersonic drag 
 

I didn't calculate anything myself, and thought that at a given air density, speed, etc. C_d is the only thing that changes drag. I didn't really care at all how that drag was generated.

[Bookstore44]

A rocket made in the SPH, facing fowards, consisting of a mark1 cockpit, a fl-t800 fuel tank, and an lvt-45 engine has a slight positive Xu that increases up to 0.251 at mach 0.6. At mach 0.61, the Xu suddenly changes to -0.05. When I hacked gravity to try to see the effect in-game, the Xu changed to be negative at all speeds. The github page said that a positive Xu means there's a bug.

@tetrydsThanks for the response. The video you linked was pretty good. You had to force your plane into it with roll and pitch controls, and you had your engine at full, so I'm still not convinced you can you make your plane spin without those, but that's still farther than I've gotten. Also, I'm confused about why your left wing is red, meaning stall, at 6 seconds into the video. Based on the navball, your nose is a few degrees above the velocity vector, meaning you're not rolling, not slipping sideways, and at a low angle of attack. 

I would share my craft, but I have nothing to show at the moment since my designs are fairly simple (jet fuel, a few wing connector type B's) and they don't spin.

Also, is the pitch down force caused by the back of the wing stalling less than the front, and thus the plane having more lift in the back than in the front? It seems like if I place the entire wing in front of the center of mass, then there is no pitch down force. A few months ago there was a pitch down force even with the entire wing in front, but I can't replicate that now. I'm assuming that was a bug which was fixed.

 

 

 

Edited February 18, 2016 by Bookstore44
minor typo

[ferram4]

And now, FAR v0.15.5.7 "Johnson" has been released, fixing a bug or two.  Changelog has the details.  FAR is also now hosted on SpaceDock, so do us all a favor and hug their server to death.

Anyway, questions:

@FourGreenFields: No, reference area also matters.  Otherwise the drag coefficient would increase for larger planes and that would defeat the purpose of creating a dimensionless coefficient for this.

@Bookstore44: Yes, I'll need to update the wiki; Xu being negative just means that the drag coefficient is dropping, it's not necessarily a bug.  Also, hacking gravity causes that to make sense since you've dropped the lift requirements down to nothing, so the drag from that has also dropped.

The way wings are currently modeled, the entire chord stalls at the same time, but the way the pressure distribution works out, that produces a pitch down moment about the wing's aerodynamic center.  That said, if the entire wing is far enough in front all the extra drag of the wing stalling might be enough to keep the plane from pitching down.  In any case, it sounds like your tail is stalling too soon and you should sweep it back / reduce its aspect ratio to help delay its stall until the main wing stalls.

[NajGeetsrev]

22 hours ago, ferram4 said:

And now, FAR v0.15.5.7 "Johnson" has been released, fixing a bug or two.  Changelog has the details.  FAR is also now hosted on SpaceDock, so do us all a favor and hug their server to death.

Anyway, questions:

@FourGreenFields: No, reference area also matters.  Otherwise the drag coefficient would increase for larger planes and that would defeat the purpose of creating a dimensionless coefficient for this.

@Bookstore44: Yes, I'll need to update the wiki; Xu being negative just means that the drag coefficient is dropping, it's not necessarily a bug.  Also, hacking gravity causes that to make sense since you've dropped the lift requirements down to nothing, so the drag from that has also dropped.

The way wings are currently modeled, the entire chord stalls at the same time, but the way the pressure distribution works out, that produces a pitch down moment about the wing's aerodynamic center.  That said, if the entire wing is far enough in front all the extra drag of the wing stalling might be enough to keep the plane from pitching down.  In any case, it sounds like your tail is stalling too soon and you should sweep it back / reduce its aspect ratio to help delay its stall until the main wing stalls.

Johnson broke my game :). The atmosphere does not slow down my craft at re-entry. I reinstalled Jacobs and it worked perfectly on the same save and vessel. What can I do to help you fix this bug? :).

 

P.s. keep up the great work!

[blowfish]

22 minutes ago, NajGeetsrev said:

What can I do to help you fix this bug?

Provide logs  (follow the first link in my signature if you don't know how to do that, but logs should accompany pretty much any support request)

[Pds314]

Thanks for fixing the Kerbal voxelization. I was having Kerbals impacting at Mach 3 after bailing from supersonic jets.

[Hodo]

On 2/19/2016 at 3:48 PM, NajGeetsrev said:

Johnson broke my game :). The atmosphere does not slow down my craft at re-entry. I reinstalled Jacobs and it worked perfectly on the same save and vessel. What can I do to help you fix this bug? :).

 

P.s. keep up the great work!

 

Did you remove the old FAR install before installing the new one?  And the output.log would be helpful.

[Paul_Sawyer]

Hello.
I need some clarification on the problem, that I posted in Deadly Reentry thread, since I feel that FAR is related to it.
Here's the picture:

Spoiler

Now I'm rather dumb at aerodynamics, but from what I know, at this angle of attack those two RCS ports on the back of the craft should be occluded from air stream and from heating it causes. In fact though, they are not only exposed to it, but they get even more blown than those on the bottom, which results in them getting more heating. It is not so obvious with only FAR, but along with DRE it causes some weird things like top ports overheating and exploding while bottom ones stay cool and "positive".

Here are the logs of my testing
KSP_log
output_log

Edit: oh, and I forgot to mention, that all the other ports on the back seem to act normal, problem is only with those two.

Edited February 21, 2016 by Paul_Sawyer

[Temeter]

So, I'm going back to FAR right now and experimenting a bit with WW2 style fighter planes, and it seems like i've unlearned a lot of stuff. Got a bit of an issue:

Plane flies ok, stability derivates and graphs seem all green and good, but as soon as my pitch AoA gets over ~15 degrees, the front wings and control surfaces basically explode with drag and kick the planes nose down again. Can someone please explain me why that happens, and how to avoid it to increase maneuvrability? Especially seems weird considering the design feels quite close to real fighter planes (bf-109 ín this regard).

edit: Hm, seems like that issue won't happen when the wings are offset to the back, instead of slightly to the front. But the real planes did have them this way? Even started up IL2 to check...

Pics, 2nd shows it (drag peaks even higher than here):

 

Btw, smaller question: Doe the settings for leading/trailing edges in b9 proc wings change behaviour in FAR in some way?

Edited February 21, 2016 by Temeter

[m4ti140]

Well, this is how planes work. It's called stall You actually didn't even stall (I haven't looked at images before posting) but the drag increase is normal, drag increases with AoA. If the pitching moment goes negative with increase in pitch then it's statically stable, this is how aircraft are supposed to work. WW2 fighters had to be stable, bc they didn't have Fly-By-Wire back then. You can make a statically unstable aircraft and keep it stable with Atmosphere Autopilot mod in FBW mode (FAR stability is assistance is usually not enough), but that wouldn't be a ww2 era aircraft

Anyway, to reduce stability move the center of mass and neutral point closer together. Shift wings and tailplane a bit forward and regenerate graph. The slope of Cm function (pitching moment coefficient) should reduce and the CoM and CoL markers should get closer together (don't trust the CoL marker though, check the stability derivatives). Make sure it doesn't flip and go positive though. Always check stability derivatives. This should reduce Cm_alpha and therefore reduce control moment required to maintain pitch. But it won't magically prevent your wings from stalling.

Also remember that a replica made of KSP parts won't have the same CoM location as the real one (or a simulation mode of that specific aircraft) Thus your lifting surfaces won't be in the same place either. A rule of thumb in case of such aircraft is that the CoM should stay between 25% and 35% of mean aerodynamic chord in all configurations. That is, you should check CoM locations with and without fuel (and take into account which tanks empty first) with and without payload, with landing gear extended/retracted etc. and make sure the CoM stays within limits. Or, since ferram provided us with great tools, check stability derivatives in each configuration seperately after each change you make to he aircraft.

Or just hit fly everytime and worry about details if it crashes and you have to find out why - this is the beauty of KSP after all.

 

 

 

 

 

 

Edited February 22, 2016 by m4ti140

[m4ti140]

As for second question: from what I noticed the total chord given to FAR is summed from leading edge, trailing edge and main width. The shape and proportions most likely don't matter.

[Styles2304]

Am I supposed to be gaining insane amounts of speed at low levels of throttle or is this a bug/issue caused by another mod? If this behavior is correct I'm not complaining I just want to clarify.

For example, I had my throttle at the first tick, engines almost cut, and I was still gaining speed at level flight.

I also can't seem to bleed off speed. Again, if it's just adjustments I have to make from stock aerodynamics I'm good with that.

Edited February 22, 2016 by Styles2304

[Rodhern]

Hi Styles2304

 

I haven't experienced quite what you describe, but I have noticed that my airplanes seems happier to speed up than to slow down.

The way I would go about sanity checking the setup is to make a few trials and take advantage of all that delicious aircraft performance data that FAR can show.

I in particular like the real time display of L/D. L/D is lift over drag and is found in the “FAR Flight Data” panel that you can open with the “Flt Data” button.

The lift to drag ratio, L/D, tells us how much lift our plane is generating compared to the amount of drag it is overcoming. We can assume that the lift force and gravity is roughly equal. The Kerbal rocket engineers might disagree because they launch stuff vertically all day, but for a steady level flying airplane it works out. That then means that L/D indirectly tells us how much drag our plane is subjected to.

The price of flight is drag, and knowing L/D means we know how much we are being charged. We have four payment options available. We can pay with airspeed, altitude, engine power or with a combination of the three.

 

Let us, pardon the pun, dive right into an example. I will make up some values to use for the example.

Parameter	Description
dt	time period for observation, say 3 seconds of flight.
g	gravity, roughly 10 m/s/s.
v	speed, say 150 m/s.
T	total current engine thrust, say 3 engines each running at 4 kN.
m	mass, say 12 tonnes.
L/D	above mentioned performance figure, let us say 15.
ls	speed loss during observation period, unknown for now.
la	altitude loss during observation period, unknown for now.

 

If we pay with airspeed only (engines off level flight) how much airspeed will be bled off during the 3 seconds:

g / (L/D) * dt = 10m/s/s / 15 * 3s = 2m/s

 

If we pay with altitude only (engines off but keeping the speed up) how much altitude is lost during the 3 seconds:

v / (L/D) * dt = 150m/s / 15 * 3s = 30m

 

If we let the engines run (level flight) how much airspeed do we loose or gain in the course of 3 seconds:

T / m * dt - 2m/s = 12kN / 12t * 3s - 2m/s = 1m/s

What I am trying to say is that the engine can potentially accelerate the plane by 3 m/s but we know from before that level flight will cost us 2 m/s, so we end up with a net speed increase of 1 m/s. In this made up example a modest 4 kN power setting will accelerate the plane past 150 m/s.

 

As an example of the fourth way of paying let us estimate the L/D performance of the airplane from the other seven parameters:

1 / (  l_a / dt / v  +  l_s / dt / g  +  T / m / g  )  =  L/D

 

The sanity check idea is to perform a two step process. For each trial, note the seven parameters on the left of the equation and compare with the FAR calculated L/D. This first step will help us determine if FAR plays by the rules. The second step is to decide if we think L/D is a reasonable value. If for instance L/D is forty or fifty the plane would need to be marvelously sleek for me to believe it. If L/D is much less than three and the plane does not look like a brick I wouldn't believe that either.

In the first step, in order to determine T, right click the engine(s) and read the current thrust (in kN) of each engine. To find m, you may bring up the map view where the total mass of your airplane (in tonnes) is listed.

 

My planes are not really up for the challenge, but I did try to fly one of my simpler propeller (KAX) planes.

My seven numbers are:

dt = 30 s, g = 9.8 m/s², v = 136 m/s, T = 3.2 kN, m = 5.1 t, l_s = 3.8 m/s, l_a = 121 m.

This gives an L/D estimate of:

1 / (121/30/136 + 3.8/30/9.8 + 3.2/5.1/9.8) = 9.4

For my example it turned out to be quite spot on, the questionable quality of my flying considered – the FAR Flight Data showed L/D in the neighborhood of 9.5. Strangely enough though, the SPH Static Analysis and Stability Derivatives predicts the Cd to be a little more than 0.012 for my particular airplane in that flight regime, yet the FAR Flight Data duly reports a very plausible 0.008 that fits with the L/D of around 9.5. The Stability Derivatives calculations show the proper Cl and AoA so I wonder why Cd is off.

 

I hope you or someone else is able to do at least one trial run (do not make dt too short though). It will be interesting to know how close you get to a reasonable result, and whether your plane lives up to the predictions made at the SPH?

Anyway, yeah, it takes an enormous amount of time to decelerate without brakes, chutes, reverse thrust or other purpose built arresting devices, and that is even when done within the rules.

 

Looking forward to learn more about FAR plane performance

Robert

 

[Styles2304]

Ok well, to make sure I was understanding the method properly I used your numbers to recreate your findings. Mine, with your numbers, comes out to 0.10660764305722288915566226490596 not 9.4. I tried grouping it a few different ways to get the same result but no dice. If you can show me what I did wrong here I'll go through the tests with one of my planes.

[Rodhern]

1 hour ago, Styles2304 said:

Ok well, to make sure I was understanding the method properly I used your numbers to recreate your findings. Mine, with your numbers, comes out to 0.10660764305722288915566226490596 not 9.4. I tried grouping it a few different ways to get the same result but no dice. If you can show me what I did wrong here I'll go through the tests with one of my planes.

The spacing I used makes it difficult to read. We are looking for

     1 / 0.106607643... = 9.380...

approx = 9.4

[Styles2304]

Ah! Ok . . . I'll try running some tests on my F/A 18 then and see what I come up with.

[Kitspace]

Hello!

I need a piece of advice.

Can you help me please?

Most of the more maneuverable plane designs that I attempt suffer from a particular behaviour for some reason. Even though those planes are statically stable technically and the stability derivatives are all green when required the numerical values of the stability derivatives are very small so dynamically the plane is almost unstable. It is very hard to stop from oscillating after any change in the control inputs whatsoever.

Even if I pull all the way back on the stick as if starting a vertical loop for example the plane instead of just settling on its maximum achieveable angle of attack and turning steadily that way starts to wobble around violently up and down as if all the pitch controls are quickly pulled between the maximum and neutral positions twice a second.

It is very hard to get rid of that effect. And I am not sure how to do it properly. What can I do in order to fix it?

Thank you.

[kcs123]

@Kitspace, that is better to ask in FAR craft exchange thread, but perhaps this picture can help ?

 

With screenshoot of craft and Sweep AoA graph with Pitch Setting = "1" you might get better answer.

[ferram4]

@Kitspace: Simple solution.  Make the plane more statically stable, which will also have the effect of making it more dynamically stable, or put more lifting surfaces further from the CoM to increase damping that way.  In general though, highly maneuverable planes are always more finicky than their less maneuverable counterparts.  It's the nature of the beast.  There aren't many other options, considering that the issue you're describing is basically continuously stalling -> recovering -> stalling the plane, so the only options you have are to increase the damping severely, cut back on control authority, or don't jerk on the stick like a madman.  Honestly, not jerking on the stick like a madman will probably be the most productive option though.

@kcs123: I... do not even have any idea what your image is supposed to show, why the peak of the L/D curve is even relevant here, and it's fairly clear that you're not optimizing for maximum maneuverability, so I don't know why you're bringing it up.

[kcs123]

@ferram4,  to minimize wooble, it is not relevant peak, but slope of L/D. When you set neutral pitching moment where L/D slope is steep you will get a lot oscilations until craft become stable. I have mentioned that if you aim for more maneuverability that you can set neutral piching moment for higher AoA, but it still need to be below stall point (also marked on picture). More info can be found in thread linked in my signature if somene want to find out more what I'm talking about.