Designing the ergoCub Humanoid Around Human Ergonomics

Analysis by the aitrendblend editorial team  ·  Robotics and autonomous systems  ·  Explains published research, not medical or safety advice  ·  Reading time about 18 minutes
Humanoid Robot ergoCub Human Robot Collaboration Embodied Intelligence Robot Co Design Ergonomics
The ergoCub humanoid robot lifting a payload together with a human worker, its body and control optimized to reduce strain on the person's lower back
ergoCub was shaped by an optimization that treats the human partner as part of the design, choosing limb lengths and control gains that take load off the worker’s back.

Lifting heavy things for a living wears out backs. Warehouse pickers, nurses shifting patients, factory hands hauling parts, all of them pay for the work in tired joints and strained spines, and the bill lands hardest on the lower back. A robot that could take the heavy half of a lift would be worth a great deal to those workers.

The catch is that most humanoid robots are built to look human and to move on their own, with almost no thought given to the person they might one day work beside. A team at the Istituto Italiano di Tecnologia decided to design the robot around that person instead, and the result is a machine named ergoCub.

Key points

  • The team proposes a design method that optimizes a humanoid robot’s body and its control together, using models of the human partner so the robot is shaped to reduce human strain rather than just to move well on its own.
  • The concrete result is ergoCub, a robot with 36 degrees of freedom, a height of 150 centimetres, and a weight of 56.7 kilograms, built to lift loads alongside people and to walk robustly.
  • In real collaborative lifting, working with ergoCub cut the peak load on the human worker’s lower back substantially, for example from about 44 to 25 newton metres when lifting a one kilogram box.
  • The same design choices that help the human also made the robot a better walker than its predecessor, with a longer maximum step and a faster stepping rhythm.
  • The robot follows the human’s motion closely, with an average tracking error under one centimetre, and its control adapts to individual partners through real time sensing.
Please note. This article explains a published robotics research paper. The figures on human back load are experimental biomechanical measurements from that study, not medical or occupational safety advice, and they do not describe any individual’s injury risk. Anyone with questions about workplace strain or back health should speak with a qualified professional.

Two ideas that rarely meet

The paper builds on two concepts that usually live in separate fields. The first is shared intelligence, the human knack for coordinating with others by carrying an internal model of what they are doing. When two people move a sofa, each is quietly predicting the other, and that mutual awareness is what makes the joint act smooth. The second is embodied cognition, the observation that a creature’s body and its mind are shaped together by the world it lives in. Our ability to walk is not just a brain trick, it is a partnership between neural circuits and the exact mechanics of our legs.

Put those two ideas together and you get what the authors call shared embodied intelligence. A robot meant to work physically with a person should carry a model of that person, and its body should be shaped by the collaboration it is meant to perform. Neither idea is new on its own. The contribution is insisting on both at once, and then actually building a robot that honours them.

This matters because of a habit in robotics that the authors gently criticize. Hardware is usually treated as a fixed given, a body that engineers hand to control researchers, who then write software to make the best of it. Design and control are optimized in sequence rather than together, and the human partner barely enters the picture at all. The whole premise here is that the body and the brain of the robot, and the body of its human partner, should all be optimized in one loop.

Designing the body around the person

The method has two stages, and the first is the one that reshapes the robot itself. The team started from an existing open source humanoid called iCub3, kept its joint layout so it would remain buildable, and then asked a nonlinear optimizer a pointed question. What limb lengths would let this robot take the most strain off a human during a shared lift, while also letting it walk well?

To make that question answerable, they described each of the robot’s body parts as simple shapes, spheres, cylinders, and boxes, whose mass and inertia follow directly from their dimensions. Stretch a link and its physical properties change in a known way. That trick turns the robot’s whole dynamics into a function of a handful of length parameters, which is what lets an optimizer explore different bodies without rebuilding the physics each time.

$$ \mathbf{M}(q, \pi)\,\dot{\mathbf{v}} + \mathbf{h}(q, \mathbf{v}, \pi) = \mathbf{B}{\tau} + \mathbf{J}_c^{\top}(q, \pi)\,\mathbf{f} $$
Figure 1. The robot dynamics written as a function of the hardware parameters, so changing a limb length changes the whole equation of motion.

