rosbag2_dynamic_recorder

A ROS 2 bag recorder that can change what it records without stopping the recording. It also records the changes themselves, so a finished bag can explain its own gaps.

Stock ros2 bag record fixes its topic set at launch. Recording a different set means stopping and starting again, so a long run becomes a pile of files that must be stitched back together, and every seam is a gap in every topic at once.

This recorder writes one continuous bag while topics come and go. It emits an event on every change, into the bag itself, so a channel that stopped can be told apart from one that was lost.

Using it

• Install
  • Full install
  • Launch arguments
  • Client-only install
  • Why there is no pip install
  • ROS 2 distributions
  • Docker
• The service API
  • Topic management
  • Recording control
  • Simulation time
  • Status
  • Events
  • Profiles
  • Parameters
  • Calling them by hand
• Recording profiles
  • Declaring profiles
  • Starting a recorder with profiles
  • Switching
  • What a switch does
  • Which profile is active
  • When a topic is not there
  • Designing profiles
• The command line
  • Finding the recorder
  • Exit codes
  • Patterns
  • Naming a type
  • Profiles
  • Scheduling
  • Reading a bag back
  • Machine-readable status
• The Python library
  • 1. Failures raise; partial successes do not
  • 2. Unknown is not zero
  • 3. It can watch
  • 4. A Recorder is meant to be long-lived
  • Reading the bag back
  • Several recorders
  • Errors
  • Without ROS installed
• The browser UI
  • Scheduling
  • The timeline
  • Filtering topics
  • Endpoints
  • Parameters
  • What it is built from

Reference

• API reference
  • The client
  • Reading a bag back
  • Results
  • Errors
  • Discovery
  • Scheduling
  • Topic specifications
  • Service types

Where to start

• Just want it running? Install, then the browser UI.

• Driving it from a shell or a supervisor script? The command line.

• Driving it from Python? The library guide and its API reference.

The four ways in

	For	Needs
Services	Anything that speaks ROS	Nothing beyond ROS
ros2 dynrec	A shell, an ssh session, a supervisor script	The CLI package
dynrec (Python)	A mission script that reacts to what the robot is doing	The library package
Browser UI	Clicking checkboxes, no syntax to learn	The UI package, a browser

Each client is a thin wrapper over the services. Keeping the API usable from the thinnest client is what keeps it honest.

One caveat, carried everywhere

Numbers the recorder cannot vouch for are reported as unknown, never as zero. messages_missed is meaningful only when the middleware supplies publication sequence numbers; messages_lost_in_transport counts only what the transport chose to report, and has been observed reading 0 while roughly 3-4% of messages were genuinely absent. Every interface here (the services, --json, the library’s Status, the browser UI) keeps that distinction rather than flattening it to zero.

Losses are also kept apart by where they happened. messages_lost_in_recorder is the writer’s own drops, meaning the cache filled because the disk could not keep up. It is reported on its own line rather than folded into the transport figure, because the two have opposite remedies: one points at the publisher or the network, the other at the cache size, the storage preset, the topic set, or the disk. On a small computer writing to an SD card it is the number to watch.