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

[blowfish]

7 hours ago, raxo2222 said:

Weird then my AJE didn't install properly, because some of jet engines have constant ISP.

Indeed.  Try reinstalling SolverEngines and AJE

[Van Disaster]

On 9/14/2016 at 1:56 AM, raxo2222 said:

I wonder if there could be some sort of calculator, that could pick best pith setting, altitude and speed for our aircraft, so we can know how high, how far and how long it could possibly fly.

 

You can see where the best L/D is from the sweep AoA graph & get cD from the second tab (  although that tab is being a bit odd, maybe it's just B9pw, but my predicted & actual AoA at height/speed are way off reality ), but there's a lot of engine in there also so any calc is going to involve a bit more than just aero.

--

Edited September 16, 2016 by Vanamonde
Reference to removed posts.

[Vanamonde]

Some posts have been edited or removed from this thread. On the one hand, modmakers update when and if they feel like it. Bugging them to do it only tends to irritate them, so please allow them to update at their own pace. On the other hand, if you see a post bugging a modmaker for an update, please do not get into an argument with that person, because that just makes things unpleasant for everyone. Instead, just hit the report button on the post and let us moderators deal with it. 

[Apurva Kawthalkar]

Hi 

Listen the mod is great , it is awesome.

Can you create a mod for just the graph tool ?

The one in which we can run the simulations and analyse the data from graph in VAB itself 

[softweir]

4 hours ago, Apurva Kawthalkar said:

Hi 

Listen the mod is great , it is awesome.

Can you create a mod for just the graph tool ?

The one in which we can run the simulations and analyse the data from graph in VAB itself 

That sounds like an interesting mod for stock aerodynamics! However, it would probably be very non-trivial converting Ferram's code to operate with stock: every line of the graphing code will be written with the assumption that it is referencing FAR aerodynamic behaviour. It would probably be easier for somebody to create new code from scratch - and i doubt Ferram has the time or inclination to do that!

[cantab]

Agreed to thinking that would be really good. The analysis tools are my main reason for using FAR, I consider them even more important to aircraft design than KER is to rocket design, and the actual better aerodynamics is secondary to me.

That said, it may be a niche viewpoint, and I don't know how much work FARTS (FAR Tools for Stock aero ) would involve.

[Rodhern]

55 minutes ago, cantab said:

... The analysis tools are my main reason for using FAR, ... That said, it may be a niche viewpoint, ...

I will agree to that. The most fun part of FAR to me too is the graphs, the analysis, the in-flight data readouts and the 'tweaking' that goes along with it.

Like most other players in this thread, I too do not believe that FAR is the most obvious project to introduce those wind tunnel features to the stock game. FAR is one of the (several) fine showcases for the modding possibilities in KSP though.

[steve_v]

6 hours ago, cantab said:

The analysis tools are my main reason for using FAR

Likewise, that and realism.

10 hours ago, softweir said:

That sounds like an interesting mod for stock aerodynamics!

Huh, I thought that too... Then I played with stock aero in 1.2-pre.

Holy-moly, this stock aerodynamics thing is ludicrously forgiving. I'm now thinking stock really doesn't need any analysis tools, as anything that looks even vaguely aircraft-ish will fly fine.

Edited September 17, 2016 by steve_v

[UltraJohn]

Is there any way to reduce the wobbling with SAS turned on?

[Apurva Kawthalkar]

18 hours ago, softweir said:

That sounds like an interesting mod for stock aerodynamics! However, it would probably be very non-trivial converting Ferram's code to operate with stock: every line of the graphing code will be written with the assumption that it is referencing FAR aerodynamic behaviour. It would probably be easier for somebody to create new code from scratch - and i doubt Ferram has the time or inclination to do that!

 

ok fine just let me know if you are thinking on that way

[Nansuchao]

4 hours ago, John007qwe said:

Is there any way to reduce the wobbling with SAS turned on?

It's a stock issue. However, if this happens in high speed flight, tweaking your elevons will help a lot. Yaw only for tail fin etc. 

Also, higher the speed, less authority is needed. Less authority, less wobble.

[UltraJohn]

5 minutes ago, Nansuchao said:

It's a stock issue. However, if this happens in high speed flight, tweaking your elevons will help a lot. Yaw only for tail fin etc. 

Also, higher the speed, less authority is needed. Less authority, less wobble.

Yes that's true, but there is no fast way to change authorities midflight. I usually just leave it on the default value, but I guess I don't really need that much anyway.

[Nansuchao]

4 minutes ago, John007qwe said:

Yes that's true, but there is no fast way to change authorities midflight. I usually just leave it on the default value, but I guess I don't really need that much anyway.

A solution can be Dynamic Deflection, a little mod that automatically tweaks the wings authority depending on the speed.

[UltraJohn]

2 minutes ago, Nansuchao said:

A solution can be Dynamic Deflection, a little mod that automatically tweaks the wings authority depending on the speed.

That would be quite nice actually.

[Nansuchao]

2 hours ago, John007qwe said:

That would be quite nice actually.

Here you have:

 

[Van Disaster]

14 hours ago, steve_v said:

Holy-moly, this stock aerodynamics thing is ludicrously forgiving. I'm now thinking stock really doesn't need any analysis tools, as anything that looks even vaguely aircraft-ish will fly fine.

To be fair anything vaguely aircraft-ish will fly under FAR too Tetryds ran a contest a while back seeing if someone could build a stock craft which didn't ( this was in mad old stock aero too ) and I don't think there was anything, although I sent a craft file in which relied on the orientation of wing panels ( remember when that mattered? ) which never got tested...

1.2 SAS is also a lot more forgiving, although as always I will suggest Pilot Assistant for anyone with more than a passing interest in KSP aviation. You'll find it at the same place as Dynamic Deflection, too.

[flx]

How much KSP have changed between 1.1.3 and 1.2 in terms of FAR work? It's so painful to have fixed (it was fixed, right?) landing gear physics an not being able to actually fly planes.

Edited September 18, 2016 by flx

[FunnelVortex]

On 9/17/2016 at 3:55 PM, Van Disaster said:

1.2 SAS is also a lot more forgiving, although as always I will suggest Pilot Assistant for anyone with more than a passing interest in KSP aviation. You'll find it at the same place as Dynamic Deflection, too.

I find Atmospheric Autopilot to be much more forgiving and smoother than stock SAS. Atmospheric Autopilot works with FAR and has it's own fly-by-wire system that makes anything with even just a remotely good design fly like a dream.

 

On 9/18/2016 at 0:45 PM, flx said:

How much KSP have changed between 1.1.3 and 1.2 in terms of FAR work? It's so painful to have fixed (it was fixed, right?) landing gear physics an not being able to actually fly planes.

FAR doesn't work in 1.2, so I guess a bit changed. Cant wait for it to update because even though stock aero is better than it was pre-1.0.5, it still is really unrealistic and it doesn't feel like I am actually handling a plane.

[Deizelpunk]

Would it be possible to set it so that stock turbo props still work when you update to 1.2? Im really sad that i cant use my propeller planes with FAR on. 

Edited September 23, 2016 by Deizelpunk

[Azimech]

1 hour ago, Deizelpunk said:

Would it be possible to set it so that stock turbo props still work when you update to 1.2? Im really sad that i cant use my propeller planes with FAR on. 

I don't think it will work with the current angular speed limit. The engines don't make enough RPM. I've asked NathanKell if the team can find what's making the joints go gaga above 51 rad/s but ... even if they like these engines (and I've got the impression they do) I imagine it's pretty far down on the list.

Turboshaft helikopters do work with FAR btw.

Rewriting FAR so my invention works while liquiding off other people? Even I wouldn't do that ;-)

Send me a PM and explain the problem ... maybe ... just maybe I can find a workaround.

[Van Disaster]

On 20/09/2016 at 4:00 AM, FunnelVortex said:

I find Atmospheric Autopilot to be much more forgiving and smoother than stock SAS. Atmospheric Autopilot works with FAR and has it's own fly-by-wire system that makes anything with even just a remotely good design fly like a dream.

I like PA because it'll hold an actual heading if I want it to - and it's a little easier resource-wise: AA is quite an achievement but at a bit of a cost on my box at least. I can't keep fiddling with the same keys all the time or I lose the use of my fingers for a while, and likewise can't hold a stick.

Building rotors out of wing pieces should work better once we can change the wing profile, I'd imagine.

[Boris-Barboris]

1 hour ago, Van Disaster said:

but at a bit of a cost on my box at leas

You mean game performace? Could you give an estimate?

[KSPNerd]

I've been told to ask about if FAR will ever be able to calculate the aerodynamics of a single part, such as the spaceplanes in Contares. So will FAR ever be able to do that? It would be really useful to modders to allow them to make single part air/space-planes and have them FAR compatible.

[Van Disaster]

On 24/09/2016 at 3:55 PM, Boris-Barboris said:

You mean game performace? Could you give an estimate?

I'll try and profile it a bit at some point ( well, "profile" - I don't have an actual profiling install right now ).

[Rodhern]

Hi

I mentioned that I find the sign of Zq (and Xq) unintuitive, and downloaded the source code to investigate. Now I have the downloaded source code, and I have suggestions for more changes to the derivatives page.
I don't quite know if it is best to post in this thread or in the FAR craft thread. I don't know if I should post craft pictures first and follow up with code or do it the other way around either.

The issue I want to mention is the yaw, pitch and bank angle conventions used in this bit of code.

Vector3d velocity = forward * cosAlpha * cosBeta;
velocity += right * (sinPhi * cosAlpha * cosBeta + cosPhi * sinBeta);
velocity += -up * cosPhi * (sinAlpha * cosBeta + sinBeta);

velocity.Normalize();

//this is negative wrt the ground
Vector3d liftVector = -forward * sinAlpha + right * sinPhi * cosAlpha - up * cosPhi * cosAlpha;

Let me do a few simplifications to get to one of the most important issues. In general it matters to some extent which sequence the rotations w.r.t. yaw, pitch and roll are done. It also matters when rotation composites are formed if later rotations are relative to earlier rotations or in 'world' coordinates. Obviously the sign of rotations (e.g. bank angle) matters. In this post, however, let us assume that bank angle is zero, and assume that the yaw (and possibly pitch) angle is not too large. In this case the Phi-stuff is unimportant and consistency in the yaw, pitch and roll angle conventions become less important too. With these simplifications in mind the third code line becomes:

velocity += -up * (sinAlpha * cosBeta + sinBeta);

Writing the formula in this way it is clear that a (positive) sideslip angle disturbance implicitly factors in an increase in AoA.

This effect can be observed in the SPH as well.

Notice how the naive interpretation of the Lbeta suggests that just a small yaw angle will induce a tremendous roll rate (beyond the roll rate tendency present at level flight).

I suggest that yaw, pitch and roll angle conventions are changed to make them more easily intuitively understandable.

 - Rodhern

 

Edit: Trying to read between the lines, I have come up with a guess, that the velocity direction vector for the intended orthonormal vector set should be something like this (change in line 2 and line 3)

Vector3d velocity = forward * cosAlpha * cosBeta;
velocity += right * (sinPhi * sinAlpha * cosBeta + cosPhi * sinBeta);
velocity += -up * (cosPhi * sinAlpha * cosBeta - sinPhi * sinBeta);

thus making "velocity.Normalize();" redundant.

Edited October 1, 2016 by Rodhern
wild guess, (and one "yaw" replaced with "sideslip")