Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

different results when running the project more than once #45

Closed
sunstarchan opened this issue Mar 22, 2016 · 10 comments
Closed

different results when running the project more than once #45

sunstarchan opened this issue Mar 22, 2016 · 10 comments

Comments

@sunstarchan
Copy link

Hi @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.

@poine
Copy link

poine commented Mar 22, 2016

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 notifications@github.com 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

@sunstarchan
Copy link
Author

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);_

@sunstarchan
Copy link
Author

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.

@emphos1
Copy link

emphos1 commented Sep 2, 2016

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

@sunstarchan
Copy link
Author

@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.

@teenapjose
Copy link

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

@sunstarchan
Copy link
Author

@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.

@chaiein
Copy link

chaiein commented Jan 12, 2017

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?

@naja1987
Copy link

@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.

@sunstarchan
Copy link
Author

@naja1987

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants