Question about initial values for time clock drifts and extrinsic

[Joanna-HE]

Hi, I have a question about the initialization of this system. As indicated in the article, there is only an implicit initialization procedure for the proposed system, then how to give an initial value to the extrinsic between local world frame and ecef frame, as well as what is the initial value of time clock drifts?

Hope to hear from you, and thanks in advance.

[JonasBchrt]

Hi @Joanna-HE , There are basically three different things to initialise:

• The clock offset w.r.t. to each of the GNSS, one for each system. If these are completely unknown initially and the clock offset of the receiver isn't too bad, they can all be set to zero with a reasonable uncertainty and the optimiser will figure them out. (That's what was done for the paper.) If the receiver clock offset is really bad - like seconds - it might be a good idea to roughly sync it via NTP first, for example.
• The orientation of the local system in the global Earth frame. Again, this can be set arbitrary with an appropriate uncertainty and the solver should be able to figure it out. Although, it is often reasonable to assume that the orientation of the vertical axis is roughly known (gravity-aligned); so, a smaller uncertainty can be used for that one.
• The translation between the local and the global frame. If this is completely unknown, you can theoretically set the initial position to the centre of the Earth, put a high uncertainty on it, and let the solver figure it out. However, without extra measures, you're likely going to run into numerical issues and/or face slow convergence. Usually, it's reasonable to assume that a rough initial position is known in practice, even if it's kilometres away. That's the assumption in the paper. If you have no idea in which part of the world you are, then you can also consider running a little bit of "normal" GNSS-based positioning in a separate solver first and use the resulting position to initialise the actual fusion algorithm.

I hope that makes sense.

[Joanna-HE]

Thanks a lot for your prompt response! I also want to make sure about a technical issue of the GTSAM: how to set an initial uncertainty for the gtsam::Values? Could I make it through adding a prior factor with self-defined noises? Or is there another way to set the initial uncertainties?

I hope I have made my question clear. And looking forward to your help.

[JonasBchrt]

Yes, that's what I would do.

In the Python code in this repository you can find an (albeit very minimal) example, where I use gtsam.noiseModel.Diagonal.Sigmas() to define a noise model for the prior and a simple numpy array for the prior mean. Then, I create a prior factor with gtsam.PriorFactorVector() and add it to the non-linear FG with gtsam.NonlinearFactorGraph.add(). The C++ interface is roughly similar. Although, you may want to use different types of noise models and factors depending on your implementation. The noise magnitude would usually be a tuning parameter that determines convergence speed, I think.

[Joanna-HE]

Thanks very much for your response. I am clear about this problem now.