Why does my vertical landing vehicle start rolling upon (reverse) entering atmosphere?

[paul23]

Well I have made a craft that is supposed to land (and lift off) again vertically. It's a single stage to orbit craft, and shouldn't use any modded parts anymore.

 

However upon flying the craft I notice it starts rolling out of control if I enable SAS. - Worse I notice that the roll motion implied by SAS is actually causing the unstable roll, yet the yaw and pitching motions are fine "cancelling" things out the rolling motion is actually "reversed" upon landing. I've tried reversing the control from the probe, however that just makes the whole thing unstable. So what am I doing wrong? How can I prevent the rolling into kraken drive?

 

The craft file made in vanilla 1.7.3

 

You can test it by putting the craft into low kerbin orbit (either flying or whatever other method), and then lowering periapsis to 45ish kilometers. (much lower and the craft starts disintegrating). - Make sure to enable the brakes (airbrakes). Around 30km altitude the craft will start rolling and you'll actively have to counter this, making controlled landing hard if not impossible.

Edited December 9, 2019 by paul23

[AHHans]

9 hours ago, paul23 said:

If there are any modded parts in the craft file tell me btw, I tried (and tested) with just vanilla parts

Well, the list of non-stock parts in the craft file is pretty long, my stock KSP refuses to load the craft.

[Geonovast]

In addition to the craft file, it would really help to have pictures of the craft.  Video of the problem too if you can swing it.

[paul23]

7 hours ago, AHHans said:

Well, the list of non-stock parts in the craft file is pretty long, my stock KSP refuses to load the craft.

Oops, I forgot a lot of mods add extra "Modules" to the craft file even for vanilla parts (mechjeb for all etc). I've remade the craft in a fresh install of ksp 1.7.3, it should work now perfectly and I tested it. I notice that the rotation start "later" and is "slower" in the vanilla atmosphere (at least not going into kraken territory). However the effect is still there, where the SAS is actually rolling in the wrong direction and hence increasing the roll.

Updated the craft file, it should now show in 1.7.3 and 1.8 at least. Sorry and thanks for warning me.

 

 

2 hours ago, Geonovast said:

In addition to the craft file, it would really help to have pictures of the craft.  Video of the problem too if you can swing it.

I need to get some video capturing tools first, but it's quite simple:

Top is a docking port + okto2, then some utility (reaction wheels, rcs tanks) and the airbrakes attached to those (to give a stable descent). A hitchhiker, big 2.5m tank and finally a mainsail. Parts don't particularly matter those, it's about the geometry. Okto is put on "default" setting for landing, but forward & reversed gives the same problem (if I aim the craft correctly).

You can see the sas has a maximum roll deflection, but when in game the roll deflection is actually increasing the roll motion, so SAS should deflect the other way.

 

Putting SAS off actually makes the craft "stable" (so it is aerodynamically stable). However then doing a suicide burn might topple the craft, since it's unstable in the other direction, kind of need SAS for a retroburn. And as I plan to let these things go automatically (many launches) using Mechjeb it's even worse.

Edited December 9, 2019 by paul23

[AHHans]

2 hours ago, paul23 said:

Updated the craft file, it should now show in 1.7.3 and 1.8 at least. Sorry and thanks for warning me.

O.K.

2 hours ago, paul23 said:

Putting SAS off actually makes the craft "stable" (so it is aerodynamically stable).

