Precise position solver 🦀
Nalgebra
is used for anything related to linear algebraNyx-space
provides required features in orbital calculationsHifitime
provides timing and timescale definitionsGnss-rs
provides basic GNSS definitions
The RINEX Wiki describes extensive application of this framework.
The objective is to resolve PVT solutions, implemented in the form of a prelude::PVTSolution
,
ideally the most precise as possible, at a given Epoch.
Resolving a PVT requires a minimum number of SV (actual measurements) in sight and within the preset criteria:
- 4 SV are required, per Epoch, in default mode
- 3 SV in fixed altitude mode
- 1 SV in time only mode
The preset criteria are manually set in the configuration file (or config script). At the moment, refer to the RINEX Wiki pages for meaningful examples.
Depending on the preset configuration, other requirements will apply to the previous list, most importantly:
CPP
strategy will required pseudo range observation on a secondary frequencyPPP
strategy will required pseudo range and phase observations on a two frequencies- SNR, Elevation and Azimuth mask will require to gather the required amount of SV within those conditions
Each PVT solution contains the Dilution of Precision (DOP) and other meaningful information, like which SV contributed. We have the capability to express the clock offset to any desired Timescale.
The solver's behavior and output results are highly dependent on the selected strategy.
Advanced strategies require deeper knowledge and most likely more tuning of the solver configuration. The Rust/JSON infrastructure is powerful enough though, to allow to only define the config parts you are interested in: others will simply default.
PVTSolutionType defines the type of solutions we want to form and therefore,
the minimum amount of SV we need to gather. As previously stated, other criteria like min_sv_elev
or max_sv_azim
will restrict the condition on those vehicles that they must fit in
to be considered.
When fixed_altitude
is set to a certain value, the quantity of required SV is reduced by 1.
This has no impact when PVTSolutionType
is set to TimeOnly
.
The SolverOpts
configuration gives more advanced options on how to tweak the solver. Briefly, this allows to
- select one of our Navigation Filters, like Kalman filter or LSQ
- define the PVT solutions confirmation criteria
Modeling
defines what physical and environmental phenomena we compensate for.
Modeling are closely tied to the selected solver strategy. For example,
models that impact at the centimetric level like the sunlight rate, are not meaningful in strategies other than advanced PPP.
On the other hand, you will not reach metric solutions, whatever the strategy might be, if a minimum of physical phenomena are not accounted for.
This solver is always capable of modelizing all conditions and form a solution.
It is important to understand how our API is designed and operate it the best you can to get the best results.
Troposphere bias always needs to be estimated.
By default, the solver will use a model implemented in the [model::tropo API].
If you're in position to determine yourself the Tropospherical Delay components (TropoComponents structure)
at the required latitude and Epoch, you are highly encouraged to provide your data.
To do so, we use a function pointer that can serve as a TropoComponents source.
TropoComponents evaluation parameters (function pointer arguments) should be :
- Epoch
- altitude (above sea level) expressed in meters
- latitude expressed as decimal degrees
For Epochs where the data source is not capable to supply data, that is not a problem, we will rely on the internal model.
Example of handmade TropoComponents provider :
TODO
TODO