Webots User Guide

previous page go up next page

Foreword

Thanks

1.Installing Webots

2.Upgrading from Webots 2

3.Getting Started with Webots

4.Tutorial: Modelling and simulating your robot

5.Robot and Supervisor Controllers

6.Tutorial: Using the KheperaTM robot

7.ALife Contest

     

3.3 Scene Tree Window

As seen in the previous section, to access to the Scene Tree Window you can either choose Scene Tree Window in the Edit menu, or click on the pointer button and double-click on a solid object.

The scene tree contains all information necessary to describe the graphic representation and simulation of the 3D world. A world in Webots includes one or more robots and their environment.

The scene tree of Webots is structured like a VRML file. It is composed of a list of nodes, each containing fields. Fields can contain values (text string, numerical values) or nodes.

Some nodes in Webots are VRML nodes, partially or totally implemented, while others are specific to Webots. For instance the Solid node inherits from the Transform node of VRML and can be selected and moved with the buttons in the World Window.

This section describes the buttons of the Scene Tree Window, the VRML nodes, the Webots specific nodes and how to write a .wbt file in a text editor.

(null)

3.3.1 Buttons of the Scene Tree Window

The scene tree with the list of nodes appears on the left side of the window. Clicking on the + in front of a node or double-clicking on the node displays the fields inside the node, and similarly expands the fields. The field values can be defined on the top right side of the window. Five editing buttons are available on the bottom right side of the window:

Cut

Copy

Paste after

These three buttons let you cut, copy and paste nodes and fields. However, you can't perform these operations on the three first nodes of the tree (WorldInfo, Viewpoint and Background). These nodes are mandatory and don't need to be duplicated. Similarly, you can't copy the Supervisor node because only one supervisor is allowed. Please note that when you cut or copy a robot node, like a DifferentialWheels or Supervisor node, the controller field of this node is reset to "void".

Delete: This button allows you to delete a node. It appears only if a node is selected. If a field is selected, the Default Value button appears instead.

Default Value: You can click on this button to reset the default value(s) of a field. A field with values must be selected in order to perform this button. If a node is selected, the Delete button replaces it.

Transform: This button allows you to transform a node into another one.

Insert after: With this button, you can insert a node after the one currently selected. This new node contains fields with default values, which you can of course modify to suit your needs. This button also allows you to add a node to a children field. In all cases, the software only permits you to insert a coherent node.

Insert Node: Use this to insert a node into a field whose value is a node. You can insert only a coherent node.

Export Node: Use this button to export a node into a file. Usually, nodes are saved in your objects directory. Such saved nodes can then be reused in other worlds.

Import Node: Use this button to import a previously saved node into the scene tree. Usually, saved nodes are located in the Webots objects directory or in your own objects directory. The Webots objects directory already contains a few nodes that can be easily imported.

3.3.2 VRML nodes

A number of VRML 2.0 nodes are partially or completely supported in Webots.

The exact features of VRML 2.0 are the subject of a standard managed by the International Standards Organization (ISO/IEC 14772-1:1997).

You can find the complete specifications on the official VRML Web site: \texttt{http://www.vrml.org}.

The VRML nodes supported in Webots are the following:

  • Appearance

  • Background

  • Box

  • Color

  • Cone

  • Coordinate

  • Cylinder

  • DirectionalLight

  • ElevationGrid

  • Fog

  • Group

  • ImageTexture

  • IndexedFaceSet

  • IndexedLineSet

  • Material

  • PointLight

  • Shape

  • Sphere

  • Switch

  • TextureCoordinate

  • TextureTransform

  • Transform

  • Viewpoint

  • WorldInfo

The Reference Manual gives a more comprehensive list of nodes with associated fields.

3.3.3 Webots specific nodes

In order to implement powerful simulations including mobile robots with two-wheel differential steerings, a number of nodes specific to Webots have been added to the VRML set of nodes.

VRML uses a hierarchical structure for nodes. For example, the Transform node inherits from the Group node, such that, like the Group node, the Transform node has a children field, but it also adds three additional fields: translation, rotation and scale.

In the same way, Webots introduces new nodes which inherit from the VRML Transform node, principally the Solid node. Other Webots nodes (DifferentialWheels, DistanceSensor, Camera, etc.) inherit from this Solid node.

The different fields of the Webots nodes are explained below.

The Reference Manual gives a complete list of Webots nodes and their associated fields along with a brief description of each field.

The Solid node

A solid is a group of shapes that you can drag and drop in the world, using the mouse. Moreover, the sensors of the robots and the collision detector of the simulator are able to detect solids. The Solid node represents this group of shapes in the scene tree.

Principle of the collision detection of the simulator:

The collision detection engine is able to detect a collision between two Solid nodes. It calculates the intersection between the bounding objects of the solids. A bounding object (described in the boundingObject field of the Solid node) is a geometric shape or a group of geometric shapes which bounds the solid. If the boundingObject field is NULL, then no collision detection is performed for this Solid node. list of children of the Solid node are used to compute the bounding object.

The collision detection is mainly of use between a robot DifferentialWheels node) and an obstacle (Solid node), and between two robots. Two Solid nodes can never interpenetrate each other; their movement is stopped just before the collision.

