API Question Put your spacecraft in conjunction with Earth

[Evgheny]

Sorry, if I messed up with the title, don't know how to say correct this in English. (edited, thanks 2 Keatah)

What I need:

I need to put my Vessel on a line "Earth - Sun" but at the opposite (to Earth) side of Sun.

Vessel ---- SUN ---- Earth

I've tried to do it in such a way:

// Getting handles of Sun and Earth
OBJHANDLE Sun = oapiGetGbodyByName("Sun");
OBJHANDLE Earth = oapiGetGbodyByName("Earth");	

// Getting Earth Global position
VECTOR3 earthpos;
oapiGetGlobalPos(Earth, &earthpos);

// Getting handle, instance and status instance of Vessel
VESSELSTATUS vs;
VESSEL2 *pVessel;
OBJHANDLE hVessel = oapiGetVesselByName("UAV");
pVessel = (VESSEL2*)oapiGetVesselInterface ( hVessel );
pVessel->GetStatus(vs);
	
// Vessel is on Sun's orbit
vs.rbody = Sun;
	
// Getting Local coordinates of Earth
VECTOR3 local_earthpos;
pVessel->Global2Local(earthpos, local_earthpos);
	
// If we put our vessel in point '-local_earthpos' 
// it should be opposite to Sun, isn't it?
vs.rpos = -local_eartpos;
	
// Saving Vessel state
pVessel->DefSetState(&vs);

I try my code with Camera Tool from Orbiter Main Menu.
In the second tab, I choose "Target from ... Sun" and then "Target from ... Earth"
and I got some little changing between these two states. But if I'm on a line Earth-Sun, I shouldn't get changes in these views, but I get.

Why this approach doesn't work? Where is my mistake?
Thank you in advance.


P.S. I've made some corrections in code, and it works now fine. Views "Target from Sun" and "Target from Earth" haven't any error (no difference at all).
But then I'm feeling misunderstanding in theory of Vessel positioning.
Such code works good:

// Getting Sun Global Position
VECTOR3 sunpos;
oapiGetGlobalPos(Sun, &sunpos);
vs.rpos = -earthpos+sunpos;

But both earthpos and sunpos are global coordinates. rpos field of state - is local coordinate, isn't it? So setting global coordinates in rpos is fine. But why?

 

[Face]

But both earthpos and sunpos are global coordinates. rpos field of state - is local coordinate, isn't it? So setting global coordinates in rpos is fine. But why?

With newer versions of Orbiter also comes barycenter simulation, resulting in 0,0,0 in Orbiter's global frame NOT being the center of the sun anymore.

And if you do glob(A)-glob(B), you'll get nothing else but relB(A), that's why your new rpos value fits the reference body "Sun".

 

[Evgheny]

With newer versions of Orbiter also comes barycenter simulation, resulting in 0,0,0 in Orbiter's global frame NOT being the center of the sun anymore.

Yeap, I've already knew (from here) about barycenter in [0,0,0]. (And I use Orbiter 2006, so it's not new)

And if you do glob(A)-glob(B), you'll get nothing else but relB(A), that's why your new rpos value fits the reference body "Sun".

Ok. Thanks. Understand.
So. rpos is global coordinates relative to reference body. But not local - that's why the first example of code doesn't work?

 

[Keatah]

I suppose the right way to say this is "put your spacecraft in conjunction with earth".

 

[Face]

Ok. Thanks. Understand.
So. rpos is global coordinates relative to reference body. But not local - that's why the first example of code doesn't work?

I see it like that: in Orbiter, you have different coordinate systems. 3 types of them are:
1. "Global" coordinates you'll get with GetGlobalPos() calls,
2. "Relative" coordinates you specify in VESSELSTATUS(EX),
3. "Local" coordinates you deal with in vessel-specific positioning (e.g. thruster position, mesh vertices, etc.).

All 3 types are Cartesian systems (meaning it uses perpendicular line axis with distance coordinates in contrast to e.g. polar coordinates) with equal scaling (meaning one unit in all 3 is 1 meter). They are different only in origin and rotation. To convert coordinates from one system to the other you'd normally need a 4x4 transformation matrix (rotation + scaling/offset). But since you only have an origin shift from 1 to 2, a rotation from 2 to 3, and consequently a shift plus a rotation from 1 to 3, we can work with 1 shift vector and 1 3x3 rotation matrix per coordinate system transformation.

