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

[localSol]

I didn't know about that maneuver, that's good. But I wonder about some kind of helper mod, that could boost engine efficiency only during atmospheric landings until the landing is over. Maybe Kerbal ISP Difficulty Scaler could do this if it changes engines that are already in-flight? If not I guess it would be possible though a plugin otherwise.

Edit : DaMichel : I like to see stuff made for FAR! I used interstellar's nuclear thermal turbojets too, they work fine with FAR as far as I can tell.

Edited December 11, 2013 by localSol

[Starwaster]

Request that 'aeroshell' be added to list of fairing-type names to look for, the next time the plugin is updated.

[DaMichel]

localSol: Yeah. There seem to be some glitches with the atmospheric intakes, but the engines definitely work. I should read up on super sonic aircraft design though, since most of my planes become terribly unstable at high speeds and altitudes whereas they fly just fine in the lower atmosphere

[azza276]

Hi Ferram, I've only been playing KSP since soon after .22 was released and so far love it. I also love the FAR mod. I love the more realistic aerodynamics and the challenge of building a plane that flies realistically. Although I have had my frustrations, pitching too high and flipping etc, etc.

But anyway, that's not why I'm here. I'm sure you may of heard of and seen the TiberDyne Shuttle craft/parts (TiberDyne Shuttle). I don't know if you are aware that they are unflyable with FAR, essentially, they fly backwards! I had a search through this thread and the forum and could not see any relationship between the two other than a few other complaining about it in the Tiberdyne Thread.

So now to the guts of it. Can you help?

I took it upon my self to look into the part config files that make up the shuttles last night. I used the B9 Aerospace and Squad parts as a reference and tried to match things like drag and lift for similar sized equivalent parts, it is a little more stable but still in the end they just fly backwards. One thing I did add to the wings was angular drag.

I tried a crazy thing and built one of the shuttles myself keeping an eye on CoM, CoL, etc and slotting in parts from B9 etc to try to see if it was one particular part that was causing the issue. From what I could see was that most of the parts are good until... the cargo fuselage... When the cargo fuselage is mounted onto the back of the cockpit (no wings), the CoL is not vertical, but points forward at a roughly 45 degree angle centered over where Tiberion has the docking port node. Once you add the wings and engine, the CoL comes drastically rearward and rear of the CoM, but still has a slight lean forward.

I then flipped the Cargo fuselage back to front, whacked the wings on it etc (all tiberdyne parts) and IT FLEW Straight forward! It was controllable, got into orbit and returned (although with the SAS on after reentry it shuddered the control surfaces and the tail plane ripped off... but I still able to land it).

Back in the SPH, I looked at the CoL with the reversed cargo and no wings and the CoL was now at the rear but pointing down. Weird I thought, so played around with the CoM offset and a few things, but was never able to adjust that. I also noted that the Part was an RCS tank module "welded" to it at the normally rear position of the cargo.

So my Questions;

1. How much does FAR use the Models to calculate things. I'm not a 3d modeller so unable to see that actual models except in KSP.

2. What does FAR/KSP use to calculate lift of a non-lifting surface (no lift defined in the part cfg)

3. What aspects of the part.cfg does FAR use. Which values should I look at changing?

The Parts are all in the Tiberdyne Shuttle Mod in the Link at the beginning, as well as some crafts. I will put a post in the Tiberdyne thread as well so that he is aware of this.

I would really like to get the Tiberdyne Shuttle Mod working with FAR, as I love FAR and the Tiberdyne shuttles are just really good looking just not flyable with FAR. I'd love to keep both.

Cheers

Azza

p.s. I actually joined the forum to write this... Cheers for your help.

[toadicus]

@ferram4

I'm working on a plane, and am having some weird asymmetric control issues. I am adding some standard control surfaces as spoilers, using surface attachment to stick them on the top of of some wings. When I add pair 1, which attach to some wing connectors, everything is fine.

One pair of spoilers, works just fine.

