Some questions

[chengwei0427]

Hi， @jaeyoungjo99

Thank you for open-sourcing such an amazing piece of work. As I’m studying the code, I have some questions and would like to discuss them with you:

1. Why is the lidar_time_delay processing necessary? After processing, the LiDAR timestamp is no longer accurate. Since the delayed time is used for distortion correction and EKF state updates, won't this have an impact on the results?
2. In the function Run() of the EKF, the current state is updated to the latest system time through RunPrediction(cur_timestamp). However, during observation, it seems that the time difference between the observation data and the current system state is not considered. Could this be an issue? Specifically, when performing observation with PCM estimation results, although the PCM calculation result is compensated, the LiDAR data used to estimate PCM has undergone lidar_time_delay processing. Is this approach reasonable?

Looking forward to your reply.
Best regards!

[jaeyoungjo99]

Thank you for your question.

1. First, lidar_time_delay is a parameter to deal with the ros time delay that occurs when the sync system between the lidar sensor driver and the system is not established. In our system, a delay of about 30ms occurred empirically and was applied.

2. Basically, the EKF system I have configured operates based on the current time. Therefore, of course, the data used in
   RunGnssUpdate() must be synchronized with the current EKF system time. Therefore, the GnssTimeCompensation function in https://github.com/jaeyoungjo99/ELiMaLoc/blob/f89294b3714f19cda3a94e8f49ccf17dbf635f23/src/app/localization/ekf_localization/src/ekf_localization.cpp#L176C9-L176C29
   compensates for the time delay of this observation.

Additionally, to explain the function, the interpolated position data through the CV model is used for Gnss Update by the amount of delayed dt based on the ekf state closest to the observation.

[chengwei0427]

Hi， @jaeyoungjo99

Thank you for your patient reply. I have a few more questions:

1. How can I obtain the time difference between the LiDAR sensor and the system?

2. I noticed that in the CallBackPcmOdom, the PCM results are compensated, but in CallBackNavsatFix, no compensation is performed. Could there be a time difference between the GPS observation and the current EKF state?

[jaeyoungjo99]

Hello @chengwei0427

1. The time delay between the lidar and the IMU (or system) was actually tuned empirically(no tool).

2. The position data received via GPS was assumed to have no delay.

[chengwei0427]

Thank you for your patient answers. My questions have all been resolved, and I will close the issue. Thanks again!

[chengwei0427]

Hello, @jaeyoungjo99

Thank you for open-sourcing ELiMaLoc.

I’ve tested the ELiMaLoc dataset you provided and it performs very well. I also applied your algorithm to my own dataset, but encountered some issues during testing that I hope you can help clarify.

In my data, the mapping approach is as follows:
I used LiDAR + IMU + GPS for mapping. In this setup, continuous LIO pose results from LiDAR and IMU form the frontend, and the backend uses PGO (pose graph optimization) to fuse LIO poses with intermittent GPS measurements. These GPS points are filtered using the information matrix and only fixed solutions are inserted, ultimately constructing a global map.

For localization testing, I followed the sensor configuration provided in your open-source ELiMaLoc code. However, in my case, GPS signals are often affected by occlusions. Although the GPS feedback does not indicate a fixed solution, it still produces noisy jumps. This causes drift when updating the IMU prediction, resulting in a wavy trajectory after fusion.

My questions are:

1. How can LiDAR + IMU + GPS be effectively fused to obtain a global map like the one in ELiMaLoc?
   In my case, the PGO-fused result is just an optimized compromise between LIO and GPS poses. It generally follows the GPS trajectory but doesn’t match it precisely, which introduces a certain offset in the global map when used for localization.

2. How can GPS data be effectively utilized under intermittent reception and occlusion, so that GPS jumps don’t cause the fused trajectory to become wavy?