nyx-space / anise Goto Github PK

ANISE provides a toolkit and files for Attitude, Navigation, Instrument, Spacecraft, and Ephemeris data. It's a modern replacement of the NAIF SPICE toolkit.

License: Mozilla Public License 2.0

Rust 98.80% Python 0.86% Shell 0.03% HTML 0.02% Dhall 0.29%

attitude ephemeris naif rust spice

anise's Introduction

ANISE (Attitude, Navigation, Instrument, Spacecraft, Ephemeris)

ANISE is a rewrite of the core functionalities of the NAIF SPICE toolkit with enhanced performance, and ease of use, while leveraging Rust's safety and speed.

Please fill out our user survey

Introduction

In the realm of space exploration, navigation, and astrophysics, precise and efficient computation of spacecraft position, orientation, and time is critical. ANISE, standing for "Attitude, Navigation, Instrument, Spacecraft, Ephemeris," offers a Rust-native approach to these challenges. This toolkit provides a suite of functionalities including but not limited to:

Loading SPK, BPC, PCK, FK, and TPC files.
High-precision translations, rotations, and their combination (rigid body transformations).
Comprehensive time system conversions using the hifitime library (including TT, TAI, ET, TDB, UTC, GPS time, and more).

ANISE stands validated against the traditional SPICE toolkit, ensuring accuracy and reliability, with translations achieving machine precision (2e-16) and rotations presenting minimal error (less than two arcseconds in the pointing of the rotation axis and less than one arcsecond in the angle about this rotation axis).

Features

High Precision: Matches SPICE to machine precision in translations and minimal errors in rotations.
Time System Conversions: Extensive support for various time systems crucial in astrodynamics.
Rust Efficiency: Harnesses the speed and safety of Rust for space computations.
Multi-threaded: Yup! Forget about mutexes and race conditions you're used to in SPICE, ANISE guarantees that you won't have any race conditions.
Frame safety: ANISE checks all frames translations or rotations are physically valid before performing any computation, even internally.
Auto-downloading capability: ANISE simplifies your workflow by automatically downloading the latest Earth orientation parameters, or any other SPICE or ANISE file from a remote location, seamlessly integrating them into the Almanac for immediate use.

Interfaces

Rust

ANISE is developed in Rust, leveraging Rust's robust features such as memory safety, efficient concurrency handling, a superb test framework, and excellent error management. These capabilities ensure that all ANISE features are highly reliable and secure from the outset. Being native to Rust, these features are available first within the Rust ecosystem, offering cutting-edge functionality to Rust developers. They are then integrated into other interfaces. If there is a feature in Rust that has yet to be ported into the language of your choice, please open a Github issue.

Refer to the Rust README for further details. The Rust API documentation is available on https://docs.rs/anise/latest/anise/.

Python

Although ANISE is primarily developed in Rust, it offers first-class support for Python, recognizing that many users will interact with ANISE through its Python interface. This integration ensures that Python users can leverage most of ANISE's capabilities without compromise. If you encounter any limitations or missing features in the Python support, we encourage you to open a GitHub issue to help us improve the interface.

For Python-specific tutorials and resources, please refer to the Python README, which includes Jupyter notebook tutorials tailored for Python users.

GUI

ANISE provides a graphical interface to inspect SPK, BPC, and PCA (Planetary Constant ANISE) files. Allows you to check the start/end times of the segments (shown in whichever time scale you want, including UNIX UTC seconds).

Refer to the GUI README for details.

Validation

ANISE is validated by running the same queries in ANISE and in SPICE (single threaded) in the Validation step linked above. This workflow validates 101,000 BSP queries in the DE440.BSP file, and 7305 queries each frame in the PCK08 file (every day for 20 years), along with thousands of rotations from Earth high precision BPC file.

Note: The PCK data comes from the IAU Reports, which publishes angle, angle rate, and angle acceleration data, expressed in centuries past the J2000 reference epoch. ANISE uses Hifitime for time conversions. Hifitime's reliance solely on integers for all time computations eliminates the risk of rounding errors. In contrast, SPICE utilizes floating-point values, which introduces rounding errors in calculations like centuries past J2000. Consequently, you might observe a discrepancy of up to 1 millidegree in rotation angles between SPICE and ANISE. However, this difference is a testament to ANISE's superior precision.

Resources / Assets

For convenience, Nyx Space provides a few important SPICE files on a public bucket:

de440s.bsp: JPL's latest ephemeris dataset from 1900 until 20250
de440.bsp: JPL's latest long-term ephemeris dataset
pck08.pca: planetary constants ANISE (pca) kernel, built from the JPL gravitational data gm_de431.tpc and JPL's plantary constants file pck00008.tpc
pck11.pca: planetary constants ANISE (pca) kernel, built from the JPL gravitational data gm_de431.tpc and JPL's plantary constants file pck00011.tpc
moon_fk.epa: Euler Parameter ANISE (epa) kernel, built from the JPL Moon Frame Kernel moon_080317.txt

You may load any of these using the load() shortcut that will determine the file type upon loading, e.g. let almanac = Almanac::new("pck08.pca").unwrap(); or in Python almanac = Almanac("pck08.pca"). To automatically download remote assets, from the Nyx Cloud or elsewhere, use the MetaAlmanac: almanac = MetaAlmanac("ci_config.dhall").process() in Python.

Contributing

Contributions to ANISE are welcome! Whether it's in the form of feature requests, bug reports, code contributions, or documentation improvements, every bit of help is greatly appreciated.

License

ANISE is distributed under the Mozilla Public License 2.0 (MPL-2.0), offering a balanced approach to open-source by allowing the use of source code within both open and proprietary software. MPL-2.0 requires that modifications to the covered code be released under the same license, thus ensuring improvements remain open-source. However, it allows the combining of the covered software with proprietary parts, providing flexibility for both academic and commercial integrations.

For more details, please see the full text of the license or read a summary by Github.

Acknowledgements

ANISE is heavily inspired by the NAIF SPICE toolkit and its excellent documentation.

