Support roaming correctly

[gwbres]

@ChristopherRabotin, @jmfriedt,

When navigating, we always determine the receiver state with respect to a local (x0, y0, z0) reference point:

Currently, static applications of the solver works very well. Whether the user specifies x0, y0, z0, or we figure it ourselves in a first special iteration, it works as expected.

The problem is that I always use (x0, y0, z0) as figured at build time or first iteration:
https://github.com/rtk-rs/gnss-rtk/blob/main/src/solver.rs#L437. If I use the past solution (t-1) as x0, y0, z0, when attempting to resolve solution(t), the solver starts to oscillate rapidly.

To my understanding, this is what we should ideally do, otherwise roaming rovers (so called dynamic applications) will not be supported correctly, the rover rapidly moves away from (x0, y0, z0) which can no longer serve as a local reference point

[ChristopherRabotin]

That sounds correct to me : the iteration should return to the original point all the time, unless you define another point in space and time to be the new reference. In my work, we often decide before the mission how many days we want the first to cover (eg 14 days), and we typically run the filter for the whole period throughout the mission.

[gwbres]

the iteration should return to the original point all the time,
unless you define another point in space and time to be the new reference

I presume it oscillates because the redefinition of the reference point (in space & time) requires to reset the fillter.

The problem being for roaming application (like cars and rockets) when to decide we should evaluate a new reference point.
The faster the rover, the quicker you need to re-evaluate this point.
Yet in our use case (not yours) I don't see any reason x0,y0,z0 could not be (0, 0, 0), ie., the center of the ECEF system. It's just farther from actual truth and requires more iteration of the filter, but remains valid initialization. Now that I've said that, it might just be a "false" topic

[ChristopherRabotin]

As I reread this, it sounds like you're saying that being iterations of the batch least squares estimator, the initial position of the roaming vehicle changes. If so, that's perfectly normal! In fact that I'd the whole point of a BLSE: estimate the original state until the square of the distance between the propagated initial state and the measurements are the smallest.

Typically, the BLSE is used in iteration mode until the solution cannot be improved upon: https://rustdoc.nyxspace.com/nyx_space/od/process/struct.IterationConf.html.