Hi all,
Now that 7.0 is finally out, it is time to think about next version.
Here are some of the thoughts from the CS Toulouse team. We would like
to discuss about it and hear about other ideas from the rest of the
Orekit community.
Orbit Determination
-------------------
This is the evergreen lacking feature in Orekit, which corresponds
to issue number 1 in our tracker
<https://www.orekit.org/forge/issues/1>.
There is already a contribution from Telespazio in the Orekit labs
<https://www.orekit.org/forge/projects/orbit-determination-telespazio-s-contribution>,
but it needs some work to be merged into Orekit core (design is not in
line with Orekit standards, measurements types are not object oriented,
...).
We know several other users did develop their own orbit determination
systems (I am aware of at least four other implementations), but none
have been
contributed to Orekit.
We think some low level building blocks should be made available in
Orekit
so users can easily create full-fledged orbit determination systems.
We already
have some of these blocks. One such block is the full integration of
state
transition matrices as well as partial derivatives of state with
respect to
model parameters in the numerical propagator (implemented using
variational
equations). Another block is the least squares adjustment of initial
orbit
used in propagator conversion. It would be nice to also provide a
proper Measurement
interface with several Orekit-provided implementation for traditional
measurement
types (range, range-rate, angular, 3D point) and perhaps more exotic
ones (double-range
turn-around measurements, angular measurements of ground references
extracted from
on-board remote sensing, ...). It should be possible to include biases
at different
levels (for example at ground-station level where it would be
different for all ground
stations or at spacecraft level where it would be shared among all
measurements of
the same type). It would also be nice to be able to go through
maneuvers and even
to calibrate maneuvers. Perhaps loading CCSDS tracking data messages
(CCSDS 503.0-B-1)
should be included too, just as we already support other CCSDS
standards.
Of course, the goal is not to implement everything up to
mission-specific loading of
meta-data like special measurements formats, calibration or
pre-processing features,
but only to provide at Orekit level the general purpose parts and
standard-compliant
parts with some high-level API.
We would like to have orbit determination for both the numerical
propagator and the
DSST propagator which is now complete.
Low-thrust
----------
Low-thrust was not already registered in the issue tracker, but we are
considering
it right now. Modeling the thrust itself is not a problem at all, it
is just another
force model with some specificities. What is more challenging is
computing a maneuver
that allows to reach some predefined target: a longitude rendez-vous
for low thrust
orbit raising for geostationary LEOP, a planet or asteroid fly-by for
interplanetary
scientific missions. This is completely different from traditional
maneuvers which
can be computed by an initial guess using analytical models and
impulse maneuver
approximation followed by numerical optimization. Computing useful
low-thrust maneuvers
relates to optimal control with both the attitude law and the thrust
amplitude being
part of the control law to be found. Depending on the case, the
amplitude may be continuous
or simply on/off as in bang-bang control which often arise in
minimum-time problems.
About 20 years ago, the method of choice for solving this kind of
problems were
indirect methods, with a Two-Point Boundary Value Problem and using
shooting methods
to solve it. It seems these methods are droped and the current trend
is more about
direct method and more precisely Ross-Fahroo pseudospectral methods.
Neither methods are available in Apache Commons Math nor in Orekit, so
we would need
to add them. I first thought about a three stage process, implementing
first a TPBVP
solver in Apache Commons Math, then some interfaces for optimal
control still in
Apache Commons Math, and last using this framework in Orekit. I know
think it would be
more efficient to directly look at Ross-Fahroo for the low-thrust
problem, i.e.
merge all three steps into one for a specific problem and not the
general case.
Acceleration clean-up
---------------------
This task belongs more to day-to-day maintenance of the library, but
it is related
to the API, so worht discussing here. During the vote for the release
of version 7.0
on the PMC list, there were some issues about the current API as it
mandated providing
dynamics in some places were it looked kinematics only should have
been sufficient. Some
last minutes changes were made to solve this, but it was not possible
to fix all issues.
We clearly missed some feedback a few months ago when the feature was
introduced. The focus
shifted to solving the Eackstein-Hechler problem but the feature API
was probably neglected.
We think it is worth asking again to the community to review the
current API and to discuss
all together about what to do.
A foolow-up of this discussion should be to use the new feature more
thoroughsly in the
library.
One expected benefit would be to improve again some frame transforms.
We are
already quite fast as we use interpolation in the most costly
transforms (mainly nutation
computation with the MHB2000 model for IERS conventions 2003 and
2010), but in some cases
this is not sufficient. For example in some specific use in the Rugged
terrain-to-sensor
mapping library, we observed that we spent quite some time in the
interpolator, and we
had to use another layer and replace n-points interpolation with
1-point extrapolation with
a higher density sample as extrapolation (i.e. method shiftedBy()) was
faster than
interpolation. Adding angular acceleration in the samples at
FramesFactory level would
allow us to retrofit this trick into Orekit for everyone's benefit.
Another expected benefit would be to allow propagating oribts in
non-inertial frames
or to integrate orbits in frames not located at central body, included
cases without
a main central body (Lagrange points ...).
Infrared and Albedo radiation pressure
--------------------------------------
Two force models identified a long time ago are still missing in
Orekit: infrared
radiation pressure from central body and albedo radiation pressure
from central body.
It would be nice to finally include them. Beware that this can ranged
from very simple
to more complex depending on the model used.
What does the community think about thess tasks? Do some of you
already have something
that could be contributed to Orekit? Would some of you want to work on
this?
best regards,
Luc