the y axis, a translation, and aUSE SONAR Transform, with a name (FL1, RR4, ...) to be used by the controller.
Sonar name translation rotation FL1 -0.027 0.209 -0.164 0 1 0 1.745 FL2 -0.077 0.209 -0.147 0 1 0 2.094 FL3 -0.118 0.209 -0.11 0 1 0 2.443 FL4 -0.136 0.209 -0.071 0 1 0 3.14 FR1 0.027 0.209 -0.164 0 1 0 1.396 FR2 0.077 0.209 -0.147 0 1 0 1.047 FR3 0.118 0.209 -0.116 0 1 0 0.698 FR4 0.136 0.209 -0.071 0 1 0 0 RL1 -0.027 0.209 0.253 0 1 0 -1.745 RL2 -0.077 0.209 0.236 0 1 0 -2.094 RL3 -0.118 0.209 0.205 0 1 0 -2.443 RL4 -0.136 0.209 0.160 0 1 0 -3.14 RR1 0.027 0.209 0.253 0 1 0 -1.396 RR2 0.077 0.209 0.236 0 1 0 -1.047 RR3 0.118 0.209 0.205 0 1 0 -0.698 RR4 0.136 0.209 0.160 0 1 0 0
Table 4.1: Translation and rotation of the Pioneer 2TMDEF SONAR Transforms
To finish modeling the Pioneer 2TM robot, you will have to fill in the remaining fields of the DifferentialWheelsnode as shown in figure 4.25.
66 CHAPTER 4. TUTORIAL: MODELING AND SIMULATING YOUR ROBOT
Figure 4.25: Some fields of the Pioneer 2TMDifferentialWheelsnode
as possible and the programming interface can be ported or interfaced to existing real robots. We-bots already include transfer systems for a number of existing real roWe-bots including KheperaTM, HemissonTM, LEGO MindstormsTM, AiboTM, etc. This section explains how to develop your own transfer system to your very own mobile robot.
Since the simulation is always a more or less accurate approximation of the physics of the real robot, some tuning is always necessary when developing a transfer mechanism for an existing real robot. This tuning will affect the simulated model so that it better matches the behavior of the real robot.
4.5.1 Remote control
Overview
The easiest way to transfer your control program to a real robot is often to develop a remote con-trol system. In this case, your concon-trol program runs on the computer, but instead of sending com-mands to and reading sensor data from the simulated robot, it sends comcom-mands to and read sensor data from the real robot. Developing such a remote control system can be achieved in a very sim-ple way by writing your own imsim-plementation of the Webots API functions as a small library. For example, you will probably have to implement thedifferential wheels set speed func-tion as a funcfunc-tion that sends a specific command to the real robot with the wheel speeds as an
4.5. TRANSFER TO YOUR OWN ROBOT 67 argument. This command can be sent to the real robot via the serial port of the PC or whatever PC robot interface you have. You will probably need to make some unit conversion since your robot may not use the same speed unit as the one used in Webots. The same applies for reading sensor values from the real robot.
Developing a custom library
Once you have created a number of C functions implementing the Webots functions you need to redirect outputs and inputs to the real robot. You will then be able to reuse your Webots controller used for the simulation without changing a line of code, and even without recompiling it to an object file: Instead of linking this object file with the WebotsControllerdynamic library, you will link it with your own C functions. For your convenience, you may want to create a static or dynamic library containing your own robot interface.
Special functions
Therobot livefunction can be used to perform some initialization, like setting up the connec-tion with the real robot.
Therobot get devicefunction should return arbitrary integer values specific to each device of your real robot. These values should be used by device specific functions. For example, the distance sensor get valuefunction is able to recognize the specified device and return the correct value.
The robot run function should call repeatedly the function passed as an argument. The first call should be performed with 0 as an argument. It should then take care of the return value of the run function and respect the requested delay before calling again this function. The parameter passed to the run function should describe the actual delay (see reference description about the robot runfunction for more details about it).
Running your real robot
Once linked with your own library, your controller can be lauched as a stand alone application to control your real robot. It might be useful to include in your library or in your Webots controller some graphical representation to display sensor values, motor commands or a stop button. Such a remote control system can be implemented in C as explained here, however, it can also be implemented in Java using the same principle by replacing theController.jar Webots file by your own robot specificController.jarfile and using this one to drive the real robot.
68 CHAPTER 4. TUTORIAL: MODELING AND SIMULATING YOUR ROBOT
4.5.2 Cross-compilation
Overview
Developing a cross-compilation system will allow you to recompile your Webots controller for the embedded processor of your own real robot. Hence the source code you wrote for the Webots simulation will be executed on the real robot itself and there is no need to have a permanent PC connection with the robot as with the remote control system. This is only possible if the processor on your robot can be programmed in C, C++ or Java. It is not possible for a processor that can be programmed only in assembler or another specific language. Webots includes the source code of such a cross-compilation system for the Hemisson robot. This sample is located in theHemiOS directory of thehemisson controller.
Developing a custom library
Unlike the remote control system, the cross-compilation system requires that the source code of your Webots controller be recompiled using the cross-compilation tools specific to your very own robot. You will also need to rewrite the Webots include files to be specific to your very own robot. In simple cases, you can simply rewrite the Webots include files you need, as in the hemisson example. In more complex cases, you will also need to write some C source files to be used as a replacement of the WebotsController library, but running on the real robot.
You should then recompile your Webots controller with your robot cross-compilation system and link it with your robot library. The resulting file should be uploaded onto the real robot for local execution.
Examples
Webots support cross-compilation for the several existing commercial robots. For the HemissonTM robot, this system is as simple a few include files replacing the Webots API include files. For the KheperaTMrobot, a specific C library is used additionally to specific include files. For the LEGO MindstormsTMrobot, a Java library is used and the resulting binary controller is executed on the real robot using theLeJOSJava virtual machine.
4.5.3 Interpreted language
In some cases, it may be better to implement an interpreted language system. This is useful if your real robot already uses an interpreted language, like Basic or a graph based control lan-guage. In such a case, the transfer is very easy since you will just transfer the code of your program that will be interpreted on the real robot. The most difficult part may be to develop a language interpreter in C or Java to be used by your Webots controller for controlling the simu-lated robot. Such an interpreted language system was developed for the HemissonTMrobot with the BotStudioTMsystem.