Orbit determination for interplanetary missions

Orekit development
5

Hi,

That would be a great addition!!
I too like @Serrof think that the SpacecraftState has become too bloated but I think your solution @bcazabonne may reduce its complexity.

I would pay extra attention to the measurements and the light time correction inside of them.
Since we use "shiftedBy"s to correct for the light time it can lead to big errors, given that the delay of the signal will be of several minutes in interplanetary motion.
Maybe it will be ok for a spacecraft on a heliocentric cruise. But, take for example a radio-relay spacecraft around Mars with a complex force model which is communicating with the Deep Space Network antennas on Earth.
The signal can take up to 20 minutes to arrive/depart from the spacecraft to the antenna, and I’m pretty sure that “shiftedBy” won’t perform well in that case.

Some time ago with @luc we tried to add an OrekitStepInterpolator in the signature of the theoreticalEvaluation method of the measurements to improve the extrapolation of the state used in light-time corrections, but:

  • It was already hard (to my defense I was a beginner in Orekit by that time :slight_smile: )
  • It implied that the OD was performed with an integrated propagator (and now we can do it with analytical propagators too)
    (Edit: I was wrong here, analytical propagators also expose an OrekitStepInterpolator for the step handlers)
  • It supposed that the light-time delay was contained in the time interval of the interpolator. Looking back at the example above, I don’t think we can use 20min steps with a complex gravity model of Mars

Now that I’m putting some thoughts on this again, I think the best course of action would be to propagate on the whole time span first, store the results in a BoundedPropagator, and then compute the estimated measurements using this propagator (or a more generic object like PVCoordinatesProvider). That way we can correct for light-time delays much better.
This will break the logic of the MeasurementsHandler gathering the measurements’ estimations on the fly during propagation.
And probably induce API changes in the measurement classes and the OD classes.
Kalman filters will somehow also need to store the ephemeris of the propagation performed during the prediction step.

Anyway, that was long but I just wanted to warn you about that potential trap beforehand.
I don’t think that it’s impossible to do though.

Maxime

1 Like