Robot Gyms vs Simulation: Why Physical AI Still Needs Real Robot Data, with Python Code

Near Munich Airport there is now a gym for robots. The TUM RoboGym, opened in October 2026 by NEURA Robotics and the Technical University of Munich, covers more than 2,300 square metres and cost about €17 million. Companies from more than ten industries bring real jobs there, such as stacking cardboard boxes, filling bottles and loading wooden parts, and robots practise them over and over while people guide them and the data is recorded.

Munich is late to this idea. China has at least 90 humanoid data collection centres operating, planned or under construction, according to Interact Analysis, and the largest has about 200 robots. Europe has fewer than ten. NEURA's chief executive David Reger compares it to learning to swim: you have to get in the water, not just watch videos.

That raises an obvious question. Simulators are cheap, fast and never break. Why would anyone spend €17 million on a building full of real robots? This post explains the gap between simulation and the real world, what the main tricks for closing it can and cannot do, and why the answer in 2026 is "both". A short Python example puts numbers on it: a robot trained only in simulation succeeds 0% of the time on a real floor, while the same simulator plus three real attempts reaches 84%.

Robot gyms at a glance

What a robot gym is	A facility where many robots practise real tasks while people guide them, so their attempts can be recorded as training data
In the news	TUM RoboGym in Munich, opened October 2026 by NEURA Robotics and TUM, over 2,300 m², about €17 million
How data is collected	Teleoperation, people wearing sensor suits, motion capture, and simulation to create extra variations
The scale in China	At least 90 data collection centres, robots from at least 30 makers, the largest with about 200 robots
Why not only simulation	Simulators get some numbers wrong, such as friction, and a robot trained on wrong numbers fails in ways it cannot notice
Our Python result	Simulation only 0%, domain randomization 5%, simulation plus 3 real attempts 84%, best possible 92%

What happens inside a robot gym

A robot gym is closer to a training ground than a factory. In Munich, data comes from three sources. Robots run real tasks. People demonstrate tasks, wearing sensor suits, under motion capture, or by teleoperating a robot from a distance. Simulation then creates extra variations of each task, and those are checked again on physical robots. NEURA feeds the data into Neuron AI, its model that takes in vision, touch, force and sound, and runs on its new 4NE1 Gen 4 humanoid, which is about 20% lighter than the previous version.

NEURA is collecting data outside the gym too. According to The New York Times, it is giving more than 1,000 Bosch workers sensor suits to record their movements during normal shifts.

The Chinese centres mostly follow one model: many robots in one building, controlled remotely by human operators who record demonstrations. Interact Analysis counted at least 13 operating centres with over 100 robots each. In 2026 some started a second approach, crowdsourcing first person video of people doing ordinary work, the same idea we covered in our article on robots learning from human video.

All of this exists for one reason. Robot learning methods such as imitation learning and Diffusion Policy need demonstrations, and there is no internet of robot actions to download. Someone has to make the data.

The sim to real gap

A simulator is a physics model written by people. It is fast and safe, and it can run thousands of copies at once. But it is wrong in small ways that matter:

• Friction and contact. How much a box slides, or whether a grasp slips, depends on surfaces, dust and wear that no simulator models exactly.
• Soft and fluid things. Cloth, cables, food and liquids are hard to simulate well.
• Sensors. Real cameras have glare, blur and noise. Real force sensors drift.
• The robot itself. Motors heat up, gears have play, and two copies of the same robot never behave quite the same.

A policy trained in a simulator learns that simulator's numbers. If the simulator says the floor is slippery and the real floor is not, the robot pushes too softly every time, and nothing in its training tells it something is wrong. This is called the sim to real gap.

Three ways to close the gap

1. Domain randomization

Instead of one simulator, train on thousands of slightly different ones: random friction, random masses, random lighting, random camera positions. The idea, made popular by Tobin and colleagues in 2017, is that if the policy works across all of them, the real world will look like one more variation. OpenAI used a strong version of it in 2019 to teach a robot hand to solve a Rubik's cube.

The catch is easy to miss. Domain randomization works when the policy can sense which world it is in and react, for example by noticing that an object slips and gripping harder. If the robot gets one shot with no feedback, the best a randomized policy can do is aim for the average world. Our Python example shows exactly that.

