Luc, 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 classes. 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. Thanks, Evan 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