1261.35 액션 통신의 설계 동기와 필요성

1261.35 액션 통신의 설계 동기와 필요성

1. 기존 통신 패러다임의 한계에서 비롯된 설계 동기

ROS2의 액션(Action) 통신 패러다임은 기존의 토픽 통신과 서비스 통신이 로봇 행동 제어의 핵심 요구사항을 충족시키지 못하는 문제에 대한 체계적 해결책으로 설계되었다. 로봇 시스템에서 빈번하게 수행되는 장시간 목표 지향적 작업은 단순한 데이터 스트리밍이나 일회성 요청-응답으로는 적절히 관리할 수 없으며, 이 구조적 공백이 액션 통신의 설계 동기를 형성하였다.

2. 토픽 통신의 한계와 액션의 필요성

토픽 통신은 발행-구독 방식의 비동기 단방향 데이터 흐름을 제공하나, 로봇 행동 관리에서 요구되는 다음의 기능을 지원하지 못한다.

2.1 목표-결과 인과 관계의 부재

토픽 통신에서는 특정 명령 메시지의 발행과 해당 명령의 실행 결과를 인과적으로 연결하는 메커니즘이 존재하지 않는다. “목표 위치 (3.0, 4.0)으로 이동하라“는 명령을 토픽으로 발행하더라도, 로봇이 해당 목표에 실제로 도달하였는지, 도달에 실패하였는지를 구조적으로 확인할 방법이 없다. 발행자는 명령을 전달한 후 구독자의 실행 결과에 대한 어떠한 회신도 수신하지 못한다.

2.2 진행 상황 보고의 구조적 결핍

로봇이 목표 위치로 이동하는 동안 현재 위치, 남은 거리, 예상 도착 시간 등의 중간 정보를 요청자에게 체계적으로 전달하는 표준화된 메커니즘이 토픽 통신에는 존재하지 않는다. 별도의 상태 토픽을 수동으로 설계하여 유사한 기능을 구현할 수 있으나, 이 경우 명령 토픽과 상태 토픽 간의 대응 관계를 응용 수준에서 관리하여야 하며, 이는 코드의 복잡성과 오류 가능성을 증가시킨다.

3. 서비스 통신의 한계와 액션의 필요성

서비스 통신은 명시적 요청-응답 상호작용을 제공하나, 장시간 작업의 관리에서 다음과 같은 구조적 한계를 나타낸다.

3.1 응답 지연으로 인한 시스템 차단

서비스 통신은 설계상 요청에 대한 응답이 비교적 짧은 시간 내에 반환되는 것을 전제한다. 로봇의 내비게이션이나 매니퓰레이션과 같이 수십 초에서 수분에 걸쳐 수행되는 작업에 서비스를 적용하면, 클라이언트가 응답 대기 중에 다른 콜백을 처리하지 못하거나, 타임아웃이 발생하여 통신 실패로 처리된다.

3.2 취소 메커니즘의 부재

서비스 통신에는 이미 전달된 요청에 대해 실행을 중단하도록 서버에 통지하는 표준 메커니즘이 존재하지 않는다. 장애물 발견, 운용자의 수동 개입, 우선순위 높은 작업의 도래 등으로 인해 진행 중인 작업을 중단하여야 하는 상황은 로봇 시스템에서 일상적으로 발생하며, 이에 대한 구조적 지원이 필수적이다.

3.3 중간 상태 보고의 불가

서비스 통신에서 서버는 요청을 처리하는 동안 클라이언트에게 중간 결과를 전달할 수 없다. 요청과 최종 응답 사이의 기간 동안 클라이언트는 작업의 현재 상태를 파악할 방법이 없으며, 이는 장시간 작업에서 사용자 인터페이스의 진행 표시, 안전 모니터링, 적응적 계획 수정 등을 불가능하게 한다.

4. 액션 통신이 해결하는 핵심 요구사항

4.1 목표의 명시적 관리

