# ros2 topic, ros2 service, ros2 action 명령어 활용 #### 로깅과 디버깅을 위한 CLI 활용 개요 ROS2 Humble 환경에서 노드의 상태나 데이터 흐름을 파악하기 위해 가장 먼저 고려해야 할 요소 중 하나가 바로 명령줄 인터페이스(CLI)이다. 특히 로깅과 디버깅 과정에서 다음과 같은 CLI 명령어들은 빠르고 간단하게 시스템 상태를 점검하고 이슈를 파악하는 데 큰 도움을 준다. * `ros2 topic` * `ros2 service` * `ros2 action` 이번 절에서는 로깅과 디버깅에 핵심이 되는 이 세 가지 명령어의 세부 활용법을 집중적으로 살펴본다. #### ros2 topic 명령어의 종류와 사용법 ROS2에서 토픽(topic)은 노드 간 통신의 기본적인 단위이다. 로깅 및 디버깅을 위해 특정 토픽의 메시지가 잘 송수신되고 있는지, 혹은 메시지의 내용이 어떤지를 확인할 일이 잦습니다. 이를 위해 ROS2는 `ros2 topic`이라는 명령어 세트를 제공한다. **ros2 topic list** * 전체 토픽 목록을 확인한다. * 예시: ```bash ros2 topic list ``` * 로깅을 위해 토픽 목록을 주기적으로 확인하면서 새로 생긴 토픽이나 사라진 토픽을 추적할 수 있다. **ros2 topic echo** * 특정 토픽으로부터 실제 메시지가 어떻게 들어오는지 콘솔에서 확인할 수 있다. * 예시: ```bash ros2 topic echo /chatter ``` * 지속적으로 메시지를 모니터링하며 예상치 못한 데이터가 들어오는지 확인할 수 있고, 이를 통해 디버깅 힌트를 얻을 수 있다. **ros2 topic info** * 특정 토픽에 대한 정보를 확인한다. * 예시: ```bash ros2 topic info /image_raw ``` * 노드 목록, 메시지 타입, 퍼블리셔/서브스크라이버 수 등을 확인할 수 있어, 통신 구조가 의도한 대로 구현되었는지 점검할 수 있다. **ros2 topic type** * 특정 토픽의 메시지 타입을 확인한다. * 예시: ```bash ros2 topic type /scan ``` * 로깅 시 메시지를 파싱할 때 필요하므로, 해당 토픽의 타입을 알아두면 디버깅 시 유용하다. **ros2 topic pub** * 특정 토픽에 임의의 메시지를 퍼블리시한다(디버깅용). * 예시: ```bash ros2 topic pub /test_topic std_msgs/String "data: 'Hello ROS2'" ``` * 잘못된 형태의 메시지를 퍼블리시함으로써 에러 상황을 재현해보거나, 원하는 시점에 데이터를 보내 시스템이 어떻게 반응하는지 볼 수 있다. **ros2 topic bw (Bandwidth)** * 특정 토픽의 대역폭 사용량(bandwidth)을 측정한다. * 예시: ```bash ros2 topic bw /camera/image_raw ``` * 로깅 과정에서 대규모 데이터를 퍼블리시하는 토픽이 성능 저하나 네트워크 병목을 일으키는 원인이 될 수 있으므로, 이를 주기적으로 확인하여 시스템 병목 구간을 파악할 수 있다. **ros2 topic hz (Frequency)** * 특정 토픽의 발행 주기(초당 메시지 수)를 측정한다. * 예시: ```bash ros2 topic hz /scan ``` * 센서 주기가 의도한 대로 동작하는지 확인하고, 주기의 변동이 있는 경우 로깅 파일과 대조하여 문제점을 추적할 수 있다. #### ros2 topic 명령어 활용 시 주의사항 * 노드와 토픽 이름이 일관성 있게 관리되어야 한다. 디버깅 중간에 토픽 이름을 변경하면 로깅 및 추적이 복잡해질 수 있다. * 터미널에서 `ros2 topic echo`를 실행 중인 상태에서 ROS2 노드를 재시작하면, 에코 화면에 오류가 발생하거나 끊길 수 있으므로 주의해야 한다. * ROS2 Humble에서는 DDS 구현체에 따라 토픽 정보 수집에 약간의 지연이 발생할 수 있으므로, 이를 염두에 두고 로깅 데이터와 실시간 데이터를 비교해야 한다. #### ros2 service 명령어의 종류와 사용법 ROS2 서비스(service)는 노드 간에 동기적인 요청(Request)과 응답(Response) 패턴으로 통신하는 방식을 제공한다. 이를 통해 특정 기능을 호출하고 그 결과를 빠르게 확인할 수 있으므로, 로깅과 디버깅 작업 시 원하는 시점에 함수를 수행해보거나 에러 발생 지점을 재현하기가 용이한다. ROS2에서 서비스 관련 기능을 확인하거나 호출하기 위해서는 다음과 같은 `ros2 service` 하위 명령어들을 활용한다. **ros2 service list** * 현재 활성화되어 있는 서비스 목록을 확인한다. * 예시: ```bash ros2 service list ``` * 어떤 노드가 어떤 서비스를 제공하고 있는지 파악할 수 있으므로, 시스템 구성을 빠르게 파악하고 로깅 대상 혹은 디버깅 대상 서비스를 찾는 데 유용하다. **ros2 service type** * 특정 서비스의 타입(인터페이스)을 확인한다. * 예시: ```bash ros2 service type /add_two_ints ``` * 예측과 다른 타입을 사용하는 경우 로깅 시스템에서 에러가 발생할 수 있으므로, 서비스를 호출하기 전에 타입 정보가 정확히 일치하는지 확인해야 한다. **ros2 service call** * 특정 서비스에 실제 요청(Request)을 보내고, 그 결과(응답, Response)를 즉시 확인한다. * 예시: ```bash ros2 service call /add_two_ints example_interfaces/srv/AddTwoInts "{a: 2, b: 3}" ``` * 로깅 시 에러를 재현하거나, 정상 동작 여부를 확인하기 위해 서비스 호출이 유용하다. 또한 서비스 응답 데이터를 통해 시스템 로직이 예상대로 동작하는지 판단할 수 있다. **ros2 service find** * 특정 서비스 타입을 사용하고 있는 모든 서비스 이름을 찾는다. * 예시: ```bash ros2 service find example_interfaces/srv/AddTwoInts ``` * 여러 노드에서 동일한 서비스 타입을 사용하고 있을 수 있으므로, 로깅 시 어떤 노드가 해당 서비스를 실제로 제공하는지 빠르게 파악할 수 있다. **ros2 service info** * 특정 서비스에 대한 자세한 정보를 확인한다. * 예시: ```bash ros2 service info /add_two_ints ``` * 노드 이름, 서비스 타입, 제공 혹은 사용 여부 등을 파악하여 로깅 과정에서 점검해야 할 주요 지점을 쉽게 찾아낼 수 있다. #### ros2 service 명령어 활용 시 주의사항 * 서비스는 요청-응답 패턴으로 동작하기 때문에, 서비스 서버 노드가 실행 중이지 않으면 호출에 실패한다. 따라서 디버깅 과정에서 서버 노드의 상태를 항상 체크해야 한다. * 서비스는 실시간성이 큰 토픽에 비해 요청-응답 패턴 때문에 지연이 발생할 수 있으므로, 로깅할 때 타임스탬프나 처리 시간을 꼼꼼히 확인해야 한다. * ROS2 Humble에서 서비스 관련 API가 DDS 구현체 및 RMW(Robot Middleware) 계층에 따라 차이가 있을 수 있으므로, 디버깅 시 환경 설정과 버전을 명확히 기록하는 것이 좋다. #### ros2 action 명령어의 종류와 사용법 ROS2 액션(action)은 토픽과 서비스의 장점을 결합한 통신 방식으로, 긴 시간에 걸쳐 수행되어야 하는 작업을 요청하고 그 상태(progress)를 주기적으로 전송받거나, 목표(goal)를 취소하는 등의 기능을 제공한다. 긴 시간을 소요하는 동작이나 제어 명령 등을 디버깅할 때 액션을 사용하면 진행 상황을 간편하게 모니터링할 수 있다. 로깅 시에는 액션 상태와 결과 메시지를 중요한 데이터로 저장해두면, 실패 지점이나 지연 이슈를 빠르게 파악할 수 있다. ROS2에서 액션에 관련된 정보를 확인하거나 액션을 호출하기 위한 CLI 인터페이스로는 `ros2 action`이 제공된다. 주요 하위 명령어는 다음과 같다. **ros2 action list** * 현재 사용 가능한 액션 서버 목록을 확인한다. * 예시: ```bash ros2 action list ``` * 로깅할 때 어떤 액션이 실행 가능한지 빠르게 파악할 수 있다. **ros2 action type** * 특정 액션 서버의 액션 타입(인터페이스)을 확인한다. * 예시: ```bash ros2 action type /fibonacci ``` * 액션 타입에는 Goal, Feedback, Result 메시지 타입이 정의되어 있으므로, 로깅 과정에서 어떤 데이터 구조가 오고 가는지 파악할 수 있다. **ros2 action send\_goal** * 액션 서버에 Goal을 전송하고, 진행 상황 및 결과를 받아온다. * 예시: ```bash ros2 action send_goal /fibonacci example_interfaces/action/Fibonacci "{order: 10}" ``` * 로깅 시 액션의 Goal을 명시적으로 보내어 시스템이 수행 과정에서 어떤 데이터를 Publish하는지 실시간으로 모니터링할 수 있다. **ros2 action send\_goal --feedback** * Goal 전송 시 피드백 메시지도 함께 콘솔에 출력해준다. * 예시: ```bash ros2 action send_goal /fibonacci example_interfaces/action/Fibonacci "{order: 10}" --feedback ``` * 액션이 수행 중에 주기적으로 발생하는 상태 정보를 확인하면서, 예상과 다른 진행이 발생하는지 디버깅할 수 있다. **ros2 action cancel** * 이미 전송한 Goal을 중간에 취소할 수 있다. * 예시: ```bash ros2 action cancel /fibonacci ``` * 취소를 요청했을 때, 액션 서버가 어떻게 응답하고, 어떤 메시지를 주고받는지 로깅하여 오류 상황을 재현하거나 사용자 입력 취소가 필요한 시나리오를 테스트해볼 수 있다. **ros2 action info** * 특정 액션 서버에 대한 정보를 확인한다. * 예시: ```bash ros2 action info /fibonacci ``` * 액션 서버 이름, 액션 타입, Goal 및 피드백, Result 트랜잭션 등이 제대로 설정되어 있는지 점검할 수 있다. #### ros2 action 명령어 활용 시 주의사항 * 액션을 디버깅할 때는 Goal 전송부터 Result 수령까지의 전 과정을 로깅하는 것이 중요하다. 각 상태 전이(transition)에 대한 타임스탬프를 기록해두면, 지연이나 실패 포인트를 파악하기 쉽다. * 액션은 피드백이 주기적으로 전달되므로, 토픽보다 훨씬 많은 데이터가 오갈 수 있다. 따라서 로깅 시 필요한 정보만 선별 저장하거나 대역폭과 스토리지 용량을 고려해야 한다. * 액션을 구현하는 노드가 여러 개 실행 중이거나, 네트워크 지연이 있는 경우에는 Goal이 중복 전달되거나 충돌하는 상황이 발생할 수 있으니, 테스트 환경과 실제 운영 환경에서의 통신 상태를 별도로 모니터링해야 한다.