제11부 도구·관측성

11.5 rqt·PlotJuggler·시각 분석

11.5.1 이 장에서 배우는 것 / 선수 지식

RViz2가 3D 공간을 보여준다면, 이 장의 도구들은 시간·구조·텍스트를 보여준다. 제어 게인이 진동하는지, 노드가 어떻게 연결됐는지, 어떤 로그가 언제 나왔는지 — RViz2로는 답할 수 없는 질문들이다.

이 장의 실용적 목표는 "이 질문에는 이 도구" 를 정하는 것이다. 도구가 많은데 각각의 강점이 다르고, 잘못 고르면 시간을 버린다.

배우는 것:

• rqt 프레임워크 — 구조와 주요 플러그인.
• rqt_graph — 연결 확인과 그 한계.
• rqt_console·rqt_reconfigure — 로그와 파라미터.
• rqt_plot과 PlotJuggler — 시계열, 그리고 왜 후자인가.
• PlotJuggler 심층 — 변환·수식·bag 분석.
• 도구 선택 — 질문에서 도구로.
• CLI와의 조합 — GUI가 답이 아닐 때.
• 원격에서 보는 법 — 그래프를 늘릴 것인가, 브리지를 둘 것인가(11.5.12).

선수 지식: 1.11(로깅), 1.9(파라미터), 11.2·11.3(bag), 3.3(디스커버리·연결).

정직: rqt 플러그인의 패키지명·설치 여부는 배포판·설치 방식에 따라 다르다(확인 필요). PlotJuggler는 ROS 외부 프로젝트이며 기능·ROS 2 연동은 버전 의존이다(확인 필요). Foxglove 등 상용·외부 도구는 존재를 언급하되 평가하지 않는다. 이 환경에서 실행 검증하지 않았다(목차 3).

검증 상태(추가): 이 장의 서술 가운데 1곳은 이후 회차에서 Jazzy 실물과 대조해 확인했다 — 본문의 (실행 확인) 표기가 그것이다. 표기가 없는 서술은 위 고지가 그대로 적용된다(목차 3의 검증 범위 표).

11.5.2 rqt 프레임워크

Qt 기반 플러그인 컨테이너다. 여러 플러그인을 한 창에 배치할 수 있다.

rqt                                    # 빈 창 — Plugins 메뉴에서 추가
rqt --standalone rqt_graph             # 단일 플러그인
ros2 run rqt_graph rqt_graph           # 직접 실행

정직: 일부 플러그인은 ROS 2에서 미지원이거나 기능이 축소됐을 수 있다(확인 필요). ROS 1 시절 자료를 보고 찾다가 없는 경우가 있다.

견해: rqt의 가치는 "여러 도구를 한 화면에 배치"에 있다. 로그·그래프·진단을 나란히 놓고 보면 상관관계가 눈에 들어온다. 배치를 저장(Perspective)해 두면 매번 구성하지 않아도 된다.

11.5.3 rqt_graph — 연결 확인

"노드가 서로 연결됐는가"를 그림으로 본다.

ros2 run rqt_graph rqt_graph

무엇을 알 수 있나:

함정: rqt_graph는 QoS 불일치를 보여주지 않는다. 이름이 같으면 선이 그어지지만, QoS가 안 맞으면 데이터는 안 흐른다(1.5.4). 선이 있는데 데이터가 없으면 ros2 topic info -v로 QoS를 확인해야 한다.

함정: rqt_graph는 실제 데이터 흐름이 아니라 선언된 연결을 보여준다. 발행자가 있어도 발행을 안 하면 선은 그어진다. ros2 topic hz로 실제 흐름을 확인한다.

견해: rqt_graph는 "구조 파악"에 강하고 "동작 확인"에는 약하다. 처음 보는 시스템의 구성을 이해하거나 리매핑 실수를 찾는 데 좋고, "왜 데이터가 안 오나"에는 CLI가 낫다(11.5.8).

11.5.4 rqt_console — 로그

ros2 run rqt_console rqt_console

견해: 로그가 폭주할 때 필터가 가치를 발휘한다. ros2 topic echo /rosout은 흐름이 빠르면 못 읽지만, rqt_console은 멈추고 필터링해 볼 수 있다.

CLI 대안:

