1. What robot simulation and digital twins are (the short version)

• A simulator is a “copy of the real machine”: you enter values such as shape, mass, friction and stiffness, and it solves the equations of physics a little at a time, one time step after another, to reproduce the motion of robots and objects inside a computer. It is useful, but what you did not enter is not reproduced. Contact (things touching) is a particularly hard partSourced[Ref. 2]
• There is a speed-versus-accuracy trade-off in the calculation: a larger time step is faster but less stable. In our calculation the same spring, depending on step size and integration method, diverged in some cases and in others was numerically damped awayOur calculation. The stiffer the contact material, the smaller the step needed
• A digital twin is not the same as a simulator: a digital twin is described as a digital counterpart that exchanges data two ways with the real object and is updated by itSourced[Ref. 21]. It is distinguished from a one-way “shadow” and from a “model” built by people, and it has been pointed out that the term has no common understanding yet [Ref. 20]

2. What simulation is used for

There are four main uses. All of them start from the fact that “doing it on the real thing is heavy in time, cost and safety”.

Each example is a report by its developers or authors; conditions differ, so we do not compare the numbers. The “Notes” column is this article’s arrangement (commentary).

Original SVG, detailed explanation and sources

Original SVG reference: Conceptual diagram (vector drawing). An arrangement of the cycle: measure the real machine and build a model, learn, evaluate and design in a simulator, try the result on the machine, and feed the gap back to the model. Some studies measure the gap to adjust the randomisation distribution [Ref. 15]. It is not the architecture of any particular software.

3. What a physics engine does in one step

The part of a simulator that computes forces, contacts and motion is called the physics engine. One step goes: (1) from the current state (positions and velocities), (2) find what is touching (contact), (3) compute contact forces, friction and joint forces, (4) advance by the time step dt, and (5) obtain the new state. This is repeated over and over.

(1) The time step: a tug of war between “speed” and “stability”

The official MuJoCo documentation gives the default time step as 0.002 s and describes it as the single most important value for the speed-accuracy trade-off. Smaller values raise accuracy and stability but need more computation to advance the same time [Ref. 3]Sourced. To run in real time, that means calculating one second of motion in 500 steps (the inverse of 0.002 s)Our calculation.

(2) Contact: treated as “soft”

When objects touch, even hard materials in reality deform slightly and transmit force. The official MuJoCo documentation says that all physical materials deform somewhat and that the contacting parts of robots are often designed to be soft, and explains that contact is treated with a “soft contact” model that allows slight penetration. Constraint forces are defined as the solution of a convex optimisation problem. The default friction cone is pyramidal [Ref. 2]Sourced.

4. Seeing it in numbers — time step and contact stiffness

Why does the time step decide stability? Let us check with a spring. A mass of 0.5 kg is supported by a spring of 10⁵ N/m (the larger the number, the stiffer the spring) and starts pushed in by 1 mm (an assumption). This is a simplified example of a “stiff contact”. We calculated this oscillation for 0.2 s, varying the time step and the integration method.

The results are as follows (Our calculation).

• Explicit Euler (1 ms): the energy grows to about 7 x 10¹⁵ times its start and the calculation diverges. It is a very simple method, but not suited to oscillating systems
• Semi-implicit Euler (1 ms): the energy stays within about 1.3 times the start, nearly conserved. MuJoCo’s default integrator is this semi-implicit Euler method [Ref. 3]
• Semi-implicit Euler (4 ms): close to the stability limit (ω x dt < 2; here about 1.79) and wobbles up to about 9.5 times
• Semi-implicit Euler (5 ms): ω x dt is about 2.24, beyond the limit, and diverges to about 10³⁴ times
• Implicit Euler (5 ms): it does not diverge, but the energy vanishes artificially (in a system that should keep oscillating). Read it as having dulled the motion for the sake of stability

Our calculation. Assumed mass 0.5 kg, spring constant 10⁵ N/m, initial displacement 1 mm, no damping. Natural angular frequency ω = √(k/m) = about 447 rad/s (period about 14 ms). Not values for any real material or simulator.

The stiffer the contact, the smaller the time step needed

From the condition that semi-implicit Euler stays bounded, ω x dt < 2, the limit of dt is 2√(m/k). Here is the limit for the same mass of 0.5 kg as the contact stiffness k changes (Our calculation).

