안녕하세요 너무 좋은 리뷰 감사합니다! Recent map point culling부분에서 # of the frames the map point is visible은 map point를 feature로 가지고 있는 키프레임의 수 라고 이해했는데 # of frames the matching is found은 논문에 나오는map point의 a representative ORB descriptor와 매칭되는 프레임을 말하는 걸까요?
안녕하세요. 좋은 영상 감사합니다. 항상 잘보고 있습니다. 질문이 몇가지 있습니다. 1. 맵이라고 하는 Keyframe과 Mappoint는 무한정으로 생성되는 건가요? 유사하게 Loop을 위한 keyframe DB도 계속 생성되는건가요? 만약 그렇다면 시간에 따라 맵을 저장해야하는 메모리가 증가하고, 최적화 복잡도도 커지고 (global BA), 여러 연산량이 증가할 것 같은데요... 장시간 slam을 돌린다하면 문제가 될 것 같은데, ORB-SLAM으로는 Large-scale SLAM이 불가능한가요? ORB-SLAM 뿐만 아니라 다른 SLAM알고리즘에서는 이러한 문제가 없는지 궁금합니다. sliding window를 적용한다고 해도, loop closing 및 global pose graph 최적화를 위해선 전체 keyframe을 다 저장하고 있어야 할 것 같은데요... 2. tracking을 위한 3d-2d point correspondence 를 찾는 과정이 궁금한데, 현재 영상에서 추출된 피쳐와 맵에 저장된 모든 mappoint와 매칭을 하는 건가요?
1. Keyframe과 map point는 무한정 생성되는 것은 아니고 compact한 map을 관리하기 위해 불필요한것은 제거합니다. 그러한 과정을 culling이라고 하는데요. flowcharts에서 mappoint culling과 keyframes culling이라고 적힌 블록이 바로 그러한 부분입니다.
그럼에도 불구하고 말씀하신대로 large-scale (도시 규모) 로 가게되면 계산량이 기하급수적으로 증가하게됩니다. 이런 부분을 해소하기 위해 다양한 방법이 있겠지만 일정 블록 단위로 끊어서 최적화를 수행하거나 계층 구조를 만들어서 연산량을 줄이는 방법을 생각해볼수 있을것 같습니다.
2. 현재 영상에서 추출된 피쳐와 맵에 저장된 모든 map point들과 매칭을하면 map의 크기가 커짐에 따라 탐색시간이 기하급수적으로 증가하게 되어 좋은 방법은 아닙니다. (large scale의 경우에) 대신 현재 키프레임에 대해 global descriptor(bow vector와 같은)를 계산해서 처음시간부터 현재시간까지의 키프레임들에 대해 키프레임 DB를 지속적으로 만들어서 가지고 있다가 현재 키프레임에 대해서 키프레임 DB에서 일단 외형적으로 비슷한것을 찾은다음 찾은 키프레임이 보고 있는 3d map points들에 대해서만 nearest neighbor search를 하면 효율적으로 탐색할수 있습니다.
Superb, you're a life saver Dr Won
You did good job bro your english is great
Thanks for doing it in English. Good presentation
You help me a lot. thxx 😍
안녕하세요 너무 좋은 리뷰 감사합니다!
Recent map point culling부분에서
# of the frames the map point is visible은 map point를 feature로 가지고 있는 키프레임의 수 라고 이해했는데
# of frames the matching is found은 논문에 나오는map point의 a representative ORB descriptor와 매칭되는 프레임을 말하는 걸까요?
네네 말씀하시는게 맞습니다! 늦게 답변드렸네요 ㅠ 관심가져주셔서 감사합니다~!
안녕하세요. 좋은 영상 감사합니다. 항상 잘보고 있습니다.
질문이 몇가지 있습니다.
1. 맵이라고 하는 Keyframe과 Mappoint는 무한정으로 생성되는 건가요? 유사하게 Loop을 위한 keyframe DB도 계속 생성되는건가요?
만약 그렇다면 시간에 따라 맵을 저장해야하는 메모리가 증가하고, 최적화 복잡도도 커지고 (global BA), 여러 연산량이 증가할 것 같은데요...
장시간 slam을 돌린다하면 문제가 될 것 같은데, ORB-SLAM으로는 Large-scale SLAM이 불가능한가요?
ORB-SLAM 뿐만 아니라 다른 SLAM알고리즘에서는 이러한 문제가 없는지 궁금합니다.
sliding window를 적용한다고 해도, loop closing 및 global pose graph 최적화를 위해선 전체 keyframe을 다 저장하고 있어야 할 것 같은데요...
2. tracking을 위한 3d-2d point correspondence 를 찾는 과정이 궁금한데, 현재 영상에서 추출된 피쳐와 맵에 저장된 모든 mappoint와 매칭을 하는 건가요?
1. Keyframe과 map point는 무한정 생성되는 것은 아니고 compact한 map을 관리하기 위해 불필요한것은 제거합니다.
그러한 과정을 culling이라고 하는데요. flowcharts에서 mappoint culling과 keyframes culling이라고 적힌 블록이 바로 그러한 부분입니다.
그럼에도 불구하고 말씀하신대로 large-scale (도시 규모) 로 가게되면 계산량이 기하급수적으로 증가하게됩니다.
이런 부분을 해소하기 위해 다양한 방법이 있겠지만 일정 블록 단위로 끊어서 최적화를 수행하거나
계층 구조를 만들어서 연산량을 줄이는 방법을 생각해볼수 있을것 같습니다.
2. 현재 영상에서 추출된 피쳐와 맵에 저장된 모든 map point들과 매칭을하면
map의 크기가 커짐에 따라 탐색시간이 기하급수적으로 증가하게 되어 좋은 방법은 아닙니다. (large scale의 경우에)
대신 현재 키프레임에 대해 global descriptor(bow vector와 같은)를 계산해서
처음시간부터 현재시간까지의 키프레임들에 대해 키프레임 DB를 지속적으로 만들어서 가지고 있다가
현재 키프레임에 대해서 키프레임 DB에서 일단 외형적으로 비슷한것을 찾은다음
찾은 키프레임이 보고 있는 3d map points들에 대해서만 nearest neighbor search를 하면 효율적으로 탐색할수 있습니다.
혹시 도커 웹사이트 링크 받을 수 있을까요? 감사합니다!
아래의 링크를 확인하시면 됩니다!
hub.docker.com/r/celinachild/orbslam2
docker pull 하신다음에 readme에 적힌 명령어 따라하시면 될것 같네요 🙂