Why are ships rotating? (during warp)

[MechBFP]

SAS turns off during warp, otherwise it would. 

[Kesa]

1 hour ago, firda said:

And what are you doing, when you hit 'W'?

You are activating torque system (RCS or action wheels) which will alter rotational momentum of the ship. The command and its effect is independant of referential, they are relative to the ship (causing him to pitch down, or to slow a pitch up -or the opposite if like me you changed the control because a keyboard is not a joystick, up and down being define by the control point of the ship).

The referential is just a way to describe things here, but has no bearing.

Quote

If the ship is not rotating, then the universe is.

Both descriptions are valid, but the one where the ship rotates is the simplest, and the one used in the coding of the game.

Quote

Orbit is something else, you orbit around some body, but rotate around your own CoM.

Yep. Orbiting describes a mouvement of the CoM, without precision, it is a translation (eg no rotation).

Quote

That rotation can be zero in some reference frame and non-zero in another, but at least one of these frames won't be inertial and there would be some fictional forces acting on objects (making Kerbing appear like orbiting around the ship and moon doing some crazy flower-shaped orbits around you ... people actually described geo-centric systems like that, before moving to helio-centric).

Yes. Except for landed vessels, I'm pretty sure the game engine computes orientation and rotation, in an inertial frame of reference, which never coincides with the spherical coordinate system atached to the body your orbiting, the one that corresponds to what the Navball is showing you. For the very reason it never corresponds to an inertial frame.

Quote

I have started this, becase I was observing my ship in warp and seen, that Kerbin is rotating around the ship (you can enter the cockpit to see same thing),
but I had SAS locked to prograde and the only reasonable thing for me was, that the prograde-locked SAS should actually make the ship rotate (in global reference frame, where the ship is orbiting Kerbin and not the other way around) to match the period of the orbit, becase that is the most stable result, requiring least amount of energy to maintain (zero in ideal world),
but KSP is doing something else - it cancels the rotation in global reference frame ... and maybe even the coding of prograde-SAS is somehow wrong, to treat zero-rotation in global frame as stable, which it is not (becase the SAS needs to repeatedly cycle between readjusting to prograde and pseudo-stabilizing in global reference frame, that is just wrong).

An accurate description of what the SAS system does.

A stability assist is hard to get done right, and it was initially bugged. The goal of SAS prograde is to reach prograde as fast as possible, which has the side effect of locking the craft to prograde. To work as you expected it to work would require that the SAS system :

• Assumes that you want to minimize the amount of energy spent, which generally is not the case. The biggest use of SAS prograde is for a gravity turn, and you want your craft to point forward as soon as possible when you hit the SAS button, because taking a more economical path may result in rapid unpllaned dissassembly.
• Knows the period of the orbit, and knows it is a circular one. You can't assume that. SAS can't know this information. Ok, technically, it could "learn it" with minimal memory and computation required, and don't necessarilly need to know it (see below).
• Knows that is the most stable result. Studying the stability states of a system is an hard problem, and not one to be solved by a SAS.

So in short, SAS gets its job done (helping you in flight) and stabilizing a space station at a non zero momentum is not a task it was designed for because the game assumes you will time warp anyway.

Now if we look deeper, SAS should, in theory at least, be able to do what you'd want it to do (though I would not count on it in practice.

Tools like SAS are typically PID controllers, (Position Integral Derivative), and it happens that a PID controller, or even a P controller could stabilze a station the way you'd want it (but the three point above holds if you hold prograde in weirder situations, like elliptical orbit, target relative velocity...). Problem is, such a controller would need parameters fine tuned to work for very slow orbital rotation, and probably would not work well in more common and critical situation with much shorter times and bigger rotations, like atmospheric flight.

If your observations are right, which I believe they are, I suspect what's happening is the following :

