# 시뮬레이션 디버깅을 위한 rqt 및 로그 분석

rqt는 ROS 환경에서 다양한 디버깅과 시각화를 제공하는 통합 툴 세트이다. 시뮬레이션 환경에서 문제를 찾고, 토픽 정보를 빠르게 모니터링하거나, 로그를 통해 시스템 동작을 살펴보는 데 유용하다. ROS 2 Humble 버전에서도 rqt의 많은 플러그인이 그대로 사용 가능하며, ROS 2에 맞춰 개선된 UI나 기능을 활용할 수 있다.

일반적으로 시뮬레이션 환경에서 시스템이 의도대로 동작하는지 빠르게 확인하려면, 다음 두 가지가 가장 중요하다.

* 주어진 토픽의 송수신 상태
* 시스템이 출력하는 로그 메시지

이를 간단히 파악하려면 다음과 같은 rqt 플러그인을 사용할 수 있다.

* rqt\_graph
* rqt\_plot
* rqt\_console (rqt\_logger 대화형 패널 포함)

#### rqt\_graph

시뮬레이션에서 노드 간 데이터 흐름을 시각적으로 확인할 수 있는 툴이다. 시뮬레이션 환경이 복잡해질수록 노드와 토픽 수도 많아지는데, rqt\_graph를 통해 다음과 같은 정보를 빠르게 파악할 수 있다.

1. 어떤 노드가 어떤 토픽을 발행(Publish)하고 구독(Subscribe)하는지
2. 잘못된 QoS 설정으로 인한 통신 실패 여부
3. 불필요하게 많이 생성된 노드 또는 토픽

**rqt\_graph 사용 예시**

ROS 2 Humble 환경에서 rqt\_graph를 실행하려면 터미널에서 아래와 같이 입력한다.

```
$ ros2 run rqt_graph rqt_graph
```

시뮬레이터(Gazebo)와 함께 노드를 실행하고 위 명령어를 입력하면, rqt\_graph 창이 뜨면서 노드와 토픽의 연결 구조를 시각적으로 보여준다.

#### rqt\_console와 로그 레벨

rqt\_console는 노드에서 발생하는 로그 메시지를 실시간으로 확인하고 필터링할 수 있는 플러그인이다. 시뮬레이션 중 발생하는 Warn, Error, Debug 메시지를 확인하여 문제점의 원인을 파악할 수 있다.

ROS 2의 로그 레벨은 다음과 같다.

* DEBUG
* INFO
* WARN
* ERROR
* FATAL

ROS 2에서는 로깅 방식을 바꾸거나, 레벨을 동적으로 조정하여 더욱 상세한 정보를 얻을 수도 있다. 시뮬레이션 중 한 노드만 INFO 레벨로, 다른 노드는 DEBUG 레벨로 설정할 수도 있다.

**rqt\_console 실행 예시**

아래와 같이 명령어로 rqt\_console를 실행할 수 있다.

```
$ ros2 run rqt_console rqt_console
```

창이 열리면 상단 메뉴나 플러그인 패널을 통해 로그 메시지 필터를 걸거나 로거 수준을 변경할 수 있다.

#### rqt\_logger

rqt\_logger는 특정 노드에 대해 동적으로 로깅 레벨을 변경할 수 있는 패널을 제공한다. 시뮬레이션 과정에서 특정 노드에 대한 디버깅 정보를 더 많이 보고 싶다면, rqt\_logger를 통해 그 노드의 로그 레벨을 DEBUG로 설정하면 된다.

예를 들어, odometry 정보를 처리하는 노드가 잘 동작하는지 확인하고 싶다면, 아래 과정을 거칠 수 있다.

1. rqt\_logger 패널에서 해당 노드 선택
2. 로거 이름(일반적으로 패키지명이나 클래스명) 선택
3. DEBUG 레벨로 변경
4. 시뮬레이션 재실행 (또는 실시간 변경 반영)

이렇게 하면, 다른 노드들은 INFO 정도의 로그만 출력하더라도, 대상 노드는 세부 정보를 DEBUG로 출력하여 문제를 빠르게 찾을 수 있다.

#### ros2 doctor 및 추가 디버깅 툴

rqt 플러그인 외에도 ROS 2 Humble에는 ros2 doctor라는 진단 툴이 있어, 환경 설정, 토픽 상태, 노드 상태 등을 간략히 점검할 수 있다. rqt와 함께 활용하면, 시뮬레이션 상태를 보다 입체적으로 확인하고 문제를 더욱 체계적으로 추적할 수 있다.

