inblog logo
|
DEEP.FINE 딥파인 기술 블로그

    실내 VPS 고도화: MegaLoc 기반 Retrieval과 LiDAR Map 정합으로 개선한 Visual Localization

    반복 구조와 부족한 특징점으로 위치 추정이 어려운 실내·지하 공간에서 VPS 정확도 개선을 위해 Visual Localization 구조를 고도화한 과정을 소개합니다.
    딥파인's avatar
    딥파인
    Jul 29, 2026
    실내 VPS 고도화: MegaLoc 기반 Retrieval과 LiDAR Map 정합으로 개선한 Visual Localization
    Contents
    1. 왜 실내 VPS는 어려운가?🚗실내·지하주차장 VPS의 어려움2. 기본 구조: HLoc 기반 Visual LocalizationHLoc 기반 Localization 테스트 결과잘못된 Reference Image가 검색되는 문제Feature Matching이 부족한 문제PnP 또는 Pose Estimation이 실패하는 문제3. 실패 원인을 확인하기 위한 단계별 로그4. 핵심 개선 1: MegaLoc 기반 Image Retrieval5. 핵심 개선 2: LiDAR Map과 Visual Map 정합6. 핵심 개선 3: LiDAR Map 연계 Hybrid Localization7. 핵심 개선 4: XR 적용을 위한 Pose Stabilization8. 선택 검토: MegaPose6D 기반 객체 6DoF Pose 확장마무리하며

    실내 VPS(Visual Positioning System)는 카메라로 촬영한 이미지를 바탕으로 사용자가 공간의 어디에 있고, 어느 방향을 바라보고 있는지를 추정하는 기술이다.

    기존에는 HLoc 기반의 Visual Localization 구조를 사용했다. 사용자가 촬영한 이미지인 query image를 입력하면, 저장된 이미지 중 같은 장소로 보이는 reference image를 찾는다. 이후 두 이미지의 특징점을 비교하고 PnP/RANSAC을 통해 카메라의 위치와 방향인 camera pose를 계산하는 방식이다.

    하지만 지하주차장처럼 비슷한 기둥과 벽, 주차선이 반복되고 이미지의 특징이 부족한 환경에서는 실제 위치와 다른 reference image가 선택되는 문제가 발생했다. Reference image가 적절하더라도 matching에 필요한 inlier가 충분히 확보되지 않아 pose estimation이 실패하는 경우도 있었다.

    이를 개선하기 위해 기존 HLoc 기반 구조는 유지하면서 image retrieval 단계를 MegaLoc 기반 구조로 교체했다. 또한 retrieval score, matching inlier, PnP inlier, pose estimation 결과를 로그로 저장해 위치 추정이 어느 단계에서 실패하는지 분석할 수 있도록 했다.

    이와 함께 이미지 기반으로 생성한 Visual Map과 LiDAR SLAM으로 생성한 LiDAR Map을 Sim3 alignment로 정합했다. 이를 통해 Visual Localization 결과를 실제 공간과 연결된 LiDAR Map 기준 좌표계에서 활용할 수 있도록 했다.

    이번 글에서는 실내 Visual Localization 과정에서 발생한 문제와 MegaLoc, LiDAR Map을 활용한 개선 구조를 살펴본다. 또한 향후 LiDAR Map 연계 Hybrid Localization, XR Pose Stabilization, MegaPose 기반 객체 6DoF pose 추정으로 확장하는 방향을 함께 소개한다.


    1. 왜 실내 VPS는 어려운가?

    실외에서는 GPS를 이용해 사용자의 대략적인 위치를 확인할 수 있다. 반면 실내나 지하 공간에서는 GPS 신호가 약하거나 사용할 수 없기 때문에, 카메라와 센서로 수집한 정보를 바탕으로 위치를 추정해야 한다.

    Visual Localization은 현재 카메라로 촬영한 query image를 사전에 구축한 Visual Map과 비교해 카메라의 위치와 방향을 찾는 기술이다.

    먼저 query image와 같은 장소를 촬영했을 가능성이 높은 reference image를 찾는다. 이후 두 이미지 사이의 특징점을 비교하고, 이미지의 2D 특징점과 지도에 저장된 3D point를 연결한다. 마지막으로 이 대응 관계를 이용해 camera pose를 계산한다.

    문제는 실내 공간에 시각적으로 비슷한 구조가 반복된다는 점이다.

    지하주차장을 예로 들면 서로 다른 구역에서도 기둥과 벽, 주차선의 배치가 비슷하게 보일 수 있다. 이 경우 시스템이 실제 위치와 다른 reference image를 같은 장소로 판단할 가능성이 있다.

    조명 변화와 낮은 texture도 위치 추정을 어렵게 한다. 지도 구축 당시에는 없었던 차량이나 사람이 query image에 포함되면 기존 reference image와의 공통 특징점도 줄어들 수 있다.

    🚗실내·지하주차장 VPS의 어려움

    • 반복되는 기둥과 주차선

    • 특징점이 적은 벽과 바닥

    • 낮은 texture

    • 조명과 노출 변화

    • 서로 비슷한 reference image

    • 차량과 사람 같은 동적 객체

    • 차량 등에 의한 시야 가림

    • 지도 구축 시점과 서비스 시점의 환경 차이

    • GPS 사용 불가

    이러한 환경에서는 query image와 단순히 ‘비슷해 보이는’ reference image를 찾는 것만으로는 부족하다. 실제로 같은 위치를 관측한 reference image가 검색돼야 하며, 이후 feature matching과 PnP 단계에서도 충분한 대응점이 확보돼야 한다. Retrieval부터 feature matching, PnP까지 모든 단계가 안정적으로 이어져야 정확한 camera pose를 얻을 수 있다.

    실내 주차장 환경을 LiDAR 포인트 클라우드로 구현한 3D 지도
    실내 주차장 환경을 LiDAR 포인트 클라우드로 구현한 3D 지도
    반복구간의 query image(왼쪽)와 reference image(오른쪽) 비교

    2. 기본 구조: HLoc 기반 Visual Localization

    초기 Visual Localization 구조는 HLoc 기반으로 구성했다.

    서버는 클라이언트에서 전송된 단일 query image를 입력받는다. 이후 Visual Map에서 유사한 reference image를 찾고, query image와 reference image 사이의 local feature를 비교한다.

    다음으로 이미지에서 찾은 2D 특징점과 Visual Map에 저장된 3D point 사이의 대응 관계를 만든다. 마지막으로 PnP와 RANSAC을 이용해 camera pose를 추정한다.

    전체적인 처리 흐름은 다음과 같다.

    쉽게 설명하면 다음과 같다.

    서버는 위치 추정 결과로 다음과 같은 정보를 반환한다.

    • Pose

    • Camera center

    • Quaternion

    • Translation

    • Matching inlier 수

    • PnP inlier 수

    • Pose estimation 성공 여부

    • Runtime

    이 결과는 Unity 또는 XR 클라이언트에서 AR 콘텐츠를 실제 공간에 정렬하는 데 사용된다. HLoc은 retrieval, feature extraction, feature matching, pose estimation을 각각 모듈 형태로 구성할 수 있다. 따라서 전체 pipeline을 다시 구현하지 않고도 특정 단계의 모델이나 설정을 교체해 성능을 비교할 수 있다.

    HLoc 기반 Localization 테스트 결과

    MegaLoc 적용 전 HLoc 기반 구조에서도 실제 query image를 대상으로 Localization 테스트를 진행했다.

    해당 테스트에서는 26개의 query image 모두에서 Localization에 성공했으며, query별 camera pose와 inlier 수, pipeline 단계별 runtime을 함께 확인했다. 로컬 네트워크 환경에서 측정한 이미지 1장당 평균 처리시간은 약 0.356초였다.

    또한 테스트 결과를 3D Viewer로 시각화해 각 query image에서 추정된 camera pose와 SfM Map 내 위치를 확인할 수 있도록 했다.

    HLoc 기반 Visual Localization 테스트 결과 화면

    다만, 지하주차장처럼 반복 구조가 많고 texture가 부족한 실내 환경에 적용하는 과정에서는 다음과 같은 문제가 확인됐다.

    잘못된 Reference Image가 검색되는 문제

    실제 위치와 다른 구역의 reference image가 높은 순위로 검색되는 경우가 있었다. 기둥과 주차선, 벽면의 형태가 반복되기 때문에 서로 다른 장소도 이미지 전체의 구조와 색상이 비슷하게 보일 수 있다.

    Feature Matching이 부족한 문제

    Reference image가 실제 위치와 가깝더라도 벽이나 바닥처럼 texture가 적은 영역에서는 충분한 특징점을 찾기 어려웠다. 지도 구축 당시에는 없었던 차량이나 사람이 query image를 가리는 경우에도 matching inlier가 감소했다.

    PnP 또는 Pose Estimation이 실패하는 문제

    2D-3D correspondence가 부족하거나 잘못된 대응점이 포함되면 PnP가 실패한다. 일부 경우에는 PnP 계산 자체는 성공했지만 실제 위치와 다른 pose가 반환되기도 했다. 잘못된 reference image를 기준으로 계산했다면 RANSAC을 통과한 대응점이 존재하더라도 최종 pose는 잘못될 수 있다.

    따라서 최종 pose estimation의 성공 여부만 확인하는 것으로는 정확한 실패 원인을 파악하기 어려웠다.


    3. 실패 원인을 확인하기 위한 단계별 로그

    Visual Localization은 image retrieval, feature matching, PnP가 순차적으로 연결되는 pipeline이다.

    따라서 최종 pose estimation이 실패했을 때 결과만으로는 어느 단계에서 문제가 발생했는지 판단하기 어렵다. 실제 위치와 다른 reference image가 검색됐을 수도 있고, 적절한 reference image를 찾았지만 matching이나 PnP 단계에서 충분한 inlier가 확보되지 않았을 수도 있다.

    이를 구분하기 위해 다음 결과를 로그로 저장했다.

    • Retrieval score

    • Matching inlier

    • PnP inlier

    • Pose estimation 성공·실패 결과

    이러한 로그를 통해 localization이 어느 단계에서 실패했는지 확인하고, retrieval 모델이나 matching 설정을 변경했을 때 각 단계의 결과가 어떻게 달라지는지 분석할 수 있도록 했다.


    4. 핵심 개선 1: MegaLoc 기반 Image Retrieval

    앞서 확인한 실패 원인을 바탕으로, 실내·지하 공간에서는 초기 image retrieval 단계에서 적절한 reference image를 찾는 것이 중요하다고 판단했다.

    잘못된 reference image가 선택되면 이후 feature matching과 PnP가 수행되더라도 정확한 camera pose를 얻기 어렵기 때문이다.

    이를 개선하기 위해 기존 retrieval 구조를 MegaLoc 기반으로 교체해 query image에 더 적합한 reference 후보를 찾도록 했다.

    기존 구조

    Query Image
    → 기존 Retrieval
    → Top-K Reference
    → Feature Matching
    → PnP

    개선 구조

    Query Image
    → MegaLoc Retrieval
    → Top-K Reference
    → Feature Matching
    → PnP

    MegaLoc 적용 전후에는 실제 위치에 적합한 reference image가 Top-K 후보에 포함되는지를 우선 확인했다. 또한 앞서 수집한 단계별 로그를 활용해 retrieval 결과의 변화가 이후 feature matching과 PnP, 최종 pose estimation까지 어떻게 이어지는지 함께 살펴봤다.

    즉, 이번 개선의 핵심은 단순히 retrieval 모델을 교체하는 것이 아니라, 더 적절한 reference image를 찾고 retrieval 결과의 변화가 이후 feature matching과 PnP, 최종 pose estimation에 어떤 영향을 주는지 함께 확인하는 것이다.


    5. 핵심 개선 2: LiDAR Map과 Visual Map 정합

    SfM 기반 Visual Map은 이미지로 만든 map이고, LiDAR Map은 LiDAR SLAM으로 만든 metric map이다.

    두 map은 서로 다른 좌표계를 가지므로 scale, rotation, translation 차이가 발생한다. 이를 맞추기 위해 Sim3 alignment를 적용한다.

    X_lidar = s × R × X_visual + t

    여기서 s는 scale, R은 rotation, t는 translation을 의미한다.

    Sim3 alignment를 거치면 Visual Localization으로 계산한 camera pose를 LiDAR Map 기준 좌표계로 변환할 수 있다.

    이 과정은 XR 콘텐츠를 실제 공간의 정확한 위치에 배치하기 위해 필요하다. 카메라의 위치와 방향이 상대적으로만 맞는 것이 아니라, LiDAR Map이 나타내는 실제 공간 좌표와 일치해야 안정적인 AR·XR 서비스를 구현할 수 있기 때문이다.

    image.png
    image.png

    6. 핵심 개선 3: LiDAR Map 연계 Hybrid Localization

    현재는 Visual Localization 결과를 Sim3를 통해 LiDAR Map 좌표계로 변환해 활용하고 있다. 향후에는 LiDAR Map의 3D point를 localization 과정에 직접 활용하는 Hybrid Localization 구조로 확장할 계획이다.

    이 구조는 Visual Localization의 image retrieval과 feature matching 방식은 유지하면서도, 최종 pose를 LiDAR Map의 metric coordinate 기준으로 얻을 수 있다는 장점이 있다. 즉, 이미지 기반 위치 인식의 강점과 LiDAR Map의 실제 공간 좌표 정보를 함께 활용하는 방식이다.

    다만 이를 구현하기 위해서는 해결해야 할 과제도 있다.

    Reference image에서 추출한 feature를 LiDAR Map의 3D point와 안정적으로 연결해야 하며, 연결된 point가 query view에서 실제로 보이는지를 판단하는 visibility 처리도 필요하다.

    7. 핵심 개선 4: XR 적용을 위한 Pose Stabilization

    VPS에서 계산한 pose를 Unity 또는 XR 클라이언트에 바로 적용하면 AR 콘텐츠가 순간적으로 움직이거나 튀는 현상이 발생할 수 있다.

    특히 단일 frame에서 추정한 VPS pose를 AR Origin에 즉시 반영하면, 작은 pitch나 roll 오차가 콘텐츠의 높이 변화로 크게 나타날 수 있다. Localization을 수행할 때마다 pose 결과가 조금씩 달라지면 AR 콘텐츠가 계속 흔들리는 것처럼 보일 수도 있다.

    이를 줄이기 위해서는 VPS pose를 단독으로 적용하지 않고, ARCore 또는 ARKit이 추적한 이동 경로와 함께 정렬하는 방식이 필요하다.

    AR Tracking Trajectory
    +
    VPS Pose
    → Trajectory Alignment
    → Smoothed AR Origin Correction
    → Stable AR Content

    ARCore와 ARKit은 기기의 프레임 간 움직임을 부드럽게 추적하지만, 시간이 지나면 오차가 누적될 수 있다. 반면 VPS는 Map 기준의 절대 위치를 제공할 수 있지만, 매 frame 결과를 제공하지 않으며 순간적인 오차가 포함될 수 있다.

    따라서 ARCore·ARKit의 연속적인 움직임 추적에 VPS의 절대 위치 보정값을 부드럽게 반영해야 한다.

    즉, 실제 XR 서비스에서는 위치를 정확하게 찾는 것뿐 아니라, 계산된 pose를 화면에 얼마나 자연스럽고 안정적으로 적용하는지도 중요하다.

    8. 선택 검토: MegaPose6D 기반 객체 6DoF Pose 확장

    VPS가 공간을 기준으로 카메라의 위치와 자세를 추정하는 기술이라면, MegaPose6D는 이미지 속 특정 객체의 6DoF pose를 3D mesh 기준으로 추정하는 확장 모듈이다.

    이를 활용하면 시설물, 장비, 안내 오브젝트처럼 사전에 3D mesh가 구축된 객체를 XR 환경에서 더욱 정밀하게 정합하는 방향으로 확장할 수 있다.

    마무리하며

    이번 연구의 핵심은 HLoc 기반 Visual Localization을 실제 실내·지하 공간에서 활용할 수 있는 VPS pipeline으로 확장하는 것이다.

    지하주차장처럼 반복 구조가 많고 texture가 부족한 환경에서는 하나의 모델만 개선한다고 해서 안정적인 localization을 구현하기 어렵다. 실제 위치에 적합한 reference image를 찾는 retrieval부터 feature matching, PnP를 통한 pose estimation까지 각 단계가 안정적으로 연결돼야 한다.

    또한 계산된 pose를 실제 XR 서비스에 활용하려면 Visual Map과 LiDAR Map의 좌표계를 정합하고, 최종 결과를 실제 공간 좌표 기준으로 해석할 수 있어야 한다. XR client에서는 VPS pose를 그대로 적용하는 데 그치지 않고, ARCore·ARKit의 tracking trajectory와 함께 보정해 콘텐츠가 자연스럽고 안정적으로 유지되도록 해야 한다.

    결국 실내 VPS의 성능은 단일 모델의 정확도만으로 결정되지 않는다. 적절한 reference image를 찾는 retrieval, 안정적인 feature matching, 신뢰할 수 있는 PnP, LiDAR Map 기준 좌표계, XR client의 pose stabilization이 하나의 pipeline으로 연결될 때 실제 서비스에서 활용할 수 있는 Visual Localization 구조가 완성된다.

    향후에는 LiDAR Map의 3D point를 localization 과정에 직접 활용하는 구조와, 3D mesh가 구축된 시설물·장비를 정밀하게 정합하는 MegaPose6D 기반 확장 가능성도 함께 검토할 수 있다.


    Share article
    Contents
    1. 왜 실내 VPS는 어려운가?🚗실내·지하주차장 VPS의 어려움2. 기본 구조: HLoc 기반 Visual LocalizationHLoc 기반 Localization 테스트 결과잘못된 Reference Image가 검색되는 문제Feature Matching이 부족한 문제PnP 또는 Pose Estimation이 실패하는 문제3. 실패 원인을 확인하기 위한 단계별 로그4. 핵심 개선 1: MegaLoc 기반 Image Retrieval5. 핵심 개선 2: LiDAR Map과 Visual Map 정합6. 핵심 개선 3: LiDAR Map 연계 Hybrid Localization7. 핵심 개선 4: XR 적용을 위한 Pose Stabilization8. 선택 검토: MegaPose6D 기반 객체 6DoF Pose 확장마무리하며

    DEEP.FINE 딥파인 기술 블로그

    RSS·Powered by Inblog