Part 1. 객관식 (1~10)
문제 1. 서로 다른 센서의 독립 좌표계를 하나의 3D 공간에 왜곡 없이 모으는 "전역 기준점"은?
RViz로 로봇 상태·주변 환경을 시각화할 때, 서로 다른 센서 노드가 발행하는 독립적인 좌표계 데이터들을 하나의 3D 공간에 왜곡 없이 표현하기 위해 전역적인 공간 기준점 역할을 하는 설정 항목은?
- A)
frame_id— 개별 메시지가 "나는 이 좌표계 기준"이라고 적어두는 헤더 필드일 뿐, 전역 기준점 설정이 아님. - B)
child_frame_id— TF에서 자식 좌표계 이름을 가리키는 필드. 전역 기준과 무관. - C) Fixed Frame — RViz가 모든 데이터를 변환해 모으는 단 하나의 기준 좌표계. 정답.
- D) Topic Namespace — 토픽 이름 충돌을 막는 이름 공간일 뿐, 좌표 기준과 무관.
✅ 정답: C
💡 RViz의 모든 Display는 자기 데이터를
frame_id기준으로 들고 오지만, 화면에 그릴 때는 Fixed Frame 하나로 전부 TF 변환해서 모읍니다. Fixed Frame이 존재하지 않는 좌표계면 "Frame [xxx] does not exist" 에러가 나고 아무것도 안 보입니다.
문제 2. /scan은 발행되는데 "No transform from [laser] to [odom]" 오류 — 가장 적절한 조치는?
2D LiDAR가
/scan을 정상 발행함에도 LaserScan Display에 데이터가 안 뜨고 "No transform from [laser] to [odom]" 오류가 보인다. 진단·해결로 가장 적절한 것은?
- A) 전원·물리 포트 재점검 — 토픽이 이미 정상 발행 중이므로 하드웨어 문제가 아님. 헛다리.
- B)
ranges배열의 0·∞ 값 확인 — 값 품질 문제는 점이 일부 튀는 수준이지, "No transform"(좌표 변환 없음) 오류의 원인이 아님. - C) Fixed Frame 확인 +
odom→laserTF 트리 연결 점검 — 오류 메시지 그대로 TF 경로가 끊긴 것이 원인. 정답. - D) Style을 Points→Flat Squares로 변경 — 렌더링 모양 설정일 뿐, 변환 문제와 무관.
✅ 정답: C
💡 "No transform from A to B"는 A와 B를 잇는 TF가 없다는 뜻입니다.
ros2 run tf2_tools view_frames로 트리를 그려보고,ros2 run tf2_ros tf2_echo odom laser로 경로가 이어지는지 확인하세요. 보통 중간base_link연결이나 static TF 발행이 빠진 경우입니다.
문제 3. "센서 장착 위치(불변)"와 "주행 기준↔본체 관계(가변)"를 처리하는 형식 순서는?
시간이 지나도 변하지 않는 '본체↔탑재 센서 장착 위치 관계'와, 바퀴 회전·오차 누적으로 계속 변하는 '주행 기준 좌표계↔본체 관계'를 처리하는 형식을 순서대로 짝지으면?
- A) Dynamic TF — Static TF — 순서가 뒤바뀜. 장착 위치가 Static인데 Dynamic이라 했으니 오답.
- B) Static TF — Dynamic TF — 장착 위치=Static(불변), 주행 기준↔본체=Dynamic(계속 변함). 정답.
- C) Fixed TF — Global TF — ROS에 없는 명칭.
- D) Joint TF — Link TF — 그런 분류는 없음.
✅ 정답: B
💡 변하지 않으면 Static TF(예:
base_link → laser, 한 번 발행하고 latched), 계속 변하면 Dynamic TF(예:odom → base_link, 매 주기 발행). "장착 위치는 고정 / 로봇 이동은 변동"으로 외우세요.
문제 4. 로봇 구조를 XML로 정의하는 포맷 + 그 모델을 3D로 렌더하는 Display는?
로봇의 물리 구조·링크/조인트 연결성·외형을 XML로 정의하는 파일 포맷과, 그 정보로 RViz 3D View에 로봇 하드웨어 형태를 렌더하는 전용 Display의 명칭이 올바르게 연결된 것은?
- A) SDF — Odometry — SDF는 주로 Gazebo용 포맷, Odometry는 위치 추정 Display(로봇 외형 렌더 아님).
- B) URDF — RobotModel — URDF(Unified Robot Description Format) + RobotModel Display. 정답.
- C) YAML — Path — YAML은 설정 포맷, Path는 경로 Display.
- D) XML — TF — XML은 일반 형식 명칭일 뿐(URDF가 XML 기반이긴 함), TF는 좌표계 Display.
✅ 정답: B
💡 URDF는
<link>·<joint>로 로봇을 기술하고, RobotModel Display가 이를 읽어 메시(형상)를 그립니다. 각 링크가 공간 어디에 놓일지는 TF가 결정 — URDF(형상) + TF(자세)가 함께 있어야 로봇이 제대로 보입니다(20번 참고).
문제 5. 시각화가 정상 작동하기 위한 필수 조건과 가장 거리가 먼 것은? ⚠️
Display를 연결했는데 화면에 아무것도 안 나온다. 정상 작동을 위한 필수 조건과 가장 거리가 먼 것은?
- A) 해당 토픽이 활성화되어 메시지가 지속 발행되어야 한다 — 맞는 조건(O). 데이터가 없으면 그릴 게 없음.
- B) 메시지 헤더의
frame_id가 유효해야 한다 — 맞는 조건(O). frame_id가 있어야 TF로 위치를 잡음. - C) Display가 요구하는 메시지 타입과 실제 토픽 타입이 일치해야 한다 — 맞는 조건(O). 타입이 다르면 구독 불가.
- D) frame_id와 TF 이름의 대소문자가 달라도 시스템이 자동 유추해 연결하므로 일치할 필요 없다 — 틀림(✗). 정답.
✅ 정답: D (필수 조건과 가장 거리가 먼 = 틀린 설명)
💡 좌표계 이름은 대소문자까지 정확히 일치해야 합니다.
Laser와laser는 다른 프레임으로 취급되어 TF 연결이 끊깁니다. 자동 유추는 없습니다 — 오타·대소문자가 "데이터 안 보임"의 단골 원인.
문제 6. Odometry로 위치·방향을 가장 직관적으로 보는 Shape 두 가지는?
nav_msgs/msg/Odometry를 구독해 로봇의 방향성(Orientation)과 위치를 기하학적 축·포인터로 가장 직관적으로 확인할 Shape 속성 두 가지는?
- A) Line, Point — 위치는 알아도 방향(자세) 표현에 약함.
- B) Cube, Cylinder — 단순 도형, 바라보는 방향을 나타내지 못함.
- C) Arrow, Axes — 화살표(위치+바라보는 방향)와 좌표축(x/y/z 자세)으로 방향성을 직관 표현. 정답.
- D) Billboard, Flat Square — 점군/평면 렌더 스타일, 방향 표현 아님.
✅ 정답: C
💡 Arrow는 "어디에서 어디를 향하는지"를 한눈에, Axes는 세 축으로 자세(roll/pitch/yaw)를 보여줍니다. 방향이 중요한 Odometry·Pose 계열의 기본 선택.
문제 7. Gazebo와 RViz의 차이·협업에 대한 설명으로 가장 올바르지 않은 것은? ⚠️
물리 시뮬레이터 Gazebo와 시각화 도구 RViz의 차이·데이터 흐름 설명 중 가장 올바르지 않은 것은?
- A) Gazebo는 중력·마찰·충돌 등 물리 연산으로 가상 동작·센서 원시 데이터를 생성한다 — 맞음(O).
- B) RViz는 물리 엔진이 없고, 실제 로봇이나 Gazebo가 발행한 토픽을 구독해 3D 렌더만 한다 — 맞음(O).
- C) Gazebo 물리 좌표계와 ROS 2 TF 트리가 일치하지 않아도, RViz는 독립 레이어라 항상 실세계 기준으로 정확히 표시한다 — 틀림(✗). 정답.
- D) Gazebo의 가상 센서 데이터가 RViz에 뜨려면 ROS 2 Bridge/플러그인으로 표준 메시지로 발행돼야 한다 — 맞음(O).
✅ 정답: C (가장 올바르지 않은 설명)
💡 RViz는 TF에 전적으로 의존합니다. 좌표계 정의가 어긋나면 RViz도 어긋난 위치로 그립니다 — "독립 레이어라 항상 정확"은 명백히 틀린 말. RViz는 진실을 만들어내지 않고, 주어진 좌표계대로 충실히 그릴 뿐입니다.
문제 8. nav_msgs/msg/Path를 구성하는 개별 요소의 메시지 타입은?
nav_msgs/msg/Path로 주행 궤적을 선으로 그릴 때, 타임스탬프와 함께 연속 위치·방향 배열을 구성하는 개별 요소의 실제 메시지 타입은?
- A)
sensor_msgs/msg/PointCloud2— 3D 점군 타입, 경로 요소가 아님. - B)
geometry_msgs/msg/PoseStamped— Path는poses[]가 PoseStamped 배열. 정답. - C)
visualization_msgs/msg/Marker— 자유 도형 마커, Path 내부 요소 아님. - D)
sensor_msgs/msg/Imu— 관성 센서 데이터, 무관.
✅ 정답: B
💡
Path.poses는PoseStamped의 배열입니다(각 요소 = header + pose(위치+자세)). 그래서 경로의 각 점이 "언제, 어디서, 어느 방향"을 모두 담습니다. (Odometry의 자세 표현, 4편의 좌표 개념과 연결됩니다.)
문제 9. 목표점·장애물·위험구역을 도형·텍스트로 자유 배치하는 메시지·Display는?
개발자가 목표 지점·장애물 후보·위험 구역 등을 사각형·구·텍스트로 3D 공간에 자유롭게 배치해 디버깅할 때 쓰는 메시지 타입과 Display는?
- A)
sensor_msgs/msg/Image— Image — 카메라 영상 표시용(2D), 자유 도형 배치 아님. - B)
nav_msgs/msg/Odometry— Odometry — 위치 추정 표시용. - C)
visualization_msgs/msg/Marker— Marker — 큐브·구·텍스트·화살표 등 사용자 정의 도형을 자유 배치. 정답. - D)
sensor_msgs/msg/LaserScan— LaserScan — LiDAR 거리 데이터 전용. - ✅ 정답: C*
💡 정형 센서 데이터로는 표현 못 하는 "내가 찍고 싶은 것"(목표점·박스·라벨)을 그릴 때 Marker(여러 개면
MarkerArray). type으로 CUBE/SPHERE/TEXT_VIEW_FACING 등을 고릅니다. (W2D1 3편·W2D2 실습에서 MarkerArray로 로봇 팔을 그렸죠.)
문제 10. Fixed Frame·토픽 매핑·색·카메라 시점을 저장해 화면을 복원하는 설정 파일 확장자는?
Display 구성, Fixed Frame, 토픽 매핑, 선 두께·색, 3D View 카메라 시점을 저장해 다음 실행 시 동일 화면을 복원하는 설정 파일의 확장자는?
- A)
.urdf— 로봇 구조 정의 파일(4번). - B)
.yaml— 일반 설정/파라미터 포맷. - C)
.rviz— RViz 화면 구성 전체를 담는 설정 파일. 정답. - D)
.xml— 일반 형식 명칭.
✅ 정답: C
💡
rviz2 -d demo.rviz로 한 번에 같은 화면을 복원합니다. 요약본을 손으로 옮기면 일부만 읽혀 기본값(Fixed Frame=map)으로 떨어지는 함정이 있으니, 설정은 RViz에서 Save Config로 통째 저장하세요(W2D1 3편의 그 함정!).
Part 2. 서술형 (11~20)
문제 11. ros2 topic echo 같은 텍스트 확인 대비, RViz(3D 시각화)가 디버깅에 필수인 이유는?
✅ 모범답안
ros2 topic echo /scan은 숫자 나열만 보여줍니다 — 거리 배열·좌표값으로는 로봇이 어느 방향을 보는지, 센서 점이 주변에 어떻게 분포하는지, 좌표계가 맞게 연결됐는지, 경로가 정상인지 직관적으로 판단하기 어렵습니다.- RViz는 여러 데이터(TF·RobotModel·LaserScan·Odometry·Path)를 하나의 3D 공간에 좌표계 기준으로 동시에 렌더합니다. → 위치·방향·센서 커버리지·좌표계 정합성·충돌 여부를 눈으로 즉시 확인.
- 결과적으로 오류의 위치를 공간적으로 짚어 디버깅 속도가 크게 빨라집니다(예: 점들이 로봇 뒤에 찍히면 센서 장착 TF가 틀린 것).
💡 한 줄: "숫자는 검증, 그림은 직관" — 텍스트로는 값의 정확성, RViz로는 공간적 맥락을 본다.
문제 12. map / odom / base_link 3대 표준 좌표계의 의미 비교
✅ 모범답안
- map — 전역 고정 월드 좌표계. 누적 오차가 없는 절대 기준(위치추정·SLAM이 보정). 단, 보정되는 순간 위치가 불연속적으로 점프할 수 있음. 장기 절대 위치의 기준.
- odom — 휠 엔코더·IMU를 적분해 만든 연속·매끄러운 국소 좌표계. 단기적으로 정확하고 점프가 없지만, 시간이 지나며 드리프트(누적 오차) 가 쌓임.
- base_link — 로봇 본체 중심에 고정된 좌표계. 모든 센서·링크 좌표계의 기준(부모)이 됨.
- 관계(트리):
map → odom → base_link— 위로 갈수록 전역·절대, 아래로 갈수록 본체 기준.💡 "정확하지만 가끔 점프하는 map" vs "매끄럽지만 서서히 밀리는 odom" — 둘을 함께 써서 장점을 합칩니다.
문제 13. Display에 경고/오류가 뜨고 데이터가 안 보일 때, 데이터·통신 관점의 디버깅 3단계
✅ 모범답안 (순서대로)
- ① 토픽 발행 확인 —
ros2 topic list로 토픽이 있는지,ros2 topic echo/ros2 topic hz로 실제 메시지가 흐르는지(노드가 살아 있고 발행 중인지) 확인. - ② 메시지 타입·
frame_id확인 — Display가 요구하는 메시지 타입과 실제 토픽 타입이 일치하는지, 헤더의frame_id가 유효한지 확인. - ③ TF 연결 확인 — Fixed Frame ↔ 데이터의
frame_id사이 TF 경로가 이어지는지 점검(ros2 run tf2_tools view_frames,tf2_echo). 끊겨 있으면 "No transform" 오류.💡 "데이터가 오나(토픽) → 형식이 맞나(타입·frame_id) → 위치를 잡을 수 있나(TF)" 순서로 좁혀 갑니다(2번·5번 문항이 각각 ③·②에 해당).
문제 14. LaserScan이 2D 점들로 변환되는 원리(어떤 필드를 결합하나)
✅ 모범답안
- LaserScan 메시지의 핵심 필드:
angle_min,angle_increment,ranges[](그리고range_min/range_max로 유효 범위 필터). - i번째 점의 각도:
angle = angle_min + i × angle_increment, 거리:r = ranges[i]. - 이를 평면 좌표로:
x = r·cos(angle),y = r·sin(angle)(laser 좌표계 기준). - RViz는 이 점들을 laser 프레임에서 Fixed Frame으로 TF 변환해 3D 공간에 찍습니다.
💡 즉 "각도(인덱스로 계산) + 거리(ranges)"를 극좌표→직교좌표로 바꾼 뒤 TF로 옮기는 것.
range_min/max밖이나inf는 버려집니다.
문제 15. 토픽·TF가 다 맞는데 Marker가 안 보일 때, 0으로 채워졌을 가능성 높은 필드 2개
✅ 모범답안
scale.x/y/z(크기) — 0이면 크기가 0이라 화면에 점도 안 찍힘. (단, LINE/POINTS 류는 일부 축만 쓰므로 해당 축이 0이어도 문제.)color.a(알파, 불투명도) — 0이면 완전 투명이라 그려져도 보이지 않음.
- 이유: 토픽 이름·메시지 타입·
frame_id·TF가 모두 맞아도, 크기 0 또는 알파 0이면 렌더 결과가 보이지 않습니다 — Marker "안 보임"의 1순위 원인.💡 새 Marker를 만들 때
scale과color.a를 깜빡하고 0으로 두는 실수가 흔합니다. 최소scale=0.1,color.a=1.0부터.
문제 16. "현재 순간 위치·방향" + "누적 주행 경로"를 한 화면에 — 두 Display와 목적
✅ 모범답안
- Odometry Display —
nav_msgs/msg/Odometry를 구독해 로봇의 현재 실시간 순간 위치와 바라보는 방향을 화살표(Arrow)로 표시. 목적: "지금 어디서 어디를 보는가". - Path Display —
nav_msgs/msg/Path를 구독해 시동 이후 누적된 전체 주행 궤적을 선으로 표시. 목적: "여태 어떻게 움직여 왔는가". - 두 Display를 동시에 켜면 현재 상태(점)와 이력(선)을 한 화면에서 비교 모니터링할 수 있습니다.
💡 Odometry=순간(현재), Path=누적(이력). 같은 Fixed Frame(
odom) 위에서 겹쳐 봅니다.
문제 17. PointCloud2의 높낮이·깊이감을 살리는 주요 옵션과 역할
✅ 모범답안
- 옵션 명칭: Color Transformer 를
AxisColor(축 기준 색상, 보통 Z축=높이)로 설정. - 역할: 각 점의 좌표값(높이/깊이)을 색으로 매핑해, 수많은 점의 공간적 높낮이를 색 그라데이션으로 한눈에 구분 → 입체감·가시성 향상.
- (보조)
Intensity모드는 반사 강도,FlatColor는 단색 — 높낮이 분석엔 AxisColor가 핵심.💡 "높이를 색으로" — 바닥은 파랑, 위로 갈수록 빨강 식으로 깊이를 직관화합니다. Size(점 크기)도 가시성 보조 옵션.
문제 18. 빈 화면에서 Display를 쌓을 때 권장 1~3단계 빌드 순서와 이유
✅ 모범답안 (순서대로)
- 1단계 — Fixed Frame 설정 — 모든 데이터를 모을 기준 좌표계를 먼저 확정. 기준이 없으면 어떤 Display도 그릴 위치를 정하지 못함.
- 2단계 — TF Display 추가 — 좌표계 트리가 올바르게 연결됐는지 먼저 검증. 센서 데이터가 올라타는 토대이기 때문.
- 3단계 — RobotModel·센서 Display 추가 — 좌표계가 검증된 위에 로봇 모델·센서 데이터를 얹음.
- 이유: 기준 → 좌표계 → 데이터 순으로 쌓아야, 문제가 생겨도 "어느 단계에서 깨졌는지" 원인을 단계별로 분리할 수 있음(처음부터 다 켜면 원인 추적이 어려움).
💡 한꺼번에 다 켜고 "왜 안 보이지?" 하기보다, 한 겹씩 올리며 확인하는 습관이 디버깅을 빠르게 합니다.
문제 19. 카메라 image_raw를 보는 전용 Display와, 정상 출력 위해 추가 검증할 속성
✅ 모범답안
- 전용 Display: Image Display — 3D View에 점·선으로 융합하지 않고, 별도 2D 패널에 영상을 그대로 표시.
- 추가 검증 속성:
- Image Topic(토픽 매핑) — 올바른 영상 토픽(
/camera/image_raw등)을 정확히 지정했는지. - Transport Hint(전송 방식) —
raw/compressed등 발행 방식과 일치하는지(compressed로 발행되는데 raw로 구독하면 안 나옴).
- Image Topic(토픽 매핑) — 올바른 영상 토픽(
- 참고: Image는 2D 영상이라 Fixed Frame/TF에 의존하지 않습니다(좌표 변환 대상이 아님).
💡 LiDAR·Odometry는 3D View에, 이미지는 Image 패널에. "안 나오면 토픽 이름·transport부터" 확인.
문제 20. RobotModel Display가 robot_state_publisher·파라미터 서버와 연동되는 원리
✅ 모범답안
robot_state_publisher는 두 가지를 공유합니다: ①robot_description파라미터(URDF 전체), ② 관절 상태로부터 계산한 각 링크의 TF(/tf, 고정 관계는/tf_static).- RobotModel Display는
robot_description파라미터에서 URDF를 읽어 각 링크의 메시(형상) 를 가져오고, TF로 각 링크 좌표계의 위치·자세를 받아 3D 공간에 배치·렌더합니다. - 즉 연동 인터페이스 =
robot_description파라미터(형상) + TF(자세). 둘 중 하나라도 없으면 모델이 안 보이거나 자세가 틀어집니다.💡 URDF = "어떻게 생겼나", TF = "지금 어떤 자세인가". RobotModel은 이 둘을 합쳐 살아 있는 로봇 모델을 그립니다(4번 문항과 직접 연결).
한 장 정리 — 헷갈리면 이것만
| 구분 | 핵심 |
|---|---|
| Fixed Frame | 모든 데이터를 모으는 단 하나의 기준 좌표계(없으면 아무것도 안 보임) |
| frame_id | 개별 메시지가 "나는 이 좌표계 기준"이라 적는 헤더 필드 |
| Static TF | 변하지 않는 관계(센서 장착: base_link→laser) |
| Dynamic TF | 계속 변하는 관계(로봇 이동: odom→base_link) |
| URDF + RobotModel | 로봇 형상 정의(XML) + 그 형상을 그리는 Display |
| map / odom / base_link | 전역 절대(점프 가능) / 매끄러움(드리프트) / 본체 중심 |
| LaserScan→점 | angle_min + i·angle_increment, ranges[i] → (r·cosθ, r·sinθ) |
| Marker 안 보임 | scale=0 또는 color.a=0 의심 |
| Odometry / Path | 현재 순간(Arrow) / 누적 궤적(선) |
| .rviz | 화면 구성·Fixed Frame·시점을 통째 저장 |
단골 함정 3개: ① 좌표계 이름은 대소문자까지 일치(자동 유추 없음, 5번) ② RViz는 TF에 의존 — 좌표계 틀리면 RViz도 틀리게 그림(7번) ③ Fixed Frame이 존재하는 좌표계여야 함(없으면 "does not exist", 1·10번).
📚 함께 보기 — Week2 Day1 본편
- 1/6 RViz로 로봇을 눈으로 보다 — 시각화 흐름·Fixed Frame·Display
- 2/6 TF·URDF·센서 Display·디버깅
- 3/6 RViz2 GCP VM 헤드리스 실습
- 4·5/6 좌표계·동차변환행렬(2D / 3D·TF·Quaternion)
- 6/6 좌표변환 실습(Python·TF Publisher)