Buying a Unitree G1: Standard, EDU and the Real Integration Cost

A field guide for a lab or product team that wants an accessible full-body development platform, with the current manufacturer claims separated from the configuration, acceptance and legal work that determines whether the purchase is usable.

The first decision is Standard or EDU

The conspicuous number attached to the G1 is the official starting price of US $13,500 before tax and shipping. That number is real, but it describes a specific product boundary. Unitree's store says the base product does not support secondary development and directs customization buyers to G1 EDU. A team buying the base model because it is cheaper, then discovering that its project depends on low-level interfaces or added compute, has not found an inexpensive developer robot. It has bought the wrong configuration.

Begin the request for quotation with the interfaces the project must control. Name whether the team needs high-level motion commands, user development compute, low-level joint control, dexterous hands, tactile arrays, extra waist or wrist axes, ROS integration, simulation assets, or access to reinforcement-learning examples. Ask the seller to mark each requirement as included, optional, restricted, or not supported. “G1 compatible” is not a sufficient answer because Unitree lists a range from 23 to 43 joint motors across configurations.

What the published hardware tells you

Unitree's current parameter page lists a standing size of roughly 1320 × 450 × 200 mm, a folded envelope of roughly 690 × 450 × 300 mm, and a weight around 35 kg with battery. The quick-release battery is listed at 9,000 mAh with about two hours of battery life. Those figures make the G1 physically manageable compared with a full-height industrial humanoid, but 35 kg of powered machinery is still not a desktop peripheral. The lab needs a safe staging area, a way to lift or recover a disabled robot, protected storage and a charging procedure.

The platform's locomotion demonstrations are easy to mistake for shipped task capability. Unitree publishes movement above 2 m/s and shows dynamic recovery, folding and athletic motions. Those demonstrations establish a capable mechanism and control stack; they do not establish that a purchased unit can autonomously perform a buyer's task. A useful acceptance test specifies floor material, lighting, route, obstacles, payload, run duration and allowed intervention. “Can walk” and “can repeat our route safely for an hour” are different requirements.

Manipulation varies even more. The base configuration may end in simple grippers or pads, while EDU options include force-controlled three-finger hands and optional tactile arrays. Dexterous hands add joints, cables, calibration, collision exposure and replacement cost. Buy them only when the research question requires contact-rich manipulation. A navigation or whole-body-control project may learn faster with simple, durable end effectors.

Compute, perception and software need line-item answers

The pasted market summary treated NVIDIA Jetson Orin, 3D LiDAR, depth sensing, ROS 2 and Python support as universal attributes. The official table is more careful: high-compute modules are optional on EDU, with multiple brands and models available. Development documentation exists, but the store explicitly separates the non-development base model. Procurement should therefore record the exact compute module, storage, operating-system image, SDK version, network interfaces, sensor models and source-code access supplied with the quoted unit.

Ask for a minimal program that reads joint state, receives the perception streams, commands a supported motion and stops the robot. Run that program on the actual unit during acceptance. If the vendor says ROS 2 is available through a distributor, identify who maintains the bridge and which message definitions are supported. An unmaintained community bridge is useful research material, but it is not the same procurement object as a supported manufacturer interface.

The landed cost is still a small-capital project

Unitree's current store lists shipping in a narrower US $300–$1,200 range for the G1 and makes the customer responsible for duties, taxes and import clearance. A contactable phone number, email and sometimes a tax identifier are required for customs. That is better evidence than generic freight estimates, but it is not a landed-cost quote. Destination, Incoterms, broker fees, tariff classification, sales tax or VAT and return freight can all change the total.

Budget separately for spare batteries, chargers, hand consumables, a flight case, replacement cables, insurance, a suitable compute workstation and engineer time. Also ask where a failed actuator is diagnosed, who authorizes a return, whether the robot can be shipped with its lithium battery, and what happens to the warranty when the team runs custom controllers. The cheapest repair is the one whose process was agreed before a 35 kg robot became immobile.

Turn the purchase into an acceptance specification

Unitree G1 should be purchased against a task, not against a showreel. Write one page that describes the operating environment, the objects or payloads, the people who may be nearby, required runtime, permitted network access, maximum intervention and the evidence that constitutes success. This converts broad claims such as “general purpose,” “home assistance” or “industrial research” into a test both buyer and seller can understand.

Separate hardware acceptance from application acceptance. Hardware acceptance checks that the delivered configuration matches the order, boots cleanly, charges, reports healthy joints and sensors, executes supported reference motions, stops on command and arrives without shipping damage. Application acceptance asks whether the buyer's own task works. The seller can reasonably warrant the first without promising the second.

Ask for the complete commercial packet

