Weird shuttle behaviour

[Mat2ch]

Hi,

I'm currently fiddeling around with the Space Shuttle. (I've already learnt that the big-S Tail fin is not a good idea to use as the whole thing thens to oversteer)

My Shuttle flies on the back of a tank and makes an orbit (with a full orange fuel tank). But I've got a problem on reentry. The shuttle looses its lift and then falls to the ground with a back first. Usually I'd say, CoM behind CoL, but I made sure that this is not the case.

Then I took a look at the aero overlay. And on some occasions there's a cyan vector appearing and if that happens the spin starts. As if there's another lifting surface which you don't see in the editor. And it is huge.

In the first image you can see that CoL is far behind CoM and it stays there, although I've added additional engines for the flight test. You can see in the second and third picture that the wings do what they should. Now on pancake manouvers you see the cyan vectors appear, which seem then to get bigger than the lift. On fourth and fifth image the shuttle has spun out of control and is falling down with it's back, although the mass should push the nose down.

What is it? And why do I have the feeling that the game mechanic is wrong here? (or my understanding of the events that would happen in real life)

[Rodyle]

It seems to be the issue that your CoT isn't in line with your CoM enough, which creates a lot of torque.

[Snark]

19 minutes ago, Mat2ch said:

As if there's another lifting surface which you don't see in the editor.

Except that you do see it in the editor.  It's huge.  It's called the "fuselage". 

The problem is that your ship is aerodynamically unstable.

A common mistake that people make is that they think "I'm good if my center of lift is behind my center of mass."

The problem is that you're looking at the wrong thing.  What's important is that your center of drag is behind the center of mass.  Drag.  Not lift.  For aero stability, that's all that matters.

