# ros2 cli를 이용한 노드 상태 점검 #### 노드 리스트 확인 ROS2에서 노드를 진단할 때 가장 먼저 확인해야 할 정보는 현재 실행 중인 노드들의 목록이다. 이를 위해 다음 명령어를 사용할 수 있다. ``` ros2 node list ``` 위 명령어를 입력하면 현재 ROS2 네트워크 상에서 식별 가능한 모든 노드들의 이름이 출력된다. 일반적으로 ROS2는 서로 다른 프로세스에서 구동되는 노드를 서로 연결해 주며, 이 리스트는 ROS2 DDS 통신 계층에서 해당 노드들의 존재를 파악할 수 있을 때 업데이트된다. **예시 출력** ``` /turtle1_controller /turtle2_controller /teleop_twist_keyboard ``` 위 예시에서 `/turtle1_controller`, `/turtle2_controller`, `/teleop_twist_keyboard` 총 세 개의 노드가 확인된다. 노드 이름은 각 노드가 생성될 때 설정하거나 기본 값을 사용한 것이다. 노드 이름이 중복되면 ROS2 내부적으로 자동으로 이름에 숫자가 붙으므로, 개발 환경에서 동일 노드 이름을 여러 번 실행할 때는 주의가 필요하다. > **참고** ROS2에서는 노드의 이름이 고유 식별자가 아니다. 동일한 노드 이름을 갖는 여러 노드가 동시에 실행될 수 있으며, 이 경우 ROS2는 노드 이름을 유일하게 만들기 위해 내부적으로 `_X`와 같은 숫자를 자동으로 덧붙여 식별한다. #### 노드 상세 정보 조회 특정 노드에 대해 더 자세한 정보를 확인하기 위해서는 다음 명령어를 사용한다. ``` ros2 node info <노드이름> ``` 예를 들어 `/turtle1_controller` 노드의 정보를 확인한다고 가정하면 다음과 같다. ``` ros2 node info /turtle1_controller ``` **예시 출력** ``` /turtle1_controller Subscribers: /turtle1/cmd_vel: geometry_msgs/msg/Twist Publishers: /turtle1/pose: turtlesim/msg/Pose Service Servers: /turtle1/set_pen: turtlesim/srv/SetPen Service Clients: <없음> Action Servers: <없음> Action Clients: <없음> ``` 이를 통해 해당 노드가 어떤 토픽(Topic)을 구독(Subscriber)하고, 어떤 토픽을 퍼블리시(Publisher)하며, 어떤 서비스(Service)를 제공하거나(서버), 사용하는지(클라이언트)를 알 수 있다. 이러한 정보는 디버깅 시 매우 중요하다. 예컨대 특정 노드가 메시지를 발행하지 않고 있거나, 혹은 기대하는 서비스 인터페이스가 누락되어 있다면, 노드 간 통신 문제를 빠르게 파악할 수 있다. #### 노드 파라미터 확인 ROS2 노드는 많은 경우 파라미터(Parameters)를 사용하여 동작 모드를 설정하거나 내부 알고리즘에 필요한 상수값을 대입한다. 노드가 사용 가능한 파라미터 목록을 확인하고 싶다면 다음과 같은 명령어를 사용할 수 있다. ``` ros2 param list --node-name <노드이름> ``` 예를 들어 `/turtle1_controller` 노드에 대해 확인한다고 하면, ``` ros2 param list --node-name /turtle1_controller ``` 로 실행할 수 있다. 결과로는 해당 노드가 정의하고 있는 모든 파라미터 이름이 나열된다. 그리고 특정 파라미터의 값을 확인하기 위해서는 다음 명령어를 사용할 수 있다. ``` ros2 param get <노드이름> <파라미터이름> ``` 파라미터는 노드 동작에 영향을 주므로, 디버깅 과정에서 문제의 원인을 찾아낼 때 필수적으로 확인해야 한다. #### 토픽 정보 확인 노드에 대한 정보 확인 시, 해당 노드가 퍼블리시(Publish)하는 토픽과 구독(Subscribe)하는 토픽이 상호 정상적으로 데이터 통신을 하고 있는지 점검하는 것이 중요하다. 이를 위해 토픽 정보를 조회할 수 있는 명령어들이 마련되어 있다. **토픽 리스트 확인** 현재 ROS2 네트워크 상에서 존재하는 모든 토픽들을 확인하고 싶다면 다음 명령어를 실행한다. ``` ros2 topic list ``` 출력 예시는 다음과 비슷할 수 있다. ``` /tf /clock /turtle1/cmd_vel /turtle1/pose ``` 이 목록은 실제 동작 중인 노드들이 발행 또는 구독 중인 모든 토픽의 이름을 나열한 것이다. 토픽 이름에 접두사 `/`가 붙는 것은 ROS2에서 루트 네임스페이스를 의미하기 때문이다. **특정 토픽 상세 정보 조회** 특정 토픽의 메시지 타입, 퍼블리셔(Publisher), 서브스크라이버(Subscriber)가 궁금하면 다음 명령어를 사용한다. ``` ros2 topic info <토픽이름> ``` 예를 들어 `/turtle1/pose` 토픽에 대한 정보를 확인하면, ``` ros2 topic info /turtle1/pose ``` 출력 예시는 다음과 같이 나올 수 있다. ``` Type: turtlesim/msg/Pose Publisher count: 1 Subscriber count: 0 ``` * **Type**: 메시지 타입을 나타낸다. 여기서는 `turtlesim/msg/Pose`가 사용된다. * **Publisher count**: 현재 이 토픽에 데이터를 발행하는 노드(퍼블리셔)의 수이다. * **Subscriber count**: 이 토픽을 수신하여 사용하는 노드(서브스크라이버)의 수이다. 이 정보를 통해 특정 토픽에 대한 통신 방향을 파악할 수 있으며, 퍼블리셔 혹은 서브스크라이버가 의도와 다르게 0개인 경우 어떤 노드가 기대한 대로 동작하지 않는지 빠르게 확인할 수 있다. **토픽 메시지 타입 확인** 위 명령어를 통해 확인한 메시지 타입이 `turtlesim/msg/Pose`와 같이 확인되었다면, 다음과 같이 메시지 타입 정의를 좀 더 구체적으로 확인할 수 있다. ``` ros2 interface show turtlesim/msg/Pose ``` 출력은 다음과 같은 메시지 필드 목록이 될 수 있다. ``` float32 x float32 y float32 theta float32 linear_velocity float32 angular_velocity ``` 이를 통해 해당 메시지가 어떤 구조를 가지고 있는지 상세히 파악할 수 있으며, 노드 간 통신에서 올바른 메시지 타입을 사용하고 있는지 점검할 수 있다. #### 서비스 정보 확인 ROS2에서 서비스(Service)는 요청(Request)과 응답(Response)을 주고받는 통신 모델이다. 노드들이 사용 중인 서비스 인터페이스나 현재 실행 중인 서비스 서버, 클라이언트 정보를 확인하고 싶다면 다음 명령어들이 유용하다. **서비스 리스트 확인** 다음 명령어를 통해 현재 ROS2 네트워크에서 사용 중인 서비스 이름을 확인할 수 있다. ``` ros2 service list ``` 출력 예시는 다음과 유사할 수 있다. ``` /turtle1/teleport_absolute /turtle1/set_pen ``` 여기서 `/turtle1/teleport_absolute`, `/turtle1/set_pen`은 각각의 서비스 이름이다. **특정 서비스 정보 조회** 특정 서비스의 요청, 응답 타입 등 상세 정보를 확인할 때는 다음 명령어를 사용한다. ``` ros2 service type <서비스이름> ``` 예를 들어 `/turtle1/set_pen` 서비스에 대해 타입을 조회하면, ``` ros2 service type /turtle1/set_pen ``` 출력 예시는 다음과 같이 나온다. ``` turtlesim/srv/SetPen ``` 확인된 서비스 타입을 `ros2 interface show`로 다시 조회하면, 요청(Request)과 응답(Response)에 대한 메시지 필드를 알 수 있다. ``` ros2 interface show turtlesim/srv/SetPen ``` 출력은 대략 다음과 같은 형식을 가진다. ``` uint8 r uint8 g uint8 b uint8 width uint8 off --- ``` 요청과 응답이 `---` 구분으로 나뉘어 있다. #### 액션 정보 확인 ROS2의 액션(Action)은 목표(Goal)와 피드백(Feedback), 결과(Result) 세 단계를 통해 작업이 진행되는 구조를 가진다. 노드가 액션 인터페이스를 사용 중이라면, 다음 명령어로 현재 실행 중인 액션 서버와 액션 클라이언트를 조회할 수 있다. ``` ros2 action list ``` 또는 특정 액션의 타입을 확인하기 위해서는: ``` ros2 action type <액션이름> ``` 을 사용한다. 이를 통해 액션 목표, 결과, 피드백 메시지 구조를 확인할 수 있다. #### ros2 daemon 활용 ROS2에서는 `ros2 daemon` 명령어를 통해 내부에서 동작하는 DDS(데이터 분산 서비스) 관련 데몬을 제어하고 상태를 확인할 수 있다. ROS2 CLI 명령어들은 대부분 이 데몬을 통해 노드, 토픽, 서비스 등의 정보를 조회하기 때문에, 데몬의 상태가 불안정하거나 통신이 원활하지 않으면 CLI 명령어 결과가 제대로 나오지 않을 수 있다. **데몬 상태 확인** 현재 데몬이 정상적으로 동작 중인지, 혹은 어떤 상태인지 알아보기 위해서는 다음 명령어를 사용할 수 있다. ``` ros2 daemon status ``` 출력 예시: ``` The daemon is running. ``` 만약 데몬이 이미 실행 중이지만 네트워크나 DDS 레이어 문제 등으로 인해 정보를 제대로 수집하지 못하는 경우도 있을 수 있다. **데몬 종료 및 재시작** 데몬과 관련된 문제가 의심될 때는 데몬을 강제 종료한 뒤 다시 시작해 볼 수 있다. ``` ros2 daemon stop ros2 daemon start ``` * **stop**: 현재 동작 중인 데몬을 종료한다. * **start**: 데몬을 다시 실행한다. 만약 CLI 명령어들이 결과를 제대로 출력하지 않는다면, 일단 위 명령어들을 통해 데몬을 재시작하고 다시 시도하는 것이 좋다. #### ros2 doctor 활용 ROS2 Humble 버전 이상에서는 `ros2 doctor` 명령어를 통해 ROS2 환경 설정 및 네트워크 상태 등을 간단히 점검할 수 있다. 이는 ROS1에서 제공되던 `roswtf` 유틸리티와 유사한 기능을 제공한다. ``` ros2 doctor ``` 이 명령어를 입력하면 ROS\_DOMAIN\_ID, RMW Implementation, DDS 네트워크 상태 등 현재 ROS2가 동작하는 데 필요한 주요 정보 및 진단 결과를 표시한다. 예컨대 패키지가 올바르게 설치되지 않았거나, DDS 관련 환경 변수가 잘못 설정되어 있는 경우, 이를 감지하고 경고를 표시한다. **진단 상세 옵션** * `--report`: 세부 진단 보고서를 한 번 더 자세하게 제공한다. * `--pre`: 기본 진단 과정을 수행하기 전, 환경 변수를 먼저 점검한다. * `--post`: 기본 진단 과정을 수행한 후의 상태를 출력한다. #### ros2 topic echo / pub 노드 간 토픽 통신 상태를 직접 모니터링하거나 테스트 메시지를 발행해야 할 때 유용한 명령어가 `ros2 topic echo`와 `ros2 topic pub`이다. **ros2 topic echo** 특정 토픽으로 발행되는 메시지를 실시간으로 확인할 수 있는 명령어이다. ``` ros2 topic echo /turtle1/pose ``` 실행 시, `/turtle1/pose` 토픽으로 발행되는 `turtlesim/msg/Pose` 메시지를 터미널에서 계속해서 출력해 준다. ``` x: 5.544445 y: 5.544445 theta: 0.000000 linear_velocity: 0.000000 angular_velocity: 0.000000 --- ``` 이를 통해 토픽이 의도대로 발행되고 있는지, 메시지 값은 정상적인지 실시간으로 점검할 수 있다. **ros2 topic pub** 특정 토픽에 테스트 메시지를 손수 발행할 수 있는 명령어이다. 예컨대 `geometry_msgs/msg/Twist` 타입의 메시지를 `/turtle1/cmd_vel` 토픽에 발행해 볼 수 있다. ``` ros2 topic pub /turtle1/cmd_vel geometry_msgs/msg/Twist "{linear: {x: 2.0}, angular: {z: 1.0}}" --once ``` 위 명령어는 아래와 같은 의미를 가진다. * **/turtle1/cmd\_vel**: 발행할 대상 토픽 이름 * **geometry\_msgs/msg/Twist**: 메시지 타입 * **"{linear: {x: 2.0}, angular: {z: 1.0}}"**: 실제 메시지 내용 * **--once**: 한 번만 발행한다(옵션을 생략하면 일정 간격으로 반복 발행 가능) 이런 식으로 직접 메시지를 발행하면서, 구동 중인 노드가 해당 토픽을 잘 처리하는지 테스트할 수 있다. #### ros2 service call 서비스 통신이 정상적으로 이뤄지는지 확인하기 위해, CLI에서 직접 서비스 요청을 보낼 수 있는 명령어이다. ``` ros2 service call /turtle1/set_pen turtlesim/srv/SetPen "{r: 255, g: 0, b: 0, width: 3, off: 0}" ``` * **/turtle1/set\_pen**: 호출할 서비스 이름 * **turtlesim/srv/SetPen**: 서비스 타입 * **"{r: 255, g: 0, b: 0, width: 3, off: 0}"**: 요청(Request)에 해당하는 데이터 이를 통해 `/turtle1/set_pen` 서비스가 정상적으로 요청을 받아서 응답하는지 확인할 수 있다. #### ros2 param set 디버깅 과정에서 파라미터를 실시간으로 수정해야 할 때 사용하는 명령어이다. 예를 들어 `my_node` 노드의 `max_speed` 파라미터를 수정하는 경우: ``` ros2 param set /my_node max_speed 10.0 ``` 성공적으로 값이 바뀌면 다음과 같은 응답이 온다. ``` Set parameter successful ``` 이후 `ros2 param get /my_node max_speed`로 해당 파라미터의 값이 실제로 변경되었는지 재확인할 수 있다. #### 라이프사이클 노드 상태 점검 ROS2에는 노드의 상태를 체계적으로 관리하기 위한 라이프사이클(Lifecycle) 개념이 있다. 라이프사이클 노드는 특정 상태 전이를 통해 동작을 제어할 수 있으며, 상태 전이가 일어날 때마다 콜백 함수를 통해 설정, 초기화, 정리 등을 수행할 수 있다. 이러한 라이프사이클 노드의 상태를 점검하고 제어하기 위해서는 다음과 같은 CLI 명령어를 활용한다. **라이프사이클 노드 조회** 라이프사이클 노드 목록을 확인하고 싶다면 아래 명령어를 사용한다. ``` ros2 lifecycle list ``` 출력 예시: ``` Managed nodes: /lifecycle_talker /lifecycle_listener ``` * **/lifecycle\_talker**, **/lifecycle\_listener**와 같이 `rclcpp_lifecycle`을 사용하여 구현된 노드들이 표시된다. **라이프사이클 노드 상태 확인** 특정 노드가 현재 어떤 상태인지 알고 싶다면 다음 명령어로 확인할 수 있다. ``` ros2 lifecycle get <노드이름> ``` 예시: ``` ros2 lifecycle get /lifecycle_talker ``` 출력 예시: ``` Current state of node "/lifecycle_talker": "inactive" ``` 라이프사이클 노드는 일반적으로 다음과 같은 주요 상태를 갖는다. * **unconfigured**: 노드가 초기 구성을 하기 전 상태 * **inactive**: 노드의 구성이 완료되었으나, 아직 활성화되지 않은 상태 * **active**: 실제로 데이터 처리를 수행하고 콜백이 활성화된 상태 * **finalized**(shut down): 노드가 종료되고 더 이상 활동하지 않는 상태 **라이프사이클 상태 전이** 라이프사이클 노드를 수동으로 다른 상태로 전이시키려면 다음 명령어를 사용할 수 있다. ``` ros2 lifecycle set <노드이름> <이동할 상태명> ``` 예컨대 `/lifecycle_talker`를 활성화(activate)하려면, ``` ros2 lifecycle set /lifecycle_talker activate ``` > **참고** 라이프사이클 노드가 `unconfigured` 상태라면 먼저 `configure` 상태로 전이를 시도해야 하며, `inactive` 상태에서만 `activate`로 전이할 수 있다. 만약 전이 가능한 조건이 만족되지 않으면 에러 메시지가 표시된다. 아래는 대표적인 상태 전이 명령어 예시이다. * `ros2 lifecycle set /lifecycle_talker configure` * `ros2 lifecycle set /lifecycle_talker activate` * `ros2 lifecycle set /lifecycle_talker deactivate` * `ros2 lifecycle set /lifecycle_talker cleanup` * `ros2 lifecycle set /lifecycle_talker shutdown` 이와 같이 노드의 상태를 단계적으로 전이시키면서, 원하는 시점에 노드 동작을 정지하거나 재시작해 볼 수 있다. 이는 각 단계에서 수행하는 설정 로직, 해제 로직, 에러 핸들링 로직 등을 시험하고 디버깅하는 데 유용하다. #### 노드 상태 점검 시 유의사항 1. **DDS 통신 레이어 확인** 노드, 토픽, 서비스, 액션 등 모든 통신 계층은 DDS를 통해 이루어진다. 만약 DDS 관련 환경 변수 설정이나 네트워크 환경에 문제가 있다면, CLI 명령어 결과가 불완전할 수 있다. 2. **라이프사이클 노드와 일반 노드 혼동 주의** 라이프사이클 노드는 특별한 상태 전이 로직을 갖는다. 일반 노드에는 `ros2 lifecycle` 명령어가 적용되지 않으며, `ros2 node list` 결과에는 일반 노드와 라이프사이클 노드가 구분 없이 함께 표시된다. 3. **네임스페이스** 노드 이름에 네임스페이스가 포함되어 있을 수 있다. 예: `/robot1/lifecycle_talker`. 이 경우 CLI 명령어에서도 전체 이름을 정확히 입력해야 한다. 4. **멀티 머신 환경** 여러 대의 컴퓨터가 네트워크를 통해 DDS를 공유하고 있다면, 각 머신의 ROS\_DOMAIN\_ID나 DDS 설정이 불일치하지 않도록 주의해야 한다. #### 토픽 주파수와 대역폭 측정 노드 간 토픽 통신에서 문제가 발생하는 경우, 메시지가 정상적으로 발행되고 있는지, 얼마나 빈번하게 발행되는지, 또 얼마나 많은 데이터를 송수신하는지 확인해야 할 때가 많다. 이를 확인하기 위한 명령어로 `ros2 topic hz`와 `ros2 topic bw`가 있다. **ros2 topic hz** 특정 토픽으로 발행되는 메시지의 주파수(Hz, 초당 메시지 수)를 측정할 수 있다. 예시: ``` ros2 topic hz /turtle1/pose ``` 출력 예시: ``` average rate: 62.492 min: 0.014s max: 0.017s std dev: 0.0004s window: 64 ``` * **average rate**: 평균 메시지 발행 주기(주파수) * **min, max**: 최근 측정한 메시지 간격의 최소/최대값 * **std dev**: 메시지 간격의 표준편차 * **window**: 통계 계산에 사용된 메시지 개수 ROS2 노드가 메시지를 1초에 몇 회 정도 발행하는지 파악할 수 있으며, 의도한 주기(예: 10Hz)와 실제 주기가 다르다면 시스템 상태나 노드 로직을 점검해야 한다. **ros2 topic bw** 특정 토픽으로 발행되는 메시지의 대역폭(초당 전송되는 데이터량)을 측정할 수 있다. 예시: ``` ros2 topic bw /camera/image_raw ``` 출력 예시: ``` Subscribed to [/camera/image_raw] BW: 1.58 MiB/s (1.58e+06 B/s) Msg size: 1228800 Bytes Messages in last second: 1 ``` * **BW**: 현재 측정한 대역폭(초당 바이트 전송량) * **Msg size**: 메시지 1건 당 크기 * **Messages in last second**: 최근 1초 동안 수신한 메시지 수 카메라 영상 토픽과 같이 대용량 메시지를 전달하는 노드를 디버깅할 때 유용하다. 대역폭이 지나치게 높아 네트워크에 부담이 걸리거나, 예상보다 낮아 영상 프레임이 제대로 전송되지 않는 문제가 있는지 확인할 수 있다. #### 토픽 지연 시간 측정 네트워크 환경이나 노드 성능에 따라 토픽 지연(Latency)이 발생할 수 있다. ROS2 Foxy 시절에는 `ros2 topic delay` 명령어가 별도로 존재하지 않았으나, Humble 또는 이후 버전에서 유틸리티 패키지를 통해 측정이 가능할 수 있다. (일부 환경에서는 별도 패키지 설치가 필요할 수 있다.) 일반적으로 지연 시간을 측정하기 위해서는 퍼블리셔와 서브스크라이버가 직접 타임스탬프를 기록하고, 메시지가 도착했을 때의 시간을 비교하여 지연 시간을 계산한다. 이를 수동으로 구현하거나, `ros2 topic echo` 결과의 타임스탬프를 참고하여 계산할 수도 있다. #### QoS 설정 점검 ROS2 토픽 통신은 QoS(Quality of Service) 설정에 의해 동작이 달라질 수 있다. 예를 들어, RMW 설정에 따라 신뢰 모드(Reliability), 내구성(Durability) 등의 파라미터가 달라지면 토픽 구독이 실패하거나 의도치 않은 통신 방식을 야기할 수 있다. ``` ros2 topic info /example_topic --verbose ``` 위와 같이 `--verbose` 옵션을 사용하면 QoS 정보까지도 확인 가능하다. 출력 예시: ``` Type: example_interfaces/msg/String Publisher count: 1 Subscriber count: 1 Node name: /my_node QoS profile: Reliability: BEST_EFFORT Durability: VOLATILE ... ``` 퍼블리셔와 서브스크라이버 간 QoS 호환성이 맞지 않으면 ROS2 통신 계층에서 연결이 성립되지 않는다. 따라서 디버깅 시 QoS 파라미터를 꼼꼼히 확인해야 한다. #### rqt 플러그인 활용 CLI 명령어 외에도 ROS2에서 `rqt` 플러그인을 사용하면 GUI 환경에서 토픽, 노드, 파라미터 등을 시각적으로 확인할 수 있다. 예: ``` rqt ``` 실행 후 상단 메뉴에서 플러그인을 추가해 `Nodes`, `Topics`, `Services` 등을 탐색할 수 있다. 메시지 주파수나 대역폭도 시각화 플러그인을 통해 확인 가능하므로, CLI 사용이 불편할 때는 `rqt`를 적극적으로 활용하는 편이 좋다. #### ros2 graph로 노드 상호 연결 구조 확인 ROS2 노드들의 상호 연결 관계(토픽, 서비스 등)를 한눈에 파악하고 싶다면 `ros2 graph` 명령어가 유용하다. 이 명령어는 현재 노드들 간의 통신 그래프를 텍스트 형태로 보여준다. ``` ros2 graph ``` 출력 예시: ``` subgraph cluster_0 { label="/" "/talker" -> "/listener" [label="/chatter"] } ``` * **"/talker" -> "/listener" \[label="/chatter"]**: `talker` 노드가 `/chatter` 토픽으로 메시지를 발행(Publish)하고, `listener` 노드가 이를 구독(Subscribe)한다는 의미를 나타낸다. * `subgraph cluster_0 { ... }` 구문은 노드들이 같은 네임스페이스에 속해 있음을 나타낸다. 출력 형식은 DOT(Graphviz) 기반이므로, 실제 시각적인 그래프를 확인하려면 DOT 파일을 별도로 생성하여 Graphviz 같은 툴로 열 수도 있다. **그래프를 직접 파일로 저장** 다음과 같이 DOT 형식으로 파일에 저장한 후, Graphviz를 이용하여 시각화할 수 있다. ``` ros2 graph --dot > ros2_graph.dot dot -Tpdf ros2_graph.dot -o ros2_graph.pdf ``` * **--dot**: DOT 포맷으로 그래프 정보를 출력한다. * **dot -Tpdf**: DOT 파일을 PDF로 변환한다. 이렇게 생성된 `ros2_graph.pdf` 파일을 열어보면, 노드 간 토픽 흐름을 시각적으로 확인할 수 있다. #### ros2 node kill 디버깅을 위해 특정 노드를 강제로 종료해야 하는 상황이 있을 수 있다. 이전에는 터미널에서 실행한 노드를 강제로 종료하려면 해당 터미널 세션을 중단하거나 프로세스 ID를 찾아 `kill` 명령을 사용했다. 이제 ROS2 CLI에서 다음 명령어로 노드를 직접 종료할 수 있다. ``` ros2 node kill <노드이름> ``` 예시: ``` ros2 node kill /talker ``` 정상적으로 종료되면 이후 `ros2 node list`에서 해당 노드가 사라지게 된다. 다만 노드가 올바르게 구현되지 않았거나, OS 신호 처리를 무시하도록 작성된 경우에는 실제로 종료되지 않을 수도 있다. #### ros2 component CLI ROS2는 노드를 시스템 자원 효율적으로 구동하기 위해 ‘컴포넌트(Component)’라는 개념을 제공한다. 이를 이용하면 여러 노드를 하나의 프로세스에서 동적으로 로드하거나 언로드할 수 있다. 만약 컴포넌트 형태로 개발된 노드를 디버깅해야 한다면 다음 명령어를 참고하자. * **ros2 component list**: 컴포넌트를 로드해 둔 프로세스(예: `component_container`)에 현재 어떤 컴포넌트들이 등록되어 있는지 확인한다. * **ros2 component load**: 러닝 중인 컴포넌트 컨테이너 프로세스에 원하는 컴포넌트를 동적으로 로드한다. * **ros2 component unload**: 이미 로드된 컴포넌트를 언로드한다. 이러한 컴포넌트 CLI를 사용하면 프로세스를 재시작하지 않고도 노드를 동적 로드/언로드할 수 있어, 각 노드 상태를 개별적으로 확인하고 디버깅하기 편리하다. #### ros2 trace를 이용한 런타임 추적 ROS2에서는 런타임에 발생하는 다양한 이벤트(콜백 호출, 스레드 스위치, 메모리 할당 등)를 추적(trace)하여 성능 및 상태를 분석할 수 있는 도구인 `tracetools` 패키지를 제공한다. 이를 간단히 사용할 수 있는 CLI가 바로 `ros2 trace`이다. **ros2 trace 시작** 다음 예시는 노드를 구동하는 동안 발생하는 ROS2 이벤트를 기록할 수 있는 추적 세션을 시작하는 명령어이다. ``` ros2 trace start ``` 추적이 시작되면, 기본적으로 `$HOME/.ros/tracing/` 아래에 타임스탬프 기반 폴더(예: `session-2024-12-29-12-00-00/`)가 생성되어, 그 안에 LTTng으로 수집된 추적(trace) 데이터가 저장된다. **사용자 정의 추적 옵션** `ros2 trace` 명령어에는 여러 옵션을 설정할 수 있다. * **--session-name**: 추적 세션 이름을 지정 (기본은 시간 기반) * **--output-directory**: 출력 디렉토리를 직접 지정 * **--events-regex**: 추적할 이벤트 이름을 정규 표현식으로 필터링 * **--kernel**, **--userspace**: 커널 공간, 유저 공간 이벤트를 각각 추적할지 여부 예시: ``` ros2 trace start --session-name my_trace --output-directory /tmp/ros2_trace ``` 이렇게 실행하면 `/tmp/ros2_trace/my_trace/` 경로에 추적 데이터가 저장된다. **ros2 trace 중지** 추적을 멈추려면 다음 명령어를 사용한다. ``` ros2 trace stop ``` 이후 LTTng 기반의 추적 세션이 종료되며, 기록된 데이터를 오프라인 분석 툴(예: [Trace Compass](https://www.eclipse.org/tracecompass/))이나 `tracetools_analysis` Python 라이브러리를 통해 정밀 분석할 수 있다. **활용 예시** * **콜백 지연 분석**: 노드에서 콜백 실행이 지연되는 이유를 찾기 위해, 콜백 스케줄링과 실행 시간을 정밀 추적한다. * **멀티스레딩 이슈 디버깅**: 스레드 간 문맥 전환과 락 경쟁 현상을 추적해, 병목 구간을 파악한다. * **시스템 전반 성능 진단**: CPU 로드, DDS 통신 레이어에서의 메시지 전달 순서, rclcpp에서 발생하는 이벤트 등을 통합적으로 관찰한다. *** 지금까지 `ros2 node`, `ros2 param`, `ros2 topic`, `ros2 service`, `ros2 lifecycle`, `ros2 graph`, `ros2 component`, `ros2 trace` 등 다양한 ROS2 CLI 툴을 이용하여 노드 상태를 점검하고 디버깅하는 방법에 대해 살펴보았다. 이러한 CLI 도구는 각종 문제 상황을 빠르게 진단하고, 노드 간 상호 작용의 전반적인 흐름을 시각화·분석할 수 있게 해 준다.