Request for Ground Truth Trajectory Generated by PAloc for the FusionPortable Dataset

[ljy-zju]

Dear Dr. Hu,
Thank you so much for sharing the PAloc algorithm and making your work open-source! It has been incredibly helpful for the research community.

While working with the FusionPortable dataset, I noticed that the ground truth trajectory provided for the escalator_day sequence contains significant jitter. This makes it less suitable for evaluating odometry accuracy. To address this issue, I tried generating a more accurate trajectory locally using your PAloc algorithm.

However, due to the limited performance of my personal computer, the process is extremely slow (approximately 1 second per frame), making it challenging to complete the entire sequence in a reasonable amount of time.

I would like to kindly ask if you could provide the ground truth trajectory generated by PAloc for the escalator_day sequence, as well as for the other sequences in the FusionPortable dataset, if possible. Having these trajectories would greatly help in accurately evaluating odometry performance across multiple scenarios.

Thank you again for your excellent work and support!

Looking forward to your reply.
Best regards!

[JokerJohn]

@ljy-zju
Hi, thanks for your interest.
If you're experiencing slow performance, I suggest adjusting the map_filter_size parameter to 0.1, as it should not significantly affect trajectory accuracy. As for the FusionPortable dataset sequences, I haven't organized them yet, so it may take some time.

[ljy-zju]

I’m feeling really frustrated because last night I ran the long experiment sequence of the NCD dataset, hoping to obtain the ground truth, but it still crashed midway. It seems my computer’s configuration is too low, and I’m feeling pretty helpless. I believe I’ve already set the map_filter_size to 0.2, and when playing the rosbag, I’ve set the playback rate to -r 0.1. My physical memory and virtual memory are both 32GB.

[JokerJohn]

@ljy-zju
If you are referring to the "parkland" sequence in the NCD dataset, I recall that it is split into several segments. When merged all together, the data collection time is indeed quite long. Since PALoc generates poses frame by frame, with the default configuration and my comoputer having 96GB of RAM, it is not possible to generate the full trajectory for this dataset because there are too many point cloud frames with 128 or 64 beams. I recommend the following:

1. Generate the trajectory in segments. As long as the prior map remains unchanged, the trajectories will be in the same coordinate system.
2. Select keyframes to generate a sparse ground truth trajectory.

If option 2 meets your needs, I can update the code accordingly.

[ljy-zju]

Is it possible to have a switch functionality to choose whether to keep a global map generated by PAloc? This way, the cumulative map does not need to be stored in the system's memory, freeing up enough space.

[JokerJohn]

@ljy-zju
In fact, PALoc only performs the full map merging in memory when the rosservice command is called to save all the data and the map. During runtime, it only saves the necessary point clouds for each frame. The memory only stores a sparse point cloud map for visualization purposes. You can adjust the visualization in RViz using the map_viewer_size parameter, with a default sampling size of 0.2 meters. This is not the main reason to memory usage. For computers with smaller memory, I also recommend closing RViz after the system has successfully run.

[ljy-zju]

I will try it tonight. Thank you!