Issue with orbit Determination from OEM/measurements

Orekit usage
1

Dear Orekit team,

For an open source project that I am developing, I am trying to use Orekit to generate orbit estimations, based on:

  • an original TLE, and
  • a set of measurements, in the form of TDMs (for ranging) or OEMs (GPS based)

In order to make some tests and to make sure I get the concept right, I prepared a test (see attached) with:

  • an initial TLE (from Celestrak), let’s call it TLE-1, which is ca 2 weeks old (epoch: 14/03/2023);
  • an updated TLE (from Celetrak), rather new, let’s call it TLE-2;
  • a OEM file, generated by propagating the updated TLE-2, with one point every 5 minutes, covering ca. 2 days (27/03 - 29/03).

The idea is that, starting from the initial TLE (TLE-1) and applying orbit determination using the OEM file generated by the updated TLE (TLE-2), I could derive a 3rd TLE (TLE-3) that is very close to TLE-2, so that the orbit position/velocity errors between the propagated orbits of TLE-3 and TLE-2 is actually lower than the error obtained comparing the propagation of TLE-1 and TLE-2.

The reality is that the error is actually quite large: in terms of positioning, TLE-1 has an error of ca. 3.6 km with respect to TLE-2, but the derived TLE (TLE-3) has more than 30 km error on the 27/03 with respect to TLE-2…

image
image800×200 11.5 KB

I defined the orbit determination without atmospheric drag and solar radiation pressure, with a spacecraft mass of 2600 kg and I got the following TLE-3 (in ca. 5 minutes processing):
1 54234U 22150A 23073.00000000 .00000224 00000-0 10631-3 0 1368
2 54234 98.7088 12.4818 0001523 60.1873 15.8200 14.19571986 17555

If I run the same with the two additional perturbations, the estimation takes much longer and after 20 minutes I stopped it.

Changing the mass to 600 kg does not introduce any change to the derived TLE orbit:
1 54234U 22150A 23073.00000000 .00000224 00000-0 10631-3 0 1368
2 54234 98.7088 12.4818 0001523 60.1873 15.8200 14.19571986 17555

The Celestrak TLEs are:

TLE-1
1 54234U 22150A 23073.00000000 .00000224 00000-0 10631-3 0 1368
2 54234 098.7089 012.4823 0001096 091.3860 344.8096 14.19561677017553

TLE-2
1 54234U 22150A 23082.14800799 .00000237 00000+0 13325-3 0 9999
2 54234 98.7098 21.4778 0001071 76.9929 283.1367 14.19566608 18848

Do you have any insight/feedback on what I might setup in the wrong way, and why the derived orbit is so off with respect to the OEM positions used as input measurements? I am attaching the code of the test and the OEM input file as well, in case you have some time to give it a look. The approach is the same from GorgiAstro.

Thanks a lot for the help, and congratulations for Orekit: it is really a nice piece of software. I am sure that the problem I am observing is related to something wrong used in my code, since the OEM data is correct and, if I just propagate the orbit defined by the OEM, it pretty much matches the propagation from the generating TLE (TLE-2).

Best regards,
Dario
OrbitDeterminationComputation.java (12.1 KB)
measurements.xml (222.8 KB)

2

Hey there,

I haven’t looked at your code, but if your purpose is to fit TLEs, you should stick to the SGP4 model. This means using TLEPropagatorBuilder for your OD. You won’t have the choice in the forces but you can then estimate the B* used with the non-gravitational ones.

Best,
Romain.

3

Hi @dariol83,

Welcome to the community and thank you for the kind words !

I agree with @Serrof you should estimate the TLE directly instead of using a numerical propagator to fit the measurements.
You can find an example in the tutorial TLEBasedOrbitDetermination.

Two things I noted in your code:

  • Your initial orbit is 9 days before the reference TLE and 13 days before the first measurement. You should probably first propagate to ref TLE date with SGP4, this should save you some computation time.

  • Be aware that the estimation date is the initial guess date so in your case 2023-03-14.
    Then you use stateToTLE which fits a TLE initial state at this date with a fixed point algorithm.
    And you compare this to a TLE that is dated around 2023-03-23 so the error is expected to be huge. stateToTLE is not meant to fit a TLE, it is accurate enough at given orbit date but not after 9 days of propagation.
    In your case you should redo an OD from your fitted numerical propagator to a TLE. Instead of doing that, as Romain said, you should directly estimate with SGP4 using a TLEPropagatorBuilder.

Hope this helps,
Maxime

4

Hi guys, thanks a lot for having spent some time on the issue and with the code. I will need some time to ‘digest’ the hints (I am not an expert and I need to understand the terminology), but I am really reassured to know that I did something wrong :smiley:

I will check the link and what you just reported, and hopefully I will report here good news.

Thanks a lot, really!!

5

So, I followed your suggestions and I used a TLEPropagatorBuilder, making sure to propagate the initial TLE up to the time of the first measurement. Now the derived TLE is following pretty closely the new TLE, while the old TLE is diverging more and more. So I think I am on the right track.

image
image800×200 15.3 KB

For reference, I attach my updated code. I will still play a bit with the code, to tune the end result a bit.
Thank you very much for your help, I am learning a lot by exploring with Orekit!

Best regards,
Dario

OrbitDeterminationComputation.java (9.8 KB)

2 Likes
6

Hi @dariol83,

I’m glad to know you managed to make it work !!