But, when I add the second pair, out a bit farther and attached to some delta wings, I get very significant asymmetric control. Pitching induces some roll, and braking induces very significant roll.

Two pairs of spoilers, rolls like a crazy rolling thing. For example:

.

Removing all of the non-airbrake control surfaces from the brakes action group lessens the effect slightly, but it doesn't go away.

Any ideas?

Edited December 12, 2013 by toadicus

[camlost]

So my Questions;

1. How much does FAR use the Models to calculate things. I'm not a 3d modeller so unable to see that actual models except in KSP.

2. What does FAR/KSP use to calculate lift of a non-lifting surface (no lift defined in the part cfg)

3. What aspects of the part.cfg does FAR use. Which values should I look at changing?

The Parts are all in the Tiberdyne Shuttle Mod in the Link at the beginning, as well as some crafts. I will put a post in the Tiberdyne thread as well so that he is aware of this.

I would really like to get the Tiberdyne Shuttle Mod working with FAR, as I love FAR and the Tiberdyne shuttles are just really good looking just not flyable with FAR. I'd love to keep both.

Cheers

Azza

p.s. I actually joined the forum to write this... Cheers for your help.

1.FAR assumes all fuselage are cylindrical and calculate its drag and lift. Any part from any mod can be recognized and nothing needs to be specified.

2. All wing parts need their span/taper ratio/swept etc. specified in the cfg. B9 and a few other mods have these parameters, apparently tiberdyne does not. If you really want you can try to write it

3. Seems to me the best way to build a space shuttle with FAR is to use B9 wings/fuselage. Then you need some kind of large-gimble-range engine like "space shuttle engine pack" and find some proper mod for the SRB and external tank. Shuttle wings have complex geometries that are hard to configure with a single part.

[Goozeman]

@ferram4

I'm working on a plane, and am having some weird asymmetric control issues. I am adding some standard control surfaces as spoilers, using surface attachment to stick them on the top of of some wings. When I add pair 1, which attach to some wing connectors, everything is fine.

One pair of spoilers, works just fine.

But, when I add the second pair, out a bit farther and attached to some delta wings, I get very significant asymmetric control. Pitching induces some roll, and braking induces very significant roll.

Two pairs of spoilers, rolls like a crazy rolling thing. For example:

.

Removing all of the non-airbrake control surfaces from the brakes action group lessens the effect slightly, but it doesn't go away.

Any ideas?

Depending on how accurate FAR is, it looks like you're getting a "tip stall" condition. If you're going to use spoilers/speed brakes, you want them inboard. If you stall the tip of the wing first, usually one tip will stall first, causing the condition you see. Notice the "minor stalling detected" indicator.

It could be an issue with FAR, but spoilers near the tip is bad aircraft design.

[ferram4]

@azza276: Camlost got a lot of the basics down, but the main problem is that the Tiberdyne Shuttles aren't set up to work with FAR. Depending on where the part origin for the wings is placed it may not be possible to make them work. FAR's wing code is designed to function well with wings designed like the stock wing parts; reversible, surface attached, symmetric. Anything outside of those parameters may not be capable of being set up to work.

@toadicus: I'll check out the craft in my dev build; I've changed how some of the wing code works, so I may have already fixed the issue. I think removing the non-airbrakes from the action group is just a result of the placebo effect.

[toadicus]

Depending on how accurate FAR is, it looks like you're getting a "tip stall" condition. If you're going to use spoilers/speed brakes, you want them inboard. If you stall the tip of the wing first, usually one tip will stall first, causing the condition you see. Notice the "minor stalling detected" indicator.

It could be an issue with FAR, but spoilers near the tip is bad aircraft design.

Thanks! I didn't know that, and will revise, whether FAR models that or not.

@azza276: Camlost got a lot of the basics down, but the main problem is that the Tiberdyne Shuttles aren't set up to work with FAR. Depending on where the part origin for the wings is placed it may not be possible to make them work. FAR's wing code is designed to function well with wings designed like the stock wing parts; reversible, surface attached, symmetric. Anything outside of those parameters may not be capable of being set up to work.

