datadensity

A data layer for AI 🤖 built by real people, grounded in real-world behavior.

[datadensity @datadensityxyz]

More data is not always better data.

A team can record hundreds of hours on a factory floor and still produce a dataset with limited training value because recordings may contain broken sensor streams, incomplete tasks, corrupted timestamps, or repeated conditions.

Recorded hours only show how long the system was running. The useful measures are:

- Episodes that pass quality control
- Coverage across tasks, objects, environments, and edge cases
- Gaps that require further collection
- New variation added with each recording cycle

Quality control determines what enters the dataset and guides what should be collected next: Recorded hours → Quality control → Accepted episodes → Coverage analysis

Once a routine motion is sufficiently represented, another hundred similar episodes may add less value than a smaller batch covering a new object, operator, environment, or failure condition.

The goal is to collect the data needed to achieve useful coverage, not maximise recorded hours.

[datadensity @datadensityxyz]

A recorded episode can be technically sound and still be unusable for training. It can also capture a failed task and be exactly what the model needs.

This is why dataset quality is a routing problem, not a pass-or-fail check.

First, check the recording:
- Are the required files present?
- Are the sensor streams complete and synchronized?
- Are the relevant actions visible?
- Is the calibration valid?

If the recording passes, check whether it captures the intended task, variation, or failure mode.

The episode can then be routed to:
(i) Accept: It meets the requirements and captures the intended behaviour.
(ii) Human review: Its task boundary, outcome, or failure type is unclear.
(iii) Repurpose: It does not fit the original training objective but may support perception, failure analysis, or evaluation.
(iv) Reject: Recording errors make it unreliable.

A failed task may be accepted because it clearly captures the error and recovery, while a successful task may be rejected because frames are missing, streams are out of sync, or the contact point is occluded.

TL;DR: Quality control should determine what an episode is usable for, not simply whether it passes or fails.

[datadensity @datadensityxyz]

What if a camera gets moved slightly and the contact point disappears? What if two sensors slowly drift out of sync?

The same instruction gets interpreted three different ways.

None of these necessarily stops the recording but that’s what makes them difficult to catch.

You can come back with hours of apparently valid data and only discover later that the conditions changed halfway through collection.

Before scaling, we test for things like:

- camera placement and occlusion
- synchronization across sensor streams
- consistent starting states and resets
- differences between operators
- changes in the actual working environment

A small field pilot gives you a chance to find these problems while changing the protocol is still cheap.

So, how much of the collection setup has actually been tested where the data will be recorded?

Find what breaks first. Then scale the collection.

[datadensity @datadensityxyz]

A request for 1,000 hours of robotics data is incomplete unless you know what those 1,000 hours need to contain.

Recorded hours measure collection volume but they don't tell you how the data is distributed across the conditions a model needs to learn.

Before scaling a collection, we look at:

- whether the data passes the required quality checks
- which tasks, objects, environments, and states are covered
- whether failures and recovery paths are represented
- where the dataset is becoming repetitive
- which conditions are still underrepresented

A recording can pass every technical check and still add little because the dataset already contains enough examples of that behaviour. A failed attempt can do the opposite.

But if the recording is valid and the failure exposes a missing state or recovery path, it may be exactly the data the model needs.

We define the quality requirements and target coverage before collection, test them during a pilot, and track both as the dataset grows.

[datadensity @datadensityxyz]

A robot makes contact at the wrong angle, retries, and completes the task. Is that a success or a failure?

For failure analysis and recovery learning, the useful unit is the sequence of states and actions:

Initial state → Action → Deviation → Failure state → Recovery attempt → Final outcome

The robot may approach correctly, detect resistance, withdraw, adjust the angle, and succeed on its second attempt.

(i) A success label preserves the result but hides the recovery.
(ii) A failure label preserves the mistake but ignores the correction.

The episode needs a richer structure that records:

- the state before the error
- the action that caused it
- where execution deviated
- the resulting failure state
- the recovery attempt and action
- the final outcome

This also separates failures with similar outcomes but different causes.

An incorrect pose estimate, collision, or unstable placement may all prevent completion, but each points to a different model gap and requires different data.

A failed task can still be valuable training data, while a recording with missing frames, broken synchronization, or an occluded contact point may be unusable regardless of the outcome.

TL;DR: Failure demonstrations are useful when the dataset preserves what failed, when it failed, and what happened next.

[datadensity @datadensityxyz]

https://t.co/gBqXPEE8iZ

[NVIDIA @nvidia]

Physical AI is here—the next wave of AI and the foundation of the next industrial revolution.

NVIDIA founder and CEO Jensen Huang outlines the full stack making it possible: Cosmos and Omniverse to develop physical AI in virtual worlds, Isaac and Newton where robots learn skills in physics-simulated gyms, and Jetson robotics computers where their intelligence runs.

Together with Japan’s robotics and manufacturing leaders, NVIDIA is creating a new era of industrial automation.