Contact

For any inquiries, feedback, or discussions, please open an issue here or contact the maintainer at [email protected].

anise's People

Contributors

Stargazers

Watchers

Forkers

gregoirehenry pwnorbitals shabbirhasan1 hartmut thomasantony leafwell cmleinz

anise's Issues

Support overwriting part of an ephemeris/orientation data

There is a use case where a user may wish to load a smaller spacecraft ephemeris and have ANISE automatically switch to that one where possible. In SPICE this is handled by order to loading (furnsh). This helps in creation operational kernels. In the following example, let PREV be the previous spacecraft ephemeris, NEW be the new one from a new orbit determination solution.

Query     t_0  t_1 t_2 ...    t_k
                |      |     |            |
NEW        |   ---------------   |
PREV     -------------------------

In this use case, NEW does not have any data for t_0 or t_k, but it does for t_1 and t_2. So for t_0 and t_k querying, SPICE returns the data from PREV. But for a query on t_1 or t_2 SPICE returns the data from the NEW ephemeris.

This simplest solution here is to prevent loading two ephemeris/orientation data with the same name. If we support loading both, then there could be some confusion (where does this data point come from) and it's complicated to store both given how the look up table is setup. At the same time, I definitely see a use-case where one might want this: updating an ephemeris after an OD solution for example. But that use-case would probably be better handled through the anise merge command (or anise_ctx.merge(anise_ctx_2) via the rust API).

@pwnorbitals , what do you think should be the behavior?

Create issue templates

Issue templates will ensure that ANISE adheres to the Nyx Quality Assurance process.

Structures and traits for rotation mathematics ( SO(3) group )

High level description

Rotations are a key component of attitude and orientation parameters. At first, ANISE only supports Direct Cosine Matrix math. This is a redundant representation of rotations and therefore not an optimal one.

The purpose of this issue is to design and implement a correct SO(3) group for use in ANISE. Currently, work by Greg and Chris in commit 04b719f, have an early draft of what is needed for rotations in src/math/rotation/mod.rs.

Some useful resources:

Wikipedia on SO(3)
RigidBodyKinematic.py is Basilisk's set of conversions between different attitude representations
Sophus (C++) is a Lie group implementation in C++
Mathoverflow
PyQuat is an excellent resource for quaternion math (uses the Shulster notation)
This PDF seems to provide good information on how to derive different representations.

Requirements

