Closed ChristopherRabotin closed 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.
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.
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 ?).
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.
In other words, this issue depends on #4 .
Similarly to how I am implementing #5 , I'll work on this issue in different steps, as follows:
Orbit
(or OrbitalElements
) which can be initialized from different ways of defining an orbit: Cartesian position and velocity,Keplerian OEs, Equinoctal and Mean Brower Short. From that object, it shall compute and provide the Mean Brower Short elements, the orbital elements in Keplerian and Equinoctal, the position and velocity. I'm not very familiar with the Brower elements, so I'll have to see how GMAT implements it, and how to convert from Brower short to other elements. I'm also not entirely sure how I'll avoid recomputation of the same information knowing that Rust does not support uninitialized values.CoordinateFrame
trait instead of a Planet
trait: to be seen.as_seen_from(another_spacecraft)
or as_seen_from(Mars.position_at_time(t))
.As evident from this comment, only the first step as somewhat been thought through.
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.
Status update:
Closing this as all the tasks listed here are now separated into subtasks.
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.