Webots Robot Simulator

The Webots Python API is contained in the controller module. It is designed to mirror the C++ API, meaning class hierarchies, names, and function names are nearly identical.

• Supported Versions: Python 3.8 or higher.
• API Composition: Approximately 25 classes and 200 public functions.
• Class Types:
  • Node representations: Classes representing scene tree nodes (e.g., Robot, LED).
  • Utility classes: Classes for specialized tasks (e.g., Motion, ImageRef).

The Open Dynamics Engine (ODE) is a free, industrial-quality library used for simulating articulated rigid body dynamics. It is suitable for simulating ground vehicles, legged creatures, and moving objects in VR environments. Key features include:

• Fast, flexible, and robust simulation.
• Platform independence.
• Advanced joints.
• Contact with friction.
• Built-in collision detection.

The Java API is a wrapper around the C++ API generated via SWIG. It is contained in the package com.cyberbotics.webots.controller and consists of approximately 25 classes and 200 public functions.

Key Components

• Node Representations: Classes representing scene tree nodes (e.g., Robot, LED).
• Utility Classes: Classes for specialized tasks (e.g., Motion, ImageRef).

API Files

• Controller.jar: The main package for users wanting to use third-party IDEs. It is located in the lib directory of the Webots installation.
• Generated Source: SWIG-generated files can be found in src/controller/java/SWIG_generated_files.
• API Customization: Advanced users can modify the API by editing the SWIG script (src/controller/java/controller.i) and the Makefile (src/controller/java/Makefile).

OPCODE (OPtimized COllision DEtection) is a C++ collision detection package designed for high performance and low memory footprint. It is suitable for applications requiring mesh-mesh collision detection, N-body collisions, camera-vs-world collisions, shadow feelers, and rigid body simulation.

Key features include:

• Support for arbitrary meshes (convex, non-convex, or polygon soups).
• Implementation using AABB-trees, including hybrid trees and quantized trees (decompressed on-the-fly).
• Support for 'first contact' or 'all contacts' modes.
• Temporal coherence for 'first contact' mode, providing significant speedups in rigid body simulations.
• Various query types: Stabbing, planes, and volume queries (Sphere, AABB, OBB, LSS).
• Sweep-and-prune support.
• Support for deformable meshes.

The C Controller API module provides the necessary functions for developing robot controllers in C. It includes APIs for:

• Controlling robot hardware and actuators.
• Handling user interaction.
• Managing networking capabilities.
• Interacting with the Webots scene management system.

Webots typically follows a release cycle with two major versions per year:

• Version a: Released early in the year.
• Version b: Released around the middle of the year.
• Patch releases: Released between major versions as needed (e.g., R2020a-revision1).

Nightly Builds:

• Nightly builds are generated from the develop branch (which corresponds to the upcoming 'version b').
• Nightly build files are only kept for the last 3 days. For long-term stability, use official stable versions.

The Webots Graphical User Interface (GUI) consists of four primary windows:

1. 3D window: Displays and allows interaction with the 3D simulation.
2. Scene tree: A hierarchical representation of the current world.
3. Text editor: Used for editing source code (controllers, plugins, etc.).
4. Console: Displays compilation logs and controller outputs.

The GUI includes eight menus: File, Edit, View, Simulation, Build, Overlays, Tools, and Help.

Webots maintains a strict distinction between the wb_robot_* and wb_supervisor_* APIs.

• wb_robot_*: Used for standard robot functionalities available on real hardware.
• wb_supervisor_*: Corresponds to human intervention or experimental setup functionalities that are typically not available on real robots.

This distinction is intentional to remind users that Supervisor API functions may not be easily transposable to real-world robotic hardware.

The Webots streaming architecture uses a multi-tier communication model:

1. Session Server: Monitors simulation server availability and load. It answers '1' (available) or '0' (unavailable) via WebSocket. It acts as a load balancer, assigning clients to the server with the lowest compute load.
2. Simulation Server: Receives AJAX requests from web clients. It clones the requested project from a GitHub repository, starts Webots, and provides the client with the Webots WebSocket URL.
3. Webots: The actual simulator. The client communicates directly with Webots via WebSocket once the simulation is started.

Lifecycle Management:

• If the WebSocket connection to the simulation server is closed/broken, the simulation server closes Webots.
• If Webots quits, the simulation server notifies the web client and closes the connection.

Webots follows a client-server architecture for communication between the simulator and the controller:

• libController: A shared library (.dll on Windows, .so on Linux) that is linked with your controller program. It allows the controller (a standalone executable) to communicate with the Webots simulator.
• src/Controller/api: Contains the Webots API (the functions you call from your controller program).
• src/webots/nodes: Part of the Webots binary that implements nodes and communicates with libController via a communication pipe.

When implementing new functionality, it is recommended to start by implementing the API function in libController first, then implementing the underlying logic in the Webots nodes.

Wren exposes its public interface through C headers located in the include/wren directory.

To use Wren, ensure the following four dependencies are available:

1. STL
2. glm
3. glade
4. siphash

Note: The dependency on Qt has been removed.