The recording shows when. It never shows why.
Camera and lidar are most of the file and none of the answer. logcat.ai reads the channel inventory from the recording's own index and decodes the two channels that explain a run. It can tell a node that stopped from a topic nobody wrote to.
A recording shows exactly when a channel went quiet, and never why: that is usually in a log the robot wrote somewhere else.
One recording, one question.
The recording is asked directly. The investigation reads the health reports in order, finds the moment a channel went quiet, checks that it was quiet rather than never used, and says plainly when the cause is not in the file.
The arm stopped responding about seven minutes in. What does the recording show leading up to it?
Synthetic recording, not a customer run.
The arm controller missed its control deadline and took itself out.
The arm controller went from OK to degraded at 06:25.0 and to critical at 06:42.0, and its own health message names a control loop overrun. The log stream shows that overrun repeating for seventeen seconds before the controller stopped publishing on its command channel, which had carried 1,608 messages up to that point. That channel is silent for the rest of the run rather than absent, which is a different fact and is reported as one. Nothing in the recording says why the loop overran, so the next file to read is the kernel log from the same window.
All three recording formats.
You don't have to tell us which one you have. Recognition is by content, not by file name: the same channels come out of all three, read the same way.
The original single-file recording. Upload it directly, exactly as it came off the robot.
The container newer ROS 2 systems record to by default. Read the same way as the other two.
The other ROS 2 storage backend, where the recording is a database file rather than a stream.
There's no export step, no conversion, and nothing to declare in the upload. If your robot wrote it, we read it.
What gets read, and what deliberately doesn't.
Two channels are decoded in depth. Everything else is inventoried and left alone, on purpose.
Every channel, the message type it declared, how many messages it carried, and the window it covers, read from the recording's own index. A channel that carried nothing is kept rather than dropped, because it's usually the interesting one.
Each reporting component's worst state across the run, what it said at the time, and every report that wasn't OK in the order the robot made them. This is the machine's own account of itself.
The robot's log messages are pulled out into their own searchable log beside the recording. It opens in the log viewer and answers questions the way any other log does.
Camera frames, lidar returns and point clouds are inventoried and never decoded. In a recording carrying them that's almost the whole file, and skipping it is what makes a very large recording quick to analyze.
Every answer says what it was drawn from.
Three things are read: the channel inventory, the robot's log stream, and its component health reports. Each one reports its own state, every time, so you're never left reading an empty result and guessing which kind of empty it is.
It was decoded and the answer draws on its contents.
Some of it was decoded, and the answer says how much.
It is there and could not be decoded, which is stated rather than shown as a zero.
This recording does not carry it, which is a different fact from an empty one.
A channel nobody could decode and a channel the robot published nothing on look identical if you only count messages, and only the second one means the robot was quiet.
Why a recording is hard to get an answer out of.
The file is enormous, the interesting part is tiny, and the usual way of reading it is to watch it go past.
A few minutes of a camera and a lidar is gigabytes. The part that explains the run is a rounding error inside it, and most tools insist on reading the rest first.
Playing a run back at wall-clock speed to watch for the moment it went wrong is waiting, not analysis. Eleven minutes of run costs eleven minutes of your attention, and you get one look.
A node that stopped publishing and a topic nobody ever wrote to both count zero messages. Telling them apart is the difference between a fault and a non-event.
A node stops publishing and the reason is in the kernel log, or in memory pressure, or on a bus. The recording shows the symptom and stops there.
A dashboard, a searchable log, and two ways to ask.
What the recording is, component health, the reports that weren't OK, what was read, and how the messages divided across channels. It renders from the recording's own metadata, so nothing on it is guessed.
Ask the recording a question in plain English and get an answer from it in seconds, cited to the channels it came from.
A multi-round investigation that queries the recording, follows what it finds, and reports what it couldn't read as clearly as what it could.
Put a recording next to another run, or next to the robot's kernel log, on one timeline. Recordings carry absolute timestamps, which makes them a good anchor for a log whose timezone was never written down.
two files · one timeline · the cause beside the symptomRecord it however you already do.
Nothing here needs a special capture mode. Upload whatever your robot already writes.
A recording that includes the robot's log channel and its health channel gives you the most, because those are the two read in depth. Recording them costs almost nothing next to sensor data.
What you need on your account.
Robot recording analysis needs robotics log analysis on your account. Without it a recording still uploads and is still recognised for what it is, and the analysis step is skipped. Emailsales@logcat.aiif you need it enabled.
The rest of the robot has analyzers too.
A recording explains the middleware. These read the machine underneath it, and a comparison puts them on one timeline.
Questions about robot recordings.
What gets read, what doesn't, and what it takes to get an answer.
All three, and you don't have to say which one you have. The classic single-file bag, the MCAP container that newer ROS 2 systems record to by default, and the database-backed ROS 2 recording. Recognition is by content rather than by file name. There's no export or conversion step.
No, and that's deliberate. Sensor payload is left untouched, which is what keeps a recording that's mostly image or point cloud data quick to analyze. Those channels are still inventoried, with their message type and count, you just don't get their contents. Questions about what the robot saw can't be answered from a recording. Questions about what it did and what it reported can.
Recordings get a much larger allowance than an ordinary log, because a run carrying camera or lidar data is large by nature and trimming it throws away the evidence. Upload the recording as it came off the robot. Recording the log and health channels to their own recording is still worth doing when you can, since it uploads in a fraction of the time and is the same analysis: the reading cost tracks the diagnostic channels rather than the total size, because sensor payload is never decoded.
Every answer states its coverage. 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, or aren't in this recording at all. That matters more than it sounds. A channel nobody could decode and a channel the robot published nothing on look identical if you only count messages, and only the second one means the robot was quiet. The two are kept apart and labelled.
The log stream is pulled out of the recording and promoted to its own searchable log beside it. It opens in the log viewer and answers questions the way any other log does, so you can read what the robot said around a moment without opening the recording at all. The recording keeps its own dashboard and its own investigations.
Yes. A comparison can place a recording alongside the robot's kernel log, a packet capture, or anything else you collected from the same machine, on one timeline. Recordings carry absolute timestamps, which makes them a good anchor for a log whose timezone was never written down. That pairing is usually where the cause turns up, because the recording tends to hold the symptom.
Robot recording analysis needs robotics log analysis on your account, which is the exact wording you'll see if a recording is held back. Without it a recording still uploads and is still recognised for what it is, but the analysis step is skipped. Email sales@logcat.ai if you need it enabled.
Point it at your last run.
Upload the recording as it came off the robot. You get a dashboard, the log stream as its own searchable log, and an answer you can trace back to a channel.