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

[BudgetHedgehog]

@Obsessed: Aye, that's me. Even changes significance between VAB and SPH; it's a warning in the VAB (because normally, it just calls for more boosters there) and a critical issue in the SPH (because it tends to limit you to M < 1).

Yer a wizard, ferram.. I didn't even know injecting custom reports there was even possible, let alone changing significance! Hot damn, do I love FAR... epic work, simply amazing

[BigNose]

Opened a new Issue on Github regarding the erratic fluttering of control surfaces set to follow AoA while the craft is standing still; easy fix should be disabling AoA control under a few m/s.

https://github.com/ferram4/Ferram-Aerospace-Research/issues/69

EDIT: Ha! It's Issue #69...

[B15HOP_xmen]

Opened a new Issue on Github regarding the erratic fluttering of control surfaces set to follow AoA while the craft is standing still; easy fix should be disabling AoA control under a few m/s.

https://github.com/ferram4/Ferram-Aerospace-Research/issues/69

EDIT: Ha! It's Issue #69...

Isn't that a stock problem? I'm sure vanilla has the same problem.

[ferram4]

@jrandom: Not the AoA control (which automatically changes the deflection of the control surface as the AoA changes), I meant build some angle of attack into it by default. Angle the vertical tails so that in straight flight they start at something like 5 degrees AoA.

@amankd: It's not that simple. I need to know all about the wingspan and where pressure can leak around the wings to get it right. A high AR wing will have ground effect at higher altitude than a low AR wing, for example.

@Obsessed: Actually absurdly easy to implement, and I can probably get a few more in there if necessary.

@BigNose: Agreed, fixed, closed.

[ferram4]

Alright, so FAR v0.15.1 Fanno is out. This is mostly a bug-bash, with a few nasty things that got into Euler being taken care of. Changelog has the details, as always.

Although it didn't get into this release, this has also laid the groundwork for area ruling accounting for the ducting through the inside of vehicles, which will be included once it's gotten a fair bit more testing.

[Jovus]

Have the wing-strength sliders been tweaked, or the way wing strength is calculated been changed? My wings seem weaker than before, but that might just be because I'm out of practice.

[Gfurst]

@Ferram

So ok, I've taken some pictures to compare, added some test and took a bonus flight.

I'm going to compare it with the de Havilland DHC-6, as it is more or less the closest I could find, and I've searched a lot, If anyone can find a better comparison please do.

