I can't understand the coordinate system: why am I moving vertically when on ground?

[Dunbaratu]

No. You know, in KSP physics are horrible complicated. As long as you are on the ground, the planet does not rotate and instead the entire universe including sun flies around the planet, just like Christians would have loved it^^

Afaik the reason is similar to the krakensbane... a moving ground + still standing (but for the physics sys also moving) obj can create problems for the physics engine so not rotating physics makes sense once your get close to the surface. The planet Kerbin actually starts "rotating" exactly at 100km.

So am I to understand that below 100km the surface velocity is "native" and the orbital one is derived, whereas above 100 km they swap and the orbital velocity is native and the surface one is calculated?

But still, whats the problem? You need an "Up in the sky" vector? Well, the coordinates systems origin should be the center of the planet, so all you have to do is normalize your position vector and your fine. If your velocity is not pointing in the same direction that means your not going to space today

I can work with the system if I know what it actually IS. It was trying to decipher what it is from only being able to see velocity vectors and having to guess that was the problem.

[Dunbaratu]

"So why do i have a velocity if the plant is not rotating?" your asking? KSP does calculate the "what would it be actually"-velocity, so you can use only this one and do not have to consider such stuff... usually^^

Year, its soooo complicated and coooooool (to quote southpark)

My problem is the other way around. The KOS plugin gives me the surface velocity in the form of a vector, and I'm trying to use that for landing purposes, but if I want to aim the craft by saying "a bit more north than" or "a bit more east than" the surface velocity vector then I needed to know in what coordinate space that vector was expressed so I can get the "upward" vector. The plugin does provide an upward directional ray, but it's expressed as Euler angles (complete with the gimbal lock problem and all that) instead of as something sane I can actually work with like all-axis matrix roations or quaternions or vectors.

[Gaius]

Well, I can't read your mind. That's true of what you *meant*, when clarified, but not what you *said*, which was that the coordinate system was universal space. It's not if it's centered on the SOI body.

It is if the SOI body defines the game universe. The other sense of "universal space" makes sense talking about the real universe, but doesn't really exist in the code. It's an abstraction we insert into the virtual reality in our own minds -- in reality, Kerbin doesn't actually rotate in universal space, the star-sphere rotates around it while you're in it's SOI. It's a "keocentric" model in the reality of the code (at least while you're in Kerbin's SOI). Tycho's answer to Copernicus' heresy, made virtual reality... but switch SOIs, and the universe changes...

Edited September 17, 2013 by Gaius

[BubbaWilkins]

Gaius,

The system works on the simplified rules relative to sol as the origin at all times. First it calculates the position of the planets relative to SOL to determine their path of travel at any given time. Then for each planet it calculates the crafts and moons, and then finally the crafts orbiting the moons. That origin can't shift as it complicates all positional computations resulting in a separate system for each SOI. That said, obviously the physics window works on a much more complicated set of factors.

Steve,

I think you're over thinking it. Go back to the beginning and look at what the command you are executing.

It's returning three instantaneous velocity magnitudes. Up/Down, North/South, East/West. This describes the path of travel of your COM relative to the source of gravity/origin in that SOI. Since these vectors do not curve, there must be a velocity in two directions to result in a curved path of travel. So at any altitude on an equatorial position, you will have only values in the Up/Down and East/West velocity vectors relative to Kerbin. On the planet, all other positions will result in lower orbital values the further you travel from the equator until you reach the poles at which point you will only have the DOWN value. If you have an exact Polar Orbit, than your values will reflect a North/South velocity and a zero East/West velocity.

OR...I'm completely smoking something.

Edited September 18, 2013 by BubbaWilkins

[Dunbaratu]

Steve,

I think you're over thinking it. Go back to the beginning and look at what the command you are executing.

It's returning three instantaneous velocity magnitudes. Up/Down, North/South, East/West. This describes the path of travel of your COM relative to the source of gravity/origin in that SOI.

No it isn't. It's not aligned with those directions at all, which was the whole point that made me start the thread.

