Orekit issueshttps://gitlab.orekit.org/groups/orekit/-/issues2021-02-02T16:08:14Zhttps://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/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/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/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/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/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/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/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/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/758Support alpha-5 TLE satellite numbers2021-03-11T10:54:20ZMark 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/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/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/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/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/763Add support for IGS SSR data2021-04-02T14:20:59ZBryan 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/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/765Implement Geoid.projectToGround2021-03-09T21:01:33ZEvan WardImplement Geoid.projectToGroundImplement `Geoid.projectToGround(TSPVC, ...)`. The method currently throws an `UnsupportedOperationException`. Before that the JavaDoc for `BodyShape.projectToGround(TSPVC, ...)` should be clarified as what projection, if any, is performed for the velocity and acceleration.Implement `Geoid.projectToGround(TSPVC, ...)`. The method currently throws an `UnsupportedOperationException`. Before that the JavaDoc for `BodyShape.projectToGround(TSPVC, ...)` should be clarified as what projection, if any, is performed for the velocity and acceleration.https://gitlab.orekit.org/orekit/orekit/-/issues/766Setting AttitudeProvider to the BoundedPropagator generated via propagation2021-03-10T07:23:00ZGowtham SivaramanSetting AttitudeProvider to the BoundedPropagator generated via propagationFollow [this discussion](https://forum.orekit.org/t/setting-attitude-provider-to-a-boundedpropagator/1141) in the forum.Follow [this discussion](https://forum.orekit.org/t/setting-attitude-provider-to-a-boundedpropagator/1141) in the forum.https://gitlab.orekit.org/orekit/orekit/-/issues/767Feature Request: Add a generic `TwoVectorAttitudeProvider` interface2021-03-10T07:28:17ZGowtham SivaramanFeature Request: Add a generic `TwoVectorAttitudeProvider` interfaceIt can be interesting to work out a generic interface, say `TwoVectorAttitudeProvider`, where in we need two vectors or vector providers (like PVCoordinatesProvider), one for pointing and other for phasing.
This will make sure the `CelestialBodyPointed`, `NadirPointing` and `YawSteering` etc. can all implement this particular interface and simplify the architecture of Attitude computation in a whole.
More details on this [here](https://forum.orekit.org/t/sun-pointing-attitude-mode-with-nadir-constraint/1094/5)It can be interesting to work out a generic interface, say `TwoVectorAttitudeProvider`, where in we need two vectors or vector providers (like PVCoordinatesProvider), one for pointing and other for phasing.
This will make sure the `CelestialBodyPointed`, `NadirPointing` and `YawSteering` etc. can all implement this particular interface and simplify the architecture of Attitude computation in a whole.
More details on this [here](https://forum.orekit.org/t/sun-pointing-attitude-mode-with-nadir-constraint/1094/5)https://gitlab.orekit.org/orekit/orekit/-/issues/768Parse several types of ITRF specifications2021-03-15T14:50:26ZLuc MaisonobeParse several types of ITRF specificationsSeveral ways to specify ITRF versions are used in several contexts.
- some contexts allow years on two digits (CCSDS ODM before version 3, CCSDS ADM, CCSDS TDM, Orekit `itrf-version.conf`)
- all contexts allow years on 4 digits, some require them
- some contexts use "-" as separator (CCSDS, Orekit `itrf-version.conf`)
- some contexts use " " as separator (comments in IERS bulletins B)
- some contexts don't use any separators (CCSDS after ITRF2000)
- some contexts would be simpler if "_" was allowed as a separator (parsing from enumerates `name()` output)
- some contexts allow lower case (Orekit `itrf-version.conf`)
It would be simpler if Orekit allowed all these variations to be used, mainly in `itrf-version.conf` and in CCSDS parsing.
For consistency, the constants of the various enums (`org.orekit.frames.ITRFVersion`, `org.orekit.frames.HelmertTransformation.Predefined`, `org.orekit.files.ccsds.definitions.CelestialBodyFrame`) should all use 4 digits years instead of mixing two digits and four digits.Several ways to specify ITRF versions are used in several contexts.
- some contexts allow years on two digits (CCSDS ODM before version 3, CCSDS ADM, CCSDS TDM, Orekit `itrf-version.conf`)
- all contexts allow years on 4 digits, some require them
- some contexts use "-" as separator (CCSDS, Orekit `itrf-version.conf`)
- some contexts use " " as separator (comments in IERS bulletins B)
- some contexts don't use any separators (CCSDS after ITRF2000)
- some contexts would be simpler if "_" was allowed as a separator (parsing from enumerates `name()` output)
- some contexts allow lower case (Orekit `itrf-version.conf`)
It would be simpler if Orekit allowed all these variations to be used, mainly in `itrf-version.conf` and in CCSDS parsing.
For consistency, the constants of the various enums (`org.orekit.frames.ITRFVersion`, `org.orekit.frames.HelmertTransformation.Predefined`, `org.orekit.files.ccsds.definitions.CelestialBodyFrame`) should all use 4 digits years instead of mixing two digits and four digits.11.0Luc MaisonobeLuc Maisonobe