1 Lab+Hwk 3: Introduction to the Webots Robotics Simulation Software

Transcription

1 1 Lab+Hwk 3: Introduction to the Webots Robotics Simulation Software This laboratory requires the following software (pre-installed in BC07/08): C development tools (gcc, make). Webots simulation software. The laboratory duration is about 3 hours. Homework will be due on the 7 th day after your lab session, at 12 noon. Please format your solution as a PDF file with the name [name]_lab[#].pdf, where [name] is your account user name and [#] is the number of the lab+homework assignment, and upload it as the Report submission onto the student section of the course webpage. All additional material (movies, code, and any other relevant files) should be archived as a zip file with the name [name]_lab[#].tgz (hint: tar cvzf [name]_lab[#].tgz [directory]) and uploaded as the Additional Material submission onto the student section of the course webpage. Every misnamed file will result in a 1 point penalty to your assignment grade. Keep in mind that no late solutions will be accepted unless supported by health reasons (and a note from the doctor). If there are extreme circumstances which will prevent you from attending a particular lab session, it may be possible to make arrangements with the TAs before the lab in question takes place. The more advance notice you can give in these situations, the more likely it is that we will be able to work something out. 1.1 Grading In the following text you will find several exercises and questions. The notation S means that a simulation is necessary; you are not required to write or produce anything for these questions. The notation Q x means that the question can be answered theoretically, or based on the previous simulation (S); your answers to these questions must be submitted in your Report. The length of answers should be approximately two sentences unless otherwise noted. The notation I x means that the problem has to be solved by implementing a piece of code and performing a simulation; the code written for these questions must be submitted in your Additional Material. Please use this notation in your answer file! 1.2 The e-puck The e-puck is a miniature mobile robot developed to perform desktop experiments for educational purposes. Figure 1-1 shows a close-up of the e-puck robot.more information about the e-puck project is available at The e-puck distinguishing characteristic is its small size (7 cm in diameter). Other basic features are: significant processing power (dspic 30F6014 from Microchip running at 30 MHz), programmable using the standard gcc compilation tools, energetic autonomy of about 2-3 hours of intensive use (with no additional turrets), an extension bus, a belt of eight light and proximity sensors, a 3 axis accelerometer, three YB, JP Swarm Intelligence, Lab+Hwk 3: Intro to the Webots Robotic Simulation Software 1

2 microphones, a speaker, a color camera with a resolution of 640x480 pixels, 8 red leds placed around the robot and a bluetooth interface to communicate with a host computer. The wheels are controlled by two miniature step motors, and can rotate in both directions. Figure 1-1: Close-up of an e-puck robot. The simple geometrical shape and the positioning of the motors allow the e-puck to negotiate any kind of obstacle or corner. Modularity is another characteristic of the e-puck robot. Each robot can be extended by adding a variety of modules. For instance, some other labs in the Swarm Intelligence course make use of a dedicated ZigBee communication module. A follow-up lab on the real e-puck (next week) will allow you to further understand the e-puck hardware platform. The e-puck robot can be simulated in the Webots simulator, as shown in Figure 1-2. The current version of the simulated model can simulate the differential wheels system with physics (including friction, capability to push objects, etc.), and the distance sensors. This model will be further refined to represent more of the e-puck functionalities. Figure 1-2: Webots simulation of the e-puck robot. YB, JP Swarm Intelligence, Lab+Hwk 3: Intro to the Webots Robotic Simulation Software 2

3 1.3 Webots Webots is a fast prototyping and simulation software developed by Cyberbotics Ltd., a spin-off company from the. Webots allows the experimenter to design, program and simulate virtual robots which act and sense in a 3D world. Then, the robots controllers can be transferred to real robots (see Figure 1-3). Webots can either simulate the physics of the world and robots (nonlinear friction, slipping, mass distribution, etc.) or simply the kinematic laws. The choice of the level of simulation is a trade-off between simulation speed and simulation realism. However, in any case all sensors and actuators are affected by a realistic amount of noise so that the transfer from simulation to the use of real robot controllers is usually very smooth. Webots can simulate any type of robots, including wheeled, legged, flying and swimming robots. Several examples are included in the Webots distribution and Guided Tour. During this laboratory we will perform experiments only with the e- puck models. Webots Scene Tree editor allows one to design and place several types of objects in the environment. Figure 1-3: Overview of Webots principles. A very useful feature of the Webots simulator, in particular for multiple-robot experiments, is the way supervisor modules are implemented. A supervisor module is a program similar to a robot controller module. However, such a program is not associated with a given robot but rather with the whole simulation world. The supervisor module is able to get information from robots about their internal (control flag, sensor data, etc) and external variables (position, orientation, etc), and also from some objects in the world such as balls. Supervisor modules can be used for: YB, JP Swarm Intelligence, Lab+Hwk 3: Intro to the Webots Robotic Simulation Software 3

4 Monitoring of experimental data (e.g., reading the robot trajectories); Controlling experimental parameters, (e.g., resetting the robot positions); Defining new virtual sensors. Controller and supervisor modules are programmed in C, C++ or Java. For this lab we will use C exclusively. 2 Webots mini-tutorial At the begininning of your lab session you will go through a mini-tutorial that introduces you to Webots' user interface. First you need to download the lab package from the course webpage, please follow these steps: 1. Dowload the webots-lab3.tgz file from the WEEK 5 section of the course's Moodle site, to the directory of your choice. 2. Extract the file with this command: tar xvzf webots-lab3.tgz 2.1 Starting Webots 1. Launch Webots from a terminal by entering this command: webots & 2. If you're openning Webots for the first time, the About Webots and Guided Tour windows will pop up: you can discard them. 3. Using Webots File/Open... menu, open the e-puck.wbt file from the webotslab3/worlds directory structure that was just created. 4. At this point the e-puck model should appear in Webots main window. 5. Now you can hit the Run button and the e-puck robot will start moving. 6. The rays of the proximity sensors can be displayed in Webots. Please switch on this feature using the menu: Edit->Preferences->Rendering tab->display sensor rays. You can Stop, Run and Revert the simulation with the corresponding buttons in Webots' toolbar. Please do try all these buttons: Revert: Reload the world (.wbt) file and restarts the simulation from the beginning Step: Go one simulation step forward Stop: Stop at the current simulation step Run: Run the simulation Fast: Run the simulation at the maximal CPU speed (OpenGL rendering is disabled for better performance) At the bottom of Webots 3D window you will see two numerical indicators (see Figure 4): The left indicator (0:00:08:768) shows the simulation elapsed time as Hours:Minutes:Seconds:Milliseconds. Note that this is simulated time (not the wall clock time), it stops when the simulation is stopped. Figure 4: Elapsed time indicator and speedometer The right indicator (4.16x) is the speedometer which indicates how fast the simulation is currently running with respect to real time (wall clock time). See how YB, JP Swarm Intelligence, Lab+Hwk 3: Intro to the Webots Robotic Simulation Software 4

5 the elapsed time and speedometer are affected by the simulation Run, Stop and Fast buttons. 2.2 Manipulating objects Learn how to navigate in the 3D view using the mouse: Try all the mouse buttons and wheel while dragging the mouse. It is also possible to manipulate objects with the mouse: This can be done while the simulation is stopped or running. In order to move an object: first select the object and then: For translation: hold down the shift key and the left mouse button to shift the object in the xz-plane (parallel to the ground). For rotation: hold down the shift key and the right mouse button to rotate the object around its rotation axis. For lift: hold down the shift key and press simultaneously the left and right mouse buttons (or the middle button), and drag the mouse up and down to lift and lower the object (Alternatively you can also use the mouse wheel). Try to translate / rotate / lift the e-puck robot and the obstacles both while the simulation is running and stopped. 3 Getting familiar with Webots This lab consists of several modules. We will start by programming a simple obstacle avoidance behavior for a single robot. We will then move to more complex collective behaviors that can help you to get insights for solving the homework problems. 3.1 Simple obstacle avoidance The current e-puck behaviour is controlled by a controller program written in C. The program source code can be edited like this: 1. Press Ctrl-T to open Webots Scene Tree (if not already opened). 2. In the Scene Tree : expand the DEF E_PUCK DifferentialWheels node. 3. Scroll down and select the controller e-puck field. 4. Hit the Edit button: this opens the controller's code (e-puck.c) in Webots' editor, the file looks like this: webots-lab3/controllers/e-puck/e-puck.c: #include <device/robot.h> #include <device/differential_wheels.h> #include <device/distance_sensor.h> #define NB_SENSORS 8 #define TIME_STEP 64 DeviceTag ps[nb_sensors]; static void reset(void) { int i; char name[4]="ps0"; for(i=0;i<nb_sensors;i++) { ps[i]=robot_get_device(name); /* get a handler to the sensor */ /* perform distance measurements every TIME_STEP millisecond */ distance_sensor_enable(ps[i],time_step); name[2]++; /* increase the device name to "ps1", "ps2", etc. */ } } YB, JP Swarm Intelligence, Lab+Hwk 3: Intro to the Webots Robotic Simulation Software 5

6 static int run(int ms) { int v; v = distance_sensor_get_value(ps[0]); /* range: 0 (far) to 4095 (close) */ robot_console_printf("v=%d\n",v); if (v>512) { /* we detected an obstacle with this sensor */ differential_wheels_set_speed(400,-400); /* spin round */ return 1280; /* run for 1280 milliseconds */ } else { differential_wheels_set_speed(600,600); /* advance, slightly turning */ return 64; /* run for 64 milliseconds. */ } } int main() { robot_live(reset); /* initialization */ robot_run(run); /* starts the controller */ return 0; } Remark: Such a controller program, once compiled and linked, cannot be run from a shell like a standard C program in UNIX. It has to be launched within the Figure 5: E-puck proximity sensors simulator because there is communication with Webots through pipes. Examine the code carefully: The distance sensors in the e-puck.c file corresponds to those indicated in Figure 5. For example, ps0 in the code corresponds to IR0 in the figure, ps1 in the code corresponds to IR1 in the figure, etc. Note that sensor numbers increment going clockwise; ps0 and ps7 are at the front. In the code, the function distance_sensor_enable() initializes the e- puck sensors. The function distance_sensor_get_value() reads the sensors values while differential_wheels_set_speed() sends commands to the wheel motors (actuators). The user-defined run() function is called repeatedly by Webots; this function implements one step of simulation. The duration of the step will correspond to the returned value in milliseconds (in this example 64 or 1280 milliseconds). You can find more information on these function in Webots Reference Manual which can be opened using the menu: Help->Reference Manual. In this exercise will have to implement your own controller as a replacement for the current e-puck controller. Your controller will be named obstacle, it can be created by copying the e-puck controller. In a terminal do this: $ cd webots-lab3/controllers $ mkdir obstacle $ cp e-puck/e-puck.c obstacle/obstacle.c $ cp e-puck/makefile obstacle/makefile YB, JP Swarm Intelligence, Lab+Hwk 3: Intro to the Webots Robotic Simulation Software 6

7 Note that with Webots, each controller must be placed in its own directory and that the directory name and the source file name must correpond (e.g., the directory xyz-controller contains the file xyz-controller.c). Furthermore, each controller directory must also contain a copy of the controller Makefile. From now on, each time we ask you to save your controller we will implicitely assume that you also create the corresponding directory and copy the Makefile as explained above. Now open the obstacle.c file in Webots editor, then hit the Make button of the editor to compile obstacle.c. At this point obstacle.c should compile without problem because it is just a copy of the original e-puck.c. If compilation fails ask for assistance. Now Webots must be told to use the newly created obstacle controller, proceed as follows: 1. If the simulation is running stop it by pushing the Stop button 2. Push the Revert button 3. Open the Scene Tree window (if closed) with Ctrl-T. 4. In the scene tree : expand the DEF E_PUCK DifferentialWheels node. 5. Scroll down a bit and select the field: controller e-puck 6. Hit the [...] button and choose the obstacle controller from the list: Now, you should have: controller obstacle 7. Then save your world as obstacle.wbt. Finally, you can push the Run button to execute the simulation with the new obstacle controller. At this point the obstacle controller must behave like the epuck controller. Now you can start answering the lab questions: I 1 (10): As you may have noticed, the original e-puck.c controller does not allow the robot to avoid obstacles very well. Now, you must modify obstacle.c so that your robot is capable of avoiding any type of obstacle in any maze. Hint: implement an appropriate perception-to-action loop by starting with the 2 central sensors on the front and then exploiting all the 8 available proximity sensors. Test the performance of your obstacle avoidance algorithm. Try to keep your solution simple and reactive. Save you changes in obstacle.c and your world as obstacle.wbt. S: Open the u_obstacle.wbt world which contains a long, narrow corridor that has a dead end. The robot can detect both walls simultaneously. Change the robot controller to your obstacle controller, save and run the world. Q 2 (5): What happens when the robot tries to avoid obstacles here? If obstacle avoidance still works, what types of controllers might have trouble here. If it doesn t work, how could the controller be modified to work properly? I 3 (5): In the same way that you created the obstacle.c controller, now create a new controller named u_obstacle.c that allows the robot to escape from a U- obstacle (if it could already, you can keep the same code). Be sure you save your new program in u_obstacle.c. S: Test the robustness of your program again by painting all the walls of the U- obstacle maze (u_obstacle.wbt) in black first, and then in white. Hint: remove the texture and change the color of 3 objects in the Scene Tree: reset/delete DEF U_{...}_SOLID -> children -> Shape -> Appearance -> ImageTexture modify DEF U_{...}_SOLID -> children -> Shape -> Appearance-> Material -> diffusecolor YB, JP Swarm Intelligence, Lab+Hwk 3: Intro to the Webots Robotic Simulation Software 7

8 Q 4 (5): What happens? How does the color affect the obstacle avoidance behavior of the robot? S: Now test the effectiveness of your u_obstacle.c controller in the presence of other robots. Open the multi_obstacle.wbt world which contains five e- pucks, change the five controllers to u_obstacle, then save and run the world. Q 5 (10): What happens? What are the additional difficulties involved in avoiding other robots (list at least two)? Q 6 (5): Do you have an idea how a proximity sensor works and how could it be implemented from a hardware point of view? 3.2 Braitenberg vehicles Valentino Braitenberg presented in his book Vehicles: Experiments in Synthetic Psychology (The MIT Press, 1984) several interesting ideas for developing simple, reactive control architectures and obtaining several different behaviors. These types of architectures are also called proximal because they tightly couple sensors to actuators at the lowest possible level (proximal to the hardware). Conversely, distal architectures imply the presence of at least one additional layer between sensors and actuators, a layer which could consist for instance of basic behaviors, based on a priori knowledge which the programmer wants to give the robot. light sensors motors a 2b 3a 3b Figure 2-6: Four Braitenberg vehicles. The numbering corresponds to the original one used by Braitenberg. Plus signs correspond to excitatory connections, minus signs to inhibitory ones. Vehicle 2a avoids light by accelerating away from it. Vehicle 2b exhibits a light approaching and following behavior, accelerating more and more as approaches the source. Vehicle 3a approaches light but brakes and stops in front of it. Finally, vehicle 3b avoids light by braking and accelerating away toward darker areas. In this lab, we want to see what we can achieve if robots are programmed as Braitenberg vehicles. Figure 2-6 shows four different Braitenberg vehicles. Q 7 (5): Which vehicle should you implement for avoiding obstacles? I 8 (5): Implement the controller requested in step I 1 using Braitenberg principle on distance sensors (and not light sensors) and exclusively using a linear perception-to action map (i.e., essentially a 8x2 coefficient matrix). Create a new controller and save it as braiten.c. Q 9 (5): What are the difficulties of designing such a controller? What are the differences between one of the vehicles proposed by Braitenberg and the controller you implemented in I 1 (obstacle.c) and in I 3 (u_obstacle.c)? S: Run obstacle avoidance experiments with the provided worlds that contains 1, 5 and 10 e-pucks robots. The robot models in e-puck_physics_1x.wbt, e- puck_physics_5x.wbt, and e-puck_physics_10x.wbt use dynamic (physicsbased) simulation type. The ones provided in e-puck_kinematic_1x.wbt, e- YB, JP Swarm Intelligence, Lab+Hwk 3: Intro to the Webots Robotic Simulation Software 8

9 puck_kinematic_5x.wbt and e-puck_kinematic_10x.wbt use kinematic simulation. The ones provided in e-puck-2d_1x.wbt, e-puck_2d_5x.wbt and e-puck_2d_10x.wbt use a 2D simulation engine (Enki). Q 10 (5): What is the difference in term of simulator performance when running these different types of simulation in Fast mode (without 3D display)? 4 Hwk: More insight in Webots 4.1 Understanding distance sensor modeling in Webots In Webots, the behavior of distance sensor is modeled by computing the intersection between a ray cast from the center of the sensor and directed according to the orientation of the sensor (rotation field of the DistanceSensor node). For each sensor a lookup table is used to determine the answer of the sensor according to the distance to the obstacle. This also defines implicitly the range of the sensor. This lookup table includes the return values as well as the noise level for a number of distances entries. A linear extrapolation is performed on this lookup table to compute the answer (value and noise) for a given measurement. You will find more information about the modelling of the DistanceSensor in Webots Reference Manual (Chapter 2, Section 15). Be sure you understood the principle of the distance sensor before going further: Q 11 (5): As you may have noticed, a special case is made for infra-red distance sensor, since their behavior depends on the color of the objects. How does one mark a distance sensor to be an infra-red sensor? How do object colors influence the answer of such infra-red sensors? Q 12 (5): Look at the DistanceSensor nodes used to simulate the sensors of the e- puck robot. How many entries are contained in the lookup table? What is the maximum range of the sensors? Modeling a distance sensor with a single ray casting may be a bad approximation for sensors with a wide field of view, as the sensors of the e-puck robot. In most cases, such an approximation is sufficient and provides a fast simulation speed, but in some cases, it may be desirable to have a better sensor modeling. In order to improve this simple model, several options are available. One may first use several simulated distance sensors to approximate the behavior of a single real distance sensor. All the simulated distance sensors should be located at the same position, but heading into slightly different directions. This corresponds to several ray castings and the measured values for each sensor should be used to compute a weighted sum corresponding to a more realistic measurement for the real distance sensor. Q 13 (5): Try to model an infra-red sensor with 4 rays: set the numberofray field of a DistanceSensor nodes to 4, set the aperture to 0.3 and the gaussianwidth field to 1.0 to model appropriate values of the e-puck robot. Read the description of the DistanceSensor in the reference manual (Chapter 2, Section 15). What would happen if we were to set the gaussianwidth to 0? Would doing this ever be useful? YB, JP Swarm Intelligence, Lab+Hwk 3: Intro to the Webots Robotic Simulation Software 9

10 4.2 Noise in Webots It s possible to configure the noise on sensor readings and motor outputs in the Webots simulator in order to model what happens in the real world. Real-world noise can cause poor performance on many algorithms which perform very well theoretically. However, noise can sometimes be useful in some scenarios. S: Open and run the no_noise.wbt world; in this example the noise of all the e- pucks proximity sensors is set to 0. Q 14 (5): What happens? Why? S: Increase the proximity sensor noise. Q 15 (10): What happens now? Why? What does this tell you about noise in robotic experiments? 4.3 Using Webots Supervisor In Webots, a supervisor controller is similar to a robot controller. It corresponds to a Supervisor node in the scene tree. However, a supervisor controller has more capabilities than a regular robot controller. It can be used to make dynamic environment (i.e., move objects while the simulation is running), track the trajectory of robots, reset initial positions of robots, send (resp. receive) message to (resp. from) robots, take automatic screenshots in particular situations, etc. An example of a supervisor process is provided with the soccer.wbt example. This example world, contains a soccer field with 6 robots and a ball. A supervisor process is used to track the position of the ball to determine when the ball enters a goal, compute the score of the match, display it and reset the initial positions of the robots and the ball after a goal is scored. Open the source code of the supervisor using Webots editor (the file is located at webots-lab3/controllers/soccer_supervisor/soccer_supervisor.c). I 16 (5): Review the source code of soccer_supervisor.c and try to understand how it works and change the inital position of the ball, so that it starts at 10 cm up in the air at position (0,0.1,0) after a goal is scored. Be sure you save your final version of soccer_supervisor.c. Q 17 (5): How is it possible to know the current simulation time in a controller process? YB, JP Swarm Intelligence, Lab+Hwk 3: Intro to the Webots Robotic Simulation Software 10