Hi,
\nI was very excited about this competition, but couldn't spend much time on it. One of my ideas was to use sequence-2-sequence modelling of IMU sensor features to generate local waypoints. I tried to implement my idea in this notebook
Basic idea is to used encoder decoder architecture with convolutions as follows:
\nEncoder input - Features are IMU data, considering 2D plane, (i.e), timestamps of IMU data, linear acceleration in x,y directions and yaw rate (gyroscope z axis) along with euler angles w.r.t magnetic north.
Decoder input - Timestamp at which waypoint is to be inferred. The inference time is relative to the first imu timestamp.
Decoder output - Local waypoints (i.e) actual waypoint - first waypoint of path. The points are translated such that first waypoint is the origin. This is done because, the imu features give local trajectory (~shape of the path) but by itself cannot infer global trajectory directly.
The encoder and decoder data are made of fixed length. For encoder, the imu data is sampled to be of 100 time sequences. For decoder, the maximum waypoints is fixed at 107 (max number of waypoints in path in train data). More details on data generation can be found at my notebook. Padding is done to ensure equal length in all batches.
\nProblem
\nDue to some issue, the model doesn't seem to learn anything. The loss seems to reduce 0.0x only with each epoch. I have doubts in loss computation (competitionMetric_Seq2Seq). I am not sure if the current implementation is the correct way to calculate loss for padded elements. But this is only guess and I am not sure where the mistake is. If somebody can help me out, it would be great.
Hi,
\nI was very excited about this competition, but couldn't spend much time on it. One of my ideas was to use sequence-2-sequence modelling of IMU sensor features to generate local waypoints. I tried to implement my idea in this notebook
Basic idea is to used encoder decoder architecture with convolutions as follows:
\nEncoder input - Features are IMU data, considering 2D plane, (i.e), timestamps of IMU data, linear acceleration in x,y directions and yaw rate (gyroscope z axis) along with euler angles w.r.t magnetic north.
Decoder input - Timestamp at which waypoint is to be inferred. The inference time is relative to the first imu timestamp.
Decoder output - Local waypoints (i.e) actual waypoint - first waypoint of path. The points are translated such that first waypoint is the origin. This is done because, the imu features give local trajectory (~shape of the path) but by itself cannot infer global trajectory directly.
The encoder and decoder data are made of fixed length. For encoder, the imu data is sampled to be of 100 time sequences. For decoder, the maximum waypoints is fixed at 107 (max number of waypoints in path in train data). More details on data generation can be found at my notebook. Padding is done to ensure equal length in all batches.
\nProblem
\nDue to some issue, the model doesn't seem to learn anything. The loss seems to reduce 0.0x only with each epoch. I have doubts in loss computation (competitionMetric_Seq2Seq). I am not sure if the current implementation is the correct way to calculate loss for padded elements. But this is only guess and I am not sure where the mistake is. If somebody can help me out, it would be great.
As far as we understand from EDA, IMU can not be used to predict waypoints. We did a quite similar thing, using IMU to predict the change in waypoints, but we failed too. We detected that the headings do not seem right (like headings from IMU show the surveyor is going to the North, but he turns to the West). Therefore, I guess using IMU to generate waypoints is similar to using IMU predict waypoints and it would not work (in my opinion). We are still waiting for the top teams to publish their solutions regarding using IMU features.
", "rawMarkdown": "As far as we understand from EDA, IMU can not be used to predict waypoints. We did a quite similar thing, using IMU to predict the change in waypoints, but we failed too. We detected that the headings do not seem right (like headings from IMU show the surveyor is going to the North, but he turns to the West). Therefore, I guess using IMU to generate waypoints is similar to using IMU predict waypoints and it would not work (in my opinion). We are still waiting for the top teams to publish their solutions regarding using IMU features.", "votes": null }, { "id": "1311444", "postDate": "05/17/2021 12:02:28", "content": "I'll publish more info after the competition is over today, but I already wrote up a post about a few tricks for how to use sensor data: https://www.kaggle.com/c/indoor-location-navigation/discussion/236096
\nI think a few of the points there may help with the trouble you're having!
\n[EDIT]: oh, I just realized you've already commented on that post - sorry! I'll be happy to answer specific questions in about 12 hours after the deadline :)
", "rawMarkdown": "I'll publish more info after the competition is over today, but I already wrote up a post about a few tricks for how to use sensor data: https://www.kaggle.com/c/indoor-location-navigation/discussion/236096\n\nI think a few of the points there may help with the trouble you're having! \n\n[EDIT]: oh, I just realized you've already commented on that post - sorry! I'll be happy to answer specific questions in about 12 hours after the deadline :)", "votes": null }, { "id": "1311451", "postDate": "05/17/2021 12:09:46", "content": "Ah, by the way, Chris, actually your tricks help us quite a lot :D, but we still can not use them totally properly, so the improvements were not so impressive.
\nWe are looking for your solutions after the competition.
", "rawMarkdown": "Ah, by the way, Chris, actually your tricks help us quite a lot :D, but we still can not use them totally properly, so the improvements were not so impressive.\n\nWe are looking for your solutions after the competition.", "votes": null }, { "id": "1312244", "postDate": "05/18/2021 00:01:49", "content": "Thanks @shinomoriaoshi for you suggestion. I did try converting the ruler angles from compass to Cartesian co-ordinate system but there's not much luck that way either. Thanks anyway for the comment. Looking forward to learning from Winning solutions
", "rawMarkdown": "Thanks @shinomoriaoshi for you suggestion. I did try converting the ruler angles from compass to Cartesian co-ordinate system but there's not much luck that way either. Thanks anyway for the comment. Looking forward to learning from Winning solutions", "votes": null }, { "id": "1312247", "postDate": "05/18/2021 00:04:03", "content": "Thanks @chris62 for your suggestion. Your suggestions have been very helpful in this competition. I'll go through my code once again keeping those in kind. Waiting to learn from your solution
", "rawMarkdown": "Thanks @chris62 for your suggestion. Your suggestions have been very helpful in this competition. I'll go through my code once again keeping those in kind. Waiting to learn from your solution", "votes": null } ], "comments": [ { "id": 1311295, "author_name": "shinomoriaoshi", "author_url": "", "post_date": "05/17/2021 09:52:54", "content": "As far as we understand from EDA, IMU can not be used to predict waypoints. We did a quite similar thing, using IMU to predict the change in waypoints, but we failed too. We detected that the headings do not seem right (like headings from IMU show the surveyor is going to the North, but he turns to the West). Therefore, I guess using IMU to generate waypoints is similar to using IMU predict waypoints and it would not work (in my opinion). We are still waiting for the top teams to publish their solutions regarding using IMU features.
", "votes": null, "replies": [ { "id": 1311444, "author_name": "chris62", "author_url": "", "post_date": "05/17/2021 12:02:28", "content": "I'll publish more info after the competition is over today, but I already wrote up a post about a few tricks for how to use sensor data: https://www.kaggle.com/c/indoor-location-navigation/discussion/236096
\nI think a few of the points there may help with the trouble you're having!
\n[EDIT]: oh, I just realized you've already commented on that post - sorry! I'll be happy to answer specific questions in about 12 hours after the deadline :)
", "votes": null, "replies": [ { "id": 1312247, "author_name": "suryajrrafl", "author_url": "", "post_date": "05/18/2021 00:04:03", "content": "Thanks @chris62 for your suggestion. Your suggestions have been very helpful in this competition. I'll go through my code once again keeping those in kind. Waiting to learn from your solution
", "votes": null, "replies": [] } ] }, { "id": 1311451, "author_name": "shinomoriaoshi", "author_url": "", "post_date": "05/17/2021 12:09:46", "content": "Ah, by the way, Chris, actually your tricks help us quite a lot :D, but we still can not use them totally properly, so the improvements were not so impressive.
\nWe are looking for your solutions after the competition.
", "votes": null, "replies": [] }, { "id": 1312244, "author_name": "suryajrrafl", "author_url": "", "post_date": "05/18/2021 00:01:49", "content": "Thanks @shinomoriaoshi for you suggestion. I did try converting the ruler angles from compass to Cartesian co-ordinate system but there's not much luck that way either. Thanks anyway for the comment. Looking forward to learning from Winning solutions
", "votes": null, "replies": [] } ] } ], "raw_markdown_by_id": { "1311058": "Hi,\nI was very excited about this competition, but couldn't spend much time on it. One of my ideas was to use sequence-2-sequence modelling of IMU sensor features to generate local waypoints. I tried to implement my idea in this [notebook](https://www.kaggle.com/suryajrrafl/conv-se2seq-attention-model-imu-features)\n\n\nBasic idea is to used encoder decoder architecture with convolutions as follows:\n1. Encoder input - Features are IMU data, considering 2D plane, (i.e), timestamps of IMU data, linear acceleration in x,y directions and yaw rate (gyroscope z axis) along with euler angles w.r.t magnetic north.\n\n2. Decoder input - Timestamp at which waypoint is to be inferred. The inference time is relative to the first imu timestamp.\n\n3. Decoder output - Local waypoints (i.e) actual waypoint - first waypoint of path. The points are translated such that first waypoint is the origin. This is done because, the imu features give local trajectory (~shape of the path) but by itself cannot infer global trajectory directly.\n\nThe encoder and decoder data are made of fixed length. For encoder, the imu data is sampled to be of 100 time sequences. For decoder, the maximum waypoints is fixed at 107 (max number of waypoints in path in train data). More details on data generation can be found at [my notebook](https://www.kaggle.com/suryajrrafl/interpolated-imu-data). Padding is done to ensure equal length in all batches.\n\n**Problem**\nDue to some issue, the model doesn't seem to learn anything. The loss seems to reduce 0.0x only with each epoch. I have doubts in loss computation (competitionMetric_Seq2Seq). I am not sure if the current implementation is the correct way to calculate loss for padded elements. But this is only guess and I am not sure where the mistake is. If somebody can help me out, it would be great.", "1311295": "As far as we understand from EDA, IMU can not be used to predict waypoints. We did a quite similar thing, using IMU to predict the change in waypoints, but we failed too. We detected that the headings do not seem right (like headings from IMU show the surveyor is going to the North, but he turns to the West). Therefore, I guess using IMU to generate waypoints is similar to using IMU predict waypoints and it would not work (in my opinion). We are still waiting for the top teams to publish their solutions regarding using IMU features.", "1311444": "I'll publish more info after the competition is over today, but I already wrote up a post about a few tricks for how to use sensor data: https://www.kaggle.com/c/indoor-location-navigation/discussion/236096\n\nI think a few of the points there may help with the trouble you're having! \n\n[EDIT]: oh, I just realized you've already commented on that post - sorry! I'll be happy to answer specific questions in about 12 hours after the deadline :)", "1311451": "Ah, by the way, Chris, actually your tricks help us quite a lot :D, but we still can not use them totally properly, so the improvements were not so impressive.\n\nWe are looking for your solutions after the competition.", "1312244": "Thanks @shinomoriaoshi for you suggestion. I did try converting the ruler angles from compass to Cartesian co-ordinate system but there's not much luck that way either. Thanks anyway for the comment. Looking forward to learning from Winning solutions", "1312247": "Thanks @chris62 for your suggestion. Your suggestions have been very helpful in this competition. I'll go through my code once again keeping those in kind. Waiting to learn from your solution" }, "source": "meta" }