@toadicus: I'll check out the craft in my dev build; I've changed how some of the wing code works, so I may have already fixed the issue. I think removing the non-airbrakes from the action group is just a result of the placebo effect.

If it helps any, this seems to happen to previously-placed airbrakes (or something) after placing any additional parts in the editor. As I continued to revise the design, I wound up needing to re-place the first two air brakes as the last two parts on the plane after I added any other parts. As long as the only two airbrake parts are the very last parts on the plane, it works. If they're not, it doesn't seem to.

[azza276]

@azza276: Camlost got a lot of the basics down, but the main problem is that the Tiberdyne Shuttles aren't set up to work with FAR. Depending on where the part origin for the wings is placed it may not be possible to make them work. FAR's wing code is designed to function well with wings designed like the stock wing parts; reversible, surface attached, symmetric. Anything outside of those parameters may not be capable of being set up to work.

Thanks Ferram,

Yeah, that could be it, Tiberion's wings attach to the cargo bay with nodes (stacked) and are not able to be symmetried (obviously not a word but you know what I mean). The Left and right wings are separate parts, although I did try deleting the nodes and allowing surf attachment and was able to build it, but still unflyable.

Tiberion thought that nodes and their sizes also had an affect and from some testing I did, it does have and affect on the CoL, for example he has a robotic arm attachment point on the front right corner of the cargo bay which seems to pull the CoL to the right, also it was suggested to change the node size from small at the front to large at the rear.

I also tried Bobcats Buran last night and it seemed to have large nodes all over (including the left and right wings) but still flew straight (until I botched the reentry and just flat spun). I did note that he had 2 arm nodes, one on each side (balanced).

I will have a look at the cfg for the wing "attributes" mentioned in camlost's second point (I did note it before but I thought I read somewhere that FAR would use default values if none are specified), as well as the nodes again (I stopped last night as it was starting to bug out my save file and I wanted to try bobcats buran.) I'll also see if I can determine the origin. What specifically about the origin is important. Does it need to be central to the part (x0,y0,z0 physically)? Or does it need to be at a wing root, theoretical wing CoM, etc? I'm assuming the origin is defined in the model.

Cheers

Azza

[ferram4]

The offset robotic arm attach node probably causes some issues for the cargo bay; attach something to it and that should clean things up.

The nodes on the wings wouldn't matter if the wings were set up to use the FAR wing code, but since they aren't the standard FARBasicDragModel module would be applied to them instead, which would cause the nodes to be used in calculations and the wing to be treated like a fuel tank or engine or something like that. It's okay if the regular attach nodes stay there, so long as the FARWingAerodynamicModel is applied in the config.

The wing's part origin needs to be at the midchord point on the wing root for the CoL to be placed properly. Further, the wing needs to have some type of surface attach node specified so that it can be surface attached correctly; this is how FAR figures out which direction to offset the CoL in so that it is halfway down the wing span. Take a look at the differences between the stock tailfin and deltaWing parts and you will see how they are actually flipped, but with flipped surface attach data as well to counteract that.

The part origin can be offset by using a MODEL{} block. I can't think of any examples offhand, but if you toy with PartWelder the resulting models are offset using the same type of logic.

[azza276]

Thanks Ferram,

That it gold. I'm not 100% on what you are talking about with the tail fin nodes (don't worry not asking for more explanation), but I will have a look at a few examples and figure it out.

So what you are saying about the nodes is if one if left "unattached" it can affect the dynamics, but if it is used/attached, it is no longer taken into account for calcs? Also does it matter if they are stack or attach nodes? I can't really find any definition on the nodes except ones for vertical (stack) and ones for Horizontal (attach) but again that was old data, 0.15 to 0.20. Are attach nodes for defining the pivot point when surface attaching?

Sorry for all the questions, but as I get my head around one aspect, more questions become apparent.

Cheers

Azza

[SnappingTurtle]