For a lab or product team that wants an accessible full-body development platform, the acquisition route is online purchase for the base unit or a sales-led EDU quotation. Before money becomes non-refundable, collect the quotation, configuration schedule, warranty, software license, privacy policy, support plan, shipping terms, battery documentation, declaration of conformity where applicable and every safety or certification document the seller is willing to stand behind. Marketing pages can guide questions; signed documents allocate risk.

Have engineering, safety, security, facilities, finance and legal review the same configuration. Otherwise each group approves a different imagined robot. Engineering may picture an EDU API while finance prices the Standard unit. Security may picture offline use while the application team depends on cloud learning. Facilities may picture guarded trials while a sponsor imagines a public demonstration. Put these assumptions in one bill of materials and operating-envelope document.

Use a conservative commissioning ladder

1. Inventory without motion. Photograph shipping condition, verify serials and options, inspect batteries and record installed software.
2. Power with restraint. Establish the emergency stop, command timeout, user roles, logs and a safe recovery method before free movement.
3. Run manufacturer references. Reproduce supported health checks and basic motions on a clear surface under the documented limits.
4. Add one project variable. Introduce the buyer's sensor, model, payload or task separately so failures have an identifiable cause.
5. Repeat under realistic conditions. Measure success, intervention, energy, temperature, falls, resets and damage over enough runs to reveal variance.
6. Expand access last. People outside the trained team enter the operating area only after controls have been demonstrated and documented.

This ladder is intentionally slower than an unboxing video. It is faster than debugging simultaneous hardware, network, policy and task failures after a public demo has been scheduled.

Import, privacy and liability are configuration-dependent

Do not copy a generic duty percentage into a budget. Classification, origin, destination, declared value, battery handling and current trade measures determine the actual customs treatment. Use a broker and identify importer of record. Confirm who pays when customs requests documents or returns the shipment. Radio approvals, electrical compliance and workplace obligations likewise depend on destination and use; a seller's global availability page is not proof of local approval.

Map every camera, microphone, telemetry stream, remote-support route, mobile app and OTA service. Record destination, encryption, credentials, retention, administrator, offline behavior and deletion. Put the robot on a segmented network during evaluation and observe traffic rather than relying only on a “local mode” label. If recording workers, visitors or household members is possible, establish notice, access and retention rules before collecting real data.

Physical liability cannot be assigned by a sentence in an article. Applicable law, the sales contract, product defect, buyer modifications, operator conduct and the chosen environment all matter. The buyer should insure the actual use and preserve logs, configuration and maintenance records. Never assume the manufacturer absorbs all autonomous-motion risk, and never accept a blanket claim that it absorbs none. Get jurisdiction-specific advice for a consequential deployment.

Measure cost per accepted task, not cost per robot

The purchase price is only the first denominator. Track engineer setup time, operator supervision, failed attempts, charging, battery aging, replacement parts, service travel, software subscriptions, network service, floor-space controls and the time spent preparing the environment. Then divide by accepted task cycles under the conditions that matter. This calculation prevents a low acquisition price from hiding a platform that consumes a full-time operator, and it prevents an expensive platform from being rejected when it reliably replaces a genuinely costly process.

Set a learning budget before commissioning. Decide how many weeks, engineering hours, falls, damaged consumables and vendor support cases are acceptable before the team pauses or changes scope. Record failures as structured observations: command, software version, environment, robot state, intervention and recovery. Video is useful evidence, but it should accompany logs rather than replace them. A failed trial that identifies a repeatable boundary has value; an endless sequence of undocumented demonstrations does not.

Plan the exit while the robot is still working. Determine how accounts are closed, credentials and recordings deleted, batteries shipped or recycled, licensed software removed and hardware resold, returned or stored. A platform with no supported transfer or decommissioning route carries a residual cost that belongs in the original decision.

A purchase-order checklist

• Exact model, edition, revision, serial-number range and included end effectors.
• Compute, storage, sensors, controller, batteries, chargers, cables and case.
• SDK and firmware versions, API level, source access and update policy.
• Permitted development, commercial use, model ownership and redistribution rights.
• Safety documents, certified standards and the exact configuration in their scope.
• Price, currency, tax, Incoterms, freight, broker, duty and importer of record.
• Delivery window, cancellation, acceptance period and remedy for mismatch.
• Warranty duration, excluded uses, spare prices, service location and response time.
• Telemetry, remote access, privacy controls, retention and offline capability.
• Training, installation, maintenance schedule and safe decommissioning.

Bottom line

The base G1 and G1 EDU are not interchangeable developer packages. The right purchase is the configuration that passes a written task, safety and service case at a defensible landed cost. Preserve the source page, quote, software version and acceptance evidence together. That record is what lets a team distinguish a capable platform from a compelling demonstration and keeps the next software update or repair from erasing the basis of the decision.