점에는 좌표계뿐 아니라 시각도 붙는다
tf2는 여러 좌표계의 관계를 시간에 따라 관리하고 변환을 조회하는 라이브러리다. M02.02에서 정의한 변환을 ROS 시스템에서 필요한 시각에 찾아 쓰는 역할로 연결하면 이해하기 쉽다. 변환의 방향은 ‘카메라에서 베이스로’ 같은 말만 암기하지 말고 입력 자료의 좌표계인 source와 결과를 표현할 target을 적는다. target=base, source=camera인 조회는 camera로 표현한 점을 base로 바꾸는 데 필요한 변환을 구하는 질문이다.
그림 M05.05-1. 각 칸은 서로 다른 역할/근거다. 나란히 비교할 항목이며 위아래가 시간 순서를 뜻하지 않는다. 직접 제작한 개념도이며 본문의 조건과 함께 읽는다.
가상 센서 camera가 base에서 x방향 0.2 m 앞에 있고 축 방향은 같다고 하자. camera에서 본 점 (1,0,0) m는 base에서 (1.2,0,0) m다. base가 world에서 (2,0,0) m에 있고 방향도 같으면 world에서는 (3.2,0,0) m다. 역으로 world 점에서 camera 좌표를 구하려면 총 이동 2.2 m를 빼서 (1,0,0) m로 돌아온다. 회전이 있으면 이동을 무조건 더하는 계산을 사용할 수 없으며 행렬의 합성·역변환 순서를 따라야 한다.
동적 변환은 시각에 따라 달라진다. 위 수치가 관측 시각 t=1.0 s의 관계인데, 현재 t=1.2 s의 base 위치가 x=2.1 m라고 하자. 과거 센서 관측을 현재 변환으로 옮기면 world의 x는 3.3 m가 되어 같은 시각의 계산보다 0.1 m 다르다. 물체가 그만큼 움직였다고 바로 결론 내릴 수 없다. 서로 다른 시각의 프레임을 섞은 것이다. tf2의 버퍼에 필요한 시각의 연결 정보가 없으면 조회가 실패할 수 있고, 요청 시각이 보관 범위 밖이면 시간 외삽 문제가 생길 수 있다. ‘최신 변환을 쓰면 해결’은 의미를 바꾸므로 정확한 해결책이 아닐 수 있다.
물리적으로 고정된 장착 관계는 정적 변환으로, 움직이는 관절이나 베이스 관계는 동적 변환으로 표현한다. 하지만 데이터가 정적 채널로 왔다는 사실이 실제 장착의 정확성을 보증하지는 않는다. 오프셋·축 방향·단위·프레임 이름을 검증해야 한다. 기존 2.2 변환 설명과 4.2 센서 프레임은 이 기하와 실제 파이프라인을 잇는 자료다.
화면이 보여 주는 것은 어떤 증거인가
RViz는 ROS 자료를 3차원으로 시각화하는 도구이며 물리 시뮬레이터가 아니다. Fixed Frame은 자료를 모아 표현하는 기준 좌표계다. 선택한 표시 항목이 센서 프레임의 자료를 Fixed Frame으로 바꾸려면 해당 시각의 변환 연결이 필요하다. 점군 메시지가 도착해도 변환이 없으면 기대 위치에 표시되지 않을 수 있다. 표시 항목의 상태·Topic·타입·QoS·frame_id·stamp와 Fixed Frame을 함께 확인한다. 화면에 로봇이 예쁘게 보인다는 사실만으로 질량·충돌·구동·센서 보정이 검증된 것도 아니다.
rqt는 여러 ROS 관측·조작 도구를 플러그인으로 제공하는 GUI 틀이다. 그래프를 보는 플러그인과 값을 그리는 도구는 관찰 대상이 다르다. 연결 그림에 선이 있다고 매 표본이 제시간에 처리되거나 단위가 맞는다는 뜻은 아니다. 원시 메시지의 필드와 타임스탬프, Endpoint 정보, 표시 도구의 상태를 나누어 읽어야 한다. 이 단위에서는 도구 화면을 실제로 열지 않고 ‘이 관찰로 무엇을 알 수 있는가’를 판단한다. GUI에는 명령을 보내는 기능도 있으므로 시각화와 제어 동작을 같은 것으로 취급하지 않는다.
가상 장애에서 노드/Topic의 연결은 보이고 점군의 수신 개수도 늘지만, RViz 상태에 필요한 프레임 연결이 없다고 나온다면 먼저 tf 연결과 요청 시각을 조사한다. 생산자가 아무 자료도 보내지 않는다는 결론은 기존 증거와 맞지 않는다. 반대로 원시 수신조차 확인되지 않았다면 표시 설정만 바꾸기 전에 이름·타입·QoS·발견 단계부터 점검한다. 원인 후보를 증거 순서로 좁히는 것이 도구를 많이 켜는 것보다 중요하다.
기록은 세계 전체의 복사본이 아니다
rosbag2는 ROS 통신 자료를 기록하고 재생하는 도구다. MCAP은 사용할 수 있는 저장 형식이고 rosbag2_storage_mcap은 그 형식을 지원하는 플러그인이다. 파일 확장자가 .mcap이라고 실제 환경 전체가 기록된 것은 아니다. 어떤 Topic과 타입, 어느 시간 범위, 어떤 QoS와 시계 및 설정으로 기록했는지를 함께 남긴다. 기록기가 자료를 받지 못했거나 디스크 처리가 따라가지 못한 상황은 저장 형식만으로 없어지지 않는다.
가상 bag에 /camera/points와 /joint_states만 있고 /tf와 /tf_static 및 외부 보정 파일이 없다면, 나중에 점군을 world로 옮길 근거가 충분하지 않을 수 있다. 정적 보정을 별도 문서로 보존했다면 일부를 보완할 수 있지만 무엇을 복구했는지 명시해야 한다. 파일의 메시지 개수는 저장된 개수이지 센서가 원래 생성한 전체 개수와 자동으로 같지 않다. 원본 생성 카운터나 누락 기록이 있어야 손실을 판정할 수 있다.
재생 배속 2는 기록의 시간 간격을 두 배 빠르게 진행하려는 설정이다. 기록상 0.0, 0.1, 0.2 s의 세 사건은 이상적인 일정 배속에서 시작 대비 0, 0.05, 0.10 s의 벽시계 간격에 대응한다. 실제 스케줄과 소비자의 처리 속도 때문에 정확한 전달 시각이 보장되는 것은 아니다. 메시지 내부의 획득 stamp가 자동으로 현재 벽시계로 바뀐다고도 가정하지 않는다. 소비자의 use_sim_time과 재생 /clock을 포함한 시계 정합은 M05.06에서 다룬다.
재생은 저장된 자료를 다시 발행할 수 있어 외부 실행기가 연결된 환경에서는 단순한 동영상 감상과 다르다. 이 단위의 기본 활동은 표를 읽는 것이며 실제 재생 명령을 실행하지 않는다. 입력을 다시 넣어 같은 분석을 비교하는 것과 새로운 물리 환경에서 성능이 검증된 것은 구분한다. 모델·설정·버전·시계·누락 범위를 남겨야 어떤 결과를 재현했다고 주장하는지 명확해진다.