Open Toumi0812 opened 7 years ago
@Toumi0812 , orb-slam2 is an enhancement, a improved version of orb-slam based on experience.
They changed the ORB vocabulary for BoW, added a BA after loop closing. The code was rewritten with slightly better modularization.
Someone told me orb-slam2 doesn't publish pose on ROS.
I prefer orb-slam2, and I only use it in monocular.
@AlejandroSilvestri, Thank you very much, excuse for my entry level, how does ORB vocabulary work (I read the paper but I didn't completely understand it)? For me orb-slam2 publishes keyframes trajectory poses on ROS. In the paper (orb-slam2) I can see the addition of BA after loop closing, where can I find the ORB vocabulary change? so the three threads don't change. In #11 in the first answer of the author raulmur, do you the difference between the old method and new method on computing keypoints? One of my goals in my stage is to find the difference (if exists) between the two versions of orb-slam system. Thanks!!!
@Toumi0812 , they continue to be 3 threads (plus one for Viewer).
This BoW (bag of words) is a classification of BRIEF descriptors. The second vocabulary uses a different classification authors say is more suitable for visual slam.
About #11 , Raúl is talking about the initialization process. I forgot the differences, but they can be found comparing ComputeKeyPointsOld with ComputeKeyPoints.
If I remember correctly, System.cc and System.h didn't exist in orb-slam, they are new in orb-slam2.
Someone told me orb-slam2 doesn't publish actual frame pose in ROS, but I didn't check. And it shouldn't be difficult to add if necessary.
@AlejandroSilvestri, Thank you very much, I understand something now. The BoW is used to detect close loop. What is the mechanism?
@Toumi0812 ,
Descriptor matching is rather slow. BoW is a way to group descriptors, so if two BoW are different, descriptors doesn't match. It accelerate descriptor matching avoiding slow comparison between two descriptors with different BoW.
BoW is used to detect candidates for loop closing. When two keyframes share a lot of BoW, they are loop closing candidates. So, orb-slam avoids comparing every keyframe in map: it only compares candidates.
@AlejandroSilvestri, Thank you very much, reading the paper[DBoW2] I understood that collecting a lot of descriptors from a large set of images, build a database, for a new image (keyframe) we convert it into a BoW and check in the database for matches as you said. I don't understand in database building: "discretizing the descriptor space into W visual words", BoW=set of descriptors? What/How do we have to compare in the database to compare current image (converted into a BoW) ?
Thanks in advance
Each word in a Bag of Words is an int. They apply maching learning to create a BoW vocabulary for a specific type of descriptor, in this case BRIEF (the one used in ORB).
Each keyframe has a list of BoW words found in its image. orb-slam2 loops into these words and other keyframe's words, looking for matches: it counts how many matches are found. If enough matches are found, one keyframe is a candidate.
The actual process is a little more complex, involving BoW weight and pose check.
hey guys, i'm knew to this and i want to install ORB-SLAM3. what's the best link for this? I like to have a detailed installation instruction as i'm not familiar with this at all!
thanks, Sam
@ihamieh
I don't know of ORB-SLAM3. I believe you meant ORB-SLAM2. You don't need to know about visual slam, but you do have to know about Linux. This project main page have detailed installation instructions: install dependencies, clone orb-slam2 and build with cmake.
@AlejandroSilvestri thank you for your response! ORB-SLAM3 link: https://github.com/UZ-SLAMLab/ORB_SLAM3 I'll try it out and see how to do it! Thank you Alejandro!
@AlejandroSilvestri I've tried ORB-SLAM2 on my ubuntu 16 and I'm getting this error message when i run it:
i'm having the same error message and i'm not sure how to fix it!
ThinkPad-T440s:~$ rosrun ORB_SLAM2 MonoAR Vocabulary/ORBvoc.txt /media/ish/New\ Volume/dataset/rgbd_dataset_freiburg1_rpy
ORB-SLAM2 Copyright (C) 2014-2016 Raul Mur-Artal, University of Zaragoza. This program comes with ABSOLUTELY NO WARRANTY; This is free software, and you are welcome to redistribute it under certain conditions. See LICENSE.txt.
Input sensor was set to: Monocular OpenCV Error: Unknown error code -49 (Input file is empty) in cvOpenFileStorage, file /tmp/binarydeb/ros-kinetic-opencv3-3.3.1/modules/core/src/persistence.cpp, line 4484 terminate called after throwing an instance of 'cv::Exception' what(): /tmp/binarydeb/ros-kinetic-opencv3-3.3.1/modules/core/src/persistence.cpp:4484: error: (-49) Input file is empty in function cvOpenFileStorage
Aborted (core dumped)
Do you know anything about this?
Thanks, Ismail
Hi @ihamieh,
No, I'm not familiar with this error. I can see the message "Input file is empty".
ORB-SLAM2 uses a .yaml configuration file, I don't see it in your command.
Usually ORB-SLAM2 needs a configuration file .yaml, the vocabulary .txt and the dataset path. You are missing the first.
@AlejandroSilvestri thank you for your comment but I do follow the for ORB-SLAM2 with ROS as follows: $ rosrun ORB_SLAM2 Mono Vocabulary/ORBvoc.txt /home/ismail/bagfiles/UC_SP2_15sec.bag
but I get the following error message on OpenCV:
Input sensor was set to: Monocular OpenCV Error: Unknown error code -49 (Input file is empty) in cvOpenFileStorage, file /tmp/binarydeb/ros-kinetic-opencv3-3.3.1/modules/core/src/persistence.cpp, line 4484 terminate called after throwing an instance of 'cv::Exception' what(): /tmp/binarydeb/ros-kinetic-opencv3-3.3.1/modules/core/src/persistence.cpp:4484: error: (-49) Input file is empty in function cvOpenFileStorage
ORB-SLAM2 examples are running okay but not rosrun ORB-SLAM2 !!
I will post a new README, with a complete guide on how to run ORB-SLAM2 and ORB-SLAM3 pretty soon.
To answer the main question ORB-SLAM3 is an improvement on ORB-SLAM2, which is an improvement on ORB-SLAM. The main difference between ORB-SLAM 3 and ORB-SLAM2, as far as I know, is the ability to relocalize itself even when the tracking is lost and there is poor visual information. For me, this truly helps, and was able to close a map long after the tracking was lost. In fact, the tracking was lost once again, and it was able to localize itself again. I think this is the best one yet, and don't see a real need to use ORB-SLAM2 or 1.
Hello everyone, I installed the two versions of ORB_SLAM (my work is focused on ORB_SLAM1) I would like to know if there is any difference between ORB_SLAM1 and ORB_SLAM2 (Monocular) in map creation process (three threads, used modules, feature extraction, parameters... )? Is ORB_SLAM2 just the the extension of ORB_SLAM1 to RGB-D and Stereo with the same Monocular part?
Thanks!!!!