Integration Scenarios:
Selecting Integration Pathways by Development Environment | Development Environment | Recommended Pathway | Status | Invalid Assumptions |
|---|---|---|---|
| On-Robot Host (Ubuntu 22.04) | Direct ROS 2 calls via rclpy/rclcpp, reading local disk-persisted data | Officially Released | Do NOT treat root permissions, configuration edits, or stopping system services as standard SDK privileges |
| Ubuntu 22.04 / ROS 2 Humble Dev PC | Cross-machine ROS 2 when DDS requirements are met; otherwise deploy via SSH directly to robot host | Reference Info | Network connectivity (ping) alone does NOT guarantee ROS 2 availability; requires matching Domain ID, compatible RMW/message packages, multicast, and firewall rules |
| Non-ROS Linux / Java / Go / Python Platforms | Loopback HTTP Bridge, SSH/SFTP, and offline MCAP packages | HTTP Bridge code hardened; on-site customer deployment acceptance required | Do NOT expose ROS 2 custom message types directly to non-ROS platforms |
| macOS / Windows | SSH, published REST/HTTP APIs, and offline MCAP packages | Default Pathway | Do NOT assume native cross-machine DDS setup or a local Humble environment with matching custom message workspaces |
If the business requirement is strictly "Trigger Data Collection — Fetch Files — Process Offline", prioritize the file-based closed loop. Forcing a complex cross-machine DDS setup solely to retrieve completed MCAP data files is strictly prohibited.
If the business requirement requires low-latency real-time data, place the ROS 2 subscriptions and protocol translation layer directly on the robot host or a controlled Ubuntu gateway, and design dedicated mechanisms for image bandwidth, QoS policies, and backpressure management.