Commit 35b6aa85 authored by Luc Maisonobe's avatar Luc Maisonobe
Browse files

Updated documentation.

parent 077c18ae
......@@ -57,19 +57,22 @@
+modify(estimated)
}
class "On-board antenna" as Onboard
ObservedMeasurement *--> "*" EstimationModifier
ObservedMeasurement --> EstimatedMeasurement : create
EstimatedMeasurement <-- EstimationModifier : modify
class "..." as OtherMeasurement
OtherMeasurement ..|> ObservedMeasurement
Range ..|> ObservedMeasurement
RangeRate ..|> ObservedMeasurement
Angular ..|> ObservedMeasurement
AngularAzEl ..|> ObservedMeasurement
AngularRaDec ..|> ObservedMeasurement
PV ..|> ObservedMeasurement
ObservedMeasurement <|.. TurnAroundRange
ObservedMeasurement <|.. InterSatellitesRange
EstimationModifier <|.. Bias
EstimationModifier <|.. OutlierFilter
EstimationModifier <|.. Tropo
EstimationModifier <|.. Iono
EstimationModifier <|.. Onboard
}
......
......@@ -65,9 +65,12 @@ The shape of celestial bodies is represented by the `BodyShape` interface.
### Implementations
Only one implementation is provided by Orekit for now: the `OneAxisEllipsoid`
class, which represents the natural flattened shape of big space rotating bodies
like planets or the Sun.
Only two implementations are provided by Orekit for now:
* the `OneAxisEllipsoid` class, which represents the natural flattened shape
of big space rotating bodies like planets or the Sun
* the `Geoid` class, which adds the effect of a gravity field on top of
an ellipsoid, to represent the _sea level_
For asteroids, it is expected that users will provide their own shape models, for example
based on tessellation. They should implement the `BodyShape` interface in order to
......
......@@ -47,7 +47,10 @@ methods of this interface allow to:
* compute the time offset between measurement and spacecraft state
The estimated measurements can be modified by registering one or several `EstimationModifier`
objects. These objects will manage notions like tropospheric delays, biases, ground antennas position offsets ...
objects. These objects will manage notions like ionospheric or tropospheric delays, biases,
ground antennas position offsets, Antenna Phase Center... One specific modifier `OutlierFilter`
can be used to reject outliers at run time if the current residuals exceed the theoretical
standard deviation by some user-defined factor.
A typical operational case from a ground stations network would create distance and angular measurements, create
one bias modifier for the on-board delay for distance measurements, a few modifiers for each ground station
......@@ -76,9 +79,9 @@ neverthelesss selected, it should be configured to use `QR` decomposition rather
stability in case of poor observability. During the resolution, the selected Hipparchus algorithm will call the `evaluate`
method of the local `LeastSquaresProblem` model at each algorithm test point. This will trigger one orbit propagation with
some test values for the orbit state and the parameters (for example biases from the measurements modifiers parameters
or drag coefficients from the force models parameters). During the propagation, the Orekit event mechanism is used to
collect the state and its Jacobians at measurements dates. A `MeasurementsHandler` class performs the binding between the
generic events handling mechanism and the orbit determination framework. At each measurement date, it gets the state
or drag coefficients from the force models parameters). During the propagation, the Orekit step handler mechanism is used to
collect the state and its Jacobians at measurements dates. A `MeasurementHandler` class performs the binding between the
generic step handling mechanism and the orbit determination framework. At each measurement date, it gets the state
and Jacobians from the propagator side, calls the measurement methods to get the residuals and the partial
derivatives on the measurements side, and fetches the least squares estimator with the combined values, to be
provided back to the Hipparchus least squares solver, thus closing the loop.
......@@ -87,12 +90,13 @@ provided back to the Hipparchus least squares solver, thus closing the loop.
Users can decide what they want to estimate. The 6 orbital parameters are typically always estimated and are selected
by default, but it is possible to fix some or all of these parameters. Users can also estimate some propagator parameters
(like drag coefficient or radiation pressure coefficient) and measurements parameters (like biases or stations position
offsets). One use case for estimating only a subset of the orbital parameters is when observations are very scarce (say
the first few measurements on a newly detected debris or asteroid). One use case for not estimating any orbital parameters
at all is when calibrating measurements biases from a reference orbit considered to be perfect Selecting which parameters
should be estimates and which parameters should remain fixed is done thanks to the `ParameterDriver` class. During setup,
the user can retrieve three different `ParametersDriversList` from the `BatchLSEstimator`:
(like drag coefficient or radiation pressure coefficients) and measurements parameters (like biases, stations position
offsets or Earth Orientation parameters). One use case for estimating only a subset of the orbital parameters is when
observations are very scarce (say the first few measurements on a newly detected debris or asteroid). One use case for
not estimating any orbital parameters at all is when calibrating measurements biases from a reference orbit considered
to be perfect. Selecting which parameters should be estimates and which parameters should remain fixed is done thanks
to the `ParameterDriver` class. During setup, the user can retrieve three different `ParametersDriversList` from the
`BatchLSEstimator`:
* one list containing the 6 orbital parameters, which are estimated by default
* one list containing the propagator parameters, which depends on the force models used and
......@@ -100,7 +104,7 @@ the user can retrieve three different `ParametersDriversList` from the `BatchLSE
* one list containing the measurements parameters, which are not estimated by default
Then, looping on the elements of these lists, the user can change the default settings depending on his/her needs
and for example fix a dew orbital parameters while estimating a few propagation and measurements parameters.
and for example fix a few orbital parameters while estimating a few propagation and measurements parameters.
#### Parameters values changes
......@@ -153,7 +157,7 @@ been set to 2⁻³ whereas the scale factor for central attraction coefficient h
#### Parameters bounds
Some parameters values are forbidden and should not be used by the least squares estimator. Unfortunately, as of
early 2016 the Hipparchus library does not support simple bounds constraints for these algorithms. There is
mid 2017 the Hipparchus library does not support simple bounds constraints for these algorithms. There is
however a workaround with parameters validator. Orekit uses this workaround and set up a validator for the full
set of parameters. This validator checks the test values provided by the least squares solver are within the
parameters bounds, and if not it simply force them at boundary, effectively clipping the values. Just like
......
......@@ -45,24 +45,12 @@ The force models implemented are as follows:
* atmospheric drag forces, taking attitude into account if spacecraft shape is defined,
* central gravity forces, including time-dependent parts (linear trends and
pulsation at several different periods). Several attraction models are
available for representing the gravitational field of a celestial body
(the recommended model is Holmes and Featherstone):
* Andrzej Droziner model (Institute of Mathematical Machines, Warsaw) in his 1976 paper:
_An algorithm for recurrent calculation of gravitational acceleration_
(artificial satellites, Vol. 12, No 2, June 1977),
* Leland E. Cunningham model (Lockheed Missiles and Space Company, Sunnyvale
and Astronomy Department University of California, Berkeley) in his 1969 paper:
_On the computation of the spherical harmonic terms needed during the numerical integration of the orbital motion of an artificial satellite_
(Celestial Mechanics 2, 1970),
* S. A. Holmes and W. E. Featherstone (Department of Spatial Sciences,
Curtin University of Technology, Perth, Australia) in their 2002 paper:
_A unified approach to the Clenshaw summation and the recursive computation
of very high degree and order normalised associated Legendre functions_
(Journal of Geodesy (2002) 76: 279–299).
pulsation at several different periods). Our implementation is based on
S. A. Holmes and W. E. Featherstone (Department of Spatial Sciences,
Curtin University of Technology, Perth, Australia) 2002 paper:
_A unified approach to the Clenshaw summation and the recursive computation
of very high degree and order normalised associated Legendre functions_
(Journal of Geodesy (2002) 76: 279–299).
* third body gravity force. Data for all solar system bodies is available,
based on JPL DE ephemerides or IMCCE INPOP ephemerides,
......@@ -81,16 +69,24 @@ The force models implemented are as follows:
are implemented, with the possibility to define an impulse maneuver, thanks
to the event detector mechanism.
* parametric accelerations, to model lesser-known forces, estimating a few
defining parameters from a parametric function using orbit determination.
Typical parametric functions are polynomial (often limited to a constant term)
and harmonic (often with either orbital period or half orbital period).
An important operational example is the infamous GPS Y-bias.
## Spacecraft shapes
Surface forces like atmospheric drag or radiation pressure can use either
a simple `SphericalSpacecraft` shape or a more accurate
`BoxAndSolarArraySpacraft` shape.
a simple spherical shape using the various `Isotropic` classes or a more
accurate `BoxAndSolarArraySpacraft` shape.
The spherical shape will be independent of attitude.
The box and solar array will consider the contribution of all box facets facing
the flux as computed from the current attitude, and also the contribution of a
pivoting solar array, whose orientation is a combination of the spacecraft body
attitude and either the true Sun direction or a regularized rotation angle. As
of 6.1, the box and solar array does not compute yet shadowing effects.
attitude and either the true Sun direction or a regularized rotation angle.
The box can have any number of facets, and they can have any orientation as long
as the body remains convex. As of 9.0, the box and solar array does not compute
yet shadowing effects.
......@@ -242,6 +242,19 @@ system barycenter, as its associated frame is the ICRF.
![solar system frames](../images/solar-system-frames.png)
## Earth Frames
As explained above, the IERS conventions define Earth frames, the ITRF frames.
Depending on which Earth Orientation Parameters are loaded at run time by
users, the ITRF frame computed my be an older or a newer one. As of mid-2017,
if EOP parameters are loaded from EOP C04 14 files, the ITRF will be ITRF 2014,
whereas if EOP parameters are loaded from EOP C04 08, or from Bulletin A or
from Bulletin B, the ITRF be be ITRF 2008. When IERS will update its references,
the ITRF produce will change accordingly. Orekit always allows to convert
from one ITRF to any other ITRF. All ITRF versions since 1988 are supported,
as of Orekit 9.0, it corresponds to ITRF88, ITRF89, ITRF90, ITRF91, ITRF92,
ITRF93, ITRF94, ITRF96, ITRF97, ITRF2000, ITRF2005, ITRF2008 and ITRF2014).
## Topocentric Frame
This frame model allows defining the frame associated with any position at
......
......@@ -149,8 +149,9 @@ There are also several predefined events detectors already available, amongst wh
* `LatitudeCrossingDetector`, `LatitudeExtremumDetector`, `LongitudeCrossingDetector`,
`LongitudeExtremumDetector`, which are triggered when satellite position with respect
to central body reaches some predefined values,
* an `AlignmentDetector`, which is triggered when satellite and some body are aligned
in the orbital plane,
* an `AlignmentDetector`, which is triggered when satellite and some body projected
in the orbital plane have a specified angular separation (the term `AlignmentDetector`
is clearly a misnomer as the angular separation may be non-zero),
* an `AngularSeparationDetector`, which is triggered when angular separation between satellite and
some beacon as seen by an observer goes below a threshold. The beacon is typically the Sun, the
observer is typically a ground station
......@@ -175,6 +176,10 @@ some threshold. The filter does not simply ignore events after they have been de
it filters them before they are located and hence save some computation time by not doing
an accurate search for events that will ultimately be ignored.
A `BooleanDetector` is provided to combine several other detectors with boolean
operators `and`, `or` and `not`. This allows for example to detect when a satellite
is both visible from a ground station and out of eclipse.
Event occurring can be automatically logged using the `EventsLogger` class.
## Additional states
......@@ -354,3 +359,52 @@ Semianalytical propagation is implemented using Draper Semianalytical Satellite
Since version 7.0, both mean elements equations of motion models and short periodic terms
have been implemented and validated.
## Field propagation and Taylor Algebra
Since 9.0, most of the Orekit propagators (in fact all of them except DSST) have both a regular
version the propagates states based on classical real numbers (i.e. double precision numbers)
and a more general version that propagates states based on any class that implements the
`RealFieldElement` interface from Hipparchus. Such classes mimic real numbers in the way they
support all operations from the real field (addition, subtraction, multiplication, division,
but also direct and inverse trigonometric functions, direct and inverse hyperbolic functions,
logarithms, powers, roots...).
A very important implementation of the `RealFieldElement` interface is the `DerivativeStructure`
class, which in addition to compute the result of the canonical operation (add, multiply, sin,
atanh...) also computes its derivatives, with respect to any number of variables and to any
derivation order. If for example a user starts a computation with 6 canonical variables px,
py, pz, vx, vy, vz to represent an initial state and then performs a propagation. At the
end for all produced results (final position, final velocity but also geodetic altitude
with respect to an ellipsoid body or anything that Orekit computes), then for these results
one can retrieve its partial derivatives up to the computed order with respect to the 6
canonical variables. So if for example in a step handler you compute a geodetic altitude h,
you also have ∂³h/∂px²∂vz or any of the 84 components computed at order 3 for each value
(1 value, 6 first order derivatives, 14 second order derivatives, 56 third order derivatives).
The `DerivativeStructure` class also provides Taylor expansion, which allow to extrapolate
the result accurately to close values. This is an implementation of Taylor Algebra. Its two
main uses in space flight dynamics are
* accurate propagation of uncertainties (to much higher accuracy than simple covariance matrices)
* very fast Monte-Carlo analyses
Orekit implementations of field propagators support all features from classical propagators:
propagation modes, events (all events detectors), frames transforms, geodetic points. The
propagators available are Keplerian propagator, Eckstein-Heschler propagator, SGP4/SDP4
propagator, and numerical propagator with all Hipparchus integrators (fixed steps or adaptive
stepsizes) and all force models (including all atmosphere models). All attitude modes are
supported.
One must be aware however of the combinatorial explosion of computation size. For p derivation
parameters and o order, the number of components computed for each value is given by the
binomial coefficient (o+p¦p). As an example 6 parameters and order 6 implies every single
double in a regular propagation will be replaced by 924 numbers in field propagation. These
numbers are all combined together linearly in addition and subtraction, but quadratically
in multiplication and divisions. The `DerivativeStructure` class is highly optimized, but having
both high order and high number of parameters remains inherently costly.
Once the propagation has been performed, however, evaluating a Taylor expansion, for example in
a Monte-Carlo application is *very* fast. So even if the propagation ends up to be for example a
hundred of times slower than regular propagation, depending on the number of derivatives, the
payoff is still very important as soon as we evaluate a few hundreds of points. As Monte-Carlo
analyses more often use several thousands of evaluations, the payoff is really interesting.
......@@ -41,6 +41,13 @@ with groupID org.orekit and artifactId orekit so maven
internal mechanism will download automatically all artifacts and dependencies
as required.
| package | link |
|----------|-----------------------------------------------------------------------------------------------------------|
| source | [orekit-9.0-sources.zip](https://www.orekit.org/forge/attachments/download/xxx/orekit-9.0-sources.zip) |
| binary | [orekit-9.0.jar](https://www.orekit.org/forge/attachments/download/xxx/orekit-9.0.jar) |
| javadoc | [orekit-9.0-javadoc.jar](https://www.orekit.org/forge/attachments/download/xxx/orekit-9.0-javadoc.jar) |
version 9.0 downloads (release date: 2017-07-25)
| package | link |
|----------|-----------------------------------------------------------------------------------------------------------|
| source | [orekit-8.0-sources.zip](https://www.orekit.org/forge/attachments/download/611/orekit-8.0-sources.zip) |
......
......@@ -118,6 +118,7 @@ Math to Hipparchus
Orekit 7.1 | Apache Commons Math 3.6
Orekit 7.2 | Apache Commons Math 3.6.1
Orekit 8.0 | Hipparchus 1.0
Orekit 9.0 | Hipparchus 1.1
### Maven failed to compile Orekit and complained about a missing artifact.
......@@ -160,7 +161,7 @@ data for the IERS convention 2003, they have switched to IERS conventions 2010.
(EOP 05 C08 file) are still published. We advise then that you update these files regularly as
the IERS publish them.
Concerning UTC leap seconds, as of mid 2016, the last one was introduced at the end of June 2015.
Concerning UTC leap seconds, as of mid 2017, the last one was introduced at the end of December 2016.
## Runtime errors
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment