This is probably introduced by https://github.com/anise-toolkit/specs/commit/a3204fdac1e877e20f2eb19448fe6d275bf31ff4, where licensing was updated, but not in the README.

They are needed in Nyx because of how the frames are handled in there, but in Anise, we can get rid of it (probably). To compute the first and last state, simply evaluate at the start and end times.

It should be possible to use ANISE to store gravity fields, e.g. EGM2008. At the moment, software will typically read this data from a text file found on NASA PDS in a specific format.

Text formats are great for data that is typically read or edited by humans. This is not the case for gravity field information.

Gravity field information contains the C_nm and S_nm coefficients and may optionally contain the standard deviation of those coefficients. This standard deviation data can be used to generate gravity clones, often used in orbit determination to see how small errors in the gravity field may affect the OD solution.

Storing this data as a packed structure will be significantly more efficient, and would prevent memory allocation to read said data.

Moreover, it should be possible for several gravity fields for the same object to be stored in the same file. This will allow for tools like Nyx to quickly switch between gravity fields while reading the same file.

Modified Rodrigues Parameters have been developed for the aerospace industry and recommended by Schaub (cf. Basilisk) and as the attitude representation in NASA's Best Practices for Navigation Filters.

Some of the main reasons include:

1. Ease of interpolation, although switching to the shadow set may lead to interpolation issues
2. Only three numbers proportional to the tangent of the quarter of the angle -- which implies that a 32 bit representation may be sufficient in many (most?) cases
3. Ease of conversion to a skew-symmetric matrix and to quaternions
4. No ambiguity in quaternion nomenclature or structure
5. The orientation path between two MRPs is necessarily the shortest path (which is not true for quaternions)
6. MRPs are necessarily normalized

Proposed signatures

This would be available everywhere by default.

MRP definition

pub struct MRP {
   s1: f32,
   s2: f32,
   s3: f32,
   is_singular: bool
}

Question: are 32 bits indeed enough to represent all rotations without loss compared to a 64 bit unit quaternion? This question can be easily answered with a plot showing the error in conversion to/from a 32 bit MRP and 64 bit quaternion.

Question: if the shadow set is always enforced, is there a need for the is_singular parameter?

Nomenclature

The nomenclature from Schaub and Junkins shall be used throughout the implementation, including for the naming of the operations (e.g. Add vs Mul).

Here are the recommended metadata points for FAIR: https://specs.fairdatapoint.org/#metadataschemas .

Although not all should be in the data files themselves, the metadata builder should allow for these.

In the specs, it would be extremely useful to provide a checksum field early into the file. The checksum should be computed for the subsequent data (i.e. metadata excluded). Moreover, a function shall be provided to recompute this checksum.

The purpose of this checksum is to allow for rapid verification of the integrity of the data, it shall not be used for signing the data. As such, the CRC32 hashing function is proposed (specifically the cdc32fast crate).

Proposed signatures

This is only valid in an Anise context, i.e. with a loaded Anise file.

impl Anise {
   /// Returns the rotation quaternion and the body rate vector
   pub fn verify_checksum(&self) -> Result<(), AniseError>;
}

The following AniseError enum variant is proposed:

pub enum  AniseError {
// ...
  /// Error returned if the checksum in the Anise file does not match the one computed by reading the file
  InvalidChecksum {expected: u32, computed: u32}
}

Proposed usage

This can be used onboard in a guidance loop to ensure that the data is valid at each new guidance loop iteration, and if it isn't, a backup file can be loaded from another disk for example.

ASN.1 is a highly efficient standardized platform-independent binary encoding used in lots of applications, including telecommunications and cryptographic key exchanges. This just looks amazing, seriously. Huge thanks to @pwnorbitals for letting me know about this.

Some references:

• https://www.thanassis.space/asn1.html
• https://luca.ntop.org/Teaching/Appunti/asn1.html
• A rust library that supports most of the tags in ASN.1: https://docs.rs/der/
• A cheat sheet reference: https://www.oss.com/asn1/resources/reference/ASN.1-Reference-Card-format-USA.pdf

Note: all of the ASN.1 specs below can be tested directly on this playground: https://asn1.io/asn1playground/ .

Benchmark encoding sizes

One issue with the der library is that it does not support the Real type defined in section 2.4 of the specs (PDF).

Rebuilding the REAL type

Built-in

ANISE DEFINITIONS AUTOMATIC TAGS ::= 
BEGIN
  Real ::= SEQUENCE       
  {                                                     
     data REAL
  }                                                     
END

Encode:

value Real ::= {
  data 3.141592653589793
}

DER: 26 bytes

Naive

ANISE DEFINITIONS AUTOMATIC TAGS ::= 
BEGIN
  Real ::= SEQUENCE       
  {                                                     
     mantissa INTEGER DEFAULT 0,
     realbase INTEGER DEFAULT 10,
     exponent INTEGER DEFAULT 0
  }                                                     
END

Encode Pi:

value Real ::= {
  mantissa 3141592653589793,
  realbase 10,
  exponent 15
}

DER: 14 bytes

Full specs

(Took me one hour to fix...)

ANISE DEFINITIONS AUTOMATIC TAGS ::= 
BEGIN
  Normal ::= SEQUENCE       
  {                                                     
     mantissa INTEGER DEFAULT 0,
     realbase INTEGER DEFAULT 10,
     exponent INTEGER DEFAULT 0
  }

Subnormal ::= ENUMERATED {
    plus-infinity,
    neg-infinity
}   

Real ::= CHOICE {
    as_normal Normal,
    as_subnormal Subnormal
}                                                                                                 
END

Encoding a normal number:

realdata Real ::= as_normal : {
  mantissa 3141592653589793,
  realbase 10,
  exponent 15
}

DER: 14 bytes ( no overhead it seems!)

Encoding a subnormal number:

realdata Real ::= as_subnormal : plus-infinity

DER: 1 byte (yet, ONE!)

Also computing the quaternion corresponding to a given rotation

Proposed signatures

This is only valid in an Anise context

impl Anise {
   /// Returns the rotation quaternion and the body rate vector
   pub fn rotation(&self, from_frame: &Frame, into_frame: &Frame) -> Result<(Quaternion, Vector3), AniseError>;
   pub fn position_rotation(&self, from_frame: &Frame, into_frame: &Frame) -> Result<Quaternion, AniseError>;
   /// Returns a 6x6 DCM which can be multiplied by a state represented as [x,y,z,vx,vy,vz]
   pub fn rotation_dcm(&self, , from_frame: &Frame, into_frame: &Frame) -> Result<Matrix6, AniseError>;
   /// The same as above but with the provided light time calculations, cf. https://docs.rs/nyx-space/latest/nyx_space/cosmic/enum.LightTimeCalc.html .
   pub fn rotation_with_correction(&self, obj: &Anise.Ephemeris, at: &Anise.Epoch, lt: LightTimeCalc) -> Result<Vector6, AniseError>;
}