General Question Establishing a local vessel reference frame/coordinate system

[birdman]

Heyho :tiphat:

a new question came up.
I try to establish a local vessel reference frame/coordinate system which is not dependent on the CoG of the vessel.
This is necessary to move my CoG without moving my local vessel coordinate system.
This sound probably very stupid, but is this at all possible, when the definition is:

Note that in Orbiter, a vessel’s CG coincides by definition
always with the origin (0,0,0) of its local reference frame.

Best regards
birdman

 

[JMW]

Doesn't either void ShiftCentreOfMass (const VECTOR3 &shift);
or void ShiftCG (const VECTOR3 &shift);
do this for you depending whether you want to retain mesh etc positions or not ?

 

[jedidia]

This sound probably very stupid, but is this at all possible, when the definition is:

It depends what you want to use it for. IMS2 is using a vessel-internal coordinate system, since the CoG is a result of its internal composition, and if it wouldn't retain its own zero-point there would be incremental errors over time when shifting CoG (not to mention that I'd have to update a whole lot of internal position references by hand).

In essence, all you have to do is store your CoG-offset. There's your internal 0-coordinate.

In a bit more detail, you take an arbitrary point in your vessel as your internal 0/0/0, and note how far away that is from the initial CoG. When the CoG should move, you calculate where it's supposed to move in internal coordinates, shift it by the difference of that new position and its previous offset, and store the new offset. This way you always know where your CoG is in respect to a certain point in your vessel.

 

[birdman]

Doesn't either void ShiftCentreOfMass (const VECTOR3 &shift);
or void ShiftCG (const VECTOR3 &shift);
do this for you depending whether you want to retain mesh etc positions or not ?

As far as I understand the API description to these options, both lead to a translation of the initial vessel coordinate system in the new CoG.
Only difference is, the handling of the meshes/dockingports/etc.

Please correct me if I'm wrong.

In a bit more detail, you take an arbitrary point in your vessel as your internal 0/0/0, and note how far away that is from the initial CoG. When the CoG should move, you calculate where it's supposed to move in internal coordinates, shift it by the difference of that new position and its previous offset, and store the new offset. This way you always know where your CoG is in respect to a certain point in your vessel.

At the moment I'm trying to set up a transformation of my body based coordinate system (local vessel COS) to a velocity COS.
The origin of this COS is placed in the center of pressure, which is per definition (in a reference documentation) in the axis of symmetry of my rotationally symmetrical vessel.

If I now shift my CoG in one component (in my case the y-axis) I shift it away from the axis of symmetry. And from this moment on (that's how I understand it) all my vessel relative parameters I get from API commands, are now relative to the new origin of the local vessel COS.
Am I right with this assumption?
Also my center of pressure (defined while creation of an airfoil, is now out of the center line).

It depends what you want to use it for. IMS2 is using a vessel-internal coordinate system, since the CoG is a result of its internal composition, and if it wouldn't retain its own zero-point there would be incremental errors over time when shifting CoG (not to mention that I'd have to update a whole lot of internal position references by hand).

That's exactly my point/problem I don't want to update all parameters and already written functions, which are dependent on the "neutral" local vessel COS.

 

[jedidia]

all my vessel relative parameters I get from API commands, are now relative to the new origin of the local vessel COS.
Am I right with this assumption?

The API will always consider your CoG to be the 0/0/0 of your vessel and give data relative to that, yes.

That's exactly my point/problem I don't want to update all parameters and already written functions, which are dependent on the "neutral" local vessel COS.

I'm afraid you won't get around some updating your code if you want to switch to a new coordinate system. I would suggest just putting a method in your vessel class that transforms the CoG-relative coordinates to your internal coordinate system, and then use that in all your other methods.

 

[birdman]

I'm afraid you won't get around some updating your code if you want to switch to a new coordinate system. I would suggest just putting a method in your vessel class that transforms the CoG-relative coordinates to your internal coordinate system, and then use that in all your other methods.

Seems like it h:
Thank you all for your fast help

 

[martins]

I guess the original question has been answered, but just to summarise:

• the origin of the vessel's local frame of reference, as used by the API, is (by definition) the centre of gravity
• in addition, the local frame of reference is orientated so that the inertia tensor is diagonal. For most vessel designs with some structural symmetry this will naturally be approximately correct.

Orbiter assumes these points to be satisfied. If they are not, at least approximately, then Orbiter's rigid body model will produce nonphysical results.

If the CoG moves with respect to the vessel structure (the meshes), then the meshes (and all parameters fixed in the mesh frame) must be moved in the opposite direction.

This also means that you will need to adjust the vessel's position in the global frame, such that the moved mesh frame retains a fixed position in the global frame.

 

[birdman]

Thank you martins for the clarification!

So as a result if I want to get parameters like Roll, Pitch, Yaw over the complete simulation from the same reference system, I can't use the APIs for it, because their reference point is shifted out of the symmetry axis (z-axis) of my rotational symmetrical vessel at some point.

At the moment I can't get behind the necessary transformations to get the
angles as described for the APIs:

Lets take a look at the definition of the "oapiGetPitch" API

Returns pitch angle w.r.t. closest planet
The local horizon is the plane whose normal is defined by the distance vector from the planet centre to the vessel.
The handle passed to the function must refer to a vessel.

So I want to get the angle between the vessel’s positive z axis (forward direction) and the normal of the local horizon.

1. Question
Does the distance vector from the planet centre to the vessel point to the CoG of the vessel? (I think it does, I just want to make sure)

2. Question
Does the orientation (except the sign) of the normal of the local horizon match the weight vector of the vessel? It should if the normal points to the CoG and the weight vector should point to the centre of the gravitation reference object

3. Question
Is it possible to get the distance vector in the vessel relative coordinate system? I just don't seem to find a way to accomplish it.

Coordinate transformations are hard until you really understand them...

Thank you in advance

(If I should better open a new thread for this questions, please tell me. I will then do so.)

 

[martins]

1. Question
Does the distance vector from the planet centre to the vessel point to the CoG of the vessel? (I think it does, I just want to make sure)

Yes it does. The vessel's position in the global frame is the position of its local frame origin, and hence the CoG.

2. Question
Does the orientation (except the sign) of the normal of the local horizon match the weight vector of the vessel? It should if the normal points to the CoG and the weight vector should point to the centre of the gravitation reference object

Yes, the normal of the local horizon and weight vector are colinear. They do point to the centre of the gravitation reference body, but that last point may not remain true in the future, if the planet's geoid is modelled by something more accurate than a sphere.

3. Question
Is it possible to get the distance vector in the vessel relative coordinate system? I just don't seem to find a way to accomplish it.

I haven't got the API at hand right now, but the vessel should have a method to retrieve its rotation matrix for transformation from local to global frame. Just transform the global distance vector with the transpose of that matrix.

 

[birdman]

Thank you very much for your fast and very helpful reply!

I think I can make it work now.