High fidelity rotation information (binary PCK conversion)

[ChristopherRabotin]

High level description

Note: only the high level description needs to be filled out to report an issue or to request a new feature.

New feature

NAIF publishes Moon BPC data tied to a specific ephemeris (e.g. DE440.bsp has its own Moon BPC) and regularly publishes the long and short-term Earth Orientation Parameters. These provide high precision rotation calculations for the Earth and Moon.

PCK Required Reading describes the three kinds of BPC that exist. Note that only two of those are used by NASA.

CK Required Reading describes the camera kernels of NAIF.

One could argue that there is no reason for these to be separate data sources.

Therefore:

1. this issue should allowing storing both kinds of data in the orientation_data field of an ANISE file, whilst also providing an allocation-free reading and conversion of the NAIF data.
2. this issue should also provide interpolation methods of a specific attitude representation that is glitch free such that the interpolation does not lead to ringing of the data: this will require a lit review of interpolation methods (maybe a Fourier interpolation of quaternions could work well here?)

Requirements

The purpose of this section is to fill out the Requirements of the QA process.

• [x] Rotation from source frame to parent frame when defined in planetary constant kernels
• [x] Rotation from source frame to parent frame when defined in BPC kernel
• [x] Rotation from any arbitrary frames defined either as PCK or BPC kernels which share a rotation node
• [x] Add transformation functions to rotation and translate between any arbitrary frame which share a rotation and translation node
• [x] Validation of PCK
• [x] Validation of BPC rotation
• [x] Validation of BPC DCM time derivative

Test plans

This must be validated by running the same queries in SPICE (using rust-spice) and ANISE.

Design

This is the design section. Each subsection has its own subsection in the quality assurance document.

Algorithm demonstration

If this issue requires a change in an algorithm, it should be described here. This algorithm should be described thoroughly enough to be used as documentation. This section may also simply refer to an algorithm in the literature or in another piece of software that has been validated. The quality of that reference will be determined case by case.

API definition

Define how the ANISE APIs will be affect by this: what are new functions available, do any previous function change their definition, why call these functions by that name, etc.

High level architecture

Document, discuss, and optionally upload design diagram into this section.

Detailed design

The detailed design *will be used in the documentation of how ANISE works.

Feel free to fill out additional QA sections here, but these will typically be determined during the development, including the release in which this issue will be tackled.

[ChristopherRabotin]

I need to figure out the rotation from ECLIPJ2000 to J2000 because it turned out that my validation case was incorrect.

This might be as simple as a 23.4 degree rotation about X: https://naif.jpl.nasa.gov/pub/naif/toolkit_docs/Tutorials/pdf/individual_docs/17_frames_and_coordinate_systems.pdf.