humanoidsdata.com

Search

Search companies, datasets, articles, and glossary terms for humanoids and embodied AI.

← All glossary terms

Data & collection

Trajectory augmentation

Trajectory augmentation is the creation of additional robot trajectories by transforming, replaying, generating, or re-executing existing trajectories under changed conditions while preserving defined task semantics. Useful augmented trajectories are validated for feasibility and outcome rather than accepted solely because their coordinates were transformed.

Also known as: trajectory data augmentation, demonstration augmentation

Updated

Augmentation changes a known trajectory

A robot trajectory is a time-ordered sequence, not an independent image. Augmentation must therefore preserve temporal structure and task meaning while changing something useful: object pose, scene layout, timing, body posture, viewpoint, noise, or another controlled condition.

MimicGen transforms object-centric segments from human demonstrations into new scene configurations, executes the resulting attempts, and retains successful demonstrations. The method illustrates the crucial distinction between a proposed trajectory and a validated rollout. A coordinate transform alone does not show that the robot can complete the task.

Execution can be the filter and the generator

InterMimicGen applies small object and body edits around verified human-object interactions. Its tracker learns from the proposals, executes them under simulated physics, and stores successful rollouts as parents for later rounds. The policy is therefore part of the data generator: a fixed tracker eventually stops accepting variations beyond its existing competence.

This is not the same as inventing new tasks. The paper holds the interaction type, intended contacts, object, and outcome fixed. The augmented set broadens how a known task is realized, while new task semantics still require new demonstrations, goals, or generation rules.

Lineage makes augmented data auditable

Augmented trajectories are correlated with their seeds. Counting every child as an independent demonstration can exaggerate behavioural diversity and hide repeated errors. A release should preserve the source trajectory, transformation parameters, parent-child graph, generator or policy version, simulator and robot configuration, random seed, validation checks, rejection reason, and task outcome.

Evaluation should also split by source lineage. If children of one seed appear in both training and test sets, the result may measure interpolation around that seed rather than generalization to a new task, object, operator, or environment.

Sources