More robot activity is not automatically useful robot data

Our recording kept the arm's numerical state after its final action. It did not keep an image after that action.

The run could still succeed at its task. But a consumer needing to see the final scene would be missing an input. Exporting the recording into a standard dataset could not recover an image we had never captured.

That is a concrete limit on the idea that more robot use will automatically produce useful learning data. The question is useful to whom, for which decision, with which evidence?

Four different kinds of success

Question	What it establishes
Did the task succeed?	The evaluator's outcome for that attempt.
Is the evidence intact?	Whether retained channels can be inspected without silently changing the source.
Does it help explain the run?	Whether it answers a particular diagnostic question.
Can a downstream consumer use it?	Whether channels, timing, rights and format meet that consumer's requirements.

A failed attempt may be useful for diagnosis. An intact successful one may be unsuitable for a learner. Keeping a capture is also different from consenting to its use in a dataset.

A command is not a measurement

In the October 11 simulation export, the standard dataset paired pre-action images and measured joint state with the executed action's joint targets in radians. The targets were commands. They were not measurements of where the joints ended up.

A separate Roboty companion retained original indices, simulation and host clocks, requested and accepted actions, executed targets, after-action numerical state and outcomes. Its reader verified the content hash and mapped those channels to dataset rows. An ordinary LeRobot reader did not automatically interpret the companion.

The final numerical state existed there. The missing final image did not. This was a limitation of our capture, not an inherent restriction of LeRobot's format.

Regular timestamps do not make new observations

The exporter used LeRobot 0.6.1 and dataset format v3.0. It checked consecutive simulation times against the requested cadence within 5 milliseconds and refused captures outside that tolerance.

It wrote each sample in a selected contiguous segment once, with dataset time calculated as frame_index / fps. It did not interpolate, duplicate or drop observations to repair timing. Regular row timestamps did not describe host wall time. A consumer needing the original clocks had to read them explicitly.

The selected official writer/reader checks established format behavior across channels, timing, ranges and episode boundaries. They did not demonstrate improved diagnosis or training. Physical captures were outside this simulation consumer.

More participation could reveal confusing workflows and reusable methods even before it produces learning data. The data branch needs its own design and evaluation. Define the consumer first, then ask what must be recorded. A success message and a saved file cannot answer that for us.

For current formats and recording limits, see Robotics tools and your data. This article describes the historical simulation export.