search

ethz-asl / maplab

A Modular and Multi-Modal Mapping Framework
https://maplab.asl.ethz.ch
Apache License 2.0
2.55k stars 722 forks source link

Anchoring missions sequentially #159

Open GilSerrano opened 4 years ago

GilSerrano commented 4 years ago

Hi!

I was trying to merge and anchor 3 missions and noticed something.

If the missions are loaded and merged first and only after the commands sbk and aam are run, the TGMs are computed fine and everything works (just like on the wiki tutorial Preparing a multi session map).

However, I tried a different approach. I loaded one mission and ran sbk. Then I ran load_merge_map to merge a second mission and then aam to compute its TGM in relation to the first mission. The following is the output I got:

No loop found! Probe did not meet criteria, not merging mission f185..0000 Failed to anchor mission f185..0000, pushing it back to the work-list.

I tried loading one more mission and running aam and got the same result.

Should it not be able to find loop closures (and therefore TGMs) in this sequential approach, just like it does when every mission is loaded and merged first? Do you know why it only works that way? Any ideas on how it could be done sequentially?

Thanks!

GilSerrano commented 4 years ago

I have also noticed that if there are 2 merged missions with unknown baseframes, the mission that is chosen to have its baseframe set to known by sbk --map_mission="_mission_id_" has influence on whether aam is able to find loop closures and TGMs.

I have used 2 missions, merged them, used sbk on the first mission and aam to find the second mission's TGM, but maplab is not able to find loopclosures. Then, using the same 2 missions, I used sbk on the second mission and used aam to find the first's TGM. This way, maplab is able to find loop closures and compute the TGM.

The fact that this choice matters seems odd to me, since if one way finds loop closures, the other should too I believe.

mfehr commented 4 years ago

Hi @GilSerrano Thanks for the report, that does indeed sound like a bug. I remember, however, that we have encountered a bug in aam quite a while ago and have fixed it in private version, maybe it is this one. But I would need to check whether this fix made it into one of the release candidates or not. What version are you using and did you perform these tests on the datasets we provided in the wiki?

GilSerrano commented 4 years ago

Hi, I was using the March 2018 version and the EuRoC Machine Hall dataset. I have also noticed that sometimes, even if loopclosures are found either way, the number of loopclosures found depends on the choice of the mission that is used for sbk --map_mission="_mission_id_".