로봇 시스템 안에는 좌표계가 하나만 존재하지 않습니다.
카메라에는 카메라 좌표계가 있고, LiDAR에는 LiDAR 좌표계가 있고, 로봇 몸체에는 로봇 몸체 좌표계가 있고, 바퀴의 회전이나 로봇의 이동은 또 다른 기준에서 표현됩니다. 여기에 world, map, odom 같은 상위 좌표계까지 더해지면 로봇은 말 그대로 여러 좌표계가 동시에 존재하는 세계 안에서 움직이게 됩니다.
문제는 여기서부터 시작됩니다.
센서는 각자 자기 기준으로 데이터를 내보내는데, 로봇이 실제로 판단하고 움직이려면 이 데이터를 하나의 기준으로 해석할 수 있어야 합니다. 예를 들어 카메라가 본 물체를 로봇 팔 기준으로 바꾸어야 집을 수 있고, LiDAR가 본 장애물을 로봇 몸체 기준으로 바꾸어야 충돌을 피할 수 있습니다.
즉, 좌표계가 여러 개 있다는 사실만으로는 부족합니다.
그 좌표계들 사이의 관계를 알아야 합니다.
바로 이 역할을 해주는 것이 TF(Transform) 입니다.
TF는 무엇인가
TF는 여러 좌표계 사이의 변환 관계를 다루기 위한 개념이자, ROS에서 이를 관리하기 위한 핵심 도구입니다.
조금 더 직관적으로 말하면, TF는 이런 질문에 답하기 위해 존재합니다.
- 카메라는 로봇 몸체에서 어디에 달려 있는가
- LiDAR는 base_link 기준으로 어느 위치에 있는가
- 지금 로봇의 몸체는 map 기준으로 어디에 있는가
- 바퀴가 굴러가며 변한 자세는 어느 프레임 기준인가
- 어떤 센서가 본 점을 다른 프레임으로 바꾸면 어디가 되는가
결국 TF는
“어느 프레임에서 본 위치와 방향을, 다른 프레임 기준으로 바꾸는 것”
이라고 이해하면 됩니다.
이때 변환에는 단순히 위치만 들어가는 것이 아닙니다.
회전도 함께 포함됩니다.
왜냐하면 좌표계가 다르다는 것은 단순히 원점이 다른 것만이 아니라, 축의 방향도 다를 수 있기 때문입니다. 그래서 프레임 간 변환은 보통 다음 두 가지를 함께 다룹니다.
- 위치(Position): x, y, z
- 회전(Rotation): roll, pitch, yaw 또는 quaternion
즉, TF는 로봇 시스템 안에서 완전한 6자유도 변환 정보를 다루는 구조라고 볼 수 있습니다.
좌표계가 많아질수록 TF가 더 중요해진다
간단한 예를 하나 생각해보겠습니다.
로봇 몸체 위에 카메라가 달려 있고, 그 카메라가 어떤 물체를 감지했다고 해보겠습니다.
카메라는 자기 기준으로 “물체가 전방 0.8m, 약간 오른쪽에 있다”는 식의 정보를 갖고 있을 겁니다.
그런데 이 정보를 그대로는 쓸 수 없습니다.
왜냐하면 물체를 실제로 집거나 피하거나 추적하려면,
카메라 기준 좌표가 아니라 로봇 몸체 기준 좌표, 혹은 상황에 따라 로봇 팔 끝단 기준 좌표로 바뀌어야 하기 때문입니다.
여기서 필요한 것이 바로 TF입니다.
카메라와 로봇 몸체의 상대 위치와 방향을 알고 있다면, 카메라가 본 물체 위치를 로봇 몸체 기준으로 변환할 수 있습니다. 그리고 로봇 몸체와 로봇 팔, 또는 world 좌표계와의 관계까지 알고 있다면, 같은 물체를 다른 어떤 프레임 기준으로도 다시 표현할 수 있습니다.
즉 TF의 핵심은 단순합니다.
각 프레임이 서로 어떻게 연결되어 있는지만 알면,
어느 프레임에서 측정된 데이터든 다른 프레임 기준으로 해석할 수 있다는 점입니다.

