1261.34 ROS2 액션(Action) 통신의 개요

1. 액션 통신의 정의

ROS2에서 액션(Action)은 장시간 수행되는 목표 지향적 작업을 관리하기 위한 통신 패러다임이다. 액션 통신은 목표(Goal)의 전달, 진행 상황(Feedback)의 주기적 보고, 최종 결과(Result)의 반환, 그리고 작업 취소(Cancel)를 하나의 통합된 프로토콜로 제공한다.

액션은 토픽(Topic)의 비동기 데이터 스트리밍 능력과 서비스(Service)의 요청-응답 상호작용을 결합한 복합 통신 메커니즘으로, ROS2의 세 번째 핵심 통신 패러다임에 해당한다. 로봇의 내비게이션, 매니퓰레이션 궤적 실행, 자율 순찰 등 수초에서 수분에 걸쳐 수행되는 복합 행동의 관리에 필수적인 통신 구조이다.

2. 액션 통신의 구성 요소

2.1 액션 인터페이스(.action 파일)

액션의 인터페이스는 .action 파일을 통해 정의되며, 세 개의 섹션으로 구분된다.

# Goal (목표)
int32 target_position
---
# Result (결과)
int32 final_position
int32 error_code
---
# Feedback (피드백)
int32 current_position
float32 progress_percentage
  • Goal(목표): 클라이언트가 서버에 전달하는 작업 요청 데이터이다. 목표 위치, 목표 속도, 목표 자세 등 작업의 목적을 정의하는 필드를 포함한다.
  • Result(결과): 작업이 완료된 후 서버가 클라이언트에 반환하는 최종 결과 데이터이다. 최종 상태, 오류 코드, 수행 통계 등을 포함한다.
  • Feedback(피드백): 작업 수행 중 서버가 클라이언트에 주기적으로 전달하는 중간 진행 상황 데이터이다. 현재 위치, 진행률, 경과 시간 등을 포함한다.

2.2 액션 서버(Action Server)

액션 서버는 클라이언트로부터 목표를 수신하고, 해당 목표를 향한 작업을 수행하며, 수행 중 피드백을 발행하고, 작업 완료 시 결과를 반환하는 개체이다. 액션 서버는 목표의 수락·거부 판단, 작업 취소 요청의 처리, 다중 목표의 관리 등 작업 생명주기 전반을 책임진다.

2.3 액션 클라이언트(Action Client)

액션 클라이언트는 목표를 전달하고, 피드백을 수신하며, 최종 결과를 획득하고, 필요 시 작업 취소를 요청하는 개체이다. 액션 클라이언트는 비동기적으로 동작하며, 목표 전달 후에도 다른 작업을 계속 수행할 수 있다.

3. 액션 통신의 내부 구현 구조

ROS2의 액션 통신은 토픽과 서비스의 조합으로 내부적으로 구현된다. 하나의 액션은 다음의 세 가지 서비스와 두 가지 토픽으로 분해된다.

내부 통신 채널유형역할
<액션_이름>/_action/send_goal서비스목표 전달 및 수락·거부 응답
<액션_이름>/_action/cancel_goal서비스작업 취소 요청 및 응답
<액션_이름>/_action/get_result서비스최종 결과 요청 및 반환
<액션_이름>/_action/feedback토픽진행 상황 피드백의 주기적 발행
<액션_이름>/_action/status토픽목표의 상태 변경 통지

이 내부 구조는 ROS2 프레임워크에 의해 자동으로 생성되며, 사용자는 액션 서버와 액션 클라이언트의 API만을 사용하여 상위 수준의 통신을 수행한다.

4. 액션 목표의 생명주기

