{
  "id": 591323,
  "title": " What is your IMU sensor value clipping ranges for numerical stability?",
  "url": "/competitions/cmi-detect-behavior-with-sensor-data/discussion/591323",
  "author_name": "",
  "post_date": "2025-07-27T05:45:54.508968100Z",
  "votes": 8,
  "comment_count": 4,
  "views": 0,
  "content": "<p>Hi everyone,</p>\n<p>I wanted to start a discussion about preprocessing strategies, specifically regarding <strong>IMU sensor value clipping ranges</strong>. I've noticed that raw IMU data can sometimes contain extreme outliers or physically implausible values that can cause numerical instability during training.</p>\n<h2>My Current Approach</h2>\n<p>In my preprocessing pipeline, I'm applying the following clipping ranges:</p>\n<pre><code>\nacc_data = np.clip(acc_data, -, )\n\n\ngyro_data = np.clip(gyro_data, -, )\n\n\njerk = np.clip(np.diff(acc_data, axis=), -, )\n\n\n\nacc_normalized = (acc_clipped - acc_mean) / (acc_std + )\n\n</code></pre>\n<h2>Rationale</h2>\n<p>These ranges are based on:</p>\n<ul>\n<li><strong>Acceleration</strong>: ±50 m/s² (~5g) seems reasonable for wrist-worn devices during BFRB gestures</li>\n<li><strong>Angular velocity</strong>: ±10 rad/s covers most human wrist rotations</li>\n<li><strong>Jerk</strong>: ±20 m/s³ for smooth human motion constraints</li>\n</ul>\n<h2>Questions for the Community</h2>\n<ol>\n<li><strong>What clipping ranges are you using</strong> for IMU sensors (if any)?</li>\n<li><strong>Have you found that clipping helps or hurts</strong> your model performance?</li>\n<li><strong>Alternative approaches</strong>: Are you using other outlier handling methods instead of hard clipping?<ul>\n<li>Percentile-based clipping (e.g., 1st-99th percentile)?</li>\n<li>Z-score based filtering?</li>\n<li>Robust scaling without clipping?</li></ul></li>\n<li><strong>Normalization strategies</strong>: If you're normalizing after clipping, what ranges are you using?<ul>\n<li>Standard normalization to [-1, 1] or [0, 1]?</li>\n<li>Per-channel statistics (mean/std) or global?</li>\n<li>Different normalization for different sensor types?</li></ul></li>\n</ol>\n<h2>Observations</h2>\n<p>I've noticed that without clipping:</p>\n<ul>\n<li>Training becomes unstable with NaN losses</li>\n<li>Model predictions become overconfident on outlier samples</li>\n</ul>\n<p>But with too aggressive clipping:</p>\n<ul>\n<li>We might lose important gesture dynamics</li>\n<li>The model might not generalize well to test data</li>\n</ul>\n<p><strong>My current normalization stats (after clipping):</strong></p>\n<ul>\n<li>Acceleration mean: ~[0.1, -0.2, 9.5] (gravity visible in z-axis)</li>\n<li>Acceleration std: ~[2.5, 2.8, 3.1]</li>\n<li>Final normalized range: roughly [-3, 3] for most values</li>\n</ul>\n<h2>Additional Considerations</h2>\n<p>Since the competition mentions that <strong>50% of test data is IMU-only</strong>, getting the IMU preprocessing right seems crucial. I'm particularly interested in whether others have found sensor-specific calibration or normalization strategies that work well.</p>\n<p>Would love to hear your thoughts and experiences! </p>\n<p><strong>Related question</strong>: Has anyone analyzed the IMU data distribution to determine if there are sensor-specific biases or drift patterns we should account for?</p>\n<p><strong>Impact on performance</strong>: With proper clipping and normalization, I've been able to achieve stable training and F1 scores around 0.55-0.65 on validation. Without clipping, I was getting NaN losses after just a few epochs.</p>",
  "messages": [
    {
      "id": "3254734",
      "postDate": "07/27/2025 05:45:54",
      "content": "<p>Hi everyone,</p>\n<p>I wanted to start a discussion about preprocessing strategies, specifically regarding <strong>IMU sensor value clipping ranges</strong>. I've noticed that raw IMU data can sometimes contain extreme outliers or physically implausible values that can cause numerical instability during training.</p>\n<h2>My Current Approach</h2>\n<p>In my preprocessing pipeline, I'm applying the following clipping ranges:</p>\n<pre><code>\nacc_data = np.clip(acc_data, -, )\n\n\ngyro_data = np.clip(gyro_data, -, )\n\n\njerk = np.clip(np.diff(acc_data, axis=), -, )\n\n\n\nacc_normalized = (acc_clipped - acc_mean) / (acc_std + )\n\n</code></pre>\n<h2>Rationale</h2>\n<p>These ranges are based on:</p>\n<ul>\n<li><strong>Acceleration</strong>: ±50 m/s² (~5g) seems reasonable for wrist-worn devices during BFRB gestures</li>\n<li><strong>Angular velocity</strong>: ±10 rad/s covers most human wrist rotations</li>\n<li><strong>Jerk</strong>: ±20 m/s³ for smooth human motion constraints</li>\n</ul>\n<h2>Questions for the Community</h2>\n<ol>\n<li><strong>What clipping ranges are you using</strong> for IMU sensors (if any)?</li>\n<li><strong>Have you found that clipping helps or hurts</strong> your model performance?</li>\n<li><strong>Alternative approaches</strong>: Are you using other outlier handling methods instead of hard clipping?<ul>\n<li>Percentile-based clipping (e.g., 1st-99th percentile)?</li>\n<li>Z-score based filtering?</li>\n<li>Robust scaling without clipping?</li></ul></li>\n<li><strong>Normalization strategies</strong>: If you're normalizing after clipping, what ranges are you using?<ul>\n<li>Standard normalization to [-1, 1] or [0, 1]?</li>\n<li>Per-channel statistics (mean/std) or global?</li>\n<li>Different normalization for different sensor types?</li></ul></li>\n</ol>\n<h2>Observations</h2>\n<p>I've noticed that without clipping:</p>\n<ul>\n<li>Training becomes unstable with NaN losses</li>\n<li>Model predictions become overconfident on outlier samples</li>\n</ul>\n<p>But with too aggressive clipping:</p>\n<ul>\n<li>We might lose important gesture dynamics</li>\n<li>The model might not generalize well to test data</li>\n</ul>\n<p><strong>My current normalization stats (after clipping):</strong></p>\n<ul>\n<li>Acceleration mean: ~[0.1, -0.2, 9.5] (gravity visible in z-axis)</li>\n<li>Acceleration std: ~[2.5, 2.8, 3.1]</li>\n<li>Final normalized range: roughly [-3, 3] for most values</li>\n</ul>\n<h2>Additional Considerations</h2>\n<p>Since the competition mentions that <strong>50% of test data is IMU-only</strong>, getting the IMU preprocessing right seems crucial. I'm particularly interested in whether others have found sensor-specific calibration or normalization strategies that work well.</p>\n<p>Would love to hear your thoughts and experiences! </p>\n<p><strong>Related question</strong>: Has anyone analyzed the IMU data distribution to determine if there are sensor-specific biases or drift patterns we should account for?</p>\n<p><strong>Impact on performance</strong>: With proper clipping and normalization, I've been able to achieve stable training and F1 scores around 0.55-0.65 on validation. Without clipping, I was getting NaN losses after just a few epochs.</p>",
      "rawMarkdown": "Hi everyone,\n\nI wanted to start a discussion about preprocessing strategies, specifically regarding **IMU sensor value clipping ranges**. I've noticed that raw IMU data can sometimes contain extreme outliers or physically implausible values that can cause numerical instability during training.\n\n## My Current Approach\n\nIn my preprocessing pipeline, I'm applying the following clipping ranges:\n\n```python\n# Acceleration (m/s²)\nacc_data = np.clip(acc_data, -50, 50)\n\n# Angular velocity (rad/s) - derived from quaternions\ngyro_data = np.clip(gyro_data, -10, 10)\n\n# Jerk (m/s³) - first derivative of acceleration\njerk = np.clip(np.diff(acc_data, axis=1), -20, 20)\n\n# After clipping, I normalize the features\n# Example for acceleration:\nacc_normalized = (acc_clipped - acc_mean) / (acc_std + 1e-6)\n# where acc_mean and acc_std are computed from training data\n```\n\n## Rationale\n\nThese ranges are based on:\n- **Acceleration**: ±50 m/s² (~5g) seems reasonable for wrist-worn devices during BFRB gestures\n- **Angular velocity**: ±10 rad/s covers most human wrist rotations\n- **Jerk**: ±20 m/s³ for smooth human motion constraints\n\n## Questions for the Community\n\n1. **What clipping ranges are you using** for IMU sensors (if any)?\n2. **Have you found that clipping helps or hurts** your model performance?\n3. **Alternative approaches**: Are you using other outlier handling methods instead of hard clipping?\n   - Percentile-based clipping (e.g., 1st-99th percentile)?\n   - Z-score based filtering?\n   - Robust scaling without clipping?\n4. **Normalization strategies**: If you're normalizing after clipping, what ranges are you using?\n   - Standard normalization to [-1, 1] or [0, 1]?\n   - Per-channel statistics (mean/std) or global?\n   - Different normalization for different sensor types?\n\n## Observations\n\nI've noticed that without clipping:\n- Training becomes unstable with NaN losses\n- Model predictions become overconfident on outlier samples\n\nBut with too aggressive clipping:\n- We might lose important gesture dynamics\n- The model might not generalize well to test data\n\n**My current normalization stats (after clipping):**\n- Acceleration mean: ~[0.1, -0.2, 9.5] (gravity visible in z-axis)\n- Acceleration std: ~[2.5, 2.8, 3.1]\n- Final normalized range: roughly [-3, 3] for most values\n\n## Additional Considerations\n\nSince the competition mentions that **50% of test data is IMU-only**, getting the IMU preprocessing right seems crucial. I'm particularly interested in whether others have found sensor-specific calibration or normalization strategies that work well.\n\nWould love to hear your thoughts and experiences! \n\n**Related question**: Has anyone analyzed the IMU data distribution to determine if there are sensor-specific biases or drift patterns we should account for?\n\n**Impact on performance**: With proper clipping and normalization, I've been able to achieve stable training and F1 scores around 0.55-0.65 on validation. Without clipping, I was getting NaN losses after just a few epochs.",
      "votes": null
    },
    {
      "id": "3254805",
      "postDate": "07/27/2025 09:05:35",
      "content": "<p>I think most public models do not clip, and they have no nan problem.  </p>",
      "rawMarkdown": "I think most public models do not clip, and they have no nan problem.",
      "votes": null
    },
    {
      "id": "3254822",
      "postDate": "07/27/2025 09:49:25",
      "content": "<p>\"Some sequences have acceleration spikes up to 9000+ m/s² (clearly sensor errors)\" what?</p>",
      "rawMarkdown": "\"Some sequences have acceleration spikes up to 9000+ m/s² (clearly sensor errors)\" what?",
      "votes": null
    },
    {
      "id": "3254829",
      "postDate": "07/27/2025 10:01:58",
      "content": "<p>sorry my mistake delete this sentene</p>",
      "rawMarkdown": "sorry my mistake delete this sentene",
      "votes": null
    },
    {
      "id": "3254835",
      "postDate": "07/27/2025 10:10:57",
      "content": "<p>Thank you for your detailed comment! It seems there might be some issues with my implementation. I really appreciate you taking the time to share your approach and insights.</p>",
      "rawMarkdown": "Thank you for your detailed comment! It seems there might be some issues with my implementation. I really appreciate you taking the time to share your approach and insights.",
      "votes": null
    }
  ],
  "comments": [
    {
      "id": 3254805,
      "author_name": "shlomoron",
      "author_url": "",
      "post_date": "07/27/2025 09:05:35",
      "content": "<p>I think most public models do not clip, and they have no nan problem.  </p>",
      "votes": null,
      "replies": [
        {
          "id": 3254835,
          "author_name": "ryota040",
          "author_url": "",
          "post_date": "07/27/2025 10:10:57",
          "content": "<p>Thank you for your detailed comment! It seems there might be some issues with my implementation. I really appreciate you taking the time to share your approach and insights.</p>",
          "votes": null,
          "replies": []
        }
      ]
    },
    {
      "id": 3254822,
      "author_name": "celiker",
      "author_url": "",
      "post_date": "07/27/2025 09:49:25",
      "content": "<p>\"Some sequences have acceleration spikes up to 9000+ m/s² (clearly sensor errors)\" what?</p>",
      "votes": null,
      "replies": [
        {
          "id": 3254829,
          "author_name": "ryota040",
          "author_url": "",
          "post_date": "07/27/2025 10:01:58",
          "content": "<p>sorry my mistake delete this sentene</p>",
          "votes": null,
          "replies": []
        }
      ]
    }
  ],
  "raw_markdown_by_id": {
    "3254734": "Hi everyone,\n\nI wanted to start a discussion about preprocessing strategies, specifically regarding **IMU sensor value clipping ranges**. I've noticed that raw IMU data can sometimes contain extreme outliers or physically implausible values that can cause numerical instability during training.\n\n## My Current Approach\n\nIn my preprocessing pipeline, I'm applying the following clipping ranges:\n\n```python\n# Acceleration (m/s²)\nacc_data = np.clip(acc_data, -50, 50)\n\n# Angular velocity (rad/s) - derived from quaternions\ngyro_data = np.clip(gyro_data, -10, 10)\n\n# Jerk (m/s³) - first derivative of acceleration\njerk = np.clip(np.diff(acc_data, axis=1), -20, 20)\n\n# After clipping, I normalize the features\n# Example for acceleration:\nacc_normalized = (acc_clipped - acc_mean) / (acc_std + 1e-6)\n# where acc_mean and acc_std are computed from training data\n```\n\n## Rationale\n\nThese ranges are based on:\n- **Acceleration**: ±50 m/s² (~5g) seems reasonable for wrist-worn devices during BFRB gestures\n- **Angular velocity**: ±10 rad/s covers most human wrist rotations\n- **Jerk**: ±20 m/s³ for smooth human motion constraints\n\n## Questions for the Community\n\n1. **What clipping ranges are you using** for IMU sensors (if any)?\n2. **Have you found that clipping helps or hurts** your model performance?\n3. **Alternative approaches**: Are you using other outlier handling methods instead of hard clipping?\n   - Percentile-based clipping (e.g., 1st-99th percentile)?\n   - Z-score based filtering?\n   - Robust scaling without clipping?\n4. **Normalization strategies**: If you're normalizing after clipping, what ranges are you using?\n   - Standard normalization to [-1, 1] or [0, 1]?\n   - Per-channel statistics (mean/std) or global?\n   - Different normalization for different sensor types?\n\n## Observations\n\nI've noticed that without clipping:\n- Training becomes unstable with NaN losses\n- Model predictions become overconfident on outlier samples\n\nBut with too aggressive clipping:\n- We might lose important gesture dynamics\n- The model might not generalize well to test data\n\n**My current normalization stats (after clipping):**\n- Acceleration mean: ~[0.1, -0.2, 9.5] (gravity visible in z-axis)\n- Acceleration std: ~[2.5, 2.8, 3.1]\n- Final normalized range: roughly [-3, 3] for most values\n\n## Additional Considerations\n\nSince the competition mentions that **50% of test data is IMU-only**, getting the IMU preprocessing right seems crucial. I'm particularly interested in whether others have found sensor-specific calibration or normalization strategies that work well.\n\nWould love to hear your thoughts and experiences! \n\n**Related question**: Has anyone analyzed the IMU data distribution to determine if there are sensor-specific biases or drift patterns we should account for?\n\n**Impact on performance**: With proper clipping and normalization, I've been able to achieve stable training and F1 scores around 0.55-0.65 on validation. Without clipping, I was getting NaN losses after just a few epochs.",
    "3254805": "I think most public models do not clip, and they have no nan problem.",
    "3254822": "\"Some sequences have acceleration spikes up to 9000+ m/s² (clearly sensor errors)\" what?",
    "3254829": "sorry my mistake delete this sentene",
    "3254835": "Thank you for your detailed comment! It seems there might be some issues with my implementation. I really appreciate you taking the time to share your approach and insights."
  },
  "source": "meta"
}