Simulation and digital twins

Overview

A simulator lets you test software before the hardware exists, run thousands of trials overnight, train learned policies and catch regressions in continuous integration. It never matches the real robot exactly. The skill is knowing which differences matter for your task and closing those. A digital twin goes one step further: a simulation model of one specific installation, kept in step with the real system and used to plan, commission or monitor it. This hub is for engineers choosing a simulator, or wondering why a controller that worked in simulation fails on the bench.

Key ideas

What a robot simulator computes

A robot simulator integrates rigid-body dynamics, resolves contacts, models sensors and usually renders images. The robot is described in a file format such as URDF, SDF or MJCF. Contact is the hard part. Engines differ in how they detect contacts, model friction and solve for contact forces, and the results change with the time step and solver settings. A grasp that holds in one engine can slip in another. Rendering matters when cameras feed a perception model. Physics matters when forces, impacts or balance decide success. Few tools are best at both, which is why teams often use more than one.

Choosing a simulator, and what runs on a Mac

Pick by the job. Gazebo is the simulator that ROS 2 distributions pair with (Lyrical lists Gazebo Jetty), and suits testing a full ROS 2 system with simulated sensors. Isaac Sim offers RTX rendering and synthetic data generation, and the Isaac Lab learning framework can run on it. MuJoCo was built for model-based control and suits control and reinforcement learning work. Drake describes itself as a toolbox for model-based design and verification. PyBullet is a light Python option. Webots is a complete desktop application with a graphical interface.

Platform support differs, and each project’s own documentation is explicit. Isaac Sim’s requirements page lists Ubuntu 22.04 and 24.04 and Windows 11 on x86-64, plus DGX OS on NVIDIA DGX Spark. It does not list macOS, and it does not support GPUs without RT cores. Gazebo Jetty is officially supported only on Ubuntu Noble and Ubuntu Resolute on amd64. Its install page lists macOS, Windows and arm only as best effort. MuJoCo ships prebuilt binaries for macOS on x86-64 and arm64. Drake supports macOS on arm64, Webots lists macOS releases in its system requirements, and the Bullet README says it is tested on macOS. On a Mac, use MuJoCo, Drake, PyBullet or Webots natively, and run Isaac Sim on a Linux or Windows machine with an RTX GPU.

The sim-to-real gap

The sim-to-real gap has a few usual sources. Actuators are the largest: motor torque limits, gearbox friction, backlash, compliance and communication latency are often missing from the model. Contact and friction parameters are uncertain and change with wear and dirt. Sensors differ in noise, delay and, for cameras, appearance. Two tools close the gap. System identification fits model parameters to logged data from the real robot. Domain randomisation varies whatever cannot be pinned down, so the controller learns to cope with a range. Tobin et al. (2017) trained an object detector only on images with random, unrealistic textures and, according to the authors, reached 1.5 cm accuracy on real images. Peng et al. (2018) randomised dynamics for a pushing task and moved the policy to a real arm without further training. Tan et al. (2018) combined both for quadruped gaits, with an identified actuator model, simulated latency and randomised physics.

Digital twins

A digital twin models one particular system, such as a work cell with its robots, fixtures, conveyors and control logic. Engineers use it to check reach and cycle time before installation, to commission robot programs and PLC logic against a virtual cell, and to replay faults. The value depends on how closely the model is kept in step with the real cell. A twin built once at design time and never updated is a simulation, not a twin.

Where to start

Simulate an arm in MuJoCo loads an inline MJCF model and steps it without a viewer. The two-link arm project and the PyBullet pick-and-place project build complete simulated tasks. The URDF and MJCF reference covers both formats, and the software matrix compares tools. The MuJoCo platform page and NVIDIA platform page go further on each ecosystem.

Tools and platforms

Common mistakes

• Trusting default friction, damping and joint limits. Measure them, or at least randomise them.
• Modelling motors as ideal torque sources. Add torque limits, a velocity-dependent torque curve and latency.
• Using a large time step for speed, then debugging contact chatter that the time step caused.
• Comparing simulators on one scenario. Check the behaviours your task depends on.
• Training on perfectly rendered images and deploying to a camera with blur, glare and a different white balance.
• Buying an RTX-only simulator for a team that works on Macs, without a Linux machine to run it.

Going deeper

• Todorov, Erez and Tassa, MuJoCo: A physics engine for model-based control, IROS 2012.
• Koenig and Howard, Design and use paradigms for Gazebo, an open-source multi-robot simulator, IROS 2004.
• Tobin et al., Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World, 2017.
• Peng et al., Sim-to-Real Transfer of Robotic Control with Dynamics Randomization, 2018.
• Tan et al., Sim-to-Real: Learning Agile Locomotion For Quadruped Robots, 2018.
• Platform pages: Isaac Sim requirements, Gazebo installation, MuJoCo programming guide, Drake installation and Webots system requirements.