Spin-up on reentry under physics warp with FAR #2519
Comments
|
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. |
|
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. |
|
I might have found a way to reproduce the issue with no FAR, no RO, and no physics warp: |
|
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. |
|
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. |
|
Quoting @nepphhh in #2533 (comment) to keep the discussion in one place:
@nepphhh calls the behaviour described in 2. above « Fubini oscillations » which is a nice name. |
|
Here is my theory:
This is from staring at the video, not from any analysis based on facts. |
We always correct the angular momentum (if we did not we would run into horrible discontinuities).
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. |
|
My own observations with the Fubini test build; based on a fully guided moon-impact rocket, so fairly different conditions than nepphhh's:
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 |
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... |
|
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. |
Random improvements and cleanups done while investigating #2519
|
I have reproduced the Fubini oscillations in stock. |
|
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. |
|
@lpgagnon, @nepphhh can you test whether this build fixes the Fubini oscillations, and whether any new and exciting side effects appear? |
|
@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. |
|
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. |
|
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. |
|
@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 :) |
|
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 |
|
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. |
|
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
Yeah, the combinations are: Stock behaviour
Frobenius behaviour (+PID)
Test2550, Fubini + PID
Test2561
Absurd
|
|
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 |
|
Another report (using the test2561 build) from discord: |
|
Roll-induced aberrant nutation (compare with warp for physically correct behaviour), stock, freely spinning in space. |
|
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: 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. |
|
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 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. |
|
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).
These choices, and their applicability to different physical situations, hint at the fact that this approach consists in an attempt to model the forces. 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.
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.
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 eggrobin@f73a0bb, 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}}}] |
|
@lpgagnon @nepphhh Please test this version both in space and in the atmosphere. We believe that it fixes the issue once and for all. |
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:
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 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 Graphs produced from the traces in eggrobin/Principia@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}}]]] |
|
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. |
@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 #2519 (comment)? |
|
From discord:
|
|
My test case performs perfectly with test2574 both on ascent and descent. Nice work! |
|
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.
Mods in the save apart from principia:
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). |
|
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. |
|
@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". |
|
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. |
|
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. |
Remove rotation traces related to #2519
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. |
@nepphhh reported this issue, illustrated by the following video.
https://www.youtube.com/watch?v=dNHiZsGIurg
Some notes from experiments by @nepphhh:
@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.
The text was updated successfully, but these errors were encountered: