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

[gilflo]

HI guys

As user of FAR, I have a question about the setting of flight controls.

What is the purpose of the tabs "AOA%" and "Brake rudder" in the settings of standard control?

Thank you

[taniwha]

57 minutes ago, kcs123 said:

It also helps that you don't do gravity turns until you reach less dense atmosphere (again after 10km).

This is simply untrue: you begin your gravity turn soon after launch (usually between 50-100m/s, depending on your TWR profile). Of course, you turn only a little (about 5°) and then stay prograde (surface velocity) the rest of the way up. I have found that you should be at about 50-60° at around 10-12km: any higher and you'll have a steep ascent and thus have less time to circularize (possibly wasting fuel), much lower will result in nose-diving into the ocean.

[Wanderfound]

3 hours ago, gilflo said:

HI guys

As user of FAR, I have a question about the setting of flight controls.

What is the purpose of the tabs "AOA%" and "Brake rudder" in the settings of standard control?

Thank you

AoA settings cause the control surface to deflect in response to Angle of Attack. The value is a percentage of the AoA.

Why this is useful is because it can greatly boost stability at extreme AoA. To do this, you would use negative AoA on forward control surfaces (e.g. canards) and/or positive AoA on rear surfaces (e.g. elevators). In effect, it gradually reduces the control surface deflection as AoA increases.

Not sure about brake rudder, although at a guess it's for using opposed rudders as airbrakes on twin-tail ships.

[gilflo]

Thank's for answer, that's quite interesting for maneuvrability...

[kcs123]

6 hours ago, taniwha said:

This is simply untrue: you begin your gravity turn soon after launch (usually between 50-100m/s, depending on your TWR profile). Of course, you turn only a little (about 5°) and then stay prograde (surface velocity) the rest of the way up. I have found that you should be at about 50-60° at around 10-12km: any higher and you'll have a steep ascent and thus have less time to circularize (possibly wasting fuel), much lower will result in nose-diving into the ocean.

It is certainly better when you start gravity turn early, almost imediately after takeoff. However, you need to build stable rocket for that and steer very carefuly.
If you have trouble with creating stable rocket and aerodynamic forces gives you too much trouble it might be better to consider taking gravity turns much later when you can accelerate more quickly and easier steer rocket without fear that aerodynamic forces will rip your craft apart.

It is less fuel efficient, without doubt, but when you choose properly engine and fuel tanks for early rocket stages it can be more cost effective than using all kind of expencive parts to make rocket stearable. It all depends how much payload you need to lift in orbit, how much money you can spend on it and what parts/tech level is available in your career mode.

Of course, if you play sandbox game that kind of things does not bother you and you can be very creative with all kind of parts on disposal when you build rocket, but again if you have trouble with such designs it is good to consider other options.

[NathanKell]

Then you are not performing a gravity turn.

And, stable or not, if you actually keep aligned with your velocity vector you'll be fine. If your unstable rocket is making you 'flip out' then you're deviating too much.

[taniwha]

kcs123: a gravity turn, by definition, is you following your velocity as gravity bends it towards horizontal. Indeed, a stable rocket makes it easier (to a point), but I have done it with unstable rockets.

The main problem with a stable rocket is it can become difficult to start your turn, especially if your TWR is too high.

[Wanderfound]

On 27 November 2015 at 6:09:29 PM, SpacedInvader said:

I can give you that FAR is more accurate, as I would expect it to be, and if that's where the CoL is supposed to be, then I can live with that, but I've yet to fly a successful rocket in 1.0.5 where I didn't add fins which moved the CoL below the CoM. Where I keep having the disconnect is that I've never NEEDED fins in the past. Here is an example of a launch vehicle I used to launch around 15 missions last year in RSS on 0.90:



No tail fins, and only small reaction wheels on the payload that wouldn't be able to stabilize a vehicle of this size and mass, yet this rocket was always rock solid stable. I have tried to rebuild something similar, albeit smaller, on my new install and it can't get more than a couple of thousand meters into the air before it tumbles and tears itself apart.

With a bit of gimbal and streamlining, you can launch chunky payloads without fins:

 

Add some fins, and you can launch totally ridiculous things:

 

But it's all about the gimbal. You can only get away with ungimballed thrust if it's countered by fins or gimbal elsewhere.

[SpacedInvader]

On 12/5/2015, 12:14:32, ferram4 said:

That sounds realistic actually; your design is highly flexible and extremely prone to flutter.  I would suggest many more struts as a solution.  Real planes flex a lot unless you take steps to fix it.

 

