[자율주행] 측위와 SLAM — 에고 포즈는 어디서 오는가

씬 데이터에서 씬의 구성 요소를 셀 때 에고 포즈를 넣었고, 3D 기하에서 좌표 변환의 사슬을 그릴 때도 에고 포즈가 마지막 고리였다. 그런데 그게 어떻게 만들어지는지는 한 번도 다루지 않았다.

이건 작은 누락이 아니다. 시리즈에서 이야기한 것들이 전부 여기에 걸려 있다.

• 앞뒤 스윕을 누적해 점군을 촘촘하게 만드는 것
• 모션 보정 — 스윕 안에서 차가 움직인 만큼 되돌리기
• 정지물과 이동물을 가르는 것 (상대 속도에서 자기 속도를 빼야 한다)
• 사람이 누적 점군 위에 그리는 3D 박스의 정확도

에고 포즈가 흔들리면 이 전부가 같이 흔들린다. 그래서 측위는 인지 팀의 일처럼 보이지만 실제로는 데이터 품질의 상한을 정하는 층이다.

먼저 프레임이 왜 셋인가

로그를 열면 map, odom, base_link 세 좌표 프레임이 나온다. 처음 보면 왜 이렇게 나눠 놨는지 이해가 안 되는데, 이게 측위의 핵심 설계다.

map ──────────▶ odom ──────────▶ base_link
 절대 · 점프함    연속 · 드리프트함    차 자신

• odom → base_link — 오도메트리. 휠·IMU·라이다로 누적한 상대 이동이다. 연속적이고 부드럽다. 절대 안 튄다. 대신 시간이 지나면 드리프트한다(1km 달리면 몇 m 어긋난다).
• map → odom — 지도 기반 측위가 만든 보정. 절대 위치를 맞춰주지만, 새 관측이 들어올 때마다 점프할 수 있다.

왜 나눠야 하나. 제어는 부드러운 연속 신호가 필요하다. 측위가 20cm 튄 것을 그대로 조향에 넣으면 차가 움찔한다. 그래서 가까운 미래의 제어는 odom 프레임에서, 지도·경로 같은 절대적인 것은 map 프레임에서 다룬다.

데이터 쪽에서 이게 왜 중요한가 — 어느 프레임의 포즈를 썼는지에 따라 결과가 달라진다. 짧은 구간의 점군 누적은 odom이 낫고(부드러움), 여러 주행을 겹치는 것은 map이어야 한다(절대 기준). 로그와 라벨에 프레임을 명시하지 않으면 나중에 아무도 못 가린다.

재료 — 무엇으로 포즈를 만드나

어느 하나로는 안 된다. 각자 다른 방식으로 틀린다.

스캔 매칭 — 라이다가 이동량을 재는 법

연속한 두 점군을 겹쳐서 "얼마나 움직였으면 이렇게 겹치나"를 푸는 문제다.

• ICP — 가장 가까운 점끼리 짝지어 오차를 줄이는 걸 반복한다. 직관적이지만 초기값에 민감하다.
• NDT — 공간을 격자로 나눠 각 칸의 점 분포를 정규분포로 근사하고, 그 확률을 최대화한다. ICP보다 초기값에 관대하고 빠르다. 양산 측위에서 많이 쓴다.
• 특징 기반(LOAM 계열) — 모서리와 평면 특징만 뽑아 맞춘다. 훨씬 빠르다.

융합 — 어떻게 합치나

칼만 필터 계열(EKF/UKF) 이 고전적 답이다. IMU로 고주파 예측을 하고, GNSS·라이다 관측이 들어올 때마다 보정한다. 각 관측의 불확실성(공분산)에 따라 가중치가 자동으로 정해진다는 게 핵심이다.

최근에는 팩터 그래프 방식이 늘었다. 포즈들을 노드로, 관측을 제약(팩터)으로 두고 전체를 한꺼번에 최적화한다. 필터가 "지금까지의 요약"만 들고 가는 데 비해, 그래프는 과거를 다시 고칠 수 있다. 이 성질이 다음 절에서 결정적이다.

SLAM — 지도를 만들면서 그 안에서 나를 찾기

SLAM은 지도가 없는 상태에서 지도와 자기 위치를 동시에 만드는 일이다. 자율주행에서는 보통 두 갈래로 쓰인다.

• 오프라인 매핑 — 매핑 차량으로 돌면서 정밀 포인트 맵을 만든다. 이게 나중에 양산차 측위의 기준이 된다.
• 온라인 SLAM — 지도가 없는 환경(주차장 등)에서 실시간으로.

루프 클로저

SLAM의 심장이다. 한 바퀴 돌아 아까 왔던 곳에 다시 왔다는 걸 알아채면, 그 사이 누적된 드리프트를 전부 되돌려 펼 수 있다.

드리프트 누적 →   ╭────────────╮
                 │            ╰─── 시작점에서 3m 어긋남
                 ╰──────────╯

