1317.28 액션 클라이언트와 액션 수행기의 관계

1317.28 액션 클라이언트와 액션 수행기의 관계

1. 개요

PlanSys2의 액션 실행 체���에서 액션 클라이언트(action client)와 액션 수행기(action performer/executor)는 ROS2 액션 프로토콜을 통해 연결되는 상호 보완적 구성 요소이다. 액션 클라이언트는 실행기 노드(Executor Node) 내부에 위치하며, 계획에 포함된 각 PDDL 액션을 해당 액션 수행기에 전달하는 역할을 담당한다. 액션 수행기는 독��적인 ROS2 노드로서, 전달받은 PDDL 액션을 실제 로봇 행동으로 변환하고 실행한다. 이 두 구성 요소 사이의 관계를 정확히 이해하는 것은 PlanSys2 기반 로봇 시스템의 설계와 구현에 필수적이다(Martín et al., 2021).

2. 액션 클라이언트의 구조

2.1 행동 트리 액션 노드로서의 클라이언트

PlanSys2에서 액션 클라이언트는 행동 트리(behavior tree)의 리프 노드(leaf node)로 구현된다. 실행기 노드가 계획으로부터 행동 트리��� 동적으로 생성할 때, 각 PDDL 액션에 대응하는 행동 ���리 액션 노드가 생성되고, 이 노드가 ROS2 액션 클라이���트의 역할을 수행한다.

행동 트리 액션 노드는 다음과 같은 정보를 보유한다.

속성설명
액션 이름PDDL 액션의 이름(예: move, pick, place)
인자 목록PDDL 액션의 구체적 인자(예: robot1, kitchen, bedroom)
액션 서버 이름연결 대상 ROS2 액션 서버의 이름

2.2 액션 서버 탐색과 연결

행동 트리의 틱이 특정 액션 노드에 도달하면, 해당 노드는 PDDL 액션 이름과 동일한 이름을 가진 ROS2 액션 서버를 탐색한다. PlanSys2는 /actions/<action_name> 형식의 ROS2 액션 이름 규약을 ��용한다. 액션 클라이���트는 해당 액션 서버��� 활성 상태인지 확인하고, 서버가 발견되면 목표(goal)를 전송하여 액션 실행을 요청한다.

서버가 발견되지 않거나 지정된 시간 내에 연결이 이루어지지 않으면, 액션 노드는 FAILURE 상태를 반환하여 실행기 노드에 오류를 보고한다.

3. 액션 수행기의 구조

3.1 ActionExecutorClient 기반 클래스

PlanSys2는 액션 수행기를 구현하기 위한 기반 클래스로 ActionExecutorClient를 제공한다. 이 클래스는 ROS2의 라이프사이클 노드(lifecycle node)를 상속하며, ROS2 액션 서버를 내부적으로 관리한다. 개발자는 이 기반 클래스를 상속하여 do_work() 콜백을 오버라이드함으로써 구체적인 로봇 행동을 구현한다.

class MoveAction : public plansys2::ActionExecutorClient
{
public:
  MoveAction() : ActionExecutorClient("move", 500ms) {}

private:
  void do_work() override
  {
    // 로봇 이동 로직 구현
    // get_arguments()로 PDDL 인자 접근
    // finish(true, 1.0, "Move completed")로 완료 보고
  }
};

ActionExecutorClient의 생성자에는 두 가지 핵심 인자가 전달된다.

  • 액션 이름: 이 수행기가 처리하는 PDDL 액션의 이름. 이 이름은 ROS2 액션 서버의 이름으로 ��용되어 액션 클라이언트와의 매칭에 활용된다.
  • 틱 주기: do_work() 콜백이 호출되는 주기. 이 주기는 액션의 특성에 따라 조절할 수 있다.

3.2 액션 수행기의 라이프사이클

액션 수행기는 ROS2 관리형 노드(managed node)로 구현되므로, 다음과 같은 라이프사이클 상태를 가진다.

  1. Unconfigured: 노드가 생성되었으나 초기화되지 않은 상태
  2. Inactive: 초기화가 완료되었으나 활성화되지 않은 상태
  3. Active: 액션 서버가 활성화되어 실행 요청을 수신할 준비가 된 상태
  4. Finalized: 노드가 종료된 ���태

액션 수행기는 Active 상태에서만 액션 클라이언���의 실행 요청을 처리할 수 있다. PlanSys2의 런치 시스템은 액션 수행기 노드의 라이프사이클 전이를 관리하여, 시스템 시작 ��� 모든 수행��가 Active 상태로 전이되도록 한다.

4. 클라이언트와 수행기 간의 통신 프로토콜

4.1 목표 전송 단계

액션 클라이언트가 수행기에 실행을 요청할 때, 다음과 같은 정보를 포함한 목표(goal)가 전송된다.

  • 액션 식별자: PDDL 액션의 전체 문자열(예: (move robot1 kitchen bedroom))
  • 인자 목록: 액션의 구체적 인자를 분리하여 전달

수행기의 액션 서버는 목표를 수신하면 이를 수락(accept)하거나 거부(reject)할 수 있다. 수락된 경우 즉시 실행이 시작되며, 거부된 경우 클라이언트에 거부 사유가 반환된다.

