Best Logging and Replay Tools for Robotics in 2026

For most robotics teams in 2026 the best combination is ros2 bag writing MCAP files, Foxglove for reading them, and structured text logs underneath. Those three answer what the robot received, in what order, and what it decided, which is where most faults live. That flips when the fault is a handover between programs on one machine, a question about ROS 2, HORUS and the layer under the tools. The rest of this post is for a team that has already lost an afternoon arguing about a failure nobody recorded.

Your robot did something wrong on Thursday and nobody can prove what. One engineer remembers the arm hesitating before it swung. Another is certain the camera dropped out first. The terminal history is gone, the machine has been rebooted twice since, and the behaviour has not come back in forty attempts.

So you start recording. Now you have a folder of files nobody can open on their own laptop, a disk that filled during the one run that mattered, and a naming scheme that made sense on the day and means nothing a fortnight later. When you do open a recording, it shows the failure happening, which everyone already agreed on, and nothing about why.

Meanwhile the failures are getting harder to catch. The ones you can reproduce are fixed. What is left happens on the fifth run, on the cold morning, on the unit in the other building, and each one costs a day of somebody sitting beside the robot waiting for it. You do not need more data. You need the run itself, in a file, in a form that answers questions.

What are the best logging and replay tools for robotics in 2026?

The ros2 bag recorder writing MCAP files, Foxglove for reading them back, and structured text logs underneath cover what almost every team needs. Each answers a different question, which is why the combination beats any single tool. The recorder captures the messages programs sent each other, so a run can be played back into your software later. Foxglove opens those files without a ROS 2 environment on the machine, which matters the moment a second person wants to look. Structured text logs carry the part no recording can hold: what your code concluded and why it chose what it chose. Teams working outside ROS 2 substitute Rerun for the viewer and log directly from their own programs, which trades the ready-made recorder for control over exactly what gets captured. Above a handful of robots, a hosted place to put recordings stops being a luxury, because copying files off machines by hand quietly becomes somebody's job. Best visualisation and debugging tools for robot projects covers the live-viewing half of the same problem.

What does replay actually mean on a robot?

Replay means feeding a robot's recorded inputs back into the same software, so a run that happened once can be studied as many times as you like. The recording holds the messages that travelled between programs during the run: camera frames, laser returns, joint positions, the commands your planner produced. Playing that back means your navigation code, or your perception code, receives the same stream it received on the day, on your desk, with no robot present and nothing at risk. This is why replay changes how a team works rather than just adding a tool. A fault that exists only in a memory is something people argue about. A fault in a file is something people fix, in any order, on any machine, with a colleague watching. It is also the only honest way to compare two versions of your code, because the alternative is running the robot twice and hoping the world was the same both times, which it was not. The limits of that promise matter, and they arrive sooner than most teams expect.

What are the actual options for recording a robot run?

There are six families, and a working team usually runs three of them at once. The ros2 bag recorder is the default for anyone on ROS 2, and since it writes MCAP the files outlive the tool. MCAP on its own is the second option, usable from code that never touches ROS 2, which is how teams with their own stack get a portable recording. Foxglove is the reader most teams settle on, opening live data and files in the same window and sharing a view with somebody who has no robot environment installed. Rerun is the option for logging your own program's data as you write it, rather than recording a message graph you already have. Structured text logging is the unglamorous fifth family that finds more bugs than the rest combined. The sixth is the messaging layer beneath everything, ROS 2 or a single-machine middleware such as HORUS, which decides where a recorder can tap in and what a handover between two programs even looks like.

How do the recording and replay options compare?

The rows run from the most ready-made to the most hand-built, which is roughly the order teams adopt them.

Read the last column first. Most wasted weeks come from adopting a tool whose "when not to" describes your project exactly.

Which setup fits a small team shipping a product?