(Keeping CoL behind CoM is good, too; it's for stable level flight so that you don't pitch-up too much and stall.  But it's not the problem you're facing here, and in any case, the CoL indicator in the SPH only shows the lift from wings and explicit aero surfaces; it doesn't show body lift generated by the fuselage.)

Look at where your CoM is.  It's way the heck in the back of the plane.  Then you've got that big huge draggy fuselage sticking out in front, which desperately wants to be behind the center of mass.

You say that "the mass should push the nose down."  It doesn't do that because it's nowhere near the nose.  The mass is at the tail end of the ship, so of course it pushes the tail down.

Furthermore, your craft has very little steering ability.  for pitch or yaw.  The effectiveness of a control surface depends on how much torque it can generate, and torque is directly proportional to the lever arm you give it, meaning how far from the center of mass.  Look at where all your control surfaces are, and then look at the center of mass.  They're practically right on top of each other, very close together.  They're going to be extremely weak at trying to steer.  One simple solution is to add a pair of canards way up at the front; those will be very far from your CoM and will therefore give you a fair amount of pitch authority.

Also, have you configured your control surface rules?  Specifically, have you set up your tail fin so that it only helps with yaw, and not with roll?  If you haven't, then it's fighting itself and reducing the effectiveness of all your control surfaces.  Whenever you try to yaw to the right, it's going to induce roll to the left, and it'll try to move the fin the other way to compensate for the roll and thereby end up fighting itself.  You want the tail fin to exercise yaw only, and you want your ailerons to be roll and pitch only (no yaw).

Edited January 19, 2016 by Snark

[max_42]

1 hour ago, Snark said:

Then you've got that big huge draggy fuselage sticking out in front, which desperately wants to be behind the center of mass.

THANK YOU, I finally understand. You made that so easy for me to wrap my head around

[Stoney3K]

14 hours ago, Snark said:

Except that you do see it in the editor.  It's huge.  It's called the "fuselage". 

The problem is that your ship is aerodynamically unstable.

A common mistake that people make is that they think "I'm good if my center of lift is behind my center of mass."

The problem is that you're looking at the wrong thing.  What's important is that your center of drag is behind the center of mass.  Drag.  Not lift.  For aero stability, that's all that matters.

When are we ever going to convice Squad that they need to calculate the center of drag (and body lift) as well so we can actually check them in the VAB? In other words, how can we even predict where the center of drag is going to be?

Right now, when drag is concerned, we're just guessing and flying blind when constructing our ships.

[Temstar]

16 minutes ago, Stoney3K said:

When are we ever going to convice Squad that they need to calculate the center of drag (and body lift) as well so we can actually check them in the VAB

It's a non-trivial problem because centre of drag depends on AoA, particularly AoA of the fuselage. As a result the centre of drag is dynamic and subject to extreme changes during flight.

In fact centre of lift depends on AoA too, in the SPH they just assume head on and level flight and give you the centre of lift based on that. But as you can see when you turn the aero overlay on the arrows will change in flight depending on AoA.

[Val]

20 minutes ago, Temstar said:

In fact centre of lift depends on AoA too, in the SPH they just assume head on and level flight and give you the centre of lift based on that. But as you can see when you turn the aero overlay on the arrows will change in flight depending on AoA.

Only when the craft is facing the default direction. If you pitch the craft in SPH or VAB, you can check how the CoL moves when AoA changes.

Regarding Center of Drag, I usually just assume it's right in the middle of the craft, and place my CoM and CoL close to the middle of the craft too, to avoid any surprises from CoD.

[Mat2ch]

Hello Snark and everyone else, thanks for answering my post.

Yes, I feared that the cyan vectors are the drag vectors and that they are throwing my shuttle around. It's the first time I encounter this problem (at least I think so), before all my crafts flew very stable (but most of them had canards, so...).

6 hours ago, Stoney3K said:

When are we ever going to convice Squad that they need to calculate the center of drag (and body lift) as well so we can actually check them in the VAB? In other words, how can we even predict where the center of drag is going to be?

Right now, when drag is concerned, we're just guessing and flying blind when constructing our ships.

Yes, you are totally right here. But also drag and body lift is the same in real life. It's air particles hitting a surface. There is no difference between them and Squad should get rid of the drag and add an aero vector to all parts. Would also solve the editor problem once and for all.

[montrealshark]

I have a follow up question to this -

I have a similar shuttle design (only difference is a short MK3 rocket fuel fuselage instead of monoprop at the back and thuds for OMS), and I'm having similar issues with CoM location and getting it to fly stably during reentry. I understand the concepts Snark mentioned about CoM/CoL and placement of control surfaces. What I don't understand is why I've seen many similar designs that can remain stable during a nose up pancake reentry. What changes do I need to make to the shuttle to get it to fly right during reentry (and still look like a shuttle)? I'm clearly missing something, but I can't figure out what based on pictures of other STS type craft.

Pictures of my shuttle:

http://imgur.com/jz9NkhP
http://imgur.com/taUwFXg
http://imgur.com/Y6Aaznk

 

[Snark]

16 hours ago, Stoney3K said:

When are we ever going to convice Squad that they need to calculate the center of drag (and body lift) as well so we can actually check them in the VAB? In other words, how can we even predict where the center of drag is going to be?

Right now, when drag is concerned, we're just guessing and flying blind when constructing our ships.

I'm quite certain it's not a question of "convincing" Squad of anything.  They know it's an issue.  The single most common newbie problem is "Why does my rocket keep flipping?"  It's been a continuous and frequent complaint since the new aero came in.

The issue is, as other posters have said:  this would be a major feature to add.  Not just in terms of engineer-hours of time to code it:  it would be tricky to design what the user experience would look like.  It's not simple like CoM or CoL; you can't just add a CoD marker, because the drag depends on speed, orientation, etc.  Does this mean it's impossible?  No, but it's very non-trivial, and you have to remember that Squad is a very tiny company and they really have their hands full with other major features to implement.

Here's an indication of how hard it is:  if it were easy, somebody would have produced a mod to do it and everyone would be using it.  It would be at least as popular as KER.

So I wouldn't be surprised Squad gets around to it sometime, I'm sure it's on their "wish list" of features  to implement.  But it has to wait its turn.

[swjr-swis]

3 hours ago, Snark said:

The issue is, as other posters have said:  this would be a major feature to add.  Not just in terms of engineer-hours of time to code it:  it would be tricky to design what the user experience would look like.  It's not simple like CoM or CoL; you can't just add a CoD marker, because the drag depends on speed, orientation, etc.  Does this mean it's impossible?  No, but it's very non-trivial, and you have to remember that Squad is a very tiny company and they really have their hands full with other major features to implement.

Here's an indication of how hard it is:  if it were easy, somebody would have produced a mod to do it and everyone would be using it.  It would be at least as popular as KER.

First: agreed that Squad already has their hands full. No criticism here on that. I'm only passionate about this because it would improve the design process so much.

But: I am inclined to disagree that this is either tricky to design or massive to code.

• There is already code to calculate and show drag vectors on all separate parts, fully coded in the game: the flight scene F12 aerodynamics display.
• Currently that display shows a vector per part, and perhaps in the flight scene it's maybe too much of a calculation impact (or it's done on purpose to give us a more detailed view of drag), but would it not be as 'simple' as combining those separate vectors into one, with code very similar if not identical to that used to combine the lift and thrust vectors of multiple parts into a single CoL/CoT?
• In the VAB/SPH that exact same code could be reused for this purpose. The only thing missing there is a vector for the velocity through the air. Obviously there won't be a 'live' velocity, but all it needs is to add an UI element for the player to create an artificial velocity.
• The UI for this can reuse elements already coded in the game as well: an extra button showing a combination/derivative of the rotate/offset gizmos would in my opinion be very intuitive/fitting with the rest of the interface. For example, add only the 'up/forward' arrow of the offset gizmo to the circles of the rotate gizmo, and call it the 'drag gizmo'. Click and drag the arrow shorter or longer to set a high/lower artificial velocity, click and drag the circles to rotate the direction in any of the planes, and you got your vector. The aero display code can use that artificial velocity vector to draw the CoD. Since in the editor it's purely informative, the calculation doesn't need to be continuous (just recalculate when the drag gizmo is used), so performance impact could be almost negligible.

