[Orekit Developers] Roadmap for next version

[MAISONOBE Luc <luc.maisonobe@c-s.fr>]

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