webots
Rust bindings and safe wrappers for the Webots controller API.
webots provides checked-in Rust bindings for the Webots controller API plus a thin, safe wrapper
layer for common controller operations and device access.
Build model
This crate is designed so companion crates can compile on machines that do not have Webots installed.
- Default builds use checked-in, versioned bindings such as
src/v2025a/bindings.rs. - Default builds also select a versioned wrapper header such as
headers/2025a/wrapper.h. - Default builds do not link
libController. - Real controller linking is opt-in through the
runtime_linkfeature. - Running a controller still requires a valid Webots installation.
This makes the default mode suitable for CI/CD jobs where the goal is to compile Rust code, not to execute it inside Webots.
Highlights
- Checked-in generated bindings for reproducible builds.
- Safe wrapper entrypoints for robot lifecycle and common devices.
- Versioned API namespaces so multiple Webots releases can coexist over time.
- Optional runtime linking for real controller binaries.
Usage
Library-only or CI compilation:
[]
= "0.1"
Version-explicit API:
let simulator = new?;
let webots = new?;
Executable controller that should link against a real Webots installation:
[]
= { = "0.1", = ["runtime_link"] }
Runtime linking looks for Webots in the standard host install location and also honors
WEBOTS_HOME if Webots already set it.
Quick start
use Webots;
Example
use Webots;
Supported bindings versions
One version feature must be selected at a time.
v2025a(default)
The selected version is exposed in Rust as webots::WEBOTS_API_VERSION.
The current versioned namespace is webots::v2025a.
Each supported Webots release owns its own Rust module tree under src/vXXXX/.
Release and CI
The repository ships with GitHub Actions for:
- CI on pushes and pull requests:
fmt,check,clippy,doc, andcargo package. release-plz-driven releases: pushes tomain/masterupdate or create a release PR, and merging that PR publishes the crate to crates.io and creates a GitHub release.
The release workflow expects a CARGO_REGISTRY_TOKEN repository secret and uses the default
GITHUB_TOKEN for release PRs and GitHub releases.
Maintainer workflow
This repository uses a small internal workspace member to scaffold and regenerate versioned API trees. End users do not build this helper crate.
Scaffold a new Webots version from an existing Rust API tree:
That copies src/v2025a/ to src/v2025b/, rewrites internal module paths, copies
headers/2025a/wrapper.h to headers/2025b/wrapper.h, and adds the v2025b feature/export
boilerplate.
Generate a bindings file:
That command reads headers/2025a/wrapper.h and writes src/v2025a/bindings.rs.
If Webots is installed somewhere non-standard, pass it explicitly:
The generator also honors WEBOTS_HOME if it is already present in the environment.
Adding a new Webots version
No build.rs changes are needed for a new version.
- Run
cargo bindings-generator scaffold v2025b v2025a. - Edit
headers/2025b/wrapper.hfor the new Webots header surface. - Run
cargo bindings-generator v2025b. - Review
src/v2025b/and make any API changes required by that Webots release.
Runtime linking
To link the real Webots controller library during build:
If runtime linking is requested and Webots is missing from the standard install location, the build fails fast.