{
  "id": 262941,
  "title": "19 place solution （shake TOKYO）",
  "url": "/competitions/google-smartphone-decimeter-challenge/discussion/262941",
  "author_name": "dehokanta",
  "post_date": "2021-08-08T00:27:22.397000",
  "votes": 22,
  "comment_count": 0,
  "views": 0,
  "content": "<h2>Team solution</h2>\n<p>First of all, thank you very much for hosting this competition. Here we describe the team TOKYO's solution. </p>\n<p>Unfortunately, our solution went through a shake down （Public 8th Private 19th）. We guess one of the reasons is that we targeted downtown &amp; tree areas too much, while highway areas consist the major part of the private dataset.</p>\n<p>Our solution consists of several algorithms, some of them introduced by other competitors and made public, the others developed by ourselves.</p>\n<p><img src=\"https://i.imgur.com/pAhVzTP.png\" alt=\"Imgur\"></p>\n<h4>1. GNSS-based localization   (<a href=\"https://www.kaggle.com/minomonter/gnss-only-estimation?scriptVersionId=70161014\" target=\"_blank\">link</a>)</h4>\n<p>The first module is a position estimation based on GNSS data provided in *_derived.csv. With some simple tricks as follow, we achived LB: 6.665 in public.</p>\n<ul>\n<li>Using cauchy loss in least-square optimization</li>\n<li>Introducing Elevation Mask</li>\n</ul>\n<h4>2. Delta prediction  (<a href=\"https://www.kaggle.com/dehokanta/shake-tokyo-delta-predicition?scriptVersionId=70516831\" target=\"_blank\">link</a>)</h4>\n<p>Here we trained a model which estimates the difference between estimated position \\((lat^i_{est}, lng^i_{est})\\) and corresponding ground truth position \\((lat^i_{gt}, lng^i_{gt})\\), based on the provided train data. We introduced several features and used LightGBM for the estimation.</p>\n<h4>3. Outlier rejection &amp; Kalman smoothing</h4>\n<p>Based on the idea introduced <a href=\"https://www.kaggle.com/dehokanta/baseline-post-processing-by-outlier-correction\" target=\"_blank\">here</a> by <a href=\"https://www.kaggle.com/dehokanta\" target=\"_blank\">@dehokanta</a>, we introduced a rule-based outlier detection algorithm. Through several experiments, we've found out that the estimation accuracy improved significantly by rejecting the following points:</p>\n<ul>\n<li>A point where the estimated velocity （= distance between the neighboring points） is higher than \\(45 [\\rm{m/s}]\\)</li>\n<li>A point where the estimated acceleration （ = difference of velocity between the two neighboring points） is higher than \\(1.8 \\times 9.81 [\\rm{m/s^2}]\\)<br>\nAfter this, we applied the kalman smoothing introduced <a href=\"https://www.kaggle.com/emaerthin/demonstration-of-the-kalman-filter\" target=\"_blank\">here</a> by <a href=\"https://www.kaggle.com/emaerthin\" target=\"_blank\">@emaerthin</a>.</li>\n</ul>\n<h4>4. Phones mean</h4>\n<p>We used several types of phones mean method. Extended from the idea introduced <a href=\"https://www.kaggle.com/t88take/gsdc-phones-mean-prediction\" target=\"_blank\">here</a>, we used several types of phone means such as:</p>\n<ul>\n<li>Align all the points from different smartphones into one line</li>\n<li>Align all the points from different smartphones by introducing a weight based on how \"zigzag\" the estimated trajectories are</li>\n</ul>\n<h4>5. Stop detection &amp; filtering</h4>\n<p>As discussed in several discussions &amp; notebooks, the noise during the vehicle's stop was apparently one of the major noise in the baseline estimation.<br>\nWe developed stop detection algorithm using inertial measurements in a rule-based fashion.</p>\n<p>For some collections which does not include sensor data, we estimated the stop state only from the position data.</p>\n<h4>6. Snap-to-grid</h4>\n<p>We used snap-to-grid for tree area. For downtown area, we applied a different snap-to-grid method described below.</p>\n<h4>7. Dynamic Time Warping based snap-to-grid  (<a href=\"https://www.kaggle.com/minomonter/dynamic-time-warping-snap-to-grid?scriptVersionId=70166586\" target=\"_blank\">link</a>)</h4>\n<p>To overcome some severe problems in simple snap-to-grid, we combined the algorithm with Dynamic Time Warping （DTW）. This algorithm significantly worked especially for the downtown area.</p>\n<h4>8. Remove Samsung</h4>\n<p>We used a method introduced <a href=\"https://www.kaggle.com/columbia2131/device-eda-interpolate-by-removing-device-en-ja\" target=\"_blank\">here</a> by the other team.</p>\n<hr>\n<h3>What we tried but didn't use in the final pipeline</h3>\n<ul>\n<li>RTK based localization using RTKLIB</li>\n<li>delta prediction by MLP</li>\n<li>pseudo labeling for delta prediction</li>\n<li>some other filtering methods, e.g. SGFilter</li>\n<li>Factor graph optimization based on <a href=\"https://arxiv.org/pdf/2004.10572.pdf\" target=\"_blank\">this paper</a></li>\n<li>outlier prediction by ML</li>\n<li>stop detection by density</li>\n</ul>\n<h3>Final submission is visualized here.(<a href=\"https://www.kaggle.com/dehokanta/shake-tokyo-visualization-of-final-submissions\" target=\"_blank\">link</a>)</h3>",
  "messages": [
    {
      "id": 1458569,
      "postDate": "2021-08-08T00:27:22.397Z",
      "content": "<h2>Team solution</h2>\n<p>First of all, thank you very much for hosting this competition. Here we describe the team TOKYO's solution. </p>\n<p>Unfortunately, our solution went through a shake down （Public 8th Private 19th）. We guess one of the reasons is that we targeted downtown &amp; tree areas too much, while highway areas consist the major part of the private dataset.</p>\n<p>Our solution consists of several algorithms, some of them introduced by other competitors and made public, the others developed by ourselves.</p>\n<p><img src=\"https://i.imgur.com/pAhVzTP.png\" alt=\"Imgur\"></p>\n<h4>1. GNSS-based localization   (<a href=\"https://www.kaggle.com/minomonter/gnss-only-estimation?scriptVersionId=70161014\" target=\"_blank\">link</a>)</h4>\n<p>The first module is a position estimation based on GNSS data provided in *_derived.csv. With some simple tricks as follow, we achived LB: 6.665 in public.</p>\n<ul>\n<li>Using cauchy loss in least-square optimization</li>\n<li>Introducing Elevation Mask</li>\n</ul>\n<h4>2. Delta prediction  (<a href=\"https://www.kaggle.com/dehokanta/shake-tokyo-delta-predicition?scriptVersionId=70516831\" target=\"_blank\">link</a>)</h4>\n<p>Here we trained a model which estimates the difference between estimated position \\((lat^i_{est}, lng^i_{est})\\) and corresponding ground truth position \\((lat^i_{gt}, lng^i_{gt})\\), based on the provided train data. We introduced several features and used LightGBM for the estimation.</p>\n<h4>3. Outlier rejection &amp; Kalman smoothing</h4>\n<p>Based on the idea introduced <a href=\"https://www.kaggle.com/dehokanta/baseline-post-processing-by-outlier-correction\" target=\"_blank\">here</a> by <a href=\"https://www.kaggle.com/dehokanta\" target=\"_blank\">@dehokanta</a>, we introduced a rule-based outlier detection algorithm. Through several experiments, we've found out that the estimation accuracy improved significantly by rejecting the following points:</p>\n<ul>\n<li>A point where the estimated velocity （= distance between the neighboring points） is higher than \\(45 [\\rm{m/s}]\\)</li>\n<li>A point where the estimated acceleration （ = difference of velocity between the two neighboring points） is higher than \\(1.8 \\times 9.81 [\\rm{m/s^2}]\\)<br>\nAfter this, we applied the kalman smoothing introduced <a href=\"https://www.kaggle.com/emaerthin/demonstration-of-the-kalman-filter\" target=\"_blank\">here</a> by <a href=\"https://www.kaggle.com/emaerthin\" target=\"_blank\">@emaerthin</a>.</li>\n</ul>\n<h4>4. Phones mean</h4>\n<p>We used several types of phones mean method. Extended from the idea introduced <a href=\"https://www.kaggle.com/t88take/gsdc-phones-mean-prediction\" target=\"_blank\">here</a>, we used several types of phone means such as:</p>\n<ul>\n<li>Align all the points from different smartphones into one line</li>\n<li>Align all the points from different smartphones by introducing a weight based on how \"zigzag\" the estimated trajectories are</li>\n</ul>\n<h4>5. Stop detection &amp; filtering</h4>\n<p>As discussed in several discussions &amp; notebooks, the noise during the vehicle's stop was apparently one of the major noise in the baseline estimation.<br>\nWe developed stop detection algorithm using inertial measurements in a rule-based fashion.</p>\n<p>For some collections which does not include sensor data, we estimated the stop state only from the position data.</p>\n<h4>6. Snap-to-grid</h4>\n<p>We used snap-to-grid for tree area. For downtown area, we applied a different snap-to-grid method described below.</p>\n<h4>7. Dynamic Time Warping based snap-to-grid  (<a href=\"https://www.kaggle.com/minomonter/dynamic-time-warping-snap-to-grid?scriptVersionId=70166586\" target=\"_blank\">link</a>)</h4>\n<p>To overcome some severe problems in simple snap-to-grid, we combined the algorithm with Dynamic Time Warping （DTW）. This algorithm significantly worked especially for the downtown area.</p>\n<h4>8. Remove Samsung</h4>\n<p>We used a method introduced <a href=\"https://www.kaggle.com/columbia2131/device-eda-interpolate-by-removing-device-en-ja\" target=\"_blank\">here</a> by the other team.</p>\n<hr>\n<h3>What we tried but didn't use in the final pipeline</h3>\n<ul>\n<li>RTK based localization using RTKLIB</li>\n<li>delta prediction by MLP</li>\n<li>pseudo labeling for delta prediction</li>\n<li>some other filtering methods, e.g. SGFilter</li>\n<li>Factor graph optimization based on <a href=\"https://arxiv.org/pdf/2004.10572.pdf\" target=\"_blank\">this paper</a></li>\n<li>outlier prediction by ML</li>\n<li>stop detection by density</li>\n</ul>\n<h3>Final submission is visualized here.(<a href=\"https://www.kaggle.com/dehokanta/shake-tokyo-visualization-of-final-submissions\" target=\"_blank\">link</a>)</h3>",
      "rawMarkdown": "## Team solution\nFirst of all, thank you very much for hosting this competition. Here we describe the team TOKYO's solution. \n\nUnfortunately, our solution went through a shake down （Public 8th Private 19th）. We guess one of the reasons is that we targeted downtown & tree areas too much, while highway areas consist the major part of the private dataset.\n\nOur solution consists of several algorithms, some of them introduced by other competitors and made public, the others developed by ourselves.\n\n![Imgur](https://i.imgur.com/pAhVzTP.png)\n\n#### 1. GNSS-based localization   ([link](https://www.kaggle.com/minomonter/gnss-only-estimation?scriptVersionId=70161014))\nThe first module is a position estimation based on GNSS data provided in *_derived.csv. With some simple tricks as follow, we achived LB: 6.665 in public.\n- Using cauchy loss in least-square optimization\n- Introducing Elevation Mask\n\n#### 2. Delta prediction  ([link](https://www.kaggle.com/dehokanta/shake-tokyo-delta-predicition?scriptVersionId=70516831))\nHere we trained a model which estimates the difference between estimated position \\\\((lat^i_{est}, lng^i_{est})\\\\) and corresponding ground truth position \\\\((lat^i_{gt}, lng^i_{gt})\\\\), based on the provided train data. We introduced several features and used LightGBM for the estimation.\n\n#### 3. Outlier rejection & Kalman smoothing\nBased on the idea introduced [here](https://www.kaggle.com/dehokanta/baseline-post-processing-by-outlier-correction) by [@dehokanta](https://www.kaggle.com/dehokanta), we introduced a rule-based outlier detection algorithm. Through several experiments, we've found out that the estimation accuracy improved significantly by rejecting the following points:\n- A point where the estimated velocity （= distance between the neighboring points） is higher than \\\\(45 [\\rm{m/s}]\\\\)\n- A point where the estimated acceleration （ = difference of velocity between the two neighboring points） is higher than \\\\(1.8 \\times 9.81 [\\rm{m/s^2}]\\\\)\nAfter this, we applied the kalman smoothing introduced [here](https://www.kaggle.com/emaerthin/demonstration-of-the-kalman-filter) by [@emaerthin](https://www.kaggle.com/emaerthin).\n\n#### 4. Phones mean\nWe used several types of phones mean method. Extended from the idea introduced [here](https://www.kaggle.com/t88take/gsdc-phones-mean-prediction), we used several types of phone means such as:\n- Align all the points from different smartphones into one line\n- Align all the points from different smartphones by introducing a weight based on how \"zigzag\" the estimated trajectories are\n\n#### 5. Stop detection & filtering\nAs discussed in several discussions & notebooks, the noise during the vehicle's stop was apparently one of the major noise in the baseline estimation.\nWe developed stop detection algorithm using inertial measurements in a rule-based fashion.\n\nFor some collections which does not include sensor data, we estimated the stop state only from the position data.\n\n#### 6. Snap-to-grid\nWe used snap-to-grid for tree area. For downtown area, we applied a different snap-to-grid method described below.\n\n#### 7. Dynamic Time Warping based snap-to-grid  ([link](https://www.kaggle.com/minomonter/dynamic-time-warping-snap-to-grid?scriptVersionId=70166586))\nTo overcome some severe problems in simple snap-to-grid, we combined the algorithm with Dynamic Time Warping （DTW）. This algorithm significantly worked especially for the downtown area.\n\n#### 8. Remove Samsung\nWe used a method introduced [here](https://www.kaggle.com/columbia2131/device-eda-interpolate-by-removing-device-en-ja) by the other team.\n\n------------------------------------------------------\n\n###  What we tried but didn't use in the final pipeline\n- RTK based localization using RTKLIB\n- delta prediction by MLP\n- pseudo labeling for delta prediction\n- some other filtering methods, e.g. SGFilter\n- Factor graph optimization based on [this paper](https://arxiv.org/pdf/2004.10572.pdf)\n- outlier prediction by ML\n- stop detection by density\n\n### Final submission is visualized here.([link](https://www.kaggle.com/dehokanta/shake-tokyo-visualization-of-final-submissions))\n\n",
      "votes": 22
    }
  ],
  "comments": [],
  "raw_markdown_by_id": {
    "1458569": "## Team solution\nFirst of all, thank you very much for hosting this competition. Here we describe the team TOKYO's solution. \n\nUnfortunately, our solution went through a shake down （Public 8th Private 19th）. We guess one of the reasons is that we targeted downtown & tree areas too much, while highway areas consist the major part of the private dataset.\n\nOur solution consists of several algorithms, some of them introduced by other competitors and made public, the others developed by ourselves.\n\n![Imgur](https://i.imgur.com/pAhVzTP.png)\n\n#### 1. GNSS-based localization   ([link](https://www.kaggle.com/minomonter/gnss-only-estimation?scriptVersionId=70161014))\nThe first module is a position estimation based on GNSS data provided in *_derived.csv. With some simple tricks as follow, we achived LB: 6.665 in public.\n- Using cauchy loss in least-square optimization\n- Introducing Elevation Mask\n\n#### 2. Delta prediction  ([link](https://www.kaggle.com/dehokanta/shake-tokyo-delta-predicition?scriptVersionId=70516831))\nHere we trained a model which estimates the difference between estimated position \\\\((lat^i_{est}, lng^i_{est})\\\\) and corresponding ground truth position \\\\((lat^i_{gt}, lng^i_{gt})\\\\), based on the provided train data. We introduced several features and used LightGBM for the estimation.\n\n#### 3. Outlier rejection & Kalman smoothing\nBased on the idea introduced [here](https://www.kaggle.com/dehokanta/baseline-post-processing-by-outlier-correction) by [@dehokanta](https://www.kaggle.com/dehokanta), we introduced a rule-based outlier detection algorithm. Through several experiments, we've found out that the estimation accuracy improved significantly by rejecting the following points:\n- A point where the estimated velocity （= distance between the neighboring points） is higher than \\\\(45 [\\rm{m/s}]\\\\)\n- A point where the estimated acceleration （ = difference of velocity between the two neighboring points） is higher than \\\\(1.8 \\times 9.81 [\\rm{m/s^2}]\\\\)\nAfter this, we applied the kalman smoothing introduced [here](https://www.kaggle.com/emaerthin/demonstration-of-the-kalman-filter) by [@emaerthin](https://www.kaggle.com/emaerthin).\n\n#### 4. Phones mean\nWe used several types of phones mean method. Extended from the idea introduced [here](https://www.kaggle.com/t88take/gsdc-phones-mean-prediction), we used several types of phone means such as:\n- Align all the points from different smartphones into one line\n- Align all the points from different smartphones by introducing a weight based on how \"zigzag\" the estimated trajectories are\n\n#### 5. Stop detection & filtering\nAs discussed in several discussions & notebooks, the noise during the vehicle's stop was apparently one of the major noise in the baseline estimation.\nWe developed stop detection algorithm using inertial measurements in a rule-based fashion.\n\nFor some collections which does not include sensor data, we estimated the stop state only from the position data.\n\n#### 6. Snap-to-grid\nWe used snap-to-grid for tree area. For downtown area, we applied a different snap-to-grid method described below.\n\n#### 7. Dynamic Time Warping based snap-to-grid  ([link](https://www.kaggle.com/minomonter/dynamic-time-warping-snap-to-grid?scriptVersionId=70166586))\nTo overcome some severe problems in simple snap-to-grid, we combined the algorithm with Dynamic Time Warping （DTW）. This algorithm significantly worked especially for the downtown area.\n\n#### 8. Remove Samsung\nWe used a method introduced [here](https://www.kaggle.com/columbia2131/device-eda-interpolate-by-removing-device-en-ja) by the other team.\n\n------------------------------------------------------\n\n###  What we tried but didn't use in the final pipeline\n- RTK based localization using RTKLIB\n- delta prediction by MLP\n- pseudo labeling for delta prediction\n- some other filtering methods, e.g. SGFilter\n- Factor graph optimization based on [this paper](https://arxiv.org/pdf/2004.10572.pdf)\n- outlier prediction by ML\n- stop detection by density\n\n### Final submission is visualized here.([link](https://www.kaggle.com/dehokanta/shake-tokyo-visualization-of-final-submissions))\n\n"
  }
}