Robot recordings (ROS)

Robot recordings (ROS)

Upload a recording as it came off the robot and logcat.ai reads its channel inventory, decodes the diagnostic channels, pulls the robot’s own log stream out into a searchable log beside it, and renders a dashboard. You investigate it the same way you would a bugreport.

What gets accepted

All three ROS recording formats, and you do not need to say which one you have:

  • The classic single-file bag. One file, uploaded directly.
  • The MCAP container. The format newer ROS 2 systems record to by default.
  • The database-backed recording. The other ROS 2 storage backend.

Recognition is by content, not by the file name; keep the recording’s own extension (see Size limits). There is no export or conversion step.

What to actually upload

Upload the recording file, not a folder. This matters because the two ROS 2 formats are written as a folder:

  • ROS 1 writes a single .bag. Upload it as-is.
  • ROS 2 writes a folder holding a metadata file and one or more storage files. Upload the storage file itself: the .mcap or the .db3 inside that folder. You can also zip the folder and upload the archive, which arrives as a bundle.

If your run produced more than one storage file, zip the folder. A long run rolls over into several storage files, and the zipped folder is read as one recording covering the whole run. Uploading the storage files individually gives you one set of results per file, each covering its own slice.

How a recording is analyzed

  • The channel inventory is read from the recording’s own index: every channel, the message type it declared, and how many messages it carried. A channel that is present and carried nothing is kept rather than dropped, because it is usually the interesting one.
  • Only the diagnostic channels are decoded. The robot’s log stream and its component health reports have their contents read; sensor payload is left alone. In a recording carrying a camera or a lidar, that payload is almost all of the file, and leaving it untouched is what makes a very large recording quick to analyze.
  • Component health becomes the machine’s own account of itself. Each reporting component’s worst state across the run, what it said at the time, and the reports that were not OK in the order the robot made them.
  • The log stream becomes its own searchable log. It sits alongside the recording, opens in the log viewer, and answers questions the same way any other log does.
  • The dashboard shows what the recording is, component health, the health reports, what was read, and how the messages divided across channels.
  • Ask in plain English. Quick Search answers from the recording directly, and Deep Research investigates it across rounds. To bring in the robot’s other logs, use Delta, which is the comparison surface.

What was read, and what was not

Every answer says how much of the recording it was drawn from: the channel inventory, the log stream and the health reports each report whether they were read in full, read in part, could not be read, were not examined, or were absent from the recording. A channel we could not decode and a channel the robot published nothing on are reported as the different things they are; only the second means the robot was quiet.

Example questions to ask

Quick Search, answered from the recording:

Which components reported a problem, and in what order?

Which channels stopped carrying messages during the run?

What did the log say in the two minutes before the run ended?

Deep Research, across rounds, over this one recording:

The arm stopped responding partway through. What does the recording show leading up to it?

Which components degraded first, and what did the log say around each?

Delta, comparing this recording with another file:

Compare this run against yesterday’s and tell me what changed.

Line this run up against the robot’s kernel log and tell me what happened underneath it.

Recording on the robot

You upload whatever your robot already writes. Nothing here needs a special capture mode:

# ROS 1
rosbag record -a

# ROS 2 (records to the default storage backend)
ros2 bag record -a

# ROS 2, MCAP explicitly
ros2 bag record -a -s mcap

A recording that includes the robot’s log channel and its health channel gives you the most, because those are the two the analysis reads in depth. Recording them costs almost nothing next to sensor data.

Size

A single-file recording (.bag, .mcap, .db3) is exempt from the ordinary 250 MB per-file limit. A multi-file ROS 2 folder should be archived with 7z a run.7z run/, since .7z keeps the larger allowance; a .zip or .tar.gz is read the same way but takes the ordinary 250 MB.

Recording the diagnostic channels to their own recording is worth doing anyway. It uploads in a fraction of the time and gives the same analysis, since sensor payload is never decoded:

# ROS 2, just the channels the analysis reads in depth
ros2 bag record /rosout /diagnostics

If a full sensor recording is refused as too large, talk to us at sales@logcat.ai rather than trimming it yourself.

Pairing a recording with the robot’s other logs

A robot is not only its middleware. It is a computer with a kernel log, a network stack, memory pressure and often a vehicle bus, and a recording usually shows the symptom while the cause sits in a file that is not robot-shaped at all: a node stops publishing, and the reason is in the kernel log.

Upload both. Recordings carry absolute timestamps, so a recording is a good anchor for a log whose own timezone was never written down, and a comparison places them on one timeline and answers across both.

Access

Robot recording analysis needs the robotics log analysis capability on your account. See Why was I limited?.

Next