Orbit Estimation - Outlier Filtering

1

Hey everyone,
Lately, I have been working on orbit determination, where I have regular GNSS measurements that possibly have large outliers. I want to run a Batch Least Squares OD when I get new measurements. The problem I ran into when using the Orekit outlier filter is that the number of warm up iterations changes from data set to data set and I prefer not to recalculate the OD over and over again till I find a suitable warm up. When doing research I came across the outlier filter used by GMAT which they call Outer Loop Sigma Editing (OLSE) which works very well and does not require setting any warm up before LS. I wanted to try and implement the filter in orekit, but the only solution (tho it which works like a charm) was a combination of using the DynamicOutlierFilter and pass it to a self-written BatchLSObserver in which I can retrieve the RMSE after each iteration and modify the sigma values of the dynamic outlier filter. I was wondering if there was a “cleaner” solution to this. Essentially what I would need is to have the RMSE available inside the EstimationModifier but I believe this is not possible.

I wonder if anyone has a nice idea of how to implement this in a better way.
Thanks for your help!
Benedikt

2

Perhaps your outlier filter could implement both EstimationModifier and BatchLSObserver?

This filter could also be a great addition to Orekit. Would you consider contributing it?

3

Hey Luc,
thanks for your answer. I can try to contribute this feature, yet I currently don’t have much time but I hope I can come back to this. Regarding combining the EstimationModifier with the BatchLSObserver I don’t know how I would then attach this to the BatchLSEstimator since you can currently only set one observer. Implementing this feature would then also require an API change/ addition here I guess.

4

If you want to use several observers, you can always put them in anything iterable (a list, a set, an array…) and use something like:

final Iterable<BatchLSObserver> iterable = ... set up the iterable...;
estimator.setObserver((iterations, evaluations, orbits,
                       orbitalParameters, propagatorParameters, measurementsParameters,
                       evaluationsProvider, lspEvaluation) -> {
    iterable.forEach(o -> o.evaluationPerformed(iterations, evaluations, orbits,
                                                orbitalParameters, propagatorParameters, measurementsParameters,
                                                evaluationsProvider, lspEvaluation));
});
5

ah, I see that’s nice of course. I mainly use the Python wrapper where this would be a bit more tricky I believe. Then I think implementing this wont take too much time and I believe I will find some time in the next month!

1 Like
6

I created issue#1687 for this. I will try and add this feature.

2 Likes
7

so in the meantime I managed to set everything up and created a first sketch on my fork here. Before opening an MR on the orekit forge I wanted to add a unit test for the outlier filter but could not find a good example how the the existing outlier filters are tested at the moment. The one thing I did find was in the AbstractOrbitDetermination class where outlier filters can be set up and selection between the normal outlier filter and the dynamic one is possible. Probably I would need to adapt these functions to allow for a greater selection of also potential future outlier filters? Also, is there a test case with actual outliers in the data? I’m looking forward to your feedback and suggestions!
Best
Benedikt

8

Hi @BS_space,

Yes,

Great!

Indeed you’ll probably need to adapt the outlier filters setup in AbstractOrbitDetermination.
I think all the tests are using them, search for the keyword “rejection” in the configuration files of the OD test suite (files with suffix “.in”), you will see how it’s done. These files are the ones read at the beginning of the tests to configure everything.

For now, the default behavior is to have dynamic filtering for all Kalman tests, and non-dynamic for all BLS tests. This is handled with a boolean in methods like createRangeOutliersManager and so on.

I think the best route for you would be to replace this boolean with an enum (SIGMA, SIGMA_DYNAMIC, RMSE) with: SIGMA by default for BLS, DYNAMIC always for Kalman, and, user-defined if a key like range.outlier.filter.type = RMSE is in the configuration file.

Hope this helps,
Maxime