A humanoid is a robot with a body structure resembling a person’s. Humanoids are drawing attention as a prominent application of Physical AI: systems that perceive their surroundings, make decisions and act in the physical world. But moving a box once and moving it economically all day are very different achievements. Specifications, human support and cost per completed job help close that gap.
Five things we will work through
- Define the whole job first. Picking up a box and placing it correctly with a completion check require different capabilities.
- Compare a stationary robot arm and a wheeled robot too. Be clear about why the task needs legs.
- Attach a pose and a duration to any payload figure. The same 3 kg load can put very different demands on a joint.
- Find out how much human help is needed after a stop. Track hands-on assistance separately from time until the robot resumes work.
- Include failures and recovery in cost per job. In our hypothetical example, roughly 197 seconds of recovery is the point where the preferred option changes.
The robot carries a box to a shelf. Thirty seconds later, it sets it down. In the meeting room, someone says, “A little more speed and we’re there.” Then the next box arrives with its handle facing the other way. The robot stops. Someone calls an operator, resets the box and restarts the task. Five minutes have passed. Time missing from the demo has started showing up in the cost model. This is a hypothetical review scenario, not an account of a real deployment.
My first question in this review would not be “What is its top speed?” It would be “What exactly counts as one job worth paying for?” Next: does the task need legs, can the robot sustain the required pose, and who helps when it stops? This is where the technical review meets the business case. We will read the numbers in that order.
1. Picking up the box does not finish the job
Not every humanoid walks on two legs. NASA’s Robonaut 2 began as an upper-body humanoid; climbing manipulators serving as legs were added in 2014. A human-shaped body, the ability to walk on two legs, and the ability to work without human help are separate things to check.
First, write down the task in enough detail to test it. “Move a box” is not enough. A clean pickup does not count as a successful job if the box ends up in the wrong slot or its contents are damaged. Record assisted jobs separately too: you will need that information to work out staffing later.
| What to check | For our box-handling example |
|---|---|
| What moves, and where? | Move a parts box with a total mass of 3 kg from a shelf to a workbench, over an assumed 4 m of level floor. |
| What varies between attempts? | Box position, grasp-surface condition, shelf height and people appearing in the aisle. |
| What counts as success? | Place the undamaged box in the assigned slot and send a completion signal. Count human-assisted jobs separately. |
| When does timing start and end? | From readiness to start until completion—or recovery from a failure—and readiness for the next attempt. |
| What goes in the log? | All attempts and successes, failure causes, hands-on assistance time and time until the robot is ready to work again. |
The 3 kg load and 4 m route are assumptions for this example. In a real review, ask how heavy the heaviest box is and how often it appears. Even a 4 m route can call for a different robot depending on whether it is wide and level, crosses a threshold, or turns a tight corner.
NIST’s report on measuring assembly-robot performance also explains that the importance of a performance measure depends on the task. Do we need a robot that scores highly on every measure, or one that does the job we actually have? If the box must fit into a narrow space, for example, I would check whether the arm can reach in and place it accurately before worrying about top speed.
2. Does this job actually need two legs?
A human-shaped body is appealing if it lets us keep existing shelves, tools and workbenches. A familiar shape, however, does not establish the lowest-cost solution. The job determines the useful body form; the cost of completing that job determines the business case. Assessing both helps avoid choosing a robot from a video and then reshaping the requirements to suit it.