A description of the fields of the Solid node is given below.

The Solid node inherits from the VRML Transform node. The additional fields are:

  • name: individual name of the solid (e.g.: ""my blue chair").

  • model: generic name of the solid (e.g.: "chair").

  • author: name of the author of the simulation model of the solid.

  • constructor: name of the company or individual who made the real solid.

  • description: short description (1 line) of the solid.

  • boundingObject: shape or a group of shapes which bound the solid for collision detection. If the value of this field is NULL, the collision detection is computed from the children list of the Solid node. In any other case, the Shape node is not used, because a bounding box is not a filled object. The Shape node is replaced directly by a Box or a Cylinder node for example. See the example below.

  • physics: this field is used when it is necessary to model a minimum of physics for a Solid object. In this case, it contains a Physics object which defines a number of physical properties for the solid. This is especially useful when implementing a robot pushing an object like a ball. In this case, both the robot and the ball should have a Physics node in their physics field. If not used, this field is left to NULL.

  • joint: unused at the moment (reserved for future use).

  • locked: if TRUE, the solid object cannot be moved using the mouse. This is useful to prevent moving an object by error.

Example: a solid with a bounding box different from its list of children.

Let us consider the Khepera robot model. It is not exactly a Solid node, but the principle for the boundingObject is the same. Open the khepera.wbt file and look at the boundingObject field of the DifferentialWheels node. The bounding object is a cylinder which has been transformed. See figure 3.4.

bounding1

Figure 3.4: The bounding box of the Khepera robot

The DifferentialWheels node

The DifferentialWheels node inherits from the Solid node. It is used to represent any robot with two-wheel differential steering. The two specific fields which are essential for the simulation are axleLength and wheelRadius. The value of axleLength is the distance (in meters) between the two wheels of the robot, and the value of wheelRadius is the radius (in meters) of the wheels.

Moreover, the origin of the robot coordinate system is the projection on the ground plane of the center of the axle of the wheels. x 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).

The DifferentialWheels node inherits from the Solid node. The additional fields are:

  • controller: name of the program controlling the robot. This program lies in the directory with the same name in the controllers directory; for example, the void (or void.exe) controller is found in the webots/controllers/void/ directory . The simulator will use this program to control the robot.

  • synchronozation: if the value is TRUE (default value), the simulator is synchronized with the controller; if the value is FALSE, the simulator runs as fast as possible, without synchronization.

  • battery: this field should contain three values: the first one corresponds to the current energy of the robot in Joules(J), the second one is the maximum energy the robot can hold in Joules, the third one is the speed of energy recharge in Watts ([W]=[J]/[s]). The simulator updates the first value, while the two others remain constant.

  • cpuConsumption: consumption of the CPU (central processing unit) of the robot in Watts.

  • motorConsumption: consumption of the the motor in Watts.

  • axleLength: distance between the two wheels in meters.

  • wheelRadius: radius of the wheels in meters. Both wheels must have the same radius.

  • maxSpeed: maximum speed of the wheels, expressed in rad/s.

  • maxAcceleration: maximum acceleration of the wheels, expressed in rad/s^2.

  • speedUnit: defines the unit used in the differential_wheels_set_speed function, expressed in rad/s.

  • slipNoise: slip noise added to each move expressed in percent. If the value is 0.1, a noise of +/- 10 percent is added to the command for each simulation step.

  • encoderNoise: noise added to the incremental encoder. If the value is -1, the encoders are not simulated. If the value is 0, encoders are simulated without noise. Otherwise a noise is added to encoder values. When the robot faces an obstacle, the robot wheels do not slip, hence the encoder values are not incremented. This is very useful to detect that a robot has hit an obstacle.

  • encoderResolution: defines the number of encoder incrementations per radian of the wheel. An encoderResolution of 100 will make the encoders increment their value of about 628 each times the wheel makes a complete revolution.

The DistanceSensor node