A small team shipping a product should record every run on the robot, keep a shared place to put the interesting ones, and treat replay as a test rather than a debugging session. The difference between a hobby setup and a product setup is not the tools; it is whether recordings are kept on purpose. Two people can survive with files on a laptop. Four people cannot, because the run that explains the customer complaint is on the machine of whoever was on site, and that person is now on holiday. What works is boring: recording starts when the robot starts, files are named by unit and date without anyone thinking about it, and there is one location everyone knows. The second habit that pays for itself is keeping a handful of clean runs as a reference set and replaying them before each release, so the question "did we make it worse" has an answer that is not a shrug. How teams test robot software without breaking hardware covers what those replays sit alongside.

What changes if the robot is a small board with limited storage?

Storage becomes the design constraint, and every choice follows from it. A small board can record, and should, because a recording made on the robot loses nothing to a dropped network connection. What a small board cannot do is record everything for hours. Camera data fills a card while you are still setting up, and a full card produces failures that look like every other kind of failure, which is a special waste of an afternoon. The arrangement that works is recording the small things always and the large things on demand: joint positions, commands, decisions and state changes run continuously, while camera and laser data is captured only during a session you deliberately started. The second trick is a rolling buffer that keeps the last stretch and writes it out only when something goes wrong, so the run before the failure survives without keeping the nine that were fine. Copy files off promptly, delete on a schedule, and check free space before blaming your code.

What should you put in place if the deadline is this month?

Start recording today and fix the rest later, because a fault on disk is one you can work on all month and a fault somebody watched is one you will argue about. On a deadline the sequence matters more than the tooling. First, make recording automatic, so nobody has to remember to start it during the run that finally reproduces the problem. Second, put timestamps and a message identifier into your own log lines, taken at the moment the event happened rather than when the line was printed, because ordering questions are the most common and the hardest to answer after the fact. Third, agree where files go and how they are named, which takes ten minutes and saves the fortnight where three people have three copies of nearly the same run. Only then reach for a viewer, and use whatever is already installed rather than adopting something new. Why does my robot behave differently every run covers the fault class that most often creates this kind of month.

What skill level does a replay workflow assume?

Recording assumes almost nothing, replay assumes you understand your own system, and that gap is where teams stall. Starting a recorder is a single command, and any engineer can do it on their first day. Playing a recording back into your software requires knowing which programs consume which data, what your code does when time jumps backwards, and which parts of the system will refuse to run without hardware attached. That last one catches everyone: the perception code replays happily, the motor driver does not, and now half your system is running and half is waiting for a device that is not there. The way through is to design for it, by keeping a way to substitute a stand-in for anything that talks to hardware, which takes an afternoon and pays back permanently. Reading a recording is the easiest skill and the one people overrate; the picture is legible on day one. Understanding what the picture leaves out is the skill that takes a season.

What do teams try first, and why does saving logs to a file stop working?

Teams first redirect their terminal output into a file, and that stops working the moment the answer depends on two programs at once. The file grows to something no one will read, the lines from different programs are interleaved by whichever happened to flush first rather than by what actually occurred, and the timestamps, if there are any, were taken when the text was written and not when the event happened. So you have a document that appears to prove the command came before the sensor reading when the opposite happened on the robot. The second failure is subtler: writing all that text is work the robot was not doing before, so the timing shifts and the fault moves or disappears. Teams then conclude the fault is intermittent when what changed was the observation. The escape is not a larger file. It is recording the messages themselves rather than sentences about them, stamping events at their source, and carrying an identifier so one item can be followed through the whole system. Why is my robot dropping sensor data is where this lesson usually lands.

What do you give up by committing to a recording workflow?

You give up disk space, some speed of iteration, and a certain innocence about what your data actually shows. Storage is the obvious cost and the one teams underestimate, because sensor recordings grow at a rate nobody's intuition predicts and the first serious consequence is an experiment stopping halfway. The second cost is discipline: recordings only help if they are named, kept and deleted by rules rather than by whoever remembers, and that is process work no engineer enjoys. The third is legal and human rather than technical. A robot in a home or a workplace records people, and a folder of camera data is now something your company is responsible for, with retention rules and access questions attached. The fourth cost is the quiet one. Once replay exists, it is tempting to treat a passing replay as proof, and it is not, which is a specific trap worth naming rather than a general caution. None of this argues against recording. It argues for deciding what you keep before the disk decides for you.

