next up previous contents index
Next: Installation Issues Up: Introduction Previous: Objective

General Structure

Our simulator implements two main objects: the robot and the world (figure 1.2). The robot includes either the emulation of the mechanical parts of the robot (legs, sensors,...) as well as the execution of the robot controller. As far as the world is concerned, it implements the ground and the visual landmarks emulation. All these objects can be initialized by the user by setting the corresponding configuration files and they can be controlled on line through the user interface provided by the simulator.      


 
Figure 1.2: The simulator logical structure. 
\begin{figure}
\centerline{
\includegraphics [width=0.9\linewidth]{images/e_logica.eps}
}\end{figure}

The different objects interact between them:


 
Figure 1.3: The processes of the simulator. Each oval represents an independent process 
\begin{figure}
\centerline{
\includegraphics [width=0.9\linewidth]{images/e_processos.eps}
}\end{figure}

Two kinds of simulators are possible according to who owns the control of the simulation execution: the user controller or the simulator routines. In the first approach, the user controller constitutes the main program of the simulation and has to decide when to pass control to the robot and world update routines. An example of this approach is the Webots simulator [5]. In the second approach, the simulator routines passes the control to the user controller form time to time (in general once each time slice). The user controller has to use these opportunities to command low level commands to the simulated robot that are executed as soon as the user routines return the execution control to the simulator code. An example of this approach, that is the one taken by the simulator presented here, is the Kephera simulator [6].

  When running, three processes are executed in parallel (see figure 1.3). The first one implements the main loop in charge of executing the user defined controller from which low level commands are derived. This process uses these low level commands to update the state of the robot and the world for the next time slice. The second parallel process executes the user interface from which the state of the robot and the world can be modified on line. Finally, the third parallel process is the one in charge of displaying the geometry (that is changed when the robot or the world are updated). This process also allows to change the view on the scene according to the user preferences.

  The simulator is executed as an external module of Geomview [7]. This program is in charge of the geometry management and the external module implements either the user interface and the main loop processes.


next up previous contents index
Next: Installation Issues Up: Introduction Previous: Objective
Josep M. Porta Pleite
8/2/2000