The recording shows the symptom.
The cause is in another file, on another clock.
Two files, two clocks. One offset makes every line parallel, and puts the symptom and its cause on the same instant.
A robot is a Linux computer that happens to run a middleware. When a node stops publishing, the recording says exactly when it went quiet and almost never why. logcat.ai reads the recording and the kernel log together, on one timeline, and answers across both with citations.
Illustrative. Synthetic data.A robot is a Linux computer that happens to run a middleware. When a node stops publishing, the recording says exactly when it went quiet and almost never why: the reason is in the kernel log, in memory pressure, in a link that dropped, or on a vehicle bus. logcat.ai reads them together, on one timeline, and answers across all of them with citations.
A robot is more than its middleware
The recording is one of the files you collected, not all of them. These are the others, and they're where causes usually live. Each keeps its own clock; every one is placed against the recording's.
The recording
Says exactly when a node went quiet. Its absolute timestamps anchor every other clock on this page.
The kernel log
Thermal throttling, an OOM kill, a driver reset, a real-time task blocked past its deadline. None of this reaches the recording, and any of it can stop a node.
The network
A packet capture explains a link that dropped, a discovery that never completed, a peer that stopped answering. The recording only holds the silence that followed.
Memory and scheduling
A system trace shows which process lost the CPU and for how long. A missed control deadline usually has a scheduler or an allocator behind it.
The vehicle bus
Plenty of robots carry CAN. A trace decoded through its signal database puts actuator faults on the same timeline as the node that was commanding them.
Upload the recording and whatever else you collected from the same machine and the same window. A comparison places them on one timeline and answers across both, rather than leaving you to hold two screens in your head.
Why this is hard today
Two toolchains, two clocks, and a file that hides its evidence under sensor data.
Two toolchains
Recording tools read recordings. Log tools read logs. Nothing reads both, so the correlation happens in your head, off two screens.
Two clocks
A recording is in absolute time. A kernel log is often seconds since boot with no year on it anywhere. Lining them up manually is a guess you then build a theory on top of.
Size hides the evidence
Most of a recording is sensor payload nobody needs to read. Tools that insist on reading it turn a five-minute question into an afternoon.
Silence reads as nothing
A node that died and a topic nobody ever used both count zero messages. If your tool can't tell them apart, neither can you.
How a failed run gets debugged
Same recording, same kernel log, two very different afternoons.
Replay the recording at wall-clock speed and watch for the moment it went wrong.
Open the kernel log in a second window and try to reconcile two different clocks.
Write a throwaway script to pull the health reports out into something readable.
Ask whoever wrote the node, because only they know what its states mean.
Do all of it again for the next run, and again for the next engineer.
Hours per run, and a correlation that lives in one person’s head.
Upload the recording and whatever else you collected from the same robot.
Ask in plain English what happened, or what changed since the last run.
Get an answer across every file, on one timeline, cited and with its coverage stated.
Minutes, and an answer the next engineer can check.
What the platform does with a robot's files
The same investigation engine every other surface uses, pointed at a recording and its neighbours.
Deep Research
A multi-round investigation over one recording that queries it, follows what it finds across rounds, and reports what it couldn't read as plainly as what it could. To bring in the robot's other logs, use Delta.
Learn moreDelta
Two runs, or one run and the kernel log underneath it, placed on one timeline. The recording's absolute timestamps anchor files that never wrote down a year.
Learn moreCoverage, stated every time
Every answer says how much of the recording it rests on: the inventory, the log stream and the health reports each report whether they were read in full, in part, or not at all. A channel nobody decoded and a channel the robot never published on are different facts, and they're reported as different facts.
Sensor payload skipped on purpose
Camera, lidar and point clouds are inventoried and never decoded, so the reading cost tracks the channels that explain a run rather than the ones that fill the file. Where a payload-heavy recording can only be read in part, the answer says so.
When this comes up
Four situations that arrive with a recording and not much else.
A run failed in the field
One recording came back and nobody was watching. Ask which components reported a problem and in what order, then pull in the kernel log from the same machine when the recording stops explaining itself.
It worked yesterday
Compare the two runs directly: what changed in component health, which channels went quiet, and whether the difference shows up in the robot's system logs rather than in its middleware at all.
The same fault on more than one robot
Upload the recordings and the logs from each machine and ask whether it's the same failure, so you know whether you're chasing one robot or a build.
Bring-up on new hardware
New board, same stack. The recording shows which nodes came up and which never published anything, and the kernel log says which driver is the reason.
What comes back from a recording
All three ROS recording formats, read as they came off the robot.
All three formats
The classic single-file bag, the MCAP container, and the database-backed ROS 2 recording. Recognised by content rather than file name, so there's nothing to convert.
Channel inventory
Every channel, its message type, its message count and the window it covers, read from the recording's own index. Channels that carried nothing are kept, because they're often the point.
Component health
Each 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.
The log stream
The robot's log messages become a searchable log beside the recording, in the same viewer as every other log you upload.
Recording on the robot
Nothing here needs a special capture mode. Upload whatever your robot already writes.
rosbag record -aros2 bag record -aros2 bag record -a -s mcapA 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. Collect the kernel log from the same window while you're at it.
Analyzers for a robot's stack
A recording is one file among several. Each of these reads another part of the same machine.
What the robot published, reported and stopped doing.
Root cause from a raw logcat stream, cited to the line.
Kernel panics, oopses, and driver faults from dmesg.
Cross-file correlation across a whole diagnostic archive.
Jank, startup, and scheduling from a Perfetto trace.
Questions about robot debugging
What to upload, how the files line up, and where a person comes in.
What do I upload for a robot?
Start with the recording, in whatever format your robot already writes: classic bag, MCAP, or the database-backed ROS 2 format. Then add whatever else you collected from the same machine over the same window, especially the kernel log. The recording tells you when a node went quiet, and the other files usually tell you why.
How do you line a recording up with a kernel log?
Recordings carry absolute timestamps, so the recording anchors the comparison. A kernel log that only counts seconds since boot is placed against that anchor rather than guessed at. Where a file's clock genuinely can't be resolved, the comparison says so instead of quietly aligning it wrong.
Do I need to convert or export anything?
No. All three ROS recording formats are read as they come off the robot, and they're recognised by content rather than by file name. There's no conversion step and nothing to declare in the upload.
Can it answer questions about what the robot saw?
No. Sensor payload (camera frames, lidar returns, point clouds) is inventoried but never decoded, which is what keeps a very large recording quick to analyze. Questions about what the robot did, what it reported, and when it stopped are all answerable. Questions about the contents of an image are not.
Is this only for ROS robots?
The recording surface is ROS specific, in all three of its recording formats. Everything else on the robot is not. Kernel logs, packet captures, system traces, bus traces and crash dumps are read the same way whatever middleware runs above them, so a robot without ROS still gets everything except the recording surface.
Where does a person come into this?
Throughout. The investigation runs on its own and reports what it found, cited back to the file and the channel, including what it couldn’t read. Deciding what that means, and what to change on the robot, stays with the engineer. Nothing is applied to your fleet.
What do I need enabled?
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 recognised for what it is, and the analysis step is skipped. The rest of the robot's logs need nothing special. Email sales@logcat.ai if you need it enabled.