Hi Evan, Evan Ward <evan.ward@nrl.navy.mil> a écrit :
Hi Guillaume, On 08/10/2015 07:18 PM, Guillaume Obrecht wrote:Dear developers, My work on Orekit for the SOCIS 2015 could possibly imply some changes in basic elements of Orekit. I hence would really appreciate if you could read through this analysis and tell me what you think about it, and what options you would prefer to see implemented. Thank you in advance for your time. *_SOCIS 2015:_* I am working for the SOCIS 2015 on making the modifications necessary to allow Orekit to propagate orbits in non-inertial reference frames. The goal is to be able to deal with problems such as: * trajectory about an L2 point, * swing-by about Jupiter in different reference frames (EME2000, ICRF, inertial centred on Jupiter), * Earth orbit in rotating reference frame.I'm curious, what is the use case for propagation in a ECEF frame? It is certainly interesting academically, but I can't think of a case where I would use it.
It is a case I proposed to Guillaume. It has two different uses:
- as a validation method for the inertial forces
- some Earth observing spacecraft provide their data already in
Earth frame (typically because they use GPS on-board), so it
seems better to remain in this frame for orbit to terrain mapping.
We encountered this in the Sentinel-2 mission for example, and
currently we convert from ITRF to EME2000 at meta-data loading
(introducing a dependency to Orekit and IERS there), only to
convert back to ITRF in another software layer (in Rugged ...)
Luc
To do so, several things need to be done: * Allowing the definitions of Orbit and SpacecraftState in non-inertial reference frames, * Allowing the definition of orbits without a central body, * Creation of an inertial forces model, * Allowing the orbit propagation in non-inertial reference frames. *_Work progress:_* I already completed the following tasks, and the modifications uploaded on https://www.orekit.org/forge/projects/socis-2015/repository : * new inertial force model class (/src/main/java/org/orekit/forces/inertia/InertialForces.java) taking as argument an reference inertial reference frame to use to compute the forces. * new orbit class(/src/main/java/org/orekit/orbits/CartesianOrbitWithoutCentralBody.java) allowingto define an orbit with no central body (mu=0) with all method using mu redefined (this class inherits from CartesianOrbit). * Temporary commenting of some lines to prevent Orekit from throwing exceptions if the reference frame is not pseudo-inertial. I attached to this email a very simple script allowing to test the new orbit class and the new force model.I think the ability to add inertial forces will be a valuable addition to Orekit.*_Decisions to make for the next steps:_* Now, these changes have been quite conservative so far, but in the next steps, I will probably need to shake up the inheritance and aggregation structure of basic elements such as Orbit and SpacecraftState. In the current state, these are defined as such: data class P, V, A --> PVCoordinates P, V, A, date --> TimeStampedPVCoordinates P, V, A, date, frame --> [not defined] P, V, A, date, frame, mu --> Orbit and sub-classes P, V, A, date, frame, mu, attitude --> SpacecraftState TimeStampedPVCoordinates inherits from PVCoordinates. Orbit aggregates TimeStampedPVCoordinates. SpacecraftState aggregates Orbit . In my current proposal, the "orbit without a central body" inherits from Orbit, which causes issues as many methods of Orbit do not make sense anymore with no "mu" (getA(), getKeplerianPeriod(), etc...). There are two options to deal with the problem, and both consist in creating a new class containing the following data: P, V, A, date, frame. The doubt is on where to put it in the hierarchy. /_Option 1: In the PVCoordinates/TimeStampedPVCoordinates tree_/ The new class (TimeStampedFramedPVCoordinates or FramedPVCoordinates) would extend TimeStampedPVCoordinates to add the methods that are frame-dependent. /_Option 2: Above the Orbit class_/ Currently, my new class is *below *Orbit (inheritance). Creating a new class *above *instead would solve a lot of problems. It could be called TrajectoryState for instance. Then Orbit would inherit/aggregate TrajectoryState to add the methods related to the central body. In both cases, SpacecraftState would be modified to deal with the new class.I think you may have two different problems that may be better addressed separately. Currently the Orbit classes represent solutions to the two body problem (TBP). Your use cases for L2 and a swing-by would seem to be instances of the circularly restricted three body problem (CRTBP). So in these cases it would make more sense to have two central bodies instead of zero. Perhaps someone with more experience in this area would know if there are solutions the CRTBP that would make sense to use in the shiftedBy() method. Without any central bodies the object would just have PVA coordinates and the shiftedBy() trajectory would produce a parabolic trajectory. I wouldn't classify this as an orbit, but as a linearizion / series expansion at a particular point. So I think option 1 is the way to go. IIUC this is the same as option 2 to create a new superclass. Perhaps AbsolutePVCoordinates would be a nicer name for the class. This recalls some earlier discussions we had started on the purpose of the orbit classes and whether it should have osculating or mean elements. I think the orbit classes provide a useful trade off between propagation complexity and accuracy by using Kepler's equation for extrapolation. If there isn't a similar equation for these new types of orbits then I think it would be better to not classify them as orbits and instead use PVA coordinates. This would mean that SpacecraftState would have to be updated to no longer depend on the Orbit class. I think it would also be good to keep in mind that most users likely won't use these new features so ECI propagation and orbits should still be easy after the update. Best Regards, Evan*Could you give me your impressions about these options, * *and "vote" for the one you prefer?* Kind regards, Guillaume Obrecht