2. Calibrating the simulator with real data

Keep the simulator's physics, but measure its wrong numbers on the real robot. A few real attempts can tell you the true friction, mass or motor strength, and the simulator can then be corrected. This is often called system identification. It is cheap when the simulator has the right structure and only a few numbers are off.

3. Training on simulated and real data together

Large robot models now mix both: lots of simulated data for variety, plus real data to keep the policy honest. RL-Co, which we covered in Beyond Imitation, trains in simulation while keeping a loss on real demonstrations, and it lifted real world success for OpenVLA from 40% to 64%. Robot gyms like the one in Munich are built for this loop: generate variations in simulation, then check them on real robots.

A Python example: pushing a box

The example below is deliberately small so every number can be checked. A robot pushes a box across a floor so that it stops at a target between 0.5 and 2 m away. The only choice is how fast to push. Friction then slows the box to a stop. A push counts as a success if the box stops within 5 cm of the target.

The simulator assumes floor friction of 0.25. The real floor is 0.35, and it changes slightly from push to push. We compare four ways to train:

1. Simulation only. Invert the simulator's physics exactly.
2. Domain randomization. Train on simulated floors with friction anywhere from 0.1 to 0.5, with no real data.
3. Real data only. No simulator. Fit a flexible curve to real pushes.
4. Simulation plus real calibration. Keep the simulator's physics and use real pushes only to estimate the true friction.

The code needs only NumPy and runs in a few seconds.

import numpy as np

# A robot slides a box across a floor to a target 0.5 to 2.0 m away.
# It chooses one number: how fast to push. Friction then stops the box.
# The simulator thinks the floor friction is 0.25. The real floor is 0.35,
# and it changes a little from push to push (dust, wear, a different box).
G, TOL = 9.81, 0.05                       # success = box stops within 5 cm
SIM_MU, REAL_MU, REAL_SPREAD = 0.25, 0.35, 0.007


def slide(v, mu):
    # distance a box slides from speed v with friction mu
    return v ** 2 / (2 * mu * G)


def real_push(rng, v):
    mu = REAL_MU + rng.normal(0, REAL_SPREAD, np.shape(v))
    return slide(v, mu) + rng.normal(0, 0.01, np.shape(v))  # sensor noise


def success_rate(policy, rng, n=2000):
    d = rng.uniform(0.5, 2.0, n)
    return np.mean(np.abs(real_push(rng, policy(d)) - d) < TOL)


# 1. simulation only: invert the simulator's physics exactly
def sim_only():
    return lambda d: np.sqrt(2 * SIM_MU * G * d)


# 2. domain randomization: train on many simulated floors, mu from 0.1 to 0.5
def domain_randomized(rng, n=5000):
    mu = rng.uniform(0.1, 0.5, n)
    v = rng.uniform(0.5, 6.0, n)
    d = slide(v, mu)
    keep = (d > 0.4) & (d < 2.1)
    # fit speed as a function of target distance across all floors
    coef = np.polyfit(np.sqrt(d[keep]), v[keep], 1)
    return lambda x: np.polyval(coef, np.sqrt(x))


# 3. real data only: no simulator, fit a curve to real pushes
def real_only(rng, n_trials):
    v = rng.uniform(1.5, 4.5, n_trials)
    d = real_push(rng, v)
    coef = np.polyfit(d, v, min(3, n_trials - 1))  # flexible cubic curve
    return lambda x: np.polyval(coef, x)


# 4. simulation + a few real trials: keep the simulator's physics,
#    use real pushes only to correct its one wrong number (friction)
def sim_plus_real(rng, n_trials):
    v = rng.uniform(1.5, 4.5, n_trials)
    d = real_push(rng, v)
    mu_est = np.mean(v ** 2 / (2 * G * d))
    return lambda x: np.sqrt(2 * mu_est * G * x)