# 파일로 기록된 로그를 검색 (1.11.3)
grep -r "ERROR" ~/.ros/log/latest/

# 실시간
ros2 topic echo /rosout | grep -i error

견해: 로그 분석에서 궁극적으로 강력한 것은 grep이다. GUI는 실시간 관찰에, grep은 사후 분석에 낫다. 로그를 구조화해 두면(1.11.6) grep이 훨씬 유용해진다.

11.5.5 rqt_reconfigure — 파라미터

ros2 run rqt_reconfigure rqt_reconfigure

견해: 튜닝에서 이 도구가 시간을 크게 아낀다. 게인·임계값을 바꿔 가며 즉시 효과를 보는 작업(6.5.5의 제어 튜닝·8.5의 컨트롤러 튜닝)에서, 재시작 없이 조정할 수 있다.

함정: 동적으로 반영되는 파라미터인지 확인하라. 노드가 파라미터 콜백을 구현하지 않았으면(1.9.6) 값은 바뀌지만 동작은 안 바뀐다. 1.9.5·1.9.6에서 "읽기 전용으로 선언하거나 콜백을 구현하라"고 한 이유가 이것이다.

함정: 여기서 바꾼 값은 저장되지 않는다. 재시작하면 YAML 값으로 돌아간다. 좋은 값을 찾았으면 YAML에 반영해야 한다(1.9.7). ros2 param dump로 현재 값을 저장할 수 있다.

ros2 param dump /controller_server > tuned.yaml

11.5.6 시계열 — rqt_plot과 PlotJuggler

시계열 분석은 제어·성능 진단의 핵심 도구다.

ros2 run rqt_plot rqt_plot /odom/twist/twist/linear/x

견해: 시계열 분석이 필요하면 PlotJuggler를 쓰라. rqt_plot은 값 하나를 잠깐 보는 데는 충분하지만, 실제 진단은 여러 신호를 겹쳐 보고 파생값을 계산하는 작업이라 곧 한계에 닿는다.

11.5.7 PlotJuggler 심층

bag 분석의 주력 도구다.

전형적 분석:

수식 활용 예:

견해: "명령과 실제를 같은 플롯에 겹치는 것"이 제어 진단의 기본 동작이다. 이것만으로 게인이 낮은지(느린 추종)·높은지(진동)·지연이 있는지(위상 차)가 대개 보인다.

견해: 주기 지터를 시계열로 보는 것이 통계보다 정보가 많다(2.5.6). 평균과 최댓값은 "가끔 급증하는지 주기적으로 급증하는지"를 구분 못 하지만, 시계열은 패턴을 보여준다 — 그것이 원인을 가리킨다(주기적이면 다른 주기 작업, 산발적이면 GC·페이지 폴트).

정직: PlotJuggler의 ROS 2 지원·설치 방법·기능 범위는 버전 의존이며 별도 설치가 필요할 수 있다(확인 필요).

기타 도구:

견해: 정형화된 반복 분석은 스크립트로 만들라. GUI로 매번 클릭하는 것보다, bag을 입력받아 지표와 그림을 생성하는 스크립트가 재현 가능하고 CI에도 넣을 수 있다(11.3.8). 탐색은 GUI, 반복은 스크립트가 좋은 분업이다.

11.5.8 도구 선택

견해: CLI를 먼저 쓰라. ros2 topic hz·ros2 topic info -v·ros2 node info는 GUI를 실행하는 시간보다 빠르고, 원격·헤드리스에서도 되며, 스크립트로 자동화된다. GUI는 CLI로 답이 안 나올 때 쓴다.

견해: GUI 도구는 원격·현장에서 제약이 크다(11.4.6). SSH만 되는 상황에서는 CLI가 유일한 수단이므로, CLI 숙련이 실무 능력을 좌우한다. 11.1에서 이 관점을 정리한다.

11.5.9 진단 도구 조합

실제 진단은 도구 하나로 끝나지 않는다.

예: "로봇이 목표에 못 간다"(8.8.8의 확장)

견해: "위에서 아래로" 순서가 효율적이다 — 인식(RViz2) → 판단(로그) → 명령(CLI) → 실행(PlotJuggler) → 설정. 이것이 2.1.8에서 세운 계층 식별의 실무 적용이다.

예: "제어가 진동한다"

