Data Collection & Management:

Selecting a Recording Pipeline

This section compares the applicable scenarios, current delivery verification status, and key safety/architectural boundaries across three data recording pipeline architectures to assist customers in selecting the appropriate solution based on their actual development requirements.

Pipeline	Applicable Scenarios	Current Verification Status	Key Boundaries
Simplified Built-in Recorder mcap_record_control	Customer platforms controlling single recording sessions and retrieving MCAP files upon stopping	Officially Released	/mcap_recorder_service manages start/stop operations; data moves from mcap_recording to mcap_recorded
Custom Customer Solution rosbag2_py / ros2 bag record	Highly customized requirements needing tailored topic filtering lists, internal queues, and disk I/O strategies	MCAP writing pipeline Officially Released	• Thread Isolation Requirement: High-frequency callbacks must only handle queue insertion; disk I/O writes MUST be executed by dedicated threads. • Responsibility Boundary: Customers assume full responsibility for potential frame loss risks, disk capacity monitoring, and teardown/persistence logic upon unexpected termination.
rm_data_collect Platform Edition	Leveraging the full Darwin platform task management, remote upload, and status closed-loop system	Officially Released	• Full-Chain Closed-Loop: Supports start/stop, recording, file hash validation, file upload, metadata reporting, and auto-purging. • Compliance & Sanitization: Sensitive logging points have been sanitized.