이번에는 ROS 2에서 사용하는 Action(액션) 개념을 정리했다.
앞서 Topic은 지속적으로 데이터를 주고받고, Service는 요청과 응답을 주고받는 방식이었다면, Action은 시간이 걸리는 작업을 수행하면서 목표(Goal), 피드백(Feedback), 결과(Result)를 주고받을 수 있는 통신 방식이다.
1. ROS 2 Action이란?
ROS 2의 Action은 특정 작업을 수행하기 위한 목표를 전달하고, 작업이 진행되는 동안 피드백을 받으며, 작업이 완료되면 결과를 받는 방식이다.
Action은 크게 다음 세 가지 데이터로 구성된다.
- Goal: 수행하고자 하는 작업의 목표
- Feedback: 작업이 진행되는 동안 전달되는 현재 상태
- Result: 작업이 완료된 후 전달되는 최종 결과
전체적인 흐름은 다음과 같이 볼 수 있다.
Action Client
│
│ Goal
↓
Action Server
│
├──── Feedback ────→ Action Client
│
└──── Result ──────→ Action Client즉, 단순히 한 번 요청하고 끝나는 것이 아니라 작업의 진행 상황을 확인하면서 최종 결과까지 받을 수 있다는 점이 Action의 특징이다.
2. Action은 Topic과 Service의 혼합
ROS 2 Action의 구현 방식은 Topic과 Service를 혼합한 형태로 볼 수 있다.
자료에서는 Action Client가 3개의 Service Client와 2개의 Topic Subscriber로 구성되고, Action Server는 3개의 Service Server와 2개의 Topic Publisher로 구성된다고 설명한다.
정리하면 다음과 같다.
Action Client
├─ Service Client × 3
└─ Topic Subscriber × 2
Action Server
├─ Service Server × 3
└─ Topic Publisher × 2이를 통해 Action에서는 목표 전달, 목표 취소, 결과 전달과 같은 작업과 피드백 전달을 함께 처리할 수 있다.
3. 왜 Topic과 Service를 함께 사용할까?
ROS 2의 Action에서는 작업을 수행하는 과정에서 여러 종류의 통신이 필요하다.
자료에서는 Action에서 다음과 같은 동작을 위해 Service를 사용한다고 설명한다.
- send_goal: 목표 전달
- cancel_goal: 목표 취소
- get_result: 결과 받기
반면 작업이 진행되는 동안 전달되는 Feedback은 Topic을 통해 처리한다.
따라서 Action은 다음과 같은 형태로 이해할 수 있다.
Goal
Client ─────────────→ Server
Service
Feedback
Client ←───────────── Server
Topic
Result
Client ←───────────── Server
Service이처럼 Action은 동기식 처리가 필요한 부분과 비동기식으로 진행 상황을 전달하는 부분을 함께 사용하는 구조를 가진다.
4. Goal State Machine
Action에서는 작업의 진행 상태를 관리하기 위해 Goal State Machine을 사용한다.
목표를 전달한 이후에는 해당 목표가 어떤 상태인지 추적하면서 Action의 전체 과정을 관리한다.
즉,
Goal 전달
↓
Goal 상태 확인
↓
Action 수행
↓
Feedback 전달
↓
Action 완료
↓
Result 전달과 같이 목표가 전달된 이후의 과정을 상태 머신을 통해 관리한다.
자료에서는 이러한 Goal State Machine을 통해 비동기 방식과 동기 방식이 혼재된 Action의 처리를 원활하게 할 수 있다고 설명한다.
5. Action 인터페이스
Action 역시 Topic의 msg, Service의 srv와 마찬가지로 별도의 인터페이스를 사용한다.
이를 Action Interface라고 하며 파일 확장자는 .action이다.
Action 인터페이스는 다음과 같이 구성된다.
Goal
---
Result
---
Feedback---를 기준으로 각각 Goal, Result, Feedback이 구분된다.
예를 들어 Turtlesim에서 사용하는 RotateAbsolute.action은 다음과 같이 구성되어 있다.
float32 theta
---
float32 delta
---
float32 remaining각 항목의 의미는 다음과 같다.
Goal
└─ theta : 목표 회전 각도
Result
└─ delta : 실제 회전한 각도
Feedback
└─ remaining : 남은 회전 각도자료에서는 세 값 모두 각도의 SI 단위인 라디안(radian) 사용한다고 설명한다.
6. Topic, Service, Action 비교
앞에서 학습한 통신 방식과 비교하면 다음과 같이 정리할 수 있다.
| 구분 | Topic | Service | Action |
|---|---|---|---|
| 통신 방식 | 지속적인 메시지 전달 | 요청 → 응답 | 목표 → 피드백 → 결과 |
| 주요 구성 | Publisher / Subscriber | Client / Server | Action Client / Action Server |
| 인터페이스 | msg | srv | action |
| 특징 | 지속적인 데이터 전달 | 즉각적인 요청과 응답 | 시간이 걸리는 작업의 진행 과정 관리 |
특히 Action은 단순히 결과만 받는 것이 아니라 작업 중간의 Feedback을 받을 수 있다는 점에서 Service와 차이가 있다.
마무리
이번에는 ROS 2의 Action 통신 방식을 정리했다.
Action은 특정 작업의 Goal을 전달하고, 작업이 진행되는 동안 Feedback을 받으며, 작업이 완료되면 Result를 받는 구조로 동작한다.
또한 Action은 Topic과 Service를 혼합하여 구현되며, Goal 전달과 취소, Result 처리에는 Service를 사용하고 Feedback 전달에는 Topic을 사용하는 구조로 설명할 수 있다.
마지막으로 Action Interface는 다음과 같이 Goal, Result, Feedback으로 구성된다.
Goal
---
Result
---
Feedback따라서 ROS 2의 통신 방식을 간단히 정리하면,
Topic → 지속적인 데이터 전달
Service → 요청과 응답
Action → 목표 + 진행 상황 + 최종 결과와 같이 구분할 수 있다.
