Orekit issues
https://gitlab.orekit.org/orekit/orekit/issues
2020-02-11T09:41:18Z
https://gitlab.orekit.org/orekit/orekit/issues/649
Adding a piecewise drag force model
2020-02-11T09:41:18Z
Maxime Journot
Adding a piecewise drag force model
For operational uses it would be useful to have an implementation of [DragForce](https://gitlab.orekit.org/orekit/orekit/blob/master/src/main/java/org/orekit/forces/drag/DragForce.java) that would allow for piecewise definition of the drag and lift coefficients.
Each coefficient would be defined with a timespan validity and the orbit determination would be able to estimate each one of them separately.
This is useful in operational context where the solar activity is unknown or badly known. Generally a daily solar activity is used based on data provided by different services.
With this drag force model, the orbit determination would for example estimate a drag coefficient for each day and the uncertainties derived from the daily solar activity could be estimated separately.
For operational uses it would be useful to have an implementation of [DragForce](https://gitlab.orekit.org/orekit/orekit/blob/master/src/main/java/org/orekit/forces/drag/DragForce.java) that would allow for piecewise definition of the drag and lift coefficients.
Each coefficient would be defined with a timespan validity and the orbit determination would be able to estimate each one of them separately.
This is useful in operational context where the solar activity is unknown or badly known. Generally a daily solar activity is used based on data provided by different services.
With this drag force model, the orbit determination would for example estimate a drag coefficient for each day and the uncertainties derived from the daily solar activity could be estimated separately.
10.2
https://gitlab.orekit.org/orekit/orekit/issues/648
Improving forces.maneuvers package
2020-02-11T09:32:05Z
Maxime Journot
Improving forces.maneuvers package
Current `forces.maneuvers` package only proposes the [ConstantThrustManeuver](https://gitlab.orekit.org/orekit/orekit/blob/master/src/main/java/org/orekit/forces/maneuvers/ConstantThrustManeuver.java) class as a numerical force model that can be integrated during a propagation and estimated with orbit determination.
It has been discussed in the [following thread on the forum](https://forum.orekit.org/t/maneuvers-package-organization-proposal/684) that it would be a good addition to have a more versatile implementation of numerical maneuvers' models that would allow for:
- Estimating the direction of the maneuver as well as its norm, with a 3D model that could be customized;
- Implementing a variable thrust maneuver model (see this other [forum thread](https://forum.orekit.org/t/variable-thrust-maneuver-force-model/462));
- Using a ΔV-based definition instead of a thrust-based definition to model, estimate or optimize quasi-impulse maneuvers;
- Using other triggers than dates to define start and stop of maneuvers;
- etc.
In that perspective a first implementation of a new maneuver package was proposed and is available on branch [maneuver-package](https://gitlab.orekit.org/orekit/orekit/tree/maneuver-package).
It is based on the organization proposal given in the first forum thread mentioned here.
Current `forces.maneuvers` package only proposes the [ConstantThrustManeuver](https://gitlab.orekit.org/orekit/orekit/blob/master/src/main/java/org/orekit/forces/maneuvers/ConstantThrustManeuver.java) class as a numerical force model that can be integrated during a propagation and estimated with orbit determination.
It has been discussed in the [following thread on the forum](https://forum.orekit.org/t/maneuvers-package-organization-proposal/684) that it would be a good addition to have a more versatile implementation of numerical maneuvers' models that would allow for:
- Estimating the direction of the maneuver as well as its norm, with a 3D model that could be customized;
- Implementing a variable thrust maneuver model (see this other [forum thread](https://forum.orekit.org/t/variable-thrust-maneuver-force-model/462));
- Using a ΔV-based definition instead of a thrust-based definition to model, estimate or optimize quasi-impulse maneuvers;
- Using other triggers than dates to define start and stop of maneuvers;
- etc.
In that perspective a first implementation of a new maneuver package was proposed and is available on branch [maneuver-package](https://gitlab.orekit.org/orekit/orekit/tree/maneuver-package).
It is based on the organization proposal given in the first forum thread mentioned here.
10.2
https://gitlab.orekit.org/orekit/orekit/issues/646
Merge project "Vincent Mouraux / Orekit" into "develop"
2020-02-10T10:55:04Z
Bryan Cazabonne
Merge project "Vincent Mouraux / Orekit" into "develop"
Vincent's project introduces new features in CR3BP model.
Vincent's project introduces new features in CR3BP model.
10.2
https://gitlab.orekit.org/orekit/orekit/issues/645
Merge project "David Soulard / Orekit" into "develop"
2020-02-10T10:55:18Z
Bryan Cazabonne
Merge project "David Soulard / Orekit" into "develop"
David's project introduces new features in GNSS orbit determination, especially for the modelling of the phase measurement.
David's project introduces new features in GNSS orbit determination, especially for the modelling of the phase measurement.
10.2
https://gitlab.orekit.org/orekit/orekit/issues/576
Add weak-time-dependent (WTD) terms in the DSST lunar solar short period motion.
2019-07-18T13:24:33Z
Bryan Cazabonne
Add weak-time-dependent (WTD) terms in the DSST lunar solar short period motion.
For a better accuracy in orbit propagation and orbit determination it is necessary to add the weak-time-dependent (WTD) terms in the Orekit DSST lunar solar short period motion. For GNSS or GEO orbits adding these terms can improve significantly the results.
For a better accuracy in orbit propagation and orbit determination it is necessary to add the weak-time-dependent (WTD) terms in the Orekit DSST lunar solar short period motion. For GNSS or GEO orbits adding these terms can improve significantly the results.
https://gitlab.orekit.org/orekit/orekit/issues/555
Change ionospheric models API
2019-11-14T14:38:08Z
Bryan Cazabonne
Change ionospheric models API
Current API used for the computation of the path delay due to ionospheric effects limits the implementation of new ionospheric models. Current API can be improved by:
* Add `SpacecraftState` information and the possibility to estimate some ionospheric model parameters.
* Add the frequency parameter to limit the number of model initialization.
* Replace `GeodeticPoint`, elevation and azimuth parameters with `TopocentricFrame` parameter.
Old method parameters: `pathDelay(AbsoluteDate date, GeodeticPoint geo, double elevation, double azimuth)`
New method parameters: `pathDelay(SpacecraftState state, TopocentricFrame baseFrame, double frequency, double[] parameters)`
Current API used for the computation of the path delay due to ionospheric effects limits the implementation of new ionospheric models. Current API can be improved by:
* Add `SpacecraftState` information and the possibility to estimate some ionospheric model parameters.
* Add the frequency parameter to limit the number of model initialization.
* Replace `GeodeticPoint`, elevation and azimuth parameters with `TopocentricFrame` parameter.
Old method parameters: `pathDelay(AbsoluteDate date, GeodeticPoint geo, double elevation, double azimuth)`
New method parameters: `pathDelay(SpacecraftState state, TopocentricFrame baseFrame, double frequency, double[] parameters)`
11.0
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/issues/525
How to use BatchLSEstimator with GPSPropagator?
2019-11-13T15:37:35Z
Gowtham Sivaraman
How to use BatchLSEstimator with GPSPropagator?
A typical problem of Orbit determination of LEO satellites using GNSS involves processing InterSatellitesRange with remote satellite being one of the GNSS satellites. But the BatchLSEstimator requires the constellation to be propagated numerically (instead of using GPSPropagator).
Since the Numerical propagation of the constellation requires PV data, which typically is unavailable (even with IGS final product). It would be a great feature to implement a separate propagator to interpolate the position solution from IGS data (as mentioned here: https://gssc.esa.int/navipedia/index.php/Precise_GNSS_Satellite_Coordinates_Computation) which can be fed into BatchLSEstimator to use for the orbit determination.
A typical problem of Orbit determination of LEO satellites using GNSS involves processing InterSatellitesRange with remote satellite being one of the GNSS satellites. But the BatchLSEstimator requires the constellation to be propagated numerically (instead of using GPSPropagator).
Since the Numerical propagation of the constellation requires PV data, which typically is unavailable (even with IGS final product). It would be a great feature to implement a separate propagator to interpolate the position solution from IGS data (as mentioned here: https://gssc.esa.int/navipedia/index.php/Precise_GNSS_Satellite_Coordinates_Computation) which can be fed into BatchLSEstimator to use for the orbit determination.
11.0
https://gitlab.orekit.org/orekit/orekit/issues/523
Add support for loading RINEX navigation file
2019-11-13T15:30:32Z
Gowtham Sivaraman
Add support for loading RINEX navigation file
Orekit (as of v9.3) supports RINEX (measurement/observation files) versions 2.x and 3.x. But the support for loading navigation files (Eg: ftp://cddis.nasa.gov/gnss/data/daily/2019/035/19n/brdc0350.19n.Z) is lacking. The RINEX data format document (ftp://igs.org/pub/data/format/rinex301.pdf
) discusses the format of navigation file broadcasted.
Similar to SEM/YUMA parsers, the support to run GPSPropagator at the end of loading RINEX navigation files can be made available.
Orekit (as of v9.3) supports RINEX (measurement/observation files) versions 2.x and 3.x. But the support for loading navigation files (Eg: ftp://cddis.nasa.gov/gnss/data/daily/2019/035/19n/brdc0350.19n.Z) is lacking. The RINEX data format document (ftp://igs.org/pub/data/format/rinex301.pdf
) discusses the format of navigation file broadcasted.
Similar to SEM/YUMA parsers, the support to run GPSPropagator at the end of loading RINEX navigation files can be made available.
10.2
https://gitlab.orekit.org/orekit/orekit/issues/504
How to initialize the Eckstein Hechler propagator with a mean orbit?
2020-02-11T13:06:20Z
SÃ©bastien HerbiniÃ¨re
How to initialize the Eckstein Hechler propagator with a mean orbit?
The initial orbit in the EcksteinHechlerPropagator builders is an osculating one.
I see that, internally, the mean parameters are computed by "computeMeanParameters" private method.
I would like to initialize the propagation with a mean orbit (in EcksteinHechler sens).
Is there a simple way to do that?
Thanks
The initial orbit in the EcksteinHechlerPropagator builders is an osculating one.
I see that, internally, the mean parameters are computed by "computeMeanParameters" private method.
I would like to initialize the propagation with a mean orbit (in EcksteinHechler sens).
Is there a simple way to do that?
Thanks
10.2
Bryan Cazabonne
Bryan Cazabonne
https://gitlab.orekit.org/orekit/orekit/issues/372
Add TLE generation
2019-11-13T15:24:34Z
Daniel Ferrochio
Add TLE generation
It would be a great feature being capable of create TLE files from orbit
estimation (SGP4 Orbit Determination). Something similar to SGP4DC
routine (Vallado, 2007).
*(from redmine: issue id 372, created on 2017-12-29)*
It would be a great feature being capable of create TLE files from orbit
estimation (SGP4 Orbit Determination). Something similar to SGP4DC
routine (Vallado, 2007).
*(from redmine: issue id 372, created on 2017-12-29)*
11.0
https://gitlab.orekit.org/orekit/orekit/issues/481
Elevation Detector for a Geographic Zone
2019-11-13T15:19:41Z
Javier Montemayor
Elevation Detector for a Geographic Zone
It would be nice to have a constructor for an Elevation Detector that
instead of taking a Topocentric Frame as argument, takes a Spherical
Polygon Set.
Basically, having ElevationDetector capabilities for a
GeographicZoneDetector.
*(from redmine: issue id 481, created on 2018-06-25)*
It would be nice to have a constructor for an Elevation Detector that
instead of taking a Topocentric Frame as argument, takes a Spherical
Polygon Set.
Basically, having ElevationDetector capabilities for a
GeographicZoneDetector.
*(from redmine: issue id 481, created on 2018-06-25)*
https://gitlab.orekit.org/orekit/orekit/issues/474
Add support for version 3 of CCSDS Orbit Data Messages
2019-10-09T14:35:55Z
Luc Maisonobe
Add support for version 3 of CCSDS Orbit Data Messages
CCSDS Orbit Data Message will be updated in the near future, with
a new Orbit Comprehensive Message (OCM) in addition to the existing
OPM, OMM and OEM already supported by Orekit.
The update was presented during SpaceOps 2018 conference by David
Berry (see https://arc.aiaa.org/doi/pdf/10.2514/6.2018-2456). The
paper provided a link to the current draft.
We discussed with Dave at the conference and agreed Orekit could
provide one of the prototype implementations for the standard.
*(from redmine: issue id 474, created on 2018-06-04)*
CCSDS Orbit Data Message will be updated in the near future, with
a new Orbit Comprehensive Message (OCM) in addition to the existing
OPM, OMM and OEM already supported by Orekit.
The update was presented during SpaceOps 2018 conference by David
Berry (see https://arc.aiaa.org/doi/pdf/10.2514/6.2018-2456). The
paper provided a link to the current draft.
We discussed with Dave at the conference and agreed Orekit could
provide one of the prototype implementations for the standard.
*(from redmine: issue id 474, created on 2018-06-04)*
11.0
Luc Maisonobe
Luc Maisonobe
https://gitlab.orekit.org/orekit/orekit/issues/403
Add a provider generating process noise increasing in time, for better Kalman...
2019-11-13T15:15:52Z
Luc Maisonobe
Add a provider generating process noise increasing in time, for better Kalman filtering
The Kalman filter implementation in Orekit let the user provide the
process noise
matrix at each prediction step. As of 2018-03-22, the only
implementation of
the ProcessNoiseMatricProvider is ConstantProcessNoise. Users could
implement their
own process noise provider, as complex and as realistic as they want.
It would be interesting to have another implementation in Orekit that is
more realistic
than a constant matrix, and that simulates at least the expansion of the
uncertainty
ellipsoid along track as time without measurements increase.
A first idea would be to have user provide six polynomials representing
the diagonal
elements of the covariance in some Local Orbital Frame (say LVLH for
example). The
polynomial for the along velocity covariance would increase faster than
the polynomial
for the across directions. Then, by pre and post-multiplying by the
rotation matrix
we get from LOFType.rotationFromInertial, we get the dense matri in
inertial frame
we need to return.
This implementation is simple but much more realistic than a constant
matrix, and it
should properly take into account the fact the uncertainty from the
prediction step
is larger when the time between measurements is long than when
measurements occur
frequently.
Finding the polynomials would remain here the responsibility of the
caller. Later on,
we can think about using FieldPropagator on a reference orbit to
estimate these
polynomials during the mission analysis phase prior to operations.
*(from redmine: issue id 403, created on 2018-03-22)*
The Kalman filter implementation in Orekit let the user provide the
process noise
matrix at each prediction step. As of 2018-03-22, the only
implementation of
the ProcessNoiseMatricProvider is ConstantProcessNoise. Users could
implement their
own process noise provider, as complex and as realistic as they want.
It would be interesting to have another implementation in Orekit that is
more realistic
than a constant matrix, and that simulates at least the expansion of the
uncertainty
ellipsoid along track as time without measurements increase.
A first idea would be to have user provide six polynomials representing
the diagonal
elements of the covariance in some Local Orbital Frame (say LVLH for
example). The
polynomial for the along velocity covariance would increase faster than
the polynomial
for the across directions. Then, by pre and post-multiplying by the
rotation matrix
we get from LOFType.rotationFromInertial, we get the dense matri in
inertial frame
we need to return.
This implementation is simple but much more realistic than a constant
matrix, and it
should properly take into account the fact the uncertainty from the
prediction step
is larger when the time between measurements is long than when
measurements occur
frequently.
Finding the polynomials would remain here the responsibility of the
caller. Later on,
we can think about using FieldPropagator on a reference orbit to
estimate these
polynomials during the mission analysis phase prior to operations.
*(from redmine: issue id 403, created on 2018-03-22)*
https://gitlab.orekit.org/orekit/orekit/issues/9
force model for infrared radiation pressure
2018-08-07T09:40:50Z
Luc Maisonobe
force model for infrared radiation pressure
Radiation pressure force model handle only direct solar radiation
pressure.
A separate model for taking body-emitted infrared radiation pressure
into account would be nice.
*(from redmine: issue id 9, created on 2011-01-12)*
* Changesets:
* Revision 3ac3ff62b862ee89effcf1a4889b04f32fd8dbb2 on 2015-07-05T08:21:53Z:
```
Add getXmax, getXmin, getYmax, getYmin to BicubicInterpolatingFunction.
These can be useful to manage an OutOfRangeException without the need to
access the original x and y arrays.
Closes #9.
```
* Revision 5c7355161ae71aaeb94ad9a76a08bfb47a54b970 by Luc Maisonobe on 2016-08-02T06:07:08Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #9
```
* Revision 5c7355161ae71aaeb94ad9a76a08bfb47a54b970 by Luc Maisonobe on 2016-08-02T06:07:08Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #9
```
* Revision 5c7355161ae71aaeb94ad9a76a08bfb47a54b970 by Luc Maisonobe on 2016-08-02T06:07:08Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #9
```
* Revision 5c7355161ae71aaeb94ad9a76a08bfb47a54b970 by Luc Maisonobe on 2016-08-02T06:07:08Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #9
```
Radiation pressure force model handle only direct solar radiation
pressure.
A separate model for taking body-emitted infrared radiation pressure
into account would be nice.
*(from redmine: issue id 9, created on 2011-01-12)*
* Changesets:
* Revision 3ac3ff62b862ee89effcf1a4889b04f32fd8dbb2 on 2015-07-05T08:21:53Z:
```
Add getXmax, getXmin, getYmax, getYmin to BicubicInterpolatingFunction.
These can be useful to manage an OutOfRangeException without the need to
access the original x and y arrays.
Closes #9.
```
* Revision 5c7355161ae71aaeb94ad9a76a08bfb47a54b970 by Luc Maisonobe on 2016-08-02T06:07:08Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #9
```
* Revision 5c7355161ae71aaeb94ad9a76a08bfb47a54b970 by Luc Maisonobe on 2016-08-02T06:07:08Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #9
```
* Revision 5c7355161ae71aaeb94ad9a76a08bfb47a54b970 by Luc Maisonobe on 2016-08-02T06:07:08Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #9
```
* Revision 5c7355161ae71aaeb94ad9a76a08bfb47a54b970 by Luc Maisonobe on 2016-08-02T06:07:08Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #9
```
https://gitlab.orekit.org/orekit/orekit/issues/8
force model for albedo radiation pressure
2018-08-07T09:40:49Z
Luc Maisonobe
force model for albedo radiation pressure
Radiation pressure force model handle only direct solar radiation
pressure.
A separate model for taking body-reflected radiation pressure into
account would be nice.
*(from redmine: issue id 8, created on 2011-01-12)*
* Changesets:
* Revision 088d0f9222337a1b3be44b99523094ff0af06cde on 2015-07-05T08:19:10Z:
```
Added mapping functions to MathArrays.
These methods allow to map any univariate or bivariate function to
arrays.
This fixes several pull requests on github, but uses a generalized
mapping approach rather than specific api for each function (closes #6,
closes #7, closes #8).
```
* Revision 4aa83d71e9bc06811b276cc46c5ac473ed98b71d by Luc Maisonobe on 2016-08-02T06:05:28Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #8
```
* Revision 4aa83d71e9bc06811b276cc46c5ac473ed98b71d by Luc Maisonobe on 2016-08-02T06:05:28Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #8
```
* Revision 4aa83d71e9bc06811b276cc46c5ac473ed98b71d by Luc Maisonobe on 2016-08-02T06:05:28Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #8
```
* Revision 4aa83d71e9bc06811b276cc46c5ac473ed98b71d by Luc Maisonobe on 2016-08-02T06:05:28Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #8
```
Radiation pressure force model handle only direct solar radiation
pressure.
A separate model for taking body-reflected radiation pressure into
account would be nice.
*(from redmine: issue id 8, created on 2011-01-12)*
* Changesets:
* Revision 088d0f9222337a1b3be44b99523094ff0af06cde on 2015-07-05T08:19:10Z:
```
Added mapping functions to MathArrays.
These methods allow to map any univariate or bivariate function to
arrays.
This fixes several pull requests on github, but uses a generalized
mapping approach rather than specific api for each function (closes #6,
closes #7, closes #8).
```
* Revision 4aa83d71e9bc06811b276cc46c5ac473ed98b71d by Luc Maisonobe on 2016-08-02T06:05:28Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #8
```
* Revision 4aa83d71e9bc06811b276cc46c5ac473ed98b71d by Luc Maisonobe on 2016-08-02T06:05:28Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #8
```
* Revision 4aa83d71e9bc06811b276cc46c5ac473ed98b71d by Luc Maisonobe on 2016-08-02T06:05:28Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #8
```
* Revision 4aa83d71e9bc06811b276cc46c5ac473ed98b71d by Luc Maisonobe on 2016-08-02T06:05:28Z:
```
Updated Orekit after Checkstyle improvements.
Thanks to rnveach for the patch.
GitHub closes #8
```