Record & replay

Record every stream a robot produces into one portable SQLite file; replay it later as if the robot were there

Any DimOS stack can record itself. A Recorder is an ordinary module you compose into a blueprint: every stream wired into it - camera frames, lidar scans, odometry, joint states, whatever the blueprint connects - is written to a single SQLite .db file, message by message, each observation stamped with its time and the robot’s pose (the recorder also captures the live TF tree). This is the memory2 episode store.

The result is a portable file that contains the robot’s entire sensory experience of a session. Four things you can do with it:

You want to…	Use
Drive a full stack against the recording, no robot needed	dimos --replay run ...
Look at what was recorded	dimos mem summary / dimos mem rerun
Query and analyze it from Python	Offline analysis
Turn it into a training dataset	Collect data & train

Recording is generic

Recording is not a Go2 feature - it is a module you can put in any blueprint. The stacks that ship with a recorder wired in:

Stack	What gets recorded
unitree-go2-memory	The full Go2 sensor suite: camera, lidar, odometry, TF
learning-collect-quest-*	Arm teleop sessions: camera, joint states, episode markers
dimos a1z teach	A1Z teach-mode episodes: camera, arm joints, gripper

To record your own stack, compose a Recorder (dimos/memory2/module.py) into the blueprint and wire the streams you care about into it - Go2Memory in the Go2 blueprints is a thirty-line example of exactly this. The store path is configured on the recorder and printed at startup.

Record a session

No hardware needed to try it - this replays a bundled dataset through the full Go2 stack and records what flows:

dimos --replay --replay-db go2_bigoffice run unitree-go2-memory

On a real robot, drop the replay flags. Recording adds one module to the running stack; everything else behaves normally.

Inspect a recording

dimos mem summary <recording.db>    # streams, counts, time ranges
dimos mem rerun <recording.db>      # render the whole session into the Rerun viewer

dimos mem rerun is the fastest way to scrub through what the robot saw - it writes an .rrd file and opens the viewer. Both commands accept a bare dataset name (resolved from the working directory, data/, or LFS) or a path.

Replay a session

Replay feeds a recorded database back through the stack as if the sensors were live - the robot connection is replaced by a playback connection, and everything downstream (mapping, planning, perception) runs for real against recorded inputs:

dimos --replay run unitree-go2                        # bundled default (go2_short)
dimos --replay --replay-db go2_bigoffice run unitree-go2
dimos --replay --replay-db my_recording.db run unitree-go2

--replay-db takes a bundled preset name (go2_short, go2_bigoffice, downloaded automatically) or your own .db. This is how you develop navigation and perception on the couch: record once on hardware, iterate against the recording forever.

Replay drives the software stack with recorded data. It is different from physically re-executing motion on a robot - that exists too, for taught arm episodes: dimos a1z replay (Galaxea A1Z).

Query it from Python

The same file is a queryable store - five lines to see what is inside:

skip

from dimos.memory2.store.sqlite import SqliteStore

store = SqliteStore(path="recording.db")
for name, stream in store.streams.items():
    print(stream.summary())

From here you can filter by time or space, compute derived streams, embed frames, and search semantically - that is its own page: Offline analysis. The library behind it: The memory2 library.