A robot data factory is not a facility that merely stores large volumes of video. It captures synchronized episodes from real robots and human demonstrations, verifies the right to use them, separates training from evaluation, deploys only validated models and brings field failures back into the pipeline. The defining capability is traceability: teams must be able to show which failure changed which model and why.
It becomes a factory only when data returns to improve field behavior
In an August 2026 announcement, LG Electronics said it was building a Data Factory at its Yangjae R&D campus in Seoul, with full operation targeted by year-end. The facility includes training spaces that reproduce homes and manufacturing sites, plus areas for logistics automation and robot-hand data collection. According to the official LG–NVIDIA robotics announcement, LG plans to augment and synthesize the collected data with NVIDIA's robotics stack and use it to improve its Robot Foundation Model.
Read the disclosed scale as a distinction between current state and target. The facility was described as 1 basement level and 3 above-ground levels totaling 10,000㎡, with several hundred robots planned by year-end. LG's estimate of 100,000 hours—about 12 years—combines direct collection with synthetic and augmented data; it is a target, not an achieved result.
SEER Robotics also described a data system in its 2026 strategy announcement that connects real-robot collection, multi-source collection, governance, training, simulation evaluation and capability feedback. The shared idea is that data cannot end as inventory; it must return as measurable robot capability.
| Stage | Evidence to preserve | What breaks when it is missing |
|---|---|---|
| Collection | Sensor, action, human intervention and task outcome on one clock | Cause and outcome cannot be connected |
| Curation and governance | Quality decision, ownership, consent, retention and deletion history | Training eligibility and accountability are unclear |
| Training and evaluation | Data, code and model lineage plus a held-out test set | Leakage inflates performance or reproduction fails |
| Release and feedback | Approval, canary, field metrics, rollback and failure recollection | A bad update can spread across the fleet |
The useful collection unit is a task episode, not a camera file
A video of a cup entering a shelf does not reveal what the robot perceived or how much force it applied. A task episode should align RGB, depth, tactile signals, joint position and velocity, force and torque, commands, battery state, teleoperation, safety stops and final outcome on one timeline. Each task also needs fixed start conditions and definitions for success, partial success, failure and abort.
A success-only dataset cannot teach the warning signs before failure. Label slip on a wet handle, partial occlusion, communication delay, a person entering the work zone and why a remote operator intervened. 100 distinct failures can reveal a clearer improvement path than 10,000 repetitions of the same normal scene.
When reporting collection in hours, separate time spent acting from waiting and resetting, and report duplicate-frame share. “100,000 hours” describes quantity; it does not automatically prove task diversity or useful-data yield.
Collection design must also define what not to retain. Keeping every raw camera stream indefinitely can increase cost and privacy exposure without improving a model. Separate incident-analysis originals, curated training copies and operational summaries by retention period, quarantine episodes that fail quality gates, and require an explicit approval before quarantined data can change state.
Without clock alignment, the pipeline loses the cause of contact failure
Robot sensors run at different rates. A camera may run at 30Hz, joint state at hundreds of Hz and tactile events faster still, while teleoperation commands add network delay. Without a shared clock and latency metadata, a log can reverse whether force was reduced after a cup slipped or whether reducing force caused the slip.
Preserve original timestamps and create resampling or interpolation as a separate derived version. Bind sensor calibration, firmware and robot identity to the episode so the same record can be replayed later. Missing frames and clock jumps should create quality flags, not silent repairs.
Label definitions are an engineering decision too. If one team marks success when the object enters a target region and another waits until the hand withdraws safely, the same task produces different metrics. Operations and learning teams should jointly approve completion criteria so field KPIs and model evaluation remain aligned.
Governance defines whether customer data can enter a model at all
Robots can capture factory equipment, worker faces, home layouts and product defects in the same stream. Buying a robot does not automatically give a customer every right to originals, derivatives and trained models; nor does it let a supplier reuse every log for other customers. Contracts and technical controls must agree before collection starts.
A rights matrix should state who owns originals, which training and evaluation purposes are allowed, whether data may be shared with a third party or transferred abroad, retention and deletion procedures, and ownership of derivative models. Minimize and pseudonymize human imagery, control access, and preserve lineage so a deletion request can find downstream datasets.
Scope access by role and task rather than a broad folder. If one account can view raw video, edit labels, approve training and approve deployment, mistakes and insider misuse become hard to trace. Audit every change with user, time, reason and prior value.
Test deletion rather than leaving it as policy text. An episode ID tied to a worker or customer site should be discoverable in originals, replicas, labels and candidate training sets and removed through the defined process. Data deletion and model retirement are not always the same action; contractual and risk analysis must define the response, including backup expiry and re-deletion after recovery.
Synthetic data is most valuable where real collection is rare or unsafe
The official NVIDIA Cosmos page presents tools for curating, annotating and deduplicating sensor data, along with world-foundation-model synthetic data and training and evaluation frameworks. Synthetic generation can expand nighttime, bad weather, partial occlusion and near-collision conditions that are rare or dangerous to repeat in reality.
Physical plausibility in a synthetic video does not mean the scene reproduces real sensing and contact. Reflective and transparent materials, motor backlash, camera noise and unpredictable human behavior may differ. Evaluate on withheld real-robot data, and vary the synthetic-data share to see which failures improve and which get worse.
Keep provenance tags. If real, teleoperated, simulated and generated episodes lose their source labels, teams cannot tell what drove a gain or which bias produced a new failure.
Split by scene and episode to keep near-duplicates out of evaluation
Robot data often comes from continuous recording, so a random frame split can place nearly identical scenes in both training and evaluation. Dividing adjacent episodes from the same home, object and operator can make memorization look like generalization. Split by task, location, robot, date and object group.
Control access to the held-out set so model developers cannot repeatedly tune against it. Before release, move through lab evaluation, field shadow mode and a limited canary fleet. Track worst task performance, intervention rate, near-collision stops, recovery time and regressions against the previous model—not just mean success.
An old test set can miss field change, but adding every new failure immediately and tuning on it recreates leakage. Separate operational cases used for diagnosis from candidates for the next evaluation release. Freeze the change date and rationale, rerun the prior model, and keep performance by task and environment so one customer's decline is not hidden by the average.
| Validation question | Passing evidence | Stop or rework signal |
|---|---|---|
| Is evaluation leakage absent? | Split lists and duplicate checks by site, task and robot | One continuous recording appears in training and evaluation |
| Did the model reduce real failures? | Repeated comparison with the prior model under the same conditions | Mean rises while the worst safety-relevant task declines |
| Is data use authorized? | Consent, contract and retention policy per episode | No provenance or deletion path can be found |
| Can deployment be reversed? | Model lineage, canary evidence and rehearsed automatic rollback | The training data behind a model is unknown |
A release gate matters more than an automatic retraining loop
A pipeline that retrains on incoming field logs and updates every robot immediately is fast but unsafe. Mislabeling, a failed sensor or poisoned data can spread into fleet behavior. Automated collection and training still require a separate release gate.
A model registry should link data version, code and environment, evaluation results, approver and target robots. Start on equipment with low traffic and easy recovery, comparing intervention, task time, safety stops and hardware temperature with the previous version. Rehearse disabling the new model and returning to a validated one when thresholds trip.
Not every field log belongs in training. Separate sensor failure, operator error and process changes that a policy cannot solve. The objective is not to consume the most logs; it is to select the logs that support a defined improvement.
Prove lineage on 100 episodes before buying the large-scale stack
Choose one task and one robot before purchasing a massive repository. Collect 100 sample episodes and verify that video, joints, force and intervention replay on the same timeline, then trace one record from collection through deletion. Create a held-out set with intentionally introduced failures and deploy a small model to one canary robot.
Robot tactile sensors, teleoperation data and imitation versus reinforcement learning provide deeper context for signals, demonstrations and learning choices.
Do not manage the program by total hours alone. Review valid-episode yield, task and environment diversity, failure and intervention distribution, rights-clearance rate, evaluation leakage and rollback time by model. Only connected measures turn a file pile into a compounding capability asset.
Budget beyond storage and GPUs: label review, field reset, sensor calibration, privacy processing, export approval and failure reproduction all matter. Rare failures can cost more to reproduce safely than abundant normal scenes. If the team cannot connect a dataset slice to a field KPI, increasing scale will make waste harder to identify.
Frequently asked questions
Does a large robot-video archive qualify as a robot data factory?
No. Video must align with state, action and human intervention, and the system must also govern rights, quality, held-out evaluation, deployment and failure feedback. Video alone rarely reproduces why an action occurred.
Can synthetic data replace real-robot evaluation?
No. It can expand rare conditions, but real sensors, contact and hardware variation remain. Evaluate with real-robot episodes excluded from synthesis and a limited field rollout.
Who owns the field data collected by a deployed robot?
The contract decides. It should address originals, derivatives, models, learning use, third-party sharing, cross-border transfer and deletion separately, with privacy and trade-secret controls.
Official sources checked
- Official LG Electronics–NVIDIA robotics collaboration announcement
- SEER Robotics WRC 2026 strategy announcement
- Official NVIDIA Cosmos page
Last checked: August 23, 2026