Hello Evan,
Thank you for your feedback.
The first option also has my preference. I agree that such object barely classifies as an orbit. On top of PVA coordinates, the new class would also include a frame, possibly non-inertial. Orbit would be a particular case where a body is present. It would then be possible in the future to create new kind of orbit classes (CRTBP or others) based on this more general AbsolutePVCoordinates class.
I imagine that the shiftedBy() trajectory could, depending on the frame defined, take into account the inertial forces.
I do not think that the new features would change a lot the working of the existing ones. SpacecraftState could be modified to accept an Orbit OR an AbsolutePVCoordinates.
Kind regards,
Guillaume
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)
>> allowing
>> to 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
>>