기존 SLAM 시스템들의 단점(?)

kinfuLS는 만든 사람들도 얘기했고, TUM 대학의 벤치마크 데이터 중 floor 데이터 집합을 돌려보면 알겠지만

깊이값 변화가 별로 없는 영상에서는 lost가 많이 난다. 실시간 입력영상으로 돌려봐도 lost가 쉽게 발생해서 수행하다보면 짲응..

그리고 소스 자체의 문제점 중에 하나는 evaluation 모드일 때 원소스로는 실행이 안되고, 

pcl mailinglist에서 조언한대로 grab 함수를 가지고 코드 오류를 수정해줘야한다는 것이다.

그리고 part1~3까지로 나뉘어져서 pcd 추출까지의 작업, mesh작업, texture mapping 작업을 따로따로 실행을 해줘야 하는 불편함이 있기 때문에 mesh 작업까지는 코드를 통합하는 것도 나쁘지 않은 것 같다. mesh 추출하는 것까지는 pcl 내에 코드가 있기 때문에...

mesh 쪽 코드는 어렵지 않아서 금방 합칠수있다.

다만, 쪼개져있는 mesh 조각들을 하나의 mesh로 합쳐버리는 거는 meshlab을 빌려서 하고 있기 때문에 pcl내에 코드가 없다.

이게 불편하면 meshlabserver를 이용해서 cmd창 한방으로 끝낼 수 있다. 이건 meshlabserver에서 사용할 수 있는 스크립트를 짜놓으면 쉽게 할 수 있다. 이것들을 배치파일로 다 만들어서 아예 코드 내부에 넣어버리면 전체 통합이 될것같기도 하고.. 

 

fovis는 inlier가 미달나면 오도메트리 값을 이전 값과 동일하게 반환하는데, 일반적인경우에는 별 문제가 없고,

TUM 대학의 벤치마크 데이터 중 파이오니아 로봇으로 촬영한 slam1~3 영상같은거 돌려보다보면 문제가 생긴다.

inlier가 연속해서 미달이 되니까 로봇이 급격히 움직이고 있음에도 계속 제자리에 있는것처럼 값을 반환해서 실제 경로 추적에 오류가 누적된다.

나는 이부분을 좀(아주 단순하게) 손봐서 fovis의 lost(?)를 30% 정도 줄였다.

대단한 알고리즘을 건드리는 것이 아니기 때문에, 간단한 아이디어 넣어서 개인이 좀 수정해도 될 것 같다.

 

dvo-slam은 .. 걍 수행 시간이 드릅게 오래걸려서 별로다. 근데 이건 병렬 처리 수행이 잘 안되고 있기 때문일 가능성이 크다고 하신다. 결국 내가 코드를 잘 모르는상태로 윈도우로 포팅하고 kinfuLS랑 마구잡이로 합쳐버려서 코드가 비빔밥이 되버린거다. 비빔밥 속을 들여다 보니 아무 생각도 나지 않아 이건 사용하고 싶지 않다...