How Are Unitree Robots Controlled?

Unitree robots can receive commands from a handheld controller or, on supported development configurations, from software written by a research or integration team. Some setups also use human teleoperation. Whether a robot completes a task autonomously depends on the model, software and application. A walking demonstration alone cannot establish that.

At a Unitree visit, I stood with visitors in front of the company's humanoids. The photograph below captures the attraction: you can finally see these machines at human scale. It says nothing about who selected their movements. That question needs its own evidence, even when the hardware is right in front of you.

I'm Thomas Derksen, founder of Asiabits. In our podcast conversation with robotics entrepreneur Francesco Crivelli, I asked what an investor should look for when assessing robot companies. His emphasis was on an honest team that learns quickly and on how a demonstration translates into value for the user. That is a useful starting point for a buyer too.

Who gives the command when a Unitree robot walks?

The command can come from a person or a software application, while the robot's motion controller handles the movement. For the G1, Unitree's current product comparison lists a manual controller for both the standard and EDU versions. It lists secondary development for the EDU version. Buyers should verify the exact configuration and delivered functions before choosing a package.

Separate the decision to move from the work of moving. An operator might choose a direction. A navigation application might instead choose a destination and send motion commands. Either arrangement still needs a controller that coordinates the body. Watching the feet gives you little information about where the instruction originated.

Unitree's G1 high-level software example makes this visible. Its menu includes forward, lateral and rotational movement, along with standing transitions and gestures. The program accepts a selection and calls a corresponding function. This shows a way to request movements; evaluating a complete application requires additional evidence.

For a demonstration, ask the host to describe the path from instruction to action. Who selected the destination? What generated the movement command? Which software reacted to the surroundings? A clear explanation should connect the visible behaviour to the system being offered.

Can a remotely controlled robot still use AI?

Yes. Human input and learned motion control can be part of the same system. Teleoperation describes a person's role in directing the robot. It does not tell you how every motor command is calculated, or whether the robot uses learned components elsewhere.

Unitree publishes an XR teleoperation project for its humanoids. The documented setup uses devices such as a headset and tracked hand or controller input. It also supports recording demonstrations. This is direct manufacturer evidence that human teleoperation is one supported development route.

That route can be useful for collecting examples of a task, testing a new application or providing human assistance. Its suitability depends on what you need to achieve. A research team collecting manipulation data has a different requirement from a factory team expecting unattended material handling.

Ask the supplier to identify which parts of your proposed workflow require a person. Does an operator control each grasp? Does someone choose the next task? Does a person intervene only after a failure? Record those answers beside the proposed operating model. A video with the operator outside the frame cannot answer them for you.

What do SDK and ROS 2 access actually provide?

They provide interfaces through which developers can communicate with and control supported robots. An SDK is a software development kit. ROS 2 is commonly used to connect robotics software components. Access to either is a starting point for application development.

Unitree's Python SDK2 repository documents status acquisition and control through requests and message exchange. Its ROS 2 repository describes communication using DDS, a messaging technology also used by ROS 2. Compatibility must be checked against the robot, interface and software release you intend to use.

For a buyer, the practical question is what your team can do with the delivered interface. Can you read the state information needed for your application? Can your software request the required movements? Who maintains the connection to your existing systems? Ask for a small demonstration using the proposed hardware and software versions.

High-level control typically requests a behaviour or motion through an existing controller. Low-level development reaches closer to individual joint commands and transfers more responsibility to the development team. Unitree publishes examples for both levels. Keep that distinction visible in the project brief so that a software-access promise has a concrete meaning.

A procurement team can use this without reading code. Have the engineer responsible for the application review the interfaces before ordering. A successful connection, a documented limitation and an agreed support owner are more useful at that stage than a long list of compatible software names.

Does buying a G1 include autonomous task execution?

You need to confirm the particular task and delivered package. A product's sensors, computing hardware and development access do not by themselves establish that it can perform your workflow. Ask the vendor to demonstrate the capability you intend to buy on the configuration you will receive.

Unitree's G1 page distinguishes standard and EDU development access and cautions that some displayed functions remain under development or testing. Read those notes alongside the videos. Treat the product page as a description to verify with the supplier, especially when your decision depends on a particular function.

