{
  "id": 583650,
  "title": "📊 Drift in Velocity and Position Estimation",
  "url": "/competitions/cmi-detect-behavior-with-sensor-data/discussion/583650",
  "author_name": "Bilzard",
  "post_date": "2025-06-08T11:12:46.601000",
  "votes": 29,
  "comment_count": 3,
  "views": 0,
  "content": "<p>In <a href=\"https://www.kaggle.com/competitions/cmi-detect-behavior-with-sensor-data/discussion/583080\" target=\"_blank\">the previous topic</a>, I shared how to estimate acceleration in world coordinates (i.e., real-world coordinates).  <br>\nAs a next step, we can go further to estimate the <strong>velocity and position</strong> of the sensors in the world coordinate system.</p>\n<ul>\n<li>Notebook: <a href=\"https://www.kaggle.com/code/tatamikenn/eda-drift-in-velocity-position-estimate\" target=\"_blank\">https://www.kaggle.com/code/tatamikenn/eda-drift-in-velocity-position-estimate</a></li>\n</ul>\n<h2>Background</h2>\n<p>In theory, velocity and position are computed as cumulative sums of acceleration and velocity, respectively, as follows:</p>\n<pre><code>gravity = np.array([, , ])\nacc_linear = acc_world - gravity\n\nvelocity_linear = np.cumsum(acc_linear * dt, axis=)\nposition_linear = np.cumsum(velocity_linear * dt, axis=)\n</code></pre>\n<p>However, in practice, the estimated velocity and position are <strong>very prone to noise</strong>, commonly referred to as <strong>drift</strong>.<br>\nThis drift accumulates over time as the measurement continues.</p>\n<h2>Example</h2>\n<p>Let's take a look at an example sequence.</p>\n<p>The first graph below shows that the estimated position drifts <strong>up to 20 meters</strong> away from the initial position — clearly an unrealistic scale of error.</p>\n<p>A naive but often effective approach is to <strong>reset the drift</strong> when we are confident that the subject is in a static state.<br>\nIn this competition, labels like <code>Hand at target location</code> or <code>Performs gesture</code> can be useful indicators of such static states.</p>\n<p>The second graph shows the estimated velocity and position <strong>after drift correction</strong> at the beginning of the <code>Gesture</code> phase.</p>\n<p>This time, the final position of the sensor is about <strong>50 cm</strong> away from the initial point.<br>\nThe drift is significantly smaller and within what we could consider a more <strong>realistic range</strong>.</p>\n<p>That said, <strong>some residual drift still remains</strong>, and it may affect ML models — especially during longer gestures.</p>\n<p>Therefore, <strong>drift correction techniques</strong>, potentially including ML-based estimation, might be valuable in this competition.</p>\n<p><img src=\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F4910466%2F30acf3967741a1f989e83490874588e3%2FScreenshot%202025-06-08%20at%2019.49.26.png?generation=1749379935002121&amp;alt=media\" alt=\"\"></p>\n<p><img src=\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F4910466%2F2f72e539c06f7f993b1fc82c12bdda97%2FScreenshot%202025-06-08%20at%2019.49.38.png?generation=1749379954477521&amp;alt=media\" alt=\"\"></p>",
  "messages": [
    {
      "id": 3219832,
      "postDate": "2025-06-08T11:12:46.600Z",
      "content": "<p>In <a href=\"https://www.kaggle.com/competitions/cmi-detect-behavior-with-sensor-data/discussion/583080\" target=\"_blank\">the previous topic</a>, I shared how to estimate acceleration in world coordinates (i.e., real-world coordinates).  <br>\nAs a next step, we can go further to estimate the <strong>velocity and position</strong> of the sensors in the world coordinate system.</p>\n<ul>\n<li>Notebook: <a href=\"https://www.kaggle.com/code/tatamikenn/eda-drift-in-velocity-position-estimate\" target=\"_blank\">https://www.kaggle.com/code/tatamikenn/eda-drift-in-velocity-position-estimate</a></li>\n</ul>\n<h2>Background</h2>\n<p>In theory, velocity and position are computed as cumulative sums of acceleration and velocity, respectively, as follows:</p>\n<pre><code>gravity = np.array([, , ])\nacc_linear = acc_world - gravity\n\nvelocity_linear = np.cumsum(acc_linear * dt, axis=)\nposition_linear = np.cumsum(velocity_linear * dt, axis=)\n</code></pre>\n<p>However, in practice, the estimated velocity and position are <strong>very prone to noise</strong>, commonly referred to as <strong>drift</strong>.<br>\nThis drift accumulates over time as the measurement continues.</p>\n<h2>Example</h2>\n<p>Let's take a look at an example sequence.</p>\n<p>The first graph below shows that the estimated position drifts <strong>up to 20 meters</strong> away from the initial position — clearly an unrealistic scale of error.</p>\n<p>A naive but often effective approach is to <strong>reset the drift</strong> when we are confident that the subject is in a static state.<br>\nIn this competition, labels like <code>Hand at target location</code> or <code>Performs gesture</code> can be useful indicators of such static states.</p>\n<p>The second graph shows the estimated velocity and position <strong>after drift correction</strong> at the beginning of the <code>Gesture</code> phase.</p>\n<p>This time, the final position of the sensor is about <strong>50 cm</strong> away from the initial point.<br>\nThe drift is significantly smaller and within what we could consider a more <strong>realistic range</strong>.</p>\n<p>That said, <strong>some residual drift still remains</strong>, and it may affect ML models — especially during longer gestures.</p>\n<p>Therefore, <strong>drift correction techniques</strong>, potentially including ML-based estimation, might be valuable in this competition.</p>\n<p><img src=\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F4910466%2F30acf3967741a1f989e83490874588e3%2FScreenshot%202025-06-08%20at%2019.49.26.png?generation=1749379935002121&amp;alt=media\" alt=\"\"></p>\n<p><img src=\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F4910466%2F2f72e539c06f7f993b1fc82c12bdda97%2FScreenshot%202025-06-08%20at%2019.49.38.png?generation=1749379954477521&amp;alt=media\" alt=\"\"></p>",
      "rawMarkdown": "In [the previous topic](https://www.kaggle.com/competitions/cmi-detect-behavior-with-sensor-data/discussion/583080), I shared how to estimate acceleration in world coordinates (i.e., real-world coordinates).  \nAs a next step, we can go further to estimate the **velocity and position** of the sensors in the world coordinate system.\n\n- Notebook: https://www.kaggle.com/code/tatamikenn/eda-drift-in-velocity-position-estimate\n\n## Background\n\nIn theory, velocity and position are computed as cumulative sums of acceleration and velocity, respectively, as follows:\n\n```python\ngravity = np.array([0, 0, 9.81])\nacc_linear = acc_world - gravity\n\nvelocity_linear = np.cumsum(acc_linear * dt, axis=0)\nposition_linear = np.cumsum(velocity_linear * dt, axis=0)\n```\n\nHowever, in practice, the estimated velocity and position are **very prone to noise**, commonly referred to as **drift**.\nThis drift accumulates over time as the measurement continues.\n\n## Example\n\nLet's take a look at an example sequence.\n\nThe first graph below shows that the estimated position drifts **up to 20 meters** away from the initial position — clearly an unrealistic scale of error.\n\nA naive but often effective approach is to **reset the drift** when we are confident that the subject is in a static state.\nIn this competition, labels like `Hand at target location` or `Performs gesture` can be useful indicators of such static states.\n\nThe second graph shows the estimated velocity and position **after drift correction** at the beginning of the `Gesture` phase.\n\nThis time, the final position of the sensor is about **50 cm** away from the initial point.\nThe drift is significantly smaller and within what we could consider a more **realistic range**.\n\nThat said, **some residual drift still remains**, and it may affect ML models — especially during longer gestures.\n\nTherefore, **drift correction techniques**, potentially including ML-based estimation, might be valuable in this competition.\n\n![](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F4910466%2F30acf3967741a1f989e83490874588e3%2FScreenshot%202025-06-08%20at%2019.49.26.png?generation=1749379935002121&alt=media)\n\n![](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F4910466%2F2f72e539c06f7f993b1fc82c12bdda97%2FScreenshot%202025-06-08%20at%2019.49.38.png?generation=1749379954477521&alt=media)",
      "votes": 29
    },
    {
      "id": 3219876,
      "postDate": "2025-06-08T12:49:38.587Z",
      "content": "<p>i think acceleration data is just not granular enough to reconstruct the trajectory. When the sign of acceleration repeatedly changes between adjacent frames you know the data is not granular enough.</p>",
      "rawMarkdown": "i think acceleration data is just not granular enough to reconstruct the trajectory. When the sign of acceleration repeatedly changes between adjacent frames you know the data is not granular enough.",
      "votes": 5,
      "replies": [
        {
          "id": 3219938,
          "postDate": "2025-06-08T14:44:54.633Z",
          "content": "<p>Yes, I agree with that.<br>\nReconstruction using sensor data only can be ill-posed task.<br>\nSo I wander if training with ML model which estimate the hidden error can help capture missing trace.</p>",
          "rawMarkdown": "Yes, I agree with that.\nReconstruction using sensor data only can be ill-posed task.\nSo I wander if training with ML model which estimate the hidden error can help capture missing trace."
        }
      ]
    },
    {
      "id": 3232650,
      "postDate": "2025-06-26T04:24:53.353Z",
      "content": "<p>Hi Blizard , did you got any improvement by incorporating these features into your model?? </p>",
      "rawMarkdown": "Hi Blizard , did you got any improvement by incorporating these features into your model?? ",
      "votes": 1,
      "isDeleted": true
    }
  ],
  "comments": [
    {
      "id": 3219876,
      "author_name": "Youri Matiounine",
      "author_url": "",
      "post_date": "2025-06-08T12:49:38.587000",
      "content": "<p>i think acceleration data is just not granular enough to reconstruct the trajectory. When the sign of acceleration repeatedly changes between adjacent frames you know the data is not granular enough.</p>",
      "votes": 5,
      "replies": [
        {
          "id": 3219938,
          "author_name": "Bilzard",
          "author_url": "",
          "post_date": "2025-06-08T14:44:54.633000",
          "content": "<p>Yes, I agree with that.<br>\nReconstruction using sensor data only can be ill-posed task.<br>\nSo I wander if training with ML model which estimate the hidden error can help capture missing trace.</p>",
          "votes": 0,
          "replies": []
        }
      ]
    },
    {
      "id": 3232650,
      "author_name": "",
      "author_url": "",
      "post_date": "2025-06-26T04:24:53.353000",
      "content": "<p>Hi Blizard , did you got any improvement by incorporating these features into your model?? </p>",
      "votes": 1,
      "replies": []
    }
  ],
  "raw_markdown_by_id": {
    "3219832": "In [the previous topic](https://www.kaggle.com/competitions/cmi-detect-behavior-with-sensor-data/discussion/583080), I shared how to estimate acceleration in world coordinates (i.e., real-world coordinates).  \nAs a next step, we can go further to estimate the **velocity and position** of the sensors in the world coordinate system.\n\n- Notebook: https://www.kaggle.com/code/tatamikenn/eda-drift-in-velocity-position-estimate\n\n## Background\n\nIn theory, velocity and position are computed as cumulative sums of acceleration and velocity, respectively, as follows:\n\n```python\ngravity = np.array([0, 0, 9.81])\nacc_linear = acc_world - gravity\n\nvelocity_linear = np.cumsum(acc_linear * dt, axis=0)\nposition_linear = np.cumsum(velocity_linear * dt, axis=0)\n```\n\nHowever, in practice, the estimated velocity and position are **very prone to noise**, commonly referred to as **drift**.\nThis drift accumulates over time as the measurement continues.\n\n## Example\n\nLet's take a look at an example sequence.\n\nThe first graph below shows that the estimated position drifts **up to 20 meters** away from the initial position — clearly an unrealistic scale of error.\n\nA naive but often effective approach is to **reset the drift** when we are confident that the subject is in a static state.\nIn this competition, labels like `Hand at target location` or `Performs gesture` can be useful indicators of such static states.\n\nThe second graph shows the estimated velocity and position **after drift correction** at the beginning of the `Gesture` phase.\n\nThis time, the final position of the sensor is about **50 cm** away from the initial point.\nThe drift is significantly smaller and within what we could consider a more **realistic range**.\n\nThat said, **some residual drift still remains**, and it may affect ML models — especially during longer gestures.\n\nTherefore, **drift correction techniques**, potentially including ML-based estimation, might be valuable in this competition.\n\n![](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F4910466%2F30acf3967741a1f989e83490874588e3%2FScreenshot%202025-06-08%20at%2019.49.26.png?generation=1749379935002121&alt=media)\n\n![](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F4910466%2F2f72e539c06f7f993b1fc82c12bdda97%2FScreenshot%202025-06-08%20at%2019.49.38.png?generation=1749379954477521&alt=media)",
    "3219876": "i think acceleration data is just not granular enough to reconstruct the trajectory. When the sign of acceleration repeatedly changes between adjacent frames you know the data is not granular enough.",
    "3232650": "Hi Blizard , did you got any improvement by incorporating these features into your model?? "
  }
}