견해: "조정 → 즉시 확인" 루프를 짧게 만드는 것이 튜닝의 핵심이다. rqt_reconfigure + PlotJuggler 조합이 그 루프를 초 단위로 줄인다. 재시작이 필요한 구조라면 튜닝이 몇 배 느려지므로, 파라미터 콜백을 구현해 두는 것(1.9.6)이 여기서 값을 한다.

11.5.12 원격에서 본다 — 브리지 계층

번호에 대하여: 이 절은 나중에 추가되었다. 규약(CLD-03)에 따라 번호는 끝에 붙이고 읽는 흐름을 위해 함정 카탈로그 앞에 놓았다.

지금까지의 도구는 전부 ROS 그래프 안에 들어가서 본다. rqt도 RViz2도 노드이며, 자신이 구독해서 그린다. 로봇과 같은 LAN에 노트북을 물리면 그것으로 충분하다.

현장에서는 대개 그렇지 않다. 로봇은 무선 뒤에, NAT 뒤에, 혹은 다른 지역에 있다. 여기서 두 가지 길이 갈린다.

7.8.6이 "원격 운영자에게 필요한 것은 원본 센서 데이터가 아니라 상태 요약과 필요 시의 저품질 영상"이라고 결론지었다. ②는 그 결론을 실행에 옮기는 계층이다.

11.5.12.1 브리지 후보

실행 확인(2026-08-16): Jazzy apt 인덱스에 ros-jazzy-rosbridge-suite(2.7.0)와 ros-jazzy-foxglove-bridge(3.4.1)가 실재한다. 확인한 것은 패키지의 존재와 버전까지이며, 기능·성능·프로토콜 세부는 실행해 보지 않았다(확인 필요). 도구 평가는 이 책의 방침상 하지 않는다(3.6.1).

11.5.12.2 설계 지점 — 브리지에도 비용이 든다

견해: 브리지 뒤에 로봇의 안전 로직을 두지 말라. 통신이 끊겨도 로봇이 스스로 멈추고 스스로 판단할 수 있어야 하며(3.9.3·8.7), 브리지는 관측과 상위 지시의 통로여야 한다. 이 경계를 흐리면 링크 품질이 안전 수준을 결정하게 된다.

견해: 개발에는 ①, 운영에는 ②가 대체로 맞는다. 개발 중에는 그래프를 늘려 익숙한 도구를 그대로 쓰는 편이 빠르고, 운영에서는 노출면과 대역을 통제할 수 있는 브리지가 안전하다. 둘을 한 시스템에 함께 두되 운영 기본값은 ②, 조사할 때만 ①을 여는 구성이 실무적이다.

11.5.10 함정 카탈로그

11.5.11 체크포인트

• rqt의 주요 플러그인 열 가지와 각각의 용도를 말할 수 있는가.
• rqt의 핵심 가치는 무엇인가.
• rqt_graph가 보여주지 않는 것 둘은? 그것을 확인하는 CLI 명령은?
• rqt_graph가 강한 영역과 약한 영역을 구분할 수 있는가.
• rqt_console과 grep의 분업은?
• rqt_reconfigure의 두 함정과 각각의 대처는?
• rqt_plot과 PlotJuggler의 차이 일곱 가지, 그리고 후자를 권하는 이유는?
• PlotJuggler의 전형적 분석 여섯 가지와 수식 활용 네 가지를 말할 수 있는가.
• "명령과 실제를 겹쳐 보기"가 제어 진단의 기본인 이유는?
• 주기 지터를 시계열로 봐야 하는 이유와, 패턴이 알려주는 것은?
• 탐색과 반복의 도구 분업 원칙은?
• CLI를 먼저 쓰라는 조언의 근거 셋은?
• "로봇이 안 간다" 진단의 다섯 단계와, 그 순서의 원리는?
• 튜닝 루프를 짧게 만드는 조합과, 그것을 가능하게 하는 사전 조치는?
• 원격에서 보는 두 접근(그래프 확장·브리지)의 트레이드오프를 말하고, 개발과 운영에 각각 무엇이 맞는지 설명할 수 있는가.
• 브리지 뒤에 로봇의 안전 로직을 두면 안 되는 이유는?

다음 장 11.6는 이 도구들로도 보이지 않는 것 — 실행 내부의 타이밍을 보는 트레이싱을 다룬다.