Spin-up on reentry under physics warp with FAR

[eggrobin]

@nepphhh reported this issue, illustrated by the following video. https://www.youtube.com/watch?v=dNHiZsGIurg

Some notes from experiments by @nepphhh:

• the issue is not visible prior to Frobenius;
• the issue is not visible without FAR;
• the issue is not visible unless physics-warp is used.

@Myshiko reports that this only occur on reentries with high deceleration, not, e.g., when flying an aeroplane.

Note that @ferram4 and @dkavolis confirm that FAR (and FAR continued) correctly applies forces and torques (via Part.Add(Torque|Force[AtPosition]), so the discrepancy in angular momentum is not due to FAR applying a torque via some nonconformant path for which we would not account.

@ferram4 suggests that this may be some minor error in, e.g., application points, getting amplified by FAR’s reentry forces being much greater than stock’s as well as physics warp making the Δt longer.

[scimas]

Actually this has happened to me without FAR (basically almost no mods) in JNSQ during an Mk1 capsule reentry (maybe without timewarp? don't remember), but only once. I will see if I can recreate it and report with reproduction steps.

[scimas]

It seems that any uncontrolled craft (ie without SAS or similar systems actively controlling attitude) start vibrating more and more throughout reentry. The more the initial deflection from perfect retrograde orientation, the more severe is the amplification. And timewarping does make it worse. You can activate one such attitude control system to bring it under control. But if you deactivate it, the amplifications start taking place again.

While trying to figure out reproduction steps I encountered a crash actually. The game simply crashed on a decouple event with principia's logs saying "time Append at xyz which is before fork time abc". Probably the same as #2507. The issue is marked resolved for next release, but I'm attaching the logs and save anyway in case they're of any use. decouple_crash.zip

[eggrobin]

I might have found a way to reproduce the issue with no FAR, no RO, and no physics warp: 2519.zip Launch, timewarp as soon as you leave the atmosphere, and watch the reentry (the parachutes are inoperant, but their casings affect the trajectory of the rocket).

[pleroy]

We've found that, in addition to the save above, a simple 2-part vessel in free rotation with no forces applied does exhibit an instability with Principia, even though it is stable in stock.

By investigating this simple case we have been able to eliminate the possibility of gross programming errors (misinterpretation of KSP data, wrong timing, incorrect reference frame change, etc.).

So we now believe that the software is correctly implemented, but the way that we correct angular momentum (by adjusting the angular velocity of the vessel) is faulty, confuses the PhysX integrator, and leads to oscillations. We are looking into the possibility of correcting the angular momentum by tweaking the orientation of the vessel, in the hope that this won't negatively affect PhysX.

[pleroy]

As described in #2533, we have a change that works satisfactorily in space and improves the situation in the atmosphere. This will be in Fubini and we'll see if we still get reports of unflyable vessels.

[eggrobin]

Quoting @nepphhh in https://github.com/mockingbirdnest/Principia/pull/2533#issuecomment-616730775 to keep the discussion in one place:

Tested the binaries in KSP v1.8.1 in a mess of an RP-1 career/dev mod environment. Thanks to egg for providing them.

Results: https://gfycat.com/jubilantmeaslydartfrog

Report:

1. The mad spinning is no more.
2. There are some [new] strange wobbles, an intermediate-axis roll after burnout as you exit atmosphere. The onset of this effect is fairly defined, and it can be easily spotted at ~46 km in the video above.
3. There is the old mild roll on ascent. This has been tracked down to be PF's fault. To what extent it may also be responsible for point 2 is anybody's guess.

@nepphhh calls the behaviour described in 2. above « Fubini oscillations » which is a nice name.

[pleroy]

Кошмар Фубини

Here is my theory:

1. At the beginning (until approximately 14 s in the video) the rocket does not rotate on its axis. Therefore, we don't correct its angular momentum.
2. At 14 s it starts slowly rotating, first in one direction, then in the other, and it seems to rotate faster and faster until about 23 s. We still don't correct because we are in the neighbourhood of the singularity.
3. Finally at 23 s the angular velocity becomes large enough that we decide to correct the angular momentum. Now we have observed that the PhysX angular momentum has the right magnitude but dances a bit around our true value. The correction that we do changes slightly the orientation of the vessel to realign the PhysX angular momentum, but it keeps dancing and we end up chasing it. Note that the wobble has roughly the same frequency as the rotation of the rocket on its axis (it's always the same winglet pointing downwards) which would imply that α ≃ ω * Δt.

This is from staring at the video, not from any analysis based on facts.

[eggrobin]

@pleroy

we don't correct its angular momentum

We always correct the angular momentum (if we did not we would run into horrible discontinuities). I think you mean that we correct the angular momentum without changing the orientation of the vessel.

We still don't correct because we are in the neighbourhood of the singularity. the angular velocity becomes large enough

The threshold isn’t really about the angular velocity being large so much as it is about the angular velocity being, in a sense, larger than the error. That said, for reasons not yet understood, the error tends to be larger in the presence of large aerodynamics forces, so it may be that earlier in the ascent, as forces are larger, we do not pass the bar for orientation corrections.

In any case, it is fairly easy to make a build that displays the traces now. Perhaps we should make one and give it to @nepphhh et al. (@lpgagnon has also made some interesting observations regarding the Fubini oscillations), so that they can give us videos that actually tell us what we are doing.

[lpgagnon]

My own observations with the Fubini test build; based on a fully guided moon-impact rocket, so fairly different conditions than nepphhh's:

• at lift-off using PVG, the roll program (spinning ~90 degrees to go for a polar orbit) is "jerky"; instead of a smooth roll, the rocket shakes itself into the right attitude. The motion is reminiscent of nepphhh's rocket around 23s

• once in orbit, the dry stage is used to spin up the TLI stage using RCS. Again, instead of a smooth rotation, jerky sideways movements get introduced; MJ SmartASS struggles a bit to keep pointed in the right direction. The jerkiness continues even after killing RCS.

• stages are then separated; at this point, the spinning dry stage is still a bit jerky, possibly less than before. The TLI stage appears to be spinning smoothly

Experimenting, what I found is that the jerkiness appears to be more pronounced with a higher-mass rocket. With a few tons added to the TLI stage, it continued to be jerky after decoupling; removing the extra mass with hyperedit (down to ~300kg) reduced jerkiness to apparent nothing.

Finally, I tried reverting to Frobenius; none of these effects were visible. They returned after going back to Fubini.

[edit: extra observation: the jerkiness while free-spinning in orbit stops when entering (non-physical) timewarp; resumes when coming back to 1x]

[edit 2: videos] https://discordapp.com/channels/319857228905447436/480397772248580098/702994549806465202

[pleroy]

In any case, it is fairly easy to make a build that displays the traces now. Perhaps we should make one and give it to @nepphhh et al. (@lpgagnon has also made some interesting observations regarding the Fubini oscillations), so that they can give us videos that actually tell us what we are doing.

At this point I think I would prefer to get Mathematica traces. They would tell us much more than eyeballing videos. They would also make life easier for our guinea pig users, as uploading a (big) file is probably less hassle than making videos.

Unfortunately we know that our Mathematica traces are not ready for prime time so it's going to take me a bit of work to make them robust. Probably worth the investment given the situation with this bug.

Of course, the best would be to reproduce these problems in the stock game...

[nepphhh]

This guinea pig is plenty happy recording videos. He does not, however, have any idea what a good stock vessel for duplicating these problems would be. Did I see above that a 2-part test article was developed? If I could get the details on how to build & test it, I can put it through its paces.

If these traces are helpful & can be displayed on-screen during the flight screen, I can record a video with them pulled up (and legible) & dump the logs post-flight. Reach out if I can help.

[eggrobin]

I have reproduced the Fubini oscillations in stock. Fubini oscillator.zip

[garnet420]

Unsolicited suggestion: since this is, in a sense, wrapping a control loop around the PhysX integrator, have you considered adding a gain (less than 1) to the angular velocity correction, rather than turning it off entirely? The potential limitation of that is that the region of stability may not always be the same.

[eggrobin]

@lpgagnon, @nepphhh can you test whether this build fixes the Fubini oscillations, and whether any new and exciting side effects appear? principia test2550 for 1.9.1.zip

[pleroy]

@garnet420: When I saw your comment, I was in the process of writing a PID because, as you point out, this is looking more and more like a control theory problem. Early results are encouraging, but we'll need to get more mileage to know for sure.

[lpgagnon]

repeating from discord: with test2550, I'm no longer seeing any misbehavior in my 'in orbit' test case. The issue during liftoff roll program is still happening; it might be less 'sudden jerks' and more 'oscillation' than it was, but hard to be sure.

[nepphhh]

Fubini oscillations still present. Interesting new effects in my test flights (n=2): less "new and exciting source of angular momentum" and more "let's move back and forth sharply between two well-defined attitudes".

https://gfycat.com/impassionedincompatiblefunnelweaverspider

This recording of the second test flight doesn't demonstrate that new behavior as well as the unrecorded first test flight did. However, once the Fubini effect kicks in shortly after burnout, you can see, briefly, this switching between orientations, where it stops at one of the two terminal orientations, pauses, and then moves back to the next one with apparently very high if not instantaneous angular acceleration between each phase of the reorient-pause-reorient-pause-repeat process.

[pleroy]

@nepphhh: At the beginning of the video the rocket looks like it moves left and right, but there is hardly any motion on the navball. Do you understand why? Is this an effect of the camera moving?

Also, at the end of the video the rocket looks like it start precessing, but the video cuts too early and one is left wondering what happens next :)

[lpgagnon]

New video, a variation on the same issue. Seems to behave the same with fubini and the test build; doesn't happen with frobenius

https://discord.com/channels/319857228905447436/480397772248580098/708295984257433611

[pleroy]

@lpgagnon @nepphhh Please test this version in the atmosphere. You can compare the test2550 and the test2561 behaviours by checking (test2550) or unchecking (test2561) the Fubini orientation correction checkbox in the KSP Features section of the UI.

principia test2561 for 1.9.1.zip

[lpgagnon]

With the roll-program test case: not seeing a difference between 2561 and 2550 modes. In both cases the effect is definitely smoother than in the video I linked, but still pronounced.

fwiw, I tried other permutations of the other checkboxes (correct orientation, correct angular velocity); turning off Correct Orientation brings back "correct" (pre-fubini) behaviour.

[lpgagnon]

With 2561, I've been unable to replicate the magic-cube behaviour, with or without 'Fubini orientation correction' checked.

I went back to 2550 to make sure, and I still see it there.

[eggrobin]

With 2561, I've been unable to replicate the magic-cube behaviour, with or without 'Fubini orientation correction' checked. I went back to 2550 to make sure, and I still see it there.

O_o

fwiw, I tried other permutations of the other checkboxes (correct orientation, correct angular velocity); turning off Correct Orientation brings back "correct" (pre-fubini) behaviour.

Yeah, the combinations are:

Stock behaviour

• [ ] correct orientation
• [ ] correct angular velocity
• (third setting irrelevant)

  Frobenius behaviour (+PID)

• [ ] correct orientation
• [x] correct angular velocity
• (third setting irrelevant)

  Test2550, Fubini + PID

• [x] correct orientation
• [x] correct angular velocity
• [x] Fubini orientation

  Test2561

• [x] correct orientation
• [x] correct angular velocity
• [ ] Fubini orientation

Absurd

• [x] correct orientation
• [ ] correct angular velocity
• (either value of the third setting is absurd, but they will lead to different behaviour)

[lpgagnon]

Still playing in 2550, I've hit a case that produces the bouncy CoM even in vacuum: start a krash sim (so the vessel starts with absolutely no rotation), give it a touch of W rcs so it slowly spins along exactly one axis, then decouple it.

Reproduced several times in a row; in one case, the effect was violent enough to destroy the cube, with F3 window indicating 74G.

It's possible the reason I couldn't reproduce with 2561 is that the cube was spinning "wrong" by dumb luck. will try it again.

[edit] This is reliably reproducible without krash, using Hack Gravity to set up the initial 'no rotation' state. Still can't trigger it with 2561, but 100% reproducible with 2550. So maybe we can call this one fixed. video for posterity: https://discord.com/channels/319857228905447436/480397772248580098/708750794006200422

[eggrobin]

Another report (using the test2561 build) from discord: https://discord.com/channels/319857228905447436/480397772248580098/708731970103804005

[eggrobin]

Roll-induced aberrant nutation (compare with warp for physically correct behaviour), stock, freely spinning in space. Sadly this means we cannot (yet) mitigate this by disabling it in the atmosphere. On the other hand, this is reproducible, and feels a lot like the roll programme issues of @lpgagnon while being in a simple setting (free-spinning in space), so maybe we can make progress. strange spin in space.zip

[lpgagnon]

New test case: stock install, only Squad and Principia folders in GameData. Minimal vessel, command/tank/engine. With frobenius, vessel launched straight up can roll on its axis and still fly straight; with Fubini or 2561, it quickly picks up a wobble SAS struggles to compensate.

Demo: https://discord.com/channels/319857228905447436/480397772248580098/708760491509415978

Save folder, with vessel on the pad: https://drive.google.com/open?id=1wDxc9Amk1HB3GWAqLJuSz14WrgJLT84g

Usage: Go to vessel. T to activate SAS. Spacebar to launch. Set SAS to prograde mode. Start rotating with E. Wobble should become evident after a few seconds (~200m/s). Try keeping E pressed for a long time, or try releasing it every few seconds to give SAS time to recover. (on frobenius, a small precession starts happening after a long time keeping E pressed, once a very fast rotation has been reached; nothing comparable to fubini behavior)

[pleroy]

After long hours of experimentation with the above saves we came to the inescapable conclusion:

PhysX is crap.

We used Mathematica to plot the angular velocity coming directly from the game. Unity doesn't do a great job at documenting in which reference frame the angular velocity is expressed, but there are only two possibilities: in world, or in the frame of the part. In the former case the angular velocity should trace a curve in a plane, in the latter case a closed curve at the intersection of two ellipsoids. (The interested reader can look at the definition of the polhode and the herpolhode in Wikipedia in French, German or Spanish; the English article is lame.)

It turns out that the angular velocity doesn't do that. So we tested the simplest possible "vessel" that exhibits an interesting rotational motion, viz., a single part 6 BC15AC5 roverBody.v2, which is shaped like a book. Rotating this part along its second axis of inertia should exhibit the Джанибеков effect (demonstration with a Russian-English dictionary). Turns out it doesn't. It rotates in the most boring fashion. Mathematica traces show that the angular velocity is in fact held constant. This is not how physics works in this universe. Looking at the source code for PhysX, it's pretty clear that they are, in fact, not even trying to solve Euler's equations.

For the purpose of this issue, it means that we got things completely wrong: we expected PhysX to simulate rotational motion reasonably correctly, if inaccurately, and that Principia would perform incremental adjustments. After all, this is what we do for N-body gravity, and it works fine.

Instead, we need to completely replace the computations done by PhysX at each frame.

[eggrobin]

In light of this, the way forward is clear: we must use the Euler solver to propagate the orientation and angular velocity of the pile up, assuming rigidity, when it is freely rotating, and somehow incorporate the torques (and deformations) therein.

This will, in particular, have the effect of making timewarp equivalent to non-timewarp as long as the vessel remains rigid and free of torque. This is a satisfying property.

That somehow is the subject of this comment.

We might naïvely think that applying the forces should apply constantly over the duration of the Unity physics frame (this could then be integrated with a suitable splitting). However, there are multiple interpretations of constantly here:

1. body-fixed point of application, body-fixed force, e.g., thrusters mounted on the rocket;
2. nonrotating point of application, nonrotating force, e.g., a body being spun between two rollers;
3. body-fixed point of application, nonrotating force, e.g., a body being being spun up by pulling on two strings affixed to it.

These choices, and their applicability to different physical situations, hint at the fact that this approach consists in an attempt to model the forces. This cannot work; we do not know whether a force comes from an engine or from FAR, and we certainly do not know how the forces from FAR would evolve as the body rotates.

Instead we must consider the game logic as one half of a splitting method: the game alters L (by applying torques) in a way that depends on the attitude and angular velocity; we then alter the attitude and angular velocity by solving Euler’s equation, given the new angular momentum (and probably the new moment of inertia as well).

Besides these theoretical considerations, the results speak for themselves. Here are the angular velocities during test reentries of the 2519 save linked earlier (quicksaved from space for reproducibility), with various schemes of force application; for those that require integration of Euler’s equation under torque, a Newton-Delambre-Størmer-Verlet-Leapfrog splitting with an overkill 200 ms timestep (100 steps per physics frame) was used, ensuring that integration errors are not a concern.

Note that all schemes are equivalent when the vessel rotates slowly, as they differ only in that the effect gets spread out, and varies differently, as the vessel rotates. Note also that even when they are equivalent, all schemes quickly differ from stock. This is expected, as

PhysX is crap.

While this means that we should not expect to reproduce stock behaviour, we can clearly see that some options lead to aberrant behaviour. In particular, model (2.) above, in yellow on the graph, leads to spin-up (in roll) reaching 500 revolutions per minute (!) when the forces of reentry are at their strongest; this phenomenon is the one described in the title of this issue, as the Frobenius correction, while convoluted, was roughly equivalent to this kind of modelling.

The purple curve, which consists in treating the (game logic, Principia pile up) pair as as splitting method, exhibits fairly reasonable behaviour; the vessel reaches a roll rate between 20 and 30 rpm, which remains roughly stable, but gradually slows down under the influence of the atmosphere as the vessel descends.

Rockets spinning up during uncontrolled reentry is expected behaviour, exemplified, e.g., by the first Falcon 9 v1.1 reentry.

Note: these graphs were produced using the traces in https://github.com/eggrobin/Principia/commit/f73a0bb1b1787b02dfd8aa6bdde75ba333cde8b0, and with the following Mathematica code:

<<"2519 traces\\f73a0bb1b\\pile_up16";
stockω=angularVelocity;
<<"2519 traces\\f73a0bb1b\\pile_up36";
instantInitialForcesω=angularVelocity;
<<"2519 traces\\f73a0bb1b\\pile_up54";
nonRotatingForcesAndApplicationPointsω=angularVelocity;
<<"2519 traces\\f73a0bb1b\\pile_up72";
nonRotatingForcesBodyFixedApplicationPointsω=angularVelocity;
<<"2519 traces\\f73a0bb1b\\pile_up90";
bodyFixedForcesAndApplicationPointsω=angularVelocity;
Column@{#[[1]],Row@{#[[2]],#[[3]]}}&@Table[
With[
{f=parameter[[1]],
name=parameter[[2]],
big=parameter[[3]]},
ListLogPlot[
{f/@stockω,
f/@nonRotatingForcesAndApplicationPointsω,
f/@bodyFixedForcesAndApplicationPointsω,
f/@nonRotatingForcesBodyFixedApplicationPointsω,
f/@instantInitialForcesω},
ImageSize->If[big,1000,500],PlotRange->{{0,90},{0.1,500}},
GridLines->{None,Flatten[Range[#,9#,#]&/@(10^Range[-1,2])]},
Ticks->{Automatic,Flatten[Range[#,If[big,7,2]#,#]&/@(10.^Range[-1,2])]},
Joined->True,
PlotLegends->If[big,{
"stock",
"non-rotating forces and application points",
"body-fixed forces and application points",
"non-rotating forces, body-fixed application points",
"instant initial forces"},
None],
AxesLabel->{"time (s)", name<>" (rpm)"}]],
{parameter,{
{{60#[[1]]-3643,Norm[#[[2]]]}&,"angular frequency",True},
{{60#[[1]]-3643,Norm[#[[2,1]]]}&,"roll rate",False},
{{60#[[1]]-3643,Norm[#[[2,2;;]]]}&,"pitch & yaw rate",False}}}]

[pleroy]

@lpgagnon @nepphhh Please test this version both in space and in the atmosphere. We believe that it fixes the issue once and for all.

principia test2574 for 1.9.1.zip

[eggrobin]

we must use the Euler solver to propagate the orientation and angular velocity of the pile up, assuming rigidity, when it is freely rotating, and somehow incorporate the torques (and deformations) therein.

Emphasis added.

This comment is about the somehow of the deformations.

If we were the physics engine, things would be straightforward: one half of the splitting would be interaction torques & forces between rigid parts, and the other half would be free rigid body motion of the parts. We are not, cannot be, and do not want to be in the business of replacing the bulk of the physics engine; there is no realistic way for us to deal with joints, collisions, etc. Further, regardless of the physics engine, the general principle of the pile up is that it is a higher-level construct: it is aware of properties of the physical system (isolation between vessels, and net changes to their linear and angular momenta) that are not visible at the lower level of a physics engine.

We must therefore deal the fact that the pile up is a nonrigid body. As a result, its principal axes can move arbitrarily (even discontinuously) within it; assuming that the orientation of the principal axes continuously follows Euler’s equation from one step to the next leads to flips and aberrant nonremovable rotation when the vessel is nearly symmetrical.

Ideally, we would deal with the whole problem cleanly as a splitting into:

1. the rigid motion of the whole pile up;
2. net torques and forces from KSP via the FlightIntegrator census;
3. internal dynamics from PhysX (note that the issues of PhysX’s handling of rigid body motion would still be present therein, but they should matter less within the narrow range of internal motion of the components of a spacecraft).

A way of looking at the separation between 1. and 3. is to see 1. as the definition of a reference frame (whose instantaneous motion is that of a rigid body with the same inertia and angular momentum as the whole, and whose axes are whatever they need to be to satisfy continuity), and 3. as physics in that rotating reference frame.

However, getting PhysX to deal only in 3. is tricky: the FlightIntegrator has applied 2. to it, and as the whole actually has a net rotation, it does 1. as well (albeit rather poorly). If we wanted to go that way, we would have to, immediately prior to the physics step, change the angular velocities of all parts of the pile up to the ones in the rotating pile up frame defined by 1., and apply the corresponding apparent forces (as well as some manner of rigid compensation torques and forces for 2., so that it does not result in net rotation; I am not quite sure how that part should work). Any change in orientation of the parts would then be a pure result of the internal dynamics, and we could happily apply that on top of our integration of 1.

Beyond the complexity and remaining unanswered questions pertaining to that preprocessing, this gets in the way of the lifecycle of the pile up: the pile up is defined by the collisions, and those are computed by the PhysX step; we would be relying on the pile up to perform the computation that defines it. We would probably also mess with inter-pile up collisions.

We might even run into issues should PhysX, once given parameters that should make it compute 3., compute out of them something that has a net rotation.

While not obviously infeasible, this would take a lot of design work, and a very long time.

Instead we choose to go with a cheesier approach, predicated on the assumption that, while flexible, vessels are not completely arbitrary. We assume that there will always be some part which is “sufficiently immobile” within the rigid body equivalent to the pile up (in practice we look for the part which rotates least with respect to the principal axes), and we use that part to define the attitude: its old orientation defines the old orientation of the new principal axes, the Euler solver advances, and this gives us our step of the splitting.

This will fail if every part of a vessel is significantly spinning with respect to the whole, e.g., if the vessel consists of two counter-rotating parts. Hopefully such vessel are niche enough that this approach will work for practical purposes.

On the (highly rigid) vessel from the 2519 save, things seem to work decently; it is noticeable (from the graphs, not in game) that the behaviour is less reproducible than it was when we used the principal axes, but it is very similar to the behaviour from my previous comment, and now things cylinders and other symmetrical rockets are not subject to haphazard absurd rotation, which is a marked improvement. Note that the reference part rotates within the vessel between 2 and 3 of magnitude slower than the vessel itself spins. The capsule and nosecone seem to be the most stable parts.

Graphs produced from the traces in eggrobin@e7d5d2f47, with the following Mathematica code:

<< "2519 traces\\f73a0bb1b\\pile_up36";
principalAxesω = angularVelocity;

<< "2519 traces\\e7d5d2f47\\pile_up16";
testω = angularVelocity;

parts = Union[First@*StringSplit@*Last /@ referencePart]

(partIndex[parts[[#]]] = #) & /@ Range[Length[parts]];

With[
 {f = {60 #[[1]] - 3643, Norm[#[[2]]]} &},
 Show[
  ListLogPlot[
   {f /@ principalAxesω,
    f /@ testω,
    {60 #[[1]] - 3643, #[[2]]} & /@ referencePartProperAngularvelocity,
    {60 #[[1]] - 3643, 
       10^(partIndex@First@StringSplit@#[[2]] - 3.9)} & /@ 
     referencePart},
   ImageSize -> 1000, PlotRange -> {{0, 3700 - 3643}, {0.001, 30}},
   GridLines -> {None, 
     Flatten[Range[#, 9 #, #] & /@ (10^Range[-3, 2])]},
   FrameTicks -> {
     {Flatten[Range[#, 7 #, #] & /@ (10.^Range[-3, 2])],
      {10^(# - 3.9), parts[[#]]} & /@ Range[Length[parts]]},
     Automatic},
   Joined -> {True, True, True, False},
   Frame -> True,
   PlotLegends -> {
     "attitude determined by principal axes",
     "attitude determined by slowest-rotating part",
     "internal rotation rate of reference part",
     "reference part"},
   PlotStyle -> PointSize[.0015],
   FrameLabel -> {{ "angular frequency (rpm)", 
      "reference part"}, {"time (s)", None}}]]]

[lpgagnon]

All 3 of my test cases appear fixed with 2574. Roll-program is smooth, vacuum free spin is smooth, magic cube doesn't shake itself apart. (all tested with the same .craft that previously had issues)

Can't vouch for the original frobenius spin issue, I never had a clear-cut test case for it. A couple of quick tests haven't shown any unusual spin.

[eggrobin]

Can't vouch for the original frobenius spin issue, I never had a clear-cut test case for it. A couple of quick tests haven't shown any unusual spin.

@nepphhh, @Myshiko, @scimas, you had encountered the original Frobenius issue, can you confirm that a reentry that was affected by the Frobenius spin behaves plausibly with the test2574 build from https://github.com/mockingbirdnest/Principia/issues/2519#issuecomment-629715006?

[eggrobin]

From discord:

\ I experienced something similar to neph's reentry spinup where my sounding rocket spun up to 3k rad/s; that is completely gone with the new test build

[nepphhh]

My test case performs perfectly with test2574 both on ascent and descent. Nice work!

[scimas]

My test case (just an extreme spin-up I had come across during gameplay, not a specifically created test case) still has the extreme spin up issue. The situation is a reentry from Minmus in JNSQ, no FAR. Note that the ship is not stable in the retrograde orientation with or without principia, but it shouldn't be spinning like this either. I'm attaching the save if you want to reproduce it on your end.

1. The quicksave will take you to a ship that will reenter atmosphere within 2-3 seconds.
2. You will need to use kOS or mechjeb to keep the ship stable (I'm using kOS: lock steering to srfretrograde.) or it will burn up long before the spin up issue can occur. Alternatively, turn on cheats for ignoring temperature.
3. Observe that there is no indication that kOS is struggling to hold the ship orientation.
4. After a few minutes surface frame speed will drop to ~2600 m/s at which point suddenly kOS won't be able to hold retrograde.
5. You can either tell kOS to stop trying (unlock steering.) or not, the end result is the same. A few parts explode due to overheating and the ship goes into an increasingly extreme spin. The chutes even break off due to the spinning.

Mods in the save apart from principia:

1. Better SRBs
2. Community Resource Pack
3. Contract Configurator
4. JNSQ
5. JX2Antenna
6. Kerbal Alarm Clock
7. Kopernicus Planetary System Modifier
8. kOS: Scriptable Autopilot System
9. Laser Dist
10. ModularFlightIntegrator
11. Module Manager
12. Rational Resources
13. SCANsat
14. Eve Engines

All except for Eve Engines can be installed using CKAN. Although I do not believe the ship in question is using any non-stock parts (other than kOS). reetry_spinup.zip Edit: I should clarify, it's KSP 1.8.1

[Myshiko]

Frobenius spin-up looks to be fixed with Principia build TEST2574. No major unexplained spin-ups in suborbital unguided rockets launches or reentries. Very minor induced rotations observed looks "physically correct" given many forces of various magnitudes affecting the system.

Fubini jerkiness also looks to be fixed : space planes (and planes in general) no longer experience sudden jerks and jumps in orientations. Verified with AtmosphereAutopilot, standard stock SAS and no SAS at all (in aerodynamically stable plane). All planes are now "smooth as android bottom", as they originally where. Most likely same will be true for the various accent guidance technologies (MechJeb and PVG).

Orientation looks to be preserved well during warp.

All tests done in RSS+RO+RP1+FAR, KSP 1.8.1. Deep space probes not tested yet.

Overall excellent work.

[pleroy]

@scimas: We have reproduced your issue and spent quite some time investigating it. After the ship explodes due to overheating, it is subject to such forces that it is no longer rigid: we see rotational speeds of 1°/s for the parts with respect to the overall vessel, which is quite large (typical rotational speeds would be 100 times smaller). As explained by @eggrobin in its latest (long) comment, the "cheesy" approach that we use to compensate for the shortcomings of PhysX depends on the ship being mostly rigid, so it fails here.

Frankly, I don't see us having a solution to that problem in the near future, so I guess it's a case of "if it hurts, don't do it".

[scimas]

I understand. That was the only issue I had remaining. I haven't encountered any new problems with either the test build posted in the comments or the Fuchs release. I had kept that quicksave around just as an extreme test case, it is not an ongoing problem for me. I'm fine with closing the issue.

[pleroy]

Closing as the only remaining problem is the one reported by @scimas, it is very uncommon, and we will probably never be able to fix it.

[eggrobin]

https://github.com/mockingbirdnest/Principia/issues/2519#issuecomment-628810018

Here are the angular velocities during test reentries of the 2519 save linked earlier (quicksaved from space for reproducibility)

I had forgotten to upload this quicksave. I believe it is one of these (which seem to be seconds apart both in game time and real time): quicksaves.zip.