예시:

```
$ ros2 doctor --report
```

이 명령어를 통해 ROS 2 네트워크 설정, 패키지 상태 등을 요약해서 보여주며, 어떤 부분이 잘못되었는지 힌트를 얻을 수 있다.

#### rqt\_plot

시뮬레이션 중에 특정 토픽의 값이 시시각각 어떻게 변하는지 모니터링할 때 유용한 플러그인이다. 예를 들어 로봇의 센서 데이터, 제어 입력, 상태 변수 등을 실시간 그래프로 시각화할 수 있다. 예를 들어, 라이다 거리나 로봇의 속도 값을 라인 차트로 표시함으로써 시뮬레이션 상황에서 특정 시점에 값이 급변하는 순간을 빠르게 파악할 수 있다.

rqt\_plot로 플롯하고 싶은 토픽을 여러 개 지정하여 각각을 서로 다른 축에 표시할 수도 있고, 하나의 축에 겹쳐서 비교할 수도 있다. 직관적인 그래프 시각화를 통해 다음과 같은 문제점을 진단하기 용이한다.

* 센서 값(예: IMU, 라이다, 카메라 등)이 잘 들어오지 않는 구간
* 제어 신호(예: 속도, 조향각 등)의 갑작스러운 변동
* 토픽이 발행되지 않는(또는 발행률이 떨어지는) 순간

ROS 2 Humble 환경에서 rqt\_plot을 실행하려면 다음 명령어를 사용할 수 있다.

```
$ ros2 run rqt_plot rqt_plot
```

실행 후, GUI 상단에서 “Topic” 버튼을 클릭한 뒤, 모니터링하고자 하는 토픽을 입력하면 그래프가 표시된다.

#### 토픽 모니터링 및 QoS 설정 문제

시뮬레이션에서 토픽 모니터링이 정확히 이루어지지 않는다면, QoS 설정이 맞지 않는 경우일 수 있다. ROS 2에서는 QoS(서비스 품질)를 설정해야 원활한 통신을 보장할 수 있는데, 시뮬레이션 환경처럼 많은 양의 데이터를 빠르게 주고받을 때 QoS 불일치는 종종 발생하는 문제이다.

예를 들어, 다음과 같은 QoS 프로필 불일치가 대표적인 예시이다.

* 퍼블리셔에서는 `RELIABLE` 모드, 서브스크라이버에서는 `BEST_EFFORT` 모드
* 퍼블리셔에서는 `TRANSIENT_LOCAL`, 서브스크라이버에서는 `VOLATILE`

이때 rqt\_graph나 rqt\_plot에서 해당 토픽의 데이터가 잘 들어오지 않는다면, rqt\_console의 WARN 또는 ERROR 메시지를 확인하여 QoS 불일치 여부를 파악할 수 있다.

#### ros2 topic 명령어 활용

ROS 2에서는 rqt를 사용하지 않고도 CLI(Command Line Interface) 명령어만으로도 토픽 정보를 확인할 수 있다. 시뮬레이션 환경에서 rqt가 제대로 동작하지 않는 상황이거나, 직접적인 디버깅을 위해 터미널 명령어가 필요할 때가 있다. 다음 명령어들을 참고하라.

```
$ ros2 topic list            # 현재 활성화된 토픽 목록을 출력
$ ros2 topic echo <토픽명>    # 해당 토픽의 메시지 실시간 출력
$ ros2 topic hz <토픽명>      # 해당 토픽의 발행 주기(Hz)를 측정
$ ros2 topic info <토픽명>    # 해당 토픽의 유형, 퍼블리셔와 서브스크라이버 노드 이름, QoS 정보 등
```

이러한 CLI 명령어를 활용하면, rqt\_graph에서 확인되는 토픽 연결 상태와 실제 메시지 흐름이 일치하는지 비교 가능하며, 발행 주기가 의도와 다르거나 QoS 문제가 있는 경우 빠르게 확인할 수 있다.

#### 로그 메시지 분석 고급 기법

rqt\_console, rqt\_logger와 함께 아래와 같은 접근 방식을 활용하면, 시뮬레이션 중 발생하는 문제를 더욱 세밀하게 추적할 수 있다.

