Attitude dynamics integration

Good afternoon,

I’m currently writing an attitude dynamics model to be integrated by the propagator. It implements the AdditionalEquations interface and the integration performs correctly. It also implements the AttitudeProvider interface to provide the attitude based on those integrated additional states. In order to achieve this, I need to access the full spacecraft state in the getAttitude() method (see https://www.orekit.org/mailing-list-archives/orekit-users/msg00175.html).

Do you know a workaround or a way to build a bridge between the AdditionalEquations and the AttituteProvider ?

Thanks in advance,

Paul Dewost for Exotrail

Hi @PaulDewost

Sorry for the late answer.

This is a difficult task that I don’t think is possible with the current version of Orekit. To access the spacecraft state in the getAttitude() method, the method signature must be modified. However, I don’t know if it’s a good idea.
Can your attitude model implement both interface (i.e. AttitudeProvider and AdditionalEquations) ?

Best regards,
Bryan

Hi @bcazabonne,

My model is already implementing both interfaces.
The problem is to get the additional state inside the getAttitude() method at the exact right date.
I’ve tried to also implement the StepHandler interface and store the value of the additional state each time a propagation step is performed, but it does not work well because the time steps are usually way too big to simulate attitude dynamics accurately…

Best regards,

Paul

Instead of storing the state, you could try to store the interpolator, but this implies that you implement OrekitStepHandler and not OrekitFixedStepHandler. In fact, I doubt this will work and it may generate infinite recursion: the step handler manages state that includes attitude so we have a chicken and egg problem.

Hi @luc,
Thanks for your reply. Indeed you are right, implementing OrekitStepHandler might end up in some kind of infinite recursion. I will look into it.
Best regards,
Paul

Some more thoughts about this problem.

State handling is quite involved in Orekit. State contains orbit, attitude, mass and additional states. Additional states may be constants that are copied around, values evaluated from analytical equations, or values obtained by ODE integration (the last one only for numerical and DSST propagators which are integration-based).
During propagation, each state is built up progressively. Here is what happens for integration- based propagators:

  1. position-velocity is computed by integrating space dynamics equations
  2. attitude is added using attitude provider (in OsculatingMapper.mapArrayToState or MeanPlusShortPeriodicMapper.mapArrayToState)
  3. constants (unmanaged) additional states are added (in AbstractPropagator.updateAdditionalStates)
  4. analytical additional states are added (in AbstractPropagator.updateAdditionalStates)
  5. additional states managed by integrated equations are added

So attitude is handled early in this process. Even if we were to pass the SpacecraftState to AttitudeProvider it would probably not help in your case because the additional states have not been included yet.

What I could suggest (but it is only a wild guess, I did not check it works or not) would be to add a 6th step that would apply a user-provided post-processing object to the state before it is returned. This post-processing would simply take a state and return a possibly modified state. In your case, you could have the attitude really handled there, overriding the attitude used in earlier step, perhaps by simple interpolation, or using a crude model, or reusing data extracted the previous call if you use the same object as attitude provider and as state post-processor.

I did not check we could insert this everywhere properly (for example, is it taken into account before force models are called in the core of the integration, I don’t know yet).

Such a new feature could be added in 10.3 if required.

What do you think of this proposal?

Hi @luc,
Thank you for the idea !
We will definitely look into this in the coming days. Anyway this would be a very nice feature to add in Orekit 10.3, as it would allow many other developments of this kind.
I will keep you informed of our progress on this thread.
Best regards,
Paul