Anyone got tips on how to place landing flaps for best drag and lift? Should I put them on my main wings aligned with the center of mass? What angle should I deflect them to?

[ferram4]

@azza276: In the configs you'll see each stack attach node specified, as well as a surface attach node (node_attach). That's what I meant about the tail fin and delta wing nodes.

Unconnected stack attach nodes are used by FAR to detect large, relatively flat surfaces in the airflow; this is how it handles a fuel tank without a nosecone, for example, or the drag of a relatively flat command pod bottom. The "new" attach node system hasn't been added yet, and currently they still use the "old" data that you found.

Don't worry about questions. No worries.

@SnappingTurtle: They'll make more lift if they're placed on larger wings, but ideally you want them near the plane's center of mass for pitch-control purposes. Deflect them as much as you want, so long as they don't stall; you can probably get away with ~20 degrees and you'll be fine.

[SnappingTurtle]

Deflect them as much as you want, so long as they don't stall; you can probably get away with ~20 degrees and you'll be fine.

In the control surface assignment FAR tells me that my flaps have a stall angle of over 800 degrees. Is this because they're so close to the center of mass?

[ferram4]

No, that would be because you don't have the CoL on. Without having the game run aerodynamic calculations it can't estimate the stall angle.

[azza276]

@azza276: In the configs you'll see each stack attach node specified, as well as a surface attach node (node_attach). That's what I meant about the tail fin and delta wing nodes.

Unconnected stack attach nodes are used by FAR to detect large, relatively flat surfaces in the airflow; this is how it handles a fuel tank without a nosecone, for example, or the drag of a relatively flat command pod bottom. The "new" attach node system hasn't been added yet, and currently they still use the "old" data that you found.

Don't worry about questions. No worries.

Well Bugger me that is brilliant, and makes so much sense now... So that tails, node and stack nodes are in the same position, just one is oriented 180 (so one node is say angy+1 and the other angy-1).

So would this also apply to the top and bottom stacks? I note in the Wiki for the cfg that it says

Generally, most parts will have angx, angy, and angz values of either (0.0, -1.0, 0.0) for a node_stack_bottom and (0.0, 1.0, 0.0) for a node_stack_top.

But the Tibers stacking sections (nose, cockpit, cargobay etc) are all angy 1.0 (form memory). Would changing these to +/- top/bottom (front/rear) cancel out the fuselage lift characteristics?

How would I apply this to the wing nodes. fuselage angy+1 and wing angy-1, or both angy+1. Would the Ferram properties added to the wings negate this effect?

Dammit, I'm so keen to knock of work now to try all these ideas...

[SnappingTurtle]

Deflecting flaps past their stall angle seems to work, this should cause extra high drag because of the separation of the boundary layer, right? Is this a good or bad idea for landing? Are FAR flaps from standard control surfaces more realistic than B9's airbrakes which seem to have extremely high drag?

Edited December 13, 2013 by SnappingTurtle

[ferram4]

@azza276: The angle values aren't used anymore for anything but the surface attach (I believe) on any parts, so FAR doesn't do anything with them. That said, the node values (other than the surface ones) do nothing for wings. Fuselage and wing parts use completely different aerodynamic models; the former makes use of attach nodes for drag characteristics, the latter only uses the surface node to figure out how the model is oriented.

@SnappingTurtle: Yeah, it'll make quite a bit more drag, but you'd be surprised how much lift you can make while still stalling something; it's just a lot draggier. It's probably good for landing.

[azza276]

@azza276: The angle values aren't used anymore for anything but the surface attach (I believe) on any parts, so FAR doesn't do anything with them. That said, the node values (other than the surface ones) do nothing for wings. Fuselage and wing parts use completely different aerodynamic models; the former makes use of attach nodes for drag characteristics, the latter only uses the surface node to figure out how the model is oriented.

Sorry, I think I got a little confused... But don't you mean aerodynamics model for the fuselage uses the Stack nodes for drag, and for the wings use the attach nodes for orientation (e.g. calculating AoA?)

