peaqOS for Unitree: An App Enabling Unitree Robots to do Business

To every service, marketplace, lender, and application it might work with, the robot is anonymous hardware. No verifiable name. No track record. No way to be discovered, trusted, or served. Robotics solved capability years ago. It never solved standing.

peaqOS for Unitree is live, and it closes that gap for the Unitree G1 Edu and Edu+. It's on GitHub today, under Apache 2.0.

‍

What Shipped

Start with the simple version: peaqOS for Unitree is an app you install on the robot.

It ships as a single compressed package built for Unitree hardware specifically. Download it, run one install script, point it at the robot's network interface, and the G1 is connected to peaqOS. No custom firmware. No rebuilt control stack. No per-robot engineering work.

That matters far more at ten robots than at one. The same package runs on Linux, ARM64 or AMD64, in Docker or as a bare binary — so the hundredth G1 is the same command as the first, and the operator ends up with a fleet where every robot has its own identity and reports its own health.

What you get:

peaq machine identity and pairing. The robot gets a verifiable identity, not just an IP address.

Runtime health and status reporting. Live G1 state, readable over a local REST endpoint and reportable to peaqOS.

Service discovery. The robot can query the peaqOS robotics catalog and search it by what it actually needs.

A deployment you can audit. Checksum-verified releases and an ARM64 package built to Unitree's UniStore specification.

Curl the status endpoint and the live state of a humanoid comes back.

‍

Read-Only Is the Point

The integration subscribes to the G1's state. It does not publish motor commands. Not because control was the hard part — because withholding it was the right call.

The fastest way to lose a robot operator's trust is to hand them software that can move their humanoid. peaqOS for Unitree can't. It observes, reports, and looks things up. Control stays exactly where it was before the install.

That constraint is what makes the rest deployable. An operator can put this on a working fleet without first running a safety review of what happens when the network drops. Write access is a later conversation, and it should be — with explicit permission scoping, spend limits, and an operator in the loop. Identity and observability come first, because everything above them depends on them.

‍

What the Robot Actually Gains

Three things, in order.

It becomes findable. peaqOS gives every machine a cryptographically verifiable identity. The Purple Paper calls it a passport, and the analogy holds: a G1 with a peaq machine identity can be verified by any application, service provider, or counterparty, on any chain, without being re-onboarded by each one.

It becomes legible. Runtime reporting turns a robot from a black box into a stream of timestamped, attributable state. That is the raw material for everything financial downstream. A Machine Credit Rating is only as good as the telemetry beneath it, and insurance underwritten on verified uptime needs uptime that was actually verified.

It becomes a customer. This is the part developers should look at first. The app exposes the curated peaqOS robotics catalog, and a paired machine can search it by intent:

serviceType: "data.location"

operation:   "geocode"

That is a humanoid asking, in a single call, which providers on the network can turn a place into coordinates — and getting back a ranked answer. There are 17 services on peaqOS Scale today, from GEODNET's centimetre-precise positioning to NAVER Maps.

Buying is only half of it. peaqOS Monetize runs the same mechanism in reverse: a machine registers the resources it isn't using — compute, storage, data — the networks that want those resources discover it, and payment settles onchain to the machine's own wallet. Once a G1 carries a verifiable identity on peaqOS, that road is open to it.

This is the part that changes the maths. A robot that only consumes services is a cost line. A robot that can also sell what it isn't using is a productive asset. A G1 standing idle between tasks still has compute, sensors, and a camera doing nothing — connected to peaqOS, that idle capacity becomes inventory.

Discovery and monetization are two halves of the same loop. This ships the half that has to come first.

‍

Try It

peaqOS for Unitree is on GitHub now, Apache 2.0: github.com/peaqnetwork/peaqOS-App 

You need a G1 Edu or Edu+, a Linux host that can reach the robot, and Docker. Set the network interface, run the installer, and hit the status endpoint. If the live humanoid state comes back, you're connected.

If you run Unitree hardware, this is the shortest path from a robot that works to a robot that earns in the Machine Economy.

‍