[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] Roadmap for next version


I think this is a great list of new features for Orekit. As you know
from our conference paper I have a simple OD application based on
Orekit, and I think some parts of it are general enough that they could
be included in Orekit. I will check with my management to see if this is
something I can contribute. I'm afraid I won't be any help for the low
thrust work though.

I think in our follow on discussion about accelerations we should also
discuss the dividing line between the Orbit classes and the Propagator

One other aspect that I think deserves some attention is generating TLEs
using Orekit. My experience with the current has been hit or miss. If I
have some time next week I'll try to upload some test cases.


On 01/28/2015 10:04 AM, MAISONOBE Luc wrote:
> 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 implementathrougttions),
> 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

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature