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

[jcd]

I tried it with one pair of wings and no control surfaces and it looked the same, but I think it may just be an issue with the indicator because it seems to fly properly.

BTW the stall behavior seems to have improved a lot since previous versions for me. Now I can stall and recover a plane with only control surfaces and in general things seem to behave more like flight simulators.

[Andon]

So, I have a minor gripe with the latest FAR build. A number of rockets that worked previously no longer do. They get to about 5km up before keeling over and flopping around like a fish. At first I thought it was just the new rocket that I was attempting to build, with no success, but after loading a few of my .22 rockets, they do the same thing. Any ideas on what's changed to cause this, and how I should build around it?

[ferram4]

@Andon: Your designs probably weren't supposed to be stable to begin with. Odds are they took advantage of a bug in the standard drag model code that produced a lot of lift in situations when it shouldn't have, which I can see making rockets stable in situations that they shouldn't have been. The best way to fix it is to look into adding flared-out bases to the bottom of your rocket or fins at the bottom of it. Look at the included FAR Artemis Transfer as inspiration, since that is amazingly stable and its characteristics haven't changed with the updates.

And version 0.12.3 is out, fixing a payload fairing bug in the editor, some conversion errors in the Flight Data GUI, a scaling error in the flap code, and (what I think) was the source of the negative drag bug.

[BelgarionNL]

when can we expect mechjeb integration? Not that I like mechjeb so much but I prefer to use mechjeb on re-entry without burning up!/ or landing of course

[ferram4]

Everything is set up for MJ integration on my side. You're waiting on sarbian, r4mon and whoever else is updating MJ.

[DaMichel]

And version 0.12.3 is out, fixing a payload fairing bug in the editor, some conversion errors in the Flight Data GUI, a scaling error in the flap code, and (what I think) was the source of the negative drag bug.

Nice, that was quick. Thanks again for all the effort.

The CoL in Donziboys pics shifts a big step forward upon adding the delta wing to the front. Is there some strange aerodynamic effect going on or is it simply due to the shift of the wing area?

[not-a-cylon]

Hey Ferram! Thanks for your work in getting this playable ASAP for .23. Anyways, I noticed that there isn't a way to tell what the maximum deflection for a flap is before it stalls like in previous versions. Have I missed something?

[Camacha]

Hey Ferram! Thanks for your work in getting this playable ASAP for .23. Anyways, I noticed that there isn't a way to tell what the maximum deflection for a flap is before it stalls like in previous versions. Have I missed something?

Isn't that right beneath where you set the flap deflection? Or is my version already outdated?

[taniwha]

Ferram: please bring back the control surface panel. It is not entirely redundant with tweakables (though making the graphs the default display might be reasonable).

Also, do you have a bug tracker somewhere?

[BelgarionNL]

then I will go bother sarbian and his gang

[ferram4]

@DaMichel: That's mostly the effect of adding more wing area that far forward.

@not-a-cylon: Removed it, since it wasn't always accurate anyway.

@Camacha: You're trying to run v0.11 in 0.23, aren't you? The control surface GUI with all of that stuff has been stripped out, in favor of a tweakables implementation.

@taniwha: The tweakables handles setting up a control surface as to act in pitch, yaw or roll, as well as acting as a flap or spoiler, as well as setting the max deflections for each of those separately. What's missing then?

Also, no I don't have a bug tracker, besides a (currently empty) text file on my computer.

[Amazingteknique]

Yo, any chance that the toolbar plugin could possibly be made optional. Call me wierd, but I actually liked the old FAR Flight SYS button beneath my clock >.>

[DaMichel]

Alright, think i need some help from the pros here. I made this little aircraft which becomes very hard to control in the transsonic regime. The image should be self explanatory

[ferram4]

@Amazingteknique: Nope, not gonna happen. That would make the toolbar more expensive, computationally, and would be more work on my end. Besides, with the new toolbar I can sneak slight changes into the button image every update, allowing me to identify what version of FAR someone is using so that I can determine whether their problem is due to an already-fixed bug or a new issue.

@DaMichel: Okay, first, the Stability Derivatives are only truly valid around a specific velocity + Mach number + AoA condition, which means that the data isn't valid for the condition you're looking at. Besides that, the assumptions used in that analysis are violated by stalling anyway; they're intended to prevent stall. It looks like the main cause of Xw being wrong is that you have so many intakes; basically it indicates that it makes less drag at a slightly higher angle of attack than at the angle of attack it's currently at. That's the one deriv that does have a "correct" sign, but it's okay if it's wrong. Temperature is best found by flying a sounding rocket with a thermometer attached; take a look at the display, and that will tell you the temp at that altitude.

As for the static analysis, it's not Cm that you're really concerned about, it's the slope. And the sudden positive Cm slope when it stalls makes it stall more as it begins stalling; you want to have lower aspect ratio wings at the back of the plane, higher aspect ratio wings at the front to make it more stable during stalling.

[Cinocal]

Best mod as usual. Thanks for keeping it up to date!

[SFJackBauer]

Ferram, why in the transonic/subsonic region the graph displays double lines for everything (Cl, Cd and Cm and L/D)?

@DaMichel, just so I can complete the picture in my head with the explanation ferram gave (and so learn something in the process), does the craft flip at mach 0.9 without touching the controls, while flying level and straight? If you did a pull-up before the stall, then would be useful to analyze the graph with the "Pitch setting" to 1?

[Hyomoto]