1. **로거 이름별 필터링** ROS 2 노드가 많아질수록 로그 메시지도 기하급수적으로 증가한다. rqt\_console 상단의 필터 또는 검색 기능을 사용하여, 특정 패키지 혹은 노드 이름으로 필터링하면, 방대한 로그 중에서도 원하는 부분만 추출하여 볼 수 있다.
2. **ros2 param 명령어와 결합** ROS 2 노드에서 동적으로 파라미터(예: PID 제어 계수, TF 브로드캐스팅 주기)를 조정할 수 있다면, 로그 메시지를 보면서 실시간으로 파라미터 값을 변경해보는 방법도 좋다.

   ```
   $ ros2 param list
   $ ros2 param get <노드명> <파라미터명>
   $ ros2 param set <노드명> <파라미터명> <값>
   ```

   이렇게 파라미터를 변경한 후 로그를 주의 깊게 모니터링하면, 문제가 개선되는지 혹은 다른 경고 메시지가 나타나는지 확인할 수 있다.
3. **Trace 데이터 활용** 더 복잡한 시뮬레이션 상에서의 성능 문제(예: 메시지 지연, 스레드 블로킹 등)를 파악하기 위해서는, ros2 trace 같은 트레이싱 툴도 사용할 수 있다. rqt를 통한 로그 분석과 병행하면, 단순한 WARN, ERROR 메시지가 아닌 시간축 상의 이벤트 흐름까지 확인 가능해진다.

#### ros2 bag (rosbag2)와 시뮬레이션 로그 분석

시뮬레이션 실행 중 발생하는 데이터를 모두 실시간으로 모니터링하기는 쉽지 않는다. 특히 복잡한 시뮬레이션이나 장시간 수행되는 시뮬레이션에서는, 필요한 시점에 로그나 토픽 정보를 놓칠 수도 있다. 이런 상황에서 자주 사용되는 것이 rosbag2(ROS 2의 rosbag) 기능이다.

rosbag2를 활용하면 시뮬레이션에서 발생하는 토픽 메시지를 기록해 두었다가, 나중에 이를 재생하면서 rqt 플러그인을 통해 분석할 수 있다. 이를 통해 아래와 같은 작업을 할 수 있다.

1. **오프라인 분석** 시뮬레이션 진행 상황을 실시간으로 모두 모니터링하기 부담스러울 때, 모든 토픽을 기록해 두고 필요할 때 재생하면서 rqt\_graph, rqt\_plot, rqt\_console 등을 동원하여 문제점이나 이상 동작을 분석할 수 있다.
2. **다양한 시점 비교** 시뮬레이션 과정을 여러 차례 반복했을 때, rosbag2 파일들을 각각 따로 저장해 두었다가 동일한 시나리오에서의 로그 차이를 비교할 수 있다.
3. **토픽 & 로그 동기 분석** rosbag2 파일을 재생하면서, rqt\_console에서 각 시점별 로그를 함께 확인하면 해당 이벤트가 발생했던 상황(토픽 값)과 로그 내용이 어떻게 매칭되는지 정밀하게 파악할 수 있다.

**rosbag2 사용 예시**

아래 예시를 통해 시뮬레이션 상에서 발생하는 모든 토픽을 rosbag2로 기록할 수 있다.

```
# 모든 토픽을 기록
$ ros2 bag record -a -o my_sim_bag
```

`-a` 옵션은 모든 활성 토픽을 대상으로 하며, `-o` 옵션은 출력 파일(폴더) 이름을 설정한다. 시뮬레이션이 종료되거나, 더 이상 기록할 필요가 없을 때 Ctrl+C로 종료하면, `my_sim_bag`이라는 폴더가 생성된다.

이제 기록된 bag 파일을 재생하려면 다음 명령어를 사용한다.

```
$ ros2 bag play my_sim_bag
```

이와 동시에 rqt\_plot, rqt\_console, rqt\_graph 등 다양한 rqt 툴을 실행해 두면, rosbag에서 재생되는 시점의 토픽 메시지 흐름을 실제 시뮬레이션 중인 것처럼 분석할 수 있다.

#### rqt\_bag (ROS 2 버전 대안)

ROS 1 시절에는 rqt\_bag이라는 GUI 툴이 있어, bag 파일을 직접 열어서 시각적으로 타임라인을 탐색할 수 있었다. ROS 2 환경에서는 아직 ROS 1 버전만큼 완성도가 높은 rqt\_bag이 제공되지 않지만, 일부 기능은 계속 개선되고 있다.

* rosbag2 파일을 직접 열어 특정 토픽만 재생하거나
* 시간 범위를 지정하여 부분만 재생

