Serializable
, AttitudeProvider
public class AttitudesSequence extends Object implements AttitudeProvider
Only one attitude provider in the sequence is in an active state. When one of the switch event associated with the active provider occurs, the active provider becomes the one specified with the event. A simple example is a provider for the sun lighted part of the orbit and another provider for the eclipse time. When the sun lighted provider is active, the eclipse entry event is checked and when it occurs the eclipse provider is activated. When the eclipse provider is active, the eclipse exit event is checked and when it occurs the sun lighted provider is activated again. This sequence is a simple loop.
An active attitude provider may have several switch events and next provider settings, leading to different activation patterns depending on which events are triggered first. An example of this feature is handling switches to safe mode if some contingency condition is met, in addition to the nominal switches that correspond to proper operations. Another example is handling of maneuver mode.
Note that this attitude provider is stateful, it keeps in memory the sequence of active underlying providers with their switch dates and the transitions from one provider to the other. This implies that this provider should not be shared among different propagators at the same time, each propagator should use its own instance of this provider.
The sequence kept in memory is reset when resetActiveProvider(AttitudeProvider)
is called, and only the specify provider is kept. The sequence is also partially
reset each time a propagation starts. If a new propagation is started after a first
propagation has been run, all the already computed switches that occur after propagation
start for forward propagation or before propagation start for backward propagation will
be erased. New switches will be computed and applied properly according to the new
propagation settings. The already computed switches that are not in covered are kept
in memory. This implies that if a propagation is interrupted and restarted in the
same direction, then attitude switches will remain in place, ensuring that even if the
interruption occurred in the middle of an attitude transition the second propagation will
properly complete the transition that was started by the first propagator.
Modifier and Type | Class | Description |
---|---|---|
static interface |
AttitudesSequence.SwitchHandler |
Interface for attitude switch notifications.
|
Constructor | Description |
---|---|
AttitudesSequence() |
Constructor for an initially empty sequence.
|
Modifier and Type | Method | Description |
---|---|---|
<T extends EventDetector> |
addSwitchingCondition(AttitudeProvider past,
AttitudeProvider future,
T switchEvent,
boolean switchOnIncrease,
boolean switchOnDecrease,
double transitionTime,
AngularDerivativesFilter transitionFilter,
AttitudesSequence.SwitchHandler handler) |
Add a switching condition between two attitude providers.
|
<T extends org.hipparchus.RealFieldElement<T>> |
getAttitude(FieldPVCoordinatesProvider<T> pvProv,
FieldAbsoluteDate<T> date,
Frame frame) |
Compute the attitude corresponding to an orbital state.
|
Attitude |
getAttitude(PVCoordinatesProvider pvProv,
AbsoluteDate date,
Frame frame) |
Compute the attitude corresponding to an orbital state.
|
<T extends org.hipparchus.RealFieldElement<T>> |
registerSwitchEvents(org.hipparchus.Field<T> field,
FieldPropagator<T> propagator) |
Register all wrapped switch events to the propagator.
|
void |
registerSwitchEvents(Propagator propagator) |
Register all wrapped switch events to the propagator.
|
void |
resetActiveProvider(AttitudeProvider provider) |
Reset the active provider.
|
public AttitudesSequence()
public void resetActiveProvider(AttitudeProvider provider)
Calling this method clears all already seen switch history, so it should not be used during the propagation itself, it is intended to be used only at start
provider
- provider to activatepublic void registerSwitchEvents(Propagator propagator)
This method must be called once before propagation, after the
switching conditions have been set up by calls to addSwitchingCondition
.
propagator
- propagator that will handle the eventspublic <T extends org.hipparchus.RealFieldElement<T>> void registerSwitchEvents(org.hipparchus.Field<T> field, FieldPropagator<T> propagator)
This method must be called once before propagation, after the
switching conditions have been set up by calls to addSwitchingCondition
.
T
- type of the field elementsfield
- field to which the elements belongpropagator
- propagator that will handle the eventspublic <T extends EventDetector> void addSwitchingCondition(AttitudeProvider past, AttitudeProvider future, T switchEvent, boolean switchOnIncrease, boolean switchOnDecrease, double transitionTime, AngularDerivativesFilter transitionFilter, AttitudesSequence.SwitchHandler handler)
The past
and future
attitude providers are defined with regard
to the natural flow of time. This means that if the propagation is forward, the
propagator will switch from past
provider to future
provider at
event occurrence, but if the propagation is backward, the propagator will switch
from future
provider to past
provider at event occurrence. The
transition between the two attitude laws is not instantaneous, the switch event
defines the start of the transition (i.e. when leaving the past
attitude
law and entering the interpolated transition law). The end of the transition
(i.e. when leaving the interpolating transition law and entering the future
attitude law) occurs at switch time plus transitionTime
.
An attitude provider may have several different switch events associated to it. Depending on which event is triggered, the appropriate provider is switched to.
The switch events specified here must not be registered to the
propagator directly. The proper way to register these events is to
call registerSwitchEvents(Propagator)
once after all switching
conditions have been set up. The reason for this is that the events will
be wrapped before being registered.
If the underlying detector has an event handler associated to it, this handler
will be triggered (i.e. its eventOccurred
method will be called), regardless
of the event really triggering an attitude switch or not. As an example, if an
eclipse detector is used to switch from day to night attitude mode when entering
eclipse, with switchOnIncrease
set to false
and switchOnDecrease
set to true
. Then a handler set directly at eclipse detector level would
be triggered at both eclipse entry and eclipse exit, but attitude switch would
occur only at eclipse entry. Note that for the sake of symmetry, the
transition start and end dates should match for both forward and backward propagation.
This implies that for backward propagation, we have to compensate for the
transitionTime
when looking for the event. An unfortunate consequence is that the
eventOccurred
method may appear to be called out of sync with respect to the
propagation (it will be called when propagator reaches transition end, despite it
refers to transition start, as per transitionTime
compensation), and if the
method returns EventHandler.Action.STOP
, it will stop at the end of the
transition instead of at the start. For these reasons, it is not recommended to
set up an event handler for events that are used to switch attitude. If an event
handler is needed for other purposes, a second handler should be registered to
the propagator rather than relying on the side effects of attitude switches.
The smoothness of the transition between past and future attitude laws can be tuned
using the transitionTime
and transitionFilter
parameters. The
transitionTime
parameter specifies how much time is spent to switch from one law to
the other law. It should be larger than the event convergence threshold
in order to ensure attitude continuity. The
transitionFilter
parameter specifies the attitude time derivatives that should match
at the boundaries between past attitude law and transition law on one side, and
between transition law and future law on the other side.
AngularDerivativesFilter.USE_R
means only the rotation should be identical,
AngularDerivativesFilter.USE_RR
means both rotation and rotation rate
should be identical, AngularDerivativesFilter.USE_RRA
means both rotation,
rotation rate and rotation acceleration should be identical. During the transition,
the attitude law is computed by interpolating between past attitude law at switch time
and future attitude law at current intermediate time.
T
- class type for the switch eventpast
- attitude provider applicable for times in the switch event occurrence pastfuture
- attitude provider applicable for times in the switch event occurrence futureswitchEvent
- event triggering the attitude providers switchswitchOnIncrease
- if true, switch is triggered on increasing eventswitchOnDecrease
- if true, switch is triggered on decreasing eventtransitionTime
- duration of the transition between the past and future attitude lawstransitionFilter
- specification of transition law time derivatives that
should match past and future attitude lawshandler
- handler to call for notifying when switch occurs (may be null)public Attitude getAttitude(PVCoordinatesProvider pvProv, AbsoluteDate date, Frame frame)
getAttitude
in interface AttitudeProvider
pvProv
- local position-velocity provider around current datedate
- current dateframe
- reference frame from which attitude is computedpublic <T extends org.hipparchus.RealFieldElement<T>> FieldAttitude<T> getAttitude(FieldPVCoordinatesProvider<T> pvProv, FieldAbsoluteDate<T> date, Frame frame)
getAttitude
in interface AttitudeProvider
T
- type of the field elementspvProv
- local position-velocity provider around current datedate
- current dateframe
- reference frame from which attitude is computedCopyright © 2002-2019 CS Systèmes d'information. All rights reserved.