A Rental Demo Recording and a Compatible Live Connection Are Different Evidence

When a rented robot returns after a job, two very different kinds of evidence might be offered to explain what happened on the shop floor. One is a stored recording of topic data, captured during an earlier session and replayed on demand. The other is a live physical connection, where a real machine publishes or subscribes to a real network in real time. Treating these two things as interchangeable is a persistent misunderstanding in robot rental handovers, and it can create friction between the parties about what was actually demonstrated, what was merely stored, and what still remains unknown. This article sets out the distinction in plain terms, using a handover glossary that flags explicit unknowns rather than filling them with assumptions.

What a Stored Recording Actually Contains

The ROS 2 rosbag2 tutorial describes recording topic data and replaying saved messages. The interpretation depends on what was recorded and what question is being asked. A recording can contain useful observations, but replaying it does not itself establish the rented machine’s current condition. Separate the original capture, the later playback and any present-hardware claim instead of treating them as one event.

From an editorial perspective, a careful way to describe a recording in a handover document is as "a replayable archive of past topic traffic." That phrasing keeps the focus on what the file contains and avoids treating it as a substitute for a physical demonstration. If the renter wants evidence that the machine can still perform a task, a live run — or at minimum a documented test protocol — is needed. The recording can support that narrative, but it cannot replace it.

What a Live Connection Actually Requires

The ROS 2 QoS documentation distinguishes requested and offered policies and explains compatibility conditions for publisher/subscription connections. Matching topic names alone does not establish those conditions. A review should identify the relevant policies and observed communication before drawing a connection-related conclusion. Even verified message exchange is not, by itself, evidence about every function of a rented robot.

For a rental handover, this creates a practical question: has the compatibility of requested and offered policies been verified on the actual hardware and network that will be used? A configuration file that looks correct in a repository is not the same as a verified live connection. The handover glossary should therefore distinguish between "documented QoS settings" and "verified live compatibility," and should mark the latter as unknown until a test has been performed and recorded.

Building the Handover Glossary: Known, Documented, and Unknown

A useful handover glossary for rented robots separates three categories of information. The first is known and verified: something that has been observed during a live test, with the test conditions recorded. The second is documented but not verified: a configuration file, a design intention, or a recording that exists but has not been exercised on the current hardware. The third is explicitly unknown: a gap where no information exists, and where the parties should agree on whether further investigation is needed before the next job begins.

The verification label should attach to a claim, not permanently to a file type. A recording may support a verified statement about a past observation while leaving present-condition questions unresolved. A connection test may support a statement about the communication examined without settling mechanical condition. The glossary can record the question, available evidence and remaining gap so that one successful check is not reused to answer unrelated questions.

For related explanations, this site’s technical category and article archive provide reading routes. They are not the rental project’s test logs or recording store. The actual handover should identify its own captures and communication observations, keeping playback evidence and current-condition evidence distinguishable.

Common Misconceptions and How to Address Them

One common misconception is that a successful replay proves the machine is in working order. As noted above, a replay only proves that the recorded data can be read back. It does not prove that the motors, sensors, or network interfaces are functioning correctly at the time of return. Another misconception is that matching topic names are sufficient for communication. The QoS facts make clear that requested and offered policies must be compatible, and that a name match alone is not evidence of compatibility.

A third misconception is that a recording can serve as a contractual deliverable in place of a live demonstration. Editorial reasoning suggests caution here. A recording is a useful artifact, but it is an artifact of the past. If the rental agreement requires evidence of current capability, the handover should include a live test or a clear statement that such a test has not been performed and that the parties accept the associated uncertainty.

In a hypothetical handover discussion, one party presents a playback while the other asks about current communication. The record can state what the playback demonstrated and separately identify what evidence about current communication is available. If that evidence is missing, the question remains open. This example does not report a rental incident or instruct anyone to operate hardware; it shows how to avoid filling an evidentiary gap with an unrelated demonstration.

Questions to Ask Before the Next Job

When a rented robot changes hands or moves to a new task, the following questions help surface the distinction between replayable data and live compatibility. Has a live connection been verified between the relevant publishers and subscribers, using the actual hardware and network for the upcoming job? Are the QoS policies requested by each subscriber compatible with those offered by each publisher, and has this been confirmed rather than assumed? Does the handover glossary clearly label recordings as replayable archives rather than live evidence? Are there any QoS mismatches that were observed but not resolved, and if so, what is the agreed mitigation?

These questions do not require any particular technical depth to ask, but they do require discipline to answer honestly. An honest "unknown" is more useful than a confident "yes" that rests on a replay. The handover glossary exists to make that honesty structurally easy, so that both parties can see the same map of what is known, what is documented, and what remains to be checked.

Keeping the Distinction Visible Over Time

As a rented robot passes through multiple jobs and multiple users, the distinction between recordings and live connections can blur. Old recordings accumulate in the archive, and it becomes tempting to treat the archive as a substitute for fresh testing. Editorial practice suggests periodic review: before each new job, the handover glossary should be updated to reflect what has been verified in the current session, what remains from earlier sessions, and what has never been tested at all.

This approach does not guarantee that every issue will be identified. It makes the scope of each check visible. A recording is not inherently unverified, and a live check is not inherently comprehensive: each needs to be assessed against the particular claim it is used to support. Keeping that scope explicit is the purpose of the handover glossary.