The objective the optimizer minimizes is a weighted sum of three concerns. Keep the robot’s own joint torques low so the machine is efficient. Keep the human partner’s joint torques low so the person is spared. And raise the robot’s centre of mass, which turns out to make walking more robust. The weights are lopsided on purpose, with the human ergonomics term carried at a far higher weight than the others, a design choice that says plainly whose comfort comes first.

$$ \mathbf{y}^{\star} = \arg\min_{\mathbf{y}} \big( W_1\,T_1 + W_2\,T_2 + W_3\,T_3 \big) $$
Figure 2. The codesign objective. The three tasks are robot torque, human torque, and walking robustness, balanced by their weights.

Out of this optimization came a taller robot with rearranged proportions, and the winning design was chosen because it did the best job across a whole range of lifting heights rather than excelling at just one. The output was not a paper study. It was a manufacturing specification, and the team built the real ergoCub from those limb lengths.

Key takeaway

The robot’s body is the answer to an optimization, not a starting assumption. By writing the dynamics as a function of limb length and putting the human’s back load into the objective at a high weight, the team let the collaboration itself decide the robot’s shape.

Giving the body a matching mind

A well shaped body is only half the story. The second stage of the method optimizes the robot’s control, what the authors call its physical intelligence, on top of the fixed hardware. Here the architecture mirrors the way a human nervous system is often modelled, as a hierarchy. A planning layer turns a high level goal into a rough whole body trajectory, an adjustment layer refines that trajectory against live sensor feedback, and a fast control layer turns it into the actual commands that drive the motors.

The symmetry with the human is deliberate and useful. The robot carries a model of its human partner built from the same kind of equations it uses for itself, and it updates that model continuously from wearable and onboard sensors. During a lift the robot estimates the strain on the person’s lower back in real time and shapes its own motion to keep that strain down. This is the shared intelligence idea made concrete, a robot acting on an internal picture of the person it is helping. The control layer that plans the robot’s footsteps leans on model predictive control, the same technique our write up of a multi drone search system examines in a very different setting.

$$ \dot{\mathbf{h}} = m\,\mathbf{g} + \sum_{i} \begin{bmatrix} \mathbf{I}_3 \\ (p_i – p_{\text{CoM}})^{\wedge} \end{bmatrix} \mathbf{f}_i $$
Figure 3. The centroidal momentum dynamics the walking controller reasons about, balancing gravity against the forces at the feet.

One nice detail is how the robot decides how fast to follow the human. Its reference motion is planned ahead of time, but its actual speed of following is governed by the height gap between its hands and the human’s hands. The person leads, the robot keeps pace only within a sensible range, and if the human moves outside the agreed working heights the robot simply waits rather than lunging along. That restraint is a safety feature dressed up as a control law.

What the measurements show

The payoff is in the numbers, and the headline result is about the human worker rather than the robot. In real collaborative lifting, with the robot taking one end of a load at heights between 0.8 and 1.2 metres, the team measured the peak torque at the base of the human’s spine, the lumbosacral joint written as L5 to S1, both with and without the robot’s help.

LoadHuman lifting aloneLifting with ergoCub
Empty box43.95 Nm24.88 Nm
1 kilogram50.66 Nm25.77 Nm
2 kilograms44.88 Nm31.82 Nm
Source, Sartore et al, Nature Machine Intelligence, 2026, figure 4. Maximum estimated torque at the lumbosacral joint, L5 to S1, during collaborative lifting.

The reductions are large, roughly halving the peak spinal load in the lighter cases. And this happened while the robot tracked the human closely, following the hand motion with an average error under one centimetre and a worst case around three centimetres across the trials. Some lag was present, because the robot reacts to the human rather than predicting the next move, but the following stayed smooth and reliable throughout.

The walking side of the story is just as telling, because the very same design choices paid off there. The taller body with the higher centre of mass, chosen partly for ergonomics, also made ergoCub a stronger walker than the iCub3 it grew from.