Our calculation. The spring constants are assumed values, not those of any particular material or device. Real physics engines treat contacts softly, and the stability condition depends on settings [Ref. 2].

5. The main simulators — reading the official descriptions

We sort representative simulators used in robotics by their official descriptions. We do not rank them. The “suited to” column is this article’s arrangement.

The table is Sourced from the descriptions in official documentation and papers (licences were checked through GitHub’s public API or the official documentation, 25 October 2026). The “suited to” column is this article’s arrangement (commentary). There are many other simulators, but we limit ourselves to what we could confirm.

GPU parallelism: orders of magnitude more trials in the same time

The Isaac Gym paper reports that running physics simulation and policy training together on the GPU gave a speed-up of two to three orders of magnitude over conventional simulators running on the CPU [Ref. 8]Sourced. Rudin et al. report that with this approach an ANYmal walking policy could be learned on uneven terrain in 20 minutes [Ref. 9]. Running many environments at once makes possible a quantity of trials that is impossible on real machines. These speed figures, however, are for the tasks and computers chosen by their developers and authors (commentary).

6. Synthetic data — making “teaching material” by computer

A simulator can produce not only motion but also training data. The main ways of using it are as follows.

• Images with varied appearance: Tobin et al. report that a real-world object detector accurate to 1.5 cm could be learned from simulator images with only non-realistic random textures [Ref. 13]. Isaac Sim describes a framework for synthetic data generation (Replicator) [Ref. 6]Sourced
• Many demonstrations from a few: MimicGen converted about 200 human demonstrations to fit new scenes, objects and robot arms and automatically produced over 50,000 demonstrations on 18 tasks (about 250 times as many). It reports that imitation learning on this synthetic data gave strong performance on long-horizon and high-precision tasks, comparing favourably with collecting additional human demonstrations [Ref. 17]SourcedOur calculation (250 times = 50,000 / 200)
• Large-scale environments: RoboCasa is a large-scale simulation centred on kitchens, with thousands of 3D assets in over 150 object categories, and reports a trend of improving performance with the amount of synthetic data [Ref. 18]Sourced

7. The gap to the real machine — measuring material properties is the key

The gap between simulation and the real machine (the reality gap) has many causes. Here we focus on material properties that can be shrunk by measurement. The overall arrangement of the causes is in Chapter 4 of our article on world models and embodied AI.

The table is this article’s arrangement (commentary), and the “how to measure or respond” entries are general examples. That Isaac Lab provides actuator models is stated in its paper, and that friction is randomised is stated in the OpenAI paper.

A calculation of how a friction error affects the grip force

Let us see the size of a friction-coefficient error with a simple example. To lift an object pinched between two fingers without slipping, the force N each finger needs follows from the condition that the friction force 2μN of the two fingers supports the object’s weight mg: N = mg / (2μ) (a formula with no safety factor). Take an object of 0.5 kg whose friction coefficient is 0.5 in the simulator and 0.3 on the real machine.

• Simulator (μ = 0.5): N = 0.5 x 9.81 / (2 x 0.5) = about 4.9 N
• Real machine (μ = 0.3): N = 0.5 x 9.81 / (2 x 0.3) = about 8.2 N (about 1.67 times the simulator’s)
• So a policy that learned in simulation that “about 5 N is enough” may drop the object on a real machine whose friction coefficient is 0.3Our calculation

Our calculation. Mass 0.5 kg, gravitational acceleration 9.81 m/s², friction coefficients 0.5 and 0.3 are illustrative assumptions, not values of real materials. Real grasping also involves finger shape, contact area and dynamic forces; this is a simplification.

The gap in evaluation: a simulated score is no substitute for a real-machine score

SIMPLER built simulation environments paired with real-robot policy evaluation and reports that, in paired evaluations, policy performance correlated strongly between the two and that behaviours such as sensitivity to distribution shift were also reflected. This is a result for particular robot set-ups and does not necessarily hold for all [Ref. 19]Sourced. An overview of sim2real methods is organised in the survey by Zhao et al. [Ref. 16].

8. What a digital twin is — meaning and limits

“Digital twin” is a widely used term, but its meaning varies. Kritzinger et al. divide the manufacturing literature by level of integration into digital model, digital shadow and digital twin, and state that there is no common understanding of the term and that papers at the most advanced level, the digital twin, are scarce [Ref. 20]Sourced. A report of the US National Academies of Sciences, Engineering, and Medicine describes a digital twin as something that couples a computational model with a physical counterpart and is updated through bidirectional data flows [Ref. 21]Sourced.

