Webots User Guide release 6.2.4

	Foreword
	Thanks
1.	Installing Webots
2.	Getting Started with Webots
3.	Sample Webots Applications
4.	Language Setup
5.	Development Environments
6.	Programming Fundamentals
7.	Tutorial: Modeling and simulating your robot
8.	Using the e-puck robot
9.	Webots FAQ
10.	Known Bugs

5.8 Using Webots Remotely (Linux)

In the Unix environments it is very common to start an application on a remote computer, over the network, for example using the ssh command. With ssh it is also possible to redirect the application's GUI and graphics output (and input) across the network. This useful Unix feature can be used to start Webots jobs remotely on a computer cluster, as explained below.

5.8.1 Using X11 Forwarding

Here is the usual way to start webots on a remote computer using ssh:

$ ssh -X myname@remote.computer.org $ webots myworld.wbt &

The -X option (high case) tells ssh to enable X11 forwarding. With X11 forwarding the Webots GUI, just like any other X11 application, will be displayed on the host that called ssh. If the network connection is interrupted the simulation is put on wait but it resumes smoothly when the network connection is re-established.

It is also possible to start Webots minimized by adding the --minimize flag to the command line. Then it is possible to maximize the Webots icon at any time to verify that the remote simulation is doing what is expected:

$ ssh -X myname@remote.computer.org $ webots --minimize myworld.wbt &

The --minimize flag is sometimes used to call Webots from scripts to do batch jobs: this avoids cluttering the screen with several Webots windows.

Note that Webots PRO does automatically enable the Fast mode when its window is minimized (iconized). So with Webots PRO the simulation is faster when the window is minimized, because the 3D graphics is left out and almost no network bandwidth is used for X11.

5.8.2 Hanging Up Safely

The problem with the above approach is that terminating the ssh session also kills the remote jobs. So in this case it will kill the remote Webots job and this is often unwanted.

Fortunately it is possible to overcome this problem by using the nohup command and by connecting Webots to the X11 server of the remote host. In this approach ssh must be called without the -X (X11 forwarding) option and Webots must be called from the nohup command. The nohup causes the Webots to ignore the HUP (hangup) signal, and keeps it running after the user has logged out. Here is the procedure:

$ ssh myname@remote.computer.org $ export DISPLAY=:0.0 $ nohup webots --minimize myworld.wbt & nohup: ignoring input and appending output to `nohup.out' $ exit

Now the user can safely exit the ssh session, while Webots keeps running.

With nohup, output that would normally go to the terminal goes to a file called nohup.out. At this point it may become useful to redirect Webots console output to the nohup.out file (or to another file), in order to examine it later on. This can be achieved by defining the WEBOTS_STDOUT and WEBOTS_STDERR environment variables. When these variables are defined, the simulation output is redirected to Webots standard stdout and sterr streams. For example:

$ ssh myname@remote.computer.org $ export DISPLAY=:0.0 $ export WEBOTS_STDOUT=1 $ export WEBOTS_STDERR=1 $ nohup webots --minimize myworld.wbt & nohup: ignoring input and appending output to `nohup.out' $ exit

With the nohup approach, the decision to terminate the job is usually made in the Supervisor code according to simulation specific critera. The wb_supervisor_simulation_quit() function can be used to automatically terminate Webots.

5.8.3 Using a Virtual Frame Buffer

Sometimes Webots will be unable to connect to an X11 server on the remote computer. This may be because the remote computer is not running any X11 server, or because the X11 server was started by another user and therefore it does not authorise a connection from a different user. It may also be possible that the remote computer has no graphics card installed (headless).

It is possible to overcome these problems by connecting webots to a virtual frame buffer. The Xvfb command (virtual framebuffer X server for X Version 11) is exactly what is needed: it's an X server that can run on machines with no display hardware. So here is how to start a webots job on a remote computer without X11 server and to log out without killing the job:

$ ssh my_name@remote.computer.org $ nohup Xvfb -screen 0 640x480x16 :5 & $ export DISPLAY=:5 $ export WEBOTS_STDOUT=1 $ export WEBOTS_STDERR=1 $ nohup webots --minimize myworld.wbt & $ exit

Explanations: Xvfb :5 starts a virtual frame buffer on display 5. The extra -screen 0 640x480x16 option is needed because Webots requires at least a 16 bit OpenGL depth buffer. On the next line export DISPLAY=:5 informs any subsequent X11 program to use display 5. The next two lines instruct Webots to use the standard output and error streams instead of printing to the GUI Console. The next line starts webots (using display 5); the graphical output goes to Xvfb and is not visible to the user. The last line, logs the user out but leaves Xvfb, Webots and the controllers running.

5.8.4 Using Cameras

The X11 server connection is required because Webots depends on OpenGL for various aspects of the simulation, in particular for computing the images of the simulated Camera devices. Like the rendering of Webots main 3D view, the OpenGL computation of the Camera images does actually takes place on the computer used as X11 server (DISPLAY environment variable). So when Cameras are used it becomes particularly important to choose wisely which computer (remote or local ?) is used as X11 server, e.g. it is advisable to use a computer with an accelerated OpenGL graphics card.

^ page top ^

E-mail to webmaster

Last updated: