Orekit issues
https://gitlab.orekit.org/groups/orekit/-/issues
2020-10-23T14:59:44Z
https://gitlab.orekit.org/orekit/orekit/-/issues/723
AEMWriter does not write comments stored in AEMFiles
2020-10-23T14:59:44Z
Paul Dewost
AEMWriter does not write comments stored in AEMFiles
See https://forum.orekit.org/t/problem-with-ccsds-export/1011?u=pauldewost
See https://forum.orekit.org/t/problem-with-ccsds-export/1011?u=pauldewost
10.3
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/-/issues/720
UnivariateProcessNoise does not consider measurement parameters
2020-11-05T07:31:06Z
Bryan Cazabonne
UnivariateProcessNoise does not consider measurement parameters
`UnivariateProcessNoise` class considers both orbital and propagation parameters to build the noise matrix. However, it does not support measurement parameters that can be estimated during a Kalman filtering.
`UnivariateProcessNoise` class considers both orbital and propagation parameters to build the noise matrix. However, it does not support measurement parameters that can be estimated during a Kalman filtering.
10.3
https://gitlab.orekit.org/orekit/orekit/-/issues/719
Add a way to not estimate remote satellite orbit for inter-satellites measure...
2020-10-23T14:59:44Z
Bryan Cazabonne
Add a way to not estimate remote satellite orbit for inter-satellites measurements
For some applications, it is not needed to estimate the coordinates of the remote satellite simultaneously with the ones of the local satellite for inter-satellite measurements. For instance, in LEO satellite orbit determination, remote satellite coordinates can be obtained accurately using IGS products.
Find a way to enable the user to choose whether or not to estimate remote satellite coordinates can be a good enhancement for inter-satellite measurements in Orekit.
For some applications, it is not needed to estimate the coordinates of the remote satellite simultaneously with the ones of the local satellite for inter-satellite measurements. For instance, in LEO satellite orbit determination, remote satellite coordinates can be obtained accurately using IGS products.
Find a way to enable the user to choose whether or not to estimate remote satellite coordinates can be a good enhancement for inter-satellite measurements in Orekit.
10.3
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/-/issues/718
DSST short period Jacobian must be computed according to mean orbital state
2020-10-23T14:59:43Z
Bryan Cazabonne
DSST short period Jacobian must be computed according to mean orbital state
In DSST orbit determination, it is possible to consider either an osculating orbital state or a mean orbital state. Short period Jacobian is computed according to this state. However, it must be computed according to a mean orbital state. Therefore, the nature of the orbital state must be verify and a conversion must be performed if needed.
In DSST orbit determination, it is possible to consider either an osculating orbital state or a mean orbital state. Short period Jacobian is computed according to this state. However, it must be computed according to a mean orbital state. Therefore, the nature of the orbital state must be verify and a conversion must be performed if needed.
10.3
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/-/issues/716
Add piecewise empirical force models
2020-10-23T14:59:44Z
Bryan Cazabonne
Add piecewise empirical force models
For precise orbit determination applications it could be useful to have an implementation of [PolynomialParametricAcceleration](https://gitlab.orekit.org/orekit/orekit/-/blob/master/src/main/java/org/orekit/forces/PolynomialParametricAcceleration.java) and [HarmonicParametricAcceleration](https://gitlab.orekit.org/orekit/orekit/-/blob/master/src/main/java/org/orekit/forces/HarmonicParametricAcceleration.java) that would allow for piecewise definition of the empirical coefficients.
Each coefficient would be defined with a timespan validity and the orbit determination would be able to estimate each one of them separately.
For precise orbit determination applications it could be useful to have an implementation of [PolynomialParametricAcceleration](https://gitlab.orekit.org/orekit/orekit/-/blob/master/src/main/java/org/orekit/forces/PolynomialParametricAcceleration.java) and [HarmonicParametricAcceleration](https://gitlab.orekit.org/orekit/orekit/-/blob/master/src/main/java/org/orekit/forces/HarmonicParametricAcceleration.java) that would allow for piecewise definition of the empirical coefficients.
Each coefficient would be defined with a timespan validity and the orbit determination would be able to estimate each one of them separately.
10.3
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/-/issues/715
Relativistic clock correction term cannot be used for orbit determination
2020-10-23T14:59:45Z
Bryan Cazabonne
Relativistic clock correction term cannot be used for orbit determination
Currently, the relativistic clock correction term is computed inside an `AdditionalStateProvider`. This implementation prevents the use of this correction in orbit determination applications. A better implementation is:
1. Implement the relativistic clock correction term in a dedicated `EstimationModifier`.
2. Update the `ClockCorrectionProvider` documentation to point the new `EstimationModifier`.
This implementation is compatible for a minor release of Orekit.
Currently, the relativistic clock correction term is computed inside an `AdditionalStateProvider`. This implementation prevents the use of this correction in orbit determination applications. A better implementation is:
1. Implement the relativistic clock correction term in a dedicated `EstimationModifier`.
2. Update the `ClockCorrectionProvider` documentation to point the new `EstimationModifier`.
This implementation is compatible for a minor release of Orekit.
10.3
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/-/issues/714
Add relativistic frequency deviation for RangeRate measurements
2020-10-23T14:59:44Z
Bryan Cazabonne
Add relativistic frequency deviation for RangeRate measurements
Currently, clock relativistic correction is not used in `RangeRate` measurements. Adding it can improve the modelling of the range-rate measurement. The implementation of that offset is given in [1].
It can be implemented as a new `EstimationModifier`.
[1] Teunissen, P., & Montenbruck, O. (Eds.). (2017). Springer handbook of global navigation satellite systems, Eq. (19.13) - (19.15) and (19.17). Springer.
Currently, clock relativistic correction is not used in `RangeRate` measurements. Adding it can improve the modelling of the range-rate measurement. The implementation of that offset is given in [1].
It can be implemented as a new `EstimationModifier`.
[1] Teunissen, P., & Montenbruck, O. (Eds.). (2017). Springer handbook of global navigation satellite systems, Eq. (19.13) - (19.15) and (19.17). Springer.
10.3
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/-/issues/713
Wrong computation of DSST short period Jacobian
2020-10-23T14:59:44Z
Thomas Paulet
Wrong computation of DSST short period Jacobian
After discussion with @bryan, it was figured out that DSST short period derivative computation is wrong. Indeed, the setShortPeriodJacobians method in DSSTJacobianMapper.java is building a variational equation to complete an analytical calculation. The short period Jacobian should be directly computed using values from the orbital element Gradients.
After discussion with @bryan, it was figured out that DSST short period derivative computation is wrong. Indeed, the setShortPeriodJacobians method in DSSTJacobianMapper.java is building a variational equation to complete an analytical calculation. The short period Jacobian should be directly computed using values from the orbital element Gradients.
10.3
https://gitlab.orekit.org/orekit/orekit/-/issues/712
Add support for IGS clock products
2021-02-26T15:42:29Z
Bryan Cazabonne
Add support for IGS clock products
It could be an interesting feature to add support for IGS clock products. These files contain clock offsets (optionally clock rate) of GNSS satellites and IGS stations.
Format is described here: ftp://igs.org/pub/data/format/rinex_clock304.txt
It could be an interesting feature to add support for IGS clock products. These files contain clock offsets (optionally clock rate) of GNSS satellites and IGS stations.
Format is described here: ftp://igs.org/pub/data/format/rinex_clock304.txt
11.0
https://gitlab.orekit.org/orekit/orekit/-/issues/711
Allow setting default value for OEM interpolation samples
2020-11-10T14:48:50Z
Evan Ward
Allow setting default value for OEM interpolation samples
In an OEM `INTERPOLATION_DEGREE` is optional. In Orekit's implementation if it is not provided then it is assumed to be zero. In Orekit's implementation the number of samples to use for interpolation is `degree + 1`. This leads to linear (or quadratic if acceleration is present) *extrapolation* when the degree is not specified in the OEM. Orekit should provide a method to set the default interpolation samples to use if they are not specified in the OEM. E.g. add a method `OemParser.withDefaultInterpolationDegree(int)`.
In an OEM `INTERPOLATION_DEGREE` is optional. In Orekit's implementation if it is not provided then it is assumed to be zero. In Orekit's implementation the number of samples to use for interpolation is `degree + 1`. This leads to linear (or quadratic if acceleration is present) *extrapolation* when the degree is not specified in the OEM. Orekit should provide a method to set the default interpolation samples to use if they are not specified in the OEM. E.g. add a method `OemParser.withDefaultInterpolationDegree(int)`.
10.3
https://gitlab.orekit.org/orekit/orekit/-/issues/709
Satellite and receiver clock drifts are not taking into account in range-rate...
2020-11-12T11:08:46Z
Bryan Cazabonne
Satellite and receiver clock drifts are not taking into account in range-rate measurement theoritical evalutation.
According to [1], the most significant contributors to the range-rate measurement are the line-of-sight velocity and the receiver clock drift. Furthermore, the satellite clock drift must be also taking into account when modelling a range-rate measurement.
However, these two time drifts are not used in the theoretical evaluation of the range-rate measurement. Their contributions must be added.
Suggestion: Orekit considers receiver and satellite clock offsets. However, range-rate measurement considers clock drifts. Therefore, adding two new `ParameterDriver` to consider the clock drifts (one in ObservableSatellite and another one in `GroundStation`) can be an easy solution to solve the problem.
[1]: Teunissen, P., & Montenbruck, O. (Eds.). (2017). Springer handbook of global navigation satellite systems, Eq. 14.82. Springer.
According to [1], the most significant contributors to the range-rate measurement are the line-of-sight velocity and the receiver clock drift. Furthermore, the satellite clock drift must be also taking into account when modelling a range-rate measurement.
However, these two time drifts are not used in the theoretical evaluation of the range-rate measurement. Their contributions must be added.
Suggestion: Orekit considers receiver and satellite clock offsets. However, range-rate measurement considers clock drifts. Therefore, adding two new `ParameterDriver` to consider the clock drifts (one in ObservableSatellite and another one in `GroundStation`) can be an easy solution to solve the problem.
[1]: Teunissen, P., & Montenbruck, O. (Eds.). (2017). Springer handbook of global navigation satellite systems, Eq. 14.82. Springer.
10.3
https://gitlab.orekit.org/orekit/orekit/-/issues/706
Satellites clock offsets for InterSatellitesRange measurement missing from me...
2020-10-23T14:59:45Z
Bryan Cazabonne
Satellites clock offsets for InterSatellitesRange measurement missing from measurement parameters drivers
Remote and local satellites clock offsets are taken into account in `InterSatellitesRange` measurement. They are however not available in the measurements parameters.
The following statement should be added to the constructor:
```
if (!twoWay) {
// for one way measurements, the local and remote satellite clock offsets affects the measurement
addParameterDriver(local.getClockOffsetDriver());
addParameterDriver(remote.getClockOffsetDriver());
}
```
Remote and local satellites clock offsets are taken into account in `InterSatellitesRange` measurement. They are however not available in the measurements parameters.
The following statement should be added to the constructor:
```
if (!twoWay) {
// for one way measurements, the local and remote satellite clock offsets affects the measurement
addParameterDriver(local.getClockOffsetDriver());
addParameterDriver(remote.getClockOffsetDriver());
}
```
10.3
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/-/issues/705
Allow writing an AEM file from a list of SpacecraftStates
2020-12-07T10:51:13Z
ClĂ©ment Masson
Allow writing an AEM file from a list of SpacecraftStates
This issue is related to [this thread](https://forum.orekit.org/t/writing-spacecraftstates-into-an-aem-file/944) on the forum.
A list of positions/velocities can be written to an OEM file as follows :
```
OrekitEphemerisFile ephemerisFile = new OrekitEphemerisFile();
OrekitEphemerisFile.OrekitSatelliteEphemeris satelliteEphemeris = ephemerisFile.addSatellite(satelliteId);
satelliteEphemeris.addNewSegment(spacecraftStates);
OEMWriter ephemerisFileWriter = new OEMWriter(OEMWriter.InterpolationMethod.HERMITE, originator, satelliteId, spaceObjectName);
ephemerisFileWriter.write(outputFilePath, ephemerisFile);
```
However, @bryan explained in the thread that this method doesn't work for AEM files, because `AEMFile` doesn't implement `EphemerisFile` and `AemSatelliteEphemeris` doesn't implement `SatelliteEphemeris`. The reason for that is these interfaces have methods that are specific to position/velocity ephemeris, and incompatible with attitude files. He suggested adding exceptions for those cases.
This issue is related to [this thread](https://forum.orekit.org/t/writing-spacecraftstates-into-an-aem-file/944) on the forum.
A list of positions/velocities can be written to an OEM file as follows :
```
OrekitEphemerisFile ephemerisFile = new OrekitEphemerisFile();
OrekitEphemerisFile.OrekitSatelliteEphemeris satelliteEphemeris = ephemerisFile.addSatellite(satelliteId);
satelliteEphemeris.addNewSegment(spacecraftStates);
OEMWriter ephemerisFileWriter = new OEMWriter(OEMWriter.InterpolationMethod.HERMITE, originator, satelliteId, spaceObjectName);
ephemerisFileWriter.write(outputFilePath, ephemerisFile);
```
However, @bryan explained in the thread that this method doesn't work for AEM files, because `AEMFile` doesn't implement `EphemerisFile` and `AemSatelliteEphemeris` doesn't implement `SatelliteEphemeris`. The reason for that is these interfaces have methods that are specific to position/velocity ephemeris, and incompatible with attitude files. He suggested adding exceptions for those cases.
10.3
https://gitlab.orekit.org/orekit/orekit/-/issues/704
Allow using user specified velocity error for computing tolerance vectors for...
2020-10-23T14:59:44Z
Bryan Cazabonne
Allow using user specified velocity error for computing tolerance vectors for integrators
Currently only user specified position error is used to compute tolerance vectors for integrators, velocity error is computed inside the method. It can be useful to have a method signature allowing user to specified both position and velocity errors to compute tolerance vectors for integrators.
Currently only user specified position error is used to compute tolerance vectors for integrators, velocity error is computed inside the method. It can be useful to have a method signature allowing user to specified both position and velocity errors to compute tolerance vectors for integrators.
10.3
https://gitlab.orekit.org/orekit/orekit/-/issues/703
Add inter-satellites phase measurements
2020-10-23T14:59:45Z
Bryan Cazabonne
Add inter-satellites phase measurements
LEO satellites can receive both range and phase measurements from GNSS satellites. Inter-satellites range measurement is implemented in Orekit, not the phase.
LEO satellites can receive both range and phase measurements from GNSS satellites. Inter-satellites range measurement is implemented in Orekit, not the phase.
10.3
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/-/issues/701
Kalman estimator confuses propagation parameters in multi-sat context
2020-07-31T13:06:43Z
Luc Maisonobe
Kalman estimator confuses propagation parameters in multi-sat context
When Kalman estimation is performed in a multi-satellite context, propagation parameters are not put in the proper column of measurement matrix.
The `KalmanModel` constructor sets up a `propagationParameterColumns` map to associate propagation parameters to columns, but this map is not stored as an instance field. When `getMeasurementMatrix` is called, it just counts parameters, assuming the propagation parameters are placed just after the estimated orbital parameters. If we consider two satellites and estimate the 6 orbital parameters and 2 propagation parameters for each. Then the estimated state has dimension 16. The `KalmanModel` constructor will properly assign columns 0:5 to orbit 1, 6:11 to orbit 2, 12:13 to propagation parameters 1 and 14:15 to propagation parameters 2. However, `getMeasurementMatrix` will fill up the measurement matrix with partial derivatives wrt orbit 1 to columns 0:5, partial derivatives wrt propagation parameters 1 to columns 6:7, partial derivatives wrt orbit 2 to columns 6:11 (overriding derivatives wrt propagation parameters 1), partial derivatives wrt propagation parameters 2 to columns 12:13 and never filling columns 14:15.
When Kalman estimation is performed in a multi-satellite context, propagation parameters are not put in the proper column of measurement matrix.
The `KalmanModel` constructor sets up a `propagationParameterColumns` map to associate propagation parameters to columns, but this map is not stored as an instance field. When `getMeasurementMatrix` is called, it just counts parameters, assuming the propagation parameters are placed just after the estimated orbital parameters. If we consider two satellites and estimate the 6 orbital parameters and 2 propagation parameters for each. Then the estimated state has dimension 16. The `KalmanModel` constructor will properly assign columns 0:5 to orbit 1, 6:11 to orbit 2, 12:13 to propagation parameters 1 and 14:15 to propagation parameters 2. However, `getMeasurementMatrix` will fill up the measurement matrix with partial derivatives wrt orbit 1 to columns 0:5, partial derivatives wrt propagation parameters 1 to columns 6:7, partial derivatives wrt orbit 2 to columns 6:11 (overriding derivatives wrt propagation parameters 1), partial derivatives wrt propagation parameters 2 to columns 12:13 and never filling columns 14:15.
10.3
Luc Maisonobe
Luc Maisonobe
https://gitlab.orekit.org/orekit/orekit/-/issues/700
Titles of the Download documentation page disapeared
2020-11-18T13:25:50Z
Guilhem Bonnefille
Titles of the Download documentation page disapeared
Since moving download page into markown+velocity the titles disapeared.
* Wrong: https://www.orekit.org/site-orekit-development/downloads.html
* Correct: https://www.orekit.org/site-orekit-10.0/downloads.html
Since moving download page into markown+velocity the titles disapeared.
* Wrong: https://www.orekit.org/site-orekit-development/downloads.html
* Correct: https://www.orekit.org/site-orekit-10.0/downloads.html
10.3
Guilhem Bonnefille
Guilhem Bonnefille
https://gitlab.orekit.org/orekit/website-2015/-/issues/8
Rugged: Update continuous integration link and add links to source code quali...
2020-07-20T14:05:37Z
Guylaine Prat
Rugged: Update continuous integration link and add links to source code quality and coverage
CI was updated for Rugged (like in Orekit):
* under Community tab:
- change link from Jenkins to Gitlab CI pipelines: https://gitlab.orekit.org/orekit/rugged/pipelines
- add link to Source code quality: https://sonar.orekit.org/dashboard?id=org.orekit%3Arugged
* in the home page, add badges to :
- quality date (source code quality): https://sonar.orekit.org/dashboard?id=org.orekit%3Arugged
- coverage: https://sonar.orekit.org/component_measures?id=org.orekit%3Arugged&metric=coverage&view=treemap
CI was updated for Rugged (like in Orekit):
* under Community tab:
- change link from Jenkins to Gitlab CI pipelines: https://gitlab.orekit.org/orekit/rugged/pipelines
- add link to Source code quality: https://sonar.orekit.org/dashboard?id=org.orekit%3Arugged
* in the home page, add badges to :
- quality date (source code quality): https://sonar.orekit.org/dashboard?id=org.orekit%3Arugged
- coverage: https://sonar.orekit.org/component_measures?id=org.orekit%3Arugged&metric=coverage&view=treemap
Guylaine Prat
Guylaine Prat
https://gitlab.orekit.org/orekit/orekit/-/issues/699
Satellite clock offset for Phase measurement missing from measurement paramet...
2020-10-23T14:59:42Z
Luc Maisonobe
Satellite clock offset for Phase measurement missing from measurement parameters drivers
Satellite clock offset are taken into account in Phase measurement since commit 3795667ecf8d8a401420d10a1bd490487de65e6f.
It is however not available in the measurements parameters.
The following statement should be added to the constructor:
```java
addParameterDriver(satellite.getClockOffsetDriver());
```
Satellite clock offset are taken into account in Phase measurement since commit 3795667ecf8d8a401420d10a1bd490487de65e6f.
It is however not available in the measurements parameters.
The following statement should be added to the constructor:
```java
addParameterDriver(satellite.getClockOffsetDriver());
```
10.3
https://gitlab.orekit.org/orekit/orekit/-/issues/697
DSST Orbit Determination not working correctly in 10.1
2020-07-10T19:18:10Z
James Schatzman
DSST Orbit Determination not working correctly in 10.1
I find that using the DSSTBatchLSModel against PV data does not seem to work correctly. Specifically
1) It converges to a solution, but a solution with large residuals.
2) The DSSTPropagator does not seem to obey physics, because with a PVT in the .in file used to initialize the estimated orbit, and a PVT value a few seconds later, I would expect very small residuals for that data value, but the residuals are surpsingly lage (100s of m and 10s of m/sec). This is true whther or not drag, radiation pression, sun/moon third body forces, etc., are turned on. Residuls are much large when hours of data are used.
3) I am providing all data in EME2000 coordinates and UTC (data comes from precision Grace ephemeris that is in ITRF and modified GPS seconds - I am pretty sure that all PV conversions are done correctly).
3) mu is correct. Switching from central body degree/order 12 to 70 does not significantly change the results.
4) Using iers.conventions=2010. Switching from WGS-84 to CIO/2010 doesn't change the results significantly.
5) Latest test using
propagator.min.step = 0.1
propagator.max.step = 100.0
propagator.position.error = 0.0001
but using other step sizes does not siginicantly change the results.
6) Modifying DSSTBatchLSModel from
parallelizer.propagate(firstDate.shiftedBy(-1.0), lastDate.shiftedBy(+1.0));
to
parallelizer.propagate(firstDate.shiftedBy(-1.0e-3), lastDate.shiftedBy(+1.0e-3));
does not significantly change the results (but why was a shift of 1 sec chosen?? If the propagation region in this line needs to strictly include the requested time range, shouldn't the extensions be configurable?).
Bottom line - something seems wrong with the physics model, but I am unable to determine what. Suggestions?
I find that using the DSSTBatchLSModel against PV data does not seem to work correctly. Specifically
1) It converges to a solution, but a solution with large residuals.
2) The DSSTPropagator does not seem to obey physics, because with a PVT in the .in file used to initialize the estimated orbit, and a PVT value a few seconds later, I would expect very small residuals for that data value, but the residuals are surpsingly lage (100s of m and 10s of m/sec). This is true whther or not drag, radiation pression, sun/moon third body forces, etc., are turned on. Residuls are much large when hours of data are used.
3) I am providing all data in EME2000 coordinates and UTC (data comes from precision Grace ephemeris that is in ITRF and modified GPS seconds - I am pretty sure that all PV conversions are done correctly).
3) mu is correct. Switching from central body degree/order 12 to 70 does not significantly change the results.
4) Using iers.conventions=2010. Switching from WGS-84 to CIO/2010 doesn't change the results significantly.
5) Latest test using
propagator.min.step = 0.1
propagator.max.step = 100.0
propagator.position.error = 0.0001
but using other step sizes does not siginicantly change the results.
6) Modifying DSSTBatchLSModel from
parallelizer.propagate(firstDate.shiftedBy(-1.0), lastDate.shiftedBy(+1.0));
to
parallelizer.propagate(firstDate.shiftedBy(-1.0e-3), lastDate.shiftedBy(+1.0e-3));
does not significantly change the results (but why was a shift of 1 sec chosen?? If the propagation region in this line needs to strictly include the requested time range, shouldn't the extensions be configurable?).
Bottom line - something seems wrong with the physics model, but I am unable to determine what. Suggestions?