[v0.1.1.0] Attitude Auto-Pointing Unstable During Time Warp

[bdkaplin]

I noticed a bug where the auto-pointing/vehicle attitude control gets disturbed and sometimes decides to take the "long way" around to the desired pointing direction (for example, is 30 deg off of prograde and decides to continue rotation 330 deg rather than unwinding the 30 deg offset). This happens significantly more often when the offset is caused during time warp (either physics or just the desired pointing direction rotating) and results in significant control activity following reversion to 1x speed. On occasion, the behavior is unstable - the vehicle overshoots the correction, then decides to continue rotating rather than unwinding, etc. A few times, this has resulted in Kraken-like behavior.

Proposed Fix:

It depends on the exact root cause, for example if it's just a performance issue in the physics calcs. However, one possible cause could be attributed to how the game handles the ASAS simulation. If a torque command is generated in response to the attitude being stored as quaternions (my recommendation), then a possible error source could be in a handful of places: a) generating the target quaternion among the set of possible values, b) representation of the vehicle current attitude relative to inertial frame, c) chattering at the hypersphere equator (depending on convention this is the real part equal to zero, q0 or q4 = 0), or d) the control law itself.

For a) a fix could be as simple as normalizing the real part to the same sign as the vehicle (since the shadow set -q is the same physical orientation as q). For b) it depends if the chosen "inertial" frame is super important, but one fix could be to incline the relative frame a few degree to lessen the chance you are exactly 180 deg off of it. Alternatively, utilizing the shadow set again could work (always real part positive vehicle representation) but this increases chattering stability issues if you don't handle that separately. For c) again inclining the reference could work but otherwise you would want to introduce some hysteresis into the calculations. For d) there are several alternative control laws available designed to solve this issue, see for example Wie's Space Vehicle Dynamics and Control. A simple modification if using linear feedback is to multiply the quaternion term by the sign of its real part (so that it drives to the closest version of the target).

If you can replicate this and track it down, I'm happy to help. I teach attitude control and build and fly ADCS on rockets, missiles, and spacecraft.

[MehJeb]

all rotations in Unity are quaternions; if your rotation is exactly -180 deg (Euler?) than there is no difference which "way" the rotation happens... but this cannot happen as your other two axis are not null at any point in time...

Also, you may have a look at 

https://docs.unity3d.com/ScriptReference/Quaternion.FromToRotation.html

since it is the most common way to implement target rotations towards vector (and around another vector, usualy one of axis) in Unity

it is also an equivalent of 

Quaternion newRotation = oldRotation * givenRotation;

of course, noone stops you from either += * or *-1 ;-)

The question is: "what is the "correct" side to rotate via?" for airplane - no problem, its belly is +- limited to the ground plane (in Unity physics it is implemented via developer-configurable Gravity value); but for space-craft in true 3D space - what would be your constraint? Planet? Star? Axe of ecliptics? Relative to what should it turn left or right or any other Vector3?

[darthgently]

Well there is the OP case of shortest rotation path.  Additionally, in the orbital case,  any existing angular velocity could be taken into account along with available torque as there may be some cases (probably not overshoot cases) where it makes more sense to take the long angle way around because it is shorter from a torque and duration pov (would take more time to reverse rotation and backtrack than simply catch the target direction next time around)

[bdkaplin]

50 minutes ago, MehJeb said:

The question is: "what is the "correct" side to rotate via?" for airplane - no problem, its belly is +- limited to the ground plane (in Unity physics it is implemented via developer-configurable Gravity value); but for space-craft in true 3D space - what would be your constraint? Planet? Star? Axe of ecliptics? Relative to what should it turn left or right or any other Vector3?

Given two quaternions representing two orientations, there is a representation of the difference as a single rotation angle about a single axis. So, the most common implementation is to attempt such an "eigenaxis" rotation. From rest to rest, this is always possible, but if you are already rotating it's not always easy.  Adding a constraint (such as I want to rotate but keep one side facing the nadir/"down" direction) is beyond the scope of what KSP is going for, I think. It can be done, but is more difficult to do smoothly in a closed-loop simulation that only depends on the current vehicle state.

The tricker part here is how you represent either the current vehicle quaternion or the target direction. Saying "I want to point in the prograde direction" is not proscribing an orientation, because it leaves the roll angle about the pointing axis undetermined. So, there are an infinite number of quaternions representing this direction. Picking which one to plug into the Unity helper function is a non-trivial task and may or may not matter. Sometimes, you go "whatever, I don't care" and make a random selection, or hold some other value constant. And sometimes, that breaks the behavior in odd ways. I was suggesting that was one possible cause.

For an aircraft, Euler angles provide a natural way of representing pitch/roll/yaw from a reference case. Some quaternion implementations start with this and then convert to quaternions for the "under the hood" calcs (example in Unity). But, this destroys one of the benefits of a native quaternion representation, which is avoiding singularities that are present in Euler angle descriptions.

26 minutes ago, darthgently said:

Well there is the OP case of shortest rotation path.  Additionally, in the orbital case,  any existing angular velocity could be taken into account along with available torque as there may be some cases (probably not overshoot cases) where it makes more sense to take the long angle way around because it is shorter from a torque and duration pov (would take more time to reverse rotation and backtrack than simply catch the target direction next time around)

This statement is entirely true, but I doubt that is what the KSP2 simulation is doing, or at least not in detail. More likely, it is a simple feedback law saturated by available torque. I don't even know for sure if there is an allocation strategy (for example if I have multiple SAS modules) or if the parts are just additive to some vehicle maximum torque. The latter is simpler and faster, but less real world. The former introduces a new spot for error, because most allocation methods have singularities. I'm guessing it is somewhat of the former, with the torques added as part properties, because of the attitude instability of long, slender vehicles.
 

In terms of "maybe it makes more sense", one possibility is to estimate this by computing maximum torques and time in both directions, but doing so and including saturation of the torque elements is computationally expensive. So, you would have to have decent estimating procedures. Otherwise, it is generally an optimal control problem (which I love, but is probably beyond the scope of real-time simulation).

[darthgently]

42 minutes ago, bdkaplin said:

but I doubt that is what the KSP2 simulation is doing

I'm about certain this is not what KSP 1 or 2 is doing.  I was going more for the ideal and what I've attempted to do in kOS but still working on that...