\n
![\"Ft1PB.png\"](\"https://s1.328888.xyz/2022/08/01/Ft1PB.png\")
\n
![\"FtKuP.md.png\"](\"https://s1.328888.xyz/2022/08/01/FtKuP.md.png\")
First of all, thanks to the organizers and Kaggle for organizing this unique challenge. We would also thank the other participants. It's the competition that makes things more interesting. Thanks to my teammates @linwei9, @chris62, @gmhost, and @rytisva88. It's team work that won us a gold medal.
\nOur solution is an ensemble of RTK and taro's public baseline. Thank you @timeverett @taroz1461 for your great contribution. These two codes help newbies like me to get started with GNSS positioning quickly. But since we didn't end up making too much improvement to the taro's public baseline, RTK played the most part in our final solution.
\nSwitch the Loss function of WSL of position estimation and velocity estimation from soft_L1 loss to Cauchy loss.
Optimize the parameters of Kalman filter on phone-wise with Optuna. It helped LB, but not really helped pb.
Predict whether the car is stopping with a threshold, and average all the stopping points.
Use LGB to predict relative position. It can help the baseline when the loss function is soft_L1 loss. But it can't help when it's Cauchy loss.
Go to RTKExplorer's blog, download the Demo5 User Manual Introduction.
Read the demo5 manual to understand the meaning and default values of each parameter specified in the open source RTK notebook from the manual.
Fine-tune each parameter around the default values in the manual and the parameter values in the open source code. The scores of RTK for the whole training set (excluding wrong paths) are calculated after each adjustment. We found that the CV and LB are inconsistent when tuning the parameters only on certain phones. But if run on the whole dataset, CV has the same boosting/decreasing trend as LB, although they are not consistent.
Ensemble the prediction of the best parameter on the training data, and several sub-optimal parameter
Using multiple reference stations for the rtk solution, and averaging the results
\nYou can get the score of each kind of phone on training data with this notebook. You can also search for the ensemble weight of two baselines at the end. This step is really important, as you can find that rtk is so good at dealing with GooglePixel5, Samsung, and Xiaomi, which are all the kinds of phones in PB. Especially for Google5 and Samsung, which are the most part in PB, RTK can reach a score of another level compared to the other baseline. You can also find that it is so bad on GooglePixel4, and GooglePixel4XL.
With a weight of 0.65:0.35 for RTK and taro's public baseline(modified by us), we can reach our highest LB rank, which also ranks 11 on LB.
But given that GooglePixel5 and Samsung take the most part of PB, we expect a huge shake on PB. Since RTK plays really well on training sets for GooglePixel5 and Samsung. We decided to give it a much higher weight for PB. In the end, we used a weight of 0.8: 0.2 to get 11th place on PB.
There are some obvious outliers in the public RTK baseline(python). We simply replace them with the points of taro's baseline.
\n
\n
Even if an RTK submission scores 2.4(Red) in LB, there will be some strange points. We also replace with taro's public baseline(blue).
\n![\"FtvBd.md.png\"](\"https://s1.328888.xyz/2022/08/01/FtvBd.md.png\")
We use the code in rob's notebook to predict whether it's stopping, and average all of the stopping points.
\nWe noticed that even after ensemble, there are some noisy stopping points. So we used that code to average them.
\n![\"FyVHF.md.png\"](\"https://s1.328888.xyz/2022/08/01/FyVHF.md.png\")
\n![\"FyIIo.md.png\"](\"https://s1.328888.xyz/2022/08/01/FyIIo.md.png\")
But we don't think treating them as the same point is a good idea. When we are driving on our own and need to brake, we cannot suddenly slow down from 100 mph to 0 mph. Usually we gradually decelerate to 0 over a period of a few seconds. So in the end, I average the stop mean and the original predictions. We call it 'rolling stop mean'.
\n![\"Fygvy.md.png\"](\"https://s1.328888.xyz/2022/08/01/Fygvy.md.png\")
\n![\"FyUwC.md.png\"](\"https://s1.328888.xyz/2022/08/01/FyUwC.md.png\")
First of all, thanks to the organizers and Kaggle for organizing this unique challenge. We would also thank the other participants. It's the competition that makes things more interesting. Thanks to my teammates @linwei9, @chris62, @gmhost, and @rytisva88. It's team work that won us a gold medal.
\nOur solution is an ensemble of RTK and taro's public baseline. Thank you @timeverett @taroz1461 for your great contribution. These two codes help newbies like me to get started with GNSS positioning quickly. But since we didn't end up making too much improvement to the taro's public baseline, RTK played the most part in our final solution.
\nSwitch the Loss function of WSL of position estimation and velocity estimation from soft_L1 loss to Cauchy loss.
Optimize the parameters of Kalman filter on phone-wise with Optuna. It helped LB, but not really helped pb.
Predict whether the car is stopping with a threshold, and average all the stopping points.
Use LGB to predict relative position. It can help the baseline when the loss function is soft_L1 loss. But it can't help when it's Cauchy loss.
Go to RTKExplorer's blog, download the Demo5 User Manual Introduction.
Read the demo5 manual to understand the meaning and default values of each parameter specified in the open source RTK notebook from the manual.
Fine-tune each parameter around the default values in the manual and the parameter values in the open source code. The scores of RTK for the whole training set (excluding wrong paths) are calculated after each adjustment. We found that the CV and LB are inconsistent when tuning the parameters only on certain phones. But if run on the whole dataset, CV has the same boosting/decreasing trend as LB, although they are not consistent.
Ensemble the prediction of the best parameter on the training data, and several sub-optimal parameter
Using multiple reference stations for the rtk solution, and averaging the results
\nYou can get the score of each kind of phone on training data with this notebook. You can also search for the ensemble weight of two baselines at the end. This step is really important, as you can find that rtk is so good at dealing with GooglePixel5, Samsung, and Xiaomi, which are all the kinds of phones in PB. Especially for Google5 and Samsung, which are the most part in PB, RTK can reach a score of another level compared to the other baseline. You can also find that it is so bad on GooglePixel4, and GooglePixel4XL.
With a weight of 0.65:0.35 for RTK and taro's public baseline(modified by us), we can reach our highest LB rank, which also ranks 11 on LB.
But given that GooglePixel5 and Samsung take the most part of PB, we expect a huge shake on PB. Since RTK plays really well on training sets for GooglePixel5 and Samsung. We decided to give it a much higher weight for PB. In the end, we used a weight of 0.8: 0.2 to get 11th place on PB.
There are some obvious outliers in the public RTK baseline(python). We simply replace them with the points of taro's baseline.
\n
\n
Even if an RTK submission scores 2.4(Red) in LB, there will be some strange points. We also replace with taro's public baseline(blue).
\n
We use the code in rob's notebook to predict whether it's stopping, and average all of the stopping points.
\nWe noticed that even after ensemble, there are some noisy stopping points. So we used that code to average them.
\n
\n
But we don't think treating them as the same point is a good idea. When we are driving on our own and need to brake, we cannot suddenly slow down from 100 mph to 0 mph. Usually we gradually decelerate to 0 over a period of a few seconds. So in the end, I average the stop mean and the original predictions. We call it 'rolling stop mean'.
\n
\n
Let me say that this is a great post and discussion. I'm glad you guys were able to share your thoughts and process with the community.
\nThe Devastator.
", "rawMarkdown": "Let me say that this is a great post and discussion. I'm glad you guys were able to share your thoughts and process with the community.\n\nThe Devastator.", "votes": null } ], "comments": [ { "id": 1888792, "author_name": "thedevastator", "author_url": "", "post_date": "08/07/2022 19:23:48", "content": "Let me say that this is a great post and discussion. I'm glad you guys were able to share your thoughts and process with the community.
\nThe Devastator.
", "votes": null, "replies": [] } ], "raw_markdown_by_id": { "1879611": "First of all, thanks to the organizers and Kaggle for organizing this unique challenge. We would also thank the other participants. It's the competition that makes things more interesting. Thanks to my teammates @linwei9, @chris62, @gmhost, and @rytisva88. It's team work that won us a gold medal.\n\nOur solution is an ensemble of [RTK](https://www.kaggle.com/code/timeverett/getting-started-with-rtklib) and [taro's public baseline](https://www.kaggle.com/code/taroz1461/carrier-smoothing-robust-wls-kalman-smoother). Thank you @timeverett @taroz1461 for your great contribution. These two codes help newbies like me to get started with GNSS positioning quickly. But since we didn't end up making too much improvement to the taro's public baseline, RTK played the most part in our final solution.\n\n## Modification to Taro's public baseline\n1. Switch the Loss function of WSL of position estimation and velocity estimation from `soft_L1` loss to `Cauchy` loss. \n\n2. Optimize the parameters of Kalman filter on phone-wise with Optuna. It helped LB, but not really helped pb.\n\n3. Predict whether the car is stopping with a threshold, and average all the stopping points.\n\n4. Use LGB to predict relative position. It can help the baseline when the loss function is `soft_L1` loss. But it can't help when it's Cauchy loss.\n\n## Modification to RTK's baseline\n\n### Tuning the parameters\n\n1. Go to [RTKExplorer's blog](https://rtklibexplorer.wordpress.com/resources/), download the Demo5 User Manual Introduction.\n\n2. Read the demo5 manual to understand the meaning and default values of each parameter specified in the open source RTK notebook from the manual.\n\n3. Fine-tune each parameter around the default values in the manual and the parameter values in the open source code. The scores of RTK for the whole training set (excluding wrong paths) are calculated after each adjustment. We found that the CV and LB are inconsistent when tuning the parameters only on certain phones. But if run on the whole dataset, CV has the same boosting/decreasing trend as LB, although they are not consistent.\n\n4. Ensemble the prediction of the best parameter on the training data, and several sub-optimal parameter\n\n### Adding Reference Station\nUsing multiple reference stations for the rtk solution, and averaging the results\n\n## Ensemble \n### Calculate the score of each kind of phone! \n1. You can get the score of each kind of phone on training data with [this notebook](https://www.kaggle.com/forcewithme/gsdc2022-get-the-score-on-training-set). You can also search for the ensemble weight of two baselines at the end. This step is really important, as you can find that **rtk is so good at dealing with GooglePixel5, Samsung, and Xiaomi**, which are all the kinds of phones in PB. Especially for Google5 and Samsung, which are the most part in PB, RTK can reach a score of another level compared to the other baseline. You can also find that it is so bad on GooglePixel4, and GooglePixel4XL. \n\n2. With a weight of 0.65:0.35 for RTK and taro's public baseline(modified by us), we can reach our highest LB rank, which also ranks 11 on LB.\n\n3. But given that GooglePixel5 and Samsung take the most part of PB, we expect a huge shake on PB. Since RTK plays really well on training sets for GooglePixel5 and Samsung. We decided to give it a much higher weight for PB. In the end, we used a weight of 0.8: 0.2 to get 11th place on PB.\n\n### Post Processing\n1. Replace the outliers of RTK. \n\nThere are some obvious outliers in the public RTK baseline(python). We simply replace them with the points of taro's baseline. \n[](https://imgloc.com/i/Ft1PB)\n[](https://imgloc.com/i/FtKuP)\n\nEven if an RTK submission scores 2.4(Red) in LB, there will be some strange points. We also replace with taro's public baseline(blue).\n[](https://imgloc.com/i/FtvBd)\n\n2. Average the stopping points.\n\nWe use the code in [rob's notebook](https://www.kaggle.com/code/robikscube/smartphone-competition-2022-twitch-stream) to predict whether it's stopping, and average all of the stopping points.\nWe noticed that even after ensemble, there are some noisy stopping points. So we used that code to average them.\n[](https://imgloc.com/i/FyVHF)\n[](https://imgloc.com/i/FyIIo)\n\nBut we don't think treating them as the same point is a good idea. When we are driving on our own and need to brake, we cannot suddenly slow down from 100 mph to 0 mph. Usually we gradually decelerate to 0 over a period of a few seconds. So in the end, I average the stop mean and the original predictions. We call it 'rolling stop mean'.\n\n[](https://imgloc.com/i/Fygvy)\n[](https://imgloc.com/i/FyUwC)", "1888792": "Let me say that this is a great post and discussion. I'm glad you guys were able to share your thoughts and process with the community.\n\nThe Devastator." }, "source": "meta" }