Now I've written "3 types" of systems, not just "3 systems". That is because every object in Orbiter has it's own coordinate system, distinguished from the single "global" one by means of a set of shift vector and rotation matrix. The shift vector is simply the position of the object in the global frame, the rotation matrix is what lays behind Global2Local().

In your example, all 3 objects "Sun", "Earth" and the vessel have their own set, thus their own instances of type 2 and 3. Since VESSELSTATUS(EX) uses type 2 coordinates for the appropriate reference body, you have to use the "Sun" set for the transformation, ergo the Sun's position in the global frame as shift vector for the global position of the vessel. But you used the vessel set (rotation matrix via Global2Local) - even incompletely without the shift vector - to transform type 1 to type 3 for the vessel. Therefore it did not work.

Confusing enough? :lol:

 

[Evgheny]

Big thanks for explanation. Almost everything is clear now, just few questions:

But since you only have an origin shift from 1 to 2, a rotation from 2 to 3, and consequently a shift plus a rotation from 1 to 3, we can work with 1 shift vector and 1 3x3 rotation matrix per coordinate system transformation.

from 2 to 3 - is it only rotation? If frames differ only in rotation, it means that their origins match. In local system (3), origin of frame is the center of gravity of object. So coordinates of Vessel will be [0 0 0]. In relative system (2), origin is the reference body, Sun for example, if Vessel is on Sun's orbit.

But yes, so, we have 3 types of systems and we have in API such convert functions (Vessel methods):
Local2Global, Global2Local (3 <--> 1)
Local2Rel (3 --> 2)

I see such a formula in API Reference:

r_global = R * r_local + p_vessel;
(it's what is under Local2Global I guess)

I understand it in such a way: to convert Local coordinates to Global, we should rotate the axis (using rotation matrix) and than shift it.

So, if I set another rotation matrix via method setRotationMatrix... will it only rotate the object, or will it move it? I mean by changing R in equation above, r_global should change too... but it's the position of vessel.

In your example, all 3 objects "Sun", "Earth" and the vessel have their own set, thus their own instances of type 2 and 3. Since VESSELSTATUS(EX) uses type 2 coordinates for the appropriate reference body, you have to use the "Sun" set for the transformation, ergo the Sun's position in the global frame as shift vector for the global position of the vessel. But you used the vessel set (rotation matrix via Global2Local) - even incompletely without the shift vector - to transform type 1 to type 3 for the vessel. Therefore it did not work.

I got it.

Confusing enough? :lol:

Not so, as I was expected

 

[Face]

from 2 to 3 - is it only rotation? If frames differ only in rotation, it means that their origins match. In local system (3), origin of frame is the center of gravity of object. So coordinates of Vessel will be [0 0 0]. In relative system (2), origin is the reference body, Sun for example, if Vessel is on Sun's orbit.

I think this is the key point to understand my post above: 2 is in relation to the object itself, not the reference body it is orbiting. What I mean is that 2 ("relative" coordinates) is always depending on the object you have. So a vessel's 2 is relative to the vessel origin, not the body it might be orbiting. The 2 you use in VESSELSTATE is of course the 2 of a reference body, in your case the Sun's 2. It is just the vessel's position you want to represent INSIDE this Sun's type 2 coordinate system.

You do not have "only" 3 coordinate systems, but twice as many as you have objects (suns/planets/moons/vessels) plus one (the single global one). The transformation information to each of this coordinate systems is the appropriate object's position and rotation. And of course there are more types of coordinate systems in Orbiter, not only those Cartesian ones.

So to summarize:

OBJECT |         1->2        |            2->3
-------+---------------------+----------------------------
Sun    |    x2sun=x1-pSun    |     x3sun=Rsun * x2sun
Earth  |  x2earth=x1-pEarth  |  x3earth=Rearth * x2earth
Vessel | x2vessel=x1-pvessel | x3vessel=Rvessel * x2vessel

x1       .. point position in Orbiter's single type 1 coordinate system ("Global")
x2object .. point position in the type 2 coordinate system of the object ("Relative")
x3object .. point position in the type 3 coordinate system of the object ("Local")
pObject  .. vector shift of the object
Robject  .. rotation matrix of the object

x1 is what you get in oapiGetGlobalPos().
x2object is what you set in VESSELSTATUS for the reference body object.
x3object is what you typically need in vessel-specific positioning.

I hope I'm making sense to you now...

 

[Evgheny]

I hope I'm making sense to you now...

Yeap, now I understood the theory of Orbiter's coordinate systems.
Thank you very much.


For the same as I, I upload a drawing, representing relations of Orbiter's coordinate systems.