ROBOT MOTION API
Use target-aware AIMoCap API jobs when your integration needs robot motion output such as Unitree G1.
For robotics teams searching for an API that can produce robot motion data from video.
A robot motion API should turn source video into target-aware motion artifacts that can be reviewed, downloaded, and validated in a robotics pipeline.
Use AIMoCap when your integration needs an async video mocap job that can request a robot-oriented target such as Unitree G1 alongside animation review outputs.
Do not treat generated robot motion as a direct hardware control command; validate it in your simulation, retargeting, or robot control stack before any physical deployment.
Robotics teams often need motion data that starts from human video but ends in a target-specific format rather than a generic animation clip.
AIMoCap exposes this through the same async API lifecycle as other mocap jobs, while keeping robot-oriented output separate from browser-only Studio credits and manual workflows.
The practical benefit is not just an upload endpoint. It is the ability to request supported targets, poll job state, and download artifacts that downstream robotics tools can inspect before use.
A robot-motion API page should be explicit about the handoff. AIMoCap can provide target-aware motion data, while simulation, controller limits, balance checks, and hardware safety remain outside the API response.
Use this matrix to separate API success from robotics acceptance, because a completed robot-motion artifact still needs simulation, controller, contact, and target-validation evidence.
Robot API users need the page to separate generated motion data from hardware control, because robotics failures are often safety and validation failures, not just API failures.
A robot motion API should return artifacts for simulation, conversion, or controller review; it should not imply torque commands or direct hardware execution.
Clients should track whether a robot artifact passed simulation, contact review, controller limits, and safety checks before it is considered useful.
The integration should request the documented robot target it actually needs and reject unsupported robot bodies as custom integration work.
Use these facts to decide whether this workflow matches your output, integration, and cleanup needs.
A robot motion integration should request the robot target explicitly instead of assuming that any animation file can be used as a robot motion artifact.
The API result is useful for robotics data and validation workflows, but physical robot execution remains the responsibility of the downstream control stack.
Because API v-credit is separate from web credit, automated robotics pipelines can track usage without mixing it with Studio mocap jobs.
A robot-motion API integration should record whether each artifact passed simulation and controller review, not only whether it was downloaded.
Robotics teams need failure categories because bad source video, target mismatch, contact instability, and controller limits require different fixes.
A robot-motion product should separate API completion from robot validation so users know whether a file is merely available or actually accepted downstream.
Accepted and rejected robot-motion attempts can become training data for capture guidelines, validation rules, and future integration priorities.
Create a mocap API job with the supported target IDs your integration needs. For robot motion workflows, Unitree G1 is the public robot-oriented target to request.
Upload the source video to the returned upload URL and call complete-upload. AIMoCap verifies the source, applies account limits, and queues the job without requiring a blocking API call.
After completion, download the available preview and target artifacts. Robot motion output should be checked in simulation, retargeting review, or the downstream control environment.
Keep the job ID, source clip, target, artifact, simulation result, controller notes, and rejection reason so repeated robot tests become comparable.
Treat API completion as artifact readiness, then let a downstream validation service decide whether the motion passed contact, balance, joint-limit, and controller checks.
If your product exposes robot-motion results, show separate states for uploaded, processing, artifact ready, validation passed, validation rejected, and needs review.
Yes, for supported robot-oriented targets. The current public robot target is Unitree G1, requested through the async mocap API job workflow.
No. FBX is animation-oriented, while robot motion output is target-aware and intended for downstream robotics validation or conversion workflows.
Yes, clients can request supported target IDs together when they need both animation review output and robot-oriented output from the same source video.
No. AIMoCap provides processed motion artifacts. Robotics teams should validate and adapt those artifacts in their own simulation, retargeting, and control systems.
Robot motion API jobs use API v-credit, which is tracked separately from web Studio credits and should appear as API usage in account ledgers.
A completed API job only proves the artifact exists. Acceptance should depend on downstream simulation, joint limits, contact behavior, controller tracking, and safety review.
Log source clip, target ID, artifact URL, timing assumptions, simulation environment, controller version, validation result, and reason for accepting or rejecting the motion.
No. Show completed as artifact-ready, then use a separate downstream validation status for robot acceptance, rejection, or manual review.
Separate upload validation, AIMoCap processing, artifact availability, target mapping, simulation failure, controller tracking, and manual safety review instead of using one generic failure label.
Continue through this topic cluster to compare output formats, API options, and workflow boundaries.
Async job creation, upload, polling, and downloads.
Use output, limits, and accounting to evaluate fit.
Compare animation, preview, and robot artifacts.
Build async video mocap jobs with upload, polling, and downloadable motion outputs through the AIMoCap API.
Use AIMoCap API jobs to request Default output and download animation-ready FBX motion after processing.
Create AIMoCap video-to-FBX API jobs, upload source clips, poll status, and download outputs when processing completes.
These related AIMoCap resources document the workflow boundaries, output formats, and implementation details referenced on this page.
