396.51 ROS2 액션(Action) 서버를 통한 비동기 임무 실행

1. ROS2 통신 패러다임과 임무 실행

ROS2(Robot Operating System 2)는 로봇 소프트웨어 개발을 위한 미들웨어 프레임워크로서, 토픽(Topic), 서비스(Service), **액션(Action)**의 세 가지 핵심 통신 패러다임을 제공한다. 이 중 액션(Action) 인터페이스는 장시간 실행(long-running) 과업의 비동기적 관리를 위해 설계된 통신 메커니즘으로, 임무 관리 시스템에서 개별 과업의 실행, 모니터링, 제어에 핵심적 역할을 수행한다.

1.1 통신 패러다임의 비교

토픽은 빈번한 데이터 스트리밍에, 서비스는 즉시 완료되는 단발성 요청에 적합하다. 반면, 액션은 수 초에서 수 분 이상 소요될 수 있는 과업에 대해 목표 전송(goal sending), 진행 상태 피드백(feedback), 결과 수신(result receiving), 취소(cancellation) 기능을 통합적으로 제공한다.

2. ROS2 액션 인터페이스의 구조

2.1 액션 정의(Action Definition)

ROS2 액션은 .action 파일을 통해 정의되며, 세 가지 구성요소로 이루어진다:

# 목표(Goal) 정의
<goal_fields>
---
# 결과(Result) 정의
<result_fields>
---
# 피드백(Feedback) 정의
<feedback_fields>

각 구성 요소의 역할은 다음과 같다:

• 목표(Goal): 클라이언트가 서버에 전송하는 과업 명세. 목적지 좌표, 원하는 행동 유형, 제약 조건 등을 포함한다.
• 결과(Result): 과업 완료 시 서버가 클라이언트에 반환하는 최종 성과. 성공 여부, 수행 시간, 최종 상태 등을 포함한다.
• 피드백(Feedback): 과업 실행 중 주기적으로 발행되는 진행 상태 정보. 남은 거리, 완료 비율, 현재 하위 과업 등을 포함한다.

2.2 형식적 모델

액션 인터페이스를 형식적으로 표현하면, 액션 \mathcal{A}는 다음과 같은 3-튜플(3-tuple)로 정의된다:

\mathcal{A} = (\mathcal{G}, \mathcal{R}, \mathcal{F})

여기서 \mathcal{G}는 목표 메시지 타입, \mathcal{R}은 결과 메시지 타입, \mathcal{F}는 피드백 메시지 타입이다.

3. 액션 서버-클라이언트 아키텍처

3.1 아키텍처의 구성 요소

ROS2 액션 시스템은 **액션 서버(Action Server)**와 **액션 클라이언트(Action Client)**의 쌍으로 구성된다:

• 액션 서버: 실제 과업을 수행하는 실행기(executor)로서, 목표를 수신하고, 과업을 실행하며, 피드백을 발행하고, 최종 결과를 반환한다.
• 액션 클라이언트: 임무 관리자 또는 상위 제어기에 위치하며, 목표를 전송하고, 피드백을 수신하며, 필요 시 목표를 취소한다.

3.2 내부 통신 프로토콜

액션 인터페이스는 내부적으로 다수의 토픽과 서비스의 조합으로 구현된다:

이 복합 프로토콜은 ROS2 프레임워크에 의해 자동으로 관리되므로, 개발자는 상위 수준의 액션 API만을 활용하여 임무 실행을 구현할 수 있다.

4. 목표 상태 머신(Goal State Machine)

4.1 목표 생애 주기

ROS2 액션의 각 목표는 다음과 같은 상태 전이를 따른다:

\text{GoalState} \in \{\texttt{UNKNOWN}, \texttt{ACCEPTED}, \texttt{EXECUTING}, \texttt{CANCELING}, \texttt{SUCCEEDED}, \texttt{CANCELED}, \texttt{ABORTED}\}

주요 상태 전이는 다음과 같다:

