Part 132. 행동 제어의 기초: ROS2 액션 (Foundations of Behavior Control: ROS2 Actions)

1. 개관

로봇 시스템에서 행동 제어(behavior control)는 단일 명령의 즉각적 실행을 넘어, 시간적으로 확장된 작업(temporally extended task)의 요청, 모니터링, 완료 확인, 그리고 필요 시 취소에 이르는 일련의 과정을 체계적으로 관리하는 것을 의미한다. ROS2(Robot Operating System 2)에서 제공하는 액션(Action) 통신 패러다임은 이러한 장시간 실행 작업(long-running task)의 비동기적 관리를 위한 핵심 인터페이스이다. 본 Part에서는 ROS2 액션의 이론적 기반, 프로토콜 구조, 내부 구현 메커니즘, 그리고 행동 제어에서의 역할을 상세히 다룬다.

2. ROS2 통신 패러다임의 계층 구조

2.1 토픽, 서비스, 액션의 비교

ROS2는 세 가지 기본 통신 패러다임을 제공하며, 각각은 상이한 상호작용 패턴에 적합하다.

**토픽(Topic)**은 발행-구독(publish-subscribe) 모델에 기반한 단방향 비동기 통신이다. 다대다(many-to-many) 관계를 지원하며, 센서 데이터 스트리밍과 같은 연속적 데이터 전송에 적합하다. 그러나 요청-응답 구조가 부재하므로, 특정 작업의 완료 여부를 확인하는 데에는 부적절하다.

**서비스(Service)**는 요청-응답(request-response) 모델에 기반한 동기적 통신이다. 클라이언트가 서버에 요청을 전송하면 서버가 응답을 반환하는 일대일(one-to-one) 상호작용을 수행한다. 짧은 시간 내에 완료되는 계산이나 파라미터 조회에 적합하나, 장시간 소요되는 작업에 사용할 경우 클라이언트가 응답 대기 중 차단(blocking)되는 문제가 발생한다.

**액션(Action)**은 토픽과 서비스의 조합으로 구성된 복합 통신 패러다임이다. 목표(goal) 전송, 진행 상황에 대한 피드백(feedback) 수신, 최종 결과(result) 획득, 그리고 실행 중 취소(cancel)를 지원한다. 이로써 장시간 실행 작업의 비동기적 관리가 가능해진다.

2.2 통신 패러다임 선택 기준

통신 패러다임의 선택은 작업의 시간적 특성과 상호작용 요구사항에 의해 결정된다. 일반적으로 실행 시간이 수백 밀리초 이하인 작업에는 서비스를, 연속적 데이터 흐름에는 토픽을, 그리고 실행 시간이 불확정적이거나 수 초 이상 소요되는 작업에는 액션을 적용한다.

3. ROS2 액션의 구조

3.1 액션 정의 파일

ROS2 액션은 .action 확장자를 가진 인터페이스 정의 파일을 통해 목표, 결과, 피드백의 데이터 구조를 명세한다. 파일은 세 개의 구획(section)으로 구성되며, 각 구획은 --- 구분자로 분리된다.

# Goal (목표 정의)
<goal_field_type> <goal_field_name>
---
# Result (결과 정의)
<result_field_type> <result_field_name>
---
# Feedback (피드백 정의)
<feedback_field_type> <feedback_field_name>

예를 들어, 네비게이션 행동의 액션 정의는 다음과 같이 구성된다:

# Goal
geometry_msgs/PoseStamped pose
---
# Result
int16 error_code
float32 total_time
---
# Feedback
geometry_msgs/PoseStamped current_pose
float32 distance_remaining

3.2 내부 프로토콜 구조

ROS2 액션은 내부적으로 세 개의 서비스와 두 개의 토픽으로 구현된다:

이러한 분해 구조를 통해 액션은 DDS(Data Distribution Service) 미들웨어 위에서 표준 토픽과 서비스 메커니즘만으로 구현되며, 별도의 전용 전송 프로토콜을 요구하지 않는다.

