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 ﬂight 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 diﬃcult to operate as user-friendliness is not
their primary goal. Commercial oﬀ-the-shelf systems are available but at a high price tag and
without any way for user to add their speciﬁcities. This paper describes the fully open-source
orbit determination package that has been made available since 2016 in the Orekit space ﬂight
dynamics library. It presents ﬁrst the history of the package and how it started as a tool for
regular operations using classical measurements and how it evolved to include ﬁner and ﬁner
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.
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-speciﬁc methods
and models. Some are only used for research as they require speciﬁc 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 [
] space ﬂight dynamics library with an
orbit determination package. This package was ﬁrst published as of version 8.0 of the library, and signiﬁcantly improved
with version 9.0 released in mid 2017. This orbit determination package was at ﬁrst 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 oﬀ the shelf package. This ﬁrst 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 fulﬁlled needs that were ﬁrst only available using research-level
or agency tools. The improvements included multi-satellite orbit determination, much more accurate derivations,
inclusion of very ﬁne 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-speciﬁc
needs. This paper describes ﬁrst 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
implementation of the multi-satellites features. Results and performances are shown. It ends with a presentation of a
roadmap for future extensions.
Orekit is a space ﬂight dynamics library developed since 2002, ﬁrst as a CS-SI internal product. It was released as
open source in 2008  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 ﬁrst 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 simpliﬁed 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 diﬃcult at that time to ﬁt
the contribution into the current library version than it was three years before. We ﬁnally 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 ﬂy during propagation at measurements times
propagators optimizers initially created for models conversion that allowed to ﬁnd the propagator conﬁguration
most consistent with a precomputed ephemeris
Tables 1 and 2 present the orbit determination features roughly classiﬁed in the perspectives of projects foreseen by
the Orekit team. This classiﬁcation is of course subject to interpretation and arbitration, it was only used for setting
correspond to mandatory features that are needed even for the least demanding missions that
could tolerate errors up to a few meters
correspond to nice to have features or features useful for some speciﬁc missions (like
turn-around range measurements), these features are mandatory if a below meter accuracy is required for the
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 identiﬁed during the ﬁrst 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 classiﬁed as basic operations and the two extended operations features corresponding to user-provided
‡https://www.orekit.org/forge/projects/orbit-determination- telespazio-s- contribution
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 eﬀects 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
measurements and corrections were considered. The rationale behind this choice was that extensions would have a
dramatic eﬀect 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 ﬂy as they ﬁtted 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 reaﬀected 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 diﬀerent use cases. The ﬁrst 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 ﬁles or similar) and rebuilding a complete orbital model from the
ephemeris data in order to extend it past the ﬁle end.
The partial orbit determination feature may seem strange at ﬁrst sight. It is strange and should be very seldom used.
It was not really added intentionally, but was a side-eﬀect of the design of parameters drivers (see section III.C). By
default, all orbital parameters are always estimated, but users can switch oﬀ 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 ﬁnd. 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
The ﬁrst version of the orbit determination feature was made available on 2016-06-30 with version 8.0 of the Orekit
C. Second phase, addressing extended needs
Once a general purpose orbit determination tool was available, the Orekit team members focused on more speciﬁc
needs that they faced for some operational systems [
]. 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 speciﬁc, 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 ﬁrst 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 [
], 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...
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 diﬀerence 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 ﬁles science (geodesy)
loading of Antex ﬁles science (geodesy)
constellation-speciﬁc 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 . 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 ﬁles 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 ﬁrst phases.
D. Towards high accuracy
The ﬁrst 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 ﬁlter that runs continuously and updates the
estimations as new measurements are processed.
A Kalman ﬁlter [
] 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 ﬁlter 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 ﬁlter was ﬁrst 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 ﬂight
dynamics layer that deals with orbital parameters, propagation parameters and measurements parameters. The underlying
mathematical framework was contributed to the Hipparchus project [
], which is the open-source mathematical library
Then as the trend towards very high accuracy and navigation was conﬁrmed, 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 oﬃcial releases of the library. As of writing (April 2018), most of the features are already implemented and the
oﬃcial 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
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 ﬂight dynamics creates an orbit determination problem as an implementation of the domain-agnostic
interface, which can be handled by any of the
(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 conﬁgured 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 ﬂight 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 ﬂy during the propagation
, 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 diﬀerence 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 ﬁlter
The architecture of the Kalman estimator is explained in the class diagram 2. The Kalman estimator is an extended
ﬁlter, devoted to non-linear processes. Measurements are fed one at a time to the non-linear
, which is an
implementation of the domain-agnostic
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 diﬃcult part in using a Kalman ﬁlter 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 diﬀerent 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
will call the implementation
that was conﬁgured for a given propagator and expect it to return appropriate
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 ﬁne 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 simpliﬁed 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 ﬁrst run of Taylor algebra during the mission analysis phase, to monitor how the high order
uncertainties evolve, and to ﬁt a time-dependent ellipsoid on this evolution. Then a Kalman ﬁlter 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
Fig. 1 batch least squares overview
the eﬀect of each force models (see for example [
]). Class diagram 2 was drawn in such a situation, where the user
implemented the ProcessNoiseMatrixProvider using a custom MyProcessNoiseMatrixProvider.
B. Raw measurements and modiﬁers
As Orekit is a library, it can be used in diﬀerent environments and for various missions. The physical models
to use may be diﬀerent from one use to another. Even considering a basic measurement like two-way pseudo-range,
the number of corrections to apply and their ﬁne tuning are very diﬀerent for a geodesy study and for a commercial
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 eﬀects and by
regular telecommunication operators that are happy with a few meters and do not want to deal with downloading huge
correction data from scientiﬁc institutions each day.
Diving into the measurements equations, one can see they are always iterative and in the form:
Fig. 2 Kalman ﬁlter overview
is the estimated value for measurement number
is the measurement date,
is the state at
the measurements parameters, fis the main eﬀect (say the geometric distance between ground station and spacecraft)
are correction eﬀects 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:
Therefore, the design that was adopted is to separate all elements (
and all the
) in separate
objects and let the user decide which elements to consider for each measurement. This is depicted in class diagram 3. The
is what is computed when
ﬁrst creates the
are what is computed when
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
, and add it in the list of eﬀects to consider, taking care to not add the other tropospheric eﬀects so the eﬀect 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 modiﬁers is done by implementing the
interfaces, which ensures extensibility of the orbit determination package to mission-speciﬁc
Fig. 3 measurements
C. How to estimate parameters from user-provided models
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
How could an existing orbit determination package tune a parameter embedded deep inside a model it doesn’t know
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 oﬀset parameters. However, the
ground station can provide to the upper layers a list of
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
Fig. 4 driving low level parameters from the optimizer
conﬁgure for each parameter driver if it is ﬁxed or if it should be estimated.
When users add their own measurements, their own modiﬁers 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 notiﬁed synchronously when the
value is changed by the estimator.
This decoupling between the lower and upper layers of the orbit determination greatly simpliﬁes evolutive maintenance
of the package and extensibility for users. It was used for example between the ﬁrst 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 oﬀset, prime meridian drift, pole oﬀsets 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 eﬀect: being driven by parameters
drivers, orbital parameters could be selectively considered as ﬁxed 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 ﬁrst validation attempts in the ﬁrst 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 ﬁrst, 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
multiplication) and it was numerically checked.
The problem was in fact related to a state vector having components with very diﬀerent 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
and the central attraction coeﬃcient (which was estimated in a stress test) and is of the order of magnitude of 10
The Levenberg-Marquardt estimator behaved badly with a vector where two components had 22 orders of magnitude
diﬀerence. It was therefore a simple and classical problem of using raw values of parameters instead of normalizing
them. Once identiﬁed, 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 diﬃcult to set up correctly and it delayed the ﬁrst release a few weeks.
3. Simple bounds
A ﬁnal 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 ineﬃcient 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 ﬁrst, we used as everyone else explicit analytic equations for the derivatives. This was not to diﬃcult 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 ﬁnite diﬀerences, we identiﬁed 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 inﬂuence 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
in appendix are not trivial and
in the equation
, the matrix
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 ﬁrst 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
]. It is provided by the Hipparchus [
] mathematical library and is able to compute derivatives to any
order and with any number of parameters .
The basic idea behind algorithmic diﬀerentiation is that you only implement the equation you want to diﬀerentiate,
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
or any other
double function. When performing all these elementary operations (add, subtract, ...,
, ...) 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 [
] are very generic and allow to compute derivatives to any order
and with respect to any number of parameters. The
class provided by Hipparchus for this
purpose also implements the hints presented at the end of Dan Kalman’s paper to improve eﬃciency 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
diﬀerentiation. This ensured derivatives are extremely accurate and don’t rely on any assumption or simpliﬁcation.
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 diﬀerent 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 ﬁnd 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 coeﬃcient, 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 ﬁxing the reﬂection coeﬃcient
to a standard value (+2.0).
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 ﬁrst 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 ﬁles and basic one-way pseudo-range. Dynamic
model and measurement models were not reﬁned at this stage. There was a lot of room for improvement, but for a ﬁrst
result, it was considered promising.
V. Future work
A. Orbit determination for DSST semi-analytical propagator
The Draper Semi-Analytical Satellite Theory [
] 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
]. 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 modiﬁed by the optimizer at each
step, their indirect evolution will be much smaller that the direct evolution of the mean elements. Therefore, the orbit
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 [
] that was implemented using the Field mechanism from
Hipparchus that allows to do computation on any type that has the same properties as the ﬁeld of real numbers (addition,
subtraction, multiplication and also scientiﬁc functions like trigonometric, hyperbolic, logarithmic...). Section III.D
already presented one use of ﬁelds 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 conﬁgure a propagation to use a simple ﬁrst 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 diﬀerent way to compute what the numerical propagators does with variational
equations. The diﬀerence 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 ﬁrst part was already done and the oﬃcial release is expected to occur just before the SpaceOps
conference. It contains phase measurements with combinations that remove the integer ambiguities (simple and double
diﬀerences). 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 [
] for dealing directly with
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 speciﬁc missions, even
adding user-provided measurements and corrections. The system is readily available and used in diﬀerent contexts.
New features are added regularly and the trend is to go towards extremely accurate GNSS handling.
This appendix presents a derivation of computation of pseudo-range measurement derivatives taking into account
some often neglected eﬀects. This was used in an early implementation of the pseudo-range measurement and was
discarded later on as we switched to algorithmic diﬀerentiation as explained in section III.D.
A pseudo-range measurement is a two ways measurement. A signal is ﬁrst emitted from a ground station, it travels
along the uplink leg for a
time of ﬂight, arrives at the spacecraft, transits on-board and is re-emitted back to ground.
It then travels along the downlink leg for a
time of ﬂight 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 oﬀsets with respect
to this reception time. Station position at reception time is
, 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, ampliﬁcation, 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
. However, it is able to compute the elapsed time
Fig. 7 Two ways pseudo-range measurement
time of ﬂight
time of ﬂight
between emission and reception
. 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 ﬁrst consider a linearized motion for the origin of the downlink leg, at on-board transit time:
Lets also consider the station point Qat the known ﬁxed date tfor the reception of the signal.
The free parameters are
, because we want the orbit determination engine to be able to adjust both the
orbit and station position. The
oﬀset represents the time diﬀerence at which
points positions have
been picked up (i.e.
) for measurement estimation. The time of ﬂight
is not a free parameter because it is
adjusted to ensure that the following equality always holds:
Lets diﬀerentiate this equation:
[PQ − (∆−τd)Û
2PτdQ·d[PQ − (∆−τd)Û
PτdQ· [dQ −dP − (∆−τd)dÛ
PτdQ· [dQ −dP − (∆−τd)dÛ
Now that we know the relationship between the dependent variable
and the free variables
that will be
controlled by the orbit determination engine, we can compute the evolution of the relative position vector
diﬀerentiating linear motion equation (1) and substituting time of ﬂight correction equation (2):
dQPτd=[dP −dQ +(∆−τd)dÛ
P] − dτdÛ
dQPτd=[dP −dQ +(∆−τd)dÛ
PτdQ· [dP −dQ +(∆−τd)dÛ
which can be written in matrix form, assuming all vectors are column vectors
dQPτd=M[dP −dQ +(∆−τd)dÛ
shows two diﬀerent eﬀects. The ﬁrst eﬀect is that if the state provided by the propagator is not exactly
synchronized with the spacecraft state when signal leaves it (i.e. if
does depend on
despite states are not synchronized, we can identify the non-syncronism (because we know how to estimate
), and as
long as we remain in the linearity domain, the term in
takes care of it. The second eﬀect is that as time of ﬂight is
aﬀected by state position changes, the relationship between
is not simply identity, the coupling factor
represented by the matrix
. This second eﬀect occurs even if states are perfectly synchronized (i.e.
it occurs even if ∆=τd).
The derivatives of the uplink time of ﬂight
are computed in a manner very similar to what was used for the
downlink leg. There are some changes, however. The reception point is
and we already know its
derivatives. The emission point is Qτd+τuinstead of Pτdand it moves as the time of ﬂight 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:
One should note that this is a simpliﬁed model that is applicable only for Earth orbiting spacecrafts. Linearization is
suﬃcient only as long as the time of ﬂight 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 simpliﬁed.
The time of ﬂight τuis adjusted to ensure that the following equality always holds:
Lets diﬀerentiate this equation:
Qτd+τuPτd· [dQPτd+(τd+τu)Ω∧dQ +Ω∧Qd τd]=c2τudτu−Qτd+τuPτd·Ω∧Qdτu
Qτd+τuPτd· [dQPτd+(τd+τu)Ω∧dQ +Ω∧Qd τd]
At the end, we combine the derivatives of the two times of ﬂight to get the derivatives of the measurement:
This expression takes into account the partial derivatives of the measurement with respect to the state at
correspond to the terms
) as well as the partial derivatives of the measurement with respect to one parameter:
the station position (which corresponds to the term dQ).
are not trivial and in equation
, the matrix
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.
Maisonobe, L., et al., “Orekit, An accurate and eﬃcient core layer for space ﬂight dynamics applications,” , 2008. URL
Maisonobe, L., Cefola, P. J., Frouvelle, N., Herbinière, S., Laﬀont, 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,
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,
 Janer, A., Romeu, P. S., and Journot, M., “Orekit in Neosat FDS,” Orekit day, 2017.
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.
 Parraud, P., personal communication, 2016.
Antolino, A., and Maisonobe, L., “Automatic diﬀerentiation for propagation of orbit uncertainties,” Stardust ﬁnal conference,
 Raymond, E. S., The Cathedral and the Bazaar, O’Reilly Media, 1999.
 Vallado, D. A., Fundamentals of Astrodynamics and Applications, 4th ed., Microcosm Press, 2013, Chap. 10, pp. 777–833.
 Steitz, P., et al., “Hipparchus: a mathematics Library,” , 2016. URL https://hipparchus.org/.
Griewank, A., and Walther, A., Evaluating Derivatives, Principles and Techniques of Algorithmic Diﬀerentiation, Society for
Industrial and Applied Mathematics, 2008.
Kalman, D., “Doubly Recursive Multivariate Automatic Diﬀerentiation,” Mathematics Magazine, Vol. 75, 2002, pp. 187–202.
Cefola, P. J., Long, A. C., and Jr, H. G., “The Long-Term Prediction of Artiﬁcial Satellite Orbits,” AIAA 12th Aerospace Science
 McClain, W. D., “A Semianalytic Artiﬁcial Satellite Theory,” Tech. rep., Charles Stark Draper Laboratory, 1992.
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.
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.
Green, A. J., “Orbit Determination and Prediction Processes for Low Altitude Satellites,” Tech. rep., Charles Stark Draper
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.
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.