Ideas for localization package/extension based on GLIM

[hoangsep]

Hi all,

Since the localiztion package (GLIL) is proprietary, I am looking for ideas/guidance to write a localization package/extension based on GLIM by myself. Please share if you have any idea about how to achieve that.

Cheers,

[marmik18]

+1

[Alexasandrovich]

@hoangsep Hi! se7oluti0n (https://github.com/se7oluti0n) provided a summary of their approach for GLIM-based localisation. I will duplicate it here for further discussion and comments. Approach:

1. Glim is run in mapping mode, followed by the use of offline_viewer to manually add constraints for map correction.

2. The main modifications in the GlobalMapping module are as follows:

• The saved map is loaded, but instead of restoring the full factor graph, a GTSAM NonlinearEqualityFactor is created for each submap to freeze it during optimization.

• The OdometryEstimation Module and Submapping module remain unchanged.

• For relocalization, the initial pose is used to find a list of saved submaps near the initial pose, then the submaps with the highest overlap score with the current submap are selected. The exact pose is then determined using a three-level VGICP.

• After successful relocalization, for each new submap, the loop-closure constraint to a saved submap is found by comparing the overlap score and applying VGICP again.

• The PriorFactor confidence for the first submap in GlobalMapping is reduced to allow the FactorGraph to correctly adjust the pose during relocalization.

[Alexasandrovich]

I’ve tested this approach (https://youtu.be/kD990JR5S-8) and have a couple of observations that I think are worth discussing further:

1. Sensitivity to Initial Pose Orientation in Relocalization

A key issue I encountered is related to the directional bias of the recorded map. If the original map was created while moving in a specific direction (i.e., submap poses have consistent orientation), then relocalization from the opposite direction can lead to incorrect initial pose deltas. This can cause VGICP optimization to diverge or converge poorly due to mismatched overlap estimations.

To address this, the global localization process should ideally be invariant to orientation. This is also highlighted in related works:

• [GLIL paper (Koide, ICRA 2024)], which mentions dynamically loading a global localization module as a shared library:

  “We designed the framework so that it can dynamically load a global localization module from a shared library... any 3- or 4-DoF global localization algorithm can easily be incorporated.”

• See also this recent [preprint], which discusses the challenges of global localization under viewpoint changes.

This implies that incorporating a viewpoint-agnostic global localization step before selecting nearby submaps could greatly improve robustness.

2. Using hdl_global_localization as a Baseline

In the same GLIL paper, the authors suggest [hdl_global_localization] as a baseline global localization method. I’m currently exploring how to cleanly integrate this with [glim_ext], since it’s not immediately obvious how to do so.

If anyone has already tried this or has suggestions on integrating hdl_global_localization into the glim_ext pipeline (e.g., as a pre-processing step before relocalization), I’d be happy to discuss and contribute to such an effort

[marmik18]

Hey @Alexasandrovich even I am working on my implementation for localization, I am stuck on something, would you be open for discussion? Also, I could possibly make my code open so that we can collaborate on the same.

[VArt3m]

This implies that incorporating a viewpoint-agnostic global localization step before selecting nearby submaps could greatly improve robustness.

Perhaps even crude sampling-based approach would work for initialization - as in, trying different initial poses with rotation of e.g. 45 degrees between them and seeing which one converges better.

But yes, also curious about your implementation and willing to discuss collaborate.