Well, yes and no. For aircraft in KSP I identified two general regimes: low&slow and high&fast. At low-ish speeds (say less than mach 2.5) and low-ish elevations (less than 10 - 20 km) the aerodynamic forces (on most craft, I'm sure you could create an exception to the rule) are dominated by lift. At high elevations the air is too thin to generate significant lift, but at high (e.g. near orbital) speeds the drag is still significant. So your craft is aerodynamically stable falling "tail forwards" in the high&fast regime, but in the low&slow regime the airbrakes generate less drag than the winglets at the tail generate lift, so it flips (at least when I tried) and falls nose forwards.

[*more testing*]

The "SAS induced roll" is because you have way too much roll control authority when the winglets generate significant lift. Not only are all winglets ideally placed to affect roll, but also you have little moment of inertia along the longitudinal axis. Combine that with the fact that SAS doesn't try to minimize the speed of roll, but tries to keep a certain angle of roll. So when SAS tries to do a small correction to roll, it oversteers by a large amount. Then either because due to a bug in the implementation (number overflow?) or in the design of the SAS control algorithm it keeps oversteering more and more. If you disable roll control on the winglets, then this doesn't happen, and SAS manages to keep the craft steady ... until it wants to flip.

 

Edited December 9, 2019 by AHHans

[paul23]

Hmm but that would mean I'd also be unstable in the rolling direction when lifting off, or when I go nose down descent. I didn't notice that. As for stability: FAR removes that "difference": drag & lift work both equally based on density & velocity (as it should be, they have the same factors and same formula in reality).

Edited December 9, 2019 by paul23

[AHHans]

1 hour ago, paul23 said:

Hmm but that would mean I'd also be unstable in the rolling direction when lifting off, or when I go nose down descent.

Well, O.K. Maybe it's something else.

45 minutes ago, paul23 said:

As for stability: FAR removes that "difference": drag & lift work both equally based on density & velocity (as it should be, they have the same factors and same formula in reality).

I used the definition of "lift" and "drag" that is also used here: https://en.wikipedia.org/wiki/Aerodynamic_force
And here: https://en.wikipedia.org/wiki/Lift-to-drag_ratio it says that e.g. the space shuttle had a lift to drag ratio of ~1 at hypersonic speeds and ~4.5 at low speeds.

[paul23]

Solution is indeed to stop the rolling authority on the wings. - Or putting the wings on the other side of the aerodynamic center. Can I do this in vab already? I think the reaction wheel is enough control for roll during launch.

[RizzoTheRat]

I found the controls for winglets gets it all wrong when flying backwards.  In the end I mounted my winglets backwards and disabled them for takeoff, then enabled them for landing where they worked correctly.  Mine are above the COM when descending though, not sure if that makes a difference.

 

[Snark]

On 12/8/2019 at 4:15 PM, paul23 said:

However upon flying the craft I notice it starts rolling out of control if I enable SAS.

That's right.  It's because you've got steerable fins, and you're flying backwards.  It's trivially easy to fix:  just change the control authority of the fins to be negative when you're flying backwards.

It's one of those things that's surprising to encounter, but makes sense in hindsight.  Explanation of what's going on in spoiler, for the curious.

Spoiler

Let's look at an illustrative example to set the context:

Let's say you're building an airplane, and for roll control you have some ailerons on the wings.

Now, while it's sitting on the runway, try pressing the Q key to make the craft try to roll left.  What happens?

• The control surface on the left wing tips up.
• The control surface on the right wing tips down.

That is, in fact, the correct thing to do-- it's just "common sense".  You can probably see, with your human eyeballs and brain, that those are the correct movements for those particular control inputs.

But how does the game know that?  It's just a dumb computer, it can't "think".  How does the game decide "which direction should I rotate the control surface, when I'm given a 'pitch up' control input?"

Answer:  It does it based on some calculations it does when you're assembling the craft.  It does various math, based on the orientation of the part, and also on where it's located.  So the game "knows", for each control surface, which direction to tip it to make the craft roll clockwise, and which direction to make it roll counterclockwise.

It's straightforward, it's reliable, it works great, and we all take it for granted.

But that code is assuming that the craft is flying in the direction.  It's assuming that the airflow is from the front of the craft to the rear.

If the plane were flying backwards, then you'd want the control surfaces to tip in the opposite direction, because the airflow is moving in the opposite direction.

You know that... but the program doesn't.  It bases its "which way to tip a control surface for a given control input" decisions based on the design of the craft, not on which direction the craft is facing during flight.

The executive summary is that the game's "control surface management" code assumes you're flying .  If you're flying backwards, i.e. , this means that the control inputs will be precisely backwards.  This applies to all control input, whether it's the player hitting the QWEASD keys, or SAS making automatic "corrections".

So, you end up in a spin because what happens is, when your craft just randomly happens to roll a little bit, SAS goes "oh noes, it rolled clockwise, Imma make it go counterclockwise" ... and then tweaks the fins in the wrong direction, which makes it roll more, which makes SAS tweak them harder in the wrong direction, and now you're spinning.

By changing the control surfaces to have negative control authority when you're flying backwards, that un-munges it and then they behave the way you want to. 

[Empiro]

I think that the game does the right thing even with reverse-pointed winglets if you are going forward, so another solution is to mount a backward-facing control point somewhere.