{
  "id": 583388,
  "title": "Geometric Structure of IMU data",
  "url": "/competitions/cmi-detect-behavior-with-sensor-data/discussion/583388",
  "author_name": "",
  "post_date": "2025-06-06T13:24:18.556101Z",
  "votes": 17,
  "comment_count": 5,
  "views": 0,
  "content": "<p>I was thinking about feature extraction from IMU data, and here are some of my thoughts that others might find useful.</p>\n<h1>The Nature of IMU Data</h1>\n<h2>1. Acceleration</h2>\n<p>The acceleration data is presented in the columns <code>acc_[x/y/z]</code>. These are simply vectors in ℝ³ (3D Euclidean space) and can be treated as a point cloud. The distance metric between them is the ordinary Euclidean norm. There’s nothing particularly complex about them, but as mentioned <a href=\"https://www.kaggle.com/competitions/cmi-detect-behavior-with-sensor-data/discussion/583080\" target=\"_blank\">here</a>, it might be beneficial to change the coordinate system.</p>\n<h2>2. Rotation</h2>\n<p>There are four columns related to rotation: <code>rot_[w/x/y/z]</code>. These are not ordinary vectors—they are quaternions. They lie on the S³ (a 4D sphere) and satisfy the equation w² + x² + y² + z² = 1. Unlike vectors in ℝ³, quaternions require a geodesic distance metric to properly measure differences in orientation. Using Euclidean distance here distorts the intrinsic geometry of the data.</p>\n<h1>And what of that?</h1>\n<p>Merging these features directly into a 7D vector introduces several problems:</p>\n<ol>\n<li><strong>Metric mismatch</strong>: Euclidean distance is invalid for quaternions, as it ignores the curvature of S³.</li>\n<li><strong>Topological distortion</strong>: Quaternions describe a curved space, and forcing them into ℝ⁴ breaks their rotational semantics.</li>\n</ol>\n<p>Blindly feeding this data into an ML model should work <em>okay</em>, but in my opinion, it’s not the most optimal approach. If we naively concatenate these features, we’ll likely lose information about orientation—especially if one intends to use <em>graphs, hypergraphs, simplicial complexes, or similar structures,</em> as this could deform the underlying topological structure of the data.</p>\n<p>Also note that quaternions are already kind of LayerNormalized, and since the data itself is a sequence, acceleration should be LayerNormalized too, especially if one uses Neural Nets.</p>\n<h1>Suggestion</h1>\n<p>To preserve the inherent properties of the data, I suggest extracting features from acceleration and rotation separately rather than merging them carelessly.</p>",
  "messages": [
    {
      "id": "3218635",
      "postDate": "06/06/2025 13:24:18",
      "content": "<p>I was thinking about feature extraction from IMU data, and here are some of my thoughts that others might find useful.</p>\n<h1>The Nature of IMU Data</h1>\n<h2>1. Acceleration</h2>\n<p>The acceleration data is presented in the columns <code>acc_[x/y/z]</code>. These are simply vectors in ℝ³ (3D Euclidean space) and can be treated as a point cloud. The distance metric between them is the ordinary Euclidean norm. There’s nothing particularly complex about them, but as mentioned <a href=\"https://www.kaggle.com/competitions/cmi-detect-behavior-with-sensor-data/discussion/583080\" target=\"_blank\">here</a>, it might be beneficial to change the coordinate system.</p>\n<h2>2. Rotation</h2>\n<p>There are four columns related to rotation: <code>rot_[w/x/y/z]</code>. These are not ordinary vectors—they are quaternions. They lie on the S³ (a 4D sphere) and satisfy the equation w² + x² + y² + z² = 1. Unlike vectors in ℝ³, quaternions require a geodesic distance metric to properly measure differences in orientation. Using Euclidean distance here distorts the intrinsic geometry of the data.</p>\n<h1>And what of that?</h1>\n<p>Merging these features directly into a 7D vector introduces several problems:</p>\n<ol>\n<li><strong>Metric mismatch</strong>: Euclidean distance is invalid for quaternions, as it ignores the curvature of S³.</li>\n<li><strong>Topological distortion</strong>: Quaternions describe a curved space, and forcing them into ℝ⁴ breaks their rotational semantics.</li>\n</ol>\n<p>Blindly feeding this data into an ML model should work <em>okay</em>, but in my opinion, it’s not the most optimal approach. If we naively concatenate these features, we’ll likely lose information about orientation—especially if one intends to use <em>graphs, hypergraphs, simplicial complexes, or similar structures,</em> as this could deform the underlying topological structure of the data.</p>\n<p>Also note that quaternions are already kind of LayerNormalized, and since the data itself is a sequence, acceleration should be LayerNormalized too, especially if one uses Neural Nets.</p>\n<h1>Suggestion</h1>\n<p>To preserve the inherent properties of the data, I suggest extracting features from acceleration and rotation separately rather than merging them carelessly.</p>",
      "rawMarkdown": "I was thinking about feature extraction from IMU data, and here are some of my thoughts that others might find useful.\n\n# The Nature of IMU Data\n## 1. Acceleration\n\nThe acceleration data is presented in the columns `acc_[x/y/z]`. These are simply vectors in ℝ³ (3D Euclidean space) and can be treated as a point cloud. The distance metric between them is the ordinary Euclidean norm. There’s nothing particularly complex about them, but as mentioned [here](https://www.kaggle.com/competitions/cmi-detect-behavior-with-sensor-data/discussion/583080), it might be beneficial to change the coordinate system.\n\n## 2. Rotation\n\nThere are four columns related to rotation: `rot_[w/x/y/z]`. These are not ordinary vectors—they are quaternions. They lie on the S³ (a 4D sphere) and satisfy the equation w² + x² + y² + z² = 1. Unlike vectors in ℝ³, quaternions require a geodesic distance metric to properly measure differences in orientation. Using Euclidean distance here distorts the intrinsic geometry of the data.\n\n# And what of that?\nMerging these features directly into a 7D vector introduces several problems:\n1. **Metric mismatch**: Euclidean distance is invalid for quaternions, as it ignores the curvature of S³.\n2. **Topological distortion**: Quaternions describe a curved space, and forcing them into ℝ⁴ breaks their rotational semantics.\n\nBlindly feeding this data into an ML model should work *okay*, but in my opinion, it’s not the most optimal approach. If we naively concatenate these features, we’ll likely lose information about orientation—especially if one intends to use *graphs, hypergraphs, simplicial complexes, or similar structures,* as this could deform the underlying topological structure of the data.\n\nAlso note that quaternions are already kind of LayerNormalized, and since the data itself is a sequence, acceleration should be LayerNormalized too, especially if one uses Neural Nets.\n\n# Suggestion\nTo preserve the inherent properties of the data, I suggest extracting features from acceleration and rotation separately rather than merging them carelessly.",
      "votes": null
    },
    {
      "id": "3218685",
      "postDate": "06/06/2025 15:08:17",
      "content": "<p>rotation is more about the angles i think, and it's best compared to euler angles and  (edit: it depends on the context) and what problem quaternions fixes. </p>\n<p>and acceleration data can be used to create geometric spaces, each geometric space can be distinct enough to describe one of the 18 behaviors. </p>",
      "rawMarkdown": "rotation is more about the angles i think, and it's best compared to euler angles and ~~why euler angles suck~~ (edit: it depends on the context) and what problem quaternions fixes. \n\nand acceleration data can be used to create geometric spaces, each geometric space can be distinct enough to describe one of the 18 behaviors.",
      "votes": null
    },
    {
      "id": "3218697",
      "postDate": "06/06/2025 15:30:46",
      "content": "<p>Don’t we lose information when we convert quaternions into Euler angles? It’s true that it’s purely about angles, so we can encode the distance between quaternions using geodesic distance instead of euler angles. The point of the post was to show that if we simply concatenate these features into ℝ⁷, we lose information. Correct me if I’m wrong.  </p>\n<p>About acceleration—true enough, but since we have information about rotation, why don’t we use it?  </p>\n<p>Actually, I was thinking of building a Vietoris-Rips filtration on a simplicial complex for each sequence and calculating persistent homology. While thinking about it, I concluded that it might not be a good idea to mix acceleration and rotation, since the spaces they lie in are very different. Of course, we could use a combined distance metric—say, Euclidean for the first three coordinates and geodesic for the remaining four—but processing them separately seems like a better approach to me.</p>\n<p><a href=\"https://www.kaggle.com/jaejohn\" target=\"_blank\">@jaejohn</a> </p>",
      "rawMarkdown": "Don’t we lose information when we convert quaternions into Euler angles? It’s true that it’s purely about angles, so we can encode the distance between quaternions using geodesic distance instead of euler angles. The point of the post was to show that if we simply concatenate these features into ℝ⁷, we lose information. Correct me if I’m wrong.  \n\nAbout acceleration—true enough, but since we have information about rotation, why don’t we use it?  \n\nActually, I was thinking of building a Vietoris-Rips filtration on a simplicial complex for each sequence and calculating persistent homology. While thinking about it, I concluded that it might not be a good idea to mix acceleration and rotation, since the spaces they lie in are very different. Of course, we could use a combined distance metric—say, Euclidean for the first three coordinates and geodesic for the remaining four—but processing them separately seems like a better approach to me.\n\n@jaejohn",
      "votes": null
    },
    {
      "id": "3218728",
      "postDate": "06/06/2025 16:20:17",
      "content": "<p>i was building on your idea that acceleration and rotation data live in different geometrical spaces, but coming from a dynamical systems approach. and we surely need to use both in some way (depends on the approach).</p>",
      "rawMarkdown": "i was building on your idea that acceleration and rotation data live in different geometrical spaces, but coming from a dynamical systems approach. and we surely need to use both in some way (depends on the approach).",
      "votes": null
    },
    {
      "id": "3218742",
      "postDate": "06/06/2025 16:39:47",
      "content": "<p>something about Takens's theorem or what? not really acquainted with dynamical systems tbh</p>",
      "rawMarkdown": "something about Takens's theorem or what? not really acquainted with dynamical systems tbh",
      "votes": null
    },
    {
      "id": "3218747",
      "postDate": "06/06/2025 16:48:22",
      "content": "<p>yeah, and i think topological approach can be a great complement to dynamical systems approach, vice versa. </p>",
      "rawMarkdown": "yeah, and i think topological approach can be a great complement to dynamical systems approach, vice versa.",
      "votes": null
    }
  ],
  "comments": [
    {
      "id": 3218685,
      "author_name": "jaejohn",
      "author_url": "",
      "post_date": "06/06/2025 15:08:17",
      "content": "<p>rotation is more about the angles i think, and it's best compared to euler angles and  (edit: it depends on the context) and what problem quaternions fixes. </p>\n<p>and acceleration data can be used to create geometric spaces, each geometric space can be distinct enough to describe one of the 18 behaviors. </p>",
      "votes": null,
      "replies": [
        {
          "id": 3218697,
          "author_name": "eikyou",
          "author_url": "",
          "post_date": "06/06/2025 15:30:46",
          "content": "<p>Don’t we lose information when we convert quaternions into Euler angles? It’s true that it’s purely about angles, so we can encode the distance between quaternions using geodesic distance instead of euler angles. The point of the post was to show that if we simply concatenate these features into ℝ⁷, we lose information. Correct me if I’m wrong.  </p>\n<p>About acceleration—true enough, but since we have information about rotation, why don’t we use it?  </p>\n<p>Actually, I was thinking of building a Vietoris-Rips filtration on a simplicial complex for each sequence and calculating persistent homology. While thinking about it, I concluded that it might not be a good idea to mix acceleration and rotation, since the spaces they lie in are very different. Of course, we could use a combined distance metric—say, Euclidean for the first three coordinates and geodesic for the remaining four—but processing them separately seems like a better approach to me.</p>\n<p><a href=\"https://www.kaggle.com/jaejohn\" target=\"_blank\">@jaejohn</a> </p>",
          "votes": null,
          "replies": [
            {
              "id": 3218728,
              "author_name": "jaejohn",
              "author_url": "",
              "post_date": "06/06/2025 16:20:17",
              "content": "<p>i was building on your idea that acceleration and rotation data live in different geometrical spaces, but coming from a dynamical systems approach. and we surely need to use both in some way (depends on the approach).</p>",
              "votes": null,
              "replies": [
                {
                  "id": 3218742,
                  "author_name": "eikyou",
                  "author_url": "",
                  "post_date": "06/06/2025 16:39:47",
                  "content": "<p>something about Takens's theorem or what? not really acquainted with dynamical systems tbh</p>",
                  "votes": null,
                  "replies": [
                    {
                      "id": 3218747,
                      "author_name": "jaejohn",
                      "author_url": "",
                      "post_date": "06/06/2025 16:48:22",
                      "content": "<p>yeah, and i think topological approach can be a great complement to dynamical systems approach, vice versa. </p>",
                      "votes": null,
                      "replies": []
                    }
                  ]
                }
              ]
            }
          ]
        }
      ]
    }
  ],
  "raw_markdown_by_id": {
    "3218635": "I was thinking about feature extraction from IMU data, and here are some of my thoughts that others might find useful.\n\n# The Nature of IMU Data\n## 1. Acceleration\n\nThe acceleration data is presented in the columns `acc_[x/y/z]`. These are simply vectors in ℝ³ (3D Euclidean space) and can be treated as a point cloud. The distance metric between them is the ordinary Euclidean norm. There’s nothing particularly complex about them, but as mentioned [here](https://www.kaggle.com/competitions/cmi-detect-behavior-with-sensor-data/discussion/583080), it might be beneficial to change the coordinate system.\n\n## 2. Rotation\n\nThere are four columns related to rotation: `rot_[w/x/y/z]`. These are not ordinary vectors—they are quaternions. They lie on the S³ (a 4D sphere) and satisfy the equation w² + x² + y² + z² = 1. Unlike vectors in ℝ³, quaternions require a geodesic distance metric to properly measure differences in orientation. Using Euclidean distance here distorts the intrinsic geometry of the data.\n\n# And what of that?\nMerging these features directly into a 7D vector introduces several problems:\n1. **Metric mismatch**: Euclidean distance is invalid for quaternions, as it ignores the curvature of S³.\n2. **Topological distortion**: Quaternions describe a curved space, and forcing them into ℝ⁴ breaks their rotational semantics.\n\nBlindly feeding this data into an ML model should work *okay*, but in my opinion, it’s not the most optimal approach. If we naively concatenate these features, we’ll likely lose information about orientation—especially if one intends to use *graphs, hypergraphs, simplicial complexes, or similar structures,* as this could deform the underlying topological structure of the data.\n\nAlso note that quaternions are already kind of LayerNormalized, and since the data itself is a sequence, acceleration should be LayerNormalized too, especially if one uses Neural Nets.\n\n# Suggestion\nTo preserve the inherent properties of the data, I suggest extracting features from acceleration and rotation separately rather than merging them carelessly.",
    "3218685": "rotation is more about the angles i think, and it's best compared to euler angles and ~~why euler angles suck~~ (edit: it depends on the context) and what problem quaternions fixes. \n\nand acceleration data can be used to create geometric spaces, each geometric space can be distinct enough to describe one of the 18 behaviors.",
    "3218697": "Don’t we lose information when we convert quaternions into Euler angles? It’s true that it’s purely about angles, so we can encode the distance between quaternions using geodesic distance instead of euler angles. The point of the post was to show that if we simply concatenate these features into ℝ⁷, we lose information. Correct me if I’m wrong.  \n\nAbout acceleration—true enough, but since we have information about rotation, why don’t we use it?  \n\nActually, I was thinking of building a Vietoris-Rips filtration on a simplicial complex for each sequence and calculating persistent homology. While thinking about it, I concluded that it might not be a good idea to mix acceleration and rotation, since the spaces they lie in are very different. Of course, we could use a combined distance metric—say, Euclidean for the first three coordinates and geodesic for the remaining four—but processing them separately seems like a better approach to me.\n\n@jaejohn",
    "3218728": "i was building on your idea that acceleration and rotation data live in different geometrical spaces, but coming from a dynamical systems approach. and we surely need to use both in some way (depends on the approach).",
    "3218742": "something about Takens's theorem or what? not really acquainted with dynamical systems tbh",
    "3218747": "yeah, and i think topological approach can be a great complement to dynamical systems approach, vice versa."
  },
  "source": "meta"
}