ROS 2 디바이스 클라이언트 런타임 개요

문서 범위

이 문서는 서버 아키텍처 문서와 별도로, 서버에 등록되는 디바이스 측 ROS 2 클라이언트 소프트웨어를 설명합니다.

서버 아키텍처 문서가 CoBiz 전체 시스템의 control plane과 외부 서비스 연동을 설명한다면, 이 문서는 다음에 집중합니다.

• 로봇 단말에서 어떤 ROS 2 노드들이 실행되는지
• 각 노드가 어떤 입력을 받아 어떤 출력을 만드는지
• 플러그인이 Task 상태를 어떤 방식으로 보고해야 하는지
• config.yaml을 어떻게 작성하고 운영 중 어떻게 점검하는지

런타임 목적

cobiz는 ROS 2 기반 로봇 단말에서 영상, 오디오, LiDAR, 센서, 제어를 서버와 연결하고, 플러그인 작업 상태를 중앙에서 서버로 전달하는 런타임입니다.

기준 변경점은 다음과 같습니다.

• 플러그인은 직접 HTTP 요청을 하지 않습니다.
• 플러그인은 /task_state만 publish 합니다.
• 서버 요청은 request_manager가 담당합니다.

이 구조의 목적은 플러그인 도메인 로직과 외부 HTTP 통신을 분리하는 것입니다.

권장 실행 구조

1. cobiz_bridge_node: 서버에 로봇 등록 + /device_info publish
2. manager_node: /device_info 기반 child 노드 자동 실행/관리
3. health_check_node: 서버 task 이벤트를 /task_event로 전달
4. 플러그인(SLAM, TTS 등): /task_event 처리 후 /task_state publish
5. request_manager: /task_state를 서버 API로 POST

서버 아키텍처와의 경계

서버 문서와 디바이스 문서를 분리해서 보면 역할 경계가 더 명확합니다.

• 서버 아키텍처 문서: Device 등록, Task/Workflow 상태 전이, Mantis/TGDM 연동, 운영 정책
• 디바이스 런타임 문서: ROS 2 노드 실행, 센서/미디어 입력 수집, 제어 브리지, 플러그인 상태 보고

즉, 서버는 도메인 상태와 정책을 담당하고, 디바이스 런타임은 현장 단말의 입출력과 실행 연결 계층을 담당합니다.