An international standard for manufacturing

In manufacturing, the ISO 23247 series sets out a framework for digital twins. ISO 23247-1:2021 covers an overview and general principles of the digital-twin framework for manufacturing (terms and requirements), and ISO 23247-2:2021 a reference architecture (a reference model from domain and entity viewpoints, and a functional view) [Ref. 22, 23]Sourced. We did not read the text, which is paid, and it is not a standard specific to simulators for robot learning.

Limits: why a digital twin is not all-powerful

• Scope of the model: a twin reproduces only the phenomena put into it. Simplifications of friction or deformation lead to wrong decisions (Chapters 3 and 7)
• Quality and updating of data: if the sensor data representing the real object’s state are delayed, off or missing, the twin drifts away from the real object (commentary)
• Degradation of the real object: wear, contamination and ageing change the real object, so the twin’s values must keep being updated (this is this article’s general view)
• How the word is used: something called a “digital twin” may in fact be a model built by people or a one-way shadow. Check whether data flow both ways and whether predictions and decisions return to operation

9. Limits, and what could not be confirmed / summary

(1) Comparing simulators

The speed and accuracy of each simulator are the developers’ or authors’ statements and not a like-for-like comparison. We did not confirm independent third-party comparisons. Words such as “fastest” and “high fidelity” are treated as developers’ claims, and we do not rank them.

(2) Calculations from assumed values

The numbers in Chapters 4 and 7 are arithmetic on assumptions we made (mass, spring constant, friction coefficient), not values for real materials, devices or simulators. The stability condition ω x dt < 2 is that of semi-implicit Euler for a simple spring; the stability conditions of real engines are more complicated.

(3) The text of standards

We did not read the text of ISO 23247. We could not confirm an international standard that defines the fidelity of robot simulators.

(4) The text of Kritzinger et al.

The publisher’s page refused automated access, so we cite only within the bibliographic data and abstract. We did not check the text for the detailed definitions of the three levels.

(5) What we did not cover

Multiscale simulation of materials is in our materials-informatics series and the details on the learning side in our article on imitation and reinforcement learning. We do not cover market size or prices.

10. How to read the yardsticks and standards

The basic yardstick for a simulator is how well it corresponds to the real machine (correlation, or differences in results). Speed (steps per second), stability (does it diverge?) and reproducibility (does it give the same result?) matter too. For digital twins there is a framework standard for manufacturing (checked 25 October 2026).

The arrangement of the table is Our calculation (organising). Numbers, titles, dates and stages of ISO standards were checked on the official ISO pages (25 October 2026). The text of the standards is paid, so we stay with titles and scope.

Notes on reading (for materials engineers)

• Simulation results follow the correctness of the values entered: check whether friction, stiffness and damping are measured or provisional values, and match the measurement conditions (load, surface state, temperature)
• A developer’s speed and accuracy are the developer’s claims: tasks and computers differ, so do not rank by lining up the numbers
• Is a standard a requirement or a framework? ISO 23247 is a framework for digital twins in manufacturing and does not guarantee the fidelity of a simulator for robot learning
• Watch the words “digital twin”: check whether data flow in both directions and whether predictions and decisions return to operation

11. Glossary

12. References