Alternatively, decide that the stock game's joints are terrible and go for Kerbal Joint Reinforcement.  From the way things have seemed to me, they've backed off the joint stiffness a bit every update or so, so things get a lot more wobbly again.

 

Well, it depends on how much load you're putting on that control surface.  You're doing a real impressive job if you're getting the default wing strength parts to come off at 150 m/s at SL; that implies you're getting a lift coefficient of 2.8... okay either you're reducing the wing strength parameters too much or your install is borked.  By default, each wing should be able to take ~40 kN/m^2 of lift force before it fails.

 

For AoA sweep, you're really only interested in the yellow line (Cm).  As usual, a negative slope means stable, but you're unlikely to get that.  Instead, just make sure that it's not that stupidly large a positive slope.  Remember to check at different Mach numbers, particularly around 1 - 1.6, since that's where Max Q is likely to be for you.  For a Mach sweep, just make sure that the red line (Cd) doesn't spike way too much near Mach 1.  If it does, you might want to smooth out the vehicle a bit.

Remember to do this for all the configurations that will have strong aerodynamic forces on them, so with / without boosters, and possibly the second stage if the first stage drops off very early.

I'll give these a try. As for AoA sweep, shouldn't I really only be worried with at most 5°-10°? The only time I've ever gone much above 5° is at altitudes in the 30+ km range to flatten out my trajectory, and never above about 10° below 50km.

 

On 12/5/2015, 1:22:04, kcs123 said:

For rockets in FAR, another good tip is to reduce engine max. thrust in hangar, so it does not accelerate rocket too quickly.
Try to tweak engines in a way that you breach mach 1 only when you are near 10km of altitude. It also helps that you don't do gravity turns until you reach less dense atmosphere (again after 10km).

Using engines with good gimbals for stages up to 30 km also helps and when you start to steer rocket make sure that AoA is low enough - you need to wait for a while until prograde vector align with direction where you want to go. Otherwise you may turn rocket in unrecoverable spin due to too large AoA.

Like Wanderfound said, for more questions about designs better ask in FAR exchange thread, to help making this thread more "clean" so bugs reports and similar issues does not left unnoticed.

I have started reducing max throttle to reduce the rate of acceleration, though sometimes I find it hard to judge what is enough throttle to give me a reasonable rate of acceleration. 

 

23 hours ago, taniwha said:

This is simply untrue: you begin your gravity turn soon after launch (usually between 50-100m/s, depending on your TWR profile). Of course, you turn only a little (about 5°) and then stay prograde (surface velocity) the rest of the way up. I have found that you should be at about 50-60° at around 10-12km: any higher and you'll have a steep ascent and thus have less time to circularize (possibly wasting fuel), much lower will result in nose-diving into the ocean.

For basically the last 3 years, I've designed my launch vehicles to begin their gravity turn at ~100m/s, which is still what I go for these days, I'm just finding it more involved than it used to be thanks to the new aero system.

 

12 hours ago, NathanKell said:

Then you are not performing a gravity turn.

And, stable or not, if you actually keep aligned with your velocity vector you'll be fine. If your unstable rocket is making you 'flip out' then you're deviating too much.

This, very much... However, the behavior that started this whole discussion was that my smooth-sided rockets weren't able to statically hold themselves on the velocity vector in the way they used to in the old aero system.

 

@Wanderfound: Testing the theory about convincing bricks to fly?

[taniwha]

54 minutes ago, SpacedInvader said:

However, the behavior that started this whole discussion was that my smooth-sided rockets weren't able to statically hold themselves on the velocity vector in the way they used to in the old aero system.

This is because the drag on the nose has increased from previous versions (before, it was unrealistically low (or so I'm told, and I'm willing to believe)).

Also, check for flexing. Just recently I was having a terrible time with one of my rockets. While it was unstable, I could sometimes get it past 15km, other times not, despite flying it as carefully as I could (including pumping fuel forward). It turned out the payload was shifting in the fairing, and that was causing enough torque to push the nose too far and then FAR had its fun with my rocket (the problems occurred whenever I tried even tiny adjustments to my trajectory). A few struts later and it flew well enough. I do not remember what clued me in to the fact it was the payload, though.

[Drew Kerman]

9 hours ago, taniwha said:

This is because the drag on the nose has increased from previous versions (before, it was unrealistically low (or so I'm told, and I'm willing to believe)).

Yea, nose drag has surprised me too. Live and learn...