이 상태 머신은 임무 관리 시스템이 각 과업의 실행 상태를 추적하고, 상태에 따른 적절한 제어 결정을 내릴 수 있게 한다.

4.2 목표 수락 정책(Goal Acceptance Policy)

액션 서버는 수신된 목표에 대해 수락(accept) 또는 거부(reject) 결정을 내리는 **목표 수락 콜백(goal callback)**을 제공한다. 임무 관리의 관점에서, 이 콜백은 다음과 같은 조건을 검사할 수 있다:

1. 자원 가용성: 요청된 과업에 필요한 자원(배터리, 메모리, 통신 대역폭)이 충분한지 검증
2. 선행 조건 충족: 과업 실행을 위한 전제 조건이 만족되었는지 확인
3. 충돌 검사: 현재 실행 중인 다른 목표와의 충돌 여부 판정
4. 우선순위 평가: 새 목표의 우선순위와 기존 목표의 우선순위 비교

5. 비동기 임무 실행의 설계 패턴

5.1 단일 목표 실행 패턴

가장 기본적인 패턴으로, 한 번에 하나의 목표만을 수락하고 실행한다. 새로운 목표가 수신되면 기존 목표를 취소하거나, 새 목표를 거부한다:

\text{Policy}_{\text{single}}(g_{\text{new}}, g_{\text{current}}) = \begin{cases} \texttt{ACCEPT}(g_{\text{new}}), \; \texttt{CANCEL}(g_{\text{current}}) & \text{if } \text{priority}(g_{\text{new}}) > \text{priority}(g_{\text{current}}) \\ \texttt{REJECT}(g_{\text{new}}) & \text{otherwise} \end{cases}

5.2 다중 목표 동시 실행 패턴

다수의 비충돌적(non-conflicting) 목표를 동시에 관리하는 패턴이다. 각 목표는 독립적인 실행 스레드에서 처리되며, 목표 간 상호 배제(mutual exclusion)가 필요한 자원에 대해서만 동기화를 수행한다:

\text{ConcurrentGoals} = \{g_1, g_2, \ldots, g_m\} \quad \text{s.t. } \forall i \neq j, \; \text{Resource}(g_i) \cap \text{Resource}(g_j) = \emptyset

5.3 큐 기반 순차 실행 패턴

수신된 목표를 큐(queue)에 저장하고, 현재 목표가 완료되면 큐에서 다음 목표를 추출하여 실행한다:

\mathcal{Q} = \langle g_1, g_2, \ldots, g_n \rangle, \quad g_{\text{current}} = \text{dequeue}(\mathcal{Q})

이 패턴은 순서 보장이 필요한 임무 시퀀스(예: 다중 웨이포인트 내비게이션)에 적합하다.

6. 피드백 기반 임무 모니터링

6.1 피드백 메커니즘의 역할

액션 서버가 주기적으로 발행하는 피드백은 임무 관리 시스템의 실시간 모니터링에 핵심적 역할을 수행한다. 피드백 f_t는 시간 t에서의 과업 진행 상태를 나타내며, 임무 관리자는 이를 기반으로 다음과 같은 판단을 수행한다:

\text{Decision}(f_t) = \begin{cases} \texttt{CONTINUE} & \text{if } f_t \in \mathcal{F}_{\text{normal}} \\ \texttt{CANCEL} & \text{if } f_t \in \mathcal{F}_{\text{anomaly}} \\ \texttt{REPLAN} & \text{if } f_t \in \mathcal{F}_{\text{deviate}} \end{cases}

여기서 \mathcal{F}_{\text{normal}}은 정상 범위의 피드백 집합, \mathcal{F}_{\text{anomaly}}는 이상 상태 피드백 집합, \mathcal{F}_{\text{deviate}}는 계획 이탈 피드백 집합이다.

6.2 진행률 추정

피드백 데이터를 활용하여 과업의 완료 비율(completion ratio) \eta(t)를 추정할 수 있다:

\eta(t) = \frac{d_{\text{traveled}}(t)}{d_{\text{total}}} \quad \text{(내비게이션 과업의 경우)}