액션 통신은 목표(Goal)를 일급 객체(First-Class Object)로 관리한다. 각 목표는 고유 식별자(UUID)를 부여받으며, 수락·거부·실행·취소·완료 등의 상태 전이를 거치는 명확한 생명주기를 가진다. 이를 통해 “어떤 작업이 어떤 상태에 있는지“를 체계적으로 추적할 수 있다.

4.2 주기적 피드백 전달

액션 서버는 작업 수행 중에 피드백(Feedback)을 주기적으로 발행하며, 클라이언트는 이를 통해 작업의 진행 상황을 실시간으로 모니터링한다. 피드백 데이터의 구조는 .action 파일에서 정의되며, 현재 위치, 진행률, 남은 시간 등 작업 특성에 맞는 정보를 포함한다.

4.3 작업 취소와 선점

액션 프로토콜은 진행 중인 목표를 외부에서 취소(Cancel)하는 메커니즘을 내장하고 있다. 클라이언트가 취소를 요청하면 서버는 이를 감지하고 적절한 정리(Cleanup) 절차를 수행한 후 목표를 CANCELED 상태로 전이시킨다. 또한, 새로운 목표를 전달하면서 기존 목표를 자동으로 취소하는 선점(Preemption) 패턴도 구현할 수 있다.

4.4 비동기적 작업 관리

액션의 목표 전달은 비동기적으로 수행되어 클라이언트는 목표를 전달한 직후에 다른 작업을 계속 수행할 수 있다. 피드백과 결과는 콜백을 통해 비동기적으로 수신되므로, 실행자의 이벤트 루프가 차단되지 않으며 시스템의 반응성이 유지된다.

5. ROS1에서 ROS2로의 액션 설계 발전

ROS1의 actionlib 패키지는 ROS2 액션 통신의 전신이다. actionlib는 토픽 기반의 구현을 통해 목표-피드백-결과 패턴을 제공하였으나, 프로토콜의 명세가 비공식적이고 DDS 기반이 아닌 자체 구현에 의존하였다.

ROS2의 액션 통신은 actionlib의 설계 철학을 계승하면서, 다음과 같은 개선 사항을 적용하였다.

  • 표준화된 프로토콜: 목표 상태 머신과 통신 프로토콜이 ROS2 설계 문서에 공식적으로 명세되어 있다.
  • DDS 기반 구현: 서비스와 토픽의 조합으로 DDS 미들웨어 위에 구현되어 QoS 정책의 활용이 가능하다.
  • 다중 목표 지원: ROS1의 SimpleActionServer가 단일 목표만 처리할 수 있었던 것과 달리, ROS2 액션 서버는 복수의 목표를 동시에 관리할 수 있다.
  • 목표 수락·거부 메커니즘: 서버가 목표를 수신한 후 즉시 실행하는 것이 아니라, 수락 여부를 결정하는 단계가 추가되었다.

6. 로봇 행동 제어에서 액션 통신의 중심적 역할

로봇의 자율적 행동은 본질적으로 목표 지향적이며 시간 확장적(Time-Extended)이다. “A 지점에서 B 지점으로 이동하라”, “물체를 집어서 지정된 위치에 놓아라”, “순찰 경로를 1회 순환하라“와 같은 행동 명령은 모두 목표 설정, 실행, 모니터링, 완료(또는 취소)의 생명주기를 가진다.

액션 통신은 이러한 로봇 행동의 본질적 특성을 통신 프로토콜 수준에서 지원하는 유일한 ROS2 통신 패러다임이며, 행동 트리(Behavior Tree), 유한 상태 머신(FSM), 태스크 플래너(Task Planner) 등의 행동 제어 프레임워크와 로봇 하드웨어 사이를 연결하는 표준 통신 인터페이스로 기능한다.

7. 참고 문헌

  • Open Robotics, “ROS 2 Design: Actions,” https://design.ros2.org/articles/actions.html, 2018.
  • Open Robotics, “ROS 2 Documentation: Humble Hawksbill,” https://docs.ros.org/en/humble/, 2022.
  • 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.