Data Collection & Management:

Selecting and Verifying Topics

This section details topic validation commands on the robot host, recording recommendations across data types, acceptance criteria, and key differences between the platform and simplified recording stacks.

Topic Selection and Categorization

• Shell Ownership: Robot host.
• Risk Level: Read-only for the query commands below. Modifying configurations and restarting the recorder are high-risk operations and are NOT performed in this step.

source /opt/ros/humble/setup.bash
source /home/realman/workspace/rm_robot_ws/install/setup.bash
ros2 topic list
ros2 topic type /mcap/slave_arm_left
timeout 10 ros2 topic hz /mcap/slave_arm_left

Reminder

• Topic selection for recording MUST strictly follow the active recorder configuration file and actual disk-persisted MCAP sampling results.
• Example: A short test recording verified 5 onboard /mcap/* topics and 4 camera_info topics, while excluding image topics (which does NOT contradict wide-angle compressed image topics outputting normally at ~25 Hz at the time). Whether topics like /odom, /scan, or image streams are recorded depends entirely on the active recorder configuration. NEVER infer that a topic is recorded solely based on its presence in the active topic list or historical records.

Data Category	Baseline Examples	Selection Recommendations
Slave Arm, Master Arm, and Onboard Body	/mcap/slave_arm_left, /mcap/master_arm_left, /mcap/body	High-frequency onboard state data; raw message timestamps and schema definitions MUST be preserved.
Chassis	/odom, /scan	Record ONLY when required by specific task workflows; confirm total message count > 0 inside the bag post-recording.
Wide-Angle Color Images	.../image_raw/compressed	Highest impact on storage size and compute load; recording corresponding camera_info topics concurrently is recommended to assist in source-side frame rate diagnostics.
Depth Images	Subject to ros2 topic list on the active machine	Depth topics depend on specific hardware setups; NEVER copy topic naming directly from other hardware configurations to this unit.

• Acceptance Criteria: All topics targeted for recording return valid message types and active data streams, with expected frequencies, serialization types, and resource allocations documented.
• Troubleshooting:
  • If ros2 topic hz returns no data, verify that the underlying hardware component is powered on and its driver node is running properly.
  • For image topics, individual real-time topic hz measurements may report lower rates due to subscriber overhead; the actual message count and total duration in the persisted MCAP file MUST serve as the final authority.

Recording Stack Architecture and Environment Sourcing

The active setup houses both the Simplified Recording Stack and the Platform Recording Stack, each tailored to distinct operational workflows and environment setups:

• The platform edition data collection interface utilizes a second overlay.
• When inspecting rm_interface messages or executing platform nodes, strictly source workspace configurations in the following order (do NOT omit or invert the robot workspace step):

source /opt/ros/humble/setup.bash
source /home/realman/workspace/rm_robot_ws/install/setup.bash
source /home/realman/workspace/rm_data_collect/install/setup.bash
ros2 interface show rm_interface/msg/RmFuncRecordStatus
ros2 topic info /rm_func_mcap_recoder/rm_func_record_status

• Differences Between Simplified vs. Platform Editions & High-Risk Notes

  [ Simplified /mcap_recorder_service ] ──► V1.0 official recording demos strictly utilize the verified simplified pipeline;
  [ Platform /rm_func_mcap_* ]         ──► V1.1 platform pipeline (functional, security, and auto-purge closed-loops fully verified).

TIP

Platform execution remains a high-risk operation: execute ONLY after explicitly accepting that "local task directories are purged automatically following a successful upload," and NEVER copy raw uploader log outputs directly.