MetriciCub3ergoCub
Maximum step length0.28 m0.35 m
Minimum step duration0.8 s0.5 s
Height1.25 m1.50 m
Centre of mass height0.59 m0.72 m
Source, Sartore et al, Nature Machine Intelligence, 2026, figures 3 and 5. ergoCub walks with longer, quicker steps than its predecessor.

ergoCub took longer, quicker steps, and it stayed upright under real pushes, adjusting where it planted its feet to recover from shoves estimated at 60 to 100 newtons and from carrying an extra load of several kilograms. The robot that was easier on a human back also turned out to be the more capable walker, which is exactly the kind of happy alignment the joint optimization was hoping to find. For a broader picture of how robots learn to plan stable motion, our review of robot path planning maps the wider landscape.

The ergoCub robot represents a contribution in its own as a tangible realization of the methodology, demonstrating how human representations can be embedded into the robot’s body and physical intelligence to support ergonomic collaboration and robust locomotion. Sartore and colleagues, Nature Machine Intelligence, 2026

Did people actually like it?

A robot meant to work beside people has to be accepted by them, not just measured to be helpful. The team ran an acceptability survey with 850 participants drawn from industry and healthcare, and ergoCub was rated more positively than two other well known robots used as comparisons. Its simplified facial expressions, shown on a flexible screen where a face would be, were consistently preferred over the alternatives. A machine that looks approachable and moves considerately is one people are more willing to stand next to, and that willingness is part of whether the technology ever leaves the lab.

From the lab to the workplace

This is where enthusiasm has to make room for care. The strain reductions reported here are real and carefully measured, but they were gathered in a controlled setting with cooperative volunteers lifting light, well behaved loads over a fixed range of heights. A warehouse or a hospital ward is a messier place, with awkward objects, cramped spaces, unpredictable movements, and long shifts that no short experiment can capture.

The back load figures are also estimates from a biomechanical model, not direct readings from inside anyone’s spine, and they describe the mechanical torque at one joint rather than a person’s actual risk of injury, which depends on many factors the study does not address. Reducing a peak torque in a lab is encouraging, and it is not the same as preventing a back injury on a real job over years of use. The distance between those two things is filled with questions about repeated use, fatigue, individual differences in body and strength, and how workers behave when a robot is genuinely part of their day rather than part of a demonstration.

None of this diminishes the result. It places it correctly. The paper demonstrates a design method and a working robot that lowers a measurable mechanical load, which is a meaningful and necessary step. Turning that into a validated reduction in workplace injury would require long term studies with many workers in real settings, and the authors are clear that such broader user studies and ergonomic validation lie ahead rather than behind.

Key takeaway

The back load numbers are lab measurements of mechanical torque, not a promise about anyone’s injury risk. They show the method works in principle, and they leave the harder question of real workplace benefit for future long term studies.

Where the method falls short

Beyond the gap between lab and workplace, the authors are candid about several technical limits.

The robot’s awareness of its human partner is reactive rather than anticipatory. It responds to where the person is now, which is why small delays appear in its following, and it does not yet forecast where the person is about to move. The authors sketch a future version that would predict the human’s next motion and plan ahead to head off strain before it builds, but that is a design on paper, not a tested feature.

There is also an honest gap between the optimized design and the robot that was actually built. Manufacturing a real machine forced compromises the clean optimization did not anticipate, so the final ergoCub differs from the ideal by a few centimetres in some limbs and a few kilograms in weight, partly because a screen and real electronics had to go somewhere. The team argues, reasonably, that the important whole body properties were preserved, but the difference between the design and the object is a reminder that optimization output is a suggestion, not a finished robot.

The scope is deliberately narrow too. The method was demonstrated on two tasks, collaborative lifting and walking, with a single human partner and simple loads. Extending it to teams of people, to heavy or awkward payloads, and to the full variety of real jobs is future work. And the whole approach rests on models, of the human body, of the robot’s simplified shapes, of the contact forces between them, each a reasonable approximation whose errors feed into the result.

Why it matters