The DistanceSensor node is used to model sonar sensors, infra-red sensors and laser range finders. It uses a ray casting algorithm to detect collision between the sensor ray and Solid nodes in the world. The DistanceSensor node inherits from the Solid node. it includes two additional specific fields:

  • type: type of sensor: currently only the "infra-red" type is supported, but upcoming versions of Webots may include "sonar" or "laser" types. Infra red sensors have a special property: the are color sensitive and will see better light or red obstacles than dark or black ones.

  • lookupTable: This field is best explained through an example: Let us consider an infra-red sensor. The white noise on the return value is 10 percent. For an obstacle made of a given material and color and for a given ambient light, the response of the sensor is as shown in figure 3.5

    infrared

    Figure 3.5: Measurements of the light reflected by an obstacle

    The values of the lookupTable will be:

    lookupTable [ 0     1000  0,
                  0.1   1000  0.1,
                  0.2    400  0.1,
                  0.3     50  0.1,
                  0.37    30  0   ]

    This means that for a distance of 0 meter, the sensor will return a value of 1000 without noise (0), for a distance of 0.1 meter, the sensor will return 1000 with a noise of 10 percent, for a distance value of 0.2 meters, the sensor will return 400 plus or minus 10 percent of noise, etc. For distance values not specified in the lookup table, the simulator will perform a linear interpolation to compute the value returned by the sensor and its associated noise. The first distance value of a lookup table must always be 0.

Note: the ray of a sensor can be displayed in the world view by selecting Display sensor rays in the File/Preferences menu under the Rendering panel.

In the case of an "infra-red" sensor, the value returned by the lookup table is modified by a reflection factor depending on the color properties of the object hit by the sensor ray. This reflection factor is computed as follow: f = 0.2 + 0.8 * red_level where red_level is the level of red color of the object hit by the sensor ray. This factor is then multiplicated to the return value computed from the lookup table.

Please note that a primtive support for DistanceSensor nodes used for reading the red color level of a textured ground was implemented. This is useful to simulate line following behaviors. This feature is demonstrated in the ground_color.wbt example. In short, the ground texture should lie in a rectangular IndexedFaceSet node centered at (0,0,0).

The LightSensor node

The LightSensor node is used to model a phototransistor-like sensor which measure the level of ambiant light in a given direction. The light level measured by the LightSensor node is computed from each PointLight node in the scene, taking into account the distance between the sensor and the light, the orientation of the sensor relatively to the light, the intensity of the light (computed from its ambient intensity, intensity and color). The LightSensor node inherits from the Solid node. it includes an additional specific field:

  • lookupTable: similar to the one of the DistanceSensor node except that the distance values (first column) are replaced by intensity values. This intensity value results from the sum of intensity values computed for each PointLight as follow:

    distance is the distance between the LightSensor and the PointLight.

    dot is the dot product between the normalized sensor direction and the normalized vector defined by the LightSensor location and the PointLight location.

    att = attenuation.x + attenuation.y * distance + attenuation.z * distance * distance

    cf = color.red * color.green * color.blue

    intensity_value = (ambiantIntensity + intensity) * cf * dot / att

The Camera node

The Camera node is used to model a robot's on-board camera. The Camera node inherits from the Solid node. The fields specific to the Camera node are:

  • fieldOfView: horizontal field of view angle of the camera. The value ranges from 0 to pi radians. Since camera pixels are squares, the vertical field of view can be computed from the width, height and horizontal fieldOfView:

    vertical FOV = fieldOfView * height / width

  • width: width of the image in pixels.

  • height: height of the image in pixels.

  • type: type of the camera: "color" or "black and white".

The Charger node

The Charger node is used to model a special kind of battery charger for the robots. A robot has to get close to a charger in order to recharge itself. A charger is not like a standard battery charger you plug to the power supply. Instead, it is a battery itself: it accumulates energy with time. It could be compared to a solar power plan loading a battery. When the robot comes to get energy, it can't get more than the charger has currently accumulated.

The Charger node inherits from the Solid node. The fields specific to the Charger node are:

  • battery: this field should contain three values: the current energy of the charger (J), its maximum energy (J) and its charging speed (W=J/s).

  • radius: radius of the charging area in meters. The charging area is a disk centered on the origin of the charger coordinate system. The robot can recharge itself if its origin is in the charging area. See figure 3.6.

    charger

    Figure 3.6: The sensitive area of a charger

The Emitter node

The Emitter node is used to model an infra-red or radio emitter on-board a robot. You must insert the Emitter node into the list of children of the robot. Please note that an emitter can only emit data but it cannot receive any information. In order to enable a bi-directional communication system, a robot needs both an Emitter and a Receiver node.