I think I still need further explanation of the use of nodes. So does a fuselage have attach nodes? or does it just allow surfattach? Are attach nodes used on non-stacking parts to specify the point at which that part connects to the surface (of a fuselage) and rotates around that node (when ghosted to that surface) when in the VAB/SPH?

Only reason I think I am getting confused is because I did try to change some of the stacked nodes to attach nodes (making sure to name the attach node properly) but they didn't show the green ball in the SPH, and could snap them to each other, they were in the same position as the stack node just defined them as attach. So my questions above are based on what I saw, and just want to confirm this is normal behavior or have I right royally stuffed up the cfg?

Cheers

[ferram4]

Yeah, that's what I said, except wings only use the surface attach nodes to calculate the offset of the CoL from the wing root. After that, wings don't do anything more with it.

Every part has attach nodes. That is how the ability to attach parts to each other are defined. The stack nodes are a subset of attach nodes, used to connect a specific section of one part to a specific section of another (top of tank to bottom of another). Surface attach nodes are another subset of attach nodes used to define radial attachment of parts (fuel tank slapped on the side of another fuel tank), used on all parts, stacking and non-stacking.

I dunno what you managed to do with the config, but I guess that works. I haven't played with attach nodes too much.

[a.g.]

Every part has attach nodes. That is how the ability to attach parts to each other are defined. The stack nodes are a subset of attach nodes, used to connect a specific section of one part to a specific section of another (top of tank to bottom of another). Surface attach nodes are another subset of attach nodes used to define radial attachment of parts (fuel tank slapped on the side of another fuel tank), used on all parts, stacking and non-stacking.

More specifically, every part can have at most one surface attach node, and any number of stack ones. Also, the 'angle' name is misleading, because unless I'm very much mistaken that is just a unit vector defining the orientation of the node. When attaching it is aligned to match the surface normal for surface attach, and the similar orientation vector of the other node for stack. FAR actually uses the stack and surface attach orientation in a heuristic to resolve some difficult cases of radial part main axis orientation.

[NathanKell]

ferram, can you take a look at the FASA Mercury? Especially the strap/decoupler for the retro pack. It seems to add a TON of drag, to the point where a built Atlas has a crazy-high CoP.

I'm using this config, by me and Dragon01 (WIP): https://www.dropbox.com/s/89h5824hby2xsei/FASA.cfg

But it'll probably still exist for the unrescaled part too.

[Guest]

Ah, I was just about to PM you about that. The whole thing is unstable and tries to flip out after 100m/s because for that. And here I was buffing the verniers trying to combat this (still good, though, I've found that the new value is more realistic)... Anyway, I'd really like to know what's going on, Atlas is near-unflyable because of that (near, because the buffed vernier can hold it on course somewhat).

Oh, and BTW, I've found a neat datasheet for various Atlas vernier configurations. The only problem is that all thrust are SL, and I'm estimating vacuum ones. NA-13 is what we use, NA-15 a the later one.

http://heroicrelics.org/info/lr-101/lr-101.html

[azza276]

Ok, been playing around a bit and still no luck... I think I am close though. The issue now seems that the FARWingAerodynamicModel applied to the right wing is causing issues.

What I see is I have the model (cockpit and cargo) and everything centreline. I add the right wing and the CoL moves backwards but stays on the centreline. Add the left wing and the CoL moves to the left. Remove the right wing and the CoL sits on the left wing. So the FAR aero model module works on the left wing but when the same settings are applied to the right wing, it moves the CoL to the left of the wing.

Is there anyway of mirroring the module for the right wing? I tried some of the values with a - sign, no change. I even changed the nodes orientations and that had no affect. Ran without the stack nodes and surfaced attached, no change, commented out the FAR module (to apply the default) shuttle still flips out, even though the CoL sits just behind the CoM.

I know you said it is designed for symmetrical wings etc, just wondering if it is mirrorable for the right wing? (Or left if that is the actual issue...)

Cheers

Azza