\eta(t) = \frac{N_{\text{completed}}(t)}{N_{\text{total}}} \quad \text{(이산 하위 과업의 경우)}

이 추정치는 임무의 예상 완료 시간(ETA)을 계산하고, 시간 제약 조건 위반 여부를 사전에 예측하는 데 활용된다.

7. 취소와 중단 메커니즘

7.1 목표 취소 프로토콜

액션 클라이언트가 cancel_goal 요청을 전송하면, 액션 서버는 다음과 같은 취소 처리를 수행한다:

1. 취소 요청 수신 및 \texttt{CANCELING} 상태 전이
2. 실행 중인 과업의 안전한 중단(graceful shutdown) 수행
3. 리소스 해제 및 상태 정리
4. 취소 완료 시 \texttt{CANCELED} 상태 전이 및 결과 반환

안전한 중단(graceful shutdown)은 로봇의 현재 물리적 상태를 안정적으로 유지하면서 과업을 종료하는 것을 의미한다. 예를 들어, 내비게이션 과업을 취소할 때 로봇은 즉시 멈추는 것이 아니라 감속 프로파일을 따라 안전하게 정지한다.

7.2 선점(Preemption) 패턴

상위 우선순위 목표가 수신되면, 현재 실행 중인 목표를 취소하고 새 목표를 실행하는 선점 패턴을 구현할 수 있다. 이 패턴의 절차는 다음과 같다:

\text{Preempt}(g_{\text{high}}, g_{\text{current}}) : \texttt{CANCEL}(g_{\text{current}}) \rightarrow \texttt{ACCEPT}(g_{\text{high}}) \rightarrow \texttt{EXECUTE}(g_{\text{high}})

선점 시 현재 목표의 중간 상태를 저장(checkpoint)하면, 고우선순위 목표 완료 후 중단된 목표를 재개(resume)할 수 있다.

8. 행동 트리와의 통합

8.1 BT 리프 노드로서의 액션 클라이언트

행동 트리(Behavior Tree)의 리프 노드에서 ROS2 액션 클라이언트를 구동함으로써, BT의 구조적 유연성과 액션 인터페이스의 비동기 실행 능력을 결합할 수 있다. BT 리프 노드의 상태와 액션 목표 상태의 매핑은 다음과 같다:

BT가 해당 리프 노드를 중단(halt)할 때, 노드는 cancel_goal 요청을 전송하여 액션 서버의 과업을 취소한다. Nav2(Navigation2) 프레임워크가 이 통합 패턴의 대표적 구현 사례이다 (Macenski et al., 2020).

8.2 다계층 액션 체인

복합 임무는 다계층 액션 체인으로 구현할 수 있다. 상위 수준 액션 서버가 자체의 과업을 수행하기 위해 하위 수준 액션 클라이언트를 호출하는 재귀적 구조이다:

\mathcal{A}_{\text{mission}} \xrightarrow{\text{calls}} \mathcal{A}_{\text{navigate}} \xrightarrow{\text{calls}} \mathcal{A}_{\text{controller}}

각 수준의 액션 서버는 하위 액션의 피드백을 집약하여 상위 수준의 피드백으로 변환하고, 취소 요청을 하향 전파한다.

9. 참고 문헌

• Macenski, S., Martín, F., White, R., and Ginés Clavero, J. (2020). “The Marathon 2: A Navigation System.” Proceedings of the IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 2718–2725.
• Open Robotics. (2024). ROS 2 Documentation: Actions. https://docs.ros.org/
• Maruyama, Y., Kato, S., and Azumi, T. (2016). “Exploring the Performance of ROS2.” Proceedings of the International Conference on Embedded Software (EMSOFT), 1–10.
• Thomas, D. and Woodall, W. (2019). “ROS 2 Design: Actions.” ROS 2 Design Documentation.

본 절은 로봇공학 서적 Volume 9, Part 53, Chapter 396의 일부로 작성되었다. v1.0