Buying a Unitree H1 or H2: Full-Size Power Changes the Procurement
A field guide for an industrial R&D group or university lab that genuinely needs full-height dynamics, with the current manufacturer claims separated from the configuration, acceptance and legal work that determines whether the purchase is usable.
Do not buy the slash in “H1 / H2”
Market lists often collapse Unitree's full-size humanoids into one row, then combine the most attractive specification from each. That produces a robot that is not for sale. H1, H1-2 and H2 have different masses, degrees of freedom, compute choices, arm designs and mobility figures. A procurement document must name one model and one edition on every line.
The official store currently shows H1 at US $90,000 with the instruction to contact sales for the real price. The H2 listing shows US $29,900 and says only an EDU version supports secondary development. Those are starting signals, not comparable turnkey totals. A lower H2 storefront price does not establish that an H2 development configuration with hands, compute, support and freight costs less than the quoted H1 package.
| Published specification | H1 | H1-2 | H2 |
|---|---|---|---|
| Approximate height | 180 cm | 178 cm | 180 cm |
| Approximate weight | 47 kg | 70 kg | 70 kg reported by Unitree |
| Mobility | 3.3 m/s published; higher potential claimed | Below 2 m/s | Confirm for shipping configuration |
| Battery | 864 Wh quick-release | 864 Wh quick-release | Confirm capacity and runtime in quote |
| Maximum joint torque | Up to 360 N·m at knee | Up to 360 N·m at leg | 360 N·m advertised |
| Development compute | i5/i7; optional Orin-class modules | Similar, with more optional modules | 2070 TOPS advertised |
Power is the feature and the principal hazard
H1's published knee torque is about 360 N·m, with hip torque around 220 N·m. H1-2 adds full arms whose shoulder and elbow peak figures are listed around 120 N·m. These are not numbers to admire in isolation. They determine fixture design, stopping distance, guarding, recovery equipment and the severity of a controller error. A team that wants full-scale dynamic behavior must also want the engineering controls that make full-scale testing defensible.
Use staged commissioning. Begin with the robot supported and power limited. Verify joint direction, state estimation, emergency stop and command timeout. Move to a guarded flat-floor cell, then to constrained walking, then to the intended terrain. Increase speed, payload and autonomy separately. A dramatic manufacturer video is not a substitute for this sequence because the buyer does not inherit the people, environment, controller version or rehearsals behind that video.
The frequently repeated “30 kg payload” is not a safe general specification. Unitree's H1-2 page gives a rated normal arm load around 7 kg and a peak around 21 kg, with posture-dependent caveats. H1's original short arms do not share that entry. Define payload at a named reach, speed, duty cycle and stability margin. Payload without posture is advertising shorthand.
H2's newer headline requires a newer configuration sheet
Unitree describes H2 as a 180 cm, 31-degree-of-freedom humanoid with 360 N·m joint torque and a 2070 TOPS compute platform. It is also presented with a bionic face and dual-eye camera design. Those details make it tempting to treat H2 as a lower-cost, automatically superior H1. The official sales page supplies far less of the line-by-line parameter detail available for H1, so the prudent response is not inference. It is a more detailed quotation.
Ask H2 sales to specify mass, battery, charger, runtime under the intended duty cycle, sensor part numbers, included compute, end effectors, SDK access, low-level control policy, controller, spares, warranty and delivery state. Confirm which features belong to Standard and which require EDU. Put the version of the SDK and motion controller in the acceptance schedule because continuous OTA evolution can change behavior after the original demonstration.
A full-size robot changes the room around it
A 47–70 kg humanoid needs more than floor area. Check slab and mezzanine load, door width, ceiling clearance during falls or lifts, Wi-Fi isolation, charging and lithium-battery storage, fire response, overhead lifting points, fall mats and a route for bringing the flight case inside. Identify how two people safely move the robot when it cannot stand. If the answer is “drag it,” commissioning has started too soon.
For industrial trials, integrate the robot with the site's safety function instead of placing a consumer emergency button beside it. A risk assessment should cover unexpected startup, loss of communications, stale commands, perception failure, falling, pinch and crush zones, dropped payload, battery event and maintenance with stored energy. Speed-and-separation monitoring or guarding may be required depending on the task and applicable standards. A humanoid body shape does not make industrial power collaborative.
Commercial terms deserve engineering review
The official listings exclude customs duties and direct buyers to contact sales. The contract should identify Incoterms, destination, packaging, import responsibility, training, installation, service response, spare-part lead time, software license, telemetry behavior and ownership of buyer-developed models. Avoid assuming that an open SDK grants rights to redistribute every binary or that optional offline operation means no service traffic is enabled by default.
Insurers and facilities teams should see the intended operating envelope before the purchase, not after delivery. Describe maximum commanded speed and torque, number of operators, access controls, public exposure, payloads and whether testing occurs inside a guarded cell. The policy and the safety plan should describe the same robot.
Never let one H1 or H2 specification stand in for the family. Record the model, edition, end effector, compute module, controller and software version beside every performance claim and every acceptance result.
Turn the purchase into an acceptance specification
Unitree H1 and H2 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.
| Gate | Evidence to keep | Reason |
|---|---|---|
| Configuration | Serials, edition, hands, compute, sensors and software versions | Product-family names hide option differences |
| Safety | Risk assessment, limits, stop test and recovery procedure | Autonomous motion creates physical exposure |
| Capability | Repeated task results and intervention log | A demonstration is not a reliability estimate |
| Data | Network captures, account settings and retention terms | Cameras and telemetry cross privacy boundaries |
| Service | Warranty, spare parts, response time and return route | Downtime can dominate ownership cost |
Ask for the complete commercial packet
For an industrial R&D group or university lab that genuinely needs full-height dynamics, the acquisition route is a sales-led capital-equipment purchase with a configuration schedule. 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
- Inventory without motion. Photograph shipping condition, verify serials and options, inspect batteries and record installed software.
- Power with restraint. Establish the emergency stop, command timeout, user roles, logs and a safe recovery method before free movement.
- Run manufacturer references. Reproduce supported health checks and basic motions on a clear surface under the documented limits.
- Add one project variable. Introduce the buyer's sensor, model, payload or task separately so failures have an identifiable cause.
- Repeat under realistic conditions. Measure success, intervention, energy, temperature, falls, resets and damage over enough runs to reveal variance.
- 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.
This guide uses manufacturer material checked on August 30, 2026: Unitree H1 and H1-2 parameter page, Unitree official H1 store listing, Unitree official H2 store listing. Prices, configurations, delivery queues, software access and specifications can change. Product pages document what the manufacturer currently represents; they are not independent performance tests or substitutes for the final quotation and terms.
Bottom line
H1, H1-2 and H2 are different machines, not trim levels with directly portable specifications. 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.