4.2 피드백 전송 단계

액션 실행 중 수행기는 주기적으로 피드백(feedback)을 ���라이언트에 전송한다. PlanSys2의 액션 피드백에는 다음과 같은 정보가 포함된다.

필드타입설명
progressfloat액션 진행률(0.0 ~ 1.0)
statusstring현재 상태 설명 메시���

수행기의 do_work() 콜백 내에�� send_feedback() 메서드를 호출��여 진행 상태를 보고한다. 이 피드백은 실행기 노드를 거쳐 상위 수준의 임무 관리자에게 전달되어, 전체 계획의 진행 상태 모니터링에 활용된다.

4.3 결과 반환 단계

액션이 완료되면 수행기는 finish() 메서드를 호출하여 최종 결과를 반환한다.

// 성공 완료
finish(true, 1.0, "Action completed successfully");

// 실패 완료
finish(false, 0.0, "Navigation failed: obstacle detected");

finish() 메서드의 인자는 다음과 같다.

  • 성공 여부(success): 불리언 값으로 액션의 성공 또는 실패를 나타낸다.
  • 완료율(completion): 부동 소수점 값으로 최종 진행률을 나타낸다.
  • 상태 메시지(message): 완료 상태를 기술하는 문자열이다.

클라이언트는 이 결과를 수��하여 행동 ���리 노드의 상태를 SUCCESS 또는 FAILURE로 갱신한다.

5. 대1 매핑과 다대1 매핑

5.1 기본 1대1 매핑

가장 일반��인 구성에서, 각 PDDL 액션에 대해 하나의 액션 수행기 노드가 대응한다. 예를 들어, PDDL 도메인에 move, pick, place 세 개의 액션이 정의되어 있으면, 각각에 대응하는 세 ��의 액션 수행기 노드가 시스템에 배치된다.

PDDL 액션        →    액션 수행기 노드
move             →    move_action_node
pick             →    pick_action_node
place            →    place_action_node

5.2 동일 액션의 다중 인스���스

시간적 계획(temporal plan)에서 동일한 PDDL 액션이 상이한 인자로 동시에 실행될 수 있다. 예를 들어, (move robot1 A B)와 (move robot2 C D)가 병렬로 스케줄링될 수 있다. 이 경우, PlanSys2는 각 액션 인스턴스를 구분하기 위해 액션 이름과 인자 조합에 기반한 고유 식별자를 사용한다. 단일 액션 수행기 노드가 복수의 동시 요청을 처리하거나, 인자별로 독���적인 수행기 인스턴스가 운용될 수 있다.

6. 액션 취소 처리

계획 실행 중 상위 수준에서 실행 취소가 요청되면, 실행기 노드는 현재 활성 상태인 모든 액션 클라이언트에 취소(cancel) 요청을 전파한��. 각 액션 클라이언트는 연결된 수행기의 액션 서버에 목표 취소를 요청��며, 수��기는 진행 중인 작업을 안전하게 중단한 후 취소 결과를 반환한다.

액션 수���기는 취소 요청 시 다음과 같�� 안전 절차를 수행해야 한다.

  • 로봇의 현��� 동작을 즉시 정지하거나 안전한 상태로 전이한다.
  • 점유 중인 리소스(하드웨어 인터페이스, 네트워크 연결 등)를 해제한다.
  • 취소 결과를 클라이언트에 반환한다.

7. 느슨�� 결합 설계의 의의

PlanSys2에서 액션 클라이언트와 액션 수행기는 ROS2 액션 프로토콜을 통해 느슨하게 결합(loosely coupled)되어 있다. 이 설계는 다음과 같은 아키텍처적 이점을 제공한다.

  • 독립적 개발: 실행기 노드와 액션 수행기가 독립적으로 개발, 테스트, 배포될 수 있다.
  • 교체 가능성: 특정 액션의 수행기를 다른 구현으로 교체할 때 실행기 노드의 수정이 필요하지 않다.
  • 분산 배치: 액션 수행기가 실행기 노드와 다른 컴퓨터에 배치될 수 있으며, ROS2의 DDS(Data Distribution Service) 통신이 이를 투명하게 지원한다.
  • 재사용성: 동일한 액션 수행기가 PlanSys2 외의 다른 시스템에서도 활용될 수 있다.

이러한 느슨한 결합은 ROS2의 분산 시스템 아키텍처의 근본 원칙에 부합하며, PlanSys2가 다양한 로봇 플랫폼에 적용될 수 있는 유연성을 보장한다(Martín et al., 2021; Macenski et al., 2022).

참고 문헌

  • Martín, F., Cañas, J. M., Ginés, J., & Fuentetaja, R. (2021). “PlanSys2: A Planning System Framework for ROS2.” IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS).
  • Macenski, S., Foote, T., Gerkey, B., Lalancette, C., & Woodall, W. (2022). “Robot Operating System 2: Design, Architecture, and Uses in the Wild.” Science Robotics, 7(66), eabm6074.
  • Colledanchise, M., & Ögren, P. (2018). Behavior Trees in Robotics and AI: An Introduction. CRC Press.

버전: v1.0