Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2021-03-06T21:00:16Zhttps://gitlab.orekit.org/orekit/orekit/-/issues/764Expose underlying UTC-TAI data in UTCScale2021-03-06T21:00:16ZAndrew GoetzExpose underlying UTC-TAI data in UTCScaleI would like an easy way to access the raw UTC-TAI offset data which underlie a `UTCScale`. I don't see any easy way of extracting that data right now. Thus, I would like to add a `getUTCTAIOffsets()` method to `UTCScale`.I would like an easy way to access the raw UTC-TAI offset data which underlie a `UTCScale`. I don't see any easy way of extracting that data right now. Thus, I would like to add a `getUTCTAIOffsets()` method to `UTCScale`.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/763Add support for IGS SSR data2021-03-02T14:57:26ZBryan CazabonneAdd support for IGS SSR dataIn October 2020, IGS released the first format for SSR (State Space Representation) data: https://files.igs.org/pub/data/format/igs_ssr_v1.pdf
It could be interesting to start the implementation of this format in OrekitIn October 2020, IGS released the first format for SSR (State Space Representation) data: https://files.igs.org/pub/data/format/igs_ssr_v1.pdf
It could be interesting to start the implementation of this format in Orekit11.0https://gitlab.orekit.org/orekit/orekit/-/issues/762TabulatedLofOffset should implement BoundedAttitudeProvider2021-03-05T18:40:52ZBryan CazabonneTabulatedLofOffset should implement BoundedAttitudeProviderSame as #761 but for `TabulatedLofOffset`.Same as #761 but for `TabulatedLofOffset`.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/761TabulatedProvider should implement BoundedAttitudeProvider2021-02-26T08:39:23ZLuc MaisonobeTabulatedProvider should implement BoundedAttitudeProviderTable is bounded, so the provider must be too.Table is bounded, so the provider must be too.11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/760TabulatedProvider ignores frame passed in getAttitude call2021-02-25T17:21:49ZLuc MaisonobeTabulatedProvider ignores frame passed in getAttitude callWhen a `TabulatedProvider` is created, it has a set of predefined attitudes
that have been computed in a fixed reference frame.
When the `getAttitude()` method is called, user can ask for the attitude
in a different frame. This is currently ignored, the returned attitude
is just interpolated in the table and no frames conversion is attempted.When a `TabulatedProvider` is created, it has a set of predefined attitudes
that have been computed in a fixed reference frame.
When the `getAttitude()` method is called, user can ask for the attitude
in a different frame. This is currently ignored, the returned attitude
is just interpolated in the table and no frames conversion is attempted.11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/759Add support for JB2008 (atmosphere model) input data2021-03-02T14:57:00ZBayden PritchardAdd support for JB2008 (atmosphere model) input dataCurrently the JB2008InputParameters interface is not implementedCurrently the JB2008InputParameters interface is not implemented11.0https://gitlab.orekit.org/orekit/orekit/-/issues/758Support alpha-5 TLE satellite numbers2021-03-02T14:57:45ZMark RuttenSupport alpha-5 TLE satellite numbersUS Space Force have introduced a new form of 5-digit satellite number (a combination of a letter and numbers) that allows for numbers > 99,999. Orekit currently expects the satellite numbers to be decimal digits.
From the [space-track documentation](https://www.space-track.org/documentation#tle-alpha5):
Alpha-5 is a stopgap object numbering schema from the United States Space Force that increases the satellite catalog’s capacity to display up to 339,999 objects in the GP/GP_History API classes using legacy fixed-width Two and Three Line Element Set (TLE/3LE) formats.
Replacing the 1st digit of the 5-digit object number with an alphanumeric character makes it possible to represent 240,000 more numbers. Objects less than 100,000 are unaffected by Alpha-5, as are users who download elsets from the GP and GP_History API classes in other formats like XML, JSON, KVN, and CSV. In order to preserve legacy operations that depend on 5-digit integers, our legacy API Classes tle, tle_latest, and tle_publish will not change to Alpha-5.
Only capital letters and numbers are used in Alpha-5. The letters “I” and “O” are omitted to avoid confusion with the numbers “1” and “0”.US Space Force have introduced a new form of 5-digit satellite number (a combination of a letter and numbers) that allows for numbers > 99,999. Orekit currently expects the satellite numbers to be decimal digits.
From the [space-track documentation](https://www.space-track.org/documentation#tle-alpha5):
Alpha-5 is a stopgap object numbering schema from the United States Space Force that increases the satellite catalog’s capacity to display up to 339,999 objects in the GP/GP_History API classes using legacy fixed-width Two and Three Line Element Set (TLE/3LE) formats.
Replacing the 1st digit of the 5-digit object number with an alphanumeric character makes it possible to represent 240,000 more numbers. Objects less than 100,000 are unaffected by Alpha-5, as are users who download elsets from the GP and GP_History API classes in other formats like XML, JSON, KVN, and CSV. In order to preserve legacy operations that depend on 5-digit integers, our legacy API Classes tle, tle_latest, and tle_publish will not change to Alpha-5.
Only capital letters and numbers are used in Alpha-5. The letters “I” and “O” are omitted to avoid confusion with the numbers “1” and “0”.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/757Dynamic outlier filter and multiplexed measurements2021-02-16T15:26:04Zandrea fiorentinoDynamic outlier filter and multiplexed measurements[Relevant forum discussion here](https://forum.orekit.org/t/dynamic-outlier-filter-and-multiplexed-measurements/1104).
As of now, the dynamic outlier filter doesn't seem to be correctly applied to Multiplexed measurements before computation of innovation.
The measurement as a whole should be tagged as rejected if and only if all the observables are rejected. In this case no innovation should be computed.
On the other hand, if only a (proper) subset of the observables is accepted for processing, the innovation should be computed by only taking those into account.[Relevant forum discussion here](https://forum.orekit.org/t/dynamic-outlier-filter-and-multiplexed-measurements/1104).
As of now, the dynamic outlier filter doesn't seem to be correctly applied to Multiplexed measurements before computation of innovation.
The measurement as a whole should be tagged as rejected if and only if all the observables are rejected. In this case no innovation should be computed.
On the other hand, if only a (proper) subset of the observables is accepted for processing, the innovation should be computed by only taking those into account.https://gitlab.orekit.org/orekit/orekit/-/issues/756Add new method signature for IodGooding2021-02-25T17:21:33ZBryan CazabonneAdd new method signature for IodGoodingSame as #753 but for `IodGooding`.Same as #753 but for `IodGooding`.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/755Remove Frame argument in IodGooding constructor2021-02-25T17:21:34ZBryan CazabonneRemove Frame argument in IodGooding constructorFor the three other IOD methods in Orekit (Gibbs, Lambert, and Laplace) the `Frame` is defined in the `estimate()` method signature. However, for Gooding method it is defined in the constructor.
For consistency between IOD methods, it could be interesting to move the `Frame` definition from the constructor to the `estimate()` method. Furthermore, it will allow having only one instance of IOD Gooding calculating orbits in different frames.For the three other IOD methods in Orekit (Gibbs, Lambert, and Laplace) the `Frame` is defined in the `estimate()` method signature. However, for Gooding method it is defined in the constructor.
For consistency between IOD methods, it could be interesting to move the `Frame` definition from the constructor to the `estimate()` method. Furthermore, it will allow having only one instance of IOD Gooding calculating orbits in different frames.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/754Add support for Space-Based Visible (SBV) observations2021-02-10T08:53:08ZBryan CazabonneAdd support for Space-Based Visible (SBV) observationsSpace-Based Visible (SBV) observations are optical observations of space objects from a satellite mounted telescope.
In other words, they represent inter-satellites angular measurements.Space-Based Visible (SBV) observations are optical observations of space objects from a satellite mounted telescope.
In other words, they represent inter-satellites angular measurements.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/753Add new method signature for IodLaplace2021-02-25T17:21:33ZBryan CazabonneAdd new method signature for IodLaplaceLaplace method uses three angular observations to calculate an initial orbit.
Currently, the `IodLaplace` class has only one signature for the `estimate` method. This signature uses `Vector3D` and `AbsoluteDate` objects. It could be useful to add another method signature that uses `AngularRaDec` object of OrekitLaplace method uses three angular observations to calculate an initial orbit.
Currently, the `IodLaplace` class has only one signature for the `estimate` method. This signature uses `Vector3D` and `AbsoluteDate` objects. It could be useful to add another method signature that uses `AngularRaDec` object of Orekit11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/752Add new method signature in IodLambert2021-02-25T17:21:34ZBryan CazabonneAdd new method signature in IodLambertSame as issue #751 but for `IodLambert` class.Same as issue #751 but for `IodLambert` class.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/751Add new method signature in IodGibbs2021-02-25T17:21:33ZBryan CazabonneAdd new method signature in IodGibbsGibbs initial orbit determination method calculates and orbit from three position vectors. Currently the estimation method has two signatures: one with `PV` objects and another one with `Vector3D`/`AbsoluteDate` objects (the first signature uses the second one by calling `.getPosition()` and `.getDate()` methods of `PV` class).
Because Gibbs method uses position measurements to calculate the initial orbit, it could be useful to have another method signature using `Position` class.Gibbs initial orbit determination method calculates and orbit from three position vectors. Currently the estimation method has two signatures: one with `PV` objects and another one with `Vector3D`/`AbsoluteDate` objects (the first signature uses the second one by calling `.getPosition()` and `.getDate()` methods of `PV` class).
Because Gibbs method uses position measurements to calculate the initial orbit, it could be useful to have another method signature using `Position` class.11.0Bryan CazabonneBryan Cazabonnehttps://gitlab.orekit.org/orekit/orekit/-/issues/750Attitude Dynamics Integration2021-01-27T08:12:31ZEmmanuel PapanagiotouAttitude Dynamics Integration~Feature
According to [this](https://forum.orekit.org/t/attitude-dynamics-integration/1001/8) Orekit Forum post, it has been identified that _it would be desirable for an Attitude Dynamics model to be integrated by a propagator_ in Orekit. In other words, the user could provide the attitude dynamics equations as additional equations, depending on a variety of additional states, and those would be ideally integrated throughout the propagation, changing the spacecraft attitude as desired.
Such a feature would allow Orekit developers to address a variety of use cases, including but not limited to:
- Incorporation of reaction wheel dynamics models, coupled with the spacecraft attitude;
- Reaction wheel momentum management and dumping with the modelling of magnetic torquers or paired thrusters;
- Design of custom control laws. For instance, given a desired attitude maneuver, the user could be allowed to develop attitude maneuver laws that are eigen-axis maneuvers, time-optimal maneuvers, minimum-cost maneuvers etc..
- Effect of gimbaling (or misaligned) thrusters to the spacecraft attitude, which could also be used as momentum dumping devices.
It would be beneficial to investigate the use of such a feature in combination with analytical and/or numerical propagators.
An older [mailing list post](https://www.orekit.org/mailing-list-archives/orekit-users/msg00175.html) sheds additional light to the complexity of Orekit propagation pipeline, and specifically how the attitude in Orekit is computed "on top" of the orbital state integration, in a sequential manner. The sequence of steps in integration is also discussed in the initally mentioned post.
A suggested course of action to develop this feature is outlined by @luc. [His answer](https://forum.orekit.org/t/attitude-dynamics-integration/1001/6?u=manny) suggests to implement a final step during the integration process:
> What I could suggest [...] would be to add a 6th step that would apply a user-provided post-processing object to the state before it is returned. This post-processing would simply take a state and return a possibly modified state. [...] You could have the attitude really handled there, overriding the attitude used in earlier step, perhaps by simple interpolation, or using a crude model, or reusing data extracted the previous call if you use the same object as attitude provider and as state post-processor.
I hope this feature will be considerd for some new version of Orekit.
Kind regards,
Emmanuel Papanagiotou
~Feature~Feature
According to [this](https://forum.orekit.org/t/attitude-dynamics-integration/1001/8) Orekit Forum post, it has been identified that _it would be desirable for an Attitude Dynamics model to be integrated by a propagator_ in Orekit. In other words, the user could provide the attitude dynamics equations as additional equations, depending on a variety of additional states, and those would be ideally integrated throughout the propagation, changing the spacecraft attitude as desired.
Such a feature would allow Orekit developers to address a variety of use cases, including but not limited to:
- Incorporation of reaction wheel dynamics models, coupled with the spacecraft attitude;
- Reaction wheel momentum management and dumping with the modelling of magnetic torquers or paired thrusters;
- Design of custom control laws. For instance, given a desired attitude maneuver, the user could be allowed to develop attitude maneuver laws that are eigen-axis maneuvers, time-optimal maneuvers, minimum-cost maneuvers etc..
- Effect of gimbaling (or misaligned) thrusters to the spacecraft attitude, which could also be used as momentum dumping devices.
It would be beneficial to investigate the use of such a feature in combination with analytical and/or numerical propagators.
An older [mailing list post](https://www.orekit.org/mailing-list-archives/orekit-users/msg00175.html) sheds additional light to the complexity of Orekit propagation pipeline, and specifically how the attitude in Orekit is computed "on top" of the orbital state integration, in a sequential manner. The sequence of steps in integration is also discussed in the initally mentioned post.
A suggested course of action to develop this feature is outlined by @luc. [His answer](https://forum.orekit.org/t/attitude-dynamics-integration/1001/6?u=manny) suggests to implement a final step during the integration process:
> What I could suggest [...] would be to add a 6th step that would apply a user-provided post-processing object to the state before it is returned. This post-processing would simply take a state and return a possibly modified state. [...] You could have the attitude really handled there, overriding the attitude used in earlier step, perhaps by simple interpolation, or using a crude model, or reusing data extracted the previous call if you use the same object as attitude provider and as state post-processor.
I hope this feature will be considerd for some new version of Orekit.
Kind regards,
Emmanuel Papanagiotou
~Featurehttps://gitlab.orekit.org/orekit/orekit/-/issues/749PVCoordinates and AngularCoordinates cannot be built from UnivariateDerivativ...2021-02-02T16:08:14ZLuc MaisonobePVCoordinates and AngularCoordinates cannot be built from UnivariateDerivative{1,2}There are constructors to convert from `FieldVector3D<DerivativeStructure>` to `PVCoordinates`
and from `FieldRotation<DerivativeStructure>` to `AngularCoordinates`, but this is not
possible from `FieldVector3D<UnivariateDerivative1>` and others.
The code of the existing constructors would however allow this, as `DerivativeStructure`,
`UnivariateDerivative1` and `UnivariateDerivative2` all implement the same interface `Derivative`
and use only the methods from this interface.
The same problem occurs with all other variations (`TimesStamped`, `Absolute`, `Field` and any combinations).There are constructors to convert from `FieldVector3D<DerivativeStructure>` to `PVCoordinates`
and from `FieldRotation<DerivativeStructure>` to `AngularCoordinates`, but this is not
possible from `FieldVector3D<UnivariateDerivative1>` and others.
The code of the existing constructors would however allow this, as `DerivativeStructure`,
`UnivariateDerivative1` and `UnivariateDerivative2` all implement the same interface `Derivative`
and use only the methods from this interface.
The same problem occurs with all other variations (`TimesStamped`, `Absolute`, `Field` and any combinations).11.0Luc MaisonobeLuc Maisonobehttps://gitlab.orekit.org/orekit/orekit/-/issues/748Access to Other Controls for iodLambert2021-03-02T14:59:13ZKennethAccess to Other Controls for iodLambertExpand access to iodLambert.java to allow user to specify orbit path as left or right branch, long or short way.
(See call to solveLambertPb) (For reference and examples see "Superior Lambert Algorithm by Gim Der)Expand access to iodLambert.java to allow user to specify orbit path as left or right branch, long or short way.
(See call to solveLambertPb) (For reference and examples see "Superior Lambert Algorithm by Gim Der)11.1https://gitlab.orekit.org/orekit/orekit/-/issues/747Full Eckstein-Hechler dynamical model realization2021-01-26T13:38:55ZLiao SpacefanFull Eckstein-Hechler dynamical model realizationBoth Orekit and [Celestlab](https://atoms.scilab.org/toolboxes/celestlab) implement the Eckstein-Hechler model, but the modeling is not fully realized, only the perturbations of J2~J6 and J2^2 are considered.
The semi-major axis accuracy of the complete Eckstein-Hechler model can reach 1m. The full implementation can address many orbital maneuver planning problems, is anyone willing to do this difficult but cool task together?Both Orekit and [Celestlab](https://atoms.scilab.org/toolboxes/celestlab) implement the Eckstein-Hechler model, but the modeling is not fully realized, only the perturbations of J2~J6 and J2^2 are considered.
The semi-major axis accuracy of the complete Eckstein-Hechler model can reach 1m. The full implementation can address many orbital maneuver planning problems, is anyone willing to do this difficult but cool task together?https://gitlab.orekit.org/orekit/orekit/-/issues/746The ionosphere-free LC for phase measurements2021-02-26T00:46:45ZAmir Allahvirdi-ZadehThe ionosphere-free LC for phase measurementsIn combining GNSS phase observations to form the ionosphere-free LC, the phase measurements are considered in meters, while in the RINEX observations files, they are in cycles. So they need to be transformed into meters before combining.In combining GNSS phase observations to form the ionosphere-free LC, the phase measurements are considered in meters, while in the RINEX observations files, they are in cycles. So they need to be transformed into meters before combining.11.0https://gitlab.orekit.org/orekit/orekit/-/issues/745Add Sequential-Batch Least Squares2021-01-12T13:38:37ZBryan CazabonneAdd Sequential-Batch Least SquaresBatch Least Squares main problem can be describe as follow:
"_Suppose we have 1000 observations and we perform an iterative loop to find the best answer to the state space of the system. But just as we finish converging on the answer, we receive 30 new observations. We could redo the process, using 1030 observations, but that is a waste of time because we've already extracted the information from the first 1000._"
Sequential-Batch Least Squares allows using the statistical information from the least squares processing of the first 1000 observations, and combine it with the new information.
More details are given in: Vallado D., Fundamentals of astrodynamics, Chapter 10.5.Batch Least Squares main problem can be describe as follow:
"_Suppose we have 1000 observations and we perform an iterative loop to find the best answer to the state space of the system. But just as we finish converging on the answer, we receive 30 new observations. We could redo the process, using 1030 observations, but that is a waste of time because we've already extracted the information from the first 1000._"
Sequential-Batch Least Squares allows using the statistical information from the least squares processing of the first 1000 observations, and combine it with the new information.
More details are given in: Vallado D., Fundamentals of astrodynamics, Chapter 10.5.11.1