{
  "id": 262406,
  "title": "1st place solution",
  "url": "/competitions/google-smartphone-decimeter-challenge/writeups/taro-1st-place-solution",
  "author_name": "",
  "post_date": "2021-08-06T15:34:38.433356300Z",
  "votes": 119,
  "comment_count": 32,
  "views": 0,
  "content": "<p>First, I would like to thank everyone involved in this competition. It has been a very enjoyable two months. </p>\n<p>Although I am a researcher in the GNSS field, this was the first time I worked with raw GNSS data from smartphones. The raw GNSS data from the smartphone was compared to commercial GNSS receivers used in drones and mobile robots, and I had the following impressions.</p>\n<ul>\n<li>Pseudorange is <strong>very noisy</strong>, and the quality of the GNSS observations is not good</li>\n<li>There are a lot of <strong>missing data</strong>, <strong>duplication</strong>, <strong>time jump</strong>, etc., and it is very complicated</li>\n</ul>\n<p>I realized that I was usually exposed to very clean GNSS data…This competition was very very tough because of the huge amount of courses and the variety of smartphones（and the long variable names…）. To be honest, I don't want to look at GNSS data on smartphones anymore!😐</p>\n<h1>Key Points for Solution</h1>\n<ul>\n<li>Global optimization of position and velocity by <strong>Factor Graph Optimization</strong> Technique</li>\n<li>Velocity constraint by <strong>accumulated delta range（ADR）</strong></li>\n<li>Absolute position constraint by <strong>differential pseudorange between a base station</strong></li>\n<li>No machine learning（or rather, it was not possible due to time limitations）</li>\n</ul>\n<h1>Input Data</h1>\n<ul>\n<li>Phone_Gnsslog.txt</li>\n<li>RINEX files of GNSS<a href=\"https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238579\" target=\"_blank\"> base station</a> (I used Verizon base station data from <a href=\"https://webscope.sandbox.yahoo.com/catalog.php?datatype=s&amp;did=88\" target=\"_blank\">here</a>）</li>\n<li>Ground Truth（Downtown area only）</li>\n</ul>\n<p>In the end, I did not use Phone_derived.csv. There were some missing data in Phone_derived.csv files. I calculated the satellite position and velocity directly from the RINEX navigation file. Baseline position and IMU data are also not used.</p>\n<h1>Factor Graph Optimization</h1>\n<blockquote>\n  <p>Factor graphs are a class of graphical models in which there are variables and factors. The variables represent unknown quantities in the problem, and the factors represent functions on subsets of the variables. Edges in the factor graph are always between factors and variables, and indicate that a particular factor depends on a particular variable.（from <a href=\"https://gtsam.org/2020/06/01/factor-graphs.html\" target=\"_blank\">here</a>）</p>\n</blockquote>\n<p>The core of my approach was to use a <strong>global optimization method</strong> based on <strong>Factor Graph</strong>. Several optimization methods have been used <a href=\"https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/261959\" target=\"_blank\">here</a> and <a href=\"https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/262074\" target=\"_blank\">here</a>, with good results. Factor graph optimization is a method that can apply a variety of complex nonlinear constraints and simultaneously optimize all state variables（the entire driving trajectory）. There are many outliers in the various constraints（edges in the graph）, but a robust optimization technique eliminates the need to manually set the outlier threshold parameters. For more information about factor graphs, see  <a href=\"https://gtsam.org/tutorials/intro.html\" target=\"_blank\">this page</a>.</p>\n<h1>Factor Graph Structure</h1>\n<p>I tried many different graph structures and finally performed Graph optimization using the following Factor graph.<br>\n<img src=\"https://user-images.githubusercontent.com/7933764/128525861-3b529b21-e5bb-49ca-8ca6-60229b4ade32.png\" alt=\"fgo\"></p>\n<p>The graph node\\(X_i\\) presents the state variable of different moments, and the edge connecting two nodes presents the error function \\(e(\\cdot)\\); each edge corresponds to a single observation \\(Z_i\\). In the graph, error function \\(e(\\cdot)\\) represents probabilistic constraints applied to the state at the specified time-step. Optimization factor graph can be written as follows.<br>\n<img src=\"https://user-images.githubusercontent.com/7933764/128522724-ad708687-61ec-4416-b622-c972b451a8a0.png\"></p>\n<p>Here, \\(\\Omega_i\\) is the information matrix（inverse of covariance matrix）which determines the accuracy of the observation \\(Z_i\\). We defined the following as nodes（estimated states）of the graph.<br>\n<img src=\"https://user-images.githubusercontent.com/7933764/128524196-b6843c78-dfe3-4850-88ed-9fada7becea2.png\"><br>\n<img src=\"https://user-images.githubusercontent.com/7933764/128524319-f1c6a8fe-0f7e-4417-b702-a9cf815aa466.png\"></p>\n<p>where \\(r\\) and \\(\\dot{r}\\) is 3D position/velocity in earth-centered earth-fixed（ECEF）coordinate. \\(t\\) and \\(\\dot{t}\\) represent the receive clock bias and drift in each GNSS signals.</p>\n<p>Here, \\(s\\) in the graph is a <a href=\"https://nikosuenderhauf.github.io/assets/papers/IROS12-switchableConstraints.pdf\" target=\"_blank\">switchable constraint</a>, which is a state that takes a variable between 0 and 1. The value of switchable constraint is estimated simultaneously by optimization. On the edge of an outlier, the switchable constraint is automatically optimized to 0 and acts like a weight for the observed value. The optimization problem can be described as follows.</p>\n<p><img src=\"https://user-images.githubusercontent.com/7933764/128525345-2cb74f7a-5a74-4fa4-8c30-1d73a0828ecf.png\"></p>\n<p>where the last term in the above equation is the anchor factor of the switch to prevent the switch state from going to all zeros. </p>\n<h3>Pseudorange Factor</h3>\n<p>In the Pseudorange Factor, the observation is the difference between the pseudorange and the reference station's pseudorange, which removes the all bias error component in GNSS measurements（excluding multipath errors）. Theoretically, the residuals of the single differenced pseudorange have a Gaussian distribution with zero mean value if receiver clock error is compensated. This single-difference pseudorange improves the absolute position accuracy. Using this differential GNSS technique, I did not need any bias correction for the final position.</p>\n<h3>Doppler/ADR Factor</h3>\n<p>The pseudorange rate（Doppler shift）of the smartphone was noisier than I expected. I think the use of ADR（see P21-P22 of <a href=\"https://www.euspa.europa.eu/simplecount_pdf/tracker?file=expo/1.1_frank_van_diggelen_-_google.pdf\" target=\"_blank\">this document</a>） led to a higher level of competition. The following figure shows the velocities calculated from Doppler and ADR, respectively, compared to the ground truth. Velocity from ADR is about <strong>5 cm/s</strong>! In terms of accuracy alone, ADR was clearly superior to Doppler shift. Although the ADR is super accurate, its availability is lower than Doppler shift due to cycle slip and half-cycle ambiguity problem, so the Doppler factor is used instead only when the ADR factor is not available.</p>\n<p><img src=\"https://user-images.githubusercontent.com/7933764/128528282-8383da71-dbed-4b11-b121-743bf3fbf839.png\" alt=\"adr\"></p>\n<h3>Motion Factor</h3>\n<p>The motion factor uses the estimated velocity and clock drift to add constraints between neighboring nodes. It simply adds a constraint so that the integral of the velocity and clock drift is equal to the difference between the neighboring states.</p>\n<h3>Pseudo-Position Factor</h3>\n<p>The pseudo-position factor was used only for the downtown area, and since the ground truth was traveling along the same path as the test data, the points on the ground truth path closest to the estimated trajectory were extracted and added to the graph as pseudo position constraints with appropriate covariance.</p>\n<h1>A Few Concerns</h1>\n<ul>\n<li><p>As you can see in this discussion, the CV and LB scores are not matched, as is the big difference between the public and private LB scores. Without machine learning, I don't think there would be much overfitting to public scores. I can't explain the difference in these scores.</p></li>\n<li><p>I have some doubts about the accuracy of Ground Truth. The ground truth is based on Novatel SPAN（I also have this sensor）, but the results are quite different depending on multipath situations and analysis parameters. I would like the organizer to release the ground truth of the test data for future evaluation. I would also like to know the variance of the estimated ground truth.</p></li>\n</ul>\n<h1>My Impressions</h1>\n<ul>\n<li><p>Too bad I failed the decimeter challenge. The best public score in all my submissions was 1.4 m. I failed to choose the final post… I am convinced that with a combination of different techniques, I can eventually break 1 m!😃</p></li>\n<li><p>Graph optimization was very powerful. It optimizes all variables at the same time under nonlinear constraints, so it performs much better than filtering methods such as KF. For the implementation, I used the <a href=\"https://github.com/borglab/gtsam\" target=\"_blank\">GTSAM</a>, which is C++ library, and has Matlab and Python wrapper.</p></li>\n<li><p>It's a shame that I couldn't incorporate machine learning, which I wanted to do at first. I'm enjoying reading the other team's solutions. Let's write a paper together.</p></li>\n<li><p>There was a considerable difference in the GNSS observations depending on the phone. In the end, I didn't use phone marge and estimated the trajectory of only the best phone for each run. My best smartphone is Samsung Galaxy S20 Ultra, which is very good at tracking the GNSS carrier phase. I love it😊</p></li>\n<li><p>The only thing I could trust was ADR. Thank you so much, ADR.</p></li>\n</ul>",
  "messages": [
    {
      "id": "1455510",
      "postDate": "08/06/2021 15:34:38",
      "content": "<p>First, I would like to thank everyone involved in this competition. It has been a very enjoyable two months. </p>\n<p>Although I am a researcher in the GNSS field, this was the first time I worked with raw GNSS data from smartphones. The raw GNSS data from the smartphone was compared to commercial GNSS receivers used in drones and mobile robots, and I had the following impressions.</p>\n<ul>\n<li>Pseudorange is <strong>very noisy</strong>, and the quality of the GNSS observations is not good</li>\n<li>There are a lot of <strong>missing data</strong>, <strong>duplication</strong>, <strong>time jump</strong>, etc., and it is very complicated</li>\n</ul>\n<p>I realized that I was usually exposed to very clean GNSS data…This competition was very very tough because of the huge amount of courses and the variety of smartphones（and the long variable names…）. To be honest, I don't want to look at GNSS data on smartphones anymore!😐</p>\n<h1>Key Points for Solution</h1>\n<ul>\n<li>Global optimization of position and velocity by <strong>Factor Graph Optimization</strong> Technique</li>\n<li>Velocity constraint by <strong>accumulated delta range（ADR）</strong></li>\n<li>Absolute position constraint by <strong>differential pseudorange between a base station</strong></li>\n<li>No machine learning（or rather, it was not possible due to time limitations）</li>\n</ul>\n<h1>Input Data</h1>\n<ul>\n<li>Phone_Gnsslog.txt</li>\n<li>RINEX files of GNSS<a href=\"https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238579\" target=\"_blank\"> base station</a> (I used Verizon base station data from <a href=\"https://webscope.sandbox.yahoo.com/catalog.php?datatype=s&amp;did=88\" target=\"_blank\">here</a>）</li>\n<li>Ground Truth（Downtown area only）</li>\n</ul>\n<p>In the end, I did not use Phone_derived.csv. There were some missing data in Phone_derived.csv files. I calculated the satellite position and velocity directly from the RINEX navigation file. Baseline position and IMU data are also not used.</p>\n<h1>Factor Graph Optimization</h1>\n<blockquote>\n  <p>Factor graphs are a class of graphical models in which there are variables and factors. The variables represent unknown quantities in the problem, and the factors represent functions on subsets of the variables. Edges in the factor graph are always between factors and variables, and indicate that a particular factor depends on a particular variable.（from <a href=\"https://gtsam.org/2020/06/01/factor-graphs.html\" target=\"_blank\">here</a>）</p>\n</blockquote>\n<p>The core of my approach was to use a <strong>global optimization method</strong> based on <strong>Factor Graph</strong>. Several optimization methods have been used <a href=\"https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/261959\" target=\"_blank\">here</a> and <a href=\"https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/262074\" target=\"_blank\">here</a>, with good results. Factor graph optimization is a method that can apply a variety of complex nonlinear constraints and simultaneously optimize all state variables（the entire driving trajectory）. There are many outliers in the various constraints（edges in the graph）, but a robust optimization technique eliminates the need to manually set the outlier threshold parameters. For more information about factor graphs, see  <a href=\"https://gtsam.org/tutorials/intro.html\" target=\"_blank\">this page</a>.</p>\n<h1>Factor Graph Structure</h1>\n<p>I tried many different graph structures and finally performed Graph optimization using the following Factor graph.<br>\n<img src=\"https://user-images.githubusercontent.com/7933764/128525861-3b529b21-e5bb-49ca-8ca6-60229b4ade32.png\" alt=\"fgo\"></p>\n<p>The graph node\\(X_i\\) presents the state variable of different moments, and the edge connecting two nodes presents the error function \\(e(\\cdot)\\); each edge corresponds to a single observation \\(Z_i\\). In the graph, error function \\(e(\\cdot)\\) represents probabilistic constraints applied to the state at the specified time-step. Optimization factor graph can be written as follows.<br>\n<img src=\"https://user-images.githubusercontent.com/7933764/128522724-ad708687-61ec-4416-b622-c972b451a8a0.png\"></p>\n<p>Here, \\(\\Omega_i\\) is the information matrix（inverse of covariance matrix）which determines the accuracy of the observation \\(Z_i\\). We defined the following as nodes（estimated states）of the graph.<br>\n<img src=\"https://user-images.githubusercontent.com/7933764/128524196-b6843c78-dfe3-4850-88ed-9fada7becea2.png\"><br>\n<img src=\"https://user-images.githubusercontent.com/7933764/128524319-f1c6a8fe-0f7e-4417-b702-a9cf815aa466.png\"></p>\n<p>where \\(r\\) and \\(\\dot{r}\\) is 3D position/velocity in earth-centered earth-fixed（ECEF）coordinate. \\(t\\) and \\(\\dot{t}\\) represent the receive clock bias and drift in each GNSS signals.</p>\n<p>Here, \\(s\\) in the graph is a <a href=\"https://nikosuenderhauf.github.io/assets/papers/IROS12-switchableConstraints.pdf\" target=\"_blank\">switchable constraint</a>, which is a state that takes a variable between 0 and 1. The value of switchable constraint is estimated simultaneously by optimization. On the edge of an outlier, the switchable constraint is automatically optimized to 0 and acts like a weight for the observed value. The optimization problem can be described as follows.</p>\n<p><img src=\"https://user-images.githubusercontent.com/7933764/128525345-2cb74f7a-5a74-4fa4-8c30-1d73a0828ecf.png\"></p>\n<p>where the last term in the above equation is the anchor factor of the switch to prevent the switch state from going to all zeros. </p>\n<h3>Pseudorange Factor</h3>\n<p>In the Pseudorange Factor, the observation is the difference between the pseudorange and the reference station's pseudorange, which removes the all bias error component in GNSS measurements（excluding multipath errors）. Theoretically, the residuals of the single differenced pseudorange have a Gaussian distribution with zero mean value if receiver clock error is compensated. This single-difference pseudorange improves the absolute position accuracy. Using this differential GNSS technique, I did not need any bias correction for the final position.</p>\n<h3>Doppler/ADR Factor</h3>\n<p>The pseudorange rate（Doppler shift）of the smartphone was noisier than I expected. I think the use of ADR（see P21-P22 of <a href=\"https://www.euspa.europa.eu/simplecount_pdf/tracker?file=expo/1.1_frank_van_diggelen_-_google.pdf\" target=\"_blank\">this document</a>） led to a higher level of competition. The following figure shows the velocities calculated from Doppler and ADR, respectively, compared to the ground truth. Velocity from ADR is about <strong>5 cm/s</strong>! In terms of accuracy alone, ADR was clearly superior to Doppler shift. Although the ADR is super accurate, its availability is lower than Doppler shift due to cycle slip and half-cycle ambiguity problem, so the Doppler factor is used instead only when the ADR factor is not available.</p>\n<p><img src=\"https://user-images.githubusercontent.com/7933764/128528282-8383da71-dbed-4b11-b121-743bf3fbf839.png\" alt=\"adr\"></p>\n<h3>Motion Factor</h3>\n<p>The motion factor uses the estimated velocity and clock drift to add constraints between neighboring nodes. It simply adds a constraint so that the integral of the velocity and clock drift is equal to the difference between the neighboring states.</p>\n<h3>Pseudo-Position Factor</h3>\n<p>The pseudo-position factor was used only for the downtown area, and since the ground truth was traveling along the same path as the test data, the points on the ground truth path closest to the estimated trajectory were extracted and added to the graph as pseudo position constraints with appropriate covariance.</p>\n<h1>A Few Concerns</h1>\n<ul>\n<li><p>As you can see in this discussion, the CV and LB scores are not matched, as is the big difference between the public and private LB scores. Without machine learning, I don't think there would be much overfitting to public scores. I can't explain the difference in these scores.</p></li>\n<li><p>I have some doubts about the accuracy of Ground Truth. The ground truth is based on Novatel SPAN（I also have this sensor）, but the results are quite different depending on multipath situations and analysis parameters. I would like the organizer to release the ground truth of the test data for future evaluation. I would also like to know the variance of the estimated ground truth.</p></li>\n</ul>\n<h1>My Impressions</h1>\n<ul>\n<li><p>Too bad I failed the decimeter challenge. The best public score in all my submissions was 1.4 m. I failed to choose the final post… I am convinced that with a combination of different techniques, I can eventually break 1 m!😃</p></li>\n<li><p>Graph optimization was very powerful. It optimizes all variables at the same time under nonlinear constraints, so it performs much better than filtering methods such as KF. For the implementation, I used the <a href=\"https://github.com/borglab/gtsam\" target=\"_blank\">GTSAM</a>, which is C++ library, and has Matlab and Python wrapper.</p></li>\n<li><p>It's a shame that I couldn't incorporate machine learning, which I wanted to do at first. I'm enjoying reading the other team's solutions. Let's write a paper together.</p></li>\n<li><p>There was a considerable difference in the GNSS observations depending on the phone. In the end, I didn't use phone marge and estimated the trajectory of only the best phone for each run. My best smartphone is Samsung Galaxy S20 Ultra, which is very good at tracking the GNSS carrier phase. I love it😊</p></li>\n<li><p>The only thing I could trust was ADR. Thank you so much, ADR.</p></li>\n</ul>",
      "rawMarkdown": "First, I would like to thank everyone involved in this competition. It has been a very enjoyable two months. \n\nAlthough I am a researcher in the GNSS field, this was the first time I worked with raw GNSS data from smartphones. The raw GNSS data from the smartphone was compared to commercial GNSS receivers used in drones and mobile robots, and I had the following impressions.\n\n- Pseudorange is **very noisy**, and the quality of the GNSS observations is not good\n- There are a lot of **missing data**, **duplication**, **time jump**, etc., and it is very complicated\n\nI realized that I was usually exposed to very clean GNSS data...This competition was very very tough because of the huge amount of courses and the variety of smartphones（and the long variable names...）. To be honest, I don't want to look at GNSS data on smartphones anymore!😐\n\n# Key Points for Solution\n- Global optimization of position and velocity by **Factor Graph Optimization** Technique\n- Velocity constraint by **accumulated delta range（ADR）**\n- Absolute position constraint by **differential pseudorange between a base station**\n- No machine learning（or rather, it was not possible due to time limitations）\n\n# Input Data\n- Phone_Gnsslog.txt\n- RINEX files of GNSS[ base station](https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238579) (I used Verizon base station data from [here](https://webscope.sandbox.yahoo.com/catalog.php?datatype=s&did=88)）\n- Ground Truth（Downtown area only）\n\nIn the end, I did not use Phone_derived.csv. There were some missing data in Phone_derived.csv files. I calculated the satellite position and velocity directly from the RINEX navigation file. Baseline position and IMU data are also not used.\n\n# Factor Graph Optimization\n> Factor graphs are a class of graphical models in which there are variables and factors. The variables represent unknown quantities in the problem, and the factors represent functions on subsets of the variables. Edges in the factor graph are always between factors and variables, and indicate that a particular factor depends on a particular variable.（from [here](https://gtsam.org/2020/06/01/factor-graphs.html)）\n\nThe core of my approach was to use a **global optimization method** based on **Factor Graph**. Several optimization methods have been used [here](https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/261959) and [here](https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/262074), with good results. Factor graph optimization is a method that can apply a variety of complex nonlinear constraints and simultaneously optimize all state variables（the entire driving trajectory）. There are many outliers in the various constraints（edges in the graph）, but a robust optimization technique eliminates the need to manually set the outlier threshold parameters. For more information about factor graphs, see  [this page](https://gtsam.org/tutorials/intro.html).\n\n# Factor Graph Structure\nI tried many different graph structures and finally performed Graph optimization using the following Factor graph.\n![fgo](https://user-images.githubusercontent.com/7933764/128525861-3b529b21-e5bb-49ca-8ca6-60229b4ade32.png)\n\nThe graph node\\\\(X_i\\\\) presents the state variable of different moments, and the edge connecting two nodes presents the error function \\\\(e(\\cdot)\\\\); each edge corresponds to a single observation \\\\(Z_i\\\\). In the graph, error function \\\\(e(\\cdot)\\\\) represents probabilistic constraints applied to the state at the specified time-step. Optimization factor graph can be written as follows.\n<img src=\"https://user-images.githubusercontent.com/7933764/128522724-ad708687-61ec-4416-b622-c972b451a8a0.png\" width=\"300\">\n\nHere, \\\\(\\Omega_i\\\\) is the information matrix（inverse of covariance matrix）which determines the accuracy of the observation \\\\(Z_i\\\\). We defined the following as nodes（estimated states）of the graph.\n<img src=\"https://user-images.githubusercontent.com/7933764/128524196-b6843c78-dfe3-4850-88ed-9fada7becea2.png\" width=\"100\">\n<img src=\"https://user-images.githubusercontent.com/7933764/128524319-f1c6a8fe-0f7e-4417-b702-a9cf815aa466.png\" width=\"400\">\n\nwhere \\\\(r\\\\) and \\\\(\\dot{r}\\\\) is 3D position/velocity in earth-centered earth-fixed（ECEF）coordinate. \\\\(t\\\\) and \\\\(\\dot{t}\\\\) represent the receive clock bias and drift in each GNSS signals.\n \nHere, \\\\(s\\\\) in the graph is a [switchable constraint](https://nikosuenderhauf.github.io/assets/papers/IROS12-switchableConstraints.pdf), which is a state that takes a variable between 0 and 1. The value of switchable constraint is estimated simultaneously by optimization. On the edge of an outlier, the switchable constraint is automatically optimized to 0 and acts like a weight for the observed value. The optimization problem can be described as follows.\n\n<img src=\"https://user-images.githubusercontent.com/7933764/128525345-2cb74f7a-5a74-4fa4-8c30-1d73a0828ecf.png\" width=\"400\">\n\nwhere the last term in the above equation is the anchor factor of the switch to prevent the switch state from going to all zeros. \n\n### Pseudorange Factor\nIn the Pseudorange Factor, the observation is the difference between the pseudorange and the reference station's pseudorange, which removes the all bias error component in GNSS measurements（excluding multipath errors）. Theoretically, the residuals of the single differenced pseudorange have a Gaussian distribution with zero mean value if receiver clock error is compensated. This single-difference pseudorange improves the absolute position accuracy. Using this differential GNSS technique, I did not need any bias correction for the final position.\n\n### Doppler/ADR Factor\nThe pseudorange rate（Doppler shift）of the smartphone was noisier than I expected. I think the use of ADR（see P21-P22 of [this document](https://www.euspa.europa.eu/simplecount_pdf/tracker?file=expo/1.1_frank_van_diggelen_-_google.pdf)） led to a higher level of competition. The following figure shows the velocities calculated from Doppler and ADR, respectively, compared to the ground truth. Velocity from ADR is about **5 cm/s**! In terms of accuracy alone, ADR was clearly superior to Doppler shift. Although the ADR is super accurate, its availability is lower than Doppler shift due to cycle slip and half-cycle ambiguity problem, so the Doppler factor is used instead only when the ADR factor is not available.\n\n![adr](https://user-images.githubusercontent.com/7933764/128528282-8383da71-dbed-4b11-b121-743bf3fbf839.png)\n\n### Motion Factor\nThe motion factor uses the estimated velocity and clock drift to add constraints between neighboring nodes. It simply adds a constraint so that the integral of the velocity and clock drift is equal to the difference between the neighboring states.\n\n### Pseudo-Position Factor\nThe pseudo-position factor was used only for the downtown area, and since the ground truth was traveling along the same path as the test data, the points on the ground truth path closest to the estimated trajectory were extracted and added to the graph as pseudo position constraints with appropriate covariance.\n\n# A Few Concerns\n- As you can see in this discussion, the CV and LB scores are not matched, as is the big difference between the public and private LB scores. Without machine learning, I don't think there would be much overfitting to public scores. I can't explain the difference in these scores.\n\n- I have some doubts about the accuracy of Ground Truth. The ground truth is based on Novatel SPAN（I also have this sensor）, but the results are quite different depending on multipath situations and analysis parameters. I would like the organizer to release the ground truth of the test data for future evaluation. I would also like to know the variance of the estimated ground truth.\n\n# My Impressions\n- Too bad I failed the decimeter challenge. The best public score in all my submissions was 1.4 m. I failed to choose the final post... I am convinced that with a combination of different techniques, I can eventually break 1 m!😃\n\n- Graph optimization was very powerful. It optimizes all variables at the same time under nonlinear constraints, so it performs much better than filtering methods such as KF. For the implementation, I used the [GTSAM](https://github.com/borglab/gtsam), which is C++ library, and has Matlab and Python wrapper.\n\n- It's a shame that I couldn't incorporate machine learning, which I wanted to do at first. I'm enjoying reading the other team's solutions. Let's write a paper together.\n\n- There was a considerable difference in the GNSS observations depending on the phone. In the end, I didn't use phone marge and estimated the trajectory of only the best phone for each run. My best smartphone is Samsung Galaxy S20 Ultra, which is very good at tracking the GNSS carrier phase. I love it😊\n\n- The only thing I could trust was ADR. Thank you so much, ADR.",
      "votes": null
    },
    {
      "id": "1456303",
      "postDate": "08/06/2021 21:15:11",
      "content": "<p>Wow, Congratulations</p>",
      "rawMarkdown": "Wow, Congratulations",
      "votes": null
    },
    {
      "id": "1456455",
      "postDate": "08/06/2021 23:13:02",
      "content": "<p>congratulations!</p>",
      "rawMarkdown": "congratulations!",
      "votes": null
    },
    {
      "id": "1456481",
      "postDate": "08/06/2021 23:43:11",
      "content": "<p>Congratulations on winning! We’ve enjoyed so much competing with you. </p>\n<p>I have some questions regarding the solution:</p>\n<ol>\n<li><p>Are there any specific reason why you did not use the IMU sensor data here?</p></li>\n<li><p>Did you incorporate any prior knowledge to estimate multipath satellite signals, such as a mask based on elevation angle, in the FGO? Or is it intended that the switchable constraints performs well enough to detect such signals?</p></li>\n</ol>",
      "rawMarkdown": "Congratulations on winning! We’ve enjoyed so much competing with you. \n\nI have some questions regarding the solution:\n\n1. Are there any specific reason why you did not use the IMU sensor data here?\n\n2. Did you incorporate any prior knowledge to estimate multipath satellite signals, such as a mask based on elevation angle, in the FGO? Or is it intended that the switchable constraints performs well enough to detect such signals?",
      "votes": null
    },
    {
      "id": "1456622",
      "postDate": "08/07/2021 02:53:26",
      "content": "<p>Congrats <a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> 🎉🎉</p>",
      "rawMarkdown": "Congrats @taroz1461 🎉🎉",
      "votes": null
    },
    {
      "id": "1456623",
      "postDate": "08/07/2021 02:54:16",
      "content": "<p>Thanks!</p>\n<blockquote>\n  <p>Are there any specific reason why you did not use the IMU sensor data here?</p>\n</blockquote>\n<p>The reason is that I simply did not have the time to do it, and in many environments where GNSS is available, the relative position can be estimated with sufficient accuracy from the carrier phase measurements (ADR). Another reason is that when I checked the IMU data, there was a considerable time jump… In my solution, only the 3D position/velocity was estimated, but I would like to try adding 3D attitude into the estimated state and using IMU observations.</p>\n<blockquote>\n  <p>Did you incorporate any prior knowledge to estimate multipath satellite signals, such as a mask based on elevation angle, in the FGO? Or is it intended that the switchable constraints performs well enough to detect such signals?</p>\n</blockquote>\n<p>The part of robust optimization using outlier-containing measurements was left to switchable constraint. This figure illustrates the switch values of each pseudorange finally estimated by the omitimizer in the MTV course. It can be seen that the weights of observations with large residuals due to multipath, etc., are automatically reduced.<br>\n<img src=\"https://user-images.githubusercontent.com/7933764/128584580-8b50cbb0-41fa-481c-a43d-ddcc195b222c.png\" alt=\"sw\"></p>",
      "rawMarkdown": "Thanks!\n\n> Are there any specific reason why you did not use the IMU sensor data here?\n\nThe reason is that I simply did not have the time to do it, and in many environments where GNSS is available, the relative position can be estimated with sufficient accuracy from the carrier phase measurements (ADR). Another reason is that when I checked the IMU data, there was a considerable time jump... In my solution, only the 3D position/velocity was estimated, but I would like to try adding 3D attitude into the estimated state and using IMU observations.\n\n> Did you incorporate any prior knowledge to estimate multipath satellite signals, such as a mask based on elevation angle, in the FGO? Or is it intended that the switchable constraints performs well enough to detect such signals?\n\nThe part of robust optimization using outlier-containing measurements was left to switchable constraint. This figure illustrates the switch values of each pseudorange finally estimated by the omitimizer in the MTV course. It can be seen that the weights of observations with large residuals due to multipath, etc., are automatically reduced.\n![sw](https://user-images.githubusercontent.com/7933764/128584580-8b50cbb0-41fa-481c-a43d-ddcc195b222c.png)",
      "votes": null
    },
    {
      "id": "1456661",
      "postDate": "08/07/2021 03:27:17",
      "content": "<p>Thank you for the quick and detailed response! It is quite surprising that the switching constraints contribute that well to the robustness towards outliers.</p>\n<p>One more question: How did you determine the parameters(I assume covariance matrices are the ones) in that optimization? And how tough was it to tune them up?</p>\n<p>I also tried an optimization-based approach similar to the one introduced in <a href=\"https://arxiv.org/pdf/2004.10572.pdf\" target=\"_blank\">this paper</a>, but I kept getting bad results, possibly due to the poor choice of covariances.</p>",
      "rawMarkdown": "Thank you for the quick and detailed response! It is quite surprising that the switching constraints contribute that well to the robustness towards outliers.\n\n\nOne more question: How did you determine the parameters(I assume covariance matrices are the ones) in that optimization? And how tough was it to tune them up?\n\nI also tried an optimization-based approach similar to the one introduced in [this paper](https://arxiv.org/pdf/2004.10572.pdf), but I kept getting bad results, possibly due to the poor choice of covariances.",
      "votes": null
    },
    {
      "id": "1456873",
      "postDate": "08/07/2021 06:07:22",
      "content": "<p>In the case of the pseudorange factor, the variance of the measurement is based on the provided pesudorange uncertainty. In practice, the variance is adjusted by multiplying the provided pseudorange uncertainty by a factor that depends on the type of satellite signal.</p>\n<p>In many cases, the variance of the measurement（edges）is determined from the specifications or outputs of the sensor, so I manually adjusted some scale parameters of the variances.</p>\n<p>I read that paper! A group at the Hong Kong PolyU is also actively engaged in research in this area.</p>",
      "rawMarkdown": "In the case of the pseudorange factor, the variance of the measurement is based on the provided pesudorange uncertainty. In practice, the variance is adjusted by multiplying the provided pseudorange uncertainty by a factor that depends on the type of satellite signal.\n\nIn many cases, the variance of the measurement（edges）is determined from the specifications or outputs of the sensor, so I manually adjusted some scale parameters of the variances.\n\nI read that paper! A group at the Hong Kong PolyU is also actively engaged in research in this area.",
      "votes": null
    },
    {
      "id": "1456947",
      "postDate": "08/07/2021 06:57:01",
      "content": "<p>Congratulations <a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> !</p>",
      "rawMarkdown": "Congratulations @taroz1461 !",
      "votes": null
    },
    {
      "id": "1457153",
      "postDate": "08/07/2021 09:11:58",
      "content": "<p>I did not come up with the idea of tuning the variances of pseudoranges based on the type of satellite. That might solve the poor performance of my optimization method.</p>\n<p>I’ve also read some of your papers as well as the one above! They were very useful for the GNSS beginners like me to get an insight on the recent techniques in this field of research.</p>\n<p>Again, thank you for the reply, and congrats for your 1st place!</p>",
      "rawMarkdown": "I did not come up with the idea of tuning the variances of pseudoranges based on the type of satellite. That might solve the poor performance of my optimization method.\n\nI’ve also read some of your papers as well as the one above! They were very useful for the GNSS beginners like me to get an insight on the recent techniques in this field of research.\n\nAgain, thank you for the reply, and congrats for your 1st place!",
      "votes": null
    },
    {
      "id": "1457796",
      "postDate": "08/07/2021 15:07:41",
      "content": "<p>Congratulations <a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> for winning the competition!  I have a question, if you haven't worked with raw GNSS data, what data do you use in your research. Not sure if you can share but I am curious.  Congrats again, great work!</p>",
      "rawMarkdown": "Congratulations @taroz1461 for winning the competition!  I have a question, if you haven't worked with raw GNSS data, what data do you use in your research. Not sure if you can share but I am curious.  Congrats again, great work!",
      "votes": null
    },
    {
      "id": "1457857",
      "postDate": "08/07/2021 15:41:34",
      "content": "<p>Congratulations Taro (and everyone)!</p>\n<p>I hadn't heard of Factor Graph Optimisation before, so thanks, something for me to look into for future use. I did a quick search and found <a href=\"https://www.youtube.com/watch?v=f5bIh96SRsk\" target=\"_blank\">this</a> youtube presentation by one of the authors of the paper you and koji mentioned. Might be useful for anyone that is interested.</p>",
      "rawMarkdown": "Congratulations Taro (and everyone)!\n\nI hadn't heard of Factor Graph Optimisation before, so thanks, something for me to look into for future use. I did a quick search and found [this](https://www.youtube.com/watch?v=f5bIh96SRsk) youtube presentation by one of the authors of the paper you and koji mentioned. Might be useful for anyone that is interested.",
      "votes": null
    },
    {
      "id": "1458612",
      "postDate": "08/08/2021 01:21:05",
      "content": "<p>Sorry to mislead you, but I usually use GNSS raw data for my research. However, this was the first time for me to handle raw data from <strong>smartphones</strong>. Thank you!</p>",
      "rawMarkdown": "Sorry to mislead you, but I usually use GNSS raw data for my research. However, this was the first time for me to handle raw data from **smartphones**. Thank you!",
      "votes": null
    },
    {
      "id": "1458660",
      "postDate": "08/08/2021 02:33:03",
      "content": "<p>Congrats on your win!</p>\n<ol>\n<li>Can you share some Python code? <br>\n.2 This may be a dumb question, but can you also explain the difference between GTSAM and simple Bayesian Optimization?</li>\n</ol>",
      "rawMarkdown": "Congrats on your win!\n\n1. Can you share some Python code? \n.2 This may be a dumb question, but can you also explain the difference between GTSAM and simple Bayesian Optimization?",
      "votes": null
    },
    {
      "id": "1459879",
      "postDate": "08/08/2021 15:38:09",
      "content": "<p>Thank you that makes sense.  </p>",
      "rawMarkdown": "Thank you that makes sense.",
      "votes": null
    },
    {
      "id": "1460707",
      "postDate": "08/09/2021 03:31:39",
      "content": "<p>thanks for  Factor Graph Optimization</p>",
      "rawMarkdown": "thanks for  Factor Graph Optimization",
      "votes": null
    },
    {
      "id": "1460964",
      "postDate": "08/09/2021 06:49:12",
      "content": "<p>Congratulations! <a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> </p>",
      "rawMarkdown": "Congratulations! @taroz1461",
      "votes": null
    },
    {
      "id": "1461091",
      "postDate": "08/09/2021 08:00:24",
      "content": "<p>Congratulations Taro! I have never thought of using graph optimization with features like yours. I have one question if you are so kind to answer. You said that you switch between ADR and Doppler whenever possible. Do you need to normalize the ADR values and Doppler values to avoid biased numerical variation?<br>\nCongrats again! Your solution is wonderful. I will keep this in mind for my future research.</p>",
      "rawMarkdown": "Congratulations Taro! I have never thought of using graph optimization with features like yours. I have one question if you are so kind to answer. You said that you switch between ADR and Doppler whenever possible. Do you need to normalize the ADR values and Doppler values to avoid biased numerical variation?\nCongrats again! Your solution is wonderful. I will keep this in mind for my future research.",
      "votes": null
    },
    {
      "id": "1461276",
      "postDate": "08/09/2021 10:12:22",
      "content": "<p>Congratulations</p>",
      "rawMarkdown": "Congratulations",
      "votes": null
    },
    {
      "id": "1461903",
      "postDate": "08/09/2021 15:59:27",
      "content": "<p>Neither ADR nor Doppler is normalized. As shown in this <a href=\"https://www.kaggle.com/gymf123/onepager-tip-acumulated-delta-range-adr\" target=\"_blank\">code</a>, only the drift of the satellite clock is corrected for in both cases. The time variability of the atmosphere delay is negligible within a second, so I do not correct it. Thank you very much!</p>",
      "rawMarkdown": "Neither ADR nor Doppler is normalized. As shown in this [code](https://www.kaggle.com/gymf123/onepager-tip-acumulated-delta-range-adr), only the drift of the satellite clock is corrected for in both cases. The time variability of the atmosphere delay is negligible within a second, so I do not correct it. Thank you very much!",
      "votes": null
    },
    {
      "id": "1461934",
      "postDate": "08/09/2021 16:12:03",
      "content": "<blockquote>\n  <p>Can you share some Python code?</p>\n</blockquote>\n<p>Sorry, I did not use Python this time. I implemented the main algrithm in C++ and Matlab due to the use of GTSAM. I would like to share the source code when I get a chance, but it may take some time.</p>\n<blockquote>\n  <p>This may be a dumb question, but can you also explain the difference between GTSAM and simple Bayesian Optimization?</p>\n</blockquote>\n<p>Graph optimization is different from Bayesian optimization. Unlike Bayesian optimization, which is a black-box optimization, the main difference is that the cost function is created under various nonlinear constraints, and the cost function is minimized.</p>",
      "rawMarkdown": "> Can you share some Python code?\n\nSorry, I did not use Python this time. I implemented the main algrithm in C++ and Matlab due to the use of GTSAM. I would like to share the source code when I get a chance, but it may take some time.\n\n> This may be a dumb question, but can you also explain the difference between GTSAM and simple Bayesian Optimization?\n\nGraph optimization is different from Bayesian optimization. Unlike Bayesian optimization, which is a black-box optimization, the main difference is that the cost function is created under various nonlinear constraints, and the cost function is minimized.",
      "votes": null
    },
    {
      "id": "1462229",
      "postDate": "08/09/2021 18:36:03",
      "content": "<p>awesome-oposume)</p>",
      "rawMarkdown": "awesome-oposume)",
      "votes": null
    },
    {
      "id": "1464636",
      "postDate": "08/10/2021 16:36:40",
      "content": "<p>Congratulations</p>",
      "rawMarkdown": "Congratulations",
      "votes": null
    },
    {
      "id": "1465891",
      "postDate": "08/11/2021 08:08:55",
      "content": "<p>Congrats, Alot to learn from this solution. Thank you for sharing.</p>",
      "rawMarkdown": "Congrats, Alot to learn from this solution. Thank you for sharing.",
      "votes": null
    },
    {
      "id": "1466123",
      "postDate": "08/11/2021 10:20:50",
      "content": "<p>Congrat <a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> for being the 1st solution!</p>",
      "rawMarkdown": "Congrat @taroz1461 for being the 1st solution!",
      "votes": null
    },
    {
      "id": "1467333",
      "postDate": "08/11/2021 23:50:51",
      "content": "<p>Congratulations <a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> </p>",
      "rawMarkdown": "Congratulations @taroz1461",
      "votes": null
    },
    {
      "id": "1486953",
      "postDate": "08/23/2021 10:08:16",
      "content": "<p>Congratulations!!</p>",
      "rawMarkdown": "Congratulations!!",
      "votes": null
    },
    {
      "id": "1490618",
      "postDate": "08/25/2021 18:19:55",
      "content": "<p>Congratulations</p>",
      "rawMarkdown": "Congratulations",
      "votes": null
    },
    {
      "id": "1498091",
      "postDate": "08/31/2021 16:41:43",
      "content": "<p><a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> Congrats , good job =))</p>",
      "rawMarkdown": "taroz1461 Congrats , good job =))",
      "votes": null
    },
    {
      "id": "1553672",
      "postDate": "10/22/2021 11:58:58",
      "content": "<p>Congrats! great job</p>",
      "rawMarkdown": "Congrats! great job",
      "votes": null
    },
    {
      "id": "1714652",
      "postDate": "03/07/2022 07:51:17",
      "content": "<p>Thanks for sharing!<br>\nIs there some code about FGO in python language?</p>",
      "rawMarkdown": "Thanks for sharing!\nIs there some code about FGO in python language?",
      "votes": null
    },
    {
      "id": "1777470",
      "postDate": "05/04/2022 16:01:56",
      "content": "<p>Congratulations!</p>",
      "rawMarkdown": "Congratulations!",
      "votes": null
    },
    {
      "id": "2966970",
      "postDate": "08/22/2024 11:59:57",
      "content": "<p>Very insightful solution!! Can you share more about the 'Motion Factor', what it is and how is it being calculated. Thanks for sharing and Congratulations <a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> !! </p>",
      "rawMarkdown": "Very insightful solution!! Can you share more about the 'Motion Factor', what it is and how is it being calculated. Thanks for sharing and Congratulations @taroz1461 !!",
      "votes": null
    }
  ],
  "comments": [
    {
      "id": 1456303,
      "author_name": "hemhemoh",
      "author_url": "",
      "post_date": "08/06/2021 21:15:11",
      "content": "<p>Wow, Congratulations</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1456455,
      "author_name": "wesleyacheng",
      "author_url": "",
      "post_date": "08/06/2021 23:13:02",
      "content": "<p>congratulations!</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1456481,
      "author_name": "minomonter",
      "author_url": "",
      "post_date": "08/06/2021 23:43:11",
      "content": "<p>Congratulations on winning! We’ve enjoyed so much competing with you. </p>\n<p>I have some questions regarding the solution:</p>\n<ol>\n<li><p>Are there any specific reason why you did not use the IMU sensor data here?</p></li>\n<li><p>Did you incorporate any prior knowledge to estimate multipath satellite signals, such as a mask based on elevation angle, in the FGO? Or is it intended that the switchable constraints performs well enough to detect such signals?</p></li>\n</ol>",
      "votes": null,
      "replies": [
        {
          "id": 1456623,
          "author_name": "taroz1461",
          "author_url": "",
          "post_date": "08/07/2021 02:54:16",
          "content": "<p>Thanks!</p>\n<blockquote>\n  <p>Are there any specific reason why you did not use the IMU sensor data here?</p>\n</blockquote>\n<p>The reason is that I simply did not have the time to do it, and in many environments where GNSS is available, the relative position can be estimated with sufficient accuracy from the carrier phase measurements (ADR). Another reason is that when I checked the IMU data, there was a considerable time jump… In my solution, only the 3D position/velocity was estimated, but I would like to try adding 3D attitude into the estimated state and using IMU observations.</p>\n<blockquote>\n  <p>Did you incorporate any prior knowledge to estimate multipath satellite signals, such as a mask based on elevation angle, in the FGO? Or is it intended that the switchable constraints performs well enough to detect such signals?</p>\n</blockquote>\n<p>The part of robust optimization using outlier-containing measurements was left to switchable constraint. This figure illustrates the switch values of each pseudorange finally estimated by the omitimizer in the MTV course. It can be seen that the weights of observations with large residuals due to multipath, etc., are automatically reduced.<br>\n<img src=\"https://user-images.githubusercontent.com/7933764/128584580-8b50cbb0-41fa-481c-a43d-ddcc195b222c.png\" alt=\"sw\"></p>",
          "votes": null,
          "replies": []
        },
        {
          "id": 1456661,
          "author_name": "minomonter",
          "author_url": "",
          "post_date": "08/07/2021 03:27:17",
          "content": "<p>Thank you for the quick and detailed response! It is quite surprising that the switching constraints contribute that well to the robustness towards outliers.</p>\n<p>One more question: How did you determine the parameters(I assume covariance matrices are the ones) in that optimization? And how tough was it to tune them up?</p>\n<p>I also tried an optimization-based approach similar to the one introduced in <a href=\"https://arxiv.org/pdf/2004.10572.pdf\" target=\"_blank\">this paper</a>, but I kept getting bad results, possibly due to the poor choice of covariances.</p>",
          "votes": null,
          "replies": []
        },
        {
          "id": 1456873,
          "author_name": "taroz1461",
          "author_url": "",
          "post_date": "08/07/2021 06:07:22",
          "content": "<p>In the case of the pseudorange factor, the variance of the measurement is based on the provided pesudorange uncertainty. In practice, the variance is adjusted by multiplying the provided pseudorange uncertainty by a factor that depends on the type of satellite signal.</p>\n<p>In many cases, the variance of the measurement（edges）is determined from the specifications or outputs of the sensor, so I manually adjusted some scale parameters of the variances.</p>\n<p>I read that paper! A group at the Hong Kong PolyU is also actively engaged in research in this area.</p>",
          "votes": null,
          "replies": []
        },
        {
          "id": 1457153,
          "author_name": "minomonter",
          "author_url": "",
          "post_date": "08/07/2021 09:11:58",
          "content": "<p>I did not come up with the idea of tuning the variances of pseudoranges based on the type of satellite. That might solve the poor performance of my optimization method.</p>\n<p>I’ve also read some of your papers as well as the one above! They were very useful for the GNSS beginners like me to get an insight on the recent techniques in this field of research.</p>\n<p>Again, thank you for the reply, and congrats for your 1st place!</p>",
          "votes": null,
          "replies": []
        }
      ]
    },
    {
      "id": 1456622,
      "author_name": "jarupula",
      "author_url": "",
      "post_date": "08/07/2021 02:53:26",
      "content": "<p>Congrats <a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> 🎉🎉</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1456947,
      "author_name": "saurabhbagchi",
      "author_url": "",
      "post_date": "08/07/2021 06:57:01",
      "content": "<p>Congratulations <a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> !</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1457796,
      "author_name": "yvonnef",
      "author_url": "",
      "post_date": "08/07/2021 15:07:41",
      "content": "<p>Congratulations <a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> for winning the competition!  I have a question, if you haven't worked with raw GNSS data, what data do you use in your research. Not sure if you can share but I am curious.  Congrats again, great work!</p>",
      "votes": null,
      "replies": [
        {
          "id": 1458612,
          "author_name": "taroz1461",
          "author_url": "",
          "post_date": "08/08/2021 01:21:05",
          "content": "<p>Sorry to mislead you, but I usually use GNSS raw data for my research. However, this was the first time for me to handle raw data from <strong>smartphones</strong>. Thank you!</p>",
          "votes": null,
          "replies": []
        },
        {
          "id": 1459879,
          "author_name": "yvonnef",
          "author_url": "",
          "post_date": "08/08/2021 15:38:09",
          "content": "<p>Thank you that makes sense.  </p>",
          "votes": null,
          "replies": []
        }
      ]
    },
    {
      "id": 1457857,
      "author_name": "oarfish",
      "author_url": "",
      "post_date": "08/07/2021 15:41:34",
      "content": "<p>Congratulations Taro (and everyone)!</p>\n<p>I hadn't heard of Factor Graph Optimisation before, so thanks, something for me to look into for future use. I did a quick search and found <a href=\"https://www.youtube.com/watch?v=f5bIh96SRsk\" target=\"_blank\">this</a> youtube presentation by one of the authors of the paper you and koji mentioned. Might be useful for anyone that is interested.</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1458660,
      "author_name": "returnofsputnik",
      "author_url": "",
      "post_date": "08/08/2021 02:33:03",
      "content": "<p>Congrats on your win!</p>\n<ol>\n<li>Can you share some Python code? <br>\n.2 This may be a dumb question, but can you also explain the difference between GTSAM and simple Bayesian Optimization?</li>\n</ol>",
      "votes": null,
      "replies": [
        {
          "id": 1461934,
          "author_name": "taroz1461",
          "author_url": "",
          "post_date": "08/09/2021 16:12:03",
          "content": "<blockquote>\n  <p>Can you share some Python code?</p>\n</blockquote>\n<p>Sorry, I did not use Python this time. I implemented the main algrithm in C++ and Matlab due to the use of GTSAM. I would like to share the source code when I get a chance, but it may take some time.</p>\n<blockquote>\n  <p>This may be a dumb question, but can you also explain the difference between GTSAM and simple Bayesian Optimization?</p>\n</blockquote>\n<p>Graph optimization is different from Bayesian optimization. Unlike Bayesian optimization, which is a black-box optimization, the main difference is that the cost function is created under various nonlinear constraints, and the cost function is minimized.</p>",
          "votes": null,
          "replies": []
        }
      ]
    },
    {
      "id": 1460707,
      "author_name": "shivawork",
      "author_url": "",
      "post_date": "08/09/2021 03:31:39",
      "content": "<p>thanks for  Factor Graph Optimization</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1460964,
      "author_name": "rohitsahoo",
      "author_url": "",
      "post_date": "08/09/2021 06:49:12",
      "content": "<p>Congratulations! <a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> </p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1461091,
      "author_name": "thanhdvan",
      "author_url": "",
      "post_date": "08/09/2021 08:00:24",
      "content": "<p>Congratulations Taro! I have never thought of using graph optimization with features like yours. I have one question if you are so kind to answer. You said that you switch between ADR and Doppler whenever possible. Do you need to normalize the ADR values and Doppler values to avoid biased numerical variation?<br>\nCongrats again! Your solution is wonderful. I will keep this in mind for my future research.</p>",
      "votes": null,
      "replies": [
        {
          "id": 1461903,
          "author_name": "taroz1461",
          "author_url": "",
          "post_date": "08/09/2021 15:59:27",
          "content": "<p>Neither ADR nor Doppler is normalized. As shown in this <a href=\"https://www.kaggle.com/gymf123/onepager-tip-acumulated-delta-range-adr\" target=\"_blank\">code</a>, only the drift of the satellite clock is corrected for in both cases. The time variability of the atmosphere delay is negligible within a second, so I do not correct it. Thank you very much!</p>",
          "votes": null,
          "replies": []
        }
      ]
    },
    {
      "id": 1461276,
      "author_name": "kunalbhangare",
      "author_url": "",
      "post_date": "08/09/2021 10:12:22",
      "content": "<p>Congratulations</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1462229,
      "author_name": "zviads",
      "author_url": "",
      "post_date": "08/09/2021 18:36:03",
      "content": "<p>awesome-oposume)</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1464636,
      "author_name": "abhi712",
      "author_url": "",
      "post_date": "08/10/2021 16:36:40",
      "content": "<p>Congratulations</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1465891,
      "author_name": "kingabzpro",
      "author_url": "",
      "post_date": "08/11/2021 08:08:55",
      "content": "<p>Congrats, Alot to learn from this solution. Thank you for sharing.</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1466123,
      "author_name": "promrcan1",
      "author_url": "",
      "post_date": "08/11/2021 10:20:50",
      "content": "<p>Congrat <a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> for being the 1st solution!</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1467333,
      "author_name": "iniestamoh",
      "author_url": "",
      "post_date": "08/11/2021 23:50:51",
      "content": "<p>Congratulations <a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> </p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1486953,
      "author_name": "hironobukobayashi",
      "author_url": "",
      "post_date": "08/23/2021 10:08:16",
      "content": "<p>Congratulations!!</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1490618,
      "author_name": "emptyset3",
      "author_url": "",
      "post_date": "08/25/2021 18:19:55",
      "content": "<p>Congratulations</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1498091,
      "author_name": "firefliesqn",
      "author_url": "",
      "post_date": "08/31/2021 16:41:43",
      "content": "<p><a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> Congrats , good job =))</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1553672,
      "author_name": "nitzankarni",
      "author_url": "",
      "post_date": "10/22/2021 11:58:58",
      "content": "<p>Congrats! great job</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1714652,
      "author_name": "zekunn",
      "author_url": "",
      "post_date": "03/07/2022 07:51:17",
      "content": "<p>Thanks for sharing!<br>\nIs there some code about FGO in python language?</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 1777470,
      "author_name": "apurbapandey",
      "author_url": "",
      "post_date": "05/04/2022 16:01:56",
      "content": "<p>Congratulations!</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 2966970,
      "author_name": "dakshvarshney1409",
      "author_url": "",
      "post_date": "08/22/2024 11:59:57",
      "content": "<p>Very insightful solution!! Can you share more about the 'Motion Factor', what it is and how is it being calculated. Thanks for sharing and Congratulations <a href=\"https://www.kaggle.com/taroz1461\" target=\"_blank\">@taroz1461</a> !! </p>",
      "votes": null,
      "replies": []
    }
  ],
  "raw_markdown_by_id": {
    "1455510": "First, I would like to thank everyone involved in this competition. It has been a very enjoyable two months. \n\nAlthough I am a researcher in the GNSS field, this was the first time I worked with raw GNSS data from smartphones. The raw GNSS data from the smartphone was compared to commercial GNSS receivers used in drones and mobile robots, and I had the following impressions.\n\n- Pseudorange is **very noisy**, and the quality of the GNSS observations is not good\n- There are a lot of **missing data**, **duplication**, **time jump**, etc., and it is very complicated\n\nI realized that I was usually exposed to very clean GNSS data...This competition was very very tough because of the huge amount of courses and the variety of smartphones（and the long variable names...）. To be honest, I don't want to look at GNSS data on smartphones anymore!😐\n\n# Key Points for Solution\n- Global optimization of position and velocity by **Factor Graph Optimization** Technique\n- Velocity constraint by **accumulated delta range（ADR）**\n- Absolute position constraint by **differential pseudorange between a base station**\n- No machine learning（or rather, it was not possible due to time limitations）\n\n# Input Data\n- Phone_Gnsslog.txt\n- RINEX files of GNSS[ base station](https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238579) (I used Verizon base station data from [here](https://webscope.sandbox.yahoo.com/catalog.php?datatype=s&did=88)）\n- Ground Truth（Downtown area only）\n\nIn the end, I did not use Phone_derived.csv. There were some missing data in Phone_derived.csv files. I calculated the satellite position and velocity directly from the RINEX navigation file. Baseline position and IMU data are also not used.\n\n# Factor Graph Optimization\n> Factor graphs are a class of graphical models in which there are variables and factors. The variables represent unknown quantities in the problem, and the factors represent functions on subsets of the variables. Edges in the factor graph are always between factors and variables, and indicate that a particular factor depends on a particular variable.（from [here](https://gtsam.org/2020/06/01/factor-graphs.html)）\n\nThe core of my approach was to use a **global optimization method** based on **Factor Graph**. Several optimization methods have been used [here](https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/261959) and [here](https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/262074), with good results. Factor graph optimization is a method that can apply a variety of complex nonlinear constraints and simultaneously optimize all state variables（the entire driving trajectory）. There are many outliers in the various constraints（edges in the graph）, but a robust optimization technique eliminates the need to manually set the outlier threshold parameters. For more information about factor graphs, see  [this page](https://gtsam.org/tutorials/intro.html).\n\n# Factor Graph Structure\nI tried many different graph structures and finally performed Graph optimization using the following Factor graph.\n![fgo](https://user-images.githubusercontent.com/7933764/128525861-3b529b21-e5bb-49ca-8ca6-60229b4ade32.png)\n\nThe graph node\\\\(X_i\\\\) presents the state variable of different moments, and the edge connecting two nodes presents the error function \\\\(e(\\cdot)\\\\); each edge corresponds to a single observation \\\\(Z_i\\\\). In the graph, error function \\\\(e(\\cdot)\\\\) represents probabilistic constraints applied to the state at the specified time-step. Optimization factor graph can be written as follows.\n<img src=\"https://user-images.githubusercontent.com/7933764/128522724-ad708687-61ec-4416-b622-c972b451a8a0.png\" width=\"300\">\n\nHere, \\\\(\\Omega_i\\\\) is the information matrix（inverse of covariance matrix）which determines the accuracy of the observation \\\\(Z_i\\\\). We defined the following as nodes（estimated states）of the graph.\n<img src=\"https://user-images.githubusercontent.com/7933764/128524196-b6843c78-dfe3-4850-88ed-9fada7becea2.png\" width=\"100\">\n<img src=\"https://user-images.githubusercontent.com/7933764/128524319-f1c6a8fe-0f7e-4417-b702-a9cf815aa466.png\" width=\"400\">\n\nwhere \\\\(r\\\\) and \\\\(\\dot{r}\\\\) is 3D position/velocity in earth-centered earth-fixed（ECEF）coordinate. \\\\(t\\\\) and \\\\(\\dot{t}\\\\) represent the receive clock bias and drift in each GNSS signals.\n \nHere, \\\\(s\\\\) in the graph is a [switchable constraint](https://nikosuenderhauf.github.io/assets/papers/IROS12-switchableConstraints.pdf), which is a state that takes a variable between 0 and 1. The value of switchable constraint is estimated simultaneously by optimization. On the edge of an outlier, the switchable constraint is automatically optimized to 0 and acts like a weight for the observed value. The optimization problem can be described as follows.\n\n<img src=\"https://user-images.githubusercontent.com/7933764/128525345-2cb74f7a-5a74-4fa4-8c30-1d73a0828ecf.png\" width=\"400\">\n\nwhere the last term in the above equation is the anchor factor of the switch to prevent the switch state from going to all zeros. \n\n### Pseudorange Factor\nIn the Pseudorange Factor, the observation is the difference between the pseudorange and the reference station's pseudorange, which removes the all bias error component in GNSS measurements（excluding multipath errors）. Theoretically, the residuals of the single differenced pseudorange have a Gaussian distribution with zero mean value if receiver clock error is compensated. This single-difference pseudorange improves the absolute position accuracy. Using this differential GNSS technique, I did not need any bias correction for the final position.\n\n### Doppler/ADR Factor\nThe pseudorange rate（Doppler shift）of the smartphone was noisier than I expected. I think the use of ADR（see P21-P22 of [this document](https://www.euspa.europa.eu/simplecount_pdf/tracker?file=expo/1.1_frank_van_diggelen_-_google.pdf)） led to a higher level of competition. The following figure shows the velocities calculated from Doppler and ADR, respectively, compared to the ground truth. Velocity from ADR is about **5 cm/s**! In terms of accuracy alone, ADR was clearly superior to Doppler shift. Although the ADR is super accurate, its availability is lower than Doppler shift due to cycle slip and half-cycle ambiguity problem, so the Doppler factor is used instead only when the ADR factor is not available.\n\n![adr](https://user-images.githubusercontent.com/7933764/128528282-8383da71-dbed-4b11-b121-743bf3fbf839.png)\n\n### Motion Factor\nThe motion factor uses the estimated velocity and clock drift to add constraints between neighboring nodes. It simply adds a constraint so that the integral of the velocity and clock drift is equal to the difference between the neighboring states.\n\n### Pseudo-Position Factor\nThe pseudo-position factor was used only for the downtown area, and since the ground truth was traveling along the same path as the test data, the points on the ground truth path closest to the estimated trajectory were extracted and added to the graph as pseudo position constraints with appropriate covariance.\n\n# A Few Concerns\n- As you can see in this discussion, the CV and LB scores are not matched, as is the big difference between the public and private LB scores. Without machine learning, I don't think there would be much overfitting to public scores. I can't explain the difference in these scores.\n\n- I have some doubts about the accuracy of Ground Truth. The ground truth is based on Novatel SPAN（I also have this sensor）, but the results are quite different depending on multipath situations and analysis parameters. I would like the organizer to release the ground truth of the test data for future evaluation. I would also like to know the variance of the estimated ground truth.\n\n# My Impressions\n- Too bad I failed the decimeter challenge. The best public score in all my submissions was 1.4 m. I failed to choose the final post... I am convinced that with a combination of different techniques, I can eventually break 1 m!😃\n\n- Graph optimization was very powerful. It optimizes all variables at the same time under nonlinear constraints, so it performs much better than filtering methods such as KF. For the implementation, I used the [GTSAM](https://github.com/borglab/gtsam), which is C++ library, and has Matlab and Python wrapper.\n\n- It's a shame that I couldn't incorporate machine learning, which I wanted to do at first. I'm enjoying reading the other team's solutions. Let's write a paper together.\n\n- There was a considerable difference in the GNSS observations depending on the phone. In the end, I didn't use phone marge and estimated the trajectory of only the best phone for each run. My best smartphone is Samsung Galaxy S20 Ultra, which is very good at tracking the GNSS carrier phase. I love it😊\n\n- The only thing I could trust was ADR. Thank you so much, ADR.",
    "1456303": "Wow, Congratulations",
    "1456455": "congratulations!",
    "1456481": "Congratulations on winning! We’ve enjoyed so much competing with you. \n\nI have some questions regarding the solution:\n\n1. Are there any specific reason why you did not use the IMU sensor data here?\n\n2. Did you incorporate any prior knowledge to estimate multipath satellite signals, such as a mask based on elevation angle, in the FGO? Or is it intended that the switchable constraints performs well enough to detect such signals?",
    "1456622": "Congrats @taroz1461 🎉🎉",
    "1456623": "Thanks!\n\n> Are there any specific reason why you did not use the IMU sensor data here?\n\nThe reason is that I simply did not have the time to do it, and in many environments where GNSS is available, the relative position can be estimated with sufficient accuracy from the carrier phase measurements (ADR). Another reason is that when I checked the IMU data, there was a considerable time jump... In my solution, only the 3D position/velocity was estimated, but I would like to try adding 3D attitude into the estimated state and using IMU observations.\n\n> Did you incorporate any prior knowledge to estimate multipath satellite signals, such as a mask based on elevation angle, in the FGO? Or is it intended that the switchable constraints performs well enough to detect such signals?\n\nThe part of robust optimization using outlier-containing measurements was left to switchable constraint. This figure illustrates the switch values of each pseudorange finally estimated by the omitimizer in the MTV course. It can be seen that the weights of observations with large residuals due to multipath, etc., are automatically reduced.\n![sw](https://user-images.githubusercontent.com/7933764/128584580-8b50cbb0-41fa-481c-a43d-ddcc195b222c.png)",
    "1456661": "Thank you for the quick and detailed response! It is quite surprising that the switching constraints contribute that well to the robustness towards outliers.\n\n\nOne more question: How did you determine the parameters(I assume covariance matrices are the ones) in that optimization? And how tough was it to tune them up?\n\nI also tried an optimization-based approach similar to the one introduced in [this paper](https://arxiv.org/pdf/2004.10572.pdf), but I kept getting bad results, possibly due to the poor choice of covariances.",
    "1456873": "In the case of the pseudorange factor, the variance of the measurement is based on the provided pesudorange uncertainty. In practice, the variance is adjusted by multiplying the provided pseudorange uncertainty by a factor that depends on the type of satellite signal.\n\nIn many cases, the variance of the measurement（edges）is determined from the specifications or outputs of the sensor, so I manually adjusted some scale parameters of the variances.\n\nI read that paper! A group at the Hong Kong PolyU is also actively engaged in research in this area.",
    "1456947": "Congratulations @taroz1461 !",
    "1457153": "I did not come up with the idea of tuning the variances of pseudoranges based on the type of satellite. That might solve the poor performance of my optimization method.\n\nI’ve also read some of your papers as well as the one above! They were very useful for the GNSS beginners like me to get an insight on the recent techniques in this field of research.\n\nAgain, thank you for the reply, and congrats for your 1st place!",
    "1457796": "Congratulations @taroz1461 for winning the competition!  I have a question, if you haven't worked with raw GNSS data, what data do you use in your research. Not sure if you can share but I am curious.  Congrats again, great work!",
    "1457857": "Congratulations Taro (and everyone)!\n\nI hadn't heard of Factor Graph Optimisation before, so thanks, something for me to look into for future use. I did a quick search and found [this](https://www.youtube.com/watch?v=f5bIh96SRsk) youtube presentation by one of the authors of the paper you and koji mentioned. Might be useful for anyone that is interested.",
    "1458612": "Sorry to mislead you, but I usually use GNSS raw data for my research. However, this was the first time for me to handle raw data from **smartphones**. Thank you!",
    "1458660": "Congrats on your win!\n\n1. Can you share some Python code? \n.2 This may be a dumb question, but can you also explain the difference between GTSAM and simple Bayesian Optimization?",
    "1459879": "Thank you that makes sense.",
    "1460707": "thanks for  Factor Graph Optimization",
    "1460964": "Congratulations! @taroz1461",
    "1461091": "Congratulations Taro! I have never thought of using graph optimization with features like yours. I have one question if you are so kind to answer. You said that you switch between ADR and Doppler whenever possible. Do you need to normalize the ADR values and Doppler values to avoid biased numerical variation?\nCongrats again! Your solution is wonderful. I will keep this in mind for my future research.",
    "1461276": "Congratulations",
    "1461903": "Neither ADR nor Doppler is normalized. As shown in this [code](https://www.kaggle.com/gymf123/onepager-tip-acumulated-delta-range-adr), only the drift of the satellite clock is corrected for in both cases. The time variability of the atmosphere delay is negligible within a second, so I do not correct it. Thank you very much!",
    "1461934": "> Can you share some Python code?\n\nSorry, I did not use Python this time. I implemented the main algrithm in C++ and Matlab due to the use of GTSAM. I would like to share the source code when I get a chance, but it may take some time.\n\n> This may be a dumb question, but can you also explain the difference between GTSAM and simple Bayesian Optimization?\n\nGraph optimization is different from Bayesian optimization. Unlike Bayesian optimization, which is a black-box optimization, the main difference is that the cost function is created under various nonlinear constraints, and the cost function is minimized.",
    "1462229": "awesome-oposume)",
    "1464636": "Congratulations",
    "1465891": "Congrats, Alot to learn from this solution. Thank you for sharing.",
    "1466123": "Congrat @taroz1461 for being the 1st solution!",
    "1467333": "Congratulations @taroz1461",
    "1486953": "Congratulations!!",
    "1490618": "Congratulations",
    "1498091": "taroz1461 Congrats , good job =))",
    "1553672": "Congrats! great job",
    "1714652": "Thanks for sharing!\nIs there some code about FGO in python language?",
    "1777470": "Congratulations!",
    "2966970": "Very insightful solution!! Can you share more about the 'Motion Factor', what it is and how is it being calculated. Thanks for sharing and Congratulations @taroz1461 !!"
  },
  "source": "meta"
}