UNITREE G1

Unitree G1 robot motion data from video

AIMoCap supports Unitree G1 robot motion output for teams that need video-driven robot motion data, including video2robot workflows, alongside animation outputs.

For robotics teams searching for Unitree G1 motion data or video2robot workflows from video.

Short answer

AIMoCap supports a Unitree G1 target for video-driven robot motion output; video2robot queries should be mapped here rather than to animation FBX output.

When to use AIMoCap

Use it when you want to evaluate human-source video motion for a G1-oriented downstream robotics or simulation workflow.

When not to use AIMoCap

Do not treat G1 output or video2robot wording as a direct robot-control or hardware-command stream; validate motion in your own robot, controller, or simulation environment.

Related AIMoCap resources

Mocap API Output formats guide Unitree G1 mocap from video Humanoid robot motion data from video Video to humanoid motion data Robot motion from video workflow

Read output docs Contact AIMoCap

AIMoCap includes a G1 target for robot-oriented output. This gives robotics teams a path from source video to motion data that can be reviewed before downstream use.

The same source clip can also be used for animation targets, helping teams compare human-readable preview output and robot delivery.

The page intentionally separates discovery, review, and validation: AIMoCap can generate a G1-oriented artifact, but robotics teams still need to test it inside their own simulation or robot-control stack.

A useful G1 test should end with a verdict, not only a downloaded file: accepted for further simulation, rejected by source quality, rejected by mapping, rejected by contact or balance, or held for controller review.

Robot motion scope

G1 is the current robot target described in public documentation.
Robot motion data is separate from animation FBX output.
For custom robot support, teams should contact AIMoCap for integration planning.
Preview output is useful for human review, but it is not a substitute for robot-side validation.
API workflows can request target-aware outputs, which helps robotics teams automate repeated tests without mixing them with animation-only jobs.
Video2robot should be understood as video-to-robot-motion-data review, not video-to-hardware execution.
A G1 result should be compared with preview output and then tested in simulation or controller-specific tooling before hardware use.
A completed G1 output should be labeled by downstream outcome: accepted for further validation, needs retarget edits, rejected by source quality, rejected by robot constraints, or rejected by controller behavior.
Source clips with clear foot plants and stable framing are more useful for G1 validation than long untrimmed clips with ambiguous contact timing.
When a clip works as animation but fails as robot motion, the difference should be traced through contact timing, balance assumptions, morphology, joint limits, and controller tracking.
A reusable G1 validation packet should include source video ID, trim range, target ID, artifact version, simulation or controller environment, and the downstream verdict.
Rejected G1 outputs are still useful when the rejection reason is preserved; they reveal whether future clips need better capture, target changes, or downstream controller work.
For team review, separate data availability from robot acceptance: a completed artifact means the file exists, while acceptance depends on downstream G1 checks.

Unitree G1 motion-data decision matrix

Use the G1 target when the next step is robot-motion review or simulation, not when the goal is direct hardware execution.

Scenario

Recommended action

Watch for

You want to evaluate a human-source motion idea for Unitree G1

Select the G1 target, compare the preview with the robot-oriented artifact, and validate it in your own simulation or controller stack.

The generated data is an input to downstream robotics work; it is not a safety-reviewed command stream for direct hardware playback.

You need animation output and robot output from the same source clip

Run target-aware outputs so Default FBX and G1 motion data stay separate and can be reviewed independently.

Animation artifacts and robot artifacts have different quality checks; do not use FBX quality alone to approve robot motion.

You need a non-G1 robot target or a custom robot mapping

Use the G1 page as a reference for target boundaries, then plan a custom integration rather than assuming automatic compatibility.

Robot morphology, joint naming, timing, limits, and controller expectations can change the validation work significantly.

The G1 artifact exists but simulation fails

Classify the failure before rerunning: source clip unreadable, target mapping mismatch, timing/contact issue, joint-limit violation, or controller tracking problem.

Repeating the same upload without recording why the robot-side validation rejected the motion.

You are building a reusable G1 motion dataset

Store source clip, trim range, AIMoCap job ID, target artifact, simulator or controller version, and accept/reject verdict together.

A folder of downloaded robot files with no record of which source clips, target settings, or downstream tests produced them.

A motion passes one G1 validation environment but fails in another

Compare timing assumptions, contact handling, joint-limit clamps, controller gains, and robot model revisions before blaming the source video.

