Worlds
Controllers
Prototypes
Samples
Devices
Real Robot
HowTo
What is Webots?
Webots is a professional mobile robot simulation software
package. It offers a rapid prototyping environment, that
allows the user to create 3D virtual worlds with physics
properties such as mass, joints, friction coefficients, etc.
The user can add simple passive objects or active objects
called mobile robots. These robots can have different
locomotion schemes (wheeled robots, legged robots, or
flying robots).
Moreover, they may be equipped with a number of sensor
and actuator devices, such as distance sensors, drive
wheels, cameras, servos, touch sensors, emitters, receivers,
etc.
Finally, the user can program each robot individually to
exhibit the desired behavior. Webots contains a large
number of robot models and controller program examples to
help users get started.
sojourner.wbt
Keywords: Sojourner, Passive joint, planetary exploration robot, keyboard,
IndexedFaceSet
This is a realistic model of the "Sojourner" Mars exploration robot (NASA). A large
obstacle is placed in front of the robot so that it is possible to observe how the robot
manages to climb over it. The keyboard can be used to control the robot's motion.
Physics-based model of the Surveyor SRV-1 robot (Surveyor Corp.). The track
system is emulated with a series of 5 wheels for each of the two tracks.
gps.wbt
Keywords: GPS, Supervisor, DifferentialWheels, keyboard
This example shows two different techniques for finding out the current
position of a robot. The first technique consists in using an on-board GPS
device. The second method uses a Supervisor controller that reads and
transmits the position info to the robot. Note that a Supervisor can read (or
change) the position of any object in the simulation at any time. This
example implements both techniques, and you can choose either one or the
other with the keyboard. The 'G' key prints the robot's GPS device position.
The 'S' key prints the position read by the Supervisor.
Kuka YouBot
This model includes an accurate and fast simulation of the Meccanum wheels.
The robot can be equiped with various sensors (including the Microsoft
Kinect) and configured with zero, one or two arms.
Webot Skills
A basic knowledge of the C, C++, Java, Python, Matlab or
URBI programming language is necessary to program
your own robot controllers.
However, even if you don't know these languages, you
can still program the e-puck and Hemisson robots using a
simple graphical programming language called BotStudio.
If you don't want to use existing robot models provided
within Webots and would like to create your own robot
models, or add special objects in the simulated
environments, you will need a basic knowledge of 3D
computer graphics and VRML97 description language.
That will allow you to create 3D models in Webots or
import them from 3D modelling software
What is world?
A world, in Webots, is a 3D description of the
properties of robots and of their environment. It
contains a description of every object: position,
orientation, geometry, appearance (like color or
brightness), physical properties, type of object, etc.
For example, a robot can contain two wheels, a
distance sensor and a servo which itself contains a
camera, etc.
A world file doesn't contain the controller code of the
robots; it only specifies the name of the controller that
is required for each robot.
Worlds are saved in .wbt files. The .wbt files are stored
in the worlds subdirectory of each Webots project.
What is a controller ?
A controller is a computer program that controls a
robot specified in a world file.
Controllers can be written in any of the
programming languages supported by Webots: C,
C++, Java, URBI, Python or MATLABTM.
When a simulation starts, Webots launches the
specified controllers, each as a separate process,
and it associates the controller processes with the
simulated robots.
World Files
Generalities
Webots world files must use the .wbt file name extension. The
first line of a .wbt file uses this header:
#VRML_SIMV6.0utf8
Nodes and Keywords
VRML97 nodes
Webots implements only a subset of the nodes and fields
specified by the VRML97 standard. In the other hand, Webots
also adds many nodes, which are not part of the VRML97
standard, but are specialized to model robotic experiments.
The following VRML97 nodes are supported by Webots:
Appearance, Background, Box, Color, Cone, Coordinate,
Cylinder, DirectionalLight, ElevationGrid, Extrusion, Fog, Group,
ImageTexture, IndexedFaceSet, IndexedLineSet, Material,
PointLight, Shape, Sphere, SpotLight, TextureCoordinate,
TextureTransform, Transform, Viewpoint and WorldInfo.
Here are Webots additional nodes:
Accelerometer, Camera, Charger, Compass, Connector,
DifferentialWheels, DistanceSensor, Emitter, GPS, Gyro,
HyperGate, LED, LightSensor, Pen, Physics, Receiver, Robot,
Servo, Solid, Supervisor and TouchSensor.
World Files
USE and DEF
A node which is named using the DEF keyword
can be referenced later by its name in the same
file with USE statements.
The DEF and USE keywords can be used to reduce
redundancy in .wbt and .proto files.
DEF name are limited in scope to a single
.wbtor .proto file. If multiple nodes are given the
same DEF name, each USE statement refers to
the closest node with the given DEF name
preceding it in the .wbt or .proto file.
Prototype
A prototype defines a new node type in terms of built-in
nodes or other prototypes.
The prototype interface defines the fields for the
prototype.
Once defined, prototypes may be instantiated in the
scene tree exactly like built-in nodes. Here example of
proto definition :
Example of Proto
A complete example of prototype definition and instantiation
is provided here. The prototype is called TwoColorChair; it
defines a simple chair with four legs and a seating part.
For simplicity, this prototype does not have bounding objects
nor Physics nodes. A more complete example of this prototype
named SimpleChair is provided in Webots distribution.
The TwoColorChair prototype allows to specify two colors: one
for the legs and one for the seating surface of the chair.
The interface also defines a translation field and a rotation
field that are associated with the equally named fields of the
prototype's Solid base node. This allows to store the position
and orientation of the prototype instances.
Functions
This manual covers all the functions of the controller API,
necessary to program robots. The C prototypes of these functions
are described under the SYNOPSIS tag. The prototypes for the
other languages are available through hyperlinks or directly in
chapter 10. The language-related particularities mentioned under
the label called C++ Note, Java Note, Python Note, Matlab Note,
etc.
Remote Control
The C, C++, Java or the Python API can be used for programming
a remotely controlled e-puck, Khepera or Aibo robot. This can be
achieved through the robot window in the Webots graphical user
interface.
ODE: Open Dynamics Engine
Webots relies on ODE, the Open Dynamics Engine, for physics
simulation. Hence, some Webots parameters, structures or
concepts refer to ODE. The Webots documentation does not,
however, duplicate or replace the ODE documentation. Hence, it
is recommended to consult the ODE documentation to understand
these parameters, structures or concepts. This ODE
documentation is available online from the ODE web site.
Accelerometer
Appearance
The Appearance node specifies the visual properties of a
geometric node. The value for each of the fields in this node
may be NULL. However, if the field is non-NULL, it shall
contain one node of the appropriate type.
Field Summary
The material field, if specified, shall contain a Material node.
If the material field is NULL or unspecified, lighting is off (all
lights are ignored during rendering of the object that
references this Appearance) and the unlit object color is
(1,1,1).
The texture field, if specified, shall contain an ImageTexture
node. If the texture node is NULL or the texture field is
unspecified, the object that references this Appearance is
not textured.
The textureTransform field, if specified, shall contain a
TextureTransform node. If the textureTransform is NULL or
unspecified, the textureTransform field has no effect.
Box
Camera
Camera Type
The camera type can be setup by the type field described above.
Color
The color camera allows to get color information from the OpenGL context of the
camera. This information can be get by the wb_camera_get_image function, while the
red, green and blue channels (RGB) can be extracted from the resulted image by the
wb_camera_image_get_*-like functions.
Internally when the camera is refresh, an OpenGL context is created, and the RGB
information is copied into a buffer of unsigned char (0-255). It's this buffer which is
accessible by the wb_camera_get_image function.
Range-Finder
The range-finder camera allows to get depth information (in meters) from the OpenGL
context of the camera. This information can be get by the wb_camera_get_range_image
function, while the depth can be extracted from the resulted image by the
wb_camera_range_image_get_depth function.
Internally when the camera is refresh, an OpenGL context is created, and the z-buffer is
copied into a buffer of float. As the z-buffer contains scaled and logarithmic values, an
algorithm linearizes the buffer to metric values between near and maxRange. It's this
buffer which is accessible by the wb_camera_get_range_image function.
Both
This type of camera allows to get both the color data and the range-finder data in the
resulted buffer doing only one OpenGL context. This has been introduced for
optimization reasons, mainly for the Microsoft Kinect device, because creating the
OpenGL context is costly. The color image and the depth data can be get with the
wb_camera_get_image and the wb_camera_get_range_image functions as described
above.
Light Sensor
Light Sensor
Field Summary
lookupTable: this table allows Webots to map simulated
irradiance values to user-defined sensor output values and to
specify a noise level. The first column contains the input
irradiance values in W/m 2. The second column represents the
corresponding sensor output values in user-defined units. The
third column specifies the level of noise in percent of the
corresponding output value
colorFilter: specifies an RGB filter that can be used to
approximate a physical color filter or spectral response. The total
RGB irradiance is multiplied by this filter (see formula below) in
order to obtain a scalar irradiance value E that is then used as
the input to the lookup table. The colorFilter field can, for
example, be used to selectively detect light sources according to
color.
occlusion: specifies whether or not obstacles between the sensor
and light sources should be taken into account in the calculation
of irradiance. If the occlusion field is FALSE (the default), all
potential obstacles (Walls, other Robots, etc.) are ignored and
Webots behaves as if they were transparent. If the occlusion
field is TRUE, Webots will detect which light sources are
occluded (from the sensor's viewpoint) and it will ignore their
direct contributions.
Connector
Damping
A Damping node can be used to slow down a body (a Solid
node with Physics). The speed of each body is reduced by
the specified amount (between 0.0 and 1.0) every second.
A value of 0.0 means "no slowing down" and value of 1.0
means a "complete stop", a value of 0.1 means that the
speed should be decreased by 10 percent every second.
A damped body will possibly come to rest and become
disabled depending on the values specified in WorldInfo.
Damping does not add any force in the simulation, it
directly affects the velocity of the body. The damping
effect is applied after all forces have been applied to the
bodies. Damping can be used to reduce simulation
instability.
A Damping node can be specified in the defaultDamping
field of the WorldInfo node; in this case it defines the
default damping parameters that must be applied to
every body in the simulation.
Physics
The Physics node allows to specify parameters for the physics
simulation engine.
Physics nodes are used in most Webots worlds with the exception
of some purely kinematics-based simulations.
The Physics node specifies the mass, the center of gravity and the
mass distribution, thus allowing the physics engine to create a
body and compute realistic forces.
A Physics node can be placed in a Solid node (or any node derived
from Solid).
The presence or absence of a Physics node in the physics field of
a Solid defines whether the Solid will have a physics or a
kinematic behavior.
In passive objects
If a passive object should never move during a simulation then
you should leave its physics field empty. In this case no contact
force will be simulated on this object and hence it will never
move.
In Robot
Articulated robot, humanoids, vehicles and so on, are built as
hierarchies of Solid nodes (or subclasses of Solid). The contact
and friction forces generated by legs or wheels are usually a
central aspect of the simulation of robot locomotion.
Robot
The Robot node can be used as basis for building a robot, e.g., an
articulated robot, a humanoid robot, a wheeled robot...
If you want to build a two-wheels robot with differential-drive you should
also consider the DifferentialWheels node. If you would like to build a
robot with supervisor capabilities use the Supervisor node instead
(Webots PRO license required).
Field Summary
controller: name of the controller program that the simulator must use to
control the robot. This program is located in a directory whose name is
equal to the field's value. This directory is in turn located in the
controllers subdirectory of the current project directory. For example, if
the field value is "my_controller" then the controller program should be
located in my_project/controllers/my_controller/my_controller[.exe].
The .exe extension is added on the Windows platforms only.
controllerArgs: string containing the arguments (separated by space
characters) to be passed to the main() function of the C/C++ controller
program or the main() method of the Java controller program.
wb_robot_step, wb_robot_init, wb_robot_cleanup - controller step,
initialization and cleanup functions
wb_robot_get_device - get a unique identifier to a device
Robot::getAccelerometer, Robot::getCamera, Robot::getCompass,
Robot::getConnector, Robot::getDistanceSensor, Robot::getDisplay,
Robot::getEmitter, Robot::getGPS, Robot::getGyro, Robot::getLED,
Robot::getLightSensor, Robot::getPen, Robot::getReceiver,
Robot::getServo, Robot::getTouchSensor - get the instance of a robot's
Solid
DifferentialWheels
The DifferentialWheels node can be used as base node to
build robots with two wheels and differential steering. Any
other type of robot (legged, humanoid, vehicle, etc.)
needs to use Robot as base node.
A DifferentialWheels robot will automatically take control
of its wheels if they are placed in the children field. The
wheels must be Solid nodes, and they must be named
"right wheel" and "left wheel". If the wheel objects are
found, Webots will automatically make them rotate at the
speed specified by the
wb_differential_wheels_set_speed() function.
The origin of the robot coordinate system is the projection
on the ground plane of the middle of the wheels' axle.
The x axis is the axis of the wheel axle, y is the vertical
axis and z is the axis pointing towards the rear of the
robot (the front of the robot has negative z coordinates).
Simulation modes
Gyro
The Gyro node is used to model 1, 2 and 3-axis angular velocity
sensors (gyroscope). The angular velocity is measured in radians
per second [rad/s].
Field Summary
lookupTable: This field optionally specifies a lookup table that can
be used for mapping the raw angular velocity values [rad/s] to
device specific output values. With the lookup table it is also
possible to add noise and to define the min and max output
values. By default the lookup table is empty and therefore the raw
values are returned (no mapping).
xAxis, yAxis, zAxis: Each of these boolean fields specifies if the
computation should be enabled or disabled for the specified axis. If
one of these fields is set to FALSE, then the corresponding vector
element will not be computed and it will return 0.0. For example if
zAxis is FALSE, then wb_gyro_get_values()[2] returns 0.0. The
default is that all three axes are enabled (TRUE).
The wb_gyro_enable() function turns on the angular velocity
measurement each ms milliseconds.
The wb_gyro_disable() function turns off the Gyro device.