Content uploaded by Luc Maisonobe

Author content

All content in this area was uploaded by Luc Maisonobe on Jul 03, 2018

Content may be subject to copyright.

Content uploaded by Luc Maisonobe

Author content

All content in this area was uploaded by Luc Maisonobe on Jun 04, 2018

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 ﬂ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.

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-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 [

1

] 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

∗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 ﬂight dynamics library developed since 2002, ﬁrst 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 ﬁ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

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 speciﬁc 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 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

∗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 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

3

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

years [3].

The ﬁrst 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 speciﬁc

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 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 [

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 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 [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 ﬁ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 [

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 ﬁ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 [

10

], which is the open-source mathematical library

Orekit uses.

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

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 ﬂight 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 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

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 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

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 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

Model

will call the implementation

of

ProcessNoiseMatrixProvider

that was conﬁgured 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 ﬁ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

6

Fig. 1 batch least squares overview

the eﬀect 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 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

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 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:

7

Fig. 2 Kalman ﬁlter overview

mk←f(tk,yk,p)

i←1

do

mk←ci(mk,tk,yk,p)

i←i+1

while i≤imax

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 eﬀect (say the geometric distance between ground station and spacecraft)

and

ci

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:

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 eﬀect

f(tk,yk,p)

is what is computed when

ObservedMeasurement

ﬁrst 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

speciﬁc

ci

, 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

ObservedMeasurement

and

EstimationModifier

interfaces, which ensures extensibility of the orbit determination package to mission-speciﬁc

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 oﬀset 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

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

10

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

−6

and the central attraction coeﬃcient (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

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

(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 ﬁ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

diﬀerentiation [

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 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

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 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.

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 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).

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 ﬁ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 [

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 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

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 ﬁ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 [

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 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.

Appendix

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

τu

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

τd

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

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, 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

τ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 ﬂight

fc`

Q(t)

τd: downlink

time of ﬂight

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 ﬁrst 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 ﬁxed 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

∆

oﬀset represents the time diﬀerence at which

Q(t)

and

P(ζ)

points positions have

been picked up (i.e.

∆=t−ζ

) for measurement estimation. The time of ﬂight

τd

is not a free parameter because it is

adjusted to ensure that the following equality always holds:

||PτdQ|| =cτd

Lets diﬀerentiate 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τd−PτdQ·Û

Pd τd

dτd=

PτdQ· [dQ −dP − (∆−τd)dÛ

P]

c2τd−Pτ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

diﬀerentiating linear motion equation (1) and substituting time of ﬂight 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τd−Pτ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τd−PτdQ·Û

P(3)

15

Equation

(3)

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

∆,τ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 eﬀect is that as time of ﬂight is

aﬀected 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 eﬀect occurs even if states are perfectly synchronized (i.e.

it occurs even if ∆=τd).

The derivatives of the uplink time of ﬂight

τ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 ﬂ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:

Qτd+τu=Q− (τd+τu)Ω∧Q(4)

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:

||Qτd+τuPτd|| =cτu

Lets diﬀerentiate 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τu−Qτd+τuPτd·Ω∧Qdτu

dτu=

Qτd+τuPτd· [dQPτd+(τd+τu)Ω∧dQ +Ω∧Qd τd]

c2τu−Qτd+τuPτd·Ω∧Q(5)

At the end, we combine the derivatives of the two times of ﬂight 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 eﬃcient core layer for space ﬂight dynamics applications,” , 2008. URL

https://orekit.org/.

[2]

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,

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 diﬀerentiation for propagation of orbit uncertainties,” Stardust ﬁnal 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 Diﬀerentiation, Society for

Industrial and Applied Mathematics, 2008.

[12]

Kalman, D., “Doubly Recursive Multivariate Automatic Diﬀerentiation,” Mathematics Magazine, Vol. 75, 2002, pp. 187–202.

[13]

Cefola, P. J., Long, A. C., and Jr, H. G., “The Long-Term Prediction of Artiﬁcial Satellite Orbits,” AIAA 12th Aerospace Science

Meeting, 1974.

[14] McClain, W. D., “A Semianalytic Artiﬁcial 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