1
$\begingroup$

As far as I know, OctoMap or any other grid occupancy maps are only for mapping. How do they handle a loop closure problem?

The first method came to my mind is optimizing a pose graph in the backend and send the corrected map to grid map library to fuse and build the map again from the beginning. But I dought that they do this. What's the secret?

$\endgroup$
2
$\begingroup$

There is no secret. OctoMap was not really designed with pose refinement in mind. You can even see one of the authors of RGBD-SLAM mention it here.

If you did want to try and still use octomap with loop closure then the approach that you mention could work. You could probably make it a bit more efficient by only deleting the poses in Octomap that were affected by the loop closure.

One possibility you could also use is to utilize the probabilistic aspect of OctoMap. On your first run set the pointclouds to have a very low probability. With the loop closure update you then add another set of pointclouds with a much higher probability. Octomap will take care of the fusing for you so this idea could work.

If you do ,however, want mapping software that is built to deal with changing poses due to loop closure and bundle adjustment then I would advise you to look into Thomas Wheelans work on deformable pose graphs specifically with Bundlefusion and Elasticfusion.

$\endgroup$
1
  • $\begingroup$ Thanks for the clear answer! Actually, I published one paper that applied the Elasticfusion approach to LiDAR and was wondering how the old map-centric (which fuses all the measurement to map) handled the loop closure problem. $\endgroup$ – C.O Park Apr 2 '18 at 18:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.