VLA Models & Embodied AI: A Buyer’s Primer
Source: https://sourcebotics.com/guides/vla-models-embodied-ai-buyers-primer/
TL;DRSpecify the robot adapter, observation/action contract, model and data licenses, compute and episode-level acceptance evidence before buying a VLA research setup.
Procurement guidance based on linked research and manufacturer documents. Define application-specific acceptance criteria for the selected robot and software configuration.
What a VLA model actually is
A VLA learns a mapping from inputs such as camera images and language instructions to actions the robot system can execute. The action representation might describe joint targets or movements of an end effector; the interface and control system determine how those outputs become physical motion.
Google DeepMind’s RT-2 research describes transferring vision-language knowledge to robotic control and evaluates tasks involving previously unseen objects and instructions. It is an example of the approach, not a specification for every system marketed as a VLA.
For a buyer, the model is one part of a larger system. Perception inputs, control interfaces, timing, mechanical capability and safety functions still matter. Ask which model and software version the supplier actually delivers and what work is required to run your application.
Why the training data matters—and why volume is not enough
Teleoperation is one way to collect demonstrations: a person controls a robot while observations and actions are recorded. Before purchasing a data-collection setup, confirm which signals it logs, their timestamps, whether interventions are recorded, and how the data can be exported.
The number of demonstrations alone does not establish model quality. Task coverage, environment diversity, recording quality, training method and evaluation conditions all affect how useful a dataset is for your application. There is no demonstration count in this guide that guarantees a new skill will work.
Physical Intelligence’s π0.5 report describes training with several kinds of data, including robot demonstrations, multimodal web data and high-level instructions. Its experiments test generalization to new settings and examine the effect of different training inputs. The experiments have a defined robot, task and evaluation scope. That supports asking about the composition and evaluation of a dataset, rather than treating the largest teleoperation operation as proof of the best model.
When a supplier offers a hardware-and-data package, ask:
- Which tasks, objects, environments and robot configurations are represented?
- Which evaluation conditions were excluded from training?
- Can you inspect the data format and a usable sample before purchase?
- What rights cover the data, model weights, commercial use and your own recordings?
- What additional collection or adaptation work is expected for your task?
Do not assume that a hardware order includes a dataset or model license. Those are separate deliverables to confirm.
What the model needs from the hardware
| Requirement | What to inspect | Why it matters to the purchase |
|---|---|---|
| Action interface | Independently controlled joints, command types, units and available control modes | Total joint DOF does not tell you which commands your application can send |
| Observation interface | Camera, joint and sensor streams; timestamps and export access | A sensor on the robot is not automatically an input to the delivered model |
| Tactile sensing | Exact sensor configuration, calibration, exposed data and model support | Additional sensors need a defined use in control, recording or evaluation |
| Compute and timing | Supported hardware, measured inference rate, latency and where computation runs | An “onboard AI” label is not a performance measurement |
| Integration | Robot adapter, firmware, software versions and recovery behavior | A model demonstrated on one embodiment may require work on another |
Choose hardware that supports the task and workflow you plan to run. Avoid paying for a larger action space or denser sensing solely because a future software release might use it. Additional capability can be worthwhile for a defined research objective; it should have an owner, an integration plan and an evaluation method.
Turn a model demonstration into an integration checklist
A usable proposal names the checkpoint, its robot adapter and the exact input/output contract. In the OpenVLA reference code, the action-prediction example selects a dataset-specific action unnormalization key before handing the result to a robot adapter. Confirm action units, coordinate frame, gripper encoding and limits for your own system; an action vector is not a device command until that mapping is defined.
The repository also separates its MIT-licensed code from pretrained-model conditions inherited from the base model. Ask for the actual code, weights and data license documents in the delivered package. “Open source” is not a substitute for that list.
Physical Intelligence's openpi documentation describes normalization statistics, custom-data preparation and remote inference. Its reviewed requirements distinguish inference from fine-tuning memory needs and a tested software environment. Budget the intended workflow and measured end-to-end timing; an onboard TOPS figure alone does not specify those requirements.
Three hardware paths to assess
| Candidate | Hardware/software boundary to resolve | Evidence to request |
|---|---|---|
| G1 EDU U1 | Quoted 23 DoF configuration, delivered compute and firmware-specific joint map | Configuration list, supported interfaces, synchronized feedback and supplier-supported startup example |
| AgileX PiPER | Original PiPER CAN interface, adapter and compatible SDK/firmware | Tested connection, command mode, feedback and a camera/action recording sample |
| UFACTORY xArm 6 | Controller connection, available command modes and complete wrist load | Controller revision, SDK example, applicable load diagram and task-specific adapter |
These are procurement candidates, not a list of hardware certified compatible with OpenVLA or openpi. Require the supplier or integrator to identify who delivers each adapter and demonstrates it on the offered configuration. Use a stationary research-arm shortlist when locomotion is outside the experiment.
An episode-level acceptance packet
Ask for one recorded episode with the camera configuration, robot/firmware identity, observation timestamps, command units and frame, policy version and intervention log. Agree a test set separately from the demonstrations used for adaptation. Record completion, failures, resets and elapsed time using a definition your lab can reproduce.
If inference runs on a separate workstation, agree the network path, synchronization and timeout/recovery behavior with the integrator. Remote inference is a documented architecture; it does not prove the delivered setup meets your latency or task criteria. Include adapter development, recording and evaluation work in the total-cost worksheet.
A concrete configuration example: OmniHand
AGIBOT sells OmniHand through a standalone official product listing. It does not require buying an AGIBOT humanoid simply to purchase the hand. Integration with a particular robot remains a separate question.
The August 2026 OmniHand technical specification distinguishes the standard model from the tactile-equipped model. For the standard OmniHand 2025 without tactile sensing, it states 16 total DOF and 10 active DOF. Do not combine that configuration with OmniHand Pro’s specifications or assume tactile hardware is included.
| Example | Documented distinction | What remains to confirm |
|---|---|---|
| AGIBOT OmniHand 2025, standard | 16 total DOF, 10 active DOF, without the tactile sensor package | Left/right hand, hardware revision, interface integration, current quote and delivery |
| Unitree G1 / G1 EDU | The manufacturer lists secondary development for EDU separately from standard G1 | Required SDK/control access, compute, accessories and software version in the EDU quote |
The Unitree G1 comparison marks standard G1 secondary development “/” and G1 EDU “YES”; EDU pricing requires contacting sales. A low standard-model price does not establish the cost of a development-ready configuration.
The broader hands and grippers catalog can help identify candidates. Compare their available documentation and interfaces before treating any sensor count, customer name or product family as evidence that your chosen model will run on them. Current lead times and included software require supplier confirmation.
Separate research evidence from delivery commitments
Research generalization is real evidence when its experiment is described. It still has a defined model, robot, task set, evaluation method and failure cases. A commercial promise needs similarly clear boundaries, plus confirmation that the relevant components and support are included in your purchase.
| Supplier claim | Question that makes it assessable |
|---|---|
| “General-purpose embodied AI” | Which unfamiliar tasks or environments were tested, and what counted as success? |
| “Learns a new task” | What data, adaptation work and evaluation are required for our task? |
| “Autonomous” | Which steps needed human input or resets, and how were interventions recorded? |
| “Onboard AI” | Where does inference run, at what measured rate, and what happens if the network fails? |
| “Model included” | Which weights, licenses, robot adapters and updates are included? |
Remote inference is not itself evidence of teleoperation: a policy can run on a workstation. Likewise, smooth motion is not evidence that a robot is autonomous. Our teleoperation and autonomy guide turns those distinctions into questions for a supplier demonstration.
What to specify before buying
For research, prioritize documented access to the observations and actions you need, usable recording tools and clear licensing. Ask for an example workflow on the exact hardware configuration so your team can estimate the adaptation work.
For a fixed production task, compare the simplest viable hardware and control approaches as well as VLA-based options. Require task results and account for supervision, recovery and maintenance. The model architecture alone does not determine whether a project is economical.
Include compute, data collection, annotation, software adaptation and evaluation in the total-cost-of-ownership worksheet. Keep quoted items separate from project assumptions. Buying mechanics such as configuration lists, inspection scope and support terms are covered in the import playbook.
When sending an RFQ, describe the task, robot or hand configuration, available compute, required data interfaces and what your team expects to develop itself. That makes a software-and-hardware proposal more assessable than a request for an “AI robot.”
Update scope
The OpenVLA/openpi integration references and hardware procurement links added above were reviewed on 2026-10-13. This limited documentation update does not refresh every earlier research/product claim or report a policy or driver run on physical hardware.
FAQ
Does a public VLA repository establish compatibility with these three robots?
No. Confirm the robot adapter, action mapping, observation schema, software versions and measured test results for the offered configuration.
Is a VLA the robot’s operating system?
No. It is a learned component that produces actions within a larger software and control system. Confirm how its outputs reach the robot and which components handle timing, limits and recovery.
Can I train a VLA after buying the hardware?
Check the observation/action interfaces, recording tools, model access and licenses first. Hardware ownership alone does not establish that the required workflow is supported.
Does more tactile sensing justify a higher price?
It can, when the task, controller, recording workflow or research plan uses it. Confirm the exact sensing package and its interfaces; do not infer useful model input from a catalog sensor count.
Is OmniHand 2025 only available with an AGIBOT robot?
No. AGIBOT has a standalone official listing. The standard model has 16 total DOF and 10 active DOF without tactile sensing; confirm the required hand and integration details in the quotation.
Does successful research generalization mean a robot is ready for my factory?
No. Examine the test conditions and then ask for evidence on your task, hardware and operating environment, including interventions and recovery work.
Must inference run on the robot?
Not for every application. Confirm the supported compute arrangement and measured latency, and decide whether a workstation or network dependency is acceptable for your operating conditions.
Planning a robotics purchase? Share the quantity, configuration and destination so we can check fit, availability and quote requirements.
Request a quote— The Sourcebotics sourcing desk
