Conference PaperPDF Available

Multi-satellites Precise Orbit Determination, an adaptable open-source implementation

Authors:
  • CS SI, France, Toulouse
Conference Paper

Multi-satellites Precise Orbit Determination, an adaptable open-source implementation

Figures

No caption available
… 
No caption available
… 
No caption available
… 
Content may be subject to copyright.
Multi-satellites Precise Orbit Determination,
an adaptable open-source implementation
Luc Maisonobe, Pascal Parraud, Maxime Journot, and Albert Alcarraz García§
CS-SI, 5 rue Brindejonc des Moulinais, 31506 Toulouse CEDEX 5, FRANCE
Orbit determination is a major feature in all operational flight dynamics systems. The
most accurate research-level tools have been tuned for decades by agencies. They are generally
not available to the public and are also very difficult to operate as user-friendliness is not
their primary goal. Commercial off-the-shelf systems are available but at a high price tag and
without any way for user to add their specificities. This paper describes the fully open-source
orbit determination package that has been made available since 2016 in the Orekit space flight
dynamics library. It presents first the history of the package and how it started as a tool for
regular operations using classical measurements and how it evolved to include finer and finer
models and new features like multi-satellites handling and exotic measurement types. The
second part explains the philosophy behind some design choices like the adaptive computation
of measurement corrections. Then it presents some technical details about the algorithms used
under the hood, like partial derivatives computations or implementation of the multi-satellites
features. Results and performances are shown. The paper ends with a presentation of a
roadmap for future extensions.
I. Introduction
Orbit determination is a major feature in all operational Flight Dynamics systems. It has long been considered a
highly priced component that includes top level know-how. All major agencies have one or several home-grown orbit
determination software that have been tuned over decades. These components often include agency-specific methods
and models. Some are only used for research as they require specific training and in-depth knowledge of their operations.
Some are also used for routine operations for the missions agencies directly manage. These agencies orbit determination
packages are considered to be strategic assets and are generally not shared with anyone. A few commercial companies
have developed generally available orbit determination packages that can be used for regular operations and that handle
classical measurements. Licenses for these packages are available, at a high price tag, and without any possibility to add
new measurements types or to adapt the interface.
CS Systèmes d’Information has extended in 2016 the open-source Orekit [
1
] space flight dynamics library with an
orbit determination package. This package was first published as of version 8.0 of the library, and significantly improved
with version 9.0 released in mid 2017. This orbit determination package was at first a classical one that could manage
routine orbit determination for single spacecraft. It handled range, range-rate (one way and two-way), azimut-elevation
and PV bulletins measurements. It allowed to estimate orbit, propagation parameters like drag, radiation pressure and
maneuvers parameters, and also to estimate measurements parameters like biases or station positions. At this step, it
was equivalent to a commercial off the shelf package. This first step showed it was possible to have a fully open-source,
reliable orbit determination implementation that meets many operational needs. As this initial version was already a
success, an extended goal was sought, and achieved with Orekit 9.0 release. With this release, orbit determination not
only dealt with classical or routine missions, but it also fulfilled needs that were first only available using research-level
or agency tools. The improvements included multi-satellite orbit determination, much more accurate derivations,
inclusion of very fine estimation of pole motion and prime meridian, parametric forces, inter-satellite measurements...
while still being fully open-source, freely available to everyone, and could be extended to address mission-specific
needs. This paper describes first the history of this package and the philosophy behind some design choices. Then
it presents some technical details about the algorithms used under the hood, like partial derivatives computations or
luc.maisonobe@c-s.fr.
pascal.parraud@c-s.fr.
maxime.journot@c-s.fr
§albert.alcarraz-garcia@c-s.fr
1
implementation of the multi-satellites features. Results and performances are shown. It ends with a presentation of a
roadmap for future extensions.
II. History
A. Background
Orekit is a space flight dynamics library developed since 2002, first as a CS-SI internal product. It was released as
open source in 2008 [2] under the terms of the business-friendly Apache License V2.
Many users have asked for a long time for an orbit determination package in the Orekit library. This feature was
so important to the project team that is was the very first feature registered in the issue tracker when the forge was
established in 2011, hence getting the very symbolic issue number 1
. There were initially some discussions within the
Orekit team and with some power users, in order to settle whereas orbit determination was too high level to be included
in a general purpose library or if it suited within the library scope. We reached the conclusion that it was within scope.
An orbit determination application was contributed in 2012 by Telespazio. This was a big and unexpected
contribution, and we were (and still are) very grateful to Telespazio for having done this. However, it was impossible to
introduce this contribution into the main library for several reasons. It was monolithic, was not extensible in terms of
both measurements and parameters estimation and it used simplified measurement equations and derivatives computation
that would not scale to precise orbit determination. The contribution was put on hold in the Orekit lab
, a sub-project of
Orekit, waiting for time to redesign it.
For a few years we lacked resources to progress on this topic, so it was postponed year after year until it bubbled up
at the top of the priority list in the middle of 2015.
When work started in June 2015, we considered again the Telespazio contribution. During the three years elapsed
since the contribution was made, the main library had evolved a lot. It was even more difficult at that time to fit
the contribution into the current library version than it was three years before. We finally decided to redesign and
redevelop entirely the orbit determination feature, and to use the contribution code as a reference implementation and
the contribution data as reference test cases.
Apart from the contribution, there were already a number of building blocks validated by years of use available in
Orekit at that time:
orbit propagation handling any type of orbit and any force model,
Jacobian propagation capable of integrating state transition matrices and covariance
local Jacobians for any type of orbits with respect to Cartesian coordinates
steps and events handling allowing to pick up Jacobians on the fly during propagation at measurements times
propagators optimizers initially created for models conversion that allowed to find the propagator configuration
most consistent with a precomputed ephemeris
Tables 1 and 2 present the orbit determination features roughly classified in the perspectives of projects foreseen by
the Orekit team. This classification is of course subject to interpretation and arbitration, it was only used for setting
priorities.
basic operations
correspond to mandatory features that are needed even for the least demanding missions that
could tolerate errors up to a few meters
extended operations
correspond to nice to have features or features useful for some specific missions (like
turn-around range measurements), these features are mandatory if a below meter accuracy is required for the
mission
science correspond to high accuracy requirements, when seeking at a few centimeters
Not all of the features were foreseen right from the beginning. Typically the need for position-only measurements,
despite being now considered useful for basic operations was not identified during the first phase.
B. First phase, a tool for regular operations
The initial goal was to have an operational tool for classical, non-demanding missions. From the table 1 features set,
only the features classified as basic operations and the two extended operations features corresponding to user-provided
http://orekit.org/license.html
https://www.orekit.org/forge/issues/1
https://www.orekit.org/forge/projects/orbit-determination- telespazio-s- contribution
2
Table 1 Orbit Determination Initial Features
feature expected use achievement date
single satellite orbit determination basic operations
propagation parameters determination (drag, SRP...) basic operations
measurements biases estimation basic operations
batch least squares engine basic operations
two-way pseudo-range measurements from ground station basic operations
two-way range-rate measurements from ground station basic operations
azimuth-elevation measuremenst from ground station basic operations
position-velocity measurements basic operations
automatic detection of outliers basic operations 2016-06-30
ground stations position estimation extended operations
tropospheric and ionospheric effects extended operations
allow user-provided measurements extended operations
allow user-provided corrections extended operations
passing through maneuvers extended operations
estimating maneuver parameters extended operations
partial orbit determination (for example a, e only) extended operations
one-way range-rate science (oceanography)
rigth-ascension/declination measurements extended operations
turn-around range measurements extended operations
loading of CCSDS Tracking Data Messages extended operations
parametric accelerations estimation extended operations
one-way and two-way intersatellite measurements science (geodesy) 2017-07-26
on-board antenna phase center correction science (geodesy)
Earth Orientation Parameters estimation science (oceanography, geodesy)
multi-satellite orbit determination science (geodesy)
ground station displacement due to tides science (geodesy)
ground station displacement due to ocean loading science (geodesy) 2017-11-26
3
measurements and corrections were considered. The rationale behind this choice was that extensions would have a
dramatic effect on design, so it needed to be addressed right from the beginning. This was one of the lessons learned
from the 2012 contribution.
During the design of the orbit determination package, a number of other extended operations features were added on
the fly as they fitted well with the design.
The development spanned over one year, due partly to shifted assignments within the team (the project was internally
funded and some people were reaffected to customer projects) and due partly to a partial redesign required for addressing
numerical stability issues.
The need for position-velocity measurement was driven by two different use cases. The first one was for operational
spacecrafts that have an on-board GNSS receiver directly providing location information that is downloaded to ground.
The receiver itself often uses the navigation signal only with low accuracy broadcasted orbits, and does not provide raw
code and phase measurements, at least not for nominal operation. The second use case was for importing ephemerides
from another entity (typically from CCSDS OEM files or similar) and rebuilding a complete orbital model from the
ephemeris data in order to extend it past the file end.
The partial orbit determination feature may seem strange at first sight. It is strange and should be very seldom used.
It was not really added intentionally, but was a side-effect of the design of parameters drivers (see section III.C). By
default, all orbital parameters are always estimated, but users can switch off the estimation on individual parameters.
One use case for this feature corresponds to contingency cases at injection or after a big maneuver (think an apogee
maneuver for a geostationary satellite). At that time, the spacecraft starts to drift from its nominal orbit and very
few measurements are available before its track is lost. This feature allows to limit orbit determination to a few key
parameters (in this case semi major axis and eccentricity would be the obvious choice) and still be able to get some
crude information from a scarce number of measurements. This crude orbit can be used for antenna pointing for the
next station so additional measurements can be performed and a real complete orbit estimated.
Validation of the new orbit determination package was done over a long time. As per the nature of the project team,
we didn’t had access to a lot of reference data, so had to make do with what we could find. The reference data from
the Telespazio contribution was a major help here. It was also a very interesting case because it was real data from a
spacecraft that experienced a leak after injection and was ultimately brought back to burn at reentry. The leak induced
unmodelled perturbing forces that were orders of magnitude above radiation pressure. Most of the validation could
fortunately be done using simulated data as the propagation features used for this have already been validated since
years [3].
The first version of the orbit determination feature was made available on 2016-06-30 with version 8.0 of the Orekit
library.
C. Second phase, addressing extended needs
Once a general purpose orbit determination tool was available, the Orekit team members focused on more specific
needs that they faced for some operational systems [
4
][
5
][
6
]. The corresponding features correspond to the last sections
of table 1.
The needs were for the most part additional measurements types or interfacing with external systems. Some of these
needs were included in the Orekit library, some were too specific, but could be added later if there is a demand for them
§
.
At that time a new trend emerged with future needs for very high accuracy and navigation. As the orbit determination
package was designed for extensions, it was considered feasible to start introducing progressively features devoted to
high accuracy, despite they were not immediately used. It was a much smaller investment of time than the first phase
and could turn out well. This proved the design was correct as all addition were quite easy to make. This was the origin
of the features idenditifed as science in table 1.
The only really breaking change introduced during this phase was multi-satellite propagation. Despite begin a major
change from a user point of view, it took only three days to develop (from June 30th to July 2nd).
Once again, the delay between the previous release of Orekit (8.0, published during summer 2016) and the new
release (9.0, published during summer 2017) was over one year. The delay was not related to orbit determination. It was
due to a major evolution with the introduction of Taylor algebra [
7
], which is not yet used in orbit determination but will
probably be used later (see section V.B).
A third release of the orbit determination package was performed at the end of 2017, containing the last two features
from table 1, ground station displacements, which are both only needed for sub-meter orbit determination. The shorter
§for example support for a bi-static radar producing pseudo-range-rate...
4
Table 2 Orbit Determination Extended Features
feature expected use target date
position-only measurement basic operations
covariance matrix in each PV measurement extended operations
extended Kalman orbit determination extended operations
GNSS code measurement extended operations
simple/double difference phase measurements science (geodesy)
combined measurements (wide-lane, iono-free...) science (geodesy) scheduled for
estimation of time-dependent tropospheric corrections science (geodesy) SpaceOps 2018
loading of Rinex files science (geodesy)
loading of Antex files science (geodesy)
constellation-specific models for Noon/Midnight turns science (geodesy)
along track time-dependent process noise provider science (geodesy)
orbit determination with DSST extended operations
orbit determination with analytical propagators extended operations
clock estimation science (geodesy) 2018-2019
ambiguity resolution in phase measurements science (geodesy)
time span since previous release was an attempt to abide more strictly to the open-source moto release early, release
often [8]. After this release, all features from table 1 were available.
It appeared later that position-velocity measurements were sometimes too restrictive for the ephemeris use case.
The CCSDS OEM files always include velocity, but custom-created ephemerides sometimes only include position.
Therefore a position-only measurement has been included too and is now considered to belong to the basic operations
category, but it was not available in the first phases.
D. Towards high accuracy
The first orbit determination package was based on a batch least squares implementation, with a few alternate
choices for the underlying optimizer. Some missions ask for a sequential filter that runs continuously and updates the
estimations as new measurements are processed.
A Kalman filter [
9
] was therefore introduced as an alternative orbit determination engine. It can handle the same
measurements as the batch least squares estimator and is based on similar principles (see sections III.B, III.C, III.D).
The Kalman filter also supports multi-satellite orbit propagation and hence is well suited for full-constellation estimation
when a lot of estimated parameters are shared among several satellites (ground stations positions, clocks, ...).
The filter was first developed as an autonomous package within the Orekit library, and later split in two layers, an
underlying mathematical framework that can be applied to any type of linear or non-linear process, and a space flight
dynamics layer that deals with orbital parameters, propagation parameters and measurements parameters. The underlying
mathematical framework was contributed to the Hipparchus project [
10
], which is the open-source mathematical library
Orekit uses.
Then as the trend towards very high accuracy and navigation was confirmed, a new set of extended features was set up.
The current set appears in table 2. Most of these features are already implemented. As Orekit is an open-source project
with an open development process and governance, all these features are available as soon as they are implemented, even
before official releases of the library. As of writing (April 2018), most of the features are already implemented and the
official release is expected to be done just before the SpaceOps conference, and the next set that will allow to perform a
full navigation constellation orbit determination at a few centimeters level should be available in the subsequent release.
E. Current status
From a user point of view, the current status is that the orbit determination package provided by Orekit works well,
has been validated and is used. It supports all required features need for space operations (nominal or contingency) of
5
single or multiple spacecrafts plus a number of extra features more related to high accuracy needs like geodesy.
III. Under the hood
A. Global architecture
1. Batch least squares
The architecture of the batch least squares is explained in the class diagram 1. The estimator which knows
about space flight dynamics creates an orbit determination problem as an implementation of the domain-agnostic
LeastSquaresProblem
interface, which can be handled by any of the
LeastSquaresOptimizer
(not shown in the
diagram) provided by the Hipparchus mathematical library. The user can choose the optimizer he or she wants, for
example Gauss-Newton or Levenberg-Marquardt, and even the matrix decomposer the optimizer will use (QR, LU,
Cholesky, SVD) and whereas the normal equations should be used (i.e. the optimizer will solve
JTJ x =JTr
) or not (i.e.
the optimizer will solve J x =r). The second form, not forming the normal equations, is preferred when the orbit may
have observability problems, as it is numerically more stable. Of course, when using a decomposition algorithm like LU
or Cholesky that requires a square system, the formal equations must be used.
The orbit determination problems is configured with the estimated parameters, that will be presented to the optimizer
as a simple compound vector and with all the observed measurements.
Each time the optimizer needs to evaluate a new test point in the orbit determination problem, the components of the
test point are distributed to the space flight dynamics models they belong to (initial orbit, force model, measurement
bias model, ...) and a new propagation is performed. The measurements are picked up on the fly during the propagation
using the
MeasurementHandler
, and an estimated measurement generated, which corresponds to the theoretical
evaluation of the measurement from the current state. At the end of the propagation, the difference between the observed
measurements and the estimated measurements as well as the corresponding Jacobians are returned to the optimizer so
it can determine if convergence has been reached or if a new test point must be generated.
2. Kalman filter
The architecture of the Kalman estimator is explained in the class diagram 2. The Kalman estimator is an extended
filter, devoted to non-linear processes. Measurements are fed one at a time to the non-linear
Model
, which is an
implementation of the domain-agnostic
NonLinearProcess
interface. The model will call the propagator for the
estimation state, and will estimate the measurement for the correction step. There is no need for an intermediate
measurement handler here as measurements and propagation are synchronized by construction.
A notoriously difficult part in using a Kalman filter is providing the initial covariance at estimation start and the
process noise introduced during the estimation part of the Kalman estimation/correction steps.
As usual in Orekit design, when several different models may be used and when some expert users may have their
own private theories, a delegation approach with an interface has been used. The
Model
will call the implementation
of
ProcessNoiseMatrixProvider
that was configured for a given propagator and expect it to return appropriate
covariance matrices.
In simple cases, or if the user has no clue about what to use, a simple provider is made available in Orekit that uses
only constant matrices. This is fine for the initial covariance, which in fact is often the result from a previous orbit
determination that was stored for this purpose.
This is however not suitable for the process noise between the previous and current state as this depends on both
states and most importantly on the time gap between them. If two measurements are only a few seconds apart, the
noise introduced by the estimation step should be far smaller than the noise introduced by an estimation step between
measurements separated by a few hours.
A simplified model expanding an error ellipsoid with principal axes in the along-track, across-track and normal
directions and using time-dependent lengths for the ellipsoid axes has been set up in the library. Finding the right
univariate time function for the matrix diagonal terms remains the responsibility of user. One way to tune it properly for
a family of orbits is to use a first run of Taylor algebra during the mission analysis phase, to monitor how the high order
uncertainties evolve, and to fit a time-dependent ellipsoid on this evolution. Then a Kalman filter using a covariance
matrix provider with such a time-dependent ellipsoid model will be more realistic than a basic constant matrix.
For even more accurate representations, users are free to set up their own models, which could go up to evaluating
6
Fig. 1 batch least squares overview
the effect of each force models (see for example [
9
]). Class diagram 2 was drawn in such a situation, where the user
implemented the ProcessNoiseMatrixProvider using a custom MyProcessNoiseMatrixProvider.
B. Raw measurements and modifiers
As Orekit is a library, it can be used in different environments and for various missions. The physical models
to use may be different from one use to another. Even considering a basic measurement like two-way pseudo-range,
the number of corrections to apply and their fine tuning are very different for a geodesy study and for a commercial
telecommunications satellite.
A naive implementation, with each measurement including all the possible corrections directly in the model would
therefore need to be rewritten to be usable by both power users requiring all possible and even custom effects and by
regular telecommunication operators that are happy with a few meters and do not want to deal with downloading huge
correction data from scientific institutions each day.
Diving into the measurements equations, one can see they are always iterative and in the form:
7
Fig. 2 Kalman filter overview
mkf(tk,yk,p)
i1
do
mkci(mk,tk,yk,p)
ii+1
while iimax
return mk
where
mk
is the estimated value for measurement number
k
,
tk
is the measurement date,
yk
is the state at
tk
,
p
are
the measurements parameters, fis the main effect (say the geometric distance between ground station and spacecraft)
and
ci
are correction effects like projected distance between antenna phase center and spacecraft center of gravity,
tropospheric delay, ionospheric delay, measurement bias...
In most if not all cases, the correction has a simple additive form:
ci(mk,tk,yk,p)=mk+γi(tk,yk,p)
Therefore, the design that was adopted is to separate all elements (
f(tk,yk,p)
and all the
ci(mk,tk,yk,p)
) in separate
objects and let the user decide which elements to consider for each measurement. This is depicted in class diagram 3. The
main effect
f(tk,yk,p)
is what is computed when
ObservedMeasurement
first creates the
EstimatedMeasurement
,
and the
ci(mk,tk,yk,p)
are what is computed when
EstimationModifierModifier
are applied. If a researcher
developing a new tropospheric model wants to use it, there is no need to rewrite everything, just compute the new
specific
ci
, and add it in the list of effects to consider, taking care to not add the other tropospheric effects so the effect is
not counted twice.
This design proved to work really well and also to simplify validation and maintenance a lot, which is of prime
importance as models get more and more complex for handling more and more accurate results.
Adding new measurements and new modifiers is done by implementing the
ObservedMeasurement
and
EstimationModifier
interfaces, which ensures extensibility of the orbit determination package to mission-specific
needs.
8
Fig. 3 measurements
C. How to estimate parameters from user-provided models
1. Decoupling
Orekit is a library intended to be used as an intermediate layer to build complete applications, it is not an application
by itself. Users may want to add their own models on top of Orekit (for example exotic measurements types or
corrections, as seen in section III.B) and these models may have some parameters that the orbit determination package
should estimate.
How could an existing orbit determination package tune a parameter embedded deep inside a model it doesn’t know
anything about?
This problem was solved by using an intermediate representation for parameters that can be adjusted. This is
demonstrated in class diagram 4 with the case of measurements that refer to a ground station, and this ground station
position can be estimated. In this diagram, the estimator (here a batch least squares estimator, but it could be a Kalman
estimator as well) doesn’t see directly the ground station, and of course not its position offset parameters. However, the
ground station can provide to the upper layers a list of
ParameterDriver
instances, as proxy objects allowing these
layers to adjust its internal parameters. From the upper layers point of view, including the batch least squares estimator,
all parameters drivers are the same, it does not need to know what the value is used for. All it needs to know is that the
driver is available, that it can ask for partial derivatives with respect to it, and that it can change its value. Users can
9
Fig. 4 driving low level parameters from the optimizer
configure for each parameter driver if it is fixed or if it should be estimated.
When users add their own measurements, their own modifiers and their own parameters to be adjusted, all they need
to do is link these internal parameters with drivers and provide the drivers to the upper layers. They have two ways to
get the values changed by the estimator: either they also store the driver and just get the value asynchronously from
them when they need it, or they register themselves as observers of changes and will be notified synchronously when the
value is changed by the estimator.
This decoupling between the lower and upper layers of the orbit determination greatly simplifies evolutive maintenance
of the package and extensibility for users. It was used for example between the first and second phase of the development
to add Earth Orientation Parameters estimation without breaking anything. We only had to add a series of drivers for
prime meridian offset, prime meridian drift, pole offsets and pole drifts.
Parameters drivers are used for everything the orbit propagator estimates. This includes the orbital parameters.
When this design was set up, in the very early phases, it had an unexpected side effect: being driven by parameters
drivers, orbital parameters could be selectively considered as fixed or estimated. This is what allows partial orbit
determination as explained in section II.B.
Changing from single satellite orbit determination to multi-satellites orbit determination was also made possible
thanks to parameters driver.
2. Normalization of the parameters
During the first validation attempts in the first phase of the project, some stability issues where encountered. The
estimation went well in most cases, and both orbital parameters and propagation model parameters were estimated
correctly. However, when some parameters were estimated, convergence issues appeared. At first, we thought there was
an error in the computation of the derivatives, but it was quickly ruled out because this derivative was trivial (a single
10
multiplication) and it was numerically checked.
The problem was in fact related to a state vector having components with very different orders of magnitude. An
extreme example would be the eccentricity of an almost circular orbit, which is of the order of magnitude of about 10
6
and the central attraction coefficient (which was estimated in a stress test) and is of the order of magnitude of 10
+14
.
The Levenberg-Marquardt estimator behaved badly with a vector where two components had 22 orders of magnitude
difference. It was therefore a simple and classical problem of using raw values of parameters instead of normalizing
them. Once identified, the solution was obvious (at least theoretically) and the parameters drivers were adapted to
manage a scaling factor. This allowed the optimizer in the upper layer to drive the parameters as normalized parameters
while the lower layer deals with the physical values of the parameters. Despite being a simple scaling problem, it turned
out to be quite difficult to set up correctly and it delayed the first release a few weeks.
3. Simple bounds
A final feature of the parameters drivers is the ability to enforce simple bounds on the values of the parameters (for
example eccentricity which should always be positive), despite some optimizers do not support constraints.
This is a poor-man way to add constraints, but it works remarkably well in the context of orbit determination. It
would certainly be inefficient for general mathematical optimization when the optimum is exactly on the boundary, but
this is generally not the case in orbit determination. However, an optimizer during its search to the minimum could make
an attempt to test a point which has no physical meaning. Without protection of the bounds, that would generate NaN
and lead to a failure of the computation as they would quickly spread throughout the state vector. With the protection,
the test point is simply clipped to feasibility domain and optimization continues.
D. Accurate computation of derivatives
One of the core computation in an orbit determination system is the evaluation of partial derivatives with respect to
the estimated parameters: orbital parameters, propagation parameters and measurement parameters.
At first, we used as everyone else explicit analytic equations for the derivatives. This was not to difficult for most
measurements, for example pseudo-range which is basically only evaluating two distances, one for the uplink and one
for the downlink of the signal. As we were checking our models against finite differences, we identified some tiny
discrepancies. They were well below the accuracy needed even for very high orbit determination, but they bothered
us and we wanted to be sure we understood where they came from. It appeared they were due to the influence of the
velocity, which was unexpected because it was pseudo-range, not range rate, it had nothing to do with velocity! For
the curious, we have put the derivation of the accurate derivatives in the paper appendix. This derivation should be
considered only as an historical reference since we do not use it anymore. What is interesting however in this derivation
is that even for something as simple as pseudo-range, explicit analytic equations may have some hidden traps and there
are some parameters dependencies that are easily forgotten. The equations
(2)
and
(5)
in appendix are not trivial and
in the equation
(3)
, the matrix
M
is not identity despite a quick analysis would conclude it should be identity. These
equations were the cause of the tiny discrepancies we detected in this phase.
We then decided that we should avoid computing the derivatives analytically first with pencil and paper (or even with
a formal algebra system). We decided to rely on something much more robust that automatically takes all dependencies
into account and still computes derivatives without approximations. We had already used such a system in Orekit
for years, and it was both fully validated and praised by the team members. This system is based on algorithmic
differentiation [
11
]. It is provided by the Hipparchus [
10
] mathematical library and is able to compute derivatives to any
order and with any number of parameters [12].
The basic idea behind algorithmic differentiation is that you only implement the equation you want to differentiate,
but you don’t do this using primitive double numbers. You use some extended double that behaves like double number,
but does something more. These extended double can be added, subtracted, multiplied, passed to
sin
,
cos
or any other
double function. When performing all these elementary operations (add, subtract, ...,
sin
,
cos
, ...) these extended
double compute both the value, just as a double would do, but they also compute the derivatives analytically, simply by
applying the chain rule. The algorithms presented in [
12
] are very generic and allow to compute derivatives to any order
and with respect to any number of parameters. The
DerivativeStructure
class provided by Hipparchus for this
purpose also implements the hints presented at the end of Dan Kalman’s paper to improve efficiency by compiling the
recursive rules into iterative loops with all common factors merged.
All derivatives used in the measurements equations in Orekit orbit determination package use algorithmic
differentiation. This ensured derivatives are extremely accurate and don’t rely on any assumption or simplification.
11
IV. Results
The orbit determination features has been used for more than two years now. A few issues have been registered by the
community and quickly resolved. The most important ones were a set of inter-related issues linked to the management
of parameters drivers lists that caused huge performance drops when the number of iterations increased. All these
problems have been solved. There were no problems at all related to the equations or physical models. We had several
informal reports that the orbit determination worked well, and indeed we use it in several operational projects.
Fig. 5 Comparison of two different orbit -determination implementations
Figure 5 shows a comparison of the reference orbit determination that was contributed by Telespazio in 2012
and the current Orekit implementation. The plot shows the residuals of the range measurements after convergence
in an operational case with very chaotic dynamics (a spacecraft that experienced a leak after injection). The other
measurement types show similar behaviors. This plot shows that both system find comparable results. The residuals
have almost equal standard deviations (4.40m for the reference implementation, 4.37m for the Orekit implementation)
that are considered to correspond to measurement errors.
In the reference implementation, the leak was mainly absorbed by the solar radiation pressure coefficient, which
was estimated to a huge negative value (-1414.51). This is probably explained as the attitude mode for satellites in
transfer orbit is often a slow spin around a Sun-pointed axis with thrusters on the cool side. The mean value of a leak
will therefore tend to appear aligned with Sun direction and opposite to it. This model is however not representative
when the satellite is in eclipse, since the radiation pressure model becomes zero whereas the leak still occurs in this
phase. In the Orekit case, we did set up a parametric acceleration and estimated it, while fixing the reflection coefficient
to a standard value (+2.0).
12
Fig. 6 Orbit determination of a GPS satellite using pseudo-range only
Figure 6 shows an early orbit determination using only pseudo-range measurements from 5 stations. The plot shows
the residuals of the pseudo-range measurements after convergence. The standard deviation of the residuals is 0.75m.
This early result was the very first one obtained on real GNSS data, before all GNSS-related features were available. The
plot was mainly created for validating the averall loading of RINEX files and basic one-way pseudo-range. Dynamic
model and measurement models were not refined at this stage. There was a lot of room for improvement, but for a first
result, it was considered promising.
V. Future work
A. Orbit determination for DSST semi-analytical propagator
The Draper Semi-Analytical Satellite Theory [
13
], [
14
], [
15
] is a very fast and accurate model to propagate orbits. It
is especially suited for station-keeping as it provides both mean elements (which are essential for this activity) and
osculating elements, and also suited for very long term analysis like end of life estimation.
In the use-case of station-keeping, it would be nice to have an orbit determination that is consistent with the DSST
model [
16
], [
17
], [
18
]. Some work has been started in the Orekit implementation of the DSST. The main idea is to
apply the variational equations in the numerical part of the theory to get the partial derivatives with respect to the mean
elements, and to simply add the short periodic terms without computing their derivatives. The rationale is that despite
the short periodic terms do depend on the state and they will evolve as the state is modified by the optimizer at each
step, their indirect evolution will be much smaller that the direct evolution of the mean elements. Therefore, the orbit
13
determination process can be performed, albeit more slowly than with perfect derivatives.
This work is currently ongoing and has been added to the extended features in table 2.
B. Orbit determination for analytical propagators
Since version 9.0, Orekit includes a Taylor algebra feature [
7
] that was implemented using the Field mechanism from
Hipparchus that allows to do computation on any type that has the same properties as the field of real numbers (addition,
subtraction, multiplication and also scientific functions like trigonometric, hyperbolic, logarithmic...). Section III.D
already presented one use of fields with algorithmic derivatives, restricted in this section to the low level computation of
measurements partial derivatives with respect to current state.
The Taylor algebra feature is more general and can be applied directly to most propagators in Orekit: numerical,
Kepler, Eckstein-Heschler, SGP4/SDP4. If we configure a propagation to use a simple first order Taylor algebra where
the canonical variables are the initial orbit and the propagation parameters, then we automatically get the Jacobians with
respect to these variables and we are able to combine them with the Jacobians of the measurements. In essence, the
Taylor algebra applied to propagator is a different way to compute what the numerical propagators does with variational
equations. The difference is that it is not restricted to integration-based methods: it works also for analytical methods.
From this observation, we deduce that we could set up orbit determination engines consistent with analytical
propagators and providing directly initial states for these propagators. We could for example produce TLE from
observations in one direct step.
This application of the Taylor algebra has not yet been started but is considered to be almost a routine task. It has
been added to the extended features in table 2.
C. GNSS phase measurements
One of the topics that was discussed during the 2017 Orekit day with the Orekit community was the trend towards
high accuracy and navigation. A major feature that needs to be implemented is the handling of phase measurements
and of clocks. A first part was already done and the official release is expected to occur just before the SpaceOps
conference. It contains phase measurements with combinations that remove the integer ambiguities (simple and double
differences). A second part will be added later on. We hope to implement other phase combinations and to implement
at least the LAMBDA (Least-squares AMBiguity Decorrelation Adjustment) method [
19
] for dealing directly with
integer ambiguities.
VI. Conclusion
As a conclusion, we can say that Orekit provides a full-blown orbit determination system that addresses a large range
of needs, from regular operations to accurate geodesy. It is fully open-source and can be tuned to specific missions, even
adding user-provided measurements and corrections. The system is readily available and used in different contexts.
New features are added regularly and the trend is to go towards extremely accurate GNSS handling.
Appendix
This appendix presents a derivation of computation of pseudo-range measurement derivatives taking into account
some often neglected effects. This was used in an early implementation of the pseudo-range measurement and was
discarded later on as we switched to algorithmic differentiation as explained in section III.D.
A pseudo-range measurement is a two ways measurement. A signal is first emitted from a ground station, it travels
along the uplink leg for a
τu
time of flight, arrives at the spacecraft, transits on-board and is re-emitted back to ground.
It then travels along the downlink leg for a
τd
time of flight and arrives at the same ground station. The measurement is
considered to be time stamped at reception on ground, all times are therefore computed as backward offsets with respect
to this reception time. Station position at reception time is
Q(t)
, spacecraft position at signal on-board transit time is
P=s(tτd)and station position at emission time is Q(tτdτu).
Of course, some additional corrections apply to real measurements, like ground and on board delays as the signal
travels through the electronics (reception, amplification, frequency change, re-emission) and as signal goes through the
upper atmosphere... These are mainly biases that can be added to the free space travel time, and can be estimated too
during the orbit determination process.
Upon reception, the station is not able to separate
τu
from
τd
. However, it is able to compute the elapsed time
14
Fig. 7 Two ways pseudo-range measurement
spacecraft trajectory
s(tτd)
c
Q(tτdτu)
τu: uplink
time of flight
fc`
Q(t)
τd: downlink
time of flight
fc`
between emission and reception
τu+τd
. This elapsed time is the basis of the range measurement. In order to have a
measurement that is representative of the mean distance to the spacecraft, it is customary to represent the observed
measurement value as (τu+τd)c/2where c is the speed of light.
Lets first consider a linearized motion for the origin of the downlink leg, at on-board transit time:
Pτd=P+(τd)Û
P(1)
Lets also consider the station point Qat the known fixed date tfor the reception of the signal.
The free parameters are
P
,
Û
P
and
Q
, because we want the orbit determination engine to be able to adjust both the
orbit and station position. The
offset represents the time difference at which
Q(t)
and
P(ζ)
points positions have
been picked up (i.e.
=tζ
) for measurement estimation. The time of flight
τd
is not a free parameter because it is
adjusted to ensure that the following equality always holds:
||PτdQ|| =cτd
Lets differentiate this equation:
[PQ − (τd)Û
P]2=c2τ2
d
2PτdQ·d[PQ − (τd)Û
P]=2c2τddτd
PτdQ· [dQ dP − (τd)dÛ
P]=c2τddτdPτdQ·Û
Pd τd
dτd=
PτdQ· [dQ dP − (τd)dÛ
P]
c2τdPτdQ·Û
P(2)
Now that we know the relationship between the dependent variable
τd
and the free variables
P
,
Û
P
and
Q
that will be
controlled by the orbit determination engine, we can compute the evolution of the relative position vector
QPτd
, by
differentiating linear motion equation (1) and substituting time of flight correction equation (2):
QPτd=QP +(τd)Û
P
dQPτd=[dP dQ +(τd)dÛ
P] − dτdÛ
P
dQPτd=[dP dQ +(τd)dÛ
P]+
PτdQ· [dP dQ +(τd)dÛ
P]
c2τdPτdQ·Û
P
Û
P
which can be written in matrix form, assuming all vectors are column vectors
dQPτd=M[dP dQ +(τd)dÛ
P]with M=I3+
Û
P×PτdQT
c2τdPτdQ·Û
P(3)
15
Equation
(3)
shows two different effects. The first effect is that if the state provided by the propagator is not exactly
synchronized with the spacecraft state when signal leaves it (i.e. if
,τd
), then
dQPτd
does depend on
dÛ
P
. However,
despite states are not synchronized, we can identify the non-syncronism (because we know how to estimate
τd
), and as
long as we remain in the linearity domain, the term in
dÛ
P
takes care of it. The second effect is that as time of flight is
affected by state position changes, the relationship between
dQPτd
and
dQP
is not simply identity, the coupling factor
represented by the matrix
M
involves velocity
Û
P
. This second effect occurs even if states are perfectly synchronized (i.e.
it occurs even if =τd).
The derivatives of the uplink time of flight
τu
are computed in a manner very similar to what was used for the
downlink leg. There are some changes, however. The reception point is
Pτd
instead of
Q
and we already know its
derivatives. The emission point is Qτd+τuinstead of Pτdand it moves as the time of flight changes.
Lets consider a linearized motion for the origin of the uplink leg, at ground emission time, introducing the
instantaneous rotation rate of the Earth with respect to the inertial frame:
Qτd+τu=Q− (τd+τu)Q(4)
One should note that this is a simplified model that is applicable only for Earth orbiting spacecrafts. Linearization is
sufficient only as long as the time of flight is short and as we consider only a rotation, this does not work for probes
orbiting the Sun or other planets, as Earth revolution around Sun is ignored here. So despite the equations will be quite
complex, they are still simplified.
The time of flight τuis adjusted to ensure that the following equality always holds:
||Qτd+τuPτd|| =cτu
Lets differentiate this equation:
[QPτd+(τd+τu)Q]2=c2τ2
u
2Qτd+τuPτd·d[QPτd+(τd+τu)Q]=2c2τudτu
Qτd+τuPτd· [dQPτd+(τd+τu)dQ +Qd τd]=c2τudτuQτd+τuPτd·Qdτu
dτu=
Qτd+τuPτd· [dQPτd+(τd+τu)dQ +Qd τd]
c2τuQτd+τuPτd·Q(5)
At the end, we combine the derivatives of the two times of flight to get the derivatives of the measurement:
dm =(dτd+dτu)c
2
This expression takes into account the partial derivatives of the measurement with respect to the state at
ζ
(which
correspond to the terms
dP
and
dÛ
P
) as well as the partial derivatives of the measurement with respect to one parameter:
the station position (which corresponds to the term dQ).
Equations
(2)
and
(5)
are not trivial and in equation
(3)
, the matrix
M
is not identity despite a quick analysis would
conclude it should be identity. Therefore, this derivation shows that setting up accurate derivatives by using analytical
development quickly goes out of hands, even for a very simple measurement like two-way pseudo-range. The derivation
above has therefore been replaced by something more robust as explained in section III.D.
References
[1]
Maisonobe, L., et al., “Orekit, An accurate and efficient core layer for space flight dynamics applications,” , 2008. URL
https://orekit.org/.
[2]
Maisonobe, L., Cefola, P. J., Frouvelle, N., Herbinière, S., Laffont, F.-X., Lizy-Destrez, S., and Neidhart, T., “Open Governance
of the Orekit Space Flight Dynamics Library,International Conference on Astrodynamics Tools and Techniques, ESA/ESTEC,
2012.
[3]
Ward, E. M., Warner, J. G., and Maisonobe, L., “Do Open Source Tools Rival Heritage Systems? A comparison of tide models
in OCEAN and Orekit,” AIAA/AAS Astrodynamics Specialist Conference, American Institute of Aeronautics and Astronautics,
2014. doi:10.2514/6.2014-4429.
16
[4] Janer, A., Romeu, P. S., and Journot, M., “Orekit in Neosat FDS,” Orekit day, 2017.
[5]
Journot, M., Frouvelle, N., Udroiu, C. I., Barbulescu, L. F., Hogoiu, O. M., Teodorescu, M., Janer, A., and Romeu, P. S.,
“Modular Orekit-based Flight Dynamics Software,” SpaceOps, American Institute of Aeronautics and Astronautics, 2018.
[6] Parraud, P., personal communication, 2016.
[7]
Antolino, A., and Maisonobe, L., “Automatic differentiation for propagation of orbit uncertainties,Stardust final conference,
ESA/ESTEC, 2016.
[8] Raymond, E. S., The Cathedral and the Bazaar, O’Reilly Media, 1999.
[9] Vallado, D. A., Fundamentals of Astrodynamics and Applications, 4th ed., Microcosm Press, 2013, Chap. 10, pp. 777–833.
[10] Steitz, P., et al., “Hipparchus: a mathematics Library,” , 2016. URL https://hipparchus.org/.
[11]
Griewank, A., and Walther, A., Evaluating Derivatives, Principles and Techniques of Algorithmic Differentiation, Society for
Industrial and Applied Mathematics, 2008.
[12]
Kalman, D., “Doubly Recursive Multivariate Automatic Differentiation,” Mathematics Magazine, Vol. 75, 2002, pp. 187–202.
[13]
Cefola, P. J., Long, A. C., and Jr, H. G., “The Long-Term Prediction of Artificial Satellite Orbits,” AIAA 12th Aerospace Science
Meeting, 1974.
[14] McClain, W. D., “A Semianalytic Artificial Satellite Theory,” Tech. rep., Charles Stark Draper Laboratory, 1992.
[15]
Bernard, N., Maisonobe, L., Barbulescu, L., Scortan, S., Cefola, P. J., Casasco, M., and Merz, K., “Validating Short Periodics
Contributions in a Draper Semi-Analytical Satellite Theory Implementation: the Orekit Example,” ISSFD, 2015.
[16]
Cefola, P. J., Sabol, C., Hill, K., and Nishimoto, D., “Demonstration of the DSST State Transition Matrix Time-update Properties
Using the Linux GTDS Program,” Tech. rep., 2011.
[17]
Green, A. J., “Orbit Determination and Prediction Processes for Low Altitude Satellites,” Tech. rep., Charles Stark Draper
Laboratory, 1979.
[18]
Setty, S. J., Cefola, P. J., Montenbruck, O., and Fiedlerd, H., “Application of Semi-analytical Satellite Theory orbit propagator
to orbit determination for space object catalog maintenance,” 2016, pp. 2218–2233.
[19]
de Jonge, P., and Tiberius, C. C. J. M., “The LAMBDA method for integer ambiguity estimation: implementation aspects,”
Tech. rep., Delft Geodetic Computing Centre, 1996.
17
... This corresponds to a revisit time of 17 d. The orbit was propagated for 1 year with a numerical propagator based on the Orekit space flight dynamics library (Maisonobe et al., 2018). ...
Article
Full-text available
ALTIUS (Atmospheric Limb Tracker for the Investigation of the Upcoming Stratosphere) is the upcoming stratospheric ozone monitoring limb sounder from ESA's Earth Watch programme. Measuring in the ultraviolet–visible–near-infrared (UV–VIS–NIR) spectral regions, ALTIUS will retrieve vertical profiles of ozone, aerosol extinction coefficients, nitrogen dioxide and other trace gases from the upper troposphere to the mesosphere. In order to maximize the geographical coverage, the instrument will observe limb-scattered solar light during daytime (i.e. bright limb observations), solar occultations at the terminator and stellar/lunar/planetary occultations during nighttime. This paper evaluates the constraint of ALTIUS ozone profiles on modelled stratospheric ozone by means of an observing system simulation experiment (OSSE). In this effort, a reference atmosphere has been built and used to generate ALTIUS ozone profiles, along with an instrument simulator. These profiles are then assimilated to provide ozone analyses. A good agreement is found between the analyses and the reference atmosphere in the stratosphere and in the extra-tropical upper troposphere. In the tropical upper troposphere, although providing significant information in the analyses, the assimilation of ozone profiles does not completely eliminate the bias with respect to the reference atmosphere. The impacts of the different modes of observations have also been evaluated, showing that all of them are necessary to constrain ozone during polar winters where solar/stellar occultations are the most important during the polar night and bright limb data are the most important during the development of the ozone hole in the polar spring.
... This method prevents the complex task to establish and validate all model derivatives. State transition matrix terms are computed directly from model evolution equations, instead of creating a new differential equation to integrate as it is done in Orekit numerical or semi-analytical orbit determination [5] [6]. Moreover, automatic differentiation is used to create SGP4/SDP4 compliant TLEs from a state vector. ...
Conference Paper
Full-text available
Earth orbital space suffers from the ever increasing count of space objects, including operational satellites and space debris. Space system operations rely on the management of vast catalogs of objects to avoid any damaging collision. NORAD (North American Aerospace Defense Command) and NASA (National Aeronautics and Space Administration) both maintain a database for a large quantity of orbiting objects. Data are stored as Two Line Elements (TLE) and used along with specific analytical propagation models. Operation centers need Orbit Determination methods to accurately compute conjunctions and collision probabilities. With more and more flying objects, computations must be fast enough to ensure satellite safety. Mixing Orbit Determination and TLE analytical propagation models appears to be an effective way to grant security in space. This paper presents an open-source solution for an Orbit Determination method based on TLE propagation models. The method was implemented and validated inside the Orekit space mechanic library. It was then confronted with a classical numerical Orbit Determination on a GNSS test case.
... The first one is a Batch Least Squares algorithm and the other one is a Kalman Filter. The architecture as well as the operating principle of these algorithms in Orekit, are exposed by Maisonobe et al [11]. ...
Conference Paper
Full-text available
Space objects catalog maintenance demands an accurate and fast Orbit Determination (OD) process to cope with the ever increasing number of observed space objects. The development of new methods, that answer the two previous problems, becomes essential. Presented as an alternative to numerical and analytical methods, the Draper Semi-analytical Satellite Theory (DSST) is an orbit propagator based on a semi-analytical theory allowing to preserve the accuracy of a numerical method while providing the speed of an analytical method. This propagator allows computing the mean elements and the short-period effects separately. We reproduced this architecture at the OD process level in order to be able to return, as desired, the mean elements or the osculating elements. Two major use cases are thus possible: fast OD for big space objects catalog maintenance and mean elements OD for station keeping needs. This paper presents the different steps of development of the DSST-OD included in the Orekit open-source library [1]. Integrating an orbit propagator into an OD process can be a difficult process. Computing and validating derivatives is a critical step, especially with the DSST whose equations are very complex. To cope with this constraint, we used the automatic differentiation technique. Automatic differentiation has been developed as a mathematical tool to avoid the calculations of the derivatives of long equations. This is equivalent to calculating the derivatives by applying chain rule without expressing the analytical formulas. Thus, automatic differentiation allows a simpler computation of the derivatives and a simpler validation. Automatic differentiation is also used in Orekit for the propagation of the uncertainties using the Taylor algebra. Existing OD applications based on semi-analytical theories calculate only the derivatives of the mean elements. However , for higher accuracy or if the force models require further development, adding short-period derivatives improves the results. Therefore, our study implemented the full contribution of the short-period derivatives, for all the force models, in the OD process. Nevertheless, it is still possible to choose between using the mean elements or the osculating elements derivatives for the OD. This paper will present how the Jacobians of the mean rates and the short-periodic terms are calculated by automatic differentiation into the DSST-specific force models. It will also present the computation of the state transition matrices during propagation. The performance of the DSST-OD is demonstrated under Lageos2 and GPS Orbit Determination conditions.
Article
This article proposes a method to decentralize the navigation burden and improve the fault tolerance for a spacecraft constellation. The constellation body reference system is introduced, which is the perifocal frame of one satellite in the constellation. The structure of the proposed navigation method is constructed to enable each spacecraft to estimate its own orbit in this body reference system. This step is essentially the relative orbit determination (OD) based on inter-satellite range measurements. Thereafter, the approach to transfer an orbit from the constellation body reference system to an inertial reference system is developed. The essential requirements on absolute measurements to realize the coordinate transfer are presented. By dividing the absolute OD into relative OD and coordinate transfer, each navigation subsystem operated in a spacecraft can be independent with others, and the absolute measurements collected by any spacecraft can contribute to the absolute OD of the whole constellation. The proposed method applies to constellations in any geometric configuration. A Walker constellation is taken as an example for numerical simulations. The results show that the proposed method has a lower computation burden compared to an integrated navigation system. With the same type of absolute measurements, the proposed method has higher accuracy and convergence velocity than conventional decentralized algorithms. When a spacecraft occurs with fault, the orbit results of other spacecraft are not affected using the proposed method, which is beyond the ability of conventional methods.
Preprint
Full-text available
ALTIUS (Atmospheric Limb Tracker for the Investigation of the Upcoming Stratosphere) is the upcoming stratospheric ozone monitoring limb sounder from ESA's Earth Watch programme. Measuring in the ultraviolet-visible-near infrared spectral regions, ALTIUS will retrieve vertical profiles of ozone, aerosol extinction coefficients, nitrogen dioxide and other trace gases from the upper troposphere to the mesosphere. In order to maximize the geographical coverage, the instrument will observe limb- scattered solar light during daytime, solar occultation at the terminator and stellar/lunar/planetary occultations during nighttime. This paper evaluates the constraint of ALTIUS ozone profiles on modelled stratospheric ozone by the means of an Observing System Simulation Experiment (OSSE). In this effort, a reference atmosphere has been built and used to generate ALTIUS ozone profiles, along with an instrument simulator. These profiles are then assimilated to provide ozone analyses. A good agreement is found between the analyses and the reference atmosphere in the stratosphere and in the extra-tropical upper troposphere. In the tropical upper troposphere, although providing a significant weight in the analyses, the assimilation of ozone profiles does not allow to completely eliminate the bias with the reference atmosphere. The weight of the different modes of observations have also been evaluated, showing that all of them are necessary to constrain ozone during polar winters where solar/stellar occultations are the most important during the polar night and limb data are the most important during the development of the ozone hole in the polar spring.
Conference Paper
Full-text available
Orekit is a library for space flight dynamics. It was released under an open-source license in 2008 and has since gained widespread recognition. It has already been used operationally, it has been selected as the basis of new generation systems in agencies, it has been used for several studies and ground systems developments by various industrial actors, and it is used for training purposes at universities. The project has gone through several phases, becoming more and more open at each step. During the first phase, Orekit started as a closed-source product. During the second phase (2008), Orekit switched to a permissive open-source license (Apache License V2) in 2008. The Orekit third phase started in early 2011. The third phase included a collaborative site, with direct public visibility of the development version control system, issue tracker, mailing lists, blog and wiki. The third phase culminated in late 2011 when the first external committer was nominated and gained write access to the source code repository. The Orekit project is now entering its fourth phase, with a completely open governance model, involving representatives from different space field actors in a Project Management Committee (PMC). The Orekit governance model follows the Apache Software Foundation meritocracy. This model is based on several roles (user, contributor, committer, Project Management Committee member and PMC chair). This paper explains the various roles and the rights that are bound to them. Everyone can go through the various roles. The rules to get access to the various roles are explained in the paper. They are based on merit previously earned within the project. Merit is gained through contributions and involvement. The first PMC of the Orekit project is officially set up as the 5 th ICATT conference is taking place. It is composed of people with different affiliations in order to meet the needs of the widest possible range of users. There are representatives of spacecraft manufacturers, academics (both European and US), satellite operators, software industry and independent experts. Representatives of space agencies are expected to join the PMC soon. This PMC will be in charge of defining the roadmap for the future evolution of the Orekit project. The rules for evolution of the PMC are explained in the paper. The role of the PMC is mainly to define global orientation. The technical low level decisions are still taken by the members of the development list where everyone can contribute to discussions, regardless of affiliation and whether they are or not members of the PMC. Orekit is a community oriented project.
Article
Full-text available
Catalog maintenance for Space Situational Awareness (SSA) demands an accurate and computationally lean orbit propagation and orbit determination technique to cope with the ever increasing number of observed space objects. As an alternative to established numerical and analytical methods, we investigate the accuracy and computational load of the Draper Semi-analytical Satellite Theory (DSST). The Standalone version of the DSST was enhanced with additional perturbation models to improve its recovery of short periodic motion. The accuracy of DSST is, for the first time, compared to a numerical propagator with fidelity force models for a comprehensive grid of low, medium, and high altitude orbits with varying eccentricity and different inclinations. Furthermore, the run-time of both propagators is compared as a function of propagation arc, output step size and gravity field order to assess its performance for a full range of relevant use cases. For use in orbit determination, a robust performance of DSST is demonstrated even in the case of sparse observations, which is most sensitive to mismodeled short periodic perturbations. Overall, DSST is shown to exhibit adequate accuracy at favorable computational speed for the full set of orbits that need to be considered in space surveillance. Along with the inherent benefits of a semi-analytical orbit representation, DSST provides an attractive alternative to the more common numerical orbit propagation techniques.
Conference Paper
Full-text available
Among existing orbital propagation techniques, semi-analytical methods are of great interest: by separating the computation of long-term evolution from one side and the short-term variations from the other side, they tend to be significantly faster than classical numerical methods while keeping similar accuracy. The implementation of the Draper Semi-analytical Satellite Theory (DSST) into the free OREKIT library offers to the astrodynamics community one of the most mature and versatile semi-analytical propagator. This paper focuses on the validation process of this implementation covering a large panel of orbits, from LEO to HEO. Comparison with legacy Fortran 77 software demonstrated a great consistency.
Conference Paper
Full-text available
Open source software tools have been gaining acceptance in the astrodynamics community for some applications, though heritage tools still dominate precision orbit determination and propagation. This paper examines recent tide modeling improvements in the open source Orbit Extrapolation Toolkit (Orekit) and compares it with the US Naval Research Laboratory's (NRL) heritage Orbit Covariance Estimation And ANalysis (OCEAN) system. First, the two tools are compared directly against each other by propagating a given state vector for Stella, a geodetic satellite sensitive to tidal variations in the geopotential. Second, orbits were fit to International Laser Ranging Service (ILRS) laser ranging data using OCEAN and orbit determination software built around Orekit so that a more useful comparison could be made. Five days of data were used to solve for orbital parameters using OCEAN and Orekit. This solution orbit is then propagated forward 25 days and compared to subsequent five day orbit solutions. This comparison between predicted and fitted orbit solutions is used as a metric to compare the quality of each piece of software's dynamic modeling capability. Results from the direct orbit propagation comparison indicate the RSS of postion difference between the OCEAN and Orekit propagated orbit grow to only 7 meters over 25 days. It is also seen that the difference between OCEAN's and Orekit's implementation of Earth tides are less than 3% of the total tidal effect. The results of the orbit determination analysis show that the Orekit orbit solution comparison is at worst on the same order of magnitude in accuracy as the OCEAN orbit solution comparison, and at best more accuate than the OCEAN orbit solution comparison. While OCEAN produces a more accurate orbit prediction than Orekit in the majority of the cases studied, more testing is need to understand the origin of the difference.
Article
Full-text available
The semi-analytical theory for the motion of a space object replaces the conventional equations of motion with two formulas: (1) equations of motion for the mean equinoctial elements, and (2) expressions for the short periodic motion in the equinoctial elements. Very complete force models have been developed for the mean element equations of motion and for the short periodic motion. There is also a semi-analytical theory for the partial derivatives of the perturbed motion. An interpolation strategy greatly assists in producing the mean elements, the osculating elements, the perturbed position and velocity, and the partial derivatives at the output request times. The semi-analytical satellite theory has been interfaced with a variety of batch least squares and Kalman Filter estimation processes. The current effort improves the software implementation of the semi-analytical theory for the partial derivatives so that (1) the mean element state transition matrix can be integrated backwards in time consistent with the interpolation architecture and (2) the epoch in a mean element orbit determination process can have an arbitrary location in a span of observation data. Both of these new capabilities support studies of the propagation of the state error covariance in the mean equinoctial elements. The paper describes the mathematical formulation and the software implementation in the Linux GTDS DSST program, and provides several test cases to illustrate the capabilities.