The Dehavilland weights at about 4 tons, while mine is 6, referenced wing area seems to be 35,7m²(the ref area in the pic above if I'm not mistaken) while the DHC is 39 m².

Engines are not comparable, so lets consider powerless flight. The DHC stalls at 58 knots (really low) while in my previous test I was stalling around 45m/s or around 90 knots.

So yes, being a heavier aircraft mine shouldn't glide nearly as much, at the same it should handle better at lower speed, and with somewhat smaller wing ratio (basically 3 length x 1 wide) more drag.

A note on the AoA sweep graphs, you can notice stall angle should be around 15°, thats a bit low but still there should be a bit a more aggressive drop in lift and increase in drag.

Additionally I've did some more level flight tests, strapped on another flap to fill the gap and get the slowest speeds I could, moved engines as forward as I could since they're the heavier part still.

Minimum speed to maintain level flight: ~50m/s - 97knots with flaps full, ~62m/s - 120knots with flaps up. Surely that is way too high for the design.

As you can see I've used Pilot assistant to maintain nearly perfect levelness.

This becomes really evident when going for a landing, notice how I came powered off and much lower than a normal approach would be. The result is that I've ended over shooting the runway even nearly level with it...

As an side note, I gave the conventional landing gear (or tail-dragger) a try again, this time was successful

But still same result, needed to come in lower and slower, which is even more important with the tail-wheel stuff.

So my conclusions:

Yep, there is definitely a need to look better at this, maybe a tune up of global modifier, if there is such thing for FAR. Maybe the wings configs are being too generous.

Maybe a touch up on the drag coefficient for wings, maybe a touch down on the lift coefficient. Maybe you're not accounting for surface drag as enough.

By the way, I've read above that all given wings have a small AoA by default, you should most definitely not do this, leave a small lift for either the airfoil shape or for the user to setup it manually.

As it is in most cases, planes have to be nosed up relative to the air flow to keep enough lift.

Seems that people have been getting hyper-sonic quite easily, and so it may suggest indeed a balance issue. It is hard to diagnose alone on real world physics, as that is surely very hard to simulate in a game.

Let me know what you think about it. And about others too, please if anyone knows is experienced in aircraft performances as such, input in.

[ferram4]

For one, yes, the stall angle should be slightly low. FAR assumes that it's using a very thin airfoil, so only a peak lift coefficient of 1.6 without flaps.

Most of your pictures show that you're reaching a fair bit below the stall angle when you're at your minimum speeds, so I don't think you're stalling out; I think you're just getting screwed by the fact that your wings have no angle of incidence and are modeled as symmetric airfoils, so you need a heavy download on the tail to get them at an AoA so they produce lift. You're also getting screwed by the fact that the wing reference area for most planes is only the main wing, but FAR will use all lifting surfaces. So you've got a much lower wing area and 50% more mass, and you've got a stall speed twice as high... I'm not seeing the issue at all, this seems exactly right.

Now, I have no idea where drag stands on this, because I can't find the drag coefficient of this plane. This is one of the things I've been asking for again and again dammit. I don't care what the stall speed is, or any of this garbage. I care about things I can code: lift coefficient, drag coefficient. What are they?

Now, I also don't know where the hell you got this "wings automatically get some AoA by default" line, because they don't. That's not in the code. They don't, and I'm honestly kind of insulted that you think I'd take a solution that stupid.

So, in conclusion:

Your wing loading is so much higher than a DHC-6 that it's not a fair comparison.

You need to provide actual data that I can code, not the end results of that data, because backing that out is nearly impossible. The actual properties of the plane that the engineers get, not the simplified numbers given to pilots.

You're working with jets as well, and jets have much lower windmilling drag than props, so even if the drag is low compared to the DHC-6, it should be.

[CaelReader]

I'm finding it impossible to launch rockets with the new FAR. They all flip over and explode at ~400m/s. I'm not sure what's going on with the transsonic curves here.

[StevenRS11]

@ferram4,

I think I figured out a way to determine what's a 'wing' from your voxel models by looking at their surface area to volume ratios. That seems like the best distinguishing charateristic to use, just from looking at lots of pictures of KSP planes. Wings are thin, other parts are thicker. Now actually *doing* that is a different matter, but I think I know a way of doing that too, depending on how your voxels are represented and what they know about each other.

This is the process I am imagining-

1. If the voxels are stored as a graph, find the nearest voxel that is not adjacent and add it to a list if that distance is less than some amount. The idea is to find voxels that are separated by a thin volume. A bit of tuning would be needed to make this work, especially to find the right distance to look for nearby voxels- You could probably use the slope of the line relating voxels discovered nearby to distance searched. When the slope of that line changes very quickly, you have gone from finding flat, thin wing parts to thicker more sloped structural parts.

When you are done, each list would represent group of adjacent voxels, all forming a wing.

This other way would work if you didnt have a graph and just coordinates.

"Seed" the interior area of the voxels with small points, and grow these in all directions that are not constrained by the voxel boundary. Keep growing them until they reach a certain surface area to volume ratio. When they reach that, all voxels they touch form the outline of a wing.

Of course, this is all super broad, but I have coded a very similar algorithm but for 2D. I was drawing fractals, and I had a voxel representation of the outside of the fractal. I would control the iterations of the fractal in different areas until the structures where too thin too look good, and then stop it. I had a graph to work with, so I used the first method, but the second would have worked too. If you think this sounds like something you would use, I could probably manage to write it in a few days for you.

[ferram4]

@IrishBandit: It looks fine, with a few cross-sectional area changes where the parts change cross-section. Looks perfectly normal, though I think you need more fuel and engine. Stick to prograde, don't do anything funky, take advantage of thrust vectoring.

@StevenRS11: Well, considering that the voxel model is stored as a 3d array, I suppose the first one is possible. The problem is that this will merge a tail sticking out of a single thing. It might be possible to separate the two later, but I'm not sure how doable that would really be, especially considering that the wing representation also has to handle polyhedral wings.

Wouldn't this method end up being O(n^2) though, for n number of voxels? I mean, that's pretty expensive when you're talking about an upper limit of 250k items, and then you need to consider that some pople will push it higher.

[jrandom]

Wouldn't this method end up being O(n^2) though, for n number of voxels?

You could amortize the lookup cost by using an octree or other space-dividing structure. Octrees are probably the least adaptive but build times are fast. Other methods have much cleaner grouping but have longer element insertion time.

[Gfurst]

For one, yes, the stall angle should be slightly low. FAR assumes that it's using a very thin airfoil, so only a peak lift coefficient of 1.6 without flaps.

Most of your pictures show that you're reaching a fair bit below the stall angle when you're at your minimum speeds, so I don't think you're stalling out; I think you're just getting screwed by the fact that your wings have no angle of incidence and are modeled as symmetric airfoils, so you need a heavy download on the tail to get them at an AoA so they produce lift. You're also getting screwed by the fact that the wing reference area for most planes is only the main wing, but FAR will use all lifting surfaces. So you've got a much lower wing area and 50% more mass, and you've got a stall speed twice as high... I'm not seeing the issue at all, this seems exactly right.

Now, I have no idea where drag stands on this, because I can't find the drag coefficient of this plane. This is one of the things I've been asking for again and again dammit. I don't care what the stall speed is, or any of this garbage. I care about things I can code: lift coefficient, drag coefficient. What are they?

What the hell do you want? The lift/drag coefficient for the DHC-6, you could look into this, but I doubt even them engineers would know that. The Cd and Cl for my plane are right there in picture. 9.69 and 0.331

And as you've said, it doesn't matter because you know what airfoil You're using. And I don't think the AoA is wrong at all, that seems quite right to me.

What I'm trying to compare between two is more less size of the wing to the plane ratio, as pretty much nothing else is comparable. In any case, even with the bigger weight and smaller wings my plane glides a lot...

Now, I also don't know where the hell you got this "wings automatically get some AoA by default" line, because they don't. That's not in the code. They don't, and I'm honestly kind of insulted that you think I'd take a solution that stupid.

And I'm sorry about this, I thought to read it somewhere, but misunderstood.

So, in conclusion:

Your wing loading is so much higher than a DHC-6 that it's not a fair comparison.

You need to provide actual data that I can code, not the end results of that data, because backing that out is nearly impossible. The actual properties of the plane that the engineers get, not the simplified numbers given to pilots.

You're working with jets as well, and jets have much lower windmilling drag than props, so even if the drag is low compared to the DHC-6, it should be.

I'm just demonstrating that powered off, so it doesn't conflict, its evident specially in the landings. I don't know what the problem actually is, as I've said I don't know how to diagnose this, I'm just showing its symptom....

[Psycho_zs]

Hi!

And thank you for great mod!

I wanted to check if this is a proper behavior: 2.17t craft (Mk1 pod, service bay with science stuff, heat shield) dropped from ~20km (is it theoretically possible to launch rocket without fins?) While Mk16 chute is semi-deployed, around 10km the pod gained speed up to 1.3 Mach. Full deployment at 800m pulled about 14G. Is everything OK here?

Minor bug: when deliberately cutting the chute, message says chute failed due to high speed.

Also, here is a nice bugfix pack: http://forum.kerbalspaceprogram.com/threads/97285-KSP-v0-90-Stock-Bug-Fix-Modules-%28Release-v0-1-7d-6-Jan-15%29-Misc-Utilities-%2818-Jan-15%29 One of the tweaks involves spread of symmetrically placed radial chutes, looks nice, but works only for stock. Any chance something like that would end up in FAR?

[StevenRS11]

Actually, the first method is probably O(n) or maybe O(nlog(n) for thin features. Each voxel only searches until it finds one non-adjacent voxel, and then it stops, because that means it's on a wing. They all stop once they reach the distance limit, which is whatever the cutoff for max wing thickness ends up being. The voxels need to be in a graph, though, for it to run in log time. You end up with one big list of voxels that are separated by thin geometry, and that's it. You just pick one 'wing voxel' and follow all of its edges, checking if those voxels are also wing voxels. If it is, you remove it from the primary list and add it to a different one, which represents a single contiguous thin piece of geometry. Once all the remaining edges point to non-wing voxels, you are done with that wing. Repeat on the now-shorter unsorted list of wing voxels.

Its log time because the number of negative checks on the "is the adjacent voxel part of this wing" scales based on the boundary of the surface area of the wing voxels, essentially a one dimensional feature. Because it follows the surface of the wing it is almost always a positive check, and then those get removed from the pool for the next go around. Very little re checking a voxel more than once.

It would be O(n^3) with respect to wing thickness, though, because that's a 3D volume search. (I think?) If the thickness is very low, it shouldnt be too bad. Because all the searches done are limited radius volume searches, I don't think anything will scale primarily with the number of total voxels. Know, if it was just a big unsorted list of coordinates, then yea, it would. But hey, that's why voxels are great!

As for polyhedral wings, (or a tail fin sticking straight up out of a wing), you could calculate the angle of vector connecting the across-wing nearest voxel and the opposite wing plane. The opposite wing plane could be approximated from the directly adjacent voxels, and that angle could be used to determine polyhedral or a tail fin. Other wing parts could be split along a vertical plane following the axial symmetry line, too.

All that said, if its a 3D array and not a graph, then I am not sure how to use the first method. It really depends on each voxel outright knowing what's adjacent to it. That way one or two iterations through the list can just sort voxels based on their nearest neighbors into various lists, and then all those lists just magically turn into physically connected geometry.

I guess if you made sure that the maximum wing thickness was less than half the separation between two voxels you could still do it, but you would have to make a pass though the 3D array to build a graph of adjacent voxels. That wouldn't be a cheap operation, but it still would only really scale hard with the max wing thickness. Otherwise each cheap 'voxel.getAdjacent()' would become a tiny area search, which I guess still wouldn't be too bad anyway.

Also, if you have a little memory to spare, you can give each integer voxel added precision in the form of metadata. When you are building the voxel model, you can attach a few decimal places that represent the offset from the center of the voxel to the actual point on the geometry that you are measuring. All the advantages of integers with the precision of a float! Though you may already be doing that.

EDIT: I just thought of an even better way to do this, because voxels. You can collapse the step that sees if voxels are on a wing and the step that identifies single wings into one, and if you started with a way lower resolution sample (just to make sure you get atleast a single voxel on each wing) then you could probably make the the whole thing amortized O(log(n)) with respect to voxels. Well, with respect to voxels that arent on wings. No way around constant time for wing voxels, have to check each of those at least once.

Edited May 11, 2015 by StevenRS11

[Wanderfound]

Good news!

Aero failures are confirmed as no longer causing my laptop to crash:

Not such good news for Loberry, though...

[ferram4]

@Gfurst: I don't care what your plane's Cl and Cd are. I care about what the real plane's Cl and Cd are. You're the one talking about how the Cl and Cd are wrong, though you take the long way about it and talk about stall angle and glide slopes instead, so I was hoping that you had actual data on real plane Cls and Cds to work with. Guess not. And yes, the engineers do know those for a plane, it's how we design them and figure out whether they can do what they need to do.

Alright, so here's what we're gonna do to compare your vehicle.

You've got 50% more mass than the real thing. So that's gonna increase your stall speed right off the bat. Looking at just the main wing area (because FAR is slightly stupid and includes the area of tailplanes, even when it shouldn't), you've got 32.7 m^2 to the real thing's 39 m^2. Alright, so overall, that means if the maximum lift coefficients are the same, you need to go 33% faster just to stay in the air. Now, given that FAR only assumes an airfoil shape for stall angle (the other properties are lost in the drag of the wing itself), and that it assumes a rather low maximum Cl of 1.6, while you can easily get Cls of 2 without flaps on well-designed airfoils, you're now looking at a 50% faster stall speed. And we're not even considering whether your comparison vehicle and the real thing have the same lift on the tails; if you've got negative lift on the tail, that's just going to make things worse.

Now, as for gliding. That might be a problem. Maybe it's just the difference between jets and propellers. Maybe there's actually something there. I don't know, but I do know that I'm implementing the same methods used by engineers to design planes, and these are the numbers I'm getting out, and all of them agree with the literature or are on the high side. And I know that the drag coefficients that I'm getting for a lot of my replica planes are high. Hence why I want the damn drag coefficient for all the things that you're so eager to compare against so I can compare and see where the error is, if there is one.

@Psycho_zs: For one, no, that is not proper behavior, for two, you are using the most recent version, right? There were some bugs fixed related to stuff like that.

And that stock bugfix code is not needed for FAR. Completely different system.

Also, perfectly possible to build rockets without fins. Most of mine don't bother with them.

[Psycho_zs]

Using Fanno, trying to get this to orbit:

It starts flipping irreversibly some time after going supersonic, anywhere random between 6km to 20km.

Claw's bugfixes are not only about aero, there are other, both useful and cosmetic things in the pack like gimbal speed, MK3 strength, symmetry issues etc.

[ferram4]

Well, it's out of scope for FAR to really tweak any more than it already does, and it does already give 1.5x gimbal range because it's somewhat needed.

That rocket probably would benefit from switching out the non-gimballing engines for gimballing ones. That or add radial verniers for more control.

[futrtrubl]

Using Fanno, trying to get this to orbit:

https://i.imgur.com/ZlU8iqq.jpg

It starts flipping irreversibly some time after going supersonic, anywhere random between 6km to 20km.

At what angle of attack? That is the most important factor.

- - - Updated - - -

@Ferram

I think the problem is you are building something in KSP and then trying to find something similar to it in real life. Try finding something in real life that has the data Ferram needs and then build that as exactly as you can in KSP.

[Mipe]

Real life data does not fit in Kerbin scope.

[Psycho_zs]

At what angle of attack? That is the most important factor.

When it deviates past 1.5, only extreme luck will get it back. And it is pretty responsive, despite only one "Swivel".

On reentry and chutes: Dropping the same return stage from 25km with 200m/s horizontal speed, mk16 chute and two small drogues semi-deployed, it accelerated up to 1.1M on 11km, went subsonic around 9km.

[Gfurst]

@Gfurst: I don't care what your plane's Cl and Cd are. I care about what the real plane's Cl and Cd are. You're the one talking about how the Cl and Cd are wrong, though you take the long way about it and talk about stall angle and glide slopes instead, so I was hoping that you had actual data on real plane Cls and Cds to work with. Guess not. And yes, the engineers do know those for a plane, it's how we design them and figure out whether they can do what they need to do.

Alright, so here's what we're gonna do to compare your vehicle.

You've got 50% more mass than the real thing. So that's gonna increase your stall speed right off the bat. Looking at just the main wing area (because FAR is slightly stupid and includes the area of tailplanes, even when it shouldn't), you've got 32.7 m^2 to the real thing's 39 m^2. Alright, so overall, that means if the maximum lift coefficients are the same, you need to go 33% faster just to stay in the air. Now, given that FAR only assumes an airfoil shape for stall angle (the other properties are lost in the drag of the wing itself), and that it assumes a rather low maximum Cl of 1.6, while you can easily get Cls of 2 without flaps on well-designed airfoils, you're now looking at a 50% faster stall speed. And we're not even considering whether your comparison vehicle and the real thing have the same lift on the tails; if you've got negative lift on the tail, that's just going to make things worse.

Now, as for gliding. That might be a problem. Maybe it's just the difference between jets and propellers. Maybe there's actually something there. I don't know, but I do know that I'm implementing the same methods used by engineers to design planes, and these are the numbers I'm getting out, and all of them agree with the literature or are on the high side. And I know that the drag coefficients that I'm getting for a lot of my replica planes are high. Hence why I want the damn drag coefficient for all the things that you're so eager to compare against so I can compare and see where the error is, if there is one.

I think you misunderstood me, the only original issue I had was that planes tend to glide way more than its expected, with power off its very hard to lose speed. As Mipe mentioned, I might be thrown off by the KSP ratio, where as there seemed to be a lot of wing for the plane, but the KSP parts are incomparably too heavy for them. I wasn't complaining for not getting enough lift at all, its quite the opposite, I'm complaining is quite hard to get the plane to slow down instead... Now given, propeller planes suffer indeed from heavy drag when tuned down, but mostly sure all planes will almost immediately lose speed and altitude when powered off. The level demonstrations were more to show just how long it took to lose speed without loosing altitude, the minimum speed in the last one were just for the fun of it.

I think the problem is you are building something in KSP and then trying to find something similar to it in real life. Try finding something in real life that has the data Ferram needs and then build that as exactly as you can in KSP.

Real life data does not fit in Kerbin scope.

Now I'm aware if I want lower speed I need to account for the heavy weight of KSP parts. Still, I'll try to look for something good to compare and then try to test it. Specific data like that is quite hard to find.

[Goddess Bhavani]

I tried your craft and it doesn't seem to work (installed the other mod).

Flipped straight up and then eventually killed itself with sheer G force changes.

@B15HOP_xmen

I boosted the elevator controls to shorten the takeoff roll, by way of 'negative flaps'. IIRC some modern fly by wire aircraft also flip their tail feathers to induce pitch up, then revert to normal control ranges once airborne. F-35 is one of them.

Once you rotate, immediately revert elevators to normal position by hitting the '2' key twice or visually inspecting the ailerons. Accelerate to transonic at medium altitude, and you can then turn off SAS and fly with trim controls or gentle stick input.

Also see notes on DPCR in the craft description. It will indeed rip itself to pieces without DPCR since I needed to make the plane responsive all across its flight envelope.

Well if I could video it... it could be made to work

[futrtrubl]

Real life data does not fit in Kerbin scope.

It does fit in FAR scope though.

- - - Updated - - -

I think you misunderstood me, the only original issue I had was that planes tend to glide way more than its expected, with power off its very hard to lose speed. As Mipe mentioned, I might be thrown off by the KSP ratio, where as there seemed to be a lot of wing for the plane, but the KSP parts are incomparably too heavy for them. I wasn't complaining for not getting enough lift at all, its quite the opposite, I'm complaining is quite hard to get the plane to slow down instead... Now given, propeller planes suffer indeed from heavy drag when tuned down, but mostly sure all planes will almost immediately lose speed and altitude when powered off. The level demonstrations were more to show just how long it took to lose speed without loosing altitude, the minimum speed in the last one were just for the fun of it.

You feel it is too hard to slow a plane down. What is ferram supposed to do now?

Make it so that it is easier to slow down just because you feel that way?

Do tests to show that you are correct? He has done tests and they led him to the system as it now is. You want him to do even more tests in his own time to counter what he has already seen?

Act on hard data that you provide him? This is what he is asking for. If you can show him that your feeling is correct then he will have no problem fixing things.