Having what I hope is a bug? There always seems to be something and this time it's my plane's desire to freak the hell out when SAS is turned on. The plane will fly using your assists, trim use, or with just plain manual control, and it will sometimes fly with SAS on, however the smallest bit of turbulence and suddenly it starts convulsing all my flight surfaces and threatens to tear the craft apart. It also doesn't seem to want to hold a heading. I saw something about this in your patch notes, but I have no idea how tweaking it will affect anything. Definitely had zero issues with this design on 0.22 so I'm wondering if SAS can't handle the mechanical lag. Is that what your patch notes are talking about? Any ideas?

By the way, thanks for supporting the toolbar. It's nice to have what you want, where you want, when you want, and not a screen cluttered with windows and buttons

Edited December 20, 2013 by Hyomoto

[taniwha]

Ferram: The stall angle indicator is missing. Yes, the rest of the controls are redundant, but having them doesn't hurt and better yet, allows for more precise tuning than do sliders.

[longhornchris]

Having what I hope is a bug? There always seems to be something and this time it's my plane's desire to freak the hell out when SAS is turned on. The plane will fly using your assists, trim use, or with just plain manual control, and it will sometimes fly with SAS on, however the smallest bit of turbulence and suddenly it starts convulsing all my flight surfaces and threatens to tear the craft apart. It also doesn't seem to want to hold a heading. I saw something about this in your patch notes, but I have no idea how tweaking it will affect anything. Definitely had zero issues with this design on 0.22 so I'm wondering if SAS can't handle the mechanical lag. Is that what your patch notes are talking about? Any ideas?

By the way, thanks for supporting the toolbar. It's nice to have what you want, where you want, when you want, and not a screen cluttered with windows and buttons

There are 2 big issues that mess up the SAS with FAR:

1: Control lag - SAS is assuming a near-instantaneous response from the control surfaces (stock behavior & how the system reaction wheels & engine gimbals behave) and in FAR both the deflection and its impact take some time (like in real life). Control lag is a classic instability in control theory.

2: Variable control effectiveness - the impact of control surfaces (and the outside forces being corrected for) varies over the flight envelope based on speed, altitude, AOA, etc. The SAS algorithm scales based on a few items (based on how it behaves on rockets) but can't account for the dynamics and isn't robust against having a bad (i.e. poorly understood) plant model.

3: SAS responds poorly to cross-coupling, which all aircraft suffer from to some extent. The most basic example is roll-yaw coupling, where a rolling causes a yaw, or yawing causes a roll. SAS detects and reacts to deviations from the desired attitude and tries to correct all of them and exacerbates the problem. FAR's controls operates on a per-axis basis with tuning for each which helps to suppress coupling. Additionally tools like the pitch and yaw damper don't try to return to a set pitch, instead they try to zero their respective rates.

In short, SAS isn't tuned for aircraft unless you are careful in your design (i.e. its fairly stable to begin with) or you get very lucky.

[spudcosmic]

Is the Control Axis Choice feature now mostly redundant now with .23, or does it still serve some purpose/is better than the stock one?

[SFJackBauer]

Bug report - Control surface when assigned also as a speedbrake, the deflection taken into consideration when the brake is applied is the control surface deflection, not the flap/brake deflection.

Also, when trying to configure a split-rudder brake, attaching a control surface with symmetry makes it behaves weirdly when the brake is applied - either the deflection is inverted, or both surfaces deflect to the same side.

[ferram4]

@SFJackBauer: That happens in all regimes; one line is increasing AoA, the other is decreasing. Usually the lower Cl line is decreasing AoA, since you need to drop the nose quite a bit to get out of a stall.

Also, confirmed and fixed the deflection limit issue; should be in the next release.

@Hyomoto: SAS has been causing that since 0.22, when all of the complaints people made about it not being as aggressive as they would like in 0.21 were addressed. The problem is that without a setting that we can use to control how aggressive SAS should be there's no way to make it work for everything; it'll just have to settle for being okay at controlling most not-aircraft things and terrible at controlling anything with wings. In 0.21, it was perfect for aircraft, but I guess it wasn't acceptable for rockets? I dunno, I never understood the complaints there.

@taniwha: But the stall indicator was wrong half the time. And as far as precision goes, I can tweak the settings until you can get great precision without me having to deal with the hassle of maintaining an extra GUI that will probably never be used.

@spudcosmic: That's true; I'll get rid of it.

[lammatt]

i encountered a problem which i havent before the 0.23 release

- when re-entering, the speed doesnt slowdown any bit without entering a stall

- so i purposedly enter a stall to try slowing down in another trial. upon regaining of control at manageable speed and altitude, (~400m/s @ ~6000m), the plane gains speed at an unreasonably high rate when i tried to descend... it is to a point that the plane gains up to a relative surface speed of ~2000m/s at 1000m altitude and it explodes due to structural failure.

- then i tried to make a turn to bleed the speed off without engine, but the funny thing is, the speed keeps increasing regardless.

why does this happen?

(it doesnt happen pre 0.23)

Edited December 20, 2013 by lammatt

[ferram4]

What version of FAR are you using? I believe I fixed that issue in FAR 0.12.3, since I removed the only bit of code that could possibly add negative drag.

[lammatt]

What version of FAR are you using? I believe I fixed that issue in FAR 0.12.3, since I removed the only bit of code that could possibly add negative drag.

O...i was using v0.12.2

let me try the new one and see if it works

-----

downloaded the 0.12.3 file, and extracted.

but the in game tooltip is still showing 0.12.2

is it normal?

Edited December 20, 2013 by lammatt