TF는 프레임 사이의 관계를 트리처럼 다룬다
로봇 시스템의 프레임들은 서로 무작위로 흩어져 있지 않습니다.
대부분은 계층적으로 연결됩니다.
예를 들어 아주 단순하게 표현하면 이런 구조를 생각할 수 있습니다.
- world
- map
- odom
- base_link
- camera_link
- lidar_frame
- imu_link
- base_link
- odom
- map
물론 실제 시스템마다 구성은 다를 수 있습니다.
하지만 중요한 점은, 프레임들이 이런 식으로 부모-자식 관계를 가지며 연결된다는 것입니다.
예를 들어 camera_link는 base_link에 붙어 있고, base_link는 odom이나 map 기준으로 움직입니다. 그러면 camera 기준 좌표를 map 기준 좌표로 바꾸고 싶을 때, camera에서 base로, base에서 odom으로, odom에서 map으로 이어지는 관계를 따라가면 됩니다.
이 구조가 좋은 이유는 명확합니다.
모든 프레임 사이 관계를 각각 일일이 직접 저장하지 않아도 됩니다.
대신 인접한 프레임 사이 변환만 정의해 두면, 시스템 전체에서 필요한 변환을 조합해 얻을 수 있습니다.
다시 말해 TF는 단순한 좌표 변환기가 아니라,
좌표계들의 관계를 체계적으로 연결한 지도에 가깝습니다.
위치뿐 아니라 회전도 함께 다뤄야 한다
프레임 변환이 헷갈리는 가장 큰 이유 중 하나는, 많은 분들이 처음에는 좌표 이동만 떠올리기 때문입니다.
예를 들어
“카메라가 로봇 몸체보다 10cm 위에 있으니 z값만 더하면 되겠네”
이렇게 생각하기 쉽습니다.
그런데 실제로는 회전이 훨씬 중요해지는 경우가 많습니다.
카메라가 정면을 보지 않고 약간 아래를 향하고 있을 수도 있고, IMU는 몸체와 미세하게 다른 방향으로 장착되어 있을 수도 있습니다. LiDAR도 설치 각도에 따라 축 방향이 달라질 수 있습니다. 이때는 원점만 옮기는 것으로는 부족하고, 축의 방향까지 함께 바꿔야 합니다.
그래서 프레임 변환은 보통 이렇게 구성됩니다.
- Translation: 원점이 얼마나 떨어져 있는가
- Rotation: 축 방향이 어떻게 회전해 있는가
이 두 가지가 모두 맞아야 비로소 올바른 좌표 변환이 됩니다.
즉, TF는 “위치를 옮긴다”는 감각보다
**“기준 자체를 바꾼다”**는 감각으로 이해하는 편이 훨씬 정확합니다.
/tf와 /tf_static은 무엇이 다를까
ROS에서 TF를 다루다 보면 아주 자주 마주치는 것이 있습니다.
바로 /tf와 /tf_static입니다.
이 둘은 이름이 비슷해서 처음에는 헷갈리기 쉽습니다.
하지만 역할은 꽤 명확하게 나뉩니다.
/tf
/tf는 시간에 따라 변하는 동적 변환을 다룹니다.
예를 들어
- 로봇이 앞으로 이동하는 경우
- 베이스가 회전하는 경우
- 움직이는 관절이 계속 자세를 바꾸는 경우
이런 정보들은 시간이 흐르면서 계속 바뀝니다.
그래서 /tf에는 보통 연속적으로 업데이트되는 변환 정보가 들어갑니다.
대표적으로 로봇의 odom -> base_link 같은 관계는 시간이 지날수록 달라집니다. 로봇이 계속 움직이기 때문입니다.
/tf_static
반면 /tf_static은 시간이 지나도 바뀌지 않는 정적 변환을 다룹니다.
예를 들어
- base_link 기준 카메라 위치
- base_link 기준 LiDAR 위치
- base_link 기준 IMU 위치
이런 관계는 센서가 물리적으로 고정되어 있다면 변하지 않습니다.
그래서 이런 정보는 한 번 정의되면 계속 같고, 굳이 자주 다시 보낼 필요도 없습니다.
이 차이를 이해하면 훨씬 정리됩니다.
- 움직이면 /tf
- 고정이면 /tf_static
아주 단순한 구분 같지만, 실제 로봇 시스템을 이해할 때는 굉장히 중요합니다.
왜냐하면 어떤 프레임이 동적으로 변하는지, 어떤 프레임이 구조적으로 고정되어 있는지를 구분할 수 있어야 전체 시스템의 동작이 머릿속에서 정리되기 때문입니다.

