Webots is an open-source, general-purpose robot simulator for modeling, programming and testing robots in a 3D virtual environment. In robotics simulation it occupies the space of an all-in-one desktop application: it combines a scene editor, a rigid-body physics engine, sensor and actuator models, and a controller runtime in a single program that runs on Windows, macOS and Linux.
Originally developed at the Swiss Federal Institute of Technology in Lausanne and maintained by Cyberbotics, Webots has been released under the Apache 2.0 license since the end of 2018. It is widely used in education, research and early product development, especially for mobile robots, small manipulators and swarm experiments.
How Webots structures a simulation
A Webots simulation is described by a world file with the extension wbt. The world contains a scene tree of nodes, inherited from the VRML97 format, that defines geometry, appearance, physical properties, lights and robots. Users edit the tree in the graphical interface or directly as text.
Reusable models are packaged as PROTO nodes, parameterized templates for robots, objects and environment pieces. Webots ships a large library of PROTO models, including well-known research and educational robots, common sensors and furniture, so a test world can be assembled in minutes.
| Element | Role | Example |
|---|---|---|
| World file | Defines the complete scene | A warehouse with shelves and robots |
| Scene tree node | Describes one object or property | Solid, Shape, Physics, Light |
| PROTO node | Reusable parameterized model | A wheeled robot with configurable sensors |
| Robot node | Root of a controllable device | Links motors and sensors to a controller |
| Controller | Program that drives a robot | Python obstacle-avoidance loop |
| Supervisor | Privileged controller for the world | Resets scenes, logs ground truth |
Physics, sensors and controllers
Webots computes dynamics with a customized fork of the Open Dynamics Engine, a rigid-body solver with collision detection and joint constraints. Simulation advances in a fixed basic time step, commonly between 1 and 32 milliseconds; smaller steps improve stability of contacts and fast joints at the cost of speed.
Each robot runs one or more controller programs as separate processes. Controllers communicate with the simulator through an API available in C, C++, Python, Java and MATLAB, reading sensors and commanding motors once per control step. Because controllers are ordinary programs, the same logic can later be ported to real hardware with limited changes.
| Device category | Examples | Typical use |
|---|---|---|
| Motion devices | Rotational and linear motors | Wheels, joints, grippers |
| Position sensing | Position sensors, GPS, compass | Odometry and ground-truth pose |
| Inertial sensing | Accelerometer, gyro, inertial unit | Balance and state estimation |
| Range sensing | Distance sensors, LiDAR, radar | Obstacle detection and mapping |
| Vision | Camera, range finder, recognition | Perception and computer vision |
| Contact and force | Touch sensors, force sensors | Grasping and collision detection |
Sensors can be configured with noise, resolution limits and lookup tables that reproduce the nonlinear response of real devices, which matters when a controller must be robust before it meets physical hardware.
Webots compared with other robot simulators
Webots competes with Gazebo, CoppeliaSim, MuJoCo, PyBullet and Isaac Sim. Its distinguishing strengths are ease of installation, a built-in editor and a broad ready-made model library, while specialized simulators lead in contact accuracy, massive parallelism or photorealism.
| Simulator | Main strength | Typical audience |
|---|---|---|
| Webots | Integrated editor and model library | Education, research, prototyping |
| Gazebo | Deep ROS integration, plugins | ROS developers |
| CoppeliaSim | Flexible scripting, several engines | Research and industrial prototyping |
| MuJoCo | Fast, accurate contact dynamics | Control and reinforcement learning |
| PyBullet | Lightweight Python access | Learning research |
| Isaac Sim | GPU physics and photorealistic rendering | Large-scale synthetic data, learning |
For ROS 2 projects, Webots offers an official interface package that exposes devices as ROS topics and lets a URDF description be imported or used directly. Teams already invested in a specific simulator ecosystem usually stay there, but Webots is often chosen when students or small teams need results quickly.
Choosing Webots for a project
Webots fits best when the goal is validating behavior and control logic of robots whose dynamics are dominated by rigid bodies and wheels. It is less suited when results depend on fine contact physics, deformable objects or thousands of parallel environments.
| Project need | Suitability | Reason |
|---|---|---|
| Teaching robotics programming | Strong | Simple setup, many example robots |
| Mobile robot navigation testing | Strong | Good wheel, LiDAR and camera models |
| Robot competitions and swarms | Strong | Supervisor control, repeatable worlds |
| Dexterous manipulation research | Limited | Contact modeling is less precise |
| Massively parallel learning | Limited | Not designed for GPU batch simulation |
Practical setup choices also matter. Running in fast mode without rendering speeds up batch experiments considerably, and a supervisor can log ground-truth poses for evaluating localization. Keeping controllers free of simulator-specific shortcuts, such as reading true positions instead of sensors, makes the later transfer to hardware far smoother.
Limitations and the reality gap
Like every simulator, Webots suffers from the reality gap: behaviors tuned in simulation may fail on hardware because friction, motor response, sensor noise and timing differ from the model. Simulated wheels, for instance, often slip less than real ones on dusty floors.
- Contact-rich tasks such as insertion or in-hand manipulation can show unrealistic jitter or penetration.
- Rendering is functional rather than photorealistic, which limits training vision models on synthetic images.
- Large time steps destabilize fast joints and stiff contacts.
- Model parameters such as mass, inertia and friction are often guessed and must be measured for credible results.
Practitioners narrow the gap by identifying real parameters, adding realistic sensor noise and using domain randomization, then always validating the final controller on the physical robot.
The simple explanation
Webots is like a flight simulator for robots. Instead of building a robot and risking crashes, a developer builds a virtual copy on the computer, places it in a virtual room and writes the program that controls it.
The program sees through simulated cameras and distance sensors and moves simulated wheels and arms. When it works well in the virtual world, the same program can be moved to a real robot, saving time, money and broken parts.
How it is used in practice
A university robotics course gives each student team a simulated differential-drive robot in Webots, placed in a maze with walls, ramps and a moving obstacle. Teams write Python controllers that read eight distance sensors and a camera, with a basic time step of 16 milliseconds, and a supervisor controller scores each run automatically.
Because the world resets in seconds, teams test hundreds of variations in a week without waiting for shared hardware. In the final week they load their controllers onto physical robots of the same model. Most teams need only retuning of speed and sensor thresholds, because real friction and sensor noise differ from the simulation, and the course covers far more material than a hardware-only version could.