Skip to main content
Version: 3.4.x

ROS 2 Device Client Runtime Overview

Document scope​

Separate from the server architecture docs, this document explains the ROS 2 client software that runs on devices registered to the server.

If the server architecture docs explain the CoBiz-wide control plane and external-service integrations, this document focuses on the following:

  • which ROS 2 nodes run on the robot endpoint
  • what inputs each node receives and what outputs it produces
  • how plugins must report Task state
  • how config.yaml should be written and inspected during operation

Runtime purpose​

cobiz is the runtime that connects video, audio, LiDAR, sensors, and control on ROS 2-based robot endpoints to the server, and centrally forwards plugin task states back to the server.

The key design changes are:

  • plugins do not make HTTP requests directly
  • plugins only publish to /task_state
  • request_manager is responsible for server requests

The purpose of this structure is to separate plugin domain logic from external HTTP communication.

  1. cobiz_bridge_node: registers the robot with the server and publishes /device_info
  2. manager_node: automatically starts and manages child nodes based on /device_info
  3. health_check_node: forwards server task events to /task_event
  4. plugins (SLAM, TTS, and others): process /task_event and publish /task_state
  5. request_manager: posts /task_state to the server API

Boundary with the server architecture​

Separating the server docs and the device docs makes the responsibility boundary clearer.

  • Server architecture docs: Device registration, Task/Workflow state transitions, Mantis/TGDM integration, operating policy
  • Device runtime docs: ROS 2 node execution, sensor/media input collection, control bridging, plugin status reporting

In short, the server owns domain state and policy, while the device runtime owns field I/O and the execution bridging layer.