Ubuntu ROS 실습(19)

ROS 2에서는 노드 간 데이터를 주고받기 위해 여러 가지 통신 방식을 사용한다.

대표적으로 Topic, Service, Action이 있으며, 각각 통신 방식과 사용 목적에 차이가 있다.

이번에는 앞서 학습한 세 가지 통신 방식을 다시 정리하고, 연속성, 방향성, 동기성, 노드 역할, 인터페이스 등의 관점에서 비교해 보았다.

---

1. Topic

Topic은 노드 간에 연속적으로 데이터를 전달하기 위한 통신 방식이다.

Publisher가 Topic에 데이터를 발행하면 Subscriber가 해당 Topic을 구독하여 데이터를 전달받는다.

Publisher
    │
    │ Message
    ↓
  Topic
    │
    ↓
Subscriber

Topic은 비동기 방식으로 동작하며, 하나의 Publisher와 여러 Subscriber가 연결될 수 있다.

또한 여러 Publisher와 Subscriber가 하나의 Topic을 통해 연결되는 것도 가능하다.

1 : 1
1 : N
N : 1
N : N

따라서 센서 데이터, 로봇 상태, 로봇 좌표, 속도 명령과 같이 지속적으로 전달되는 데이터를 처리하는 데 사용할 수 있다.

Topic의 특징

연속성  → 연속적
방향성  → 단방향
동기성  → 비동기
노드 역할 → Publisher / Subscriber
인터페이스 → msg

Topic에서 사용하는 인터페이스는 msg이며, 파일 확장자는 .msg이다.

---

2. Service

Service는 특정 작업을 요청하고 그에 대한 결과를 받는 요청-응답 방식의 통신이다.

작업을 요청하는 쪽은 Service Client, 요청을 받아 처리하는 쪽은 Service Server 역할을 한다.

Service Client
      │
      │ Request
      ↓
Service Server
      │
      │ Response
      ↓
Service Client

Topic과 달리 Service는 하나의 요청에 대해 하나의 응답을 받는 방식으로 동작한다.

따라서 LED 제어, 모터 토크 On/Off, 계산 요청 등과 같이 특정 작업을 요청하고 결과를 받는 경우에 사용할 수 있다.

Service의 특징

연속성  → 일회성
방향성  → 양방향
동기성  → 동기
노드 역할 → Client / Server
인터페이스 → srv

Service에서 사용하는 인터페이스는 srv이며, Request와 Response를 ---로 구분한다.

Request
---
Response

파일 확장자는 .srv이다.

---

3. Action

Action은 시간이 걸리는 작업을 수행하면서 목표, 진행 상황, 결과를 처리하기 위한 통신 방식이다.

Action에서는 Action Client가 작업의 목표인 Goal을 전달하고, Action Server가 작업을 수행한다.

작업이 진행되는 동안에는 Feedback을 전달하고, 작업이 완료되면 Result를 전달한다.

Action Client
      │
      │ Goal
      ↓
Action Server
      │
      ├──── Feedback ───→ Action Client
      │
      └──── Result ─────→ Action Client

Action은 Topic과 Service의 특성을 함께 사용하는 복합적인 통신 방식이다. 자료에서는 ROS 2의 Action이 Topic과 Service를 혼합하여 구현되며, Action Client는 Service Client 3개와 Topic Subscriber 2개, Action Server는 Service Server 3개와 Topic Publisher 2개로 구성되는 형태로 설명한다.

Action의 구성

Goal
---
Result
---
Feedback

Action 인터페이스의 파일 확장자는 .action이다.

예를 들어 TurtleSim에서 사용하는 RotateAbsolute.action은 다음과 같이 구성된다.

float32 theta
---
float32 delta
---
float32 remaining

여기서 각각 Goal, Result, Feedback에 해당한다.

---

4. Topic + Service = Action

Action의 특징을 이해하기 위해 Topic과 Service가 Action에서 어떻게 사용되는지 살펴볼 수 있다.