4. 액션 상태 기계

4.1 목표 상태 전이

ROS2 액션의 목표는 내부적으로 유한 상태 기계에 의해 관리되며, 다음의 상태를 가진다:

S = \{UNKNOWN, ACCEPTED, EXECUTING, CANCELING, SUCCEEDED, CANCELED, ABORTED\}

상태 전이는 다음의 규칙을 따른다:

1. UNKNOWN → ACCEPTED: 서버가 목표를 수락한다.
2. ACCEPTED → EXECUTING: 서버가 목표 실행을 개시한다.
3. EXECUTING → SUCCEEDED: 목표가 성공적으로 완료된다.
4. EXECUTING → ABORTED: 목표 실행 중 오류가 발생하여 중단된다.
5. EXECUTING → CANCELING: 취소 요청이 수락되어 취소 처리 중이다.
6. CANCELING → CANCELED: 취소가 완료된다.
7. CANCELING → SUCCEEDED: 취소 처리 중에 목표가 완료된다.
8. CANCELING → ABORTED: 취소 처리 중에 오류가 발생한다.
9. ACCEPTED → CANCELING: 수락된 목표에 대해 취소가 요청된다.

이 상태 기계는 REP-2004(ROS Enhancement Proposal 2004)에 의해 공식 명세되어 있다.

5. 액션 서버 구현

5.1 서버 콜백 구조

ROS2 액션 서버는 다음의 콜백 함수를 등록하여 동작한다:

• 목표 콜백(goal callback): 수신된 목표의 수락 또는 거부를 결정한다.
• 취소 콜백(cancel callback): 취소 요청의 수락 또는 거부를 결정한다.
• 실행 콜백(execute callback): 수락된 목표에 대한 실제 행동을 수행하며, 실행 중 피드백을 발행하고 최종 결과를 반환한다.

실행 콜백은 별도의 스레드에서 비동기적으로 실행될 수 있으며, 이를 통해 서버는 동시에 복수의 목표를 관리할 수 있다. 다만 기본 설정에서는 새로운 목표가 수락되면 기존 목표가 자동으로 취소되는 단일 목표 정책(single-goal policy)이 적용된다.

5.2 피드백 발행 메커니즘

실행 콜백 내에서 publish_feedback() 메서드를 호출하면 피드백 토픽을 통해 진행 상황이 발행된다. 피드백 발행 주기는 작업의 특성에 따라 결정되며, 과도한 발행 빈도는 DDS 미들웨어의 대역폭을 소모할 수 있으므로 적절한 조절이 필요하다.

6. 액션 클라이언트 구현

6.1 비동기 통신 패턴

ROS2 액션 클라이언트는 비동기적 통신 패턴을 따른다. 목표 전송 후 즉시 퓨처(Future) 객체가 반환되며, 콜백 함수를 등록하여 목표 수락, 피드백 수신, 결과 획득 이벤트에 응답한다.

send_goal_async(goal) → GoalHandle Future
                          ├── goal_response_callback(goal_handle)
                          ├── feedback_callback(feedback_msg)
                          └── get_result_async() → Result Future
                                └── result_callback(result)

6.2 목표 관리

클라이언트는 GoalHandle 객체를 통해 전송된 목표의 상태를 추적하고, cancel_goal_async() 메서드를 통해 실행 중인 목표의 취소를 요청할 수 있다. 복수의 목표를 동시에 관리하는 경우, 각 목표의 GoalHandle을 별도로 저장하고 관리하여야 한다.

7. 행동 제어에서의 액션 활용

7.1 행동의 추상화

로봇 행동 제어에서 하나의 “행동(behavior)“은 특정 목표 달성을 위한 시간적으로 확장된 작업 단위로 정의된다. ROS2 액션은 이러한 행동의 자연스러운 추상화를 제공한다. 목표가 행동의 의도(intent)를, 피드백이 행동의 진행 상태를, 결과가 행동의 성과를 각각 캡슐화한다.

