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