Step back and the contribution is a change in what gets designed. For years the humanoid robot was treated as a finished body that control software had to cope with, and the human it might help was an afterthought. This work folds the human’s wellbeing and the robot’s body and brain into a single optimization, and it proves the idea by building a real machine whose shape was chosen to spare a worker’s back.

The deeper appeal is that the method is a template rather than a one off. The same loop that traded robot torque against human strain could be pointed at other collaborative tasks, other ergonomic measures, or other partners, simply by changing what the optimizer is told to value. Paired with an open release of the models and controllers, that makes ergoCub less a single robot than a worked example of designing machines around the people they serve. As humanoid robots move from spectacle toward genuine coworkers, that reorientation, from optimizing the robot alone to optimizing the partnership, is the shift worth watching. Our look at an octopus inspired soft robot arm shows a different route to the same goal of machines that touch the world gently.

A reference implementation

Because this work is a hardware and control codesign rather than a trainable network, a fabricated neural model would misrepresent it. The code below instead captures the paper’s genuine core in plain Python. It derives a link’s mass, centre of mass, and inertia from its length, builds a small model where the robot’s proportions affect the human’s back torque during a lift, and then runs the weighted codesign optimization that trades robot effort against human strain and walking robustness. The authors full code is linked under the block.

# ergoCub style co-design, faithful reference for the paper computational core
# Link inertia from geometry, then optimize limb lengths to spare the human back.
# This is a hardware and control co-design, not a trained neural network.

import numpy as np
from scipy.optimize import minimize


def cylinder_link(length, radius=0.05, density=2700.0):
    # mass, centre of mass, and inertia of a uniform cylinder, from geometry
    volume = np.pi * radius ** 2 * length
    mass = density * volume
    com = length / 2.0                                   # along the link axis
    inertia = mass * (3 * radius ** 2 + length ** 2) / 12.0
    return mass, com, inertia


def robot_com_height(lengths):
    # stack torso and legs, mass weighted centre of mass height
    heights, masses = [], []
    z = 0.0
    for L in lengths:
        m, c, _ = cylinder_link(L)
        heights.append(z + c)
        masses.append(m)
        z += L
    heights, masses = np.array(heights), np.array(masses)
    return float((heights * masses).sum() / masses.sum())


def human_back_torque(lengths, load=1.0, lift_height=1.0):
    # toy ergonomic model, a taller robot reach lets the human stay upright,
    # which lowers the moment arm at the base of the spine
    reach = robot_com_height(lengths)
    stoop = max(0.0, lift_height - reach)                 # how far the human must bend
    moment_arm = 0.2 + 1.5 * stoop
    return (load + 8.0) * 9.81 * moment_arm               # newton metres at L5 to S1


def robot_torque(lengths, load=1.0):
    # longer, heavier limbs cost the robot more effort to hold the load
    total_mass = sum(cylinder_link(L)[0] for L in lengths)
    return (total_mass + load) * 9.81 * (0.1 + 0.4 * sum(lengths))


def codesign_objective(lengths, w1=1.0, w2=1e5, w3=1.0):
    # weighted sum, human strain carried at the highest weight, as in the paper
    t1 = robot_torque(lengths) ** 2                      # robot effort
    t2 = human_back_torque(lengths) ** 2                 # human ergonomics
    t3 = 1.0 / (robot_com_height(lengths) ** 2 + 1e-6)   # walking robustness
    return w1 * t1 + w2 * t2 + w3 * t3


if __name__ == "__main__":
    x0 = np.array([0.40, 0.40, 0.40])                    # torso and two leg links, metres
    bounds = [(0.30, 0.75)] * 3                           # manufacturability limits on height

    before = human_back_torque(x0)
    result = minimize(codesign_objective, x0, method="L-BFGS-B", bounds=bounds)
    after = human_back_torque(result.x)

    print(f"optimized lengths m   {np.round(result.x, 3)}")
    print(f"robot com height m    {robot_com_height(result.x):.3f}")
    print(f"human back torque Nm  {before:.1f} then {after:.1f}")

Go to the source

Read the peer reviewed paper and explore the authors open code and models.

