![\"\"](\"https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F4910466%2F6f4fbc29e3e24e15e51ca96adb4e44f9%2FScreenshot%202025-06-04%20at%2023.54.19.png?generation=1749048894095118&alt=media\")
I’d like to share a few tips that might be useful.
\nThe sensor data is originally recorded in the device’s coordinate system (i.e., relative to the position and orientation of the wrist-worn device).
\nHowever, I believe that converting the data to a world coordinate system (i.e., relative to the real world) can make it more interpretable and possibly better feature representation.
Here’s the code I used to convert sensor data into world coordinates:
\n scipy.spatial.transform Rotation R\n\n ():\n \n \n r = R.from_quat(rot) \n acc_world = r.apply(acc)\n acc_world\nThe plot below shows the acceleration in world coordinates.
\nIt looks reasonable — the estimated acceleration appears to include gravitational acceleration (approximately 9.8 m/s²).
\nNote that in this context, gravity should be defined as pointing upward, because the sensor detects acceleration in the direction opposite to the external force (imagine being in a rocket accelerating upward — gravity feels like it pushes down).
I also shared EDA notebook for reproducibility.
\nI’d like to share a few tips that might be useful.
\nThe sensor data is originally recorded in the device’s coordinate system (i.e., relative to the position and orientation of the wrist-worn device).
\nHowever, I believe that converting the data to a world coordinate system (i.e., relative to the real world) can make it more interpretable and possibly better feature representation.
Here’s the code I used to convert sensor data into world coordinates:
\n scipy.spatial.transform Rotation R\n\n ():\n \n \n r = R.from_quat(rot) \n acc_world = r.apply(acc)\n acc_world\nThe plot below shows the acceleration in world coordinates.
\nIt looks reasonable — the estimated acceleration appears to include gravitational acceleration (approximately 9.8 m/s²).
\nNote that in this context, gravity should be defined as pointing upward, because the sensor detects acceleration in the direction opposite to the external force (imagine being in a rocket accelerating upward — gravity feels like it pushes down).
I also shared EDA notebook for reproducibility.
\nOne small caveat: in train data, some sequence_id has completely null rot_* (while acc do not)
This change indeed makes it more interpretative, but what do u mean by 'informative'? ML models don't seem to care about orienation, no? Correct me if i am wrong.
", "rawMarkdown": "This change indeed makes it more interpretative, but what do u mean by 'informative'? ML models don't seem to care about orienation, no? Correct me if i am wrong.", "votes": 2, "replies": [ { "id": 3217333, "postDate": "2025-06-04T22:24:06.503Z", "content": "This competition will likely be decided by feature eng, and this transformation may be neccesary for future more complex features
\nso in a sense clearer representation -> potentially better features -> more informative
makes sense, thx
", "rawMarkdown": "makes sense, thx", "votes": 1 }, { "id": 3217363, "postDate": "2025-06-05T00:06:43.183Z", "content": "@defdet Thank you for the clearer interpretation. Yes, this is exactly what I meant.
", "rawMarkdown": "@defdet Thank you for the clearer interpretation. Yes, this is exactly what I meant.", "votes": 1 } ] }, { "id": 3219551, "postDate": "2025-06-07T23:57:11.953Z", "content": "U can extract features using this like motion trace , velocity , etc. To get more informative features.
\nEx. Converting to world frame + Kalman filtering turns your raw IMU streams into a clean, physically meaningful motion trace
@anasshahmurshad good idea. These information might provides good hidden pattern.
", "rawMarkdown": "@anasshahmurshad good idea. These information might provides good hidden pattern." } ] } ] }, { "id": 3224211, "postDate": "2025-06-14T14:41:24.767Z", "content": "Anyone seeing improvement using this? In my case CV gets worse and even some hyperparameter tuning cannot get it back to where I was without it. Interesting learning though, thanks a mor for sharing! 😊
", "rawMarkdown": "Anyone seeing improvement using this? In my case CV gets worse and even some hyperparameter tuning cannot get it back to where I was without it. Interesting learning though, thanks a mor for sharing! 😊", "replies": [ { "id": 3224331, "postDate": "2025-06-14T17:09:35.707Z", "content": "same thing, at first I thought going to a world coordinate system would really help since sensor location would no longer affect acceleration, but it just made my metrics worse
", "rawMarkdown": "same thing, at first I thought going to a world coordinate system would really help since sensor location would no longer affect acceleration, but it just made my metrics worse", "votes": 4, "replies": [ { "id": 3224457, "postDate": "2025-06-14T22:11:54.400Z", "content": "Thanks for your reply! Good to hear that I am not alone with that observation!
", "rawMarkdown": "Thanks for your reply! Good to hear that I am not alone with that observation! ", "votes": 1 }, { "id": 3224752, "postDate": "2025-06-15T12:09:21.410Z", "content": "same to me😀
", "rawMarkdown": "same to me😀" } ] } ] }, { "id": 3218642, "postDate": "2025-06-06T13:34:10.507Z", "content": "Great insights! Thank you for providing this!
", "rawMarkdown": "Great insights! Thank you for providing this!" }, { "id": 3217648, "postDate": "2025-06-05T08:58:23.730Z", "content": "Great observation.
\nHave you tried the reverse of this, whereby you could estimate the rotational pose from the gravity component of the accelerations? Does your gravity component agree with the given rotational pose within the published IMU error rate?
", "rawMarkdown": "Great observation.\n\nHave you tried the reverse of this, whereby you could estimate the rotational pose from the gravity component of the accelerations? Does your gravity component agree with the given rotational pose within the published IMU error rate? ", "replies": [ { "id": 3217673, "postDate": "2025-06-05T09:39:49.633Z", "rawMarkdown": "", "isDeleted": true } ] } ], "comments": [ { "id": 3221090, "author_name": "Gerwyn", "author_url": "", "post_date": "2025-06-10T11:35:25.237000", "content": "One small caveat: in train data, some sequence_id has completely null rot_* (while acc do not)
This change indeed makes it more interpretative, but what do u mean by 'informative'? ML models don't seem to care about orienation, no? Correct me if i am wrong.
", "votes": 2, "replies": [ { "id": 3217333, "author_name": "ImperfectKitto", "author_url": "", "post_date": "2025-06-04T22:24:06.503000", "content": "This competition will likely be decided by feature eng, and this transformation may be neccesary for future more complex features
\nso in a sense clearer representation -> potentially better features -> more informative
makes sense, thx
", "votes": 1, "replies": [] }, { "id": 3217363, "author_name": "Bilzard", "author_url": "", "post_date": "2025-06-05T00:06:43.183000", "content": "@defdet Thank you for the clearer interpretation. Yes, this is exactly what I meant.
", "votes": 1, "replies": [] } ] }, { "id": 3219551, "author_name": "andyops", "author_url": "", "post_date": "2025-06-07T23:57:11.953000", "content": "U can extract features using this like motion trace , velocity , etc. To get more informative features.
\nEx. Converting to world frame + Kalman filtering turns your raw IMU streams into a clean, physically meaningful motion trace
@anasshahmurshad good idea. These information might provides good hidden pattern.
", "votes": 0, "replies": [] } ] } ] }, { "id": 3224211, "author_name": "Jan Brederecke", "author_url": "", "post_date": "2025-06-14T14:41:24.767000", "content": "Anyone seeing improvement using this? In my case CV gets worse and even some hyperparameter tuning cannot get it back to where I was without it. Interesting learning though, thanks a mor for sharing! 😊
", "votes": 0, "replies": [ { "id": 3224331, "author_name": "lightsource<3", "author_url": "", "post_date": "2025-06-14T17:09:35.707000", "content": "same thing, at first I thought going to a world coordinate system would really help since sensor location would no longer affect acceleration, but it just made my metrics worse
", "votes": 4, "replies": [ { "id": 3224457, "author_name": "Jan Brederecke", "author_url": "", "post_date": "2025-06-14T22:11:54.400000", "content": "Thanks for your reply! Good to hear that I am not alone with that observation!
", "votes": 1, "replies": [] }, { "id": 3224752, "author_name": "Yang Wei Hao", "author_url": "", "post_date": "2025-06-15T12:09:21.410000", "content": "same to me😀
", "votes": 0, "replies": [] } ] } ] }, { "id": 3218642, "author_name": "Tom", "author_url": "", "post_date": "2025-06-06T13:34:10.507000", "content": "Great insights! Thank you for providing this!
", "votes": 0, "replies": [] }, { "id": 3217648, "author_name": "Bijan Rafraf", "author_url": "", "post_date": "2025-06-05T08:58:23.730000", "content": "Great observation.
\nHave you tried the reverse of this, whereby you could estimate the rotational pose from the gravity component of the accelerations? Does your gravity component agree with the given rotational pose within the published IMU error rate?
", "votes": 0, "replies": [ { "id": 3217673, "author_name": "", "author_url": "", "post_date": "2025-06-05T09:39:49.633000", "content": "", "votes": 0, "replies": [] } ] } ], "raw_markdown_by_id": { "3217139": "I’d like to share a few tips that might be useful.\n\nThe sensor data is originally recorded in the device’s coordinate system (i.e., relative to the position and orientation of the wrist-worn device).\nHowever, I believe that converting the data to a **world coordinate system** (i.e., relative to the real world) can make it more **interpretable and possibly better feature representation**.\n\nHere’s the code I used to convert sensor data into world coordinates:\n\n```python\nfrom scipy.spatial.transform import Rotation as R\n\ndef compute_acc_world(acc, rot):\n # acc: [:, x, y, z]\n # rot: [:, x, y, z, w]\n r = R.from_quat(rot) # shape: (M,)\n acc_world = r.apply(acc)\n return acc_world\n```\n\n## Result\n\nThe plot below shows the acceleration in world coordinates.\nIt looks reasonable — the estimated acceleration appears to include gravitational acceleration (approximately 9.8 m/s²).\nNote that in this context, **gravity should be defined as pointing upward**, because the sensor detects acceleration in the direction opposite to the external force (imagine being in a rocket accelerating upward — gravity feels like it pushes down).\n\n\n\n## Reference\n\nI also shared EDA notebook for reproducibility.\n\n- https://www.kaggle.com/code/tatamikenn/cmi-eda-visualize-sample-gestures?scriptVersionId=243712613", "3221090": "One *small* caveat: in train data, some sequence_id has completely null `rot_*` (while acc do not)", "3217294": "This change indeed makes it more interpretative, but what do u mean by 'informative'? ML models don't seem to care about orienation, no? Correct me if i am wrong.", "3224211": "Anyone seeing improvement using this? In my case CV gets worse and even some hyperparameter tuning cannot get it back to where I was without it. Interesting learning though, thanks a mor for sharing! 😊", "3218642": "Great insights! Thank you for providing this!", "3217648": "Great observation.\n\nHave you tried the reverse of this, whereby you could estimate the rotational pose from the gravity component of the accelerations? Does your gravity component agree with the given rotational pose within the published IMU error rate? " } }