Better Ephemerides, Rotation Models, and a Solution to X64 Builds

[n72.75]

The one important thing that is missing now is celestial body orientation. SPICE can handle this very easily.
I think the simplest way is to add something like this to Celbody.cpp, in CelestialBody::GetRotation(..):
if (module && module->bRotation())
return module->clbkRotation(mjd, rot);
...
Then it will be possible to implement this rotation in spice.dll.
It will also be possible to implement any custom rotation for any Celbody using external modules.

What is the best format to represent rotation in, as far as something that would get passed to the new clbkRotation function.
I'm very on the fence, Quaternion vs Rotation matrix. I guess I could make overloads for both, but if cspice has a "preferred" or "native" format that we have to do less translations on, I'd prefer to use that.

Apologies for replying for replying to the same thread 3 times in a row...don't ban me.

 

[Ajaja]

What is the best format to represent rotation in, as far as something that would get passed to the new clbkRotation function.
I'm very on the fence, Quaternion vs Rotation matrix. I guess I could make overloads for both, but if cspice has a "preferred" or "native" format that we have to do less translations on, I'd prefer to use that.

Orbiter uses Rotation matrix

void CelestialBody::GetRotation (double t, Matrix &rot)

BTW, some years ago I made a Python script that compares SPICE rotation and Orbiter rotation and optimizes the parameters (LAN/Obliquity/SidRotOffset/SidRotPeriod) to fit better over a given time interval. It may be useful now (specifically SpiceRotation.UpdateRotation function):

 

[n72.75]

Orbiter uses Rotation matrix

void CelestialBody::GetRotation (double t, Matrix &rot)

BTW, some years ago I made a Python script that compares SPICE rotation and Orbiter rotation and optimizes the parameters (LAN/Obliquity/SidRotOffset/SidRotPeriod) to fit better over a given time interval. It may be useful now (specifically SpiceRotation.UpdateRotation function):

Thank you.

I'm a little unsure on how to proceed next, and could use your input.

I'm assuming this is what I'm looking for:

def UpdateRotation(self, MJD=MJD0):
    self.MJD = MJD
    et = (MJD - 51544.5) * 86400
    rotate = sp.pxform(self.name, "ECLIPJ2000",  et)
    x, y, z = np.dot(rotate, np.array([0, 0, 1]))
    ra = math.atan2(y, x)
    dec = math.asin(z)
    rotback = sp.eul2m(0, dec-HALFPI, ra-HALFPI, 3, 1, 3)
    x, y, z = np.dot(rotate, np.array([1, 0, 0]))
    x, y, z = np.dot(rotback, np.array([x, y, z]))
    pm = -math.atan2(y, -x)

    LAN = np.mod(ra-HALFPI, TWOPI)
    Obliquity = np.mod(HALFPI-dec, TWOPI)
    SidRotOffset = np.mod(PI + pm - (MJD0 - 51544.5)
                          * self.prime[1]/360 * TWOPI, TWOPI)
    SidRotPeriod = 360/self.prime[1]*86400
     self.rp = OrbiterRotation.RotationParameters(SidRotPeriod=SidRotPeriod, SidRotOffset=SidRotOffset, Obliquity=Obliquity, LAN=LAN)
     # right hand to left hand
    for i in range(3):
        for j in range(3):
                self.rotate_lh[i, j] = rotate[3-i if i > 0 else i, 3-j if j > 0 else j]

So PXFRM is to rotation as SPKGEO is to position.

Or more precicely I'd need to call:

Matrix* rot;
pxform_c(body_id, "ECLIPJ2000", ((mjd - 51544.5) * 86400.0), rot);

And then orbiter-ify the handedness of the rotation matrix.

This seems fairly easy.

 

[Ajaja]

So PXFRM is to rotation as SPKGEO is to position.

Or more precicely I'd need to call:

Matrix* rot;
pxfrm_c(body_id, "ECLIPJ2000", ((mjd - 51544.5) * 86400.0), rot);

And then orbiter-ify the handedness of the rotation matrix.

This seems fairly easy.

Yes, pxfrm and the conversion from right-hand to left-hand should work. But needs some testing