Unable to obtain the same result as solution 2

[timuxi]

@weisongwen Thanks for your reply, Professor Wen. It seems that I have fallen into confusion. I will list them one by one:

1、As you wrote in the MD, the results of RTK position (solution 2) will be saved by default in ~/GraphGNSSLib/trajectory_psr_dop_fusion.csv. However, I cannot find the function to log the results. But I did find the log function factor_graph.logResults(logPath); in psr_doppler_fusion.launch. As you said, the default name is ~/GraphGNSSLib/trajectory_psr_dop_fusion.csv, but I see that the name is <param name="logPath" type="string" value="$(findglobal_fusion)/FGO_trajectoryllh_psr_dop_fusion.csv" />. It seems different.

2、I was confused about the meaning of ref_lat, ref_lon, and ref_alt. Initially, I thought they were transformed from station_x, station_y, and station_z to represent llh coordinate, but after testing, I found that they represent different positions. Then I looked up the previous issue and found that it seems to be related to the enu coordinate system?, What I want to know is whether this value will affect the final positioning result?

#define ref_lon 114.179000972 /* Weisong: reference longitude */
#define ref_lat 22.3011535667 /* Weisong: reference latitude */
#define ref_alt 6.42821512092 /* Weisong: reference altitude */

#define station_x -2414266.9200 /* Weisong: pose x of base station */
#define station_y 5386768.9870  /* Weisong: pose y of base station */
#define station_z 2407460.0310  /* Weisong: pose z of station */

3、No matter how I change the opt in the code, I still cannot get the same result as in your paper. Is the data (solution 2 static) the same as in your paper? Or did I make some mistakes? Here are the results of my run, with orange representing rtklib, blue representing fgo, and red representing groundtruth.

[weisongwen]

@Pirkaklo Hi Yihan, can you please take a look at this? thanks

[Pirkaklo]

**timuxi ** commented May 23, 2023 •

Thanks for sharing your results. Before we discuss the FGO results in the static dataset, the result of RTK looks strange. To help address your concern, please provide the specific options or configuration settings you used for RTKLIB. Knowing the options will help us analyze any discrepancies or potential issues.

[timuxi]

@Pirkaklo Thanks for your reply，the following is a configuration item in my RTKLIB. I haven't made any modifications to the original configuration items in the code (if I haven't made any mistakes). If you need the data file I calculated, I can send it to you via email

[weisongwen]

Hi @timuxi , thanks for the feedback!

• GNSS-RTK based on the RTKLIB: For the RTKLIB setup, we use the forward mode. If you try this, you should be able to get similar results from RTKLIB.
• GNSS-RTK based on the FGO: in this repository, the GNSS-RTK demo is only a toy example which is slight different from our internal version, such as the GNSS DD measurements management which is also done in RTKLIB. For example, the GNSS DD measurements will be used only when both the pseudorange and carrier-phase are received.

Still, lots of things can be done to improve this repository. For example, cycle slip detection could be added. The constant ambiguity variable constraint can also be applied. We are internally working on this new version of the GNSS-RTK using FGO. We would open-source this version soooon.

[timuxi]

Hi @weisongwen ,Professor Wen, thank you for your patient answer. I have another question: you mentioned RTK-EKF in your paper. May I ask if this refers to the result calculated directly through rtklib? Or implemented by yourself ? (to avoide optimization methods in rtklib)