The Emitter node inherits from the Solid node. The fields specific to the Emitter node are:

  • type: type of the emitted signals: "infra-red" or "radio".

  • range: radius of the emission area in meters. The origin of the coordinate system of a receiver must be in this area to allow this receiver to pick up the signal.

  • channel: channel of emission. The value is an identification number for an infra-red emitter or a frequency for a radio emitter. The receiver must use the same channel to receive the emitted signals. It can be any positive integer value.

  • baudRate: the baudRate value is the communication speed expressed in number of bits per second.

  • byteSize: the byteSize value is the number of bits used to represent one byte (usually 8, but may be more depending on whether control bits are used).

  • bufferSize: the buffer is a memory area, its size is specified in bytes. The size of the data to be emitted cannot exceed the buffer size, otherwise data is lost. When the emitter emits the data, it flushes the buffer.

The Receiver node

The Receiver node is used to model an infra-red or radio receiver. A receiver, just like an emitter, is usually on-board a robot. Please note that a receiver can only receive data but it cannot emit any information. In order to enable a bi-directional communication system, a robot needs both an Emitter and a Receiver node.

The fields and values of the Receiver node are nearly the same as those of the Emitter node. As the Emitter node, the Receiver node inherits from the Solid node. The fields specific to the Receiver node are:

  • type: type of the received signals: "infra-red" or "radio".

  • channel: channel of reception. The value is an identification number for an infra-red receiver or a frequency for a radio receiver. The emitter must use the same channel to detect the emitted signals.

  • baudRate: the baudRate value is the communication speed expressed in bits per second. It must be the same as the speed of the emitter.

  • byteSize: the byteSize value is the number of bits used to represent one byte (usually 8, but may be more if control bits are used). It must be the same size as the emitter buffer.

  • bufferSize: the buffer is a memory area, its size is specified in bytes. The size of the received data can't exceed the buffer size, otherwise data is lost. When the receiver reads the data, it flushes the buffer. If the old data has not been read when the new data is received, the former is lost.

The HyperGate node

A hypergate is defined as a cylindrical area in the world. When a robot (more precisely the origin of the robot coordinate system) enters it, it disappears and gets transferred to another world specified in the HyperGate node.

The HyperGate node inherits from the Solid node. The fields specific to the HyperGate node are:

  • url: destination URL of the form "wtp://host.domain.com/file#name".

  • radius: radius of the transfer cylinder.

  • height: height of the transfer cylinder.

  • maxFileSize: maximum file size for the Robot node accepted by the hypergate.

    For example, an hypergate can look like an arch with the transfer cylinder lying inside the arch. See figure 3.7.

    hypergate

    Figure 3.7: An example of an Hypergate

The Physics node

This node is used to specify a number of physical properties associated to a Solid node, like its mass, friction coefficient, energy absobtion, etc.

It was implemented to enable the modelling robot soccer systems, where a robot, or several robots can push a ball which can roll and bounce against the walls. An example of using the Physics node is provided in the alice_soccer.wbt world. The list of available fields is mentioned in the reference manual and in the resources/nodes/Physics.wrl file with the physical unit for each field.

The Supervisor node

A supervisor is a program which controls a world and its robots. For convenience it is represented as a robot without any wheels, driven by a controller with extended capabilities which supervises the whole world. A world cannot have more than one supervisor.

The Supervisor node inherits from the Solid node. Its other fields include some of the DifferentialWheels node fields:

  • controller

  • synchronisation

  • battery: usually meaningless for a Supervisor node.

  • cpuConsumption: usually meaningless for a Supervisor node.

The TouchSensor node

The TouchSensor node is used to model bumper sensors. A bumper sensor will detect the collision with any Solid object in the world, including other DifferentialWheels nodes. Collision detection is based upon the boundingObject field of the TouchSensor node and the boundingObject field of other Solid nodes. The TouchSensor node inherits from the Solid node. It includes two additional specific fields:

  • lookupTable: similar to the one of the DistanceSensor node.

  • type: type of sensor: "bumper".

Note: only the "bumper" type is currently supported, but other types, including "button", "force" or "whisker" are likely to be implemented in a forthcoming version of Webots.

3.3.4 Writing a Webots file in a text editor

It is possible to write a Webots world file (.wbt) using a text editor. A world file contains a header, nodes containing fields and values. Note that only a few VRML nodes are implemented, and that there are nodes specific to Webots. Moreover, comments can only be written in the DEF, and not like in a VRML file.

The Webots header is:

#VRML_SIM V3.0 utf8

After this header, you can directly write your nodes. The three nodes WorldInfo, Viewpoint and Background are mandatory.

Note: we recommend that you write your file using the tree editor. However it may be easier to make some particular modifications using a text editor (like using the search and replace feature of a text editor).

previous page go up next page
^ page top ^

  E-mail to webmaster Last updated: Copyright © 2002 Cyberbotics Ltd.