Hi ! I am using orekit to perform ionosphere-free code+phase GNSS OD with a kalman estimator. I am using OneWayGNSSPhase with the ambiguityCache. And in order to deal with the cycle slips I used PhaseMinusCodeCycleSlipDetector (the two frequency detector outputted 0 cycle slips despite very low thresholds) then, for each satellite and frequency, I used .getAmbiguityDriver().addSpanAtDate(measDate); on the measurement ambiguity driver (following the recommendation of this topic here ). Now whenever the kalman is called either at its initialisation or for a kalman.estimationStep(measurement), I get the following error :
org.orekit.errors.OrekitIllegalStateException: le paramètre ambiguity-G07-sat-0-154.00 contient plusieurs intervals dans sa TimeSpanMap de valeurs, il faut utiliser la méthode getParameterDerivatives(driver, date) at org.orekit.estimation.measurements.EstimatedMeasurement.getParameterDerivatives(EstimatedMeasurement.java:151) at org.orekit.estimation.sequential.KalmanModel.getMeasurementMatrix(KalmanModel.java:277) at org.orekit.estimation.sequential.KalmanModel.getEvolution(KalmanModel.java:343) at org.orekit.estimation.sequential.KalmanModel.getEvolution(KalmanModel.java:47) at org.hipparchus.filtering.kalman.extended.ExtendedKalmanFilter.estimationStep(ExtendedKalmanFilter.java:56) at org.orekit.estimation.sequential.KalmanEstimator.estimationStep(KalmanEstimator.java:142)
Is there any way to overcome that ? Maybe should I skip the addSpanAtDate and temporarily change/increase the covariance matrices at each cycle-slip ?
Thank you.
Hi Luc and thank you for your answer, I have created an issue under #1697. As far as I understood the methods .estimationStep(..) or the kalmanBuilder.build() they do not allow to specify the measurement date. Am I wrong ?
So what is the appropriate way to deal with changing the covariance of measurement parameters whenever a cycle slip occurs ? is it to create an instance of the interface CovarianceMatrixProvider that returns an appropriate process noise matrix according to the cycle slips ?
Changing the covariance matrix could work.
Adding the date parameter is probably the clean way to solve issue 1697, but it requires modifying the library.
Could you check very fast it it solve the issue for you?
There is a vote ongoing for publishing version 13.0, if you can confirm very fast it work, we could probably interrupt the vote and merge the fix in this version, or we could just let the vote conclude and publish a patch version (13.0.1) very soon after, or we could just put the fix in develop and wait for 13.1 if you can use develop on your side even before 13.1 publication.
Hi Luc ! Sorry for the delay, I am quit new to java ^^". I have modified the source files in kalmanModel to solve the error. It is indeed quit simple, I have just added the argument date in a few calls. I uploaded the changes git file. I just went the brute way, but I guess it is cleaner to check whether the paramaterdriver has indeed several time spans before calling each time the functions that needs the measurement date. I am not sure I can directly contribute to the future-imminent release, I did my tests on the 12-2-1-R1.
Unfortunately, my kalman is still not converging, I guess there is other bugs to be solved in my own code.
I was wondering, what the timespans do is that at each new one the corresponding covariance error matrix is set to the initialP (first argument of ConstantProcessNoise) ?
No, unfortunately it is much cruder than this… it just uses the new value.
In fact, the time span is more suited for batch least squares as all parameters are fixed, it then just set up a different parameter for each time span that can be adjusted independently from each other. So for batch least squares, we introduced these time spans and the fact there are several spans induced the runtime error you encountered. What I suggested was just to solve this runtime error.
In the case of Kalman filtering, there would in theory be no need for this as the parameters are updated automatically. Ambiguities are special cases, though because as long as there are no cycle slips on the receiver, update should remain smooth and Kalman handles that perfectly well. But when a cycle slip occurs, you are right, it is the covariance that should be updated, so my initial suggestion in the original thread really holds only in this original case that was batch least square. In your case, it just introduces new problems (the time spans numbers), without addressing the root cause (covariance increase). I’m sorry I gave you a wrong advice
So back to your initial problem, I now think the covariance is the key and so you should remove the time span map and focus on your own implementation of CovarianceMatrixProvider that knows about cycle slips (or start of visibility, where the ambiguity is also unknown).
Thank you Luc, at least with the covarianceMatrixProvider the kalman is no longer diverging .
Yet, my OD is still getting unsatisfactory results, I suspect the PhaseMinusCodeCycleSlipDetector, do you know if it is well suited for LEO-MEO oneWayGNSS ?
I also noticed that the GeometryFreeCycleSlipDetector gives me empty outputs because I have got 2 phases of different signal code (L1C and L2W), but the bias between the two is unlikely to affect the detection since it should evolve very slowly, is there a way to prevent the cycle-slip detector from checking the signal codes ?
I really don’t know. The cycle detectors (both geometry-free and phase minus code) use the signal to build a map a cycle slips (see CycleSlipDetectorResults) and this map uses the higher frequency as the key in this map for dual-frequency detectors, but I don’t really known what is done. The implementations attempt to follow the published algorithms; their validation status is probably dubious, though.
.