루프 클로저 후 →  ╭────────────╮
                 │            │  ← 같은 곳임을 알아채고
                 ╰────────────╯     전체 궤적을 다시 최적화

이걸 포즈 그래프 최적화라고 하고, 여기서 나온 포즈가 온라인 포즈보다 훨씬 정확하다. 다음 절이 이 사실 위에 서 있다.

데이터 엔지니어가 반드시 알아야 할 것

온라인 포즈와 리파인 포즈는 다른 물건이다

차에서 실시간으로 나온 포즈는 과거를 못 고친다. 그 순간까지의 정보만 쓴다.

반면 주행이 끝난 뒤 오프라인에서 루프 클로저와 전역 최적화를 돌려 다시 만든 포즈(리파인 포즈)는 훨씬 정확하다. 미래 관측까지 쓸 수 있기 때문이다. 오토라벨링이 사람보다 나을 수 있는 것과 정확히 같은 이유다.

그래서 실무의 규칙:

• 라벨링과 학습 데이터 생성은 리파인 포즈로 한다. 온라인 포즈로 누적한 점군은 두 겹으로 보이고, 그 위에 그린 박스에는 오차가 그대로 박힌다.
• 인지 알고리즘 평가는 온라인 포즈로 한다. 차가 실제로 알 수 있었던 정보만 써야 공정하다.
• 둘을 섞으면 조용히 틀린다. 그래서 포즈에도 버전과 종류를 붙여야 한다.

pose_source: online | refined
pose_version: v3

이건 데이터 버저닝과 같은 급의 메타데이터다. 라벨이 어느 포즈 위에서 만들어졌는지 모르면 재현이 안 된다.

로그에 무엇을 남길 것인가

포즈 값만 남기면 사후 분석이 막힌다. 함께 남길 것들:

• 공분산 — 그 순간 시스템이 스스로를 얼마나 믿었는가. 측위가 나빴던 구간을 찾는 유일한 단서다.
• GNSS 상태 — RTK fix / float / 단독. 지하주차장 진입 구간을 자동으로 골라낼 수 있다.
• 점프 이벤트 — map → odom 보정이 크게 튄 순간. 여기서 만들어진 라벨은 의심해야 한다.
• 어느 프레임 기준인지 — 앞에서 말한 그것.

이게 있으면 "측위가 흔들린 구간을 라벨링 대상에서 제외" 같은 규칙을 SQL로 쓸 수 있다. 없으면 사람이 눈으로 찾아야 한다.

정밀도가 무너지는 곳

절대 좌표(UTM 등)는 수십만 m 단위다. float32로는 표현 간격이 수 cm로 벌어진다. 포즈를 저장할 때는 float64를, GPU로 보낼 때는 원점을 옮긴 상대 좌표를 쓴다. 뷰어에서만의 문제가 아니라 저장 스키마의 문제이기도 하다.

자주 겪는 실패

• 터널·지하주차장 — GNSS가 끊기고 라이다 특징도 반복적이라 드리프트가 급격히 는다.
• 고층 협곡 — GNSS 멀티패스로 위치가 수십 m 튄다. 끊기는 것보다 틀린 값이 확신을 갖고 들어오는 게 더 위험하다.
• 개활지·긴 터널 — 스캔 매칭이 붙잡을 특징이 없다. 앞뒤가 다 똑같이 생겼다.
• 동적 환경 — 주변이 전부 움직이는 차라면(정체 구간) 스캔 매칭이 그 차들을 배경으로 오인한다.
• 지도 노후 — 공사로 지형이 바뀌면 지도 정합이 조용히 어긋난다.

이 구간들의 공통점은 포즈 품질이 나쁜데 시스템이 그걸 모를 수 있다는 것이다. 그래서 공분산과 상태 플래그를 남기는 게 중요하다.

정리

• 에고 포즈는 씬 정의·모션 보정·점군 누적·라벨 품질의 공통 상한이다.
• 프레임이 셋인 이유가 있다 — odom은 연속하지만 드리프트하고, map은 절대적이지만 점프한다. 용도가 다르다.
• 어느 하나의 센서로는 안 된다. GNSS·IMU·휠·라이다·카메라를 칼만 필터나 팩터 그래프로 합친다.
• SLAM의 루프 클로저가 드리프트를 되돌린다. 그래서 오프라인 리파인 포즈가 온라인 포즈보다 정확하다.
• 라벨은 리파인 포즈로, 평가는 온라인 포즈로. 섞으면 조용히 틀린다. 그래서 포즈에도 버전이 필요하다.
• 포즈 값만 남기지 말고 공분산·GNSS 상태·점프 이벤트를 함께 남긴다. 그래야 나쁜 구간을 질의로 걸러낸다.

이어서 볼 글: 센서가 무엇을 재는지는 센서 물리, 좌표 변환의 근간은 3D 기하 기초, 이 포즈 위에서 만들어지는 정답은 어노테이션 데이터에서 다룬다.