Autonomy should be described at task level. A robot might move to a known point independently but need help identifying an object. Another application might automate grasping at a fixed workstation while relying on a person to reset the scene. These are illustrative examples of different operating arrangements, rather than claims about a specific G1 installation.

Write a short task statement before comparing offers. Include the starting conditions, objects, expected result and permitted human assistance. Describe what should happen when the task cannot be completed. That gives the supplier something testable and helps your team distinguish included functions from development work.

Our guide to embodied AI and China's robot builders explains the broader relationship between perception, decisions and physical action. For purchasing, bring the discussion back to one workflow and the evidence available for it.

How should a buyer test the control mode?

Agree a demonstration in which the human assistance and operating conditions are visible and recorded. Define success before the run, then keep a record of completed attempts, failures, resets and interventions. Choose the test conditions with the supplier so the exercise stays within the machine's intended operating limits.

Start by asking who or what issues each instruction. Then observe the complete task, including preparation and recovery. A useful record follows the process from its starting state until the system is ready to repeat it. Editing out the reset can hide work your team would have to provide during daily operation.

If the application is supposed to tolerate variation, agree a relevant change: a different permitted object position, for example. Ask the team to explain how the system detects and handles that change. Record whether a person updates the program, directs the robot or simply authorizes the next run. Each answer helps define the actual application.

Keep the test record with the offer. Include the robot configuration, software version, task conditions, responsible team and observed assistance. When a later update changes the behaviour, repeat the relevant checks. This also helps internal handover: the engineer who attended the demonstration and the operations manager who receives the machine should be working from the same description of what was demonstrated and what still needs development.

Measure the outcome that matters to your business. For material handling, that might include completed transfers, damaged items and time spent on recovery. Set acceptance criteria from your own process requirements. A universal percentage would conceal the differences between a research experiment and a production task.

We have not independently tested every Unitree configuration or third-party control system. Public code demonstrates available interfaces and examples. Only a relevant application test can establish whether the proposed setup meets your requirements. Our guide to checking a robotics supplier before a pilot covers the surrounding evidence and delivery questions.

How does this change the choice of a Chinese robotics partner?

Choose a partner against the application work you need done. In our database of 7,000+ robotics companies, the snapshot checked on 27 October 2026 contains 7,320 records, including 214 classified in the Humanoid Robots category worldwide. Those are directory classifications, with varying verification dates. They establish neither market size nor proven autonomy.

The distinction matters when building a shortlist. A robot manufacturer, a control-software team and a system integrator may solve different parts of your problem. Ask each candidate which part it will deliver, what evidence supports that offer and who owns the remaining integration. Carry the same task statement into every discussion.

Asiabits helps teams research Chinese robot manufacturers through our robotics directory and arrange robotics company visits in China. Bring a defined task and the control questions above. That gives a visit a practical purpose: seeing the proposed operating arrangement and identifying the engineering work needed before a pilot.

Frequently asked questions

Are Unitree robots remote controlled or autonomous?

The answer depends on the robot, software and task. Unitree documents manual control, developer interfaces and humanoid teleoperation. Ask which actions are performed independently and which require an operator in the exact setup being demonstrated.

Can you program the Unitree G1?

Unitree's current G1 comparison lists secondary development for the EDU version and distinguishes it from the standard package. Confirm the exact model, supported interfaces, software version and delivered capabilities with the supplier before ordering.

Does ROS 2 make a Unitree robot autonomous?

ROS 2 provides software communication and integration tools. A complete autonomous application also needs the capabilities required by its task, such as perception, planning and recovery. Check the interfaces and demonstrate the intended application on the proposed hardware.

Why do developers teleoperate humanoid robots?

Teleoperation lets a person direct the robot and can support testing or recording task demonstrations. Unitree publishes an XR teleoperation project with recording support. Any planned human operation should be included when assessing staffing and operating cost.

How can you check whether a humanoid demonstration is autonomous?

Ask the demonstrator to identify every source of commands and any human assistance. Observe the complete task, including preparation, failures and resets, against agreed conditions. Keep a record of interventions rather than inferring autonomy from the finished video.