| Robot option | Questions to ask first | Costs and operating issues to include |
|---|---|---|
| Stationary robot arm | Can objects be brought to the robot? Can it finish the job within its reach? | Fixtures, feeders, conveyors and equipment-layout changes |
| Wheeled robot arm | Must it travel between work locations? Can it handle the floor, thresholds and tight turns? | Stopping-position error, floor improvements, door/elevator integration and waiting time |
| Bipedal humanoid | Are legs needed for an obstacle or a working pose? Can it repeat that task? | Balance, recovery after a fall or stop, and sharing travel routes with people |
What I would want to test here is how much we really save by changing less of the site. A humanoid might let us keep the workbench, but installation, integration and ongoing human support still have a price. Compare acquisition and operating costs over the same period, then divide by the number of jobs completed to the required standard during that period.
If one threshold is the reason for choosing legs, it is worth first asking whether a ramp or a different route would solve the problem. If work locations change often and the equipment cannot be modified, the ability to move into different poses becomes more valuable. Put the cost of a more complex robot alongside the cost of a modest change to the site.
3. What “it can lift 3 kg” leaves out
Start with Unitree’s official G1 specifications. The base G1 has 23 degrees of freedom; the G1 EDU has 23–43 depending on configuration. Development support also needs checking by configuration. “We’re buying a G1” does not tell us which hands, joints or development environment are included. Match the options before comparing price and capability.
Boston Dynamics’ Atlas product page distinguishes a 50 kg instantaneous payload from a 30 kg sustained payload. Those are different commitments. Neither figure alone establishes how long one arm can repeat a task in a particular pose. Beside maximum payload, I would leave blanks for “Which pose? How many repetitions? For how long?” Unitree also notes that maximum arm load varies substantially with arm extension.

Suppose one joint holds a 3 kg object still. The torque caused by that load can be calculated as τ = m × g × r. Here m is mass in kg, g is gravitational acceleration (9.81 m/s²), and r is the perpendicular distance in metres from the joint axis to the line of action of gravity. With the arm horizontal, as in the figure, r is the horizontal distance from the joint to the object.
| Hypothetical condition | Calculation | Torque due to the load |
|---|---|---|
| 3 kg, r = 0.2 m | 3 × 9.81 × 0.2 | 5.886 ≈ 5.9 N·m |
| 3 kg, r = 0.5 m | 3 × 9.81 × 0.5 | 14.715 ≈ 14.7 N·m |
| Change only the distance | 0.5 ÷ 0.2 | 2.5× |
The same box puts a different load on the joint when held close to the body or reached deep into a shelf. A real arm is more complicated, of course. This calculation leaves out the arm’s own weight, acceleration and deceleration, friction, impacts, gearbox losses and design margins. For a robot with multiple joints, the force–torque relationship depends on pose, as in τ = JᵀF in Modern Robotics, Section 5.2.
Repeated lifting needs a separate check. maxon’s motor guidance explains that continuous operation depends on winding temperature, heat dissipation and speed-dependent losses. A momentary peak-torque figure is not enough to estimate a day’s output. Go beyond “How many kilograms?” Ask how many minutes the robot can repeat the task at the required pose and speed, and under what temperature and cooling conditions.
4. When it stops, who gets it working again?
In its January 27, 2026 Helix 02 announcement, Figure reports a roughly four-minute dishwasher task spanning 61 actions without human intervention. Connecting a long sequence of actions is interesting evidence beyond a single successful grasp. The next question is “Does it still work with different dishes and layouts, across repeated trials?” That demonstration alone cannot supply an eight-hour success rate for our factory.