액션 통신에서 각 목표는 정의된 상태 머신에 따라 생명주기(Lifecycle)를 가진다. 주요 상태 전이는 다음과 같다.

  1. UNKNOWN: 초기 상태. 목표가 아직 서버에 전달되지 않았다.
  2. ACCEPTED: 서버가 목표를 수락하였으나 아직 실행을 시작하지 않았다.
  3. EXECUTING: 서버가 목표를 향한 작업을 수행 중이다.
  4. CANCELING: 취소 요청이 수신되었으며 취소 처리가 진행 중이다.
  5. SUCCEEDED: 작업이 성공적으로 완료되었다.
  6. CANCELED: 작업이 취소되었다.
  7. ABORTED: 작업이 서버 측의 오류로 중단되었다.

이 상태 머신은 액션 통신의 핵심 추상화이며, 클라이언트는 상태 토픽을 통해 목표의 현재 상태를 실시간으로 추적할 수 있다.

5. 액션 통신의 동작 흐름

액션 통신의 일반적인 동작 흐름은 다음과 같은 단계를 거친다.

  1. 목표 전달(Goal Submission): 클라이언트가 send_goal 서비스를 통해 목표를 서버에 전달한다.
  2. 목표 수락·거부(Goal Accept/Reject): 서버가 목표를 수락하면 목표 핸들(Goal Handle)을 반환하고, 거부하면 해당 응답을 반환한다.
  3. 작업 실행(Execution): 서버가 목표를 향한 작업을 수행하며, 피드백 토픽을 통해 진행 상황을 주기적으로 발행한다.
  4. 피드백 수신(Feedback Reception): 클라이언트가 피드백 토픽을 구독하여 중간 진행 상황을 수신한다.
  5. 작업 완료(Completion): 작업이 완료되면 서버가 결과를 설정하고, 클라이언트가 get_result 서비스를 통해 최종 결과를 요청·수신한다.
  6. 작업 취소(Cancellation, 선택적): 클라이언트가 cancel_goal 서비스를 통해 진행 중인 작업의 취소를 요청할 수 있다.

6. 액션 통신의 핵심 특성

6.1 비동기적 장시간 작업 관리

액션 통신은 목표 전달 후 클라이언트가 다른 작업을 계속 수행할 수 있는 비동기적 구조를 제공한다. 서비스 통신과 달리 응답 대기로 인한 호출 스레드 차단이 발생하지 않으며, 피드백을 통해 작업 진행 상황을 능동적으로 모니터링할 수 있다.

6.2 작업 취소와 선점

진행 중인 작업을 외부에서 취소하거나, 새로운 목표로 기존 작업을 선점(Preempt)하는 메커니즘이 프로토콜 수준에서 제공된다. 이는 로봇 시스템에서 상황 변화에 따른 유연한 작업 전환을 지원하는 필수적인 기능이다.

6.3 다중 목표 동시 처리

액션 서버는 복수의 목표를 동시에 수용하고 처리할 수 있다. 각 목표는 독립적인 목표 핸들을 통해 관리되며, 서버의 구현에 따라 병렬 실행, 대기열 기반 순차 실행, 선점 기반 실행 등 다양한 처리 정책을 적용할 수 있다.

7. 대표적 적용 사례

  • 자율 내비게이션: Nav2의 NavigateToPose 액션을 통해 목표 위치로의 이동을 관리하며, 현재 위치와 남은 거리를 피드백으로 보고한다.
  • 로봇 팔 궤적 실행: MoveIt2의 ExecuteTrajectory 액션을 통해 관절 궤적의 실행을 제어하며, 현재 관절 위치를 피드백으로 전달한다.
  • 도킹(Docking): 충전 스테이션으로의 접근 및 도킹 과정을 액션으로 관리하며, 정렬 상태와 접근 거리를 피드백으로 보고한다.

8. 참고 문헌

  • Open Robotics, “ROS 2 Documentation: Humble Hawksbill,” https://docs.ros.org/en/humble/, 2022.
  • Open Robotics, “ROS 2 Design: Actions,” https://design.ros2.org/articles/actions.html, 2018.
  • Open Robotics, “Navigation 2 Documentation,” https://navigation.ros.org/, 2022.
  • Maruyama, Y., Kato, S., Azumi, T., “Exploring the Performance of ROS2,” Proceedings of the 13th International Conference on Embedded Software (EMSOFT), 2016.