if __name__ == "__main__":
    rng = np.random.default_rng(0)
    print(f"{'method':<34}{'real trials':>12}{'success':>9}")
    print(f"{'simulation only':<34}{0:>12}{success_rate(sim_only(), rng):>9.0%}")
    print(f"{'domain randomization':<34}{0:>12}"
          f"{success_rate(domain_randomized(rng), rng):>9.0%}")
    for n in [1, 3, 10, 30, 100]:
        a = np.mean([success_rate(real_only(rng, n), rng) for _ in range(20)])
        b = np.mean([success_rate(sim_plus_real(rng, n), rng) for _ in range(20)])
        print(f"{'real data only':<34}{n:>12}{a:>9.0%}")
        print(f"{'simulation + real calibration':<34}{n:>12}{b:>9.0%}")

Running it prints:

method                             real trials  success
simulation only                              0       0%
domain randomization                         0       5%
real data only                               1       5%
simulation + real calibration                1      78%
real data only                               3      48%
simulation + real calibration                3      84%
real data only                              10      84%
simulation + real calibration               10      90%
real data only                              30      90%
simulation + real calibration               30      92%
real data only                             100      91%
simulation + real calibration              100      92%

Simulation only fails every single time. The simulator thinks the floor is slippery, so the robot pushes too softly and the box always stops short. The policy is perfectly trained, on the wrong world.

Domain randomization barely helps here, at 5%. It learns to aim for a floor in the middle of its range, which is still wrong for this real floor. The robot has one push and no feedback, so it cannot work out which floor it is on. A robot that could watch the box slide and push again would get far more out of randomization.

Simulation plus a few real pushes wins early. With one real push, it is right 78% of the time. With three it reaches 84%, and it gets close to the best possible score of 92% within about ten. The simulator supplied the shape of the problem, how distance grows with speed, and the real pushes supplied the one number it had wrong.

Real data only gets there too, but it needs more pushes. It starts at 5% with one push, reaches 48% with three and 84% with ten. With no simulator, it has to learn the shape of the curve from data as well as the numbers.

This toy problem has one wrong number. A real humanoid has thousands: every joint, every contact, every sensor. The gap between "real data only" and "simulation plus real data" grows quickly as the task gets harder, and so does the amount of real data needed to fill it. That is the business case for robot gyms. They do not replace simulation. They make the real data that keeps it honest.

What still does not work

• Real data is slow and costly. A robot gym produces data at the speed of real time, one attempt after another, with people supervising. Simulation produces it thousands of times faster.
• Data from one gym may not transfer. A task learned on one robot model, in one building, under one kind of lighting, can fail somewhere else. Most centres collect data on specific robots, and the robots keep changing.
• Quality is hard to measure. Many hours of teleoperation can still be the wrong hours: too easy, too repetitive, or from operators who do the task in odd ways.
• Simulation for contact is still weak. Cloth, cables and tight assembly remain hard to simulate, which is exactly where real data is most needed.
• Nobody knows the right mix yet. How much simulation, how much real data and how much human video a good robot model needs is one of the open questions of 2026.

Frequently asked questions

Closing thoughts

For a few years the hope was that robots could learn everything in simulation and arrive in the real world ready. That hope has not disappeared, and simulators keep getting better. What changed in 2026 is that the industry decided not to wait. It is building gyms, filling them with robots, and paying people to show those robots what to do.

If you run the example, try giving the robot two pushes with feedback after the first, or adding a second unknown such as the box's starting speed, and watch how much more real data each method needs. We would like to hear what you find.

References

• NEURA Robotics, TUM RoboGym opens in Munich with 4NE1 Gen 4, October 2026. neura-robotics.com
• Robotics and Automation News, Neura Robotics and TUM open €17 million RoboGym and unveil new humanoid, October 2026. roboticsandautomationnews.com
• J. Paton, In the AI "robogym", machines train to be more like humans, The New York Times, republished by The Star, October 2026. thestar.com.my
• Interact Analysis, An Overview of Over 90 Humanoid Robot Data Collection Centers in China, May 2026. note.com
• J. Tobin, R. Fong, A. Ray, J. Schneider, W. Zaremba and P. Abbeel, Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World, IROS 2017. arXiv:1703.06907
• OpenAI, I. Akkaya and others, Solving Rubik's Cube with a Robot Hand, 2019. arXiv:1910.07113
• L. Shi, S. Chen and others, Beyond Imitation: Reinforcement Learning-Based Sim-Real Co-Training for VLA Models, 2026. arXiv:2602.12628