-
Notifications
You must be signed in to change notification settings - Fork 32
Project RoadMap
The foundational input data to sensor models are the interior and exterior orientation. The ephemeris abstraction library (EAL) is designed to provide a standard interface to spacecraft position and pointing information. Within the planetary science community, most position and orientation information is provided by the NAIF SPICE toolkit and associated data. This data delivery mechanism is not though universal. For example, mission teams can provide updated position and orientation information in plain text formats. Therefore, it is desirable to decouple the data representation of exterior orientation (position and pointing) from the interface through which sensor models can access said data. EAL seeks to fulfill this goal.
We are aware of multiple libraries that supply an API to planetary exterior orientation information: (1) NAIF SPICE Toolkit, (2) ISIS3 via the SpicePosition and SpiceRotation classes, and (3) VICAR. These libraries are widely used by the planetary science community. We suggest that they do not fulfill all of our design goals for an abstract ephemeris library. First, in the case of ISIS3 and VICAR, the NAIF SPICE C (or FORTRAN) APIs are being wrapped. Therefore, the input data types supported for exterior orientation are those available from the SPICE Toolkit.
In designing EAL, we have identified three primary motivators. (1) We seek to break the tight coupling to the SPICE Toolkit for all input data types. As described above, exterior orientation data are normally shipped as SPICE kernels, but this is not a universal data transmission format. It can, for a number of reasons, be desirable to use a different data source for operations involving exterior orientation. (2) In wrapping the SPICE Toolkit a user accessible mid-level API is not being made available by either ISIS3 or VICAR. If we assume that the SPICE Toolkit provides the lowest level interface to SPICE kernels, it is desirable to have a mid-level library to handle operations such as interpolation between discrete SPICE contained ephemeris points. A library at this level could also be utilized to perform analysis of the impact of interpolation (as required by sensors where the discrete ephemeris points are too sparse to allow for sufficiently accurate look-vector intersection with some surface) on the exterior orientation of a sensor over some time interval. This capability is nominally available with the ISIS3 library, but the API is not exposed in a user accessible way. Additionally, the size of the ISIS3 library requires that significant other capability be installed to gain access to the components designed to represent and interact with exterior orientation. (3) Given the previous, we also seek to decouple the current ISIS3 SpicePosition and SpiceRotation classes from the ISIS3 library, create a standalone library (EAL), and then reintegrate the EAL library as an ISIS3 dependency. This final motivator is part of a larger desire to modularize the ISIS3 code base for reasons of usability and maintainability.
We see multiple potential integration points for a mid-level EAL style library into our software portfolio. First, EAL can provide the foundational exterior orientation data representation and manipulation interface for the ASC Core (ISIS3) software package. We suggest that EAL will become a dependency of the ISIS3 library. Second, the data represented by EAL is required to support the generation of image support data (isd) files for the ASC Community Sensor Model (CSM). This capability is wrapped and exposed via the pfeffernusse library as a micro-service. Third, we anticipate the ability to create exterior orientation analysis capabilities on top of EAL. For example, the ASC sunkern repository contains Jupyter notebooks with SPICE analysis and visualization capability. These notebooks are making low-level SPICE calls where an abstract interface library (EAL) would allow down stream developers to focus more on analysis and visualization and less on the mechanics of how to access SPICE data.
- Repo creation and tooling deployed: This includes setup for buildings, dependency management, testing (gtest), continuous integration (TravisCI), continuous deploy (Anaconda) and documentation.
- Initial library stub: The initial development of an MVP that, using the EAL library is able to take in the SPICE data necessary to parametrize a Mercury MDIS NAC or WAC sensor and expose said data via the defined EAL interface.
- RFC and Project Documentation:
- Demo: Documentation, RFC, basic implementation on the C++ side
- Implement Python I/O: Create the I/O and file parsing module for a non-spiceinit'd cube and a spiceinit'd cube.
- Read a non-spiceinit'd cube
- Read a spiceinit'd old cube
- Read a spiceinit'd new cube (JSON)
- Demo: Demo the I/O module reading and writing EAL compliant data.
- C-API to the Python Side that EAL consumes: This is the code that supports the interface between EAL and the Python side.
- Demo: EAL is able to return something
- ISIS Integration of the CTX prototype: Determine how to interface the EAL library with ASC Core (ISIS3) replacing the SpicePosition and SpiceRotation classes or turning said classes into the necessary wrappers to make use of EAL. Create a lightweight functional test to do this.
- ISIS works. Working test suite. Working spiceinit. Working map projection. Working bundle adjustment.
- SPICE Interface: Decide are we are making SPICE calls through this library, is the user making SPICE calls and passing results to this library? What happens when this library points at a JSON file? What about a PDS label? Where does the responsibility fall for dealing with kernels (or other challenging data sources)?
- Demo: Updated RFC and reading spice data from PDS images via the EAL interface or an env. that uses the EAL library.
- CSM Integration of the MDIS prototype:
- Instantiate a CSM sensor, do some I2G and G2I in a Jupyter notebook.
- Read the raw data from the SPICE kernels: On the Python interface side, be able to access the raw kernel data so that we can be sure that no interpolation is occurring.
- Demo: Have a jupyter notebook that plots some raw data
- Write a spice kernel: Take bundle results from the functional test above and write the results to the correct kernels / types.
- Demo: Updated mosaic or something. Kernels on disk. Updated values visible in the reader.
| Start Date | Stop Date | Target Deliverable |
|---|---|---|
| Oct. 1 2018 | Jan. 30 2019 | RFC issue; ALE 0.1 release with Python I/O, C++ computation library, and ISIS3 integration |
| Spring 2019 | Late Spring 2019 | Integration of RFC comments, raw kernel reads, kernel writing, TDB |
Architectural and interface specification can be found in the Design RFC.
User stories are one tool being used to capture the desired functionality of the library. User stories are available as their own wiki page.