Google has just kicked off the 2023 Smartphone Decimeter Challenge on Kaggle. Similar to the previous two years, it is a competition to see who can generate the most accurate solutions for a large number of raw observation data sets collected with Android phones on vehicles driven around the Bay Area and Los Angeles. In the previous two competitions, all the phones were higher-end models that supported dual-frequency GNSS. This year, they are also including mid-range phones with only single frequency GNSS to better represent the total population of phones. This will make the solutions more challenging.
They have also increased the total prize money from $10,000 to $15,000. The competition started just over a week ago and will run until May 23 next year. The top three winners will be invited to present papers on their solutions at the 2024 ION GNSS+ conference.
Last year, after the competition had concluded, I shared a version of my final solution in a notebook on the competition’s Kaggle page. When copied to a local computer and run, it will generate a result that can be submitted to Kaggle and will place 5th in last year’s public leaderboard.
I have just published an updated version of this notebook on this year’s Kaggle page. It is the same solution as the previous version, just updated to run with this year’s data and also modified so it will run more easily on Linux as well as Windows. For anyone interested in joining the competition, this latest version will produce a score of 1.80 meters, which at the moment is good enough for first place. I’m sharing it to help promote a stronger competition as well as to encourage the use of RTKLIB.
Below is a screenshot of the state of the public leaderboard as of September 21. You can see the most recent version of the leaderboard here.
For reference, last year’s winning score on the public leaderboard was 1.38 meters, and I expect this year’s winning score to be lower. So, this is only a starting point, but it should give anyone interested in competing an opportunity to take advantage of previous work and jump in near the front of the pack (at least for the moment).
I’m happy to answer any questions about using RTKLIB in the competition but the rules require that I do that in the competition’s Kaggle discussion group so that the information is available to all participants. There was quite a bit of collaboration between competitors in last year’s competition as well as a lot of information shared after the competition, all on the competition’s Kaggle discussion group page, so check that out if you haven’t already.
More details of the optimizations I have made to RTKLIB for smart phone observations are described in these links:
rtklibexplorer 
Is RTKLib still a freeware? Last time I downloaded it, there was something on the site that said it was now a shareware or licensed software.That was several years ago around 2020 if I remember correctly. Strange that I could no longer find that site. I think it belonged to the code developer who passed away and the estate was trying to get some fees from his work.
LikeLike
RTKLIB is still free for commercial or non-commercial use under an open source BSD license. Tomoji Takasu, the original developer of the library, is still alive and well.
LikeLike
hello, what do you think “factor graph optimization” with “EKF” in GNSS RTK processing,
will FGO better than EKF in this field, i see a lot of participants use “FGO” instead of “EKF”
LikeLike
It’s a good question, I don’t know the answer. FGO does have an advantage that is can process multiple samples as a batch, but I believe it also uses a lot more CPU effort than an equivalent EKF. It’s also true that some of the solutions using FGO were also estimating velocity separately with doppler and carrier phase. IT’s hard to know how much improvement came from FGO and how much came from the additional velocity estimates, or other algorithmic differences.
LikeLike
thahks for your reply, agree with you
doppler velocity and FGO all gives benifit to RTK solutions
LikeLike