이런 기능이 점차 도입되고 있으므로, 최신 ROS 2 Humble 패치 노트나 관련 패키지를 확인해 보면 더욱 편리하게 로그를 분석할 수 있다.

#### 시뮬레이션에서 발생하는 비정상 로그 추적

로봇 시뮬레이션은 가상 환경에서 이뤄지지만, 실제 디바이스 드라이버나 하드웨어 상에서 발생하는 문제들(예: 드라이버 미연결, 센서 데이터 오류 등)을 모사하기도 한다. 이때 rqt\_console를 통해 발견하기 어려운 시스템 수준 오류나 라이브러리 충돌 문제가 발생할 수 있다. 다음과 같은 접근을 해볼 수 있다.

**시스템 로그(dmesg, journalctl) 확인**: 시뮬레이션과 별개로 운영체제 레벨에서 발생하는 오류나 경고가 있는지 확인한다. 예:

```
$ dmesg | grep -i error
$ journalctl -p err
```

여기서 GPU 드라이버 오류, 메모리 부족, 네트워크 관련 에러 등을 찾아볼 수 있다.

**환경 변수 출력**: ROS 2 Humble에서 세팅한 환경 변수(예: `ROS_DOMAIN_ID`, `RMW_IMPLEMENTATION`, `LD_LIBRARY_PATH` 등)가 제대로 설정되지 않으면 일부 rqt 플러그인 또는 시뮬레이터가 동작하지 않을 수 있다.

```
$ printenv | grep ROS
```

이 명령어로 ROS 관련 환경 변수를 한 번에 확인하고, 설정이 잘못되어 있거나 누락되어 있는지 점검한다.

**라이브러리 버전 호환성 확인**: ROS 2 Humble부터는 일부 패키지 간 버전 호환성이 중요한 경우가 있다. rqt와 Gazebo, 그리고 시뮬레이션에 사용되는 플러그인(version lock)이 맞지 않으면, rqt에서 로그 필터가 안 된다거나, 특정 토픽이 차트에 표시되지 않는 문제점이 생길 수 있다.

#### Gazebo 콘솔 및 gz 로그 분석

Gazebo(ROS 2 Humble 버전에서는 대부분의 상황에서 gz 혹은 ignition 명령어 사용)도 자체 콘솔 로그를 남깁니다. 이는 ROS 2 노드들이 생성하는 로그와는 별개로, 물리 엔진이나 센서 플러그인 등이 출력하는 메시지를 담습니다. 시뮬레이션이 예기치 않게 종료되거나, Gazebo 인터페이스가 갑자기 먹통이 될 때는 Gazebo 로그를 확인해 보는 것이 좋다.

**Gazebo 로그 위치**

기본적으로 Gazebo 로그는 다음 경로에 저장된다.

* Linux: `~/.gazebo/log` 혹은 `~/.ignition/log`
* Windows: 설치 드라이브의 사용자 폴더 아래 (경로가 OS 환경에 따라 상이)

디버깅을 위해 시뮬레이션이 종료된 후에 이 로그 파일들을 열어보면, Gazebo 실행 시점부터 발생했던 에러 메시지와 경고(WARN), 시뮬레이션 시간에 따른 로그가 순차적으로 남아 있다.

**gz 명령어 예시**

ROS 2 Humble에서 Gazebo용 명령어들은 기존의 `gazebo` 대신 `gz` 또는 `ign`으로 시작하는 경우가 있다. 예를 들어, 실행 중인 Gazebo(또는 Ignition)에서 제공하는 토픽을 확인하려면:

```
$ gz topic -l
```

를 입력하고, 특정 토픽을 모니터링하려면:

```
$ gz topic -e <토픽명>
```

을 사용할 수 있다. 이는 `ros2 topic echo`와 유사하지만, Gazebo 자체가 발행하는 토픽(예: 물리 시뮬레이션 상태, 월드(World) 정보, 센서 데이터 등)을 직접 보여주므로, 시뮬레이션 뷰와 실제 물리 엔진 내부 상태가 일치하는지 여부를 파악할 수 있다.

#### rqt 및 Gazebo 로그를 종합적으로 분석하기

rqt\_console와 Gazebo 콘솔 로그를 동시에 모니터링하면, 다음과 같은 순서로 문제를 추적할 수 있다.

1. **Gazebo 콘솔(또는 gz CLI)을 통해 월드 및 물리 엔진 상태 점검**
   * 시뮬레이션 로드 시점에서 WARN 또는 ERROR가 발생했는지 확인
   * Gazebo 플러그인(예: 로봇 모델 플러그인, 센서 플러그인)에서 발생하는 에러 메시지 여부 확인
