\n
![\"fig1\"](\"https://user-images.githubusercontent.com/7933764/182075782-be8d5e1c-992b-4b5f-8c69-5426bb6cf222.png\")
I am very happy to have won first place in this competition again. I am a researcher in the GNSS and robotics fields, but last year's competition was very inspiring, with many different people working on ideas that I would never have thought of. I would be very happy if you could also share your solutions and ideas.
\nSmartphone's GNSS observations are very noisy, and the output data has many missing and abnormal values, making it very difficult to estimate positions accurately. I also had difficulty dealing with the differences in observations for different types of smartphones. There were a lot of details to deal with and a lot to do, and I think this competition was unusual and tough for many of us.
\nThe basic idea of my solution is the same as last year's: global optimization of position and velocity using pseudorange, pseudorange rate (Doppler), and ADR (carrier phase) by Factor Graph Optimization (FGO). For more on FGO, see last year's solution. The key point of this year's method, which contributed to the accuracy, was to separate the velocity and position estimation and process them in two stages. The flow of the proposed method is shown in the following figure. It has a very simple structure.
\n
gnss_log.txt
GNSS observation data and satellite orbit data (broadcast ephemeris) of base station
\nAccurate relative position (velocity) can be calculated from ADR time differences, but availability is low because of vulnerability to signal shielding and frequent cycle slips. The velocity is estimated first using Doppler, which is more robust, and then outliers are removed, interpolated, and used as a loose constraint in the next stage of position estimation. At the same time, it can be used to determine that a vehicle is stopped. If velocity is included in the optimization at the same time as position, such interpolation and determination of the stop position become difficult. In the case of data with many missing outliers, elevations, tunnels, etc., it was very effective to estimate and correct the velocity at a separate stage.
\n![\"fig2\"](\"https://user-images.githubusercontent.com/7933764/182075787-50a13c78-2662-4729-b4ab-04af3d609e85.png\")
Position and receiver clock are estimated by optimizing a graph constructed using pseudorange corrected for bias components using a base station, ADR time difference, and the velocity estimated in the previous stage. For city driving data, where there are many pauses due to traffic signals, the observed pseudorange data at stops are eliminated from the velocity estimated in the previous stage. Between each state (position), the estimated velocity is used to constrain the relative position, and a highly accurate relative position constraint is added when ADR is valid. In addition, as an absolute position constraint, the pseudorange corrected by the base station is used. No post-processing is done and the position estimated by optimization is submitted as the final estimate.
\n![\"fig3\"](\"https://user-images.githubusercontent.com/7933764/182075795-f044b3cc-ed7f-493a-82d0-aea6fdbb7a73.png\")
As in the previous year, GTSAM were used. This time, we used a simple M-Estimator for robust optimization instead of Switchable Constraint, which we used last year. Switchable Constraint has the advantage of being able to visualize and tune the values of the weights, but it has the disadvantage of low convergence and processing time. Since the performance was almost the same, I used the M-Estimator with the Huber function, which is suitable for noisy smartphone GNSS observations because the weights are not completely zero. The processing time was about 30 minutes for the entire test data run, allowing for a lot of trial and error in a limited amount of time.
\nThe device_gnss.csv has missing pseudoranges, so it was more accurate to convert the pseudoranges from gnss_log.txt by myself.
As @saitodevel01 pointed out, there is a problem with Doppler timing misalignment in the XiaomiM8. Apparently, only the Doppler of the XiaomiM8 matches the Android system clock as well as the IMU, not the GPS clock. As noted in the discussion, the velocity was best estimated when an offset of 600 ms was added.
The SamsongGalaxyS20 and XiaomiMi8 differ significantly from the other phones in terms of pseudorange rate and ADR uncertainty provided by the phone. I used a satellite elevation angle-based error model instead of the uncertainty provided by the phone.
With respect to the interpolation method for the velocity, the Akima interpolation method was more accurate than using spline interpolation. Spline interpolation is not good for overshooting.
When the HardwareClockDiscontinuedCount flag changes, cycle slips occur, and ADRs become discontinuous. This occurs only in some runs on Pixel4/4XL. Under these circumstances, ADRs are rarely available.
Velocity estimation with accelerometer integration. I spent quite a bit of time, but as a result, I did not contribute to accuracy.
Estimation of M-estimator hyper parameter by learning. Tried learning and dynamically applying the appropriate Huber function parameters according to the residuals of the observations but could not go beyond tuning the fixed parameters individually for each run.
A method that optimizes the distance from each satellite individually. This would be so-called tightly coupled, which optimizes the distance and distance rate from each satellite instead of optimizing the position and velocity, but it did not work. I would like to try this as a research project because I feel it has potential.
It is regrettable that, as mentioned in this discussion, the mistake in the ground truth had no small impact on the competition. The host said that the test data was correct, but I doubt that the error can really be verified when lever arm offsets of several 10 cm are mixed in. This could be a big problem if we are competing with a difference of a few centimeters since the ground truth bias error directly affects the final leaderboard.
The issue of invalid ADR (carrier phase) data on some GooglePixel 4/4XL runs was honestly something that could not be addressed; I feel that decimeter accuracy cannot be achieved without ADR. In the test data, there were problems with the /2021-08-12-US-MTV-1/GooglePixel4 and /2022-04-25-US-OAK-2/GooglePixel4, but I think these runs should have been excluded from the test data.
I question the setup regarding the fact that the test data includes data that was run in a completely different region than the training data (e.g., runs of OAK and all runs of LAX). If machine learning is to be used in the solution, I believe that at least data that was run in the same region as the training data should have been provided.
After the competition, I noticed that the coordinates of the base station had an offset… After correcting the offset, I made a late submission and got Public: 1.372, Private: 1.197. This is the best score so far.
\n![\"fig4\"](\"https://user-images.githubusercontent.com/7933764/182088010-f608223c-acc5-412f-a0cc-ead5013663f5.png\")
If a similar competition is held next year, I am not sure if I will participate. I don't want to look at the GNSS logs on a smartphone for at least a while!
I am very happy to have won first place in this competition again. I am a researcher in the GNSS and robotics fields, but last year's competition was very inspiring, with many different people working on ideas that I would never have thought of. I would be very happy if you could also share your solutions and ideas.
\nSmartphone's GNSS observations are very noisy, and the output data has many missing and abnormal values, making it very difficult to estimate positions accurately. I also had difficulty dealing with the differences in observations for different types of smartphones. There were a lot of details to deal with and a lot to do, and I think this competition was unusual and tough for many of us.
\nThe basic idea of my solution is the same as last year's: global optimization of position and velocity using pseudorange, pseudorange rate (Doppler), and ADR (carrier phase) by Factor Graph Optimization (FGO). For more on FGO, see last year's solution. The key point of this year's method, which contributed to the accuracy, was to separate the velocity and position estimation and process them in two stages. The flow of the proposed method is shown in the following figure. It has a very simple structure.
\n
gnss_log.txt
GNSS observation data and satellite orbit data (broadcast ephemeris) of base station
\nAccurate relative position (velocity) can be calculated from ADR time differences, but availability is low because of vulnerability to signal shielding and frequent cycle slips. The velocity is estimated first using Doppler, which is more robust, and then outliers are removed, interpolated, and used as a loose constraint in the next stage of position estimation. At the same time, it can be used to determine that a vehicle is stopped. If velocity is included in the optimization at the same time as position, such interpolation and determination of the stop position become difficult. In the case of data with many missing outliers, elevations, tunnels, etc., it was very effective to estimate and correct the velocity at a separate stage.
\n
Position and receiver clock are estimated by optimizing a graph constructed using pseudorange corrected for bias components using a base station, ADR time difference, and the velocity estimated in the previous stage. For city driving data, where there are many pauses due to traffic signals, the observed pseudorange data at stops are eliminated from the velocity estimated in the previous stage. Between each state (position), the estimated velocity is used to constrain the relative position, and a highly accurate relative position constraint is added when ADR is valid. In addition, as an absolute position constraint, the pseudorange corrected by the base station is used. No post-processing is done and the position estimated by optimization is submitted as the final estimate.
\n
As in the previous year, GTSAM were used. This time, we used a simple M-Estimator for robust optimization instead of Switchable Constraint, which we used last year. Switchable Constraint has the advantage of being able to visualize and tune the values of the weights, but it has the disadvantage of low convergence and processing time. Since the performance was almost the same, I used the M-Estimator with the Huber function, which is suitable for noisy smartphone GNSS observations because the weights are not completely zero. The processing time was about 30 minutes for the entire test data run, allowing for a lot of trial and error in a limited amount of time.
\nThe device_gnss.csv has missing pseudoranges, so it was more accurate to convert the pseudoranges from gnss_log.txt by myself.
As @saitodevel01 pointed out, there is a problem with Doppler timing misalignment in the XiaomiM8. Apparently, only the Doppler of the XiaomiM8 matches the Android system clock as well as the IMU, not the GPS clock. As noted in the discussion, the velocity was best estimated when an offset of 600 ms was added.
The SamsongGalaxyS20 and XiaomiMi8 differ significantly from the other phones in terms of pseudorange rate and ADR uncertainty provided by the phone. I used a satellite elevation angle-based error model instead of the uncertainty provided by the phone.
With respect to the interpolation method for the velocity, the Akima interpolation method was more accurate than using spline interpolation. Spline interpolation is not good for overshooting.
When the HardwareClockDiscontinuedCount flag changes, cycle slips occur, and ADRs become discontinuous. This occurs only in some runs on Pixel4/4XL. Under these circumstances, ADRs are rarely available.
Velocity estimation with accelerometer integration. I spent quite a bit of time, but as a result, I did not contribute to accuracy.
Estimation of M-estimator hyper parameter by learning. Tried learning and dynamically applying the appropriate Huber function parameters according to the residuals of the observations but could not go beyond tuning the fixed parameters individually for each run.
A method that optimizes the distance from each satellite individually. This would be so-called tightly coupled, which optimizes the distance and distance rate from each satellite instead of optimizing the position and velocity, but it did not work. I would like to try this as a research project because I feel it has potential.
It is regrettable that, as mentioned in this discussion, the mistake in the ground truth had no small impact on the competition. The host said that the test data was correct, but I doubt that the error can really be verified when lever arm offsets of several 10 cm are mixed in. This could be a big problem if we are competing with a difference of a few centimeters since the ground truth bias error directly affects the final leaderboard.
The issue of invalid ADR (carrier phase) data on some GooglePixel 4/4XL runs was honestly something that could not be addressed; I feel that decimeter accuracy cannot be achieved without ADR. In the test data, there were problems with the /2021-08-12-US-MTV-1/GooglePixel4 and /2022-04-25-US-OAK-2/GooglePixel4, but I think these runs should have been excluded from the test data.
I question the setup regarding the fact that the test data includes data that was run in a completely different region than the training data (e.g., runs of OAK and all runs of LAX). If machine learning is to be used in the solution, I believe that at least data that was run in the same region as the training data should have been provided.
After the competition, I noticed that the coordinates of the base station had an offset… After correcting the offset, I made a late submission and got Public: 1.372, Private: 1.197. This is the best score so far.
\n
If a similar competition is held next year, I am not sure if I will participate. I don't want to look at the GNSS logs on a smartphone for at least a while!
Thank you for sharing the solution.
\nHowever, I think this solution alone does not seem to explain the large gap, especially for private LB. I believe the key to high accuracy is in the use of ADR. I found that ADR is relatively high accuracy, but still contains many outliers that may be due to undetected cycle slips and half cycle ambiguity. How does your \"ADR Factor\" address these issues?
The ADR observations were processed using the following procedure.
\n(1) exclude invalid ADRs from the AccumulatedDeltaRangeState
\n(2) exclude cycle slips of ADR from diff(ADR)-PseudorangeRate*dt
Note that (2) includes receiver clock jumps. (2) values are shown in the following figure. As a threshold, I used 1.5 m. When Doppler's accuracy is poor, ADR is almost never obtained, so this will eliminate a significant amount of cycle slips. Of course, this still leaves half-cycle slips and outliers. However, the M-estimator can almost eliminate the influence of these outliers.
\n![\"fig5\"](\"https://user-images.githubusercontent.com/7933764/182264555-a2fe4adf-65af-4047-9de5-5375025cd7df.png\")
This graph clearly shows that outliers remain.
\nAnd this method was included in your public notebook. I did not understand what the code meant.
Thank you very much. And congratulations on your two consecutive victories.
", "rawMarkdown": "This graph clearly shows that outliers remain.\nAnd this method was included in your public notebook. I did not understand what the code meant.\n\nThank you very much. And congratulations on your two consecutive victories.", "votes": 1 } ] }, { "id": 1883213, "postDate": "2022-08-03T16:50:54.200Z", "content": "Wow! Congratulations and thank you for sharing your thought process
", "rawMarkdown": "Wow! Congratulations and thank you for sharing your thought process", "votes": 1 }, { "id": 1882303, "postDate": "2022-08-03T07:38:51.157Z", "content": "I really like all the explanations and congrats on the results.
", "rawMarkdown": "I really like all the explanations and congrats on the results.", "votes": 1 }, { "id": 1882151, "postDate": "2022-08-03T05:17:11.557Z", "content": "Awesome writeup @taroz1461, thanks for sharing, however sad to read the last line, kindly do participate next year we need a hattrick from you :D
", "rawMarkdown": "Awesome writeup @taroz1461, thanks for sharing, however sad to read the last line, kindly do participate next year we need a hattrick from you :D", "votes": 1 }, { "id": 1881459, "postDate": "2022-08-02T14:23:43.473Z", "content": "I'm really curious about how you code the switchable constraints of GNSS. Is it possible to open source some of the code? Because the performance of the switchable constraint I implemented is far from that you implemented last year, sometimes there will be errors caused by local convergence.
\nAnd thank you again for your solution, which goes beyond my understanding of GNSS!
Congratulations on your excellent work.
\nI've got a question for you. I tried to build motion factors in my FGO framework, but did not work.How are velocity factor and motion factor constructed, and whether they correspond to the following error functions?
And how much should their measurement noise be set?
", "rawMarkdown": "Congratulations on your excellent work. \nI've got a question for you. I tried to build motion factors in my FGO framework, but did not work.How are velocity factor and motion factor constructed, and whether they correspond to the following error functions?\n\n\n- **e_vel=pos(k+1)-pos(k)-vel(k)*dt**，where pos is to be estimated, and vel has been estimated by Doppler/dAdr\n- **e_motion(1)=vel(k+1)-vel(k)-acc(k)*dt**\n- **e_motion(2)=acc(k+1)-acc(k)**\nAre both velocity and acceleration considered as states to be estimated here？\n\nAnd how much should their measurement noise be set?\n", "votes": 1 }, { "id": 1880905, "postDate": "2022-08-02T06:03:13.210Z", "content": "Excelent job, I really like all the explanation
", "rawMarkdown": "Excelent job, I really like all the explanation", "votes": 1 }, { "id": 1880681, "postDate": "2022-08-02T00:21:51.070Z", "content": "Wow! Congratulations and thank you for sharing your thought process
", "rawMarkdown": "Wow! Congratulations and thank you for sharing your thought process", "votes": 1 }, { "id": 1880553, "postDate": "2022-08-01T19:59:27.387Z", "content": "Great working method and congrats for the results!
", "rawMarkdown": "Great working method and congrats for the results! ", "votes": 1 }, { "id": 1880073, "postDate": "2022-08-01T12:52:52.677Z", "content": "Great work!
\nI think it is challenging to switch between Doppler speed and ADR speed. Because they are not necessarily consecutive.
", "rawMarkdown": "Great work! \n\nI think it is challenging to switch between Doppler speed and ADR speed. Because they are not necessarily consecutive.", "votes": 1 }, { "id": 1880052, "postDate": "2022-08-01T12:40:42.870Z", "content": "Cool! Thanks for sharing and for your public decision that helps me a lot
", "rawMarkdown": "Cool! Thanks for sharing and for your public decision that helps me a lot", "votes": 1 }, { "id": 1879865, "postDate": "2022-08-01T10:09:50.910Z", "content": "Taro @taroz1461, King of GSDC 🔥
", "rawMarkdown": "Taro @taroz1461, King of GSDC 🔥", "votes": 2 }, { "id": 2008574, "postDate": "2022-10-29T07:40:18.140Z", "content": "You won the first place in both last year and this year's competition, and both adopted the method of factor graph optimization; However, it is difficult for a novice to build a factor graph optimization project for this competition, so I would like to ask if you can share a factor graph optimization demo for a better understanding of your solution. Thank you very much if you can reply!
", "rawMarkdown": "You won the first place in both last year and this year's competition, and both adopted the method of factor graph optimization; However, it is difficult for a novice to build a factor graph optimization project for this competition, so I would like to ask if you can share a factor graph optimization demo for a better understanding of your solution. Thank you very much if you can reply!", "replies": [ { "id": 2008623, "postDate": "2022-10-29T08:08:37.383Z", "content": "", "rawMarkdown": "@taroz1461 ", "replies": [ { "id": 3020034, "postDate": "2024-10-17T05:30:40.590Z", "content": "😭+1😭+1😭+1
", "rawMarkdown": "😭+1😭+1😭+1" } ] } ] }, { "id": 1894951, "postDate": "2022-08-11T20:22:06.113Z", "content": "Great coding and great explanation. Great job.
", "rawMarkdown": "Great coding and great explanation. Great job." }, { "id": 1888802, "postDate": "2022-08-07T19:33:48.827Z", "content": "Congratulations!
\nA well deserved solution!
\nThe Devastator.
Congratulations! Thanks for sharing your ideas
", "rawMarkdown": "Congratulations! Thanks for sharing your ideas" }, { "id": 1883082, "postDate": "2022-08-03T15:29:22.370Z", "content": "Awesome….
", "rawMarkdown": "Awesome...." }, { "id": 1879830, "postDate": "2022-08-01T09:39:54.257Z", "rawMarkdown": "", "votes": 2, "isDeleted": true }, { "id": 1884710, "postDate": "2022-08-04T15:32:37.753Z", "content": "thanks and congrats!
", "rawMarkdown": "thanks and congrats!" } ], "comments": [ { "id": 1880407, "author_name": "Akio Saito", "author_url": "", "post_date": "2022-08-01T17:36:38.693000", "content": "Thank you for sharing the solution.
\nHowever, I think this solution alone does not seem to explain the large gap, especially for private LB. I believe the key to high accuracy is in the use of ADR. I found that ADR is relatively high accuracy, but still contains many outliers that may be due to undetected cycle slips and half cycle ambiguity. How does your \"ADR Factor\" address these issues?
The ADR observations were processed using the following procedure.
\n(1) exclude invalid ADRs from the AccumulatedDeltaRangeState
\n(2) exclude cycle slips of ADR from diff(ADR)-PseudorangeRate*dt
Note that (2) includes receiver clock jumps. (2) values are shown in the following figure. As a threshold, I used 1.5 m. When Doppler's accuracy is poor, ADR is almost never obtained, so this will eliminate a significant amount of cycle slips. Of course, this still leaves half-cycle slips and outliers. However, the M-estimator can almost eliminate the influence of these outliers.
\n
This graph clearly shows that outliers remain.
\nAnd this method was included in your public notebook. I did not understand what the code meant.
Thank you very much. And congratulations on your two consecutive victories.
", "votes": 1, "replies": [] } ] }, { "id": 1883213, "author_name": "whoami-anoint", "author_url": "", "post_date": "2022-08-03T16:50:54.200000", "content": "Wow! Congratulations and thank you for sharing your thought process
", "votes": 1, "replies": [] }, { "id": 1882303, "author_name": "Shadab Akhtar", "author_url": "", "post_date": "2022-08-03T07:38:51.157000", "content": "I really like all the explanations and congrats on the results.
", "votes": 1, "replies": [] }, { "id": 1882151, "author_name": "Old Monk", "author_url": "", "post_date": "2022-08-03T05:17:11.557000", "content": "Awesome writeup @taroz1461, thanks for sharing, however sad to read the last line, kindly do participate next year we need a hattrick from you :D
", "votes": 1, "replies": [] }, { "id": 1881459, "author_name": "Lcy", "author_url": "", "post_date": "2022-08-02T14:23:43.473000", "content": "I'm really curious about how you code the switchable constraints of GNSS. Is it possible to open source some of the code? Because the performance of the switchable constraint I implemented is far from that you implemented last year, sometimes there will be errors caused by local convergence.
\nAnd thank you again for your solution, which goes beyond my understanding of GNSS!
Congratulations on your excellent work.
\nI've got a question for you. I tried to build motion factors in my FGO framework, but did not work.How are velocity factor and motion factor constructed, and whether they correspond to the following error functions?
And how much should their measurement noise be set?
", "votes": 1, "replies": [] }, { "id": 1880905, "author_name": "Agustin222", "author_url": "", "post_date": "2022-08-02T06:03:13.210000", "content": "Excelent job, I really like all the explanation
", "votes": 1, "replies": [] }, { "id": 1880681, "author_name": "Will", "author_url": "", "post_date": "2022-08-02T00:21:51.070000", "content": "Wow! Congratulations and thank you for sharing your thought process
", "votes": 1, "replies": [] }, { "id": 1880553, "author_name": "Ravi Ramakrishnan", "author_url": "", "post_date": "2022-08-01T19:59:27.387000", "content": "Great working method and congrats for the results!
", "votes": 1, "replies": [] }, { "id": 1880073, "author_name": "Yanbing Zhang", "author_url": "", "post_date": "2022-08-01T12:52:52.677000", "content": "Great work!
\nI think it is challenging to switch between Doppler speed and ADR speed. Because they are not necessarily consecutive.
", "votes": 1, "replies": [] }, { "id": 1880052, "author_name": "Egor Borisov", "author_url": "", "post_date": "2022-08-01T12:40:42.870000", "content": "Cool! Thanks for sharing and for your public decision that helps me a lot
", "votes": 1, "replies": [] }, { "id": 1879865, "author_name": "ForcewithMe", "author_url": "", "post_date": "2022-08-01T10:09:50.910000", "content": "Taro @taroz1461, King of GSDC 🔥
", "votes": 2, "replies": [] }, { "id": 2008574, "author_name": "Beginnerrrrrr", "author_url": "", "post_date": "2022-10-29T07:40:18.140000", "content": "You won the first place in both last year and this year's competition, and both adopted the method of factor graph optimization; However, it is difficult for a novice to build a factor graph optimization project for this competition, so I would like to ask if you can share a factor graph optimization demo for a better understanding of your solution. Thank you very much if you can reply!
", "votes": 0, "replies": [ { "id": 2008623, "author_name": "Beginnerrrrrr", "author_url": "", "post_date": "2022-10-29T08:08:37.383000", "content": "", "votes": 0, "replies": [ { "id": 3020034, "author_name": "Mo Frank", "author_url": "", "post_date": "2024-10-17T05:30:40.590000", "content": "😭+1😭+1😭+1
", "votes": 0, "replies": [] } ] } ] }, { "id": 1894951, "author_name": "Gabriel Soares Arantes", "author_url": "", "post_date": "2022-08-11T20:22:06.113000", "content": "Great coding and great explanation. Great job.
", "votes": 0, "replies": [] }, { "id": 1888802, "author_name": "The Devastator", "author_url": "", "post_date": "2022-08-07T19:33:48.827000", "content": "Congratulations!
\nA well deserved solution!
\nThe Devastator.
Congratulations! Thanks for sharing your ideas
", "votes": 0, "replies": [] }, { "id": 1883082, "author_name": "MD. Arif Uz Zaman Badhon", "author_url": "", "post_date": "2022-08-03T15:29:22.370000", "content": "Awesome….
", "votes": 0, "replies": [] }, { "id": 1879830, "author_name": "", "author_url": "", "post_date": "2022-08-01T09:39:54.257000", "content": "", "votes": 2, "replies": [] }, { "id": 1884710, "author_name": "Omar ElSayed", "author_url": "", "post_date": "2022-08-04T15:32:37.753000", "content": "thanks and congrats!
", "votes": 0, "replies": [] } ], "raw_markdown_by_id": { "1879816": "I am very happy to have won first place in this competition again. I am a researcher in the GNSS and robotics fields, but last year's competition was very inspiring, with many different people working on ideas that I would never have thought of. I would be very happy if you could also share your solutions and ideas.\n\nSmartphone's GNSS observations are very noisy, and the output data has many missing and abnormal values, making it very difficult to estimate positions accurately. I also had difficulty dealing with the differences in observations for different types of smartphones. There were a lot of details to deal with and a lot to do, and I think this competition was unusual and tough for many of us.\n\n# Overview\nThe basic idea of my solution is the same as [last year's](https://www.kaggle.com/competitions/google-smartphone-decimeter-challenge/discussion/262406): global optimization of position and velocity using pseudorange, pseudorange rate (Doppler), and ADR (carrier phase) by Factor Graph Optimization (FGO). For more on FGO, see last year's solution. The key point of this year's method, which contributed to the accuracy, was to separate the velocity and position estimation and process them in two stages. The flow of the proposed method is shown in the following figure. It has a very simple structure.\n\n\n## Input\n- `gnss_log.txt`\n\n- GNSS observation data and satellite orbit data (broadcast ephemeris) of base station\n - For the GNSS base station, I used [NGS CORS](https://geodesy.noaa.gov/CORS/) data at 30-sec intervals. I used a single base station, but I thought @saitodevel01's method of the ensemble of multiple base station analysis results might contribute to accuracy. I should have tried it... \n\n# Velocity estimation stage\nAccurate relative position (velocity) can be calculated from ADR time differences, but availability is low because of vulnerability to signal shielding and frequent cycle slips. The velocity is estimated first using Doppler, which is more robust, and then outliers are removed, interpolated, and used as a loose constraint in the next stage of position estimation. At the same time, it can be used to determine that a vehicle is stopped. If velocity is included in the optimization at the same time as position, such interpolation and determination of the stop position become difficult. In the case of data with many missing outliers, elevations, tunnels, etc., it was very effective to estimate and correct the velocity at a separate stage.\n\n\n# Position estimation stage\nPosition and receiver clock are estimated by optimizing a graph constructed using pseudorange corrected for bias components using a base station, ADR time difference, and the velocity estimated in the previous stage. For city driving data, where there are many pauses due to traffic signals, the observed pseudorange data at stops are eliminated from the velocity estimated in the previous stage. Between each state (position), the estimated velocity is used to constrain the relative position, and a highly accurate relative position constraint is added when ADR is valid. In addition, as an absolute position constraint, the pseudorange corrected by the base station is used. No post-processing is done and the position estimated by optimization is submitted as the final estimate.\n\n\n# Optimization\nAs in the previous year, [GTSAM](https://github.com/borglab/gtsam) were used. This time, we used a simple M-Estimator for robust optimization instead of Switchable Constraint, which we used last year. Switchable Constraint has the advantage of being able to visualize and tune the values of the weights, but it has the disadvantage of low convergence and processing time. Since the performance was almost the same, I used the M-Estimator with the [Huber function](https://xipengwang.github.io/paper-reading-mixture-models-for-least-square-optimization/#Huber-Loss), which is suitable for noisy smartphone GNSS observations because the weights are not completely zero. The processing time was about 30 minutes for the entire test data run, allowing for a lot of trial and error in a limited amount of time.\n\n# Tips\n- The `device_gnss.csv` has missing pseudoranges, so it was more accurate to convert the pseudoranges from `gnss_log.txt` by myself.\n\n- As @saitodevel01 [pointed out](https://www.kaggle.com/competitions/smartphone-decimeter-2022/discussion/340692), there is a problem with Doppler timing misalignment in the XiaomiM8. Apparently, only the Doppler of the XiaomiM8 matches the Android system clock as well as the IMU, not the GPS clock. As noted in the [discussion](https://www.kaggle.com/competitions/smartphone-decimeter-2022/discussion/323135), the velocity was best estimated when an offset of 600 ms was added. \n\n- The SamsongGalaxyS20 and XiaomiMi8 differ significantly from the other phones in terms of pseudorange rate and ADR uncertainty provided by the phone. I used a satellite elevation angle-based error model instead of the uncertainty provided by the phone.\n\n- With respect to the interpolation method for the velocity, the [Akima](https://www.mathworks.com/help/matlab/ref/makima.html) interpolation method was more accurate than using spline interpolation. Spline interpolation is not good for overshooting.\n\n- When the `HardwareClockDiscontinuedCount` flag changes, cycle slips occur, and ADRs become discontinuous. This occurs only in some runs on Pixel4/4XL. Under these circumstances, ADRs are rarely available.\n\n# Ideas that were tried and did not work\n- Velocity estimation with accelerometer integration. I spent quite a bit of time, but as a result, I did not contribute to accuracy.\n\n- Estimation of M-estimator hyper parameter by learning. Tried learning and dynamically applying the appropriate Huber function parameters according to the residuals of the observations but could not go beyond tuning the fixed parameters individually for each run.\n\n- A method that optimizes the distance from each satellite individually. This would be so-called tightly coupled, which optimizes the distance and distance rate from each satellite instead of optimizing the position and velocity, but it did not work. I would like to try this as a research project because I feel it has potential.\n\n# Other views on the competition\n- It is regrettable that, as mentioned in [this discussion](https://www.kaggle.com/competitions/smartphone-decimeter-2022/discussion/337416), the mistake in the ground truth had no small impact on the competition. The host said that the test data was correct, but I doubt that the error can really be verified when lever arm offsets of several 10 cm are mixed in. This could be a big problem if we are competing with a difference of a few centimeters since the ground truth bias error directly affects the final leaderboard.\n\n- The issue of invalid ADR (carrier phase) data on some GooglePixel 4/4XL runs was honestly something that could not be addressed; I feel that decimeter accuracy cannot be achieved without ADR. In the test data, there were problems with the `/2021-08-12-US-MTV-1/GooglePixel4` and `/2022-04-25-US-OAK-2/GooglePixel4`, but I think these runs should have been excluded from the test data.\n\n- I question the setup regarding the fact that the test data includes data that was run in a completely different region than the training data (e.g., runs of OAK and all runs of LAX). If machine learning is to be used in the solution, I believe that at least data that was run in the same region as the training data should have been provided.\n\n- After the competition, I noticed that the coordinates of the base station had an offset... After correcting the offset, I made a late submission and got Public: 1.372, Private: 1.197. This is the best score so far.\n\n\n- If a similar competition is held next year, I am not sure if I will participate. I don't want to look at the GNSS logs on a smartphone for at least a while!\n", "1880407": "Thank you for sharing the solution.\nHowever, I think this solution alone does not seem to explain the large gap, especially for private LB. I believe the key to high accuracy is in the use of ADR. I found that ADR is relatively high accuracy, but still contains many outliers that may be due to undetected cycle slips and half cycle ambiguity. How does your \"ADR Factor\" address these issues?", "1883213": "Wow! Congratulations and thank you for sharing your thought process", "1882303": "I really like all the explanations and congrats on the results.", "1882151": "Awesome writeup @taroz1461, thanks for sharing, however sad to read the last line, kindly do participate next year we need a hattrick from you :D", "1881459": "I'm really curious about how you code the switchable constraints of GNSS. Is it possible to open source some of the code? Because the performance of the switchable constraint I implemented is far from that you implemented last year, sometimes there will be errors caused by local convergence.\nAnd thank you again for your solution, which goes beyond my understanding of GNSS!", "1881444": "Congratulations on your excellent work. \nI've got a question for you. I tried to build motion factors in my FGO framework, but did not work.How are velocity factor and motion factor constructed, and whether they correspond to the following error functions?\n\n\n- **e_vel=pos(k+1)-pos(k)-vel(k)*dt**，where pos is to be estimated, and vel has been estimated by Doppler/dAdr\n- **e_motion(1)=vel(k+1)-vel(k)-acc(k)*dt**\n- **e_motion(2)=acc(k+1)-acc(k)**\nAre both velocity and acceleration considered as states to be estimated here？\n\nAnd how much should their measurement noise be set?\n", "1880905": "Excelent job, I really like all the explanation", "1880681": "Wow! Congratulations and thank you for sharing your thought process", "1880553": "Great working method and congrats for the results! ", "1880073": "Great work! \n\nI think it is challenging to switch between Doppler speed and ADR speed. Because they are not necessarily consecutive.", "1880052": "Cool! Thanks for sharing and for your public decision that helps me a lot", "1879865": "Taro @taroz1461, King of GSDC 🔥", "2008574": "You won the first place in both last year and this year's competition, and both adopted the method of factor graph optimization; However, it is difficult for a novice to build a factor graph optimization project for this competition, so I would like to ask if you can share a factor graph optimization demo for a better understanding of your solution. Thank you very much if you can reply!", "1894951": "Great coding and great explanation. Great job.", "1888802": "Congratulations!\n\nA well deserved solution! \nThe Devastator.\n", "1883142": "Congratulations! Thanks for sharing your ideas", "1883082": "Awesome....", "1879830": "", "1884710": "thanks and congrats!" } }