KSP prograde SAS is a PD controller, the Position coding the difference between the prograde and the forward vector. In a traditional PD, the Derivative should be the derivative of P, but for computation saving purposes, the Derivative is the angular momentum, which the game has anyways to compute the motion of your ship. That precisely causes the problem you're describing.

 

But I can't be 100% sure it's not just a matter of parametrisation, SAS parameters being calibered for flight and lacking precision.

 

Edited June 6, 2018 by Kesa

[Vanamonde]

This thread involves physics and stuff. And so it has been moved to Science and Spaceflight. 

[OHara]

8 hours ago, Tyko said:

I don't think that tidal influence really matters for craft, even in real life. It's a very subtle effect that wouldn't get the craft tidally locked in any reasonable period of time.

Tidal forces are just enough to get a long stick-shaped satellite to rotate as fast as the orbital period, within about half an orbit.   It then takes a very long time for the swinging to damp down to one of the two stable orientations, pointing radially out or radially in, but the initial swinging starts fast enough that tidal forces are obvious.

KSP applies the same gravity to all parts of any single craft, no different for the parts slightly closer or further to the planet, so it usually doesn't demonstrate tidal forces.  

If you let fuel tanks float loose in cargo bays, however, KSP separately applies local gravity to those tanks.  A craft like this will be swung around by tidal forces.  If you let it run with physics-on time-warp, it will start to tidally lock enough that one end is always pointing above the horizon.  I cheated one into orbit, and decoupled the caged fuel tanks, just starting to cook dinner, and now it is swinging around, pointing just above the western horizon on the day side, pointing just above the eastern horizon on the night side of the orbit.  On average, it is rotating as fast as it orbits, nav-ball always showing  more sky than ground.

[OHara]

 

8 hours ago, firda said:

 So, my "if you give it the proper amount of rotation (hit "W" a bit)" and Shadowmage's "You'll need a rotation rate that matches your orbital period." is exactly what I expected prograde-locked SAS to do 

SAS, when locked to prograde, does give you the rotation rate matched to your orbital period, as you want.

The problem is that KSP's "on-rails" time-warp  (the one you get by pressing '.'  without the [alt] key) turns off the SAS (as MechBFP said) and suddenly stops the rotation of the ship.   You are not the only person to want different behavior; someone made a mod Persistent Rotation to teach KSP to obey physics better and keep ships rotating during 'on-rails' time warp.

Edited June 7, 2018 by OHara

[firda]

To OHara: I will definitely try the mod, when I have the time.

To Kesa: I know PIDs, wrote some myself: https://robotics.stackexchange.com/questions/3178/controlling-a-system-with-pid-that-resists-backdrive/4964#4964
The fine-tuning is usually to miminize overshooting and oscillation. P-only regulator should, in theory, achieve the rotation, PID should, after some dumped-oscillation, achieve that too. So again, I will try the mod.

8 hours ago, Kesa said:

• Assumes that you want to minimize the amount of energy spent, which generally is not the case. The biggest use of SAS prograde is for a gravity turn, and you want your craft to point forward as soon as possible when you hit the SAS button, because taking a more economical path may result in rapid unpllaned dissassembly.
• Knows the period of the orbit, and knows it is a circular one. You can't assume that. SAS can't know this information. Ok, technically, it could "learn it" with minimal memory and computation required, and don't necessarilly need to know it (see below).
• Knows that is the most stable result. Studying the stability states of a system is an hard problem, and not one to be solved by a SAS.

1. That is where I-part kicks in, because it accumulates the difference quickly, to overrule P-part to make the adjustement quicker (but causes overshooting and oscillation if unchecked - D-part helps canceling this side-effect). But the accumulator will then diminish when you get close to the goal and PID will revert to P-only regulation (with possible constant accumulated offset to counter lower-P factor used in PID regulator, but it would act like P-only with Kp=1 when stabilized).

2. Circular orbit is the condition for stable result, not that the PID would need to know it, it should achieve the goal when e=0. It would not if e>0, because the rotation won't be stable, it would with e=0 and that is all the PID has to care about.