2. **rqt\_graph나 rqt\_plot을 사용하여 ROS 2 노드 및 토픽 모니터링**
   * Gazebo에서 발행하는 센서 토픽이 실제 ROS 2 레벨에서 정상적으로 수신되는지
   * 제어 명령(토픽)이 Gazebo로 정상 전달되고 있는지
3. **rqt\_console에서 ROS 노드 메시지 레벨 확인**
   * WARN 이상 레벨의 메시지가 지속적으로 발생하는지
   * 특정 시점에서 ERROR 메시지를 남긴 노드는 어떤 이유로 에러를 일으켰는지

이 과정을 순차적으로 거치면서, 시뮬레이션에서 발생하는 문제의 진짜 원인을 좁혀갈 수 있다.

#### mermaid를 이용한 디버깅 흐름 예시

아래는 시뮬레이션 디버깅을 위한 일반적인 흐름을 다이어그램으로 표현한 예시이다.

{% @mermaid/diagram content="flowchart LR
A(시뮬레이션 실행<br>Gazebo & ROS2 노드 구동) --> B\[Gazebo 로그 모니터링]
A --> C\[rqt\_graph / rqt\_plot로<br>토픽 상태 확인]
A --> D\[rqt\_console로<br>로그 레벨 모니터링]
B --> E{문제 발생 여부}
C --> E
D --> E
E -->|문제 없음| F(시뮬레이션 정상 진행)
E -->|문제 발견| G(원인 분석<br>QoS, 플러그인 충돌, 세팅 오류 등)
G --> H{환경 수정 혹은<br>코드 수정 후 재시도}
H --> A" %}

위 다이어그램에서 보듯, 시뮬레이션 실행 후 Gazebo, rqt\_graph, rqt\_console 등의 정보를 **반복적으로** 모니터링하고, 문제가 발견되면 원인을 찾아 수정한 뒤 다시 시뮬레이션을 수행하는 형태가 일반적이다.

#### ROS 2 노드 vs. Gazebo 플러그인 로그 비교

ROS 2 노드에서의 로그와 Gazebo 플러그인에서의 로그가 서로 다른 계층을 의미한다는 점을 인지해야 한다. 예를 들어, Gazebo 플러그인에서 심각한 에러가 발생했을 때, ROS 2 레벨의 노드는 토픽을 구독(또는 발행)하지 못할 수 있으나, 그 사실을 전혀 인지하지 못할 수도 있다. 이럴 때 rqt\_graph만 본다면 노드가 살아있는 것처럼 보이지만, Gazebo 월드 자체가 멈춰 있거나 플러그인이 중단된 상태일 수 있다. 따라서 시뮬레이션 문제를 확실히 해결하려면 반드시 Gazebo 로그와 ROS 2 로그를 **동시에** 모니터링해야 한다.

#### Gazebo & ROS 2 시뮬레이션 성능 문제 디버깅

디버깅 중 흔히 접할 수 있는 문제 중 하나는 “시뮬레이션이 지나치게 느려진다” 혹은 “로봇이 끊겨 움직인다” 같은 성능 문제이다. 이 경우 다음과 같은 단계를 거쳐 문제를 찾아나간다.

CPU/GPU 사용량 확인:

* `top`이나 `htop`, 또는 GPU 모니터링 툴(nvidia-smi 등)을 통해 Gazebo 또는 ROS 프로세스가 과도한 자원을 사용 중인지 확인한다.

시뮬레이션 해상도 혹은 물리 업데이트 간격 변경:

* Gazebo의 Update Rate, Physics step size(예: $\Delta t$) 등이 너무 높은 값으로 설정되어 있으면 CPU/GPU 부하가 커진다.

토픽 발행 주기 및 메시지 크기 점검:

* `ros2 topic hz`로 실제 토픽 발행 주기가 너무 빠른지(수백 Hz 이상), 메시지 크기가 과도하게 큰지(예: 고해상도 카메라 이미지)를 확인한다.

QoS 설정에 의한 패킷 누락:

* 발행 주기가 높은 토픽이 `RELIABLE` 모드로 설정되어 무리하게 네트워크(또는 로컬 DDS) 리소스를 소모하는지 확인한다.

ROS 2 및 Gazebo 모두에서 위 요소를 점검하고 필요할 경우 rqt\_console, gz console 로그 등을 보면서 상황을 유추해볼 수 있다.