ROS 2 Action에서는 목표 전달, 목표 취소, 결과 받기와 같은 동작에 Service를 사용하고, 작업 진행 중 전달되는 Feedback에는 Topic을 사용한다.

Action Client
 ├── Service Client
 │     ├── send_goal
 │     ├── cancel_goal
 │     └── get_result
 │
 └── Topic Subscriber
       └── Feedback

따라서 Action은 단순한 요청-응답만으로 끝나는 것이 아니라, 작업이 수행되는 동안 진행 상태를 확인할 수 있다.

또한 Goal이 전달된 이후의 상태를 관리하기 위해 Goal State Machine을 사용하며, 이를 통해 동기 방식과 비동기 방식이 함께 사용되는 Action의 과정을 관리한다.

---

5. Topic, Service, Action 비교

세 가지 통신 방식은 각각 다른 특성을 가지고 있다.

구분	Topic	Service	Action
연속성	연속적	일회성	복합
방향성	단방향	양방향	양방향
동기성	비동기	동기	동기 + 비동기
연결 형태	1:1, 1:N, N:1, N:N	1:1	1:1
노드 역할	Publisher / Subscriber	Server / Client	Server / Client
동작 트리거	Publisher	Client	Client
인터페이스	msg	srv	action
주요 용도	지속적인 데이터 전달	요청 및 응답	시간이 걸리는 작업

자료에서도 이러한 연속성, 방향성, 동기성, 다자간 연결, 노드 역할, 동작 트리거, 인터페이스를 세 가지 통신 방식의 주요 차이점으로 제시하고 있다.

---

6. 인터페이스 비교

Topic, Service, Action은 각각 서로 다른 인터페이스를 사용한다.

Topic
→ msg
→ *.msg

Service
→ srv
→ *.srv

Action
→ action
→ *.action

각 인터페이스는 --- 구분자의 개수에 따라 데이터 구조가 달라진다.

Topic

Data

Service

Request
---
Response

Action

Goal
---
Result
---
Feedback

즉, msg 인터페이스를 기본으로 생각하면 Service는 Request와 Response를 구분하고, Action은 Goal, Result, Feedback을 구분하는 형태로 확장된 구조라고 볼 수 있다.

---

7. 어떤 통신 방식을 사용할까?

세 가지 방식은 서로 대체하는 개념이라기보다 작업의 특성에 따라 선택해서 사용하는 통신 방식이라고 볼 수 있다.

계속 데이터를 전달해야 한다
        ↓
      Topic

특정 작업을 요청하고 결과를 받는다
        ↓
     Service

시간이 걸리는 작업을 수행하면서
진행 상황과 최종 결과가 필요하다
        ↓
      Action

예를 들어 센서 데이터나 로봇 상태처럼 지속적으로 발생하는 데이터는 Topic을 사용할 수 있다.

반면 LED 제어처럼 특정 작업을 요청하고 처리 결과를 받는 경우에는 Service를 사용할 수 있다.

목적지까지 이동하거나 물건을 파지하는 것처럼 작업 시간이 길고 진행 상황을 확인해야 하는 경우에는 Action을 사용할 수 있다.

---

마무리

ROS 2의 Topic, Service, Action은 모두 노드 사이에서 데이터를 전달하기 위한 통신 방식이지만 각각의 목적과 구조가 다르다.

Topic
→ 연속적인 데이터 전달
→ Publisher / Subscriber
→ 비동기
→ msg

Service
→ 요청과 응답
→ Client / Server
→ 동기
→ srv

Action
→ Goal + Feedback + Result
→ Client / Server
→ 동기 + 비동기
→ action

특히 Action은 Topic과 Service의 특성을 함께 사용하여 시간이 걸리는 작업의 목표를 전달하고, 진행 상황을 확인하며, 최종 결과까지 받을 수 있도록 구성된 통신 방식이라는 점이 핵심이다.

따라서 ROS 2에서 노드 간 통신을 설계할 때는 전달하려는 데이터의 특성과 작업의 진행 방식에 따라 Topic, Service, Action 중 적절한 방식을 선택할 수 있다.