Two measures make the record easier to use. One is the share of all attempts completed without human help. The other is the minutes of hands-on human assistance per observed hour. Calculate them as “successful unassisted completions ÷ all attempts” and “total hands-on intervention time in minutes ÷ observation time in hours.” Decide in advance how retries count, and keep failed attempts in the record.
There is one more distinction: a person’s hands-on time may be much shorter than the robot’s time until restart. The operator may fix the issue quickly once they arrive, while the robot spends several minutes waiting. Hands-on time affects staffing; time until restart affects output. Several robots may also ask for help at once, so average intervention time alone cannot tell you how many robots one person can support.
When a report says 95% success, find the denominator. Nineteen successes in 20 attempts and 950 in 1,000 both give 95%, but they offer different amounts of evidence. If someone neatly arranged the objects beforehand, record that preparation too. A useful review includes the failures and restart logs alongside the successful footage. Reproducing those failures in the next trial helps estimate what improvement will cost.
Ask the same questions when reading about these five companies. This is not a ranking. It maps each type of public evidence to a useful decision and a follow-up check.
| Public example | What it supports / what to check next |
|---|---|
| Boston Dynamics · Atlas | Product specifications separating instantaneous and sustained payload. Request conditions for the required pose and repetition cycle. |
| Figure · Helix 02 | A continuous-task demonstration. Ask about repeated trials, failures and how the task resumes. |
| Google DeepMind · Gemini Robotics | A VLA model mapping visual and language inputs to robot actions. Check supported robots, tasks and evaluation conditions. |
| Tesla · Optimus | Production preparation reported in the Q2 2026 update. Distinguish preparation and plans from actual production and operating results. |
| Unitree · G1 | Joint and development-support specifications by configuration. Confirm what is included in the version being purchased. |
5. Thirty seconds or thirty-five: is faster always better?
Back to the 30-second demo. This time, compare two hypothetical robots moving the same box: A takes 30 seconds per attempt, B takes 35. Both must meet the same quality standard to count as successful. Assume that even a failed attempt consumes the basic task time, followed by extra recovery time before the next attempt can start.
| Hypothetical inputs | A | B |
|---|---|---|
| Basic time per attempt, t | 30 seconds | 35 seconds |
| Success probability per attempt, p | 95% | 99% |
| Extra recovery time after failure, r | 300 seconds | 60 seconds |
| Hourly cost, Cₕ—same cost scope | KRW 30,000 | KRW 35,000 |
A attempts the task in 30 seconds, but fails 5% of the time and then needs another 300 seconds before restarting. Averaged across attempts, that adds 0.05 × 300 = 15 seconds per attempt. The average duration is therefore 45 seconds, not 30. Include the probability of success, and the rate of properly completed jobs becomes:
Q = 3,600 × p ÷ [t + (1 − p) × r]
Q: successful completions per hour (jobs/hour)
t: basic time per attempt (seconds)
p: success probability per attempt—for 95%, use 0.95
r: extra time after a failure until ready to restart (seconds)
For A: 3,600 × 0.95 ÷ [30 + 0.05 × 300] = 76 jobs/hour. For B: 3,600 × 0.99 ÷ [35 + 0.01 × 60] = about 100.1 jobs/hour. B takes about 16.7% longer per basic attempt, yet completes about 31.7% more good jobs per hour. In this example, fewer failures and a quicker restart more than make up for the slower movement.