To keep it as minimal work as possible and really just reuse existing code, I'd already be happy if all the first iteration did was show the exact same thing as the F12 aero display in the flight scene. Not as quick and easy to understand as a single ball marker like the CoT/CoL, but it would be something, whereas now we have nothing but our gut feeling and trial and error to go on.

Am I way off that all these elements are essentially already in the game?

[Mat2ch]

Oh, I just got another idea. Adding a "simulate" button. It will show you how the CoL and CoM behaves in different flight situations. It doesn't have to be a full calclation of every angle. Just once from -90 to 90 degress pitch, same for yaw and roll. Usually we're flying forward, so no 360° simulation required. (And this is just a proposal, doesn't have to be discussed).

[Stoney3K]

2 hours ago, swjr-swis said:

First: agreed that Squad already has their hands full. No criticism here on that. I'm only passionate about this because it would improve the design process so much.

But: I am inclined to disagree that this is either tricky to design or massive to code.

• In the VAB/SPH that exact same code could be reused for this purpose. The only thing missing there is a vector for the velocity through the air. Obviously there won't be a 'live' velocity, but all it needs is to add an UI element for the player to create an artificial velocity.
• The UI for this can reuse elements already coded in the game as well: an extra button showing a combination/derivative of the rotate/offset gizmos would in my opinion be very intuitive/fitting with the rest of the interface. For example, add only the 'up/forward' arrow of the offset gizmo to the circles of the rotate gizmo, and call it the 'drag gizmo'. Click and drag the arrow shorter or longer to set a high/lower artificial velocity, click and drag the circles to rotate the direction in any of the planes, and you got your vector. The aero display code can use that artificial velocity vector to draw the CoD. Since in the editor it's purely informative, the calculation doesn't need to be continuous (just recalculate when the drag gizmo is used), so performance impact could be almost negligible.

I figure adding an artificial aerodynamics UI where the player can set altitude and velocity (much like the dV display in KER) would serve a second purpose as well: Calculate the thrust and Isp values for rocket and jet engines at altitude, much like KER does now. Right now there is no way, at least in stock, to determine how much oompfh your Whiplash is going to produce when you're flying Mach 3 at 15000m, other than just trying it out.

[ineon]

2 hours ago, swjr-swis said:

I am inclined to disagree that this is either tricky to design or massive to code.

Just wondering: are you a coder?

I am a programmer by profession, and I find that non-coder that I come into contact with (sales, product managers, ...) consistently underestimate how much coding effort something takes - often by orders of magnitude.

Pure Speculation: I would guess that the VAB/SPH code is well separated from the drag vectors in flight, but the drag vectors are tightly coupled with the code outside the VAB/SPH. So, while the code for displaying these vectors already exists, it would be really awkward to try to use that code in the VAB/SPH. There are probably some other weird snags, like it is possible to detach parts from a craft and then the Centre of Drag tool would have to be explicitly told to not worry about it, or editing a craft and recomputing physics might be really laggy. None of these things are show-stoppers by themselves, but they all would need doing. 

And finally, don't forget Hofstadter's law: 

Quote

It always takes longer than you expect, even when you take into account Hofstadter's Law.

 

[Starwaster]

2 hours ago, ineon said:

Pure Speculation: I would guess that the VAB/SPH code is well separated from the drag vectors in flight, but the drag vectors are tightly coupled with the code outside the VAB/SPH. So, while the code for displaying these vectors already exists, it would be really awkward to try to use that code in the VAB/SPH. There are probably some other weird snags, like it is possible to detach parts from a craft and then the Centre of Drag tool would have to be explicitly told to not worry about it, or editing a craft and recomputing physics might be really laggy. None of these things are show-stoppers by themselves, but they all would need doing. 

No, having a center of drag indicator in the VAB wouldn't be a difficult thing; you're overestimating the difficulty involved.

Its usefulness however is debatable and it's a topic that's come up often over the past few years. Probably too often or you'd already have excessively knowledgeable people coming in this thread already to tell you why it's a bad idea. (like @ferram4)

I won't go into the reasons why here but you can find a good discussion on the topic  at https://www.reddit.com/r/KerbalSpaceProgram/comments/3bbbv8/mod_idea_center_of_drag/

Edited January 21, 2016 by Starwaster

[ineon]

15 minutes ago, Starwaster said:

No, having a center of drag indicator in the VAB wouldn't be a difficult thing

You say that with a high degree of certainty. Can I ask how you are so sure?

[swjr-swis]

1 hour ago, ineon said:

Just wondering:

That makes two of us.

 

[Starwaster]

48 minutes ago, ineon said:

You say that with a high degree of certainty. Can I ask how you are so sure?

Because I'm a coder who understands the code required to make it happen and who doesn't have to speculate as to its feasibility.

I write code on a regular basis for several KSP mods and have coded my own from scratch.

[Snark]

My own two cents on the debate of "how hard would it be to add a design tool":

I think that adding a tool for drag/stability in the vehicle editor is pretty much a non-starter.  It's primarily a design problem (how to make something that's complex enough to be useful, but simple enough to be 1. usable by newbies, and 2. not a nightmare complex feature to code).  Drag depends on so many factors:   speed, angle of attack, air density.  And instability issues can happen anywhere along the flight path-- CoM shifts around as fuel drains, there's staging, etc.  It's really hard for me to picture something in the VAB/SPH that would actually be useful without being so complex it's confusing.  It would end up being something that amounts to a "wind tunnel", and by the time you've added all the features you need, you end up with something so complex that it's tantamount to just flying the darn ship.

However, I think that one thing that would be both extremely useful and easy to code would be to add "center of mass" and "center of aero" markers to the debug aero display.  Still doesn't help you in the VAB, but at least it would give you a very easy-to-read indiction in flight of what's going on, and would make answering "why is this flipping" questions a lot easier to debug.

I went ahead and posted this as a suggestion in the suggestions forum:

 

Edited January 21, 2016 by Snark

[Xooxer]

Programmers: always over-complicating things. We don't need any fancy UI in the VAB. What we need is a friggen wind tunnel. Not even engineers trust their math when it comes to drag and airflow, they determine it empirically with functional tests in the controlled environment of a wind tunnel.

 

Give me a building that I can pass visible air over my craft and let me alter the orientation during the testing. That is a trivial addition. Right now, our only option is to fly the craft and use the atmosphere as our wind tunnel.

 

<rant>

The lack of a wind tunnel is a crippling factor for this game. Major failure, if you ask me. Almost on par with making UI element transparent to clicks, so clicking a button also clicks the ship part under it. So frustrating.

</rant>

Edited February 1, 2016 by Xooxer
a little less ranting