flightopsDocumentation
Reference: recording

Managed recording in Standard mode

2 min readdocs/reference/managed-recording-commands.md (source repository)

Enable a standing policy once in the ROS environment and project you intend to use. Policies are disabled until explicitly enabled. The selected topics apply to ordinary managed launches in that same scope.

sh
flightops record --project /path/to/project enable --topics /scan /camera/info
flightops --project /path/to/project launch /path/to/robot.launch.py
flightops record list
flightops record show SESSION_ID
flightops record view -o /new/path/recordings.html
flightops record --project /path/to/project disable

The launch owner probes the installed MCAP writer and arms a separate bounded recorder before starting the application. Quitting stops the owned application, then closes and verifies its recording. No Save action, investigation, model, or provider connection is required. Capture failure is visible and does not prevent the application from running. A later ordinary launch reuses the enabled policy. Disabling or replacing that policy stops active capture; it does not stop the application.

Use --ros-domain-id before enable, status, or disable to select a domain. The policy is also bound to the resolved environment identity. A different project, setup environment, domain, or RMW needs its own explicit policy. --allow-shared-topic /tf (or /tf_static, /rosout) explicitly authorizes that complete shared stream; selecting a namespace does not filter its payload.

Optional enable flags set --max-bytes (aggregate retained bytes), --max-session-bytes, --max-segment-bytes, --reserve-bytes, and --max-duration-s. The owner monitors usage and stops capture when a bound or reserve is reached. Bounds are polled, with a shutdown margin; they are not kernel-enforced hard disk quotas. Read the resulting reason and gaps before using a degraded recording. These limits have not been accepted under sustained high-rate load; see known limits.

The catalog retains separate arming, application-start, and first-recorded message times. Startup coverage before the first message remains unknown. MCAP hashes are assigned only after the writer stops cleanly and the closed file passes verification. Active or interrupted bytes have no final digest. No-message capture remains explicit. Availability is separate from historical segment state; an excluded backup copy does not rewrite a past finalized state.

These commands record managed launches only. To capture topics from external nodes, use the independent collector (flightops record collector). For retention budgets, expiry and incident pins, use recording retention (flightops retention). Damaged-MCAP recovery is not available, and complete startup capture is not claimed. The list and dark HTML view work without ROS and show historical metadata; verify actual bytes and source scope before reuse.