about google smartphone decimeter 2 challenge

Got kaggle silver medal. This was an interesting challenge to build trajectory using gnss/imu measurements from smartphones with maximum accuracy possible.

I tried two different approaches for this competition:

• rtklib based
• global optimization factor graph approach

source code.

1. Rtklib tweaking

Based on 'Getting started with RTKLIB' notebook.
Tried tweaking different configuration parameters.
Helped keeping cycle slip flags from receiver (slip_mask=3)
and adding weighting by snr and pseudorange uncertainty:
stats-errsnr: 0 -> 0.003
stats-errrcv: 0 -> 0.1
stats-errphaseel: 0.003 -> 0
stats-errphase: 0.003 -> 0

Finally rtklib solution was postsmoothed by https://www.kaggle.com/code/taroz1461/carrier-smoothing-robust-wls-kalman-smoother notebook.

Tried ensembling between weighted by elevation and weighted by snr -> worser results.
Tried enabling ambiguity resolution- noisy data, false fixes -> no improvement.
Tried estimate velocity (estval() function) not by doppler but by TDCP technique (adr),
but after debugging understood that velocity from doppler (results from estvel())
rarely (only in case of big pos variance) comes into ekf state, and velocity is got mostly from kalman state,
did not much have time/success in modifying rtklib ekf model to adapt this.

2. Factor graph approach

Hope was that this is kind of global optimization model formulation (unlike ekf)
and it can potentially help.

Adopted this code https://github.com/weisongwen/GraphGNSSLib.

This approach is using preprocessing via rtklib and afterwards solves
optimization problem via ceres solver.

It did not much work out of the box for this dataset:
it relied on ambiguity resolution (but there were no fixes at all).

Factors which finally were used:

• double difference pseudorange factor with reference station (analog to rtklib for code measurements, ddres() function)
• motion factor (distance between neigh epochs divided by dt - should be equal to est velocity)
• doppler factor for velocity estimation (it was used only if cycle slip was detected, otherwise adr factor was used),
  estimation by doppler is close to estvel() function in rtklib
• adr factor for velocity estimation (TDCP technique, see paper: Time-differenced carrier phases technique for precise GNSS velocity estimation), plus of tdcp - is removal of integer ambiguity term.

After testing with above factors I did get results severely affected by outliers,
so tried to remove outliers by switchable constraints/big initial residuals, got some kind of progress.

Also the resulting trajectory was nonsmooth after all above factors so added kind of acceleration constraints
for big acceleration. And also postprocessed solution with kalman smoother based on notebook listed above.

Submission

For submission I used weighted average of these two approaches.