[Kurtvw]

In this latest version I'm having a problem  where drag doesn't seem to be getting applied in the atmosphere.  I think it is occurring because I have gone to another window (such as browser) while in atmosphere.  I don't recall this being a problem in the past.  I do have KSP set to simulate in the background, so I'm not sure why this would be true.

I've been using FAR for as long as I can remember (10 minutes?   no, seriously, 18months?), I'm not new to this mod, so please, if you're going to assume I'm an idiot in your response, please make sure you phrase it in a way where I'm an idiot who has been running this mod for an awfully long time with this behavior having never manifested in the past :-)

I run a DEEP pile of add-ons, so it could be one of the others causing wonkiness.. But I'm in the early stages of tracking this one down.  Has anyone else been having a similar problem?

[blowfish]

2 minutes ago, Kurtvw said:

In this latest version I'm having a problem  where drag doesn't seem to be getting applied in the atmosphere.  I think it is occurring because I have gone to another window (such as browser) while in atmosphere.  I don't recall this being a problem in the past.  I do have KSP set to simulate in the background, so I'm not sure why this would be true.

I've been using FAR for as long as I can remember (10 minutes?   no, seriously, 18months?), I'm not new to this mod, so please, if you're going to assume I'm an idiot in your response, please make sure you phrase it in a way where I'm an idiot who has been running this mod for an awfully long time with this behavior having never manifested in the past :-)

I run a DEEP pile of add-ons, so it could be one of the others causing wonkiness.. But I'm in the early stages of tracking this one down.  Has anyone else been having a similar problem?

No idea what the problem is, but providing an output log might help (as usual).

[tetryds]

22 minutes ago, Kurtvw said:

Has anyone else been having a similar problem?

Yes, but no one could provide proper reproduction steps.
It's not that people who report issues are called something, it's just that most of the times there is barely enough information to even explain what is going on.
Often things like going back to the KSC, alt+tabbing, going EVA, docking, reverting the launch, etc. are ignored, which makes it impossible to know what causes the issue.
So, we are hoping that you can come up with some good reproduction steps and description of what you did, until then there is nothing that can be done, unfortunately.

Edited December 6, 2015 by tetryds

[Kurtvw]

33 minutes ago, blowfish said:

No idea what the problem is, but providing an output log might help (as usual).

Which log do you need?  Give me the path I am looking for and I'll be happy to send what I have.

 

[Kurtvw]

In the mean time, Here is a picture of my most recent kerbal getting ready to die... Note the drag values, and the altitude and speed.  Its clearly not calculating.

What I just noticed is that V.O.I.D. is calling my biome 'near in space' which is also incorrect.   Now I've got a serious case of WTH? <updated VOID, that issue went away, but FAR still not applying drag>.

<edit> apparently I can't add an image link :-\

Ok, here is the link...

http://imgur.com/AabmfYX

Edited December 7, 2015 by Kurtvw

[Kurtvw]

I believe this is the log you want?

https://drive.google.com/file/d/0BzFXyPyioIwrNTdiM0NkRkdsazQ/view?usp=sharing

[Kurtvw]

Ok, Sorry to spam the forum.

I uninstalled and reinstalled clean, AND I deleted the ModuleManager DB and forced it to recreate.

Everything is now working normally.

[blowfish]

29 minutes ago, Kurtvw said:

I believe this is the log you want?

https://drive.google.com/file/d/0BzFXyPyioIwrNTdiM0NkRkdsazQ/view?usp=sharing

Yes, that's the one.  It looks like you're a few versions behind on FAR.  Try the latest (0.15.5.4)

[The DigitalAlchemist]

Hey, thanks for the responses.

 

I think half the issue is that the CoG in my ship is in front of the CoM. I did this, because the plane has SO MUCH authority over it's control that it doesnt matter. I can carefully go into a turn, or I can just slam it and do a back flip sub 200m/s. It's supposed to be an agility fighter jet (actually looks like the Sukhoy a lot)

 

So, I relented and brought the wings back so the CoL and CoG were the right way around... Same issue however. The plane is made of very few parts for wings, but I think the issue is coming from the immense amount of control authority the plane has. The SAS seems to apply full force to achieve it's goal, over shoots, and has to correct causing it to bob up and down. It's like the gain is too high on it. If I turn off auto pilot, it's 100% fine, CoL wherever it is. But this plane is impossible (or frustrating at the least) to fly long distances. 

 