센서 데이터를 왜 base 기준으로 바꿔야 할까
이제 TF가 왜 실무적으로 중요한지 조금 더 직접적으로 보겠습니다.
예를 들어 LiDAR가 전방 0.3m에 장애물이 있다고 측정했다고 해보겠습니다.
겉보기에는 이 정보만으로도 충분해 보입니다.
그런데 실제로는 그렇지 않습니다.
왜냐하면 이 0.3m라는 값은 보통 LiDAR 프레임 기준이기 때문입니다.
즉, LiDAR 센서 원점에서 봤을 때 전방 0.3m에 장애물이 있다는 뜻이지, 로봇 몸체 전체 기준으로 정확히 어디에 있는지는 아직 모릅니다. 그런데 로봇이 충돌을 피하려면 중요한 것은 LiDAR 자체가 아니라 로봇 전체가 장애물과 얼마나 가까운가입니다.
여기서 TF가 필요합니다.
LiDAR가 base_link에서 얼마만큼 앞에 있고, 위에 있고, 어느 방향으로 설치되어 있는지 알면, LiDAR가 측정한 장애물 위치를 base_link 기준으로 바꿀 수 있습니다. 그러면 이제 로봇은
“센서 앞 0.3m”가 아니라
“내 몸체 기준으로 이 장애물이 실제 어디에 있다”
라고 해석할 수 있습니다.
이 차이는 굉장히 중요합니다.
센서 프레임에서만 데이터를 보면 로봇이 실제 몸체 크기를 고려한 판단을 하기가 어렵습니다.
반면 base 기준으로 변환하면, 주행 경로 계획이든 장애물 회피든 훨씬 일관된 판단이 가능해집니다.
즉, TF는 단순한 수학 도구가 아니라
센서 데이터를 로봇 행동으로 연결해주는 핵심 다리라고 볼 수 있습니다.
SLAM과 Navigation에서도 TF는 빠질 수 없다
SLAM과 Navigation을 공부하다 보면 TF가 거의 빠지지 않습니다.
이유는 간단합니다. 둘 다 결국 위치와 지도, 그리고 센서 데이터의 기준 통일을 필요로 하기 때문입니다.
예를 들어 SLAM에서는 로봇이 이동하면서 센서 관측을 지도 위에 누적해야 합니다.
이때 센서가 본 값이 어느 프레임 기준인지, 그리고 그것을 map이나 base 기준으로 어떻게 바꿀지가 명확해야 합니다.
Navigation도 마찬가지입니다.
로봇이 경로를 따라 이동하고 장애물을 피하려면, 주변 환경 정보가 로봇이 이해할 수 있는 기준으로 정리되어야 합니다. LiDAR, depth camera, IMU, wheel odometry가 제각각 자기 프레임에서 말하고 있으면 경로 계획이 안정적으로 돌아가기 어렵습니다.
결국 TF는 이런 역할을 합니다.
- 센서 데이터를 공통 기준으로 정리합니다.
- 로봇의 현재 자세와 위치를 다른 프레임과 연결합니다.
- SLAM이 만든 지도와 실제 센서 관측을 이어줍니다.
- 내비게이션이 장애물과 목표 위치를 해석할 수 있게 해줍니다.
그래서 TF가 꼬이면, 그 위에 올라가는 많은 기능들도 같이 흔들립니다.
센서가 이상한 게 아니라 프레임 정의가 잘못된 경우도 실제로 꽤 자주 발생합니다.
처음에는 센서나 알고리즘 문제처럼 보이는데, 조금 파고 들어가보면 TF 관계가 잘못되어 있는 경우가 생각보다 많습니다.
TF를 제대로 이해하면 보이는 것들
TF를 이해하고 나면 로봇 시스템을 볼 때 관점이 조금 달라집니다.
이전에는 단순히
“카메라가 영상을 준다”
“LiDAR가 스캔을 준다”
“오도메트리가 위치를 준다”
이 정도로 보였다면,
이제는
“이 데이터는 어느 프레임 기준이지?”
“이걸 base 기준으로 바꾸면 어떻게 되지?”
“센서 장착 위치가 정확히 정의되어 있나?”
같은 질문이 자연스럽게 따라오게 됩니다.
이 질문들이 바로 실제 시스템 디버깅과 연결됩니다.
- 장애물이 옆에 있는데 정면에 있는 것처럼 보일 때
- 카메라로 본 목표물 위치가 팔 동작과 안 맞을 때
- SLAM 결과가 지도를 비틀어 쌓는 것처럼 보일 때
- Navigation에서 회피가 어색할 때
이런 문제들 중 일부는 알고리즘보다 먼저 프레임 관계를 점검해봐야 합니다.
즉 TF를 이해한다는 것은 단순히 문법을 안다는 뜻이 아니라,
로봇 시스템을 좌표계 관점에서 읽을 수 있게 된다는 뜻에 가깝습니다.
정리해보면
이번 글에서는 여러 좌표계를 실제로 연결해주는 TF의 역할을 정리해봤습니다.
TF는 단순히 좌표를 옮기는 도구가 아니라,
서로 다른 프레임에서 표현된 위치와 방향을 일관된 기준으로 바꿀 수 있게 해주는 구조입니다.
그리고 이 덕분에 카메라, LiDAR, IMU, 바퀴 오도메트리처럼 서로 다른 기준에서 나오는 데이터를 하나의 로봇 시스템 안에서 함께 사용할 수 있게 됩니다.
또한 ROS에서는 시간에 따라 변하는 관계는 /tf, 고정된 관계는 /tf_static으로 나누어 관리합니다.
이 구분을 이해하면 로봇의 움직임과 센서 장착 구조를 훨씬 명확하게 볼 수 있습니다.
결국 TF의 핵심은 이것입니다.
로봇은 하나의 좌표계에서만 살지 않는다.
그래서 여러 좌표계를 연결하는 체계가 반드시 필요하다.
이 관점을 잡아두면 이후에 나오는 URDF와 Xacro도 훨씬 자연스럽게 이어집니다.
다음 글에서는 로봇의 링크와 조인트 구조를 어떻게 정의하고, 그 구조가 TF와 어떻게 연결되는지 URDF와 Xacro를 중심으로 정리해보겠습니다.
'Study Archives > Robotics' 카테고리의 다른 글
| Nav2(Path Planning) (1) | 2026.04.10 |
|---|---|
| [SLAM의 이해 ⑤] Mapping과 Localization (0) | 2026.04.10 |
| [SLAM의 이해 ④] URDF와 Xacro (0) | 2026.04.10 |
| [SLAM의 이해 ②] 좌표계와 프레임 (0) | 2026.04.10 |
| [SLAM의 이해 ①] SLAM 개요 (0) | 2026.04.10 |