Rotation structures shall be composable
1. Composition between different representations shall be supported
2. Composition between different representations shall use the most efficient calculation that maintains accuracy (efficient as "least number of instructions", as determined by iai/cachegrind)
Rotations shall check the source and destination frames to prevent invalid rotations (this can probably not be done at compile time)
The following representations shall be supported at a minimum:
1. Direct Cosine Matrix (DCM)
2. Quaternions shall be supported in their "natural" form (i, j, k, scalar), but a conversion to and from Shuster notation shall also be supported (https://possiblywrong.wordpress.com/2021/05/10/beware-the-natural-quaternion/)
3. Modified Rodrigez Parameters (cf. Springer and Schaub)
4. Representations shall be unambiguous on initialization and getters (e.g. a quaterion shall not be publicly indexable because that's confusion to the user who might not remember the storage order)
All representations shall provide relevant helpers
1. Quaternions shall provide at a minimum a conjugate function and a "short direction" function
2. MRPs shall provide at a minimum a shadow set representation
All computations shall be checked for math domain errors and return AniseError::MathError where relevant.
All representation shall allow for rotation of both vectors and matrices (and ensure that matrices are rotated using C^T * A * C)
_More? Should we this also provide the time-derivatives of each representation? That could be useful)

Test plans

How do we test that these requirements are fulfilled correctly? What are some edge cases we should be aware of when developing the test code.

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.

Local solar time computations

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

If this is a new feature, describe the need you have either with use cases or examples. If this is a bug report, file a bug report instead.

Requirements

ANISE shall provide a function equivalent to et2lst that takes an ephemeris epoch et and a longitude as input arguments.
The et2lst function shall return the local solar time at the specified longitude for the given epoch.
The et2lst function shall be based on the SPICE implementation and provide the same results.
The et2lst function shall take into account any applicable leap seconds in the computation of the local solar time.
The et2lst function shall handle inputs in a range of valid values, including dates beyond the valid range of SPICE.
The et2lst function shall return an error if the input arguments are invalid or if there is a problem with the computation.
The opposite function (equivalent to lst2et) shall take as input the local solar time, the longitude of the object, and the body on which the object is located.
The function shall return the corresponding ephemeris epoch et or local solar time.
The function shall handle cases where the input local solar time is outside of the range [0, 86400] seconds.
The function shall handle cases where the input longitude is outside of the range [-180, 180] degrees.
The function shall handle cases where the input body is not recognized.

Test plans

For the et2lst function equivalent, test cases should include providing a variety of epoch times and longitudes to ensure that the resulting local solar time is correct. This can be verified by comparing the output of the function to expected values or by comparing it to the output of the lst2et function when provided with the same input.

For the lst2et function equivalent, test cases should include providing a variety of local solar times and longitudes to ensure that the resulting epoch time is correct. This can be verified by comparing the output of the function to expected values or by comparing it to the output of the et2lst function when provided with the same input.

Design

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

Algorithm demonstration

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.

Load SPICE metakernel

High level description

SPICE metakernels are really useful for ensuring that the same data is always loaded correctly. The purpose of this issue is to implement a way to load and append a given Almanac from a SPICE metakernel.

Requirements

#152
Parse the variables if appliable
Load all of the files on the heap
Convert from the SPICE files to the ASN1 equivalent where needed.

Test plans

Test loading without variable
Test loading with variables

Design

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

API definition

Maybe something like this:

impl Almanac {

    /// Extends the current Almanac with the provided meta kernel
    pub fn extend(&mut self, meta: Metakernel) {
    // ...
    }

    // Clone the Almanac and extend it with the provided meta kernel
    pub fn with(&self, meta: Metakernel) -> Self {
    // ...
    }
}

pub struct Metakernel {
paths: HashMap<String, PathBuf>,
kernels: Vec<String>
}

Metakernel would implement FromStr to be build from the string of the metakernel I think. It would also reuse the parse function currently used to parse all other KPL files.

Example input:

\begindata
 
   PATH_VALUES  = ( '/flight_projects/mgs/SPICE_kernels',
                    '/generic/SPICE_kernels'              )
 
   PATH_SYMBOLS = ( 'MGS',
                    'GEN' )
 
 
   KERNELS_TO_LOAD = ( '$GEN/leapseconds.tls',
                       '$MGS/mgs.tsc',
                       '$GEN/generic.bsp',
                       '$MGS/mgs.bc',
                       '$GEN/earth.bpc',
                       '$MGS/mgs.bes'           )
 
   \begintext

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.

BSP export of a single ephemeris

It should be possible to export an ANISE ephemeris data to a BSP file. A single entry BSP should not be too difficult I think, but maybe I'm wrong.

This is useful so that no one is stuck in ANISE format. When this tool and the other ones are completed, it should be possible to convert any CCSDS OEM into ANISE (and vice versa) and any BSP into ANISE (but probably not vice versa on writing).

Moon frame simplifications

High level description

The Moon is the Earth's Moon. So let's call it that.

Requirements

Rename LUNA_xxx frames to MOON_xxx
Create the IAU_MOON frame constant
Create the MOON_ME frame constant
Create the MOON_PA frame constant (requires an update to the pck.pca file) -- check out the moon_xxx.tf file in the data folder
Expose all three of these to Python

Test plans

Ensure that it's exposed to Python notebooks

Design

No change

Context should include planetary constants

Context should include planetary constants (these should be not inherited by children nodes because lack of constant definition does not imply that the same constant is applicable in the child's context).

Convert a set of KPL/TPC files into the ANISE equivalent format
Convert the KPL/TPC nutation and precession angles into ANISE equivalent format
~~Compute the phase angles given an Epoch~~ cf #35
Lookup of planetary data from the Context provided a NAIF ID if that data is stored as constants (i.e. TPC equivalent)
Lookup of planetary data from the Context provided the &str name if that data is stored as constants (i.e. TPC equivalent)
Lookup of planetary data from the Context provided a NAIF ID if that data is stored as a set of interpolated coefficients from BPC
Lookup of planetary data from the Context provided the &str name if that data is stored as a set of interpolated coefficients from BPC

Support SPK Type 9 - Lagrange Unequal Time Steps

SPICE Documentation

Purpose

Be able to convert a BSP file of Type 9 to an ANISE trajectory file.

SPICE organization

                                       +--------+
                                       |  x(1)  |
                                   /   +--------+
                                  /    |  y(1)  |
                                 /     +--------+
                                /      |  z(1)  |
   +-----------------------+   /       +--------+
   | State 1               |  <        |dx(1)/dt|
   +-----------------------+   \       +--------+
   | State 2               |    \      |dy(1)/dt|
   +-----------------------+     \     +--------+
               .                  \    |dz(1)/dt|
               .                       +--------+
               .
   +-----------------------+
   | State N               |
   +-----------------------+
   | Epoch 1               |
   +-----------------------+
   | Epoch 2               |
   +-----------------------+
               .
               .
               .
   +-----------------------+
   | Epoch N               |
   +-----------------------+
   | Epoch 100             | (First directory)
   +-----------------------+
               .
               .
               .
   +-----------------------+
   | Epoch ((N-1)/100)*100 | (Last directory)
   +-----------------------+
   | Polynomial degree     |
   +-----------------------+
   | Number of states      |
   +-----------------------+

Test requirements

Find a public BSP Type 8 file
Ensure correct parsing
Ensure correct copying of the data
Ensure correct computation of states

Migrate from travis-ci to github actions

Travis CI suddenly wants me to pay for builds although this is an open-source project which should be free. GA could also be used for deployment later on, so we might as well switch to that for builds now.

https://docs.github.com/en/actions/migrating-to-github-actions/migrating-from-travis-ci-to-github-actions

SPICE BSP files should be usable without needing the ANISE file equivalent

Use case

Although the ANISE file format provides a number of advantages compared to the BSP files, requiring users to convert their data into ANISE before using this library is a large overhead.

Effort

ANISE.rs already supports reading BSP files of some types. However, that implementation requires memory allocations. These should not be required.

Hence, the crux of this issue is to rewrite the SPK parser to not perform any memory allocations. This issue also includes providing a rewrite of some of the SPK related functions (exact list to be determined from this list). These functions must be behind a specific crate feature, e.g. spice-interop.

Verification

TDB: from the list of functions above, the tests should require rust-spice by @GregoireHENRY and make sure that the SPK functions selects return the same values. This will likely require #26 too.

Strange periodic error between SPICE and ANISE for ephemerides computation

Bug report

Bug reports will lead to a stakeholder need report, and will need to be linked to this issue

Describe the bug

Between SPICE and ANISE, the ephemeris computation has a periodic error despite both receiving the same input epoch in f64.

Hunch: CSPICE is built with gcc whereas rust is build with clang. So maybe there's a rounding issue somewhere? One way to test this would be to modify the dev-env-setup.sh file and switch the compiler from gcc to clang.

Relative error in Hermite Type 13:

Relative error in Chebyshev Type 2 for DE440 file

Pluto error

Mars error

To Reproduce

Clone anise.rs
Build CSPICE (for the tests)
Run RUST_BACKTRACE=full RUST_LOG=debug cargo test validate_hermite_translation --features validation --release -- --nocapture
Run the analysis script ipython analysis/spk_type13_val_err.py
See error in the Plotly plots.

Expected behavior

We expect the relative error to be zero not a few nanometers.

Code to reproduce the issue

The steps above are sufficient. You may also grab the artifacts from the build.

Platform

Linux for sure, likely other platforms too.

Additional context

Add any other context about the problem here.

validation-artifacts(1).zip

Support SPK Type 8 - Lagrange Equal Time Steps

SPICE Documentation

Purpose

Be able to convert a BSP file of Type 8 to an ANISE trajectory file.

SPICE organization

                                       +--------+
                                       |  x(1)  |
                                   /   +--------+
                                  /    |  y(1)  |
                                 /     +--------+
                                /      |  z(1)  |
   +-----------------------+   /       +--------+
   | State 1               |  <        |dx(1)/dt|
   +-----------------------+   \       +--------+
   | State 2               |    \      |dy(1)/dt|
   +-----------------------+     \     +--------+
               .                  \    |dz(1)/dt|
               .                       +--------+
               .
   +-----------------------+
   | State N               |
   +-----------------------+
   | Epoch of state 1 (TDB)|
   +-----------------------+
   | Step size             |
   +-----------------------+
   | Polynomial degree     |
   +-----------------------+
   | Number of states      |
   +-----------------------+

Test requirements

Find a public BSP Type 8 file
Ensure correct parsing
Ensure correct copying of the data
Ensure correct computation of states

Remote loads from MetaAlmanac hang forever in Python

Bug report

Describe the bug

In Python, the MetaAlmanac cannot successfully load the default remote files. It just hangs forever.

To Reproduce

data_path = Path(__file__).parent.joinpath("..", "..", "data", "default_meta.dhall")
meta = MetaAlmanac(str(data_path))
print(meta)
# Process the files to be loaded
ctx = meta.process() # --> This line will hang forever

Expected behavior

It should just download the files and get on with it, as it does in Rust.

Code to reproduce the issue

Cf. above

Platform

Linux and Github CI all platforms.

Additional context

None

Trajectory structure and event finding

High level description

New feature

I've put a substantial amount of work into the Trajectory type in Nyx. Quite frankly, it's extremely useful, and it should be ported to ANISE.

This will include event finding, which is very robust (Brent solver) and one of the main features of the trajectory structure.

To make this generic over an Orbit structure, I export the trait bounds as is recommended by PyO3: https://pyo3.rs/v0.20.0/trait_bounds .

One of the main limitations of using the Trajectory structure in Python in Nyx is that it cannot be pickled. This sounds like it shouldn't be a big deal, but Kedro (among other frameworks) will pickle data between computational steps. As such, I think that pythonize would be useful, where the serialized representation of the structure is used as a proxy. In Nyx, I rely on using the parquet intermediate file, but that isn't convenient.

Once I tackle nyx-space/nyx#86, I'll have a better idea on how to integrate Nyx's Spacecraft object with ANISE's Orbit object. Nyx relies on spacecraft trajectories in several spots (e.g. orbit determination of spacecraft instead of just of their orbits): that feature must remain.

Requirements

Store any number of states in a trajectory structure
Interpolate in between these states using the Hermite algorithm currently available for Type 13 SPK
Find events in a trajectory, including falling or rising edges
Support Pickling of the data for Python interaction

Test plans

Grab those from Nyx.

Design

Move the Nyx implementation in full.

Investigate return case of de440s_transform_verif_venus2emb

Bug report

Bug reports will lead to a stakeholder need report, and will need to be linked to this issue

Describe the bug

The lower half of de440s_transform_verif_venus2emb in tests/ephemerides/transform.rs is disabled. The SPICE data shows that both queries should be strictly opposite. ANISE shows that it isn't the case, and it only matches SPICE when transforming from IAU VENUS to EARTH ITRF93, but not the other way around.

I wonder if somehow the rotations need to be applied in a given order? I'm really confused about this one.

Note that this only applies if there are rotations involved. If the frame is J2000, there is no issue.

Expected behavior

ANISE return computation should be the exact opposite of the original computation.

Code to reproduce the issue

Uncomment the lower part of the code of that test in release 0.1 of ANISE.

Platform

Rust, Linux

Context should include gravity fields

These should be stored with C_nm and S_nm separate from each other, a flag specifying whether the coefficients are normalized, and (tbd) the uncertainty around these coefficients (which will allow tools to generate gravity clones, and provide lossless info from PDS)

ANISE Notebook tutorials for getting started

Description

Documentation type

Tutorial

Affected area(s)

Learn how to create a PCA file from TPC files
Learn how to query at different epochs learning how to use a time series

Possible solutions (optional)

Use https://github.com/chrisjsewell/pytest-notebook

Read SPICE DAF files

This is going to be a real pain in the neck, but we need to be able to read SPICE DAF data so we can copy the data from there directly into an ANISE file.

We should probably follow the code from jplephem. JPLEphem does not support all kinds of files (only Chebyshev IIRC), but as long as we can read the planetary ephemeris files and the Earth EOPs we should be good-enough. Best would be to support reading Hermite interpolation too.

Task list:

Create a helper module
mmap the input file
Allow seeking through the file
Use git-lfs to check-in the DE440.bsp file

Eventually, the ANISE platform should provide an API to automatically translate BSP files into ANISE files (something that responds to a simple wget should work).

Refactor as Cargo workspace + organizational stuff

Purpose: Nyx Space has much more visibility than "ANISE toolkit", has a little bit of brand notoriety already, and so far, I've written nearly all of the 10.5k lines of code. Nyx will also be the first user of the ANISE toolkit, so it makes sense to use it there. The license of ANISE will remain in Mozilla Public License.

This task should refactor the repo to be a cargo workspace with the following sub-folders:

anise : the core ANISE code in Rust
anise-cli : the ANISE client
anise-py : the Python bindings (PyO3?)
anise-cpp : the C++ bindings created via diplomat or something equivalent

This will be similar to the setup for pola.rs.

In summary, Rust workspaces are a powerful tool for organizing and building complex projects that consist of multiple crates. They allow you to manage multiple crates as a single unit, share code between crates, and make it easier to build, test, and distribute complex projects.
-- Perplexity.ai

Moreover, this issue should tackle the following:

Update the Matrix.org links to nyx-space/anise
Deprecate anise-toolkit organization
Update the Github issue templates to those from Nyx
Update the Github labels to those from Nyx or come up with new ones
Move the meeting notes into the repo: https://github.com/anise-toolkit/meeting-notes

Expose rotation parameters to Python

High level description

The current ANISE library offers functionality for handling rotation parameters (including fetching the Direction Cosine Matrix (DCM) and converting it to Quaternion or Modified Rodrigues Parameters (MRPs)) exclusively in Rust. This functionality needs to be exposed to Python users. The implementation should:

Requirements

Feature Parity: Ensure Python users have access to the same rotation parameters functionalities as Rust users.
Functionality: Include the ability to fetch the DCM of a given set of rotations and convert it to Quaternion or MRPs.
Integration: Seamlessly integrate with the existing Python modules in ANISE, maintaining consistency in usage and design.
Allow initialization and conversion into numpy arrays.

Test plans

To validate the implementation, the following test plans will be executed:

Copy the same unit tests from Rust into a Python test
Test initialization from numpy array
Test conversion to a numpy array

Design

Deciding whether to wrap the Rust implementation for Python use or rewrite the functionality in Python, considering performance and maintenance.

Support SPK DAF Hermite unequal time step

Currently, ANISE supports converting a Type 2 Chebyshev Position only SPK file into an ANISE file. Lots of BSPs use Hermite interpolation, so ANISE should be able to convert those as well.

From a publicly available Hermite interpolation BSP, convert to ANISE
Add a loading segment comparison test

Docs: https://naif.jpl.nasa.gov/pub/naif/toolkit_docs/C/req/spk.html#Type%2013:%20Hermite%20Interpolation%20---%20Unequal%20Time%20Steps

Support SPK Type 13 - Hermite unequal Time Steps

Documentation

Note: this is a set of discrete states which can be used, it seems, to build a Hermite interpolation scheme.

Purpose

Be able to convert a BSP file of Type 13 to an ANISE trajectory file.

SPICE organization

                                       +--------+
                                       |  x(1)  |
                                   /   +--------+
                                  /    |  y(1)  |
                                 /     +--------+
                                /      |  z(1)  |
   +-----------------------+   /       +--------+
   | State 1               |  <        |dx(1)/dt|
   +-----------------------+   \       +--------+
   | State 2               |    \      |dy(1)/dt|
   +-----------------------+     \     +--------+
               .                  \    |dz(1)/dt|
               .                       +--------+
               .
   +-----------------------+
   | State N               |
   +-----------------------+
   | Epoch 1               |
   +-----------------------+
   | Epoch 2               |
   +-----------------------+
               .
               .
               .
   +-----------------------+
   | Epoch N               |
   +-----------------------+
   | Epoch 100             | (First directory)
   +-----------------------+
               .
               .
               .
   +-----------------------+
   | Epoch ((N-1)/100)*100 | (Last directory)
   +-----------------------+
   | Window size - 1       |
   +-----------------------+
   | Number of states      |
   +-----------------------+

Test requirements

~~Find a public relevant BSP (Cassini?)~~ Build a BSP from GMAT
Ensure correct parsing
Ensure correct copying of the data
Ensure correct computation of states

Formal verification / property testing

What should be formally verified?
How should it be verified?

References:

https://github.com/project-oak/rust-verification-tools
https://github.com/AltSysrq/proptest
https://github.com/BurntSushi/quickcheck/ (and differences between quickcheck and proptest here)

Demo ASN.1 file format

The draft of ANISE uses Flatbuffers. The main benefit there is being able to read data without memory allocations (just mmap the data and seek through it). However, the DE421.bsp of 16.9 MB is converted into a 20.1 MB Flatbuffer file. This is 19% memory footprint increase.

The purpose of this issue is simply to track the ASN.1 conversion test.

Related issue: anise-toolkit/specs#10

CCSDS OEM conversion

High level description

CCSDS OEM is a standard for transferring orbital element data. As such, ANISE shall support reading these files and producing them from an ephemeris.

The API should also allow for converting an ephemeris into another frame prior to the serialization of the data in OEM format.

Requirements

Convert the OEM state data into an SPK with relevant metadata where possible.
Copy would-be discarded data into DAF comment section

Test plans

Generate a CCSDS OEM file from a public tool, or find one online, and convert that into an SPK file. Then make sure that when queried at the epochs present in the OEM file, the state data from the SPK matches that of the OEM file.
Test that optional fields do not cause the parser to fail.
Test that incorrectly formatted fields do not cause the parser to fail.

Design

Algorithm demonstration

N/A

API definition

A new module called ccsds will be added along with an oem submodule. All of the OEM parsing logic will be there.
The ccsds module will only be available with the ccsds crate feature, enabled by default, but not supported in no_std environments.

High level architecture

The text version of the OEMs will likely be parsed using an abstract syntax tree. Although, it is to be see whether that is an overkill since the text file is relatively simple. The XML version, if it is to be supported at all, will use an standard XML parser.

Ref. 1: https://createlang.rs/01_calculator/ast.html
Ref. 2: https://doc.rust-lang.org/stable/nightly-rustc/rustc_ast/ast/index.html

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.

High fidelity rotation information (binary PCK conversion)

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:

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.
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.

Rotation from source frame to parent frame when defined in planetary constant kernels
Rotation from source frame to parent frame when defined in BPC kernel
Rotation from any arbitrary frames defined either as PCK or BPC kernels which share a rotation node
Add transformation functions to rotation and translate between any arbitrary frame which share a rotation and translation node
Validation of PCK
Validation of BPC rotation
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

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.

Better error logging

Issue

At the moment, in part because this is very early stage, ANISE does not have good or useful logging.

Here's an example where fetching data failed:

 INFO  lib::ephemerides::translation_verif > Query Mercury J2000 -> Venus J2000 with TimeSeries [1899-12-31T23:59:27.816030720 UTC : 2099-11-03T22:26:41.217509894 UTC : 73 days 1 h 32 min 9 s 599 ms 999 μs 714 ns]
 ERROR anise::spline                       > [fetch] could not fetch 0-th MidPoint in spline 9133
thread 'ephemerides::translation_verif::exhaustive_de440_translation' panicked at 'called `Result::unwrap()` on an `Err` value: MalformedData(3141760)', tests/ephemerides/translation_verif.rs:325:22
stack backtrace:
   0: rust_begin_unwind
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/panicking.rs:142:14
   2: core::result::unwrap_failed
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/result.rs:1814:5
   3: lib::ephemerides::translation_verif::exhaustive_de440_translation
   4: core::ops::function::FnOnce::call_once
             at /rustc/a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
test ephemerides::translation_verif::exhaustive_de440_translation ... FAILED

failures:

failures:
    ephemerides::translation_verif::exhaustive_de440_translation

This is frankly not helpful.

Test plan

Build (or use an existing) malformed ANISE file and run any test to make sure that it returns something actually useful, including filename if possible
Build an index of errors on the website with resolution options.
Use a structured logged
Find a better error handling crate which is no-std compatible.

Support SPK Type 12 - Hermite Equal Time Steps

SPICE Documentation

Purpose

Be able to convert a BSP file of Type 12 to an ANISE trajectory file.

SPICE organization

                                       +--------+
                                       |  x(1)  |
                                   /   +--------+
                                  /    |  y(1)  |
                                 /     +--------+
                                /      |  z(1)  |
   +-----------------------+   /       +--------+
   | State 1               |  <        |dx(1)/dt|
   +-----------------------+   \       +--------+
   | State 2               |    \      |dy(1)/dt|
   +-----------------------+     \     +--------+
               .                  \    |dz(1)/dt|
               .                       +--------+
               .
   +-----------------------+
   | State N               |
   +-----------------------+
   | Epoch of state 1 (TDB)|
   +-----------------------+
   | Step size             |
   +-----------------------+
   | Window size - 1       |
   +-----------------------+
   | Number of states      |
   +-----------------------+

Test requirements

Find a public relevant BSP file
Ensure correct parsing
Ensure correct copying of the data
Ensure correct computation of states

Avoid static arrays when interpolating

High level description

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

Prior to calling hermite_eval, the Type 13 interpolation will copy the f64 data into compile-time defined arrays. This should not be required. In fact, with a clever use of a type backed by the memory-mapped data, we should be able to index directly into the underlying address space.

This would only save on the stack space of that function.

Requirements

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

Requirements answer the question: what does the system need to do? It does not answer the question of how does the system do this?

Test plans

How do we test that these requirements are fulfilled correctly? What are some edge cases we should be aware of when developing the test code.

Design

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

Algorithm demonstration

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.

Python interface

High level description

New feature

This will add a Python interface and automatically publish the package to PyPi. Python is the simplest way to reach lots of folks.

Requirements

Load files
Unload files (might not be trivial from Python!)
Query BSP and SPK files
Build orbits (needed for nyx-space/nyx#86)
Transform newly created states via loaded

Test plans

Add python tests that seemingly cover all of the functionality (I'm not sure that coverage analysis can be done since we're crossing the language barrier)

Design

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

Algorithm demonstration

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.

Rotations involved nutation and precession angles is wrong

Bug report

Describe the bug

When loading this specific data for BODY599, I compute the alpha, delta, and twist angles to be as follows on J2000 TDB (i.e. both d and T are strictly zero, and they are respectively the days past J2000 TDB and the centuries past J2000 TDB). In the following, the cos() and sin() functions expect degrees (not radians).

alpha = 268.056595 - 0.006499 T + 0.000117 * sin(99.360714) + 0.000938 * sin(175.895369) + 0.001432 * sin(300.323162) + 0.00003 * sin(114.012305) + 0.00215 * sin(49.511251) = 268.0914905766866 deg = 4.679079207142533 rad
delta = 64.495303 + 0.002413 T + 0.00005 * cos(99.360714) + 0.000404 * cos(175.895369) + 0.000617 * cos(300.323162) - 0.000013 * cos(114.012305) + 0.000926 * cos(49.511251) = 64.52434928998404 deg = 1.126162342817087 rad
w = 284.95 + 870.536 d = 284.95 deg = 4.973315703557842 rad

Note that the expression above is printed directly by the program, and I believe it matches the example from the PCK header documentation.

The complete list of nutation and precession angles at T=d=0.0 are computed as followed by ANISE (numbered here as J1-J15 instead of J1-J10 and Ja-Je as in the documentation):

J1 = 73.32 + 91472.9 T = 73.32
J2 = 24.62 + 45137.2 T = 24.62
J3 = 283.9 + 4850.7 T = 283.9
J4 = 355.8 + 1191.3 T = 355.8
J5 = 119.9 + 262.1 T = 119.9
J6 = 229.8 + 64.3 T = 229.8
J7 = 352.25 + 2382.6 T = 352.25
J8 = 113.35 + 6070 T = 113.35
J9 = 146.64 + 182945.8 T = 146.64
J10 = 49.24 + 90274.4 T = 49.24
J11 = 99.360714 + 4850.4046 T = 99.360714
J12 = 175.895369 + 1191.9605 T = 175.895369
J13 = 300.323162 + 262.5475 T = 300.323162
J14 = 114.012305 + 6070.2476 T = 114.012305
J15 = 49.511251 + 64.3 T = 49.511251

The DCM returned by PXFORM differs from that that returned by ANISE:

thread 'orientations::validation::validate_iau_rotation_to_parent' panicked at '#0 2000-01-01T11:58:55.816072704 UTC
got:
  ┌                                                                   ┐
  │    0.2287851464637683   -0.8803183511537116  -0.41556823432447604 │
  │     0.973371541024141   0.20058701392260808   0.11096257463622777 │
  │ -0.014324799539297372  -0.42988888153524274     0.902768159413333 │
  └                                                                   ┘

want:
  ┌                                                                   ┐
  │    0.2282653328760834   -0.8802481155891952   -0.4160026355789609 │
  │    0.9734895258323475   0.19994923179133894   0.11107856589263648 │
  │ -0.014597290902157951   -0.4303295942736501    0.9025537986129101 │
  └                                                                   ┘

err: 1.101e-3', tests/orientations/validation.rs:80:13

#0 @ 2000-01-01T11:58:55.816072704 UTC unit vector angle error for body 599 IAU_JUPITER: 1.5515228172636192e-2 deg

To be perfectly clear, if I use the PCK 08 file, or if I set the arrays BODY599_NUT_PREC_RA and BODY599_NUT_PREC_DEC to zero, then the DCM computed by ANISE matches that computed by SPICE's PXFORM function. So I've pinpointed my issue to the computation of the nutation and precession angles.

To Reproduce

Modify the validate_iau_rotation_to_parent test to load this file the PCK 00011 file, or enable Mercury in the PCK 00008 file.
Run the test, and observe it failing.

Expected behavior

The computation by ANISE should match that of SPICE's PXFORM.

Code to reproduce the issue

Refer to commit b8b97cf.

Platform

Linux, Rust

Additional context

I've contacted NAIF about this specific issue, seeking guidance.

Support SPK Type 14 - Chebyshev Unequal Time Steps

Documentation

Purpose

Be able to convert a BSP file of Type 14 to an ANISE trajectory file.

SPICE organization

Segment

      +============================+
      |         Constants          |
      +============================+
      |          Packet 1          |
      |----------------------------|
      |          Packet 2          |
      |----------------------------|
      |              .             |
      |              .             |
      |              .             |
      |----------------------------|
      |          Packet N          |
      +============================+
      |      Reference Epochs      |
      +============================+
      |      Packet Directory      |
      +============================+
      |       Epoch Directory      |
      +============================+
      |       Reserved  Area       |
      +============================+
      |     Segment Meta Data      |
      +----------------------------+

Record

   ------------------------------------------------
   |  The midpoint of the approximation interval  |
   ------------------------------------------------
   |  The radius of the approximation interval    |
   ------------------------------------------------
   |  CHBDEG+1 coefficients for the X coordinate  |
   ------------------------------------------------
   |  CHBDEG+1 coefficients for the Y coordinate  |
   ------------------------------------------------
   |  CHBDEG+1 coefficients for the Z coordinate  |
   ------------------------------------------------
   |  CHBDEG+1 coefficients for the X velocity    |
   ------------------------------------------------
   |  CHBDEG+1 coefficients for the Y velocity    |
   ------------------------------------------------
   |  CHBDEG+1 coefficients for the Z velocity    |
   ------------------------------------------------

Test requirements

Find a public relevant BSP (Cassini?)
Ensure correct parsing
Ensure correct copying of the data
Ensure correct computation of states

Python needs a `MetaAlmanac::default()` equivalent

High level description

Currently, in the ANISE Rust library, MetaAlmanac::default() provides a convenient way to download the latest planetary ephemerides, planetary constants, the Moon's high fidelity rotation parameters, and the daily JPL earth orientation parameters. This functionality is integral for users who rely on up-to-date celestial data for various computations and simulations.

Having this as a class method of Almanac or MetaAlmanac would prevent people from having to download a copy of latest.dhall.

Requirements

Add a latest() to MetaAlmanac which is equivalent to the default call.
Expose that function as a class method

Test plans

Check that the call loads the latest data by calling describe from Python (it's possible that this call does not work well with a fully loaded Moon BPC file for some reason!).

Design

No design change.

Publish profiling information

TODO: update this issue with the specific profiling data we want to publish: https://nnethercote.github.io/perf-book/profiling.html .

no_std support

We might want to evaluate, test and benchmark anise.rs for embedded targets.

It looks like all dependency crates support no_std (flatbuffers and hifitime has a feature flag and memmap2 isn't useful for non-hosted embedded so can be made optional).

The use of std within the (non-flatbuf-generated) crate code is minimal and seems to be easily replaceable with the core equivalent. Further evaluation may be needed for PR #8 when merged

Roadmap :

Replace all uses of std with core when possible
Add a default std feature flag that enables all std-based features
Write a few test-cases and benchmarks for embedded targets

[Python] Documentation notebook for Orbit (and Keplerian elements) and AER computations

Description

Add a Python notebook for documenting how to use the Orbit structure, including the basic two body propagation and changing the GM value of the frame for a given orbit. This should also include how to compute the azimuth, elevation, and range data of one SPK item compared to a randomly chosen object in a loaded SPK file.

Documentation type

Tutorial

Context to include planetary and spacecraft constants

One of the most frustrating things with BSPs is that planetary constants are separate from the rest of the file. One needs to load the PCK (planetary constant kernels). The advantage is the simplicity in quickly changing planetary constants ... but that is rarely done in analysis. Moreover, gravity fields or gravity clones are completely separate and are found on NASA PDS instead of NAIF. This adds to the complexity of finding relevant information.

Objectives

Read/write metadata to file

Add the specs draft 0.0.1 as a submodule
Write tests, create error enum
Generate the FBS files, check those in
Create binary to read/write metadata

Simple GUI for inspection

High level description

New feature

Inspection of SPICE/ANISE data requires either a tool that already exists, like NAIF's closed-source brief, or a custom implementation. It just isn't convenient. The purpose of this issue is to build a simple gui (egui?) that can load, inspect, and (eventually?) modify files as needed by the user.

Requirements

Inspect file type kind
Inspect start/stop of each segment in the file
Copy and see the CRC32 checksum

Test plans

Inspection does not need additional testing.
Modification of a file will need to be tested thoroughly, including by reloading a modified file and inspecting it

Hermite Series interpolation

Clone the polyfit module of Nyx into anise.rs.

As the copyright holder on the AGPLv3-license Nyx, I, Christopher Rabotin, hereby allow that part of the Nyx code to be copied and relicensed in MPL.

This will add the following functionality:

Build a Hermite series from a set of data
Store a series as a set of coefficients either as a generic polynomial or specifically as a Hermite Series
Evaluate these coefficients
Evaluate the desired components of a spline
Normalize the input (e.g. the time) within the bounds requested
Build an Anise Ephemeris table from an interpolated trajectory and store it in an Anise file
CLI tool that converts a set of CSV files into a single Anise file

Expected limitations:

The degree of the interpolation will need to be specified by the user.
Providing too little data for the provided interpolation degree will result in an error by default. In Nyx, this is handled by building a strict interpolation of the data, but this overfits it and leads to bad results between those interpolation points.

Chebyshev in-place evaluation

I strongly suspect that it should be possible to write the following algorithm with in-place computation of x, y, z, vx, vy, vz. I think that because it "looks" like it should work and because SPICE, I don't think, requires storing anything in an array.

Specifically, I think that the data from interp_t and interp_dt can be computed on the fly without having to store each of the data. That would save some memory. (Note that this current algorithm is basically a Rust rewrite of the numpy algo).

let pos_coeffs = &exb_states.position[index];

        let mut interp_t = vec![0.0; coefficient_count];
        let t1 = 2.0 * offset / interval_length - 1.0;
        interp_t[0] = 1.0;
        interp_t[1] = t1;
        for i in 2..coefficient_count {
            interp_t[i] = (2.0 * t1) * interp_t[i - 1] - interp_t[i - 2];
        }

        let mut interp_dt = vec![0.0; coefficient_count];
        interp_dt[0] = 0.0;
        interp_dt[1] = 1.0;
        interp_dt[2] = 2.0 * (2.0 * t1);
        for i in 3..coefficient_count {
            interp_dt[i] = (2.0 * t1) * interp_dt[i - 1] - interp_dt[i - 2]
                + interp_t[i - 1]
                + interp_t[i - 1];
        }
        for interp_i in &mut interp_dt {
            *interp_i *= 2.0 / interval_length;
        }

        let mut x = 0.0;
        let mut y = 0.0;
        let mut z = 0.0;
        let mut vx = 0.0;
        let mut vy = 0.0;
        let mut vz = 0.0;

        for (idx, pos_factor) in interp_t.iter().enumerate() {
            let vel_factor = interp_dt[idx];
            x += pos_factor * pos_coeffs.x[idx];
            y += pos_factor * pos_coeffs.y[idx];
            z += pos_factor * pos_coeffs.z[idx];
            vx += vel_factor * pos_coeffs.x[idx];
            vy += vel_factor * pos_coeffs.y[idx];
            vz += vel_factor * pos_coeffs.z[idx];
        }

hub.nyxspace.com authentication

The Hub is be a place to collaborate on ANISE files: upload, share, download.

The CLI tool shall allow uploading a proper ANISE file to the Hub.

Support of aberration corrections

The SPICE documentation on aberration corrections is very useful. All of this needs to be in version 1.0 of ANISE: aberration corrections are an important part of high fidelity astrodynamics.

Small velocity errors in light time correction and stellar aberration

Bug report

Describe the bug

In the de440s_translation_verif_aberrations test, it's clear that the velocity computation has a difference on the other of a few millimeters per second compared to SPICE. This is surprising given that it's the same algorithm and that the position error is down to machine precision (so 2e-16 km or 0.2 picometers).

The SPICE code indicates that only the position is corrected for, and not the velocity. However, correcting the velocity in the loop brings the error down to 5 mm/s from 7 mm/s.

To Reproduce

Look at test de440s_translation_verif_aberrations in commit 90b6f40.

Expected behavior

Error should be five orders of magnitude less than it currently is: SPK geometric query error is machine precision in position and 5 micrometers per second in velocity.

Platform

Linux

Additional context

Add any other context about the problem here.

Support SPK Type 18 - ESOC/DDID Hermite/Lagrange Interpolation

Documentation

Note: this should already be supported with the data structure. It's important to confirm that this format is supported prior to to version 1.0.

Purpose

Be able to convert a BSP file of Type 18 to an ANISE trajectory file.

Test requirements

Find a public relevant BSP (Cassini?)
Ensure correct parsing
Ensure correct copying of the data
Ensure correct computation of states

Context must be able to load all data types directly

High level description

Requirements

DataSet needs the bytes to loaded manually and must outlive the DataSet itself. This will likely require changing from &[u8] to Bytes, but there are likely lifetime issues to resolve there. Might be worth seeing if there's a solution by upgrading to the latest der version.
Context must be able to load the data directly instead of requiring the SPK and BPC to be loaded manually and then inserted into the context.

Test plans

How do we test that these requirements are fulfilled correctly? What are some edge cases we should be aware of when developing the test code.

Design

TBD

Algorithm demonstration

No change.

API definition

This will likely require changing the load_spk to include_spk and change the behavior of load_spk to be behind std only and load from a file path.

High level architecture

No significant change I think.

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.

Load a metakernel from its path

The purpose of this issue is to allow loading a Dhall-based metakernel for ANISE.

This will allow downloading the appropriate files wherever the path points to and store it locally, or try to load it from that path. This will not support the SPICE metakernel, cf. #123 .

Allow binary search of Lookup table

Due to the (minor) limitations of der's SequenceOf, it is not possible to get a pointer to the underlying array of items. This prevent searching is trivially with a binary search.

Trying to implement a binary search of the hashes requires, at the moment, copying the underlying index at every single call. This is slow.

This requires a solution to RustCrypto/formats#665.

Context should include spacecraft constants

Spacecraft constants shall be limited to what is typically done in 6-DOF analysis (Cd, Cr, A, inertial tensor, cg, etc.). Any very high fidelity attitude modeling would likely use its own file definitions. Table 6-2 of CCSDS Orbit Data Messages has an exhaustive list of potential spacecraft object parameters, although not all are relevant.

Look up spacecraft constants data from Context