I've made a few other models as well, same issue. In fact, I've always had this issue with Ferram. I really want to play with realistic lift and physics for flight, but the ability to take my hands away and relax for a long 500+km flight across the ocean to my designated markers is needed. I cant be bothered to manually fly a plane for 2 hours. Not why I like KSP, I like doing things IN it, and making little touchy adjustments every 5 seconds is... boring. 

[Wanderfound]

1 hour ago, The DigitalAlchemist said:

The SAS seems to apply full force to achieve it's goal, over shoots, and has to correct causing it to bob up and down. It's like the gain is too high on it. If I turn off auto pilot, it's 100% fine, CoL wherever it is. But this plane is impossible (or frustrating at the least) to fly long distances.

The stock SAS is oversensitive; it's set up for rockets, not high-authority aircraft. You want Kerbal Pilot Assistant: use the included PID tuner to de-wobble your SAS. http://forum.kerbalspaceprogram.com/threads/100073-0-25-Pilot-Assistant-0-8-Nov-24-Atmospheric-piloting-aids

These settings should see most SAS-related wobble problems go away:

Edited December 7, 2015 by Wanderfound

[The DigitalAlchemist]

2 hours ago, Wanderfound said:

The stock SAS is oversensitive; it's set up for rockets, not high-authority aircraft. You want Kerbal Pilot Assistant: use the included PID tuner to de-wobble your SAS. http://forum.kerbalspaceprogram.com/threads/100073-0-25-Pilot-Assistant-0-8-Nov-24-Atmospheric-piloting-aids

These settings should see most SAS-related wobble problems go away:

Hey thanks for posting this mod! Even if it doesnt fix my issues, it sounds ultra nice. I HAAATE flying across oceans especially on sub sonic flights that take over an hour. +1 to you sir for sharing good content!

 

Edit after testing:

As interesting as this mod is (and I predict useful in the future for other endeavors) it didnt help.

 

What I however found that DID help, was locking the gimbal on my engines as I approached super sonic flight. It turned into a massive wag to a jitter, which I can live with... Theres a lot of forces going on all at once. 

Edited December 7, 2015 by The DigitalAlchemist

[taniwha]

1 hour ago, The DigitalAlchemist said:

What I however found that DID help, was locking the gimbal on my engines as I approached super sonic flight. It turned into a massive wag to a jitter, which I can live with... Theres a lot of forces going on all at once. 

I have found that turning off all non-aerodynamic control sources to be helpful, especially for smaller planes. Sometimes the extra torque can overpower the aerodynamics and get the plane into a situation (usually bad AoA) that the control surfaces alone would not be able to achieve.

[Drew Kerman]

I'm running Hayes on 1.0.4 but a look at the change logs for recent releases did not specifically address this issue - although I did see a lot of voxel improvements that could perhaps have also inadvertently solved this issue I'm seeing. I've noticed that going into the tracking station and returning directly to the craft causes the reference area to change. It doesn't vary extremely wildly, but it does differ from load to load for some reason:

 

I've also got recorded instances of 5.262 and 5.295

Edited December 8, 2015 by Gaiiden

[capi3101]

Alright - I think I need to attempt to make a bug report. Makes me nervous - because I sure as hell don't want to waste anybody's time here, and I don't want anybody to rip into me, either...

I had a problem with one of my craft, the Lawsuit 7, flipping out and disintegrating upon re-entry. Just for the sake of trying to eliminate it as a possibility, I decided to take a look at FAR's debug voxels to see if anything weird was going on. This was what I saw when I did that:

And when I opened the doors, this happened:

So, I tried re-entry with the doors open, and the craft survived re-entry. In later permutations of the craft, I removed the Service Bay entirely.

Later, after I had problems with a second craft (the Baywatch 7) exploding due to excessive dynamic pressures with each re-entry attempt (despite being almost identical to the revised Lawsuit 7 design), I decided I should try to see how things looked in a vanilla install of KSP with FAR alone installed: 

I'm attaching links to the relevant craft files and output logs for the two saves - 

Lawsuit 7 Craft File

Baywatch 7 Craft File (Full Craft)

Baywatch 7 Craft File (Capsule Only)

Output Log (Normal Save)

Output Log (Vanilla w/ FAR Only Save)

I'm hoping I haven't missed any possible diagnostic steps.

 

TL, DR: I think that an old voxelization bug with the Mk1 Service Bay has come back. I'm not sure what's going on with the Baywatch craft. Hopefully I'm making sense - I'm more than a little sleep-deprived at the moment..