7.2 Nav2에서의 액션 활용 사례

Nav2(Navigation 2) 스택은 ROS2 액션을 행동 제어의 기본 단위로 활용하는 대표적 사례이다. 주요 액션 서버는 다음과 같다:

이들 액션 서버는 행동 트리(Behavior Tree)의 리프 노드에서 호출되며, 행동 트리의 상위 구조가 이들의 조합과 전환을 관리한다.

8. QoS 설정과 신뢰성

8.1 액션에 대한 QoS 정책

ROS2 액션의 내부 토픽과 서비스에는 서비스 품질(Quality of Service, QoS) 정책이 적용된다. 기본적으로 서비스 구성 요소에는 신뢰성(reliable) 정책이, 피드백 토픽에는 신뢰성 정책과 변동적 내구성(volatile durability)이 적용된다. 상태 토픽에는 과도적 로컬 내구성(transient local durability)이 적용되어, 후기 합류(late-joining) 클라이언트가 최신 상태 정보를 획득할 수 있도록 한다.

네트워크 환경의 특성에 따라 QoS 정책을 조정하여야 하며, 특히 무선 통신 환경에서는 피드백 토픽의 신뢰성 정책을 최선 노력(best-effort)으로 변경하여 지연 시간을 최소화하는 방안을 고려할 수 있다.

9. 동시성과 다중 목표 관리

9.1 단일 목표 정책과 다중 목표 정책

행동 서버의 목표 관리 정책은 응용의 요구사항에 따라 결정된다. 단일 목표 정책(single-goal policy)에서는 새로운 목표가 수락되면 기존에 실행 중인 목표가 자동으로 취소된다. 다중 목표 정책(multi-goal policy)에서는 복수의 목표가 동시에 실행될 수 있으며, 각 목표의 실행은 독립적인 스레드 또는 코루틴(coroutine)에 의해 관리된다.

9.2 콜백 그룹과 실행기

ROS2의 콜백 그룹(callback group)과 실행기(executor)는 액션 서버의 동시성 모델을 결정한다. 상호 배타적 콜백 그룹(mutually exclusive callback group)은 콜백의 순차적 실행을 보장하며, 재진입 콜백 그룹(reentrant callback group)은 복수의 콜백이 동시에 실행되는 것을 허용한다. 다중 목표 관리를 위해서는 재진입 콜백 그룹과 다중 스레드 실행기(multi-threaded executor)의 조합이 필요하다.

10. 오류 처리와 견고성

10.1 타임아웃과 재시도

행동 제어 시스템에서의 견고성(robustness)을 확보하기 위해, 액션 클라이언트는 목표 전송 및 결과 획득에 대한 타임아웃(timeout)을 설정하여야 한다. 서버 응답이 제한 시간 내에 수신되지 않는 경우, 재시도(retry) 정책 또는 대안 행동으로의 전환이 이루어져야 한다.

10.2 선제적 취소와 안전 정지

비상 상황이나 상위 계획의 변경으로 인해 현재 행동의 즉각적 중단이 필요한 경우, 액션의 취소 메커니즘이 활용된다. 서버 측에서는 취소 요청 수신 시 진행 중인 작업을 안전하게 정지(safe stop)하고 자원을 해제하는 정리(cleanup) 절차를 구현하여야 한다.

참고 문헌

• Open Robotics. (2024). ROS 2 Documentation: Humble Hawksbill. https://docs.ros.org/en/humble/
• REP-2004: Action Design. https://www.ros.org/reps/rep-2004.html
• Macenski, S., Martín, F., White, R., & Clavero, J. G. (2020). “The Marathon 2: A Navigation System.” arXiv preprint arXiv:2003.00368.
• Maruyama, Y., Kato, S., & Azumi, T. (2016). “Exploring the Performance of ROS2.” Proceedings of the 13th International Conference on Embedded Software (EMSOFT).