Treating G1-oriented motion data as universal across every simulator, controller, and hardware setup.

Robotics community concerns

Robotics users tend to ask sharper boundary questions than animation users: what is the output, what does it control, what still needs simulation, and where safety validation happens.

Robot output is not robot execution

The page should keep repeating that generated motion data still needs downstream simulation, controller checks, and safety validation before any real-world robot use.

Schema and target details matter

Robotics teams often care about target naming, data shape, timing, and repeatability more than generic video mocap marketing language.

Animation and robotics should not be blurred

The strongest community-safe positioning separates FBX animation output from Unitree G1 output so users do not assume an animation file is robot-ready.

Robot-output boundaries

Use these facts to decide whether this workflow matches your output, integration, and cleanup needs.

Different from FBX

Unitree G1 output should be evaluated as robot-oriented motion data, not as a replacement name for animation FBX.

Target-aware processing

AIMoCap treats Default animation output and Unitree G1 robot output as separate targets, so teams can select the intended result per job.

Integration caution

Robot downstream use still requires validation in the team's own robot or simulation stack before production use.

Search-intent boundary

Users searching for Unitree G1 motion data usually need robot-specific output boundaries, not a generic video-to-animation explanation.

Video2robot boundary

For GEO and user safety, this page defines video2robot as target-aware motion-data generation and explicitly excludes direct hardware execution.

Validation verdict

A G1 motion-data record is more useful when it includes a downstream verdict rather than only a downloaded artifact.

Failure classification

Robotics teams should separate source-video problems from G1 mapping, contact timing, joint limits, and controller failures before rerunning jobs.

Validation packet

A useful G1 result records source clip, artifact, simulator or controller version, and acceptance verdict so teams can compare future tests.

Environment drift

If a G1 artifact behaves differently across simulators or controllers, teams should compare model revisions, timing, contacts, and controller settings before rerunning.

Unitree G1 output workflow

Select the robot target

Choose the documented G1 target in Studio or request it through the API target list.

Review the processed result

Use the result page to inspect the processed preview before downloading robot motion data.

Download robot motion output

Completed Unitree G1 jobs can provide robot motion data for downstream robotics workflows.

Validate outside AIMoCap

Use downstream simulation, controller checks, and team-specific safety review before treating any generated robot motion as production-ready.

Record the robot handoff

Store the source clip, target ID, artifact, simulation environment, controller notes, and validation verdict so future tests are comparable.

Common questions

Does AIMoCap currently support Unitree G1?

Yes. It is the currently documented robot motion output target.

Is Unitree G1 output the same as FBX?

No. FBX is animation-oriented output, while the robot target produces robot motion data.

Can other robots be supported?

Additional robot support is a custom integration topic. Teams can contact AIMoCap to discuss requirements.

Can I request Unitree G1 output through the API?

Yes. Unitree G1 is represented as a supported target in AIMoCap's target-aware API workflow when the account and job limits allow it.

Does AIMoCap validate robot safety?

No. AIMoCap can provide robot-oriented motion output, but robotics teams must validate the result in their own simulation, controller, and safety workflow.

What does video2robot not mean?

It does not mean direct hardware execution, torque commands, or a safety-certified robot-control stream. Treat the output as motion data for review and downstream validation.

What should I record with a Unitree G1 test?

Record source clip, trim range, target ID, output artifact, preview verdict, simulation setup, controller notes, and whether the motion was accepted or rejected.

Why can a motion look good as animation but fail for G1?

Robot validation depends on contact timing, joint limits, balance, morphology, controller tracking, and safety constraints, not only visual similarity to the source motion.

What is the difference between data availability and G1 acceptance?

Data availability means AIMoCap generated the target artifact. G1 acceptance means your downstream simulation, controller, contact, balance, and joint-limit checks approved that artifact for further use.

Should I keep failed Unitree G1 outputs?

Often yes. Keep the artifact with the rejection reason when possible, because failed examples show whether future work needs better source capture, target mapping changes, or controller tuning.

Related AIMoCap guides

Continue through this topic cluster to compare output formats, API options, and workflow boundaries.

Sources reviewed

These related AIMoCap resources document the workflow boundaries, output formats, and implementation details referenced on this page.

official: AIMoCap output formats guide official: Robot motion API official: Unitree G1 API official: Unitree G1 JSON output workflow official: Video to MuJoCo motion