3. PID is designed to achieve stable result (if the set-point is stable) and the goal is keep prograde oriented. The feed-back is the difference between your forward vector and prograde vector and it will try to minimize that difference, which is exactly what you need to get the wanted rotation (assumming infinitesimal dt and infinite precision of numbers, real world gives tiny difference for P-only and tiny oscillation for PID ... look at my experiments in the link, my PID regulator quickly ended with one-bit oscillation).

[Kesa]

3 hours ago, firda said:

 

Really nice! If you're into coding, you should definitely check

if you don't already know it (no sure it's stable or recent). It lets you writte program to act on the rocket, like, for example a PID SAS with the correct input and behaviour.

Edited June 7, 2018 by Kesa

[Superfluous J]

6 hours ago, OHara said:

A craft like this will be swung around by tidal forces.

You, sir, win yourself one free Internet. That is the most awesome thing I've seen in KSP in a long time.

[kerbiloid]

I'm not sure if I got it right:
is this thread about tidal orientation or also about that fuelless propulsion of a dumbbell craft?

[firda]

On 6/7/2018 at 12:12 PM, Kesa said:

Really nice! If you're into coding, you should definitely check

if you don't already know it (no sure it's stable or recent). It lets you writte program to act on the rocket, like, for example a PID SAS with the correct input and behaviour.

 

kOS is the reason I can achieve orbit with eccentricity 0.0000 (reported by DMagic's Basic Orbit) and see how Apo+Peri are jumping like mad

Edited February 12, 2019 by firda
Outdated info and link

[Aphobius]

Quote

Quote

If the ship is not rotating, then the universe is.

Both descriptions are valid, but the one where the ship rotates is the simplest, and the one used in the coding of the game.

No, they are not, he seems to lack some basic notions of physics, you shouldn't encourage him.

Rotation is not relative like velocity, if you have a rotating bar, it will get longer because of the centrifugal force. If you choose a rotating non-inertial reference frame that is fixed on the bar, even if you could say that the bar is not rotating in that reference frame, the bar is still a ROTATING bar that is getting stretched because of the centrifugal force. That stretching doesn't disappear because you choose a different reference frame.

Even a better example, if you have an object suspended in a box (consider it to be the "universe"), a situation where the object is rotating and the box doesn't is not equivalent with a situation where the object doesn't rotate and the box does. In the first situation only the object is getting stretched, in the second situation only the box is getting stretched.

[magnemoe]

On 6/7/2018 at 6:06 AM, OHara said:

Tidal forces are just enough to get a long stick-shaped satellite to rotate as fast as the orbital period, within about half an orbit.   It then takes a very long time for the swinging to damp down to one of the two stable orientations, pointing radially out or radially in, but the initial swinging starts fast enough that tidal forces are obvious.

KSP applies the same gravity to all parts of any single craft, no different for the parts slightly closer or further to the planet, so it usually doesn't demonstrate tidal forces.  

If you let fuel tanks float loose in cargo bays, however, KSP separately applies local gravity to those tanks.  A craft like this will be swung around by tidal forces.  If you let it run with physics-on time-warp, it will start to tidally lock enough that one end is always pointing above the horizon.  I cheated one into orbit, and decoupled the caged fuel tanks, just starting to cook dinner, and now it is swinging around, pointing just above the western horizon on the day side, pointing just above the eastern horizon on the night side of the orbit.  On average, it is rotating as fast as it orbits, nav-ball always showing  more sky than ground.

This, note that if you have an stick like satellite you would add an rotation of one turn each orbit to keep it pointed correctly, here the tides just have to compensate for errors not rotate the satellite who would take an long time. 
You also has drag because of air resistance, this is why ISS is pointed flat in the orbital direction, they even rotate solar panels and radiators to minimize drag while behind the earth. For an satellite with lots of solar panels but lightweight solar wind push is also an issue.