Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TLE parsing and SGP4 propagation #160

Open
4 tasks
ChristopherRabotin opened this issue May 31, 2023 · 3 comments
Open
4 tasks

TLE parsing and SGP4 propagation #160

ChristopherRabotin opened this issue May 31, 2023 · 3 comments
Labels
Interface: Python Interface: Rust Kind: New feature This is a proposed new feature Priority: normal Status: Design Issue at Design phase of the quality assurance process Topic: Mission Design

Comments

@ChristopherRabotin
Copy link
Member

High level description

Nyx currently does not support the Two-Line Element Set (TLE) format and Simplified Perturbations Model (SGP4), both of which are commonly used in satellite tracking and collision avoidance tasks. Despite not being a high fidelity propagation, TLE parsing and SGP4 propagation are frequently utilized in space mission planning and operations. This feature is increasingly requested by users, showcasing its relevance for the Nyx project. Implementing this feature will broaden the usability of Nyx for users working in these specific use-cases and potentially attract new users who primarily rely on TLE and SGP4.

I don't seem to be able to figure out how to load and propagate a TLE, would anyone mind a code snippet or point me in the right direction?

Originally posted by @hambone01 in #159

Requirements

  • SGP4 propagation: The system should be able to propagate orbital states using the SGP4 model.
  • TLE parsing into an Orbit structure. Special attention should be paid to potential issues related to the TLE reference frame. Parsing into an Orbit structure will allow comparing SGP4 and high fidelity models.

Test plans

  • Consider integrating the SPG4 crate as most (all?) of that work is done there and it benefits from verification and testing. Optionally recommend switching from Chrono to Hifitime to maintain the same precision the rest of Nyx has in time.
  • If opting for this solution, review the current test plans and open pull requests for more tests if needed.

Design

The propagation should be available in Rust and Python. This would likely live in another module to not mix mission design and SGP4 (maybe the cola module would be fit for this so it could include other collision avoidance methods).

graph LR
A[TLE String] --> B[Orbit object]
B --> C[SGP4 Propagation]
C --> D[Nyx Trajectory]
Loading
@Thomas-Oz-Dunn
Copy link

I have some TLE parsing in Rust here at line 231, though it maps into my Orbit struct that uses keplerian parameters instead of state vectors, but it would be a relatively easy conversion.

I'm less familar with SGP4 interfacing, though.

Perhaps, for the good of the community, I throw my TLE parsing into a standalone lib for us both to import since it is such a common starting point for developers that may not want either of our entire packages. Have it extract just the values present, no further calculations.

@Thomas-Oz-Dunn
Copy link

I have some TLE parsing in Rust here at line 231, though it maps into my Orbit struct that uses keplerian parameters instead of state vectors, but it would be a relatively easy conversion.

I'm less familar with SGP4 interfacing, though.

Perhaps, for the good of the community, I throw my TLE parsing into a standalone lib for us both to import since it is such a common starting point for developers that may not want either of our entire packages. Have it extract just the values present, no further calculations.

TLE parser

https://crates.io/crates/parse-tle

https://github.com/Thomas-Oz-Dunn/parse-tle

Mapped the fields into a simple struct of each parameter, that way we each can have our own derived Orbit class.

@ChristopherRabotin
Copy link
Member Author

Nice, thanks! I will let you know when I start working on this.

For the epoch calculations, you may wish to use hifitime since it computes the Julian dates directly and performs nanosecond precision duration arithmetics.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Interface: Python Interface: Rust Kind: New feature This is a proposed new feature Priority: normal Status: Design Issue at Design phase of the quality assurance process Topic: Mission Design
Projects
None yet
Development

No branches or pull requests

2 participants