Data Collection & Management:

Recording Protocol

This section outlines the read-only readiness checks, Service protocol format, single recording session control, and execution specifications for the end-to-end recording delivery closed-loop demo for the robot-side simplified built-in recorder.

Read-Only Readiness Check and Mount Point Verification

• Shell Ownership: Both readiness checks and record_once.py are executed on the robot host.
• Risk Level: Controllable risk.
  • Impact: Initiating recording will continuously consume disk space and compute resources;
  • Warning: DO NOT power off the robot before recording stops and data persistence finishes writing to disk.

• Readiness Check:

ros2 service list | grep -x /mcap_recorder_service
findmnt -T /home/realman/ssd
df -h /home/realman/ssd
du -sh /home/realman/ssd/mcap_recording \
  /home/realman/ssd/mcap_recorded \
  /home/realman/ssd/mcap_compressed \
  /home/realman/ssd/rm_mcap 2>/dev/null
python3 examples/04_data_recording/record_once.py --help

Delivery Package

The examples/ scripts referenced on this page are obtained through the delivery package provided via official delivery channels; use the delivery package version matching your software version. The paths shown in this document are for illustrating script structure only.

Reminder

• Output from findmnt -T MUST explicitly show that /home/realman/ssd itself is the target mount point, and the mount source MUST be a /dev/... block device.
• Safety Abort: If the target is merely a standard directory under the system root partition, or if the mount type is NFS, tmpfs, bind mount, or lacks NVMe backing, initiating recording is strictly prohibited to prevent high-frequency data writes from crashing the operating system.

• Directory Structure and Usage Boundaries

Directory	Observed Role	Customer Usage Boundary
mcap_recording	Active recording/finalizing directory for the simplified edition	DO NOT pull or delete; query status first if the outcome is uncertain.
mcap_recorded	Directory for completed files from the simplified edition	Official data source for the recording delivery demo in this manual.
mcap_compressed	Candidate directory for compression processing	Reference information; customer-side compression closed-loop not established.
rm_mcap	Platform Edition data and upload checkpoint root directory	Reference information; MUST NOT be mixed with simplified edition completed directories.

Service Protocol Format

The Service interface is /mcap_recorder_service, with message type rm_robot_interfaces/srv/StringCmd. Its data field carries the following JSON payload:

{
  "operate": 1,
  "command": "capture",
  "sence_id": "kitchen",
  "task_id": "pick_001",
  "operator_id": "op01",
  "device_id": "110"
}

• operate: MUST be an integer: 1 to start recording, 0 to stop recording. The string "1" has caused process exceptions on legacy recorders; passing string values is strictly prohibited.
• command: Fixed value "capture". Unverified query or compress interfaces must not be called as production APIs.
• sence_id / task_id / operator_id / device_id: These four identifier fields MUST NOT be empty. Their values participate in physical directory naming and MUST NOT contain path separators (/), control characters, or Shell metacharacters.
• Success Response Criterion: The JSON response returned by the service MUST contain a status field with the exact integer 0 (false, 0.0, or string "0" are all considered invalid responses).

Single Recording Session Control and Exception Handling

The single recording demo in this package generates a 16-character unique run ID written to task_id. Upon stopping, it accepts only the newly created directory matching that exact run ID:

python3 examples/04_data_recording/record_once.py \
  --scene kitchen --task pick_001 --operator op01 --device 110 --duration 10

• Clock Buffer Warning: There is a ~$1\text{-second}$ topic subscription skip window after the recorder starts. Critical task actions should account for extra buffer time after status confirmation; NEVER equate the Service response timestamp with the first recorded frame timestamp.
• Pre-Printed Metadata Mechanism: record_once.py prints a compact JSON string (e.g., {"status":"prepared","run_id":"...","meta":{...}}) prior to issuing the start command, enabling back-end status traceability in case of request timeouts. Upon successful completion, it outputs a final JSON containing the same run ID and completed directory path.
• Success Criteria: Both start and stop commands return exact integer status: 0, run IDs in prepared and completed log lines match strictly, and the final target directory /home/realman/ssd/mcap_recorded/<full_directory_name> is successfully generated.
• Timeout Handling: A request timeout does NOT indicate recording failure; NEVER immediately retry the start command. Always use the metadata set from the prepared log line to inspect the active recording directory, completed directory, recorder logs, and service status. If a stop command times out, perform a controlled stop using the same metadata after manual log verification. If non-unique results occur, preserve the environment and avoid automated selection or deletion.