{ "id": 241987, "title": "How to reproduce the provided baseline result from \"*_derived.csv\"?", "url": "/competitions/google-smartphone-decimeter-challenge/discussion/241987", "author_name": "YangLiu", "post_date": "2021-05-27T01:51:05.461000", "votes": 12, "comment_count": 4, "views": 0, "content": "

Hi, everyone,

\n

Currently I'm trying to reproduce the baseline result from \"*_derived.csv\" in this notebook.

\n

I did following the suggestions and read carefully about the source code of WLS shown in official repo and applied the rawPrUncM as the weight for least square.

\n

However, the gap between the current WSL result and baseline result is still pretty high. I'm wondering is there any idea/suggestion about how to fill the gap? Thanks in advance!

\n

Btw, if you are interested in using the infomation from the derive files to train your model, there are sample code in evaluation/submission part about merging the derived files with ground truth file.

", "messages": [ { "id": 1325190, "postDate": "2021-05-27T15:03:36.107Z", "content": "

Hi YangLiu,

\n

First of all, this Stanford GPS course about pseudorange explains how to formulate the system of equations, with those error terms in consideration. With this setup, your WLS should be able to get to within 100 meter level of location error.

\n

Secondly, this article explains an important source of error: earth rotation. Briefly speaking, the derived csv provides satellite positions at signal transmission time, but not the signal arrival time. Note that it takes the signal 70-80ms to travel to the phone on the Earth, and during this time, the Earth has rotated, so does the Earth-Centered Earth-Fixed (ECEF) frame! Therefore, we must compute the satellite position at ARRIVAL time. The formula is provided in this article. It's a simple one-liner. With this, your WLS should reach to a few meter level.

\n

Good luck,
\nMichael

", "rawMarkdown": "Hi YangLiu, \n\nFirst of all, this [Stanford GPS course about pseudorange](https://www.youtube.com/watch?v=-hnkDQIZ8kY&list=PLGvhNIiu1ubyEOJga50LJMzVXtbUq6CPo&index=11) explains how to formulate the system of equations, with those error terms in consideration. With this setup, your WLS should be able to get to within 100 meter level of location error. \n\nSecondly, this [article](https://insidegnss.com/how-does-earths-rotation-affect-gnss-orbit-computations/) explains an important source of error: earth rotation. Briefly speaking, the derived csv provides satellite positions at signal transmission time, but not the signal arrival time. Note that it takes the signal 70-80ms to travel to the phone on the Earth, and during this time, the Earth has rotated, so does the Earth-Centered Earth-Fixed (ECEF) frame! Therefore, we must compute the satellite position at ARRIVAL time. The formula is provided in this article. It's a simple one-liner. With this, your WLS should reach to a few meter level.\n\nGood luck,\nMichael", "votes": 14, "replies": [ { "id": 1325617, "postDate": "2021-05-27T21:18:36.990Z", "rawMarkdown": "", "isDeleted": true }, { "id": 1326550, "postDate": "2021-05-28T14:34:24.170Z", "content": "

Hi, @gymf123, Thank you so much for these information here. These information is super helpful!

\n

Currently I do be able to reproduce the basic version of the WSL in this notebook, which gets 33.185 in test set. However, I'm still unable to reproduce the baseline result.

\n

I did read the articles you mentioned above, that is super helpful. But I do not fully understand some context you mentioned here.

\n

From my personal understanding, the actual range should be calculated by the satellite position at the transmission time (which are [x/y/z]SatPosM) and the GNSS user location at the receive time, which can be formulated as $ r^k = || x^k_{tran} - x^u_{recie} || $. The Earth’s rotation affect are used to calculate the actual satellite position at the transmission time (which are [x/y/z]SatPosM). In this case, why do we need to calculate the satellite position at ARRIVAL time as you mentioned?

\n

In stand of calculating the satellite position at ARRIVAL time, should we calculate the ARRIVAL time for GNSS reciever by receivedSvTimeInGpsNanos and rawPrM. And build the WSL also with the ARRIVAL time to reproduce the result for baseline?

\n

But I'm failed to fetch the relative information in the official repo or relative paper/book/article. Would you might provide more information to guide me to the baseline result?

\n

Thanks so much for your help!

\n

Have a great weekend!

\n

Best,
\nYang Liu

", "rawMarkdown": "Hi, @gymf123, Thank you so much for these information here. These information is super helpful!\n\nCurrently I do be able to reproduce the basic version of the WSL in this [notebook](https://www.kaggle.com/foreveryoung/least-squares-solution-from-gnss-derived-data), which gets 33.185 in test set. However, I'm still unable to reproduce the baseline result.\n\nI did read the articles you mentioned above, that is super helpful. But I do not fully understand some context you mentioned here.\n\nFrom my personal understanding, the actual range should be calculated by the satellite position at the transmission time (which are `[x/y/z]SatPosM`) and the GNSS user location at the receive time, which can be formulated as $ r^k = || x^k_{tran} - x^u_{recie} || $. The Earth’s rotation affect are used to calculate the actual satellite position at the transmission time (which are `[x/y/z]SatPosM`). In this case, why do we need to calculate the satellite position at ARRIVAL time as you mentioned?\n\nIn stand of calculating the satellite position at ARRIVAL time, should we calculate the ARRIVAL time for GNSS reciever by `receivedSvTimeInGpsNanos` and `rawPrM`. And build the WSL also with the ARRIVAL time to reproduce the result for baseline?\n\nBut I'm failed to fetch the relative information in the [official repo](https://github.com/google/gps-measurement-tools/blob/master/opensource/WlsPvt.m#L62-L111) or relative paper/book/article. Would you might provide more information to guide me to the baseline result?\n\nThanks so much for your help!\n\nHave a great weekend!\n\nBest,\nYang Liu", "votes": 3 } ] }, { "id": 1324473, "postDate": "2021-05-27T01:51:05.463Z", "content": "

Hi, everyone,

\n

Currently I'm trying to reproduce the baseline result from \"*_derived.csv\" in this notebook.

\n

I did following the suggestions and read carefully about the source code of WLS shown in official repo and applied the rawPrUncM as the weight for least square.

\n

However, the gap between the current WSL result and baseline result is still pretty high. I'm wondering is there any idea/suggestion about how to fill the gap? Thanks in advance!

\n

Btw, if you are interested in using the infomation from the derive files to train your model, there are sample code in evaluation/submission part about merging the derived files with ground truth file.

", "rawMarkdown": "Hi, everyone,\n\nCurrently I'm trying to reproduce the baseline result from \"*_derived.csv\" in this [notebook](https://www.kaggle.com/foreveryoung/least-squares-solution-from-gnss-derived-data). \n\nI did following the [suggestions](https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238583) and read carefully about the source code of [WLS shown in official repo](https://github.com/google/gps-measurement-tools/blob/master/opensource/WlsPvt.m#L62-L111) and applied the rawPrUncM as the weight for least square.\n\nHowever, the gap between the current WSL result and baseline result is still pretty high. I'm wondering is there any idea/suggestion about how to fill the gap? Thanks in advance!\n\nBtw, if you are interested in using the infomation from the derive files to train your model, there are sample code in evaluation/submission part about merging the derived files with ground truth file.", "votes": 12 }, { "id": 1367321, "postDate": "2021-06-27T15:31:58.623Z", "content": "

Hey YangLiu,
\nI had a go at it and implemented the recommendations given by the competition host taking inspiration from your notebook. You'll find the notebook here, it does seem to be closer to the baseline solution now, thanks for your work! 👍

", "rawMarkdown": "Hey YangLiu,\nI had a go at it and implemented the recommendations given by the competition host taking inspiration from your notebook. You'll find the notebook [here](https://www.kaggle.com/hyperc/gsdc-reproducing-baseline-wls-on-one-measurement), it does seem to be closer to the baseline solution now, thanks for your work! 👍", "votes": 1 } ], "comments": [ { "id": 1325190, "author_name": "Michael Fu", "author_url": "", "post_date": "2021-05-27T15:03:36.107000", "content": "

Hi YangLiu,

\n

First of all, this Stanford GPS course about pseudorange explains how to formulate the system of equations, with those error terms in consideration. With this setup, your WLS should be able to get to within 100 meter level of location error.

\n

Secondly, this article explains an important source of error: earth rotation. Briefly speaking, the derived csv provides satellite positions at signal transmission time, but not the signal arrival time. Note that it takes the signal 70-80ms to travel to the phone on the Earth, and during this time, the Earth has rotated, so does the Earth-Centered Earth-Fixed (ECEF) frame! Therefore, we must compute the satellite position at ARRIVAL time. The formula is provided in this article. It's a simple one-liner. With this, your WLS should reach to a few meter level.

\n

Good luck,
\nMichael

", "votes": 14, "replies": [ { "id": 1325617, "author_name": "", "author_url": "", "post_date": "2021-05-27T21:18:36.990000", "content": "", "votes": 0, "replies": [] }, { "id": 1326550, "author_name": "YangLiu", "author_url": "", "post_date": "2021-05-28T14:34:24.170000", "content": "

Hi, @gymf123, Thank you so much for these information here. These information is super helpful!

\n

Currently I do be able to reproduce the basic version of the WSL in this notebook, which gets 33.185 in test set. However, I'm still unable to reproduce the baseline result.

\n

I did read the articles you mentioned above, that is super helpful. But I do not fully understand some context you mentioned here.

\n

From my personal understanding, the actual range should be calculated by the satellite position at the transmission time (which are [x/y/z]SatPosM) and the GNSS user location at the receive time, which can be formulated as $ r^k = || x^k_{tran} - x^u_{recie} || $. The Earth’s rotation affect are used to calculate the actual satellite position at the transmission time (which are [x/y/z]SatPosM). In this case, why do we need to calculate the satellite position at ARRIVAL time as you mentioned?

\n

In stand of calculating the satellite position at ARRIVAL time, should we calculate the ARRIVAL time for GNSS reciever by receivedSvTimeInGpsNanos and rawPrM. And build the WSL also with the ARRIVAL time to reproduce the result for baseline?

\n

But I'm failed to fetch the relative information in the official repo or relative paper/book/article. Would you might provide more information to guide me to the baseline result?

\n

Thanks so much for your help!

\n

Have a great weekend!

\n

Best,
\nYang Liu

", "votes": 3, "replies": [] } ] }, { "id": 1367321, "author_name": "Parrot", "author_url": "", "post_date": "2021-06-27T15:31:58.623000", "content": "

Hey YangLiu,
\nI had a go at it and implemented the recommendations given by the competition host taking inspiration from your notebook. You'll find the notebook here, it does seem to be closer to the baseline solution now, thanks for your work! 👍

", "votes": 1, "replies": [] } ], "raw_markdown_by_id": { "1325190": "Hi YangLiu, \n\nFirst of all, this [Stanford GPS course about pseudorange](https://www.youtube.com/watch?v=-hnkDQIZ8kY&list=PLGvhNIiu1ubyEOJga50LJMzVXtbUq6CPo&index=11) explains how to formulate the system of equations, with those error terms in consideration. With this setup, your WLS should be able to get to within 100 meter level of location error. \n\nSecondly, this [article](https://insidegnss.com/how-does-earths-rotation-affect-gnss-orbit-computations/) explains an important source of error: earth rotation. Briefly speaking, the derived csv provides satellite positions at signal transmission time, but not the signal arrival time. Note that it takes the signal 70-80ms to travel to the phone on the Earth, and during this time, the Earth has rotated, so does the Earth-Centered Earth-Fixed (ECEF) frame! Therefore, we must compute the satellite position at ARRIVAL time. The formula is provided in this article. It's a simple one-liner. With this, your WLS should reach to a few meter level.\n\nGood luck,\nMichael", "1324473": "Hi, everyone,\n\nCurrently I'm trying to reproduce the baseline result from \"*_derived.csv\" in this [notebook](https://www.kaggle.com/foreveryoung/least-squares-solution-from-gnss-derived-data). \n\nI did following the [suggestions](https://www.kaggle.com/c/google-smartphone-decimeter-challenge/discussion/238583) and read carefully about the source code of [WLS shown in official repo](https://github.com/google/gps-measurement-tools/blob/master/opensource/WlsPvt.m#L62-L111) and applied the rawPrUncM as the weight for least square.\n\nHowever, the gap between the current WSL result and baseline result is still pretty high. I'm wondering is there any idea/suggestion about how to fill the gap? Thanks in advance!\n\nBtw, if you are interested in using the infomation from the derive files to train your model, there are sample code in evaluation/submission part about merging the derived files with ground truth file.", "1367321": "Hey YangLiu,\nI had a go at it and implemented the recommendations given by the competition host taking inspiration from your notebook. You'll find the notebook [here](https://www.kaggle.com/hyperc/gsdc-reproducing-baseline-wls-on-one-measurement), it does seem to be closer to the baseline solution now, thanks for your work! 👍" } }