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

Re: [Orekit Users] BatchLeastSquares issues


Le 15/11/2017 à 11:01, Ignacio Grande a écrit :
Hi Ignacio,
Dear Orekit users,

This is my first message in this list, nice to meet you all and thank you for making Orekit available for general use!
Thank you for the kind words!

I'm trying to run some orbit determination tests and I'm facing some issues with it that I'm not sure how to solve. I don't know if I found issues with the orbit determination implementation or if I'm doing something wrong.

For the test case, I have a simple circular LEO orbit and a radar station. I propagate the orbit for a number of days, and record the observations from the radar station. I can record range, azel and Doppler observations.

Then I add some Gaussian noise to the observations and feed them to the Batch Least Square orbit determination solver. As starting orbit I'm using the actual initial orbit used to propagate, which is very optimistic.

In some cases it works just fine, and estimate() returns after a few iterations with a low residual value. I'm using a LeastSquareObserver to monitor the evolution of the process that can be found here: https://pastebin.com/QQ1AW65i

However, I'm facing several problems with some cases:

* When using only azel observations, the process makes 7 iterations and then becomes unresponsive. After a lot of time (like half an hour), it makes an 8th iteration and keeps processing. I haven't waited to check if there is a 9th iteration after an hour, but it seems stuck. Test case is here: (modify path to orekit-data as provided): https://pastebin.com/uYjUw7Pn

For this one I think you ran in a bug we fixed this summer. If I remember well it is related to issue 360 in Orekit forge.
There was a huge number of calls to the observers in the ParameterDriversList class, growing exponentially with the number of iterations of the estimator.
It's been fixed now so I guess you must be using the latest release of Orekit (9.0.1) and not the development version.
To get the fix you can either:
 - If you're using Maven: Link your project to Orekit version "9.1-SNAPSHOT" in your "pom.xml" file
 - If you pulled Orekit from the git repository: check-out the "develop" branch and use this one
 - Download the development version from the forge.

Regardless of this bug in Orekit, the convergence on your test case is hard to obtain.
I ran the test case and it did not converge after 40 iterations. I'm not sure why.
Maybe it's the sigma of 1 degree in azel that is too high and the Gauss-Newton optimizer cannot converge with the threshold you put. I think the optimizer is moving around a set of solutions that have almost the same RMS but the distance between two consecutive solutions is too high for it to tag the estimation as converged.
I found three ways to make it converge. You can either:
- Set the sigma to a lower value: 0.5 degree seems to work
- Lower the convergence threshold: 0.1 (instead of 0.01) seems to work
- Use the Levenberg-Marquardt optimizer. For example replace in your code:
    GaussNewtonOptimizer optimizer = new GaussNewtonOptimizer(Decomposition.QR);
with:
    double initialStepBoundFactor = 100.;
  LevenbergMarquardtOptimizer optimizer = new LevenbergMarquardtOptimizer().withInitialStepBoundFactor(initialStepBoundFactor);
It is converging on my machine with any of these fixes.
* When Doppler measurements are used, the initial RMS is absurdly large and usually the process doesn't converge, so I end with some Exception from Orekit or Hipparchus about NaNs, like in this example: https://pastebin.com/P0PBtec7

* Sometimes during the process (usually at the first iteration) it tries re-entering orbits and I get exceptions of low altitude, like in https://pastebin.com/gtU1ZkKB

I haven't actually tested these two with the test cases you provided but I think I know where the errors come from.
When you're producing the range rate measurements, you calculate a doppler value using the TopocentricFrame class.
Then you input this value in a "Range" measurement instead of a "RangeRate" measurement.
So for the 1st measurement you have for example a doppler value of 6000 m/s and you put this value as a Range. So Orekit thinks the satellite is at a distance of only 60km from the station... hence the re-entering orbit.
If you just replace the "Range" by "RangeRate" it should work fine.
I've read that the Hipparchus library doesn't support parameter bounding and it is done in Orekit with predefined bounds so it may not be possible to avoid re-entering orbits during the estimation process. It happens more frequently when the initial orbit is not the one used to propagate (as in these cases), but one coming from an IOD. In that case, it's pretty common (in my tests) to get re-entering orbits or diverging iterations even with high orbits (about 700 km).

I'm not sure if this user list is the best place to report this problems as I'm not discarding that the issue is on my wrong usage of the library. But I could fill issue reports if you wish.
I think you're in the right place. Your issues and their fixes can very well help other users who may be struggling with the orbit determination of Orekit.

Thank you very much!

You are very welcome. I hope my answers help you!

Maxime