nyx-space / nyx

Nyx is a high fidelity, fast, reliable and validated astrodynamics toolkit library written in Rust and available in Python
https://nyxspace.com
GNU Affero General Public License v3.0
187 stars 20 forks source link

Orbit management module #9

Closed ChristopherRabotin closed 6 years ago

ChristopherRabotin commented 6 years ago

This module should handle all orbit manipulation. The organization of this module isn't necessarily trivial, and I really need to think of a good way of handling this. The constructors in smd were not all that useful, especially for the control laws.

Another thing to consider is the size of state vector. The propagators handle VectorN, so it must be possible to provide a VectorN which represents the full state which needs to be propagated, may that be simply a position and velocity vector, or P, V and STM, or equinoctal propagation if that feature is desired. I also need to support frames, as defined in GMAT here.

ChristopherRabotin commented 6 years ago

To simplify the handling of states, I might simply have Orbit be an alias for Vector6<f64> with several added functions... although the problem with this approach is that I won't be able to store any computations or add the frames. So this is actually a bad idea. The frame information (cf. comment above) needs to be available in the struct itself in order to provide reference frame transformations and prevent bad math (e.g. adding two vectors defined in different frames). Moreover, in order to do many orbital computations, I need to store the gravity parameter mu. I initially think that the best approach here is to handle that via monomorphism, e.g. Orbit::<Earth>new(). I'm also considering adding the frame as a type parameter but I'm not sure what information from a Frame object would suffice to handle everything: hence it's likely that the frame will need to be passed as a parameter instead of a type parameter. Back to the propagator information, maybe I should simply have a into_state and from_state set of functions, but that would definitely add overhead to propagator calls. In fact let (t, state) = prop.derive(cur_t, &init_state, two_body_dynamics); would become something like let (t, state) = prop.derive(cur_t, orbit.into_state(), two_body_dynamics); orbit = Orbit::from_state(). That's kinda cumbersome. Moreover, the orbital elements should be as simple to get as in GMAT: orbit.inc() or orbit.mean_brower_inc(). Finally, I need consider how I'll handle the concatenation of these different states when I have a position, a velocity, the Cr, ground station positions, etc.

ChristopherRabotin commented 6 years ago

After a bit more thought, I think there should be different containers for different orbital elements, may these be Keplerian elements, Equinoctal or Brower Mean. There should also be a common trait which allows for the conversion of all of them so that an Orbit (default in position velocity with a given frame, eg True of Date) can be converted to a Mean Brower Short. I also think that the intermediate conversion via a state is the simplest solution, but that may be handled directly by the Orbit structure.

ChristopherRabotin commented 6 years ago

Currently working on this issue, but I'm concerned about how to handle frames. What do they provide? At the very least, they should explain whether they are inertial or not. But they should also provide, I think, information about where they are centered (Earth centered, Earth-Moon barycenter, etc.) so as to allow for correct reference frame transformation. Arguably, the orbit itself only needs to know the mu (or GM) parameter (in order to properly compute the orbital period, velocity, and other stuff). That's how it is in GMAT somewhat: Earth_TOD, etc. Implementing that however, would require implementing celestial bodies as well, or at least a draft of them (as an enum ?).

ChristopherRabotin commented 6 years ago

I'm going to ditch the work done on this branch so far. I think that before writting frame manipulation code, I need to learn how to properly load a BSP file. From there, I'll have a better understanding as to what kind of informatiocan be in there, and how it might affect reference frame transformations. Specifically, I think the current idea of having "reference frames" which can be TOD or Julian etc. and be Keplerian, Equinoctal, etc. is a good idea, but it does not solve the problem of changing the origin of a position & velocity vector into its position into another frame. Once that's handled, I will be able to better handle the reference frame transformation.

Moreover, I hope to be able to provide a DE file in this repo, but the latest DE436 is larger than the github limit of 100 MB. So I might trim it to start at 1976 and go until 2050 or something (I believe the default version is 1900 to 2100). Moreover, note that this will require the implementation of an interpolation code, which I'll likely implement using the same algorithm as GMAT (although I might check out other algorithms which may be faster [maybe there should be a way to choose which interpolation scheme to use?]). Finally, this work will add the dependency on hifitime.

ChristopherRabotin commented 6 years ago

In other words, this issue depends on #4 .

ChristopherRabotin commented 6 years ago

Similarly to how I am implementing #5 , I'll work on this issue in different steps, as follows:

As evident from this comment, only the first step as somewhat been thought through.

ChristopherRabotin commented 6 years ago

As I'm currently coding this, I think that the state should also include a time, based on hifitime of course since it supports leap seconds. This information could also be used in order to convert to a TOD frame by calling "state.tod()" which would return a new state. Maybe could that struct know whether or not it was already converted to a tod to prevent usage errors (eg initialized from a tod state and calling tod again, one would apply both rotations). If that is the selected design, then the celestial body trait needs to include the relevant rotation matrices. By default, they should be identity. I'll have to check if these rotation matrices depend on anything more than time and a fixed nutation rate depend on the planet, or more than that.

ChristopherRabotin commented 6 years ago

Status update:

ChristopherRabotin commented 6 years ago

Closing this as all the tasks listed here are now separated into subtasks.