i use code from : https://github.com/rtklibexplorer/RTKLIB/releases/tag/b34e_smartphone
\n(https://rtklibexplorer.wordpress.com/2022/01/10/google-smartphone-decimeter-challenge/)
i make late submission to the previous 2021 competition: https://www.kaggle.com/competitions/google-smartphone-decimeter-challenge
\nhere are interesting results
\n1) using provided submission_1230.csv
\nprivate/public lb: 2.15119/4.56668
2) using provided rnx2rtkp.exe and use wine to run in linux
\nprivate/public lb: 2.15119/4.62310
3) compile code using GCC for linux
\nprivate/public lb: 3.43606/16.80587
actually there is no solution for the test cases: 2021-03-16-US-MTV-2_Pixel4Modded, 2021-04-08-US-MTV-1_Pixel4Modded. which I reverted back to baseline test results.
\n4) compile code using GCC for linux for latest built in https://github.com/rtklibexplorer/RTKLIB
\nprivate/public lb: 2.33241/4.60841
I am not sure what cause the difference. all code and input(base station obs, nav files) were the same. the only difference is the binary rnx2rtkp used
", "messages": [ { "id": "1806473", "postDate": "05/31/2022 08:05:01", "content": "i use code from : https://github.com/rtklibexplorer/RTKLIB/releases/tag/b34e_smartphone
\n(https://rtklibexplorer.wordpress.com/2022/01/10/google-smartphone-decimeter-challenge/)
i make late submission to the previous 2021 competition: https://www.kaggle.com/competitions/google-smartphone-decimeter-challenge
\nhere are interesting results
\n1) using provided submission_1230.csv
\nprivate/public lb: 2.15119/4.56668
2) using provided rnx2rtkp.exe and use wine to run in linux
\nprivate/public lb: 2.15119/4.62310
3) compile code using GCC for linux
\nprivate/public lb: 3.43606/16.80587
actually there is no solution for the test cases: 2021-03-16-US-MTV-2_Pixel4Modded, 2021-04-08-US-MTV-1_Pixel4Modded. which I reverted back to baseline test results.
\n4) compile code using GCC for linux for latest built in https://github.com/rtklibexplorer/RTKLIB
\nprivate/public lb: 2.33241/4.60841
I am not sure what cause the difference. all code and input(base station obs, nav files) were the same. the only difference is the binary rnx2rtkp used
", "rawMarkdown": "i use code from : https://github.com/rtklibexplorer/RTKLIB/releases/tag/b34e_smartphone\n(https://rtklibexplorer.wordpress.com/2022/01/10/google-smartphone-decimeter-challenge/)\n\ni make late submission to the previous 2021 competition: https://www.kaggle.com/competitions/google-smartphone-decimeter-challenge\n\nhere are interesting results\n\n1) using provided submission_1230.csv\nprivate/public lb: 2.15119/4.56668\n\n2) using provided rnx2rtkp.exe and use wine to run in linux\nprivate/public lb: 2.15119/4.62310\n\n3) compile code using GCC for linux\nprivate/public lb: 3.43606/16.80587\n\nactually there is no solution for the test cases: 2021-03-16-US-MTV-2_Pixel4Modded, 2021-04-08-US-MTV-1_Pixel4Modded. which I reverted back to baseline test results.\n\n4) compile code using GCC for linux for latest built in https://github.com/rtklibexplorer/RTKLIB\nprivate/public lb: 2.33241/4.60841\n\nI am not sure what cause the difference. all code and input(base station obs, nav files) were the same. the only difference is the binary rnx2rtkp used", "votes": null }, { "id": "1807067", "postDate": "05/31/2022 17:22:33", "content": "Regarding your result 3, my best guess is that you missed the note in the release description to use the source files included in the main release file and not the source code zip file that Github automatically added to the release package. This is because I did not realize that Github would do this and I did not create a separate branch before generating the release package.
\nI would recommend using the method in your result 4, building the most recent code. To confirm the code, I just now cloned the latest code from the Github repo and built both the linux version with GCC and the Windows version with the Embarcadero compiler, then ran both on the first training data set from 2021 (2020-05-15-US-MTV-1\\Pixel4) and confirmed the solutions were identical. This code, along with the config file from \"Getting Started with RTKLIB\" notebook should give you a score of 3.135 on the 2022 test data. This also assumes you replace the solutions for the datasets with hardware clock discontinuities with the baseline solutions from the \"GSDC2 - baseline submission\" notebook as is explained in the above-mentioned RTKLIB notebook.
\nSome of your remaining variation may be due to how you handled the data sets with hardware clock discontinuities. In the 2021 results I eliminated these with the mergePhones.py python code since there was always at least one phone in every ride that did not have clock discontinuities. In the 2022 results, I replaced these solutions with the baseline results as mentioned above.
", "rawMarkdown": "Regarding your result 3, my best guess is that you missed the note in the release description to use the source files included in the main release file and not the source code zip file that Github automatically added to the release package. This is because I did not realize that Github would do this and I did not create a separate branch before generating the release package.\n\nI would recommend using the method in your result 4, building the most recent code. To confirm the code, I just now cloned the latest code from the Github repo and built both the linux version with GCC and the Windows version with the Embarcadero compiler, then ran both on the first training data set from 2021 (2020-05-15-US-MTV-1\\Pixel4) and confirmed the solutions were identical. This code, along with the config file from \"Getting Started with RTKLIB\" notebook should give you a score of 3.135 on the 2022 test data. This also assumes you replace the solutions for the datasets with hardware clock discontinuities with the baseline solutions from the \"GSDC2 - baseline submission\" notebook as is explained in the above-mentioned RTKLIB notebook.\n\nSome of your remaining variation may be due to how you handled the data sets with hardware clock discontinuities. In the 2021 results I eliminated these with the mergePhones.py python code since there was always at least one phone in every ride that did not have clock discontinuities. In the 2022 results, I replaced these solutions with the baseline results as mentioned above.", "votes": null }, { "id": "1808816", "postDate": "06/02/2022 07:15:46", "content": "@timeverett thanks for the reply.
\n\"3.135 on the 2022 test data\"
I confirm I can get results.
\nRTKLIB-py gives better results.
after setting up c debugger(RTKLIB) and compare it with python debugger (RTKLIB-py), I compare line-by-line how the input changes its values. this is the first function estpos(), that causes output differences(dx) due to the value of parameter NX.
\npython (RTKLIB-py)
\nppk_phone_0510.py\nnf = 2 # num frequencies ( 1 or 2)\n\n\npntpos.py\nNX = 6 # num of estimated parameters, pos + clock\n\ndef estpos(obs, nav, rs, dts, svh):\n \"\"\" estimate position and clock errors with standard precision \"\"\"\n\n ...\n dx = lstsq(H, v, rcond=None)[0]\n\nresults is different after least square. this is because the problem size is NX=6\nC(RTKLIB)
\nppk_phone_0510.conf\npos1-frequency =l1+l2+l5 # (1:l1,2:l1+l2,3:l1+l2+l5,4:l1+l2+l5+l6)\n\npntpos.c\n#if 0 /* enable GPS-QZS time offset estimation */\n#define NX (4+5) /* # of estimated parameters */\n#else\n#define NX (4+4) /* # of estimated parameters */\n\nstatic int estpos(const obsd_t *obs, int n, const double *rs, const double *dts,\n const double *vare, const int *svh, const nav_t *nav,\n const prcopt_t *opt, const ssat_t *ssat, sol_t *sol, double *azel,\n int *vsat, double *resp, char *msg)\n{\n\n double x[NX]={0},dx[NX],Q[NX*NX],*v,*H,*var,sig;\n ....\n /* least square estimation */\n if ((info=lsq(H,v,NX,nv,dx,Q))) {\n sprintf(msg,\"lsq error info=%d\",info);\n break;\n }\nYes, it is true that the estpos() function is not identical between RTKLIB and rtklib-py. This is a standard precision solution used only to make an initial rough estimate of position and velocity. Small differences in the results of this function between the two codes shouldn't make a material different on the solutions but it can hinder direct comparison of the two debug trace files.
\nTo make direct comparison between the two debug trace files easier, I have a couple of input parameters in the rtklib-py config file to use a specified initial position/velocity estimate instead of the result of estpos(). rr_f is for the forward solution and rr_b is for the backward solution. The forward solution is run first so you usually only need to set that one.
\n# initial rover position/velocity for alignment to RTKLIB\n#rr_f = [-2694556.682853, -4296492.691977, 3854819.048563, # forwards\n# -0.009033 , 0.042808, -0.027949] \n#rr_b = [-2709836.020965, -4269097.509128, 3874376.664473, # backwards\n# 0.018097, 0.051379, -0.027851 ]\n# Set to zero to use standard precision computed starting position\nrr_f = [0, 0, 0, 0, 0, 0]\nrr_b = [0, 0, 0, 0, 0, 0]\nThe commented out values are for the example dataset included with rtklib-py but if you replace these with the values from the RTKLIB trace file (search for rr_init), then you should see much closer alignment between the two traces. They will diverge slowly over time due to small differences in the code and the iterative nature of the solution but I did find this feature very useful when I was aligning the rtklib-py solutions to the RTKLIB solutions.
\nDuring this process I did find a few minor issues with the RTKLIB code which I have not yet had time to correct. I believe these are the reason the rtklib-py results are currently slightly better than the RTKLIB results.
", "rawMarkdown": "Yes, it is true that the estpos() function is not identical between RTKLIB and rtklib-py. This is a standard precision solution used only to make an initial rough estimate of position and velocity. Small differences in the results of this function between the two codes shouldn't make a material different on the solutions but it can hinder direct comparison of the two debug trace files.\n\nTo make direct comparison between the two debug trace files easier, I have a couple of input parameters in the rtklib-py config file to use a specified initial position/velocity estimate instead of the result of estpos(). rr_f is for the forward solution and rr_b is for the backward solution. The forward solution is run first so you usually only need to set that one.\n\n```\n# initial rover position/velocity for alignment to RTKLIB\n#rr_f = [-2694556.682853, -4296492.691977, 3854819.048563, # forwards\n# -0.009033 , 0.042808, -0.027949] \n#rr_b = [-2709836.020965, -4269097.509128, 3874376.664473, # backwards\n# 0.018097, 0.051379, -0.027851 ]\n# Set to zero to use standard precision computed starting position\nrr_f = [0, 0, 0, 0, 0, 0]\nrr_b = [0, 0, 0, 0, 0, 0]\n```\n\nThe commented out values are for the example dataset included with rtklib-py but if you replace these with the values from the RTKLIB trace file (search for rr_init), then you should see much closer alignment between the two traces. They will diverge slowly over time due to small differences in the code and the iterative nature of the solution but I did find this feature very useful when I was aligning the rtklib-py solutions to the RTKLIB solutions.\n\nDuring this process I did find a few minor issues with the RTKLIB code which I have not yet had time to correct. I believe these are the reason the rtklib-py results are currently slightly better than the RTKLIB results.", "votes": null } ], "comments": [ { "id": 1807067, "author_name": "timeverett", "author_url": "", "post_date": "05/31/2022 17:22:33", "content": "Regarding your result 3, my best guess is that you missed the note in the release description to use the source files included in the main release file and not the source code zip file that Github automatically added to the release package. This is because I did not realize that Github would do this and I did not create a separate branch before generating the release package.
\nI would recommend using the method in your result 4, building the most recent code. To confirm the code, I just now cloned the latest code from the Github repo and built both the linux version with GCC and the Windows version with the Embarcadero compiler, then ran both on the first training data set from 2021 (2020-05-15-US-MTV-1\\Pixel4) and confirmed the solutions were identical. This code, along with the config file from \"Getting Started with RTKLIB\" notebook should give you a score of 3.135 on the 2022 test data. This also assumes you replace the solutions for the datasets with hardware clock discontinuities with the baseline solutions from the \"GSDC2 - baseline submission\" notebook as is explained in the above-mentioned RTKLIB notebook.
\nSome of your remaining variation may be due to how you handled the data sets with hardware clock discontinuities. In the 2021 results I eliminated these with the mergePhones.py python code since there was always at least one phone in every ride that did not have clock discontinuities. In the 2022 results, I replaced these solutions with the baseline results as mentioned above.
", "votes": null, "replies": [ { "id": 1808816, "author_name": "hengck23", "author_url": "", "post_date": "06/02/2022 07:15:46", "content": "@timeverett thanks for the reply.
\n\"3.135 on the 2022 test data\"
I confirm I can get results.
\nRTKLIB-py gives better results.
after setting up c debugger(RTKLIB) and compare it with python debugger (RTKLIB-py), I compare line-by-line how the input changes its values. this is the first function estpos(), that causes output differences(dx) due to the value of parameter NX.
\npython (RTKLIB-py)
\nppk_phone_0510.py\nnf = 2 # num frequencies ( 1 or 2)\n\n\npntpos.py\nNX = 6 # num of estimated parameters, pos + clock\n\ndef estpos(obs, nav, rs, dts, svh):\n \"\"\" estimate position and clock errors with standard precision \"\"\"\n\n ...\n dx = lstsq(H, v, rcond=None)[0]\n\nresults is different after least square. this is because the problem size is NX=6\nC(RTKLIB)
\nppk_phone_0510.conf\npos1-frequency =l1+l2+l5 # (1:l1,2:l1+l2,3:l1+l2+l5,4:l1+l2+l5+l6)\n\npntpos.c\n#if 0 /* enable GPS-QZS time offset estimation */\n#define NX (4+5) /* # of estimated parameters */\n#else\n#define NX (4+4) /* # of estimated parameters */\n\nstatic int estpos(const obsd_t *obs, int n, const double *rs, const double *dts,\n const double *vare, const int *svh, const nav_t *nav,\n const prcopt_t *opt, const ssat_t *ssat, sol_t *sol, double *azel,\n int *vsat, double *resp, char *msg)\n{\n\n double x[NX]={0},dx[NX],Q[NX*NX],*v,*H,*var,sig;\n ....\n /* least square estimation */\n if ((info=lsq(H,v,NX,nv,dx,Q))) {\n sprintf(msg,\"lsq error info=%d\",info);\n break;\n }\nYes, it is true that the estpos() function is not identical between RTKLIB and rtklib-py. This is a standard precision solution used only to make an initial rough estimate of position and velocity. Small differences in the results of this function between the two codes shouldn't make a material different on the solutions but it can hinder direct comparison of the two debug trace files.
\nTo make direct comparison between the two debug trace files easier, I have a couple of input parameters in the rtklib-py config file to use a specified initial position/velocity estimate instead of the result of estpos(). rr_f is for the forward solution and rr_b is for the backward solution. The forward solution is run first so you usually only need to set that one.
\n# initial rover position/velocity for alignment to RTKLIB\n#rr_f = [-2694556.682853, -4296492.691977, 3854819.048563, # forwards\n# -0.009033 , 0.042808, -0.027949] \n#rr_b = [-2709836.020965, -4269097.509128, 3874376.664473, # backwards\n# 0.018097, 0.051379, -0.027851 ]\n# Set to zero to use standard precision computed starting position\nrr_f = [0, 0, 0, 0, 0, 0]\nrr_b = [0, 0, 0, 0, 0, 0]\nThe commented out values are for the example dataset included with rtklib-py but if you replace these with the values from the RTKLIB trace file (search for rr_init), then you should see much closer alignment between the two traces. They will diverge slowly over time due to small differences in the code and the iterative nature of the solution but I did find this feature very useful when I was aligning the rtklib-py solutions to the RTKLIB solutions.
\nDuring this process I did find a few minor issues with the RTKLIB code which I have not yet had time to correct. I believe these are the reason the rtklib-py results are currently slightly better than the RTKLIB results.
", "votes": null, "replies": [] } ] } ], "raw_markdown_by_id": { "1806473": "i use code from : https://github.com/rtklibexplorer/RTKLIB/releases/tag/b34e_smartphone\n(https://rtklibexplorer.wordpress.com/2022/01/10/google-smartphone-decimeter-challenge/)\n\ni make late submission to the previous 2021 competition: https://www.kaggle.com/competitions/google-smartphone-decimeter-challenge\n\nhere are interesting results\n\n1) using provided submission_1230.csv\nprivate/public lb: 2.15119/4.56668\n\n2) using provided rnx2rtkp.exe and use wine to run in linux\nprivate/public lb: 2.15119/4.62310\n\n3) compile code using GCC for linux\nprivate/public lb: 3.43606/16.80587\n\nactually there is no solution for the test cases: 2021-03-16-US-MTV-2_Pixel4Modded, 2021-04-08-US-MTV-1_Pixel4Modded. which I reverted back to baseline test results.\n\n4) compile code using GCC for linux for latest built in https://github.com/rtklibexplorer/RTKLIB\nprivate/public lb: 2.33241/4.60841\n\nI am not sure what cause the difference. all code and input(base station obs, nav files) were the same. the only difference is the binary rnx2rtkp used", "1807067": "Regarding your result 3, my best guess is that you missed the note in the release description to use the source files included in the main release file and not the source code zip file that Github automatically added to the release package. This is because I did not realize that Github would do this and I did not create a separate branch before generating the release package.\n\nI would recommend using the method in your result 4, building the most recent code. To confirm the code, I just now cloned the latest code from the Github repo and built both the linux version with GCC and the Windows version with the Embarcadero compiler, then ran both on the first training data set from 2021 (2020-05-15-US-MTV-1\\Pixel4) and confirmed the solutions were identical. This code, along with the config file from \"Getting Started with RTKLIB\" notebook should give you a score of 3.135 on the 2022 test data. This also assumes you replace the solutions for the datasets with hardware clock discontinuities with the baseline solutions from the \"GSDC2 - baseline submission\" notebook as is explained in the above-mentioned RTKLIB notebook.\n\nSome of your remaining variation may be due to how you handled the data sets with hardware clock discontinuities. In the 2021 results I eliminated these with the mergePhones.py python code since there was always at least one phone in every ride that did not have clock discontinuities. In the 2022 results, I replaced these solutions with the baseline results as mentioned above.", "1808816": "timeverett thanks for the reply.\n\"3.135 on the 2022 test data\"\n\nI confirm I can get results.\nRTKLIB-py gives better results.\n\nafter setting up c debugger(RTKLIB) and compare it with python debugger (RTKLIB-py), I compare line-by-line how the input changes its values. this is the first function estpos(), that causes output differences(dx) due to the value of parameter NX.\n\npython (RTKLIB-py)\n```\nppk_phone_0510.py\nnf = 2 # num frequencies ( 1 or 2)\n\n\npntpos.py\nNX = 6 # num of estimated parameters, pos + clock\n\ndef estpos(obs, nav, rs, dts, svh):\n \"\"\" estimate position and clock errors with standard precision \"\"\"\n \n ...\n dx = lstsq(H, v, rcond=None)[0]\n \nresults is different after least square. this is because the problem size is NX=6\n\n```\n\n\nC(RTKLIB) \n```\nppk_phone_0510.conf\npos1-frequency =l1+l2+l5 # (1:l1,2:l1+l2,3:l1+l2+l5,4:l1+l2+l5+l6)\n\npntpos.c\n#if 0 /* enable GPS-QZS time offset estimation */\n#define NX (4+5) /* # of estimated parameters */\n#else\n#define NX (4+4) /* # of estimated parameters */\n\nstatic int estpos(const obsd_t *obs, int n, const double *rs, const double *dts,\n const double *vare, const int *svh, const nav_t *nav,\n const prcopt_t *opt, const ssat_t *ssat, sol_t *sol, double *azel,\n int *vsat, double *resp, char *msg)\n{\n\n double x[NX]={0},dx[NX],Q[NX*NX],*v,*H,*var,sig;\n ....\n /* least square estimation */\n if ((info=lsq(H,v,NX,nv,dx,Q))) {\n sprintf(msg,\"lsq error info=%d\",info);\n break;\n }\n```", "1809220": "Yes, it is true that the estpos() function is not identical between RTKLIB and rtklib-py. This is a standard precision solution used only to make an initial rough estimate of position and velocity. Small differences in the results of this function between the two codes shouldn't make a material different on the solutions but it can hinder direct comparison of the two debug trace files.\n\nTo make direct comparison between the two debug trace files easier, I have a couple of input parameters in the rtklib-py config file to use a specified initial position/velocity estimate instead of the result of estpos(). rr_f is for the forward solution and rr_b is for the backward solution. The forward solution is run first so you usually only need to set that one.\n\n```\n# initial rover position/velocity for alignment to RTKLIB\n#rr_f = [-2694556.682853, -4296492.691977, 3854819.048563, # forwards\n# -0.009033 , 0.042808, -0.027949] \n#rr_b = [-2709836.020965, -4269097.509128, 3874376.664473, # backwards\n# 0.018097, 0.051379, -0.027851 ]\n# Set to zero to use standard precision computed starting position\nrr_f = [0, 0, 0, 0, 0, 0]\nrr_b = [0, 0, 0, 0, 0, 0]\n```\n\nThe commented out values are for the example dataset included with rtklib-py but if you replace these with the values from the RTKLIB trace file (search for rr_init), then you should see much closer alignment between the two traces. They will diverge slowly over time due to small differences in the code and the iterative nature of the solution but I did find this feature very useful when I was aligning the rtklib-py solutions to the RTKLIB solutions.\n\nDuring this process I did find a few minor issues with the RTKLIB code which I have not yet had time to correct. I believe these are the reason the rtklib-py results are currently slightly better than the RTKLIB results." }, "source": "meta" }