Skip to content

Ephemeris and navigation API upgrade#398

Draft
gwbres wants to merge 13 commits intomainfrom
ephemeris_upgrade
Draft

Ephemeris and navigation API upgrade#398
gwbres wants to merge 13 commits intomainfrom
ephemeris_upgrade

Conversation

@gwbres
Copy link
Copy Markdown
Collaborator

@gwbres gwbres commented Nov 22, 2025

  • improve Solver API
    • remove code duplicates from previous PRs
    • Improve BDS APi
    • improve terms definition (for example: longan, compared to raan in ANISE)
    • generalize _km position and velocity API (facilitates bridge to ANISE)
  • improve ANISE bridge
  • inquire Glonass / SBAS integration method
  • Add test for all orbit cases

Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
@gwbres gwbres self-assigned this Nov 22, 2025
@gwbres gwbres added documentation Improvements or additions to documentation enhancement New feature provided navigation labels Nov 22, 2025
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
@gwbres
Copy link
Copy Markdown
Collaborator Author

gwbres commented Nov 22, 2025

@ChristopherRabotin,

now I understand things "much better", GNSS (GPS and alike) use a modified (more realistic)
orbital model that integrates harmonic corrections (Cis, Cic... from the radio message) to the classical keplerian model.

This allows to fit the use case of orbiting Earth precisely.
Because ANISE does not know of Earth correction terms, we already have converged to the only possible workflow, that is,
to solve using the classical GPS solver, and eventually switch to ANISE using ::from_position.

@ChristopherRabotin, while ANISE applies to all Orbits in theory, it seems like only an adapted model would provide precise solutions. Yet you have used ANISE with low/medium earth orbits. Do you have a notion of how "far" from truth these solutions are ? Do you think it could have value to introduce a new Orbit constructor, that would be ::from_keplerian augmented with harmonic corrections ?

Side note, starting from this patch, you will find an API that is much similar to ANISE, for example I renamed many fields to match ANISE, for example, sqrta becomes sma_m, aop_rad etc..

Side note (b), I will provide Glonass and SBAS (GEO) integration method with this patch, the ANISE bridge still applies, so it will provide an interesting method to move to ANISE from a geostationnary object

@ChristopherRabotin
Copy link
Copy Markdown
Contributor

I am not very familiar with the concept of harmonic corrections to Keplerian elements. Is it related to mean orbital elements, which smooth out the variations in the Keplerian elements? The orbit structure in ANISE represents a unique point in space and time so I'm not inclined to add parameters to that constructor, however if there is a specific mean orbital element theory you want to initialize with, we can do that.

Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation enhancement New feature provided navigation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants