Theory

Obstacle avoidance in mobile robots refers to a robot’s ability to autonomously adjust its path in response to objects in its environment. This is achieved either through proximal (reactive) or distal (rule-based) control. The difference between these two control paradigms can be subtle.

Under proximal control, the robot’s sensors are tied directly to the motor controls and the motor speeds respond to the sensor input directly. One way to implement this is to create a weighted matrix that converts the sensor inputs into motor speeds. You can use a two-dimensional array with the number of rows corresponding to the number of distance sensors and the number of columns corresponding to the number of motors. For example, if we consider a two-wheel differential-wheels robot with eight sensors, then the array would have eight rows of two columns each. In this case each row can be thought of as a two item list specifying the left and right motor speeds respectively. This array is then used in the avoidance algorithm. The algorithm used as well as the values of the weighted matrix depends on the particular implementation that you are planning. The weights of the matrix are determined empirically. For example the Braitenberg controller implements the control algorithm below.

speed[i] += matrix[j][i] * (1.0 – (sensorsValue[j] / 512));

The speed[] array is a two item array representing the speed of the left and right motor, the matrix[] array holds the values in the weighted matrix, and the sensorsValue[] array holds the sensor values. The 512 normalizes the sensor values and the values i and j are values from a nested for loop that is used to iterate over the sensor values and weighted matrix.

Under distal control, the sensor values are fed to a set of rules (think if-then statements) that determines the motor speeds. For example, you may have some code like the one below in your step function:

if (distance[6]+distance[7] > 1800 || distance[0]+distance[1] > 1800) {

do some action, i.e. set motor speeds to turn the robot;

}

With either control paradigm there are situations in which the robot may get stuck, e.g. in a narrow passage it may try to turn right and left at the same time or it may get stuck in a U-shaped corridor and spend its time running from one wall to the other. One way to make your controller more robust is to introduce noise. This can be in the form of infrequent random deviations from the general rules, think dice throwing, or perhaps more eloquently, you can use the natural noise that arises from the robots sensors. We tend to think of noisy sensors as a hindrance to overcome, but we can use this same noise to improve the performance of our algorithms if we are thoughtful.

## Webots

Although you have developed some familiarity with Webots there are a couple features we wanted to point out explicitly. The Webots IDE consists of four windows, the Scene Tree, the World View, the Editor, and the Console. The Scene Tree shows the structure of the world and its components. This is what you spent your time with during the first lab. The World View shows the simulation that you are running including the world you created and the robot(s) you are using. The Editor allows you to create and edit the code for the controller. The Console is primarily used to debug errors in your code or simulation. One new window we have not yet explored is the Robot Window in the Robot drop-down menu. This provides you with real-time information about the robot’s sensors (shown in blue), wheel speed (shown in red), and the odometry (shown in green). This window will be useful to you as you create the weighted matrix for proximal control or write the rules used for distal control as it will give you a sense of the typical values you will encounter from the sensors. Lastly, if you want information about the E-Puck in your world, you can examine the epuck.proto code in the proto directory you will download for the exercise. In this file you can also find the names for the sensors. To get you started, the names of the distance sensors are “ps0” – “ps7” and the name for the camera is “camera”. Depending on how far you got during lab 2, you may also want to refer back to the Controllers page from last time.

## Exercise

Create a controller for the E-Puck that implements basic obstacle avoidance. Choose either a proximal or distal implementation or, if you have time, implement both. We have created a basic world with an E-Puck for you to experiment with. To begin programming, follow these steps:

1. In the terminal navigate to the directory in which you want your new project and create a directory for lab3 by typing mkdir lab3 in the terminal.
2. Download the lab3.wbt file and the directory protos from the Files link under lab 3 on the course page.
3. Open Webots and choose Your Project

1. in the Wizard menu, choose New Project Directory and create it under the lab3 directory you just made.
2. Place the lab3.wbt file that you just downloaded in the worlds directory of lab3.
3. In order for the world we gave you to function revert correctly, you will also have to add the protos directory into your lab3 directory. This will give you a maze and an E-Puck to work with.
4. Open the lab3.wbt world in the World View of Webots.
5. In the Wizard directory choose New Robot Controller and pick the language you are going to use and name the controller lab3Controller and choose yes to editing the controller. This will open a blank controller template in the editor window.
6. Write a controller that will allow the E-Puck to avoid obstacles.