1. Todorov E., Erez T., Tassa Y. “MuJoCo: A physics engine for model-based control”, IEEE/RSJ IROS 2012, 5026–5033, DOI 10.1109/IROS.2012.6386109 — doi.org/10.1109/IROS.2012.6386109
2. Google DeepMind MuJoCo documentation, “Computation” (soft contact model, constraint solver). Checked 25 October 2026 — mujoco.readthedocs.io (computation)
3. Google DeepMind MuJoCo documentation, “XML Reference” (option: timestep, integrator). Checked 25 October 2026; values confirmed in the documentation source on GitHub — mujoco.readthedocs.io (XML reference)
4. Google DeepMind GitHub repository “google-deepmind/mujoco” (Apache License 2.0). Licence confirmed through GitHub’s public API (25 October 2026) — github.com/google-deepmind/mujoco
5. Zakka K. et al. “MuJoCo Playground”, arXiv:2502.08844 (2025) — arxiv.org/abs/2502.08844
6. NVIDIA Isaac Sim documentation (overview). Checked 25 October 2026 — docs.isaacsim.omniverse.nvidia.com
7. NVIDIA et al. “Isaac Lab: A GPU-Accelerated Simulation Framework for Multi-Modal Robot Learning”, arXiv:2511.04831 (2025) — arxiv.org/abs/2511.04831
8. Makoviychuk V. et al. “Isaac Gym: High Performance GPU-Based Physics Simulation For Robot Learning”, arXiv:2108.10470 (2021) — arxiv.org/abs/2108.10470
9. Rudin N. et al. “Learning to Walk in Minutes Using Massively Parallel Deep Reinforcement Learning”, arXiv:2109.11978 (2021) — arxiv.org/abs/2109.11978
10. Koenig N., Howard A. “Design and use paradigms for Gazebo, an open-source multi-robot simulator”, IEEE/RSJ IROS 2004, 2149–2154, DOI 10.1109/IROS.2004.1389727 — doi.org/10.1109/IROS.2004.1389727
11. Gazebo / Open Robotics GitHub repository “gazebosim/gz-sim” (Apache License 2.0). Licence confirmed through GitHub’s public API (25 October 2026) — github.com/gazebosim/gz-sim
12. Tao S. et al. “ManiSkill3: GPU Parallelized Robotics Simulation and Rendering for Generalizable Embodied AI”, arXiv:2410.00425 (2024) — arxiv.org/abs/2410.00425
13. Tobin J. et al. “Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World”, arXiv:1703.06907 (2017) — arxiv.org/abs/1703.06907
14. OpenAI et al. “Learning Dexterous In-Hand Manipulation”, arXiv:1808.00177 (2018) — arxiv.org/abs/1808.00177
15. Chebotar Y. et al. “Closing the Sim-to-Real Loop: Adapting Simulation Randomization with Real World Experience”, arXiv:1810.05687 (2018) — arxiv.org/abs/1810.05687
16. Zhao W., Queralta J. P., Westerlund T. “Sim-to-Real Transfer in Deep Reinforcement Learning for Robotics: a Survey”, arXiv:2009.13303 (2020) — arxiv.org/abs/2009.13303
17. Mandlekar A. et al. “MimicGen: A Data Generation System for Scalable Robot Learning using Human Demonstrations”, arXiv:2310.17596 (2023) — arxiv.org/abs/2310.17596
18. Nasiriany S. et al. “RoboCasa: Large-Scale Simulation of Everyday Tasks for Generalist Robots”, arXiv:2406.02523 (2024) — arxiv.org/abs/2406.02523
19. Li X. et al. “Evaluating Real-World Robot Manipulation Policies in Simulation” (SIMPLER), arXiv:2405.05941 (2024) — arxiv.org/abs/2405.05941
20. Kritzinger W. et al. “Digital Twin in manufacturing: A categorical literature review and classification”, IFAC-PapersOnLine 51(11), 1016–1022 (2018), DOI 10.1016/j.ifacol.2018.08.474. Bibliographic data and abstract confirmed (via Semantic Scholar); the publisher’s page refused automated access — doi.org/10.1016/j.ifacol.2018.08.474
21. National Academies of Sciences, Engineering, and Medicine “Foundational Research Gaps and Future Directions for Digital Twins” (2024), DOI 10.17226/26894. Checked 25 October 2026 — nationalacademies.org/publications/26894
22. ISO ISO 23247-1:2021 “Automation systems and integration — Digital twin framework for manufacturing — Part 1: Overview and general principles” (Edition 1, October 2021). Checked 25 October 2026 — iso.org/standard/75066.html
23. ISO ISO 23247-2:2021 “Automation systems and integration — Digital twin framework for manufacturing — Part 2: Reference architecture” (Edition 1, October 2021). Checked 25 October 2026 — iso.org/standard/78743.html

13. Claim-to-source audit

Last updated: 25 October 2026 / Sources are limited to primary material (arXiv papers, official documentation, public GitHub information, the official ISO pages and a report of the US National Academies). We could not read the text of the ISO standards or of the paper by Kritzinger et al. The numerical examples are calculations from values we assumed and are not the performance of any real material, device or simulator. We could not confirm, and so do not state, an international standard defining the fidelity of robot simulators, independent comparisons of simulators, or measured friction values for real machines. Figures 1 and 7 are ImageGen-generated conceptual illustrations; the other figures are explanatory concept diagrams or figures containing our calculations.