This chapter documents the use of Urbi in the Webots simulation environment.
This section describes how to setup the software on your computer and give you the basis to use Urbi for Webots.
The setup process depends on your OS, please follow the corresponding instructions.
To install Urbi for Webots in your Webots on Linux, you must download an archive of the form ‘urbi-for-webots-version-linux-x86-gcc4-release.tar.bz2’. You may choose an other archive format than .tar.bz2, but you will need to slightly adjust the following instruction accordingly.
The archive is structured to blend into the Webots hierarchy, as follow:
All you need to do is extract it into your Webots directory, minus the urbi-for-webots-version containing directory, so as to merge the packaged project directory with your Webots’ project directory.
This can be easily done with the following tar command:
Otherwise, you can also merge the directory after extracting the archive:
You can check your installation works correctly by starting a test world:
You should see an Aibo looking at a moving ball.
Urbi for Webots is not available under Mac OS X anymore for now. We hope to fix this very shortly.
Urbi for Webots is not available under windows anymore for now. We hope to fix this very shortly.
If you don’t provide a valid license file to the Urbi controller, it will be launched in evaluation mode. The only difference with the normal version is that the controller will exit after five minutes, thus letting you test all the features of the registered version during this amount of time. In evaluation mode, the Urbi controller will display the following message in the Webots console:
In order to run Urbi for Webots without constraints you must provide it with a license file, as described in the following section.
Providing a valid Urbi for Webots license will enable you to run Urbi controllers for an unlimited amount of time. The license is a file named ‘urbi.key’. You simply need copy it in the ‘webots/resources/’ directory of your Webots installation.
The Urbi for Webots licensing system is based on the Webots licensing system: your Urbi for Webots key is attached to your Webots key. The procedure will depend on whether your Webots license is based on a ‘webots.key’ file or an USB dongle.
If you have any problem setting up your Urbi for Webots license, feel free to contact us at contact@gostai.com.
Urbi licensing with a ‘webots.key’ Webots license: If you use a file-based Webots license, please send us your ‘webots.key’ on contact@gostai.com so as we can generate your ‘urbi.key’. In this case, you need to put your ‘webots.key’ together with your ‘urbi.key’ in the ‘webots/resources/’ directory.
Urbi licensing with an USB dongle Webots license: If you use an USB dongle based license, please send us your dongle number available in the help/about Webots menu to contact@gostai.com so as we can generate your ‘urbi.key’.
This section will show you how to control your own simulation with Urbi controllers.
A robot controlled by Urbi in Webots uses a controller which is actually a standard Urbi server, with custom UObjects plugged in. This mean you can connect to the Urbi server and interact with the robot just like you would with the actual Urbi server of the robot. Note however that since the Urbi server is started by webots, we have no way to interact with it on the standard input, and need to connect to it via the network. Please refer to Listing 2 to learn how to interact with an Urbi server via the network.
You can try it out with one of the bundled demonstration worlds. For instance, run in Webots the ‘aibo-ball-tracking.wbt’ world located in the ‘projects/packages/urbi2.0/worlds/’. You can then connect on the 54000 port and control the Aibolike a regular one.
To use an urbi controller in your Webots world, first define an urbi-2.0 controller for your webots node:
This will start an Urbi server to interact with your robot. This server is however useless since it doesn’t run any specific behavior and you cannot interact with it. You can ask the Urbi server to listen for incoming connection, so as you can connect to it and control the robot interactively. You can also load urbiscript files in the server to run them at start-up. You can of course do both.
To do this, simply pass arguments to the controller with the controllerArgs Webots attribute. Available arguments are the exact same as the urbi program, as described in Section 21.3.
Listening for incoming connections: pass a --port option to the controller.
Loading an urbiscript file: pass a --file option to the controller. In addition to standard directories, scripts are also searched in the ‘projects/packages/urbi-2.0/share/’ directory of your webots installation. For instance, you could create a ‘my_behavior/my_script.u’ script in this directory, and use the following controllerArgs.
A different approach would be to define your own Urbi-based controller. If you create a controller in Webots’ controllers directory and create a ‘global.u’ file in it, Webots will automatically recognize it as an Urbi controller and start the ‘urbi-2.0’ controller. The ‘global.u’ and potential ‘local.u’ will be automatically loaded by the Urbi kernel, as documented in Section 21.2.
This approach is equivalent to using the default ‘urbi-2.0’ controller and passing it file to load, but enables you to define custom, reusable controllers for your robots. For instance, you could create a ‘my-project/controllers/my-robot/’ controller, with a ‘global.u’ file in it that load all your robots objects (motors, sensors, …). To use an Urbi controller for your robot, you would then simply have to use controller "my-robot" in your world file. If you used the default ‘urbi-2.0’ controller, you would have to add
controllerArgs "--file some-dir/my-robot-bindings.u"
to get a functional controller for your robot.
Binding your own robot model with Urbi for Webots is extremely similar to binding an actual robot with Urbi, except the UObjects (device drivers) are already written for Webots generic devices. It thus mainly consists in writing an initialization urbiscript file that instantiate those Urbi objects for your robots devices (motors, sensors, …). For instance, a binding for a minimalist robot that only has a servomotor and a distance sensor could be:
var motor = Servo.new("webots_motor_node_name");
var distance = DistanceSensor.new("webots_sensor_node_name");
Note that, whenever possible, your Webots binding should be strictly identical to the actual robot binding (if any) so as the same Urbi code will work in the simulator and in reality. Additionally, you should whenever possible respect the Gostai Standard Robotics API (see Section 25) to be compatible with standard Urbi components.
Urbi for Webots comes with several built-in demonstration robots and worlds. Every included robot has a binding file named ‘projects/packages/urbi-2.0/share/robot-name/robot-name.u’ and a custom controller located in ‘projects/packages/urbi-2.0/controllers’ whose ‘global.u’ start-up file loads the binding. Thus, using controller "robot-name" in the webots world file automatically starts an Urbi kernel with the right binding to control the robot.
Here is a description of the built-in worlds:
These uobjects are the Urbi API for Webots robots devices such as motors or sensors. They all implement at least an interface from the Gostai Standard Robotics API (see Section 25). Please refer to these interfaces to discover most functionalities of the object. Only additional slots are documented here.
All objects are constructed with a node_name argument, which is the name of the corresponding node in the Webots world.
While Webots accelerators all have three components, Urbi prefer to differentiate every component in one linear accelerometer.
Gostai Standard Robotic API interface: AccelerationSensor (Section 25.5.11)
Constructor: Accelerometer.new(node_name, component_name)
Note: Since there is only one device for the three components in Webots, disabling one of the component (by setting the load slot to false will disable all three components.
Gostai Standard Robotic API interface: VideoIn (Section 25.5.17)
Constructor: Camera.new(node_name)
Note: The Webots camera won’t appear in the webots interface until the corresponding UObject has been instantiated. You can create only one camera Urbi Object by Webots camera device.
Differential wheels in Webots represent a pair of wheels. They are represented as separated motors in Urbi.
Gostai Standard Robotic API interface: RotationalMotor (Section 25.5.6)
Constructor: DifferentialWheels.new(node_name, left)
Note: The differential wheels won’t work correctly unless you instantiate both left and right objects.
Gostai Standard Robotic API interface: DistanceSensor (Section 25.5.9)
Constructor: DistanceSensor.new(node_name)
Gostai Standard Robotic API interface: Led (Section 25.5.23)
Constructor: Led.new(node_name)
Gostai Standard Robotic API interface: RotationalMotor (Section 25.5.6)
Constructor: Servo.new(node_name, force_feedback)
Gostai Standard Robotic API interface: TouchSensor (Section 25.5.10)
Constructor: TouchSensor.new(node_name)
The supervisor UObjects are only available from a supervisor robot (i.e. from the controller of a supervisor node in Webots). They enable to control the simulation in an omnipotent manner.
Constructor: Label.new(text)
Constructor: ManipulateNode.new(node_name)
Constructor: SimulationController.new()