Re: [Orekit Users] Attitude transition issues.

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

Tom Walford <tom@open-cosmos.com> a écrit :

> Hi All,

Hi Tom,

> I have been working on the basic simulation of an AOCS, and to do that I
> have been defining attitude laws and then switching them on specific events
> using event detectors and the attitudesSequencer class.
>
> When the switch event occurs, it appears that there is some form of spike,
> as shown in AOCSspike1.png and AOCSspike2and3.png, which are from the AOCS
> software developed. In these images, the dark blue line shows when the
> event occurs, the other coloured lines represent the z component of the
> attitude using different transition times. If I had zoomed in further for
> spike1, it would show a linear angular shift of 180 degrees in 3 seconds,
> far beyond the capabilities of most AOCSs.
>
> Looking at  the spike at the end of the pass in AOCSspike2and3.png, it
> becomes obvious that the spike is not a rapid shift back to the original
> curve, as immediately after the line begins to rise back towards the
> original shifted attitude. From there it later falls to rejoin the original
> pointing law.
>
> My current working theory is that there is some kind of integrator failure
> between the two laws causing a large change in attitude, at which point the
> attitude law attempts to rectify the situation, however I am open to all
> other ideas.
>
> As this is part of a large project, I copied and pasted the relevant code
> into a SSCCE and built a similar propagator to the one used in the project,
> and a similar thing can be seen in the second transition as shown in
> SSCCEspike. This SSCCE is included in the email in case this helps somehow.
> If the attachments are unavailable, they are included on github here:
> https://github.com/TommyOC/SSCCEaocs.git
>
> I would appreciate any suggestions as to the cause of these spikes and any
> potential solutions.

I have quickly looked at your simulation. There is at least two programming
problems, but you also probably found a bug in Orekit!

The first programming problem is the following one: when you create  
the TargetPointing
attitude law, you don't give it the real ground station position in  
Earth frame,
but the unit vector corresponding to Nadir direction. In the startSim  
method, you
should replace the first argument to sequencer.targetPoint
        gs.getLocation().getNadir()
with
	earthBody.transform(gs.getLocation())


The second programming problem is when you display the Z axis coordinates in
the step handler. You should replace
  Vector3D pointing = currentState.getAttitude().getRotation().applyTo(ones)
with
  Vector3D pointing =  
currentState.getAttitude().getRotation().applyInverseTo(Vector3D.PLUS_K)
and print all three coordinates of the pointing vector

The bug is in fact a known limitation that has been plaguing us since years
and that we cannot really fix, at least not without removing a feature.
There is a scheduling issue between calls to step handlers and events  
handlers.
during one step, the events that may end the step are triggered first, and
once the propagators knows if it should or not end the propagation due  
to the event,
then it calls the step handler on the step just computed.

Here, you have a variable step size integrator that is allowed to  
compute large
steps at once, up to 100 seconds. What seems to happen is that the  
event is detected
and processed, some variables are reset inside the attitude sequence and then
the step handler is called, which can reference times up to 100 seconds in the
past (as the step has hust finished). As you use an  
OrekitFixedStepHandler, the
variable step is sampled and your handler is called several times in  
raw, but in
fact it already nows about the upcoming switch and it get confused in  
the interpolation
between the previous and current mode.

One workaround is to reduce the max step size of the integrator to  
something much
closer to the sampling rate you want in the step handler. It should  
smooth things a
little, but you will still get some issues in the now small step just  
before the switch.

Could you register an issue in the bug tracker at  
<https://www.orekit.org/forge/projects/orekit/issues>?
You will need to register to the forge in order to be allowed to open  
a new issue.
I'll have a look to see if I can at least make AttitudeSequence aware  
it can be
called out of sync.

best regards,
Luc

> Kind regards,
>
>
> --
>
> Tom Walford
> Software Engineer
>
> Open Cosmos Ltd. | Company Registration no: 09704443 (England) | VAT
> Registered: 225 9566 81 | RAL Atlas Building R27 | Fermi Avenue | Harwell
> Campus | OX11 0QX | Oxfordshire | United Kingdom