Rotation-Trajectory Interaction Bug

[M3Henry]

Seeing as Kerbal Ships are a set of masses on semi-rigid joints, the following applies quite specifically to our case:

Quote

A set of masses connected by springs will follow a path such that its center of mass moves along the same path that a point mass of the same total mass would follow under the influence of the same net force.

- http://hyperphysics.phy-astr.gsu.edu/hbase/mechanics/n2ext.html

However the predicted trajectory of a craft seems to change when the craft is rotating.

When around Gilly, this effect is pronounced enough to show an escape trajectory where there is none. Note how the prograde and retrograde aligment functions are unable to align due to fluctuating orbital patterns. I used a probe where the probe core is far from the CoM to further amplify the effect. So I believe that the predicted trajectory is not showing the Center of Mass trajectory, but instead it shows the probe core's current trajectory if it were not attached to anything else.

The game even thinks that the ship is under acceleration while it is rotating.

[Nich]

You have too big of reaction wheel for that tiny ship and yes I am sick of it throwing off my PE on transfers.  Oh well free kraken corrections

[suicidejunkie]

I wouldn't call it a bug, as I suspect it is working as expected.

The course based on the control point is quite useful in many cases.  For example, when you are docking and you 'control from here', the important bit is the motion of your docking port (relative to the other docking port) and CoM motion isn't really important.

 

For the situation you are looking at specifically?  You can use it to accurately fling payloads using an electrical launch system

• 1) Have a station with a heavy central mass and a long arm with a claw or docking port.  Use stretchy battery strings for more fun.
• 2) Set an action group to release the claw/port.
• 3) Dock a payload, and spin up the station.  Set 'control from here' on the payload.
• 4) Watch the map view to see when your payload's trajectory is at the desired parameters.
• 5) Press the release button and fling your payload on its way with free dV.

If you have a fuel depot and assemble a 1km long truss with the claw at the end, and then spin it up to 10rpm, that's 1km/s tangential speed (if I did the math right) and you can fling things from LKO onto escape trajectories using your gyros.  (plus some occasional re-boosting of the station to keep it out of the atmosphere)

Trade off the long truss for higher spin rates as desired.

[Nich]

 Ha ha oh my god that is awesome I am so trying that 

[John FX]

Yeah, I pointed this out earlier in another thread.

Having your trajectory calculated from the centre of mass would lead to more stable orbits being shown in the map.

It would require what I suspect to be very small changes in the code as the centre of mass is already calculated AFAIK.

[Sir_Robert]

This is because, while rotating the ship, your COM moves around (your ship rotates around the root, not the COM)

An extreme example is here:

 

[cfds]

To give all possible SQUAD answers:

"It is a Unity problem."

"It is working as intended."

"Here, have another jet engine."

[M3Henry]

3 hours ago, Sir_Robert said:

An extreme example is here:

I do remember this video.

While I agree that this can be useful for predicting flinging things, it is not the behiavour that orbital trajectories would be expected to exhibit.

The fact that it breaks autopilot when tangenital velocity is not negligible in comparison to the oribtal velocity is definitely a bug.

I would suggest that physical trajectories are always taken from CoM, and that displayed trajectiories can be shown from CoM trajectory command point instantanous trajectory as a toggle.

[Nukeknockout]

On 2/26/2016 at 0:56 PM, suicidejunkie said:

I wouldn't call it a bug, as I suspect it is working as expected.

The course based on the control point is quite useful in many cases.  For example, when you are docking and you 'control from here', the important bit is the motion of your docking port (relative to the other docking port) and CoM motion isn't really important.

 

For the situation you are looking at specifically?  You can use it to accurately fling payloads using an electrical launch system

• 1) Have a station with a heavy central mass and a long arm with a claw or docking port.  Use stretchy battery strings for more fun.
• 2) Set an action group to release the claw/port.
• 3) Dock a payload, and spin up the station.  Set 'control from here' on the payload.
• 4) Watch the map view to see when your payload's trajectory is at the desired parameters.
• 5) Press the release button and fling your payload on its way with free dV.

If you have a fuel depot and assemble a 1km long truss with the claw at the end, and then spin it up to 10rpm, that's 1km/s tangential speed (if I did the math right) and you can fling things from LKO onto escape trajectories using your gyros.  (plus some occasional re-boosting of the station to keep it out of the atmosphere)

Trade off the long truss for higher spin rates as desired.

BRB, constructing Kerbal Fling Beacon #1. Also, first reason I've had to research the Klaw.

[NathanKell]

I actually did (try to) fix this in 1.0.5, but evidently not quite enough.

[Sir_Robert]

1 hour ago, NathanKell said:

I actually did (try to) fix this in 1.0.5, but evidently not quite enough.

Well it's good to know you're working on it

[KerikBalm]

On 2/27/2016 at 4:18 PM, Sir_Robert said:

This is because, while rotating the ship, your COM moves around (your ship rotates around the root, not the COM)

An extreme example is here:

 

That's not an accurate description of what is going on there.

Your ship does rotate around the CoM - because it calculates the mass and momentum of each part as they move.

The thing is that when you transfer fuel, the mass and momentum of the fuel is not conserved. One part just gains mass while another loses mass. The CoM of your craft shifts, while the position of each part does not shift one iota as a result of the fuel transfer.

[AgentRev]

On 2016-02-28 at 1:05 PM, NathanKell said:

I actually did (try to) fix this in 1.0.5, but evidently not quite enough.

AFAIK this has been plaguing KSP since forever, and it's quite surprising that it hasn't been fixed in such a long time. An absolute indicator proving this bug is still present is that the maneuver prograde (blue target) on the navball starts shaking violently when the maneuver dV is very close to 0, with a large ship that is prone to wobbling a bit.

The fix is as follows:

• Velocities and distances should be relative the CoM while in Staging View & map view, and relative to the controlled part while in Docking View
• Navball maneuver markers & orbit markers should always be relative the CoM, regardless of the view
• Navball rotation and target markers should always be relative to the controlled part, regardless of the view (as is currently)

If you are serious about fixing this bug, and have trouble understanding the above explanations, please do tell, I will be happy to go into further details as necessary.

[NathanKell]

@AgentRev the problem is that that is all true already. If it were that simple I'd have fixed it long ago.

[DuoDex]

5 minutes ago, NathanKell said:

@AgentRev the problem is that that is all true already. If it were that simple I'd have fixed it long ago.

Spoiler

Ladies and gentlemen, it is my great pleasure to present to you the biggest roast of 2016.

Seriously though, I think that @NathanKell and Squad in general quite understand the issue - after all, they're the ones that wrote the code!

[AgentRev]

@NathanKell

Okay, the issue is not as straightforward as I believed, but still, the problem has to do with the fact that velocities/trajectories are not using the same reference point as angular momentum, which should be the CoM.

I ran some tests with the following rig (the weird radial decoupler thing was just to rule out staging as a cause), and regardless of what I would do, velocities and trajectories were always calculated relative to the bottom lander pod. The vessel was rotating from its CoM, the controlled part was the middle pod, yet when I built up a decent amount of yaw momentum, I could clearly see the surface velocity varying according the bottom pod's movement; when the bottom pod was rotating in prograde direction, the surf vel increased, and when it was rotating in retrograde direction, the surf vel decreased. If I removed the top and bottom pods, then the velocity was roughly relative to the bottommost girder segment that was right above the bottom pod... And, as expected, if I removed everything but the middle pod, then all worked fine and the surf vel didn't change on rotation.

So, there's definitely something wacky happening here. The velocities roughly appear to be relative to either the bottommost or outermost part, regardless of any other variable.

Edited March 14, 2016 by AgentRev