[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orekit Developers] Question about verification of TLE using Orekit9.0

billgacsli@163.com a écrit :


Hi Rongwang Li,

I am a newer of Orekit9.0. My name is Rongwang Li. It is amazing for me, so

Now, I have a question about the verification of TLE. The orbital elements do
NOT match.

For example (from the file "SGP4-VER.TLE"):
1 00005U 58002B   00179.78495062  .00000023  00000-0  28098-4 0  4753
2 00005 34.2682 348.7242 1859667 331.7664 19.3264 10.82419157413667 0.00
4320.0        360.00

The ref output is as following (see the file "tjavaver.out.ref" for details):
5 xx
       0.00000000    7022.46529266   -1400.08296755       0.03995155
1.893841015  6.405893759  4.534807250
     360.00000000   -7154.03120202   -3783.17682504   -3536.19412294
4.741887409 -4.151817765 -2.093935425    8635.348839 0.185684   34.26805
347.97998  332.85719  252.46822  273.52846

What I get is:
5 xx
       0.00000000    7022.46529267   -1400.08296755       0.03995155
1.893841015  6.405893759  4.534807250
     360.00000000   -7154.03120202   -3783.17682504   -3536.19412294
4.741887409 -4.151817765 -2.093935425    8635.348829 0.185684   34.26905
347.97553  332.85501  252.46822  273.52846

We can see that the position and velocity in TEME do match, but the orbital
elements do NOT match exactly. What's the problem with it?

The following code is what I used in step handler,

PVCoordinates pv = state.getPVCoordinates(FramesFactory.getEME2000());
Orbit orbit = new CartesianOrbit(pv, FramesFactory.getEME2000(),
state.getDate(), Constants.WGS84_EARTH_MU);
KeplerianOrbit keplerianOrbit = (KeplerianOrbit)

The culprit is probably in the line above.

TLE parameters correspond to a dedicated model, SGP4/SDP4, which is a *mean* model.
This model removes short periodic terms and provides a smoothed orbit. This
implies that you cannot simply convert between orbital parameters and Cartesian
parameters normally, with a single point as is done by OrbitType.convertType.
This single point conversion is valid only at the single point itself for
osculating elements, not for mean elements.

As a consequence, depending on how the conversion is done, how the initial
parameters at the input of the conversion were generated beforehand, and in
which direction you perform the conversion, you may end up with exactly
matching Cartesian and different Keplerian elements or the other way round.

Here, you generated Cartesian and converted to Keplerian, so the Cartesian did
match and the Keplerian didn't. It is normal here.

The proper way to convert TLE parameters to other orbital types is to use
a full sample, covering about 2 or three orbits. There are dedicated classes
for this in Orekit, look at the org.orekit.propagation.conversion package.
In this package, you use one reference propagator to create the sample,
and a converter managing a propagator builder to create a second propagator
from a different type that will pass through the sample with minimum residuals. The second propagator can be as simple as a Keplerian propagator (in which case
you find the Keplerian orbit closest to the sample), or it can be a better
propagator, adding perturbating force models. Choosing the proper propagator
to convert to depends on what you want to do with the converted orbit. For
simple display purposes a Keplerian propagator would be enough. For further
computation, a numerical propagator with a force model including at least the
same forces as SGP4/SDP4 (i.e. first zonal terms and depending on altitude
drag, third bodies, radiation pressure...) would be more adequate.

best regards,

out.print(String.format("%15.6f %8.6f %10.5f %10.5f %10.5f %10.5f %10.5f",
                keplerianOrbit.getA() / 1000.0, keplerianOrbit.getE(),


MathUtils.normalizeAngle(keplerianOrbit.getPerigeeArgument(), FastMath.PI)),


Best regards!

Rongwang Li