different results when running the project more than once about orb_slam2 HOT 10 CLOSED

@sunstarchan @teenapjose I digged more into the problem of different keypoint extraction results. And I found that the call to sort() in https://github.com/raulmur/ORB_SLAM2/blob/master/src/ORBextractor.cc#L684 was the issue.
Here the vector vector<pair<int,ExtractorNode*> > is sorted where int is the number of keypoints per Node and the ExtractorNode* the pointer to the corresponding node in the lNodes list. And the second part is the issue. When two nodes have the same number of keypoints, sort() uses then the pointer to decide which comes first. But as a list isn't storing its members sequentially in memory, on every run the pointers are totally different and so the result of the sorting will be different.

from orb_slam2.

@teenapjose

one reason of getting different keypoints after calling DistributeOctTree is that there 4 if conditions
https://github.com/raulmur/ORB_SLAM2/blob/master/src/ORBextractor.cc#L620
https://github.com/raulmur/ORB_SLAM2/blob/master/src/ORBextractor.cc#L690

if the compiler optimization is enabled, then the running sequence of these 4 if is not guaranteed. But this will not cause too much difference. In my case, there just about 4 keypoints different.

Except for random number, multiple threads is another reason the result various. It is related to system overload.

from orb_slam2.

Hi Chan

looks like there is:

poine@ella ~/work/ORB_SLAM2 $ grep -ri rand src/
src/Sim3Solver.cc:#include "Thirdparty/DBoW2/DUtils/Random.h"
src/Sim3Solver.cc: int randi = DUtils::Random::RandomInt(0,
vAvailableIndices.size()-1);
[...]
src/PnPsolver.cc:#include "Thirdparty/DBoW2/DUtils/Random.h"
src/PnPsolver.cc: int randi = DUtils::Random::RandomInt(0,
vAvailableIndices.size()-1);
src/PnPsolver.cc: int idx = vAvailableIndices[randi];
[...][
src/Initializer.cc:#include "Thirdparty/DBoW2/DUtils/Random.h"
src/Initializer.cc: DUtils::Random::SeedRandOnce(0);
src/Initializer.cc: int randi =
DUtils::Random::RandomInt(0,vAvailableIndices.size()-1);

poine@ella ~/work/ORB_SLAM2 $ grep -ri ransac src/
src/Sim3Solver.cc: SetRansacParameters();
src/Sim3Solver.cc:void Sim3Solver::SetRansacParameters(double probability,
int minInliers, int maxIterations)
src/Sim3Solver.cc: mRansacProb = probability;
[...]

HTH

Poine

On Tue, Mar 22, 2016 at 2:58 AM, Chan Ming [email protected] wrote:

Hi @raulmur https://github.com/raulmur

When I run mono_kitti example with the 3rd dataset, I find the result is
different when running more than once, even I change whole project to
single thread.

Is there any random processing that causes these difference?

Thanks.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#45

from orb_slam2.

Yes, I notice these code of random.

But currently I just want to check the first two images. and I notice that before calling DistributeOctTree in ORBextractor.cc, the input is the same, but after this calling, keypoints is not the same. The order is changed, which results in different matches. Do you know this?

    _keypoints = DistributeOctTree(vToDistributeKeys, minBorderX, maxBorderX,minBorderY, maxBorderY,mnFeaturesPerLevel[level], level);_

from orb_slam2.

by the way, I notice you use sort or set with input of pointers, so when the first element is the same, it is going to compare the pointers, which I think is not correctly used.

from orb_slam2.

Hi @sunstarchan
You have mentioned "I change whole project to a single thread". Could you please let me know how?
Best

from orb_slam2.

@emphos1

As you know, in System.cc constructor of class System, there creates three thread for local mapping, loop closing and view. So with the main thread, there are four thread in total.

local mapping thread is invoked whenever there is a key frame inserted. so in order to avoid this thread, I rewrite the LocalMapping::InsertKeyFrame function to include all processing of LocalMapping::Run() in while(1). The same for loop closing.

for viewer, I just show the result after processing one frame. I think it's more easier to implement. then if you have any problems, just let me know.

from orb_slam2.

Hi @sunstarchan ,

I'm working on ORB SLAM right now and am totally new to it . I'm also facing the same issue of getting different keypoints after calling DistributeOctTree eventhough the inputs given are same. Could you please clarify how you rectified it.

Thanks

from orb_slam2.

I noticed the change while its loop is detected, First time it continued tracking after the loop detection, but after that, that is after more than once execution using the same kitti data set, the program ends. why is it so?

from orb_slam2.

@naja1987

Thanks for your explanation. I think this issue can be closed now.

from orb_slam2.