pose graph optimization not always converge

[highlightz]

I test the program with EuRoC dataset MH_01_easy, where there exists several loops. And the pose graph optimization iteration times is set to 5(as default), and the keyframe database size is 400(as default). I test for tens of times. Sometimes after a loop is detected and pose graph optimization performed, the drift(e.g. postion) converges to a smaller one than before optimizing; but this does not always happen. There are several times pose graph optimiztion does not converge at all, or converge (to a local optimization I guess) to an unreasonable state with big drift. I want to know why this happen, and how can I get a stabe performance of the loop closure?

[highlightz]

An even worse performance on MH_02_easy is like this:

[qintonguav]

Update to the newest version.

[qintonguav]

The performance should be like that in newest version.

[highlightz]

I pull your updated repo and run with MH_02_easy, gettting below result:

[highlightz]

The same thing happens at MH_01_easy too, i.e. after a converged pose graph optimization, the estimated trajectory is not smooth, as can be seen below:

[highlightz]

Is is because my PC' s computation power is not enough? (Intel Core i5-4570 CPU @ 3.20GHz × 4)

[qintonguav]

Are you using the virtual machine?

In fact, it can have the much better result with i5 U 2.2GHz.

[qintonguav]

Because only a few frames are added to the pose graph, the pose graph is very sparse. So the trajectory is not smooth.

We add frames into pose graph according to computation resources. If the computation resource is so limited, we add frames into pose graph in a lower frequnecy and downsampe the pose graph.

[highlightz]

Not a virtual machine. So I'd better try with a higher frequency of adding frames?

[qintonguav]

That's the result running on my laptop(i5 U 2.2G) without any code modification. Actually, your CPU is much more powerful than my laptop. So strange ... You can disable the loop closure function, by setting the loop_closure to 0.

[highlightz]

Thanks for your time and great patience. In fact, your implementation is good enough and I've tested with loop closure function off using your last version where the trajectory precision is already very acceptable. I will make more check for my experiment, and if I find the reason, I will let you know.