[Dunbaratu]

So I've almost got it but now I need a way to find at which longitudes the X and Z axes come out from the globe, which ISN'T the zero point of the latitude/longitude of the planet it seems. On Kerbin it appears to be that the X axis exits the globe at about Longitude -170 or so, and the Z axis comes out of the globe at about Longitude 100 or so. Getting those numbers more precisely is needed to make a conversion from the XYZ numbers into a vector expressed in terms of north/east/up. I can do the trig to make the conversion but only if I know which longitude to call "zero".

Is there somewhere to look that up for each body in the game?

[Faark]

There are a bunch of techniques for mods to get the height over terrain, and in the worst cast if non of the objects has a fitting property you can still do a raycast. Anyway, as far as i did understood you, you are not writing a mod but a kOS script. That means you have to look what stuff your script environment offers and use those value & should refer to their documentation.

[Dunbaratu]

There are a bunch of techniques for mods to get the height over terrain, and in the worst cast if non of the objects has a fitting property you can still do a raycast. Anyway, as far as i did understood you, you are not writing a mod but a kOS script. That means you have to look what stuff your script environment offers and use those value & should refer to their documentation.

It doesn't offer enough to do this, which is the problem, I think. It presents an "up" Euler rotation set for your current position, and a "north" Euler rotation set for your current position and expects you to use them to steer by, but when it gives you vectors instead of rotation tuples, those vectors are expressed in the native coordinate space, and since Euler rotations, despite the name, don't actually rotate the universe but rather they distort it into a non-orthogonal shape, I can't wrap my head around them.

Basically I guess it's a failing of the mod. To do anything useful requires that you know the meaning of the XYZ numbers but there isn't enough information being passed from the native API up to the KOS user to do that. I've been experimentally looking at the XYZ velocity at different points in orbit trying to find the longitude where the X and Z axes is on the planet (when the X or Z part of the velocity turns to zero when in a perfectly circular orbit, I reckon I'm on an axis). Z seems to be near 100 degrees, but not exactly there, and at any rate this isn't a general solution for all planets just to learn where it is on Kerbin.

[BubbaWilkins]

For grins, and if you don't mind humoring me:

What are the returned values for that command:

Stationary:

At the KSP launchpad:

At the North Pole:

At the South Pole:

at some point 1/2 way between KSP and the North Pole:

In circleized orbit:

150km Equatorial:

150km Polar:

time of day and orientation of the craft shouldn't matter.

[Dunbaratu]

In a lot of experimenting I eventually figured out what the underlying "hidden" XYZ system really is based purely on taking lots of velocity and "up" samples at different positions and using them to work out logically what it has to be. Now I've got the transformation I wanted worked out, and it's here:

http://kos.wikia.com/wiki/Tutorial_-_KOS_0.65_and_above:_Finding_surface_dynamic_information

It occurs to me that now that I have this I could probably also get my position in XYZ terms (another thing the KOS mod doesn't tell you) by using the altitude plus the sea-level radius of the planet to get the radius of the polar-coordinate system, and then convert that to XYZ now that I can work out the angles of the polar coordinate system relative to the "hidden" X and Z axes.

[BubbaWilkins]

In a lot of experimenting I eventually figured out what the underlying "hidden" XYZ system really is based purely on taking lots of velocity and "up" samples at different positions and using them to work out logically what it has to be. Now I've got the transformation I wanted worked out, and it's here:

http://kos.wikia.com/wiki/Tutorial_-_KOS_0.65_and_above:_Finding_surface_dynamic_information

It occurs to me that now that I have this I could probably also get my position in XYZ terms (another thing the KOS mod doesn't tell you) by using the altitude plus the sea-level radius of the planet to get the radius of the polar-coordinate system, and then convert that to XYZ now that I can work out the angles of the polar coordinate system relative to the "hidden" X and Z axes.

Nice work. I would have never expected the coordinate system to have been derivative of position at the point of SOI engagement. I figured these were always absolute, but it does make sense.