Read the paper Code on GitHub

Conclusion

The core achievement here is a humanoid robot whose body was chosen to help a human, not merely to move on its own. By writing the robot’s dynamics as a function of its limb lengths and folding the human partner’s back load into the optimization at a high weight, the team let a shared lifting task decide the robot’s shape, then built the real ergoCub from that answer. In collaboration it roughly halved the peak mechanical load on a worker’s spine in the lighter cases, and the same design made it a more capable walker.

The conceptual shift worth remembering is that the human belongs inside the optimization. Robotics has long designed the body first and worried about the collaboration later, and this work inverts that order, treating the person’s wellbeing and the robot’s hardware and control as one coupled problem. The elegant part is that the choices which spared the human, chiefly a taller frame with a higher centre of mass, also improved locomotion, so ergonomics and capability pulled in the same direction rather than fighting.

The approach travels because it is a method, not a single robot. The same loop could balance different tasks, different ergonomic measures, or different partners by changing what the optimizer values, and the open release of the underlying models and controllers invites exactly that reuse. As humanoid robots edge toward real work beside people, a design philosophy that starts from the partnership is the more promising foundation.

The honest limits keep the result in proportion. The robot reacts to the human rather than anticipating them, the built machine differs from its optimized design, the demonstrations cover a narrow slice of tasks and partners, and, most importantly, the back load figures are lab measurements of mechanical torque rather than proof of reduced injury in a real workplace. The road from a measured torque reduction to a genuinely safer job runs through long term studies this work does not attempt.

Future directions follow naturally. Give the robot the ability to predict a partner’s next move and plan ahead to prevent strain, extend the method to teams and to heavier, more awkward loads, and, above all, take it into real industrial and care settings for the long observation that turns a promising measurement into a trustworthy benefit. If those steps hold up, the tired backs at the end of a long shift might finally get some help, from a robot that was designed with them in mind from the start.

Frequently asked questions

What is ergoCub?

ergoCub is a humanoid robot developed by the Istituto Italiano di Tecnologia with the Italian workplace injury institute. It has 36 degrees of freedom, stands 150 centimetres tall, weighs 56.7 kilograms, and was designed to lift loads alongside people while reducing the strain on the human partner.

What does designing the robot around the human mean?

It means putting the human partner into the optimization that chooses the robot’s shape and control. The robot’s limb lengths and control gains were selected to lower the human’s back load during a shared lift, rather than only to make the robot move well by itself.

How much did it reduce human back strain?

In collaborative lifting the peak mechanical torque at the base of the human’s spine dropped substantially, for example from about 44 to 25 newton metres when lifting a one kilogram box. These are experimental biomechanical measurements, not a claim about any person’s injury risk.

Is ergoCub a medical or safety device?

No. It is a research robot, and the ergonomic figures come from a controlled study rather than real workplaces. The results show the design method works in principle, and turning that into proven injury prevention would require long term studies in real settings.

Did designing for ergonomics hurt the robot’s other abilities?

No, it helped. The taller body with a higher centre of mass, chosen partly for ergonomics, also let ergoCub walk with longer, faster steps and stay upright under pushes, outperforming the earlier iCub3 robot it was based on.

Can the code and models be reproduced?

Yes. The authors released their code, models, and controllers on GitHub and Zenodo under an open licence, so the design method and results can be studied and extended.

Sartore, C., Elobaid, M., Rapetti, L., Romualdi, G., Dafarra, S., Piga, N. A., Sorrentino, I., Viceconte, P. M., Traversaro, S., Pattacini, U., Fiorio, L., Draicchio, F., Tranfo, G., Natale, L., Maggiali, M. and Pucci, D. Towards shared embodied intelligence in humanoid robots through optimization, development and testing of the human-aware ergoCub robot. Nature Machine Intelligence 8, 1221 to 1237 (2026). DOI 10.1038/s42256-026-01272-2. Open access under CC BY-NC-ND 4.0. Code and data at GitHub and Zenodo. This analysis is based on the published paper and an independent evaluation of its claims.

Leave a Comment

Your email address will not be published. Required fields are marked *