How are you approaching this competition?
\nI would like to discuss this post again before closing.
\nhttps://www.kaggle.com/competitions/smartphone-decimeter-2022/discussion/323548
I am trying to improve on this notebook as a base.
\nhttps://www.kaggle.com/code/taroz1461/carrier-smoothing-robust-wls-kalman-smoother
\n\nthere is a lot of room for improvement!
\n
I have above comments , but I don't understand the policy.
\nI tried to utilize imu before applying last year's method, but it did not work. I believe the reason is that the noise in the data is too noisy compared to GNSS and Doppler velocity.
\nHowever, if we can take advantage of imu's advantage of high frequency, it may lead to improvement.
Here are the results of last year's method.
\nDo you use RTKlib ?
\nI would be happy if you could share your approaches .
How are you approaching this competition?
\nI would like to discuss this post again before closing.
\nhttps://www.kaggle.com/competitions/smartphone-decimeter-2022/discussion/323548
I am trying to improve on this notebook as a base.
\nhttps://www.kaggle.com/code/taroz1461/carrier-smoothing-robust-wls-kalman-smoother
\n\nthere is a lot of room for improvement!
\n
I have above comments , but I don't understand the policy.
\nI tried to utilize imu before applying last year's method, but it did not work. I believe the reason is that the noise in the data is too noisy compared to GNSS and Doppler velocity.
\nHowever, if we can take advantage of imu's advantage of high frequency, it may lead to improvement.
Here are the results of last year's method.
\nDo you use RTKlib ?
\nI would be happy if you could share your approaches .
@tyonemoto - thanks for posting. Obviously the discussion forums of Kaggle competitions need to strike a balance between sharing of interesting ideas and not giving too much away.
\nThere are a lot of teams 0 to 50 cm ahead of you, and a similar distance ahead of the best public notebooks. Some of that improvement will have come from reducing the error in what I think of as the basic predictions, but a significant part is likely to have come from postprocessing.
\nYou have already mentioned some possible postprocessing approaches in your post - have you succeeded in implementing these? I'm not sure if by \"results of last year's method\" you mean reports from that competition, or your results from using these methods now.
\nI think the situation with snap-to-grid is somewhat nuanced. It can be made to work in some contexts, but applying it naively risks making good predictions worse. Beware snapping to the wrong lane or even the wrong road. Note that phone mean can't work in this competition as there is only one active phone in the car for each test run.
\nPersonally, I've seen useful improvements from two separate postprocessing methods.
\nGood luck with your implementations!
", "rawMarkdown": "tyonemoto - thanks for posting. Obviously the discussion forums of Kaggle competitions need to strike a balance between sharing of interesting ideas and not giving too much away.\n\nThere are a lot of teams 0 to 50 cm ahead of you, and a similar distance ahead of the best public notebooks. Some of that improvement will have come from reducing the error in what I think of as the basic predictions, but a significant part is likely to have come from postprocessing.\n\nYou have already mentioned some possible postprocessing approaches in your post - have you succeeded in implementing these? I'm not sure if by \"results of last year's method\" you mean reports from that competition, or your results from using these methods now. \n\nI think the situation with snap-to-grid is somewhat nuanced. It can be made to work in some contexts, but applying it naively risks making good predictions worse. Beware snapping to the wrong lane or even the wrong road. Note that phone mean can't work in this competition as there is only one active phone in the car for each test run.\n\nPersonally, I've seen useful improvements from two separate postprocessing methods.\n\nGood luck with your implementations!", "votes": null }, { "id": "1850158", "postDate": "07/10/2022 06:52:20", "content": "@tyonemoto
\nI think the biggest potential improvement is to estimate the velocity directly from the Accumulated Delta Range (ADR). I believe that the top solutions in last year's competition all used ADR to estimate the velocity. My public code uses ADR for carrier smoothing, but not directly for velocity estimation. I think it would also work to correct the pseudorange bias using the reference station observations, as the RTKLIB-based method uses. I hope this helps.
I have estimated the velocity directly from ADR. But it only improved a little using Kalman filter.
", "rawMarkdown": "I have estimated the velocity directly from ADR. But it only improved a little using Kalman filter.", "votes": null }, { "id": "1850431", "postDate": "07/10/2022 11:57:40", "content": "I saw the topic \"Some ground truths are wrong\". I will test it after update.
", "rawMarkdown": "I saw the topic \"Some ground truths are wrong\". I will test it after update.", "votes": null } ], "comments": [ { "id": 1848035, "author_name": "jbomitchell", "author_url": "", "post_date": "07/08/2022 10:04:34", "content": "@tyonemoto - thanks for posting. Obviously the discussion forums of Kaggle competitions need to strike a balance between sharing of interesting ideas and not giving too much away.
\nThere are a lot of teams 0 to 50 cm ahead of you, and a similar distance ahead of the best public notebooks. Some of that improvement will have come from reducing the error in what I think of as the basic predictions, but a significant part is likely to have come from postprocessing.
\nYou have already mentioned some possible postprocessing approaches in your post - have you succeeded in implementing these? I'm not sure if by \"results of last year's method\" you mean reports from that competition, or your results from using these methods now.
\nI think the situation with snap-to-grid is somewhat nuanced. It can be made to work in some contexts, but applying it naively risks making good predictions worse. Beware snapping to the wrong lane or even the wrong road. Note that phone mean can't work in this competition as there is only one active phone in the car for each test run.
\nPersonally, I've seen useful improvements from two separate postprocessing methods.
\nGood luck with your implementations!
", "votes": null, "replies": [] }, { "id": 1850158, "author_name": "taroz1461", "author_url": "", "post_date": "07/10/2022 06:52:20", "content": "@tyonemoto
\nI think the biggest potential improvement is to estimate the velocity directly from the Accumulated Delta Range (ADR). I believe that the top solutions in last year's competition all used ADR to estimate the velocity. My public code uses ADR for carrier smoothing, but not directly for velocity estimation. I think it would also work to correct the pseudorange bias using the reference station observations, as the RTKLIB-based method uses. I hope this helps.
I have estimated the velocity directly from ADR. But it only improved a little using Kalman filter.
", "votes": null, "replies": [] }, { "id": 1850431, "author_name": "yanbing06", "author_url": "", "post_date": "07/10/2022 11:57:40", "content": "I saw the topic \"Some ground truths are wrong\". I will test it after update.
", "votes": null, "replies": [] } ] } ], "raw_markdown_by_id": { "1847676": "How are you approaching this competition?\n\nI would like to discuss this post again before closing.\nhttps://www.kaggle.com/competitions/smartphone-decimeter-2022/discussion/323548\n\nI am trying to improve on this notebook as a base.\nhttps://www.kaggle.com/code/taroz1461/carrier-smoothing-robust-wls-kalman-smoother\n> there is a lot of room for improvement!\n\nI have above comments , but I don't understand the policy.\n\nI tried to utilize imu before applying last year's method, but it did not work. I believe the reason is that the noise in the data is too noisy compared to GNSS and Doppler velocity.\nHowever, if we can take advantage of imu's advantage of high frequency, it may lead to improvement.\n\nHere are the results of last year's method.\n\n# Improvement\n1. Bias correction\n1. Stop prediction and averaging\n\n# No improvement\n1. snap to grid\n1. phone mean\n1. imu(angular velocity) + ukf\nI tried to improve the score by using imu angular velocity and extended Kalman filter on the base notebook but it did not work (public notebook)\n1. imu (acceleration) + kf\nI also tried to improve the score from imu acceleration and Kalman filter but it did not work.\n\nDo you use RTKlib ?\nI would be happy if you could share your approaches .", "1848035": "tyonemoto - thanks for posting. Obviously the discussion forums of Kaggle competitions need to strike a balance between sharing of interesting ideas and not giving too much away.\n\nThere are a lot of teams 0 to 50 cm ahead of you, and a similar distance ahead of the best public notebooks. Some of that improvement will have come from reducing the error in what I think of as the basic predictions, but a significant part is likely to have come from postprocessing.\n\nYou have already mentioned some possible postprocessing approaches in your post - have you succeeded in implementing these? I'm not sure if by \"results of last year's method\" you mean reports from that competition, or your results from using these methods now. \n\nI think the situation with snap-to-grid is somewhat nuanced. It can be made to work in some contexts, but applying it naively risks making good predictions worse. Beware snapping to the wrong lane or even the wrong road. Note that phone mean can't work in this competition as there is only one active phone in the car for each test run.\n\nPersonally, I've seen useful improvements from two separate postprocessing methods.\n\nGood luck with your implementations!", "1850158": "tyonemoto\nI think the biggest potential improvement is to estimate the velocity directly from the Accumulated Delta Range (ADR). I believe that the top solutions in last year's competition all used ADR to estimate the velocity. My public code uses ADR for carrier smoothing, but not directly for velocity estimation. I think it would also work to correct the pseudorange bias using the reference station observations, as the RTKLIB-based method uses. I hope this helps.", "1850238": "I have estimated the velocity directly from ADR. But it only improved a little using Kalman filter.", "1850431": "I saw the topic \"Some ground truths are wrong\". I will test it after update." }, "source": "meta" }