Interplanetary transfers: add UP to all bodies using the same reference frame

[baloan]

Feature

The key challenge for Hohmann burns to other bodies is to find the right angle for planetary alignment and for the hyperbolic escape burn. Finding correct angles is possible with adding:

Body:UP
Body:VELOCITY 

to all bodies in the same reference frame. UP should point away from the Body:BODY, i.e. the SOI body (Sun for Kerbin; Kerbin for Mun & Minmus). I can't imagine any use for the roll parameter though. Velocity points in the direction of Kerbin moving around the sun relative to the sun.

What is it good for?

1. Calculation of the angular difference between two bodies shall be possible using:

D = Kerbin:UP - Duna:UP
A = D:ANGLE

I'd consider ANGLE optional. It makes sense for highly inclined orbits, otherwise we can use D:pitch or D:yaw with small errors. So A describes the angle between Kerbin and Duna as seen from the Sun. The angle can be used to check of the planets' proper alignment for the transfer orbit injection - or how long to wait for it.

1. UP and VELOCITY will also be used to determine the direction for interplanetary burns to outer planets (PROGRADE where VELOCITY points) or inner planets (RETROGRADE opposite to VELOCITY). UP then allows to calculate the exact position where to begin the hyperbolic escape burn so that SHIP:PROGRADE aligns with Kerbin:VELOCITY after the burn.

[Dunbaratu]

This would be useful.

Please, in NO way take what I'm about to say as meaning we don't need this. I think we do. But in the meantime, this may help you until it becomes available:

I managed to find a way to do it with what's there now but it's really ugly. You can work it out with dot products and some of the vector transforms stuff I put on the community wiki.

The nutshell is this:

1. Transform your own UP direction into an UP unit vector using tfDirToUnitV from the community wiki.
2. Planetary bodies have a position vector from zero available: BODY:POSITION.
3. The dot product of your UP vector and the body position can be used to derive the angle between you and the target body from the property that (dot product)=cos(A)_mag1_mag2 (Solve for A to get the angle between you and the target body).

That gets you the angle between you and the target body, but not it's sign. (If you are 40 degrees ahead of it, or 40 degrees behind it,you will get "40" either way.) Getting the sign involves more vector dot product trickery to decide if your velocity is toward-ish the target or away-ish from the target.

I managed to accurately work out the right location for a Hohmann transfer this way. I'm testing it out in my entry for Thrfoot's contest on the forums, but hopefully the above can give you enough of a hint for how to do it. Good luck.

[baloan]

I agree with that BODY:POSITION vectors relative to the Sun are as good as UP (same direction). From looking at the POSITIONs of Kerbin, Mun, Sun at first glance I'd suspect my ship is at POSITION(0,0,0). Once you move the origin into the Sun it should be relatively easy. I need to sit down and write down some vectors in order to figure it out.

While being useful I agree the UP vectors are not essential to solve the problem. So nothing to be implemented immediately. ;-)

Btw, I never figured where R(0,0,0) points. Any idea?

[Dunbaratu]

I think R(0,0,0) is along the Z axis of the XYZ system. I had to do a lot of experimentation to make tfDirToUnitV work and trial and error to figure out, for example, which axis is being rotated first, as that changes everything and leads to different values in the rotation matrix. I vaguely remember that I could only make it work right if my initial starting unit vector was V(0,0,1) before I began applying rotations to it, which would seem to indicate that R(0,0,0) is the same thing as V(0,0,1).

[baloan]

Unfortunately KSP changes reference frames when crossing 100km altitude. Below 100km the planetary coordinate system seems to be the basis, above 100km the Kerbin-Mun system (?). I can detect this when calculating the positions and velocities for ship and mun.

set pm0 to mun:position - kerbin:position.
set ps0 to V(0,0,0) - kerbin:position.
wait 1
set pm1 to mun:position - kerbin:position.
set ps1 to V(0,0,0) - kerbin:position.
set vmum to pm1 - pm0.
set vship to ps1 - ps0.

If I put my ship into an elliptic orbit with apoapsis at 150km and periapsis at 80km I observe jumps in velocities - and Mun actually changes its sense of direction in orbit (running clockwise instead of counterclockwise). This is (without having confirmed by calculation) due to the rotation of Kerbin which adds angular velocity between the frames of reference. Although possible to treat computationally it is high effort, error-prone. It is not possible to handle this without feeding the 100km frame transition as an script-defined variable which feels like introducing a hack. There is also the problem of inconsistencies (altitude queried below 100km, position above 100km) when crossing the boundary. Thus there is still a case for the UP vectors in the same frame of reference (the Sun).