Now add costs. Assume A costs KRW 30,000 per hour and B costs KRW 35,000. These hypothetical totals include acquisition, installation and integration costs allocated over the usage period, plus the same scope of operating labour, maintenance and electricity. They are not product quotes or market averages; KRW means South Korean won. Divide hourly cost Cₕ by hourly output Q: cost per successful completion = Cₕ ÷ Q. If recovery labour is already included in operating costs, do not add it again.
| Calculated result | A | B |
|---|---|---|
| Successful completions per hour | 76.0 jobs/hour | 100.1 jobs/hour |
| Cost per successful completion | 30,000 ÷ 76 ≈ KRW 395 | 35,000 ÷ 100.1 ≈ KRW 350 |
B costs about 16.7% more per hour, but each completed job costs about 11.4% less. That looks like a reason to choose B. But what if we could reduce the time A takes to get back to work after a failure?
Reduce only A’s recovery time from 300 seconds to 60. Keep the other inputs unchanged. Output becomes 3,420 ÷ 33 ≈ 103.6 jobs/hour, and cost falls to about KRW 289 per job. A is now cheaper. Before assigning a project to shave one second off its motion, I would separate waiting for help from the time spent actually fixing the problem. Could a different operator-call process or object-reset procedure remove part of the five-minute delay?
How far must A’s recovery time fall? With these inputs, cA = 30,000 × (30 + 0.05rA) ÷ 3,420. Set it equal to B’s KRW 349.607 per job and solve: rA ≈ 197.1 seconds, or about three minutes and seventeen seconds. A is cheaper below that point; B is cheaper above it. If the recovery improvement changes hourly cost or success probability, recalculate those inputs too. The 197-second threshold belongs to this hypothetical quote, not to a product benchmark.
This is a long-run average for repeated work under the same conditions. It assumes a constant success probability and recovery time, and excludes charging, scheduled maintenance, queues and correlated failures. It does not promise exactly this many completions in the first hour. For a real deployment decision, compare total costs over the same period against jobs actually completed to the required standard. Include time when the robot was standing idle in that period too.
Take these five questions to the next demo
Bring the following questions along with the spec sheet. It is fine if you cannot get every answer on the spot. Knowing what remains unverified tells you what the next trial needs to test.
| Question to ask | What the answer lets you judge |
|---|---|
| ① What is the full job? | Specify objects, loads, distances, variable conditions and success criteria. Different criteria make even success rates hard to compare. |
| ② Why this robot form? | Compare a stationary arm, a wheeled robot and a humanoid. Check whether a small site change would allow a simpler robot. |
| ③ Can it keep working in the required pose? | Check load, reach, speed, continuous working time and temperature. A momentary peak does not establish repetitive-task performance. |
| ④ How much human help does it need? | Check total attempts, unassisted completions, hands-on time and time until restart. These records are needed to estimate staffing. |
| ⑤ What does a properly completed job cost? | Compare costs and output over the same period. Vary success rate or recovery time, then test the conditions that change the preferred option. |
Back in the meeting room, the 30-second video ends. This time, “Can it move faster?” is followed by “Can we get recovery below three minutes and seventeen seconds? What would we need to change?” A vague hope has become something to measure. The answer helps decide whether to change the robot, change the site or wait before deploying.
Coming next: Do more joints make a robot better at the job? On Day 2, Unitree G1’s configuration-dependent degrees of freedom will be our starting point for weighing extra capability against the added control and cost burden of another axis.
Related reading
- [Explainer] Humanoid Actuators: Motors, Gearboxes, Torque and DoF—Atlas, Figure and Optimus Compared
- [News Explained] DDC: Why Is Single-Leg Balance So Hard for Humanoids?
Sources and calculation limits
Public sources checked: October 5, 2026. Product specifications are manufacturer-provided figures, not independent performance-test results. The review sequence and checklist are the author’s interpretation of public evidence. Torque, throughput and cost examples were calculated from hypothetical inputs; they do not represent actual customer, site or product results.
- NASA · About Robonaut — Robonaut 2 section: the original upper-body humanoid and the addition of legs in 2014. Updated September 26, 2023.
- NIST · Measuring and Representing the Performance of Manufacturing Assembly Robots — Abstract: task- and capability-dependent importance and classification of performance measures. NISTIR 8090, published December 10, 2015.
- Unitree · G1 official specifications — Unitree G1 Parameter / Mechanical Dimensions / Total Degrees of Freedom and footnotes [2] and [5]. Checked October 5, 2026; no web revision number shown. G1 and G1 EDU columns distinguished.
- Modern Robotics · 5.2 Statics of Open Chains — Transcript derivation of τ = JᵀF. Kevin M. Lynch and Frank C. Park; online textbook lecture, no revision number shown.
- maxon · Continuous operation range of BLDC (EC) Motors — Border continuous operation range. Updated August 29, 2024.
- Boston Dynamics · Atlas — Product-page distinction between instantaneous and sustained payload; manufacturer specifications.
- Figure · Helix 02 — January 27, 2026 dishwasher demonstration; company report.
- Google DeepMind · Gemini Robotics — VLA model inputs, outputs and supported platforms; model documentation.
- Tesla · Q2 2026 Update — Published July 22, 2026; Manufacturing & Hardware, Robotics section (PDF page 8 / printed page 6), preparation as reported for that quarter.

Sean Woo | Robotics & AI Editor
I have spent more than 15 years shaping robotics technology and business strategies. I analyze developments in robotics and AI using publicly available technical documents, research papers and company announcements. The views expressed here do not represent the official position of any company or institution.