Humanoid robot secondary development: twelve questions buyers always ask
Buying a humanoid robot delivers only the body. Whether it does any work depends on secondary development. In project meetings the question buyers ask most is not which brand is best but how much work remains after delivery. Here are the twelve technical questions, in order.
Separate three layers first
| Layer | Contents | Usually owned by |
|---|---|---|
| Body | Joint motors, sensors, battery, structure and safety mechanisms | The robot vendor |
| Control | Motion control, balance and gait, teleoperation, data interfaces | Vendor-opened interfaces, developed by the integrator or user |
| Application | Scenario tasks, perception and grasping, voice interaction, business system integration | Integrator and user |
Most disputes labelled secondary development are really about who owns the control layer and who owns the application layer. Put a responsibility matrix for these three layers into the contract before approval and you avoid most of the arguing later.
The twelve questions
| Question | Common answer | What the buyer must confirm |
|---|---|---|
| 1. How far is the interface opened? | Most vendors provide an SDK and a simulation environment, some expose ROS interfaces, low-level control usually stays closed | Whether joint states can be read, trajectories commanded and sensors subscribed; whether a simulation counterpart exists |
| 2. How are motions developed? | Three routes: teaching and replay, scripted sequencing, learned policies | Teaching repeatability and accuracy; whether scripts support conditional branching |
| 3. How is data collected? | A combination of teleoperation, motion capture and simulation synthesis | Collection efficiency, where teleoperation yields roughly one hour of valid data per operator hour, and cost per sample |
| 4. Data format and ownership? | Format and annotation rules must be agreed up front or the data cannot be reused | Who owns it, whether it can be exported, whether it transfers to another brand of robot |
| 5. Can simulation replace real machines? | Not entirely, but most policy iteration can happen in simulation | How the sim-to-real gap is measured and narrowed |
| 6. What does real-machine testing require? | A fixed area, protective equipment and emergency stop | Area size, floor conditions, electrical and safety works, and who pays for them |
| 7. Where does compute live? | On-board compute is limited; heavy workloads run on an edge server or local data centre | Network latency requirements and degraded-mode behaviour when the network drops |
| 8. Do we train perception and grasping ourselves? | Standard scenarios can use pre-trained models; non-standard ones need custom data and training | Sample volume for non-standard objects, training duration and acceptance accuracy |
| 9. How is voice interaction integrated? | Usually an external chain of speech recognition, a large model and speech synthesis | Whether deployment is on-premises, terminology coverage and multilingual support |
| 10. Faults and safety? | Fall detection, emergency stop and power-loss protection are mandatory | Committed failure rate, spare parts supply and response time |
| 11. Schedule and staffing? | Estimate in four blocks: PoC, data, integration, tuning | Deliverables and acceptance criteria per block, and who provides algorithm engineers |
| 12. IP and licensing? | Open-source component licences vary and must be checked item by item | Commercial-use terms, SDK licence scope and ownership of development results |
The path from PoC to production
- PoC: pick a tightly bounded scenario and verify interfaces and cycle time
- Data: fix the collection plan and annotation rules, and close the collect-train-replay loop
- Integration: connect business systems and safety mechanisms, then run long-duration stability tests
- Rollout: replicate the single-station solution across similar workstations and set up maintenance and spares
Estimating cost and schedule
There is no single public price benchmark for secondary development, but two known facts frame it. First, data collection is slow: one operator hour of teleoperation yields roughly one hour of valid data, so data volume drives the schedule. Second, hardware delivery has hard deadlines, with public projects requiring delivery within 45 days. Budget therefore splits in two: hardware and integration as a one-off, and data collection plus model iteration as recurring cost. Treating the second as project capex rather than operating expense is why many programmes are cancelled in year two.
One recommendation: in a secondary development contract, three things matter more than price, namely how far the interface is opened, who owns the data, and what the acceptance criteria are. Get those right and technical risk is manageable; leave them open and even the best technology choice becomes an argument at acceptance.
Technical routes and public resources referenced: Unitree official SDK documentation, the Tiangong general-purpose humanoid development documentation, and the open-source vision-language-action project WorldVLA built on RynnVLA-002. Data-collection efficiency is based on industry data compiled by Aibang Robot. Delivery timelines reference the embodied AI training centre project published on the China Government Procurement website, which requires delivery within 45 days. Interface capabilities and licence scope follow the vendor's official documentation and contract.
FAQ
- How long does secondary development take?
- Three phases: interface and scenario validation, data collection and model training, and integration plus stability tuning. The bottleneck is usually data, since teleoperation yields roughly one hour of valid data per operator hour, so data-hungry projects take as long as the data takes.
- Must we collect our own data?
- Not necessarily. First check whether vendor pre-trained models and public datasets cover the scenario; if you do collect, combine teleoperation, motion capture and simulation, and fix the dataset format, annotation rules and ownership in the contract.
- Can we use open-source projects directly?
- As a starting point, yes, but check the licence. Open-source vision-language-action implementations such as WorldVLA, built on RynnVLA-002, and vendor SDK documentation are common starting points; verify commercial-use terms and whether the supported robot models and interfaces match.
- What is the biggest risk?
- Three: interface lock-in, unclear ownership of collected data, and scenarios that never reach production use. Contract terms on interface openness, data ownership and acceptance criteria matter more than the technology choice.