KSP 1.0.5 Apoapsis and Periapsis Changing when Pitching Spacecraft

[kysam2]

My apoapsis and periapsis are changing when I turn spacecraft. Any help would be appreciated!!!

[Evanitis]

That's kinda' normal. RCS thrusters or reaction wheels apply force to the spacecraft, and any force modifies your orbit.

[radonek]

Rotational force should not affect you orbit. Also, my orbits tend to change even when ship is completely passive. Most of the time it just drifts a bit up and down, but some orbits are particularly unstable. Low Mun orbit for one - I frequently use 10-12km parking orbit for phasing to station higher up and I can attest it is actually impossible to keep anything there without timewarp. Effect disappears when on rails. I had one case when I left ship there and went away for about 20 minutes and when I got back it was falling onto surface…

It is probably product of floating point calculations inaccuracy.

[MrWolf83]

I had this same issue last night and went back into ship view, and realized I had three reaction wheels on ship and shut off all but one, problem solved.

[Zhetaan]

It's floating-point inaccuracy, and also I recall that KSP calculates off-rails apses based on the root part, rather than the centre of mass.  Since it's rare for the root part to be at the centre of mass, rotation (which is based on the centre of mass) changes the root part's position with respect to the orbit, thereby changing the calculated orbit.

It would be difficult to test whether they've addressed that because using a single command pod, for example, wouldn't eliminate the floating-point problem.  Maybe a command pod on one end of a long rotating boom with a couple of full Kerbodyne tanks at the other would do the trick?

Edited February 22, 2016 by Zhetaan

[sal_vager]

Floating point inaccuracy is a part of it, the major reason however is the limitation of numeric integration.

Your Apoapsis and Periapsis are not numbers held in a variable, they are recalculated every physics frame.

And there's a lot of factors involved, you are not the center of the game universe, though you're never too far from it thanks to the Krakensbane fix.

So the calculation has to use your angle and magnitude (distance) from the 0,0,0 origin point in the scene, your crafts direction of travel and speed, as well as any acceleration that may be applied.

And it has to take into account the angle and distance of the body your orbit is relative to, the difference between them and apply gravity on your craft, this changes your crafts direction (vector) and speed.

With these KSP can start calculating the various orbital elements, and find your Apoapsis and Periapsis.

On the next physics tick it does all this again.

But because of numeric integration the results are slightly different each time.

[John FX]

One thing to remember is that your cabin or core is often not at the centre of mass of your craft so when you rotate it moves around the centre of mass meaning it will appear to be moving faster or slower than your craft is actually going which will give it a different Ap and Pe.

This is why, when you rotate, your Ap and Pe change but return back to more accurate numbers when you stop rotating without having to resort to blaming floating point issues.

Technically it`s a bug because the Ap and Pe should be taken from the movement of the centre of mass of your craft but instead it seem plain that it is taken from the movement of your probe core or cabin leading to inaccuracy when they are not at the centre of rotation for your whole craft..

[StarManta]

3 hours ago, sal_vager said:

Floating point inaccuracy is a part of it, the major reason however is the limitation of numeric integration.

 

Those two things are part of it, but not all of it. There's no way simple arbitrary math error - whether due to FP inaccuracy or something more mathematically fundamental - accounts for all observed movements of faraway nodes. Those would lead only to random-looking "jitter". And yes, we see that. But there are also more predictable inaccuracies when rotational force is being applied to the craft, especially in faraway nodes that are especially sensitive to small changes, such as interplanetary captures. I have  taken advantage of this to fine-tine encounters spending no fuel on occasion - because it's predictable, I could hold the rotation keys to "force" the path towards one direction or another, and it would sort of oscillate as the craft rotated with the button held down. By entering timewarp at the most desirable point in the oscillation (zeroing out rotation immediately), then repeating the process, I could achieve some significant changes using only reaction wheels. The path generally "bounces" back after the key is released, indication it's the rotational force causing the error and not the rotation itself.

I think @Zhetaan is on the right track with it being a discrepancy between the CoM and the root part. I've noticed this most often on big vessels - when rotating, it's easy to see how the root part (at the front of the ship) would have a different world velocity than the CoM when rotating. If the patched conics are using the root part's world velocity to calculate the trajectory, this would align with what I've seen of this issue.

[radonek]

3 hours ago, sal_vager said:

…On the next physics tick it does all this again…

Which is what bugs me. If ship is outside atmosphere and all engines are off, it could be effectively "on rails". AFAIK this is why timewarping mitigates this problem.

[sal_vager]

Other craft are, but your craft could change its orientation at any time, you can go to warp and be put on rails but then you have no control.

Players often think it'd be fine to have the ship on rails when it's not receiving input but there can be a big jump in apoapsis when coming off rails, much more than being in physics time all the time.

Your orbits would be massively more jumpy if you were going on and off rails with every movement.

[radonek]

18 hours ago, sal_vager said:

Other craft are, but your craft could change its orientation at any time, you can go to warp and be put on rails but then you have no control.

Players often think it'd be fine to have the ship on rails when it's not receiving input but there can be a big jump in apoapsis when coming off rails, much more than being in physics time all the time.

Your orbits would be massively more jumpy if you were going on and off rails with every movement.

Thanks for clarifying that one Sal. I knew there would be simple reason, but could not think of one. Silly of me, now I remeber Harvester mentioning it in devnotes once.

[kysam2]

Thank you all for the info, but this still doesn't fix the problem. It's really not when I' min Kerbin orbit that's annoying, but when I have a interception with a perhaps is of another planet and moving around changes that by many kilometers, which makes aerobraking quite difficult.

[FullMetalMachinist]

6 minutes ago, kysam2 said:

Thank you all for the info, but this still doesn't fix the problem. It's really not when I' min Kerbin orbit that's annoying, but when I have a interception with a perhaps is of another planet and moving around changes that by many kilometers, which makes aerobraking quite difficult.

I'm afraid that there really isn't a "fix" for this. As those above have said, it comes from the way that KSP calculates your obits while in different situations. 

As for interplanetary trips, you can minimize the errors in your obit pretty easily. Just get your encounter "good enough" while in Kerbin's SOI, then when you're about halfway to the destination planet, do a minor correction burn. Then right when you enter the destination planet's SOI you should be going (relatively) slowly, and you can do a final correction burn for minimal dV.