IOD with Multiple Passes

Hello everyone,

I am trying to utilize optical observation data with IOD methods that Orekit already have. Consider I have the following observational data:


Using IodLaplace or Gauss Method for the first 3 observations give me acceptable results for inclination and RAAN, depending on the orbit. However I have multiple passes as seen on the data table above.

Normally, I would expect that multiple passes to constrain the orbit so that we can increase the accuracy of other orbital elements. At this point, 2 seperate IOD methods to different passes can be applied (total of 6 data is used), then the mean of the orbital elements could be obtained. OR we could just use 3 observational data from a single pass for IOD, and the remaining data can be fed to batch least square method.

I am not sure which one performs well, and gives me better results.

This one’s a bit of an Orbital Mechanics question but I though people here on forum might know the answer or have an interpretation to this.

Thanks in advance!

Hi @Echulion

I’m not an IOD expert but it it is an interesting topic.
Maybe you could try the following method:

  • Estimate an orbit based on the first pass using Laplace method. From this orbit, compute the distance between the station and the spacecraft
  • Estimate an orbit based on the second pass using Laplace. From this orbit, compute the distance between the station and the spacecraft.
  • Estimate the orbit based on the IodGooding method.

I know this “algorithme” is used but I’m not sure it will works for multiple pass. I’m interesting to know your result :slight_smile:

For more theoritical elements about IOD method, you can look at SCHAEPERKOETTER’s master thesis.

Best regards,

Hi @Echulion,

Just adding up to Bryan’s answer

I would personally favor this method for two reasons:

  • IOD methods generally assume Keplerian (two bodies) dynamics while you can use a much more complex model (numerical propagation with force models) with a batch least-square OD.
    So the results should be closer to reality with a batch LS.
  • Taking the mean between two IOD is choosing the middle value of two poorly determined orbits.
    On the other hand, the batch LS OD will really try to find the best-fit trajectory for all the measurements.
    And the more measurements you have, the better the OD should be.

Best regards,

Hello @bcazabonne , @MaximeJ

Thanks for the valuable discussion and advices. I also quickly skimmed through the mentioned thesis and its definitely gonna be useful for my IOD studies, thanks a lot :slight_smile: I tried your suggestion @bcazabonne , but unfortunately Laplace IOD does not give good results. I think either Gooding IOD method is not very stable in terms of convergence (since it depends on initial distance) or I am doing something wrong :man_shrugging:

Well I tried this way again, by performing an IOD calculation with 3rd, 4th and 5th data, and fed the rest of it to the BLS estimator. Long story short, 6-7 data is not even nearly sufficient for a good OD. I reckon +100 observational -and accurate- data is required here…?

Instead of this, maybe trying to improve individual Kepler elements would be a solution. I am trying this now but im not sure about this.

from org.orekit.propagation.conversion import TLEPropagatorBuilder, FiniteDifferencePropagatorConverter
from org.orekit.propagation.analytical.tle import TLEPropagator

threshold = 1.0  
tle_builder = TLEPropagatorBuilder(orekitTle, PositionAngle.MEAN, 1.0)
fitter = FiniteDifferencePropagatorConverter(tle_builder, threshold, 1000)
fitter.convert(states_list, False, 'BSTAR')  
tle_propagator = TLEPropagator.cast_(fitter.getAdaptedPropagator())
tle_fitted = tle_propagator.getTLE()

fitter.convert line asks for all the states but let’s say I only want to improve one Kepler element. Isn’t that possible?

Edit: I might have misunderstood the above code snipped and the purpose of FiniteDifferencePropagatorConverter. Kinda confused now :frowning:

Could you show me how did you implement the algorithm?

Angles-only IOD methods usually have a poor accuracy… They are really useful to create an initial guess for the OD. But the initial guess is not very accurate.
In addition, if you only have 6-7 observations to perform the OD with an initial guess computed from an IOD, that’s probably a difficult problem to solve for the optimizer.

Did you tried with a LevenbergMarquardtOptimizer?

I don’t know if 100 observations are needed. The more measurements you have, the better the observability. :slight_smile:

One of the purpose of the FiniteDifferencePropagatorConverter is to generate a TLE that fits a sample of states (represented here by states_list parameter in your example).

I don’t think you can improve your initial guess using the fitter.
Again, I’m not an IOD expert but I think that combining IOD method, like the algorithm I proposed in the first comment, is a solution to improve the orbit computed by IOD. Another solution could be to try Gauss method instead of Laplace. But unfortunately it is not yet implemented in Orekit…

Best regards,

Hey there,

I am attaching the code and the data to this message.

I was already using LevenbergMarquardtOptimizer :slight_smile:

Thank you for the clarification, now I understood its purpose.

As you stated, these methods have poor accuracy and can be improved as we feed more and more data.

IOD methods provide me with relatively accurate results for inclination, RAAN and mean motion. But, is there a way that you know, to improve the orbit of an unknown satellite by just improving its remaining Kepler elements one by one? If this can be done, remaining Kepler elements (eccentricity, arg of perigee etc.) could perhaps be improved and as a result we’ll get a better orbit for the unknown satellite!

Kind regards,

48042oneweb.txt (408 Bytes)
Laplace IOD based range calculation for IOD Gooding.ipynb (28.4 KB)

That’s the main issue of angular-based methods… Good accuracy for the orbital plane, but poor accuracy for the orbit’s shape.

I recently encounter this issue. The eccentricity of the satellite was 0.0012 and the IOD estimated 0.32…

What we’ve done to solve the issue is simple, but it is a big assumption. The assumption is that the orbit is a near circular orbit. So, the eccentricity is close to 0.0. The algorithm is:

  1. Override the eccentricity computed by IOD. Let name it ecc_over. ecc_over could be equal to 0.0 here. This is the big assumption. But 0.0 is clearly a better value compared to the value estimated by the angular-based IOD.
  2. Compute the corresponding semi-major axis: sma_over = [ sma_iod * (1 - ecc_iod * ecc_iod) * (1.0 + ecc_over * cos(true_anom_iod) ] / [ (1 - ecc_over * ecc_over) * (1 + ecc_iod * cos(true_anom_iod)) ]

The above equation is generic to any ecc_over value.

At the end, the estimated orbit is:

  • sma_over
  • ecc_over
  • inc_iod
  • raan_iod
  • pa_iod
  • true_anom_iod

These are big assumptions, but for near-circular orbit it improves the accuracy.

1 Like