Playing back recordings

A good recording of a drive is often the most useful test data you will ever have. With RemotiveTopology you can play that recording back onto virtual buses and watch it in RemotiveStudio, with the camera videos in sync. This post covers how to set that up and what we use it for day to day.

Why play back a recording

Playback, also called open loop simulation, sends recorded vehicle data back onto the channels of a running topology as if the vehicle were there. Three things make that useful:

• Debugging. When something odd happens on a test drive, you can replay those 20 seconds as often as you like, pause on the frame where it goes wrong and look at it next to the front camera video.
• Developing against real data. A behavioral model or an app that consumes signals gets realistic input from a laptop, without a car or a test rig. You can also mix recorded data with a running topology (closed loop simulation), for example by feeding recorded GPS positions to an Android Automotive instance while the climate controls still respond.
• Regression testing. The same recording gives the same input every time, so a test case that runs against it in CI shows you when behavior changes.

Describe the drive as a recording session

Everything starts with a recording session: a YAML file with the session's start and end time, the recording files, any video files, and a mapping from the recording equipment's device names to the platform's channels. RemotiveTopology reads CAN dumps and CSV in long format (timestamp, signal name, signal value). This example is taken from the docs:

schema: remotive-recording-session:0.2

name: Roundabout left turn
start_time: 1753865338s
end_time: 1753865361s

files:
  - location: ./candata.log
    type: recording
  - location: front.mp4
    name: front
    type: video
    start_time: 1753865335s

mapping:
  includes:
    - ../equipment.mapping.yaml

Some things to watch for:

• The mapping is what turns can0 on the logger into DriverCan in your platform. If the device names already match the channel names, you don't need one. If you keep the mapping in its own file, several recordings made with the same equipment can share it.
• Videos need a name (front, rear and so on). Dashboards pick videos by that name, so one dashboard works for every session from the same car. Set the video's start_time too: the camera rarely starts at the same moment as the logger. Use MP4 with H.264 and AAC, since RemotiveStudio runs in a browser.
• You can have several sessions that point at the same recording files, for example to cut out the interesting part of a long drive.

You don't have to write the file by hand: remotive topology recording-session create -f candump.log generates a session from one or more recording files, and recording-session recalculate updates its start and end time after you change file offsets. See Recording concepts for the details.

Start a topology to play it on

Playback needs a running topology instance whose platform has every channel the mapping uses. The instance can have more channels than that, so a recording of only one bus works too. To get a simple instance with default settings and no behavioral models, generate it from the session, then build and run it:

remotive topology recording-session instantiate roundabout.recordingsession.yaml playback.instance.yaml
remotive topology generate -f playback.instance.yaml build
docker compose -f build/<instance>/docker-compose.yml --profile ui up

You don't need a new instance for every recording. If you recorded several drives with the same platform, you can use one instance to play all of them. The Usage page also shows how to add your own signals that aren't on the vehicle platform, such as emulated GPS, through a CSV file and an extra channel.

Watch it in RemotiveStudio

Start RemotiveStudio in your workspace with remotive studio . and open a dashboard. The Add Panel picker has two groups. Use Open recording from the recordings group to load the session for playback, then add a Video panel for each camera. The video stays in sync with the signal timeline. Next to them, add the chart panels you need: a Time series for the signals you care about, a Trace for raw frames, a Map if the recording has latitude and longitude, or a Frame distribution to see which frames are sent most often.

One tip from experience: use only one dashboard tab. RemotiveStudio warns if it sees more than one dashboard running, and you may find that playback controls stop responding or videos don't play. The Add a panel page lists every panel type.

Control playback from the command line

The same controls are in RemotiveCLI, which is handy from a script or when you only want to jump to the interesting moment. Offsets can be given in minutes, seconds, milliseconds or microseconds:

export REMOTIVE_RECORDING_SESSION_PATH=<recording session>

remotive broker playback open "$REMOTIVE_RECORDING_SESSION_PATH"
remotive broker playback play "$REMOTIVE_RECORDING_SESSION_PATH" --offset 10s
remotive broker playback pause "$REMOTIVE_RECORDING_SESSION_PATH"
remotive broker playback seek "$REMOTIVE_RECORDING_SESSION_PATH" --offset 15000ms
remotive broker playback repeat "$REMOTIVE_RECORDING_SESSION_PATH" --start-offset 10s --end-offset 20s
remotive broker playback status --stream

repeat loops a part of the recording, which is useful while you change a behavioral model and want the same few seconds over and over. Run it with --clear to stop the loop. Every command takes --url if your broker isn't on http://localhost:50051. All options are in the RemotiveCLI manual.

For regression tests, playback can also be controlled from code, for example from a test case running in its own container in the topology, and the topology can be shut down when the tests are done (see Running). To try all of this without a recording of your own, the examples include a Tesla Model 3 drive with two CAN buses and four camera videos.