Section 46.2: Platforms: Unitree G1/H1, Figure, Optimus, 1X, electric Atlas, Apptronik

"Platform choice decides which research questions are real and which ones are just impossible on your hardware."

A Humanoid Lab Procurement Meeting

A useful platform comparison uses a capability vector $p = [n_{\mathrm{dof}}, \tau_{\max}, m_{\mathrm{payload}}, s_{\mathrm{perception}}, h_{\mathrm{dexterity}}, o_{\mathrm{sdk}}]$. The point is not to pretend these numbers collapse neatly into one score. The point is to make the tradeoffs explicit enough that a research program can choose a platform on purpose.

Publicly documented platforms already differ in strategic ways. Unitree G1 emphasizes affordability and force-controlled hands. Unitree H1 is full-sized with stronger legs and richer onboard sensing. Atlas targets industrial mobile manipulation. 1X NEO emphasizes home-facing autonomy and supervised expert mode. Apptronik Apollo targets general-purpose industrial work. Figure couples humanoid hardware to a strong VLA narrative. Tesla Optimus remains comparatively closed in public technical documentation, which matters if your project depends on inspectable interfaces.

Theory

Humanoid platforms should be compared by capability surfaces rather than by single numbers. A body with lower raw torque may still be superior for research if it offers better teleoperation, more stable software, or clearer access to state and control loops.

The platform decision also determines benchmark compatibility. Some whole-body tasks need dexterous hands, wrist cameras, or rich force sensing. Others mainly need robust locomotion and payload handling. Treating all humanoids as interchangeable destroys experimental clarity.

For research, a closed but impressive platform can be the wrong choice if it prevents controller inspection, synchronized logging, or low-level safety instrumentation.

Worked Example

A simple capability table already explains why two humanoid teams with similar goals can rationally choose different hardware.

platforms = {
    "Unitree_G1": {"dexterity": 4, "locomotion": 3, "sdk": 4},
    "Unitree_H1": {"dexterity": 3, "locomotion": 5, "sdk": 4},
    "Atlas": {"dexterity": 4, "locomotion": 5, "sdk": 2},
    "NEO": {"dexterity": 4, "locomotion": 3, "sdk": 3},
}

weights = {"dexterity": 0.4, "locomotion": 0.4, "sdk": 0.2}
scores = {name: round(sum(vals[k] * weights[k] for k in weights), 2) for name, vals in platforms.items()}
print(scores)
print(max(scores, key=scores.get))

Expected output interpretation. Under this toy weighting, H1 and Atlas are close because locomotion is priced heavily. If SDK openness were more important, the ranking could flip. This is the exact point of writing the weights down.

Practical Recipe

1. Write a capability matrix before looking at vendor demo videos.
2. Match each task to required locomotion, manipulation, and sensing primitives.
3. Price interface openness and logging access explicitly.
4. Prototype on simulation and small data flows before full commitment.
5. Update the scorecard as public documentation changes.

This section can teach strong research taste. Platform comparisons should include what is unknown. Missing interface documentation, unclear safety APIs, and uncertain teleoperation hooks are all part of the technical evaluation, not procurement trivia.

It is also a good place to emphasize that benchmark fit matters. A platform built for home assistance and one built for industrial tote handling can both be 'general purpose' in marketing language while being very different research instruments.

Platform-selection failures usually come from missing interfaces, not from missing hype. If the controller cannot be instrumented, the benchmark cannot be trusted.