When is ROS 2 the better choice?

ROS 2 is the better choice whenever recording and replay are central to how your team works, and here the gap is not close. The recorder that captures every topic without per-project work, the replay tool that feeds a run back unchanged, the message definitions that make a file readable by someone who has never seen your code, and years of accumulated answers about clock handling during playback all live in the ROS 2 world. If your robot has several sensors and more than two people who need to look at the same run, that ecosystem is a strong argument on its own, before any package is counted. HORUS is not the answer to that question, because a shared-memory layer for a single machine gives programs a way to hand data to each other and does not give you a recorder, a file format or a viewer. The narrow case where the layer underneath becomes worth examining is one onboard computer running Rust, Python and C++ together, where the question is when data arrived rather than what it contained.

Can a replayed run prove your fix works?

No, and here is why. Replay feeds recorded inputs into your software, but the robot's own actions changed the world during the original run, and your fixed code will act differently. The moment your new version steers half a metre left of where the old one went, every camera frame and laser return after that point is wrong, because the recording holds what the sensors saw from the old path. The replay keeps running and keeps looking convincing, which is the dangerous part. What replay genuinely proves is narrower and still valuable: that a specific component, given a specific input, produces a different and better output than before. Perception is the clean case, since a detector fed the same image should improve or not regardless of what the robot did next. Anything that steers, plans or closes a loop around the world needs the world back in the loop, which means simulation or hardware. What to do when simulation and hardware disagree covers what happens when you take the next step.

Does recording everything keep you covered?

Partly, but not the way you think. Recording every topic does mean the data was captured, and teams reasonably feel safer for it, but capture is only the first of three things you needed and the other two are usually missing. The second is finding: a run you cannot locate a fortnight later, among four hundred files named by timestamp, is functionally not recorded. The third is meaning: raw messages tell you what arrived, not what your code believed, so the recording shows the robot turning without any trace of the reason. Teams that record everything and log nothing end up staring at a complete account of a decision whose logic is absent. The practical shape is the opposite of the instinct. Record less, deliberately, with the large data captured only in sessions. Log more, in a shape a machine can sort. Name and store runs so a person who was not there can find the one that matters. Completeness is not coverage.

How should your team decide what to record?

Decide by asking what question each recording is meant to answer, then keep only what answers one. Three questions cover most teams. Did the robot receive what we think it received, which needs the sensor and command messages. Did the code decide what we think it decided, which needs your own log lines with timestamps and identifiers and cannot come from the messages alone. Did this build get worse than the last one, which needs a small reference set of clean runs kept permanently and replayed on purpose. Anything that answers none of those three is a candidate for deletion, and saying that out loud is what keeps the disk usable. The order to build in is equally practical: automatic recording first, log structure second, storage and naming third, a viewer fourth, and a hosted place for files when carrying them by hand starts costing real time. What happens when a robot program crashes mid-motion is a good test of whether your current setup would tell you anything.

If you are one engineer on one robot -> ros2 bag plus timestamped logs, because the whole cost is a command and a habit.

If you are a team of three or more -> add Foxglove and one shared location, because the run that matters is never on your machine.

If you are outside ROS 2 entirely -> MCAP written from your own code, or Rerun, because portable files matter more than the recorder.

If you are running a fleet -> hosted run storage with retention rules, because hand-copying becomes a job nobody was hired for.

If you are on a small board -> continuous small data plus on-demand large data, because a full card ends the experiment.

The HORUS Fit Framework is the shorter way to sanity-check any of these before committing: ecosystem size, setup effort, team size fit, deployment target, and licence. Recording tools sit almost entirely on the first two axes, which is why ROS 2 wins this category so often. If the layer beneath your tools is what keeps producing unexplained runs, HORUS is on GitHub under Apache-2.0 at github.com/softmata/horus, and it is worth a look on its own terms rather than as a logging answer. Star it so it is in your list when you start building.